etests
Goto Top

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:
csvfs

Cluster Networking:
cluster networking

Synology 10G
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_1

iSCSI HV1 Target
iscsi_hv1_2

iSCSI HV2 Discovery Portal
iscsi_hv2_1

iSCSI HV2 Target
iscsi_hv2_2

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.

Content-ID: 595906

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

Ausgedruckt am: 06.11.2024 um 01:11 Uhr

aqui
aqui 13.08.2020 aktualisiert um 12:55:49 Uhr
Goto Top
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...
ETESTS
ETESTS 13.08.2020 aktualisiert um 13:24:38 Uhr
Goto Top
Hallo aqui,

danke für deine schnelle Antwort. Ich habe es angepasst. Storage neu eingebunden, leider ohne Besserung.

Neue iSCSI Config Synology
bildschirmfoto 2020-08-13 um 13.16.27

Hyper-Vs sind parallel dazu angepasst.


Der obere Ethernet ist die 10G, der 2. das LIVE Mig-Team.
bildschirmfoto 2020-08-13 um 13.15.22

MPIO ist auf den HVs installiert.
aqui
aqui 13.08.2020 aktualisiert um 13:32:04 Uhr
Goto Top
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.
ETESTS
ETESTS 13.08.2020 um 14:08:38 Uhr
Goto Top
Hallo aqui,

es gibt nur ein Gateway, in der NIC für Internet. Das Routing passt der Cluster Manager teilweise an.

Verschiebe ich das CSVFS auf den HV2, dann nutzt HV2 die 10G zum iSCSI und HV1 hat dann das Problem, dass er über 1GBe geht. Verschiebe ich es zurück auf HV1, nutzt HV1 seine 10GBe und HV2, schiebt über 1GBe. Normalerweise sollte über die 1GBe aber nur die Metadata übertragen werden.

bildschirmfoto 2020-08-13 um 13.44.25

bildschirmfoto 2020-08-13 um 13.44.34

Verwende ich 2 Test-LUNs und verbinde je eines mit HV1 und eins mit HV2 und hänge sie ohne CSVFS ein, sondern direkt über Disk Management, wird jeweils 10G verwendet.

route print:
route print
===========================================================================
Interface List
 24...a0 36 9f 26 65 24 ......Intel(R) Gigabit 4P I350-t Adapter
 13...a0 36 9f 26 65 25 ......Intel(R) Gigabit 4P I350-t Adapter #2
 12...f4 52 14 3e eb b0 ......Mellanox ConnectX-3 Ethernet Adapter
 52...02 d7 df 08 96 91 ......Microsoft Failover Cluster Virtual Adapter
  5...a0 36 9f 26 65 27 ......Microsoft Network Adapter Multiplexor Driver
  7...00 1e 67 8a 72 25 ......Intel(R) 82574L Gigabit Network Connection #2
 23...00 1e 67 8a 72 24 ......Hyper-V Virtual Ethernet Adapter
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.252.1   192.168.252.23    281
        10.0.20.0    255.255.255.0         On-link        10.0.20.22    281
       10.0.20.22  255.255.255.255         On-link        10.0.20.22    281
      10.0.20.255  255.255.255.255         On-link        10.0.20.22    281
        10.0.30.8  255.255.255.248         On-link        10.0.30.11    276
       10.0.30.11  255.255.255.255         On-link        10.0.30.11    276
       10.0.30.15  255.255.255.255         On-link        10.0.30.11    276
     10.255.255.4  255.255.255.252         On-link      10.255.255.6    271
     10.255.255.6  255.255.255.255         On-link      10.255.255.6    271
     10.255.255.7  255.255.255.255         On-link      10.255.255.6    271
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      169.254.0.0      255.255.0.0         On-link      169.254.2.77    271
     169.254.2.77  255.255.255.255         On-link      169.254.2.77    271
  169.254.255.255  255.255.255.255         On-link      169.254.2.77    271
    192.168.252.0    255.255.255.0         On-link    192.168.252.23    281
   192.168.252.23  255.255.255.255         On-link    192.168.252.23    281
   192.168.252.99  255.255.255.255         On-link    192.168.252.23    281
  192.168.252.255  255.255.255.255         On-link    192.168.252.23    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link        10.0.20.22    281
        224.0.0.0        240.0.0.0         On-link    192.168.252.23    281
        224.0.0.0        240.0.0.0         On-link        10.0.30.11    276
        224.0.0.0        240.0.0.0         On-link      169.254.2.77    271
        224.0.0.0        240.0.0.0         On-link      10.255.255.6    271
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link        10.0.20.22    281
  255.255.255.255  255.255.255.255         On-link    192.168.252.23    281
  255.255.255.255  255.255.255.255         On-link        10.0.30.11    276
  255.255.255.255  255.255.255.255         On-link      169.254.2.77    271
  255.255.255.255  255.255.255.255         On-link      10.255.255.6    271
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0    192.168.252.1  Default
          0.0.0.0          0.0.0.0    192.168.252.1     256
