OPNFV

2017/06/13

プロジェクト名

OPNFV


プロジェクト期間
2016年4月~2018年3月

 

■プロジェクト概要 

OPNFVはオープンなNFVのプラットフォームを構築するためのオープンソースプロジェクト(コミュニティ)である。

沖縄オープンラボではSDN/NFV連携技術研究としてNFVの利用可能性について研究してきたが、この活動をさらに広げていくため2016年3月にOPNFVにAssociate Memberとして加盟した。より多くの技術者と連携しながら国内外におけるOPNFVコミュニティ活動の活性化に協力し、OPNFVのすそ野を広げる活動を実施している。
具体的には、日本初のOPNFVコミュニティテストラボを沖縄に構築し、その上でOPNFVのFunctestプロジェクトをベースとした仮想ルータの自動テストシステムを開発・検証した。開発したテストシステムはOPNFVコミュニティへコントリビューションするとともに、国内外のOPNFV SummitやOPNFV User Groupにおいて成果を発表している。また、台湾の会員であるIIIに対してOPNFVの環境構築ノウハウを提供し、IIIにおけるOPNFV環境の構築をサポートした。
2017年度は、IIIや他の拠点と連携し、自動デプロイ、自動テスト、フォールトマネージメント、リソース管理といったNFVユースケースの検討、PoCを実施する。

 

 

2017年度の取り組み(2017年4月~2018年3月)

■ 2017年度の研究活動

 2017年度は以下の3つの検証を実施した。各検証内容について記載する。

  • マルチサイト環境下(台湾と沖縄)でのVNFテスト

  • OpenStackの予約機能とVNF Managerの連携機能検証(スケールイン・アウト)

  • OpenStackの予約機能とVNF Managerの連携機能検証(SR-IOVのComputeノード予約)

 

■マルチサイト環境を用いた(台湾と沖縄)でのVNFテスト
 

OPNFV FunctestをベースにIIIとOOLの両拠点に構築したOPNFV環境を用いて仮想ルータの自動テストを行うシステムの検証を実施。本検証により、IIIと連携した環境構築ができた。また、FunctestのVNFテスト基盤は、シングルサイトでの利用のみではなくマルチサイト環境下でも利用可能ということが本PoCを通して確認できた。本PoCの成果は北京で開催されたOPNFVSummit2017のセッションでも発表を実施。

 

  • 試験環境

 (1)Manegement netとPublic netをVPN接続。
  a) ManegementはOpenStackのテナント・ユーザ作成やOSイメージのためのAPIをたたくことに使用。
  b) PublicはFuctestから各vrouterへのssh経由でのコンフィグ投入や、Cloudify Managerから各拠点の
    OpenStack環境の操作のために使用。

 

 (2)VNFの相互接続テストを行なうコンテナImageとなっているOPNFV FunctestをマルチサイトでVNF

   テストができるように変更を実 施。コンテナを起動後、CloudifyというVNFマネージャが立ちあがる。

   Cloudifyより仮想ルータを台湾と沖縄のOPNFV環境に立ち上げを行なう。その後、テストが実行され

   結果がコンソールに出力される。

 

   テスト内容は、VyosのBGP相互接続検証を実施した。詳細は下図。

 

 

 

■OpenStackの予約機能とVNFマネージャーの連携機能検証(スケールイン・アウト)

 

 テレコムシステムではインフラリソースが限定された条件でのVNFの運用も想定され、VNFの運用上リソースの予約が必要となる。通信の標準化団体(ETSI)でも標準仕様に「予約」の考えが盛り込まれている。NFVO・VNFMであるTackerと予約機能のBlazarとの連携機能は、まだ実現されていなので、不足分の機能の作りこみを行い、作りこんだ機能上でVNFを動かしPoCを実施する。得られた知見や機能は精査しOpenStackやOPNFVのコミニュティに機能提案とコントリビューションを念頭に活動をしている。

 

  • 想定するシナリオ

   ・VNF への負荷上昇に対応するスケールアウトの実施
        スケールアウトの実施直前に資源の予約を実施して、確実にスケールアウト出来ることを保証

   ・特定イベントなど事前に はじめはVNF への負荷上昇が想定可能な場合の事前スケールアウト
        事前に資源を予約しておくことで、イベント期間に他のアプリケーションが資源を使い尽くしてしまうことを防止

 

  • 検証する機能

    ・VNFの予約機能と連携したスケールアウトシナリオ
        シナリオ観点
          指定した開始時間に予約したVNFがスケールアウトされることを確認

    ・VNFの予約機能と連携したスケールインシナリオ
        シナリオ観点
          指定した終了時間に予約したVNFがスケールインされることを確認
 

  • コンポーネント間の動作の流れ

  以下に、リソース予約機能を利用したVNFのスケールアウト・スケールインのユースケースを実現するために、主要なコンポーネントとして、OpenStackのBlazar(リソース予約機能)、Tacker(NFVO/VNFM)、Aodh(アラーム機能)、Heat(OpenStackオーケストレーション機能)、Nova(VM提供機能)を利用した。

 

    1)    初期トポロジ構築・予約作成時
        1-1) ユーザがTackerにVNFDを登録しVNF生成要求を行う
        1-2) TackerからBlazarに予約の作成を行う
        1-3) TackerでHOTを生成し、Heatに生成要求を行う
        1-4) HeatからNovaにVM立上げ要求を行う
        1-5) NovaがVM立上げを行う
        1-6) HeatからAodhにアラーム作成を行う
          この手順で、初期トポロジのデプロイと予約が作成される。

    2)    予約開始店・終了時
        2-1) BlazarよりAodhに予約開始・終了を通知する
        2-2) AodhよりHeatに予約開始・終了アラームを通知する
        2-3) HeatよりNovaにスケールアウト用VM立上げ・削除要求を行う
        2-4) Novaがスケールアウト用VMの立上げ・削除を行う
 

 

  • PoCについて

  本項目では構築したデモの流れの詳細を記載する。デモの内容はIP電話システムにおいてリソース予約にあわせてSIPサーバを増減(スケールアウト・スケールイン)させるものである。デモの構成はロードバランサ(Kamailio)1台とSIPサーバ(Astarisk)2台、SIPクライアントは各SIPサーバに対して2台1ペアの計4クライアントのシンプルな最小構成で実現した。状態として予約開始前の初期状態(ロードバランサ1台とSIPサーバ1台)から予約開始時の拡張用SIPサーバがスケールアウトされる。予約終了時にはスケールインされ初期状態に戻ることを確認する。
 

 

  • POCの動画

 

■OpenStackの予約機能とVNF Managerの連携機能検証(SR-IOVのComputeノード予約)

 

 予約機能を用いたスケールイン・アウトの検証が2017年12月に完了し、共同検証メンバーで2017年度4Q(1月~3月)期間の検証内容の検討を実施。検討の結果、SR-IOV や DPDK 等の特定機能を持ったサーバの利用を予約で保証することは重要であることから、SR-IOV機能を持ったComputeノードの予約機能のユースケースとして、BlazrとTackerを連携させた特殊機能をもつComputeノードのPoCを行なうことで検証内容が決定しその検証を実施。
 

 SR-IOVとは、VNFのスループットを高速化する技術の一つで、仮想マシンに接続するNICをサーバの物理NICで利用できる技術である。SR-IOVの機能は、物理機能(PF)と仮想機能(VF)の2つがある。PFは、SR-IOV の機能を管理するために使用されサーバでは、通常の物理NICと同様に使用でき、VFを制御するために利用する。VFは物理 Ethernetコントローラーから作成された仮想 PCIe デバイスで、仮想マシンと接続ができる。

 

 

  • コンポーネント間の動作の流れ

  「OpenStackの予約機能とVNFマネージャーの連携機能検証(スケールイン・アウト)」で利用した主なコンポーネントの組み合わせでリソース予約機能を用いたSR-IOV機能(特殊機能)をもった予約を実現する。

 

 

 

  • PoCのデモ内容

 PoCデモの内容の流れを以下となる。以下の手順より、正常にSR-IOVのComputeノードからVMが正常起動することが確認できた。その結果を下図のOpenStackのDashBordでネットワークトポロジーにて示す。

 

    1.SR-IOVのPortと予約開始時間、終了時間を記載したVNFDのファイルを用意しておく。
    2.1.のファイルを用いてTakcerにVNFDの作成要求を実施。
    3.2.のVNFDを用いてTackerにVNFの作成要求を実施。
    4.予約開始時にSR-IOVのPortを用いたVMが起動し、予約終了時にVMが削除されることを確認する。
 

 

 

