「ファイルシステムキャッシング機能を利用した高速マルチクラスタの実現」
プレゼンター：Senior Systems Engineer, Pre-Sales, T3S　塩入ヶ谷　寛

要旨

はじめに

先程IBMさんからご紹介のあったアクティブファイルマネジメントと呼ばれる技術の詳細な紹介になります。

私はデータダイレクト・ネットワークス・ジャパンの塩入ヶ谷寛といいます。主に担当しているのは、製造、製薬、自動車、通信事業におけるビッグデータ、OpenStack関係、仮想化など、DDN=HPCというイメージがとても大きいんですけれども、私はHPCから派生した実際の自動車屋さんのシミュレーションやビッグデータなどを担当させて頂いています。

今回、AFMのご紹介ということで、主にデータを遠隔地でコラボレーションしたいというご要望に応えることができるのではないかと考えている技術になります。

アジェンダ

・AFMの前提知識
・5つのキャッシュモードは、実際にどういったところでそれが使えるのか
・弊社のラボで行ったAFMのパフォーマンスはどれくらいか（どちらかと言うとAFMのパフォーマンスというよりは遠隔地で遅延があるとどれくらいパフォーマンスに影響するのか）

AFMの前提知識

まずは「AFMとは？」いうのは最初にお話頂いたので、キャッシング機能、キャッシングというのがミソです。キャッシング機能を利用したデータマネジメント機能ということで、主に遠隔地での高遅延、遅延のある環境下で上手くデータを両サイトでコラボレーションしたいという時に、別の遠隔地にあるデータを、よりよく使うものだけでもいいから、速く読み出したり書き出したりするのに利用する機能になります。

もともとGPFS（Spectrum Scaleの旧名称） v3.5からあったんですけれども、AFMという名前になったのはGPFS v4.1からで、弊社もGPFS v4.1になってからAFMの検証をしてお客様にご提案してきています。

GPFSのライセンスは4.x台から新しくExpress、Standard、Advancedというのがありますが、一部Advancedでないと使えない機能があります。あとは、GPFSのマルチクラスタを組んだ時に、グローバルネームスペースができるとか、修正されたデータは全て非同期ですべて転送される形になっています。

距離的に離れたサイト間で上手くデータを転送したり、コラボレーションしたりしたい時に使う機能になっていて、実際にデータをどういう形で転送しているかというと、GPFSのプロトコルで転送するパターンと、NFSを使って転送するパターンというこの2種類から選ぶことが出来る機能になっています。

GPFSを使うともちろんGPFS同士のクラスタでしか連携できないですけれども、NFSを使うことで、他社のNAS製品を高速化したいですとか、遠隔地の他社のNASをより速くバックアップしたいですとか、そういった用途にも使える機能になっています。

用語紹介

Filesetと呼ばれるものは、GPFSの機能を語る上で重要なファクターとなるので、Filesetに関しては、ファイルシステムのサブツリーとして定義します。
ファイルシステムに関しては、rootを頂点としていて、Fliesetに関しては、その下のdirectoryに紐付ける特殊directoryだと思ってください。
Filesetを作成することで、quotaをかけたりだとか、snapshotを取得、これはdirectory単位でsnapshotが取れるというメリットがあります。
あとはFilesetを作ることで、AFMの連携をしたりすることができるようになります。
ここではそのFilesetと呼ばれる特殊directory単位でデータのコラボレーションをする、ということを覚えておいてください。

もう一つ用語として出てくるのが、HomeとCacheという概念になります。
Homeに関しては、データのソースとなるGPFS Filesetと書いてあるんですけども、GPFSである必要はなく、ここはNFS Exportでも大丈夫です。
Homeに関しては実際のデータが置かれている場所だと思って頂ければ良いです。データが貯まっている場所です。
あとここでは他社製のNASでも大丈夫です。他社製のNASでNFS Exportしたものをいわゆるキャッシングして高速に見せてしまうという使い方です。
ただし、他社製のNASの場合は、他社は他社でのファイルシステムがあるので、例えばzfsとかwaflですとか、色々なファイルシステムがありますが、そういったファイルシステムが持っている拡張ACLと呼ばれるもの、ファイルシステム固有で持っているExtended Attributeに関しては、GPFSは対応しないので、注意してください。
POSIXだけのACLでやってもいいよという場合、他社製のNASでも一応マウントして高速化できます。他社製のNASでデータ移行したりバックアップしたりしたいという場合には、お声がけ頂ければどういう形になるかをお見せできると思います。

