さっしーの試してみるか3

2021年5月1日土曜日

Windows Admin Center で、Cluster-Aware Updating を実行

命名規則にそったクラスターリソース名で、Cluster-Aware Updating を有効化する　からの続き。

クラスター対応更新が構成できたので、Windows Admin Center から動きを見てみます。更新プログラムのスキャンが終わったタイミングが下記です。

[次のステージ: インストール]をクリックします。

更新プログラムが検出できたので、インストールします。

順次開始。

完了しました。

完了したのは良いのですが、どこでドレインしているのかが、ちょっと判別できない。。。

ということで、クラスター対応更新で、ステップごとの挙動をもう少し細かく見てみようと思います。

命名規則にそったクラスターリソース名で、Cluster-Aware Updating を有効化する

Windows Admin Center で Cluster-Aware Updating を有効にすると　では、クラスターリソース名でコンピューターオブジェクトができるとわかりました。が、こちらが指定する名称でクラスターリソース名（コンピューターオブジェクト）を作れないこともわかりました。

こちらが指定する名称でクラスターリソース名（コンピューターオブジェクト）を作る方法を探ります。その方法として、PowerShell があると認識しました。PowerShell は、下記を使います。

Add-CauClusterRole

で、-VirtualComputerObjectName オプションを使えば、こちらが指定する名称でクラスターリソース名（コンピューターオブジェクト）を作れますね。

では、クラスターリソース名（コンピューターオブジェクト）に対して、

クラスター名アカウントを事前設定する手順

の方法を使って、Cluster-Aware Updating 用のコンピューターオブジェクトにアクセス権限を付与しました。
※が、つもりでして、あとで設定箇所を間違えていたことがわかります。。。

Add-CauClusterRole を確認する前に、クラスター対応更新は、どういう感じなのか見ておきましょう。

サーバーマネージャーから、クラスター対応更新を起動します。

起動したら、[クラスターの自己更新オプションの構成]をクリックします。

ウィザードが起動したら、[次へ]をクリックします。

[CAU のクラスター化された役割を、自己更新モードを有効にしてこのクラスターに追加]をチェックし、[次へ]をクリックします。

赤枠内の自己更新スケジュールを変更します。

第３火曜日だと、日本のパッチ適用スケジュールに合わないのと、こちらの PoC 環境の起動スケジュールに合わせて、変更しました。[次へ]をクリックします。

詳細スケジュールは、既定値のままにします。

[次へ]をクリックします。

こちらのオプションは、チェックしようと思いましたが、一旦このままにします。あとで Add-CauClusterRole のオプションを追加して作り直しても以下と思いましたので。[次へ]をクリックします。

設定値のサマリー画面です。

ちょど良い具合に、Add-CauClusterRole のオプションが指定されていますね。これをベースに、-VirtualComputerObjectName オプションを追加してみます。
※なので、ウィザードは、ここでキャンセルします！

Add-CauClusterRole に、-VirtualComputerObjectName オプションを追加して実行します。

指定したクラスターリソース名になってない。。。
※ここで、設定箇所を間違えたことに気づく。クラスター名アカウントを事前設定する手順の項番8～12を実施していました。これだと、上記の挙動になってしまいますね。

作成したクラスターリソースを削除します。

クラスター名アカウントを事前設定する手順の項番1～6とプラスαを実施します。
※先に、クラスター名アカウントを事前設定する手順の項番7～12を実施していました。よって、項番1～6だけ実施です。

作成したクラスターリソース名（コンピューターオブジェクト）に対して、クラスターアカウントがフルコントロール権限を持つように設定した例が上記です。

再び、Add-CauClusterRole を実行します。

今度は、うまくいきました！
Add-CauClusterRole のスクリプト例を下記に貼っておきます。

Add-CauClusterRole -ClusterName s2dws2019 -VirtualComputerObjectName s2dws2019cau -Force -CauPluginName Microsoft.WindowsUpdatePlugin -MaxRetriesPerNode 3 -CauPluginArguments @{ 'IncludeRecommendedUpdates' = 'False' } -StartDate "2021/04/30 11:00:00" -DaysOfWeek 1 -WeeksOfMonth @(3) -EnableFirewallRules -Verbose

Get-CauClusterRole でクラスターリソースのパラメーターを見てみます。

クラスターリソースに対して、ping を打ってみました。

IP アドレスで逆引きしてみたところ、クラスターノードの一台ですね。よってクラスターリソース用に IP アドレスは用意しなくてもよさそうですね。

Windows Admin Center で、Cluster-Aware Updating を実行　に続く。

Windows Admin Center で Cluster-Aware Updating を有効にすると

