Diseñar la recuperación tras desastres para cargas de trabajo con restricciones de localidad

Last reviewed 2024-07-20 UTC

En este documento se explica cómo puede usar Google Cloud para diseñar una arquitectura de recuperación tras desastres (DR) que cumpla los requisitos específicos de cada ubicación. En algunos sectores regulados, las cargas de trabajo deben cumplir estos requisitos. En este caso, se aplican uno o varios de los siguientes requisitos:

  • Los datos en reposo deben estar restringidos a una ubicación específica.
  • Los datos deben tratarse en la ubicación en la que residen.
  • Solo se puede acceder a las cargas de trabajo desde ubicaciones predefinidas.
  • Los datos deben cifrarse con claves que gestione el cliente.
  • Si utilizas servicios en la nube, cada uno de ellos debe proporcionar un mínimo de dos ubicaciones redundantes entre sí. Para ver un ejemplo de los requisitos de redundancia de ubicación, consulta el Catálogo de criterios de cumplimiento en materia de cloud computing (C5).

La serie consta de las siguientes partes:

Terminología

Antes de empezar a diseñar la recuperación ante desastres para cargas de trabajo con restricciones de localidad, es recomendable que consultes la terminología de localidad que se usa en Google Cloud.

Google Cloud ofrece servicios en regiones de América, Europa, Oriente Medio y Asia-Pacífico. Por ejemplo, Londres (europe-west2) es una región de Europa y Oregón (us-west1) es una región de Norteamérica. Algunos Google Cloud productos agrupan varias regiones en una ubicación multirregión específica a la que se puede acceder de la misma forma que a una región.

Las regiones se dividen en zonas en las que se despliegan determinados Google Cloud recursos, como máquinas virtuales, clústeres de Kubernetes o bases de datos de Cloud SQL. Los recursos de Google Cloud pueden ser multirregionales, regionales o de zona. Algunos recursos y productos que se designan de forma predeterminada como multirregionales también se pueden restringir a una región. Los distintos tipos de recursos se explican a continuación:

  • Los recursos multirregionales se han diseñado para ser redundantes y estar distribuidos en una misma región y en distintas regiones. Google Cloud Los recursos multirregionales son resistentes a los fallos de una sola región.

  • Los recursos regionales se despliegan de forma redundante en varias zonas de una región y son resistentes a los fallos de una zona de la región.

  • Los recursos de zona operan en una única zona. Si una zona deja de estar disponible, todos los recursos zonales de esa zona también dejarán de estarlo hasta que se restaure el servicio. Considera una zona como un dominio de fallo único. Debes diseñar tus aplicaciones para mitigar los efectos de que una sola zona deje de estar disponible.

Para obtener más información, consulta el artículo sobre geografía y regiones.

Planificar la recuperación ante desastres de cargas de trabajo con restricciones de localidad

El enfoque que adoptes para diseñar tu aplicación depende del tipo de carga de trabajo y de los requisitos de localidad que debas cumplir. También debes tener en cuenta por qué debes cumplir esos requisitos, ya que lo que decidas influirá directamente en tu arquitectura de recuperación ante desastres.

Empieza leyendo la Google Cloud guía de planificación para la recuperación tras fallos. Cuando pienses en las cargas de trabajo restringidas por la localidad, céntrate en los requisitos que se describen en esta sección de planificación.

Definir los requisitos de localidad

