Docker Swarm over drie continenten: hoge beschikbaarheid, ontworpen voor 100% uptime

Een server in één datacenter is een single point of failure, hoe goed de hardware en het netwerk ook zijn. Valt de locatie uit, bijvoorbeeld door een storing in de stroomvoorziening of het netwerk, of simpelweg door een fout bij onderhoud, dan is de applicatie weg. Docker Swarm over meerdere datacenters lost precies dit probleem op: de containers draaien op drie onafhankelijke locaties, idealiter op drie continenten, en valt een daarvan volledig uit, dan nemen de andere twee het over zonder dat de gebruikers er iets van merken.

Dit artikel laat stap voor stap zien hoe u een Docker Swarm-cluster opzet dat is ontworpen voor 100% uptime: één server in Noord-Amerika, één in Europa en één in Azië, een versleuteld WireGuard-netwerk tussen de nodes, een managerquorum dat de uitval van een volledig continent overleeft, een toegangspunt per regio en een DNS-failover die de gebruikers automatisch naar de dichtstbijzijnde gezonde locatie leidt. Daarnaast leggen we eerlijk uit wat zelfs bij deze architectuur nog kan uitvallen en hoe u ook die risico's opvangt.

Is 100% uptime haalbaar met Docker Swarm?

Een Docker Swarm over drie continenten is ontworpen voor 100% uptime: geen enkele server, geen enkel datacenter en geen enkel continent kan de applicatie in zijn eentje platleggen. Een absolute beschikbaarheid kan desondanks niemand garanderen, zelfs de grote cloudaanbieders niet, waarvan de hoogste toezeggingen tussen 99,99 en 99,999% liggen. De oorzaak zit niet in de datacenters, maar in de dingen die alle locaties gemeen hebben. Juist die komen in dit artikel ook aan bod, zodat u de 100% zo dicht nadert als technisch mogelijk is.

Wat beschikbaarheid in cijfers betekent

Er is gerekend met 8.760 uur per jaar en 730 uur per maand. Elke extra negen verkort de toegestane downtime tot een tiende, en precies daar begint het werk dat een enkele server niet meer kan leveren.

Waarom drie continenten zoveel opleveren

Drie onderling onafhankelijke locaties met elk 99,9% beschikbaarheid vallen rekenkundig alleen tegelijk uit als ze alle drie op hetzelfde moment een storing hebben: 0,1% maal 0,1% maal 0,1% is 0,0000001%. Hoe verder de locaties uit elkaar liggen, hoe onafhankelijker ze werkelijk zijn: eigen stroomnetten, eigen netwerkaansluitingen, eigen weersomstandigheden, eigen onderhoudsvensters. Daarom is de spreiding over Noord-Amerika, Europa en Azië de sterkste vorm van bescherming tegen uitval die met servers te bouwen is.

Wat zelfs bij drie continenten nog kan uitvallen

De resterende risico's zijn de gemeenschappelijke afhankelijkheden van alle locaties, en voor elk daarvan bestaat een tegenmaatregel:

• Een foutieve update wordt door het cluster net zo betrouwbaar naar alle locaties verspreid als een goede. Tegenmaatregel: health checks en automatisch terugdraaien, plus updates regio voor regio.
• DNS is het ene punt waarlangs alle gebruikers binnenkomen. Tegenmaatregel: een DNS-aanbieder met een wereldwijd gespreid netwerk en failover, korte TTL.
• De database moet op alle locaties dezelfde gegevens hebben. Tegenmaatregel: replicatie met automatische omschakeling, zie het onderdeel over data.
• Verlopen certificaten en domeinen treffen alle locaties tegelijk. Tegenmaatregel: automatische verlenging en bewaking van de vervaldata.
• Het omschakelen zelf duurt tot health checks en DNS hebben gereageerd, meestal een tot twee minuten, waarin afzonderlijke verzoeken kunnen mislukken. Tegenmaatregel: korte controle-intervallen, korte TTL en clients die mislukte verzoeken herhalen.

De architectuur in één oogopslag

Een Docker Swarm over meerdere continenten bestaat uit zes bouwstenen. Elk daarvan neemt een specifiek single point of failure weg:

Hoeveel managers, en waar?

De managernodes van een Swarm beheren de clustertoestand met het Raft-consensusalgoritme. Elke wijziging vraagt de instemming van een meerderheid van de managers, het zogeheten quorum. Valt de meerderheid weg, dan blijven de bestaande containers weliswaar draaien, maar kan het cluster niets meer opnieuw inplannen, geen uitval meer opvangen en geen updates meer uitrollen.

