Heckflosse 10 Geschrieben 12. Juli 2020 Melden Teilen 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 Link zu diesem Kommentar
Nobbyaushb 1.484 Geschrieben 12. Juli 2020 Melden Teilen 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 Link zu diesem Kommentar
falkebo 21 Geschrieben 12. Juli 2020 Melden Teilen 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 Link zu diesem Kommentar
Heckflosse 10 Geschrieben 13. Juli 2020 Autor Melden Teilen 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 Link zu diesem Kommentar
NilsK 2.968 Geschrieben 13. Juli 2020 Melden Teilen 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 Link zu diesem Kommentar
zahni 558 Geschrieben 13. Juli 2020 Melden Teilen 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 Link zu diesem Kommentar
Heckflosse 10 Geschrieben 13. Juli 2020 Autor Melden Teilen 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 Link zu diesem Kommentar
tesso 375 Geschrieben 13. Juli 2020 Melden Teilen 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 Link zu diesem Kommentar
Heckflosse 10 Geschrieben 13. Juli 2020 Autor Melden Teilen Geschrieben 13. Juli 2020 @tesso Dies gilt für Hyper-V. Gibt es diese Einstellung auch für physikalische Server? Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 13. Juli 2020 Melden Teilen 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 Link zu diesem Kommentar
Nobbyaushb 1.484 Geschrieben 13. Juli 2020 Melden Teilen 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 Link zu diesem Kommentar
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.