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 Bereitstellungsoption für den RPM-Orchestrator bietet cloudähnliche Flexibilität und Automatisierung für 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 stark in VM-Infrastruktur investiert haben und etablierte Betriebsabläufe nutzen, die auf Automatisierungstools wie Ansible basieren. 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 einheitliche 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 Bereitstellungsoption für den RPM-Orchestrator sind unter anderem:
- 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.
- Konsistente Nutzung: Bietet eine Nutzererfahrung und ein Feature-Set für Verwaltung und Betrieb, die mit dem AlloyDB Omni Kubernetes-Operator vergleichbar sind, was für Konsistenz über verschiedene Bereitstellungsmodelle hinweg sorgt.
- Hochverfügbarkeit und Notfallwiederherstellung 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: Ermöglicht die Verwaltung mehrerer AlloyDB Omni-Cluster im großen Maßstab.
Architektur
AlloyDB Omni definiert eine Hierarchie von Komponenten, die Flexibilität bieten. So können Sie die Datenverfügbarkeit maximieren und die Abfrageleistung und den Durchsatz 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 (nur Lesezugriff). 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 In-Sync-Replikationsmodus des Standby-Knotens.
Resiliente 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 dynamische virtuelle IP-Adresse zu verwalten, über die der Lese-/Schreibendpunkt auf dem aktiven primären Knoten verfügbar gemacht wird.
Die folgende Abbildung zeigt die resiliente HA-Bereitstellungsarchitektur in einer Bare-Metal- oder VM-Umgebung:
Abbildung 1: Ausfallsichere 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 einer skalierbaren AlloyDB Omni-Hochverfügbarkeitsbereitstellung in einer Bare-Metal- oder VM-Umgebung:
Abbildung 2: Skalierbare AlloyDB Omni-VM-Bereitstellungsarchitektur mit Hochverfügbarkeit
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 der Hochverfügbarkeit, die Verarbeitung von Failover, die Koordination von Upgrades und die Bereitstellung von Schnittstellen für Automatisierungstools wie Ansible und das alloydbctl-Befehlszeilen-Dienstprogramm. |
| 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. AlloyDB Omni zu installieren und zu konfigurieren, den Lebenszyklus des Datenbankdienstes zu verwalten (starten und stoppen), den Knotenstatus zu überwachen und Logs und Messwerte zu erfassen. |
| 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 für die beteiligten Knoten, z. B. HAProxy, eine hohe Verfügbarkeit mit einer Floating-VIP-Adresse bieten. |
| 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 und AlloyDB Omni mit Ihren etablierten Betriebsabläufen kombinieren.
Systemanforderungen
Die Systemanforderungen für den AlloyDB Omni-Bereitstellungsstack umfassen 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 minimalen 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) |
|
|
| Knoten des Backup-Repositorys |
|
|
Referenzarchitektur für die HA-Bereitstellung
Die HA-Architektur bietet im Vergleich zu Datenbankeinrichtungen mit einem einzelnen Knoten einen besseren Schutz vor Ausfallzeiten der Datenebene. 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 Clientabfragen 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 die wichtigsten Messgrößen für die Verfügbarkeit. Die HA-Architektur-Setups bieten 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
Bei der resilienten HA-Architektur werden die Datenbankknoten (primary_instance_nodes-Gruppe) ohne dedizierte Load-Balancer-Knoten bereitgestellt:
- Virtuelles IP-Routing: Der
keepalived-Dienst wird direkt auf den Datenbankknoten ausgeführt und verwaltet eine Floating-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 Clustermanager zusammen, um den Status von Knoten zu überwachen, Lese-/Schreibanfragen an den aktiven primären Knoten weiterzuleiten und schreibgeschützte Anfragen auf fehlerfreie Standby-Knoten oder optionale Lesepoolinstanzen zu verteilen. Wenn ein Failover auftritt, leitet HAProxy den Lese-/Schreibtraffic automatisch zum neuen aktiven Knoten um.
- 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 (High Availability, HA).
Der AlloyDB Omni-Clustermanager stellt die Steuerungsebene bereit. Diese Komponente ist der Kerndienst, der die Verwaltung und Hochverfügbarkeit des AlloyDB Omni-Clusters automatisiert, um den gesamten Lebenszyklus eines AlloyDB Omni-Clusters zu steuern. Die Steuerungsebene selbst ist hochverfügbar und kann verschiedene Ausfallszenarien bewältigen.
Die RPM-Orchestrator-Bereitstellungsoption ist die Remote-Schnittstelle für die Kommunikation mit dem AlloyDB Omni-Cluster-Manager-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): Dies 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 bietet Ansible-Rollen für jeden dieser Vorgänge. 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 nicht angegeben, werdenkeepalivedund PgBouncer direkt auf den Knoten in der Gruppeprimary_instance_nodesin einer resilienten 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 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.