다음을 통해 공유


DPM 2010 による Hyper-V 2.0 CSV 環境のバックアップ その 2

こんにちは、System Center サポート部の石井です。

今回は、前ポストに引き続き、Hyper-V CSV 環境を DPM 2010 でバックアップする際の手順をご紹介します。

前のポストはこちらです ↓

DPM 2010 による Hyper-V 2.0 CSV 環境のバックアップ その 1

https://blogs.technet.com/b/systemcenterjp/archive/2010/11/30/dpm-2010-hyper-v-2-0-csv.aspx

- DPM 2010 からのバックアップの設定手順

前回のポストにて、System VSS Provider を使用した場合に、あるコーディネータ ノード上の VM のバックアップ中には別ノードの VM のバックアップを行えないと記載いたしました。

DPM で試しに、2 ノード クラスタで両方のノードが VM をそれぞれ稼働させている場合に、同一保護グループから両 VM をバックアップした場合に以下のエラーになります。(1 LUN に 2 つの VM の VHD が存在する環境です。)

事象発生時の [監視] – [ジョブ] タブの抜粋:

同時に両ノードで同一 LUN 上にある VHD を使用している為、片方の VM のバックアップのみしか同時に行えません。

これを避ける為に、DPM から行う設定は以下の両方の設定が必要です。

           1. ノード単位でのバックアップのシリアル化

           2. LUN 単位でのバックアップのシリアル化

以下に、それぞれの手順をご説明します。

1. ノード単位でのバックアップのシリアル化

既定では、DPM 2010 は単一ノード上での VM は 3 台ごとに並列で行います。(下記ブログ エントリにてご説明しております。)

DPM による Hyper-V VM バックアップにおける同時バックアップ数について

https://blogs.technet.com/b/systemcenterjp/archive/2010/11/12/dpm-hyper-v-vm.aspx

これによって予測出来る不具合としては、単一ノードで、別 LUN にそれぞれ存在する VM を 3 台同時にバックアップしてしまい、3 LUN とも、別ノードからの Redirect I/O を発生させてしまう、ということです。(3 LUN へアクセスしている他のノード全てが、バックアップしている Hyper-V ホスト経由での Redirect I/O を生じさせてしまうため、リダイレクト処理のオーバーヘッドの分のパフォーマンス劣化が生じる上、ホストへの負荷も高くなります。)

まずは、DPM 2010 サーバー上にて、上記ブログ エントリにて紹介しております、“MaxAllowedParallelBackups” キーの “Microsoft Hyper-V” の値を 1 に設定します。

これにより、Hyper-V ノードごとのバックアップは 1 台ごとに終わりますので、上記 3 台並列バックアップに伴う負荷等の懸念事項をクリア出来ます。

2. LUN 単位でのバックアップのシリアル化

続いて、LUN ごとのシリアル化です。

ノード単位のシリアル化をしても、複数のノードが 1 LUN にアクセスしてしまうことで、あるノードがバックアップ中に別のノードのバックアップが失敗してしまう現象については発生する可能性が十分にあります。(保護グループをわけて、スケジュールを別にすることである程度は回避可能ですが、台数が多くなってくると管理が面倒です。)

このエラーを避けるためには、LUN 単位でのシリアル化を設定する必要があります。ノード単位のシリアル化と違って、若干手順が面倒です。

2-1. DSConfig.ps1 により CSV の構成 XML ファイルを作成する

以下の弊社技術情報にある、DSConfig.ps1 のコードをコピーし、テキスト ファイルに ”DSConfig.ps1” というファイル名で保存します。

Considerations for Backing Up Virtual Machines on CSV with the System VSS Provider

https://technet.microsoft.com/en-us/library/ff634192.aspx

2-2. DSConfig.ps1 をクラスタの 1 つのノードで実行する。

DSConfig.ps1 を 1 つのクラスタ ノードにコピーし、PowerShell の画面から実行します。

この際の注意事項は以下です。

注意事項:

PS1 ファイルの実行にあたっては Set-ExecutionPolicy コマンドでコード署名を無効化しなければいけません。

例: Set-ExecutionPolicy unrestricted

参考情報: Set-ExecutionPolicy コマンドレットの使用

https://technet.microsoft.com/ja-jp/library/ee176961.aspx

DSConfig.ps1 を実行すると、DSConfig.ps1 と同階層に DataSourceGroups.xml という XML ファイルが出力されます。

以下の通り、該当の XML ファイルの <Group> タグ内に CSV 上の VM 名が記録されていることが分かります。

クラスタ環境が 1 つだけの場合には、この DataSourceGroups.xml ファイルを DPM サーバー上の “%Programfiles%\Microsoft DPM\DPM\Config” フォルダにそのままコピーします。

DPM からバックアップしているクラスタが複数存在する場合、以下の手順も実行します。

2-3. 複数のクラスタがある場合、全てのクラスタで DataSourceGroups.xml を出力する。

複数のクラスタをバックアップしている場合、全てのクラスタで、1 つずつ DataSourceGroups.xml ファイルを出力していきます。(各クラスタごとに、ノードのどれか 1 つで DSConfig.ps1 を実行すれば OK です。各ノード全てではありませんのでご注意下さい。)

