Manutenção do host na nuvem e live migration Cloud host maintenance / live migration
ID da causa nic-host-maintenance · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
Quando o provedor de nuvem faz manutenção em um servidor físico (host), ele move as VMs para outro host (live migration) ou as pausa por um momento. Nesse tempo o servidor inteiro para, e se a pausa for longa as conexões caem.
Por quê Por manutenção do host ou previsão de falha, o provedor move a VM para outro host ou a pausa por um instante → Efeito Durante a migração, CPU, memória e rede ficam lentas, e no final a VM para completamente por um instante (de menos de 1 segundo a cerca de 30 segundos, conforme o provedor e o método) → Na tela Todos no servidor travam ao mesmo tempo e depois vêm avanço rápido e teleporte; se a pausa passar do timeout, desconexões em massa
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Usar timeouts que aguentem pausas de alguns segundos, limitar quantos ticks o servidor recupera depois de uma pausa, calcular o tempo decorrido com monotonic clock, ter um procedimento que salve o progresso e mova os jogadores para outro servidor ao receber o aviso de manutenção.
O que fazer (Equipe de infraestrutura)
Assinar os avisos de manutenção e criar alertas (Google Cloud maintenance-event, eventos programados da AWS e AWS Health, Azure Scheduled Events), ao receber o aviso trocar o servidor com antecedência, em horário de poucos jogadores, ajustar o horário da manutenção quando o provedor permitir (Azure Maintenance Configuration, eventos programados da AWS conforme o tipo), cruzar os registros de manutenção com os registros de incidente.
O que fazer (Externo)
Confirmar com o provedor de nuvem o cronograma de manutenção e o alcance do impacto, reportar se a mesma instância pausa repetidamente.
Números de referência
O Google Compute Engine diz que a pausa da live migration costuma ser bem menor que 1 segundo, e durante a pausa o relógio do sistema pode saltar até 5 segundos para a frente. O valor de metadados maintenance-event muda 60 segundos antes da migração (se ele tiver sido consultado pelo menos uma vez antes). No Azure, manutenções que não exigem reboot pausam a VM quase sempre por menos de 10 segundos e raramente (no máximo uma vez a cada 18 meses nos tamanhos de uso geral) por cerca de 30 segundos, e a live migration em geral não passa de 5 segundos. O Azure Scheduled Events avisa dessas pausas (Freeze) com pelo menos 15 minutos de antecedência. Porém, se o hardware do host falhar de repente, a recuperação começa na hora, sem aviso.
No gráfico
Lacuna e depois tudo junto · Pacotes enviados e recebidos pelo servidor, intervalo entre ticks
Onde olhar
Cruzar o horário da parada com os registros do provedor. Google Cloud: compute.instances.migrateOnHostMaintenance nos logs de auditoria; AWS: eventos programados no describe-instance-status e no AWS Health; Azure: Microsoft.Compute/virtualMachines/liveMigration/action no log de atividades (Activity Log) e o horário em que a métrica de disponibilidade da VM (VmAvailabilityMetric) caiu a 0. Dentro do servidor, ver se as métricas e os logs ficaram vazios durante a parada e se o relógio saltou logo depois (logs de sincronização de horário)
Confirma se
O horário em que o servidor inteiro parou coincide com um horário de manutenção ou migração nos registros do provedor, e todas as métricas e logs dentro do servidor ficam vazios nesses poucos segundos
Descarta se
Não está nos registros do provedor e pausas curtas se repetem com frequência: “CPU steal (máquina virtual)”. Registros de reset da NIC no log do kernel: “Problemas de driver ou firmware da NIC”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
A AWS avisa por eventos programados (scheduled events). system-reboot significa que a instância será reiniciada e movida para um novo host; system-maintenance significa que uma manutenção de rede ou de energia pode afetá-la por um momento. Mesmo que a pausa dure só alguns segundos, os clientes que não receberam ACK dos pacotes enviados ao servidor nesse tempo vão dobrando a espera de retransmissão, então a conexão TCP pode continuar parada por mais tempo depois que a pausa acaba (“RTO do TCP e backoff exponencial”). Quando a VM volta da pausa, o relógio pode saltar e levar a um “Salto do relógio do sistema (step do NTP)”, e o health check do load balancer pode falhar e tirar o servidor de rotação por um tempo. Instâncias que não podem ser movidas (como as instâncias bare metal do Google Cloud) são paradas ou reiniciadas na manutenção.
Fontes
Live migration process during maintenance eventsGoogle Cloud A pausa da live migration costuma ser bem menor que 1 segundo; durante a pausa o relógio do sistema salta até 5 segundos para a frente; durante a migração, o desempenho de disco, CPU, memória e rede cai por um tempo; VMs que não fazem live migration são encerradas na manutenção (instâncias bare metal não têm suporte)
Query metadata server for maintenance event noticesGoogle Cloud O valor de metadados maintenance-event muda 60 segundos antes da live migration (se a VM está configurada para live migration e o valor foi consultado pelo menos uma vez depois da última manutenção)
Scheduled events for Amazon EC2 instancesAWS Tipos de eventos programados (system-reboot reinicia e move para um novo host; system-maintenance indica impacto breve por manutenção de rede ou de energia), avisos por e-mail e AWS Health, verificação com describe-instance-status, horário ajustável conforme o tipo
Maintenance and updatesMicrosoft Azure Manutenções sem reboot quase sempre pausam por menos de 10 segundos, raramente (no máximo uma vez a cada 18 meses nos tamanhos de uso geral) por cerca de 30 segundos, e a live migration em geral por até 5 segundos; o relógio é sincronizado automaticamente após a pausa; conexões TCP longas podem cair, ou a recuperação pode demorar mais porque o outro lado retransmite com backoff exponencial os dados enviados à VM pausada; o health check do load balancer marca a VM como não saudável em cerca de 10 segundos; confirmação por Microsoft.Compute/virtualMachines/liveMigration/action no log de atividades e pela VmAvailabilityMetric, que vai a 0 durante a pausa; escolha do horário de aplicação com Maintenance Configuration
Scheduled Events for Linux VMs in AzureMicrosoft Azure Freeze (pausa de alguns segundos; CPU e rede podem parar) é avisado com pelo menos 15 minutos de antecedência; em falhas de hardware do host, a recuperação começa na hora, sem prazo de aviso