Regional Persistent Disk y Hyperdisk Balanced High Availability son opciones de almacenamiento que te permiten implementar servicios de alta disponibilidad en Compute Engine. Regional Persistent Disk y Hyperdisk Balanced High Availability replican de forma síncrona los datos entre dos zonas de la misma región y garantizan la alta disponibilidad para los datos de disco hasta una falla zonal.
Compila servicios de alta disponibilidad con discos replicados
En esta sección, se explica cómo puedes compilar servicios de alta disponibilidad con discos con discos deRegional Persistent Disk oHyperdisk Balanced High Availability.
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, entonces puede que usar discos deRegional Persistent Disk o deHyperdisk Balanced High Availability (vista previa), o incluso instantáneas de discos zonales, no sea posible 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 antes de la falla.
Ten en cuenta lo siguiente cuando diseñes para alta disponibilidad:
- El efecto en la aplicación del uso de la Hyperdisk Balanced High Availabilityo Regional Persistent Disk o cualquier otra solución
- Rendimiento de escritura en el disco
- El objetivo de tiempo de recuperación del servicio: 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 costos, usa las siguientes opciones 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 de Persistent Disk oHyperdisk
- Costos de mantenimiento de la replicación de aplicaciones
Usa una sola VM con discos replicados de forma síncrona. Para lograr una alta disponibilidad con un disco deRegional Persistent Disk o un disco de Hyperdisk Balanced High Availability, usa los mismos componentes de instancia de VM y disco que en la opción anterior, pero también incluye un disco replicado de forma síncrona. Los discos Persistent Disks Regional y los discos de Hyperdisk Balanced High Availability tienen el doble del costo por byte en comparación con los discos zonales porque se replican en dos zonas.
Sin embargo, el uso de discos replicados de forma síncrona puede reducir el costo de mantenimiento debido a que los datos se escriben de forma automática en dos réplicas sin necesidad de mantener la replicación de aplicaciones.
No inicies la VM secundaria hasta que se requiera la conmutación por error. Puedes reducir los costos del host aún más si inicias la VM secundaria solo a pedido durante la conmutación por error, en lugar de mantener la VM como una VM en 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 zonales |
Nivel de aplicación síncrono |
Nivel de la aplicación asíncrono |
Discos replicados de forma síncrona |
|---|---|---|---|---|
| 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 replicados 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.
2 La 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 VM de réplica se dañen también. 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.
Compila servicios de bases de datos de alta disponibilidad con discos replicados de forma síncrona
En esta sección, se describen los conceptos de alto nivel para compilar soluciones de alta disponibilidad para servicios de bases de datos con estado (MySQL, Postgres, etc.) mediante Compute Engine condiscos de Persistent Disks regionales y discos de Hyperdisk Balanced High Availability (vista previa).
Si hay interrupciones generales en Google Cloud, por ejemplo, si una región completa deja de estar disponible, es posible que la aplicación deje de estar disponible. Según tus necesidades, considera usar técnicas de replicación interregionaleso Persistent Disk Asynchronous Replication (PD Async Replication) para obtener 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: un disco de arranque y uno replicado. El disco replicado 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. Además, 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. 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 disco síncrona con discos deRegional Persistent Diskes y discos de Hyperdisk Balanced High Availability (Vista previa).
| Desafíos | Aplicación síncrona o replicación semisíncrona |
Replicación de discos sincrónica |
|---|---|---|
| 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:
|
Las fallas de almacenamiento se controlan mediante discos de Regional Persistent Diskes y discos de Hyperdisk Balanced High Availability. 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 esperado. | 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 deRegional Persistent Diskes y y los discos de Hyperdisk Balanced High Availability proporcionan 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. | |
Secuencia de operaciones de lectura y escritura en discos
Para determinar las secuencias de lectura y escritura, o el orden en el que se leen y escriben los datos en el disco, el controlador de disco de tu VM realiza la mayor parte del trabajo. Como usuario, no tienes que lidiar con la semántica de replicación y puedes interactuar con el sistema de archivos como de costumbre. El controlador subyacente controla la secuencia para lectura y escritura.
De forma predeterminada, una VM de Compute Engine conRegional Persistent Disk oHyperdisk Balanced High Availability (vista previa) funciona en modo de replicación completa, en el que las solicitudes de lectura o escritura desde el disco se envían a ambas réplicas.
En el modo de replicación completa, ocurre lo siguiente:
- Cuando se escribe, una solicitud de escritura intenta escribir en ambas réplicas y confirma cuando ambas operaciones de escritura se realizan correctamente.
- Cuando se realiza la lectura, la VM envía una solicitud de lectura a ambas réplicas y muestra los resultados de la que se ejecuta de forma correcta. Si se agota el tiempo de espera de la solicitud de lectura, se envía otra solicitud de lectura.
Si una réplica se retrasa o falla en confirmar que las solicitudes de lectura o escritura se completaron, entonces el estado de la réplica se actualiza.
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 discos replicados de forma síncrona.
- Obtén más información sobre la replicación asíncrona de Persistent Disks.
- Aprende a compilar aplicaciones web escalables y resilientes en Google Cloud.
- Revisa la guía de planificación para la recuperación ante desastres.