目次 表示
NeDiはスイッチやルータのようなネットワークを構成するデバイスを管理するためのオープンソースツールキットで、GroundWork Network Management Suite(NMS)のオプションコンポーネントとしてGroundWork Monitorに統合されてます。GroundWorkのNMS NeDiパッケージがインストールされると、”NeDi”のメニューがメインのドロップダウンメニューに現れます。
簡単に言うと、NeDiはルータやスイッチのような構成デバイスを管理するための統合されたツールキットです。GroundWork Monitor内のほとんどのコンポーネントがネットワーク上のデバイスを監視(ホスト上の利用可能なリソースを計測し、条件を満たせばアラームを生成する、といったような)する目的でデザインされていますが、NeDiは管理者が特定の構成デバイスを管理すること(ネットワークトポロジへの検出や監視の変更、ネットワーク上のスイッチとルー他の構成設定の操作など)をサポートするためにデザインされています。
より具体的に言うと、NeDiはネットワーク上の構成デバイスの場所を特定するために、色々な検出技術を使用し、プローブするために別の技術を使用して詳細を得るために検出したデバイスに問い合わせを行い、最終的にはダイナミックデータベースに検出したデータを保存します。そこから、管理者はネットワークデバイスとそれぞれの関係についての情報の表示、基本的な管理タスクのいくつかの実行、そしてネットワーク上の予期しない変更に対するアラートなどを行うためにNeDiのWebインタフェースを使用することができます。NeDiはまた設定のバックアップと編集ツール、デバイス管理機能セットをより特化したインベントリの管理機能を提供します。
このドキュメントは基本設定とNeDiの操作について述べています。より詳しい情報については オンラインの NeDi セットアップドキュメント とオンラインの NeDi GUI ドキュメント.を参照します。
GroundWork NMS NeDi パッケージは、GroundWork Monitor 、他のアプリケーションから独立してインストールされ、また固有の構成設定プロセスも持っています。
NeDiとNMSアプリケーションのほとんどはGroundWork Monitorによって使用されるサーバとは別に特化したアパッチサーバを使用するWebベースのアプリケーションとして組み込まれています。そのApcheサーバはNeDiのWebページにアクセスする前に起動する必要があります。Apacheサーバは /etc/init.d/nms-httpd を使用して、起動・停止が行われます。初期設定ではこのスクリプトはシステムの起動時に自動的に実行されます。
NMSに特化したApacheサーバを手動で停止するにはルート権限を持つユーザでログインし、以下のコマンドを実行します:
/etc/init.d/nms-httpd stop
NMSに特化したApacheサーバを手動で停止するにはルート権限を持つユーザでログインし、以下のコマンドを実行します:
/etc/init.d/nms-httpd start
NMSに特化したApacheサーバが自動的に起動するのを防ぐ場合はルート権限を持つユーザでログインし、以下のコマンドを実行します:
chkconfig --del nms-httpd
スクリプトを再度有効にするには、ルート権限を持つユーザでログインし、以下のコマンドを実行します:
chkconfig --add nms-htppd
NeDiのWebのフロントエンドはGroundWork Guavaの使用によってGroundWork Monitorに統合されていますがNeDiのWebページはNMS特化のApacheのインスタンスによって提供されます。つまり、NeDiにアクセスできるパーミッションを持つ適切なロールを持つユーザはGoundWork Monitorにログインし、アプリケーションランチャーからNeDiを選択することでNeDiにアクセスすることができます。
しかしながら、NeDiは独自のユーザアカウントとアクセスコントロールを持ち、それはGroundWorkのコントロールから独立しています。具体的に言うとNediはユーザネーム”admin”、パスワード”admin”という設定墨の管理者アカウントのみ持っています。それ以上に、ビルドインのWebページのほとんどは無制限であり、認証を必要とされません。NeDiのWebサーバや他のページへのアクセスを制限したい場合はNeDi内で適切なユーザコントロールとアクセスコントロールを作成する必要があります。
このプロセスはGroundWork Monitorのメインメニュー内にあるどのユーザがNeDiにアクセスさせるかを決めるプロセスとは別のものです。NeDiのメインメニューへのユーザアクセスの設定についての情報は管理者ドキュメントの”ロールの設定”セクションを参照します。
GroundWork NMSのNeDiパッケージはユーザがGroundWork Monitorを通じて最初にNeDiにアクセスすると自動的にNeDiにユーザアカウントを作成する技術を含んでいます。つまり、ユーザが他のページへアクセスするためにNeDi内でユーザを明示的に作成する必要はありません。しかし、時々ユーザアカウントを直接管理する必要があります。
NeDiのユーザカウントを管理するには管理者権限でNeDiにログインし、画面上の”User”メニューにマウスを移動し、”Accounts”メニューアイテムでクリックをします。すると、以下のように現在定義されているユーザアカウントがリストアップされた画面が表示されます:
新しいユーザアカウントを追加する場合は右上にある”User”のボックスに希望するユーザ名を入力して、その隣にある”Add”ボタンをクリックします。新規ユーザがリストの下にある状態で現在の画面がリロードされます。
一度、ユーザアカウントが作成されると”Groups”カラムにある小さなアイコンをクリックすることで、そのアカウントは定義されたNeDiグループに関連さえることができます。NeDiグループについての詳細な情報は下のアクセスコントロールの管理セクションを参照します。
希望するアカウントの右にある鍵のアイコンをクリックすることでユーザのパスワードをリセットすることも可能です。これはユーザの現在のパスワードを削除し、該当のユーザアカウントによってリセットされるまで空の状態になります。
パスワードやフルネームといったユーザ固有の詳細を変更する場合はそのユーザアカウントでGroundWork Monitorへログインし、メインメニューからNeDiへ移動して画面上の”User”メニューを選択し”Profile”メニューをクリックします。すると以下と同じような現在のユーザのアカウントの詳細についての画面が表示されます:
E-mailと電話番号のフィールドはアラートオペレーションの際に使用され、NeDiのアラートをユーザが受け取る場合は定義される必要があります。このユーザをそれらのアクティビティからはずしたい場合は関連するグループから削除するか連絡先データを削除する必要があります。
ユーザアカウントを削除するにはメインのユーザアカウントページに戻り、削除を希望するアカウントの右にある赤い”X”のアイコンをクリックします。削除の確認が表示されます。
NeDiのアクセスコントロールは基本的にグループベースのアクティビティフィルターでフィルターされます。特定のグループに属するユーザは自動的にそのグループに関連するWebページへのアクセスが許可され、そのグループと自動的につながるタスクのいくつかにも関連します。例えば、NeDiはクリティカルなイベントが検出されると、監視部ループのメンバーにe-mailとSMSメッセージを送るデバイス監視スクリプトを提供します。
定義済みのNeDiのグループは以下です:
Admin -このグループメンバはメニューアイテムとセッティングとデバイスを編集するWebページにアクセスができます。これはユーザアカウントの追加と削除、デバイス監視のコントロール、構成デバイスに対する生のコマンドの発行や他の可能性のある破壊的にタスクの実行する機能を含みます。
Network - このグループのメンバーはDevicesとToporlogyメニュー、関連するWebページへのアクセスが可能になります。
Helpdesk - このグループのメンバーはNodesとそれに関連するWebページにアクセスすることが可能になります。
Monitoring -このグループのメンバーはMonitoringと関連するWebページへのアクセスが可能で、監視プロセスによってクリティカルイベントが検知されると通知がなされます。
Manager -このグループのメンバーはReportsと関連するWebページへのアクセスが可能になります。
Other - このグループのメンバーはOtherと関連するWebページにアクセスすることが可能になります。
アカウントのグループメンバーシップを編集するには画面上の”User”にマウスを移動し、”Accounts”をクリックします。現在定義されたユーザアカウントが表示されたら、アカウントを有効/無効にするために”Groups”カラムにある適切な小さなアイコンをクリックします。マウスのそのグループのヘルプ情報をえるためにカーソルをアイコンの上に持っていくこともできることに注意します。
あるグループに特定のモジュールが使えるよう変更をしたい場合は、後で紹介されるnedi.confファイルを編集することによって可能になります。
先に述べたようにNeDiはネットワーク上の構成デバイスの位置を特定するために色々な検出技術を使用します。一般的にはNeDiはまず、1つ以上のスタートデバイスの位置の特定を試み、その後近隣のデバイスを特定するためにある検出方法を使用します。このアプローチはNeDiが立ち上がりと起動をすばやく行うと同時にネットワークの総合的なマップを作成することが可能になります。
検出プロセス自身はスクリプトへのコマンドラインパラメータとして特定される検出技術とともに /usr/local/groundwork/nms/applications/nedi/seedlist perl スクリプトによって実行されます。
NeDiによってサポートされる検出技術は以下のとおりです:
静的なシードリスト - 管理者が1つ以上の検出スタートデバイスを手動で特定する必要がある場合、それらは”seedlist”ファイルで箇条書きにすることができます。初期設定のシードリストファイルは/usr/local/groundwork/nms/applications/nedi/seedlistですが、必要であれば異なったファイルも-uで引数として特定されます。
デフォルトゲートウェイ -シードリストファイルが定義されていないあるいはエントリを含んでいない場合、NeDiは現在のホストに対するデフォルトゲートウェイデバイスの位置を特定し、そのデバイスのIPアドレスを間接的なシードリストとして使用します。
Cisco Discovery Protocol (CDP) - CDPはCiscoによって開発された色々なレイヤ2のネットワーク上でCiscoのデバイス同士がお互いの位置を特定することを可能にしたプロプラエタリな検出技術です。結果として、CDPが可能なデバイスは他のCDPが可能なデバイスに気づくことができ、もしネットワーク上のほとんど、あるいは全てのデバイスのCDPが可能であれば、ネットワークマップを提供することが可能です。CDPによる検出方法は-cオプションで有効です。
Link Layer Discovery Protocol (LLDP) - LLDPはIEEEによって管理されている標準化されたレイヤ2の検出技術です。CDPと同じですが、より広い範囲のメーカーの構成デバイスで実装されています。LLDPによる検出方法は-lオプションで有効です。
OUI Discovery - OUI ディレクトリは、"-o" コマンドラインパラメータとともに有効です。NeDiが一度デバイスの位置を特定すると、そのデバイスのARPテーブルエントリに対して問い合わせをするためにSNMPを使用することができます。もし、OUI検出が可能であれば、NeDiはいくつかの既知のネットワーク設備ベンダーに属するネットワークハードウェアアドレスに対してARPテーブルを検査し、それらのシステムを使用して検出を続行しようとします。OUI検出は-oオプションで有効です。
Route Table Discovery - NeDiが一度デバイスの位置を特定すると、そのデバイスの上のルーティングテーブルに対して問い合わせをするためにSNMPを使用することができます。もし、ルートテーブル検出オプションが有効であれば、NeDiは戻ってくる次のホップのルータで検出の続行を試みます。ルートテーブル検出は-rオプションで有効です
もし、あるデバイスが上述の検出方法で検出がされない場合、それがシードリストにリストされていない限り検出されません。例えばCDPやLLDP対応ではない小さなルータで初期のOUI検出にも一致しない場合、検出される必要があればシードリストファイルで特定する必要があります。
検出プロセスをデバックする必要がある場合、nedi.plスクリプトを直接起動して、異なる検出方法の結果を確認します。しかしながら、スクリプトはファイルとデータベースのパーミッションが変更されていないことを確認するため、ユーザnagiosで実行される必要があります。したがって、GroundWorkサーバにターミナルでログインし、スクリプトを実行する前にユーザnagiosにスイッチするために”su nagios”を使用します。必要であれば、デバックと詳細なレスポンスを有効にするためにnedi.plスクリプトに-dや-vオプションをつけることも可能です。
GroundWork NMS NeDiのパッケージは自動的にnedi.plスクリプトにユーザアカウントnagiosのctontabファイルに追加し、それをCDP,LLDP,OUIによる検出方法が可能な状態で毎4時間ごとに起動するようスケジュールします。(別のcrontabが設定のバックカップを作成するために真夜中に起動し、以下の様に分かれてドキュメント化されます。)この動きを編集するために以下のステップを実行します:
root権限でGroundWorkサーバにログインします。
コマンドプロンプトからnagiosアカウントに関連するcrontabファイルを編集するために"crontab -u nagios -e"のコマンドを実行します。
"nedi.pl -clo"のcrontabエントリの位置を特定し、必要であれば編集を行います。スケジューラーの時間の間隔を変更した場合はNeDiに新しい間隔を通知することでグラフが正しい時間で表示されます。これを行うためには、/usr/local/groundwork/nms/applications/nedi/nedi.conf ファイルをテキストエディタで開き、"rrdstep"の値を新しいものにセットし、ファイルをセーブします。
Crontabファイルをセーブしてエディタを終了します。Cronデーモンは自動的に新しいパラメータを現在のスケジュールに組み込みます。
もし、シードデバイスを手動で定義したい場合は初期設定の/usr/local/groundwork/nms/applications/nedi/seedlist ファイルを使用するか、独自のシードリストファイルを定義してもかまいません。もし、独自で定義する場合はnedi.pl検出スクリプトに-uパラメータと上述の crontab エントリにファイルのパスを追加する必要があります。シードリスト内のエントリにはスタートデバイスのIPアドレスあるいはホスト名、あるいはSNMPのコミュニティストリングが入っている必要があります。SNMPのコミュニティが定義されていない場合は ned.conf からのSNMPコミュニティストリングは、/usr/local/groundwork/nms/applications/nedi/seedlistになります。
新しく検出されたデバイスをプローブするためにNeDiによって使用されたSNMPコミュニティストリングは、 /usr/local/groundwork/nms/applications/nedi/nedi.conf 設定ファイル内の”comm.”エントリによって定義されます。複数の”comm.”エントリは行ごとのエントリと値で定義され、それぞれは全ての検出されたデバイスに成功した順番で試みます。
By default, the GroundWork NMS NeDi package defines the single community string value of "public".
初期設定ではGroundWork NMS NeDiパッケージは”public”を単一のコミュニティストリングとして定義しています。
注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。Nefi.confファイルを編集する際、このシンタックスを使用する必要があります。
先に述べたように、デバイスの構成設定ファイルのいくつかはそのデバイスにログインし、TELNETかSSHを通してコマンドを発行することで取得されます。NeDiがこのタスクを実行するためにはデバイスに対する認証に使用するログインの証明が提供される必要があります。
使用する認証の証明は、 /usr/local/groundwork/nms/applications/nedi/nedi.conf ファイル内の”usr”エントリで定義されます。それぞれの”usr”エントリは1つから3つのフィールドを含んでいます。:1つ目のフィールドはユーザ名を特定し、2つ目はアクセスパスワード、3つ目はCiscoのデバイスに追加のアクセスする際に使用される有効なパスワードを含んでいます。複数の”usr”エントリは行ごとのエントリで定義され、それぞれは全ての検出されたデバイスに成功した順番で試みます。
初期設定ではGroundWork NMS NeDiパッケージは”usr”エントリを定義しません。
注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。nedi.conf ファイルを編集する際、このシンタックスを使用する必要があります。
NeDiがローカルの検出に使用する技術はネットワークの外側にあるデバイスも検出することができ、NeDiが強制的にあるネットワークからブロックされない限り、インターネット全体を検出しようとります。NeDiのIPアドレスによる検出の制限の主な方法は、/usr/local/groundwork/nms/applications/nedi/nedi.conf ファイルにある”netfilter”エントリです。この値は検出されたIPアドレスと比較した正規表現であり、NeDiはその正規表現と一致しないIPアドレスを破棄します。
例えば、192.168.1.*のネットワークでNeDiにIPアドレスの制限をかけたい場合、netfilterエントリに"^192\.168\.1"の値を定義することができます。一方で例えば、192.168.1.*と10.*.*.*のネットワークでNeDiにIPアドレスの制限をかけたい場合"^192\.168\.1|^10\."の値をnetfilterエントリに定義することが可能です。Netfilterの値に一致しないアドレスが検出された場合は、破棄されます。
初期設定ではGroundWork NMS NeDiパッケージはアドレスフィルターを全てのIPが一致する”.”を定義しています。
注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。nedi.confファイルを編集する際、このシンタックスを使用する必要があります。
OUIによる検出を使用している場合、 /usr/local/groundwork/nms/applications/nedi/nedi.conf ファイル内の”ouidev”エントリを編集することでNeDiが使用するハードウェアアドレスに制限を変えることができます。このエントリの値は検出されたハードウェアアドレスの名前と比較される正規表現であり、NeDiはその正規表現と一致しないハードウェアアドレスを破棄します。親密性のあるハードウェアアドレスは、/usr/local/groundwork/nms/applications/nedi/inc/oui.txtファイルにリストアップされています。
初期設定ではGroundWork NMS Nediパッケージは"bay|nortel|netics|xylogics|foundry|XYLAN|Netgear|RUBY"のフィルターを定義しており、検出されない可能性があるプラットフォームよりはより一般的なものです。
注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。nedi.confファイルを編集する際、このシンタックスを使用する必要があります。
NeDiがネットワークデバイスを検出する際に使用する技術は(プリンターなど)構成デバイスとは関連しないデバイス、無視したいデバイスも検出することもあります。NeDiのプラットフォームを制限する検出は/usr/local/groundwork/nms/applications/nedi/nedi.confファイルの”descfilter”にあります。このエントリの値は検出されたデバイスのSNMPストリングと比較される正規表現で、NeDiは正規表現と一致しないデバイスを破棄します。
初期設定ではGroundWork NMS Nediパッケージはプラットフォームフィルターを"LaserJet|JETDIRECT|HP-UX|Linux"と定義しており、それはほとんどのプリンターと、別途の構成デバイスとして検出されるかもしれないUnixプラットフォームと一致します。
多くの小さいルータがLinuxをOSとして使用しており、初期設定のフィルタストリングは検出から自動的にそれらのデバイスを除外します。検出プロセスにおいて検出されたいデバイスがある場合、ストリングから"|Linux"の部分を削除指定ください(デバイスを検出させるためにシードリストファイルにデバイスを加える必要があるかも知れません)。
注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。nedi.confファイルを編集する際、このシンタックスを使用する必要があります。
NeDiが検出した構成デバイスを持つと、そのデバイスについての追加情報を得るため色々な問い合わせを使用します(これはインストールされたモジュールや使用中のVLANなども含みます。)。しかし、ベンダは異なった位置にこの情報を保存しており、NeDiがこのデータの引き出し方を知るためには最初にデバイスのタイプを特定できなくてはなりません。
これはデバイスの”System Object ID”についてSNMPによる問い合わせを行い、結果をデバイスの定義ファイルと一致させることでなされます。基本的にデバイスの定義ファイルは特定のデバイス上の利用可能な機能についてのもので、そのデータに対してNeDiが問い合わせる必要のある情報をNeDiに提供します。これはデバイスのアイコンとOSのような高度なデータ、CPUとメモリ稼働率についてSNMPのOIDへの問い合わせのような管理データ、そしてインタフェースの詳細のVLANの識別についてSNMPのOIDへの問い合わせのような別々のデータを含みます。
GroundWork NMS Nediパッケージではデバイスの定義ファイルは、 /usr/local/groundwork/nms/applications/nedi/sysobj/ ディレクトリに保存されています。それぞれの聞き定義は既知のSNMP OIDの値で別のファイルで管理されます。NeDiでは150以上の聞き定義ファイルが提供されていますが、これは全てのデバイスの完全なコレクションではなく、古い、あるいは無名のデバイスと統合するためには独自の定義ファイルを作成する必要があるかも知れません。
独自のデバイス定義ファイルを作成したい場合、そのデバイスに良く似た既存の定義をコピーして、編集するか(同じHP ProCurveスイッチの定義をコピーして異なったSNMP OIDのファイル名にする)Webベースの”Defgen”ツールを使用してスクラッチから新しいファイルを作成するかのどちらかです。
Defgenツールを使用するには画面上部に”Other”にマウスを移動し、”Defgen”をクリックします。 フォームが埋められたら、あたらいいデバイス定義ファイルを自動的に作成するために”Write”ボタンをクリックします。
Defgenによって作成されたファイルは自動的に、 /usr/local/groundwork/nms/applications/nedi/html/log/ ディレクトリに保存され、ファイルはnedi.plスクリプトに使用される前に /usr/local/groundwork/nms/applications/nedi/sysobj/ ディレクトリへコピーされる必要があります。Nedi.pl検出スクリプトは検出プロセスが起動するたびにデバイスの定義ファイルを読み込むので、なされた変更はデバイスが検出された自動的に次回更新されます。動作を適切に行うために、このディレクトリにあるファイルはnagiosのユーザアカウントによって読み込みが可能である必要があります。
イントロダクションで記述したように、NeDiはネットワーク上の構成デバイスの位置を特定するために色々な検出方法を使用し、検出したデバイスの追加情報をプローブし問い合わせるために別の方法を使用し、そしてNeDiのWebインタフェースを通じて管理者に利用できるダイナミックデータベースの中に検出したデータを保存します。
もっとも多く使用されているWebページの簡単な記述がこのセクションの残りで提供されます。より詳しい情報については、オンライン NeDi ドキュメント オンラインのNeDiドキュメントを参照します。NeDiのWebページのそれぞれがページの右上にある救命具のアイコンをクリックすることでアクセスが可能なヘルプを提供します。
リストビューを提供する全てのNeDiのWebページは最初にユーザがリスト結果で戻ってくるデータ量を制限することが可能なサーチフィルタダイアログが表示され、それはサーチ結果に含みたいフィールドを特定することが可能になります。特定のサーチフィルタはそれぞれのフィールドに対して別のものですが、一般的に以下と同じようなものです:
期設定のサーチフィルタは何もフィルターしないので、サーチ結果を制限したくない場合は単純にダイアログの右にある”Show”ボタンを押下すると現在のリソースタイプの既知のエントリが表示されます。
結果をフィルターしたい場合、サーチフィルタダイアログは二つの異なったフィルターを定義することが可能です(上にあるような”Condition A”と”Conditon B”です)。それはまた、ある方法で統合することが可能です(これは”Combination”インプットで管理されます)。初期設定では”Condition A”のフィルターは空で(つまり全てのエントリに一致します)、”Condition B”のフィルタは完全に無視されます(これは”Condition A”のみ表示している”Combination”のインプットで示されています)。
サーチフィルタのクライテリアとは別にダイアログボックスは現在のリソースタイプのための既知のデータベースフィールドのリスとボックスを持っており、ユーザが戻ってくるフィールドを決定することが可能です。フィールドの初期の設定はそれぞれのリソースタイプによって異なります(例えば、構成デバイスの検索はVLAN検索とは違うフィールドが戻ってきます)。
NeDiは検出した構成デバイスのシンプルなテーブル表示を提供し、ネットワーク構成をすばやく調査することができます。このデータを表示するには画面上の”Device”にマウスを移動し”List”をクリックします。検索と表示フィルターの使用セクションで記述されていたものと同じような検索画面が表示され、適用したフィルターに定義することが可能になります。検出された全ての構成デバイスを表示したい場合、単純に右にある”Show”ボタンをクリックすると、以下と同じようなサーチフィルターの下に新しいテーブル内にリストアップされた既知のデバイスを表示した画面がリロードされます:
初期設定ではNeDiは検出された構成デバイスに対して以下のデータを表示します:
デバイス名とアイコン -デバイス名は色々な参照方法から決定されます。一方、デバイスアイコンは検出プロセス中に選択されたデバイス定義ファイルによって管理されます。デバイスアイコンは次のセクションで述べられているようにそのデバイスの詳細Webページへリダイレクトするリンクが張られています。
プライマリIP アドレス - 全てのルータといくつかのスイッチは典型的に1つ以上のIPアドレスを持ち、このフィールドは色々なアルゴリズムを通して決定されたデバイスのプライマリアドレスを表示します。いくつかのデバイスにとって、IPアドレスはプライマリアドレスで対話式のターミナルを開くことができるTelnetやSSHのリンクになっています。リンクはnedi.plスクリプトが検出の際にそのデバイスにログインできた場合のみ、利用可能です。しかし検出スクリプトはNeDiがそのプラットフォームのコマンドラインインタフェースの使用方法を知っているかどうか接続を試みるだけなので、いくつかのデバイスはTelnetやSSH接続をサポートしていたとしてもリンクは表示されません。
デバイスのシリアルナンバー – シリアルナンバーは構成デバイスの独自のトラック方法を提供し、デバイスが他の同じようなユニットと置き換わったかどうかを特定します。いくつかのデバイスは独自のシリアルナンバーを持たないので、その場合このフィールドは空になります。
プラットフォーム詳細 - このフィールドは典型的にデバイスのモデルナンバーを表示しますが、いくつかのデバイスはこの情報を提供しません。
SNMP コンタクト - このフィールドは検出が行われた際に検出されたSNMPコンタクト情報を表示します。
希望があれば、検索フィルターダイアログぼっくの右側で”r;Display”フィルターのインプットで選択されたアイテムを編集することによって表示されたフィールドを変更することができます。
NeDiは検出された構成デバイスのそれぞれに対して詳細画面を提供し、デバイスの構成設定と利用可能な機能を確認することが可能になります。このデータを表示するために、デバイスリストのWebページ(先のセクションで説明した)にあるアイコンをクリックするか、画面上の”Device”にマウスを動かし”Status”でクリックしてそれから表示されたドロップダウンのリストからデバイスを選択してもどちらかが可能です:以下と同じような画面が選択されたデバイスの詳細情報とともに表示されます:
TNeDiのデバイスステータスページは選択したデバイスの異なったタイプのデータを持つテーブルのセットを表示します。テーブルのそれぞれはデバイスの拡張性と関連する定義ファイルにより変わります。表示されるテーブルは以下です:
Summary -このテーブルはメインのIPアドレス、使用中のOSやSNMPのバージョンなどといったデバイス自身の情報を含んでいます。デバイスの定義は関連データの収集方法について述べていれば、このテーブルは温度、同じグラフのフルサイズ表示へのリンクと同じようにCPUとメモリ使用率のサムネイルグラフを含みます。このテーブルの一番上の行はアイコンのセットがあり、それぞれが特別な機能にリンクしています。アイコンが何を表しているかについては風船のヘルプアイコンにマウスを当てることができます。一方で、IPアドレスは対照IPアドレスでのTelnetあるいはSSHターミナルセッションへのリンクがあります(WebブラウザはURLを使用することができると仮定します。)。また、SNMPとSLIフィルー度は右側にクリックが可能なアイコンがあり、それはSNMPバージョンとデバイス上で利用可能なターミナルのエミュレーションプロトコルを再テストすることができます。
Modules -このテーブルはSNMPクエリや定義ファイルで特定されたOIDを使用する戸により検出されたデバイスのハードウェアモジュールをリストアップします。いくつかのハイエンドなデバイスは複数のハードウェアコンポーネントを持っている一方で、小さなデバイスはモジュールを表示しないかもしれません。既知のモジュールの全てのリストを表示するために、画面上の”Devices”をクリックして”Modules”をクリックします。すると、上述の”検索と表示フィルターの使用で”述べられたものと同じようなサーチフィルターのダイアログスクリーンが表示されます。
Links - このテーブルはこのデバイスと他の構成デバイスとの既知の全ての接続をリストアップします。これらの接続は自動的に検出プロセス中にNeDiによって特定されますが静的な接続も必要であれば作られます(例えばリモートのネットワークがPPP経由でローカルネットワークに接続していて、通常の方法では検知できないなど)。既知の接続の表示、または独自の静的な接続の管理を行うには、画面上の”Topology”をクリックして、”Linked”をクリックします。既知の構成デバイス間のリンク表示、作成、管理を行うことができる”Link Editor”が表示されます。
VLANs -選択したデバイスがバーチャルLANのサポート機能が組み込まれていて、デバイスの定義ファイルにSNMP経由でVLANの設定ファイルを引き出す方法が記載されていれば、NeDiha設定されたVLANとそれらの名前をレポートします。
Interfaces -このテーブルは引き出すことのできるサポートデータとともにデバイス上で検出されたインタフェースをリストアップします。このデータのほとんどはインタフェースに対する標準のSNMP OIDから読み込まれますが、いくつかはデバイスの定義ファイルにリストされているプラットフォーム特有のSNMP OIDがソースとなります。背景色のインタフェースアイコンは特定のインタフェースがアクティブ(緑)、インアクティブ(黄)、無効(赤)であるかを示しています。また一番右のカラムにあるネットワークアドレスは管理者がネットワークの可視化を操作できるダイナミックなマッピングページにリンクしています。全てのインタフェースを表示するには画面上の”Devices”をクリックし、”Interface”をクリックします。すると、上述の”検索と表示フィルターの使用で”述べられたものと同じようなサーチフィルターのダイアログスクリーンが表示されます。
上述したように、これらのテーブルを定着させるために使用されるデータはデバイス定義ファイルの完成と同じようにSNMPクエリから来ており、選択したデバイスの拡張性によります。デバイスは特定の技術を組み込まない(VLANが組み込まれていないローエンドなスイッチなど)あるいはSNMP経由でのデータ取得方法が無い場合があります。
NeDiは検出されたネットワークのノードの単純なテーブル表示を提供します。それは全体としてネットワークをすばやく確認することが可能です。このデータは構成デバイスに対しても提供されるので、他のノードと同じ方法で利用可能な特性を表示することが可能です。このデータを表示するには画面上の”Nodes”にマウスを移動し、”List”をクリックします。上述の検索と表示フィルターの使用セクションで述べたようなものと似た画面が表示され、適用したいフィルタを定義することができます。全ての検出されたネットワークノードを表示したい場合は、右側にある”Show”ボタンをクリックすると、以下と同じようにサーチフィルターの下にリストアップされた新しいテーブルの画面がリロードされます:
初期設定ではNeDiは検出したノードに対して以下のデータを表示します:
Node name and icon -ノード名は色々な参照方法から特定されますが、ノードのアイコンはそのアドレスに割り振られたメーカーを示すハードウェアアドレスのマッピングテーブルによって特定されます。ノードのアイコンは次のセクションで説明しますがノードの詳細情報が記載されたWebページへリンクします。
Primary IP address - ハードウェアアドレスに関連したIPアドレスです。IPアドレスは検索フィルターとして選択されたIPアドレスとともにノードリストをリロードするリンクで、重複したアドレスを持つデバイスの検索をすることが可能です。
Device name and interface name -ノードがつながっている構成デバイスの名前とインタフェースです。デバイス名は検索フィルターとして選択されたデバイスとともにノードリストをリロードするリンクですが、インタフェース名は検索フィルターとして選択されたインタフェースとともにノードリストをリロードします。
VLAN -対象デバイスに対するVLANの識別。VLAN IDは検索フィルターとして選択されたVLAN IDとともにノードリストをリロードするリンクです。
First Seen and Last Seen - データベースから期限が切れることなしにデータベースに追加された最初の日時とそのデバイスからのトラフィックが最後に検出された日時です。First Seenフィールドの後ろにある緑はそのデバイスが追加されてからの総時間量を表しています。
検索フィルタダイアログボックスの右にある”Display”フィルタのインプット内で選択されたアイテムを編集することで表示されているフィールドを変更することが可能です。
NeDi は、管理者がノードの利用可能な機能を確認できるネットワークノードの詳細表示を提供します。このデータは構成デバイスに対しても提供されるので、他のノードと同じ方法でこれらのデバイスの利用可能な機能を表示することが可能です。このデータを表示するにはDevice List の Webページにあるデバイスのアイコンをクリックするか、画面上の”Nodes”にマウスを移動し、”Status”をクリックして、表示される編集フィールドにハードウェアアドレスを入力します。以下と同じような画面が選択したノードの詳細情報とともに表示されます:
NeDiのノードステータスのページはテーブルを表示します。それぞれのテーブルは選択したノードの異なる情報を含んでいます。このデータはほとんど構成デバイスから収集されたものですが、いくつかの部分はノード自身から収集しています。表示されるテーブルは以下のとおりです:
Summary -ハードウェアアドレス、そのアドレスに割り当てられたハードウェアメーカー、ハードウェアアドレスに対応するプライマリのIPアドレスなどノード自身の概要です。これらのフィールドのほとんどは前述したノードリストのページで利用できるものと同じです。このテーブルの一番上の行はアイコンのセットがあり、それぞれのアイコンが特別の機能へリンクしています。それぞれのアイコンにマウスを移動すると、アイコンが何を表しているかのヘルプを減ることができます。NIC vendorフィールドはGoogleに対してベンダーの正式名称を問いあわれるリンクで最初に応答のあったところへリダイレクトをします。
Service - これらのエントリはノードが様々な一般的なネットワークサービスを起動しているかどうかを示します。このテーブル内のデータはページがロードするたびに実行されるテストによって定着しています。すべてのモジュールを表示するには画面上の”Devices”炉クリックして、それから”Modules”をクリックします。上述の” 上述の検索と表示フィルターの使用”セクションで述べたようなものと似た画面が表示されます。
Interface Traffic and Errors -最初のグラフはノードのネットワーク稼働率を示し、2番目のグラフは記録されたエラーの数を示します。これらの値はSNMPクエリとともに上流の構成デバイスから引き出します。
IP Address Changes -ノードが最初に検出された時と異なるIPアドレスに変更した場合、記録された変更がこのテーブルで表示されます。
Interface Changes -ノードが最初に検出された時と異なるポートや上流の構成デバイスに移動した場合、記録された変更がこのテーブルに表示されます。
前述した様に、このデータは検出された構成デバイスに対しても利用が可能です。つまり、スイッチとルー他の情報を表示するためにノードの詳細ページを使用することも可能です。
GroundWork NMSのNeDiパッケージは、管理者がホスト定義のデータをNediの外にエクスポート、それをGroundWork MonitorのConfigurationデータベースにインポートすることが可能な、スクリプトと自動化スキーマを提供します。このプロセスは管理者の好みで手動、あるいは自動で実行することが可能です。
管理者はNeDiからデータをエクスポートする2つのオプションがあります。ひとつは特定のテーブルから全てのデータを持つテキストファイルを手動で作成するためにNeDiの”Export”Webページを使うことです。この方法を使用する場合、画面上の”Other”にマウスを移動し、”Export”をクリックします。ツールの詳しい使用方法については、画面右上にある救命具のアイコンをクリックします。
2つ目のエクスポート方法は(こちらを推奨します)
/usr/local/groundwork/nms/tools/automation/scripts/extract_nedi.pl を使用することです。GroundWork Monitor NMSのNeDiパッケージに含まれるPerlスクリプトは、NeDiのデバイスやノードテーブルからデータをエクスポートして /usr/local/groundwork/core/monarch/automation/data/nedi_data.txt テキストファイルにアウトプットを入力します。このスクリプトは以下のフィールドでファイルを生成し、それぞれのフィールドは一組のセミコロンによって分けられています(いくつかのフィールドはどのNeDiのテーブルが現在の行を定着させているかに基づき、複数の意味を重複しています。):
フィールド名 |
フィールドデータ |
備考 |
Name |
デバイス あるいはノード名 |
構成デバイスあるいはノードの親密性のある名前 |
IP |
デバイスあるいはデバイスのIPアドレス |
構成デバイスやノードに関連するプライマリIPアドレス |
Description |
デバイスの詳細 |
構成デバイスに関する記述 |
OS/OUI |
デバイスの OS あるいはノードのOUI |
構成デバイス上で使用しているOS、あるいはノードのハードウェアアドレスと関連しているベンダー名 |
Location |
デバイスの位置 |
構成デバイスのSNMPのロケーション |
Type |
デバイスのタイプ |
構成デバイスのモデル名 |
Contact |
デバイスのコンタクト |
構成デバイスのSNMPコンタクトストリング |
Device |
ノードの親デバイス |
現在のノードに対する親機 |
Nedi.pl 検出スクリプトが実行された後(初期設定では4時間おき)9すぐにユーザ nagiosのcrontabの一部としてextract_nedi.pl Perlスクリプトは自動的に実行されます。それはアウトプットファイルが常に最新の検出データを含んでいることを確実にします。
GroundWork NMSのNeDiパッケージは、nedi_data.txt テキストファイルをGroundWork Monitorのコンフィグレーションにインポートするために、2つの異なるモデルを提供します。それぞれがGroundWork Monitorの自動検出サブシステムのスキーマテンプレートとして定義されています。
最初のモデルは、/usr/local/groundwork/core/monarch/automation/templates/schema-template-NeDi-host-import.xml スキーマテンプレートで定義されており、該当のデバイスやノードに対するホストエントリがコンフィグレーションデータベースに存在するかどうかにより新しいホストエントリを作成するか、既存のものを修正するかのどちらかによってNeDiのデバイスとノードをコンフィグレーションサブシステムに統合します。このスキーマテンプレートを使用したい場合は以下の手順を使用して適切なスキーマを作成する必要があります:
GroundWork Monitorから自動検出アプリケーションを開います。
トップのメニューバーから自動化スキーマ定義を管理する自動化をクリックします。
新しいスキーマ定義を作成するためにNew Schemaボタンを押下します。
新しいスキーマ定義に"NeDi-host-import"という名前をつけます。
下部のドロップダウンから"NeDi-host-import" テンプレートを選択します。
新しいスキーマ定義の作成を終了するために"Add" ボタンをクリックします。
スキーマの編集画面から、"Data source"の行にある"View"ボタンをクリックしてデータファイルがNeDiのデータベーステーブルからのアウトプットを含んでいるかどうかを確認し、終了の際はポップアップウインドウをクローズします。
レコードを処理したい場合は、スキーマ編集画面の上にある"Process Records"ボタンをクリックします。それ以外はスキーマ定義ウインドウに戻るために"Close"ボタンをクリックします。
GroundWork NMS NeDiパッケージはインポートプロセスを自動化するために使用される/usr/local/groundwork/nms/tools/automation/scripts/auto_import_nedi_sync.plPerl スクリプトを提供します。このスクリプトは"NeDi-host-import"の名前でスキーマ定義のエントリを探し、自動的にスキーマ定義を実行します。しかし、このスクリプトは自動的に変更をコンフィグレーションデータベースにコミットしないので、変更は手動でコミットされるまでは認識されません。