仮想化と災害復旧の簡単な紹介

基本的な災害復旧は効果的です。しかし、ある程度の不確実性もあり、一部のベンダーは仮想化の普及が災害復旧に与える影響を過剰に報告し、誇張しているところもあります。

サーバー仮想化の登場により、災害復旧 (DR) と事業継続 (BC) の実現が容易になり、あるいは過去のものになったと主張する人もいます。

なぜこのような状況が発生するのかは簡単に理解できます。最近の仮想化管理者に話を聞くと、従来のバックアップとテープを使用するというアイデアや考え方は遠い記憶のように思えます。

仮想化の初期の頃から、高可用性クラスタリングや、ほとんどのデータ保護ニーズを解決すると思われる vMotion などの機能が導入されてきました。

しかし、注意深く調べてみると、これらの発言はいくぶん誇張されていることがわかります。

[[209580]]

災害復旧の定義

定義されたベンチマークを特定できることは常に良いことです。また、これは災害復旧計画においても非常に重要です。読者は、これに関する包括的なガイドを確認できます。災害復旧と事業継続の定義は若干異なります。

• 事業継続とは、ビジネスが継続して運営されることを保証するプロセスを指します。
• 災害復旧とは、災害が発生した後にサービスを復旧するプロセスを指します。ほとんどの場合、企業はこのような状況をできるだけ避けたい、あるいは少なくともその可能性を最小限に抑えたいと考えるでしょう。

現在、災害復旧と事業継続性には 2 つの定義が広く使われています。リカバリ時間目標 (RTO) とリカバリポイント目標 (RPO) はどちらもデータリカバリのサービス レベルを確立します。

• 復旧時間目標は、ビジネスを通常の運用に復旧するための予想時間または目標時間を特定します。 RTO がゼロの場合、サービスは直ちに、または中断することなく復旧する必要があることを意味します。 1 時間の RTO では、アプリケーションを 1 時間以内に通常の使用状態に復元する必要があります。
• 復旧ポイント目標は、サービスを履歴の特定の時点まで復元する必要があることを示します。 RPO がゼロということは、サービスがその履歴時点から開始され、すべてのデータが損失なく回復される必要があることを意味します (銀行アプリケーションでは必須)。 24 時間の RPO は、昨日のデータ (テスト/開発環境で使用可能) のみを復元する必要があることを意味します。

災害復旧計画を策定する

理想的には、すべてのアプリケーションを RTO ゼロおよび RPO ゼロに回復する必要がありますが、実現可能性とコストの観点からこれは不可能です。

代わりに、災害復旧および事業継続計画は、災害シナリオを確立し、その重要性と影響を評価し、各アプリケーションに適用することから始める必要があります。たとえば、失敗のシナリオには次のようなものがあります。

• （火災、停電、洪水、地震）による損失または損害。
• (火災、洪水、危険な災害、化学事故、放射線) により、インフラへのアクセスが失われます。
• （不満を抱いた従業員やサイバー攻撃）犯罪行為や悪意のある危害。
• (ソフトウェア エラー、アップグレードの失敗、データの破損) により、システムまたはアプリケーションの障害が発生します。

各アプリケーション障害の影響を評価し、それに基づいて RTO/RPO サービス レベル目標 (SLO) を決定できます。もう一度、いくつか例を挙げます。

• 電子メール システムのダウンタイムの影響 – 影響は大きい。 RTO = 30 分、RPO = ゼロ。
• コアバンキングアプリケーションのダウンタイムの影響 – 重大な影響。 RTO = ゼロ、RPO = ゼロ。
• 夜間の報告手順におけるダウンタイムの影響 – 影響は低い。 RTO = 4 時間、RPO = 24 時間。

今日の常時稼働の世界では、顧客対応アプリケーションのほとんどは 24 時間 365 日稼働することが求められます。これにより、特定の SLO は削減されますが、フロントエンド アクセスをバックエンド機能から分離することで、アプリケーションの設計を最小限に抑えることができます。

当然のことながら、アプリケーションが仮想化されているかどうか、またそのテクノロジが独立しているかどうかに関係なく、まずビジネス復旧要件を確立する必要があります。実際、従来のビジネス運用モデルでは、IT 部門が標準を押し付けるのではなく、企業のビジネス部門が常に特定のニーズに関するガイダンスを提供する必要があります。

仮想化が災害復旧にどのように役立つか

仮想化は、サーバーの物理リソースをハードディスク、ネットワーク カード、ディスク コントローラーを表す論理構造に抽象化します。プロセッサ、メモリ、ネットワーク ポートは構成ファイル内のパラメーターとして表され、ハード ディスクはローカルまたは共有ストレージ上のファイルとして表されます。

