Перенос живой Ubuntu на программный RAID1 в горячем режиме

© Onizuka, “Теория антисистем”, 2016 год

Print PDF

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

Итак, в чём смысл решаемой нами задачи? Мы будем переность полностью рабочую и, более того – продолжающую работать копию на программный RAID1, созданный средствами самой Юбунты. Пара слов о том, почему программный, почему RAID именно первый, и зачем нам это вообще. В целом технология RAID предназначена для решеня задачи повышения надёжности хранения данных, попутно в ряде случаев обеспечивая и некоторый прирост производительности. Углубляться в её дебри мы не будем, для нас существенно то, что в случае с Ubuntu перенос системы вместе с загрузчиком без плясок с бубнами и прочего шаманизма возможен только на RAID1. Что нам даст на практике именно этот стандарт RAID? Он предусматривает многократное дублирование (от двух раз и более) хранимых данных, соотвественно при выходе из строя одного из носителей массива работоспособность сисетмы не будет нарушена, она продолжит работать на т.н. деградированном массиве дисков. В качестве приятного бонуса RAID1 даёт примерно полуторакратный прирост производительности операций чтения с массива – мы будем использовать программный RAID Ubuntu, в алгоритмах которого заложена возможность чтения файлов параллельно с двух физических носителей, особенно это ощутимо при работе с множеством мелких файлов, а именно такие файлы и составляют основную массу наполнения системного раздела Ubuntu. Скорость операций записи на самом деле тоже чуть выше, но незначительно, такой эффект возникает из-за распараллеливания потока на запись между буферами нескольких физических накопителей. Таким образом, в результате мы рассчитываем повысить надёжность нашей системы и немножко поднять её производительность.

Почему же мы выбираем именно программную релизацию RAID? Для начала, перенос работающей системы в горячем режиме на аппаратный RAID (реализуемый средствами аппраратного контроллера) в большинстве случаев попросту невозможен. Контроллеры, реализующие настоящий полноценный аппаратный RAID, массивы котрого прозрачно воспринимаются системой как просто дисковые накопители, по стоимости находятся в том же ценовом диапазоне, что и недорогие материнские платы, но производительность их ограничена пропускной способностью шины (PCI или PCI-E x1 для наиболее массовых моделей), в итоге мы попросту не получим ожидаемого прироста производительности, если будем использовать SSD в качестве дисков массива. Программно-аппратный, или FakeRAID (псевдо-RAID), наличие которого гордо декларируют производители практически всех материнских плат, а также дешёвых контроллеров расширения SATA-IDE имеет для нас смысл в одном единственном случае – если перед нами стоит задача сделать доступным наш RAID-массив для другой системы (обычно это Windows). На физическом уровне контроллер FakeRAID всего лишь декларирует включение режима RAID для соответствующих накопителей, а все операции с ними обеспечиваются уже драйверами системы, то есть по сути это тоже программный RAID, но с тормозами, вызванными необходимостью обращения к “мозгам” контроллера по любому поводу. Существенной проблемой для FakeRAID и чисто аппаратного RAID является то обстоятельство, что перенос собранного дискового массива на другой контроллер (в случае, если сдохнет контроллер или материнка) физически невозможен в большинстве случаев, а это обесценивает саму идею хранения избыточных данных для повышения надёжности. Реализация программного RAID в Ubuntu в плане производительности практически не проигрывает FakeRAID материнской платы, точно так же дополнительно нагружая своими операциями центральный процессор, однако мы имеем возможность при необходимости перенести массив дисков с нашей системой на любое другое железо.

Что мы будем для этого делать? Мы создадим программными средствами деградированный массив RAID1, перенесём на него нашу систему, не прерывая её работы, а затем перезагрузимся уже с деградированного массива, и восстановим его до рабочего, система при этом уже будеть работать как обычно. Для начала нам понадобится установить пакет mdadm:

Во многих публикациях рекомендуют проверить подгрузку соответствующих модулей ядра, но Ubuntu в последние годы делает это сама, автоматически. Далее, нам понадобится место для как минимум одного раздела на другом дисковом накопителе (технически возможно собрать RAID на двух разделах одного физического накопителя, но это очень, очень плохая идея ). Нам надо создать пустой раздел (для простоты пусть это бует /dev/sdb1 в дополнение к нашему системному, с которого мы сейчас грузимся, допустим это /dev/sda1 – конкретно ваши разделы могут быть, понятное дело, другими). При создании раздела необходимо, чтобы его размер в блоках был чуть меньше (на практике достаточно разницы в тысячу блоков), чем у исходного системного – иначе нам не удастся затем подцепить старый системный раздел в деградированный массив. Практический опыт показывает, что все ухищрения создать полностью идентичный второй раздел обречены – из-за разницы в геометрии и особенностях конкретных накопителей даже прямое копирование раздела не даёт желаемого результата (даже на накопителях одной модели и из одной партии некие технические особенности и изменения состояния могут привести к созданию физически неидентичных разделов). В принципе наш новый раздел может быть отформатирован в любую файловую систему, но по практике лучше, если он будет неотформатированным. Создать его можно консольной утилитой fdisk, редактором с графической оболочкой gparted или штатным системным приложением. Очень часто в статьях встречается рекомендация изменить тип раздела на fd (0xfd), однако для нашего случая она скорее вредна, чем полезна – для mdadm это несущественно, а для всего остального программного обеспечения такой тип надо обязательно устанавливать только для массивов типа RAID0 (и его производных, например RAID01, RAID10 и пр.), RAID3 и им подобных, предполагающих “размазывание” файловой системы на несколько физических разделов. Нам же стандартный тип файловой системы наших разделов позволит при необходимости обратиться к ним при помощи другого софта, даже если наш массив RAID по каким-то причинам рассыплется. Итак, у нас есть новый раздел, и мы создаём с его участием деградированный массив:

Здесь мы указываем, что создаём массив уровня RAID1 из двух дисков, один из которых “missing”, т.е. массив на момент создания у нас будет деградированным. Собственно, если мы не собираемся прицеплять потом к массиву наш старый системный раздел и у нас есть лишние диски, мы можем сразу создавать массив на двух дисках, недеградированным – все последующие манипуляции будут почти аналогичными, с поправкой на отсутствие необходимости подцеплять старый раздел. Параметр –metadata=0.90 нужен нам для того, чтобы потом у нас не возникло проблем с загрузчиком grub. В принципе, если его не указать, то современные версии mdadm сами предупреждают о возможных проблемах при загрузке с массива. В случае успешного старта массива команда

покажет нам параметры созданного массива. Их нам надо поместить в конфигурационный файл mdadm (если они ещё не попали туда автоматически) любым текстовым редактором, например:

При этом очень часто встречается рекомендация помещать в файл прямиком вывод команды mdadm – возможно раньше так оно и было, но сейчас формат этого файла несколько отличается: в секции “definitions of existing MD arrays” после параметра metadata (в нашем случае metadata=0.90) должен следовать параметр UUID, а не name. Есть такой вариант автоматической генерации конфига:

После этого всего мы можем отформатировать наш новый массив:

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

Дальше нам надо скопировать на него корень нашей файловой системы, для корректного завершения этого процесса желательно снизить активность до минимума – позакрывать все лишние приложения, остановить сервисы, какие можно, и т.п.. Затем выполняем копирование:

Более продвинутый вариант той же команды:

Но этот вариант предпочтительнее для отмонтированного рута. После успешного завершения копирования надо отредактировать fstab на массиве:

прописав в него UUID нашего массива вместо прежнего корневого раздела. Почему здесь надо использовать именно UUID, а не имя массива (/dev/md0)? Дело в том, что в дальнейшем при перезагрузке имена массивов могут неоднократно перестроиться, и в результате наш корень не смотнируется, если мы укажем для него именно имя массива. В параметрах монтирования целесообразно указать дополнительно discard,noatime,nodiratime, если мы используем SSD – это продлит их здоровье. Теперь мы можем подмонтировать системные каталоги и перейти в новый корень на массиве:

