PostgreSQL-Datenbank-Referenzarchitektur in GDC mit Air Gap

Diese Referenzarchitektur bietet einen konzeptionellen Rahmen für die Bereitstellung und den Betrieb von von Kunden verwalteten PostgreSQL Datenbanken in Google Distributed Cloud (GDC) mit Air-Gap. Mit dieser Lösung können Unternehmen kritische Datenbankarbeitslasten aufrechterhalten, indem sie einen hochverfügbaren (HA) Cluster mit mehreren Zonen nutzen, der auf virtuellen Maschinen bereitgestellt wird.

Die Architektur basiert auf einer resilienten Konfiguration mit drei Knoten, die die Verfügbarkeit der Datenbank auch bei einem Ausfall einer einzelnen Zone oder Infrastruktur gewährleistet. Sie deckt den gesamten Lebenszyklus ab, von der automatisierten Bereitstellung und Vernetzung bis hin zu Produktionsvorgängen wie Hochverfügbarkeit, Sicherung, Wiederherstellung und Beobachtbarkeit.

Funktionen

Die Lösung bietet mehrere funktionale Kernkomponenten für die Datenbankverwaltung:

  • Automatisierte Hochverfügbarkeit: Mit Patroni und etcd werden die automatische Leader-Wahl und das Failover bereitgestellt, sodass die Datenbank ohne manuelle Eingriffe betriebsbereit bleibt.
  • Resilienz in mehreren Zonen: Datenbankknoten werden auf drei verschiedene Verfügbarkeitszonen verteilt, um vor lokalen Hardware- oder Infrastrukturausfällen zu schützen.
  • Standardisierte Automatisierung: Der gesamte Stack wird mit Ansible-basierten Playbooks mit Autobase bereitgestellt, um wiederholbare und konsistente Bereitstellungen zu gewährleisten.
  • Verbindungspooling: Integrierter PgBouncer Dienst zur Verwaltung einer hohen Anzahl von Verbindungen und zur Stabilisierung des Ressourcenverbrauchs auf den Datenbankknoten.
  • Globales Load-Balancing: Der von der Plattform verwaltete Global L4 Load Balancer bietet eine einzelne, stabile virtuelle IP-Adresse (VIP), auf die in allen Zonen zugegriffen werden kann.
  • Air-Gap-Bereitschaft: Spezialisierte Workflows zum Packen aller erforderlichen Betriebssystemabhängigkeiten und Binärdateien für die Bereitstellung in getrennten Umgebungen.
  • Datenschutz: Standardtools wie pg_dump und pg_basebackup werden zusammen mit GDC-Speicher-Snapshots verwendet, um eine robuste Sicherungs- und Wiederherstellungsstrategie zu gewährleisten.

Architektur

Die Architektur besteht aus einer Umgebung mit drei VMs, die auf drei Verfügbarkeitszonen verteilt sind und einen gemeinsam genutzten Stack von Diensten ausführen.

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

Architekturprinzipien

  • Mehrheitsbasierter Konsens: Es wird ein quorum-basiertes Modell verwendet, bei dem eine Mehrheit der Knoten (2 von 3) dem Clusterstatus zustimmen muss, um „Split-Brain“-Szenarien zu verhindern und die Datenintegrität zu gewährleisten.
  • Trennung von Zuständigkeiten: Auf jeder VM wird ein gemeinsam genutzter, aber separater Stack von Diensten (Datenbank, HA-Manager, Konsens und Pooler) ausgeführt, um einen in sich geschlossenen und resilienten Knoten bereitzustellen.
  • Datenbankbasiertes Failover: Datenbank-Gesundheitsmesswerte werden mit der REST API von Patroni priorisiert, um die Traffic-Umleitung über den Load Balancer der Plattform zu koordinieren.
  • Infrastruktur als Code: Für alle Konfigurationsaufgaben werden automatisierte Playbooks verwendet, um das Risiko menschlicher Fehler bei der Bereitstellung und Skalierung zu verringern.

