CISMとは？CCMとは？NFVでコンテナ管理はどうやるの？

ETSI-NFV仕様の各Release機能の通り、ETSI-NFVのRelease4ではコンテナの制御が追加される。Release4はIFA039のSBAの影響でService Baseの仕様が入っており、ETSI-NFVにおけるコンテナ管理は様々なバリエーションがある。そのため、どのように各仕様を使うかを理解するのは非常に難易度が高いだろう。なお、コンテナとは何か？についてはこちらを参照して頂きたい。

Kubernetesによるクラウド管理

Kubernetesは、コンテナという技術と各種管理機能を使ってプログラム(APL)を抽象化し、クラウド上でAPLを制御するフレームワークとそれを支える管理機能群である。ここでのクラウドとは、APLを抽象化することでインフラの制御を含む様々な資源を共通機能化し、それらをAPIでソフトウェア的に制御できるようにしていることだが、それを仮想化とクラウドの違いから図でまとめてみた。

仮想化だけした場合(単純仮想化)は、基本的にはAPLは物理装置自体と同じ構造であり、それをインストールしたり故障時の修理をしたりする作業も物理装置と同じ手順が必要だった。しかし、せっかくAPLを仮想化によりソフトウェア化し、HWとの依存関係を無くしている(抽象化している)ので、例えば初期構築やHW故障時の対応をAPI化したい。これがIaaS(Infrastructure As A Service)と呼ばれ、サーバやNW機能の一部を管理機能(ETSI-NFVの場合はVIM)で制御できるようにしている。これにより、物理装置の変更に伴う各種作業は削減され、VMだけ考慮すればよくなった。さらに一歩進んで、LBやDBなどの共通機能をインフラの一部として提供する(PaaS)ことで、HWに依存しない新しいタイプのAPLとプラットフォームへ進化することができ、この“何か分らない雲のようなところにリクエストを出すとサービスを得られる“というものがクラウドである。

Kubernetesは、このクラウドの効果を最大化するために、APLの範囲を最小限化している。

Kubernetesの世界では、APLはDataを持たず、Logicのみをコンテナとしてカプセル化しPodという単位で管理することで、外部から容易かつ高速に起動/停止が可能となっている。そのため、APLの冗長やScalabilityの維持はPodを複数起動することで実現可能となる。複数のPodをKubernetesから自由に起動/停止するために、NetworkやStorageのリソースはインフラとしてKubernetesが準備する。NATやLBを利用することで、Podが増えたとしても外部装置からはIPaddressなどのネットワーク情報を隠蔽することで、PodのHealingやScaleを簡単に実現できるようにしている。

APLの構成はDeploymentで宣言的に記述することで、KubernetesはDeploymentに従ってPodの起動/停止を行う。DeploymentにはPodとReplicaSetが記述可能であり、ReplicaSetの亜種としてStatefulSetやDaemonSetがある。

ETSI-NFVにおけるCNF LCM

ETSI-NFVのRelease 4においてコンテナの対応が始まっている。Cloud Native VNFやContainer-based VNFと呼ばれCNFという言葉を使われるケースがあるが、厳密にはCNFという用語はETSI-NFVでは定義されておらず、Cloud NativeなVNFの基準としてEVE011のドキュメントがあるだけである。ETSI-NFVでの議論を聞く限り、Cloud Native VNFと呼ぶ場合はVMかContainerかは区別せずクラウドの機能を十分に利用できるAPLを総称しており、OS Container、MCIO(Managed Container Infrastructure Object)またはWorkloadと呼ぶ時は所謂コンテナを指すようだ。

Release 4のCNFのLCM関連の機能としては、CIS(Container Infrastructure Service)・CISM(CIS Management)・CIR(Container Image Registry)が中心となり、IFA040とSOL018にCISMのインタフェース仕様(API requirements)が記載されている。CISMの参照実装はKubernetesであり、デファクトの乖離が発生しないようにETSI-NFVではパラメータレベルの詳細な要件は定義せず、VNFDとの関係やCISMの要件レベルの定義で終わっている。もう一つ大きな機能としてはCIS Cluster(＝CIS＋CISM)とCCM(CIS Cluster Management)であり、IFA036にてCCMのインタフェース仕様が検討されいている(2021年11月現在も策定中)。CNFのInstantiationのためには、CCMを中心としたCIS Clusterのデプロイと、VNFMを中心としたMCIOのデプロイの2Stepが必要となる。

