Situaciones de recuperación ante desastres para aplicaciones

Last reviewed 2023-05-25 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 exploran las situaciones comunes de recuperación ante desastres para las aplicaciones.

La serie consta de estas partes:

Introducción

En este artículo, se enmarcan las situaciones de recuperación ante desastres para las aplicaciones en términos de patrones de recuperación ante desastres que indican la facilidad con que la aplicación se puede recuperar de un desastre. Se usan los conceptos que se discutieron en el artículo sobre los componentes básicos de la DR a fin de describir cómo puedes implementar un plan de DR de extremo a extremo que sea adecuado para tus objetivos de recuperación.

Para comenzar, considera algunas cargas de trabajo típicas a fin de ilustrar cómo tus pensamientos sobre tus objetivos de recuperación y arquitectura tienen una influencia directa en tu plan de recuperación ante desastres.

Cargas de trabajo de procesamiento por lotes

Las cargas de trabajo de procesamiento por lotes no suelen ser esenciales, por lo que no suele ser necesario incurrir en el gasto de diseñar una arquitectura de alta disponibilidad para maximizar el tiempo de actividad; las cargas de trabajo de procesamiento por lotes pueden solucionar las interrupciones. Este tipo de carga de trabajo puede aprovechar los productos rentables, como las instancias de VM interrumpibles, que son instancias que puedes crear y ejecutar a un precio mucho más bajo que las instancias normales (sin embargo, Compute Engine finalizará, o interrumpirá, estas instancias si requiere acceso a esos recursos para otras tareas, y estas finalizarán hasta 24 horas después de iniciarse).

Mediante la implementación de puntos de control regulares como parte de la tarea de procesamiento, el trabajo de procesamiento puede reanudarse desde el punto de falla cuando se inician VM nuevas. Si usas Dataproc, un grupo de instancias administrado controla el proceso de lanzamiento de los nodos trabajadores interrumpibles. Este se puede considerar un patrón templado, en el que hay una breve pausa en la que se espera que las VM de reemplazo continúen el procesamiento.

Sitios de comercio electrónico

En los sitios de comercio electrónico, algunas partes de la aplicación pueden tener valores de RTO más altos. Por ejemplo, la canalización de compra real debe tener una alta disponibilidad, pero el proceso de correo electrónico que envía notificaciones de pedidos a los clientes puede tolerar un retraso de unas pocas horas. Los clientes saben acerca de su compra y aunque esperan un correo electrónico de confirmación, la notificación no es una parte crucial del proceso. Esta es una mezcla de patrones calientes (de compra) y templados/fríos (de notificación).

La parte transaccional de la aplicación necesita un tiempo de actividad alto con un valor de RTO mínimo. Por lo tanto, usas la alta disponibilidad, que maximiza la disponibilidad de esta parte de la aplicación. Este enfoque se puede considerar un patrón caliente.

La situación de comercio electrónico ilustra cómo puedes tener valores de RTO diversos dentro de la misma aplicación.

Transmisión de video por Internet

Una solución de transmisión de video por Internet tiene muchos componentes que deben tener disponibilidad alta, desde la experiencia de búsqueda hasta el proceso real de transmisión de contenido al usuario. Además, el sistema requiere latencia baja a fin de crear una experiencia del usuario satisfactoria. Si algún aspecto de la solución no brinda una experiencia excelente, es malo para el proveedor y también el cliente. Además, en la actualidad, los clientes pueden recurrir a un producto competitivo.

En esta situación, debes tener una arquitectura de alta disponibilidad y se necesitan valores pequeños de RTO. En esta situación se requiere un patrón caliente en la arquitectura de la aplicación para ayudar a garantizar que haya un impacto mínimo en caso de que ocurra un desastre.

Arquitecturas de DR y de alta disponibilidad para la producción local

En esta sección, se analiza cómo implementar tres patrones (frío, templado y caliente) cuando la aplicación se ejecuta de forma local y la solución de DR se encuentra en Google Cloud.

