Что проверять после отключения сервера в кластере

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

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

У каждого пула хранилища свой предел

Даже внутри одного Ceph-кластера допустимые отказы могут различаться. Рассмотрим две конфигурации:

Хранилище	Сценарий испытания	Что проверять
Пул с erasure coding 8+3	Одновременное отключение двух серверов Ceph	Продолжение обслуживания нагрузки
Пул с тройной репликацией	Отключение одного сервера	Доступность данных и операций записи

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

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

Для erasure coding тоже требуется карта размещения. Отключение нескольких серверов может почти не затронуть один набор данных и оказаться критичным для другого. Поэтому формулировку «Ceph переживает два сервера» следует сопровождать указанием пула, конфигурации и проверенного размещения.

Реплики нужно привязать к физическим доменам отказа

PostgreSQL с primary и двумя резервными репликами на разных физических узлах позволяет проверить потерю primary и переключение на реплику. В такой конфигурации возможен и сценарий потери двух машин с экземплярами БД. Результат этого теста относится к выбранной схеме репликации и переключения; само число экземпляров универсальной гарантии не даёт.

У Cassandra с тройной репликацией и у Kafka с replication factor 3 предусмотренный сценарий может ограничиваться потерей одной машины. Для Kafka в рассматриваемой схеме также используются три ZooKeeper. Проверять нужно весь набор зависимостей брокеров, включая координацию.

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

Следующий домен отказа — стойка. Практический вариант размещения: максимум один backend-сервер каждой роли в стойке. Для описанного Ceph-пула 8+3 допустимо размещение двух серверов в стойке, поскольку именно их одновременная потеря входит в протокол испытаний. Обесточивание стойки проверяет эту схему целиком: вместе исчезают вычислительные узлы и часть хранилища.

Control plane проверяется отдельно

Три экземпляра etcd на трёх master-нодах позволяют сохранить кворум при потере одной из них. Такой отказ входит в штатный сценарий проверки Kubernetes. Потеря двух участников выходит за его пределы и требует восстановления control plane.

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

Доступность приложения и работоспособность control plane проверяют раздельно. Успешный ответ уже запущенного приложения ещё не подтверждает, что Kubernetes способен восстановить потерянные экземпляры.

Восстановлению подов нужны ресурсы и доступ к данным

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

Отдельный сценарий — поды, зависшие после исчезновения узла. Для их обработки может использоваться специализированный сервис вроде Lost Node Cleaner, который отслеживает такие экземпляры и обеспечивает их перенос. При испытании проверяют, что кластер действительно возвращается к требуемому числу работающих реплик.

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

Балансировка и наблюдаемость входят в тот же тест

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

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

Что записать в протокол испытаний

Для каждого сценария нужен отдельный набор условий:

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

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

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