Установка debian на raid

В этой статье описывается конфигурирование программного RAID массива с помощью мастера установки и настройки Debian на примере RAID 10.

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

В следующем окне раздела разметки выбираем диск sda

Соглашаемся создать пустую таблицу разделов

И также делаем с остальными дисками — sdb, sdc и sdd

На выходе должно быть так:

Теперь переходим в пункт Настройка программного RAID и соглашаемся сохранить изменения и настроить RAID

Выбираем тип устройства программного RAID: RAID10

число активных разделов — 4

число резервных разделов — 0

Ставим звёздочки всех четырёх активных диска для массива и продолжаем

В действиях по настройке выбираем Закончить

Теперь на выходе должно быть так:

Также можно создавать разметку на дисках — как вручную, так и автоматическую. В данном примере выберем автоматическую. Выбираем метод: Авто — использовать весь диск

Диск для разметки — RAID10 устройство #0

Далее в Схеме разметки выберем Все файлы в одном разделе

Теперь закончим разметку и сохраним изменения

Соглашаемся записать изменения на диск

Устанавливаем системный загрузчик GRUB

выберем для него диск — sda (устройство /dev/sda)

Теперь он установится

После всех проделанных действий перезагружаем машину и проверяем:

# cat /proc/mdstat

Система покажет активные диски массива RAID10

UUUU в квадратных скобках обозначает, что все диски в онлайне и работают нормально.

В этой статье рассказывается о том, как сконфигурировать программный RAID массив с помощью мастера установки и настройки Ubuntu Server на примере RAID 1 (зеркало).

Во время установки системы в разделе Guided storage configuration необходимо выбрать пункт Custom storage layout

Попадаем в раздел Storage configuration. Здесь у нас отображаются 2 наших жёстких диска

Жмём на первый и выбираем пункт Use As Boot Device

Также жмём на второй и выбираем пункт Add As Another Boot Device

Теперь в пункте USED DEVICES у нас отображаются оба жёстких диска с разделом bios_grub — 1MB

Затем снова жмём на первый и выбираем пункт Add GPT Partition

Создаём раздел диска 256M для /boot, но оставим его неформатированным

Затем также создадим ещё 2 раздела для swap и корня — 1GB и оставшееся место на диске, и тоже оставим их неформатированными

Эти же действия проделаем и со вторым диском

Теперь переходим в пункт Create software RAID (md) и здесь настроим MD диск md0. В устройствах выберем partition 2 на обоих жёстких дисках, и режим у них должен быть active.

Таким же образом создадим диск md1 для partition 3 и md2 для partition 4 и на выходе получим связанные разделы software RAID 1

Далее жмём на md0 (new) и выбираем пункт Add GPT Partition

выбираем формат ext4 и Mount /boot

Таким же образом сделаем для md1 (new) с форматом swap и md2 (new) с форматом ext4 и Mount / (корень).

Таким образом мы объединили разделы жётских дисков в массив RAID 1 (зеркало)

Затем жмём Готово

и подтверждаем изменения, нажав Продолжить

После этого продолжаем установку системы как обычно.

Когда установка системы завершится и машина перезагрузится, запустим команду:

Консоль покажет, что массив работает в активном состоянии.

Программный RAID в Linux на основе MD-устройств успел отлично зарекомендовать себя в работе и пользуется заслуженной популярностью у администраторов, сочетая надежность и простоту создания и управления. Но со все более широким распространением UEFI-систем приходится сталкиваться с некоторыми особенностями. Многие, если есть такая возможность, переключают настройки в режим совместимости, но это неправильно, UEFI — это стандарт для современных устройств и поэтому надо учиться работе с ним.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

Конфигурация разделов Linux с UEFI

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

EFI — он же ESP (EFI system partition) — специальный раздел с файловой системой FAT который содержит загрузчик, вызываемый микропрограммой UEFI, должен находиться в основной таблице разделов и не может располагаться в программных RAID-массивах, томах LVM или пулах ZFS. Данный раздел должен располагаться на каждом диске, с которого предусматривается загрузка.

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

