Unité 7.1 : Résilience et continuité des activités

Introduction

La résilience n'est pas un produit que vous achetez sur IONOS ; c'est une propriété que vous composez. La plateforme vous offre des zones de disponibilité, un niveau de charge d'équilibrage avec vérification de l'état, un service DNS anycast, une récupération de base de données à un moment donné, et un Backup Service, mais elle ne vend pas un seul bouton de "basculement" qui les orchestre. Cette absence est le fait de conception central de cette unité. Votre travail en tant qu'architecte est de traduire un requis de continuité des activités en un arrangement de ces primitives, puis de prouver qu'il fonctionne.

Cette unité se termine par la construction de la moitié de direction de cet arrangement dans le Data Center Designer : une paire d'enregistrements Cloud DNS à faible TTL orchestrée par le client à travers deux zones, ainsi que l'étape de validation qui confirme qu'un basculement déplace réellement le trafic. Le Cloud DNS ne vérifie pas l'état de santé par lui-même, donc la vérification de l'état qui déclenche ce basculement est fournie par vous. La construction renforce ce que vous avez provisionné dans les unités 3.6 et 3.7 (connectivité hybride et DNS), maintenant vu à travers le prisme de la reprise après sinistre. FinCorp, notre entreprise financière allemande sous les obligations GDPR et BSI, ancre chaque décision : un service adjacent aux paiements dont les cibles de continuité sont dictées par un régulateur, et non par une préférence d'ingénierie.

1. RTO, RPO et les trois stratégies de reprise

Deux chiffres régissent chaque conception de continuité, et l'entreprise possède les deux. L'objectif de temps de reprise (RTO) est le temps pendant lequel le service peut être arrêté avant que la panne ne devienne matériellement préjudiciable. L'objectif de point de reprise (RPO) est la quantité de données, mesurée en temps, que l'on peut se permettre de perdre. Un architecte qui choisit ces chiffres a pris une décision commerciale sans autorité. La fonction de risque et de conformité de FinCorp les définit ; vous concevez pour les atteindre et vous déclarez honnêtement ce que chaque objectif coûte.

Ces deux repères sélectionnent une stratégie de reprise. Trois stratégies couvrent le spectre coût-vitesse, et chacune se mappe clairement sur les primitives IONOS.

La stratégie est une décision budgétaire autant qu'une décision de disponibilité. Actif-actif double l'empreinte en cours d'exécution et exige la réplication de données la plus serrée ; sauvegarde-restauration est bon marché mais lente à reprendre et perd le plus de données. Le service de paiement adjacent de FinCorp ne peut pas tolérer un RTO de plusieurs heures, la sauvegarde-restauration est donc disqualifiée comme stratégie principale pour ce niveau, même si elle reste la bonne réponse pour les charges de travail de rapport et d'archive de l'entreprise. La conception réaliste de FinCorp est pilote-lumière pour le noyau réglementé : une base de données Cluster toujours active avec un Node de secours, un calcul pré-templété qui se met à l'échelle en cas de basculement, et DNS pour rediriger.

Une vérité de plateforme critique se déroule dans les trois stratégies. Le Backup Service (Acronis) couvre les machines virtuelles et Block Storage ; il ne sauvegarde pas les bases de données gérées, et il ne fournit pas de sauvegardes immuables. La continuité de la base de données est donc un mécanisme séparé : récupération à un moment donné à l'intérieur de la fenêtre de rétention de Cluster, plus dump et restauration pour tout ce qui dépasse. Traiter le Backup Service comme votre plan de reprise de base de données est l'erreur la plus coûteuse dans cet espace, car vous découvrez le fossé uniquement pendant une véritable reprise. Les instantanés aggravent la confusion : un instantané Block Storage Snapshot est un rollback de niveau VM, non incrémentiel, local à la région, et non une sauvegarde cohérente de la base de données. Planifiez le plan de continuité des données autour de la récupération à un moment donné et de la dump/restauration pour les niveaux de données, et autour du Backup Service uniquement pour les machines virtuelles et les volumes qu'il couvre réellement.

2. Placement multi-zone et le piège de l'auto-zone

La résilience commence par l'emplacement physique des éléments. IONOS expose les zones de disponibilité comme primitive de placement, et la redondance que vous obtenez dépend entièrement de la mise de ressources appariées dans différentes zones. La plateforme ne déduira pas votre intention.

