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 de région. 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 reprise après sinistre pour Google Cloud (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 (applicables si vous exécutez des charges de travail de bases de données Oracle)
Connectivité entre pods
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 d'accès aux données n'est pris en charge pour 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 services Google 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 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 d'activité, il peut exister des exigences réglementaires concernant les données ou la localité qui déterminent où vous pouvez répliquer des 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ées Application VPC
et
Replication VPC
, respectivement. Les annonces BGP sont configurées de sorte que chaque routeur Cloud 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 signifier une route qui envoie du trafic vers une autre
vers votre 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 incluses dans le paramètre
Application VPC
peut toujours communiquer avec les bases de données s'exécutant dans
Extension de région de la solution Bare Metal.
Les interconnexions qui se terminent au niveau du VPC de transit permettent également aux services Google Cloud, tels que Cloud Storage, Filestore, ou la sauvegarde et reprise après sinistre. Pour ce faire, vous pouvez créer Cloud Filestore dans le VPC de transit ou via l'utilisation Private Service Connect les points de terminaison du réseau VPC de transit.