仮想化バックアップをすぐに理解できるようにします

1. 概要

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

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

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

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

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

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

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

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

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

現在、仮想化プラットフォームのバックアップには 2 つの主流のバックアップ ソリューションがあり、1 つはエージェントレス バックアップ (エージェントレス)、もう 1 つはエージェント バックアップ (エージェント)、またはゲスト OS レベルのバックアップと呼ばれます。この記事では、エージェントレス バックアップとエージェント ベースのバックアップの長所と短所を分析および比較することにより、仮想化バックアップのベスト プラクティスをまとめます。

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

エージェントレス バックアップは、通常、仮想マシンにバックアップ エージェント (またはクライアント、プローブ) をインストールする必要がなく、キャプチャに 1 つまたは複数のプロキシ VM (バックアップ プロキシ アプリケーション) を使用することを意味します。バックアップ VM。

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

1. 導入とインストールが簡単です。各仮想マシンにバックアップ エージェントをインストールする必要はなく、ハイパーバイザー統合を構成するだけで完全に自動で導入できます。

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

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

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

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

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

しかし、実際の運用ではエージェントレスバックアップには多くの問題があり、次のような欠点が見られます。アプリケーション対応のきめ細かいデータ リカバリと RDM (RAW ディスク マッピング) 仮想マシン バックアップを実現します。

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

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

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

5. エージェントレス バックアップはツール ツール (VMware ツール、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 をバックアップする場合、仮想化プラットフォームのスナップショットに依存せず、システム スナップショット (システム vss) を直接呼び出します。ゲスト OS システム上の LVM スナップショットなど) を使用する場合、I/O が高くデータ量が多い VM やマルチディスク構造の VM のバックアップの安定性が向上します。

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

3. 物理デバイスのブロック追跡をサポートするバックアップ ソフトウェアの場合、エージェント バックアップはエージェントレス バックアップよりも高速なバックアップおよびリカバリ速度を実現します。

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

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

6. 幅広い仮想化プラットフォームをサポートします。プロキシ バックアップ方法は、ソフトウェアの認証が許可されていれば、基本的に仮想化プラットフォームの制限を受けません。

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

プロジェクトでの私の実装経験の一部に基づいて、次のバックアップ手順を大規模な仮想マシンのバックアップに使用できます (VMware 仮想化を例にします)。仮想化プラットフォームからすべての仮想マシン情報を EXCEL 形式に抽出し、大量のデータ (TB 以上)、マルチディスク構造、RDM、コア データベース タイプ (高 I/O)、ドロップされたストレージ ボリューム (またはストレージ ボリューム) を追加します。ではありません すべてのアクティブな VM がフィルターで除外されます。エージェントレス バックアップが使用できない VM には、エージェント バックアップがインストールされます。

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

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

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

1) 従来の LAN-BASE アーキテクチャでは、エージェントレス仮想化バックアップ ネットワークは少なくともギガビット ネットワーク標準を満たしている必要があります (10 ギガビット ネットワークを推奨)。ベスト プラクティスでは、各 ESXI ホスト上に少なくとも 1 つの物理ネットワーク ポートを残し、その物理ネットワーク ポートをバックアップ専用仮想ネットワークに割り当てる必要があり、バックアップ データは、ESXI ホスト上の専用ネットワーク ポートを介してバックアップ転送ネットワークを介して送信される必要があります。各 ESXI ホストがビジネスと通信できるようにすることで、バックアップ中に大規模なデータ転送がビジネス ネットワークに与える影響を防ぎます。バックアップ ストレージ サーバーについては、複数のネットワーク カード バインディングの使用を検討してください。スイッチがサポートしている場合は、バックアップ ストレージ サーバーに接続されているスイッチ ポートでマルチリンク アグリゲーションを使用して、バックアップ ストレージ サーバーの帯域幅を増やすことができます。ベスト プラクティスの要件を満たせない場合は、仮想ネットワーク内の負荷圧力が低い非コア ビジネス ネットワーク セグメントからバックアップ データを流すことをお勧めします。

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 を使用する場合、展開の便宜のために、リモート プッシュ方式を使用してバックアップ エージェントをインストールできます。プッシュ条件が満たされない場合は、ローカル インストールが使用されます。エージェントをローカルにプッシュまたはインストールする前に、インストール環境のチェックに注意を払う必要があります。パッチ、互換性、ネットワーク、構成などの側面から 1 つずつチェックできます。

13. 仮想化バックアップ計画の導入後、1 ～ 2 週間毎日のバックアップ状況とビジネスへの影響を注意深く観察する必要があります。バックアップが異常であるか、通常のビジネスに影響を与える場合は、バックアップ戦略を調整する必要があります。バックアップ計画は、バックアップが安定するまで継続的に最適化する必要があります。

5.まとめ

仮想化バックアッププロジェクトは単純そうに見えますが、仮想マシンの数、ストレージアーキテクチャ、ネットワークアーキテクチャ、バックアップ計画サイクルなどからバックアップ計画を検討し、仮想化プラットフォームの実態に基づいて実装プロセスを決定し、バックアップ戦略を継続的に最適化します。