Docker raadt een oneven aantal managers aan, verdeeld over minstens drie zones: bij drie managers in de verhouding 1-1-1, bij vijf in de verhouding 2-2-1. Daaruit volgt de belangrijkste regel van dit artikel: twee locaties zijn niet genoeg. Bij twee locaties staan er onvermijdelijk meer managers op een van beide, en valt juist die uit, dan is de meerderheid weg. Pas met drie locaties overleeft het quorum de uitval van een willekeurig datacenter, bij drie continenten dus de uitval van een volledig continent.

Drie continenten of één continent: de afweging

Elke wijziging aan het cluster, elke deployment en elke herplanning van een container wacht op de bevestiging van de meerderheid van de managers. Tussen Europa, Noord-Amerika en Azië kost elk van die bevestigingen een latentie van ongeveer 80 tot 250 milliseconden. Voor de gebruikers maakt dat niet uit, omdat hun verzoeken lokaal worden beantwoord; deployments en herplanningen duren wel merkbaar langer dan in een cluster met korte afstanden.

Voor applicaties met gebruikers op meerdere continenten en maximale beschikbaarheid als doel is de variant met drie continenten de juiste, en die bouwen we in de handleiding op. Daarbij geldt één regel die door alle stappen heen loopt: elk verzoek wordt in zijn eigen regio beantwoord en reist nooit heen en weer tussen de continenten.

Welke KernelHost-locaties geschikt zijn

KernelHost beheert servers in het maincubes-datacenter in Frankfurt am Main en biedt virtuele servers aan op andere locaties in Europa, Noord-Amerika en Azië-Pacific, onder meer op drie locaties in de VS en in Canada, Londen, Straatsburg, Warschau, Helsinki, Singapore, Japan, Sydney en Mumbai. De volledige lijst met kaart staat op de pagina Serverlocaties. Voor het voorbeeld in dit artikel nemen we Frankfurt am Main voor Europa, de Amerikaanse oostkust voor Noord-Amerika en Singapore voor Azië.

Handleiding: Docker Swarm over drie continenten opzetten

Het voorbeeld gebruikt drie servers: swarm-eu in Frankfurt am Main, swarm-us aan de Amerikaanse oostkust en swarm-asia in Singapore. De publieke adressen komen uit het documentatienetwerk 203.0.113.0/24, het WireGuard-netwerk gebruikt 10.10.0.0/24. Vervang beide door uw eigen waarden. Alle drie de nodes zijn tegelijk manager en worker; voor meer capaciteit voegt u later in elke regio nodes toe die alleen als worker dienen.

Stap 1: servers op drie continenten klaarzetten

Bestel drie servers met Debian 12 of 13 in drie regio's en richt de basisbeveiliging in: SSH alleen met sleutel, automatische beveiligingsupdates, eigen gebruikers. De checklist voor nieuwe rootservers dekt dat af. Geef de servers herkenbare hostnamen, zodat u in docker node ls meteen ziet welke node waar staat.

hostnamectl set-hostname swarm-eu

Stap 2: Docker op alle nodes installeren

Installeer Docker Engine uit de officiële Docker-repository op alle drie de servers, zoals beschreven in het artikel Docker installeren op Debian en Ubuntu. Controleer daarna op elke node de versie; alle drie moeten dezelfde hoofdversie hebben:

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

Stap 3: een WireGuard-netwerk tussen de continenten opzetten

De nodes communiceren via het publieke internet met elkaar. Om al het clusterverkeer te versleutelen en de Swarm-poorten nooit publiek bereikbaar te maken, verbindt een WireGuard-netwerk de drie servers. Op elke node maakt u eerst een sleutelpaar aan:

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

Daarna krijgt elke node een bestand /etc/wireguard/wg0.conf. Op swarm-eu ziet het er zo uit; de andere twee nodes zijn in spiegelbeeld opgebouwd:

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

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

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

Antwoorden alle nodes via hun 10.10.0.x-adressen, dan staat het netwerk. PersistentKeepalive houdt de verbinding ook achter stateful firewalls open. De looptijden die ping nu tussen de continenten toont, zijn precies de wachttijden die elke wijziging aan het cluster kost.

Stap 4: de firewall laat alleen de Swarm-nodes binnen

Docker Swarm heeft tussen de nodes poort 2377/TCP nodig voor het clusterbeheer, 7946/TCP en UDP voor de communicatie tussen de nodes onderling en 4789/UDP voor het overlaynetwerk. Deze poorten staat u uitsluitend toe op de WireGuard-interface; publiek blijft alleen WireGuard zelf open, en dan nog alleen voor de andere nodes. Met ufw ziet dat er op swarm-eu zo uit:

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

