El disco persistente regional y la alta disponibilidad equilibrada de hiperdisco son opciones de almacenamiento que te permiten implementar servicios de alta disponibilidad (HA) en Compute Engine. El disco persistente regional y la alta disponibilidad equilibrada de hiperdisco replican datos de forma sincrónica entre dos zonas en la misma región y garantizan HA para los datos del disco en caso de hasta una falla zonal.
Creación de servicios de alta disponibilidad con discos regionales
Esta sección explica cómo puede crear servicios HA conDisco persistente regional oDiscos Hyperdisk equilibrados de alta disponibilidad.
Consideraciones de diseño
Antes de comenzar a diseñar un servicio HA, comprenda 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 aplicación, algunas opciones de diseño correspondientes no son aplicables.
De manera similar, si la aplicación, el sistema de archivos o el sistema operativo no son tolerantes a fallas, entonces usarDisco persistente regional oEs posible que los discos Hyperdisk Balanced High Availability, o incluso las instantáneas de discos zonales, no sean una opción. La tolerancia a fallas se define como la capacidad de recuperarse de una terminación abrupta sin perder ni corromper datos que ya estaban comprometidos en un disco antes de la falla.
Considere lo siguiente al diseñar para alta disponibilidad:
- El efecto en la aplicación del uso de alta disponibilidad equilibrada de Hyperdisk, disco persistente regional, u otras soluciones.
- Rendimiento de escritura en disco.
- El objetivo del tiempo de recuperación del servicio: qué tan rápido debe recuperarse su servicio de una interrupción zonal y los requisitos del SLA.
- El costo de construir una arquitectura de servicios resistente y confiable.
- Para obtener más información sobre consideraciones específicas de la región, consulte Geografía y regiones .
En términos de costo, utilice las siguientes opciones para la replicación de aplicaciones sincrónica y asincrónica:
Utilice dos instancias de la base de datos y la VM. En este caso los siguientes elementos determinan el coste total:
- Costos de instancia de VM
- Disco persistente oCostos de hiperdisco
- Costos de mantener la replicación de aplicaciones.
Utilice una única máquina virtual con discos replicados sincrónicamente. Para lograr una alta disponibilidad con unDisco persistente regional o El disco Hyperdisk Balanced High Availability, utiliza la misma instancia de VM y componentes de disco que la opción anterior, pero también incluye un disco replicado sincrónicamente. Discos persistentes regionales y Los discos Hyperdisk Balanced High Availability tienen el doble de costo por byte en comparación con los discos zonales porque se replican en dos zonas.
Sin embargo, el uso de discos replicados sincrónicamente puede reducir el costo de mantenimiento porque los datos se escriben automáticamente en dos réplicas sin el requisito de mantener la replicación de la aplicación.
No inicie la máquina virtual secundaria hasta que sea necesaria la conmutación por error. Puede reducir aún más los costos del host iniciando la máquina virtual secundaria solo según demanda durante la conmutación por error en lugar de mantener la máquina virtual como una máquina virtual en espera activa.
Compare costos, rendimiento y resiliencia
La siguiente tabla destaca las compensaciones en costo, rendimiento y resiliencia para las diferentes arquitecturas de servicios.
| servicio HA arquitectura | disco zonal instantáneas | Nivel de aplicación sincrónico | Nivel de aplicación asincrónico | Discos regionales |
|---|---|---|---|---|
| Protege contra fallas de aplicaciones, VM y zonas * | ||||
| Mitigación contra la corrupción de aplicaciones (Ejemplo: intolerancia a fallas de aplicaciones) | † | † | ||
| Costo | $ | $$
|
$$
| $1.5x - $$
|
| Rendimiento de la aplicación |
|
|
|
|
| Adecuado para aplicaciones con requisitos de RPO bajo (muy baja tolerancia a la pérdida de datos) |
|
|
|
|
| Tiempo de recuperación de almacenamiento después de un desastre # |
|
|
|
|
* El uso de discos regionales o instantáneas no es suficiente para proteger y mitigar fallas y corrupciones. Su aplicación, sistema de archivos y posiblemente otros componentes de software deben ser compatibles con fallas o utilizar algún tipo de inactividad .
† La replicación de algunas aplicaciones proporciona mitigación contra algunos daños en las aplicaciones. Por ejemplo, la corrupción de la aplicación principal de MySQL no causa que sus instancias de réplica de VM también se corrompan. Revise la documentación de su solicitud para obtener más detalles.
‡ La pérdida de datos significa la pérdida irrecuperable de datos comprometidos en un almacenamiento persistente. Todos los datos no confirmados aún se pierden.
# El rendimiento de la conmutación por error no incluye la verificación del sistema de archivos ni la recuperación y carga de aplicaciones después de la conmutación por error.
Creación de servicios de bases de datos HA utilizando discos regionales
Esta sección cubre conceptos de alto nivel para crear soluciones HA para servicios de bases de datos con estado (MySQL, Postgres, etc.) usando Compute Engine conDiscos persistentes regionales y Discos Hyperdisk equilibrados de alta disponibilidad.
Si hay cortes generalizados en Google Cloud, por ejemplo, si toda una región deja de estar disponible, su aplicación podría dejar de estar disponible. Dependiendo de sus necesidades, considere técnicas de replicación interregionalo replicación asincrónica para una disponibilidad aún mayor.
Las configuraciones de HA de base de datos suelen tener al menos dos instancias de VM. Preferiblemente, estas instancias de VM son 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 un disco regional. El disco regional contiene datos de la base de datos y cualquier otro dato mutable que debe conservarse en otra zona en caso de una interrupción.
Una instancia de VM en espera requiere un disco de arranque separado para poder recuperarse de interrupciones relacionadas con la configuración, que podrían resultar de una actualización del sistema operativo, por ejemplo. Además, no puede forzar la conexión de un disco de arranque a otra máquina virtual durante una conmutación por error.
Las instancias de VM principal y en espera están configuradas para usar un equilibrador de carga con el tráfico dirigido a la VM principal en función de las señales de verificación de estado. El escenario de recuperación ante desastres para datos describe otras configuraciones de conmutación por error, que podrían ser más apropiadas para su escenario.
Desafíos con la replicación de bases de datos
La siguiente tabla enumera algunos desafíos comunes con la configuración y administración de la replicación síncrona o semisíncrona de aplicaciones (como MySQL) y cómo se comparan con la replicación de disco síncrona conDisco persistente regional y Discos Hyperdisk equilibrados de alta disponibilidad.
| Desafíos | Aplicación sincrónica o replicación semisincrónica | Replicación de disco síncrona |
|---|---|---|
| Mantener una replicación estable entre la réplica principal y la de conmutación por error. | Hay una serie de cosas que podrían salir mal y hacer que una instancia de VM salga del modo HA:
| Los fallos de almacenamiento son manejados por Disco persistente regional y Discos Hyperdisk equilibrados de alta disponibilidad. Esto sucede de forma transparente para la aplicación, excepto por una posible fluctuación en el rendimiento del disco. Deben existir comprobaciones de estado definidas por el usuario para revelar cualquier problema de aplicación o VM y activar la conmutación por error. |
| El tiempo de conmutación por error de un extremo a otro es mayor de lo esperado. | El tiempo necesario para la operación de conmutación por error no tiene límite superior. Esperar a que se reproduzcan todas las transacciones (paso 2 anterior) podría llevar un tiempo arbitrariamente largo, según el esquema y la carga de la base de datos. | Disco persistente regional y Los discos Hyperdisk Balanced High Availability proporcionan replicación síncrona, por lo que el tiempo de conmutación por error está limitado por la suma de las siguientes latencias:
|
| Cerebro dividido | Para evitar el cerebro dividido , ambos enfoques requieren disposiciones que garanticen que solo haya un cerebro primario a la vez. | |
Secuencia de operaciones de lectura y escritura en discos.
Para determinar las secuencias de lectura y escritura, o el orden en que se leen y escriben los datos en el disco, la mayor parte del trabajo lo realiza el controlador de disco de su máquina virtual. Como usuario, no tiene que lidiar con la semántica de replicación y puede interactuar con el sistema de archivos como de costumbre. El controlador subyacente maneja la secuencia de lectura y escritura.
De forma predeterminada, una VM de Compute Engine conDisco persistente regional oHyperdisk Balanced High Availability funciona en modo de replicación completa, donde las solicitudes de lectura o escritura desde el disco se envían a ambas réplicas.
En modo de replicación completa, ocurre lo siguiente:
- Al escribir, una solicitud de escritura intenta escribir en ambas réplicas y reconoce cuando ambas escrituras se realizan correctamente.
- Al leer, la VM envía una solicitud de lectura a ambas réplicas y devuelve los resultados de la que tiene éxito. Si la solicitud de lectura caduca, se envía otra solicitud de lectura.
Si una réplica se retrasa o no reconoce que se completaron las solicitudes de lectura o escritura, se actualiza el estado de la réplica .
Controles de salud
Las comprobaciones de estado utilizadas por el equilibrador de carga las implementa el agente de comprobación de estado. El agente de control de salud tiene dos propósitos:
- El agente de verificación de estado reside dentro de las VM primarias y secundarias para monitorear las instancias de VM y comunicarse con el equilibrador de carga 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 basadas en el comportamiento del plano de control. El plano de control debe estar en una zona que difiera de la instancia de VM cuyo estado está monitoreando.
El propio agente de verificación de estado debe ser tolerante a fallas. Por ejemplo, observe que, en la imagen siguiente, 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?
- Aprenda a crear y administrar discos regionales .
- Obtenga más información sobre la replicación asincrónica .
- Aprenda a configurar una instancia de clúster de conmutación por error de SQL Server para discos en modo de escritura múltiple .
- Aprenda a crear aplicaciones web escalables y resistentes en Google Cloud .
- Revise la guía de planificación de recuperación ante desastres .