Arquitectura de recuperación ante desastres para cargas de trabajo con restricciones de localidad

Last reviewed 2022-06-10 UTC

En este documento, se analiza cómo puedes usar Google Cloud para diseñar la recuperación ante desastres (DR) a fin de cumplir con los requisitos específicos de la ubicación. Para algunos sectores regulados, las cargas de trabajo deben cumplir con estos requisitos. En este caso, se aplican uno o más de los siguientes requisitos:

  • Los datos en reposo deben estar restringidos a un país específico.
  • Los datos se deben procesar en el país en el que residen.
  • Solo se puede acceder a las cargas de trabajo desde ubicaciones predefinidas.
  • Los datos deben encriptarse mediante claves que el cliente administra.
  • Si usas servicios en la nube, cada servicio en la nube debe proporcionar un mínimo de dos ubicaciones redundantes entre sí. Para ver un ejemplo de los requisitos de redundancia de ubicación, consulta la página sobre el catálogo de criterios de cumplimiento de computación en la nube (C5).

Este artículo es la quinta parte de una serie en la que se trata la recuperación ante desastres (DR) en Google Cloud. En esta parte, se ofrece una descripción general del proceso de planificación de recuperación ante desastres: lo que necesitas saber para diseñar e implementar un plan de recuperación ante desastres.

La serie consta de estas partes:

Terminología

Antes de comenzar a diseñar la DR para las cargas de trabajo con restricciones de localidad, es una buena idea revisar la terminología de localidad que se usa en Google Cloud.

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

Las regiones se dividen aún más en zonas en las que se implementan determinados recursos de Google Cloud, como máquinas virtuales, clústeres de Kubernetes o bases de datos de Cloud SQL. Los recursos de Google Cloud son multirregionales, regionales o zonales. Algunos recursos y productos que están definidos de forma predeterminada como multirregión, también se pueden restringir a una región. Los diferentes tipos de recursos se explican de la siguiente manera:

  • Google Cloud diseña los recursos multirregión para que sean redundantes y se distribuyan en las regiones y entre ellas. Los recursos multirregionales son resistentes a la falla de una sola región.
  • Los recursos regionales se implementan de forma redundante en varias zonas de una región y son resistentes a la falla de una zona dentro de la región.
  • Los recursos zonales operan en una sola zona. Si una zona deja de estar disponible, pasa lo mismo con todos los recursos zonales hasta que se restablezca el servicio. Considera una zona como un dominio de falla única. Debes diseñar tus aplicaciones para mitigar los efectos de una sola zona que no está disponible.

En la tabla siguiente, se muestra la relación actual entre regiones, zonas y ubicaciones de Europa.

Región Zonas Ubicación
europe-north1 a, b, c Hamina, Finlandia
europe-west1 b, c, d Saint-Ghislain, Bélgica
europe-west2 a, b, c Londres, Inglaterra, Reino Unido
europe-west3 a, b, c Fráncfort, Alemania
europe-west4 a, b, c Puerto de Ems, Países Bajos
europe-west6 a, b, c Zúrich, Suiza

Para obtener más información, consulta Geografía y regiones.

Planifica la DR para cargas de trabajo con restricción de localidad

El enfoque que adoptes para diseñar la aplicación depende del tipo de carga de trabajo y los requisitos de localidad que debes cumplir. También considera la razón por la que debes cumplir esos requisitos, ya que lo que decidas influirá directamente en tu arquitectura de DR.

Comienza por leer la Guía de planificación para la recuperación ante desastres de Google Cloud. Y, si consideras las cargas de trabajo con restricción de localidad, enfócate en los requisitos analizados en esta sección de planificación.

Define los requisitos de localidad

