Migrar entre regiones de Google Cloud: diseñar entornos de una sola región resistentes en Google Cloud

Last reviewed 2024-12-08 UTC

Este documento le ayudará a diseñar entornos de una sola región resilientes enGoogle Cloud. Este documento es útil si tienes previsto migrar un entorno de una sola región o si estás evaluando la oportunidad de hacerlo en el futuro y quieres saber cómo sería.

Este documento forma parte de una serie:

El objetivo de este documento es proporcionar directrices sobre cómo diseñar entornos de una sola región resilientes en Google Cloud. Se centra en los siguientes componentes de la arquitectura:

Las directrices de este documento presuponen que estás diseñando e implementando entornos de una sola región. Si ahora usas un entorno de una sola región, podrás migrar a un entorno multirregión en el futuro. Si tienes previsto migrar y evolucionar tus entornos zonales y de una sola región a entornos multirregión, consulta el artículo Migrar entre regiones: primeros pasos. Google Cloud

Propiedades de los distintos arquetipos de despliegue

LosGoogle Cloud productos se ofrecen en muchas regiones y zonas.

Cuando diseñes tu Google Cloud entorno, puedes elegir entre los siguientes arquetipos de implementación, presentados en orden de fiabilidad y sobrecarga operativa crecientes:

  • Zonal aprovisionas recursos de Google Cloud en una sola zona de una región y usas los servicios zonales donde estén disponibles. Si los servicios zonales no están disponibles, puedes usar los regionales.
  • Regional: aprovisionas Google Cloud recursos en varias zonas de una región y usas servicios regionales cuando sea posible.
  • Multirregional: aprovisionas Google Cloud recursos en varias zonas de diferentes regiones. Los recursos zonales se aprovisionan en una o varias zonas de cada región.
  • Global: aprovisionas Google Cloud recursos en varias zonas de diferentes regiones de todo el mundo. Los recursos zonales se aprovisionan en una o varias zonas de cada región.

Los arquetipos de implementación anteriores tienen diferentes propiedades de fiabilidad y puedes usarlos para proporcionar las garantías de fiabilidad que necesita tu entorno. Por ejemplo, es más probable que un entorno multirregional sobreviva a una interrupción regional que un entorno de una sola región o de una sola zona. Para obtener más información sobre las propiedades de fiabilidad de cada arquetipo de implementación, consulta el artículo Cómo aprovechar las zonas y las regiones para conseguir fiabilidad y la Google Cloud guía de fiabilidad de la infraestructura.

Diseñar, implementar y operar un entorno basado en estos arquetipos de implementación requiere diferentes niveles de esfuerzo debido a las propiedades de coste y complejidad de cada arquetipo de implementación. Por ejemplo, un entorno zonal puede ser más barato y fácil de diseñar, implementar y operar que un entorno regional o multirregional. El menor esfuerzo y coste del entorno zonal se debe a la sobrecarga adicional que tienes que gestionar para coordinar las cargas de trabajo, los datos y los procesos que residen en diferentes regiones.

En la siguiente tabla se resumen la distribución de recursos, las propiedades de fiabilidad y la complejidad de cada arquetipo de implementación. También se describe el esfuerzo necesario para diseñar e implementar un entorno basado en cada una de ellas.

Nombre del arquetipo de despliegue Distribución de recursos Ayuda a resistir Complejidad del diseño
Entorno zonal En una sola zona Errores de recursos Requiere coordinación en una sola zona
Entorno de una sola región En varias zonas de una sola región Errores de recursos y interrupciones zonales Requiere coordinación entre varias zonas de una misma región
Entorno multirregional En varias zonas y regiones Errores de recursos, interrupciones de zonas, interrupciones de regiones e interrupciones multirregionales Requiere coordinación entre varias zonas y regiones
Entorno global En varias zonas y regiones de todo el mundo Errores de recursos, interrupciones de zonas, interrupciones de regiones e interrupciones multirregionales Requiere coordinación entre varias zonas y regiones

Para obtener más información sobre estos y otros arquetipos de implementación, consulta los Google Cloud arquetipos de implementación.

Elegir arquetipos de implementación para tus entornos

Para elegir el arquetipo de implementación que mejor se adapte a tus necesidades, haz lo siguiente:

  1. Define los modelos de fallo que quieres evitar.
  2. Evalúa los arquetipos de implementación para determinar cuál se adapta mejor a tus necesidades.

Definir modelos de fallos

Para definir modelos de fallos, responde a las siguientes preguntas:

  • ¿Qué componentes de tu entorno necesitan modelos de fallos? Los modelos de errores se pueden aplicar a cualquier elemento que aprovisiones o implementes enGoogle Cloud. Un modelo de fallo se puede aplicar a un elemento concreto o a todos los recursos de una zona o región. Te recomendamos que apliques un modelo de fallos a todo lo que te aporte valor, como cargas de trabajo, datos, procesos y cualquier Google Cloud recurso.
  • ¿Cuáles son los requisitos de alta disponibilidad, continuidad de la actividad empresarial y recuperación tras fallos de estos componentes? Cada componente de tu entorno puede tener sus propios objetivos de nivel de servicio (SLOs), que definen los niveles de servicio aceptables para ese componente, y sus propios requisitos de recuperación tras desastres. Por ejemplo, el acuerdo de nivel de servicio de Compute Engine indica que, si necesitas alcanzar más del 99,5% de tiempo de actividad mensual, debes aprovisionar instancias en varias zonas de una sola región. Para obtener más información, consulta la guía de planificación para la recuperación tras fallos.
  • ¿Cuántos modelos de fallo necesitas definir? En un entorno típico, no todos los componentes tienen que ofrecer las mismas garantías de fiabilidad. Si ofreces garantías de mayor tiempo de actividad y mayor resiliencia, normalmente tendrás que invertir más esfuerzo y recursos. Cuando definas tus modelos de fallos, te recomendamos que adoptes un enfoque en el que definas varios modelos de fallos para cada componente, y no solo uno para todos tus componentes. Por ejemplo, las cargas de trabajo críticas para la empresa suelen necesitar una fiabilidad mayor, aunque puede ser aceptable ofrecer garantías de fiabilidad menores para otras cargas de trabajo menos críticas.
  • ¿Cuántos recursos necesitan los modelos de fallos para protegerse contra los fallos? Para protegerte frente a los modelos de fallos que has definido, inviertes recursos como el tiempo y el coste necesarios para que los usuarios diseñen, aprovisionen y configuren mecanismos de protección y procesos automatizados. Te recomendamos que evalúes cuántos recursos necesitas para protegerte frente a cada modelo de fallo que definas.
  • ¿Cómo detectarás que se está produciendo un fallo? Es fundamental poder detectar que se está produciendo un fallo o que está a punto de producirse para poder iniciar los procesos de mitigación, recuperación y conciliación. Por ejemplo, puedes configurar Google Cloud Observability para que te avise si el rendimiento se reduce.
  • ¿Cómo puedes probar los modelos de fallo que estás definiendo? Cuando definas modelos de fallos, te recomendamos que pienses en cómo probarlos continuamente para verificar que protegen de forma eficaz contra los fallos para los que se han diseñado. Por ejemplo, puedes inyectar fallos en tus entornos o adoptar ingeniería del caos para evaluar la capacidad de tus entornos de tolerar fallos.
  • ¿Qué impacto esperas que tenga un modelo de fallo concreto? Para comprender el impacto que puede tener un fallo en tu empresa, te recomendamos que, en cada modelo de fallo, estimes las consecuencias de cada fallo para el que se ha diseñado el modelo. Esta información es útil para establecer prioridades y órdenes de recuperación, de forma que tú y tus procesos os ocupéis primero de los componentes más críticos.
  • ¿Cuánto tiempo crees que durarán los fallos en los modelos de fallos que estás definiendo? La duración de un fallo puede afectar en gran medida a los planes de mitigación y recuperación. Por lo tanto, cuando definas modelos de fallos, te recomendamos que tengas en cuenta cuánto tiempo puede durar un fallo. Cuando pienses en cuánto tiempo puede durar un fallo, también debes tener en cuenta cuánto tiempo se tarda en identificarlo, solucionarlo y restaurar los recursos que han fallado.

Para obtener más información sobre los modelos de fallos y cómo diseñar un plan de recuperación tras desastres fiable, consulta el artículo Diseñar la recuperación tras desastres para interrupciones de la infraestructura en la nube.

Evaluar arquetipos de despliegue

Una vez que hayas definido los modelos de fallo que quieres evitar, evalúa los arquetipos de implementación para determinar cuál se adapta mejor a tus necesidades. Cuando evalúe los arquetipos de implementación, plantéese las siguientes preguntas:

  • ¿Cuántos arquetipos de implementación necesitas? No tienes que elegir un solo arquetipo de implementación para todos tus entornos. En su lugar, puedes implementar un enfoque híbrido en el que elijas varios arquetipos de implementación en función de las garantías de fiabilidad que necesites para protegerte frente a los modelos de fallos que hayas definido. Por ejemplo, si has definido dos modelos de fallos (uno que requiere un entorno zonal y otro que requiere un entorno regional), puedes elegir arquetipos de implementación independientes para protegerte frente a cada modelo de fallos. Si eliges varios arquetipos de implementación, te recomendamos que evalúes la complejidad que puede suponer diseñar, implementar y operar varios entornos.
  • ¿Cuántos recursos necesitas para diseñar e implementar entornos basados en los arquetipos de implementación? Diseñar e implementar cualquier tipo de entorno requiere recursos y esfuerzo. Te recomendamos que evalúes cuántos recursos crees que necesitarás para diseñar e implementar cada entorno en función del arquetipo que elijas. Cuando sepas cuántos recursos necesitas, podrás sopesar las ventajas y desventajas de las garantías de fiabilidad que ofrece cada arquetipo de implementación, así como el coste y la complejidad de diseñar, implementar y operar entornos basados en esos arquetipos.
  • ¿Tienes previsto migrar un entorno basado en un arquetipo de implementación a un entorno basado en otro arquetipo? En el futuro, es posible que migres cargas de trabajo, datos y procesos de un entorno deGoogle Cloud a otro Google Cloud. Por ejemplo, puedes migrar de un entorno zonal a un entorno regional.
  • ¿Qué importancia tienen para la empresa los entornos que diseñas e implementas? Los entornos críticos para la empresa probablemente necesiten más garantías de fiabilidad. Por ejemplo, puedes diseñar e implementar un entorno multirregional para cargas de trabajo, datos y procesos críticos para la empresa, y diseñar un entorno zonal o regional para cargas de trabajo, datos y procesos menos críticos.
  • ¿Necesitas las funciones que ofrecen determinados arquetipos de implementación para ciertos entornos? Además de las garantías de fiabilidad que ofrece cada arquetipo de implementación, los arquetipos también ofrecen diferentes garantías de escalabilidad, proximidad geográfica, latencia y localidad de los datos. Te recomendamos que tengas en cuenta esas garantías cuando elijas los arquetipos de implementación para tus entornos.

Además de los aspectos técnicos de los modos de fallo que hayas definido siguiendo las directrices anteriores, te recomendamos que tengas en cuenta los requisitos no funcionales, como los requisitos normativos, de localidad y de soberanía. Estos requisitos pueden restringir las opciones que tienes a tu disposición. Por ejemplo, si tienes que cumplir requisitos normativos que exigen el uso de una región específica, debes diseñar e implementar un entorno de una sola región o un entorno zonal en esa región.

Elige una Google Cloud región para tu entorno

Cuando empiece a diseñar sus entornos de una sola región, deberá determinar la región que mejor se adapte a los requisitos de cada entorno. En las siguientes secciones se describen estas dos categorías de criterios de selección:

  • Criterios funcionales. Estos criterios se refieren a losGoogle Cloud productos que ofrece una región concreta y a si una región concreta cumple los requisitos de latencia y proximidad geográfica a los usuarios y a otros entornos externos Google Cloud. Por ejemplo, si tus cargas de trabajo y datos tienen requisitos de latencia para tus usuarios u otros entornos externos Google Cloud, puede que tengas que elegir la región que esté más cerca de tus usuarios u otros entornos para minimizar esa latencia.
  • Criterios no funcionales. Estos criterios se refieren a los precios de los productos asociados a regiones específicas, los requisitos de huella de carbono y los requisitos y normativas obligatorios que se aplican a su empresa. Por ejemplo, los mercados muy regulados, como el bancario y el público, tienen requisitos muy estrictos y específicos sobre la ubicación de los datos y las cargas de trabajo, así como sobre cómo comparten la infraestructura del proveedor de servicios en la nube con otros clientes.

Si eliges una Google Cloud región concreta ahora, en el futuro podrás migrar a otras regiones o a un entorno multirregión. Si tienes previsto migrar a otras regiones en el futuro, consulta el artículo Migrar entre regiones: primeros pasos Google Cloud .

Evaluar los criterios funcionales

Para evaluar los criterios funcionales, plantéate las siguientes preguntas:

  • ¿Cuáles son tus requisitos de proximidad geográfica? Cuando elijas una Google Cloud región, es posible que tengas que colocar tus cargas de trabajo, datos y procesos cerca de tus usuarios o de tus entornos externosGoogle Cloud, como tus entornos on-premise. Por ejemplo, si te diriges a una base de usuarios concentrada en una zona geográfica concreta, te recomendamos que elijas una región que esté lo más cerca posible de esa zona. Google Cloud Si eliges una Google Cloud región que se ajuste mejor a tus requisitos de proximidad geográfica, tus entornos podrán garantizar una latencia y unos tiempos de respuesta más bajos a las solicitudes de tus usuarios y de tus entornos externos Google Cloud. Herramientas como el Google Cloud panel de control de latencia y herramientas no oficiales como GCPing y el Google Cloud selector de regiones pueden darte una idea general de las características de latencia de lasGoogle Cloud regiones. Sin embargo, te recomendamos que realices una evaluación exhaustiva para determinar si las propiedades de latencia se ajustan a tus requisitos, cargas de trabajo, datos y procesos.
  • ¿En qué regiones quieres usar los productos que necesitas? Te recomendamos que evalúes los productos disponibles en cada Google Cloud región y las regiones que ofrecen los servicios que necesitas para diseñar e implementar tus entornos. Para obtener más información sobre los productos disponibles en cada región y sus plazos de disponibilidad, consulta las ubicaciones de Cloud. Además, es posible que algunos productos no ofrezcan todas sus funciones en todas las regiones en las que estén disponibles. Por ejemplo, las regiones y zonas disponibles de Compute Engine ofrecen tipos de máquinas específicos enGoogle Cloud regiones concretas. Para obtener más información sobre las funciones que ofrece cada producto en cada región, consulta la documentación del producto.
  • ¿Los recursos que necesitas en cada Google Cloud región están dentro de los límites de cuota por región? Google Cloud usa cuotas para limitar la cantidad de un recurso compartido Google Cloud que puedes usar. Algunas cuotas son globales y se aplican al uso que hagas del recurso en cualquier parte deGoogle Cloud, mientras que otras son regionales o zonales y se aplican al uso que hagas del recurso en una región Google Cloud específica. Por ejemplo, la mayoría de las cuotas de uso de recursos de Compute Engine, como el número de máquinas virtuales que puedes crear, son regionales. Para obtener más información sobre las cuotas y cómo ajustarlas, consulta la documentación de Cloud Quotas.

Evaluar los criterios no funcionales

Para evaluar los criterios no funcionales, plantéate las siguientes preguntas:

  • ¿Prefieres una huella de carbono baja? Google Cloud invierte continuamente en sostenibilidad y en energía libre de carbono para Google Cloud regiones, y se ha comprometido a utilizar energía libre de carbono en todas las regiones de la nube. Google Cloud Las regiones tienen diferentes huellas de carbono. Para obtener información sobre la huella de carbono de cada Google Cloud región Google Cloud y sobre cómo incorporar energía libre de carbono en tu estrategia de ubicación, consulta Energía libre de carbono para las regiones.
  • ¿Tus entornos deben cumplir normativas concretas? Los gobiernos y las entidades nacionales y supranacionales suelen regular estrictamente determinados mercados y áreas empresariales, como la banca y el sector público. Estas normativas pueden exigir que las cargas de trabajo, los datos y los procesos se ubiquen únicamente en determinadas regiones geográficas. Por ejemplo, es posible que tus entornos deban cumplir los requisitos de soberanía de datos, operativa y software para garantizar determinados niveles de control y transparencia de los datos sensibles y las cargas de trabajo que se ejecutan en la nube. Te recomendamos que evalúes los requisitos normativos actuales y futuros a la hora de elegir lasGoogle Cloud regiones de tus entornos y que selecciones lasGoogle Cloud regiones que mejor se adapten a tus requisitos normativos.

Diseñar y crear entornos de una sola región

Para diseñar un entorno de una sola región, haz lo siguiente:

  1. Crea tu base en Google Cloud.
  2. Aprovisionar y configurar recursos informáticos.
  3. Aprovisionar y configurar recursos de almacenamiento de datos.
  4. Aprovisionar y configurar recursos de analíticas de datos.