Swap — раздел подкачки, используется как механизм виртуальной памяти, а также для организации режима сна (в настольных системах). Некоторые современные системы не используют раздел подкачки (Ubuntu) используя для этой цели специальный файл в корневом разделе. Swap можно объединить в программный RAID, но смысла в этом немного, более того, при использовании отдельных swap-разделов системе будет доступен вдвое больший объем для подкачки.

Некоторые особенности Ubuntu Server 18

Начиная с версии 18.04 Ubuntu Server по умолчанию предлагается с новым инсталлятором Subiquity, который очень просто отличить по обновленному внешнему виду:

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

Также легко можно отличить дистрибутивы по наименованию, образ с Subiquity содержит в наименовании слово live (ubuntu-18.04.3-live-server-amd64.iso).

Создание программного RAID при установке системы

Все дальнейшие действия мы будем производить на системе Debian 10, однако все сказанное будет справедливо для любой основанной на Debian системе, а с некоторыми поправками и для любого дистрибутива Linux.

Прежде всего создадим в начале каждого диска системный раздел EFI размером в 499 МБ (по умолчанию Debian и Ubuntu используют близкие к этому размеры разделов).

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

В итоге каждый диск содержит три раздела: ESP, будущие разделы Linux RAID и разделы подкачки. Порядок следования разделов и размер разделов для RAID должны быть одинаковы на обоих дисках. После того, как первоначальная разметка выполнена соберем программный RAID 1 из разделов для данных, в нашем случае sda2 и sdb2:

Теперь разметим созданный массив, создав там корневой раздел. Помните, что один программный массив Linux (md-устройство) может содержать только один раздел, если вам нужно несколько разделов, то потребуется создать несколько массивов.

Далее продолжаем установку в обычном режиме, программный RAID-массив создан, а к загрузчику мы вернемся после завершения этого процесса.

Настройка загрузчика EFI и его копирование на второй раздел

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

lsblk -o +uuid

В полученном выводе прежде всего обратим внимание на идентификаторы EFI-разделов.

Они разные, в то время как UUID RAID-разделов совпадают. Чтобы понять, что это означает и какие может иметь последствия откроем /etc/fstab:

Как видим, разделы монтируются по идентификаторам и в случае выхода из строя первого диска вы не сможете загрузиться со второго, так как система не сможет смонтировать EFI-раздел. В некоторых источниках советуют изменить строку монтирования, используя вместо UUID явное указание устройства, например, /dev/sda1. Да, если мы отключим первый диск, то второй превратится в sda и система загрузится, но если диск выйдет из строя, физически определяясь в системе или на его месте будет новый диск без разметки, то такой фокус не сработает.

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

Для работы с разделами FAT32 нам потребуется установить дополнительные утилиты:

apt install dosfstools

После чего выполним:

mkdosfs -i 2396BE56 /dev/sdb1

Где 2396BE56 — идентификатор первого EFI-раздела (/dev/sda1), его следует указывать в одну строку без пробелов и тире, а /dev/sdb1 — второй EFI раздел.

Теперь получим список текущих загрузочных записей EFI:

Здесь нас интересует запись под номером 5 — debian, которая отвечает за загрузку системы и указывает на первый жесткий диск. Запомните или запишите путь к EFI-образу для загрузки системы: EFIdebianshimx64.efi.

Создадим аналогичную запись для второго диска:

efibootmgr -c -d /dev/sdb -p 1 -L «debian 2» -l «EFIdebianshimx64.efi»

Немного поясним назначение ключей команды:

Так как наш EFI-раздел располагается в /dev/sdb1, то в опциях -d и -p указываем /dev/sdb и 1 соответственно, а в качестве пути указываем данные из первой загрузочной записи, которые мы получили на предыдущем шаге. Обратите внимание, что при указании пути к образу EFI используется обратный слеш.

Еще раз убедимся, что запись выполнена правильно:

Обе строки должны отличаться только меткой и GUID раздела (уникальный GPT-идентификатор, который позволяет микропрограмме UEFI найти нужный раздел).

Если обнаружена ошибка, то запись следует удалить и создать заново, для удаления используйте команду:

efibootmgr -b 6 -B

Ключ -b (—bootnum) указывает на номер записи, а -B (—delete-bootnum) предписывает удалить ее.

Последним шагом скопируем содержимое загрузочного раздела с первого диска на второй, для этого смонтируем второй EFI-раздел:

