NetApp Tech OnTap
     

ラウンドテーブル・ディスカッション:VMware SRMとNetAppを
使用したMicrosoftアプリケーションのディザスタ・リカバリ

Tech OnTap:Microsoftアプリケーション環境では、オンラインのディザスタ・リカバリを幅広く採用することに躊躇する傾向が見受けられますが、これにはどのような原因があると思われますか?

Wen Yu氏(VMware):VMwareでは、大半の企業がDRの採用を躊躇している理由は主に次の3つであると考えています。第1に、おそらく一番大きな理由と思われるのが、DRの実行にかかるコストです。単に別の施設を用意すればDRを実行できる、というわけではありませんから。多くのサーバ、ネットワーク・インフラが追加で必要になりますし、ストレージも2倍必要になります。使用しているのが物理サーバであっても、仮想サーバであっても、非常に高額なコストがかかってしまいます。

第2に、DRの実行には、従来かなり複雑な作業が伴っていました。物理サーバ環境の場合は特に複雑です。さらに、複数のアプリケーションにDRを実装しようとすると、複雑性は一層深刻になります。ディザスタ・リカバリを完了するために、製品やテクノロジを複雑に組み合わせなければならないこともあります。また、多くの製品では、両方のサイトの構成がほぼ同じでなければならないため、コストがさらにかさみます。

最後に、3つ目の理由ですが、妥当なRPOを達成するためには、相応のネットワーク帯域幅が必要となるため、それが採用の妨げになっているケースも多いようです。Windows®を採用している多くの企業が、複製の実行に必要な帯域幅を用意できず、帯域幅への投資をためらっているのではないかと思います。

しかし、NetApp、Cisco、VMwareの共同ソリューションを使用すれば、こうした問題の多くが解決できます。

Larry Touchette(NetApp):Wenが最後に触れた点について詳しく説明させていただきます。NetAppとVMwareは、DRのコストと複雑さを大幅に削減します。つまり、はるかに多くのアプリケーションを保護できるだけでなく、VMware環境全体をも保護できるソリューションが導入できるということです。NetAppとVMwareの共通のお客様の中には、プライマリVMwareストレージでNetAppの重複排除を使用し、削減できたコストでDR環境用ストレージの購入代金を補うことができたお客様や、さらには購入資金全額分に相当するコストを削減されたお客様もいらっしゃいます。Tech OnTapをかなり頻繁に読まれている方なら、VMwareとNetAppの重複排除の組み合わせがもたらすメリットはよくご存じだと思います。こちらの記事(英語)を手始めにご参照ください。VMwareのDRと重複排除についてご理解いただけます。—TOT編集部]

帯域幅の節約に関して言えば、NetApp SnapMirror® テクノロジをNetAppの重複排除と組み合わせて使用すると、重複しないブロックのみが複製されるため、帯域幅の使用効率が非常に高くなります。最近NetAppは、WANでの通信時間を短縮するためにData ONTAP®にSnapMirrorの圧縮機能を追加しました。そのため、帯域幅が限られている環境でのパフォーマンスが向上し、データの圧縮率にもよりますが、帯域幅の使用率を最大で70%削減できるようになりました。[SnapMirrorの圧縮機能については、最近のTech OnTapの記事(英語)で詳細を紹介しています。—TOT編集部]

TOT:VMware/NetAppのDR構成向けに、VMware Site Recovery Manager(SRM)を推奨する理由は何でしょうか?

Yu氏:仮想アプリケーション・サーバのDRで最も難しく重要なのは、DRサイトに接続し、インベントリを確認し、サイトを再構成し、仮想マシンを起動する段階です。こうしたタスクを手動で実行するのは複雑で、ミスが発生しやすくなります。さらに、特定のVMを起動するために別のVMを起動しなければならない、というような依存関係がある場合はなおさらです。スクリプトを作成してDRプロセスを自動化するという問題解決の方法もありますが、実装にコストがかかることが多く、メンテナンスも困難です。

Site Recovery Managerは、検出と構成、フェイルオーバー、DRテストなど、DRプロセス全体の管理を簡易化します。SRM構成の設定を行う段階でリカバリ計画を作成すれば、DR計画全体をあらかじめ設定しておくことができます。また、組み込みの検出機能や、vCenterとの緊密な統合により、DR処理の所要時間を短縮できます。

DR計画さえ作成してしまえば、後はDR処理を自動的に実行でき、ユーザは最小限の操作を行うだけで済みます。SRMによって必要な手順をすべて実行でき、仮想マシンを正しい順序で起動することができます。たとえば、Active Directory®(AD)サーバやDNSサーバなどのインフラをサポートしている仮想マシンを最初に起動したあとで、データベース・サーバ、アプリケーション・サーバをサポートする仮想マシン、そのあとでWebサーバをサポートする仮想マシンを起動する、といったことが可能です。

