TackerはVNFFGの柔軟性が向上

　本記事では、2018年5月21日～24日に開催されたOpenStack Summit Vancouverにおいて発表されたTackerに関する最新動向をご紹介します。

Tackerプロジェクトについて

　TackerはNFVのオーケストレーションの実現を目的とした、いわゆるMANO（Management and Network Orchestration）と呼ばれる機能を提供するOpenStackの1プロジェクトです。通信キャリアや関連ベンダによって構成される標準化機関のESTI（欧州電気通信標準化機構）^※1にて定義されたNFV仕様準拠を志向して実装されており、VNFやNW構成、その他各種設定に関する情報をテンプレートとして用意することで、VNFデプロイの簡易化、定常運用や障害時の復旧自動化、サービス環境の削除などを実現したライフサイクルマネージメントを提供します。

※1：ESTI: http://www.etsi.org/technologies-clusters/technologies/nfv

Tackerのプロジェクトアップデート情報

　TackerのProject UpdateセッションでのQueensリリースで追加された主な機能を紹介します^※2。

※2：Tacker project update: https://www.youtube.com/watch?v=FOPSd3dBBPU

図1：Tacker Project Updateセッション

VNFFG（VNF Forwarding Graph）とトラフィックのフローclassifierの更新機能

　これまでのTackerでは、VNFFG用のテンプレートにVNFFGおよびトラフィックのフローclassifierを記述すると、それ以降は変更することができませんでした。しかしQueensリリースにて、すでに作成されたVNFFGを追加または削除したり、VNFFGに対するフローclassifierを更新したりできるようになりました。詳細は次の章にて紹介します。

VNFモニタリングのためのZabbixプラグイン対応

　Tackerはこれまでに、CPUやメモリ使用量のようなCeilometerが提供するリソースパラメータに対応した、簡易なモニタリングドライバを提供してきました。Queensリリースでは、ハードウェアコンポーネントの可用性とパフォーマンスを監視するソフトウェアであるZabbixのプラグインがサポートされました。これにより、CPU、OS、プロセス、メモリ空間の使用量から、アプリケーションに関連したステータスまで監視できるようになりました。

Kubernetesおよびコンテナ型VNFへの対応

　これまでのTackerでは、OpenStackだけがVIM（Virtualized Infrastructure Manager）としてサポートされており、VNFを仮想マシン上で稼働させていました。しかしながら、通信キャリアのユースケースでは、NFV環境下においては、VNFのアップデートや障害からの再構築、スケーリングのスケジューリング、そしてマイグレーションに迅速に対応することが求められています。軽量なコンテナはその解決策として期待されていることから、Queensリリースにて、TackerはKubernetesをVIMとして追加しました。これでTackerは、コンテナ化されたVNFと、仮想マシン型のVNFの両方を扱えるようになりました。

注目のVNFFG機能

　今回のリリースにおける注目機能はVNFFG です。VNFFGは、VNF間の通信経路をsrc/dstの仮想ポートIDやIPアドレスなどによって柔軟に操作できる機能です。VNFFG自体は既存の機能ですが、QueensリリースではVNFFGの定義の自由度が向上しました。

　詳細をご説明する前に、VNFFGについて少し紹介させていただきます。VNFFGはVNFFGD（VNFFG Discriptor）と呼ばれるYAML形式のテキストで定義されます。VNFFGD内ではNFP（Network Forwarding Path）と呼ばれる通信フローの定義がされており、NFPはClassifierと呼ばれるフロー適用対象トラフィック定義と、Chainと呼ばれる制御ポリシー定義で構成されています。例えばClassifierには通信元のneutronのポートIDや通信先のIPアドレスなどが記載されており、Chainには転送先のVNFなどが記載されます。

図2：VNFFG、NFP、Classifier、Chainの関係（※3の発表資料より引用）

※3：dynamic SFC from Tacker to incept specific traffic of VM https://www.youtube.com/watch?v=Shxd9zVPif0

　VNFFG内でClassifierとChainを定義することで、NFVの中のトラフィックを柔軟に制御できます。例えば、ユーザートラフィックと管理トラフィックが存在するNFVにおいて、ユーザートラフィックを定義するClassifierと管理トラフィックを定義するClassifierを記述し、それぞれにChainを定義することで、通信経路や通過するVNFを制御できます。

　Queensでは、このVNFFGに関して、以下のようなアップートがありました。

• 1つのVNFFGD内に複数のClassifierを記載できるようになった
• VNFFGで定義された通信の戻りの通信も同じ経路を通せるようになった
• 登録済みのVNFFGを更新できるようになった

　また、Queensリリースでは、前述のとおりZabbixとの連携が強化されており、VNFFGとZabbixの連携による運用作業の自動化が容易になりました。例えば、ZabbixにVNFの異常監視と、監視状況をトリガにしたVNFFG更新ジョブを設定しておけば、障害発生時に通信を自動制御できます。本サミットでは、このユースケースのデモセッションも行われており、Zabbixが監視対象のWeb Serverのアクセス負荷増を検知して、Tackerに登録されたVNFFGの自動更新を行う様子が見られます^※3。

次期リリースでのTackerの新機能

　次期Rockyリリースでは、仮想マシン型VNFとコンテナ型VNFへのサービスファンクションチェイニング機能や、OpenStack Blazar^※4の予約リソースを利用したインスタンス生成機能がサポートされる見込みで、カバーするNFVのユースケースが拡大されることが期待されます。また、Horizonと連携したGUI機能がサポートされ、VNFやVNFFGのテンプレートを容易に作成できるようになる予定です。

※4：OpenStack Blazar: https://wiki.openstack.org/wiki/Blazar

終わりに

　今回のサミットでは、OpenStackを「Open Infrastructure」として押し出しており、NFV、container連携、HPCなどの話題の技術に共通して利用できる基盤という地位を確立しようとしていました。

　Tackerがより成熟すれば、OpenStackはNFV基盤の選択肢の一つとなるでしょう。