ESXi 5.5 via iSCSI an QNAP NAS

[hardye]

Hallo VMware-Admins,
ich stehe vor einer Konfigurationsherausforderung zur Anbindung einer QNAP an einen ESXi 5.5 Server. Die QNAP (TS870U-RP) soll via iSCSI an den ESXi zu Backupzwecken angebunden werden. Es handelt sich beim ESXi um die kostenlose Version.
Ich würde die QNAP gerne mit Hilfe 2 1GB LAN an den ESXi anbinden. Am ESXi stehen 2 freie LAN-Ports zur Verfügung, ebenso an der QNAP. Ein Switch dazwischen gib es nicht, die Geräte sind direkt verbunden.
Wie muss ich den ESXi konfigurieren damit die Last auf beide Leitungen verteilt wird und somit 2GBit zur Verfügung stehen?
Am ESXi habe ich den iSCSI Software-Adapter hinzugefügt. Dazu einen vSwitch und einer iSCSI Ip-Adresse aus einem eigenen Bereich.
Was wäre nun zu tun? Was muss ich der QNAP mitteilen?

[irix]

Du solltest den ISCSI Konfiguration Guide lesen
1. 2 VMKs mit IPs aus unterschiedlichen Subnets und je EINER aktiven vmnic (andere nicht zuweisen)
2. Binding der beiden VMKs an den swISCSI Initiator machen
3. QNAP Manual lesen
4. Round Robin als PathPolicy verwenden

Ich habs die Tage fuer ein Synology gemacht inkl. ChapUser und das sollte bei dir nicht viel anders sein. Da die meisten NAS auf Linux basieren schaetze ich das bei 2 zuverwendeten Netzwerkkarten diese IPs aus unterschiedlichen Subnetzen haben sollten weil es hier mit dem Balacing besser klappen wird. Bei unseren EqualLogics ist das was anderes und eher die Ausnahme.

Gruss
Joerg

[hardye]

Hallo irix,

danke!
Ich habe jetzt mal die Netzwerk-Config gemäß der Punkte 1+2 geändert. Ist das so ok?



Wo finde ich dieses ISCSI Guide?
Wo stelle ich die Round Robin Policy am ESXi ein? Oder nur an der QNAP? Das wäre klar...

[irix]

Punk1 Ja, sieht gut aus. Ich wuerde es auch erstmal auf MTU 1500 lassen. Ansonsten dran denken das man auf dem vSwitch, Storage auch die MTU anpassen muss und dann zum Schluss auf dem VMK.

Das mit den aktiven/nicht aktiven vNICS ist einer der Gruende warum man auch 2 vSwitche mit je einer Karte machen kann. Da hat der VMK dann automatisch nur die eine vmnic.


Punkt2. Geh mal auf Host-> Configuration->Storage Adapter->swISCSI -> Properties und dann der 2. Tab. und fuege deinen beiden VMKs hinzu.
Auf diesem Wege sagt man dem ESXi welche VMKs er denn fuer sein iSCSI verwenden soll weil auf dem Papier waere da noch ein VMK fuer vMotion, FT und sein eigenen Management ist auch ein VMK.

Ich empfehle immer einen abschliessenen Reboot des Hosts.


Manual:
http://pubs.vmware.com/vsphere-55/topic ... -guide.pdf
Es geht bei Seite 69 los.

Beim QNAP muesste ich nun die GUI sehen bzw. selber im Manual lesen. Das ueberlass ich erstmal dir und warte auf Fragen

Gruss
Joerg

[hardye]

Prima, danke!
Der QNAP wollte ich zuerst noch eine 2-Port NIC spendieren und es dann in Betrieb nehmen. Das Teil steht noch verpackt im Lager.
Sobald die QNAP läuft (8x3TB im RAID5 und den beiden dedizierten NICs für das iSCSI trunking) werde ich mich an die Konfig der QNAP machen sowie die Anbindung an den ESXi. Dort müssen ja nur die beiden NICs als Team laufen und via Round Robin gruppiert werden. Der 3. und 4. Netzwerkanschluss sollen dann als NAS bzw. Management laufen. Die Anbindung als iSCSI mit 2 Anschlüssen kann ich auch ohne Switch direct durchführen, oder?

