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

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

Для этого определяют RTO и RPO, составляют карту зависимостей, устраняют критичные единичные точки отказа, настраивают резервирование и проверяют его отказами. RAID, ИБП, второй сетевой интерфейс, репликация, кластер и автоматический failover закрывают разные риски. Ни один из этих механизмов не защищает от всех сценариев одновременно.

Практическая последовательность выглядит так: определить критичные сервисы и стоимость простоя, задать SLA и SLO, найти домены отказа, выбрать ручное восстановление, active-passive, active-active или кластер, затем проверить health check, quorum, fencing, бэкапы и план восстановления. Подробнее о различиях между отказоустойчивостью, высокой доступностью и аварийным восстановлением можно прочитать в материале об отказоустойчивости информационных систем.

Что такое отказоустойчивость и как она снижает простой сервисов

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

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

Доступность, надежность и восстановление: не путать разные цели

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

Доступность показывает, какую долю времени сервис доступен пользователю. На нее влияют отказы, длительность восстановления, регламентные работы и ошибки эксплуатации.

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

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

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

Почему резервные копии не заменяют отказоустойчивость

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

Во время восстановления сервис часто остается недоступным. Бэкап защищает содержимое, но не удерживает приложение в рабочем состоянии при отказе сервера. Поэтому бэкапы, репликация и высокая доступность решают разные задачи:

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

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

С чего начать: требования к доступности, RTO и RPO

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

RTO, Recovery Time Objective, это максимальное время восстановления сервиса после отказа. RPO, Recovery Point Objective, это допустимый объем данных, который можно потерять, выраженный через момент времени. Если RPO равен 15 минутам, резервная схема должна позволять вернуть состояние не старше четверти часа.

Как задать RTO и RPO для разных типов сервисов

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

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

Доступность в процентах не описывает последствия одного инцидента

Годовой uptime скрывает длительность отдельных аварий. При расчете за 365 дней:

• 99,9% доступности допускают примерно 8 часов 46 минут недоступности в год.
• 99,99% допускают примерно 52 минуты 34 секунды.
• 99,999% допускают примерно 5 минут 15 секунд.

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

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

Карта зависимостей и доменов отказа

Домен отказа, это группа компонентов, которые могут выйти из строя по общей причине. При проектировании составьте карту минимум по таким уровням:

• сервер, шасси, материнская плата и локальные контроллеры;
• стойка, PDU, ИБП и ввод питания;
• гипервизор, кластер управления и сеть BMC;
• коммутатор, маршрутизатор, firewall и DNS;
• провайдер, канал связи и внешняя площадка;
• система хранения, контроллер, пул дисков и путь доступа к данным;
• приложение, база данных, очереди, секреты и внешние API.

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

Резервирование в вычислительных системах: какие отказы закрывает каждый уровень

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

Питание: ИБП, два блока питания и независимые линии

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

Два БП, подключенные к одному ИБП, не защищают от отказа этого ИБП. Две PDU в одной стойке не закрывают потерю стойки или общего ввода. Поэтому схему описывают как цепочку: ввод, ИБП, PDU, кабель, блок питания, сервер.

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

Если отказ электропитания площадки недопустим, локального ИБП недостаточно. Нужны независимые вводы, резервная площадка или заранее проверенный порядок восстановления в другом месте.

Диски и контроллеры: RAID, ZFS и границы аппаратного резервирования

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

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

Практическая схема проверки хранения включает:

• мониторинг SMART, температуры, ошибок чтения и записи;
• контроль деградации массива и времени resilver;
• проверку состояния контроллера, кэширования и батареи кэша;
• обоснованное использование hot spare, если скорость восстановления важнее стоимости диска;
• регулярный scrub для ZFS и проверку контрольных сумм;
• резервные копии на независимый сервер или площадку;
• тест восстановления отдельных файлов и всей услуги.

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

Сеть: два интерфейса, bonding и резервные каналы связи

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

• Active-backup переключает трафик на резервный интерфейс после отказа активного.
• LACP объединяет несколько физических линий в логический канал и распределяет соединения.
• Два коммутатора снижают риск отказа одного сетевого устройства.
• Резервные маршруты позволяют вывести трафик через другой шлюз.
• Два провайдера уменьшают зависимость от одной внешней сети.

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

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

Сервер, гипервизор и контроллеры управления

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

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

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

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

Схемы отказоустойчивости серверов: от ручного восстановления до кластера

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

Один сервер, мониторинг и проверенные бэкапы

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

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

Ориентир по RTO составляет несколько часов, если есть запасное оборудование и свежие копии. Без подготовленного хоста восстановление может занять рабочий день и больше. RPO зависит от расписания бэкапов и может составлять 15 минут, час или сутки.

Основной и резервный сервер: схема active-passive

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

