Failover Cluster Network
Hallo zusammen,
toller Freitag heute... vielleicht kann mir jemand unter die Arme greifen.
Ich habe einen Failover Cluster gebaut.
Teaming
-> für jeden Bereich ein eigenes VLAN
Storage-SCSI
Mangmenent
Cluster
Livemigration
beim Cluster prüfen bekomme ich jetzt die Meldung das
Die Netzwerkschnittstellen "exodus01.bw-h.de - VLAN-Cluster" und "exodus02.bw-h.de - VLAN-Cluster" befinden sich im selben Clusternetzwerk, die Adresse "192.168.51.2" ist jedoch von "192.168.51.1" unter Verwendung von UDP an Port 3343 nicht erreichbar.
Ich die Sever mit einer IP im gleichen Subnetz ausgestattet
192.168.50.1 Node1
192.168.50.2 Node2
Keine Firewall... Verbindung über VLAN nur über den Switch
Zum einem sehe ich im SMB Client eine Fehlermeldung :
Dann mal die Route geprüft:
beim erste Knoten:
beim zweiten
Er scheint ihr also den Traffic über Netzwerkbereich 192.168.4.0 zu routen. Das kann nicht funktionieren.
Wie kann ich ihm jetzt mitgeben, das der Traffic an diese IP über den Netzwerkbereich 192.168.51.0 routet?
Bin für Unterstützung dankbar
Grüße
Stefan
toller Freitag heute... vielleicht kann mir jemand unter die Arme greifen.
Ich habe einen Failover Cluster gebaut.
Teaming
-> für jeden Bereich ein eigenes VLAN
Storage-SCSI
Mangmenent
Cluster
Livemigration
beim Cluster prüfen bekomme ich jetzt die Meldung das
Die Netzwerkschnittstellen "exodus01.bw-h.de - VLAN-Cluster" und "exodus02.bw-h.de - VLAN-Cluster" befinden sich im selben Clusternetzwerk, die Adresse "192.168.51.2" ist jedoch von "192.168.51.1" unter Verwendung von UDP an Port 3343 nicht erreichbar.
Ich die Sever mit einer IP im gleichen Subnetz ausgestattet
192.168.50.1 Node1
192.168.50.2 Node2
Keine Firewall... Verbindung über VLAN nur über den Switch
Zum einem sehe ich im SMB Client eine Fehlermeldung :
Fehler bei der Einrichtung einer Netzwerkverbindung.
Fehler: {Gerät-Zeitüberschreitung}
Das Zeitlimit des angegebenen E/A-Vorgangs auf %hs wurde erreicht, bevor der E/A-Vorgang abgeschlossen wurde.
Servername: fe80::454d:1a6:3fa1:2ce2%16
Serveradresse: 192.168.50.2:445
Verbindungstyp: Wsk
Erläuterung:
Dies ist ein Hinweis auf ein Problem mit dem zugrunde liegenden Netzwerk oder dem Transportprotokoll, z.B. mit TCP/IP, und nicht auf ein Problem mit SMB. Eine Firewall, die den TCP-Port 445 oder 5445 bei Verwendung eines iWARP-RDMA-Adapters blockiert, kann dieses Problem ebenfalls verursachen.
Dann mal die Route geprüft:
beim erste Knoten:
PS C:\Users\administrator.> Find-NetRoute -RemoteIPAddress 192.168.51.1
IPAddress : 192.168.51.2
InterfaceIndex : 28
InterfaceAlias : VLAN-Cluster
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Manual
SuffixOrigin : Manual
AddressState : Preferred
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore
Caption :
Description :
ElementName :
InstanceID : ;C<8;@B8?;8:9<>55<B55:8:8:8:55;
AdminDistance :
DestinationAddress :
IsStatic :
RouteMetric : 256
TypeOfRoute : 3
AddressFamily : IPv4
CompartmentId : 1
DestinationPrefix : 192.168.51.0/24
InterfaceAlias : VLAN-Cluster
InterfaceIndex : 28
NextHop : 0.0.0.0
PreferredLifetime : 10675199.02:48:05.4775807
Protocol : Local
Publish : No
Store : ActiveStore
ValidLifetime : 10675199.02:48:05.4775807
PSComputerName :
ifIndex : 28
beim zweiten
PS C:\Users\administrator.> Find-NetRoute -RemoteIPAddress 192.168.51.2
IPAddress : 192.168.4.83
InterfaceIndex : 8
InterfaceAlias : vEthernet (Hausnetz)
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Dhcp
SuffixOrigin : Dhcp
AddressState : Preferred
ValidLifetime : 7.23:42:05
PreferredLifetime : 7.23:42:05
SkipAsSource : False
PolicyStore : ActiveStore
Caption :
Description :
ElementName :
InstanceID : :8:8:8:9:55B55;C<8;@B8>8;55;
AdminDistance :
DestinationAddress :
IsStatic :
RouteMetric : 0
TypeOfRoute : 3
AddressFamily : IPv4
CompartmentId : 1
DestinationPrefix : 0.0.0.0/0
InterfaceAlias : vEthernet (Hausnetz)
InterfaceIndex : 8
NextHop : 192.168.4.1
PreferredLifetime : 8.00:00:00
Protocol : NetMgmt
Publish : No
Store : ActiveStore
ValidLifetime : 8.00:00:00
PSComputerName :
ifIndex : 8
Er scheint ihr also den Traffic über Netzwerkbereich 192.168.4.0 zu routen. Das kann nicht funktionieren.
Wie kann ich ihm jetzt mitgeben, das der Traffic an diese IP über den Netzwerkbereich 192.168.51.0 routet?
Bin für Unterstützung dankbar
Grüße
Stefan
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 617586
Url: https://administrator.de/forum/failover-cluster-network-617586.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
22 Kommentare
Neuester Kommentar
Hallo samrein,
die Domain solltest du rausnehmen. Ggf. einfach ein DNS Problem, da die exodus wohl nach aussen auflösen dürfte. Daneben ist die Frage, wie dein Clusternetzwerk nach extern angebunden ist - Stichwort falsches (zu viele gegensätzliche!) Gateway.
Im Detail gilt hier aber leider, per Forum erhält man nie den Einblick wie am Livesystem, ggf. sollte man sich das mal gemeinsam anschauen.
Grüße,
Christian
die Domain solltest du rausnehmen. Ggf. einfach ein DNS Problem, da die exodus wohl nach aussen auflösen dürfte. Daneben ist die Frage, wie dein Clusternetzwerk nach extern angebunden ist - Stichwort falsches (zu viele gegensätzliche!) Gateway.
Im Detail gilt hier aber leider, per Forum erhält man nie den Einblick wie am Livesystem, ggf. sollte man sich das mal gemeinsam anschauen.
Grüße,
Christian
Kannst Du Mal das "Teaming" mit dem "Storage-ISCSI" etwas genauer erklären?
Teaming:
Das Storage ist über ISCSI angeschlossen, MPIO.
Das befindet sich in einem separaten VLAN
Die beiden Netzwerkadapter vom Server sind als TEAM konfiguriert.
Das Storage ist über ISCSI angeschlossen, MPIO.
Das befindet sich in einem separaten VLAN
Die beiden Netzwerkadapter vom Server sind als TEAM konfiguriert.
Interessante Konfiguration ...
Ich hoffe mal, der Hersteller sieht ein solches "Konstrukt" auch vor.
Zitat von @mbehrens:
Interessante Konfiguration ...
Ich hoffe mal, der Hersteller sieht ein solches "Konstrukt" auch vor.
Teaming:
Das Storage ist über ISCSI angeschlossen, MPIO.
Das befindet sich in einem separaten VLAN
Die beiden Netzwerkadapter vom Server sind als TEAM konfiguriert.
Das Storage ist über ISCSI angeschlossen, MPIO.
Das befindet sich in einem separaten VLAN
Die beiden Netzwerkadapter vom Server sind als TEAM konfiguriert.
Interessante Konfiguration ...
Ich hoffe mal, der Hersteller sieht ein solches "Konstrukt" auch vor.
Es ist wirklich ein Konstrukt.
Normalerweise gehört jeder Pfad in ein separates VLAN und kein klassisches serverseitiges Teaming drüber gelegt.
Das Layer 2 Forwarding gehört entsprechend angepasst/optimiert.
was ist daran falsch? Meinst Du das das Teaming Probleme bereitet für das Storage?
Das kann ich nicht wissen. In der Regel macht man aber MPIO ohne Team. Bei "einem" Team braucht man auch kein MPIO mehr.
Mehr weiß dann sicherlich der Hersteller.
Es hört sich alles auf jeden Fall ziemlich schräg an...
Ich glaube auch dass Du eher sagen möchtest dass auf dem Server die ISCSI Initiatoren sind?
Jeder Pfad gehört in ein völlig autonomes VLAN mit Jumboframes usw...
Jeder Pfad at ein eigenes IP-Netz.
Das Multi-Pfad Input Output sorgt für den redundanten Zugriff auf die Blockebene. Der Dateisystemtreiber organisiert, dann z. B. das der eine Pfad die Blöcke des anderen Pfad nicht überschreibt.
Ein Teaming im Sinne der Windows Server Funktion hat da nichts zu suchen.
Es wird auch massiven Einfluss auf die Performance haben im negativen Sinne wenn man kein MPIO fährt. Das wird noch weitere schwerwiegende Probleme nach sich ziehen. keine Ahnung wie dann überhaupt die Warteschlange in der LUNs arbeiten sollen? Usw...
Hast du mal geguckt ob du die Netzwerkkarten auf Hardwareebene partitionieren kannst? Und sind es überhaupt "Netzwerkkarten" oder sind es Converged Network Adapter? (CNA)
Das Systemhaus was das eingerichtet hat gehört mindestens geohrfeigt.
Wenn das stimmt was du sagst, es ist ja möglich dass Du mit den ganzen Begrifflichkeiten etwas anders umgehst als wir das tun, dann bin ich wirklich entsetzt und muss sagen dass dieses Systemhaus euch in größte Gefahr gebracht hat.
Ich glaube auch dass Du eher sagen möchtest dass auf dem Server die ISCSI Initiatoren sind?
Jeder Pfad gehört in ein völlig autonomes VLAN mit Jumboframes usw...
Jeder Pfad at ein eigenes IP-Netz.
Das Multi-Pfad Input Output sorgt für den redundanten Zugriff auf die Blockebene. Der Dateisystemtreiber organisiert, dann z. B. das der eine Pfad die Blöcke des anderen Pfad nicht überschreibt.
Ein Teaming im Sinne der Windows Server Funktion hat da nichts zu suchen.
Es wird auch massiven Einfluss auf die Performance haben im negativen Sinne wenn man kein MPIO fährt. Das wird noch weitere schwerwiegende Probleme nach sich ziehen. keine Ahnung wie dann überhaupt die Warteschlange in der LUNs arbeiten sollen? Usw...
Hast du mal geguckt ob du die Netzwerkkarten auf Hardwareebene partitionieren kannst? Und sind es überhaupt "Netzwerkkarten" oder sind es Converged Network Adapter? (CNA)
Das Systemhaus was das eingerichtet hat gehört mindestens geohrfeigt.
Wenn das stimmt was du sagst, es ist ja möglich dass Du mit den ganzen Begrifflichkeiten etwas anders umgehst als wir das tun, dann bin ich wirklich entsetzt und muss sagen dass dieses Systemhaus euch in größte Gefahr gebracht hat.
Hier oberflächlich aufgekocht das Thema...
https://www.windowspro.de/wolfgang-sommergut/multipath-io-mpio-fuer-iscs ...
https://www.windowspro.de/wolfgang-sommergut/multipath-io-mpio-fuer-iscs ...
Wie gesagt, oberflächlich....
Die Switchkonfig kann noch diverse Optimierungen ermöglichen.
Wir haben über 1000 Server mit FCoE, das ist bestimmtes Know How vergleichbar. Außerdem sind fast alle Server Diskless und booten aus dem SAN, auf dem Weg zum Login-Screen kommt dann das MPIO und der Server steht mit doppelt so vielen Warteschlangen und Bandbreite auf dem SAN.
Lediglich unsere vier HANA Monster stehen noch auf FC. Das ist allerdings auch schon bald nicht mehr Realität, weil das FCoE seit über einem Jahr im keinem Punkt dem nativen FC nach steht. Ganz im Gegenteil die Vorteile überwiegen.
Wir sparen so riesengroße Summen ein. Die Server haben keine Backplanes, besondere Gehäuse mit vielen Slots, aufwendige SAS Verkabelung, keine RAID Controller, keine Laufwerke, geringere Leistungsaufnahme, bessere Lüftung und im Falle der zyklischen Hardware Migration sind die LUNs sehr schnell umgezogen auf die neue Hardware.
Grundsätzlich bist du auf der richtigen Seite mit dem iSCSI.
Die Switchkonfig kann noch diverse Optimierungen ermöglichen.
Wir haben über 1000 Server mit FCoE, das ist bestimmtes Know How vergleichbar. Außerdem sind fast alle Server Diskless und booten aus dem SAN, auf dem Weg zum Login-Screen kommt dann das MPIO und der Server steht mit doppelt so vielen Warteschlangen und Bandbreite auf dem SAN.
Lediglich unsere vier HANA Monster stehen noch auf FC. Das ist allerdings auch schon bald nicht mehr Realität, weil das FCoE seit über einem Jahr im keinem Punkt dem nativen FC nach steht. Ganz im Gegenteil die Vorteile überwiegen.
Wir sparen so riesengroße Summen ein. Die Server haben keine Backplanes, besondere Gehäuse mit vielen Slots, aufwendige SAS Verkabelung, keine RAID Controller, keine Laufwerke, geringere Leistungsaufnahme, bessere Lüftung und im Falle der zyklischen Hardware Migration sind die LUNs sehr schnell umgezogen auf die neue Hardware.
Grundsätzlich bist du auf der richtigen Seite mit dem iSCSI.
Aber du meinst schon, das für die jeweiligen Wege zum Storage auch entsprechend eigene vlans zum Einsatz kommen sollten?
Damit der Traffic für jeden Pfad definitiv eigens geroutet wird?
Also z.B. Storage 4x 10Gb
Controller A
Nic 1 - vlan 1 - 192.168.1.1
Nic 2 - vlan 2 - 192.168.2.1
Controller B
Nic 3 - vlan 1 - 192.168.1.2
Nic 4 - vlan 2 - 192.168.2.2
Server 1
Nic 1 - vlan 1 - 192.168.1.11
Nic 2 - vlan 2 - 192.168.2.11
Server 2
Nic 1 - vlan 1 - 192.168.1.12
Nic 2 - vlan 2 - 192.168.2.12
Und so weiter...
Wäre das besser?
Damit der Traffic für jeden Pfad definitiv eigens geroutet wird?
Also z.B. Storage 4x 10Gb
Controller A
Nic 1 - vlan 1 - 192.168.1.1
Nic 2 - vlan 2 - 192.168.2.1
Controller B
Nic 3 - vlan 1 - 192.168.1.2
Nic 4 - vlan 2 - 192.168.2.2
Server 1
Nic 1 - vlan 1 - 192.168.1.11
Nic 2 - vlan 2 - 192.168.2.11
Server 2
Nic 1 - vlan 1 - 192.168.1.12
Nic 2 - vlan 2 - 192.168.2.12
Und so weiter...
Wäre das besser?
Zitat von @samrein:
Wow...das ist natürlich eine andere Liga. Hört sich auf jeden Fall spannend an. Habt ihr alle möglichen Betriebssysteme im Einsatz, auch esxi über FC?
Wir haben nur eine kleine Farm, aber das Thema find ich sehr spannend....
Wow...das ist natürlich eine andere Liga. Hört sich auf jeden Fall spannend an. Habt ihr alle möglichen Betriebssysteme im Einsatz, auch esxi über FC?
Wir haben nur eine kleine Farm, aber das Thema find ich sehr spannend....
Ja, großer Schwerpunkt auf ESXI für die Sachen im Hause und nur vier R940 laufen mit Suse und nativen FC. Jeweils 8x 16GBit pro Host.
Sonst alles 25,40,50 und 100 GBit FCoE.
Cloud läuft größtenteils auf Azure.
Client OSes geschätzte 80% für Windows und Linux, Rest kunterbunt.
Zitat von @farddwalling:
Aber du meinst schon, das für die jeweiligen Wege zum Storage auch entsprechend eigene vlans zum Einsatz kommen sollten?
Damit der Traffic für jeden Pfad definitiv eigens geroutet wird?
Also z.B. Storage 4x 10Gb
Controller A
Nic 1 - vlan 1 - 192.168.1.1
Nic 2 - vlan 2 - 192.168.2.1
Controller B
Nic 3 - vlan 1 - 192.168.1.2
Nic 4 - vlan 2 - 192.168.2.2
Server 1
Nic 1 - vlan 1 - 192.168.1.11
Nic 2 - vlan 2 - 192.168.2.11
Server 2
Nic 1 - vlan 1 - 192.168.1.12
Nic 2 - vlan 2 - 192.168.2.12
Und so weiter...
Wäre das besser?
Aber du meinst schon, das für die jeweiligen Wege zum Storage auch entsprechend eigene vlans zum Einsatz kommen sollten?
Damit der Traffic für jeden Pfad definitiv eigens geroutet wird?
Also z.B. Storage 4x 10Gb
Controller A
Nic 1 - vlan 1 - 192.168.1.1
Nic 2 - vlan 2 - 192.168.2.1
Controller B
Nic 3 - vlan 1 - 192.168.1.2
Nic 4 - vlan 2 - 192.168.2.2
Server 1
Nic 1 - vlan 1 - 192.168.1.11
Nic 2 - vlan 2 - 192.168.2.11
Server 2
Nic 1 - vlan 1 - 192.168.1.12
Nic 2 - vlan 2 - 192.168.2.12
Und so weiter...
Wäre das besser?
Ja, schon besser und nichts mit Routing. Einfach brachiales niedriglatentes Layer 2 Forwarding.
Bevorzugt mit optimierten NICs/CNAs und je nach anwendungsfall auch partitioniert.
Nein, du brauchst nur genügend Netzwerkkarten. Aber ein Switch ist da schon die Regel.
/Thomas