Docker Swarm napříč třemi kontinenty: vysoká dostupnost navržená pro 100% uptime

Server v jednom datovém centru je jediným bodem selhání, ať jsou hardware a síť sebelepší. Když lokalita vypadne, třeba kvůli poruše napájení nebo sítě, nebo prostě kvůli chybě při údržbě, aplikace je pryč. Docker Swarm napříč několika datovými centry řeší právě tento problém: kontejnery běží ve třech nezávislých lokalitách, v ideálním případě na třech kontinentech, a když jedna z nich úplně vypadne, zastoupí ji zbylé dvě, aniž by si toho uživatelé všimli.

Tento článek krok za krokem ukazuje, jak postavit cluster Docker Swarm navržený pro 100% uptime: po jednom serveru v Severní Americe, Evropě a Asii, šifrovaná síť WireGuard mezi uzly, kvórum manažerů, které přežije výpadek celého kontinentu, jeden vstupní bod na region a DNS failover, který uživatele automaticky přesměruje do nejbližší funkční lokality. Poctivě také vysvětlíme, co může i při této architektuře stále selhat a jak podchytit i tato rizika.

Lze s Docker Swarmem dosáhnout 100% uptime?

Docker Swarm napříč třemi kontinenty je navržený pro 100% uptime: žádný jednotlivý server, žádné jednotlivé datové centrum ani žádný jednotlivý kontinent nemůže sám o sobě aplikaci zastavit. Absolutní dostupnost přesto nemůže zaručit nikdo, ani velcí poskytovatelé cloudu, jejichž nejvyšší přísliby se pohybují mezi 99,99 a 99,999 %. Důvodem nejsou datová centra, ale věci, které mají všechny lokality společné. Tento článek se zabývá i jimi, abyste se ke 100 % dostali tak blízko, jak je to technicky možné.

Co znamená dostupnost v číslech

Výpočet vychází z 8 760 hodin ročně a 730 hodin měsíčně. Každá další devítka zkrátí povolenou dobu výpadku na desetinu a právě tady začíná práce, kterou jediný server už nezvládne.

Proč tři kontinenty tolik pomáhají

Tři na sobě nezávislé lokality, každá s dostupností 99,9 %, vypadnou matematicky vzato současně jen tehdy, když mají poruchu všechny tři ve stejnou chvíli: 0,1 % krát 0,1 % krát 0,1 % dává 0,0000001 %. Čím dál od sebe lokality leží, tím nezávislejší ve skutečnosti jsou: vlastní elektrické sítě, vlastní síťová konektivita, vlastní povětrnostní podmínky, vlastní servisní okna. Proto je rozložení mezi Severní Ameriku, Evropu a Asii nejsilnější formou odolnosti proti výpadkům, jakou lze se servery vybudovat.

Co může vypadnout i při třech kontinentech

Zbývající rizika tvoří společné závislosti všech lokalit a pro každou z nich existuje protiopatření:

• Chybnou aktualizaci rozešle cluster do všech lokalit stejně spolehlivě jako tu dobrou. Protiopatření: health checky a automatický rollback, k tomu aktualizace region po regionu.
• DNS je jediné místo, přes které přicházejí všichni uživatelé. Protiopatření: poskytovatel DNS s celosvětově distribuovanou sítí a failoverem, krátké TTL.
• Databáze musí mít ve všech lokalitách stejná data. Protiopatření: replikace s automatickým přepnutím, viz oddíl o datech.
• Certifikáty a domény s prošlou platností zasáhnou všechny lokality současně. Protiopatření: automatické obnovování a sledování dat vypršení platnosti.
• Samotné přepnutí trvá, dokud nezareagují health checky a DNS, obvykle jednu až dvě minuty, během nichž mohou jednotlivé požadavky selhat. Protiopatření: krátké intervaly kontrol, krátké TTL a klienti, kteří neúspěšné požadavky zopakují.

Přehled architektury

Docker Swarm napříč několika kontinenty se skládá ze šesti stavebních prvků. Každý z nich odstraňuje určitý bod selhání:

Kolik manažerů a kde?

