Java ベースのワークロードを対象とした、クラウドでのトランスペアレントなネットワーク高速化

JSOR (Java Sockets over RDMA) ライブラリーの紹介

Java Sockets over RDMA (JSOR) は、Linux プラットフォーム向けの IBM SDK Java Technology Edition Version 7 に含まれる新しい通信ライブラリーです。JSOR は RDMA 対応の高速ネットワーク・アダプターを活用することにより、クラウド環境で実行されるクライアント・サーバー・アプリケーションのスループットを改善し、遅延を軽減します。JSOR の基礎となる技術について学び、このライブラリーの使い方を知り、JSOR のパフォーマンスを他の通信プロトコル・ベースのソリューションと比較しましょう。

Sivasakthi Thirugnanapandi, Java Developer, IBM

Sivasakthi Thirugnanapandi は、インドにある IBM Java Technology Center の開発者として 2006年以降、IBM Java クラス・ライブラリー・チームで Java コンポーネント、Java プラグイン、Java Web Start、automation/tooling/scripting、ツールおよびインフラストラクチャー・フレームワークに携わってきました。彼が関心を持っていることは、Java や C でコーディングをしたり、ポッドキャストを聴いたり、記事やブログを読んだりすることなどです。



Sreedhar Kodali, Software Engineering Researcher, IBM

Sreedhar Kodali は、15 年の IT キャリアのなかでもこの 13 年、多くの分野で各種プラットフォーム (Linux、UNIX、Windows、z/OS) およびアーキテクチャー (Intel、Power、System z) 上での製品開発に携わってきました。彼は、2007年から IBM に勤めており、ネットワーキング、パフォーマンス、I/O、ランタイム、仮想化、ツール、フレームワークといった領域で、X10 言語、IBM J9 仮想マシン、IBM Java SDK の実装に貢献してきました。



Neil Richards, Advisory Software Engineer, OpenJDK Developer, IBM

Neil Richards は現在、OpenJDK Java 8 および Java 7 の更新プロジェクトのコントリビューター兼コミッターをしています。彼が IBM Java Technology Center に初めて参加したのは、Java 1.1.4 に関する作業で、それ以降、ネットワーキング、シリアライズ、RMI、CORBA をはじめとするさまざまな分野で、IBM Java JVM およびクラス・ライブラリーを対象としたシニア開発者として勤めています。



Tim Ellison, Senior Technical Staff Member, IBM

20 年にわたって、Tim Ellison は Smalltalk、IBM VisualAge Micro Edition、Eclipse、Java SDK の商用実装に貢献してきました。彼は、ハイパフォーマンス・ランタイム、オープンソース手法、開発環境に関する広範な知識があり、テクニカル・カンファレンスで定期的にこれらのトピックについてのプレゼンテーションを行っています。



Xiaoqiao Meng, Research Staff Member, IBM

Xiaoqiao MengXiaoqiao Meng は、IBM T.J. Watson Research Center の研究スタッフ・メンバーであり、中国科学技術大学で学士号を、UCLA のコンピューター・サイエンスで博士号を取得しています。彼は現在、ミドルウェア・ソフトウェア、クラウド・コンピューティング、パフォーマンス評価に関する業務をしています。



Indrajit Poddar, Senior Software Engineer, IBM

Indrajit Poddar's photoIndrajit Poddar は、IBM Software Group Technical Strategy のソフトウェア・アーキテクトであり、そこでは戦略的テクノロジー領域でインキュベーション・プロジェクトを率いています。プロジェクトの例としては、分散クラウド・コンピューティング、DevOps、ソフトウェア定義インフラストラクチャーなどがあります。彼は、IBM Master Inventor であり、3 つの IBM Outstanding Technical Achievement アワードを受賞しています。



2014年 4月 24日