Belangrijk: poorten die Docker voor containers publiceert, omzeilen ufw, omdat Docker eigen iptables-regels instelt. Publiceer daarom alleen de poorten van het toegangspunt (80 en 443) en nooit database- of beheerpoorten.

Stap 5: de Swarm initialiseren en managers toevoegen

Op swarm-eu initialiseert u de Swarm en zorgt u ervoor dat het beheer- en dataverkeer via WireGuard loopt:

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

Het tweede commando toont het join-commando voor extra managers. Op swarm-us en swarm-asia voert u dat uit met het eigen WireGuard-adres van de betreffende node, hier voor 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 toont daarna drie nodes, een daarvan met de status Leader, de andere twee met Reachable. Het join-token is een geheim: wie het kent, kan een eigen manager in uw cluster binnensmokkelen. Zodra het cluster staat, vernieuwt u het met docker swarm join-token --rotate manager.

Stap 6: autolock activeren

De managers slaan de clustertoestand op onder /var/lib/docker/swarm/, samen met de sleutels waarmee de Raft-logs zijn versleuteld. Met autolock worden die sleutels zelf versleuteld, en een opnieuw gestarte manager treedt pas weer tot het cluster toe nadat er een ontgrendelsleutel is ingevoerd:

docker swarm update --autolock=true
docker swarm unlock

Het eerste commando toont de ontgrendelsleutel, die u in een wachtwoordmanager opslaat. Het tweede hebt u na elke herstart van een manager nodig. Zonder de sleutel is de Swarm ook uit een back-up niet te herstellen; bewaar hem daarom gescheiden van de servers.

Stap 7: nodes per regio labelen

Labels vertellen de scheduler waar een node staat. Daarop bouwen de plaatsingsregels in de volgende stappen voort:

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

Stap 8: een overlaynetwerk met de juiste MTU aanmaken

Containers op verschillende locaties communiceren via een overlaynetwerk met elkaar. Omdat dat netwerk door de WireGuard-tunnel loopt, moet de MTU ervan kleiner zijn: WireGuard werkt met 1420 byte, het overlaynetwerk (VXLAN) heeft daarvan 50 byte nodig voor zijn eigen headers, zodat er 1370 byte overblijven:

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

Een te grote MTU uit zich verraderlijk: kleine verzoeken werken, grote antwoorden blijven hangen. Wie geen WireGuard gebruikt, kan het overlaynetwerk in plaats daarvan met --opt encrypted versleutelen; dan moet tussen de nodes daarnaast IP-protocol 50 (ESP) zijn toegestaan, en Docker wijst uitdrukkelijk op merkbaar prestatieverlies. Wij raden WireGuard aan, omdat het al het verkeer afdekt, inclusief het beheer.

Stap 9: de applicatie in elke regio draaien

Een gewone Swarm-service verdeelt verzoeken via zijn serviceadres over alle replica's in het cluster, dus ook over de andere continenten. Bij drie continenten zou daardoor elk tweede of derde verzoek de halve wereld over reizen. Daarom krijgt elke regio een eigen service die via een plaatsingsregel in zijn regio blijft. De update-instellingen zorgen ervoor dat nieuwe versies container voor container worden uitgerold en bij fouten automatisch worden teruggedraaid:

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

Om Swarm te laten herkennen of een container echt werkt en niet alleen draait, hoort er een health check in het image, bijvoorbeeld deze regel in het Dockerfile van uw applicatie:

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

Een container waarvan de health check drie keer achter elkaar mislukt, wordt vervangen, en tijdens een update stopt een mislukte health check het uitrollen.

Stap 10: een toegangspunt per regio

Als toegangspunt dient een reverse proxy zoals Caddy, Traefik of nginx. Ook die draait per regio als eigen service en stuurt verzoeken alleen door naar de applicatie van zijn eigen regio. In hostmodus publiceert hij de poorten 80 en 443 rechtstreeks op de server van zijn regio. Eén gedeelde configuratie volstaat, omdat Caddy het doel uit een omgevingsvariabele leest:

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 regio's hebben een TLS-certificaat voor hetzelfde domein nodig. Vraag de certificaten daarom aan via de DNS-challenge, die werkt ongeacht naar welke regio het DNS-record op dat moment wijst; Caddy heeft daarvoor de module van uw DNS-aanbieder nodig. De basis van de proxy staat in het artikel nginx als reverse proxy instellen.

Stap 11: geo-DNS met failover instellen

