17 05 2013
Hyper-V 2012: Problème critique avec l’outil Test-Cluster
Petit problème, grosses conséquences, avec un bug dans l’outil Test-Cluster qu’il est nécessaire de lancer avant la création d’un cluster Hyper-V ou l’ajout d’un nœud.
Ces dernières semaines, nous avons rencontré quelques soucis de stabilité du cluster Hyper-V chez mon client actuel.
Le problème était très simple: les LUNs n’étaient pas présentées à tous les nœuds !
Si le problème de zoning est somme toute très simple à corriger, comment avons-nous été en mesure d’ajouter des noeuds qui n’ont pas accès aux disques ?! D’autant plus que ce bug n’a pas empêché de démarrer les machines virtuelles sur ces serveurs Hyper-V (démontrant que CSV2.0 reste une tuerie de fiabilité même en cas de défaillance des liens FC).
Chaque nœud a été ajouté après vérification avec l’outil Test-Cluster (comme indiqué dans cet article). Or, la vérification des disques apparait en Success dans le rapport.
Or, quand on regarde le rapport de plus près, en cliquant sur List Potential Cluster Disks, nous avons bien l’erreur suivante:
|
1 |
Physical disk {e14db7ac-6a1c-4b41-89f0-6db1a0baccce} is not visible from all nodes. Page83 descriptor: 60A9800037537134362B434A72787131. Page80 Serial Number: 7Sq46+CJrxq1. Validation for this disk will be done using a subset of nodes. The disk is reported as visible at the following nodes: |
Le point a été remonté à Microsoft. Espérons qu’il sera corrigé dans les prochaines mises à jour.
Conclusion
Vérifiez bien avant l’ajout d’un nœud que les disques sont bien présentés avant de créer le cluster ou d’ajouter un nœud. Si le CSV 2.0 est très « resilient », le cluster teste toutes les 3 min l’accès aux disques et se sont les liens du cluster (aussi appelé HeartBeat) qui sont utilisés pour accéder aux disques et dès saturation, le service cluster devient instable, ce qui peut se traduire par:
- I/O Disques mis en pause sur les nœuds qui n’ont pas d’accès aux disques;
- Qui peut impliquer: VM qui plante si la pause est trop longue;
- Qui peut impliquer: Si la VM devient instable, le service cluster tente de la redémarrer sans succès;
- Qui peut impliquer: Si plusieurs VMs sont instable, le service cluster redémarre sur le nœud/et ou tous les nœuds du cluster;
- Qui peut impliquer: Toutes les VMs redémarrent sans préavis.
Une vérification simple avec le script suivant qui permettra de lister les disques sur chaque noeud:
|
1 2 3 4 |
$nodes = @("Hyper-V1","Hyper-V2","Hyper-V3","Hyper-V4","Hyper-V5") $credentials = Get-Credential Invoke-Command -ComputerName $nodes -Credential $credentials -ScriptBlock { Get-Disk} | sort PSComputerName | ft PSComputerName,AllocatedSize,BusType,FriendlyName -AutoSize -groupby PScomputername |
Ce qui donne un résultat de ce type:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
PSComputerName: SWIGEHPV205 PSComputerName AllocatedSize BusType FriendlyName -------------- ------------- ------- ------------ ServerHPV05 2199035784704 6 NETAPP LUN Multi-Path Disk Device ServerHPV05 2198888778240 6 NETAPP LUN Multi-Path Disk Device ServerHPV05 2198888778240 6 NETAPP LUN Multi-Path Disk Device ServerHPV05 1099604782080 6 NETAPP LUN Multi-Path Disk Device ServerHPV05 2198888778240 6 NETAPP LUN Multi-Path Disk Device ServerHPV05 2089229345280 6 NETAPP LUN Multi-Path Disk Device ServerHPV05 1000171331584 8 HP LOGICAL VOLUME SCSI Disk Device ServerHPV05 1075938816 6 NETAPP LUN Multi-Path Disk Device ServerHPV05 4398048990720 6 NETAPP LUN Multi-Path Disk Device ServerHPV05 1099616431616 6 NETAPP LUN Multi-Path Disk Device |
Deux vérifications valent toujours mieux qu’une.
Article initialement publié sur blog.sogeti.ch
Windows/Hyper-V 2012: Nouveau patch pour la stabilité des clusters SCVMM 2012 SP1: Installer l’Update Rollup 2