Docker Swarm sur trois continents : une haute disponibilité conçue pour 100 % d'uptime

Un serveur dans un centre de données constitue un point de défaillance unique, aussi bons que soient le matériel et le réseau. Si le site tombe en panne, que ce soit à cause d'une coupure de courant, d'un incident réseau ou tout simplement d'une erreur lors d'une maintenance, l'application n'est plus disponible. Docker Swarm sur plusieurs centres de données résout précisément ce problème : les conteneurs tournent sur trois sites indépendants, idéalement sur trois continents, et si l'un d'eux tombe complètement, les deux autres prennent le relais sans que les utilisateurs s'en aperçoivent.

Cet article montre pas à pas comment mettre en place un cluster Docker Swarm conçu pour 100 % d'uptime : un serveur en Amérique du Nord, un en Europe et un en Asie, un réseau WireGuard chiffré entre les nœuds, un quorum de managers qui survit à la perte d'un continent entier, un point d'entrée par région et un failover DNS qui dirige automatiquement les utilisateurs vers le site sain le plus proche. Nous expliquons aussi honnêtement ce qui peut encore tomber en panne, même avec cette architecture, et comment parer également à ces risques.

Peut-on atteindre 100 % d'uptime avec Docker Swarm ?

Un Docker Swarm réparti sur trois continents est conçu pour 100 % d'uptime : ni un serveur, ni un centre de données, ni même un continent ne peut à lui seul mettre l'application à l'arrêt. Personne ne peut pour autant garantir une disponibilité absolue, pas même les grands fournisseurs cloud, dont les engagements les plus élevés se situent entre 99,99 et 99,999 %. La raison ne tient pas aux centres de données, mais aux éléments que tous les sites ont en commun. Cet article traite aussi précisément de ces éléments, afin que vous approchiez des 100 % d'aussi près que la technique le permet.

Ce que la disponibilité signifie en chiffres

Le calcul repose sur 8 760 heures par an et 730 heures par mois. Chaque neuf supplémentaire divise par dix l'indisponibilité tolérée, et c'est précisément là que commence le travail qu'un serveur isolé ne peut plus assurer.

Pourquoi trois continents font une telle différence

Trois sites indépendants les uns des autres, offrant chacun 99,9 % de disponibilité, ne tombent en panne ensemble, d'un point de vue mathématique, que si tous les trois sont perturbés au même moment : 0,1 % fois 0,1 % fois 0,1 % donne 0,0000001 %. Plus les sites sont éloignés les uns des autres, plus ils sont réellement indépendants : réseaux électriques distincts, raccordements réseau distincts, conditions météorologiques distinctes, fenêtres de maintenance distinctes. C'est pourquoi la répartition entre l'Amérique du Nord, l'Europe et l'Asie est la forme de tolérance aux pannes la plus solide que l'on puisse construire avec des serveurs.

Ce qui peut encore tomber en panne, même avec trois continents

Les risques restants sont les dépendances communes à tous les sites, et il existe une contre-mesure pour chacune d'elles :

• Une mise à jour défectueuse est distribuée par le cluster à tous les sites avec autant de fiabilité qu'une bonne. Contre-mesure : des Health Checks et un rollback automatique, avec des mises à jour région par région.
• Le DNS est le point unique par lequel passent tous les utilisateurs. Contre-mesure : un fournisseur DNS doté d'un réseau réparti dans le monde entier et d'un failover, avec un TTL court.
• La base de données doit contenir les mêmes données sur tous les sites. Contre-mesure : une réplication avec basculement automatique, voir la section consacrée aux données.
• Les certificats et les domaines expirés touchent tous les sites en même temps. Contre-mesure : renouvellement automatique et surveillance des dates d'expiration.
• Le basculement lui-même dure jusqu'à ce que les Health Checks et le DNS aient réagi, en général une à deux minutes, pendant lesquelles certaines requêtes peuvent échouer. Contre-mesure : des intervalles de vérification courts, un TTL court et des clients qui répètent les requêtes ayant échoué.

Vue d'ensemble de l'architecture

Un Docker Swarm réparti sur plusieurs continents repose sur six briques. Chacune élimine un point de défaillance précis :

Combien de managers, et où ?

Les nœuds manager d'un Swarm gèrent l'état du cluster à l'aide de l'algorithme de consensus Raft. Toute modification exige l'accord d'une majorité des managers, ce qu'on appelle le quorum. Si cette majorité disparaît, les conteneurs existants continuent certes de tourner, mais le cluster ne peut plus ni replanifier, ni compenser les pannes, ni distribuer de mises à jour.

Docker recommande un nombre impair de managers et une répartition sur au moins trois zones, dans un rapport 1-1-1 avec trois managers et 2-2-1 avec cinq. On en tire la règle la plus importante de cet article : deux sites ne suffisent pas. Avec deux sites, l'un des deux héberge forcément plus de managers que l'autre, et si c'est justement celui-là qui tombe, la majorité est perdue. Ce n'est qu'avec trois sites que le quorum survit à la perte de n'importe quel centre de données, et donc, avec trois continents, à la perte d'un continent entier.

Trois continents ou un seul : le compromis

Chaque modification du cluster, chaque déploiement et chaque replanification d'un conteneur attend la confirmation de la majorité des managers. Entre l'Europe, l'Amérique du Nord et l'Asie, chacune de ces confirmations coûte un temps de transit d'environ 80 à 250 millisecondes. Pour les utilisateurs, c'est sans importance, car leurs requêtes reçoivent une réponse locale ; les déploiements et les replanifications prennent en revanche sensiblement plus de temps que dans un cluster aux distances courtes.

Pour des applications dont les utilisateurs se trouvent sur plusieurs continents et qui visent la disponibilité la plus élevée possible, la variante à trois continents est la bonne, et c'est celle que nous construisons dans le guide. Une règle importante traverse toutes les étapes : chaque requête reçoit sa réponse dans sa propre région et ne fait jamais d'allers-retours entre les continents.

Quels sites KernelHost conviennent

KernelHost exploite des serveurs dans le centre de données maincubes à Francfort-sur-le-Main et propose des serveurs virtuels sur d'autres sites en Europe, en Amérique du Nord et en Asie-Pacifique, entre autres sur trois sites aux États-Unis, au Canada, à Londres, à Strasbourg, à Varsovie, à Helsinki, à Singapour, au Japon, à Sydney et à Mumbai. La liste complète, avec une carte, figure sur la page Emplacements des serveurs. Pour l'exemple de cet article, nous retenons Francfort-sur-le-Main pour l'Europe, la côte Est des États-Unis pour l'Amérique du Nord et Singapour pour l'Asie.

Guide : mettre en place Docker Swarm sur trois continents

L'exemple utilise trois serveurs : swarm-eu à Francfort-sur-le-Main, swarm-us sur la côte Est des États-Unis et swarm-asia à Singapour. Les adresses publiques proviennent du réseau de documentation 203.0.113.0/24, le réseau WireGuard utilise 10.10.0.0/24. Remplacez les deux par vos propres valeurs. Les trois nœuds sont à la fois managers et workers ; pour plus de performances, vous ajouterez plus tard des nœuds worker dédiés dans chaque région.

Étape 1 : provisionner des serveurs sur trois continents

Commandez trois serveurs sous Debian 12 ou 13 dans trois régions et appliquez la sécurisation de base : SSH uniquement par clé, mises à jour de sécurité automatiques, comptes utilisateurs dédiés. La checklist pour nouveaux serveurs root couvre tout cela. Choisissez des noms d'hôte explicites, afin de voir immédiatement dans docker node ls quel nœud se trouve où.

hostnamectl set-hostname swarm-eu

Étape 2 : installer Docker sur tous les nœuds

Installez Docker Engine depuis le dépôt officiel de Docker sur les trois serveurs, comme décrit dans l'article Installer Docker sur Debian et Ubuntu. Vérifiez ensuite la version sur chaque nœud ; les trois doivent avoir la même version majeure :

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

Étape 3 : créer un réseau WireGuard entre les continents

Les nœuds communiquent entre eux par l'Internet public. Pour que l'ensemble du trafic du cluster soit chiffré et que les ports Swarm ne soient jamais joignables publiquement, un réseau WireGuard relie les trois serveurs. Sur chaque nœud, générez d'abord une paire de clés :

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

Chaque nœud reçoit ensuite un fichier /etc/wireguard/wg0.conf. Voici son contenu sur swarm-eu ; les deux autres nœuds sont configurés de façon symétrique :

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

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

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

Si tous les nœuds répondent sur leurs adresses 10.10.0.x, le réseau est en place. PersistentKeepalive maintient la connexion ouverte, même derrière des pare-feu à état. Les temps de transit que ping affiche maintenant entre les continents correspondent exactement aux temps d'attente que coûte chaque modification du cluster.

Étape 4 : un pare-feu qui ne laisse entrer que les nœuds Swarm

Entre les nœuds, Docker Swarm a besoin du port 2377/TCP pour la gestion du cluster, du port 7946/TCP et UDP pour la communication entre les nœuds et du port 4789/UDP pour le réseau overlay. Vous n'autorisez ces ports que sur l'interface WireGuard ; publiquement, seul WireGuard lui-même reste ouvert, et uniquement pour les autres nœuds. Avec ufw, cela donne ceci sur 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

