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) air-gapped. Ela permite que clientes corporativos e de acesso antecipado mantenham cargas de trabalho de banco de dados críticas de maneira confiável usando uma configuração robusta de máquina virtual (VM) multizonal.

Como o GDC com isolamento físico não oferece suporte a clusters de extensão 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 de zona completa sem perda de dados.

Recursos e funcionalidades

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

Princípios arquitetônicos

  • Consenso baseado em quórum:prioriza a consistência estrita dos dados. A replicação de grupos aplica um modelo baseado em Paxos que exige concordância da maioria, eliminando o risco de perda de dados ou split-brain durante partições de rede.
  • Separação de interesses:desvincula o mecanismo de banco de dados e a camada de consenso (replicação de grupos) da camada de roteamento de tráfego do cliente (MySQL Router), simplificando o gerenciamento do ciclo de vida do cluster usando o MySQL Shell.
  • Otimização da infraestrutura:projetada especificamente para ambientes air-gapped, usando VMs robustas para ignorar as limitações atuais de rede do Kubernetes.

Arquitetura

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

Conceitos e tecnologias

Esta seção detalha os componentes funcionais e as responsabilidades específicas deles na arquitetura multizonal.

Infraestrutura e plataforma

  • Máquinas virtuais (VMs) : três instâncias dedicadas do Compute Engine, cada uma implantada em uma zona de disponibilidade separada para formar os limites do domínio de falha.
  • GDC Global L4 Load Balancer: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 de grupos / cluster do InnoDB:o framework de clustering integrado responsável pela replicação multimestre e pela verificação do quórum de nós usando o Paxos.
  • MySQL Shell:a interface de linha de comando unificada usada especificamente para configurar, provisionar e administrar as instâncias de cluster do InnoDB.
  • MySQL Router: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 GDC Global L4 Load Balancer.
  2. O balanceador de carga faz o proxy da conexão com uma instância MySQL Router íntegra em uma das VMs.
  3. Com base na porta solicitada, o MySQL Router encaminha o tráfego dinamicamente: a porta 6446 segmenta estritamente o nó ativo para gravações, enquanto a porta 6447 faz a leitura de ciclos no cluster.

Considerações

  • Compensações de desempenho x consistência:como a replicação de grupos aplica o consenso, as transações exigem confirmação dos pares de cluster. O desempenho está diretamente correlacionado à latência da rede entre zonas no ambiente do GDC.
  • Gerenciamento de recursos:a implantação do MySQL Router diretamente nas VMs de banco de dados otimiza a utilização do hardware, mas exige 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 air-gapped não oferece suporte a 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 alta disponibilidade multizonal verdadeira e sobreviver a uma falha de zona total.
  • Cluster do InnoDB x Orchestrator e ProxySQL:uma arquitetura tradicional principal/secundária combinada com ProxySQL e 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 GDC Global L4 Load Balancer integrado 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 uniformemente em três zonas de disponibilidade.
  • Rede segura:o acesso baseado em chaves e as ProjectNetworkPolicies (PNPs) adequadas são estabelecidos para permitir a sincronização da replicação de grupos intracluster e o tráfego do MySQL Router.

Limitações

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

Outros recursos