From: "Nikolay A. Fetisov" <naf@naf.net.ru> To: ALT Linux Community general discussions <community@lists.altlinux.org> Subject: Re: [Comm] RAID, LVM & LUKS Date: Wed, 26 May 2010 12:27:29 +0400 Message-ID: <1274862449.18677.193.camel@v3405.naf.net.ru> (raw) In-Reply-To: <4BF5449C.3060606@ukr.net> В Чтв, 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? В зависимости от требований к системе. Как минимум, имеет смысл задаться вопросом о целях построения такой системы и о том, куда и _как_ будут делаться резервные копии данных. -- С уважением, Николай Фетисов
next prev parent reply other threads:[~2010-05-26 8:27 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-05-20 14:18 Vaso VV 2010-05-25 6:45 ` Vaso VV 2010-05-26 8:27 ` Nikolay A. Fetisov [this message] 2010-05-28 15:37 ` Vaso VV
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1274862449.18677.193.camel@v3405.naf.net.ru \ --to=naf@naf.net.ru \ --cc=community@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Community general discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 community community/ http://lore.altlinux.org/community \ mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com public-inbox-index community Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.community AGPL code for this site: git clone https://public-inbox.org/public-inbox.git