Heckflosse 10 Geschrieben 12. Juli 2020 Melden Geschrieben 12. Juli 2020 Hallo, bei einem Cluster-Test mit Windows Server 2019 wurden die Kabelverbindungen der NICs abgezogen und wieder eingesteckt. Nach dem Einstecken dauert es mehrere Minuten, bis das Teaming die NIC wieder erkennt und Datenverkehr vorhanden ist. Dies war bei Windows Server 2016 oder 2012 nicht so. Gibt es einen Wert, z. B. in der REG, der dieses Verhalten beeinflussen kann? Vielen Dank. Gruß
Nobbyaushb 1.580 Geschrieben 12. Juli 2020 Melden Geschrieben 12. Juli 2020 Bei Server 2019 verwendet man Set und kein Team - steht irgendwo, muss ich erst suchen. Sonst mal bei Carsten auf https://www.hyper-v-server.de/ gucken
falkebo 21 Geschrieben 12. Juli 2020 Melden Geschrieben 12. Juli 2020 vor 55 Minuten schrieb Nobbyaushb: Bei Server 2019 verwendet man Set und kein Team - steht irgendwo, muss ich erst suchen. SET gibt es auch schon in Windows Server 2016 und ist erst dann interessant, wenn es um Storage Space Direct geht, vor allem in Kombintation mit RDMA Nics. Damit verbunden sind einige Limitierungen, einiges davon hier nachzulesen: https://www.windowspro.de/marcel-kueppers/statt-nic-teaming-switch-embedded-teaming-set-hyper-v-2016 vor einer Stunde schrieb Heckflosse: Nach dem Einstecken dauert es mehrere Minuten, bis das Teaming die NIC wieder erkennt und Datenverkehr vorhanden ist. Höre ich ehrlich gesagt das erste Mal.
Heckflosse 10 Geschrieben 13. Juli 2020 Autor Melden Geschrieben 13. Juli 2020 Danke Euch für die Beiträge. Wir hatten bisher Windows 2016 Cluster, diese ohne Probleme bei der Umschaltung. Das Problem liegt jetzt in der Entwicklungsabtl. Wir werden sehen...
NilsK 3.046 Geschrieben 13. Juli 2020 Melden Geschrieben 13. Juli 2020 Moin, vor 13 Stunden schrieb Nobbyaushb: Bei Server 2019 verwendet man Set und kein Team das ist so nicht richtig. Sind Treiberprobleme ausgeschlossen? Gruß, Nils
zahni 587 Geschrieben 13. Juli 2020 Melden Geschrieben 13. Juli 2020 Ich meine, und dauert es bei dem einen Server auch eine Weile, bis das Team bereit ist. Bis dahin ist der Traffic auf einer der Karten.
Heckflosse 10 Geschrieben 13. Juli 2020 Autor Melden Geschrieben 13. Juli 2020 Hi, in dem aktuellen Fall gehts um den gesamten, simulierten Ausfall. D. h. alle Kabel werden gezogen (z. B. Ausfall einer Site, Core-Switch, etc.). Es dauerte ca. 4-5 Minuten bis der zweite Node dies "bemerkte" und seinen Dienst begann. Treiber, Firmware ist gerade in Prüfung.
tesso 384 Geschrieben 13. Juli 2020 Melden Geschrieben 13. Juli 2020 Wenn ich mich recht erinnere sind 240 Sekunden der Standard Timeout für den Ausfall eines Knoten. Das kannst du in der Powershell anpassen.
Heckflosse 10 Geschrieben 13. Juli 2020 Autor Melden Geschrieben 13. Juli 2020 @tesso Dies gilt für Hyper-V. Gibt es diese Einstellung auch für physikalische Server?
tesso 384 Geschrieben 13. Juli 2020 Melden Geschrieben 13. Juli 2020 @Heckflosse Schau doch schnell nach, ob es die Parameter auch im "normalen" Cluster gibt. Ich habe gerade keinen zur Hand.
Nobbyaushb 1.580 Geschrieben 13. Juli 2020 Melden Geschrieben 13. Juli 2020 vor 3 Stunden schrieb NilsK: Moin, das ist so nicht richtig. Sind Treiberprobleme ausgeschlossen? Gruß, Nils Haben wir so gelernt - ich muss aber gestehen, das wir (fast) nur RDMA Netzwerkkarten im Einsatz haben (Mellanox X4 und X5) Sorry, wenn ich dadurch für Verwirrung gesorgt habe
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden