Docker Swarm über drei Kontinente: Hochverfügbarkeit, die auf 100 % Uptime ausgelegt ist

Ein Server in einem Rechenzentrum ist ein einzelner Ausfallpunkt, ganz gleich, wie gut Hardware und Netz sind. Fällt der Standort aus, etwa durch eine Störung beim Strom, beim Netz oder schlicht durch einen Fehler bei einer Wartung, ist die Anwendung weg. Docker Swarm über mehrere Rechenzentren löst genau dieses Problem: Die Container laufen an drei unabhängigen Standorten, im Idealfall auf drei Kontinenten, und fällt einer davon komplett aus, übernehmen die beiden anderen, ohne dass die Nutzer davon etwas merken.

Dieser Beitrag zeigt Schritt für Schritt, wie Sie einen Docker-Swarm-Cluster aufbauen, der auf 100 % Uptime ausgelegt ist: je ein Server in Nordamerika, Europa und Asien, ein verschlüsseltes WireGuard-Netz zwischen den Knoten, ein Manager-Quorum, das den Ausfall eines ganzen Kontinents übersteht, ein Eingang je Region und ein DNS-Failover, der die Nutzer automatisch zum nächsten gesunden Standort leitet. Wir erklären außerdem ehrlich, was selbst bei dieser Architektur noch ausfallen kann und wie Sie auch diese Risiken abfangen.

Kann man mit Docker Swarm 100 % Uptime erreichen?

Ein Docker Swarm über drei Kontinente ist auf 100 % Uptime ausgelegt: Kein einzelner Server, kein einzelnes Rechenzentrum und kein einzelner Kontinent kann die Anwendung allein zum Stillstand bringen. Garantieren kann eine absolute Verfügbarkeit trotzdem niemand, nicht einmal die großen Cloud-Anbieter, deren höchste Zusagen bei 99,99 bis 99,999 % liegen. Der Grund sind nicht die Rechenzentren, sondern die Dinge, die alle Standorte gemeinsam haben. Genau die behandelt dieser Beitrag mit, damit Sie der 100 % so nahe kommen, wie es technisch möglich ist.

Was Verfügbarkeit in Zahlen bedeutet

Gerechnet ist mit 8.760 Stunden im Jahr und 730 Stunden im Monat. Jede zusätzliche Neun verkürzt die erlaubte Ausfallzeit auf ein Zehntel, und genau dort beginnt die Arbeit, die ein einzelner Server nicht mehr leisten kann.

Warum drei Kontinente so viel bringen

Drei voneinander unabhängige Standorte mit je 99,9 % Verfügbarkeit fallen rechnerisch nur dann gleichzeitig aus, wenn alle drei zur selben Zeit gestört sind: 0,1 % mal 0,1 % mal 0,1 % ergibt 0,0000001 %. Je weiter die Standorte auseinander liegen, desto unabhängiger sind sie tatsächlich: eigene Stromnetze, eigene Netzanbindungen, eigene Wetterlagen, eigene Wartungsfenster. Deshalb ist die Verteilung auf Nordamerika, Europa und Asien die stärkste Form der Ausfallsicherheit, die sich mit Servern bauen lässt.

Was selbst bei drei Kontinenten noch ausfallen kann

Die verbleibenden Risiken sind die gemeinsamen Abhängigkeiten aller Standorte, und für jede gibt es eine Gegenmaßnahme:

• Ein fehlerhaftes Update verteilt der Cluster genauso zuverlässig an alle Standorte wie ein gutes. Gegenmaßnahme: Health Checks und automatisches Zurückrollen, dazu Updates Region für Region.
• DNS ist die eine Stelle, über die alle Nutzer kommen. Gegenmaßnahme: ein DNS-Anbieter mit weltweit verteiltem Netz und Failover, kurze TTL.
• Die Datenbank muss an allen Standorten dieselben Daten haben. Gegenmaßnahme: Replikation mit automatischem Umschalten, siehe den Abschnitt zu Daten.
• Abgelaufene Zertifikate und Domains treffen alle Standorte gleichzeitig. Gegenmaßnahme: automatische Erneuerung und Überwachung der Ablaufdaten.
• Das Umschalten selbst dauert, bis Health Checks und DNS reagiert haben, meist ein bis zwei Minuten, in denen einzelne Anfragen scheitern können. Gegenmaßnahme: kurze Prüfintervalle, kurze TTL und Clients, die fehlgeschlagene Anfragen wiederholen.

Die Architektur im Überblick

Ein Docker Swarm über mehrere Kontinente besteht aus sechs Bausteinen. Jeder davon beseitigt einen bestimmten Ausfallpunkt:

Wie viele Manager und wo?

Die Manager-Knoten eines Swarms verwalten den Clusterzustand mit dem Raft-Konsensverfahren. Jede Änderung braucht die Zustimmung einer Mehrheit der Manager, des sogenannten Quorums. Fällt die Mehrheit weg, laufen die vorhandenen Container zwar weiter, aber der Cluster kann weder neu planen noch Ausfälle ausgleichen noch Updates verteilen.

Docker empfiehlt eine ungerade Zahl von Managern und die Verteilung auf mindestens drei Zonen, bei drei Managern im Verhältnis 1-1-1, bei fünf im Verhältnis 2-2-1. Daraus folgt die wichtigste Regel dieses Beitrags: Zwei Standorte reichen nicht. Bei zwei Standorten liegen zwangsläufig mehr Manager an einem der beiden, und fällt genau dieser aus, ist die Mehrheit weg. Erst mit drei Standorten übersteht das Quorum den Ausfall eines beliebigen Rechenzentrums, bei drei Kontinenten also den Ausfall eines ganzen Kontinents.

Drei Kontinente oder ein Kontinent: die Abwägung

Jede Änderung am Cluster, jedes Deployment und jede Neuplanung eines Containers wartet auf die Bestätigung der Manager-Mehrheit. Zwischen Europa, Nordamerika und Asien dauert jede dieser Bestätigungen eine Paketlaufzeit von etwa 80 bis 250 Millisekunden. Für die Nutzer ist das unerheblich, weil ihre Anfragen lokal beantwortet werden; Deployments und Umplanungen dauern aber spürbar länger als in einem Cluster mit kurzen Wegen.

Für Anwendungen mit Nutzern auf mehreren Kontinenten und dem Ziel größtmöglicher Verfügbarkeit ist die Variante mit drei Kontinenten die richtige, und diese bauen wir in der Anleitung auf. Wichtig ist dabei eine Regel, die sich durch alle Schritte zieht: Jede Anfrage wird in ihrer Region beantwortet und reist nie zwischen den Kontinenten hin und her.

Welche KernelHost-Standorte sich eignen

KernelHost betreibt Server im maincubes-Rechenzentrum in Frankfurt am Main und bietet virtuelle Server an weiteren Standorten in Europa, Nordamerika und Asien-Pazifik an, unter anderem an drei Standorten in den USA, in Kanada, London, Straßburg, Warschau, Helsinki, Singapur, Japan, Sydney und Mumbai. Die vollständige Liste mit Karte steht auf der Seite Serverstandorte. Für das Beispiel dieses Beitrags nehmen wir Frankfurt am Main für Europa, die US-Ostküste für Nordamerika und Singapur für Asien.

Anleitung: Docker Swarm über drei Kontinente aufbauen

Das Beispiel nutzt drei Server: swarm-eu in Frankfurt am Main, swarm-us an der US-Ostküste und swarm-asia in Singapur. Die öffentlichen Adressen stammen aus dem Dokumentationsnetz 203.0.113.0/24, das WireGuard-Netz nutzt 10.10.0.0/24. Ersetzen Sie beides durch Ihre Werte. Alle drei Knoten sind zugleich Manager und Worker; für mehr Leistung ergänzen Sie später in jeder Region reine Worker.

Schritt 1: Server auf drei Kontinenten bereitstellen

Bestellen Sie drei Server mit Debian 12 oder 13 in drei Regionen und setzen Sie die Grundabsicherung um: SSH nur mit Schlüssel, automatische Sicherheitsupdates, eigene Benutzer. Die Checkliste für neue Rootserver deckt das ab. Vergeben Sie sprechende Hostnamen, damit Sie in docker node ls sofort sehen, welcher Knoten wo steht.

hostnamectl set-hostname swarm-eu

Schritt 2: Docker auf allen Knoten installieren

