2016年3月31日

ブロードバンドタワーで Scality RING を担当しているポールです。
(漢字で書く本名よりも、ストレージ業界の一部ではニックネームのほうが通りがよいので、TOEブログではニックネームを使うことにします。)

目次

自己紹介およびブログの方向性

私自身は通算で20年近く、エンタープライズ環境で利用されるリレーショナルデータベースや、SAN/NAS ストレージに関する SE 業務に携わってきました。データベースはデータの保存先としてストレージ機能を必要とするので、両者には密接な関係があります。私は過去の経験から、アプリケーションがストレージを利用する際に何を気にしなければいけないのか、それなりにわかっているつもりでした。しかし残念なことに、Scality RING はオブジェクトストレージ機能がベースのため、従来のSAN/NASストレージとは勝手が違い、私の SE 経歴はあまり参考になっていません。製品については1から勉強している最中で、やればやるほど大小様々な発見があり、未体験ゾーンに突入しています。ブログでは、Scality RING そのものについて大枠から取り上げるだけでなく、日々の業務の中で得られた私の発見の中から、読者の皆様に興味を持っていただけそうなものについても、小ネタとして取り上げていこうと考えています。

今回は Scality RING 関連の初回なので、大枠から、Scality RING の概要をできるだけわかりやすく書いてみることにします。

Scality RING とは?

製品名について

製品名と社名

Scality RING (以降 RING) は、Scality 社が開発・提供しているストレージのソフトウェアです。実はこの一文にも突っ込みポイントがありまして、社名の文字列が製品名の一部に含まれているので、Scality という言葉が社名を指すのか製品を指すのかは文脈によって変わってしまいます。会話であれば、どちらの意味にとられても最終的には意味が通じる、いわゆる結果オーライなことも多いのですが、ブログは読み物なので、その辺りがわかりにくくなる場合があります。このため本ブログでは、ソフトウェア製品を指す場合は 「RING」、社名を指す場合は「Scality 社」と表記することにします。

製品名の由来

製品名の由来は、システム構成図を見ていただくと一目瞭然です。下図の左側にある、データを格納する役割のサーバ(Storage RING と書かれている部分:以降ストレージサーバと表記)を見てください。これらのサーバが、まさに「RING = 輪」を構成するように動作します。RING が輪を構成することについては後ほど説明しますが、名は体を表し、逆もまたしかり、ということで、製品の特徴がそのまま製品名になっています。

RING のシステム構成図
RING 全体構成
上図の中央にあるConnectors はクライアントからの接続を処理するコネクタサーバになります。なお上図には含まれていませんが、Supervisor という RING のインストールおよび全体管理を行うためのサーバも必要になります。

製品名とコードネーム

RING が製品名ということもありまして、皆様もご存知と思われる、J・R・R・トールキン原作の『ロード・オブ・ザ・リング』(指輪物語)に関連する名詞がアルファベット順に、Scality 社によって製品のコードネームに選ばれています。最初のリリースは Aで始まる Aragon(アラゴルン) 、2016年3月時点の最新バージョンでは、Lorien (ロリアン)が使用されており、既に L まで来ていることになります。過去のバージョンでは Gandalf (ガンダルフ)や Frodo(フロド) のような3部作の映画を見た方ならご存知のものから、Khamul や Jago のようなどういう意味なのか調べてもすぐにわからないものまであります。

RING の特長

さて、話を指輪物語から RING に戻します。RING はストレージを構成するソフトウェアなのですが、ストレージというと、ハードディスクを大量に搭載したハードウェアを想像されるかたが多いと思います。しかし、Scality 社は RING を動作させる専用のハードウェアを開発していませんし、販売もしていません。Scality社から提供されるのはソフトウェアだけなので、RING を動作させるハードウェアは Scality 社以外のベンダーから調達する必要があります。幸いにも RING にはハードウェア認定リストのような動作保証の縛りがなく、一般的な x86サーバを用意すれば動作しますし、Scality社からサポートされます。

RING にはたくさんの特長があるのですが、今回はブログの初回ということもありますので、以下のものに厳選して紹介することにします。

  • Linux が動作するx86サーバを複数台用いて構成するストレージ
  • 数十ペタバイトを越す超大容量ストレージの構築が可能
  • 可用性と拡張性に優れたストレージで、無停止運用を実現可能
  • オブジェクト接続や NAS 接続など、複数の接続方法をサポート

それぞれの項目をもう少し深く掘り下げてみましょう。

Linux が動作するx86サーバを複数台用いて構成するストレージ

RING はあくまでもストレージとして動作するアプリケーションになりますので、OSカーネルを代替する機能は含まれていません。サーバのOSとしては Linuxを用意します。RINGが動作をサポートしているのは CentOS/RHEL, Ubuntu, Debian(Debianのみ一部機能だけをサポート)になります。RINGをインストールするには最小で7台(ストレージサーバ 6台、Supervisor 1台)のLinuxサーバを用意する必要があります。クライアントからの接続方法によってはコネクタサーバを必要な数だけ追加します。RINGを動かして動作確認するだけであれば、すべてのサーバを仮想サーバで用意することも可能ですが、ストレージとしての実運用には残念ながら耐えられません。運用環境の場合は、必ずストレージサーバを物理サーバで個別に用意してください。また、コネクタサーバも I/O 性能要求次第では物理サーバで用意することになります。Supervisor に関してはRING全体の管理に特化した機能なので、よほどの大規模環境でない限り、仮想サーバで大丈夫です。

数十ペタバイトを越す超大容量ストレージの構築が可能

RING を構成するストレージサーバの台数には上限がありません。サーバ数に上限がありませんので、サーバ数百台の規模で構成されるRINGを構築することが可能です。計算を単純にするために、サーバ1台辺り100TByteの容量を搭載していると仮定すると、サーバ200台で20,000TByteになりますので、RING 全体ではざっくり20PByte ということになります。もっと容量が必要であれば、サーバ1台辺りの搭載容量を増やして構成してもよいですし、更にサーバ台数を追加することでも対応できます。近年は1台のサーバで大量のHDDを搭載可能なモデルが出てきていますので、少ないサーバ台数で超大容量のストレージを構成することも可能になります。

可用性と拡張性に優れたストレージで、無停止運用を実現可能

可用性と拡張性を実現するにあたり、RING のストレージサーバは Chord アルゴリズムに基づいて実装されています。データは割り当てられたキー値に基づいて複製もしくは分割されてから、各ストレージサーバに分散配置されます。ストレージサーバが異常停止してしまった場合や、ストレージサーバが追加される場合は、Chord アルゴリズムに基づいて、データを格納するストレージサーバが自動で変更されます。このようなアーキテクチャを採用することで、長期間に渡ってストレージ全体を停止させることなく運用することが可能になっています。(なお Chord アルゴリズムそのものについて、このブログでは説明を割愛します。興味のあるかたはインターネット上の公開文書を検索および参照してください。)

オブジェクト接続や NAS 接続など、複数の接続方法をサポート

RING は元々メールサーバ用のオブジェクトストレージとして開発されたソフトウェアであるため、オブジェクト接続(REST)は非常に得意とする接続方法です。それだけでなく、クライアントOSから利用する場合には CIFS, NFS 等の NAS 接続もサポートしています。RINGには、接続方法に対応したそれぞれのコネクタ機能が用意されており、多くの場合は接続方式ごとに異なるコネクタサーバを用意して動かします。このため、複数の接続方法で1つのRINGに接続する場合には、コネクタサーバを必要な数だけ用意することで柔軟に対応できます。また、クライアント台数増等の理由によりコネクタサーバの処理能力が不足する場合には、同じ接続方法のコネクタサーバを増やすことで、やはり柔軟に対応できます。

いかがでしょうか。Scality RING は上記のような特長をもった多機能なストレージソフトウェアです。今後もTOEブログでは様々な観点から RING の魅力や可能性について、皆様にお知らせしていきたいと思います。ご期待ください。

本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。

投稿者: ポール

ブロードバンドタワーで Scality RING を担当。ストレージ業界の知り合いからはポールと呼ばれているが、本人も由来はよくわからない。得意領域はデータベースとストレージ。