A configuração ficou somente leitura: por que o lugar onde ela vive é diferente

Você tenta editar um arquivo e a permissão é negada. Você é root. Há espaço no disco. Mesmo assim não consegue escrever.

Aqui não há nada quebrado. O lugar que você está olhando não é uma pasta comum, e ele recusa a escrita de propósito.

O lugar onde a configuração vive não é uma pasta

O Proxmox guarda as configurações de máquinas, as definições de armazenamento, as regras de firewall e as tarefas de backup em um só lugar. Parece um sistema de arquivos, tem pastas e arquivos, mas atrás dele fica um pequeno banco de dados, e esse banco é replicado para cada nó do cluster.

O motivo é simples: todos os servidores de um cluster precisam enxergar a mesma definição de máquina. Se você vai mover uma máquina de um servidor para outro, o outro lado já precisa saber como aquela máquina está definida. Se a configuração fosse um arquivo comum no disco de um servidor, os outros não saberiam dela.

Esse projeto tem três consequências, e as três aparecem no dia a dia.

Consequência um: sem maioria, a escrita é recusada

Se um servidor não enxerga a maioria do cluster, a escrita se fecha. A leitura continua, a escrita para.

Isso não é defeito, é decisão. Se a rede se partisse em duas e as duas metades pudessem escrever, a mesma máquina acabaria com duas definições diferentes. Quando a rede voltasse, ninguém saberia dizer qual está certa, e não haveria como juntar. Em vez disso o sistema escolhe isto: o lado que ficou em minoria para de escrever.

Como se conta uma maioria num cluster, e por que instalações de dois servidores são desconfortáveis, está em outro artigo. O que cabe acrescentar aqui é que essa regra de maioria se sente exatamente assim na prática: de repente não conseguir escrever.

Consequência dois: a mesma estrutura roda até num servidor sozinho

Mesmo sem cluster, essa estrutura está em pé. Um servidor sozinho já é uma maioria por si, então normalmente nada dá errado.

Mas se o serviço que fornece essa estrutura não estiver saudável, você verá o mesmo sintoma também num servidor sozinho. Ou seja, "eu não tenho cluster, isso não acontece comigo" não está certo.

Há ainda um caminho menos conhecido: o banco de dados por trás dessa estrutura fica no disco local. Quando o disco local enche, as escritas falham e para você parece que não dá para mudar as configurações. O sintoma está do lado da configuração, a causa do lado do armazenamento.

Consequência três: tudo que você escreve ali vai para todos

Não existe a opção "vou mudar só nesta máquina". O que se escreve ali chega a cada nó do cluster.

O erro clássico, cometido sem saber disso, é fazer uma mudança de teste em um nó supondo que ela não afeta os outros.

Outro ponto: aquele lugar foi projetado para configuração, não para dados. Arquivos de texto pequenos pertencem ali; scripts, arquivos compactados e backups não. Não crie o hábito de deixar arquivos ali.

Se você não consegue escrever, verifique em ordem

Verifique primeiro a maioria: o servidor enxerga o resto do cluster? Se não enxerga, o problema real está na rede e o arquivo de configuração é inocente.

Depois verifique o serviço: o serviço que fornece essa estrutura está rodando?

Depois verifique o disco local: se estiver cheio, o caminho acima está em jogo.

E o último, o mais pulado: um nó pode ter saído do cluster. Uma queda de rede, um vizinho desligado, uma regra de firewall mal configurada. O sintoma sempre parece o mesmo, a causa está em outro lugar a cada vez.

O que o Atlas faz

O Atlas lê essa estrutura diretamente como arquivos, em vez de rodar a ferramenta de consulta do sistema toda vez.

Medimos o porquê. Cada chamada àquela ferramenta custa entre cem e duzentos milissegundos de processador e cerca de cem megabytes de memória temporária. Com o painel aberto há uma atualização a cada dez segundos, e cada atualização precisa de oito a dez chamadas. Ou seja, o monitoramento produzia uma oscilação constante justamente no servidor que monitorava.

Ler a mesma informação de um arquivo leva microssegundos. A diferença é de milhares de vezes, e essa diferença aparece na máquina do usuário como estabilidade.

O segundo detalhe é mais elegante: dentro dessa estrutura existe um contador de mudança que avança sempre que a configuração muda. O Atlas o observa. Assim, no instante em que uma configuração é alterada pelo painel, o cache se atualiza sozinho; perguntar pouco e nunca mostrar informação velha se tornam possíveis ao mesmo tempo.

Essa é outra face de um princípio escrito em outras partes desta wiki: aquilo que observa não deve ser aquilo que custa. O erro mais fácil de uma ferramenta de monitoramento é frear o sistema que observa e, com isso, distorcer justamente o número que mede.