IO disque lente sur ESXi, encore plus lente sur une VM (freeNAS + iSCSI)

Pour accélérer le processus, vous aurez besoin de plus de RAM. Je commencerais par ces quelques améliorations progressives.

Tout d'abord, accélérer le système de fichiers : 1) ZFS a besoin de beaucoup plus de RAM que vous n'en avez pour utiliser le cache ARC. Plus il y en a, mieux c'est. Si vous pouvez l'augmenter d'au moins 8 Go ou plus, vous devriez constater une nette amélioration. Les nôtres contiennent 64 Go.

2) Ensuite, j'ajouterais un disque ZIL Log, c'est-à-dire un petit disque SSD d'environ 20 Go. Utilisez un type SLC plutôt que MLC. La recommandation est d'utiliser 2 disques ZIL pour la redondance. Cela accélérera énormément les écritures.

3) Ajoutez un disque L2ARC. Il peut s'agir d'un SSD de bonne taille, par exemple un disque MLC de 250 Go. Techniquement parlant, un L2ARC n'est pas nécessaire. Cependant, il est généralement moins cher d'ajouter une grande quantité de stockage rapide SSD que plus de RAM primaire. Mais commencez par ajouter autant de RAM que vous pouvez le faire/le payer.

Il existe un certain nombre de sites Web qui prétendent aider à l'optimisation de zfs en général et ces paramètres/variables peuvent être définis via l'interface graphique. Cela vaut la peine de chercher/essayer.

Consultez également les forums de freenas. Vous y recevrez peut-être un meilleur soutien qu'ici.

Deuxièmement : vous pouvez accélérer le réseau. Si vous avez plusieurs interfaces NIC dans votre serveur supermicro. Vous pouvez les relier par canal pour doubler le débit du réseau et assurer une certaine redondance. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004088

Quelques suggestions.

• Le RAID 1+0 ou les miroirs ZFS sont généralement plus performants que le RAIDZ.
• Vous ne mentionnez pas les spécifications réelles de votre serveur de stockage, mais quel est le type/la vitesse de votre CPU, la quantité de RAM et le contrôleur de stockage ?
• Un commutateur de réseau est-il impliqué ? Le stockage est-il sur son propre réseau, isolé du trafic des machines virtuelles ?

Je dirais que 80 Megabytes/seconde est lent pour un test direct sur le système FreeNAS. Vous avez peut-être un problème de disque. Utilisez-vous des disques "Advanced Format" ou à secteurs de 4K ? Si oui, il pourrait y avoir problèmes d'alignement des partitions qui affecteront vos performances.

Ce que vous constatez n'est probablement pas une surcharge de traduction, mais une baisse de performance due à un modèle d'accès différent. Les écritures séquentielles sur un volume ZFS créent simplement un flux de données quasi-séquentiel à écrire sur vos disques physiques sous-jacents. Les écritures séquentielles dans un datastore VMFS au-dessus d'un volume ZFS créent un flux de données qui est "percé" par des mises à jour de métadonnées de la structure du système de fichiers VMFS et des demandes fréquentes de synchronisation / vidage du cache pour ces mêmes métadonnées. Les écritures séquentielles sur un disque virtuel à partir d'un client ajouteraient encore plus de "perçage" de votre flux séquentiel en raison des métadonnées du système de fichiers de l'invité.

Le remède habituellement prescrit dans ces situations est l'activation d'un cache d'écriture qui ignore les demandes de vidage du cache. Cela atténuerait les problèmes d'écriture aléatoire et de synchronisation et améliorerait les performances de vos hôtes VM. Gardez cependant à l'esprit que l'intégrité de vos données serait menacée si le cache n'était pas capable de persister en cas de coupure de courant ou de redémarrage soudain.

Vous pouvez facilement tester si vous atteignez les limites de votre disque en lançant quelque chose comme iostat -xd 5 sur votre boîtier FreeNAS et regarder la taille des files d'attente et les statistiques d'utilisation de vos périphériques physiques sous-jacents. Exécuter esxtop en disk device devrait également vous aider à avoir une idée de ce qui se passe en affichant les statistiques d'utilisation du disque du côté ESX.

J'utilise actuellement FreeNas 8 avec deux matrices Raid 5 sSata attachées au serveur. Le serveur dispose de 8 Go de mémoire vive et de deux processeurs Intel Xeon à cœur unique.