mount /dev/sdb1 /mnt

И скопируем на него содержимое первого EFI-раздела:

cp -R /boot/efi/EFI/ /mnt

После чего отмонтируем раздел:

На этом настройка завершена, система теперь может быть успешно загружена с любого диска.

В одной далёкой-далёкой галактике появился один очень-очень странный проект, под который было приобретено не менее странное оборудование, которое разные странные люди почему-то называли сервером. И вот, в один из заснеженных августовских дней, попал этот сервер модели HP/HPE ProLiant DL20 Gen10 ко мне с постановкой задачи, согласно которой на сервер нужно установить ОС Debian Linux и некоторое прикладное ПО.

Имея некоторый опыт работы с RAID-контроллерами HPE Smart Array, я предположил, что задача будет решена без каких-либо затруднений. Однако, когда я добрался до инвентаризации комплектации полученной «железяки», меня ждал сюрприз. Оказалась, что сервер в своей поставке имеет два дисковых накопителя SATA HDD и, вместо аппаратного RAID-контроллера, оснащён базовой опцией программного RAID — HPE Smart Array S100i SR Gen10 SW RAID.

Если заглянем в спецификацию QuickSpecs по данной модели сервера, то увидим некоторые замечания относительно опции программного RAID:

Пройдя по последней ссылке, мы можем найти документ, описывающий набор костылей от HPE под названием LSRRB (Linux Software RAID — Redundant Boot), адаптированный под системы Red Hat Enterprise Linux 7.3 и SuSE Linux Enterprise Server 12.2. В нашем же случае на сервер необходимо установить ОС Debian 10 (Buster) GNU/Linux и это несколько меняет набор необходимых действий.

В качестве решения по защите данных на сервере в случае отказа одного из дисков мы воспользуемся возможностями программной реализации RAID в Linux — mdraid. При этом программные RAID-массивы RAID-1 мы будем делать не из дисков в целом, а из отдельных, заранее созданных, дисковых разделов, а загрузочные разделы EFI System Partition (ESP) будут незеркалируемыми.

Раздел ESP в нашем случае незеркалируемый, так как загрузка EFI работает только с физическими устройствами на начальном этапе включения сервера, когда управляющий код Linux ещё не загружен и не инициализированы программные RAID-массивы. Хотя следует признать, что способы размещения раздела ESP на зеркалируемом разделе существуют, однако выглядят они больше, как экстремальное развлечение с учётом костылей, которыми всё это обставляется, а также с учётом разных страшных историй про потерянные супеблоки.

По условиям нашей задачи, сервер с установленной Debian Linux должен содержать 3 раздела:

Если с необходимостью зеркалирования корневого раздела с ОС Linux и рабочим ПО всё понятно, то относительно раздела подкачки Swap есть мнения, что включение в RAID этого раздела лишено смысла. Однако, если не зеркалировать этот раздел, то может получиться так, что процессы, использующие swap на диске, который внезапно выйдет из строя, могут упасть, что, само по себе, при неудачном стечении обстоятельств может привести к порче каких-либо данных. Чтобы этого не допускать, мы настроим отдельный RAID-1 для раздела подкачки.

Далее, в рамках нашей задачи, мы по порядку рассмотрим следующие процедуры:

Подготовка аппаратной платформы сервера

Работу с любым сервером начинаем с доведения микрокода аппаратных компонент сервера до актуальных версий.

Для серверов на базе платформы HPE ProLiant G10 имеется загружаемый ISO-образ с комплектом обновлений микрокода и драйверов — Service Pack for ProLiant (SPP). Актуальную версию пакета можно найти по ссылке: Gen10 Service Pack for ProLiant (SPP) Version 2020.03.0.

С помощью утилиты HPE USB Key Utility for Windows 3.0.0.0 (12 Jul 2017) мы можем подготовить загрузочный USB-накопитель, на который будет записано содержимое пакета SPP.

Загружаем сервер с подготовленного USB-накопителя и запускаем сессию обновления микрокода для всех поддерживаемых устройств сервера.

Утилита Smart Update Manager проведёт загрузку метаданных о всех доступных обновлениях микрокода, входящих в текущую версию пакета SPP, сопоставит их с аппаратной частью сервера и проведёт обновление.

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