Antes de comenzar tu diseño, responde estas preguntas para definir los requisitos de localidad:

  • ¿Dónde están los datos en reposo? La respuesta determina qué servicios puedes usar y los métodos de alta disponibilidad (HA) y DR que puedes emplear para lograr tus valores de RTO/RPO. Usa la página Ubicaciones de Cloud para determinar qué productos están dentro del alcance.
  • ¿Se pueden usar técnicas de encriptación para mitigar el requisito? Si puedes mitigar los requisitos de localidad mediante el uso de técnicas de encriptación con Cloud External Key Manager y Cloud Key Management Service, puedes usar servicios multirregión y birregionales y seguir las técnicas de HA/DR estándar que se describen en Situaciones de recuperación ante desastres para datos.
  • ¿Se pueden procesar datos fuera del lugar de reposo? Puedes usar productos, como GKE Enterprise, para proporcionar un entorno híbrido a fin de abordar tus requisitos o implementar controles específicos del producto, como las instancias de Compute Engine de balanceo de cargas en varias zonas de una región. Usa la restricción de ubicación de recursos de las políticas de la organización para restringir en qué lugares se pueden implementar.

    Si los datos se pueden procesar fuera del lugar en el que deben estar en reposo, puedes diseñar las partes de “procesamiento” de tu aplicación mediante las instrucciones en las páginas Componentes básicos de la recuperación ante desastres y Situaciones de recuperación ante desastres para aplicaciones.

    Configura un perímetro de Controles de seguridad de VPC a fin de controlar quién puede acceder a los datos y restringir los recursos que pueden procesarlos.

  • ¿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 que se describen en la serie de recuperación ante desastres. Verifica las restricciones multirregión y regionales para los productos de Google Cloud.

  • ¿Necesitas restringir quién puede acceder a tu aplicación? Google Cloud tiene varios productos y funciones que te ayudan a restringir quién puede acceder a tus aplicaciones:

    • Identity-Aware Proxy (IAP) Verifica la identidad del usuario y, luego, determina si se le debe permitir el acceso a una aplicación. La política de la organización usa la restricción de uso compartido restringido al dominio para definir los ID de Cloud Identity o Google Workspace permitidos en las políticas de IAM.
    • Controles de localidad específicos del producto. Consulta cada producto que quieras usar en la arquitectura para restricciones apropiadas de la localidad. Por ejemplo, usa el administrador de configuración de GKE Enterprise para aplicar políticas específicas de localidad a tus clústeres de GKE administrados por GKE Enterprise. Si usas Cloud Storage, crea depósitos en regiones específicas.

Identifica los servicios que puedes usar

Identifica qué servicios se pueden usar en función de los requisitos de nivel de detalle de localidad y regionales. Diseñar aplicaciones sujetas a restricciones de localidad requiere la comprensión de qué productos se pueden restringir a qué región y qué controles se pueden aplicar para la aplicación de los requisitos de restricción de ubicación.

Identifica el nivel de detalle regional para tu aplicación y tus datos

Responde estas preguntas para identificar el nivel de detalle regional de tu aplicación y los datos:

  • ¿Puedes usar servicios multirregión en tu diseño? Mediante el uso de servicios multirregión, puedes crear arquitecturas resilientes con alta disponibilidad.
  • ¿El acceso a tu aplicación tiene restricciones de ubicación? Usa estos productos de Google Cloud para definir desde dónde se puede acceder a tus aplicaciones:
  • ¿Tus datos en reposo están restringidos a una región específica? Si usas servicios administrados, asegúrate de que los servicios que usas se puedan configurar para que tus datos almacenados en el servicio estén restringidos a una región específica. Por ejemplo, usa las restricciones de localidad de BigQuery para determinar la ubicación en la que se almacenan y se crean copias de seguridad de tus conjuntos de datos.
  • ¿En qué regiones necesitas restringir tu aplicación? Algunos productos de Google Cloud no tienen restricciones regionales. Usa la página de ubicaciones de Cloud y las páginas específicas del producto a fin de validar en qué regiones puedes usar el producto y qué características de mitigación hay disponibles, si las hay, para restringir tu aplicación a una región específica.

Cumple con las restricciones de localidad mediante los productos de Google Cloud

En esta sección, se detallan las características y las técnicas de mitigación a fin de usar los productos de Google Cloud como parte de tu estrategia de DR para cargas de trabajo restringidas por la localidad. Te recomendamos leer esta sección junto con los componentes básicos de la recuperación ante desastres.

Políticas de la organización

