Workload Availability (HA)

Availability ajoute à un Container, un Deployment ou un projet Compose existant des placements sur des nœuds Docker indépendants. Opfield préserve l’identité, la configuration et les relations de la ressource tout en créant et en remplaçant des instances d’exécution selon sa politique de disponibilité.

La fonctionnalité est disponible en Business et Enterprise. Gérez les instances via la ressource propriétaire plutôt que comme des Containers individuels : la politique détient le nombre de placements, les générations, l’appartenance au routage et le nettoyage.

Le basculement s’effectue de l’une de deux façons. Lorsque chaque nœud Docker, chaque nœud Ingress et chaque relais de la charge de travail exécute une version qui le prend en charge, les nœuds basculent d’eux-mêmes, sans Opfield ; voir Basculement du plan de données. Sinon, Opfield remplace lui-même les placements perdus (basculement côté serveur), comme décrit sur cette page.

Choisir un mode

Mode	Comportement	Quand l’utiliser
Replicated	Maintient de 2 à 32 placements actifs, au plus un par nœud	L’application prend en charge des instances concurrentes
Failover	Maintient un placement actif et crée un remplaçant après la perte d’un nœud	Une seule instance active avec reprise sur un autre nœud est requise

Sans Availability, la ressource conserve son cycle de vie mononœud ordinaire. Chaque placement Compose contient l’ensemble du projet ; Opfield ne répartit pas les services individuels d’une instance entre plusieurs nœuds.

Le nombre de répliques est manuel. La mise à l’échelle automatique sur métriques, les placements multiples d’une même charge de travail sur un nœud et le rééquilibrage opportuniste des instances saines sortent de ce modèle.

Prérequis

L’activation d’Availability nécessite au moins deux nœuds Docker compatibles en ligne. En production, elle nécessite aussi au moins deux relais sur des hôtes autres que l’hôte Opfield, dans des domaines de panne différents ; avec le seul relais local, le basculement dépend de l’hôte Opfield. Voir Combien de relais. Prévoyez une capacité suffisante pour le nombre de répliques souhaité et pour les placements temporaires pendant les mises à jour.

La charge de travail ne doit comporter aucun montage configuré ou observé, y compris des volumes nommés, externes ou en lecture seule, ou des montages de répertoires de l’hôte. Pour Compose, l’ensemble du projet est vérifié. Les données persistantes doivent résider dans des services distincts ; Availability ne copie pas les données locales entre nœuds.

Opfield épingle les images par dépôt et empreinte dans son registre interne et les récupère à l’avance sur les nœuds de secours éligibles. Vérifiez l’accès aux registres, les chemins Relay et Secure Link, ainsi que les bases de données managées dépendantes.

Activer Availability

1. Ouvrez le Container, le Deployment ou le projet Compose et sa section Availability.
2. Sélectionnez Check eligibility et résolvez les incompatibilités.
3. Activez Enable et choisissez Mode. Pour Replicated, définissez Serving placements.
4. Sous Eligible nodes, choisissez All compatible nodes ou Selected nodes avec une liste explicite de nœuds.
5. Examinez les paramètres de remplacement et de déploiement, puis sélectionnez Save.
6. Suivez l’opération et la liste Placements jusqu’à ce que le nombre de placements actifs demandé soit atteint.
7. Vérifiez une vraie requête via la Route, l’accès à la base de données et les journaux de l’application.

Basculer l’interrupteur seul n’applique pas la politique : Save est nécessaire. Un enregistrement réussi signifie que l’état souhaité a été accepté, et non que la création des instances est terminée.

Activer sur une charge de travail en cours d’exécution

Activer Availability sur une charge de travail qui sert déjà ne l’interrompt pas et ne démarre jamais de seconde copie à côté d’elle. Le Container, le Deployment ou le projet Compose en cours d’exécution devient le premier placement sur le nœud où il s’exécute :

