meister00
Goto Top

QNAP + HYPER-V + HP Switch Trunk

hallo,

ich habe ein QNAP TS453A und möchte auf meinem hp switch HP ProCurve 1810G - 24 GE den port trunk einrichten.
habe es als iscsi eingebunden.

wenn ich im nas die netzwerkeinstellungen auf port trunk stelle und 802.3ad dynamic und am hp switch den trunk einrichte mit oder ohne lacp dann ist das nas sofort nicht mehr erreichbar.
was mache ich falsch bzw. was muss ich machen?

danke

Content-Key: 319509

Url: https://administrator.de/contentid/319509

Ausgedruckt am: 19.03.2024 um 11:03 Uhr

Mitglied: psannz
psannz 29.10.2016 um 22:36:54 Uhr
Goto Top
Sers,

LACP ist hier der falsche Ansatz.

MPIO ist viel mehr das Mittel der Wahl. QNAP und Windows Server unterstützen es beide, wobei beim Windows Server das MPIO Feature installier und für iSCSI aktiviert werden muss.
Die Switche sind dabei aussen vor.

Vorteil von MPIO gegenüber LACP ist dass du bei 2*1G wirklich die gesamten 2G nutzen kannst. Redundanz ist bei beiden gegeben.

Grüße,
Philip
Mitglied: meister00
meister00 30.10.2016 um 12:42:07 Uhr
Goto Top
hi,

also brauche im am switch keine trunks bilden?

thx
Mitglied: psannz
psannz 30.10.2016 um 13:16:49 Uhr
Goto Top
Wenn alles über einen Switch läuft brauchst du dann wegen iSCSI auf dem Switch keine Trunks einzurichten.

Wenn es über mehere Switch läuft wäre es Sinnvoll eine redundante Verbindung zwischen den Switchen aufzubauen, sei es via Stacking Kabeln, oder einem Stacking Trunk. Das hat dann aber nichts direkt mit iSCSI, MPIO oder den Anbindungen von Servern und QNAP zu tun.
Mitglied: aqui
aqui 30.10.2016 aktualisiert um 13:29:55 Uhr
Goto Top
Warum sollte LACP falsch sein ??
Egal ob er das Hashing über Mac Adressen oder IPs macht sollte es eine halbwegs granulare Verteilung auf den Links geben im Layer 2.
Das macht natürlich nur dann Sinn wenn es mehrere Partner gibt die über den LAG zugreifen. Ist es immer nur ein Pärchen egal ob L2 oder L3 kommt natürlich keinerlei Lastverteilung bei einem 802.3ad Verfahren zustande, das ist zweifelsohne richtig.
Dann greift im LAG einzig und allein nur der Link Backup was ja nicht gerade der tiegere Sinn von Link Aggregation ist.
Details zum Thema Link Aggregation mit gruseligen HP Switches findest du hier:
Netzwerk Management Server mit Raspberry Pi
Was sagt denn den HP Switch bei einem show trunk oder show lacp ???
DAS wäre hier hilfreich mal zu posten um zu wissen ob der Switch überhaupt einen LAG aktiviert hat.
Vermutlich ist das wegen eines Konfig Fehlers von dir nicht der Fall face-sad
Mitglied: psannz
psannz 30.10.2016 um 13:42:06 Uhr
Goto Top
Zitat von @aqui:

Warum sollte LACP falsch sein ??
Egal ob er das Hashing über Mac Adressen oder IPs macht sollte es eine halbwegs granulare Verteilung auf den Links geben im Layer 2.
Das macht natürlich nur dann Sinn wenn es mehrere Partner gibt die über den LAG zugreifen. Ist es immer nur ein Pärchen egal ob L2 oder L3 kommt natürlich keinerlei Lastverteilung bei einem 802.3ad Verfahren zustande, das ist zweifelsohne richtig.

Und mittels MPIO können bei 2*1G auch tatsächlich 2G auf einem Target genutzt werden. In Verbindung mit MCS natürlich.