現在、クラウドにデプロイされた分散 Java アプリケーションのコンポーネント間の通信ロジックは TCP/IP ソケット・プログラミング技術を用いて実装されています。クラウド・データ・センターに高速ネットワーク (10/40/100Gbps イーサネットなど) が採用されるのに伴い、より高速なネットワーク通信技術 (RDMA (Remote Direct Memory Access) など) を使用できるようになっています。RDMA プログラムは通常、OFA (Open Fabrics Alliance) verbs などの下位レベルの API や、MPI (Message Passing Interface) などのハイパフォーマンス・コンピューティング・ツールを使用して C/C++ で作成されます。Java ベースのアプリケーションで、このような下位レベルの API に JNI (Java Native Interface) を介してアクセスすると、プログラミングが複雑になり、パフォーマンスのオーバーヘッドが大きくなります。Java 7 で使用可能な同等の手法である SDP (Sockets Direct Protocol) は、ワークロードが大きい場合に優れたパフォーマンスを示せておらず、もう 1 つの同等の手法である R-Sockets (RDMA Sockets) は C/C++ プログラムでしか使用することができません。

この記事では、Java 専用で Linux ソケットに対応した新しい RDMA 通信ライブラリーを紹介します。このライブラリーは JSOR (Java Sockets over RDMA) と呼ばれ、Linux/AMD64 プラットフォームおよび Linux/Intel プラットフォーム上で IBM Java SDK 7SR6 の一部です。ここでは、JSOR の使い方と JSOR を使用するメリットについて、単純な Java クライアント・サーバー・プログラム (「ダウンロード」を参照) を使用して説明します。このプログラムは Java ソケット・インターフェースを使用して作成されており、何もコードを変更せずに RDMA 対応のクラウド・インフラストラクチャー上で実行することができます。

背景

クラウド環境にデプロイされる典型的な Java クライアント・サーバーのシナリオでは、多くの場合、サービス・リクエストに対する応答時間は、リクエスト送信側とサービス提供側ホストとの間のネットワーク接続の応答時間によって制限されます。通常、リモート・エンドポイント間のやりとりを実現するネットワーク通信ロジックでは、Java ソケット・インターフェースを使用して接続を確立し、データを転送します。デフォルトで、Java ソケット・インターフェースは POSIX ソケット API ベースで実装されます。すべてのネットワーク・オペレーションは、その下位にあるオペレーティング・システムを通過してから、ネットワーク・インターフェースに到達しなければなりません。このことから、コストがかかる OS コンテキスト・スイッチや、ソフトウェア・レイヤー間での複数回のバッファー・コピーを伴うことになります。

特殊用途のネットワーク・インターフェース・カード (NIC) に付属の TCP/IP プロトコル負荷軽減専用エンジンを使用すると、ネットワーク処理のオーバーヘッドを軽減することができます。しかし、そうした負荷軽減手法にも、やはり何らかのバッファー・コピー・ステップが必要です。クラウドの採用が広がるにつれ、クラウド・コンピューティングの帯域幅増加要求に対応するために、多くの企業のデータ・センターはネットワーク・リンクを 10Gbps イーサネットから 40Gbps イーサネットへと移行し始めています。

RDMA はハードウェア・ベースのプロトコル負荷軽減技術であり、最初は InfiniBand や高速イーサネットなどのハイパフォーマンス・ネットワーク・ファブリック用に提案されたもので、2 つのリモート・アプリケーションのメモリー間で直接データ転送を行い、いずれのホスト・プロセッサーの介在も必要としません。RDMA により、コストのかかる OS コンテキスト・スイッチが不要となる可能性があり、CPU サイクル数を大幅に削減できる可能性があります。このメッセージ・ベースのプロトコルはハイパフォーマンス・ネットワーク専用に定義されているため、アプリケーションは向上したネットワーク速度を活かして、10 ミリ秒未満のレイテンシーを実現することができます。

RoCE (RDMA over Converged Ethernet) 標準の登場により、既存の高速 10/40Gbps イーサネット・インフラストラクチャー上で RDMA プロトコルを直接使用できるようになりました。つまり従来の TCP/IP スタックから RDMA ベースのネットワーク処理に移行することにより、一部のクラウド・ベースのアプリケーションは CPU リソースの使用を減らす一方でレイテンシーやスループットの向上を期待できる可能性があります。

