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 regionales replicados de forma síncrona.
Este documento está destinado a los desarrolladores de aplicaciones como seguimiento de Crea servicios de alta disponibilidad con discos regionales, que expande la información del diseño y la arquitectura de la sección Crea servicios de bases de datos de alta disponibilidad con discos 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 Compute Engine secundaria en una zona diferente. Cuando la instancia principal falla, la aplicación continúa ejecutándose en la instancia secundaria. Una aplicación con estado puede conservar el estado de su aplicación en un disco zonal, o un disco que está disponible en una sola zona, para recuperar su estado desde el reinicio de una instancia. Para ser resiliente, una aplicación con estado también debe conservar el estado de la aplicación en una instancia secundaria.
En la Figura 1, 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 zonal que captura 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.
Figura 1. Aplicación con estado de dos nodos sin discos regionales
Agrega un disco regional
Otra forma de sincronizar el estado de una aplicación con estado es agregar un disco regional. Cuando una aplicación escribe su estado de 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 estado.
Figura 2. Aplicación de base de datos con estado
Como se muestra en la Figura 2, aún hay dos instancias de procesamiento de la aplicación (una instancia principal y una secundaria) implementadas en dos zonas. Además de usar un disco 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 tiene conectado el disco regional y qué instancia es la instancia 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 procesamiento y la aplicación con estado
En la figura 2, 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 secundaria, puedes ahorrar costos de Compute Engine si solo ejecutas 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 transmisión que controlan su progreso en el disco 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 Compute Engine
Debido a que solo una instancia de procesamiento puede tener un disco regional conectado a la vez, debes iniciar las instancias y conectar el disco regional de forma sistemática. Una práctica recomendada es separar la instancia de procesamiento y el inicio de la aplicación de la conexión del disco regional. Las secuencias de comandos de inicio de la instancia no deben iniciar la conexión del disco 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 regional.
Durante el inicio, la instancia de procesamiento debe realizar los siguientes pasos secuenciales:
- Iniciar el agente de verificación de estado
- Espera a que se conecte el disco regional.
- Después de conectar el disco regional, activa 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 regional se conecta de manera forzada a la instancia secundaria. El disco regional también se quita de manera forzada de la instancia principal, y las operaciones de E/S en el sistema de archivos fallan. En este punto, debes cerrar o reiniciar la instancia de procesamiento.
Ejecuta el agente de verificación de estado y las verificaciones de estado
Como se describe en la sección anterior, la instancia de procesamiento 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 conecta el disco regional, pero solo a una instancia de procesamiento 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 procesamiento tiene uno de los siguientes estados:
- Inactivo
- Iniciando
- Esperando un disco
- Aplicación en ejecución
El agente de verificación de estado informa el estado actual de la instancia. 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 procesamiento está lista para conectar el disco regional o si el disco regional está conectado y admite la escritura, la verificación de estado de la instancia informa un buen estado. Si la aplicación se está ejecutando y puede escribir el estado de la aplicación en el disco 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 procesamiento 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:
- Administrar el ciclo de vida de las instancias de procesamiento principal y 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 secundaria esté en ejecución y esperando que se conecte un disco regional.
- Fuerza la conexión del disco regional a la instancia secundaria.
- Supervisa y reinicia la instancia principal con errores. 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 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 procesamiento 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 procesamiento que ejecutan la aplicación
- Grupos de instancias administrados que administran el ciclo de vida de las instancias de procesamiento
En la Figura 3, se ilustra 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 administrado con estado y verificaciones de estado administradas.
Figura 3. Plano de control regional específico de la aplicación
En la Figura 3, se muestran dos instancias de procesamiento de la aplicación, la principal y la secundaria. Cada instancia se ejecuta en una zona separada y la administra un MIG regional con estado. Un disco 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 regional con la instancia de procesamiento en buen estado actual.
¿Qué sigue?
- Lee Aprovisiona discos regionales en la documentación de 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.