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

АЛЕКСЕЙ БАРАБАНОВ

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

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

Большинство из представленных далее положений и рекомендаций прошли многолетнюю проверку практикой. Но тем не менее не надо все изложенное считать жесткой схемой. Это всего лишь одно из мнений. Воспринимите статью как попытку упорядочить подход и поиск общих путей решения проблемы планирования дисковых ресурсов. И задача эта, ранее в эпоху магнитных дисков типа RK для PDP-11 решаемая всегда очень просто и однозначно, а сейчас – уже с привлечением всего разнообразия современных технологий, далее будет лишь эволюционировать в сложности и многообразии подходов. Поэтому эпитет «современный» в названии надо читать как соответствующий настоящему уровню развития. Выберем для работы универсальный дистрибутив, например, SuSE Linux 10.0 выпуска конца 2005 года, который и примем за эталон современности. Далее рассмотрим, что нам сейчас предлагается и какой сложности выбор предстоит сделать каждому при создании нового сервера.

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

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

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

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

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

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

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

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

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

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

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

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

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

• DISK – физическое дисковое устройство;
• MD – так называемый multiple device или программный RAID;
• LVM – виртуальный диск по технологии Logical Volume Manager;
• DRB/iSCSI – сетевой диск по соответствующей технологии;
• EXT3... – уровень представления, соответствующий файловым системам;
• NFS... – уровень представления, соответствующий сетевым файловым системам и протоколам, используемым для организации сетевого доступа к файлам.

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

• SAS – устройства, физически подключаемые к серверу;
• SAN – блочные устройства, подключаемые по сетевым интерфейсам;
• NAS – файловые системы, доступные через сеть.

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1. Операции и стоимости

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

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

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

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

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

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

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

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

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

Таблица 2. Зависимость скорости доступа от разбиения и типа разметки

Опишем их по порядку:

• sda3 – проверка проводится на «чистом» разделе диска, размеченного под ext3;
• sda3,md3 – файловая система размечена поверх половинки «зеркала» RAID1;
• sda3,md3,lvm – раздел, использованный как половинка RAID1, помещен в LVM, и уже поверх него размечена файловая система ext3;
• sda3,md3,amd64 – случай 2, но в режиме 64 бита;
• sda3,md3,4096 – условия как в предыдущем 64-битном варианте, но с размером тестового файла в 4 Гб;
• sda2,md2 – случай 2, но со смещением к начальным областям диска.

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

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

Испытания с 1-го по 3-е определяют то, как влияет использование дополнительных уровней представления данных на скорость работы. Практически отклонения не превышают 5%. Совершенно понятно, что с увеличением числа «слоев» трансляции уровней представления немного подрастает скорость записи и немного снижается скорость чтения. Это объясняется тем, что при записи большее число программных драйверов создает большую массу кеширующих механизмов, и в сравнении с тестом на файле 4 Гб (колонка 5) видно, как увеличение размера в 2 раза довольно существенно снижает результаты по записи. А вот в процедуре чтения данных увеличение числа уровней представления лишь увеличивает цепочку запросов, если данные не сохранены в кеше, и, значит, немного снижает скорость. Сравнение результатов тестирования, произведенного на другом разделе диска (колонка 6), с аналогичным по условиям (колонка 2) дает основания считать результаты последней достаточно достоверными, так как за небольшим исключением скорости обмена данными схожи. Здесь очень интересно отметить, что переход на 64-битную платформу показывает резкий прирост скорости символьного чтения. Вероятно, из-за более эффективного использования индексов в кеше. Безусловно, увеличение числа прогонов, изменение соотношения размера тестового файла к объему оперативной памяти и другие приемы, возможно, дали бы более стабильные результаты, но, скорее всего, общий уровень показателей не изменился бы существенно. Можно считать, что уровень отклонения не превысит 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

Внутри раздела уже создана файловая система.

# fsck /dev/sda3

По умолчанию использован блок с размером 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

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

# fsck /dev/md3

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

# e2fsck -f /dev/sda3

А вот теперь скорректируем размер самой системы:

# resize2fs /dev/sda3 $(( 2622592 * 4 ))K

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

# e2fsck -f /dev/md3

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

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

# mount /dev/md3 /mnt

# mount | grep md3

Сначала исправим /etc/fstab, так как изменилось имя устройства, использованного для монтирования раздела:

# perl -i.orig -p -e 's,/dev/sda3,/dev/md3,g' /mnt/etc/fstab

# cat /mnt/etc/fstab | grep md3

/dev/md3            /                    ext3       acl,user_xattr        1 1

И для того чтобы инициировать автоматическое детектирование RAID в процессе загрузки системы, поправим тип раздела (для краткости используем неинтерактивную форму):

# fdisk /dev/sda <

Перечитаем таблицы разметки диска:

# partprobe

Если обновленный раздел используется в качестве корневого, то есть его имя передается загрузчиком ядру, то надо поправить меню загрузки. В нашем случае /boot размещен на модифицируемом разделе. Здесь принимается без объяснений то, что следует использовать загрузчик 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 <<EOT

> root (hd0,2)

> setup (hd0)

> quit

> EOT 

grub> root (hd0,2)

grub> quit

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

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