Planifica la recuperación ante desastres

En esta página, se proporciona información que puedes usar para planificar la recuperación ante desastres de tus cargas de trabajo que se ejecutan en el entorno de la solución Bare Metal.

La solución Bare Metal se entrega desde una extensión regional. A partir de febrero de 2024, todas las regiones de la solución Bare Metal se alojan físicamente en instalaciones que no son de Google. Debido al modelo de extensión regional, la solución Bare Metal no sigue el modelo de separación zonal convencional que usan otros Google Cloud servicios, como Compute Engine. Cada implementación de la solución Bare Metal dentro de una extensión regional se conoce como pod. En algunas regiones, los recursos de la solución Bare Metal se entregan desde varios pods, pero no hay ningún requisito ni expectativa de que los pods estén separados geográficamente.

Si ejecutas cargas de trabajo fundamentales, te recomendamos que planifiques la recuperación ante desastres.

Recursos recomendados para la planificación de la recuperación ante desastres

Te recomendamos que consultes los siguientes recursos para planificar la recuperación ante desastres:

Conectividad entre pods

Los pods y las extensiones regionales no tienen conectividad directa. Todo el tráfico (de entrada y salida) de tu implementación de la solución Bare Metal transita a través de una interconexión y de la Google Cloud red troncal. No hay una ruta de datos compatible para la replicación a nivel de almacenamiento. Esto elimina las opciones de recuperación ante desastres basadas en las tecnologías de almacenamiento, como la replicación de almacenamiento a nivel de bloque o la replicación de instantáneas remotas.

Planificación de la región de recuperación ante desastres

Cuando selecciones regiones para la planificación de la recuperación ante desastres, ten en cuenta los siguientes puntos:

  • Por lo general, puedes seleccionar una región de la solución Bare Metal en función de otros Google Cloud servicios que usas. Sin embargo, la recuperación ante desastres para las bases de datos suele coincidir con las regiones que se usan para las aplicaciones correspondientes y sus integraciones. Por lo tanto, considera la latencia de la red entre regiones cuando planifiques qué regiones quieres usar para la recuperación ante desastres.

  • Según tu industria, puede haber requisitos reglamentarios sobre la ubicación de los datos que dicten dónde puedes replicar los datos. Cada aplicación tiene sus propios requisitos, por lo que la selección específica de la región de recuperación ante desastres depende de ti.

  • La solución Bare Metal opera ciertos componentes del plano de control para un grupo de regiones, que en conjunto se denominan GeoSector. Una falla de estos componentes puede afectar las operaciones del plano de control, como la creación de bases de datos, las operaciones de inicio y detención, o el escalamiento del almacenamiento en una o más regiones dentro del GeoSector. Según tus requisitos comerciales, cuando realices implementaciones en varias regiones, te recomendamos que selecciones regiones que estén en GeoSectors separados para mejorar la confiabilidad.

    Para garantizar la resiliencia de tu solución Bare Metal, te recomendamos que sigas estos pasos:

    1. Asigna tus entornos de recuperación ante desastres primario y secundario a los GeoSectors que se mencionan en la siguiente tabla:

      GeoSector Google Cloud región
      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. Configura tu configuración de recuperación ante desastres en GeoSectors separados. Si no tienes una configuración de recuperación ante desastres o si tus entornos primario y secundario se implementan dentro del mismo GeoSector, haz la transición de tu entorno secundario a un GeoSector diferente para mejorar la resiliencia.

Consideraciones de red

Aislamiento del tráfico para la interconexión

En muchos casos, es posible que desees aislar el tráfico de replicación de las sesiones de la aplicación.

El aislamiento del tráfico se puede lograr aprovisionando interconexiones de socio separadas en cada región que finalicen en una VPC de tránsito que se use para la replicación. En el siguiente diagrama, se muestra este tipo de configuración.

Aislamiento del tráfico con interconexiones independientes

En el diagrama, los servidores de la solución Bare Metal en la región us-west2 usan la red 10.10.10.0/24, y los servidores de la solución Bare Metal en la región us-east4 usan la red 10.20.20.0/24. El proyecto de usuario contiene VPC separadas para el tráfico de aplicaciones y replicación, denominadas Application VPC y Replication VPC, respectivamente. Los anuncios de BGP están configurados de modo que cada Cloud Router en la Replication VPC anuncie una ruta a la red de la solución Bare Metal entre regiones, lo que obliga a que el tráfico entre regiones fluya a través de la Replication VPC. Los Cloud Routers en la Application VPC anuncian una ruta 0.0.0.0/0 genérica o rutas a bloques CIDR específicos con los que deben comunicarse los servidores de la solución Bare Metal. En este ejemplo, se usa 0.0.0.0/0 para indicar una ruta que envía tráfico a cualquier otro destino.

Los servidores de aplicaciones y otros servicios que se conectan desde centros de datos locales se conectan a través de la Application VPC. Las instancias dentro de la Application VPC aún pueden comunicarse con las bases de datos que se ejecutan en cualquier extensión regional de la solución Bare Metal.

Las interconexiones que finalizan en la VPC de tránsito también se pueden usar para acceder a Google Cloud servicios, como Cloud Storage, Filestore, o Backup and DR. Esto se puede lograr creando la instancia de Filestore en la VPC de tránsito o mediante el uso de extremos de Private Service Connect que residen dentro de la VPC de tránsito.