こんにちは。ソリューション技術部の佐藤です。
私が所属する次世代インフラ基盤チームでは、仮想化基盤技術、データ分析基盤技術、インフラ自動化の3つ技術を軸に
推進しており、今回、その中の注力分野のひとつであるNFVの動向について纏めたいと思います。
かなり広範囲に渡る領域なので、今後、数回に分けて掲載していきたいと思っています。
NFV(Network Function Virtualization)とは
ネットワーク機器は、物理の専用ハードウェア(アプライアンス)でソフトウェアとハードウェアが 一体化されて提供されていました。 NFVでは、専用ハードウェア部分を汎用ハードウェア(汎用サーバ)で代替し、そのハードウェア上で ネットワーク機器を仮想化技術に対応したネットワークの機能をソフトウェアで動作させる考え方です。 このNFVの考え方は、主に通信事業者やサービスプロバイダーが保有する大規模な通信設備に対するCAPEX/OPEXの削減を実現することが 一般的に言われていますが、動画配信のトラフィックの増大やIoTなど求められる通信特性の変化により、 柔軟性の高い通信設備を迅速に導入できるようにすることで新しいサービス(ビジネス)の創造に寄与すると期待されている背景があります。
下記の画は、ETSIで提唱しているNFVのアプローチ
アーキテクチャ
下記のアーキテクチャは、ETSIで提唱しているNFVのリファレンスです。
このリファレンスアーキテクチャで大きく3つの領域に分けられます。
・NFVI →NFV Infrastractureの略称で物理の汎用ハードウェア(CPU/RAM/DISK)を仮想リソースとして提供できる形態で構成する OpenStack/KVMやVMwareの製品など仮想化ソフトウェアを含む仮想化基盤であり、VNFにそのリソースを使用させる。
・NFV-MANO →物理および仮想リソースを一元的に管理することとVNF/VNFCsのライフサイクルを管理する役割を担う。 また、それらにオーケストレーションさせる機能を組み合わせて、NFVシステム全体を最適に運用できる仕組みを提供する。
・VNF →仮想リソースを使用して動作する仮想ネットワークアプライアンスで一般的に複数の役割に分離したアプライアンスをまとめて VNFCs(VNF Components)としてO&Mを含んで機能を提供するケースが多い。
標準化動向
NFVを実現するためには、大変広い技術領域で構成されるため様々な要素技術やそれに対応した製品が組み合わされて導入されることになり、 完全に独自仕様で実装するケースや標準化を検討している団体のリファレンスをベースに実装するケースが現状であるが、標準化に関しては、 まだ発展途上の段階であり、現時点での主要な団体とその動向をまとめてみました。
ETSI NFV ISG
ETSI(欧州電気通信標準化機構)が2012年にNFVを検討するNFV ISGを世界の大手通信事業者7社で発足させた標準化団体。 サービスプロバイダーとは違い、通信事業者の通信設備は、大規模/複雑な実装をされており、尚且つ、OSS/BSSとの連携が必要なため 情報提供されたものを集約し、ETSI NFVリファレンスアーキテクチャから必要な要件の洗い出しやインターフェースの標準仕様策定までの活動を継続しており、 現在は、Working Group(WG)がTST,SOL,REL,IFA,EVE,SECの6つが活動中である。これらのWGの活動については別途記事を書こうと思います。
Open Source MANO
概要と動向
Open Source MANO(OSM)は、ETSI主導によるNFV-MANOのソフトウェアを開発するプロジェクトで アーキテクチャは、ETSIのリファレンスに準拠するものでTelefonicaが開発していたOpenMANOの拡張版の位置付け。 リソースオーケストレーションの機能がOpenMANO、VNFMの機能がJuju、ネットワークオーケストレーターの機能が RIFT.ioによる組み合わせで構成されています。 Current Versionは、Release THREEとなっており、ETSI NFV PoCでも使用されています。
The Linux Foundation(Linux Foundation Networking)
Linux Foundation内にNetworkingのプロジェクトが複数運営されていましたが、 2018年1月にLinux Foundation Fundを立ち上げ、プロジェクト(FD.io,ONAP,OpenDaylight,pnpd,SNAS.io)を まとめて運営する方針に変わり、Open Source Networkingとして活発に活動しています。
ONAP(Open Network Automation Platform)
概要と動向
Linux Foundation Networking Projectsの一つで、NFVだけでなくSDNも対象とした NFV-MANOの領域であるオーケストレーションのインターフェースの標準化を行うOpen-O(Open-Orchestrator)と AT&Tが開発したOpenECOMPを統合したソフトウェアです。 ネットワークデザイン、ランタイム、FCAPS、マネジメントの4つのコアコンポーネントで構成され機能が非常に多岐に渡ります。 ネットワークサービス全体のライフサイクルの運用観点で幅広いレイヤを対象としており、ETSI、MEF(E2E-Orchestrator)、OPNFVなど多数の標準化団体との 連携もしつつ非常に活発に活動しています。
OPNFV
概要と動向
OPNFVは、キャリアグレードなNFVを実現するためのNFVI環境に必要な実装を実現するためのソフトウェアの位置付けで、 ETSIが検討しているユースケースや要件を受け、OpenStackやOpenDaylightなど各種OSSをインテグレーションし、 検証を継続的に実施することでNFVのプラットフォームとして進化をさせています。 OpenStackとのコラボレーションの機能拡張が活発でOpenStackのアップストリームコミュニティでは、 NFVの要件に対応できないところを補完している印象。 Current Versionは、6.0のFraserとなっており、約6か月毎のサイクルでリリースされています。
OpenStack Foundation
概要と動向
OpenStackは、言わずと知れた抽象化(仮想化)されたハードウェアリソースをAPIで制御するオースンソースソフトウェアですが、 すでに2010年初期バージョンのAustinリリースから8年が経過しています。現在は、17番目のリリースのQueensで コアコンポーネントを含むプロジェクトが30を超えており、今もなお進化を続けています。 昨今のOpenStack Summitでは、通信事業者主導になり、NFV/SDN関連の話題が中心になっておりように見受けられます。 NFVでは、オープンソースをベースとして他のOSSや製品とエコシステムを形成して実現する考え方がありますが、 まさにOpenStackのようなAPIで連携する仕組みで裾野が非常に広く複雑な場合に インターフェースの連携を簡素化/共通化することで今後のNFVの発展に寄与し続けると思っています。
まとめ
今回は、動向を記載しましたが、具体的にNFVを実現するためには、考慮すべきポイントが多々あります。
・NFVリファレンスアーキテクチャのインテグレーションポイント(インターフェース)の仕様が厳密に決められていない。
・仮想化させることで、専用アプライアンスよりもアーキテクチャの複雑化によるボトルネックが発生する。
・運用監視の仕組みは、サーバ系でよく使われる製品や技術を利用できるが、物理/仮想に跨る障害発生時の切り分け、復旧手法がが複雑化(影響範囲の特定が難しい)する。
・複数のベンダーが提供するVNFCを共通基盤(NFVI/NFV-MANO)で動作させる場合は、共有基盤に求められる要求仕様が異なる。
・エコシステムを形成するため各製品やOSSのライフサイクルが異なるためアップデートやパッチの適用など運用設計/ポリシーが難しい。
・NFVでは、ネットワーク機器を仮想化するため、ネットワークアクセラレーターなどを使用する必要性がある。
このように幾つか挙げてみましたが、課題に対応する製品や技術が出てきており、より具体的に検討が始まるフェーズに入ると予想されます。 弊社では、継続的に全体感を捉えつつ、今後課題解決のパッケージなどの開発に取り組んでいこうと思っています。
