Migra en todas las regiones de Google Cloud: Diseña entornos resilientes de una sola región en Google Cloud

Last reviewed 2023-12-08 UTC

En este documento, encontrarás ayuda para diseñar entornos resilientes y de una sola región en Google Cloud. Este documento es útil si planeas migrar un entorno de una sola región o si evalúas la oportunidad de hacerlo en el futuro y deseas explorar cómo podría ser.

Este documento forma parte de una serie:

En este documento, el objetivo es proporcionar orientación sobre cómo diseñar entornos resilientes y de una sola región en Google Cloud, y se enfoca en los siguientes componentes arquitectónicos:

En la guía de este documento, suponemos que estás diseñando e implementando entornos de una sola región. Si usas un entorno de una sola región ahora, en el futuro puedes migrar a un entorno multirregional. Si consideras una migración y evolución de tus entornos zonales y de una sola región para entornos multirregionales, consulta Migra entre regiones de Google Cloud: Comienza ahora.

Propiedades de diferentes arquetipos de implementación

Google Cloud ofrece servicios de diferentes regiones de todo el mundo. Cada región es un área geográfica independiente que consta de áreas de implementación llamadas zonas. Para obtener más información sobre las regiones y zonas de Google Cloud, consulta Geografía y ubicaciones.

Cuando diseñas tu entorno de Google Cloud, puedes elegir entre los siguientes arquetipos de implementación, que se presentan para aumentar la confiabilidad y la sobrecarga operativa:

  • Arquetipo zonal: Debes aprovisionar recursos de Google Cloud en una sola zona dentro de una región y usar servicios zonales cuando están disponibles. Si los servicios zonales no están disponibles, usa servicios regionales.
  • Arquetipo de una sola región: Debes aprovisionar recursos de Google Cloud en varias zonas dentro de una región y usar servicios regionales cuando sea posible.
  • Arquetipo multirregional: Aprovisiona los recursos de Google Cloud en varias zonas en diferentes regiones. Los recursos zonales se aprovisionan en una o más zonas en cada región.

Los arquetipos de implementación anteriores tienen diferentes propiedades de confiabilidad, y puedes usarlas para proporcionar las garantías de confiabilidad que necesita tu entorno. Por ejemplo, es más probable que un entorno multirregional sobreviva a una interrupción regional en comparación con un entorno de una sola región o zonal. Si deseas obtener más información sobre las propiedades de confiabilidad de cada arquetipo de arquitectura, consulta Cómo aprovechar las zonas y las regiones para lograr la confiabilidad y la guía de confiabilidad de la infraestructura de Google Cloud.

Diseñar, implementar y operar un entorno basado en estos arquetipos de implementación requiere diferentes niveles de esfuerzo debido a las propiedades de costo y complejidad de cada arquetipo. Por ejemplo, un entorno zonal puede ser más económico y fácil de diseñar, implementar y operar en comparación con un entorno regional o multirregional. El esfuerzo y el costo potencialmente más bajos del entorno zonal se deben a la sobrecarga adicional que debes administrar para coordinar las cargas de trabajo, los datos y los procesos que residen en diferentes regiones.

En la siguiente tabla, se resume la distribución de recursos, las propiedades de confiabilidad y la complejidad de cada arquetipo de arquitectura. También se describe el esfuerzo que se necesita para diseñar e implementar un entorno basado en cada uno.

Nombre del arquetipo arquitectónico Distribución de recursos Ayuda a resistir Complejidad del diseño
Entorno zonal En una sola zona Fallas de recursos Requiere coordinación dentro de una sola zona
Entorno de una sola región En varias zonas, en una sola región Fallas de recursos, interrupciones zonales Requiere coordinación en varias zonas, en una sola región
Entorno multirregional En múltiples zonas y regiones Fallas de recursos, interrupciones zonales, interrupciones regionales e interrupciones multirregionales Requiere coordinación en varias zonas, en varias regiones

Elige arquetipos de implementación para tus entornos

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

  1. Define los modelos de falla contra los que deseas protegerte.
  2. Evalúa los arquetipos de implementación para determinar qué se adapta mejor a tus necesidades.

Define modelos de fallas

