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.

NFVアプリケーションをOpenStack上で動かす為に - OpenStack最新情報セミナー 2017年7月

1,434 views

Published on

タイトル:NFVアプリケーションをOpenStack上で動かす為に
講師:橋口 厚志(NEC)
アジェンダ:
- NFV概要
- 独自基盤時代
- OpenStack改造時代
- OpenStack利用時代、そしてこれから

Published in: Technology
  • Be the first to comment

NFVアプリケーションをOpenStack上で動かす為に - OpenStack最新情報セミナー 2017年7月

  1. 1. NFVアプリケーションを OpenStackで動かす為に 2017年 7月 26日 日本電気株式会社 橋口 厚志 【NEC Confidential】
  2. 2. 3 © NEC Corporation 2017 NEC Confidential ▌仮想化技術によって従来ネットワーク機器のソフトウェアとハードウェアを分離 ▌通信ネットワークの経済性、柔軟性、迅速性の高度化を目指す 仮想化されたネットワーク機能(VNF)従来のネットワーク機能 専用/特定ハードウェアリソース 仮想化レイヤ 汎用ハードウェアリソース オーケストレーション/リソース制御 IMS VM VM EPC VM VM L3SW VM VM GW VM VM Data Base VM VM App Server VM VM IMS EPC L3SW GW Data Base App Server 迅速かつ柔軟なリソース変更 ハード/ソフトの垂直統合 ソフト/ハードの分離 専用、特定のハードウェア 汎用、最新ハードウェア 専任者による保守運用業務 オーケストレータによる保守自動/簡易化 ハード括り付けのためリソース変更不可 NFV概要(NFVとは)
  3. 3. 4 © NEC Corporation 2017 NEC Confidential NFVの課題 汎用サーバ ハイパーバイザ 仮想マシン 仮想スイッチ キャリア向け 通信ソフトウェア キャリア向け 通信ソフトウェア 専用HW (ATCA等) 汎用ハード化 仮想化 従来のHWの単位でVM化 冗長構成も従来を踏襲 ⇒運用保守性の踏襲、安定した資産の活用 仮想マシン キャリア向け 通信ソフトウェア NIC冗長構成によ る信頼性担保不可 Numa Node跨りに よる性能劣化 リソース 共有による性能劣化 仮想スイッチの 性能ボトルネック HW障害検知契機の 系切替不可
  4. 4. 5 © NEC Corporation 2017 NEC Confidential NECのNFV基盤に対する取り組み OpenStack NEC 2011 2012 2013 2015 20162014 ETSI NFV E F G H I J K L M N Release1 Release2 独自基盤 OpenStack 改造 OpenStack 利用 NECCSを発表世界初vEPC商用稼働
  5. 5. 独自基盤時代
  6. 6. 7 © NEC Corporation 2017 NEC Confidential 独自基盤時代の取り組み概要 ▌VNF(Virtualized Network Function)に必要な要件を実装 ▌OpenStack Controller相当の機能実装  CPU Pinning/占有  NUMA考慮スケジューリング  PCI-Passthrough/SR-IOV  EPT HugePage  ベアメタル制御 ▌ Compute Serverでの機能実装  DPDK-VS  リソース優先制御  KVM Monitoring  HW障害通知
  7. 7. 8 © NEC Corporation 2017 NEC Confidential NFVI施策:リソース優先制御 3.63 5.96 0.62 2.30 5.07 20.65 0.00 5.00 10.00 15.00 20.00 25.00 物理環境 仮想環境(2VM) [ms] 平均値 標準偏差 最大値 TAT計測結果 SIP SIP VM① ホストOS+KVM VM② 計測区間: INV~100間のTAT 負荷: 36万BHCA vCPU数=16 物理CPU数=16 vCPU数=16 標準偏差(σ)の計算式: N: 900 [回] Xi: i回目のTAT m: TAT平均値 ▌SIPアプリケーションでリソース競合影響を確認 ▌平均1.8倍、最大値4倍の影響あり
  8. 8. 9 © NEC Corporation 2017 NEC Confidential NFVI施策:リソース優先制御 NIC・ディスク 仮想マシン(VM) ホストOS (Linux) KVMモジュール ハードウェア ドライバ virtio CPU スケジューラ メモリ 施策3 ディスクIO優先 制御 施策2 ネットワークIO優 先制御 ゲストOS AP ネットワークIO ディスクIO virtioドライバ CPU命令 QEMU 仮想マシン(VM) ゲストOS AP ネットワークIO ディスクIO CPU命令 QEMU virtioドライバ 施策1-1 リブート時高負荷対策 リブートイベント検出し CPU使用率を制御 施策1 CPUリソース優先制御 チューニング チューニング
  9. 9. 10 © NEC Corporation 2017 NEC Confidential NFVI施策:リソース優先制御 ▌施策1:CPUリソース優先制御  リアルタイムスケジューラでスケジューリング  VM毎に期間単位で優先制御を行う VM1 VM2 VM3 タイムスロット値 2ms 5ms 1ms 設定イメージ VM1:2ms VM2:5ms, VM1:2ms, VM3:1ms, NULL:4ms 2ms start ホ ス ト O S の 他 プ ロ セ ス が 動 く た め の 期 間 max max max優先度 max max max 優先度変更 ポイント 2ms 5ms 2ms 1ms 4ms 2ms 5msタイムスロット値に 合わせ優先度を制御 優先度 優先度 タイムスロット コントローラ (ホスト上デーモン) 1 112 23 優先度に合わせ CPUリソース割当て リアルタイムスケジューラ (ホストカーネル内)
  10. 10. 11 © NEC Corporation 2017 NEC Confidential NFVI施策:リソース優先制御 Linux Kernel VMVM 物理マシン 仮想マシン ホストOS 標準KVM 仮想NIC 仮想NIC 仮想NIC 仮想NIC 標準Bridge 物理NIC 物理NIC Linux Kernel VMVM 物理マシン 仮想マシン ホストOS 改善版KVM 仮想NIC 仮想NIC 仮想NIC 仮想NIC Open vSwitch 物理NIC 物理NIC ▌施策2:ネットワークIO優先制御  Open vSwitchを利用し、ネットワークIOの上限帯域の制御を行う。  仮想NICごとの制御/上限帯域、バースト値を設定
  11. 11. 12 © NEC Corporation 2017 NEC Confidential NFVI施策:リソース優先制御 ▌施策3:ディスクIO優先制御  cgroupを利用し、ディスクIOの上限帯域の制御を実施  仮想NICごとの制御/上限帯域、バースト値を設定 Linux Kernel VMVM 仮想HBA 仮想HBA DISK 物理マシン 仮想マシン Linux Kernel 改善版KVM cgroups IO IO
  12. 12. 13 © NEC Corporation 2017 NEC Confidential NFVI施策:NW性能向上 DPDK-VS Host OS NFV Extension Intel DPDK vSwitch VM AP Guest OS VM AP Guest OS VM AP Guest OS Host OS KVM Open vSwitch NIC HW DPDK Pass-through VM AP Guest OS VM AP Guest OS VM AP Guest OS KVM HW ボトルネック NIC DPDK NIC NIC Pass-through ▌“Intel DPDK vSwitch”に「QOS機能」「大規模フロー対策機能」 「virtio IF対応」をNECで追加。 ▌Open vSwitchに代わり適用することで、NWデータ転送性能向上、性能 ボトルネックを解決
  13. 13. 14 © NEC Corporation 2017 NEC Confidential NFVI施策:NW性能向上 DPDK-VxLAN OpenvSwitch + VXLAN DPDK vSwitch + DPDK VXLAN Throughput 約10倍 better VM Guest OS AP DPDK vSwitch (with VXLAN) VTEP NIC NIC Linux kernel vNIC virtio tap vport Hypervisor H W High-speed Processing Network throughput 一般的に性能劣化の発生しやすいトンネリング技術であるVXLANを利用時にお いても、DPDK VXLAN/DPDK vSwitchを利用することで高スループットを実現
  14. 14. OpenStack改造時代
  15. 15. 16 © NEC Corporation 2017 NEC Confidential OpenStack改造時代の取り組み概要 ▌ETSI NFV発足  どうやらVIMは、OpenStackがデファクトスタンダードらしい ▌Icehouseをベースに足りない機能を追加実装 ▌並行してRedHat社と連携、Communityでの機能実装を促進 ⇒ Kiloでほぼ機能実装完了
  16. 16. 17 © NEC Corporation 2017 NEC Confidential OpenStackのキャリアグレード化 Red Hat社と共同でOpenStackのキャリアグレード化を推進
  17. 17. 18 © NEC Corporation 2017 NEC Confidential OpenStack(Icehouse)+NEC拡張 NEC-Extension OpenStack VM VM HW/OS Nova PMControl Glance NWControl Keystone VMControl Neutron Ceilometer Resource Monitoring Local Resource Orchestrator アーキテクチャ Nova拡張。半故障HWや使用NW帯域の考慮 等高度な配置ロジックを実現 Nova拡張。CPU占有化、仮想NIC冗長等 を実現 物理サーバ制御。OpenStackに存在しな い物理サーバ制御/障害監視機能 Neutron拡張。高速仮想スイッチであるD PDK vSwitchと連携を実現 Ceilometer拡張。物理サーバのリソー ス収集/監視を実現。 Agent群。NFVIに配備されVIM機能と 連携した情報通知/制御を実施 プラグイン連携 API連携 NEC-Extension Agent plugin OpenStack Agent plugin VIM NFVI
  18. 18. 19 © NEC Corporation 2017 NEC Confidential OpenStack改造時代:HW構成を意識した配置 Pinning Numa Node 1 Numa Node 2 6 7 VM2 2 3 4 5 VM1 0 1 0 1 16GB 32GB 32GB 32GB 2 3 4 5 アーキテクチャを意識しない場合、 NUMAを跨ぐ・CPU共有する配置となる可能性 →性能劣化の原因 Processor (Core) phy_id(Node) memory Pinning Numa Node 1 Numa Node 2 6 7 VM2 2 3 4 5 VM1 0 1 0 1 16GB 32GB 32GB 32GB 2 3 4 5 Node構成を考慮することで、 仮想化の性能劣化を最小限に OpenStack(Icehouse) OpenStack + NEC拡張(NFV Extension) Node構成・Pinningの定義と、それを考慮した配置先選択で、性能劣化 を最小限に
  19. 19. 20 © NEC Corporation 2017 NEC Confidential OpenStack改造時代:SR-IOV NIC VM AP Guest OS NIC VM AP Guest OS vNIC vNIC Host OS NIC VM AP Guest OS NIC(SR-IOV) VM AP Guest OS vNIC vNIC Host OS HWHW SR-IOV未適用の場合 SR-IOVを利用した場合 VF VF 要5Gbps 要5Gbps 10GbE 要5Gbps 要5Gbps 10GbE 10GbE 10GbE 1:1割り当てのみ 1物理デバイスに複数割り当て 単一物理デバイスに複数VMの割り当てを可能とすることで、物理デバ イスの帯域幅を有効活用。 ユーザプレーン等のトラヒックのスループット性能を向上
  20. 20. 21 © NEC Corporation 2017 NEC Confidential OpenStack改造時代:EPT Hugepage 【施策前】 【施策後】 ゲ ス ト メ モ リ マ ッ プ ホ ス ト メ モ リ マ ッ プ ゲ ス ト メ モ リ マ ッ プ ホ ス ト メ モ リ マ ッ プ ・・・ ・・・ ・・・ ・・・ ページサイズ: 2MB ページサイズ: 1GB TLB EPT アドレス変換 EPT アドレス変換 TLB ヒット率向上 段数が減り 変換処理高速化 24段の変換 15段の変換 アドレス解決アドレス解決 EPT Hugepageを利用し、ページサイズ(メモリの区切り)を拡大。ア ドレス数を減少させることで、アドレス解決の変換処理高速化、アドレ スキャッシュのヒット率を向上。
  21. 21. 22 © NEC Corporation 2017 NEC Confidential OpenStack改造時代:性能 呼処理能力 (TPS) スループット (PPS) (1) 非仮想化:NEC専用HW(aTCA) (1.00) (1.00) (2) 仮想化 :汎用サーバ、OpenStack 0.27 0.02 (3) 仮想化 :汎用サーバ、OpenStack+NEC拡張 1.20 1.63 ※弊社EPC(PGW)での測定結果を基に、 CPU 1スレッドあたりに換算して比較しています。(測定条件は次頁参照。) なお、弊社トラヒックモデル例での性能値の為、お客様環境条件によっては異なる場合があります。 NEC拡張なしでは、Cプレーン性能 73%減、Uプレーン性 能 98%減 NEC拡張により、最新HWを使用することによる性能向上が 、仮想化オーバーヘッドを上回り既存装置以上の性能に
  22. 22. OpenStack利用時代、そしてこれから。。
  23. 23. 24 © NEC Corporation 2017 NEC Confidential OpenStack利用時代 ▌VNFを動かす為のOpenStack機能はおおむね実装完了 ▌パラメータチューニング(収容数/同時制御数) ▌OpenStack以外の基盤コンポーネントの効率的な構築 ▌運用改善  基盤装置交換  増減設  Update/Upgrade  解析
  24. 24. 25 © NEC Corporation 2017 NEC Confidential module C 担当 module B 担当 OpenStack利用時代:現在の営み Before 時刻 module A Module B の問題 module A 担当 問い合わせ 保守部門 module B module C ? Module C の問題 障害解析に 着手 問い合わせ 回答(転送) 問い合わせ ? 解析 module C 担当 After 時刻 module A 保守部門 module B module C 回答 問い合わせ 分析 ? 1次対応リードタイムを削減 障害解析に 着手 回答 解析 根本原因は module C トリガ ログ トリガ ログ ▌AIを活用しNFV化による解析煩雑性を解決

×