Unité 3.5 : Haute disponibilité au niveau du réseau périphérique

Introduction

Un point de terminaison public n'est disponible que si l'interface réseau unique qui répond actuellement pour lui est disponible. Si cette interface appartient à un serveur et que le serveur est perdu, l'adresse cesse de répondre, et chaque client qui l'a mise en cache est bloqué jusqu'à ce que quelque chose déplace l'adresse ailleurs. La question architecturale à la limite du réseau est donc non pas "comment rendre un serveur fiable" mais "comment maintenir une adresse publique stable qui répond lorsque la chose derrière elle change". IONOS vous donne une primitive spécifique pour cela, IP basculement, avec un champ d'application précis et étroit. Cette unité traite de la haute disponibilité à la limite comme d'une décision de conception : ce que IP basculement garantit, ce qu'il ne garantit pas délibérément, et comment il s'intègre dans le tableau plus large de la résilience que le Module 7 complète.

1. IP Basculement : une adresse partagée sur des NIC redondants

Le basculement IP est le mécanisme de la plateforme pour un bord actif-passif. La fonctionnalité Cloud IP-Basculement provisionne la même adresse IP à plusieurs interfaces réseau appartenant à différents serveurs virtuels sur le même LAN. Une NIC est désignée comme maître et détient l'adresse comme son adresse IP principale ; les autres NIC du groupe sont des répliques qui sont prêtes à porter la même adresse. Lorsque le serveur maître échoue, l'adresse peut passer à une NIC réplique, de sorte que le point de terminaison public continue de répondre sans que le client n'ait jamais à apprendre une nouvelle adresse.

Ce qui fait fonctionner cela comme un point de terminaison stable, c'est que l'adresse doit être une adresse IP publique réservée. Les adresses générées par DHCP ne peuvent pas être utilisées dans un groupe de basculement. C'est la même discipline de réservation que vous avez appliquée lors de la construction de la topologie à trois LAN dans l'Unité 3.1 : l'adresse IPv4 réservée est liée à la région et persiste indépendamment de tout serveur, ce qui est exactement la propriété dont un point de terminaison HA a besoin. Le groupe de basculement relie simplement cette adresse persistante à un ensemble de NIC candidates et suit laquelle d'entre elles la possède actuellement.

La propriété la plus importante à internaliser est la limite de la garantie. Le basculement IP fournit la mise à disposition de la même adresse IP à plusieurs interfaces. Il ne surveille pas la disponibilité du service accessible via cette adresse IP. La plateforme déplace une adresse entre les NIC ; elle ne lance pas de sonde de santé contre votre application, ne décide pas que votre serveur Web renvoie des erreurs et ne déclenche pas de commutation en votre nom. La logique de détection et de décision qui promeut une réplique à maître vit dans votre système d'exploitation invité. Le modèle établi est une couche HA logicielle qui s'exécute sur les serveurs eux-mêmes, par exemple keepalived qui pilote VRRP, ou un mécanisme HA propre à un appareil de fournisseur, qui décide quand de revendiquer l'adresse partagée, puis déplace. La plateforme fournit la primitive d'adresse partagée ; vous fournissez l'intelligence qui décide quand de basculer. C'est la division récurrente du travail que la plateforme dessine au niveau de l'infrastructure par rapport au niveau de l'application, et à la limite, elle est inhabituellement nette.

Deux contraintes supplémentaires façonnent chaque conception qui utilise le basculement IP :

• Le LAN doit être public (connecté à Internet) et ne doit pas contenir un Load Balancer. Le basculement IP et un Load Balancer géré sont des modèles de limite alternatifs, et non superposés : là où un Managed Application Load Balancer ou un Load Balancer de réseau est déjà à la tête du niveau, cet équilibreur est la construction de disponibilité et le basculement IP n'a pas d'effet sur le même LAN.
• Les adresses MAC virtuelles ne sont pas prises en charge. Une conception de basculement ne peut pas supposer une identité de couche 2 portable qui voyage avec l'adresse ; le déplacement se fait à la couche IP, et la réplique répond avec sa propre adresse MAC une fois qu'elle possède l'adresse. Planifiez le comportement ARP/voisin et les attentes de gratuitous-ARP en conséquence, puisque le logiciel HA invité est ce qui annonce le déplacement.

Le basculement IP doit être configuré pour tous les ensembles HA de ce type ; c'est la construction native pour une paire active-passive autogérée derrière une adresse publique, et la plateforme ne documente pas d'alternative pour cette forme spécifique.

2. Lorsque le basculement Edge IP est l'outil approprié

