別稿で、Windows Server 2016 S2D を構築する際、仮想マシンを可用性ゾーンで作ってしまい、内部ロードバランサーでうまく使えないことを記載しました。
本稿は、ちょっとした都合で、Azure 上に、Windows Server 2019 S2D を組んだ際の気づきをまとめています。
構築にあたっては、
- Dv3 / Ev3 VM と Nested Virtualization
- Azure仮想マシンでNested Hypver-Vを構築してみる！Part1
- Azure VM の Hyper-V で Nested Virtualization を使い色々試せる検証環境を構築する
- Azure の Nested VM の後で見る用のメモ
- 記憶域スペース ダイレクトで FCI を作成する (Azure VM 上の SQL Server)
を参考にしました。
Windows Server 2019の仮想マシンは、可用性ゾーンで構築しました。この場合も、内部ロードバランサーを使えばよいのだろうと思っていました。別稿のとおり、内部ロードバランサーを使う場合、仮想マシンは可用性セットにしておく必要がありました。
可用性セットで作り直そうかとも思ったのですが、
を読み直したら、「分散ネットワーク名（Distributed Network Name：DNN）」というものが使えるとわかりました。
「分散ネットワーク名」ってなんだ？
- フェールオーバー クラスター インスタンス用に DNN を構成する
- Error (The given key was not present in the dictionary) and SQL Server FCI installation fails on an Azure VM in Server 2019
を読みました。
New-Cluster の実行時に、
-ManagementPointNetworkType Distributed
を指定することで分散ネットワーク名が使えるのですね。コマンド例は、下記のとおりです。
New-Cluster –Name ARC2019S2D1 –Node arcws2019s2d1,arcws2019s2d2,arcws2019s2d3,arcws2019s2d4 –NoStorage –StaticAddress クラスター用のIPアドレス -ManagementPointNetworkType Distributed
※当初は、内部ロードバランサーを使うために、
-ManagementPointNetworkType Singleton
を使おうと思っていました。
DNNが有効化できましたので、オンプレミスと同じような使い勝手が得られました。具体例は、下記のとおりです。
- Azure 上に、Windows Server 2019 S2D を組んだ際、DNNを使わない場合、クラスター対応更新（CAU）が使えませんでした。
Windows Admin Centerから「更新プログラム」つまり、CAUを使うこともできませんでした。 - DNNを有効化したことで、CAUが使えるようになりましたね。
すなわち、Windows Admin Centerからも「更新プログラム」が使えます。
ということで、Azure IaaS で、フェールオーバークラスターを組む場合は、Windows Server 2019以上をお勧めしますよ。（たぶん Windows Server 2022もこの機能をサポートするのだと思いますし）
さて、ここまでできたので、後は下記を参照して、NAT仮想スイッチを作れば仮想マシン配置できますね。
0 件のコメント:
コメントを投稿