Notez une asymétrie qui piège les architectes. Les zones de disponibilité de calcul sont la zone 1, la zone 2 et Auto. Les zones de disponibilité de Block Storage sont la zone 1, la zone 2, la zone 3 et Auto. Il n'y a pas de zone de calcul 3, donc un Volume placé dans la zone 3 n'a pas de serveur co-zoné pour s'y attacher dans la même zone. Pour une paire de calcul et de stockage redondants, concevez à l'intérieur des zones que les deux plans partagent.

Le piège se cache dans le mot "Auto". La sélection de la zone de disponibilité Auto est un indice de placement à une seule zone qui permet à IONOS de choisir une zone pour vous ; ce n'est pas une instruction de placement multi-zone ou "réparti sur les zones". Si vous créez deux serveurs destinés à former une paire HA et que vous les laissez tous les deux sur Auto, il n'y a aucune garantie qu'ils atterriront dans des zones différentes, et ils peuvent en partager une. Un domaine de défaut partagé est exactement ce qu'une paire HA est censée éliminer. La règle est sans ambiguïté : pour toute paire qui doit survivre à une défaillance de zone, définissez des zones explicites et différentes. Auto est acceptable pour une ressource unique et non appariée où vous n'avez pas de préférence de zone ; c'est incorrect pour la redondance.

Pour FinCorp, cela signifie que la base de données de secours Node est située dans une zone explicitement différente de la zone principale, et que le modèle de calcul de pilotage est provisionné dans une zone nommée distincte de la couche de production. La discipline de zone explicite est peu coûteuse à appliquer au moment de la conception et impossible à rétroéquiper proprement après une panne qui prouve que la paire était co-localisée.

3. Orientation basée sur la santé : Vérifications de santé de l'équilibreur de charge, basculement de IP et orchestration client de DNS

IONOS ne vend pas de produit de basculement géré. Il n'y a pas d'orchestrateur qui surveille un primaire, le déclare mort et promeut un secondaire dans l'ensemble de la pile, et il n'y a pas de service de basculement géré entre zones ou sites. Il est important d'être précis quant à quel primitif effectue l'orientation sensible à la santé, car ce n'est pas Cloud DNS.

Les primitifs d'orientation automatisés basés sur la santé de la plateforme sont deux. Premièrement, vérifications de santé de l'équilibreur de charge : le Managed Application Load Balancer effectue des vérifications de santé actives de ses cibles de backend sur TCP ou HTTP, tandis que le Managed Network Load Balancer effectue des vérifications de santé de ses cibles sur TCP uniquement (les vérifications de santé HTTP-aware sont une fonctionnalité ALB-only) ; les deux supportent des intervalles et des réessais configurables et dévient le trafic loin des cibles non saines dans le pool de backend du Load Balancer lui-même. Ceci est un véritable basculement automatique, mais il est limité à la région et au LAN : il déplace le trafic entre les cibles à l'intérieur d'un pool, et non entre les zones ou les sites. Deuxièmement, groupes de basculement de IP : un IP réservé partagé entre les machines virtuelles sur un LAN, pour un basculement de IP au niveau de l'application construit par le client ; il est également local au LAN. La mise en place multi-zone (section 2) est la troisième étape, mais il s'agit d'une mise en place, et non d'une orientation.

Le basculement entre zones et entre sites se situe au-dessus de tous ces éléments, et ici, il n'y a pas de mécanisme natif sensible à la santé. Cloud DNS n'est pas sensible à la santé : il ne surveille pas la santé des points de terminaison et ne modifie pas un enregistrement de son propre chef. Le basculement entre zones est donc orchestré par le client : votre propre vérification de santé (un moniteur externe ou un signal dérivé de l'état de santé de l'équilibreur de charge) détecte que le point de terminaison d'une zone est hors service et appelle l'API Cloud DNS API pour réorienter un enregistrement à faible TTL vers la zone saine. La contribution de Cloud DNS est que l'enregistrement est anycast, pris en charge par un SLA et peut avoir un TTL très bas ; l'automatisation de détection et de réorientation est la vôtre. Ceci est le remplacement de basculement introduit dans l'unité 1.3, réalisé honnêtement : composez un primitif sensible à la santé (le Load Balancer à l'intérieur d'une zone) avec une réorientation DNS à faible TTL orchestrée par le client.

