仮想化バックアップについてお話しましょう

1. 概要

仮想化バックアップ テクノロジーは、VMware によって最初に提供され、開始されました。企業やさまざまな業界で仮想化アプリケーションが普及するにつれ、主流のバックアップ製品は基本的に VMware、Hyper-V、Citrix、および Xen または KVM から派生した仮想化プラットフォームをサポートしています。

仮想マシンのバックアップは、仮想マシンのスナップショットとは異なり、仮想化データ保護のための最も重要な基本的な手段です。仮想化を初めて使用するユーザーの多くは、仮想マシンのスナップショットをバックアップと見なすことがよくありますが、これは実際には重大な間違いです。理由は次のとおりです。

1. スナップショットは、仮想化されたローカル バックアップのソリューションにはなりません。

2. スナップショットを使用して以前の状態を復元すると、現在の状態に戻ることはできません。

3. 仮想マシンのディスク ファイルが破損すると、スナップショットは無効になります。

4. スナップショットは仮想マシンイメージ全体に基づいてのみ復元でき、ファイルレベルまたはアプリケーションの粒度で復元することはできません。

5. スナップショットは、仮想化を保護し、迅速に回復するための補助手段としてのみ使用できます。

6. すべての仮想マシンでスナップショットを使用できるわけではありませんが、すべての仮想マシンでバックアップを使用できます。

7. スナップショットが多すぎると、仮想マシンのパフォーマンスに重大な影響が及び、スナップショットの作成または削除中に仮想マシンのデータが破損する可能性があります。

[[222336]]

現在、仮想化プラットフォーム向けの主流のバックアップ ソリューションは 2 つあります。1 つはエージェントレス バックアップ、もう 1 つはエージェント バックアップまたはゲスト OS レベルのバックアップです。この記事では、エージェントレス バックアップとエージェントベース バックアップの長所と短所を分析および比較することで、仮想化バックアップの最良の実践的経験をまとめます。

2. エージェントレスバックアップの分析

エージェントレス バックアップとは通常、仮想マシンにバックアップ エージェント (クライアントまたはプローブとも呼ばれます) をインストールする必要がないことを意味します。バックアップ VM は、ESXI ホストまたはハイパーバイザー クラスターに 1 つまたは複数のエージェント仮想マシン (バックアップ エージェント アプリケーション) を展開することによってキャプチャされます。

エージェントレス バックアップの利点は明らかです。

1. 簡単な展開とインストール。各仮想マシンにバックアップ エージェントをインストールする必要はありません。ハイパーバイザー統合を構成することで、完全に自動的な展開を完了できます。

2. エージェントレス バックアップでは、仮想化メーカーが提供する専用のバックアップ インターフェイスを最大限に活用します。仮想マシンをバックアップする際に、リソースの消費を最適化し、バックアップ中の仮想マシン自体の負荷を軽減できます。

3. 特別に適応された仮想化プラットフォーム上でエージェントレス バックアップ製品を使用すると、仮想化プラットフォーム固有のバックアップおよびリカバリ機能を実現できます。 (CBT\RCT ブロック トラッキング、インスタント リカバリ、仮想マシン レプリケーションなど)

4. 仮想化メーカーによると、エージェントレスのバックアップとリカバリの方が高速です。

5. エージェントレス バックアップには、LAN フリーまたはサーバーフリーのバックアップ方式を実装する場合に多くの利点があります。

前述のように、エージェントレス バックアップは多くのバックアップ ベンダー、特に仮想化ベンダーによって強く推奨されています。多くのユーザーは、エージェントレス バックアップは仮想化プラットフォームとより適切に統合できると考えています。

しかし、実際のアプリケーションではエージェントレス バックアップには多くの問題があります。実際の運用では、エージェントレス バックアップに次のような欠陥が見つかります。

1. 仮想化ベンダーが提供するバックアップ インターフェイスによって制限されるため、一部のエージェントレス バックアップ製品では、アプリケーション認識、きめ細かいデータ回復、RDM (raw ディスク マッピング) 仮想マシン バックアップを実現できません。

