DPDK利活用:良質ソフトウェアルータを効率的に作るために我々がやるべきこと

Transcript

1. Copyright © NTT Communications Corporation. All rights reserved. DPDK利活用 良質ソフトウェアルータを 効率的に作るために我々がやるべきこと (15min version) Internet Week 2018/11/28 NTT Communications Technology Development Division Hiroki Shirokura <slankdev@nttv6.jp>
2. Copyright © NTT Communications Corporation. All rights reserved. 発表に関して • 背景: ◦ 我々はDPDKルータを開発している ◦ 良い設計を考え続けていている ◦ 良質なソフトウェアルータを開発する方法が知りたい • 内容: ◦ 良質なソフトウェアルータの定義 ◦ ソフトウェアルータ関連の設計例, 関連OSSの紹介 ◦ ソフトウェアルータ設計論の再考
3. Copyright © NTT Communications Corporation. All rights reserved. 良質の定義: ソフトウェアルータの三高 • 高性能 ◦ 汎用計算機のみを用いて限界性能を出す ◦ コア数でスケール • 高機能 ◦ モダンなプロトコル ◦ 十分に発達した既存のインターネット技術を活用可能なこと. ◦ i.e. FRR/OpenDaylight/Nginx等 • 堅牢 ◦ 24/365運用の準備 ◦ 全体のシステムに依存せずに部分的なモジュールが 再起動/リプレース可能であること ◦ 実際の運用現場で利用される効率化ツールと親和性をもつこと
4. Copyright © NTT Communications Corporation. All rights reserved. revisit: DPDK’s overview. ref:www.dpdk.org Distributions Gold Members Silver Members Associate Members Amazon, Atomic Rules, Broadcom, Cavium, Chelsio, Cisco, Intel, Marvell, Mellanox, Netcope, Netronome, NXP, Solarflar, Paravirtualization(VMware/KVM), Others Support Hardware ANS, BESS, Butterfly, DPVS, VPP, FastClick, Lagopus, MoonGen, mTCP, OPNFV, OpenDataPlane, Open vSwitch, Packet-journey, Pktgen-dpdk, PcapPlusPlus, Ruru, Seaster, SPDK, TRex, WARP, YANFF Open Source Projects consuming DPDK 6WIND, Calsoft Labs, Intel, Wind River Service/Support Calsoft Labs, Semihalf, Wind River Instructor-Led train DPDK is the Data Plane Development Kit that consists of libraries to accelerate packet processing workloads running on a wide variety of CPU architectures
5. Copyright © NTT Communications Corporation. All rights reserved. revisit: DPDK’s approach Basics to achieve over x10 perf than linux There are some mechanisms makes network application slow, because of general purpose network stack on Linux. DPDK is set of libraries for fast packet processing. it uses some mechanizm to bypass Kernel NetStack. (UIO, pthread setaffinity, special Memory management with hugepages) 1. Memory Copy 2. Context Switch 3. Fat Network Stack 4. Kernel Scheduler 1. No Memory Copy 2. No Context Switch 3. Scratch for perf 4. Avoid K-Scheduler L2Fwdの差をここで図示 できたらよいが今回は割愛 (すみません. できなかった) Linux Networking DPDK Networking
6. Copyright © NTT Communications Corporation. All rights reserved. 6 revisit: DPDK’s core consuming model Run to Completion Model & Pipeline Model FYI: Run to Completion - Kamuee - OvS-dpdk Pipeline - Lagopus - VPP • Run to Completion ◦ pros: Low latency, Utilize HW-option, ◦ cons: nic need be capable RSS, monorithic • Pipeline ◦ pros: low latency, moduler, don’t need RSS ◦ cons: high latency, can’t utilize HW-option • Scientific Comparison is nothing..? (old:RouteBricks)
7. Copyright © NTT Communications Corporation. All rights reserved. revisit: Core Consumption (Fast/Slow thread) 7 Fast Thread • dplane: packet forwarding Slow Thread • cplane: routing protocol • cplane: UI
8. Copyright © NTT Communications Corporation. All rights reserved. revisit: マルチコアへの負荷分散方式 (負荷分散ポイントに注目) 8 - RSS: Receive Side Scaling -> NICの機能 - RPS: Receive Packet Steering -> RSSをソフトウェア的に実現したもの
9. Copyright © NTT Communications Corporation. All rights reserved. revisit: マルチコア活用術: 負荷分散3種類 9 ハードウェアによる負荷分散 CPUに無駄なリソースを割かない Kamueeはこのタイプ ロックフリー実現可能 ソフトウェアによる負荷分散 LBとかはよくのこの方式を用いる 特別なHW支援機構を必要としない ロックフリー実現可能 ソフトウェアによる負荷分散 排他制御を行うことで , RSSと同じ構造を作る. ロックフリー実現不可能 . 10GbE以上では, ロックがボトルネック で, マルチコアの利点すら 薄れてしまう. パケット処理に関してスレッド間で排他制 御があると辛い. せっかくRSSでコスト0 で負荷分散したのに, それすら打ち消さ れる このどちらかを使おう. ロックはだめ.
10. DPDK Data Planeの設計実装の四方山話 • DPDKが他のKernel Bypass系と比べて優れているポイント ◦ D-plane開発のための統合SDKとしてライブラリが豊富 (パケットヘッダ, 経路検索やACLやLock-freeQueue等の各種アルゴリズム ) ◦ 豊富なサンプル(l2fwdからLB, ACL, IPsec等) ◦ 強力なコミュニティ (https://www.dpdk.org/ecosystem/) • Dplane開発者が考えないといけないこと ◦ 表現力を持ったFIBをどうやって作るか. ◦ FIB install時の停止時間をどうやって防ぐか . ◦ 様々な環境で最適に動作するにはどうするか • 並列化やパイプライン化 & バッチ処理をして帯域を稼ぐ ◦ RSS, TxBuffer, Lock-free-Queue
11. revisit: FRRouting • Zebra/QuaggaのFork • Cumulus Linux等での活用. • 他にもBIRD,XORP等あるが, 現状最強 • Linuxをソフトウェアルータにすることができる • 基本的なデータプレーンは Linux kernel • Kernel IP stack / iptables等様々を利用 • 元祖, ルーティングソフトウェア • LinuxのFIBに対して経路を注入する Zebra • ルーティングプロトコルを喋り , 計算をした経路を Zebraに注入する各ルーティングデーモン (bgpd, ospfd, etc...) • オープンソースのソフトウェアルータの ありとあらゆる場面で活用されている . • telnet localhost 2601 でVTYに入り操作する. • 最近Flowspecのcplaneを喋れるようになった . (要iptables)
12. Copyright © NTT Communications Corporation. All rights reserved. revisit: NETLINK 12 • Wikipediaが良い. (https://en.wikipedia.org/wiki/Netlink) • netlink はカーネルモジュールとユーザー空間のプロセス間で 情報をやりとりするために用いられる特別な IPC方式. • カーネルとユーザで全移住通信のリンクを提供し , カーネルの ネットワーク機能に対する様々な設定関連のシグナルがなが される. • Netlinkを監視する ◦ ルーティング経路の追加 ◦ アドレス設定 ◦ リンクアップ等 ◦ etc... • u-proc: 標準的なsocketインターフェース • k-proc: カーネルの内部 API を提供 • nlmonでググれ
13. Copyright © NTT Communications Corporation. All rights reserved. case study: Kamuee / N-path Architecture • KamueeはN=2の場合. • Cplane動作がDplane性能に無影響 • Run to completion dplane • 2 type Data-path ◦ Slow-path: Redirect to the Kernel via TAP ◦ Fast-path: Run to completion in DPDK-space • Linux kernel can perform TCP/IP so-stable • 他SDKの人はどのように同期をとる ? • そもそもそういうの違う ? • XDPはBPF-Mapのみ? • XDPはmessage passing無理? • Kamueeとcumulusは同じ構成. • これに限界があるか ? 特徴はなに? 関連議論
14. Copyright © NTT Communications Corporation. All rights reserved. case study: Kamuee / N-path Architecture • KamueeはN=2の場合. • Cplane動作がDplane性能に無影響 • Run to completion dplane • 2 type Data-path ◦ Slow-path: Redirect to the Kernel via TAP ◦ Fast-path: Run to completion in DPDK-space • Linux kernel can perform TCP/IP so-stable • 他SDKの人はどのように同期をとる ? • そもそもそういうの違う ? • XDPはBPF-Mapのみ? • XDPはmessage passing無理? • Kamueeとcumulusは同じ構成. • これに限界があるか ? 特徴はなに? 関連議論
15. case study: Cumulus Linux switchd • ソースコードは非公開 . • Netlinkを有効活用する構造 . • Netlink対応部分はLinux UIを叩く • Netlink非対応部分はCumulus特別UIを叩く • 必要に応じてLinuxに機能追加をする • RoutingはFRRを活用している
16. case study: Open Route Cache(ORC) by ONL • Cumulus と同様のORCをPoC実装している. not productionと主張 • http://networkautonomy.blogspot.com/2015/01/force10open-network-linux-2.html • https://opennetlinux.org/OCP-May-ONL-final.pdf • ONL(open network linux)のrouter cache https://opennetlinux.org/Open%20Network%20Linux%20-%20A%20Programmers%20View.pdf
17. case study: DANOS based on AT&T’s dNOS • これも元はVRouter5600/Vyatta …? • Whitebox向けにカスタマイズされている ...? • DANOSとかdNOSとかいくつか名前があるけど , どうなんでしょうか... (知っている人教えて ) • http://about.att.com/story/dnos_software_frame work_into_open_source.html • http://about.att.com/story/att_welcomes_brocade _employees.html • http://about.att.com/innovationblog/white_box_h ardware • whitepaperは出ているが, sourceがどこにも出て いない. プロジェクトすすんでいるのか ... • 進んでない...?
18. case study: vMX by juniper c-plane, d-planeをVM分離しているモデル . HVスイッチを用いて, c/pを接続する cplaneはFreeBSDのJunos, dplaneはwind river linuxでDPDKが動いているっぽい . VM分離の理由はMXのOSをそのまま使いたかったから . (Asic API互換のソフトウェアdplaneを書いただけ)
19. Copyright © NTT Communications Corporation. All rights reserved. case study: FD.io Vector Packet Processing 19 • DPDKを用いた, ネットワークスタックフレームワーク . • DPDKにないプロトコルの実装を進める プロジェクトである. • Interop18ではSRのルータとして動いていた • Quaggaと連携する機能も開発されており もっとも強大なライバルかもしれない • Quaggaと連携する機能ちゃんとある ? • Cplane側の成長がしにくい実装な印象 . • CiscoのPoCはここで開発される...? • XRvはVPPをからせたものという印象で良い ? • Cplaneはプロプライエタリという戦略 ?
20. Copyright © NTT Communications Corporation. All rights reserved. case study: Lagopus Router 20 - NTTの開発するOSSのソフトウェアルータ - 以前はOpenFlow Switchのみの機能だった - Netlinkを監視するスタイル - パケット転送はDPDKを用いたC言語だが, パ ケット処理はcgoを用いて, Golangで書かれ ていることが特徴 - Zebra2.0の構造を採用した, dplaneとして動 作することにより, シームレスにルータになる ことができた.
21. Copyright © NTT Communications Corporation. All rights reserved. case study: IP Infusion VirNOS (これわかりません...) 21
22. Control Plane の設計実装の四方山話 netlinkdを開発することになりそう。 RIBの管理機構と連携する APIを頑張って作ることになると思われる - 何を中心に物事を考えるかを決める . → 今回はLinux - ip-routing, interface configはnetlinkでいける. - iptablesはどうだろうか. - netlink daemonが頑張ればLinuxのDplaneを全て置き換えるのは夢ではないと slankは思っている. - 必要に応じてnetilnkに対応するだけ. - みんなはどうですか DPDKの我々が気にしないといけない重要ポイント - TAP/KNI等のSlowpath endpointのこと - 本Interfaceへの更新が何かしら (netlink等)で知ることができるか - Linux-Interfaceの統計情報等はよしなに変更することができるか . (NetFlow/SNMPの課題の話) - Netlink/RoutingSocket等のSync用BusInterface - 新たな昨日に迅速に対応すべき Switchdの設計とは 課題: RIB,FIBをどこでどうやって持っておくのか . Kamueeはまだまだ
23. 課題: それぞれのモジュールは何で繋げよう... • gRPC? NETCONF? REST API? • こればっかりは世の中の発展に合わせないといけない 結論: 何を作ればよかったんや • netlink monitorくんはとても必要としてる . ここだけは絶対に疎結合にしたい • debugが大変だから. • linux の network interfaceの統計情報も変更したいよね . • Linux上に実装されたいいものを使いたい • アルゴリズムもその先に出てくる話ではある • 限界まで性能出したかったらスレッドの使い方を考えよう