基本的な管理モデルは何年も前から存在しており、非常にシンプルで論理的な階層構造に基づいています。つまり、まず機器を購入し、購入したハードウェア機器の上にネットワークを構築します。ネットワークは、相互接続性を確保するためにネットワーク管理システムを使用し、必要な「ネットワークへのサービス」認識を追加するためにサービス管理システムを使用する機器のセットで構成されます。
何十年も続いてきた素晴らしいモデルですが、仮想化の出現によって時代遅れになりつつあります。
仮想化にも、抽象化とインスタンス化に基づく独自の管理モデルがあります。まず、導入したい抽象的なサービスやデバイス（ルーターやルーターのセット、あるいはルーターのセットに基づくVPNサービスなど）を設定します。次に、抽象的な仮想リソース（コンピューティング・パワー、アプリケーション、データ・ストレージ、仮想接続など、何でも）をデプロイして実装します。最も単純な説明でも、仮想化に関する2つの事実が明らかになりつつあります。1つ目は、仮想化はサービスとリソースの間の低レベルのステップをすべてスキップする必要があるということ。しかし、仮想ネットワークによってクラウド・プロバイダーが仮想アプライアンスを直接操作して新しい仮想ネットワーク・サービスを作成できるようになった場合、仮想アプライアンスはサービス全体の属性について何も知らず、同様にサービス間の相互関係も知らないと考えるのが妥当です。このような管理環境で失われるもの、つまり、サービスの一部をサービス全体に関連付ける能力、またその逆も同様です。
その結果、仮想ネットワーク管理では、サービスが作成されたときに確立された関係の記録をプロバイダーが保持し、必要に応じて後日管理環境を復元するためのアクションを実行できるようにする必要があります。これは、クラウド・コンピューティング・ネットワークの実装ではほとんど見落とされている非常に重要なステップです。つまり、通常はサービスの開発だけで、ソフトウェア・オーバーレイはネットワーク機器との特別なリンクを持っていません。このアプローチを使って最高のサービスを開発することはできますが、それはSLAや契約上のコミットメントに基づくマネージド・サービスではありません。
仮想化に関する2つ目の発見は、物理的な対応とは異なる抽象的なリソースを作成できることです。実際の物理デバイスを使って仮想スイッチ、ルーター、ファイアウォールを開発する必要はありません。このため、管理ラインがより複雑になります。例えば、仮想ファイアウォールは、実際にはいくつかの管理プロセスと1組のネットワーク接続で構成されているかもしれません。もしファイアウォールが物理的なデバイスであれば、ファイアウォールのステータスをチェックするために、SNMPコマンドを送信してその管理情報ベースを読み取ることが可能でしょう。しかし、仮想ネットワーク・サービスには物理的なファイアウォール・コンポーネントが存在しないため、読み込むべき MIB はありません。また、仮に各コンポーネントの MIB があったとしても、その MIB データは仮想ファイアウォールの機能にどのように関係するのでしょうか？物理世界には接続性が存在しないため、コンポーネント間のネットワーク接続状態も考慮する必要があります。
仮想ネットワーク管理に関するこれら2つの戦略的問題に加えて、非常に現実的な問題があります。バックボーン・ファイバーのみで接続された複数の異なるデータセンター内の物理サーバー上で数十台の仮想マシンが稼働しているシナリオを想像してみてください。この複雑なプラットフォーム上で仮想ネットワークサービスがどのように機能するかを想像してみてください。クライアントが1,000台、サービスが2,000台、サーバーが12台、データセンター間のリンクが1本あるかもしれません。これらのサービスのどれかの状態を発見するためには、そのサービスが使用するリソースの管理インターフェースを調べる必要があり、その結果、何千ものサービスが有限数のリソースにそのようなサービス要求を行うことになります。このため、ネットワーク・トラフィック管理には膨大な負荷がかかり、管理要求に応答するだけでもリソースに大きなアプリケーション負荷がかかります。
仮想ネットワークサービスの新たな管理モデル
業界全体として、バーチャル・マネジメントに関するすべての答えをまだ持っているわけではありませんが、マネジメント・モデルの定義やマネジメント・フローのコントロールについては、ある程度の進展が見られます。バーチャル・マネジメントの経験が増えるにつれて、どちらも洗練されていくでしょう。
トラフィック管理の分野では、IETFは「インフラからアプリケーションへの情報転送」と呼ばれるプロジェクトに取り組んでいます。このプロジェクトでは、ステートフルなシステム・プロセスにリソースをポーリングし、その結果を便利な場所または複数の場所で収集する機能を持たせることで、管理情報のリポジトリを作成します。アプリケーションは、管理データに直接アクセスするのではなく、i2aexリポジトリにデータを照会ることができます。また、ライブラリは、アプリケーションを繰り返しポーリングするのではなく、アプリケーションにプロアクティブに変更をプッシュすることができます。
管理モデルに関しては、2つの発展方向が見られます。1つは仮想アプライアンス・モデルで、ソフトウェア定義または仮想ネットワーク機能には、それらが作成する仮想アプライアンスを表すことができる管理コンポーネントが含まれます。管理コンポーネントは、最も便利な機能セットで開発することができ、このモデルでは、厳密な機能性よりも管理のしやすさに基づいて仮想アプライアンスを作成できる可能性があります。
もう1つのモデルはサービス駆動型オペレーティング・モデルで、サービスを作成するための機能の集合体が定義されます。例えば、TMフォーラムの情報アーキテクチャGB922サービス・ドメイン・パターンを使用するクラウド・コンピューティング・プロバイダーは、サービス・ポートフォリオを定義すると同時に、管理関係の定義を行うことができます。その結果、一般化されたプロセスは、任意の時点で管理の試みを提供することができます。
市場では、現在のOSS/BSSシステムが新しい仮想化ベースのサービスに適していないのではないかという疑念がありますが、事業者がこれらのシステムをリプレースするのではなく、むしろ進化させ続けているという事実も非常に示唆的です。統一データモデルと派生サービス運用モデルの組み合わせは、現在のOSS/BSSソフトウェアや慣行とのリンクを維持しながらも、仮想サービス管理に対する事業者の将来の目標とかなり一致しているようです。実際、事業者は、これらの組み合わせがTMフォーラムと自社のOSS/BSSシステムの両方に適しており、事業者にとってクラウド主導の仮想化ベースの新しい未来が到来することを期待しています。
