GPUDirect RDMAを用いた リモートホストの異常検知手法

Presentation on theme: "GPUDirect RDMAを用いた リモートホストの異常検知手法"— Presentation transcript:

1 GPUDirect RDMAを用いた リモートホストの異常検知手法
九州工業大学 金本　颯将　　光来　健一

2 システムの異常検知 システムの複雑化にともない，様々な異常が引き起こ されている システムの異常はできるだけ早く検知する必要
システムの複雑化にともない，様々な異常が引き起こ されている システム障害，性能低下，攻撃 システムの異常はできるだけ早く検知する必要 障害検知：早期に障害から復旧 性能監視：システム性能を維持 侵入検知：攻撃の被害を最小化 近年、システムの複雑化に伴い、様々な異常が引き起こされるようになってきています。 例えば、(*)OS等に障害が発生したり、システム全体の性能が低下したりします。 また、(*)外部からの攻撃によってもシステムに異常が引き起こされることがあります。 これらシステムの異常を出来るだけ早く検知することは重要です。そのために、早期に障害から復旧するための障害検知やシステム性能を維持するための性能監視、また、攻撃の被害を最小化するための侵入検知などが実際に行われています。 種類　　具体例　　障害 ハードウェア 機器の故障，停電や過電流による機能停止 ソフトウェア データ欠損，仕様外の動作 ヒューマンエラー 思い込みや勘違い，過失による誤操作 性能低下 CPU の性能低下，通信の遅延 攻撃 セキュリティ上の脆弱性をついた攻撃 障害 ホスト 攻撃 OS メインメモリ CPU

3 ソフトウェアを用いた異常検知 OS上やOS内部の検知システムを用いて異常を検知 OS内部の異常により検知システムが機能を停止 OS
アンチウィルスによってウィルスへの感染を検知 システムの状態を取得して障害を検知 OS内部の異常により検知システムが機能を停止 OSが異常停止すると検知システムは動作しなくなる カーネルルートキットをインストールされると攻撃を検知できな くなる 従来、ソフトウェアを用いた異常検知では、OS上やOS内部の検知システムを用いて異常を検知してきました。 例として、(*)ウィルスへの感染を検知するアンチウィルスや(*)システムの状態を取得して障害を検知する障害検知システムなどが挙げられます。 しかし、ソフトウェアを用いた異常検知手法には問題があり、OSの内部に異常が発生してしまうと検知システムが機能を停止してしまうという問題があります。 例えば、(*)OSに障害が発生し、異常停止してしまうと、検知システムは動作しなくなります。 また、(*)OSの内部にカーネルルートキットがインストールされてしまうと、(*)アンチウィルスに偽の情報が返され、外部からの攻撃を検知できなくなってしまいます。 アンチ ウィルス 偽の情報 障害検知 システム OS カーネルルートキット 障害

4 ハードウェアを用いた異常検知 専用ハードウェアを利用 汎用CPUの隔離実行のための機能を利用
PCIカード上でOSの整合性を安全に検査 [Petroni et al. ’04] 高コストであることが多い 汎用CPUの隔離実行のための機能を利用 Intel製CPUのSMMと呼ばれるモードを用いてハイパーバイザ を安全に監視 [Rutkowska et al. ’08] SMMでの実行は低速であり，性能面に課題 一方、ハードウェアを用いた異常検知では、専用ハードウェアや汎用CPUの隔離実行のための機能を利用して異常を検知してきました。 専用ハードウェア上で異常を検知する手法の例として、PCIカード上でOSの整合性を安全に検査する手法が提案されています。 この手法では、リモートホストからメモリを監視するために信頼できますが、コストが高くなりがちです。 一方、汎用CPUの隔離実行のための機能を利用する手法の例として、Intel製CPUのシステムマネジメントモード（SMM）と呼ばれるモードを用いてハイパーバイザを安全に監視する手法が提案されています。 CPUは標準的に搭載されているためにコストは低く、SMMによる実行は信頼できます。 しかし、SMMの実行は低速であるため、性能面に課題があります。 ハイパーバイザ：仮想マシンを作って動かす為のソフト PCIカード CPU 監視 監視 OS