2. エージェントレス バックアップで VM をバックアップする場合、仮想化プラットフォームはまずバックアップする VM のスナップショットを取得し、そのスナップショット情報をエージェントレス バックアップ ソフトウェアに渡します。この VM スナップショットは、I/O が高い VM や非常に大量のデータ (TB レベルの VM) を持つ VM、およびマルチディスク構造を持つ VM で問題を引き起こす可能性が最も高くなります。スナップショット時間は数時間または数日間続く場合があります。スナップショット処理中に仮想マシンのディスク ファイルに異常が発生すると、VM がクラッシュする可能性があります。バックアップの最後にスナップショットを削除する場合にも同様の状況が発生する可能性があります。さらに、仮想化プラットフォーム自体のスナップショットは、サイレントに適用できないことがよくあります。特にデータベース タイプの VM の場合、リカバリ中にデータの一貫性の問題が発生する可能性があります。

3. 実際のシナリオでは、エージェントレス バックアップのリソース消費量はエージェントベース バックアップよりも低くはなく、場合によってはそれ以上消費します。エージェントレス仮想化バックアップでは、ホスト CPU がより限られたリソースであり、通常 1 つのコアが 6 台以上の仮想マシンで共有されるため、CPU リソースの消費に特別な注意が必要です。注意深く分析すると、バックアップ中に CPU 使用率がピークになる主な理由は 2 つあることがわかります。たとえば、バックアップ エージェントがファイル システム全体をスキャンして、バックアップの対象となるファイル (通常は前回のバックアップ以降に変更されたファイル) を探す必要があるときに、CPU スパイクが発生します。たとえば、増分バックアップまたは差分バックアップ中、このようなディレクトリ ツリーのトラバーサルは非常に時間がかかり、CPU を大量に消費します。 2 番目に、バックアップ プロセス中の実際のデータ転送によって CPU スパイクが発生する可能性があります。 CPU ピークの問題に対処するために、仮想化ベンダーは、VM 内のディレクトリ ファイルを走査して比較するのではなく、基盤となるディスク ブロックの変更を追跡することで増分バックアップと差分バックアップ中のリソース消費を最適化するブロック追跡テクノロジ (VMware の CBT や Hyper-V 2016 の RCT など) を開発しました。

4. 実際のシナリオでは、エージェントレス バックアップは遅くなります。エージェントレス バックアップは通常、ビジネス アプリケーションの速度を低下させることなく、ホストごとに 2 つの VM を同時にバックアップすることに制限されています。プロキシレス ソリューションの利点が主張されているにもかかわらず、転送されるデータの量を削減するブロック追跡テクノロジが使用されています。ただし、エージェントレス バックアップ方法はブラインド スキャンに近いため、バックアップ プロセスに「プル」方式が必要となり、CPU の速度が低下します。多くのエージェントレス バックアップ製品では、同時 VM バックアップの数を調整できます。通常、同時バックアップの最大数は 10 ～ 15 です (最大数の制限も仮想化プラットフォーム自体によって制限されており、バックアップ ソフトウェアとは関係ありません)。ただし、実際のシナリオでは、仮想化プラットフォームへの負荷圧力が大幅に増加するため、*** 同時実行を有効にすることは推奨されません。同時バックアップの最も適切な数は、実際の仮想マシンの数とプラットフォームのパフォーマンスに基づいて決定する必要があります。

5. エージェントレス バックアップは、ツール (VMware Tools、Hyper-v システム統合ツール、KVM の virt-tools など) に大きく依存します。 VM ツールが正常に実行できない場合、または時間内に更新されない場合、エージェントレス バックアップで CBT/RCT ブロック トラッキングまたはスナップショット例外が使用できず、VM がサイレント状態にならない可能性があります。

6. エージェントレス バックアップでは通常、仮想マシンが配置されているストレージ ボリュームに少なくとも 25% の空き領域が必要です。ストレージ容量が不足している場合、エージェントレス バックアップ スナップショットによってストレージ ボリューム アラームが発生したり、仮想マシンのスナップショットが失敗したりします。

