Situaciones de recuperación tras fallos con las aplicaciones

Last reviewed 2024-08-05 UTC

Este documento forma parte de una serie sobre la recuperación tras fallos en Google Cloud. En esta parte se analizan las situaciones habituales de recuperación tras fallos de las aplicaciones.

La serie consta de las siguientes partes:

Introducción

En este documento se describen los escenarios de recuperación tras fallos de las aplicaciones en términos de patrones de recuperación tras fallos, que indican la facilidad con la que la aplicación puede recuperarse de un desastre. En él se usan los conceptos que se explican en el documento Elementos básicos de la recuperación tras fallos para describir cómo puedes implementar un plan de recuperación tras fallos integral adecuado para tus objetivos de recuperación.

Para empezar, vamos a analizar algunas cargas de trabajo típicas para ilustrar cómo influyen directamente los objetivos de recuperación y la arquitectura 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 críticas, por lo que normalmente no es necesario incurrir en el coste de diseñar una arquitectura de alta disponibilidad (HA) para maximizar el tiempo de actividad. En general, las cargas de trabajo de procesamiento por lotes pueden hacer frente a las interrupciones. Este tipo de carga de trabajo puede aprovechar productos rentables, como las máquinas virtuales de acceso puntual y las instancias de máquina virtual interrumpibles, que son instancias que puedes crear y ejecutar a un precio mucho más bajo que las instancias normales. Sin embargo, Compute Engine puede detener o eliminar de forma preventiva estas instancias si necesita acceder a esos recursos para otras tareas.

Al implementar puntos de control periódicos como parte de la tarea de procesamiento, el trabajo de procesamiento puede reanudarse desde el punto de fallo cuando se lancen nuevas VMs. Si usas Dataproc, el proceso de iniciar nodos de trabajo preemptivos se gestiona mediante un grupo de instancias gestionado. Se puede considerar un patrón de espera, en el que hay una breve pausa mientras se espera a que las máquinas virtuales de sustitución continúen con 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 horas. Los clientes conocen su compra, por lo que, aunque esperan recibir un correo de confirmación, la notificación no es una parte crucial del proceso. Se trata de una combinación de patrones de calor (compra), templado y frío (notificación).

La parte transaccional de la aplicación necesita un tiempo de actividad elevado 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 de alta frecuencia.

El caso práctico de comercio electrónico muestra cómo se pueden tener valores de RTO diferentes en la misma aplicación.

Stream de vídeo

Una solución de streaming de vídeo tiene muchos componentes que deben tener una alta disponibilidad, desde la experiencia de búsqueda hasta el proceso real de streaming de contenido al usuario. Además, el sistema requiere una latencia baja para ofrecer una experiencia de usuario satisfactoria. Si algún aspecto de la solución no ofrece una experiencia excelente, perjudica tanto al proveedor como al cliente. Además, los clientes pueden recurrir a un producto de la competencia.

En este caso, es imprescindible contar con una arquitectura de alta disponibilidad y se necesitan valores de RTO pequeños. Este escenario requiere un patrón activo en toda la arquitectura de la aplicación para asegurar que el impacto sea mínimo en caso de desastre.

Arquitecturas de recuperación tras fallos y alta disponibilidad para producción local

En esta sección se explica cómo implementar tres patrones (frío, templado y caliente) cuando tu aplicación se ejecuta de forma local y tu solución de recuperación ante desastres se encuentra enGoogle Cloud.

Patrón de frío: recuperación a las Google Cloud

En un patrón de frío, tienes recursos mínimos en el proyecto de recuperación ante desastres Google Cloud, solo los suficientes para habilitar un escenario 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 réplica del entorno de producción en Google Cloud. A continuación, los clientes empiezan a usar los servicios del entorno de recuperación ante desastres.

En esta sección, analizaremos un ejemplo de este patrón. En el ejemplo, Cloud Interconnect se configura con una solución VPN autogestionada (noGoogle Cloud) para proporcionar conectividad a Google Cloud. Los datos se copian en Cloud Storage como parte del entorno de producción.

Este patrón usa los siguientes elementos básicos de recuperación ante desastres:

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

En el siguiente diagrama se muestra esta arquitectura de ejemplo:

Arquitectura para el patrón de frío cuando la producción es local

En los siguientes pasos se explica cómo configurar el entorno:

  1. Crea una red VPC.
  2. Configura la conectividad entre tu red on-premise y la red Google Cloud .
  3. Crea un segmento de Cloud Storage como destino de tu copia de seguridad de datos.
  4. Crear cuentas de servicio
  5. Crea una política de gestión de identidades y accesos (IAM) para restringir quién puede acceder al segmento y a sus objetos. Incluye la cuenta de servicio creada específicamente para este fin. También puedes añadir la cuenta de usuario o el grupo a la política de tu operador o administrador del sistema, lo que concederá a todas estas identidades los permisos pertinentes. Para obtener información sobre los permisos de acceso a Cloud Storage, consulta Permisos de gestión de identidades y accesos para Cloud Storage.
  6. Usa la suplantación de identidad de cuenta de servicio para permitir que tu usuario local de Google Cloud(o cuenta de servicio) suplante la identidad de la cuenta de servicio que has creado anteriormente. También puedes crear un usuario nuevo específicamente para este fin.
  7. Comprueba que puedes subir y descargar archivos en el segmento de destino.
  8. Crea una secuencia de comandos de transferencia de datos.
  9. Crea una tarea programada para ejecutar la secuencia de comandos. Puedes usar herramientas como Linux crontab y el Programador de tareas de Windows.

  10. Crea imágenes personalizadas configuradas para cada servidor del 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 copie automáticamente la copia de seguridad más reciente de un contenedor de Cloud Storage en la instancia y, a continuación, invoque el proceso de restauración.

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

  12. Crea una plantilla de Deployment Manager que cree servidores de aplicaciones en tu red Google Cloud con las imágenes personalizadas que hayas configurado anteriormente. Esta plantilla también debe configurar las reglas de cortafuegos necesarias.

Debe implementar procesos para asegurarse de que las imágenes personalizadas tengan la misma versión de la aplicación que la versión local. Asegúrate de incorporar las actualizaciones a las imágenes personalizadas como parte de tu ciclo de actualización estándar y de que tu plantilla de Deployment Manager utilice la imagen personalizada más reciente.

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

Si se produce un desastre, puedes restaurar el sistema que se ejecuta enGoogle Cloud. Para ello, inicia el proceso de recuperación para crear el entorno de recuperación con la plantilla de Deployment Manager que crees. Cuando las instancias del entorno de recuperación estén listas para aceptar tráfico de producción, ajusta el DNS para que apunte al servidor web deGoogle Cloud.

Una secuencia de recuperación habitual es la siguiente:

  1. Usa la plantilla de Deployment Manager para crear un despliegue enGoogle Cloud.
  2. Aplica la copia de seguridad de la base de datos más reciente de Cloud Storage al servidor de bases de datos que se ejecuta en Google Cloud siguiendo las instrucciones de tu sistema de bases de datos para recuperar archivos de copia de seguridad.
  3. Aplica los registros de transacciones más recientes en Cloud Storage.
  4. Prueba que la aplicación funcione correctamente simulando escenarios de usuario en el entorno recuperado.
  5. Si las pruebas se realizan correctamente, configura Cloud DNS para que dirija al servidor web de Google Cloud. Por ejemplo, puedes usar una dirección IP anycast detrás de un Google Cloud balanceador de carga, con varios servidores web detrás del balanceador de carga.

En el siguiente diagrama se muestra el entorno recuperado:

Configuración de la copia de seguridad en frío para la recuperación cuando la producción es local

Cuando el entorno de producción vuelva a ejecutarse en las instalaciones y pueda admitir cargas de trabajo de producción, invierte los pasos que has seguido para conmutar por error al entorno de recuperación Google Cloud . La secuencia habitual para volver al entorno de producción es la siguiente:

  1. Crea una copia de seguridad de la base de datos que se ejecuta en Google Cloud.
  2. Copia el archivo de copia de seguridad en tu entorno de producción.
  3. Aplica el archivo de copia de seguridad a tu sistema de base de datos de producción.
  4. Evita las conexiones a la aplicación en Google Cloud. Por ejemplo, impide las conexiones al balanceador de carga global. A partir de este momento, tu aplicación no estará disponible hasta que termines de restaurar 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 apunte a tu servicio web local.
  7. Comprueba que el proceso que tenías para copiar datos en Cloud Storage funciona correctamente.
  8. Elimina tu implementación.

Standby activo: recuperación a Google Cloud

Un patrón de espera activa se suele implementar para mantener los valores de RTO y RPO lo más pequeños posible sin el esfuerzo y el gasto de una configuración de alta disponibilidad completa. Cuanto menor sea el valor de RTO y RPO, mayores serán los costes, ya que te acercarás a un entorno totalmente redundante que puede servir tráfico desde dos entornos. Por lo tanto, implementar un patrón de espera activa para tu escenario de recuperación tras desastres es un buen equilibrio entre presupuesto y disponibilidad.

Un ejemplo de este enfoque es usar Cloud Interconnect configurado con una solución de VPN autogestionada para proporcionar conectividad a Google Cloud. Una aplicación multinivel se ejecuta de forma local y usa un conjunto de recuperación mínimo en Google Cloud. El conjunto de recuperación consta de una instancia de servidor de base de datos operativa en Google Cloud. Esta instancia debe ejecutarse en todo momento para poder recibir transacciones replicadas mediante técnicas de replicación asíncronas o semisíncronas. Para reducir los costes, puedes ejecutar la base de datos en el tipo de máquina más pequeño que pueda ejecutar el servicio de base de datos. Como puedes usar una instancia de larga duración, se aplicarán descuentos por uso continuado.

Este patrón usa los siguientes elementos básicos de recuperación ante desastres:

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

Las capturas de Compute Engine te permiten crear copias de seguridad que puedes restaurar a un estado anterior. En este ejemplo se usan las instantáneas porque las páginas web y los archivos binarios de las aplicaciones actualizados se escriben con frecuencia en la web de producción y en los servidores de aplicaciones. Estas actualizaciones se replican periódicamente en las instancias del servidor web y del servidor de aplicaciones de referencia en Google Cloud. Los servidores de referencia no aceptan tráfico de producción, sino que se usan para crear las capturas.

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

Arquitectura de un patrón cálido cuando la producción es local

En los siguientes pasos se explica cómo configurar el entorno:

  1. Crea una red VPC.
  2. Configura la conectividad entre tu red on-premise y la red Google Cloud .
  3. Replica tus servidores on-premise en Google Cloud instancias de máquina virtual. Una opción es usar una solución de partner. El método que emplees dependerá de tus circunstancias.
  4. Crea una imagen personalizada de tu servidor de bases de datos en Google Cloud que tenga la misma configuración que tu servidor de bases de datos local.
  5. Crea instantáneas de las instancias del servidor web y del servidor de aplicaciones.
  6. Inicia una instancia de base de datos en Google Cloud con la imagen personalizada que has creado anteriormente. Usa el tipo de máquina más pequeño que pueda aceptar datos replicados de la base de datos de producción local.
  7. Adjunta discos persistentes a la instancia de base de datos para las bases de datos y los registros de transacciones. Google Cloud
  8. Configura la replicación entre tu servidor de base de datos local y el servidor de base de datos de Google Cloud siguiendo las instrucciones de tu software de base de datos.
  9. Asigna el valor no-auto-delete a la marca auto delete de los discos persistentes vinculados a la instancia de base de datos.
  10. Configura una tarea programada para crear capturas periódicas de los discos persistentes de la instancia de base de datos en Google Cloud.
  11. Crea reservas para asegurar la capacidad de tu servidor web y de tus servidores de aplicaciones según sea necesario.
  12. Prueba el proceso de creación de instancias a partir de capturas y de creación de capturas de los discos persistentes.
  13. Crea instancias del servidor web y del servidor de aplicaciones con las instantáneas que has creado antes.
  14. Crea una secuencia de comandos que copie las actualizaciones en la aplicación web y en el servidor de aplicaciones cada vez que se actualicen los servidores locales correspondientes. Escribe la secuencia de comandos para crear una instantánea de los servidores actualizados.
  15. Configura Cloud DNS para que dirija a tu servicio web accesible a través de Internet en las instalaciones.

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

