Mettre à jour des firmwares sur un Dell PowerEdge 2950

On ne le répètera jamais assez, il faut toujours s’assurer d’avoir ses firmwares à jour sur un serveur. D’abord parce-que toute demande de support impliquera leur passage sur la machine qui pose problème et ensuite parce-qu’ils améliorent significativement la stabilité matérielle et logicielle de l’infrastructure.

Chez Dell, on peut principalement mettre à jour les firmwares via :

• Disquette (eh oui, cela vous sortira souvent d’une mauvaise passe)
• Clé USB (si quelqu’un sait faire ça m’intéresse)
• CD ou DVD (relativement instable)
• Partage réseau (jamais essayé, un retour d’expérience est également bienvenu)
• Internet (pour les machines les plus récentes type PowerEdge R610)

Dans cet article, nous nous attacherons à étudier une variante, via le passage d’un firmware directement depuis l’hôte allumé au moyen d’un package .bin. C’est par exemple le cas pour la mise à jour du BMC (Baseboard Management Controller). Une fois celui-ci téléchargé, déposez-le sur le disque local de votre serveur et rendez-le exécutable grâce à la commande chmod +x. Ensuite, vous pouvez le lancer avec la commande ./<nom_package>. Accessoirement, avant de le lancer, vous avez la possibilité de passer l’argument –version qui vous donnera tous les détails du package.

[root@esx vmfs-local0-esx]# chmod +x BMC_FRMW_LX_R202152.BIN
[root@esx vmfs-local0-esx]# ./BMC_FRMW_LX_R202152.BIN
Collecting inventory...
..
Running validation...

Baseboard Management Controller

The version of this Update Package is newer than the currently installed version.
Software application name: BMC
Package version: 2.37
Installed version: 1.27

Continue? Y/N:Y
Executing update...
WARNING: DO NOT STOP THIS PROCESS OR INSTALL OTHER DELL PRODUCTS WHILE UPDATE IS IN PROGRESS.
THESE ACTIONS MAY CAUSE YOUR SYSTEM TO BECOME UNSTABLE!
............................................................................................
............................................................................................
............................................................................................
Update Successful.

Ici, la version constatée était 1.27. Le package étant en version 2.37, le BMC a été upgradé après confirmation de la mise à jour (Y), tout ceci de manière transparente pour les utilisateurs.

Auditer un SAN EMC CLARiiON CX3-10 grâce à Navisphere Analyzer (deuxième partie)

Vous serez probablement intéressé par la lecture de la première partie de cet article.

Analyse des valeurs remontées dans Navisphere Analyzer

Lorsque vous ouvrez votre fichier “mergé”, vous avez la possibilité de sélectionner une vue par LUN, par Raid Group ou par Storage Processor (SP). Ici on utilisera la vue RAID Group qui permet de naviguer dans l’arborescence RAID Group, disque et LUN. Remarquez le chiffre 5 inscrit sur l’icône des LUNs DataStore-diskATA-01 et 02. Cela signifie que le pack est configuré en RAID 5.

Pour auditer efficacement votre baie, seules les cases cochées dans la capture ci-dessus s’avèrent réellement utiles. Voici un bref récapitulatif qui détaille pourquoi et comment se servir de ces valeurs :

• Utilization (%) : pertinent pour monitorer un RAID Group. La valeur indique le pourcentage d’utilisation (sur 100%) du LUN. Une crète proche des 100% sera mauvais signe et indiquera une saturation de votre RAID Group.
• Queue Length : pour ceux qui sont familiers avec les bases de données, cette valeur sera facilement assimilable. La file d’attente de votre baie doit toujours être aux alentours de 0, ce qui signifie que la baie a un excellent temps de réponse car aucun traitement en suspend.
• Response Time (ms) : cette valeur correspond au temps de réponse de la baie sur ses volumes. Ne confondez pas avec la Queue Length. L’intérêt des graphs Response Time (ms) n’a de sens qu’au niveau des disques physiques de la baie plutôt que des LUNs ou du RAID Group. Ayez en tête le fait qu’un disque FC répond en moyenne dans les 5ms alors qu’un disque SATA répond quant à lui en moyenne dans les 9ms. Toutefois, les valeurs que vous retrouverez sur vos disques n’ont pas lieu de vous inquiéter jusqu’à 100ms en permanence.
• Total Throughput (I/O/sec) : correspond au cumul lecture/écriture des entrées et sorties de votre baie. C’est probablement la valeur la plus utile et importante à auditer pour déterminer l’efficacité de la baie. Il n’y a pas de valeur type à remonter sans au préalable déterminer combien votre pack RAID est capable de supporter comme I/O/sec en lecture/écriture (voir plus bas pour un exemple avec des disques 10k/mn en RAID 5)
• Read Size (KB)* : correspond à la mémoire cache en lecture. Cette valeur n’a de sens que lorsque l’on se positionne sur un SP et que l’on compare les valeurs relevées avec le cache préalablement défini sur les Storage Processors. Trop de pics – ou pire, des crètes – indiquent qu’il n’y a pas assez de cache sur le SP en question. Il semble que ce graph se lise à l’envers et qu’une valeur proche de 0 indique que le Storage Processor n’a plus de cache.
• Read Throughput (I/O/sec) : correspond aux I/O en lecture montés en mémoire. Plus de détail en se référant à la valeur Total Throughput (I/O/sec)
• Write Size (KB)* : correspond à la mémoire cache en écriture. Cette valeur n’a de sens que lorsque l’on se positionne sur un SP et que l’on compare les valeurs relevées avec le cache préalablement défini sur les Storage Processors. Trop de pics – ou pire, des crètes – indiquent qu’il n’y a pas assez de cache sur le SP en question. Il semble que ce graph se lise à l’envers et qu’une valeur proche de 0 indique que le Storage Processor n’a plus de cache.
• Write Throughput (I/O/sec) : correspond aux I/O en écriture montés en mémoire. Plus de détail en se référant à la valeur Total Throughput (I/O/sec)

