Durchsatz mit NFS-Datastores auf NetApp optimieren

[GTMK]

Moin,

bislang betreibe ich eine ESX-Farm mit einem iSCSI-Storage von LeftHand auf einer dedizierten Switch-Infrastruktur. Alle ESXe sind mit jeweils zwei (1 GbE-) NICs über zwei unterschiedliche Switche angebunden, die LeftHand-Knoten ebenfalls. Auf dem iSCSI-vSwitch sind 2 VMkernel-Ports im gleichen Subnetz konfiguriert, von denen einer an die eine und der andere an die andere NIC gebunden ist. Auf diese Weise kann ich auf jedem ESX einen Durchsatz von 2 Gbit zum Storage erreichen. Bislang reicht das auch.

Jetzt soll die LeftHand durch eine NetApp abgelöst werden (die selbst mit 10 GbE angebunden ist) und NFS eingesetzt werden, wo obige Konstruktion nicht mehr funktioniert. Bei meinen bisherigen Versuchen ist es mir nicht gelungen, einen Durchsatz von mehr 1 Gbit zu erreichen.

Wie muss ich vSwitch, VMkernel Ports und NICs konfigurieren, um auf 2 Gbit zu kommen?

Das Argument für die Verwendung von NFS-Datastores ist, dass es schlicht einfacher sei... Wir haben auch eine iSCSI-Lizenz für die NetApp. Sollten wir vielleicht doch lieber weiter iSCSI machen?

Viele Grüße

Georg.

[Gad]

Wie misst du den Datendurchsatz zum Storage?

[GTMK]

IOmeter in den beteiligten VMs.

[Whitemoon]

Alle ESXe sind mit jeweils zwei (1 GbE-) NICs über zwei unterschiedliche Switche angebunden, die LeftHand-Knoten ebenfalls. Auf dem iSCSI-vSwitch sind 2 VMkernel-Ports im gleichen Subnetz konfiguriert, von denen einer an die eine und der andere an die andere NIC gebunden ist

Ich dachte immer, bei iSCSI ist aus Gründen der Reduanz und Pfade zwei unterschiedliche Subnetze notwendig.

Jetzt soll die LeftHand durch eine NetApp abgelöst werden (die selbst mit 10 GbE angebunden ist) und NFS eingesetzt werden, wo obige Konstruktion nicht mehr funktioniert. Bei meinen bisherigen Versuchen ist es mir nicht gelungen, einen Durchsatz von mehr 1 Gbit zu erreichen.

Warum? Gerade mit NFS und LACP reicht ein Subnet völlig aus. Die Ports auf der Netapp bzw. SVM (unter C-Mode) zu Multimode LACP konfigurieren. Auf den ESXi-Servern alle Netzwerkkarten für das Subntz in einem vSwitch zusammenfassen und Lastausgleich auf IP-Hash einstellen. Wobei echtes LACP steht nur über Dist. Switches zur Verfügung.

Das Argument für die Verwendung von NFS-Datastores ist, dass es schlicht einfacher sei...

Und auch schneller... weil einfach ein Layer weniger dazwischen ist. Du kannst auch das NFS Volume auch einfach freigeben und direkt auf die Verzeichnisse zugreifen. Des Weiteren wird es dir die Netapp Deduplikationsfunktion danken... dies kann noch effektiver sein.

[GTMK]

Danke für die Anmerkungen...

Ich dachte immer, bei iSCSI ist aus Gründen der Reduanz und Pfade zwei unterschiedliche Subnetze notwendig.

Nö, ist es nicht. Ich habe deine Anmerkung zum Anlass genommen, es zu überprüfen

Gerade mit NFS und LACP reicht ein Subnet völlig aus.

Ich bilde mir ein, dass LACP Endpunkte auf _einem_ Switch benötigt. Die beiden NICs des ESX gehen aber auf zwei unterschiedliche Switche.

Und auch schneller... weil einfach ein Layer weniger dazwischen ist.

Ich war immer der Meinung, das Block Storage eigentlich schneller sein müsste - eben wegen des fehlenden Overhead. Oder meist du damit, dass bei der NetApp der Block Storage ja auf ein Filesystem abgebildet werden muss?

[kastlr]

Hallo zusammen,

ich will jetzt keinen Glaubenskrieg starten, aber warum NFS einen Layer weniger als Block Storage hat erschließt sich mir nicht.

Schließlich muss der NFS Server die Daten schlussendlich auch auf seine Platten schreiben, und da wird wieder SCSI verwendet.

Also findet auch zweimal eine "Konvertierung" statt, denn die "Payload" muss in IP Packete eingepackt werden.
Bei Block Storage ist dass bei FC/FCoE/iSCSI auch erforderlich.

Das Protokoll ist eigentlich Nebensache, denn aus Performance Sicht hat es kaum Einfluss.
Man sollte also das wählen, was am besten in die Umgebung passt bzw. womit man sich persönlich am besten "fühlt".

In Enterprise Umgebungen war/ist Blockstorage aktuell immer noch sehr stark vertreten, NFS findet sich verstärkt im Mid Market Bereich.
Unter anderem deshalb, weil die meisten Hersteller dort Multiprotokoll Arrays verkaufen.

Gruß,
Ralf

[rziwin]

Das Argument für die Verwendung von NFS-Datastores ist, dass es schlicht einfacher sei... Wir haben auch eine iSCSI-Lizenz für die NetApp. Sollten wir vielleicht doch lieber weiter iSCSI machen?

In der genannten Konstellation dürfte nfs gegenüber iSCSI langsamer sein, da nur ein vmkernel auf die nfs Datastores je ESXi zugreifen kann. Multipath funktioniert erst mit ESXi 6.0 und nfs 4.1, welches wiederum NetApp nur im C-DOT Mode neuerer Versionen kann.

Des Weiteren sollte man zwischendurch auch im Kleingedruckten bei Firmen wie Microsoft lesen - bestimmte Server Applikationen werden nur Supported auf Block-Device (FC oder iSCSI) und nicht auf File-Device!

Deduplication funktioniert übrigens auch mit iSCSI.

[GTMK]

Ich habe vSphere 6 im Einsatz, auch NFS 4.1 mit einer NetApp mit cDOT 8.3.2P1 - da sollten alle Voraussetzungen stimmen.

Auf der NetApp sind in der SVM zwei Data-LIFs konfiguriert, deren physikalische Interfaces mit unterschiedlichen Switches verbunden sind. Muss ich auf der NetApp noch mehr konfigurieren?

Wie muss das Load Balancing auf dem vSwitch definiert sein? Dieser hat je einen aktive Uplink auf die beiden Switches, mit denen auch die NetApp verbunden ist.

[Whitemoon]

Auf der NetApp sind in der SVM zwei Data-LIFs konfiguriert, deren physikalische Interfaces mit unterschiedlichen Switches verbunden sind. Muss ich auf der NetApp noch mehr konfigurieren?

Bilden die Switches eine logische Einheit ab, sprich unter einer IP-Adresse erreichbar?

[GTMK]

Nein, das sind zwei separate Switches. Aber was hat die IP-Adresse des Switches damit überhaupt zu tun?

[GTMK]

Der Thread ist zwar schon etwas älter... Ich habe gerade von unserem NetApp-Partner die Information bekommen, dass NetApp auch mit cDOT Session Trunking mit NFS 4.1 (noch?) nicht unterstützt. Mehr als die Geschwindigkeit eines Interfaces erreiche ich in meiner Konfiguration nicht. Daher werde ich wieder iSCSI machen...

Viele Grüße, Georg.