Manažerské uzly Swarmu spravují stav clusteru pomocí konsenzuálního algoritmu Raft. Každá změna potřebuje souhlas většiny manažerů, takzvaného kvóra. Když se většina ztratí, stávající kontejnery sice běží dál, ale cluster nedokáže znovu plánovat, vyrovnávat výpadky ani rozesílat aktualizace.

Docker doporučuje lichý počet manažerů a jejich rozložení alespoň do tří zón, u tří manažerů v poměru 1-1-1, u pěti v poměru 2-2-1. Z toho plyne nejdůležitější pravidlo tohoto článku: Dvě lokality nestačí. Při dvou lokalitách je v jedné z nich nutně více manažerů. Když vypadne právě ta, většina je pryč. Teprve se třemi lokalitami přežije kvórum výpadek libovolného datového centra, u tří kontinentů tedy výpadek celého kontinentu.

Tři kontinenty, nebo jeden kontinent: co zvážit

Každá změna v clusteru, každé nasazení a každé přeplánování kontejneru čeká na potvrzení od většiny manažerů. Mezi Evropou, Severní Amerikou a Asií zabere každé takové potvrzení dobu přenosu paketu, zhruba 80 až 250 milisekund. Pro uživatele to nehraje roli, protože jejich požadavky se vyřizují lokálně; nasazení a přeplánování ale trvají znatelně déle než v clusteru s krátkými cestami.

Pro aplikace s uživateli na několika kontinentech a s cílem co nejvyšší dostupnosti je správnou volbou varianta se třemi kontinenty a tu v návodu postavíme. Důležité je přitom pravidlo, které se táhne všemi kroky: každý požadavek se vyřídí ve svém regionu a nikdy necestuje tam a zpět mezi kontinenty.

Které lokality KernelHost se hodí

KernelHost provozuje servery v datovém centru maincubes ve Frankfurtu nad Mohanem a nabízí virtuální servery v dalších lokalitách v Evropě, Severní Americe a Asii a Pacifiku, mimo jiné ve třech lokalitách v USA, v Kanadě, Londýně, Štrasburku, Varšavě, Helsinkách, Singapuru, Japonsku, Sydney a Mumbai. Úplný seznam s mapou najdete na stránce Umístění serverů. Pro příklad v tomto článku použijeme Frankfurt nad Mohanem pro Evropu, východní pobřeží USA pro Severní Ameriku a Singapur pro Asii.

Návod: jak postavit Docker Swarm napříč třemi kontinenty

V příkladu použijeme tři servery: swarm-eu ve Frankfurtu nad Mohanem, swarm-us na východním pobřeží USA a swarm-asia v Singapuru. Veřejné adresy pocházejí ze sítě vyhrazené pro dokumentaci 203.0.113.0/24, síť WireGuard používá 10.10.0.0/24. Obojí nahraďte svými hodnotami. Všechny tři uzly jsou zároveň manažery i workery; pro vyšší výkon později v každém regionu doplníte uzly, které budou jen workery.

Krok 1: zřídit servery na třech kontinentech

Objednejte tři servery s Debianem 12 nebo 13 ve třech regionech a proveďte základní zabezpečení: SSH jen s klíčem, automatické bezpečnostní aktualizace, vlastní uživatelé. To vše pokrývá checklist pro nové root servery. Zvolte výstižné názvy hostitelů, abyste v docker node ls hned viděli, který uzel kde stojí.

hostnamectl set-hostname swarm-eu

Krok 2: nainstalovat Docker na všechny uzly

Nainstalujte Docker Engine z oficiálního repozitáře Dockeru na všechny tři servery, jak popisuje článek Instalace Dockeru na Debianu a Ubuntu. Poté na každém uzlu zkontrolujte verzi, všechny tři by měly mít stejnou hlavní verzi:

docker version --format '{{.Server.Version}}'

Krok 3: vybudovat síť WireGuard mezi kontinenty

Uzly spolu komunikují přes veřejný internet. Aby byl veškerý provoz clusteru šifrovaný a porty Swarmu nikdy nebyly veřejně dostupné, jsou tři servery propojené sítí WireGuard. Na každém uzlu nejprve vygenerujte pár klíčů:

apt-get install -y wireguard
umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key

Poté dostane každý uzel soubor /etc/wireguard/wg0.conf. Na swarm-eu vypadá takto, oba další uzly jsou nastavené zrcadlově:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = SOUKROMY_KLIC_SWARM_EU
MTU = 1420

[Peer]
PublicKey = VEREJNY_KLIC_SWARM_US
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

[Peer]
PublicKey = VEREJNY_KLIC_SWARM_ASIA
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.10.0.3/32
PersistentKeepalive = 25

systemctl enable --now wg-quick@wg0
ping -c 3 10.10.0.2

Pokud všechny uzly odpovídají na svých adresách 10.10.0.x, síť funguje. PersistentKeepalive udržuje spojení otevřené i za stavovými firewally. Doby odezvy, které teď ping mezi kontinenty ukazuje, jsou přesně tím čekáním, které stojí každá změna v clusteru.

Krok 4: firewall propustí dovnitř jen uzly Swarmu

Docker Swarm potřebuje mezi uzly port 2377/TCP pro správu clusteru, 7946/TCP a UDP pro vzájemnou komunikaci uzlů a 4789/UDP pro overlay síť. Tyto porty povolte výhradně na rozhraní WireGuard, veřejně zůstává otevřený jen samotný WireGuard, a to pouze pro ostatní uzly. S ufw to na swarm-eu vypadá takto:

ufw allow from 203.0.113.12 to any port 51820 proto udp
ufw allow from 203.0.113.13 to any port 51820 proto udp
ufw allow in on wg0 to any port 2377 proto tcp
ufw allow in on wg0 to any port 7946
ufw allow in on wg0 to any port 4789 proto udp

Důležité: porty, které Docker publikuje pro kontejnery, obcházejí ufw, protože Docker nastavuje vlastní pravidla iptables. Publikujte proto jen porty vstupního bodu (80 a 443) a nikdy porty databází nebo správy.

Krok 5: inicializovat Swarm a přidat manažery

Na swarm-eu inicializujte Swarm a zajistěte, aby správa i datový provoz běžely přes WireGuard:

docker swarm init --advertise-addr 10.10.0.1 --data-path-addr 10.10.0.1
docker swarm join-token manager

Druhý příkaz vypíše příkaz pro připojení dalších manažerů. Na swarm-us a swarm-asia ho spusťte, pokaždé s vlastní adresou WireGuard daného uzlu, zde pro swarm-us:

docker swarm join --token SWMTKN-1-... --advertise-addr 10.10.0.2 --data-path-addr 10.10.0.2 10.10.0.1:2377
docker node ls

docker node ls pak ukáže tři uzly, jeden se stavem Leader a zbylé dva se stavem Reachable. Token pro připojení je tajemství: kdo ho zná, může do vašeho clusteru propašovat vlastního manažera. Po sestavení clusteru ho obnovte příkazem docker swarm join-token --rotate manager.

Krok 6: aktivovat autolock

Manažeři ukládají stav clusteru včetně klíčů, kterými jsou šifrované logy Raftu, do /var/lib/docker/swarm/. S autolockem se šifrují i samotné tyto klíče a restartovaný manažer se ke clusteru znovu připojí až po zadání odemykacího klíče:

docker swarm update --autolock=true
docker swarm unlock

První příkaz vypíše odemykací klíč, který si uložte do správce hesel. Druhý potřebujete po každém restartu manažera. Bez klíče nelze Swarm obnovit ani ze zálohy, proto ho uchovávejte odděleně od serverů.

Krok 7: označit uzly podle regionu

Labely sdělují plánovači, kde uzel stojí. Na nich stavějí pravidla umístění v dalších krocích:

docker node update --label-add region=eu swarm-eu
docker node update --label-add region=us swarm-us
docker node update --label-add region=asia swarm-asia

Krok 8: vytvořit overlay síť s vhodnou MTU

Kontejnery v různých lokalitách spolu komunikují přes overlay síť. Protože vede tunelem WireGuard, musí mít menší MTU: WireGuard pracuje s 1420 bajty, overlay síť (VXLAN) z nich potřebuje 50 bajtů na vlastní hlavičky, zbývá tedy 1370 bajtů:

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1370 appnet