Installieren Sie Docker Engine aus dem offiziellen Docker-Repository auf allen drei Servern, wie im Beitrag Docker unter Debian und Ubuntu installieren beschrieben. Prüfen Sie danach auf jedem Knoten die Version, alle drei sollten dieselbe Hauptversion haben:

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

Schritt 3: Ein WireGuard-Netz zwischen den Kontinenten aufbauen

Die Knoten sprechen über das öffentliche Internet miteinander. Damit der gesamte Clusterverkehr verschlüsselt und die Swarm-Ports nie öffentlich erreichbar sind, verbindet ein WireGuard-Netz die drei Server. Auf jedem Knoten erzeugen Sie zuerst ein Schlüsselpaar:

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

Danach bekommt jeder Knoten eine Datei /etc/wireguard/wg0.conf. So sieht sie auf swarm-eu aus, die beiden anderen Knoten sind spiegelbildlich aufgebaut:

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

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

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

Antworten alle Knoten über ihre 10.10.0.x-Adressen, steht das Netz. PersistentKeepalive hält die Verbindung auch hinter zustandsbehafteten Firewalls offen. Die Laufzeiten, die ping jetzt zwischen den Kontinenten anzeigt, sind genau die Wartezeiten, die jede Änderung am Cluster kostet.

Schritt 4: Firewall: nur die Swarm-Knoten dürfen hinein

Docker Swarm braucht zwischen den Knoten Port 2377/TCP für die Clusterverwaltung, 7946/TCP und UDP für die Kommunikation der Knoten untereinander und 4789/UDP für das Overlay-Netz. Diese Ports erlauben Sie ausschließlich auf der WireGuard-Schnittstelle, öffentlich bleibt nur WireGuard selbst offen, und das nur für die anderen Knoten. Mit ufw sieht das auf swarm-eu so aus:

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

Wichtig: Ports, die Docker für Container veröffentlicht, umgehen ufw, weil Docker eigene iptables-Regeln setzt. Veröffentlichen Sie deshalb nur die Ports des Eingangs (80 und 443) und nie Datenbank- oder Verwaltungsports.

Schritt 5: Swarm initialisieren und Manager hinzufügen

Auf swarm-eu initialisieren Sie den Swarm und sorgen dafür, dass Verwaltung und Datenverkehr über WireGuard laufen:

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

Der zweite Befehl gibt den Beitrittsbefehl für weitere Manager aus. Auf swarm-us und swarm-asia führen Sie ihn mit der jeweils eigenen WireGuard-Adresse aus, hier 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 zeigt danach drei Knoten, einer davon mit dem Status Leader, die beiden anderen mit Reachable. Das Beitrittstoken ist ein Geheimnis: Wer es kennt, kann einen eigenen Manager in Ihren Cluster einschleusen. Nach dem Aufbau erneuern Sie es mit docker swarm join-token --rotate manager.

Schritt 6: Autolock aktivieren

Die Manager speichern den Clusterzustand samt der Schlüssel, mit denen die Raft-Protokolle verschlüsselt sind, unter /var/lib/docker/swarm/. Mit Autolock werden diese Schlüssel selbst verschlüsselt, und ein neu gestarteter Manager tritt dem Cluster erst nach Eingabe eines Entsperrschlüssels wieder bei:

docker swarm update --autolock=true
docker swarm unlock

Der erste Befehl gibt den Entsperrschlüssel aus, den Sie in einem Passwortmanager ablegen. Den zweiten brauchen Sie nach jedem Neustart eines Managers. Ohne den Schlüssel lässt sich der Swarm auch aus einem Backup nicht wiederherstellen, bewahren Sie ihn deshalb getrennt von den Servern auf.

Schritt 7: Knoten nach Region beschriften

Labels verraten dem Scheduler, wo ein Knoten steht. Darauf bauen die Platzierungsregeln der nächsten Schritte auf:

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

Schritt 8: Ein Overlay-Netz mit passender MTU anlegen

Container an verschiedenen Standorten sprechen über ein Overlay-Netz miteinander. Weil es durch den WireGuard-Tunnel läuft, muss seine MTU kleiner sein: WireGuard arbeitet mit 1420 Byte, das Overlay-Netz (VXLAN) braucht davon 50 Byte für seine eigenen Kopfdaten, bleiben 1370 Byte:

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