После перезапуска сервера извлекаем загрузочный USB-накопитель с SPP и, на этапе инициализации аппаратной платформы, нажимаем F9, чтобы попасть в главное меню «System Utilities».

Меняем в опции «Embedded SATA Configuration» режим «Smart Array SW RAID Support» на режим «SATA AHCI Support».

Клавишей F10 сохраняем сделанные изменения и выходим из RBSU.

Обратите внимание на то, что сделать данное переключение режима работы SATА контроллера обязательно до того, как начинать какие-либо дальнейшие действия с дисками и установкой Linux. А после того, как ОС будет установлена и в Linux будет собран программный RAID, изменять настройки режима SATA крайне не рекомендуется, поэтому лучше сразу ограничить доступ к настройкам RBSU от любителей «крутить всякие крутилки».

Подготовка дисков сервера к установке Debian Linux на программный RAID

Нужную нам разметку диска с созданием всех необходимых разделов можно выполнить непосредственно в процессе установки ОС даже в графическом инсталляторе Debian Buster. Однако мои практические эксперименты с использованием такого варианта разметки показали то, что он не лишён своих недостатков и не даёт нужной гибкости, которую мы имеем в случае предварительной разметки диска в режиме загрузки с Debian Live CD.

При выборе дистрибутива Debian Linux следует помнить, что в стандартный дистрибутив этой ОС не включены никакие проприетарные драйверы и файлы поддержки микрокода. А учитывая то, что в нашем случае используется сервер HPE, где могут быть устройства, требующие проприетарного кода, нам лучше сразу скачивать загрузочный образ дистрибутива Debian, укомплектованный «non free» драйверами, а также имеющий режим загрузки Debian Live. Текущая версия такого образа для 64-разрядных систем доступна по ссылке: Debian Live (amd64, non-free)

Здесь мы можем увидеть множество Live-дистрибутивов, собранных с поддержкой разных графических сред исполнения, таких как Gnome, KDE и т.п. Так как в рамках нашей задачи графическая среда не требуется, а все операции по управлению разделами будут проводится утилитами командной строки, то и загружать можно самый простой стандартный дистрибутив вида debian-live-10.-amd64-standard+nonfree.iso.

В ходе загрузки Live-система автоматически получит адрес с DHCP и сконфигурирует сетевой адаптер для работы с локальной сетью.

В дальнейшем нам потребуется до-установить в Live-систему некоторые пакеты из online-репозиториев Debian. Эти дополнительные пакеты пригодятся нам для работы с разделами дисков. Поэтому на время у сервера должен быть прямой доступ в Интернет.

Дождёмся окончания загрузки Debian Live и появления приглашения командной строки. Первой командой повысим себе привилегии до уровня супер-пользователя (root):

$ sudo su —

Теперь с помощью пакетного менеджера apt обновляем информацию о пакетной базе и до-устанавливаем утилиты, которые нам потребуются для работы

# apt-get update
# apt-get install mdadm gdisk dosfstools -y

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

Получим информацию о блочных устройствах, доступных нашей Linux системе:

Как видим, система обнаружила и обозначила два наших физических SATA диска, как и .

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

# sfdisk —delete /dev/sda
# sfdisk —delete /dev/sdb

Выполним создание нужных нам разделов на первом физическом диске командой вида:

В нашем случае, для трёх нужных нам разделов (250MB под ESP, 4GB по Swap, остальное пространство под корневую ФС Linux) на первом диске (), выполняются команды:

# sgdisk -n 1:0:+250M -t 1:ef00 -c 1:»EFI System» /dev/sda
# sgdisk -n 2:0:+4G -t 2:fd00 -c 2:»Linux RAID» /dev/sda
# sgdisk -n 3:0:0 -t 3:fd00 -c 3:»Linux RAID» /dev/sda

Здесь в ключе -t указывается тип раздела, который в общем случае «ef00» для EFI и «fd00» для разделов, которые будут являться участниками Linux RAID.

В рассматриваемом примере для дальнейшего создания RAID разделов будет использоваться два физических диска идентичного размера. Однако Linux RAID можно собирать и из физических дисков разного объёма, при условии, что раздел RAID не будет превышать ёмкости наименьшего физического диска. И если изначально диски, которые мы собираемся использовать, имеют разный объём, то в качестве первого диска при создании разделов, нужно использовать диск меньшего объёма. Это важно по той простой причине, что конфигурацию созданных разделов первого физического диска на следующем шаге мы будем копировать на второй диск.