===========================================================================


ipconfig
ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : MA-HV-02
   Primary Dns Suffix  . . . . . . . : ma.hv
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : ma.hv

Ethernet adapter 10G:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Mellanox ConnectX-3 Ethernet Adapter
   Physical Address. . . . . . . . . : F4-52-14-3E-EB-B0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.255.255.6(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.252
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter Local Area Connection* 11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Failover Cluster Virtual Adapter
   Physical Address. . . . . . . . . : 02-D7-DF-08-96-91
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::b87c:dbb6:79de:3fbc%52(Preferred)
   IPv4 Address. . . . . . . . . . . : 169.254.2.77(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 872601567
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-DF-9B-18-00-1E-67-8A-72-24
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter LIVE:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Network Adapter Multiplexor Driver
   Physical Address. . . . . . . . . : A0-36-9F-26-65-27
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.0.30.11(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.248
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter MAHV:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection #2
   Physical Address. . . . . . . . . : 00-1E-67-8A-72-25
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.0.20.22(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 10.0.20.20
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (vSwitch01):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   Physical Address. . . . . . . . . : 00-1E-67-8A-72-24
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.252.23(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 192.168.252.99(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.252.1
   NetBIOS over Tcpip. . . . . . . . : Enabled


Mir ist prinzipiell klar, dass es ein Routingproblem zu geben scheint, aber ich gehe es seit Tagen wieder und wieder durch und finde keins. face-wink Danke für deine bisherige Hilfe!
clSchak
clSchak 13.08.2020 um 14:25:12 Uhr
Goto Top
Hi

sind mehrfacher Zugriff durch unterschiedliche Hosts auf der Synology aktiv? So das du synchron mit beiden auf dem LUN schreiben kannst?
ETESTS
ETESTS 13.08.2020 aktualisiert um 14:34:00 Uhr
Goto Top
Jawohl, aktiv und beide HVs verbunden.

bildschirmfoto 2020-08-13 um 14.31.19

Ich kann auch ein LUN auf beiden Hosts gleichzeitig einbinden und per NTFS formatieren. Dann können beide HVs kurz damit arbeiten (über 10GBe), bis es natürlich kurrupt wird, weil kein Clustered Volume.

Das Problem besteht ausschließlich beim CSVFS!
ETESTS
ETESTS 13.08.2020 aktualisiert um 16:39:17 Uhr
Goto Top
Weitere Tests haben folgendes ergeben:

  • Das CSVFS Storage wird wie eine lokale Platte behandelt. Je nachdem welcher HV es owned wird über diesen per iSCSI auf das Storage geschrieben, wie eine Art Proxy.
  • Sind alle NICs bis auf iSCSI deaktiviert, ist das Storage via C:\ClusterStorage\Volume1 von dem Host der ese owned erreichbar, vom anderen nicht, obwohl eine eigene iSCSI Connection verbunden ist.
  • Es macht keinen Untschied, ob Multi-Path auf seiten der HVs verwendet wird oder nicht.
  • Microsoft Failover Cluster Virtual Adapter Performance Filter auf den Nics brachte keine Besserung

EDIT: Lösung gefunden / Fails

  • Das LUN darf nicht, wie bei mir mit ReFS formatiert werden, bei ReFS wechselt Windows in den Redirection Mode
  • Auf NIC iSCSI (10GBe) und NIC LIVE (2x1GBe Team) muss Microsoft Failover Cluster Virtual Adapter Performance Filter installiert und aktiviert werden

Danke für eure rege Beteiligung. Das hat mich motiviert nicht auf SMB3 zu wecheln und das erklärte Ziel weiter zu verfolgen.
mbehrens
mbehrens 13.08.2020 um 17:59:45 Uhr
Goto Top
Zitat von @ETESTS:

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.