 |
|||||||
|
|
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
 |
|||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||
|
SAN/NASを包括するEMCのストレージ仮想化ソリューション【NAS編】 |
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||
前回は、SAN環境でストレージ仮想化を実現するソリューションとして「EMC Invista」を紹介したが、今回はNAS環境でストレージ仮想化を実現する「EMC Rainfinity Global File Virtualization」（以下、Rainfinity GFV）を取り上げていく。EMCジャパン株式会社 マーケティング本部 プロダクト・マーケティング・マネージャの後藤哲也氏に、Rainfinity GFVが求められる背景やそのアーキテクチャーについてお話を伺った。 ■ ファイルサーバーの乱立はさまざまな問題を生み出している
こうしたファイルサーバー群が互いに連携することなく独立して使用されると、いくつかの問題が発生する。まず、ファイルサーバーごとのアクセス負荷やディスク使用率がばらつく。ファイルサーバーを利用するアプリケーションの種類や特性によってアクセス負荷が大きく左右されるが、それぞれが単独に動作している以上は、適正な負荷率に抑えたり、負荷分散を図ったりすることが困難だ。また、ディスク使用率についても、アプリケーションに強く依存するものであり、中には十分に使用効率を高められないファイルサーバーも出てくる。そして、ファイルサーバーそれぞれに残された空き領域は、そのスペースが小さければほかの用途に流用することさえできない。つまり、ファイルサーバーの台数が増えれば増えるほど、どうやっても使い切れない無駄な領域がトータルとして増えていく。 いうまでもなく、IT管理者の負担も増える一方だ。ハードウェアの台数が増えれば、それを運用管理するための手間も格段に増していく。また、前編でも取り上げたように、長期的に見れば、必ず古いファイルサーバーから新しいファイルサーバーへのデータ移行が発生する。ファイルサーバーは、SAN上のストレージと違ってファイル単位でコピーできることから、当該システムを完全に止められるのであればデータ移行そのものは容易だ。しかし、近年のITシステムでサービスを長時間止められるようなものは少ない。やはり、サービスを極力止めることなく、バックグラウンドでデータを移行できるソリューションが求められる。そこで、ストレージ仮想化技術が注目を浴びるようになった。 ■ NAS向け仮想化ソリューション「Rainfinity GFV」が提供する3つの機能 今回取り上げるRainfinity GFVは、こうしたファイルサーバー（NAS）環境における諸問題を解決するストレージ仮想化ソリューションとなる。Rainfinity GFVは、既存のファイルサーバー環境にプラグオンする形で使用する。ハードウェア自体はLinuxベースのOSが動作するIAサーバーだが、あくまでもハードウェアとOS、Rainfinity GFVの中核となるソフトウェアがすべてパッケージングされたアプライアンスとして提供されている。
データ移行では、Rainfinity GFVがクライアントとファイルサーバー間を仲介して実施される。ここでいうクライアントとは、もちろんクライアントPCの場合もあるが、ファイルサーバーをデータの保管庫として使用している各種サーバーコンピューターもファイルサーバーにとってのクライアントとなる。本稿では、ファイルサーバーを利用する側のコンピューターを総称してクライアントと書くことにする。さて、それらのクライアントは、データ移行中、あたかも移行元ファイルサーバーのように振る舞うRainfinity GFVを通じてファイルサーバーにアクセスする。このように、Rainfinity GFVが介在する通信状態をインバンドと呼んでいる。2台のRainfinity GFVを使用した同期ミラーソリューションでも、常にRainfinity GFVが介在するので、これもインバンドな状態だ。
■ いくつかのステージに分かれて実行されるデータ移行のプロセス Rainfinity GFVで中核となる機能は、やはりファイルサーバー間での透過的なデータ移行だ。Rainfinity GFVのデータ移行プロセスは、いくつかのステージに分かれて実行される。まず、データ移行を開始する直前までは、ファイルサーバーとクライアント間で従来通りのファイルアクセスが行われている。Rainfinity GFVは、ファイルサーバー群の動作状況を監視し、その統計情報を作成する。この状態では、ftpやsnmpなどのプロトコルを通じて、アウトオブバンド方式で各ファイルサーバーから統計情報を取得している。データ移行が開始されると、Rainfinity GFVがクライアントとファイルサーバー間を完全に仲介し、インバンド方式の通信に切り替わる。まずは、Rainfinity GFV自身が移行元ファイルサーバーから移行先ファイルサーバーへとバックグラウンドでデータコピーを実行する。これが、『Executing』と呼ばれるステージだ。クライアントからRainfinity GFVにアクセスがあった場合、読み出しは移行元ファイルサーバーから、書き込みは両方のファイルサーバーに対してそれぞれ実行される。なお、移行可能なファイル数は7000万ファイルまでをサポートしている。ほとんどの企業では十分すぎる仕様だが、万が一足りない場合にはRainfinity GFVアプライアンスの増設によって対処できる。 データ移行が順調に進み、ある程度の時間が経過すると、最終的には移行元ファイルサーバーと移行先ファイルサーバー間でデータ内容が完全に一致するタイミングが訪れる。クライアントからのファイル書き込みは、両方のファイルサーバーに対して同時に行われることから、いったんデータ内容が一致してしまえば、それ以降は両者で完全に同期した状態を維持できる。そこで、Rainfinity GFVは、両者のデータ内容が一致した段階で『Syncing』と呼ばれるステージに移行する。 「少々低速なインバンド方式でデータ移行が行われるExecutingのステージは、できる限り減らしたいものです。そこでお勧めなのが、既存のデータ移行手法と上手に組み合わせるアプローチです。ストレージのミラー機能やコピーコマンドを用いて初期コピーを実施し、あらかたのデータを高速にコピーしてしまいます。このとき、アウトオブバンド方式でデータ移行が行われるので、スピーディーにデータを移行できます。そして、Rainfinity GFVによって差分コピーを実施し、両方のファイルサーバー間で完全に同期をとります。こうすることで、Rainfinity GFVによるインバンド方式のデータ移行を最小化できるため、データ移行にかかる時間を短縮可能です。（後藤氏）」
■ 新しいファイルサーバーへのアクセス経路に切り替えたらデータ移行完了 Syncingのステージに達したら、移行元ファイルサーバーはいつでも切り離せる。移行元ファイルサーバーをRainfinity GFVから切り離し、Rainfinity GFVは読み書きともに移行先ファイルサーバーのみに対して行うようになる。これが、『Redirecting』と呼ばれるステージだ。SyncingからRedirectingへの切り替えは、原則として管理者自身が手動で実行する。Rainfinity GFVが自動で切り替えることも可能だが、Redirecting移行後には両ファイルサーバー間のデータ同期が崩れることから、やはり安全のためにも管理者自身の目で判断し、手動でRedirectingへと移行させるべきなのだ。そして、データ移行作業の最終段階では、移行元ファイルサーバーを完全に切り離す。ネームスペースを移行先ファイルサーバーにアクセスできるようなマップ情報に書き換えることで、それ以降のデータアクセスはすべて移行先ファイルサーバーに対して実行されるようになる。このとき、クライアントがファイルサーバー群にアクセスする際のネームスペースとして、MicrosoftのActive DirectoryやDFS（Distributed File System）、UNIX系OS向けのNIS（Network Information Server）など、業界標準の技術をそのまま使用できる点が大きなポイントだ。 データ移行が完了すると、Rainfinity GFVの仲介がなくなり、クライアントと移行先ファイルサーバー間で直接的にアクセスが行われる。Rainfinity GFVは、各ファイルサーバーの統計情報を取得するモニタリング状態に戻り、再びアウトオブバンド方式の通信に切り替わる。なお、クライアントからのアクセス先を移行元から移行先のファイルサーバーに切り替える際には、一時的にアクセスできなくなるタイミングが発生する。これは、移行元ファイルサーバーとのコネクションを切るアンマウントから、移行先ファイルサーバーへのコネクションを再び張るマウントまでの時間にあたる。1台のクライアントが必要とするアンマウント/マウント作業の時間は非常に短いが、クライアントの台数が多ければトータルの時間はそれなりにかかる。どのクライアントからどのようなタイミングでアンマウント/マウントを実施するかという計画は、あらかじめ慎重に練っておく必要がある。 「アプリケーションによっては、サービスをまったく止めなくてもすむケースがあります。例えば、それなりの規模を持つWebサービスでは、コンテンツを保管している1台のファイルサーバーを複数のWebサーバー（ファイルサーバーにとってのクライアント）から共有します。このような環境では、1台のWebサーバーがアンマウント/マウントを実施している最中にほかのWebサーバーがサービスを提供し続けられます。つまり、実質的にサービスを停止させることなくファイルサーバーの移行作業を行えるわけです。（後藤氏）」
■ インバンドとアウトオブバンド間の切り替えでアクセス断が発生する
Rainfinity GFVは、一種のEthernetブリッジとして動作している。Rainfinity GFVには、2つの出入り口があり、それぞれパブリック側とプライベート側という2つのセグメントに分割される。クライアントから直接アクセスできるセグメントをパブリック側、Rainfinity GFVの配下となるセグメントをプライベート側とすると、アウトオブバンド方式の通信は、クライアントとファイルサーバーともにパブリック側に接続することを意味している。一方、インバンド方式の通信は、クライアントをパブリック側、ファイルサーバーをプライベート側に接続することを意味している。 こうしたバンド状態の変更には、いくつかの方法がある。最も原始的なやり方は、管理者が物理的にLANケーブルをつなぎ替える方法だ。ファイルサーバー自身をRainfinity GFVのプライベート側に接続し直すことでインバンドの状態となる。パブリック側に戻せば再びアウトオブバンドの状態に戻る。LANケーブルのつなぎ替えだけで対応でき、Ethernetスイッチ、ファイルサーバー、Rainfinity GFVなど、各種ハードウェアに対する構成変更を必要としない。このため、最も簡単にバンド変更を行えるのがメリットだ。しかし、管理者が物理的にLANケーブルをつなぎ替える際に発生する、余計なタイムロスや人為的ミスによるリスクをてんびんに掛けなければならない。バンド変更用の予備スイッチを使用するアプローチもあるが、管理者の手作業が発生することに変わりはない。 ■ VLANを利用することで、よりスマートなバンド状態の変更が可能 そこで、Rainfinity GFVは、IPネットワーク機器の世界で広く普及しているVLAN（Virtual LAN）機能を活用したバンド状態の変更をサポートしている。VLANを利用すれば、既存のネットワーク上にパブリック側とプライベート側のセグメントを論理的に持てるようになり、LANケーブルの物理的なつなぎ替えが必要なくなるのだ。具体的には、2つのアプローチがある。ひとつはNAS VLANだ。NAS VLANは、ファイルサーバーとEthernetスイッチ間のネットワークインターフェイス上でVLANタグ（通常はIEEE 802.1Q）を使用する。パブリック側とプライベート側のVLANタグを別々に持つことで、ファイルサーバーとRainfinity GFVを結ぶセグメントを論理的に切り替える。パブリック側のVLANタグを使用すればアウトオブバンド方式となり、プライベート側のVLANタグを使用すればインバンド方式になる。当然、VLANタグをサポートするファイルサーバーも必須であり、現時点ではEMC CelerraとNetApp FASシステムでNAS VLANを利用できる。EMCは、これらのストレージシステムでバンド状態の変更を自動化するRainfinity GFV向けのスクリプトも用意している。 もうひとつのアプローチは、スイッチVLANである。スイッチVLANは、Ethernetスイッチのポート単位で実現されるVLAN機能を利用するものだ。ファイルサーバーが接続されているポートをパブリック側にすればアウトオブバンド方式、プライベート側にすればインバンド方式になる。こうしたバンド状態の変更を自動化するには、EthernetスイッチのVLAN設定を動的に変更する機能が求められる。そこで、Rainfinity GFVは、Cisco IOS、Cisco CatOS、Foundry IronOS、Extreme ExtremeWare、Nortel BayStack、Nortel Passportスイッチに対してVLANの設定を動的に変更するスクリプトを用意している。スイッチVLANは、外部からVLANの設定を変更できるEthernetスイッチさえ使用していれば、ファイルサーバーの種類（VLANへの対応有無）は問わない。 「Rainfinity GFVが勝手にEthernetスイッチのVLAN構成を変更することに不安を感じるお客さまも一部にはいらっしゃいます。そうしたお客さまは、LANケーブルをつなぎ替える従来型のアプローチでハンド状態の変更を実施しています。確かにVLAN機能を活用したほうがバンド状態の変更にかかる時間を短縮できるのですが、実際にVLANベースのバンド変更を採用するかどうかはお客さまによりけりといったところです。（後藤氏）」
これまで説明してきたように、Rainfinity GFVを使用することで、現在乱立しているファイルサーバーの稼働状況を細かくチェックし、ファイルサーバーの統合に向けた的確な計画を立てられる。そして、データ移行の際には、サービスの停止を最小限に抑えながら、クライアントから透過的にデータ移行作業を進められる。今回は紙面の都合から取り上げられなかったが、NASのファイル階層化ソリューションである「Rainfinity File Management Appliance（Rainfinity FMA）」を併用すれば、ファイルの価値やアクセス頻度に応じて適切なファイルサーバーに最適配置しながら、ファイルサーバーの統合も図れるようになる。こうした包括的なストレージソリューションは、やはり広範囲な製品ラインアップを持つ大手ストレージベンダーの強みといえるのではないだろうか。 ■ ＵＲＬ EMCジャパン株式会社 http://japan.emc.com/ ■ 関連記事 ・ SAN/NASを包括するEMCのストレージ仮想化ソリューション【SAN編】（2008/12/02）
（ 伊勢 雅英 ）
|