Клонируем таблицу разделов (ключ -R) с первого диска () на второй диск () с регенерацией идентификаторов разделов (в контексте GPT) на втором диске (ключ -G):

# sgdisk /dev/sda -R /dev/sdb -G

Давайте посмотрим, что у нас получилось:

# fdisk -l

Создаём RAID-разделы (устройства и ) уровня RAID1 из пар идентичных разделов с разных физических дисков:

# mdadm —create /dev/md0 —bitmap=internal —level=1 —raid-disks=2 /dev/sda2 /dev/sdb2
# mdadm —create /dev/md1 —bitmap=internal —level=1 —raid-disks=2 /dev/sda3 /dev/sdb3

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

Дожидаемся, когда процесс синхронизации разделов в RAID дойдёт до 100%.

Чтобы в реальном режиме времени наблюдать за процессом, можно выполнить команду вида:

# watch cat /proc/mdstat

После того, как RAID-устройства и окончили синхронизацию, проверим их статус:

# mdadm —detail /dev/md0
# mdadm —detail /dev/md1

RAID-разделы подготовлены и теперь можно переходить к процессу установки ОС Debian.

В процессе установки загрузчик EFI будет записан на первый раздел (тот, что размером 250MB) на первом диске (). Раздел подкачки будет создан на первом зеркалируемом разделе (программном RAID-устройстве ), а раздел с ОС Linux будет размещён на втором зеркалируемом разделе ()

Отправляем сервер в перезагрузку, чтобы завершить сеанс работы в режиме Debian Live

Установка Debian 10 (Buster) GNU/Linux

Загружаем сервер с установочного накопителя Debian Buster. В качестве установщика можем использовать всё тот же USB-накопитель с Debian Live, только при запуске в начальном меню Grub нужно выбрать режим установки ОС, например, «Graphical Debian Installer».

В графическом инсталляторе Debian пройдём несколько стандартных этапов. На этапе «Select a language» выберем в качестве языка, используемого для процесса установки, «English».

На этапе «Configure locales» в качестве основной локализации системы сервера выбираем «en_US. UTF-8».

На этапе «Configure the keyboard» выбираем текущую раскладку клавиатуры, например, «Russian» и сочетание клавиш для переключения между языками.

На этапе «Configure the network» инсталлятор проверит все доступные сетевые интерфейсы и попытается выполнить авто-конфигурацию настроек IP, получив данные с DHCP-сервера. В нашем примере, перед установкой ОС сервер уже был переключен в изолированный VLAN, где DHCP не работает и требуется ручная настройка сети. Выберем интерфейс, который будет использоваться в качестве основного интерфейса сервера и перейдём к его ручной настройке «Configure network manually».

Затем укажем имя сервера, и имя основного доменного суффикса, если требуется.

После окончания установки ОС вместо стандартного механизма разрешения имён рекомендуется настроить службу DNS-клиента systemd-resolved, так как она имеет встроенный механизм кеширования разрешаемых в DNS имён, что само по себе благотворно влияет на DNS-серверы с точки зрения снижения нагрузки.

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

На этапе «Configure the clock» нам будет предложено выбрать текущий часовой пояс для настройки системы.

В Debian Linux клиент NTP в конфигурации по умолчанию будет пытаться достучаться до NTP-серверов в Интернете. При наличии в сети предприятия локальных NTP-серверов после окончания установки ОС рекомендуется настроить службу синхронизации времени systemd-timesyncd.

Теперь мы подошли к самому интересному этапу разметки дисков «Partition disks». В перечне доступных методов разметки выбираем режим ручной разметки «Manual».

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

Убедимся в том, что инсталлятор пометил этот раздел как наиболее подходящий под «EFI System Partition» с включенным флагом загрузки «Bootable flag» в «on». То есть, фактически, в нашем случае можно здесь ничего не менять. Завершаем работу с разделом, выбрав внизу экрана пункт «Done settings up the partition».