Eine zu große MTU äußert sich tückisch: Kleine Anfragen funktionieren, große Antworten hängen. Wer auf WireGuard verzichtet, kann das Overlay-Netz stattdessen mit --opt encrypted verschlüsseln; dann muss zwischen den Knoten zusätzlich das IP-Protokoll 50 (ESP) erlaubt sein, und Docker weist ausdrücklich auf spürbare Leistungseinbußen hin. Wir empfehlen WireGuard, weil es den gesamten Verkehr einschließlich Verwaltung abdeckt.

Schritt 9: Die Anwendung in jeder Region betreiben

Ein gewöhnlicher Swarm-Dienst verteilt Anfragen über seine Dienstadresse auf alle Repliken im Cluster, also auch auf die anderen Kontinente. Bei drei Kontinenten würde damit jede zweite oder dritte Anfrage um die halbe Welt reisen. Deshalb bekommt jede Region einen eigenen Dienst, der per Platzierungsregel in seiner Region bleibt. Die Update-Einstellungen sorgen dafür, dass neue Versionen Container für Container ausgerollt und bei Fehlern automatisch zurückgenommen werden:

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

Damit Swarm erkennt, ob ein Container wirklich arbeitet und nicht nur läuft, gehört ein Health Check in das Image, zum Beispiel diese Zeile im Dockerfile Ihrer Anwendung:

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

Ein Container, dessen Health Check dreimal hintereinander fehlschlägt, wird ersetzt, und während eines Updates stoppt ein fehlschlagender Health Check das Ausrollen.

Schritt 10: Ein Eingang je Region

Den Eingang übernimmt ein Reverse Proxy wie Caddy, Traefik oder nginx. Auch er läuft je Region als eigener Dienst und leitet Anfragen nur an die Anwendung seiner Region weiter. Im Host-Modus veröffentlicht er die Ports 80 und 443 direkt auf dem Server seiner Region. Eine gemeinsame Konfiguration genügt, weil Caddy das Ziel aus einer Umgebungsvariable liest:

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

Alle Regionen brauchen ein TLS-Zertifikat für dieselbe Domain. Holen Sie die Zertifikate deshalb über die DNS-Challenge, die unabhängig davon funktioniert, auf welche Region der DNS-Eintrag gerade zeigt; Caddy braucht dafür das Modul Ihres DNS-Anbieters. Grundlagen zum Proxy stehen im Beitrag nginx als Reverse Proxy einrichten.

Schritt 11: Geo-DNS mit Failover einrichten

Der letzte Baustein führt die Nutzer zur richtigen Region. Ein DNS-Dienst mit Geo-Routing und Health Checks schickt Nutzer aus Europa nach Frankfurt am Main, aus Amerika an die US-Ostküste und aus Asien nach Singapur. Fällt eine Region aus, erkennt der Health Check das innerhalb von 30 bis 60 Sekunden und schickt ihre Nutzer zur nächstgelegenen gesunden Region. Setzen Sie die Gültigkeitsdauer (TTL) der Einträge auf 60 Sekunden, damit Resolver eine Umstellung schnell übernehmen. Mehrere A-Einträge ohne Health Check sind nur eine Notlösung: Browser versuchen zwar oft die nächste Adresse, aber nicht jeder Client tut das, und eine ausgefallene Region bleibt in der Antwort.

Rechnen Sie ehrlich: Zwischen Ausfall und Umstellung vergehen Prüfintervall plus TTL, im Beispiel also ein bis zwei Minuten, in denen ein Teil der Nutzer der betroffenen Region noch den ausgefallenen Standort erreicht. Anwendungen und Apps, die fehlgeschlagene Anfragen nach kurzer Pause wiederholen, überbrücken diese Zeit fast unbemerkt.

Schritt 12: Den Ausfall einer Region testen

Ein Failover, das nie geprobt wurde, funktioniert im Ernstfall selten. Simulieren Sie den Ausfall einer Region, indem Sie ihren Knoten aus dem Betrieb nehmen, und beobachten Sie, wie Cluster und DNS reagieren:

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