Important : les ports que Docker publie pour les conteneurs contournent ufw, car Docker pose ses propres règles iptables. Ne publiez donc que les ports du point d'entrée (80 et 443), jamais des ports de base de données ou d'administration.

Étape 5 : initialiser le Swarm et ajouter les managers

Sur swarm-eu, initialisez le Swarm en veillant à ce que la gestion et le trafic de données passent par WireGuard :

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

La seconde commande affiche la commande de jonction destinée aux autres managers. Exécutez-la sur swarm-us et swarm-asia, chaque fois avec l'adresse WireGuard propre au nœud, ici pour 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 affiche ensuite trois nœuds, l'un avec le statut Leader, les deux autres avec Reachable. Le jeton de jonction est un secret : quiconque le connaît peut introduire son propre manager dans votre cluster. Une fois la mise en place terminée, renouvelez-le avec docker swarm join-token --rotate manager.

Étape 6 : activer Autolock

Les managers stockent l'état du cluster, ainsi que les clés qui chiffrent les journaux Raft, sous /var/lib/docker/swarm/. Avec Autolock, ces clés sont elles-mêmes chiffrées, et un manager redémarré ne rejoint le cluster qu'après la saisie d'une clé de déverrouillage :

docker swarm update --autolock=true
docker swarm unlock

La première commande affiche la clé de déverrouillage, que vous rangez dans un gestionnaire de mots de passe. La seconde vous servira après chaque redémarrage d'un manager. Sans cette clé, le Swarm ne peut pas non plus être restauré à partir d'une sauvegarde : conservez-la donc à l'écart des serveurs.

Étape 7 : étiqueter les nœuds par région

Les labels indiquent au scheduler où se trouve un nœud. Les contraintes de placement des étapes suivantes s'appuient dessus :

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

Étape 8 : créer un réseau overlay avec la bonne MTU

Les conteneurs situés sur des sites différents communiquent entre eux via un réseau overlay. Comme ce réseau passe par le tunnel WireGuard, sa MTU doit être plus petite : WireGuard travaille avec 1420 octets, le réseau overlay (VXLAN) en utilise 50 pour ses propres en-têtes, il reste donc 1370 octets :

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

Une MTU trop grande se manifeste de façon sournoise : les petites requêtes fonctionnent, les grosses réponses restent bloquées. Si vous renoncez à WireGuard, vous pouvez à la place chiffrer le réseau overlay avec --opt encrypted ; il faut alors autoriser en plus le protocole IP 50 (ESP) entre les nœuds, et Docker signale explicitement une baisse de performances sensible. Nous recommandons WireGuard, car il couvre l'ensemble du trafic, gestion comprise.

Étape 9 : exploiter l'application dans chaque région

Un service Swarm ordinaire répartit les requêtes, via l'adresse du service, sur toutes les répliques du cluster, donc aussi sur les autres continents. Avec trois continents, une requête sur deux ou sur trois partirait ainsi à l'autre bout du monde. C'est pourquoi chaque région reçoit son propre service, maintenu dans sa région par une contrainte de placement. Les paramètres de mise à jour garantissent que les nouvelles versions sont déployées conteneur par conteneur et annulées automatiquement en cas d'erreur :

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

Pour que Swarm sache si un conteneur travaille réellement et ne se contente pas de tourner, l'image doit contenir un Health Check, par exemple cette ligne dans le Dockerfile de votre application :

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

Un conteneur dont le Health Check échoue trois fois de suite est remplacé, et pendant une mise à jour, un Health Check en échec interrompt le déploiement.

Étape 10 : un point d'entrée par région

Le rôle de point d'entrée revient à un reverse proxy comme Caddy, Traefik ou nginx. Lui aussi tourne comme service distinct dans chaque région et ne transmet les requêtes qu'à l'application de sa région. En mode host, il publie les ports 80 et 443 directement sur le serveur de sa région. Une configuration commune suffit, car Caddy lit la cible dans une variable d'environnement :

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

Toutes les régions ont besoin d'un certificat TLS pour le même domaine. Obtenez donc les certificats via le challenge DNS, qui fonctionne quelle que soit la région vers laquelle pointe l'enregistrement DNS à ce moment-là ; Caddy a besoin pour cela du module de votre fournisseur DNS. Les bases du proxy sont présentées dans l'article Configurer nginx en reverse proxy.

Étape 11 : configurer un Geo-DNS avec failover