Ручное переключение проще контролировать. Оператор сначала подтверждает отказ, останавливает неисправный ресурс, проверяет актуальность реплики и запускает сервис на резервном узле. Автоматическое переключение сокращает RTO, но требует health check, quorum и fencing.

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

Active-passive подходит для СУБД, файловых сервисов, виртуальных машин и приложений, где одновременная работа двух экземпляров создает риск конфликтующих записей. RTO часто измеряется минутами, а RPO зависит от синхронной или асинхронной репликации.

Два активных узла: схема active-active

В active-active несколько узлов одновременно обслуживают трафик. Балансировщик нагрузки направляет запросы на доступные экземпляры, а приложение должно корректно работать при потере любого узла.

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

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

Сравнение active-active и active-passive, а также синхронной и асинхронной репликации приведено в практическом руководстве по стратегиям резервирования и репликации.

Кластер высокой доступности для виртуальных машин, баз данных и Kubernetes

Кластер объединяет несколько узлов и правилами управления определяет, где должен работать ресурс. Кластер виртуализации переносит или запускает виртуальные машины на другом хосте. Кластер СУБД управляет ролями экземпляров, репликацией и выбором лидера. Kubernetes перезапускает pod-ы и размещает их на доступных worker-узлах.

Эти механизмы нельзя считать взаимозаменяемыми. Виртуализация зависит от хранилища и сети. СУБД зависит от консистентности данных и кворума. Kubernetes зависит от control plane, etcd, ingress, постоянных томов и внешних сервисов.

Для кластера виртуализации нужны независимые узлы, сетевые пути, доступное хранилище или репликация дисков, а при автоматическом запуске ресурсов, quorum и fencing. Для СУБД задают правила выбора primary, задержку репликации и порядок возврата узла. Для Kubernetes распределяют control plane и worker-узлы по доменам отказа, а состояние кластера регулярно резервируют.

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

Автоматическое переключение при сбоях: quorum, fencing и защита от split-brain

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

Проверка доступности узла не равна проверке работоспособности сервиса

Проверка по ICMP отвечает только на вопрос, доступен ли сетевой адрес. Открытый TCP-порт показывает, что процесс принял соединение. Пользовательская операция требует более глубокого health check.

Полезно разделить проверки на уровни:

1. Сетевой маршрут и доступность интерфейса.
2. Работа процесса и открытый порт.
3. Корректный HTTP-ответ приложения.
4. Подключение к базе данных и очереди.
5. Выполнение безопасной тестовой операции, например чтение подготовленного объекта.
6. Сквозная проверка пользовательского сценария с контролем задержки и кода ошибки.

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

Зачем кластеру quorum

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

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

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

Fencing: как изолировать прежний активный узел

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

Для fencing используют:

• отключение питания через BMC или управляемую PDU;
• блокировку доступа к SAN или общему диску;
• изоляцию порта на сетевом оборудовании;
• механизмы fencing, встроенные в гипервизор или кластерное ПО.

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

Автоматическое переключение без quorum и fencing превращает сетевой сбой в риск двойной записи. Сначала защищают владение ресурсом, затем сокращают время переключения.

Как обеспечить отказоустойчивость сервера без избыточных затрат

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

N+1, 2N и N+2: что означают уровни резервирования

N, это минимальное число компонентов или мощность, необходимые для работы. N+1 означает один дополнительный резервный элемент. N+2 дает два резервных элемента. 2N означает полное дублирование всей требуемой мощности или цепочки.

N+1 полезен, когда система должна пережить один отказ и продолжить работу с допустимой деградацией. 2N оправдан при независимых доменах питания или сети. Формальное дублирование без разнесения по стойкам и площадкам дает слабую защиту.

Когда достаточно резервирования компонентов, а когда нужен второй узел

Второй сервер полезен, когда отказ целого узла превышает допустимый RTO. Он потребует синхронизации данных, конфигурации, секретов, версий и сетевых адресов. Без этих элементов резервный сервер остается пустым корпусом с неопределенным сроком запуска.

Как учитывать стоимость простоя и сложность сопровождения

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

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

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

Рабочие схемы для типовых сценариев

Ниже приведены отправные архитектуры. Их параметры нужно подтвердить нагрузочными проверками, тестом отказа и расчетом RTO/RPO.

Внутренний сервис с допустимым простоем в несколько часов

Подойдет схема с одним сервером, RAID или ZFS, ИБП, внешним мониторингом и резервными копиями на отдельное хранилище. Конфигурацию храните в репозитории, а восстановление описывайте в runbook.

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

Ориентир по RTO, 2-4 часа при наличии подготовленного оборудования. RPO определяется расписанием копирования. Такой подход дешевле кластера и подходит, если остановка внутреннего сервиса не блокирует продажи, платежи или производственные операции.

Веб-приложение и база данных с коротким RTO

