Planifier la reprise après sinistre
Cette page fournit des informations que vous pouvez utiliser pour planifier la reprise après sinistre de 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 autres que 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 régionale est appelé "pod". Dans certaines régions, les ressources de la solution Bare Metal sont servies à partir de plusieurs pods, mais il n'est pas obligatoire ni attendu 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:
- Planifier la reprise après sinistre (ce document)
- Guide de planification de la reprise après sinistre pour (fournit des conseils supplémentaires que vous pouvez utiliser pour mettre en œuvre votre plan de reprise après sinistre)
- Options de reprise après sinistre pour les charges de travail de bases de données Oracle (applicable si vous exécutez des charges de travail de bases de données Oracle)
Connectivité entre les nœuds
Les pods et les extensions de région ne sont pas directement connectés. Tout le trafic (entrant et sortant) de votre déploiement de solution Bare Metal transite via une interconnexion et via le backbone Google Cloud . Aucun chemin de données n'est accepté pour 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 de stockage au niveau des blocs ou la réplication d'instantanés à distance.
Planification de la région de reprise après sinistre
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 des 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 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, des exigences réglementaires concernant la localité des données peuvent dicter l'emplacement où vous pouvez répliquer les données. Chaque application a ses propres exigences. La sélection de la région de reprise après sinistre vous revient donc.
Remarques sur la mise en réseau
Isoler le trafic pour l'interconnexion
Dans de nombreux cas, vous pouvez souhaiter isoler le trafic de réplication des sessions d'application.
Vous pouvez isoler le trafic en provisionnant des interconnexions partenaires distinctes 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.
Dans le diagramme, les serveurs de la solution Bare Metal dans la région us-west2
utilisent le réseau 10.10.10.0/24
, et les serveurs de la solution Bare Metal dans 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 Application VPC
et Replication VPC
, respectivement. Les annonces BGP sont configurées de sorte que chaque Cloud Router de l'Replication VPC
annonce une route vers le réseau de solution Bare Metal interrégional, forçant le trafic interrégional à transiter par l'Replication VPC
. Les routeurs Cloud Router de 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 de la solution Bare Metal doivent communiquer. Dans cet exemple, 0.0.0.0/0
est utilisé pour désigner un parcours qui envoie du trafic vers n'importe quelle autre destination.
Les serveurs d'applications et les autres services qui se connectent à partir de centres de données sur site se connectent via le Application VPC
. Les instances de Application VPC
peuvent toujours communiquer avec les bases de données exécutées dans l'une ou l'autre extension de région de la solution Bare Metal.
Les interconnexions qui se terminent au 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, créez l'instance Filestore dans le VPC de transit ou utilisez des points de terminaison Private Service Connect situés dans le VPC de transit.