LACP hat natürlich auch seine Berechtigung, keine Frage, aber bei iSCSI mit Windows Initiatoren bevorzuge ich MPIO deutlich.
Mitglied: aqui
aqui 30.10.2016 um 16:38:38 Uhr
Goto Top
Wird aber dann vermutlich am QNAP scheitern, denn ich gehe mal davon aus das auch MPIO beidseitig supportet sein muss, oder ?
Tatsächlich 2G kann aber physisch eigentlich nicht sein, denn auch bei 2 mal 1 Gig werden die Daten ja immer nur mit einem 1Gig Clocking über die Leitung gebracht. Die physische Geschwindigkeit bleibt also.
Nur das eben die Kapazität sich wie 2G anfühlt.
Mitglied: psannz
psannz 30.10.2016 um 16:49:45 Uhr
Goto Top
Zitat von @aqui:

Wird aber dann vermutlich am QNAP scheitern, denn ich gehe mal davon aus das auch MPIO beidseitig supportet sein muss, oder ?
Tatsächlich 2G kann aber physisch eigentlich nicht sein, denn auch bei 2 mal 1 Gig werden die Daten ja immer nur mit einem 1Gig Clocking über die Leitung gebracht. Die physische Geschwindigkeit bleibt also.
Nur das eben die Kapazität sich wie 2G anfühlt.

http://files.qnap.com/news/pressresource/product/How_to_connect_to_your ...

MPIO wird ab Firmware 3.2.2 supportet.

QNAP scheint von MC/S zusammen mit MPIO abzuraten. Performance sollte trotzdem - gesetzt dass das Raid schnell genug ist - die 2G saturieren.
Mitglied: meister00
meister00 30.10.2016 aktualisiert um 18:03:05 Uhr
Goto Top
bei uns schaut es so aus:

hyper-v fail over cluster mit 2 servern
jeder server 4xlan(nic team) auf hp switch

qnap port bündelung mit 4xlan 802.3ad auf hp switch
und wenn ich am hp switch einen trunk mit den 4 xlan von qnap mache ist es offline.

danke
Mitglied: psannz
psannz 30.10.2016 um 18:38:24 Uhr
Goto Top
Sers,

Hier nochmal deutlich was Microsoft von LAG/Teaming (via LACP) im Zusammenhang mit iSCSI hält:

Technet: Ask the Primier Field Engineer: Is NIC Teaming in Windows Server 2012 supported for iSCSI, or not supported for iSCSI?

The Technet statement that basically quotes “iSCSI + NIC Teaming not supported” is still true for all teaming solutions, with the EXCEPTION of the Windows Server 2012 inbox NIC Teaming solution we provide.

If iSCSI Initiator is used with dedicated NICs such as in a stand-alone and/or Failover Clustering environment, then NIC Teaming should not be used (because it adds no benefit over MPIO for dedicated NICs).

If iSCSI Initiator is used in a shared NIC scenario (see figure below) such as in a Hyper-V 2012 environment, then iSCSI Initiator used over the Hyper-V switch (and over NIC Teaming) is supported.
Mitglied: meister00
meister00 30.10.2016 um 18:51:37 Uhr
Goto Top
@psannz

danke

und welcher modus ist dann der beste optimale für die qnap

Balance-rr
Balance-xor
Broadcast
802.3ad dynamic

thx
Mitglied: psannz
psannz 30.10.2016 um 21:46:00 Uhr
Goto Top
Zitat von @meister00:

@psannz

danke

und welcher modus ist dann der beste optimale für die qnap

Balance-rr
Balance-xor
Broadcast
802.3ad dynamic

thx

Das vermag ich nicht zu sagen, da ich den von dir gewählten LAG Modus von Switch und Windows Server nicht kenne.
Mitglied: aqui
aqui 31.10.2016 um 09:57:43 Uhr
Goto Top
Was mich zu der Themaitk MPIO nochmal interessieren würde WIE wird das auf Netzwerkseite konfiguriert ??
Leider sagen die Tech Infos von MS oben ja rein gar nix dazu... face-sad
  • 2 Server NICs mit je einer IP im gleichen Netz auf einen Draht (Switch) gesteckt ? Wie siehts hier mit Loop Gefahr aus ?
  • Jede NIC in ein separates VLAN ?
  • Jede NIC einen andere IP und separates VLAN
Wie sieht das auf der Infrastruktur aus und wie werden sollte alles in einer gemeinsamen L2 Domain arbeiten die Loop Verhinderung aus ??
Mitglied: psannz
psannz 31.10.2016 aktualisiert um 11:19:35 Uhr
Goto Top
Zitat von @aqui:

Was mich zu der Themaitk MPIO nochmal interessieren würde WIE wird das auf Netzwerkseite konfiguriert ??
Leider sagen die Tech Infos von MS oben ja rein gar nix dazu... face-sad
  • 2 Server NICs mit je einer IP im gleichen Netz auf einen Draht (Switch) gesteckt ? Wie siehts hier mit Loop Gefahr aus ?
je NIC mit eigener IP zum Switchport. MPIO passiert auf Layer 3 bis 5.
Loop Gefahr besteht nur wenn auf den Server NICs ne Bridge läuft (warum auch immer)

* Jede NIC in ein separates VLAN ?
VLAN ist wie immer optional. Macht natürlich Sinn für iSCSI 1 eigenes VLAN zu betreiben, willst ja schließlich nicht die ganze Broadcast Spammerei von Bonjour, Druckern und sonstigem Tralala im SAN Netz haben.

Wie sieht das auf der Infrastruktur aus und wie werden sollte alles in einer gemeinsamen L2 Domain arbeiten die Loop Verhinderung aus ??
Wie gesagt, MPIO passiert auf L3+. Auf L2 Ebene hast du die ganz normalen Mechanismen, sei es via xSTP, TRILL, oder sonstige Fabrics, Mittel und Wege.

Mein Aufbau für obigen Fall:
2 Server NICs für iSCSI mit IP 10.0.0.1/24 und 10.0.0.2/24, jeweils in VLAN 10
2 QNAP NICs für iSCSI in Team mit IP 10.0.0.3/24 in VLAN 10

Stimmt... LACP wird auf QNAP Seite auf jeden Fall benötigt. Sorry, mein Fehler.


@meister00: Das ganze Thema gab es schon mal hier im Forum: Qnap per Trunk an HP 1810G-V2
Der LAG muss natürlich korrekt auf dem Switch eingerichtet sein, damit die QNAP erreichbar ist.
Mitglied: aqui
aqui 31.10.2016 um 19:57:37 Uhr
Goto Top
je NIC mit eigener IP zum Switchport.
Das bedeutet dann z.B. 10.1.1.1 und 10.1.1.2 auf den Nics die dann in einen gemeinsame L2 Domain, sprich Switch VLAN gesteckt werden.
Ahhhh, sorry sehe gerade dein Beispiel... OK das erklärt alles ! face-wink
Wie wissen die Beteiligten welche IP Adressen ansprechbar sind, wird das dynamisch ausgetauscht oder gibt man das statisch an im MPIO Setup ?
Mitglied: psannz
psannz 31.10.2016 um 23:12:37 Uhr
Goto Top
Zitat von @aqui:

je NIC mit eigener IP zum Switchport.
Das bedeutet dann z.B. 10.1.1.1 und 10.1.1.2 auf den Nics die dann in einen gemeinsame L2 Domain, sprich Switch VLAN gesteckt werden.
Ahhhh, sorry sehe gerade dein Beispiel... OK das erklärt alles ! face-wink
Wie wissen die Beteiligten welche IP Adressen ansprechbar sind, wird das dynamisch ausgetauscht oder gibt man das statisch an im MPIO Setup ?

Das war mein Fehler. Iscsi target/SAN ist via active/active LAG angebunden, und der Initiator sucht sich dann die simultan möglichen Pfade zusammen. Drum sind auch nicht die vollen n*Bandbreite-eines-Link garantiert, sondern annähernd n*Bandreite der Links.
Mitglied: aqui
aqui 01.11.2016 aktualisiert um 21:26:51 Uhr
Goto Top
Dann ist aber active/active LAG keine übliche Link Aggregation im Sinne von 802.3ad / LACP also was der gemeine Netzwerker sich generell unter Link Aggregation vorstellt. Denn oben sagst du ja gerade das ein kein .ad und LACP sein soll wegen der Hashing Problematik.
Es ist dann eher eine Technik über parallele Links und multiple IP Adressen eine Art besseres Load Balancing hinzubekommen ohne das Hashing wie es ja bei IEEE Standard 802.3ad der Fall ist.
Wie du selbst sagst ein Balancing eben nicht im L2 sondern L3 und höher, richtig ?