Вернувшись обратно в область разметки дисков, выберем первый и единственный 4GB раздел на RAID-устройстве и перейдём к его настройке.

В окне настроек раздела в поле «Use as» будет определено значение «do not use». С помощью клавиши «Enter» или «Space» щелкнем по этому значению и из предопределённого списка выберем тип раздела «swap area», то есть определим данный зеркалируемый раздел под раздел подкачки Linux.

Завершим настройку раздела и вернёмся в область разметки дисков, где следующим шагом выберем первый и единственный раздел на RAID-устройстве .

Откроется окно настроек раздела, в котором в поле «Use as» изменим назначение раздела под журналируемую файловую систему Ext4 – «Ext4 journaling file system». В качестве точки монтирования в файловой системе Linux, связанной с этим разделом («Mount point»), выберем «/ — the root file system» и сохраним настройки через «Done settings up the partition».

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

Выбираем пункт записи настроек на диски «Finish partitioning and write changes to disk».

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

Сразу после этого начнётся процесс установки ОС на RAID-раздел, выбранный нами в качестве точки монтирования корневой ФС («/»).

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

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

После перезагрузки сервера система должна успешно загрузиться с помощью ESP раздела, который был создан на первом диске. E FI-загрузчик в ESP, в свою очередь, должен успешно запустить ОС Linux c программного RAID-раздела.

Войдём в систему с именем пользователя и паролем, которые были нами указаны в процессе установки ОС. Для проверки наличия прав администратора у нашего пользователя, выполним команду повышения привилегий до уровня root-пользователя с помощью «sudo»:

Подключим стандартные репозитории Debian Buster, как это описано в заметке «Как подключить стандартные репозитории Debian 10 Buster» и произведём обновление пакетной базы Linux:

# nano /etc/apt/sources.list
# apt-get update
# apt-get upgrade -y

Установим и запустим сервер SSH для более удобной удалённой работы с сервером:

# apt-get install openssh-server -y
# systemctl enable ssh
# systemctl start ssh

Установим другие утилиты, которые нам пригодятся для дальнейшей работы:

# apt-get install gdisk parted tree -y

На этом установку и первичную базовую настройку Debian Buster в нашем случае можно считать законченными.

Послеустановочная настройка загрузчика UEFI

Итак, система установлена и успешно запускается с раздела ESP () на первом диске (). Однако аналогичный раздел на втором диске в данный момент пуст и с точки зрения текущих системных настроек не имеет никакого отношения к процессу загрузки операционной системы Linux.

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

# lsblk -o NAME,TYPE,SIZE,FSUSED,FSUSE%,MOUNTPOINT,UUID

Как видим, точка монтирования с EFI-загрузчиком (каталог файловой системы ) расположена на разделе первого диска и имеет около 5MB контента, в то время как раздел не используется. Здесь же обратим внимание на то, что идентификаторы UUID разделов, являющихся участниками программного RAID на обоих дисках совпадают, а UUID EFI-разделов ( и ) различаются.

Теперь давайте посмотрим на конфигурационный файл , в котором описаны правила монтирования дисковых разделов:

# cat /etc/fstab

В этом файле мы увидим то, что в нашем случае каталог с файлами загрузчика EFI монтируется с FAT-раздела c UUID равным «», который соответствует идентификатору раздела только первого физического диска.

Кроме того, если проверить текущий порядок загрузки устройств EFI Boot manager, то мы увидим, что в нём фигурирует только запись о нашем первом физическом диске и этот диск установлен в качестве текущего источника загрузки. В этой записи есть ссылка на загрузочный файл (), расположенный на первом разделе этого диска.

# efibootmgr -v
# blkid

Идентификатор раздела, указанный в записи EFI Boot manager, это ни что иное, как PARTUUID раздела в контексте GPT, и очевидно, что в нашем случае здесь речь идёт только про раздел .

Исходя из того, что мы видим, загрузка операционной системы будет работать только в случае, если работоспособен первый физический диск. Если же первый диск выйдет из строя, то сервер не загрузится с ESP-раздела второго физического диска. Чтобы это исправить, нам нужно сделать несколько вещей:

Чтобы решить сразу первые две задачи, мы воспользуемся посекторным копированием всего содержимого раздела в раздел (Внимание! Все прежние данные на разделе-получаете будут уничтожены):

