Jump to content 日本-日本語
製品  >  HP ProLiant サーバ  >  技術情報  >  White Paper

whitepaper

技術資料

HP ProLiant サーバ

目次

概要/ はじめに/ TCP/IPの制限/ RDMAソリューション
  RDMA over TCP
  RDMA over InfiniBand
  まとめ/ 詳細情報 / ご意見をお寄せください

PDFファイル ダウンロード

このホワイトペーパーのPDFファイルをこちらからダウンロードしてご覧下さい。
(PDFファイル、144KB)
コンテンツに進む

RDMAプロトコル: ネットワークパフォーマンスの向上

RDMA over TCP

  イーサネットは、今日最も多く使用されているネットワークインターコネクトです。IT部門がイーサネットテクノロジに費やした額は莫大なので、大部分の人たちは、現在のネットワークを解体、交換することを望んでいません。イーサネットへの信頼には、コストの低さ、後方互換性、および長期にわたり一貫して継続されてきた帯域幅の増大といった、もっともな理由があります。現在のイーサネットネットワークでは、TCP/IP処理を使用しており、通常、100Mb/sおよび1Gb/sで動作します。次世代の速度は10Gb/sに達します。10Gbイーサネットに移行するとTCP/IP処理がサーバにもたらす入出力(I/O)処理の負荷も増大するため、移行のテンポは抑えられています。

イーサネットにRDMA機能を追加すると、ホストプロセッサ使用率を抑えることができ、10Gbイーサネットに移行するメリットが増大します。RDMA機能をイーサネットに追加すると、データセンターは、全体のパフォーマンスへの影響を抑えながらインフラストラクチャを拡張することができます。これによって、インフラストラクチャの柔軟性が向上し、将来的な要件に適応させることができます。

RDMA over TCPは、2つのシステム(ノード)上にあるアプリケーションのメモリ間でデータを直接転送する通信プロトコルで、オペレーティングシステムのカーネルの仕事量を最小限に抑え、システムバッファへの暫定的なデータコピーも行われません(図2)。このため、RDMA over TCPは、今日データセンターで一般に使われている標準的なTCP/IPベースのネットワーク(イーサネット)上で動作することができます。RDMA over TCPは物理レイヤーを特定せず、TCP/IPを使用するあらゆるネットワーク上で動作します。

図2. RDMA over TCP (イーサネット)を使用したデータフロー
図 2. RDMA over TCP ( イーサネット ) を使用したデータフロー

RDMA over TCPでは、多くの種類のトラフィック(ネットワーキング、I/O、ファイルシステムとブロックストレージ、およびプロセス間通信)で同一の物理的なインターコネクトを共有できるため、その物理的なインターコネクトがデータセンターファブリックを統一することができます。RDMA over TCPを使用すると、ネットワーク通信の効率が向上し、プロセッサを酷使するアプリケーションのスケーラビリティも向上します。RDMA over TCPはまた、既存のイーサネット インフラストラクチャや、ITネットワーク担当者の専門知識を有効に活用します。
 

RDMAプロトコルの概要

RDMA over TCPを実行する一連のプロトコルはレイヤー化されています(図3)。上位3レイヤは、高速インターネット動作を提供するプロトコルのiWARPファミリを形成します。RDMAプロトコルはRDMA writeとRDMA readを変換し、DDP (Direct Data Placement)メッセージに送信します。DDPプロトコルはアウトバウンドのDDPメッセージを1つまたは複数のDDPセグメントに分割し、あるいは逆に、1つまたは複数のDDPセグメントをDDPメッセージに再アセンブルします。MPA (marker-based protocol-data-unit-aligned)プロトコルはDDPセグメントに一定間隔で逆変換マーカーを付加します。また、各MPAセグメントに長さとCRCを付加します。TCPはアウトバウンドのTCPセグメントをスケジュールし、配信保証要件を満たします。IPは必要なネットワーク ルーティング情報を付加します。

