 |
|||||||
|
|
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
 |
|||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||
|
日本IBMに聞くストレージ仮想化の効果的な活用法 [中編] |
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||
|
日本アイ・ビー・エム株式会社 クロス・ソリューション事業部 ストレージ・ソリューション担当部長の佐野正和氏に、ストレージ仮想化のメリットとその具体的な活用法をお聞きした。中編では、IBMのストレージ仮想化製品の基本的な思想、ブロックレベルのストレージ仮想化を実現するSANボリューム・コントローラーの機能とその活用法を取り上げる。
■ クラスタ構成を標準とするIBMのストレージ仮想化製品 ストレージ仮想化で使用されるハードウェアは、ブロックレベルの仮想化がSANボリューム・コントローラー（以下、SVC）、ファイルレベルの仮想化がSANファイル・システム・メタデータ・サーバー（以下、SFS）である。いずれもOSとしてLinuxを採用しており、その上でストレージ仮想化ソフトウェアやメタデータ・サービスが動作している。「Windowsは、無停電電源装置（UPS）との相性問題を抱えています。例えば、クラスタ構成でサーバー間のテイクオーバー時にUPSでトラブルが発生したり、電圧が少し低下したらシステムがリカバリーに走ったり、UPSが瞬断と停電を誤って解釈してシステムがシャットダウンに走る、といったトラブルをよく耳にします。大きなデータセンターに見られるCVCF（Constant Voltage and Constant Frequency unit：定電圧定周波装置）のような安定した電力が供給できる環境があれば、まったく問題ありませんが、壁の電源コンセントから電源を供給している環境は危険といわざるを得ません」。 「とはいえ“OSとUPSは他社が製造したものだからIBMには責任がない”というわけにはいきません。IBMのストレージ仮想化製品をお買い求めいただく以上、お客様にとっての最終的な拠り所はIBMとなりますから、信頼性の問題はIBM自身が解決しなければなりません。そこで、信頼性の高い弊社のハードウェアにLinuxとストレージ仮想化ソフトウェアをインストールし、これらと相性問題を引き起こさない二重化UPSを組み込んでオールインワンで販売する形態をとることにしました（以上、佐野氏）」。 そして、これらのハードウェアはすべてクラスタ構成を標準としている。他社の例を見ると、信頼性を高めるためのクラスタ構成はオプション扱いであるのが一般的だが、IBMはクラスタ構成としなければ販売すらできないようになっている。佐野氏は、この理由を次のように説明する。 「ストレージ仮想化製品が止まってしまったことを想像してみてください。ストレージ全体のサービスが停止し、データにまったくアクセスできなくなります。まさに企業にとって一大事であることは明確です。したがって、ストレージ仮想化製品が絶対に止まらないことを本気で考えますと、ストレージ仮想化製品のクラスタ構成を標準とするしかありません。だからこそ、SVCは2台単位、SFSは2台以上という形で販売するようにしています（佐野氏）」。
■ ストレージ仮想化によってストレージ容量管理が簡素化される まず、ブロックレベルのストレージ仮想化は、仮想ストレージエンジンであるSVCによって実現される。SVCは、サーバーとディスクサブシステムの中間に配置されるため、ストレージ仮想化機能を搭載したファイバチャネルスイッチとして振る舞うことになる。前編ですでに解説したように、サーバーと物理ディスクは、SANを導入したとしても依然として一対一の関係にある。サーバーに物理ディスクが直結されている場合、サーバーのアプリケーションによって物理ディスクの使用率も大きく左右されるが、SANの上であっても、この一対一関係が維持される現状では、やはり物理ディスクの使用率に大きなばらつきが生じてしまう。 また、現在使っているディスクサブシステム（旧ディスク）に新たなディスクサブシステム（新ディスク）を追加した場合、多くのケースでは旧ディスクの使用率が高いまま維持される。つまり、せっかく新ディスクを追加しても、ディスクの使用率がまったく平準化されないわけだ。これは、旧ディスクから新ディスクにデータを移し替えることがテクノロジ的に不可能だからではない。データを移し替えると、運用上困ることが多いからなのだ。 例えば、Dドライブという旧ディスクのボリュームにあったものをEドライブという新ディスクのボリュームに移すことを考えてみよう。ファイル名に変更はないので、ドライブレターの変更は大した問題ではない気がする。しかし、ファイル名を完全修飾した形で表現すると、ファイル名の先頭にはドライブレターとディレクトリ名という修飾子（qualifier）が付加される。つまり、ドライブレターの変更はファイル名の変更にも等しい操作なのだ。このため、複数のユーザーがデータを共用する環境では、運用上のトラブルが発生しやすくなる。 一方、メインフレームにはカタログが存在する。ファイルが移動しても、ボリュームの変更を管理できるインデックスがあり、それを複数のメインフレームで共有することにより、どこに移動したかが分かる仕組みとなっている。しかし、オープン系システムは、もともと個人で使用するという発想からディレクトリ階層を設計した経緯があり、ボリュームの変更を一元的に管理する術がない。
例えば、10台の物理ディスクがあった場合、従来はそれぞれの物理ディスクから必要なボリュームを切り出して使っていた。しかし、空き容量をきれいに使い切ることは難しく、それぞれの物理ディスクには、もはやその他の用途に使えないような中途半端な空き容量が残される結果となる。これらの端数を組み合わせたボリュームは作成できないので、大きなボリュームが必要になったら、新たに物理ディスクを追加するしかない。したがって、ストレージの管理者は、こうした無駄ができる限り生じないように、注意深くボリュームを管理しなければならない。 そこで、SVCによって物理ディスクを束ねれば、単一の仮想ストレージプールから必要なボリュームを自由に切り出せるようになる。単なる足し算と引き算だけでボリュームを管理できるため、ストレージの管理者はそれぞれの物理ディスクの空き容量に気をとらわれないで済む。これにより、ストレージ容量管理が簡素化される。また、異なる物理ディスクの使用率を平準化し、ストレージの使用効率を大きく高められる。さらに、データの分散配置によって、特定の物理ディスクに対するアクセス集中（ホットスポット）を防ぐことも可能だ。 「従来の物理ディスク環境では、一般的にストレージの使用効率が50％以下となります。つまり、投資の半分を捨てているわけです。だからといって、ディスクの使用率を極端に高めてしまうと、データの一時的なオーバーフローによってシステムが停止する可能性があります。したがって、75～85％くらいが適切な使用率であるといえます。ディスク容量は年々増えている関係で、最適な使用率は高くなる傾向にありますが、現時点では80％くらいが最適です。ストレージ仮想化を導入すれば、そこに向けて投資効率を高めることができます（佐野氏）」。
■ ディスクアクセスのパフォーマンスチューニングが容易になる SVCは、冗長化のために2台1組で使用されるが、このペアを2組、つまり合計4台を連携させることが可能だ。すべてのSVCは“家族”であるため、あるSVCにストレージ仮想化の設定を定義すると、他のSVCにもその情報が自動的に伝わる。これにより、仮想ストレージプールの範囲を広げることが可能だ。将来的には、セット数の拡張も予定している。「4台2組で初期バージョンを発売しましたが、これでも足りないというお客様がすでに現れています。このため、近い将来には、現在の2倍（8台4組）、4倍（16台8組）くらいに拡張したいと考えています。具体的な台数については現在検討中です（佐野氏）」。ただし、仮想ストレージプールの範囲を広げられるからといって、単一のストレージプールをそのまま使用するとは限らない。例えば、人事、営業、総務、経理といった感じでプールを分けたいとか、遅いディスクと速いディスクでプールを分けたいといった要望もあるだろう。そこで、SVCは“マネージド・ディスク・グループ”という形で仮想ストレージプールをグループ化できるようになっている。ユーザーは、これらのマネージド・ディスク・グループから好きな領域（VDisk、仮想ディスク）を確保し、SVCのどれかによってこれを有効にすればよい。 SVC間では、実データを移動することなくVDiskの移動も容易に行える。この機能は、ディスクアクセスのパフォーマンスチューニングに応用できる。例えば、1組のSVCで2つのサーバー向けのVdiskがそれぞれ管理されていたとする。キャッシュアルゴリズムは日々進歩しているが、そのベースとなるアルゴリズムは30年以上も変わらないLRU（Least Recently Used）だ。LRUとは、よく使われるデータや最近使われたデータの優先順位を高めるアルゴリズムである。 したがって、片方のサーバーでデータベースのようなI/Oのきわめて多いサービスが実行されていると、そのサーバーによってキャッシュが占有されてしまう。この結果、もう一方のサーバーではキャッシュがヒットしなくなり、ディスクパフォーマンスが極端に低下する。このようなケースでは、VDiskを管理するSVCをもう1組へと切り替えればよい。こうすれば、もう1組のSVCが持つキャッシュを利用してディスクアクセスを行えるため、I/Oの多いサーバーやストレージに足を引っ張られなくなるのだ。
■ 異なる種類のディスクサブシステムでも高速コピー機能を実現可能 IBMのディスクサブシステムであるESSやFAStTは、FlashCopyと呼ばれる高速コピー機能を搭載している。FlashCopyは、ディスク間でメタ情報のみを先にコピーし、そのあとバックグラウンドでゆっくりと実データをコピーする機能だ。サーバーからはコピー元からコピー先へと瞬時にデータがコピーされたように見えるため、バックアップ処理によるアプリケーションの停止を最小限に抑えたり、テストコピーを容易に作成したりできる。SVCを導入すると、この高速コピー機能をさらに拡張できる。FlashCopyは、ESS間、FAStT間といったような同一の筐体間で行われるのが原則だが、SVCを導入することで、SVC内のディスク間、SVCをまたがるディスク間での高速コピーが実現される。これにより、異なる種類のディスクサブシステム間への高速コピーも可能になる。 例えば、高速で安定性の高い1億円のディスクサブシステムがあったとする。このディスクサブシステムのバックアップをとる場合、通常の高速コピー機能ではバックアップ用エリアとしてまったく同じぶんだけの容量を追加で搭載した筐体を用意しなければならない。つまり、合計2億円ものコストがかかってしまうわけだ。しかし、バックアップだけのために高価なディスクサブシステムを導入する必要性はない。 そこで、SVCを導入すれば、バックアップ先として安価なディスクサブシステムを選択できるようになる。例えば、このディスクサブシステムが3000万円だとしたら、合計1億3000万円で済む計算だ。だったら、同じ2億円を出すことを前提に、3000万円のディスクサブシステムを3台導入すれば（合計1億9000万円）、3世代のバックアップをとれるようになる。「3世代もバックアップをとれたらテープはいらないのではないか、と本気で考えている人が世の中にはたくさんいます（佐野氏）」。
■ ＵＲＬ 日本アイ・ビー・エム株式会社 http://www.ibm.com/jp/ ■ 関連記事 ・ 日本IBMに聞くストレージ仮想化の効果的な活用法 [前編]（2004/03/29） ・ 日本IBMに聞くストレージ仮想化の効果的な活用法 [後編]（2004/03/31）
（ 伊勢 雅英 ）
|
|
|
|
|
|
|