Opciones de alta disponibilidad con discos persistentes regionales

En este documento, se analiza cómo puedes usar discos persistentes regionales a fin de compilar servicios de alta disponibilidad (HA) mediante la comparación de opciones diferentes para aumentar la disponibilidad del servicio, así como comparar el costo, el rendimiento y la resiliencia de arquitecturas de servicios diferentes. Además, se describen los tipos de fallas y las acciones de recuperación a fin de ayudarte a decidir si los discos persistentes regionales son la solución correcta para tu servicio HA.

El disco persistente regional es una opción de almacenamiento que proporciona replicación síncrona de datos entre dos zonas de una región. Los discos persistentes regionales pueden ser un buen bloque de compilación para usar cuando implementas servicios HA en Compute Engine.

El beneficio de los discos persistentes regionales es que, en caso de una interrupción zonal, en la que tu instancia de VM podría no estar disponible, puedes adjuntar de manera forzada el disco persistente regional a una instancia de VM en una zona secundaria en la misma región. Si quieres realizar esta tarea, debes iniciar otra instancia de VM en la misma zona que el disco persistente regional que adjuntaste de manera forzada o mantener una instancia de VM en espera activa en esa zona. Una “espera activa” es una instancia de VM en ejecución que es idéntica a la que se usa. Las dos instancias tienen los mismos datos.

La operación de conexión forzada se ejecuta en menos de un minuto, lo que logra un objetivo de tiempo de recuperación (RTO) en cuestión minutos. El RTO total depende no solo de la conmutación por error del almacenamiento (la conexión forzada del disco persistente regional), sino también de si primero se debe crear una instancia de VM secundaria, el tiempo en que el sistema de archivos subyacente detecta un disco conectado activo, el tiempo de recuperación de las aplicaciones correspondientes y otros factores.

Consideraciones del diseño

Antes de comenzar a diseñar un servicio HA, debes comprender las características de la aplicación, el sistema de archivos y el sistema operativo. Estas características son la base del diseño y pueden descartar varios enfoques. Por ejemplo, si una aplicación no admite la replicación a nivel de la aplicación, algunas opciones de diseño correspondientes no son aplicables.

Del mismo modo, si la aplicación, el sistema de archivos o el sistema operativo no son tolerantes a las fallas, podría no ser una opción usar discos persistentes regionales o incluso instantáneas de discos persistentes zonales. La tolerancia a fallas se define como la habilidad de recuperarse de una interrupción abrupta sin perder ni dañar datos que ya se confirmaron en un disco persistente antes de la falla.

Ten en cuenta lo siguiente:

  1. Conocer el impacto en el rendimiento de la aplicación y la escritura
  2. Determinar el objetivo del tiempo de recuperación del servicio Conoce qué tan rápido debe recuperarse tu servicio de una interrupción zonal y los requisitos del ANS.
  3. Conoce el costo de compilar una arquitectura de servicio resiliente y confiable. En términos de costo, tus opciones para la replicación síncrona y asíncrona de la aplicación son las que se detallan a continuación:

    Usar dos instancias de la base de datos y VM. En este caso, los elementos siguientes determinan el costo total:

    • Costos de instancia de VM
    • Costos del disco persistente
    • Costos del mantenimiento de la replicación de aplicaciones

    Si quieres lograr una alta disponibilidad con un disco persistente regional, debes usar la misma instancia de VM y los componentes del disco persistente, pero también incluir un disco persistente regional. Los discos persistentes regionales cuestan el doble por byte en comparación con los discos persistentes zonales, ya que se replican en dos zonas.

    Sin embargo, el uso de discos persistentes regionales puede reducir el costo de mantenimiento debido a que los datos se replican de forma automática en dos réplicas sin necesidad de mantener la replicación de aplicaciones.
    Puedes reducir los costos del host aún más si solo inicias la copia de seguridad de la VM a pedido durante la conmutación por error, en lugar de mantener la VM en un modo de espera activa.

Compara el costo, el rendimiento y la resiliencia

En la tabla siguiente, se destacan las compensaciones sobre costo, rendimiento y resiliencia para las diferentes arquitecturas de servicio.

Arquitectura
de servicio HA
Instantáneas de discos
persistentes zonales
Nivel de aplicación
síncrono
Nivel de la aplicación
asíncrono
Solución HA
con el disco persistente regional
Protege contra fallas de zona, VM y aplicaciones 1
Mitigación contra los daños de la aplicación (ejemplo: intolerancia al fallo de la aplicación) 2
Costo $ $$
2 instancias de la base de datos/VM que se ejecutan más el costo de mantenimiento y configuración de la replicación de aplicaciones más redes entre zonas
$$
2 instancias de la base de datos/VM que se ejecutan más el costo de mantenimiento y configuración de la replicación de aplicaciones más redes entre zonas
$1.5 x $$
los costos son iguales a la replicación de aplicaciones si usas una espera activa. Puedes lograr reducir el costo si aceleras la copia de seguridad de la VM a pedido durante la conmutación por error.
Rendimiento de las aplicaciones
Sin impacto

Compensación del rendimiento de la aplicación con replicación síncrona

Sin impacto

Sin impacto para la mayoría de las aplicaciones
Adecuado para aplicaciones con requisitos de RPO bajos (sin tolerancia a la pérdida de datos)
Pérdida de datos en función del momento en que se tomó la instantánea

Sin pérdida de datos3

Pérdida de datos debido a que la replicación es asíncrona

Sin pérdida de datos
Tiempo de recuperación de almacenamiento del desastre4 O (minutos) O (segundos) O (segundos) O (segundos): para realizar la conexión forzada del disco a la instancia de VM en espera

1No es suficiente usar discos persistentes regionales o instantáneas para proteger y mitigar contra fallas y daños. Tu aplicación, el sistema de archivos y, en lo posible, otros componentes de software deben ser coherentes frente a fallas o usar algún tipo de inactividad.

2La replicación de algunas aplicaciones proporciona mitigación contra algunos daños de la aplicación. Por ejemplo, el daño de la aplicación principal MySQL no generará que tus instancias de réplica se dañen. Revisa la documentación de tu aplicación para obtener más detalles.

3La pérdida de datos implica la pérdida irrecuperable de datos confirmados con el almacenamiento continuo. Sin embargo, se perderán todos los datos que no se hayan confirmado.

4El rendimiento de la conmutación por error no incluye la verificación del sistema de archivos, la recuperación de la aplicación ni la carga después de la conmutación por error.

Compilación de servicios de bases de datos HA con discos persistentes regionales

En esta sección, se describen los conceptos de alto nivel a fin de compilar soluciones HA para servicios de bases de datos con estado (MySQL, Postgres, etc.) mediante discos persistentes regionales y Compute Engine.

En este debate, se describe la mitigación de interrupciones de zonas únicas. Una aplicación aún podría no estar disponible en caso de interrupciones más amplias, por ejemplo, si toda una región deja de estar disponible. En función de tus necesidades, es posible que quieras considerar técnicas de replicación interregionales para una disponibilidad aún mayor.

Las configuraciones de HA de la base de datos suelen tener, al menos, dos instancias de VM. En el mejor caso, estas instancias formarán parte de uno o más grupos de instancias administrados:

  • una instancia de VM principal en la zona principal
  • una instancia de VM en espera en una zona secundaria

Una instancia de VM principal tiene, al menos, dos discos persistentes: un disco de arranque y un disco persistente regional. El disco persistente regional contiene los datos de la base de datos y cualquier otro dato mutable que debería conservarse en otra zona en caso de una interrupción.

Una instancia de VM en espera necesita un disco de arranque distinto a fin de poder recuperarse de las interrupciones relacionadas con la configuración, que podrían generar, por ejemplo, una actualización del sistema operativo. No se puede forzar la conexión de un disco de arranque a otra VM durante una conmutación por error.

Las instancias de VM principal y en espera están configuradas a fin de usar un balanceador de cargas con el tráfico dirigido a la VM principal en función de los indicadores de verificación de estado. Esta configuración también se conoce como "Espera activa". La situación de recuperación ante desastres para datos describe otras configuraciones de conmutación por error, que podrían ser más apropiadas para tu caso.

Verificaciones de estado

El agente de verificación de estado implementa las verificaciones de estado y tienen dos propósitos:

  1. El agente de verificación de estado reside dentro de las VM principales y secundarias a fin de supervisar las instancias y comunicarse con el balanceador de cargas para el tráfico directo. Esto es muy útil con grupos de instancias.
  2. El agente de verificación de estado se sincroniza con el plano de control regional específico de la aplicación y toma decisiones de conmutación por error en función del comportamiento del plano de control. El plano de control debe estar en una zona distinta de la instancia cuyo estado se supervisa.

    El propio agente de verificación de estado debe ser tolerante a errores. Por ejemplo, la imagen que sigue al plano de control está separada de la instancia principal, que reside en la zona us-central1-a, al tiempo que la VM en espera reside en la zona us-central1-f.

Función del agente de verificación de estado en la VM

Función del agente de verificación de estado en las instancias de VM principales y en espera.

Conmutación por error

Cuando se detecta una falla en una VM o base de datos principal, el plano de control de la aplicación puede iniciar la conmutación por error a la VM en espera en la zona secundaria. Durante la conmutación por error, el disco persistente regional que se replica de forma síncrona en la zona secundaria se conecta de forma forzada a la VM en espera mediante el plano de control de la aplicación. Así, todo el tráfico se dirige a esa VM en función de las señales de la verificación de estado.

La latencia general de conmutación por error, que excluye el tiempo de detección de fallas, es la suma de las latencias siguientes:

  • Cero segundos para forzar la conexión de un disco persistente regional a una VM en espera
  • Tiempo requerido para la inicialización de la aplicación y la recuperación tras fallas

En la página Componentes básicos para la recuperación ante desastres, se describen los componentes disponibles en la actualidad en Compute Engine. El disco persistente regional agrega otro componente básico clave para las soluciones HA de arquitectura mediante el aprovisionamiento de la replicación en el nivel de disco.

Modos de falla

En la tabla siguiente, se enumeran los diferentes modos de falla y las acciones recomendadas para un servicio que usa discos persistentes regionales.

Categoría de fallas y (probabilidad) Tipos de fallas Acción
Falla de zona (media) El disco solo falla en la zona local. Las fallas pueden ser temporales o de larga duración.



Plano de control de Compute Engine
Fallo de energía
Fallo de Herramientas de redes

Los cortes temporales en las operaciones de disco regionales se controlarán con transparencia mediante un disco persistente regional sin necesidad de que se genere una conmutación por error. Un disco persistente regional detecta de forma automática los errores y la lentitud, cambia los modos de replicación y realiza la actualización de los datos replicados solo en una zona.

En caso de problemas de almacenamiento en una zona principal, un disco regional persistente realiza lecturas de forma automática desde una zona secundaria. Esto puede generar una mayor latencia de las operaciones de lectura. En estas circunstancias, la aplicación podría optar por activar la conmutación por error en función del impacto en el rendimiento.



El plano de control de la aplicación puede activar la conmutación por error en función de los umbrales de verificación de estado.
Falla de la aplicación (alta) La aplicación no responde
Acciones del administrador de la aplicación (por ejemplo, actualización) Error humano
(por ejemplo, configuración incorrecta de los parámetros, como certificado SSL, LCA, etc.)
El plano de control de la aplicación puede activar la conmutación por error en función de los umbrales de la verificación de estado.
Falla de VM (media) Falla de la infraestructura o de hardware
La VM no responde debido a la contención de la CPU o la interrupción de red intermedia
Por lo general, las VM se reparan de forma automática. El plano de control de la aplicación puede activar la conmutación por error en función de los umbrales de la verificación de estado.
Corrupción de la aplicación (baja-media) Corrupción de los datos de aplicación
(por ejemplo, debido a errores de la aplicación o a una mala actualización del SO)
Recuperación de la aplicación:

Desafíos de la replicación de bases de datos

En la tabla siguiente, se enumeran algunos desafíos comunes relacionados con la configuración y administración de la replicación síncrona o semisíncrona de las aplicaciones (como MySQL) y cómo se comparan con la replicación de bloques con discos persistentes regionales.

Desafíos Aplicación síncrona
o replicación semisíncrona
Replicación de bloques con
discos persistentes regionales
Mantenimiento de una replicación estable entre la réplica principal y la conmutación por error. Existen varias acciones que pueden salir mal y generar que una instancia salga del modo HA:
  1. Configuración incorrecta de los parámetros de replicación, como el error de coincidencia del certificado SSL o la falta de LCA del lado principal.
  2. Carga elevada en la instancia principal, lo que genera que la réplica de conmutación por error no pueda mantenerse al día.
  3. Errores que causan problemas de replicación, como problemas de aplicación, configuración incorrecta del SO o falla de Docker.
  4. Fallos de infraestructura como contención de la CPU, VM inmovilizada o interrupción de red intermedia.
Los discos persistentes regionales se encargan de controlar las fallas de almacenamiento. Esto sucede con transparencia en la aplicación, excepto por una posible fluctuación en el rendimiento del disco.
Debe haber verificaciones de estado definidas por el usuario para revelar cualquier aplicación o problemas de VM y activar la conmutación por error.
El tiempo de conmutación por error de extremo a extremo se extiende más de lo deseado. El tiempo necesario para la operación de conmutación por error no tiene un límite superior. Esperar a que se vuelvan a reproducir todas las transacciones (paso 2 anterior) podría llevar mucho tiempo de forma arbitraria según el esquema y la carga en la base de datos. Los discos persistentes regionales proporcionan una replicación síncrona, por lo que el tiempo de conmutación por error dependerá de la suma de las latencias siguientes:
  1. Creación de una VM secundaria, a menos que una instancia de VM ya esté disponible en espera activa.
  2. Adjuntar de manera forzada un disco persistente regional.
  3. Inicialización de la aplicación.
Cerebro dividido Ambos enfoques necesitan aprovisionamiento a fin de garantizar que solo exista una instancia principal a la vez para evitar el cerebro dividido.

Próximos pasos

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Compute Engine