Konzepte und Technologien

In diesem Abschnitt werden die funktionalen Komponenten, ihre Zuständigkeiten und die Kommunikation innerhalb des Systems beschrieben.

Infrastruktur und Plattform

  • Virtuelle Maschinen (VMs): Dedizierte Compute-Instanzen, die auf Zonen verteilt sind und den Datenbankstack hosten.
  • Global L4 Load Balancer: Ein von der Plattform verwalteter Dienst, der eine stabile virtuelle IP-Adresse (VIP) bereitstellt, die Traffic an den aktuellen Cluster-Leader weiterleitet.
  • Nichtflüchtiger Speicher: Hochleistungs-SSD-basierter Speicher ist erforderlich, um die strengen Latenzanforderungen für die Write-Ahead-Logs der Konsensschicht zu erfüllen.

Dienste und Logik

  • PostgreSQL 17: Die relationale Kerndatenbank-Engine, die für die Datenpersistenz und die Abfrageausführung verantwortlich ist.
  • Patroni: Der Manager für Hochverfügbarkeit, der den lokalen PostgreSQL-Prozess überwacht und Leader-Wahlen mit etcd koordiniert.
  • etcd: Der verteilte Konfigurationsspeicher, der die Konsensschicht bereitstellt und den autoritativen Status des Clusters enthält.
  • PgBouncer: Ein schlanker Verbindungspooler, der vor PostgreSQL platziert wird, um eingehende Anwendungsverbindungen effizient zu verarbeiten.

Datenfluss und Schnittstellen

  • PgBouncer (Port 6432): Der primäre Einstiegspunkt für den Datenbanktraffic der Anwendung.
  • Patroni API (Port 8008): Eine HTTPS-REST-Schnittstelle, die vom Load Balancer verwendet wird, um Systemdiagnosen durchzuführen und den aktuellen Leader über den Endpunkt /primary zu identifizieren.
  • etcd (Port 2379): Der Kommunikationskanal für den Konsenscluster, um den Status aufrechtzuerhalten und Wahlen durchzuführen.

Hinweise

  • Skalierbarkeit und Leistung:
    • Die Größe der Datenbankknoten sollte auf der Arbeitslast basieren, mit mindestens 2 vCPUs und 8 GB RAM. Produktionsarbeitslasten beginnen in der Regel bei 8 vCPUs und 32 GB.
    • Die Leistung hängt von einem Speicher mit niedriger Latenz ab. SSDs sind erforderlich, damit etcd Datensynchronisierungen in weniger als 10 ms verarbeiten kann.
    • Synchrone Replikation: Der Overhead der synchronen Replikation hängt direkt von der Netzwerklatenz zwischen den Zonen ab. Um eine optimale Leistung für Konfigurationen ohne Datenverlust zu gewährleisten, ist eine niedrige Latenz zwischen den Zonen erforderlich.
  • Ressourcenverwaltung und Lizenzierung:
    • Diese Lösung basiert auf kostenlosen Open-Source-Datenbankkomponenten.
    • Autobase wird als Referenz Automatisierungstool verwendet, um die Installation und Konfiguration des HA-Stacks zu optimieren. Die Architektur ist jedoch nicht ausschließlich an Autobase gebunden und die zugrunde liegenden Open-Source-Komponenten können mit benutzerdefinierten Pipelines verwaltet werden.
    • Für Unternehmen, die formellen Support für das Automatisierungspaket benötigen, kostenpflichtiger Support von Drittanbietern ist verfügbar.
    • Verbindungspooling mit PgBouncer ist unerlässlich, um eine CPU- und Arbeitsspeicherüberlastung zu verhindern, die durch eine hohe Anzahl von Nutzerverbindungen verursacht wird.
  • Verfügbarkeit und Zuverlässigkeit:
    • Hochverfügbarkeit wird durch ein Quorum mit drei Knoten erreicht. Der Ausfall eines einzelnen Knotens oder einer einzelnen Zone unterbricht den Dienst nicht.
    • Clusterstabilität: Für ein zuverlässiges Quorum ist eine niedrige Netzwerklatenz zwischen den Knoten erforderlich. Die durchschnittlichen Round-Trip-Zeiten (RTT) sollten idealerweise unter 10 ms liegen, um Zeitüberschreitungen bei der Wahl und Clusterinstabilität zu verhindern.
  • Betriebsmanagement:
    • Routineaufgaben wie das Patchen von Nebenversionen und größere Upgrades liegen weiterhin in der Verantwortung des Betriebsteams des Kunden.
    • Die Ausgaben von stdout der VMs werden automatisch in die GDC-Monitoringplattform mit Air-Gap aufgenommen. In Zukunft wird eine Anleitung zur Integration einer detaillierteren Überwachung für die einzelnen Komponenten veröffentlicht.
    • Eine robuste Sicherungsstrategie sollte mit datenbanknativen Tools und Plattform-Snapshots implementiert werden. Detaillierte Anleitungen für diese Verfahren werden separat veröffentlicht.

