test

Solstice Enterprise Agents 1.0 ユーザーズガイド

SNMP 要求の DMI への変換

SNMP マスターエージェントは要求を受信すると、そのオブジェクトが、マッパーを登録したサブツリー内にあるかどうかを判断します。そのオブジェクトがサブツリー内にある場合は、マッパーに SNMP 要求を送ります。マッパーはそのパケットを受け取ると、次の SNMP の種類に従ってパケットを解析します。

SNMP 要求の DMI への変換について、表 6-1 に示します。

表 6-1 SNMP 要求の DMI への変換

SNMP 

オブジェクト 

DMI 

データ 
{verb}{noun}{verb}{noun}
getOIDMI_cmdsID と Key
getnext  comp ID/group ID/attr ID
set/commit/undo   

構成要素、グループ、または属性のリストを問い合わせたり、個別の属性を取得 (Get) したり設定 (Set) したりするための MI コマンドを実行することによって、MIF データベースにアクセスできます。

マッパーはマスターエージェントから GET 要求を受け取ると、次の処理を行います。

  1. 変換テーブル内のエントリの有無に応じて、その要求が MIF に対するものかまたは MIB に対するものかを判断します。

  2. OID の残りの部分をパース処理することによって、妥当性をチェックします。

  3. 指定されたグループと構成要素があるかどうか変換テーブルを検索します。

  4. OID に DMI テーブルインデックスが指定されている場合は、それを DMI キー形式に変換します。

  5. DMI からオブジェクト値を検索します。オブジェクト値が見つかると、サブエージェントはそのオブジェクト値をエージェントに渡します。

GETNEXT 要求の処理中に、サブエージェントは、字句解析上の順序が維持されていることを確かめる必要があります。SMI オブジェクトとして返される属性を検出するまでに、MIF データベースの検索規模がかなり大きくなることがあります。その属性に固有なエラーなどの小さなエラーが原因で、目的の属性の値が利用できないときは、/RFC1448/ によって規定されている genErr が返されます。次のオブジェクトがサブエージェントのツリーになければ、その要求と同じオブジェクトのインスタンスとともに、値 noSuchName が返されます。

DMI 属性の識別子は、一意の OID にコード化されます。DMI テーブルのオブジェクトにアクセスしたり、DMI テーブルの行を識別したりするときは、INDEX 句を使います。GETNEXT の実行中に DMI テーブルの属性を検査するときは、すべての行識別子 (キーの値) を調べることによって、属性の字句解析上の順序を保ちます。

マスターエージェントによる SET 要求の処理は、GET 要求よりも少し複雑です。通常のコマンドシーケンスでは、GET コマンドの次に SET コマンドがマスターエージェントから送信されます。渡された SNMP PDU に対し、SET コマンドを全部完了できなかったときは、別の SET コマンドをサブエージェントに送信します。この SET コマンドには、GET コマンドから得られた oi.d 値が指定されます。サブエージェントは SET コマンドを受信すると、いくつかの基本的なチェックを行います。基本的なチェックとは、オブジェクトとインスタンスの存在、値のデータ型、有効な内容、操作に必要とされるメモリーの有効性のチェックなどです。この時点で、属性を保持 (RESERVE) するための DmiSetAttribute() による DMI の呼び出しが完了します。RESERVE を使うと、SET を実行しなくても SET の妥当性チェックを行うことができます。RESERVE が失敗すると、マスターエージェントに genErr が返されます。RESERVE が成功すると、サブエージェントは DmiSetAttribute() に SET オプションを指定して実行することによって、実際に属性を設定します。

別のサブエージェントが、その PDU の SET は実行できないということを SNMP エージェントに通知した場合は、SNMP エージェントは既存の値を使ってマッパーに SET を渡します。

例外の報告

マスターエージェントのトラップ PDU を作成し、そのトラップをマスターエージェントに送信することによって、マッパーがマスターエージェントにトラップを報告します。

トラップは、DMI SP から発行される要求外通知メッセージによって発生します。このメッセージはインジケーションの 1 つです。構成要素から送られたインジケーションは、「イベント」と呼ばれます。マッパーは、SP の登録テーブルにエントリを追加することによって、SP に登録したあと、すべてのインジケーションを受け取ります。また、マッパーは、すべての種類のイベントを受け取るためにフィルタの条件を設定します。マッパーはエージェントからの要求をすでに待っているため、このルーチンは個別のスレッドになります。サブエージェントが、トラップと共に送る OID を決めます。インジケーションには、次のようなさまざまな種類のものがあります。

サブエージェントの停止

通常、snmpXdmid デーモンは、明示的に停止されたり、メモリー資源不足のような致命的な状況に遭遇したりしないかぎり、永続的に動作します。

MIF から MIB へのマップ

MIF から MIB へのマップでは、MIF から OID を割り当てる必要があります。トランスレータ (miftomib.EXE) によって、MIF 定義から拡張子が .MAP と .MIB のファイルを構築できます。このトランスレータを、.MIB と .MAP ファイルを生成するためのツールとして使うこともできます。また、テキストエディタを使って手動でマップファイルを生成することもできます。/var/dmi/map の下のディレクトリにあるすべての .MAP ファイルは走査され、サブエージェントの変換テーブルに取り込まれます。

図 6-2 MIF から MIB へのマップ

Graphic

マップファイルの書式を、表 6-2 に示します。

表 6-2 マップファイルの書式

OID 接頭辞 

構成要素名 

"1.3.6.1.4.1.42.2000.2" 

"Client Access/400 Family - Base Product" 

DMI のコンポーネント ID、グループ ID、および属性 ID を MIB のオブジェクト ID にマップすることを目的として設計されています。管理するエンティティでは、マッパーが MIF 定義へのマップに使用する MIB 定義をあらかじめ定義しておく必要があります。miftomib トランスレータを使って MIB マップファイルを生成すると、マップが容易になります。

マップファイルは、マッパーの外部に生成されます。新しい MIF 定義を動的に追加できるようにするには、システムの新しいファイルまたは更新されたファイルについてマッパーに通知するための機構が必要です。これは、マッパーがすべての .MAP ファイルを読み込み直すときに、dmispd によって生成された DmiGroupAdded インジケーションを使うことによって実現されます。

OID 接頭辞と、完成した OID レイアウトの例については、図 6-3 を参照してください。マッパーはマップファイルを使うことによって、OID を SNMP エージェントの中継に登録したり、OID を構成要素名と相互に関連付けたりします。グループに表形式のデータが含まれている場合は、マッピングファイルにコンポーネント ID とグループキーが含まれています。

マッパーでは、OID 接頭辞に制限はありません。OID 接頭辞は、ネットワーク管理者によって制御されます。SNMP マスターエージェントでサブツリーの登録ができるときは、.MAP ファイルにどんな OID を登録してもかまいません。OID の登録に失敗したときは、OID を修正するために .MAP ファイルを変更する必要があります。

図 6-3 MIB OID レイアウト

Graphic

オブジェクト識別子を構成する部分を次に示します。

クライアントのアクセス属性(キーなし）に対する OID の例を次に示します。

MIB テーブルではカラムからカラムに渡って検索が実行され、MIB テーブルでは行から行に渡って検索が実行されるため、GetNext の操作によってオブジェクトを検索するときは注意が必要です。

特殊なマップの考慮事項

DMI の仕様では、DMI SP に対して ComponentId=1 を予約しています。また、この仕様は、SP の MIF ファイルも定義します。.MAP ファイルを作成したり、miftomib ユーティリティにのコマンド行パラメタとして OID 設定を指定したりするときは、ネットワーク管理者はこれを考慮する必要があります。すべての MIF ファイルには、ID 1 の標準グループを含める必要があります。

表 6-3 DMI MIB に変換される ComponentID グループ

MIS オブジェクトの識別子と構文 

MIF データ 

説明 

注 

DMIcompindex

INTEGER (1...217483647) 

コンポーネント ID 

構成要素の一意の値 

SP によってインストール時に割り当てられる。インストールが解除されるまで、SP はこの構成要素とやりとりする。管理アプリケーションは、あとで属性を要求するためにこの ID を記録する 

DMIcompManufacture

DisplayString (0...64) 

属性「Manufacture」 

コンポーネントプロバイダによって割り当てられる値 

この構成要素を作成した組織の名前 

DMIcompProduct

DisplayString (0...64) 

属性「Product」 

コンポーネントプロバイダによって割り当てられる値 

構成要素の名前 

DMIcompVersion

DisplayString (0...64) 

属性「Version」 

コンポーネントプロバイダによって割り当てられる値 

構成要素のバージョン 

DMIcompSerialnumber

DisplayString (0...64) 

属性「Serial Number」 

コンポーネントプロバイダによって割り当てられる値 

構成要素のシリアル番号 

DMIcompInstallation

Date 

属性「Installation」 

インストール時に SP によって割り当てられる値 

日付と時刻から成る 28 オクテットの表示可能文字列 

DMIcompVerify

Integer (0...7) 

属性「Verify」 

インストール時のこの構成要素の検査レベル 

この属性を要求すると、構成要素がまだシステム内にあり、正しく動作しているかどうかが調べられる 

このマップを使うと、DMI を使ってインストールされる MIF は、管理アプリケーションに表示できる最小限の ComponentID グループを持つだけで済みます。このグループ内の属性はすべて、読み取り専用のアクセス権を持ちます。MIF が基準となって MIB に変換されると、グループ内の属性にアクセス可能となりますが、DmtfGroups ツリーにアンカーポイントが付きます。たとえば、ソフトウェア MIF が定義されていると、変換によって DMISW MIB が作成され、次のようにアンカーポイントが付けられます。 

enterprise.sun.DmtfGroups.DMISW(2)

あるいは、次のようになります。

1.3.6.1.4.1.42.2000.3

管理アプリケーションでは、同じ構成要素が、DmtfGroups ツリーの 2 つの異なる枝に表示されるように設定されている必要があります。

追加の OID 接頭辞は、次のとおりです。