NETCONF と YANG が必要な理由

Tomas Hedqvist

Managing network devices using NETCONF and YANG
画像をクリックすると拡大します

デバイスはどのように管理していますか? まだ CLI やスクリプトをお使いですか? それとも、NETCONFREST を検討中ですか?

今日、マネジメント・インターフェースには多種多様なオプションがあります。優れたものもあれば、そうでもないものもあります。ネットワーク・マネジメントを自動化したい、あるいはマルチベンダー・ネットワークでデバイスを管理したいとお考えならば、適切なマネジメント・プロトコルを選択することで多くのメリットを得ることができます。さらに、VNF (バーチャル・ネットワーク・ファンクション) も管理したい、SDN (ソフトウェア・ディファインド・ネットワーク) や NFV (ネットワーク・ファンクション・バーチャライゼーション) のメリットを活用したいとお考えならば、最新の標準化されたマネジメント・プロトコルがふさわしいでしょう。

NETCONF と YANG が必要かどうかを判断し、どのネットワーク・インターフェースを選択すべきかを把握するために、次の 4 つの質問にお答えください。

1 - ネットワークを設定する必要があるか?それとも、設定するのはデバイスのみか?

せいぜい数十台程度のデバイスから成る超小規模ネットワークでは、デバイスを 1 台ずつ管理してもさほど大きな問題にはなりません。しかし、ネットワークの規模が大きくなり、数万台のデバイスを管理するとなると、そうはいかなくなります。 従来からこの問題への対応に使われてきたスクリプトは、実は信頼性がそれほど高くなく、標準化もされていません。

設定を変更する場合には、トランザクションを用いるのが最も有効な方法です。トランザクションを使用することにより、変更のシーケンスを含む設定全体を適用するか、それとも完全にロールバックすべきかを確認することができます。言い換えると、設定の変更が半分だけ行われるようなことはありません。

REST API は、特にクラウド・サービスに接続されている場合にマシン・コミュニケーションで能力を発揮するため、オーケストレーションとの統合に適しています。しかし、トランザクションを提供しないため、デバイス・マネジメントには最適とは言えません。

一方、NETCONF はデバイス設定を目的とし、ネットワーク全体にわたるトランザクションを提供しているため、ネットワーク内にあるすべてのデバイスの設定を一度に変更することができます。変更はすべてのデバイスに引き継がれるか、どのデバイスにも一切引き継がれないかのどちらかになります。このようにして、すべてのデバイスに必ず同じ設定されます。

2 - 標準化されたマネジメント・インターフェースが必要か?

ほとんどのネットワーク、特に大規模ネットワークは、さまざまなベンダーから提供されたデバイスで構築されています。当然ながら、標準化すれば、こうしたマルチベンダー・ネットワークのマネジメントは容易になります。

標準化は、データ・モデルから始まります。例えば、標準化されたモデリング言語である YANG は、NETCONF インターフェースでも、REST インターフェースでも使用可能です。YANG は、デバイスの記述について標準化された方法を提供するため、設定データと状態データの両方をモデリングできます。このモデルからノースバウンド・インターフェースを自動的にレンダリングすることで、デバイスとマネジメント・エンティティの間の一貫性を確保しています。

ただし、REST は単一の標準化されたプロトコルではなく、アーキテクチャ型のスタイルであるため、すべての REST API は同じ原則とガイドラインに従いますが、本質的にはプロプラエタリな手法です。

一方、NETCONF は、広く採用されている IETF ( Internet Engineering Task Force) 規格です。多くのサービス・プロバイダやネットワーク・オペレータにとって、ネットワークにインストールするデバイスは、NETCONF と YANG を使用して管理できることが必要条件となります。

3 - 障害が発生しない堅牢なマネジメントが必要か?

すでに述べたとおり、NETCONF はトランザクションを使用して変更を設定することで、ネットワーク・マネジメントをより堅牢なものにしています。

NETCONF と YANG のもう一つの特長は、ネットワーク・マネージャーがデバイスに対して加えた変更の順序を追跡する必要がなくなる点にあります。そのため、誤った順序で変更がコミットされ、デバイス内で障害が発生するリスクが最小限に抑えられます。

また、YANG でモデリングしたデバイスに制約やデータ検証ルールも含めることにより、検証を自動化できます。この機能は、モデル自体の検証にとどまらず、入力したデータについてもデバイスに反映する前に検証できるので重要です。

NETCONF は、設定データストアの概念を基に設計されているため、ロールバックが可能であるのはもちろんのこと、誤った設定変更によりデバイスとマネジメント・エンティティとの間の接続が失われた場合には、ロールバックを自動的に適用することも可能になります。

4 - 自動化が必要か?

仮想化されるネットワーク・ファンクションが増えるにつれ、デバイスの数や場所はスタティックではなくなります。仮想デバイスを手動で設定しなければならないとしたら、仮想化で最初に求めていたアジリティのほとんどが失われることになります。ただし、物理デバイスにおいても自動化は重要です。

マネジメントを自動化すれば、OPEX の削減とアジリティの向上を両立させることができますが、CLI は人力に頼るものであり、自動化ではないことを思い出す必要があります。自動化には、デバイスをプログラマブルにするための API が必要です。この API は、YANG モデルにより提供され、NETCONF または REST API を介してアクセスされます。YANG は、標準化されたモデリング言語であることから、かなり高レベルの自動化により、マルチベンダー・ネットワークを管理できます。

REST は、本来マネージド・デバイス側ではなく、クラウド側にあるため、各種クラウド・サービスとの統合性が高く、オーケストレーションとの統合に適しています。EMS (エレメント・マネジメント・システム)/NMS (ネットワーク・マネジメント・システム) からのサウスバウンドである NETCONF も選択肢として悪くはありませんが、ノースバウンドの REST が最良の選択肢となります。

ではどうすればよいか?

ネットワーク・デバイス・マネジメント・インターフェース用ソフトウェアについてさらに理解を深めるには、『Selecting NETCONF/YANG Management Interface Software』(NETCONF/YANG マネージメント・インターフェース・ソフトウェアの選択) をぜひご一読ください。