Disponibilité, compatibilité et limites

Opfield sépare la disponibilité de la gestion de celle des services. Une panne du plan de contrôle supprime la possibilité d’effectuer et d’autoriser de nouveaux changements ; l’infrastructure déjà appliquée sur les hôtes gérés continue de fonctionner.

Cette distinction est au cœur de la planification de la production : le chemin applicatif visible par les clients, l’application Opfield et Relay peuvent avoir des domaines de panne différents.

Ce qui continue pendant une panne

Panne	Ce qui continue normalement	Ce qui devient indisponible ou incertain
Application Opfield indisponible ; Relay sain	nginx continue de servir la configuration appliquée ; les conteneurs et les bases de données continuent de s’exécuter ; les relais continuent d’admettre de nouvelles connexions Secure Link et de liens de bases de données selon leur dernière politique signée pendant la durée du bail de politique (72 heures par défaut) ; les politiques Availability en mode bail continuent de basculer, tout comme les bases de données et le stockage sur plusieurs serveurs ; la page de statut publique est servie depuis le cache du nœud Ingress	Interface, API, changements de l’état souhaité, Routes et liens nouveaux ou modifiés, révocations, nouvelles opérations gérées et basculement côté serveur d’Availability
Hôte Opfield indisponible ; le relais local s’exécute sur le même hôte	les routes publiques et les charges de travail qui ne dépendent pas de Relay continuent sur leurs propres hôtes ; les liens qui utilisent aussi un relais sur un autre hôte continuent de fonctionner par son intermédiaire, et Availability en mode bail bascule via ces relais	le relais local tombe aussi en panne ; le contrôle des nœuds gérés est indisponible, et les liens transportés uniquement par le relais local sont coupés
Un membre Relay externe indisponible	les charges de travail continuent ; le trafic affecté peut utiliser d’autres membres prêts uniquement là où le placement et les affectations actives fournissent ce chemin	les sessions affectées uniquement au membre en panne peuvent se reconnecter ou échouer ; la nouvelle capacité est réduite jusqu’à la reprise et au rééquilibrage
Aucun relais joignable	les charges de travail ordinaires locales aux hôtes et le trafic public servi directement peuvent continuer	le contrôle des nœuds gérés et les nouveaux liens privés échouent ; les flux existants dépendant de Relay ne sont pas garantis
Un nœud géré indisponible	les ressources des autres nœuds continuent ; une politique Availability en mode bail déplace les slots du nœud vers d’autres candidats en 45 secondes environ, avec ou sans Opfield ; une base de données ou un stockage sur plusieurs serveurs avec basculement automatique passe sur une copie	les ressources détenues par ce nœud sont indisponibles ou périmées ; Opfield ne doit pas modifier à partir d’un inventaire périmé ; avec le basculement côté serveur, les remplacements nécessitent un Opfield en fonctionnement
La clé de licence expire normalement, ou un plan payant est rétrogradé, révoqué ou désactivé	tout pendant la période de grâce (aucune pour la révocation, le transfert ou la désactivation) ; ensuite, les charges de travail existantes, le plan de données, les données, les sauvegardes planifiées, ainsi que la consultation, la supervision et la suppression des ressources payantes existantes	la création de ressources payantes et la modification de leur configuration ; la transmission vers le SIEM et les jetons des registres externes sont suspendus jusqu’au renouvellement ; voir Rétrogradation et expiration
Service de licences injoignable	Opfield, les charges de travail et les fonctionnalités payantes continuent ; une clé payante précédemment valide reste valide pendant 100 jours après son dernier état de licence signé	l’activation d’une clé et la mise à jour d’une installation qui détient ou a détenu un plan payant (une installation Community sans clé se met toujours à jour) ; au-delà de 100 jours, les règles d’après la période de grâce d’une expiration ordinaire
Clé payante valide, cœur commercial manquant ou refusé	l’infrastructure existante et les fonctionnalités Community continuent	les fonctionnalités payantes sont signalées comme non prêtes jusqu’à la réussite de Enable paid features

« Continue » signifie que le dernier état local appliqué avec succès reste actif. Cela ne garantit pas qu’une application dispose de suffisamment de répliques, que sa base de données est saine ni qu’un flux privé existant survit à toute panne réseau.

Workload Availability

Workload Availability (HA) est disponible en Business et Enterprise. Elle prend en charge de 2 à 32 répliques, ou un placement actif avec remplacement, pour les Containers et Deployments sans montages et pour des projets Compose entiers. Lorsque chaque nœud Docker, chaque nœud Ingress et chaque relais d’une charge de travail exécute une version dotée du basculement du plan de données, les nœuds remplacent eux-mêmes un détenteur perdu, même pendant qu’Opfield est en panne, et un nœud isolé arrête sa propre copie. Sinon, Opfield rétablit les placements demandés sur des nœuds éligibles disponibles, ce qui nécessite un plan de contrôle sain. Les deux nécessitent de la capacité, des artefacts et des dépendances ; aucun n’assure la haute disponibilité d’Opfield lui-même ni de nginx. L’ingress nginx est rendu redondant avec les groupes d’ingress.

