Panoramica di AlloyDB Omni utilizzando l'orchestratore RPM

Seleziona una versione della documentazione:

AlloyDB Omni fornisce una piattaforma di orchestrazione per eseguire il deployment e gestire AlloyDB Omni in ambienti non Kubernetes, ad esempio su Red Hat Enterprise Linux (RHEL) e sistemi compatibili che utilizzano pacchetti Red Hat Package Manager (RPM). L'opzione di deployment dell'orchestratore RPM estende la flessibilità e l'automazione simili al cloud all'infrastruttura on-premise e alle macchine virtuali (VM).

AlloyDB Omni che utilizza l'orchestratore RPM consente alle aziende di installare, configurare e gestire le istanze AlloyDB Omni utilizzando pacchetti RPM standard. Questo approccio supporta le organizzazioni che hanno investimenti significativi nell'infrastruttura VM e pratiche operative consolidate basate su strumenti di automazione, ad esempio Ansible. L'opzione di deployment dell'agente di orchestrazione RPM viene eseguita direttamente su VM Linux o server bare metal senza richiedere un livello di containerizzazione come Docker o un sistema di orchestrazione come Kubernetes.

Per iniziare a utilizzare questa opzione di deployment, richiedi l'accesso utilizzando il modulo di registrazione.

Casi d'uso

L'opzione di deployment dell'orchestratore RPM supporta i seguenti casi d'uso:

Caso d'uso Descrizione
Aziende con infrastruttura VM Supporta le aziende in cui Kubernetes non è standard o gli ambienti containerizzati con dipendenze delle applicazioni che preferiscono i deployment standard di VM o bare metal.
Operazioni semplificate Automatizza il deployment, la configurazione e la gestione del ciclo di vita del database utilizzando strumenti familiari, ad esempio Ansible.
Alta affidabilità (HA) e ripristino di emergenza (RE) Configura cluster AlloyDB Omni resilienti con meccanismi di failover e ripristino automatici.
Ambienti ibridi Garantisce operazioni di database coerenti tra i data center on-premise e le VM cloud.
Integrazione dei sistemi legacy Si integra con applicazioni e sistemi esistenti progettati per ambienti non containerizzati.

Vantaggi

I vantaggi dell'opzione di deployment dell'orchestratore RPM includono:

  • Deployment rapido: automatizza l'intero ciclo di vita, dal provisioning alla verifica, riducendo in modo significativo i tempi e la complessità della configurazione dei cluster AlloyDB Omni.
  • Integrazione perfetta: si integra in modo nativo con la gestione dei pacchetti Linux standard (RPM) e con i framework di automazione più diffusi, ad esempio Ansible, che consente ai team di utilizzare le competenze e le integrazioni degli strumenti esistenti.
  • Esperienza coerente: offre un'esperienza utente e un insieme di funzionalità per la gestione e le operazioni paragonabili all'operatore Kubernetes di AlloyDB Omni, che garantisce la coerenza tra i diversi modelli di deployment.
  • Alta affidabilità (HA) e ripristino di emergenza (RE) di livello enterprise: supporta configurazioni flessibili per l'alta affidabilità e ripristino di emergenza per soddisfare le esigenze di continuità aziendale.
  • Sicurezza efficace: facilita l'implementazione di strategie di sicurezza multidimensionale, tra cui la gestione degli utenti, la sicurezza di rete con certificati (SSL) e l'integrazione con i sistemi, ad esempio Microsoft Active Directory.
  • Gestione centralizzata: utilizza il servizio AlloyDB Omni per fornire un control plane unificato per la gestione di AlloyDB Omni sulle VM.
  • Osservabilità e controllo: consente l'integrazione con server di logging esterni, ad esempio Elastic Stack, utilizzando rsyslog per la gestione, il monitoraggio e il logging centralizzato.
  • Protezione dei dati: include funzionalità per configurazioni e strategie semplificate di backup e ripristino.
  • Pool di connessioni: supporta il deployment di PgBouncer per ottimizzare le connessioni al database e migliorare le prestazioni.
  • Gestione del parco risorse: consente di gestire più cluster AlloyDB Omni su larga scala.

Architettura

