 |
|||||||
|
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
 |
|||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
| ||||||||||||||||||||||
|
日本IBMに聞くストレージ仮想化の効果的な活用法 [前編] |
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
| ||||||||||||||||||||||
|
これからのストレージを支える技術として注目を浴びているストレージ仮想化。このような背景のもと、ベンダやシステムインテグレータの営業活動、セミナーなどを通じて“ストレージ仮想化とは何か？”を知るユーザーは着実に増えてきている。しかし、“ストレージ仮想化によって具体的に何が得するのか？”をきっちりと理解しているユーザーは意外と少ない。 今回は、日本アイ・ビー・エム株式会社 クロス・ソリューション事業部 ストレージ・ソリューション担当部長の佐野正和氏に、ストレージ仮想化のメリットとその具体的な活用法をお聞きした。前編では、現在のSANが抱える問題点と、それを解決するIBMのアプローチを解説する。
■ もともとファイル共有には対応していないオープン系システム SAN（Storage Area Network）はストレージをネットワーク化したものなので、複数のコンピュータシステムからストレージを効率よく共有できる。そして、これは多くの文献や広告に見られるSANの典型的な宣伝文句だ。しかし、現実のSANをよく観察してみると、物理的にはネットワーク化されていながらも、論理的にはコンピュータシステムとストレージが一対一の関係にあることが分かる。つまり、コンピュータシステムがSANに接続されている1台のストレージを丸ごと占有するか、ストレージの中に自分専用の区画を作って利用する形となっており、SANはデータ経路を共有しているに過ぎないのだ。これは、使い方の上でいえば、コンピュータシステムにストレージを直結する従来型のDAS（Direct Attached Storage）とあまり変わらないことになる。この問題は、WindowsやUNIXなどを搭載したオープン系システムで相互にファイルを共有できないことに起因する。では、なぜファイルを共有できないかというと、まずファイルシステムがまったく異なるからだ。WindowsはNTFS、Linuxはext3やReiserFS、SolarisはUFSやVxFS、AIXはJFSが主に使用されているが、これらのファイルシステムは原則として自分以外のOSから操作できない。もちろん、他のOSのファイルシステムを読み書きするソフトウェアを追加する方法も考えられるが、ファイルシステムはOSのアーキテクチャに深く根ざしたものであり、あたかもネイティブのファイルシステムを操作するような完全なアクセス機能を実現することは不可能に近い。
例えば、オープン系システムでは、通常の使い方でファイルシステムを利用している場合、プログラムでデータの書き込みを実行したら、メインメモリに書き込んで処理を終える仕組みとなっている。メインメモリに書き込んだ時点で次のプログラムの手順が起動する。ストレージへのデータ書き込みはバックグラウンドでゆっくり行われるため、I/Oトランザクションの多いシステムでは、途中でシステムがハングアップしたり、電源が切れたりすると、データが失われる可能性が高い。 そして、さらに大きな問題となるのが、ストレージ上のデータの位置を指し示すファイルのインデックス（UNIXならばiノード）がメインメモリ上に展開されていることだ。インデックスがメインメモリに展開されていると、隣のコンピュータシステムからファイルの正確な場所を知ることができない。もちろん、ディスク上にもインデックスは書き込まれており、このインデックスを参照すれば共有できそうにも感じる。しかし、ディスク上のインデックスはメインメモリから非同期で反映されるため、中身が常に最新であるとは限らないのだ。この結果、複数のコンピュータシステムでファイルをうまく共有できない。 ■ SANが抱える問題点を解決に導くストレージ仮想化 SANが抱えるもう一つの問題は、各社のディスクサブシステムの拡張機能に違いがあることだ。こうした拡張機能の多くは各社の特徴を出すためのものだが、異なるベンダのストレージが混在するヘテロジニアスSAN環境では大きな仇となる。例えば、ほとんどのハイエンド・ディスクサブシステムには、システムを止めることなくディスクサブシステム間でデータを高速にコピーする高速コピー機能が搭載されている。しかし、その実装方法はベンダによって大きく異なる。IBMのESS（Enterprise Storage Server）同士であればFlashCopyというコマンドで高速コピーを実行できるが、日立のSANRISEならばShadowImage、HPのxpならばBusinessCopy、EMCのSymmetrix DMXならばTimeFinderとなり、異なるベンダのディスクサブシステム間で高速コピーを直接行うことはできない。このため、ある程度の規模を持つSANで多く見られるヘテロジニアスSAN環境では、各社のディスクサブシステムが互いに連携し合うことなく、単独で使用されることになる。しかし、これではストレージをネットワーク化した意味が薄れてしまう。
「古くはメインフレーム1台に複数のダム端末を接続するだけでしたので、話はとても単純でした。しかし、現在ではWindows、UNIXサーバーなど、さまざまな種類のオープン系システムが平行して稼働している上に、高機能化が進んだクライアントPCがEthernetなどのネットワーク媒体とIPなどのネットワークプロトコルを通じて相互に接続されています。この結果、システム全体の構成がきわめて複雑になり、コンピュータシステムの導入や運用、管理に必要な人手とお金が日々増加しているのです。そこで、“これらの複雑なシステムを何とかして単純化しよう”という考えのもと、仮想化と呼ばれる技術が登場しました。サーバーやストレージが何台あっても、仮想化によってこれらを1台に見せられれば運用や管理がずっと楽になります（佐野氏）」。 ■ ブロックレベルとファイルレベルのストレージ仮想化を用意 ストレージ仮想化を実現する方法には、サーバーの中にソフトウェアを組み込み、このソフトウェアを通じてストレージ仮想化を行うもの、ホストバスアダプタ（HBA）でストレージ仮想化を行うもの、ディスクサブシステムのマイクロコードにストレージ仮想化機能を搭載したものなどがある。また、ネットワーク全体で仮想化を行う研究も一部で進められている。例えば、サーバーが10台あったら、これらに均等にデータを配置し、サーバー全体に対してデータアクセスを行おうというものだ。「ネットワーク全体でストレージ仮想化を実現しようとする考え方は、世界観としてグリッドコンピューティングに近いものがあります。ネットワークが究極的に速くなれば、こうした発想も成り立つかもしれませんが、早期の実用化は難しいのではないでしょうか（佐野氏）」。
ブロックレベルの仮想化とは、SCSI（Fibre ChannelはOS上でSCSIにマッピングされる）とサーバーOSの関係を維持したまま、ネットワークの中間で仮想化を行うものである。つまり、Sun MicrosystemsのSolarisがあり、Solarisのファイルシステムがあり、ディスクサブシステムがあるという関係を維持したまま、ディスク以下の部分を仮想化する。これにより、サーバー側の変更がまったく不要という利点が生まれる。一方、これまで説明してきたようなSANの根本的な問題には目をつむっており、複数サーバー間でのファイル共有などは依然として行えない。 一方、ファイルレベルの仮想化は、すべてのサーバーで使用する共通のローカル・ファイルシステムをストレージ仮想化システムが用意するというものだ。ファイルを共有できない根本的な原因はファイルシステムにあるので、これをネットワーク上で統一することにより、複数サーバー間でのファイル共有を可能にしている。「ただし、運用に変更が加わるという欠点があり、それを好まない方も当然いらっしゃいます。そこで、運用の変更がいらないブロックレベルと、運用に変更が必要ながら従来型SANの問題点を解決できるファイルレベルという2種類の仮想化方式を用意しているわけです（佐野氏）」。 ■ ＵＲＬ 日本アイ・ビー・エム株式会社 http://www.ibm.com/jp/ ■ 関連記事 ・ 日本IBMに聞くストレージ仮想化の効果的な活用法 [中編]（2004/03/30） ・ 日本IBMに聞くストレージ仮想化の効果的な活用法 [後編]（2004/03/31）
（ 伊勢 雅英 ）
|
|
|
|
|
|
|