Почему etcd кластер теряет кворум и роняет сервисы
etcd кластер хранит конфигурацию как журнал реплицируемых записей: запись считается применённой только после подтверждения большинством узлов. Из пяти узлов кворум требует трёх — потеря третьего переводит кластер в режим только чтения, а следом и в полный отказ. Отдельная ловушка — рассинхрон настроек: узел с медленным диском отстаёт от лидера, копит очередь изменений и выпадает из голосования, после чего оставшиеся начинают выбирать нового лидера по кругу.
Снаружи это выглядит как отказ хранилища конфигураций без единой ошибки в логах приложения. Часть сервисов читает ключи из кэша и продолжает жить на устаревших значениях, часть обращается напрямую и получает таймаут. Рассинхрон настроек растекается по группам сервисов: одни уже видят новый адрес зависимости, другие держат старый, и трафик уходит в никуда.
Дальше срабатывает каскадная недоступность. На хранилище завязаны обнаружение сервисов, ротация секретов и запуск новых экземпляров приложений: пока оно молчит, не поднимаются реплики, не обновляются маршруты, а проверки живости начинают отстреливать здоровые экземпляры. Потеря кворума бьёт по всему контуру сразу, хотя причина локальна.
И почти всегда это не внезапный отказ диска, а накопленный долг: все узлы в одной зоне отказа, нет контроля задержки применения записей, бэкапы ни разу не проверяли восстановлением. Разбираем, как это закрывается — от топологии и лимитов до регламента замены узла.
Что даёт отказоустойчивый etcd кластер: эффект по метрикам
Отказоустойчивый etcd кластер собирают из нечётного числа узлов — обычно трёх или пяти. Такой состав переживает потерю одного-двух узлов: оставшиеся сохраняют кворум и продолжают отдавать конфигурацию, поэтому деградация узла не превращается в остановку сервисов. Ниже — пять результатов, которые видно в метриках после переезда на такой контур.
Время восстановления после отказа узла
Сбойный узел заменяется добавлением нового в состав и синхронизацией снимка состояния — без ручного разбора конфигурации на хосте. Время восстановления сокращается с часов ручного подъёма до десятков минут, причём запись и чтение конфигурации доступны всё это время.
Устранённый класс отказов: расхождение конфигураций между сервисами
Единая конфигурация в одном хранилище убирает разрозненные файлы на хостах, из-за которых окружения расходились и падали на несовпадении параметров. История ревизий показывает, кто и когда изменил значение, а откат к предыдущей ревизии возвращает сервис в рабочее состояние за секунды вместо поиска различий вручную.
Остальные эффекты — отсутствие единой точки отказа при чтении настроек, одинаковая конфигурация во всех средах и предсказуемая скорость применения изменений: правка раскатывается на все сервисы одним проходом, без обхода хостов.
Режимы развёртывания хранилища конфигураций: сравнение
Режим развёртывания определяет две вещи: как узлы находят друг друга и сколько отказов кластер переживает без потери конфигураций. Разница между статическим составом узлов и динамическим обнаружением проявляется именно в момент сбоя — тогда и становится видно, правильно ли выбрана схема.
Один центр обработки данных
Здесь уместен статический состав узлов: адреса прописаны в конфигурации каждого участника, кластер собирается предсказуемо, отладка сводится к проверке связности между узлами. Нечётное число узлов даёт запас на отказ одного из них без остановки записи. Ограничение схемы в другом: добавить узел без правки конфигураций и перезапуска нельзя, а отказ всего центра обработки данных останавливает запись конфигураций целиком.
Несколько зон доступности
Тут нужнее динамическое обнаружение: узлы находят друг друга через внешний реестр или службу имён, состав кластера меняется без ручной правки. Цена — зависимость от сети между зонами и от самого источника обнаружения. Чем выше задержка между зонами, тем дольше подтверждается запись, поэтому зоны размещают с предсказуемой связностью.
| Режим | Когда подходит | Ограничения схемы |
|---|---|---|
| Статический состав, один ЦОД | Небольшой контур со стабильным числом узлов | Новый узел — правка конфигураций и перезапуск; отказ центра останавливает запись |
| Статический состав по зонам | Есть управляемая сеть между зонами | Задержка между зонами увеличивает время подтверждения записи |
| Динамическое обнаружение | Состав узлов меняется часто | Нужен внешний источник обнаружения; его недоступность мешает сборке |
Перед выбором проверяем задержку между зонами и то, как часто меняется число узлов, — от этого зависит схема и порядок замены участников.
Этапы внедрения: от аудита до передачи в эксплуатацию
Порядок работ выстроен так, чтобы каждый шаг опирался на данные предыдущего: сначала фиксируем фактическое состояние, затем проектируем и только потом меняем боевой контур. Ниже — типовой маршрут для etcd-кластера, который хранит конфигурации и состояние приложений.
Аудит текущего состояния
Смотрим, что уже работает и какие конфигурации нельзя терять, и отдельно — на текущие точки отказа: единственный узел, репликация без кворума, бэкап, который ни разу не проверяли.
- Аудит конфигураций. Карта сервисов, которые читают и пишут состояние, объём ключей, частота изменений, права доступа. На выходе — узкие места и список конфигураций, которые переживут миграцию без правок.
- Проектирование схемы. Число узлов и кворум, раскладка по зонам доступности, регламент бэкапа, схема сертификатов и разграничение доступа между приложениями.
- Настройка узлов. Развёртывание по спроектированной схеме, перенос конфигураций со сверкой ключей, мониторинг, алерты на потерю кворума и автоматический перезапуск.
Проверка отказоустойчивости под нагрузкой
- Проверка отказоустойчивости. Гасим по одному узлу, имитируем потерю лидера и разрыв связи между зонами: кластер обязан сохранить кворум и продолжать обслуживать чтение и запись.
- Нагрузочные прогоны. Профиль, близкий к боевому: пики записи, много одновременных клиентов, длинные сессии. Замеряем задержку ответа и время выбора нового лидера.
- Передача в эксплуатацию. Регламенты восстановления, дашборды, разграничение прав, учения с командой заказчика и сопровождение в первые дни после переключения.
Комплект передачи: конфигурации, схемы, политики доступа
Комплект собираем не «для галочки», а чтобы дежурная смена могла поднять, расширить и восстановить кластер без нас. Ниже — что именно уходит заказчику на руки вместе с работающим контуром.
Политики доступа и IAM-роли
- Роли и привязки с разделением прав: чтение конфигураций, запись, администрирование кластера — под отдельные сервисные учётные записи.
- Порядок выдачи и ротации сертификатов с процедурой отзыва скомпрометированного ключа.
- Матрица «кто и что может»: соответствие приложений, учётных записей и разрешённых операций; запись в боевой контур из тестовых приложений запрещена правилами.
- Настройки аудита: какие обращения к хранилищу логируются и как долго хранится журнал.
Регламенты обслуживания и восстановления
- Конфигурационные файлы всех узлов с комментариями — какой параметр кластера выставлен и почему именно так.
- Схемы развёртывания: топология, кворум, порядок добавления и замены участника, привязка к площадкам.
- Регламент обслуживания: регламентные проверки состояния, обновление на актуальную ветку, вывод узла без потери кворума.
- Инструкция по восстановлению: снятие резервных копий, проверка их пригодности, сценарий подъёма с нуля и точка, до которой возможен откат.
- Документация для эксплуатации: ответственные, окна работ, время реакции дежурного и журнал изменений.
Комплект передаём в закрытом репозитории и на защищённом носителе, с сопроводительным описанием — что лежит в каждой папке и когда этот артефакт нужно обновлять.
Кейс: восстановление хранилища без потери конфигураций
После сбоя диска один из узлов etcd вышел из строя, кворум распался, и приложения перестали читать конфигурации. Часть сервисов осталась работать на устаревших значениях, а восстановление растянулось на четыре часа: состояние собирали из суточного бэкапа и правок, сделанных прямо на живых узлах, сверяя ключи вручную. Разбираем, что изменили в работе с хранилищем.
Что было до: ручные правки и расхождение настроек
Правки уходили напрямую в живое хранилище через клиент, минуя репозиторий и ревью. За несколько месяцев расхождения накопились: семь сервисов читали устаревшие ключи, и заметили это только по инциденту. Бэкап снимался раз в сутки и ни разу не проверялся восстановлением, а потерянный узел поднимали вручную, сопоставляя значения по логам — в среднем четыре часа простоя записи конфигураций.
Что стало после: управляемая схема и переключение узлов
Теперь состояние etcd-кластера описано декларативно и живёт в репозитории рядом с манифестами Kubernetes: изменения проходят ревью и применяются автоматически. Кворум держится на нечётном числе узлов и переживает потерю одного — вывод узла на обслуживание занимает секунды, приложения не замечают переключения.
Снапшот снимается каждые пятнадцать минут и раз в неделю проверяется полным восстановлением на тестовом контуре. Итог: расхождение ключей между узлами — ноль, восстановление узла — двенадцать минут вместо четырёх часов, переключение — меньше десяти секунд вместо сорока минут простоя.
Что делать, если хранилище уже развёрнуто в одном центре?
Работающая схема с кворумом в одном центре расширяется без пересборки кластера. Добавление узла — это присоединение нового участника к действующему кворуму: лидер сохраняет роль, запись конфигураций идёт непрерывно. Новый узел сначала получает снапшот и догоняет журнал изменений, и только потом становится голосующим.
Порядок такой: узлы вводятся по одному, между шагами проверяем отставание по журналу и отклик на чтение. Так смена топологии проходит постепенно — с трёх участников на пять в том же центре, а затем часть из них переносится на другую площадку. Данные остаются те же, меняется лишь раскладка кворума по центрам.
Миграция хранилища в другой центр идёт тем же принципом: поднимаем участник на новом месте, даём ему догнать остальных, и лишь потом выводим узел на старом. На каждом шаге большинство голосов остаётся живым, поэтому окна недоступности не возникает — сервисы продолжают читать и писать конфигурации.
Перед переключением фиксируем план: точки возврата, свежие снапшоты, допустимое отставание и порядок вывода узлов. Отдельно смотрим задержку между площадками — согласование изменений к ней чувствительно, и медленный канал способен превратить здоровый кластер в постоянно перевыбирающий лидера.
После переезда снимаем контрольные метрики: время согласования записи, стабильность лидера, объём журнала. Если значения выходят за границы, подготовленный откат на предыдущую раскладку выполняется так же без простоя.
Технические сомнения заказчиков: отказы узлов и обновления
Отказ узла в кластере конфигураций редко выглядит как мгновенная авария: приложения продолжают читать состояние, пока сохраняется кворум, а проблема всплывает позже — во время плановой замены оборудования или при попытке поднять окружение из копии. Ниже — три вопроса, которые чаще всего задают до старта работ: поведение при выпадении узла, порядок изменения состава и пригодность резервных копий.
Что произойдёт, если один узел выпадет?
Кворум — это большинство участников: в составе из трёх узлов теряется один, два голоса остаются, и запись конфигураций продолжается. Лидер переизбирается, клиентские приложения видят короткую задержку отклика, а не отказ. Состав из двух узлов кворума не даёт вовсе — выпадение любого останавливает запись, поэтому чётные схемы мы переводим на нечётные, а не «укрепляем» добавлением второго узла.
Как менять состав без простоя?
Узлы вводятся и выводятся по одному, по строгой последовательности: сначала включаем новый участник, дожидаемся, пока он догонит состояние и подтвердит готовность принимать нагрузку, и только затем выводим старый. Передачу роли лидера планируем в окно обслуживания. Адреса и роли участников описаны в конфигурации как данные — мы не правим живые узлы руками, иначе состав расходится с описанием.
Как убедиться, что резервная копия рабочая?
Снимок состояния бесполезен, пока он не восстановлен: копия проверяется разворачиванием на изолированном стенде, сверкой полноты ключей и контрольных значений с рабочим кластером. Отдельно фиксируем время восстановления — именно оно определяет, за сколько окружение поднимется после аварии. Проверку копий ставим в регулярный регламент, а сами копии храним за пределами площадки, где работает кластер.
Обсудим задачу: вернёмся с оценкой и планом работ
Чтобы оценка опиралась на факты, а не на средние значения по отрасли, нам нужны исходные данные по вашему контуру. Опишите задачу в свободной форме — уточним недостающее и вернёмся с оценкой, планом работ и порядком шагов.
Что запрашиваем для расчёта:
- текущую схему размещения узлов etcd: сколько машин, как разнесены по зонам доступности, отдельные ли диски под журнал;
- чем сейчас управляются конфигурации приложений и как они доставляются на узлы;
- профиль нагрузки: число ключей, доля операций записи против чтения, пиковые периоды;
- требования к доступности — какое окно недоступности одного узла допустимо, кто инициирует обслуживание;
- как устроено резервное копирование и когда последний раз проверяли восстановление из копии;
- ограничения по доступам, сертификатам, сегментации сети и регламенту изменений;
- кто со стороны заказчика принимает работы и по каким критериям.
Дальше порядок шагов такой: разбор текущей схемы и узких мест, план работ с этапами и точками контроля, согласование окна изменений, внедрение с проверкой на отказ узла, передача конфигураций, схемы и регламента обслуживания. Опишите задачу — вернёмся с планом и сроками.
