NFV

Transcription

1 OpenStack を利用した NFV の実用化 2017 年 12 月 7 日 NTT ドコモネットワーク開発部 田村宏直

2 ネットワーク仮想化への取り組み 2

3 ネットワーク仮想化のメリット メリット 1 通信混雑時のつながりやすさの向上 ( オートスケーリング ) メリット 2 通信サービスの信頼性向上 ( オートヒーリング ) メリット 3 サービスの早期提供 ( システム個別 HW の構築が不要 ) メリット 4 ネットワーク設備の経済性向上 (COTS 共用化 ) 上記メリット最大化のためには複数ベンダー装置の組み合わせが必要 3

4 メリット 1 ネットワーク設備の経済性向上 汎用が共用可能となり ネットワーク設備の経済性を向上 ネットワーク仮想化技術の適用前 ネットワーク仮想化技術の適用後 ソフト 専用 ソフト 専用 ソフト ソフト 仮想化レイヤー 仮想化管理システム ( 故障交換用 ) ( 故障交換用 ) 汎用 汎用 汎用 高価な専用 故障交換用に専用 専用毎のメンテナンス 低コストな汎用 自動切替用に共用 統一的なメンテナンス 4

5 メリット 2 通信混雑時のつながりやすさの向上 自動的に通信設備の容量を追加し つながりやすさを向上 ネットワーク仮想化技術の適用前 ネットワーク仮想化技術の適用後 容量追加 輻輳 規制 ソフト ソフトソフト仮想化レイヤー 容量逼迫 追加指示 仮想化管理システム イベント 災害発生 イベント 災害発生 輻輳時には規制を実施 自動で容量追加し つながりやすさを向上 5

6 メリット 3 通信サービスの信頼性向上 故障時に 二重化運転への自動復帰により高い信頼性を実現 ネットワーク仮想化技術の適用前 故障発生 稼働中ソフト ソフト 予備ソフト 稼働中ソフト 切替後 修理完了まで二重化されていない 故障発生 稼働中 ソフト ネットワーク仮想化技術の適用後 予備ソフト 仮想化レイヤー 稼働中ソフト 仮想化レイヤー 予備ソフト 故障 切替指示 仮想化管理システム 二重化運転に自動復帰 仮想化管理システム 自動で二重化運転に復帰する 高い信頼性を実現 6

7 メリット 4 サービスの早期提供 の準備が不要なため 迅速なサービス提供が可能 ネットワーク仮想化技術の適用前 の計画 工事が必要 ネットワーク仮想化技術の適用後 共用を用いて 迅速なサービス提供が可能 サービス準備開始 サービス準備開始 仮想化レイヤー 仮想化管理システム 計画調達工事ソフトインストール 設定 ソフトインストール 設定試験 サービス開始 ソフト 仮想化レイヤー 仮想化管理システム 試験 ソフト サービス開始 7

8 複数ベンダー装置の組合せによるメリットの最大化 ソフトウェアと仮想的なウェアが 異なるベンダーの組み合わせで動作可能とする 単一ベンダー 複数ベンダー組合せ ベンダー A ( 予備 ) ( 予備 ) 仮想化レイヤー 輻輳 仮想化レイヤー ソフト ベンダー A 用に 1 台の予備 ベンダー B 故障 ソフト 仮想化管理システム 仮想化管理システム 輻輳 or 故障 ( 予備 ) 仮想化レイヤー 設備利用の効率化 ベンダー A ベンダー B ソフトソフト 仮想化管理システム ベンダー B 用に 1 台の予備 ベンダー X 新サービス追加 ( 予備 ) 仮想化レイヤー 新サービスソフト 仮想化管理システム 新サービス追加 ベンダー X ソフト ( 新サービス ) ベンダー A ベンダー B ソフト 仮想化レイヤー ソフト 仮想化管理システム 全体を追加する必要あり 8

9 2. 商用化への取り組み 9