SDP は RDMA をサポートする InfiniBand や RoCE などのネットワーク・ファブリック向けに定義された標準的なワイヤー・ベースのプロトコルであり、ストリーム・ソケット・ベースのアプリケーションをトランスペアレントに高速化します。Java 7 以降では、JDK には Linux プラットフォームや Solaris プラットフォームでの SDP サポートが含まれています。しかし、SDP はカーネル・ベースの実装であり、バッファー・コピーやコンテキスト・スイッチのオーバーヘッドによってパフォーマンスが低下します。

以下のセクションでは、JSOR について紹介するとともに、JSOR を使用する方法について説明します。JSOR は完全にユーザー空間のソリューションであり、カーネルをバイパスし、ネイティブ RDMA ベースの類似ソリューションと同等のパフォーマンスを実現することができます。


JSOR について

JSOR はクラウド・ネットワークを高速化する機能であり、ベースのインフラストラクチャーが RDMA をサポートしている場合、Java ストリーム・ソケットの RDMA 通信をトランスペアレントに実現します。JSOR は標準的な Java ソケット・ライブラリーの中にハイパフォーマンスの RDMA ワイヤー・プロトコルを組み込んでいます。現在、java.net.Socket APIjava.net.ServerSocket API、そしてその関連入出力ストリームがサポートされているため、既存の Java クライアント・サーバー・アプリケーションの大部分は、何も手を加えずに最初からパフォーマンスの改善を期待することができます (この記事で後ほど説明する「JSOR を選択する」を参照)。

JSOR の設計についての簡単な説明

従来のクラウド・ネットワーキングのシナリオでは、アクセス・ノードとサービス・ノードとの間のやりとりは、すべて 1 つ以上のイーサネット・スイッチを介してワイヤー上を流れるパケットとして処理されます (図 1)。

図 1. 従来のクラウド・ネットワーキング
従来のクラウド・ネットワーキングを示す図

ネットワーク・オペレーション (接続関連か、データ転送関連かを問わず) が実行されるたびに、1 つ以上の Java ソケット呼び出しが実行されます。Java レベルでソケット操作が実行されると、その操作に対応するネイティブ (C または C++) ライブラリー操作が JNI レイヤーを通して呼び出されます。JNI レイヤーで実行される呼び出しの前後には、一定量の前処理と後処理が Java レベルで行われます。TCP/IP プロトコルは OS カーネル・スタックによって処理されるため、JNI ソケット固有のメソッドが実行されると、必ずコンテキスト・スイッチが発生します。転送や受信の場合にも、Java、OS、NIC レベルで何度もバッファー・コピーが必要です。バッファー・コピーや CPU コンテキスト・スイッチの繰り返しによるネットワーク処理のオーバーヘッドによって、ネットワーク・レイテンシーが大きくなり、スループットが低下します。

JSOR ライブラリーは、OFED (Open Fabric Enterprise Distribution) に含まれる R-Sockets ライブラリーの R-Sockets プロトコルに対応しており、JSOR ライブラリー自身を一般的な Java アプリケーションの要求に適したライブラリーにするための変更が含まれています。JSOR ライブラリーを使用すると、スケーラビリティー、信頼性、保守性を大幅に向上させることができます。

SDP や TCP/IPoIB (TCP/IP over InfiniBand) と比べ、一般に JSOR の方が高いパフォーマンスを発揮します。マイクロベンチマークを使用した私たちの実験では、JSOR は SDP よりも 50 パーセントも高いスループット、そして IPoIB よりも 100 パーセント以上高いスループットを実現することができました。この優れたパフォーマンスは主に、JSOR は標準的な Java クラス・ライブラリーの一部であるため、Java ソケットの実装を最適化できることによるものです。例えば、JSOR は JNI の境界をまたぐデータ・コピーを回避し、ソケットに関する多様なセマンティクスを適切にサポートし、ソケットの使用パターンに応じて RDMA パラメーターを自動調整します。また IPoIB や SDP はカーネル・ベースのトランスポート・ソリューションですが、JSOR は完全にユーザー空間にあるため、データ・パスを短縮し、カーネルのオーバーヘッドを軽減することができます。