続いて、複数の XML ファイルをマージする手順が必要です。

DPM サーバー上の “%Programfiles%\Microsoft DPM\DPM\Config” フォルダに DataSourceGroups.xml ファイルが存在します。

この <DataSourceGroup> タグから </DataSourceGroup> タグまでの中に、<Group>…</Group> というタグがあります。各クラスタから採取した XML ファイル内の <Group>…</Group> を全てここにコピーします。

--------------

<DataSourceGroup>

<Group GroupName=”…”> クラスタ 1 から取った XML の Group 情報</Group>

<Group GroupName=”…”> クラスタ 2 から取った XML の Group 情報</Group>

<Group GroupName=”…”> クラスタ 3 から取った XML の Group 情報</Group>

</DataSourceGroup>

--------------

2-4. 保護グループの構築を行います。(既に保護グループを作成している場合、保護グループ変更ウィザードを開始し、”次へ” を押して進めてゆき、完了させることで XML ファイルの変更を認識できます。)

以上で手順は完了です。これで、同一 LUN へのバックアップは、1 ノードずつ順番に行うように DPM がスケジュールします。

Hyper-V CSV クラスタ上で、VM の追加、削除、変更を行った場合には、必ず XML ファイルを再作成し、DPM サーバーにコピーする必要があります。(XML を変更した場合には、“保護グループの変更” ウィザードを実行し、完了させる手順も忘れずに行って下さい。)

- シリアル化後のバックアップ実行例

弊社の検証環境でのスクリーンショットを交えて、ノード単位のシリアル化と LUN 単位のシリアル化が両立された場合のジョブの実行例をご紹介します。

環境:

以下の 3 台の VM を同一保護グループにてバックアップしています。

Node A – VM 1 (オンライン バックアップ) と VM 3 (オフライン バックアップ)

Node B – VM 2 (オンライン バックアップ)

全ての VM は同一 LUN 上にあります。

以下のように、同一保護グループに 3 台の VM が存在するため、同じスケジュールにてバックアップが開始します。

3 台中、Node A の VM 3 だけのバックアップ開始され、他のものは “保留中” のステータスになります。(ノード単位のシリアル化のため、同ノードの VM 1 のバックアップは保留されています。また、LUN 単位のシリアル化のため、Node B のバックアップは保留されています。)

1 台が完了した後、Node B の次の VM (VM2) のバックアップが始まります。

2 台のバックアップ完了後、最後の 1 台がバックアップされます。

また、上記設定のほか、バックアップの際のボリュームの確保処理のリトライ回数をレジストリ変更にて増加可能です。

DPM 2010 による Hyper-V の Live Migration (CSV) 環境のバックアップ時、VSS ハードウェア プロバイダを使った場合の注意事項について

https://blogs.technet.com/b/systemcenterjp/archive/2011/07/14/dpm-2010-hyper-v-live-migration-csv-vss.aspx

※ 上記リンク先の設定は、ソフトウェア プロバイダを使った環境でも有効な場合がありますので、バックアップが不安定な場合にお試し下さい。

 

参考情報:

DPM からの CSV バックアップ手順の詳細は、以下の Technet ライブラリの技術資料をご参考下さい。

Understanding Protection for CSV

https://technet.microsoft.com/en-us/library/ff634189.aspx

System VSS Provider を使用したバックアップの手順は以下です。

Considerations for Backing Up Virtual Machines on CSV with the System VSS Provider

https://technet.microsoft.com/en-us/library/ff634192.aspx

その他の参考情報:

VSS Hardware Provider を用いてバックアップする際の考慮事項は以下をご参照下さい。

Considerations for Backing Up Virtual Machines on CSV with Hardware VSS Providers

https://technet.microsoft.com/en-us/library/ff634220.aspx

-> Hardware VSS Provider が存在する場合、DPM 2010 は既定で Hardware VSS Provider を優先いたします。CSV のバックアップに失敗する際に、Hardware VSS Provider のエラーであるかの切り分け等の為、Hardware VSS Provider を使用せず、System VSS Provider を優先して使う場合には、本リンクの “How to use inbox VSS Software Provider in place of VSS hardware provider” を参照いただき、レジストリ キーを設定して下さい。

VSS Hardware Provider をご利用いただく場合に、DPM 2010 にてテストされたハードウェアは以下となります。

Tested hardware VSS provider table

https://blogs.technet.com/b/dpm/archive/2010/07/08/tested-hardware-vss-provider-table.aspx

Hardware VSS Provider を新規導入した場合で、System VSS Provider から Hardware VSS Provider に設定を変更する場合は以下をご参考下さい。

Migrating from the System VSS Provider to a Hardware VSS Provider

https://technet.microsoft.com/en-us/library/ff634216.aspx

以下は、富士通様の情報となりますが、ETERNUS と DPM を用いたバックアップ リカバリについての資料となります。Hardware VSS Provider を使用しているため、Redirect I/O の影響が最小限となり、高速なバックアップが期待出来ます。

ETERNUS ディスクアレイとMicrosoft System Center Data Protection Manager 2010 による、Hyper-V CSV ボリュームのバックアップ/リカバリ・ソリューション

https://storage-system.fujitsu.com/jp/partners/microsoft/dpm/