Книги, научные публикации

1 Modern Linux - storage resource planing Москва январь 2006 Алексей Барабанов.

Современный Linux-сервер: планирование дисковых ресурсов.

От того, насколько правильно будет учтен и cпрогнозирован рост данных, размещенных на создаваемом сервере, зависит в самом прямом смысле срок жизни самого сервера!

Но можно не заниматься математическим предсказанием увеличения объема информации в сети, а использовать технологии хранения, допускающие оперативное масштабирование и резервирование.

Введение.

Большинство из представленных далее положений и рекомендаций прошли многолетнюю проверку практикой. Но, тем не менее, не надо все изложенное считать жесткой схемой.

Это всего лишь одно из мнений. Статью надо воспринимать как попытку упорядочения подхода и поиска общих путей решения проблемы планирования дисковых ресурсов. И задача эта, ранее в эпоху магнитных дисков типа RK для PDP-11 решаемая всегда очень просто и однозначно, а сейчас - уже с привлечением всего разнообразия современных технологий, далее будет лишь эволюционировать в сложности и многообразии подходов.

Поэтому эпитет современный в названии надо читать, как соответствующий настоящему уровню развития. Выберем для работы универсальный дистрибутив, например, SuSE Linux 10.0 выпуска конца 2005 года, который и примем за эталон современности. Далее рассмотрим, что нам сейчас предлагается и какой сложности выбор предстоит сделать каждому при создании нового сервера.

Постановка задачи.

Прежде всего, зададимся вопросом, в чем цель действий, производимых в процессе разметки дисковых устройств. Нужны ли вообще все эти страдания молодого Вертера, если каждый дистрибутив, и SuSE в том числе, предлагает в процессе установки выполнить автоматическое разбиение? Как определить критерии оценки правильности решения о типе и способе обустройства дисковых ресурсов сервера? Определим нашу цель так: правильным будет такой способ, который в дальнейшем цикле эксплуатации сервера позволит без привлечения избыточных ресурсов провести как комплекс работ по повышению отказоустойчивости, по увеличению емкости, так и, наконец, провести модернизацию операционной системы или миграцию сервера на иное оборудование. Это, так сказать, программа максимум. Совсем не обязательно, что все это предстоит. В моей практике много таких серверов, которые работают до полного износа оборудования (более 5 лет) без каких-либо модернизаций. Но целью выбора оптимальной структуры дисковой системы поставим именно удовлетворение перечисленных критериев. Прокомментируем их.

Во-первых, что такое цикл эксплуатации сервера. Будем считать таковым срок от введения сервера в строй до демонтажа его, или до модернизации (upgrade) операционной системы или аппаратного обеспечения. Первое понятно, второе обоснуем. Поскольку все, что далее описывается, относится к области профессиональной деятельности, то всякая работа имеет денежный эквивалент, и экономия средств принимается одним из главных критериев 2 Modern Linux - storage resource planing любой профессиональной деятельности. Так и здесь. Модернизация производится не из-за вдруг возникшей тяги системного администратора к новизне, а потому что в старой версии или на старом оборудовании сервер далее работать не может. То есть несоответствие стало столь существенным, что решено потратить средства на модернизацию. Ну а если так, то существенные изменения позволяют считать сервер после модернизации уже другим и соответственно этому начать отсчет нового цикла, тем более что и операционная система и оборудование сервера сами по себе имеют жизненный цикл, который нецелесообразно превышать.

Во-вторых, зачем нужно увеличение отказоустойчивости? Почему при вводе сервера в строй это не считали необходимым, а вот со временем вдруг озаботились? Будем считать, что с увеличением срока эксплуатации возрастает объем внутренних данных сервера и тем самым увеличивается его информационная и абсолютная ценность.

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

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

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

Резюмируем вышесказанное. Во всех технологических выборах следует предпочитать те способы и методы, которые снизят стоимость дальнейших преобразований и модификаций.

Вот такой получается восточный дракон, кусающий собственный хвост.

Теперь, когда цель ясна и определена, обсудим сами устройства хранения и те технологии, что предлагаются на выбор лиз коробки при сегодняшнем уровне развития в SuSE Linux 10.0.

Иерархия уровней представления дисковых данных.