図3. RDMA over TCP用のプロトコルレイヤー
図3. RDMA over TCP用のプロトコルレイヤー

TCPは8ビットフィールド(オクテット)のストリームを使用してデータを送信しますが、DDPは固定プロトコルデータユニット(PDU: Protocol Data Unit)を使用します。RDMAを有効にするために、DDPはTCPトランスポートプロトコル用のフレーム化メカニズムを必要とします。MPAは、TCPプロトコル用の、マーカーに基づく、PDUに揃えられたフレーム化メカニズムです。

MPAは、DDPを使用するネットワークアダプタがDDPヘッダーを見つけられるようにするための汎用フレーム化メカニズムです。それにより、ヘッダーに含まれている制御情報に基づいて、アダプタがアプリケーションバッファに直接データを置くことが可能になります。

MPAは、パケットが順不同で到着した場合にもこの役割を果たすことができます。DDPを有効にすることにより、MPAはメモリコピーのオーバーヘッドを省き、アウトオブオーダーパケットや欠損パケットを処理するためのメモリ要件を低く抑えることができます。 MPAはヘッダーをDDPセグメントの先頭に付加し、マーカーを挿入し、CRCを末尾に付加して、フレーム化されたPDU (FPDU)を作成します。MPAはFPDUをTCPに引き渡します。MPA対応のTCPセンダーはFPDUをTCPストリームに入れ、そのTCPストリームをセグメント化して、各TCPセグメントにFPDUが1つだけ含まれるようにします。MPAレシーバはFPDU一式のストリーム内での位置を確認してアセンブルし、完全性を検証して、不要になった情報を削除します。続いてMPAは、完成したDDPセグメントをDDPに渡します。

DDPを使用すると、DDPセグメントに含まれるアプリケーション メッセージやディスクI/Oなどの上位レイヤープロトコル(ULP: Upper Layer Protocol)データを、ULPによる処理を経ずに、メモリ内の最終目的地に配置できます。これはDDPセグメントが順不同で到着した場合にも可能です。 DDPセグメントは、DDPプロトコルにおけるデータ転送の最小単位です。DDPヘッダーとULPペイロードが含まれています。DDPヘッダーには、ペイロード(転送される実データ)の最終目的地を定義している制御フィールドと配置フィールドがあります。

DDPメッセージはULPで定義されたデータ交換の単位で、1つ以上のDDPセグメントにさらに分割できます。このセグメンテーションは、TCPの最大セグメントサイズを尊重するためのセグメンテーションなど、さまざまな理由で起こります。一連のDDPメッセージをDDPストリームと言います。

DDPは、タグ化バッファモデルと未タグ化バッファモデルの2つのデータ転送モデルを使用しています。

タグ化バッファモデルは、転送を行う二者(ローカルピアとリモートピア)間でタグ化バッファを送信するのに使用されます。タグ化バッファは、ステアリングタグ(STag)、タグ化オフセット、および長さの交換を通じてリモートピアに明示的に通知されます。STagはただのノード上のタグ化バッファの識別子で、タグ化オフセットはバッファのベースアドレスを特定するものです。タグ化バッファは、通常、大規模データ構造やディスクI/Oなどの大規模データの転送に使用されます。

未タグ化バッファモデルは、ローカルピアからリモートピアに未タグ化バッファを送信するのに使用されます。未タグ化バッファはリモートピアに明示的に通知されません。未タグ化バッファは、通常、処理メッセージやI/O状態メッセージなどの小規模な制御メッセージ用に使用されます。

RDMAデータ転送処理

RDMAプロトコルには、7個のデータ転送処理があります。RDMA read処理を除く各処理では、RDMAメッセージが1個だけ生成されます。

RDMA情報はDDPヘッダー内のフィールドに含まれています。 RDMA対応のネットワークインタフェースコントローラ(RNIC)を使用すると、データターゲットのホストプロセッサもデータソースのホストプロセッサもデータ転送処理に関与しないため、ホストプロセッサではより有意義な作業を継続できます。RNICは、RDMA送信パケットの生成と、RDMA着信パケットの処理を担当します。データは、アプリケーションがデータの位置として示した場所から取り出され、受け入れ場所として通知する場所に直接置かれます。これにより、従来のオペレーティングシステムのプロトコルスタックで、送信側と受信側の両方で発生していたデータコピーが不要になります。

