Optimieren des NFS-Client / Server-Stacks

Ich habe einen CentOS 5 VMWare-Server, der über NFS eine Verbindung zu einem OpenSolaris 2009.06-Computer herstellt, auf dem sich die Disk-Images befinden. Meine virtuellen Maschinen scheinen an langsame E / A gebunden zu sein, daher möchte ich alles tun, um die Verbindung zu optimieren.

Ich bin mir nicht sicher, wie ich den Durchsatz auf einem Produktionssystem am besten messen kann, aber einige unwissenschaftliche Tests mit dd bs=1024k count=400OpenSolaris-Schreibvorgängen (OpenSolaris) von ~ 1,6 GB / s und Remote-Schreibvorgängen (CentOS) mit ~ 50 MB / s. Ich stelle mir vor, dass diese niedriger sind als das, was ich tatsächlich bekomme, da derzeit 7 VMs über die Verbindung laufen.

Derzeit sind die beiden Maschinen direkt mit gigE verbunden, wobei auf beiden Netzwerkkarten Jumbo-Frames aktiviert sind (MTU = 9000). Ansonsten wurden keine Optimierungen vorgenommen. NFS-Mount / Export verwendet Standardeinstellungen.

Wo soll ich anfangen, Knöpfe zu drehen, um die Leistung zu verbessern?

Um dies zu verdeutlichen, erhalten Sie mit NFS 50 MB / s über eine einzelne Gb-Ethernet-Verbindung?

Auf dem Host-Server wird CentOS mit installiertem VMware-Server ausgeführt, auf dem wiederum die 7 VMs ausgeführt werden. Gibt es einen bestimmten Grund, warum Sie sich für CentOS und VMware Server entschieden haben, anstatt für VMware ESXi, eine leistungsstärkere Lösung?

Die 50 MB / s sind nicht großartig, aber sie liegen nicht viel unter dem, was Sie von einem einzelnen Gbit-Netzwerkkabel erwarten würden. Sobald Sie die oben erwähnten NFS-Optimierungen vorgenommen haben, werden Sie sich vielleicht 70 ansehen. 80 MB / s Optionen entlang der Linie von:

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

sind wahrscheinlich für Sie an beiden Enden des Systems vernünftig.

Um darüber hinauszukommen, müssen Sie die Netzwerkkarten paarweise zusammenfassen, was Ihren Durchsatz um etwa 90% erhöhen sollte. Möglicherweise benötigen Sie einen Switch, der 802.3ad unterstützt, um die beste Leistung bei der Link-Aggregation zu erzielen .

Eine Sache, die ich jedoch vorschlagen würde, ist, dass Ihr E / A-Durchsatz auf der OpenSolaris-Box verdächtig hoch klingt, 12 Festplatten wahrscheinlich keinen Durchsatz von 1,6 GB / s unterstützen und dies möglicherweise von Solaris + ZFS stark zwischengespeichert wird.

Für unsere RHEL / CentOS 5-Maschinen verwenden wir die folgenden Mount-Flags

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

Neuere Linux-Kernel-Versionen unterstützen noch größere rsize / wsize-Parameter, aber 32k ist das Maximum für den 2.6.18-Kernel in EL5.

Auf den NFS-Servern hilft no_wdelay zumindest für Linux angeblich, wenn Sie einen Festplattencontroller mit BBWC haben. Wenn Sie das Noatime-Flag auf den Clients verwenden, ist es wahrscheinlich sinnvoll, die Dateisysteme auch mit Noatime auf den Servern bereitzustellen.

Und wie bereits erwähnt, kümmern Sie sich nicht um UDP. Bei Netzwerken mit höherer Geschwindigkeit (1 GbE +) besteht eine geringe Wahrscheinlichkeit, dass eine Umgehung der Sequenznummer zu einer Beschädigung der Daten führt, jedoch nicht Null. Wenn die Möglichkeit eines Paketverlusts besteht, ist TCP leistungsfähiger als UDP.

