J'ai monté un RAID logiciel, redémarré, et le stockage a disparu : la grappe n'est pas assemblée au démarrage

Vous avez réuni les disques, la grappe s'est montée, le stockage est apparu, vous y avez écrit des données. Tout a fonctionné.

Puis vous avez redémarré la machine et le stockage a disparu.

Les disques vont bien. Les données sont toujours là. Ce qui manque, c'est autre chose.

Une grappe n'est pas sur les disques, elle est dans l'instruction d'assemblage

Présenter plusieurs disques comme un seul stockage n'est pas une propriété posée sur les disques. À chaque démarrage, le système doit retrouver ces disques et les réassembler.

Il existe un enregistrement qui lui dit comment. Sans cet enregistrement, la grappe peut ne pas être assemblée. Et même si elle l'est, elle peut remonter sous un autre nom, ce qui revient au même : votre stockage pointe vers l'ancien nom et il n'y a rien là-bas.

Le problème n'est donc pas « les données sont perdues » mais « le chemin vers les données n'a pas été construit au démarrage ». Cela paraît moins effrayant, mais dans l'instant de panique les deux se ressemblent.

La position de Proxmox lui-même

Cela mérite d'être dit franchement : la voie intégrée et prise en charge sur Proxmox est ZFS. Demandez un miroir de disques pendant l'installation et c'est ce que vous obtenez.

Le RAID logiciel classique fonctionne, mais ce n'est pas la voie que l'installateur met en place pour vous. Ce qui veut dire qu'en le choisissant, s'assurer que les étapes d'assemblage au démarrage ont été faites correctement vous revient.

Il reste des cas où c'est justifié : vous avez déjà une grappe et vous la migrez, la configuration de votre contrôleur n'est pas celle que ZFS attend, ou la mémoire de la machine est juste pour ZFS. Ce sont de vraies raisons. Le choisir sans raison, c'est se créer du travail pour plus tard.

La règle : une grappe qui n'a pas vu de redémarrage ne compte pas comme une grappe

C'est la phrase la plus utile de cet article.

Après avoir monté la grappe, redémarrez une fois exprès, tant que rien n'en dépend. Le stockage revient-il, revient-il sous le même nom, le contenu est-il visible ?

Nous avons écrit la même chose dans l'article sur les alertes de ce wiki : une alerte non testée n'est pas un mécanisme, c'est un espoir. Pour une grappe, c'est pareil. Une grappe qui n'a pas survécu à un redémarrage est une grappe dont vous croyez qu'elle fonctionne.

Le piège du changement de nom

Deuxième piège fréquent : la grappe est assemblée, mais sous un nom différent de la fois précédente.

Votre définition de stockage pointe vers l'ancien nom, donc le stockage est de nouveau invisible. Cette fois la grappe est debout, mais personne ne la regarde.

La solution est d'attacher le stockage par identité plutôt que par nom. Les noms peuvent changer, les identités non.

Ce que fait Atlas

Quand Atlas monte une grappe, il écrit aussi l'enregistrement de démarrage, et il affiche cet avertissement à l'écran : si cette étape échoue, la grappe peut ne pas être assemblée au démarrage et le stockage devient invisible.

L'avertissement était vrai. Mais pendant un temps il se contredisait lui-même.

L'outil du système était appelé pour produire l'enregistrement. On a mesuré, et voici ce qui est ressorti : quand il n'y a aucune grappe, cet outil se termine avec le code zéro et n'affiche rien. Autrement dit il dit « réussi » et ne vous donne rien.

Résultat : rien n'était écrit, mais l'étape était enregistrée comme réussie. Ce que l'avertissement venait justement de décrire arrivait à l'utilisateur, pendant que l'écran affichait que tout allait bien.

La correction avait deux volets. Le format attendu a été déterminé par la mesure et non deviné, et si la sortie ne correspond pas à ce format, l'étape est comptée en échec. Une sortie vide est aussi un échec. Et pour ne pas écrire deux fois la même grappe, on vérifie à la fois le chemin de l'appareil et l'identité.

La leçon générale

La phrase qui compte ici est celle-ci : « la commande a réussi » et « le travail a été fait » ne sont pas la même chose.

Un code de retour vous dit si l'outil s'est exécuté. Il ne vous dit pas si le résultat s'est produit. Si toute la raison d'être d'une étape est de produire un effet, ce qu'il faut vérifier n'est pas l'état de l'outil mais l'effet lui-même.

Il y a deux autres articles de la même famille dans ce wiki. Dans celui sur les disques orphelins, on a séparé une réponse vide d'une absence de réponse. Dans celui sur le nom du serveur, il y avait le danger de mettre une valeur par défaut d'apparence plausible à la place de l'inconnu. Voici le troisième : mettre un code de retour à la place d'un résultat jamais établi.

Les trois sont des visages du même défaut : le programme affirme quelque chose qu'il n'a pas vérifié.