Antes de empezar a diseñar, define los requisitos de tu localidad respondiendo a estas preguntas:

  • ¿Dónde se almacenan los datos en reposo? La respuesta determina qué servicios puedes usar y qué métodos de alta disponibilidad (HA) y recuperación tras fallos (DR) puedes emplear para alcanzar tus valores de RTO y RPO. Consulte la página Ubicaciones de Cloud para determinar qué productos están incluidos.
  • ¿Puedes usar técnicas de cifrado para mitigar este requisito? Si puedes mitigar los requisitos de localidad empleando técnicas de encriptado con Cloud External Key Manager y Cloud Key Management Service, puedes usar servicios multirregionales y birregionales, así como seguir las técnicas estándar de alta disponibilidad y recuperación tras desastres que se describen en Escenarios de recuperación tras desastres para datos.

  • ¿Se pueden tratar los datos fuera de donde se almacenan? Puede usar productos como GKE Enterprise para proporcionar un entorno híbrido que satisfaga sus necesidades o implementar controles específicos de productos, como el balanceo de carga de instancias de Compute Engine en varias zonas de una región. Usa la restricción Ubicación de recursos de la política de organización para restringir dónde se pueden implementar los recursos .

    Si los datos se pueden procesar fuera de donde deben estar en reposo, puedes diseñar las partes de "procesamiento" de tu aplicación siguiendo las directrices de Componentes básicos de recuperación ante desastres y Escenarios de recuperación ante desastres para aplicaciones.

    Configura un perímetro de Controles de Seguridad de VPC para controlar quién puede acceder a los datos y restringir qué recursos pueden tratarlos.

  • ¿Se puede usar más de una región? Si puedes usar más de una región, puedes usar muchas de las técnicas descritas en la serie sobre recuperación ante desastres. Consulta las restricciones de multirregión y de región para los Google Cloud productos.

  • ¿Necesitas restringir el acceso a tu aplicación? Google Cloud ofrece varios productos y funciones que te ayudan a restringir el acceso a tus aplicaciones:

    • Identity-Aware Proxy (IAP). Verifica la identidad de un usuario y, a continuación, determina si se le debe permitir acceder a una aplicación. Las políticas de organización usan la restricción de compartir con dominio restringido para definir los IDs de Cloud Identity o Google Workspace permitidos en las políticas de IAM.
    • Controles de localidad específicos de productos. Consulta las restricciones de localidad adecuadas para cada producto que quieras usar en tu arquitectura. Por ejemplo, si usas Cloud Storage, crea segmentos en regiones específicas.

Identificar los servicios que puedes usar

Identifica qué servicios se pueden usar en función de tus requisitos de granularidad local y regional. Para diseñar aplicaciones que estén sujetas a restricciones de localidad, es necesario saber qué productos se pueden restringir a qué región y qué controles se pueden aplicar para cumplir los requisitos de restricción de ubicación.

Identifica la granularidad regional de tu aplicación y tus datos

Identifica la granularidad regional de tu aplicación y tus datos respondiendo a estas preguntas:

  • ¿Puedes usar servicios multirregionales en tu diseño? Si usas servicios multirregionales, puedes crear arquitecturas resilientes de alta disponibilidad.
  • ¿El acceso a tu aplicación tiene restricciones de ubicación? Usa estos productos de Google Cloud para controlar desde dónde se puede acceder a tus aplicaciones:
  • ¿Tus datos en reposo están restringidos a una región específica? Si utilizas servicios gestionados, asegúrate de que los servicios que uses se puedan configurar de forma que tus datos almacenados en el servicio se limiten a una región específica. Por ejemplo, usa las restricciones de localidad de BigQuery para indicar dónde se almacenan y se crean copias de seguridad de tus conjuntos de datos.
  • ¿En qué regiones necesitas restringir tu aplicación? Algunos productosGoogle Cloud no tienen restricciones regionales. Consulta la página Ubicaciones de Cloud y las páginas específicas de cada producto para comprobar en qué regiones puedes usar el producto y qué funciones de mitigación hay disponibles para restringir tu aplicación a una región concreta.

Cumplir las restricciones de localidad con los productos de Google Cloud

En esta sección se detallan las funciones y las técnicas de mitigación para usar productos como parte de tu estrategia de recuperación tras desastres para cargas de trabajo con restricciones de localidad.Google Cloud Te recomendamos que leas esta sección junto con la de Componentes básicos de recuperación tras fallos.

Políticas de organización

El servicio de política de organización te permite controlar tus Google Cloud recursos de forma centralizada. Con las políticas de organización, puedes configurar restricciones en toda tu jerarquía de recursos. Ten en cuenta las siguientes restricciones de la política al diseñar cargas de trabajo restringidas por la localidad:

  • Uso compartido restringido por dominio: De forma predeterminada, se permite añadir todas las identidades de usuario a las políticas de gestión de identidades y accesos. La lista de elementos permitidos o denegados debe especificar una o varias identidades de cliente de Cloud Identity o Google Workspace. Si esta restricción está activa, solo las identidades de la lista permitida podrán añadirse a las políticas de gestión de identidades y accesos.

  • Recursos con restricciones de ubicación: esta restricción hace referencia al conjunto de ubicaciones en las que se pueden crear recursos deGoogle Cloud basados en la ubicación. Las políticas de esta restricción pueden especificar como ubicaciones permitidas o denegadas cualquiera de las siguientes: multirregiones, como Asia y Europa; regiones, como us-east1 o europe-west1; o zonas concretas, como europe-west1-b. Para ver una lista de los servicios admitidos, consulta Servicios compatibles de ubicaciones de recursos.

Cifrado