Современный Linux-сервер является многофункциональным устройством, работающим в сети. Если абстрагироваться от его прикладного назначения и попытаться представить весь спектр возможных уровней и способов доступа к данным, то получится большая схема, напоминающая многослойный пирог. Иерархию сетевого доступа к данным тоже принято изображать в виде многоуровневой схемы инкапсуляции. Только если сетевая модель уже давно канонизирована, то схема вложенности уровней доступа к дисковым данным не 3 Modern Linux - storage resource planing имеет привычного вида, что допускает вольности в ее представлении. Итак, если все доступные в SuSE Linux 10.0 технологии попытаться уложить в единую схему, отражающую их взаимосвязь и взаимодействие, то получится нечто вроде изображенного на рисунке 1.

Рисунок 1. Схема иерархии уровней представления дисковых данных.

Прокомментируем эту схему. Хотя все аббревиатуры и обозначения являются традиционными в Linux, расшифруем их: DISK - физическое дисковое устройство;

MD - так называемый multiple device или программный RAID;

LVM - виртуальный диск по технологии Logical Volume Manager;

DRB/iSCSI - сетевой диск по соответствующей технологии;

EXT3... - уровень представления, соответствующий файловым системам;

NFS... - уровень представления, соответствующий сетевым файловым системам и протоколам, используемым для организации сетевого доступа к файлам. Каждый окрашенный прямоугольник отделяет регион, включающий технологии соответствующей категории. Их три: SAS - устройства, физически подключаемые к серверу;

SAN - блочные устройства, подключаемые по сетевым интерфейсам;

NAS - файловые системы, доступные через сеть. Все перечисленные на схеме технологии могут быть задействованы в пределах одного серверного блока или, точнее, одного хоста. Безусловно, необходимость их использования должна диктоваться областью применения. И вот здесь для нашего обсуждения будет важно то, какую гибкость в настройке и модернизации обеспечивают все изображенные элементы. Для этого рассмотрим подробнее ту же схему, но с точки зрения операций и их взаимодействия по пути эскалации технологических уровней.

4 Modern Linux - storage resource planing Будем далее исходить из предположения, что все используемые технологии применяются к одному физическому дисковому устройству. Это не исключает в дальнейшем использования дополнительных дисков, но задает более жесткие рамки вариантов выбора.

Например, под MD в дальнейшем будет пониматься исключительно RAID1.

Диаграммы переходов.

Для того чтобы определить ключевые, или, в нашей терминологии, дорогостоящие технологические элементы, построим диаграмму переходов в процессе возможных настроек от самого нижнего уровня DISK до самого верхнего NFS... Полученная диаграмма представлена на рисунке 2.

Рисунок 2. Диаграмма настроек.

Узлы соответствуют технологическим уровням представления данных, а стрелки обозначают возможные направления в процессе настройки сервера. Нумерация узлов проставлена в порядке самого длинного маршрута настроек. Все очевидно и не нуждается в пояснениях. А вот теперь повернем стрелки в обратном направлении! Представим, что некий шаг настройки оказался ошибочным, но решение о его отмене пришло лишь в процессе эксплуатации, спустя некоторое время. Например, в процессе установки были последовательно пройдены этапы 1 DISK, 5 EXT3..., 6 NFS.... И, спустя некоторое время, 5 Modern Linux - storage resource planing появилась необходимость перевести работающую систему под LVM. То есть надо последовательно перевести сервер по диаграмме настроек 6 NFS..., 5 EXT3... и затем в узел 3 LVM. После чего снова в поступательном движении по диаграмме настроек вернуться в узел 6 NFS..., который соответствует полностью работоспособному серверу. Вторую диаграмму назовем диаграммой переделок. В ней все вектора изменили направление на противоположное, и рядом с каждым из них добавился комментарий, оценивающий стоимость переделки. Результат изображен на рисунке 3.

Рисунок 3. Диаграмма переделок.

