VMware-Forum

Hallo zusammen,

was ist die höchste, sinnvollste Anzahl an iSCSI-Kernels, wenn es um Software iSCSI-Adapter an einem iSCSI Storage geht?

Angenommen, es stehen am Storage 4 Channels active/active zur Verfügung, die evtl. directAttached an die 4 pNICs vom ESX gehen. Über den iSCSI Software Adapter sind die 4 Channels mit je einem Kernel verbunden. Die LUN ist an allen Channels gemappt. Also stehen 4 Pfade zur LUN bereit, die im RR Mode vewendet werden. JumboFrames auf allen Komponenten.

Sicherlich würden 4 oder sogar 8 iSCSI Kernels die ESX CPUs nicht unerheblich kräftig beschäftigen... (?)

Was ist die zu erwartende Bandbreite? Und wäre bei 8 Wegen das doppelte zu erwarten? Ist so eine Skalierung sinnvoll oder sollte man es bei 2x 1Gbit belassen?

Viele Grüße,
Conne

Hi!
Wie viele IOs & Bandbreite brauchen denn die VMs?
Wie viele ESX-Hosts hängen am Storage?
Kann das Storage überhaupt die Leistung liefern?
Viele Grüße,
Jörg

Wie viele IOs & Bandbreite brauchen denn die VMs?

Es geht mir eher um die generelle Funktion, weniger um einen speziellen Fall.

Wie viele ESX-Hosts hängen am Storage?

In meinem oben beschriebenen Beispiel, nur einer.

Kann das Storage überhaupt die Leistung liefern?

Ich gehe davon aus, dass pro iSCSI-Kernel-Port am ESX, ein Channel am Storage zur Verfügung steht, voll active/active.

Mir ist klar, dass sich in einem IP SAN die beteiligten ESX-Host die mögliche Bandbreite zum Storage streitig machen können, hier geht es mir aber eher um das RoundRobin System und die damit verbundene höchstmögliche Leistungssteigerung für den Traffic von und zum Storage.

Da es auch um den iSCSI Softwareadapter vom ESX geht, zählt der natürlich mit zur Rechnung. GbE NICs und pSwitche sind von der Rechnung ausgeschlossen, da sie überall nahezu gleich sind. Sind zwei Mörder-Xeons in einer 4 oder sogar 8 Wege Multipathingkonfig. zwingend oder nebensächlich. Ist es unsinnig mehr als 2 Wege zu fahren oder macht es in jedem Fall Sinn? Und wenn ja, welche Grenzen hat so ein Multipathingsystem?

Ich meine, es würde keinen Sinn machen, wenn ich dem System 8 Wege active/active zum iSCSI Storage zur Verfügung stellen würde, aber mein ESX damit so viel CPU-Last für den Software iSCSI Adapter aufwenden müsste, dass nix mehr für die VMs übrig bleiben würde Oder sowas in der Art.

Ich weiß mitlerweile, dass das RoundRobin System 1000 I/Os pro beteiligtem vmk verarbeitet und dann der nächste Kernel an der Reihe ist. Somit kommt die gewisse Leistungssteigerung zu Stande. Aus zwei mal 1Gbit im RR ergibt sich z.B. ein Faktor von 1,4 für den Traffic.

Mich würden Zahlen bei 4 oder 8 Wegen interessieren.

Gruß,
Conne

Hi!
Genaue Zahlen hab ich keine, aber meine Einschätzung:
CPU ist selten der Engpass bei nem ESX, also 4fach multipathing sollte kein Problem sein. Bei 8fach wäre ich bei kleineren Hosts (die z.B. nu 8 logische CPUs haben) vorsichtig, und denke auch nicht, dass da noch mehr Leistung rausspringt.

Insgesamt sollte man bei performance-Diskussionen immer den kompletten Stack betrachten, vom Gast-OS bis zur Spindel. Der Teil vom ESX zum Storage-Controller ist da nur ein kleiner Teil davon.

Aus Erfahrung: Lass die pSwitches nicht ganz aus den Augen! Wenn dessen Backplane nicht leistungsfähig genug ist, wirklich zwischen (Anzahl-Hosts * Pfade + Storage-Systeme*Pfade) Ports komplette 1GB Bandbreite in SUMME gleichzeitig bereitzustellen, gewinnt man durch round-robin gar nix...

Viele grüße,
Jörg

Hi Jörg,

na das ist doch mal ne Aussage

Ich lese durch, dass 4 Wege doch die maximal sinnvollste Konfig ganz generell ist und ein Leistungszuwachs gegenüber 8 Wegen im Zweifel sehr gering ist.

Das mit den Switchen ist richtig, man hätte nichts vom RoundRobin, wenn ein voll besetzter 8-Port pSwitch nur maximal 5GB/s auf der Platine verarbeiten kann... Muss man den Switch verwenden, sollte man 3 Kabel ziehen

Was die generelle Performance angeht, klar, geht die Kette bei den IOPs der VMs los und endet schließlich bei den Spinden und dem Raidset aufm Storage. Aber mir ging es hier primär ums Multipathing auf der VMware Seite.

Gruß,
Conne