プログラマ目線から見たRDMAのメリットとその応用例について

InfiniBand & Manycore Day

プログラマ目線から見たRDMAのメリットと
その応用例について

２０１０年１１月１７日
株式会社ＮＴＴデータ
技術開発本部伊藤雅典

ＩＮＤＥＸ

00 自己紹介
01 概要とInfiniBand & Manycore Day における位置づけ
02 InfiniBandの「機能」概要
03 RDMA技術のメリット
04 RDMAの応用例（1）：SDP
05 InfiniBandの応用例（1）：vSMP
06 今後の予定（？）
07 まとめ

Copyright © 2010 NTT DATA CORPORATION 1

00 自己紹介

氏名
伊藤雅典 (いとうまさのり)
所属
株式会社NTTデータ技術開発本部 ITアーキテクチャ＆セキュリティ技術センタ

担当業務
NTTデータの総合クラウドサービス BizXaaS™ (http://bizxaas.net/)の、
「フルOSSクラウド構築ソリューション」の開発ほかに従事
http://www.nttdata.co.jp/release/2010/040801.html
OpenStackやクラウドストレージ技術などに注力中

その他、活動領域
Open Cloud Campus、日本OpenStackユーザ会(JOSUG)、JEUG、
VIOPS InterCloud SIG、GICTF等でも活動中


00 自己紹介（続き）

Disclaimer
私の勤務先では、特に、InfiniBand に関する開発活動（製品、ソリュー
ション等）は行っておりません。純粋に、ユーザの立場にあります。

Then, why me?
その昔（前職の頃）、仕事で InfiniBand 他の高速インタコネクトに関
わっていたためです。具体的には・・・
• InfiniBand HCAカードの Linux 用デバイスドライバの開発
• SDPプロトコルの策定
• DAPL (Direct Access Provider Library)ライブラリの開発
• RDMA技術の応用の１つである、ICSC Socket Extension の仕様の策定
等々


01 概要

InfiniBand & Manycore Day シリーズの全体象
InfiniBand 関連 1．技術編
２．業界動向編
３．応用編
Manycore 関連調整中？

本日のプレゼンテーションの概要
以下のトピックについて、システムプログラマ視線でみた技術的なポイン
トをご紹介します。
• RDMA技術の代表格である、InfiniBandの機能概要
• RDMA技術のメリット
• RDMA技術および InfiniBand の応用例（SDP, vSMP）



Specification
• 最新版スペックのバージョンは1.2.1＋Errata
• http://members.infinibandta.org/kwspub/spec/
• 意外にバージョンが上がっていない
• 機能としては十分成熟したということか。
• 構成
• Volume 1 : 全体アーキテクチャ、リンク～トランスポート層、管理系 1727pp
• Volume 2 : 物理層 834pp
• Volume 1+2 合計で2500page以上！
• 物理層（L1）からトランスポート層（L4)、管理系、およびコネクタ
の規格等まで定められているため、膨大な量となっている



全体像の理解への近道
• スペックの Volume1、Chapter 3 “Architectural Overview” が一番
網羅的でまとまっており、おすすめです。
• 豊富な図版入りで、55page （ただし、英文）

システムプログラマの視線から見た特徴的な機能
• Addressing
• パケットに埋め込まれているアドレスには２種類ある
• サブネット単位でユニークな、LID （Local Identifier）： 16bit
• 全世界でユニークな、GID （Global Identifier）： 128bit
• GIDには、実は IPv6 が使用されている
• つまり、InfiniBand “ルータ” という概念がある



• 豊富なトランスポート層の機能
• ４種類のトランスポート
• RC, RD, UC, UD
• RDMA : Remote DMA
• Atomic Operation （リモートでCompareAndSwap等ができる）
• 以上はすべてハード（ファームも含む）で実装されている
• Congestion Control
• Slow Drain問題の考慮等が入っている
• 管理系
• 管理用に外付けのネットワークは要求しない。インバンドで管理


03 RDMA技術の「機能」概要

InfiniBand HCAの基本的な構造

IB spec. 1.2.1
Vol1. p96より
引用


03 RDMA技術の「機能」概要

HCA ホストチャネルアダプタの略。要するにNIC
WR Work Request。要するに通信コマンド
QP Queue Pair。プログラムが使う、通信エンドポイント
全二重のチャネルの送信側と受信側のコマンド処理キューに対応
CQ Completion Queue。QPに投入したWR（通信コマンド）のうち、
処理が完了したWRに対応する情報エントリ（CQE）が格納される
PD Protection Domain。アクセス保護のための単位
MR Memory Region。HCAに登録された、仮想連続なメモリ領域
MW Memory Window。MRを分割する単位



