GuiGui's Show

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.

IDSDM

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.

La folie du monde

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à.

• D'un côté, la virtuosité de l'humain pour trouver des solutions. Connaître l'état des stocks en temps réel dans tous les entrepôts du monde. Gérer ce stock (et si t'as eu des cours d'éco/gestion, tu sais que c'est toute une histoire). Contractualiser avec des sociétés de livraison. Filer des ordres de livraison d'un claquement de doigts. T'imagine le système d'information de malade qu'il faut afin de faire tout ça ?! Et encore, j'oublie nombre de paramètres comme faire remuer des humains.
  
  
• D'un autre côté, la folie et la démesure de l'humain. Toute une chaîne humaine s'est activée et deux putain de camions ont fait 660 km (aller-retour) en une demi-journée parce que des gus ont pleuré dans les jupes d'une multinationale et ont payé le bon contrat. L'écologie, ça sera pour demain, promis.

La chance

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 to rebuild or to continue without rebuilding. ». Nous appuyons sur Y. Contrairement à ce que mentionne le whitepaper Dell sus-mentionné, un message nous informe que la reconstruction (la copie d'une SD sur une autre, quoi) se fera en tâche de fond et le démarrage continue.

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.

Retour à la normale ?

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.

Limites d'IDSDM

Supervision

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 :

• Comme il ne s'agit pas d'un RAID, 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 si 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.

Autre

• Le module et les cartes SD sont situés à l'intérieur du serveur. Pour remplacer une carte SD défectueuse, il faut donc éteindre ledit serveur. Ce n'est pas la mort, on peut prévoir des créneaux de remplacement réguliers (nous avons des périodes d'inactivité planifiées chaque année). Mais rien dit qu'une carte SD ne tombera pas en panne en dehors de ces créneaux, et, là, on ne voudra très probablement pas attendre le prochain créneau. Alors, oui, avec la migration à chaud des machines virtuelles au sein d'un même cluster, on peut s'en sortir sans trop d'efforts, mais ça ne me convainc pas des masses : il reste la logistique (ouvrir un ticket chez Dell. Voudront-ils envoyer des SD tant qu'il n'y a pas de panne ? Réceptionner les cartes. Préparer la maintenance. Effectuer la maintenance). D'un autre côté, est-ce vraiment différent d'un RAID avec des disques durs, au fond ? Pas sûr ;
  
  
• IDSDM me semble être immature. Il nous a marqué une carte SD comme étant défectueuse alors qu'elle semble être saine (et qu'elle est toujours en production). J'aimerais ajouter que Dell, qui insiste pour remplacer les modules eux-mêmes, génère un doute sur la fiabilité du produit, mais, après réflexion, j'ai déjà vu, à plusieurs reprises, Dell changer des composants sans trop de rapport avec une panne juste parce qu'ils en ont les moyens et qu'ils veulent satisfaire la clientèle, donc on peut rien en déduire ;
  
  
• Pour identifier si le système est revenu à l'état nominal après le remplacement d'une carte SD, il faut redémarrer iDRAC à l'aveugle (redémarrer trop tôt : la copie d'une carte SD à l'autre ne sera pas terminée)… Bricolage détecté ;
  
  
• On trouve assez peu de documentation sur IDSDM : comment le superviser, le coup du redémarrage obligatoire de l'iDRAC, la présentation de l'état nominal dans iDRAC, etc.