Docker Swarm över tre kontinenter: hög tillgänglighet som är utformad för 100 % upptid

En server i ett datacenter är en enskild felpunkt, oavsett hur bra hårdvaran och nätet är. Faller platsen bort, till exempel på grund av en störning i strömförsörjningen eller i nätet, eller helt enkelt på grund av ett misstag vid underhåll, är applikationen borta. Docker Swarm över flera datacenter löser just det problemet: containrarna körs på tre oberoende platser, i bästa fall på tre kontinenter, och om en av dem faller bort helt tar de två andra över utan att användarna märker något.

Den här artikeln visar steg för steg hur du bygger ett Docker Swarm-kluster som är utformat för 100 % upptid: en server vardera i Nordamerika, Europa och Asien, ett krypterat WireGuard-nätverk mellan noderna, ett manager-kvorum som klarar bortfallet av en hel kontinent, en ingångspunkt per region och en DNS-failover som automatiskt leder användarna till närmaste fungerande plats. Dessutom förklarar vi ärligt vad som ändå kan fallera med den här arkitekturen och hur du fångar upp även de riskerna.

Kan man uppnå 100 % upptid med Docker Swarm?

Ett Docker Swarm-kluster över tre kontinenter är utformat för 100 % upptid: ingen enskild server, inget enskilt datacenter och ingen enskild kontinent kan på egen hand få applikationen att stanna. Ändå kan ingen garantera en absolut tillgänglighet, inte ens de stora molnleverantörerna, vars högsta utfästelser ligger på 99,99 till 99,999 %. Orsaken är inte datacentren, utan det som alla platser har gemensamt. Just det tar den här artikeln också upp, så att du kommer så nära 100 % som det är tekniskt möjligt.

Vad tillgänglighet betyder i siffror

Beräkningen utgår från 8 760 timmar per år och 730 timmar per månad. Varje ytterligare nia minskar den tillåtna tiden för driftstopp till en tiondel, och just där börjar det arbete som en enskild server inte längre klarar av.

Varför tre kontinenter gör så stor skillnad

Tre av varandra oberoende platser med 99,9 % tillgänglighet vardera faller rent matematiskt bara bort samtidigt om alla tre är störda vid samma tidpunkt: 0,1 % gånger 0,1 % gånger 0,1 % blir 0,0000001 %. Ju längre ifrån varandra platserna ligger, desto mer oberoende är de i praktiken: egna elnät, egna nätanslutningar, egna väderförhållanden, egna underhållsfönster. Därför är en fördelning över Nordamerika, Europa och Asien den starkaste formen av driftsäkerhet som går att bygga med servrar.

Vad som kan fallera även med tre kontinenter

De kvarvarande riskerna är de beroenden som alla platser delar, och för vart och ett av dem finns en motåtgärd:

• En felaktig uppdatering sprids av klustret till alla platser lika tillförlitligt som en bra. Motåtgärd: hälsokontroller och automatisk rollback, dessutom uppdateringar region för region.
• DNS är den enda punkt som alla användare passerar. Motåtgärd: en DNS-leverantör med ett globalt distribuerat nät och failover, kort TTL.
• Databasen måste ha samma data på alla platser. Motåtgärd: replikering med automatisk failover, se avsnittet om data.
• Utgångna certifikat och domäner drabbar alla platser samtidigt. Motåtgärd: automatisk förnyelse och övervakning av utgångsdatumen.
• Själva omkopplingen tar så lång tid som hälsokontrollerna och DNS behöver för att reagera, oftast en till två minuter, under vilka enskilda förfrågningar kan misslyckas. Motåtgärd: korta kontrollintervall, kort TTL och klienter som upprepar misslyckade förfrågningar.

En överblick över arkitekturen

Ett Docker Swarm-kluster över flera kontinenter består av sex byggstenar. Var och en av dem eliminerar en viss felpunkt:

Hur många manager-noder och var?

Manager-noderna i en swarm hanterar klustrets tillstånd med konsensusalgoritmen Raft. Varje ändring kräver godkännande av en majoritet av manager-noderna, det så kallade kvorumet. Försvinner majoriteten fortsätter de befintliga containrarna visserligen att köras, men klustret kan varken schemalägga om, kompensera för bortfall eller rulla ut uppdateringar.

Docker rekommenderar ett udda antal manager-noder och en fördelning över minst tre zoner, med tre manager-noder i förhållandet 1-1-1 och med fem i förhållandet 2-2-1. Av det följer den viktigaste regeln i den här artikeln: Två platser räcker inte. Med två platser hamnar oundvikligen fler manager-noder på den ena, och faller just den bort är majoriteten borta. Först med tre platser klarar kvorumet bortfallet av vilket datacenter som helst, med tre kontinenter alltså bortfallet av en hel kontinent.

Tre kontinenter eller en kontinent: avvägningen

Varje ändring i klustret, varje driftsättning och varje omschemaläggning av en container väntar på bekräftelse från majoriteten av manager-noderna. Mellan Europa, Nordamerika och Asien innebär varje sådan bekräftelse en paketfördröjning på cirka 80 till 250 millisekunder. För användarna spelar det ingen roll, eftersom deras förfrågningar besvaras lokalt; driftsättningar och omschemaläggningar tar däremot märkbart längre tid än i ett kluster med korta avstånd.

För applikationer med användare på flera kontinenter och målet att nå största möjliga tillgänglighet är varianten med tre kontinenter den rätta, och det är den vi bygger i guiden. En viktig regel går som en röd tråd genom alla steg: varje förfrågan besvaras i sin egen region och reser aldrig fram och tillbaka mellan kontinenterna.

Vilka KernelHost-platser som passar

KernelHost driver servrar i maincubes-datacentret i Frankfurt am Main och erbjuder virtuella servrar på ytterligare platser i Europa, Nordamerika och Asien-Stillahavsområdet, bland annat på tre platser i USA samt i Kanada, London, Strasbourg, Warszawa, Helsingfors, Singapore, Japan, Sydney och Mumbai. Den fullständiga listan med karta finns på sidan Serverplatser. I exemplet i den här artikeln använder vi Frankfurt am Main för Europa, USA:s östkust för Nordamerika och Singapore för Asien.

Guide: bygg Docker Swarm över tre kontinenter

Exemplet använder tre servrar: swarm-eu i Frankfurt am Main, swarm-us på USA:s östkust och swarm-asia i Singapore. De publika adresserna kommer från dokumentationsnätet 203.0.113.0/24, och WireGuard-nätverket använder 10.10.0.0/24. Ersätt båda med dina egna värden. Alla tre noderna är både manager och worker; för högre prestanda lägger du senare till rena worker-noder i varje region.

Steg 1: sätt upp servrar på tre kontinenter

Beställ tre servrar med Debian 12 eller 13 i tre regioner och genomför grundhärdningen: SSH bara med nyckel, automatiska säkerhetsuppdateringar, egna användare. Checklistan för nya rootservrar täcker det. Ge servrarna beskrivande värdnamn, så att du i docker node ls direkt ser vilken nod som står var.

hostnamectl set-hostname swarm-eu

Steg 2: installera Docker på alla noder

Installera Docker Engine från Dockers officiella paketkälla på alla tre servrarna, så som beskrivs i artikeln Installera Docker på Debian och Ubuntu. Kontrollera sedan versionen på varje nod; alla tre bör ha samma huvudversion:

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

Steg 3: bygg ett WireGuard-nätverk mellan kontinenterna

Noderna kommunicerar med varandra över det publika internet. För att all klustertrafik ska vara krypterad och Swarm-portarna aldrig ska vara publikt nåbara förbinder ett WireGuard-nätverk de tre servrarna. På varje nod skapar du först ett nyckelpar:

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

Därefter får varje nod en fil /etc/wireguard/wg0.conf. Så här ser den ut på swarm-eu; de två andra noderna är uppbyggda som spegelbilder:

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

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

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

Svarar alla noder på sina 10.10.0.x-adresser är nätverket uppe. PersistentKeepalive håller anslutningen öppen även bakom tillståndsbaserade brandväggar. De svarstider som ping nu visar mellan kontinenterna är exakt de väntetider som varje ändring i klustret kostar.

Steg 4: brandvägg: bara Swarm-noderna släpps in

Mellan noderna behöver Docker Swarm port 2377/TCP för klusterhanteringen, 7946/TCP och UDP för kommunikationen mellan noderna och 4789/UDP för overlay-nätverket. De här portarna tillåter du enbart på WireGuard-gränssnittet; publikt förblir bara WireGuard öppet, och då bara för de andra noderna. Med ufw ser det ut så här på swarm-eu:

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

