PostgreSQL-Datenbank-Referenzarchitektur in GDC mit Air Gap

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

Die Architektur konzentriert sich auf eine robuste Konfiguration mit drei Knoten, die die Datenbankverfügbarkeit auch bei einem Ausfall einer einzelnen Zone oder Infrastruktur gewährleistet. Er deckt den gesamten Lebenszyklus ab, von der automatisierten Bereitstellung und Vernetzung bis hin zu produktionsreifen Vorgängen wie Hochverfügbarkeit, Sicherung, Wiederherstellung und Beobachtbarkeit.

Funktionen

Die Lösung bietet mehrere zentrale Funktionskomponenten für die Datenbankverwaltung:

  • Automatisierte Hochverfügbarkeit: Verwenden Sie Patroni und etcd, um eine automatische Leader-Auswahl und ein automatisches Failover zu ermöglichen. So bleibt die Datenbank ohne manuelles Eingreifen betriebsbereit.
  • Multizonale Ausfallsicherheit: Verteilen Sie Datenbankknoten auf drei verschiedene Verfügbarkeitszonen, um sich vor lokalen Hardware- oder Infrastrukturausfällen zu schützen.
  • Standardisierte Automatisierung: Stellen Sie den gesamten Stack mit Ansible-basierten Playbooks mit Autobase bereit, um wiederholbare und konsistente Bereitstellungen zu ermöglichen.
  • Verbindungs-Pooling: Integrierter PgBouncer-Dienst zum Verwalten einer großen Anzahl von Verbindungen und zum Stabilisieren des Ressourcenverbrauchs auf den Datenbankknoten.
  • Globales Load Balancing: Verwenden Sie den von der Plattform verwalteten globalen L4-Load-Balancer, um eine einzelne, stabile virtuelle IP-Adresse (VIP) bereitzustellen, die über alle Zonen hinweg zugänglich ist.
  • Bereit für Air-Gap-Umgebungen: Spezielle Workflows zum Verpacken aller erforderlichen Betriebssystemabhängigkeiten und Binärdateien für die Bereitstellung in Umgebungen ohne Internetverbindung.
  • Datenschutz: Nutzen Sie Standardtools wie pg_dump und pg_basebackup zusammen mit GDC-Speicher-Snapshots, 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 Stack von Diensten am selben Standort ausführen.

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

Architekturprinzipien

  • Mehrheitsbasierter Konsens: Verwendet ein Quorum-basiertes Modell, bei dem sich eine Mehrheit der Knoten (2 von 3) auf den Clusterstatus einigen muss. Dadurch werden „Split-Brain“-Szenarien verhindert und die Datenintegrität wird gewährleistet.
  • Separation of Concerns: Auf jeder VM wird ein am selben Ort befindlicher, aber separater Stack von Diensten (Datenbank, HA-Manager, Konsens und Pooler) ausgeführt, um einen eigenständigen und ausfallsicheren Knoten bereitzustellen.
  • Datenbankbewusstes Failover: Priorisiert Datenbank-Zustandsmesswerte mit der REST API von Patroni, um die Weiterleitung des Traffics über den Plattform-Load-Balancer zu koordinieren.
  • Infrastructure as Code: Verlässt sich bei allen Konfigurationsaufgaben auf automatisierte Playbooks, wodurch das Risiko menschlicher Fehler bei der Bereitstellung und Skalierung verringert wird.

Konzepte und Technologien

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

Infrastruktur und Plattform

  • Virtuelle Maschinen (VMs): Dedizierte Compute-Instanzen, die über Zonen verteilt sind, um den Datenbank-Stack zu hosten.
  • Globaler 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: Ein leistungsstarker SSD-gestützter Speicher ist erforderlich, um die strengen Latenzanforderungen für die Write-Ahead-Logs der Konsensschicht zu erfüllen.

Dienste und Logik

  • PostgreSQL 17: Das zentrale relationale Datenbankmodul, das für die Datenpersistenz und die Abfrageausführung verantwortlich ist.
  • Patroni: Der Hochverfügbarkeitsmanager, der den lokalen PostgreSQL-Prozess überwacht und die Leader-Auswahl mithilfe von etcd koordiniert.
  • etcd: Der verteilte Konfigurationsspeicher, der die Konsensebene bereitstellt und den autoritativen Status des Clusters enthält.
  • PgBouncer: Ein einfacher 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 beizubehalten und Wahlen durchzuführen.

