16
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 319509
Url: https://administrator.de/forum/qnap-hyper-v-hp-switch-trunk-319509.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
16 Kommentare
Neuester Kommentar
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
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
hi,
also brauche im am switch keine trunks bilden?
thx
also brauche im am switch keine trunks bilden?
thx
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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
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
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?
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.
@psannz
danke
und welcher modus ist dann der beste optimale für die qnap
Balance-rr
Balance-xor
Broadcast
802.3ad dynamic
thx
danke
und welcher modus ist dann der beste optimale für die qnap
Balance-rr
Balance-xor
Broadcast
802.3ad dynamic
thx
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
@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.
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...
Leider sagen die Tech Infos von MS oben ja rein gar nix dazu...
- 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
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...
je NIC mit eigener IP zum Switchport. MPIO passiert auf Layer 3 bis 5.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...
- 2 Server NICs mit je einer IP im gleichen Netz auf einen Draht (Switch) gesteckt ? Wie siehts hier mit Loop Gefahr aus ?
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.
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 !
Wie wissen die Beteiligten welche IP Adressen ansprechbar sind, wird das dynamisch ausgetauscht oder gibt man das statisch an im MPIO Setup ?
Zitat von @aqui:
Ahhhh, sorry sehe gerade dein Beispiel... OK das erklärt alles !
Wie wissen die Beteiligten welche IP Adressen ansprechbar sind, wird das dynamisch ausgetauscht oder gibt man das statisch an im MPIO Setup ?
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 !
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.
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 ?
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 ?
