Esta página descreve as opções de alta disponibilidade no Google Distributed Cloud (apenas software) para VMware.
Funcionalidade essencial
Uma instalação apenas de software do Google Distributed Cloud para VMware inclui um cluster de administração e um ou mais clusters de utilizadores.
O cluster de administrador gere o ciclo de vida dos clusters de utilizadores, incluindo a criação, as atualizações, as upgrades e a eliminação de clusters de utilizadores. No cluster de administrador, o administrador principal gere os nós de trabalho do administrador, que incluem os principais do utilizador (nós que executam o plano de controlo dos clusters de utilizadores geridos) e os nós de suplementos (nós que executam os componentes de suplementos que suportam a funcionalidade do cluster de administrador).
Para cada cluster de utilizadores, o cluster de administrador tem um nó não de HA ou três nós de HA que executam o plano de controlo. O plano de controlo inclui o servidor da API Kubernetes, o programador do Kubernetes, o gestor de controladores do Kubernetes e vários controladores críticos para o cluster de utilizador.
A disponibilidade do plano de controlo do cluster de utilizadores é fundamental para as operações de cargas de trabalho, como a criação, o aumento e a diminuição da escala, e a rescisão de cargas de trabalho. Por outras palavras, uma falha de funcionamento do plano de controlo não interfere com as cargas de trabalho em execução, mas as cargas de trabalho existentes perdem as capacidades de gestão do servidor da API Kubernetes se o respetivo plano de controlo estiver ausente.
As cargas de trabalho e os serviços contentorizados são implementados nos nós de trabalho do cluster de utilizadores. Nenhum nó trabalhador único deve ser fundamental para a disponibilidade da aplicação, desde que a aplicação seja implementada com pods redundantes agendados em vários nós trabalhadores.
Ativar a alta disponibilidade
O vSphere e o Google Distributed Cloud oferecem várias funcionalidades que contribuem para a elevada disponibilidade (HA).
vSphere HA e vMotion
Recomendamos que ative as duas funcionalidades seguintes no cluster do vCenter que aloja os seus clusters do Google Distributed Cloud:
Estas funcionalidades melhoram a disponibilidade e a recuperação caso um anfitrião ESXi falhe.
O vCenter HA usa vários anfitriões ESXi configurados como um cluster para oferecer uma recuperação rápida de interrupções e HA rentável para aplicações em execução em máquinas virtuais. Recomendamos que aprovisione o cluster do vCenter com anfitriões adicionais e ative a monitorização de anfitriões do vSphere HA com Host Failure Response definido como Restart VMs. As suas VMs podem ser reiniciadas automaticamente noutros anfitriões disponíveis em caso de falha do anfitrião ESXi.
O vMotion permite a migração ao vivo sem tempo de inatividade de VMs de um anfitrião ESXi para outro. Para a manutenção planeada do anfitrião, pode usar a migração em direto do vMotion para evitar totalmente o tempo de inatividade da aplicação e garantir a continuidade operacional.
Cluster de administrador
O Google Distributed Cloud suporta a criação de clusters de administrador de alta disponibilidade (HA). Um cluster de administrador de HA tem três nós que executam componentes do plano de controlo. Para ver informações sobre os requisitos e as limitações, consulte o artigo Cluster de administrador de alta disponibilidade.
Tenha em atenção que a indisponibilidade do plano de controlo do cluster de administrador não afeta a funcionalidade do cluster de utilizador existente nem as cargas de trabalho em execução nos clusters de utilizador.
Existem dois nós suplementares num cluster de administrador. Se um estiver inativo, o outro pode continuar a publicar as operações do cluster de administrador. Para redundância,
o Google Distributed Cloud distribui serviços de suplementos críticos, como o kube-dns,
pelos dois nós de suplementos.
Se definir antiAffinityGroups.enabled como true no ficheiro de configuração do cluster de administrador, o Google Distributed Cloud cria automaticamente regras de antiafinidade do vSphere DRS para os nós do suplemento, o que faz com que sejam distribuídos por dois anfitriões físicos para HA.
Cluster de utilizadores
Pode ativar a HA para um cluster de utilizadores definindo masterNode.replicas como 3 no ficheiro de configuração do cluster de utilizadores. Se o cluster de utilizadores tiver o
Controlplane V2
ativado (recomendado), os 3 nós do plano de controlo são executados no cluster de utilizadores.
Os clusters de utilizadores de HA antigos que não têm o Controlplane V2 ativado
executam os três nós do plano de controlo no cluster de administrador. Cada nó do plano de controlo também executa uma réplica do etcd. O cluster de utilizadores continua a funcionar
enquanto existir um plano de controlo em execução e um quórum etcd. Um quórum do etcd requer que duas das três réplicas do etcd estejam a funcionar.
Se definir antiAffinityGroups.enabled como true no ficheiro de configuração do cluster de administrador, o Google Distributed Cloud cria automaticamente regras de antiafinidade do vSphere DRS para os três nós que executam o plano de controlo do cluster de utilizador.
Isto faz com que essas VMs sejam distribuídas por três anfitriões físicos.
O Google Distributed Cloud também cria regras de antiafinidade do vSphere DRS para os nós de trabalho no cluster de utilizadores, o que faz com que esses nós sejam distribuídos por, pelo menos, três anfitriões físicos. São usadas várias regras de antiafinidade do DRS por conjunto de nós do cluster de utilizadores com base no número de nós. Isto garante que os nós de trabalho podem encontrar anfitriões para serem executados, mesmo quando o número de anfitriões é inferior ao número de VMs no conjunto de nós do cluster de utilizadores. Recomendamos que inclua anfitriões físicos adicionais no cluster do vCenter. Configure também o DRS para ser totalmente automático, de modo que, caso um anfitrião fique indisponível, o DRS possa reiniciar automaticamente as VMs noutros anfitriões disponíveis sem violar as regras de anti-afinidade das VMs.
O Google Distributed Cloud mantém uma etiqueta de nó especial, onprem.gke.io/failure-domain-name, cujo valor é definido como o nome do anfitrião ESXi subjacente. As aplicações de utilizador que pretendem alta disponibilidade podem configurar regras com esta etiqueta como o topologyKey para garantir que os respetivos pods de aplicações estão distribuídos por diferentes VMs, bem como anfitriões físicos.podAntiAffinity
Também pode configurar vários conjuntos de nós para um cluster de utilizadores com diferentes
armazenamentos de dados e etiquetas de nós especiais. Da mesma forma, pode configurar podAntiAffinity
regras com essa etiqueta de nó especial como o topologyKey para alcançar uma maior
disponibilidade em caso de falhas do repositório de dados.
Para ter HA para cargas de trabalho do utilizador, certifique-se de que o cluster de utilizadores tem um número suficiente
de réplicas em nodePools.replicas, o que garante o número desejado de nós de trabalho do cluster de utilizadores em execução.
Pode usar arquivos de dados separados para clusters de administrador e clusters de utilizadores para isolar as respetivas falhas.
Balanceador de carga
Existem dois tipos de equilibradores de carga que pode usar para alta disponibilidade.
Balanceador de carga MetalLB integrado
Para o
balanceador de carga MetalLB integrado,
consegue a HA tendo mais do que um nó com enableLoadBalancer: true.
O MetalLB distribui os serviços pelos nós do equilibrador de carga, mas, para um único serviço, existe apenas um nó principal que processa todo o tráfego desse serviço.
Durante a atualização do cluster, existe algum tempo de inatividade quando os nós do equilibrador de carga são atualizados. A duração da interrupção da comutação por falha do MetalLB aumenta à medida que o número de nós do equilibrador de carga aumenta. Com menos de 5 nós, a interrupção ocorre no prazo de 10 segundos.
Balanceamento de carga manual
Com o equilíbrio de carga manual, configura o Google Distributed Cloud para usar um equilibrador de carga à sua escolha, como o F5 BIG-IP ou o Citrix. Configura a alta disponibilidade no equilibrador de carga e não no Google Distributed Cloud.
Usar vários clusters para recuperação de desastres
A implementação de aplicações em vários clusters em vários servidores vCenter pode oferecer uma maior disponibilidade global e limitar o raio de impacto durante as interrupções.
Esta configuração usa o cluster existente no centro de dados secundário para a recuperação de desastres, em vez de configurar um novo cluster. Segue-se um resumo de alto nível para o conseguir:
Crie outro cluster de administrador e cluster de utilizadores no centro de dados secundário. Nesta arquitetura de vários clusters, exigimos que os utilizadores tenham dois clusters de administrador em cada centro de dados e que cada cluster de administrador execute um cluster de utilizador.
O cluster de utilizadores secundário tem um número mínimo de nós de trabalho (três) e é uma espera ativa (sempre em execução).
As implementações de aplicações podem ser replicadas nos dois vCenters através da sincronização de configuração ou, em alternativa, pode usar uma cadeia de ferramentas de DevOps de aplicações (CI/CD, Spinnaker) existente.
Em caso de desastre, o cluster de utilizadores pode ser redimensionado para o número de nós.
Além disso, é necessária uma comutação de DNS para encaminhar o tráfego entre os clusters para o centro de dados secundário.