[irix]

http://docs.qnap.com/nas/4.1/Home/de/in ... ?iscsi.htm

Ich kann mir vorstellen das du auf QNAP Seite nichts machst weil hier haengt es jetzt mit vom ESXi ab. Des weiteren hattest du doch geschrieben das du keinen pSwitch verwenden tust oder?

Hand aufs Herz... deine ONAP mit nur 3 Platten im RAID5 wird immer der Bottleneck sein. Du hast automatisch Ausfallsicherheit und somit wuerde ich nur begrenzt Energie da noch in Geschwindigkeitssteigendere Massnahmen stecken.

Der ESXi kann folgende PathPolicies verwenden PRO LUN:
- MRU
- Fixed
- RoundRobin
- 3rd.Party MPIO Plugins

Der Default duerfte bei dir MRU sein sprich aller Traffic geht primar bis zu einem Ausfall ueber eine Leitung. Bei einem Neustart des Hosts wird die zuletzt verwendetete Leitung weiterverwendet. Wenn du mehrere Datastores hast kannst du hier eine Manuelle Aufteilung machen

Round Robin. Per Default wird alle 1000 Kommandos die Leitung gewechselt und man bekommt eine Streuung hin. RoundRobin kann beeinflusst werden was die Wechselhaeufigkeit angeht.

[hardye]

Das Doc der QNAP-Seite kenne ich schon, genau so wie http://files.qnap.com/news/pressresourc ... _above.pdf

Die QNAP hat 8 Platten

Die Einrichtung als Round-Robin würde da schon Sinn machen, einfach um beide Leitungen parallel zu belasten, oder?
Wie stelle ich denn die PathPolicies der LUNs um? Später, wenn ich die LUNs zugewiesen habe? Lässt sich das alles nachträglich anpassen?

pSwitch? Also ich verwende keinen Hardware-Switch. Die QNAP soll direkt mit handelsüblichen CAT6 LAN-Kabeln an die beiden Ports des ESXi dran

[irix]

Das Doc der QNAP-Seite kenne ich schon, genau so wie http://files.qnap.com/news/pressresourc ... _above.pdf

Der Guide stammt fuer ein anderes Produkt und ist auch veraltet. Nicht verwenden.

Die QNAP hat 8 Platten

Fuer Ablage/Archiv/MP3 Sammlung ausreichend

Die Einrichtung als Round-Robin würde da schon Sinn machen, einfach um beide Leitungen parallel zu belasten, oder?

Kanonen, Spatzen....
Probier es aus und Berichte.

Wie stelle ich denn die PathPolicies der LUNs um? Später, wenn ich die LUNs zugewiesen habe? Lässt sich das alles nachträglich anpassen?

Das wird pro LUN/Datastore eingestellt und kann natuerlich auch hinterher geaendert und angepasst werden.

Wer aber XXX Host mit XXXXX LUNs hat der stellt sicher das seine ClaimRules und geaenderte Default vorher gesetzt sind und dann stellt er die iSCSI Verbindung her. Ansonsten ist jetzt der Zeitpunkt um sich mit Scripting zu beschaeftigen.

Gruss
Joerg

[Supi]

Ich würde eher die €uros in die kleinste ESXi Lizenz stecken als in 2 weitere NIC.
mit den 8 Sata Platten im Raid 5 sind zwar bis zu 400MB/s möglich.
http://www.tomshardware.com/reviews/RAI ... 662-6.html
Aber ob deine Quelle die Daten so schnell liefern kann?

[stahly]

Wer aber XXX Host mit XXXXX LUNs hat der stellt sicher das seine ClaimRules und geaenderte Default vorher gesetzt sind und dann stellt er die iSCSI Verbindung her. Ansonsten ist jetzt der Zeitpunkt um sich mit Scripting zu beschaeftigen.
...

Konnte man die Claim Rule nicht im vSphere Client einstellen? Irgendwie finde ich die nicht mehr...

[irix]