Cloud DNS est bien adapté à la moitié DNS de cette composition. Il fonctionne sur un réseau anycast à 14 points de présence, transporte un SLA de disponibilité par service de 99,995 pour cent et prend en charge un TTL aussi bas que 60 secondes. Ce plancher de TTL est le principal levier de RTO pour tout basculement basé sur DNS, car un résolveur continuera à utiliser une réponse mise en cache jusqu'à ce que le TTL expire. Si votre enregistrement transporte un TTL d'une heure, votre récupération DNS-driven ne peut pas battre une heure, quel que soit la rapidité de détection de la panne. Abaissez le TTL des enregistrements qui participent au basculement et acceptez l'augmentation modeste des requêtes Volume comme le prix d'une coupure plus rapide.

Deux contraintes honnêtes façonnent la façon dont vous construisez ceci. Premièrement, DNS n'oriente que les nouvelles connexions. Un client qui détient déjà une connexion au point de terminaison défaillant n'est pas déplacé par un changement de DNS ; il doit se reconnecter, auquel cas il résout la nouvelle adresse. C'est pourquoi les niveaux d'application derrière un basculement DNS doivent être sans état, avec l'état de session et l'état partagé externalisés vers le niveau en mémoire au lieu d'être conservés sur l'instance. Deuxièmement, la capacité de vérification de santé vit sur le plan de l'équilibreur de charge (ou dans votre propre moniteur externe), et jamais dans Cloud DNS : il n'y a pas de type d'enregistrement de basculement de vérification de santé, car Cloud DNS ne vérifie pas la santé du tout. Dans la pratique, vous composez les plans : un Load Balancer détermine la santé à l'intérieur d'une zone, et un appel API client-orchestré réoriente l'enregistrement DNS entre les points de terminaison au niveau de la zone. Puisque ce basculement entre zones doit être piloté par vos outils de surveillance ou d'orchestration plutôt que par Cloud DNS, traitez la mise à jour de l'enregistrement comme une conception de niveau API, et non comme un assistant de console point-and-click ; le chemin de la console est la gestion de la zone et de l'enregistrement, et Cloud DNS ne déclenche jamais le changement lui-même.

4. Deux plans : direction et continuité des données

Une conception de résilience durable sépare deux préoccupations, car elles échouent et se rétablissent sur des échelles de temps et des mécanismes différents.

Le plan de direction du trafic décide où les requêtes sont acheminées. Il est construit à partir d'enregistrements Cloud DNS, de paramètres TTL et de vérifications de l'état de santé du load balancer qui déterminent l'état de santé du point de terminaison. Son rôle est de détourner les nouvelles connexions d'un emplacement défaillant rapidement. Sa vitesse de rétablissement est limitée par le plancher TTL et par les intervalles de vérification de l'état de santé, et non par la vitesse à laquelle les données peuvent être copiées.

Le plan de continuité des données décide si les données à destination sont actuelles et correctes. Il est construit à partir du mode de réplication de la base de données et de PITR, du Backup Service pour les machines virtuelles et du Block Storage, de la sauvegarde/restauration pour les bases de données, et du Object Storage en tant que queue d'archive. Ses caractéristiques de rétablissement sont le RPO que vous pouvez réellement rencontrer et le temps qu'il faut pour restaurer.

Confondre les deux est une erreur classique. Rediriger le trafic vers un système de secours en quelques secondes ne sert à rien si les données du système de secours sont obsolètes de plusieurs heures, et une réplique parfaitement actuelle est inutile si aucun mécanisme ne redirige les clients vers celle-ci. Conceptionnez chaque plan pour atteindre son propre objectif : le plan de direction pour le RTO, le plan de continuité pour le RPO. La conception de pilotage de FinCorp rend la séparation concrète : les vérifications de l'état de santé du load balancer plus un enregistrement Cloud DNS à faible TTL que une vérification externe réachemine forment le plan de direction qui répond au RTO, tandis que la base de données de secours toujours active Node et sa fenêtre PITR forment le plan de continuité qui répond au RPO. Les deux ne sont connectés qu'au moment de la coupure.

5. Réconciliation de la haute disponibilité des serveurs dédiés VMware avec la plateforme multi-zone

FinCorp exploite un grand parc de VMware, et une partie de celui-ci est hébergée sur IONOS Private Cloud, le centre de données virtuel dédié et géré VMware SDDC. Les parcs hybrides comportent donc deux modèles de résilience différents en même temps, et un architecte doit savoir où chaque modèle s’applique.

