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 Standard ist, oder containerisierte Umgebungen mit Anwendungsabhängigkeiten, die standardmäßige VM- oder Bare-Metal-Bereitstellungen bevorzugen. |
| Vereinfachter Betrieb | Automatisieren Sie die Bereitstellung, Konfiguration und Verwaltung des Lebenszyklus 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 bestehende 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.
- 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 Prüfung: Ermöglicht die Einbindung externer Logging-Server, z. B. Elastic Stack, mithilfe von rsyslog für das zentralisierte Logging, das Monitoring und die Prüfung.
- Datenschutz: Umfasst Funktionen für vereinfachte Sicherungs- und Wiederherstellungskonfigurationen und -strategien.
- Verbindungs-Pooling: Unterstützt die Bereitstellung von PgBouncer, um Datenbankverbindungen zu optimieren und die Leistung zu verbessern.
- 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, die einen primären Cluster und einen oder mehrere sekundäre Cluster enthält. 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 (Lese-/Schreib-)Knoten, der für die Verarbeitung von transaktionalen Arbeitslasten vorgesehen 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 resiliente 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 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 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. Jeder AlloyDB Omni-VM muss eine angehängte Datenfestplatte zugewiesen sein, die 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 Hochverfügbarkeitsbereitstellung
Die HA-Architektur bietet im Vergleich zu Datenbankeinrichtungen mit einem einzelnen Knoten einen besseren Schutz vor Ausfällen der Datenebene. Beide HA-Referenzarchitekturen verwenden eine Datenbankkonfiguration mit mehreren Knoten (primary_instance_nodes-Gruppe) mit einem aktiven primären Knoten und synchron gestreamten 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 Software-Stack führt die Clusterkonfiguration durch, überwacht den Zustand des AlloyDB Omni-Servers und orchestriert das automatische Failover, indem sie mithilfe eines verteilten Konfigurationssystems wie etcd den neuen primären Server auswählt. Unternehmen verwenden RPO und Recovery Time Objective (RTO) als die wichtigsten Messgrößen für die Verfügbarkeit. Die HA-Architekturkonfigurationen 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 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 (load_balancer_nodes-Gruppe) 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, wechselt HAProxy automatisch den Lese-/Schreib-Traffic zum neuen aktiven Knoten.
- Hochverfügbarkeit des Load-Balancers: Der
keepalived-Dienst wird auf den Load-Balancer-Knoten ausgeführt und verwaltet eine Floating-VIP-Adresse für diese Knoten. 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.
Die folgende Abbildung zeigt die Architektur der Hochverfügbarkeitsbereitstellung:
Abbildung 3: HA-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. Standalone, resilient und skalierbare Hochverfügbarkeit (High Availability, 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 Ausfallszenarien 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 wird für Umgebungen empfohlen, in denen Shell-Skripts verwendet werden, um die Bereitstellung und Verwaltung von Clustern zu automatisieren.
- 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 ermöglicht 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: Installieren Sie verschiedene Clusterkomponenten auf den entsprechenden Knoten.Bootstrap: Alle Komponenten gemäß ihren Spezifikationen konfigurieren und bootstrappen.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.
- Anleitungen zum Einrichten von Notfallwiederherstellungs- und Lesepoolinstanzen sind nicht enthalten.
- Die AlloyDB Omni-Überwachung 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 permissiven als auch im erzwungenen Modus. Sie müssen den ausgewählten SELinux-Modus konfigurieren, bevor Sie den Cluster booten. 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.