Отказоустойчивость систем хранения: RAID, зеркала и репликация на практике

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

Порядок выбора обратный интуиции: сначала считают RPO и RTO, потом подбирают технологии. RPO 0 требует синхронной репликации и задержки между площадками в единицы миллисекунд. RPO 15 минут закрывает асинхронная репликация снапшотов по расписанию. RPO в сутки часто устраивает ночной бэкап. RTO определяет цену простоя: если час недоступности стоит дороже второго сервера, экономия на резервном узле обманчива.

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

Три уровня отказоустойчивости: диск, узел, площадка

Каждый уровень отвечает на свой вопрос. Диск: что будет, если умрет носитель. Узел: что будет, если умрет сервер, контроллер или питание. Площадка: что будет, если умрет здание целиком.

Диск. RAID 1, RAID 5, RAID 6, RAID 10, зеркала ZFS и RAIDZ. Массив продолжает отдавать данные после отказа одного или двух дисков, а hot spare сокращает окно деградации. Уровень защищает от предсказуемого износа носителей.

Узел. Репликация между NAS, кластеризация, кворум, дублирование контроллеров и multipath. Здесь закрывают отказ сервера, сетевой карты, блока питания, HBA. RTO измеряется минутами или часами и зависит от процедуры переключения, ручной или автоматической.

Площадка. Асинхронная репликация в удаленный ЦОД, offsite-бэкап, георезерв. Защита от пожара, затопления, длительного отключения электричества, изъятия оборудования.

RAID 6 переживет смерть двух дисков из восьми и не переживет потерю стойки. Репликация между двумя NAS в одной комнате переживет отказ сервера и не переживет потерю комнаты. Уровни дополняют друг друга, подменять один другим нельзя.

Почему нельзя путать уровни при выборе архитектуры

Типовая ошибка номер один: «поставлю RAID 10 и буду спать спокойно». Массив из восьми дисков дает скорость и переживает отказ одного диска в каждом зеркале, но при выходе из строя сервера данные становятся недоступны до замены железа и переноса дисков. Если сервис критичен, к RAID нужен второй узел.

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

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

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

RAID-уровни на практике: что выбрать и почему

RAID 1: минимум два диска, полезная емкость 50%, переживает отказ одного диска, восстановление сводится к копированию зеркала.

RAID 5: минимум три диска, теряет емкость одного диска, переживает один отказ. Слабое место - rebuild. Пока массив деградирован, любой второй сбой означает потерю данных. Для дисков объемом 4 ТБ и выше окно восстановления растягивается на сутки и больше, а шанс встретить нечитаемый сектор на втором диске растет вместе с объемом.

RAID 6: минимум четыре диска, теряет емкость двух, переживает два отказа. Разумный выбор для массивов из 6-12 дисков большого объема, где rebuild идет долго.

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

В ZFS логика другая: RAIDZ1, RAIDZ2 и RAIDZ3 используют переменную ширину полосы и контрольные суммы, поэтому чтение проверяет целостность блоков. RAIDZ1 близок по стойкости к RAID 5, RAIDZ2 и RAIDZ3 переживают два и три отказа соответственно.

Ориентиры по выбору: два диска - зеркало, 4-8 дисков - RAID 10 или RAIDZ2, больше 8 дисков - RAIDZ2 или RAIDZ3. Команды mdadm, настройка hot spare и чек-листы замены диска собраны в отдельной статье про уровни RAID, настройку и практические рекомендации.

Hot spare в RAID массиве: когда нужен и как работает

Hot spare - резервный диск, подключенный к контроллеру или пулу и не участвующий в работе. При отказе рабочего диска контроллер автоматически вводит его в массив и запускает rebuild без участия администратора.

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

Что стоит: слот и деньги. Диск не добавляет полезной емкости, а в ZFS резервный диск пула (spare) простаивает до отказа. Для SSD цена резерва заметна, для HDD из расчета на терабайт она невелика.

