さっしーの試してみるか3: 1月 2021

2021年1月23日土曜日

System Center User Group Japan 第23回勉強会資料「Azure PolicyとAutomanage 2021年01月」を公開します

System Center User Group Japan 第23回勉強会資料「Azure PolicyとAutomanage 2021年01月」を公開します。

Azure PolicyとAutomanage 2021年01月 / Azure Policy and Automanage Jan 2021 from Norio Sashizaki

~~動画については、別途公開を予定しています。準備できましたら、このエントリーに追記します。~~
動画が準備できましたので、下記に公開します。

2021年1月15日金曜日

コアクラスターリソースが WMI がらみでペンディングになっているときに使えそうな情報

クラスターノードは活きているが、コアクラスターリソースがオフラインという状況に出くわしました。これは、所有権を持っているノードを「役割のドレイン」などしたところ解消しました。

で、Virtual Machine Cluster WMIのペンディングから遷移しなかったので、これをチェックするため、途中いろいろ調べている際、

Virtual Machine Cluster WMI Failed

を見つけました。こちらの中に

https://blogs.msdn.microsoft.com/clustering/2010/11/23/trouble-connecting-to-cluster-nodes-check-wmi/

というリンクがありますが、（Microsoftのブログプラットフォーム変更に伴い）リンク切れしています。現在のリンクは、下記になっていましたので、備忘として記載しておきます。

Trouble Connecting to Cluster Nodes? Check WMI!
https://techcommunity.microsoft.com/t5/failover-clustering/trouble-connecting-to-cluster-nodes-check-wmi/ba-p/371653

仮想マシンから、Automanage を解除する

Automanage も必要に応じて解除できます。

Automanage の一覧画面から、解除したい仮想マシンを選択し、[自動管理を無効にする]をクリックします。

[無効にする]をクリックします。

（今回のケースだと）仮想マシンの一覧から、対象が消えていれば、OK です。

SCOM エージェントが仮想メモリを大量に消費する？！

SCOM エージェント（Microsoft Monitoring Agent）を SCOM エージェントとして使っている場合です。

MonitoringHost.exeが仮想メモリを異常に消費する

という記事があるそうです。

SCOMアカウントと、通常の操作で使うアカウントが同一であると、仮想メモリを異常消費するそうで。。。

解決方法は、SCOMアカウントと、通常の操作で使うアカウントを分けることということです。

さて、SCOMで使用するアカウント（SCOM インストールで指定するアカウント）は、下記に記載があります。上記も踏まえ、別々のアカウントを指定いただくのが良いですね。

サービス、ユーザー、およびセキュリティアカウント

アクションアカウント
本稿で記載しているアカウントです。
SCOMアカウントと、通常の操作で使うアカウントを分けること、ローカル管理者権限が推奨されること、そして System Center Operations Manager 2019からサービスとしてログオンする許可が必要です。
※ローカル管理者権限でなくても OK なのは、上記リンクに記載がある通りで、権限を選んでいただけます。
　ただ、Linux エージェントをプッシュインストールする場合は、SCOM サーバーにおいてローカル管理者権限が必要になります。
System Center 構成サービスと System Center データアクセスサービスアカウント
SCOM の根幹を支えるアカウントですね。
データウェアハウス書き込みアカウント
SQL Serverに作成される SCOM データウェアハウス DB への書き込みアカウントです。SQL Server でアクセス権限を事前設定しておくアカウントの一つです。
データリーダーアカウント
レポートや SCOM 管理サーバーに接続する際に使われるアカウントです。SQL Server でアクセス権限を事前設定しておくアカウントのもう一つです。

2021年1月8日金曜日

Windows Server 2019 Hyper-V レプリカで、CSV 直下を指定できないみたい

CSV 直下を指定した際のエラー例を下記に記載します。

この失敗例では、上記画像にある通り、Hyper-V レプリカブローカーの所有者ではないノードから操作を行いました。加えて

CSVの所有者ではないノードでもあります。
このように、Hyper-V レプリカブローカーの所有者ではないかつ、CSVの所有者ではないノードだと、レプリカの記憶域としてCSV直下を指定するとエラーになります。

では、一つのノードがHyper-V レプリカブローカーの所有者かつ、CSVの所有者である場合は、どうなるか。
（この例では、CSVの所有者であるノードへ、Hyper-V レプリカブローカーの所有権を移動しました）

設定できたように見えますね。

ところがどっこいレジストリを見てみると、記憶域のパスが他ノードに反映されていません。（4号機は、前の設定が残っているようで、たまたま同じパスになっているだけです、須紛らわしくてすみません）

ということで、どうするのこれってということです。。。

解決策を教えてもらいました。
CSVの直下にフォルダー作成し、そのフォルダーをレプリカの記憶域として指定するのです。
※一つのノードがHyper-V レプリカブローカーの所有者かつ、CSVの所有者のままで確認してます。

この例では、C:\ClusterStorage\Volume01 に HVR フォルダー作成しました。

そのフォルダーをレプリカの記憶域として指定してみます。

エラー無しで、設定できました。

改めてレジストリを確認してみます。

レプリカの記憶域について、レジストリにも各ノードに同じ値が入っていることが確認できました！

Windows Server 2016 Hyper-V レプリカから仕様が変わったのかな？！

ともかく、Windows Server 2019 Hyper-V レプリカは、レプリカの記憶域として、CSVの直下にフォルダー作成し、それを指定するのが良さそうです。

2021年1月7日木曜日

Dual parity efficiency とNew-Volume -NumberOfColumns の関係

ハイブリッドデプロイのデュアルパリティ効率性
や
オールフラッシュデプロイのデュアルパリティ効率性
にある

LRC (8、2、1)　
ハイブリッドデプロイ（SSD+HDD）の12～16障害ドメイン = ハイブリッドデプロイなストレージを搭載する12～16ノードで構成されるS2Dクラスター）
RS 6+2
All Flashの9～15障害ドメイン = All Flashストレージを搭載する9～15ノードで構成されるS2Dクラスター
LRC (12、2、1)
All Flashの16障害ドメイン = All Flashストレージを搭載する16ノードで構成されるS2Dクラスター

ですが、数字部分がどうも New-Volume の -NumberOfColumns オプションに関係するようです。

例として、All Flashの9～15ノードのS2Dクラスターを使います。
9～15ノードのS2Dクラスターにおいて数字部分の合計、つまり"RS 6+2"だと、8になるわけですが、

New-Volume -FriendlyName "Volume03" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 1TB -ResiliencySettingName Parity -NumberOfColumns 8

というように、-NumberOfColumns オプションで"8”を指定すると、デュアルパリティ効率性（Dual parity efficiency）が75%（実際には、74.96%みたいな感じ）になるということです。

この例で、 -NumberOfColumns 8を指定しないと、RS 4+2となり、デュアルパリティ効率性が66.7%なってしまいます。
つまり All Flashやハイブリッドデプロイにおいて CSV 作成時、New-Volume の -NumberOfColumns を指定しなければ、上限値は RS 4+2、すなわちデュアルパリティ効率性の上限値は66.7%を採用するような動きになっている模様です。