AlloyDB Omni bietet eine Orchestrierungsplattform zum Bereitstellen und Verwalten von AlloyDB Omni in Nicht-Kubernetes-Umgebungen, z. B. unter Red Hat Enterprise Linux (RHEL) und kompatiblen Systemen, die RPM-Pakete (Red Hat Package Manager) verwenden. Die RPM-Orchestrator-Bereitstellungsoption erweitert die cloudähnliche Flexibilität und Automatisierung auf lokale und VM-Infrastrukturen.
Mit AlloyDB Omni mit dem RPM-Orchestrator können Unternehmen AlloyDB Omni-Instanzen mithilfe von Standard-RPM-Paketen installieren, konfigurieren und verwalten. Dieser Ansatz unterstützt Organisationen, die erhebliche Investitionen in die VM-Infrastruktur getätigt und operative Praktiken rund um Automatisierungstools wie Ansible etabliert haben. Die RPM-Orchestrator-Bereitstellungsoption wird direkt auf Linux-VMs oder Bare-Metal-Servern ausgeführt, ohne dass eine Containerisierungsebene wie Docker oder ein Orchestrierungssystem wie Kubernetes erforderlich ist.
Wenn Sie diese Bereitstellungsoption nutzen möchten, fordern Sie über das Registrierungsformular Zugriff an.
Anwendungsfälle
Die RPM-Orchestrator-Bereitstellungsoption unterstützt die folgenden Anwendungsfälle:
| Anwendungsfall | Beschreibung |
|---|---|
| Unternehmen mit VM-Infrastruktur | Unterstützt Unternehmen, in denen Kubernetes nicht standardmäßig verwendet wird, oder containerisierte Umgebungen mit Anwendungsabhängigkeiten, die Standard-VM- oder Bare-Metal-Bereitstellungen bevorzugen. |
| Vereinfachter Betrieb | Automatisierung der Bereitstellung, Konfiguration und Lebenszyklusverwaltung von Datenbanken mit vertrauten Tools wie Ansible. |
| Hochverfügbarkeit und Notfallwiederherstellung | Richtet robuste AlloyDB Omni-Cluster mit automatischen Failover- und Wiederherstellungsmechanismen ein. |
| Hybride Umgebungen | Sorgt für konsistente Datenbankvorgänge in lokalen Rechenzentren und Cloud-VMs. |
| Integration von alten Systemen | Lässt sich in vorhandene Anwendungen und Systeme einbinden, die für nicht containerisierte Umgebungen entwickelt wurden. |
Vorteile
Die Vorteile der RPM-Orchestrator-Bereitstellungsoption sind:
- Schnelle Bereitstellung: Der gesamte Lebenszyklus von der Bereitstellung bis zur Überprüfung wird automatisiert. Dadurch werden Zeitaufwand und Komplexität bei der Einrichtung von AlloyDB Omni-Clustern erheblich reduziert.
- Nahtlose Integration: Native Integration in die Standard-Linux-Paketverwaltung (RPM) und gängige Automatisierungs-Frameworks wie Ansible, sodass Teams vorhandene Fähigkeiten und Tool-Integrationen nutzen können.
- Einheitliche Nutzung: Bietet eine Nutzererfahrung und Funktionen für Verwaltung und Betrieb, die mit dem Kubernetes-Operator von AlloyDB Omni vergleichbar sind. So wird für Konsistenz zwischen verschiedenen Bereitstellungsmodellen gesorgt.
- Hochverfügbarkeit (High Availability, HA) und Notfallwiederherstellung (Disaster Recovery, DR) auf Unternehmensniveau: Unterstützt flexible Konfigurationen für Hochverfügbarkeit und Notfallwiederherstellung, um die Anforderungen an die Geschäftskontinuität zu erfüllen.
- Robuste Sicherheit: Ermöglicht die Implementierung vielschichtiger Sicherheitsstrategien, einschließlich Nutzerverwaltung, Netzwerksicherheit mit Zertifikaten (SSL) und Integration in Systeme wie Microsoft Active Directory.
- Zentralisierte Verwaltung: Verwendet den AlloyDB Omni-Dienst, um eine einheitliche Steuerungsebene für die Verwaltung von AlloyDB Omni auf VMs bereitzustellen.
- Beobachtbarkeit und Auditierung: Ermöglicht die Integration in externe Loggingserver wie Elastic Stack über rsyslog für das zentralisierte Logging, das Monitoring und die Auditierung.
- Datenschutz: Umfasst Funktionen für vereinfachte Konfigurationen und Strategien für die Sicherung und Wiederherstellung.
- Verbindungs-Pooling: Unterstützt die Bereitstellung von PgBouncer zur Optimierung von Datenbankverbindungen und zur Verbesserung der Leistung.
- Flottenverwaltung: Damit können Sie mehrere AlloyDB Omni-Cluster im großen Maßstab verwalten.
Architektur
AlloyDB Omni definiert eine Hierarchie von Komponenten, die Flexibilität bieten. Diese Flexibilität hilft Ihnen, die Datenverfügbarkeit zu maximieren und die Abfrageleistung und den Durchsatz zu optimieren. Mit diesem Ansatz können Sie Ihre AlloyDB Omni-Bereitstellung überwachen und ihre Skalierung und Größe an Ihre Arbeitslasten anpassen.
Die Ressource auf oberster Ebene in der Hierarchie ist eine AlloyDB Omni-Bereitstellung mit einem primären Cluster und einem oder mehreren sekundären Clustern. Ein AlloyDB Omni-Cluster hat eine oder mehrere Instanzen, die eine Abstraktion der Rechenressourcen sind, mit denen Nutzer eine Verbindung herstellen. Der Cluster enthält eine primäre Instanz (Lese-/Schreibzugriff) und eine oder mehrere optionale Lesepoolinstanzen (schreibgeschützt). Jede Instanz hat einen eigenen Zugriffsendpunkt. Optional können Sie eine primäre Instanz mit einem einzelnen Knoten für die eigenständige Bereitstellung oder mit mehreren Knoten für die hochverfügbare Bereitstellung einrichten. Auf allen Knoten sind AlloyDB Omni und andere zugehörige Komponenten mithilfe der Softwarepakete bereitgestellt.
Die primäre Instanz enthält einen aktiven Knoten (Lese-/Schreibzugriff), der für die Verarbeitung von Transaktionsarbeitslasten konzipiert ist. Richten Sie für Datenbankcluster, die über grundlegende Tests, Experimente und Entwicklung hinausgehen, Hochverfügbarkeit mit zusätzlichen Stand-by-Knoten ein. Um Datenverlust zu vermeiden und im Falle eines Ausfalls des primären Knotens ein Recovery Point Objective (RPO) von null zu erreichen, konfigurieren Sie den synchronen Replikationsmodus des Standby-Knotens.
Ausfallsichere Hochverfügbarkeit
Eine robuste HA-Architektur stellt einen aktiven primären Knoten und Standby-Knoten in separaten Zonen ohne dedizierte Load-Balancer-Knoten bereit.
Stattdessen wird der keepalived-Dienst direkt auf den Datenbankknoten ausgeführt, um eine Floating-Virtual-IP-Adresse zu verwalten, die den Lese-/Schreibendpunkt auf dem aktiven primären Knoten verfügbar macht.
Die folgende Abbildung zeigt die ausfallsichere HA-Bereitstellungsarchitektur in einer Bare-Metal- oder VM-Umgebung:
Abbildung 1: Resiliente HA-Bereitstellungsarchitektur für AlloyDB Omni
Skalierbare Hochverfügbarkeit
Eine skalierbare HA-Architektur stellt einen aktiven primären Knoten und Standby-Knoten in separaten Zonen bereit, die mit dedizierten HAProxy-Load-Balancer-Knoten gekoppelt sind. Diese Load-Balancer-Knoten stellen die Lese-/Schreib- und Lesezugriff-Endpunkte bereit und leiten Client-Traffic weiter.
Die folgende Abbildung zeigt die Taxonomie eines skalierbaren AlloyDB Omni-HA-Deployments in einer Bare-Metal- oder VM-Umgebung:
Abbildung 2: Skalierbare HA-VM-Bereitstellungsarchitektur für AlloyDB Omni
Komponenten
Die Bereitstellungsoption mit dem RPM-Orchestrator umfasst eine Reihe von Softwarekomponenten, die jeweils als RPM- oder Debian-Pakete installiert werden, für eine vollständige, hochverfügbare AlloyDB Omni-Bereitstellung. Die Referenzarchitektur verwendet diese Komponenten für Datenbankvorgänge.
| Komponente | Beschreibung |
|---|---|
| Orchestrator | Die AlloyDB Omni-Orchestrierung bietet Befehlszeilen- und Ansible-Schnittstellen, mit denen Sie einen oder mehrere AlloyDB Omni-Cluster in einer verteilten Umgebung bereitstellen und verwalten können. |
| alloydbomni | Der AlloyDB Omni-Kern umfasst PostgreSQL- und Autopilot-Funktionen für eine verbesserte Leistung und Funktionen zur Unterstützung moderner Arbeitslasten, z. B. Online Analytical Processing (OLAP) und generative KI. |
| alloydbomni_monitor | Mit dem AlloyDB Omni-Monitor können Sie Messwerte aus AlloyDB Omni abrufen. |
| etcd | etcd bietet ein verteiltes Konfigurationssystem, das vom Cluster-Manager zum Speichern von PostgreSQL-Konfigurations- und Statusinformationen verwendet wird. |
| Cluster-Manager | Die zentrale Steuerungsebene orchestriert clusterweite Vorgänge. Dazu gehören das Bootstrapping des Clusters, die Verwaltung von HA, die Verarbeitung von Failover, die Koordinierung von Upgrades und die Bereitstellung von Schnittstellen für Automatisierungstools wie Ansible und das alloydbctl-Befehlszeilentool. |
| Knotenmanager | Ein Agent, der auf jedem Knoten im AlloyDB Omni-Cluster ausgeführt wird. Er interagiert mit dem Cluster-Manager, um Tasks auf dem Knoten auszuführen, z. B. die Installation und Konfiguration von AlloyDB Omni, die Verwaltung des Lebenszyklus des Datenbankdienstes (Starten und Beenden), das Monitoring des Knotenzustands und das Erfassen von Logs und Messwerten. |
| HAProxy | HAProxy fungiert als Load-Balancer für AlloyDB Omni-Bereitstellungen. Sie stellt die Endpunkte mit Lese-/Schreibzugriff und Lesezugriff bereit. Er arbeitet mit dem Clustermanager zusammen, um Traffic an die entsprechenden aktiven Knoten weiterzuleiten. |
| keepalived | keepalived kann Hochverfügbarkeit für die teilnehmenden Knoten, z. B. HAProxy, mithilfe einer Floating-IP-Adresse bereitstellen. |
| PgBouncer | PgBouncer ist ein einfacher Connection Pooler für PostgreSQL-Datenbanken. |
| pgBackRest | pgBackRest ist ein Open-Source-Sicherungs- und Wiederherstellungstool für PostgreSQL. |
Mit dieser Architektur können Sie AlloyDB Omni effizient in Ihrer vorhandenen Linux-VM-Umgebung ausführen und betreiben. Dabei wird AlloyDB Omni mit Ihren vertrauten Betriebsabläufen kombiniert.
Systemanforderungen
Zu den Systemanforderungen für den AlloyDB Omni-Bereitstellungsstack gehört eine Reihe von virtuellen Maschinen, die für die Ausführung verschiedener Komponenten vorkonfiguriert sind. Jede virtuelle AlloyDB Omni-Maschine muss ein angehängtes Datenlaufwerk haben, das mit dem ext4/xfs-Dateisystem konfiguriert ist. Die Laufwerkgröße wird anhand der Datengröße geschätzt. Die Leistungsmerkmale des Speichers wirken sich auf die Leistung von AlloyDB Omni aus. In der folgenden Tabelle finden Sie die Mindest- und empfohlenen CPU- und Arbeitsspeicherkonfigurationen für die VMs.
| VM-Typ | Mindestanforderungen an Hardware und Betriebssystem | Empfohlene Hardware und Betriebssysteme |
|---|---|---|
| Controllerknoten |
|
|
| Load-Balancer-Knoten |
|
|
| AlloyDB Omni (eigenständig) |
|
|
| AlloyDB Omni (hochverfügbar) |
|
|
| Backup-Repository-Knoten |
|
|
Referenzarchitektur für Hochverfügbarkeitsbereitstellung
Die HA-Architektur bietet im Vergleich zu Datenbanken mit einem einzelnen Knoten einen besseren Schutz vor Ausfallzeiten der Datenschicht. Beide HA-Referenzarchitekturen verwenden eine Datenbankeinrichtung mit mehreren Knoten (primary_instance_nodes-Gruppe) mit einem aktiven primären Knoten und synchronen, per Streaming replizierten Standby-Knoten, die in separaten Zonen bereitgestellt werden. Wenn der primäre Knoten ausfällt, übernimmt ein Standby-Knoten die Rolle des primären Knotens, um Clientanfragen zu verarbeiten.
Die Cluster-Manager-Komponente im Softwarestack führt die Clusterkonfiguration durch, überwacht den Zustand des AlloyDB Omni-Servers und orchestriert das automatische Failover, indem sie den neuen primären Server mithilfe eines verteilten Konfigurationssystems wie etcd auswählt. Unternehmen verwenden RPO und Recovery Time Objective (RTO) als wichtigste Messwerte für die Verfügbarkeit. Die Hochverfügbarkeitsarchitektur bietet einen RPO- und RTO-Wert von nahezu null für Ausfälle auf Zonenebene. Sie können auch Sicherungen und optionale Lesepoolinstanzen mit asynchroner Replikation konfigurieren, um Arbeitslasten mit Lesezugriff auszulagern.
Je nach Arbeitslast und Routinganforderungen können Sie AlloyDB Omni entweder mit der resilienten HA-Architektur bereitstellen, die ohne dedizierte Load-Balancer-Knoten auskommt, oder mit der skalierbaren HA-Architektur, die dedizierte Load-Balancer-Knoten enthält:
Resiliente Hochverfügbarkeit
Die robuste HA-Architektur stellt die Datenbankknoten (primary_instance_nodes-Gruppe) ohne dedizierte Load-Balancer-Knoten bereit:
- Virtuelles IP-Routing: Der
keepalived-Dienst wird direkt auf den Datenbankknoten ausgeführt und verwaltet eine dynamische virtuelle IP-Adresse, die auf den aktiven primären Knoten verweist. Bei dieser Konfiguration wird der Lese-/Schreibendpunkt direkt auf dem aktiven Knoten bereitgestellt. Clientanwendungen stellen über die virtuelle IP-Adresse eine Verbindung zur Datenbank her. Wenn ein Failover auftritt und ein Standby-Knoten zum primären Knoten hochgestuft wird, wechselt derkeepalived-Dienst automatisch die virtuelle IP-Adresse zum neuen aktiven primären Knoten. - Verbindungs-Pooling: Wenn Sie PgBouncer für das Verbindungs-Pooling verwenden, wird es direkt auf den Datenbankknoten ausgeführt.
Skalierbare Hochverfügbarkeit
Die skalierbare HA-Architektur fügt dem Datenbankcluster dedizierte Load-Balancer-Knoten (Gruppe load_balancer_nodes) hinzu:
- HAProxy-Load-Balancing: Auf den dedizierten Load-Balancer-Knoten wird HAProxy ausgeführt, das sowohl Lese-/Schreib- als auch Lesezugriff-Endpunkte bereitstellt. HAProxy arbeitet mit dem Cluster-Manager zusammen, um den Knotenstatus zu überwachen, Lese-/Schreibabfragen an den aktiven primären Knoten weiterzuleiten und Abfragen mit Lesezugriff auf fehlerfreie Standby-Knoten oder optionale Lesepoolinstanzen zu verteilen. Wenn ein Failover auftritt, wechselt HAProxy automatisch den Lese-/Schreib-Traffic zum neuen aktiven Knoten.
- Hochverfügbarkeit des Load Balancers: Der Dienst
keepalivedwird auf den Load Balancer-Knoten ausgeführt und verwaltet eine Floating-VIP-Adresse über diese Knoten hinweg. Clients stellen über diese virtuelle IP-Adresse eine Verbindung zum HAProxy-Load-Balancer her, um Datenbankvorgänge auszuführen. Wenn der aktive HAProxy-Dienst oder Load-Balancer-Knoten ausfällt, migriert derkeepalived-Dienst die virtuelle IP-Adresse zu einem anderen Load-Balancer-Knoten. - Verbindungs-Pooling: Wenn Sie PgBouncer für das Verbindungs-Pooling verwenden, wird es auf den dedizierten Load-Balancer-Knoten zusammen mit HAProxy und
keepalivedausgeführt.
Das folgende Bild zeigt die HA-Bereitstellungsarchitektur:
Abbildung 3: Hochverfügbarkeits-Bereitstellungsarchitektur
RPM-Orchestrator
AlloyDB Omni mit dem RPM-Orchestrator bietet eine Automatisierungsplattform und eine Steuerungsebene zum Installieren, Einrichten und Verwalten von AlloyDB Omni-Datenbankclustern auf einer Reihe von VMs oder Bare-Metal-Servern. Dazu gehören verschiedene Referenzarchitekturkonfigurationen, z. B. eigenständige, robuste und skalierbare Hochverfügbarkeit (HA).
Der AlloyDB Omni-Clustermanager stellt die Steuerungsebene bereit. Diese Komponente ist der Hauptdienst, der die Verwaltung und Hochverfügbarkeit des AlloyDB Omni-Clusters automatisiert, um den End-to-End-Lebenszyklus eines AlloyDB Omni-Clusters zu steuern. Die Steuerungsebene selbst ist hochverfügbar und kann verschiedene Fehlerszenarien bewältigen.
Die Bereitstellungsoption für den RPM-Orchestrator ist die Remote-Schnittstelle für die Kommunikation mit dem AlloyDB Omni-Clustermanager-Dienst. Der Orchestrator wird auf einem dedizierten Knoten ausgeführt, der als Steuerungsknoten bezeichnet wird. Über diesen Knoten können Sie einen oder mehrere Cluster remote über einen sicheren Kanal verwalten. Für die Kompatibilität mit Ihrer Umgebung sind mehrere AlloyDB Omni-Orchestratoren verfügbar. Wählen Sie einen Orchestrator aus, der Ihren Automatisierungsanforderungen entspricht.
- AlloyDB Omni-Orchestrator-CLI (als RPM verfügbar): Diese Option wird für Umgebungen empfohlen, in denen Shell-Skripts zur Automatisierung der Clusterbereitstellung und -verwaltung verwendet werden.
- RPM-Orchestrator Ansible (als Ansible-Sammlung verfügbar): Dies wird für Umgebungen empfohlen, die eine integrierte Ansible-basierte Automatisierung verwenden und diese mit Aufrufen zusätzlicher Ansible-Rollen erweitern möchten. Es werden Beispiel-Ansible-Playbooks bereitgestellt, um eine einfache Integration in vorhandene Ansible-Playbooks zu ermöglichen.
Der AlloyDB Omni-Orchestrator erleichtert die folgenden AlloyDB Omni-Cluster-bezogenen Vorgänge. Der Ansible-basierte Orchestrator stellt für jeden dieser Vorgänge Ansible-Rollen bereit. Die Befehlszeile bietet eine Reihe von Befehlen, die über eine Shell-Eingabeaufforderung oder Shell-Skripts aufgerufen werden.
Installation: Verschiedene Clusterkomponenten auf den entsprechenden Knoten installieren.Bootstrap: Alle Komponenten gemäß ihren Spezifikationen konfigurieren und booten.Update: Ressourcen für neuere Versionen oder aktualisierte Konfigurationen aktualisieren.Status: Den Status aller Komponenten oder Dienste im Cluster abrufen.Delete: Clusterressourcen löschen.
Die Orchestratoren verwenden eine Reihe von Spezifikationen im YAML-Format als Eingabe.
- Bereitstellungsspezifikation: Diese entspricht dem Ansible-Inventarformat, das die Topologie des VM-Clusters definiert. Sie enthält verschiedene VM-Gruppen, z. B. die folgenden, zusammen mit ihren Konfigurationen.
primary_instance_nodes: Knoten, die für AlloyDB Omni-Datenbankserver vorgesehen sind.cluster_manager_nodes: Optional. Knoten, auf denen AlloyDB Omni-Cluster-Manager-Server ausgeführt werden. Wenn keine dedizierten Cluster-Manager-Knoten vorhanden sind, können Sie den Cluster-Manager auf demprimary_instance_nodesbereitstellen.etcd_nodes: Der Cluster-Manager speichert Metadaten in etcd. etcd kann auf denselben Knoten wie Cluster-Manager-Knoten ausgeführt werden, sofern nicht explizit angegeben.load_balancer_nodes: Optional. Zusätzliche Knoten, die für einen HAProxy-basierten Load-Balancer in einer skalierbaren HA-Bereitstellung vorgesehen sind. Wenn Sie nichts angeben, werdenkeepalivedund PgBouncer direkt auf den Knoten in der Gruppeprimary_instance_nodesin einer ausfallsicheren HA-Bereitstellung ausgeführt.
- Ressourcenspezifikation: Ein Cluster besteht aus einer oder mehreren Clusterressourcen, die bereitgestellt und verwaltet werden sollen, z. B. Datenbankcluster und Verbindungspooler. Die Ressourcenspezifikation ist im YAML-Format und beschreibt die Ressourcen, die im Cluster bereitgestellt werden sollen.
Beschränkungen
- Die Vorabversion unterstützt nur Folgendes:
- AlloyDB Omni PostgreSQL 18
- Mit RHEL-Version 9 kompatible Softwarepakete
- Intel x86 64-Bit-Plattform
- Upgrades der Hauptversion werden nicht unterstützt.
- Eine Anleitung zum Einrichten von Instanzen für die Notfallwiederherstellung und Lesepoolinstanzen ist nicht enthalten.
- Das AlloyDB Omni-Monitoring unterstützt keine SSL-Verbindungen. Sie müssen Ihre Monitoring-Dashboard-Server im selben privaten Netzwerk wie die AlloyDB Omni-Knoten bereitstellen.
- AlloyDB Omni unterstützt SELinux sowohl im Modus „Zulässig“ als auch im erzwungenen Modus. Sie müssen den ausgewählten SELinux-Modus konfigurieren, bevor Sie den Cluster bootstrappen. Der Wechsel zum Erzwingungsmodus nach dem Bootstrapping wird nicht unterstützt.
Nächste Schritte
- Wenn Sie diese Bereitstellungsoption nutzen möchten, fordern Sie über das Registrierungsformular Zugriff an.
- Wählen Sie eine Download- und Installationsoption für AlloyDB Omni aus.
- Installieren Sie den AlloyDB Omni-Orchestrator.