Viktigt: portar som Docker publicerar för containrar går förbi ufw, eftersom Docker sätter egna iptables-regler. Publicera därför bara ingångspunktens portar (80 och 443) och aldrig databas- eller administrationsportar.

Steg 5: initiera swarmen och lägg till manager-noder

På swarm-eu initierar du swarmen och ser till att både hanteringstrafiken och datatrafiken går via WireGuard:

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

Det andra kommandot skriver ut anslutningskommandot för ytterligare manager-noder. På swarm-us och swarm-asia kör du det med respektive nods egen WireGuard-adress, här för 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 visar sedan tre noder, en av dem med statusen Leader och de två andra med Reachable. Anslutningskommandots token är en hemlighet: den som känner till den kan smuggla in en egen manager-nod i ditt kluster. När uppbyggnaden är klar förnyar du den med docker swarm join-token --rotate manager.

Steg 6: aktivera autolock

Manager-noderna sparar klustrets tillstånd, inklusive nycklarna som Raft-loggarna är krypterade med, under /var/lib/docker/swarm/. Med autolock krypteras även själva nycklarna, och en omstartad manager-nod ansluter till klustret igen först efter att en upplåsningsnyckel har angetts:

docker swarm update --autolock=true
docker swarm unlock

Det första kommandot skriver ut upplåsningsnyckeln, som du sparar i en lösenordshanterare. Det andra behöver du efter varje omstart av en manager-nod. Utan nyckeln går swarmen inte att återställa ens från en backup, så förvara den separat från servrarna.

Steg 7: märk noderna efter region

Etiketter talar om för schemaläggaren var en nod står. På dem bygger placeringsreglerna i de följande stegen:

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

Steg 8: skapa ett overlay-nätverk med rätt MTU

Containrar på olika platser kommunicerar med varandra via ett overlay-nätverk. Eftersom det går genom WireGuard-tunneln måste dess MTU vara mindre: WireGuard arbetar med 1420 byte, overlay-nätverket (VXLAN) behöver 50 byte av dem för sina egna huvuden, och kvar blir 1370 byte:

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

En för stor MTU yttrar sig lömskt: små förfrågningar fungerar, stora svar hänger sig. Den som avstår från WireGuard kan i stället kryptera overlay-nätverket med --opt encrypted; då måste även IP-protokoll 50 (ESP) tillåtas mellan noderna, och Docker varnar uttryckligen för märkbara prestandaförluster. Vi rekommenderar WireGuard, eftersom det täcker all trafik, inklusive hanteringstrafiken.

Steg 9: kör applikationen i varje region

En vanlig Swarm-tjänst fördelar förfrågningar via sin tjänsteadress över alla repliker i klustret, alltså även till de andra kontinenterna. Med tre kontinenter skulle då varannan eller var tredje förfrågan resa halva jorden runt. Därför får varje region en egen tjänst som en placeringsregel håller kvar i regionen. Uppdateringsinställningarna ser till att nya versioner rullas ut container för container och rullas tillbaka automatiskt vid fel:

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

För att Swarm ska kunna avgöra om en container verkligen arbetar och inte bara körs hör en hälsokontroll hemma i imagen, till exempel den här raden i din applikations Dockerfile:

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

En container vars hälsokontroll misslyckas tre gånger i rad ersätts, och under en uppdatering stoppar en misslyckad hälsokontroll utrullningen.

Steg 10: en ingångspunkt per region

Ingångspunkten sköts av en reverse proxy som Caddy, Traefik eller nginx. Även den körs som en egen tjänst per region och vidarebefordrar förfrågningar bara till applikationen i sin egen region. I host-läge publicerar den portarna 80 och 443 direkt på servern i sin region. En gemensam konfiguration räcker, eftersom Caddy läser målet från en miljövariabel:

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

Alla regioner behöver ett TLS-certifikat för samma domän. Hämta därför certifikaten via en DNS-challenge, som fungerar oberoende av vilken region DNS-posten just nu pekar på; Caddy behöver då modulen för din DNS-leverantör. Grunderna om proxyn finns i artikeln Sätt upp nginx som reverse proxy.