Para definir modelos de fallas, considera las siguientes preguntas:

  • ¿Qué componentes de tu entorno necesitan modelos de falla? Los modelos con fallas se pueden aplicar a cualquier elemento que aprovisiones o implementes en Google Cloud. Un modelo de falla se puede aplicar a una persona, o puedes aplicar un modelo de falla a todos los recursos en una zona o región completa. Te recomendamos que apliques un modelo de falla a cualquier elemento que te proporcione valor, como cargas de trabajo, datos, procesos y cualquier recurso de Google Cloud.
  • ¿Cuáles son tus requisitos de alta disponibilidad, continuidad del negocio y recuperación ante desastres para estos componentes? Cada componente de tu entorno puede tener sus propios objetivos de nivel de servicio (SLO) que definen los niveles de servicio aceptables para ese componente y sus propios requisitos de recuperación ante desastres. Por ejemplo, el ANS de Compute Engine indica que, si necesitas alcanzar más del 99.5% del tiempo de actividad mensual, debes aprovisionar las instancias en varias zonas en una sola región. Para obtener más información, consulta la guía de planificación para la recuperación ante desastres.
  • ¿Cuántos modelos de fallas debes definir? En un entorno típico, no todos los componentes tienen que proporcionar las mismas garantías de confiabilidad. Si ofreces garantías de mayor tiempo de actividad y una resiliencia más sólida, por lo general, debes invertir más esfuerzo y recursos. Cuando definas tus modelos de falla, te recomendamos que consideres un enfoque en el que defines varios modelos de falla para cada componente, y no solo uno para todos tus componentes. Por ejemplo, las cargas de trabajo fundamentales para la empresa suelen ofrecer una mayor confiabilidad, aunque podría ser aceptable ofrecer garantías de confiabilidad menores para otras cargas de trabajo menos críticas.
  • ¿Cuántos recursos necesitan los modelos de falla para protegerse contra fallas? Para protegerte contra los modelos de falla que definiste, debes emplear los recursos, como el tiempo y los costos necesarios, para que las personas diseñen, aprovisionen y configuren mecanismos de protección y procesos automatizados. Te recomendamos que evalúes cuántos recursos debes proteger contra cada modelo de falla que definas.
  • ¿Cómo detectarás que ocurre una falla? Poder detectar que se produce una falla o está a punto de ocurrir es fundamental para que puedas comenzar los procesos de mitigación, recuperación y conciliación. Por ejemplo, puedes configurar Google Cloud Observability para que te alerte si se reduce el rendimiento.
  • ¿Cómo puedes probar los modelos de falla que estás definiendo? Cuando definas modelos de fallas, te recomendamos que pruebes cómo probar de forma continua cada modelo para protegerlo de manera efectiva contra las fallas a las que se orientan los modelos. Por ejemplo, puedes inyectar fallas en los entornos o evaluar la capacidad de los entornos para tolerar fallas, puedes adoptar la ingeniería del caos..
  • ¿Cuánto impacto esperas si se produce un modelo de falla en particular? Para comprender el impacto que puede tener una falla en tu empresa, te recomendamos que, para cada modelo de falla, evalúes las consecuencias de cada falla con la que se diseña el modelo. Esta comprensión es útil para establecer prioridades y órdenes de recuperación a fin de que tú y tus procesos se ocupen primero de los componentes más importantes.
  • ¿Cuánto esperas que las fallas duren en los modelos de falla que defines? La duración de una falla puede afectar en gran medida los planes de mitigación y recuperación. Por lo tanto, cuando definas modelos de fallas, te recomendamos que tengas en cuenta cuánto tiempo puede durar una falla. Cuando consideres cuánto tiempo puede durar una falla, también considera cuánto tiempo toma: identificar una falla, conciliar la falla y restablecer los recursos que fallaron.

Para obtener más consideraciones sobre los modelos de falla y cómo diseñar un plan de recuperación ante desastres confiable, consulta Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube.

Evalúa los arquetipos de implementación

Después de definir los modelos de falla contra los que deseas protegerte, evalúa los arquetipos de implementación para determinar qué se adapta mejor a tus necesidades. Cuando evalúes los arquetipos de implementación, ten en cuenta las siguientes preguntas:

  • ¿Cuántos arquetipos de implementación necesitas? No es necesario que elijas solo un arquetipo de arquitectura para que se ajuste a todos tus entornos. En su lugar, puedes implementar un enfoque híbrido, en el que eliges varios arquetipos de implementación según las garantías de confiabilidad que necesitas para protegerte contra los modelos de falla que definiste. Por ejemplo, si definiste dos modelos de falla, uno que requiere un entorno zonal y otro que requiere un entorno regional, es posible que desees elegir arquetipos de implementación separados para proteger contra cada modelo de falla. Si eliges varios arquetipos de implementación, te recomendamos que evalúes la complejidad potencialmente creciente de diseñar, implementar y operar varios entornos.
  • ¿Cuántos recursos necesitas para implementar y diseñar entornos según 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 y, luego, implementar cada entorno según el arquetipo que elijas. Una vez que comprendas cuántos recursos necesitas, puedes equilibrar las compensaciones entre la garantía de confiabilidad que ofrece cada arquetipo de arquitectura y el costo y la complejidad de diseñar, implementar y operar entornos basados en esos arquetipos.
  • ¿Esperas migrar un entorno basado en un arquetipo arquitectónico a un entorno basado en un arquetipo diferente? En el futuro, podrías migrar cargas de trabajo, datos y procesos de un entorno de Google Cloud a un entorno de Google Cloud diferente. Por ejemplo, puedes migrar de un entorno zonal a un entorno regional.
  • ¿Qué importancia empresarial tienen los entornos que diseñas e implementas? Es probable que los entornos críticos de la empresa necesiten más garantías de confiabilidad. Por ejemplo, puedes diseñar y, luego, implementar un entorno multirregional para cargas de trabajo, datos y procesos críticos para el negocio, y diseñar un entorno zonal o regional para cargas de trabajo, datos y procesos menos críticos.
  • ¿Necesitas las características que ofrecen arquetipos arquitectónicos particulares para ciertos entornos? Además de las garantías de confiabilidad que ofrece cada arquetipo arquitectónico, los arquetipos también ofrecen diferentes garantías de escalabilidad, proximidad geográfica, latencia y localidad de los datos. Te recomendamos que consideres esas garantías cuando elijas los arquetipos de implementación para tus entornos.

