SDNにおけるスイッチ・コントローラ間切断時のネッ トワーク復旧機構

東工大 通信情報工学専攻 2015年度 修論発表会 にてスピーチ。

Transcript

1. SELF-HEALING MECHANISM ON SWITCH-CONTROLLER CONNECTIONS IN SDN 4%/ʹ͓͚ΔεΠονɾίϯτϩʔϥؒ੾அ࣌ͷωο
   τϫʔΫ෮چػߏ
   ౉ᬑ
   ୓ຑ
   ౦ژ޻ۀେֶେֶӃ
   ཧ޻ֶݚڀՊ
   ௨৴৘ใ޻ֶઐ߈
   ൧ాݚڀࣨ
   म࢜՝ఔ
   2015/02/09 1
2. 本研究の要旨 •  SDN(Software-Defined Networking)が発展・広く普及 •  SDNは信頼性に難あり •  特に災害など、大規模リンク断への耐性に難 •  信頼性向上のため、 リンク断に対する自己修復機構を提案 1.  必要な機能の分析と設計 2.  機能を実現するための実装手法の検討 3.  機構の妥当性の実験的検証と性能評価 4.  機構の更なる応用についての議論 1.  拡張と追実験 2
3. 背景: SDNの普及 •  SDNが進展[1][2]… •  ネットワークサービス・アプリケーションが多様化 •  ネットワークが複雑化・リソース要求が高度化[3] •  →柔軟で効率的なネットワーク制御を可能にするSDNが普及 アプリケーション 動的制御 ネットワークインフラ [1] D. Kreutz, et al., “Software-Defined Networking: A Comprehensive Survey,” Proc. of the IEEE, vol. 103, no. 1, pp. 14–76, Jan. 2015. [2] N. Feamster, et al., “The Road to SDN,” ACM Queue, vol. 11, issue 12, pages 20, Dec. 2013. [3] M.F. Bari, et al., “Data Center Network Virtualization: A Survey,” IEEE Comm. Surveys & Tutorials, vol. 15, no. 2, pp. 909–928, Q2, 2013. 3
4. 背景: SDNの設計 •  SDNが進展… •  制御機構(Control Plane) と データ転送機構(Data Plane) を分離 •  制御機構を集約 4 Control  Plane   Data   Plane   Data   Plane   Data   Plane   Control   Plane   Control   Plane   Data   Plane   Data   Plane   Switch   Switch   Switch   Controller   ैདྷͷωοτϫʔΫ   SDN  ωοτϫʔΫ   Control  Channel   Control Plane ・トポロジ収集 ・ルーティングテーブル生成など Data Plane ・パケット転送 (੍ޚνϟωϧ)  
5. 背景: SDNの信頼性 •  SDNの信頼性 •  スイッチ・コントローラ間リンク(制御チャネル)が切断されるとアウト (スイッチ側に制御機構なし) •  災害などでリンク断・装置故障が起きた場合などの 信頼性向上が重要な課題 [4] 5 Controller   Switch   Switch   Switch   Oops! [4] B.J. Asten, et al., “Scalability and Resilience of Software-Defined Networking: An Overview,” arXiv:1408.6760v1 [cs.NI], Technical report, Cornell univ., Aug. 2014.
6. 既存研究 •  SDNの信頼性向上について •  障害の防止という観点 •  あらかじめ用意したバックアップコントローラへ切替 [5][6] •  あらかじめ設定したバックアップ経路へ高速切替 [7][8][9] •  障害からの回復という観点 •  コントローラに依存しバックアップ経路をセットアップ [10] 6 [5] P. Fonseca, et al., “A replication component for resilient openflow-based networking,” IEEE NOMS, 2012. [6] Kuroki, et al., “OpenFlow Controllerの冗長化に関する検討”, 　　電子情報通信学会 ネットワーク仮想化時限研究専門委員会 第5回専門委員会, 2013. [7] S. Sharma, et al., “Openflow: meeting carrier-grade recovery requirements,” Computer Communications, 2012. [8] N. L. M. van Adrichem, et al., “Fast recovery in software-defined networks,” IEEE EWSDN, 2014. [9] A. Sgambelluri, et al., “Openflow-based segment protection in ethernet networks,” IEEE/OSA JOCN, 2013. [10] S. Sharma, et al., “Fast failure recovery for in-band openflow networks,” IEEE DRCN, 2013. •  任意箇所/複数のリンク断には対応できない ✗ •  コントローラに依存した弱い復旧能力 •  → 大規模災害時の信頼性確保に難
7. 本研究の目的 •  SDNネットワークにおいて 災害など任意/複数のリンク断の発生時に スイッチの制御チャネルを自律的に復旧させることで ネットワークを自律的に維持する機構の確立 •  要求事項 •  任意箇所・複数のリンク断への対応 •  コントローラに依存しない自律的な復旧 •  研究内容 1.  必要な機能の分析と設計 2.  機能を実現するための実装手法の検討 3.  機構の妥当性の実験的検証と性能評価 4.  機構の更なる応用についての議論 7
8. 提案 •  スイッチが自律的に(=コントローラに依存せず) 自らの制御チャネルを復旧できるようにする S   S   C   S   M M M S   S   C   S   M M M ✗   ϦϯΫ੾அલ   ϦϯΫ੾அޙ   Controller   Switch   CCMM(ఏҊػߏ)   S   C   M   8
9. 設計 目的: ・制御チャネルの自律復旧 必要な機能: (1)経路計算のため、 　・トポロジ情報の交換 (2)切断検知のため、 　リンク状態の監視 　　　　↓ (3) 切断時に 　フローエントリ編集し 　制御チャネルを確立 CCMM(Func=onality(1( S( M S( M He’s(alive
   CCMM(Func=onality(2( S( M S( M CCMM(Func=onality(3( S( M S( M S( M ✗( ✗( ✓( C( Control(Channel( via(new(path
   9 (3) (2) (1)
10. 機能: (1)リンク状態の監視 (2)トポロジの交換と経路計算 (3)フローエントリの生成・制御 (制御タイミングの計算含) 実装: (1)(2): 通常の LS型経路計算手法と同等 → OSPFが適用可能 (3): 必要な情報収集と 　　　フローの計算 → 新規に実装 (挿入タイミングは常時) 実装 実装上の特記事項は論文を参照 10 CCMM(Func=onality(2( S( M S( M CCMM(Func=onality(3( S( M S( M S( M ✗( ✗( ✓( C( Control(Channel( via(new(path
    (3) (2) CCMM(Func=onality(1( S( M S( M He’s(alive
    (3)  ৽نʹ࣮૷   (1) (1)  (2)  OSPF  Λར༻  
11. 実験・評価 •  機構の妥当性の実験的検証と性能評価 •  妥当性 1.  制御チャネルのタイプによらず動作するか (シナリオ1) 2.  複数・ランダムなリンク断でも動作するか (シナリオ2) •  性能評価 •  単スイッチの復旧時間 (シナリオ1) •  ネットワーク全体の復旧時間 (シナリオ2) 11
12. 実験・評価 › シナリオ1 •  妥当性 •  制御チャネルのタイプによらず動作するか (シナリオ1) •  制御チャネルのタイプとは (1) 直接接続 (In-band) (2) 間接接続 (Out-of-band) Controller   Switch   Switch   (2)   (1)   12
13. 実験・評価 › シナリオ1 •  トポロジ 13 •  接続タイプ •  3種類 (直接 → 間接、 　　　　間接→ 間接、 　　　　間接→間接(途中経路)) •  計測項目 •  トポロジマップ生成時刻 •  フローエントリ挿入開始時刻 •  フローエントリ挿入終了時刻 •  制御チャネル復旧時刻
14. 実験・評価 › シナリオ1 C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
     C
    1
    2
    3
     (a) Out-to-in (b) In-to-in (c) In-to-in-middle Figure 5.3: Three failure cases in single specified link failure experiments chronously collects the network topology map, calculates the path, and installs the fl entries. This is considered to happen due to the reason that the in-to-in and the in-to middle case take a longer path than the other cases after the disconnection. After all switch alongside the path from the switch to the controller are configured, the switc can restore the connectivity to the controller. This describes the time between the tim C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
     C
    1
    2
    3
     (a) Out-to-in (b) In-to-in (c) In-to-in-middle Figure 5.3: Three failure cases in single specified link failure experiments chronously collects the network topology map, calculates the path, and installs the fl entries. This is considered to happen due to the reason that the in-to-in and the in-to middle case take a longer path than the other cases after the disconnection. After all switch alongside the path from the switch to the controller are configured, the switc 直接→間接 間接→間接 間接→間接(途中経路) 2 hops 2 hops 3 hops 3 nodes 4 nodes 4 nodes 211.5 ± 0.3 [ms] 246.3 ± 7.0 [ms] 211.5 ± 0.6 [ms] 279.3 ± 23.9 [ms] 217.9 ± 8.7 [ms] 292.7 ± 9.3 [ms] トポロジ生成時間 制御リンク復旧時間 ホップ数(切断後) ノード数 切断後 切断前 14
15. 実験・評価 › シナリオ1 •  結果 •  全てのトポロジで正しく復旧 •  復旧時間は300 [ms]以下 •  間接→間接・間接→間接(中間経路)ケースにて 復旧時間が伸びている •  トポロジ内のノード数が増え、 OSPFの安定に時間がかかっていることが原因と考えられる 15
16. 実験・評価 › シナリオ2 •  妥当性 •  複数・ランダムなリンク断でも動作するか (シナリオ2) •  補足: 実環境での動作検証を念頭においている 16
17. ・実トポロジを使用[11][12] 　・36ノード、76リンク ・コントローラは1台(赤印) 　・接続リンク数が最高かつ 　　ノード番号最小のノード ・残りはすべてスイッチ ・リンク断率に対する 　・復旧可能なスイッチ数 　・ネットワーク復旧時刻 を計測 補足: ・帯域は1Gbps・遅延は地理的距離から算出設定 ・リンク切断は全て同時刻に行う ・リンク数N、リンク断率xの時、[x * N]リンクを断線させる。[…]は床関数。 ・復旧可能なスイッチ := 切断後にもコントローラへの接続経路を有するスイッチ ・ネットワーク復旧時刻 := 全復旧可能スイッチの制御リンク復旧時刻 実験・評価 › シナリオ2 [11] S. Knight, H. Nguyen, N. Falkner, R. Bowden and M. Roughan, “The Internet Topology Zoo,” IEEE Journal on Selected Areas in Communications, vol. 29, no. 9, pp. 1765–1775, Oct. 2011. [12] The University of Adelaide, “The Internet Topology Zoo,” http://www. topology-zoo.org/, last accessed at 21 Oct. 2014. 引用元: Topology Zoo [12] 17
18. 実験・評価 › シナリオ2 ・ネットワーク復旧時間は、リンク断率が40[%]あたりをピークにおよそ13秒 ・それ以降は、ネットワーク復旧時間は短くなる •  ネットワーク復旧時間 •  復旧可能なスイッチの数 0 10 20 30 40 50 60 70 80 90 100 Link failure rate [%] 0 2 4 6 8 10 12 14 16 Network restoration time [s] 0 10 20 30 40 50 60 70 80 90 100 Link  failure  rate  [%] 0 5 10 15 20 25 30 35 40 #  of  controller-­reachable  switches 18
19. 実験・評価 › シナリオ2 •  結果 •  大規模リンク断発生時も正しく動作 •  ネットワーク復旧時間は リンク断率が40[%]あたりをピークにおよそ13秒 •  それ以降は、復旧可能なスイッチ数が減り、短縮 •  復旧タイムスケールが大きく変わった •  想定要因: •  制御チャネルのタイムアウトと再接続を確認 •  トポロジの大規模化によりOSPFの安定が遅れたと想定される 19
20. 議論 •  Controller-CCMM Coordination Problem •  背景: コントローラは全てを掌握できる •  問題: CCMMもコントローラにより制御可能にする必要 •  SDN Bootstrapping Problem •  背景: コントローラは全てを制御できる •  問題: コントローラにつなぐための制御はどうするのか？ •  SDN Domain-Splitting Problem •  背景: リンク断が酷いと、ネットワークのいち部分が切断・独立 •  問題: 独立ネットワークをどう制御するか？ 20
21. まとめ •  SDN(Software-Defined Networking)が発展・広く普及 •  SDNは信頼性に難あり •  特に災害など、大規模リンク断への耐性に難 •  信頼性向上のため、 リンク断に対する自己修復機構を提案 1.  必要な機能の分析と設計 2.  機能を実現するための実装手法の検討 3.  機構の妥当性の実験的検証と性能評価 1.  検証: 実装は妥当、適切に動作した。 2.  性能: 小規模トポロジで300ms以下、大規模トポロジで秒オーダー。 4.  機構の更なる応用についての議論 1.  拡張と追実験 21
22. APPENDIX A: SDN 22
23. Architectural  Comparison Control  Plane   Data   Plane   Data   Plane   Data   Plane   Control   Plane   Control   Plane   Data   Plane   Data   Plane   Applica?ons   Switch   Switch   Switch   Switch   Switch   Controller   Conven?onal  Architecture   SDN  Architecture   Control  Channel   Northbound  API   Southbound  API   23
24. SDN Switch Design Physical  Ports   Flow  Table   To  the  Controllers   Control  Channel   End  point   Datapath   Matching Rule 1 Action(s) 1 Matching Rule 2 Action(s) 2 … … 24
25. SDN Switch-Controller Connection (1) In-band (2) Out-of-band Controller   Switch   Switch   (2)   (1)   25
26. SDN and OpenFlow 26 Switches Controllers Applications Northbound API Southbound API (OpenFlow protocol) SDN OpenFlow
27. Comparison of Traditional Arch. vs O.F. Arch. 27 Data plane Control plane •  トポロジ収集 •  ルーティングテーブル生成 •  etc… •  パケット転送 Switch
28. Comparison of Traditional Arch. vs O.F. Arch. 28 Data plane Control plane •  トポロジ収集 •  ルーティングテーブル生成 •  etc… •  パケット転送 Switch OpenFlow protocol / TCP or TLS or UDP or DTLS Controller
29. OpenFlow Controller OpenFlow (Logical) Switch Control Channel Datapath OpenFlow Protocol 29
30. OpenFlow Controller OpenFlow (Logical) Switch Control Channel Datapath OpenFlow Protocol FlowTable( s) GroupTabl e Port(s) OpenFlow Protocol (must) ------------------------- TCP / TLS / UDP / DTCP (any of these OpenFlow Channel 30
31. OS Protocol Stack OS Protocol Stack OpenFlow Controller OpenFlow (Logical) Switch Control Channel Datapath 31
32. APPENDIX B: SDN’S RELIABILITY 32
33. Reliability  of  Control  Plane   Reliability  of  Data  Plane   Reliability  in  SDN Switch   Switch   Switch   Controller   Control  Channel   33
34. 既存研究 34 •  SDNの信頼性向上について •  切断の防止という観点 •  あらかじめ用意したバックアップコントローラへ切替 [4][5] Controller Switch Controller [4] P. Fonseca, et al., “A replication com- ponent for resilient openflow-based networking,” IEEE NOMS, 2012. [5] Kuroki, et al., “OpenFlow Controllerの冗長化に関する検討”, 電子情報通信学会 ネットワーク仮想化時限研究専門委員会 第5回専門 委員会, 2013.
35. 既存研究 35 •  SDNの信頼性向上について •  切断の防止という観点 •  あらかじめ設定したバックアップ経路へ高速切替 [6][7][8] Controller Switch [6] S. Sharma, et al., “Openflow: meeting carrier-grade recovery requirements,” Computer Communications, 2012. [7] N. L. M. van Adrichem, et al., “Fast recovery in software-defined networks,” IEEE EWSDN, 2014. [8] A. Sgambelluri, et al., “Openflow-based segment protection in ethernet networks,” IEEE/OSA JOCN, 2013.
36. 既存研究 36 •  SDNの信頼性向上について •  切断からの回復という観点 •  バックアップ経路を自動セットアップ [9] [9] S. Sharma, et al., “Fast failure recovery for in-band openflow networks,” IEEE DRCN, 2013. Controller Switch Switch Switch Switch ✗
37. 既存研究 37 [10] 水越, et al., “B-6-7 モバイルネットワークの動的再構成(1) : 大規模災害時における移動通信網の動的トラヒック制御方式の検討(B-6. ネットワークシステム,一般セッション)”, 電子情報通信学会ソサイエティ大会講演論文集 2012年(通信_2), 2012.
38. APPENDX C: IMPLEMENTATION 38
39. Design of CCMM-enabled switch Physical(Ports( Switch(Design( Flow(Table( Control(Channel( End(point( Control(Channel( Maintenance(Module( Neighboring( CCMMs( Controllers( (3)( 3)(Installs(Flow(Entries( 1)(Monitors(Link(Status( 2)(Exchanges( ((Network(Topology(Map( (1)( (2)( S( M( S( M( S( M( C( (1)(Heartbeat( (2)(Topology(Map
    39
40. Implementation of CCMM-enabled switch Switch(Implementa=on( Linux(Node( Flow(Entry( Installer( Linux(kernel’s( Rou=ng(Table( OSPF(daemon( (Quagga(and(OSPFd)( Open(vSwitch( Generates(Rou=ng(Table( Retrieves( Rou=ng(Table( Installs( Flow(Entries( External(Ports( Internal(Ports( Monitors(Link(Status(and( Exchanges(Network(Topology(Maps( 40
41. 実装 •  実装上の特記事項 •  フロー制御タイミングを常時とした •  切断検知後の場合、ブートストラップ(通知・状態同期)が必要になり複雑化 •  また、ブートストラップにも時間がかかり、復旧時間の悪化が想定される •  SDNスイッチとOSPFデーモンソフトウェアを共存させるための設計 •  内部ポートの応用 •  パススルーフローエントリの制御(ARP+OSPF) •  OSPFデーモンの吐き出した経路表が ノード上のアプリケーション(含SDNスイッチの制御リンク)経路制御に 影響を及ぼさないための設計 •  マルチプルルーティングテーブルの適用 •  経路表のフローエントリへの変換と制御 •  挿入タイミングの計算 (ルーティングテーブルの監視) •  フローエントリへの変換処理 •  ARPテーブル + ルーティングエントリの参照 •  フローエントリの挿入 41
42. Switch Implementation: Internal Ports Normal  Situa?on   OSPF daemon Physical Ports Interfaces Seen by applications With  Open  vSwitch  Situa?on   OSPF daemon Physical Ports Interfaces Seen by applications Bridge (Open vSwitch Bridge) OSPF daemon cannnot handle each ports separately 42
43. Switch Implementation: Internal Ports With Open vSwitch Situation (Fixed) (1)   OSPF daemon Physical Ports Interfaces Bridge ・Create the same number of Internal Ports With Open vSwitch Situation (Fixed) (2)   OSPF daemon Physical Ports Interfaces ・Insert OSPF-passthrough flow entries 43
44. APPENDIX D: EVALUATION 44
45. Experimental Evaluation with Mininet Host Linux Node LXC Controller Controller Interface OSPFd LXC Switch (OvS) Flow Installer Switch 1 OSPFd LXC Switch (OvS) Switch n OSPFd 45 TC Link Flow Installer ・Creates Network Topology ・Manages Nodes Mininet
46. 実験環境 •  実機エミュレーション環境を用いた •  柔軟な設計・実装の変更 •  大規模なデプロイ •  Mininetをフレームワークに独自実装 •  SDNスイッチとOSPFデーモンを動作させるために スイッチに特別な改造を施した •  これにより、Mininetについても リンクの切断処理に特別な改造を施した •  全スイッチノードにおいて以下を行うシナリオプログラムを作成 •  SDNスイッチの設定ファイル生成・起動 •  OSPFデーモンの設定ファイル生成・起動 •  フローエントリ生成プログラムの起動 •  制御チャネル復旧時間測定プログラムの設定・起動 46
47. 実験 › 小規模シナリオ 47 •  切断ケースごとに性能をみることが主眼 •  3種類の切断ケースを用意 •  切断時刻を0とし、以下の時間を測定 •  トポロジマップ生成時刻 •  フローエントリ挿入開始時刻 •  フローエントリ挿入終了時刻 •  制御チャネル復旧時刻 •  制御チャネルの再接続について、ログを監視
48. 実験 › 小規模シナリオ 48 •  ベースとなるトポロジ •  4ノード(1コントローラ、3スイッチ)、6リンク
49. 実験 › 小規模シナリオ 49 •  Out-to-in ケースの結果
50. 実験 › 小規模シナリオ 50 •  In-to-in ケースの結果
51. 実験 › 小規模シナリオ 51 •  In-to-in-middle ケースの結果
52. An example timeline of the restoration on Large Topology Scenario 00 01 02 03 04 05 06 07 08 09 10 11 12 13 Time from link down [s] 0 5 10 15 20 25 30 35 # of restored switches 0.0 0.2 0.4 0.6 0.8 1.0 Ratio of restored switches to total switches 52
53. An example topology after disconnection on Large Topology Scenario 25 26 27 28 21 22 23 24 29 30 2 1 4 3 6 5 8 7 10 9 12 11 14 13 16 15 18 17 20 19 32 31 36 35 34 33 53
54. Another example topology after disconnection on Large Topology Scenario 25 26 27 28 21 22 23 24 29 30 2 1 4 3 6 5 8 7 10 9 12 11 14 13 16 15 18 17 20 19 32 31 36 35 34 33 54
55. APPENDIX E: FURTHER EXTENSION OF CCMM 55
56. 拡張と追実験 (1/4) •  大規模トポロジ、高いリンクダウン率において、 ドメインが分割されるケースが散見された 56 S   Before  Links  are  Disconnected   Reachable  domain   Controller   Switch   S   C   C   S   S   S   S   S   S   S   C   S   S   S   S   S   S   ✗ ✗ Unreachable  domain   Unreachable  domain   ANer  Links  are  Disconnected  
57. 拡張と追実験 (2/4) •  CCMMはフローエントリを制御する能力がある •  拡張すれば、コントローラとして用いることが出来るのではないか？ •  切断されたドメイン内の緊急的な代替コントローラとして用いる •  拡張 •  (1) コントローラとしてのインタフェイスを備える •  (2) ドメイン内のスイッチ群から代替コントローラを選出 •  (3) スイッチに、代替コントローラへの再接続を指示 57
58. 拡張と追実験 (3/4) •  実現可能性の検証 •  切断されたドメインにて、 スイッチ群が代替コントローラに集約されるかを検証 58 3   1   ϦϯΫ੾அલ   2   ɾϦϯΫ੾அޙ   Controller   Switch   CCMM   S   C   M   M M M C   3   1   2   M M M C   ✗  
59. 拡張と追実験 (4/4) •  結果 •  適切に全スイッチが集約されることを確認 •  復旧時間は 1618 ± 499 [ms] 59
60. APPENDIX F: DISCUSSIONS 60
61. 考察 (1/4) •  CCMM–Controller Coordination Problem •  SDN Domain-Splitting Problem •  SDN Bootstrapping Problem 61
62. 考察 (2/4) •  CCMM–Controller Coordination Problem •  SDNでは、コントローラはネットワークを掌握する必要がある •  CCMMはフローエントリを制御する •  CCMMとコントローラの協調機構が必要 •  どのアドレス空間をOSPF用に用いてよいか •  どのフローテーブルを制御してよいか •  どのようなフローエントリが編集されたか 62
63. 考察 (3/4) •  SDN Domain-Splitting Problem •  コントローラへの接続性を完全に失うドメインが出現 •  緊急的な代替コントローラとしてCCMMが応用可能 •  代替コントローラの選出アルゴリズムが重要となる •  Hellerらは、平均往復時間が最小となるノードを選出する手法を提案 [11] •  また、アプリケーションとの協調機構も重要 63 [11] B. Heller, et al., “The Controller Placement Problem,” ACM SIGCOMM Computer Communication Review, vol. 42, no. 4, pp. 473–478, Sep. 2012.
64. 考察 (4/4) •  SDN Bootstrapping Problem •  「スイッチをコントローラに接続する前、 どのようにスイッチをコントローラに接続するよう設定するか？」 •  SDN標準化のひとつ、OpenFlowでは、仕様の範囲外 •  CCMMは自律的・自動的なフローテーブルの制御が可能 •  →本問題への応用が可能 •  ただし、一般的なOSPFの設定は依然必要 64