Docker Swarm három kontinensen: magas rendelkezésre állás, 100%-os uptime-ra tervezve

Egy adatközpontban működő szerver egyetlen hibapont, akármilyen jó is a hardver és a hálózat. Ha a helyszín kiesik, például áramellátási vagy hálózati zavar miatt, vagy egyszerűen egy karbantartás közben elkövetett hiba következtében, az alkalmazás is elérhetetlenné válik. A több adatközpontra kiterjedő Docker Swarm pontosan ezt a problémát oldja meg: a konténerek három független helyszínen futnak, ideális esetben három kontinensen, és ha ezek közül az egyik teljesen kiesik, a másik kettő veszi át a helyét, anélkül, hogy a felhasználók bármit észrevennének.

Ez a cikk lépésről lépésre bemutatja, hogyan építhet fel egy 100%-os rendelkezésre állásra tervezett Docker Swarm-klasztert: egy-egy szerver Észak-Amerikában, Európában és Ázsiában, titkosított WireGuard-hálózat a csomópontok között, egy teljes kontinens kiesését is túlélő manager-kvórum, régiónként egy belépési pont, valamint egy DNS-failover, amely a felhasználókat automatikusan a legközelebbi egészséges helyszínre irányítja. Őszintén elmagyarázzuk azt is, mi eshet ki még ennél az architektúránál is, és hogyan háríthatja el ezeket a kockázatokat is.

Elérhető-e 100%-os uptime a Docker Swarmmal?

Egy három kontinensre kiterjedő Docker Swarm 100%-os rendelkezésre állásra tervezett rendszer: egyetlen szerver, egyetlen adatközpont és egyetlen kontinens sem tudja egymagában leállítani az alkalmazást. Abszolút rendelkezésre állást ennek ellenére senki sem tud garantálni, még a nagy felhőszolgáltatók sem, amelyek legmagasabb vállalásai 99,99 és 99,999% között mozognak. Ennek oka nem az adatközpontokban keresendő, hanem azokban a dolgokban, amelyek minden helyszínen közösek. Ez a cikk éppen ezekkel is foglalkozik, hogy a technikailag lehetséges mértékben megközelíthesse a 100%-ot.

Mit jelent a rendelkezésre állás számokban

A számítás évi 8760 órával és havi 730 órával készült. Minden további kilences a tizedére csökkenti a megengedett leállási időt, és pontosan itt kezdődik az a munka, amelyet egyetlen szerver már nem tud elvégezni.

Miért jelent ekkora különbséget három kontinens

Három, egymástól független, egyenként 99,9%-os rendelkezésre állású helyszín számítás szerint csak akkor esik ki egyszerre, ha mindhárom helyszínen egy időben lép fel zavar: a 0,1%, 0,1% és 0,1% szorzata 0,0000001%. Minél távolabb vannak egymástól a helyszínek, annál függetlenebbek ténylegesen: saját áramhálózatok, saját hálózati bekötések, saját időjárási viszonyok, saját karbantartási ablakok. Ezért az Észak-Amerikára, Európára és Ázsiára kiterjedő elosztás a hibatűrés legerősebb formája, amely szerverekkel megvalósítható.

Mi eshet ki még három kontinens esetén is

A fennmaradó kockázatok az összes helyszín közös függőségei, és mindegyikre létezik ellenintézkedés:

• Egy hibás frissítést a klaszter ugyanolyan megbízhatóan juttat el minden helyszínre, mint egy jót. Ellenintézkedés: állapotellenőrzések és automatikus visszaállítás, emellett régióról régióra haladó frissítések.
• A DNS az az egyetlen pont, amelyen minden felhasználó áthalad. Ellenintézkedés: világszerte elosztott hálózattal és failoverrel rendelkező DNS-szolgáltató, rövid TTL.
• Az adatbázisnak minden helyszínen ugyanazokat az adatokat kell tartalmaznia. Ellenintézkedés: replikáció automatikus átkapcsolással, lásd az adatokról szóló részt.
• A lejárt tanúsítványok és domainek egyszerre érintik az összes helyszínt. Ellenintézkedés: automatikus megújítás és a lejárati dátumok figyelése.
• Maga az átkapcsolás addig tart, amíg az állapotellenőrzések és a DNS reagálnak, ez többnyire egy-két perc, amely alatt egyes kérések meghiúsulhatnak. Ellenintézkedés: rövid ellenőrzési időközök, rövid TTL és olyan kliensek, amelyek megismétlik a sikertelen kéréseket.