• Un Container n’est jamais recréé. Les réseaux de bases de données managées dont il a besoin sont rattachés pendant qu’il s’exécute.
• Un Deployment ou un projet Compose qui exécute déjà l’image qu’Opfield a copiée dans son registre est adopté tel qu’il s’exécute. Un Deployment adopté conserve la liaison de port de son routeur, et un projet Compose adopté ses ports publiés, jusqu’à ce qu’un déploiement les recrée.
• Un Deployment ou un projet Compose qui ne peut pas être adopté tel qu’il s’exécute, parce qu’il a besoin des paramètres de connexion des bases de données managées ou exécute une autre image, est remplacé sans interruption de service là où la politique autorise deux copies (Replicated, ou Failover avec Allow available mode) : un Deployment déploie la nouvelle configuration sur son slot inactif et bascule une fois celui-ci prêt ; un projet Compose reçoit d’abord une copie sur un autre nœud, les Routes passent sur celle-ci, puis l’original est recréé et, en mode Failover, la copie supplémentaire est retirée. Si aucun autre nœud ne peut servir la copie, l’original reste tel quel et l’activation est retentée.
• Un singleton Failover avec Allow available mode désactivé n’exécute jamais deux copies ; il subit donc à la place une courte interruption planifiée : un Deployment crée son nouveau slot avec l’image déjà récupérée avant l’arrêt de l’ancien slot, et revient en arrière si le nouveau slot ne devient pas prêt ; un projet Compose récupère toutes les images avant la recréation de tout service.

Le nœud où s’exécute la charge de travail continue de la servir même lorsque Priority mode place un autre nœud en premier ; le retour sur le nœud prioritaire (failback) la déplace ensuite.

Les Routes continuent d’atteindre la charge de travail d’origine via leur propre Secure Link jusqu’à ce qu’un placement serve via son lien de membre. Ce n’est qu’alors qu’Opfield fait passer la Route sur les membres ; il conserve l’ancien lien 5 secondes de plus pour que les requêtes encore détenues par les workers précédents de nginx puissent se terminer, puis le retire.

Paramètres de remplacement et de déploiement

• Replacement grace — délai d’attente après la perte de la connexion de contrôle du nœud avant de créer un remplaçant. La valeur par défaut est de 15 secondes ; la préparation de l’image, le démarrage et les vérifications de santé prennent un temps supplémentaire.
• Maximum unavailable — nombre de placements qu’une mise à jour planifiée peut rendre indisponibles simultanément.
• Maximum surge — nombre de placements temporaires pouvant exister au-delà du nombre souhaité. Ils nécessitent une capacité supplémentaire.
• Drain interval — délai entre le retrait d’un placement du routage des nouvelles requêtes et son arrêt, afin de permettre aux connexions existantes de se terminer.

Mode prioritaire

Par défaut, Opfield place les instances actives sur les nœuds éligibles selon la capacité libre. Priority mode fait préférer aux deux modes des nœuds dans un ordre fixe. Activez-le sous Eligible nodes et ordonnez la liste avec les boutons haut et bas : le premier nœud est Primary, les suivants sont Backup 1, Backup 2, etc. La liste ne contient que des nœuds éligibles ; les nœuds qui deviennent éligibles plus tard sont ajoutés à la fin. Sélectionnez Save pour appliquer l’ordre.

Les placements actifs vont aux premiers nœuds disponibles dans l’ordre. Lorsqu’un nœud de priorité supérieure revient et reste sain pendant Return to the primary after (300 secondes par défaut, de 0 à 3600), Opfield exécute une opération Failback : il démarre la charge de travail sur ce nœud, y bascule le trafic, puis vide et retire le placement de secours, de sorte qu’un placement serve en permanence. Activer le mode prioritaire ou changer l’ordre déplace la charge de travail de la même manière. Le résumé Availability indique le nœud Primary et d’où la charge de travail est servie (Serving from), avec la mention On backup tant qu’un secours sert.