Designentscheidung

Die Architektur für diese Lösung bietet einen resilienten Pfad für Bereitstellungen in mehreren Zonen.

Virtuelle Maschinen statt Kubernetes

Es wurde ein VM-basierter Ansatz gewählt, um Hochverfügbarkeit in mehreren Zonen zu ermöglichen. GDC unterstützt keine Kubernetes-Cluster, die sich über mehrere physische Zonen erstrecken. Daher ist die Bereitstellung dedizierter VMs in separaten Zonen erforderlich, um eine robuste zonenübergreifende Architektur zu erreichen. Diese Konfiguration kann den vollständigen Ausfall einer einzelnen Infrastrukturzone überstehen.

Plattformbasiertes globales Load-Balancing

Die Architektur nutzt den GDC Global L4 Load Balancer anstelle von softwarebasierten Proxys auf den VMs. Dieser Ansatz bietet mehrere Vorteile:

  • Globale Reichweite: Bietet eine stabile virtuelle IP-Adresse, auf die in allen Zonen zugegriffen werden kann.
  • Plattformverwaltung: Die VIP wird unabhängig von der Steuerungsebene der Plattform verwaltet.
  • Vereinfachtes Failover: Das Failover wird über Standard-Systemdiagnose-Prüfungen und nicht über komplexe lokale Softwarekonfigurationen verwaltet.
  • Hochverfügbarkeit: Da keine lokalen Proxys erforderlich sind, bleibt der Einstiegspunkt für den Datenbanktraffic resilient.

Annahmen und Einschränkungen

Annahmen

  • Die Umgebung verfügt über eine lokale Registry oder einen Mechanismus zum Importieren von gepackten Betriebssystemabhängigkeiten und Binärdateien.
  • Der schlüsselbasierte SSH-Zugriff ist für alle Ziel-VMs für die Ansible-basierte Automatisierung verfügbar.
  • Das Projekt hat ausreichend Kontingente für die Bereitstellung von VMs und Load Balancern in mehreren Zonen.

Einschränkungen

  • Manuelle Wartung: Das Patchen des Betriebssystems und Upgrades der PostgreSQL-Version sind manuelle Aufgaben und werden von der Lösung nicht automatisiert.
  • Speichersensibilität: Die Konsensschicht (etcd) reagiert sehr empfindlich auf die Festplattenlatenz. Anhaltende hohe Speicherkonkurrenz kann sich auf die Stabilität der Konsensschicht auswirken.
  • Netzwerkstabilität: Der Manager für Hochverfügbarkeit ist auf eine konsistente Netzwerkverbindung mit niedriger Latenz zwischen den Zonen angewiesen. Verzögerungen oder Netzwerk-Jitter können sich auf das Timing der Clusterkoordination und der Rollenübergänge auswirken.

Zusätzliche Materialien