7. 仮想マシンが配置されているストレージ ボリュームが失われたり非アクティブになったりすると、エージェントレス バックアップは失敗します。

3. プロキシバックアップの分析

エージェントは、特定の機能を実行するためにサーバーにインストールされる小さなアプリケーションです。一般的な例としては、バックアップ アプリケーションがサーバーにインストールしてサーバーをバックアップし、そのサーバー上で実行されているアプリケーションに特定のサービスを提供するクライアントが挙げられます。仮想化が普及して以来、エージェントベースのバックアップは仮想化ユーザーの間で人気がありませんでした。理由は次のとおりです。

1. 展開方法が複雑で、バックアップする仮想マシンにクライアント エージェントをインストールする必要があります。これは、多数の仮想マシンを持つユーザーにとって致命的な問題です。

2. ソフトウェアの互換性の問題: エージェントを使用して VM にインストールする場合、通常は最初に環境チェックを実行して、バックアップ ソフトウェア (ウイルス対策、システム互換性、特別なセキュリティ アプリケーションなど) との非互換性を排除する必要があります。

3. バックアップ対象の VM がクラスター内の少数のホストに集中している場合、同時バックアップ中にホストのリソース負荷が増加し、ビジネス仮想ネットワークに影響を及ぼします。

4. 一部のバックアップ ソフトウェアには、物理​​デバイスのディスク ブロック追跡機能がありません。エージェント バックアップがある場合は、ファイル レベルのバックアップが使用され、増分\差分バックアップによって VM の負荷が増加します。同時に、バックアップ速度は遅くなります。

5. エージェントなしで維持するよりも、エージェントありで維持する方が困難です。たとえば、電源がオフになっている VM はバックアップできません。また、一部の VM ではセキュリティ上の理由から一部のポートのみが開かれているため、エージェント プログラムが接続したりデータを送信したりできなくなります。

プロキシ バックアップは仮想化環境では明らかな欠点がありますが、多くの利点もあります。

1. VM をバックアップする場合、仮想化プラットフォームのスナップショットに依存せず、ゲスト OS システム上のシステム スナップショット (システム vss または LVM スナップショットなど) を直接呼び出します。これにより、I/O が多くデータ量が多い VM や、マルチディスク構造の VM のバックアップの安定性が向上します。

2. VM のバックアップ時にアプリケーションを認識し、Exchange、SQL サーバー、AD、Oracle、SharePoint、ファイルなどのきめ細かいリカバリをサポートします。

3. 物理デバイスのブロック追跡をサポートするバックアップ ソフトウェアの場合、バックアップと復元の速度の点では、エージェントベースのバックアップの方がエージェントレス バックアップよりも高速です。

4. データベース サービスを使用して仮想マシンをバックアップする場合、データベース バックアップ スクリプトを構成して呼び出すことができます。これにより、データベースを個別にバックアップできるだけでなく、データベースのデータ整合性も確保できます。

5. プロキシ バックアップは、仮想化プラットフォーム上の同時バックアップの数によって制限されません。ネットワークが耐えられる限り、同時 VM バックアップの数に上限はありません。

6. サポートされている仮想化プラットフォームは幅広く、プロキシ バックアップ方式はほぼすべての仮想化プラットフォームをサポートできます。ソフトウェアライセンスが許可している場合は、基本的に仮想化メーカーによる制限はありません。

4. 仮想化バックアップの実践経験

プロジェクトでの私自身の実装経験に基づくと、大規模な仮想マシンのバックアップには次のバックアップ手順を使用できます (VMware 仮想化を例に挙げます)。

1. 現在の仮想化プラットフォーム内のすべての仮想マシン情報を EXCEL フォームに抽出し、大容量データ (TB を超える)、マルチディスク構造、RDM、コア データベース タイプ (高 I/O)、失われたストレージ ボリューム (または非アクティブなストレージ ボリューム) を持つ VM を除外します。エージェントレス バックアップが使用できない VM には、エージェント バックアップがインストールされます。

2. 上記以外の仮想マシンはエージェントレスでバックアップできます。

3. 仮想マシン（特に Windows システム仮想マシン）のエージェントレス バックアップを使用する場合は、VMware Tools が正しくインストールされ、すべての VMware Tools システム サービスが正常に実行されていることを確認します。 VMware Tools を更新する必要がある、または実行できないというプロンプトが表示された場合は、VMware Tools を適時に更新するか、アンインストールして再インストールする必要があります。

4. バックアップ ネットワーク アーキテクチャを計画し、環境要件が LAN-BASE\LAN-FREE\SERVER-FREE などの構成要件を満たしているかどうかを確認します。

1) 従来の LAN-BASE アーキテクチャでは、エージェントレス仮想化バックアップ ネットワークは少なくともギガビット ネットワーク標準を満たしている必要があります (10 ギガビット ネットワークが推奨されます)。 ***実用的な推奨事項: 各 ESXI ホストに少なくとも 1 つの追加の物理ネットワーク ポートを用意し、その物理ネットワーク ポートをバックアップ専用の仮想ネットワークに割り当てます。バックアップ データは、各 ESXi ホストの専用ネットワーク ポートを介してバックアップ転送ネットワークを通過します。このポートはビジネス ネットワークから分離されており、バックアップ中に大量のデータ転送がビジネス ネットワークに与える影響を回避します。バックアップ ストレージ サーバーの場合は、マルチ NIC バインディングの使用を検討できます。同時に、スイッチがサポートしている場合は、バックアップ ストレージ サーバーに接続されたスイッチ ポートでマルチリンク アグリゲーションを使用して、バックアップ ストレージ サーバーの帯域幅を増やすことができます。 *** 実践要件を満たすことができない場合は、バックアップ データ フローを、仮想ネットワーク内の負荷圧力が低い非コア ビジネス ネットワーク セグメント経由でルーティングすることをお勧めします。

2) LAN-FREE アーキテクチャでは、実装前の環境チェックに特に注意を払う必要があります。主に VMFS ボリューム構造とストレージ状態、マルチパス マッピング、ストレージ LUN 構造などをチェックします。仮想化ストレージに複合ボリューム (複数のストレージ LUN で構成される VMFS ボリューム) が見つかった場合、VMware 自体はこのボリュームの LAN-FREE バックアップをサポートしていないため、LAN-BASE のみを使用できます。さらに、LAN-FREE アーキテクチャのバックアップには実稼働ストレージのマッピングが含まれており、実装には一定のリスクが伴います。適切に行われなければ、結果は深刻なものとなるでしょう。

3) サーバーフリー アーキテクチャでは通常、ストレージ デバイスとバックアップ ソフトウェア間の互換性が必要です。バックアップ製品によってサポートされるストレージ デバイスが異なるため、実際のプロジェクトではこの方法はほとんど使用されません。

5. 仮想マシンのバックアップには、別のバックアップ ストレージ サーバーまたはバックアップ ストレージ デバイスが必要ですが、貴重な運用ストレージ領域を占有してはなりません。同時に、セキュリティ上の理由から、バックアップ データを本番データと同じストレージに配置すると、ストレージに障害が発生すると、復旧に使用できるバックアップ データがなくなります。バックアップ データは、運用データとは別に保存する必要があります。

6. バックアップ時間枠の計画。どのバックアップ製品も、バックアップ中にフロントエンド アプリケーションにさまざまな程度のビジネス インパクトを与えます。したがって、バックアップ プロジェクトを実装するときは、必ずバックアップの時間枠を予約してください。バックアップ時間枠は通常、業務量が少ない期間に予約されます。バックアップに必要な時間は、バックアップデータの合計サイズと転送速度に基づいて概算できます。仮想化プラットフォームには多数の仮想マシンが存在するため、業務の種類に応じて仮想マシン グループに分割し、仮想マシン グループごとに異なるバックアップ ウィンドウを予約することをお勧めします。

