期待のネット新技術

HBAとMPIとの組み合わせで、低レイテンシーを安価に実現した「RDMA」

【InfiniBandの現在】

 「InfiniBandの現在」では、規格としての歴史と現状、今後の動向をまとめて紹介している。大半の読者にとっては「InfiniBandって何?」というところだろうが、僚誌クラウドWatchをご覧になっておられる読者の中には「何で今さら」という方も居られるかもしれない。

 そう、InfiniBandという規格は、1999年に作業が始まり、2000年に最初の規格策定が行われたという「えらく古い」規格なのである。

InfiniBandに当初から実装され、MPIの低レイテンシーを支える「RDMA」

 前回は「MPI(Message Passing Interface)」について紹介したが、これを支える技術が、InfiniBandに当初から実装されていた「RDMA(Remote DMA)」である。

 そもそもMPIにしたところで、単にInfiniBandを従来と同じ方法で利用したときには、帯域はともかくレイテンシーの観点から見ると、ほかのInterconnectとは全く変わらない。InfiniBandを使ったMPIのレイテンシーが非常に少ないのは、InfiniBandを利用した場合のレイテンシーが極端に低いためである。

RDMAを使わないと、高CPU負荷とバッファーのメモリ内コピー頻度が問題に

 以下の図は、RDMAを使わずにInitiator(送信側)からTarget(受信側)にデータを送ろうという場合の簡単な模式図だ。

 RDMAを使わない場合は、まずアプリケーション内のバッファーにデータを格納し、それをミドルウェア(例えばイーサーネットならTCP/IPのスタック)に渡す。ミドルウェアはこの渡されたデータに対してヘッダーやフッターを付加したり、CRCを計算して追加したりと、さまざまな作業を自身のバッファー内で行ってから、それをドライバーに渡す。

 ドライバーは、渡されたデータをOSの内部キューに格納し、次いでI/Oのリクエストを出す。これを受けてOSは、自身の内部キューの内容を「HBA(Host Base Adapter)」のバッファーにコピーし、ハードウェア的にI/Oリクエストを発行する(HBAのどこかのレジスタに書き込みを行う、など)。

 この結果として、Initiator側のHBAのバッファーにある内容が、Target側のバッファーにコピーされることになる。ここからは逆の手順で、最終的にアプリケーションのバッファーへデータがコピーされ、一連の転送手順が完了するわけだ。これは典型的なI/Oのやり方で、柔軟性とか相互接続性、移植性などに優れる手法ではあるのだが、以下のような問題もある。

  • レイヤーを重ねるごとにバッファーの内容のコピーが発生する。同一マシン内のメモリ内コピーとは言え、積み重なると所要時間は馬鹿にならないし、CPUの負荷も決して小さくはない
  • CPU負荷は、転送速度が上がるほど増える。特に当時のInfiniBandは2Gbpsをターゲット(信号速度は2.5GT/secだが、8B10Bエンコードの利用により2Gbps=256MB/sec)にしていた。バッファーのコピーやCRCの計算などは、この速度に間に合うよう行わねばならない

 特に後者は、当時のCPUにとって決して低い負荷とは言えなかった。2017年とやや前だが、ギガビットにおけるジャンボフレームに絡んだ話をしている。このとき、以下のグラフとともに、UltraSPARC IIiを利用したSunのワークステーションで、MTUを1.5Kにすると400Mbps程度で頭打ちになり、しかもCPU利用率が100%に達しているのに対し、MTUを9Kにすると600Mbpsを超える一方、CPU利用率は55%に落ちるという話を紹介しているが、根っこはこれと同じだ。

出典はEthernet Allianceのホワイトペーパー"Ethernet Jumbo Frames"(PDF)

高CPU負荷と同一マシン内のメモリ内コピーの問題を解消する「RDMA」

 これらの問題に対する解決法として提案されたのが、RDMAとなるわけだ。RDMAという技術そのものは、10GbEに絡んで、以前、簡単に紹介したが、要するにアプリケーションが直接HBAとやり取りすることで、余分なオーバーヘッドを削減しようという仕組みである。

 このあたりは、Hostの種類(単にx86かそれ以外か、だけではなく、WindowsなのかLinuxなのかそれ以外なのかによっても、だいぶ差がある)で若干インプリメントに違いがあるが、RDMAで最もオーバーヘッドが少ないパターンは、以下の図の赤い実線のルートである。

 一番最初、アプリケーションが立ち上がってInitiatorとTargetがお互いを認識し、通信パスを確立するという辺りまでは、黒の破線のルート、つまりRDMAが使われない先の図と変わらない。ただ、一度パスが確立したら、その後は赤い実線ないし赤い破線のルートでの通信が可能になる。技術的な難易度が高いのは赤い実線の方だ。

 こちらは、あらかじめ(つまり黒の破線で初期設定を行っている間に)、メモリI/O空間(HBAから直接アクセスできる物理メモリ領域)を、アプリケーション側で自分の仮想メモリ空間にマッピングしておく。こうすると、アプリケーションがそのマッピングした領域にアクセスしたとき、それをHBAから直接参照可能になる。これを利用して、以下のように途中の処理を全部飛ばして、いきなりデータが送れるようになる。

  • 1.アプリケーションがマッピングしたメモリ領域にデータを書き込む
  • 2.HBAがDMAを利用し、そのデータを自分のローカルの(つまりHBA上の)メモリにコピー
  • 3.HBAはそのデータを送り出す

 この場合、これまでミドルウェアで処理していた、ヘッダー/フッターの付加や、CRCの計算といった内容を誰がするのか? ということになるが、それは全てHBA側でオフロードすることになる。このため、アプリケーションから見れば、本当にバッファーにデータを書き込むだけで、後は何もしなくても勝手にデータが送られていくイメージになる。

 実際、HBA上の処理プロセッサは、ラインレート(InfiniBand 1.0で言えば250MB/sec)でこうした処理が行えるように設計されているから、HBAがボトルネックになることもない。例えば 1.で「アプリケーションが書き込みを行って転送をさせたい」というリクエストを出したいときに同期をどうするかというと、マッピングしたメモリ領域を利用して一種のセマフォを構築して、HBAが常にそこを監視しているといった手法を実装することで、CPU負荷を減らすことが可能だ。

 ちなみに先の1.~3.は、図で言えばInitiator側の処理になるので、Target側は以下のようになる。

  • 4.HBAにデータが到着
  • 5.HBAはそのデータをアプリケーションがマッピングしている領域にDMAを利用してコピー
  • 6.HBAからアプリケーションに転送完了を通知

 この際にCRC32をチェックし、データの正当性の確認(と、間違っていた場合の再送リクエスト)や、ヘッダー/フッターの除去などは、すべてHBA上の処理プロセッサが行ってくれる。

 このやり方が一番高速なのだが、Hostの環境によってはメモリI/O空間をアプリケーションの仮想アドレスにマッピングできない、なんてケースもある。そうした場合には、赤い破線のように(ミドルウェアをバイパスして)、いったんドライバーに渡すことになる。

 さすがにドライバーのレベルでメモリI/O空間へのマッピングができないことはない(できないとしたら、それはそもそもメモリI/Oという概念がないことになるが、大昔はともかく現行でそんなシステムは聞いたことがない)ので、ここからは同じルートで処理が行えることになる。

 こちらは処理がワンステップ余分に挟まる分、ややレイテンシーは増えることにはなるが、それでもミドルウェアで行っていた分の処理をHBA側にオフロードできるし、メモリコピーの頻度もずっと減るので、RDMAを用いないケースよりも高速になる。

RDMAを実装したHBAとMPIとの組み合わせで、低レイテンシを安価に実現

 InfiniBandは、Release 1.0の時点でこのRDMAの仕様を策定しており、これを実装したHBAをMPIと組み合わせることで、ほかのInterconnectに比べ、ずっと高速というか低レイテンシーでのMPIの動作が可能になった。このことは、InfiniBandがHPCのマーケットで生き延びることができた大きな要因の1つとなった。

 ちなみに別の要因は、元々サーバー市場で広く利用されることを前提に、多くのメーカーがここに参入していた結果として、HBAやスイッチといったコンポーネントが、競合製品よりずっと安かったことにある。速くて安く、しかもソフトウェアサポートがそれなりにある、という状況であれば、ほかのInterconnectを駆逐していくのは、火を見るより明らかであった。

 もっとも、2000年前後にこれをHBAに実装するのは、決して容易ではなかった。Intelが最終的にHBAの開発を放棄したのは、RDMAサポートにまつわる処理プロセッサ周りの実装が追い付かなかった(Intelはそもそもx86の会社だったので、こういう処理はHost側CPUで行うべしという思想だ。しかしながらHBAにx86を突っ込むのは当然無理で、そのあたりに困難があったと想像される)ためで、逆にこれを乗り越えたMellanoxやQLogicなどのベンダーが、HPCマーケットにおけるシェアを握ることができた、ということなのだろう。

大原 雄介

フリーのテクニカルライター。CPUやメモリ、チップセットから通信関係、OS、データベース、医療関係まで得意分野は多岐に渡る。ホームページはhttp://www.yusuke-ohara.com/