* A propos des valeurs Read Size (KB) et Write Size (KB)

Pour finir, voici un exemple de graphs que vous pourrez trouver dans Navisphere Analyzer. Ici, on affiche plusieurs valeurs. Celle sélectionnée (dans l’exemple Total Throughput) apparaît en gras.

Mémo technique de l’administrateur

Accessoirement, voici quelques informations très utiles concernant le matériel auquel vous pouvez être confronté :

• Le temps de réponse habituellement constaté sur un disque FC est de 5ms
• Le temps de réponse habituellement constaté sur un disque SATA est de 9ms
• La vitesse du bus interne EMC concernant les disques SATA à 10K/mn est de 2Go
• La vitesse du bus interne EMC concernant les disques SATA à 15K/mn est de 4Go
• Des disques FC 10K/mn configurés en RAID 5 permettent 120 I/O/sec en écriture (contre 80 I/O/sec pour des SATA). Théoriquement, pour un pack RAID 5 constitué de 5 disques (dont 1 de parité), on devrait pouvoir multiplier 120 x 4 = 480 I/O/sec, mais ce système de RAID ne permet d’obtenir que les performances d’un seul disque à cause de l’Overhead, d’où le chiffre de 120. Même exemple avec un RAID 5 de 9 disques : 120 x 8 (le 9ème sert à la parité) = 950 I/O/sec divisé par 4 = 240 I/O/sec…toujours à cause de l’overhead. A partir de ces exemples, vous venez au passage de découvrir qu’un pack RAID 5 de 9 disques est plus optimisé qu’un RAID 5 à 5 disques…
• Pour déterminer les I/O en lecture, il suffit de multiplier le nombre de disques du pack RAID par 120 I/O/sec (exemple : 5 disques x 120 I/O/sec = 600 I/O/sec en lecture)
• 1 écriture génère 4 I/O : vérification de la parité, écriture temporaire, acquittement, écriture réelle

Auditer un SAN EMC CLARiiON CX3-10 grâce à Navisphere Analyzer (première partie)

Pour déterminer si votre baie fonctionne correctement, si elle est bien taillée ou simplement à des fins de reporting, vous pouvez utiliser Navisphere Analyzer pour auditer en profondeur les échanges au niveau Storage Processor (SP), LUN ou bien disque. Si vous ne savez pas comment installer un composant sur Navisphere, lisez ce tutoriel.

Préparer l’analyse de la baie

Une fois connecté à Navisphere, cliquez droit sur votre baie et naviguez dans Analyzer > Data Logging…

Ensuite, choisissez la cible (votre baie) et laissez les options par défaut pour une analyse périodique routinière. Si jamais vous devez effectuer une analyse complexe, vous pourrez augmenter la fenêtre de récupération d’informations à plusieurs jours et réduire l’intervalle de logging des données. Les valeurs par défaut consomment déjà beaucoup de ressources. Si vous décidez de personnaliser les valeurs, assurez-vous que cela soit parfaitement justifié.

Pour débuter l’analyse, cliquez sur Start. Pour arrêter l’opération, il suffira de cliquer sur Stop au même endroit.

A présent, il faut récupérer le résultat de l’analyse. Pour cela, passez par le menu Tools > Analyzer > Archive > Retrieve…

A partir de la fenêtre qui apparaît, choisissez la baie analysée puis tour à tour les Storage Processor. Repérez le fichier qui vous intéresse grâce aux informations de date et heure (profitez-en pour faire du ménage sur d’éventuelles archives que vous n’auriez pas encore purgées) puis sauvegardez l’archive en local en cliquant sur le bouton Retrieve. Un message de confirmation apparaît enfin, acquittez-le.

Au final, vous devriez toujours vous retrouver en possession de deux archives (SP A et SP B).

Avant d’ouvrir les archives, passez par le menu Tools > Analyzer > Customize… et modifiez les paramètres de manière à toujours ouvrir les fichiers en Performance Detail. C’est le mode le plus utile pour analyser ce qu’il se passe sur votre baie.

Pour exploiter les archives, vous pouvez passer par le menu Tools > Analyzer > Archive > Open… Cependant, vous pouvez optimiser cette action en fusionnant les archives de SP A et SP B. Passez donc plutôt par le menu Tools > Analyzer > Archive > Merge…, sélectionnez vos archives, puis cliquez sur le bouton Merge (cela aura pour effet de créer un nouveau fichier .nar)

Voilà, vous êtes fin prêt à analyser la baie. Pour en savoir plus, lisez la suite de cet article.