AlloyDB Omni definisce una gerarchia di componenti che offrono flessibilità. Questa flessibilità ti aiuta a massimizzare la disponibilità dei dati e a ottimizzare il rendimento e la velocità effettiva delle query. Questo approccio ti consente di monitorare la deployment di AlloyDB Omni e di regolarne la scalabilità e le dimensioni in base ai tuoi carichi di lavoro.

La risorsa di primo livello nella gerarchia è un deployment di AlloyDB Omni che include un cluster principale e uno o più cluster secondari. Un cluster AlloyDB Omni ha una o più istanze, che sono un'astrazione delle risorse di computing a cui si connettono gli utenti. Il cluster include un'istanza principale (di lettura/scrittura) e una o più istanze facoltative del pool di lettura (di sola lettura). Ogni istanza ha il proprio endpoint di accesso. Se vuoi, puoi configurare un'istanza principale con un singolo nodo per il deployment autonomo o con più nodi per il deployment ad alta affidabilità. In tutti i nodi è stato eseguito il deployment di AlloyDB Omni e di altri componenti correlati utilizzando i pacchetti software.

L'istanza principale contiene un nodo attivo (lettura/scrittura) progettato per gestire i workload transazionali. Per i cluster di database che vanno oltre i test, gli esperimenti e lo sviluppo di base, configura l'alta affidabilità con nodi di standby aggiuntivi. Per evitare la perdita di dati e raggiungere un Recovery Point Objective (RPO) pari a zero in caso di errore del nodo principale, configura la modalità di replica sincronizzata del nodo in standby.

HA resiliente

Un'architettura HA resiliente esegue il deployment di un nodo primario attivo e di nodi di standby in zone separate senza nodi del bilanciatore del carico dedicati. Il servizio keepalived viene eseguito direttamente sui nodi del database per gestire un indirizzo IP virtuale mobile che espone l'endpoint di lettura/scrittura sul nodo primario attivo.

La figura seguente mostra l'architettura di deployment ad alta affidabilità resiliente in un ambiente bare metal o VM:

Architettura di deployment HA resiliente di AlloyDB Omni.

Fig. 1. Architettura di deployment HA resiliente di AlloyDB Omni

HA scalabile

Un'architettura HA scalabile esegue il deployment di un nodo primario attivo e di nodi di standby in zone separate, in combinazione con nodi di bilanciamento del carico HAProxy dedicati. Questi nodi del bilanciatore del carico espongono gli endpoint di lettura/scrittura e di sola lettura e instradano il traffico client.

La figura seguente mostra la tassonomia di un deployment ad alta affidabilità scalabile di AlloyDB Omni in un ambiente bare metal o VM:

Architettura di deployment delle VM ad alta affidabilità scalabile di AlloyDB Omni.

Fig. 2. Architettura di deployment delle VM HA scalabili di AlloyDB Omni

Componenti

L'opzione di deployment dell'orchestratore RPM include un insieme di componenti software, ciascuno installato come pacchetto RPM o Debian, per un deployment AlloyDB Omni full stack ad alta affidabilità. L'architettura di riferimento si basa su questi componenti per le operazioni di database.

Componente Descrizione
Orchestratore L'orchestrazione di AlloyDB Omni fornisce interfacce a riga di comando e Ansible per aiutarti a eseguire il deployment e la gestione di uno o più cluster AlloyDB Omni in un ambiente distribuito.
alloydbomni Il core di AlloyDB Omni include PostgreSQL e funzionalità di pilota automatico per prestazioni e funzionalità migliorate per supportare i workload moderni, ad esempio l'elaborazione analitica online (OLAP) e l'AI generativa.
alloydbomni_monitor Il monitor di AlloyDB Omni ti consente di estrarre metriche da AlloyDB Omni.
etcd etcd fornisce un sistema di configurazione distribuito che il gestore del cluster utilizza per archiviare le informazioni di configurazione e stato di PostgreSQL.
Gestore dei cluster Il control plane centrale orchestra le operazioni a livello di cluster. Ciò include il bootstrap del cluster, la gestione dell'alta affidabilità, la gestione del failover, il coordinamento degli upgrade e l'esposizione delle interfacce per gli strumenti di automazione, ad esempio Ansible e l'utilità a riga di comando alloydbctl.
Node manager Un agente eseguito su ciascun nodo del cluster AlloyDB Omni. Interagisce con il gestore dei cluster per eseguire attività sul nodo, ad esempio l'installazione e la configurazione di AlloyDB Omni, la gestione del ciclo di vita del servizio di database (avvio e arresto), il monitoraggio dello stato del nodo e la raccolta di log e metriche.
HAProxy HAProxy funziona come bilanciatore del carico per i deployment di AlloyDB Omni. Espone gli endpoint di lettura/scrittura e di sola lettura. Collabora con il gestore del cluster per reindirizzare il traffico ai nodi attivi appropriati.
keepalived keepalived può fornire HA per i nodi partecipanti, ad esempio HAProxy, utilizzando un indirizzo IP virtuale mobile.
PgBouncer PgBouncer è un pooler di connessioni leggero per i database PostgreSQL.
pgBackRest pgBackRest è uno strumento open source di backup e ripristino progettato per PostgreSQL.

