NetApp Tech OnTap
VMware Site Recovery Managerによるシンプルな災害復旧の対策

災害発生後にサイト全体を復旧しなければならない事態に陥ることほど、恐ろしいものはありません。環境に仮想インフラを導入している場合、状況がさらに複雑化する可能性があります。VMware® Site Recovery Manager(SRM)は、VMwareインフラの災害復旧(DR)を迅速かつ容易に行えるように設計されたツールです。このツールには、サイトのDRプランが有効かどうかを事前に確認できる、無停止型のテスト機能も含まれています。

SRMは、仮想マシン(VM)およびサーバへの仮想インフラフェイルオーバーを自動的に実行します。VMデータのDRサイトへの移動については、独自のデータレプリケーションメカニズムを提供するのではなく、ストレージベンダーが提供する既存のレプリケーション機能(NetApp® SnapMirror®テクノロジなど)を使用します。NetAppはVMwareと密接に協力し、SnapMirrorなど、NetAppテクノロジの高度な機能をSRMで最大限に活用できるようにしています。

この記事では、DRプランの問題点について説明したあと、NetAppストレージ機能を統合したVMware SRMを使用して、仮想インフラにおける災害復旧を大幅に簡易化する方法について説明します。

DRプランニング

DRシナリオで最も重要な部分は、プランニングおよび実行です。データ可用性に影響を及ぼしかねない災害には、自然災害、人的災害、コンピュータ障害など、さまざまな種類があります。今日のDRプランニングに最も多く見られる問題は、次のとおりです。

プラン自体が存在しない。:企業によってはリソースと予算があまりにも限られているために、DRの複雑性とコストに対処しきれない場合があります。計画停止を行う時間的な余裕もないため、実際のDRプランを作成したり(さらに重要な点として)テストしたりするプロセスが慢性的に後回しになっています。

Recovery Point Objective(RPO;目標復旧時点)およびRecovery Time Objective(RTO;目標復旧時間)を達成できない。:
高額なインフラ、長時間に及ぶリストア、まったくゼロからのシステムインストールが必要なプランを採用しているために、業務で要求されるRPOおよびRTOを達成できない企業が少なくありません。特に、実際の災害を経験したことがない企業は、膨大なリソースを必要とするテストプランの実装や実行に消極的です。

管理とRPO/RTOの関係。:
災害復旧のために実働環境をフェイルオーバーする場合、長時間かけて多数の手順を手動で実行しなければなりません。カスタムスクリプトを利用すれば一部のプロセスを簡易化できるとはいえ、このプロセスは、DRソリューションで達成可能な実際のRTOに影響するため、必ず実行しなければなりません。一般的なDRプロセスの流れは、次のとおりです。

  1. DRサイトへのフェイルオーバーを必要とする状況が発生します(停電が長引き、フェイルオーバーを実行しなければ業務の中断期間が許容限度を超えてしまう場合や、実働サイトでデータの損失や機器の損傷を引き起こす災害が発生した場合など)。
  2. DRチームが所定の手順を実行して災害を確認し、フェイルオーバーの実行を決定します。
  3. データのレプリケーションが成功し、DRサイトが使用可能な状態であるかを確認するためのテストが実行されます。
    • レプリケーションが行われたストレージをDRサイトのESXシステムに提供する必要があります。
    • これらのシステムをストレージに接続する必要があります。
    • ESXシステムのインベントリに適切なVMを追加する必要があります。
    • DRサイトが実働サイトとは異なるネットワークセグメントに存在する場合、各VMを再設定して新しいネットワークに対応させなければならない場合があります。
    • ネーミング/IPの矛盾を防止するために、一連のシステムとサービスが適正な順序でオンラインになり、環境が正常に起動されたことをITスタッフが確認する必要があります。
  4. DR環境の準備が整うと、DRサイト上の機器による業務の処理が開始されます。最終的に実働サイトが復旧するか、または故障した機器が交換されます。
  5. DRサイトで業務を処理していた期間中にデータに適用された変更を反映させるために、プライマリサイトへのレプリケーションを実行しなければならない場合があります(つまり、逆向きのレプリケーションが必要になります)。
  6. ステップ3のプロセスを再度実行します。
  7. 実働環境が復旧したら、元のレプリケーションのスケジュールおよび関係を(実働サイトからDRサイトへ)再設定する必要があります。

一般的にDRプロセスには長い時間がかかり、人為的なエラーが起こりがちです。プライマリサイトで業務を再開するには、基本的に(同じ問題を含む)プロセスを繰り返す必要があります。それにも関わらず、どの企業でもDRソリューションは一種の保険としてしか認識されていません。ソリューションの信頼性を確保するには、DRプランの定期的なテストが重要です。

このようなテストを行うには、一定のスケジュールに従って上記のステップ1~7を繰り返すのが一般的です。人件費とダウンタイムの両面でコストが高くなるだけでなく、通常のIT運用を中断せざるを得ない場合もあります。物理的な環境の制約とDRテストの実行の難しさから、ほとんどのサイトでは多くても年に2~3回のテストしか実行できません。また、現実に近い形でのテストを行うことがまったく不可能なサイトもあります。SRMを使用すると、DRプロセスを自動化できるため、災害復旧時の人為的エラーの影響を抑えることができます。

SRMの基本

VMware環境におけるDRフェイルオーバーで最も難しく時間がかかるのは、DRサイトに接続し、インベントリを確認し、サイトを再構成し、VMを起動する段階です。VMwareでは、これらの問題を解決するために、DRプロセス全体の管理をシンプルにするSite Recovery Managerを開発しました。
SRMには、次の3つの主要コンポーネントがあります。

  • 検出/構成
  • フェイルオーバー
  • テスト

