Visão geral do AlloyDB Omni usando o orquestrador RPM

Selecione uma versão da documentação:

O AlloyDB Omni oferece uma plataforma de orquestração para implantar e gerenciar o AlloyDB Omni em ambientes não Kubernetes, por exemplo, no Red Hat Enterprise Linux (RHEL) e em sistemas compatíveis que usam pacotes do Red Hat Package Manager (RPM). A opção de implantação do orquestrador de RPM estende a flexibilidade e a automação semelhantes à nuvem para a infraestrutura local e de máquina virtual (VM).

O AlloyDB Omni usando o orquestrador RPM permite que empresas instalem, configurem e gerenciem instâncias do AlloyDB Omni usando pacotes RPM padrão. Essa abordagem é compatível com organizações que têm investimentos significativos em infraestrutura de VM e práticas operacionais estabelecidas criadas em torno de ferramentas de automação, como o Ansible. A opção de implantação do orquestrador RPM é executada diretamente em VMs Linux ou servidores bare metal sem exigir uma camada de conteinerização, como o Docker, ou um sistema de orquestração, como o Kubernetes.

Para começar a usar essa opção de implantação, solicite acesso usando o formulário de inscrição.

Casos de uso

A opção de implantação do orquestrador RPM é compatível com os seguintes casos de uso:

Caso de uso Descrição
Empresas com infraestrutura de VM Suporta empresas em que o Kubernetes não é padrão ou ambientes conteinerizados com dependências de aplicativos que preferem implantações padrão de VM ou bare metal.
Operações simplificadas Automatiza a implantação, a configuração e o gerenciamento do ciclo de vida de bancos de dados usando ferramentas conhecidas, como o Ansible.
Alta disponibilidade (HA) e recuperação de desastres (DR) Configura clusters resilientes do AlloyDB Omni com mecanismos automatizados de failover e recuperação.
Ambientes híbridos Garante operações de banco de dados consistentes em data centers locais e VMs na nuvem.
Integração de sistemas legados Integração com aplicativos e sistemas atuais projetados para ambientes não conteinerizados.

Vantagens

Os benefícios da opção de implantação do orquestrador de RPM incluem:

  • Implantação rápida: automatiza todo o ciclo de vida, do provisionamento à verificação, o que reduz significativamente o tempo e a complexidade da configuração de clusters do AlloyDB Omni.
  • Integração perfeita: integra-se nativamente ao gerenciamento de pacotes padrão do Linux (RPM) e a frameworks de automação conhecidos, como o Ansible, permitindo que as equipes usem habilidades e integrações de ferramentas atuais.
  • Experiência consistente: oferece uma experiência do usuário e um conjunto de atributos para gerenciamento e operações comparáveis ao operador do Kubernetes do AlloyDB Omni, que oferece consistência em diferentes modelos de implantação.
  • Alta disponibilidade (HA) e recuperação de desastres (DR) de nível empresarial: oferece suporte a configurações flexíveis para alta disponibilidade e recuperação de desastres, atendendo às necessidades de continuidade de negócios.
  • Segurança robusta: facilita a implementação de estratégias de segurança multifacetadas, incluindo gerenciamento de usuários, segurança de rede com certificados (SSL) e integração com sistemas, por exemplo, o Microsoft Active Directory.
  • Gerenciamento centralizado: usa o serviço do AlloyDB Omni para fornecer um plano de controle unificado para gerenciar o AlloyDB Omni em VMs.
  • Capacidade de observação e auditoria: permite a integração com servidores de geração de registros externos, como o Elastic Stack, usando o rsyslog para gerenciamento, monitoramento e auditoria centralizados de registros.
  • Proteção de dados: inclui recursos para configurações e estratégias simplificadas de backup e restauração.
  • Pool de conexões: oferece suporte à implantação do PgBouncer para otimizar as conexões de banco de dados e melhorar o desempenho.
  • Gerenciamento de frotas: permite gerenciar vários clusters do AlloyDB Omni em grande escala.

Arquitetura

O AlloyDB Omni define uma hierarquia de componentes que oferecem flexibilidade. Essa flexibilidade ajuda a maximizar a disponibilidade de dados e otimizar o desempenho e a capacidade de processamento das consultas. Essa abordagem permite monitorar a implantação do AlloyDB Omni e ajustar a escala e o tamanho dela para atender às suas cargas de trabalho.

