Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à TremaDay #2
Similaire à TremaDay #2 (20)
Plus de Toshiki Tsuboi
Plus de Toshiki Tsuboi (14)
Dernier
Dernier (8)
TremaDay #2
- 1. OpenFlow1.2 で、 トラフィックエンジニアリングを 試してみました 2013.4.20 @ttsubo 1
- 5. たとえば、新たにネットワーク構築する場合... ３拠点（ホスト１、ホスト２、ホスト３）をイーサSWで接続す るには、カスケード接続が一般に用いられていると思います。 ホスト２ イーサ SW ホスト１ イーサ イーサ ホスト３ SW SW イーサ SW この構成の課題を、少し考えてみますと... 5
- 6. イーサNWの課題 その１ 拠点間の帯域の増速が行いにくい。 リンクアグリゲーションみたいな手法 は存在するが... ホスト２ イーサ SW ホスト１ イーサ イーサ ホスト３ SW SW イーサ SW 帯域 迫の可能性 6
- 7. イーサNWの課題 その２ 拠点間で故障が発生した場合、迅速に 復旧できない。スパニングツリーみた いな手法は存在するが... ホスト２ イーサ SW ホスト１ イーサ イーサ ホスト３ SW SW イーサ SW 故障に伴う 通信断 7
- 8. 理想的なイーサNWとは... 拠点に配備されたイーサSW間で、複 数の通信ルートが確保できる環境が望 ましいです。 ホスト２ イーサ SW ホスト１ イーサ ホスト３ SW イーサ SW 8
- 9. 帯域 迫への対応が容易 拠点イーサSW間で、複数の通信ルートを 確保できる環境では、トラフィック分散 が可能となります。帯域増速を目的とした ネットワーク拡張が図りやすくなります。 ホスト２ イーサ SW ホスト１ トラフィック イーサ 分散 SW ホスト３ イーサ SW 9
- 10. 通信故障への対応が容易 拠点イーサSW間で、複数の通信ルートを 確保できる環境では、 通信故障時、 回 ルートへの切り替えが可能となります。 よって、ネットワーク復旧が実施しやすく なります。 ホスト２ イーサ SW ホスト１ トラフィック イーサ 回 ホスト３ SW イーサ SW 10
- 11. 現行のイーサNW運用の肝は、ループの防 止ですが、現在のネットワーク技術で は、ループを防止しつつ、L２マルチパス 制御が難しいという課題がありました。 ホスト２ イーサ SW ホスト１ イーサ ホスト３ SW イーサ SW 11
- 13. 答え「OpenFlowでTE」 だと思います。 • トラフィックエンジニアリング(TE)は、WAN構築に限らず、エンター プライズ適用が可能な技術です。 • TEでは、トラフィック分散、プロテクション（高速復旧）を実現でき る技術です。ただし、エンドエンドでの帯域制御は、まだまだ難しい ですね。（TEなQoS制御は、結構、敷居が高いです。） • TEを適用するためには、MPLSルータ機器を購入する必要がありませ ん。汎用OpenFlow機器で実現可能です。（現時点では、制約条件が 多いです...） • 従来のTEでは、通信経路制御として、各種プロトコル知識（OSPF, BGP, LDP, RESV-TE ...）が必要でした。これからは、OpenFlowコン トローラによるL２マルチパスな通信制御制御で代替可能となります。 詳細は、割愛させて頂きます！！ 13
- 15. 最近のネットワーク仮想化について IaaS側のテナントネットワークと拠点間ネットワークを オーバレイ方式で接続する利用形態が、増えてきています。 テナント テナント NW NW ネットワーク抽象化 企業A 企業A （オーバレイNW） 企業B 企業B エッジ エッジ 装置 装置 R R R R R R アンダーレイNW （従来のIP機器） 15
- 16. オーバレイNWの技術要素 現行のオーバレイNW技術では、OpenFlowを適用せずとも、 環境構築が可能です。既存のテナント管理との相互接続とし て、OpenFlow適用が検討される程度です。 テナント管理 テナント テナント NW （VLAN, OpenFlow...）ネットワーク抽象化 NW 企業A 企業A （オーバレイNW） テナント／トンネル連結エッジ 企業B 企業B エッジ 装置 （NVGRE, VxLAN...） 装置 L3技術 R R R R R R アンダーレイNW 16
- 17. オーバレイNWの特徴 オーバレイ方式の利点は、単一ベンダによる垂直統合モデルとの親和性が高いところ だと思います。コスト低減を想定したマルチベンダ化を見据えた場合、逆にボトルネ ックになると思います。 ・エッジ装置間で仮想ネットワークを構築してしまえば、OpenStack等のクラウド 管理基盤との親和性が高くなり、ITリソースのスケールアウトに追従しやすい。 ・アンダーレイNWとオーバレイNWの運用管理が独立してしまうので、柔軟かつ 包括的なネットワーク運営が行いにくい １）アンダーレイNWの帯域 迫の課題が顕在化した場合の対処は？ ２）アンダーレイNWでNW機器等の故障時、L３ルーティング再計算構築に依存 ・エッジ装置間で仮想ネットワークを構築するためには、ベンダ技術の適用に依存 してしまう（例；VxLAN、NVGRE、STT） １）フルオープンソースでの環境構築が難しい ２）ベンダへの構築作業委託を前提とするならば、手間が省ける 階層ネットワークをOpenFlowで制御するホップByホップ方式は、どうだろうか？ 17
- 18. ホップByホップで実現する場合… OpenFlow1.xのフローエントリ管理手法を活用すれば、オーバ レイ方式と同様の階層ネットワークを構築可能となります。 テナント テナント NW NW 企業A OFC 企業A エッジ エッジ 企業B 企業B 装置 装置 拠点間パス OFS OFS OFS OFS OFS OFS アンダーレイNW （OpenFlowスイッチ） 18
- 19. ホップByホップNWの技術要素 エッジ装置間の拠点間パス経路と、テナントNWとの連結を OpenFlowのマルチTableにて一括管理する感じです。 テナント テナント NW NW OFC 企業A 企業A テナント管理 （OpenFlow） 企業B エッジ エッジ 企業B 装置 装置 テナント／パス連結 （OpenFlow） 拠点間パス OFS OFS OFS OFS OFS OFS アンダーレイNW （OpenFlowスイッチ） 19
- 20. OpenFlowでのフロー制御の留意点 拠点間パスを構築するには、プロアクティブでのフローエン トリ構築が必須となります。リアクティブな動作を如何に抑 止するかが、 となります。 （１）効率的なフロー設定 – リアクティブなFlowEntry • OpenFlowスイッチ側での転送処理が完結せず、 Packet-In動作によるコントローラへの問い合わせ処 理がオーバヘッドとなり、NW全体のパフォーマンス が劣化する（＝スケールしない） – プロアクティブなFlowEntry • OpenFlowスイッチ側での転送処理が完結するため、 NW全体のパフォーマンス向上が期待できる • FlowEntry量の肥大化を防止する工夫が必要となる 20
- 21. OpenFlowでのフロー制御の留意点 （２）リアルタイムなフロー監視 – 従来のNW機器モデル • ルーティングTBL／フォワーディングTBLが同一筐体 で保持されるため、データ整合性が保証しやすい。 監視 設計 ルーティング 監視 設計 コントロールプレーン プロトコル コントロールプレーン ルーティングTBL ルーティングTBL データプレーン データプレーン データ整合が フォワーディング フォワーディング TBL TBL 保証しやすい 21
- 22. OpenFlowでのフロー制御の留意点 （２）リアルタイムなフロー監視 – OpenFlow機器モデル • ルーティングTBL／フォワーディングTBLが異なる筐 体で保持されるため、データ整合性の保証が難しい。 監視 設計 データ整合の コントロールプレーン OpenFlow ルーティング ルーティング コントローラ 保証が難しい TBL TBL OpenFlow Controller OpenFlowスイッチ OpenFlowスイッチ OpenFlow プロトコル OpenFlow-Agent OpenFlow-Agent データプレーン データプレーン フォワーディング フォワーディング TBL TBL 22
- 23. OpenFlow監視の理想形態 OpenFlowコントローラで NWオペレータ 保持しているフロー情報と、 設計 監視 OpenFlowスイッチで保持 コントロールプレーン しているフロー情報が同期 ルーティング ルーティング OpenFlow されていることを把握したい。 TBL TBL コントローラ OpenFlow Controller OpenFlow OpenFlow プロトコル OpenFlow スイッチ OpenFlow-Agent OpenFlow-Agent スイッチ データプレーン データプレーン フォワーディング フォワーディング TBL TBL OpenFlowスイッチ毎のFlowEntryの正常性を確認した上で、 エンドエンド経路診断を実施したい。 23
- 25. OpenFlow-TE検証環境 というわけで、プロアクティブなFlowEntryで、ホップByホップな階層ネットワークを OpenFlowで構築してみました。 OFC OpenFlow チャネル OFS OFS OFS OFS OFS OFS アンダーレイNW （OpenFlowスイッチ） 目標感 OpenFlow-TEで、イーサループを防止しつつ、帯域有効活用をねらったL2マルチ パスと通信故障に伴う 回ルートへの復旧制御を実現する手段を試してみたい。 トラフィック分散 イ トラフィック 回 イ イ イ イ イ 25
- 26. 特徴１「拠点間フロー集約なパス構築」 事前に拠点間パスを構成するフローエントリを設定することに よるホップByホップ環境を構築。 拠点間パス用FlowEntryを テナント テナント NW 事前に登録しておく NW TOSによる高品質パス OFS エッジ エッジ TOSによる低品質パス OFS 拠点間パスを一意に識別できるよう、VlanタグやMPLSラベルが用いられるのが 今回のOVS環境では、いずれも、フローエントリ設定が成功せず、、、（原因不明） よって、IPヘッダのTOS値を代用して、L2マルチパス環境を構築しました。 26
- 27. 特徴２「柔軟なテナントNWの収容」 テナントNWに配備されたエンド端末が送出する通信パケット 種別に応じて、パス収容先を選択可能。 たとえば、TCPは、高品質パスに、UDPは低品質パスに収容とか。。。 テナントNW／通信パケット種別毎に テナント テナント NW テナント用FlowEntryを登録する NW TOSによる高品質パス OFS OFS OFS TOSによる低品質パス OFS 27
- 28. 特徴３「通信故障時の自動 回制御」 拠点間パス毎に、複数の通信ルートを確保しておき、通常の通 信ルートで通信故障が発生した場合には、迅速に、別ルートへ 切り替えるような故障復旧の自動化が可能。 故障復旧として、テナント用FlowEntry テナント テナント NW を自動修正（高品質→低品質）する NW TOSによる高品質パス OFS OFS OFS TOSによる低品質パス OFS 28
- 30. OpenFlowデモ実演（通常時） 拠点間パスを事前に構築した上で、ICMPトラフィックを高品質 パスに収容し、TCPトラフィックを低品質パスに収容したトラ フィック分散を実現できます。 HOST-1 HOST-2 OVS-1 OVS-2 OVS-3 高品質パス（ICMP用） OVS-4 OVS-5 OVS-6 低品質パス（TCP用） 30
- 31. OpenFlowデモ実演（通信故障時） ICMPトラフィックを収容した高品質パスの通信ルート区間に おいて、通信故障が発生した場合、 回パスに自動切り替えを 行い通信復旧できます。 PortStatusメッセージ が送出されないような 通信故障を想定！ HOST-1 HOST-2 OVS-1 OVS-2 OVS-3 高品質 回パス （ICMP用） OVS-4 OVS-5 OVS-6 低品質パス（TCP用） 31