• Un nœud qui passe hors ligne ou signale une erreur redémarre son délai ; un nœud instable ne reprend donc pas le trafic.
• Le failback ne s’exécute que lorsque la politique est saine et qu’aucune autre opération de la même politique n’est active ; le remplacement, le déploiement et la mise à l’échelle de cette politique passent en premier. Les opérations de politiques différentes s’exécutent en parallèle ; un failback n’attend donc jamais la réparation d’une autre charge de travail.
• Un failback en échec laisse le secours servir et est retenté au bout de 15 minutes. Utilisez Retry dans Operations pour réessayer plus tôt.
• Le failback nécessite un Maximum surge d’au moins 1 afin qu’un placement continue de servir pendant le déplacement ; en mode Replicated, un Maximum unavailable d’au moins 1 suffit aussi. Sinon, Check eligibility émet un avertissement et la charge de travail reste sur le secours.
• Lorsque les nœuds exécutent eux-mêmes le basculement (basculement du plan de données), un failback devient une passation : le nœud actif arrête sa copie avant que le nœud suivant ne démarre la sienne, car le mode de partition strict par défaut n’exécute jamais deux copies à la fois. En mode Failover, la charge de travail ne sert pas pendant l’arrêt de l’ancienne copie puis le démarrage et la mise en état de la nouvelle, généralement 5 à 15 secondes ; en mode Replicated, les autres répliques continuent de servir.
• Après un redémarrage d’Opfield, le temps de bonne santé de chaque nœud repart de zéro ; aucun failback ne s’exécute donc avant l’écoulement du délai.

Dans l’API et MCP (manage_docker_availability), les champs de la politique sont priorityMode, nodePriority (identifiants des nœuds dans l’ordre, primaire en premier) et failbackDelaySeconds.

Routes et liaisons de bases de données

Les Proxy Hosts, les Additional Routes et les Advanced Secure Links peuvent cibler la charge de travail logique. Opfield projette les points de terminaison des placements sains et répartit les nouvelles connexions d’ingress selon le moins de connexions (least connections). Les connexions existantes ne passent pas d’une réplique à l’autre.

Les ports d’hôte publiés ne sont servis que sur le nœud d’origine : les placements sur d’autres nœuds n’en publient aucun et sont joints via des Routes, des Container Links ou des Advanced Secure Links. La vérification préalable le signale avec AVAILABILITY_HOST_PORTS_NOT_REPLICATED.

Un placement ne reçoit du trafic qu’une fois sa charge de travail prête : la vérification de santé de son image signale un état sain si l’image en possède une ; sinon, son port accepte les connexions. Pour un Deployment, l’application du slot actif doit répondre via le routeur du Deployment, et pas seulement le routeur lui-même. La santé des Routes est vérifiée via les Secure Links des placements ; une Route Availability saine est donc affichée en ligne.

Un placement qui ne sert pas, comme un secours ou une copie arrêtée, garde son lien fermé sur le nœud Ingress quel que soit le mode, de sorte qu’aucune requête ne l’atteint : nginx fait échouer la connexion avant d’envoyer quoi que ce soit et passe au placement suivant, ce qui est sûr pour toutes les méthodes.

Si un placement échoue malgré tout, le nœud Ingress essaie le placement suivant : en cas d’erreur de connexion pour toutes les requêtes, et en cas de réponse 502, 503 et 504 pour les requêtes qui peuvent être répétées sans danger, comme GET et HEAD, jusqu’à 5 tentatives en 10 secondes. Les requêtes POST, PATCH et LOCK ne sont pas renvoyées une fois qu’elles ont atteint un placement. Un placement en échec est ignoré pendant une seconde ; chaque placement est aussi listé comme secours jamais ignoré, de sorte que la Route ne manque jamais d’upstreams tant qu’un placement sert.

Lorsque l’hôte d’un placement devient injoignable, les relais abandonnent sa connexion en 3,5 secondes environ et le signalent comme non prêt, et le nœud Ingress ferme son lien. Jusque-là, une nouvelle connexion vers lui coûte au plus 2 secondes avant que nginx n’essaie le placement suivant. Les requêtes déjà en cours vers lui sont retentées sur un autre placement lorsqu’elles peuvent être répétées sans danger ; un POST déjà envoyé reçoit 502. Le lien d’un placement n’abandonne immédiatement que lorsqu’un relais a répondu au sujet de ce placement et qu’un autre placement sert. Lorsqu’aucun relais n’est joignable, par exemple pendant le redémarrage du seul relais, ou qu’aucun autre placement ne sert, les nouvelles connexions sont retenues comme sur tout Secure Link : jusqu’à 3 secondes, ou 8 secondes pour un redémarrage annoncé.