7. 仮想マシンのバックアップ サイクルは、データを回復できる時点に直接影響します。そのため、異なる業務ごとに仮想マシンをグループ化し、RPO/RTO 要件に応じて異なるバックアップ サイクルを策定する必要があります。

8. 重複排除を使用するかどうか。データ重複排除を使用するかどうかの決定は、仮想化されたストレージ データの量、バックアップ ストレージに必要なスペース、およびバックアップの時間枠に基づいて行う必要があります。バックアップする仮想マシンの数が多く、データ量が多く、バックアップに必要なストレージ容量が不足し、バックアップウィンドウが短い場合は、重複排除を使用するのが最適なソリューションです。ただし、データ重複排除には、バックアップ ストレージ サーバーのハードウェア パフォーマンスに関する一定の要件があります。したがって、バックアップ製品メーカーの要件に従って重複排除サーバーを構成することをお勧めします。さらに、重複排除には一定のリスクが伴います。重複排除データベースが破損すると、すべてのバックアップを復元できなくなります。重複排除が有効になっているバックアップ データの場合は、バックアップの 3-2-1 原則を可能な限り満たすために、2 番目のコピーを作成することをお勧めします。 ***、各バックアップ メーカーには重複排除に関する独自のベスト プラクティスがありますが、基本的な考え方は同じです。一般的に、仮想化プラットフォーム内のいくつかの一般的な仮想マシンが最初にバックアップされ、次にバッチ バックアップが実行されて、最高の重複排除効果が得られます。

9. 仮想マシンのエージェントレス バックアップには同時実行制限はありません。通常、バックアップ プランでは、VMware のデフォルトに従って 2 つの仮想マシンを同時にバックアップすることが推奨されます。同時リクエストの数は、仮想化プラットフォームのパフォーマンスとネットワーク帯域幅の使用状況を総合的に考慮して調整できます。ただし、同時実行数を過度に調整したり、最大同時実行を有効にしたりしないことをお勧めします。そうしないと、仮想化プラットフォームに大きな負荷がかかり、通信の問題が発生したり、仮想マシンのビジネスが失敗したり、バックアップが失敗したりする可能性があります。

10. ビジネスに基づいてバックアップ プランを作成し、バックアップ プラン間に一定の時間間隔を確保します。多数の仮想マシンが同時に同じ期間にバックアップのために起動され、ネットワークと CPU 負荷に大きな変動が生じる状況を回避します。

11. さまざまなビジネス タイプに基づいてバックアップの保持期間を決定します。時間的制約のあるビジネスの場合、バックアップを 1 ～ 2 週間保持することをお勧めします。アーカイブする必要がある仮想マシンの保持期間は 3 か月以上に設定することをお勧めします。保持期間はバックアップ ストレージの使用率と密接に関連しているため、さまざまな仮想マシン グループのデータ保持期間は慎重に計画する必要があります。

12. エージェント バックアップを備えた Windows VM を使用する場合、展開を容易にするために、リモート プッシュを使用してバックアップ エージェントをインストールできます。プッシュ条件が満たされない場合は、ローカル インストールが使用されます。エージェントをプッシュまたはローカルにインストールする前に、パッチ、互換性、ネットワーク、構成などのインストール環境を必ず確認してください。

13. 仮想化バックアップ計画を実装した後、1 ～ 2 週間にわたって毎日のバックアップの状態とビジネスへの影響を注意深く観察します。バックアップの異常や通常業務への影響が見つかった場合は、適時にバックアップ戦略を調整し、バックアップが安定するまでバックアップ計画を継続的に最適化します。

V. 結論

仮想化バックアップ プロジェクトは単純に思えるかもしれませんが、仮想マシンの数、ストレージ アーキテクチャ、ネットワーク アーキテクチャ、バックアップ プラン サイクルなど、複数の側面からバックアップ プランを考慮する必要があります。仮想化プラットフォームの実際の状況に基づいて実装プロセスを決定し、バックアップ戦略を継続的に最適化する必要があります。