Практическое правило: для RAID 5 и RAIDZ1 с дисками от 4 ТБ hot spare обязателен, потому что rebuild долгий, а избыточность всего одна. Для RAID 6 и RAIDZ2 с запасом по времени можно обойтись без горячего резерва, держа холодный диск на полке. Hot spare не отменяет мониторинг: он не спасет, если отказал контроллер или если о деградации никто не узнал.

Деградация массива и rebuild: что происходит и как не потерять данные

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

Rebuild (в ZFS - resilver) восстанавливает данные на новый носитель. Время зависит от объема диска, скорости интерфейса, нагрузки и типа массива. Ориентиры для HDD: диск 4 ТБ восстанавливается 6-24 часа, 8 ТБ - 12-48 часов, 16 ТБ - до нескольких суток. Массив RAIDZ2 из шести дисков восстанавливается параллельно, но упирается в пропускную способность самого медленного диска.

Пример из практики: rebuild RAID 5 из четырех дисков по 4 ТБ занял 14 часов при постоянном трафике файлового сервера. Средняя задержка отклика выросла на 40%, часть задач бэкапа не уложилась в окно. После инцидента массив пересобрали в RAID 6 и добавили hot spare.

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

Репликация между двумя NAS: пошаговая настройка

Репликация переносит данные с одного NAS на другой и закрывает риск отказа узла. Типовая схема на ZFS: источник и приемник на TrueNAS, передача через zfs send и zfs receive, запуск по расписанию из интерфейса.

1. Подготовить доступ. На источнике создать ключ SSH без пароля, публичную часть положить в authorized_keys пользователя на приемнике. Проверить вход командой ssh replication@backup-nas.
2. Создать периодические снапшоты на источнике. Имя вида tank/data@auto-%Y-%m-%d_%H-%M, расписание каждые 15 минут, рекурсивно по датасетам.
3. Создать задачу репликации на приемнике: источник tank/data или корневой датасет, приемник backup/data, режим только инкрементальный, ретенция снапшотов 7 дней, сжатие включено.
4. Включить шифрование канала. В TrueNAS это SSH-транспорт с ключом или паролем, данные шифруются на время передачи.
5. Запустить задачу вручную и проверить результат: последний снапшот на приемнике совпадает по имени и времени с источником, в логах нет ошибок.
6. Настроить мониторинг отставания. Алерт, если возраст последнего снапшота на приемнике превышает RPO. При расписании 15 минут порог 45 минут дает запас на повторные попытки.

Ручная проверка одного датасета выглядит так: сначала zfs snapshot -r tank/data@test1, затем zfs send -rc tank/data@test1 | ssh backup-nas zfs receive -F backup/data. Ключ -c включает промежуточные снапшоты, ключ -F на приемнике приводит датасет к состоянию источника.

Производительность ограничивает канал, а не диски. При изменении 50 ГБ в сутки и канале 1 Гбит/с передача занимает около 7 минут в теории и 10-15 минут на практике. Для больших изменений ставят лимит пропускной способности, чтобы репликация не съедала канал у рабочих сервисов.

Для сценариев без ZFS используют rsync по SSH с ключами и опциями -aHAX --delete, но он перебирает файлы и хуже масштабируется на миллионах мелких файлов. Если сравнивать зеркало внутри узла и репликацию между узлами, разница в RPO: зеркало пишет синхронно и RPO близок к нулю, асинхронная репликация дает RPO, равный интервалу между снапшотами.

Организация кворума и защита от split-brain

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

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

Защита строится на трех механизмах.

• Кворум. Третий участник (witness, арбитр, qdevice) голосует, какой узел остается активным. В кластере Pacemaker и Corosync это quorum device на отдельной площадке. Для пары NAS роль арбитра выполняет небольшая виртуальная машина в другом ЦОД или облаке.
• Fencing. При потере связи один узел принудительно выключается: через IPMI, управляемый PDU или другой out-of-band канал. Без fencing автоматическое переключение опасно, потому что старый узел может продолжать писать.
• Ручной арбитраж. Для двух узлов без третьей площадки оставляют явное правило: автоматика запрещена, переключение делает дежурный инженер по инструкции. Это медленнее, зато исключает двойную запись.

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