図 2 に示すように、JSOR は Java ソケット呼び出しを Java レベルでインターセプトし、下位の RDMA インフラストラクチャーを介してルーティングします。JSOR を使用するには、Java の実行時に JSOR を有効にするためのプロパティーを指定し、適切な構成ファイルを参照するように設定する必要があります。TCP/IP から RDMA への切り換えが起きると、アプリケーションとリモートの相手とのやりとりはすべて、下位の RDMA ハードウェアを通じて行われるようになります。

図 2. 高速化されたクラウド・ネットワーキング
高速化されたクラウド・ネットワーキングを示す図

JSOR を使用する

JSOR を使用する前に、クラウド実行環境が以下の前提条件を満たしている必要があります。

  • ホストは適切な HCA (Host Channel Adapter) または RDMA NIC を備え、ハイパフォーマンスの InfiniBand またはイーサネット・スイッチド・ファブリックでリモート・ホストと接続されている必要があります。
  • 各参加ホストに OFED 1.5.1 またはそれ以降のベース・ランタイム・ライブラリーがインストールされている必要があります。特に、JSOR は実行時に libibverbs.so ライブラリーと librdmacm.so ライブラリーを検索して関数ポインターを動的にロードします。
  • アプリケーションの要求に応じて、ユーザー・アカウントはロック可能な適量の (できれば無制限の) メモリーを利用できる必要があります。JSOR ソケット・バッファーはデフォルトでメモリーに固定されています。そのため、データ転送の重要なフェーズで OS がそれらのバッファーをスワップしてしまうことはありません。Linux の場合には、ulimit -l シェル・コマンドを使用することで、ロックされるメモリーが最大どの程度に設定されているかを表示することができます。

これらの基本的要件が満たされている場合、プレーン・テキスト・フォーマットの構成ファイルがクライアントとサーバー両方のエンドポイントに必要です。この構成ファイルの各レコード (つまり、各行) には、accept、bind、または connect ルールを指定する必要があり、少なくともホワイト・スペースで区切られた以下の 4 つのフィールドを含んでいる必要があります。

  • 第 1 のフィールドには、ネットワーク・プロバイダーのタイプを指定します。現状では rdma プロバイダーのみが利用できます。
  • 第 2 のフィールドには、どのルールを指定するかに応じて acceptbindconnect キーワードを指定します。
  • 第 3 のフィールドには、指定されるルールが accept または bind の場合はローカル IP アドレスを指定し、指定されるルールが connect の場合はリモート IP アドレスを指定します。
  • 第 4 のフィールドには、RDMA トラフィックが許可されるポートまたはポート・セットを指定します。基本的に、第 3 のフィールドと第 4 のフィールドの両方で、RDMA 専用の接続確立やデータ転送のための一連のソケット・エンドポイントを定義します。
  • 第 5 のフィールドとそれ以降のフィールドには、accept ルールにのみ適用され、受信する RDMA 接続リクエストを受け付ける際に使用するクライアント IP アドレスのリストを指定します。

サービス (パッシブ) サイドの構成ファイルには accept または bind エントリーが存在している必要があり、クライアント (アクティブ) サイドの構成ファイルには connect または bind エントリーが存在している必要があります。

例えば、サービス・ホスト192.168.1.1 のクライアント 192.168.1.3 と 192.168.1.4 からポート 65444 で RDMA 接続を受け付ける場合、Java アプリケーション・サーバーの構成ファイルに以下のルールが必要です (このファイルを rdma_server.conf と呼ぶことにします)。

rdma    accept    192.168.1.1    65444    192.168.1.3    192.168.1.4

同様に、いずれかのクライアントから、ポート 65444 をリッスンするサービス・ホスト 192.168.1.1 に RDMA 接続を要求する場合には、Java クライアント・アプリケーションの構成ファイルに以下のルールが必要です (このファイルを rdma_client.conf と呼ぶことにします)。

rdma    connect    192.168.1.1    65444

特定のローカル・アドレスに明示的にバインドする場合を除き、クライアント・サイドではエフェメラル・ポートを使用してサービス・エンドと接続を確立します。以下の例では rdma_client.conf ファイルに bind ルールを追加しており、クライアント・エンドでの RDMA 接続をポート 65333 で確立しています。

rdma    connect    192.168.1.1    65444
rdma    bind       0.0.0.0        65333