Итак, все возможные стоимости переделок уложились в четыре градации: потеря сервиса, отключение сервиса, условно возможно, потеря данных. Например, рассмотрим возможные переделки для узла файловых систем EXT3... Во-первых, можно переразметить диск, на котором размещена файловая система - это условно возможная операция, так как на диске должно оставаться свободное место для таких манипуляций. Во-вторых, можно перевести используемый диск в статус RAID1 - это условно возможная операция, так как в случае наличия свободного места в файловой системе для размещения суперблока операцию можно провести на лету. В-третьих, можно перевести файловую систему под управление LVM - эта операция проводится с потерей данных, так как LVM использует размещение суперблоков в теле рабочих разделов так, что не представляется возможным выделить для этого единое пространство. Ну и, наконец, можно отключить от используемой файловой 6 Modern Linux - storage resource planing системы сетевое блочное устройство - эта операция приводит только к отключению самого сервиса и ни к чему более серьезному.

Таким образом, самая серьезная ситуация складывается вокруг переделок, требующих установки LVM. Если подключение RAID или переразметка диска могут быть проведены без резервного копирования всех данных в некоторых случаях, то помещение томов с данными под управление LVM потребует 100% сохранения всей задействованной информации. Здесь можно сделать вывод, что именно LVM является той критической технологией, решение об использовании которой надо принимать на самом раннем этапе планирования дисковых ресурсов.

Таблица операций.

Попробуем поместить все данные из диаграмм в таблицу (Таблица 1.). Слева в столбце 1 - исходное состояние, сверху в ряду 1 - конечное, в ячейке на пересечении соответствующих состояний указана операция, переводящая начальное состояние в конечное. Таким образом, в ячейки левой нижней части таблицы, разделенной диагональю, попадут операции переделок и их стоимости, а в ячейки правой верхней части попадут операции настроек.

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

Если исходить из условия, что необходимо обеспечить масштабирование емкостей в оперативном порядке, то выбор однозначен. Поскольку в предыдущем разделе уже был сделан вывод о том, что технология LVM единственная, которая требует решения о ее применении на самом раннем этапе, то можно сказать, выбор сделан - LVM непременно надо использовать.

Далее, у нас два кандидата для возможного увеличения отказоустойчивости путем горячего резервирования. Безусловно, сравнивать RAID и сетевые блочные устройства просто некорректно. Но в рамках рассматриваемой модели мы не учитываем ничего, кроме возможности перенастроить нужный уровень представления данных и последствий такой перенастройки. И следуя этому принципу, получается, что создание сетевого блочного устройства на основе локального - это лишь запуск соответствующего сервиса, а переключение локально подмонтированного диска на сетевой режим работы без изменения его объема или размещения тоже не представляет особой проблемы. Итак, из двух технологических подходов, MD и DRB/iSCSI, будем самым неудобным в модификации, и поэтому самым дорогим, считать MD.

1 2 3 4 5 6 1 DISK MD LVM DRB/iSCSI EXT3... NFS...

2 DISK Разбиение диска Создание MD и Создание LVM и Запуск drbd/ iscsid Разметка fs и подключение подключение монтирование 3 MD Условно возможна Создание LVM и Запуск drbd/ iscsid Разметка fs и миграция MD на подключение монтирование иной раздел диска 4 LVM Условно возможна Условно возможно Запуск drbd/ iscsid Разметка fs и миграция PV перемещение PV монтирование внутрь MD 5 DRB/iSCSI Условно возможна Условно возможно Невозможно без Разметка fs и миграция раздела перемещение полного резервного монтирование DRB/iSCSI раздела внутрь MD копирования 7 Modern Linux - storage resource planing 1 2 3 4 5 6 6 EXT3... Условно возможна Условно возможно Невозможно без Отключение от Запуск nfsd/ smbd миграция FS перемещение FS полного резервного сетевого блочного внутрь MD копирования устройства 7 NFS... Отключение всех потребителей и остановка сервиса Таблица 1. Операции и стоимости.

На этом этапе можно сформулировать первые принципы планирования дисковых ресурсов.

Принцип 1. Следует, по возможности, переключить все размеченные разделы жесткого диска в режим работы программного RAID, пусть и неполного, что позволит в дальнейшем при необходимости перевести их в режим горячего резервирования.

Принцип 2. Следует, по возможности, объединить все созданные физические тома под управлением LVM - для того, чтобы в дальнейшем, при необходимости, легко манипулировать объемом используемых логических томов.

Обращаю внимание на уточнение по возможности. Обсуждение этих возможностей, а также все, что касается стратегии разбиения на разделы, оставим для второй части этой статьи. Сейчас просто учтем эту оговорку и просто попытаемся оценить эффект от следования заявленным выводам, как принципам планирования дисковых ресурсов.

