未解決
Community Manager
•
3.1K メッセージ
2
2682
NFSがRDMAに乗ってやってきた
＊こちらの記事は2021年12月に開催された[AskTheExperts]PowerScaleコーデ 2021冬からの内容になります。
NFSがRDMAに乗ってやってきた
OneFSは、NFSについても地道に進化を続けています。OneFS 9.2と9.3でそれぞれ大きなアップデートがありましたので、ご紹介したいと思います。
トピックは二つ。
- NFS over RDMA のサポート ※OneFS 9.2のアップデート
- NFSv4.1およびv4.2のサポート ※OneFS 9.3のアップデート
1. NFS over RDMAのサポート
RDMAは、『Remote Direct Memory Access』の略です。古くからあるテクノロジーなので、耳にされた方も多いかもしれません。詳しくはネット検索をして頂くとして、ここでは簡単に。RDMAは、CPUやOSを介さずにネットワーク（※イーサーネットとは限りません）を介して異なるコンピュータのメモリに直接アクセスする仕組みです。データの受け渡しをする登場人物を減らすことで、CPUに負荷を掛けずに低遅延の高速なデータアクセスを実現しています。
「RDMAと言えばInfiniband」というセット物のようなイメージがあるかもしれませんが、それは昔の話で、今ではイーサーネット上でもRDMAが利用できる時代になっています。Converged Ethernetの登場により、イーサーネットでもロスレス通信ができるようになりました。その流れの中、イーサーネット上でRDMAを利用するためのRoCE（RDMA over Converged Ethernet）と呼ばれる仕様が2010年に策定されました。現在では2014年に策定されたRoCEv2となっています。
OneFS 9.2からRoCEv2をサポートしており、フロントエンド ネットワークのイーサーネットポートを利用してNFS over RDMAを実現しています。余談ですが、NFS over RDMAはRFC8267で標準化されています。
活用シーン
NFS over RDMAの代表的な活用シーンとしては、High Performance Computing (HPC) のワークロードがあります。HPCは、ストレージから大量のファイルを読み出し、高速計算をした結果を書き出すという低遅延・広帯域がストレージには求められます。昨今活用が広がっているAI/Deep Learningのトレーニング ワークロードが、これに似ています。高性能GPUを搭載し大量の計算を実行するサーバが注目されがちですが、Deep Learningでは大量のデータを扱うためストレージも重要な要素の一つとなります。規模が大きくなると、トレーニングデータを共有ストレージに配置し、複数のGPUサーバでトレーニングするというアーキテクチャが必要となります。高価なGPUが遊んでしまっては投資が無駄になるので、ストレージには低遅延・広帯域が必要とされます。GPUの進化に伴い、その要求は益々高まることが予測できます。このような背景のもと、GPUメーカーであるNVIDIA社は、GPUDirectというGPUがCPUを介さずにデータにアクセスできる技術を提供しています（NVIDIA社 GPUDirect Storage）。
GPUDirectは、GPUサーバと外部ストレージとの接続方式としてNFS over RDMAに対応しています。GPUが直接NFSサーバ上のトレーニングデータを読み込むなんてすごいですね。PowerScaleは、GPUDirect対応ストレージとして利用頂けます。PowerScale F600を使ったGPUDirectでの性能レポートが公開されているので、興味がある方はチェックしてみてください。Deep LearningとスケールアウトアーキテクチャであるPowerScaleの相性の良さもP.12のFigure 4で見て取れると思います！
PowerScale and NVIDIA GPUDirect Performance Report
NFS over RDMAの利用要件
NFS over RDMAを利用するためには、PowerScaleだけではなくクライアントおよびネットワークも要件を満たす必要があります。
PowerScale
|
クライアント
|
ネットワーク
|
NFS over RDMAの利用要件を満たした上で、クラスタ側ではNFS over RDMAアクセスのためのIP Poolを作成するだけで利用できます。もし、非対応の10GbEインタフェースカードを持つノードがクラスタに混在する場合には、そのノードをNFS over RDMA用のIP Poolには含めないでください。言うまでもなく、利用要件を満たさなくなります。それを未然に防ぐために、IP Pool作成画面で[Enable NFSoRDMA]というチェックボックスが追加されています。これにチェックを入れるとNFS over RDMA対応のインタフェースだけがリストされ、間違って非対応のインタフェースを選択してしまうことがないようにしてくれています。
PowerScaleを利用する上ではIP Poolはそもそも必要ですし、NFS over RDMAの有効化はNFS設定画面（後述）にあるチェックボックスにチェックを入れるだけなので、PowerScale側のハードルはないに等しいぐらいすごく簡単です！
ただし、以下の点の考慮が必要です。
- Link Aggregationインタフェースは非対応
- VLANは非対応
- IPv6は非対応
一方、クライアント側は、インタフェースカードのドライバを組み込むなどすれば、あとはmountコマンドのオプションでRDMAを指定することでNFS over RDMAのマウントができます。
# mount -t nfs -o nfsvers=3,proto=rdma,port=20049 powerscale:/ifs/export_rdma /mnt/nfs_over_rdma
なお、NFS over RDMAはNFSv3のみをサポートしていますので、クライアント側でバージョンを指定してマウントをしてください。
性能特性
性能特性について簡単に触れておきたいと思います。具体的なグラフなどを提示できないのですが。。。
通常のTCP通信のNFSと比較した場合、ノード当たり少ないスレッド数でのReadスループットで最も大きな差となる結果が出ています。RDMAの方が2倍～3倍高いスループットとなるケースもあります。また、PowerScaleおよびクライアントのCPU負荷が低減された結果も残っています。同等負荷の場合にRDMAの方が30%～40%程度CPU負荷が軽減されたケースもあります。一方、多数のクライアントから同時に負荷を掛けた場合には、TCPとRDMAで差がない結果となっています。
だからというわけではありませんが、ノード当たりNFS over RDMAの接続数は32までが推奨となっています。
この特性からも、前述のHPCやAI/Deep Learningでの利用に合っていると言えます。他にも、限られた台数のクライアントから広帯域の読み出しが必要となる4K/8K高画質のメディア制作などのワークロードにも適していると言えようかと思います。（参考：PowerScale OneFS: NFS over RDMA for Media）
NFS over RDMAのメリットが活かせそうなワークロードがありましたら、是非試してみてください！
2. NFSv4.1および4.2のサポート
2つ目のトピックです。OneFS 9.3で新たにNFSv4.1と4.2がサポートされ、NFSのサポートバージョンがv3/4.0/4.1/4.2となりました。v4.1が2010年にRFC5661で標準化されて10年以上経ちますが、世の中ではv3の利用が多かったこともあり、ようやく開発チームも対応してくれたという感じです。
「NFSv4.1に対応したということは、pNFS（Parallel NFS）が使えるの？」と思う方もいるかもしれませんが、対応していません。RFCで定義された機能（オペレーション）の中には、必須機能とオプション機能があります。OneFSは必須機能に対応しており、オプション機能であるpNFSには対応していません（実装していません）。そもそも、PowerScaleはブロックストレージのインタフェースを持っていないので、実装することもできないわけですが。
実は、v4.2のRFCで定義された機能は全てオプション機能なため、OneFS 9.3はv4.2での接続ができることに間違いはありませんが、v4.2の機能が使えるわけではありません。今後の進化に期待したいところです！
NFSv4.1およびv4.2を利用するのは簡単です。管理画面のチェックボックスにチェックを入れるだけです！
一目瞭然ですが、各バージョンを使用するか否かを細かく選択することができるようになっています。デフォルトではOFFになっているので、使うバージョンだけをONにしてください。使わないバージョンはオフっておきましょう。なお、前述したNFS over RDMAもこの画面で有効化します。
セッショントランキング
最後に、NFSv4.1のセッショントランキングを紹介しておきたいと思います。1つのNFS接続で複数のTCPコネクションを張れるというものです。
例えば、NFSクライアント上のアプリケーションAがNFS exportから重いRead処理を行っている最中に、別のアプリケーションBが同一のNFS exportにアクセスするとなった際、TCPコネクションが一つだとアプリケーションBの処理は待たされてしまいます。このような場合でも、複数のTCPコネクションが張られていると、アプリケーションBはアプリケーションAとは異なるTCPコネクションを利用して即座にNFS exportにアクセスできます。NFSクライアント上の複数スレッドがNFS exportにアクセスするような環境ではNFSv4.1のセッショントランキングが有効です。高負荷利用では、All Flashモデルとの相性はバッチリです。
これを利用するためには、OneFS側ではNFSv4.1をONにするだけです。あとは、クライアント側でNFSマウントする際に"nconnect"オプションを指定します。ただし、nconnectはLinuxカーネル5.3以上である必要があるので、適合したバージョンを利用してください。
# mount -t nfs -o nfsvers=4.1,nconnect=4 powerscale:/ifs/nfs01 /mnt/nfs01
# netstat -an |grep 2049
tcp 0 0 10.119.81.82:1000 10.119.80.31:2049 ESTABLISHED
tcp 0 0 10.119.81.82:810 10.119.80.31:2049 ESTABLISHED
tcp 0 0 10.119.81.82:674 10.119.80.31:2049 ESTABLISHED
tcp 0 0 10.119.81.82:701 10.119.80.31:2049 ESTABLISHED
↑クライアント（10.119.81.82）から1つのノード（10.119.80.31）に対して4つのTCPコネクションが張られていることがわかります
※1台のクライアントからは1ノードに対してのみNFS接続するので、ノードに渡って複数TCPコネクションが張られるわけではありません
長らくNFSの機能拡張がなかったのですが、ここにきて立て続けに目玉が２つリリースされました。いずれもさらなる機能改善が期待できるので、NFSをご利用の方は今後の地道な進化にも注目しておいてください！