De laatste bouwsteen leidt de gebruikers naar de juiste regio. Een DNS-dienst met geo-routing en health checks stuurt gebruikers uit Europa naar Frankfurt am Main, uit Amerika naar de Amerikaanse oostkust en uit Azië naar Singapore. Valt een regio uit, dan detecteert de health check dat binnen 30 tot 60 seconden en stuurt hij de gebruikers van die regio naar de dichtstbijzijnde gezonde regio. Zet de geldigheidsduur (TTL) van de records op 60 seconden, zodat resolvers een omschakeling snel overnemen. Meerdere A-records zonder health check zijn slechts een noodoplossing: browsers proberen weliswaar vaak het volgende adres, maar niet elke client doet dat, en een uitgevallen regio blijft in het antwoord staan.

Reken eerlijk: tussen uitval en omschakeling verstrijkt het controle-interval plus de TTL, in het voorbeeld dus een tot twee minuten, waarin een deel van de gebruikers in de getroffen regio nog de uitgevallen locatie bereikt. Applicaties en apps die mislukte verzoeken na een korte pauze herhalen, overbruggen die tijd vrijwel ongemerkt.

Stap 12: de uitval van een regio testen

Een failover die nooit is geoefend, werkt zelden als het erop aankomt. Simuleer de uitval van een regio door de node ervan uit bedrijf te nemen, en kijk hoe cluster en DNS reageren:

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

Omdat de services van de regio via een plaatsingsregel aan hun node gebonden zijn, verhuizen ze niet, maar pauzeren ze; de gebruikers van de regio worden opgevangen door de DNS-failover. Controleer in deze test daarom vooral of de health check de regio uit de antwoorden haalt en of de naburige regio de extra belasting aankan. Voor een zwaardere test koppelt u de node volledig los van het netwerk, bijvoorbeeld door WireGuard te stoppen. Herhaal de test na grotere wijzigingen en minstens eens per kwartaal.

Data: het moeilijkste deel van hoge beschikbaarheid

Docker Swarm repliceert containers, geen data. Een volume staat altijd op de node waarop de container draait. Stateless services zoals webfrontends en API's zijn daarom zonder problemen in elke regio te draaien; voor alles met data hebt u een eigen replicatie nodig.

Databases over continenten heen repliceren

Databases hebben hun eigen replicatie aan boord, en die verdient altijd de voorkeur boven gedeelde opslag over datacenters heen. Over continenten heen heeft een primaire instantie in één regio met asynchrone replica's in de andere twee zich bewezen: bij PostgreSQL bijvoorbeeld via streaming replication met een tool als Patroni voor het automatisch omschakelen, bij MariaDB en MySQL via de ingebouwde replicatie. Leesverzoeken beantwoordt dan elke regio lokaal, schrijfbewerkingen gaan naar de primaire instantie. Asynchroon betekent eerlijk gezegd ook: valt de primaire regio uit, dan kunnen de laatste seconden aan schrijfbewerkingen ontbreken. Wie wereldwijd wil schrijven zonder iets te verliezen, kiest voor databases die voor meerdere regio's zijn gebouwd, zoals CockroachDB of YugabyteDB. De databasenodes bindt u via een plaatsingsregel vast aan hun regio, zodat Swarm ze nooit zonder hun data verplaatst:

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

Bestanden en uploads

Geüploade bestanden horen niet in een lokaal volume, maar in S3-compatibele objectopslag met replicatie naar een tweede regio of in een eigen, gerepliceerd opslagsysteem. Netwerkbestandssystemen zoals NFS over continenten heen zijn traag en vormen zelf een single point of failure.

Sessies en caches

Slaat de applicatie sessies op in het werkgeheugen van een container, dan verliezen gebruikers bij het omschakelen hun aanmelding. Bewaar sessies in een gerepliceerde database of een gerepliceerde cache zoals Redis, of gebruik ondertekende tokens die elke regio zelf kan controleren.

Back-ups blijven verplicht

Replicatie beschermt tegen de uitval van een locatie, maar niet tegen fouten: een per ongeluk verwijderd record is seconden later in alle regio's verwijderd. Daarom horen regelmatige, geteste back-ups op een onafhankelijke plek bij elke hoogbeschikbare architectuur, zoals beschreven in het artikel Back-upstrategie voor servers.

Beheer: updates, onderhoud en monitoring

Updates regio voor regio

Rol nieuwe versies niet in alle regio's tegelijk uit, maar na elkaar, en houd elke regio even in de gaten voordat de volgende aan de beurt is. Zo bereikt een fout die door geen enkele health check wordt opgemerkt, hooguit één regio, en bedienen de andere twee de gebruikers daarvan verder:

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