Wer aber XXX Host mit XXXXX LUNs hat der stellt sicher das seine ClaimRules und geaenderte Default vorher gesetzt sind und dann stellt er die iSCSI Verbindung her. Ansonsten ist jetzt der Zeitpunkt um sich mit Scripting zu beschaeftigen.
...

Konnte man die Claim Rule nicht im vSphere Client einstellen? Irgendwie finde ich die nicht mehr...

Nicht das ich wuesste. Ich kenne es nur von der cmd aus.

Gruss
Joerg

[stahly]

Nicht das ich wuesste. Ich kenne es nur von der cmd aus.

Schade...
P.S. Habe aber gerade gesehen, dass nach dem Update von 5.0 auf 5.5U1 (IBM custom.) die Pfade von Fixed auf RR automatisch umgestellt wurden. Viele Arbeit gespart

[irix]

Nicht das ich wuesste. Ich kenne es nur von der cmd aus.

Schade...
P.S. Habe aber gerade gesehen, dass nach dem Update von 5.0 auf 5.5U1 (IBM custom.) die Pfade von Fixed auf RR automatisch umgestellt wurden. Viele Arbeit gespart

Ich wuerde jetzt Nachlesen was IBM empfiehlt was RR angeht, sprich alle 1000 oder 3 CMDs den Wechsel und was ist konfiguriert

Gruss
Joerg

[stahly]

..
Ich wuerde jetzt Nachlesen was IBM empfiehlt was RR angeht, sprich alle 1000 oder 3 CMDs den Wechsel und was ist konfiguriert
...

Habe ich natürlich gemacht Bei Einsatz des SVCs lautet die Empfehlung:
5.0: fixed
5.5: RR

Deswegen freut mich natürlich, das nach dem Neustart des Hosts plötzlich RR unter den Pfadeigenschaften konfiguriert ist, wo vorher noch fixed eingetragen war.

[irix]

Jein, das RR kann auf unterschiedliche Weise agieren. Der Default ist alle 1000 CMDs ein Wechsel. Aber ich kenne viele Bestpractives wo der Hersteller dann sagt alle 3 CMD. Daneben kann man RR auch sagen alle XXXX Bytes und so.

Also.... was sagt IBM zu RR genau und was ist konfiguriert.

Gruss
Joerg

[hardye]

Hallo zusammen,

danke für die zahlreichen Infos.
Die QNAP hat nun eine weitere Netzwerkkarte. Diese beiden Ports habe ich nun via Port-Trunking zu einem "Balance-rr" zusammen gefasst.
Dem neuen, jetzt einzelnen Port muss ich jetzt noch eine feste IP vergeben. Welche Adresse muss dieser erhalten?
Wie oben schon erwähnt, hat der ESXi ja jetzt an seinen beiden Anschlüssen 2 IPs aus unterschiedlichen Subnetzen.
iSCSI01 mit 10.55.2.2 (255.255.255.0)
iSCSI02 mit 10.56.2.2 (255.255.255.0)

Wie sieht das dann aus? Da bin ich noch nicht so ganz durch gestiegen.
Balance-rr ist auch richtig, oder?

[irix]

Mach kein Port Trunking.
Mach 2 einzelne Ports und gut ist.

Gruss
Joerg

[hardye]

Warum nicht?
Bei 2 einzelnen wird die Last doch nicht mehr verteilt oder?
Dann wäre bei 100MB/s schluss.

[irix]

Weil du auf ESXi Seite RR einstellt wird er alle 1000 CMD den Pfad wechseln.

Gruss
Joerg

[hardye]

Wäre das ein Problem? Ich würde es gerne richtig verstehen. Würdest du nicht die Bandbreite vergrößern wollen / können in diesem Szenario?
2 LAN Ports stehen auf beiden Seiten zur Verfügung, oder wird das nie stabil lauffähig werden können dann?

[rprengel]

Wäre das ein Problem? Ich würde es gerne richtig verstehen. Würdest du nicht die Bandbreite vergrößern wollen / können in diesem Szenario?
2 LAN Ports stehen auf beiden Seiten zur Verfügung, oder wird das nie stabil lauffähig werden können dann?