Это нам нужно для того, чтобы корректно поставить загрузчик на этот накопитель:

или даже

Для команды grub-install надо указать имя того физического накопителя, на котором разместился наш деградированный массив. Кроме того, нам нужно разрешить загрузку с нашего массива, “потерявшего” один диск, для этого запускаем

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

и поптыаться загрузиться с того физического накопителя, на котором мы конфигурировали RAID. Если нам не удалось разрешить загрузку системы с деградированного массива, при последующей перезагрузке возможен вылет в оболочку initramfs, в большинстве случаев загрузка после этого может нормально продолжиться, если выйти из неё по команде exit.

Загрузившись в первый раз с массива нам надо удостовериться, что в корень подмонтировался именно наш массив (не забываем, что символьное имя у него могло при этом поменяться). Если всё в порядке, и система работает нормально, то можно подцепить старый системный раздел в наш массив вторым диском. Для этого превращаем его в “неформатированный” и подаём команду

где вместо sda1 подставляем имя нашего бывшего системного раздела, а вместо md0 может понадобиться вписать реальное имя массива после перезагрузки. Если всё сделано правильно, то раздел присоединится к массиву и начнётся его перестроение из деградированного в рабочий, за которыми можно наблюдать при помощи команды

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

На этом до версий 14 процесс и заканчивался, система сама подхватывала собранный массив, однако в более поздних версиях необходимо дополнительно пересобрать initram:

после чего снова обновить grub:

в противном случае система при каждой перезагрузке будет терять второй диск массива. Что удивительно – на других видах RAID-массивов этой проблемы не возникает.

Одной из нестандартных схем использования программного RAID1 является ускорение работы системы за счет подключения к массиву более быстрого накопителя. Дело в том, что mdadm поддерживает принудительное назначение приоритетности чтения с определённого физического диска внутри массива. Так можно подключить к уже имеющемуся массиву (заметим, не размонтируя его) более скоростной накопитель (SSD для HDD, NVMe для SSD), который будет выполнять фактически функции кеширующего устройства, и одновременно обеспечивать дополнительное резервирование данных. Допустим, наш массив md0 из sda1 и sdb1, а мы подключили более быстрый накопитель sdc1. Добавляем его в массив:

Первая команда добавит в массив новый физический диск, но он будет в статусе резервного (spare – флаг “S” в статусе), вторая включит его в массив, увеличив размерность массива до 3 дисков, после чего надо будет дождаться завершения переноса данных на новый диск. Затем надо поочерёдно снизить приоритетность чтения со старых разделов:

Первая команда отключает диск от массива, вторая удаляет из массива, третья – вновь подключает обратно, но уже в статусе “ведомого” – этот диск будет использоваться преимущественно для записи, тогда как для чтения будут использоваться остальные диски. Потом ту же манипуляцию надо проделать со вторым физическим диском, после этого в статусе mdadm у них появится флаг “W”. Ключ –write-mostly перед именем конкретного физического диска можно использовать и непосредственно при создании массива, но в этом случае ранее надо было соблюдать условие, чтобы в любой момент времени в массиве был бы хотя бы один накопитель без этого флага, то есть приоритетный на чтение. Фактическая скорость такого массива будет в итоге ниже, чем у самого быстрого (кеширующего) из дисков, но всё равно ощутимо выше, чем без такого кеширования (при использовании NVMe на PCI-E 2.0 например средняя скорость чтения будет 1.4 Гб/с против 1.6 Гб/с на диске вне массива).

После всего этого надо обязательно обновить initramfs и grub, иначе система с высокой вероятностью не загрузится. Если нас выкинуло при перезагрузке в оболочку initramfs, можно попытаться исправить ситуацию:

Этими командами мы останавливаем массив, затем пересобираем его автоматически, если на автомате массив не собирается, его можно попытаться собрать принудительно вручную:

После загрузки надо опять обновить initramfs. Эти же манипуляции можно использовать и для изменения имени массива, (например, останавливаем md0 и собираем с теми же дисками под именем md01), но в этом случае надо будет снова сгенерировать или исправить руками конфиг mdadm.