10 ドコモの取り組み 2005 年よりネットワーク仮想化の基礎研究を開始 ETSI ISG NFVにてネットワーク仮想化の検討をリード OPNFVにて仮想化プラットフォームの実装を推進 2 度の実証実験を経て 2016 年 3 月にvEPCを商用化 年 11 月 年 4 月 2016 年 3 月 Today ネットワーク仮想化の基礎研究に着手 総務省受託研究 大規模災害時等により発生する通信混雑を緩和する技術研究 3 社との単一ベンダー実証実験 6 社との複数ベンダー組み合わせ実証実験 vepc の商用化 拡大 & 拡張 2012 年 11 月 ~ ETSI ISG NFVで活動 2014 年 9 月 ~ OPNFVで活動 10

11 ETSI ISG NFV のアーキテクチャフレームワーク ウェアとソフトウェアを分離し 異なるベンダーからの提供を可能とするアーキテクチャプラットフォーム : 仮想化技術によりウェアに依存しないソフトウエア実行環境を提供アプリケーション : ソフトウェアのみによるネットワーク機能の実装管理制御 : 全体を管理制御するオーケストレーション機能 OSS/BSS サービス 仮想 NW 機能等の要件記述 Os-Ma Se-Ma オーケストレータ Or-Vnfm 網内全体にわたるインフラとサービスの管理 仮想 NW 機能 (IMS, EPC) EMS 1 仮想 NW 機能 (VNF 1) EMS 2 EMS 3 仮想 NW 機能 (VNF 2) 仮想 NW 機能 (VNF 3) Ve-Vnfm 仮想 NW 機能マネージャ (VNFM) Or-Vi 仮想 NW 機能 ( 通信 APL) のライフサイクル管理 VNF に仮想資源を提供 ( 非依存 ) 実行参照点 NFV 参照点 NFV 対象外 NFVI 仮想計算資源 仮想記憶資源 Vn-Nf 仮想伝送資源 仮想化レイヤ (Hypervisor) Vl-Ha Hardware resources 計算装置記憶装置伝送装置 汎用機器から構成される物理装置 Nf-Vi Vi-Vnfm 仮想インフラマネージャ (VIM) NFV Management and Orchestration DC( 局舎 ) 内の各種インフラ資源の管理 出典 :ETSI GS NFV 002 V

12 NFV 標準アーキテクチャと利用している仮想基盤構成 OSS/BSS サービス 仮想 NW 機能等の要件記述 Os-Ma Se-Ma オーケストレータ Or-Vnfm EMS 1 仮想 NW 機能 (VNF 1) NFVI 仮想計算資源 EMS 2 EMS 3 仮想 NW 機能 (VNF 2) Vn-Nf 仮想 NW 機能 (VNF 3) 計算装置記憶装置伝送装置 Ve-Vnfm 仮想 NW 機能マネージャ (VNFM) Vi-Vnfm 仮想 仮想 記憶資源 伝送資源 Nf-Vi 仮想化レイヤ (Hypervisor) 仮想インフラ Vl-Ha マネージャ Hardware resources (VIM) NFV Management and Orchestration Or-Vi 出典 :ETSI GS NFV 002 V

13 vepc のベンダ構成 異なるベンダーのソフトウェアとウェアを組み合わせてシステムを構築 VIM として OpenStack を採用 システムインテグレーションはドコモが実施 マルチベンダ構成 複数ベンダのアプリケーション NEC FUJITSU vepc vepc Hypervisor HW HW SDN NW NFVO VNFM VNFM VIM ERICSSON CISCO NFV test bed in DOCOMO 13

14 対象とするキャリア向けの VNF 14

15 VNF と一般的なアプリケーションとの違い リアルタイム処理指向 モバイル網の規定する遅延時間未満での処理 低い処理遅延と低いジッタ 高いネットワーク I/O パケット処理性能が必要 Gbps 級 sub M PPS 級の性能 1KB 以下パケットサイズ時の高い性能 VNF の レベルで HA Failover 機能が動作 L2/L3 レベルでの HA 機能あり VNF: Virtual Network Function : Virtual Network Function Component 15