Le basculement IP trouve sa place dans une bande étroite de conceptions, et reconnaître cette bande vous empêche de la mal appliquer. Le tableau suivant contraste les options de disponibilité de bord que vous avez maintenant à travers ce module.

La question décisive est de savoir si la chose que vous protégez gère sa propre disponibilité et a besoin d'une seule adresse publique fixe, ou si c'est un niveau évolutif horizontalement que l'équilibreur géré devrait répartir le trafic. Un appareil virtuel réseau auto-géré, un pare-feu logiciel ou un service clusterisé qui s'attend à posséder une adresse VIP flottante est le candidat classique au basculement IP : il fonctionne déjà avec keepalived ou un équivalent, et il n'a besoin que de la plateforme pour laisser deux de ses NIC partager une adresse réservée. Un niveau web ou API sans état ne l'est pas ; cela appartient derrière un Load Balancer géré, où la vérification de la santé et la distribution des backends sont gérées pour vous.

Le basculement IP est également limité par le domaine de défaut. Puisque le groupe de basculement vit sur un seul LAN, il protège contre la perte d'un serveur, et non contre la perte d'une zone de disponibilité ou d'une région. C'est la couture où les deux mécanismes suivants prennent le relais.

3. Composition de la haute disponibilité Edge avec une mise à l'échelle multi-zone et basculement DNS

Aucun seul élément ne garantit une résilience complète, et concevoir comme si c'était le cas est l'erreur la plus courante en matière d'Edge. La posture robuste est en couches, avec chaque mécanisme couvrant le domaine de défaut que celui en dessous ne peut pas.

Au bas, la mise à l'échelle multi-zone répartit les membres redondants de toute paire à travers les zones de disponibilité afin qu'une panne au niveau de la zone n'affecte pas les deux moitiés en même temps. Il s'agit d'une décision de placement prise au moment de la mise en service, et elle interagit directement avec la haute disponibilité Edge : une paire de basculement IP dont le maître et la réplique sont situés dans la même zone ne gagne rien lorsque cette zone est perdue. Placez les membres dans différentes zones, et soyez délibéré à ce sujet plutôt que d'accepter un placement automatique qui peut les regrouper en silence. (Compute expose les zones 1, 2 et Auto ; "Auto" est pratique, mais c'est exactement le paramètre qui peut silencieusement mettre une paire redondante ensemble, donc nommez les zones explicitement pour toute paire à haute disponibilité. Le Module 7 revient sur ce piège de zone automatique dans le contexte de la résilience.)

Au-dessus du placement, le basculement DNS couvre les domaines de défaut que aucun seul IP ne peut couvrir. Un IP réservé et son groupe de basculement sont ancrés dans une région et un LAN ; ils ne peuvent pas déplacer un point de terminaison vers un second site ou une seconde région. Lorsque le domaine de défaut que vous devez survivre est plus grand qu'un LAN, la direction passe à la hauteur. Comme le développe l'Unité 3.7, il s'agit d'un modèle construit par le client plutôt que d'un produit natif : votre propre contrôle de santé (un moniteur externe ou un signal provenant de la cible de santé d'un Load Balancer) détecte un point de terminaison mort et appelle le Cloud DNS API pour réorienter un enregistrement à faible durée de vie vers un point sain. Le Cloud DNS lui-même n'est pas conscient de la santé ; il sert tout enregistrement que vous définissez et ne modifie jamais une réponse de son propre chef. C'est ainsi que vous obtenez un basculement automatisé entre les zones et les sites étant donné qu'il n'y a pas de produit de basculement géré. Le basculement DNS ne dirige que les nouvelles connexions, donc les niveaux qu'il précède doivent être sans état pour que le modèle soit sûr.

Lus ensemble, les trois couches forment une hiérarchie claire : le basculement IP maintient une seule adresse publique qui répond lorsque un serveur meurt sur un LAN ; la mise à l'échelle multi-zone garantit que les membres redondants ne partagent pas un sort au niveau de la zone ; et le basculement DNS redirige les clients lorsque tout un point de terminaison, une zone ou un site est perdu. Chacun est nécessaire, aucun n'est suffisant seul, et la conception Edge est l'acte de choisir quelles couches un point de terminaison donné a réellement besoin.

FinCorp à la pointe

