Et justement, en ce moment nous sommes en pleine découverte de la configuration FC sur Nexenta (plus particulièrement sur la configuration du mode target) qui est un Unified Storage System  tout à fait capable de présenter la même LUN (un zvol pour être précis) via FC et iSCSI. Voici donc une petite démo en 4 étapes :

1. Coupure de vmhba1 (prefered path) > Bascule sur vmhba2
2. Coupure de vmhba2 > Bascule sur vmhba32 (iSCSI)
3. Restauration de vmhba2 > Aucun effet
4. Restauration de vmhba1 > bascule sur vmhba1

Tout d’abord, vous remarquerez que ça bombarde à 10k+ IOPS (alors que le serveur Nexenta est une petite VM), remettez vous, c’est l’effet ZFS

Plus sérieusement, on remarque que le failover se fait dans le sens croissant des vmhba, ce qui règle le problème du choix d’iSCSI qu’en dernier recours étant donné que l’initiateur est toujours à 32 ou plus. De plus le failover se fait dans un délais raisonnable de 10 secondes (contre 30sec pour MPIO de Windows 2008 R2 et donc d’Hyper-V) mais cette solution pose un réel problème si le chemin préféré venait a être le seul à ne PAS être restauré car le chemin iSCSI est considéré comme les autres donc restera “valable” (cf FC to iSCSI failover : MRU ranking). Mais nous pensons que cela reste néanmoins une solution à connaitre et peut être à envisager pour les plus parano du HA.

Et le plus drôle dans l’histoire c’est que vous n’avez rien à configurer !

PS: Ça doit être possible à faire avec les autres hyperviseurs évidement…

get-vmhost -location "mon_beau_cluster"|get-view|select name,@{N="WWN";E={get-view $_.ConfigManager.StorageSystem|%{$_.StorageDeviceInfo.HostBusAdapter|?{$_ -is [VMware.Vim.HostFibreChannelHba]}}|select @{N="WWN";E={"{0:x}" -f $_.PortWorldWideName}}}}|select name -ExpandProperty WWN|select name, @{N="WWN";E={$_.WWN.substring(0,2)+":"+$_.WWN.substring(2,2)+":"+$_.WWN.substring(4,2)+":"+$_.WWN.substring(6,2)+":"+$_.WWN.substring(8,2)+":"+$_.WWN.substring(10,2)+":"+$_.WWN.substring(12,2)+":"+$_.WWN.substring(14,2)}}|sort name

PS : Et nous on pense que les “:” c’est important

MAJ 07.06.2013 : Nouvelle version 2.1 plus rapide et dotée des nouveaux paramètres -onlyfree (pour ne retourner que les LUN vides) et -minVMFSsizeGB (pour ne retourner que les datastore d’une taille minimum de xGB – 1GB par défaut)

Avec la cmd-let Get-ScsiLunPath, il est très facile de repérer les “dead path” sur un ou une liste d’ESX et c’est d’ailleurs de cette façon que vCheck v5+ les obtient. Le problème est qu’il n’est pas facile ensuite de faire le rapport avec le datastore concerné et si c’est bien d’un datastore dont il est question (cela peut être un périphérique de stockage autre comme un lecteur cdrom ou une clef usb par exemple).

Nous avons donc créé pour cela un script avec la collaboration de notre ami JJR (qui souhaite conserver l’anonymat dans cette affaire) qui nous a été d’une grande aide en ce qui concerne l’optimisation du script lorsqu’il est exécuté sur un gros environnement. Ce script génère une liste des chemins de LUN (dead ou non selon le paramétrage) avec les informations suivantes :

• ClusterName : nom du cluster
• ESX : nom de l’ESX
• CanonicalName : LUN identifier
• Runtime : vmhba<Adapter>:C<Channel>:T<Target>:L<LUN>
• State : active, standby ou dead
• IsWorkingPath : true ou false
• LunSize : exprimé en MB, GB ou TB (le cas échéant)
• Datastore : nom du datastore VMFS (le cas échéant)
• UUID : VMFS UUID (ou “cdrom” si le périphérique est un lecteur optique)

Pour plus d’informations, nous vous recommandons de consulter la kb Identifying disks when working with VMware ESX

Voici le détails et les valeurs par défaut des paramètres disponibles :

• cluname : permet de spécifier un cluster (parcours tous les hosts par défaut)
• nofile : n’affiche que le résultat dans la console et ne génère pas de fichier (“0″ par défaut)*
• html : génère un fichier html au lieu d’un csv (“0″ par défaut)*
• onlydead : ne liste que les chemins “dead” (“1″ par défaut)
• onlyvmfs : ne liste que les chemins de LUN comportant un datastore VMFS (“0″ par défaut)

* le fichier est généré dans le répertoire de travail.

Exemple d’usage pour afficher tous les chemins d’un cluster :

.\Get-DeadPath+.ps1 -cluname "CLU01" -html "1" -onlydead "0"

Exemple d’usage pour n’afficher que les chemins “dead” :

.\Get-DeadPath+.ps1 -html "1" -onlydead "1"

Nous ne manquerons pas mettre à jour vCheck en conséquence.

download