Para gestionar una conmutación por error, normalmente se usa el sistema de monitorización y alertas para invocar un proceso de conmutación por error automatizado. Cuando la aplicación local necesita conmutar por error, configura el sistema de 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 la conmutación por error aGoogle Cloud , lo que permite que las cargas de trabajo de producción se sirvan desdeGoogle Cloud:

Configuración de un patrón de espera para la recuperación cuando la producción es local

Una secuencia de recuperación habitual es la siguiente:

  1. Cambia el tamaño de la instancia del servidor de bases de datos para que pueda gestionar las cargas de producción.
  2. Usa las copias de servidor web y de aplicación en Google Cloud para crear nuevas instancias de servidor web y de aplicación.
  3. Prueba que la aplicación funcione correctamente simulando escenarios de usuario en el entorno recuperado.
  4. Si las pruebas se realizan correctamente, configura Cloud DNS para que apunte a tu servicio web en Google Cloud.

Cuando el entorno de producción vuelva a ejecutarse en las instalaciones y pueda admitir cargas de trabajo de producción, invierte los pasos que has seguido para conmutar por error al entorno de recuperación Google Cloud . Una secuencia habitual para volver al entorno de producción es la siguiente:

  1. Crea una copia de seguridad de la base de datos que se ejecuta en Google Cloud.
  2. Copia el archivo de copia de seguridad en tu entorno de producción.
  3. Aplica el archivo de copia de seguridad a tu sistema de base de datos de producción.
  4. Evita las conexiones a la aplicación en Google Cloud. Una forma de hacerlo es impedir las conexiones al servidor web modificando las reglas del cortafuegos. A partir de este momento, tu aplicación no estará disponible hasta que termines de restaurar 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 funciona correctamente simulando situaciones de usuario en el entorno de producción.
  7. Configura Cloud DNS para que apunte a tu servicio web local.
  8. Elimina las instancias del servidor web y del servidor de aplicaciones que se estén ejecutando en Google Cloud. Deja los servidores de referencia en funcionamiento.
  9. Cambia el tamaño del servidor de bases de datos en Google Cloud al tamaño mínimo de instancia que pueda aceptar datos replicados de la base de datos de producción local.
  10. Configura la replicación entre tu servidor de base de datos local y el servidor de base de datos de Google Cloud siguiendo las instrucciones de tu software de base de datos.

Alta disponibilidad activa en entornos locales y en Google Cloud

Si tienes valores de RTO y RPO pequeños, solo puedes conseguirlos ejecutando la alta disponibilidad en tu entorno de producción y Google Cloud simultáneamente. Este enfoque te proporciona un patrón activo, ya que tanto el entorno local como Google Cloud sirven tráfico de producción.

La diferencia principal con respecto al patrón de actualización en caliente es que los recursos de ambos entornos se ejecutan en modo de producción y sirven tráfico de producción.

Este patrón usa los siguientes elementos básicos de recuperación ante desastres:

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

En el siguiente diagrama se muestra esta arquitectura de ejemplo. Al implementar esta arquitectura, tendrás un plan de recuperación ante desastres que requiere una intervención mínima en caso de desastre.

Arquitectura de un patrón activo cuando la producción es local

