Relay et Relay Pool

Relay est le transport authentifié qui relie Opfield aux nœuds gérés et transporte le trafic privé pris en charge, comme les Secure Links. Un Relay Pool ajoute des membres afin que la capacité et la disponibilité du transport ne dépendent pas d’un seul domaine de panne. Ce n’est ni un VPN général ni un répartiteur de charge applicatif.

Combien de relais

Exécutez au moins deux relais sur des hôtes autres que l’hôte Opfield, dans des domaines de panne différents : un hôte, une alimentation et un chemin réseau différents. C’est la règle pour toute installation de production et pour toute configuration Availability : Docker Availability et bases de données et stockage sur plusieurs serveurs. Deux relais derrière le même hôte, la même alimentation, le même pare-feu ou la même route forment un seul domaine de panne et comptent comme un seul relais.

Lorsqu’un relais tombe en panne :

• Les flux qu’il transportait passent sur un autre relais sans être interrompus. Les flux Relay peuvent être repris : un flux reprend sur un autre relais, et les sockets de l’application et de la base de données aux deux extrémités ne remarquent pas le déplacement.
• Les nœuds qui l’utilisaient se reconnectent d’eux-mêmes aux autres relais.
• Les liens des membres des charges de travail Availability sont déjà enregistrés sur chaque relais prêt ; ils continuent donc de servir via les autres.

Avec le seul relais local, les Secure Links, les liens vers les bases de données et le stockage, et le basculement du plan de données dépendent de l’hôte Opfield et s’arrêtent avec lui.

Le responsable du réseau fournit des points de terminaison que les nœuds peuvent joindre ; Opfield gère l’enrôlement, l’affectation, le vidage et les mises à jour.

Détails pour l’opérateur : topologie et point de terminaison

Le relais local est un service obligatoire et de longue durée du plan de données, et le seul détenteur public de 9443/tcp. Il authentifie les sessions des nœuds gérés et le trafic des tunnels privés pris en charge.

Un Relay Pool ajoute des membres superviseur/worker et un placement tenant compte des domaines de panne. Les opérateurs vérifient que les domaines physiques sont distincts et annoncent des points de terminaison de workers joignables ; Opfield rééquilibre automatiquement les affectations, et la mise à jour du Relay Pool vide, met à jour et vérifie un membre à la fois.

Opfield ne crée pas de règles de pare-feu, ne traverse pas le NAT et ne crée pas de réseau overlay général. Chaque hôte géré affecté doit joindre le point de terminaison de données de son worker. Pendant un incident Relay, préservez le volume d’identité et évitez d’introduire un chemin alternatif non authentifié.

Topologie

Chaque installation dispose d’un service Relay local associé à Opfield. Les nœuds Relay supplémentaires exécutent un superviseur qui s’enrôle via le processus standard d’identité des nœuds et gère un worker Relay. Opfield distribue une politique signée et les affectations des charges de travail ; les nœuds gérés établissent des connexions sortantes authentifiées vers les points de terminaison Relay qui leur sont attribués.

Relay est un transport, et non un propriétaire de charges de travail. Les démons Ingress, Docker, de bases de données, de supervision et de build continuent de détenir leurs opérations sur l’hôte. Relay transporte le contrôle authentifié et les flux privés pris en charge sans devenir un tunnel réseau général.

Ajouter un nœud Relay

1. Préparez un hôte dédié dans le domaine de panne physique ou réseau prévu.
2. Assurez-vous que son adresse annoncée est joignable par les nœuds participants sur le port TCP 9443.
3. Ouvrez Settings → Relay et choisissez Add relay node, ou créez un relais depuis Nodes.
4. Saisissez le nom d’affichage et la Relay Address joignable.
5. Exécutez la commande d’installation à usage unique générée sur l’hôte cible.
6. Attendez que la boîte de dialogue d’enrôlement se ferme une fois ce nœud en ligne.
7. Confirmez que l’instance Relay se signale prête avant d’affecter ou de rééquilibrer du trafic.

