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月」を公開します。

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

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%を採用するような動きになっている模様です。


2021年1月2日土曜日

SCDPM 2019 UR2 の新機能 - ボリュームからボリュームの移行の最適化

SCDPM 2019 UR2 の新機能 に、ボリュームからボリュームの移行の最適化というのがあります。

この新機能を使うと、新しいバックアップは、指定された新しいボリュームに取得され、設定変更前のバックアップは保持ポリシーに基づいて既存のボリュームに残るというものです。

この機能を使うためには、下記リンクのレジストリ設定が必要です。

データソースを新しいボリュームに移行する

設計変更前のレジストリ設定です。

設定変更後のレジストリ設定です。

念のため、再起動しておきます。
※SCDPM 関連サービスの再起動だけで良いのかもしれない。。。

[ディスク記憶域の移動]を使って、いくつかディスク記憶域を移動してみます。

データベースのバックアップ先をGドライブに移動してみました。

データベースのバックアップ後、どうなっているか確認しました。
移動先のGドライブにバックアップが取得されています。

既存のディスク記憶域にも、まだデータベースのバックアップは残っています。こちらはおっつけ無くなりますね。

Azure File Sync の通信要件で関係しそうなところ

 まずは、Azure File Sync 自体の通信要件に対して、関連する情報をリストアップ。