Si tus requisitos de localización de datos se refieren a restringir quién puede acceder a los datos, puede que te convenga implementar métodos de cifrado. Si utilizas sistemas de gestión de claves externos para gestionar las claves que proporcionas fuera deGoogle Cloud, puedes desplegar una arquitectura multirregión para cumplir tus requisitos de localidad. Si no se dispone de las claves, los datos no se pueden descifrar.

Google Cloud tiene dos productos que te permiten usar las claves que gestionas:

  • Cloud External Key Manager (Cloud EKM): Cloud EKM te permite cifrar los datos de BigQuery y de Compute Engine con claves de cifrado que se almacenan y se gestionan en sistemas externos de gestión de claves que están desplegados fuera de la infraestructura de Google.

  • Claves de cifrado proporcionadas por el cliente (CSEK): puedes usar CSEK con Cloud Storage y Compute Engine. Google usa tu clave para proteger las claves generadas por Google que se usan para encriptar y desencriptar tus datos.

    Si proporcionas una clave de cifrado suministrada por el cliente, Google no almacenará tu clave de forma permanente en sus servidores ni la gestionará de ninguna otra forma. En su lugar, proporcionas tu clave para cada operación y se elimina de los servidores de Google una vez que se completa la operación.

Cuando gestionas tu propia infraestructura de claves, debes tener en cuenta los problemas de latencia y fiabilidad, así como asegurarte de implementar procesos de alta disponibilidad y recuperación adecuados para tu administrador de claves externas. También debes conocer tus requisitos de RTO. Las claves son fundamentales para escribir los datos, por lo que el RPO no es un problema crítico, ya que no se pueden escribir datos de forma segura sin las claves. El problema real es el tiempo de recuperación, ya que, sin tus claves, no puedes descifrar ni escribir datos de forma segura.

Almacenamiento

Al diseñar la recuperación ante desastres para cargas de trabajo con restricciones de localidad, debes asegurarte de que los datos en reposo se encuentren en la región que necesites. Puedes configurar Google Cloud servicios de almacenamiento de objetos y archivos para satisfacer tus necesidades

Cloud Storage

Puedes crear segmentos de Cloud Storage que cumplan las restricciones de localidad.

Además de las funciones que se describen en la sección de Cloud Storage del artículo sobre los componentes básicos de la recuperación ante desastres, cuando diseñes la recuperación ante desastres para cargas de trabajo con restricciones de localidad, plantéate si necesitas redundancia entre regiones. Los objetos almacenados en ubicaciones multirregionales y de dos regiones se almacenan en al menos dos zonas geográficas distintas, independientemente de su clase de almacenamiento. Esta redundancia garantiza la máxima disponibilidad de tus datos, incluso durante interrupciones a gran escala, como desastres naturales. Las regiones duales consiguen esta redundancia mediante un par de regiones que elijas. Las multirregiones consiguen esta redundancia usando cualquier combinación de centros de datos de la multirregión especificada, que pueden incluir centros de datos que no se indiquen explícitamente como regiones disponibles.

La sincronización de datos entre los contenedores se produce de forma asíncrona. Si necesitas un alto grado de confianza en que los datos se han escrito en una región alternativa para cumplir los valores de RTO y RPO, una estrategia consiste en usar dos cubos de una sola región. Después, puedes escribir el objeto en ambos segmentos o escribirlo en uno y hacer que Cloud Storage lo copie en el segundo.

Estrategias de mitigación de una sola región al usar Cloud Storage

Si tus requisitos te obligan a usar una sola región, no puedes implementar una arquitectura redundante en diferentes ubicaciones geográficas solo con Google Cloud . En este caso, te recomendamos que utilices una o varias de las siguientes técnicas:

  • Adopta una estrategia multinube o híbrida. Con este enfoque, puedes elegir otra solución en la nube o local en la misma zona geográfica que tu región deGoogle Cloud . Puedes almacenar copias de tus datos en segmentos de Cloud Storage locales o, como alternativa, usar Cloud Storage como destino de tus datos de copia de seguridad.

    Para usar este método, sigue estos pasos:

    • Asegúrate de que se cumplen los requisitos de distancia.
    • Si usas AWS como otro proveedor de servicios en la nube, consulta la guía de interoperabilidad de Cloud Storage para saber cómo configurar el acceso a Amazon S3 con herramientas de Google Cloud .
    • En el caso de otras nubes y soluciones locales, puedes usar soluciones de código abierto como minIO y Ceph para proporcionar un almacén de objetos local.
    • Puedes usar Cloud Composer con la utilidad de línea de comandos gcloud storage para transferir datos de un almacén de objetos local a Cloud Storage.
    • Usa el servicio de transferencia de datos on-premise para copiar datos almacenados on-premise en Cloud Storage.

  • Implementa técnicas de cifrado. Si tus requisitos de localidad lo permiten, puedes usar técnicas de cifrado como solución alternativa y, a continuación, usar segmentos multirregionales o birregionales.