5 GPUSentinel [尾崎ら’18] GPU上でOS監視システムを実行して異常検知 高信頼・低コスト・高性能の3つを満たす
多数の演算コアを用いて並列に検知が可能 OS監視システムはGPUを占有して自律的に動作 メインメモリ上のOSデータを解析することで異常検知 監視対象ホスト リモートホスト そこで、高信頼・低コスト・高性能の3つを満たすものとして、GPUを用いた異常検知手法も提案されています。 GPUはCPUやメインメモリから独立しており、信頼できます。 また、専用ハードウェアなどと比較すると低コストで導入でき、GPU内の多数の演算コアを用いることで並列に検知することも可能です。 このGPUを用いた異常検知手法の例として、GPUSentinelがあります。 GPUSentinelでは、GPU上でOS監視システムを実行して異常を検知します。 OS監視システムはGPUを占有して自律的に動作し、(*)メインメモリ上のOSデータを解析することによって異常を検知します。 GPU OS リモート監視 システム OS監視 システム 監視 CPU メインメモリ

6 検知結果の通知 OSの通信機能を利用して検知結果を通知する必要 GPUは能動的にネットワーク通信を行えないため
監視対象ホスト リモートホスト GPU上のOS監視システムでは、リモートホストに対して検知結果を通知する際に、OSの通信機能を利用する必要があります。 OSの通信機能を利用するのは、GPUが能動的にネットワーク通信を行えないためであり、(*)GPUSentinelでは、OS上のプロセスを介してリモートホストに検知結果を通知しています。 そのため、ソフトウェアを用いた異常検知手法と同様に、OSの異常停止や攻撃による通信の阻害が発生してしまうと、リモートホストに検知結果を通知することができなくなる可能性があります。 検知結果 GPU OS リモート監視 システム OS監視 システム 監視 CPU メインメモリ

7 提案：GRASS 監視対象ホストのOSを介さずにGPUと直接ネットワー ク通信を行い，検知結果を取得
GPUDirect RDMAと呼ばれる機能を利用して実現 GPU上のOS監視システムが検知結果をGPUメモリに格納 リモートホストはGPUメモリから直接，検知結果を取得 監視対象ホスト リモートホスト GPU そこで本発表では、監視対象ホストのOS等を介さずにGPUと直接ネットワーク通信を行い、検知結果を取得するシステムであるGRASSを提案します。 GRASSはGPUDirect RDMAと呼ばれるハードウェア機構を利用しており、リモートホストと監視対象ホスト内GPUとの間で直接通信します。 GRASSでは、リモートホストはRDMA Write機能を用いて要求を書き込みます。 OS監視システムは要求内容に基づいた検知結果を格納し、リモートホストはRDMA Read機能を用いて、GPUメモリから直接、検知結果を取得します。 OS監視 システム リモート監視 システム GPUDirect RDMA OS CPU メインメモリ GPUメモリ メインメモリ NIC NIC

8 GPUDirect RDMA CPUを介さずにリモートホスト上のGPUメモリに直接ア クセスするためのハードウェア機構
NICからのアクセスを可能にする マッピングしたGPUメモリにネットワーク経由でアクセス NICのRDMA Read/Write機能を用いてデータの読み書きを行う 監視対象ホスト リモートホスト GPUDirect RDMAは、CPUを介さずにリモートホスト上のGPUメモリに直接アクセスするためのハードウェア機構です。 まず、GPUDirectによって、GPUメモリを物理メモリアドレス空間にマッピングします。(*) このマッピングを行うことで、NICからのアクセスが可能になります。 次に、マッピングしたGPUメモリに対してネットワーク経由でアクセスを行います。 この際、(*)NICのRDMA Read機能を用いることでデータの読み込みを行い、RDMA Write機能を用いることでデータの書き込みを行います。 GPU メインメモリ GPUメモリ メインメモリ マッピング RDMA Read/Write NIC NIC