Bases de données et stockage sur plusieurs serveurs

En Business et Enterprise, les bases de données et le stockage managés peuvent s’exécuter sur 2 à 5 nœuds Storage avec un primaire et des copies. Avec des témoins sur des relais ou d’autres nœuds Docker, une copie prend le relais automatiquement, y compris pendant qu’Opfield est en panne, tant que la politique signée des relais est valide (72 heures par défaut). Deux serveurs sans hôte témoin forment une paire répliquée que vous basculez à la main. Ce qu’un basculement peut faire perdre dépend du moteur et de la durabilité ; voir Bases de données et stockage sur plusieurs serveurs.

La question du relais local

Chaque installation comprend un relais local. Si Opfield et ce relais partagent un même hôte, la perte de l’hôte supprime à la fois la gestion et le transport utilisé par les Secure Links et les sessions des nœuds gérés.

Pour les environnements qui exigent que les connexions privées survivent à la perte de l’hôte Opfield, ajoutez des membres Relay externes dans des domaines de panne indépendants et vérifiez que chaque nœud concerné peut les joindre. Opfield place alors chaque Secure Link sur au moins un relais hors de l’hôte Opfield que ses nœuds peuvent joindre, et Settings → Relay signale les liens qui dépendent de l’hôte Opfield parce que leurs nœuds ne peuvent joindre aucun autre relais. Le simple fait d’exécuter un second conteneur Relay sur la même machine, derrière le même pare-feu, sur la même alimentation ou le même chemin réseau n’améliore pas la tolérance aux pannes.

Testez le chemin applicatif exact. Une Route publique vers un upstream local peut continuer sans Relay, tandis qu’une Route ou une liaison de base de données applicative qui utilise un Secure Link dépend d’un transport Relay joignable.

Compatibilité des versions

Traitez Opfield, Relay, les démons gérés et leurs versions de protocole comme un seul ensemble de versions testé.

Utilisez les versions publiées ensemble par les métadonnées de version et l’installateur pris en charge.
Mettez à jour les membres du Relay Pool un domaine de panne à la fois.
Mettez d’abord à jour des nœuds représentatifs et vérifiez des capacités, un inventaire et une opération réelle récents.
Ne supposez pas que des démons plus anciens ou plus récents arbitraires sont compatibles parce qu’ils peuvent établir une connexion TCP.
Conservez les références d’images approuvées précédentes et la sauvegarde correspondante jusqu’à la fin de la fenêtre d’observation.
Ne revenez pas à une version antérieure à une migration de base de données, sauf si les notes de version le prennent explicitement en charge et qu’un point de restauration coordonné existe.

Le basculement du plan de données nécessite la même version sur chaque participant d’une charge de travail : une politique n’y entre qu’une fois que tous l’ont exécutée pendant 2 minutes, et en sort lorsqu’un nœud Ingress ou un relais reste obsolète pendant 2 minutes. Voir Mises à jour et versions mixtes.

La compatibilité est définie par version, et non sous la forme d’une matrice de toutes les combinaisons historiques de composants : exécutez les démons et les relais de la même version qu’Opfield, et limitez les versions mixtes à la fenêtre de mise à jour. Si votre politique exige une fenêtre de versions mixtes plus longue, testez cette combinaison exacte sur une installation de préproduction et consignez-la comme contrainte propre à l’installation.

Capacité et limites testées

Il n’existe pas de nombre maximal unique et significatif de nœuds, de Routes, de charges de travail, de builds, de bases de données ou de flux privés simultanés. La capacité dépend des ressources des hôtes, du rythme des opérations, de la rétention, de la forme des charges utiles, du placement de Relay, de la charge de build et des fournisseurs externes.

Ne convertissez pas les quotas des plans en garantie de performances. Avant la production, testez une charge de travail représentative au pic attendu plus une marge convenue, et consignez :

la latence de l’API d’Opfield et le délai des files d’arrière-plan ;
les connexions PostgreSQL, la latence, la croissance du stockage et la durée des sauvegardes ;
la mémoire de Redis et la santé de ses files ;
les connexions Relay, la mémoire, le débit, le comportement de reconnexion et l’étalement des affectations ;
le volume et la fraîcheur des rapports des nœuds ;
la concurrence des builds, la taille des artefacts et la pression sur le disque ;
la croissance de la rétention des journaux, de l’audit, des métriques et de Pages ;
le temps de reprise après le redémarrage de chaque composant partagé.

Conservez ces valeurs avec la version et la topologie sur lesquelles elles ont été mesurées, et mesurez à nouveau après toute mise à niveau significative.

Décision de production

Avant d’accepter une charge de travail, documentez les chemins de panne qu’elle tolère, ceux qui nécessitent un relais externe, les services de données qui disposent d’une haute disponibilité indépendante et la personne qui rétablit le plan de contrôle. Exécutez ensuite la liste de contrôle de production et le runbook d’incident sur cette topologie.