とことこロゴス
メニュー

NFV

読み：えぬえふぶい　／　英語表記：Network Functions Virtualization

ルータやファイアウォールなどのネットワーク機能を専用機器から切り離し、汎用サーバなどの共通基盤上でソフトウェアとして動作させる仮想化技術である。機能の追加や能力の増減を、物理装置の調達・交換から独立して管理しやすくする。

イマシルちゃんの解説

通信を振り分ける装置や、不正な通信を止めるファイアウォールを増やすたびに専用の機器を用意すると、設置や配線に手間がかかるよ。
NFVは、こうした装置の働きをソフトウェアにして、共通のサーバ上で動かす仮想化技術なんだ。
例えば新しい拠点にファイアウォールが必要になったら、用意してある基盤でその機能を起動し、拠点の通信が通るように接続するの。
機器を一台ずつ追加する構成より、機能の配置や変更を柔軟に進めやすいよ。
ただし、サーバの処理能力や故障時の備えも必要だから、ソフトウェアにしただけで性能や信頼性まで確保できるわけではないんだ。

より深い解説

専用機器から機能を切り離す

NFVはNetwork Functions Virtualisationの略であり、ネットワーク機能と、それを実行する物理ハードウェアの結び付きを緩める考え方である。例えば従来は一台の専用装置として導入したファイアウォールやロードバランサを、共通基盤へ配置できるソフトウェアとして扱う。

目的は、装置の台数を減らすことだけではない。必要な場所へ機能を配置する、処理負荷に応じて能力を増減する、ソフトウェアを更新するといった作業を、物理装置の入替えから分けて行いやすくすることにある。実際の機能配置には計算資源とネットワーク接続の両方が必要であり、ソフトウェアを起動しただけでは通信を処理できない。

ETSIのGS NFV 002は、機能、実行基盤、管理の役割を分けた基本的な構成を示している。ここでいう共通基盤は、必ずパブリッククラウドでなければならないわけではない。通信事業者の設備や企業内のデータセンターでも構成できる。

機能・基盤・管理を分けて捉える

NFVを理解するときは「何を動かすか」「どこで動かすか」「どう配置・管理するか」を区別する。次の表は基本構成における役割を整理したものである。

名称担当するものファイアウォールを配置する例
VNF仮想化したネットワーク機能パケットを検査して許可・拒否するソフトウェアが該当する
NFVI計算・記憶・ネットワークの資源と仮想化層からなる実行基盤CPU、メモリ、NIC、仮想スイッチなどを提供する
NFV-MANO機能と基盤の管理・オーケストレーション必要な資源を確保し、起動・接続・監視・増減を調整する

VNFはVirtualised Network Function、NFVIはNFV Infrastructureの略である。VNFを動かす単位は一つの仮想マシンに限らず、複数の構成要素からなる場合もある。物理装置が担う機能をPNFと呼んで区別し、移行途中のシステムでは物理機能と仮想化した機能を組み合わせる構成もある。

仮想マシンではハイパーバイザを通して計算資源などを提供する。コンテナを用いる実装ではOSの機能を利用して実行環境を分離する。クラウドネイティブな設計に基づくネットワーク機能はCNFと呼ばれることがあるが、単にコンテナで動かすだけで自動的に高可用性になるわけではない。ETSIのコンテナ対応に関する説明でも、仮想マシン型とコンテナ型を並行して扱う構成が示されている。

起動から更新・終了までを管理する

機能がソフトウェアになると、起動、設定、監視、能力変更、故障復旧、更新、終了という一連の管理が必要になる。このような生成から終了までの管理をライフサイクル管理という。MANOはManagement and Orchestrationの略であり、個々の操作をサービス全体として整合させる役割を持つ。

基本となる三つの管理機能には次の違いがある。担当範囲はETSI GS NFV 006に基づいて整理している。

管理機能主な責任確認する対象
VIM（Virtualised Infrastructure Manager）実行基盤の計算・記憶・ネットワーク資源を管理するどのサーバへ資源を割り当てられるか、どの仮想ネットワークへ接続するかを扱う
VNFM（VNF Manager）各ネットワーク機能の生成・能力変更・復旧・終了を管理するその機能が必要な状態で動作しているかを扱う
NFVO（NFV Orchestrator）ネットワークサービス全体と資源利用を調整する複数機能をどう組み合わせ、サービス全体を成立させるかを扱う

例えば、拠点向けの通信サービスにファイアウォールを追加するなら、サービス全体の構成を決める処理、機能を起動する処理、実行資源を確保する処理が協力する。これらは責任の分け方であり、必ず別々の物理サーバや製品で実装するという意味ではない。ETSI NFV FAQでは、管理機能の違いと、複数の役割を同じソフトウェアにまとめられることを説明している。

再現可能に配置するため、必要な資源や接続点などを記述するVNFDと、サービス全体の構成を記述するNSDを用いる。運用を支えるOSSや契約・課金などを扱うBSSとも連携するが、利用者向けサービスの契約処理とパケット転送そのものは担当範囲が異なる。

通信を必要な機能へ順番に通す

機能を起動した後は、対象の通信をそこへ導く必要がある。例えば「利用者からの通信をファイアウォールへ通し、その後でロードバランサへ渡す」という処理順を定める。必要な機能を順序付きで通過させる仕組みがサービスファンクションチェイニングである。

