Parechje persone sò familiarizati cù u DBMS PostgreSQL, è hà pruvatu in picculi installazioni. Tuttavia, a tendenza versu l'Open Source hè diventata sempre più chjaru, ancu quandu si tratta di grandi imprese è esigenze di l'impresa. In questu articulu vi diceremu cumu integrà Postgres in un ambiente corporativu è sparte a nostra sperienza di creà un sistema di salvezza (BSS) per questa basa di dati utilizendu u sistema di salvezza Commvault cum'è un esempiu.
PostgreSQL hà digià dimustratu u so valore - u DBMS funziona bè, hè utilizatu da imprese digitale di moda cum'è Alibaba è TripAdvisor, è a mancanza di tariffi di licenze face una alternativa tentativa à mostri cum'è MS SQL o Oracle DB. Ma appena avemu principiatu à pensà à PostgreSQL in u paisaghju di l'Intraprisazione, avemu subitu subitu in esigenze strette: "Chì ne dici di a tolleranza di errore di cunfigurazione? resistenza à i disastri? induve hè u monitoraghju cumpletu? E i backups automatizati? Chì ne dite di l'usu di biblioteche di nastri sia direttamente sia in u almacenamentu secundariu?"
Da una banda, PostgreSQL ùn hà micca strumenti di salvezza integrati, cum'è DBMS "adulti" cum'è RMAN in Oracle DB o SAP Database Backup. Per d 'altra banda, i fornitori di sistemi di salvezza corporativa (Veeam, Veritas, Commvault) ancu s'elli supportanu PostgreSQL, in fattu, travaglianu solu cù una certa cunfigurazione (di solitu standalone) è cù un inseme di diverse restrizioni.
Sistemi di salvezza apposta per PostgreSQL, cum'è Barman, Wal-g, pg_probackup, sò estremamente populari in picculi installazioni di u DBMS PostgreSQL o induve ùn sò micca necessarii backups pesanti di altri elementi di u paisaghju IT. Per esempiu, in più di PostgreSQL, l'infrastruttura pò include servitori fisici è virtuali, OpenShift, Oracle, MariaDB, Cassandra, etc. Hè cunsigliatu di fà una copia di salvezza di tuttu questu cù un strumentu cumuni. L'installazione di una soluzione separata solu per PostgreSQL hè una mala idea: i dati seranu copiati in un locu à u discu, è dopu deve esse eliminati à a cinta. Questa doppia copia di salvezza aumenta u tempu di salvezza, è ancu, più criticu, u tempu di ricuperazione.
In una suluzione di l'impresa, a copia di salvezza di a stallazione si faci cù un certu numaru di nodi in un cluster dedicatu. À u listessu tempu, per esempiu, Commvault pò travaglià solu cù un cluster di dui nodi, in quale Primariu è Secundariu sò strettamente assignati à certi nodi. È hè solu sensu per a copia di salvezza da Primary, perchè a copia di salvezza da Secundaria hà e so limitazioni. A causa di e peculiarità di u DBMS, un dump ùn hè micca creatu nantu à u Sicundariu, è per quessa solu a pussibilità di una copia di salvezza di u schedariu resta.
Per riduce u risicu di downtime, quandu crea un sistema tolerante à i difetti, una cunfigurazione di cluster "live" hè creata, è Primary pò migrate gradualmente trà i diversi servitori. Per esempiu, u software Patroni stessu lancia Primary nantu à un node di cluster sceltu aleatoriamente. L'IBS ùn hà micca manera di seguità questu fora di a scatula, è se a cunfigurazione cambia, i prucessi si rompenu. Questu hè, l'intruduzioni di u cuntrollu esternu impedisce à l'ISR di travaglià in modu efficace, perchè u servitore di cuntrollu ùn capisce micca da induve è quale dati deve esse copiatu.
Un altru prublema hè l'implementazione di copia di salvezza in Postgres. Hè pussibule à traversu dump, è travaglia nantu à basa di dati chjuchi. Ma in una grande basa di dati, u dump dura assai tempu, esige assai risorse è pò purtà à u fallimentu di l'istanza di basa di dati.
A copia di salvezza di l'archivi curregge a situazione, ma nantu à e grande basa di dati hè lentu perchè travaglia in modu unicu filatu. Inoltre, i venditori anu una quantità di restrizioni supplementari. O ùn pudete micca aduprà e copie di salvezza di file è dump à u stessu tempu, o a deduplicazione ùn hè micca supportata. Ci sò parechji prublemi, è più spessu hè più faciule di sceglie un DBMS caru ma pruvucatu invece di Postgres.
Ùn ci hè nudda parte per ritruvà ! I sviluppatori di Mosca sò daretu!
Tuttavia, recentemente a nostra squadra hà affruntatu una sfida difficiule: in u prughjettu di creà AIS OSAGO 2.0, induve avemu creatu l'infrastruttura IT, i sviluppatori anu sceltu PostgreSQL per u novu sistema.
Hè assai più faciule per i grandi sviluppatori di software per utilizà soluzioni open-source "di moda". Facebook hà abbastanza specialisti per sustene l'operazione di stu DBMS. È in u casu di RSA, tutti i travaglii di u "secunnu ghjornu" cascò nantu à e nostre spalle. Eramu stati richiesti per assicurà a tolleranza di difetti, assemble un cluster è, sicuru, stabilisce una copia di salvezza. A logica di l'azzione era a siguenti:
- Insegne à l'SRK per fà backups da u node Primariu di u cluster. Per fà questu, u SRK deve truvà - chì significa chì l'integrazione cù una o una altra soluzione di gestione di cluster PostgreSQL hè necessaria. In u casu di RSA, u software Patroni hè stata utilizata per questu.
- Decide u tipu di salvezza basatu nantu à u voluminu di dati è esigenze ripresa. Per esempiu, quandu avete bisognu di restaurà e pagine granularly, utilizate un dump, è se e basa di dati sò grande è a restaurazione granulare ùn hè micca necessariu, travaglià à u livellu di u schedariu.
- Attach a pussibilità di bluccà copia di salvezza à a suluzione per creà una copia di salvezza in modu multi-threaded.
À u listessu tempu, avemu principiatu per creà un sistema efficace è simplice senza un arnesi monstruosu di cumpunenti supplementari. U menu crutches, u menu travagliu di u persunale è u risicu di fallimentu IBS. Avemu immediatamente escluditu approcci chì anu utilizatu Veeam è RMAN, perchè un inseme di duie suluzioni indica digià l'inaffidabilità di u sistema.
Un pocu di magia per l'impresa
Dunque, avemu bisognu di guarantisci una copia di salvezza affidabile per 10 clusters di 3 nodi ognunu, cù a listessa infrastruttura riflessa in u centru di dati di salvezza. I centri di dati in termini di PostgreSQL travaglianu nantu à u principiu attivu-passivu. A dimensione totale di a basa di dati era 50 TB. Ogni sistema di cuntrollu di u livellu corporativu pò facilmente affruntà questu. Ma l'avvertimentu hè chì inizialmente Postgres ùn hà micca idea di cumpatibilità cumpleta è prufonda cù i sistemi di salvezza. Dunque, avemu avutu à circà una suluzione chì inizialmente hà avutu a funziunalità massima in cunghjunzione cù PostgreSQL, è raffinà u sistema.
Avemu tenutu 3 "hackathons" interni - avemu guardatu più di cinquanta sviluppi, pruvati, fatti cambiamenti in cunnessione cù e nostre ipotesi, è pruvati di novu. Dopu avè rivisatu l'opzioni dispunibili, avemu sceltu Commvault. Fora di a scatula, stu pruduttu puderia travaglià cù l'installazione di cluster PostgreSQL più simplice, è a so architettura aperta hà risuscitatu speranze (chì eranu ghjustificate) per u sviluppu è l'integrazione successu. Commvault pò ancu fà una copia di salvezza di i log PostgreSQL. Per esempiu, Veritas NetBackup in termini di PostgreSQL pò solu fà una copia di salvezza completa.
Più nantu à l'architettura. I servitori di gestione Commvault sò stati installati in ognunu di i dui centri di dati in una cunfigurazione CommServ HA. U sistema hè spechju, gestitu attraversu una cunsola è, da u puntu di vista HA, risponde à tutti i requisiti di l'impresa.
Avemu ancu lanciatu dui servitori di media fisici in ogni centru di dati, à quale avemu cunnessu arrays di discu è biblioteche di cinta dedicate specificamente per backup via SAN via Fibre Channel. A basa di dati di deduplicazione estesa hà assicuratu a tolleranza à i difetti di i servitori media, è a cunnessione di ogni servitore à ogni CSV hà permessu un funziunamentu cuntinuu se un cumpunente falliu. L'architettura di u sistema permette a salvezza di cuntinuà ancu s'ellu unu di i centri di dati casca.
Patroni definisce un node Primariu per ogni cluster. Pò esse qualsiasi node liberu in u centru di dati - ma solu a maiò parte. In a copia di salvezza, tutti i nodi sò Sicundarii.
Per chì Commvault capisce quale node di cluster hè Primariu, avemu integratu u sistema (grazie à l'architettura aperta di a suluzione) cù Postgres. Per questu scopu, hè statu creatu un script chì informa a situazione attuale di u node Primariu à u servitore di gestione Commvault.
In generale, u prucessu si vede cusì:
Patroni selezziunate Primariu → Keepalived piglia u cluster IP è eseguisce u script → l'agente Commvault nantu à u node di cluster selezziunatu riceve una notificazione chì questu hè u Primariu → Commvault reconfigura automaticamente a copia di salvezza in u pseudo-cliente.
U vantaghju di questu approcciu hè chì a suluzione ùn affetta micca a coherenza, a correzione di i logs, o a ricuperazione di l'istanza di Postgres. Hè ancu facilmente scalabile, perchè ùn hè più necessariu di riparà i nodi primari è secundari di Commvault. Hè abbastanza chì u sistema capisce induve Primary hè, è u numaru di nodi pò esse aumentatu à quasi ogni valore.
A suluzione ùn pretende micca esse ideale è hà i so sfumaturi. Commvault pò solu fà una copia di salvezza di l'istanza sana, è micca e basa di dati individuali. Dunque, hè stata creata una istanza separata per ogni basa di dati. I clienti reali sò cumminati in pseudo-clienti virtuali. Ogni pseudo-cliente Commvault hè un cluster UNIX. Quelli nodi di cluster nantu à quale l'agente Commvault per Postgres hè stallatu sò aghjuntu à questu. In u risultatu, tutti i nodi virtuali di u pseudo-cliente sò salvati cum'è una sola istanza.
In ogni pseudo-cliente, u node attivu di u cluster hè indicatu. Questu hè ciò chì a nostra suluzione d'integrazione per Commvault definisce. U principiu di u so funziunamentu hè abbastanza simplice: se un cluster IP hè risuscitatu nantu à un node, u script stabilisce u paràmetru "node attivu" in u binariu di l'agente Commvault - in fattu, u script stabilisce "1" in a parte necessaria di a memoria. . L'agente trasmette queste dati à CommServe, è Commvault face una copia di salvezza da u node desideratu. Inoltre, a correctezza di a cunfigurazione hè verificata à u nivellu di script, aiutendu à evità l'errore quandu principia una copia di salvezza.
À u listessu tempu, e grande basa di dati sò salvate in blocchi in parechje fili, rispondendu à i requisiti RPO è di a finestra di salvezza. A carica nantu à u sistema hè insignificante: e copie piene ùn sò micca cusì spessu, in l'altri ghjorni sò culligati solu logs, è durante i periodi di carica bassa.
A propositu, avemu applicatu pulitiche separati per a copia di salvezza di i logs di l'archiviu PostgreSQL - sò stati guardati secondu diverse regule, copiati secondu un schedariu sfarente, è a deduplicazione ùn hè micca attivata per elli, postu chì sti logs cuntenenu dati unichi.
Per assicurà a coerenza in tutta l'infrastruttura IT, i clienti di file Commvault separati sò installati in ognuna di i nodi di cluster. Escludenu i fugliali Postgres da e copie di salvezza è sò destinati solu per i backups di l'OS è l'applicazioni. Sta parte di e dati hà ancu a so propria pulitica è u periodu di almacenamiento.
Attualmente, IBS ùn affetta micca i servizii di produtividade, ma se a situazione cambia, Commvault pò attivà a limitazione di carica.
Hè bonu? Bene!
Dunque, avemu ricevutu micca solu una copia di salvezza funzionale, ma ancu una copia di salvezza cumpletamente automatizata per una stallazione di cluster PostgreSQL, è risponde à tutti i requisiti per e chjama di l'impresa.
I paràmetri RPO è RTO di l'ora 1 è l'ora di 2 sò cuparti cù un marghjenu, chì significa chì u sistema cumpiarà cun elli ancu cù un incrementu significativu in u voluminu di dati almacenati. A cuntrariu di parechji dubbiti, PostgreSQL è l'ambiente di l'impresa sò diventati abbastanza cumpatibili. È avà sapemu da a nostra sperienza chì a copia di salvezza per tali DBMS hè pussibule in una larga varietà di cunfigurazioni.
Di sicuru, in sta strada, avemu avutu a purtari sette pariglii di stivali di ferru, superà una quantità di difficultà, mette nantu à parechji razzii è corregge una quantità di sbagli. Ma avà l'approcciu hè digià statu pruvatu è pò esse usatu per implementà Open Source invece di DBMS proprietariu in cundizioni d'impresa duru.
Avete pruvatu à travaglià cù PostgreSQL in un ambiente corporativu?
Autori:
Oleg Lavrenov, ingegnere di cuncepimentu di sistemi di almacenamiento di dati, Jet Infosystems
Dmitry Erykin, ingegnere di cuncepimentu di sistemi di computer in Jet Infosystems
Source: www.habr.com