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 mit 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 Bereitstellungsoption für den RPM-Orchestrator 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 einheitliche 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 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: Die Lösung lässt sich nativ in die Standard-Linux-Paketverwaltung (RPM) und gängige Automatisierungsframeworks wie Ansible einbinden. So können Teams vorhandene Kenntnisse und Tool-Integrationen nutzen.
- 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: Erleichtert die Implementierung vielfältiger 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 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. 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 (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 (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
Bei einer resilienten HA-Architektur werden ein aktiver primärer Knoten und Standby-Knoten in separaten Zonen ohne dedizierte Load-Balancer-Knoten bereitgestellt.
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 ausfallsichere 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 der Cluster-Manager zum Speichern von PostgreSQL-Konfigurations- und Statusinformationen verwendet. |
| 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 schlanker Verbindungspooler 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 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 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 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 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:
Ausfallsichere 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 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 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, leitet HAProxy den Lese-/Schreibtraffic automatisch zum neuen aktiven Knoten um.
- 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 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): 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: Aktualisieren Sie Ressourcen für neuere Versionen oder aktualisierte Konfigurationen.Status: 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 anders 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 RPM-Orchestrator-Bereitstellungsoption 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.
- 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. Ein 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.