Al diseñar tu entorno, ten en cuenta los siguientes principios generales de diseño:

  • Aprovisionar recursos regionales. Muchos Google Cloud productos admiten el aprovisionamiento de recursos en varias zonas de una región. Te recomendamos que aprovisiones recursos regionales en lugar de recursos de zona siempre que sea posible. En teoría, podrías aprovisionar recursos zonales en varias zonas de una región y gestionarlos tú mismo para conseguir una mayor fiabilidad. Sin embargo, esa configuración no aprovecharía al máximo todas las funciones de fiabilidad de la infraestructura de Google en la que se basan los servicios de Google Cloud .
  • Verifica que los entornos funcionan como se espera con las suposiciones del modelo de fallo. Cuando diseñes e implementes tus entornos de una sola región, te recomendamos que verifiques si cumplen los requisitos para protegerte frente a los modelos de fallos que estés considerando antes de promocionarlos como parte de tu entorno de producción. Por ejemplo, puedes simular interrupciones zonales para comprobar que tus entornos de una sola región pueden seguir funcionando con las mínimas interrupciones.

Para obtener más información sobre los principios de diseño generales para diseñar entornos fiables de una y varias regiones, así como sobre cómo consigue Google una mayor fiabilidad con los servicios regionales y multirregionales, consulta el artículo Diseño de la recuperación tras desastres para interrupciones de la infraestructura en la nube: temas comunes.

Crea tu base en Google Cloud

Para sentar las bases de tus entornos de una sola región, consulta Migrar a: planificar y sentar las bases Google Cloud. Las directrices de ese documento tienen como objetivo sentar las bases para migrar cargas de trabajo, datos y procesos a Google Cloud, pero también se pueden aplicar para sentar las bases de tus entornos de una sola región. Después de leer ese documento, sigue leyendo este.

Una vez que hayas sentado las bases en Google Cloud, diseña e implementa controles y límites de seguridad. Estas medidas de seguridad ayudan a garantizar que tus cargas de trabajo, datos y procesos permanezcan en sus respectivas regiones. Las medidas de seguridad también ayudan a asegurar que tus recursos no filtren nada a otras regiones debido a errores, configuraciones incorrectas o ataques maliciosos.

Aprovisionar y configurar recursos de computación

Una vez que haya sentado las bases de sus entornos de una sola región, podrá aprovisionar y configurar recursos de computación. En las siguientes secciones se describen los productos de computación deGoogle Cloud que admiten implementaciones regionales.

Compute Engine

Compute Engine es la infraestructura como servicio (IaaS) de Google Cloud. Utiliza la infraestructura mundial de Google para ofrecer máquinas virtuales y servicios relacionados a los clientes.

Los recursos de Compute Engine pueden ser de zona (como las máquinas virtuales o los discos persistentes de zona), regionales (como las direcciones IP externas estáticas) o globales (como las capturas de disco persistente). Para obtener más información sobre los recursos de zona, regionales y globales que admite Compute Engine, consulta Recursos globales, regionales y de zona.

Para ofrecer una mayor flexibilidad y gestión de recursos físicos, Compute Engine desacopla las zonas de sus recursos físicos. Para obtener más información sobre esta abstracción y lo que puede implicar para ti, consulta Zonas y clústeres.

Para aumentar la fiabilidad de los entornos que usan Compute Engine, ten en cuenta lo siguiente:

  • Grupos de instancias gestionados regionales. Las máquinas virtuales de Compute Engine son recursos zonales, por lo que no estarán disponibles en caso de interrupción zonal. Para mitigar este problema, Compute Engine te permite crear MIGs regionales que aprovisionan máquinas virtuales en varias zonas de una región automáticamente, según la demanda y la disponibilidad regional.

    Si tus cargas de trabajo tienen estado, también puedes crear grupos de instancias gestionados con reconocimiento del estado regionales para conservar los datos y las configuraciones con estado. Los MIGs regionales admiten la simulación de errores zonales. Para obtener información sobre cómo simular un fallo de zona al usar un MIG regional, consulta Simular una interrupción de zona en un MIG regional. Para obtener información sobre cómo se comparan las MIGs regionales con otras opciones de implementación, consulta el artículo Elegir una estrategia de implementación de Compute Engine para tu carga de trabajo.

  • Forma de distribución del destino. Los grupos de instancias gestionados regionales distribuyen las máquinas virtuales según la forma de distribución de destino. Para asegurarte de que la distribución de las máquinas virtuales no difiera en más de una unidad entre dos zonas de una región, te recomendamos que elijas la forma de distribución EVEN al crear MIGs regionales. Para obtener información sobre las diferencias entre las formas de distribución de destino, consulta Comparación de formas.

  • Plantillas de instancia. Para definir las máquinas virtuales que se van a aprovisionar, los MIGs usan un tipo de recurso global llamado plantillas de instancia. Aunque las plantillas de instancias son recursos globales, pueden hacer referencia a recursos de zona o regionales. Cuando crees plantillas de instancia, te recomendamos que hagas referencia a recursos regionales en lugar de a recursos zonales siempre que sea posible. Si usas recursos zonales, te recomendamos que evalúes el impacto de usarlos. Por ejemplo, si creas una plantilla de instancia que hace referencia a un volumen de disco persistente que solo está disponible en una zona determinada, no puedes usar esa plantilla en ninguna otra zona porque el volumen de disco persistente no está disponible en esas otras zonas.

  • Configura el balanceo de carga y el escalado. Compute Engine admite el balanceo de carga del tráfico entre instancias de Compute Engine y el autoescalado para añadir o quitar automáticamente máquinas virtuales de los MIGs según la demanda. Para aumentar la fiabilidad y la flexibilidad de tus entornos, así como para evitar la carga de gestión de las soluciones autogestionadas, te recomendamos que configures el balanceo de carga y el escalado automático. Para obtener más información sobre cómo configurar el balanceo de carga y el escalado en Compute Engine, consulta Balanceo de carga y escalado.

  • Configura las reservas de recursos. Para asegurarte de que tus entornos tengan los recursos necesarios cuando los necesites, te recomendamos que configures reservas de recursos para obtener capacidad de los recursos de zona de Compute Engine. Por ejemplo, si hay una interrupción zonal, es posible que tengas que aprovisionar máquinas virtuales en otra zona para proporcionar la capacidad necesaria y compensar las que no están disponibles debido a la interrupción. Las reservas de recursos aseguran que tengas los recursos disponibles para aprovisionar las máquinas virtuales adicionales.

  • Usa nombres de DNS zonales. Para mitigar el riesgo de interrupciones entre regiones, te recomendamos que utilices nombres de DNS zonales para identificar de forma única las máquinas virtuales que usan nombres de DNS en tus entornos. Google Cloud utiliza nombres de DNS zonales para las máquinas virtuales de Compute Engine de forma predeterminada. Para obtener más información sobre cómo funciona el DNS interno de Compute Engine, consulta DNS interno. Para facilitar una futura migración entre regiones y que tu configuración sea más fácil de mantener, te recomendamos que consideres los nombres de DNS zonales como parámetros de configuración que podrás cambiar en el futuro.

  • Elige las opciones de almacenamiento adecuadas. Compute Engine admite varias opciones de almacenamiento para tus máquinas virtuales, como volúmenes de Persistent Disk y unidades de estado sólido (SSDs) locales:

    • Los volúmenes de Persistent Disk se distribuyen en varios discos físicos y se encuentran de forma independiente de tus máquinas virtuales. Los discos persistentes pueden ser de zona o regionales. Los discos persistentes zonales almacenan datos en una sola zona, mientras que los discos persistentes regionales replican datos en dos zonas diferentes. Cuando elijas opciones de almacenamiento para tus entornos de una sola región, te recomendamos que elijas discos persistentes regionales, ya que te ofrecen opciones de conmutación por error si se producen fallos en una zona. Para obtener más información sobre cómo reaccionar ante fallos de zona cuando se usan discos persistentes regionales, consulta las secciones Opciones de alta disponibilidad con discos persistentes regionales y Conmutación por error de discos persistentes regionales.
    • Las SSDs locales tienen un alto rendimiento, pero solo almacenan datos hasta que se detiene o se elimina una instancia. Por lo tanto, las SSDs locales son ideales para almacenar datos temporales, cachés y datos que se pueden reconstruir por otros medios. Los discos persistentes son dispositivos de almacenamiento duraderos a los que pueden acceder las máquinas virtuales, como si fueran discos físicos.

  • Diseñar e implementar mecanismos de protección de datos. Cuando diseñes tus entornos de una sola región, te recomendamos que implementes mecanismos automatizados para proteger tus datos en caso de que se produzcan eventos adversos, como fallos zonales, regionales o multirregionales, o ataques deliberados por parte de terceros malintencionados. Compute Engine ofrece varias opciones para proteger tus datos. Puedes usar esas funciones de opciones de datos como elementos de creación para diseñar e implementar tus procesos de protección de datos.

