Molti conoscono il database PostgreSQL, che ha dimostrato di essere efficace in installazioni di piccole dimensioni. Tuttavia, la tendenza a passare all'Open Source è diventata sempre più evidente, anche per le grandi aziende e le esigenze enterprise. In questo articolo, parleremo di come integrare Postgres in un ambiente aziendale e condivideremo la nostra esperienza nella creazione di un sistema di backup (SRK) per questo database, utilizzando come esempio il sistema di backup Commvault.
PostgreSQL ha già dimostrato il suo valore: il database funziona bene, è utilizzato da aziende digitali rinomate come Alibaba e TripAdvisor, e l'assenza di costi di licenza lo rende un'alternativa attraente a giganti come MS SQL o Oracle DB. Tuttavia, quando iniziamo a considerare PostgreSQL nel contesto Enterprise, ci imbattiamo immediatamente in requisiti rigorosi: "Come gestiamo la resilienza della configurazione? La recovery da disastri? Dove si trova il monitoraggio completo? Il backup automatizzato? L'uso delle librerie a nastro sia direttamente che come storage secondario?"
Da un lato, PostgreSQL non ha strumenti di backup integrati come i database 'maturi' RMAN di Oracle DB o SAP Database Backup. Dall'altro, i fornitori di sistemi di backup aziendale (Veeam, Veritas, Commvault) supportano PostgreSQL, ma in realtà lavorano solo con configurazioni specifiche (di solito standalone) e con una serie di limitazioni.
Sistemi di backup appositamente progettati per PostgreSQL, come Barman, Wal-g, pg_probackup, sono estremamente popolari in installazioni di piccole dimensioni o dove non sono richiesti pesanti backup di altri elementi del panorama IT. Ad esempio, oltre a PostgreSQL, nell'infrastruttura possono esserci sistemi fisici e virtuali, OpenShift, Oracle, MariaDB, Cassandra, ecc. È preferibile eseguire backup con uno strumento comune. Utilizzare una soluzione separata esclusivamente per PostgreSQL è una cattiva idea: i dati verrebbero copiati su disco per poi essere trasferiti su nastro. Questa duplicazione del backup aumenta il tempo di backup e, cosa più critica, il tempo di ripristino. serverIn una soluzione enterprise, il backup dell'installazione avviene su un certo numero di nodi di un cluster dedicato. Tuttavia, ad esempio, Commvault funziona solo con un cluster a due nodi in cui Primary e Secondary sono rigidamente assegnati a nodi specifici. Ha senso effettuare il backup solo dal Primary, dato che il backup dal Secondary presenta le sue limitazioni. A causa delle caratteristiche del database, il dump non viene creato sul Secondary, quindi rimane solo l'opzione del backup a livello di file.
Per ridurre il rischio di inattività, nella creazione di un sistema di failover viene creata una configurazione cluster 'viva', e il Primary può migrare gradualmente tra diversi server. Ad esempio, il software Patroni avvia il Primary su un nodo randomizzato del cluster. Il SRK non ha modo di monitorare questo 'out-of-the-box', e se la configurazione cambia, i processi si rompono. Cioè, l'implementazione di una gestione esterna ostacola il corretto funzionamento del SRK, poiché il server di gestione non comprende quali dati copiare e da quale fonte.
Un'altra problematica riguarda la realizzazione del backup in Postgres. È possibile tramite dump, e per piccole basi funziona. Ma nelle grandi basi, il dump richiede tempo, molte risorse e può portare a un crash dell'istanza del database.
Il backup a livello di file migliora la situazione, ma sulle grandi basi è lento, poiché funziona in modalità single-threaded. Inoltre, i fornitori impongono una serie di limitazioni aggiuntive. Si può non utilizzare contemporaneamente il backup a livello di file e il backup a livello di dump, oppure non si supporta la deduplicazione. Ci sono molte problematiche, e spesso è più semplice scegliere un costoso ma collaudato DB rispetto a Postgres.
Non si può tornare indietro! Mosca è alle spalle della squadra di sviluppatori!
Tuttavia, recentemente il nostro team si è trovato di fronte a una sfida difficile: nel progetto di creazione del SIS OSAGO 2.0, dove abbiamo sviluppato l'infrastruttura IT, gli sviluppatori hanno scelto PostgreSQL per il nuovo sistema.
Per i grandi sviluppatori di software, utilizzare soluzioni open-source 'alla moda' è molto più semplice. Nel personale di Facebook ci sono abbastanza specialisti che mantengono il funzionamento di questo database. Nel caso dell'RSA, tutte le attività 'del secondo giorno' gravavano sulle nostre spalle. Ci è stato richiesto di garantire la resilienza, costruire un cluster e, naturalmente, impostare il backup. La logica delle azioni era la seguente:
Insegnare al SRK a effettuare il backup dalla nodo Primary del cluster. Per questo, il SRK deve trovarlo — quindi è necessaria un'integrazione con qualche soluzione di gestione del cluster PostgreSQL. Nel caso dell'RSA, è stato utilizzato il software Patroni.
- Insegnare a SRK come eseguire il backup dalla nodo primario del cluster. Per questo SRK deve essere in grado di trovarlo, quindi è necessaria un'integrazione con una delle soluzioni di gestione del cluster PostgreSQL. Nel caso di RSA, è stato utilizzato il software Patroni.
- Stabilire il tipo di backup in base ai volumi di dati e alle esigenze di ripristino. Ad esempio, quando è necessario ripristinare le pagine in modo granulare, utilizzare un dump; se i database sono grandi e non è necessario un ripristino granulare, lavorare a livello di file.
- Incorporare nella soluzione la possibilità di backup a livello di blocco, per creare backup in modalità multithreading.
Fin dall'inizio, il nostro obiettivo era creare un sistema efficiente e semplice, senza una complessa struttura di componenti aggiuntivi. Meno elementi superflui comportano una minore pressione sul personale e un rischio ridotto di malfunzionamento del sistema di backup. Abbiamo subito escluso approcci che utilizzavano Veeam e RMAN, poiché la combinazione di due soluzioni suggerisce già inaffidabilità del sistema.
Un po' di magia per l'enterprise
Quindi, dovevamo garantire un backup affidabile per 10 cluster ciascuno con 3 nodi, con un'infrastruttura speculare nel centro dati di backup. I centri dati, per quanto riguarda PostgreSQL, funzionano su un principio attivo-passivo. Il volume totale dei database ammontava a 50 TB. Qualunque sistema di backup di livello enterprise può gestirlo facilmente. Tuttavia, il problema è che inizialmente PostgreSQL non ha alcun appiglio per una compatibilità completa e profonda con i sistemi di backup. Pertanto, abbiamo dovuto cercare una soluzione che avesse il massimo delle funzionalità in combinazione con PostgreSQL e perfezionare il sistema.
Abbiamo condotto 3 hackathon interni: abbiamo esaminato più di cinquanta progetti, testandoli, apportando modifiche basate sulle nostre ipotesi, e verificando nuovamente. Dopo aver analizzato le opzioni disponibili, abbiamo scelto Commvault. Questo prodotto poteva già funzionare, ‘out of the box’, con una semplice installazione cluster di PostgreSQL, e la sua architettura aperta ci dava speranza (che è stata ripagata) per un'integrazione e un miglioramento di successo. Inoltre, Commvault è in grado di eseguire backup dei log di PostgreSQL. Ad esempio, Veritas NetBackup può effettuare solo backup completi per PostgreSQL.
Ulteriori dettagli sull'architettura. I server di gestione di Commvault sono stati installati in ciascuno dei due centri dati in configurazione CommServ HA. Il sistema è speculare, gestito tramite un'unica console e risponde a tutti i requisiti enterprise in termini di alta disponibilità.
Inoltre, in ciascun centro dati abbiamo avviato due server multimediali fisici, collegati tramite SAN via Fibre Channel a sistemi di archiviazione dedicati per i backup e librerie a nastro. Le basi deduplicate distribuite garantiscono resilienza ai server multimediali, mentre il collegamento di ciascun server a ciascun CSV consente un funzionamento continuo anche in caso di guasto di uno qualsiasi dei componenti. L'architettura del sistema permette di continuare i backup anche se uno dei centri dati va in panne.
Patroni determina il nodo Primario per ogni cluster. Può essere qualsiasi nodo libero nel centro dati — ma solo in quello principale. Negli ambienti di backup, tutti i nodi sono secondari.
Per consentire a Commvault di comprendere qual è il nodo Primario del cluster, abbiamo integrato il sistema (grazie all'architettura aperta della soluzione) con Postgres. A tale scopo, è stato creato uno script che informa il gestore della posizione attuale del nodo Primario. server Commvault.
In generale, il processo si svolge così:
Patroni sceglie il Primario → Keepalived attiva l'IP del cluster e avvia lo script → l'agente Commvault sul nodo selezionato del cluster riceve la notifica che è il Primario → Commvault ri-configura automaticamente il backup nell'ambito del pseudo-client.
Il vantaggio di questo approccio è che la soluzione non influisce né sulla coerenza né sulla correttezza dei log, né sul ripristino dell'istanza di Postgres. È anche facilmente scalabile, poiché non è più necessario fissare i nodi Primari e Secondari per Commvault. È sufficiente che il sistema capisca dove si trova il Primario, e il numero di nodi può essere aumentato praticamente a qualsiasi valore.
La soluzione non si pretende perfetta e presenta alcune peculiarità. Commvault è in grado di eseguire il backup solo dell'intera istanza, non di singoli database. Pertanto, per ogni database è stato creato un'istanza separata. I clienti reali sono stati uniti in pseudo-client virtuali. Ogni pseudo-client di Commvault rappresenta un cluster UNIX. In esso vengono aggiunti i nodi del cluster sui quali è installato l'agente Commvault per Postgres. Di conseguenza, tutte le nodi virtuali del pseudo-client vengono sottoposte a backup come un'unica istanza.
All'interno di ogni pseudo-cliente è indicato il nodo attivo del cluster. Questo è precisamente ciò che la nostra soluzione di integrazione definisce per Commvault. Il funzionamento è piuttosto semplice: se su un nodo viene attivato un IP di cluster, lo script imposta nel binario dell'agente Commvault il parametro "nodo attivo" — in effetti, lo script inserisce "1" nella parte corretta della memoria. L'agente trasferisce questi dati a CommServe, e Commvault esegue il backup dal nodo corretto. Inoltre, a livello di script, viene verificata la correttezza della configurazione, aiutando a evitare errori durante l'avvio del backup.
In questo modo, grandi database vengono eseguiti in backup a blocchi tramite più thread, soddisfacendo i requisiti RPO e le finestre di backup. Il carico sul sistema è minimo: i backup completi non avvengono molto spesso, nei giorni restanti vengono raccolti solo i log, e questo durante i periodi di bassa richiesta.
A proposito, abbiamo applicato politiche specifiche per il backup dei log archivi di PostgreSQL — questi vengono conservati secondo regole diverse, copiati a orari differenti e non viene attivata la deduplica, poiché questi log contengono dati unici.
Per garantire la coerenza dell'intera infrastruttura IT, client di file Commvault sono installati su ciascun nodo del cluster. Essi escludono dai backup i file Postgres e sono dedicati esclusivamente al backup del sistema operativo e delle applicazioni. Anche per questa parte dei dati è prevista una politica e un periodo di conservazione specifici.
Attualmente, il SRK non influisce sui servizi produttivi, ma se la situazione dovesse cambiare, in Commvault sarà possibile attivare un sistema di limitazione del carico.
Va bene? Va bene!
Quindi, abbiamo ottenuto non solo un backup funzionante, ma anche completamente automatizzato per l'installazione cluster di PostgreSQL, che soddisfa tutte le esigenze dell'impresa.
I parametri RPO e RTO di 1 ora e 2 ore sono ampiamente soddisfatti, il che significa che il sistema continuerà a rispettarli anche con un significativo aumento dei dati memorizzati. Contrariamente a molte preoccupazioni, PostgreSQL e ambiente enterprise si sono rivelati perfettamente compatibili. E ora sappiamo per esperienza che il backup per database di questo tipo è possibile in molte configurazioni diverse.
Certo, lungo questo percorso abbiamo dovuto consumare sette paia di stivali di ferro, affrontare una serie di difficoltà, calpestare alcuni rastrelli e correggere un certo numero di errori. Ma ora il metodo è stato testato e può essere applicato per implementare Open Source al posto di database proprietari in condizioni aziendali difficili.
Hai mai provato a lavorare con PostgreSQL in un ambiente aziendale?
Autori:
Oleg Lavrenov, ingegnere progettista di sistemi di archiviazione dati "Infossistemi Jet"
Dmitry Yerikin, ingegnere progettista di complessi elaborativi "Infossistemi Jet"
Fonte: habr.com