Az architektúra áttekintése

Egy több kontinensre kiterjedő Docker Swarm hat építőelemből áll. Mindegyik egy-egy konkrét hibapontot szüntet meg:

Hány manager kell, és hol?

Egy Swarm manager-csomópontjai a Raft-konszenzusalgoritmussal kezelik a klaszter állapotát. Minden változtatáshoz a managerek többségének, az úgynevezett kvórumnak a jóváhagyása szükséges. Ha a többség kiesik, a meglévő konténerek ugyan tovább futnak, de a klaszter sem újraütemezni, sem a kieséseket kiegyenlíteni, sem frissítéseket kiosztani nem tud.

A Docker páratlan számú managert javasol, legalább három zónára elosztva: három managernél 1-1-1, ötnél 2-2-1 arányban. Ebből következik a cikk legfontosabb szabálya: két helyszín nem elég. Két helyszín esetén az egyiken szükségszerűen több manager van, és ha éppen az esik ki, elvész a többség. Csak három helyszínnel éli túl a kvórum bármelyik adatközpont kiesését, három kontinens esetén tehát egy teljes kontinens kiesését is.

Három kontinens vagy egy kontinens: a mérlegelés

A klaszter minden módosítása, minden deployment és egy konténer minden újraütemezése a managerek többségének megerősítésére vár. Európa, Észak-Amerika és Ázsia között minden ilyen megerősítés nagyjából 80 és 250 ezredmásodperc közötti csomagfutási időt vesz igénybe. A felhasználók számára ez lényegtelen, mert a kéréseikre helyben kapnak választ; a deploymentek és az átütemezések azonban érezhetően tovább tartanak, mint egy rövid hálózati utakkal rendelkező klaszterben.

Ha az alkalmazás felhasználói több kontinensen vannak, és a cél a lehető legnagyobb rendelkezésre állás, akkor a három kontinensre kiterjedő változat a helyes választás, és az útmutatóban ezt építjük fel. Ennek során fontos egy szabály, amely minden lépésen végigvonul: minden kérés a saját régiójában kap választ, és soha nem utazik oda-vissza a kontinensek között.

Mely KernelHost-helyszínek alkalmasak

A KernelHost a Frankfurt am Main-i maincubes adatközpontban üzemeltet szervereket, és további helyszíneken is kínál virtuális szervereket Európában, Észak-Amerikában, valamint Ázsiában és a csendes-óceáni térségben, többek között három helyszínen az USA-ban, továbbá Kanadában, Londonban, Strasbourgban, Varsóban, Helsinkiben, Szingapúrban, Japánban, Sydneyben és Mumbaiban. A teljes lista térképpel a Szerverhelyszínek oldalon található. A cikk példájában Európához Frankfurt am Maint, Észak-Amerikához az USA keleti partját, Ázsiához pedig Szingapúrt használjuk.

Útmutató: Docker Swarm felépítése három kontinensen

A példa három szervert használ: swarm-eu Frankfurt am Mainban, swarm-us az USA keleti partján és swarm-asia Szingapúrban. A nyilvános címek a 203.0.113.0/24 dokumentációs tartományból származnak, a WireGuard-hálózat a 10.10.0.0/24 tartományt használja. Mindkettőt cserélje le a saját értékeire. Mindhárom csomópont egyszerre manager és worker; nagyobb teljesítményhez később minden régióban tisztán worker szerepű csomópontokkal bővítheti a klasztert.

1. lépés: Szerverek üzembe helyezése három kontinensen

Rendeljen meg három szervert Debian 12-vel vagy 13-mal három régióban, és végezze el az alapvető megerősítést: SSH csak kulccsal, automatikus biztonsági frissítések, saját felhasználók. Ezt az új root szerverek ellenőrzőlistája lefedi. Adjon beszédes hostneveket a szervereknek, hogy a docker node ls kimenetében azonnal lássa, melyik csomópont hol található.

hostnamectl set-hostname swarm-eu

2. lépés: A Docker telepítése az összes csomópontra

Telepítse a Docker Engine-t a Docker hivatalos csomagtárolójából mindhárom szerverre, ahogyan a Docker telepítése Debianra és Ubuntura című cikk leírja. Ezután minden csomóponton ellenőrizze a verziót; mindhárom szerveren ugyanannak a főverziónak kellene futnia:

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

