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

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.

Je suis passé de la version 10.4 à la 10.7 de Debian GNU/Linux. Depuis, Chromium ne fonctionne plus : l'affichage se fige totalement quelques secondes après son démarrage.

Solution ? Désactiver l'accélération graphique.

Comment faire ?

• Dans un terminal, utiliser la commande chromium --disable-gpu ;
  
  
• Aller dans le menu => « Paramètres » => « Paramètres avancés » (en bas de la page) => « Système » (en bas) => Décocher « Utiliser l'accélération matérielle » ;
  
  
• Fermer Chromium. Il pourra à nouveau être ouvert sans préciser « --disable-gpu ».

Sur l'iDRAC d'un serveur Dell, je veux récupérer l'état d'un composant en utilisant le protocole SNMP. Dell complète les bases de données standardisées interrogeables en SNMP avec la sienne (ce qu'on nomme un module MIB, l'ensemble des bases de données agrégées sous forme arborescente est nommée MIB).

Première question : comment connaître l'OID (l'identifiant unique) d'un objet défini dans un module MIB afin de le consulter en SNMP ?

Généralement, chercher le nom de l'objet sur un moteur de recherche web suffit. Dans mon cas, chercher « systemStateIDSDMCardDeviceStatusList » conduit à des résultats fort bien présentés : oidref et observium.org. L'OID est 1.3.6.1.4.1.674.10892.5.4.200.10.1.61

Mais si l'on veut trouver par nous-même, au cas où une MIB ne soit pas aussi bien indexée ?

Le début d'un OID est normalisé : .1.3.6.1. .1.3.6.1.2.1 pour la très populaire MIB-II. .1.3.6.1.4.1 pour les sociétés commerciales privées. Mais la suite dépend de Dell (dans mon cas).

On peut télécharger la MIB et l'étudier avec un éditeur de texte. On cherche notre objet par son nom (« systemStateIDSDMCardDeviceStatusList » dans mon cas). On lit « ::= { systemStateTableEntry 61 } ». Cet objet a donc l'ID 61 relativement à l'objet « systemStateTableEntry ». On remonte l'arborescence : l'objet « systemStateTableEntry » a l'ID 1 relativement à l'objet « systemStateTable » qui, lui-même, a l'ID 10 relativement à l'objet « systemStateGroup » qui a l'ID 1.3.6.1.4.1.674.10892.5.4.200. L'OID absolu que nous cherchons est donc 1.3.6.1.4.1.674.10892.5.4.200 + .10.1.61 + .1 soit 1.3.6.1.4.1.674.10892.5.4.200.10.1.61.1. Pourquoi j'ai ajouté un « 1 » à la fin ? Car c'est comme ça que l'on consulte la case d'un tableau en SNMP.

Et si l'on n'a pas envie de s'embêter avec ce que je viens de raconter ? On utilise le logiciel snmptranslate de la trousse à outils net-snmp (nom du paquet Debian : snmp). Tout est dans la documentation, mais je vais répéter :

• Trouver les endroits où sont stockées les modules MIB : snmptranslate -Dinit_mib .1.3 2>&1 | grep MIBDIR. Sous Debian, il y a des chemins dans /usr/share (si l'on dépose une MIB dedans, le dossier ne sera pas supprimé quand on supprimera le paquet snmp…) et ~/.snmp/mibs ;
  
  
• Créons donc ce deuxième dossier : mkdir -p ~/.snmp/mibs ;
  
  
• On télécharge la MIB IDRAC-MIB-SMIv2 et on la dépose dans le dossier créé à l'étape précédente ;
  
  
• Ce module MIB dépend d'autres modules MIB. Il faut donc les installer, sinon on aura les erreurs « Cannot find module (SNMPv2-SMI): At line 39 in /home/guigui/.snmp/mibs/IDRAC-MIB-SMIv2.mib », « Cannot find module (SNMPv2-TC): At line 41 in /home/guigui/.snmp/mibs/IDRAC-MIB-SMIv2.mib », « Undefined identifier: enterprises near line 146 of /home/guigui/.snmp/mibs/IDRAC-MIB-SMIv2.mib » et le bout de MIB de Dell ne sera pas chargé (« Unlinked OID in IDRAC-MIB-SMIv2: dell ::= { enterprises 674 } »). Pour récupérer les autres MIBs avec Debian, il faut installer le paquet non-free snmp-mibs-downloader car tous les modules MIB ne sont pas libres. Les MIBs seront téléchargées durant l'installation du paquet ;
  
  
• On peut enfin convertir un nom en OID : snmptranslate -IR -On IDRAC-MIB-SMIv2:systemStateIDSDMCardDeviceStatusList.

Deuxième question : comment charger / ajouter une MIB à snmpget / snmpwalk afin d'utiliser le nom d'un objet pour y accéder ?

Nous venons de faire cela pour répondre à la question précédente.

Nous pouvons récupérer la valeur d'un objet à partir de son nom : snmpget -v2c -c <COMMUNAUTÉ> <nom_DNS_iDRAC> IDRAC-MIB-SMIv2:systemStateIDSDMCardDeviceStatusList.1 (là non plus, on n'oublie pas le « .1 » final afin d'entrer dans la case du tableau).

On peut toujours récupérer la valeur de l'objet à partir de l'OID qu'on a trouvé ci-dessus : snmpget -v2c -c <COMMUNAUTÉ> <nom_DNS_iDRAC> 1.3.6.1.4.1.674.10892.5.4.200.10.1.61.1.

Et si l'on veut que snmpget / snmpwalk résolvent le nom d'un OID pour nous ? snmpwalk -m +IDRAC-MIB-SMIv2 -v2c -c <COMMUNAUTÉ> <nom_DNS_iDRAC> 1.3.6.1.4.1.674.10892.5.4.200.10.1. Et si préciser « -m +IDRAC-MIB-SMIv2 » est trop pénible, tu remplaces la ligne « mibs : » par « mibs +IDRAC-MIB-SMIv2 » dans /etc/snmp/snmp.conf.