bind ルールの第 3 のフィールド (0.0.0.0) はヌル・アドレスを参照しており、このフィールドのデフォルトはローカル・ホストで最初に利用可能な InfiniBand アドレスになります。

構成ファイルを準備したら、Java コマンドを実行する際の com.ibm.net.rdma.conf プロパティーの値として、その構成ファイルを指定します。例えば、パッシブ (サービス) サイドでは以下のように設定します。

java -Dcom.ibm.net.rdma.conf=rdma_server.conf SampleServer args

アクティブ (クライアント) サイドでは以下のように設定します。

java -Dcom.ibm.net.rdma.conf=rdma_client.conf SampleClient args

リスト 1 はサーバー・ソケットを作成してリモート・エンドからの接続を待機する SampleServer クラスの一部を示しています。接続が確立されると、サーバーは指定したバイト数をクライアントから受信し、同じバイト数をクライアントに送信します。この送受信が 1 回の繰り返しの中で行われ、指定回数だけ送受信が繰り返されます。

リスト 1. SampleServer.java
 // Create server socket to listen on x.x.x.x address and x port
 ServerSocket server = new ServerSocket(Integer.parseInt(args[1]), 0, InetAddress.getByName(args[0]));
 ...
 Socket client = server.accept();
 ...
 // Receive and send message specified number of times
 for (int i = 0; i < xferCount; i++) {
     in.read(msgBuf, 0, msgSize);
     out.write(msgBuf, 0, msgSize);
}

リスト 2 はリモート・サービス・ホストとの接続を要求する SampleClient クラスの一部を示しています。接続が確立されると、クライアントは指定したバイト数をサーバーに送信し、同じバイト数をサーバーから受信します。この送受信が 1 回の繰り返しの中で行われ、指定回数だけ送受信が繰り返されます。

リスト 2. SampleClient.java
// Create client socket to connect x.x.x.x address and x port
 Socket client = new Socket(InetAddress.getByName(args[0]), Integer.parseInt(args[1]));
 ...
long startTime = System.nanoTime();
for (int i = 0; i < xferCount; i++) {
    out.write(msgBuf, 0, msgSize);
    in.read(msgBuf, 0, msgSize);
}
 long endTime = System.nanoTime();

SampleClient.java では全体としての送受信シーケンスの時間を測定し、送受信される総バイト数に対する RTT (Round-Trip Time: ラウンド・トリップ時間) を計算できるようにしています。

実行テストの例

私たちはさまざまなプロトコルの RTT を比較するために、メッセージ・サイズ 4KB、繰り返し回数 1,000 回で以下のサンプル・テストを実行しました。これらのテストを実行したテスト・ベッドは 2 台の IBM HS22 ブレード・サーバーで構成され、Voltaire 40Gbps InfiniBand スイッチで接続されています。各サーバーは Red Hat Enterprise Linux (RHEL) v61 を実行し、8 コアの Intel Xeon CPU L5609 (1.87GHz) と 148GB のメモリー、そして Mellanox MT26428 ConnectX VPI PCIe カードを搭載しています。

