2 votes

Performances d'écriture NFS

Nous avons trois hôtes VMware ESXi 4 qui servent des machines virtuelles à partir d'un partage NFS OpenFiler. Chaque hôte dispose d'une connexion gigabit directe au NAS. Bien que les performances en lecture soient excellentes, l'écriture de fichiers à l'intérieur des VM invitées souffre.

La configuration recommandée pour l'intégrité des données est d'exporter les partages NFS avec l'option sync et monter ext3 avec data=journal .

J'aimerais comparer le comportement de la configuration d'intégrité maximale avec celui de la configuration de performance d'E/S maximale. Pour configurer la performance, j'ai exporté le partage NFS en tant que

/mnt/raided/main/vm 10.0.0.0/255.255.0.0(rw,anonuid=96,anongid=96,secure,root_squash,wdelay,async)

alors que ext3 est monté avec

/dev/raided/main /mnt/raided/main ext3 defaults,usrquota,grpquota,acl,user_xattr,data=writeback,noatime

Ces options de configuration me permettront-elles d'obtenir des performances optimales en matière d'E/S ? Et si je changeais de système de fichiers ? Le système XFS améliorera-t-il les performances de manière significative ?

À part le plantage du NAS ou les pannes de courant, qu'est-ce qui peut causer des problèmes d'intégrité des données avec cette configuration ?

2voto

LuckySevens Points 586

Je réfléchirais sérieusement à l'utilisation de la synchronisation. Cela me rappelle le discours de Dirty Harry "Do you feel lucky".

NFS v2 et v3 est conçu de telle sorte que lorsque l'écriture est acceptée par le serveur au client, les données sont sur le disque. Cela permet à NFS d'être sans état et, par conséquent, le serveur POURRAIT redémarrer entre chaque demande. On espère que ce n'est pas le cas, mais cela pourrait se produire.

Cela signifie que si le client voit l'ACK sur l'écriture, il n'a plus à se préoccuper de la présence des données sur le disque.

Si vous utilisez async, ce n'est plus vrai. Ce sera cependant beaucoup plus rapide. En fait, si vous utilisez l'asynchronisme et que le serveur tombe en panne, vous devriez probablement redémarrer les clients, à moins que vous ne sachiez exactement ce qu'ils font, car s'ils s'attendent à ce que plusieurs fichiers soient synchronisés, le client peut croire qu'ils sont synchronisés, alors qu'en fait ils ne le sont pas.

2voto

David Mackintosh Points 14093

Je crois savoir qu'OpenFiler est basé sur la famille de systèmes d'exploitation CentOS/RedHat. Le serveur nfs de Linux n'est pas le meilleur pour commencer*, et celui de CentOS/RedHat est plus mauvais que la moyenne.

*= par rapport aux filers NetApp, *bsd ou aux serveurs Solaris.

(Je me demande si je vais me faire down-modder pour cela).

1voto

wazoox Points 6554

Oui, 'sync' est définitivement un énorme destructeur de performance en écriture. Je ne l'envisagerais jamais à moins que la demande d'intégrité des données soit élevée. Si vous n'avez pas de RAID et d'onduleur avec batterie, ne vous en préoccupez pas car cela n'aura de toute façon que peu ou pas d'effet.

'ext3 data=journal' n'aide pas non plus. Si vous avez besoin de performances en écriture, abandonnez ext3 et optez pour xfs, c'est tellement plus rapide que ce n'est même pas drôle.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X