Esta arquitectura de referencia proporciona un framework conceptual para implementar y operar bases de datos de MySQL 8.4 de alta disponibilidad administradas por el cliente en Google Distributed Cloud (GDC) aislado. Permite que los clientes empresariales y de acceso anticipado mantengan de forma confiable las cargas de trabajo de bases de datos esenciales con una configuración de máquina virtual (VM) multizona sólida.
Debido a que GDC aislado no admite clústeres extendidos de Kubernetes 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 multizona: Es una configuración de 3 nodos altamente resiliente que se implementa en tres zonas de disponibilidad distintas para proteger contra fallas de una sola zona de infraestructura.
- Alta disponibilidad y consenso automatizados: Usa la replicación de grupos 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 inteligente del tráfico: Las instancias de MySQL Router ubicadas en el mismo lugar administran el enrutamiento de las conexiones. El router dirige las operaciones de escritura (por ejemplo, el puerto 6446) estrictamente a un nodo principal activo y balancea las cargas de las operaciones de lectura (por ejemplo, el puerto 6447) entre las réplicas sincronizadas.
- Balanceo de cargas global: Se integra en el balanceador de cargas de L4 global 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. La replicación de grupos aplica un modelo basado en Paxos que requiere un acuerdo mayoritario, lo que elimina el riesgo de pérdida de datos o de división de cerebro durante las particiones de red.
- Separación de problemas: Desvincula el motor de base de datos y la capa de consenso (replicación de grupo) de la capa de enrutamiento del tráfico del cliente (MySQL Router), a la vez que simplifica la administración del ciclo de vida del clúster con MySQL Shell.
- Optimización de la infraestructura: Se diseñó específicamente para entornos aislados, con VMs sólidas para omitir las limitaciones actuales de las herramientas de redes de Kubernetes.
Arquitectura
Conceptos y tecnologías
En esta sección, se detallan los componentes funcionales y sus responsabilidades específicas dentro de la arquitectura multizona.
Infraestructura y plataforma
- Máquinas virtuales (VMs): Tres instancias de procesamiento dedicadas, cada una implementada en una zona de disponibilidad independiente para formar los límites del dominio con fallas.
- Balanceador de cargas de L4 global de GDC: Es una construcción de red 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: Es el motor de base de datos relacional principal.
- Replicación de grupo/clúster de InnoDB: Es el framework de agrupamiento en clústeres integrado responsable de la replicación de varios maestros y de verificar el quórum de nodos con Paxos.
- MySQL Shell: Es la interfaz de línea de comandos unificada 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 las escrituras y round-robin para las lecturas.
Flujo de datos e interfaces
- Las aplicaciones envían solicitudes de base de datos a la VIP del balanceador de cargas de L4 global de GDC.
- El balanceador de cargas envía la conexión a una instancia de MySQL Router en buen estado en una de las VMs.
- Según el puerto solicitado, MySQL Router reenvía el tráfico de forma dinámica: El puerto 6446 se orienta estrictamente al nodo activo para las operaciones de escritura, mientras que el puerto 6447 alterna las operaciones de lectura en todo el clúster.
Consideraciones
- Compensaciones entre rendimiento y coherencia: Debido a que la replicación de grupos aplica el consenso, las transacciones requieren el reconocimiento de los pares del clúster. El rendimiento se correlaciona directamente con la latencia de red entre zonas dentro del entorno de GDC.
- Administración de recursos: Implementar 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 de la agrupación de conexiones agote los procesos principales de MySQL.
Decisión de diseño
- Máquinas virtuales en Kubernetes: GDC aislado no admite clústeres de Kubernetes que abarquen varias zonas físicas. Se eligió un enfoque basado en VM de forma estricta porque implementar VMs dedicadas en zonas separadas es el único método viable para lograr una verdadera alta disponibilidad multizona y sobrevivir a una falla total de la zona.
- InnoDB Cluster frente a Orchestrator y ProxySQL: Se evaluó como una alternativa viable una arquitectura principal/secundaria tradicional vinculada con ProxySQL y Orchestrator. Sin embargo, se seleccionó el clúster de InnoDB integrado (replicación de grupo + MySQL Router + MySQL Shell) porque elimina la dependencia de las superposiciones de enrutamiento de terceros y simplifica de forma drástica la complejidad operativa en torno a las conmutaciones por error, ya que mantiene el consenso directamente dentro de MySQL.
- Balanceo de cargas global integrado en la plataforma: El uso del balanceador de cargas L4 global de GDC integrado garantiza que la VIP esté controlada por el plano de control de GDC, lo que mantiene la resiliencia del punto de entrada y simplifica la entrega de tráfico entre zonas.
Suposiciones y limitaciones
Suposiciones
- Disponibilidad de la infraestructura: Los clientes tienen suficiente cuota de proyecto para aprovisionar VMs dedicadas y de tamaño adecuado, y balanceadores de cargas globales distribuidos de manera uniforme en tres zonas de disponibilidad.
- Herramientas de redes seguras: Se establecen el acceso basado en claves y las ProjectNetworkPolicies (PNP) adecuadas para permitir la sincronización de la replicación de grupos 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 alta disponibilidad multizona hasta que la plataforma admita por completo los clústeres extendidos.
- Se requieren actualizaciones manuales: A diferencia de los servicios administrados, esta solución coloca la responsabilidad de la aplicación de parches de rutina a nivel del SO y las actualizaciones de versiones secundarias de la base de datos por completo en el cliente.
- Sensibilidad a la latencia de la red: La replicación exige una red estable y de alta calidad. La inestabilidad de la red o los picos de latencia entre las zonas aisladas retrasarán proporcionalmente las operaciones de escritura en el clúster de MySQL.
Materiales adicionales
- Implementación de referencia de la solución (SRI): Implementación de referencia de la solución para MySQL 8 de alta disponibilidad y multizona en GDC aislado