Wenn Sie sich nicht so viele Sorgen um die Datenintegrität machen, kann die Exportoption "Async" eine erhebliche Leistungsverbesserung darstellen (das Problem bei Async besteht darin, dass Sie möglicherweise Daten verlieren, wenn der Server abstürzt).

Zumindest für Linux-Server müssen Sie außerdem sicherstellen, dass genügend NFS-Server-Threads ausgeführt werden. Die Standardeinstellung 8 ist einfach viel zu niedrig.

Ich habe einmal einen Test mit einem Dell R710, 1 CPU, 4 GB RAM, 6 SATA-Festplatte mit RAID-10 durchgeführt. Der Client war ein sun x2100, sowohl mit CentOS 5.3 als auch mit den oben genannten nfs-Parametern

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

beidseitig mittags montiert.

Ich habe auch auf nfsds bis 256 gestoßen und den Noop-Scheduler für den Perc6-Raid-Controller verwendet. Eine andere Sache, die ich tat, war, die Partitionen an der 64K-Streifengröße des RAID-Controllers auszurichten.

dann habe ich die nfs-leistung mit dd gemessen - für lesungen konnte ich die gigE-rohr füllen, aber für schreibvorgänge konnte ich nur geringfügig bessere ergebnisse erzielen als du. Bei aktiviertem Async konnte ich 70 bis 80 MB / s erreichen, aber Async war für mich keine Option.

Vielleicht können Sie mit nfs über einen gigE-Link nicht mehr erreichen?

Versuchen Sie Folgendes: Deaktivieren Sie das ZFS Intent Log (ZIL) vorübergehend auf dem OpenSolaris NFS-Server mit den folgenden zwei Schritten

1. echo zil_disable/W0t1 | mdb -kw
2. Hängen Sie die Testpartition erneut ein

Dann erneut testen. Sie können zilstat verwenden , um sicherzustellen, dass der ZIL wirklich keine E / A mehr enthält. Wenn der Test schneller ausgeführt wird, wissen Sie, dass das Leistungsproblem etwas mit der ZIL zu tun hat. Wenn es immer noch langsam läuft, wissen Sie, dass der ZIL nicht der Schuldige ist und dass die Verwendung einer SSD für den ZIL auch nicht hilft. Weitere Informationen zum ZIL finden Sie im ZFS Evil Tuning Guide .

Eine andere Möglichkeit wäre, den Netzwerkverkehr (z. B. mit Wireshark) zu erfassen und festzustellen, ob Probleme auftreten, z. B. mit den Jumbo-Frames. Stellen Sie sicher, dass die Pakete auf dem Kabel so aussehen, wie Sie es von Ihrer Konfiguration erwarten. Gibt es eine schlechte Fragmentierung? Gibt es erneute Übertragungen?

Das Erhöhen der Nutzlastgrößen für Lesen und Schreiben kann hilfreich sein. Besonders in Verbindung mit Jumbo-Frames.

Ich finde 32k optimal.

rsize=32768,wsize=32768

Die Umstellung auf UDP-Transport ist natürlich schneller als TCP, da dadurch der Aufwand für die Übertragungssteuerung gespart wird. Dies gilt jedoch nur für zuverlässige Netzwerke, in denen NFSv4 nicht verwendet wird.

Die NFS-Leistung unter ZFS wird durch die Verwendung einer SSD für das ZFS-Absichtsprotokoll (ZIL) erheblich verbessert, da dies die Latenz von Vorgängen verringert. Dieser Thread zu VMWare NFS zur ZFS-Leistung in den OpenSolaris NFS- und ZFS-Mailinglisten enthält weitere Informationen, einschließlich eines Benchmark-Tools, um festzustellen, ob die ZIL-Leistung der Engpass ist.

Zu Ihrer Information, der Befehl dd schreibt in den Cache und keine Festplatte. Dies kann zu verrückten Zahlen wie 1,6 G / s führen, da Sie unter Solaris in den RAM und nicht in die Festplatte schreiben. Mit "-oflag = sync" können Sie Schreibvorgänge auf die Festplatte erzwingen