3. lépés: WireGuard-hálózat kiépítése a kontinensek között

A csomópontok a nyilvános interneten keresztül kommunikálnak egymással. Ahhoz, hogy a teljes klaszterforgalom titkosított legyen, a Swarm-portok pedig soha ne legyenek nyilvánosan elérhetők, egy WireGuard-hálózat köti össze a három szervert. Először minden csomóponton hozzon létre egy kulcspárt:

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

Ezután minden csomópont kap egy /etc/wireguard/wg0.conf fájlt. A swarm-eu csomóponton így néz ki, a másik két csomópont tükörképszerűen épül fel:

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

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

[Peer]
PublicKey = SWARM_ASIA_NYILVANOS_KULCSA
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

Ha az összes csomópont válaszol a 10.10.0.x címeken, a hálózat működik. A PersistentKeepalive állapotkövető tűzfalak mögött is nyitva tartja a kapcsolatot. Azok a késleltetések, amelyeket a ping most a kontinensek között mutat, pontosan azok a várakozási idők, amelyekbe a klaszter minden egyes módosítása kerül.

4. lépés: Tűzfal: csak a Swarm-csomópontok juthatnak be

A Docker Swarmnak a csomópontok között a 2377/TCP portra van szüksége a klaszterkezeléshez, a 7946/TCP és UDP portra a csomópontok egymás közötti kommunikációjához, valamint a 4789/UDP portra az overlay-hálózathoz. Ezeket a portokat kizárólag a WireGuard-interfészen engedélyezze; nyilvánosan csak maga a WireGuard marad nyitva, és az is csak a többi csomópont számára. Az ufw használatával ez a swarm-eu csomóponton így néz ki:

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

Fontos: a Docker által a konténerek számára publikált portok megkerülik az ufw-t, mert a Docker saját iptables-szabályokat állít be. Ezért csak a belépési pont portjait (80 és 443) publikálja, adatbázis- vagy felügyeleti portokat soha.

5. lépés: A Swarm inicializálása és managerek hozzáadása

A swarm-eu csomóponton inicializálja a Swarmot, és gondoskodjon arról, hogy a felügyeleti és az adatforgalom is a WireGuardon keresztül haladjon:

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

A második parancs kiírja a további managerek csatlakozási parancsát. Ezt a swarm-us és a swarm-asia csomóponton futtassa, mindkettőn a saját WireGuard-címével; itt a swarm-us példája látható:

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

Ezután a docker node ls három csomópontot mutat, közülük egyet Leader, a másik kettőt Reachable állapottal. A csatlakozási token titok: aki ismeri, saját managert csempészhet be az ön klaszterébe. A kiépítés után újítsa meg a docker swarm join-token --rotate manager paranccsal.

6. lépés: Az autolock bekapcsolása

A managerek a /var/lib/docker/swarm/ könyvtárban tárolják a klaszter állapotát, azokkal a kulcsokkal együtt, amelyekkel a Raft-naplók titkosítva vannak. Az autolock magukat ezeket a kulcsokat is titkosítja, és egy újraindított manager csak egy feloldókulcs megadása után csatlakozik újra a klaszterhez:

docker swarm update --autolock=true
docker swarm unlock

Az első parancs kiírja a feloldókulcsot, amelyet tároljon el egy jelszókezelőben. A másodikra minden manager újraindítása után szüksége lesz. A kulcs nélkül a Swarm még mentésből sem állítható helyre, ezért a szerverektől elkülönítve őrizze meg.

7. lépés: A csomópontok felcímkézése régió szerint

A címkék elárulják az ütemezőnek, hol található egy csomópont. Erre épülnek a következő lépések elhelyezési szabályai:

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

8. lépés: Overlay-hálózat létrehozása megfelelő MTU-val

A különböző helyszíneken futó konténerek egy overlay-hálózaton keresztül kommunikálnak egymással. Mivel ez a WireGuard-alagúton halad át, kisebb MTU-ra van szüksége: a WireGuard 1420 bájttal dolgozik, ebből az overlay-hálózat (VXLAN) 50 bájtot a saját fejléceire használ fel, így 1370 bájt marad:

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