Además de los aspectos técnicos de los modos de falla que definiste mediante la guía anterior, te recomendamos que consideres los requisitos no funcionales, como los requisitos regulatorios, de localidad y de soberanía. Esos requisitos pueden restringir las opciones que están disponibles. Por ejemplo, si necesitas cumplir con los requisitos reglamentarios que exigen el uso de una región específica, debes diseñar y, luego, implementar un entorno de una sola región o un entorno zonal en esa región.

Elige una región de Google Cloud para tu entorno

Cuando comienzas a diseñar tus entornos de una sola región, debes 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 qué productos de Google Cloud ofrece una región en particular y si una región en particular cumple con tu latencia y proximidad geográfica para los usuarios y otros entornos fuera de Google Cloud. Por ejemplo, si tus cargas de trabajo y datos tienen requisitos de latencia para tus usuarios y otros entornos fuera de Google Cloud, es posible que debas elegir la región más cercana a tus usuarios o a otros entornos para minimizar esa latencia.
  • Criterios no funcionales. Estos criterios se relacionan con los precios de los productos asociados con regiones específicas, los requisitos de la huella de carbono y los requisitos y regulaciones obligatorios que se aplican a tu empresa. Por ejemplo, los mercados altamente regulados, como los bancos y el público, tienen requisitos muy estrictos y específicos sobre la localidad de los datos y las cargas de trabajo, y cómo comparten la infraestructura del proveedor de servicios en la nube con otros clientes.

Si eliges una región de Google Cloud en particular, ahora en el futuro puedes migrar a regiones diferentes o a un entorno multirregional. Si consideras una migración futura a otras regiones, consulta Migra en las regiones de Google Cloud: Comienza ahora.

Evalúa los criterios funcionales

Para evaluar los criterios funcionales, considera las siguientes preguntas:

  • ¿Cuáles son tus requisitos de proximidad geográfica? Cuando eliges una región de Google Cloud, es posible que debas colocar las cargas de trabajo, los datos y los procesos cerca de los usuarios o los entornos fuera de Google Cloud, como los entornos locales. Por ejemplo, si te orientas a una base de usuarios que se concentra en un área geográfica particular, te recomendamos que elijas una región de Google Cloud más cercana a esa área geográfica. Elegir la región de Google Cloud que mejor se adapte a tus requisitos de proximidad geográfica permite que tus entornos garanticen una menor latencia y menores tiempos de reacción para las solicitudes de tus usuarios y de tus entornos fuera de Google Cloud. Herramientas como el panel de latencia de Google Cloud y herramientas no oficiales, como GCP y el selector de región de Google Cloud puede darte una idea de alto nivel de las características de latencia de las regiones de Google Cloud. Sin embargo, te recomendamos realizar una evaluación integral para evaluar si las propiedades de latencia se ajustan a tus requisitos, cargas de trabajo, datos y procesos.
  • ¿Qué regiones quieres usar para ofrecer los productos que necesitas? Te recomendamos que evalúes los productos que están disponibles en cada región de Google Cloud y qué regiones proporcionan los servicios que necesitas para diseñar e implementar tus entornos. Para obtener más información sobre qué productos están disponibles en cada región y sus cronogramas de disponibilidad, consulta 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 para Compute Engine ofrecen tipos específicos de máquinas en regiones específicas de Google Cloud. Para obtener más información sobre qué características ofrece cada producto en cada región, consulta la documentación del producto.
  • ¿Los recursos que necesitas en cada región de Google Cloud están dentro de los límites de cuota por región? Google Cloud usa cuotas para restringir cuánto se puede usar de un recurso compartido particular de Google Cloud. Algunas cuotas son globales y se aplican al uso del recurso en cualquier parte de Google Cloud, mientras que otras son regionales o zonales y se aplican al uso del recurso en una región específica de Google Cloud. Por ejemplo, la mayoría de las cuotas de uso de recursos de Compute Engine, como la cantidad de máquinas virtuales que puedes crear, son regionales. Para obtener más información sobre las cuotas y cómo aumentarlas, consulta Trabaja con cuotas.

Evalúa los criterios no funcionales

Para evaluar los criterios no funcionales, considera las siguientes preguntas:

  • ¿Prefieres una huella de carbono baja? Google Cloud invierte de forma continua en sustentabilidad y en energía libre de carbono para las regiones de Google Cloud, y está comprometida con la energía libre de carbono para todas las regiones en la nube.. Las regiones de Google Cloud tienen diferentes huellas de carbono. Para obtener información sobre la huella de carbono de cada región de Google Cloud y cómo incorporar energía sin emisiones de carbono en tu estrategia de ubicación, consulta Energía sin emisiones de carbono para regiones de Google Cloud.
  • ¿Tus entornos deben cumplir con regulaciones específicas? Los gobiernos y las entidades nacionales y supranacionales a menudo regulan estrictamente ciertos mercados y áreas de negocios, como el sector bancario y público. Estas regulaciones pueden requerir que las cargas de trabajo, los datos y los procesos residan solo en ciertas regiones geográficas. Por ejemplo, es posible que tus entornos necesiten cumplir con requisitos de soberanía operativa, de datos y operativos para garantizar ciertos niveles de control y transparencia para cargas de trabajo y datos sensibles que se ejecutan en la nube. Te recomendamos evaluar los requisitos regulatorios actuales y futuros cuando elijas las regiones de Google Cloud para tus entornos y seleccionar las regiones de Google Cloud que mejor se adapten a tus necesidades normativas.