16 10Gbps ってどのくらい大変なの? # of packets per seconds 16,000,000 14,000,000 12,000,000 10,000,000 8,000,000 6,000,000 4,000,000 2,000,000 Short packet 64Byte MPPS, 67.2 ns 2Ghz: 134 clocks 3Ghz: 201 clocks Computer packet 1KByte 1.2MPPS, 835 ns 2Ghz: 1670 clocks 3Ghz: 2505 clocks Packet size (Byte) 16

17 テレコム向け VNF の特徴 (1/5) 1 function = 1 = 1 1 function = 3-10 s = s VNF VNF 17

18 テレコム向け VNF の特徴 (2/5) ~1000 VNF VNF VNF VNF VNF VNF NFVI Compute server Compute server Compute server Compute server Compute server Compute server Compute server Compute server Compute server 台 18

19 テレコム向け VNF の特徴 (3/5) 構成がシンプル 3v 程度 通信用途ごとの QOS 要件やセキュリティ要件のため v 数が多い App App OS OS v v backend v v v v v v management frontend C-plane (internal) C-plane (external1) C-plane (external2) U-plane (internal) U-plane (external) 19

20 テレコム向け VNF の特徴 (4/5) VNF VNF の更新 VNF VNF VNFM 100 への同時操作 NFVI Compute server Compute server Compute server Compute server Compute server Compute server VIM 20

21 テレコム向け VNF の特徴 (5/5) 大量の 全部が正常に Instantiation 完了する必要性 VNF VNFM NFVI Compute server Compute server Compute server Compute server Compute server Compute server VIM 21

22 NFV 向けの仮想化環境として求められる機能 要件 OpenStack の機能 ( 期待を含む ) 運用の工夫 オーバヘッドの無い環境 性能劣化を防ぐ資源配置 - CPU 占有 - NUMA-aware 割り当て - 資源の Over commit を防止 - NUMA を意識した資源割り当て - CPU - Memory - リアルタイム処理にむけた環境を提供 資源の Over commit を防止 CPU pinning Memory の確保 高性能な Network I/O を提供 - DPDK 対応 OVS - SR-IOV サーバベンダ差分を吸収 - K/HV - NWの命名規則による工夫 - Fencing 保守作業の部分自動化 - ヒーリング機能 - Fencing 高い同時制御命令実行 - OpenStack のスケーラビリティ - Nova - Cinder 22

23 VNF の高い性能要件を満たすために 仮想 CPU はオーバコミットしない ( 専用割り当て ) 仮想メモリーはオーバコミットしない ( 専用割当て ) 単一 Numa ノードで配置 ( 同一スロットル上に配置 ) RAM RAM RAM RAM RAM RAM RAM RAM RAM RAM RAM RAM RAM RAM RAM RAM CPU Socket#0 HostOS CPU Socket#1 vsw SRIOV SRIOV OVS-DPDK を活用 SR-IOV を利用 23

24 SR-IOV の活用 24

25 SR-IOV と vsw の使いどころ SR-IOV (Intel 82599) OVS DPDK 帯域性能 1-10 Gbps 1 1 Gbps PPS 性能 8 MPPS < 1 MPPS 遅延 HW と同等 HW より大きい Jitter HW と同等 HW より大きい VLAN 数 64 2K v の制限 最大 64 VF 1 unicast MAC/VF 64 vlan/vf 最大 30 multicast MAC 最大 100 v v の増加に伴い性能劣化 NW アプリの挙動観点で制限が多い 25

26 SR-IOV の中身 OS VF driver OS VF driver HW と比較し制限あり VLAN 数 /VF 1 Unicast MAC addr/vf 単なる L2 SW ではない Source MAC filter Multicast MAC filter PCI Pass-through VF0 VF1 PF BUF BUF BUF Embedded L2 SW Intel

