NetApp Tech OnTap NetApp Logo NetApp Logo
NetApp Tech OnTap
     
[特別寄稿]「ネットワンシステムズ様ご提供コンテンツ:FlexPodを使った災害対策のポイントとSnapMirror性能」
シェアする NetAppオフィシャルFacebook

サーバの仮想化という技術が注目を浴び始めてからずいぶん経ちます。最初は部門ごとに徐々に導入されていた仮想基盤は近年では統合された基盤となり、プライベートクラウドやパブリッククラウドという形に進化してきています。これにより仮想化システムの重要度が高くなり、どのような状況でも可能な限りサービスを続けられることが求められるようになってきています。

このような要望に応えるためにネットアップのパートナーであるネットワンシステムズ様では、仮想化基盤の災害対策システムにFlexPod を使って詳細性能試験や障害試験を実施されています。今回は特別に検証結果をご提供いただける運びとなりましたので、検証結果や構成からみる災害対策のポイントについてお届けします。

F5 BigIP + VMware Site Recovery manager

ネットワンシステムズでは大規模な災害が起こった際に、継続してサービスを行うための仕組みについて検証しています。特に3.11の震災後はシステムを管理する方々の危機感が高くなり、多くの相談を頂いています。今回は、よくご相談頂く項目「災害対策のネットワーク設計」と「サイト間のデータ転送」についてご紹介致します。

物理構成

物理構成

上記図は、今回の動作検証を行った際の物理構成です。ネットアップ社のFASおよびシスコシステムズ社のUCS、Nexusを組み合わせたFlexPodをベースに、2つのデータセンターをイメージした仮想環境を構成しています。データセンター間にはWANシミュレータを導入して遅延を発生させることにより、離れた拠点をシミュレートしています。

それぞれのデータセンターには別々にVMware vSphereによる仮想環境を構成し、vCenterにはSRM(Site Recovery Manager)をインストールしています。SRMは災害時におけるサイトの切り替えを簡易化するvCenterのプラグインです。事前に切り替えの設定をしておくことにより、災害時に最小限のオペレーションを実行するだけで簡単に仮想マシンをスタンバイサイトで復旧させることができます。復旧の際は、単純に仮想マシンを起動できるだけでなく、NetApp FASシリーズと連携してストレージの切り替えも自動的に行えることが、大きな特徴となります。

今回は上記構成に加えてF5社のBIG-IP GTM(Global Traffic Manager)を導入しています。BIG-IP GTMはGSLB(Global Server Load Balancing)という機能を実現する製品で、DNSの応答をコントロールすることによりユーザのアクセスを適切なサイトに誘導することを可能にします。また、同じ筐体でローカルのSLB(Server Load Balancing)を行うことが可能なBIG-IP LTM(Local Traffic Manager)も稼働させております。

災害対策システムで考慮すべきポイント

災害対策システムを実際に動作させる場合には3つの大きなポイントがあります。

災害対策システムで考慮するべきポイント

1つ目は、ストレージの設計です。仮想環境における災害対策システムでは、最初に仮想マシンのデータをActiveサイトのストレージからStandbyサイトのストレージへコピーするために、ストレージのレプリケーションを行う必要があります。この時にストレージのレプリケーションパフォーマンスや、データを転送する回線の帯域、遅延により、レプリケーションを完了するまでに掛かる時間が変わってきます。レプリケーションを完了するまでに掛かる時間は、そのままRPO(Recovery Point Objective:災害が発生したときにどれくらい前のデータに戻るか)に直結するため、非常に重要な要素となります。

2つ目は、仮想レイヤの設計です。対象とする仮想マシンの台数や起動順序などにより、RTO(Recovery Time Objective:どれくらいの時間を掛けてシステムが復旧するか)が変わってきます。SRMには、仮想マシン単位で起動の優先度をつけて復旧させる機能があります。重要なシステムの仮想マシンから先に起動させることにより、重要なシステムのRTOをより短くする必要があります。

3つ目は、ネットワーク設計です。仮想マシンが復旧してもユーザからのアクセスが切り替わったサイトへ向かないと、復旧した意味がありません。仮想マシンの復旧に伴い自動的にネットワークが切り替わり、仮想マシンのIPアドレスがそのまま移行されても問題なくアクセスできるようケアした構成にする必要があります。SRMには切り替え時に仮想マシンのIPアドレスを変更する機能がありますが、それはOSのIPアドレスを変更するだけです。アプリケーションに設定されたIPアドレスは、スクリプトを別途作成して実行するなどの対策が必要で、難易度が高くなります。今回ご紹介する災害対策システムでは、IPアドレスの変更は行わずネットワーク側で対応する仕組みを採用しています。