次にCacheに関してですけれども、Cacheに関してはfile単位で作成されて、Homeの特定のNFS ExportもしくはGPFSのdirectoryと紐づく形になります。このCacheのモードは5つのモードを持っていますので、これは後ほどご紹介します。

もう一つは、Gateway（MDC）これはメタデータコントローラなんですけれども、Gatewayと呼ばれるもので、このGatewayはAFMで扱うデータを転送するサーバです。サーバと書いてあるんですけれども、実際にはroleです。GPFSのサーバにはいろんなroleがあるんですけれども、Gatewayだとか、SNPサーバだとか、Managerとか、そのroleの一つになります。

まずはこのHome、Cache、Gatewayという言葉を、Homeに関しては、データのソース、データが蓄積される場所だと思ってください。Cacheに関しては、実際にFilesetで作成されてHomeと結びつく、ここが速ければ速いほど、遠隔地とのデータのやり取りが速くなるという形になっています。

今回作成した資料は、全て左手がHome、右手がCache、赤い左手がHome、青い右手がCacheという形で作られていますので、これから詳細をご紹介していきます。

5つのキャッシュモード

まずはAFMにはCacheのモードが全部で5つあります。いわゆるCacheに対してファイルシステムのCacheに対して、どういったアクセスができるかによって、全部で5つ、
「Read Only」
「Single Writer」
「Independent Writer」
「Single DR」
「Local Update」
今回のセッションでは「Local Update」については省かせて頂きますが、これから4つのAFMのCacheのモードについてご紹介していきます。

・Read Only

まず一番わかりやすいのは「Read Only」で、AFMのCacheモードで「Read Only Cache」というものがあります。
実際に皆さんから見て左手の赤い/gpfsの部分に対して通常利用して頂いていて、遠隔地のクラスタに対して、そのHomeで使っている領域を、Read Onlyでもいいから速く見せたいというような場合に、Read Only Cachingを使います。
通常現在使って頂いている /gpfsと呼ばれる、例えばHomeにある数PBのデータの一部を、例えばCache、遠隔地が大阪だったらその大阪のクラスタで、Read Onlyでもいいから速く見せたいという場合、こういったRead Cache Onlyというものが使えます。
Read Only Cacheとして例えばサイトAというところで /gpfs/cache と作った場合に、そこに対してclientがアクセスした段階でHomeからデータを持ってくるというような形になります。あとは面白い使い方として、カスケード・キャッシングという、サイトをまたいでRead Onlyでキャッシングするということもできます。

Read Only Cachingを使った場合の利用用途は、配信のソリューションになります。
左側のHomeに例えば1PBのコンテンツを入れて、エディットしたり、エンコーディングしたり、レンダリングしたり、映像系でやるような配信で必要な処理をここでやっておいて、それをそれぞれのdirectoryに対してdelivery1,2,3というような形で分けて置いておく。そうすると、自動的にCacheサイトの方にclientからアクセスがあればデータが転送されていくというような形になります。
Cacheのサイトの方の容量がそれぞれ10TBのSSDしかないんですけれども、Homeは1PBあって、Cacheは10TBです。これはCacheなので、自動的にいらなくなったデータ、メタデータだけを残して、データをどんどん自動的に削除してくれます。つまり、ホットコンテンツ、いわゆるよく使われるデータのみをCacheに置いておいて、使わないデータに関してはずっとHomeに置いてあるという状態になります。
Read Only Cacheで設定した場合には、もちろんRead Onlyですので、コンテンツを配信するdirectoryに対しては一切書き込みは出来ないです。実際の書き込みや編集をするのはHome側で行って、Cache側に関してはすべて配信用、Read OnlyのCacheとして動作します。これが、Read Only Cacheモードの動きです。こういった配信のソリューションでは、一箇所でデータをまとめて、複数のサイトで配信したいような場合に使えます。

・Single Writer

次に、別のCachingモードで、今度はCacheに書き込みたいという場合です。例えば、他社のNAS製品が500TBくらいあり、そこのスピードを上げたいという場合に例えば、CacheとしてSSDのGPFSを持ってきて使いたいという場合に使えるものとなっています。
向かって左側がHomeで、右側がCacheになっています。真ん中の赤い点線を見ていただくと、CacheからHomeに対する矢印というのは一方通行です。Cacheに書いたものは、自動的に非同期でどんどんHomeにpushされます。ただし、Homeで何か変更を加えても、一切Cacheには変更がありません。よって、常に書き込む時には、Cacheに書き込む必要があります。
ただしHomeでは、一応Read Onlyで読み出す分には問題ないですが、Homeに書き込みを行った瞬間に不整合が起こるので、あまりHome側での運用を同時にするというのはお勧めしません。
Single Writer Cacheモードの利用形態というのは、主には、こういった中央バックアップと呼ばれる機能です。右側にあるCacheサイトで、実際のclientはNFSやGPFSやCIFSで運用をします。ただし実際には10TB、20TB、30TBくらいの容量で運用していって、実際にはバックラインに大きな別の、中央バックアップするためのストレージが存在しています。個別でバックアップを取るのではなくて、別のサイトに流してから、中央でバックアップ取ったものを、逆にアーカイブして、テープライブラリやオブジェクトに対してのアーカイブをするということが可能になっています。このCacheに対して書き込みをする、ただし、CacheからHomeに対する書き込みに関しては一方通行、というのがSingle Writerになります。