GKE

GKE te ayuda a desplegar, gestionar y escalar cargas de trabajo en contenedores en Kubernetes. GKE se basa en Compute Engine, por lo que las recomendaciones de la sección anterior sobre Compute Engine se aplican parcialmente a GKE.

Para aumentar la fiabilidad de los entornos que usan GKE, ten en cuenta los siguientes puntos de diseño y funciones de GKE:

  • Usa clústeres de GKE regionales para aumentar la disponibilidad. GKE admite diferentes tipos de disponibilidad para tus clústeres, en función del tipo de clúster que necesites. Los clústeres de GKE pueden tener un plano de control zonal o regional, y pueden tener nodos que se ejecuten en una sola zona o en varias zonas de una región. Los distintos tipos de clústeres también ofrecen diferentes acuerdos de nivel de servicio (ANS). Para aumentar la fiabilidad de tus entornos, te recomendamos que elijas clústeres regionales.

    Si usas la función Autopilot de GKE, solo puedes aprovisionar clústeres regionales.

  • Considera un entorno de varios clústeres. Implementar varios clústeres de GKE puede aumentar la flexibilidad y las propiedades de disponibilidad de tu entorno, pero también la complejidad. Por ejemplo, si necesitas usar una nueva función de GKE que solo puedes habilitar al crear un clúster de GKE, puedes evitar el tiempo de inactividad y reducir la complejidad de la migración añadiendo un nuevo clúster de GKE a tu entorno multiclúster, desplegando cargas de trabajo en el nuevo clúster y destruyendo el antiguo. Para obtener más información sobre las ventajas de un entorno de GKE con varios clústeres, consulta Casos prácticos de varios clústeres. Para ayudarte a gestionar la complejidad de la migración, Google Cloud ofrece Gestión de flotas, un conjunto de funciones para gestionar un grupo de clústeres de GKE, su infraestructura y las cargas de trabajo que se despliegan en esos clústeres.

  • Configura Copia de seguridad de GKE. Copia de seguridad de GKE es un servicio regional para crear copias de seguridad de la configuración y los volúmenes de las cargas de trabajo de un clúster de GKE de origen y restaurarlos en un clúster de GKE de destino. Para proteger la configuración y los datos de las cargas de trabajo frente a posibles pérdidas, te recomendamos que habilites y configures Copia de seguridad de GKE. Para obtener más información, consulta el artículo Información general sobre Backup for GKE.

Cloud Run

Cloud Run es una plataforma de computación gestionada para ejecutar cargas de trabajo en contenedores. Cloud Run usa servicios para proporcionarte la infraestructura que necesitas para ejecutar tus cargas de trabajo. Los servicios de Cloud Run son recursos regionales y se replican en varias zonas de la región en la que se encuentran. Cuando despliegas un servicio de Cloud Run, puedes elegir una región. A continuación, Cloud Run elige automáticamente las zonas de esa región en las que desplegar las instancias del servicio. Cloud Run equilibra automáticamente el tráfico entre las instancias de servicio y se ha diseñado para mitigar en gran medida los efectos de una interrupción zonal.

VMware Engine

