A ordem de inicialização é um atraso, não uma dependência

Todo mundo configura a ordem de inicialização esperando que a segunda máquina aguarde a primeira ficar pronta. Ela não aguarda. Espera um número fixo de segundos e sobe do mesmo jeito, e por isso a ordem que funcionava no teste falha na manhã de uma queda de energia de verdade.

AtlasPVE ·

Este verbete responde a

  • proxmox ordem de inicialização
  • proxmox boot order não funciona
  • proxmox atraso de inicialização vm
  • proxmox ordem de desligamento
  • proxmox start order

O hospedeiro volta depois de uma queda de energia e metade do que deveria estar rodando não está. A máquina do banco de dados subiu, mas a aplicação na frente dela desistiu, ou um contêiner não conseguiu montar um armazenamento que outro contêiner ainda estava subindo. Nada quebrou e ninguém registrou um erro que valha a leitura. As peças simplesmente subiram na ordem errada.

É aqui que o formato da sua instalação, quem depende de quem, deixa de ser um desenho na sua cabeça e vira algo que a máquina de fato executa. Vale saber com precisão o que esse mecanismo faz, porque ele é mais estreito do que quase todo mundo supõe.

A frase que explica quase todas as surpresas

O atraso de inicialização é um intervalo, não uma condição.

Quando você dá um atraso a um convidado, o Proxmox VE inicia esse convidado, espera os segundos informados e passa ao próximo. Ele não verifica se a inicialização terminou dentro do convidado. Não verifica se algum serviço responde. Espera e segue.

Ou seja, o arranjo que está na sua cabeça, "a aplicação espera o banco de dados", nunca é o que fica configurado. O que fica configurado é "a aplicação sobe noventa segundos depois que mandaram o banco de dados subir". Num reinício de teste tranquilo os dois são indistinguíveis. Depois de uma queda real, quando os discos estão mais lentos, uma verificação de sistema de arquivos roda ou um convidado sobe em modo de recuperação, deixam de ser.

Quatro regras que vale conhecer antes de pôr números

O menor sobe primeiro e desliga por último. A ordem de desligamento é o inverso da de inicialização; não existe ajuste separado. Um convidado com ordem 1 é o primeiro a subir e o último a descer, que costuma ser exatamente o desejado para aquilo de que todo o resto depende.

Números iguais não são aleatórios. Convidados que compartilham a mesma ordem são adicionalmente ordenados por identificador crescente. Os empates são estáveis e previsíveis, e você não precisa dar um número único a cada convidado para ter comportamento repetível.

Convidados sem ordem sempre sobem depois dos que têm ordem. Isso é mais útil do que parece. Você não precisa numerar tudo. Numere as três ou quatro coisas que realmente precisam vir cedo e deixe o resto em paz.

A ordem vale para um hospedeiro, não para o cluster. Ela não consegue expressar "este convidado no nó A precisa subir antes daquele no nó B". No momento em que a dependência cruza a fronteira de um nó, esse mecanismo não tem nada a dizer.

A armadilha que aparece depois

Convidados gerenciados pela pilha de alta disponibilidade ignoram tanto o iniciar junto com o sistema quanto a ordem de inicialização. A rotina de subida e descida pula todos eles, porque quem decide quando rodam é o gerenciador de alta disponibilidade.

Essa morde tarde. Um hospedeiro único com ordem cuidadosamente ajustada funciona por um ano. Depois chega um segundo nó, alguns convidados passam para alta disponibilidade, e a ordem deles silenciosamente deixa de valer. Nada avisa, porque nada está errado; só mudou de mãos a responsabilidade.

O atraso que você realmente quer costuma ser outro

Um motivo comum para recorrer a atrasos por convidado é um recurso externo: um armazenamento de rede que precisa estar acessível antes que alguém o monte, ou um comutador que precisa de um instante. Comprar esse tempo espaçando convidados um a um é um caminho desajeitado, porque estica a sequência inteira.

Existe um ajuste separado por nó exatamente para isso: um atraso entre o fim da inicialização do hospedeiro e o primeiro convidado de início automático. Um número só, aplicado uma vez, no ponto onde a espera realmente pertence.

O número que ninguém ajusta até doer

O tempo limite de desligamento é por padrão 180 segundos por convidado. O Proxmox VE pede que o convidado desligue, espera, e se ao vencer o prazo ele ainda estiver rodando, é parado à força. Uma parada em bloco de todos os convidados tem seu próprio limite geral de três minutos antes de acontecer o mesmo.

Para uma máquina que grava em disco ao desligar, esse teto merece ser conferido de propósito, não descoberto durante uma falha. O padrão é generoso para a maioria dos convidados e curto demais para alguns, e esses poucos são exatamente aqueles em que uma parada forçada custa alguma coisa.

O que se vê na prática

No hospedeiro usado para verificar o comportamento descrito aqui havia nove convidados configurados e três marcados para subir com o sistema. Nenhum tinha ordem de inicialização.

Esse é o estado normal das coisas, e muitas vezes está tudo bem. Máquinas que não dependem umas das outras não precisam de ordem. O objetivo deste texto é mais estreito: se você já disse em voz alta que um convidado precisa que outro esteja no ar primeiro, essa frase hoje mora só na sua memória, e uma queda de energia não lê a sua memória.

O que o Atlas faz

O Atlas não reordena nada por você e não inventa um sistema de dependências em cima do que o Proxmox VE já tem. O que ele faz é tornar as relações visíveis em uma única imagem em vez de convidado por convidado, para que a pergunta "o que aqui realmente depende do quê" possa ser feita enquanto a máquina está calma, e não enquanto ela está voltando.

Ver o formato não o configura. Mas ninguém define uma ordem sensata para um arranjo que nunca viu desenhado.

Fontes

A documentação oficial do Proxmox. Em inglês, e é ela que dá a palavra final neste assunto.

Verbetes relacionados

Como isso aparece dentro do Atlas?

Ir para a página do produto