El Servicio de políticas de la organización te brinda control centralizado sobre tus recursos de Google Cloud. Con las políticas de la organización, puedes configurar restricciones en toda tu jerarquía de recursos. Ten en cuenta las siguientes restricciones de política cuando diseñes para cargas de trabajo con restricción de localidad:

  • Uso compartido restringido al dominio: De forma predeterminada, se permite agregar todas las identidades de usuario a las políticas de IAM. La lista de usuarios admitidos o rechazados debe especificar una o más identidades de cliente de Cloud Identity o Google Workspace. Si esta restricción está activa, solo las identidades de la lista permitida son aptas para agregarse a las políticas de IAM.

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

Encriptación

Si tus requisitos de localidad de datos se relacionan con restringir quién puede acceder a los datos, la implementación de métodos de encriptación podría ser una estrategia aplicable. Si usas sistemas de administración de claves externos para administrar las claves que proporcionas fuera de Google Cloud, puedes implementar una arquitectura multirregión a fin de cumplir con los requisitos de localidad. Sin las claves disponibles, los datos no se pueden desencriptar.

Google Cloud tiene dos productos que te permiten usar claves que administras:

  • Cloud External Key Manager (Cloud EKM): Este producto te permite encriptar datos en BigQuery y Compute Engine con claves de encriptación que se almacenan y administran en un sistema de administración de claves de terceros que se implementa fuera de la infraestructura de Google.
  • Claves de encriptación proporcionadas por el cliente (CSEK): Puedes usar las CSEK con Cloud Storage y Compute Engine. Google usa tu clave a fin de proteger las claves generadas por Google que se usan para encriptar y desencriptar tus datos.

    Si facilitas una clave de encriptación proporcionada por el cliente, Google no almacenará ni administrará tu clave de forma permanente en sus servidores. En cambio, deberás proporcionar tu clave para cada operación y esta se borrará de forma definitiva de los servidores de Google una vez que se complete la operación.

Cuando administres tu propia infraestructura de claves, debes considerar con cuidado los problemas de latencia y confiabilidad, y asegurarte de implementar los procesos de alta disponibilidad y recuperación adecuados para tu administrador de claves externo. También debes comprender los requisitos de RTO. Las claves son parte integral de la escritura de los datos, por lo que el RPO no es la preocupación crítica porque no se pueden escribir datos de manera segura sin las claves. La verdadera preocupación es el RTO, ya que sin tus claves no puedes desencriptar ni escribir datos de forma segura.

Almacenamiento

Cuando diseñas la DR para cargas de trabajo con restricciones de localidad, debes asegurarte de que los datos en reposo se encuentren en la región que necesitas. Puedes configurar los servicios de almacenamiento de archivos y objetos de Google Cloud para cumplir con tus requisitos.

Cloud Storage

Puedes crear depósitos de Cloud Storage que cumplan con las restricciones de localidad.

Más allá de las características analizadas en la sección de Cloud Storage del artículo sobre los componentes básicos de la recuperación ante desastres, cuando diseñas la DR para cargas de trabajo con restricción de localidad, considera si la redundancia entre regiones es un requisito: objetos almacenados en multirregiones y regiones dobles se almacenan en al menos dos áreas separadas a nivel geográfico, sin importar su clase de almacenamiento. Con esta redundancia, se garantiza la disponibilidad máxima de tus datos, incluso durante las interrupciones a gran escala, como los desastres naturales. Las regiones dobles logran esta redundancia mediante el uso de un par de regiones que elijas. Las multirregiones logran esta redundancia mediante cualquier combinación de centros de datos en la multirregión especificada, la que puede incluir centros de datos que no están explícitamente indicados como regiones disponibles.

La sincronización de datos entre los depósitos se realiza de forma asíncrona. Si necesitas un alto grado de confianza de que los datos se escribieron en una región alternativa para cumplir con los valores de RTO y RPO, una estrategia es usar dos depósitos de una sola región. Luego, puedes escribir dos veces el objeto o escribirlo en un bucket y hacer que Cloud Storage copie (rewriteTo) el segundo bucket.

Estrategias de mitigación de una sola región cuando se usa Cloud Storage

