Partilhar via


Visão geral da implantação de um banco de dados PostgreSQL altamente disponível no Serviço Kubernetes do Azure (AKS)

Neste guia, você implanta um cluster PostgreSQL altamente disponível que abrange várias zonas de disponibilidade do Azure no AKS com a CLI do Azure.

Este artigo descreve os pré-requisitos para configurar um cluster PostgreSQL no Serviço Kubernetes do Azure (AKS) e fornece uma visão geral do processo de implantação completo e da arquitetura.

Importante

O software de código aberto é mencionado em toda a documentação e amostras do AKS. O software que você implanta é excluído dos contratos de nível de serviço do AKS, da garantia limitada e do suporte do Azure. Ao usar a tecnologia de código aberto ao lado do AKS, consulte as opções de suporte disponíveis nas respetivas comunidades e mantenedores do projeto para desenvolver um plano.

A Microsoft assume a responsabilidade pela criação dos pacotes de código aberto que implantamos no AKS. Essa responsabilidade inclui ter a propriedade completa do processo de compilação, digitalização, assinatura, validação e correção rápida, juntamente com o controlo dos binários nas imagens de contentor. Para obter mais informações, consulte Gestão de vulnerabilidades para AKS e Cobertura de suporte AKS.

Pré-requisitos

Processo de implantação

Neste guia, você aprenderá a:

  • Use a CLI do Azure para criar um cluster AKS de várias zonas.
  • Implante um cluster e banco de dados PostgreSQL altamente disponíveis usando o operador CNPG.
  • Configure o monitoramento para PostgreSQL usando Prometheus e Grafana.
  • Implante um conjunto de dados de exemplo em um banco de dados PostgreSQL.
  • Execute atualizações de cluster PostgreSQL e AKS.
  • Simule uma interrupção de cluster e falha de replicação do PostgreSQL.
  • Execute backup e restauração de um banco de dados PostgreSQL.

Arquitetura de implantação

Este diagrama ilustra uma configuração de cluster PostgreSQL com uma réplica primária e duas réplicas de leitura gerenciadas pelo operador CloudNativePG (CNPG). A arquitetura fornece um PostgreSQL altamente disponível executado em um cluster AKS que pode resistir a uma interrupção numa zona realizando failover entre réplicas.

As cópias de segurança estão armazenadas no Armazenamento de Blobs do Azure, fornecendo outra maneira de restaurar o banco de dados no caso de um problema com a replicação em fluxo da réplica principal.

Você pode optar por hospedar o PostgreSQL no AKS quando precisar de controle total sobre a configuração do banco de dados, extensões e arquitetura de implantação. É ideal para integração total com ferramentas nativas do Kubernetes, otimizando custos em escala e ajustando o desempenho por meio de alocação de recursos personalizada, estratégias de cache e configurações de armazenamento adaptadas à sua carga de trabalho.

Diagrama de arquitetura do operador CNPG Kubernetes para auto-hospedagem de um banco de dados PostgreSQL altamente disponível no AKS.

Observação

Para aplicativos que exigem separação de dados no nível do banco de dados, você pode adicionar mais bancos de dados com comandos postInitSQL e similares. Atualmente, não é possível adicionar mais bases de dados de forma declarativa com o operador CNPG. Saiba mais sobre a operadora CNPG.

Considerações sobre armazenamento

O tipo de armazenamento que você usa pode ter grandes efeitos no desempenho do PostgreSQL. Mais adiante neste guia, você seleciona a opção mais adequada para seus objetivos e necessidades de desempenho.

Tipo de armazenamento Driver compatível Descrição
SSD Premium Driver CSI de Discos Azure Máxima resiliência de dados. O SSD Premium do Azure fornece armazenamento de alto desempenho e funciona perfeitamente com o armazenamento redundante de zona Premium (ZRS) do Azure. O SSD Premium é provisionado com base em tamanhos específicos, cada um oferecendo determinados IOPS e níveis de taxa de transferência.
SSD Premium v2 Driver CSI de Discos Azure Melhor preço-desempenho. O SSD Premium do Azure v2 oferece um desempenho mais elevado do que os SSD Premium do Azure e, ao mesmo tempo, é geralmente menos dispendioso. Ao contrário dos SSDs Premium, o SSD Premium v2 não tem tamanhos dedicados. Você pode definir um SSD Premium v2 para qualquer tamanho suportado que preferir e fazer ajustes granulares no desempenho sem tempo de inatividade. Os discos SSD Premium v2 do Azure têm certas limitações que você deve estar ciente. Para obter uma lista completa, consulte Limitações do SSD Premium v2.
NVMe local ou SSD temporário (discos efêmeros) Apenas Armazenamento de Contentores do Azure Máximo desempenho. Os discos temporários são armazenamento NVMe local e SSD temporário disponíveis em determinadas famílias de máquinas virtuais. Eles oferecem o maior número possível de IOPS, taxa de transferência elevada e latência de submilissegundos para o seu cluster AKS. Você também pode aproveitar o alto desempenho do Ephemeral Disks usando o Azure Container Storage, uma solução de armazenamento Kubernetes gerenciada que provisiona dinamicamente volumes persistentes para cargas de trabalho com monitoração de estado, como o PostgreSQL. No entanto, como esses discos residem nas VMs locais que hospedam o cluster, os dados não são persistidos para um serviço de armazenamento do Azure. Como resultado, todos os dados armazenados nesses discos serão perdidos se o cluster for interrompido ou deslocalizado. Para resolver essa limitação, as seções posteriores deste guia mostram como configurar backups periódicos de seus dados PostgreSQL para o Armazenamento de Blobs do Azure.

Próximos passos

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram-no originalmente:

  • Ken Kilty - Brasil | Principal TPM
  • Russell de Pina - Brasil | Principal TPM
  • Adrian Joian | Engenheiro de Clientes Senior
  • Jenny Hayes | Desenvolvedora de Conteúdo Sénior
  • Carol Smith | Desenvolvedora Sénior de Conteúdos
  • Erin Schaffer | Desenvolvedora de Conteúdo 2
  • Adam Sharif | Engenheiro de Clientes 2

Agradecimento

Esta documentação foi desenvolvida em conjunto com o EnterpriseDB, os mantenedores do operador CloudNativePG. Agradecemos a Gabriele Bartolini por ter revisado rascunhos anteriores deste documento e oferecido melhorias técnicas.