SRMのもう1つの大きなメリットは、テストの実行機能です。ほとんどのDRソリューションでは、日々の業務の運用や継続的な複製処理を中断せずにテストを実行することはほぼ不可能ですが、SRMとNetAppを組み合わせて使用すれば、DRテストを簡単に効率よく実行できます。たとえば、DRテストを行うために必要なのは、分離されたテスト・ネットワークを作成することだけです(社内ネットワークの各VMでアクティブなインスタンスが誤って2つ存在することを防ぐため)。後は、SRMによってプロセスを自動化し、分離された環境でテストを行うことができます。

Larry:NetApp FlexClone®テクノロジをSRMのDRテストと組み合わせて使用すると、DRサイトを立ち上げてテストを実行するために大量のストレージを追加で使用する必要はなく、サイト間で継続的に行っている複製やプライマリ・サイトの運用を停止する必要もありません。このため、業務サイトや契約済みのSLAに影響を与えることなく、テストを簡単に実行してDRを検証できます。複製ソリューションの中には、DRサイトにストレージ複製用の容量を2倍用意しなければならないものもあります。これは、テストの実行中に複製を継続させるためなのですが、この方法では、多くの時間が無駄になるうえ、テスト環境を利用できる時間が短くなったり、テストの実行頻度を減らす必要が出じたりします。FlexCloneを使用すると、必要なストレージ容量が大幅に削減され、テストにかかる時間が短縮されます。

図1)DRテストによるストレージ使用量の増加(FlexCloneの場合)

TOT:VMware SRMとNetAppストレージを使用してDRソリューションを導入する場合、主にどういったことを考慮したらいいでしょうか?

Yu氏:SRMの観点から、いくつかの考慮事項が挙げられます。まず、各サイトに、VMware vCenterサーバ1台、SRMデータ・ベースを格納するためのMicrosoft SQL Server1台、サポートされているバージョンのESXを実行するサーバが必要となります。

プライマリ・サイトとリカバリ・サイトは信頼性の高いIPネットワークで接続されていなければなりません。また、リカバリ・サイトからは、プライマリ・サイトと同じパブリック/プライベート・ネットワークにアクセスできる必要があります。それから、最後に大切なことを1つ。リカバリ・サイトには最新のActive DirectoryサーバとDNSサーバが必要です。

実際にサイト間で複製を実行する際、SRMはストレージに依存します。この場合はNetAppストレージに依存することになりますね。階層1のアプリケーションを実行している場合は、同期複製するようにSnapMirrorを設定すると、RPOゼロを達成できます。複製だけでなく、OSレベルとアプリケーション・レベルの両方で整合性を保つことが鍵となります。

Larry:NetAppは、VM自体とMicrosoftアプリケーション(Exchange、SQL Server、SharePoint Server)の両方を整合性を保って複製するために、いくつかのコンポーネントを使用しています。VMとアプリケーションの両方に言えることですが、データを定期的に複製するだけでは不十分です。アプリケーションとの整合性がとれた状態を維持し、その状態から各コンポーネントを再開できることが重要です。アプローチの全容については、 最近のテクニカル・レポートで詳しく説明しています。このテクニカル・レポートは、Wenにも目を通してもらっているので、記載されているVMware関連情報の正確性は確認済みです。

VMは、VMFS(FC/iSCSI LUN)またはNFS共有データストアに実装されます。NetApp SnapManager for Virtual Infrastructureでは、整合性のとれたVMデータのSnapshot™コピーおよび複製を作成できます。

設計の鍵となるのは、アプリケーション・データをVMデータストアから分離することです。これは、アプリケーション・データを物理モードのRDM LUN(iSCSIまたはFC)に格納することによって実現します。こうすると、一連のNetApp SnapManager製品を使用して、アプリケーションごとに整合性のあるリカバリ・ポイントを作成できます。また、アプリケーションごとに異なる複製スケジュールを設定し、さまざまな数のリカバリ・ポイントを作成することで、異なるRPOに対応できます。

複製アーキテクチャ

図2)複製アーキテクチャ

TOT:アプリケーションを再開するリカバリ・ポイントを多数設定できるよう、NetAppは尽力してきました。その点について読者にもう少し詳しく説明していただけますか?

Larry:NetAppのSQL Server、Exchange、SharePoint向けSnapManager製品では、多数のリカバリ・ポイントを作成し、リカバリ・サイトに複製したリカバリ・ポイントを検証できるため、柔軟性が向上します。SnapManagerアプリケーションはフル・バックアップを作成し、フル・バックアップのアプリケーションとの整合性を検証します。加えて、フル・バックアップの間に発生した変更の差分ログのみを頻繁にバックアップします。こうした差分バックアップは、Frequent Recovery Point(FRP;短周期リカバリ・ポイント)バックアップと呼ばれます。FRPバックアップの間隔を調整することで、希望するRPOをアプリケーションごとに柔軟に設定できます。

リカバリ・サイトでリカバリされたアプリケーション・データに問題が検出された場合は、個々のアプリケーションを過去の任意の時点のリカバリ・ポイントにリバートできます。SnapManagerは、アプリケーションが前のリカバリ・ポイントにリバートされた場合、コミットされていないデータベース・ログをロール・フォワードできるため、リカバリ・サイトでフェイルオーバー後に書き込まれた新しいデータが失われません。

