Wir haben einen vorhandenen Windows 2012-Cluster mit 2 Knoten und Dateizeugen, ersetzen diese jedoch durch 2019-Server. Wir können also einfach das vorhandene Clusterobjekt wiederverwenden, wir fügen die 2019-Server zum Cluster hinzu und löschen die 2012-Server, sobald die geclusterten Datenbanken synchronisiert sind. Der Validierungstest zeigt nur wenige Warnungen, darunter die Warnung „nur ein Paar Netzwerkschnittstellen“ bei „Netzwerkkommunikation validieren“, die Warnung „Das Kennwort entspricht nicht den Anforderungen der Kennwortrichtlinie“ bei „CSV-Einstellungen validieren“, die neuen Server befinden sich nicht in derselben Organisationseinheit wie die alten Server (sie sind nach Server-Betriebssystemversion 2012 vs. 2019 gruppiert), „Die Clustereigenschaft „ClusterLogSize“ ist auf einen Wert eingestellt, der kleiner ist als der Standardwert von 1536“, und die offensichtliche Warnung „unterschiedliche, aber kompatible Betriebssystemversionen“. Es gibt also nichts, was uns daran hindern sollte, die Knoten zum Cluster hinzuzufügen.
Der Vorgang „Knoten hinzufügen“ schlägt beim Schritt „Warten auf Benachrichtigung, dass Knoten … ein voll funktionsfähiges Mitglied des Clusters ist“ fehl. Systemereignisprotokolle zeigen die Fehler 1653 und 5398 an, was auf ein Kommunikationsproblem hinweist. Der Clusterdienst kommuniziert über 3343, daher konzentrierte sich die Fehlerbehebung darauf. Firewall und AV wurden vollständig ausgeschaltet, aber das Problem bestand weiterhin.
Der einzige Unterschied, der mir zwischen den neuen und den alten Servern auffällt, ist, dass während des Assistenten zum Hinzufügen von Knoten, wenn der Clusterdienst auf dem neuen Server aktiviert wird, der Server nicht auf UDP 3343 lauscht. Ich habe dies gesehen, als ich TCPView sowohl auf den 2012-Servern ausgeführt habe, die sich derzeit im Cluster befinden, als auch auf den 2019-Servern, die ich dem Cluster hinzufügen möchte. Die 2012-Server zeigen das Lauschen über 3343 auf TCP und UDP, aber die 2019-Server zeigen das Lauschen und Senden von Informationen nur über TCP 3343. Es wird 4 Time-Wait-Kommunikationen über TCP 3343 zu den beiden 2012-Servern geben, aber diese laufen irgendwann ab, wodurch der Vorgang zum Hinzufügen von Knoten mit einem Timeout-Fehler fehlschlägt. Ich bin nicht sicher, ob das Nichtlauschen auf UDP 3343 zu diesem Zeitpunkt des Vorgangs normales Verhalten ist, bevor ein Knoten vollständig hinzugefügt wurde, oder ob es darauf hinweist, dass der Dienst auf den neuen Servern nicht richtig sowohl auf TCP als auch auf UDP 3343 lauscht.
Es scheint, als würde nichts die Kommunikation aktiv blockieren. Es scheint nur so, als würden die neuen Server nicht richtig auf die Kommunikation der anderen Knoten hören. Oder bin ich einfach auf dem Holzweg?
Antwort1
Obwohl dies im Validierungsbericht nicht erwähnt wurde, ist es physikalisch unmöglich, einem 2012-Cluster einen 2019-Knoten hinzuzufügen.