Questa architettura ti consente di eseguire e utilizzare AlloyDB Omni in modo efficiente nel tuo ambiente VM Linux esistente, combinando AlloyDB Omni con la familiarità delle tue pratiche operative consolidate.

Requisiti di sistema

I requisiti di sistema per lo stack di deployment di AlloyDB Omni includono un insieme di macchine virtuali preconfigurate per l'esecuzione di vari componenti. Ogni macchina virtuale AlloyDB Omni deve avere un disco dati collegato configurato con il file system ext4/xfs. La dimensione del disco viene stimata in base alla dimensione dei dati. Le caratteristiche di prestazioni dello spazio di archiviazione influiscono sulle prestazioni di AlloyDB Omni. La tabella seguente fornisce le configurazioni minime e consigliate di CPU e memoria per le VM.

Tipo di VM Hardware e sistema operativo (OS) minimi Hardware e sistema operativo consigliati
Nodo controller
  • OS: RHEL9
  • CPU: x86-64 2 vCPU con supporto AVX2
  • RAM: 2 GB
  • Disco: 10 GB
  • Sistema operativo: RHEL9
  • CPU: x86-64 8 vCPU con supporto AVX2
  • RAM: 8 GB
  • Disco: 20 GB o più
Nodi del bilanciatore del carico
  • OS: RHEL9
  • CPU: x86-64 2 vCPU con supporto AVX2
  • RAM: 2 GB
  • Disco: 10 GB
  • Sistema operativo: RHEL9
  • CPU: x86-64 16 vCPU con supporto AVX2
  • RAM: 8 GB
  • Disco: 20 GB o più
AlloyDB Omni (autonomo)
  • OS: RHEL9
  • CPU: x86-64 2 vCPU con supporto AVX2
  • RAM: 16 GB
  • Disco: 20 GB
  • Disco dati: 2 volte la dimensione dei dati
  • OS: RHEL9
  • CPU: x86-64 64 vCPU con supporto AVX2
  • RAM: 8 GB per vCPU per AlloyDB Omni
  • Disco: 20 GB
  • Disco dati: 2 volte la dimensione dei dati
AlloyDB Omni (alta affidabilità)
  • OS: RHEL9
  • CPU: x86-64 4 vCPU con supporto AVX2
  • RAM: 20 GB
  • Disco: 10 GB
  • Disco dati: 2 volte la dimensione dei dati
  • OS: RHEL9
  • CPU: x86-64 64 vCPU con supporto AVX2
  • RAM: almeno 8 GB per vCPU per AlloyDB Omni
  • Disco: 20 GB
  • Disco dati: 2 volte la dimensione dei dati
Nodo del repository di backup
  • Sistema operativo: RHEL9
  • CPU: x86-64 2 vCPU con supporto AVX2
  • RAM: 2 GB
  • Disco: 10 GB
  • Disco di backup: N giorni moltiplicati per le dimensioni dei dati
  • Sistema operativo: RHEL9
  • CPU: x86-64 8 vCPU con supporto AVX2
  • RAM: 8 GB
  • Disco: 20 GB
  • Disco di backup: N giorni moltiplicati per le dimensioni dei dati

Architettura di riferimento per il deployment ad alta affidabilità