A túl nagy MTU alattomos módon jelentkezik: a kis kérések működnek, a nagy válaszok elakadnak. Aki lemond a WireGuardról, ehelyett a --opt encrypted kapcsolóval titkosíthatja az overlay-hálózatot; ekkor a csomópontok között az 50-es IP-protokollt (ESP) is engedélyezni kell, és a Docker kifejezetten figyelmeztet az érezhető teljesítménycsökkenésre. Mi a WireGuardot javasoljuk, mert a teljes forgalmat lefedi, a felügyeleti forgalmat is beleértve.

9. lépés: Az alkalmazás futtatása minden régióban

Egy hagyományos Swarm-szolgáltatás a szolgáltatáscímén keresztül a klaszter összes replikájára osztja el a kéréseket, vagyis a többi kontinensen futókra is. Három kontinens esetén így minden második vagy harmadik kérés a fél világon át utazna. Ezért minden régió saját szolgáltatást kap, amelyet egy elhelyezési szabály a saját régiójában tart. A frissítési beállítások gondoskodnak arról, hogy a Swarm az új verziókat konténerről konténerre vezesse be, hiba esetén pedig automatikusan visszavonja őket:

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

Ahhoz, hogy a Swarm felismerje, valóban dolgozik-e egy konténer, és nem csak fut, az image-be állapotellenőrzés kell, például ez a sor az alkalmazása Dockerfile-jában:

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

Azt a konténert, amelynek állapotellenőrzése háromszor egymás után sikertelen, a Swarm lecseréli, frissítés közben pedig egy sikertelen állapotellenőrzés megállítja a bevezetést.

10. lépés: Régiónként egy belépési pont

A belépési pont szerepét egy reverse proxy tölti be, például a Caddy, a Traefik vagy az nginx. Ez is régiónként külön szolgáltatásként fut, és a kéréseket csak a saját régiója alkalmazásához továbbítja. Host módban a 80-as és a 443-as portot közvetlenül a saját régiója szerverén publikálja. Elég egy közös konfiguráció, mert a Caddy a célt egy környezeti változóból olvassa ki:

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

Minden régiónak TLS-tanúsítványra van szüksége ugyanarra a domainre. Ezért a tanúsítványokat a DNS-challenge módszerrel igényelje, amely attól függetlenül működik, hogy a DNS-rekord éppen melyik régióra mutat; ehhez a Caddynek szüksége van az ön DNS-szolgáltatójához tartozó modulra. A proxy alapjait az nginx beállítása reverse proxyként című cikk ismerteti.

11. lépés: Geo-DNS beállítása failoverrel

Az utolsó építőelem a megfelelő régióba vezeti a felhasználókat. Egy földrajzi útválasztással és állapotellenőrzéssel működő DNS-szolgáltatás az Európából érkező felhasználókat Frankfurt am Mainba, az Amerikából érkezőket az USA keleti partjára, az Ázsiából érkezőket pedig Szingapúrba küldi. Ha egy régió kiesik, az állapotellenőrzés ezt 30 és 60 másodperc közötti idő alatt észleli, és a régió felhasználóit a legközelebbi egészséges régióba küldi. A rekordok érvényességi idejét (TTL) állítsa 60 másodpercre, hogy a resolverek gyorsan átvegyék a változást. Több A rekord állapotellenőrzés nélkül csak szükségmegoldás: a böngészők ugyan gyakran megpróbálják a következő címet, de nem minden kliens teszi ezt, és egy kiesett régió a válaszban marad.

Számoljon őszintén: a kiesés és az átállás között az ellenőrzési időköz és a TTL összegének megfelelő idő telik el, a példában tehát egy-két perc, amely alatt az érintett régió felhasználóinak egy része még a kiesett helyszínt éri el. Azok az alkalmazások és appok, amelyek a sikertelen kéréseket rövid szünet után megismétlik, ezt az időt szinte észrevétlenül áthidalják.

12. lépés: Egy régió kiesésének tesztelése

Az a failover, amelyet soha nem próbáltak ki, éles helyzetben ritkán működik. Szimulálja egy régió kiesését úgy, hogy kivonja a csomópontját az üzemből, és figyelje meg, hogyan reagál a klaszter és a DNS:

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

Mivel a régió szolgáltatásait elhelyezési szabály köti a csomópontjukhoz, nem költöznek át máshová, hanem szünetelnek; a régió felhasználóit a DNS-failover veszi át. Ebben a tesztben ezért elsősorban azt ellenőrizze, hogy az állapotellenőrzés kiveszi-e a régiót a válaszokból, és hogy a szomszédos régió elbírja-e a többletterhelést. Keményebb teszthez teljesen válassza le a csomópontot a hálózatról, például a WireGuard leállításával. Ismételje meg a tesztet nagyobb változtatások után, és legalább negyedévente egyszer.

