Сколько дисков выдержит RAID, зависит от схемы

Фраза «RAID 6 выдерживает два диска» верна, но для проектирования ее недостаточно. Массив сохраняет данные, пока число одновременных отказов в одной группе избыточности не превысило возможности схемы. После первого отказа начинается период деградации, и его длительность часто важнее красивой цифры в спецификации.

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

Считать нужно группы избыточности

Число дисков в корпусе ничего не говорит о допустимом числе отказов, пока неизвестна топология. Двадцать четыре диска могут образовывать один RAID 6, четыре группы RAID 6 по шесть дисков, двенадцать зеркал или набор без избыточности. Во всех четырех случаях ответ будет разным.

Группа избыточности, или fault domain на уровне раскладки, это минимальный набор накопителей, внутри которого лежат данные и информация для их восстановления. В RAID 5 одна группа имеет одну порцию четности. В RAID 6 таких порций две. В обычном RAID 10 группой для конкретного блока служит зеркальная пара, хотя контроллер показывает один логический том.

Здесь полезно разделить два вопроса, которые часто смешивают:

• сколько отказов схема гарантированно переносит при любом расположении отказавших дисков;
• сколько отказов она может перенести при удачном расположении.

RAID 10 из восьми дисков гарантированно переносит один отказ. Он может пережить и четыре, если из каждой зеркальной пары выйдет только один накопитель. Но два отказа в одной паре уничтожат доступную копию части данных. Поэтому фраза «RAID 10 выдерживает четыре диска» опасна без оговорки о расположении.

Та же логика работает для RAID 50 и RAID 60. RAID 50 состоит из нескольких групп RAID 5, объединенных полосой. Он может потерять по одному диску в каждой группе, но два диска в одной группе приводят к потере всего тома. RAID 60 допускает до двух отказов в каждой дочерней группе RAID 6. Общая цифра зависит от числа групп, а гарантированный предел для произвольного расположения отказов остается равным запасу одной группы.

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

Предел каждого уровня виден из раскладки

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

OpenZFS описывает ту же модель для RAIDZ: RAIDZ1 переносит один отказ, RAIDZ2 два, RAIDZ3 три. Руководство zpoolconcepts(7) формулирует емкость группы из N дисков размером X с P дисками четности примерно как (N - P) × X, а допустимое число отказов равно P. Это хорошая формулировка, потому что она связывает цену емкости с запасом избыточности.

Зеркало из трех устройств отличается от трех зеркальных пар. Первое хранит три копии одного набора блоков и переносит любые два отказа. Второе хранит по две копии разных полос данных и гарантирует лишь один произвольный отказ. Одинаковые слова «шесть дисков в зеркалах» скрывают разные пределы.

Обозначение на экране тоже может обмануть. Аппаратный контроллер способен представить RAID 60 как один виртуальный диск, а распределенная система может размещать копии по узлам, полкам или зонам питания. Считать надо отказавшие домены, а не строки со статусом Failed. Два диска за одним SAS-экспандером могут исчезнуть одновременно из-за кабеля, хотя сами накопители исправны.

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

RAID 10 ломается по парам

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

Возьмем восемь дисков:

Пара A: disk0 + disk1
Пара B: disk2 + disk3
Пара C: disk4 + disk5
Пара D: disk6 + disk7

Отказы disk0, disk2, disk4 и disk6 оставляют по одной копии в каждой паре, поэтому том продолжает работать после четырех отказов. Отказы disk0 и disk1 уничтожают пару A уже после двух событий. Контроллеру неоткуда прочитать полосы, которые хранились в этой паре.

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

Раскладки Linux MD RAID10 near, far и offset размещают копии не всегда как простые соседние пары. Руководство mdadm(8) прямо говорит о наборах, каждый из которых содержит полную копию данных, когда число копий делит число устройств. Поэтому перед расчетом откройте фактический layout, число копий и сопоставление устройств. Правило «не потерять пару» верно по смыслу, но физическая пара может не совпадать с тем, как подписаны соседние отсеки.

