Esta publicação foi de autoria de Yashesh Mankad, membro sênior da equipe técnica da Nutanix
O PostgreSQL é um poderoso sistema de banco de dados relacional de código aberto, robusto e confiável, com uma arquitetura totalmente extensível. Ele roda em todos os principais sistemas operacionais e oferece diversos complementos que podem transformar uma instância do PostgreSQL em diversos aplicativos, como bancos de dados de séries temporais, filas de mensagens etc.
Devido aos pontos fortes do Postgres, é uma opção popular de persistência de dados para aplicativos complexos, especialmente quando se considera bancos de dados de código aberto. O Postgres pode ser implantado como uma instância autônoma ou na forma de um cluster. As implantações mais graves atingem rapidamente os limites de escala e disponibilidade com implantações de instância única. O Postgres oferece blocos de construção para alta disponibilidade, como replicação, leitura de réplicas, implantação de mestre único versus mestre múltiplo e assim por diante. No entanto, ele não oferece uma solução integrada para armazenamento em cluster e alta disponibilidade.
Nutanix d atabase como um s erv gelo (conhecido como Nutanix Era ) resolve esse problema oferecendo uma capacidade de um clique para implantar um banco de dados Postgres altamente disponível. Era utiliza uma série de tecnologias impulsionadas por Postgres ' melhores práticas para prestação deste cluster. Este guia fornece detalhes sobre essas tecnologias, qual o seu papel, além de alguns aspectos importantes da configuração para criar um cluster operacional.
Elementos de um cluster do Postgres
Um cluster do Postgres deve oferecer elasticidade - essa é a capacidade de adicionar / remover nós do cluster com 100% de disponibilidade do Postgres. Para alta disponibilidade, o cluster deve ser capaz de acompanhar as mudanças de estado de seus nós membros para garantir que há sempre uma m aster a aceitar as gravações de banco de dados de forma consistente. Além disso, ele deve fornecer durabilidade dos dados por meio da replicação para levar em conta falhas de disco ou nó. O software Postgres não é suficiente para atender a todos esses requisitos. Precisamos trazer outros elementos para o ecossistema. Descrevemos abaixo alguns desses elementos e o papel que cada elemento desempenha no cluster.
Gerenciador de clusters
Um gerenciador de cluster está no coração de toda a arquitetura. Ele é responsável por configurar um nó do Postgres com base em sua função no cluster (mestre x réplica). Ele monitora os nós que entram e saem do cluster. Quando um novo nó é adicionado, ele precisa ser configurado como uma réplica primeiro. Como réplica, o nó é responsável por sincronizar seu estado com o mestre. Os membros do cluster também são responsáveis por manter os logs de archive para recuperação posterior. O gerenciador de cluster mantém o estado de cada nó , incluindo qual nó é mestre e quais são réplicas.
Entre réplicas, podemos ter réplicas síncronas que refletem o estado exato do mestre, enquanto algumas réplicas podem ser assíncronas que podem atrasar o mestre. O gerenciador de clusters controla quais réplicas são síncronas versus assíncronas e a quantidade pela qual cada réplica fica atrasada no mestre. Todo esse estado deve ser mantido e atualizado em tempo real para garantir a maior disponibilidade do cluster de banco de dados. Os gerenciadores de cluster são peças complexas de software . Este fluxograma fornece uma idéia sobre quantas transições de estado um gerente de cluster precisa executar quando um nó fica inativo no cluster.
A comunidade do Postgres recomenda vários gerenciadores de cluster, como Barman e Stolon. A Nutanix Era usa o gerenciador de cluster mais popular, Patroni, como o gerenciador de cluster em todos os clusters do Postgres provisionados para seus clientes. Patroni é altamente recomendado devido a recursos como detecção automática de falha e recuperação, o consenso distribuído para cada ação no cluster, e uma API - primeira abordagem para a configuração, switchovers e ferramental. Uma instância do Patroni é executada em todos os nós do Postgres.
Armazenamento de Configuração Distribuída
O Patroni precisa de um armazenamento de valor-chave distribuído e altamente consistente para salvar todos os estados que está rastreando para os membros do cluster. Esse armazenamento de valor-chave também é usado para rastrear alterações de estado, configurando uma sessão HTTP ativa com verificações de integridade para todos os nós no cluster. Como a loja fornece consistência estrita durante a atualização das chaves, é uma boa solução para a eleição de líderes em um quorum de nós do Postgres e Patroni. Patroni suporta um número de lojas de valores-chave como etcd, Consul e Zookeeper.
No entanto, o etcd é de alto desempenho e é usado em muitos sistemas distribuídos como Kubernetes, CockrochDB e assim por diante. O Nutanix Era usa o etcd também para fins de consenso e persistência distribuídos. Uma instância do etcd é executada em todos os nós do Postgres. O anel etcd pode ser mantido fora do Postgres e Patroni, mas a Eraescolheu essa abordagem para minimizar os recursos físicos necessários para o cluster.
Servidores proxy
Os pedidos devem ser afetados quando há m áster ou de liderança mudanças no cluster. Para conseguir isso, o cluster é front-end com um proxy e os aplicativos se conectam a esse proxy em vez de mnó aster diretamente. O Era usa o HAProxy para oferecer esse recurso. O proxy não deve ser um ponto único de falha. Como resultado, o Era implanta duas instâncias do proxy para redundância. O aplicativo também não deve ser afetado por alterações nesses proxies. Como resultado, os proxies são expostos ao aplicativo por meio de um IP virtual reservado que nunca muda. O Era usa um daemon chamado keepalived que é responsável pelo mapeamento de solicitações no IP virtual para o proxy apropriado. Tanto o HAProxy quanto o keepalived são tecnologias confiáveis e de código aberto que foram reforçadas ao longo dos anos.
Topologia de implantação
Se juntarmos todas as peças, teremos uma topologia parecida com esta:
O cluster do Postgres consiste em 3 ou mais nós, com um nó mantendo a função principal e o restante dos nós atuando como réplicas (hot standbys). Podemos ter até dois nós HAProxy para redundância com um IP virtual usado pelos aplicativos para usar o cluster.
As gravações de banco de dados são direcionadas ao mestre, enquanto que temos várias opções para leituras. Lê pode ser dirigido para o mestre, todas as réplicas , ou um subconjunto deles.
Replicação
As réplicas extraem dados do mestre de duas formas : síncrona e assíncrona. O Era suporta as duas formas de replicação quando provisiona um cluster. Caso o usuário escolha a replicação síncrona, configuramos apenas um nó do cluster como uma réplica de sincronização para limitar a degradação do desempenho do banco de dados para atualizações de tabela. O restante das réplicas é assíncrono. A replicação do Postgres é um tópico vasto, e é possível aprender mais sobre isso nos documentos do Postgres.
Configuração de chave
A maioria das configurações do cluster ocorre no Patroni. Aqui estão alguns detalhes importantes da configuração que são essenciais para um cluster íntegro:
Usuário de replicação : um usuário dedicado do Postgres especificado na configuração do Patroni que é usado para conectar-se ao mestre, transmitir logs do WAL e aplicá-los.
Armazenamento para logs de arquivamento : é recomendável manter logs de arquivamento em um cluster. Se as réplicas perderem a conexão com o mestre, elas poderão ser sincronizadas a partir dos arquivos. O Era arquiva logs WAL do banco de dados para ativar esse recurso. A implantação precisa de armazenamento suficiente se o arquivamento for desejado.
Comando de arquivamento : comando usado para arquivar logs WAL ao atuar como mestre.
Comando Restaurar : Comando usado para arquivar logs WAL ao atuar como uma réplica.
Configurações do modo síncrono: synchronous_mode e synchronous_mode_strict devem estar "ativados" caso o usuário deseje replicação síncrona.
Era Nutanix - Banco de Dados como Serviço
O Nutanix Era fornece à funcionalidade DBaaS o gerenciamento de banco de dados com um clique (fornecimento, clone, patch, atualização e backup) em apenas alguns minutos. O Nutanix Era automatiza e simplifica o gerenciamento de banco de dados, trazendo simplicidade com um clique e operações invisíveis ao provisionamento de banco de dados e gerenciamento do ciclo de vida (LCM). O provisionamento e o gerenciamento de dados de cópia (CDM) são recursos fundamentais que permitem aos administradores de banco de dados provisionar, clonar, atualizar e restaurar seus bancos de dados a qualquer momento. Por meio de uma interface do usuário e CLI rica, mas simples de usar, elas podem restaurar a transação mais recente consistente com o aplicativo.
A Era utiliza as tecnologias acima para não apenas provisionar rapidamente os clusters do Postgres para seus clientes, mas também praticar as melhores práticas e padrões. Os aglomerados têm uma única m áster e várias réplicas de leitura com uma opção de implantar uma réplica síncrona. O Era suporta a implantação de até dois HAProxies, dependendo da redundância desejada. Os logs de arquivamento também são gerenciados pelo Era. Eles são armazenados dentro e fora do cluster do Postgres para fornecer opções de recuperação, caso o cluster inteiro precise ser recriado. O Era também oferece instantâneos de nível de armazenamento em tempo discreto para backups e recuperação de banco de dados.
Referências
https://patroni.readthedocs.io/en/latest/dynamic_configuration.html
https: // www.linode.com/docs/databases/postgresql/create-a-highly-available- postgresql-cluster-using-patroni-and-haproxy /
ASG
https://www.asgit.com.br/
contato@asg.com.br
(51) 3376.1210