VMware Engine es un servicio totalmente gestionado que te permite ejecutar la plataforma VMware en Google Cloud. Para aumentar la fiabilidad de los entornos que usan VMware Engine, te recomendamos que hagas lo siguiente:

  • Aprovisionar nubes privadas de VMware Engine de varios nodos. VMware Engine permite aprovisionar pilas de VMware aisladas llamadas nubes privadas. Todos los nodos que componen una nube privada residen en la misma región. Los nodos de nube privada se ejecutan en nodos de hardware bare metal aislados y dedicados, y están configurados para eliminar los puntos únicos de fallo. VMware Engine admite nubes privadas de un solo nodo, pero solo recomendamos usarlas para pruebas de concepto y pruebas. En los entornos de producción, te recomendamos que uses las nubes privadas multinodo predeterminadas.
  • Aprovisionar nubes privadas extendidas de VMware Engine. Una nube privada extendida es una nube privada multinodo cuyos nodos se distribuyen entre las zonas de una región. Una nube privada extendida protege tu entorno frente a las interrupciones zonales.

Para obtener más información sobre las funciones de alta disponibilidad y redundancia de VMware Engine, consulta Disponibilidad y redundancia.

Aprovisionar y configurar recursos de almacenamiento de datos

Después de aprovisionar y configurar los recursos informáticos de tus entornos de una sola región, aprovisiona y configura los recursos para almacenar y gestionar los datos. En las siguientes secciones se describen los productos de almacenamiento y gestión de datos que admiten configuraciones regionales y multirregionales. Google Cloud

Cloud Storage

Cloud Storage es un servicio para almacenar objetos, que son fragmentos de datos inmutables, en segmentos, que son contenedores básicos para almacenar datos. Cuando crea un bucket, selecciona el tipo de ubicación del bucket que mejor se adapte a sus requisitos de disponibilidad, normativas y otros. Los tipos de ubicación tienen diferentes garantías de disponibilidad. Para proteger tus datos frente a fallos e interrupciones, Cloud Storage hace que tus datos sean redundantes en al menos dos zonas en el caso de los segmentos que tienen el tipo de ubicación de región, en dos regiones en el caso de los segmentos que tienen el tipo de ubicación de dos regiones y en dos o más regiones en el caso de los segmentos que tienen el tipo de ubicación multirregional. Por ejemplo, si necesitas que un segmento de Cloud Storage esté disponible en caso de que haya interrupciones zonales, puedes aprovisionarlo con un tipo de ubicación de región.

Para obtener más información sobre cómo diseñar mecanismos de recuperación ante desastres para los datos almacenados en Cloud Storage y sobre cómo reacciona Cloud Storage ante las interrupciones zonales y regionales, consulta el artículo Diseñar la recuperación ante desastres para las interrupciones de la infraestructura en la nube: Cloud Storage.

Filestore

Filestore proporciona servidores de archivos totalmente gestionados en Google Cloud que se pueden conectar a instancias de Compute Engine, clústeres de GKE y máquinas locales. Filestore ofrece varios niveles de servicio. Cada nivel ofrece funciones únicas de disponibilidad, escalabilidad, rendimiento, capacidad y recuperación de datos. Cuando aprovisiones instancias de Filestore, te recomendamos que elijas el nivel Enterprise, ya que admite alta disponibilidad y redundancia de datos en varias zonas de una región. Las instancias de otros niveles son recursos zonales.

Bigtable

Bigtable es un servicio de base de datos totalmente gestionado, de alto rendimiento y alta escalabilidad para grandes cargas de trabajo analíticas y operativas. Las instancias de Bigtable son recursos de zona. Para aumentar la fiabilidad de tus instancias, puedes configurar Bigtable para que replique los datos en varias zonas de la misma región o en varias regiones.

Si la replicación está habilitada y se produce una interrupción, Bigtable redirige automáticamente las solicitudes a otras instancias disponibles en las que hayas replicado los datos.

Para obtener más información sobre cómo funciona la replicación en Bigtable, consulta los artículos Acerca de la replicación y Diseño de la recuperación tras desastres para interrupciones de la infraestructura en la nube: Bigtable.

Firestore

Firestore es una base de datos flexible y escalable para el desarrollo móvil, web y de servidores de Firebase y Google Cloud. Cuando aprovisionas una base de datos de Firestore, seleccionas su ubicación. Las ubicaciones pueden ser multirregionales o regionales, y ofrecen diferentes garantías de fiabilidad. Si una base de datos tiene una ubicación regional, replica los datos en diferentes zonas de una región. Una base de datos multirregional replica datos en más de una región.

Para obtener información sobre cómo funciona la replicación en Firestore y cómo reacciona Firestore ante las interrupciones zonales y regionales, consulta Ubicaciones de Firestore y Diseño de la recuperación ante desastres en caso de interrupciones de la infraestructura en la nube: Firestore.

Memorystore

Memorystore te permite configurar servicios de almacenamiento de datos en memoria escalables, seguros y de alta disponibilidad. Admite back-ends de datos para Redis, Memcached y Valkey.

Cuando aprovisionas instancias de Memorystore para Redis, seleccionas un nivel de servicio para esa instancia. Memorystore para Redis admite varios niveles de servicio de instancias, y cada nivel ofrece características únicas de disponibilidad, tamaño de nodo y ancho de banda. Cuando aprovisiones una instancia de Memorystore para Redis, te recomendamos que elijas el nivel Estándar o el nivel Estándar con réplicas de lectura. Las instancias de Memorystore de esos dos niveles replican automáticamente los datos en varias zonas de una región.

Para obtener más información sobre cómo consigue Memorystore para Redis la alta disponibilidad, consulta el artículo Alta disponibilidad de Memorystore para Redis.

Cuando aprovisiones instancias de Memorystore para Memcached, ten en cuenta lo siguiente:

  • Selección de zonas. Cuando aprovisionas instancias de Memorystore para Memcached, seleccionas la región en la que quieres desplegar la instancia. A continuación, puedes seleccionar las zonas de esa región en las que quieras desplegar los nodos de esa instancia o dejar que Memorystore para Memcached distribuya automáticamente los nodos entre las zonas. Para colocar las instancias de forma óptima y evitar problemas de aprovisionamiento, como colocar todos los nodos en la misma zona, te recomendamos que permitas que Memorystore para Memcached distribuya automáticamente los nodos en las zonas de una región.
  • Replicación de datos en distintas zonas. Las instancias de Memorystore para Memcached no replican datos entre zonas o regiones. Para obtener más información sobre cómo funcionan las instancias de Memorystore para Memcached si hay interrupciones zonales o regionales, consulta el artículo Diseño de la recuperación tras desastres para interrupciones de la infraestructura en la nube: Memorystore para Memcached.

