AlloyDB Omni bietet eine Orchestrierungsplattform zum Bereitstellen und Verwalten von AlloyDB Omni in Nicht-Kubernetes-Umgebungen, z. B. auf 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 Infrastrukturen und Infrastrukturen für virtuelle Maschinen (VM).
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 haben und etablierte Betriebsabläufe haben, die auf Automatisierungstools wie Ansible basieren. 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.
Anwendungsfälle
Die Bereitstellungsoption für den RPM-Orchestrator 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 | Automatisierung der Datenbankbereitstellung, -konfiguration und -lebenszyklusverwaltung mit vertrauten Tools wie Ansible. |
| Hochverfügbarkeit und Notfallwiederherstellung | Richtet robuste AlloyDB Omni-Cluster mit automatischen Failover- und Wiederherstellungsmechanismen ein. |
| Hybridumgebungen | Sorgt für einheitliche Datenbankvorgänge in lokalen Rechenzentren und Cloud-VMs. |
| Integration von Altsystemen | 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 wird von der Bereitstellung bis zur Überprüfung automatisiert. Dadurch werden Zeit und Komplexität der Einrichtung von AlloyDB Omni-Clustern erheblich reduziert.
- Nahtlose Integration: Die Lösung lässt sich nativ in die Standard-Linux-Paketverwaltung (RPM) und beliebte Automatisierungsframeworks wie Ansible einbinden. So können Teams vorhandene Kenntnisse und Tool-Integrationen nutzen.
- Konsistente Bedienung: Bietet eine Nutzerfreundlichkeit und ein Feature-Set für Verwaltung und Betrieb, die mit dem AlloyDB Omni Kubernetes-Operator vergleichbar sind. Dies sorgt für Konsistenz über verschiedene Bereitstellungsmodelle hinweg.
- Hochverfügbarkeit (High Availability, HA) und Notfallwiederherstellung (Disaster Recovery, DR) auf Unternehmensniveau: Unterstützt flexible Konfigurationen für Hochverfügbarkeit und Notfallwiederherstellung, um den Anforderungen an die Geschäftskontinuität gerecht zu werden.
- Robuste Sicherheit: Ermöglicht die Implementierung vielschichtiger Sicherheitsstrategien, einschließlich Nutzerverwaltung, Netzwerksicherheit mit Zertifikaten (SSL) und Integration in Systeme wie Microsoft Active Directory.
- Zentrale Verwaltung: Der AlloyDB Omni-Dienst bietet eine einheitliche Steuerungsebene für die Verwaltung von AlloyDB Omni auf VMs.
- Beobachtbarkeit und Auditierung: Ermöglicht die Integration in externe Logging-Server wie Elastic Stack über rsyslog für die zentrale Logverwaltung, 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 in großem Umfang verwalten.
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. So können Sie Ihre AlloyDB Omni-Bereitstellung überwachen und ihre Skalierung und Größe an Ihre Arbeitslasten anpassen.
Die folgende Abbildung zeigt die Taxonomie der AlloyDB Omni-Bereitstellung in einer Bare-Metal- oder VM-Umgebung.
Abbildung 1: Topologie der AlloyDB Omni-VM-Bereitstellung
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 Zugriffs-Endpunkt. 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 mit den Softwarepaketen bereitgestellt.
Die primäre Instanz enthält einen aktiven (Lese-/Schreib-)Knoten, der für die Verarbeitung von transaktionalen Arbeitslasten vorgesehen ist. Für Datenbankcluster, die über grundlegende Tests, Experimente und Entwicklung hinausgehen, sollten Sie Hochverfügbarkeit mit zusätzlichen Standby-Knoten einrichten. Um Datenverlust (RPO=0) im Falle eines Fehlers zu vermeiden, der zum Verlust der Verfügbarkeit eines primären Knotens führt, der Lese- und Schreibtransaktionen verarbeitet, konfigurieren Sie den synchronen Replikationsmodus des Standby-Knotens. RPO wird als Recovery Point Objective definiert.
Komponenten
Die Bereitstellungsoption für den RPM-Orchestrator umfasst eine Reihe von Softwarekomponenten, die jeweils als RPM- oder Debian-Pakete für eine Full-Stack-Bereitstellung von AlloyDB Omni mit hoher Verfügbarkeit installiert werden. Die Referenzarchitektur basiert für Datenbankvorgänge auf diesen Komponenten.
| 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 wie 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 Clustermanager zum Speichern von PostgreSQL-Konfigurations- und Statusinformationen verwendet wird. |
| Clusteradministrator | 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 Clustermanager, um Aufgaben 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 macht die Lese-/Schreib- und schreibgeschützten Endpunkte verfügbar. Es arbeitet mit dem Clustermanager zusammen, um Traffic an die entsprechenden aktiven Knoten weiterzuleiten. |
| keepalived | keepalived kann HA für die beteiligten Knoten bereitstellen, z. B. HAProxy, indem es eine Floating-Virtual-IP-Adresse verwendet. |
| PgBouncer | PgBouncer ist ein einfacher Connection-Pooler für PostgreSQL-Datenbanken. |
| pgBackRest | pgBackRest ist ein Open-Source-Tool zum Sichern und Wiederherstellen von PostgreSQL-Daten. |
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 AlloyDB Omni-virtuelle Maschine muss eine angehängte Datenfestplatte mit dem ext4-/xfs-Dateisystem zugewiesen sein. Die Laufwerksgröß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) |
|
|
| Sicherungs-Repository-Knoten |
|
|
Referenzarchitektur für die Bereitstellung mit Hochverfügbarkeit
Die HA-Architektur bietet im Vergleich zu Datenbankkonfigurationen mit nur einem Knoten einen höheren Schutz vor Ausfällen der Datenstufe. Diese Referenzarchitekturkonfiguration verwendet eine Einrichtung mit drei Knoten, wobei ein Knoten als primärer aktiver Knoten und die anderen Knoten als synchron gestreamte replizierte Standby-Server fungieren, die in separaten Zonen bereitgestellt werden. Wenn ein primärer Knoten ausfällt, übernimmt einer der Standby-Knoten die Rolle des primären Knotens, um Clientanfragen zu verarbeiten.
Die Cluster-Manager-Komponente im Softwarestack führt die Clusterkonfiguration aus. Der Clustermanager überwacht auch den AlloyDB Omni-Server und wählt den neuen primären Server mithilfe eines verteilten Konfigurationssystems wie etcd aus. Unternehmen verwenden RPO und RTO (Recovery Time Objective) als die wichtigsten Messgrößen für die Verfügbarkeit. Die HA-Architektur bietet ein RPO und RTO von nahezu null für Ausfälle auf Zonenebene.
Auf einem zusätzlichen Knoten wird ein HAProxy-basierter Load Balancer mit zusätzlichen Endpunkten für schreibgeschützte Arbeitslasten bereitgestellt. HAProxy arbeitet mit dem Clustermanager zusammen, um den aktuellen aktiven Knoten zu überwachen und bei einem Failover zum neuen aktiven Knoten zu wechseln. Clients stellen eine Verbindung zum HAProxy-Knoten her, um Vorgänge in der Datenbank auszuführen. Das folgende Bild zeigt diese HA-Bereitstellungsarchitektur.
Abbildung 2: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-, ausfallsichere 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 Fehlerszenarien bewältigen.
Die Bereitstellungsoption für den RPM-Orchestrator ist die Remote-Schnittstelle für die Kommunikation mit dem AlloyDB Omni-Clustermanagerdienst. 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 zum Automatisieren der Clusterbereitstellung und -verwaltung verwendet werden.
- RPM-Orchestrator Ansible (als Ansible Collection verfügbar): Diese Option wird für Umgebungen empfohlen, in denen die integrierte Ansible-basierte Automatisierung verwendet wird und die mit Aufrufen zusätzlicher Ansible-Rollen erweitert werden sollen. Es sind Beispiel-Ansible-Playbooks verfügbar, die eine einfache Integration in vorhandene Ansible-Playbooks 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: Installieren Sie verschiedene Clusterkomponenten auf den entsprechenden Knoten.Bootstrap: Konfiguriert und bootet alle Komponenten gemäß ihren Spezifikationen.Update: Ressourcen für neuere Versionen oder aktualisierte Konfigurationen aktualisieren.Status: Ruft den Status aller Komponenten oder Dienste im Cluster ab.List: Eine Liste der im Cluster bereitgestellten verfügbaren Ressourcen abrufen.Delete: Clusterressourcen löschen.
Die Orchestratoren verwenden eine Reihe von Spezifikationen im YAML-Format als Eingabe.
- Bereitstellungsspezifikation: Dies 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-Clustermanager-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 Clustermanager speichert Metadaten in etcd. etcd kann auf denselben Knoten wie Clustermanagerknoten ausgeführt werden, sofern nicht explizit anders angegeben.load_balancer_nodes: Dies sind zusätzliche Knoten, die für einen HAProxy-basierten Load-Balancer vorgesehen sind.
- Ressourcenspezifikation: Ein Cluster besteht aus einer oder mehreren Clusterressourcen, die bereitgestellt und verwaltet werden sollen, z. B. Datenbankcluster und Verbindungspooler. Die Ressourcenspezifikation hat das 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 9 kompatible Softwarepakete
- Intel x86-64-Bit-Plattform
- Upgrades auf Hauptversionen werden nicht unterstützt.
- Eine Anleitung zum Einrichten von Instanzen für die Notfallwiederherstellung und Lesepoolinstanzen ist nicht enthalten.
- 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 geht davon aus, dass SELinux, sofern vorhanden, auf dem Host so konfiguriert ist, dass es permissive ist, einschließlich des Zugriffs auf das Dateisystem.
Nächste Schritte
- Wählen Sie eine Download- und Installationsoption für AlloyDB Omni aus.
- Installieren Sie den AlloyDB Omni-Orchestrator.