Persistent Disk regional es una opción de almacenamiento que te permite implementar servicios de alta disponibilidad (HA) en Compute Engine. Persistent Disk regional replican datos de forma síncrona entre dos zonas de la misma región y garantizan la alta disponibilidad para los datos en disco hasta una falla zonal.
En este documento, se explica cómo puedes usar Persistent Disk regional para compilar servicios de alta disponibilidad.
Compila servicios de alta disponibilidad con Persistent Disk regional
En esta sección, se explica cómo compilar servicios de alta disponibilidad con Persistent Disk regional.
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 cuando diseñes para una alta disponibilidad:
- El efecto de usar discos persistentes regionales o cualquier otra solución en el rendimiento de escritura de la aplicación y el disco.
- 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.
- El costo de compilar una arquitectura de servicio resiliente y confiable.
En términos de costo, las siguientes opciones son para la replicación de aplicaciones síncrona y asíncrona:
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
Usa una sola VM con discos persistentes regionales. 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.
No inicies la segunda VM hasta que se requiera la conmutación por error. Puedes reducir los costos del host aún más si inicias la copia de seguridad de la VM solo 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 resistencia
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 a la falla de la aplicación) | 2 | 2 | ||
| Costo | $ |
$$
|
$$
|
$1.5x - $$
|
| Rendimiento de la aplicación |
|
|
|
|
| Adecuado para aplicaciones con requisitos de RPO bajos (tolerancia muy baja a la pérdida de datos) |
|
|
|
|
| Tiempo de recuperación de almacenamiento ante desastres4 |
|
|
|
|
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.
3 La 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.
Si hay interrupciones generales en Google Cloud, por ejemplo, si una región completa deja de estar disponible, la aplicación podría dejar de estar disponible. Según tus necesidades, considera usar técnicas de replicación interregionales para obtener una mayor disponibilidad.
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.
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:
|
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:
|
| 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. | |
Verificaciones de estado
El agente de verificación de estado implementa las verificaciones de estado que usa el balanceador de cargas. El agente de verificación de estado tiene dos propósitos:
- El agente de verificación de estado reside dentro de las VMs principal y secundaria a fin de supervisar las instancias de VM y comunicarse con el balanceador de cargas para dirigir el tráfico. Esto funciona mejor cuando se configura con grupos de instancias.
- 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 de VM principal, que reside en la zona us-central1-a, mientras que la VM en espera reside en la zona us-central1-f.
¿Qué sigue?
- Obtén más información sobre cómo crear y administrar volúmenes de Persistent Disk regional.
- Aprende a compilar aplicaciones web escalables y resilientes en Google Cloud.
- Revisa la guía de planificación para la recuperación ante desastres.