Для проверки Linux MD полезны два вывода:

mdadm --detail /dev/md0
cat /proc/mdstat

В первом ищите Raid Level, Raid Devices, Total Devices, State и таблицу участников. Во втором во время восстановления появятся направление операции, процент, скорость и расчетное время, например:

md0 : active raid10 sda1[0] sdb1[1] sdc1[2] sdd1[3]
      [====>................]  recovery = 23.4% (228514304/976630336) finish=84.2min speed=148127K/sec

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

Большой диск удлиняет окно риска

Объем диска не меняет алгебру четности: RAID 5 с дисками по 2 ТБ и RAID 5 с дисками по 22 ТБ допускают один полный отказ. Но второму массиву обычно нужно прочитать и записать гораздо больше данных, чтобы вернуть избыточность. Все это время новый отказ может превысить предел схемы.

Нижнюю границу времени можно оценить так:

T_rebuild = объем восстанавливаемого диска / устойчивая скорость перестроения

Для диска 18 ТБ при устойчивых 150 МБ/с идеальная оценка равна 120 000 секундам, или примерно 33,3 часа. При 100 МБ/с получится 50 часов. Это расчет без конкуренции с приложениями, повторных чтений, пауз контроллера и падения скорости на части поверхности. В рабочей системе то же перестроение легко растянется на несколько суток.

Используйте десятичные или двоичные единицы последовательно. Производитель обычно маркирует 18 ТБ как 18 × 10^12 байт, а операционная система может показывать около 16,37 ТиБ. Если разделить ТБ на МиБ/с, не приведя единицы, ошибка в оценке приблизится к десяти процентам еще до учета нагрузки.

Для parity-массива объем чтения со здоровых участников может быть намного больше объема одного диска. Чтобы восстановить отсутствующий блок полосы, системе нужны остальные блоки данных и четности. Контроллеры оптимизируют операции по-разному, а ZFS resilver часто обрабатывает выделенные данные, а не пустое пространство, поэтому расчет по паспортной емкости дает границу, а не точный срок.

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

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

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

Вероятность второго отказа можно посчитать

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

Пусть AFR равен годовой вероятности отказа одного диска. Переведем ее в часовую интенсивность:

lambda = -ln(1 - AFR) / 8760

После отказа одного диска в группе из N участников останется N - 1 работающих дисков. Вероятность хотя бы одного дополнительного отказа за T часов при независимых событиях:

P_second = 1 - exp(-(N - 1) × lambda × T)

Пример: двенадцать дисков, условный AFR 2% и перестроение 72 часа. Часовая интенсивность равна примерно 0,000002306. Тогда:

P_second = 1 - exp(-11 × 0,000002306 × 72)
         ≈ 0,001825
         ≈ 0,1825%

Если перестроение займет 24 часа, оценка снизится примерно до 0,061%. Если оно растянется на семь суток, вырастет примерно до 0,425%. Это условная вероятность нового полного отказа во время одного деградированного эпизода, а не годовой риск потери данных и не прогноз для парка.

Для RAID 5 такой второй отказ превышает запас четности. Для RAID 6 после первого отказа еще один диск допустим, а опасны два дополнительных отказа до восстановления. Если обозначить m = (N - 1) × lambda × T, вероятность двух или более независимых событий в простейшей модели Пуассона равна:

P_two_or_more = 1 - exp(-m) × (1 + m)

При тех же N, AFR и 72 часах результат составит около 0,000167%. Разница выглядит огромной, и двойная четность действительно резко снижает риск независимых полных отказов. Но число нельзя использовать как итоговую вероятность потери данных: модель не включает ошибки чтения, общую причину отказов, ошибку оператора и повреждение корпуса.

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

from math import exp, log

n = 12
afr = 0.02
hours = 72

