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

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

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

Проектирование стоит начинать с двух метрик. RTO, Recovery Time Objective, задает допустимое время восстановления сервиса. RPO, Recovery Point Objective, определяет объем последних изменений, которые бизнес готов потерять при аварии. Механизм защиты выбирают под конкретный сценарий отказа, а не по названию уровня RAID.

Почему отказ хранилища останавливает серверную систему

Подсистема хранения часто обслуживает несколько вычислительных узлов одновременно. Один SAN-массив, NAS или программный кластер хранения может содержать диски виртуальных машин, тома баз данных, общие каталоги и persistent volumes Kubernetes. Его отказ создает единую точку отказа для нескольких сервисов сразу.

Хранилище как критическая точка всей инфраструктуры

Гипервизор хранит конфигурацию ВМ, виртуальные диски и журналы на datastore. Потеря доступа к datastore приводит к зависанию гостевых ОС, ошибкам записи или остановке машин после исчерпания тайм-аутов. База данных при недоступности журнала транзакций обычно переводит часть операций в ошибку, чтобы не нарушить целостность. Файловый сервер не сможет открыть каталог, если файловая система или сетевой том недоступны.

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

Перед настройкой полезно разобрать цепочку зависимостей: носители, RAID или пул, контроллеры, HBA или NIC, кабели, коммутаторы, LUN или файловый экспорт, гипервизор, приложение. Подробнее состав подсистемы и точки отказа разобраны в статье об архитектуре программного хранилища данных.

Доступность, целостность и сохранность данных - разные свойства

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

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

Какие угрозы должна закрывать система хранения

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

Отказ диска, нескольких дисков и деградация массива

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

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

• Контролируйте состояние RAID, SMART, температуру и ошибки чтения.
• Настройте уведомления о состоянии degraded и начале rebuild.
• Держите совместимый hot spare или запасной носитель с достаточной фактической емкостью.
• Проверяйте свободное место в пуле: заполненный пул может осложнить восстановление и работу снапшотов.

Отказ контроллера, пути доступа, питания или площадки

RAID не защищает от отказа RAID-контроллера, HBA, NIC, кабеля, SFP-модуля, коммутатора, блока питания, PDU, стойки или площадки. Любой одиночный компонент в пути от сервера к данным способен сделать исправный массив недоступным.

Для блочного SAN обычно нужны два контроллера хранения, две независимые фабрики, минимум два пути от каждого сервера и multipath в ОС или гипервизоре. Для сетевого хранилища нужны раздельные NIC, коммутаторы и корректно настроенный сетевой failover. Резервное питание требует независимых линий, PDU и источников питания, иначе два блока питания будут зависеть от одной точки отказа.

Отказ площадки требует отдельного решения: репликации в другой дата-центр или облако, offsite backup, плана запуска сервиса на резервной стороне и проверенных учетных данных. Вынесенная копия в той же стойке не защищает от аварии стойки.

Логические ошибки и вредоносные изменения

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

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

RAID и зеркалирование дисков на сервере: что именно они защищают

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

RAID 1 и RAID 10: зеркалирование с разными компромиссами

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

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

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

RAID 5 и RAID 6: емкость против времени восстановления

RAID 5 хранит распределенную четность и допускает отказ одного носителя. При выходе диска из строя массив восстанавливает недостающие блоки по данным и четности с остальных дисков. Второй отказ до завершения rebuild приводит к потере массива.

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

Выбор между RAID 5, RAID 6 и RAID 10 нельзя делать только по расчету полезной емкости. Оцените размер дисков, допустимое окно деградации, профиль I/O, наличие проверенной резервной копии и последствия полной потери массива.

Аппаратный и программный RAID

Аппаратный RAID использует контроллер с собственной прошивкой, кэшем и метаданными конфигурации. Контроллер может ускорять операции с четностью, но сам становится критичным компонентом. Для защищенного кэша нужны исправная батарея или supercapacitor и энергонезависимая память. При отказе контроллера замена должна поддерживать совместимый формат массива и версию прошивки.

