15 min de lecture

Objectifs d'apprentissage

À la fin de ce module, vous serez en mesure de:

  • Concevoir une périphérie en haute disponibilité active-passive utilisant la bascule IP, afin qu'une seule IP publique réservée survive à la perte d'un serveur.
  • Évaluer les limites qui déterminent où la bascule IP peut ou non être appliquée, et décider quelle responsabilité en matière de haute disponibilité vous incombe à l'intérieur de l'invité.
  • Concevoir une posture de résilience par couches qui combine la bascule IP de la périphérie avec le déploiement multi-zones et la bascule basée sur le DNS, au lieu de s'appuyer sur un seul mécanisme.

Unité 3.5 : Haute disponibilité à la périphérie du réseau

Introduction

Un point d'accès public n'est disponible que dans la mesure où l'unique interface réseau qui y répond actuellement est opérationnelle. Si cette interface appartient à un serveur unique et que ce serveur est perdu, l'adresse cesse de répondre, et tous les clients qui l'ont mise en cache restent bloqués jusqu'à ce que l'adresse soit déplacée ailleurs. La question architecturale à la périphérie du réseau n'est donc pas « comment rendre un serveur fiable », mais « comment maintenir une adresse publique stable qui répond lorsque l'élément qui se trouve derrière elle change ». IONOS CLOUD vous fournit un primitif spécifique à cet effet, le basculement d'IP, avec un périmètre précis et étroit. Cette unité aborde la haute disponibilité en périphérie comme une décision de conception : ce que le basculement d'IP garantit, ce qu'il ne fait pas délibérément, et comment il s'inscrit dans le tableau plus large de la résilience que le Module 7 complète.

1. Reprise sur défaillance IP : une adresse partagée entre des NIC redondantes

La reprise sur défaillance IP est le mécanisme de la plateforme pour une architecture active-passive en périphérie. La fonctionnalité Cloud IP-Failover provisionne la même adresse IP sur 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 en tant que son IP principale ; les autres NIC du groupe sont des répliques prêtes à prendre en charge la même adresse. Lorsque le serveur maître tombe en panne, l'adresse peut être transférée vers une NIC réplique, de sorte que le point d'accès public continue de répondre sans que le client n'ait à connaître une nouvelle adresse.

Ce qui permet à cela de fonctionner comme un point d'accès stable est que l'adresse doit être une IP publique réservée. Les adresses générées par DHCP ne peuvent pas être utilisées dans un groupe de reprise sur défaillance. 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 individuel, ce qui est précisément la propriété dont un point d'accès HA a besoin. Le groupe de reprise sur défaillance lie simplement cette adresse persistante à un ensemble de NIC candidates et suit laquelle d'entre elles en est actuellement propriétaire.

La propriété la plus importante à assimiler est la limite de la garantie. La reprise sur défaillance IP fournit le provisionnement de la même IP sur plusieurs interfaces. Elle ne surveille pas la disponibilité du service atteint via cette IP. La plateforme déplace une adresse entre les NIC ; elle n'exécute pas une sonde de santé contre votre application, ne décide pas que votre serveur web renvoie des erreurs, et ne déclenche pas de bascule en votre nom. La logique de détection et de décision qui promeut une réplique au statut de maître réside dans votre système d'exploitation invité. Le modèle établi est une couche HA logicielle exécutée sur les serveurs eux-mêmes, par exemple keepalived pilotant VRRP, ou le mécanisme HA propre à un équipement de fournisseur, qui décide quand réclamer l'adresse partagée et pilote ensuite le transfert. La plateforme fournit le primitif d'adresse partagée ; vous fournissez la logique qui décide quand effectuer la reprise sur défaillance. C'est la division du travail récurrent que la plateforme établit entre le niveau infrastructure et le niveau application, et en périphérie, elle est particulièrement marquée.