Un nœud Relay en attente ne constitue pas de la capacité du pool. Ne considérez pas un enregistrement créé en base ou un superviseur installé comme prêt tant qu’Opfield n’a pas vérifié le point de terminaison du worker et son état de santé.

L’installateur attend que le superviseur soit enrôlé et connecté à Opfield, et se termine sinon en indiquant la raison. Un hôte physique détient un seul relais du pool : l’enrôlement d’un nouveau relais sur un hôte qui en possède déjà un est refusé avec le nom de ce relais, et rien n’est enrôlé ; réenrôlez ce relais ou retirez-le d’abord. Pour changer l’utilisateur d’un relais enrôlé, réexécutez son installateur sans --token et avec OPFIELD_RELAY_RUN_USER : il conserve son identité et reprend l’adresse d’Opfield, l’épinglage du certificat, l’adresse annoncée et le port depuis sa configuration. Voir Exécuter un démon sans root.

Placement et affectation

Placez chaque membre dans son propre domaine de panne ; voir Combien de relais. Vérifiez que chaque hôte géré peut joindre chaque relais susceptible de lui être affecté. L’étalement des affectations (spread) détermine combien de relais prêts reçoivent les nouvelles connexions des charges de travail ; augmenter l’étalement améliore la redondance, mais consomme davantage de connexions et de mémoire.

Les relais les plus proches d’abord

Les démons mesurent le temps d’aller-retour vers chaque relais qu’ils peuvent joindre et le signalent à Opfield. Pour chaque point de terminaison, Opfield additionne le temps d’aller-retour depuis le nœud du point de terminaison et le temps d’aller-retour moyen depuis les nœuds qui s’y connectent, et désigne les relais les plus proches comme primaires ; les emplacements restants de l’étalement vont à des relais de secours dans d’autres domaines de panne. Les relais situés à environ 20 % ou 3 ms du plus proche partagent le rôle de primaire ; les relais d’un même centre de données se partagent donc la charge. Les primaires ne changent que lorsqu’un autre relais est nettement plus proche, d’au moins 30 % et 5 ms ; la gigue des temps d’aller-retour ne déplace donc jamais le trafic. Tant qu’un nœud n’a pas signalé de mesures, le placement utilise comme auparavant un hachage stable du point de terminaison.

Membres Availability et hôte Opfield

Deux règles s’appliquent en plus de l’étalement :

• Les Secure Links des placements Workload Availability (liens des membres) sont placés sur chaque relais prêt qui prend en charge le basculement du plan de données (availability_lease_v2), quel que soit l’étalement. Les placements de secours y restent aussi enregistrés, mais ne reçoivent pas de trafic tant que leur nœud ne détient pas la charge de travail ; après une reprise, le nouveau détenteur est donc déjà joignable via chaque relais. Un nouveau lien de membre démarre immédiatement sur ces relais.
• Chaque autre Secure Link conserve son étalement, mais inclut au moins un relais qui ne s’exécute pas sur l’hôte Opfield, dès que ses nœuds ont mesuré un tel relais comme joignable. Un lien que seul le relais local transporte s’arrête avec l’hôte Opfield. Lorsque les nœuds d’un lien ne peuvent joindre aucun relais hors de l’hôte Opfield, le lien reste là où il fonctionne et Settings → Relay affiche un avertissement : « No relay off the Opfield host is reachable from <node>: traffic of this link depends on the Opfield host. » Le pool reste sain ; l’avertissement n’est pas une alerte.

Après une mise à jour vers une version dotée de ces règles, attendez-vous à un rééquilibrage automatique pour chaque lien dont le placement change.