Cuando aprovisionas instancias de Memorystore para Valkey, puedes elegir opciones de disponibilidad y fiabilidad. Memorystore for Valkey admite varias configuraciones, como instancias zonales y multizonales. Para obtener más información sobre la disponibilidad y la fiabilidad de Memorystore for Valkey, consulta Memorystore for Valkey: alta disponibilidad y réplicas.

Spanner

Spanner es una base de datos relacional completamente gestionada con escala ilimitada, coherencia inmediata y hasta un 99,999% de disponibilidad. Para usar Spanner, debes aprovisionar instancias de Spanner. Cuando aprovisiones instancias de Spanner, ten en cuenta lo siguiente:

  • Configuración de la instancia. Una configuración de instancia define la ubicación geográfica y la replicación de las bases de datos de una instancia de Spanner. Cuando creas una instancia de Spanner, la configuras como regional o multirregional.
  • Replicación Spanner admite la replicación automática a nivel de bytes y la creación de réplicas en función de tus necesidades de disponibilidad, fiabilidad y escalabilidad. Puedes distribuir réplicas en diferentes regiones y entornos. Las instancias de Spanner que tienen una configuración regional mantienen una réplica de lectura y escritura por cada zona de una región. Las instancias que tienen una configuración multirregional replican los datos en varias zonas de varias regiones.
  • Mover instancias Spanner te permite mover una instancia de una configuración de instancia a otra sin que se produzca ningún tiempo de inactividad ni interrupción de las garantías de las transacciones durante el movimiento.

Para obtener más información sobre la réplica de Spanner y sobre cómo reacciona Spanner ante las interrupciones zonales y regionales, consulta Réplica de Spanner y Diseño de la recuperación ante desastres en caso de interrupciones de la infraestructura de la nube: Spanner.

Aprovisionar y configurar recursos de analíticas de datos

Después de aprovisionar y configurar los recursos de almacenamiento de datos para tus entornos de una sola región, aprovisiona y configura los recursos de analíticas de datos. En las secciones siguientes se describen los Google Cloud productos de analíticas de datos que admiten configuraciones regionales.

BigQuery

BigQuery es un almacén de datos empresariales totalmente gestionado que te ayuda a gestionar y analizar tus datos con funciones integradas como el aprendizaje automático, el análisis geoespacial y la inteligencia empresarial.

Para organizar y controlar el acceso a los datos de BigQuery, se proporcionan contenedores de nivel superior llamados conjuntos de datos. Cuando aprovisione conjuntos de datos de BigQuery, tenga en cuenta lo siguiente:

  • Ubicación del conjunto de datos. Para seleccionar la ubicación de BigQuery en la que quieres almacenar tus datos, configura la ubicación del conjunto de datos. Una ubicación puede ser regional o multirregión. En ambos tipos de ubicación, BigQuery almacena copias de sus datos en dos zonas diferentes dentro de la ubicación seleccionada. No puedes cambiar la ubicación del conjunto de datos después de crearlo.
  • Plan de recuperación tras desastres. BigQuery es un servicio regional y gestiona los fallos de zona automáticamente, tanto en el caso de los recursos informáticos como en el de los datos. Sin embargo, hay ciertas situaciones que debes planificar por tu cuenta, como las interrupciones regionales. Te recomendamos que tengas en cuenta estos casos al diseñar tus entornos.

Para obtener más información sobre la planificación y las funciones de recuperación ante desastres de BigQuery, consulta el artículo Información sobre la fiabilidad: planificación ante desastres de la documentación de BigQuery y el artículo Diseñar la recuperación ante desastres en caso de interrupciones de la infraestructura de la nube: BigQuery.

Dataproc

Dataproc es un servicio gestionado que te permite aprovechar las herramientas de datos de código abierto para el procesamiento por lotes, las consultas, la transmisión y el aprendizaje automático. Dataproc se basa en Compute Engine, por lo que las recomendaciones de la sección anterior sobre Compute Engine se aplican parcialmente a Dataproc.

Para usar Dataproc, debes crear clústeres de Dataproc. Los clústeres de Dataproc son recursos zonales. Cuando crees clústeres de Dataproc, ten en cuenta lo siguiente:

  • Colocación automática de zonas. Cuando creas un clúster, puedes especificar la zona de una región en la que quieras aprovisionar los nodos del clúster o dejar que la colocación automática de zonas de Dataproc seleccione la zona automáticamente. Te recomendamos que utilices la colocación automática de zonas, a menos que necesites ajustar la colocación de las zonas de los nodos del clúster en la región.
  • Modo de alta disponibilidad. Cuando creas un clúster, puedes habilitar el modo de alta disponibilidad. No puedes habilitar el modo de alta disponibilidad después de crear un clúster. Te recomendamos que habilites el modo de alta disponibilidad si necesitas que el clúster sea resistente a los fallos de un solo nodo coordinador o a las interrupciones zonales parciales. Los clústeres de Dataproc de alta disponibilidad son recursos zonales.

Para obtener más información sobre cómo reacciona Dataproc ante las interrupciones zonales y regionales, y cómo aumentar la fiabilidad de los clústeres de Dataproc en caso de fallos, consulta el artículo Diseño de la recuperación tras desastres para interrupciones de la infraestructura en la nube: Dataproc.

Dataflow