Patrón frío: Recuperación en Google Cloud

En un patrón frío, tienes los recursos mínimos en el proyecto de DR de Google Cloud, que son los suficientes como para habilitar una situación de recuperación. Cuando hay un problema que impide que el entorno de producción ejecute cargas de trabajo de producción, la estrategia de conmutación por error requiere que se inicie una duplicación del entorno de producción en Google Cloud. Luego, los clientes comienzan a usar los servicios del entorno de DR.

En esta sección, examinamos un ejemplo de este patrón. En el ejemplo, Cloud Interconnect se configura con una solución de VPN autoadministrada (que no es de Google Cloud) para proporcionar la conectividad con Google Cloud. Los datos se copian en Cloud Storage como parte del entorno de producción.

Los componentes básicos de la DR son los siguientes:

  • Cloud DNS
  • Cloud Interconnect
  • Solución de VPN autoadministrada
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

En el siguiente diagrama, se ilustra esta arquitectura de ejemplo:

Arquitectura para patrones fríos cuando la producción se encuentra en un entorno local.

En los siguientes pasos, se describe cómo puedes configurar el entorno:

  1. Crea una red de VPC.
  2. Configura la conectividad entre tu red local y la red de Google Cloud.
  3. Crea un depósito de Cloud Storage para la copia de seguridad de los datos.
  4. Crea una clave de cuenta de servicio para una cuenta de servicio dedicada. Este archivo se usa para pasar credenciales a una secuencia de comandos automatizada.

  5. Copia la clave de la cuenta de servicio en la máquina local donde ejecutarás la secuencia de comandos que sube las copias de seguridad de tu base de datos (este podría ser tu servidor de base de datos, pero tus políticas de seguridad tal vez no te permitan instalar un software adicional en tu servidor de base de datos).

  6. Crea una política de IAM para restringir quién puede acceder al depósito y sus objetos. Incluyes la cuenta de servicio creada de manera específica para este propósito. Además, agrega la cuenta de usuario o el grupo a la política para tu operador o administrador del sistema si otorgas a todas estas identidades los permisos relevantes. Si quieres obtener detalles sobre los permisos de acceso a Cloud Storage, consulta Permisos de IAM para Cloud Storage.

  7. Comprueba que puedes subir y descargar archivos en el bucket de destino.

  8. Crea una secuencia de comandos de transferencia de datos.

  9. Crea una tarea programada para ejecutar la secuencia de comandos.

  10. Crea imágenes personalizadas que se configuran para cada servidor en el entorno de producción. Cada imagen debe tener la misma configuración que su equivalente local.

    Como parte de la configuración de la imagen personalizada del servidor de la base de datos, crea una secuencia de comandos de inicio que copiará de forma automática la última copia de seguridad desde un bucket de Cloud Storage a la instancia y luego invocará el proceso de restablecimiento.

  11. Configura Cloud DNS para que apunte a tus servicios web orientados a Internet.

  12. Crea una plantilla de Deployment Manager para crear servidores de aplicaciones en tu red de Google Cloud mediante las imágenes personalizadas configuradas de forma previa. Esta plantilla también debe configurar las reglas de firewall adecuadas obligatorias.

Debes implementar procesos para asegurarte de que las imágenes personalizadas tengan la misma versión de la aplicación que las locales. Asegúrate de incorporar actualizaciones en las imágenes personalizadas como parte de tu ciclo de actualización estándar y de que tu plantilla de Deployment Manager use la imagen personalizada más reciente.

Proceso de conmutación por error y tareas posteriores al reinicio

Si ocurre un desastre, puedes recuperarte en el sistema que se ejecuta en Google Cloud. Para ello, debes iniciar el proceso de recuperación a fin de crear el entorno de recuperación mediante la plantilla de Deployment Manager que crees. Cuando las instancias del entorno de recuperación estén listas para aceptar el tráfico de producción, deberás ajustar el DNS a fin de que apunte al servidor web en Google Cloud.

A continuación, se muestra una secuencia de recuperación típica:

  1. Usa la plantilla de Deployment Manager para crear una implementación en Google Cloud.
  2. Si deseas aplicar la copia de seguridad más reciente de la base de datos de Cloud Storage en el servidor de la base de datos que se ejecuta en Google Cloud, sigue las instrucciones del sistema de la base de datos para recuperar los archivos de copia de seguridad.
  3. Aplica los registros de transacciones más recientes en Cloud Storage.
  4. Prueba que la aplicación funcione según lo esperado mediante la simulación de situaciones de usuario en el entorno recuperado.
  5. Cuando las pruebas tengan éxito, configura Cloud DNS para que apunte al servidor web en Google Cloud. Por ejemplo, puedes usar una dirección IP anycast detrás de un balanceador de cargas de Google Cloud, con varios servidores web detrás del balanceador de cargas.

En el siguiente diagrama, se muestra el entorno recuperado:

Configuración de patrones fríos para la producción en un entorno local.

Cuando el entorno de producción se vuelve a ejecutar de forma local y el entorno puede admitir las cargas de trabajo de producción, puedes revertir los pasos que seguiste a fin de realizar la conmutación por error para el entorno de recuperación de Google Cloud. A continuación, se describe una secuencia típica para volver al entorno de producción:

  1. Realiza una copia de seguridad de la base de datos que se ejecuta en Google Cloud.
  2. Copia el archivo de copia de seguridad en el entorno de producción.
  3. Aplica el archivo de copia de seguridad al sistema de base de datos de producción.
  4. Evita conexiones a la aplicación en Google Cloud. Por ejemplo, evita conexiones al balanceador de cargas global. Desde este punto, tu aplicación no estará disponible hasta que termines de restablecer el entorno de producción.
  5. Copia los archivos de registro de transacciones en el entorno de producción y aplícalos al servidor de la base de datos.
  6. Configura Cloud DNS para que se oriente a tu servicio web local.
  7. Asegúrate de que el proceso que usabas para copiar datos a Cloud Storage funcione según lo esperado.
  8. Borra tu implementación.

Espera templada: Recuperación en Google Cloud

Por lo general, se implementa un patrón templado para mantener los valores de RTO y RPO tan pequeños como sea posible sin el esfuerzo de una configuración de alta disponibilidad completa ni el gasto en ella. Cuanto más bajo sean los valores de RTO y RPO, mayores serán los costos en el proceso de obtener un entorno completamente redundante que pueda procesar el tráfico desde dos entornos. Por lo tanto, la implementación de un patrón templado para tu situación de DR es un buen equilibrio entre el presupuesto y la disponibilidad.

Un ejemplo de este enfoque es usar Cloud Interconnect configurado con una solución de VPN autoadministrada para proporcionar conectividad a Google Cloud. Se ejecuta una aplicación de varios niveles de forma local mientras se usa un paquete de recuperación mínimo en Google Cloud. El paquete de recuperación consta de una instancia del servidor de la base de datos operativa en Google Cloud. Esta instancia se debe ejecutar en todo momento para que pueda recibir transacciones replicadas mediante técnicas de replicación asíncronas o semisíncronas. Para reducir los costos, puedes ejecutar la base de datos en el tipo de máquina más pequeño que sea capaz de ejecutar el servicio de base de datos. Debido a que puedes usar una instancia de larga duración, se aplicarán descuentos por uso continuo.

Los componentes básicos de la recuperación ante desastres son los siguientes:

  • Cloud DNS
  • Cloud Interconnect
  • Solución de VPN autoadministrada
  • Compute Engine
  • Deployment Manager

Las instantáneas de Compute Engine proporcionan una forma de realizar copias de seguridad que puedes revertir a un estado anterior. En este ejemplo, se usan instantáneas porque las páginas web actualizadas y los objetos binarios de las aplicaciones se escriben con frecuencia en la Web de producción y en los servidores de aplicaciones. Estas actualizaciones se replican con frecuencia en las instancias del servidor de aplicaciones y del servidor web de referencia en Google Cloud. Los servidores de referencia no aceptan el tráfico de producción; se usan para crear las instantáneas.

En el siguiente diagrama, se ilustra una arquitectura que implementa este enfoque. Los objetivos de replicación no se muestran en el diagrama.

Arquitectura para patrones templados cuando la producción se encuentra en un entorno local.

En los siguientes pasos, se describe cómo puedes configurar el entorno:

  1. Crea una red de VPC.
  2. Configura la conectividad entre tu red local y la red de Google Cloud.
  3. Replica tus servidores locales en instancias de VM de Google Cloud. Una opción es usar una solución de socios; el método que emplees depende de tus circunstancias.
  4. Crea una imagen personalizada del servidor de tu base de datos en Google Cloud que tenga la misma configuración que el servidor de tu base de datos local.
  5. Crea instantáneas del servidor web y las instancias del servidor de aplicaciones.
  6. Inicia una instancia de base de datos en Google Cloud mediante la imagen personalizada que creaste antes. Usa el tipo de máquina más pequeño que sea capaz de aceptar datos replicados de la base de datos de producción local.
  7. Adjunta discos persistentes a la instancia de base de datos de Google Cloud para los registros de las transacciones y las bases de datos.
  8. Si deseas configurar la replicación entre el servidor de tu base de datos local y el servidor de la base de datos de Google Cloud, sigue las instrucciones para el software de la base de datos.
  9. Configura la marca de eliminación automática en los discos persistentes conectados a la instancia de la base de datos como no-auto-delete.
  10. Configura una tarea programada para crear instantáneas regulares de los discos persistentes de la instancia de base de datos de Google Cloud.
  11. Crea reservas a fin de garantizar la capacidad para tu servidor web y los servidores de aplicaciones según sea necesario.
  12. Prueba el proceso de crear instancias a partir de instantáneas y de tomar instantáneas de los discos persistentes.
  13. Crea instancias del servidor web y el servidor de aplicaciones mediante las instantáneas creadas con anterioridad.
  14. Crea una secuencia de comandos que copie actualizaciones a la aplicación web y el servidor de aplicación siempre que los servidores locales correspondientes estén actualizados. Escribe la secuencia de comandos para crear una instantánea de los servidores actualizados.
  15. Configura Cloud DNS para que se oriente a tu servicio web local accesible desde Internet.

Proceso de conmutación por error y tareas posteriores al reinicio

Para administrar una conmutación por error, por lo general, debes usar tu sistema de supervisión y alertas para invocar un proceso de conmutación por error automatizado. Cuando la aplicación local necesite conmutar por error, configura el sistema de la base de datos en Google Cloud para que pueda aceptar el tráfico de producción. También inicias instancias del servidor web y del servidor de aplicaciones.

En el siguiente diagrama, se muestra la configuración después de una conmutación por error en Google Cloud, que permite que las cargas de trabajo de producción se entreguen desde Google Cloud:

Configuración de patrones templados para la recuperación cuando la producción se encuentra en un entorno local.

A continuación, se muestra una secuencia de recuperación típica:

  1. Cambia el tamaño de la instancia de servidor de base de datos para que pueda controlar las cargas de producción.
  2. Usa el servidor web y las instantáneas de aplicaciones en Google Cloud para crear instancias de aplicaciones y de servidores web nuevas.
  3. Prueba que la aplicación funcione según lo esperado mediante la simulación de situaciones de usuario en el entorno recuperado.
  4. Cuando las pruebas tengan éxito, configura Cloud DNS para que apunte a tu servicio web en Google Cloud.

Cuando el entorno de producción se vuelve a ejecutar de forma local y puede admitir las cargas de trabajo de producción, puedes revertir los pasos que seguiste a fin de realizar la conmutación por error para el entorno de recuperación de Google Cloud. A continuación, se describe una secuencia típica para volver al entorno de producción:

  1. Realiza una copia de seguridad de la base de datos que se ejecuta en Google Cloud.
  2. Copia el archivo de copia de seguridad en el entorno de producción.
  3. Aplica el archivo de copia de seguridad al sistema de base de datos de producción.
  4. Evita conexiones a la aplicación en Google Cloud. Una forma de hacerlo es evitar las conexiones al servidor web mediante la modificación de las reglas de firewall. Desde este punto, tu aplicación no estará disponible hasta que termines de restablecer el entorno de producción.
  5. Copia los archivos de registro de transacciones en el entorno de producción y aplícalos al servidor de la base de datos.
  6. Prueba que la aplicación funcione según lo esperado mediante la simulación de situaciones de usuario en el entorno de producción.
  7. Configura Cloud DNS para que se oriente a tu servicio web local.
  8. Borra las instancias del servidor de aplicaciones y el servidor web que se ejecutan en Google Cloud. Deja en ejecución los servidores de referencia.
  9. Cambia el tamaño del servidor de la base de datos de Google Cloud al tamaño mínimo de instancia que pueda aceptar datos replicados de la base de datos local de producción.
  10. Si deseas configurar la replicación entre el servidor de tu base de datos local y el servidor de la base de datos de Google Cloud, sigue las instrucciones para el software de la base de datos.

Alta disponibilidad caliente en infraestructuras locales y en Google Cloud

Si tienes valores pequeños de RTO y RPO, puedes alcanzarlos solo si ejecutas una alta disponibilidad en tu entorno de producción y en Google Cloud al mismo tiempo. Este enfoque te proporciona un patrón caliente, ya que la infraestructura local y Google Cloud entregan tráfico de producción.

La principal diferencia con el patrón templado es que los recursos en ambos entornos entregan tráfico de producción y se ejecutan en modo de producción.

Los componentes básicos de la recuperación ante desastres son los siguientes:

  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • Grupos de instancias administrados
  • Cloud Monitoring
  • Cloud Load Balancing

En el siguiente diagrama, se ilustra esta arquitectura de ejemplo. Si implementas esta arquitectura, tienes un plan de DR que requiere una intervención mínima en caso de que ocurra un desastre.

Arquitectura para patrones calientes cuando la producción se encuentra en un entorno local.

En los siguientes pasos, se describe cómo puedes configurar el entorno:

  1. Crea una red de VPC.
  2. Configura la conectividad entre la red local y la red de Google Cloud.
  3. Crea imágenes personalizadas en Google Cloud que estén configuradas para cada servidor del entorno de producción local. Cada imagen de Google Cloud debe tener la misma configuración que su equivalente en el entorno local.

  4. Si deseas configurar la replicación entre el servidor de tu base de datos local y el servidor de la base de datos de Google Cloud, sigue las instrucciones para el software de la base de datos.

    Muchos sistemas de base de datos solo permiten una única instancia de base de datos que admita operaciones de escritura cuando configuras la replicación. Por lo tanto, tal vez debas asegurarte de que una de las réplicas de la base de datos actúe como un servidor de solo lectura.

  5. Crea plantillas de instancias individuales que usan las imágenes para los servidores de aplicaciones y los servidores web.

  6. Configura los grupos de instancias regionales administrados para los servidores de aplicaciones y los servidores web.

  7. Configura las verificaciones de estado mediante Cloud Monitoring.

  8. Configura el balanceo de cargas con los grupos de instancias regionales administrados que se configuraron antes.

  9. Configura una tarea programada para crear instantáneas regulares de los discos persistentes.

  10. Configura un servicio de DNS para distribuir el tráfico entre tu entorno local y el entorno de Google Cloud.

Con este enfoque híbrido, necesitas usar un servicio DNS que admita el enrutamiento ponderado a los dos entornos de producción para que puedas entregar la misma aplicación desde ambos.

Debes diseñar el sistema para las fallas que pueden ocurrir solo en una parte de un entorno (fallas parciales). En ese caso, el tráfico se debe redirigir al servicio equivalente en el otro entorno de copia de seguridad. Por ejemplo, si los servidores web locales no están disponibles, puedes inhabilitar el enrutamiento de DNS a ese entorno. Si tu servicio DNS admite las verificaciones de estado, esto ocurrirá de manera automática cuando la verificación de estado determine que no se puede acceder a los servidores web en uno de los entornos.

Si usas un sistema de base de datos que solo permite una única instancia que admite operaciones de escritura, en muchos casos, el sistema de la base de datos promoverá de forma automática que la réplica de solo lectura sea la principal de escritura cuando la seña de monitoreo de funcionamiento entre la base de datos original y la réplica de lectura pierde el contacto. Asegúrate de comprender este aspecto de la replicación de tu base de datos en caso de que necesites intervenir después de un desastre.

Debes implementar procesos para asegurarte de que las imágenes de VM personalizadas de Google Cloud tengan la misma versión de la aplicación que las versiones del entorno local. Incorpora actualizaciones a las imágenes personalizadas como parte del ciclo de actualización estándar y asegúrate de que tu plantilla de Deployment Manager use la imagen personalizada más reciente.

Proceso de conmutación por error y tareas posteriores al reinicio

En la configuración descrita aquí para una situación caliente, un desastre significa que uno de los dos entornos no está disponible. El proceso de conmutación por error no es igual que en las situaciones templadas o frías, en las que necesitas mover los datos o el procesamiento al segundo entorno. Sin embargo, es posible que debas controlar los siguientes cambios de configuración:

  • Si tu servicio DNS no redirige de manera automática el tráfico en función de una falla en la verificación de estado, necesitas reconfigurar de forma manual el enrutamiento DNS para enviar tráfico al sistema que todavía esté activo.
  • Si el sistema de tu base de datos no promueve de forma automática una réplica de solo lectura para que admita operaciones de escritura en caso de fallas, debes intervenir a fin de asegurarte de que se promueva la réplica.

Cuando el segundo entorno se ejecuta de nuevo y puede controlar el tráfico de producción, debes volver a sincronizar las bases de datos. Debido a que ambos entornos admiten cargas de trabajo de producción, no tienes que realizar ninguna otra acción para modificar cuál es la base de datos principal. Una vez que se sincronizan las bases de datos, puedes permitir que el tráfico de producción se distribuya de nuevo en ambos entornos si estableces la configuración del DNS.

Arquitecturas de DR y alta disponibilidad para la producción en Google Cloud

Cuando diseñas la arquitectura de la aplicación para la carga de trabajo de producción en Google Cloud, las características de alta disponibilidad de la plataforma influyen de forma directa en tu arquitectura de DR.

Frío: Servidor de aplicaciones recuperable

En una situación de conmutación por error en frío en la que necesitas una sola instancia activa de servidor, solo una instancia debe escribir en el disco. En un entorno local, a menudo usas un clúster activo/pasivo. Cuando ejecutas un entorno de producción en Google Cloud, puedes crear una VM en un grupo de instancias administrado que solo ejecute una instancia.

Los componentes básicos de la DR son los siguientes:

  • Compute Engine
  • Grupos de instancias administrados

Esta situación de conmutación por error en frío se muestra en la siguiente imagen de arquitectura de ejemplo:

Configuración del patrón frío para la recuperación cuando la producción se encuentra en Google Cloud.

Para obtener una descripción general completa sobre cómo implementar esta situación de ejemplo y probar la recuperación ante fallas, consulta Implementa un servidor web recuperable en frío con instantáneas de discos persistentes.

En los siguientes pasos, se describe cómo configurar esta situación de conmutación por error en frío:

  1. Crea una red de VPC.
  2. Crea una imagen de VM personalizada que se configure con el servicio web de tu aplicación.
    1. Configura la VM para que los datos que el servicio de la aplicación procesa se escriban en un disco persistente conectado.
  3. Crea una instantánea desde el disco persistente adjunto.
  4. Crea una plantilla de instancias que haga referencia a la imagen de VM personalizada del servidor web.
    1. Configura una secuencia de comandos de inicio a fin de crear un disco persistente a partir de la última instantánea y para activar el disco. Esta secuencia de comandos debe poder obtener la última instantánea del disco.
  5. Crea un grupo de instancias administrado y verificaciones de estado con un tamaño de destino que haga referencia a la plantilla de instancias.
  6. Crea una tarea programada para crear instantáneas normales del disco persistente.
  7. Configura un balanceador de cargas de aplicaciones externo.
  8. Configura alertas mediante Cloud Monitoring para enviar una alerta cuando se produce una falla en el servicio.

En esta situación de conmutación por error en frío, se aprovechan algunas de las características de la alta disponibilidad en Google Cloud. Si una VM falla, el grupo de instancias administrado intenta volver a crearla de forma automática. No es necesario que inicies este paso de conmutación por error. El balanceador de cargas de aplicaciones externo se asegura de que, incluso cuando se necesita una VM de reemplazo, se use la misma dirección IP frente al servidor de aplicaciones. La plantilla de instancias y la imagen personalizada garantizan que la VM de reemplazo esté configurada de manera idéntica a la instancia que reemplaza.

La última instantánea determina tu RPO. El valor de RPO será más pequeño mientras más instantáneas tomes.

El grupo de instancias administrado proporciona alta disponibilidad en profundidad. El grupo de instancias administrado proporciona formas de reaccionar ante fallas a nivel de la aplicación o de la VM. No intervengas de forma manual si se produce alguna de esas situaciones. Un tamaño de destino de uno garantiza que solo tengas una instancia activa que se ejecute en el grupo de instancias administrado y entregue tráfico.

Los discos persistentes son zonales, por lo que debes tomar instantáneas para volver a crear discos si hay una falla zonal. Las instantáneas también están disponibles en todas las regiones, lo que te permite restablecer un disco en una región diferente, de manera similar a si lo restableces en la misma región.

En el caso improbable de una falla zonal, debes intervenir de forma manual para realizar la recuperación, como se describe en la siguiente sección.

Proceso de conmutación por error

Si una VM falla, el grupo de instancias administrado intenta volver a crear la VM en la misma zona de forma automática. La secuencia de comandos de inicio en la plantilla de instancias crea un disco persistente a partir de la última instantánea y lo conecta a la nueva VM.

Sin embargo, un grupo de instancias administrado con tamaño de uno no se recupera si hay una falla de zona. En el caso en el que una zona falla, debes reaccionar a la alerta de Cloud Monitoring, o a otra plataforma de supervisión, cuando el servicio falla y crear de forma manual un grupo de instancias en otra zona.

Una variación de esta configuración es usar discos persistentes regionales en lugar de discos persistentes zonales. Con este enfoque, no necesitas usar instantáneas para restablecer el disco persistente como parte del paso de recuperación. Sin embargo, esta variación consume el doble de almacenamiento y tienes que hacer un presupuesto para eso. Para implementar esta situación alternativa y probar la recuperación ante fallas, consulta Implementa un servidor web recuperable en frío con discos persistentes regionales.

El enfoque que elijas depende de tu presupuesto y los valores de RTO y RPO.

Templado: Conmutación por error de sitios estáticos

En caso de que las instancias de Compute Engine fallen, puedes reducir la interrupción del servicio si tienes un sitio estático en función de Cloud Storage en espera. El uso de un sitio estático es una opción cuando tu aplicación web es, en gran parte, estática. En esta situación, la aplicación principal se ejecuta en instancias de Compute Engine. Estas instancias se agrupan en grupos de instancias administrados que sirven como servicios de backend para un balanceador de cargas HTTPS. El balanceador de cargas HTTP dirige el tráfico entrante a las instancias de acuerdo con la configuración del balanceador de cargas, la configuración de cada grupo de instancias y el estado de cada instancia.