Filestore

Filestore proporciona almacenamiento de archivos gestionado que puedes implementar en regiones y zonas según tus requisitos de restricción de localidad.

Bases de datos gestionadas

En Situaciones de recuperación tras fallos con los datos se describen métodos para implementar estrategias de copia de seguridad y recuperación paraGoogle Cloud servicios de bases de datos gestionados. Además de usar estos métodos, también debes tener en cuenta las restricciones de localidad de cada servicio de base de datos gestionado que utilices en tu arquitectura. Por ejemplo:

  • Bigtable está disponible en ubicaciones zonales de una región. Las instancias de producción tienen un mínimo de dos clústeres, que deben estar en zonas únicas de la región. Google gestiona automáticamente la replicación entre los clústeres de una instancia de Bigtable. Bigtable sincroniza los datos entre los clústeres, creando una copia independiente de los datos en cada zona en la que la instancia tenga un clúster. La replicación permite que el tráfico entrante conmute por error a otro clúster de la misma instancia.

  • BigQuery tiene restricciones de localidad que determinan dónde se almacenan tus conjuntos de datos. Las ubicaciones de los conjuntos de datos pueden ser regionales o multirregionales. Para ofrecer resiliencia durante un desastre regional, debes crear copias de seguridad de los datos en otra ubicación geográfica. En el caso de las multirregiones de BigQuery, te recomendamos que no crees copias de seguridad en regiones que estén dentro del ámbito de la multirregión. Si seleccionas la multirregión de la UE, Zúrich y Londres no formarán parte de la configuración multirregional. Para obtener información sobre cómo implementar una solución de recuperación tras fallos para BigQuery que aborde el improbable caso de que se produzca una pérdida física regional, consulta Pérdida de una región.

    Para entender las implicaciones de adoptar configuraciones de BigQuery de una o varias regiones, consulte la documentación de BigQuery.

  • Puedes usar Firestore para almacenar tus datos de Firestore en una ubicación multirregional o en una ubicación regional. Los datos de una ubicación multirregional se almacenan en una configuración replicada multizona y multirregional. Selecciona una ubicación multirregional si tus requisitos de restricción de localidad lo permiten y quieres maximizar la disponibilidad y la durabilidad de tu base de datos. Las ubicaciones multirregionales pueden resistir la pérdida de regiones enteras y mantener la disponibilidad sin que se pierdan datos. Los datos de una ubicación regional se almacenan en una configuración replicada multizona.

  • Puedes configurar Cloud SQL para alta disponibilidad. Una instancia de Cloud SQL configurada para ofrecer alta disponibilidad también se denomina "instancia regional" y se encuentra en una zona principal y otra secundaria de la región configurada. En una instancia regional, la configuración se compone de una instancia principal y una de reserva. Asegúrate de que conoces el tiempo de conmutación por error habitual de la instancia principal a la de espera.

    Si tus requisitos lo permiten, puedes configurar Cloud SQL con réplicas entre regiones. Si se produce un desastre, se puede promocionar la réplica de lectura en otra región. Como las réplicas de lectura se pueden configurar para la alta disponibilidad con antelación, no necesitan someterse a cambios adicionales después de la promoción para la alta disponibilidad. También puedes configurar réplicas de lectura para que tengan sus propias réplicas entre regiones, que pueden ofrecer protección inmediata frente a fallos regionales después de la promoción de la réplica.

  • Puedes configurar Spanner como regional o multirregional. En cualquier configuración regional, Spanner mantiene tres réplicas de lectura y escritura, cada una en una Google Cloud zona diferente de esa región. Cada réplica de lectura y escritura contiene una copia completa de tu base de datos operativa que puede atender solicitudes de lectura y escritura, así como de solo lectura.

    Spanner usa réplicas en diferentes zonas para que, si se produce un fallo en una zona, tu base de datos siga estando disponible. Una implementación multirregional de Spanner proporciona un entorno coherente en varias regiones, incluidas dos regiones de lectura y escritura y una región testigo que contiene una réplica testigo. Debe validar que las ubicaciones de todas las regiones cumplen sus requisitos de restricción de localidad.

Compute Engine

