Home メインフレーム 知らなきゃ損するz機能~こんなに速い 最新のShared Memory通信|メインフレーム技術解説

知らなきゃ損するz機能~こんなに速い 最新のShared Memory通信|メインフレーム技術解説

by iida

 z/OS Communications Serverで提供されるTCP/IPスタックは、外部ノードとのIP通信だけではなく、z/OS間の大容量データ伝送にも利用され、z Systemsの重要コンポーネントとなっている。TCP/IPスタックがサポートするネットワーク・デバイスは「OSA-Express」(以下、OSA)と「HiperSockets」が主流で、これまでもCPUコスト削減やパフォーマンス向上のための機能拡張が実施されてきた。

 本稿では、z/OS間TCP/IP通信のさらなる低CPUコスト、低遅延、高スループットを実現した、「RoCE」(RDMA over Converged Ethernet)と「vISM」(Virtual Internal Shared Memory)を用いるShared Memory通信(Shared Memory Communication。以下、SMC)について解説する。

OSA-ExpressとHiperSocketsによる
z/OS間データ通信フロー

 図表1は、OSAを介したz/OS間のTCPソケット・アプリケーションによる通信フローの概要である。3ウェイ・ハンドシェークによるTCPコネクションが確立(破線矢印)されたあと、データ伝送(実線矢印)が行われるが、このときアプリケーション、メモリ、TCP/IP、OSA、LANと複数箇所でのデータ・コピーが発生する()。

 またLANに送出可能なセグメント・サイズは最大MTUサイズ(標準的なLANで1500バイト、ジャンボフレーム対応で8992バイト)に制限されるため、データ分割と組み立てが発生する()。

 さらにLANとのデータ授受に必要なTCPヘッダ、IPヘッダ、Ethernetヘッダの付与や除去といった処理も発生する()。これらの処理が伝送遅延やCPU負荷、スループット抑制の要因となっている。

 

 これらの処理を効率化する目的で、これまでQDIO (Queued Direct I/O) やDMA (Direct Memory Access)、OSAセグメンテーション・オフロードといった技術が実装されてきた。

 HiperSocketsは、OSA QDIOのDMA技術をz Systems筐体内の通信に適用したものである。最大MTUサイズが56KBにまで拡張され、z/OSのDMA処理をファームウェアが実行することで、高速IP通信を実現している。ただし、TCPソケット・アプリケーションの通信フローはOSAと同様であり、HiperSocketsにも伝送遅延やCPU負荷の要因となる処理は存在する。こうした伝送遅延やCPU負荷のさらなる改善、スループット向上を目指して実装されたのがRoCEとvISMである。

新たなネットワーク・デバイス
RoCEとvISM

◆ SMC-R/RoCE

 IBMはz SystemsでRoCEを実装する際に、TCPソケット・アプリケーションから透過的に利用できるよう、SMC-R(Shared Memory Communication-RDMA)というハイブリッド・ソリューションを開発した(*1)。SMC-Rは、RoCE-Expressネットワーク・デバイスを前提とした通信プロトコル(RFC7609)である。

 SMC-Rハイブリッド・ソリューションでは、OSA経由で3ウェイ・ハンドシェークとRoCE通信の前提となるCLC(Connection Layer Control)メッセージ交換(ランデブー処理)を行ったあと、通信パスをRoCEへスイッチし、LLC(Link Layer Control)メッセージ交換を経てデータ伝送となる(図表2)。

 図表2のOSAを介したネゴシエーション処理からRoCEへの通信パスのスイッチというロジックによって、TCPソケット・アプリケーションが直接RoCEを制御することなく、RoCE経由のデータ伝送を可能にした。

 SMC-Rソリューションでは、図表1で複数箇所に存在したデータ・コピー()がリモート・ホストへのメモリ・アクセスのみ(’)となっており、伝送遅延やCPU負荷の低減効果が得られている。の処理は、OSAからよりローレベルな処理を実行するRoCEへ場所を変えることで高速化が図られているが、処理そのものは残存する。

◆ SMC-D/vISM

 図表3に、SMC-D/vISMによる通信フローの概要を示す。

 SMC-D(Shared Memory Communi cation-DMA)が通信プロトコルを、vISMがネットワーク・デバイスを意味する。SMC-R/RoCEのデータパスが、仮想内部共有メモリ技術であるvISMに置き換わっている。SMC-Rと比較してLLCメッセージ交換が省略されているが、3ウェイ・ハンドシェークからCLCメッセージ交換のネゴシエーション処理とデータ伝送までのフローは同じである。

 SMC-R/RoCEとの最も大きな相違点は、Socket APIと筐体内メモリとの密結合により、TCP/IPのオーバーヘッドを排除したことである。VMAC、MTU、IPやフレームサイズといったネットワーク通信に用いられる情報がすべて不要となり、分割・組み立て()、ヘッダ処理()までもが排除された。

 たとえば180KBのデータ転送では、180KBのデータがそのままリモート・メモリへ、ゼロ・コピーでダイレクトに書き込まれると考えれば理解しやすい。

SMC-RとSMC-Dの
適用効果

 ゼロ・コピーや分割・組み立て処理、ヘッダ処理の除去によるパフォーマンス効果を判断するために、開発元が公開しているSMC-R/RoCEとSMC-D/vISMのパフォーマンス・データを図表4にまとめた。

 スループット向上、CPUコスト削減、ネットワーク伝送遅延削減とすべてにおいて改善効果が見られるが、これはテスト・ツールを使用してコントロールされた環境下でのデータであり、最良の数値が出ている点に注意したい。

 例を挙げると、SMC-R/RoCEのオンライン・トランザクション系のCPUコストが56%削減という効果は、データ・サイズが大きい場合の最大値であり、データ・サイズが小さい場合には逆に15%増加するという結果が出ている。

 比較のために開発元とは異なる環境下で実施した検証データを解析したところ、以下の条件であればスループット向上およびCPUコスト削減の効果があることは確認できた。

