|
日本アイ・ビー・エム株式会社 クロス・ソリューション事業部 ストレージ・ソリューション担当部長の佐野正和氏
|
ここ最近、いくつかのストレージベンダが“ストレージグリッド”と呼ばれる構想を口にするようになった。本稿では、ストレージグリッドの仕組みと最新動向を、その主要なベンダであるNetwork Appliance、Hewlett-Packard、IBMという3社の切り口からそれぞれ解説していく。後編では、日本アイ・ビー・エム株式会社 クロス・ソリューション事業部 ストレージ・ソリューション担当部長の佐野正和氏へのインタビューに基づき、ストレージグリッド技術の将来像とそれにまつわる課題を取り上げる。
■ 広域のストレージグリッドを実現しづらい今日のI/Oバウンド環境
グリッドの世界では“世界中に散在するパソコンを集めてスーパーコンピュータ並みの処理速度を実現”といったような話がよく聞かれるが、これは科学技術計算の世界では十分実用的なアプローチといえる。流体解析や原子粒の計算など、初期値を与えれば、あとはコンピュータを回し続けるだけで計算できる科学技術計算にとって、グリッドはとても効果的に働くからだ。しかし、一般企業のビジネスにまつわる処理は、計算している時間よりもデータの読み書きを行うI/Oの時間のほうが長い。処理の時間が10分あったとしたら、その10分間に計算をしている時間は1分もないのが実情だ。また、計算処理はnsの単位で行われ、データの読み書きはmsの単位で行われる。この速度差は無視できないほどに大きい。だからこそ、ストレージを高速化する必要があるのだ。
一般に、CPU処理の占める割合が大きなものをCPUバウンド(bound)、I/O処理の占める割合が大きなものをI/Oバウンドと呼ぶ。CPUバウンドのタスクは、計算処理を複数のノードに分散した方が高速化できる。一方、I/Oバウンドのタスクは、I/O処理をとにかく高速化しなければならない。ストレージをグリッド化した場合、ストレージはときに長距離のネットワークを介して接続されることになる。このため、本来はI/O処理の時間を短くしなければならないにも関わらず、その処理単位がmsどころか秒になる可能性があるのだ。「I/Oバウンドのタスクが多くを占める一般企業のシステムでは、世の中の回線が全部高速なFibre Channelにでもなってくれない限り、世界をまたがる大規模のストレージグリッドを実現するのは難しいと思います(佐野氏)」。
ストレージグリッドには、そのデータ配置として3種類のアプローチがある。1つ目は、世界中のサーバーやパソコンにデータを均一に分散させるという手法だ。最も究極的な例としては、世界中のパソコンにデータを分散し、その上でRAIDを構成してしまうようなものが考えられる。世界中にある500台のパソコンにデータを分散させた場合、400台にデータを保存し、100台にパリティを保存することでデータの冗長性を確保する。全体として仮想的な巨大ストレージとして見せ、500台のうち400台のパソコンがどこかで動いていればデータは失われないといった具合だ。
この手法は、世間一般で言うところのグリッド・コンピューティングないしはピア・ツー・ピア・コンピューティングに沿ったものなので、ある意味では最もグリッドらしく感じられる。しかし、I/Oバウンドのタスクを実行するには、パソコン同士を接続するネットワークが究極的に高速でなければ実用にならない。「このアプローチは、多くの人に理解してもらいやすいものの、実際に実現しようとすると空想科学小説にも等しい困難を伴います(佐野氏)」。
■ アイランドごとにデータを分散させるストレージグリッドが現実的
2つ目は、データを世界の中の一カ所に置いてしまおうというアプローチだ。将来的にネットワークがいくら高速になったとしても、データのバックアップなど、運用管理に関する考慮が必要である。そこで、ストレージを一カ所に集めてしまえば、こうした運用管理が究極的に簡単になるというわけだ。近くのサーバーからはFibre Channel経由で、遠くのサーバーからはiSCSI経由などでアクセスすればいいので、アクセス速度さえ目をつむれば、現在ある技術の延長線でも一応は実現できる。
|
サーバーからのデータアクセスには局所性があるため、データはある程度分散した方がいい。ただし、他のアイランドに格納されたデータに遠隔からアクセスする場合には、アクセス効率を踏まえた“データ移動”を考慮しなければならない。
|
ただし、それぞれのサーバーにはデータ参照の局所性が必ず発生するので、アクセス効率を考えると、データはサーバーの所在地に近い場所へとある程度分散したほうがよい。そこで、3つ目の手法としてアイランドごとにデータを分散するというアプローチが加わる。例えば、企業のオフィスがニューヨーク、東京、ロンドンにあった場合には、これらの3カ所をアイランドとしてデータを分散させるわけだ。
多くの企業に見られるデータアクセスの特性や世界中を結ぶネットワークの性能を考えれば、この3つ目の手法が最も現実的である。ここでの課題は、データ参照の局所性を維持しながら、データ移動の自由性をいかに確保するかということだ。先ほどの例でいえば、東京のサーバーからロンドンにあるデータにアクセスする場合、東京からロンドンに直接アクセスした方がいいのか、それともロンドンから東京にデータをいったん移し、東京でアクセスした方がいいのか。そして、このときのデータ移動をどう設定するのかが大きな課題だ。また、もっと話を先に進めて、全データの一部分だけを東京でアクセスし、他の大部分をロンドンでアクセスするとした場合、その割合をどのように設定すればいいのか。このとき、東京のほうが使用率が高まってきたら、ロンドンから東京へとアメーバのようにデータが自動的に移動してくれるようだったら非常にうれしい。
実は、これに似たテクノロジとしてCollective Intelligent Bricks (CIB)-Hardware(以前はIceCubeと呼ばれていた)の研究がIBMのアルマデン研究所で行われている。このCIB-Hardwareは、プロセッサ、メモリ、複数のディスクを内蔵した要素(ブリック)を3次元構成でグリッド化する新しいタイプのサーバーアーキテクチャである。ブリックをグリッド化することで、高い処理性能と可用性を同時に得る仕掛けとなっている。一部のブリックに障害が発生したら、正常なブリックへとタスクやデータが引き継がれる。ユーザーの作業はブリックの増設や取り外しのみであり、その他の作業はすべて自動化されている。このブリック間のデータ移動が、先述のアイランド間のデータ移動に通じるものなのだ。
|
CIB-Hardware(旧IceCube)の3次元構造(左)とブリックの内部構造(右)。積み木を重ねるようなイメージでブリックを組み合わせることで、処理性能と可用性の向上を図れる異色のサーバーアーキテクチャだ
|
■ ストレージグリッドの完成形はオブジェクトストレージ
ただし、ここで重要なのは、こうしたデータ移動の仕組みを作るだけでなく、これらのデータにアクセスするための“方法論”も同時に築き上げることだ。一般に、データへのアクセスは、アプリケーションの作り方に大きく依存している。例えば、アプリケーションを三層化し、そのアプリケーションをJavaのようなオブジェクト指向言語で開発した場合、その処理自身はかなりオブジェクト化されているものの、I/Oの部分はアプレットで対応しているだけだったりする。ファイルアクセス、データベースアクセスなどには、それ専用のアプレットを組み合わせて“ごまかす”わけだ。当然、こうしたごまかしをせずにすべてをオブジェクト化しようという発想も生まれてくる。「オブジェクト指向でアプリケーションを開発するからには、I/Oもオブジェクト指向で行う必要があります。IBMは、ストレージグリッドという観点において、むしろこのオブジェクト化に注目して開発を進めています(佐野氏)」。
ストレージをオブジェクト化するには、データをオブジェクトとして管理する仕組みが必要だ。具体的には、データ本体に加え、そのデータがどのアプリケーションから読まれるものなのかを管理する付加情報が欠かせない。一般にこうした付加情報をメタデータと呼び、このメタデータを管理する情報システム全体のことをオブジェクトストレージと呼んでいる。このオブジェクトストレージの考え方は、言葉の意味としては世の中の人が言うところのストレージグリッドの究極像とほぼ等しいものだ。
そして、オブジェクトストレージの世界では、アプリケーションとのやり取りに必要なインターフェイスの標準化にまで話が及んでくる。すでに各方面から標準としていくつかの案が提示されているが、現実的に一番有力なものはXMLだという。ただし、XMLの記述をどのように行うかはまた別の問題となる。
例えば、データに関連するアプリケーション名が「Adobe Acrobat 7.0」だとした場合、TCP/IPのwell-known portのように1101をAcrobat 7.0と設定する方法がまず考えられる。しかし、それをバージョンの違いも含めてアプリケーションの種類だけ用意するのは現実的ではない。だったら、文字列でアプリケーション名を格納する方法も考えられるが、その文字列をどのように定義するかという部分で問題が発生しそうだ。一社が独自に定義するなら乗り切れそうだが、全社に共通の標準化された定義を用意するのはかなり難しい。「各OSのローカルファイルシステムに互換性がない現状を見ても分かるように、ファイルシステムのレベルでさえこのような状態なのですから、オブジェクトストレージのインターフェイスを標準化するのは事実上無理なのではないでしょうか(佐野氏)」。
■ 従来型ストレージとオブジェクトストレージを結ぶ架け橋が不可欠
このように考えると、将来的にオブジェクトストレージが実用化されたとしても、そのインターフェイスはベンダ独自のものになる可能性が極めて高い。仮にそうしたオブジェクトストレージが発売されたとしたら、今度はこれを顧客に売るための戦略が必要になる。というのも、オブジェクトストレージは従来型のストレージとまったく互換性を持たないからだ。つまり、従来のファイルシステムやアプリケーションをそのまま乗せられないストレージなのだ。だからといって、オブジェクトストレージ向けの新しいインターフェイスを使って一からシステムを作り直すことを許容する顧客がいるとも思えない。
|
オブジェクトストレージが発売されたとしても、当面は従来型のストレージと互換性を取る仕組みが盛り込まれるものと予想される。ファイルシステム経由では「1」、Rawディスク経由では「2」だ。将来的には、オブジェクトストレージのI/Oに直接対応できるアプリケーション「3」の登場が期待される。
|
そこで、一歩手前に間を取り持つ形態が必要になってくる。例えば、IBMのSANファイルシステムのようなものを間に挟んで、オブジェクトストレージの特殊なI/Oを従来型のI/Oに変換する仕組みを搭載する。こうすることで、従来のアプリケーションからも従来通りにアクセスできるようになる。もちろん、これでは従来型のストレージとまったく変わらないわけだが、新しいストレージをとにかく世に輩出するには致し方がないところだ。ここでは、オブジェクト化された新しいインターフェイスも用意されていることもアピールしながら、少しずつオブジェクトストレージへとユーザーを導いていくことになる。
「他社が言うところのストレージグリッドは、現在のストレージ仮想化技術の延長線上にあるものです。これなら、製品化はそれほど難しくないでしょう。しかし、IBMが考えている真のストレージグリッドとは、従来型ストレージとは一線を画する“オブジェクトストレージ”のことなのです。このため、新型ストレージに向けたインターフェイス構築、従来型ストレージとの互換性確保など、さまざまな面を考慮しなければならず、お客様が安心して利用できるストレージグリッドの実現にはまだまだ時間がかかると考えています(佐野氏)」。
■ URL
日本アイ・ビー・エム株式会社
http://www.ibm.com/jp/
■ 関連記事
・ ストレージ仮想化の先にあるストレージグリッド技術 [前編](2005/05/23)
・ ストレージ仮想化の先にあるストレージグリッド技術 [中編](2005/06/13)
( 伊勢 雅英 )
2005/06/20 00:00
|