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

Transcript

1. インターン成果報告資料 @UdonYuya
2. 自己紹介・参加動機 名前：@UdonYuya 所属：九州大学大学院システム情報科学府 研究：セキュリティ、脅威トレース 低レイヤが好きで、クラウドの基盤開発をやりたいと思っていた。
3. 取り組んだこと ContrailのvRouterが同時に処理できる最大フロー数に関する調査・改善 JP7のvRouterの最大フロー数の2.5倍のフローが扱えるように！
4. vRouter ・1台のハイパーバイザに対して、 vRouterが1台存 在する。 ・パケットのフォワーディングを行っている。 ・vRouter Agentは経路などの制御情報やフローの エントリなどをvRouterに格納する。 ・フロー：５つの要素からなる通信を識別するための 単位。
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. 感想 ・本当に本当に勉強になりました。 - もっと勉強します。。。 ・想像してたより、すごいサービスだと思った。（小学生並みの（以下略）） - 同時に改善できる点も多くあり、自分の手でより良くしたいと感じた。