En este documento, se explican los comportamientos y las interacciones de una aplicación con estado, un agente de verificación de estado y un plano de control regional específico de la aplicación que se usa para supervisar y organizar una conmutación por error zonal mediante la implementación de discos persistentes regionales.
Este documento está destinado a los desarrolladores de aplicaciones como seguimiento de Opciones de alta disponibilidad con discos persistentes regionales, que expande la información del diseño y la arquitectura de la sección Compila servicios de bases de datos de alta disponibilidad con discos persistentes regionales. Te recomendamos que primero leas ese documento, en especial las secciones sobre las consideraciones de diseño y la comparación de costos, rendimiento y resiliencia.
Una aplicación sin estado aumenta la resiliencia mediante la ejecución de al menos una instancia de máquina virtual (VM) secundaria en una zona diferente de Compute Engine. Cuando la instancia de VM principal falla, la aplicación continúa ejecutándose en la instancia de VM secundaria. Una aplicación con estado puede conservar el estado de su aplicación en un disco persistente zonal para recuperar su estado desde el reinicio de una instancia de VM. Para ser resiliente, una aplicación con estado también debe conservar el estado de la aplicación en una instancia de VM secundaria.
En el siguiente diagrama, se ilustra una típica aplicación con estado de dos nodos que se replica en dos zonas. La aplicación en cada zona tiene un disco persistente zonal que captura el estado de la aplicación y una conexión de red entre las instancias de VM para sincronizar los cambios de estado de la aplicación entre los nodos.
Agrega un disco persistente regional
Otra forma de sincronizar el estado de una aplicación con estado es agregar un disco persistente regional. Cuando una aplicación escribe su estado de aplicación en un disco persistente regional, Google Cloud sincroniza de manera automática el almacenamiento en bloque con otra zona. El almacenamiento en el disco persistente regional también ayuda a garantizar que solo una instancia de VM en ambas zonas esté conectada al disco persistente regional a la vez.
En el siguiente diagrama, se muestra la arquitectura de una aplicación de base de datos con estado.
Como se muestra en el diagrama anterior, aún hay dos instancias de VM de la aplicación (una instancia de VM principal y una secundaria) implementadas en dos zonas. Además de usar un disco persistente regional para el almacenamiento del 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 de VM tiene conectado el disco persistente regional y qué instancia de VM es la instancia de VM principal actual. Esta arquitectura es una configuración activa/pasiva porque solo la instancia de VM principal puede confirmar un estado de la aplicación en el disco persistente regional.
Instancias de VM y la aplicación con estado
En el diagrama de arquitectura anterior, se ilustra una aplicación de base de datos activa/pasiva. También son posibles las siguientes opciones de configuración:
- Si tu objetivo de tiempo de recuperación (RTO) permite la latencia adicional de iniciar una instancia de VM secundaria, puedes ahorrar costos de Compute Engine si solo ejecutas la instancia de VM activa. En una conmutación por error, el plano de control regional específico de la aplicación inicia la instancia de VM secundaria y conecta el disco persistente regional.
- Cargas de trabajo de procesamiento de transmisión o por lotes que controlan su progreso al disco persistente regional. En una conmutación por error, la aplicación reanuda el procesamiento desde ese último punto de control.
Administra el inicio de instancias de VM
Debido a que solo una instancia de VM puede tener un disco persistente regional conectado a la vez, debes iniciar las instancias de VM y conectar el disco persistente regional de forma sistemática. Una práctica recomendada es separar la instancia de VM y el inicio de la aplicación de la conexión del disco persistente regional. Las secuencias de comandos de inicio de la instancia de VM no deben iniciar la conexión del disco persistente regional. En su lugar, las secuencias de comandos de inicio deben iniciar el agente de verificación de estado y esperar a que se conecte el disco persistente regional.
Durante el inicio, la instancia de VM debe realizar los siguientes pasos secuenciales:
- Iniciar el agente de verificación de estado
- Esperar a que se conecte el disco persistente regional
- Luego de que se conecte el disco persistente regional, activar el sistema de archivos
- Una vez que se active el sistema de archivos, iniciar la aplicación
Estos pasos cubren el inicio del sistema, pero también hay una conmutación por error. Durante una conmutación por error, el disco persistente regional se conecta de manera forzada a la instancia de VM secundaria. El disco persistente regional también se quita de manera forzada de la instancia de VM principal, y las operaciones de E/S en el sistema de archivos fallan. En este punto, debes cerrar o reiniciar la instancia de VM.
Ejecuta el agente de verificación de estado y las verificaciones de estado
Como se describe en la sección anterior, la instancia de VM espera a que se conecte el disco persistente regional antes de iniciar la aplicación. El plano de control regional específico de la aplicación conecta el disco persistente regional, pero solo a una instancia de VM que está esperando que el disco se conecte. Cuando se conecta un disco, el plano de control específico de la aplicación supervisa el estado de la aplicación e inicia una conmutación por error si está en mal estado.
Cada instancia de VM tiene uno de los siguientes estados:
- Inactiva
- Iniciando
- Esperando un disco
- Aplicación en ejecución
El agente de verificación de estado informa el estado actual de la instancia de VM. En lugar de informar estos dos estados a través de una verificación de estado única, puedes ejecutar dos verificaciones de estado binarias. Si la instancia de VM está lista para conectar el disco persistente regional o si el disco persistente regional está conectado y admite la escritura, la verificación de estado de la instancia de VM informa un buen estado. Si la aplicación se está ejecutando y puede escribir el estado de la aplicación en el disco persistente regional, la verificación de estado de la aplicación informa un buen estado.
El uso de dos verificaciones de estado binarias tiene varias ventajas:
- Puedes usar el servicio de verificación de estado administrado de Compute Engine, que sondea el agente de verificación de estado y también resuelve errores transitorios a través de los recuentos de umbrales.
- Un grupo de instancias administrado (MIG) puede supervisar la verificación de estado de la instancia y la reparación automática de una instancia de VM en mal estado.
- El balanceador de cargas puede supervisar la verificación de estado de la aplicación y enrutar el tráfico a la instancia de la aplicación activa.
Puedes evitar que el sistema reaccione a una falla transitoria si disminuyes la frecuencia de los informes de verificación de estado o si aumentas el umbral de las señales repetidas necesarias para la transición de un nivel a otro. Ambos enfoques retrasan la reacción del sistema ante una interrupción y aumentan el tiempo de recuperación. Cuando pruebas y mides estos parámetros, puedes ajustar los parámetros de la verificació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 es responsable de las siguientes dos funciones:
- La administración del ciclo de vida de la instancia de VM principal y de la secundaria
- La supervisión del estado de la verificación de estado de la aplicación para decidir si se necesita una conmutación por error
Si se necesita una conmutación por error, el plano de control regional específico de la aplicación la organizará mediante los siguientes pasos:
- Comprueba que una instancia de VM secundaria esté en ejecución y esperando que se conecte un disco persistente regional.
- Fuerza la conexión del disco persistente regional con la instancia de VM secundaria.
- Supervisa y reinicia la instancia de VM principal con errores. Cuando se reinicia la instancia de VM, 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 alta disponibilidad en las dos zonas en las que se ejecuta la aplicación. En los centros de datos locales, la alta disponibilidad (HA) a menudo se logra mediante la implementación de servidores adicionales para lograr un quórum, decidir qué instancia de VM es la principal y organizar la conmutación por error. Este enfoque a menudo usa herramientas de supervisión de alta disponibilidad, como Heartbeat, Pacemaker o Keepalived.
Si bien 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 administrados y disponibles por regiones para simplificar la implementación de este enfoque:
- Productos sin servidores de Google Cloud, como App Engine, Cloud Run y Cloud Functions, que son fáciles de implementar y administrar
- Verificaciones de estado administradas que descargan la supervisión de las instancias de la aplicación
- Grupos de instancias administrados que gestionan el ciclo de vida de las instancias de servidor
En el siguiente diagrama, se ilustra el uso de Cloud Functions para el plano de control regional específico de la aplicación, junto con un grupo de instancias administrado con estado y verificaciones de estado administradas.
En el diagrama anterior, se muestran dos instancias de VM de la aplicación, la primaria y la secundaria. Cada instancia de VM se ejecuta en una zona separada y la administra un MIG regional con estado. Un disco persistente regional está disponible en las mismas dos zonas. Dos servicios de verificación de estado administrados están en ejecución. Un servicio de verificación de estado administrado supervisa el estado de la instancia, y el MIG con estado lo usa. El otro servicio de verificación de estado supervisa el estado de la aplicación, y el grupo de destino del balanceador de cargas lo usa.
Un plano de control regional específico de la aplicación interactúa con el estado de la aplicación del grupo de destino y con el MIG regional con estado para supervisar el estado de la aplicación e iniciar la conexión del disco persistente regional con la instancia de VM en buen estado actual.
¿Qué sigue?
- Lee Aprovisiona discos persistentes regionales en Google Kubernetes Engine.
- Si deseas obtener información sobre cómo adaptar las herramientas de alta disponibilidad locales para usarlas en Google Cloud, consulta Patrones para usar direcciones IP flotantes.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.