Le rééquilibrage est automatique. Lorsque la capacité Relay ou l’étalement des charges de travail change, Opfield lance un rééquilibrage une fois que le nouveau placement est resté stable pendant 30 secondes ; les connexions existantes se vident sans interruption. Avant un déplacement, les démons qui utilisent le point de terminaison sondent le nouveau relais ; une sonde que le relais refuse uniquement parce que la cible est un secours Availability compte comme vérifiée, et au plus 2 sondes s’exécutent simultanément par démon. Le rééquilibrage automatique est suspendu pendant une mise à jour du Relay Pool, mais les charges de travail continuent de quitter les membres vidés.

Le pool reste healthy en régime établi. Opfield distingue trois types d’erreurs de rééquilibrage :

• Les conditions transitoires, comme un démon occupé, un nœud non connecté, un relais local en cours de redémarrage ou une préparation interrompue par un redémarrage d’Opfield, ne comptent pas comme des échecs. Le déplacement est différé avec la note « Deferred by a transient condition and retried automatically » et retenté au bout de 30 secondes, ce délai doublant jusqu’à 5 minutes ; le pool ne se dégrade pas.
• Les échecs réels dégradent le pool et sont retentés automatiquement au bout de 5 minutes ; Rebalance les retente immédiatement.
• Une charge de travail supprimée pendant un rééquilibrage le quitte simplement ; les autres déplacements se poursuivent.

Relais sous charge

Un relais à court de capacité, par exemple de CPU, de mémoire ou de descripteurs de fichiers, refuse les nouveaux tunnels avant de faire échouer ceux qu’il transporte. Les liens vers les bases de données et le stockage disposent d’une part réservée et sont refusés en dernier. Lorsqu’un relais refuse ainsi un nouveau tunnel, les démons essaient d’abord tous les autres relais connectés à sa place, pendant 30 secondes au début et jusqu’à 5 minutes tant qu’il continue de refuser. Les nouvelles connexions vont aux autres relais ; les flux déjà ouverts restent où ils sont. Un relais qui refuse et qui est le seul restant reçoit tout de même de nouvelles connexions à un débit limité, afin de les reprendre dès qu’il les admet.

Les journaux des démons le montrent sur chaque nœud qui utilise le relais : un avertissement « relay refuses new tunnels under load », un rappel « still refuses » chaque minute, et « admits again » lorsqu’il est rétabli. Aucune action n’est nécessaire ; si un relais refuse souvent, donnez-lui davantage de ressources ou ajoutez un autre relais au pool.

Relais que les nœuds ne peuvent pas joindre

Un relais peut être connecté à Opfield et rester injoignable pour les nœuds sur son adresse annoncée, par exemple en l’absence de redirection de port ou derrière un pare-feu. Lorsque la plupart des nœuds qui mesurent un relais ne peuvent pas joindre son port relais, le relais ne reçoit plus de nouvelles affectations. Settings → Relay l’affiche comme unreachable avec « Nodes cannot reach <address>; check the port forward and firewall. It gets no connections meanwhile. », et l’événement de notification Relay Unreachable by Nodes (critique par défaut) se déclenche. Les deux disparaissent lorsque les nœuds joignent à nouveau le relais. Juste après le redémarrage d’un relais pour une mise à jour, les nœuds signalent encore ce qu’ils ont mesuré pendant son indisponibilité ; ces rapports ne comptent que s’ils persistent au-delà du redémarrage.

Les relais sans Opfield

Opfield signe la politique qu’il envoie à chaque relais en l’assortissant d’un bail. Un relais continue d’admettre des connexions selon sa dernière politique signée jusqu’à l’expiration de ce bail ; les Secure Links et les liens vers les bases de données continuent donc d’ouvrir de nouvelles connexions via un relais distant pendant qu’Opfield est arrêté, mis à jour ou injoignable. Définissez le bail dans Settings → Relay sous Policy lease : 72 heures par défaut, de 1 heure à 7 jours (168 heures).