Si tus requisitos te restringen al uso de una sola región, por ejemplo, Londres o Zúrich, estarás restringido a esa región y no podrás implementar una arquitectura que sea redundante entre ubicaciones geográficas solo con Google Cloud. En esta situación, considera usar una o más de las siguientes técnicas:

  • Adopta una estrategia de nubes híbridas o de múltiples nubes. Este enfoque te permite elegir otra solución local o en la nube en la misma área geográfica que tu región de Google Cloud. Puedes almacenar copias de tus datos en depósitos de Cloud Storage locales o, de forma alternativa, usar Cloud Storage como destino de tus datos de copia de seguridad.

    Sigue estos pasos para usar este enfoque:

    • Asegúrate de que se cumplan los requisitos de distancia.
    • Si usas AWS como tu otro proveedor de servicios en la nube, consulta la guía de Interoperabilidad de Cloud Storage para configurar el acceso a Amazon S3 mediante las herramientas de Google Cloud.
    • En otras nubes y soluciones locales, considera utilizar soluciones de código abierto, como minIO y Ceph, para proporcionar un depósito de objetos local.
    • Considera usar las soluciones de socios a fin de proporcionar un depósito de objetos local.
    • Considera usar una solución de socios a fin de implementar flujos de trabajo que te permitan escribir datos en Cloud Storage y en el servicio de depósito de objetos alternativo en la nube.
    • Considera usar Cloud Composer con la utilidad de línea de comandos de gsutil para transferir datos de un depósito de objetos local a Cloud Storage.
    • Usa el Servicio de transferencia de datos locales para copiar los datos almacenados de forma local a Cloud Storage.
  • Implementa técnicas de encriptación. Si tus requisitos de localidad permiten usar técnicas de encriptación como una solución alternativa, puedes usar depósitos multirregión o birregionales.

Filestore

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

Bases de datos administradas

Las situaciones de recuperación ante desastres para datos describen métodos a fin de implementar estrategias de copia de seguridad y recuperación de servicios de bases de datos administrados de Google Cloud. Además de usar estos métodos, también debes considerar las restricciones de localidad para cada servicio de base de datos administrado que uses 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 en la región. Google administra automáticamente la replicación entre los clústeres de una instancia de Bigtable. Bigtable sincroniza los datos entre los clústeres y crea una copia independiente de tus datos en cada zona en la que la instancia tiene un clúster. La replicación hace posible que el tráfico entrante realice una conmutación por error hacia otro clúster en la misma instancia.

  • BigQuery tiene restricciones de localidad que determinan dónde se almacenan tus conjuntos de datos. Las ubicaciones de los conjunto de datos pueden ser regionales o multirregionales. Para proporcionar resiliencia durante un desastre regional, debes crear una copia de seguridad de los datos en otra ubicación geográfica. En el caso de las multirregiones de BigQuery, te recomendamos que evites crear copias de seguridad en regiones que se encuentren dentro del alcance de la multirregión. Si seleccionas la multirregión de la UE, se excluye a Zúrich y Londres de la configuración multirregión. Si deseas obtener orientación sobre cómo implementar una solución de DR para BigQuery que aborde el improbable caso de una pérdida regional física, consulta Pérdida de región.

    Para comprender las implicaciones de adoptar las configuraciones regionales o multirregión de BigQuery, consulta la documentación de BigQuery.

  • Puedes usar Firestore para almacenar tus datos de Firestore en una ubicación multirregional o en una regional. Los datos en una ubicación multirregión operan en una configuración replicada multizona y multirregión. Selecciona una ubicación multirregión si tus requisitos de restricción de localidad lo permiten y si deseas maximizar la disponibilidad y durabilidad de tu base de datos. Las ubicaciones multirregión pueden soportar pérdidas de regiones completas y mantener la disponibilidad sin perder datos. Los datos en una ubicación regional operan en una configuración replicada multizona.

  • Puedes configurar Cloud SQL para la alta disponibilidad. Una instancia de Cloud SQL configurada para la alta disponibilidad también se llama instancia regional y se ubica en una zona primaria y secundaria en la región configurada. En una instancia regional, la configuración se compone de una instancia principal y una instancia en espera. Asegúrate de comprender el tiempo de conmutación por error típico de la instancia principal a la instancia en espera.

    Si tus requisitos lo permiten, puedes configurar Cloud SQL con réplicas entre regiones. Si ocurre un desastre, la réplica de lectura en una región diferente se puede promover. Debido a que las réplicas de lectura se pueden configurar para HA con anticipación, no necesitan pasar por cambios adicionales después de esa promoción para HA. También puedes configurar réplicas de lectura para tener sus propias réplicas entre regiones que pueden ofrecer protección inmediata de fallas regionales después de la promoción de réplicas.

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

    Spanner usa réplicas en zonas diferentes de modo que, si se produce un error en una zona, tu base de datos permanezca disponible. Una implementación multirregión 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. Debes validar que las ubicaciones de todas las regiones cumplan con los requisitos de restricción de localidad.

