Comment fonctionne la bascule dans Opfield, sans Kubernetes

Faire tourner un service sur plus d'un serveur oblige en général à adopter un cluster : Kubernetes ou Docker Swarm, un réseau overlay, et quelqu'un pour s'en occuper. Opfield prend un autre chemin. Chaque serveur reste un hôte Docker ordinaire. Availability ajoute des copies d'une charge de travail sur d'autres serveurs et déplace le trafic quand l'un d'eux tombe. Cet article explique comment cela fonctionne et où se trouvent les limites.

Un réglage sur une charge existante

Availability s'active sur un conteneur, un déploiement ou un projet Compose entier qui existe déjà. Rien n'est reconstruit ni migré. Il y a deux modes :

• Replicated garde de 2 à 32 copies en service en même temps, au plus une par serveur. À utiliser quand l'application supporte plusieurs instances côte à côte.
• Failover garde une copie en service et la remplace sur un autre serveur quand son serveur est perdu. À utiliser quand une seule instance doit tourner.

Il faut au moins deux serveurs Docker en ligne. La charge ne doit avoir aucun montage : Availability ne copie pas les données locales entre serveurs, les données persistantes vivent donc dans des services séparés, comme des bases de données gérées. En production, faites aussi tourner au moins deux relais sur des hôtes autres que celui d'Opfield, dans des domaines de panne différents.

Prêt avant d'en avoir besoin

Une reprise est rapide parce que le travail est fait à l'avance. Opfield copie l'image de la charge dans son registre interne, figée sur un digest exact, et la télécharge à l'avance sur les serveurs de secours. Un conteneur de secours est créé mais pas démarré, si bien qu'une reprise n'a plus qu'à le démarrer. Toutes les copies tournent sur la même image.

Le trafic atteint les copies par les routes. Les nœuds nginx envoient les nouvelles connexions vers la copie saine qui en a le moins ; les connexions existantes restent où elles sont. Chaque copie reçoit sa propre connexion aux bases de données gérées auxquelles la charge est liée.

Les serveurs décident, pas le panneau

Quand un serveur tombe ou se retrouve isolé, la charge passe sur un autre serveur en 45 secondes environ, même quand Opfield est arrêté, en cours de mise à jour ou injoignable.

Depuis la 2.11, les serveurs et les relais d'une charge décident entre eux qui la sert. Il n'y a rien à activer : cela démarre dès que tous les nœuds Docker, nœuds nginx et relais de la charge tournent en 2.11. Chaque copie en service détient un bail qu'elle renouvelle toutes les quelques secondes auprès d'une majorité des votants de la charge. Un serveur qui ne joint plus cette majorité arrête sa propre copie, et le serveur suivant prend le créneau et démarre la sienne. Par défaut, deux copies d'un même créneau ne tournent jamais en même temps, même lors d'une coupure réseau. Un petit service watchdog sur chaque nœud Docker arrête une copie dont le bail a expiré, même si Docker lui-même est bloqué.

Quand Opfield revient, il inscrit au journal d'audit chaque reprise survenue pendant son absence. Les charges dont des composants sont antérieurs à la 2.11 basculent aussi, mais c'est Opfield qui pilote : après la perte d'un serveur, il attend 15 secondes par défaut, puis démarre une copie de secours préparée ou crée un remplacement ailleurs. Ce chemin nécessite qu'Opfield tourne.

Aucun cluster à exploiter

Opfield ne crée ni état Swarm, ni réseau overlay, ni confiance entre serveurs, ni ports de cluster entrants. Chaque serveur se connecte lui-même à Opfield, et les serveurs gérés n'ont besoin d'aucun port d'administration entrant. Les serveurs d'une même charge ne communiquent entre eux que par les relais.

Un point à prévoir : les ports publiés sur l'hôte ne sont servis que sur le serveur d'origine. Les copies sur les autres serveurs n'en publient aucun et sont jointes par les routes.

Quand Opfield lui-même est hors ligne

Opfield n'est pas sur le chemin du trafic. Si l'application Opfield est hors ligne, nginx continue de servir, les conteneurs continuent de tourner et les bases de données gérées tournent avec l'état qui leur a été appliqué en dernier. Avec un relais en bon état, les connexions privées aux bases de données continuent pendant un redémarrage de l'application Opfield. Les relais acceptent de nouvelles connexions selon la dernière politique qu'Opfield a signée pour eux, pendant 72 heures par défaut. Ce qui manque jusqu'au retour d'Opfield, c'est le pilotage central : l'interface, l'API et les nouvelles modifications.

Le relais local d'Opfield s'arrête avec l'hôte d'Opfield. Pour que la bascule survive à la perte de cet hôte, faites tourner au moins un relais sur un autre hôte.

Ce qu'Availability ne fait pas

• Elle ne rend hautement disponibles ni Opfield lui-même, ni le stockage du registre, ni les volumes partagés.
• Le nombre de copies est fixé par vous ; il n'y a pas de mise à l'échelle selon des métriques.
• Elle ne copie pas les données du disque d'un serveur vers d'autres serveurs.

Offres et suite

Availability fait partie des offres Business et Enterprise. La mise en place, les exigences sur les relais et le comportement lors des coupures réseau sont décrits dans les pages Workload Availability et Basculement du plan de données de la documentation.