Delegated Agent for Network Management - エージェント指向ネットワーク管理
慶應義塾大学大学院
政策・メディア研究科
修士課程1年 89931354 木田敦子
SNMP(Simple Network Management Protocol)は,均一かつ小規模なネットワー
クを想定して1989年に標準化されたネットワーク管理プロトコルである.しか
し,開発後10余年経た今,ネットワーク構成は巨大・複雑化の傾向にある.
SNMPもv2, RMON MIB, v3などの改良や時代に即した仕様の変更が行われた,し かしながら,最も普及したのは実装の容易なv1であり,依然として,現在のネッ トワーク機器の多くがSNMPv1のみの実装にとどまっている.このような新旧機 器の混在する次世代ネットワークは,SNMPv1のみによる管理が困難になると予 測される. このような前世代のシステムとの互換性を保つために,さまざまな次世代ネッ トワーク管理手法が提案されている,またそれらのアプローチの中では特に, CORBA等の分散オブジェクト技術が,注目されている.本論文では,分散オブ ジェクト技術HORBを用いたネットワーク管理モデルMOSS(Meta Operation for SNMP Services)を提案する. MOSSは,クライアント,エージェント,管理機器から構成され,クライアント, エージェント間はHORBプロトコルを用いて通信を行なう.また,エージェントは 複数のSNMPポーリングをエージェントの存在するローカルセグメントのみで行な う.監視対象機器からの応答も,エージェント内で保存し,ポーリングの終了時 にクライアントへ監視データの転送をする.この方式により,SNMPのポーリング を行なう方式に比べてネットワーク全体に派生するトラフィックの量が削減され る.また,SNMPによる巨大で複雑なネットワーク管理における問題点の解決を行 う. 以下,はじめに,近年のネットワーク管理プロトコル技術についてのべ,次に MOSSによるアプローチにについて述べる. |
現在,多くの企業や学術組織がインターネットに接続されている.また,このネッ トワークシステムの運用の成否が組織活動のパフォーマンスに大きな比重を占 めていることは明白である.正常なネットワークシステムの運用には,定期的な 構成管理が必要とされる.従来からTCP/IPベースのネットワークでは,標準プロ トコルであるSNMP(Simple Network Management Protocol)を用い たネットワーク管理が行われている.
SNMPは,ネットワーク管理がOSIシステム管理に移行する際の短期的な解決法と して容易に実装できるプロトコルとしてデザインされた.しかし,ISOによる OSI(Open Systems Interconnection)システム管理は手法,管理情報の書式の複 雑さなどの要因により開発の進展が遅れ,その間に簡易に実装できるSNMPが広範 化するようになった.インターネットに接続される各種ネットワーク機器には SNMPが実装され,多くのルータ,ハブなどの機器はSNMPによる管理が可能である.
そして,機器情報のデータベースであるMIB(Management Information Base)の標 準化も現在行われており,ATMやFDDI用など,数多くの標準化されたMIBの仕様が RFC文書により公開されている.
SNMPは1980年代後半に提案され,1990年にRFC1157によって標準化されたネット ワーク管理プロトコルである.標準化当時のネットワーク構成は,単一セグメン トのような均一な性質でかつ小さなものであり,SNMPで十分に構成管理が行え る程度の規模であった.
しかし,LANの普及,インターネット利用者の増加に伴い,標準化された1990年 当時に比べ,想定するネットワークの形態は変化し,現在ネットワークは複雑, 巨大化の傾向にある.このようなネットワークをSNMPで管理するのは難しく,こ の困難さに対する解決方法が深刻に求められている.また,次世代のネットワー クはさらにこの傾向がさらに進むと考えられる.
このような背景から,次世代のネットワークはさらに管理が困難になると予測で きる.本研究では,電子総合研究所の平野聡博士によって作られた分散オブジェ クト技術HORB(Hirano ORB)と,ネットワーク管理プロトコルSNMPを 用いて,ネットワーク管理モデルMOSS(Meta Operation for SNMP Services)の設 計と実装を行った.
このシステムは,巨大で複雑なネットワークに対して,柔軟 で効率的な管理の実現を目標とする.本研究では,以下のアプローチに従って, 設計と実装を行った.
SNMPは1990年から10年近くにも渡る長い間使用されてきたプロトコルである.そ のため,現在インターネットに接続されている多くの機器はSNMP経由の操作が可 能であり,多くのネットワーク機器には,SNMP経由で情報取得するためのMIBが 提供されている.
したがって,本研究では,このSNMPによる操作が可能な資源の 有効利用を行うためにHORBによるSNMPの遠隔操作という形式をとる. SNMPを遠隔操作をするアプローチにより,より粒度の細かいSNMPによる管理操作 を実現できる.
SNMPは普及こそしたが,OSIによる管理システムに移行するまでの一時的なプロ トコルであったために,現在の巨大で複雑なネットワークを管理するにあたって はいくつか問題点がある.SNMPの機能改善には様々な努力がなされているが,本 システムでは,主に以下の3つの問題点を解決する.
ネットワーク管理システムの研究は多数存在する.SNMPをベースとしたネットワー ク管理については以下のような関連研究が行われている.主な研究対象は,SNMP のセキュリティ面の改良と,トラフィック削減,そして,他のネットワーク管理 システムとの統合化があげられる.
また,解決のアプローチとしては,SNMPプロトコルの標準化に於いて従来の問題 点の解決を施したもの.それと,新しく提案された管理方式の2種類があげられ る.
ネットワーク管理システムの研究として,SNMPプロトコル自身に改良が行われた 事例について説明する.
SNMPでは同じタイプの複数操作をヘッダに変数のリストを複数付加して一つのメッ セージにまとめることができる.この機能を変数バインディング(variable binding)とよぶ.変数バインディングの目的は,管理プロトコルのトラフィック の量を削減し,操作の多重化を可能にすることでより容易に管理を行うことがで きる.
変数バインディングを用いない場合,複数のオブジェクトに対して個別に GetRequestメッセージを用いて値を取得した場合に,オブジェクトごとにプロ トコルを送信しなくてはならないので,監視対象となるオブジェクトの数の分 だけGetResponseによる応答の量が増加し,ポーリングによるトラフィック量 増加の原因となる.
しかし,変数バインディング機構をもちいることで,一つのポーリングで複数 の監視対象の値を取得することができる.しかし,この機構には問題点がある. もし,バインディングリスト中に一つでも対象オブジェクトが存在しない場合 は,そのバインディングリスト全体に対してエラーが返される.したがって, 監視対象が動的に変化するものなどの監視には利用することができない.
また, このエラー処理に関しては,SNMPv2においては個別にエラーメッセージ を返すようにプロトコルの改良が行われた.
SNMPv2における最も大きな拡張の一つにGetBulkRequestと呼ばれるSNMPメッ セージがあげられる.これは大量の管理情報の取得時に必要となるプロトコル上 のやりとりを最小限に抑えることを目的にしている.SNMPv2マネージャはメッセー ジサイズの制約のなかで応答メッセージをできるかぎり大きくできる. また,GetBulkRequestは,取得を繰り返す回数をリピート変数として扱えるので, SNMPv1で,複数値の取得に用いられるGetNextRequestの再帰的呼出とことなりよ り効率的に一つのメッセージで情報取得を行える.
また,監視対象によっては,頻繁な参照を必要としないノードに対してはポーリ ングよりもむしろトラップを用いて情報取得を行う行う監視モデルもある.しか し,トラップ自体が監視対象機器への過負荷の要因になることもあり,また標準 のトラップの実装は少ない,または実装されていないことが多いため,一般的な 手法とはいえない.
Webからの可視化された環境でのネットワーク管理を円滑化するために,ネット ワーク管理に関して,WBEMなど独自のスキーマ定義に従ったのHTTP などの他プロトコルによるネットワーク管理技術も現在研究されている.
しかし,他のプロトコルを用いるとMIBの名前空間を用いることができない. WBEMではこの問題をNameSpaceと呼ばれるMIBのツリーを外部化したモデルを用い て解決を行っている.このNameSpaceは,SNMPプロトコルを用いない(ASN.1で符 合化していない)ネットワーク管理において用いられている手法である.
分散オブジェクト技術のネットワーク管理システムへの応用も盛んに行われてい る.JIDM(Joint Inter Domain Management)は,分散オブジェクト技術 CORBAにTMN(Telecommunication Management Network)とSNMPの収容 方式IDL(Interface Definition Language)定義を規定し,その提案 方式の有効性を実装を通して示している
本章では,SNMPネットワーク管理モデルを次世代のネットワークとして想定され る様な複雑巨大なネットワーク管理に移行した場合に於けるSNMPの問題点を以下 の3つに挙げ,その詳細について述べる.
|
エージェントと管理マネージャが異なるネットワークセグ メントに存在する時は,管理マネージャからのSNMP経由の操作をファイヤーウォー ルのパケットフィルタリング設定で禁止している場合がある.それは,管理機器 に対する操作が外部によって行われるだけでなく,取得情報の盗聴により,ネッ トワーク全体をダウンさせるのに十分なトラフィック量など,システム運用関し 深刻な打撃をあたえる情報を取得できるからである.したがって,通常,SNMPに よる情報取得,管理機器に対する操作は,外部の管理ドメインから行えるように は設定されてはいない.
SNMPでは先に述べたように,認証はコミュニティ名と呼ばれる機構を用いて行わ れる.SNMPはUDPベースのコネクションレスなプロトコルであるため,認証はプ ロトコルごとに行われる.また,このコミュニティ名は暗号化などをおこなわず, 平文で送信されるため,外部の盗聴者によるパスワードの取得が容易である.こ のSNMPの認証機構は,ネットワーク全体が善意の利用者によって利用されている という前提が必要とされてきた.
sending 50 bytes to 133.27.175.3:161: 0000: 30 82 00 2E 02 01 00 04 06 70 75 62 6C 69 63 A1 0........public. 0016: 82 00 1F 02 04 4E 32 25 89 02 01 00 02 01 00 30 .....N2%.......0 0032: 82 00 0F 30 82 00 0B 06 07 2B 06 01 02 01 01 01 ...0.....+...... 0048: 05 00 .. received 66 bytes from 133.27.175.3:161: 0000: 30 40 02 01 00 04 06 70 75 62 6C 69 63 A2 33 02 0@.....public.3. 0016: 04 4E 32 25 89 02 01 00 02 01 00 30 25 30 23 06 .N2%.......0%0#. 0032: 08 2B 06 01 02 01 01 01 00 04 17 53 75 6E 20 53 .+.........Sun S 0048: 4E 4D 50 20 41 67 65 6E 74 2C 20 55 6C 74 72 61 NMP Agent, Ultra 0064: 2D 34 -4 |
上はSNMPのパケットダンプである.見てわかるようにSNMPでは,認証に関して 暗号化を行っていない(イメージ中の''public''という文字列)また,取得情 報(イメージ中の''Sun SNMP Agent, Ultra-4'') もまた暗号化されずに応答さ れる.
このことから,複数のセグメントから構成されるような大規模で複雑なネットワー ク監視においてSNMPは適していない.
対象機器数,監視対象オブジェクトが多いネットワーク内で定期的にポーリング を行なうと,ネットワークトラフィック全体に占める管理プロトコルのオーバー ヘッドが高くなる.インターネットの全ての機器をポーリングによって統計情報 を集めることは管理方法としては有効だが,装置の数が多い場合に,それによっ て生じるトラフィックはネットワークが許容できない大きさになると考えられる.
また,対象機器から管理アプリケーションのホップ数が多い場合(ネットワーク 自体が巨大である)場合は,小規模なネットワークに比べ派生するトラフィック の範囲が広がると想定される.
このような巨大なネットワーク監視にもSNMPは適していない.
対象機器の情報には頻繁な参照を必要としないが重要な情報がある.そのような 情報は管理エージェントの非同期通知(トラップ)で情報の取得を行なうべきで ある.しかし対象機器への非同期通知情報定義の実装にはSNMPとASN.1(Abstruct Syntax Notation)の知識と理解が必要である.また,ルーターやハブなど,ファー ムウェア自体の書き換えを行わなくてはならない.これは通常の監視アプリケー ションをプログラムするようなプログラマには繁雑な作業である.また,SNMPで は7種類の汎用トラップが定義されている.
本稿では分散オブジェクト技術HORBを用いたネットワーク管理モデルMOSSの提案 を行なう.
MOSSは前述のSNMPネットワーク管理に於いて挙げられた3つの問題に 対し,以下のアプローチにより解決を行なう.それぞれの問題に対するMOSSのア プローチを以下に挙げる.
MOSSはクライアント,エージェント,監視対象機器から構成されるネットワー ク管理モデルである.また,前述のSNMPネットワーク管理モデル(SNMPマネー ジャ,SNMPエージェント)はこのシステムのMOSSエージェント内に包含されて いる.また,クライアントとエージェント間はHORBプロトコルで通信を行う.
MOSSは,クライアントからエージェントに対して,HORBプロトコルを使って通 信を行なう.エージェントはクライアントから送られた対象機器管理情報をエー ジェント内でSNMPプロトコルに変換し,ポーリングを行なう.
SNMPでは,管理マネージャと管理エージェントが異なるセグメントに存在する と,管理エージェント側でネットワークアクセス制限がかかり,SNMPの直接操 作ができない場合がある.しかし,HORBの認証機構を利用して,HORBプロトコ ルによるSNMPの遠隔操作を行なっているため,異なるセグメントに対しても SNMP管理ができる.
MOSS管理システムでは,クライアントがエージェントに対して,複数対象機器 の情報取得を設定した場合,SNMPのポーリングは,エージェントが存在するロー カルセグメント内のみで行なわれる様子を示している.つまり,一回のHORBプ ロトコルによる機器管理情報の送信で,複数のネットワーク機器の情報を取得 することができる.また,大規模なネットワークを管理する場合にこの方式を 採用することで,ネットワーク管理プロトコルによるトラフィックを,他のネッ トワークセグメントに派生することのない操作が可能になる.
SNMPでは非同期通知の対象となっているオブジェクトは7種類(そのうち一つ はベンダ定義のトラップ)に限定されており,他のオブジェクトへの拡張を行な うことが難しい.
にみられるようにMOSSでは,エージェントが,ローカルセグメ ント内でポーリングを定期的に行い,状態が変化したことでUpDateメッセージを クライアントに通知することができ,すべてのオブジェクトに対してトラップを 拡張することが容易にできる.
MOSSは,JAVA言語による分散オブジェクト技術HORB\cite{HORB}を用いた通信を 利用する.クライアントからネットワーク管理を行うためには,対象機器管理情 報の記述されたオブジェクトをHORBプロトコルを用いてエージェントに送信する.
つまり,クライアントは,HORBを介して間接的にSNMPのポーリングを行なう形式 をとる.また,MOSSはHORBの認証機構を用いてクライアントとエージェントが通 信を行なうため,異なるセグメントからのSNMPによる遠隔操作を禁止しているネッ トワークに対する管理を実現する.
クライアントとエージェントの認証は,HORBの分散アクセス制御機構ACL(Access Control List)を用いて行う.この分散アクセス制御リストは,クラスや,メソッ ドのアクセスが許されているホスト,ユーザを指定することができる.
HORBサーバを実行する際に,aclのリストの読み込みを行う.
クライアントは,対象機器管理情報クラスの生成と,エージェントの代理オブジェ クトの生成を行なうだけで対象機器情報の取得を行なうことができる.
また,非同期通知の場合は,クライアント側では,非同期通知を待ち,エージェ ント側では,ローカルセグメント内でSNMPのポーリングを行ない対象機器の値の 変化を調べる.
エージェント内には,クライアントからの対象機器管理情報をローカルセグメン ト内のSNMPのポーリングに変換する機能がある. 機能の主な役割は次の2つである.
対象機器管理情報は,エージェント,対象機器間でSNMPによる通信を行う際に必 要な情報である.対象機器情報の内容を以下に示す.また,次にクライアントプログラム内での監視機器情報オブジェクト(下記 の例ではInfoクラス)を以下に示す.
|
public final class Info{ public String Target = "localhost"; // hostname public String[] ObjectID = {"system.sysDescr.0"}; // object id public int Opnum = 1; // SNMP message name public String MibName = "RFC1213-MIB"; // mib name public String READCOM = "public"; // snmp authentification keys public String WRITECOM = "private"; // snmp authentification keys } |
管理ドメインを越えたネットワーク管理には,セキュリティの弱さをHORBの認証 機構を用いてセキュアなネットワーク管理環境の実現を行った.また,ポーリン グメソッドというローカルドメイン内で複数のSNMPポーリングを実行するメソッ ドを実装し,管理プロトコルのネットワーク全体への波及の削減を行った.
また,実装が困難とされるSNMPの非同期通信機構トラップに対して,ローカルエ リア内に対してポーリングを行い,変化の際にクライアントに通知を行うUpdate メッセージの実装を行い,実際にトラップを機器に実装するよりも簡易に非同期 通知機構を実装した.