Compute Engine

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

La ubicación de recursos en diferentes zonas de una región aísla esos recursos de la mayoría de los tipos de fallas físicas de infraestructura y de software del servicio de infraestructura. Además, ubicarlos en diferentes regiones proporciona un grado aún mayor de independencia de fallas. Este enfoque te permite diseñar sistemas sólidos con recursos distribuidos en diferentes dominios con fallas.

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

Usa otra nube o una nube local como sitio de producción

Es posible que uses una región de Google Cloud que te impida usar combinaciones dobles o multirregión para tu arquitectura de DR. Para cumplir con las restricciones de localidad en este caso, considera usar tu propio centro de datos o cualquier otra nube como sitio de producción o como sitio de conmutación por error.

En esta sección, se analizan los productos de Google Cloud optimizados para cargas de trabajo híbridas. Las arquitecturas de DR que usan el entorno local y Google Cloud, se analizan en la página Situaciones de recuperación ante desastres para aplicaciones.

GKE Enterprise

GKE Enterprise es una plataforma de aplicaciones abierta de nube híbrida y múltiples nubes de Google Cloud que te ayuda a ejecutar de forma segura tus cargas de trabajo basadas en contenedores en cualquier lugar. GKE Enterprise la coherencia entre los entornos locales y de nube, lo que te permite tener un modelo operativo coherente y una vista única de tus clústeres de Google Kubernetes Engine (GKE), sin importar la ubicación en la que los ejecutes.

Como parte de tu estrategia de DR, GKE Enterprise simplifica la configuración y la operación de las arquitecturas de alta disponibilidad y de conmutación por error en entornos diferentes (entre Google Cloud y otras nubes o entornos locales). Puedes ejecutar tus clústeres de producción de GKE Enterprise de forma local y, si ocurre un desastre, puedes realizar la conmutación por error para ejecutar las mismas cargas de trabajo en los clústeres de GKE Enterprise en Google Cloud.

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

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

Este tipo de clústeres es el más resistentes a las interrupciones zonales.

Google Cloud VMware Engine

Google Cloud VMware Engine te permite ejecutar cargas de trabajo de VMware en la nube. Si tus cargas de trabajo locales están basadas en VMware, puedes diseñar tu solución de DR para que se ejecute en la misma solución de virtualización que ejecutas de forma local. Puedes seleccionar la región que cumpla con tus requisitos de localidad.

Redes

Cuando tu plan de DR se basa en el traslado de datos desde entornos locales a Google Cloud o desde otro proveedor de servicios en la nube, debes abordar tu estrategia de red. Para obtener más información, consulta la sección Transferencia de datos hacia y desde Google Cloud del documento “Componentes básicos de la recuperación ante desastres”.

Controles del servicio de VPC

Cuando planifiques tu estrategia de DR, 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. Si usas los Controles del servicio de VPC, puedes definir un perímetro de seguridad desde las redes locales hasta los proyectos en Google Cloud.

Los Controles del servicio de VPC habilitan un enfoque de acceso adaptado al contexto para controlar los recursos en la nube. Puedes crear políticas de control de acceso detalladas en Google Cloud según 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 locales y de Google Cloud.

Próximos pasos