Шифрування ZFS RAID та LUKS в Linux


24

Я планую встановити набір 3x 2TB 7200 об / хв як зашифрований LUKS пул Z-RAID в Linux (для рішення NAS).

Я розумію проблему, яка полягає в тому, що єдиний спосіб досягти цього - luksFormatкожен фізичний пристрій, а потім зібрати zpool із незамкнених контейнерів LUKS.

У мене є такі проблеми з цим:

  • Чи не суттєво це перешкоджатиме виконанню запису? У цій установці надлишкові дані шифруються кілька разів, оскільки LUKS не "знає" про Z-RAID. У рішенні LUKS-на-mdadm дані шифруються один раз і просто записуються на диски кілька разів. Мій процесор підтримує Intel AES-NI.

  • Чи буде ZFS обізнаний про збої диска під час роботи на контейнерах LUKS-картографа пристроїв на відміну від фізичних пристроїв? Як щодо дедуплікації та інших функцій ZFS?


4
Я б не робив цього. Звуки невдачі.
ewwhite

3
@MadHatter Тому що це ZFS. Ви не можете цього зробити.
Майкл Хемптон

1
Чудово (я візьму за це ваше слово). Зробити однієї великої ZFS , що містять один великий файл, петлевий змонтувати його і шифрувати , що .
MadHatter підтримує Моніку

1
@eewhite Я просто з'ясовую варіанти використання шифрування за допомогою ZFS в Linux, поки модуль ядра ZFS не реалізує шифрування самостійно. Але я маю згоду - ЛУКС та ZFS, схоже, не ладнають.
MasterM

4
Ніколи, ніколи, не створюйте великий файл і не підтримуйте його за допомогою ZFS. У вас не вистачає швидкості, коли коровам не вистачає місця для його роботи.
Vinícius Ferrão

Відповіді:


27

Один із серверів, якими я адмініструю, виконує тип конфігурації, яку ви описуєте. Він має шість жорстких дисків розміром 1 Тб із зашифрованим LUKS пулом RAIDZ. У мене також є два жорсткі диски 3 ТБ у дзеркалі ZFS, зашифрованому LUKS, які щомісяця змінюються, щоб знімати їх. Сервер використовував цю конфігурацію вже близько трьох років, і я ніколи з цим не мав проблем.

Якщо у вас є потреба у ZFS з шифруванням в Linux, то я рекомендую цю установку. Я використовую ZFS-Fuse, а не ZFS в Linux. Однак я вважаю, що це не матиме жодного відношення до результату, окрім ZFS на Linux, мабуть, матиме кращу продуктивність, ніж налаштування, яке я використовую.

У цій установці надлишкові дані шифруються кілька разів, оскільки LUKS не "знає" про Z-RAID. У рішенні LUKS-на-mdadm дані шифруються один раз і просто записуються на диски кілька разів.

Майте на увазі, що LUKS не знає про RAID. Знає лише те, що він сидить поверх блочного пристрою. Якщо ви використовуєте mdadm для створення пристрою RAID, а потім luksformatвін, це mdadm є реплікацією зашифрованих даних на базові пристрої зберігання даних, а не LUKS.

Питання 2.8 відповіді на відповіді на питання LUKS стосується того, чи має бути шифрування поверх 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 визначають, що розділ LUKS має вирівнювання в 1 Мб. Питання 6.12 та 6.13 обговорюють це детально, а також надають поради щодо збільшення заголовка розділу LUKS. Однак я не впевнений, що можна зробити його досить великим, щоб забезпечити створення вашої файлової системи ZFS на кордоні 4K. Мені буде цікаво почути, як це працює для вас, якщо це проблема, яку потрібно вирішити. Оскільки ви використовуєте накопичувачі 2 ТБ, можливо, ви не зіткнетеся з цією проблемою.

Чи буде ZFS обізнаний про збої диска під час роботи на контейнерах LUKS-картографа пристроїв на відміну від фізичних пристроїв?

ZFS буде в курсі відмов диска, наскільки він може читати і записувати на них без проблем. ZFS вимагає блочного зберігання і не дбає і не знає про специфіку цього сховища та звідки він походить. Він лише відслідковує будь-які помилки читання, запису чи контрольної суми, з якими стикається. Вам належить стежити за здоров’ям базових пристроїв зберігання даних.

Документація ZFS містить розділ щодо усунення несправностей, який варто прочитати. У розділі щодо заміни або ремонту пошкодженого пристрою описано, з чим ви можете зіткнутися під час поломки та як ви можете його вирішити. Тут ви зробите те саме, що і для пристроїв, на яких немає ZFS. Перевірте системний журнал щодо повідомлень від драйвера SCSI, контролера HBA або HD та / або програмного забезпечення для моніторингу SMART, а потім дійте відповідно.

Як щодо дедуплікації та інших функцій ZFS?

Усі функції ZFS працюватимуть однаково, незалежно від того, зашифрований базовий блок зберігання чи ні.

Підсумок

  1. ZFS на зашифрованих LUKS пристроях працює добре.
  2. Якщо у вас апаратне шифрування, ви не побачите показника ефективності, якщо ви використовуєте метод шифрування, який підтримується вашим обладнанням. Використовуйте, cryptsetup benchmarkщоб побачити, що найкраще працюватиме на вашому обладнанні.
  3. Подумайте про ZFS як про RAID та файлову систему, об'єднану в єдине ціле. Дивіться діаграму ASCII вище, де вона вписується в стек зберігання.
  4. Вам потрібно буде розблокувати кожен блок-зашифрований блок LUKS, який використовує файлова система ZFS.
  5. Контролюйте стан обладнання для зберігання так само, як зараз.
  6. Пам’ятайте про вирівнювання блоку файлової системи, якщо ви використовуєте диски з 4K-блоками. Можливо, вам доведеться експериментувати з параметрами luksformat або іншими налаштуваннями, щоб отримати необхідне вирівнювання для прийнятної швидкості.

3
+1 Для пошуку способу зробити цю роботу на прикладах.
ewwhite

1
1 МіБ вже рівномірно ділиться на 4 Кбіт, тому вам слід правильно вирівняти до рівня ashift = 20 (що, я не думаю, буде необхідним у моїй кар'єрі) за умови використання сирих дисків.
Майкл Хемптон

1
Ще одне: я голосую за вашу відповідь, тому що це очікуване ОП, і це добре написано, тож це краще, ніж моя відповідь.
Vinícius Ferrão

3
@ ViníciusFerrão: Також врахуйте, що FreeBSD та FreeNAS використовують ідентичний підхід для шифрування ZFS. geliвикористовується для створення зашифрованого пристрою, і дані простого тексту стають доступними через другий пристрій, який використовує ZFS. Дивіться другу точку кулі на doc.freenas.org/index.php/Volumes#Encryption .
Морська зірка

2
@CMCDragonkai Оскільки і пристрої L2ARC, і SLOG містять біти та фрагменти даних із вашого пулу, якщо ви шифруєте сховище для забезпечення конфіденційності (що найчастіше в першу чергу полягає у використанні зашифрованого сховища), ви майже напевно хочете запускайте будь-які пристрої L2ARC та SLOG, аналогічно зашифрованим.
CVn

2

Альтернативною реалізацією є створення блокового пристрою ZVOL ( http://zfsonlinux.org/example-zvol.html ), використання LUKS для шифрування новоствореного ZVOL, а потім створення файлової системи ext4 (або іншої) поверх шифрованого блоку пристрій.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.