MySQL-Datenbank-Referenzarchitektur auf GDC mit Air Gap

Diese Referenzarchitektur bietet einen konzeptionellen Rahmen für die Bereitstellung und den Betrieb von hochverfügbaren, vom Kunden verwalteten MySQL 8.4-Datenbanken in Google Distributed Cloud (GDC) mit Air-Gap. Sie ermöglicht Unternehmen und Kunden mit Vorabzugriff, kritische Datenbankarbeitslasten zuverlässig mit einer robusten, multizonalen Einrichtung für virtuelle Maschinen (VMs) zu verwalten.

Da GDC mit Air-Gap keine Unterstützung für zonenübergreifende Kubernetes-Stretch-Cluster bietet, basiert diese Architektur ausschließlich auf dedizierten VMs, die in drei Verfügbarkeitsdomains bereitgestellt werden, um einen kontinuierlichen Betrieb zu gewährleisten und einen vollständigen Zonenausfall ohne Datenverlust zu überstehen.

Funktionen

  • Multizonale Resilienz:Eine hochresiliente 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 Gruppenreplikation für Paxos-basiertes Konsens-Clustering und bietet automatische Fehlererkennung, Knotenvereinbarung und globale Datensynchronisierung ohne Split-Brain-Szenarien.
  • Intelligentes Traffic-Routing:Gemeinsam bereitgestellte 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:Lässt sich in den integrierten GDC Global L4 Load Balancer einbinden, um eine einzelne, stabile virtuelle IP-Adresse (VIP) für Clientanwendungen bereitzustellen und die zugrunde liegende Knotentopologie zu abstrahieren.

Architekturprinzipien

  • Quorum-basierter Konsens:Priorisiert strenge Datenkonsistenz. Die Gruppenreplikation erzwingt ein Paxos-basiertes Modell, das eine Mehrheitsvereinbarung erfordert, wodurch das Risiko von Datenverlust oder Split-Brain bei Netzwerkpartitionen ausgeschlossen wird.
  • Trennung von Zuständigkeiten:Entkoppelt die Datenbank-Engine und die Konsensschicht (Gruppenreplikation) von der Schicht für das Routing des Client-Traffics (MySQL Router) und vereinfacht gleichzeitig die Lebenszyklusverwaltung des Clusters mit MySQL Shell.
  • Infrastrukturoptimierung:Speziell für Umgebungen mit Air-Gap entwickelt, wobei robuste VMs verwendet werden, um die aktuellen Einschränkungen der Kubernetes-Netzwerke zu umgehen.

Architektur

Architektur mit drei VMs, auf denen ein gemeinsam genutzter Stapel von Diensten ausgeführt wird.

Konzepte und Technologien

In diesem Abschnitt werden die funktionalen Komponenten und ihre spezifischen Verantwortlichkeiten innerhalb der multizonalen Architektur beschrieben.

Infrastruktur und Plattform

  • Virtuelle Maschinen (VMs) : Drei dedizierte Compute-Instanzen, die jeweils in einer separaten Verfügbarkeitszone bereitgestellt werden, um die Grenzen der Fehlerdomain zu bilden.
  • GDC Global L4 Load Balancer:Ein von der Plattform verwaltetes Netzwerkkonstrukt, das eine stabile interne VIP bereitstellt und automatisch Systemdiagnosen für MySQL Router ausführt, um eingehenden Traffic umzuleiten.

Dienste und Logik

  • MySQL 8.4:Die relationale Datenbank-Engine.
  • Gruppenreplikation / InnoDB-Cluster:Das integrierte Clustering-Framework, das für die Multi-Master-Replikation verantwortlich ist und das Knotenquorum mit Paxos überprüft.
  • MySQL Shell:Die einheitliche Befehlszeilenschnittstelle, die speziell zum Konfigurieren, Bereitstellen und Verwalten der InnoDB-Clusterinstanzen verwendet wird.
  • MySQL Router:Fungiert als Traffic-Router auf jeder VM. Wird dynamisch konfiguriert, um auf die Clustermetadaten zu warten 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 GDC Global L4 Load Balancer VIP.
  2. Der Load Balancer leitet die Verbindung an eine fehlerfreie MySQL Router-Instanz auf einer der VMs weiter.
  3. Abhängig vom 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 Cluster verteilt.