Příliš velká MTU se projevuje záludně: malé požadavky fungují, velké odpovědi se zaseknou. Kdo se WireGuardu vzdá, může overlay síť místo toho šifrovat pomocí --opt encrypted; pak musí být mezi uzly navíc povolený IP protokol 50 (ESP) a Docker výslovně upozorňuje na znatelný pokles výkonu. Doporučujeme WireGuard, protože pokrývá veškerý provoz včetně správy.

Krok 9: provozovat aplikaci v každém regionu

Běžná služba Swarmu rozesílá požadavky přes svou adresu služby na všechny repliky v clusteru, tedy i na ostatní kontinenty. Při třech kontinentech by tak každý druhý nebo třetí požadavek cestoval přes půl světa. Proto dostane každý region vlastní službu, která díky pravidlu umístění zůstává ve svém regionu. Nastavení aktualizací zajistí, že se nové verze nasazují kontejner po kontejneru a při chybách se automaticky vrátí zpět:

for r in eu us asia; do
  docker service create --name web-$r --replicas 2 --network appnet \
    --constraint node.labels.region==$r \
    --update-parallelism 1 --update-delay 30s \
    --update-failure-action rollback \
    registry.example.com/web:1.0
done

Aby Swarm poznal, zda kontejner skutečně pracuje, a ne jen běží, patří do image health check, například tento řádek v Dockerfile vaší aplikace:

HEALTHCHECK --interval=10s --timeout=3s --retries=3 CMD wget -qO- http://127.0.0.1:8080/health || exit 1

Kontejner, jehož health check třikrát po sobě selže, se nahradí a během aktualizace selhávající health check zastaví nasazování.

Krok 10: jeden vstupní bod na region

Roli vstupního bodu přebírá reverse proxy, například Caddy, Traefik nebo nginx. I ta běží v každém regionu jako samostatná služba a předává požadavky jen aplikaci ve svém regionu. V režimu host publikuje porty 80 a 443 přímo na serveru svého regionu. Stačí jedna společná konfigurace, protože Caddy čte cíl z proměnné prostředí:

example.com {
    reverse_proxy {$UPSTREAM}:80
}

docker config create caddyfile ./Caddyfile
for r in eu us asia; do
  docker service create --name edge-$r --network appnet \
    --constraint node.labels.region==$r \
    --env UPSTREAM=web-$r \
    --config source=caddyfile,target=/etc/caddy/Caddyfile \
    --publish mode=host,target=80,published=80 \
    --publish mode=host,target=443,published=443 \
    caddy:2
done

Všechny regiony potřebují certifikát TLS pro stejnou doménu. Certifikáty proto získávejte přes DNS challenge, která funguje bez ohledu na to, na který region záznam DNS právě ukazuje; Caddy k tomu potřebuje modul vašeho poskytovatele DNS. Základní informace o proxy najdete v článku Nastavení nginx jako reverse proxy.

Krok 11: nastavit Geo-DNS s failoverem

Poslední stavební prvek vede uživatele do správného regionu. Služba DNS s geo-routingem a health checky posílá uživatele z Evropy do Frankfurtu nad Mohanem, z Ameriky na východní pobřeží USA a z Asie do Singapuru. Když region vypadne, health check to rozpozná během 30 až 60 sekund a pošle jeho uživatele do nejbližšího funkčního regionu. Nastavte dobu platnosti (TTL) záznamů na 60 sekund, aby resolvery změnu rychle převzaly. Několik záznamů typu A bez health checku je jen nouzové řešení: prohlížeče sice často zkusí další adresu, ale ne každý klient to dělá a vypadlý region v odpovědi zůstává.

Počítejte poctivě: mezi výpadkem a přepnutím uplyne interval kontroly plus TTL, v příkladu tedy jedna až dvě minuty, během nichž část uživatelů postiženého regionu stále míří na vypadlou lokalitu. Aplikace a mobilní aplikace, které neúspěšné požadavky po krátké pauze zopakují, tento čas překlenou téměř bez povšimnutí.

Krok 12: otestovat výpadek regionu

Failover, který nikdy nebyl vyzkoušen, ve skutečné krizi funguje jen zřídka. Simulujte výpadek regionu tak, že jeho uzel vyřadíte z provozu, a sledujte, jak zareagují cluster a DNS:

docker node update --availability drain swarm-asia
docker node ls
docker service ls
docker node update --availability active swarm-asia

Protože jsou služby regionu pravidlem umístění vázané na svůj uzel, nepřesunou se, ale pozastaví se; uživatele regionu převezme DNS failover. V tomto testu proto kontrolujte hlavně to, zda health check vyřadí region z odpovědí a zda sousední region unese dodatečnou zátěž. Pro tvrdší test uzel úplně odpojte od sítě, například zastavením WireGuardu. Test opakujte po větších změnách a nejméně jednou za čtvrtletí.

Data: nejtěžší část vysoké dostupnosti

Docker Swarm replikuje kontejnery, ne data. Volume je vždy uložené na uzlu, na kterém běží kontejner. Bezstavové služby, jako jsou webové frontendy a API, proto můžete bez problémů provozovat v každém regionu; pro vše, co pracuje s daty, potřebujete vlastní replikaci.

Replikace databází mezi kontinenty

Databáze mají vlastní replikaci a ta je vždy lepší volbou než sdílené úložiště napříč datovými centry. Mezi kontinenty se osvědčila primární instance v jednom regionu s asynchronními replikami ve zbylých dvou, u PostgreSQL například přes streaming replication s nástrojem jako Patroni pro automatické přepnutí, u MariaDB a MySQL přes vestavěnou replikaci. Požadavky na čtení pak každý region vyřizuje lokálně, zápisy jdou na primární instanci. Asynchronní ale upřímně řečeno znamená také: pokud vypadne primární region, mohou chybět zápisy z posledních sekund. Kdo chce zapisovat celosvětově a nic neztratit, sáhne po databázích stavěných pro více regionů, například CockroachDB nebo YugabyteDB. Databázové uzly pevně svažte pravidlem umístění s jejich regionem, aby je Swarm nikdy nepřesunul bez jejich dat:

docker service create --name db-asia --constraint node.labels.region==asia ...

Soubory a uploady

Nahrané soubory nepatří do lokálního volume, ale do objektového úložiště kompatibilního se S3, které se replikuje do druhého regionu, nebo do vlastního replikovaného úložného systému. Síťové souborové systémy jako NFS napříč kontinenty jsou pomalé a samy o sobě představují jediný bod selhání.

Relace a cache

Pokud aplikace ukládá relace do paměti kontejneru, uživatelé při přepnutí přijdou o přihlášení. Ukládejte relace do replikované databáze nebo replikované cache, jako je Redis, nebo používejte podepsané tokeny, které si každý region dokáže ověřit sám.

Zálohy zůstávají povinností

Replikace chrání před výpadkem lokality, ale ne před chybami: omylem smazaný záznam je o několik sekund později smazaný ve všech regionech. Proto ke každé vysoce dostupné architektuře patří pravidelné a otestované zálohy na nezávislém místě, jak popisuje článek Zálohovací strategie pro servery.

Provoz: aktualizace, údržba a monitoring

Aktualizace region po regionu

Nové verze nenasazujte ve všech regionech současně, ale postupně, a každý region chvíli sledujte, než přijde na řadu další. Chyba, kterou žádný health check nerozpozná, tak zasáhne nanejvýš jeden region a zbylé dva dál obslouží jeho uživatele:

for r in asia us eu; do
  docker service update --image registry.example.com/web:1.1 web-$r || break
  sleep 300
done

Pokud aktualizace selže, Swarm ji díky nastavení z kroku 9 automaticky vrátí zpět a || break ukončí smyčku, jakmile příkaz ohlásí chybu. Aktualizaci, u které se problém projeví až později, vrátíte ručně pomocí docker service rollback web-asia.

Údržba regionu

Když je potřeba server restartovat nebo aktualizovat, vyřaďte ho z provozu pomocí docker node update --availability drain a nechte DNS failover předem přesměrovat jeho uživatele do sousedních regionů. Po údržbě ho pomocí --availability active znovu zapojte. S dalším manažerem počkejte, dokud docker node ls znovu neukáže všechny tři jako dostupné, aby nikdy nechyběli dva manažeři současně.

