Unité 7.1 : Résilience et continuité d'activité

Introduction

La résilience n'est pas un produit que vous achetez sur IONOS CLOUD ; c'est une propriété que vous composez. La plateforme vous offre des zones de disponibilité, une couche d'équilibrage de charge avec vérification d'état, un service DNS anycast, une restauration de base de données à un instant donné et un service de sauvegarde, mais elle ne propose pas de bouton unique « basculement » qui les orchestre. Cette absence constitue le fait de conception central de cette unité. Votre rôle en tant qu'architecte consiste à traduire une exigence de continuité d'activité en une organisation de ces primitives, puis à prouver que cela fonctionne.

Cette unité se conclut par la construction de la moitié de pilotage de cette organisation dans Data Center Designer : une paire d'enregistrements Cloud DNS à TTL faible orchestrée par le client, répartie sur deux zones, ainsi que l'étape de validation qui confirme qu'un basculement déplace réellement le trafic. Cloud DNS ne réalise pas de vérification d'état de manière autonome, de sorte que la vérification d'état qui pilote ce basculement est celle que vous fournissez. La construction renforce ce que vous avez provisionné dans les unités 3.6 et 3.7 (connectivité hybride et DNS), désormais observé sous l'angle de la reprise sur sinistre. FinCorp, notre entreprise allemande de services financiers soumise aux obligations RGPD et BSI, ancre chaque décision : il s'agit d'un service proche des paiements dont les objectifs de continuité sont dictés par un régulateur, et non par une préférence d'ingénierie.

1. RTO, RPO et les trois stratégies de récupération

Deux chiffres gouvernent toute conception de continuité, et l'entreprise en est propriétaire. Le Recovery Time Objective (RTO) est la durée maximale pendant laquelle le service peut être indisponible avant que l'interruption ne devienne matériellement préjudiciable. Le Recovery Point Objective (RPO) est la quantité de données, mesurée en temps, que vous pouvez vous permettre de perdre. Un architecte qui choisit ces chiffres a pris une décision commerciale sans y être habilité. La fonction risques et conformité de FinCorp les définit ; vous concevez pour les atteindre et vous déclarez honnêtement le coût de chaque objectif.

Ces deux points d'ancrage sélectionnent une stratégie de récupération. Trois stratégies couvrent le spectre coût-vitesse, et chacune se mappe proprement sur les primitives IONOS CLOUD.

La stratégie est une décision budgétaire autant qu'une décision de disponibilité. Actif-actif double l'empreinte d'exécution et exige la réplication de données la plus stricte ; sauvegarde-restauration est bon marché mais lent à récupérer et perd le plus de données. Le service proche des paiements de FinCorp ne peut pas tolérer un RTO de plusieurs heures, donc sauvegarde-restauration est disqualifié comme stratégie principale pour cette couche, même s'il reste la bonne réponse pour les charges de travail de reporting et d'archive de l'entreprise. La conception réaliste de FinCorp est pilot-light pour le cœur régulé : un cluster de base de données toujours actif avec un nœud en veille, une puissance de calcul pré-modélisée qui monte en charge lors du basculement, et le DNS pour rediriger.

Une vérité critique de la plateforme traverse les trois stratégies. Le Backup Service (Acronis) couvre les VM et le 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 distinct : récupération à un instant donné (point-in-time recovery) dans la fenêtre de rétention du cluster, plus dump et restauration pour tout ce qui dépasse cette fenêtre. Considérer le Backup Service comme votre plan de reprise sur incident pour la base de données est l'erreur la plus coûteuse dans ce domaine, car vous ne découvrez l'écart que lors d'une récupération réelle. Les Snapshots aggravent la confusion : un snapshot de Block Storage est un retour arrière au niveau de la VM, local à la région, non incrémental, et non une sauvegarde cohérente de la base de données. Planifiez le plan de continuité des données autour du PITR et du dump/restauration pour les couches de données, et autour du Backup Service uniquement pour les VM et les volumes qu'il couvre réellement.

2. Répartition multi-zones et le piège de la zone automatique

La résilience commence par l'emplacement physique des ressources. IONOS CLOUD expose les zones de disponibilité comme primitive de placement, et la redondance obtenue dépend entièrement de la répartition des ressources appariées dans des zones distinctes. La plateforme n'infère pas votre intention.

