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ß Zitieren
Nobbyaushb 1.506 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 Zitieren
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. Zitieren
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... Zitieren
NilsK 2.978 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 Zitieren
zahni 566 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. Zitieren
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. Zitieren
tesso 377 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. Zitieren
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? Zitieren
tesso 377 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. Zitieren
Nobbyaushb 1.506 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 Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.