O Google Distributed Cloud foi projetado para limitar o escopo de falhas e priorizar funcionalidades essenciais para a continuidade dos 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 dos 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 nenhuma carga de trabalho do usuário. Se o cluster de administrador tiver um problema, as cargas de trabalho do aplicativo continuarão sendo executadas sem interrupção.
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 falha a seguir podem afetar o desempenho dos clusters do Google Distributed Cloud.
Falha no host ESXi
Nesse cenário de falha, um host ESXi que executa instâncias de máquina virtual (VM) que hospeda nós do Kubernetes pode parar de funcionar ou se tornar particionado de 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 executados nas VMs hospedadas pelo host com falha são interrompidos e reprogramados automaticamente em outras VMs íntegras. 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 do 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 executados nas VMs de worker com falha são interrompidos e 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 ao desligamento incorreto de uma VM, ou uma falha no armazenamento de dados pode causar a perda de dados etcd e PersistentVolumes (PVs).
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 fornece um processo manual para se recuperar de falhas. | O Google Distributed Cloud fornece um processo manual para recuperação após uma falha. | O Google Distributed Cloud fornece um processo manual para recuperação após uma 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é 2 segundos ao usar o Seesaw e a 300 segundos ao usar F5. A duração da interrupção de failover do MetalLB cresce à medida que o número de nós do balanceador de carga aumenta. Com menos de cinco nós, a interrupção ocorre em até 10 segundos. |
|||
| Recuperação | A alta disponibilidade do Seesaw detecta automaticamente a falha e passa a usar a instância de backup. O Google Distributed Cloud fornece um processo manual para recuperação após uma falha no 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 depende da alta disponibilidade do vSphere para fornecer recuperação de uma falha do host ESXi. A alta disponibilidade do vSphere pode monitorar continuamente hosts ESXi e reiniciar automaticamente as VMs em outros hosts quando necessário. Isso é transparente para os 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.
Corrupção do disco de inicialização de VMs, como um disco de inicialização que se torna somente leitura devido a registros de diário de spam.
Falha na inicialização da VM devido a problemas de configuração de disco ou configuração de rede de baixo desempenho. Por exemplo, uma VM não consegue inicializar porque um endereço IP não pode ser alocado a 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 complementares do administrador, os planos de controle do usuário e os nós do usuário. 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 dos negócios. Para recuperação de falhas de VM 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 pela alta disponibilidade do vSphere e pela vSAN sem afetar o Google Distributed Cloud. No entanto, algumas falhas de armazenamento podem aparecer 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 (de administrador e de usuário) tem um banco de dados etcd que armazena o estado (objetos do Kubernetes) do cluster.
- PersistentVolumes: usados 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, em seguida, 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 corrupção ou perda de dados do etcd pode acontecer 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 perda de dados, substituindo a réplica do etcd com falha por uma nova no 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. O quórum é perdido, portanto, substituir as réplicas do etcd com falha por novas não ajuda. 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 ver a lista de parceiros de armazenamento que foram qualificados para o Google Distributed Cloud, consulte Parceiros de armazenamento da Anthos 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 Seekaw para a mesma versão, conforme mostrado em Como fazer upgrade do balanceador de carga para seu 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 em que há o acesso ao plano de controle.
Para balanceadores de carga integrados (F5), entre em contato com o suporte da 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. Siga o processo manual para reparar o nó.