Diseña y compila entornos de una sola región

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

  1. Compila tu base en Google Cloud.
  2. Aprovisiona y configura los recursos de procesamiento.
  3. Aprovisiona y configura los recursos de almacenamiento de datos.
  4. Aprovisiona y configura los recursos de análisis de datos.

Cuando diseñes tu entorno, considera los siguientes principios de diseño generales:

  • Aprovisiona recursos regionales. Muchos productos de Google Cloud admiten el aprovisionamiento de recursos en varias zonas de una región. Te recomendamos que aprovisiones los recursos regionales en lugar de los zonales cuando sea posible. Teóricamente, es posible que puedas aprovisionar recursos zonales en varias zonas de una región y administrarlos tú mismo para lograr una mayor confiabilidad. Sin embargo, esa configuración no se beneficiaría por completo de todas las funciones de confiabilidad de la infraestructura de Google que respalda los servicios de Google Cloud.
  • Verifica que los entornos funcionen como se espera con las suposiciones del modelo de falla. Cuando diseñes e implementes los entornos de una sola región, te recomendamos que verifiques si esos entornos cumplen con los requisitos para protegerte contra los modelos de falla que consideras antes de promover esos entornos como parte del entorno de producción. Por ejemplo, puedes simular interrupciones zonales para verificar que los entornos de una sola región puedan sobrevivir con una interrupción mínima.

Si deseas obtener principios de diseño más generales para diseñar entornos confiables y de una sola región y obtener información sobre cómo Google logra una mejor confiabilidad con servicios regionales y multirregionales, consulta Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: temas comunes

Compila tu base en Google Cloud

Para crear la base de tus entornos de una sola región, consulta Migración a Google Cloud: Compila tu base. El objetivo de ese documento es crear una base para migrar cargas de trabajo, datos y procesos a Google Cloud, pero también es aplicable a compilar la base para tus entornos de una sola región. Después de leer ese documento, continúa leyendo este documento.

Después de compilar la base en Google Cloud, debes diseñar e implementar controles y límites de seguridad. Esas medidas de seguridad ayudan a garantizar que tus cargas de trabajo, datos y procesos permanezcan dentro de sus respectivas regiones. Las medidas de seguridad también ayudan a garantizar que tus recursos no filtren nada a otras regiones debido a errores, configuraciones incorrectas o ataques maliciosos.

Aprovisionar y configurar los recursos de procesamiento

Después de compilar la base de tus entornos de una sola región, debes aprovisionar y configurar los recursos de procesamiento. En las siguientes secciones, se describen los productos de computación de Google Cloud que admiten implementaciones regionales.

Compute Engine

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

Los recursos de Compute Engine son zonales, comomáquinas virtuales o Disco persistente zonal, regional, como direcciones IP externas estáticas, o globales, como instantáneas de Persistent Disk. Para obtener más información sobre los recursos zonales, regionales y globales que admite Compute Engine, consulta Recursos globales, regionales y zonales.

