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

Метки: , ,
FavoriteLoadingПометить для себя
Перенос живой Ubuntu на программный RAID1 в горячем режиме
5 (100%) 4 голосов

ClassicMenu-indicator-Ubuntu-13.04-425x360© Onizuka, “Теория антисистем”, 2016 год Скачать в формате электронной книги

О переносе 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-массивов этой проблемы не возникает.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

0
(Просмотров: 638)
Категории Линуксоводство, метки , , . Постоянная ссылка.

Новое

15.10.2019 - Стрейс Я.Я. Три путешествия ... 12.10.2019 - Grundmann H. Religious Movements in the Middle Ages ... 11.10.2019 - Сулимов С.И., Черниговских И.В., Черенков Р.А. Антисистемность и терроризм: проблема взаимосвязи ... 09.10.2019 - Алексанян А.Г. Процесс инкультурации манихейства в Китае ... 05.10.2019 - Карелия в годы Первой мировой войны ... 04.10.2019 - Деконская Н.В. Ландшафтный археологический музей-заповедник как форма сохранения и презентации историко-культурного наследия (на примере проекта музеефикации территории Охтинского мыса) ... 02.10.2019 - Суфизм в контексте мусульманской культуры ... 30.09.2019 - Исследования гуманитарных систем. Выпуск 2. Доминантность систем и её виды. ... 28.09.2019 - Ради жизни на земле… Русская мечта против Антисистем. «Изборский клуб» №7(53), 2017 год ... 27.09.2019 - “Суслик” ... 26.09.2019 - Будницкий О.В. Российские евреи между красными и белыми ... 25.09.2019 - Ермоленко А. Понятие антисистемы в исследовании результатов социально-экономических преобразований ... 24.09.2019 - Hardin G. The Tragedy of the Commons ... 22.09.2019 - Histoire de la croisade contre les hérétiques albigeois ... 21.09.2019 - Ушницкий В.В. Центральноазиатское и северное манихейство ... 20.09.2019 - Шишкин И.С. «Малый народ»: элитная антисистема ... 18.09.2019 - Landscape Archaeology between Art and Science ... 17.09.2019 - Современные нецке ... 17.09.2019 - Пыпинъ А.Н. Русское масонство. XVIII и первая четверть XIX в. ... 16.09.2019 - Смирнов В. Симптомы. Продолжение. ... на главную

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *