Opciones de alta disponibilidad con PD 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.

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 componente básico para usar cuando implementas servicios de alta disponibilidad en Compute Engine.

El beneficio de los discos persistentes regionales es que, en caso de una interrupción zonal en la que la instancia de máquina virtual (VM) deja de estar disponible, puedes forzar la conexión de un disco persistente regional a una instancia de VM en una zona secundaria de la misma región. Para ello, debes iniciar otra instancia de VM en la misma zona en la que se encuentra el disco persistente regional que vas a conectar de manera forzada o mantener una instancia de VM en espera activa en esa zona. Una instancia de VM en espera activa es una instancia de VM en ejecución que es idéntica a la que usas. Las dos instancias tienen los mismos datos.

La operación de conexión forzada se ejecuta en menos de un minuto. El objetivo de tiempo de recuperación (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, del tiempo en que el sistema de archivos subyacente detecta un disco activo conectado, del tiempo de recuperación de las aplicaciones correspondientes y de otros factores.

El disco persistente regional favorece la disponibilidad de la carga de trabajo, lo que significa que hay compensaciones para la protección de datos en el caso improbable de que ambas réplicas de disco dejen de estar disponibles al mismo tiempo. Para obtener más información, consulta Conmutación por error del disco persistente regional.

Compila servicios de alta disponibilidad con discos persistentes regionales

Consideraciones del diseño

Antes de comenzar a diseñar un servicio de 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 ayudarte a descartar diversos 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, es posible que usar discos persistentes regionales o incluso instantáneas de discos persistentes zonales no sea una opción. La tolerancia a fallas se define como la capacidad 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. Debes conocer el efecto en el rendimiento de la aplicación y de la escritura.
  2. Debes determinar el objetivo de 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. Debes conocer el costo de compilar una arquitectura de servicio resiliente y confiable. En términos de costo, las siguientes opciones son para la replicación síncrona y asíncrona de la aplicación:

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

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

    Si quieres lograr una alta disponibilidad con un disco persistente regional, debes usar los mismos componentes de instancia de VM y disco persistente, pero también debes 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 resistencia para las diferentes arquitecturas de servicio.

Arquitectura
de servicio de HA
Instantáneas de discos
persistentes zonales
Nivel de aplicación
síncrono
Nivel de la aplicación
asíncrono
Solución de HA
con discos persistentes regionales
Protege contra fallas de zona, VM y aplicaciones1
Mitigación contra los daños de la aplicación (ejemplo: intolerancia al fallo de la aplicación)2
Costo $ $$

  • Dos instancias de la base de datos o VM en ejecución, el mantenimiento y la configuración de la replicación de aplicaciones y las redes entre zonas.
$$

  • Dos instancias de la base de datos o VM en ejecución, el mantenimiento y la configuración de la replicación de aplicaciones y las redes entre zonas.
$1.5x - $$

  • Los costos son los mismos que para la replicación de aplicaciones si usas una instancia en espera activa. Puedes lograr reducir el costo si aceleras la copia de seguridad de la VM a pedido durante la conmutación por error. No se aplican cargos por las redes entre zonas entre las réplicas de los discos persistentes regionales.
Rendimiento de la aplicación

  • Sin efecto


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

  • Sin efecto


  • Sin efecto para la mayoría de las aplicaciones
Adecuado para aplicaciones con requisitos de RPO bajos (tolerancia muy baja 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 porque la replicación es asíncrona


  • Sin pérdida de datos
Tiempo de recuperación de almacenamiento del desastre4
  • 0 (minutos)
  • 0 (segundos)
  • 0 (segundos)
  • 0 (segundos) para forzar la conexión del disco a una instancia de VM en espera

1 No 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 de MySQL no hará que las 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 en el almacenamiento continuo. Se perderán todos los datos que no estén confirmados.

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

Crea servicios de bases de datos de alta disponibilidad con discos persistentes regionales

En esta sección, se describen los conceptos de alto nivel a fin de compilar soluciones de HA para servicios de bases de datos con estado (MySQL, Postgres, etc.) mediante discos persistentes regionales y Compute Engine. Se describe la mitigación de interrupciones de zonas únicas. Una aplicación puede dejar de estar disponible en caso de interrupciones más amplias, por ejemplo, si una región completa deja de estar disponible. En función de tus necesidades, te recomendamos 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 modificable que deba 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”. En la situación de recuperación ante desastres para datos, se describen otras opciones de configuración 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 principal y secundaria a fin de supervisar las instancias y comunicarse con el balanceador de cargas para dirigir el tráfico. Esto es muy útil para los 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, observa que, en la siguiente imagen, el plano de control está separado de la instancia principal, que reside en la zona us-central1-a, mientras que la VM en espera reside en la zona us-central1-f.

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

La función del agente de verificación de estado en las instancias de VM principal 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 los indicadores de la verificación de estado.

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

  • Cero segundos para forzar la conexión de un disco persistente regional a una VM en espera
  • Tiempo necesario para la inicialización de la aplicación y la recuperación ante 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.

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 aplicaciones (como MySQL) y se muestra 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 instancia principal y la réplica de conmutación por error Existen varios aspectos que pueden salir mal y generar que una instancia salga del modo de alta disponibilidad:
  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 de la instancia principal
  2. Carga elevada en la instancia principal, lo que genera que la réplica de conmutación por error no pueda mantenerse actualizada
  3. Errores que causan problemas de replicación, como problemas de la aplicación, una configuración incorrecta del SO o fallas de Docker
  4. Fallas de infraestructura como contención de la CPU, una VM detenida o una 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 problema de aplicación o 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 máximo. La espera para que se reanuden todas las transacciones (paso 2 anterior) puede llevar mucho tiempo, según el esquema y la carga de 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 siguientes latencias:
  1. Creación de una VM secundaria, a menos que una instancia de VM ya esté disponible en espera activa.
  2. Conexión forzada de un disco persistente regional
  3. Inicialización de la aplicación
Cerebro dividido Para evitar un problema de cerebro dividido, ambos enfoques necesitan aprovisionamiento a fin de garantizar que solo exista una instancia principal a la vez.

¿Qué sigue?