La dernière brique conduit les utilisateurs vers la bonne région. Un service DNS avec routage géographique et Health Checks envoie les utilisateurs d'Europe vers Francfort-sur-le-Main, ceux d'Amérique vers la côte Est des États-Unis et ceux d'Asie vers Singapour. Si une région tombe en panne, le Health Check le détecte en 30 à 60 secondes et redirige ses utilisateurs vers la région saine la plus proche. Fixez la durée de validité (TTL) des enregistrements à 60 secondes, afin que les résolveurs prennent rapidement en compte un changement. Plusieurs enregistrements A sans Health Check ne sont qu'un pis-aller : les navigateurs essaient certes souvent l'adresse suivante, mais tous les clients ne le font pas, et une région en panne reste présente dans la réponse.

Faites un calcul honnête : entre la panne et le basculement s'écoulent l'intervalle de vérification plus le TTL, soit une à deux minutes dans l'exemple, pendant lesquelles une partie des utilisateurs de la région concernée atteint encore le site en panne. Les applications et les apps mobiles qui répètent les requêtes ayant échoué après une courte pause comblent ce délai de façon presque imperceptible.

Étape 12 : tester la panne d'une région

Un failover jamais testé fonctionne rarement le jour où l'on en a besoin. Simulez la panne d'une région en retirant son nœud du service, et observez la réaction du cluster et du DNS :

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

Comme les services de la région sont liés à leur nœud par une contrainte de placement, ils ne migrent pas, mais restent en pause ; c'est le failover DNS qui prend en charge les utilisateurs de la région. Dans ce test, vérifiez donc surtout que le Health Check retire la région des réponses et que la région voisine absorbe la charge supplémentaire. Pour un test plus exigeant, coupez complètement le nœud du réseau, par exemple en arrêtant WireGuard. Répétez le test après chaque changement important et au moins une fois par trimestre.

Les données : la partie la plus difficile de la haute disponibilité

Docker Swarm réplique des conteneurs, pas des données. Un volume se trouve toujours sur le nœud où tourne le conteneur. Les services sans état, comme les frontends web et les API, s'exploitent donc sans difficulté dans chaque région ; pour tout ce qui contient des données, il vous faut une réplication dédiée.

Répliquer les bases de données entre continents

Les bases de données disposent de leur propre réplication, et celle-ci est toujours préférable à un stockage partagé entre centres de données. Entre continents, le schéma éprouvé est une instance primaire dans une région avec des répliques asynchrones dans les deux autres : pour PostgreSQL, par exemple via la Streaming Replication avec un outil comme Patroni pour le basculement automatique, pour MariaDB et MySQL via la réplication intégrée. Chaque région répond alors localement aux requêtes de lecture, tandis que les écritures vont à l'instance primaire. Pour être honnête, asynchrone signifie aussi : si la région primaire tombe en panne, les dernières secondes d'écritures peuvent manquer. Si vous voulez écrire dans le monde entier sans rien perdre, tournez-vous vers des bases de données conçues pour plusieurs régions, comme CockroachDB ou YugabyteDB. Liez les nœuds de base de données à leur région par une contrainte de placement, afin que Swarm ne les déplace jamais sans leurs données :

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

Fichiers et uploads

Les fichiers téléversés n'ont pas leur place dans un volume local, mais dans un stockage objet compatible S3 répliqué vers une seconde région, ou dans votre propre système de stockage répliqué. Les systèmes de fichiers réseau comme NFS, utilisés d'un continent à l'autre, sont lents et constituent eux-mêmes un point de défaillance unique.

Sessions et caches

Si l'application stocke les sessions dans la mémoire vive d'un conteneur, les utilisateurs perdent leur connexion lors du basculement. Placez les sessions dans une base de données répliquée ou dans un cache répliqué comme Redis, ou utilisez des jetons signés que chaque région peut vérifier elle-même.

Les sauvegardes restent obligatoires

La réplication protège contre la panne d'un site, mais pas contre les erreurs : un enregistrement supprimé par erreur l'est aussi, quelques secondes plus tard, dans toutes les régions. C'est pourquoi toute architecture haute disponibilité comprend des sauvegardes régulières et testées vers un lieu indépendant, comme décrit dans l'article Stratégie de sauvegarde pour serveurs.

Exploitation : mises à jour, maintenance et supervision

Mises à jour région par région

Ne déployez pas les nouvelles versions dans toutes les régions en même temps, mais l'une après l'autre, et observez brièvement chaque région avant de passer à la suivante. Ainsi, une erreur qu'aucun Health Check ne détecte n'atteint au plus qu'une seule région, et les deux autres continuent de servir les utilisateurs de celle-ci :

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

