O Google Distributed Cloud foi concebido para limitar o âmbito das falhas e dar prioridade à funcionalidade essencial para a continuidade operacional. Este documento explica como a funcionalidade dos seus clusters é afetada quando ocorre uma falha. Estas informações podem ajudar a dar prioridade às áreas a resolver se tiver um problema.
A funcionalidade essencial do Google Distributed Cloud inclui as seguintes categorias:
- Executar cargas de trabalho: as cargas de trabalho existentes podem continuar a ser executadas. Esta é a consideração mais importante para manter a continuidade do negócio. Mesmo que o seu cluster tenha um problema, as cargas de trabalho existentes podem continuar a ser executadas sem interrupções.
- Gerir cargas de trabalho: pode criar, atualizar e eliminar cargas de trabalho. Esta é a segunda consideração mais importante para dimensionar as cargas de trabalho quando o tráfego aumenta, mesmo que o cluster tenha um problema.
- Gerir clusters de utilizadores: pode gerir nós, atualizar, fazer a atualização e eliminar clusters de utilizadores. Isto é menos importante do que as considerações sobre o ciclo de vida da aplicação. Se houver capacidade disponível nos nós existentes, a incapacidade de modificar os clusters de utilizadores não afeta as cargas de trabalho dos utilizadores.
- Gerir clusters de administrador: pode atualizar o cluster de administrador. Esta é a consideração menos importante porque o cluster de administrador não aloja nenhuma carga de trabalho do utilizador. Se o cluster de administrador tiver um problema, as cargas de trabalho da aplicação continuam a ser executadas sem interrupções.
As secções seguintes usam estas categorias de funcionalidade essencial para descrever o impacto de tipos específicos de cenários de falha.
Modos de falha
Os seguintes tipos de falhas podem afetar o desempenho dos clusters do Google Distributed Cloud.
Falha do anfitrião ESXi
Neste cenário de falha, um anfitrião ESXi que executa instâncias de máquinas virtuais (VMs) que alojam nós do Kubernetes pode deixar de funcionar ou ficar com a rede dividida.
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão dos clusters de utilizadores | Faça a gestão de clusters de 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 alojadas pelo anfitrião com falhas são interrompidos e são reagendados automaticamente para outras VMs em bom estado. Se as aplicações do utilizador tiverem capacidade de carga de trabalho adicional e estiverem distribuídas por vários nós, a interrupção não é observável pelos clientes que implementam novas tentativas. |
Se a falha do anfitrião afetar a VM do plano de controlo num cluster de utilizador não de HA ou mais do que uma VM do plano de controlo num cluster de utilizador de HA, ocorre uma interrupção. | Se a falha do anfitrião afetar a VM do plano de controlo ou as VMs de trabalho no cluster de administrador, ocorre uma interrupção. | Se a falha do anfitrião afetar a VM do plano de controlo no cluster de administrador, há uma interrupção. |
| Recuperação | O vSphere HA reinicia automaticamente as VMs em anfitriões em bom estado. | O vSphere HA reinicia automaticamente as VMs em anfitriões em bom estado. | O vSphere HA reinicia automaticamente as VMs em anfitriões em bom estado. | O vSphere HA reinicia automaticamente as VMs em anfitriões em bom estado. |
| Prevenção | Implemente cargas de trabalho de forma HA para minimizar a possibilidade de interrupção. | Use clusters de utilizadores de HA para minimizar a possibilidade de interrupção. | — | — |
Falha da VM
Neste cenário de falha, uma VM pode ser eliminada inesperadamente, um disco de arranque pode ficar danificado ou uma VM pode ser comprometida devido a problemas do sistema operativo.
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão dos clusters de utilizadores | Faça a gestão de clusters de 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 trabalho com falhas são interrompidos e são reagendados automaticamente para outras VMs em bom estado pelo Kubernetes. Se as aplicações do utilizador tiverem capacidade de carga de trabalho adicional e estiverem distribuídas por vários nós, a interrupção não é observável pelos clientes que implementam novas tentativas. |
Se a VM do plano de controlo num cluster de utilizador não de HA ou mais do que uma VM do plano de controlo num cluster de utilizador de HA falhar, ocorre uma interrupção. | Se a VM do plano de controlo ou as VMs de trabalho no cluster de administrador falharem, ocorre uma interrupção. | Se a VM do plano de controlo no cluster de administrador falhar, ocorre uma interrupção. |
| Recuperação | A VM com falhas é recuperada automaticamente se a reparação automática de nós estiver ativada no cluster de utilizador. | A VM com falhas é recuperada automaticamente se a autorreparação de nós estiver ativada no cluster de administrador. | A VM do trabalhador com falhas no cluster de administrador é recuperada automaticamente se a autorreparação de nós estiver ativada no cluster de administrador. Para recuperar a VM do plano de controlo do cluster de administrador, consulte o artigo Reparar a VM do plano de controlo do cluster de administrador. |
Para recuperar a VM do plano de controlo do cluster de administrador, consulte o artigo Reparar a VM do plano de controlo do cluster de administrador. |
| Prevenção | Implemente cargas de trabalho de forma HA para minimizar a possibilidade de interrupção. | Use clusters de utilizadores de HA para minimizar a possibilidade de interrupção. | — | — |
Falha de armazenamento
Neste cenário de falha, o conteúdo de um ficheiro VMDK pode ser danificado devido a um encerramento inesperado de uma VM, ou uma falha do repositório de dados pode causar a perda de dados do etcd e dos PersistentVolumes (PVs).
Falha do etcd
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão dos clusters de utilizadores | Faça a gestão de clusters de administrador | |
|---|---|---|---|---|
| Interrupção | Sem interrupções | 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 etcd num cluster de utilizadores não de HA ou mais de uma réplica etcd num cluster de utilizadores de HA falhar, ocorre uma interrupção. | Se o armazenamento etcd num cluster de utilizadores não de HA ou mais de uma réplica etcd num cluster de utilizadores de HA falhar, ocorre uma interrupção. Se a réplica do etcd num cluster de administrador falhar, ocorre uma interrupção. |
Se a réplica do etcd num cluster de administrador falhar, ocorre uma interrupção. |
| Prevenção | — | O Google Distributed Cloud oferece um processo manual para recuperar da falha. | O Google Distributed Cloud oferece um processo manual para recuperar da falha. | O Google Distributed Cloud oferece um processo manual para recuperar da falha. |
Falha de PV da aplicação do utilizador
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão dos clusters de utilizadores | Faça a gestão de clusters de administrador | |
|---|---|---|---|---|
| Interrupção | Possível interrupção | Sem interrupções | Sem interrupções | Sem interrupções |
| Explicação | As cargas de trabalho que usam o PV com falha são afetadas. Implemente cargas de trabalho de forma de HA para minimizar a possibilidade de interrupção. |
— | — | — |
Falha do balanceador de carga
Neste cenário de falha, uma falha do balanceador de carga pode afetar as cargas de trabalho do utilizador que expõem serviços do tipo LoadBalancer.
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão dos clusters de utilizadores | Faça a gestão de clusters de 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 ligação VIP do plano de controlo de administração. A interrupção do serviço pode durar até 2 segundos quando usa o Seesaw e até 300 segundos quando usa o F5. 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. |
|||
| Recuperação | A HA do Seesaw deteta automaticamente a falha e muda para a utilização da instância de cópia de segurança. O Google Distributed Cloud oferece um processo manual para a recuperação de uma falha do Seesaw. |
|||
Recuperar um cluster danificado
As secções seguintes descrevem como recuperar um cluster danificado.
Recuperação de falhas do anfitrião ESXi
O Google Distributed Cloud baseia-se no vSphere HA para fornecer recuperação em caso de falha do anfitrião ESXi. O vSphere HA pode monitorizar continuamente os anfitriões ESXi e reiniciar automaticamente as VMs noutros anfitriões quando necessário. Isto é transparente para os utilizadores do Google Distributed Cloud.
Recuperação de falhas de VMs
As falhas de VMs podem incluir o seguinte:
Eliminação inesperada de uma VM.
Corrupção do disco de arranque da VM, como um disco de arranque que se torna só de leitura devido a registos de diário de spam.
Falha no arranque da VM devido a problemas de configuração de rede ou de disco de baixo desempenho, como o facto de não ser possível arrancar a VM porque não lhe é possível atribuir um endereço IP.
Corrupção do sistema de ficheiros de sobreposição do Docker.
Perda da VM do plano de controlo do administrador devido a uma falha na atualização.
Problemas com o sistema operativo.
O Google Distributed Cloud oferece um mecanismo de recuperação automático para os nós suplementares de administrador, os planos de controlo do utilizador e os nós do utilizador. Esta funcionalidade de reparação automática de nós pode ser ativada por cluster de administrador e cluster de utilizador.
A VM do plano de controlo do administrador é especial no sentido em que não é gerida por um cluster do Kubernetes e a respetiva disponibilidade não afeta a continuidade da empresa. Para a recuperação de falhas de VMs do plano de controlo do administrador, contacte o apoio ao cliente do Google Cloud.
Recuperação de falhas de armazenamento
Algumas das falhas de armazenamento podem ser atenuadas pelo vSphere HA e vSAN sem afetar o Google Distributed Cloud. No entanto, determinadas falhas de armazenamento podem surgir ao nível do vSphere, o que provoca corrupção ou perda de dados em vários componentes do Google Distributed Cloud.
As informações com estado de um cluster e das cargas de trabalho do utilizador são armazenadas nos seguintes locais:
- etcd: cada cluster (cluster de administrador e cluster de utilizador) tem uma base de dados etcd que armazena o estado (objetos Kubernetes) do cluster.
- PersistentVolumes: usado por componentes do sistema e cargas de trabalho do utilizador.
Recuperação de corrupção ou perda de dados do etcd
O etcd é a base de dados usada pelo Kubernetes para armazenar todo o estado do cluster, incluindo manifestos de aplicações do utilizador. As operações do ciclo de vida da aplicação deixariam de funcionar se a base de dados etcd do cluster do utilizador estiver danificada ou perdida. As operações do ciclo de vida do cluster de utilizadores deixariam de funcionar se a base de dados etcd do cluster de administrador estiver danificada ou perdida.
O etcd não oferece um mecanismo integrado fiável para detetar a corrupção de dados. Tem de analisar os registos dos pods etcd se suspeitar que os dados etcd estão danificados ou foram perdidos.
Um pod etcd pendente/com erro/em ciclo de falhas nem sempre significa que os dados do etcd estão danificados ou perdidos. Pode dever-se a erros nas VMs que alojam os pods etcd. Só deve realizar a seguinte recuperação do etcd em caso de corrupção ou perda de dados.
Para poder recuperar (para um estado de cluster recente) de uma perda ou corrupção de dados do etcd, tem de fazer uma cópia de segurança dos dados do etcd após qualquer operação do ciclo de vida no cluster (por exemplo, criar, atualizar ou atualizar). Para fazer uma cópia de segurança dos dados do etcd, consulte os artigos Fazer uma cópia de segurança de um cluster de administrador e Fazer uma cópia de segurança de um cluster de utilizador.
A restauração dos dados do etcd leva o cluster a um estado anterior. Se for feita uma cópia de segurança antes de uma aplicação ser implementada e, em seguida, essa cópia de segurança for usada para restaurar o cluster, a aplicação implementada recentemente não é executada no cluster restaurado. Por exemplo, se usar a cópia instantânea do etcd de um cluster de administrador com uma cópia instantânea criada antes de criar um cluster de utilizador, o cluster de administrador restaurado tem o plano de controlo do cluster de utilizador removido. Por isso, recomendamos que faça uma cópia de segurança do cluster após cada operação crítica do cluster.
A falha de perda ou corrupção de dados do etcd pode ocorrer nos seguintes cenários:
Um único nó de um cluster etcd de três nós (cluster de utilizadores de HA) está permanentemente danificado devido a danos ou perda de dados. Neste caso, apenas um único nó está danificado e o quórum do etcd ainda existe. Este cenário pode ocorrer num cluster de HA, em que os dados de uma das réplicas do etcd estão danificados ou foram 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 o artigo Substituir uma réplica do etcd com falhas.
Dois nós de um cluster etcd de três nós (cluster de utilizadores de HA) estão permanentemente danificados devido a danos ou perda de dados. O quórum é perdido, pelo que a substituição das réplicas etcd com falhas por novas não ajuda. O estado do cluster tem de ser restaurado a partir dos dados da cópia de segurança. Para mais informações, consulte o artigo Restaurar um cluster de utilizadores a partir de uma cópia de segurança (HA).
Um cluster etcd de nó único (cluster de administrador ou cluster de utilizador não HA) está permanentemente danificado devido a danos ou perda de dados. O quórum é perdido, pelo que tem de criar um novo cluster a partir da cópia de segurança. Para mais informações, consulte o artigo Restaurar um cluster de utilizadores a partir de uma cópia de segurança (sem HA).
Recuperação de danos ou perdas de PVs de aplicações de utilizadores
Pode usar determinadas soluções de armazenamento de parceiros para fazer uma cópia de segurança e restaurar os PersistentVolumes da aplicação do utilizador. Para ver a lista de parceiros de armazenamento que foram qualificados para o Google Distributed Cloud, consulte Parceiros de armazenamento compatíveis com o GDC.
Recuperação de falhas do balanceador de carga
Para o balanceador de carga do Seesaw incluído, pode recuperar de falhas recriando o balanceador de carga. Para recriar o balanceador de carga, atualize o Seesaw para a mesma versão apresentada na documentação da versão 1.16 Atualizar o balanceador de carga para o cluster de administrador.
No caso de falhas do equilibrador de carga do cluster de administrador, o plano de controlo pode estar inacessível. Execute a atualização na VM do plano de controlo do administrador onde existe acesso ao plano de controlo.
Para equilibradores de carga integrados (F5), contacte o apoio técnico da F5.
Para o balanceador de carga MetalLB integrado, usa nós de cluster como balanceadores de carga. A reparação automática de nós não é acionada em problemas do equilibrador de carga. Pode seguir o processo manual para reparar o nó.
O que se segue?
Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud.
Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:
- Requisitos para abrir um registo de apoio ao cliente.
- Ferramentas para ajudar a resolver problemas, como registos e métricas.
- Componentes suportados, versões e funcionalidades do Google Distributed Cloud para VMware (apenas software).