◇ スループット向上

データ・サイズ2KB以上
接続・切断の頻度が少ない

◇ 総CPUコスト削減

データ・サイズ:32KB
バッファ・サイズ:64KB
MTUサイズ:1500

 またトラフィック特性ごとのデータでは開発元データと類似の傾向が認められたが、実測値ベースでは乖離も見られた。このことから、アプリケーションのデータ通信特性やネットワーク環境が適用効果に影響を及ぼすことがわかる。

SMC-R/RoCE
ネットワーク要件

 SMC-D/vISMは筐体内部通信であるため、前提条件が整えば、追加投資なく機能の実装が可能である。一方、SMC-R/RoCEはLAN経由の通信となるので、RoCE通信に必要なネットワーク要件を満たす必要がある。

 z SystemsのRoCE(10GbE RoCE-Express)は、RDMA(Remote Direct Memory Access)トラフィックのみに特化した実装のため、一般的なRoCE実装に求められるネットワーク・スイッチのIEEE CEE(Converged Enhanced Ethernet)機能要件を必要としない。

 これは一般的な10GbEスイッチが利用可能であることを意味する。z SystemsのSMC-R/RoCEネットワーク要件と制約事項を以下に挙げる。

・ L2ネットワークへのOSAおよびRoCEのダイレクト接続(ただしVIPAは利用可能)
・ IPルータ/Firewall経由のルーティングには非対応
・ PNetID(RoCEカード)ごとの同一サブネットおよびVLAN(オプション)へのダイレクト接続
・ OSAをVLANタグ設定で使用する場合、同一VLANへの接続が必要(RoCE通信にVLANタグ情報が無条件に引き継がれるため)

Shared Memory通信の
適用を考える

 最後にSMCに適した「アプリケーションの選択」、およびSMC-R/RoCEとSMC- D/vISMのいずれを選択するかという「ネットワーク・デバイスの選択」の観点に分けて、SMCの適用について検討する。

◆アプリケーションの選択

 前述したとおり、SMCではアプリケーションの送信データ・サイズが比較的大きい場合にパフォーマンス向上とCPUコスト削減の効果が期待できる。その一方、データ・サイズが小さい場合や、接続・切断を繰り返すアプリケーションでは処理オーバーヘッドが増えるために効果が薄くなる。

 このことから、Telnetやrexec/rshなどショートパケットをやり取りするものや、接続・切断を頻繁に行うようなアプリケーションよりも、FTPに代表されるファイル転送、データ・レプリケーション、DRDA接続で大量データをQUERYするデータベース・アクセス通信などで効果が高いと考えられる。

 ただしアプリケーションACKやデータベース処理を伴うものは、処理遅延となって効果が抑えられる可能性があるので、考慮が必要である。

 またSMC設定で、Liste ningポート単位にSMC対象外となるよう設定可能なため、アプリケーション混在環境への適用を検討しやすい。図表5-④は、PORTRangeステートメントを利用してFTPのデータ・コネクションと制御コネクションをSMC対象外とする例である。

◆ネットワーク・デバイスの選択

 z/OS間TCP/IPデータ通信は、以下の3つの利用シーンが想定される。

(a)複数z Systems間のOSA通信
(b)同一z Systems内のOSA通信
(c)同一z Systems内のHiperSockets通信

 既存環境へのSMCソリューションの適用を検討する場合、(a)ではSMC-R/RoCE以外の選択肢はない。(b)ではまずHiperSocketsへの移行を検討し、移行可能と判断できる場合は、さらにSMC-D/vISMの利用を検討する。現状が(c)であれば、図表6のようにHiperSocketsをネゴシエーション処理に流用し、データ伝送をvISM経由へ切り替える構成への移行が可能である。

 SMC-RはRoCEデバイスや10GbE L2ネットワークが必要なために実装のハードルが高くなるが、vISMはファームウェアで提供される機能なので、TCPIP.PROFILE設定を一部追加変更するだけで容易に移行できる(図表5)。z Systemsとz/OSバージョンの前提を満たす環境ではぜひ、実装を検討してほしい。

 以上本稿では、SMCの機能実装、適用効果と適用方法について例を用いて解説した。ハードウェアおよびソフトウェアの前提条件やアプリケーション適性があるため、すべてのユーザーで適用できるとは限らないが、今後、z/OS間TCPソケット・アプリケーション通信に着目してCPUコスト削減やスループット向上、ネットワーク伝送遅延削減を検討する際に、一助となれば幸いである。

著者|宮本 幸彦

日本アイ・ビー・エム システムズ・エンジニアリング株式会社
テクニカル・コンピテンシー
ネットワーク
シニアITスペシャリスト


著者プロフィール
1996年に日本IBM入社。同年、日本IBMシステムズ・エンジニアリングへ出向。1999年からの金融系大規模アウトソーシングプロジェクトでのネットワークの提案から設計・構築、保守運用までの経験を経て、2005年よりメインフレーム系ネットワークを中心とした技術支援に従事。現在はネットワーク部門のマネージャーを務めるかたわら、金融系ユーザーのプロジェクトでの技術支援活動を継続。

 

[IS magazine No.16(2017年7月)掲載]

related posts