JSOR — SampleClient ログ
$ cat rdma_client.conf
rdma connect 7.7.12.10 65444
$ java - Dcom.ibm.net.rdma.conf=rdma_client.conf SampleClient 7.7.12.10 65444 1000 4096
Client Ready>
Local: /7.7.12.9:40563 Remote: /7.7.12.10:65444
SBuf: 32768 bytes RBuf: 45056 bytes
Round trip time of 4096000 bytes: 27313 usec
JSOR — SampleServer ログ
$ cat rdma_server.conf
rdma accept 7.7.12.10 65444 7.7.12.9
$ java -Dcom.ibm.net.rdma.conf=rdma_server.conf SampleServer 7.7.12.10 65444 1000 4096
Server Ready>
Local: /7.7.12.10:65444 Remote: /7.7.12.9:40563
SBuf: 32768 bytes RBuf: 45056 bytes
Received/Sent 4096000 bytes
SDP — SampleClient ログ
$ cat sdp_client.conf
bind * *
connect 7.7.12.10 65444
$ java -Dcom.sun.sdp.conf=sdp_client.conf 
-Djava.net.preferIPv4Stack=true SampleClient 7.7.12.10 65444 1000 4096
Client Ready>
Local: /7.7.12.9:39156 Remote: /7.7.12.10:65444
SBuf: 8388608 bytes RBuf: 8388608 bytes
Round trip time of 4096000 bytes: 33836 usec
SDP — SampleServer ログ
$ cat sdp_server.conf
bind * *
connect 7.7.12.10 65444
$ java -Dcom.sun.sdp.conf=sdp_server.conf 
-Djava.net.preferIPv4Stack=true SampleServer 7.7.12.10 65444 1000 4096
Server Ready>
Local: /7.7.12.10:65444 Remote: /7.7.12.9:39156
SBuf: 8388608 bytes RBuf: 8388608 bytes
Received/Sent 4096000 bytes
IPoIB — SampleClient ログ
$ java SampleClient 7.7.12.10 65444 1000 4096
Client Ready>
Local: /7.7.12.9:40666 Remote: /7.7.12.10:65444
SBuf: 99000 bytes RBuf: 174752 bytes
Round trip time of 4096000 bytes: 98848 usec
IPoIB — SampleServer ログ
$ java SampleServer 7.7.12.10 65444 1000 4096
Server Ready>
Local: /7.7.12.10:65444 Remote: /7.7.12.9:40666
SBuf: 99000 bytes RBuf: 174752 bytes
Received/Sent 4096000 bytes
TCP/IPoE — SampleClient ログ
$ java SampleClient 9.42.84.20 65444 1000 4096
Client Ready>
Local: /9.42.84.26:48729 Remote: /9.42.84.20:65444
SBuf: 32768 bytes RBuf: 43690 bytes
Round trip time of 4096000 bytes: 194224 usec
TCP/IPoE — SampleServer ログ
$ java SampleServer 9.42.84.20 65444 1000 4096
Server Ready>
Local: /9.42.84.20:65444 Remote: /9.42.84.26:48729
SBuf: 32768 bytes RBuf: 43690 bytes
Received/Sent 4096000 bytes

表 1 はテストした各プロトコルの RTT を示しています。

表 1. サンプル・テストの RTT
プロトコル送受信バイトの総数RTT (マイクロ秒)
JSOR4,096,00027,313
SDP4,096,00033,836
IPoIB4,096,00098,848
TCP/IP4,096,000194,224

表 1 が示すように、JSOR は他のプロトコルよりもパフォーマンスが優れています。


JSOR をトレースする

クラウド・ベースの Java アプリケーションを JSOR モードで実行する場合、接続の確立とデータ転送用にアプリケーションが RDMA パスを選択していることを必ず確認することが重要です。JSOR が有効かどうかはアプリケーションから見えないようになっているため、通常のモードで簡単に確認することはできません。ただし IBM JDK のトレース・オプションをオンにすると、サービス・レベルのビューを表示することができます。できれば、Java メソッドのトレースと JSOR/NET ネイティブのトレースの両方をオンにし、全体を把握できるようにします。JSOR 対応のアプリケーションでトレース・オプションを呼び出すには、通常は以下のようにします。

java -Dcom.ibm.net.rdma.conf=config_file 
   -Xtrace:methods={java/net/RDMA*.*},iprint=mt,iprint=NET,iprint=JSOR main_class args

例えば、トレースを有効にして JSOR モードで SampleClient アプリケーションと SampleServer アプリケーションを再度実行してみましょう。

SampleClient でトレースを呼び出すには以下のようにします。

java -Dcom.ibm.net.rdma.conf=rdma_client.conf 
   Xtrace:methods={java/net/RDMA*.*},iprint=mt,iprint=NET,iprint=JSOR 
   SampleClient 7.7.12.10 65444 1000 4096

SampleServer でトレースを呼び出すには以下のようにします。

java -Dcom.ibm.net.rdma.conf=rdma_server.conf 
   -Xtrace:methods={java/net/RDMA*.*},iprint=mt,iprint=NET,iprint=JSOR 
   SampleServer 7.7.12.10 65444 1000 4096

