[Comm] RAID, LVM & LUKS

[Nikolay A. Fetisov]

В Чтв, 20/05/2010 в 17:18 +0300, Vaso VV пишет: 
> Дано: AltLinux Desktop KDE4 P5
... 
> Задача:
> Создать на md5 пару-тройку масштабируемых шифрованных разделов.
> 
> Возникшие вопросы:
> 1. Как кошерней: а) организовать сначала LVM-тома, а затем зашифровать 
> их cryptsetup-ом (можно ли [каким образом] в таком случае изменять 
> размер разделов?); или
> б) создать шифрованный раздел и на него повесить LVM?


Тут основной вопрос - для чего и как эти разделы планируется дальше
использовать. В зависимости от этого и можно будет выбирать конкретную
схему.

Кстати, помимо этих двух перечисленных есть и третий вариант - сделать
LUKS-разделы поверх логических разделов дисков, и уже их объединять в
MD-RAID. Не говоря о вариантах, когда часть входящих в VG PV
располагаются на LUKS-разделах, а часть - на обычных некриптованных.

Из тех особенностей, которые сходу пришли в голову:

Вариант partition - LUKS - mdraid - LVM - FS:
- независимые ключи на каждый из дисковых разделов;
- невозможно получить информацию о структуре RAID'а 
  и вышестоящих уровней;
- вся информация криптуется;
- легко изменяются размеры LV (т.е. без лишних действий), работают
  snapshot'ы, и т.п.
- возможно в прозрачном режиме перенести имеющиеся LV на криптованные
  диски и/или обратно;
- требуется ручная сборка mdraid, активация PV, VG, монтирование
  файловых систем;
- корректная остановка всей системы при выключении машины, за
  исключением закрытия разделов LUKS (что, впрочем, мешать не будет).


Вариант partition - mdraid - LUKS - LVM - FS:
- Один общий ключ на PV;
- автоматическая сборка mdraid при загрузке машины;
- невозможно получить заголовок PV и информацию о структуре вышестоящих
  уровней;
- вся информация криптуется;
- легко изменяются размеры LV (т.е. без лишних действий), работают
  snapshot'ы, и т.п.
- возможно в прозрачном режиме перенести имеющиеся LV на криптованные
  диски и/или обратно;
- требуется ручная активация PV, VG, монтирование файловых систем;
- возможны проблемы деактивации mdraid при выключении машины.


Вариант partition - mdraid - LVM - LUKS - FS:
- Независимые ключи на разные LV;
- автоматическая сборка mdraid и LVM при загрузке машины;
- криптуются только конкретные LV;
- возможно использование LV без LUKS;
- при изменении размеров LV требуется также изменение размера тома LUKS,
  с дополнительными действиями по подготовке нового пространства;
- вопросы при работе с snapshot'ами; как минимум, не будет работать
  freeze файловых систем перед созданием snapshot'а;
- возможно перемещение LV с LUKS между разными PV без угрозы защиты
  данных;
- требуется ручное монтирование файловых систем в LV с LUKS;
- возможны проблемы деактивации LVM/mdraid при выключении машины.


Изменение размеров разделов LUKS вполне возможно, последовательность
стандартная: при увеличении - увеличить размер диска нижнего уровня,
заполнить добавленную часть мусором, увеличить размер раздела LUKS,
увеличить размер на следующем уровне. При уменьшении - в обратную
сторону.
Нюансы появляются при определении той части диска, которую требуется
заполнить мусором. Наиболее лёгкий вариант, но плохо подходящий при
изменении размеров при параллельной штатной работе системы - сначала
увеличить размер файловой системы, потом создать на ней файл, заполнив
до конца доступное место, и удалить его. Другие варианты требуют
расчётов размера раздела LUKS и потенциально опасны.


> 2. Нужен ли скрипт [где его пристроить?], выполняемый перед выключением 
> для корректного размонтирования/даективации такого «бутерброда»?

Вообще, для варианта  mdraid - LVM - LUKS обхожусь и без чего-либо
дополнительного. Впрочем, штатные перезагрузки крайне редки, и когда
выполняются, то перед ними обычно руками останавливается всё начиная с
VE и кончая размонтированием практически всех файловых систем.

> 3. Есть ли ещё какие-то особенности, которые нужно учесть в организации 
> связки RAID-LVM-LUKS?

В зависимости от требований к системе. Как минимум, имеет смысл задаться
вопросом о целях построения такой системы и о том, куда и _как_ будут
делаться резервные копии данных.


-- 
С уважением,
Николай Фетисов