Les charges de travail réglementées de FinCorp sont situées derrière un pare-feu réseau autonome que l'équipe de sécurité insiste pour exploiter elle-même, pour des raisons de politique et d'audit. Cet appareil est le cas classique de basculement IP : deux instances de pare-feu sur le LAN public, maître et réplique, partageant une adresse publique réservée, avec le processus de haute disponibilité des appareils décidant quand la réplique revendique l'adresse. FinCorp place les deux instances de pare-feu dans différentes zones de disponibilité afin qu'une panne de zone ne puisse pas les faire tomber toutes les deux, et accepte que la plateforme ne vérifiera pas la santé du service de pare-feu pour eux ; cette surveillance est la responsabilité de l'appareil. Pour le niveau Web public sans état situé derrière ce pare-feu, FinCorp n'utilise pas le basculement IP du tout ; il utilise le Managed Application Load Balancer de l'Unité 3.3, car ce niveau se met à l'échelle horizontalement et bénéficie d'une distribution vérifiée. La question du site croisé, survivant à la perte de la région principale dans son ensemble, est reportée à la conception de basculement DNS dans l'Unité 3.7 et au plan de continuité dans le Module 7, car aucun IP de pointe ne peut répondre à cette exigence. La décision s'accumule : un IP réservé et une paire de basculement IP pour l'appareil autonome, un équilibrage de charge géré pour les niveaux élastiques, et DNS comme couche de direction transversale.

Résumé de la décision

La règle de sélection : protéger une paire d'adresses unique auto-gérée avec un basculement IP ; protéger un niveau élastique avec un Load Balancer géré ; protéger contre la perte de zone avec un placement multi-zone explicite ; et protéger contre la perte d'un point de terminaison ou d'un site entier avec un basculement DNS. Les mécanismes se superposent ; ils ne se substituent pas les uns aux autres.

Résumé

La haute disponibilité au niveau du réseau IONOS est construite par composition, et non par une seule fonctionnalité. Le basculement de IP donne une paire auto-gérée active-passive une adresse publique réservée stable IP qui peut se déplacer entre des cartes réseau redondantes sur le même LAN public, mais il s'arrête délibérément à la mise à disposition de l'adresse partagée : la détection de la santé et la décision de basculement vivent dans votre invité, et le constructeur ne peut pas s'étendre sur un LAN équilibré de charge, utiliser une adresse DHCP ou reposer sur une adresse MAC virtuelle. Autour de ce primitif, vous ajoutez une mise en place explicite multi-zone pour vaincre les défauts de niveau de zone et le basculement de DNS pour rediriger les clients lorsque tout un point de terminaison ou un site est disparu, ce qui est la réponse de la plateforme à ne pas avoir de produit de basculement géré.

Points clés :

• Le basculement de IP met à disposition une adresse publique réservée IP sur plusieurs cartes réseau sur différents serveurs sur le même LAN public ; le maître la détient, les répliques peuvent la reprendre.
• La plateforme ne surveille pas la santé du service pour le basculement. La détection et la promotion sont la responsabilité du client, généralement une couche HA d'invité telle que keepalived/VRRP ou un appareil de fournisseur avec sa propre couche HA.
• Le basculement de IP nécessite une adresse publique réservée IP (pas de DHCP), un LAN public avec aucun Load Balancer, et ne prend pas en charge les adresses MAC virtuelles.
• Le basculement de IP est pour des paires à adresse unique auto-gérées ; les couches étatiques élastiques appartiennent derrière un Load Balancer géré à la place.
• L'HA de bord compose avec une mise en place multi-zone (vaincre les défauts de zone ; définir les zones explicitement, jamais Auto pour une paire redondante) et le basculement de DNS (vaincre la perte de point de terminaison/zone/site), chacun couvrant un domaine de défaut que l'autre ne peut pas.

Terminologie importante :

• Groupe de basculement de IP : Un ensemble de cartes réseau sur différents serveurs sur un LAN public qui partagent une seule adresse publique réservée IP, avec un maître désigné, permettant un basculement actif-passif de l'adresse.
• Carte réseau maître/réplica : Dans un groupe de basculement, le maître détient actuellement l'adresse partagée comme son adresse IP principale ; les répliques sont éligibles pour la reprendre.
• HA actif-passif : Un modèle de redondance dans lequel un Node sert du trafic et un standby reprend le relais en cas de défaillance, contrairement au partage de charge actif-actif.

Lecture supplémentaire

• Unité 3.3, Équilibrage de charge - Couche 7 (Application), et Unité 3.4, Équilibrage de charge - Couche 4 (Réseau), pour l'alternative d'arête du répartiteur de charge géré.
• Unité 3.7, DNS et routage de basculement, pour la direction du basculement interzone et intersite.
• Module 7, Opérations, Résilience et Performance, pour le placement multi-zone, le piège auto-zone et l'image complète de la continuité des activités.