Горячая замена диска: сервер живёт, массив нервничает

Железо дешевеет, и то, что раньше стояло только в серьёзных вычислительных центрах, постепенно оседает у обычных клиентов. Один из них в этом квартале поставил себе сервер с горячей заменой дисков - hot-swap. Корзины с салазками, индикаторы на морде, и диски, которые теоретически можно менять без остановки машины. Мы, признаться, к этому заказу отнеслись с интересом: на SCSI-массивах такую механику видели, но самим вытаскивать диск из живого сервера ещё не приходилось.

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

Вытащили - и вот тут всё началось

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

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

Что значит деградировавший массив

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

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

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

Бэкап именно сейчас, не вчера

Мы сделали то, что должны были сделать ещё до замены диска: проверили бэкап. Лента была. Последняя копия - суточной давности. Для этого клиента - приемлемо, потеря дня работы неприятна, но не смертельна. Если бы резервной копии не было или она была недельной давности - разговор с клиентом шёл бы совсем иначе.

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

Мы порекомендовали клиенту добавить в регламент простое правило:

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

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

Дождаться завершения - утилита покажет, когда массив снова в норме. До этого момента он остаётся уязвимым.

Горячая замена - не волшебство

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

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

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