Les liaisons de bases de données managées reçoivent des connexions par placement. Gardez les relations rattachées à la ressource logique plutôt qu’à des noms de Containers temporaires. Pour diagnostiquer une instance particulière, utilisez le sélecteur de placement dans les journaux, la console et la supervision lorsqu’il est disponible.

Un lien entre conteneurs vers une charge de travail Availability suit ses placements sains : chaque nœud consommateur privilégie un placement situé sur son propre nœud, le lien quitte un placement qu’Availability juge défaillant et y revient une fois qu’il réussit de nouveau ses vérifications de santé. Un lien vers un Deployment Availability doit utiliser l’un des ports du Deployment, car le routeur du Deployment ne transmet que ceux-ci.

Mises à jour et santé des répliques

Une mise à jour progressive qui échoue définitivement, ou qui continue d’échouer pendant 3 tentatives ou 15 minutes, est annulée automatiquement : les répliques déjà mises à jour reviennent à l’image et aux paramètres précédents, et la politique conserve l’erreur d’origine. Modifier un paramètre ne recrée plus toutes les répliques.

Un déploiement met à jour chaque copie, y compris la charge de travail d’origine sur son premier nœud, et ne se termine qu’une fois que chaque nœud exécute la nouvelle version de sa copie. Un déploiement interrompu par un redémarrage ou une mise à jour d’Opfield n’est ni déclaré en échec ni annulé : il reprend au retour d’Opfield, avec l’image et les paramètres avec lesquels il a été lancé.

Availability fonctionne avec des images multiplateformes sur Docker 29 et ultérieur, qui utilisent le magasin d’images containerd. Après une mise à jour d’Opfield, une réparation qui trouve le registre interne encore en cours de démarrage réessaie au lieu d’échouer.

Opfield vérifie la santé des répliques toutes les 30 secondes. Une réplique manquante, arrêtée, qui redémarre en boucle ou est défaillante lors de deux vérifications consécutives est retirée du routage et réparée ; elle revient après deux vérifications saines. Un Container autonome qui dispose déjà d’une Route peut activer Availability, et Availability peut être désactivée même lorsqu’aucune réplique n’est saine.

Perte d’un nœud et reprise

En mode bail, les nœuds remplacent eux-mêmes un détenteur perdu ; voir Basculement du plan de données. Avec le basculement côté serveur, un nœud dont la connexion de contrôle tombe est affiché hors ligne au bout de 5 secondes, et ses placements quittent le routage au bout de 10 secondes ; un court redémarrage de Relay ne déplace donc pas le trafic. Après Replacement grace, Opfield démarre un secours préparé si la politique en possède un, et crée sinon un remplaçant sur un nœud éligible disponible. Lorsque le nœud perdu se reconnecte, Opfield répare immédiatement la politique.

Dans les deux modes, une politique comptant moins de placements actifs que demandé et disposant d’une capacité éligible en ligne est réparée sans modification : Opfield vérifie toutes les 15 secondes, en dehors de la période de grâce hors ligne d’un nœud, et à chaque connexion d’un nœud. Un update qui redéfinit le nombre de placements actifs ou la sélection de nœuds actuels répare aussi les placements manquants. Si le nombre demandé n’est toujours pas rétabli, examinez la phase de l’opération, la compatibilité et la capacité des nœuds, la récupération des images, la santé de l’application et les dépendances privées.

Avec le basculement côté serveur, un hôte injoignable peut encore exécuter son ancien processus. Opfield exclut les générations périmées du routage géré et les réconcilie à la reconnexion. Il ne s’agit ni d’une isolation physique du nœud (fencing) ni d’une garantie d’écrivain unique pour un système externe ; seul le basculement du plan de données fait arrêter sa propre copie à un nœud coupé.