・Independent Writer

こうなると、Homeの同一領域に対しても、書き込みとか色々できたらな、と思うと思うんですけれども、それを実現するのがAFM Cacheモードの「Independent Writer」になります。
こちらに関しては、Homeも、Cacheも、両方の遠隔地のサイトで、同一directoryに対して、書き込み、読み込みを許可しています。両方のサイトに対して、ReadやWriteはすべて許可しているのですが、完全にクラスタは別になっているので、一切ロックの管理に関してはそれぞれのクラスタ間ではしていないです。よって、同一ファイルを同一時期に触ると、意図しない状態に陥るので、同一のファイルをそのまま書いたり読んだりするのはおすすめしませんが、例えばdirectoryが別れているような使い方です、ロックは管理していないということを意識して使って頂く分には特に問題はありません。

このIndependent Writerを使った場合に、もちろん両方のサイトで運用が出来ますが、もう一つ使える機能としては、Independent Writerモードを使った、いわゆるバーストバッファ、GPFSを使ったバーストバッファになります。皆さんから見て今度は左側がCacheになっているんですけども、実際にはSSDのみで作られたファイルシステム157TBにclientが大量に実際にはぶら下がっていて、そこに書き込んだものが自動的に右側のHomeである4.5PBにどんどん流れていくという仕組みになっています。使わなくなったファイルに関してはmetadataだけを残してCacheからデータは削除されます。これを使うことによって、157TBのファイルシステムと4.5PBのファイルシステム、2つに分かれるんですけれども、それぞれで、高速なキャッシングの方と、低速だけれど大容量のストレージを分割して使うことが出来るようになります。

このIndependent Writerを使う目的というのは、もし例えばSSDの方のファイルシステムが潰れてしまった場合等には、4.5PBの方のストレージだけで運用できるようになっています。これは元々、Single Writerに関しては、バックアップを基にして考えられた機能なのですが、Independent Writerに関しては、いわゆるディザスタ・リカバリを目的として両方の整合性を保つことを目的として使われているものなので、そこで例えばCache側に何か問題があっても、バックアップ側、低速なHome側で運用するためには、Independent Writerを使う必要があります。

ここで、バーストバッファという形で、いわゆる階層化という形になるんですけれども、いわゆるILMやHSMと、Independent Writerの違いになるんですけれども、 基本今まで出てきたGPFSのILMに関しては、ファイルシステムの下に、いわゆるpoolと呼ばれる例えばSSDのpool、ニアラインSASのpool、そういった形でSSDとハードディスクの集合をまとめて1個のファイルシステムで組んでいるのがILMです。データがSSDからニアラインSASに落ちるのはポリシーベース、ポリシーをキープして、それにマッチしたものがどんどんメタデータはsystem poolに残した状態で、ニアラインSASにデータだけを置いていくという形です。ニアラインSASがデータがあるところにアクセスしても、自動的にSSDには戻ってこないで、直接SSDから返しているというのがGPFSのILM、テープは別ですけども、ストレージでやった場合にはそういった仕様になります。ただし、policyを一個作れば、ニアラインSASからSSDに持ってくることは一応可能です。

それに対して、GPFSのILMというよりも、AFMのIndependent Writerを使ったバーストバッファに関しては、まずはファイルシステムが2つあります。ILMに関してはファイルシステムは一個だったんですけれども、AFMのIndependent Writerに関してはファイルシステムは2つです。SSDのファイルシステムと、GPFSという形でニアラインSASのファイルシステムが2つある状態です。SSDからニアラインSASに関してはほぼ自動でエミュレートされます。使っていないデータだけがどんどん、使っているデータがSSDの方に貯まるという仕様になっています。もしSSDのファイルシステムが潰れてしまっても、ニアラインSASの方だけで運用できるようになっています。
リコールと言う処理に関しては、メタデータだけになっているCache側のSSDの方に、メタデータだけのところにアクセスすると、自動的にニアラインSASからSSDにデータが戻ってくるという形になっています。すでにこのGPFSのIndependent Writerを使ったご提案というのは弊社も始めており、既に1件受注しているところもありますし、米国では大きいサイトでいわゆるバーストバッファ側がIBMさんでHomeがDDNという案件もあります。