Weil die Dienste der Region per Platzierungsregel an ihren Knoten gebunden sind, ziehen sie nicht um, sondern pausieren; die Nutzer der Region übernimmt der DNS-Failover. Prüfen Sie deshalb in diesem Test vor allem, ob der Health Check die Region aus den Antworten nimmt und die Nachbarregion die zusätzliche Last trägt. Für einen härteren Test trennen Sie den Knoten ganz vom Netz, etwa indem Sie WireGuard stoppen. Wiederholen Sie den Test nach größeren Änderungen und mindestens einmal im Quartal.

Daten: der schwierigste Teil der Hochverfügbarkeit

Docker Swarm repliziert Container, keine Daten. Ein Volume liegt immer auf dem Knoten, auf dem der Container läuft. Zustandslose Dienste wie Webfrontends und APIs lassen sich deshalb problemlos in jeder Region betreiben, für alles mit Daten brauchen Sie eine eigene Replikation.

Datenbanken über Kontinente replizieren

Datenbanken bringen ihre eigene Replikation mit, und die ist einem geteilten Speicher über Rechenzentren hinweg immer vorzuziehen. Über Kontinente hinweg ist eine primäre Instanz in einer Region mit asynchronen Replikaten in den beiden anderen bewährt, bei PostgreSQL etwa über Streaming Replication mit einem Werkzeug wie Patroni für das automatische Umschalten, bei MariaDB und MySQL über die eingebaute Replikation. Leseanfragen beantwortet dann jede Region lokal, Schreibzugriffe gehen zur primären Instanz. Asynchron heißt ehrlich gesagt auch: Fällt die primäre Region aus, können die letzten Sekunden an Schreibvorgängen fehlen. Wer weltweit schreiben und nichts verlieren will, greift zu Datenbanken, die für mehrere Regionen gebaut sind, etwa CockroachDB oder YugabyteDB. Die Datenbank-Knoten binden Sie per Platzierungsregel fest an ihre Region, damit Swarm sie nie ohne ihre Daten verschiebt:

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

Dateien und Uploads

Hochgeladene Dateien gehören nicht in ein lokales Volume, sondern in einen S3-kompatiblen Objektspeicher mit Replikation in eine zweite Region oder in ein eigenes, repliziertes Speichersystem. Netzwerkdateisysteme wie NFS über Kontinente hinweg sind langsam und selbst ein einzelner Ausfallpunkt.

Sitzungen und Caches

Speichert die Anwendung Sitzungen im Arbeitsspeicher eines Containers, verlieren Nutzer beim Umschalten ihre Anmeldung. Legen Sie Sitzungen in eine replizierte Datenbank oder einen replizierten Cache wie Redis, oder nutzen Sie signierte Token, die jede Region selbst prüfen kann.

Backups bleiben Pflicht

Replikation schützt vor dem Ausfall eines Standorts, aber nicht vor Fehlern: Ein versehentlich gelöschter Datensatz ist Sekunden später in allen Regionen gelöscht. Deshalb gehören regelmäßige, getestete Backups an einen unabhängigen Ort zu jeder hochverfügbaren Architektur, wie im Beitrag Backup-Strategie für Server beschrieben.

Betrieb: Updates, Wartung und Überwachung

Updates Region für Region

Rollen Sie neue Versionen nicht in allen Regionen gleichzeitig aus, sondern nacheinander, und beobachten Sie jede Region kurz, bevor die nächste folgt. So erreicht ein Fehler, den kein Health Check erkennt, höchstens eine Region, und die anderen beiden bedienen deren Nutzer weiter:

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

Schlägt ein Update fehl, nimmt Swarm es dank der Einstellungen aus Schritt 9 automatisch zurück, und || break beendet die Schleife, sobald der Befehl einen Fehler meldet. Ein Update, das erst später auffällt, nehmen Sie mit docker service rollback web-asia von Hand zurück.

Wartung einer Region

Muss ein Server neu gestartet oder aktualisiert werden, nehmen Sie ihn mit docker node update --availability drain aus dem Betrieb und lassen den DNS-Failover seine Nutzer vorher auf die Nachbarregionen umleiten. Nach der Wartung schalten Sie ihn mit --availability active wieder zu. Warten Sie mit dem nächsten Manager, bis docker node ls wieder alle drei als erreichbar zeigt, damit nie zwei Manager gleichzeitig fehlen.

Überwachung von außen