# dd if=/dev/sda1 of=/dev/sdb1

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

# mount /dev/sdb1 /mnt
# tree /mnt -h
# tree /boot/efi -h

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

# lsblk -o NAME,TYPE,SIZE,FSUSED,FSUSE%,MOUNTPOINT,UUID
# blkid /dev/sda1
# blkid /dev/sdb1

После окончания проверки не забудем отмонтировать раздел из каталога :

# umount /mnt

Теперь осталось только отредактировать перечень устройств загрузки EFI Boot manager таким образом, чтобы там была запись не только о первом физическом диске с загрузочным ESP-разделом, но и запись о втором физическом диске с загрузочным ESP-разделом .

Для начала ещё раз проверим под каким сейчас номером запись о первом диске:

Видим, что запись о первом диске на данный момент имеет номер «» и в списке порядка загрузки BootOrder этот номер стоит на первом месте. Чтобы в нашей таблице EFI Boot manager всё выглядело культурно, удалим текущую запись «» и добавим две новые записи со схожими описаниями. При этом, если мы хотим, чтобы приоритетным диском для загрузки был первый диск, то лучше сначала добавить запись о втором диске, а затем о первом, так как в приоритет загрузки BootOrder по умолчанию первой попадает именно та запись, которая была добавлена в таблицу последней:

# efibootmgr —delete-bootnum -b 000F
# efibootmgr —create -d /dev/sdb -p 1 -L «Debian Linux EFI Partition 2» -l «EFIdebianshimx64.efi»
# efibootmgr —create -d /dev/sda -p 1 -L «Debian Linux EFI Partition 1» -l «EFIdebianshimx64.efi»
# efibootmgr -v

Как видно в нашем случае, запись о загрузочном разделе первого диска теперь имеет номер «», а запись второго диска «». При этом EFI Boot manager будет сначала пытаться выполнять загрузку с первого диска, а затем со второго.

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

Проверка обработки отказа дисков в RAID

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

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

После этого войдём в систему, убедимся в её штатной работе и проверим как изменилось состояние программных RAID-разделов:

Как видим, состояние RAID-устройств изменилось на «degraded», но система при этом продолжает работать.

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

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

После успешной загрузки системы снова проверим текущий статус разделов.

# cat /proc/mdstat
# lsblk -o NAME,TYPE,SIZE,FSUSED,FSUSE%,MOUNTPOINT,UUID

Обратите внимание на то, что теперь именование дисков и разделов изменилось. Диск, ранее считавшийся в системе, как с разделами // теперь определён в системе, как с соответствующими разделами.

Далее, установим ранее извлечённый диск в дисковую корзину сервера и выполним его перезагрузку. После успешной загрузки сервера убедимся в том, что программные RAID-разделы вернулись в штатное состояние со статусом «clean».

# mdadm —detail /dev/md*

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

# mdadm —add /dev/md1 /dev/sdb3

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

Таким образом, мы убедились в том, что отказ любого из дисков не приведёт к отказу работы системы или к невозможности последующей загрузки сервера с EFI-загрузчика.

Замена неисправного диска в RAID

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

Далее рассмотрим пример всех этих действий последовательно.

После «горячей» установки нового чистого диска, теоретически можно заставить увидеть систему новый диск путём принудительного сканирования шины командами типа:

Однако в моём случае с сервером ProLiant DL20 у меня подобный приём не сработал и, чтобы Linux-система нормально увидела новый диск, пришлось отправлять сервер в перезагрузку.

Посмотрим текущую ситуацию по блочным устройствам в системе:

Как видим, теперь система видит новый пустой диск , и этот диск не имеет разделов и никак не связан с ранее настроенными RAID-устройствами и .

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

# sgdisk /dev/sdb -R /dev/sda

Помимо этого, выполним регенерацию PARTUUID разделов на новом диске (чтобы они не совпадали с PARTUUID разделов диска-источника):

# sgdisk /dev/sda -G
# partprobe

Теперь нам нужно добавить пустой раздел в RAID-массив в качестве зеркала для работающего сейчас раздела , а пустой раздел добавить в RAID-массив в качестве зеркала для работающего сейчас раздела :

# mdadm —add /dev/md0 /dev/sda2
# mdadm —add /dev/md1 /dev/sda3

