• POST

SDSの分類 – 特別なノードの存在 –

SDSの分類 – 特別なノードの存在 –

今回は、前回の記事で紹介したSDSマッピング表の中でもIzumoFSの含まれるSBS-SW(Software Based Storage)について掘り下げていきます。

SDS Mapping
SDS Mapping Graph
Source: Techno Systems Research Co., Ltd.

汎用サーバで分散ストレージを構築する、ということがSBS-SWの製品にほぼ共通するコンセプトとなっています。前回の記事でも少し触れましたが、分散ストレージは従来型のストレージと比較して、可用性と拡張性の高さを基本的な特徴としています。

SBS-SWの中での分類

では、これらの似た特徴を持つ製品を分類するための本質的な違いとはなんでしょうか。たとえばクラウドサービスとの連携や拠点間クラスタ、重複排除方式などは弊社含めベンダーによってアピールされることの多い機能ではありますが、製品そのものの性質を分けるものとはいいがたいように思えます。一般的な分類方法があるわけではないので、ここでは1つのアイデアとして、クラスタを構成するノードの役割分担に着目してみたいと思います。ノードの役割分担の直接的な結果として、各プロトコルへの対応方法も決まってきます。

SBS-SWでストレージをつくる際に必要とされることのある典型的なノードを以下に示します。

  1. データの保存を行うストレージノード
  2. メタデータのみを扱うノード
  3. 構成や監視を行うノード
  4. データの受け渡しを担当するコネクタ
  5. 特定のプロトコルを扱うゲートウェイ

(1)のストレージノードに相当するものはどの製品でも存在します。それ以外の特別な役割を持つノードを用意する必要があるか、用意する場合には物理と仮想どちらの形態をとるか、といったことは同じSBS-SWとはいえ製品によってまったく異なっています。本記事においては単純化のため、特別な役割を持ったいくつかのノードにより構成される製品と、ストレージノードのみで構成される製品という二通りに分類してみます。

特別なノードが存在する製品

役割毎にノードが分かれている構成というのは開発者の立場から見れば実装がしやすいという面もありますが、実際的には製品の出自に影響を受けている部分が大きいといえます。たとえばオブジェクトストレージが元となっているものであれば、CIFS/NFSを利用する場合などには専用のゲートウェイが必要となることが多いようです。

ここで注意しなければならないのが冒頭で挙げた分散ストレージとしてのSBS-SWの特徴である、“可用性と拡張性の高さ”です。実は上述のゲートウェイも含め、ストレージノード以外の特別なノードはこの“可用性と拡張性の高さ”という特徴を持っていない場合があります。一例を挙げると、SDSを使用した経験のあるIT担当者の方から不満点として指摘されることとして「どうしてもゲートウェイにアクセスが集中し、性能と可用性のボトルネックになってしまう」といったものがあります。

ゲートウェイ、コネクタのあるシステム

この部分はSDSベンダー各社の工夫のしどころでもあり、各種のノードそれぞれに“可用性と拡張性の高さ”を持たせている製品もあるようです。ただし、ゲートウェイに限らず特別なノードを用意する必要がある場合、その分ノード数が増加しハードウェアコストやラックスペースが必要になり、構成も複雑になることで構築と運用の手間がかかかるため、結果としてイニシャルコストとランニングコストの両面でデメリットが出てきます。

特別なノードが存在しない製品

一方で特別なノードが無く、ストレージノードのみで構成された純粋なP2Pアーキテクチャを持つ製品もいくつか存在します。このような構成であれば、アクセスがどこかに集中することもなく、ノード数も最小限に抑制でき、構成も単純でわかりやすくなると予想できます。

ゲートウェイ、コネクタのないシステム

ただし、当然ながらこの場合にはストレージノードが先に挙げた各種の役割を持っている必要があります。理想的には以下のような要素が揃っていることが求められるのではないでしょうか。

  • それぞれのストレージノードがデータとメタデータを持つ
  • ノード数に依存しない可用性と拡張性を持つ
  • オブジェクト/HDFS/CIFS/NFS/iSCSIといった各種のプロトコルをゲートウェイ無しに扱うことができる
  • 互いに構成や監視を行うことができる

上記の項目は定量的な判断が必要なものも含まれており、単純なマルバツで評価することは難しいのですが、すくなくとも2015年10月の時点において上記のすべての要素を満たすSDS製品は存在しないと思われます。これらの要素すべてをストレージノードに実装することは困難であり、「特別なノードが存在しない製品」を検討する場合には、上述のどの要素をどのような水準で“特別なノード無しで”実現しているのかを要件に合わせて調査することが重要です。基本的には特別なノード無しで使用できるが、特定の用途においては特別なノードが追加で必要となるといったケースも想定されます。

IzumoFSの実装

ここまででお気づきとは思いますが、IzumoFSは後者の特別なノードが存在しない構成をとっています。基本的な設計方針として“シンプル”であることを掲げており、今のところオプションでの特別なノード等の提供も行っていません。先に挙げた要素の中では、オブジェクト/HDFS対応以外はおおむね満たしていると考えています。IzumoFSの製品の出自として、「FS」とついていることからもお分かりいただける通り、分散ファイルシステムが元となっています。ファイルサーバとしての利用を指向してつくられていることもあり、CIFS/NFS/iSCSIであれば各ストレージノードが直接扱うことができます

3つのプロトコルをネイティブに扱う

機能比較という文脈においてはあまり取り上げられることのない部分ではありますが、実はこのような“ノードの役割分担”こそが各製品の特徴がもっとも色濃く反映されているといえるかもしれません。性能、可用性、拡張性、管理性などに幅広く影響する要素なので、SBS-SWの製品を比較する際には、利用したいプロトコルと合わせて“ノードの役割分担”を確認することをおすすめします。