Разделите stateless-слой приложения и stateful-слой данных. Два экземпляра приложения размещают на разных узлах и подключают к балансировщику. Сетевые интерфейсы и коммутаторы разводят по независимым путям.

Для базы данных задают отдельную стратегию: primary-replica, синхронная репликация или кластер СУБД, регулярные бэкапы и мониторинг задержки. База чаще определяет фактический RPO всей системы. Если приложение переключается за минуту, а база восстанавливается за час, общий RTO составляет не минуту.

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

Проверяйте транзакцию целиком: открыть страницу, авторизоваться, прочитать данные, создать тестовую запись, обработать очередь и корректно удалить тестовый объект. Проверка только HTTP-кода не выявит отказ базы или очереди.

Файловое хранилище или NAS с критичными данными

Базовая схема включает зеркала или RAIDZ, контроль целостности, мониторинг накопителей, резервные копии и документированное восстановление экспортов SMB или NFS. При высоких требованиях добавляют репликацию на второй NAS или площадку.

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

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

Kubernetes-нагрузка с критичными сервисами

Автоматический перезапуск pod-а защищает от падения процесса. Отказоустойчивость Kubernetes требует защиты control plane, etcd, worker-узлов, ingress, постоянных томов, DNS и внешних зависимостей.

• Размещайте control plane минимум на трех узлах для сохранения кворума после потери одного.
• Распределяйте worker-узлы по стойкам или зонам отказа.
• Задавайте replicas, PodDisruptionBudget и правила anti-affinity для критичных приложений.
• Используйте несколько экземпляров ingress-контроллера и отказоустойчивую публикацию трафика.
• Резервируйте состояние etcd и проверяйте его восстановление.
• Отдельно защищайте постоянные тома и внешнюю базу данных.

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

Проверка отказоустойчивости: мониторинг, тесты и план восстановления

Схема считается готовой после контролируемой проверки отказов. Документация без теста показывает намерение, но не фактический RTO и RPO.

Что мониторить помимо доступности сервера

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

• доступность и задержку пользовательского сценария;
• коды ошибок, таймауты, длину очередей и число повторных запросов;
• состояние репликации, lag, ошибки синхронизации и разрыв связи;
• здоровье RAID, ZFS, дисков, контроллеров и файловых систем;
• температуру, вентиляторы, питание, батареи ИБП и блоки питания;
• ошибки сетевых интерфейсов, потери пакетов и состояние bonding;
• место для данных, логов и резервных копий;
• состояние quorum, fencing и кластерных ролей;
• срок действия сертификатов, DNS и внешних API.

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

Как проводить тесты failover и восстановления

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

Проверяйте последовательно:

1. Отключение одного сетевого интерфейса и кабеля.
2. Потерю порта или коммутатора.
3. Отказ диска и восстановление массива.
4. Отключение активного сервера.
5. Недоступность общего хранилища.
6. Разрыв связи между узлами кластера.
7. Срабатывание quorum и fencing.
8. Недоступность внешнего провайдера или канала.
9. Восстановление сервиса из резервной копии.

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

Чек-лист перед вводом схемы в эксплуатацию

• Определены критичные сервисы, SLA, SLO, RTO и RPO.
• Составлена карта зависимостей и доменов отказа.
• Питание, сеть, хранилище и вычислительные узлы имеют защиту, соответствующую риску.
• Резервные копии хранятся отдельно от основного сервиса.
• Восстановление из копии проверено на тестовой или резервной площадке.
• Резервный узел синхронизирован по данным, версиям, конфигурации и секретам.
• Health check проверяет пользовательскую операцию и ключевые зависимости.
• Quorum настроен с учетом реальных доменов отказа.
• Fencing проверен отдельным тестом.
• Алерты доходят ответственным сотрудникам и содержат понятное действие.
• Есть актуальный runbook с командами, контактами и критериями завершения аварии.
• Назначены владельцы сервиса и ответственные за принятие решения о переключении.
• Запланированы регулярные тесты failover, восстановления и возврата к штатной схеме.

Коротко: как выбрать схему отказоустойчивости

1. Определите критичные сервисы, пользовательские операции и стоимость часа простоя.
2. Задайте для каждого сервиса RTO, RPO, SLA и SLO.
3. Составьте карту зависимостей: серверы, питание, сеть, хранилище, DNS, базы и внешние API.
4. Устраните единичные точки отказа на нужном уровне, начиная с наиболее дорогих сценариев.
5. Выберите ручное восстановление, active-passive, active-active или кластер.
6. Для автоматического failover настройте health check, quorum и fencing.
7. Вынесите бэкапы за пределы основного домена отказа и регулярно проверяйте восстановление.
8. Свяжите мониторинг с пользовательскими операциями, RTO и RPO.
9. Проводите тесты отказа, фиксируйте фактическое время восстановления и обновляйте runbook.

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