プライベートクラウド環境向けオブジェクトストレージ製品「Scality RING」の評価レポート
本コラムでは、Scality RINGによるプライベート環境でのオブジェクトストレージサービス提供を想定した検証内容について解説します。
背景
近年、Web/メール関連サービスを構成するシステム基盤として普及していた「オブジェクトストレージ」という技術要素が、公共およびミッションクリティカル分野でも少しずつ注目されてきています。
オブジェクトストレージは、パブリッククラウド型オブジェクトストレージであるAmazon S3の登場をきっかけにその存在が認識され、格納できるファイル数やデータサイズには理論上制限がないことから、AIやビッグデータ基盤などで導入が先行しています。
このような背景から、プライベート型のオブジェクトストレージ製品は、高度なセキュリティや安定稼働を求めるユーザーから今後需要の拡大が見込まれると想定し、プライベートクラウド型オブジェクトストレージの「Scality」の製品評価を実施しました。
Scality RINGについて
Scality RINGは、汎用的なx86 IAサーバーのLinux環境で動作する、エクサバイト規模の拡張性をもったスケールアウト型のソフトウェア・ディファインド・ストレージ製品です。
オブジェクトストレージでは約6年以上前から国内の大規模環境における導入およびサポート提供実績があり、多くの企業とパートナーシップを締結するなどの安定性があることから、公共などのミッションクリティカル分野で要求される品質やサポートレベルの提供が期待できる製品です。
Scality社について
開発元のScality社は、2016年から5回連続で、ガートナー Magic Quadrant for Distributed File Systems and Object Storageでリーダーの1社と位置付けられています(*)。グローバルではもちろん、国内でも大手企業への採用実績が豊富な製品です。
Scality RING構成概要
Scality RINGは、ストレージサーバーと呼ばれるデータノード、コネクターと呼ばれるアプリケーションとの通信をつかさどるノード、Supervisorと呼ばれる管理ノードにて構成されます。
ストレージサーバーは、最小6ノードの分散型のストレージ クラスタを構成し、ニーズの増大に応じて、実質無制限に容量の拡張が可能です。
ストレージ クラスタのアップグレード、スケールアウト、ハードウェア交換は無停止で可能なため、信頼性と可用性に長けています。
コネクターは仮想マシン上でも実装可能で、ストレージに対するI/O性能やクライアント接続数によってはコネクターのスケールアウトやスケールアップも可能です。
Scality RINGは、S3などのオブジェクトアクセスだけでなく、NFSやSMBなどのファイルアクセスなど、多数のプロトコルに対応しているため、さまざまなシステム、アプリケーションとのシームレスな連携が可能であることが特長です。
また、Active Directoryと連携可能な、AWS IAM互換のアクセス管理機能も実装しています。これにより、オンプレミス環境で、Active Directoryと連携したS3互換のオブジェクトストレージ環境を構成することができます。
今回当社では、オンプレミス環境でScality RINGを構成し、S3アクセス機能を中心とした評価検証作業を実施しました。
図1: 構成イメージ
1. 検証実施概要
検証実施にあたり、Scarity RING 7.4.7.0の環境を構築した。
RINGはHPE ProLiant DL380を最小の6ノード構成で構築し、コネクターサーバーであるScality SupervisorはVMware vSphere 6.7基盤上で稼働する、RHEL7.8をインストールした仮想マシン上に配置した。
図2: 検証環境物理/論理構成
上記にて構築した検証環境上で、オブジェクトストレージとしての基本機能(バケット、オブジェクトの操作、ユーザー管理機能の確認、S3互換性確認)および、実運用を想定し、スケールアウト、バージョンアップ、疑似障害発生時の動作確認などを実施した。
分類 | 項目 | 検証目的 |
---|---|---|
基本機能 | <パケット操作> | オブジェクトストレージの基本機能であるパケットの操作全般、およびメタデータの付与、検索、アクセスコントロールが正常に機能するか検証を行う。 |
<オブジェクト操作> | オブジェクトストレージの基本機能であるオブジェクトの操作全般、およびメタデータの付与、検索、アクセスコントロールが正常に機能するか検証を行う。 | |
<認証> | ユーザー管理のための基本操作全般、およびアクセス管理に必要なユーザーポリシーが正常に機能するか検証を行う。 | |
運用 | <データ保護> | 適切にデータ保護され、リカバリーすることができるか検証を行う。 |
<バージョンアップ> | バージョンアップ動作および所要時間、バージョンアップ中のクラスタ動作への影響を確認する。 | |
<障害(ハードウェア/ソフトウェア)> | システムの設計や要件で想定されている障害に対し、システムが正しく動作すること、意図しない動作や新たな障害が発生しないかの検証を行う。 |
表1: 試験実施概要
2. 検証実施内容
2.1 基本機能
本項では、Scality RINGの一般的なオブジェクトストレージとしての動作と、Amazon S3との機能差異を確認した。
No. | 分類 | 項目 | 概要 |
---|---|---|---|
1 | CLI | AWS CLI | コマンドを使用してサービスとやり取りするためのオープンソースツール。 ブラウザーベースで提供される機能と同等の機能を実装するコマンドを実行可能。 |
2 | API | S3 API | APIレベルのアクセスを提供し、複数のリクエストにまたがるような処理が可能。 Scality RINGでは、AWS S3 APIと互換性のあるAPIを提供する。 |
3 | GUI | S3 Browser | Scality RING標準実装のGUIツール。 WEBブラウザーからパケット・オブジェクトに対し基本的な操作が可能。 |
S3 Console | Scality RING標準実装のGUIツール。 WEBブラウザーからユーザーアカウント管理が可能。 |
表2: 利用ツール一覧
バケット/オブジェクトの操作などの、基本的なS3互換のオブジェクトストレージとしての機能については、AWS CLI、S3 APIやS3クライアントツール(S3 Browser)などからも操作が可能であった。
また、IAM互換のアカウント管理機能については、AWS CLI、ScalityのS3管理ツール(S3 Console)から操作や設定が可能であった。
S3とScality RINGの機能比較は以下の通りとなる。
機能 | AWS S3 | Scality RING |
---|---|---|
パケットへのタグ付け | 〇 | ー |
オブジェクトへのタグ付け | 〇 | 〇 |
タグ検索 | 〇 | 〇 |
ライフサイクルポリシー | 〇 | 〇 |
データ保護 | 〇 | 〇 |
操作通知 | 〇 | 〇 |
WORM | 〇 | 〇 |
バージョニング | 〇 | 〇 |
スナップショット | 〇 | ー |
WEBホスティング | 〇 | 〇 |
アーカイブ | 〇 | ー |
アクセス許可 | 〇 | 〇 |
暗号化 | 〇 | 〇 |
アカウント・ユーザー管理 | 〇 | 〇 |
AD連携 | 〇 | 〇 |
データ使用量の可視化 | 〇 | 〇 |
表3: Amazon S3, Scality RING機能比較サマリー表
Scality RING未実装のS3互換機能は、順次追従して実装されている。加えてISVパートナー(S3アプリケーションベンダ)とのCertificationを順次拡大している。
2.2 運用
本項では、実際の運用を想定した動作の確認を実施した。
2.2.1 データ保護動作の確認
Scality RINGは、データ冗長性を保つ仕組みとして「レプリケーション」と「イレージャーコーディング」の機能を実装している。
図3: データ保護方式
本検証においては、削除したデータの復元および、レプリケーションやイレージャーコーディング機能により、データが分散配置されることの確認を実施した。
No. | テスト項目 | テストパターン | 想定する結果・確認ポイント | 結果 |
---|---|---|---|---|
1 | データ保護 | データ復元 | 削除前の状態に復元できる | 〇 |
レプリケーション | 60KB以下のオブジェクトアップロード時にはレプリケーションになる⇒ ユニークオブジェクト数が1加算され、総オブジェクト数が4加算される | 〇 | ||
イレージャコーディング | 60KBを超えるオブジェクトアップロード時にはイレージャコーディングになる⇒ ・ユニークオブジェクト数が1加算される。 ・アップロードオブジェクトの容量が32MB以下の場合、総オブジェクト数が12加算される。 | 〇 | ||
スナップショット | スナップショット作成時点へ復元できる | 機能実装無し |
※データ保護検証における用語は下記の通り
ユニークオブジェクト⇒オリジナルデータ
オブジェクト⇒分割データ
表4: データ保護動作試験結果サマリー
2.2.2 バージョンアップ
検証環境にて、クラスタ全体のマイナーバージョンアップを実施し、バージョンアップにかかる時間を計測した。
RINGのアーキテクチャ上、クラスタ内を構成するRINGノードは、異なるバージョンが混在可能ではあるが、今回はすべてのRINGノード(6ノード)、コネクターに対してバージョンアップを実施した。
また、今回時間の制約の都合上、クラスタが完全停止の状態でのバージョンアップ実施になったが、本来は無停止でのバージョンアップが可能となっている。
図4: バージョンアップ作業概要
バージョンアップ作業の所要時間は6ノードで2時間程度であった。
No. | 作業内容 | 所要時間 |
---|---|---|
1 | 状態確認、パッチ配置 | 15分 |
2 | Supervisor更新 | 40分 |
3 | ノード更新(6台) | 1時間(同時更新) |
合計 | 1時間55分 |
表5: バージョンアップ所要時間
2.2.3 ハードウェア故障時の動作確認
意図的にハードウェアの取り外しや構成要素の停止などで疑似障害を発生させ、クラスタへの動作影響を確認した。
No. | テスト項目 | テストパターン | 想定する結果・確認ポイント | 結果 |
---|---|---|---|---|
1 | 障害 (ハードウェア/ソフト) | ノード停止 >1-2ノード停止 | 正常に復旧、データ参照ができる。Balanceが正常に機能すること。 | 〇 |
SSD/HDD抜去 >SSD: 1本 HDD: 2本 | 正常に復旧、データ参照ができる。Balanceが正常に機能すること。 | 〇 | ||
Balance ※オブジェクトを「正しい」ノードへ移動させるタスク | Balanceが正常に機能すること。 | 〇 | ||
Rebuild ※レプリカの存在をチェック | Rebuildが正常に機能すること。 | 〇 | ||
Repair(Disk repair) ※他サーバーより復元 | Repairが正常に機能すること。 | 〇 | ||
NW断(SW1-2切替) | 片系断からの切替ができる | 〇 | ||
Supervisor停止 | 停止有無に関わらずオブジェクト操作・参照ができること | 〇 |
表6: 疑似障害試験
上記に示す内容で疑似障害状態を発生させたが、それに伴うRINGの動作への影響はなく、データへの影響もなかった。ディスクの疑似障害に関しては、BalanceやRebuildなどのデータ保護動作が正常に動作したことを確認した。
なお、検証環境において正常動作維持のために許容できる停止ノード数は6ノード中2ノードまでであった。
図5: ハードウェア障害時のSupervisor画面の状態
今後について
当社では、本検証作業で培ったノウハウをもとに、Scality RINGの構築/運用ノウハウの蓄積やソリューション開発に向け、日本ヒューレット・パッカード、スキャリティ・ジャパンと連携し、引き続き検証活動などの取り組みを実施します。
注釈
*Gartner, Magic Quadrant for Distributed File Systems and Object Storage, Julia Palmer et al., 15 Oct 2020
ガートナーは、ガートナー・リサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティング又はその他の評価を得たベンダーのみを選択するようにテクノロジーユーザーに助言するものではありません。ガートナー・リサーチの発行物は、ガートナー・リサーチの見解を表したものであり、事実を表現したものではありません。ガートナーは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の責任を負うものではありません。
- 文中の商品名、会社名、団体名は、各社の商標または登録商標です。