Grant lifetime (de 1 à 224 heures, 4 par défaut) définit la durée de validité des autorisations de points de terminaison et de connexions nouvellement émises. Les autorisations d’un membre du Relay Pool durent toujours au moins un tiers de plus que le bail de politique (96 heures avec les valeurs par défaut) ; un relais ne se trouve donc jamais à court d’autorisations tant qu’il admet encore selon sa dernière politique. Une rotation de la clé de signature des autorisations attend que chaque relais ait appliqué la nouvelle clé ou que son bail ait expiré. Un relais 2.10 conserve un bail de 15 minutes et plafonne ses autorisations à 48 heures jusqu’à sa mise à jour.

Ce qui nécessite Opfield : les Routes et liens nouveaux ou modifiés, les révocations, les nouvelles autorisations, l’enrôlement et toute opération de gestion. Le relais local s’arrête avec l’hôte Opfield ; seuls les relais situés sur d’autres hôtes transportent donc du trafic lorsque tout l’hôte est en panne. Lorsqu’un relais se reconnecte après une interruption, le journal d’audit enregistre la période pendant laquelle il a fonctionné sur sa dernière politique sous relay.instance.policy.stale_period, avec from et to.

Lorsqu’Opfield ou un relais revient, le relais reçoit chaque changement de politique dès qu’il est reconnecté, et les Secure Links qui continuent de servir ne sont pas démantelés : si l’actualisation d’un lien échoue parce qu’un nœud ne s’est pas encore reconnecté, le lien conserve son point de terminaison Relay et Opfield réessaie.

Enregistrements et changements d’autorisations

• Changements de génération d’un point de terminaison. Lorsqu’un point de terminaison passe à une nouvelle génération, par exemple après la rotation du certificat de sa cible ou le déplacement de sa cible vers un autre nœud, le relais garde l’enregistrement précédent en service, avec ses tunnels, jusqu’à l’enregistrement de la nouvelle génération. Les tunnels ne sont fermés que lors de changements de route ou d’affectation et pour les points de terminaison supprimés.
• Autorisations en avance sur la politique. Un démon peut recevoir une autorisation avant que son relais ne dispose de la politique qui l’inclut. Le relais attend alors cette politique jusqu’à 10 secondes au lieu de refuser, et un enregistrement refusé avec « does not match policy » par un relais plus ancien est retenté toutes les 0,2 à 0,4 seconde pendant les 10 premières secondes.
• Démons injoignables. Un relais abandonne la connexion d’un démon dont l’hôte n’acquitte pas les données en 2 secondes environ, généralement environ 3,5 secondes après que l’hôte est devenu injoignable. Ses enregistrements et tunnels prennent fin avec elle, et les routes Availability passent sur d’autres placements. Un démon simplement occupé conserve sa connexion, car son hôte continue d’acquitter.
• Démons en cours de redémarrage. Un démon Docker qui redémarre en douceur l’annonce ; le relais conserve ses enregistrements jusqu’à 15 secondes, le temps que le processus suivant s’enregistre, et répond entre-temps aux nouveaux tunnels par « target endpoint is restarting », ce que les nœuds Ingress retiennent au lieu d’échouer. Voir Redémarrages du démon Docker.

Révocation des routes

Lorsqu’une Route ou un lien est supprimé ou que sa cible change, Opfield envoie à chaque relais une politique qui révoque l’ancienne route. Un relais qui ne l’a pas appliquée dans les 90 secondes est considéré comme périmé pour les routes révoquées : Opfield le retire de leurs candidats, et le démon du point de terminaison refuse ces routes passant par lui, car chaque tunnel porte la route pour laquelle il a été admis. Les autres routes du relais continuent de fonctionner. Dans Settings → Relay, un tel relais affiche « Revocation of N revoked routes pending », puis « Stale for revocation of N revoked routes » jusqu’à ce qu’il applique la révision de politique requise.

Vider, mettre à jour et retirer

Drain dirige les nouveaux tunnels vers d’autres membres. Les flux existants peuvent continuer jusqu’à 10 minutes, puis sont déconnectés ; Force disconnect met fin immédiatement à l’attente. Resume remet le membre en service. Le vidage, la remise en service et la déconnexion forcée nécessitent admin:system. Un membre non connecté peut être vidé ; le vidage s’applique à sa reconnexion. Resume et Force disconnect nécessitent un membre connecté et sont refusés sinon (409 RELAY_NOT_CONNECTED).