Mes performances ont été sensiblement différentes de celles des autres.

Je n'utilise pas de MPIO ni d'équilibrage de charge sur les cartes réseau. Je n'utilise qu'une seule carte réseau Intel GIGE 10/100/1000 pour serveur.

Les deux baies comportent cinq disques de 2,0 To, soit un espace RAID5 d'environ 7,5 To.

J'utilise ces deux tableaux pour deux fonctions différentes :

1) Le réseau #1 est attaché à un serveur Intel HPC exécutant Centos 5.8 et PostGres. Le système de fichiers est ext4. J'ai pu obtenir un pic de 800 Mbps/sec sur ce réseau.

2) Le tableau n° 2 est utilisé pour les VM de Citrix Xenserver 6 Centos. Ces partitions de 200 Go offrent des performances exceptionnelles. Chacune des machines virtuelles exécute des serveurs de signalisation SIP en temps réel qui prennent en charge 5 à 10 000 appels simultanés à 500-1000 CPS. La base de données locale écrit les CDR sur ces partitions avant que le serveur de base de données principal ne les copie dans ses tables. J'ai également pu obtenir un pic de 800 Mbps/sec sur cette matrice.

Maintenant, je ne suggérerais pas d'utiliser une matrice iSCSI FreeNas comme solution principale pour les grandes partitions de base de données. Je l'ai fait fonctionner sur une partition SAS 10K RPM Raid 10 sur le serveur de base de données.

Mais, il n'y a absolument aucune raison pour que vous ne puissiez pas envoyer votre trafic de données à travers un simple réseau Ethernet commuté vers un serveur raisonnablement configuré exécutant FreeNAS et l'envoyer au pic théorique de GIGE.

Je n'ai pas encore testé le débit de lecture, mais le RAID5 est plus lent en lecture. Donc, il devrait être aussi bon ou meilleur.

FreeNAS s'adapte toujours bien à l'augmentation du trafic qui lui est demandé. Tout serveur CentOS 5.8 va utiliser son propre cache pour mettre en mémoire tampon les données avant de les envoyer aux matrices iSCSI. Donc, assurez-vous d'avoir suffisamment de mémoire sur vos hôtes VM et vous serez satisfait de vos performances.

À mon avis, rien ne permet de mieux tester une technologie que les applications de base de données et les applications de trafic en temps réel.

Je pense aussi que l'ajout d'une fonction de cache en écriture dans la mémoire du système serait bénéfique, mais mes chiffres de performance montrent que FreeNAS et iSCSI sont très performants !

Ça ne peut que s'améliorer.

Tout d'abord, les performances de VMware ne sont pas vraiment un problème de protocole iSCSI (sur FreeNAS) ou NFS 3 ou CIFS (Windows), c'est un problème d'écriture dans le système de fichiers XFS et de statut 'sync'.

FreeNAS a une propriété appelée "sync" et elle peut être activée ou désactivée. "zfs sync=always" est défini par défaut et provoque la purge de chaque écriture. Cela ralentit considérablement les performances mais garantit les écritures sur le disque. Par exemple, l'exécution de VMware ESXI 5.5 et de FreeNAS sur un équipement moderne (CPU 3.x GHZ, disque dur Seagate 7200, réseau 1GigE) sans contrainte donne typiquement des performances de 4-5MB/sec sur un clone VMware ou une robocopie Windows ou toute autre opération d'écriture. En définissant "zfs sync=disabled", les performances d'écriture atteignent facilement 40 Mo et même 80 Mo (c'est-à-dire des mégaoctets par seconde). C'est 10x-20x plus rapide avec sync-disabled et c'est ce à quoi on peut s'attendre..... MAIS les écritures ne sont pas aussi sûres.

J'utilise donc sync=disabled 'temporairement' lorsque je veux faire un tas de clones ou une robocopie de signification, etc. Puis je réinitialise sync=always pour le fonctionnement 'standard' de la VM.

FreeNAS dispose d'un 'scrub' qui vérifie tous les octets sur le disque... cela prend environ 8 heures pour 12TB et je le lance une fois par semaine comme suivi pour m'assurer que les octets écrits pendant sync=disabled sont OK.