Wenn die qnap dabei Probleme macht wirst du kaum eine Chance haben das Problem einzukreisen. Die Logfiles sind eher spärlich.
Mein Ansatz ist die Zielspeicher möglichst "dumm" zu halten und alles aus ESX heraus zu erledigen.
Angesehen davon muss man dann nur an einer Stelle auf Konfigurationen und Parameter achten.

Gruss

[Dayworker]

Wie bereits früher geschrieben. Wenn deine Quelle nicht dauerhaft 100MB/s liefern kann, hilft dir Trunking in keinster Weise weiter.

[hardye]

Gerade mal das NAS getestet, beim Schreiben eines Backups via Windows-Freihabe und über einen handelsüblichen Netzwerkanschluss kommt das NAS auf knapp 99% Netzwerklast beim kontinuierlichen Schreiben eines Backups aus BackupExec B2D Jobs.
Mit 2GBit würde es bestimmt um etliches schneller laufen, möchte mir bei iSCSI aber keine Probleme mit fehlerhaften LUNs antun und Euren Ratt, höchstens auf eine Ausfallsicherheit statt Trunking zu setzen, mal befolgen. Obwohl mir immer noch nicht klar ist warum der Esxi oder die QNap das nicht stabil hinbekommen sollten.
Und das Problem mit dem Umschalten nach 1000 Paketen ist mir irgendwie auch noch nicht klar geworden. Habt ihr zu dem Thema noch mehr Erfahrungen und Hintergrund-Infos?

[PeterDA]

Hi,
Was du bei iSCSI haben möchtest ist Multipathing mir Round Robin. Wenn du jetzt auf Storage Seite einen Trunk/Channel baust dann ist das ein Pfad bestehend aus zwei Leitungen. wie Willst du jetzt Mulitpathing machen, wenn du im Storage nur einen Pfad hast?? Damit es wieder Sinn macht müsstest du jetzt auch einen LACP Trunk auf dem ESXi schalten. Dazu brauchst du aber dSW bzw. Ent+. Wir gehen meistens sogar hin und machen zwei iSCSI Subnetze. Wenn dann eins gestört ist läuft alles weiter. Geht aber nicht bei jeden Storage (z.B. EQL und Lefthand/StoreVirtual.


Gruß Peter

[~thc]

Mit 2GBit würde es bestimmt um etliches schneller laufen...

Weil wir das hier im Forum oft zu hören bekommen, hier mal ganz deutlich:

Layer 2 Port Teaming/Trunking mit zwei mal 1 GBit entspricht nicht netto 2 GBit und hat nicht einfach die doppelte Geschwindigkeit.

Auch wenn ESXi oder NAS und der pSwitch mehrere pNICs zu einem (logischen) Team/Trunk zusammenbinden, bleiben das physisch zwei Netzwerkkarten mit eigener MAC-Adresse, die nach wie vor einzeln geswitcht werden. Einzelne IP-Verbindungen laufen dabei immer nur über einzelne pNICs (von MAC zu MAC). Das Team / der Trunk hat lediglich die Brutto-Kapazität von 2 GBit bei mindestens zwei separaten IP-Verbindungen.

In deinem Szenario könntest du also Layer 2 Teaming/Trunking nur dann sinnvoll anwenden, wenn die Software mindestens zwei separate IP-Verbindungen zum NAS parallel aufbaut.

Das von irix und PeterDA vorgeschlagene MP/RR nutzt zwei separate Netzwerkpfade und ist ein Layer 3 Teaming, dass durch seinen Wechsel der Storage-Kommandos in 1000er-Einheiten (1000 auf Pfad A, 1000 auf Pfad B, 1000 auf Pfad A...) ein Failover-Team darstellt, das die I/O-Leistung steigern kann. Der jeweils "andere" Pfad wird parallel von dieser iSCSI-Session nicht aktiv genutzt. Prinzipiell wäre das machbar, aber:

However, a vSphere host does not support multiple connections per [iSCSI] session at this time.

(Aus dem 2013er iSCSI Best Practices Guide von VMWare)