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

© 2017 NTT DOCOMO, INC. All Rights Reserved.
OpenStackを利用したNFVの商用化
２０１7年7月２6日
NTTドコモネットワーク開発部
中島佳宏

自己紹介
•中島佳宏
– 経歴
•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

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

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

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

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

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

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

２．商用化への取り組み
10

ネットワーク
仮想化
の基礎研究に着手
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

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

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

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

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

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

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
Computer packet 1KByte
1.2MPPS, 835 ns
10Gbpsってどのくらい大変なの?
17

テレコム向け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

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

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数が多い
構成がシンプル
３vNIC程度
20

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

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

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

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を活用

SR-IOVの活用
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
vNICの制限最大64 VF
1 unicast MAC/VF
64 vlan/VF
最大30 multicast MAC
最大100 vNIC
vNICの増加に伴い
性能劣化
NWアプリの挙動観点で
制限が多い 
26

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

実際は････
› 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

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

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

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

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

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

論理識別子の命名方法の工夫による解決
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
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
NIC#1NIC#0
host
Physnet2
①Assign Logical Name for Physical NIC
NIC#0 = Physnet2／NIC#1 = Physnet1
Physnet1
VM#AVM#B
①機種に依らず同じ空リ
ソースのSocketを識別
• Physnet1:空リソース大
• Physneｔ2:空リソース小
②論理デバイスによる識別方法
を仮想Network名にも透過適用
し、抽象的なSocket指定
• Large：空リソース大
• Small：空リソース小
34

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

ヒーリング
36

①オートヒーリング
（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
サーバ異常を検出
VNFMへ通知
別ServerにVMを配置
IA Server
VNFc
IA Server
VNFc
OSS
VIM
VNFM
NFVO
VNFc
VNFc
故障
ヒーリング
VNFMは障害情報から
ヒーリング要否を判断
VMを起動通信ソフトを復旧
サーバベンダ毎に故障情報ポリシーが異なる
①障害検知可能な故障部位
②故障レベル
③故障検出方法
障害情報をNova schedulerを考慮せず
• 故障ノードに再配置
• リブートするHWに再配置

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

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 重度の障害

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

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秒以下で故障対応可
開発のスコープ

Doctor開発機能一覧
43
 OpenStackに７つの新機能を開発した
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

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

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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

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

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

More from VirtualTech Japan Inc.

More from VirtualTech Japan Inc. (20)

Recently uploaded

Recently uploaded (9)

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