■国内外のイベントでの成果発表

  • OPNFV Summit(2017年6月 北京)

    • 「Challenge in Asia Region: Connecting Each Testbed and POC of Distributed NFV Use Cases」のタイトルで発表

  • 日本OPNFVユーザ会Meetup(2017年4月 東京)

    • 「沖縄と台湾を接続した環境でFunctestのVNF(vrouter)テストを 動かしてみた」のタイトルで発表

  • OpenStack Days Tokyo(2017年7月 東京)

    • 「沖縄オープンラボラトリのOPNFV 活動の取り組み」のタイトルで発表

  • Okinawa Open Days 2017
    日 時:2017年12月4日(月)〜2017年12月7日(木)
    場 所:沖縄県市町村自治会館(那覇市)
    プレゼン資料

  •  

    平成29年度沖縄オープンラボラトリ活動報告会
    日 時:2018年2月21日(水)
    場 所:沖縄県市町村自治会館(那覇市)
    プレゼン資料

     

     

     

     

     

     

     

     

2016年度の取り組み(2016年3月~2018年3月)

 

■OPNFVへ加盟

  • 2016年3月にOPNFVにAssociate Memberとして加盟

 

 

 

 

 

 

■OPNFV Test Labを構築

  • OPNFV評価環境として日本初OPNFV Test Labを構築しOPNFVコミニュティに登録

  • サーバ4台と3台構成それぞれでOpenStackを構築し検証やCIで利用

 

 

 

■OPNFV上でVNFテストシステムを開発

  • OPNFV FunctestをベースにOPNFV環境上で仮想ルータの自動テストを行うシステムを開発

 

 

 

OPNFV Functest へのコントリビューション

  • 開発したVNFテストシステムをFunctestのテストケースの一つとしてコントリビューション実施

 

 

■IIIへのOPNFV環境構築ノウハウの提供

  • 構築ノウハウの提供とチャットにて随時フォローすることで無事にOPNFV環境を構築完了

 

 

■国内外のイベントでの成果発表

  • OPNFV Summit(2016年6月 ベルリン)

    • 「Automated Platform for Testing VNF Performance and Interoperability with Variable Flavors」と題して発表

  • 日本OPNFVユーザ会Meetup(2016年9月 東京)

    • 「FunctestでVNFを動かしてみた」と題して発表

  • OPNFV Summit(2017年6月 北京)

    • 「Connecting Each Testbed and POC of Distributed NFV Use Cases」と題してIIIとの共同研究を発表

  • 【平成27年度 沖縄オープンラボラトリ活動報告会】

    • 日時:2016年2月5日(金)10:00~17:00

      場所:沖縄IT津梁パーク 会議室(うるま市)

      成果報告資料

 

■2017年度の活動案

  • IIIとの検証活動

    • OOLとIIIを接続した環境上でVNF(vrouter)テストのBGP相互接続性検証を実施し、マルチサイトでの自動デプロイ・自動テストの検証を実施する

  • OPNFV Functestへのコントリビューション活動

    • 前年度FunctestへコントリビューションしたVNF(vrouter)テストにFunctestのVNF抽象化フレームワークを適用するリファクタリングを行い、Functestコミュニティに貢献する

  • NFV PoC実施(案)

    • オープンラボを1つの拠点としてNTI(NECインド)拠点に接続し、NFV PoC検証実施に協力する

    • 下記の要素を組み合わせたNFVユースケースを検討してPoCを実施し、得た知見を展開する

      • TOSCAベーステンプレートのデプロイ(Cloudify/Tackerなど)

      • フォールトマネージメント(Doctor)、リソース管理(Promise、Blazar)

    • Sprintを分け段階的に検証を実施

      ①Sprint1:計画、設計、NFVユースケースの検討

      ②Sprint2:環境準備・構築(マルチサイト)、vEPCのデプロイ検証実施

      ③Sprint3:フォールトマネージメント(Doctor)の検証

      ④Sprint4:リソース管理(Promise、Blazar)の検証

    • NFVユースケース案:

      • Promise/Blazarでアクティブ側、スタンバイ側のリソースを予約して、vEPCをデプロイし、アクティブ側のvEPCの切断をDoctorで検知してスタンバイ側のvEPCに切り替える

 

 

Share on Facebook
Please reload