 |
|||||||
|
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
 |
|||||||||||||||||||||||
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
| ||||||||||||||||||||||||
|
高いスケーラビリティとコスト効率を兼ね備えた3PARのストレージアーキテクチャ |
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
| ||||||||||||||||||||||||
■ 小さく始めて、大きく拡張できる3PAR InSpireアーキテクチャ 現在主流のディスクストレージは、モノリシック型とモジュラー型の2つに分類される。ディスクストレージは、主にチャネルアダプタ、キャッシュ、ディスクコントローラの3つから構成されるが、モノリシック型はこれらのコンポーネントが大きな筐体の中に多数内蔵されている。このため、巨大なストレージ容量や最高レベルのアクセス性能を求める、メインフレーム向けの大規模ディスクストレージで多く採用されている。ただし、構造上かなりコストがかかることから、ディスクストレージ本体も非常に高価だ。モジュラー型は、それぞれのコンポーネントがモジュール形式でひとつの筐体に収まっているもので、主にミドルレンジ以下のディスクストレージで採用されている。通常は冗長化のために2つの筐体を組み合わせ、いわゆるデュアルコントローラとして機能する。このとき、それぞれのコントローラが別々のデータボリュームを扱うことは可能だが、2つのコントローラでひとつのデータボリュームを同時に扱うことはできない。このようにデータボリュームとコントローラの関係が常に一対一となることから、規模を拡張するには新たなコントローラを独立して配置するか、現在のコントローラをより高性能なものに置き換えるしか方法がない。 つまり、モノリシック型は大規模環境に対応できるものの非常に高価、モジュラー型は初期コストこそモノリシック型より安価だが、大きく拡張していくのが困難という問題をそれぞれ抱えている。「ユーティリティコンピューティングの世界でお客様が本当に欲しいディスクストレージとは、モジュラー型のように最小限の規模からスタートしつつ、ビジネスの成長にあわせてディスク容量やアクセス性能をモノリシック型以上に拡張できるものです。そこで、3PARはこれらの要求に応えるディスクストレージの新設計として3PAR InSpireアーキテクチャを開発しました。（スコット氏）」 ■ 広帯域・低レイテンシの独自バスによりストレージクラスタを構成 3PAR InSpireアーキテクチャでは、チャネルアダプタ、キャッシュ、ディスクコントローラからなるコントローラノードが独自開発のASICによってフルメッシュで相互接続され、典型的なクラスタを形成している。ノード数は執筆時点で2～8ノードに設定されており、最大ノード数は製品によって異なる。ローエンドモデルの3PAR InServストレージ・サーバー E200は2ノードのみ、ミドルレンジのS400は最大4ノード、ハイエンドのS800が最大8ノードとなっている。3PAR InSpireアーキテクチャのハードウェアプラットフォーム（3PAR InServストレージ・サーバー）は、物理ドライブ（いわゆるHDD）を提供するドライブシャーシ、コントローラノード、この2つを接続する完全パッシブ型のバックプレーンから構成されている。コントローラノード間は、広帯域（1GB/秒）かつ低レイテンシの独自バスを採用している。こうした高速バスにはInfiniBandのような汎用バスもあるが、スコット氏はあえて独自バスを採用した理由を次のように説明する。 「3PARの独自バスは、汎用バスと比較するとその低レイテンシの度合いが違います。クラスタ化されたストレージでは、すべてのコントローラノードがひとつのシステムのように振る舞わなければならないので、ノード間のレイテンシを極限まで短縮する必要があります。そこで、3PAR自身がクラスターストレージに最適な低レイテンシの独自バスを開発し、それを3PAR InSpireアーキテクチャに採用しました。」
■ データを多くの物理ディスクに広く分散させてアクセス性能を稼ぐ 3PAR InSpireアーキテクチャは、データ配置の手法も非常にユニークだ。従来型のディスクストレージは、物理ドライブを最小の単位として、これらをRAIDによって束ねて論理ドライブ（LUN）を構成する。採用する物理ディスクやRAIDレベルは、アプリケーションが求めるサービスレベルによって選択される。しかし、いくら高速な物理ドライブやコントローラを搭載していたとしても、RAIDを構成する物理ドライブの台数が少なければデータ転送速度やI/O性能を稼ぐことはできない。例えば、従来型のディスクストレージで4台の物理ドライブとRAID 1によってLUNを構成した場合、1台の物理ドライブが毎秒200回のI/Oを処理できるとすると、LUN全体のI/O性能はライトで毎秒400回、リードで毎秒800回しか達成できない。ディスクストレージ全体で毎秒数万I/Oを処理できると唱われている高性能な製品であっても、LUNを構成する物理ディスクの台数が少なければ宝の持ち腐れになってしまうのだ。 これに対し、3PAR InSpireアーキテクチャは、物理ディスクをさらに細かいチャンクレットという単位に分割する。現在、チャンクレットのサイズは256MBに設定されている。スコット氏によれば、多くのアプリケーションにおいて物理ディスクの利用効率とアクセス性能のバランスのとれるサイズが256MBなのだという。このチャンクレットは、構成するLUNのサイズとRAIDレベルに応じて物理ドライブ上から必要な数だけ割り当てられる。 例えば、RAID 1による8GBのLUNを作成する場合、総物理容量は16GBになるので、64個のチャンクレットが必要になる。もし64台以上の物理ドライブが搭載されていれば、すべて独立した物理ドライブからチャンクレットが割り当てられる。従来型のディスクストレージでは4台の物理ドライブで構成されていたLUNを、3PAR InSpireアーキテクチャでは64台の物理ドライブで構成できることになる。つまり、従来型のディスクストレージと比較して最大16倍のI/O性能が得られるわけだ。
■ 仮想ボリュームのサービスレベルを自在に変更できる アプリケーションが直接的に利用する論理ボリュームは、1つまたはそれ以上のLUNから構成される。論理ボリュームのサイズは256MBから2TBだ。3PAR InSpireアーキテクチャは、チャンクレットによる粒度の細かいファイングレイン仮想化技術を採用しているため、3PAR自身はこの論理ボリュームを特に仮想ボリュームと呼んでいる。「3PAR InSpireアーキテクチャは、必要なときに必要なだけの容量、パフォーマンス、可用性を備えた仮想ボリュームを迅速に構成できます。このため、ストレージ管理者は、ボリュームを事前に計画する必要がないのです。（スコット氏）」従来型のディスクストレージは、求められるパフォーマンスや信頼性、コストなどを考慮に入れながら、採用する物理ドライブの種類、RAIDレベルを事前に決め、論理ボリュームを作成しなければならない。永続的にその論理ボリュームを使い続けられるなら、こうした計画は初回だけですむが、実際にはサービス内容の変化に伴って最適な論理ボリュームの構成も時々刻々と移り変わっていく。 もし、論理ボリュームの構成を変更するときには、論理ボリューム内のデータをいったん別の場所に待避させ、論理ボリュームを再構成し、データを復元するといった手順を踏まなければならない。こうしたデータ移行作業にはかなりの時間がかかり、当然のことながらその間のサービスは停止してしまう。一方、3PAR InSpireアーキテクチャでは、サービスレベルの異なる仮想ボリュームへの変換は、オンラインかつ無停止で実行可能だ。その作業は15秒ほどで完了する。 ■ 運用コストとサービス品質のバランスを最適化する3PAR Dynamic Optimization
新規のビジネスを立ち上げたとき、当然のことながら将来の行く末は分からない。だからこそ、最小のコストで小さく始めたいと思うのが顧客の心理だ。そこで、最初は小容量かつブロンズグレードからスタートする。そして、ビジネスが軌道に乗ってきたら、より大規模で高品質のサービスを提供できるシルバーやゴールドへとアップグレードしていく。ここで、3PAR InSpireアーキテクチャなら、3PAR Dynamic Optimizationによってオンラインかつ無停止にてグレードを自在に変更できる。 しかも、このグレード移行は年間のアクセス負荷と連動することも可能だ。例えば、贈答品をオンラインで販売するサイトでは、クリスマスのようなホリデーシーズンにアクセスが急増しやすい。したがって、普段はシルバーで運用しておき、ホリデーシーズンだけはゴールドにアップグレードすれば、最小限の運用コストで最大限のサービス品質を維持できるようになる。 「今後は、さらに進歩した3PAR Adaptive Provisioningも登場します。3PAR Adaptive Provisioningは、データの使用状況パターンをもとにデータの格納場所を自動的に最適化するものです。複数のサービスレベルに基づくデータの格納場所を用意しておけば、あとはそれぞれのデータが自動的に最適な場所に配置されます。しかも、これらの作業はサブボリュームレベルで行われますので、単一の論理ボリュームでありながら、その中のデータは異なるサービスレベルの格納場所に分散されることになります。3PAR Adaptive Provisioningの実用化は2007年を目標としています。既存の3PAR製品でもOSアップデートを通じて3PAR Adaptive Provisioningに対応できるようにする予定です。（スコット氏）」 ■ 物理容量の無駄を徹底的に省く3PAR Thin Provisioningや3PAR Virtual Copy
これに対し、3PAR Thin Provisioningは、アプリケーションからは大きな容量に見せつつも、必要最低限の物理容量のみを割り当てる。アプリケーションに対して余裕を持たせたストレージ容量さえ割り当てれば、その後はアプリケーションがデータを書き込み、より多くの物理容量が必要になった時点で必要なだけの物理容量を購入すればよい。こうすることで物理容量の余剰、すなわち無駄な投資を最小限に抑えられる。 そして、この3PAR Thin Provisioningの延長線上にあるスナップショット技術が、3PAR Virtual Copyだ。3PAR Virtual Copyはcopy-on-write方式によるユニークなスナップショット技術で、ベースボリュームもしくは他のスナップショットから数百のリードおよびライト可能なスナップショットを瞬時に作成する。このとき、他のスナップショット技術のようにスナップショット領域を確保する必要がない。 他社のスナップショット技術を例にとると、一般にスナップショット領域はベースボリュームの20％程度を確保するように推奨されている。1TBのベースボリュームに対してスナップショットをとる場合には、200GBのスナップショット領域を確保しなければならないわけだ。しかし、スナップショットの記録に10GBしか使われていないとしたら、残りの190GBは無駄になってしまう。 これに対し、3PAR Virtual Copyは、スナップショット領域を確保する必要がない。データが新たに書き込まれたり、書き換えられた部分だけを差分として抽出し、これをスナップショットとして単に記録するだけなのだ。必要な物理領域はスナップショット本体のみであり、スナップショットの総容量が10GBであれば、その10GBしか物理容量を消費しない。3PAR Thin Provisioningと同様に、ストレージの物理容量を過剰に用意しなくてもよいので、無駄な投資を最小限に抑えられる。 3PAR Virtual Copyは、最小限の物理容量で細やかにスナップショットをとれることから、ちょうどCDP（Continuous Data Protection）のような機能を顧客に提供できるという（CDPの詳細は自由な地点へとデータをリカバリできる最新のデータ保護技術「Continuous Data Protection」を参照）。3PAR Recovery Manager for Exchangeや3PAR Recovery Manager for Oracleといった特定アプリケーション向けのデータ保護ソリューションも用意されており、これらのソフトウェアとリモートコピー機能（3PAR Remote Copy）を組み合わせることでディザスタリカバリー環境も構築可能だ。 ■ ＵＲＬ 3PARdata株式会社 http://www.3par.jp/ ■ 関連記事 ・ 米3PARの新ストレージソフト、サービスレベルの動的な最適化を実現（2005/05/27） ・ 3PAR、シン・プロビジョニング機能を搭載したミッドレンジ向けディスクアレイ（2006/08/29）
（ 伊勢 雅英 ）
|
