O Google Distributed Cloud foi desenvolvido para limitar o escopo de falhas e priorizar recursos essenciais para a continuidade de negócios. Neste documento, explicamos como a funcionalidade dos clusters é afetada quando há uma falha. Essas informações podem ajudar você a priorizar áreas a serem resolvidas.
Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.A funcionalidade principal do Google Distributed Cloud inclui as seguintes categorias:
- Executar cargas de trabalho: as cargas de trabalho atuais podem continuar em execução. Essa é a consideração mais importante para manter a continuidade de negócios. Mesmo que o cluster tenha um problema, as cargas de trabalho atuais podem continuar em execução sem interrupção.
- Gerencie cargas de trabalho: é possível criar, atualizar e excluir cargas de trabalho. Essa é a segunda consideração mais importante para escalonar cargas de trabalho quando o tráfego aumenta, mesmo que o cluster tenha um problema.
- Gerenciar clusters de usuários: é possível gerenciar nós, atualizar, fazer upgrade e excluir clusters de usuários. Isso é menos importante do que as considerações sobre o ciclo de vida do aplicativo. Se houver capacidade disponível nos nós existentes, a incapacidade de modificar clusters de usuário não afetará as cargas de trabalho do usuário.
- Gerenciar clusters de administrador: é possível atualizar e fazer upgrade do cluster de administrador. Essa é a consideração menos importante, porque o cluster de administrador não hospeda cargas de trabalho do usuário. Se o cluster de administrador tiver um problema, as cargas de trabalho do seu aplicativo vão continuar em execução sem interrupções.
As seções a seguir usam essas categorias de funcionalidade principal para descrever o impacto de tipos específicos de cenários de falha.
Modos de falha
Os tipos de falhas a seguir podem afetar o desempenho dos clusters do Google Distributed Cloud.
Falha no host ESXi
Nesse cenário de falha, um host do ESXi que executa instâncias de máquina virtual (VM) que hospedam nós do Kubernetes pode parar de funcionar ou ser particionado pela rede.
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção | Possível interrupção e recuperação automática | Possível interrupção e recuperação automática | Interrupção e recuperação automática | Interrupção e recuperação automática |
| Explicação | Os pods em execução nas VMs hospedadas pelo host com falha são interrompidos e reprogramados automaticamente em outras VMs em bom estado. Se os aplicativos do usuário tiverem capacidade de carga de trabalho disponível e estiverem distribuídos entre vários nós, a interrupção não será observável por clientes que implementam novas tentativa. |
Se a falha do host afetar a VM do plano de controle em um cluster de usuário sem alta disponibilidade ou mais de uma VM de plano de controle em um cluster de usuário de alta disponibilidade, haverá interrupções. | Se a falha do host afetar a VM do plano de controle ou as VMs do worker no cluster de administrador, haverá interrupções. | Se a falha do host afetar a VM do plano de controle no cluster de administrador, haverá interrupções. |
| Recuperação | O vSphere HA reinicia automaticamente as VMs em hosts em bom estado. | O vSphere HA reinicia automaticamente as VMs em hosts em bom estado. | O vSphere HA reinicia automaticamente as VMs em hosts em bom estado. | O vSphere HA reinicia automaticamente as VMs em hosts em bom estado. |
| Prevenção | Implante as cargas de trabalho com HA para minimizar a possibilidade de interrupção. | Use clusters de usuários de alta disponibilidade para minimizar a possibilidade de interrupção. | — | — |
Falha na VM
Nesse cenário de falha, uma VM pode ser excluída inesperadamente, um disco de inicialização pode ser corrompido ou uma VM pode ser comprometida devido a problemas no sistema operacional.
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção | Possível interrupção e recuperação automática | Possível interrupção e recuperação automática | Interrupção e recuperação automática/manual | Interrupção e recuperação manual |
| Explicação | Os pods em execução nas VMs de worker com falha são interrompidos e são reprogramados automaticamente em outras VMs íntegras pelo Kubernetes. Se os aplicativos do usuário tiverem capacidade de carga de trabalho disponível e estiverem distribuídos entre vários nós, a interrupção não será observável por clientes que implementam novas tentativas. |
Se a VM do plano de controle em um cluster de usuário sem alta disponibilidade ou mais de uma VM de plano de controle em um cluster de usuário de alta disponibilidade falhar, haverá interrupção. | Se a VM do plano de controle ou as VMs do worker no cluster de administrador falharem, haverá interrupções. | Se a VM do plano de controle no cluster de administrador falhar, haverá interrupções. |
| Recuperação | A VM com falha é recuperada automaticamente se o reparo automático de nó estiver ativado no cluster de usuário. | A VM com falha é recuperada automaticamente se o reparo automático de nós estiver ativado no cluster de administrador. | A VM de worker com falha no cluster de administrador será recuperada automaticamente se o reparo automático de nós estiver ativado no cluster de administrador. Para recuperar a VM do plano de controle do cluster do administrador, consulte Como reparar a VM do plano de controle do cluster de administrador. |
Para recuperar a VM do plano de controle do cluster do administrador, consulte Como reparar a VM do plano de controle do cluster de administrador. |
| Prevenção | Implante as cargas de trabalho com HA para minimizar a possibilidade de interrupção. | Use clusters de usuários de alta disponibilidade para minimizar a possibilidade de interrupção. | — | — |
Falha no armazenamento
Nesse cenário de falha, o conteúdo em um arquivo VMDK pode ser corrompido devido à diminuição da potência de uma VM ou a uma falha no armazenamento de dados fazer com que dados etcd e PersistentVolumes (PVs) sejam perdidos.
Falha no etcd
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção | Sem interrupção | Possível interrupção e recuperação manual | Interrupção e recuperação manual | Interrupção e recuperação manual |
| Explicação | — | Se o armazenamento do etcd em um cluster de usuário que não seja de alta disponibilidade ou mais de uma réplica do etcd em um cluster de usuário de alta disponibilidade falharem, haverá interrupção. | Se o armazenamento do etcd em um cluster de usuário que não seja de alta disponibilidade ou mais de uma réplica do etcd em um cluster de usuário de alta disponibilidade falharem, haverá interrupção. Se a réplica do etcd em um cluster de administrador falhar, haverá interrupções. |
Se a réplica do etcd em um cluster de administrador falhar, haverá interrupções. |
| Prevenção | — | O Google Distributed Cloud tem um processo manual de recuperação de falha. | O Google Distributed Cloud tem um processo manual de recuperação de falha. | O Google Distributed Cloud tem um processo manual de recuperação de falha. |
Falha no PV do aplicativo do usuário
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção | Possível interrupção | Sem interrupção | Sem interrupção | Sem interrupção |
| Explicação | As cargas de trabalho que usam o PV com falha são afetadas. Implante as cargas de trabalho com HA para minimizar a possibilidade de interrupção. |
— | — | — |
Falha do balanceador de carga
Nesse cenário de falha, uma falha no balanceador de carga pode afetar as cargas de trabalho do usuário
que expõem serviços do tipo LoadBalancer.
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção e recuperação manual | ||||
| Explicação |
Há alguns segundos de interrupção até que o balanceador de carga em espera recupere a conexão VIP do plano de controle do administrador. A interrupção do serviço pode ser de até dois segundos ao usar o Seesaw e até 300 segundos ao usar F5. A duração da interrupção de failover do MetalLB aumenta à medida que o número de nós do balanceador de carga cresce. Com menos de cinco nós, a interrupção ocorre dentro de 10 segundos. |
|||
| Recuperação | A alta disponibilidade detecta a falha automaticamente e faz o failover para a utilização da instância de backup. O Google Distributed Cloud tem um processo manual de recuperação de uma falha do Seesaw. |
|||
Como recuperar um cluster corrompido
Veja nas seções a seguir como recuperar um cluster corrompido.
Recuperação de falhas de host ESXi
O Google Distributed Cloud utiliza o vSphere com alta disponibilidade para recuperar uma falha de host ESXi. O vSphere com alta disponibilidade pode monitorar continuamente os hosts ESXi e reiniciar as VMs automaticamente em outros hosts quando necessário. Isso é transparente para usuários do Google Distributed Cloud.
Recuperação de falhas de VM
As falhas de VM podem incluir o seguinte:
Exclusão inesperada de uma VM.
A corrupção do disco de inicialização da VM, como um disco que se torna somente leitura devido a registros do diário de spam.
Falha na inicialização da VM devido a problemas de configuração de disco ou rede de baixo desempenho, como uma em que a VM não pode inicializar porque um endereço IP não pode ser alocado para ela.
Corrupção do sistema do arquivo de sobreposição do Docker.
Perda de VM de plano de controle de administrador devido a uma falha de upgrade.
Problemas no sistema operacional.
O Google Distributed Cloud fornece um mecanismo de recuperação automática para os nós de complementos, planos de controle de usuário e nós de usuários. Esse recurso de reparo automático de nós pode ser ativado por cluster de administrador e pelo cluster do usuário.
A VM do plano de controle do administrador é especial porque não é gerenciada por um cluster do Kubernetes. Além disso, sua disponibilidade não afeta a continuidade de negócios. Para a recuperação de falhas de VMs do plano de controle do administrador, entre em contato com o Cloud Customer Care.
Recuperação de falhas de armazenamento
Algumas das falhas de armazenamento podem ser atenuadas pelo vSphere de alta disponibilidade e pela vSAN sem afetar o Google Distributed Cloud. No entanto, algumas falhas de armazenamento podem ocorrer no nível do vSphere causando corrupção ou perda de dados em vários componentes do Google Distributed Cloud.
As informações com estado de um cluster e cargas de trabalho do usuário são armazenadas nos seguintes locais:
- etcd: cada cluster (cluster de administrador e cluster de usuário) tem um banco de dados etcd que armazena o estado (objetos do Kubernetes) do cluster.
- PersistentVolumes: é usado por componentes do sistema e cargas de trabalho do usuário.
Recuperação de corrupção/perda de dados do etcd
O etcd é o banco de dados usado pelo Kubernetes para armazenar todo o estado do cluster, inclusive o manifesto do aplicativo do usuário. As operações de ciclo de vida do aplicativo seriam interrompidas se o banco de dados do etcd do cluster do usuário fossem corrompido ou perdido. As operações do ciclo de vida do cluster do usuário pararam de funcionar se o banco de dados etcd do cluster de administrador estava corrompido ou perdido.
O etcd não fornece um mecanismo integrado confiável para detectar corrupção de dados. Será preciso analisar os registros dos pods do etcd se você suspeitar que os dados do etcd estão corrompidos ou perdidos.
Um pod do etcd pendente/error/crash-looping nem sempre significa que os dados do etcd estão corrompidos ou perdidos. Isso pode ocorrer devido a erros nas VMs que hospedam os pods do etcd. Execute a recuperação do etcd a seguir somente para corrupção ou perda de dados.
Para conseguir se recuperar (em um estado de cluster recente) da corrupção ou perda de dados do etcd, é preciso fazer o backup dos dados do etcd após qualquer operação de ciclo de vida no cluster (por exemplo, criar, atualizar ou fazer upgrade). Para fazer backup dos dados do etcd, consulte Como fazer backup de um cluster de administrador e Como fazer backup de um cluster de usuário.
Como restaurar dados do etcd transforma o cluster em um estado anterior. Se um backup for feito antes de um aplicativo ser implantado e esse backup for usado para restaurar o cluster, o aplicativo implantado recentemente não será executado no cluster restaurado. Por exemplo, se você usar o snapshot do etcd de um cluster de administrador que é criado antes da criação de um cluster de usuário, o plano de administração restaurado terá o plano de controle do cluster do usuário. Portanto, recomendamos fazer backup do cluster após cada operação de cluster essencial.
A falha de corrupção ou perda de dados do etcd pode ocorrer nos seguintes cenários:
Um único nó de um cluster do etcd (cluster de HA) é permanentemente interrompido devido à corrupção ou perda de dados. Nesse caso, apenas um nó é interrompido e o quórum do etcd ainda existe. Esse cenário pode acontecer em um cluster de alta disponibilidade, em que os dados de uma das réplicas do etcd são corrompidos ou perdidos. O problema pode ser corrigido sem a perda de dados ao substituir a réplica do etcd com falha por uma nova em estado limpo. Para mais informações, consulte Como substituir uma réplica do etcd com falha.
Dois nós de um cluster de três nós do etcd (cluster de usuário de alta disponibilidade) são permanentemente corrompidos devido à corrupção ou perda de dados. Como o quórum foi perdido, a substituição das réplicas do etcd com falhas por novas não vai ajudar. O estado do cluster precisa ser restaurado dos dados de backup. Para mais informações, consulte Como restaurar um cluster de usuário de um backup (HA).
Um cluster do etcd de nó único (cluster de administrador ou cluster de usuário sem alta disponibilidade) é permanentemente corrompido devido à corrupção ou perda de dados. O quórum é perdido, então é preciso criar um novo cluster com base no backup. Para mais informações, consulte Como restaurar um cluster de usuário de um backup (sem alta disponibilidade).
Recuperação da perda ou perda do PV de aplicativo do usuário
É possível usar determinadas soluções de armazenamento de parceiros para fazer backup e restaurar PersistentVolumes de aplicativos do usuário. Para conferir a lista de parceiros de armazenamento qualificados para o Google Distributed Cloud, consulte Parceiros de armazenamento da GDC Ready.
Recuperação de falhas do balanceador de carga
Para o balanceador de carga Seesaw em pacote, é possível realizar a recuperação de falhas recriando o balanceador de carga. Para recriar o balanceador de carga, faça o upgrade da Seesaw para a mesma versão mostrada na documentação da versão 1.16 Como fazer upgrade do balanceador de carga para o cluster de administrador.
No caso de falhas do balanceador de carga do cluster do administrador, é possível que o plano de controle esteja fora de alcance. Execute o upgrade na VM do plano de controle do administrador onde há acesso ao plano de controle.
Para balanceadores de carga integrados (F5), entre em contato com o Suporte F5.
Para o balanceador de carga MetalLB em pacote, nós de cluster são usados como balanceadores de carga. O reparo automático de nós não é acionado em problemas do balanceador de carga. É possível realizar o processo manual para reparar o nó.