La haute disponibilité ne consiste pas seulement à ajouter un second dispositif — il s'agit de s'assurer que le bon VIP reste sur le bon nœud.
Avoir un second dispositif dans une couche ADC ne signifie pas en soi une haute disponibilité. Les questions critiques sont : quel nœud détient le VIP lors d'une panne, les deux nœuds partagent-ils la même configuration, et les stick tables et compteurs de sécurité survivent-ils à un failover. Lorsque ces éléments ne fonctionnent pas ensemble, le failover se produit — mais l'expérience utilisateur et le comportement de sécurité se dégradent.
Le VRRP classique est suffisant pour la plupart des scénarios, mais ne résout pas chaque problème. Un nœud peut sembler en cours d'exécution, un peer VRRP peut encore être actif, pourtant l'interface pertinente peut avoir perdu son lien ou la gateway peut être devenue inaccessible. Si le dispositif continue à détenir le VIP dans cet état, le trafic afflue vers un nœud qui semble actif mais ne peut pas atteindre le monde extérieur.
Dans les déploiements gérés manuellement, la synchronisation de configuration est un risque séparé. Qu'un changement effectué sur un nœud ait été transmis à l'autre, si les ensembles de certificats et de règles sont égaux, ou quel dispositif a conservé les logs — tout cela nécessite une vérification constante. S'il n'y a pas de réponse claire à « les deux nœuds sont-ils vraiment identiques ? », le cluster n'est pas une construction fiable mais un point de panne différé.
L'incompatibilité matérielle est l'une des pannes silencieuses les plus dangereuses. Un nœud renouvelé avec un nom d'interface réseau différent, un ensemble de cœurs CPU différent ou une capacité mémoire différente peut briser le comportement du cluster au pire moment possible. Ces différences doivent être détectées lors de l'intégration au cluster, pas pendant un événement de failover.
TR7 HA Clustering adresse tous ces risques ensemble : failover VIP, décisions link/gateway contrôlées par TR7, synchronisation, flux de maintenance contrôlé et contrôles de compatibilité matérielle — tous gérés dans un seul modèle.
Notre approche
TR7 implémente le clustering à deux nœuds avec un plan VIP, une surveillance active, une synchronisation, une validation matérielle et une gestion contrôlée des changements fonctionnant ensemble.
Deux nœuds gérés comme un seul ADC logique
Les paramètres du cluster sont définis avec une topologie partagée entre les deux nœuds. L'interface de gestion affiche ce nœud et le nœud pair dans le même modèle ; les changements de règles, certificats et services sont gérés avec le comportement du cluster en tête.
Le failover VIP est déterminé par VRRP et les options de surveillance TR7
La propriété des VIPs peut être gérée avec le VRRP classique ou augmentée par les décisions de surveillance link, gateway ou link+gateway de TR7. Cela permet un failover basé sur l'accessibilité réseau réelle plutôt que sur la vivacité du pair seule.
La compatibilité matérielle est validée lors de l'intégration au cluster
La liste des cœurs CPU, les noms d'interfaces réseau et la taille mémoire sont comparés entre les deux nœuds. Les incompatibilités matérielles sont détectées lorsqu'un nœud rejoint le cluster — pas laissées à se manifester lors d'un événement de failover.
Le mode de synchronisation manuelle permet des changements de maintenance contrôlés
La synchronisation automatique peut être temporairement mise en pause. L'opérateur effectue un changement sur un nœud, teste le résultat et, une fois vérifié, pousse délibérément tous les changements vers le nœud pair.
Capacités
HA Clustering gère le comportement de haute disponibilité locale — de la propriété VIP à la réplication d'état — dans une seule interface.
Le failover VIP basé sur VRRP maintient les adresses de service stables
TR7 utilise un modèle VRRP pour gérer quel nœud détient chaque adresse VIP. Le comportement MASTER et BACKUP est généré automatiquement pour chaque interface pertinente. Lorsque le nœud actif se déconnecte, le VIP se déplace vers le pair et le trafic utilisateur continue sur la même adresse. Ce modèle rend l'infrastructure Linux éprouvée disponible via le modèle de gestion TR7.
Le mode de bascule se choisit par service, pas par équipement
Une paire d'équipements TR7 n'a pas à adopter une personnalité unique. Une application sensible à la latence peut tourner en actif-actif sur les deux nœuds pendant que l'application héritée liée à une licence, juste à côté, tourne en actif-passif — même cluster, même console. C'est ce qui rend une migration supportable : les services passent en actif-actif un par un, chacun après avoir fait ses preuves, au lieu que tout le parc change de comportement en une nuit et que tout le monde découvre ensemble si cela a marché.
La surveillance des liens et gateways comble les angles morts de VRRP
TR7 ne restreint pas le failover IP du cluster au seul VRRP ; les méthodes link, gateway ou link+gateway sont également disponibles. En mode link, l'état du carrier de l'interface est évalué ; en mode gateway, l'accessibilité upstream est vérifiée. En mode link+gateway, les deux signaux sont évalués ensemble pour une décision de failover plus robuste. Cela aide à empêcher un VIP de rester sur un nœud qui semble actif mais dont le chemin réseau est brisé.
Les topologies Active-Passive et Active-Active s'exécutent dans le même modèle cluster
En Active-Passive, un nœud porte les VIPs de service pendant que l'autre attend en standby. En Active-Active, différents VIPs peuvent être distribués sur les deux nœuds de sorte que les deux dispositifs transportent du trafic en direct. Lorsqu'un nœud tombe en panne, l'autre prend la propriété de ses VIPs. Cette approche permet à la stratégie de failover et à l'utilisation de la capacité du dispositif d'être façonnées par la préférence architecturale.
Les changements de configuration et de données sont propagés automatiquement au pair
Avec la synchronisation automatique activée, chaque opération d'insertion, de mise à jour et de suppression est envoyée au nœud pair. Les opérateurs n'ont pas besoin d'écrire une automatisation séparée, d'effectuer des copies de fichiers manuelles ou de planifier des tâches de synchronisation. Garder les configurations de règles, certificats et services cohérentes sur les deux nœuds devient simple. Cela réduit l'ambiguïté « le pair est-il vraiment le même ? » au moment du failover.
Les stick tables et compteurs sont préservés par la réplication peer
Les stick tables, les compteurs de rate limiting et l'état basé sur l'IP source peuvent être répliqués vers le nœud pair. Lorsqu'un failover se produit, le comportement utilisateur ne repart pas de zéro. Les décisions captcha, rate limit ou de routage de session continuent de manière plus cohérente après un événement de panne. Cette fonctionnalité cible non seulement le transfert de VIP mais aussi la préservation de l'état de décision.
Les incompatibilités matérielles sont détectées tôt lors de l'intégration
L'ensemble des cœurs CPU, les interfaces réseau et la RAM des nœuds rejoignant le cluster sont comparés. Un nom d'interface différent, une NIC manquante ou une incompatibilité mémoire est traitée comme une erreur dès le départ. Cela aide à empêcher les différences matérielles silencieuses de se manifester lors d'un failover. Cela réduit le risque opérationnel particulièrement lors des cycles de renouvellement matériel et de remplacement de nœud de remplacement.
Le mode de synchronisation manuelle ouvre un espace de test sécurisé pour la maintenance planifiée
Lorsque la synchronisation manuelle est activée, la propagation automatique des changements est mise en pause. L'opérateur peut tester une nouvelle règle, un certificat ou un comportement de service sur un nœud. Une fois la validation terminée, le changement est poussé vers le pair via un flux syncAll ou requestSyncAll. Ce modèle empêche un changement incorrect de se propager instantanément sur l'ensemble du cluster.
Les IPs de gestion du cluster sont maintenues séparées du trafic utilisateur
Une IP du réseau de gestion 241.0.1.0/24 est assignée pour chaque ID de cluster. La communication intra-cluster est conceptuellement séparée du trafic de service utilisateur. La valeur d'ID de cluster est utilisée dans la plage 1-254, chaque ID correspondant à une IP de gestion dédiée. Cette séparation rend le trafic de synchronisation et de communication peer plus prévisible à gérer.
Profondeur opérationnelle
Le HA clustering est planifié avec les slots VRRP, la communication unicast, les paires d'IPs de gestion, le diff de configuration, le comportement de failback et l'intégration GTM.
Gestion des slots VRRP
Dans les scénarios Active-Active, 2 slots VRRP représentant le comportement MASTER et BACKUP peuvent être générés par interface. Les valeurs virtual_router_id et priority sont définies selon le rôle cluster. Cette structure permet à la propriété des VIPs dans le même sous-réseau d'être gérée sans conflits.
VRRP unicast
Dans les réseaux de centres de données modernes, le trafic VRRP multicast peut être filtré par certaines politiques de switches. TR7 atténue cela en gérant les informations du nœud pair via une approche peer unicast. Le trafic VRRP s'écoule alors de manière contrôlée via l'IP du nœud pair attendu.
Mode de décision link et gateway
La méthode IP du cluster peut être définie sur vrrp, link, gw ou link+gw. La méthode link décide selon l'état de l'interface, gw selon l'accessibilité de la gateway et link+gw selon la combinaison des deux signaux. Ces options rendent le comportement des VIPs plus réaliste dans différentes conceptions réseau.
Paire d'IPs de gestion
La synchronisation du cluster s'exécute sur une paire d'IPs définie pour chaque interface. Ces IPs sont traitées séparément des VIPs de production. Cela sépare opérationnellement le trafic de synchronisation du trafic utilisateur.
Comportement de failback contrôlé
Le mode nopreempt empêche le VIP de retourner automatiquement vers l'ancien master lorsqu'il revient en ligne. Cela évite le failover ping-pong dans les scénarios impliquant une récupération temporaire suivie d'une autre panne. La décision de failback est prise délibérément par l'opérateur.
Intégration cluster local et GTM
Le cluster local fournit le failover VIP dans le même centre de données. Si l'ensemble du centre de données se déconnecte, la couche GTM peut rediriger le DNS vers un centre de données distant. Cela permet à la panne de nœud local et à la panne de centre de données d'être gérées à deux niveaux distincts.
Quand l'utiliser
Propriété VIP ininterrompue dans les applications financières
Les institutions financières peuvent faire fonctionner les VIPs de banque mobile et internet en configuration hautement disponible sur deux nœuds TR7 ADC. Lorsqu'un nœud se déconnecte pour maintenance ou en raison d'une panne, l'autre nœud prend la propriété du VIP et l'accès au service continue sur la même adresse.
Transfert intelligent de VIP lors d'une perte de gateway
Les équipes réseau peuvent s'assurer que le VIP se déplace vers l'autre nœud lorsque l'accès à la gateway est perdu — même si le nœud lui-même est encore en cours d'exécution. Dans ce scénario, le failover est basé sur l'accessibilité upstream réelle plutôt que sur la vivacité du dispositif seule.
Changements sécurisés pendant la maintenance planifiée avec synchronisation manuelle
Les agences gouvernementales ou les opérateurs d'activités critiques peuvent activer le mode de synchronisation manuelle et tester un changement sur un nœud d'abord. Après validation, le changement est poussé vers le pair, empêchant une propagation incontrôlée à l'échelle du cluster.
Contrôle de compatibilité lors du renouvellement matériel
Les équipes opérationnelles peuvent voir les différences de CPU, d'interface et de mémoire lors de l'intégration en retirant un ancien nœud et en ajoutant du nouveau matériel au cluster. Un avertissement est produit avant qu'un serveur mal spécifié n'entre dans le cluster, réduisant le risque de failover.
Questions fréquentes
Quelle est la différence entre les topologies Active-Active et Active-Passive ?
Qu'est-ce qui peut être utilisé lorsque VRRP seul n'est pas suffisant ?
Comment fonctionne la synchronisation de configuration ?
L'état de session et de rate limit est-il préservé lors d'un failover ?
Que se passe-t-il lors de l'ajout d'un nouveau nœud matériel au cluster ?
Comment le failover fonctionne-t-il lorsqu'il est utilisé avec GTM ?
Exécutez votre cluster ADC dans un seul modèle de gestion
Failover VIP VRRP, synchronisation de configuration, validation matérielle et flux de maintenance contrôlé — laissez-nous vous guider ensemble dans une configuration en direct.