Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube

Last reviewed 2023-01-16 UTC

Este artículo forma parte de una serie en la que se trata la recuperación ante desastres (DR) en Google Cloud. En esta parte, se analiza el proceso para diseñar la arquitectura de cargas de trabajo mediante Google Cloud y los componentes básicos resilientes a las interrupciones en la infraestructura de nube.

La serie consta de estas partes:

Introducción

A medida que las empresas trasladan las cargas de trabajo a la nube pública, necesitan traducir sus conocimientos de cómo compilar sistemas locales resilientes en la infraestructura de hiperescalamiento de los proveedores de servicios en la nube, como Google Cloud. En este artículo, se asignan conceptos estándar de la industria sobre la recuperación ante desastres, como el RTO (objetivo de tiempo de recuperación) y el RPO (objetivo de punto de recuperación) a la infraestructura de Google Cloud.

La orientación de este documento sigue uno de los principios clave de Google para lograr una disponibilidad de servicio muy alta: planificar la falla. Si bien Google Cloud ofrece un servicio muy confiable, ocurrirán desastres naturales, cortes de fibra y errores complejos de infraestructura; estos pueden causar interrupciones. La planificación para las interrupciones permite que los clientes de Google Cloud compilen aplicaciones que se ejecuten de manera predecibles durante estos eventos inevitables mediante el uso de productos de Google Cloud con mecanismos de DR “integrados”.

La recuperación ante desastres es un tema amplio que cubre mucho más que las fallas de infraestructura, como los errores de software o la corrupción de datos, y debes tener un plan integral de extremo a extremo. Sin embargo, este artículo se centra en una parte de un plan de DR general: cómo diseñar aplicaciones que sean resilientes a las interrupciones de la infraestructura de nube. En concreto, se explica lo siguiente:

  1. La infraestructura de Google Cloud, cómo se manifiestan los eventos de desastre como interrupciones de Google Cloud y cómo Google Cloud está diseñado para minimizar la frecuencia y el alcance de las interrupciones
  2. Una guía de planificación de la arquitectura que proporciona un framework para categorizar y diseñar aplicaciones según los resultados de confiabilidad deseados
  3. Una lista detallada de productos de Google Cloud seleccionados que ofrecen funciones de DR integradas que tal vez quieras usar en tu aplicación

Para obtener más detalles sobre la planificación general de la DR y el uso de Google Cloud como componente de tu estrategia de DR local, consulta la Guía de planificación para la recuperación ante desastres. Aunque la alta disponibilidad es un concepto muy relacionado con la recuperación ante desastres, no se aborda en este artículo. Si deseas obtener más detalles sobre la arquitectura de una alta disponibilidad, consulta el framework de la arquitectura de Google Cloud.

Nota sobre la terminología: Este artículo hace referencia a la disponibilidad cuando se describe la capacidad de un producto de que se acceda a él de manera significativa y se use a lo largo del tiempo, mientras que la confiabilidad se refiere a un conjunto de atributos que incluye la disponibilidad, además de funciones como la durabilidad y la corrección.

Cómo está diseñado Google Cloud para ofrecer resiliencia

Centros de datos de Google

Los centros de datos tradicionales se basan en maximizar la disponibilidad de componentes individuales. En la nube, la escala permite a operadores como Google distribuir servicios en muchos componentes mediante tecnologías de virtualización y, por lo tanto, superar la confiabilidad tradicional de los componentes. Esto significa que puedes dejar de enfocar la mentalidad de la arquitectura de confiabilidad en los innumerables detalles que te preocupaban en las instalaciones locales. En lugar de preocuparte por los distintos modos de falla de los componentes, como el enfriamiento y la entrega de energía, puedes planificar en torno a los productos de Google Cloud y sus métricas de confiabilidad indicadas. Estas métricas reflejan el riesgo de interrupción agregado de toda la infraestructura subyacente. De esta manera, puedes enfocarte mucho más en el diseño, la implementación y las operaciones de la aplicación en lugar de la administración de infraestructura.

