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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Azure File Sync のデプロイの計画 - ネットワーク
  基本的には、HTTPS 通信ですね。ただし、下記の要件も考慮な感じですね。
  ※キーワードは、上記リンクより少しアレンジして引用してます。
• ExpressRoute または Azure VPN 経由
  
• 仮想プライベート ネットワークまたは ExpressRoute でトラフィックをトンネリングする
• プライベート エンドポイント
  からたどれる
  Azure File Sync ネットワーク エンドポイントの構成
  で、Azure のパブリックエンドポイントへの接続を制限できますね。
  ここで、ストレージアカウントの話が出てきます。下記も踏まえておくと良さそうですね。
• Azure Storage ファイアウォールおよび仮想ネットワークを構成する
• Azure Files と Azure のネットワーク機能
• Azure Files のネットワークに関する考慮事項
• Azure Files ネットワーク エンドポイントの構成
  こちらにもプライベートエンドポイントを構成し、パブリックエンドポイントを制限するお話があります。
• オンプレミスネットワーク環境でプロキシをサポートするよう Azure File Sync を構成
• Azure File Sync のプロキシとファイアウォールの設定
  プロキシを経由した接続許可を構成するには、上記リンクがとても役立ちます。
  まあ例によって、接続先は、IPアドレスよりドメイン名のほうが、管理は柔軟にできます。
  
• Azure File Sync IP アドレスの許可リスト
  も一応あります。
• Azure File Sync からネットワーク アクティビティを調整
• モニター
  接続関連の設定を行ったら、下記に基づき監視になりますね。
• Azure File Sync の監視
• Azure Files の監視
• Azure File Sync のトラブルシューティング
  こちらも確認しておくの良さそうですね。

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（おそらく今後リリースされる最新バージョンもでしょうね）について、累積更新プログラムやサービスパックで最新版を確認できますね！

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

Azure Update Management 展開スケジュールの実行履歴

 Azure Update Management 展開スケジュールの実行履歴も見れるようになりましたので、例としてご覧ください。

任意の実行履歴を見るとこんな感じで、状況が確認できます。

Azure Update Management でオンプレミス用の展開スケジュールを作成

結論から申し上げますと、Azure VM のやり方と変わらないです！
※Log Analytics エージェントが関連付けられている Azure サブスクリプションを選択することになるため、結果的に同じやり方になってました。

Azure Update Management の「更新プログラムの展開のスケジュール」も併せてご覧ください。

展開スケジュールの作成画面を開きます。名前を入力したところです。ちなみに、名前は後から変更できないので、命名規則を先に考えたほうが良いですね。

次に[更新するグループ]を選択します。

こちらの操作が、「オンプレミスなサーバーにインストールしてあるLog Analytics エージェント」が関連付けられている Azure サブスクリプションを選択することになります。

ここでは、すべてのサブスクリプションを選択しています。

次に、対象とするマシンを選択します。

赤枠の[タイプ]で"マシン"を選択します。

[タイプ]で"マシン"を選択すると、対象になるマシンが表示されます。対象にしたいマシンンの名前をクリックし、

[OK]をクリックします。

次に、スケジュール設定を行います。

この例だと、3週間おきということですね。（この後、2週間おきに修正しました）

ほかのパラメーターは既定値のままにします。[作成]をクリックします。

こんな感じで出来上がりです。