Le trafic de production commence généralement par DNS mais finit par aboutir aux adresses IP. Lorsque la gestion des VIPs est traitée comme rien de plus que « binder sur une adresse », la vraie topologie réseau est laissée de côté. Si VLAN, LACP, Bridge, V-ETH, V-ETH(peer), namespace, IPv6 et le comportement de failover cluster ne sont pas considérés ensemble, un VIP peut sembler opérationnel pendant que le trafic n'arrive pas par le chemin attendu.
Dans les environnements multi-VLAN, le problème devient plus apparent. Un opérateur crée d'abord le VLAN côté réseau, puis ajuste les relations Bond ou Bridge, et enfin définit le VIP sur l'ADC. Lorsque ces éléments sont gérés de manière isolée, un mauvais tag VLAN, une incompatibilité MTU, une sélection incorrecte d'interface parente ou un contrôle de gateway manquant conduisent tous à la situation classique « le VIP est actif mais pas de trafic ».
Les approches de transition VIP classiques sont également insuffisantes dans certains scénarios. Un nœud peut sembler sain, la communication VRRP peer peut continuer, pourtant le lien pertinent peut être tombé ou la gateway peut être devenue inaccessible. Si le VIP reste sur un dispositif qui ne peut pas atteindre l'upstream, aucun failover ne se produit et une interruption de service s'ensuit.
Le bon modèle lie le VIP au cluster, pas à un dispositif physique. Le type d'interface, la relation d'interface parente, la structure VLAN ou Bond, les adresses IPv4/IPv6, le rôle MASTER/BACKUP et la méthode de transition doivent tous être définis ensemble dans le même modèle de configuration.
TR7 VIP and IP Scenarios répond à ce besoin : il rend les VIPs gérables avec la topologie réseau, la propriété cluster et la conscience des liens/gateways.
TR7 construit la gestion des VIPs sur un modèle d'interface, le couplage de communication VIP, la distribution MASTER/BACKUP et la composition d'interfaces multi-couches.
Les interfaces Ethernet, VLAN, Bond, LACP, V-ETH, V-ETH(peer) et Bridge sont toutes définies via la même approche de configuration. Seules les options pertinentes à chaque type sont affichées, de sorte que les opérateurs ne peuvent pas écrire le mauvais paramètre réseau dans le mauvais champ.
Un couple de communication VIP est défini pour chaque interface et les nœuds du cluster se correspondent via ces adresses. Le VIP n'est pas épinglé à un seul nœud ; il est détenu sur le nœud qui détient le rôle actif dans le cluster.
Les VIPs sont séparés en listes master et backup. Dans les déploiements Active-Active, un nœud détient la liste VIP master et le pair détient la liste backup. Si un nœud tombe en panne, tous les VIPs convergent sur le nœud sain.
Les relations d'interfaces parentes, les membres Bond, les membres Bridge et les associations d'interfaces virtuelles sont tous définis dans le même arbre. Les topologies réelles comme VLAN sur Bond, V-ETH dans un Bridge, ou V-ETH(peer) attaché à un namespace sont toutes représentées dans un seul modèle.
VIP and IP Scenarios combine la structure réseau physique et virtuelle avec la gestion VIP consciente du cluster.
TR7 supporte les types d'interfaces Ethernet, VLAN, Bond, LACP, V-ETH, V-ETH(peer) et Bridge. Les interfaces physiques, sous-interfaces VLAN, Bond, LACP, Bridge, Ethernet virtuel et paires d'Ethernet virtuel peuvent tous être inclus dans le même modèle réseau. Cela fait de l'ADC un point de gestion conscient de la topologie réseau plutôt qu'une simple couche d'assignation d'IP. Les opérateurs gèrent la vraie disposition réseau de leur environnement de production depuis l'interface TR7.
TR7 gère ensemble les familles d'adresses IPv4 et IPv6 dans la gestion des VIPs. Les deux adresses v4 et v6 peuvent fonctionner en parallèle pour le même service ou interface. Les contrôles de santé de gateway peuvent également être séparés par famille d'adresses. Cela traite l'adoption IPv6 comme une extension naturelle du modèle VIP existant plutôt qu'un projet séparé.
Les interfaces VLAN peuvent être définies avec une interface parente Ethernet, Bond ou LACP. Chaque VLAN peut porter son propre sous-réseau et son propre ensemble de VIPs. C'est particulièrement précieux pour les architectures de fournisseurs de services, multi-locataires et orientées segmentation. Différents clients ou zones de sécurité sont séparés sur le même lien physique.
Les interfaces Bond et LACP permettent à plusieurs ports physiques d'opérer comme une seule interface logique. Bond couvre les scénarios de redondance comme le mode active-backup ; LACP couvre l'agrégation de liens 802.3ad. Les VIPs de production placés sur ces interfaces logiques deviennent plus résilients aux pannes de port unique ou de lien unique. Une couche VLAN peut également s'exécuter sur Bond ou LACP pour une conception de topologie flexible.
Bridge peut être utilisé pour le comportement de bridging Layer 2 dans les plans réseau basés sur VM ou conteneurs. V-ETH fournit une interface Ethernet virtuelle au niveau MAC pour les environnements de virtualisation. V-ETH(peer) crée une paire d'Ethernet virtuel pour l'isolation namespace et conteneur. Ce support signifie que TR7 opère de manière flexible dans les architectures virtuelles et cloud on-premises, pas seulement sur les appliances physiques.
Les VIPs sont gérés comme des adresses de service appartenant au cluster plutôt que comme des listes IP locales sur un seul nœud. Les couples de communication VIP et les objets VIP sont définis par interface. Lorsqu'un failover se produit, la propriété du VIP peut se déplacer vers le nœud pair. Ce modèle préserve les adresses de service à travers les scénarios de maintenance et de panne.
TR7 offre quatre méthodes de transition par VIP : VRRP uniquement, contrôle de lien TR7, contrôle de gateway TR7 et contrôle de lien et gateway TR7. VRRP uniquement utilise le comportement de protocole classique ; le contrôle de lien TR7 surveille l'état du carrier de l'interface physique ; le contrôle de gateway TR7 teste l'accessibilité upstream ; le contrôle de lien et gateway TR7 évalue les deux signaux ensemble. Les VIPs critiques peuvent donc se déplacer selon l'accessibilité réseau réelle plutôt que la simple vivacité du dispositif. Ce comportement — qui nécessite généralement des scripts de surveillance personnalisés dans les déploiements standard — est offert comme sélection de politique depuis l'interface TR7.
La liste VIP master et la liste VIP backup sont maintenues séparément. Dans une configuration Active-Active, un groupe de VIPs est actif sur un nœud pendant que l'autre groupe est actif sur le pair. Si un nœud tombe, le nœud sain prend la propriété des deux ensembles de VIPs. Cela signifie que les deux dispositifs servent de sources de trafic actives plutôt qu'un seul étant un standby inactif.
La gestion des VIPs est planifiée avec la hiérarchie d'interfaces, les slots VRRP, la communication unicast, le namespace, la zone et les contrôles de gateway.
Les relations VLAN, Bond, LACP, Bridge, V-ETH et V-ETH(peer) sont définies via les champs d'interface parente et d'interface membre. Cela permet de modéliser précisément des compositions comme VLAN sur Bond, V-ETH dans un Bridge, ou V-ETH(peer) attaché à un namespace. Les équipes opérationnelles gèrent la structure réseau avec ses dépendances plutôt que comme des pièces déconnectées.
Deux slots VRRP — MASTER et BACKUP — peuvent être générés par interface. Dans les déploiements Active-Active, cette séparation est le fondement de la distribution des VIPs. Les valeurs virtual_router_id sont assignées automatiquement, réduisant le risque de collisions dans le même sous-réseau.
TR7 peut utiliser une approche unicast pour la communication VRRP peer. Cela fournit un comportement plus prévisible dans les réseaux de centres de données modernes où le trafic multicast est filtré. La communication avec le nœud pair est définie explicitement via les champs unicast_src_ip et unicast_peer.
L'accessibilité de la gateway peut être surveillée avec un contrôle de santé par interface. Les familles IPv4 et IPv6 peuvent être contrôlées indépendamment. Lorsque l'accès à la gateway est perdu et que la méthode de transition est contrôle de gateway TR7 ou contrôle de lien et gateway TR7, la décision de failover tient compte de ce signal.
Les VIPs peuvent être associés à un contexte de namespace et de zone. Cela rend la propriété des VIPs plus clairement définie dans les déploiements multi-locataires ou multi-zones. Une isolation réseau séparée et une gestion VIP séparée peuvent être configurées pour chaque locataire ou zone.
Lorsqu'un VIP bascule, un gratuitous ARP est envoyé pour mettre à jour les tables MAC des switches côté réseau. Cela accélère la redirection du trafic au niveau L2 vers le nouveau nœud actif. Cela aide à réduire le temps d'interruption de service particulièrement lors des transitions VIP dans le même sous-réseau.
Les équipes télécom peuvent définir de nombreux VLANs sur un port trunk et exécuter un ensemble de VIPs séparé pour chaque client ou segment de service. Plusieurs sous-réseaux et plusieurs séparations clients sont gérés sur un seul lien physique.
Les équipes opérationnelles peuvent agréger plusieurs ports physiques en une seule interface LACP et placer les VIPs de production sur cette interface logique. La continuité de service est renforcée contre les pannes de lien ou les besoins de capacité.
Dans les grands déploiements, certains VIPs peuvent être actifs sur un nœud pendant que d'autres s'exécutent sur le pair. Les deux dispositifs transportent du trafic en direct, et si un nœud tombe le nœud sain prend la propriété de l'ensemble complet des VIPs.
Dans les environnements multi-locataires, chaque locataire peut être placé dans son propre namespace. Les VIPs sont définis comme appartenant à ce namespace, et le trafic locataire est séparé au niveau du plan réseau.
Sept types d'interfaces, quatre méthodes de failover et propriété VIP à l'échelle du cluster. Laissez-nous vous guider dans une configuration en direct dans votre propre environnement.