27 実際は VNF ベンダ Guest OS VF driver 互換性の欠如 基盤ベンダ Host OS PF driver パケット転 SR-IOV ドライババージョン相性 VNF ベンダの提供する VF driver と基盤ベンダの提供する PF driver のバージョン相性問題 特定パケットがドロップ Neutron で Port security = off Host で ip vf trusted on 送 SR-IOVでのパケットロス 切り分け 解析が非常に困難 VF 切れば切るほどBufferが削減 27 SR-IOV は高スループットを必要とる にとっては現実解であるが インテグレーションの複雑さの増大 問題解析の困難さ増大 将来的に OVS の高速化や Hardware acceleration の活用も?

28 HW 差分を隠蔽した上でサーバ内部構成を意識 28

29 SR-IOV 利用時の NFVO, VNFM,VIM の流れ NFVO Create Network Network#A Physnet1 Create Port Port#A Network#A VNFM Create #A Port#A VIM (OpenStack) #A CPU Socket#0 #0 Physnet1 host CPU Socket#1 #1 IA Server Assign Logical Name for Physical #0 = Physnet1 NFVO VNFM が指定した Network Port 情報は間接的に特定の CPU Socket を活用するのと同義 29

30 SR-IOV のための IA サーバのバス構造によるホスト設計差分 CPU Socketごとの差分削減のためCPU Socket 毎に直結したを搭載 IAサーバは機種やCPUの違いにより以下のように内部バス構造が異なる IA サーバ ( 機種 #A) RAM RAM RAM RAM RAM RAM RAM RAM CPU Socket#0 CPU Socket#1 IA サーバ ( 機種 #B) RAM RAM RAM RAM RAM RAM RAM RAM CPU Socket#0 CPU Socket#1 30

31 DPDK OVS のための IA サーバのバス構造によるホスト設計差分 DPDK OVSの性能ために CPU Socketとを考慮しプロセスを固定 機種差分によって固定配備するCPU Socketが異なる IA サーバ ( 機種 #A) RAM RAM RAM RAM RAM RAM RAM RAM CPU Socket#0 HostOS vsw CPU Socket#1 IA サーバ ( 機種 #B) RAM RAM RAM RAM RAM RAM RAM RAM HostOS vsw CPU Socket#0 CPU Socket#1 31

32 OpenStack 活用 +SR-IOV, ホスト設計差分による課題 NFVO,VNFM においてマルチソケットを考慮した 生成を制御する必要 機種毎の設計差分が存在し,Socket# 指定では差分を吸収できない 課題 1 大規模 の作成失敗 VNFM 作成要求 (socket#0) VIM 課題 2 収容効率の向上 or 作成失敗 VNFM 作成 4 (socket#0) 作成 2 (socket#1) VIM IA サーバ ( 機種 #A): 成功 IA サーバ ( 機種 #A):6 CPU Socket#0 CPU Socket#1 CPU Socket#0 CPU Socket#1 Host Host IA サーバ ( 機種 #B): 失敗 IA サーバ ( 機種 #B):4(2 失敗 ) Host CPU Socket#0 CPU Socket#1 Host CPU Socket#0 CPU Socket#1 32

33 論理識別子の命名方法の工夫による解決 NFVO VNFM 2Create Network for SR-IOV Create network Large physnet1 Create network Small physnet2 3Create Port Create port aaa Large Create port bbb Small 4Create Create server #A port aaa, bbb Create server #B port ccc, ddd VIM 2 論理デバイスによる識別方法を仮想 Network 名にも透過適用し 抽象的なSocket 指定 Large: 空リソース大 Small: 空リソース小 #A CPU Socket#0 #0 #B host CPU Socket#1 #1 Physnet1 Physnet2 1Assign Logical Name for Physical #0 = Physnet1/#1 = Physnet2 IA Server 機種 A #B host CPU Socket#0 #0 #A CPU Socket#1 #1 Physnet2 Physnet1 1Assign Logical Name for Physical #0 = Physnet2/#1 = Physnet1 5Deploy IA Server 機種 B 1 機種に依らず同じ空リソースのSocketを識別 Physnet1: 空リソース大 Physnet2: 空リソース小 33

34 識別の工夫による結果 VIM によって機種差分は隠ぺいされ 且つ VNFM は仮想ネットワーク名を CPU 空リソースの識別子として扱うことが可能 課題 1 大規模 の作成失敗 課題 2 収容効率の向上 or 作成失敗 VNFM 作成要求 ( 空リソース : 大 ) VIM VNFM 作成 4 ( 空リソース : 大 ) 作成 2 ( 空リソース : 小 ) VIM IA サーバ ( 機種 #A): 成功 IA サーバ ( 機種 #A):6 CPU Socket#0 CPU Socket#1 CPU Socket#0 CPU Socket#1 Host Host IA サーバ ( 機種 #B): 成功 IA サーバ ( 機種 #B):6 Host CPU Socket#0 CPU Socket#1 Host CPU Socket#0 CPU Socket#1 34

35 ヒーリング 35

36 ヒーリングとは () 障害や HW 障害時に正常な HW 上に を再生成し障害から復旧させる機能 オートヒーリング : 仮想化基盤が障害状況に応じて自動的に実施 マニュアルヒーリング : 障害監視等を通じて人手によって実施 HW 故障の自動復旧により駆けつけ稼働 (OPEX) の削減が可能 1 オートヒーリング (VNFM 起動 ) 2 オートヒーリング (VIM 起動 ) 3 マニュアルヒーリング ヒーリング判断 OSS NFVO OSS NFVO OSS NFVO ヒーリング 故障 IA Server IA Server VNFM VIM IA Server 故障 IA Server VNFM ヒーリング判断 VIM 故障 故障 IA Server IA Server VNFM VIM 36 36

37 オートヒーリングの動作 OSS ヒーリング NFVO サーバ異常を検出 VNFM へ通知 サーバベンダ毎に故障情報ポリシーが異なる 1 障害検知可能な故障部位 2 故障レベル 3 故障検出方法 故障 IA Server VNFM VNFM は障害情報からヒーリング要否を判断 IA Server VIM 別 Server に を配置 障害情報を Nova scheduler を考慮せず 故障ノードに再配置 リブートする HW に再配置 を起動通信ソフトを復旧 37

38 キャリアネットワーク観点からの解決法 OSS NFVO STEP1:HW 監視装置は NFVI Server 障害を検出し, 障害情報の正規化を実施 2 HW 監視装置 1 故障 IA Server 3 VNFM VIM STEP2:HW 監視装置は正規化した障害情報を VIM に送信 STEP3:VIM は正規化された障害情報を元にヒーリング実施判断し, NFVI Server の IPMI を使い NFVI Server の停止 (Fencing 機能 ) STEP4:VIM/VNFM は NFVI Server の停止を検出し他の NFVI Server に を起動する 38

39 ウエア差分をなくすための障害情報の統一化 仮想化基盤システム内で用いる障害情報は統一的な表現とする 障害レベルの定義と構成品を定義 異なる汎用 IAサーバの障害情報を定義した障害情報にマッピングし正規化 障害情報のマッピング処理は一元的に実施する必要がある為,HW 監視装置での実施 正規化はテンプレートを用いる事で汎用 IAサーバの追加毎に機能追加なく実現可能 HW 監視装置 致命的な障害重度の障害軽度の障害警告情報 オペレータのポリシーを元に定義 CPU MEM DISK PSU FAN Temp CPU MEM DISK PSU FAN Temp CPU MEM DISK PSU FAN Temp CPU MEM DISK PSU FAN Temp Fault ID Fault severity 1011 CPU 警告 1012 CPU 軽度の障害 1013 CPU 重度の障害 障害情報をマッピング NFVI( ベンダ :A) テンプレート NFVI( ベンダ :B) テンプレート 障害情報 障害情報 NFVI( ベンダ :A) NFVI( ベンダ :B) 39

40 OPNFV Doctor 故障を即座に検知し切替指示を行う機能を開発 当初の Scope は開発完了 故障発生 稼働中ソフト 予備ソフト仮想化レイヤー 仮想化管理システム 稼働中 予備 ソフト仮想化レイヤー ソフト 切替指示 仮想化管理システム 故障 ウェア等の故障情報をリアルタイム把握し の SLA を踏まえて切替指示を実施 40

41 OPNFV Doctor 機能 モバイルコアノードの故障対応機能を新たに開発した PJ メンバ :NEC, Nokia, Ericsson, NTT SIC, DOCOMO 他 OpenStack にて開発した新機能 : 1: 故障通知 ( ホスト名 ) 2: 故障通知 ( ホスト名 ) -NOVA にて ホスト利用不可能 と状態変更 3: 状態変更 4:VNFM へ故障通知 VNF (ACT) VNFM VNF (SBY) NOVA 4 3 AODH 開発のスコープ ハイパーバイザ ウェアサーバ ( ホスト ) NFVI( クラウド基盤 ) 3 rd Party NFVI モニタ 2 1 Inspector (Congress/ Vitrage) オヘ レータによる故障項目の動的な定義 オープンソースソフトウェアとして開発することで低コスト化の実現 OpenStack で 1 秒以下で故障対応可 41

42 Doctor 開発機能一覧 OpenStack に 7 つの新機能を開発した OpenStack function NFVI ( クラウドインフラ ) Nova Controller Controller Controller Monitor Monitor Monitor 4. Notify all Resource Map 3 3. Update State 2. Find Affected 1. Raw Fault Title Status Owner Lead Developer Description Link Event Alarm Evaluator New nova API call to mark nova-compute down Support forcing service down Get valid server state Add Notification for service status change Push Type Data Source Driver Doctor Data Source Driver Code merged in Liberty Code merged in Liberty Code merged in Liberty Code merged in Mitaka Code merged in Mitaka Code merged in Mitaka Code merged in Newton Ryota (NEC) Ceilometer: Ryota (NEC) Implementation of new alarm evaluator to immediately notify consumers of fault events Tomi (NOKIA) Nova: Roman (Intel) API to set compute nodes to down / up Tomi (NOKIA) Nova client: Carlos (NEC) Client-side implementation of above Tomi (NOKIA) Balazs (Ericsson) Masahito (NTT) Masahito (NTT) プロジェクト名 OPNFV Doctor Nova: Tomi (NOKIA) Nova: Balazs (Ericsson) Congress: Masahito (NTT) Congress: Masahito (NTT) 2 To get host status information when consumer queries for instance detailed information Notification of maintenance actions on e.g. compute nodes to consumers This feature enables Congress to receive data from another service. Push Type Data Source Driver adaptation for Doctor Consumer (VNFM, NFVO) 5. Notify Error 0. Set Alarm Notifier Ceilometer+Aodh 6 7 Inspector Congress Alarm Conf. 4. (alt) Notify Failure Policy ec/event-alarm-evaluator ark-host-down t-valid-server-state rvice-status-notification c/push-type-datasource-driver 42

43 今後 43

44 コアネットワークの進化 [2016 年 3 月 9 日 ] vepc の商用導入 [2016 年度以降 ] ネットワーク仮想化の適用拡大とウェア利用の効率化 [2020 年度以降 ] 5G 時代の新たなビジネスを実現するネットワークへの発展 現在 2017 年度以降 2020 年度以降 既存 IMS vepc の導入 適用対象拡大ウェア利用効率化 ビジネス領域の拡大 4K HSS P-CSCF TAS S-CSCF SGW PGW MME NFV 導入 - スケールアウト / ヒーリング HSS MME TAS PCRF P-CSCF クラウドネイティブアプリ SGW S-CSCF NFV 拡張 - 自動化の拡大 - 局舎間リソース共有 PGW NFV 進化 - サーヒ ス最適化ネットワーク MME PCRF 市販 IA サーバ (COTS) SGW PGW 既存 EPC SDN( 局舎内 ) SDN( 局舎間 ) SDN( マルチレイヤ連携 ) 44

45 Reference (1/2) OpenStack Low-Latency-NFV-With-Openstack.pdf DPDK V_Container_final.pdf Steve%20Liang-DPDKUSASummit2016.pdf mark_test_report_v1.0.pdf 45

46 Reference (2/2) SR-IOV xcon_sriov_final.pdf rep1&type=pdf 46