Cluster existe, entre outras razões, para que manutenção deixe de ser evento. Trocar um disco, atualizar firmware, aplicar correção de segurança ou substituir um módulo de memória deveria acontecer durante o expediente, com as VMs rodando em outro lugar, sem comunicado a ninguém.
Na prática, muita equipe com cluster montado continua agendando janela noturna — porque nunca esvaziou um nó e não sabe se vai funcionar. Este é o roteiro que transforma manutenção em rotina.
Antes de tudo: as verificações que evitam surpresa
Executadas com antecedência, não no dia:
- O cluster está saudável? Todos os nós presentes, quórum estabelecido, nenhum alerta pendente. Manutenção em cluster já degradado é como operar com uma mão amarrada.
- O storage está saudável? Ceph sem alerta e com recuperação concluída; ZFS sem disco em falha; replicações em dia. Se o storage já está em recuperação, esvaziar um nó adiciona carga exatamente onde não deveria.
- Há capacidade nos outros nós? Some CPU e memória das VMs do nó alvo e confirme que cabem. Esta é a verificação que mais falha em cluster operando cheio.
- Quais VMs não migram? Dispositivo repassado, disco local muito grande, tipo de CPU incompatível. Essas precisam de decisão específica: parada planejada, migração a frio, ou adiamento da manutenção delas.
- Backup recente e válido de tudo que está no nó.
- Quanto tempo leva esvaziar? Se você já cronometrou antes, sabe. Se não, a manutenção não deveria ser a primeira vez.
Esse último ponto merece destaque: ensaie o esvaziamento antes de precisar dele. Faça uma vez por trimestre, sem manutenção nenhuma — só para medir e descobrir os problemas com calma.
O modo de manutenção
O Proxmox tem um estado de nó que muda o comportamento do HA: ao colocar o nó em manutenção, as VMs gerenciadas por alta disponibilidade são migradas automaticamente para os outros nós, e o nó deixa de receber novas.
É melhor que migrar na mão, por duas razões: o HA registra que aquelas VMs estavam ali, e ao sair do modo de manutenção elas podem voltar, o que preserva a distribuição planejada do cluster.
As VMs não gerenciadas por HA não são movidas automaticamente. Elas precisam ser migradas manualmente — e é uma boa oportunidade para revisar por que não estão sob HA.
O roteiro
Preparação (dias antes)
- Verificações acima executadas e registradas.
- Janela definida, ainda que a expectativa seja de zero impacto.
- Comunicação enviada às partes interessadas, incluindo as VMs que terão parada real.
- Peça de reposição em mãos, se for troca de hardware.
- Acesso ao console fora de banda testado — não descoberto no dia.
- Plano de volta escrito: o que fazer se o nó não voltar.
Esvaziamento (dia da manutenção)
- Confirmar novamente a saúde do cluster e do storage.
- Colocar o nó em modo de manutenção.
- Acompanhar a migração das VMs de HA.
- Migrar manualmente as demais.
- Tratar as VMs que não migram, conforme decidido.
- Confirmar que o nó está vazio.
- Confirmar que as VMs migradas estão saudáveis nos destinos — não apenas ligadas. Serviço respondendo.
A manutenção
- Executar o trabalho.
- Se envolver reinício, acompanhar pelo console fora de banda.
Retorno
- Nó volta e entra no cluster; confirmar quórum.
- Confirmar acesso ao storage — todos os storages montados e acessíveis.
- Confirmar rede: todas as interfaces ativas, bonding correto, VLANs presentes.
- Verificar versões, se houve atualização de pacotes.
- Sair do modo de manutenção.
- Rebalancear as VMs, ou deixar o HA devolvê-las.
- Período de observação antes de considerar concluído.
- Registrar o que foi feito e o que foi aprendido.
O passo 18 é o mais esquecido e o que mais causa problema depois: um nó que voltou com uma interface de bonding inativa funciona normalmente até o outro caminho falhar — e aí a redundância que você achava ter não existe.
Atualização de pacotes: cuidados específicos
Quando a manutenção é aplicar atualizações:
- Um nó por vez, sempre. Nunca todos em paralelo.
- Leia as notas da versão em mudança de versão maior. Elas avisam sobre passos manuais e incompatibilidades.
- Não deixe o cluster com nós em versões muito divergentes por longos períodos. Divergência causa comportamento estranho em migração e em HA. Termine o ciclo em dias, não em meses.
- Valide o nó atualizado com uma VM de teste antes de seguir para o próximo. Se houver regressão, você descobre com um nó comprometido em vez de todos.
- Homologação recebeu antes? Se você mantém laboratório, ele deveria ter rodado a mesma atualização dias antes.
Troca de disco
Caso específico e frequente, com detalhes que importam:
Com Ceph: marque o OSD como fora do cluster e aguarde a redistribuição terminar antes de remover fisicamente o disco. Remover durante a recuperação reduz a redundância abaixo do esperado. Verifique também se há capacidade para absorver os dados do disco removido — pool cheio impede a recuperação.
Com ZFS: identifique fisicamente o disco correto antes de tocar em qualquer coisa. Remover o disco errado de um pool degradado transforma um problema em um desastre. Use identificação por número de série e, se o gabinete permite, acenda o indicador luminoso do disco alvo.
Em ambos: acompanhe a reconstrução até o fim antes de dar a manutenção por concluída. Redundância durante a reconstrução está reduzida, e é o período de maior risco.
O plano de volta
O item que separa manutenção profissional de otimismo:
- Se o nó não voltar, as VMs já estão distribuídas nos outros. Você tem tempo. Mas confirme que os outros nós aguentam a carga indefinidamente, não só durante a janela.
- Se a atualização causou regressão, qual é o caminho? Reversão de pacote é possível em alguns casos e não em todos — o caminho confiável é restaurar o nó a partir da configuração versionada.
- Se o storage não voltar, há procedimento? É o cenário mais grave e o que mais merece ter resposta escrita.
- Até quando você tenta consertar antes de desistir e reconstruir o nó? Definir esse limite antes evita as quatro horas de tentativa que poderiam ter sido trinta minutos de reinstalação.
O que fazer com as VMs que não migram
Elas existem em todo ambiente, e a decisão precisa ser consciente:
- Dispositivo repassado (GPU, placa dedicada): migração a frio é a opção — desligar, migrar, ligar. Rápida se o storage é compartilhado. Exige janela real para aquela VM.
- Disco local grande: avalie migrar com antecedência, fora da janela, já que a cópia é demorada mas não impacta.
- Tipo de CPU incompatível: corrija na próxima parada programada daquela VM, ajustando para um modelo comum. Não deixe para descobrir de novo.
Mantenha uma lista viva dessas VMs, com o motivo. Ela é consultada em toda manutenção e evita descobrir o problema no meio do processo.
A frequência que mantém a capacidade
Manutenção que não é exercitada deixa de ser confiável. Uma cadência que funciona:
- Mensal: atualizações de segurança, nó a nó.
- Trimestral: ensaio de esvaziamento cronometrado, mesmo sem manutenção a fazer.
- Semestral: firmware de servidor, switch e BMC.
- Anual: revisão do roteiro e do plano de volta.
O item trimestral é o mais valioso e o mais fácil de abandonar por falta de tempo.
Erros comuns
- Nunca ter esvaziado um nó e descobrir na urgência.
- Fazer manutenção com cluster ou storage já degradado.
- Cluster operando cheio, sem capacidade para absorver o nó esvaziado.
- Não saber quais VMs não migram.
- Não testar o console fora de banda antes.
- Atualizar vários nós em paralelo.
- Deixar o cluster com versões divergentes por meses.
- Não validar o nó atualizado antes de seguir para o próximo.
- Remover disco de Ceph antes de a redistribuição terminar.
- Identificar o disco errado em pool ZFS degradado.
- Não conferir bonding e VLANs no retorno do nó.
- Considerar concluído sem período de observação.
- Nenhum plano de volta e nenhum limite de tempo para desistir.
- Não registrar o que foi feito.
Onde a Solvefy/Cloud entra
Como parceiros oficiais Proxmox, escrevemos e executamos esse roteiro com o seu time: verificações prévias, inventário das VMs que não migram com o motivo de cada uma, ensaio de esvaziamento cronometrado para você conhecer a sua janela real, procedimento de retorno com validação de storage, rede e bonding, e plano de volta com limite de tempo definido. Também assumimos a execução das janelas, se preferir que a manutenção deixe de consumir as noites da sua equipe.
Você consegue esvaziar um nó agora, no meio do expediente? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.