ノード削除自体は、シンプルです。が、実際にやろうとすると
VMGroup なるものを知ったの巻。
※仮想マシンのバックアップなどで使われることがあるようです。
Remove-VMGroup で VMGroup が消せそうとしましたが、エラー。。。
Remove-VMGroup : 操作に失敗しました。
予期しないエラーが発生しました: ライブラリ、ドライブまたはメディアプールはこの操作を実行するためには空でなければなりません。(0x800710D3)
VMMembers : {}VMGroupMembers :
エラーメッセージも、VMGroup に何か入っている的なものだったので、もしかしてメンバーを何とかして特定し、その関連付けを外せばよいのかなと。
docs.microsoft.com の Remove-VMGroup のコマンドレットページを眺めていたら、
なるものが！
幸いにして仮想マシン名は、判明したので、Remove-VMGroupMember の Examples を使って、一台ずつ仮想マシンを VMGroup のメンバーから外しました。
その後、Remove-VMGroup で VMGroupを無事に削除できましたよ。
VMGroup の関連付けが空になっていないと、Remove-VMGroup で VMGroup を消すことができないのですね。勉強になりました。
※仕組みを考えるとある意味当たり前の話ですね。。。
にパフォーマンス履歴の PowerShell が記載されています。見た方も多いのではないでしょうか。
本稿では、個々の PowerShell コマンドレットではなく、そのサンプルを紹介します。
PowerShell と記憶域スペースダイレクトパフォーマンス履歴を使用したスクリプト
いくつかのコードサンプルが記載されています。これを基にカスタマイズできますよ。
また、
Get-ClusterPerformanceHistory
で、
-TimeFrame
を指定したときの利用可能な期間は、
に記載されています。は、指定しないときはどうなるのか。同じページの別の場所にちゃんど書かれています。以下引用します。（日本語訳だと、ちょっと変な感じになっているので、あえて英語）
You can specify the timeframe of history you want with the -TimeFrame parameter.
If you don't specify, the MostRecent measurement is returned.
ということで、MostRecent で採取できますよ。これはこれでリアルタイムのパフォーマンス測定したい場合には、ありですね。
さて、簡単にグラフを見たい場合は、Windows Admin Center をつかってください。
にグラフのサンプルが出ています。ちなみに、手元の Nested Hyper-V だとこんな感じで表示されてます。
いつまでもあると思うな Cluster コマンドという感じなので、後生のために差異を確認しました。
Get-Cluster を読み直したところ、プロパティをすべて表示させれば、Cluster コマンドとほぼ同じことができますね。どういう感じで差異があるかについて、画像を貼っておきます。また、画像と同じものをPDFファイルにしているので、必要に応じてご参照ください。
同僚の方より、Hyper-V vSwitch における負荷分散フェールオーバー (LBFO)は、Azure Stack HCI でのサポートが無いようだと聞きました。
教えてもらった情報
を読んでみました。上記から本文を引用しますと、
SET は、Azure Stack HCI でサポートされている唯一のチーミング テクノロジです。 負荷分散フェールオーバー (LBFO) は、Windows Server で一般的に使用される別のチーミング テクノロジですが、Azure Stack HCI ではサポートされていません。
とありますね。。。
ほかにも、下記の情報を教えていただきました。
Teaming in Azure Stack HCI より本文を引用します。
All-in-all, we’re not focusing on LBFO much these days, particularly as software-defined Windows Server networking scenarios become more exotic with the rise of containers, software-defined networking, and much more. There’s a faster, more stable, and performant teaming solution, called Switch Embedded Teaming.
Features we're no longer developing より本文を引用します。
Hyper-V vSwitch on LBFO In a future release, the Hyper-V vSwitch will no longer have the capability to be bound to an LBFO team. Instead, it must be bound via Switch Embedded Teaming (SET).
これらを見ていくと、今後は スイッチが埋め込まれたチーミング/Switch Embedded Teaming (SET)を主流にしていくのかなと思います。
例えば。
Windows Admin Center において、 Azure Stack HCI OSを使ったクラスター作成では、SET を使っていくようになっています。
※もちろん、Azure Stack HCI OS は、Storage Spaces Direct (S2D)です。ストレージ同期ジョブに高速なネットワークを使います。その高速なネットワークを通すためには、SET が最適というのも理由でしょう。
SET は、PowerShell で作成しますので、このあたりの押さえておくべき技術になるのかもしれませんね。
別稿で、Windows Server 2016 S2D を構築する際、仮想マシンを可用性ゾーンで作ってしまい、内部ロードバランサーでうまく使えないことを記載しました。
本稿は、ちょっとした都合で、Azure 上に、Windows Server 2019 S2D を組んだ際の気づきをまとめています。
構築にあたっては、
を参考にしました。
Windows Server 2019の仮想マシンは、可用性ゾーンで構築しました。この場合も、内部ロードバランサーを使えばよいのだろうと思っていました。別稿のとおり、内部ロードバランサーを使う場合、仮想マシンは可用性セットにしておく必要がありました。
可用性セットで作り直そうかとも思ったのですが、
を読み直したら、「分散ネットワーク名（Distributed Network Name：DNN）」というものが使えるとわかりました。
「分散ネットワーク名」ってなんだ？
を読みました。
New-Cluster の実行時に、
-ManagementPointNetworkType Distributed
を指定することで分散ネットワーク名が使えるのですね。コマンド例は、下記のとおりです。
New-Cluster –Name ARC2019S2D1 –Node arcws2019s2d1,arcws2019s2d2,arcws2019s2d3,arcws2019s2d4 –NoStorage –StaticAddress クラスター用のIPアドレス -ManagementPointNetworkType Distributed
さて、ここまでできたので、後は下記を参照して、NAT仮想スイッチを作れば仮想マシン配置できますね。
ちょっとした都合で、Azure 上に、Windows Server 2016 S2D を組もうと思い立ちました。
を参考にしました。
で、本題ですけど、Azure 仮想マシンでフェールオーバークラスターを組む時には、内部ロードバランサーが必要と思っていました。
が、その場合は、可用性セットを使わないと、内部ロードバランサーのバックエンドプールにとしてうまくいかないと知りました。。。以下、顛末です。
可用性ゾーンで作れば良いやと、Azure 仮想マシンを作ったわけです。で、内部ロードバランサーのバックエンドプールを構成しました。
止めてあった仮想マシンを起動しようとしても起動しない。。。
クラスターの役割としてコンピューターオブジェクトを指定して、クラスター対応更新（CAU）を登録しています。
が、初回登録の挙動がおかしいような。。。 virtualComputerObjectName で指定したコンピューターオブジェクトを使わってくれていない表示になってます。
旦、CAU を削除してから、再登録すると virtualComputerObjectName で指定したコンピューターオブジェクトを使ってくれた表示です。