Los recursos de Compute Engine son globales, regionales o de zona. Los recursos de Compute Engine, como las instancias de máquina virtual o los discos persistentes de zona, se denominan recursos de zona. Otros recursos, como las direcciones IP externas estáticas, son regionales. Los recursos regionales pueden usarse con cualquier recurso de esa región, independientemente de la zona, mientras que los recursos zonales solo pueden usarse con otros recursos de la misma zona.

Si colocas los recursos en diferentes zonas de una región, los aislarás de la mayoría de los tipos de fallos de infraestructura física y de software de infraestructura. Además, si colocas los recursos en diferentes regiones, se consigue un grado de independencia ante fallos aún mayor. Este enfoque te permite diseñar sistemas sólidos con recursos distribuidos en diferentes dominios de errores.

Para obtener más información, consulta Regiones y zonas.

Usar un entorno on-premise u otra nube como sitio de producción

Es posible que estés usando una Google Cloud región que te impida usar combinaciones de dos o varias regiones en tu arquitectura de recuperación ante desastres. Para cumplir las restricciones de localidad en este caso, te recomendamos que utilices tu propio centro de datos u otra nube como sitio de producción o de conmutación por error.

En esta sección se describen los productos optimizados para cargas de trabajo híbridas. Google Cloud Las arquitecturas de recuperación tras fallos que usan entornos on-premise y Google Cloud se describen en el artículo sobre situaciones de recuperación tras fallos con las aplicaciones.

GKE Enterprise

GKE Enterprise es la plataforma de aplicaciones híbrida y multinube de código abierto de Google Cloudque te ayuda a ejecutar de forma segura tus cargas de trabajo basadas en contenedores en cualquier lugar. GKE Enterprise permite mantener la coherencia entre los entornos locales y en la nube, lo que te ofrece un modelo operativo coherente y una vista única de tus clústeres de Google Kubernetes Engine (GKE), independientemente de dónde los ejecutes.

Como parte de tu estrategia de recuperación ante desastres, GKE Enterprise simplifica la configuración y el funcionamiento de las arquitecturas de alta disponibilidad y conmutación por error en entornos diferentes (entre Google Cloud y on-premise u otra nube). Puedes ejecutar tus clústeres de GKE Enterprise de producción de forma local y, si se produce un desastre, puedes conmutar por error para ejecutar las mismas cargas de trabajo en clústeres de GKE Enterprise enGoogle Cloud.

GKE Enterprise en Google Cloud tiene tres tipos de clústeres:

  • Clúster de zona única. Un clúster de zona única tiene un único plano de control que se ejecuta en una zona. Este plano de control gestiona las cargas de trabajo en los nodos que se ejecutan en la misma zona.
  • Clúster multizona. Un clúster multizona tiene una sola réplica del plano de control que se ejecuta en una sola zona y nodos que se ejecutan en varias zonas.
  • Clúster regional. Los clústeres regionales replican los elementos principales y los nodos de un clúster en varias zonas de una misma región. Por ejemplo, un clúster regional de la región us-east1 crea réplicas del plano de control y de los nodos en tres zonas de us-east1: us-east1-b, us-east1-c y us-east1-d.

Los clústeres regionales son los más resistentes a las interrupciones de las zonas.

Google Cloud VMware Engine

VMware Engine de Google Cloud te permite ejecutar cargas de trabajo de VMware en la nube. Si tus cargas de trabajo on-premise se basan en VMware, puedes diseñar tu solución de recuperación ante desastres para que se ejecute en la misma solución de virtualización que usas on-premise. Puedes seleccionar la región que cumpla tus requisitos de localidad.

Redes

Si tu plan de recuperación ante desastres se basa en mover datos de un entorno local aGoogle Cloud o de otro proveedor de servicios en la nube a Google Cloud, debes definir tu estrategia de redes. Para obtener más información, consulta la sección Transferencia de datos Google Cloud del documento "Componentes básicos de la recuperación ante desastres".

Controles de Servicio de VPC

Al planificar tu estrategia de recuperación tras desastres, debes asegurarte de que los controles de seguridad que se aplican a tu entorno de producción también se extiendan a tu entorno de conmutación por error. Con Controles de Servicio de VPC, puedes definir un perímetro de seguridad desde las redes locales hasta tus proyectos en Google Cloud.

Controles de Servicio de VPC ofrece un método de acceso contextual para controlar los recursos en la nube. Puedes crear políticas de control de acceso pormenorizadas en Google Cloud en función de atributos como la identidad del usuario y la dirección IP. Estas políticas ayudan a garantizar que se apliquen los controles de seguridad adecuados en tus entornos on-premise y Google Cloud .

Siguientes pasos