InfiniBandによる通信手順の概要
1. 事前準備
• HCAとの接続、PD、CQの準備等
2. 通信エンドポイントを作成する（QPをつくる）
3. コネクションを張る（RCを使う場合）
4. 通信バッファをHCAに登録する 2/3と4は逆でも構わない
5. 通信リクエストWRをQPにポストする
Send/Recv、RDMAなど
RDMAするリモートアドレスは、Send/Recvでコネクションの両側で
通知しあうのが普通
6. CQから通信リクエストの完了を刈り取る



広帯域通信？低遅延？
違います。それは、主にリンク層の性能によるメリット
• リンク層の性能以外にも、 I/Oバスの性能、I/Oブリッジの性能、
DMAエンジンのI/Oバスの使い方の善し悪し、そもそも論としてソ
フトからの使い方の善し悪し等、さまざまな要素が関係してきま
す。

では何がRDMA技術のメリットなのか？
コピーを減らせること
システムバスの負荷が低いこと
≒SMPシステム全体の効率を上げられること



まず、プログラマ視点で見た、RDMAを復習しておきましょう

• リモートノード上の、
• 仮想アドレス(user/kernel spaceを問わない)を指定して、
• 書き込み、読み込みができる
• しかもCPUを介さずにデバイスがやってくれる
• だから、Remote Direct Memory Access（RDMA）



「コピーを減らせる」とはどういうことか？

以下の２つのケースにおける、受信側でのデータの動きを比較してみます
1. 通常の socket 通信のケース
2. RDMAによるユーザレベル通信(ULT)のケース０コピー通信？



１．通常のSocket通信などのケース
送受信バッファを使って Send/Recv する

Main Memory
HCA I/O I/O
Bus Bridge Kernel Buffer

User Buffer
System
Bus
CPUによるメモリコピー：
ca CPU #1
ch
e



２．RDMAによるユーザレベル通信(ULT)のケース
リモートのユーザバッファへ直接RDMA Write する

Main Memory
HCA I/O I/O
Bus Bridge Kernel Buffer

User Buffer
System
Bus

CPUによるメモリコピーなし
：
ca CPU #1
ch
e



これら２つのケースにおける、受信側でのデータの動きの違い
1. 通常の socket 通信などのケース
デバイス -> I/Oバス -> I/Oブリッジ -> システムバス -> メモリ
(kernel buffer) -> メモリ(user buffer)
2. RDMAによるユーザレベル通信(ULT)のケース
デバイス -> I/Oバス -> I/Oブリッジ -> システムバス -> メモリ
(user buffer)
実は違いは最後のメモリコピーしかない
• メモリコピーはシステムバスを２回通るのに注意
つまり、RDMAの有無で、システムバス上のトラフィックは（最悪）３倍違う！
• これがSMPシステム全体の効率に効く。


03 RDMA技術のメリット（余談）

I/Oバスに対する DMA READ/WRITE とRDMA Read/Writeの関係

RDMA Writeソース側のデバイス上のHCAのDMAエンジンからは、主
記憶上からのデータの読み出しが必要
• DMA READ を実行
RDMA Writeターゲット側のHCAのDMAエンジンからは、主記憶へ
データの書き込みが必要
• DMA WRITE を実行

つまり、立ち位置によって、READとWRITEが逆転して見えることがあ
るので混乱しないようにしましょう



RDMA技術の問題点の一つ
ハードの設定を気にするのは面倒だし、慣れたソケット通信でプログ
ラムを書きたい

解決策
ソケットライブラリのすぐ下の層（ユーザ空間）で、通信処理を横取り
し、RDMAを利用した低コスト・高性能通信処理にすげかえてしまえ
ばいい！
この種のアイデアは、古くは、UCB の FastSockets の研究[1] にさ
かのぼります
[1] Steven H.Rodrigues, Thomas E.Anderson, and David E.Culler. High-performance
local area communication with fast sockets. USENIX, 1997.


SDPの処理の概要
• TCPの代わりに独自プロトコル（Socket Direct Protocol）を定義。上
位プログラムには通常の byte-stream通信を見せる。
• ショートメッセージ、Recv Postingが間に合わない場合は
Send/Recvを使用して通信
• ロングメッセージの場合は、プログラムが渡したバッファをメモリ登録
してからRDMAを使用して０コピー通信
使い方
通常のsocket通信を行うプログラムの起動時に、LD_PRELOADに
libsdp.so を指定するだけ