À l’intérieur d’un Private Cloud Cluster, la tolérance aux défauts est une propriété VMware, et non une propriété de disponibilité de la zone de la plateforme. vSAN (version 8.0, édition Enterprise selon la documentation Private Cloud, sur vSphere 8.0 Enterprise Plus) protège contre les défaillances de l’hôte et du disque grâce au codage d’effacement et au mirroring. La matrice répertorie trois méthodes de tolérance aux défauts : le mirroring RAID-1 (minimum 3 hôtes), le codage d’effacement RAID-5 (minimum 4 hôtes) et le codage d’effacement RAID-6 (minimum 6 hôtes). vSAN nécessite un minimum de 3 hôtes pour maintenir la protection RAID1 (deux copies complètes des données), ce qui est la taille minimale Cluster. vSphere HA redémarre les machines virtuelles sur les hôtes survivants en cas de défaillance d’un hôte. Il s’agit d’une résilience intra-Cluster : elle maintient le SDDC en fonctionnement grâce aux défaillances matérielles à l’intérieur d’un Cluster, et c’est le modèle opérationnel natif VMware que le parc comprend déjà.

Ce que vSAN et vSphere HA ne fournissent pas, c’est la résilience inter-sites. Ils protègent une charge de travail contre la perte d’hôte à l’intérieur du Cluster ; ils ne permettent pas à une charge de travail de survivre à la perte de l’ensemble du site ou du Cluster. La continuité inter-sites pour le parc VMware est une question de réplication, gérée par VMware Cloud Director Availability (VCDA, version 4.7.x), qui effectue une réplication asynchrone et un basculement entre les sites à environ 50 EUR par VM protégé par mois. La limite honnête, énoncée dans l’unité 4.4 et reportée à 7.4, est que l’outil VMware que IONOS répertorie pour cela est VCDA, NSX-T L2 VPN pour l’extension de la couche 2, et vMotion intra-Cluster. Il n’y a pas de capacité de mobilité live inter-sites et pas d’autre module complémentaire VMware à supposer.

Pour une conception hybride de FinCorp, les deux modèles se combinent plutôt que de se concurrencer. Au sein du noyau dédié VMware, s’appuyer sur vSAN et vSphere HA pour la tolérance aux défauts intra-Cluster. Pour le niveau natif de la plateforme (calcul standard, bases de données gérées, conteneurs), s’appuyer sur le placement multi-zones explicite, les vérifications de santé du chargeur d’équilibrage à l’intérieur d’une zone, plus la réorientation low-TTL DNS orchestrée par le client entre les zones, et la récupération ponctuelle dans le temps des bases de données. La continuité inter-sites pour le parc VMware est la réplication VCDA ; la continuité inter-zones pour le parc natif est la composition DNS-plus-plan de données à partir des sections 3 et 4. Le point de réconciliation est de reconnaître que « HA » signifie des choses différentes sur chaque côté, et que les mécanismes d’un côté ne remplacent pas ceux de l’autre.

DCD Marche à suivre pour la mise en œuvre

Vous allez configurer une bascule automatique à deux zones pour un point de terminaison FinCorp et valider qu'elle dirige le trafic. L'objectif architectural est le plan de direction de la section 4 : un nom qui se résout en un point de terminaison principal dans une zone et peut être déplacé vers un point de terminaison de secours dans une autre zone. Cela compose le travail de Cloud DNS de l'unité 3.7 avec la discipline de zone explicite de la section 2. Prérequis : deux points de terminaison de backend (par exemple, deux adresses d'équilibrage de charge ou de serveur) déployés dans des zones de disponibilité différentes, et le privilège d'administrateur de contrat ou "Accéder et gérer DNS" requis pour gérer les zones et les enregistrements.

Objectif de construction : Configurer un enregistrement de bascule automatique à faible TTL DNS sur une paire de deux zones et valider, en notant que Cloud DNS ne vérifie pas la santé de manière autonome.

Étapes (dans le Data Center Designer) :