failure_rate = -log(1 - afr) / 8760
mean = (n - 1) * failure_rate * hours

result = {
    "second_failure_percent": 100 * (1 - exp(-mean)),
    "two_or_more_percent": 100 * (1 - exp(-mean) * (1 + mean)),
}
print(result)

Форма вывода:

{'second_failure_percent': 0.182509..., 'two_or_more_percent': 0.000166...}

Подставляйте AFR для своей модели, партии и условий, если накоплена достоверная статистика. Паспортный AFR полезен для сравнения допущений, но не описывает стареющий парк с общей прошивкой и одинаковой датой ввода в работу.

Ошибка чтения не равна отказу диска

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

В руководстве Seagate Exos для корпоративных HDD указана частота невосстановимой ошибки чтения менее одного сектора на 10^15 прочитанных бит. Производитель поясняет, что такую ошибку обнаруживают при чтении, но само чтение ее не вызывает. Знак «менее» важен: это верхняя граница спецификации, а не утверждение, что каждые 10^15 бит обязательно содержат один плохой сектор.

Если ради осторожной оценки принять частоту u = 10^-15 на бит как точное независимое значение и прочитать R бит, вероятность хотя бы одной ошибки:

P_URE = 1 - (1 - u)^R ≈ 1 - exp(-u × R)

В RAID 5 из восьми дисков по 18 ТБ полное восстановление может потребовать чтения порядка семи полных участников. Это около 1,008 × 10^15 бит. Подстановка дает примерно 63,5%. Этот результат часто приводят как доказательство неизбежной смерти больших RAID 5, но такое толкование слишком прямолинейно.

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

Однако отмахиваться от расчета тоже нельзя. Он показывает, почему проверка поверхности до аварии имеет смысл. OpenZFS различает scrub и resilver: scrub проходит по данным, ищет скрытые повреждения и при наличии избыточности переписывает плохую копию; resilver обрабатывает данные, которые ZFS считает устаревшими после замены или возврата устройства. Scrub не заменяет перестроение, а перестроение не заменяет регулярный поиск тихих ошибок.

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

Двойная четность дает еще одну степень свободы при ошибке чтения во время восстановления после одного отказа. У массива остается информация для восстановления проблемной полосы. Это одна из причин выбирать RAID 6 или RAIDZ2 для широких групп больших HDD, даже когда расчет независимого второго отказа кажется небольшим.

Общая причина ломает независимую модель

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

После замены первого диска нагрузка на оставшиеся резко растет. Массив читает области, которые могли месяцами не попадать в рабочий набор. Соседний диск с накопившимися дефектами проявит их именно во время rebuild. Это не доказывает, что перестроение «убивает» исправные диски, но объясняет кластеризацию проблем вокруг аварии.

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

• накопитель и его отсек;
• кабель, экспандер и контроллер;
• блок питания и полка;
• сервер или узел;
• помещение и административный доступ.

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

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

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

Горячий резерв убирает задержку, а не перестроение

Hot spare сокращает время между обнаружением отказа и началом восстановления, но не уменьшает объем данных, который придется прочитать и записать. Если запасной диск уже установлен, контроллер может начать rebuild без поездки инженера и без ожидания доставки. Это особенно важно ночью и на удаленной площадке.

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

Hot spare не добавляет еще одну четность. RAID 5 со spare остается схемой с одной четностью до завершения перестроения. Если второй участник откажет через десять минут после первого, наличие диска, на который успели восстановить лишь малую часть полос, не превращает массив в RAID 6.

Некоторые системы используют распределенное свободное место и восстанавливают данные параллельно на много устройств. OpenZFS dRAID, например, описывает интегрированные распределенные резервы для более быстрого resilver. Принцип оценки не меняется: измерьте фактическое время возврата полной избыточности и считайте риск на это окно, а не на время появления сообщения «spare activated».