Notez une asymétrie qui surprend les architectes. Les zones de disponibilité pour le calcul sont Zone 1, Zone 2 et Auto. Les zones de disponibilité pour le Block Storage sont Zone 1, Zone 2, Zone 3 et Auto. Il n'existe pas de Zone 3 pour le calcul, de sorte qu'un volume placé dans la Zone 3 ne dispose d'aucun serveur co-localisé dans cette même zone pour y être attaché. Pour une paire redondante calcul-stockage, concevez la répartition au sein des zones partagées par les deux plans.

Le piège réside dans le mot « Auto ». La sélection de la zone de disponibilité Auto constitue une indication de placement mono-zone qui permet à IONOS CLOUD de choisir une zone à votre place ; ce n'est pas une instruction de multi-zones ou de « répartition sur plusieurs zones ». Si vous créez deux serveurs destinés à former une paire HA et que vous les laissez tous deux sur Auto, il n'y a aucune garantie qu'ils soient placés dans des zones différentes, et ils peuvent se retrouver dans la même zone. Un domaine de défaillance partagé est précisément 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 distinctes. Auto est acceptable pour une ressource unique, non appariée, pour laquelle vous n'avez pas de préférence de zone ; il est inapproprié pour la redondance.

Pour FinCorp, cela signifie que le nœud de base de données en attente est placé dans une zone explicitement distincte de celle du nœud principal, et que le modèle de calcul en mode pilote est provisionné dans une zone nommée distincte de celle du niveau de production. La discipline de zones explicites est facile à appliquer lors de la conception et impossible à rétrofitter proprement après qu'une panne a démontré que la paire était co-localisée.

3. Pilotage basé sur l'état de santé : contrôles d'état de santé du Load Balancer, basculement IP et DNS orchestré par le client

IONOS CLOUD ne propose pas de produit de basculement managé. Il n'existe aucun orchestrateur qui surveille un nœud principal, déclare son indisponibilité et promeut un nœud secondaire sur l'ensemble de la pile, et aucun service de basculement managé inter-zones ou inter-sites. Il est important d'être précis quant à la primitive qui assure le pilotage tenant compte de l'état de santé, car ce n'est pas Cloud DNS.

Les primitives de pilotage automatisé et basé sur l'état de santé de la plateforme sont au nombre de deux. Premièrement, les contrôles d'état de santé du Load Balancer : le Managed Application Load Balancer effectue activement des contrôles d'état de santé de ses cibles arrière-plan via TCP ou HTTP, tandis que le Managed Network Load Balancer effectue ses contrôles d'état de santé uniquement via TCP (les contrôles d'état de santé prenant en compte HTTP sont une fonctionnalité exclusive de l'ALB) ; les deux prennent en charge des intervalles et des tentatives de reconnexion configurables, et détournent le trafic des cibles non saines au sein du propre pool de cibles arrière-plan du Load Balancer. Il s'agit d'un basculement automatisé réel, mais il est limité à la région et au LAN : il déplace le trafic entre les cibles d'un même pool, et non entre des zones ou des sites. Deuxièmement, les groupes de basculement IP : une IP réservée partagée entre des VM sur un LAN, destinée au basculement IP au niveau applicatif construit par le client ; elle est également locale au LAN. Le déploiement multi-zones (section 2) constitue le troisième pilier, mais il s'agit d'un déploiement, et non d'un pilotage.

