Arquitetura de referência do banco de dados MySQL no GDC com isolamento físico

Esta arquitetura de referência fornece um framework conceitual para implantar e operar bancos de dados MySQL 8.4 altamente disponíveis e gerenciados pelo cliente no Google Distributed Cloud (GDC) com isolamento físico. Ele permite que clientes corporativos e de acesso antecipado mantenham de forma confiável cargas de trabalho de banco de dados críticas usando uma configuração robusta de máquina virtual (VM) multizona.

Como o GDC com isolamento físico não é compatível com clusters estendidos do Kubernetes entre zonas, essa arquitetura depende estritamente de VMs dedicadas implantadas em três domínios de disponibilidade para garantir operações contínuas e resistir a uma falha total de zona sem perda de dados.

Recursos e funcionalidades

  • Resiliência multizona: uma configuração altamente resiliente de três nós implantada em três zonas de disponibilidade distintas para proteção contra falhas de zona de infraestrutura única.
  • Alta disponibilidade e consenso automatizados: usa a replicação de grupo para clustering de consenso baseado em Paxos, fornecendo detecção automática de falhas, acordo de nós e sincronização global de dados sem cenários de split-brain.
  • Roteamento de tráfego inteligente: as instâncias do roteador MySQL colocalizadas gerenciam o roteamento de conexão. O roteador direciona as operações de gravação (por exemplo, porta 6446) estritamente para um nó principal ativo e balanceia a carga das operações de leitura (por exemplo, porta 6447) entre as réplicas sincronizadas.
  • Balanceamento de carga global: integra-se ao balanceador de carga global de camada 4 do GDC para fornecer um IP virtual (VIP) único e estável para aplicativos cliente, abstraindo a topologia de nó subjacente.

Princípios de arquitetura

  • Consenso baseado em quórum: prioriza a consistência estrita dos dados. A replicação de grupo aplica um modelo baseado em Paxos que exige um acordo majoritário, eliminando o risco de perda de dados ou de split-brain durante partições de rede.
  • Separação de responsabilidades: separa o mecanismo de banco de dados e a camada de consenso (replicação de grupo) da camada de roteamento de tráfego do cliente (MySQL Router), além de simplificar o gerenciamento do ciclo de vida do cluster usando o MySQL Shell.
  • Otimização de infraestrutura: projetada especificamente para ambientes com isolamento físico, usando VMs robustas para contornar as limitações atuais de rede do Kubernetes.

Arquitetura

Arquitetura de três VMs que executa uma pilha de serviços colocalizada.

Conceitos e tecnologias

Nesta seção, detalhamos os componentes funcionais e as responsabilidades específicas deles na arquitetura de várias zonas.

Infraestrutura e plataforma

  • Máquinas virtuais (VMs): três instâncias de computação dedicadas, cada uma implantada em uma zona de disponibilidade separada para formar os limites do domínio de falha.
  • Balanceador de carga L4 global do GDC: um constructo de rede gerenciado pela plataforma que expõe um VIP interno estável, avaliando automaticamente as verificações de integridade do MySQL Router para redirecionar o tráfego de entrada.

Serviços e lógica

  • MySQL 8.4: o mecanismo de banco de dados relacional principal.
  • Replicação em grupo / cluster do InnoDB: o framework de clustering integrado responsável pela replicação de vários mestres e pela verificação do quórum de nós usando o Paxos.
  • Shell do MySQL: a interface de linha de comando unificada usada especificamente para configurar, provisionar e administrar as instâncias do cluster do InnoDB.
  • Roteador MySQL: atua como o roteador de tráfego em cada VM. Configurado dinamicamente para detectar os metadados do cluster e encaminhar o tráfego: ativo/backup para gravações e round-robin para leituras.

Fluxo de dados e interfaces

  1. Os aplicativos enviam solicitações de banco de dados para o VIP do balanceador de carga global L4 do GDC.
  2. O balanceador de carga faz o proxy da conexão com uma instância íntegra do MySQL Router em uma das VMs.
  3. Com base na porta solicitada, o MySQL Router encaminha o tráfego de forma dinâmica: a porta 6446 é destinada estritamente ao nó ativo para gravações, enquanto a porta 6447 alterna as leituras no cluster.

Considerações

  • Compensações de desempenho x consistência: como a replicação de grupo impõe consenso, as transações exigem confirmação dos pares do cluster. O desempenho está diretamente correlacionado à latência de rede entre zonas no ambiente do GDC.
  • Gerenciamento de recursos: implantar o MySQL Router diretamente nas VMs do banco de dados otimiza o uso do hardware, mas requer um ajuste cuidadoso dos recursos para evitar que a sobrecarga do pool de conexões prejudique os processos principais do MySQL.

Decisão de design

  • Máquinas virtuais no Kubernetes: o GDC com isolamento físico não é compatível com clusters do Kubernetes que abrangem várias zonas físicas. Uma abordagem baseada em VM foi escolhida estritamente porque a implantação de VMs dedicadas em zonas separadas é o único método viável para alcançar uma verdadeira alta disponibilidade multizona e sobreviver a uma falha total de zona.
  • Cluster InnoDB x Orchestrator e ProxySQL: uma arquitetura principal/secundária tradicional combinada com o ProxySQL e o Orchestrator foi avaliada como uma alternativa viável. No entanto, o cluster do InnoDB integrado (replicação de grupos + MySQL Router + MySQL Shell) foi selecionado porque elimina a dependência de sobreposições de roteamento de terceiros e simplifica drasticamente a complexidade operacional em torno de failovers, mantendo o consenso diretamente no MySQL.
  • Balanceamento de carga global integrado à plataforma: o uso do balanceador de carga global de camada 4 integrado do GDC garante que o VIP seja controlado pelo plano de controle do GDC, mantendo o ponto de entrada resiliente e simplificando a entrega de tráfego entre zonas.

Suposições e limitações

Suposições

  • Disponibilidade da infraestrutura: os clientes têm cota de projeto suficiente para provisionar VMs dedicadas e dimensionadas corretamente e balanceadores de carga globais distribuídos de maneira uniforme em três zonas de disponibilidade.
  • Rede segura: o acesso baseado em chave e as ProjectNetworkPolicies (PNPs) adequadas são estabelecidos para permitir a sincronização da replicação de grupo intracluster e o tráfego do roteador MySQL.

Limitações

  • Kubernetes não compatível: os clientes que buscam estritamente soluções baseadas em contêineres/Kubernetes não podem alcançar a alta disponibilidade multizona até que os clusters estendidos sejam totalmente compatíveis com a plataforma.
  • Upgrades manuais necessários: ao contrário dos serviços gerenciados, essa solução coloca a responsabilidade pela aplicação de patches de rotina no nível do SO e pelos upgrades de versão secundária do banco de dados totalmente no cliente.
  • Sensibilidade à latência da rede: a replicação exige uma rede estável e de alta qualidade. O jitter de rede ou os picos de latência entre as zonas com isolamento físico vão atrasar proporcionalmente as operações de gravação no cluster do MySQL.

Outros recursos