Überwachen Sie jede Region einzeln und von außerhalb des Clusters: Erreichbarkeit der Eingänge, Health Checks der Dienste, Zustand der Manager, die Replikationsverzögerung der Datenbank und die Ablaufdaten von Zertifikaten und Domains. Ein Alarm muss auch dann ankommen, wenn eine ganze Region schweigt. Wie Sie das für einzelne Server aufbauen, zeigt der Beitrag Server-Monitoring einrichten.

Geheimnisse sicher verteilen

Passwörter und Schlüssel gehören nicht in Umgebungsvariablen oder Compose-Dateien, sondern in Docker Secrets. Sie werden verschlüsselt im Raft-Protokoll gespeichert und nur an die Dienste ausgeliefert, denen Sie sie ausdrücklich zuweisen:

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

Warum KernelHost für einen Swarm über mehrere Kontinente

Ein Cluster über mehrere Kontinente stellt andere Anforderungen an den Anbieter als ein einzelner Server. Diese Punkte entscheiden in der Praxis:

Einen Überblick über alle Cloud-Tarife mit Preisen und einen Kostenvergleich mit den großen Cloud-Anbietern finden Sie auf der Seite Cloud-Server mieten.

Häufige Fehler und wie Sie sie vermeiden

• Manager an nur zwei Standorten. Fällt der Standort mit der Mehrheit aus, steht der Cluster still. Lösung: drei Standorte, Verteilung 1-1-1 oder 2-2-1.
• Gerade Anzahl von Managern. Vier Manager verkraften nicht mehr Ausfälle als drei, erhöhen aber den Abstimmungsaufwand. Lösung: 3, 5 oder 7.
• Anfragen reisen zwischen den Kontinenten. Eine Dienstadresse über alle Regionen schickt Nutzer um die halbe Welt. Lösung: ein Dienst und ein Eingang je Region.
• Swarm-Ports öffentlich erreichbar. Port 2377 und das Overlay-Netz gehören nie ins offene Internet. Lösung: nur über WireGuard, öffentlich nur 80, 443 und WireGuard für die anderen Knoten.
• MTU vergessen. Große Antworten hängen, kleine funktionieren. Lösung: Overlay-MTU 1370 bei WireGuard mit 1420.
• Vertrauen auf ufw für Containerports. Docker umgeht ufw bei veröffentlichten Ports. Lösung: nur den Eingang veröffentlichen.
• Datenbank im Volume ohne Replikation. Fällt die Region aus, sind die Daten nicht erreichbar. Lösung: Replikation der Datenbank, Platzierung fest an die Region.
• Update in allen Regionen gleichzeitig. Ein Fehler trifft dann alle Nutzer weltweit. Lösung: Region für Region ausrollen.
• Hohe DNS-TTL. Mit einer TTL von einem Tag greift der Failover erst am nächsten Tag. Lösung: 60 Sekunden.
• Replikation statt Backup. Ein Fehler wird genauso repliziert wie gute Daten. Lösung: zusätzlich getestete Backups an einem unabhängigen Ort.

Kurz zusammengefasst

• Ein Docker Swarm über drei Kontinente ist auf 100 % Uptime ausgelegt: Ein ganzer Standort oder Kontinent darf ausfallen, ohne dass die Anwendung stillsteht.
• Absolut garantieren kann niemand eine Verfügbarkeit, die verbleibenden Risiken sind DNS, fehlerhafte Updates, Datenbank und Zertifikate, und für jedes gibt es eine Gegenmaßnahme.
• Drei Manager an drei Standorten sind das Minimum, zwei Standorte reichen für ein ausfallsicheres Quorum nicht.
• Jede Anfrage bleibt in ihrer Region: ein Dienst und ein Eingang je Region, dazu Geo-DNS mit Health Checks und kurzer TTL.
• WireGuard verschlüsselt den Clusterverkehr, die Swarm-Ports bleiben unsichtbar, die Overlay-MTU sinkt auf 1370.
• Swarm repliziert Container, keine Daten: Datenbanken brauchen eigene Replikation, und Backups bleiben Pflicht.
• KernelHost bietet Standorte in Europa, Nordamerika und Asien-Pazifik, unbegrenzten Traffic, DDoS-Schutz an jedem Standort und Abrechnung PrePaid ohne Mindestlaufzeit.