MDADM ( Зеркалирование блочных устройств в рамках локальной системы. )

OS: "Linux Debian 5/6/7 (Lenny/Squeeze/Wheezy)".

Сохранность данных на диске можно повысить за счёт использования второго диска, работающего как зеркало первого. Этот режим называется RAID первого уровня (Redundant Array of Inexpensive Disks - избыточный массив недорогих дисков). Коротко - RAID-1.



Устанавливаем пакет приложений MDADM:


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

Надо понимать, что есть модуль ядра "md", обеспечивающий работу с MD-устройствами, а есть пакет утилит "mdadm", который позволяет управлять и мониторить состояние массива, работающего на модуле "md". В частности, утилиты часто запускаются в фоновом режиме для контроля состояния массивов и уведомления по почте. Кстати, файл "mdadm.conf" предназначен именно для работы этого пакета и не нужен для работы модуля "md".

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

Прежде всего останавливаем автоматически запущенные при инсталляции сервисы:




Следует иметь в виду, что простая правка параметров вышеприведённого конфигурационного файла не окажет ожидаемого влияния на работу всех компонентов подсистемы "mdadm"; у таковой имеется как набор утилит, которые могут читать информацию их этого конфигурационного файла, так и модули ядра, параметры к которым нужно сформировать отдельно. Кроме того, упомянутые модули ядра подсистемы mdadm загружаются ещё и в составе образа "initramfs" (специальным образом подготовленный "Initial RAM Disk" - мини операционная система, загружающая целевую) изменить конфигурацию которой можно только обновив её содержимое путём создания нового образа с учётом произведённых изменений. Применения изменений можно добиться перезапустив конфигурацию пакета и в процессе диалога подтвердить выбранные значения параметров; во время переконфигурирования пакета все необходимые изменения будут применены, так же и обновлением "initramfs":



В качестве последнего шага можно запретить загрузчику операционной системы (в нашем случае GRUB2) инициировать модуль "md" при обнаружении блочных устройств с мета-информацией RAID. Надо понимать, что это не позволит загрузить систему с устройств, объединённых в RAID-массив, но в нашем случае этого и не требуется. Зато, таким образом мы полностью исключим на этапе загрузке операционной системы возможность преждевременной автоматической инициализации наших массивов (и загрузка системы ускоряется за счёт пропуска операций сканирования всех блочных устройств):




После всех вышеприведённых манипуляций можно считать, что мы искоренили автоматическую инициализацию mdadm на всех уровнях загрузки: на уровне GRUB2, на уровне "Initial RAM Disk" и на уровне "init.rc".

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

Если модуль не загрузился, это можно сделать вручную:


Проверяем, загрузились ли нужные нам модули:


Попробуем подготовить HDD (или любые другие блочные устройства) для ввода их в RAID-1.

Проверяем, имеется ли на блочном устройстве "мета-данные":



Если на HDD имеются "мета-данные" от предыдущих экспериментов - затираем их (или делаем это из профилактических соображений):


Даём команду операционной системе перечитать обновлённую разметку HDD:


В команде "dd" выше, в особо злостных случаях, когда на диске предварительно порезвились и по натыкали массу вариантов разметки (вложенные контейнеры, многослойные загрузчики, сжатые файловые системы и тому подобное), параметр "count" можно установить в "1000", что бы перезаписать не один килобайт информации в начале дискового устройства, а мегабайт, например.

Для начала нужно подготовить разделы, которые хочется включить в RAID, присвоив им тип "fd (Linux RAID Autodetect)". Это не обязательно, но желательно. Для создания "программного массива" желательно использовать не весь аппаратный диск целиком, а лишь логические диски (желательно - одинакового объёма, в противном случае размер массива будет рассчитываться исходя из размера диска с минимальным объёмом), понятно, что желательно не растягивать раздел на всё доступное пространство, а оставить пару-пятёрку-десятку секторов свободными на возможность люфта объёма дисков:


Программный RAID в "Linux" ведёт журнал изменений блоков данных "bitmap". Он довольно активно используется и в случае медленного HDD ещё более замедляет его работу. Этот журнал по умолчанию сохраняется внутри самого блочного устройства RAID-а, но (режим "internal"), но можно вынести в файл на отдельный диск (системный в моём случае). Журнал вещь вспомогательная, массив восстанавливается и без "bitmap"-а, но медленнее.

Создаём директорию для выноса в неё журналов MDADM:


Первичную сборку массива осуществим ориентируясь на символические имена дисков, что автоматически создаются в каталоге устройств /dev. После будем ориентироваться на идентификаторы UUID.

Содаём массив из двух дисков:


Как вариант создаём вначале массив для двух дисков из одного диска, с резервированием места для подключения второго впоследствии:


Подключаем диск в массив, на место зарезервированное для него ранее:


Если что не так - массив можно деактивировать:


Наблюдаем за процессом зеркалирования:



Следующим набором команд можно выяснить состояние RAID-массивов и компонентов таковых:


После создания RAID-массивов можно ознакомиться с перечнем всех доступных в системе блочных устройств, как физических, так и виртуальных:


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



В таком случае синхронизацию нужно активизировать и она продолжиться с места остановки:



Переход к настройке автоматизации зеркалирования блочных устройств в рамках локальной системы.