En los siguientes pasos se explica cómo configurar el entorno:

  1. Crea una red VPC.
  2. Configura la conectividad entre tu red on-premise y tu 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 debe tener la misma configuración que su equivalente local. Google Cloud

  4. Configura la replicación entre tu servidor de base de datos local y el servidor de base de datos de Google Cloud siguiendo las instrucciones de tu software de base de datos.

    Muchos sistemas de bases de datos solo permiten una instancia de base de datos grabable cuando se configura la replicación. Por lo tanto, es posible que tengas que asegurarte de que una de las réplicas de la base de datos actúe como servidor de solo lectura.

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

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

  7. Configura comprobaciones del estado con Cloud Monitoring.

  8. Configura el balanceo de carga con los grupos de instancias gestionados regionales que has configurado anteriormente.

  9. Configura una tarea programada para crear capturas periódicas de los discos persistentes.

  10. Configura un servicio DNS para distribuir el tráfico entre tu entorno on-premise y el entorno Google Cloud .

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

Debes diseñar el sistema para los fallos que puedan producirse solo en una parte de un entorno (fallos parciales). En ese caso, el tráfico se debe redirigir al servicio equivalente del otro entorno de copia de seguridad. Por ejemplo, si los servidores web locales dejan de estar disponibles, puedes inhabilitar el enrutamiento de DNS a ese entorno. Si tu servicio DNS admite comprobaciones de estado, estas se realizarán automáticamente cuando la comprobación de estado determine que no se puede acceder a los servidores web de uno de los entornos.

Si usas un sistema de base de datos que solo permite una instancia de escritura, en muchos casos, el sistema de base de datos ascenderá automáticamente la réplica de solo lectura a principal de escritura cuando se pierda el contacto entre la base de datos de escritura original y la réplica de lectura. Asegúrate de que entiendes este aspecto de la replicación de tu base de datos por si tienes que intervenir después de un desastre.

Debes implementar procesos para asegurarte de que las imágenes de VM personalizadas deGoogle Cloud tengan la misma versión de la aplicación que las versiones on‐premise. Incorpora las actualizaciones a las imágenes personalizadas como parte de tu 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 en este artículo para un escenario activo, un desastre significa que uno de los dos entornos no está disponible. No hay ningún proceso de conmutación por error como en los casos de recuperación ante desastres en caliente o en frío, en los que tienes que mover los datos o el procesamiento al segundo entorno. Sin embargo, es posible que tengas que gestionar los siguientes cambios de configuración:

  • Si tu servicio DNS no redirige automáticamente el tráfico en función de un error de comprobación de estado, debes configurar manualmente el enrutamiento DNS para enviar el tráfico al sistema que siga activo.
  • Si tu sistema de base de datos no convierte automáticamente una réplica de solo lectura en la réplica principal de escritura en caso de fallo, debes intervenir para asegurarte de que la réplica se convierta en la principal.

Cuando el segundo entorno vuelva a estar en funcionamiento y pueda gestionar el tráfico de producción, deberás volver a sincronizar las bases de datos. Como ambos entornos admiten cargas de trabajo de producción, no tienes que hacer nada más para cambiar la base de datos principal. Una vez que las bases de datos se hayan sincronizado, puedes volver a permitir que el tráfico de producción se distribuya entre ambos entornos ajustando la configuración de DNS.

Arquitecturas de recuperación tras fallos y alta disponibilidad para la producción en Google Cloud

Cuando diseñes la arquitectura de tu aplicación para la carga de trabajo de producción enGoogle Cloud, las funciones de alta disponibilidad de la plataforma influirán directamente en tu arquitectura de recuperación tras desastres.

El Servicio de Backup y DR es una solución centralizada y nativa de la nube para crear copias de seguridad y recuperar cargas de trabajo en la nube y en entornos híbridos. Ofrece una recuperación de datos rápida y facilita la reanudación de las operaciones empresariales esenciales.

Para obtener más información sobre cómo usar el servicio de Backup y DR en escenarios de aplicaciones enGoogle Cloud, consulta los siguientes recursos:

Frío: servidor de aplicaciones recuperable

En un escenario de conmutación por error en frío en el que necesites una sola instancia de servidor activa, solo una instancia debe escribir en el disco. En un entorno local, a menudo se usa un clúster activo/pasivo. Si ejecutas un entorno de producción enGoogle Cloud, puedes crear una VM en un grupo de instancias gestionado que solo ejecute una instancia.

Este patrón usa los siguientes elementos básicos de recuperación ante desastres:

  • Compute Engine
  • Grupos de instancias administradas

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

Configuración del patrón de frío para la recuperación cuando la producción está en Google Cloud

En los pasos que se indican a continuación se explica cómo configurar este escenario de conmutación por error en frío:

  1. Crea una red VPC.
  2. Crea una imagen de VM personalizada que esté configurada con el servicio web de tu aplicación.
    1. Configura la VM para que los datos procesados por el servicio de aplicación se escriban en un disco persistente conectado.
  3. Crea una captura del disco persistente conectado.
  4. Crea una plantilla de instancia que haga referencia a la imagen de VM personalizada del servidor web.
    1. Configura una secuencia de comandos de inicio para crear un disco persistente a partir de la última captura y montar el disco. Este script debe poder obtener la última captura del disco.
  5. Crea un grupo de instancias gestionado y comprobaciones del estado con un tamaño objetivo de uno que haga referencia a la plantilla de instancia.
  6. Crea una tarea programada para crear capturas periódicas del disco persistente.
  7. Configura un balanceador de carga de aplicación externo.
  8. Configura alertas con Cloud Monitoring para que se envíe una alerta cuando falle el servicio.

En este caso de conmutación por error en frío, se aprovechan algunas de las funciones de alta disponibilidad disponibles en Google Cloud. Si una VM falla, el grupo de instancias gestionadas intenta recrearla automáticamente. No tienes que iniciar este paso de conmutación por error. El balanceador de carga de aplicaciones externo se asegura de que, aunque se necesite una máquina virtual de sustitución, se utilice la misma dirección IP delante del servidor de aplicaciones. La plantilla de instancia y la imagen personalizada aseguran que la VM de sustitución se configure de forma idéntica a la instancia que sustituye.

El RPO se determina en función de la última instantánea tomada. Cuanto más a menudo hagas instantáneas, menor será el valor del RPO.

El grupo de instancias gestionado proporciona alta disponibilidad en profundidad. El grupo de instancias gestionadas proporciona formas de reaccionar ante fallos a nivel de aplicación o de máquina virtual. No tienes que intervenir manualmente si se da alguna de esas situaciones. Si el tamaño objetivo es uno, te aseguras de que solo haya una instancia activa que se ejecute en el grupo de instancias gestionado y sirva tráfico.

Los discos persistentes son zonales, por lo que debes crear capturas para volver a crear discos si se produce un fallo en una zona. Las capturas también están disponibles en regiones, lo que te permite restaurar un disco en otra región de forma similar a como lo harías en la misma región.

En el improbable caso de que se produzca un fallo en una zona, debes intervenir manualmente para recuperarte, tal como se indica en la sección siguiente.

Proceso de conmutación por error

Si una VM falla, el grupo de instancias gestionado intenta automáticamente recrear una VM en la misma zona. La secuencia de comandos de inicio de la plantilla de instancia crea un disco persistente a partir de la última captura y lo asocia a la nueva VM.

Sin embargo, un grupo de instancias gestionado con un tamaño de uno no se recupera si se produce un fallo en la zona. Si falla una zona, debes reaccionar a la alerta de Cloud Monitoring u otra plataforma de monitorización cuando falle el servicio y crear manualmente un grupo de instancias en otra zona.

Una variante de esta configuración es usar discos persistentes regionales en lugar de discos persistentes zonales. Con este método, no es necesario usar capturas para restaurar el disco persistente como parte del paso de recuperación. Sin embargo, esta variante consume el doble de almacenamiento, por lo que debes tenerlo en cuenta en tu presupuesto.

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

Activo: conmutación por error de sitio estático

Si las instancias de Compute Engine fallan, puedes mitigar la interrupción del servicio teniendo un sitio estático basado en Cloud Storage en espera. Este patrón es adecuado cuando tu aplicación web es principalmente estática.

En este caso, la aplicación principal se ejecuta en instancias de Compute Engine. Estas instancias se agrupan en grupos de instancias gestionadas, que actúan como servicios de backend de un balanceador de carga HTTPS. El balanceador de carga de HTTP dirige el tráfico entrante a las instancias según la configuración del balanceador de carga, la configuración de cada grupo de instancias y el estado de cada instancia.

Este patrón usa los siguientes elementos básicos de recuperación ante desastres:

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

En el siguiente diagrama se muestra esta arquitectura de ejemplo:

Arquitectura para una conmutación por error en caliente a un sitio estático cuando la producción está en Google Cloud

En los siguientes pasos se explica cómo configurar este caso:

  1. Crea una red VPC.
  2. Crea una imagen personalizada configurada con el servicio web de la aplicación.
  3. Crea una plantilla de instancia que use la imagen de los servidores web.
  4. Configura un grupo de instancias gestionado para los servidores web.
  5. Configura comprobaciones del estado con Monitoring.
  6. Configura el balanceo de carga con los grupos de instancias gestionados que has configurado anteriormente.
  7. Crea un sitio estático basado en Cloud Storage.

En la configuración de producción, Cloud DNS se configura para que apunte a esta aplicación principal, y el sitio estático de reserva permanece inactivo. Si la aplicación de Compute Engine deja de funcionar, puedes configurar Cloud DNS para que dirija a este sitio estático.

Proceso de conmutación por error

Si el servidor o los servidores de aplicaciones dejan de funcionar, 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 modo de recuperación:

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

Cuando las instancias de Compute Engine de la aplicación vuelvan a estar en funcionamiento y puedan admitir cargas de trabajo de producción, invierte el paso de recuperación: configura Cloud DNS para que apunte al balanceador de carga que está delante de las instancias.

También puedes usar la réplica asíncrona de Persistent Disk. Ofrece replicación de almacenamiento en bloques con un objetivo de punto de recuperación (RPO) y un objetivo de tiempo de recuperación (RTO) bajos para la recuperación tras fallos activa-pasiva entre regiones. Esta opción de almacenamiento te permite gestionar la replicación de cargas de trabajo de Compute Engine a nivel de infraestructura, en lugar de a nivel de carga de trabajo.

Popular: aplicación web de alta disponibilidad

Un patrón habitual cuando tu entorno de producción se ejecuta en Google Cloud es establecer una implementación de alta disponibilidad bien diseñada.

Este patrón usa los siguientes elementos básicos de recuperación ante desastres:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

En el siguiente diagrama se muestra esta arquitectura de ejemplo:

Arquitectura de los patrones de calor cuando la producción está en Google Cloud

En este caso, se aprovechan las funciones de alta disponibilidad de Google Cloud. No tienes que iniciar ningún paso de conmutación por error, ya que se producirán automáticamente en caso de desastre.

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

Con este enfoque, obtienes una alta disponibilidad en profundidad. Los grupos de instancias gestionados regionales proporcionan mecanismos para reaccionar ante fallos a nivel de aplicación, instancia o zona, y no tienes que intervenir manualmente si se produce alguno de estos casos.

Para abordar la recuperación a nivel de aplicación, al configurar el grupo de instancias gestionado, se configuran comprobaciones de estado HTTP que verifican que los servicios se ejecutan correctamente en las instancias de ese grupo. Si una comprobación del estado determina que un servicio ha fallado en una instancia, el grupo vuelve a crear automáticamente esa instancia.

Para obtener más información sobre cómo crear aplicaciones escalables y resilientes enGoogle Cloud, consulta Patrones para aplicaciones escalables y resilientes .

Siguientes pasos