Para permitir una mejor flexibilidad y administración de recursos de los recursos físicos, Compute Engine separa las zonas de sus recursos físicos. Para obtener más información sobre esta abstracción y sobre lo que podría implicar, consulta Zonas y clústeres.

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

  • Grupos de instancias administrados regionales (MIG). Las máquinas virtuales de Compute Engine son recursos zonales, por lo que no estarán disponibles en caso de una interrupción zonal. Para mitigar este problema, Compute Engine te permite crear MIG regionales que aprovisionan máquinas virtuales en varias zonas de una región de forma automática, según la demanda y la disponibilidad regional. Si las cargas de trabajo tienen estado, también puedes crear MIG con estado regionales para conservar los datos y las configuraciones con estado. Los MIG regionales admiten la simulación de fallas zonales. Para obtener información sobre cómo simular una falla zonal cuando se usa un MIG regional, consulta Simula una interrupción de zona para un MIG regional. Para obtener información sobre cómo los MIG regionales se comparan con otras opciones de implementación, consulta Elige una estrategia de implementación de Compute Engine para tu carga de trabajo.
  • Forma de distribución objetivo. Los MIG regionales distribuyen las máquinas virtuales según la forma de distribución objetivo. Para garantizar que la distribución de la máquina virtual 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 cuando crees MIG regionales. Para obtener información sobre las diferencias entre las formas de distribución objetivo, consulta Comparación de formas.
  • Plantillas de instancias. Para definir las máquinas virtuales que se aprovisionarán, los MIG usan un tipo de recurso global llamado plantillas de instancias. Aunque las plantillas de instancias son recursos globales, pueden hacer referencia a recursos zonales o regionales. Cuando crees plantillas de instancias, te recomendamos que hagas referencia a recursos regionales sobre recursos zonales cuando sea posible. Si usas recursos zonales, te recomendamos que evalúes el impacto de su uso. Por ejemplo, si creas una plantilla de instancias 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 cargas y el escalamiento. Compute Engine admite el tráfico de balanceo de cargas entre instancias de Compute Engine y admite el ajuste de escala automático para agregar o quitar máquinas virtuales de forma automática de MIG, según la demanda. Para aumentar la confiabilidad y la flexibilidad de los entornos, y evitar la carga de la administración de las soluciones autoadministradas, recomendamos que configures el balanceo de cargas y el ajuste de escala automático. Consulta Balanceo de cargas y escalamiento para obtener más información sobre la configuración del balanceo de cargas y el escalamiento de Compute Engine.
  • Configura reservas de recursos. A fin de garantizar que tus entornos tengan los recursos necesarios cuando los necesites, te recomendamos que configures las reservas de recursos a fin de proporcionar seguridad a fin de obtener capacidad para recursos zonales de Compute Engine. Por ejemplo, si hay una interrupción zonal, puedes necesitar aprovisionar máquinas virtuales en otra zona para proporcionar la capacidad necesaria a fin de compensar las que no están disponibles debido a la interrupción. Las reservas de recursos garantizan que tengas los recursos disponibles para aprovisionar las máquinas virtuales adicionales.
  • Usa nombres de DNS zonales. A fin de mitigar el riesgo de interrupciones interregionales, te recomendamos que uses los nombres de DNS zonales para identificar de forma única las máquinas virtuales que usan nombres de DNS en tus entornos. Google Cloud usa nombres de DNS zonales para 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 migración futura entre regiones y hacer que la configuración sea más fácil de mantener, te recomendamos que consideres los nombres DNS zonales como parámetros de configuración que, finalmente, 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 (SSD) locales:
    • Los volúmenes de discos persistentes se distribuyen en varios discos físicos y se ubican independientemente de tus máquinas virtuales. Los discos persistentes pueden ser zonales o regionales. Los discos persistentes almacenan datos en una sola zona, mientras que los discos persistentes regionales replican los 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 porque te ofrecen opciones de conmutación por error si hay fallas zonales. Para obtener más información sobre cómo reaccionar a las fallas zonales cuando usas discos persistentes regionales, consulta Opciones de alta disponibilidad con discos persistentes regionales y Conmutación por error de discos persistentes regionales.
    • Los SSD locales tienen alta capacidad de procesamiento, pero almacenan datos solo hasta que se detiene o se borra una instancia. Por lo tanto, los SSD locales son ideales para almacenar datos temporales, cachés y datos que puedes reconstruir por otros medios. Los discos persistentes son dispositivos de almacenamiento duraderos a los que las máquinas virtuales pueden acceder como discos físicos.
  • Diseña e implementa mecanismos para la protección de datos. Cuando diseñes tus entornos de una sola región, te recomendamos que implementes mecanismos automatizados para proteger tus datos si hay eventos adversos, como fallas zonales, regionales o multirregionales, o ataques deliberados de terceros maliciosos. Compute Engine proporciona varias opciones para proteger tus datos. Puedes usar esas funciones de opciones de datos como componentes básicos para diseñar e implementar los procesos de protección de datos.

GKE

GKE te ayuda a implementar, administrar y escalar cargas de trabajo alojadas 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 de forma parcial a GKE.

Para aumentar la confiabilidad de tus entornos que usan GKE, considera 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 los clústeres, según el 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 ejecutan en una sola zona o en varias zonas dentro de una región. Los diferentes tipos de clústeres también ofrecen diferentes Acuerdos de Nivel de Servicio (ANS). Para aumentar la confiabilidad de tus entornos, te recomendamos que elijas clústeres regionales. Si usas la función de Autopilot de GKE, puedes aprovisionar solo clústeres regionales.
  • Considera un entorno de varios clústeres. La implementación de varios clústeres de GKE puede aumentar la flexibilidad y las propiedades de disponibilidad de tu entorno, a costa de una mayor complejidad. Por ejemplo, si necesitas usar una función de GKE nueva que solo puedes habilitar cuando creas un clúster de GKE, puedes evitar el tiempo de inactividad y reducir la complejidad de la migración si agregas un clúster de GKE nuevo a tu entorno de varios clústeres, implementas cargas de trabajo en el clúster nuevo y destruyes el clúster anterior. Para obtener más información sobre los beneficios de un entorno de GKE de varios clústeres, consulta Migra contenedores a Google Cloud: migra a un entorno de GKE de varios clústeres. Para ayudarte a administrar la complejidad de la migración, Google Cloud ofrece Administración de flotas, un conjunto de capacidades para administrar un grupo de clústeres de GKE, su infraestructura y las cargas de trabajo implementadas en esos clústeres.
  • Configura la copia de seguridad para GKE. La copia de seguridad para GKE es un servicio regional que permite crear una copia de seguridad de la configuración y los volúmenes de la carga de trabajo en un clúster de GKE de origen y restablecerlos en un clúster de GKE de destino. A fin de proteger la configuración de las cargas de trabajo y los datos de posibles pérdidas, te recomendamos que habilites y configures la copia de seguridad para GKE. A fin de obtener más información, consulta Descripción general de la copia de seguridad para GKE.

