Optimisation de la pile client / serveur NFS

J'ai un serveur CentOS 5 VMWare se connectant à une machine OpenSolaris 2009.06 sur NFS qui contient les images de disque. Mes machines virtuelles semblent être limitées par des E / S lentes, je voudrais donc faire tout mon possible pour optimiser la connexion.

Je ne suis pas sûr de la meilleure façon de mesurer le débit sur un système de production, mais certains tests non scientifiques utilisant dd bs=1024k count=400des écritures show local (OpenSolaris) de ~ 1,6 Go / s et des écritures distantes (CentOS) ~ 50 Mo / s. J'imagine que ceux-ci sont inférieurs à ce que j'obtiens réellement puisque 7 machines virtuelles fonctionnent actuellement sur la connexion.

Actuellement, les 2 machines sont des gigE à connexion directe avec des trames jumbo activées sur les deux cartes réseau (MTU = 9000). À part cela, aucune optimisation n'a été effectuée. Le montage / exportation NFS utilise les valeurs par défaut.

Où dois-je commencer à tourner les boutons pour améliorer les performances?

Juste pour clarifier, vous obtenez 50 Mo / s avec NFS sur une seule connexion Ethernet Gb?

Et le serveur hôte exécute CentOS avec VMware Server installé, qui à son tour exécute les 7 machines virtuelles? Y a-t-il une raison particulière pour laquelle vous avez choisi CentOS et VMware Server combinés, plutôt que VMware ESXi qui est une solution plus performante?

Les 50 Mo / s ne sont pas excellents, mais ce n'est pas beaucoup moins que ce à quoi vous vous attendez sur un seul câble réseau Gb - une fois que vous aurez mis les ajustements NFS que les gens ont mentionnés ci-dessus, vous allez peut-être envisager 70 - 80 Mo / sec. Options selon:

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

sont probablement raisonnables pour vous aux deux extrémités du système.

Pour aller au-dessus de cela, vous devrez examiner l'association des cartes réseau en paires, ce qui devrait augmenter votre débit d'environ 90%. Vous pourriez avoir besoin d'un commutateur qui prend en charge 802.3ad pour obtenir les meilleures performances avec l' agrégation de liens .

Une chose que je suggérerais cependant, c'est que votre débit d'E / S sur la boîte OpenSolaris semble étrangement élevé, 12 disques ne sont pas susceptibles de prendre en charge 1,6 Go / s de débit, et cela peut être fortement mis en cache par Solaris + ZFS.

Pour nos machines RHEL / CentOS 5, nous utilisons les drapeaux de montage suivants

nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, hard, intr, noatime

La nouvelle version du noyau Linux prend en charge des paramètres rsize / wsize encore plus grands, mais 32k est le maximum pour le noyau 2.6.18 dans EL5.

Sur le (s) serveur (s) NFS, au moins pour Linux no_wdelay est censé aider si vous avez un contrôleur de disque avec BBWC. De plus, si vous utilisez l'indicateur noatime sur les clients, il est probablement judicieux de monter également les systèmes de fichiers sur les serveurs avec noatime.

Et, comme cela a déjà été mentionné, ne vous embêtez pas avec UDP. Avec les réseaux à plus haut débit (1 GbE +), il y a une petite chance, mais non nulle, qu'un bouclage du numéro de séquence entraîne une corruption des données. En outre, s'il existe une possibilité de perte de paquets, TCP fonctionnera mieux que UDP.

Si vous ne vous souciez pas autant de l'intégrité des données, l'option d'exportation "async" peut être une amélioration majeure des performances (le problème avec async est que vous risquez de perdre des données si le serveur tombe en panne).

De plus, au moins pour le serveur Linux, vous devez vous assurer d'avoir suffisamment de threads de serveur NFS en cours d'exécution. Le 8 par défaut est bien trop bas.

J'ai fait une fois un test avec un Dell R710, 1 CPU, 4 Go de RAM, 6 disques SATA avec RAID-10. Le client était un sun x2100, avec CentOS 5.3 et les paramètres nfs comme mentionné ci-dessus

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

monté des deux côtés avec noatime.

J'ai également grimpé jusqu'à nfsds à 256 et utilisé le planificateur noop pour le contrôleur de raid perc6. Une autre chose que j'ai faite a été d'aligner les partitions sur la taille de bande de 64 Ko du contrôleur RAID.

puis j'ai mesuré les performances nfs avec dd - pour les lectures, je pouvais remplir le tube gigE mais pour les écritures, je ne pouvais obtenir que des résultats légèrement meilleurs que vous. Avec async activé, je pouvais obtenir de 70 à 80 Mo / s, mais async n'était pas une option pour moi.

Peut-être que vous ne pouvez pas obtenir plus avec nfs à partir d'un lien gigE?

Essayez ceci: Désactivez temporairement le journal d'intention ZFS (ZIL) sur le serveur NFS OpenSolaris en procédant comme suit:

1. echo zil_disable/W0t1 | mdb -kw
2. remonter la partition de test

Ensuite, testez à nouveau. Vous pouvez utiliser zilstat pour vous assurer qu'il n'y a vraiment plus d'E / S dans le ZIL. Si le test s'exécute plus rapidement, vous savez que le problème de performances a quelque chose à voir avec le ZIL. S'il fonctionne toujours lentement, vous savez que le ZIL n'est pas le coupable et que l'utilisation d'un SSD pour le ZIL ne vous aidera pas non plus. Voir le Guide de réglage ZFS Evil pour plus d'informations sur le ZIL.

Une autre option serait de capturer le trafic réseau (par exemple avec Wireshark) et de voir s'il y a des problèmes, par exemple avec les trames Jumbo. Vérifiez que les paquets sur le fil ressemblent à ce que vous attendez de votre configuration. Y a-t-il une mauvaise fragmentation? Y a-t-il des retransmissions?

Augmenter les tailles de charge utile en lecture et en écriture peut aider. Surtout en conjonction avec des trames jumbo.

J'ai tendance à trouver 32k pour être optimal.

rsize=32768,wsize=32768

Le passage au transport UDP est bien sûr plus rapide que TCP, car il économise les frais généraux du contrôle de transmission. Mais il n'est applicable que sur des réseaux fiables et lorsque NFSv4 n'est pas utilisé.

Les performances NFS sur ZFS sont considérablement améliorées en utilisant un SSD pour le journal d'intention ZFS (ZIL) car cela réduit la latence des opérations. Ce fil sur VMWare NFS sur les performances ZFS sur les listes de diffusion OpenSolaris NFS et ZFS contient des informations supplémentaires, y compris un outil de référence pour voir si les performances ZIL sont le goulot d'étranglement.

Pour info la commande dd écrira dans le cache et pas de disque, ceci vous pouvez obtenir des nombres fous comme 1.6G / s parce que vous écrivez sur la RAM et non sur le disque sous Solaris vous pouvez utiliser le "-oflag = sync" pour forcer les écritures sur le disque