Publié dans VSAN

VSAN – Overall disks health et Software state health errors

 

Nous avons rencontré des erreurs Overall disks health et Software state health :

 

 

Cela concernait 4 HDD de deux ESXi différents :

 

 

Au niveau vmkernel.log, on apercevait les messages d’erreurs suivants :

2016-11-23T13:22:35.056Z cpu0:33702)NMP: nmp_ThrottleLogForDevice:3298: Cmd 0x12 (0x439f32e28e00, 0) to dev « naa.50000397285891d1 » on path « vmhba0:C0:T5:L0 » Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0. Act:NONE

2016-11-23T13:15:58.832Z cpu4:50814 opID=352896dc)PLOG: PLOGOpenDevice:3703: Disk handle open failure for device naa.50000397285891d1:2, status:Busy

2016-11-23T13:15:58.838Z cpu4:50814 opID=352896dc)PLOG: PLOGOpenDevice:3703: Disk handle open failure for device naa.50000397285891d1:2, status:Busy

Ceci semblait indiquer un problème sur le backend.

De notre côté, les storage providers étaient tous up and running :

 

 

Nous avons depuis la ruby vsphere console vérifié le statut du cluster vSAN et son état de santé. Tout était ok :

 

 

Sur les ESXi impactés, nous avons vérifié l’état d’un des disques non healthy.

Le paramètre In CMMDS était à false au lieu de true.

 

 

Nous avons essayé de monter le disk group, sans succès :

 

 

unable to mount: Disk with VSAN uuid 52431ec7-7309-e02e-0a8d-bb530653f54c failed to appear in LSOM

Nous avons alors décidé de mettre l’esxi en maintenance et de supprimer le disk group puis de le réajouter :

Esxi in maintenance mode with full data migration :

 

 

Pour la suppression des disques du disk group il a fallu sélectionner no data migration, sinon nous avions une erreur :

 

 

 

 

A chaque remove de disque, nous vérifions l’état du cluster vSan :

 

 

Nous avons ensuite ré-ajouter le disk group :

 

 

Sortie l’Esxi de maintenance mode et vérifié le health. Les erreurs avaient disparues.

 

 

Share

VSAN – Changer la VM Storage Policy à la volée

 

Un des gros avantages de VSAN est de pouvoir modifier la VM Storage Policy à la volée. Pour divers raisons, vous pouvez avoir à modifier un ou plusieurs paramètres de la Policy. Par exemple, passer d’un FTT 1 à un FTT2 ou changer le nombre de stipe. VSAN offre la possibilité de le faire et ce pendant que les VMs sont Up and Running.

Dans notre cas, nous avons voulu passer notre default Storage Policy d’un FTT1 à FTT2.

Avant le changement, une VM sur le cluster avait 2 copies de vmdk et un witness :

 

vsanonthefly1.jpg

 

Via ESXCLI, on voit la default policy :

 

vsanonthefly2.jpg

 

On va changer la storage policy à la volée en passant le Number of failures to tolerate :

 

 

Appliquer les changements à la volée :

 

 

Voici les changements à la volée qui nécessitent la création d’un nouveau tout nouveau réplica avant de synchroniser les objets avec la VM (Attention donc à l’espace disponible). Ceci rajoutera demadera également plus de ressources au cluster :

  • Agrandir la read cache reservation

  • Changer le stripe width

  • Agrandir l’Object Space Reservation.

  • Changer le FTT si le read cache reservation est different de 0

 

Après l’augmentation du FTT, on peut voir que les nouveaux objets sont en cours de reconfiguration :

 

vsanonthefly3.jpg

 

Que l’objet est Noncompliant pendant la copie :

 

 

A la fin de la synchronisation, vous retrouvez les différentes copies et les nouveaux objets witness :

 

vsanonthefly4.jpg

 

 

Share