Une mise à jour du Relay Pool effectue elle-même la procédure progressive : elle vide chaque membre distant, met à jour son superviseur puis, via le superviseur mis à jour, son worker, vérifie les deux et remet le membre en service avant de passer au suivant. Elle attend jusqu’à 30 minutes la fin des flux de longue durée sur un membre, comme les pools de connexions aux bases de données et les WebSockets ; elle déconnecte ensuite ceux qui restent, enregistre une déconnexion forcée dans le journal d’audit et continue. Force disconnect met fin plus tôt à l’attente. Une exécution en échec libère les vidages qu’elle a effectués. Un membre non connecté, par exemple parce que son hôte est en panne, ne bloque pas la mise à jour : l’exécution l’ignore, enregistre Skipped: the relay is not connected; it is updated when it reconnects dans son étape, met à jour les autres membres et le relais local, puis se termine. Settings → Relay affiche le membre ignoré et, une fois celui-ci reconnecté, la mise à jour du Relay Pool est à nouveau proposée et ne met à jour que les membres encore en retard. La même exécution met à jour le relais local en dernier. Lorsqu’un autre relais du pool est prêt, connecté et capable de servir chaque charge de travail que transporte le relais local, et que le relais local en cours d’exécution est en 2.11.1 ou ultérieur, l’exécution vide d’abord le relais local de la même manière : ses charges de travail passent sur les autres relais, le vidage attend comme ci-dessus, puis Opfield recrée le conteneur du relais, vérifie qu’il exécute la version cible et le remet en service. Le registre interne, que seul le relais local sert, reste sur lui : un relais en cours de vidage continue d’admettre les récupérations d’images, et une récupération coupée par la recréation est renvoyée par le démon Docker. Sinon, le relais local est recréé immédiatement, et les connexions qui passent par lui tombent une fois pendant environ une seconde puis se reconnectent : lorsqu’aucun autre relais n’est prêt, lorsque le relais local en cours d’exécution est antérieur à 2.11.1 (la première mise à jour du Relay Pool vers 2.11.1 ou ultérieur le recrée donc encore immédiatement), lorsqu’un démon situé sur le chemin d’une charge de travail ne prend pas en charge le Relay Pool, lorsque le nœud d’une charge de travail ne joint aucun relais hors de l’hôte Opfield, ou lorsque les charges de travail du relais local n’ont pas été déplacées dans les 5 minutes qui suivent le vidage. L’étape du relais local dans l’exécution en indique la raison. Une fois la recréation du relais local engagée, l’exécution ne peut plus être abandonnée (409 RELAY_UPDATE_COMMITTED) et va jusqu’au bout, ou ramène le relais local à sa version précédente en cas d’échec. En 2.11, les versions de Relay nécessitent Opfield 2.11 ou ultérieur, et Opfield ne propose pas de mise à jour tant que son relais local a deux versions mineures ou plus de retard sur la cible.

Avec un seul relais, sa recréation interrompt brièvement le trafic Secure Link : les requêtes ouvertes via l’ancien relais à ce moment-là prennent fin, et les démons se reconnectent en une fraction de seconde après que le nouveau relais écoute. Les nœuds Ingress retiennent les nouvelles connexions Secure Link jusqu’à 3 secondes pendant le retour du relais ou du démon cible ; les démons actuels constatent donc une latence supplémentaire plutôt que des réponses 502. Un relais 2.10 est arrêté au bout de 2 secondes au lieu d’attendre le délai d’arrêt de 10 secondes de Docker. Lors d’une mise à jour depuis 2.10, mettez à jour les démons des nœuds avant le Relay Pool, afin que le relais recréé trouve des démons qui se reconnectent rapidement. Des mises à jour de Relay sans aucune interruption nécessitent un second relais dans le pool.

Les relais votent pour le basculement du plan de données, et un relais qu’un administrateur a autorisé à héberger des témoins vote aussi pour les bases de données et le stockage sur plusieurs serveurs (Settings → Relay, colonne Witnesses). Avant de vider un relais, la mise à jour attend que les autres votants et candidats de ses politiques Availability soient de retour et votent, et après le redémarrage elle attend que le relais vote à nouveau (au plus 3 minutes) ; une mise à jour de relais ne retire donc jamais une seconde voix à une politique.

Un relais installé sur une machine qui appartient à quelqu’un d’autre peut s’exécuter en mode protégé, ce qui tient les administrateurs d’Opfield à l’écart de cet hôte.

Retirez un relais distant une fois vidé et lorsque plus rien ne lui est affecté. Un membre hors ligne peut aussi être retiré, mais seulement après l’expiration de sa politique signée, s’il n’a pas été vu depuis au moins 90 secondes, et seulement si chaque charge de travail concernée est servie par un membre restant prêt ; Opfield refuse un retrait qui laisserait un point de terminaison orphelin. Tant que la politique n’a pas expiré, le membre pourrait encore admettre des connexions de son propre chef. Pour un membre hors ligne, Settings → Relay affiche Can be removed after avec la date et l’heure dans votre fuseau horaire et garde Remove désactivé jusque-là ; un retrait anticipé est refusé avec 409 RELAY_OFFLINE_REMOVAL_UNSAFE, dont le message et details.removableAfter indiquent la même heure.

Retirer l’enregistrement dans Opfield ne remplace pas la mise hors service normale de l’hôte. Désinstallez le superviseur et retirez le matériel de l’hôte selon le processus d’exploitation documenté.

Reprise de Relay en 2.11

Opfield répare lui-même les problèmes courants de confiance et de certificats de Relay :

• Certificats. Les certificats serveur de Relay sont renouvelés automatiquement avant leur expiration ; voir Renouvellement des certificats. Chaque membre indique si son certificat arrive à expiration, a expiré ou n’a pas pu être renouvelé. Renew certificate apparaît pour un certificat expiré ou un renouvellement en échec et nécessite que le membre soit connecté.
• Confiance dans la politique, relais local. Si le relais local refuse la politique signée d’Opfield, Opfield réépingle automatiquement la clé de signature active, au plus une fois toutes les 10 minutes, et enregistre la reprise dans le journal d’audit. Un relais local dépourvu de cette capacité affiche un message avec la procédure manuelle ; mettez d’abord à jour le Relay Pool.
• Confiance dans la politique, membres distants. Un membre distant qui ne fait plus confiance à aucune clé avec laquelle Opfield peut signer est marqué pour réenrôlement.
• Réenrôlement. Pour un membre distant qui nécessite un réenrôlement, dont le certificat a expiré ou qui est hors ligne ou en échec, Re-enroll émet une commande d’installation à usage unique, valable 7 jours, épinglée sur la version de Relay qu’exécute le pool. Opfield n’accepte le jeton que depuis l’hôte propre du membre. Le membre conserve sa place et ses affectations ; sur l’hôte, le superviseur met de côté son identité précédente et la restaure si Opfield refuse l’enrôlement. L’installateur attend l’enrôlement et se termine par une erreur lorsqu’Opfield refuse le jeton (déjà utilisé, expiré, émis pour un autre relais ou exécuté sur un autre hôte) ; le relais continue alors de fonctionner avec son identité précédente. Pour conserver un relais tel quel, réexécutez l’installateur sans --token. Le relais local ne peut pas être réenrôlé ; Opfield le rétablit automatiquement.
• Connexions après renouvellement ou réenrôlement. Les nœuds Docker et Ingress suivent le certificat renouvelé ou réenrôlé d’un membre sans redémarrage du démon. Les connexions établies le restent pendant un renouvellement ; une connexion qui tombe est reconstruite avec le nouveau certificat et la nouvelle adresse.
• État perdu. Un relais qui redémarre sans sa politique stockée, par exemple après la réinitialisation de son fichier de données, reçoit à nouveau sa politique dès sa reconnexion au lieu de refuser les connexions avec « policy snapshot is required ».
• Redémarrages du relais local. Avec Automatic recovery activé, Opfield redémarre un relais local qui a planté ou qui est bloqué. Il ne touche pas à un redémarrage ou à un arrêt lancé par quelqu’un d’autre, quelle que soit sa durée, et se reconnecte au nouveau relais en quelques secondes. Un docker stop du relais local effectué par un opérateur est tout de même annulé, 2 secondes après la fin de l’arrêt. Un nœud dont la connexion tombe pendant un redémarrage du relais n’est affiché hors ligne qu’au bout de 5 secondes, et les démons retentent leurs enregistrements avec un délai croissant jusqu’à 15 secondes, immédiatement dès que le relais est à nouveau joignable.