Adatok: a magas rendelkezésre állás legnehezebb része

A Docker Swarm konténereket replikál, nem adatokat. Egy volume mindig azon a csomóponton található, amelyen a konténer fut. Az állapotmentes szolgáltatások, például a webes frontendek és az API-k ezért gond nélkül futtathatók minden régióban, de mindenhez, ami adatokat tárol, saját replikációra van szüksége.

Adatbázisok replikálása kontinensek között

Az adatbázisok saját replikációval rendelkeznek, és ez mindig előnyösebb, mint egy adatközpontokon átívelő közös tároló. Kontinensek között bevált megoldás egy elsődleges példány az egyik régióban, aszinkron replikákkal a másik kettőben: PostgreSQL esetén például streaming replikációval és egy olyan eszközzel, mint a Patroni, az automatikus átkapcsoláshoz, MariaDB és MySQL esetén pedig a beépített replikációval. Az olvasási kéréseket ekkor minden régió helyben szolgálja ki, az írások az elsődleges példányhoz kerülnek. Az aszinkron működés őszintén szólva azt is jelenti, hogy ha az elsődleges régió kiesik, az utolsó néhány másodperc írásai hiányozhatnak. Aki világszerte írni szeretne, és semmit sem akar elveszíteni, több régióra tervezett adatbázist választ, például a CockroachDB-t vagy a YugabyteDB-t. Az adatbázis-csomópontokat elhelyezési szabállyal rögzítse a régiójukhoz, hogy a Swarm soha ne helyezze át őket az adataik nélkül:

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

Fájlok és feltöltések

A feltöltött fájlok helye nem egy helyi volume, hanem egy S3-kompatibilis objektumtároló, amely egy második régióba replikál, vagy egy saját, replikált tárolórendszer. A kontinenseken átívelő hálózati fájlrendszerek, például az NFS, lassúak, és maguk is egyetlen hibapontot jelentenek.

Munkamenetek és gyorsítótárak

Ha az alkalmazás egy konténer memóriájában tárolja a munkameneteket, a felhasználók átkapcsoláskor elveszítik a bejelentkezésüket. Tárolja a munkameneteket replikált adatbázisban vagy replikált gyorsítótárban, például Redisben, vagy használjon aláírt tokeneket, amelyeket minden régió maga is ellenőrizni tud.

A mentések továbbra is kötelezők

A replikáció véd egy helyszín kiesése ellen, a hibák ellen azonban nem: egy véletlenül törölt rekord másodpercekkel később minden régióból törlődik. Ezért minden magas rendelkezésre állású architektúrához hozzátartoznak a rendszeres, tesztelt mentések egy független helyre, ahogyan a Mentési stratégia szerverekhez című cikk leírja.

Üzemeltetés: frissítések, karbantartás és monitorozás

Frissítések régióról régióra

Az új verziókat ne egyszerre vezesse be az összes régióban, hanem egymás után, és minden régiót figyeljen meg egy rövid ideig, mielőtt a következőre lépne. Így egy olyan hiba, amelyet egyetlen állapotellenőrzés sem észlel, legfeljebb egy régiót ér el, a másik kettő pedig továbbra is kiszolgálja annak felhasználóit:

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

Ha egy frissítés sikertelen, a Swarm a 9. lépés beállításainak köszönhetően automatikusan visszavonja, a || break pedig befejezi a ciklust, amint a parancs hibát jelez. Az olyan frissítést, amelynek a hibája csak később derül ki, a docker service rollback web-asia paranccsal vonhatja vissza kézzel.

Egy régió karbantartása

Ha egy szervert újra kell indítani vagy frissíteni kell, vonja ki az üzemből a docker node update --availability drain paranccsal, de előtte hagyja, hogy a DNS-failover a szomszédos régiókba irányítsa át a felhasználóit. A karbantartás után a --availability active kapcsolóval állítsa vissza üzembe. A következő managerrel várjon addig, amíg a docker node ls ismét mindhármat elérhetőként nem mutatja, hogy soha ne hiányozzon egyszerre két manager.

Monitorozás kívülről