A figura a seguir mostra a taxonomia da implantação do AlloyDB Omni em um ambiente bare-metal ou de VM.

Topologia de implantação de VM do AlloyDB Omni.

Fig. 1. Topologia de implantação de VM do AlloyDB Omni

O recurso de nível superior na hierarquia é uma implantação do AlloyDB Omni com um cluster primário e um ou mais clusters secundários. Um cluster do AlloyDB Omni tem uma ou mais instâncias, que são uma abstração dos recursos de computação a que os usuários se conectam. O cluster inclui uma instância principal (leitura e gravação) e uma ou mais instâncias de pool de leitura opcionais (somente leitura). Cada instância tem um endpoint de acesso próprio. Você pode configurar uma instância principal com um único nó para implantação independente ou vários nós para implantação de alta disponibilidade. Todos os nós têm o AlloyDB Omni e outros componentes relacionados implantados usando os pacotes de software.

A instância principal contém um nó ativo (leitura e gravação) projetado para processar cargas de trabalho transacionais. Para clusters de banco de dados além de testes básicos, experimentos e desenvolvimento, configure a alta disponibilidade com outros nós de espera. Para evitar perda de dados (RPO=0) em caso de falha que resulte na perda de disponibilidade de um nó principal que atende a transações de leitura e gravação, configure o modo de replicação sincronizada do nó de espera. O RPO é definido como objetivo do ponto de recuperação.

Componentes

A opção de implantação do orquestrador RPM inclui um conjunto de componentes de software, cada um instalado como pacotes RPM ou Debian, para uma implantação completa e altamente disponível do AlloyDB Omni. A arquitetura de referência depende desses componentes para operações de banco de dados.

Componente Descrição
Orquestrador A orquestração do AlloyDB Omni oferece interfaces de linha de comando e Ansible para ajudar você a implantar e gerenciar um ou mais clusters do AlloyDB Omni em um ambiente distribuído.
alloydbomni O núcleo do AlloyDB Omni inclui recursos do PostgreSQL e do Autopilot para melhorar o desempenho e as capacidades de suporte a cargas de trabalho modernas, como o processamento analítico on-line (OLAP) e a IA generativa.
alloydbomni_monitor Com o monitor do AlloyDB Omni, é possível extrair métricas do AlloyDB Omni.
etcd O etcd fornece um sistema de configuração distribuído que o gerenciador de cluster usa para armazenar informações de configuração e estado do PostgreSQL.
Gerente de cluster O plano de controle central orquestra operações em todo o cluster. Isso inclui a inicialização do cluster, o gerenciamento de alta disponibilidade, o tratamento de failover, a coordenação de upgrades e a exposição de interfaces para ferramentas de automação, por exemplo, Ansible e o utilitário de linha de comando alloydbctl.
Gerenciador de nós Um agente executado em cada nó do cluster do AlloyDB Omni. Ele interage com o gerenciador de clusters para executar tarefas no nó, por exemplo, instalar e configurar o AlloyDB Omni, gerenciar o ciclo de vida do serviço de banco de dados (iniciar e parar), monitorar a integridade do nó e coletar registros e métricas.
HAProxy O HAProxy funciona como um balanceador de carga para implantações do AlloyDB Omni. Ele expõe os endpoints de leitura/gravação e somente leitura. Ele funciona com o gerenciador de cluster para redirecionar o tráfego aos nós ativos adequados.
keepalived O keepalived pode fornecer alta disponibilidade para os nós participantes, por exemplo, HAProxy, usando um endereço IP virtual flutuante.
PgBouncer O PgBouncer é um pooler de conexões leve para bancos de dados PostgreSQL.
pgBackRest O pgBackRest é uma ferramenta de backup e restauração de código aberto projetada para o PostgreSQL.

Essa arquitetura permite executar e operar o AlloyDB Omni de maneira eficiente no ambiente de VM do Linux atual, combinando o AlloyDB Omni com a familiaridade das práticas operacionais estabelecidas.

Requisitos do sistema

