Upgrade to Pro — share decks privately, control downloads, hide ads and more …

NTTコミュニケーションズ インターンシップレポート

NTTコミュニケーションズ インターンシップレポート

3dfba21f12b674371e38d9535e0ea6df?s=128

udon-yuya

March 02, 2021
Tweet

Transcript

  1. インターン成果報告資料 @UdonYuya

  2. 自己紹介・参加動機 名前:@UdonYuya 所属:九州大学大学院システム情報科学府 研究:セキュリティ、脅威トレース 低レイヤが好きで、クラウドの基盤開発をやりたいと思っていた。

  3. 取り組んだこと ContrailのvRouterが同時に処理できる最大フロー数に関する調査・改善 JP7のvRouterの最大フロー数の2.5倍のフローが扱えるように!

  4. vRouter ・1台のハイパーバイザに対して、 vRouterが1台存 在する。 ・パケットのフォワーディングを行っている。 ・vRouter Agentは経路などの制御情報やフローの エントリなどをvRouterに格納する。 ・フロー:5つの要素からなる通信を識別するための 単位。

  5. 背景 ・商用で使われているvRouter1台が一度に扱える最大フロー数は2Mフロー。 ・VM1台あたりのフロー数は0.9M(45%)。 ・JP7では次世代基盤に移行され、収容できるVMの数が2倍になるため、4Mフローまで 扱えるしようとしている。 ・しかし新基盤でもVM1台あたりのフロー数は0.9Mのままでお客様的には大してメリット がない。

  6. 動機 ・vRouterの最大フロー数を増やしたい。 ・そもそもわからないことがたくさんある。 - 現状どこまで増やせるのか。 - 増やすと性能にどう影響が出るのか。 これらを明らかにしたい。

  7. バグとの出会い ・最大フローを7Mにしたときに、メモリアロケーションエラーが発生した。 Error mapping KSync memory. Device: /dev/flow; /dev/flow: Cannot

    allocate memory contrail-vrouter-agent: controller/src/vnsw/agent/vrouter/ksync/ksync_memory.cc:116: void KSyncMemory::Mmap(bool, void*, bool): Assertion `0' failed.
  8. バグとの出会い ・最大フロー7M時、フローテーブルのサイズは { 7M + 1,468,456(overflow table) } * 256

    = 2,254,962,688 bytes ・これはintの最大値 2,147,483,647 より大きい。 ・オーバフローによって正常に処理が行われていない可能性がある。
  9. 実際に ・vRouterカーネルモジュールがメモリをアロケートするときは、size_t宣言。 ・vRouter Agentが保持するフローテーブルのサイズはint宣言。 const char * vr_table_map(int major, unsigned

    int table, const char *table_path, size_t size, void **mem) { … *mem = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0); … } https://github.com/tungstenfabric/tf-vrouter/blob/R2011/utils/unix_util.c class KSyncMemory { … // Size of flow table memory int table_size_; … }; https://github.com/tungstenfabric/tf-con troller/blob/R2011/src/vnsw/agent/vrout er/ksync/ksync_memory.h
  10. つまり、 1. vRouter Agentがフローテーブルのサイズを計算し、オーバーフローが発生する。 2. オーバーフローした値がsize_tにキャストされ、非常に大きな値になる。 3. メモリアロケーションエラーが起きる。 参考:https://cplayground.com/

  11. 変更点 ・vRouter Agent内のフローテーブルサイズをsize_tで扱うように変えた。 ・vRouter カーネルモジュール内のSandeshというプロトコル周りの部分はu32(符号なし 32bit整数)で扱われていたため、u64で扱うように変更。 ・(余談)この辺で、もしかしてContrailは32bitで扱える範囲しかサポートしないつもりな のでは?という疑念がわきました。 変更によって7Mのフローを扱えるようになった!

  12. 性能測定 ・TRexというトラフィックジェネレータを用いて1台のVMに対し、高トラフィックを印加。 ・VM1台のフロー数の上限はvRouterの最大フロー数の80%に設定。 ・最大フロー数に達するまでのSetup Rateを最大フロー数ごとに比較。 ・最大フローに達した時の、他のVMに対する通信の遅延をqperfで測定。

  13. 4Mフロー フロー数 (左軸) Setup Rate (右軸)

  14. 5Mフロー

  15. 7Mフロー

  16. 10Mフロー

  17. qperf 4Mフロー ubuntu@ubuntu:~$ qperf -vvs -t 30 192.168.56.6 tcp_lat tcp_lat:

    latency = 51.1 us msg_rate = 19.6 K/sec loc_send_bytes = 293 KB loc_recv_bytes = 293 KB loc_send_msgs = 293,312 loc_recv_msgs = 293,311 rem_send_bytes = 293 KB rem_recv_bytes = 293 KB rem_send_msgs = 293,311 rem_recv_msgs = 293,311
  18. qperf 5Mフロー ubuntu@ubuntu:~$ qperf -vvs -t 30 192.168.56.9 tcp_lat tcp_lat:

    latency = 48.7 us msg_rate = 20.5 K/sec loc_send_bytes = 308 KB loc_recv_bytes = 308 KB loc_send_msgs = 307,696 loc_recv_msgs = 307,695 rem_send_bytes = 308 KB rem_recv_bytes = 308 KB rem_send_msgs = 307,695 rem_recv_msgs = 307,695
  19. qperf 7Mフロー ubuntu@ubuntu:~$ qperf -vvs -t 30 192.168.56.9 tcp_lat tcp_lat:

    latency = 45.5 us msg_rate = 22 K/sec loc_send_bytes = 329 KB loc_recv_bytes = 329 KB loc_send_msgs = 329,442 loc_recv_msgs = 329,441 rem_send_bytes = 329 KB rem_recv_bytes = 329 KB rem_send_msgs = 329,441 rem_recv_msgs = 329,441
  20. qperf 10Mフロー ubuntu@ubuntu:~$ qperf -vvs -t 30 192.168.56.9 tcp_lat tcp_lat:

    latency = 44.8 us msg_rate = 22.3 K/sec loc_send_bytes = 335 KB loc_recv_bytes = 335 KB loc_send_msgs = 335,191 loc_recv_msgs = 335,190 rem_send_bytes = 335 KB rem_recv_bytes = 335 KB rem_send_msgs = 335,190 rem_recv_msgs = 335,190
  21. 考察 ・最大フロー数を10Mまで増加させても、Setup Rateや他VMの通信の遅延には変化が 見られなかった。 ・フローテーブルはハッシュテーブルとして管理されており、処理は定数時間で完了す る。(要調査)

  22. まとめ ・vRouterのフローテーブルのサイズを現在の最大の4Mから10Mまで増やして実験を行 い、また大きく性能に影響を与えることがないことを確認した。 ・vRouter内のバグを発見し、修正を行った。

  23. 感想 ・本当に本当に勉強になりました。 - もっと勉強します。。。 ・想像してたより、すごいサービスだと思った。(小学生並みの(以下略)) - 同時に改善できる点も多くあり、自分の手でより良くしたいと感じた。