Cloud Run

Cloud Run es una plataforma de procesamiento administrada para ejecutar cargas de trabajo alojadas en contenedores. Cloud Run usa servicios para proporcionarte la infraestructura a fin de 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 implementas un servicio de Cloud Run, puedes elegir una región. Luego, Cloud Run elige de forma automática las zonas dentro de esa región en la que se implementan las instancias del servicio. Cloud Run balancea el tráfico de forma automática entre las instancias de servicio y está diseñado para mitigar en gran medida los efectos de una interrupción zonal.

VMware Engine

VMware Engine es un servicio completamente administrado que te permite ejecutar la plataforma de VMware en Google Cloud. Para aumentar la confiabilidad de tus entornos que usan VMware Engine, recomendamos lo siguiente:

  • Aprovisiona nubes privadas de VMware Engine de varios nodos. VMware Engine admite el aprovisionamiento de pilas de VMware aisladas llamadas nubes privadas, y 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 físicos aislados y dedicados, y están configurados para eliminar puntos únicos de fallo. VMware Engine admite nubes privadas de un solo nodo, pero solo recomendamos usar nubes privadas de un solo nodo para realizar pruebas de concepto y realizar pruebas. Para entornos de producción, te recomendamos usar las nubes privadas predeterminadas de varios nodos.
  • Aprovisiona nubes privadas extendidas de VMware Engine. Una nube privada extendida es una nube privada de varios nodos cuyos nodos se distribuyen en las zonas de una región. Una nube privada extendida protege tu entorno contra interrupciones zonales.

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

Aprovisiona y configura recursos de almacenamiento de datos

Después de aprovisionar y configurar los recursos de procesamiento para tus entornos de una sola región, aprovisiona y configura los recursos a fin de almacenar y administrar datos. En las siguientes secciones, se describen los productos de administración y almacenamiento de datos de Google Cloud que admiten opciones regionales y multirregionales.

Cloud Storage

Cloud Storage es un servicio para almacenar objetos, que son datos inmutables, en buckets, que son contenedores básicos para guardar tus datos. Cuando creas un depósito, seleccionas el tipo de ubicación de depósito que mejor se adapte a tu disponibilidad, reglamento y otros requisitos. Los tipos de ubicación tienen garantías de disponibilidad diferentes. A fin de proteger tus datos contra interrupciones y fallas, Cloud Storage hace que los datos sean redundantes en al menos dos zonas para los buckets que tienen un tipo de ubicación regional, en dos regiones para los buckets que tienen una ubicación birregional, y en dos o más regiones para los buckets que tienen un tipo de ubicación multirregional. Por ejemplo, si necesitas que un bucket de Cloud Storage esté disponible si hay interrupciones zonales, puedes aprovisionarlo con un tipo de ubicación regional.

Si deseas obtener más información sobre cómo diseñar mecanismos de desastre para datos almacenados en Cloud Storage y cómo reacciona Cloud Storage a interrupciones zonales y regionales, consulta Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: Cloud Storage.

Filestore

Filestore proporciona servidores de archivos completamente administrados en Google Cloud que pueden conectarse a instancias de Compute Engine, clústeres de GKE y tus 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 empresarial porque admite alta disponibilidad y Redundancia de datos en varias zonas de una región Las instancias que están en otros niveles son recursos zonales.

Bigtable

Bigtable es un servicio de base de datos completamente administrado, de alto rendimiento y de alta escalabilidad para cargas de trabajo grandes de análisis y operaciones. Las instancias de Bigtable son recursos zonales. Con el fin de aumentar la confiabilidad de tus instancias, puedes configurar Bigtable para que replique los datos en varias zonas dentro de la misma región o en varias regiones. Cuando la replicación está habilitada, si hay una interrupción, Bigtable conmuta por error las solicitudes a otras instancias disponibles en las que replicaste los datos.

Si deseas obtener más información sobre cómo funciona la replicación en Bigtable, consulta Acerca de la replicación y Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: Bigtable.

Firestore

Firestore es una base de datos flexible y escalable para el desarrollo en servidores, dispositivos móviles y la Web desde Firebase y Google Cloud. Cuando aprovisionas una base de datos de Firestore, debes seleccionar su ubicación. Las ubicaciones pueden ser multirregionales o regionales, y ofrecen diferentes garantías de confiabilidad. Si una base de datos tiene una ubicación regional, replica datos en diferentes zonas dentro de una región. Una base de datos multirregional replica los 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 a interrupciones zonales y regionales, consulta Ubicaciones de Firestore y Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: Firestore.

Memorystore

Memorystore te permite configurar servicios de almacenamiento de datos escalables, seguros y con alta disponibilidad en la memoria. Admite backends de datos para Redis y Memcached.

