2021年1月15日金曜日

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 自体の通信要件に対して、関連する情報をリストアップ。

2020年12月20日日曜日

SCDPM 2019 を作り直したら、ID 31313を引いた

物理サーバーのディスク構成を見直し、SCDPM 2019 を作り直しました。

Windows Server 2008などの仮想マシンをバックアップしようと設定を作成しようとしたところ、下記のエラーが発生。


調べると、下記のようなエントリーがありました。

System Center Data Protection Manager 2016 Error 31313 during creation of protection group

SQLをアレンジして、実行してみました。

仮想マシンが選択できるようになりましたー


SQL Server のサービスパックや累積更新プログラムについて、最新版を確認できるページがあるんですね

 Microsoft SQL Server の最新の更新プログラム

SQL Server 2008からSQL Server 2019(おそらく今後リリースされる最新バージョンもでしょうね)について、累積更新プログラムやサービスパックで最新版を確認できますね!

このページはちょくちょく確認することになりそうです、ありがたい!