Регламент замены жёстких дисков на сервере - это набор правил, которые отвечают на три вопроса: когда диск пора менять, кто и как это делает и что должно быть готово заранее, чтобы замена прошла без остановки сервиса. Регламент - это не инструкция «какой отвёрткой откручивать»: физическая процедура занимает пять минут, а всё остальное решается до того, как диск начал сыпаться.
Главное отличие серверного диска от десктопного здесь принципиальное. Диск в сервере меняют горячим - не выключая сервер и не снимая крышку. Если вы встречаете совет остановить сервер, отсоединить кабель питания и кабель данных от диска, - это инструкция для настольного компьютера, и к стоечному серверу она не имеет отношения.
Диск меняют в трёх ситуациях, и они требуют совершенно разной срочности.
Отказ уже произошёл. Диск не определяется контроллером, вылетел из массива, RAID перешёл в состояние degraded. Здесь думать не о чем: меняем сейчас, потому что до восстановления избыточности массив живёт без запаса прочности.
Диск ещё работает, но подаёт сигналы. Растёт число переназначенных секторов, появляются ошибки чтения, контроллер помечает диск как подозрительный, время отклика заметно выросло относительно соседей в массиве. Это плановая замена: её можно назначить на удобное окно, но откладывать на месяцы не стоит.
Диск здоров, но исчерпал ресурс по регламенту. Отработал заявленный срок, вышел из гарантии, относится к партии с известными проблемами. Замена по календарю, а не по симптомам.
Какие именно показатели считать сигналом и как читать отчёт диска - тема отдельная и подробная: значения атрибутов, ложные срабатывания и то, какие показатели реально предсказывают отказ, разобраны в статье про SMART-мониторинг дисков на серверах.
Разница между «сейчас» и «планово» - это не вкусовщина, а расчёт риска. В массиве с одинарной избыточностью (RAID 5, RAID 1) отказ одного диска съедает весь запас: следующий отказ означает потерю данных. В RAID 6 или RAID 10 запас есть, но он тоже конечен.
| Ситуация | Срочность | Почему |
|---|---|---|
| Диск вылетел, массив degraded, hot-spare нет | немедленно | массив без избыточности, второй отказ - потеря данных |
| Диск вылетел, hot-spare подхватил | в ближайшие дни | избыточность восстанавливается автоматически, но запас израсходован |
| Растут ошибки, диск ещё в массиве | плановое окно | есть время выбрать момент и подготовить замену |
| Ресурс по календарю исчерпан, симптомов нет | планово, партиями | удобно совмещать с другими работами |
Отдельно про то, чего делать не надо: менять здоровые диски «для профилактики производительности». В сервере диск в составе массива не начинает работать быстрее оттого, что он новый, а лишняя замена - это лишний ребилд, то есть лишний риск.
Регламент существует ради этого раздела. Когда диск уже вылетел, поздно выяснять, есть ли на складе такой же.
Запас ЗИП. Держите на полке хотя бы один диск той же модели и ёмкости на каждый тип массива. Диск, купленный «когда понадобится», приезжает через недели, а массив всё это время живёт без избыточности. Для критичных систем разумный ориентир - один запасной на каждые 8-12 рабочих дисков, но точнее считать от сроков поставки: чем дольше везут, тем больше запас.
Hot-spare в массиве. Диск горячего резерва стоит в корзине, крутится вхолостую и вступает в дело автоматически, как только контроллер отбраковал рабочий. Это переводит ситуацию из «немедленно» в «в ближайшие дни» - самая дешёвая покупка спокойствия из всех возможных.
Проверенная резервная копия. Ребилд - момент повышенной нагрузки на оставшиеся диски, и именно во время него иногда вылетает второй. Копия должна существовать и восстанавливаться, а не просто числиться в отчёте.
Совместимость. Диск на замену должен подходить контроллеру по интерфейсу, а массиву - по ёмкости и, желательно, по модели. Диск меньшего объёма в массив не встанет; диск большего встанет, но излишек пропадёт. Что бывает и чем модели отличаются между собой - в разборе, какие бывают жёсткие диски.
Журнал замен. Простая таблица: дата, слот, серийные номера снятого и поставленного, причина. Через год она отвечает на вопросы «эта партия сыпется?» и «когда мы вообще этот диск ставили?».
Сама процедура на стоечном сервере с горячей заменой выглядит так.
Пошаговый разбор с оговорками под конкретные контроллеры - в отдельной инструкции, как заменить жёсткий диск на сервере.
Чего делать нельзя: выдёргивать диск, который контроллер считает рабочим; вынимать сразу два диска; извлекать диск во время ребилда. И не стоит менять диск в массиве без избыточности - там сначала копия, потом всё остальное.
Восстановление массива - не формальность, а тот момент, когда чаще всего теряют данные.
Пока идёт ребилд, контроллер читает все данные с оставшихся дисков, чтобы пересчитать содержимое нового. Диски одной партии, отработавшие одинаковое время под одинаковой нагрузкой, оказываются под пиковой нагрузкой одновременно - и если один уже был на грани, вылетает он именно сейчас. В массиве с одинарной избыточностью это означает потерю данных.
Отсюда несколько практических следствий.
Время ребилда растёт вместе с ёмкостью дисков: чем крупнее диски, тем дольше окно риска. Для многотерабайтных дисков онÐ