Google Distributed Cloud (GDC) sous air gap offre des fonctionnalités de déploiement qui assurent une haute disponibilité et une reprise après sinistre. Cette fonctionnalité est appelée multizone sur cette page.
La fonctionnalité multizone vous permet d'exécuter des charges de travail stratégiques déconnectées sur GDC en offrant des fonctionnalités de haute disponibilité (HA) et de reprise après sinistre (DR) semblables à celles des fournisseurs de cloud hyperscale publics. GDC fournit des services gérés et d'infrastructure résilients aux défaillances locales. Pour certains services, vous devez déterminer le niveau de résilience requis par votre charge de travail. Voici quelques exemples de services offrant des fonctionnalités multizones :
Pour obtenir la liste complète des services offrant des fonctionnalités multizones, consultez Services GDC compatibles avec les configurations multizones.
GDC multizone offre des fonctionnalités de gestion des ressources globales pour simplifier la gestion des ressources dans les zones GDC. Vous pouvez afficher toutes les ressources et tous les services GDC gérés dans un univers, avec une visibilité sur les alertes, l'état, l'utilisation, la journalisation, la surveillance et la facturation.
Les univers multizones dans GDC nécessitent une symétrie globale des ressources et du matériel. Cette symétrie signifie que le matériel et les organisations doivent être identiques dans toutes les zones et ne peuvent pas être modifiés indépendamment dans une zone spécifique.
Le multizone vous fournit également des blocs de construction pour atteindre vos objectifs de reprise après sinistre et de continuité d'activité. Il offre trois fonctionnalités principales :
Continuité des services du plan de contrôle. En cas de sinistre zonal, les fonctionnalités critiques requises pour récupérer une organisation et ses services associés seront déjà présentes dans une autre zone.
Ressources multizones. Par exemple, la réplication asynchrone du stockage entre les zones GDC.
Services gérés multizones. Par exemple, les équilibreurs de charge proposent des variantes multizones contrôlées par un service géré.
Qu'est-ce qu'une zone ?
Chaque zone peut être un domaine de sinistre indépendant en fonction de son emplacement. Par exemple, deux zones situées à moins d'un kilomètre l'une de l'autre dans une zone de subduction se trouveraient dans le même domaine de sinistre. Chaque zone est une implémentation complète de GDC sous air gap, une solution matérielle et logicielle qui ne nécessite aucune connectivité à Google Cloud à aucun moment. Une zone gère l'infrastructure, les services, les API et les outils qui utilisent un plan de contrôle local.
Une zone GDC sous air gap est composée de quatre couches :
Matériel : matériel sous-jacent et conception du rack définis par Google.
Infrastructure : gère le matériel et fournit des abstractions qui permettent aux couches logicielles de s'exécuter sans référence à des configurations spécifiques au matériel.
Plate-forme de services : framework permettant de créer des services sur le cloud distribué, qui assure la cohérence entre les services gérés et les services Marketplace.
Services gérés et Marketplace : services cloud destinés aux clients et exécutés sur GDC.
Un groupe de zones isolées connectées est appelé univers. Pour déployer des applications tolérantes aux pannes et à haute disponibilité qui vous protègent contre les défaillances inattendues, vous devez déployer vos applications sur plusieurs zones d'un univers.
Qu'est-ce qu'une région ?
Une région est un regroupement de zones dans un univers, conformément à nos exigences de latence. Une zone sans pairs suffisamment proches est considérée comme sa propre région. Les zones d'une région doivent être séparées d'au moins 10 km pour garantir qu'elles constituent des domaines de sinistre distincts dans de nombreux régimes de conformité.
Les régions peuvent être distantes de centaines de kilomètres. C'est pourquoi GDC ne propose que des services synchrones dans les régions. Les services asynchrones sont disponibles dans les régions et entre elles.
Les services asynchrones effectuent la réplication en arrière-plan, ce qui permet d'obtenir des objectifs de point de récupération (RPO) faibles, mais non nuls. En règle générale, les services asynchrones restent disponibles pendant les partitions réseau.
Voici quelques exemples de services asynchrones isolés de GDC :
- Stockage de blocs
- Stockage d'objets
Les zones d'une même région doivent répondre aux exigences de latence qui permettent la fourniture de services fortement cohérents. Les services synchrones effectuent la réplication immédiatement, ce qui garantit que chaque écriture est disponible dans au moins deux zones. Il s'agit de l'étape clé pour atteindre un RPO nul. En règle générale, les services synchrones ont une latence plus élevée que les services non répliqués et peuvent devenir indisponibles lors de partitions réseau.
Voici quelques exemples de services synchrones GDC sous air gap :
- Partages de fichiers NFS
- Stockage d'objets
Qu'est-ce qu'un univers ?
Les zones disposant d'une connectivité réseau directe, quelle que soit la distance ou la latence, et d'un plan de gestion et de contrôle partagé appartiennent à un univers. Un univers peut comporter jusqu'à six zones.
Chaque univers peut être constitué de plusieurs zones organisées en régions interconnectées. Par exemple, deux régions dans l'État américain de Virginie et à Amsterdam, aux Pays-Bas, respectivement, chacune avec trois zones :
Région 1 des centres de données Google (Virginie)
- Zone 1 (us-virginia1-a)
- Zone 2 (us-virginia1-b)
- Zone 3 (us-virginia1-c)
Région de centre de données Google 2 (Pays-Bas)
- Zone 1 (eu-ams1-a)
- Zone 2 (eu-ams1-b)
- Zone 3 (eu-ams1-c)
Le schéma suivant montre un exemple d'univers GDC.
Un univers peut comporter entre une et six zones, et un ou deux centres d'opérations.
Les univers proposent les stratégies de récupération automatisées suivantes, quelle que soit la configuration régionale :
- Pour les univers comportant deux zones, la récupération doit être déclenchée manuellement.
- Pour les univers comportant trois zones ou plus, la récupération peut être déclenchée automatiquement.
Pour en savoir plus, contactez votre opérateur.
Ressources zonales
Les ressources zonales sont disponibles dans une seule zone. Les interruptions zonales peuvent affecter une partie ou l'ensemble des ressources de cette zone. Une instance de machine virtuelle (VM) résidant dans une zone spécifique est un exemple de ressource zonale. Pour en savoir plus sur la gestion des ressources zonales dans un univers GDC, consultez Serveurs de l'API Management.
Ressources globales
Les ressources globales sont déployées dans les zones d'un univers, comme les organisations. Elles offrent ainsi une disponibilité plus élevée que les ressources zonales. Les ressources globales sont déployées dans le serveur d'API de gestion global et y sont gérées.
Pour chaque organisation, il existe des serveurs d'API de gestion mondiaux et zonaux.
Domaines liés aux catastrophes
Un domaine de sinistre représente un ensemble de ressources susceptibles d'être affectées en même temps en raison de leur proximité physique. Il s'agit donc d'une construction liée à la durabilité utilisée pour simplifier les exigences de séparation des zones. En général, un domaine sinistré correspond à un seul campus.
Dans la plupart des univers GDC, Google ne possède pas les installations, mais travaille plutôt avec des fournisseurs de colocation qui disposent de centres de données offrant un accès à une infrastructure robuste, à une alimentation redondante et à une connectivité haut débit. Cette approche offre des performances et un temps d'activité optimaux pour les applications et les services, en fonction de la stratégie et des bonnes pratiques de Google en matière de haute disponibilité et de reprise après sinistre.
Contactez votre opérateur pour en savoir plus sur les spécifications du domaine de sinistre pour votre univers.
API globales et zonales
GDC air-gapped propose deux niveaux d'API de plan de gestion pour créer et gérer des ressources globales et zonales : les API globales et les API zonales. Pour savoir comment ces types d'API sont gérés dans un univers GDC, consultez la documentation sur les serveurs d'API de gestion mondiaux et zonaux.
Les API globales et zonales sont des API déclaratives Kubernetes diffusées à différents points de terminaison. Les ressources GDC sont représentées sous forme de ressources personnalisées Kubernetes dans les serveurs d'API. Les serveurs d'API mondiaux partagent un seul cluster etcd distribué sur plusieurs zones pour assurer une cohérence forte avec tolérance aux pannes, au prix d'une latence plus élevée et d'un nombre de requêtes par seconde (RPS) réduit par rapport aux serveurs d'API zonaux. Dans chaque organisation, un serveur d'API de gestion zonale fournit l'API zonale aux administrateurs et aux développeurs pour gérer les ressources zonales, et un serveur d'API de gestion globale fournit l'API globale pour gérer les ressources globales.
Pour en savoir plus sur les API dans GDC, consultez la présentation des API.
gdcloud CLI
La CLI gdcloud permet d'interagir avec l'API zonale ou globale pour gérer vos ressources et leur déploiement, y compris :
- Se connecter à l'URL de la console zonale ou globale à l'aide de la CLI
- Utiliser un indicateur CLI zonal pour des actions spécifiques à une zone
L'URL globale est celle qui est configurée par défaut lors de l'initialisation de la CLI gdcloud. Vous pouvez mettre à jour votre configuration gdcloud pour définir des URL zonales et vous y connecter afin d'effectuer des tâches spécifiques à une zone.
De même, la CLI gdcloud propose un indicateur --zone que vous pouvez définir pour de nombreuses tâches de gestion des ressources dans les groupes de commandes. Lorsque vous êtes connecté à la configuration d'URL globale, vos actions CLI sur les ressources globales sont appliquées à toutes les zones pour lesquelles elles sont dans le champ d'application.
Pour en savoir plus sur l'utilisation de la gcloud CLI pour les services zonaux et globaux, consultez Gérer les ressources dans les zones.
Console GDC
La console GDC d'une organisation donnée est accessible depuis toutes les zones du même univers. Vous pouvez donc utiliser la console GDC pour gérer toutes les ressources mondiales et zonales d'une organisation.
Les fonctionnalités multizones suivantes sont disponibles dans la console GDC :
Naviguer à l'aide d'un nom de domaine complet (FQDN) : vous pouvez utiliser le FQDN global pour accéder automatiquement au point de terminaison de la console zonale le plus approprié. Si le nom de domaine complet global ne parvient pas à être résolu pour une raison quelconque ou si vous souhaitez vous connecter à une zone spécifique, vous pouvez utiliser le nom de domaine complet zonal pour accéder à un point de terminaison de console spécifique dans une zone cible.
Gérer la création de ressources zonales : un sélecteur de zone est disponible lorsque vous créez une ressource zonale. Il détermine la zone dans laquelle une ressource est créée. À l'inverse, le sélecteur de zone n'est pas visible lorsque vous créez une ressource globale.
Afficher les ressources existantes dans les zones : différentes pages de ressources de la console GDC affichent les ressources par zone. Vous pouvez utiliser le sélecteur de zone pour afficher les ressources de la zone choisie. Vous pouvez accéder aux ressources de toutes les zones en accédant aux URL de la console GDC globale et zonale, puis en sélectionnant la zone appropriée dans le sélecteur. Toutefois, il n'existe pas de vue agrégée des ressources de toutes les zones.
Pour savoir comment gérer les ressources dans plusieurs zones d'un univers GDC avec la console GDC, consultez Gérer les ressources dans plusieurs zones.
GDC est conçu pour résister aux défaillances. Par conséquent, si un problème de connectivité zonale est détecté, la console GDC affiche une bannière persistante vous informant que vous ne pourrez peut-être pas apporter de modifications aux ressources globales.
Conteneurs de ressources
Une organisation définit une limite de sécurité pour les ressources à administrer ensemble. Chaque organisation dans GDC air-gapped fournit une API globale et une API zonale pour permettre la création de ressources globales et zonales au sein de l'organisation. Lors de la création d'une organisation mondiale, l'opérateur est responsable du déploiement des zones et de la configuration des paramètres zonaux, tels que la quantité de stockage et le nombre de serveurs physiques disponibles pour les charges de travail des utilisateurs.
Contactez votre opérateur pour en savoir plus sur la configuration spécifique des zones pour votre organisation.
Un projet fournit un regroupement logique des ressources de service au sein d'une organisation, ainsi qu'une limite de cycle de vie et de règles pour la gestion des ressources. Tous les projets sont globaux et couvrent par défaut les zones que vous avez configurées dans votre univers.
Bien que toutes les ressources de service doivent être créées dans un projet, tous les services ne sont pas globaux. Pour les services qui ne sont compatibles qu'au niveau d'une zone, vous devez les déployer et les gérer dans les zones de votre choix. Pour en savoir plus, consultez la documentation appropriée d'un type de ressource.
IAM
Les services IAM (Identity and Access Management) suivants doivent être configurés en tant que ressources globales :
- Fournisseurs d'identité (IdP) pour l'authentification
- Contrôle des accès basé sur les rôles (RBAC)
- Identités de service
Chaque configuration IAM s'étend à toutes les zones d'un univers.
Authentification
Vous devez connecter un fournisseur d'identité à votre organisation à l'aide de la ressource globale IdentityProviderConfig. Cette ressource vous permet de vous assurer que vous utilisez le même IdP pour vous connecter à votre organisation pour toutes les zones de l'univers.
Pour en savoir plus, consultez Se connecter à un fournisseur d'identité.
Accès
Chaque utilisateur ou groupe doit se voir attribuer une ressource IAMRoleBinding globale pour accéder aux serveurs d'API de gestion globale et zonale, ainsi qu'aux clusters Kubernetes de manière cohérente dans chaque zone de l'organisation.
Accès au serveur de l'API Global Management :
IAMRoleBindingest propagé en tant queClusterRoleBindingouRoleBindingà unClusterRoleprédéfini dans le serveur d'API global.Accès au serveur de l'API Management zonale :
IAMRoleBindingest propagé en tant queClusterRoleBindingouRoleBindingdans le serveur de l'API Management zonale.Accès au cluster Kubernetes :
IAMRoleBindingest propagé en tant queProjectRoleetProjectRoleBindingpour être propagé en tant queRoleetRoleBindingKubernetes dans les espaces de noms Kubernetes du serveur d'API Management et des clusters Kubernetes, correspondant au projet dans lequel se trouventProjectRoleetProjectRoleBinding.
Pour en savoir plus, consultez Accorder et révoquer l'accès.
Identité du service
Les comptes de service sont des comptes principaux utilisés par les charges de travail et les services pour consommer des ressources et accéder aux microservices de manière sécurisée et programmatique. Il s'agit d'un type d'identité spécial utilisé par une application ou une charge de travail, et non par une personne. Comme un compte utilisateur, les comptes de service peuvent se voir attribuer des autorisations et des rôles, mais ils ne peuvent pas se connecter comme un utilisateur humain. La fonctionnalité d'identité de service est incluse dans la ressource ProjectServiceAccount globale.
Pour en savoir plus, consultez S'authentifier avec des comptes de service.
Mise en réseau
Vous pouvez configurer les services réseau suivants pour vos zones GDC :
- Services Anycast
- Équilibrage de charge
- Règles de réseau du projet
- DNS
Configurez vos services réseau mondiaux et zonaux pour gérer le trafic réseau entre les zones et à l'intérieur des zones dans votre univers GDC.
Services Anycast
La multizone fournit des services réseau Anycast pour assurer une haute disponibilité des ressources de plusieurs zones. De même, les options d'interconnexion des centres de données (DCI) sont implémentées sous forme de maillage complet pour interconnecter plusieurs zones isolées de GDC. Cela permet à GDC d'offrir une protection multizone contre les sinistres dans plusieurs zones, tout en répondant à l'exigence d'une déconnexion complète de toute infrastructure Google.
Les services Anycast sont représentés par des préfixes IPv4 uniques de taille /32, qui sont fournis à l'aide du protocole BGP (Border Gateway Protocol) aux installations des clients, ce qui garantit l'accessibilité depuis n'importe quel réseau connecté. Bien que chaque service Anycast soit accessible depuis toutes les zones du réseau GDC isolé, le point de terminaison réel vers lequel le trafic est dirigé dépend de facteurs tels que la proximité et la préférence de zone en fonction de votre règle de routage personnalisée.
La diffusion du trafic est optimisée en l'acheminant vers l'instance de service disponible la plus proche, toujours dans la même zone que la connexion client. Cela permet non seulement de réduire la latence, mais aussi d'améliorer les performances et la réactivité globales du service. Par exemple, si un service Anycast est déployé dans les zones 1, 2 et 3, une requête client provenant de la zone 2 est généralement acheminée vers l'instance de service de la zone 2, car il s'agit de l'option la plus proche et donc la plus efficace.
Bien que la plage Anycast soit accessible dans le monde entier, elle n'est fournie qu'aux clients des zones spécifiques où le service est activement déployé. Cette configuration d'accès signifie qu'un service déployé dans la zone 1 ne serait disponible que pour les clients connectés à la zone 1, et non pour ceux connectés à d'autres zones.
De plus, GDC implémente un système de préférence de zone où les zones se voient attribuer une valeur numérique lors de leur création, indépendamment de leur nom, qui définit l'attraction des clients. Par exemple, si un service Anycast est déployé dans des zones avec les valeurs numériques 1, 2 et 3, le trafic client est généralement dirigé vers la zone avec la valeur la plus basse définie avant les autres zones comme emplacement préféré. Ce système de préférences offre un certain degré de prévisibilité et de contrôle sur les schémas de trafic, mais il inclut également des mécanismes de basculement intégrés. En cas de défaillance ou d'indisponibilité affectant la zone préférée, le système transfère automatiquement le trafic vers une autre zone, ce qui garantit la disponibilité ininterrompue du service.
Dans une configuration multizone, l'accès aux services d'une zone spécifique nécessite une interconnexion entre votre réseau et cette zone. Pour un déploiement multizone cohérent, les interconnexions créées dans chaque zone de votre univers doivent être identiques en termes de capacité et de configuration. Chaque zone à laquelle vous souhaitez accéder doit disposer d'une interconnexion correspondante, et ces interconnexions doivent être identiques les unes aux autres.
Pour en savoir plus, contactez votre opérateur.
Équilibrage de charge
GDC fournit un équilibreur de charge L4 en mode traversée pour les charges de travail Kubernetes et de VM. Cet équilibreur de charge propose les configurations suivantes :
- Protocole TCP ou UDP.
- Aucun proxy entre la charge de travail et le client.
- Équilibrage de charge dédié à des zones spécifiques ou globalement à toutes les zones de l'univers.
- Trafic réseau interne au sein de votre organisation ou trafic réseau externe entre organisations.
Le schéma suivant illustre les composants d'un équilibreur de charge L4 passthrough externe dans un univers GDC :
L'équilibreur de charge peut être affiné pour fonctionner dans une seule zone ou globalement pour toutes les zones.
Pour en savoir plus sur l'équilibrage de charge dans GDC, consultez Gérer les équilibreurs de charge.
Règles de réseau du projet
Les règles de transfert de données entrantes ou sortantes pour un projet sont définies dans les règles réseau du projet. Étant donné que les projets sont une ressource globale, vous devez également définir les règles réseau d'un projet de manière globale pour autoriser le trafic réseau multizone pour les services et les charges de travail d'un projet.
Pour en savoir plus, consultez Configurer des règles de réseau pour les projets.
DNS
Les services du système de noms de domaine (DNS) sont mondiaux et couvrent plusieurs zones. Si une instance de service DNS devient inaccessible dans une zone, les clients sont servis de manière transparente par une autre instance de service DNS dans une autre zone.
Chaque organisation d'une zone contient trois serveurs DNS faisant autorité au niveau mondial :
Serveur interne de l'infrastructure mondiale : serveur faisant autorité qui résout les requêtes DNS dans le réseau VPC (Virtual Private Cloud) de l'infrastructure. Ce serveur ne gère que les charges de travail d'infrastructure. Les charges de travail utilisateur n'interagissent pas avec ce composant. Tous les déploiements internes de l'infrastructure mondiale d'une organisation dans toutes les zones sont accessibles avec une adresse IP Anycast.
Serveur interne client mondial : serveur faisant autorité qui résout les requêtes DNS dans le réseau cloud privé virtuel (VPC) du client. Ce serveur ne gère que les charges de travail utilisateur, telles qu'un pod dans un cluster Kubernetes ou une machine virtuelle (VM), et résout toutes les requêtes DNS provenant de ces charges de travail utilisateur. Toutes les configurations internes des clients mondiaux d'une organisation dans toutes les zones sont accessibles avec une adresse IP Anycast. Étant donné que les VPC s'étendent sur plusieurs zones, une demande de résolution d'un nom de domaine complet (FQDN) global provenant d'une zone peut atterrir sur l'une des zones saines.
Serveur externe client mondial : serveur faisant autorité qui résout les requêtes DNS provenant du réseau du client. Toutes les adresses IP Anycast permettent d'accéder à tous les déploiements externes des clients d'une organisation dans toutes les zones.
Vous pouvez vous connecter à GDC avec un réseau externe dédié ou partagé. Ces types de réseau déterminent la façon dont GDC résout vos requêtes DNS.
Un réseau externe dédié se connecte directement au serveur DNS externe du client mondial, qui résout la requête. Vous pouvez également connecter un réseau externe partagé à la racine de votre hiérarchie DNS. Ce serveur racine fournit l'enregistrement du serveur de noms (NS) de la requête pour la zone DNS appropriée au serveur DNS externe du client mondial. Votre résolveur DNS résout ensuite la requête de manière récursive.
GDC fournit une résolution DNS pour le trafic interne et externe, à la fois au niveau mondial et dans une seule zone.
Les requêtes provenant de votre réseau externe sont acheminées depuis votre résolveur DNS. De même, les requêtes DNS internes proviennent de vos charges de travail dans un univers GDC.
Les requêtes DNS ont le format de nom de domaine complet suivant :
- Requêtes DNS globales :
SERVICE_NAME.ORG_NAME.SUFFIX, par exempleservice-1.org-1.google.com. - Requêtes DNS zonales :
SERVICE_NAME.ORG_NAME.ZONE_NAME.SUFFIX, telles queservice-1.org-1.zone-1.google.com.
Pour savoir comment configurer la mise en réseau dans un univers GDC, consultez Présentation de la mise en réseau.
Stockage
Pour la version 1.14.4 et les versions ultérieures, les univers multizones permettent d'utiliser des ressources de stockage répliquées telles que des volumes et des buckets en mode asynchrone pour les scénarios de reprise après sinistre. Ces options de ressources de stockage permettent la réplication asynchrone des données entre deux zones d'un même univers. La réplication asynchrone s'effectue en arrière-plan, ce qui permet d'obtenir un RPO faible, mais non nul, en cas de sinistre. Toutes les données répliquées sont en ligne et immédiatement accessibles, mais une procédure de basculement manuel peut être nécessaire pour permettre l'écriture dans la zone secondaire.
Réplication asynchrone des blocs : fournit des volumes (PV) répliqués de manière asynchrone, qui maintiennent l'équivalence des blocs entre les volumes principal et secondaire. En raison de la nature asynchrone, le volume secondaire reflétera l'état du volume principal à un moment donné dans le passé (RPO non nul). Le volume secondaire ne peut pas être monté tant qu'il reste la cible de la réplication. Une intervention manuelle est nécessaire pour mettre fin à la relation et permettre les écritures.
Réplication asynchrone des buckets : les buckets répliqués sont associés entre eux dans les zones, ce qui crée une relation de réplication bidirectionnelle des données. Les données d'objet écrites dans des buckets de zone principale ou secondaire à l'aide de cette fonctionnalité sont copiées dans l'autre zone. Étant donné que les données sont copiées de manière asynchrone, les buckets peuvent ne pas contenir les mêmes versions d'objet à un moment donné, mais finiront par devenir cohérents si aucune autre modification n'est apportée. Contrairement à la réplication de volumes, les buckets répliqués sont accessibles en écriture pendant les partitions de zone. Chaque écriture dans un objet produit une version différente. La dernière version dans l'une ou l'autre des zones sera l'état final une fois la connectivité rétablie.
Latence requise
Pour vous assurer de pouvoir planifier les emplacements des zones GDC pour les fonctionnalités actuelles et futures, nous basons les exigences de latence sur Google Cloud. Cette approche vous permet de choisir en toute confiance des emplacements GDC isolés, en sachant si ces zones se trouveront dans la même région.
La latence maximale acceptée est inférieure à 1 ms de délai aller-retour (DAR) au niveau de la couche physique entre deux zones d'une région. Étant donné que le calcul de la latence au niveau de la couche physique nécessite un équipement spécialisé qui n'est pas disponible dans la plupart des instances, il peut être approximé en mesurant la longueur de la fibre entre deux zones.
Une longueur de fibre de 50 km pour les zones d'une région sur le chemin principal et de 100 km sur le chemin secondaire (latence) permettra de prendre en charge les services régionaux. Dans un réseau en anneau, cette exigence signifie que chaque longueur de fibre ne peut pas dépasser 50 km.
Contactez votre opérateur pour en savoir plus sur vos exigences spécifiques en termes de latence.
Étapes suivantes
- Découvrez les serveurs d'API mondiaux et zonaux disponibles dans un univers GDC.
- Consultez le guide sur la haute disponibilité pour vous assurer que votre application est résiliente aux défaillances de zone locale.
- Consultez la page sur la hiérarchie des ressources pour en savoir plus sur la gestion hiérarchique des ressources dans une zone.