スライド
ISPネットワークアーキテクチャ の変化とNFVへの期待 慶應義塾大学 政策メディア研究科 堀場勝広 [email protected] 1 背景:SDN/NFVの流れ • (OpenFlow)SDNの登場 – ネットワーク運用をAPIベースでプログラミングす る時代の到来 • x86仮想ネットワーク機器の登場 – VMとして抽象化されたプロダクト – 今まで専用機でやっていた仕事をx86 VMにして 安上がりにする – プラットフォームが共通なので、プロビジョニング できるようになる ETSI NFV ISGの現状 • ETSIが標準化を進めている – ユースケースや要求事項の議論 – アーキテクチャの標準化 – WG毎に様々な標準化活動 • Proof of Conceptが走り始めている – ISP+複数のネットワークベンダーでチーム – DDoS MiKgaKon、Auto Scaling、などなどシナリオ別に 実装して評価するプランが公開されている – hOp://nfvwiki.etsi.org/index.php?Ktle=On-‐going_PoCs 3 ETSIのNFV ISGロードマップ hOp://portal.etsi.org/nfv/nfv_white_paper2.pdf 4 一方ISPの悩み • トラフィックトレンド(OTT: Over the Topサービス） の変化とその早さ – Network OssificaKon • インターネット技術の革新ではプロトコルスタックの下から 真ん中は弄れない • ネットワークアーキテクチャは追従するしかない • 一般的にトラフィック傾向の変化の方が、アーキテクチャの 変化より速い – 結果的にアプリ特注対応のMiddle BOXの連結 (Network Service Chaining)で解決してきた • Firewall, IDS, IDP, DPI, Cache, Video OpKmizer, etc… • これらはStaKc LocaKonかつMonolithic Productsで実現され ている 5 ISPのCAPEXとOPEX • CAPEX（設備投資によるbit単価） – ミドルボックスの割合は大きい – 追従すると新たなOTTサービスが生まれ･･･要らなく なった箱はどこへ？ • OPEX（運用管理費） – スケールアウト設計、サービス継続性のための検証、 トラブルシューティング – Service fulfillment & assurance are different process. • これが仮想化技術と組み合わさってダイナミックになっ ていくことを目標に 6 SDN/NFV化することよるISPのメリット • CAPEXの低減 – 専用機から汎用機へ、機器単品の価格低下 – 専用機の性能が余ってしまう現象から解放 – 処理すべきトラフィックの傾向変化に追従しやすい • ダイナミックなService ChainingによるOPEXの低減 – 汎用機にそのとき必要なインスタンスを上げれば良い – スケールアップ等を自動化できる可能性 • 新しいサービス形態を高速に展開可能 – ソフトウェア的に組み替えれば新サービス完成 – リファクタリングにより無駄なくリソースを使える 7 軽くNFVの構成要素と用語集 hOp://portal.etsi.org/nfv/nfv_white_paper2.pdf 8 NFV（と言うかDynamicなSFC）はISPの アーキテクチャを変化させるかも？ • 過去、今 – ASICで作られた巨大専用機を数台運用 – バックボーン内部に置き、エッジから集めて処理 • これから – 小型汎用機で並列分散処理へ – エッジで複雑な処理を完結する – 必要な処理を終えたら手早くトランジットやピアに 送り出す 9 Before NFV User CPE Access Edge DPI FW IDP Cache Service Plane B User CPE Internet Service Plane A Access Edge DPI AggregaKon FW IDP Core Backbone コアに投げ込んでデカイ箱で処理 コアのネットワークが混むし、デカイ箱は高い ASBR Afer NFV x86 HW Farm User CPE DPI Access Edge FW Cache IDP ASBR Internet Service Plane A Service Plane B User CPE DPI Access Edge FW IDP AggregaKon Core Backbone 余計な仕事は全部エッジで終わらせる 外に出し入れしないと行けないIPパケットだけBBへ エッジのエンティティが増えて、構成も複雑化 トラフィックのサイズもエッジに寄る DPI何かをベースにダイナミックに構成変更される SFC(Service FuncKon Chaining) NFVI Boot Video Cache End User DPI & Orchestrator CPE / Access Edge サービスを構成する要素をつなげて作る 新しいサービスが必要なら新しい箱（VM）を起動 新サービスを作る、客を動かす、が容易に ASBR Firewall 46NAT Video Cache 12 想定される問題点（性能面） • ASIC/FPGAから汎用機へ – 単一機器でさばけるトラフィック量は減少傾向 – SFCまで考慮して、本当に性能は出るのか？ – SFCで性能を出すネットワーク構成は？ – サービストラフィックを乗せても十分に動くのか？ – 同じトラフィック量を裁いたとき、どのくらいお買い 得なのか？ • 金銭的な問題、ラックスペース的な問題、電力の問題 13 想定される問題点（運用面） • エッジに機能分散するため運用コスト増加 – 単純に数が増えるだけでも大変 – ソフトウェア化により複雑になる • 相互接続性が更に重要に – IOTがAPIベースになる • 人間が隠蔽化していたベンダ間の差異が露呈 • プロトコルレベルで担保されていたモノから、ネット ワークの構成要素が増えた • （NFVI, VNF, Orchestrator, VNF Manager, etc… – できるだけベンダに縛られたくない 14 ISPの運用事情も加味すると • • • • 今動いているサービスを止めずに SDN/NFV特有の問題点を解決しつつ SDN/NFV環境への移行をしたい こう言うことが数千台のx86サーバ上に、数万 台のVMルータがいる環境でできないと行け ない！ • DynamicなService FuncKon Chainingを目指し た新しい研究領域が必要 15 要件整理 • Performance – Wire-‐rate? / Space, Power consumpKon – BoOleneck Point • Inter-‐operability – Service definiKon – Deploy & management – OperaKonal / Programmable • Availability / Redundancy – 99.999% • TesKng / Debugging 16 Performance • Capacity Planningが難しい – 箱モノは性能が数字で明らか • e.g.) Firewall機能が10Mppsで4Uの80Gbpsの転送容量 – VNFはその保証が難しい • NFVIの環境を限定しにくい（縛ったらNFV化する意味が･･･ • 他のVNFとの資源競合 • 例えばIaaSはそれを保証していない – 月額数百円でvCPU4個、メモリ8Gbyte、ディスク 50Gyteと言う売り方は出来る – ハードディスクのiOPSは最低X出ます。とは言えない 17 NFV/SDN的なワークフロー Service Chaining の初期環境構築 ベンダ公表値の パフォーマンスの 50%を超える 追加で機器購入 設定後デプロイ ベンチマーク ボトルネック の調査 実測値の パフォーマンスの 50%を超える SDNなアプローチ でScale Upを実行 18 B ベンチマークと ボトルネックの特定 COTS Server COTS Server VNF A VNF VNF VNF C F D E TOR SW A: TOR SWからトラフィックをVNFへInput B: VNF内でのPacket Processing C: 同じHyperVisor内のVNF間(HyperVisorのvSwitchを使う) D: （異なるHyperVisor上の）VNF間 E: 同じHyperVisor内のVNF間(TOR SWを使う) F: VNFからTOR SWへトラフィックをOutput 19 性能と汎用性のトレードオフ • x86のアーキテクチャで性能を出そうとするとチューニ ングは必須 – 昨日、関谷先生が仰ったとおりVM間パケット転送は遅い – SR-‐IOVやIntel DPDK OVSなど、VM側の特殊なドライバへ の対応が必要 – vSwitchもHyperVisor側のパラーメタチューニングが必要 • チューニングするほど環境の均質化が崩れる – VMにe1000とverKoだけドライバ入れとけば動くんじゃ無 かったか？ – VNF毎に嬉しいチューニングは違う – HyperVisorによって性能が変わる 20 チューニングと特殊ドライバ SR-‐IOV VMMをバイパス VMにVFドライバが必要 同じポートならVNF間もオフロード HyperVisor内のvSwKch VMを跨ぐとContext Switch VMはe1000とかのドライバで動く VNF VNF e1000 Driver e1000 Driver VNF VF Driver VNF VF Driver VMM Linux vSwitch PF VF VF VF VF vEther Bridge and Classifier NIC Driver 21 Inter-‐operability • 今までハードウェアとソフトウェアをセット売り – 動かない取り合わせは無かった – パフォーマンスも最適化されていた – 利用サービスに対して推奨構成、設定、チューニング方 法が定義されていた • NFVではNFVIとVNFが別売りを期待 – 単純にOSとハードウェアを別売りしてるわけでは無い – ハードウェアオフロードの範囲なども曖昧(SR-‐IOVなど） • VNFのdescripKon(meta data)とNFVIのdescripKonが何 らかの情報をベースにマッチングをとれるようにしてや りたい 22 NFVIとVNFのマッチングが必要 • NFVIとVNFの仕様記述 – メーカーサポートと言う意味では無く、技術仕様 に基づく記述 – そのマッチングによって動作を保証する仕組みが 必要 • 現在は･･･ – セット売り、推奨構成がある – A社のEPC（NFVI+VNF）の上でB社のvEPCを動かす のを保証しろって言うの？と言われたことも 23 DescripKon & Programming • Service FuncKon Chainingのブロック図化 – 各ブロックを繋ぐ方法の一般化 – それらを記述する方法が標準化 • Network ServiceとVNFのカタログ化 – カタログからインスタンスを生成 – カタログの記述方法が標準化 – ライセンス認証の方法の多様性などは議論され ていない 24 hOp://www.ien.org/proceedings/88/slides/slides-‐88-‐opsawg-‐6.pdf 25 hOp://www.ien.org/proceedings/89/slides/slides-‐89-‐opsawg-‐7.pdf 26 hOp://www.ien.org/proceedings/89/slides/slides-‐89-‐opsawg-‐7.pdf 27 NFVの構成要素 試験のハンドリング RESTFul APIなど アプリレベル プロトコル無し LibVirtなど 設定投入 IaaSではChefとか DHCP/PXE Bootとか OpenStack(Nova)とか vSphereとか NeutronとかDayLightとか OpenFlowとか Soubound API で VxLAN とか Traffic Generator / Tester External Network Component hOp://portal.etsi.org/nfv/nfv_white_paper2.pdf 28 Availability / Redundancy • Availability – 99.999%（1年に5分ほど落として良い） – 99.9999%（1年に32秒ほど落として良い） • 冗長化手法が多様化 – 利用技術の違い – 扱っているサービスの違い メーカ独自ス テート共有 HyperVisorに よるHA化 O O O ステートフル X O O 冗長化方法/ 自律分散 フローや経路 経路制御 ステートレス 29 TesKng & Debugging • HTTPなどのサーバ技術はテストパターンは確率 されている – E.g.)オンライン決済を10,000TransacKon/Secでエミュ レート • ネットワークサービスにおけるテストパターン は？ – 本当はDPIで流れているアプリケーションをトレンドか ら生成したい？ – が、通信事業者はそこまでやれない（はず） – 動的に生成されたサービスをどう評価するか？ 30 まとめ • ISPのトラフィックトレンドは変化が早い – 今もこれからもミドルボックスで対処 – ミドルボックスへの投資も、運用のコストも落としたい • NFVの特徴から – 少数の強い箱からたくさんの弱い箱へ – X86の上で動くので置き場所、用途を縛らない – そこでダイナミックなミドルボックス構成、運用へ • NFV化することで新たな研究領域がたくさん – NFVIとVNFとMANOをDe-‐coupleしても動かすには？ – 性能と汎用性の両立していくには？ – ダイナミックに構成されるService Chainingの冗長性、可用 性を確認して行くには？ 31 これから先の研究領域（5） • VNFの最適配置化、再配置 – Service Chainingは同じ箱？違う箱？散らばった 方がいい？ – 冗長化の取り方はどうすればいい？ • 箱、プロトコル？アプリ単位？ – デプロイしたサービスが廃止になったら？ • マイグレーションなどを用いて再配置するのか 32 • Open Networking Summitでは – More Availability – More Performance • OpenStack的なもの – Chipset Specificな話をどう抽象化するか、具体化した モノを突っ込んで良いか • vSwitch的な話 – パフォーマンス不足、Inter-‐VNFのトラフィックはどのく らい出れば良い？ • SFC – ボトルネックなしで頑張りたいよね 33 34 • • • • • Monolithic Network Product Network ossificaKon FW, IDS, IDP, DPI, Cache, Video OpKmizer, etc… StaKc LocaKon, Monolithic Products No AutomaKon, dynamic reconfiguraKon, and • OperaKon Complexity is so frustrated. • Service fulfillment & assurance are different process. • Debugging is so hard (on monolithic architecture.) 35 急激なトラフィック傾向変化の例 • NetFlix HDサービスの開始 – （ここではネット中立性の話はしません） – 下り回線がパンパンになった – VerizonやComcastは帯域優先割り当てを開始 – FCCもエッジのブロックは禁ずる物の、Fast Laneに ついては認める • こう言ったサービスをトラフィックトレンドの変 化と共に柔軟かつ迅速に行っていきたい 36 想定されているMiddle BOX • ISPっぽい – – – – – – Firewall DPI IDS/IDP Content Cache Video OpKmizer NAT • キャリアっぽい – – – – – EPC AAA P-‐GW/S-‐GW VoIP関係箱 VPN 37 NFVで目指す場所は • なぜNFVがそれの低減に繋がるか – ISPのコストってどこにかかっているのか？ • ASIC à x86 • COTS再利用 – ISPのボトルネックってどこなのか？ • バックホール、アグリゲーション、コア、対外接続 – ISPの今の問題は？ • Google, nenlix, Youtube, etc… 38 Before NFV EPC Internet End User End User Backbone Middle Boxes ASBR IX EPC コアに投げ込んでデカイ箱で処理 コアのネットワークが混むし、デカイ箱は高い Afer NFV DS End User EPC Internet Middle Boxes End User EPC Middle Boxes Backbone 余計な仕事は全部エッジで終わらせる 外に出し入れしないと行けないIPパケットだけBBへ エッジのエンティティが増えて、構成も複雑化 トラフィックのサイズもエッジに寄る DPI何かをベースにダイナミックに構成変更される ASBR IX – テストパターンをSDNの観点から考える – Etherだ、IPだ、と言う観点だけでは不十分(ITU-‐T Y.1564とか) – サービスを定義して、それが動いていることを担 保するには？ – DevOps – hOp://www.icsi.berkeley.edu/pubs/networking/ leveragingsdn13.pdf 41 これから先の研究領域（2） • サービスのインスタンス化とデプロイ – IaaS型とは違う – 環境がヘテロ、x86とASICが混ざることも視野に – àプログラミングが多様（いろんなプロトコルが混 ざる） – ネットワークとVMを同時にデプロイ – ライセンス認証の方法が多様 42 これから先の研究領域（4） • 性能、資料資源の見積もり、ボトルネックの – 消費電源、利用するCOTSリソースなどNFVIの資 源量が分かるようになるべき 43 図にする • サイクルとして • 作る、パフォーマンス計測をする、ボトルネックを 確認 • リソースの利用状況、予め計測したパフォーマン スから引いたウォーターマークを目処にインスタ ンスの増設、ロードバランシングを行って行く • 自動で出来るならOPEXは落ちるし、様々な用途 に再利用できるNFVIはCAPEXを下げるのに貢献 する 44
© Copyright 2024