Vérifications en cas d’incident

Pour un avertissement Relay, examinez le processus du relais local ou du worker distant, le volume d’identité, le chemin d’autorisation PostgreSQL, le point de terminaison annoncé, l’écouteur sur 9443, la fraîcheur de la politique et la joignabilité des nœuds affectés. Préservez les journaux et l’identité avant tout redémarrage. Après la reprise, vérifiez les reconnexions des nœuds, les Secure Links, les liaisons de bases de données, les flux actifs, l’état des affectations et l’avertissement du tableau de bord.

Validation de la capacité et de la résilience

Un relais n’ajoute de la disponibilité que dans son propre domaine de panne, et seulement si les nœuds gérés peuvent le joindre. Testez la connectivité depuis des réseaux Ingress, Docker, Storage, Monitoring et Build Worker représentatifs avant d’augmenter l’étalement des affectations. Un second relais derrière le même hôte, la même alimentation, le même pare-feu ou la même route ajoute de la capacité, pas de la disponibilité.

Observez le nombre de connexions, les flux actifs, la mémoire, le taux de reconnexion et les échecs d’admission sous charge normale. Prévoyez une marge suffisante pour qu’un membre restant puisse accepter les nœuds réaffectés lorsqu’un membre est vidé ou indisponible. Un rééquilibrage pendant un incident peut augmenter la charge de reconnexion ; rétablissez donc d’abord la dépendance défaillante, sauf si la concentration des affectations est elle-même le problème.

Reprise et retour arrière

Si la mise à jour d’un membre échoue, la mise à jour du Relay Pool se met en pause ou libère ses vidages ; relancez ou abandonnez l’exécution, et rétablissez la version signée réputée saine du superviseur et du worker via le chemin de mise à jour pris en charge. Ne copiez pas de binaires ni de matériel d’identité depuis un autre membre. Vérifiez son point de terminaison annoncé et sa disponibilité avant de le remettre dans les affectations.

Si l’état de contrôle du pool est sain mais qu’un réseau ne peut pas se connecter, corrigez le routage, le DNS, le pare-feu ou le NAT pour ce point de terminaison annoncé plutôt que de remplacer des identités Relay. Si l’identité d’un membre distant est perdue ou n’est plus de confiance, utilisez Re-enroll avant d’envisager un enrôlement de remplacement, et ne retirez un ancien enregistrement qu’une fois ses affectations en sécurité. Pour un incident du relais local, préservez l’identité configurée et le volume de données ; recréer le conteneur sans eux crée une identité de transport différente et inutilisable.

Après toute reprise, testez une nouvelle session de nœud géré et un vrai chemin privé, comme un Secure Link ou une liaison de base de données. Les seuls flux de longue durée existants peuvent masquer une incapacité à admettre de nouvelles connexions.

Pour la matrice d’impact client lorsqu’Opfield, le relais local ou tous les relais sont indisponibles, poursuivez avec Disponibilité, compatibilité et limites.