Hinweise

  • Skalierbarkeit und Leistung:
    • Datenbankknoten sollten je nach Arbeitslast dimensioniert werden, mit mindestens 2 vCPUs und 8 GiB RAM. Produktionsarbeitslasten beginnen in der Regel bei 8 vCPUs und 32 GiB.
    • Die Leistung hängt von einem Speicher mit geringer 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. Für eine optimale Leistung bei Konfigurationen ohne Datenverlust 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 Hochverfügbarkeits-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 Organisationen, die formellen Support für das Automatisierungspaket benötigen, ist ein kostenpflichtiger Support von Drittanbietern verfügbar.
    • Das Verbindungspooling mit PgBouncer ist wichtig, um eine Überlastung von CPU und Arbeitsspeicher durch eine hohe Anzahl von Nutzerverbindungen zu verhindern.
  • Verfügbarkeit und Zuverlässigkeit:
    • Hochverfügbarkeit wird durch ein Quorum mit drei Knoten erreicht. Der Ausfall eines einzelnen Knotens oder einer einzelnen Zone führt nicht zu einer Unterbrechung des Dienstes.
    • Clusterstabilität: Für ein zuverlässiges Quorum ist eine niedrige Netzwerklatenz zwischen den Knoten erforderlich. Die durchschnittliche Umlaufzeit (Round Trip Time, RTT) sollte idealerweise unter 10 ms liegen, um Zeitüberschreitungen bei der Auswahl und Clusterinstabilität zu vermeiden.
  • Betriebsmanagement:
    • Routinemäßige Aufgaben wie das Patchen von Nebenversionen und Hauptupgrades bleiben in der Verantwortung des Betriebsteams des Kunden.
    • Ausgaben aus den stdout der VMs werden automatisch in die Monitoring-Plattform von GDC mit Air Gap aufgenommen. In Zukunft wird ein Leitfaden veröffentlicht, in dem beschrieben wird, wie Sie ein detaillierteres Monitoring für die einzelnen Komponenten einbinden können.
    • Eine robuste Sicherungsstrategie sollte mit datenbanknativen Tools und Plattform-Snapshots implementiert werden. Detaillierte Anleitungen für diese Verfahren werden separat veröffentlicht.

Designentscheidung

Die Architekturentscheidungen für diese Lösung bieten einen stabilen Pfad für Bereitstellungen in mehreren Zonen.

Virtuelle Maschinen über Kubernetes

Es wurde ein VM-basierter Ansatz ausgewä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 es erforderlich, dedizierte VMs in separaten Zonen bereitzustellen, um eine robuste zonenübergreifende Architektur zu erreichen. Diese Konfiguration kann den Totalausfall einer einzelnen Infrastrukturzone überstehen.

Plattformnatives globales Load Balancing

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

  • Globale Reichweite: Bietet eine stabile virtuelle IP-Adresse, die über alle Zonen hinweg zugänglich ist.
  • Plattformverwaltet: Die VIP wird unabhängig von der Steuerungsebene der Plattform verwaltet.
  • Vereinfachtes Failover: Das Failover wird über standardmäßige Systemdiagnosen und nicht über komplexe lokale Softwarekonfigurationen verwaltet.
  • Hochverfügbarkeit: Wenn Sie die Abhängigkeit von lokalen Proxys aufheben, bleibt der Einstiegspunkt für den Datenbank-Traffic stabil.

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.
  • Für alle Ziel-VMs ist ein schlüsselbasierter SSH-Zugriff für die Ansible-basierte Automatisierung verfügbar.
  • Das Projekt hat ein ausreichendes Kontingent für die Bereitstellung von VMs und Load Balancern in mehreren Zonen.

Beschränkungen

  • Manuelle Wartung: Betriebssystem-Patching und PostgreSQL-Versionsupgrades sind manuelle Aufgaben und werden von der Lösung nicht automatisiert.
  • Speicherempfindlichkeit: Die Konsensebene (etcd) ist sehr empfindlich gegenüber Laufwerklatenz. Anhaltend hohe Speicherkonflikte können die Stabilität der Konsensebene beeinträchtigen.
  • Netzwerkstabilität: Der Hochverfügbarkeitsmanager ist auf eine konsistente Netzwerkverbindung mit niedriger Latenz zwischen den Zonen angewiesen. Verzögerungen oder Netzwerk-Jitter können das Timing der Clusterkoordination und der Rollenübergänge beeinflussen.

Zusätzliche Materialien