1. Confirmez que les deux points de terminaison sont dans des zones différentes. Avant de toucher DNS, vérifiez dans le DCD que les ressources principales et de secours portent des zones de disponibilité explicites et différentes (et non Auto). Si l'une d'elles est sur Auto, corrigez d'abord le placement ; un enregistrement de bascule automatique devant une paire co-localisée est inutile.
2. Ouvrez le gestionnaire de DNS et sélectionnez Créer une zone principale DNS. Entrez le nom de la zone (le domaine ou le sous-domaine FinCorp qui sera à la tête du service). La zone est le conteneur pour les enregistrements de bascule automatique.
3. Après la mise à disposition de la zone, ouvrez-la à partir de la liste des zones principales en utilisant Détails et enregistrements.
4. Créez l'enregistrement principal. Ajoutez un enregistrement (par exemple, un enregistrement A) dont le nom est le nom d'hôte du service et dont le contenu est l'adresse du point de terminaison principal dans la zone 1. Définissez la TTL à un niveau faible (à ou près du plancher de 60 secondes) afin qu'une coupure ultérieure se propage rapidement ; cette TTL est votre principal levier de temps de rétablissement (RTO).
5. Notez l'adresse du point de terminaison de secours dans la zone 2. Vous allez pointer le même nom d'enregistrement vers cette adresse pendant une bascule automatique. Conservez les détails du point de terminaison de secours afin que la coupure soit une édition unique et sans ambiguïté.
6. Définissez la source de santé sur le plan d'équilibrage de charge. Puisque Cloud DNS n'expose pas d'enregistrement de bascule automatique de vérification de santé empaqueté, attachez la vérification de santé où elle se trouve : sur le groupe cible de l'équilibrage de charge géré (Managed ALB ou NLB) qui fait face à chaque point de terminaison, configurez la vérification de santé périodique afin que l'équilibrage de charge ne serve que les cibles saines. C'est le signal de détection que votre bascule automatique va réagir.
7. Configurez la coupure automatique au niveau de API. Pour rendre la bascule automatique automatique plutôt que déclenchée par l'opérateur, faites en sorte que la mise à jour de l'enregistrement soit déclenchée par la surveillance ou l'orchestration : en cas de signal non sain prolongé pour la zone 1, appelez le Cloud DNS API pour mettre à jour le contenu de l'enregistrement vers l'adresse de la zone 2. Le chemin de la console est la gestion de zone et d'enregistrement ; l'automatisation est l'édition de API, donc conservez cette conception de sous-étape et le niveau de API plutôt que d'inventer un assistant de console.
8. Validez en simulant une défaillance. Mettez le point de terminaison principal (zone 1) hors service ou faites échouer sa vérification de santé, puis déclenchez ou effectuez la mise à jour de l'enregistrement vers l'adresse de secours. À partir d'un client externe, après l'expiration de la TTL, confirmez que le nom se résout désormais vers l'adresse de la zone 2 et que les nouvelles connexions atteignent le point de terminaison de secours. Confirmez qu'une connexion déjà ouverte ne se déplace pas jusqu'à ce qu'elle se reconnecte, ce qui prouve la nécessité d'un niveau sans état.

Erreurs courantes :

• Laisser des points de terminaison appariés sur la zone de disponibilité Auto. Auto est un indice de zone unique, et non une instruction de répartition sur plusieurs zones ; définissez des zones explicites et différentes pour les deux membres de la paire avant de construire la bascule automatique.
• Définir une TTL longue sur l'enregistrement de bascule automatique. Une TTL élevée limite votre temps de rétablissement (RTO) atteignable à la valeur de la TTL, car les résolveurs conservent la réponse mise en cache ; abaissez-la à proximité du plancher de 60 secondes sur les enregistrements qui participent à la bascule automatique.
• Supposer que Cloud DNS a un enregistrement de bascule automatique géré ou un enregistrement de vérification de santé natif. Il n'en est rien ; la détection vit sur les vérifications de santé de l'équilibrage de charge et la coupure automatique est une mise à jour d'enregistrement API-driven. N'attendez pas un bouton de console qui n'existe pas.
• Attendre que DNS déplace les connexions actives. DNS dirige uniquement les nouvelles connexions ; si le niveau d'application conserve l'état de session sur l'instance, ces sessions sont interrompues. Externalisez l'état vers le niveau sans état afin que le niveau soit réellement sans état.
• Traiter le Backup Service comme le plan de reprise après sinistre pour la base de données. Il couvre les machines virtuelles et les Block Storage, et non les bases de données gérées ; la continuité des données est assurée par PITR plus dump/restore. Validez le plan de continuité des données séparément du plan de direction.

Une courte illustration au niveau de API de l'édition de coupure (le point architectural est que la moitié de la bascule automatique de DNS est une mise à jour de contenu d'enregistrement déclenchée par le client, et non une politique gérée, et non quelque chose que Cloud DNS déclenche de manière autonome) :