Hinweise

  • Abwägung zwischen Leistung und Konsistenz:Da die Gruppenreplikation einen Konsens erzwingt, müssen Transaktionen von Cluster-Peers bestätigt werden. Die Leistung hängt direkt von der zonenübergreifenden Netzwerklatenz in der GDC-Umgebung ab.
  • Ressourcenverwaltung:Wenn Sie MySQL Router direkt auf den Datenbank-VMs bereitstellen, wird die Hardwarenutzung optimiert. Sie müssen jedoch die Ressourcen sorgfältig abstimmen, um zu verhindern, dass der Overhead des Verbindungspoolings die MySQL-Kernprozesse beeinträchtigt.

Designentscheidung

  • Virtuelle Maschinen statt Kubernetes:GDC mit Air-Gap unterstützt keine Kubernetes-Cluster, die sich über mehrere physische Zonen erstrecken. Ein VM-basierter Ansatz wurde ausschließlich gewählt, da die Bereitstellung dedizierter VMs in separaten Zonen die einzig praktikable Methode ist, um echte multizonale Hochverfügbarkeit zu erreichen und einen vollständigen Zonenausfall zu überstehen.
  • InnoDB-Cluster im Vergleich zu Orchestrator und ProxySQL:Eine herkömmliche Primär-/Sekundärarchitektur in Kombination mit ProxySQL und Orchestrator wurde als praktikable Alternative bewertet. Stattdessen wurde jedoch der integrierte InnoDB-Cluster (Gruppenreplikation + MySQL Router + MySQL Shell) ausgewählt, da er die Abhängigkeit von Routing-Overlays von Drittanbietern beseitigt und die betriebliche Komplexität im Zusammenhang mit Failovern drastisch reduziert, indem der Konsens direkt in MySQL beibehalten wird.
  • Integriertes globales Load-Balancing der Plattform:Durch die Nutzung des integrierten GDC Global L4 Load Balancer wird sichergestellt, dass die VIP von der GDC-Steuerungsebene gesteuert wird, wodurch der Einstiegspunkt resilient bleibt und die zonenübergreifende Traffic-Übertragung vereinfacht wird.

Annahmen und Einschränkungen

Annahmen

  • Verfügbarkeit der Infrastruktur:Kunden haben ein ausreichend hohes Projektkontingent, um dedizierte, richtig dimensionierte VMs und globale Load Balancer bereitzustellen, die gleichmäßig auf drei Verfügbarkeitszonen verteilt sind.
  • Sichere Netzwerke:Der schlüsselbasierte Zugriff und die entsprechenden ProjectNetworkPolicies (PNPs) sind eingerichtet, um die Synchronisierung der Gruppenreplikation innerhalb des Clusters und den MySQL Router-Traffic zu ermöglichen.

Einschränkungen

  • Kubernetes wird nicht unterstützt:Kunden, die ausschließlich containerbasierte/Kubernetes-basierte Lösungen suchen, können keine multizonale Hochverfügbarkeit 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 das regelmäßige Patchen auf Betriebssystemebene und für Upgrades der Datenbank-Nebenversion vollständig beim Kunden.
  • Empfindlichkeit gegenüber Netzwerklatenz:Die Replikation erfordert ein hochwertiges, stabiles Netzwerk. Netzwerk-Jitter oder Latenzspitzen zwischen den Zonen mit Air-Gap verzögern Schreibvorgänge im gesamten MySQL-Cluster proportional.

Zusätzliche Materialien