Monitoring zvenčí

Monitorujte každý region zvlášť, a to z místa mimo cluster: dostupnost vstupních bodů, health checky služeb, stav manažerů, zpoždění replikace databáze a data vypršení platnosti certifikátů a domén. Alarm musí dorazit i tehdy, když celý region mlčí. Jak to nastavit pro jednotlivé servery, ukazuje článek Nastavení monitoringu serveru.

Bezpečná distribuce tajemství

Hesla a klíče nepatří do proměnných prostředí ani do souborů Compose, ale do Docker Secrets. Ukládají se šifrovaně v logu Raftu a doručují se jen těm službám, kterým je výslovně přidělíte:

printf '%s' 'VASE_HESLO_K_DATABAZI' | docker secret create db_password -
docker service update --secret-add db_password web-eu

Proč KernelHost pro Swarm napříč několika kontinenty

Cluster napříč několika kontinenty klade na poskytovatele jiné nároky než jednotlivý server. V praxi rozhodují tyto body:

Přehled všech cloudových tarifů s cenami a srovnání nákladů s velkými poskytovateli cloudu najdete na stránce Pronájem cloud serveru.

Časté chyby a jak se jim vyhnout

• Manažeři jen ve dvou lokalitách. Když vypadne lokalita s většinou, cluster se zastaví. Řešení: tři lokality, rozložení 1-1-1 nebo 2-2-1.
• Sudý počet manažerů. Čtyři manažeři nezvládnou víc výpadků než tři, ale zvyšují režii při hlasování. Řešení: 3, 5 nebo 7.
• Požadavky cestují mezi kontinenty. Jedna adresa služby pro všechny regiony posílá uživatele přes půl světa. Řešení: jedna služba a jeden vstupní bod na region.
• Porty Swarmu veřejně dostupné. Port 2377 a overlay síť nikdy nepatří do otevřeného internetu. Řešení: jen přes WireGuard, veřejně jen 80, 443 a WireGuard pro ostatní uzly.
• Zapomenutá MTU. Velké odpovědi se zasekávají, malé fungují. Řešení: MTU overlay sítě 1370 při WireGuardu s 1420.
• Spoléhání na ufw u portů kontejnerů. Docker u publikovaných portů ufw obchází. Řešení: publikovat jen vstupní bod.
• Databáze ve volume bez replikace. Když region vypadne, data nejsou dostupná. Řešení: replikace databáze, umístění pevně svázané s regionem.
• Aktualizace ve všech regionech současně. Chyba pak zasáhne všechny uživatele na celém světě. Řešení: nasazovat region po regionu.
• Vysoké TTL v DNS. S TTL o délce jednoho dne se failover projeví až další den. Řešení: 60 sekund.
• Replikace místo zálohy. Chyba se replikuje stejně jako správná data. Řešení: navíc otestované zálohy na nezávislém místě.

Stručné shrnutí

• Docker Swarm napříč třemi kontinenty je navržený pro 100% uptime: celá lokalita nebo celý kontinent smí vypadnout, aniž by se aplikace zastavila.
• Absolutní dostupnost nemůže zaručit nikdo, zbývající rizika jsou DNS, chybné aktualizace, databáze a certifikáty, a pro každé z nich existuje protiopatření.
• Tři manažeři ve třech lokalitách jsou minimum, dvě lokality na kvórum odolné proti výpadkům nestačí.
• Každý požadavek zůstává ve svém regionu: jedna služba a jeden vstupní bod na region, k tomu Geo-DNS s health checky a krátkým TTL.
• WireGuard šifruje provoz clusteru, porty Swarmu zůstávají neviditelné, MTU overlay sítě klesá na 1370.
• Swarm replikuje kontejnery, ne data: databáze potřebují vlastní replikaci a zálohy zůstávají povinností.
• KernelHost nabízí lokality v Evropě, Severní Americe a Asii a Pacifiku, neomezený provoz, ochranu proti DDoS v každé lokalitě a vyúčtování PrePaid bez minimální doby trvání.