Molti sono familiarità con il DBMS PostgreSQL, e ha dimostrato di essere eccellente in piccole installazioni. Tuttavia, la tendenza al passaggio a soluzioni Open Source è diventata sempre più evidente, anche quando si parla di grandi aziende e requisiti enterprise. In questo articolo, parleremo di come integrare Postgres in un ambiente aziendale e condivideremo l'esperienza di creare un sistema di backup (SRK) per questo database utilizzando come esempio il sistema di backup Commvault.
PostgreSQL ha già dimostrato la propria efficacia: il DBMS funziona perfettamente, è utilizzato da aziende digitali alla moda come Alibaba e TripAdvisor, e l'assenza di costi di licenza la rende un'alternativa attraente a giganti come MS SQL o Oracle DB. Ma non appena iniziamo a considerare PostgreSQL nel contesto enterprise, ci troviamo subito di fronte a requisiti rigidi: «E la resilienza della configurazione? La resilienza ai disastri? Dove sono il monitoraggio completo? E il backup automatico? E l'uso di librerie a nastro sia per il salvataggio diretto che per il secondo spazio di archiviazione?»
Da un lato, PostgreSQL non ha strumenti di backup integrati come i "grandi" DBMS come RMAN di Oracle DB o SAP Database Backup. Dall'altro, i fornitori di sistemi di backup aziendali (Veeam, Veritas, Commvault) supportano anche PostgreSQL, ma in realtà lavorano solo con configurazioni specifiche (di solito standalone) e con una serie di limitazioni.
Sistemi di backup progettati specificamente per PostgreSQL, come Barman, Wal-g, pg_probackup, sono estremamente popolari in piccole installazioni del DBMS PostgreSQL o dove non sono necessari pesanti backup di altri elementi del panorama IT. Ad esempio, oltre a PostgreSQL, l'infrastruttura può includere fisici e virtuali servers, OpenShift, Oracle, MariaDB, Cassandra, ecc. È preferibile eseguire il backup di tutto con uno strumento comune. Implementare una soluzione separata esclusivamente per PostgreSQL è una cattiva idea: i dati verranno copiati su un disco e poi dovranno essere trasferiti su nastro. Questa duplicazione del backup aumenta i tempi di backup e, cosa più critica, di ripristino.
Nella soluzione enterprise, il backup dell'installazione avviene con un certo numero di nodi di un cluster dedicato. Ad esempio, Commvault può lavorare solo con un cluster a due nodi, in cui il Primary e il Secondary sono rigidamente assegnati a nodi specifici. Inoltre, ha senso fare il backup solo dal Primary, poiché il backup dal Secondary ha le sue limitazioni. A causa delle peculiarità del DBMS, il dump non viene creato sul Secondary, quindi rimane solo la possibilità del backup file-based.
Per ridurre i rischi di inattività, durante la creazione di un sistema fault-tolerant viene generata una configurazione di cluster "live", e il Primary può migrare gradualmente tra diversi server. Ad esempio, il software Patroni avvia automaticamente il Primary su un nodo scelto casualmente del cluster. Il SRK non ha modi per monitorare questo "out of the box", e quindi, se la configurazione cambia, i processi si rompono. In altre parole, l'implementazione di una gestione esterna ostacola l'efficacia del SRK, poiché il server di gestione non comprende semplicemente da dove e quali dati debbano essere copiati.
Un altro problema è l'implementazione del backup in Postgres. È possibile tramite dump, e su piccole basi funziona. Ma con grandi DB, il dump richiede molto tempo, consuma molte risorse e può portare a un'interruzione dell'istanza del DB.
Il backup file-based migliora la situazione, ma su grandi basi avviene lentamente, poiché funziona in modalità singolo-thread. Inoltre, i fornitori impongono una serie di ulteriori limitazioni. Ad esempio, non è possibile utilizzare contemporaneamente il backup file-based e il backup tramite dump, oppure la deduplicazione non è supportata. Ci sono molti problemi, e spesso è più semplice scegliere un DBMS costoso ma collaudato piuttosto che Postgres.
Non c'è tempo per indietreggiare! I programmatori di Mosca sono dietro di noi!
Tuttavia, recentemente il nostro team si è trovato di fronte a una sfida non facile: nel progetto di creazione dell'AIS OSAGO 2.0, dove abbiamo realizzato l'infrastruttura IT, gli sviluppatori della nuova sistema hanno scelto PostgreSQL.
Per i grandi sviluppatori di software è molto più semplice utilizzare soluzioni open-source "alla moda". Nel staff di Facebook ci sono abbastanza specialisti che supportano il funzionamento di questo DBMS. Nel caso del RCA, tutte le attività del "giorno due" ricadevano sulle nostre spalle. Da noi ci si aspettava di garantire la fault-tolerance, di assemblare un cluster e, naturalmente, di organizzare il backup. La logica delle azioni era questa:
- Insegnare a SRK a fare il backup dalla nodo principale 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 ai requisiti di ripristino. Ad esempio, quando è necessario ripristinare le pagine in modo granulare, utilizzare un dump, mentre se i database sono grandi e non è necessario un ripristino granulare — lavorare a livello di file.
- Aggiungere al sistema la possibilità di backup a blocchi, per creare copie di sicurezza in modalità multi-thread.
Inizialmente, ci eravamo prefissi di creare un sistema efficiente e semplice senza l'ingombrante contorno di componenti aggiuntivi. Meno fronzoli ci sono, minore è il carico sul personale e inferiore è il rischio di malfunzionamento di SRK. Le soluzioni che coinvolgevano Veeam e RMAN sono state subito escluse, poiché il pacchetto di due soluzioni suggerisce già un'affidabilità limitata del sistema.
Un po' di magia per l'impresa
Pertanto, dovevamo garantire un backup affidabile per 10 cluster, ciascuno con 3 nodi, mentre nel centro dati di backup è presente un'infrastruttura identica. I centri dati in relazione a PostgreSQL operano secondo il principio active-passive. Il volume totale dei database era di 50 TB. Qualsiasi SRK di livello aziendale può gestirlo facilmente. Ma il punto è che inizialmente in Postgres non c'era nulla per una compatibilità completa e profonda con i sistemi di backup. Pertanto, abbiamo dovuto cercare una soluzione che avesse fin dall'inizio il massimo delle funzionalità in associazione con PostgreSQL e potenziare il sistema.
Abbiamo condotto 3 hackathon interni — abbiamo esaminato oltre cinquanta sviluppi, li abbiamo testati, apportato modifiche in base alle nostre ipotesi e controllato di nuovo. Dopo aver analizzato le opzioni disponibili, abbiamo scelto Commvault. Questo prodotto già "out of the box" poteva funzionare con una semplice installazione cluster di PostgreSQL, e la sua architettura aperta ha suscitato speranza (che si è rivelata fondata) per un'integrazione e un potenziamento di successo. Inoltre, Commvault è in grado di eseguire il backup dei log di PostgreSQL. Ad esempio, Veritas NetBackup, per quanto riguarda PostgreSQL, può effettuare solo backup completi.
Ulteriori informazioni sull'architettura. I server di gestione Commvault sono stati installati in ciascuno dei due data center in configurazione CommServ HA. Il sistema è speculare, gestito tramite un'unica console e, dal punto di vista dell'HA, soddisfa tutti i requisiti enterprise.
Inoltre, in ciascun data center abbiamo avviato due server media fisici, ai quali sono stati collegati tramite SAN su Fibre Channel array di dischi dedicati appositamente per i backup e biblioteche di nastri. I database di deduplicazione distribuiti hanno garantito la disponibilità dei media server, e il collegamento di ciascun server a ciascun CSV ha permesso un funzionamento continuo in caso di guasto di qualsiasi componente. L'architettura del sistema consente di continuare il backup, anche se uno dei data center dovesse andare giù.
Patroni determina la nodi Primary per ciascun cluster. Può essere qualsiasi nodo libero nel data center — ma solo nel principale. In quello di riserva tutti i nodi sono Secondari.
Affinché Commvault riconosca quale nodo del cluster sia Primary, abbiamo integrato il sistema (grazie all'architettura aperta della soluzione) con Postgres. È stato creato uno script che informa il gestore sulla posizione attuale del nodo Primary. server Commvault.
In generale, il processo è il seguente:
Patroni seleziona il Primary → Keepalived attiva l'IP del cluster e avvia lo script → l'agente Commvault sul nodo selezionato del cluster riceve una notifica che è il Primary → Commvault riconfigura automaticamente il backup all'interno del pseudocliente.
Il vantaggio di questo approccio è che la soluzione non influisce sulla coerenza, né sulla correttezza dei log, né sul ripristino dell'istanza Postgres. È anche facilmente scalabile, poiché ora non è necessario fissare per Commvault i nodi Primary e Secondary. È sufficiente che il sistema comprenda dove si trovi il Primary e il numero di nodi può essere aumentato praticamente a qualsiasi valore.
La soluzione non pretende di essere perfetta e presenta le proprie peculiarità. Commvault può effettuare il backup solo dell'istanza intera, non di singoli database. Pertanto, per ogni database è stata creata un'istanza separata. I clienti reali sono stati unificati in pseudoclienti virtuali. Ogni pseudocliente Commvault rappresenta un cluster UNIX. Vengono aggiunti i nodi del cluster sui quali è installato l'agente Commvault per Postgres. Di conseguenza, tutti i nodi virtuali del pseudocliente vengono sottoposti a backup come un'unica istanza.
All'interno di ogni pseudocliente è specificato un nodo attivo del cluster. È proprio quello che il nostro sistema di integrazione per Commvault determina. Il principio del suo funzionamento è piuttosto semplice: se sul nodo viene attivato un IP di cluster, lo script pone nel binario dell'agente Commvault il parametro "nodo attivo" — in pratica, lo script imposta "1" nella parte corretta della memoria. L'agente trasmette questi dati a CommServe, e Commvault effettua il backup dal nodo desiderato. Inoltre, a livello di script, viene verificata la correttezza della configurazione, aiutando a evitare errori durante l'avvio del backup.
A questo punto, i grandi database vengono sottoposti a backup a blocchi su più flussi, rispettando i requisiti RPO e la finestra di backup. Il carico sul sistema è minimo: i backup completi non avvengono così frequentemente e negli altri giorni vengono raccolti solo i log, durante i periodi di bassa attività.
Tra l'altro, abbiamo applicato politiche separate per il backup dei log archivio di PostgreSQL — questi vengono conservati secondo regole diverse, copiati secondo un programma diverso e per loro non è prevista la deduplicazione, poiché questi log contengono dati unici.
Per garantire la consistenza dell'intera infrastruttura IT, i singoli client di file Commvault sono installati su ciascuno dei nodi del cluster. Essi escludono dai backup i file Postgres e sono destinati solo al backup del sistema operativo e delle applicazioni. Anche per questa parte dei dati è prevista una propria politica e un proprio periodo di conservazione.
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 delle sfide enterprise.
I parametri RPO e RTO di 1 ora e 2 ore sono stati superati abbondantemente, il che significa che il sistema li soddisferà anche con un notevole aumento dei volumi di dati memorizzati. In controtendenza a molte opinioni scettiche, PostgreSQL e l'ambiente enterprise si sono rivelati perfettamente compatibili. E ora sappiamo per esperienza che il backup per tali DBMS è possibile in configurazioni molto diverse.
Certo, lungo questo percorso abbiamo dovuto consumare sette paia di stivali di ferro, superare diverse difficoltà, inciampare in alcuni ostacoli e correggere un certo numero di errori. Ma ora l'approccio è stato testato e può essere utilizzato per implementare Open Source al posto dei DBMS proprietari in condizioni enterprise difficili.
Hai mai provato a lavorare con PostgreSQL in un ambiente aziendale?
Autori:
Oleg Lavrenov, ingegnere progettista di sistemi di archiviazione dati di «Infossistemi Jet»
Dmitry Yerykin, ingegnere progettista di sistemi di calcolo di «Infossistemi Jet»
Fonte: habr.com