Steg 11: sätt upp Geo-DNS med failover

Den sista byggstenen leder användarna till rätt region. En DNS-tjänst med geo-routing och hälsokontroller skickar användare från Europa till Frankfurt am Main, från Amerika till USA:s östkust och från Asien till Singapore. Faller en region bort upptäcker hälsokontrollen det inom 30 till 60 sekunder och skickar regionens användare till närmaste fungerande region. Sätt posternas giltighetstid (TTL) till 60 sekunder, så att resolvrar snabbt plockar upp en omställning. Flera A-poster utan hälsokontroll är bara en nödlösning: webbläsare provar visserligen ofta nästa adress, men inte alla klienter gör det, och en region som har fallit bort finns kvar i svaret.

Räkna ärligt: från bortfallet till omställningen tar det kontrollintervallet plus TTL, i exemplet alltså en till två minuter, under vilka en del av användarna i den drabbade regionen fortfarande når den plats som har fallit bort. Applikationer och appar som upprepar misslyckade förfrågningar efter en kort paus överbryggar den tiden nästan obemärkt.

Steg 12: testa bortfallet av en region

En failover som aldrig har övats fungerar sällan i skarpt läge. Simulera bortfallet av en region genom att ta dess nod ur drift, och se hur klustret och DNS reagerar:

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

Eftersom regionens tjänster är bundna till sin nod genom en placeringsregel flyttar de inte, utan pausar; regionens användare tas om hand av DNS-failovern. Kontrollera därför i det här testet framför allt om hälsokontrollen tar bort regionen ur svaren och om grannregionen klarar den extra belastningen. För ett hårdare test kopplar du bort noden helt från nätet, till exempel genom att stoppa WireGuard. Upprepa testet efter större ändringar och minst en gång per kvartal.

Data: den svåraste delen av hög tillgänglighet

Docker Swarm replikerar containrar, inte data. En volym ligger alltid på den nod där containern körs. Tillståndslösa tjänster som webbfrontends och API:er kan därför utan problem köras i varje region, men för allt som innehåller data behöver du en egen replikering.

Replikera databaser över kontinenter

Databaser har sin egen replikering, och den är alltid att föredra framför delad lagring över flera datacenter. Över kontinenter är en primär instans i en region med asynkrona repliker i de två andra ett beprövat upplägg, för PostgreSQL till exempel via streaming replication med ett verktyg som Patroni för automatisk failover, för MariaDB och MySQL via den inbyggda replikeringen. Varje region besvarar då läsförfrågningar lokalt, medan skrivningar går till den primära instansen. Asynkron betyder ärligt talat också: faller den primära regionen bort kan de sista sekundernas skrivningar saknas. Den som vill skriva världen över utan att förlora något väljer databaser som är byggda för flera regioner, till exempel CockroachDB eller YugabyteDB. Databasnoderna binder du med en placeringsregel fast vid respektive region, så att Swarm aldrig flyttar dem utan deras data:

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

Filer och uppladdningar

Uppladdade filer hör inte hemma i en lokal volym, utan i en S3-kompatibel objektlagring med replikering till en andra region eller i ett eget, replikerat lagringssystem. Nätverksfilsystem som NFS över kontinenter är långsamma och i sig en enskild felpunkt.

Sessioner och cachar

Sparar applikationen sessioner i en containers arbetsminne förlorar användarna sin inloggning vid omkopplingen. Lägg sessionerna i en replikerad databas eller en replikerad cache som Redis, eller använd signerade tokens som varje region kan kontrollera själv.

Backuper är fortfarande ett måste

Replikering skyddar mot bortfallet av en plats, men inte mot fel: en post som raderas av misstag är raderad i alla regioner några sekunder senare. Därför hör regelbundna, testade backuper till en oberoende plats till varje högtillgänglig arkitektur, så som beskrivs i artikeln Backupstrategi för servrar.

Drift: uppdateringar, underhåll och övervakning

Uppdateringar region för region

Rulla inte ut nya versioner i alla regioner samtidigt, utan i tur och ordning, och håll ett öga på varje region en kort stund innan nästa följer. Då når ett fel som ingen hälsokontroll upptäcker högst en region, och de två andra fortsätter att betjäna dess användare:

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

