From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DNS_FROM_OPENWHOIS,SPF_PASS autolearn=no version=3.2.5 From: "Nikolay A. Fetisov" To: ALT Linux Community general discussions In-Reply-To: <4BF5449C.3060606@ukr.net> References: <4BF5449C.3060606@ukr.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 May 2010 12:27:29 +0400 Message-ID: <1274862449.18677.193.camel@v3405.naf.net.ru> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 (2.30.1.2-alt2) Content-Transfer-Encoding: 8bit Subject: Re: [Comm] RAID, LVM & LUKS X-BeenThere: community@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Community general discussions List-Id: ALT Linux Community general discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 08:27:40 -0000 Archived-At: List-Archive: List-Post: В Чтв, 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? В зависимости от требований к системе. Как минимум, имеет смысл задаться вопросом о целях построения такой системы и о том, куда и _как_ будут делаться резервные копии данных. -- С уважением, Николай Фетисов