Втрата quorum і runbooks

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

• рахувати majority
• перевіряти Raft write
• не плутати stale reads із quorum
• виконувати runbook

Три managers потребують два votes. За втрати двох останній manager не може підтвердити Raft write, обрати leader або виконувати reconciliation. Деякі reads повертають local state і не доводять quorum.

Running containers продовжують працювати, але task failure не буде надійно компенсовано без control plane.

Спочатку поверніть хоча б один original manager з його Raft identity та state. Це відновлює majority без зміни cluster ID.

Force-new-cluster застосовують лише за безповоротної втрати majority. Він формує нову Raft configuration; старі managers не повертають як попередніх members.

Оголосіть incident, заморозьте changes, перевірте voters, відновіть network, power, disk або Engine. Перед DR доведіть втрату majority, оберіть найсвіжіший state та ізолюйте старі managers.

Fencing запобігає двом control planes. Після DR rejoin nodes, rotate tokens і перевірте objects та application data.

• Зніміть baseline
• Stop followers зі збереженням SSH
• Перевіряйте write
• Не змінюйте service без quorum
• Вимірюйте 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 create має помилку або timeout і object не виникає.

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 не працюють, один відповідає. Десять public requests проходять, якщо surviving task healthy.

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"

Один original 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 працює — cluster ще не healthy
• HTTP впав — task або ingress path

• Скільки votes потрібно?
• Чому read не доводить quorum?
• Що з running tasks?
• Коли force-new-cluster?
• Навіщо fencing?
• Що перевірити після DR?

Модуль засвоєно, якщо write відмовив, 10 requests пройшли, а повернення voter відновило quorum і всі managers. Recover commands є cleanup.