L'architettura ad alta affidabilità offre una maggiore protezione contro i tempi di inattività del livello dati rispetto alle configurazioni di database a nodo singolo. Entrambe le architetture di riferimento ad alta affidabilità utilizzano una configurazione del database multi-nodo (gruppo primary_instance_nodes) con un nodo principale attivo e nodi in standby con replica in streaming sincrona, di cui è stato eseguito il deployment in zone separate. Se il nodo principale non funziona, un nodo di standby subentra come principale per gestire le query dei client.

Il componente gestore dei cluster nello stack software esegue la configurazione del cluster, monitora l'integrità del server AlloyDB Omni e orchestra il failover automatico scegliendo il nuovo nodo primario con l'aiuto di un sistema di configurazione distribuito come etcd. Le aziende utilizzano RPO e RTO (Recovery Time Objective) come misure chiave per la disponibilità. Le configurazioni dell'architettura ad alta affidabilità offrono RPO e RTO quasi pari a zero per gli errori a livello di zona. Puoi anche configurare i backup e le istanze del pool di lettura facoltative con la replica asincrona per l'offload dei workload di sola lettura.

A seconda dei requisiti di routing e del carico di lavoro, puoi eseguire il deployment di AlloyDB Omni utilizzando l'architettura HA resiliente, che opera senza nodi del bilanciatore del carico dedicati, o l'architettura HA scalabile, che include nodi del bilanciatore del carico dedicati:

HA resiliente

L'architettura HA resiliente esegue il deployment dei nodi del database (gruppo primary_instance_nodes) senza nodi del bilanciatore del carico dedicati:

  • Routing IP virtuale: il servizio keepalived viene eseguito direttamente sui nodi del database e gestisce un indirizzo IP virtuale mobile che punta al nodo principale attivo. Questa configurazione espone l'endpoint di lettura/scrittura direttamente sul nodo attivo. Le applicazioni client si connettono al database utilizzando l'indirizzo IP virtuale. Se si verifica un failover e un nodo di standby viene promosso a primario, il servizio keepalived cambia automaticamente l'indirizzo IP virtuale con il nuovo nodo primario attivo.
  • Pool di connessioni: se utilizzi PgBouncer per il pool di connessioni, questo viene eseguito direttamente sui nodi del database.

HA scalabile

L'architettura HA scalabile aggiunge nodi del bilanciatore del carico dedicati (gruppo load_balancer_nodes) al cluster di database:

  • Bilanciamento del carico HAProxy: i nodi del bilanciatore del carico dedicato eseguono HAProxy, che espone endpoint di lettura/scrittura e di sola lettura. HAProxy funziona con il gestore dei cluster per monitorare gli stati dei nodi, indirizzare le query di lettura/scrittura al nodo primario attivo e distribuire le query di sola lettura tra i nodi di standby integri o le istanze del pool di lettura facoltative. In caso di failover, HAProxy trasferisce automaticamente il traffico di lettura/scrittura al nuovo nodo attivo.
  • Alta affidabilità del bilanciatore del carico: il servizio keepalived viene eseguito sui nodi del bilanciatore del carico e gestisce un indirizzo IP virtuale mobile tra questi. I client si connettono al bilanciatore del carico HAProxy utilizzando questo indirizzo IP virtuale per eseguire operazioni sul database. Se il servizio HAProxy attivo o il nodo del bilanciatore del carico non funziona, il servizio keepalived esegue la migrazione dell'indirizzo IP virtuale a un altro nodo del bilanciatore del carico.
  • Pool di connessioni: se utilizzi PgBouncer per il pool di connessioni, questo viene eseguito sui nodi del bilanciatore del carico dedicati insieme ad HAProxy e keepalived.

La seguente immagine mostra l'architettura di deployment ad alta affidabilità:

Architettura di deployment ad alta affidabilità di AlloyDB Omni.

Fig. 3. Architettura di deployment ad alta disponibilità

Orchestratore RPM

AlloyDB Omni che utilizza l'orchestratore RPM fornisce una piattaforma di automazione e un control plane per l'installazione, la configurazione e la gestione dei cluster di database AlloyDB Omni su un insieme di VM o server bare metal. Sono incluse varie configurazioni di architettura di riferimento, ad esempio autonoma, resiliente e ad alta affidabilità (HA) scalabile.

Il gestore dei cluster AlloyDB Omni fornisce il control plane. Questo componente è il servizio principale che automatizza la gestione e l'alta affidabilità del cluster AlloyDB Omni per aiutare a controllare il ciclo di vita end-to-end di un cluster AlloyDB Omni. Il control plane stesso è ad alta affidabilità e gestisce vari scenari di errore.

