Настройка Software RAID (mdadm) для серверов

Почему настройка Software RAID (mdadm) на серверах идёт не по плану

Настройка mdadm часто заканчивается там, где массив уже собрался и отвечает на запросы. Формально программный RAID на сервере есть: утилита показывает статус clean, разделы читаются, данные на месте. Но у массива нет горячего резерва, конфигурация не закреплена в файле, который читается при загрузке, а состав устройств после перезагрузки никто не сверял.

Первый software raid сбой проявляется не сразу. Деградация массива идёт тихо: один диск выпадает из зеркала, ядро фиксирует событие, но mdadm не переведён в режим оповещений — сообщение просто некому доставить, и о потере диска узнают через месяцы. Заодно выясняется, что плановая проверка носителей ни разу не запускалась: журнал пуст, а на втором диске давно растут нечитаемые сектора.

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

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

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

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

Второй эффект — время восстановления массива. С настроенным горячим резервом пересборка стартует автоматически, без ожидания инженера и ручного выбора замены; окно сокращается с нескольких часов до десятков минут, и всё это время сервис отдаёт запросы.

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

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

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

Варианты организации дискового массива: сравнение подходов

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

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

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

Как проходит внедрение: аудит, схема, сборка, проверка

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

1. Аудит конфигурации сервера и инвентаризация накопителей. Смотрим модели и ресурс дисков, разбиение, файловые системы, что уже собрано в массивы, какие разделы участвуют в загрузке, какая нагрузка на ввод-вывод и есть ли свободные отсеки под замену без остановки.
2. Проектирование схемы массива. Выбираем уровень избыточности и размер полосы под реальный профиль чтения-записи, число рабочих дисков и резервных, размечаем служебные и загрузочные разделы так, чтобы система поднималась даже с выпавшим накопителем.
3. Сборка mdadm. Создаём массив, размечаем и монтируем по идентификаторам, а не по именам устройств, прописываем зависимости в загрузчик и образ начальной загрузки, чтобы порядок определившихся дисков ничего не ломал.
4. Проверка восстановления. Намеренно выводим накопитель, смотрим, как проходит пересборка и сколько она занимает, ведёт ли себя сервис предсказуемо в это время и возвращается ли резерв в строй автоматически.
5. Мониторинг и обслуживание. Настраиваем оповещения о деградации массива, ведём журнал событий, ставим в расписание плановую проверку чётности — тогда расхождение блоков ловится до отказа, а не на восстановлении.
6. Передача регламентов. Отдаём документацию по схеме, процедуру замены накопителя по шагам, матрицу «что делать при деградации» и порядок проверки после любых изменений.

Конфигурации, схемы массива и регламенты обслуживания

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

• Файл конфигурации массива: состав дисков, уровень избыточности, размер блока и привязка к идентификаторам накопителей, а не к именам устройств. После перезагрузки массив собирается сам, независимо от порядка определения дисков.
• Карта подключения накопителей: контроллер, слот, серийный номер и роль каждого диска, отдельно отмечены слоты под горячую замену. Инженер вынимает нужный накопитель, не задев соседний массив.
• Регламент замены диска: что проверить до извлечения, как ввести новый накопитель в массив, на какие состояния смотреть при пересборке и когда операция считается закрытой.
• Политики доступа: кому разрешены операции с массивом, как ограничены права, куда пишется журнал команд. Случайное исключение диска перестаёт быть необратимым.
• Порядок плановых проверок: опрос состояния накопителей и массива по расписанию, сверка контрольных сумм, пороги, при которых инженер вмешивается до отказа.
• Инструкция по восстановлению: сценарии деградации и полной потери массива, порядок сборки на новом сервере, точки, где данные теряются безвозвратно.
• Документация по серверу: связь массива с разделами, точками монтирования и загрузкой, что меняется при расширении.

Комплект живёт вместе с сервером в репозитории конфигураций: следующая замена диска идёт по документу, а не по памяти.

Практика: сборка массива и восстановление после деградации

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

Что изменили

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

Результат в цифрах

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

mdadm или аппаратный контроллер: что выбрать для сервера

Короткий ответ: выбор определяется не скоростью, а тем, насколько вы готовы зависеть от конкретной модели платы. Программный массив mdadm собирается ядром поверх обычных накопителей, аппаратный — живёт внутри контроллера со своим кэшем и логикой. Зеркало или чётность получаются в обоих случаях, но при отказе, замене и переносе ведут себя по-разному.

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

Переносимость массива — главный водораздел. У программного разметка хранится на самих накопителях: переносим диски в другой сервер и поднимаем массив одной командой сборки, без поиска совместимого железа. Аппаратный массив читается тем же или совместимым контроллером — если плата вышла из строя и замены той же модели нет, данные придётся вытаскивать всерьёз.

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

Разбор частых сомнений: деградация, замена диска, мониторинг

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

Можно ли заменить диск без переустановки и остановки сервисов?

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

Как убедиться, что массив действительно цел, а не «просто отвечает»?

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

Нужен ли отдельный мониторинг, если массив восстанавливается сам?

Сам он не восстанавливается — он выживает. Без оповещений деградация может оставаться незамеченной неделями, пока не откажет второй диск. Мы настраиваем уведомления на события деградации, сбоя и завершения перестройки и дополняем их контролем состояния накопителей, чтобы сигнал приходил до потери данных, а не после.

Обсудим задачу: вернёмся с оценкой и планом работ

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

Что нужно от вас для старта:

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

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

Опишите задачу и текущую конфигурацию — обсудим её и вернёмся с оценкой и планом.