Я планирую настроить набор из 3 дисков по 2 ТБ со скоростью вращения 7200 об / мин в качестве зашифрованного LUKS пула Z-RAID в Linux (для решения NAS).
Насколько я понимаю, проблема заключается в том, что единственный способ добиться этого - это luksFormat
каждое физическое устройство, а затем соберите zpool из разблокированных контейнеров LUKS.
У меня есть следующие опасения по этому поводу:
Разве это не значительно снизит производительность записи? В этой настройке избыточные данные шифруются несколько раз, потому что LUKS «не знает» о Z-RAID. В решении LUKS-on-mdadm данные шифруются один раз и просто записываются на диски несколько раз. Мой процессор поддерживает Intel AES-NI.
Будет ли ZFS знать о сбоях диска при работе с контейнерами LUKS сопоставителя устройств, а не с физическими устройствами? Как насчет дедупликации и других функций ZFS?
Один из серверов, которые я администрирую, выполняет описанную вами конфигурацию. Он имеет шесть жестких дисков емкостью 1 ТБ с зашифрованным с помощью LUKS пулом RAIDZ. У меня также есть два жестких диска емкостью 3 ТБ в зеркале ZFS с шифрованием LUKS, которые меняются местами каждую неделю, чтобы убрать их за пределы офиса. Сервер использует эту конфигурацию около трех лет, и у меня никогда не было с ней проблем.
Если вам нужна ZFS с шифрованием в Linux, я рекомендую эту настройку. Я использую ZFS-Fuse, а не ZFS в Linux. Однако я считаю, что это не повлияет на результат, кроме ZFS в Linux, вероятно, будет более высокая производительность, чем установка, которую я использую.
В этой настройке избыточные данные шифруются несколько раз, потому что LUKS «не знает» о Z-RAID. В решении LUKS-on-mdadm данные шифруются один раз и просто записываются на диски несколько раз.
Имейте в виду, что LUKS не знает о RAID. Он знает только то, что находится поверх блочного устройства. Если вы используете mdadm для создания RAID-устройства, а затем luksformat
это mdadm, который реплицирует зашифрованные данные на базовые устройства хранения, а не LUKS.
Вопрос 2.8 из LUKS FAQ касается того, шифрование должно быть поверх RAID или наоборот. На нем представлена следующая диаграмма.
Filesystem <- top
|
Encryption
|
RAID
|
Raw partitions
|
Raw disks <- bottom
Поскольку ZFS сочетает в себе функции RAID и файловой системы, ваше решение должно выглядеть следующим образом.
RAID-Z and ZFS Filesystem <-top
|
Encryption
|
Raw partitions (optional)
|
Raw disks <- bottom
Я указал необработанные разделы как необязательные, поскольку ZFS ожидает, что будет использовать хранилище сырых блоков, а не раздел. Хотя вы можете создать свой zpool с использованием разделов, это не рекомендуется, потому что это добавит бесполезный уровень управления, и его нужно будет учитывать при вычислении вашего смещения для выравнивания блока разделов.
Разве это не значительно снизит производительность записи? [...] Мой процессор поддерживает Intel AES-NI.
Проблем с производительностью быть не должно, если вы выберете метод шифрования, поддерживаемый вашим драйвером AES-NI. Если у вас есть cryptsetup 1.6.0 или новее, вы можете запустить cryptsetup benchmark
и посмотрите, какой алгоритм обеспечит лучшую производительность.
Этот вопрос о рекомендуемых вариантах LUKS также может иметь ценность.
Учитывая, что у вас есть поддержка аппаратного шифрования, вы с большей вероятностью столкнетесь с проблемами производительности из-за несовпадения разделов.
ZFS в Linux имеет добавил ashift
собственность к zfs
команда чтобы вы могли указать размер сектора для ваших жестких дисков. Согласно связанному FAQ, ashift=12
скажет, что вы используете диски с размером блока 4K.
В LUKS FAQ указано, что раздел LUKS имеет выравнивание 1 МБ. Вопросы 6.12 и 6.13 Обсудите это подробно, а также дайте совет, как увеличить заголовок раздела LUKS. Однако я не уверен, что можно сделать его достаточно большим, чтобы файловая система ZFS была создана на границе 4K. Мне было бы интересно услышать, как это сработает для вас, если вам нужно решить эту проблему. Поскольку вы используете диски емкостью 2 ТБ, вы можете не столкнуться с этой проблемой.
Будет ли ZFS знать о сбоях диска при работе с контейнерами LUKS сопоставителя устройств, а не с физическими устройствами?
ZFS будет знать о сбоях дисков, поскольку может без проблем читать и писать на них. ZFS требует блочного хранилища и не заботится и не знает об особенностях этого хранилища и его происхождении. Он отслеживает только любые обнаруженные ошибки чтения, записи или контрольной суммы. Вы должны следить за состоянием основных устройств хранения.
В документации ZFS есть раздел по устранению неполадок. которую стоит прочитать. Раздел о замена или ремонт поврежденного устройства описывает, с чем вы можете столкнуться во время сценария сбоя и как вы можете его решить. Здесь вы сделали бы то же самое, что и для устройств, на которых нет ZFS. Проверьте системный журнал на наличие сообщений от вашего драйвера SCSI, контроллера HBA или HD и / или программного обеспечения для мониторинга SMART, а затем действуйте соответствующим образом.
Как насчет дедупликации и других функций ZFS?
Все функции ZFS будут работать одинаково, независимо от того, зашифровано ли базовое блочное хранилище или нет.
cryptsetup benchmark
чтобы увидеть, что лучше всего подойдет для вашего оборудования.Прошло шесть лет с тех пор, как я написал этот ответ. ZFS в Linux v0.8.0 поддерживает собственное шифрование, что следует учитывать, если у вас нет особой потребности в LUKS.
Альтернативная реализация - создание блочного устройства ZVOL (http://zfsonlinux.org/example-zvol.html), используйте LUKS для шифрования вновь созданного ZVOL, а затем создайте файловую систему ext4 (или другую) поверх зашифрованного блочного устройства.