La configuration est passée en lecture seule : pourquoi son lieu de vie est différent

Vous essayez de modifier un fichier et la permission est refusée. Vous êtes root. Il y a de la place sur le disque. Vous ne pouvez toujours pas écrire.

Rien n'est cassé ici. L'endroit que vous regardez n'est pas un répertoire normal, et il refuse l'écriture volontairement.

L'endroit où vit la configuration n'est pas un répertoire

Proxmox garde les configurations de machines, les définitions de stockage, les règles de pare-feu et les tâches de sauvegarde au même endroit. Cela ressemble à un système de fichiers, avec des dossiers et des fichiers, mais derrière se trouve une petite base de données, et cette base est répliquée sur chaque nœud du cluster.

La raison est simple : tous les serveurs d'un cluster doivent voir la même définition de machine. Si vous voulez déplacer une machine d'un serveur à un autre, l'autre côté doit déjà savoir comment cette machine est définie. Si la configuration était un fichier ordinaire sur le disque d'un serveur, les autres l'ignoreraient.

Cette conception a trois conséquences, et les trois se présentent au quotidien.

Conséquence une : sans majorité, l'écriture est refusée

Si un serveur ne voit pas la majorité du cluster, l'écriture se ferme. La lecture continue, l'écriture s'arrête.

Ce n'est pas une panne, c'est une décision. Si le réseau se coupait en deux et que les deux moitiés pouvaient écrire, la même machine finirait avec deux définitions différentes. Au retour du réseau, personne ne pourrait dire laquelle est la bonne, et il n'y aurait aucun moyen de fusionner. À la place le système choisit ceci : le côté resté minoritaire cesse d'écrire.

Comment se compte une majorité dans un cluster, et pourquoi les installations à deux serveurs sont délicates, est traité dans un autre article. La seule chose à ajouter ici : c'est exactement ainsi que cette règle de majorité se ressent en pratique, ne plus pouvoir écrire d'un coup.

Conséquence deux : la même structure tourne même sur un serveur seul

Même sans cluster, cette structure tourne. Un serveur seul est à lui seul une majorité, donc normalement rien ne cloche.

Mais si le service qui fournit cette structure n'est pas sain, vous verrez le même symptôme sur un serveur seul aussi. Donc « je n'ai pas de cluster, ça ne peut pas m'arriver » est faux.

Il existe aussi un chemin moins connu : la base de données derrière cette structure se trouve sur le disque local. Quand le disque local se remplit, les écritures échouent et vous avez l'impression de ne pas pouvoir changer les réglages. Le symptôme est du côté configuration, la cause du côté stockage.

Conséquence trois : tout ce que vous écrivez là va à tout le monde

L'option « je ne le change que sur cette machine » n'existe pas. Ce qui est écrit là atteint chaque nœud du cluster.

L'erreur classique, faite sans le savoir, est d'apporter une modification d'essai sur un nœud en supposant qu'elle n'affecte pas les autres.

Autre point : cet endroit a été conçu pour de la configuration, pas pour des données. Les petits fichiers texte y ont leur place ; les scripts, les archives et les sauvegardes non. Ne prenez pas l'habitude d'y laisser des fichiers.

Si vous ne pouvez plus écrire, vérifiez dans l'ordre

Vérifiez d'abord la majorité : le serveur voit-il le reste du cluster ? S'il ne le voit pas, le vrai problème est dans le réseau et le fichier de configuration est innocent.

Vérifiez ensuite le service : le service qui fournit cette structure tourne-t-il ?

Vérifiez ensuite le disque local : s'il est plein, le chemin ci-dessus est en jeu.

Et le dernier, le plus souvent sauté : un nœud a peut-être quitté le cluster. Une coupure réseau, un voisin éteint, une règle de pare-feu mal configurée. Le symptôme a toujours la même allure, la cause est ailleurs à chaque fois.

Ce que fait Atlas

Atlas lit cette structure directement comme des fichiers, au lieu de lancer à chaque fois l'outil de requête du système.

Nous avons mesuré pourquoi. Chaque appel à cet outil coûte entre cent et deux cents millisecondes de processeur et environ cent mégaoctets de mémoire temporaire. Avec le panneau ouvert, il y a un rafraîchissement toutes les dix secondes, et chaque rafraîchissement demande huit à dix appels. Autrement dit, la surveillance produisait une oscillation permanente sur le serveur même qu'elle surveillait.

Lire la même information depuis un fichier prend des microsecondes. L'écart se compte en milliers, et cet écart se voit sur la machine de l'utilisateur sous forme de stabilité.

Le deuxième détail est plus élégant : à l'intérieur de cette structure il y a un compteur de changement qui s'incrémente dès que la configuration change. Atlas le surveille. Ainsi, dès qu'un réglage est modifié depuis le panneau, le cache se rafraîchit tout seul ; demander rarement et ne jamais montrer d'information périmée deviennent possibles en même temps.

C'est une autre face d'un principe écrit ailleurs dans ce wiki : ce qui observe ne doit pas être ce qui coûte. L'erreur la plus facile pour un outil de surveillance est de ralentir le système qu'il observe, et donc de fausser le chiffre même qu'il mesure.