Автоматический запуск тоже требует наблюдения. Тревога должна сообщить, какой диск выпал, какой spare выбран, началось ли восстановление, какова скорость и не растут ли ошибки на остальных участниках. Отдельное уведомление нужно при остановке или завершении операции. Иначе автоматизация способна молча заменить один отказ состоянием с исчерпанным резервом.

Холодный запас на складе решает другую задачу. Он полезен, когда модель диска трудно быстро купить, но время доставки со склада до стойки входит в деградированное окно. Зафиксируйте ответственного, доступ к помещению, маркировку совместимых дисков и порядок замены. Формулировка «запас есть» без проверенного маршрута часто добавляет к rebuild рабочий день.

Переходить на другую схему нужно до аварии

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

Практические признаки для пересмотра схемы:

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

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

Разбиение одного RAID 6 из двадцати четырех дисков на несколько меньших групп уменьшает число дисков, которые участвуют в одном домене четности, и локализует rebuild. Цена состоит в дополнительной четности, иной производительности и более сложном распределении емкости. RAID 60 формализует такой компромисс, но его дочерние группы все равно надо документировать.

Тройная четность нужна не «для надежности вообще», а при очень широких группах, долгом восстановлении или требованиях пережить больше двух отказов в одном домене. OpenZFS RAIDZ3 дает такой запас. Иногда лучше уйти от RAID-уровней к распределенному кодированию с учетом узлов и стоек, но тогда считать придется доступность фрагментов, кворум и время восстановления сети, а не диски.

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

При подборе серверов S200 Series и инфраструктуры ЦОД GSE можно увязать схему хранения с емкостью, нагрузкой, сервисной моделью и требованиями к локальной поставке, не привязывая расчет к одному производителю компонентов. Но ответственность за допустимую потерю данных остается у владельца системы: интегратор не может угадать RPO и RTO, которые нигде не записаны.

Проект проверяет восстановление, а не наклейка RAID

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

Минимальный расчет удобно хранить рядом со схемой:

Группа: 12 × 18 ТБ HDD
Схема: RAID 6, 10 data + 2 parity
Допустимо: любые 2 отказа в группе
Занято: 72%
Измеренный rebuild: 61 ч при типичной нагрузке
Принятый AFR для модели: 2% на диск в год
P еще одного отказа после первого: 0,155%
P двух и более после первого: 0,000120%
Scrub: ежемесячно, результат уходит в мониторинг
Spare: 1 global, автоматический запуск проверен
Резервная копия: отдельная система, тест восстановления ежеквартально

Числа вероятности здесь следуют той же независимой модели и не включают общую причину. Их задача не доказать безопасность, а сделать сравнимыми варианты на 24, 61 и 120 часов. Рядом должен лежать сценарный разбор полки, контроллера и ошибки техника.

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

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

Отдельно проверьте процедуру идентификации физического диска. Серийный номер в консоли, номер слота на корпусе и световой индикатор должны указывать на один накопитель. Команда включения locate LED полезна лишь после сверки серийного номера. При сомнении остановите замену и проследите подключение по документации: извлечение здорового партнера из деградированного зеркала остается одним из самых коротких путей к потере тома.

Мониторинг должен различать предвестник и состоявшийся отказ. Рост переназначенных секторов, ошибки интерфейса, тайм-ауты и увеличение задержки чтения требуют проверки, но ни один отдельный SMART-атрибут не дает полной гарантии. Замена подозрительного диска до его полного отказа может пройти через контролируемую операцию copyback или replace, при которой старая копия еще доступна. Это безопаснее аварийной реконструкции, если платформа поддерживает такой порядок и диск способен читать данные.

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

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

Решение о RAID 5, RAID 6, RAID 10 или другой схеме принимайте по худшему допустимому расположению отказов и измеренному окну восстановления. Большой диск сам по себе не делает массив ненадежным. Он просто дольше держит систему в состоянии, где следующая неисправность имеет более высокую цену. Эту цену надо посчитать до того, как загорится второй красный индикатор.