Cuando aprovisionas instancias de Memorystore para Redis, debes seleccionar un nivel de servicio para esa instancia. Memorystore para Redis admite varios niveles de servicio de instancia, y cada nivel ofrece atributos únicos de disponibilidad, tamaño de nodos y ancho de banda. Cuando aprovisionas una instancia de Memorystore para Redis, te recomendamos que elijas un nivel Estándar o un nivel Estándar con réplicas de lectura. Las instancias de Memorystore en esos dos niveles replican de forma automática los datos en varias zonas de una región. Para obtener más información acerca de cómo Memorystore para Redis logra una alta disponibilidad, consulta Alta disponibilidad para Memorystore para Redis.

Cuando aprovisiones instancias de Memorystore para Memcached, considera lo siguiente:

  • Selección de la zona. Cuando aprovisiones instancias de Memorystore para Memcached, selecciona la región en la que deseas implementar la instancia. Luego, puedes seleccionar las zonas dentro de esa región en la que deseas implementar los nodos de esa instancia o puedes dejar que Memorystore para Memcached distribuya de forma automática los nodos entre zonas. Para colocar instancias de forma óptima y evitar los problemas de aprovisionamiento, como colocar todos los nodos dentro de la misma zona, te recomendamos que permitas que Memorystore para Memcached distribuya de forma automática los nodos entre las zonas dentro de una región.
  • Replicación de datos entre zonas. Las instancias de Memorystore para Memcached no replican datos en las zonas o regiones. Si deseas obtener más información sobre cómo funcionan las instancias de Memorystore para Memcached si hay interrupciones zonales o regionales, consulta Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: Memorystore para Memcached.

Spanner

Spanner es una base de datos relacional completamente administrada con escalamiento ilimitado, coherencia sólida y disponibilidad de hasta el 99.999%. Para usar Spanner, debes aprovisionar instancias de Spanner. Cuando aprovisiones instancias de Spanner, considera lo siguiente:

  • Configuración de instancias. Una configuración de instancia define la ubicación geográfica y la replicación de las bases de datos en 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 admite la creación de réplicas según tus necesidades de disponibilidad, confiabilidad y escalabilidad. Puedes distribuir réplicas entre regiones y entornos. Las instancias de Spanner que tienen una configuración regional mantienen una réplica de lectura y escritura para cada zona dentro de una región. Las instancias que tienen una configuración multirregional replican los datos en varias zonas en varias regiones.
  • Transferencia de instancias. Spanner te permite mover una instancia de cualquier configuración de instancia a cualquier otra configuración de instancia sin causar tiempo de inactividad ni interrupciones de las garantías de transacción durante el traslado.

Para obtener más información sobre la replicación de Spanner y sobre cómo reacciona Spanner a las interrupciones zonales y regionales, consulta Replicación de Spanner y Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: Spanner.

Aprovisiona y configura recursos de análisis de datos

Después de aprovisionar y configurar los recursos de almacenamiento de datos para los entornos de una sola región, debes aprovisionar y configurar los recursos de análisis de datos. En las siguientes secciones, se describen los productos de análisis de datos de Google Cloud que admiten configuraciones regionales.

BigQuery

BigQuery es un almacén de datos empresarial completamente administrado que te ayuda a administrar 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 en BigQuery, debes aprovisionar contenedores de nivel superior llamados conjuntos de datos. Cuando aprovisiones conjuntos de datos de BigQuery, ten en cuenta lo siguiente:

  • Ubicación del conjunto de datos. Para seleccionar la ubicación de BigQuery en la que deseas almacenar tus datos, configura la ubicación del conjunto de datos. Una ubicación puede ser regional o multirregión. Para cualquiera de los tipos de ubicación, BigQuery almacena copias de tus 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.
  • Planificación ante desastres. BigQuery es un servicio regional y controla las fallas zonales de forma automática para el procesamiento y los datos. Sin embargo, hay ciertas situaciones que debes planificar por tu cuenta, como las interrupciones regionales. Te recomendamos que consideres esas situaciones cuando diseñes tus entornos.

Para obtener más información sobre la planificación y las funciones de la recuperación ante desastres de BigQuery, consulta Comprende la confiabilidad: Planificación de desastres en la documentación de BigQuery y Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: BigQuery.

Dataproc

Dataproc es un servicio administrado 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 también se aplican a Dataproc de forma parcial.

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:

  • Ubicación automática de zonas Cuando creas un clúster, puedes especificar la zona dentro de una región en la que deseas aprovisionar los nodos del clúster o dejar que la ubicación de zona automática de Dataproc seleccione la zona automáticamente. Te recomendamos que uses la ubicación de zona automática, a menos que necesites ajustar la ubicación de zona de los nodos de clúster dentro de 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 la falla de un solo nodo coordinador o a interrupciones zonales parciales. Los clústeres de Dataproc de alta disponibilidad son recursos zonales.

Para obtener más información sobre cómo Dataproc reacciona a las interrupciones zonales y regionales, y cómo aumentar la confiabilidad de tus clústeres de Dataproc si hay fallas, consulta:Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: Dataproc.

Dataflow