# On a sustained zone-1 unhealthy signal, repoint the record to the zone-2 standby.
ionosctl dns record update --zone-id "$ZONE_ID" --record-id "$RECORD_ID" \
  --content "$STANDBY_ZONE2_ADDRESS"

Résumé

La résilience sur IONOS est composée, et non achetée. Vous commencez par les objectifs de récupération et de point de récupération appartenant à l'entreprise, choisissez l'une des trois stratégies de récupération, placez des paires redondantes dans des zones explicitement différentes, et séparez le plan de direction du trafic (vérifications de santé d'équilibrage de charge à l'intérieur d'une zone, plus un point de reconfiguration à faible TTL Cloud DNS orchestré par le client à travers les zones) du plan de continuité des données (PITR de base de données et dump/restore, le Backup Service pour les machines virtuelles et Block Storage, Object Storage archive). Il n'y a pas de produit de basculement géré et pas d'orchestrateur de basculement géré entre zones. La direction de santé-aware du plan est le Load Balancer (à l'intérieur de son pool) et les groupes de basculement IP (à l'intérieur d'un LAN) ; le basculement entre zones est une mise à jour de l'enregistrement API pilotée par le client qui Cloud DNS sert mais ne déclenche pas, car Cloud DNS n'est pas santé-aware. Pour les domaines hybrides, les VMware vSAN et vSphere HA dédiés couvrent la tolérance aux défauts à l'intérieur de Cluster, tandis que la plateforme multi-zone, la composition LB-plus-DNS, et VCDA couvrent respectivement la continuité entre zones et entre sites.

Points clés :

• Les objectifs de récupération et de point de récupération sont des décisions commerciales ; l'architecte conçoit en fonction de ceux-ci et indique ce que chacun coûte. Les trois stratégies (sauvegarde-restauration, pilote-lumière, active-active) échangent le coût contre la vitesse de récupération.
• Le placement de la zone de disponibilité doit être explicite pour toute paire redondante. Auto est un hint de zone unique, et Block Storage a une Zone 3 que le calcul ne possède pas.
• Les primitives de direction de santé-aware de la plateforme sont les vérifications de santé d'équilibrage de charge (à l'intérieur du pool de backend d'équilibrage de charge) et les groupes de basculement IP (à l'intérieur d'un LAN) ; il n'y a pas d'orchestrateur de basculement géré entre zones.
• Cloud DNS (anycast, 14 PoPs, 99,995 pour cent SLA, plancher de TTL de 60 secondes) n'est pas santé-aware et ne réalise pas de basculement automatisé. Le basculement entre zones est une re-point de l'enregistrement à faible TTL orchestrée par le client que Cloud DNS sert mais ne déclenche pas ; le plancher de TTL est le levier dominant de l'objectif de récupération et DNS dirige les nouvelles connexions uniquement.
• Gardez le plan de direction et le plan de continuité des données séparés ; Backup Service ne couvre pas les bases de données gérées, dont la continuité est PITR plus dump/restore.
• À l'intérieur de Private Cloud, vSAN (RAID-1/5/6, minimum 3 hôtes pour RAID1) et vSphere HA donnent une tolérance aux défauts à l'intérieur de Cluster ; la continuité entre sites est VCDA, et il n'y a pas de mobilité live entre sites.

Terminologie importante :

• Objectif de récupération (RTO) : la durée maximale tolérable d'une panne ; le plan de direction est conçu pour la respecter.
• Objectif de point de récupération (RPO) : la perte de données maximale tolérable mesurée dans le temps ; le plan de continuité des données est conçu pour la respecter.
• Zone de disponibilité Auto : un hint de placement de zone unique laissant IONOS choisir une zone, et non une instruction de redondance multi-zone.
• Plancher de TTL : le temps de vie minimal de l'enregistrement (60 secondes sur Cloud DNS) ; il borne le meilleur objectif de récupération DNS réalisable.
• VCDA (VMware Cloud Director Availability) : l'outil de réplication et de basculement asynchrone natif VMware pour la continuité entre sites de l'ensemble dédié VMware.

Lecture supplémentaire

• Unité 3.7 : DNS et routage de basculement (la zone et l'enregistrement de cette unité sont réutilisés)
• Unité 3.6 : Connectivité hybride (les passerelles qui relient les sites pendant le basculement)
• Unité 5.7 : Protection des données et cycle de vie (le plan de continuité des données en profondeur)
• Unité 4.4 : Private Cloud (VMware dédié) et Unité 7.4 : Migration et basculement hybride (VCDA et le domaine VMware)