L'opzione di deployment dell'orchestratore RPM è l'interfaccia remota per comunicare con il servizio gestito di gestione dei cluster AlloyDB Omni. L'orchestratore viene eseguito su un nodo dedicato, chiamato nodo di controllo. Da questo nodo puoi gestire uno o più cluster da remoto tramite un canale sicuro. Per la compatibilità con il tuo ambiente, sono disponibili più orchestratori di AlloyDB Omni. Scegli un orchestratore adatto alle tue esigenze di automazione.

  • Interfaccia a riga di comando dell'orchestratore di AlloyDB Omni (disponibile come RPM): questa opzione è consigliata per gli ambienti che utilizzano script shell per automatizzare il deployment e la gestione dei cluster.
  • RPM orchestrator Ansible (disponibile come raccolta Ansible): questa opzione è consigliata per gli ambienti che utilizzano l'automazione integrata basata su Ansible e sono pronti a estenderla con chiamate a ruoli Ansible aggiuntivi. Vengono forniti playbook Ansible di esempio per consentire una facile integrazione con i playbook Ansible esistenti.

L'orchestratore di AlloyDB Omni facilita le seguenti operazioni relative ai cluster AlloyDB Omni. L'orchestratore basato su Ansible fornisce ruoli Ansible per ciascuna di queste operazioni. La riga di comando fornisce un insieme di comandi richiamati utilizzando un prompt della shell o script della shell.

  • Installation: installa vari componenti del cluster sui rispettivi nodi.
  • Bootstrap: configura e avvia tutti i componenti in base alle loro specifiche.
  • Update: aggiorna le risorse per le versioni più recenti o le configurazioni aggiornate.
  • Status: ottieni lo stato di tutti i componenti o servizi nel cluster.
  • Delete: elimina le risorse del cluster.

Gli orchestratori accettano un insieme di specifiche come input in formato YAML.

  • Specifica del deployment: corrisponde al formato dell'inventario Ansible che definisce la topologia del cluster di VM. Contiene vari gruppi di VM, ad esempio i seguenti, insieme alle relative configurazioni.
    • primary_instance_nodes: nodi dedicati ai server di database AlloyDB Omni.
    • cluster_manager_nodes: (Facoltativo) Nodi che eseguono i server del gestore del cluster AlloyDB Omni. Se non esistono nodi di gestione dei cluster dedicati, puoi fare il deployment del gestore dei cluster su primary_instance_nodes.
    • etcd_nodes: il gestore dei cluster archivia i metadati su etcd. etcd può essere eseguito sugli stessi nodi dei nodi del gestore dei cluster se non specificato esplicitamente.
    • load_balancer_nodes: (Facoltativo) Nodi aggiuntivi dedicati a un bilanciatore del carico basato su HAProxy in un deployment HA scalabile. Se omesso, keepalived e PgBouncer vengono eseguiti direttamente sui nodi del gruppo primary_instance_nodes in un deployment ad alta affidabilità resiliente.
  • Specifica delle risorse: un cluster è costituito da una o più risorse del cluster di cui eseguire il deployment e la gestione, ad esempio cluster di database e pool di connessioni. La specifica della risorsa è in formato YAML e descrive le risorse di cui eseguire il deployment nel cluster.

Limitazioni

  • La versione di anteprima supporta solo quanto segue:
    • AlloyDB Omni PostgreSQL 18
    • Pacchetti software compatibili con RHEL versione 9
    • Piattaforma Intel x86 a 64 bit
  • Gli upgrade della versione principale non sono supportati.
  • Le istruzioni per configurare le istanze di ripristino di emergenza e del pool di lettura non sono incluse.
  • Il monitoraggio di AlloyDB Omni non supporta le connessioni SSL. Devi eseguire il deployment dei server della dashboard di monitoraggio sulla stessa rete privata dei nodi AlloyDB Omni.
  • AlloyDB Omni supporta SELinux sia in modalità permissiva che in modalità di applicazione forzata. Devi configurare la modalità SELinux selezionata prima di bootstrap del cluster. Il passaggio alla modalità di applicazione forzata dopo il bootstrapping non è supportato.

Passaggi successivi