効果
ベンチマークすると、物理層の実効性能の9割以上は達成できます。
例：SDRの測定例で、例えば7.6Gbpsくらい。

特性（というか、留意事項）
• SDPでは、プログラムにTCPソケットに見えるパス１本について１つ、RC
のコネクションをはります。なので、低通信量でコネクション確立・切断を
繰り返すような使い方をすると、性能が出ません。
• 送受信バッファを十分大きくする必要があります。でないと、0-copy通
信が走らないことがあります。
• RCコネクションはハード資源です。なので、多量のコネクションを張るよ
うなプログラムは性能劣化を起こすことがあります。



ScaleMP
• リングトポロジのIBで接続した仮想SMP（vSMP）なるもの
• 以下の例では 8core、16GB の4台を束ねて、32core、64GB の
SSIにできる Virtual SMP
Node#1 Node#2
2QC/16GB 2QC/16GB 2port InfiniBand
でリング状に接続
HCA HCA

HCA HCA

2QC/16GB 2QC/16GB
Node#3 Node#4



リングトポロジでvSMPを実現するにあたって気になること
• 鶏と卵問題
このNノードなら、 IBサブネットもN個存在する
サブネットごとに Subnet managerが必要
Subnet manager は SSI になった後に起動するのか？
でも、Subnet Manager がいないと、SSIになれないはず
では、vSMPってどうやって起動するんだろう？
もしかしたら、各ノードごとにOSあげるのか？
• そのあとでSSI化するなら納得できる



考えるべきこと
spinlock の実装
• spinlock を獲得しようとしたプログラムが動作している物理ノード
の以外のノードも含めて、システムワイドでCAS操作を行う必要が
ある。InfiniBand の Atomic Operation で実現するのか？
ある物理ノードで動いているプロセスが、他ノードのメモリにアクセス
したらどう処理するのか？
• 別ノードにコンテキストを移動させる？
別物理ノードに接続されているI/Oアダプタに対してI/O要求が出た
場合にどう処理するのか？
etc.

某所のScaleMP環境で実機検証・調査をしたいと思います ☺


06 今後の予定（？）

• 今後の InfiniBand & Manycore Day でご紹介したいこと
• InfiniBand以外のRDMA系技術の動向
• NFS/RDMAの概要とメリット
• Oracle RACが使用する RDS : Reliable Datagram Socket の概
要とメリット
• DAPL等、RDMA技術を利用可能な通信ライブラリの概要
• RDMA技術を活用するためのSocket API拡張

Copyright © 2010 NTT DATA CORPORATION

07 まとめ

• システムプログラムからみたRDMAのメリット
• メモリコピーを減らすことが、通信性能だけでなく、システム性能全
体に効く（意外と認知されていない）

• 今後も、RDMA技術の応用例やメリットなど、ご紹介していきたいと思
います
• 一緒に実機評価作業をしてくれるボランティア求む！ ☺


ご清聴ありがとうございました


本文中に記載の会社名、商品名、製品名などは、一般に各社の商標または登録商標です
ただし本文中では、TMや®マークは明記してありません

Ｑ＆Ａ


References

InfiniBandの規格
http://www.infinibandta.org/
メンバ登録（無料）をしなくてもスペックは以下から入手できるよ
うです。
http://members.infinibandta.org/kwspub/spec/
OpenFabrics
http://www.openfabrics.org/
InterConnect Software Consortium
http://www.opengroup.org/icsc/


0x バックアップスライド

以下、バックアップスライド
投影せず。また、配布資料からも削除。


0x バックアップスライド


Interconnect の歴史
Ethernet (1973-)
Token Ring
FDDI
Fiber Channel
SONET/SDH
HIPPI, SP-Switch(IBM) , AP-net(Fujitsu), Memory-Channel(DEC), etc.
Myrinet, SCI, Giganet,... (academic NW)
Virtual Interface Architecture (1997)
NGIO + Future I/O = InfiniBand (2000-) ←ココ
3GIO => PCI-Express (2002)
Quadrics, PathScale…

Interconnect の歴史
横軸年代、縦軸帯域のグラフを描く

ＩＮＤＥＸ

NN InfiniBandに至る、Interconnect の歴史
NN InfiniBandの「機能」概要
NN そもそもRDMAのメリットって何？
NN RDMAの応用例：NFS/RDMA (RFC5532等)
NN RDMAの応用例：SRP
NN RD : Reliable Datagram の威力
NN End-to-end latency 1us の理想と現実
NN NW冗長化？昔々、APMというものがあっての～
NN SDPが効く場合と効かない場合
NN vSMPって、初代 Virtual Ironを思い出す… (OLS2005)
NN それでも socket でいきたい人っているかしら？


