Utiliser les bonnes pratiques de création et d’organisation des LUNs et volumes VMFS

Dans la série des bonnes pratiques de modélisation de votre infrastructure de stockage, le sizing de vos LUNs et volumes VMFS ne sera pas un élément bloquant de vos déploiements mais plutôt une tranquillité d’esprit quant à l’optimisation des moyens mis en œuvre pour rendre une installation plus facile et cohérente à administrer à long terme.

Déterminer les spécificités d’environnement

Pour cela, nous allons partir de préalables à déterminer selon vos besoins :

• Nombre total de VMs
• Taille moyenne (maximale) des VMs (en Go/To)
• Taille totale de la baie de stockage (en To)
• Pourcentage d’espace disque estimé réservé aux snapshots et au swap

Garder en tête les pratiques habituellement constatées

Chaque configuration révèle ses vérités et l’expérience que vous obtenez au fur et à mesure de vos déploiements peut radicalement vous faire changer de méthode. Néanmoins, il reste certaines recommandations jusqu’alors bien utiles :

• On dépasse rarement 30 machines virtuelles par LUN pour garder une file d’attente disque raisonnable. Idéalement, on restera dans la dizaine.
• On tente le plus possible de distinguer et de rapprocher en groupes les machines virtuelles de taille similaire : 0 à 100Go, 100 à 500Go etc…
• On arrondit toujours la taille totale estimée à une valeur supérieure d’au moins 20Go
• On utilise toujours des DataStores plutôt que des Raw Device Mapping (RDM), sauf si l’on désire présenter des volumes de plus de 800Go.
• VMFS3 supporte des volumes allant jusqu’à 64To donc vous n’avez pas à vous inquiéter d’un quelconque bridage technique.

Simuler une taille de volume

Comme il n’existe pas de taille idéale par définition, nous allons partir de valeurs de test pour effectuer notre exemple de modélisation :

• Nombre total de VMs : 112
• Taille moyenne (maximale) des VMs : 50Go pour 102 machines (soit une taille totale de 5,1To) et 3 VMs à 1To (soit une taille totale de 3To)
• Taille totale de la baie de stockage : 10To
• Pourcentage d’espace disque estimé réservé aux snapshots et au swap : 20

La formule mathématique qui en découle est donc très simple :

Nombre total de VMs x Taille moyenne (maximale) des VMs + 20% = Taille du volume

Comme dans notre configuration test nous nous retrouvons avec de nombreuses machines virtuelles – qui plus est hétérogènes – et que nous désirons suivre les bonnes pratiques et recommandations, nous allons créer les volumes en conséquence. Attention, ce n’est pas compliqué mais il faut être attentif avec la succession du raisonnement logique :

• 102 VMs x 50Go + 20% =  6120Go > comme on préfère travailler avec des datastores et qu’ils ne doivent pas dépasser 800Go, on divise donc 6120 par 800, ce qui donne 8 datastores de 800Go (6,4To au total) .
• 3 VMs x 1To + 20% = 3,6To > comme nos disques dépassent 800Go par machine, on crée un RDM pour chacune, ce qui donne 3 RDM de 1,5To (4,5To au total) au lieu de 1,2To normalement car avec des machines de cette taille, on surévalue par précaution le sizing en prévoyant des snapshots gourmands qui traîneraient et grossiraient bien plus vite qu’avec de petites machines virtuelles…

J’insiste sur le fait que ce n’est pas un calcul très complexe mais tout de même fin et très emprunt d’une dose de vécu qui vous fera adapter intelligemment chaque paramètre pour satisfaire au mieux votre déploiement. Rappelez-vous enfin que la concaténation de LUNs existe (MetaLUN) et que vous n’avez aucune raison de vous en priver. De même, si vous passez d’un environnnement Virtual Infrastructure à vSphere, aucun problème étant donné que le VMFS de vSphere, en version 3.33, est totalement compatible avec la version 3.31 de Virtual Infrastructure.

Rester lucide sur son travail

Voilà, votre modélisation est désormais argumentée et sérieuse. Cependant, n’avez-vous rien remarqué de bloquant ? 6,4To + 4,5To font 10,9To. Or, votre baie ne fait que 10To ! Pourtant vous ne pouvez pas avoir plus d’espace disque. Vous êtes donc confronté à une réalité tout à fait opérationnelle : il va falloir faire “comme vous pouvez”, en prenant soin de respecter au mieux les bonnes pratiques tout en faisant avec les contraintes techniques du client. C’est là que vont entrer en jeu votre imagination et votre expertise, sachant que travailler avec une baie aussi pleine n’est pas serein, ne serait-ce que vis-à-vis du blocage immédiat que vous allez rencontrer concernant la création de nouvelles VMs ou l’extension à prévoir des VMDK déjà en production.

Bon courage !

Collecter et récupérer des logs sur un switch Fiber Channel Brocade

Nous allons utiliser une vieille technologie qui s’avère toujours pratique de temps à autre : hyperterminal. Vous pourriez tout aussi bien vous connecter directement en Telnet via votre invite de commandes habituelle ou PuTTY, soit par choix, soit par nécessité (postes sous Windows Vista ou supérieur…)

Passez par le menu Démarrer > Exécuter puis tapez hypertrm pour lancer l’application. Donnez ensuite le nom que vous souhaitez à la nouvelle connexion.

Renseignez l’adresse IP du switch et sélectionnez TCP/IP (Winsock) dans le menu déroulant. La connexion s’effectue sur le port 23, ce qui indique que le protocole utilisé sera Telnet.

Une fois la connexion établie, le switch vous demandera de vous identifier. Rentrez vos informations de login et mot de passe. Par défaut, les switchs Brocade sont configurés avec le nom d’utilisateur admin et pas de mot de passe.

Maintenant que vous êtes connecté, passez par le menu Transfert > Capturer le texte… puis sélectionnez une destination sur votre disque dur local. Ceci aura pour effet d’enregistrer toutes les commandes passées via hyperterminal dans un fichier au format txt.

Tapez par exemple la commande supportshow (attention, le switch est case sensitive) pour obtenir les informations constructeur utiles au support Brocade.

swb2:admin> supportshow

Le résultat de la commande effectué, vous pouvez interrompre la capture du texte via le menu Transfert > Capturer le texte… > Arrêter puis quitter hyperterminal. Ne reste plus qu’à exploiter les logs ainsi récupérés.

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