以上3つのポイントを紹介しましたが、この全てを連携させた設計により、初めて災害対策システムは実現されます。

災害対策システムで考慮するべきポイント

災害対策システムの動作 <正常時>

こちらは正常時の災害対策システムの動作について記載した図です。

まず構成のポイントについてご説明します。

  • Active側、Standby側それぞれに1台ずつのFASがあり、SnapMirrorにより仮想マシンのデータを定期的にコピーしています。
  • ESXiサーバはそれぞれのサイトに1台ずつ用意し、正常時にはActive側のサイトにのみ仮想マシンが存在しています。
  • vCenterもデータセンター毎に別々に構成し、SRMの設定情報などがデータセンターをまたいで同期されます。
  • 仮想マシンが接続するネットワークは、どちらも同じネットワークアドレスになっています。これは、仮想マシンのIPアドレスを変更しないで切り替えても引き続きネットワークへアクセスできるようにするためです。
  • 同じネットワークアドレスのままでは外部からのアクセスができなくなるため、外部と接続するセグメントはActive側とStandby側で個別のネットワークとし、外部からはBIG-IP LTMの仮想IPアドレス(VIP)へアクセスし、NAT変換するようにしています。
  • BIG-IP LTMはヘルスチェック機能により仮想マシンの死活監視を行っており、正常時にはActive側のVIPのみアップし、Standby側のVIPはダウンのステータスになっています。
  • BIG-IP GTMはVIPのステータスを把握しており、データセンターをまたいだ2台のBIG-IP GTM間でステータス情報の交換を行っています。
  • ユーザ環境にあるLDNSにはwww.netone.localに対するNSレコードを2つ登録しており、各データセンターにあるBIG-IP GTMで名前解決をする設定になっています。

続いて、この環境でユーザがアクセスを行った時の動作をご説明します。(番号は図中の番号と紐づいています)

クライアントアプリケーションが、DNSの名前解決をするためにLDNSにDNSクエリを送ります。図はwww.netone.localにアクセスしたときの動作になります。
LDNSにはwww.netone.localに対するNSレコードのエントリが2つ登録されています。 この場合、ラウンドロビンで交互にエントリが選択され、選択された方のBIG-IP GTMにDNSクエリが送られます。
BIG-IP GTMはDNSクエリを受け取ると、VIPのステータスのチェックを行います。正常時はActive側のVIPのみアップしているため、Active側のVIP(10.0.100.1)を応答します。ここで、Standby側にクエリが行った場合(③’)でもVIPのステータスを共有できているため、同じようにActive側のVIP(10.0.100.1)を応答します。
クライアントアプリケーションは、DNSの応答に従いActive側のVIP(10.0.100.1)へアクセスし、BIG-IP LTMでNAT変換されて仮想マシンへ到達します。

以上の流れで正常時にはActive側にある仮想マシンへアクセスが行われます。

災害対策システムの動作 <正常時>

災害対策システムの動作 <災害時>

続いて災害時の切り替えとアクセスについてご説明します。(番号は図中の番号と紐づいています)

切り替えは、あらかじめ設定したSRMの切り替えのプランをvCenter上で選択し実行することにより行います。数回クリックをするのみで切り替えを実行できるため非常に簡単で、災害時に仮想環境やサーバ、ストレージのスペシャリストがその場にいなくても、vCenterを操作できるエンジニアがいれば実行することができます。
SRMで切り替えを実行すると、まずレプリケーションで仮想マシンがコピーされてきたボリュームがRead/Writeに変更されます。(この操作はSRMが自動的に実行します)
Read/Writeに変更されたボリュームがサーバにマウントされます。(この操作はSRMが自動的に実行します)
マウントされたボリューム上にあるデータにより仮想マシンを起動。(この操作はSRMが自動的に実行します)
仮想マシンが復旧するとBIG-IP LTMからのヘルスチェックが成功するため、StandbyサイトのVIPがアップします。切り替えは以上で完了です。続いて災害時のユーザアクセスの流れをご説明します。
正常時と同じようにクライアントアプリケーションがLDNSにDNSクエリを送ります。
2つのDNSエントリがありますが、Standby側のBIG-IP GTMへしかアクセスできないためStandby側へ問い合わせが行われます。
BIG-IP GTMはDNSクエリを受け取ると、VIPのステータスのチェックを行います。障害時にはStandby側のVIPのみアップしているため、Standby側のVIP(10.0.200.1)を応答します。

以上のように、vCenter上のSRMで非常に簡単な操作を行うのみでストレージ・仮想環境が切り替わり、さらにユーザアクセスがStandbyサイトで復旧した仮想マシンへ向くように自動的にコントロールされます。

また、災害対策システムにおいては、RPOを決める要因となるストレージのレプリケーション(今回はFASのSnapMirror)のパフォーマンスも重要な要素となります。下の図は、SRMと連携するストレージレプリケーション機能「SnapMirror」と、仮想環境とのバックアップ/リストア連携を可能にするプラグインである「VSC(Virtual Storage Console)」を用いて、動作とデータ転送のパフォーマンスについて検証を行った際の検証環境構成図です。

SnapMirror

仮想環境のバックアップとして、本検証では最近特に導入が盛んな仮想デスクトップ環境を想定しています。仮想環境用のサーバにはシスコシステムズ社のUCS Bシリーズを使用し、仮想環境はヴイエムウェア社のVMware vSphere5.1、仮想デスクトップ製品はVMware Horizon View5.2を使用しています。仮想デスクトップの展開にはLinked CloneとPersistent Diskの機能を使用する構成です。

SnapMirrorの構成は、ネットアップ社のFASシリーズを2台用意し、データ送信側をFAS3250AE、データ受信側をFAS3220AEとしています。本番環境となるFAS3250AE上に作成したボリュームは、NFSデータストアとしてESXiサーバに見せ、次の通り、2種類のデータストアを構成しています。

(1) 仮想デスクトップ(Linked Clone)を配置するデータストア(vm0~vm2)
(2) Persistent Diskのみを配置するデータストア(pd0~pd2)

本検証でのバックアップデータは、(2)のみを対象にしています。実際にユーザデータを格納される領域はPersistent Diskのみであり、仮想デスクトップのOS領域はLinked Cloneであるため再展開は容易であることが理由です。

vCenterサーバにはネットアップ社のvCenterプラグインであるVSCを導入しており、SnapMirror転送はVSCから実行命令を出します。

NetApp VSC(Virtual Storage Console)

VSCは、vSphere Client上からvSphereとの連携したFASの管理を可能にします。特に仮想ディスク単位でのバックアップ/リストアまで対応している点は、大きなメリットです。

まずバックアップについては、対象のデータストアや仮想マシンを指定しての即時バックアップ実行や、バックアップジョブをスケジュールすることが可能であり、バックアップジョブでは以下のオプションを設定することができます。

  • [Initiate SnapMirror update]…SnapMirrorの更新命令を出すことができます。
  • [Perform VMware consistency snapshot]…仮想マシンのスナップショットと連携し静止点を確保することができます。
  • [Include datastores with independent disks]…仮想マシンのvmdkレベルでバックアップ対象を指定できます。

[Initiate SnapMirror update]と[Perform VMware consistency snapshot]オプションを使用すれば、仮想マシンのスナップショットとSnapMirrorと連携するバックアップを容易に作成することができます。

リストアについてもバックアップと同様に、データストア単位、仮想マシン単位、仮想ディスク単位でファイルレベルでも実施可能です。操作も簡単で、基本的にはリストアしたいデータを右クリックしてリストアを実行するだけのため、大きなオペレーションミスは発生しません。また、リストアしたいデータが単一ファイルであれば、Single File Restoreの機能を使用することで、ファイルレベルのリストアも可能です。なお、これは直接単一ファイルをリストアする機能ではなく、リストア先の仮想マシンにバックアップしていた仮想ディスクをマウント、認識させる機能です。その後、手動でマウントした仮想ディスクからファイルをコピーして復旧する操作が必要となります。仮想デスクトップ環境においては、仮想デスクトップユーザに以前のデータ(スナップショット)を見せ、必要なデータをユーザ自身でリストアさせる運用も可能です。

VSC+SnapMirror

VSCの[Initiate SnapMirror update]と[Perform VMware consistency snapshot]オプションを 使用した場合のVSC+SnapMirrorのバックアップの流れは以下の通りです。

仮想マシンの静止点を取得するため、データストア内の対象となる仮想マシンのスナップショットを作成する命令を出します。
仮想マシンのスナップショットの作成が完了すると、FAS側で対象データストア(ボリューム)のスナップショットを作成します。
作成した仮想マシンのスナップショットを削除します。
対象データストア(ボリューム)のSnapMirrorセッションに更新命令を出します。

これにより容易に静止点を確保したバックアップが可能ですが、以下2点ご注意いただく内容がありますのでご紹介します。

1つ目は、①と③において、データストア内の仮想マシン台数分のスナップショット作成/削除の処理が実行されますので(一斉ではなく数台の仮想マシン単位で順番に実行されます)、FASへのI/Oが発生し、FASのCPU使用率が上昇するため、大きなI/O負荷が掛かっている状況では少し処理が長くなる可能性があることです。

2つ目は、ESXiの仕様として、独立型の仮想ディスクはスナップショットの影響を受けないことから、独立型の仮想ディスクにおいては仮想マシンのスナップショットと連携するオプシ ョンは有効にする必要がないことです。
本検証でバックアップ対象としているPersistent Diskは独立型のため、仮想マシンのスナップショットによる静止点確保はできません。従って、バックアップの流れは以下のようになります。

FAS側で対象データストア(ボリューム)のスナップショットを作成します。
対象データストア(ボリューム)のSnapMirrorセッションに更新命令を出します。

Persistent Disk内のファイルの破損などを確実に避けたい場合には、事前に仮想マシンのシャットダウンをバックアップ手順に組み入れることを検討すべきです。

SnapMirror

このスライドではRPOで重要となる実際のSnapMirrorの転送速度やコントローラ、ディスクの使用率について検証したデータをまとめています。FAS3250AEのコントローラAとFAS3220AEのコントローラAの間をNexus5020経由で10Gb Ethernetで接続しています。想定している環境は拠点内での筐体間バックアップ構成です。本番ボリュームはSAS 15krpm Drive 16本のAggregateから作成された3つのPersistent Disk用データストアです。これに対し、ターゲットボリュームはコスト削減の観点からSATA 7.2krpm Driveにすることが多いため、SATA 7.2krpm Drive 10本の構成にしています。3つのボリュームからSnapMirrorセッションを作成し、この3セッションを並列実行しています。

  • 転送速度の傾向
    初期転送は約327MB/s(334,804KB/s)、差分転送は約354MB/s(362,701KB/s)となり差分転送の方がやや高速な結果となりました。一般的なストレージでは、ブロックデータの差分更新などが発生すると、転送データをランダムに読み取る関係で、転送性能が思うように出ない場合がほとんどです。しかし、FASシリーズの場合は、WAFLやNVRAMの機能によりランダムデータも基本的にはシーケンシャルデータとして保存されるため、転送速度の劣化は発生しません。ブロックベースのストレージレプリケーション製品に比べ、これは優位点であるといえます。
  • CPU、ディスク使用率の傾向
    FAS3220側のCPU使用率は初期転送時に81%、差分転送時には76%となり、送信しているFAS3250よりも負荷が高い結果となっています。また、ディスクの使用率については、FAS3220側は転送されたデータの書き込みが中心となることや、SATA Driveを使用している点から使用率が非常に高い結果となっています。これらの結果から、転送速度を重視する場合には、コストとのトレードオフにはなりますが、受信側のコントローラのモデルをFAS3250にすることや、ディスクをSATAからSASへ変更する、RAIDを構成するディスク本数を増やすなど、受信側コントローラやディスクのリソースの考慮も十分検討する必要があります。

なお、このスライドのデータについては検証データの一部です。実際には1Gb接続の場合や災害対策環境を考慮した遅延(10ms,20ms,30ms)の検証結果もございます。また弊社Solution Briefing Centerにおいて、BCP/DRの動作や測定結果の詳細データを実際にご覧いただくことが可能ですので、ご興味をお持ちでしたらご相談ください。

<お問合せ先>

ネットワンシステムズ株式会社 <ソリューション/サービス お問い合わせフォーム>

ネットワンシステムズ株式会社< Solution Briefing Center >

[最後に]

今回のネットワンシステムズ様のご提供コンテンツは、いかがだったでしょうか。FlexPodやVSC、SnapMirrorを使ったネットアップの災害対策のソリューションをパートナー様が入念に事前検証し、性能も含めた形で準備いただけていることにエンドユーザがすぐに導入できるメリットがあるのではないでしょうか。
特にSnapMirrorの性能についてパートナー様の視点で検証された結果ということで興味深いものがあります。 当コンテンツについて詳細を知りたい方は、是非弊社あるいはネットワンシステムズ様へお問い合わせください。 今後もエンドユーザ様が興味を持てる内容でパートナー様ご提供コンテンツをご紹介していきたいと思います。


田中隆行(Takayuki Tanaka)
システム技術本部 パートナーSE部 シニアシステムズエンジニア
NetApp



主にパートナー様技術的支援やプリセールスサポートを担当。2013 vExpert

関連情報
関連情報
Tech On Tap 8月号
関連情報
 
 
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2013 NetApp