Os requisitos do sistema para a pilha de implantação do AlloyDB Omni incluem um conjunto de máquinas virtuais pré-configuradas para executar vários componentes. Cada máquina virtual do AlloyDB Omni precisa ter um disco de dados anexado configurado com o sistema de arquivos ext4/xfs. O tamanho do disco é estimado com base no tamanho dos dados. As características de desempenho do armazenamento afetam o desempenho do AlloyDB Omni. A tabela a seguir mostra as configurações mínimas e recomendadas de CPU e memória para as VMs.

Tipo de VM Hardware e sistema operacional (SO) mínimos Hardware e SO recomendados
Nó do controlador
  • SO: RHEL9
  • CPU: x86-64 2 vCPUs com suporte a AVX2
  • RAM: 2 GB
  • Disco: 10 GB
  • SO: RHEL9
  • CPU: x86-64 8 vCPUs com suporte a AVX2
  • RAM: 8 GB
  • Disco: 20 GB ou mais
Nós do balanceador de carga
  • SO: RHEL9
  • CPU: x86-64 2 vCPUs com suporte a AVX2
  • RAM: 2 GB
  • Disco: 10 GB
  • SO: RHEL9
  • CPU: x86-64 16 vCPUs com suporte a AVX2
  • RAM: 8 GB
  • Disco: 20 GB ou mais
AlloyDB Omni (independente)
  • SO: RHEL9
  • CPU: x86-64 2 vCPUs com suporte a AVX2
  • RAM: 16 GB
  • Disco: 20 GB
  • Disco de dados: duas vezes o tamanho dos dados
  • SO: RHEL9
  • CPU: x86-64 64 vCPUs com suporte a AVX2
  • RAM: 8 GB por vCPU para o AlloyDB Omni
  • Disco: 20 GB
  • Disco de dados: duas vezes o tamanho dos dados
AlloyDB Omni (alta disponibilidade)
  • SO: RHEL9
  • CPU: x86-64 4 vCPUs com suporte a AVX2
  • RAM: 20 GB
  • Disco: 10 GB
  • Disco de dados: duas vezes o tamanho dos dados
  • SO: RHEL9
  • CPU: x86-64 64 vCPUs com suporte a AVX2
  • RAM: 8 GB ou mais por vCPU para o AlloyDB Omni
  • Disco: 20 GB
  • Disco de dados: duas vezes o tamanho dos dados
Nó do repositório de backup
  • SO: RHEL9
  • CPU: x86-64 2 vCPUs com suporte a AVX2
  • RAM: 2 GB
  • Disco: 10 GB
  • Disco de backup: N dias multiplicados pelo tamanho dos dados
  • SO: RHEL9
  • CPU: x86-64 8 vCPUs com suporte a AVX2
  • RAM: 8 GB
  • Disco: 20 GB
  • Disco de backup: N dias multiplicados pelo tamanho dos dados

Arquitetura de referência de implantação de alta disponibilidade

A arquitetura de alta disponibilidade oferece maior proteção contra o tempo de inatividade no nível de dados em comparação com configurações de banco de dados de nó único. Essa configuração de arquitetura de referência usa uma configuração de três nós com um nó como principal ativo e outros nós como servidores em espera replicados por streaming síncrono, implantados em zonas separadas. Se um nó principal falhar, um dos nós de espera vai assumir a função de principal para processar as consultas do cliente.

O componente gerenciador de cluster na pilha de software realiza a configuração do cluster. O gerenciador de cluster também monitora o servidor do AlloyDB Omni e escolhe o novo principal com a ajuda de um sistema de configuração distribuída, por exemplo, etcd. As empresas usam RPO e RTO (objetivo do tempo de recuperação) como as principais medidas de disponibilidade. A configuração da arquitetura de HA oferece RPO e RTO quase zero para falhas no nível da zona.

Um nó adicional implanta um balanceador de carga baseado em HAProxy, com endpoints extras configurados para cargas de trabalho somente leitura. O HAProxy funciona com o gerenciador de cluster para monitorar o nó ativo atual e alternar para o novo nó ativo se ocorrer um failover. Os clientes se conectam ao nó do HAProxy para realizar operações no banco de dados. A imagem a seguir mostra essa arquitetura de implantação de alta disponibilidade.

Arquitetura de implantação de alta disponibilidade do AlloyDB Omni.

Figura 2:arquitetura de implantação de HA

Orquestrador de RPM