Mislukt een update, dan draait Swarm die dankzij de instellingen uit stap 9 automatisch terug, en || break beëindigt de lus zodra het commando een fout meldt. Een update waarvan de problemen pas later opvallen, draait u met docker service rollback web-asia handmatig terug.

Onderhoud van een regio

Moet een server opnieuw worden opgestart of bijgewerkt, dan neemt u hem met docker node update --availability drain uit bedrijf en laat u de DNS-failover zijn gebruikers vooraf naar de naburige regio's omleiden. Na het onderhoud schakelt u hem met --availability active weer in. Wacht met de volgende manager tot docker node ls weer alle drie als bereikbaar toont, zodat er nooit twee managers tegelijk ontbreken.

Monitoring van buitenaf

Monitor elke regio afzonderlijk en van buiten het cluster: de bereikbaarheid van de toegangspunten, de health checks van de services, de toestand van de managers, de replicatievertraging van de database en de vervaldata van certificaten en domeinen. Een alarm moet ook aankomen als een hele regio zwijgt. Hoe u dat voor afzonderlijke servers opzet, laat het artikel Servermonitoring inrichten zien.

Geheimen veilig verspreiden

Wachtwoorden en sleutels horen niet in omgevingsvariabelen of Compose-bestanden, maar in Docker Secrets. Die worden versleuteld in de Raft-log opgeslagen en alleen uitgeleverd aan de services waaraan u ze uitdrukkelijk toewijst:

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

Waarom KernelHost voor een Swarm over meerdere continenten

Een cluster over meerdere continenten stelt andere eisen aan de aanbieder dan een enkele server. In de praktijk geven deze punten de doorslag:

Een overzicht van alle cloudpakketten met prijzen en een kostenvergelijking met de grote cloudaanbieders vindt u op de pagina Cloud server huren.

Veelgemaakte fouten en hoe u ze voorkomt

• Managers op slechts twee locaties. Valt de locatie met de meerderheid uit, dan staat het cluster stil. Oplossing: drie locaties, verdeling 1-1-1 of 2-2-1.
• Een even aantal managers. Vier managers vangen niet meer uitval op dan drie, maar vergroten wel de overhead van de onderlinge afstemming. Oplossing: 3, 5 of 7.
• Verzoeken reizen tussen de continenten. Eén serviceadres voor alle regio's stuurt gebruikers de halve wereld rond. Oplossing: één service en één toegangspunt per regio.
• Swarm-poorten publiek bereikbaar. Poort 2377 en het overlaynetwerk horen nooit op het open internet. Oplossing: alleen via WireGuard, publiek alleen 80, 443 en WireGuard voor de andere nodes.
• MTU vergeten. Grote antwoorden blijven hangen, kleine werken. Oplossing: overlay-MTU 1370 bij WireGuard met 1420.
• Vertrouwen op ufw voor containerpoorten. Docker omzeilt ufw bij gepubliceerde poorten. Oplossing: alleen het toegangspunt publiceren.
• Database in een volume zonder replicatie. Valt de regio uit, dan zijn de gegevens niet bereikbaar. Oplossing: replicatie van de database, plaatsing vast aan de regio.
• Update in alle regio's tegelijk. Een fout treft dan alle gebruikers wereldwijd. Oplossing: regio voor regio uitrollen.
• Hoge DNS-TTL. Met een TTL van een dag werkt de failover pas de volgende dag. Oplossing: 60 seconden.
• Replicatie in plaats van back-up. Een fout wordt net zo goed gerepliceerd als goede data. Oplossing: daarnaast geteste back-ups op een onafhankelijke plek.

Kort samengevat

• Een Docker Swarm over drie continenten is ontworpen voor 100% uptime: een volledige locatie of een volledig continent mag uitvallen zonder dat de applicatie stilvalt.
• Niemand kan een beschikbaarheid absoluut garanderen; de resterende risico's zijn DNS, foutieve updates, de database en certificaten, en voor elk daarvan bestaat een tegenmaatregel.
• Drie managers op drie locaties zijn het minimum; twee locaties volstaan niet voor een quorum dat bestand is tegen uitval.
• Elk verzoek blijft in zijn eigen regio: één service en één toegangspunt per regio, plus geo-DNS met health checks en een korte TTL.
• WireGuard versleutelt het clusterverkeer, de Swarm-poorten blijven onzichtbaar, de overlay-MTU gaat omlaag naar 1370.
• Swarm repliceert containers, geen data: databases hebben een eigen replicatie nodig, en back-ups blijven verplicht.
• KernelHost biedt locaties in Europa, Noord-Amerika en Azië-Pacific, onbeperkt verkeer, DDoS-bescherming op elke locatie en PrePaid-afrekening zonder minimale looptijd.