9 検知結果の要求・取得 RDMA WriteによりGPUメモリに要求を書き込む ポーリングによりGPUメモリに検知結果が格納される のを待つ
OS監視システムがGPUメモリに検知結果を格納 ポーリングによりGPUメモリに検知結果が格納される のを待つ RDMA ReadによりGPUメモリから検知結果を取得 GPU リモートホスト 検知結果の要求を行う際には、リモートホストは(*)RDMA Writeを用いて、GPUメモリに対して(*)要求を書き込みます。 このとき、GPUはポーリングによってGPUメモリへの要求の書き込みを待機しており、要求が書き込まれると(*)ポーリングを終了し、(*)要求を取得します。 OS監視システムは、要求内容に基づいて処理を行い、GPUメモリに検知結果を格納します。(*) このとき、リモートホストはポーリングによってGPUメモリに検知結果が格納されるのを待機しています。 検知結果が格納されると(*)ポーリングを終了し、(*)RDMA Readを用いてGPUメモリから(*)検知結果を取得します。 RDMA Write ポーリング ポーリング 要求 OS監視 システム 要求 検知結果 RDMA Read 検知結果

10 他の検知手法での利用（1/2） 必要に応じてGPUにOSデータを要求し，取得したデー タを用いて異常を検知
例：RemoteTrans によるリモートホストでの既存IDSの実行 [Kourai et al.'16] GPU リモートホスト また、GPU上でOS監視システムを用いて異常検知を行わず、必要に応じてGPUにOSデータを要求し、取得したデータを用いてリモートホストにおいて異常を検知する手法も実現可能です。 リモートホストは(*)RDMA Writeを用いて(*)OSデータを要求します。 データ取得システムは(*)要求を受け取ると、(*)OSデータを格納し、リモートホストは(*)RDMA Readを用いて(*)OSデータを取得します。 このとき、リモートホストではOS監視システムを動作させており、(*)OS監視システムは取得したOSデータを用いて異常を検知します。 この手法では、GPU上で実行するよりも高度なOS監視システムを利用することができます。 この手法を用いることで、RemoteTransによるリモートホストでの既存IDSの実行で提案されているような手法が実現可能です。 RDMA Write 要求 OS監視 システム データ 取得 システム 要求 OSデータ RDMA Read OSデータ 異常検知

11 他の検知手法での利用（2/2） 定期的にメインメモリ上のデータを一括取得して異常 を検知 リモートホスト上のOS監視システムがデータを解析
定期的にメインメモリ上のデータを一括取得して異常 を検知 リモートホスト上のOS監視システムがデータを解析 例：Copilot [Petroni et al.‘04]，HyperCheck [Wang et al.'10] 大量のデータをRDMA転送するので転送効率がよい GPU リモートホスト また、OSデータの代わりに定期的にメインメモリのデータを一括取得して異常を検知することも可能です。 リモートホストは(*)RDMA Writeを用いて(*)メインメモリのデータを要求します。 データ取得システムは(*)要求を受け取ると、(*)メインメモリを格納し、リモートホストは(*)RDMA Readを用いて、複数回に分けてメインメモリのデータを取得します。 メインメモリのデータを取得したのち、(*)OS監視システムは取得したメインメモリのデータを用いて異常を検知します。 この手法では、リモートホスト上のOS監視システムがメインメモリのデータを解析し、異常を検知します。 この手法を用いることで、CopilotやHypercheckで提案されている異常検知手法が実現可能です。 具体的には、Copilotに関してはPCIカードを、Hypercheckに関してはCPUをGPUに置き換えることで実現することができます。 Copilot：PCIカード→GPU Hypercheck：CPU→GPU、SMM中にデータを取得し送信 RDMA Write 要求 OS監視 システム データ 取得 システム 要求 メインメモリ RDMA Read メインメモリ 異常検知

12 ハートビートでの利用 定期的に小さなデータを送り合うことでOS監視システ ムの異常を検知 検知できる異常 GPU
リモートホスト GRASSでは、OS監視システムの死活監視を行うためにハートビートを利用することができます。 ハートビートでは、(*)(*)(*)(*)定期的に小さなデータを送り合うことでOS監視システムの異常を検知します。 ハートビートを用いることで、障害の発生によるOS監視システムの停止や侵入者によるOS監視システムの停止を検知することができます。 RDMA Write ポーリング ポーリング OS監視 システム データ データ RDMA Read

13 実装 GRASSをLinux上に実装 CUDA 8.0，Verbs API，RDMA CMを用いて通信の準備
nvidia-peer-memory 1.0.7を用いてGPUDirect RDMAを利用 GPUSentinel向けに修正したLinux ，NVIDIAドライバ を利用 監視対象ホスト GPU リモートホスト OS監視 システム リモート監視システム Linux OFED ndivia-peer-memory CUDA Verbs RDMA CM メモリ管理 通信機構 NVIDIA ドライバ 実際にGRASSを図で示すように実装しました。 なお、GPUSentinelで実装した要素は、オレンジで示す、OS監視システム、メモリ管理機構およびNVIDIAドライバであり、GRASSで新規実装した要素は、黄色で示す、リモート監視システムおよび通信機構となります。 CUDA 8.0、Verbs APIおよびRDMA Communication Managerを用いて通信機構を実装し、監視対象ホストにおいてnvidia-peer-memoryを用いることでGPUDirect RDMAを利用可能にしました。 また、監視対象ホストでは、GPUSentinel向けに修正したLinux およびNVIDIAドライバ375.66を利用しています。 InfiniBand Verbs API RDMA Communication Manager(CM) RDMA CM は User Verbs のうちコミュニケーション確立に関する部分をラップしたライブラリである。 InfiniBand 以外の RDMA over Converged Ethernet(RoCE) や iWARP のメディアでも利用可能であり、共通の API を提供する。 RDMA CM は rdma_ のプレフィックスがついた関数として定義されている。 RDMA CM のコミュニケーション確立は IP ネットワーク層を使って必要なデータを交換する。 そのため InfiniBand をメディアを用いる場合、IPoIB を必要とする。 RDMA CM API はある程度 Socket API に似せて作られており、コミュニケーション確立までは Socket と同様のフローになる。 OpenFabrics Enterprise Distribution ：ソフトウェアパッケージ

14 GPUDirect RDMAの準備 監視対象ホストからリモートホストに対してRDMA接続 を確立 GPUメモリ上に通信用バッファを確保
通常のRDMA通信と同様にQueue Pairを作成 GPUメモリ上に通信用バッファを確保 そのアドレスをRDMA Sendを用いてリモートホストに送信 NVIDIAドライバが物理アドレスに変換 GRASSでの異常検知を行う前に、GPUDirect RDMAの準備を行う必要があります。 まず、監視対象ホストからリモートホストに対してRDMA接続を確立しました。 RDMA接続の確立を行う際には、通常のRDMA通信と同様にQueue Pairを作成しました。 RDMA接続の確立後、図に示すように、GPUメモリ上に通信用バッファを確保します。 GRASSでは、RDMA Write用の受信バッファおよび書き込みフラグ、RDMA Read用の送信バッファおよび読み込みフラグを確保しています。 これらバッファのアドレスをRDMA Sendを用いてリモートホストに送信することで、リモートホストからのアクセスを可能にします。 なお、この際、NVIDIAドライバがバッファのアドレスを物理アドレスに変換します。 それぞれのホストでRDMA接続前に以下を準備 Protection Domain：RDMA通信の保護領域 　　　　　　　　　　　　　RDMA通信のアクセス範囲 Queue Pair：RDMA通信の起点 Completion Queue：送受信の完了を通知 2つのホスト間でRDMA接続を確立した後，以下を実行 GPUメモリにGPUDirect RDMAに使用するバッファを確保 RDMA通信に必要な情報をリモートホストに送信 GPUメモリ上バッファのアドレス Host Channel Adapterによって生成されるリモートキー： 32 ビット値を生成する。 RDMA READ や RDMA WRITE はこの R_Key を Send WR の中に含めて通信を行い、値が一致しない場合はリモート側(受信側)でエラーとして検知することができる。 Reliable connectionタイプ　理論上の最大サイズ2^31 GPU RDMA受信バッファ 0/1 RDMA送信バッファ 読み込みフラグ 書き込みフラグ

15 検知結果の要求における同期 リモートホストは要求をGPUメモリに書き込む GPUはポーリングにより書き込みフラグのセットを待つ
書き込みフラグがセットされたら要求を取得 書き込みフラグをクリア 検知結果の要求を行う際には、まず、リモートホストは(*)(*)(*)RDMA Writeを用いて要求をGPUメモリに書き込みます。 要求の書き込み後、(*)(*)(*)再度RDMA Writeを用いて書き込みフラグをセットします。 このとき、GPUはポーリングによって書き込みフラグのセットを待機しています。 これは、GPUに書き込みを通知するハードウェア機構がないためであり、(*)(*)(*)書き込みフラグがセットされるとポーリングを終了し、 (*)(*)(*)要求を取得します。 OS監視システムは要求を取得すると、(*)(*)(*)書き込みフラグをクリアします。 フラグを用いて完了を通知する目的 　書き込みを通知するハードウェア機構がないため 　書き込み途中のデータの読み込みを防ぐため GPU リモートホスト 書き込み フラグ ポーリング RDMAWrite OS監視 システム 書き込み 読み込み 要求 要求 1 1 要求 1

16 検知結果の取得における同期 GPUは検知結果をGPUメモリに書き込む リモートホストはポーリングにより読み込みフラグの セットを待つ
完了したら，読み込みフラグをセット リモートホストはポーリングにより読み込みフラグの セットを待つ 読み込みフラグがセットされたら検知結果を取得 読み込みフラグをクリア OS監視システムは、要求内容に基づいて処理を行った後、(*)(*)(*)検知結果をGPUメモリに書き込みます。 検知結果の書き込み後、(*)(*)(*)読み込みフラグをセットします。 このとき、リモートホストはRDMA Readを用いたポーリングによって、読み込みフラグのセットを待機しています。 (*)(*)(*)読み込みフラグがセットされるとポーリングを終了し、 (*)(*)(*)再度RDMA Readを用いて検知結果を取得します。 リモートホストは検知結果を取得すると、(*)(*)(*)RDMA Writeを用いて読み込みフラグをクリアします。 GPU リモートホスト 読み込み フラグ ポーリング RDMAWrite RDMARead OS監視 システム 書き込み 検知結果 検知結果 1 1 検知結果 1

17 GPUからメインメモリへのアクセス CUDAのマップトメモリ機能を利用 問題 メインメモリ全体をプロセスのアドレス空間にマッピング
メインメモリ全体が使用中になり，空きメモリがなくなる CUDAの制限により，メインメモリ全体のマッピングは不可 ここからは監視対象ホストにおけるGPUからメインメモリへのアクセスに関する説明を行います。 GPUからメインメモリへアクセスする際にはCUDAのマップトメモリ機能を利用します。 まず、メインメモリ全体をプロセスのアドレス空間にマッピングします。 そのマッピングしたメモリ領域をマップトメモリ機能を用いてGPUアドレス空間にマッピングします。 しかし、マップトメモリ機能にはいくつかの問題があります。 まず、メインメモリをGPUアドレス空間にマッピングすると、メインメモリ全体が使用中になり、空きメモリがなくなってしまいます。 また、CUDAの制限によって、メインメモリ全体をマッピングすることはできません。 マップトメモリ：GPU-プロセス　透過的にDMAが可能 マップトメモリ機能を用いる際の問題 システムの空きメモリ不足 ピン留めされるとメモリは使用中となるため プロセスにマップしたメモリのピン留めを実行 メインメモリのサイズはマッピング不可 マップトメモリ機能により制限されている GPU プロセス メインメモリ

18 専用のメモリ管理機構 専用デバイスファイルを用いてメインメモリをマッピン グ [尾崎ら'18]
専用デバイスファイルを用いてメインメモリをマッピン グ [尾崎ら'18] メモリを使用中にせずにGPUアドレス空間にマッピング可能 ピン留めの際に参照カウンタを増やさない sysinfoシステムコールの偽装 [尾崎ら'18] LD_PRELOADでsysinfoシステムコールをフック メインメモリのサイズとして少し大きい値を返す CUDAによる制限を回避 そこで、専用のメモリ管理機構を用意し、マップトメモリ機能の問題を解決します。 まず、/dev/pmemという専用デバイスファイルを用いてメインメモリをマッピングします。 このデバイスファイルを用いると、ピン留めの際にページの参照カウンタを増やしません。 そのため、メインメモリを使用中にせずにGPUアドレス空間にマッピングすることができ、空きメモリを確保することができます。 また、sysinfoシステムコールの偽装も行っています。 下の図で示すように、CUDAプログラムがsysinfoシステムコールを発行すると、LD_PRELOADによってsysinfoシステムコールがフックされ、偽装したsysinfoシステムコールが発行されます。 fake_sysinfoでは、メインメモリのサイズとして少し大きい値を返すようになっています。 これによって、メインメモリ全体をマッピングすることが可能になります。 メインメモリ全体をGPUにマップ可能にする機構 /dev/pmemという特殊なデバイスファイルを用意 ピン留めの際にページの参照カウンタを増やさない NVIDIAドライバと連携して正常にピン留めを解除 ピン留めを解除する際に参照カウンタを減らさない プロセスはマップされたメインメモリにアクセス不可 LD_PRELOAD：環境変数 fake_sysinfo：memsize++ CUDAプログラム memsize + α OSカーネル sysinfoを発行 fake_sysinfo memsize

19 OS監視システムの作成 GPUアドレス空間にマッピングされたメインメモリ上の OSデータを監視
LLView [尾崎ら'18] を使用して透過的にアドレス変換 LLVMを用いてコンパイルし，生成された中間表現を変換 OSのグローバル変数を対応する仮想アドレスに変換 また、OS監視システムでは、GPUアドレス空間にマッピングされたメインメモリ上のOSデータを用いて異常検知を行います。 CUDAプログラムにおいてOSデータを用いる際には、まずOSデータの仮想アドレスを物理アドレスに変換し、それをGPUアドレスに変換する必要があります。 CUDAプログラムにおいてOSデータを使用する度にこの変換を記述するのは冗長かつ煩雑です。 そこで、LLViewを用いることで、OSデータの透過的なアドレス変換を実現します。 LLViewでは、LLVMを用いてコンパイルを行い、下の図に示すように、生成された中間表現を変換します。 左の図に記述されているOSのグローバル変数であるjiffiesは、右の図の下線で記述されている、対応する仮想アドレスに変換します。 また、g_map関数を用いることで仮想アドレスをGPUアドレスに変換しています。 ・検知プログラムはOSデータの仮想アドレスをGPUアドレスに変換する必要 OSデータの仮想アドレスの変換は冗長かつ煩雑 　仮想アドレスをGPUアドレスに変換するためには，OSのページテーブルを用いて物理アドレスに変換する作業が必要 GPUSentinelで提案されているLLViewを使用 　GPU上のプログラムをLLVMを用いてコンパイルし，生成された中間表現を変換 　　OSの大域変数は対応する仮想アドレスに変換 　　透過的なアドレス変換を実現 ・左の中間表現ではOSカーネル内の64ビットのグローバル変数 jiffies の値をローカル変数%1に読み込み，250で割って%2に格納 ・右の中間表現ではjiffiesのアドレスを8ビット整数のポインタにキャストして%1に格納し，それを引数としてg_map関数を呼び出してアドレス変換を実行する. g_map関数から返されたアドレスを元の64ビット整数のポインタにキャストし，そのアドレスにあるデータを%4にロードしている. %1 = bitcast i64* %0xffffffff to i8* %2 = call %1) %3 = bitcast i8* %2 to i64* %4 = load i64, i64* %3 %5 = udiv i64 %4, 250 %1 = load i64, i64* %jiffies %2 = udiv i64 %1, 250

20 Mellanox ConnectX-4 VPI（RoCE）
実験 GRASSの有用性を確認する実験を行った OSの異常停止時におけるGRASSの動作検証 ハートビートの性能 検知結果の取得性能 GPUメモリを用いる影響 プロセス情報の取得 監視対象ホスト リモートホスト OS Linux Linux CPU Intel Xeon E v4 Intel Xeon E v3 メモリ 8GB GPU NVIDIA Quadro M4000 NIC Mellanox ConnectX-4 VPI（RoCE） ネットワーク 100ギガビットイーサネット 実際にGRASSを実装し、有用性を確認する実験を行いました。 今回行った実験は5つあり、まず監視対象ホスト内OSの異常停止時におけるGRASSの動作検証を行いました。 次に、OS監視システムの死活監視を行うハートビートの性能、および検知結果の取得性能を計測し、RDMA通信においてGPUメモリを用いる影響についても調査しました。 また、実際に監視対象ホストのプロセス情報をリモートホストで取得できることを確認しました。 実験環境は表のようになっています。 監視対象ホストのOSには、修正したLinux4.4.64を使用しており、GPUはNVIDIA Quadro M4000を使用しています。 また、NICはRDMAに対応したものを使用しており、2つのホストを100ギガビットイーサネットで接続しています。 RoCE (RDMA over Converged Ethernet, ろっきー) というプロトコルを使っている。InfinibandはRDMAを使える別のプロトコル。

21 ハートビートの信頼性と性能 OSの異常停止時にハートビートを送信 ハートビートの応答時間を計測 監視対象ホストでカーネルパニックを発生させた
正常にGPUとの通信が行えることを確認 ハートビートの応答時間を計測 pingコマンドの応答時間と比較 GRASSでは十分に短い時間 で応答できることを確認 まず、OSの異常停止時にハートビートを送信し、正常に通信を行えることを検証しました。 実際に、監視対象ホストにおいてカーネルパニックを発生させることでOSに異常を引き起こし、OS監視システムと正常に通信できることを確認しました。 次に、ハートビートの応答時間を計測し、性能を評価しました。 実験結果は図のようになっており、pingの応答時間と比較しています。 pingでは124[μs]であったのに対して、GRASSでは17[μs]と、十分に短い時間で応答することができることを確認しました。

22 検知結果の取得性能 要求または検知結果のサイズを変化させて検知結果 の取得性能を計測 変化させないほうのサイズは1KBに固定
要求または検知結果のサイズを変化させて検知結果 の取得性能を計測 変化させないほうのサイズは1KBに固定 サイズが1MB程度でスループットがほぼ一定に 同じサイズなら検知結果を読み込む性能のほうが高い 次に、要求または検知結果のサイズを変化させて検知結果の取得性能を計測しました。 なお、片方を1[KB]から4[MB]まで変化させ、もう一方は1[KB]に固定しています。 実験結果は下の図のようになっており、サイズが1[MB]程度でスループットはほぼ一定になりました。 また、同じサイズであれば、検知結果を取得する性能の方が優れていることも分かりました。 変化させないバッファは1KBに固定 ネットワーク性能（iperf）：12.0Gb/s 要求：840[μs]、取得：773[μs] = 約800[μs] 1/0.0008= /1024=1.22[GB/s] = 9.77Gb/s

23 GPUメモリを用いる影響 メインメモリ上にバッファを確保した場合とRDMA性能 を比較 ハートビートはいずれも17μsで応答
GPUメモリを使ったほうがRDMA Readの性能がわずかに低下 また、メインメモリ上にRDMA通信に用いるバッファを確保した場合と比較を行い、GPUメモリを用いる影響についても調査しました。 まず、ハートビートの性能比較を行いましたが、いずれも17[μs]で応答し、違いは見られませんでした。 次に、RDMA Read/Writeの性能比較を行い、実験結果は図のようになりました。 実験結果から、RDMA性能に関してもほぼ同等でしたが、GPUメモリを用いた際にRDMA Readの性能がわずかに低下していることが読み取れます。

24 プロセス情報の取得 プロセス情報を取得するOS監視システムを開発 プロセス情報を取得するのにかかる時間を計測
検知結果として動作しているプロセス名の一覧を返す プロセス名が正しく取得できていることを確認 プロセス情報を取得するのにかかる時間を計測 OS監視システムはプロセス情報を56μsで取得 最後に、実際に監視対象ホストで動作しているプロセス情報をリモートホストで取得できることを確認するための実験を行いました。 OS監視システムでは検知結果として動作しているプロセス名の一覧を格納しています。 実験結果は左下の図のようになっており、リモートホストにおいて、プロセス情報の取得を確認することができました。 また、プロセス情報を取得するのにかかる時間も計測しており、その結果が右下の図になります。 実験結果から、OS監視システムはプロセス情報を56[μs]で取得し、通信用バッファに格納していることが分かりました。 なお、この実験において、監視対象ホストで動作しているプロセス数は179個であり、1[μs]あたり約3.2個の処理を行っていることになります。 プロセス数：179 1μsあたり約3.2個 ネットワーク性能（iperf）：12.0Gb/s 要求：840[μs]、取得：773[μs] = 約800[μs] 1/0.0008= /1024=1.22[GB/s] = 9.77Gb/s

25 関連研究 GPUnet [Kim et al. ’14] Intel AMT HyperSentry [Azab et al.'10]
GPUプログラムにソケットAPIを提供 GPUDirect RDMAを用いてGPUにデータを送信 GPUからのデータ送信はOS経由 Intel AMT 通常のNICを用いて監視対象ホストの情報を取得 ハードウェア情報とソフトウェアによって登録された情報のみ HyperSentry [Azab et al.'10] IPMIで管理対象ホストと通信し，SMMを用いて安全に監視 SMMは低速であり，監視中はシステム全体が停止 関連研究です。 GPUnetでは、GPUプログラムにソケットAPIを提供しており、GPUDirect RDMAを用いてGPUにデータを送信しています。 しかし、GPUからのデータ送信はOS経由であるため、GPUSentinelと同様に、OSに異常が発生してしまうと外部にデータを送信することができなくなります。 Intel AMTでは、通常のNICを用いて監視対象ホストの情報を取得することができます。 しかし、取得できる情報はハードウェア情報とソフトウェアによって登録された情報のみと、限られています。 HyperSentryでは、IPMIで管理対象ホストと通信を行い、SMMを用いることで安全に監視することができます。 しかし、SMMは低速であり、監視中はシステム全体が停止してしまうなど、性能面に課題があります。 IPMI (Intelligent Platform Management Interface) SNMPやDMIなどのサーバ管理ソフトウェアが特定の何かに依存することなくサーバハードウェアをモニタ可能にするための標準インタフェース仕様

26 まとめ 監視対象ホストのGPUと直接ネットワーク通信を行い， 検知結果を取得するシステムGRASSを提案 今後の課題
GPUDirect RDMAとポーリングを利用して実現 OSが異常停止しても正常に通信できることを確認 プロセス情報を取得できることを確認 今後の課題 GPUでの実際の異常検知の結果を取得して有効性を確認 様々なシステム異常の発生時における通信の確認 OSデータを取得してリモートホストでの異常検知を実現 バックアップなど異常検知以外の用途での利用 まとめです。 本発表では、監視対象ホストのGPUと直接ネットワーク通信を行い、検知結果を取得するシステムであるGRASSを提案しました。 GRASSはGPUDirect RDMAおよびポーリングを用いて実現しており、実験結果から、OSが異常停止しても正常に通信できることを確認しました。 また、実際に、リモートホストにおいて監視対象ホストで動作しているプロセスの情報を取得できることも確認しました。 今後の課題については、まず、今回はプロセス情報の取得を行いましたが、今後、GPUでの実際の異常検知結果を取得して、改めて有効性を確認する必要があると考えています。 また、カーネルパニック以外の様々なシステム異常の発生時における通信の確認も行う必要があります。 次に、GRASSではGPU上でOS監視システムを動作させることによって異常検知を行なっていますが、今後、OSデータを取得してリモートホストでの異常検知も実現していこうと考えています。 また、バックアップなど異常検知以外の用途への利用も検討しています。