Google diseña su infraestructura para cumplir con los objetivos de disponibilidad agresivos en función de nuestra vasta experiencia en el desarrollo y la ejecución de centros de datos modernos. Google es uno de los líderes mundiales en el diseño de centros de datos. Cada tecnología de centro de datos, desde la electricidad hasta el enfriamiento y las redes, tiene sus propias redundancias y mitigaciones, incluidos los planes de FMEA. El diseño de los centros de datos de Google balancea estos riesgos variados y presenta a los clientes un nivel coherente y esperado de disponibilidad para los productos de Google Cloud. Google usa su experiencia para modelar la disponibilidad de la arquitectura general del sistema físico y lógico a fin de garantizar que el diseño del centro de datos cumpla con las expectativas. Los ingenieros de Google hacen grandes esfuerzos operativos para garantizar que se cumplan esas expectativas. Es normal que la disponibilidad real exceda nuestros objetivos de diseño por un margen amplio.

Cuando se extraen todos estos riesgos y mitigaciones de los centros de datos en los productos para los usuarios, Google Cloud te evita esas responsabilidades operativas y de diseño. En cambio, puedes enfocarte en la confiabilidad integrada en el diseño de las regiones y las zonas de Google Cloud.

Regiones y zonas

Los productos de Google Cloud se proporcionan en una gran cantidad de regiones y zonas. Las regiones son áreas geográficas independientes que contienen tres zonas o más. Las zonas representan grupos de recursos de procesamiento físicos dentro de una región que tienen un alto grado de independencia entre sí en términos de infraestructura física y lógica. Proporcionan conexiones de red de latencia baja y ancho de banda alto a otras zonas de la misma región. Por ejemplo, la región asia-northeast1 en Japón contiene tres zonas: asia-northeast1-a, asia-northeast1-b y asia-northeast1-c.

Los productos de Google Cloud se dividen en recursos zonales, regionales y multirregionales.

Los recursos zonales se alojan en una sola zona. Una interrupción del servicio en esa zona puede afectar a todos los recursos de esa zona. Por ejemplo, una instancia de Compute Engine se ejecuta en una zona única y especificada. Si una falla de hardware interrumpe el servicio en esa zona, esa instancia de Compute Engine no estará disponible mientras dure la interrupción.

Los recursos regionales se implementan de forma redundante en varias zonas dentro de una región. Esto les brinda mayor confiabilidad en comparación con los recursos zonales.

Los recursos multirregionales se distribuyen dentro de las regiones y entre ellas. En general, los recursos multirregionales son más confiables que los regionales. Sin embargo, a este nivel, los productos deben optimizar la disponibilidad, el rendimiento y la eficiencia de los recursos. Como resultado, es importante comprender las compensaciones de cada producto multirregional que decidas usar. Estas compensaciones se documentan de forma específica para cada producto más adelante en este documento.

Ejemplos de productos de Google Cloud zonales, regionales y multirregionales

Cómo aprovechar las zonas y las regiones para lograr la confiabilidad

Las SRE de Google administran y escalan productos para usuarios globales de alta confiabilidad, como Gmail y Búsqueda, mediante una variedad de técnicas y tecnologías que aprovechan sin problemas la infraestructura de procesamiento en todo el mundo. Esto incluye el redireccionamiento del tráfico desde ubicaciones no disponibles mediante el balanceo de cargas global, la ejecución de varias réplicas en varias ubicaciones en todo el planeta y la replicación de datos en distintos lugares. Estas mismas capacidades están disponibles para los clientes de Google Cloud a través de productos como Cloud Load Balancing, Google Kubernetes Engine y Spanner.

En general, Google Cloud diseña productos a fin de entregar los siguientes niveles de disponibilidad para zonas y regiones:

Recurso Ejemplos Objetivo del diseño de disponibilidad Tiempo de inactividad implícito
Zonal Compute Engine, Persistent Disk 99.9% 8.75 horas al año
Regional Cloud Storage regional, Persistent Disk replicado, GKE regional 99.99% 52 minutos al año

Compara los objetivos del diseño de disponibilidad de Google Cloud con el nivel aceptable de tiempo de inactividad para identificar los recursos apropiados de Google Cloud. Si bien los diseños tradicionales se enfocan en mejorar la disponibilidad a nivel del componente para mejorar la disponibilidad resultante de la aplicación, los modelos de la nube se enfocan en la composición de los componentes a fin de lograr este objetivo. Muchos productos dentro de Google Cloud usan esta técnica. Por ejemplo, Spanner ofrece una base de datos multirregional que compone varias regiones para entregar una disponibilidad del 99.999%.

