Cette architecture de référence fournit un cadre conceptuel pour déployer et exploiter des bases de données MySQL 8.4 à disponibilité élevée gérées par le client sur Google Distributed Cloud (GDC) air-gapped. Elle permet aux entreprises et aux clients ayant un accès anticipé de maintenir de manière fiable des charges de travail de base de données critiques à l'aide d'une configuration de machine virtuelle (VM) multizone robuste.
Étant donné que GDC sous air gap n'est pas compatible avec les clusters Kubernetes étendus interzones, 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 de zone complète 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 Group Replication pour le clustering de consensus basé sur Paxos, ce qui permet une détection automatique des défaillances, un accord de nœud et une synchronisation globale des données sans scénario 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 répliques 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 : donne la priorité à la cohérence stricte des données. Group Replication 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 préoccupations : 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çue pour les environnements air-gapped, en utilisant des VM robustes pour contourner les limites actuelles de la mise en réseau Kubernetes.
Architecture
Concepts et technologies
Cette section décrit les composants fonctionnels et leurs responsabilités spécifiques au sein de l'architecture multizone.
Infrastructure et plate-forme
- Machines virtuelles (VM) : trois instances Compute 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 mondial GDC : construction de mise en réseau gérée par la plate-forme qui expose une adresse IP virtuelle interne stable, en évaluant automatiquement les vérifications d'état de MySQL Router pour rediriger le trafic entrant.
Services et logique
- MySQL 8.4 : moteur de base de données relationnelle principal.
- Group Replication / InnoDB Cluster : framework de clustering intégré responsable de la réplication multimaître et de la vérification du quorum de 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.
- MySQL Router : 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 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 mondial GDC.
- L'équilibreur de charge proxy la connexion à une instance MySQL Router opérationnelle sur l'une des VM.
- En fonction du port demandé, MySQL Router 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 fait circuler les lectures dans le cluster.
Remarques
- Compromis entre performances et cohérence : étant donné que Group Replication applique un consensus, les transactions nécessitent un accusé de réception des pairs de 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 précis des ressources pour éviter que la surcharge du pool de connexions ne prive les processus MySQL principaux.
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é strictement choisie, car le déploiement de VM dédiées sur des zones distinctes est la seule méthode viable pour obtenir une véritable haute disponibilité multizone et survivre à une défaillance totale de 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 viable. Toutefois, le cluster InnoDB intégré (Group Replication + MySQL Router + MySQL Shell) a été sélectionné à la place, car il élimine la dépendance aux superpositions de routage tierces et simplifie considérablement la complexité opérationnelle autour des 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 permet de maintenir la résilience du point d'entrée et de simplifier la diffusion du trafic interzone.
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 de taille appropriée et des équilibreurs de charge mondiaux répartis uniformément sur trois zones de disponibilité.
- Mise en réseau sécurisée : l'accès basé sur des clés et des ProjectNetworkPolicies (PNP) appropriées sont établis pour autoriser la synchronisation de la réplication de groupe intracluster et le trafic MySQL Router.
Limites
- Kubernetes non compatible : les clients qui recherchent strictement des solutions conteneurisées/basées sur Kubernetes ne peuvent pas atteindre la 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 confie entièrement au client la responsabilité de l'application de correctifs de routine au niveau du système d'exploitation et des mises à niveau de version mineure de la base de données.
- Sensibilité à la latence du réseau : la réplication nécessite un réseau stable et de haute qualité. Les fluctuations du réseau ou les pics de latence entre les zones air-gapped retarderont proportionnellement les opérations d'écriture dans le cluster MySQL.
Autres ressources
- Implémentation de référence de solution (SRI) : implémentation de référence de solution pour MySQL 8 multizone à haute disponibilité dans GDC sous air gap