MySQL-Datenbank-Referenzarchitektur auf GDC mit Air Gap

Diese Referenzarchitektur bietet ein konzeptionelles Framework für die Bereitstellung und den Betrieb hochverfügbarer, vom Kunden verwalteter MySQL 8.4-Datenbanken in Google Distributed Cloud (GDC) mit Air Gap. Damit können Unternehmenskunden und Kunden mit Early Access wichtige Datenbankarbeitslasten mithilfe einer robusten, multizonalen VM-Einrichtung zuverlässig verwalten.

Da GDC mit Air Gap keine zonenübergreifenden Kubernetes-Stretch-Cluster unterstützt, basiert diese Architektur ausschließlich auf dedizierten VMs, die in drei Verfügbarkeitsdomains bereitgestellt werden. So wird ein kontinuierlicher Betrieb gewährleistet und ein vollständiger Zonenausfall ohne Datenverlust überstanden.

Funktionen

  • Ausfallsicherheit in mehreren Zonen: Eine hochgradig ausfallsichere Konfiguration mit drei Knoten, die in drei verschiedenen Verfügbarkeitszonen bereitgestellt wird, um vor Ausfällen einzelner Infrastrukturzonen zu schützen.
  • Automatisierte Hochverfügbarkeit und Konsens: Verwendet die Gruppenreplikation für Paxos-basiertes Konsens-Clustering, um automatische Fehlererkennung, Knotenabstimmung und globale Datensynchronisierung ohne Split-Brain-Szenarien zu ermöglichen.
  • Intelligentes Traffic-Routing: Am selben Ort befindliche MySQL-Router-Instanzen verwalten das Verbindungsrouting. Der Router leitet Schreibvorgänge (z. B. Port 6446) ausschließlich an einen aktiven primären Knoten weiter und verteilt Lesevorgänge (z. B. Port 6447) per Load Balancing auf synchronisierte Replikate.
  • Globales Load Balancing: Wird in den integrierten globalen L4-Load Balancer von GDC eingebunden, um eine einzelne, stabile virtuelle IP-Adresse (VIP) für Clientanwendungen bereitzustellen und die zugrunde liegende Knotentopologie zu abstrahieren.

Architekturprinzipien

  • Quorumbasierter Konsens: Priorisiert strikte Datenkonsistenz. Die Gruppenreplikation erzwingt ein Paxos-basiertes Modell, das eine Mehrheitsvereinbarung erfordert. Dadurch wird das Risiko von Datenverlusten oder Split-Brain-Szenarien bei Netzwerkpartitionen eliminiert.
  • Trennung von Zuständigkeiten: Entkoppelt die Datenbank-Engine und die Konsensebene (Gruppenreplikation) von der Routingebene für Client-Traffic (MySQL Router) und vereinfacht gleichzeitig die Verwaltung des Cluster-Lebenszyklus mit MySQL Shell.
  • Infrastrukturoptimierung: Speziell für Umgebungen mit Air Gap entwickelt, wobei robuste VMs verwendet werden, um aktuelle Einschränkungen des Kubernetes-Netzwerks zu umgehen.

Architektur

Architektur mit drei VMs, auf denen ein Stack von Diensten am selben Standort ausgeführt wird.

Konzepte und Technologien

In diesem Abschnitt werden die funktionalen Komponenten und ihre spezifischen Aufgaben innerhalb der Architektur mit mehreren Zonen beschrieben.

Infrastruktur und Plattform

  • Virtuelle Maschinen (VMs): Drei dedizierte Compute-Instanzen, die jeweils in einer separaten Verfügbarkeitszone bereitgestellt werden, um die Grenzen der fehlerhaften Domain zu bilden.
  • Globaler L4-Load-Balancer von GDC: Ein plattformverwaltetes Netzwerkkonstrukt, das eine stabile interne VIP bereitstellt und automatisch MySQL Router-Systemdiagnosen auswertet, um eingehenden Traffic weiterzuleiten.

Dienste und Logik

  • MySQL 8.4: Das zentrale relationale Datenbankmodul.
  • Gruppenreplikation/InnoDB-Cluster: Das integrierte Clustering-Framework, das für die Multi-Master-Replikation und die Überprüfung des Knoten-Quorums mit Paxos verantwortlich ist.
  • MySQL Shell: Die einheitliche Befehlszeile, die speziell zum Konfigurieren, Bereitstellen und Verwalten der InnoDB-Clusterinstanzen verwendet wird.
  • MySQL-Router: Fungiert als Traffic-Router auf jeder VM. Dynamisch konfiguriert, um die Clustermetadaten zu überwachen und Traffic weiterzuleiten: Aktiv/Backup für Schreibvorgänge und Round-Robin für Lesevorgänge.

