Planifier la reprise après sinistre

Cette page fournit des informations que vous pouvez utiliser pour planifier la reprise après sinistre pour vos charges de travail exécutées dans l'environnement de la solution Bare Metal.

La solution Bare Metal est fournie à partir d'une extension régionale. Depuis février 2024, toutes les régions de la solution Bare Metal sont hébergées physiquement dans des installations non Google. En raison du modèle d'extension de région, la solution Bare Metal ne suit pas le modèle de séparation zonale conventionnel utilisé par d'autres services Google Cloud , tels que Compute Engine. Chaque déploiement de solution Bare Metal dans une extension de région est appelé "pod". Dans certaines régions, les ressources solution Bare Metal sont fournies à partir de plusieurs pods, mais il n'est pas nécessaire ni prévu que les pods soient géographiquement séparés.

Si vous exécutez des charges de travail critiques, nous vous recommandons de planifier la reprise après sinistre.

Ressources recommandées pour la planification de la reprise après sinistre

Nous vous recommandons de consulter les ressources suivantes pour planifier la reprise après sinistre :

Connectivité entre les pods

Les pods et les extensions régionales ne sont pas directement connectés. Tout le trafic (entrant et sortant) de votre déploiement de solution Bare Metal transite par une interconnexion et par le backbone Google Cloud . Aucun chemin de données n'est compatible avec la réplication au niveau du stockage. Cela élimine les options de reprise après sinistre basées sur les technologies de stockage, telles que la réplication du stockage au niveau des blocs ou la réplication d'instantanés à distance.

Planification de la région de reprise après sinistre

Lorsque vous sélectionnez des régions pour la planification de la reprise après sinistre, tenez compte des points suivants :

  • Vous pouvez généralement sélectionner une région de solution Bare Metal en fonction des autres servicesGoogle Cloud que vous utilisez. Toutefois, la reprise après sinistre pour les bases de données correspond généralement aux régions utilisées pour les applications correspondantes et leurs intégrations. Par conséquent, tenez compte de la latence du réseau entre les régions lorsque vous planifiez les régions que vous souhaitez utiliser pour la reprise après sinistre.

  • Selon votre secteur d'activité, il peut exister des exigences réglementaires concernant la localisation des données qui déterminent où vous pouvez les répliquer. Chaque application a ses propres exigences. Vous devez donc sélectionner vous-même une région de reprise après sinistre spécifique.

  • La solution Bare Metal exploite certains composants du plan de contrôle pour un groupe de régions, appelé collectivement "GeoSector". Une défaillance de ces composants peut avoir un impact sur les opérations du plan de contrôle, telles que la création, le démarrage et l'arrêt de bases de données, ou le scaling du stockage dans une ou plusieurs régions du géosecteur. Selon les besoins de votre entreprise, lorsque vous déployez dans plusieurs régions, nous vous recommandons de sélectionner des régions qui se trouvent dans des GeoSectors distincts pour améliorer la fiabilité.

    Pour garantir la résilience de votre solution Bare Metal, nous vous recommandons de procéder comme suit :

    1. Faites correspondre vos environnements de reprise après sinistre principal et secondaire aux secteurs géographiques mentionnés dans le tableau suivant :

      GeoSector Google Cloud  région
      ap1 asia-northeast1
      asia-northeast3
      ap2 asia-southeast1
      eu1 europe-west2
      europe-west3
      eu2 europe-west4
      us1 northamerica-northeast1
      northamerica-northeast2
      southamerica-east1
      us-central1
      us-west2
      us2 us-central2
      us-east4

    2. Configurez votre reprise après sinistre dans différents géosecteurs. Si vous n'avez pas configuré de reprise après sinistre ou si vos environnements principal et secondaire sont déployés dans le même GeoSector, migrez votre environnement secondaire vers un autre GeoSector pour améliorer la résilience.

Remarques sur la mise en réseau

Isoler le trafic pour l'interconnexion

Dans de nombreux cas, vous pouvez isoler le trafic de réplication des sessions d'application.

L'isolation du trafic peut être obtenue en provisionnant des Partner Interconnect distincts dans chaque région, qui se terminent dans un VPC de transit utilisé pour la réplication. Le schéma suivant illustre ce type de configuration.

Isolation du trafic à l'aide d'interconnexions distinctes.

Dans le schéma, les serveurs de la solution Bare Metal de la région us-west2 utilisent le réseau 10.10.10.0/24, et ceux de la région us-east4 utilisent le réseau 10.20.20.0/24. Le projet utilisateur contient des VPC distincts pour le trafic d'application et de réplication, nommés respectivement Application VPC et Replication VPC. Les annonces BGP sont configurées de sorte que chaque Cloud Router dans Replication VPC annonce une route vers le réseau multirégional de la solution Bare Metal, ce qui force le trafic multirégional à transiter par Replication VPC. Les routeurs Cloud Router dans Application VPC annoncent une route 0.0.0.0/0 générique ou des routes vers des blocs CIDR spécifiques avec lesquels les serveurs solution Bare Metal doivent communiquer. Dans cet exemple, 0.0.0.0/0 est utilisé pour indiquer une route qui envoie le trafic vers n'importe quelle autre destination.

Les serveurs d'applications et les autres services qui se connectent depuis des centres de données sur site se connectent via Application VPC. Les instances du Application VPC peuvent toujours communiquer avec les bases de données exécutées dans l'une ou l'autre des extensions de région solution Bare Metal.

Les interconnexions qui se terminent au niveau du VPC de transit peuvent également être utilisées pour accéder aux servicesGoogle Cloud , tels que Cloud Storage, Filestore ou Backup and DR. Pour ce faire, vous pouvez créer l'instance Filestore dans le VPC de transit ou utiliser des points de terminaison Private Service Connect qui résident dans le VPC de transit.