Moitas persoas están familiarizadas co DBMS PostgreSQL e demostrouse en pequenas instalacións. Non obstante, a tendencia cara ao código aberto fíxose cada vez máis clara, mesmo cando se trata de grandes empresas e requisitos das empresas. Neste artigo dirémosche como integrar Postgres nun ambiente corporativo e compartiremos a nosa experiencia na creación dun sistema de copia de seguridade (BSS) para esta base de datos usando o sistema de copia de seguridade de Commvault como exemplo.
PostgreSQL xa demostrou a súa valía: o DBMS funciona moi ben, é usado por empresas dixitais de moda como Alibaba e TripAdvisor, e a falta de taxas de licenza convérteo nunha alternativa tentadora para monstros como MS SQL ou Oracle DB. Pero axiña que comezamos a pensar en PostgreSQL no panorama empresarial, inmediatamente atopámonos con requisitos estritos: "E a tolerancia a fallos de configuración? resistencia a desastres? onde está o seguimento integral? Que pasa coas copias de seguridade automáticas? Que tal usar bibliotecas de cintas tanto directamente como no almacenamento secundario?
Por unha banda, PostgreSQL non ten ferramentas de copia de seguridade integradas, como DBMS "adultos" como RMAN en Oracle DB ou SAP Database Backup. Por outra banda, os provedores de sistemas de copia de seguridade corporativos (Veeam, Veritas, Commvault) aínda que admiten PostgreSQL, de feito só funcionan cunha determinada configuración (normalmente autónoma) e cun conxunto de varias restricións.
Os sistemas de copia de seguridade especialmente deseñados para PostgreSQL, como Barman, Wal-g, pg_probackup, son moi populares en pequenas instalacións do DBMS PostgreSQL ou onde non se necesitan copias de seguridade pesadas doutros elementos do panorama informático. Por exemplo, ademais de PostgreSQL, a infraestrutura pode incluír servidores físicos e virtuais, OpenShift, Oracle, MariaDB, Cassandra, etc. É recomendable facer unha copia de seguridade de todo isto cunha ferramenta común. Instalar unha solución separada exclusivamente para PostgreSQL é unha mala idea: os datos copiaranse nalgún lugar no disco e despois hai que eliminalos na cinta. Esta dobre copia de seguridade aumenta o tempo de copia de seguridade, e tamén, de xeito máis crítico, o tempo de recuperación.
Nunha solución empresarial, a copia de seguridade da instalación prodúcese cun número determinado de nós nun clúster dedicado. Ao mesmo tempo, por exemplo, Commvault só pode funcionar cun clúster de dous nodos, no que o Primario e o Secundario están estrictamente asignados a certos nodos. E só ten sentido facer copias de seguridade desde Primaria, porque a copia de seguridade desde Secundaria ten as súas limitacións. Debido ás peculiaridades do DBMS, non se crea un volcado en Secundario e, polo tanto, só queda a posibilidade dunha copia de seguridade de ficheiros.
Para reducir o risco de tempo de inactividade, ao crear un sistema tolerante a fallos, créase unha configuración de clúster "en vivo" e Primary pode migrar gradualmente entre distintos servidores. Por exemplo, o propio software Patroni lanza Primary nun nodo de clúster seleccionado aleatoriamente. O IBS non ten forma de rastrexar isto fóra da caixa e, se a configuración cambia, os procesos rompen. É dicir, a introdución de control externo impide que o ISR funcione de forma eficaz, porque o servidor de control simplemente non entende onde e que datos hai que copiar.
Outro problema é a implementación da copia de seguridade en Postgres. É posible mediante o vocado e funciona en pequenas bases de datos. Pero en grandes bases de datos, o volcado leva moito tempo, require moitos recursos e pode provocar un fallo da instancia da base de datos.
A copia de seguridade de ficheiros corrixe a situación, pero nas bases de datos grandes é lenta porque funciona en modo de fío único. Ademais, os provedores teñen unha serie de restricións adicionais. Ou non pode usar copias de seguranza de ficheiros e volcados ao mesmo tempo, ou non se admite a deduplicación. Hai moitos problemas, e a maioría das veces é máis fácil escoller un DBMS caro pero comprobado en lugar de Postgres.
Non hai onde retirarse! Os desenvolvedores de Moscova están atrás!
Non obstante, recentemente o noso equipo enfrontouse a un desafío difícil: no proxecto de creación de AIS OSAGO 2.0, onde creamos a infraestrutura informática, os desenvolvedores escolleron PostgreSQL para o novo sistema.
É moito máis doado para os grandes desenvolvedores de software usar solucións de código aberto "de moda". Facebook ten especialistas suficientes para apoiar o funcionamento deste DBMS. E no caso de RSA, todas as tarefas do "segundo día" recaeron sobre os nosos ombreiros. Esixímonos garantir a tolerancia a fallos, montar un clúster e, por suposto, configurar unha copia de seguridade. A lóxica de actuación foi a seguinte:
- Ensina ao SRK a facer copias de seguridade desde o nodo principal do clúster. Para iso, o SRK debe atopalo, o que significa que é necesaria a integración cunha ou outra solución de xestión de clúster PostgreSQL. No caso de RSA, utilizouse para iso o software Patroni.
- Decida o tipo de copia de seguridade en función do volume de datos e dos requisitos de recuperación. Por exemplo, cando necesite restaurar páxinas de forma granular, use un volcado e, se as bases de datos son grandes e non é necesaria a restauración granular, traballe a nivel de ficheiro.
- Achegue a posibilidade de facer copias de seguridade de bloques á solución para crear unha copia de seguridade en modo multiproceso.
Ao mesmo tempo, inicialmente propuxémonos crear un sistema eficaz e sinxelo sen un monstruoso arnés de compoñentes adicionais. Canto menos muletas, menor carga de traballo do persoal e menor risco de falla do IBS. Inmediatamente excluímos os enfoques que utilizaban Veeam e RMAN, porque un conxunto de dúas solucións xa insinúa a falta de fiabilidade do sistema.
Un pouco de maxia para a empresa
Polo tanto, necesitabamos garantir unha copia de seguridade fiable de 10 clústeres de 3 nodos cada un, coa mesma infraestrutura reflectida no centro de datos de copia de seguridade. Os centros de datos en termos de PostgreSQL traballan no principio activo-pasivo. O tamaño total da base de datos foi de 50 TB. Calquera sistema de control a nivel corporativo pode xestionar isto facilmente. Pero a advertencia é que inicialmente Postgres non ten nin idea de compatibilidade total e profunda cos sistemas de copia de seguridade. Polo tanto, tivemos que buscar unha solución que inicialmente tivese a máxima funcionalidade en conxunto con PostgreSQL e perfeccionar o sistema.
Realizamos 3 "hackathons" internos: analizamos máis de cincuenta desenvolvementos, probámolos, fixemos cambios en relación coas nosas hipóteses e probamos de novo. Despois de revisar as opcións dispoñibles, escollemos Commvault. Fóra da caixa, este produto podería funcionar coa instalación de clúster PostgreSQL máis sinxela e a súa arquitectura aberta suscitaba esperanzas (que estaban xustificadas) dun desenvolvemento e integración exitosos. Commvault tamén pode facer unha copia de seguridade dos rexistros de PostgreSQL. Por exemplo, Veritas NetBackup en termos de PostgreSQL só pode facer copias de seguridade completas.
Máis sobre arquitectura. Os servidores de xestión de Commvault instaláronse en cada un dos dous centros de datos nunha configuración de CommServ HA. O sistema é espello, xestionado a través dunha consola e, desde o punto de vista de alta disponibilidad, cumpre todos os requisitos da empresa.
Tamén lanzamos dous servidores de medios físicos en cada centro de datos, aos que conectamos matrices de discos e bibliotecas de cintas dedicadas especificamente para copias de seguridade a través de SAN a través de Fibre Channel. As bases de datos de deduplicación estendidas aseguraron a tolerancia a fallos dos servidores multimedia, e a conexión de cada servidor a cada CSV permitiu o funcionamento continuo se algún compoñente fallaba. A arquitectura do sistema permite que a copia de seguridade continúe aínda que se caia un dos centros de datos.
Patroni define un nodo principal para cada clúster. Pode ser calquera nodo libre do centro de datos, pero só na súa maioría. Na copia de seguridade, todos os nodos son secundarios.
Para que Commvault entenda que nodo do clúster é Primario, integramos o sistema (grazas á arquitectura aberta da solución) con Postgres. Para este fin, creouse un script que informa da localización actual do nodo principal ao servidor de xestión de Commvault.
En xeral, o proceso ten o seguinte aspecto:
Patroni selecciona Principal → Keepalived recolle o clúster de IP e executa o script → o axente de Commvault no nodo de clúster seleccionado recibe unha notificación de que este é o principal → Commvault reconfigura automaticamente a copia de seguranza dentro do pseudo-cliente.
A vantaxe deste enfoque é que a solución non afecta a coherencia, a corrección dos rexistros ou a recuperación da instancia de Postgres. Tamén é facilmente escalable, porque xa non é necesario arranxar os nós primarios e secundarios de Commvault. É suficiente con que o sistema entenda onde está o Primario e o número de nós pódese aumentar a case calquera valor.
A solución non pretende ser ideal e ten os seus propios matices. Commvault só pode facer unha copia de seguridade da instancia completa e non das bases de datos individuais. Polo tanto, creouse unha instancia separada para cada base de datos. Os clientes reais combínanse en pseudoclientes virtuais. Cada pseudocliente de Commvault é un clúster UNIX. Engádenselle aqueles nodos de clúster nos que está instalado o axente Commvault para Postgres. Como resultado, todos os nodos virtuais do pseudo-cliente fanse unha copia de seguranza como unha única instancia.
Dentro de cada pseudo-cliente, indícase o nodo activo do clúster. Isto é o que define a nosa solución de integración para Commvault. O principio do seu funcionamento é bastante sinxelo: se se crea unha IP de clúster nun nodo, o script establece o parámetro "nodo activo" no binario do axente Commvault; de feito, o script establece "1" na parte necesaria da memoria. . O axente transmite estes datos a CommServe e Commvault fai unha copia de seguridade desde o nodo desexado. Ademais, compróbase a corrección da configuración a nivel de script, axudando a evitar erros ao iniciar unha copia de seguridade.
Ao mesmo tempo, as grandes bases de datos fanse unha copia de seguranza en bloques en varios fíos, cumprindo os requisitos de RPO e fiestras de copia de seguridade. A carga do sistema é insignificante: as copias completas non se producen con tanta frecuencia, outros días só se recollen rexistros e durante períodos de pouca carga.
Por certo, aplicamos políticas separadas para facer copias de seguridade dos rexistros de arquivos de PostgreSQL: almacénanse segundo regras diferentes, cópianse segundo unha programación diferente e a deduplicación non está habilitada para eles, xa que estes rexistros conteñen datos únicos.
Para garantir a coherencia en toda a infraestrutura de TI, instálanse clientes de ficheiros Commvault separados en cada un dos nodos do clúster. Exclúen os ficheiros Postgres das copias de seguridade e só están destinados a copias de seguridade do SO e das aplicacións. Esta parte dos datos tamén ten a súa propia política e período de almacenamento.
Actualmente, IBS non afecta aos servizos de produtividade, pero se a situación cambia, Commvault pode activar a limitación de carga.
É bo? Ben!
Polo tanto, recibimos non só unha copia de seguridade viable, senón tamén totalmente automatizada para unha instalación de clúster de PostgreSQL e cumpre todos os requisitos para as chamadas empresariais.
Os parámetros RPO e RTO de 1 hora e 2 horas están cubertos cunha marxe, o que significa que o sistema cumprirá con eles mesmo cun aumento significativo do volume de datos almacenados. Contrariamente a moitas dúbidas, PostgreSQL e o entorno empresarial resultaron bastante compatibles. E agora sabemos pola nosa propia experiencia que a copia de seguridade para tales DBMS é posible nunha gran variedade de configuracións.
Por suposto, por este camiño tivemos que desgastar sete pares de botas de ferro, superar unha serie de dificultades, pisar varios rastrillos e corrixir unha serie de erros. Pero agora o enfoque xa se probou e pódese usar para implementar código aberto en lugar de DBMS propietario en condicións empresariais duras.
Tentaches traballar con PostgreSQL nun ambiente corporativo?
Os autores:
Oleg Lavrenov, enxeñeiro de deseño de sistemas de almacenamento de datos, Jet Infosystems
Dmitry Erykin, enxeñeiro de deseño de sistemas informáticos en Jet Infosystems
Fonte: www.habr.com