Le basculement inter-zones et inter-sites se situe au-dessus de tous ces éléments, et il n'existe ici aucun mécanisme natif tenant compte de l'état de santé. Cloud DNS ne tient pas compte de l'état de santé : il ne surveille pas l'état de santé des points de terminaison et ne modifie pas un enregistrement de sa propre initiative. Le basculement inter-zones est donc orchestré par le client : votre propre contrôle d'état de santé (un moniteur externe ou un signal dérivé de l'état de santé du Load Balancer) détecte qu'un point de terminaison d'une zone est hors service et appelle l'API de Cloud DNS pour rediriger un enregistrement à TTL faible vers la zone saine. La contribution de Cloud DNS est que l'enregistrement est anycast, adossé à un SLA, et peut porter un TTL très faible ; l'automatisation de détection et de redirection est de votre responsabilité. Il s'agit du remplacement par basculement introduit dans l'Unité 1.3, mis en œuvre de manière honnête : composer une primitive tenant compte de l'état de santé (le Load Balancer au sein d'une zone) avec une redirection DNS à TTL faible pilotée par le client entre zones.

Cloud DNS est bien adapté à la partie DNS de cette composition. Il fonctionne sur un réseau anycast réparti sur 14 points de présence, offre un SLA de disponibilité par service de 99,995 pour cent, et prend en charge un TTL aussi bas que 60 secondes. Cette limite inférieure de TTL est le levier principal de RTO pour tout basculement basé sur DNS, car un résolveur continuera d'utiliser une réponse en cache jusqu'à l'expiration du TTL. Si votre enregistrement porte un TTL d'une heure, votre récupération pilotée par DNS ne pourra pas être inférieure à une heure, quelle que soit la rapidité de détection de la défaillance. Réduisez le TTL des enregistrements participant au basculement, et acceptez la légère augmentation du volume de requêtes comme le prix d'un basculement plus rapide.

Deux contraintes honnêtes façonnent la manière dont vous construisez cela. Premièrement, le DNS pilote uniquement les nouvelles connexions. Un client qui détient déjà une connexion vers le point de terminaison défaillant n'est pas déplacé par une modification DNS ; il doit se reconnecter, auquel point il résout la nouvelle adresse. C'est pourquoi les couches applicatives situées derrière un basculement DNS doivent être sans état, avec l'état de session et l'état partagé externalisés vers la couche en mémoire plutôt que conservés sur l'instance. Deuxièmement, la capacité de contrôle d'état de santé réside sur le plan du Load Balancer (ou dans votre propre moniteur externe), et jamais dans Cloud DNS : il n'existe pas de type d'enregistrement de basculement par contrôle d'état de santé, car Cloud DNS ne vérifie tout simplement pas l'état de santé. En pratique, vous composez les plans : un Load Balancer détermine l'état de santé au sein d'une zone, et un appel API piloté par le client redirige l'enregistrement DNS entre les points de terminaison au niveau des zones. Étant donné que ce basculement inter-zones doit être piloté par vos outils de surveillance ou d'orchestration, et non par Cloud DNS, considérez la mise à jour de l'enregistrement comme une conception au niveau API, et non comme un assistant de console en quelques clics ; le chemin de la console concerne la gestion des zones et des enregistrements, et Cloud DNS ne déclenche jamais lui-même la modification.

4. Deux plans : pilotage du trafic et continuité des données

Une conception de résilience durable maintient deux préoccupations distinctes, car elles échouent et se rétablissent à des échelles de temps différentes et par des mécanismes différents.

Le plan de pilotage du trafic décide où les requêtes sont dirigées. Il est constitué d'enregistrements Cloud DNS, de paramètres TTL et des vérifications d'état du load-balancer qui déterminent l'état des points de terminaison. Son rôle est de rediriger rapidement les nouvelles connexions loin d'un emplacement défaillant. Sa vitesse de récupération est limitée par le plancher TTL et par les intervalles de vérification d'état, 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 à la destination sont à jour et correctes. Il est constitué du mode de réplication de la base de données et de PITR, du Backup Service pour les VM et le Block Storage, des opérations d'export/restauration pour les bases de données, et du Object Storage en tant que zone d'archivage. Ses caractéristiques de récupération sont le RPO que vous pouvez réellement atteindre et la durée d'une restauration.

Confondre les deux est un échec classique. Rediriger le trafic vers un serveur de secours en quelques secondes ne sert à rien si les données de ce serveur sont en retard de plusieurs heures, et un réplique parfaitement à jour est inutile s'il n'existe aucun mécanisme pour rediriger les clients vers elle. Concevez chaque plan selon sa propre cible : le plan de pilotage selon le RTO, le plan de continuité selon le RPO. La conception pilot-light de FinCorp rend cette séparation concrète : les vérifications d'état du load-balancer et un enregistrement Cloud DNS à faible TTL, redirigé par une vérification externe, forment le plan de pilotage qui atteint le RTO, tandis que le nœud de base de données de secours toujours actif et sa fenêtre PITR forment le plan de continuité qui atteint le RPO. Les deux ne sont interconnectés qu'au moment de la bascule.

5. Réconciliation de VMware HA dédié avec la multi-zone de la plateforme

FinCorp exploite un important parc VMware, dont une partie est déployée sur IONOS CLOUD Private Cloud, le SDDC VMware managé dédié. Les parcs hybrides comportent donc simultanément deux modèles de résilience distincts, et l'architecte doit savoir où chacun s'applique.

À l'intérieur d'un cluster Private Cloud, la tolérance aux pannes est une propriété VMware, et non une propriété de zone de disponibilité de la plateforme. vSAN (version 8.0, édition Enterprise selon la documentation Private Cloud, sur vSphere 8.0 Enterprise Plus) protège contre les pannes de hôte et de disque grâce au codage par suppression et au miroir. La matrice énumère trois méthodes de tolérance aux pannes : le miroir RAID-1 (minimum 3 hôtes), le codage par suppression RAID-5 (minimum 4 hôtes) et le codage par suppression RAID-6 (minimum 6 hôtes). vSAN exige un minimum de 3 hôtes pour maintenir la protection RAID1 (deux copies complètes des données), ce qui constitue la taille minimale du cluster. vSphere HA redémarre les VM sur les hôtes survivants lorsqu'un hôte tombe en panne. Il s'agit d'une résilience intra-cluster : elle permet au SDDC de continuer à fonctionner malgré des pannes matérielles à l'intérieur d'un même cluster, et c'est le modèle opérationnel natif VMware que le parc connaît 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'un hôte au sein 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 une bascule entre sites à environ 50 EUR par VM protégée et par mois. La limite honnête, énoncée dans l'Unité 4.4 et reprise dans la 7.4, est que les seuls outils VMware listés par IONOS CLOUD à cet effet sont VCDA, NSX-T L2 VPN pour l'extension en couche 2, et vMotion intra-cluster. Il n'existe aucune capacité de mobilité en direct inter-sites et aucun autre module VMware à supposer.

Pour une conception hybride FinCorp, les deux modèles se composent plutôt qu'ils ne sont en concurrence. Au sein du cœur VMware dédié, s'appuyer sur vSAN et vSphere HA pour la tolérance aux pannes intra-cluster. Pour la couche native de la plateforme (calcul standard, bases de données managées, conteneurs), s'appuyer sur un placement multi-zone explicite, des vérifications d'état du load-balancer au sein d'une zone ainsi qu'un re-pointage DNS à TTL faible orchestré par le client entre les zones, et la restauration PITR des bases de données. La continuité inter-sites pour le parc VMware est assurée par la réplication VCDA ; la continuité inter-zones pour le parc natif est assurée par la composition DNS plus plan de données décrite dans les sections 3 et 4. Le point de réconciliation consiste à reconnaître que « HA » signifie des choses différentes de chaque côté, et que le mécanisme de l'un ne remplace pas celui de l'autre.

Déroulement de la mise en œuvre de DCD

Vous allez configurer une bascule DNS sur deux zones pour un point de terminaison FinCorp et vérifier qu'elle oriente le trafic. L'objectif architectural est le plan d'orientation décrit à la section 4 : un nom qui se résout vers un point de terminaison principal dans une zone et qui peut être déplacé vers un point de terminaison de secours dans une autre zone. Cette configuration combine le travail sur Cloud DNS de l'Unité 3.7 avec la discipline des zones explicites de la section 2. Prérequis : deux points de terminaison backend (par exemple, deux adresses d'équilibreur de charge ou de serveur) déployés dans des zones de disponibilité explicitement différentes, et le privilège « Access and manage DNS » ou celui d'administrateur de contrat, nécessaires pour gérer les zones et les enregistrements.

Objectif de construction : Configurer un enregistrement DNS de bascule à faible TTL orchestré par le client sur une paire de deux zones et le valider, en notant que Cloud DNS ne réalise pas de vérification d'état par défaut.

Étapes (dans Data Center Designer) :

1. Vérifiez que les deux points de terminaison se trouvent dans des zones différentes. Avant de toucher au DNS, vérifiez dans DCD que les ressources principale 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 placé devant une paire co-localisée est une pure formalité.
2. Ouvrez le DNS Manager et sélectionnez Create primary DNS zone. Saisissez le nom de la zone (le domaine ou sous-domaine FinCorp qui sera placé devant le service). La zone est le conteneur pour les enregistrements de bascule.
3. Une fois la zone provisionnée, ouvrez-la depuis la liste Primary Zones en utilisant Details & Records.
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. Réglez le TTL sur une valeur basse (à ou près du seuil minimal de 60 secondes) afin qu'une bascule ultérieure se propage rapidement ; ce TTL est votre levier principal pour le RTO.
5. Notez l'adresse du point de terminaison de secours dans la zone 2. Vous pointerez le même nom d'enregistrement vers cette adresse lors d'une bascule. Conservez les détails du point de terminaison de secours documentés afin que la bascule soit une modification unique et non ambiguë.
6. Définissez la source de vérification d'état sur le plan de l'équilibreur de charge. Étant donné que Cloud DNS n'expose pas d'enregistrement de bascule avec vérification d'état intégrée, attachez la vérification d'état là où elle réside : sur le groupe de cibles du Managed ALB ou NLB placé devant chaque point de terminaison, configurez la vérification d'état périodique afin que l'équilibreur ne serve que des cibles saines. C'est le signal de détection auquel votre bascule réagira.
7. Configurez la bascule automatisée au niveau de l'API. Pour rendre la bascule automatique plutôt que déclenchée par un opérateur, pilotez la mise à jour de l'enregistrement depuis la surveillance ou l'orchestration : en cas de signal d'insalubrité persistant pour la zone 1, appelez l'API Cloud DNS pour mettre à jour le contenu de l'enregistrement vers l'adresse de la zone 2. Le chemin via la console concerne la gestion des zones et des enregistrements ; l'automatisation est la modification via l'API, il faut donc conserver cette sous-étape au niveau de la conception et de l'API plutôt que d'inventer un assistant dans la console.
8. Validez en simulant une défaillance. Retirez le point de terminaison principal (zone 1) du service ou faites échouer sa vérification d'état, puis déclenchez ou effectuez la mise à jour de l'enregistrement vers l'adresse de secours. Depuis un client externe, après l'expiration du 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 avant de se reconnecter, ce qui prouve la exigence de couche sans état.

Erreurs courantes :

• Laisser les points de terminaison appariés sur la zone de disponibilité Auto. Auto est une indication de zone unique, et non une instruction de répartition entre les zones ; définissez des zones explicites et différentes pour les deux membres de la paire avant de construire la bascule.
• Définir un TTL long sur l'enregistrement de bascule. Un TTL élevé limite votre RTO atteignable à la valeur du TTL, car les résolveurs conservent la réponse en cache ; réduisez-le à proximité du seuil minimal de 60 secondes pour les enregistrements qui participent à la bascule.
• Supposer que Cloud DNS possède une bascule gérée ou un enregistrement de vérification d'état natif. Ce n'est pas le cas ; la détection repose sur les vérifications d'état de l'équilibreur de charge et la bascule automatique est une mise à jour d'enregistrement pilotée par l'API. N'attendez pas un bouton dans la console qui n'existe pas.
• S'attendre à ce que le DNS déplace les connexions actives. Le DNS n'oriente que les nouvelles connexions ; si la couche applicative conserve l'état de session sur l'instance, ces sessions seront interrompues. Externalisez l'état vers la couche en mémoire afin que la couche soit véritablement sans état.
• Considérer Backup Service comme le plan de reprise sur incident pour la base de données. Il couvre les VM et le Block Storage, mais pas les bases de données gérées ; la continuité de la base de données repose sur PITR et sur la sauvegarde/restauration. Validez le plan de continuité des données séparément du plan d'orientation.

Une illustration succincte au niveau de l'API de la modification de bascule (le point architectural est que la partie DNS de la bascule est une mise à jour du contenu d'enregistrement pilotée par le client, et non une politique gérée ni quelque chose que Cloud DNS déclenche de lui-même) :

# 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 CLOUD est composée, et non achetée. On part des RTO et RPO définis par l'entreprise, on choisit l'une des trois stratégies de récupération, on place les paires redondantes dans des zones distinctes explicites, et on sépare le plan de guidage du trafic (vérifications d'état de l'équilibreur de charge au sein d'une zone, plus une redirection à faible TTL de Cloud DNS orchestrée par le client entre zones) du plan de continuité des données (PITR de la base de données et dump/restore, le Backup Service pour les VM et le Block Storage, l'archive Object Storage). Il n'existe aucun produit de basculement managé ni aucun orchestrateur inter-zones managé. Le guidage conscient de l'état de la plateforme est assuré par l'équilibreur de charge (au sein de son pool) et les groupes de basculement IP (au sein d'un LAN) ; le basculement inter-zones est une mise à jour d'enregistrement API pilotée par le client que Cloud DNS sert mais ne déclenche pas, car Cloud DNS n'est pas conscient de l'état. Pour les environnements hybrides, VMware vSAN et vSphere HA dédiés couvrent la tolérance aux pannes au sein du cluster, tandis que la multi-zonalité de la plateforme, la composition LB-plus-DNS et VCDA couvrent respectivement la continuité inter-zones et inter-sites.

Points clés :

• Les RTO et RPO sont des décisions d'entreprise ; l'architecte conçoit en conséquence et précise le coût de chaque élément. Les trois stratégies (sauvegarde-restauration, pilote lumineux, actif-actif) arbitrent entre le coût et la vitesse de récupération.
• Le placement dans les zones de disponibilité doit être explicite pour toute paire redondante. Auto est une indication de placement dans une seule zone de disponibilité, et le Block Storage dispose d'une zone 3 que le calcul ne possède pas.
• Les primitives de guidage conscient de l'état de la plateforme sont les vérifications d'état de l'équilibreur de charge (au sein du pool d'arrière-plan de l'équilibreur de charge) et les groupes de basculement IP (au sein d'un LAN) ; il n'existe aucun orchestrateur inter-zones managé.
• Cloud DNS (anycast, 14 PoPs, SLA de 99,995 pour cent, plancher TTL de 60 secondes) n'est pas conscient de l'état et n'effectue aucun basculement automatisé. Le basculement inter-zones est une redirection d'enregistrement à faible TTL orchestrée par le client que Cloud DNS sert mais ne déclenche pas ; le plancher TTL est le levier principal du RTO et DNS ne dirige que les nouvelles connexions.
• Garder le plan de guidage et le plan de continuité des données séparés ; le Backup Service ne couvre pas les bases de données managées, dont la continuité repose sur le PITR et le dump/restore.
• Au sein de Private Cloud, vSAN (RAID-1/5/6, minimum 3 hôtes pour RAID1) et vSphere HA offrent la tolérance aux pannes au sein du cluster ; la continuité inter-sites est assurée par VCDA, et il n'existe aucune mobilité en direct inter-sites.