DRプロセスで最も重要なのは、災害が発生した場合に実行するレスポンスのプランニングです。SRMを使用すると、このようなレスポンスを事前にプログラムできます。これは、このソリューションの最大の利点の1つです。何百台ものサーバの電源を入れたり切ったりするのは困難です。災害が発生したときにはなおさらです。一連のシステムを特定の順序でオンラインにするのはさらに困難です。

SRM構成のセットアップ段階でDRプランを作成しておけば、プラン全体をあらかじめ設定できるようになります。SRMは、組み込み型の検出機能を搭載しているほか、Virtual Centerと密接に統合されているため、このプランの作成を短時間で行うことができます。一度プランを作成しておけば、ユーザの介入をほとんど必要とせずに、滞りなくプランを実行できます(ユーザは災害が発生した時点でDRプロセスを起動するだけです)。このようなプランを従来のDR手法で作成しようとすれば、何か月も(場合によっては何年も)かかるだけでなく、ミスの起こりがちな手動の作業を数多く行うことになります。

SRMの自動テストソリューションを活用すれば、無停止でのDRテストが可能になります。このソリューションでは、複数のVMを起動しデータセットをテストしている間にも(DR用の)レプリケーションを続行でき、SLAにも影響がありません。レプリケーションを実行したデータセットをクローニングし、開発やテストなどに利用することも可能です。

NetAppのクローニングテクノロジを統合したSRMツールを使用してVMを操作すれば、サイトのオンライン化やそのサイト上でのテストを中央ロケーションから容易に実行できます。この際、業務運用への影響はありません。この強力な方法を使用すれば、特定のアプリケーションまたはデータセットを検証するための一連のテストを実行する際に、実働サイトや承認済みのSLAに影響を与えることがなくなります。

SRMとNetAppストレージ

SRMを使用すると、個別のVMware環境間(プライマリサイトとDRサイト)での双方向コミュニケーションが可能になります。プライマリサイトのVMを迅速かつ容易に収集し、プロテクショングループ(リソースを共有し、復旧を同時に行えるグループ)にまとめることができます。これらのプロテクショングループは、DRサイトのリカバリプランに組み込まれます。

NetAppストレージ環境でSnapMirrorを設定すれば、ローカルのNetAppストレージからリモートシステムへVMのレプリケーションを実行し、リモートロケーションに読み取り専用ミラーを作成できるようになります。SnapMirrorの利点は、非常に柔軟なDRサイトのストレージ構成を実現でき、DRストレージのコストを大幅に削減できる点です。多くのレプリケーションソリューションでは、両方のロケーションでストレージ構成がまったく同じでなければなりません。SnapMirrorの場合、両方のサイトでNetAppストレージを使用する必要はありますが、ハイエンド/ローエンドプラットフォーム間、FC/SATAディスク間、およびFibre Channel SAN/iSCSI間でのミラーリングが可能です。

Traffic through network switches

図1)SnapMirrorを単独で、またはSRMとともに使用すると、
ハイエンドのストレージ構成(高性能プラットフォーム、
FCPディスク、FC SAN構成)から、低コストのソリューション
(低コストのストレージプラットフォーム、SATAディスク、iSCSI)
への柔軟なミラーリングが可能になります。

VMware SRMはこのような関係を検出し、事前のプログラミングに基づいて、書き込み可能ミラーへの昇格、ファイルシステムのマウント、システムの起動などのレスポンスを実行します。

NetAppストレージ環境でDRプランを実行する場合、SRMは次のように動作します。

  • NetApp SnapMirror関係を静止させ、中断する
  • LUNを既存のigroupにマッピングする(igroupは、LUNへのアクセス権を持つホストのWWPNテーブル)
  • DRサイトのESXホストをトリガーし、ストレージを再スキャンして検出する
  • DRサイトのネットワーク定義に応じて、VMを再設定する
  • リカバリプランで定義された順序で、一連のVMを起動する

NetApp環境でDRテストを実行する場合、SRMは次のように動作します。

  • DR用のストレージシステムでFlexVol®からFlexClone®ボリュームを作成する
  • これらのFlexVolに含まれるLUNを既存のigroupにマッピングする
  • DRサイトのESXホストをトリガーし、ストレージを再スキャンして検出する
  • VMのネットワークアダプタをTest Bubbleプライベートネットワークに接続する
  • DRサイトのネットワーク定義に応じて、VMを再設定する
  • リカバリプランで定義された順序で、一連のVMを起動する

まとめ

SRMは、VM/ストレージ間のマッピング、適正な起動順序、IPアドレッシング/ネーミング方式の処理など、膨大なリソースの参照や手作業が必要となるDRプランニング、フェイルオーバー、およびテストを自動化することで、仮想化環境における災害復旧を大幅に簡易化します。運用面から見ると、VMの保護に必要な追加コストはほぼゼロであり、実質的に必要となるのは、レプリケーション先のサイトでのディスクスペースと、VMのデータ変更率に応じた帯域幅のコストだけです。管理者が仮想サーバとストレージの統合に煩わされることはほとんどなく、最小限の労力と時間でDRプランとリカバリ手順を作成できます。


Darrin Chapman Darrin Chapman
NetApp、データ保護問題の専門家、テクニカルマーケティングマネージャー

Darrin Chapmanは、災害対策やバックアップおよびリカバリのあらゆる問題について、NetApp社内でも豊富な知識を持つ人物です。Darrinは2002年以降、データ保護を含むNetAppのほぼすべてのベストプラクティスガイドに関与しており、空き時間にはお客様やNetAppの技術スタッフ向けにトレーニングコースを企画しています。Darrinはもともと電気技師としての教育を受け、AT&T、Nortel、およびEMCで数年間、システムアーキテクチャ関連の業務に従事していたことがあります。

関連情報