Muitas pessoas estão familiarizadas com o SGBD PostgreSQL e ele já foi comprovado em pequenas instalações. No entanto, a tendência para o Open Source tornou-se cada vez mais clara, mesmo quando se trata de grandes empresas e requisitos empresariais. Neste artigo iremos explicar como integrar o Postgres em um ambiente corporativo e compartilhar nossa experiência na criação de um sistema de backup (BSS) para este banco de dados usando o sistema de backup Commvault como exemplo.
O PostgreSQL já provou seu valor - o SGBD funciona muito bem, é usado por empresas digitais da moda como Alibaba e TripAdvisor, e a falta de taxas de licenciamento o torna uma alternativa tentadora a monstros como MS SQL ou Oracle DB. Mas assim que começamos a pensar no PostgreSQL no cenário empresarial, imediatamente nos deparamos com requisitos rigorosos: “E quanto à tolerância a falhas de configuração? resistência a desastres? onde está o monitoramento abrangente? E quanto aos backups automatizados? Que tal usar bibliotecas de fitas diretamente e no armazenamento secundário?”
Por um lado, o PostgreSQL não possui ferramentas de backup integradas, como DBMSs “adultos”, como RMAN em Oracle DB ou SAP Database Backup. Por outro lado, os fornecedores de sistemas de backup corporativos (Veeam, Veritas, Commvault) embora suportem PostgreSQL, na verdade só funcionam com uma determinada configuração (geralmente autônoma) e com um conjunto de diversas restrições.
Sistemas de backup especialmente projetados para PostgreSQL, como Barman, Wal-g, pg_probackup, são extremamente populares em pequenas instalações do SGBD PostgreSQL ou onde não são necessários backups pesados de outros elementos do cenário de TI. Por exemplo, além do PostgreSQL, a infraestrutura pode incluir servidores físicos e virtuais, OpenShift, Oracle, MariaDB, Cassandra, etc. É aconselhável fazer backup de tudo isso com uma ferramenta comum. Instalar uma solução separada exclusivamente para PostgreSQL é uma má ideia: os dados serão copiados em algum lugar no disco e então precisarão ser removidos para fita. Este backup duplo aumenta o tempo de backup e também, de forma mais crítica, o tempo de recuperação.
Em uma solução empresarial, o backup da instalação ocorre com um determinado número de nós em um cluster dedicado. Ao mesmo tempo, por exemplo, o Commvault só pode funcionar com um cluster de dois nós, no qual Primário e Secundário são estritamente atribuídos a determinados nós. E só faz sentido fazer backup do Primário, porque o backup do Secundário tem suas limitações. Devido às peculiaridades do SGBD, não é criado um dump no Secundário e, portanto, resta apenas a possibilidade de backup do arquivo.
Para reduzir o risco de tempo de inatividade, ao criar um sistema tolerante a falhas, é criada uma configuração de cluster “ao vivo” e o Primário pode migrar gradualmente entre diferentes servidores. Por exemplo, o próprio software Patroni inicia o Primário em um nó de cluster selecionado aleatoriamente. O IBS não tem como rastrear isso imediatamente e, se a configuração mudar, os processos serão interrompidos. Ou seja, a introdução do controle externo impede que o ISR funcione de forma eficaz, porque o servidor de controle simplesmente não entende de onde e de quais dados precisam ser copiados.
Outro problema é a implementação do backup no Postgres. É possível através do dump e funciona em bancos de dados pequenos. Porém, em bancos de dados grandes, o despejo leva muito tempo, requer muitos recursos e pode levar à falha da instância do banco de dados.
O backup de arquivos corrige a situação, mas em bancos de dados grandes é lento porque funciona no modo de thread único. Além disso, os fornecedores têm uma série de restrições adicionais. Você não pode usar backups de arquivo e dump ao mesmo tempo ou a desduplicação não é suportada. Existem muitos problemas e, na maioria das vezes, é mais fácil escolher um SGBD caro, mas comprovado, em vez do Postgres.
Não há para onde recuar! Os desenvolvedores de Moscou estão atrás!
Porém, recentemente nossa equipe enfrentou um difícil desafio: no projeto de criação do AIS OSAGO 2.0, onde criamos a infraestrutura de TI, os desenvolvedores escolheram o PostgreSQL para o novo sistema.
É muito mais fácil para grandes desenvolvedores de software usar soluções de código aberto “modernas”. O Facebook possui especialistas suficientes para apoiar o funcionamento deste SGBD. E no caso da RSA, todas as tarefas do “segundo dia” recaíram sobre nossos ombros. Fomos obrigados a garantir tolerância a falhas, montar um cluster e, claro, configurar backup. A lógica de ação foi a seguinte:
- Ensine o SRK a fazer backups do nó primário do cluster. Para fazer isso, o SRK deve encontrá-lo - o que significa que é necessária integração com uma ou outra solução de gerenciamento de cluster PostgreSQL. No caso do RSA, foi utilizado o software Patroni para isso.
- Decida o tipo de backup com base no volume de dados e nos requisitos de recuperação. Por exemplo, quando você precisar restaurar páginas granularmente, use um dump e, se os bancos de dados forem grandes e a restauração granular não for necessária, trabalhe no nível do arquivo.
- Anexe a possibilidade de backup em bloco à solução para criar uma cópia de backup no modo multithread.
Ao mesmo tempo, inicialmente pretendemos criar um sistema simples e eficaz, sem um conjunto monstruoso de componentes adicionais. Quanto menos muletas, menor a carga de trabalho da equipe e menor o risco de falha do IBS. Excluímos imediatamente as abordagens que usavam Veeam e RMAN, porque um conjunto de duas soluções já indica a falta de confiabilidade do sistema.
Um pouco de magia para empresas
Assim, precisávamos garantir backup confiável para 10 clusters de 3 nós cada, com a mesma infraestrutura espelhada no data center de backup. Os data centers em termos de PostgreSQL funcionam com base no princípio ativo-passivo. O tamanho total do banco de dados foi de 50 TB. Qualquer sistema de controle de nível corporativo pode lidar facilmente com isso. Mas a ressalva é que inicialmente o Postgres não tem ideia de compatibilidade total e profunda com sistemas de backup. Portanto, tivemos que buscar uma solução que inicialmente tivesse o máximo de funcionalidade em conjunto com o PostgreSQL, e refinar o sistema.
Realizamos 3 “hackathons” internos - analisamos mais de cinquenta desenvolvimentos, testamos, fizemos alterações em relação às nossas hipóteses e os testamos novamente. Depois de analisar as opções disponíveis, escolhemos o Commvault. Pronto para uso, este produto poderia funcionar com a instalação mais simples de cluster PostgreSQL, e sua arquitetura aberta levantou esperanças (que foram justificadas) de desenvolvimento e integração bem-sucedidos. O Commvault também pode fazer backup de logs do PostgreSQL. Por exemplo, o Veritas NetBackup em termos de PostgreSQL só pode fazer backups completos.
Mais sobre arquitetura. Os servidores de gerenciamento Commvault foram instalados em cada um dos dois data centers em uma configuração CommServ HA. O sistema é espelhado, gerenciado por meio de um console e, do ponto de vista de alta disponibilidade, atende a todos os requisitos empresariais.
Também lançamos dois servidores de mídia física em cada data center, aos quais conectamos arrays de discos e bibliotecas de fitas dedicadas especificamente para backups via SAN via Fibre Channel. Bancos de dados de desduplicação estendidos garantiram tolerância a falhas de servidores de mídia, e a conexão de cada servidor a cada CSV permitiu a operação contínua se algum componente falhasse. A arquitetura do sistema permite que o backup continue mesmo se um dos data centers cair.
Patroni define um nó primário para cada cluster. Pode ser qualquer nó livre no data center - mas apenas na maior parte. No backup, todos os nós são secundários.
Para que a Commvault entenda qual nó do cluster é Primário, integramos o sistema (graças à arquitetura aberta da solução) com o Postgres. Para isso, foi criado um script que reporta a localização atual do nó Primário ao servidor de gerenciamento Commvault.
Em geral, o processo é assim:
Patroni seleciona Primário → Keepalived pega o cluster IP e executa o script → o agente Commvault no nó do cluster selecionado recebe uma notificação de que este é o Primário → Commvault reconfigura automaticamente o backup dentro do pseudo-cliente.
A vantagem desta abordagem é que a solução não afeta a consistência, a exatidão dos logs ou a recuperação da instância do Postgres. Também é facilmente escalável, porque não é mais necessário consertar os nós primário e secundário do Commvault. Basta que o sistema entenda onde está o Primário e o número de nós pode ser aumentado para quase qualquer valor.
A solução não pretende ser ideal e tem nuances próprias. O Commvault só pode fazer backup de toda a instância, e não de bancos de dados individuais. Portanto, uma instância separada foi criada para cada banco de dados. Clientes reais são combinados em pseudoclientes virtuais. Cada pseudocliente Commvault é um cluster UNIX. Os nós do cluster nos quais o agente Commvault para Postgres está instalado são adicionados a ele. Como resultado, é feito backup de todos os nós virtuais do pseudocliente como uma instância.
Dentro de cada pseudocliente é indicado o nó ativo do cluster. Isto é o que define a nossa solução de integração para Commvault. O princípio de sua operação é bastante simples: se um IP do cluster for gerado em um nó, o script define o parâmetro “nó ativo” no binário do agente Commvault - na verdade, o script define “1” na parte necessária da memória . O agente transmite esses dados para o CommServe e o Commvault faz um backup do nó desejado. Além disso, a exatidão da configuração é verificada no nível do script, ajudando a evitar erros ao iniciar um backup.
Ao mesmo tempo, é feito backup de grandes bancos de dados em blocos em vários threads, atendendo aos requisitos de RPO e de janela de backup. A carga no sistema é insignificante: cópias completas não ocorrem com tanta frequência, nos outros dias apenas os logs são coletados e durante períodos de baixa carga.
A propósito, aplicamos políticas separadas para fazer backup de logs de arquivo PostgreSQL - eles são armazenados de acordo com regras diferentes, copiados de acordo com uma programação diferente e a desduplicação não está habilitada para eles, pois esses logs contêm dados exclusivos.
Para garantir a consistência em toda a infraestrutura de TI, clientes de arquivos Commvault separados são instalados em cada um dos nós do cluster. Eles excluem arquivos Postgres dos backups e destinam-se apenas a backups de sistemas operacionais e aplicativos. Esta parte dos dados também possui política e período de armazenamento próprios.
Atualmente, o IBS não afeta os serviços de produtividade, mas se a situação mudar, o Commvault poderá ativar a limitação de carga.
Isso é bom? Bom!
Portanto, recebemos não apenas um backup viável, mas também totalmente automatizado para uma instalação de cluster PostgreSQL, e ele atende a todos os requisitos para chamadas corporativas.
Os parâmetros RPO e RTO de 1 hora e 2 horas são cobertos com margem, o que significa que o sistema os cumprirá mesmo com um aumento significativo no volume de dados armazenados. Ao contrário de muitas dúvidas, o PostgreSQL e o ambiente corporativo revelaram-se bastante compatíveis. E agora sabemos por experiência própria que o backup para tais SGBDs é possível em uma ampla variedade de configurações.
É claro que neste caminho tivemos que desgastar sete pares de botas de ferro, superar uma série de dificuldades, pisar em vários ancinhos e corrigir uma série de erros. Mas agora a abordagem já foi testada e pode ser usada para implementar código aberto em vez de SGBD proprietários em condições empresariais adversas.
Você já tentou trabalhar com PostgreSQL em um ambiente corporativo?
Autores:
Oleg Lavrenov, engenheiro de projeto de sistemas de armazenamento de dados, Jet Infosystems
Dmitry Erykin, engenheiro de design de sistemas de computador da Jet Infosystems
Fonte: habr.com