Terminologie importante :

• RTO (Recovery Time Objective) : durée maximale tolérable d'une interruption de service ; le plan de guidage est conçu pour la respecter.
• RPO (Recovery Point Objective) : perte de données maximale tolérable mesurée en temps ; le plan de continuité des données est conçu pour la respecter.
• Zone de disponibilité Auto : indication de placement dans une seule zone de disponibilité permettant à IONOS CLOUD de choisir une zone, et non une instruction de redondance multi-zones.
• Plancher TTL : durée de vie minimale d'un enregistrement (60 secondes sur Cloud DNS) ; il délimite le RTO DNS piloté le plus bas atteignable.
• VCDA (VMware Cloud Director Availability) : outil natif VMware de réplication asynchrone et de basculement pour la continuité inter-sites de l'environnement VMware dédié.

Lectures complémentaires

• Unité 3.7 : DNS and Failover Routing (la zone et les enregistrements réutilisés par cette unité)
• Unité 3.6 : Hybrid Connectivity (les passerelles qui relient les sites lors d'une bascule)
• Unité 5.7 : Data Protection and Lifecycle (le plan de continuité des données en détail)
• Unité 4.4 : Private Cloud (Dedicated VMware) et Unité 7.4 : Migration and Hybrid Cutover (VCDA et le parc VMware)