После добавления разделов в RAID-массивы, автоматически запустится процесс восстановления этих массивов. Проверим статус выполнения:

После окончания процесс восстановления, убедимся в том, что текущий статус RAID-устройств – «clean»:

Теперь посекторно копируем все содержимое загрузочного раздела ESP c рабочего диска на новый диск :

# dd if=/dev/sdb1 of=/dev/sda1

Напомню, что в результате мы должны получить идентичные ESP-разделы с одинаковым идентификатором раздела UUID.

Ну и наконец, переходим к последнему этапу — правке таблице загрузочных устройств в EFI Boot manager.

Давайте посмотрим, какая в нём сейчас информация:

Как видим, в нашем случае здесь присутствуют две записи, которые мы делал ранее. Теоретически, по условиям нашей задачи, сейчас мне нужно было бы исправить лишь одну из записей, так как мы меняли только один из дисков. Однако, пока я экспериментировал с утилитой gdisk, как-то умудрился обновить идентификаторы PARTUUID разделов ESP ( и ) на обоих дисках.

Текущие идентификаторы разделов PARTUUID можно посмотреть командами типа:

# blkid
# ls -l /dev/disk/by-partuuid/

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

Удаляем в обратном порядке старые записи (в нашем случае это записи «» и «») и сразу добавляем новые записи:

# efibootmgr —delete-bootnum -b 0010
# efibootmgr —delete-bootnum -b 000F
# efibootmgr —create -d /dev/sdb -p 1 -L «Debian Linux EFI Partition 2» -l «EFIdebianshimx64.efi»
# efibootmgr —create -d /dev/sda -p 1 -L «Debian Linux EFI Partition 1» -l «EFIdebianshimx64.efi»
# efibootmgr -v

Теперь в перечне устройств загрузки EFI Boot manager фигурируют правильные идентификаторы разделов GPT, которые используются в сервере после замены неисправного диска, и можно выполнить проверочную перезагрузку системы.

На этом процедуру полной замены неисправного диска можно считать законченной.

Мониторинг программного RAID в Linux

После запуска в работу программного RAID в Linux, нельзя обойти вниманием такой важный вопрос, как постоянный контроль состояния программных RAID-массивов. Сервер крайне желательно подключить к какой-либо системе мониторинга с поддержкой mdraid. Например, для свободно распространяемой системы мониторинга Icinga, существуют всевозможные плагины для мониторинга Linux-систем. Настройку одного из таких плагинов мы рассматривали ранее в статье Вики: Мониторинг Linux Software RAID (mdraid) в Icinga с плагином check_raid

Если же под руками нет развёрнутой и функционирующей системы мониторинга подобного класса, то можно воспользоваться встроенным механизмом оповещений mdraid, который предоставляет служба «mdmonitor». Для минимальной настройки этой службы достаточно изменить email-адрес получателя () и указать адрес отправителя () для оповещений об изменениях в состояниях программного RAID в конфигурационном файле :

# nano /etc/mdadm/mdadm.conf

После этого следует перезапустить службу «mdmonitor» и проверить её состояние:

# systemctl restart mdmonitor.service
# systemctl status mdmonitor.service

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

# update-initramfs -u

Однако следует учесть то, что заданная для службы «mdmonitor» отсылка оповещений по электронной почте будет работать лишь в том случае, если Debian Linux настроен на пересылку почты за пределы сервера (пересылка на smarthost). Пример такой настройки описан в статье Вики «Как настроить отсылку уведомлений на внешний почтовый сервер с помощью msmtp в Debian 10 (Buster)».

Для проверки отсылки уведомлений можно воспользоваться командой:

# mdadm —monitor —scan —test —oneshot

В результате по каждому из устройств mdraid мы должны получить по отдельному письму, в котором будет присутствовать результат вывода команды «».

А чтобы убедиться в том, что оповещения отработают в случае возникновения проблемной ситуации, например, в случае отказа диска, можем ещё раз для проверки выдернуть из дисковой корзины сервера один из дисков. Буквально через пару минут мы должны получить от сервера письмо, сообщающее о проблеме:

На этом базовую настройку мониторинга состояния программных RAID массивов mdraid можно считать законченной.