ISCSI Traffic für CSVFS geht über falsche NIC im Hyper-V-Cluster
Hallo zusammen,
ich möchte vorweg schicken, dass es sich bei meinem Vorhaben um eine Low-Budget Lab-Umgebung aus vorhandenen Komponenten handelt. Für den produktiven Einsatz, wäre alles redundant über entsprechende Switches angebunden.
Ausgangslage
Ich habe zwei Server mit Hyper-V und eine Synology 3617XS. Die Hyper-Vs verfügen über 4x 1 GBit (Intel) und 1x 10GBit (Mellanox Connect-X3), die Synology verfügt über 4x 1GBit und 2x 10GBit (Dual Mellanox Connect-X3).
Die Hyper-Vs sind jeweils mit 1xGBit auf einem Switch im MGMT-Netzwerk der HV-Domäne (10.0.20.0/24) und mit 2x 1GBit im Team (10.0.30.8/29) direkt mit einander verbunden, damit Live-Migrationen direkt erfolgen können, was auch problemlos klappt.
Die Hyper-Vs sind jeweils per 1x DAC (10GB) mit der Synology verbunden. (HV1: 10.255.255.12 --> SYN1: 10.255.255.10 und HV2: 10.255.255.13 --> SYN2: 10.255.255.11). Discovery Portal im HV jeweils auf die zugehörige IP der Synology gesetzt. iSCSI verbunden, Laufwerke ohne Buchstaben eingehangen und im Clustermanager als Disk hinzugefügt um letztendlich ein CSVFS zu erstellen. Klappt bis hierhin alles.
CSVFS:
Cluster Networking:
Synology 10G
Problem
Das iSCSI Drive hat immer einen Owner (HV1 oder HV2), der ist es gemounted. Dieser Host nutzt auch die iSCSI 10G Verbindung, der jeweils andere schiebt alle Daten über das MGMT-Netz, und greif dann über den anderen HV-Host per iSCSI zu. Setzt man im Cluster Manager den jeweils anderen Host besteht das Problem genau in die andere Richtung. Ergo ist die Performance auf einem Host immer schlecht.
Ich weiß nicht, ob es hierfür eine Lösung gibt oder es so designed ist, da ich vermute, dass der Clustermanager nicht erkennt, dass es ein und das selbe iSCSI Drive ist. Vermutlich erfolgt der Abgleich über die IP-Adresse, die ja für jeden Host unterschiedlich ist.
Ich hoffe, dass ich nur den Wald vor lauter Bäumen nicht sehe und das Schwarmwissen zu einer Lösung kommt.
iSCSI HV1 Discovery Portal
iSCSI HV1 Target
iSCSI HV2 Discovery Portal
iSCSI HV2 Target
Plan B
Storage per SMB3 verwenden, was ich eigentlich nur mache, wenn das ein Windows-Server ist. Ich traue den SMB3 Integration der Drittanbieter nicht, kann aber auch falsches Gefühl sein.
ich möchte vorweg schicken, dass es sich bei meinem Vorhaben um eine Low-Budget Lab-Umgebung aus vorhandenen Komponenten handelt. Für den produktiven Einsatz, wäre alles redundant über entsprechende Switches angebunden.
Ausgangslage
Ich habe zwei Server mit Hyper-V und eine Synology 3617XS. Die Hyper-Vs verfügen über 4x 1 GBit (Intel) und 1x 10GBit (Mellanox Connect-X3), die Synology verfügt über 4x 1GBit und 2x 10GBit (Dual Mellanox Connect-X3).
Die Hyper-Vs sind jeweils mit 1xGBit auf einem Switch im MGMT-Netzwerk der HV-Domäne (10.0.20.0/24) und mit 2x 1GBit im Team (10.0.30.8/29) direkt mit einander verbunden, damit Live-Migrationen direkt erfolgen können, was auch problemlos klappt.
Die Hyper-Vs sind jeweils per 1x DAC (10GB) mit der Synology verbunden. (HV1: 10.255.255.12 --> SYN1: 10.255.255.10 und HV2: 10.255.255.13 --> SYN2: 10.255.255.11). Discovery Portal im HV jeweils auf die zugehörige IP der Synology gesetzt. iSCSI verbunden, Laufwerke ohne Buchstaben eingehangen und im Clustermanager als Disk hinzugefügt um letztendlich ein CSVFS zu erstellen. Klappt bis hierhin alles.
CSVFS:
Cluster Networking:
Synology 10G
Problem
Das iSCSI Drive hat immer einen Owner (HV1 oder HV2), der ist es gemounted. Dieser Host nutzt auch die iSCSI 10G Verbindung, der jeweils andere schiebt alle Daten über das MGMT-Netz, und greif dann über den anderen HV-Host per iSCSI zu. Setzt man im Cluster Manager den jeweils anderen Host besteht das Problem genau in die andere Richtung. Ergo ist die Performance auf einem Host immer schlecht.
Ich weiß nicht, ob es hierfür eine Lösung gibt oder es so designed ist, da ich vermute, dass der Clustermanager nicht erkennt, dass es ein und das selbe iSCSI Drive ist. Vermutlich erfolgt der Abgleich über die IP-Adresse, die ja für jeden Host unterschiedlich ist.
Ich hoffe, dass ich nur den Wald vor lauter Bäumen nicht sehe und das Schwarmwissen zu einer Lösung kommt.
iSCSI HV1 Discovery Portal
iSCSI HV1 Target
iSCSI HV2 Discovery Portal
iSCSI HV2 Target
Plan B
Storage per SMB3 verwenden, was ich eigentlich nur mache, wenn das ein Windows-Server ist. Ich traue den SMB3 Integration der Drittanbieter nicht, kann aber auch falsches Gefühl sein.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 595906
Url: https://administrator.de/contentid/595906
Ausgedruckt am: 06.11.2024 um 01:11 Uhr
8 Kommentare
Neuester Kommentar
Der Fehler liegt in deiner Adressierung der 2x10G Nics des NAS. Ohne Bridge sind es 2 getrennte Adapter die dann logischerweise in 2 unterschiedlichen IP Netzen liegen müssen.
Also z.B.
Erstes Subnetz: 10.255.255.0 /30 (255.255.255.252) VM=.1 und SYN1=.2
Zweites Subnetz: 10.255.255.4 /30 (255.255.255.252) VM=.5 und SYN2=.6
Das ist bei dir nicht der Fall !
Stattdessen hast du fälschlicherweise alles in ein Subnetz gepackt was dann aber zwingend voraussetzt das die beiden Interfaces am NAS dann im Bridging Mode mit einer einzigen IP arbeiten, was auch nicht der Fall ist.
Fazit: Mit der falschen IP Adressierung und Netzwerk Mode muss es mit dem Wald sehen dann scheitern...
Also z.B.
Erstes Subnetz: 10.255.255.0 /30 (255.255.255.252) VM=.1 und SYN1=.2
Zweites Subnetz: 10.255.255.4 /30 (255.255.255.252) VM=.5 und SYN2=.6
Das ist bei dir nicht der Fall !
Stattdessen hast du fälschlicherweise alles in ein Subnetz gepackt was dann aber zwingend voraussetzt das die beiden Interfaces am NAS dann im Bridging Mode mit einer einzigen IP arbeiten, was auch nicht der Fall ist.
Fazit: Mit der falschen IP Adressierung und Netzwerk Mode muss es mit dem Wald sehen dann scheitern...
leider ohne Besserung
Dann stimmt dein Routing nicht !Checke das mal mit route print in der Eingabeaufforderung. Als Ziel gibst du ja immer die SYN IP an und du hast vermutlich fälschlicherweise 2 Gateways oder sowas auf den VMs eingetragen was falsch ist bzw. Windows damit nicht umgehen kann. Da die Synology Links ein Point to Point sind mit der /30 er Maske dürfen diese Interfaces weder Gateway noch DNS definiert haben.
Siehe dazu auch hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Dort liegt also irgendwo dein Fehler in der IP Adressierung der VMs.
Es sollte natürlich klar sein das du auch die iSCSI Interfaces der VMs auf diese neue IP Adressierung mit den entsprechenden IPS und /30er Masken anpasst ?,
Auch sollten die NAS Koppelnetze in getrennten vSwitches liegen.
Jumbo Framing zu aktivieren ist bei 10G auch immer anzuraten auf beiden Enden.
EDIT: Lösung gefunden / Fails
- Das LUN darf nicht, wie bei mir mit ReFS formatiert werden, bei ReFS wechselt Windows in den Redirection Mode
Richtig, ReFS macht hier den Unterschied. Dies ist so vorgesehen. Get-ClusterSharedVolumeState würde dies bestätigen.