インバンド・マネージメントで uCPE のデプロイメントを簡単に（しかも安く）行う方法

Karl Mörner

VNF（バーチャル・ネットワーク・ファンクション）のサービス・チェイニングを実装した uCPE を管理するために、NIC（ネットワーク・インターフェース・カード）はいくつ必要でしょうか？WAN データ用として 1 つ、各 VNF に対して 1 つ、プラットフォームに対して 1 つですか？

残念ですが、不正解です。 ユニファイド・インバンド・マネージメントを利用すれば、同じ物理インターフェースですべてのマネージメントおよびデータトラフィックを共有できます。つまり共有インターフェースにより、システム・コストを最小限に抑え、エンド・ユーザーの管理を容易にすることができます。エンタープライズ・デプロイメント向けのマネージド・サービスの構築において、この 2 つは非常に重要な柱となります。インバンド・マネージメントに対して統合型アプローチを採用することで、この 2 つの柱を実現できるだけではなく、サービス・プロバイダが新たな VNF をオンボードして機能と収益のストリームを追加することも簡単になります。

商用 VNF の多くは、追加機能としてインバンド・マネージメントをサポートしています。インバンド・マネージメントを利用すれば、1 つのネットワーク接続で、WAN トラフィックとマネージメント・トラフィックの両方を構成できます。インバンド・マネージメントでは、VNF（VNF 用ベアメタルを実行する物理アプライアンス）は、すべてのインターネット経由の通信に対して 単一の IP アドレスを使用できます。マネージメント専用ポートが不要となるため、ネットワーキングのセットアップが簡素化され、システム・コストが軽減されることに加え、インストール手順も簡素化されます。VNF の基本設定は、マネージメント専用ポートを使用する標準的なアウトオブバンドの構成方法ですが、インバンド・マネージメントはこの点で大幅な向上を図ることが可能です。

 

Figure 1. Compare standard and in band management VNF configuration

図1. VNF 構成：標準型とインバンド・マネージメントの比較

 

そうは言っても、マネージメント専用ポートが必要な場合もあります。例えば、他の VNF のサービス・チェーンの一部になっている VNF などがこれに当たります。このチェーンに含まれるすべての VNF に、マネージメント・トラフィックを全て流し込むのは、理想的とは言えません。そうしたセットアップを構成すると、サービス・チェーン内の各 VNF に余計な複雑さが生じます。また、サービス・チェーンの実現のみを目的として VNF 固有の構成を行うと、サービス構成全体に脆弱性を生み出すことになります。すべての VNF に、自らの属するサービス・チェーンと基盤であるネットワークを意識させないようにすること。これが設計の鉄則です。

 

Figure 2: Service chaining combined with in band management on VNF level is a design problem

図 2：VNF レベルでサービス・チェイニングとインバンド・マネージメントを組み合わせるデザインは好ましくない

 

この状況では、WAN、LAN、マネージメント向けにそれぞれ専用ポートを設ける標準的なアウトオブバンド形式の VNF 構成を使用すべきです。その一方で、単一つのインターフェース・ポートを使用するインバンド・マネージメントでは、ユーザー・エクスペリエンスの向上とシステム・コストの削減が実現されます。

 

Figure 3: A service chain without in band management on VNF level for simple VNF onboarding

図 3：VNFのオンボードを簡素化するために VNF レベルでインバンド・マネージメントを行わないサービス・チェーン

 

優れたデザインと簡素化を両立させるには、サービス・チェーンのネットワーキングセットアップに関して、徹底すべきいくつかの要件があります。

  • コスト上の理由から、WAN とマネージメントでポートを共有する。
  • 各 VNF に、自らが属するサービス・チェーンを意識させないように構成する。
  • WAN、LAN、マネージメントそれぞれに専用ポートを使用して各VNFをコンフィギュレーションすることは理想的な手法であり、より洗練されたサービス・チェーン構成のために必須である。

これらの一見矛盾するような要件をどのように組み合わせるかについては明快な正解はないのかもしれませんが、その解を基盤となる仮想レイヤーに実装することは可能です。

  • この仮想プラットフォームでは、自身のプラットフォーム・レベルのマネージメント・トラフィックを WAN トラフィックに使用する物理 NIC と共有できるようにします。
  • WAN トラフィックに使用する物理 NIC も、各 VNF のマネージメント・トラフィックと共有します。
  • 単一の物理 NIC 上でマネージメント・トラフィックと WAN トラフィックを共有しても、サービス・チェーン内の個々の VNF 構成に影響をあたえることはありません。

 

Figure 4: The virtualization platform shall solve service chaining and in band management independent of the VNFs it hosts

図 4：仮想プラットフォームは、ホストする VNF とは無関係に、サービス・チェイニングとインバンド・マネージメントを解決

 

それでは、ユニファイド・インバンド・マネージメントへのこのアプローチを実現する仮想プラットフォームはあるのでしょうか？

答えは「Yes」です。uCPE 向けの仮想プラットフォーム Enea NFV Access があります。物理 NIC 1 つのみを使用して、マネージメント・トラフィックと WAN トラフィックのすべてに対して、プラットフォーム・レベルのインバンド・マネージメントを実現します。ZTP（Zero Touch Provisioning）の一部として、オートメーションを簡単に行うこともできます。このソリューションは、どのような規模のサービス・チェーンでも拡張することができます。 VNF をオンボードする際に、その VNF がサービス・チェーンに含まれるかどうかを考慮する必要はありません。インバンド・マネージメントとサービス・チェイニングに関するすべてのネットワーキング構成は、仮想プラットフォームにおいて解決されます。Enea NFV Access は、VNF のオンボードを簡素化し、単一のパブリック IP アドレスで WAN トラフィックとマネージメント・トラフィックのすべてをサポートし、真に汎用性の高いオンボードの方法を提供し、完全なオープン性といかなるベンダーにも依存しない柔軟性を実現します。

Enea NFV Access の詳細については、Enea のウェブサイト www.enea.com/nfv をご覧ください。

注：本記事の初出は LinkedIn です。