Dataflow es un servicio totalmente gestionado para ejecutar flujos de procesamiento de datos por lotes y en streaming. Para usar Dataflow, debes crear flujos de procesamiento de Dataflow. A continuación, Dataflow ejecuta tareas, que son instancias de esos flujos de procesamiento, en nodos de trabajador. Como las tareas son recursos zonales, cuando uses recursos de Dataflow, debes tener en cuenta lo siguiente:

  • Puntos de conexión regionales. Cuando creas una tarea, Dataflow requiere que configures un punto de conexión regional. Si configuras un punto de conexión regional para tu trabajo, restringirás la colocación de los recursos de computación y de datos a una región concreta.
  • Emplazamiento zonal. Dataflow distribuye automáticamente los nodos de trabajo en todas las zonas de una región o en la mejor zona de una región, según el tipo de trabajo. Dataflow te permite anular la colocación zonal de los nodos de trabajador colocando todos los nodos de trabajador en la misma zona de una región. Para mitigar los problemas causados por las interrupciones zonales, te recomendamos que permitas que Dataflow seleccione automáticamente la mejor ubicación de zona, a menos que necesites colocar los nodos de trabajo en una zona específica.

Para obtener más información sobre cómo reacciona Dataproc ante las interrupciones zonales y regionales, y cómo aumentar la fiabilidad de tus clústeres de Dataproc en caso de fallos, consulta el artículo Diseño de la recuperación tras desastres para interrupciones de la infraestructura en la nube: Dataflow.

Pub/Sub

Pub/Sub es un servicio de mensajería asíncrono y escalable que desacopla los servicios que producen mensajes de los servicios que los procesan. Pub/Sub organiza los mensajes en temas. Los editores (servicios que producen mensajes) envían mensajes a temas y los suscriptores reciben mensajes de temas. Pub/Sub almacena cada mensaje en una sola región y lo replica en al menos dos zonas de esa región. Para obtener más información, consulta la descripción general de la arquitectura de Pub/Sub.

Cuando configure su entorno de Pub/Sub, tenga en cuenta lo siguiente:

  • Endpoints globales y regionales. Pub/Sub admite endpoints globales y regionales para publicar mensajes. Cuando un editor envía un mensaje al punto final mundial, Pub/Sub selecciona automáticamente la región más cercana para procesar ese mensaje. Cuando un productor envía un mensaje a un punto final regional, Pub/Sub procesa el mensaje en esa región.
  • Políticas de almacenamiento de mensajes. Pub/Sub te permite configurar políticas de almacenamiento de mensajes para restringir dónde procesa y almacena mensajes Pub/Sub, independientemente del origen de la solicitud y del endpoint que haya usado el editor para publicar el mensaje. Te recomendamos que configures políticas de almacenamiento de mensajes para asegurarte de que los mensajes no salgan de tu entorno de una sola región.

Para obtener más información sobre cómo gestiona Pub/Sub las interrupciones zonales y regionales, consulta Diseño de la recuperación ante desastres para interrupciones de la infraestructura en la nube: Pub/Sub.

Adaptar las cargas de trabajo a entornos de una sola región

Cuando completes el aprovisionamiento y la configuración de tus entornos, debes plantearte cómo hacer que tus cargas de trabajo sean más resistentes a los fallos zonales y regionales. Cada carga de trabajo puede tener sus propios requisitos y propiedades de disponibilidad y fiabilidad, pero hay algunos principios de diseño que puedes aplicar y estrategias que puedes adoptar para mejorar tu postura general de resiliencia en el improbable caso de que se produzcan fallos zonales y regionales. Cuando diseñes e implementes tus cargas de trabajo, ten en cuenta lo siguiente:

  • Implementar prácticas y principios de Site Reliability Engineering (SRE). La automatización y la monitorización exhaustiva forman parte de los principios básicos de SRE. Google Cloud proporciona las herramientas y los servicios profesionales para implementar SRE con el fin de aumentar la resiliencia y la fiabilidad de tus entornos, así como reducir la carga de trabajo manual.
  • Diseña un sistema escalable y resiliente. Cuando diseñes cargas de trabajo para entornos de nube, te recomendamos que consideres la escalabilidad y la resiliencia como requisitos inherentes que deben cumplir tus cargas de trabajo. Para obtener más información sobre este tipo de diseño, consulta Patrones para aplicaciones escalables y resilientes.
  • Diseña tu aplicación para que se recupere de las interrupciones de la infraestructura en la nube. Las garantías deGoogle Cloud disponibilidad se definen en los Google Cloud acuerdos de nivel de servicio. En el improbable caso de que se produzca un fallo zonal o regional, te recomendamos que diseñes tus cargas de trabajo de forma que sean resilientes a los fallos zonales y regionales.
  • Implementa la reducción de carga y la degradación gradual. Si se producen fallos en la infraestructura de la nube o en otras dependencias de tus cargas de trabajo, te recomendamos que diseñes tus cargas de trabajo de forma que sean resilientes. Tus cargas de trabajo deben mantener ciertos niveles de funcionalidad bien definidos, incluso si se producen errores (degradación gradual), y deben poder reducir una parte de su carga cuando se acerquen a condiciones de sobrecarga (reducción de carga).
  • Planifica un mantenimiento periódico. Cuando diseñes tus procesos de implementación y tus procesos operativos, te recomendamos que también pienses en todas las actividades que debes llevar a cabo como parte del mantenimiento periódico de tus entornos. El mantenimiento periódico debe incluir actividades como la aplicación de actualizaciones y cambios de configuración a tus cargas de trabajo y sus dependencias, así como la forma en que esas actividades pueden afectar a la disponibilidad de tus entornos. Por ejemplo, puedes configurar una política de mantenimiento del host para tus instancias de Compute Engine.
  • Adopta un enfoque de desarrollo basado en pruebas. Cuando diseñes tus cargas de trabajo, te recomendamos que adoptes un enfoque de desarrollo basado en pruebas para asegurarte de que se comporten como esperas desde todos los puntos de vista. Por ejemplo, puedes comprobar si tus cargas de trabajo y tu infraestructura en la nube cumplen los requisitos funcionales, no funcionales y de seguridad que necesitas.

Siguientes pasos

Colaboradores

Autor: Marco Ferrari | Arquitecto de soluciones en la nube

Otros colaboradores: