Arquitectura de referencia de la base de datos de MySQL en GDC aislado

Esta arquitectura de referencia proporciona un marco conceptual para implementar y operar bases de datos MySQL 8.4 de alta disponibilidad administradas por el cliente en Google Distributed Cloud (GDC) air-gapped. Permite a los clientes empresariales y de acceso anticipado mantener de forma confiable cargas de trabajo de bases de datos críticas con una configuración sólida de máquina virtual (VM) de varias zonas.

Debido a que GDC air-gapped no admite clústeres de Kubernetes extendidos entre zonas, esta arquitectura se basa estrictamente en VMs dedicadas implementadas en tres dominios de disponibilidad para garantizar operaciones continuas y resistir una falla de zona completa sin pérdida de datos.

Características y funciones

  • Resiliencia en varias zonas: Una configuración de 3 nodos altamente resistente implementada en tres zonas de disponibilidad distintas para proteger contra fallas de una sola zona de infraestructura.
  • Alta disponibilidad y consenso automatizados: Usa Group Replication para el agrupamiento en clústeres de consenso basado en Paxos, lo que proporciona detección automática de fallas, acuerdo de nodos y sincronización de datos global sin situaciones de cerebro dividido.
  • Enrutamiento de tráfico inteligente: Las instancias de MySQL Router ubicadas en el mismo lugar administran el enrutamiento de la conexión. El router dirige las operaciones de escritura (por ejemplo, el puerto 6446) estrictamente a un nodo principal activo y balancea las operaciones de lectura (por ejemplo, el puerto 6447) en las réplicas sincronizadas.
  • Balanceo de cargas global: Se integra con el balanceador de cargas global L4 de GDC integrado para proporcionar una sola IP virtual (VIP) estable para las aplicaciones cliente, lo que abstrae la topología de nodos subyacente.

Principios de arquitectura

  • Consenso basado en quórum: Prioriza la coherencia estricta de los datos. Group Replication aplica un modelo basado en Paxos que requiere un acuerdo mayoritario, lo que elimina el riesgo de pérdida de datos o cerebro dividido durante las particiones de red.
  • Separación de intereses: Desacopla el motor de base de datos y la capa de consenso (Group Replication) de la capa de enrutamiento de tráfico del cliente (MySQL Router), mientras simplifica la administración del ciclo de vida del clúster con MySQL Shell.
  • Optimización de la infraestructura: Diseñada específicamente para entornos air-gapped, utiliza VMs sólidas para evitar las limitaciones actuales de las redes de Kubernetes.

Arquitectura

Arquitectura de tres VMs que ejecuta una pila de servicios colocados.

Conceptos y tecnologías

En esta sección, se detallan los componentes funcionales y sus responsabilidades específicas dentro de la arquitectura de varias zonas.

Infraestructura y plataforma

  • Máquinas virtuales (VMs): Tres instancias de Compute dedicadas, cada una implementada en una zona de disponibilidad separada para formar los límites del dominio de fallas.
  • Balanceador de cargas global L4 de GDC: Una construcción de redes administrada por la plataforma que expone una VIP interna estable y evalúa automáticamente las verificaciones de estado de MySQL Router para redireccionar el tráfico entrante.

Servicios y lógica

  • MySQL 8.4: El motor de base de datos relacional principal.
  • Group Replication / InnoDB Cluster: El framework de agrupamiento en clústeres integrado responsable de la replicación de varios maestros y la verificación del quórum de nodos con Paxos.
  • MySQL Shell: La interfaz unificada de línea de comandos que se usa específicamente para configurar, aprovisionar y administrar las instancias del clúster de InnoDB.
  • MySQL Router: Actúa como el router de tráfico en cada VM. Se configura de forma dinámica para escuchar los metadatos del clúster y reenviar el tráfico: activo/copia de seguridad para escrituras y round-robin para lecturas.

Flujo de datos e interfaces

  1. Las aplicaciones envían solicitudes de bases de datos a la VIP del balanceador de cargas global L4 de GDC.
  2. El balanceador de cargas hace un proxy de la conexión a una instancia de MySQL Router en buen estado en una de las VMs.
  3. Según el puerto solicitado, MySQL Router reenvía el tráfico de forma dinámica: el puerto 6446 apunta estrictamente al nodo activo para las escrituras, mientras que el puerto 6447 realiza ciclos de lecturas en el clúster.

Consideraciones

  • Compensaciones de rendimiento y coherencia: Debido a que Group Replication aplica el consenso, las transacciones requieren el reconocimiento de los pares del clúster. El rendimiento se correlaciona directamente con la latencia de la red entre zonas dentro del entorno de GDC.
  • Administración de recursos: La implementación de MySQL Router directamente en las VMs de la base de datos optimiza el uso del hardware, pero requiere un ajuste cuidadoso de los recursos para evitar que la sobrecarga del grupo de conexiones prive de recursos a los procesos principales de MySQL.

Decisión de diseño

  • Máquinas virtuales en lugar de Kubernetes: GDC air-gapped no admite clústeres de Kubernetes que abarquen varias zonas físicas. Se eligió estrictamente un enfoque basado en VM porque la implementación de VMs dedicadas en zonas separadas es el único método viable para lograr una verdadera alta disponibilidad en varias zonas y sobrevivir a una falla total de la zona.
  • InnoDB Cluster en comparación con Orchestrator y ProxySQL: Se evaluó una arquitectura tradicional principal/secundaria combinada con ProxySQL y Orchestrator como una alternativa viable. Sin embargo, se seleccionó el InnoDB Cluster integrado (Group Replication + MySQL Router + MySQL Shell) porque elimina la dependencia de las superposiciones de enrutamiento de terceros y simplifica drásticamente la complejidad operativa en torno a las conmutaciones por error, ya que mantiene el consenso directamente en MySQL.
  • Balanceo de cargas global integrado en la plataforma: Aprovechar el balanceador de cargas global L4 de GDC integrado garantiza que el plano de control de GDC controle la VIP, lo que mantiene el punto de entrada resistente y simplifica la entrega de tráfico entre zonas.

Suposiciones y limitaciones

Suposiciones

  • Disponibilidad de la infraestructura: Los clientes tienen cuota de proyecto suficiente para aprovisionar VMs dedicadas y con el tamaño adecuado, y balanceadores de cargas globales distribuidos de manera uniforme en tres zonas de disponibilidad.
  • Redes seguras: Se establecen el acceso basado en claves y las ProjectNetworkPolicies (PNPs) adecuadas para permitir la sincronización de Group Replication dentro del clúster y el tráfico de MySQL Router.

Limitaciones

  • Kubernetes no compatible: Los clientes que buscan estrictamente soluciones basadas en contenedores o Kubernetes no pueden lograr la HA en varias zonas hasta que la plataforma admita por completo los clústeres extendidos.
  • Se requieren actualizaciones manuales: A diferencia de los servicios administrados, esta solución le otorga al cliente la responsabilidad de aplicar parches de rutina a nivel del SO y actualizar las versiones secundarias de la base de datos.
  • Sensibilidad a la latencia de la red: La replicación exige una red estable y de alta calidad. Las fluctuaciones de la red o los picos de latencia entre las zonas air-gapped retrasarán proporcionalmente las operaciones de escritura en el clúster de MySQL.

Materiales adicionales