SRMでは、リカバリ・プロセスにカスタム・コマンドを取り入れることができます。NetAppでは、この機能を使用してリカバリ・プロセス内でコマンドを実行し、業務サイトから複製されたバックアップの全履歴をDRサイトで稼働しているVMから参照できるようにSnapDrive®を設定しています。NetApp NOW™(NetApp on the Web)サイトへのアクセスが可能なお客様は、KB56952(英語)でこのプロセスの詳細をご覧いただけます。

TOT:SRM環境でのActive Directoryの重要性について、お2人のどちらか、お話しいただけますか?

Yu氏:Microsoftのアプリケーションが正しく動作するためには、Active DirectoryとDNSが欠かせません。そのため、リカバリ・サイトでActive DirectoryとDNSが正しく構成されていることが本当に重要です。また、DRテストを実行する際には、分離されたテスト・ネットワーク上に、正しく構成された最新のActive Directoryサーバを必ず用意する必要があります。リカバリ・サイトからプライマリ・サイトへフェイルバックする際にも、Active Directory/DNSサーバを必ず適切に処理する必要があります。適切に処理しないと、Update Sequence Number(USN;更新シーケンス番号)のロールバックに問題が発生したり、Active Directoryデータベースが破損する場合があります。この問題は、Microsoft技術情報記事875495(英語)で詳しく説明されています。

リカバリ・サイトで適切なActive Directoryを確実に使用する最も簡単な方法は、プライマリ・サイトと同期されるリカバリ・サイトに少なくとも1台のActive Directoryサーバを維持することです。

DRテストの場合は、DRテストを実行する直前にこのADサーバをクローニングする必要があります。クローニングが完了したら、VMに電源を入れる前に、クローニングされたADサーバがDRテスト・ネットワークのみに接続されていることを確認します。テスト・ネットワーク内でAD VMに電源を入れたら、Active Directoryフォレスト内の5つのFSMO(Flexible Single Master Operation)の役割をMicrosoft技術情報記事255504(英語)に説明されている手順に従って強制的に転送します。

実際にフェイルオーバーが発生した際には、このクローニング・プロセスを実行する必要はありませんが、FSMO役割の強制転送は、必ず手動で実行する必要があります。災害から復旧したら、発生した災害の内容に関係なく、フェイルバックを行う前に元のサイトでActive Directoryサービスを再構築しなければなりません。Active Directoryサービスを再構築するには、元のサイトでADサーバをリカバリし、リカバリ・サイトの新しいADサーバと再同期させるか、または新しいADサーバを構築します。

上記の処理の詳細については、Larryがすでに触れたNetApp TR-3822で大きく取り上げられています。

TOT:ディスカッションの締めくくりに、元のサイトにフェイルバックする際の有効な方法を、お2人にお話しいただきましょう。

Yu氏:今ご説明したように、元のサイトが稼働したら、まず最初にActive Directoryを稼働させます。SRMにはまだ、完全に自動化された復旧機能やフェイルバック機能が備わっていないのですが、それでも、SRMを使用してフェイルバックを実行することを推奨します。つまり、逆方向にフェイルするようソフトウェアを再設定するという方法を取ります。

Larry:フェイルバックするには、リカバリ・サイトと元のサイト間でデータを同期させる必要があります。SnapMirror関係は、簡単に復旧し、再同期することができます。再同期プロセスは、どのような障害が発生したかによってある程度異なります。災害で元のストレージが破損しなかった場合、SnapMirrorは差分、つまり元のサイトがオフラインの間に発生した変更のみを複製します。それ以外の場合は、完全な再同期が必要です。もちろん、いずれの場合も、NetAppの重複排除とSnapMirrorの圧縮機能によって、WANへの影響を軽減できます。重複排除機能は、同じゲスト・オペレーティング・システムのコピーが大量にあるために生じる重複を排除し、VMware環境内のデータ量を総合的に削減します。また、圧縮機能は、WAN上で転送されるすべてのデータの帯域幅使用量を最小限に抑えます。

以上、ラウンドテーブル・ディスカッションの内容をまとめてご紹介しましたが、お役に立てば幸いです。また、この記事についてのご意見をぜひお聞かせください。ディスカッションで取り上げたトピックの詳細については、TR-3822をご覧ください。


Wen Yu

Wen Yu
シニア・テクニカル・アライアンス・マネージャー、
VMware

Yu氏は5年以上にわたってVMwareに勤務し、継続的な可用性、ディザスタ・リカバリ、デスクトップ仮想化を実現する仮想化製品のサポートと普及に取り組んでいます。現在は、インフラ・アライアンス・テクノロジ・チームの一員です。

Larry Touchette

Larry Touchette
テクニカル・マーケティング・エンジニア
NetApp

Larryは、NetAppに9年間勤続。NetAppのストレージとディザスタ・リカバリ・ソリューションのサポート、導入、設計に携わっています。現在、NetAppのサーバ仮想化テクニカル・マーケティング・チームの一員です。

 
関連情報
 
TRUSTe
お問い合わせ  |  購入方法  |  フィードバック  |  採用情報  |  登録  |  プライバシーポリシー  |  © 2010 NetApp