Если своего железа для witness нет, арбитра поднимают в облаке: отдельная виртуальная машина с минимальными ресурсами обходится дешевле второго ЦОД. Подходящий вариант - облачная инфраструктура Timeweb Cloud, где witness-инстанс и offsite-копия живут в другой зоне доступности.

RAID не заменяет резервное копирование: сценарии, где это критично

RAID защищает от отказа диска. Он не защищает от данных, которые уже испорчены: массив исправно хранит и исправно раздает любую ошибку. Ниже сценарии, где массив бесполезен.

• Ошибка оператора. Удаление по неверному пути или снос тома стирает данные на всех дисках сразу. RAID не отличает легитимную запись от разрушительной.
• Шифровальщик. Вредоносное ПО шифрует файлы, и зеркало честно повторяет каждое изменение. К моменту обнаружения зашифрованы и рабочие диски, и вторая половина зеркала.
• Сбой контроллера или прошивки. Массив может стать нечитаемым целиком, особенно при несовпадении версий прошивки после замены контроллера.
• Логическое повреждение. Ошибка приложения или администратора ломает структуру базы данных, RAID тиражирует результат.
• Пожар, затопление, кража. Локальные копии исчезают вместе с оборудованием.

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

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

Проверка восстановления обязательна. Бэкап, который ни разу не восстанавливали, остается гипотезой. Раз в квартал копию разворачивают на тестовом стенде, замеряют реальное время восстановления и сравнивают его с целевым RTO. Схемы, ретенция и расчет объема копий разобраны в руководстве по резервному копированию в системах хранения.

Как связать RAID, репликацию, снапшоты и multipath в одну схему с измеримыми RTO и RPO, разобрано в статье об отказоустойчивости хранилища в серверной системе.

Чек-лист перед вводом хранилища в прод

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

• Конфигурация массива. Уровень RAID соответствует нагрузке, hot spare назначен, состояние всех дисков в норме, контрольные суммы проверены, пул без ошибок. Для ZFS: zpool status без ошибок и завершенный scrub.
• Мониторинг и алертинг. Настроены SMART, состояние массива, свободное место, температура, статус репликации. Алерты приходят туда, где их читают ночью: почта, Telegram, системы дежурств.
• Репликация. Расписание выставлено под RPO, тестовая передача прошла, отставание не превышает порог, повторный запуск задачи дает тот же результат.
• Кворум и fencing. Witness размещен на другой площадке, fencing проверен, сценарий разрыва связи отрепетирован, автоматическое переключение запрещено там, где нет кворума.
• Резервные копии. Правило 3-2-1 соблюдено, offsite-копия есть, неизменяемость включена, восстановление проверено на тестовом стенде с замером времени.
• Документация. Схема, RPO, RTO, IP-адреса, точки входа, порядок действий при отказе. Документ лежит там, где его найдут без доступа к рабочей станции выбывшего инженера.
• Нагрузочное тестирование. Прогон реального профиля: случайная запись, последовательное чтение, одновременный бэкап и репликация. Замер задержек в деградированном режиме дает честную картину.
• Версии прошивок и ПО. Прошивки контроллеров, дисков и версия ОС совместимы и одинаковы на узлах. Расхождение версий между узлами репликации ломает совместимость функций ZFS.
• SLA и роли. Зафиксировано, какой простой считается аварией, кто принимает решение о переключении, кто отвечает за замену диска. Без этого решения принимают самые громкие в чате.
• Финальный аудит. Повторная проверка предыдущих девяти пунктов через неделю после запуска: реальная нагрузка выявляет то, что не видно на тестовом стенде.

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

Минимальный набор для продакшена: массив с двойной избыточностью, hot spare, репликация с отставанием не больше RPO, кворум на отдельной площадке, проверенный offsite-бэкап и документ с процедурой восстановления. Все, что не подтверждено командой или тестом, считается непроверенным.