PowerScale In-line Data Reduction編

＊こちらの記事は2020年10月に開催されたAsk The Expert Discover PowerScale からの内容になります。

＊本稿執筆時点ではOneFS9.0 Beta3を元に記事を作成していましたが、OneFS9.2において大きくこの表記方法が変更となり見易くなりました。詳しくはこちらの記事をご覧ください。（2021年6月加筆）

Ask The Expert Discover PowerScaleも２週目に突入しました。

今回はおよそ3年振りのメジャーOS発表となった「OneFS9.0」ですが、目玉機能の一つとなっている

「インラインデータ削減機能」についてのご紹介。

英語で書くとIn-line Data Reductionなわけですが、その頭文字を取ってIDRと略されて呼ばれています。

ちなみにインドネシアの通過もIDR（ルピア）です、関係ないですけど。

さて、一部の方々からは「待望の機能、よっ！待ってました！」という嬉しいお声を頂くのですが、今回はこのIDRの全容を明らかにしていきます。

簡単に言うとこんな感じの機能です。

ファイルをWriteする時に、ファイルを受け取ったノードがデータをぎゅぎゅっと小さくしてくれて、その後冗長データを付与してストレージデバイスに保存してくれる機能です。

そう、何も特別なことをしなくてもいいんです。特別な装置を挟まなくてもいいんです。

ななななんと！PowerScaleには無償でこの機能が付いてきちゃうんです！

それでは、一体どのような技術を用いてデータ削減を実施しているのかを詳しく解説していきましょう。

あらゆるファイルプロトコルが使えるOneFSですが、どのプロトコルを利用しても構いません、あるファイルがどこかのノードに書き込まれたとします。

ファイルを受け取ったノードは、まずOneFSのCoalescerと呼ばれるWriteキャッシュ上にデータを置きます。

通常であれば、そのままパリティ計算がなされて構成されている各ノードにデータチャンクが分散して配置される、という流れになるのですが、OneFS9.0ではこの過程（WritePathといいます）において３つのデータ削減処理工程が追加されています。

Coalescerから流れてきたデータは、

まず、データ削減として”ゼロブロックの排除”を実施します。イメージとしては、

「0000000000000000」のようなデータ配列があったら、「0が16個だよ」というような感じで縮めることができます。ゼロが取り除かれたデータは次の工程へと進みます。

次に、重複排除の処理を実施します。128bit CityHashアルゴリズムによって抽出されたリファレンス情報が各ノードのメモリ上に保管（これをインデックステーブルといいます）されており、同じパターンのデータブロックが過去に書き込まれていないかをチェックしていきます。もし、同じパターンのリファレンスが存在したら、そのデータは重複している（すでに保存されている同じデータパターンがある）ということで重複排除部分を取り除き、最後の工程にデータを送ります。

最後の工程では、データの圧縮を実施します。ここはパフォーマンスを重視していますので、やや軽めの圧縮を実施しますが、実はF810という機種ではこの部分がハードウェアチップによる圧縮を実現しており、より強めの圧縮がかかるようになっているんです。

こうして３つの工程を経たデータは、その後データ保護ポリシーに応じて冗長データが付与され、各ノードに配られるといった仕組みになっています。

ここで、ちょっと着目していただきたい点がこちら ↓

「リファレンス情報が各ノードのメモリ上に保管されており」

重複排除の工程で利用されるリファレンスは、上記の通り各ノードのメモリー上に保持されているのですが、いつリファレンスが作られるのかというと、

・WritePathにおいてDedupeをしている時

・データがReadされる時

の２つのタイミングとなっています。次の図では、Read時にどんな処理を実施しているのかを説明しています。

OneFSは、一度読み込まれたファイルはキャッシュ上に乗っていますが、もしキャッシュにヒットしなかった場合はストレージデバイスからデータを読み取る必要が出てきます。これら一連の流れをRead Pathと呼びますが、この時、データをReadしながらリファレンスを参照し、もし存在していないリファレンスだった場合にインデックステーブルに追加をします。

つまり、OneFSはRead PathとWrite Pathの両方の処理過程においてリファレンスを作成し、重複排除に役立てている、ということになります。

このリファレンスがどれだけ格納できるかというと、デフォルトでは搭載メモリの10%となっており、最大で16GBのインデックスデータを格納できるようにデザインされています。

sysctl efs.sfm.inline_dedupe.index_size_max_exp　→ Default : 34 (ie 2^34 = 16GB)
Sysctl efs.sfm.inline_dedupe.index_size_max_pct　→ Default : 10%

しかしながら、パフォーマンスを優先した結果、メモリ上にインデクステーブルを保持しているということは、「リブートするとクリアされてしまう」ということでもあるので、どうしても重複ブロックの取りこぼしが発生してしまうのです。特に、リブート直後はインデックステーブルにリファレンスが殆ど存在していないので、重複排除率が下がってしまいます。

そこで！OneFSではさらなるオプションであるSmartDedupeが用意されていますので、こちらを併用すればさらなる利用効率向上を図ることが出来るようになります。IDRとSmartDedupeの関係図がこちら。

両方を装備してしまえば鬼に金棒！桃太郎が来ても負ける気がしない！？

(※あくまでも個人的な見解です)

と、ここまで新機能であるIDRを解説してきましたが、実際にどの程度の容量削減が期待できるのか？という点についてご紹介します。

あくまでも目安となりますが、アプリケーションから出力されるデータによって大きく削減率が異なります。この表によれば、利用シーンで一番多いファイルサーバ用途の場合、平均的に25%程度の削減が期待できますね。

注目すべき点は「Pre-compressed data」というところが「全然削減(Saving)できないよ」となっています。これは、JPEGデータやMovieファイル、他にはZIP圧縮されたデータなど、もともと圧縮やデータ削減がされた状態のデータのさらなる削減がほとんど期待できない、という点には注意が必要です。