E2E latency 1us の理想と現実

どうやればこんな性能を出せるか？
CPUを busy poll で使いまくって通信完了を検出する。
これの繰り返し。

実用的には、割り込みベース
指定回数pollしてから blocking wait するのもあり

APMによるパス・マイグレーション

通信経路冗長化機能の一つ
RC作成時に、２つのパスレコード（通信経路を示す）を指定しておく
プライマリ側の通信経路でエラーが発生した場合、ハード層でセカ
ンダリ側の経路に切り替えてくれる
• Failover可能な経路の制約
• Standby 側パスは同一HCA上のポートを使っていること（マルチ
ポートHCAなら、別ポートでもいい）
絵を描く

経路変更をキックする人
ModifyQPでもできる
SW

01 クラウド業界動向


05 IaaSインフラを自分で持つとはどういうことか？

Eucalyptus で構築したオンプレミスのIaaSインフラの例で考えてみます
利用者PC

インターネット

外部ネットワーク

クラスタ＃１（≒ラック＃１）
AWS S3 API AWS EC2 API NAT、F/W
SC : Storage
CLC : Cloud CC : Cluster
Walrus Controller
Controller Controller
内部ネットワーク

管理・ストレージ用
ネットワーク VM VM VM VM VM EBSボリューム
EBSボリューム
VM
Image
NC : Node … NC : Node
Controller Controller

管理・ストレージ用ネットワーク


05 Eucalyptusの論理構成

（参考）Eucalyptusの論理コンポーネント構成（階層構成イメージ）

Walrus
クラウドで１つ CLC
（S3サーバ）

クラスタで１つ SC SC
CC CC
（EBSサーバ）（EBSサーバ）
…
NC NC NC NC
クラスタでｎ個 … VM VM VM VM VM VM VM VM …
VM VM VM VM VM VM VM VM

クラスタ #1 クラスタ #2

05 Eucalyptusの論理構成

（参考）Eucalyptusの論理コンポーネント構成
論理コンポーネント
論理コンポーネント略称役割実装単位備考

Cloud Controller CLC クラウド全体の制 eucalyptus-cloud クラウドで１つ
御プロセス

Walrus Walrus S3サーバ（イメージ同上クラウドで１つ
データ等の保持）

Storage SC EBSサーバ同上クラスタで１つ
Controller

Cluster Controller CC NAT、VLAN制御、 CCプロセスクラスタで１つ
DHCP

Node Controller NC VMの実行 NCプロセスクラスタごとにN台

（注）他のソフトもだいたい似たような論理構成になっていることが多いです。

TIPS : 試験に出るOSSクラウド

「ごった煮」 ←今年はこれだ！

NASA Nebula クラウドと、OpenNebula はまったくの別物
NASA Nebulaクラウドは、NASAエイムズ研究所のクラウド
OpenNebulaはEU系の学術プロジェクト
名前がかぶっているだけ

JOSUG (Japan OpenStack Users Group)は「ジョス・ユージー」と読
んであげてください。☺
OpenStackの 2nd リリースの Bexar は「ベア /ˈbɛər/ 」と読みます

Eucalyptus 2.0 と Eucalyptus Enterprise Edition 2.0
基本的に別物です。評価された方は情報提供お願いします！

References : IaaS基盤

オープンソース
OpenStack http://www.openstack.org/
Eucalyptus http://www.eucalyptus.com/
OpenNebula http://www.opennebula.org/
Nimbus http://www.nimbusproject.org/
Wakame-vdc http://wakame.axsh.jp/vdc.html
Karesansui http://karesansui.sourceforge.jp/
CloudStack http://cloud.com/community
商用
Morph http://www.mor.ph/ja/
Enomaly http://www.enomaly.com/
Nimbula http://www.nimbula.com/


References : IaaS基盤

その他
NASA Nebulaクラウド http://nebula.nasa.gov/
NII edubaseクラウド http://grace-center.jp/prj_educloud.html
国立情報学研究所（NII）プレスリリースより
NASA Nebula とNII edubaseクラウドが連携
http://www.nii.ac.jp/index.php?action=pages_view_main&page_id=1106

WIDEクラウド http://www.wide.ad.jp/project/wg/wide-cloud-j.html


References : 関連コンポーネント

ストレージ系
SheepDog http://www.osrg.net/sheepdog/
Ceph/RADOS http://ceph.newdream.net/
Vastsky http://sourceforge.net/projects/vastsky/
etc.
NW系
Vyatta http://www.vyatta.com/
http://www.vyatta-users.jp/
Open vSwitch http://openvswitch.org/
CloudSwitch http://www.cloudswitch.com/
etc.


References : そのほか

PaaS系
Heroku http://heroku.com/
Ruby on RailsベースのPaaS （「Heroku最強伝説」 by @nabehiro_ さん）
FluxFlex http://www.fluxflex.com/
第４回JAWS-UG勉強会LT
AppScale http://appscale.cs.ucsb.edu/
OSSなGAEクローン
etc.

国プロ系の取り組み
総務省 H21年度情報通信に関わる研究開発
「セキュアクラウドネットワーキングの研究開発」
http://www.idg.co.jp/expo/cns/ （クラウドネットワーキングシンポジウム）


References : そのほか

ユーザ会
OpenStack http://openstack.org/
Eucalyptus http://eucalyptus-users.jp/

JAWSUG http://jaws-ug.jp/
JAZUG http://jazug.jp/


OpenStackのコミュニティ動向
OpenStack
そもそも OpenStack とは・・・
ようするに Yet Another Eucalyptus のようなもの
NASAが開発したIaaS 基盤の Nova(EC2相当) ＋ RackSpace社の
Nova(EC2相当)
相当
CloudFiles 実装の Swift (S3相当)＋α
(S3相当
相当)
実装言語は、基本 Python
実装言語は
ポリシー

• Open な開発プロセス☺

• NO Enterprise Edition
URL
http ://www.openstack.org/
http://launchpad.net/openstack/

02 ねらい

有力ソフト

1 Eucalyptus Eucalytpus1.6.2は、なぜ注目に値するのか？

Eucalyputs はどのような構造で実現されているのか？
2 OpenStack （ネットワーク視点を中心に）

Eucalyptus 1.6.2 を活用する上で、なお注意が必要な事項
3 CloudStack とは何か？

4 そのほか今後、期待される改善とは何か？


図版

図版
Place holder


参考：Sheepdog

特徴
ＩａａＳのような、仮想化を前提としたクラスタ環境向けのストレージ基盤
ＶＭに接続するディスクのイメージを配置することに特化して最適化

実現方式
クラスタを構成するノードのローカルディスクを利用
ＶＭのディスクイメージを固定長のチャンクに分割
ＤＨＴでクラスタ内に分散、デフォルト３重のコピーを分散して保持
発想としては Hadoop HDFS（等）によく似ている
ＶＭインタフェース部（クライアント）は、qemu block device のドライバとして実
装
クラスタ管理、クラスタ内通信にはCorosyncを使用
開発元
日本電信電話株式会社サイバースペース研究所（＠横須賀）
2010年7月、Ｓｈｅｅｐｄｏｇのクライアント部分が、qemu のメインラインにマー
ジされました (^o^)v

0x めも

2006/8 エリック・シュミット “Cloud Computing”
2006/8 Amazon EC2 Betaサービス開始
2006/x RightScale社創業
2008/4 Google App Engineプレビューリリース公開
2008/10 Windows Azure発表
2009/4 Google App Engine有料版サービス開始
2008/5 Eucalyptus 1.0 リリース
2009/3 AppScale 1.0 リリース
2010/2 Eucalyptus 1.6.2 リリース
2010/1 Windows Azure 正式サービス開始
2010/8 Eucalyptus 2.0 リリース
2010/7/19 OpenStack発表
2010/10/21 OpenStack 1st リリース(Austin Release)

VMware vCloud (vExpress)(Vmware, EMC, Cisco)
Oracle の発表
Nifty Cloud API正式リリース ‘10/
XCP
2008年4月：GAEプレビューリリース版を公開
2009年2月：GAE有料版のサービスを開始
2009年4月：Javaアプリケーションに対応


04 RDMAの応用例（1）：NFS/RDMA

NFSの問題点の一つ
いくら高橋＠VA Linux さんが、Zerocopy NFS 化してくれたとは言
え、POSIX セマンティクスを守るためには copy-in/copy-out が必
要
• メモリコピー！

物理メモリを全部 Registerしている！

read() -> NFSサーバがクライアントへ RDMA Write
write() -> NFSクライアントがサーバから RDMA Read


プログラマ目線から見たRDMAのメリットとその応用例について

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie プログラマ目線から見たRDMAのメリットとその応用例について

Ähnlich wie プログラマ目線から見たRDMAのメリットとその応用例について (20)

Mehr von Masanori Itoh

Mehr von Masanori Itoh (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)