Misslyckas en uppdatering rullar Swarm tillbaka den automatiskt tack vare inställningarna från steg 9, och || break avslutar slingan så snart kommandot rapporterar ett fel. En uppdatering vars fel märks först senare rullar du tillbaka för hand med docker service rollback web-asia.

Underhåll av en region

Måste en server startas om eller uppdateras tar du den ur drift med docker node update --availability drain och låter DNS-failovern leda om dess användare till grannregionerna i förväg. Efter underhållet kopplar du in den igen med --availability active. Vänta med nästa manager-nod tills docker node ls åter visar alla tre som nåbara, så att det aldrig saknas två manager-noder samtidigt.

Övervakning utifrån

Övervaka varje region för sig och från en punkt utanför klustret: ingångspunkternas nåbarhet, tjänsternas hälsokontroller, manager-nodernas tillstånd, databasens replikeringsfördröjning och utgångsdatumen för certifikat och domäner. Ett larm måste komma fram även när en hel region tystnar. Hur du bygger upp det för enskilda servrar visar artikeln Sätt upp serverövervakning.

Distribuera hemligheter säkert

Lösenord och nycklar hör inte hemma i miljövariabler eller Compose-filer, utan i Docker Secrets. De lagras krypterade i Raft-loggen och levereras bara till de tjänster som du uttryckligen tilldelar dem:

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

Varför KernelHost för ett Swarm-kluster över flera kontinenter

Ett kluster över flera kontinenter ställer andra krav på leverantören än en enskild server. De här punkterna avgör i praktiken:

En överblick över alla molnpaket med priser och en kostnadsjämförelse med de stora molnleverantörerna hittar du på sidan Hyra molnserver.

Vanliga misstag och hur du undviker dem

• Manager-noder på bara två platser. Faller platsen med majoriteten bort står klustret still. Lösning: tre platser, fördelning 1-1-1 eller 2-2-1.
• Jämnt antal manager-noder. Fyra manager-noder klarar inte fler bortfall än tre, men ökar samordningsarbetet. Lösning: 3, 5 eller 7.
• Förfrågningar reser mellan kontinenterna. En tjänsteadress över alla regioner skickar användare halva jorden runt. Lösning: en tjänst och en ingångspunkt per region.
• Swarm-portar publikt nåbara. Port 2377 och overlay-nätverket hör aldrig hemma på det öppna internet. Lösning: bara via WireGuard, publikt bara 80, 443 och WireGuard för de andra noderna.
• MTU:n glöms bort. Stora svar hänger sig, små fungerar. Lösning: overlay-MTU 1370 med WireGuard på 1420.
• Att lita på ufw för containerportar. Docker går förbi ufw för publicerade portar. Lösning: publicera bara ingångspunkten.
• Databas i en volym utan replikering. Faller regionen bort går det inte att nå datan. Lösning: replikering av databasen, placering fast knuten till regionen.
• Uppdatering i alla regioner samtidigt. Ett fel drabbar då alla användare världen över. Lösning: rulla ut region för region.
• Hög DNS-TTL. Med en TTL på en dag slår failovern igenom först nästa dag. Lösning: 60 sekunder.
• Replikering i stället för backup. Ett fel replikeras precis som korrekta data. Lösning: testade backuper på en oberoende plats som komplement.

Kort sammanfattning

• Ett Docker Swarm-kluster över tre kontinenter är utformat för 100 % upptid: en hel plats eller kontinent får falla bort utan att applikationen står still.
• Ingen kan garantera tillgänglighet i absolut mening; de kvarvarande riskerna är DNS, felaktiga uppdateringar, databasen och certifikat, och för var och en finns en motåtgärd.
• Tre manager-noder på tre platser är minimum; två platser räcker inte för ett feltolerant kvorum.
• Varje förfrågan stannar i sin region: en tjänst och en ingångspunkt per region, plus Geo-DNS med hälsokontroller och kort TTL.
• WireGuard krypterar klustertrafiken, Swarm-portarna förblir osynliga och overlay-MTU:n sänks till 1370.
• Swarm replikerar containrar, inte data: databaser behöver egen replikering, och backuper är fortfarande ett måste.
• KernelHost erbjuder platser i Europa, Nordamerika och Asien-Stillahavsområdet, obegränsad trafik, DDoS-skydd på varje plats och PrePaid-debitering utan bindningstid.