Cette architecture de référence fournit un framework conceptuel pour déployer et exploiter des bases de données MySQL 8.4 gérées par le client et à disponibilité élevée sur Google Distributed Cloud (GDC) sous air gap. Il permet aux clients d'entreprise et en accès anticipé de gérer de manière fiable les charges de travail de base de données critiques à l'aide d'une configuration de machine virtuelle (VM) multizone robuste.
Comme GDC sous air gap n'est pas compatible avec les clusters Kubernetes étendus entre plusieurs zones, cette architecture repose strictement sur des VM dédiées déployées sur trois domaines de disponibilité pour assurer des opérations continues et résister à une défaillance complète de zone sans perte de données.
Fonctionnalités et capacités
- Résilience multizone : configuration à trois nœuds hautement résiliente déployée sur trois zones de disponibilité distinctes pour se protéger contre les défaillances d'une seule zone d'infrastructure.
- Haute disponibilité et consensus automatisés : utilise la réplication de groupe pour le clustering de consensus basé sur Paxos, ce qui permet la détection automatique des défaillances, l'accord des nœuds et la synchronisation globale des données sans scénarios de split-brain.
- Routage intelligent du trafic : les instances MySQL Router colocalisées gèrent le routage des connexions. Le routeur dirige les opérations d'écriture (par exemple, le port 6446) strictement vers un nœud principal actif et équilibre la charge des opérations de lecture (par exemple, le port 6447) sur les instances répliquées synchronisées.
- Équilibrage de charge mondial : s'intègre à l'équilibreur de charge L4 mondial GDC intégré pour fournir une adresse IP virtuelle (VIP) unique et stable aux applications clientes, en faisant abstraction de la topologie de nœud sous-jacente.
Principes architecturaux
- Consensus basé sur le quorum : privilégie une cohérence stricte des données. La réplication de groupe applique un modèle basé sur Paxos qui nécessite un accord majoritaire, ce qui élimine le risque de perte de données ou de split-brain lors des partitions réseau.
- Séparation des responsabilités : dissocie le moteur de base de données et la couche de consensus (Group Replication) de la couche de routage du trafic client (MySQL Router), tout en simplifiant la gestion du cycle de vie du cluster à l'aide de MySQL Shell.
- Optimisation de l'infrastructure : spécialement conçu pour les environnements air gap, en utilisant des VM robustes pour contourner les limites actuelles de la mise en réseau Kubernetes.
Architecture
Concepts et technologies
Cette section détaille les composants fonctionnels et leurs responsabilités spécifiques au sein de l'architecture multizone.
Infrastructure et plate-forme
- Machines virtuelles (VM) : trois instances de calcul dédiées, chacune déployée dans une zone de disponibilité distincte pour former les limites du domaine de défaillance.
- Équilibreur de charge L4 global GDC : construction réseau gérée par la plate-forme qui expose une adresse IP virtuelle interne stable, évaluant automatiquement les vérifications d'état du routeur MySQL pour rediriger le trafic entrant.
Services et logique
- MySQL 8.4 : moteur de base de données relationnelle de base.
- Group Replication/InnoDB Cluster : framework de clustering intégré responsable de la réplication multimaster et de la vérification du quorum des nœuds à l'aide de Paxos.
- MySQL Shell : interface de ligne de commande unifiée utilisée spécifiquement pour configurer, provisionner et administrer les instances de cluster InnoDB.
- Routeur MySQL : agit comme routeur de trafic sur chaque VM. Configuré de manière dynamique pour écouter les métadonnées du cluster et transférer le trafic : actif/sauvegarde pour les écritures et tourniquet (round-robin) pour les lectures.
Flux de données et interfaces
- Les applications envoient des requêtes de base de données à l'adresse IP virtuelle de l'équilibreur de charge L4 global GDC.
- L'équilibreur de charge transmet la connexion à une instance MySQL Router opérationnelle sur l'une des VM.
- En fonction du port demandé, le routeur MySQL transfère le trafic de manière dynamique : le port 6446 cible strictement le nœud actif pour les écritures, tandis que le port 6447 effectue des cycles de lecture sur le cluster.
Remarques
- Compromis entre performances et cohérence : étant donné que la réplication de groupe applique un consensus, les transactions nécessitent l'approbation des pairs du cluster. Les performances sont directement corrélées à la latence du réseau interzone dans l'environnement GDC.
- Gestion des ressources : le déploiement de MySQL Router directement sur les VM de base de données optimise l'utilisation du matériel, mais nécessite un réglage minutieux des ressources pour éviter que la surcharge du pooling de connexions ne prive les processus MySQL principaux de ressources.
Décision de conception
- Machines virtuelles sur Kubernetes : GDC sous air gap n'est pas compatible avec les clusters Kubernetes qui s'étendent sur plusieurs zones physiques. Une approche basée sur les VM a été choisie, car le déploiement de VM dédiées dans des zones distinctes est la seule méthode viable pour obtenir une véritable haute disponibilité multizone et survivre à une défaillance totale de la zone.
- Cluster InnoDB par rapport à Orchestrator et ProxySQL : une architecture principale/secondaire traditionnelle associée à ProxySQL et Orchestrator a été évaluée comme une alternative possible. Cependant, le cluster InnoDB intégré (Group Replication + MySQL Router + MySQL Shell) a été sélectionné à la place, car il élimine la dépendance vis-à-vis des superpositions de routage tierces et simplifie considérablement la complexité opérationnelle liée aux basculements en conservant le consensus directement dans MySQL.
- Équilibrage de charge mondial intégré à la plate-forme : l'utilisation de l'équilibreur de charge L4 mondial GDC intégré garantit que l'adresse IP virtuelle est contrôlée par le plan de contrôle GDC, ce qui maintient la résilience du point d'entrée et simplifie la distribution du trafic entre les zones.
Hypothèses et limites
Hypothèses
- Disponibilité de l'infrastructure : les clients disposent d'un quota de projet suffisant pour provisionner des VM dédiées et correctement dimensionnées, ainsi que des équilibreurs de charge mondiaux répartis de manière uniforme sur trois zones de disponibilité.
- Mise en réseau sécurisée : l'accès basé sur des clés et les règles ProjectNetworkPolicies (PNP) appropriées sont établis pour permettre la synchronisation de la réplication de groupe au sein du cluster et le trafic du routeur MySQL.
Limites
- Kubernetes non compatible : les clients qui recherchent strictement des solutions conteneurisées/basées sur Kubernetes ne peuvent pas obtenir de haute disponibilité multizone tant que les clusters étendus ne sont pas entièrement compatibles avec la plate-forme.
- Mises à niveau manuelles requises : contrairement aux services gérés, cette solution place l'entière responsabilité des correctifs de routine au niveau de l'OS et des mises à niveau de version mineure de la base de données sur le client.
- Sensibilité à la latence du réseau : la réplication nécessite un réseau stable et de haute qualité. La gigue du réseau ou les pics de latence entre les zones sous air gap retarderont proportionnellement les opérations d'écriture sur le cluster MySQL.
Autres ressources
- Implémentation de référence de la solution (SRI) : Implémentation de référence de la solution pour MySQL 8 multizone à haute disponibilité dans GDC sous air gap