Datenfluss und Schnittstellen

  1. Anwendungen senden Datenbankanfragen an die VIP des globalen L4-Load-Balancers von GDC.
  2. Der Load Balancer leitet die Verbindung über einen Proxy an eine fehlerfreie MySQL Router-Instanz auf einer der VMs weiter.
  3. Basierend auf dem angeforderten Port leitet MySQL Router den Traffic dynamisch weiter: Port 6446 ist ausschließlich für Schreibvorgänge auf dem aktiven Knoten vorgesehen, während Port 6447 Lesevorgänge im gesamten Cluster verteilt.

Hinweise

  • Kompromisse zwischen Leistung und Konsistenz: Da die Gruppenreplikation einen Konsens erzwingt, müssen Transaktionen von Cluster-Peers bestätigt werden. Die Leistung korreliert direkt mit der zonenübergreifenden Netzwerklatenz innerhalb der GDC-Umgebung.
  • Ressourcenverwaltung: Wenn Sie MySQL Router direkt auf den Datenbank-VMs bereitstellen, wird die Hardwarenutzung optimiert. Sie müssen jedoch die Ressourcen sorgfältig abstimmen, damit der Overhead für das Verbindungs-Pooling die MySQL-Kernprozesse nicht beeinträchtigt.

Designentscheidung

  • Virtuelle Maschinen über Kubernetes: GDC mit Air Gap unterstützt keine Kubernetes-Cluster, die sich über mehrere physische Zonen erstrecken. Ein VM-basierter Ansatz wurde gewählt, weil die Bereitstellung dedizierter VMs in separaten Zonen die einzige praktikable Methode ist, um eine echte Hochverfügbarkeit über mehrere Zonen hinweg zu erreichen und einen vollständigen Zonenausfall zu überstehen.
  • InnoDB-Cluster im Vergleich zu Orchestrator und ProxySQL: Eine herkömmliche primäre/sekundäre Architektur in Kombination mit ProxySQL und Orchestrator wurde als machbare Alternative bewertet. Stattdessen wurde der integrierte InnoDB-Cluster (Gruppenreplikation + MySQL Router + MySQL Shell) ausgewählt, da er die Abhängigkeit von Routing-Overlays von Drittanbietern beseitigt und die operative Komplexität bei Failovern drastisch vereinfacht, indem der Konsens direkt in MySQL beibehalten wird.
  • In die Plattform integriertes globales Load-Balancing: Durch die Verwendung des integrierten GDC Global L4 Load Balancers wird sichergestellt, dass die VIP von der GDC-Steuerungsebene gesteuert wird. Dadurch bleibt der Einstiegspunkt stabil und die zonenübergreifende Trafficbereitstellung wird vereinfacht.

Annahmen und Einschränkungen

Annahmen

  • Verfügbarkeit der Infrastruktur: Kunden haben ein ausreichendes Projektkontingent, um dedizierte, richtig dimensionierte VMs und globale Load Balancer bereitzustellen, die gleichmäßig auf drei Verfügbarkeitszonen verteilt sind.
  • Sicheres Netzwerk: Es werden schlüsselbasierter Zugriff und geeignete ProjectNetworkPolicies (PNPs) eingerichtet, um die Synchronisierung der Gruppenreplikation innerhalb des Clusters und den MySQL Router-Traffic zuzulassen.

Beschränkungen

  • Kubernetes wird nicht unterstützt: Kunden, die ausschließlich containerisierte/Kubernetes-basierte Lösungen suchen, können keine Hochverfügbarkeit über mehrere Zonen hinweg erreichen, bis Stretch-Cluster vollständig von der Plattform unterstützt werden.
  • Manuelle Upgrades erforderlich: Im Gegensatz zu verwalteten Diensten liegt die Verantwortung für routinemäßige Patches auf Betriebssystemebene und Upgrades von Datenbank-Nebenversionen bei dieser Lösung vollständig beim Kunden.
  • Empfindlichkeit gegenüber Netzwerklatenz: Die Replikation erfordert ein hochwertiges, stabiles Netzwerk. Netzwerk-Jitter oder Latenzspitzen zwischen den Air-Gap-Zonen verzögern Schreibvorgänge im MySQL-Cluster proportional.

Zusätzliche Materialien