スケールアウト型ブロックストレージの基礎：ストレージ仮想化の体系的理解（3）（1/2 ページ）

1. スケールアウト型ブロックストレージのコンセプト

　前回までは、ストレージ仮想化の全体像をつかんでいただくべく、仮想化技術を分類し、それぞれの種類について概要を説明してきた。今回からは、ストレージ仮想化の中で注目を浴びているトレンドをいくつかピックアップし、詳しい解説を加えていこう。

　今回の記事で取り上げるのは、スケールアウト型ブロックストレージだ。スケールアウト型ブロックストレージは拡張性や管理性において従来のスケールアップ型ストレージにはない利点を持ち、近年非常に注目を浴びている分野である。

　以下では、そのコンセプトについてまず説明し、次節以降で機能と技術の詳細について解説していく。

容量だけでなく性能をシームレスに拡張する

　スケールアウト型ストレージの主な利点の1つは、その拡張性にある。スケールアウト型ストレージは、複数台のストレージ装置を連携させて論理的な1つのシステムとして動かすことができ、装置の追加によりシステムを容易に拡張していくことができるためだ。

　そして、この拡張性の優れている点は、容量だけではなく性能を拡張していけるところにある。

図1　容量だけでなく、性能をシームレスに拡張

　容量だけの拡張性でいえば、従来からあるスケールアップ型ストレージでも対応できるものが多い。ハードディスクが搭載された筐体を多段で追加していくことで、容量的な拡張性は容易に実現できるためだ。

　しかし、スケールアップ型のアプローチではコントローラの数に制限があり、容量とともに性能を拡張していくことはできない。後々の拡張性を確保するために、多数のコントローラを収容できる装置を初めから選ぶという選択肢もあるが、その場合は、初期投資が非常に大きくなってしまうのが難点だ。

　その点、スケールアウト型ストレージでは、複数のコントローラを連携させて1つのシステムとして動かすことができるため、ハードディスクだけでなくコントローラの数も増やすことで、容量と性能をともにシームレスに拡張していくことができる。

　ビジネスの成長に沿ってシステムを拡張していく場合には、容量だけではなく性能の拡張が必要になる。スケールアウト型ストレージの性能面での拡張性を活用することで、最初は最低限の要件を満たす小規模な構成から始めて（スモールスタート）、後日、ビジネスが軌道に乗ってリソースの拡張が必要になったら、それに合わせてシステムを拡張していくというアプローチを採ることができるようになる。

多数のボリュームを効率よく管理するストレージプールを作る

　拡張性に優れたブロックストレージというと、1台のストレージ装置ではさばき切れないほどの巨大なボリュームを作ることを想像されるかもしれない。しかし、スケールアウト型ストレージを使う目的は、そういった巨大なボリュームを作ることではない。

　スケールアウト型ブロックストレージは、ブロックストレージの主な用途である、データペースや仮想マシン用のデータストア等のニーズを想定して作られている。一般的に、これらの用途では、そんなに巨大なボリュームは必要ない。スケールアウト型ブロックストレージを使う目的は、こういった一般的なサイズの多数のボリュームを効率よく管理する基盤となる「ストレージプール」を構築することにある。

　ストレージプールは、複数のストレージ装置のリソースが仮想化されて作りだされる。これは、仮想マシンを効率よく管理するために、サーバ仮想化でリソースプールを作ることに似ている。サーバ仮想化では、複数の物理サーバのリソースを論理的なリソースプールとしてひとまとめにし、そこから各仮想マシンにリソースを割り当てる。スケールアウト型ストレージでも、複数の物理ストレージのリソースを論理的なストレージプールとしてひとまとめにし、そこから各ボリュームにリソースを割り当てる。

図2　サーバと同様にストレージをプール化

　論理的なストレージプールが構築できると、システムとしての管理性が大きく改善される。物理的な制限に縛られずにリソースを配分したり、サーバ仮想化における「ライブマイグレーション」のように、仮想化されたストレージ装置の間で、オンラインでデータを移動したりすることができるようになるからだ。これらのメリットはサーバ仮想化のメリットによく似ている。

　以下では、このようなスケールアウト型ブロックストレージのコンセプトを支える技術と機能について、「ストレージプールの構成」、「ストレージプールの先進的な管理機能」という2つの章に分けて解説していく。

2. ストレージプールの構成

　スケールアウト型ブロックストレージでは、複数のストレージ装置のリソースを論理的なストレージプールとしてひとまとめにし、そこから各ボリュームにリソースを割り当てていく。この節では、ストレージプールの中身が具体的にはどのような構成をとっているのか、詳しく見ていこう。

ページ単位でのリソース管理

　最初に、ストレージプール内のデータが、各ノード（ストレージ装置）にどういった単位で分散されるのかについて取り上げる。

　単純に考えると、ここでは大きく2つのアプローチがある。1つはボリューム単位でノードに振り分ける方法である。もう1つは、ブロック単位で振り分ける方法である。しかし、このどちらにも課題がある。そこで、スケールアウト型ブロックストレージではページ（ブロックの集合体）単位での振り分けがよく用いられる。以下に詳しく説明しよう。

図3　振り分け単位の種類

　ボリューム単位で振り分ける場合の課題は、そのピースの大きさにある。ボリュームは、一般的には数十GBから数TBの大きさになる。こういった大きなピースを分散しようとすると、データの配置の選択肢がかなり限られる。結果、ノード間での容量バランシングなどのシステム最適化が行いにくくなってしまう。

　また、ボリューム単位での振り分けのもう1つの問題は、各ボリュームのデータを処理するために用いることのできるハードディスクとコントローラの数が少なくなることだ。各ボリュームが単一のノードに格納されるので、そのノードに属するハードディスクとコントローラしか使えなくなる。結果として、ランダムアクセスにおいて、高い性能を引き出しにくくなってしまう。

　一方、ブロック単位はどうだろうか。ブロック単位での振り分けは、上記で述べた2つの問題を解決することができる。まず、ピースがとても小さくなるので、データ配置の選択肢を豊富に持つことができる。これによって容量バランシングなどのシステム最適化がやりやすくなる。次に、各ボリュームに属するブロックを多数のノードに少しずつ振り分けることで、多くのディスクとコントローラを1つのボリュームへのアクセスに使える。これにより、ランダムアクセスの性能を大きく向上させることが可能だ。

　しかし、ブロック単位には大きな問題点が1つある。それは管理のオーバヘッドが大きくなってしまうことだ。ブロック単位の振り分けでは、何らかの制御情報をブロックごとに管理する必要がある。ブロックは非常に細かい単位なので、その制御情報の管理オーバヘッドは非常に大きいものになる。

　そのため、スケールアウト型ブロックストレージでよく使われるのが、ページ単位での振り分けである。ここで、ページはブロックの集合体を指し、ボリュームよりはずっと細かい単位である。ページは、「パーティション」「チャンク」などと呼ばれることもある。

　このようなブロックの塊の単位で分散を行うことで、システムの最適化余地や、ボリュームアクセスに使えるハードディスクとコントローラの数を大きく保ちつつ、制御情報の管理オーバヘッドがあまり大きくならないという丁度よいバランスを保つことができる。

　ページ単位の管理システムは、リソースの分散管理だけでなく、スナップショット、レプリケーション、シンプロビジョニングといったさまざまな他のデータ管理機能にも使うことができ、システムの基盤となる。

ページとハードディスクのマッピング

　前節で述べたように、ストレージプール内のデータは、ページ単位で各ノードに分散されて格納される。本節では、そのページが、ハードディスクにどうマッピングされるかについて取り上げる。

　まずハードディスク側から、ページ単位のリソースをどう作り出すかについて考えてみる。ここには大きく2つの方法がある。1つは、複数のハードディスクで構成されたRAIDグループから作り出す方法である。RAIDグループはページよりもずっと大きなサイズになるので、そこから複数のページを作り出すことができる。もう1つの方法は、1つ1つのディスクを細かい区画に切り分け、それらの区画をいくつか組み合わせることで区画レベルでの仮想的なRAIDグループを作り出し、それをページとしてしまうやり方である。

　このようにしてできたページ単位のリソースを、ストレージプール内の各ボリュームのデータにマッピングしていく。このマッピングは性能や信頼性などを決める大きなポイントであるが、スケールアウト型ストレージでは、多少のカスタマイズは指定できるものの、基本的にはシステム側にこのマッピングを自律的に管理させることが多い。こうすることで、ユーザーから管理負担を取り除くとともに、システム側がたゆまない最適化作業を自動で行うことを可能にしている。

　RAIDグループからページを切り出してくる方法の場合、以下の図のような構成となる。正確には、もっとずっと細かい単位でページは作られるのだが、図解の便宜上、大きなサイズで書いている。

図4　ページとハードディスクのマッピング

　一昔前は、ボリュームのデータがどのストレージ装置に、そしてどのハードディスク（もしくはRAIDグループ）に入っているか、ユーザーが自分で管理することが当たり前だった。ロードバランシングや容量バランシングを適切に行うために必要だったからだ。スケールアウト型ストレージでは、どのデータをどのストレージ装置に、そしてどのハードディスクに入れるのかユーザーは管理する必要がない。管理せずにシステムに任せることで、より進んだロードバランシングや容量バランシングなどの処理が可能になる。