したがって、仮想マシン (VM) のバックアップは、ファイルと構成データのコピーを作成するだけの簡単な作業です。さらに、物理ハードウェアが同一でなくても、仮想マシンを代替ハードウェアに移行できます。これにより、ハードウェア障害の問題をより簡単に管理できるようになります。仮想化機能は、以下の側面で災害復旧と事業継続の問題を解決します。

シンプルなバックアップ/復元

復旧は通常、バックアップを作成し、災害復旧の状況で必要に応じてこれらのバックアップ コピーから復元することに基づいています。このニーズを満たすために、ハイパーバイザーは、VM の内容をコピーしてバックアップを作成できる機能を提供します。データの整合性を確保するために、仮想マシン上で実行されているエージェント ソフトウェアまたはツールは、VM ファイルのコピー中に I/O を停止または一時停止します。

バックアップ ソフトウェアの高度さに応じて、単純なバックアップを使用して、ファイル、アプリケーション、または VM レベルのリカバリを提供できます。仮想マシンのスナップショット全体をバックアップすると、システム スナップショットの保存と仮想スナップショットを組み合わせて、データの整合性を維持しながら処理作業をオフロードできる一部のシステムの機能に影響します。

仮想マシンの移行

厳密にはデータ復旧プロセスではありませんが、物理ハードウェア間で仮想マシンを動的に移行する機能により、ハードウェア障害の影響が軽減されます。 VM の移行自体はサーバーの障害から保護するものではありませんが、サーバーまたは別のコンポーネント (ネットワークなど) でローカル障害が発生した場合に仮想マシンを移行するために使用できます。

VM の移行は、サービスをハードウェアから削除する必要がある場合 (メンテナンスのため)、またはデータ センターの障害のリスクを軽減する場合 (今後の嵐やハリケーンがデータ センターの運用に与える影響など) の制御プロセスとしても使用できます。この意味で、VM の移行は、潜在的または実際のインシデントが発生した場合でもサーバーが引き続き動作することを保証する、ビジネス継続性の維持に似ています。

高可用性/フォールトトレランス

これらは、ハードウェア障害が発生した場合でも仮想マシンの実行を継続できるようにするハイパーバイザーの機能です。 2 つのレベルのサービスが提供されます。高可用性は仮想マシンを監視し、サーバー障害が発生した場合に交換用ハードウェア上で仮想マシンを再起動します。その結果、アプリの再起動に不具合が発生しました。他のシステムでは、代替ハードウェア上でゴースト仮想マシン イメージを実行し、サーバー障害が発生した場合にそのイメージを本番サービスの一部にすることができます。通常、アプリケーションは中断されません。

もちろん、これらの機能を使用するには、共有ストレージ ハードウェア (仮想マシンの構成とデータを保存するため) が必要になる場合があり、これも料金が発生します。一部のベンダーは、高可用性/フォールト トレランス機能と組み合わせてアレイベースのレプリケーションを使用する機能をサポートしています。これにより、ハードウェア構成を短距離 (数百メートル) にわたって拡張し、Metro クラスターを作成できるようになります。メトロ クラスターを使用すると、複雑なアプリケーション クラスターを導入することなく、データ センターの停止や重大なハードウェア障害を軽減できます。

継続的なバックアップ

一部のサードパーティ アプリケーションは、仮想化を使用して仮想マシンの書き込み I/O をインターセプトし、リモート バックアップ イメージを作成します。このプロセスは非同期で実行され、障害発生時に仮想マシンのレプリカを提供します。これを使用して、プライマリ サイトで障害が発生した場合にフェールオーバー レプリケーションを強化できます。このようなシステムを使用するアプリケーションの RPO は、データをオフサイトに移行できる速度によって決まります。

アプリケーションの回復力

前述したように、仮想化は物理的なハードウェア コンポーネントを抽象化することによって利点をもたらします。 DR/BC を実行する際に考慮すべきもう 1 つの点は、アプリケーション自体にリカバリ機能を直接組み込むことです。

アプリケーションの回復力は、アプリケーションのインスタンスを多数実行することによって実現されます。各インスタンスは失敗しても、もちろん代替ハードウェアを使用して再起動できます。この設計は仮想化に直接依存するものではありませんが、複数のハイパーバイザーとハードウェア構成で適切に動作するように実装できます。将来的には、広く採用され始めているアプリケーション仮想化の一形態であるコンテナの使用を通じて、ビジネス継続性/災害復旧の回復力が実現されるようになるでしょう。

RTO や RPO などの災害復旧/事業継続の原則を参照して、アプリケーションのニーズを満たす復旧オプションを適用できます。一部のアプリケーションは完全な HA/FT を取得しますが、他のアプリケーションはハイパーバイザー スナップショットを使用してバックアップされるだけになる場合があります。場合によっては、アレイベースのレプリケーションによる継続的なバックアップや完全な高可用性/フォールト トレランスが適切なこともあります。特定の要件に基づいてテクノロジーを適用することが重要です。