サービスチェインでは、どの通信をどの機能の列へ入れるかという分類と、実際にそこへ届ける転送の制御を分けて考える。機能を別サーバへ移した場合は、通信経路の変更も伴う。単に仮想マシンの稼働状態だけを監視していても、経路が誤っていればサービスは成立しない。

また、ファイアウォールやNATは通信の状態を記憶する。行きと戻りで無関係な装置へ分散すると、応答を正しい通信として扱えないことがある。往復を対応する処理へ通すか、必要な状態を共有する設計が要る。サービスの順序と経路、状態を持つ機能の扱いはRFC 7665で整理されている。

SDNとは何が違うか

NFVとSDNは組み合わせて使えるが、同じ技術ではない。NFVが扱うのはネットワーク機能と専用ハードウェアの分離である。SDNはネットワークの制御と転送を分離し、ソフトウェアから通信の流れを制御しやすくする考え方である。

例えば、ファイアウォールの機能を共通基盤で動かすことはNFVの役割である。そのファイアウォールへ対象の通信を送る経路をプログラムで変更することにはSDNを利用できる。NFVを導入すれば必ずSDNも導入しなければならないわけではなく、SDNの制御機能を仮想化して動かす構成も可能である。

この違いを押さえると、仮想化した機能が正常なのに通信が届かない場合に、機能そのものと転送経路を分けて調べられる。両者の独立性と補完関係はETSI NFV FAQの説明でも明確にされている。

能力を増やすときは処理の分散方法も決める

負荷の増加に対しては、一つの実行単位にCPUやメモリを追加するスケールアップと、実行単位を増やして処理を分担させるスケールアウトを使い分ける。どちらも、機能側がその増強方法へ対応している必要がある。

例えば毎秒4万パケットを処理できる実行単位を2つ用意しても、単純にサービス全体で毎秒8万パケットを処理できるとは限らない。一方へ通信が偏る、共通のNICで詰まる、状態同期が負荷になるといった制約がある。増強する対象だけでなく、分散する位置と共通資源の上限を確認する必要がある。

能力を縮小するときも、稼働中の実行単位を突然停止させるだけでは既存の通信が切れる。新規の接続を別の実行単位へ回し、残っている接続を終了させるか引き継ぐという処理が必要になる。自動増減の条件には、CPU使用率だけでなくパケット数、同時接続数、遅延など、実際の機能に関わる指標を選ぶ。

パケット処理の性能を確保する

同じ通信量でも、小さなパケットが大量に来る場合は一秒当たりの処理回数が増える。回線速度だけでなくppsで表す毎秒のパケット数や、遅延の変動も評価する。共有サーバでは別の処理による資源競合も発生するため、平均CPU使用率が低いだけでは十分でない。

性能を調整する技術には次のようなものがある。ただし、すべての環境で同時に必要なものではなく、柔軟性との引換えも確認する。

技術NFVで使う理由
CPUピニング仮想CPUと物理CPUの対応を固定し、実行場所の変動や競合を減らす
NUMAを考慮した配置CPU、メモリ、NICの位置関係をそろえ、遠いメモリへのアクセスを抑える
ヒュージページ大きなメモリページを使い、アドレス変換の負担を減らす
DPDKパケット処理向けのライブラリなどを使って高速なデータ処理を実現する
SR-IOV一つの物理NICが提供する仮想機能を割り当て、入出力の負担を減らす

ハードウェアへの直接的なアクセスを増やすと、別のホストへ移す際の条件が厳しくなる場合がある。したがって高速化だけを選定理由にせず、移行、冗長化、監視の仕組みも合わせて評価する。Red HatのNFV構成資料では、CPU・NUMA・メモリ配置などの関係を確認できる。

故障の範囲と状態の引継ぎを設計する

複数の機能を一台のホストへ集めると、そのホストの故障でまとめて停止する。冗長化したつもりの二つの実行単位も、同じホストや同じ電源系統に置けば同時に失われるおそれがある。別の障害範囲へ分けるアンチアフィニティの配置方針を使い、物理的な故障の影響を分散する。

機能が起動し直すことと、利用者の通信が継続することは同じではない。NATの変換情報やファイアウォールの接続状態を必要に応じて待機系へ同期し、切替え後の経路も整合させる。冗長化の目的が新しい接続を受け付け直すことなのか、既存の接続も維持することなのかを明確にする。ETSI GS NFV-REL 003は、基盤と機能を含む信頼性を扱っている。

運用ではサービス単位、機能単位、基盤単位の監視を対応付ける。一つのホスト障害から複数の機能の警報が出た場合に、別々の障害として追い続けないためである。管理API、仮想化層、配布するソフトウェアイメージも保護対象となる。管理権限を絞り、更新と復旧の手順を確認してから機能を集約する。

午後問題につながる判断

例えば「ファイアウォールを二重化したが、物理サーバの故障で両方停止した」という事例では、ソフトウェアの台数だけを見てはいけない。両者が同じ障害範囲へ配置されていたかを確認し、ホストや電源・接続経路も分散させる必要がある。

また「負荷に応じて機能を増やしたのに通信が速くならない」という場合は、機能の起動数と通信の分配を分けて調べる。転送経路、負荷分散、共通NIC、状態を共有する処理のどこに上限があるかを示せば、単に資源を追加するより具体的な改善につながる。

参考資料

この用語が出てくる記事

↑