Le basculement côté serveur nécessite un plan de contrôle Opfield fonctionnel. Availability n’assure pas la haute disponibilité d’Opfield lui-même, de nginx, des moteurs de bases de données, du stockage du registre ou des volumes partagés. Les bases de données managées et le stockage managé disposent de leur propre Availability sur plusieurs nœuds Storage. Vérifiez séparément la résilience du chemin Relay et chaque dépendance.

Après la reprise, vérifiez le nombre de placements actifs, le trafic client réel, l’accès aux bases de données et le nettoyage des placements périmés. Ne supprimez pas manuellement les Containers enfants pour forcer la fin de l’opération.

Arrêter et démarrer

Stop sur une charge de travail dotée d’Availability arrête les copies en cours d’exécution et conserve tous les placements : les secours restent préparés, et la politique reste saine pendant que la charge de travail est arrêtée. Start démarre les copies qui servaient en dernier, jamais un secours, et conserve les secours ; aucun placement n’est donc supprimé, recréé ou déclaré en échec par un arrêt suivi d’un démarrage. La charge de travail d’origine n’est jamais supprimée : ni à la fermeture d’un bail, ni par le nettoyage des placements périmés, ni comme secours excédentaire. Sur un nœud qui n’est plus sélectionné, elle reste, arrêtée. Un démon Docker occupé par des commandes de longue durée retarde un arrêt, un démarrage ou une réparation (AVAILABILITY_DAEMON_BUSY, retenté automatiquement) au lieu de déclarer les placements en échec. Un démarrage, un arrêt ou un redémarrage demandé pendant que l’opération précédente de la politique est encore en cours est mis en file d’attente et s’exécute ensuite ; les Containers, Deployments et projets Compose se comportent de la même manière.

Un Stop envoyé juste après l’activation d’Availability, avant que les nœuds n’aient pris en charge le basculement, garde toutes les copies arrêtées : aucun nœud ne démarre de lui-même une copie d’une charge de travail arrêtée.

Opérations de plusieurs politiques

Chaque politique exécute une opération à la fois, dans l’ordre. Les opérations de politiques différentes s’exécutent en parallèle : les opérations de réparation, de mise à l’échelle, de déploiement, d’activation et de nettoyage s’exécutent pour au plus 4 politiques à la fois, tandis que le failback, le démarrage, l’arrêt, le redémarrage et la désactivation n’attendent jamais cette limite et s’exécutent à côté.

Désactiver Availability

Désactivez Enable et enregistrez la modification. Dans Disable Availability, choisissez Surviving placement, saisissez le nom de la charge de travail pour confirmer et sélectionnez Disable and keep one.

Le placement survivant continue de s’exécuter et devient la charge de travail ordinaire telle qu’elle s’exécute ; la désactivation ne le redémarre pas et ne le recrée pas :

• Le Container, le Deployment ou le projet Compose d’origine est adopté tel qu’il s’exécute et récupère sa propre politique de redémarrage. Un projet Compose dont les conteneurs ont été préparés par Availability apparaît en dérive sur la page Compose jusqu’à votre prochaine application.
• Une copie de Deployment sur un autre nœud est également adoptée telle qu’elle s’exécute.
• Une copie de Container ou de projet Compose sur un autre nœud s’exécute sous un nom généré par Availability. Elle est remplacée par une copie portant le nom d’origine de la charge de travail sur ce nœud, qui démarre avant la suppression de l’ancienne copie ; le trafic ne subit donc aucune interruption.

Si la politique est en mode bail, la désactivation ferme d’abord le bail et garde la copie survivante en fonctionnement pendant la fermeture. Pendant l’exécution de la désactivation, aucune réparation, mise à l’échelle, aucun failback ni démarrage de la politique ne s’exécute (AVAILABILITY_DISABLE_IN_PROGRESS), et une désactivation qui doit attendre conserve l’état disabling. Une nouvelle tentative conserve le placement survivant choisi en premier.

Attendez la fin de l’opération et du retrait des autres placements. Vérifiez l’instance survivante, les Routes et les liaisons de bases de données : la ressource doit poursuivre son cycle de vie mononœud ordinaire.