Si une mise à jour échoue, Swarm l'annule automatiquement grâce aux paramètres de l'étape 9, et || break met fin à la boucle dès que la commande signale une erreur. Une mise à jour dont le problème n'apparaît que plus tard s'annule à la main avec docker service rollback web-asia.

Maintenance d'une région

Si un serveur doit être redémarré ou mis à jour, retirez-le du service avec docker node update --availability drain et laissez au préalable le failover DNS rediriger ses utilisateurs vers les régions voisines. Après la maintenance, remettez-le en service avec --availability active. Avant de passer au manager suivant, attendez que docker node ls affiche de nouveau les trois managers comme joignables, afin qu'il ne manque jamais deux managers en même temps.

Supervision depuis l'extérieur

Surveillez chaque région séparément et depuis l'extérieur du cluster : accessibilité des points d'entrée, Health Checks des services, état des managers, retard de réplication de la base de données et dates d'expiration des certificats et des domaines. Une alerte doit arriver même quand une région entière se tait. L'article Mettre en place un monitoring serveur montre comment construire cela pour des serveurs individuels.

Distribuer les secrets en toute sécurité

Les mots de passe et les clés n'ont pas leur place dans des variables d'environnement ou des fichiers Compose, mais dans des Docker Secrets. Ceux-ci sont stockés chiffrés dans le journal Raft et ne sont transmis qu'aux services auxquels vous les attribuez explicitement :

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

Pourquoi KernelHost pour un Swarm réparti sur plusieurs continents

Un cluster réparti sur plusieurs continents n'impose pas au fournisseur les mêmes exigences qu'un serveur isolé. En pratique, ce sont ces points qui font la différence :

Vous trouverez une vue d'ensemble de toutes les offres cloud avec leurs prix, ainsi qu'une comparaison des coûts avec les grands fournisseurs cloud, sur la page Louer un serveur cloud.

Erreurs fréquentes et comment les éviter

• Des managers sur deux sites seulement. Si le site qui détient la majorité tombe en panne, le cluster est paralysé. Solution : trois sites, répartition 1-1-1 ou 2-2-1.
• Un nombre pair de managers. Quatre managers ne tolèrent pas plus de pannes que trois, mais alourdissent la coordination. Solution : 3, 5 ou 7.
• Des requêtes qui voyagent entre les continents. Une adresse de service commune à toutes les régions envoie les utilisateurs à l'autre bout du monde. Solution : un service et un point d'entrée par région.
• Des ports Swarm joignables publiquement. Le port 2377 et le réseau overlay n'ont jamais leur place sur l'Internet ouvert. Solution : uniquement via WireGuard ; publiquement, seulement 80, 443 et WireGuard pour les autres nœuds.
• La MTU oubliée. Les grosses réponses restent bloquées, les petites passent. Solution : une MTU overlay de 1370 avec WireGuard à 1420.
• Compter sur ufw pour les ports des conteneurs. Docker contourne ufw pour les ports publiés. Solution : ne publier que le point d'entrée.
• Une base de données dans un volume, sans réplication. Si la région tombe en panne, les données sont inaccessibles. Solution : réplication de la base de données, placement fixe dans sa région.
• Une mise à jour dans toutes les régions à la fois. Une erreur touche alors tous les utilisateurs dans le monde entier. Solution : déployer région par région.
• Un TTL DNS élevé. Avec un TTL d'un jour, le failover ne prend effet que le lendemain. Solution : 60 secondes.
• La réplication à la place de la sauvegarde. Une erreur est répliquée exactement comme des données saines. Solution : des sauvegardes testées en plus, dans un lieu indépendant.

En résumé

• Un Docker Swarm réparti sur trois continents est conçu pour 100 % d'uptime : un site ou un continent entier peut tomber en panne sans que l'application s'arrête.
• Personne ne peut garantir une disponibilité absolue ; les risques restants sont le DNS, les mises à jour défectueuses, la base de données et les certificats, et chacun a sa contre-mesure.
• Trois managers sur trois sites constituent le minimum ; deux sites ne suffisent pas pour un quorum tolérant aux pannes.
• Chaque requête reste dans sa région : un service et un point d'entrée par région, complétés par un Geo-DNS avec Health Checks et un TTL court.
• WireGuard chiffre le trafic du cluster, les ports Swarm restent invisibles, la MTU overlay descend à 1370.
• Swarm réplique des conteneurs, pas des données : les bases de données ont besoin de leur propre réplication, et les sauvegardes restent obligatoires.
• KernelHost propose des sites en Europe, en Amérique du Nord et en Asie-Pacifique, un trafic illimité, une protection DDoS sur chaque site et une facturation PrePaid sans durée minimale.