En este documento se explican los comportamientos y las interacciones entre una aplicación con estado, un agente de comprobación del estado y un plano de control regional específico de la aplicación que se usa para monitorizar y coordinar una conmutación por error zonal mediante la implementación de discos replicados de forma síncrona a nivel regional.
Este documento está dirigido a desarrolladores de aplicaciones como continuación del artículo Crear servicios de alta disponibilidad con discos regionales, y amplía el diseño y la arquitectura descritos en la sección Crear servicios de bases de datos de alta disponibilidad con discos regionales. Te recomendamos que leas primero ese documento, especialmente las secciones sobre consideraciones de diseño y comparación de costes, rendimiento y resiliencia.
Una aplicación sin estado aumenta la resiliencia al tener al menos una instancia secundaria de Compute Engine ejecutándose en otra zona. Si la instancia principal falla, la aplicación sigue ejecutándose en la instancia secundaria. Una aplicación con estado puede conservar su estado en un disco zonal (un disco que solo está disponible en una zona) para recuperar su estado tras reiniciar una instancia. Para ser resiliente, una aplicación con reconocimiento del estado también debe conservar el estado de la aplicación en una instancia secundaria.
En la figura 1 se muestra una aplicación con estado de dos nodos típica que se replica en dos zonas. La aplicación de cada zona tiene un disco zonal para registrar el estado de la aplicación y una conexión de red entre las instancias para sincronizar los cambios de estado de la aplicación entre los nodos.
Imagen 1. Aplicación con reconocimiento del estado de dos nodos sin discos regionales
Añadir un disco regional
Otra forma de sincronizar el estado de una aplicación con estado es añadir un disco regional. Cuando una aplicación escribe el estado de su aplicación en un disco regional,Google Cloud sincroniza automáticamente el almacenamiento en bloque con otra zona.
En la figura 2 se muestra la arquitectura de una aplicación de base de datos con reconocimiento del estado.
Imagen 2. Aplicación de base de datos con reconocimiento del estado
Como se muestra en la figura 2, todavía hay dos instancias de proceso de aplicación (una principal y otra secundaria) implementadas en dos zonas. Además de usar un disco regional para almacenar el estado de la aplicación, ahora hay una entidad adicional: el plano de control regional específico de la aplicación. El plano de control regional específico de la aplicación decide qué instancia tiene el disco regional conectado y qué instancia es la principal actual. Esta arquitectura es una configuración activa-pasiva porque solo la instancia principal puede confirmar un estado de la aplicación en el disco regional.
Instancias de Compute y la aplicación con estado
En la figura 2 se muestra una aplicación de base de datos activa-pasiva en caliente. También se pueden usar las siguientes configuraciones:
- Si tu objetivo de tiempo de recuperación (RTO) puede asumir la latencia adicional de iniciar una instancia secundaria, puedes ahorrar costes de Compute Engine ejecutando solo la instancia activa. En una conmutación por error, el plano de control regional específico de la aplicación inicia la instancia secundaria y conecta el disco regional a esa instancia.
- Cargas de trabajo de procesamiento por lotes o de flujo que registran su progreso en el disco regional. En una conmutación por error, la aplicación reanuda el procesamiento desde ese último punto de control.
Gestionar el inicio de instancias de Compute Engine
Como solo se puede adjuntar un disco regional a una instancia de proceso a la vez, debes iniciar las instancias y adjuntar el disco regional de forma sistemática. Una práctica recomendada es separar la instancia de proceso y el inicio de la aplicación de la conexión del disco regional. Los scripts de inicio de la instancia no deben iniciar la conexión del disco regional. En su lugar, los scripts de inicio deben iniciar el agente de comprobación del estado y esperar a que se conecte el disco regional.
Al iniciarse, la instancia de proceso debe realizar los siguientes pasos secuenciales:
- Inicia el agente de comprobación del estado.
- Espera a que se adjunte el disco regional.
- Una vez que se haya conectado el disco regional, monta el sistema de archivos.
- Una vez que se haya montado el sistema de archivos, inicia la aplicación.
Estos pasos abarcan el inicio del sistema, pero también hay una conmutación por error. Durante una conmutación por error, el disco regional se vincula de forma forzosa a la instancia secundaria. El disco regional también se quita de forma forzada de la instancia principal y las operaciones de E/S en el sistema de archivos fallan. En este punto, debes apagar o reiniciar la instancia de proceso.
Ejecutar el agente de comprobación del estado y las comprobaciones del estado
Como se describe en la sección anterior, la instancia de proceso espera a que se conecte el disco regional antes de iniciar la aplicación. El plano de control regional específico de la aplicación adjunta el disco regional, pero solo a una instancia de proceso que esté esperando que se adjunte el disco. Cuando se conecta un disco, el plano de control específico de la aplicación monitoriza el estado de la aplicación e inicia una conmutación por error si la aplicación deja de estar en buen estado.
Cada instancia de proceso tiene uno de los siguientes estados:
- Abajo
- Iniciando
- Esperando un disco
- Aplicación en ejecución
El agente de comprobación del estado informa del estado actual de la instancia. En lugar de informar de estos dos estados mediante una sola comprobación del estado, puedes ejecutar dos comprobaciones del estado binarias. Si la instancia de proceso está lista para que se le conecte el disco regional o si el disco regional está conectado y se puede escribir en él, la comprobación del estado de la instancia indica que el estado es correcto. Si la aplicación se está ejecutando y puede escribir el estado de la aplicación en el disco regional, la comprobación del estado de la aplicación informa de un estado correcto.
Usar dos comprobaciones de estado binarias tiene varias ventajas:
- Puedes usar el servicio de comprobación del estado gestionado de Compute Engine, que sondea el agente de comprobación del estado y también resuelve errores transitorios mediante recuentos de umbrales.
- Un grupo de instancias gestionado (MIG) puede monitorizar la comprobación del estado de las instancias y reparar automáticamente una instancia de proceso en mal estado.
- El balanceador de carga puede monitorizar la comprobación del estado de la aplicación y dirigir el tráfico a la instancia de aplicación activa.
Puedes evitar que el sistema reaccione a un fallo transitorio disminuyendo la frecuencia de los informes de comprobación del estado o aumentando el umbral de las señales repetidas que se necesitan para pasar de un nivel a otro. Ambos enfoques retrasan la reacción del sistema ante una interrupción y aumentan el tiempo de recuperación. Al probar y medir estos parámetros, puedes ajustar los parámetros de comprobación de estado para equilibrar el tiempo de recuperación del sistema.
Información sobre el plano de control regional específico de la aplicación
La última pieza de la arquitectura es el plano de control regional específico de la aplicación, que se encarga de las dos funciones siguientes:
- Gestionar el ciclo de vida de las instancias de proceso principales y secundarias.
- Decidir si es necesaria una conmutación por error monitorizando el estado de la comprobación del estado de la aplicación.
Si es necesaria una conmutación por error, el plano de control regional específico de la aplicación coordina la conmutación por error siguiendo estos pasos:
- Comprueba que se esté ejecutando una instancia secundaria y que esté esperando a que se conecte el disco regional.
- Fuerza la conexión del disco regional a la instancia secundaria.
- Monitoriza y reinicia la instancia principal que ha fallado. Cuando se reinicia la instancia principal, el plano de control inicia una conmutación por recuperación según sea necesario.
El plano de control regional específico de la aplicación debe tener una alta disponibilidad en las dos zonas en las que se ejecuta la aplicación. En los centros de datos on-premise, la alta disponibilidad (HA) se suele conseguir implementando servidores adicionales para crear un quórum, decidir qué instancia de computación es la principal y orquestar la conmutación por error. Este enfoque suele utilizar herramientas de monitorización de alta disponibilidad, como Heartbeat, Pacemaker o Keepalived.
Aunque puedes usar el plano de control regional específico de la aplicación en cualquier lugar de la nube, Google Cloud ofrece los siguientes servicios gestionados y disponibles en cada región que simplifican la implementación de este enfoque:
- Google Cloud productos sin servidor, como App Engine, Cloud Run y Cloud Run functions, que son fáciles de gestionar y desplegar.
- Comprobaciones de estado gestionadas que descargan la monitorización de las instancias de proceso que ejecutan la aplicación.
- Grupos de instancias gestionados que gestionan el ciclo de vida de las instancias de proceso.
En la figura 3 se muestra el uso de funciones de Cloud Run para el plano de control regional específico de la aplicación, junto con un grupo de instancias gestionado con estado y comprobaciones de estado gestionadas.
Imagen 3. Plano de control regional específico de la aplicación
En la figura 3 se muestran dos instancias de proceso de la aplicación, una principal y otra secundaria. Cada instancia se ejecuta en una zona independiente y se gestiona mediante un MIG regional con estado. Un disco regional está disponible en las dos mismas zonas. Se están ejecutando dos servicios de comprobación del estado gestionados. Un servicio de comprobación del estado gestionado monitoriza el estado de las instancias y lo usa el MIG con estado. El otro servicio de comprobación del estado monitoriza el estado de las aplicaciones y lo usa el grupo de destino del balanceador de carga.
Un plano de control regional específico de la aplicación interactúa con el estado de salud de la aplicación del grupo de destino y con la MIG regional con estado para monitorizar el estado de la aplicación e iniciar la conexión del disco regional a la instancia de proceso en buen estado actual.
Siguientes pasos
- Consulta Aprovisionar discos regionales en la documentación de Google Kubernetes Engine.
- Para saber cómo puedes adaptar las herramientas de alta disponibilidad locales para usarlas enGoogle Cloud, consulta Patrones para usar direcciones IP flotantes.
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.