【送信処理】
RDMAが使用する送信処理には4つのバリエーションがあります。
  • Send処理
  • Send with invalidate処理
  • Send with solicited event
  • Send with solicited event and invalidate
  Send処理では、データソース(データペイロードの送信側)から、データターゲット(データペイロードの受信側)が明示的に通知していないバッファにデータが転送されます。Sendメッセージは、DDP未タグ化バッファモデルを使用して、ULPメッセージをデータターゲットの未タグ化バッファに転送します。Send処理は、通常、DDP用のSTag作成のオーバーヘッドが大きすぎて、データコピーで消費される少量のメモリ帯域幅に見合わない場合に、少量の制御データを送信するのに使用されます。

Send with invalidateメッセージには、Sendメッセージのすべての機能と、あらかじめ通知されたSTagを無効にする機能が含まれています。メッセージがデータターゲットに配置、配信されると、メッセージに含まれるSTagによって特定されたデータターゲットのバッファはリモートからアクセスできなくなります。この状態は、データターゲットのULPによりアクセスが再び可能になり、バッファが再び通知されるまで続きます。

Send with solicited eventメッセージはSendメッセージに似ていますが、Send with solicited eventメッセージが配置、配信されると、インタラプトなどのイベントが受信側で生成される点が異なります(受信側でそうしたイベントを生成するように設定されている場合)。これを使用すると、受信側で発生するインタラプトオーバーヘッドの量を制御できます。

Send with solicited event and invalidateメッセージは、Send with invalidateメッセージと、Send with solicited eventメッセージを合わせた機能を持ちます。

【RDMA write】
RDMA write処理は、RDMA writeメッセージを使用して、データソースから、データターゲット側のあらかじめ通知されたバッファにデータを転送します。データターゲット側のULPは、データターゲットのタグ化バッファのアクセスを有効にし、Prior sendメッセージなどのULP特有のメカニズムを使用して、バッファのサイズ(長さ)、場所(タグ化オフセット)、およびSTagをデータソースに通知します。データソース側のULPはRDMA write処理を開始します。RDMA writeメッセージは、DDPタグ化バッファモデルを使用して、ULPメッセージをデータターゲットのタグ化バッファに転送します。タグ化バッファに関連付けられたSTagは、データターゲット側のULPにより、Send with invalidate処理またはSend with solicited event with invalidate処理を使用して無効にされるまで有効です。

【RDMA read】
RDMA read処理は、データソース側のタグ化バッファから、データターゲット側のタグ化バッファにデータを転送します。データソース側のULPは、データソースのタグ化バッファのアクセスを有効にし、Prior sendメッセージなどのULP特有のメカニズムを使用して、バッファのサイズ(長さ)、場所(タグ化オフセット)、およびSTagをデータソースに通知します。データターゲット側のULPは、データターゲットのタグ化バッファのアクセスを有効にし、RDMA read処理を開始します。RDMA read処理は、1つのRDMA read requestメッセージと1つのRDMA read responseメッセージから構成されており、これらのメッセージは複数のDDPセグメントにセグメント化される可能性があります。

RDMA read requestメッセージは、DDP未タグ化バッファモデルを使用して、データソースのRDMA read requestキューに、STag、開始タグ化オフセット、およびデータソース側とデータターゲット側両方のデータターゲットタグ化バッファの長さを配信します。このメッセージを受信するとデータソースはメッセージを処理してread responseメッセージを生成し、このメッセージがデータを転送します。

RDMA read responseメッセージは、DDPタグ化バッファモデルを使用して、データソースのタグ化バッファをデータターゲットに配信します。このときデータソース側のULPは関与しません。