Dataflow es un servicio completamente administrado que permite ejecutar canalizaciones de procesamiento de datos de transmisión y por lotes. Para usar Dataflow, debes crear canalizaciones de Dataflow y, luego, Dataflow ejecuta trabajos, que son instancias de esas canalizaciones, en los nodos trabajadores. Debido a que los trabajos son recursos zonales, cuando uses los recursos de Dataflow, debes tener en cuenta lo siguiente:

  • Extremos regionales. Cuando creas un trabajo, Dataflow exige que configures un extremo regional. Cuando configuras un extremo regional para tu trabajo, restringes la ubicación de los recursos de procesamiento y de datos a una región en particular.
  • Ubicación zonal. Dataflow distribuye de forma automática los nodos trabajadores en todas las zonas dentro de una región o en la mejor zona dentro de una región, según el tipo de trabajo. Dataflow te permite anular la ubicación zonal de los nodos trabajadores mediante la colocación de todos los nodos trabajadores en la misma zona dentro de una región. Para mitigar los problemas causados por las interrupciones zonales, te recomendamos que permitas que Dataflow seleccione de forma automática la mejor ubicación de zona, a menos que tengas que colocar los nodos trabajadores en una zona específica.

Para obtener más información sobre cómo Dataproc reacciona a las interrupciones zonales y regionales, y cómo aumentar la confiabilidad de tus clústeres de Dataproc si hay fallas, consulta:Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: Dataflow.

Pub/Sub

Pub/Sub es un servicio de mensajería asíncrona y escalable que separa los servicios que producen mensajes de servicios que procesan esos mensajes. Pub/Sub organiza los mensajes en temas. Los publicadores (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 dentro de esa región. Para obtener más información, consulta Descripción general de la arquitectura de Pub/Sub.

Cuando configures tu entorno de Pub/Sub, ten en cuenta lo siguiente:

  • Extremos globales y regionales. Pub/Sub admite extremos globales y regionales para publicar mensajes. Cuando un publicador envía un mensaje al extremo global, Pub/Sub selecciona automáticamente la región más cercana para procesar ese mensaje. Cuando un productor envía un mensaje a un extremo 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 el lugar en el que Pub/Sub procesa y almacena mensajes, sin importar el origen de la solicitud y el extremo que el publicador usó para publicar el mensaje. Te recomendamos que configures las políticas de almacenamiento de mensajes para asegurarte de que los mensajes no salgan de tu entorno de una sola región.

Si deseas obtener más información sobre cómo Pub/Sub maneja las interrupciones zonales y regionales, consulta Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: Pub/Sub.

Adapta tus cargas de trabajo a entornos de una sola región

Cuando completes el aprovisionamiento y la configuración de tus entornos, deberás considerar cómo hacer que tus cargas de trabajo sean más resistentes a las fallas zonales y regionales. Cada carga de trabajo puede tener sus propias propiedades y requisitos de disponibilidad y confiabilidad, pero hay algunos principios de diseño que puedes aplicar y estrategias que puedes adoptar para mejorar tu posición de resiliencia general en el caso improbable de fallas zonales y regionales. Cuando diseñes e implementes tus cargas de trabajo, ten en cuenta lo siguiente:

  • Implementa las prácticas y los principios de la ingeniería de confiabilidad de sitios (SRE). La automatización y la supervisión exhaustiva son parte de los principios básicos de la SRE. Google Cloud proporciona las herramientas y los servicios profesionales para implementar SRE a fin de aumentar la resiliencia y la confiabilidad de los entornos y reducir el trabajo repetitivo.
  • Diseña para la escalabilidad y la resiliencia. Cuando diseñas cargas de trabajo destinadas a los entornos de nube, te recomendamos que consideres la escalabilidad y la resiliencia como requisitos inherentes que tus cargas de trabajo deben respetar. Para obtener más información sobre este tipo de diseño, consulta Patrones de apps escalables y resilientes.
  • Diseña para la recuperación ante interrupciones de la infraestructura de nube. Las garantías de disponibilidad de Google Cloud se definen según los Acuerdos de Nivel de Servicio de Google Cloud. En el improbable caso de que ocurra una falla zonal o regional, te recomendamos que diseñes tus cargas de trabajo para que sean resilientes a las fallas zonales y regionales.
  • Implementa la reducción de carga y la degradación elegante. Si hay fallas de la infraestructura de nube o de otras dependencias de tus cargas de trabajo, te recomendamos que diseñes tus cargas de trabajo para que sean resilientes. Tus cargas de trabajo deben mantener ciertos niveles de funcionalidad y bien definidos, incluso si hay fallas (degradación elegante) y deben poder descartar cierta proporción de su carga, como se abordan con las condiciones de sobrecarga (reducción de carga).
  • Planifica el mantenimiento habitual. Cuando diseñes tus procesos de implementación y tus procesos operativos, te recomendamos que pienses en todas las actividades que necesitas realizar como parte del mantenimiento habitual de los entornos. El mantenimiento regular debe incluir actividades como aplicar actualizaciones y cambios de configuración a las cargas de trabajo y sus dependencias, y cómo esas actividades pueden afectar 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 tus cargas de trabajo se comporten como se espera desde todos los ángulos. Por ejemplo, puedes probar si las cargas de trabajo y la infraestructura de nube cumplen con los requisitos funcionales, no funcionales y de seguridad que necesitas.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores:

Para ver los perfiles de LinkedIn no públicos, accede a LinkedIn.