・Single DR (Disaster Recovery)

こういったIndependent Writerを使って、それを派生させたものが、AFMのディザスタ・リカバリ・モードです。
これは良くあるディザスタ・リカバリ・モードですので、いわゆる時間おきにsnapshotを取って、データの整合性を保ちます。何か障害があったときには、primaryのデータが残っていれば差分で転送できます。
ディザスタ・リカバリに関しては、基本、primaryとsecondaryは容量はイコールである必要がありますが、Independent Writerに関しては、primaryのSSDの部分とニアラインSASはイコールである必要がありません。容量がSSDは10TBくらいで、Homeが1PBくらいでも運用が可能になります。SSDの方はただのキャッシュですので、使っているデータプラス、ファイルシステムのメタデータ、Homeとのやり取りをしているメタデータだけが残っているので、ここがディザスタ・リカバリと、Independent Writerを使った転送の方法としては違いがでてきます。
よって、コスト的に考えるとディザスタ・リカバリに関しては必ず同じ容量が必要ですが、Independent Writerに関してはその必要がないのでコスト的にも安くなります。ディザスタ・リカバリとIndependent Writerで使い方が、パフォーマンスを上げるか、それともデータを保全するかで、異なってきます。

 AFMのパフォーマンス

最後に、実際に遅延を発生させて、GPFS間でAFMを使わないと、どれくらいの速度しか出ないのかについてです。
まずはGPFSのマルチクラスタの部分、AFMの検証環境ですが、左手がHome側の構成で、右手がCache側の構成です。
GPFSのclient 6台から、40Uのアップリンクを持ったスイッチではなくて、サーバをブリッジさせて、ブリッジさせたところでtcコマンドを使って遅延を発生させています。
実際にどれくらい遅延と、それから40GbEの構成で、どれくらい速度が出ているかですが、まずは遅延がない状態だと、青がWriteですが、Writeで35Gbps、Readで21.44Gbps。
Readに関して、21.44GbpsとWriteに比べて低いのは、弊社の40Gのスイッチの問題で、いわゆるアップリンクが40GbEに対して、10GbEの環境だと、Readをする時にスイッチ側がつまってしまって速度がこれくらいしか出ないという状態です。スイッチ側のポートのバッファ等を設定すると、高価なスイッチだともう少し良くなるのですが、弊社にある40GbEプラス10GbEのスイッチは、バッファを設定してもこれくらいしか出ないという状態でした。これは良いスイッチを借りてバッファを設定して実施したら結構いい数字が出たので、スイッチの環境かと思っています。
で、ここがすごいところですが、遅延が2mm secあるだけで、Writeに関しては10Gbpsくらい下がるというところです。
その後はあまりReadはそんなに影響を受けないですが、8msくらいからどんどん下がっていって、大体8ms〜16msの間だと、大体東京ー大阪間くらいですかね、10ms、11ms、それくらいですかね、少しいい環境だと8msです。北海道、札幌ー東京くらいで16msあるかないかくらいです。これはネットワークの環境次第なので何とも言えないですが、日本国内だけでも、せっかくこれくらい帯域があって速度の出るGPFSでも、マルチクラスタ環境でキャッシュを使わないと速度が出ません。遅延が92msとか110msとかになると酷いもので、ほとんどI/Oもできないというような環境になっています。

おわりに

AFMの実際のパフォーマンスに関しては、この後Yahoo! JAPANさんの事例の最後のところでご紹介させていただきますので、そちらをご参照頂ければと思います。
マルチクラスタをして、それぞれデータをコラボレーションしたい、それぞれのサイトでデータを速く読み出したいという要求は色々なところで聞いています。
プラス、それを転送したものをさらにクラウドにティアリングしたいといった要望も最近増えていますので、GPFSにはAFMと呼ばれるような複数の遠隔地でデータをコラボレーションする機能がありますので、もし「こういうことはできないか？」といったご質問やご不明な点がありましたら、弊社までご連絡頂ければと思います。ありがとうございました。

関連資料

• OpenStack
• Hadoop 対応 エンタープライズ・ストレージ
• OpenStack 環境で利用される ハイパフォーマンスストレージの紹介（OpenStack Days Tokyo 2016 スライド）