タグ化バッファに関連付けられたデータソースのSTagは、データソース側のULPか、データターゲット側のULPにより、Send with invalidateまたはSend with solicited event and invalidateを使用して無効にされるまで有効です。タグ化バッファに関連付けられたデータターゲットのSTagは、データターゲット側のULPにより無効にされるまで有効です。

【Terminate】
Terminate処理は、エラーが発生したときにコネクションの強制切断を実行するために用意されています。
Terminate処理は、データソース側で発生したエラーに関連付けられた情報をデータターゲットに転送します。
Terminateメッセージは、DDP未タグ化バッファモデルを使用して、メッセージをデータターゲットの未タグ化バッファに転送します。

Verbs

  RDMA Verbs Specificationには、RNICへの抽象インタフェースが記述されています。RNICは、MPA over TCPなどの信頼性のあるトランスポートの上位にRDMAプロトコルを実装します。RDMA Verbsは、RNICインタフェースのセマンティクス上の定義を提供します。

Verbsコンシューマは、RNICの機能を使用して一定の目的を果たします。Verbsコンシューマは、オペレーティングシステム カーネルスレッド、非特権アプリケーション、特別な特権プロセスとして定義されます。RDMAはVerbsコンシューマに、データ配置を制御し、データコピー処理を不要にし、通信オーバーヘッドおよびレイテンシを大幅に減少させる能力を提供します。これは、Verbsコンシューマに対して、別のVerbsコンシューマのメモリに情報を直接置くことを許すことによって実現されます。このとき、オペレーティングシステムやメモリ保護のセマンティクスは維持されています。図4は、特権モードコンシューマ、非特権モードコンシューマ、RNICコンポーネント、およびRNICインタフェースを含むRNIC処理で使用される要素の概念モデルです。

図4. RNIC処理のモデル
図4. RNIC処理のモデル

RNICインタフェース

  RNICインタフェースは、RNICサービスのコンシューマとRNICを協調させる役割を果たします。Verbsは、RNICの動作を指定し、キューペアの作成と管理、RNICの管理、作業要求の管理、RNICインタフェースからのエラー通知の転送を可能にします。

RNICインタフェースの基本的な機能はRNICの管理です。これには、RNICへのアクセスのアレンジ、RNICの属性へのアクセスと変更、およびRNICのシャットダウンが含まれます。

キューペア(QP)は、RNICインタフェースの動作に必要な主要コンポーネントで、コンシューマが作業要求をRNICインタフェースに送信するのに使用するRNICリソースです。キューペアは、RNIC上のRDMAストリームと相互作用するために使用されます。RNIC 1枚あたり、何千ものキューペアがあることがあります。各キューペアは、個別のRDMAストリームへの単一のアクセスポイントをコンシューマに提供します。

キューペアは、送信キューと受信キューで構成されています。Send、RDMA read、RDMA writeなどの処理は、作業要求により送信キューにポストされます。受信キューには、到着するSendメッセージ用のバッファ情報が含まれています。作業要求は、コンシューマがキューペアの送信キューと受信キューに作業キュー要素を置くためのメカニズムです。

完了キュー(CQ)を使用すると、コンシューマは作業要求の完了状態を取得することができます。通知メカニズムは、RNICインタフェースで作業要求の処理がいつ完了したかをコンシューマが特定できるようにするために提供されています。RNIC 1枚あたり、何千もの完了キューがあり、コンシューマが要求する送信キューと受信キューの任意の組み合わせに関連付けられているということもあります。

イベントハンドラは、RNICインタフェース内で発生したが、非同期であるか、作業の完了と容易に関連付けられないという理由で完了キューを使用して報告できない非同期イベントをコンシューマに通知するメカニズムです。

前のページへ 次のページへ
PDFファイルをご覧いただくには、Adobe® Reader® が必要です。
アドビシステムズ社のウェブサイト より、ダウンロード(無料)の上ご覧ください。
印刷用画面へ印刷用画面へ
プライバシー ご利用条件・免責事項