La composición es importante porque, sin ella, la disponibilidad de la aplicación no puede superar la de los productos de Google Cloud que usas. De hecho, a menos que la aplicación nunca falle, tendrá una disponibilidad menor que los productos de Google Cloud subyacentes. En el resto de esta sección, se muestra cómo puedes usar una composición de productos zonales y regionales para lograr una mayor disponibilidad de la aplicación que la que proporcionan una sola zona o región. En la próxima sección, se proporciona una guía práctica para aplicar estos principios a tus aplicaciones.

Planifica los alcances de interrupción de zonas

Las fallas de infraestructura suelen causar interrupciones del servicio en una sola zona. Dentro de una región, las zonas están diseñadas para minimizar el riesgo de fallas correlacionadas con otras zonas, y una interrupción del servicio en una zona no suele afectar el servicio desde otra zona en la misma región. Una interrupción con alcance a una zona no siempre implica que toda la zona no esté disponible; solo define el límite del incidente. Es posible que una interrupción zonal no tenga ningún efecto tangible en los recursos específicos de esa zona.

Es un caso menos frecuente, pero también es importante tener en cuenta que varias zonas, en algún momento, experimentarán una interrupción correlacionada en una sola región. Cuando dos o más zonas experimentan una interrupción, se aplica la estrategia de alcance de la interrupción regional que aparece a continuación.

Los recursos regionales están diseñados para ser resistentes a las interrupciones zonales mediante la entrega del servicio desde una composición de varias zonas. Si se interrumpe una de las zonas que respaldan un recurso regional, el recurso queda disponible de manera automática desde otra zona. Revisa con cuidado la descripción de la capacidad del producto en el apéndice para obtener más detalles.

Google Cloud solo ofrece algunos recursos zonales, como las máquinas virtuales (VM) de Compute Engine y Persistent Disk. Si planeas usar recursos zonales, tendrás que realizar tu propia composición de recursos mediante el diseño, la compilación y la prueba de la conmutación por error y la recuperación entre recursos zonales ubicados en varias zonas. Estas son algunas de las estrategias:

  • Enrutar con rapidez el tráfico a máquinas virtuales en otra zona mediante Cloud Load Balancing cuando una verificación de estado determina que una zona tiene problemas
  • Usar plantillas de instancias o grupos de instancias administrados de Compute Engine para ejecutar y escalar instancias de VM idénticas en varias zonas
  • Usar Persistent Disk regional para replicar de forma síncrona los datos en otra zona de una región. Consulta Opciones de alta disponibilidad mediante PD regionales para obtener más detalles

Planifica los alcances de interrupción regional

Una interrupción regional es una interrupción del servicio que afecta a más de una zona en una sola región. Estas son interrupciones más grandes y menos frecuentes, y pueden ser consecuencia de desastres naturales o fallas en la infraestructura a gran escala.

Si un producto regional está diseñado para proporcionar una disponibilidad del 99.99%, una interrupción puede traducirse a casi una hora de inactividad para un producto específico cada año. Por lo tanto, es posible que tus aplicaciones esenciales necesiten contar con un plan de DR multirregional si no esta duración de interrupción es inaceptable.

Los recursos multirregionales están diseñados para ser resistentes a las interrupciones regionales mediante la entrega del servicio en varias regiones. Como se describió antes, los productos multirregionales compensan la latencia, la coherencia y el costo. La compensación más común se da entre la replicación de datos síncrona y la replicación asíncrona. La replicación asíncrona ofrece menos latencia al costo de riesgo de pérdida de datos durante una interrupción. Por lo tanto, es importante verificar la descripción de la capacidad del producto en el apéndice para obtener más detalles.

Si quieres usar recursos regionales y seguir siendo resiliente ante las interrupciones regionales, debes diseñar tu propia composición de recursos. Para ello, diseña, compila y prueba la conmutación por error y la recuperación entre los recursos regionales ubicados en varias regiones. Además de las estrategias zonales anteriores, que también puedes aplicar a otras regiones, ten en cuenta lo siguiente:

  • Los recursos regionales deben replicar los datos en una región secundaria, en una opción de almacenamiento multirregional, como Cloud Storage, o en una opción de nube híbrida, como GKE Enterprise.
  • Una vez que tengas una mitigación regional ante interrupciones, pruébala con frecuencia. Si hay algo peor que pensar que eres resistente a una interrupción de una sola región, es descubrir que ese no es el caso cuando ocurre de verdad.

Enfoque de disponibilidad y resi