Deux contraintes supplémentaires façonnent toute conception utilisant la reprise sur défaillance IP :

  • Le LAN doit être public (connecté à Internet) et ne doit pas contenir de Load Balancer. La reprise sur défaillance IP et un Load Balancer managé sont des modèles de périphérie alternatifs, et non superposables : lorsqu'un Managed Application Load Balancer ou un Network Load Balancer est déjà placé en avant de la couche, ce Load Balancer est le mécanisme de disponibilité et la reprise sur défaillance IP ne s'applique pas sur le même LAN.
  • Les adresses MAC virtuelles ne sont pas prises en charge. Une conception de reprise sur défaillance ne peut pas supposer une identité de couche 2 portable qui se déplace avec l'adresse ; le transfert a lieu à la couche IP, et la réplique répond avec sa propre MAC une fois qu'elle détient l'adresse. Prévoyez le comportement ARP/voisin et les éventuelles attentes de gratuitous-ARP en conséquence, car c'est le logiciel HA invité qui annonce le transfert.

La reprise sur défaillance IP doit être configurée pour tous les montages HA de ce type ; c'est le mécanisme natif pour une paire active-passive auto-gérée derrière une seule adresse publique, et la plateforme ne documente aucune alternative pour cette configuration spécifique.

2. Quand le basculement d'IP de bord est l'outil approprié

Le basculement d'IP trouve sa place dans une gamme restreinte de conceptions, et la reconnaissance de cette gamme vous évite de l'appliquer à tort. Le tableau suivant met en contraste les options de disponibilité de bord dont vous disposez désormais dans ce module.

Construct de bord Ce qu'il rend hautement disponible Prise en compte de l'état de santé Où il s'attache Idéal pour
Basculement d'IP Une IP publique réservée unique sur des NIC redondantes Aucune côté plateforme ; le logiciel de HA invité décide Un LAN public sans équilibreur de charge géré Une paire active-passive auto-gérée (pare-feu/NVA, un appareil en grappe) qui gère sa propre logique de basculement
Managed Application Load Balancer (L7) Un point de terminaison de service public sur de nombreux backends Cibles vérifiées par sonde, exclusion automatique Son propre front-end géré (Unité 3.3) Des niveaux HTTP/S sans état nécessitant un routage de contenu et une terminaison TLS
Managed Network Load Balancer (L4) Un point de terminaison de service sur de nombreux backends Cibles vérifiées par sonde Son propre front-end géré (Unité 3.4) Des niveaux TCP/UDP et chiffrés de bout en bout, généralement orientés vers le privé
Basculement DNS (Unité 3.7) Un nom sur des points de terminaison dans différentes zones ou sites Votre propre vérification de santé externe (ou l'état de santé du LB) réoriente l'enregistrement via l'API ; Cloud DNS n'est pas conscient de l'état de santé Le chemin de résolution DNS, pas le chemin de données Basculement inter-zones et inter-sites où aucune IP unique ne peut couvrir le domaine de défaillance

La question décisive est de savoir si l'élément que vous protégez gère sa propre disponibilité et a besoin d'une adresse publique unique et stable, ou s'il s'agit d'un niveau scalable horizontalement sur lequel un équilibreur de charge géré devrait répartir le trafic. Un appareil réseau virtuel auto-géré, un pare-feu logiciel, ou un service en grappe qui s'attend à posséder un VIP flottant est le candidat classique au basculement d'IP : il exécute déjà keepalived ou un équivalent, et il a seulement besoin que la plateforme permette à deux de ses NIC de partager une adresse réservée unique. Un niveau web ou API sans état ne l'est pas ; celui-ci doit se situer derrière un équilibreur de charge géré, où la vérification de santé et la distribution vers les backends sont gérées pour vous.

Le basculement d'IP est également limité par le domaine de défaillance. Parce que le groupe de basculement réside sur un LAN unique, il protège contre la perte d'un serveur, pas contre la perte d'une zone de disponibilité ou d'une région. C'est là que les deux mécanismes suivants prennent le relais.

3. Composition de la HA d'extrémité avec un déploiement multi-zones et une bascule DNS

Aucune construction unique ne fournit une résilience de bout en bout, et concevoir comme si c'était le cas est l'erreur la plus courante au niveau de l'extrémité. La posture robuste est stratifiée, chaque mécanisme couvrant le domaine de défaillance que le mécanisme inférieur ne peut pas couvrir.

En base, le déploiement multi-zones répartit les membres redondants de toute paire entre les zones de disponibilité, afin qu'une défaillance au niveau d'une zone ne touche pas les deux moitiés simultanément. Il s'agit d'une décision de placement prise au moment de la provision, et elle interagit directement avec la HA d'extrémité : une paire de bascule IP dont le maître et la réplique se trouvent dans la même zone n'en tire aucun avantage lorsque cette zone est perdue. Placez les membres dans des zones différentes, et faites-le de manière délibérée plutôt que d'accepter un placement automatique qui pourrait les regrouper. (Compute expose les zones 1, 2 et Auto ; « Auto » est pratique, mais c'est précisément le réglage qui peut regrouper silencieusement une paire redondante, il faut donc nommer explicitement les zones pour toute paire HA. Le Module 7 revient sur ce piège de zone automatique dans le contexte de la résilience.)

