Molte persone hanno familiarità con il DBMS PostgreSQL e si è dimostrato efficace in piccole installazioni. Tuttavia, la tendenza verso l’Open Source è diventata sempre più evidente, anche per quanto riguarda le grandi aziende e le esigenze aziendali. In questo articolo ti spiegheremo come integrare Postgres in un ambiente aziendale e condivideremo la nostra esperienza nella creazione di un sistema di backup (BSS) per questo database utilizzando come esempio il sistema di backup Commvault.
PostgreSQL ha già dimostrato il suo valore: il DBMS funziona alla grande, è utilizzato da aziende digitali alla moda come Alibaba e TripAdvisor e la mancanza di costi di licenza lo rende un'alternativa allettante a mostri come MS SQL o Oracle DB. Ma non appena iniziamo a pensare a PostgreSQL nel panorama aziendale, ci imbattiamo immediatamente in requisiti severi: “E la tolleranza agli errori di configurazione? resistenza ai disastri? dov'è il monitoraggio completo? E i backup automatici? Che ne dici di utilizzare le librerie di nastri sia direttamente che su storage secondario?"
Da un lato, PostgreSQL non dispone di strumenti di backup integrati, come i DBMS “adulti” come RMAN in Oracle DB o SAP Database Backup. D'altra parte, i fornitori di sistemi di backup aziendali (Veeam, Veritas, Commvault), sebbene supportino PostgreSQL, di fatto funzionano solo con una determinata configurazione (solitamente standalone) e con una serie di varie restrizioni.
I sistemi di backup appositamente progettati per PostgreSQL, come Barman, Wal-g, pg_probackup, sono estremamente popolari nelle piccole installazioni del DBMS PostgreSQL o dove non sono necessari backup pesanti di altri elementi del panorama IT. Ad esempio, oltre a PostgreSQL, l'infrastruttura può includere server fisici e virtuali, OpenShift, Oracle, MariaDB, Cassandra, ecc. È consigliabile supportare tutto questo con uno strumento comune. Installare una soluzione separata esclusivamente per PostgreSQL è una cattiva idea: i dati verranno copiati da qualche parte sul disco e quindi dovranno essere rimossi su nastro. Questo doppio backup aumenta il tempo di backup e anche, cosa più critica, il tempo di ripristino.
In una soluzione enterprise il backup dell'installazione avviene con un certo numero di nodi in un cluster dedicato. Allo stesso tempo, ad esempio, Commvault può funzionare solo con un cluster a due nodi, in cui Primario e Secondario sono strettamente assegnati a determinati nodi. Ed ha senso eseguire il backup solo dal Primario, perché il backup dal Secondario ha i suoi limiti. Per le peculiarità del DBMS non viene creato un dump sul Secondario e quindi rimane solo la possibilità di un backup del file.
Per ridurre il rischio di tempi di inattività, quando si crea un sistema tollerante agli errori, viene creata una configurazione del cluster "live" e Primario può migrare gradualmente tra diversi server. Ad esempio, il software Patroni stesso avvia Primary su un nodo del cluster selezionato casualmente. L'IBS non ha modo di tracciarlo immediatamente e, se la configurazione cambia, i processi si interrompono. Cioè, l'introduzione del controllo esterno impedisce all'ISR di funzionare in modo efficace, perché il server di controllo semplicemente non capisce dove e da quali dati devono essere copiati.
Un altro problema è l'implementazione del backup in Postgres. È possibile tramite dump e funziona su database di piccole dimensioni. Ma nei database di grandi dimensioni, il dump richiede molto tempo, richiede molte risorse e può portare al fallimento dell'istanza del database.
Il backup dei file corregge la situazione, ma su database di grandi dimensioni è lento perché funziona in modalità a thread singolo. Inoltre, i fornitori hanno una serie di restrizioni aggiuntive. Non è possibile utilizzare i backup di file e dump contemporaneamente oppure la deduplicazione non è supportata. Ci sono molti problemi e molto spesso è più facile scegliere un DBMS costoso ma collaudato invece di Postgres.
Non c'è nessun posto dove ritirarsi! Gli sviluppatori di Mosca sono indietro!
Tuttavia, recentemente il nostro team ha dovuto affrontare una sfida difficile: nel progetto per la creazione di AIS OSAGO 2.0, in cui abbiamo creato l'infrastruttura IT, gli sviluppatori hanno scelto PostgreSQL per il nuovo sistema.
È molto più semplice per i grandi sviluppatori di software utilizzare soluzioni open source “alla moda”. Facebook ha abbastanza specialisti per supportare il funzionamento di questo DBMS. E nel caso della RSA tutti i compiti del “secondo giorno” sono ricaduti sulle nostre spalle. Dovevamo garantire la tolleranza agli errori, assemblare un cluster e, ovviamente, impostare il backup. La logica dell’azione era la seguente:
- Insegna all'SRK a eseguire i backup dal nodo primario del cluster. Per fare ciò, SRK deve trovarlo, il che significa che è necessaria l'integrazione con l'una o l'altra soluzione di gestione dei cluster PostgreSQL. Nel caso di RSA è stato utilizzato il software Patroni.
- Decidi il tipo di backup in base al volume dei dati e ai requisiti di ripristino. Ad esempio, quando è necessario ripristinare le pagine in modo granulare, utilizzare un dump e, se i database sono di grandi dimensioni e non è richiesto il ripristino granulare, lavorare a livello di file.
- Allega alla soluzione la possibilità di backup in blocco per creare una copia di backup in modalità multi-thread.
Allo stesso tempo, inizialmente abbiamo deciso di creare un sistema efficace e semplice senza un mostruoso cablaggio di componenti aggiuntivi. Meno stampelle, minore è il carico di lavoro del personale e minore è il rischio di fallimento dell’IBS. Abbiamo immediatamente escluso gli approcci che utilizzavano Veeam e RMAN, perché un insieme di due soluzioni suggerisce già l'inaffidabilità del sistema.
Una piccola magia per l'impresa
Avevamo quindi bisogno di garantire un backup affidabile per 10 cluster di 3 nodi ciascuno, con la stessa infrastruttura rispecchiata nel data center di backup. I data center in termini di PostgreSQL funzionano secondo il principio attivo-passivo. La dimensione totale del database era di 50 TB. Qualsiasi sistema di controllo a livello aziendale può facilmente far fronte a questo. Ma l'avvertenza è che inizialmente Postgres non ha la minima idea di una compatibilità completa e profonda con i sistemi di backup. Abbiamo quindi dovuto cercare una soluzione che inizialmente offrisse la massima funzionalità in combinazione con PostgreSQL e perfezionare il sistema.
Abbiamo organizzato 3 "hackathon" interni: abbiamo esaminato più di cinquanta sviluppi, li abbiamo testati, apportato modifiche in relazione alle nostre ipotesi e li abbiamo testati di nuovo. Dopo aver esaminato le opzioni disponibili, abbiamo scelto Commvault. Fuori dagli schemi, questo prodotto poteva funzionare con la più semplice installazione di cluster PostgreSQL e la sua architettura aperta suscitava speranze (giustificate) per uno sviluppo e un'integrazione di successo. Commvault può anche eseguire il backup dei log PostgreSQL. Ad esempio, Veritas NetBackup in termini di PostgreSQL può eseguire solo backup completi.
Ancora sull'architettura. I server di gestione Commvault sono stati installati in ciascuno dei due data center in una configurazione CommServ HA. Il sistema è in mirroring, gestito tramite un'unica console e, dal punto di vista HA, soddisfa tutti i requisiti aziendali.
Abbiamo inoltre lanciato due media server fisici in ciascun data center, ai quali abbiamo collegato array di dischi e librerie di nastri dedicati specificamente ai backup tramite SAN tramite Fibre Channel. I database di deduplicazione estesi garantivano la tolleranza agli errori dei server multimediali e la connessione di ciascun server a ciascun CSV consentiva il funzionamento continuo in caso di guasto di un componente. L'architettura del sistema consente di continuare il backup anche in caso di guasto di uno dei data center.
Patroni definisce un nodo Primario per ogni cluster. Può essere qualsiasi nodo libero nel data center, ma solo nella maggior parte dei casi. Nel backup, tutti i nodi sono secondari.
Affinché Commvault possa capire quale nodo del cluster è Primario, abbiamo integrato il sistema (grazie all'architettura aperta della soluzione) con Postgres. A questo scopo è stato creato uno script che segnala la posizione corrente del nodo Primario al server di gestione Commvault.
In generale, il processo è simile al seguente:
Patroni seleziona Primario → Keepalived preleva il cluster IP ed esegue lo script → l'agente Commvault sul nodo del cluster selezionato riceve una notifica che questo è il primario → Commvault riconfigura automaticamente il backup all'interno dello pseudo-client.
Il vantaggio di questo approccio è che la soluzione non influisce sulla coerenza, sulla correttezza dei log o sul ripristino dell'istanza Postgres. È anche facilmente scalabile, perché non è più necessario fissare i nodi Primari e Secondari di Commvault. È sufficiente che il sistema capisca dove si trova il Primario e il numero di nodi può essere aumentato a quasi qualsiasi valore.
La soluzione non pretende di essere ideale e ha le sue sfumature. Commvault può eseguire il backup solo dell'intera istanza e non dei singoli database. Pertanto, è stata creata un'istanza separata per ciascun database. I clienti reali vengono combinati in pseudo-clienti virtuali. Ogni pseudo-client Commvault è un cluster UNIX. Ad esso vengono aggiunti i nodi del cluster su cui è installato l'agente Commvault per Postgres. Di conseguenza, viene eseguito il backup di tutti i nodi virtuali dello pseudo-client come un'unica istanza.
All'interno di ogni pseudo-client è indicato il nodo attivo del cluster. Questo è ciò che definisce la nostra soluzione di integrazione per Commvault. Il principio del suo funzionamento è abbastanza semplice: se viene generato un IP del cluster su un nodo, lo script imposta il parametro "nodo attivo" nel binario dell'agente Commvault - infatti, lo script imposta "1" nella parte richiesta della memoria . L'agente trasmette questi dati a CommServe e Commvault esegue un backup dal nodo desiderato. Inoltre, la correttezza della configurazione viene verificata a livello di script, contribuendo ad evitare errori durante l'avvio di un backup.
Allo stesso tempo, i database di grandi dimensioni vengono sottoposti a backup in blocchi su più thread, soddisfacendo i requisiti RPO e finestra di backup. Il carico sul sistema è insignificante: le copie complete non vengono eseguite così spesso, negli altri giorni vengono raccolti solo i log e durante i periodi di basso carico.
A proposito, abbiamo applicato policy separate per il backup dei log di archivio PostgreSQL: sono archiviati secondo regole diverse, copiati secondo una pianificazione diversa e per loro la deduplicazione non è abilitata, poiché questi log contengono dati univoci.
Per garantire la coerenza nell'intera infrastruttura IT, su ciascuno dei nodi del cluster vengono installati client di file Commvault separati. Escludono i file Postgres dai backup e sono destinati solo ai backup del sistema operativo e delle applicazioni. Anche questa parte dei dati ha una propria policy e periodo di conservazione.
Attualmente, IBS non influisce sui servizi di produttività, ma se la situazione cambia, Commvault può abilitare la limitazione del carico.
È buono? Bene!
Pertanto, abbiamo ricevuto non solo un backup funzionante, ma anche completamente automatizzato per l'installazione di un cluster PostgreSQL e che soddisfa tutti i requisiti per le chiamate aziendali.
I parametri RPO e RTO di 1 ora e 2 ore sono coperti con un margine, il che significa che il sistema li rispetterà anche con un aumento significativo del volume dei dati memorizzati. Contrariamente a molti dubbi, PostgreSQL e l'ambiente aziendale si sono rivelati abbastanza compatibili. E ora sappiamo per esperienza personale che il backup di tali DBMS è possibile in un'ampia varietà di configurazioni.
Naturalmente, lungo questo percorso abbiamo dovuto consumare sette paia di stivali di ferro, superare una serie di difficoltà, calpestare diversi rastrelli e correggere una serie di errori. Ma ora l’approccio è già stato testato e può essere utilizzato per implementare Open Source invece di DBMS proprietari in condizioni aziendali difficili.
Hai provato a lavorare con PostgreSQL in un ambiente aziendale?
Autori:
Oleg Lavrenov, ingegnere progettista di sistemi di archiviazione dati, Jet Infosystems
Dmitry Erykin, ingegnere progettista di sistemi informatici presso Jet Infosystems
Fonte: habr.com