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

n  sda3 – проверка проводится на «чистом» разделе диска, размеченного под ext3;

n  sda3,md3 – файловая система размечена поверх половинки «зеркала» RAID1;

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

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

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

n  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, то при такой трансформации данные никак не должны пострадать. Проверим это.