事象
Azure Stack HCI OSでクラスタを作成中にクラスター検証に失敗する事象に遭遇しました。
ネットワークインターフェイス node1.hci.local – Management と node2.hci.local – Management が同じクラスターネットワーク上にありますが、ポート 3343 で UDP を使用して xxx.xxx.xxx.xxx からアドレス xxx.xxx.xxx.xxx に到達できません。
ですが、ネットワーク的に本当にブロックしているわけでもなく原因がわかりませんでした。切り分けのためにFirewallもすべて無効化しましたが効果なし。
そもそもクラスタにするような環境ではUDP 3343で待ち受けているプロセスがあるのかと思いましたが、ほかのクラスタの検証に成功する環境で確認したところそのようなプロセスはありませんでした。テスト実行中に動的に作成されるプロセスで通信確認しているようです。
逆に何かほかのプロセスが待ち受けでUDP 3343を使ってしまっているわけではないことも、netstat -ano で確認しました。
本当にUDP 3343で通信できるかどうかの確認
本当にUDP 3343で通信ができるかどうかを確認しました。いつもUDPでの疎通確認方法には困っていたのですが、今回下記のPowerShellを発見しました。手軽でとても便利ですね。
https://cloudbrothers.info/en/test-udp-connection-powershell/
こちらのスクリプトを使って実際にUDP 3343で通信できることを確認しました。何も問題ありません。ということで、おそらくこのエラーが出るのはバグっぽいなぁと思います。
ネット上の情報
ネットで検索すると結構UDP 3343で通信できないことが原因でクラスタの検証に失敗している例はあるようです。
でも、今回は該当しませんでした。
回避
ちょっと回避策がわかりませんでした。仕方がないのでAzure Stack HCI OSの英語版をノードにインストールしなおして、再実行したところすんなりと検証に成功してしまいました。
もともとの事象が発生していた環境は日本語版のAzure Stack HCI OSを使っていました。ですので、日本語版のAzure Stack HCI OSにはクラスタの検証に失敗するバグがある…。のかもしれません。
ただし、別環境では日本語版Azure Stack HCI OSでうまく成功しているケースもありますし、ネット上の情報では英語版のWindows Serverでの事例もあるし、はっきりとしたことはわかりません。
とりあえず、このエラーが出てしまったら、そのまま問題を深堀りするよりはOS自体を入れなおしたりしてしまったりしながら再構築してしまったほうが早そうな印象です。何かしら複雑な問題再現手順があるものと思います。ただ、基本的には検証プログラム自体が抱えている問題(バグ)があるものと推測します。
解決策が提示できず申し訳ないですが、参考にしてもらえればと思います。
2021/10/19追記
Microsoft MVP仲間の話によると、ほかの環境でも同じ問題が発生しているようです。
私の遭遇した環境ではIntel X722 NICを使っていたのですが、「Intel NICの問題ではないか？」という推測が上がっています。回避策としてはIntel NICを無効化する、という方法が有効だったという報告があります。
正しい情報かどうかはまだわかりません。
Leave a Reply