Тестирование.

Да, именно так - тестирование. Нет ничего проще, чем оценить издержки использования этих, запасенных впрок, технологических изысков MD и LVM, путем проверки с помощью самого рядового теста файловой системы bonnie, проверяющего символьные и блочные операции чтения-записи, как повлияет на его результаты внесение соответствующих изменений в настройки.

В тестовом компьютере было установлено 1Гбайт оперативной памяти. Это не очень лудобный объем, так как максимальный размер тестового файла в 32-битном режиме составляет 2Гб, что несколько снижает точность измерений. И поэтому дополнительно были сделаны проверки в 64-битном режиме и с размером тестового файла в 4Гбайта.

Полученные результаты представлены в таблице 2. В самом левом столбце перечислены операции, на которых проводились измерения, а в самой верхней строке сокращениями обозначены условия тестирования. Опишем их по порядку:

1) sda3 - проверка проводится на чистом разделе диска, размеченного под ext3;

2) sda3,md3 - файловая система размечена поверх половинки зеркала RAID1;

3) sda3,md3,lvm - раздел, использованный как половинка RAID1, помещен в LVM, и уже поверх него размечена файловая система ext3;

4) sda3,md3,amd64 - случай 2, но в режиме 64 бита;

5) sda3,md3,4096 - условия как в предыдущем 64-битном варианте, но с размером тестового файла в 4Гбайта;

6) sda2,md2 - случай 2, но со смещением к начальным областям диска.

Результаты тестов показаны в Кбайт в секунду. Рядом с ними рассчитаны индексы отклонений от средней величины, определенной по первым трем испытаниям. Для 8 Modern Linux - storage resource planing наглядности данные таблицы представлены в графическом виде в форме столбчатой диаграммы (Рисунок 4).

sda3 sda3,md3 sda3,md3,lvm sda3,md3,amd64 sda3,md3,4096 sda2,md 1 2 3 4 5 Символьная запись 1 43891 - 0,96 46049 - 1,01 47326 - 1,03 44301 - 0,97 41087 - 0,90 48253 - 1, Блочная запись 2 55173 - 0,94 60449 - 1,03 60397 - 1,03 55792 - 0,95 49368 - 0,84 54367 - 0, Перезапись 3 21288 - 0,99 21768 - 1,01 21618 - 1,00 20570 - 0,95 20688 - 0,96 21839 - 1, Символьное чтение 4 24281 - 1,07 21815 - 0,96 21791 - 0,96 30829 - 1,36 36220 - 1,60 21732 - 0, Блочное чтение 5 54047 - 1,01 53622 - 1,00 53288 - 0,99 51793 - 0,97 51768 - 0,96 54335 - 1. Таблица 2. Зависимость скорости доступа от разбиения и типа разметки.

Рисунок 4. Зависимость скорости доступа от разбиения и типа разметки.

Испытания с 1-го по 3-е определяют то, как влияет использование дополнительных уровней представления данных на скорость работы. Практически, отклонения не превышают 5%. Совершенно понятно, что с увеличением числа слоев трансляции уровней представления немного подрастает скорость записи и немного снижается скорость чтения. Это объясняется тем, что при записи большее число программных драйверов создает большую массу кеширующих механизмов, и в сравнении с тестом на файле Гбайта (колонка 5) видно, как увеличение размера в 2 раза довольно существенно снижает результаты по записи. А вот в процедуре чтения данных увеличение числа уровней представления лишь увеличивает цепочку запросов, если данные не сохранены в кеше, и, значит, немного снижает скорость. Сравнение результатов тестирования, произведенного на другом разделе диска (колонка 6), с аналогичным по условиям (колонка 2) дает основания считать результаты последней достаточно достоверными, так как за небольшим исключением скорости обмена данными схожи. Здесь очень интересно отметить, что переход на 64-битную платформу показывает резкий прирост скорости символьного чтения. Вероятно, из-за более эффективного использования индексов в кеше. Безусловно, 9 Modern Linux - storage resource planing увеличение числа прогонов, изменение соотношения размера тестового файла к объему оперативной памяти и другие приемы, возможно, дали бы более стабильные результаты, но, скорее всего, общий уровень показателей не изменился бы существенно. Можно считать, что уровень отклонения не превысит 5% и в реальной работе. Поскольку, как видно по результатам, выигрыш в записи сопровождается потерями в чтении, то никакого существенного ухудшения работы системы такой тюнинг не принесет в общем случае.

Как подтверждение правильности сделанных здесь выводов приведем тот факт, что RHEL (серверная версия Red Hat Linux) по умолчанию устанавливает все данные, кроме размещаемых в каталоге /boot, именно в раздел под управлением LVM. Даже swap помещается на раздел LVM для того, чтобы можно было в дальнейшем манипулировать его объемом. Иначе говоря, преимущества технологичности сопровождения создаваемого сервера с лихвой окупают трудноуловимые жертвы производительности.

Теперь, уверившись в правильности предложенных выше принципов, попробуем применить их на практике.

Практический рецепт миграции на RAID1.

Внимание! Используйте описанную ниже технологию на свой страх и риск. Автор не несет ответственности за возможные повреждения данных и настоятельно рекомендует выполнить процедуру резервного сохранения критически важной информации. Далее все описано применительно к SuSE 10.0. Не забудьте сделать поправку под актуальную платформу.

Как было ранее заявлено, надо стремиться к переводу разделов под RAID и LVM с самого раннего этапа. При этом вовсе не обязательно, чтобы в системе было необходимое количество дисков для построения RAID или присутствовала сложная иерархия устройств, управляемая LVM. Вовсе нет! Все должно быть применимо даже к единственному жесткому диску. В отношении LVM проблем нет даже если диск один. А вот RAID1, технологически работающий даже на одном диске, в процессе инсталляции системы с использованием стандартных установщиков не удается так просто включить в работу. Для исправления этой проблемы применяются схемы с миграцией готовой системы с обычных разделов на второе дисковое устройство, как на половинку зеркала. То есть возникает та самая аппаратная избыточность, которой мы стремились избежать. Но можно воспользоваться тем, что суперблок MD записывается в конец используемого раздела, и с точки зрения файловой системы структура раздела более не меняется. Таким образом, если на этапе установки разместить систему на некотором разделе, а потом уменьшить объем файловой системы так, чтобы в полученном хвостике уместился бы суперблок RAID1, то при такой трансформации данные никак не должны пострадать. Проверим это.

В работе используем раздел /dev/sda3, размеченный как ext3, но можно использовать любую файловую систему, допускающую изменение размера. Все манипуляции надо производить над немонтированным разделом. Если трансформируется корневой раздел, то надо использовать или спасательный диск, или альтернативную загрузку. Итак, вот разметка диска до начала работ:

# fdisk -l /dev/sda Disk /dev/sda: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes 10 Modern Linux - storage resource planing Device Boot Start End Blocks Id System /dev/sda1 1 131 1052226 82 Linux swap / Solaris /dev/sda2 132 1377 10008495 fd Linux raid autodetect /dev/sda3 * 1378 2683 10490445 83 Linux Внутри раздела уже создана файловая система.

# fsck /dev/sda fsck 1.38 (30-Jun-2005) e2fsck 1.38 (30-Jun-2005) /dev/sda3: clean, 117054/1311552 files, 720522/2622611 blocks По умолчанию использован блок с размером 4Кбайт. Уточнить действительный размер можно с помощью утилиты dumpe2fs с ключом Цh. Теперь есть возможность сразу рассчитать размер и положение суперблока MD, как указано в usr/include/linux/raid/md_p.h и уменьшить размер файловой системы соответственно. После подстановки в формулу для расчета переведем все числа, указанные в блоках, в шестнадцатеричные:

Размер устройства MD = = (размер физического устройства & ~ (размер суперблока -1) - размер суперблока = = 2622611 & ~(15) -16 = = 0x280493 & ~(0xF) - 0x10 = = 0x280480 = 2622592 блоков Полученное значение составит размер полученного диска MD. Начиная с указанного блока будет размещаться суперблок MD длиной 64Кбайта. Но можно пойти по самому примитивному пути и заставить систему сообщить нужный размер, как мы и сделаем далее.

Создадим RAID1 из раздела /dev/sda3. На предупреждение о том, что внутри уже найдена размеченная файловая система, не обращаем внимания - мы же знаем, что делаем!

# mdadm -C /dev/md3 -l 1 -n 2 /dev/sda3 missing mdadm: /dev/sda3 appears to contain an ext2fs file system size=10490444K mtime=Mon Jan 9 01:08:28 Continue creating array? y mdadm: array /dev/md3 started.

Теперь проверим целостность файловой системы внутри полученного MD. Утилита должна указать на несоответствие размера раздела и размера файловой системы, после чего проверку следует прервать:

# fsck /dev/md fsck 1.38 (30-Jun-2005) e2fsck 1.38 (30-Jun-2005) The filesystem size (according to the superblock) is 2622611 blocks The physical size of the device is 2622592 blocks Either the superblock or the partition table is likely to be corrupt!

Abort? yes fsck.ext3 /dev/md3 failed (status 0x8). Run manually!

Полученный из сообщения физический размер в 2622592 блока по 4Кбайта, который, кстати сказать, совпадает с заранее рассчитанным, нужно будет использовать при коррекции размера файловой системы. Но предварительно выполним проверку файловой системы на /dev/sda3, так как иначе утилита resize2fs откажется работать.

11 Modern Linux - storage resource planing # e2fsck -f /dev/sda e2fsck 1.38 (30-Jun-2005) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda3: 117054/1311552 files (0.5% non-contiguous), 720522/2622611 blocks А вот теперь скорректируем размер самой системы:

# resize2fs /dev/sda3 $(( 2622592 * 4 ))K resize2fs 1.38 (30-Jun-2005) Resizing the filesystem on /dev/sda3 to 2622592 (4k) blocks.

The filesystem on /dev/sda3 is now 2622592 blocks long.

Для контроля снова проверим целостность файловой системы на /dev/md3:

# e2fsck -f /dev/md e2fsck 1.38 (30-Jun-2005) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/md3: 117054/1311552 files (0.5% non-contiguous), 720522/2622592 blocks Если эта система была корневой и/или использовалась в процессе загрузки, то надо внести дополнительные правки в содержимое файлов, управляющих загрузкой системы.

Монтируем новый раздел:

# mount /dev/md3 /mnt # mount | grep md /dev/md3 on /mnt type ext3 (rw) Сначала исправим /etc/fstab, так как изменилось имя устройства, использованного для монтирования раздела:

# perl -i.orig -p -e 's,/dev/sda3,/dev/md3,g' /mnt/etc/fstab # cat /mnt/etc/fstab | grep md /dev/md3 / ext3 acl,user_xattr 1 И для того чтобы инициировать автоматическое детектирование RAID в процессе загрузки системы поправим тип раздела (для краткости используем неинтерактивную форму):

# fdisk /dev/sda

# partprobe Если обновленный раздел используется в качестве корневого, то есть его имя передается загрузчиком ядру, то надо поправить меню загрузки. В нашем случае /boot размещен на модифицируемом разделе. Здесь принимается без объяснений то, что следует использовать 12 Modern Linux - storage resource planing загрузчик grub. Обоснование этого, а также и многих других правил, оставим для второй части статьи. Итак, проводим такую же правку, как и с /etc/fstab :

# perl -i.orig -p -e 's,/dev/sda3,/dev/md3,g' /boot/grub/menu.lst Теперь все готово к работе. Надо только не забыть, что initrd должен понимать тип нового раздела. И если это не так, то следует пересобрать initrd, указав в /etc/sysconfig/kernel среди имен модулей в параметре INITRD_MODULES дополнительно raid1. Напоследок, если возникают трудности с загрузкой, то продемонстрируем протокол установки загрузчика из модифицированного раздела.

# grub root (hd0,2) > setup (hd0) > quit > EOT GNU GRUB version 0.96 (640K lower / 3072K upper memory)...

grub> root (hd0,2) Filesystem type is ext2fs, partition type 0xfd grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded...succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,2)/boot/grub/stage /boot/grub/menu.lst"... succeeded Done.

grub> quit Таким образом, была осуществлена трансформация на лету. Условием ее успешного выполнения стало то, что в файловой системе было свободно не менее 2622611-2622592 = 19 блоков или 76Кбайт. Для повторения этого трюка в другом Linux, не в SuSE, или с другим типом файловой системы надо обеспечить наличие необходимых для трансформации файловой системы утилит.

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

   Книги, научные публикации