 |
|||||||
|
|
|
||||||||||||||||||
|
||||||||||||||||||
|
 |
|||||||||||||||||
|
||||||||||||||||||
|
||||||||||||||||||
|
||||||||||||||||||
|
| ||||||||||||||||||
|
ストレージ仮想化の先にあるストレージグリッド技術 [前編] |
||||||||||||||||||
|
||||||||||||||||||
|
2005年末にストレージグリッド対応OSを発表するNetwork Appliance
|
||||||||||||||||||
|
| ||||||||||||||||||
本稿では、このストレージグリッドの仕組みと最新動向を、その主要なベンダであるNetwork Appliance（以下、NetApp）、Hewlette-Packard、IBMという3社の切り口からそれぞれ解説していく。前編では、日本ネットワーク・アプライアンス株式会社 代表取締役社長の鈴木康正氏へのインタビューに基づき、NetAppが推進しているストレージグリッド技術を取り上げる。 ■ ストレージにもグリッド的な思想が求められつつある 近年、あらゆる計算処理に関わるコンピューティングファーム側、すなわちサーバー側のグリッド化が推し進められている。このグリッド化を強く後押ししているのが、ブレードサーバーだ。ブレードサーバーの登場によって、コンピューティングリソースの高密度配置が可能になり、従来の大型SMPに匹敵する高い計算処理性能が容易に得られるようになった。それに加え、タスク負荷に応じてリソースを自由自在に動的に割り当てられる柔軟性もグリッドの大きな特徴だ。ブレードそのものは極力小さくて軽いものがいいため、ブートファイルをフラッシュメモリに持たせるケースは考えられるものの、原則としてディスクレスになるものと予想される。このとき、ブレードとストレージの接続に従来のようなFibre Channelを使用した場合、FCスイッチがいくら安価になったとはいえ、FCスイッチのポート単価がブレード1枚の価格よりも高くなる可能性がある。「ブレード環境でFibre Channelを使用すると、コスト的にまったく見合いません。ブレード群とストレージを接続するスイッチファブリックは、ほぼ間違いなくIPの方向に進むでしょう（鈴木氏）」。 そして、何らかの標準に基づくブレードサーバーを用いてグリッドの構築が可能になりつつある現在、次に課題となるのがストレージのあり方だ。現在、サーバーとストレージは一対一で直接的にマウントするか、SAN環境であれば完全にトランクをかける形でやはり一対一で対応させている。しかし、グリッドの利点は、タスクもしくはトランザクションごとに何らかの条件が変わったとき、それに対して最もパフォーマンスを高められるように動的かつ柔軟にリソースを配分できることだ。そして、このようなグリッドの利点を享受するには、ストレージにもグリッド的な思想を取り込まなければならない。 具体的には、サーバー群からストレージ側が一つのシングルイメージとして見えるようにマウントできる仕組みを作る。ちょうど、インターネットの世界でいうところのURLにも似ている。URLの場合、WebブラウザからURLを入力すれば、DNSで適切なIPアドレスを割り出し、適切なサイトへと導いてくれる。同様に、サーバーが必要としているデータにアクセスしたら、何らかの意味合いを持つ位置付けに対してだけアクセスするだけで、その先の物理的な位置が自動的に割り出され、適切なストレージにそのアクセスが導かれるようになっていればよい。 多くのベンダは、このようなシステムの理想像をユーティリティコンピューティングやオンデマンドコンピューティングなどと呼んでいる。また、特にストレージのグリッド化を支える技術を仮想化、その中の各タスクに対する割り当ての理想型をプロビジョニングと呼んでいる。鈴木氏は、これに対し「ストレージのグリッド化は“言うは易く行うは難し”です。NetAppは、これからお話しするような3つの仮想化を通じてストレージグリッドを実現しています」と話す。
■ 複数のストレージをシングルイメージとして見せる仮想化 1つ目は、先述の通りストレージをシングルイメージとしてサーバー側から見えるようにする仮想化である。そのためにはURLに似た仕組みが必要だが、NetAppのストレージグリッドはこれをグローバルネームスペースによって提供している。グローバルネームスペース（大域的名前空間）とは、広義には分散システムにおいてすべての計算機から参照できる単一の名前空間を指している。グローバルネームスペースは、データの物理的な所在に関わらず、サーバー側からは単一のファイルシステム上にあるデータのように見せかける。これにより、サーバーはデータの物理的な位置を意識することなく自由にそのデータへとアクセスできるようになる。こうした仕組みを持つソリューションには2つのアプローチが考えられる。一つは、グローバルネームスペースを提供するサーバーまたはスイッチをシングルポイントで用意するアプローチだ。サーバーからのI/Oトランザクションは、必ずこのサーバまたはスイッチを経由し、このサーバーまたはスイッチが適切なロケーションにあるストレージに対してI/Oトランザクションを割り当てる。 もう一つは、ストレージのコントローラやファームウェアなど、ストレージ側の管理機構に頼るアプローチだ。ストレージ側がロケーション情報を共有することにより、サーバーからのI/Oトランザクションが最適なロケーションにルーティングされる。つまり、これらの2つのアプローチは、I/Oトランザクションのルーティングを集中でやるか分散でやるかの違いだ。 「集中型の問題点は、いうまでもなく処理がシングルポイントで行われることです。ハードウェアを冗長化するのは当然のことですが、それ自身が高負荷になってハングアップしたら終わりです。このため、NetAppは、ストレージのコントローラ自身に共通のグローバルネームスペースをハンドリングする機構を持たせ、これらの中でお互いにやらせる分散型のほうがいいと考えています」。 「しかし、分散型は決して容易に実現できるものではありません。NASの場合、UNIXやLinux環境では、NFSのパケットに含まれるヘッダ、データ部を確かめて、そのリクエストがどのNASで処理すべきものかというロケーション情報を取得します。もし、他のNASに対するリクエストだった場合には、自分の下にあるファイルシステム側にそのリクエストを渡さず、外部のNASに処理をルーティングします。つまり、ファイルシステムおよびRAIDの処理からディスクアレイへの書き込みまでという通常の流れと完全に分離された上位ネットワークのインターフェイスがあり、これらの間を特別なルーティングプロトコルが走る構造にする必要があるわけです」。 「ここで問題となるのが、ルーティングプロトコルの性能です。ルーティングプロトコルそのものが複雑で処理が遅かったりすると、今度は分散化による弊害が生じます。従って、ルーティングプロトコルは十分に高速でなければならないのです。NetAppは、昨年買収したSpinnaker NetworksのSpinNPプロトコルを採用しています。SpinNPプロトコルは非常に良くできており、弊社のストレージにこれを組み込んで先進のストレージグリッドを実現することになりました（以上、鈴木氏）」。 ■ 3つの仮想化をすべてサポートしているNetApp 2つ目は、コントローラとディスクの間の繋がりが固定されないように、この繋がりを自由に切り替えられるようにする仮想化である。ヘッド部分のコントローラとディスク集合体であるディスクアレイの間が、FCP（Fibre Channel Protocol）のトランクなどにより、何らかの形で強く結合されていると、ストレージの柔軟性に限りが出てしまう。そこで、NetAppは、Data ONTAP 7G以降でコントローラとディスクアレイ間のパスを自由に切り替えられる仮想化機能を実装しているという。
「ディスクそのものはデータ配置のためのロケーションを提供する箱に過ぎません。ボリュームというのは、こうした物理的なディスクの配置には無関係に定義すべきものです。これは、同じ部屋の中にある複数のストレージのみならず、異なるロケーションにある複数のストレージにも当てはまります。例えば、サーバー室にあるディスクアレイA、異なる建屋にあるディスクアレイBに対し、これらのディスクアレイをまたいでファイルのストライピングを行ったりもできます。もちろん、距離の離れたロケーション間でデータをストライピングすると、ネットワーク帯域の問題なども関わってきますので、あくまでも理論上可能という意味で捉えてください」。 「以上、3点の仮想化について考えたとき、1番目のグローバルネームスペースをストレージコントローラのOS側で対応させようとしているベンダはNetAppしかありません。2番目の仮想化は、現時点でこの部分の重要性を唱っているベンダは他にありません。ただし、技術的に難しくはありませんので、今後対応するベンダも登場するでしょう。3番目の仮想化は、SANの世界でいうところのLUN（Logical Unit Number）が概念的には近いものになります。ただし、純然たるNASとして考えたときに、それとまったく同じ機能を実現しているベンダは他にありません」。 「このように見ていきますと、3つの仮想化に関してすべてソリューションを提供しているベンダは、現時点でNetAppだけということになります。また、他社はビジョンの域を超えていませんが、NetAppはすべてのコンポーネントが技術的な要素としてすでに目の前にあります。お客様のストレージ環境は、今後ますますヘテロジニアスになっていきます。NetAppは、こうしたヘテロジニアスな環境に対して3段階の仮想化を図れる唯一の仮想化エンジンとしてData ONTAPを世界標準にしたいと考えています（以上、鈴木氏）」。 ■ ストレージグリッド対応の次世代Data ONTAPは2005年末に登場
「Spinnaker Networksを買収し、SpinOSのソースコードが手に入ったからといって、すぐに私たちのData ONTAPとマージして製品化できるほど簡単な話ではありません。私たちが目指しているのは、お客様にとって最良の製品です。このため、コンポーネントとしてNetAppとSpinnaker Networksのソースコードをそれぞれ利用しつつも、双方の利点をうまく引き出せるようなまったく新しい世代のOSを開発しています。こうした作業は慎重に進めざるを得ませんので、どうしても時間がかかってしまいます」。 「その最初のバージョンが2005年末にも登場し、Data ONTAPの次期バージョンとして発表される予定です。従来のData ONTAP 7Gに対する上位互換の製品となり、同時にSpinOSに対する互換性も持っています。もっと正確に言うと、SpinOSと機能がまったく同じに見えつつ、ファイルシステムレベルではData ONTAPと完全に互換性を持つ製品となります。従って、現在Data ONTAPをお使いになっているお客様も、そのままバージョンアップするだけでOKです」。 「ストレージグリッドだけを強く意識すれば、すぐに対応する必要がない機能ももちろんあります。例えば、ストレージグリッドの現実的な構成を考えれば、FCPへの対応は不要といえるでしょう。ブレードに基づくコンピューティングファームを考えた場合、必要なプロトコルはIPネットワークをベースとしたNFS、CIFS、HTTPくらいです。お客様の動向を見る限り、ブレード環境の多くではLinuxが導入されていますので、さらに対象を絞れば、ほぼNFSで対応できるものと考えられます」。 「ところが、Data ONTAPのお客様を完全に取り込むには、これだけでは不十分です。現在のData ONTAPで大規模なSAN環境を構築していたり、FCでストレージを接続する大型のサーバを運用しているなど、Fibre Channelにかなり投資しているお客様には、どうしてもFCPへの対応が不可欠です。また、SANという観点で言えば、iSCSIへの対応も必要になります。NetAppでは、FCPやiSCSIへの対応を第二弾の対応と考えており、2006年のリリースを目指して開発を進めています（以上、鈴木氏）」。 中編では、Hewlett-Packardが考えるストレージグリッドについて取り上げていく。 ■ ＵＲＬ 日本ネットワーク・アプライアンス株式会社 http://www-jp.netapp.com/ ■ 関連記事 ・ ネットアップ、「ボリュームの動的な仮想化」を実現する新OS（2004/11/18） ・ 「Spinnakerを糧に」ストレージグリッド構想を強化するNetApp（2004/09/03）
（ 伊勢 雅英 ）
|
