iSCSI QNAP Port-Trunk Verständnisfrage

[Nukite2007]

Hallo zusammen,

wollte mich nur vergewissern, ob folgende Konfig vollständig ist:

- QNAP iSCSI Storage: 2 NIC zu einem Trunk zusammengeschlossen
- am Switch die beiden Ports ebenfalls zusammengefasst
- ESXi 4.1 U1 - Eigenschaften vSwitch zwei Netzwerkkarten hinzugefügt
- Lastenausgleich default Einstellung (anhand der ursprünglichen ID d. v. Ports routen)

Frage an der Stelle - muss am Switch über die beiden Ports der Netzwerkkarten vom ESX kommend ebenfalls ein Trunk erzeugt werden oder reicht es die o.g. Einstellungen im vSwitch so vorzunehmen?


Danke Grüße
Peter

[Tschoergez]

Hi!
Weißt Du, was für eine Art von Trunk die QNAP macht?
willst Du nur Redundanz für Ausfallsicherheit einer Netzwerkkarte, oder auch last-verteilung (bringt aber eigentlich nur was, wenn wirklich die 1GBit-Leitung ein Engpass ist => Keine Ahnung, ob die QNAP so mächtig ist ).?

Normalerweise macht man bei iSCSI kein "Trunking" mit dem Netzwerk-Stack, sondern über den iSCSI-Stack => zwei iscsi-vmkernel-ports, mit jeweils einer fest zugewiesenen NIC (ohne failover im vSwitch), dann den iscsi-initiator die Verbindungen als Storage-pfade sehen lassen (damit gibts nen automatischen Pfad-Failover, bei Bedarf kann man dann noch Round-Robin machen).

Wie das genau geht? Hier lesen
http://virtualgeek.typepad.com/virtual_ ... phere.html

Viele Grüße,
Jörg

[Nukite2007]

Hi Jörg,

ja das QNAP unterstützt folgende Trunking Mode:

- Round Robin
- Active Backup
- Balance XOR
- Broadcast
-IEEE 802.3ad
- Balance-tlb (Adaptive Transmit Load Balancing)
- Balance-alb (Adaptiv Load Balancing)

Denke ersteres würde dann eher Sinn machen oder?

Vorab schon mal vielen Dank für Deinen Ausführungen.

Grüße
Peter

[Tschoergez]

hm, da bin ich jetzt etwas unschlüssig: Die Liste sieht so aus wie die "ganz normalen" Netzwerk-trunking möglichkeiten von nem Linux.
Ich denke ehrlich gesagt nicht, dass die für iSCSI viel bringen (außer die für Failover), weil der Traffice ja vom Server aus angeregt wird, und das Storage "nur" antwortet.

Gibt's denn von QNAP Empfehlungen?

Und such mal hier im Forum, ich erinner mich an ne ähnliche Diskussion auch zur QNAP vor einiger Zeit.
Grüße,
Jörg

[Nukite2007]

Hi Jörg,

eine Empfehlung von QNAP habe ich nicht gefunden.
Ich habe nun folgendes gemacht (im Schnelldurchgang beschrieben)

1.) vSwitch erstellt
2.) vmKernel 2x erstellt
3.) iSCSI Initiator an die beiden NICs gebunden, Failoverpolicy angepasst
4.) iSCSI Disk mit beiden vmkernel verbunden (4 Pfade sichtbar)
5.) Round Robin aktiviert

vorher nachtürlich noc MTU hostgesetzt im QNAP und auf dem vSwitch sowie den beiden vmKernelports

Den Trunk im QNAP habe ich nun nicht gemacht. Da ich nach meinem Verständnis ja jetzt jeweils eine phys. Netzwerkkarte des QNAP an eine phy. NIC des ESX-Servers die wiederum an dem iSCSI Initiator hängt - verbunden ist.

Soweit funktioniert alles. Denke das wäre jetzt eine "empfohlene iSCSI-Anbindung), falls ich nichts vergessen habe

vg und Danke nochmals
Peter

[Tschoergez]

hört sich gut an.
Jetzt hast Du keine Redundanz auf Netzwerkebene (weil ja keine Trunks eingerichtet wurden), aber eben mehrere Pfade aus Storage-Sicht, die jetzt sauber für Failover und Lastverteilung genutzt werden.

Alles bene !

wenn Du natürlich andere Systeme auch an die QNAP anbinden willst, sollten die ebenfalls diese verschiedenen Pfade sehen...

Viele Grüße,
Jörg

[Nukite2007]

okey, jetzt stellt sich noch eine Frage aus Deiner Antwort.. dann gebe ich evtl. Ruhe

gesetz dem Fall ich würde ein Netzwerkkabel vom QNAP abziehen, würde doch ein Pfadwechsel erfolgen.. d.h. meine VMs die auf dem iSCSI Storage laufen sollten davon nix mitbekommen, da ja nur ein Bein wegbricht.

oder bin ich jetzt total falsch?

[Tschoergez]

richtig! Der Pfadwechsel erfolgt dann von Seiten des ESX im Storage-Stack, (sollte auch im vmkernel-log zu sehen sein), unsichtbar für die VMs.

Andere externe Systeme, die nur über eine Netzwerkverbindung auf die QNAP-zugreifen, machen das natürlich nicht.

Bevor's produktiv geht: auf jeden Fall testen!
(Geht sehr risikoarm, wenn Du die VMs auf nen anderen Datastore legst, und zum test erstmal "nur" ne zweite virtuelle Platte oder ne iso-Datei auf die QNAP legst bein den Kabelzieh-tests...)