[Comm] RAID, LVM & LUKS

[Comm] RAID, LVM & LUKS

[Vaso VV]

Дано: AltLinux Desktop KDE4 P5
# cat /proc/mdstat
Personalities : [raid1]
md5 : active raid1 sdb7[0] sda7[1]
       216821120 blocks [2/2] [UU]
...

Задача:
Создать на md5 пару-тройку масштабируемых шифрованных разделов.

Возникшие вопросы:
1. Как кошерней: а) организовать сначала LVM-тома, а затем зашифровать 
их cryptsetup-ом (можно ли [каким образом] в таком случае изменять 
размер разделов?); или
б) создать шифрованный раздел и на него повесить LVM?
2. Нужен ли скрипт [где его пристроить?], выполняемый перед выключением 
для корректного размонтирования/даективации такого «бутерброда»?
3. Есть ли ещё какие-то особенности, которые нужно учесть в организации 
связки RAID-LVM-LUKS?

-- 
WBR........[ ]
TFTHAOT....[x]
AMF........[ ]

Re: [Comm] RAID, LVM & LUKS

[Vaso VV]

20.05.2010 17:18, Vaso VV пишет:
> Дано: AltLinux Desktop KDE4 P5
> # cat /proc/mdstat
> Personalities : [raid1]
> md5 : active raid1 sdb7[0] sda7[1]
> 216821120 blocks [2/2] [UU]
> ...
>
> Задача:
> Создать на md5 пару-тройку масштабируемых шифрованных разделов.
>
> Возникшие вопросы:
> 1. Как кошерней: а) организовать сначала LVM-тома, а затем зашифровать
> их cryptsetup-ом (можно ли [каким образом] в таком случае изменять
> размер разделов?); или
> б) создать шифрованный раздел и на него повесить LVM?
> 2. Нужен ли скрипт [где его пристроить?], выполняемый перед выключением
> для корректного размонтирования/даективации такого «бутерброда»?
> 3. Есть ли ещё какие-то особенности, которые нужно учесть в организации
> связки RAID-LVM-LUKS?
>
а если хауту на altlinux.org обяжусь написать?

-- 
WBR........[ ]
TFTHAOT....[x]
AMF........[ ]

Re: [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?

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


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

Re: [Comm] RAID, LVM & LUKS

[Vaso VV]

26.05.2010 11:27, Nikolay A. Fetisov пишет:
[скип]
> … Не говоря о вариантах, когда часть входящих в VG PV
> располагаются на LUKS-разделах, а часть - на обычных некриптованных.
А если ещё и эти VG тщательно размазать по PV (lvcreate -i)… И какая 
выгода от такого "частичного" шифрования?

[скип]
> - возможно в прозрачном режиме перенести имеющиеся LV на криптованные
>    диски и/или обратно;
"в прозрачном" - это как?

[скип]
> - возможно перемещение LV с LUKS между разными PV без угрозы защиты
>    данных;
опечатка?

[скип]
>
> Изменение размеров разделов LUKS вполне возможно, последовательность
> стандартная: при увеличении - увеличить размер диска нижнего уровня,
> заполнить добавленную часть мусором, увеличить размер раздела LUKS,
> увеличить размер на следующем уровне. При уменьшении - в обратную
> сторону.
> Нюансы появляются при определении той части диска, которую требуется
> заполнить мусором. Наиболее лёгкий вариант, но плохо подходящий при
> изменении размеров при параллельной штатной работе системы - сначала
> увеличить размер файловой системы, потом создать на ней файл, заполнив
> до конца доступное место, и удалить его. Другие варианты требуют
> расчётов размера раздела LUKS и потенциально опасны.
Где-то так?:
Хотим увеличить на 1Гб LUKS раздел c ФС ext3 на LVM томе "LV1":
# lvextend -L+1G /dev/vg00/LV1
# cryptsetup luksOpen /dev/vg00/LV1 foo
# resize2fs /dev/mapper/foo
# mount -t ext3 /dev/mapper/foo /mnt/mountpoint
$ dd if=/dev/urandom of=/mnt/mountpoin/big.file bs=1M
$ rm -f /mnt/mountpoin/big.file
тут нигде "cryptsetup resize -b" махать не надо?

А если отрезать 1G от такого LUKS раздела - lvextend не повыкидывает 
нужные LE (т.е., LE заполненные шифр-кашей LUKSа видятся для LVM как LE 
с данными?)?

Какая из трёх вышеперечисленных комбинаций на Ваш взгляд наиболее 
сбоеустойчивая?

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

В разделе раздел Mounting and umounting этой статьи: 
http://linuxgazette.net/140/pfeiffer.html некий Рене Файфер предлагает 
варианты скриптов для старта/завершения связки RAID-LUKS-LVM. Насколько 
они актуальны для AltLinux Desktop P5?

[скип]
Огромное спасибо за развёрнутый ответ! По сути вышла почти готовая 
статья на тему сабжа :)


-- 
WBR........[ ]
TFTHAOT....[x]
AMF........[ ]