Потеря quorum и runbooks

После модуля вы распознаете потерю manager quorum, отделите control plane от data plane и выберете между возвратом исходных managers и disaster recovery.

• считать majority
• проверять Raft write
• не путать stale reads с quorum
• следовать runbook без импровизации

Три managers требуют два голоса. При потере двух оставшийся manager не может подтвердить Raft write, выбрать новый leader или выполнять reconciliation. Некоторые read-only команды возвращают локально известное состояние и не доказывают наличие quorum.

Уже запущенные containers продолжают работать автономно. Это временная работа data plane: task failure не будет надёжно компенсирован без control plane.

Первый выбор — вернуть хотя бы один исходный manager с его Raft identity и state. Это восстанавливает majority и сохраняет историю без изменения cluster ID.

Force-new-cluster применяют только когда majority исходных managers потеряно безвозвратно и есть выбранный surviving state либо backup. Он создаёт новую конфигурацию Raft из одного manager; старые managers нельзя возвращать как прежних членов.

Объявите incident, заморозьте изменения, подтвердите число живых voters, восстановите сеть, питание, disk или Engine исходных managers. Перед DR докажите необратимость потери majority, выберите самый свежий state и изолируйте старые managers.

Fencing предотвращает появление двух control planes. После DR заново присоединяют nodes, ротируют tokens, проверяют services, configs, secrets, networks и application data.

• Снимите baseline
• Останавливайте followers, сохраняя SSH
• Проверяйте именно write
• Не меняйте service без quorum
• Измеряйте data-plane requests
• Возвращайте один manager, затем второй

Подтвердите три voters, leader и service 3/3.

ssh swarm-manager-3 docker node ls
ssh swarm-manager-3 docker service ls
ssh swarm-manager-3 docker service ps swarm-ingress-demo

Остановите два followers. Read может вернуть stale state, но создание config должно завершиться ошибкой или timeout, а объект не должен появиться.

ssh swarm-manager-1 sudo systemctl stop docker
ssh swarm-manager-2 sudo systemctl stop docker
sleep 15
ssh swarm-manager-3 timeout 8 docker node ls
ssh swarm-manager-3 timeout 8 docker service ls
printf 'quorum-write-probe\n' | ssh swarm-manager-3 timeout 8 docker config create swarm-m23-should-not-exist -
ssh swarm-manager-3 docker config inspect swarm-m23-should-not-exist

Два endpoints недоступны, один отвечает. Traefik исключает отказавшие backends; десять публичных запросов должны пройти при условии, что surviving task здоров.

for ip in 10.77.0.11 10.77.0.12 10.77.0.13; do curl --connect-timeout 2 --max-time 4 "http://$ip:18080/" || true; done
failures=0
for n in $(seq 1 10); do curl --fail --show-error --output /dev/null https://swarm-demo.goretskiy.pro/ || failures=$((failures+1)); done
printf 'http_failures=%s\n' "$failures"

Запуск одного исходного manager возвращает majority. После проверки верните третий и убедитесь, что probe config отсутствует.

ssh swarm-manager-2 sudo systemctl start docker
sleep 20
ssh swarm-manager-3 docker node ls
ssh swarm-manager-3 docker service ls
ssh swarm-manager-1 sudo systemctl start docker
sleep 15
ssh swarm-manager-3 docker node ls
ssh swarm-manager-3 docker service ls
ssh swarm-manager-3 'docker config rm swarm-m23-should-not-exist 2>/dev/null || true'
curl --fail --show-error --output /dev/null https://swarm-demo.goretskiy.pro/

• reads работают, writes нет — нет quorum
• нет leader после возврата — проверяйте 2377/TCP, time и state
• HTTP работает без quorum — не объявляйте cluster healthy
• HTTP упал — surviving task или ingress path недоступен

• Сколько голосов нужно из трёх?
• Почему read не доказывает quorum?
• Что происходит с running tasks?
• Когда выбирать force-new-cluster?
• Зачем fencing?
• Что проверить после DR?

Модуль освоен, если Raft write отказал без quorum, 10 запросов прошли через surviving data plane, а возврат исходного voter восстановил writes и все три managers. Recover-команды являются cleanup.