既存の Windows 2012 2 ノード クラスターとファイル ウィットネスがありますが、これを 2019 サーバーに置き換えます。既存のクラスター オブジェクトを再利用し、2019 サーバーをクラスターに追加して、クラスター化されたデータベースが同期されたら 2012 サーバーを削除します。検証テストでは、ネットワーク通信の検証での「ネットワーク インターフェイスのペアは 1 つだけ」という警告、CSV 設定の検証での「パスワードがパスワード ポリシーの要件を満たしていません」という警告、新しいサーバーが古いサーバーと同じ OU にない (サーバー OS バージョン 2012 と 2019 でグループ化されている)、「クラスター プロパティ "ClusterLogSize" が既定値の 1536 より小さい値に設定されています」、および明らかな「オペレーティング システムのバージョンは異なりますが互換性があります」という警告など、いくつかの警告のみが表示されます。したがって、ノードをクラスターに追加することを妨げるものは何もありません。
ノードの追加プロセスは、「ノードがクラスターの完全に機能するメンバーであるという通知を待機しています」のステップで失敗します。システム イベント ログには、通信の問題を示すエラー 1653 および 5398 が表示されます。クラスタリング サービスは 3343 を介して通信するため、トラブルシューティングはこれに重点が置かれています。ファイアウォールと AV を完全にオフにしましたが、問題は解決されませんでした。
新しいサーバーと古いサーバーの違いとして私が気づいたのは、新しいサーバーでクラスター サービスがアクティブ化されるノードの追加ウィザードの実行中に、サーバーが UDP 3343 をリッスンしていないことです。これは、現在クラスター内にある 2012 サーバーと、クラスターに追加しようとしている 2019 サーバーの両方で TCPView を実行することで確認しました。2012 サーバーは TCP と UDP で 3343 をリッスンしていることが表示されますが、2019 サーバーは TCP 3343 をリッスンして情報を送信していることのみが表示されます。2 つの 2012 サーバーへの TCP 3343 を介した通信は 4 回待機されますが、最終的にはタイムアウトになり、ノードの追加プロセスがタイムアウト エラーで失敗します。プロセスのこの時点で UDP 3343 をリッスンしていないことが、ノードが完全に追加される前の通常の動作なのか、それともサービスが新しいサーバーで TCP と UDP 3343 の両方を正しくリッスンしていないことを示しているのかはわかりません。
通信を積極的にブロックしているものは何もないようです。新しいサーバーが他のノードからの通信を適切にリッスンしていないだけのようです。それとも、私が間違った方向に進んでいるのでしょうか?
答え1
検証レポートには記載されていませんが、2012 クラスターに 2019 ノードを追加することは物理的に不可能です。