リスト 3 は、この 2 つの呼び出しで生成されたトレース・ログの一部を示しています。

リスト 3. JSOR トレース・ログのサンプル
04:26:27.500 0x21e3e100  mt.0 >java/net/RDMANetworkProvider.initialize()V Bytecode method, This=21e02468
04:26:27.500 0x21e3e100  mt.2  >java/net/RDMANetworkProvider.initialize0()I Native method, This=21e02468
04:26:27.501 0x21e3e100   NET.440  >initialize0(env=0000000021E3E100, obj=0000000021E73B40)
04:26:27.502 0x21e3e100  JSOR.0     >RDMA_Init()
04:26:27.502 0x21e3e100  JSOR.39    >initverbs()
04:26:27.502 0x21e3e100  JSOR.43     <initverbs(rc=0)
04:26:27.502 0x21e3e100  JSOR.46    >initjsor()
04:26:27.502 0x21e3e100  JSOR.47    <initjsor(rc=0)
04:26:27.502 0x21e3e100  JSOR.3    <RDMA_Init(rc=0)
04:26:27.502 0x21e3e100  NET.441 <initialize0(rc=0)
04:26:27.502 0x21e3e100  mt.8  <java/net/RDMANetworkProvider.initialize0()I Native method
04:26:27.502 0x21e3e100  mt.6  <java/net/RDMANetworkProvider.initialize()V Bytecode
method

JSOR にはネイティブ・レベルで 200 を超えるトレース・フックがあります。そのため、簡単なアプリケーションであってもトレース・ファイルはすぐに大きなものになります。例えば SampleServer と SampleClient をトレース・モードで実行すると、トレース・ログは約 7.5MB になります。


JSOR を選択する

RDMA の優れた点を活かせるのは、ネットワーク I/O インテンシブでレイテンシーが重要なワークロードのみであることに注意する必要があります。JSOR を使用すると決める前に、エンド・ツー・エンドでのワークロードのレイテンシーを見積もることをお勧めします。より多くのメリットを得られる可能性があるのは、以下の 2 つのタイプのアプリケーションです。

  • 分散コンポーネント間で長時間接続して大量のデータを転送するアプリケーション。従来の TCP/IP ソケットに比べ、JSOR は接続確立に少し長い時間を要し、またヒープ外に大量のロック可能なメモリーを必要とします。
  • ネットワーク通信ごとにデータ・バッファーの動的割り当てをしないアプリケーション。必要に応じてバッファーが動的に割り当てられる TCP/IP とは異なり、JSOR は明示的なバッファー管理を必要とします。アプリケーションのメッセージ・サイズのばらつきが少なく、メッセージの最大サイズが事前にわかっている場合には、JSOR は静的にバッファーを割り当てることができます。

まとめ

この記事では、Linux/AMD64 プラットフォームおよび Linux/Intel プラットフォーム向けの IBM Java 7SR6 に含まれている、JSOR (Java Sockets over RDMA) という IBM JDK の機能を紹介しました。まずは、JSOR を支える技術について説明するとともに、TCP/IP プロトコルや SDP プロトコルをベースとする既存のソリューションと JSOR との比較を行いました。そして、サンプルのクライアント・サーバー・プログラムと、関連する構成ファイルを使用しながら、クラウド・ベースの環境で JSOR を使用するための手順を概説しました。また、ローカルのテスト・ベッドでサンプル・プログラムを実行することにより、SDP、IPoIB、TCP/IP プロトコルよりも JSOR の方が RTT が短いことを示しました。さらには、アプリケーションのエンドポイントの通信に RDMA パスが使用されているかどうかを確認するために使用できる、サービス・レベルのトレース・オプションについて説明しました。最後に、JSOR の利点を活かせるアプリケーションを選択するためのガイドラインを示しました。


ダウンロード

内容ファイル名サイズ
Sample codeSample_Code.zip3KB

参考文献

学ぶために

製品や技術を入手するために

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、Wiki を調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology, Cloud computing
ArticleID=968478
ArticleTitle=Java ベースのワークロードを対象とした、クラウドでのトランスペアレントなネットワーク高速化
publish-date=04242014