Résumé : présentation rapide de Dell IDSDM (système d'exploitation d'un serveur sur deux cartes SD redondées), du processus de résolution d'une banale panne de carte SD, des manières de superviser l'état des cartes SD et du module IDSDM en ligne de commande et à distance, et des limites de la techno (faux positif, remplacer une carte SD nécessite d'éteindre le serveur et de redémarrer iDRAC, logistique pour remplacer régulièrement les cartes SD, peu de documentation). Une petite anecdote mettant en exergue la démesure de la logistique de Dell sera narrée.
Notre supervision râle : l'un de nos hyperviseurs ne remonte plus d'info. Ping OK. Impossible d'établir une connexion SSH. Les machines virtuelles hébergées dessus fonctionnent toujours sans problème. Impossible de piloter les machines virtuelles (allumer/éteindre, console, migrer sur un autre nœud du cluster) depuis les autres hyperviseurs du même cluster.
Dans la salle serveurs (mais la console iDRAC aurait affiché la même chose), l'écran affiche une palanquée d'erreurs d'écriture puis de lecture sur dm-0 (probablement le device virtuel associé au conteneur LVM (LV) qui contient la racine du système).
iDRAC confirme : les deux cartes SD sont mortes. La première est morte le 13/12/2020, l'autre le 08/01/2021.
Ha, oui, on utilise la techno Dell Internal Dual SD Module (IDSDM). Un module (une carte électronique fille branchée sur la carte mère du serveur, voir la page 2 du whitepaper de Dell), deux cartes SD, les écritures se font sur les deux cartes SD et les lectures sur celle du premier slot tant qu'elle est opérationnelle (comme du RAID 1), et l'on installe un système d'exploitation dessus. Le système voit les cartes SD comme un disque dur SATA (/dev/sdX).
L'intérêt ? Séparer le système d'exploitation des VMs sans pour autant immobiliser 2 slots pour disques dur (afin de faire un RAID 1 pour le système), ce qui réduit l'espace de stockage disponible pour les machines virtuelles. Il y a 10 slots sur un serveur 1U donc 10 disques durs maximum dont 1 est perdu si l'on fait du RAID 5 (c'est comme ça que ça fonctionne) et encore 1 si l'on veut du hot spare (disque de secours qui remplacera, sans intervention humaine, un disque défectueux), alors si l'on retire encore deux disques pour le système… Cependant, deux PV LVM sur une même grappe RAID produiraient environ le même résultat de séparation sans immobiliser deux slots.
Évidemment, et c'est un tort, nous avons mis en place aucune optimisation afin de limiter les écritures sur les cartes SD : ni log2ram (qui stocke les journaux en RAM et les écrit, par paquet, à intervalle régulier sur le support de stockage), ni option de montage « noatime », rien.
On vérifie la santé des deux autres hyperviseurs du même cluster. Ho, une carte SD sur les deux est morte dans un autre hyperviseur depuis le 28/12/2020. Le troisième hyperviseur est sain.
Appel téléphonique au support Dell. On nous dit que beaucoup de clients installent un système sur IDSDM (en même temps, quel vendeur dira que son produit est inutilisé ?!). Il y a rien d'anormal, qu'on nous dit, la durée de vie des cartes SD est de 2 ans et demi / 3 ans (pour info, nos serveurs sont en prod' depuis un peu moins de 2 ans). Lourde insistance du support pour remplacer les modules en sus des cartes SD… Soit.
Nous sommes vendredi midi. Nous sommes fermés le samedi. Nous avons contracté un support ProSupport H+4. Que va faire Dell ? Attendre que le manager revienne de la cafèt’ (sisi :D), trouver 2 modules et 3 cartes SD dans l'entrepôt situé dans la grande ville la plus proche de chez nous et une 4e carte SD dans l'entrepôt d'une autre grande ville. Deux camions de livraison sont partis de deux villes différentes pour nous livrer 4 cartes SD et deux bouts d'électronique en moins d'une après-midi ! Livraison à 18 h et 20 h. :O
Deux sentiments m'ont accompagné tout cet après-midi-là.
Bon ben on part sur la réinstallation de Proxmox sur notre premier hyperviseur.
Avant ça, on sort les cartes SD et on les tripote entre nos doigts comme la puce d'une carte bancaire muette. Dans le doute…
On tente de démarrer sur l'une des cartes SD : échec. Avec un autre ordinateur, on parvient à ouvrir le VG LVM mais impossible de monter le système de fichiers ext4 : impossible de lire le superblock, input/output error.
En revanche, la deuxième carte SD fonctionne : le serveur démarre ! Tout fonctionne comme avant. Pas d'erreur apparente.
On installe une carte SD neuve dans le deuxième slot. Durant la phase POST du BIOS (tu sais, quand il vérifie la RAM, quand il initialise le contrôleur RAID, etc.), il nous est demandé « SD Card x has been replaced and needs to be rebuilt. […] Press
Sur notre deuxième hyperviseur, il nous suffit de remplacer la SD défectueuse par une neuve et de valider la reconstruction lors du démarrage. Reconstruction qui, elle aussi, s'effectuera en tâche de fond.
On notera que nous avons fait le choix de ne pas remplacer les modules, car nous ne les pensons pas défectueux.
Nous avons également fait le choix de ne pas remplacer les cartes SD qui semblent être fonctionnelles afin que toutes les cartes SD ne tombent pas en panne en même temps.
Sur le premier hyperviseur, j'espère que nous n'avons pas recopié les erreurs d'une des vieilles cartes SD sur les neuves. Pour l'instant : RÀS.
Comment savoir quand la reconstruction d'une carte SD est terminée et que nous sommes revenus à l'état nominal ? D'après les documentations que l'on trouve sur le web, cela se passe dans le BIOS ou dans l'iDRAC, mais, pour que ce dernier mette à jour l'état des cartes SD, il faut le redémarrer… … …
Après 30 minutes, nous redémarrons iDRAC, et, en effet, tous les indicateurs présentés sont repassés au vert. Je parle du tableau de bord et de la section « Média amovible » dans le menu « Système » puis « Présentation générale » dans laquelle les items « SD » (ou « VFLASH SD »), « IDSDM SD1 » et « IDSDM SD2 » doivent être en « Status » OK et l'« État de la redondance » doit avoir la valeur « Total ». Note : sur l'item « SD » (ou « VFLASH SD »), la « Condition de la connexion » est toujours définie à « Absent », même sur un serveur tout neuf.
Les cartes SD sont des consommables qu'il faut changer régulièrement. Cela implique de les superviser. Dans notre supervision actuelle (on ne va pas aller manuellement consulter des interfaces web supplémentaires), ce qui implique des outils CLI (exit, donc, le lourdingue Dell OpenManage). Cette supervision s'effectue depuis iDRAC. C'est un peu chiant à trouver :
megacli
, que l'on utilise déjà pour superviser notre RAID, est inutile ;En plus d'être toujours aussi pénible à installer, RACADM propose rien de spécifique. On peut toutefois remonter l'info sur l'on cherche en analysant les journaux ;
Si l'on active IPMI dans iDRAC (avec la version 9, cela se passe dans le menu « Paramètres de l'iDRAC » => « Connectivité » => « Paramètres IPMI » => « Activer IPMI sur le LAN ») :
ipmitool -I lanplus -H <nom_DNS_iDRAC> -U <identifiant> sensor get SD
retourne rien d'exploitable (idem pour les capteurs « SD1 » et « SD2 ») ;ipmitool -v -I lanplus -H <nom_DNS_iDRAC> -U <identifiant> sdr list | grep -A 5 ': SD'
retourne un énigmatique « sensor reading : 0h » dont on ne trouve pas d'explication dans un quelconque document Dell, et comme il s'agit, a priori, d'une valeur spécifique à un constructeur, une extrapolation depuis d'autres documentations est risquée ;ipmitool -I lanplus -H <nom_DNS_iDRAC> -U <identifiant> sensor | grep '^SD'
affiche les valeurs « 0x0180 » (pour « SD1 » et « SD2 ») et « 0x0080 » (pour « SD ») dont quelques sites web obscurs nous assurent que ça veut dire que tout est OK… Cela se confirme vaguement en regardant l'état d'autres capteurs, mais rien est plus trompeur que l'auto-persuasion ;snmpget -v2c -c public <nom_DNS_iDRAC> .1.3.6.1.4.1.674.10892.5.4.200.10.1.61.1
retourne une valeur qui est documentée dans la MIB iDRAC-SMIv2 téléchargeable sur le site web de Dell (03 03 = les deux cartes SD sont OK, le premier octet étant la première carte SD, l'autre la deuxième). L'état du module IDSDM lui-même est disponible à l'OID .1.3.6.1.4.1.674.10892.5.4.200.10.1.59.1 (même codes retour). SNMP me semble être la moins mauvaise solution pour superviser IDSDM.