NFVOとは？Orchestratorとは？
2012年頃にNFVのコンセプト議論が始まった頃から”Orchestrator”というキーワードをチラホラ聞かれるようになったが、2021年になった今でも結局Orchestratorの定義や必要性がよく分からない。仮想化と監視運用自動化のECAベースのようなWorkflowと混同されることもあり、「Workflow Orchestrator」で検索すると自動化という文脈の検索の中でWorkflowとOrchestratorが並んだ結果が多数出てくることも分かるとおり、Orchestrator＝Workflow＝自動化で話されることも多いことも原因だろう。
ETSI-NFVにおけるNFVOの役割
VNFMとは？で記載したとおり、NFVOの役割とは
- 複数のVIMのキャパシティ管理
- 既存保守機能部(OSS)との接続
- 自動化
NFVOの機能
ETSI-GS NFV-IFA 010を確認すると、NFVOが保持する機能としてはVirtualised Resource (VR) Mgmt, VR PM, VR FM, Reservation Mgmt, NFVI capacity Mgmt, Quota Mgmt, Network Forwarding Path (NFP) Mgmt, Permitted allowance Mgmt, NS LCM, NS PM, NS FM, NS Pacckage Mgmt, PNFD Mgmt, SW image Mgmt, Policy Mgmt, Multi site connectivity mgmtがある。
- NS LCM vs VNF LCM
- NS LCMはNFVO、VNF LCMはVNFMが管理しているため、例えばあるVNFに対してHealingするかScalingするかの判断がNSレベルとVNFレベルで異なる可能性がある。どちらのLCMをマスターにするか(Source of truth)とするかという問題がある。
- ETSI-NFVのArchitectureでは、”NFVOの判断を尊重する“ためにVNFMはVNF LCMを実行する前にNFVOへのGrantが必要となっている。
- VIM selection
- 元々NFVOに期待されていた自動化の機能の一つが、VIMを選定する機能であった。テレコムのように多数のData Center (＝VIM)があると当然一律なVIMがあるわけではないので、VNFをInstantiationするVIMをどう選ぶかは大変な作業が必要となる。
- NFVOのOrchestratorion機能としては、このVIMの選定をVNFの要件とVIMの能力や残容量から適切に選ぶという行為(＝Resource Orchestrator)が期待されている。一方で、なかなか期待に沿ったOrchestratorは世の中に存在しないので“人手で選定“というのが必要となっているのが現状だろう。
- Network Service (NS) vs Provider Network
- 前述のVIM SelectionをNFVOが実行できる前提で、通信が必要なVNF間を接続するために該当のVIMのNWや、VIM間を繋ぐWANのNWなどの設定が必要となる。このNW接続の機能がService Orchestratorであり、VIMを選定しそのVIM間やVNFを接続するためのNW設定を行うことが期待されている。
- 一方で結局モバイルNWのお仕事って何？のとおり、テレコム装置とはそれ自体がNW機器のようなものであり、VNF自体が様々なトンネリング技術を利用してルーティングやネットワークセグメントを行なっている。そのため、NSによってNFV-MANOが作成するNWとVNF自体が構築するNWが衝突することがあり、VIMとしてはProvider Networkとして土管だけ構築すれば良いということもある。
- VIM SelectionとNS vs Provide Networkを考慮すると、NFVOの役割はあまりなくなってしまい、ただの巨大なUIツールとしてしか使われないこともある。
- Direct mode vs Indirect mode
- これもNFV仕様を複雑にし、NFV-MANO内の機能分担を難しくしている。IFA010とIFA007を確認すると、VNFMはVRのリクエストをVIMにもNFVOにも発行できることになっている。OpenStack、VMware、AWSと様々なVIM相当の機能をどの機能部が隠蔽するかという考えにおいて、VNFM(Direct mode)とNFVO(Indirect mode)の両方があるからだろう。
- 現在のSOL003ではIndirect Modeは実質サポートされていないためデファクトの流れとしてはDirect modeになっている。そのため、実質NFVOのVR Mgmtは利用されていないだろう。
- VNFD vs Grant&Compute Flavor
- IFA011やIFA005/006によるとNFVO＆VNFMが解釈するVNFDと、VIMに格納されているCompute Flavor (Nova Flavor等)は別物である。
- しかし、SOL001のTOSCAと、SOL014のVR Descriptor (HOT)やSOL018のHelmを比較すると、かなりの部分が重複している。TOSCAはテンプレートいうより、もはやVMやNWの設計図になっており、HOTやHelmもVNFの構築手順書で多くの部分が重複している。
- NFVOを実装する際に、TOSCA Orchestratorベースで実装するか、Grant & Compute Flavorベースで実装するかはかなり悩むところだろう。
Workflow vs Orchestrator
これらのNFVOの機能を確認すると、実はWorkflowとしての機能とOrchestratorとしての機能の両方が期待されている。NSDに記載された通りにNWを構築するところやNS LCMを実施する機能はWorkflowだが、Grantに伴うVIM Selectionや必要NWの設計はOrchestratorの機能となっている。
WorkflowとOrchestratorの違いは、WorkflowはWorkflowが主体となってMaster Dataや他コンポーネントの制御を行うが、Orchestratorは他ComponentのCapabilityと他機能部のRequestをMatchingすることが求められている。そのため、Workflowは自分が保持しているデータがMaster data (Source of Truth)であり、いかにWorkflowサイドが保持している状況にComponentsの状態を近づけるかということが行われる。一方で、Orchestratorは他Componentsの最新の状況をDiscoveryし、構成やNWのトポロジーを自ら組み上げ、必要な情報を他装置に渡し、自らが制御することは無い。
Workflowは有能な指揮官に基づいてトップダウンで作業者が作業するのに対し、Orchestratorは作業者達のボトムアップのリクエストを適切に調整する合議制の会議のようなイメージだろう。NFVOはこの両面を持っている上に、世の中に信頼度の高いOrchestratorも存在しないために非常に分かりにくい機能部となっているのかもしれない。
コメント
コメントを投稿