Resumo

  • Uma atualização de configuração de rede do Google Cloud interrompeu clusters estendidos do VMware Engine em Sydney, Melbourne e Frankfurt por quase 12 horas
  • O processamento e o armazenamento continuaram disponíveis, mas falhas nos links entre as zonas de cluster e a testemunha deixaram algumas máquinas virtuais isoladas

O Fato

Uma atualização de configuração de rede do Google Cloud interrompeu os clusters estendidos do VMware Engine em Sydney, Melbourne e Frankfurt em 14 de julho. O incidente durou 11 horas e 46 minutos. O Google restaurou o serviço revertendo a configuração para o seu último valor em bom estado conhecido.

O Google informou que o processamento e o armazenamento pareceram continuar disponíveis, mas a comunicação entre as zonas de cluster falhou. As zonas afetadas também perderam o contato com o dispositivo de testemunha, impedindo que os clusters sincronizassem seu estado com segurança. Algumas máquinas virtuais ficaram isoladas e correram o risco de ficar sem dados graváveis. O Google aconselhou os clientes a consultarem o suporte antes de moverem as cargas de trabalho afetadas para o lado íntegro de um cluster.

A Avaliação

O incidente afetou clientes que utilizam clusters estendidos para manter a disponibilidade entre zonas. O processamento e o armazenamento continuaram funcionando, mas as conexões de rede e de testemunha necessárias para coordenar os clusters falharam. Para as equipes de nuvem e de continuidade empresarial, isso significou que as cargas de trabalho podiam continuar ativas enquanto o sistema responsável por manter ambos os lados sincronizados já não funcionava normalmente.

Os clusters estendidos do VMware Engine posicionam nós de dados em duas zonas e utilizam uma testemunha em uma terceira. Uma vez perdida a comunicação entre eles, algumas máquinas virtuais ficaram isoladas e correram o risco de perder o acesso a dados graváveis. O Google recomendou mover as cargas de trabalho afetadas para o lado íntegro, sempre que possível, mas também instou os clientes a consultarem o suporte devido aos riscos de failover e à incerteza sobre a condição da zona secundária. Portanto, a recuperação dependeu tanto do design do cluster quanto da resposta operacional do Google.

Para os leitores da BTW, distribuir cargas de trabalho entre zonas não torna cada parte do serviço independente. Os clientes ainda dependem da rede e do serviço de testemunha do provedor para manter essas zonas operando como um único cluster. Os planos de continuidade precisam abranger a perda desse caminho de comunicação, incluindo como as cargas de trabalho são movidas e quando o suporte do provedor é necessário.

O que Acompanhar

Acompanhe o relatório final de causa raiz do Google, as alterações em seus controles de atualização de rede e qualquer orientação de recuperação revisada para falhas que afetem a conectividade entre zonas ou com a testemunha.