Windows Admin Center で Cluster-Aware Updating を有効にしてみます。

というかその前に、アクセス権限を調整しないとだめなのでした。。。と言いますのも、Cluster-Aware Updating のクラスターリソースとして、AD ドメインにコンピューターオブジェクトが作成されます。このクラスターリソースは、クラスターアカウント/クラスターのコンピューターオブジェクトにより作成されるため、子オブジェクトの作成権限が無いと作成に失敗してしまいます。具体的な手順は、

クラスター名アカウントを事前設定する手順

の項番7～12です。本稿向けにちょっとカスタマイズして、下記に転記します。

ドメインコントローラーで、[スタート] をクリックし、[管理ツール] をクリックして、[Active Directory ユーザーとコンピューター]をクリックします。[表示] メニューで、 [高度な機能] が選択されていることを確認します。
Cluster-Aware Updating のクラスターリソースを作成したい、フォルダー（OUもしくはコンテナー）を右クリックし、[プロパティ] をクリックします。
[セキュリティ] タブで [詳細設定] をクリックします。
[ 追加] をクリックし、[オブジェクトの種類] をクリックして [コンピューター] が選択されていることを確認し、[OK] をクリックします。次に、[選択するオブジェクト名を入力してください] に、「クラスターアカウント/クラスターのコンピューターオブジェクト」の名前を入力し、[OK] をクリックします。無効なオブジェクトを追加しようとしているというメッセージが表示された場合は、[OK] をクリックします。
[アクセス許可エントリ] ダイアログボックスで、 [コンピューターオブジェクトの作成] および [すべてのプロパティの読み取り] のアクセス許可を見つけ、それぞれに対して [許可] チェックボックスがオンになっていることを確認します。
[Active Directory ユーザーとコンピューター] スナップインに戻るまで、[OK] をクリックします。

これを Windows Admin Center で Cluster-Aware Updating を有効化する前（というか、Windows Server のサーバーマネージャーからクラスター対応更新を起動して、Cluster-Aware Updating を有効化する場合もです）にやっておかないと、確実に Cluster-Aware Updating の有効化に失敗します！

クラスターアカウントにコンピューターオブジェクトを作成した権限が用意できましたら、Windows Admin Center で Cluster-Aware Updating を有効しましょう。

しばらく待っていると、有効化できます。

さて、どういうクラスターリソースができたのか見てみます。

クラスターリソースは、下記のような命名規則になってます。

固定の接頭子3文字：CAU
クラスターアカウントの最初5文字
任意の3文字

ということで、ホスト命名規則に合わないケースもあると思います。別稿でそのやり方を探ってみます。

命名規則にそったクラスターリソース名で、Cluster-Aware Updating を有効化する　に続く。

2021年4月25日日曜日

Azure Stack HCI OS で、仮想スイッチを作ってみる

Azure Stack HCI OS ノードを追加する前に Switch Embedded Teaming (SET) 仮想スイッチをそろえておきたいと思いました。

二つの SET を作成するパターンで、構築してました。
Windows Admin Center の Cluster Creation で Azure Stack HCI を組むその2

上記で作成した SET は、二つあります。Hyper-V の仮想スイッチマネージャーで見てみます。

Windows Admin Center では、このようになってます。

ホスト OS への管理ネットワークアダプターは、普通に作れるとして、SRIOV のオプションが有効化されるかも確認点となります。

早速、Windows Admin Center で作成してみました。

NIC が全部入っているし、SETになってない。。。

というわけで、PowerShell で仮想スイッチを作り直します。とりあえず、どういう感じで構成されているのか、Windows Admin Center から確認しておきます。

作成できました。GUI から違いが無いか見てみます。

SR-IOV が有効になってない。

-EnableIov $true を追加して作り直します。

今度は大丈夫です。

※ちなみに、-EnableEmbeddedTeaming $true が既定になっているような感じで、このオプションがなくても SET になっているような。

Get-VMswitch から違いがないか、diff チックに確認してみます。

違いがありますね。。。どちらの仮想スイッチで差異があるのか確認します。

DefaultQueueVmmqQueuePairsRequested
DefaultQueueVrssMaxQueuePairsRequested

に違いがありました。

プロパティを変更できるかやってみます。

読み取り専用のため、できない。。。

set-VMswitch を見てみましたが、変更できるプロパティではないようですね。。。

ということで、Windows Admin Center のクラスター作成と、PowerShell による SET 作成では、一部のプロパティに差異があります。これを防ごうとすると、事前に PowerShell で SET 作成し、Windows Admin Center のクラスター作成に進むのがよさそうです。
この仮説が可能なのかを確認してみます。別稿に続く。