Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月

3,544 views

Published on

タイトル:OpenStackを利用したNFVの商用化
講演者:中島 佳宏(NTTドコモ)
アジェンダ:
- ネットワーク仮想化への取り組み
- 商用化への取り組み
--- 対象とするキャリア向けVNF
--- SR-IOVの活用
--- HW差分を隠蔽した上でサーバ内部構成を意識
--- ヒーリング
- 今後

Published in: Technology

OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月

  1. 1. © 2017 NTT DOCOMO, INC. All Rights Reserved. OpenStackを利用したNFVの商用化 2017年7月26日 NTTドコモ ネットワーク開発部 中島 佳宏
  2. 2. © 2017 NTT DOCOMO, INC. All Rights Reserved. 自己紹介 •中島佳宏 – 経歴 •2003年 - 2008年 筑波大学大学院 コンピュータサイエンス専攻 – HPC・分散システムの研究 •2008年 – 2017年 NTT 未来ねっと研究所 – 2008年-2011年 HD映像のIP伝送装置・ネットワークトラヒック測定装置開発 – 2011年-2012年 SDN制御 – 2012年-2017年 高速なソフトウエアスイッチ開発 (Lagopus vswitch) http://www.lagopus.org/ •2017年 - NTTドコモネットワーク開発部 – NFV向け仮想化基盤 (ミドルウエア・HW)担当 – 専門 •高速な○○処理・仮想化技術・システムソフトウエア – 2012年 DPDK Version 1.1から 2
  3. 3. © 2017 NTT DOCOMO, INC. All Rights Reserved. ネットワーク仮想化への取り組み 3
  4. 4. © 2017 NTT DOCOMO, INC. All Rights Reserved. メリット① 通信混雑時のつながりやすさの向上 (オートスケーリング) メリット② 通信サービスの信頼性向上 (オートヒーリング) メリット③ サービスの早期提供 (システム個別HWの構築が不要) メリット④ ネットワーク設備の経済性向上 (COTS、共用化) 上記メリット最大化のためには 複数ベンダー装置の組み合わせが必要 ネットワーク仮想化のメリット 4
  5. 5. © 2017 NTT DOCOMO, INC. All Rights Reserved. 専用ハード ソフト 仮想化レイヤー 仮想化管理 システム ・低コストな汎用ハード ・自動切替用に共用ハード ・統一的なメンテナンス 専用ハード ソフト 汎用ハード汎用ハード ソフト ソフト ハード (故障交換用) ハード (故障交換用) ・ 汎用ハードが共用可能となり、ネットワーク設備の経済性を向上 ネットワーク仮想化技術の適用後 ・高価な専用ハード ・故障交換用に専用ハード ・専用ハード毎のメンテナンス 汎用ハード ネットワーク仮想化技術の適用前 メリット① ネットワーク設備の経済性向上 5
  6. 6. © 2017 NTT DOCOMO, INC. All Rights Reserved. ・ 自動的に通信設備の容量を追加し、つながりやすさを向上 イベント・ 災害発生 イベント・ 災害発生 容量 逼迫 容量追加 ハード ソフト 仮想化レイヤー ハード ソフト ソフト ハード 仮想化 管理 システム 追加 指示 輻輳時には規制を実施 自動で容量追加し、つながりやすさを向上 ネットワーク仮想化技術の適用後ネットワーク仮想化技術の適用前 輻輳⇒規制 メリット② 通信混雑時のつながりやすさの向上 6
  7. 7. © 2017 NTT DOCOMO, INC. All Rights Reserved. メリット③ 通信サービスの信頼性向上 ・ ハード故障時に、二重化運転への自動復帰により高い信頼性を実現 稼働中 予備 切替後、修理完了まで 二重化されていない ハード ソフト ハード ソフト 故障 発生 仮想化レイヤー ハード ソフト ソフト ハード 仮想化管理 システム ハード 稼働中 予備 仮想化レイヤー ハード ソフト ハード 仮想化管理 システム ハード 稼働中 故障 発生 故障 切替 指示 ソフト 予備 二重化運転に自動復帰 自動で二重化運転に復帰する → 高い信頼性を実現 ネットワーク仮想化技術の適用後ネットワーク仮想化技術の適用前 ソフト 稼働中 ハード ハード ソフト 7
  8. 8. © 2017 NTT DOCOMO, INC. All Rights Reserved. メリット④ サービスの早期提供 ・ ハードの準備が不要なため、迅速なサービス提供が可能 サービス開始 ハード計画 サービス準備開始 ハード調達 ハード工事 ソフトインストール・設定 試験 サービス開始 ソフトインストール・設定 試験 仮想化レイヤー ハード 仮想化管理 システム ネットワーク仮想化技術の適用後 ハード ハード ソフト ハード ソフト 仮想化管理 システム 仮想化レイヤー ハード サービス準備開始 ハードの計画・工事が必要 共用ハードを用いて、 迅速なサービス提供が可能 ネットワーク仮想化技術の適用前 8
  9. 9. © 2017 NTT DOCOMO, INC. All Rights Reserved. 複数ベンダー装置の組合せによるメリットの最大化 仮想化レイヤー 複数ベンダー組合せ単一ベンダー ・ ソフトウェアと仮想的なハードウェアが、異なるベンダーの組み合わせで動作可能とする 仮想化レイヤー 仮想化 管理 システムハード ハード (予備) ソフト 新サービス ハード (予備) 仮想化レイヤー 仮想化 管理 システム ソフト ハード ハード (予備) 仮想化レイヤー 仮想化 管理 システム ソフト ベンダーA ハード輻輳 ベンダーB ベンダーX 仮想化レイヤー 仮想化 管理 システム ハードハード ソフトソフト輻輳or故障 ハード (予備) 設備利用の効率化 ベンダーA ベンダーB ベンダーB用に1台の予備ハード 仮想化 管理 システム ハードハード ソフトソフト ベンダーA ベンダーB 全体を追加する必要あり ベンダーA用に1台の予備ハード ベンダーX ソフト (新サービス) ハード 新サービス追加 新サービス追加 故障 9
  10. 10. © 2017 NTT DOCOMO, INC. All Rights Reserved. 2.商用化への取り組み 10
  11. 11. © 2017 NTT DOCOMO, INC. All Rights Reserved. ネットワーク 仮想化 の基礎研究に着手 2005 - 総務省受託 研究 ※大規模災害時等 により発生する通信 混雑を緩和する技術 研究 2012 -2013 3社との 単一ベンダー 実証実験 2013年11月- 6社との 複数ベンダー 組み合わせ 実証実験 2014年4月― 2012年11月~ ETSI ISG NFVで活動 2014年9月~ OPNFVで活動 ドコモの取り組み •2005年よりネットワーク仮想化の基礎研究を開始 •ETSI ISG NFVにてネットワーク仮想化の検討をリード、 OPNFVにて仮想化プラットフォームの実装を推進 •2度の実証実験を経て、2016年3月にvEPCを商用化 2016年3月 Today vEPCの商用化 拡大&拡張 11
  12. 12. © 2017 NTT DOCOMO, INC. All Rights Reserved. ETSI ISG NFVのアーキテクチャフレームワーク ハードウェアとソフトウェアを分離し、異なるベンダーからの提供を可能とするアーキテクチャ プラットフォーム: 仮想化技術によりハードウェアに依存しないソフトウエア実行環境を提供 アプリケーション: ソフトウェアのみによるネットワーク機能の実装 管理制御: 全体を管理制御するオーケストレーション機能 出典:ETSI GS NFV 002 V1.1.1 実行参照点 NFV参照点 NFV対象外 網内全体にわたるインフラと サービスの管理 DC(局舎)内の各種インフラ資源 の管理 NFV Management and Orchestration 計算装置 記憶装置 伝送装置 Hardware resources 仮想化レイヤ (Hypervisor) 仮想インフラ マネージャ (VIM) 仮想NW機能マ ネージャ (VNFM) 仮想NW機能 (VNF 2) オーケストレータOSS/BSS NFVI 仮想NW機能(VNF 3) 仮想NW機能 (VNF 1) 仮想 計算資源 仮想 記憶資源 仮想 伝送資源 EMS 2 EMS 3EMS 1 サービス、仮想NW機能等の 要件記述 Or-Vi Or-Vnfm Vi-Vnfm Os-Ma Se-Ma Ve-Vnfm Nf-Vi Vn-Nf Vl-Ha 仮想NW機能 (IMS, EPC) 汎用機器から構成される物理装置 仮想NW機能(通信APL) のライフサイクル管理 VNFに仮想資源を提供 (ハード非依存) 12
  13. 13. © 2017 NTT DOCOMO, INC. All Rights Reserved. NFV標準アーキテクチャと利用している仮想基盤構成 出典:ETSI GS NFV 002 V1.1.1 NFV Management and Orchestration 計算装置 記憶装置 伝送装置 Hardware resources 仮想化レイヤ (Hypervisor) 仮想インフラ マネージャ (VIM) 仮想NW機能マ ネージャ (VNFM) 仮想NW機能 (VNF 2) オーケスト レータ OSS/BSS NFVI 仮想NW機能 (VNF 3) 仮想NW機能 (VNF 1) 仮想 計算資源 仮想 記憶資源 仮想 伝送資源 EMS 2 EMS 3EMS 1 サービス、仮想NW機能等の 要件記述 Or-Vi Or-Vnfm Vi-Vnfm Os-Ma Se-Ma Ve-Vnfm Nf-Vi Vn-Nf Vl-Ha 13
  14. 14. © 2017 NTT DOCOMO, INC. All Rights Reserved. vEPCのベンダ構成 • 異なるベンダーのソフトウェアとハードウェアを組み合わせてシステムを構築 • VIMとしてOpenStackを採用 • システムインテグレーションはドコモが実施 NFV test bed in DOCOMO Hypervisor HW vEPC HW VIM vEPC SDN NW マルチベンダ構成 複数ベンダのアプリケーション FUJITSUNEC ERICSSON CISCO VNFMVNFM NFVO 14
  15. 15. © 2017 NTT DOCOMO, INC. All Rights Reserved. 対象とするキャリア向けのVNF 15
  16. 16. © 2017 NTT DOCOMO, INC. All Rights Reserved. VNFと一般的なアプリケーションとの違い •リアルタイム処理指向 – モバイル網の規定する遅延時間未満での処理 – 低い処理遅延と低いジッタ •高いネットワークI/O・パケット処理性能が必要 – Gbps級・sub M PPS級の性能 – 1KB以下パケットサイズ時の高い性能 •VNFのVNFcレベルでHA・Failover機能が動作 – L2/L3レベルでのHA機能あり 16 VNF: Virtual Network Function VNFc: Virtual Network Function Component
  17. 17. © 2017 NTT DOCOMO, INC. All Rights Reserved. 0 2,000,000 4,000,000 6,000,000 8,000,000 10,000,000 12,000,000 14,000,000 16,000,000 0 256 512 768 1024 1280 #ofpacketsperseconds Packet size (Byte) Short packet 64Byte 14.88 MPPS, 67.2 ns • 2Ghz: 134 clocks • 3Ghz: 201 clocks Computer packet 1KByte 1.2MPPS, 835 ns • 2Ghz: 1670 clocks • 3Ghz: 2505 clocks 10Gbpsってどのくらい大変なの? 17
  18. 18. © 2017 NTT DOCOMO, INC. All Rights Reserved. テレコム向けVNFの特徴 (1/5) VNF 1 function = 1 VNFc = 1 VM VM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM 1 function = 3 - 10 VNFcs = 10 – 50 VMs 18
  19. 19. © 2017 NTT DOCOMO, INC. All Rights Reserved. テレコム向けVNFの特徴 (2/5) NFVI Compute server Compute server Compute server Compute server Compute server Compute server Compute server Compute server Compute server 100-500台 ~1000 VM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM 19
  20. 20. © 2017 NTT DOCOMO, INC. All Rights Reserved. テレコム向けVNFの特徴 (3/5) VM App vNIC OS vNIC backend frontend VM App vNIC OS vNIC vNIC vNIC vNIC vNIC management C-plane (internal) C-plane (external2) C-plane (external1) U-plane (internal) U-plane (external) 通信用途ごとのQOS要件や セキュリティ要件のためvNIC数が多い 構成がシンプル 3vNIC程度 20
  21. 21. © 2017 NTT DOCOMO, INC. All Rights Reserved. テレコム向けVNFの特徴 (4/5) NFVI Compute server Compute server Compute server Compute server Compute server Compute server VIM VNFM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFの更新 100VMへの 同時操作 21
  22. 22. © 2017 NTT DOCOMO, INC. All Rights Reserved. テレコム向けVNFの特徴 (5/5) NFVI Compute server Compute server Compute server Compute server Compute server Compute server VNF VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VNFc VM VIM VNFM 大量のVM全部が 正常にInstantiation完了する必要性 22
  23. 23. © 2017 NTT DOCOMO, INC. All Rights Reserved. NFV向けの仮想化環境として求められる機能 要件 OpenStackの機能(期待を含む) 運用の工夫 オーバヘッドの無い環境 - CPU 占有 - NUMA-aware割り当て - 資源のOver commitを防止 性能劣化を防ぐ資源配置 - NUMAを意識した資源割り当て - CPU - Memory - NIC リアルタイム処理にむけた環境を提供 • 資源のOver commitを防止 • CPU pinning • Memoryの確保 高性能なNetwork I/Oを提供 - DPDK対応OVS - SR-IOV サーバベンダ差分を吸収 - KVM/HV - NWの命名規則による工夫 - Fencing 保守作業の部分自動化 - ヒーリング機能 - Fencing 高い同時制御命令実行 - OpenStackのスケーラビリティ - Nova - Cinder 23
  24. 24. © 2017 NTT DOCOMO, INC. All Rights Reserved. VNFの高い性能要件を満たすために 24 CPU Socket#0 NICNICNIC RAM RAM RAM RAM RAM RAM RAM RAM CPU Socket#1 RAM RAM RAM RAM RAM RAM RAM RAM NIC VM VM VM VM HostOS vSW SRIOV SRIOV 仮想CPUはオーバコミット しない(専用割り当て) 仮想メモリーはオーバコ ミットしない (専用割当て) 単一Numaノードで配置 (同一スロットル上に配置) SR-IOVを利用 OVS-DPDKを活用
  25. 25. © 2017 NTT DOCOMO, INC. All Rights Reserved. SR-IOVの活用 25
  26. 26. © 2017 NTT DOCOMO, INC. All Rights Reserved. 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 vNICの制限 最大64 VF 1 unicast MAC/VF 64 vlan/VF 最大30 multicast MAC 最大100 vNIC vNICの増加に伴い 性能劣化 NWアプリの挙動観点で 制限が多い  26
  27. 27. © 2017 NTT DOCOMO, INC. All Rights Reserved. SR-IOVの中身 Intel 82599 VM OS VF driver NIC PCI Pass-through VF0 PFVF1 Embedded L2 SW BUF BUF BUF VM OS VF driver NIC 単なるL2 SWではない • Source MAC filter • Multicast MAC filter HWと比較し制限あり VLAN数/VF 1 Unicast MAC addr/VF 27
  28. 28. © 2017 NTT DOCOMO, INC. All Rights Reserved. 実際は・・・・ › SR-IOVドライババージョン相性 – VNFベンダの提供するVF driverと基盤ベンダの 提供するPF driverのバージョン相性問題 – 特定パケットがドロップ › NeutronでPort security = off › Hostでip vf trusted on › SR-IOVでのパケットロス – 切り分け、解析が非常に困難 – VF切れば切るほどBufferが削減 Guest OS Host OS PF driver VF driver NIC 互換性の欠如 • SR-IOVは高スループットを必要とるVMにとっては現実解であるが、 インテグレーションの複雑さの増大・問題解析の困難さ増大 • 将来的にOVSの高速化やHardware accelerationの活用も? VNFベンダ 基盤ベンダ パ ケ ッ ト 転 送 28
  29. 29. © 2017 NTT DOCOMO, INC. All Rights Reserved. HW差分を隠蔽した上でサーバ内部構成を意識 29
  30. 30. © 2017 NTT DOCOMO, INC. All Rights Reserved. SR-IOV利用時のNFVO, VNFM,VIMの流れ •NFVO、VNFMが指定したNetwork・Port情報は間接的に特定のCPU Socketを活用するのと同義 VIM (OpenStack) NFVO Create Network Network#A Physnet1 Create Port Port#A Network#A VNFM Create VM VM#A Port#A IA Server CPU Socket#0 CPU Socket#1 NIC#1NIC#0 host VM#A Physnet1 Assign Logical Name for Physical NIC NIC#0 = Physnet1 30
  31. 31. © 2017 NTT DOCOMO, INC. All Rights Reserved. SR-IOVのためのIAサーバのバス構造によるホスト設計差分 •CPU Socketごとの差分削減のためCPU Socket毎に直結したNICを搭載 •IAサーバは機種やCPUの違いにより以下のように内部バス構造が異なる CPU Socket#0 NICNICNIC RAM RAM RAM RAM CPU Socket#1 RAM RAM RAM RAM NIC IAサーバ(機種#A) CPU Socket#0 NICNICNIC RAM RAM RAM RAM CPU Socket#1 RAM RAM RAM RAM NIC IAサーバ(機種#B) 31
  32. 32. © 2017 NTT DOCOMO, INC. All Rights Reserved. DPDK OVSのためのIAサーバのバス構造によるホスト設計差分 •DPDK OVSの性能ために、CPU SocketとNICを考慮しプロセスを固定 •機種差分によって固定配備するCPU Socketが異なる CPU Socket#0 NICNICNIC RAM RAM RAM RAM CPU Socket#1 RAM RAM RAM RAM NIC IAサーバ(機種#A) CPU Socket#0 NICNICNIC RAM RAM RAM RAM CPU Socket#1 RAM RAM RAM RAM NIC IAサーバ(機種#B) HostOS vSW HostOS vSW 32
  33. 33. © 2017 NTT DOCOMO, INC. All Rights Reserved. OpenStack活用+SR-IOV,ホスト設計差分による課題 •NFVO,VNFMにおいてマルチソケットを考慮したVM生成を制御する必要 •機種毎の設計差分が存在し,Socket#指定では差分を吸収できない 課題① 大規模VMの作成失敗 CPU Socket#0 CPU Socket#1 Host VM 課題② 収容効率の向上 or VM作成失敗 VM VM VM CPU Socket#1CPU Socket#0 Host VM VNFM VIMVM作成要求 (socket#0) IAサーバ(機種#A):成功 IAサーバ(機種#B):失敗 CPU Socket#0 CPU Socket#1 Host CPU Socket#1CPU Socket#0 Host IAサーバ(機種#A):6VM IAサーバ(機種#B):4VM(2VM失敗) VM VM VM VM VM VM VMVM VM VM VM VNFM VIM VM作成×4 (socket#0) VM作成×2 (socket#1) 33
  34. 34. © 2017 NTT DOCOMO, INC. All Rights Reserved. 論理識別子の命名方法の工夫による解決 VIM NFVO ②Create Network for SR-IOV Create network Large – physnet1 Create network Small – physnet2 ③Create Port Create port aaa – Large Create port bbb – Small VNFM ④Create VM Create server VM#A –port aaa, bbb Create server VM#B –port ccc, ddd ⑤Deploy VM IA Server 機種A CPU Socket#0 CPU Socket#1 NIC#1NIC#0 host VM#A Physnet1 Physnet2 ①Assign Logical Name for Physical NIC NIC#0 = Physnet1/NIC#1 = Physnet2 VM#B IA Server 機種B CPU Socket#0 CPU Socket#1 NIC#1NIC#0 host Physnet2 ①Assign Logical Name for Physical NIC NIC#0 = Physnet2/NIC#1 = Physnet1 Physnet1 VM#AVM#B ①機種に依らず同じ空リ ソースのSocketを識別 • Physnet1:空リソース大 • Physnet2:空リソース小 ②論理デバイスによる識別方法 を仮想Network名にも透過適用 し、抽象的なSocket指定 • Large:空リソース大 • Small:空リソース小 34
  35. 35. © 2017 NTT DOCOMO, INC. All Rights Reserved. 識別の工夫による結果 •VIMによって機種差分は隠ぺいされ、且つVNFMは仮想ネットワーク名を CPU空リソースの識別子として扱うことが可能 課題① 大規模VMの作成失敗 CPU Socket#0 CPU Socket#1 Host VM 課題② 収容効率の向上 or VM作成失敗 VM CPU Socket#1CPU Socket#0 Host VNFM VIMVM作成要求 (空リソース:大) IAサーバ(機種#A):成功 IAサーバ(機種#B):成功 CPU Socket#0 CPU Socket#1 Host CPU Socket#1CPU Socket#0 Host IAサーバ(機種#A):6VM IAサーバ(機種#B):6VM VM VM VM VM VM VM VM VM VM VNFM VIM VM作成×4 (空リソース:大) VM作成×2 (空リソース:小) VM VM VM 35
  36. 36. © 2017 NTT DOCOMO, INC. All Rights Reserved. ヒーリング 36
  37. 37. © 2017 NTT DOCOMO, INC. All Rights Reserved. ①オートヒーリング (VNFM起動) ②オートヒーリング (VIM起動) ③マニュアルヒーリング IA Server VNFc IA Server VNFc OSS VIM VNFM NFVO IA Server VNFc VNFc IA Server VNFc OSS VIM VNFM NFVO VNFc VNFc 故障 VNFc 故障 ヒーリング ヒーリング 判断 IA Server VNFc VNFc IA Server VNFc OSS VIM VNFM NFVO 故障 ヒーリング 判断 故障 37 ヒーリングとは •VNFc(VM)障害やHW障害時に正常なHW上にVMを再生成し障害から復旧させる機能 – オートヒーリング: 仮想化基盤が障害状況に応じて自動的に実施 – マニュアルヒーリング: 障害監視等を通じて人手によって実施 •HW故障の自動復旧により駆けつけ稼働(OPEX)の削減が可能 37
  38. 38. © 2017 NTT DOCOMO, INC. All Rights Reserved. オートヒーリングの動作 38 サーバ異常を検出 VNFMへ通知 別ServerにVMを配置 IA Server VNFc IA Server VNFc OSS VIM VNFM NFVO VNFc VNFc 故障 ヒーリング VNFMは障害情報から ヒーリング要否を判断 VMを起動通信ソフトを復旧 サーバベンダ毎に故障情報ポリシーが異なる ①障害検知可能な故障部位 ②故障レベル ③故障検出方法 障害情報をNova schedulerを考慮せず • 故障ノードに再配置 • リブートするHWに再配置
  39. 39. © 2017 NTT DOCOMO, INC. All Rights Reserved. STEP1:HW監視装置はNFVI Server障害を検出し, 障害情報の正規化を実施 STEP2:HW監視装置は正規化した障害情報を VIMに送信 STEP3:VIMは正規化された障害情報を 元にヒーリング実施判断し, NFVI ServerのIPMIを使いNFVI Serverの停止 (Fencing機能) STEP4:VIM/VNFMはNFVI Serverの停止を検出し 他のNFVI ServerにVMを起動する IA Server OSS VIM VNFM NFVO HW監視装置 故障 ① ② ③ キャリアネットワーク観点からの解決法 39
  40. 40. © 2017 NTT DOCOMO, INC. All Rights Reserved. CPU MEM NIC 致命的な障害 重度の障害 軽度の障害 警告 情報 DISK PSU FAN Temp CPU MEM NIC DISK PSU FAN Temp CPU MEM NIC DISK PSU FAN Temp CPU MEM NIC DISK PSU FAN Temp NFVI(ベンダ:A) テンプレート NFVI(ベンダ:B) テンプレート HW監視装置 NFVI(ベンダ:A) NFVI(ベンダ:B) 障害情報 障害情報 ハードウエア差分をなくすための障害情報の統一化 • 仮想化基盤システム内で用いる障害情報は統一的な表現とする – 障害レベルの定義と構成品を定義 – 異なる汎用IAサーバの障害情報を定義した障害情報にマッピングし正規化 – 障害情報のマッピング処理は一元的に実施する必要がある為,HW監視装置での実施 – 正規化はテンプレートを用いる事で汎用IAサーバの追加毎に機能追加なく実現可能 40 オペレータのポリシーを 元に定義 障害情報をマッピング Fault ID Fault severity 1011 CPU 警告 1012 CPU 軽度の障害 1013 CPU 重度の障害
  41. 41. © 2017 NTT DOCOMO, INC. All Rights Reserved. OPNFV Doctor •ハード故障を即座に検知し切替指示を行う機能を開発 •当初のScopeは開発完了 41 仮想化レイヤー ハード ソフト ソフト ハード 仮想化管理 システム ハード 稼働中 予備 仮想化レイヤー ハード ソフト ハード 仮想化管理 システム ハード 稼働中 故障 発生 故障 切替 指示 ソフト 予備 ハードウェア等の故障情報をリアルタイム把握し、 VMのSLAを踏まえて切替指示を実施
  42. 42. © 2017 NTT DOCOMO, INC. All Rights Reserved. OPNFV Doctor機能 42  モバイルコアノードの故障対応機能を新たに開発した  PJメンバ:NEC, Nokia, Ericsson, NTT SIC, DOCOMO他 ハードウェアサーバ(ホスト) ハイパーバイザ NFVI(クラウド基盤) VNF (ACT) VNF (SBY) 3rd Party NFVIモニタ Inspector (Congress/ Vitrage) AODHNOVA VNFM ① ② ③ ④ OpenStackにて開発した新機能: ①:故障通知(ホスト名) ②:故障通知(ホスト名) -NOVAにて「ホスト利用不可能」と状態変更 ③:VM状態変更 ④:VNFMへ故障通知 オペレータによる故障項目の動的な定義 オープンソースソフトウェアとして開発することで低コスト化の実現 OpenStackで1秒以下で故障対応可 開発のスコープ
  43. 43. © 2017 NTT DOCOMO, INC. All Rights Reserved. Doctor開発機能一覧 43  OpenStackに7つの新機能を開発した 4. (alt) Notify Monitor Notifier Consumer (VNFM, NFVO) Alarm Conf. 3. Update State 2. Find Affected Controller Controller Controller Resource Map 1. Raw Fault Inspector 4. Notify all 5. Notify Error 0. Set Alarm Failure Policy Monitor Monitor Nova Congress Ceilometer+Aodh NFVI (クラウドインフラ) OpenStack function 6 1 2 3 4 5 Title Status Owner Lead Developer Description Link Event Alarm Evaluator Code merged in Liberty Ryota (NEC) Ceilometer: Ryota (NEC) Implementation of new alarm evaluator to immediately notify consumers of fault events https://blueprints.launchpad.net/ceilometer/+sp ec/event-alarm-evaluator New nova API call to mark nova-compute down Code merged in Liberty Tomi (NOKIA) Nova: Roman (Intel) API to set compute nodes to down / up https://blueprints.launchpad.net/nova/+spec/m ark-host-down Support forcing service down Code merged in Liberty Tomi (NOKIA) Nova client: Carlos (NEC) Client-side implementation of above https://blueprints.launchpad.net/python- novaclient/+spec/support-force-down-service Get valid server state Code merged in Mitaka Tomi (NOKIA) Nova: Tomi (NOKIA) To get host status information when consumer queries for VM instance detailed information https://blueprints.launchpad.net/nova/+spec/ge t-valid-server-state Add Notification for service status change Code merged in Mitaka Balazs (Ericsson) Nova: Balazs (Ericsson) Notification of maintenance actions on e.g. compute nodes to consumers https://blueprints.launchpad.net/nova/+spec/se rvice-status-notification Push Type Data Source Driver Code merged in Mitaka Masahito (NTT) Congress: Masahito (NTT) This feature enables Congress to receive data from another service. https://blueprints.launchpad.net/congress/+spe c/push-type-datasource-driver Doctor Data Source Driver Code merged in Newton Masahito (NTT) Congress: Masahito (NTT) Push Type Data Source Driver adaptation for Doctor https://review.openstack.org/#/c/314915/ 1 2 45 6 3 プロジェクト名OPNFV Doctor 7 7
  44. 44. © 2017 NTT DOCOMO, INC. All Rights Reserved. 今後 44
  45. 45. © 2017 NTT DOCOMO, INC. All Rights Reserved. SDN(マルチレイヤ連携) ・・・ ・・・ コアネットワークの進化 [2016年3月9日] vEPCの商用導入 [2016年度以降] ネットワーク仮想化の適用拡大とハードウェア利用の効率化 [2020年度以降] 5G時代の新たなビジネスを実現するネットワークへの発展 vEPCの導入 既存EPC MME PGWSGW PCRF P-CSCF HSS TAS S-CSCF 既存IMS ビジネス領域の拡大 NFV導入 - スケールアウト/ヒーリング SGW MMEPGW 市販IAサーバ (COTS) NFV拡張 - 自動化の拡大 - 局舎間リソース共有 適用対象拡大 ハードウェア利用効率化 MME SGWPCRF TAS P-CSCFHSS … NFV進化 - サービス最適化ネットワーク SDN(局舎内) SDN(局舎間) ・・・ ・・・ ・・・ 現在 2020年度以降2017年度以降 4K S-CSCF PGW クラウドネイティブアプリ 45
  46. 46. © 2017 NTT DOCOMO, INC. All Rights Reserved. Reference (1/2) •OpenStack – https://www.openstack.org/assets/presentation-media/7688-Achieving- Low-Latency-NFV-With-Openstack.pdf •DPDK – http://events.linuxfoundation.org/sites/events/files/slides/Jun_Nakajima_NF V_Container_final.pdf – https://dpdksummit.com/Archive/pdf/2016USA/Day02-Session02- Steve%20Liang-DPDKUSASummit2016.pdf – https://01.org/sites/default/files/page/intel_onp_server_release_1.2_bench mark_test_report_v1.0.pdf 46
  47. 47. © 2017 NTT DOCOMO, INC. All Rights Reserved. Reference (2/2) •SR-IOV – http://events.linuxfoundation.org/sites/events/files/slides/20160715_Linu xCon_sriov_final.pdf – http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.456.8534&rep= rep1&type=pdf 47

×