Los componentes básicos de la recuperación ante desastres son los siguientes:

  • Compute Engine
  • Cloud Storage
  • Cloud Load Balancing
  • Cloud DNS

En el siguiente diagrama, se ilustra esta arquitectura de ejemplo:

Arquitectura de una conmutación por error templada para un sitio estático cuando la producción se encuentra en Google Cloud.

Para obtener una descripción general completa de cómo implementar esta situación de ejemplo y probar la recuperación ante fallas, consulta Implementa un servidor web recuperable en caliente con Cloud DNS con Compute Engine y Cloud Storage.

En los siguientes pasos, se describe cómo configurar esta situación:

  1. Crea una red de VPC.
  2. Crea una imagen personalizada que se configure con el servicio web de aplicaciones.
  3. Crea una plantilla de instancias que use la imagen para los servidores web.
  4. Configura un grupo de instancias administrado para los servidores web.
  5. Configura las verificaciones de estado mediante Monitoring.
  6. Configura el balanceo de cargas mediante los grupos de instancias administrados que configuraste con anterioridad.
  7. Crea un sitio estático en función de Cloud Storage.

En la configuración de producción, Cloud DNS está configurado para que apunte a esta aplicación principal y el sitio estático en espera permanece inactivo. Si la aplicación de Compute Engine falla, configurarás Cloud DNS para que apunte a este sitio estático.

Proceso de conmutación por error

Si el servidor o los servidores de la aplicación fallan, la secuencia de recuperación consiste en configurar Cloud DNS para que apunte a tu sitio web estático. En el siguiente diagrama, se muestra la arquitectura en su modo de recuperación:

Configuración después de una conmutación por error a un sitio estático cuando la producción se encuentra en Google Cloud.

Cuando las instancias de Compute Engine de la aplicación se ejecutan de nuevo y pueden admitir cargas de trabajo de producción, reviertes el paso de recuperación: configuras Cloud DNS para que apunte al balanceador de cargas que prioriza las instancias.

Si quieres obtener un enfoque alternativo que use un balanceador de cargas de aplicaciones externo en lugar de Cloud DNS para controlar la conmutación por error, consulta Implementa un servidor web recuperable en caliente con Compute Engine y Cloud Storage. Este patrón es útil si no tienes o no quieres usar Cloud DNS.

Caliente: Aplicación web de alta disponibilidad

Cuando tu entorno de producción se ejecuta en Google Cloud, un patrón caliente debe establecer una implementación de alta disponibilidad bien diseñada.

Los componentes básicos de la DR son los siguientes:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

En el siguiente diagrama, se ilustra esta arquitectura de ejemplo:

Arquitectura de un patrón caliente cuando la producción se encuentra en Google Cloud.

En esta situación, se aprovechan las características de alta disponibilidad de Google Cloud. No es necesario que inicies ningún paso de conmutación por error, ya que ocurrirán de forma automática si ocurre un desastre.

Como se muestra en el diagrama, la arquitectura usa un grupo de instancias regional administrado junto con el balanceo de cargas global y Cloud SQL. En el ejemplo, se usa un grupo de instancias regional administrado, por lo que las instancias se distribuyen en tres zonas.

Con este enfoque, obtienes alta disponibilidad en profundidad. Los grupos de instancias regionales administrados proporcionan mecanismos para reaccionar a las fallas a nivel de las aplicaciones, las instancias o la zona. No tienes que intervenir de forma manual si ocurre alguna de esas situaciones.

Para abordar la recuperación a nivel de las aplicaciones, como parte de la configuración del grupo de instancias administrado, estableces verificaciones de estado de HTTP que verifican que los servicios se ejecuten de forma correcta en las instancias de ese grupo. Si una verificación de estado determina que un servicio falló en una instancia, el grupo vuelve a crear de forma automática esa instancia.

Para ver pasos detallados sobre una forma de configurar una aplicación web de alta disponibilidad en Google Cloud, consulta Aplicación web escalable y resiliente en Google Cloud.

¿Qué sigue?