Программный RAID работает на уровне ОС или файловой системы. Его состояние обычно хранится на носителях, а логика остается прозрачнее для администратора. Такая схема требует надежного сервера, корректной настройки загрузки и понимания поведения конкретной ОС или файловой системы. Отказ самого сервера программный RAID не компенсирует.

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

Что RAID не умеет

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

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

Репликация: как продолжить работу при отказе массива или хранилища

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

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

Синхронная и асинхронная репликация

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

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

Failover, split-brain и возврат на основную систему

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

Самый опасный сценарий - split-brain. Он возникает, когда обе стороны считают себя активными и принимают независимые записи. После восстановления сети копии расходятся, а автоматическое слияние может разрушить данные. Для защиты применяют quorum, witness, fencing и строгий порядок изоляции старой активной стороны.

1. Подтвердите недоступность основной стороны и определите масштаб сбоя.
2. Изолируйте старую сторону от записи: выключите узел, отключите доступ к LUN или примените fencing.
3. Проверьте актуальность реплики и зафиксируйте ожидаемый RPO.
4. Переключите роль, сеть и приложение на резервную сторону.
5. После возврата основной системы синхронизируйте данные и выполняйте failback только после проверки целостности.

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

Репликация не заменяет резервное копирование

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

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

Снапшоты и резервные копии: защита от логических ошибок

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

Как работают снапшоты и когда их использовать

Во многих системах снапшоты используют copy-on-write или redirect-on-write. После создания снимка исходные блоки сохраняются до тех пор, пока существуют снапшоты, которым они нужны. Новые записи получают другие блоки или сохраняют предыдущую версию перед перезаписью.

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

• Настройте интервалы по RPO: например, каждый час для рабочих данных и чаще для критичных каталогов, если это оправдано нагрузкой.
• Задайте срок хранения для часовых, дневных и недельных снимков.
• Проверяйте свободное место, возраст последнего снимка и успешность задач очистки.
• Тестируйте восстановление отдельного файла и полного тома до аварии.

Почему снапшот не является независимой копией

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

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

Правила резервного копирования для серверного хранилища

Правило 3-2-1 задает базовый минимум: три копии данных, два типа носителей или независимых систем хранения, одна копия вне основной площадки. Для защиты от ransomware добавьте неизменяемую или offline-копию. Ее срок хранения должен покрывать период, за который инцидент обычно обнаруживают.

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

Практические схемы 3-2-1, ретенцию и измерение реального времени возврата данных описывает руководство по резервному копированию в системах хранения. Для вынесенной копии, резервных серверов или тестового восстановления можно использовать облачную инфраструктуру Timeweb Cloud, предварительно проверив стоимость хранения, скорость восстановления и расположение данных.

Отказ контроллера и мультипутинг: резервирование пути к данным

Надежный RAID-массив останется недоступным, если сервер подключен к нему одним контроллером, одним кабелем или одним сетевым адаптером. Резервирование пути устраняет такие точки отказа и позволяет продолжить I/O при сбое отдельного элемента.

Два контроллера хранения и режимы работы

Система с двумя контроллерами поддерживает доступ к данным после отказа одного контроллера при корректной модели работы платформы. В active-active оба контроллера могут обслуживать I/O, но правила ownership томов и ALUA определяют предпочтительные пути. В active-passive один контроллер обслуживает тома, а второй принимает работу после сбоя.

Критичны состояние кэша записи, синхронизация между контроллерами, поведение при потере связи и порядок возврата после ремонта. Поддержку dual-controller, разрешенные версии прошивки и совместимые схемы подключения подтверждают по документации конкретного массива.

Multipath и резервные подключения сервера

Multipath объединяет несколько путей к одному LUN в единое устройство для ОС или гипервизора. Сервер видит несколько маршрутов через разные HBA или NIC, кабели, коммутаторы и контроллеры, но работает с одним логическим томом. При отказе пути multipath переводит I/O на доступный маршрут.

Рабочая схема для SAN обычно включает две HBA на сервере, два независимых коммутатора или фабрики, два контроллера хранения и минимум четыре физических пути. Для iSCSI или NVMe/TCP ту же логику строят на отдельных NIC, VLAN или сетях и коммутаторах. Два интерфейса, подключенные к одному коммутатору, не переживут отказ этого коммутатора.

