iSCSI, Openfiler & IET
Posted by NiTRo | Filed under Kb, VMware
Si vous avez utilisé l’appliance dédiée au stockage Openfiler, vous avez peut être été confronté aux nombreux problèmes liés à la cible iSCSI IET (comme beaucoup d’utilisateurs).
Le principal symptôme étant un blocage pur et simple des VM lors de fortes activités sur le datastore mais celui ci n’est pas considéré comme dead systématiquement donc d’autres VM (situées sur d’autres datastore) peuvent en pâtir sérieusement. On observe alors une serie de messages d’erreur dans le log du serveur iSCSI :
iscsi_trgt: cmnd_abort(xxxx)
Probablement saturé de demandes liées à ce problème, le support de VMware y a dédié une KB :
OpenFiler uses IET which has the following caveats:
* Does not support SCSI Reservations.
* Inquiry commands do not conform to SCSI Specification.OpenFiler is not a certified storage solution for use within a VMware environment.
Openfiler n’est pas la seule appliance à utilisé la cible iSCSI IET, Synology et Data Robotics souffrent aussi du même problème. Fort heureusement, certains utilisateurs du forum d’Openfiler ont isolés des solutions de contournement :
- esxcfg-advcfg -s 14000 /VMFS3/HBTokenTimeout (DroboElite)
- Disabling Delayed Ack (VMware KB)
Nous avons personnellement testé ces paramètres avec succès sur un NAS Synology.
Loading ...
October 4th, 2010 at 14:39
Salut !
dans quel cadre Openfiler est il supporté par VMware ? test only ?
Dans tes tests, combien de VM fais tu tourner sur un datastore OF ?
merci
October 5th, 2010 at 19:43
Openfiler n’est pas supporté par VMware mais pour ce genre de problème, le NFS est une bonne alternative.
October 7th, 2010 at 20:15
Salut,
J’ai fait le pari (osé) d’avoir de la production sur 2 SAN actif/actif via DRBD, OCFS2, IET et du channel bonding pour les accès iSCSI.
Les 2 SAN sont repartis sur 2 sites reliés en fibre optique et contiennent une trentaine de VM.
Il faut bien avouer que c’est extrêmement robuste. Ils ont subi de la rupture de lien, du reboot sauvage, de l’arrêt assez long et malgré tout ça ils sont toujours retombés sur leurs pattes sans intervention humaine.
Etrangement avec OpenFiler je n’ai jamais réussi à obtenir quelque chose de vraiment stable, notamment lorsqu’il y a un peu de charge.
Finalement, rien ne vaut le home-made
.
October 10th, 2010 at 22:39
Juste pour info, pourquoi utilises tu OCFS2 alors que tu fais du iscsi donc pas de filesystem “en dessous” du VMFS ?
October 11th, 2010 at 20:27
Avec OCFS2 on est sûr de supporter les accès concurrents sur une même LUN. OCFS2 a fait ses preuves, tout comme GFS d’ailleurs.
Je ne me suis jamais posé la question de savoir si VMFS supportait les accès concurrents ?
Après il y avait certes la possibilité de créer plusieurs LUN mais ce n’est pas ce qu’on souhaitait.
Cependant j’aurais préféré faire du FC au lieu de l’iSCSI mais le seul souci c’est que SCST (bien que plus complexe à mettre en oeuvre) souffre d’un manque de retour sur sa fiabilité…
October 11th, 2010 at 20:41
J’aurais du me relire avant de valider
.
C’est évident que le VMFS supporte les accès concurrents… Sinon ça serait de l’Hyper-V 1.0
.
Cela dit, après rapide vérification, il semblerait que du VMFS directement couplé à du DRBD soit pas d’une extrême robustesse. J’ai trouvé des témoignages de personnes qui ont perdu des datastores entiers…
Reste à voir dans quelles conditions ça a été utilisé…
October 11th, 2010 at 22:57
On y retourne… (faudrait que je pense à dormir ces temps-ci).
Je viens de vérifier parce que j’avais un doute.
En fait j’ai complété rêvé, l’OCFS2 n’est pas utilisé.
Je l’avais utilisé pour vérifier que l’actif/actif fonctionnait bien.
L’ESX se réapproprie la LUN et la reformate en VMFS3.
L’OCFS2 n’est même plus activé donc pas de doute possible !!
Je me demandais comment c’était possible de formater en VMFS par dessus de l’OCFS2… forcément je pouvais chercher un moment.
Si on récapitule :
- DRBD Primary/Primary
- iSCSI Target avec la même configuration pour faire du multipathing.
- VMFS3 sur la LUN créée
October 11th, 2010 at 23:08
Je comprends mieux maintenant
October 12th, 2010 at 15:58
Juste pour info, c’est le meme probleme avec les NAS de la marque QNAP, en tout cas pour le model TS-639 qui utilise du IET…
Maintenant j’ai vu aussi du Open iSCSI sur certain model de la marque…
Rien de tel que du FC
October 13th, 2010 at 12:44
Et pour bien completer mon post precedent, j’ai recu la confirmation de QNAP himself via un pote qui est a l’instant a Copenhague que les nouveaux NAS QNAP x59 ne tournent pas IET (ouf) et ils sont iSCSI VMware Ready!