Este documento 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:
- Guía de planificación para la recuperación ante desastres
- Componentes básicos de la recuperación ante desastres
- Situaciones de recuperación ante desastres para datos
- Situaciones de recuperación ante desastres para aplicaciones (este documento)
- Arquitectura de recuperación ante desastres para cargas de trabajo con restricciones de localidad
- Casos de uso de recuperación ante desastres: aplicaciones de análisis de datos con restricciones de localidad
- Arquitectura de recuperación ante desastres para interrupciones de infraestructura de nube
Introducción
En este documento, 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 documento sobre los componentes básicos de la DR para 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 VM Spot y 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 podría detener o borrar estas instancias de forma preventiva si requiere acceso a esos recursos para otras tareas.
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 inicio de nodos de trabajador 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 combinación de patrones calientes (de compra) y templados y 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 tu aplicación se ejecuta de forma local y la solución de DR se encuentra enGoogle Cloud.
Patrón frío: Recuperación en Google Cloud
En un patrón frío, tienes recursos mínimos en el proyecto de DR Google Cloud, los suficientes 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 deGoogle 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 componentes básicos de DR:
- 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:
En los siguientes pasos, se describe cómo puedes configurar el entorno:
- Crea una red de VPC.
- Configura la conectividad entre tu red local y la red de Google Cloud .
- Crea un bucket de Cloud Storage como destino para la copia de seguridad de los datos.
- Crea una cuenta de servicio.
- Crea una política de IAM para restringir quién puede acceder al bucket 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.
- Usa la suplantación de identidad de la cuenta de servicio para proporcionar acceso a tu usuario Google Cloud local (o cuenta de servicio) para que robe la identidad de la cuenta de servicio que creaste antes. Como alternativa, puedes crear un usuario nuevo específicamente para este fin.
- Comprueba que puedes subir y descargar archivos en el bucket de destino.
- Crea una secuencia de comandos de transferencia de datos.
- Crea una tarea programada para ejecutar la secuencia de comandos. Puedes usar herramientas como
crontab
de Linux y el Programador de tareas de Windows. Crea imágenes personalizadas que se configuren 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 copie automáticamente la copia de seguridad más reciente de un bucket de Cloud Storage a la instancia y, luego, invoque el proceso de restablecimiento.
Configura Cloud DNS para que apunte a tus servicios web accesibles desde Internet.
Crea una plantilla de Deployment Manager que creará servidores de aplicaciones en tu red de Google Cloud con las imágenes personalizadas configuradas con anterioridad. 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 enGoogle 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 enGoogle Cloud.
A continuación, se muestra una secuencia de recuperación típica:
- Usa la plantilla de Deployment Manager para crear una implementación enGoogle Cloud.
- Sigue las instrucciones de tu sistema de base de datos para recuperar archivos de copia de seguridad a fin de aplicar la copia de seguridad de base de datos más reciente en Cloud Storage al servidor de base de datos que se ejecuta en Google Cloud .
- Aplica los registros de transacciones más recientes en Cloud Storage.
- Prueba que la aplicación funcione según lo esperado mediante la simulación de situaciones de usuario en el entorno recuperado.
- 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:
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 para realizar la conmutación por error al entorno de recuperación de Google Cloud . A continuación, se describe una secuencia típica para volver al entorno de producción:
- Crea una copia de seguridad de la base de datos que se ejecuta en Google Cloud.
- Copia el archivo de copia de seguridad en el entorno de producción.
- Aplica el archivo de copia de seguridad al sistema de base de datos de producción.
- 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.
- Copia los archivos de registro de transacciones en el entorno de producción y aplícalos al servidor de la base de datos.
- Configura Cloud DNS para que se oriente a tu servicio web local.
- Asegúrate de que el proceso que usabas para copiar datos a Cloud Storage funcione según lo esperado.
- 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.
Este patrón usa los siguientes componentes básicos de DR:
- 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 web de referencia y del servidor de aplicaciones 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.
En los siguientes pasos, se describe cómo puedes configurar el entorno:
- Crea una red de VPC.
- Configura la conectividad entre tu red local y la red de Google Cloud .
- Replica tus servidores locales en instancias de Google Cloud VM. Una opción es usar una solución de socios; el método que emplees depende de tus circunstancias.
- Crea una imagen personalizada de tu servidor de base de datos en Google Cloud que tenga la misma configuración que tu servidor de base de datos local.
- Crea instantáneas del servidor web y las instancias del servidor de aplicaciones.
- Inicia una instancia de base de datos en Google Cloud con 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.
- Adjunta discos persistentes a la instancia de la base de datos de Google Cloud para las bases de datos y los registros de transacciones.
- Sigue las instrucciones de tu software de base de datos para configurar la replicación entre tu servidor de base de datos local y el servidor de base de datos en Google Cloud .
- Establece la marca de eliminación automática en los discos persistentes conectados a la instancia de la base de datos como
no-auto-delete
. - Configura una tarea programada para crear instantáneas normales de los discos persistentes de la instancia de base de datos en Google Cloud.
- Crea reservas para garantizar la capacidad para tu servidor web y los servidores de aplicaciones según sea necesario.
- Prueba el proceso de crear instancias a partir de instantáneas y de tomar instantáneas de los discos persistentes.
- Crea instancias del servidor web y el servidor de aplicaciones mediante las instantáneas creadas con anterioridad.
- 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.
- 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 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 aGoogle Cloud , lo que permite que las cargas de trabajo de producción se entreguen desdeGoogle Cloud:
A continuación, se muestra una secuencia de recuperación típica:
- Cambia el tamaño de la instancia de servidor de base de datos para que pueda controlar las cargas de producción.
- Usa el servidor web y las instantáneas de aplicaciones en Google Cloud para crear instancias de aplicaciones y un servidor web nuevos.
- Prueba que la aplicación funcione según lo esperado mediante la simulación de situaciones de usuario en el entorno recuperado.
- 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 para realizar la conmutación por error al entorno de recuperación de Google Cloud . A continuación, se describe una secuencia típica para volver al entorno de producción:
- Crea una copia de seguridad de la base de datos que se ejecuta en Google Cloud.
- Copia el archivo de copia de seguridad en el entorno de producción.
- Aplica el archivo de copia de seguridad al sistema de base de datos de producción.
- 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.
- Copia los archivos de registro de transacciones en el entorno de producción y aplícalos al servidor de la base de datos.
- Prueba que la aplicación funcione según lo esperado mediante la simulación de situaciones de usuario en el entorno de producción.
- Configura Cloud DNS para que se oriente a tu servicio web local.
- Borra las instancias del servidor web y del servidor de aplicaciones que se ejecutan enGoogle Cloud. Deja en ejecución los servidores de referencia.
- Cambia el tamaño del servidor de base de datos en Google Cloud al tamaño mínimo de la instancia que pueda aceptar datos replicados de la base de datos de producción local.
- Sigue las instrucciones de tu software de base de datos para configurar la replicación entre tu servidor de base de datos local y el servidor de base de datos en Google Cloud .
Alta disponibilidad caliente en infraestructuras locales y Google Cloud
Si tienes valores pequeños de RTO y RPO, puedes lograrlo solo si ejecutas la alta disponibilidad en tu entorno de producción y Google Cloud al mismo tiempo. Este enfoque te proporciona un patrón caliente, ya que la infraestructura local y Google Cloudentregan 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.
Este patrón usa los siguientes componentes básicos de DR:
- 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.
En los siguientes pasos, se describe cómo puedes configurar el entorno:
- Crea una red de VPC.
- Configura la conectividad entre tu red local y tu red Google Cloud .
- Crea imágenes personalizadas en Google Cloud que se configuren para cada servidor en el entorno de producción local. Cada imagen de Google Cloud debe tener la misma configuración que su equivalente local.
Sigue las instrucciones de tu software de base de datos para configurar la replicación entre tu servidor de base de datos local y el servidor de base de datos en Google Cloud .
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.
Crea plantillas de instancias individuales que usen las imágenes para los servidores de aplicaciones y los servidores web.
Configura grupos de instancias regionales administrados para los servidores de aplicaciones y los servidores web.
Configura las verificaciones de estado mediante Cloud Monitoring.
Configura el balanceo de cargas con los grupos de instancias regionales administrados que se configuraron antes.
Configura una tarea programada para crear instantáneas regulares de los discos persistentes.
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 enGoogle Cloud tengan la misma versión de la aplicación que las versiones locales. 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 de DNS no redirige de manera automática el tráfico en función de una falla en la verificación de estado, necesitas configurar 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 tu aplicación para la carga de trabajo de producción enGoogle Cloud, las funciones de alta disponibilidad de la plataforma tienen una influencia directa en la arquitectura de recuperación ante desastres.
El servicio de copia de seguridad y DR es una solución centralizada y nativa de la nube para crear copias de seguridad de cargas de trabajo híbridas y en la nube, y recuperarlas. Ofrece una recuperación rápida de los datos y facilita la reanudación rápida de las operaciones comerciales esenciales.
Para obtener más información sobre el uso del servicio de Copia de seguridad y DR para situaciones de aplicaciones en Google Cloud, consulta lo siguiente:
En Backup and DR Service para Compute Engine, se describen los conceptos y los detalles del uso de Google Cloud Backup and DR Service para crear copias de seguridad de forma incremental de los datos de tus discos persistentes a nivel de la instancia.
En Backup and DR Service para Google Cloud VMware Engine, se describen los conceptos y los detalles del uso de Google Cloud Backup and DR Service para crear copias de seguridad incrementales de los datos de tus VMDK a nivel de la VM.
En Backup and DR Service para Filestore y sistemas de archivos, se describen los conceptos y detalles del uso de Google Cloud Backup and DR Service para capturar y crear copias de seguridad de datos de sistemas de archivos SMB, NFS y Filestore de producción.
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 enGoogle Cloud, puedes crear una VM en un grupo de instancias administrado que solo ejecute una instancia.
Este patrón usa los siguientes componentes básicos de DR:
- 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:
En los siguientes pasos, se describe cómo configurar esta situación de conmutación por error en frío:
- Crea una red de VPC.
- Crea una imagen de VM personalizada que se configure con el servicio web de tu aplicación.
- Configura la VM para que los datos que el servicio de la aplicación procesa se escriban en un disco persistente conectado.
- Crea una instantánea desde el disco persistente adjunto.
- Crea una plantilla de instancias que haga referencia a la imagen de VM personalizada del servidor web.
- Configura una secuencia de comandos de inicio para crear un disco persistente a partir de la última instantánea y activarlo. Esta secuencia de comandos debe poder obtener la última instantánea del disco.
- Crea un grupo de instancias administrado y verificaciones de estado con un tamaño de destino que haga referencia a la plantilla de instancias.
- Crea una tarea programada para crear instantáneas normales del disco persistente.
- Configura un balanceador de cargas de aplicaciones externo.
- 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.
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. Este patrón es adecuado 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.
Este patrón usa los siguientes componentes básicos de DR:
- Compute Engine
- Cloud Storage
- Cloud Load Balancing
- Cloud DNS
En el siguiente diagrama, se ilustra esta arquitectura de ejemplo:
En los siguientes pasos, se describe cómo configurar esta situación:
- Crea una red de VPC.
- Crea una imagen personalizada que se configure con el servicio web de la aplicación.
- Crea una plantilla de instancias que use la imagen para los servidores web.
- Configura un grupo de instancias administrado para los servidores web.
- Configura las verificaciones de estado mediante Monitoring.
- Configura el balanceo de cargas mediante los grupos de instancias administrados que configuraste con anterioridad.
- 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:
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.
Como alternativa, puedes usar la replicación asíncrona de Persistent Disks. Ofrece replicación de almacenamiento en bloque con un objetivo de punto de recuperación (RPO) y un objetivo de tiempo de recuperación (RTO) bajos para la DR activa-pasiva entre regiones. Esta opción de almacenamiento te permite administrar la replicación de las cargas de trabajo de Compute Engine a nivel de la infraestructura, en lugar de a nivel de la carga de trabajo.
Caliente: Aplicación web de alta disponibilidad
Un patrón caliente cuando tu entorno de producción se ejecuta en Google Cloudes establecer una implementación de alta disponibilidad con buena arquitectura.
Este patrón usa los siguientes componentes básicos de DR:
- Compute Engine
- Cloud Load Balancing
- Cloud SQL
En el siguiente diagrama, se ilustra esta arquitectura de ejemplo:
En esta situación, se aprovechan las características de alta disponibilidad de Google Cloud: no es necesario que inicies ningún paso de la conmutación por error, ya que se iniciarán de manera 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 obtener más información sobre cómo compilar aplicaciones escalables y resilientes enGoogle Cloud, consulta Patrones de apps escalables y resilientes .
¿Qué sigue?
- Obtén información sobre la Google Cloud geografía y las regiones.
Lee otros documentos de esta serie sobre la DR:
- Guía de planificación para la recuperación ante desastres
- Componentes básicos de la recuperación ante desastres
- Situaciones de recuperación ante desastres para datos
- Arquitectura de recuperación ante desastres para cargas de trabajo con restricciones de localidad
- Casos de uso de recuperación ante desastres: aplicaciones de análisis de datos con restricciones de localidad
- Arquitectura de recuperación ante desastres para interrupciones de infraestructura de nube
Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.