Molta gent està familiaritzada amb el SGBD PostgreSQL i s'ha demostrat en petites instal·lacions. Tanmateix, la tendència cap al codi obert s'ha fet cada cop més clara, fins i tot quan es tracta de grans empreses i requisits empresarials. En aquest article us explicarem com integrar Postgres en un entorn corporatiu i compartirem la nostra experiència de crear un sistema de còpia de seguretat (BSS) per a aquesta base de dades utilitzant el sistema de còpia de seguretat Commvault com a exemple.
PostgreSQL ja ha demostrat la seva vàlua: el DBMS funciona molt bé, és utilitzat per empreses digitals de moda com Alibaba i TripAdvisor, i la manca de tarifes de llicència el converteix en una alternativa temptadora a monstres com MS SQL o Oracle DB. Però tan bon punt comencem a pensar en PostgreSQL al panorama empresarial, immediatament ens trobem amb requisits estrictes: "Què passa amb la tolerància a errors de configuració? resistència als desastres? on és el seguiment integral? Què passa amb les còpies de seguretat automàtiques? Què passa amb l'ús de biblioteques de cintes tant directament com a l'emmagatzematge secundari?"
D'una banda, PostgreSQL no té eines de còpia de seguretat integrades, com ara SGBD "adults" com RMAN a Oracle DB o SAP Database Backup. D'altra banda, els proveïdors de sistemes de còpia de seguretat corporatius (Veeam, Veritas, Commvault) encara que admeten PostgreSQL, de fet només funcionen amb una determinada configuració (normalment autònoma) i amb un conjunt de restriccions diverses.
Els sistemes de còpia de seguretat dissenyats especialment per a PostgreSQL, com ara Barman, Wal-g, pg_probackup, són extremadament populars en petites instal·lacions del SGBD PostgreSQL o on no es necessiten còpies de seguretat pesades d'altres elements del panorama informàtic. Per exemple, a més de PostgreSQL, la infraestructura pot incloure servidors físics i virtuals, OpenShift, Oracle, MariaDB, Cassandra, etc. És recomanable fer una còpia de seguretat de tot això amb una eina comuna. Instal·lar una solució separada exclusivament per a PostgreSQL és una mala idea: les dades es copiaran en algun lloc al disc i després s'han d'eliminar a la cinta. Aquesta doble còpia de seguretat augmenta el temps de còpia de seguretat, i també, de manera més crítica, el temps de recuperació.
En una solució empresarial, la còpia de seguretat de la instal·lació es produeix amb un nombre determinat de nodes en un clúster dedicat. Al mateix temps, per exemple, Commvault només pot funcionar amb un clúster de dos nodes, en el qual Primary i Secondary estan estrictament assignats a determinats nodes. I només té sentit fer una còpia de seguretat des de Primària, perquè la còpia de seguretat des de Secundària té les seves limitacions. A causa de les peculiaritats del SGBD, no es crea un bolcat a Secundària i, per tant, només queda la possibilitat de fer una còpia de seguretat de fitxers.
Per reduir el risc d'inactivitat, quan es crea un sistema tolerant a errors, es crea una configuració de clúster "en directe" i Primary pot migrar gradualment entre diferents servidors. Per exemple, el propi programari Patroni llança Primary en un node de clúster seleccionat aleatòriament. L'IBS no té cap manera de fer un seguiment d'això fora de la caixa i, si la configuració canvia, els processos es trenquen. És a dir, la introducció del control extern impedeix que l'ISR funcioni amb eficàcia, perquè el servidor de control simplement no entén d'on i quines dades s'han de copiar.
Un altre problema és la implementació de còpies de seguretat a Postgres. És possible mitjançant l'abocament i funciona amb bases de dades petites. Però a les bases de dades grans, l'abocament triga molt de temps, requereix molts recursos i pot provocar la fallada de la instància de la base de dades.
La còpia de seguretat de fitxers corregeix la situació, però en bases de dades grans és lenta perquè funciona en mode d'un sol fil. A més, els venedors tenen una sèrie de restriccions addicionals. O no podeu utilitzar còpies de seguretat de fitxers i abocaments al mateix temps, o no s'admet la deduplicació. Hi ha molts problemes, i la majoria de vegades és més fàcil triar un SGBD car però provat en lloc de Postgres.
No hi ha on retirar-se! Els desenvolupadors de Moscou estan enrere!
Tanmateix, recentment el nostre equip es va enfrontar a un repte difícil: en el projecte de creació d'AIS OSAGO 2.0, on vam crear la infraestructura informàtica, els desenvolupadors van triar PostgreSQL per al nou sistema.
És molt més fàcil per als grans desenvolupadors de programari utilitzar solucions de codi obert "de moda". Facebook té prou especialistes per donar suport al funcionament d'aquest SGBD. I en el cas de RSA, totes les tasques del "segon dia" van recaure sobre les nostres espatlles. Se'ns va obligar a garantir la tolerància a errors, muntar un clúster i, per descomptat, configurar una còpia de seguretat. La lògica d'actuació era la següent:
- Ensenyeu l'SRK a fer còpies de seguretat des del node principal del clúster. Per fer-ho, l'SRK l'ha de trobar, la qual cosa significa que es necessita la integració amb una o una altra solució de gestió de clúster PostgreSQL. En el cas de RSA, per a això es va utilitzar el programari Patroni.
- Decidiu el tipus de còpia de seguretat en funció del volum de dades i dels requisits de recuperació. Per exemple, quan necessiteu restaurar pàgines de manera granular, utilitzeu un abocament i, si les bases de dades són grans i no cal una restauració granular, treballeu a nivell de fitxer.
- Adjunteu la possibilitat de còpia de seguretat de bloqueig a la solució per crear una còpia de seguretat en mode multiprocés.
Al mateix temps, inicialment ens vam proposar crear un sistema eficaç i senzill sense un arnès monstruós de components addicionals. Com menys crosses, menys càrrega de treball del personal i menor risc de fracàs de l'IBS. Immediatament vam excloure els enfocaments que utilitzaven Veeam i RMAN, perquè un conjunt de dues solucions ja deixa entreveure la falta de fiabilitat del sistema.
Una mica de màgia per a l'empresa
Per tant, havíem de garantir una còpia de seguretat fiable per a 10 clústers de 3 nodes cadascun, amb la mateixa infraestructura reflectida al centre de dades de còpia de seguretat. Els centres de dades en termes de PostgreSQL funcionen segons el principi actiu-passiu. La mida total de la base de dades era de 50 TB. Qualsevol sistema de control a nivell corporatiu pot fer front a això fàcilment. Però l'advertència és que inicialment Postgres no té ni idea de la compatibilitat total i profunda amb els sistemes de còpia de seguretat. Per tant, vam haver de buscar una solució que inicialment tingués la màxima funcionalitat conjuntament amb PostgreSQL i perfeccionar el sistema.
Vam fer 3 "hackathons" interns: vam mirar més de cinquanta desenvolupaments, els vam provar, vam fer canvis en relació amb les nostres hipòtesis i els vam tornar a provar. Després de revisar les opcions disponibles, vam triar Commvault. Fora de la caixa, aquest producte podria funcionar amb la instal·lació de clúster PostgreSQL més senzilla, i la seva arquitectura oberta va generar esperances (que estaven justificades) per a un desenvolupament i una integració reeixits. Commvault també pot fer una còpia de seguretat dels registres de PostgreSQL. Per exemple, Veritas NetBackup en termes de PostgreSQL només pot fer còpies de seguretat completes.
Més sobre arquitectura. Els servidors de gestió de Commvault es van instal·lar a cadascun dels dos centres de dades en una configuració CommServ HA. El sistema es reflecteix, es gestiona a través d'una consola i, des del punt de vista d'HA, compleix tots els requisits de l'empresa.
També vam llançar dos servidors de mitjans físics a cada centre de dades, als quals vam connectar matrius de discos i biblioteques de cintes dedicades específicament a les còpies de seguretat mitjançant SAN a través de Fibre Channel. Les bases de dades de deduplicació ampliades van assegurar la tolerància a errors dels servidors multimèdia i la connexió de cada servidor a cada CSV va permetre un funcionament continu si algun component fallava. L'arquitectura del sistema permet que la còpia de seguretat continuï encara que un dels centres de dades cau.
Patroni defineix un node principal per a cada clúster. Pot ser qualsevol node lliure del centre de dades, però només la majoria. A la còpia de seguretat, tots els nodes són secundaris.
Per tal que Commvault entengui quin node del clúster és principal, hem integrat el sistema (gràcies a l'arquitectura oberta de la solució) amb Postgres. Amb aquesta finalitat, es va crear un script que informa de la ubicació actual del node principal al servidor de gestió de Commvault.
En general, el procés és el següent:
Patroni selecciona Principal → Keepalived recull el clúster IP i executa l'script → l'agent de Commvault al node de clúster seleccionat rep una notificació que aquest és el principal → Commvault reconfigura automàticament la còpia de seguretat dins del pseudoclient.
L'avantatge d'aquest enfocament és que la solució no afecta la consistència, la correcció dels registres o la recuperació de la instància de Postgres. També és fàcilment escalable, perquè ja no cal arreglar els nodes primaris i secundaris de Commvault. N'hi ha prou que el sistema entengui on es troba Primari i el nombre de nodes es pot augmentar a gairebé qualsevol valor.
La solució no pretén ser ideal i té els seus propis matisos. Commvault només pot fer una còpia de seguretat de la instància sencera i no de les bases de dades individuals. Per tant, es va crear una instància separada per a cada base de dades. Els clients reals es combinen en pseudoclients virtuals. Cada pseudoclient de Commvault és un clúster UNIX. S'hi afegeixen aquells nodes de clúster on s'ha instal·lat l'agent Commvault per a Postgres. Com a resultat, es fa una còpia de seguretat de tots els nodes virtuals del pseudoclient com una sola instància.
Dins de cada pseudoclient, s'indica el node actiu del clúster. Això és el que defineix la nostra solució d'integració per a Commvault. El principi del seu funcionament és bastant simple: si es genera una IP de clúster en un node, l'script estableix el paràmetre "node actiu" al binari de l'agent Commvault; de fet, l'script estableix "1" a la part necessària de la memòria. . L'agent transmet aquestes dades a CommServe i Commvault fa una còpia de seguretat des del node desitjat. A més, es comprova la correcció de la configuració a nivell d'script, ajudant a evitar errors en iniciar una còpia de seguretat.
Al mateix temps, es fa una còpia de seguretat de grans bases de dades en blocs a través de diversos fils, complint els requisits de RPO i de la finestra de còpia de seguretat. La càrrega del sistema és insignificant: les còpies completes no es produeixen tan sovint, altres dies només es recullen registres i durant els períodes de baixa càrrega.
Per cert, hem aplicat polítiques separades per fer còpies de seguretat dels registres d'arxiu de PostgreSQL: s'emmagatzemen segons regles diferents, es copien segons una programació diferent i la deduplicació no està habilitada per a ells, ja que aquests registres contenen dades úniques.
Per garantir la coherència a tota la infraestructura de TI, s'instal·len clients de fitxers Commvault separats a cadascun dels nodes del clúster. Exclouen els fitxers Postgres de les còpies de seguretat i només estan destinats a les còpies de seguretat del sistema operatiu i de les aplicacions. Aquesta part de les dades també té la seva pròpia política i període d'emmagatzematge.
Actualment, IBS no afecta els serveis de productivitat, però si la situació canvia, Commvault pot habilitar la limitació de càrrega.
És bo? Bé!
Per tant, hem rebut no només una còpia de seguretat viable, sinó també una còpia de seguretat totalment automatitzada per a una instal·lació de clúster PostgreSQL, i compleix tots els requisits per a les trucades empresarials.
Els paràmetres RPO i RTO d'1 hora i 2 hores estan coberts amb un marge, la qual cosa significa que el sistema els complirà fins i tot amb un augment significatiu del volum de dades emmagatzemades. Contràriament a molts dubtes, PostgreSQL i l'entorn empresarial van resultar ser bastant compatibles. I ara sabem per la nostra pròpia experiència que la còpia de seguretat d'aquests DBMS és possible en una gran varietat de configuracions.
Per descomptat, en aquest camí hem hagut de desgastar set parells de botes de ferro, superar una sèrie de dificultats, trepitjar diversos rasclets i corregir una sèrie d'errors. Però ara l'enfocament ja s'ha provat i es pot utilitzar per implementar codi obert en lloc de DBMS propietari en condicions empresarials dures.
Heu provat de treballar amb PostgreSQL en un entorn corporatiu?
Autors:
Oleg Lavrenov, enginyer de disseny de sistemes d'emmagatzematge de dades, Jet Infosystems
Dmitry Erykin, enginyer de disseny de sistemes informàtics a Jet Infosystems
Font: www.habr.com