Minden régiót külön-külön és a klaszteren kívülről monitorozzon: a belépési pontok elérhetőségét, a szolgáltatások állapotellenőrzéseit, a managerek állapotát, az adatbázis replikációs késését, valamint a tanúsítványok és a domainek lejárati dátumait. A riasztásnak akkor is meg kell érkeznie, ha egy egész régió elnémul. Hogy ezt egyes szerverekhez hogyan építheti fel, azt a Szervermonitorozás beállítása című cikk mutatja be.

Titkos adatok biztonságos kiosztása

A jelszavak és a kulcsok helye nem a környezeti változókban vagy a Compose-fájlokban van, hanem a Docker secretekben. Ezek titkosítva tárolódnak a Raft-naplóban, és csak azok a szolgáltatások kapják meg őket, amelyekhez ön kifejezetten hozzárendeli őket:

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

Miért a KernelHost egy több kontinensre kiterjedő Swarmhoz

Egy több kontinensre kiterjedő klaszter más követelményeket támaszt a szolgáltatóval szemben, mint egyetlen szerver. A gyakorlatban ezek a szempontok döntenek:

Az összes felhőcsomag áttekintését árakkal, valamint a nagy felhőszolgáltatókkal készült költség-összehasonlítást a Felhő szerver bérlés oldalon találja.

Gyakori hibák, és hogyan kerülheti el őket

• Managerek csak két helyszínen. Ha a többséget adó helyszín kiesik, a klaszter leáll. Megoldás: három helyszín, 1-1-1 vagy 2-2-1 arányú elosztás.
• Páros számú manager. Négy manager sem visel el több kiesést, mint három, viszont növeli az egyeztetési terhet. Megoldás: 3, 5 vagy 7.
• A kérések kontinensek között utaznak. Egy minden régiót átfogó szolgáltatáscím a fél világon át küldi a felhasználókat. Megoldás: régiónként egy szolgáltatás és egy belépési pont.
• Nyilvánosan elérhető Swarm-portok. A 2377-es port és az overlay-hálózat soha nem kerülhet ki a nyílt internetre. Megoldás: csak WireGuardon keresztül; nyilvánosan csak a 80-as és a 443-as port, valamint a WireGuard a többi csomópont számára.
• Elfelejtett MTU. A nagy válaszok elakadnak, a kicsik működnek. Megoldás: 1370-es overlay-MTU a WireGuard 1420-as értéke mellett.
• Az ufw-re hagyatkozás a konténerportoknál. A Docker a publikált portoknál megkerüli az ufw-t. Megoldás: csak a belépési pontot publikálja.
• Adatbázis volume-ban, replikáció nélkül. Ha a régió kiesik, az adatok elérhetetlenek. Megoldás: az adatbázis replikációja, rögzített elhelyezéssel a régióban.
• Frissítés egyszerre az összes régióban. Egy hiba ilyenkor világszerte minden felhasználót érint. Megoldás: régióról régióra történő bevezetés.
• Magas DNS-TTL. Egynapos TTL mellett a failover csak másnap lép életbe. Megoldás: 60 másodperc.
• Replikáció mentés helyett. Egy hiba ugyanúgy replikálódik, mint a jó adatok. Megoldás: emellett tesztelt mentések egy független helyen.

Röviden összefoglalva

• Egy három kontinensre kiterjedő Docker Swarm 100%-os rendelkezésre állásra tervezett rendszer: egy teljes helyszín vagy kontinens is kieshet anélkül, hogy az alkalmazás leállna.
• A rendelkezésre állást senki sem tudja abszolút garantálni; a fennmaradó kockázatok a DNS, a hibás frissítések, az adatbázis és a tanúsítványok, és mindegyikre létezik ellenintézkedés.
• Három manager három helyszínen a minimum; egy hibatűrő kvórumhoz két helyszín nem elég.
• Minden kérés a saját régiójában marad: régiónként egy szolgáltatás és egy belépési pont, emellett Geo-DNS állapotellenőrzéssel és rövid TTL-lel.
• A WireGuard titkosítja a klaszterforgalmat, a Swarm-portok láthatatlanok maradnak, az overlay-MTU 1370-re csökken.
• A Swarm konténereket replikál, nem adatokat: az adatbázisoknak saját replikációra van szükségük, és a mentések továbbra is kötelezők.
• A KernelHost helyszíneket kínál Európában, Észak-Amerikában, valamint Ázsiában és a csendes-óceáni térségben, továbbá korlátlan forgalmat, DDoS-védelmet minden helyszínen és PrePaid elszámolást minimális futamidő nélkül.