O AlloyDB Omni usando o orquestrador RPM oferece uma plataforma de automação e um plano de controle para instalar, configurar e gerenciar clusters de banco de dados do AlloyDB Omni em um conjunto de VMs ou servidores bare metal. Isso inclui várias configurações de arquitetura de referência, por exemplo, alta disponibilidade (HA) independente, resiliente e escalonável.

O gerenciador de clusters do AlloyDB Omni fornece o plano de controle. Esse componente é o serviço principal que automatiza o gerenciamento e a alta disponibilidade do cluster do AlloyDB Omni para ajudar a controlar o ciclo de vida de ponta a ponta de um cluster do AlloyDB Omni. O plano de controle em si é altamente disponível e lida com vários cenários de falha.

A opção de implantação do orquestrador RPM é a interface remota para comunicação com o serviço gerenciador de clusters do AlloyDB Omni. O orquestrador é executado em um nó dedicado, chamado de nó de controle. Nesse nó, é possível gerenciar um ou mais clusters remotamente por um canal seguro. Para compatibilidade com seu ambiente, vários orquestradores do AlloyDB Omni estão disponíveis. Escolha um orquestrador adequado às suas necessidades de automação.

  • CLI do orquestrador do AlloyDB Omni (disponível como RPM): recomendada para ambientes que usam scripts shell para automatizar a implantação e o gerenciamento de clusters.
  • Orquestrador de RPM Ansible (disponível como uma coleção do Ansible): recomendado para ambientes que usam automação integrada baseada em Ansible e estão prontos para estender com chamadas a outras funções do Ansible. Exemplos de manuais do Ansible são fornecidos para permitir integração direta com manuais do Ansible atuais.

O orquestrador do AlloyDB Omni facilita as seguintes operações relacionadas ao cluster do AlloyDB Omni. O orquestrador baseado em Ansible fornece funções do Ansible para cada uma dessas operações. A linha de comando oferece um conjunto de comandos invocados usando um prompt ou scripts do shell.

  • Installation: instale vários componentes do cluster nos respectivos nós.
  • Bootstrap: configure e inicialize todos os componentes de acordo com as especificações deles.
  • Update: atualize os recursos para versões mais recentes ou configurações atualizadas.
  • Status: confira o status de todos os componentes ou serviços no cluster.
  • List: receba uma lista de recursos disponíveis implantados no cluster.
  • Delete: exclua recursos do cluster.

Os orquestradores usam um conjunto de especificações como entrada no formato YAML.

  • Especificação de implantação: é igual ao formato do inventário do Ansible que define a topologia do cluster de VM. Ele contém vários grupos de VMs, por exemplo, os seguintes, com as respectivas configurações.
    • primary_instance_nodes: nós dedicados para servidores de banco de dados do AlloyDB Omni.
    • cluster_manager_nodes: opcional. Nós que executam servidores do gerenciador de clusters do AlloyDB Omni. Se não houver nós dedicados do gerenciador de cluster, implante o gerenciador no primary_instance_nodes.
    • etcd_nodes: o gerenciador de cluster armazena metadados no etcd, que pode ser executado nos mesmos nós que os nós do gerenciador de cluster, se não especificado explicitamente.
    • load_balancer_nodes: são nós adicionais dedicados a um balanceador de carga baseado em HAProxy.
  • Especificação de recursos: um cluster consiste em um ou mais recursos de cluster a serem implantados e gerenciados, por exemplo, clusters de banco de dados e poolers de conexão. A especificação de recursos está no formato YAML e descreve os recursos a serem implantados no cluster.

Limitações

  • A versão de prévia é compatível apenas com o seguinte:
    • AlloyDB Omni PostgreSQL 18
    • Pacotes de software compatíveis com a versão 9 do RHEL
    • Plataforma Intel x86 de 64 bits
  • Não há suporte para upgrades de versão principal.
  • As instruções para configurar a recuperação de desastres e as instâncias do pool de leitura não estão incluídas.
  • O monitoramento do AlloyDB Omni não é compatível com conexões SSL. É necessário implantar os servidores do painel de monitoramento na mesma rede particular que os nós do AlloyDB Omni.
  • O AlloyDB Omni é compatível com o SELinux nos modos permissivo e de imposição. Configure o modo do SELinux selecionado antes de inicializar o cluster. Não é possível mudar para o modo de aplicação depois da inicialização.

A seguir