CIS ClusterはContainer on VMのケースとbare metal containerのケースの2パターンがあるが、CCMはCIS Clusterを構築するために必要なリソースをNFVOへGrantして確保し、その後CCD(CIS Cluster Descriptor)を利用して確保したリソースを利用しながらCIS Clusterを構築していくことになる。

CIS Clusterが完成すると、VNFMはCNFのリソースをCIS Cluster上に確保するために必要なリソースをNFVOへGrantし、NFVOがNamespaceを設定した後に、VNFMが通常通りVNFDを利用しながら該当NamespaceにMCIOを構築していくことになる。この際、CNF LCMはVNF LCM APIをそのまま利用可能のため、OSSやEMから見るとVM based VNFとContainer based VNFは同一APIを利用して同じようなLCMを実現可能である。Release4の機能部とマッピングするとこのようになるだろう。PaaSのLCMは、CIS ClusterのLCMに含まれるのか、CNFのLCMに含まれるのか、それとも新しい機能部として新しいLCMが定義されるか不明だが、この絵では考え方をシンプルにするためにCIS ClusterのLCMに含まれる前提で記載した。

特徴しては、container on VMのCIS Clusterであったとしても、CIS DescriptorとしてVNFDとは別の方法でデプロイされることだろう。これはつまり、VMベースかどうかという技術の面ではなく、インフラとVNFが完全に分離されたことを意味する。コンテナのNWはインフラに位置するため、CIS Clusterとして構築されたNW上でCNFは動作することになる。結局モバイルNWのお仕事って何？の通り、交換機そのものがRouterみたいなものでAPL自身がNWを構築するため、CNFがインフラのNWを利用するとなると実運用としてはかなり難易度が高くなるだろう。

また、1VNFC = 1PodとしてVnfcResourceInfo + ResourceHandleによって管理される。Deploymentについては新しくMcioInfoが導入される予定である(2021年11月現在仕様策定中)。

NFVOはCIS Clusterを1つのリソースプールとしてキャパシティを管理し、VIMのTenantと同様にCIS ClusterはNamespaceで各VNFインスタンスの利用可能なリソース量が管理される。NFVOはVNFMからのGrantに応じて、デプロイ可能なCIS Clusterの選定、Namespaceの作成、CIRの選定を行い、それらをGrantInfoとしてNFVOからVNFMに渡される。

ETSI-NFVとO-RANの議論状況を踏まえたコンテナNW

コンテナのNWは、Underlay NW(物理的なケーブリング等)と、Container NWとしてのPrimary Container NW(Kubernetesが構築するデフォルトNW)とSecondary Container NW(MultusのようにKubernetesの管理するNWの外のNW)がある。O-RANにおいてはUnderlay NWはIMS(Infrastructure Management Services)によって構築されるようだ。まとめると、このようなNWの作成分担になるだろう。

今回はまだETSI-NFVで仕様策定中のコンテナ管理について解説した。そもそもコンテナはUser空間で実行されるためパケット加工のような低レイヤの処理が得意では無かったり、Kubernetesはネットワークをインフラと用意することで抽象化や可用性を高めているのでモバイルAPLのようにNWを動的に変更することは出来なかったりするので、安定してコンテナ技術をモバイルに利用できるようになるまでにはもう少し時間がかかるだろう。

また、Kubernetesのように圧倒的に強いデファクトがある場合、相互接続性のために標準化すべきポイントや内容のコンセンサスが取りにくいという問題も見つかった。現在O-RAN WG6においても、O2dms interface (Deployment Management Services)の仕様規定方法や、vRAN APLのKubernetesの使い方とTransport Networkとの接続方法について揉めているので、コンテナをテレコムの標準仕様として参照する点についても安定するまでなかなか時間がかかるのかもしれない。最近では“相互接続性担保のためのminimum set”のみ標準化するという話を聞くので、良い方向には行っていると期待したい。