Au-dessus du placement, la bascule DNS couvre les domaines de défaillance qu'une seule IP ne peut pas traverser. Une IP réservée et son groupe de bascule sont ancrés à une région et à un LAN ; ils ne peuvent pas déplacer un point d'accès vers un second site ou une seconde région. Lorsque le domaine de défaillance à survivre est plus vaste qu'un LAN, la redirection se déplace au niveau du nom. Comme l'Unité 3.7 le développe, il s'agit d'un modèle construit par le client et non d'un produit natif : votre propre vérification d'état (un moniteur externe, ou un signal issu de la santé des cibles d'un Load Balancer) détecte un point d'accès défaillant et appelle l'API Cloud DNS pour rediriger un enregistrement à TTL faible vers un enregistrement sain. Cloud DNS lui-même n'est pas conscient de l'état de santé ; il sert l'enregistrement que vous définissez et ne modifie jamais une réponse de son propre chef. C'est ainsi que vous obtenez une bascule automatisée entre zones et sites, étant donné qu'aucun produit de bascule managé n'existe. La bascule DNS ne redirige que les nouvelles connexions, de sorte que les couches qu'elle frontiste doivent être sans état pour que le modèle soit sûr.

Lus ensemble, les trois couches forment une hiérarchie claire : la bascule IP maintient une seule adresse publique en réponse lorsqu'un serveur tombe sur un LAN ; le déploiement multi-zones garantit que les membres redondants ne partagent pas un sort au niveau de la zone ; et la bascule DNS redirige les clients lorsqu'un point d'accès, une zone ou un site entier a disparu. Chacun est nécessaire, aucun n'est suffisant à lui seul, et la conception de l'extrémité consiste à choisir quelles couches un point d'accès donné nécessite réellement.

FinCorp à l'extrémité

Les charges de travail réglementées de FinCorp se trouvent derrière un pare-feu réseau auto-géré que l'équipe de sécurité tient à exploiter elle-même, pour des raisons de politique et d'audit. Cet appareil est le cas d'école de la bascule IP : deux instances de pare-feu sur le LAN public, maître et réplique, partageant une seule adresse IPv4 publique réservée, le processus HA propre aux appareils décidant quand la réplique réclame l'adresse. FinCorp place les deux instances de pare-feu dans des zones de disponibilité différentes afin qu'une défaillance de zone ne les fasse pas toutes les deux tomber, et accepte que la plateforme ne fasse pas de vérification d'état du service de pare-feu à leur place ; cette surveillance est le rôle de l'appareil. Pour la couche web sans état destinée au public située derrière ce pare-feu, FinCorp n'utilise pas du tout la bascule IP ; il utilise le Managed Application Load Balancer de l'Unité 3.3, car cette couche se met à l'échelle horizontalement et bénéficie d'une distribution avec vérification d'état. La question inter-sites, survivre à la perte totale de la région principale, est reportée à la conception de bascule DNS de l'Unité 3.7 et au plan de continuité du Module 7, car aucune IP d'extrémité ne peut répondre à cette exigence. La décision s'accumule : une IP réservée et une paire de bascule IP pour l'appareil auto-géré, un equilibrage de charge managé pour les couches élastiques, et le DNS comme couche de redirection entre domaines de défaillance.

Résumé de la décision

Exigence Option à choisir Contraintes strictes Remarques
Maintenir une seule adresse IP publique répondant sur une paire active-passive auto-gérée Groupe de basculement IP Adresse IP publique réservée uniquement (pas de DHCP) ; LAN publique sans équilibreur de charge ; pas de MAC virtuelle ; vous gérez la logique de haute disponibilité dans l'invité La plateforme déplace l'adresse ; elle ne réalise pas de vérification d'état de votre service
Couche HTTP/S sans état hautement disponible à la périphérie Managed Application Load Balancer (3.3) Dispose de sa propre interface avant ; ne peut pas partager un LAN avec un groupe de basculement IP Vérification d'état activée, terminaison TLS
Couche TCP/UDP ou chiffrée hautement disponible Managed Network Load Balancer (3.4) Dispose de sa propre interface avant Pas de terminaison TLS ; généralement orientée vers le réseau privé
Survivre à la perte d'une zone Répartition multi-zone de la paire redondante Définir les zones explicitement ; ne pas utiliser Auto pour une paire de haute disponibilité S'applique sous l'une des options ci-dessus
Survivre à la perte d'un point de terminaison, d'une zone ou d'un site entier Basculement DNS orchestré par le client (3.7) Les couches frontales doivent être sans état ; le RTO est limité par le TTL ; vous gérez la vérification d'état, Cloud DNS n'est pas conscient de l'état Substitut construit par le client à un produit de basculement managé

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

Résumé

La haute disponibilité sur le bord réseau d'IONOS CLOUD est construite par composition, et non par une fonctionnalité unique. Le basculement IP (IP failover) offre à une paire active-passive auto-gérée une IP publique réservée stable qui peut se déplacer entre des NIC 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 d'état de santé et la décision de basculement sont gérées par votre invité, et cette configuration ne peut pas couvrir un LAN équilibré en charge, utiliser une adresse DHCP, ni s'appuyer sur une adresse MAC virtuelle. Autour de cette primitive, vous superposez un placement multi-zones explicite pour contrer les pannes au niveau de la zone et le basculement DNS pour rediriger les clients lorsqu'un point d'accès ou un site entier est indisponible, ce qui constitue la réponse de la plateforme à l'absence d'un produit de basculement géré.

Points clés :

  • Le basculement IP met à disposition une IP publique réservée unique sur plusieurs NIC situées sur différents serveurs du même LAN public ; le nœud maître la détient, et les répliques peuvent la prendre en charge.
  • La plateforme ne surveille pas l'état de santé des services pour le basculement. La détection et la promotion sont de la responsabilité du client, généralement via une couche HA d'invité telle que keepalived/VRRP ou la propre HA d'un équipement de fournisseur.
  • Le basculement IP nécessite une IP publique réservée (pas de DHCP), un LAN public sans équilibreur de charge, et ne prend pas en charge les adresses MAC virtuelles.
  • Le basculement IP est destiné aux paires à adresse unique auto-gérées ; les couches sans état élastiques doivent être placées derrière un équilibreur de charge géré.
  • La HA sur le bord réseau se combine avec le placement multi-zones (pour contrer les pannes de zone ; définir les zones explicitement, jamais Auto pour une paire redondante) et le basculement DNS (pour contrer la perte d'un point d'accès/zone/site), chacun couvrant un domaine de panne que l'autre ne peut pas couvrir.

Terminologie importante :

  • Groupe de basculement IP : Un ensemble de NIC sur différents serveurs d'un même LAN public qui partagent une IP publique réservée unique, avec un nœud maître désigné, permettant le basculement actif-passif de l'adresse.
  • NIC maître / réplique : Au sein d'un groupe de basculement, le nœud maître détient actuellement l'adresse partagée en tant que son IP principale ; les répliques sont éligibles pour la prendre en charge.
  • HA actif-passif : Un modèle de redondance où un nœud traite le trafic et un nœud en veille le prend en charge en cas de défaillance, par opposition au partage de charge actif-actif.

Pour aller plus loin

  • Unité 3.3, Équilibrage de charge - Couche 7 (Application), et Unité 3.4, Équilibrage de charge - Couche 4 (Réseau), pour l'alternative d'extrémité avec équilibreur de charge géré.
  • Unité 3.7, DNS et Routage de basculement, pour l'orientation du basculement inter-zones et inter-sites.
  • Module 7, Opérations, Résilience et Performance, pour le placement multi-zones, le piège de la zone automatique et la vision complète de la continuité d'activité.