• Проверьте обнаружение всех путей на каждом сервере.
• Настройте политику балансировки и failover, которую поддерживает ОС, гипервизор и массив.
• Проверьте ALUA и приоритет оптимизированных путей, если массив использует этот механизм.
• Исключите один общий кабельный канал, один коммутатор и одну линию питания для всех путей.

Проверка отказоустойчивости пути

Наличие нескольких линий на схеме не подтверждает работоспособность multipath. Тест проводят под контролируемой нагрузкой и в согласованное окно. Поочередно отключают кабель, порт, HBA или NIC, коммутатор и контроллер, затем проверяют отсутствие ошибок файловой системы, зависаний ВМ и необработанных I/O-ошибок.

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

Практический сценарий: восстановление после отказа диска

Последовательность действий при отказе носителя должна быть нейтральной к вендору. Конкретные команды, названия пунктов интерфейса и правила hot swap зависят от контроллера, NAS, ОС и типа массива. До инцидента подготовьте карту слотов, серийных номеров, моделей дисков и порядок эскалации.

Диагностика и подтверждение отказа

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

1. Зафиксируйте статус массива, дату, время, ошибки и прогресс, если rebuild уже запущен.
2. Сопоставьте логический идентификатор диска с серийным номером и слотом.
3. Проверьте, нет ли ошибок на остальных носителях, контроллере, кабелях и питании.
4. Убедитесь, что существует актуальная независимая резервная копия.
5. Ограничьте рискованные операции: массовые миграции, нагрузочные тесты, обновления и перестройку других томов.

Замена носителя и запуск rebuild

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

Hot swap допустим только при поддержке корпуса, контроллера и процедуры производителя. Если используется hot spare, проверьте, что контроллер действительно назначил его в нужный массив. После установки нового носителя убедитесь, что rebuild начался для требуемой группы, а не был создан отдельный пустой том.

Контроль восстановления и действия после rebuild

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

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

Что делать при втором отказе во время rebuild

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

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

Как собрать отказоустойчивую архитектуру под RTO и RPO

Архитектуру выбирают по последствиям простоя и допустимой потере данных. Сначала определите сервисы, владельцев, RTO, RPO, зависимые системы, объем данных, скорость изменения и бюджет на резервные компоненты. Затем назначьте защиту для каждого типа отказа и явно запишите риски, которые остаются.

Минимальная схема для одного сервера

Для небольшой инфраструктуры практична схема с RAID 1 или RAID 10, hot spare при необходимости, двумя блоками питания на независимых линиях, мониторингом, регулярными снапшотами и независимым backup-хранилищем. Она уменьшает вероятность простоя при отказе одного диска и ускоряет возврат после ошибки пользователя.

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

Схема для критичного сервиса

Критичный сервис требует минимум двух вычислительных узлов, резервированного хранилища с двумя контроллерами, multipath, независимых коммутаторов или фабрик, репликации на вторую систему хранения и независимых backup-копий. Для автоматического failover нужны quorum или witness, fencing и проверка здоровья приложения, а не только доступность сетевого адреса.

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

Таблица выбора механизма по типу отказа

Тестирование отказов и восстановления

Фактический RTO часто отличается от расчетного. Тайм-ауты multipath могут быть слишком длинными, доступ к backup может зависеть от недоступного домена, у реплики может не оказаться нужного DNS-записа, а приложение может не запуститься без отдельного сервиса лицензирования или секретов.

• Отключайте один диск в тестовой или согласованной среде и проверяйте состояние degraded.
• Проверяйте отказ одного пути, коммутатора и контроллера без ошибок приложений.
• Тестируйте failover вычислительного узла и системы хранения.
• Восстанавливайте отдельный файл, базу, виртуальную машину и полный сервис из backup.
• Измеряйте реальное время, фиксируйте ошибки и корректируйте документацию.

Типичные ошибки при проектировании отказоустойчивого хранилища

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

Один механизм защиты на все случаи

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

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

Резервирование без мониторинга и регламентов

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

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

Схема не проверена реальным отказом

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

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

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