JP1 Version 13 JP1/Network Node Manager i セットアップガイド

3021-3-L32-20

前書き

対象製品

適用OS：Windows Server 2016，Windows Server 2019，Windows Server 2022，Windows Server 2025

P-2942-82DL JP1/Network Node Manager i 13-50

P-2942-89DL JP1/Network Node Manager i Developer's Toolkit 13-00

適用OS：Linux 7.1以降，Linux 8.1以降，Linux 9.1以降，Oracle Linux 7.1以降，Oracle Linux 8.1以降，Oracle Linux 9.1以降，SUSE Linux 12

P-8442-82DL JP1/Network Node Manager i 13-50

P-8442-89DL JP1/Network Node Manager i Developer's Toolkit 13-00

輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

HITACHI，HAモニタ，Job Management Partner 1，JP1は，株式会社 日立製作所の商標または登録商標です。

その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

マイクロソフト製品の表記について

このマニュアルでは，マイクロソフト製品の名称を次のように表記しています。

表記

製品名

Active Directory

Microsoft(R) Active Directory

Excel

Microsoft(R) Office Excel

Microsoft Cluster Service

Microsoft(R) Cluster Service

Windows

Windows Server 2016

Microsoft(R) Windows Server(R) 2016 Datacenter

Microsoft(R) Windows Server(R) 2016 Standard

Windows Server 2019

Microsoft(R) Windows Server(R) 2019 Datacenter

Microsoft(R) Windows Server(R) 2019 Standard

Windows Server 2022

Microsoft(R) Windows Server(R) 2022 Datacenter

Microsoft(R) Windows Server(R) 2022 Standard

Windows Server 2025

Microsoft(R) Windows Server(R) 2025 Datacenter

Microsoft(R) Windows Server(R) 2025 Standard

WSFC

Microsoft(R) Windows Server(R) Failover Cluster

その他

この製品には，Apache Software Foundationで開発されたソフトウェアが含まれています。

（http://www.apache.org）

この製品には，Indiana University Extreme! Labで開発されたソフトウェアが含まれています。

（http://www.extreme.indiana.edu）

この製品には，The Legion Of The Bouncy Castleによって開発されたソフトウェアが含まれています。

（http://www.bouncycastle.org）

発行

2025年9月 3021-3-L32-20

著作権

All Rights Reserved. Copyright (C) 2025 Hitachi, Ltd.

This software and documentation are based in part on software and documentation under license from Open Text or one of its affiliates, including Micro Focus. The copyright for Open Text Software and Documentation is owned by Open Text. 2009-2025 Copyright Open Text.

変更内容

変更内容（3021-3-L32-20）JP1/Network Node Manager i 13-50，JP1/Network Node Manager i Developer's Toolkit 13-00

追加・変更内容

変更個所

インストール前チェックリストのkernel.shmmaxおよびkernel.shmallの値に関する記載を変更した。

1.2

「NNMi をアンインストールする（Windows の場合）」の手順で，削除が必要な一時ディレクトリおよび一時ファイルに，次のディレクトリおよびファイルを追加した。

%TEMP%¥OpenTextInstaller¥

%TEMP%¥NNM_X.X_OpenTextInstaller.txt

2.4.1

「NNMi をアンインストールする（Linux の場合）」の手順で，削除が必要な一時ディレクトリおよび一時ファイルに，次のディレクトリおよびファイルを追加した。

/tmp/OpenTextInstaller

/tmp/NNM_X.X_OpenTextInstaller.txt

2.4.2

NNMiのインストール時の設定ファイルの内容がコピーされるフォルダについての説明を変更した。

4.9

server.properties，nms-auth-config.xmlの説明個所にNNMi の共有ディスク内のデータへの参照を追加した。

5.3.3(4)，10.2，12.2，21.7.1，21.7.2，21.18，23.2

ライセンス情報を追跡する際の注意についての説明を変更した。

6.1

適用OSにWindows Server 2025を追加した。

11.2.1

NNMiが起動に成功した場合のコマンドの実行結果例を削除した。

16.7

HA構成の場合，設定ファイルを変更する際にローカルディスクではなく共有ディスクにコピーされたファイルの設定値を直接編集するよう，手順を追加した。

19.5.1

HAクラスタ内のアクティブなクラスタノードでのNNMiの設定解除について，nnmsetofficialfqdn.ovplコマンドの実行順序を変更した。

19.7.3

NNMi管理サーバーでアクションサーバーを実行するユーザー名を変更する手順を変更した。

21.6.3

「バージョン9・10・11・12 のNNMi からの移行」の説明を，13-50 へバージョンアップするための説明に変更した。

24

環境変数（%jdkdir%および$jdkdir）についての記載を削除した。

付録C.1

Nodedownインシデントのクローズについて記載を変更した。

付録D.6(16)，付録D.6(18)

NNMi管理サーバーで使用されるポートの一覧に，次のとおり追加した。

ポート20480と20481の目的にJP1/IM3連携を追加した。

ポート20482の設定の変更についての説明を追加した。

また，ファイアウォールの通過方向の表にポート番号20480と20481を追加した。

付録E

nnmincidentcfg.ovplコマンドにvalidateオプションを追加した。

付録G.24

nnmloadattributes.ovplコマンドにlistオプションを追加した。また，t オプションの説明を変更した。

付録G.29

nnmloadinterfacegroups.ovplコマンドにlistオプションを追加した。

付録G.30

nnmpseudoobject.ovplコマンドの説明を追加した。

付録G.43

NNMiデータ暗号化に関する記述を削除した。

－

単なる誤字・脱字などはお断りなく訂正しました。

はじめに

このマニュアルは，JP1/Network Node Manager iおよびJP1/Network Node Manager i Advanced（以降，製品ごとに差異がない場合はNNMiと省略します）を導入するために必要な設定について説明したものです。

なお，このマニュアルは各OS共通のマニュアルです。OSごとに差異がある場合は，本文中でそのつど内容を書き分けています。

対象読者

NNMiを使用してネットワークの分散管理システムの構築を検討および実現する方を対象としています。熟練したシステム管理者，ネットワークエンジニア，または大規模システムのネットワークの導入および管理の経験がある方を対象としています。

マニュアルの構成

このマニュアルは，次に示す編から構成されています。

第1編　準備編

NNMiをインストールする前に必要な準備作業とインストール・アンインストールについて説明しています。

第2編　入門編

NNMiでネットワーク管理を始めるために最低限必要な設定について説明しています。

第3編　設定編

ネットワーク管理をするための設定について説明しています。

第4編　詳細設定編

証明書や，NNMiとLDAPによるディレクトリサービスの統合など，NNMiの機能を使用するための設定について説明しています。

第5編　高可用性環境設定編

高可用性（HA）クラスタやアプリケーションフェイルオーバーへの対応について説明しています。

第6編　NNMiのメンテナンス編

NNMiのバックアップ，リストア，および保守方法について説明しています。

第7編　移行編

バージョン13へNNMiを移行するために必要な操作について説明しています。

第8編　NNMiとの統合編

関連製品とNNMiとの統合について説明しています。

第9編　連携編

NNMiと関連製品との連携について説明しています。

新・旧の対応表

このマニュアル「JP1/Network Node Manager i セットアップガイド（3021-3-L32）」は，次のマニュアルの内容を取り込んだ上で，バージョン13のエンハンス内容を追加，更新しました。

JP1/Cm2/Network Node Manager i　インストールガイド（3021-3-241-20）

Job Management Partner 1/Consolidated Management 2/Network Node Manager i　インストールガイド（3021-3-342-20）

旧セットアップガイドと新セットアップガイドの構成の対応は次のとおりです。

旧セットアップガイドと新セットアップガイドの構成対応表

旧（セットアップガイド）

新（セットアップガイド）

【第1編　準備編】

【第1編　準備編】

1　ハードウェアとソフトウェアの要件

−

1.1　対応ハードウェアとソフトウェア

（「1.1　ハードウェアおよびソフトウェアを確認する」に対応）

1.2　システム設定（UNIX）

（「付録A　NNMiのmanページを表示できない場合（Linux)」に移動）

（インストールガイドの「2　インストール前チェックリスト」を取り込み）

1　インストール前チェックリスト

1.1　ハードウェアおよびソフトウェアを確認する

1.2　インストール前のNNMi管理サーバー環境を準備する

1.3　DNS設定を確認する

1.4　NNMiクイックスタート設定ウィザードを使用するための準備をする

（インストールガイドの「付録A　インストール時の補足情報」を取り込み）

1.5　インストール時の補足情報

（インストールガイドの「3　NNMiのインストールとアンインストール」を取り込み）

2　NNMiのインストールとアンインストール

2.1　NNMiをインストールする

2.2　クイックスタート設定ウィザードを使用する

2.3　NNMiのライセンスを取得する

2.4　NNMiをアンインストールする

（インストールガイドの「付録B　インストールおよび初期スタートアップのトラブルシューティング」を取り込み）

2.5　インストールおよび初期スタートアップのトラブルシューティング

（インストールガイドの「4　NNMi入門」を取り込み）

【第2編　入門編】

3　NNMi入門

3.1　NNMiへアクセスする

3.2　NNMiヘルプへアクセスする

3.3　ネットワーク検出を設定する

【第2編　設定編】

【第3編　設定編】

2　設定の一般概念

4　設定の一般概念

3　NNMi通信

5　NNMi通信

4　NNMi検出

6　NNMi検出

5　NNMiステータスポーリング

7　NNMiステータスポーリング

6　NNMiインシデント

8　NNMiインシデント

7　NNMiコンソール

9　NNMiコンソール

【第3編　詳細設定編】

【第4編　詳細設定編】

8　NNMiでの証明書の使用

10　NNMiでの証明書の使用

9　NNMiで使用するTelnetおよびSSHプロトコルの設定

11　NNMiで使用するTelnetおよびSSHプロトコルの設定

10　NNMiとLDAPによるディレクトリサービスの統合

12　NNMiとLDAPによるディレクトリサービスの統合

11　NAT環境の重複IPアドレスの管理

13　NAT環境の重複IPアドレスの管理

12　NNMiのセキュリティおよびマルチテナント

14　NNMiのセキュリティおよびマルチテナント

13　グローバルネットワーク管理

15　グローバルネットワーク管理

14　NNMiIPv6管理機能

16　NNMi IPv6管理機能

【第4編　高可用性環境設定編】

【第5編　高可用性環境設定編】

15　NNMiがサポートするデータの保護

17　NNMiがサポートするデータの保護

16　アプリケーションフェイルオーバー構成のNNMiを設定する

18　アプリケーションフェイルオーバー構成のNNMiを設定する

17　高可用性クラスタにNNMiを設定する

19　高可用性クラスタにNNMiを設定する

【第5編　NNMiのメンテナンス編】

【第6編　NNMiのメンテナンス編】

18　NNMiのバックアップおよびリストアツール

20　NNMiのバックアップおよびリストアツール

19　NNMiの保守

21　NNMiの保守

20　NNMi管理サーバーの変更

22　NNMi管理サーバーの変更

21　NNMiセキュリティ

23　NNMiセキュリティ

【第6編　移行編】

【第7編　移行編】

22　バージョン9・10-00・10-10のNNMiからの移行

24　バージョン9・10・11・12のNNMiからの移行

23　バージョン8以前のNNMとの比較

－

24　バージョン8以前のNNMからの移行

－

【第7編　NNMiとの統合編】

【第8編　NNMiとの統合編】

25　NNMi Northboundインタフェース

25　NNMi Northboundインタフェース

26　JP1/Integrated Management-UniversalCMDB10.1Full※

－

－

【第9編　連携編】

－

26　JP1/IM2 のインテリジェント統合管理基盤との連携

－

27　RESTful API

付録

付録

（「1.2　システム設定（UNIX）」を移動）

付録A　NNMiのmanページを表示できない場合（Linux)

（インストールガイドの「付録C　新規インストール中に読み込むMIB一覧」を取り込み）

付録B　新規インストール中に読み込むMIB一覧

付録A　NNMi環境変数

付録C　NNMi環境変数

付録B　Causal EngineとNNMiインシデント

付録D　Causal EngineとNNMiインシデント

付録C　NNMiが使用するポートの一覧

付録E　NNMiが使用するポートの一覧

－

付録F　リファレンスページ（User Commands）

－

付録G　リファレンスページ（Administrator Commands）

－

付録H　リファレンスページ（File Formats）

付録D　各バージョンの変更内容

付録I　各バージョンの変更内容

付録E　このマニュアルの参考情報

付録J　このマニュアルの参考情報

付録F　用語解説

付録K　用語解説

注※

この章は，「Job Management Partner 1/Consolidated Management 2/Network Node Manager i　セットアップガイド（3021-3-343-20）」には記載されていません。

第1編　準備編

1　インストール前チェックリスト

ここでは，NNMiをインストールする前に必要な準備と確認方法について説明しています。

1.1　ハードウェアおよびソフトウェアを確認する

NNMiのインストールを開始する前に，NNMiのリリースノートに記載されているハードウェアおよびソフトウェアに関する情報をお読みください。

また，監視対象の規模に変更があった場合，リリースノートの「4.　メモリ所要量およびディスク占有量」および「9.1　システム」を参考にして，Java最大ヒープサイズ（-Xmx）の値を見直してください。

1.2　インストール前のNNMi管理サーバー環境を準備する

NNMi管理サーバーとは，NNMiソフトウェアがインストールされているサーバーのことです。各NNMi管理サーバーは，64ビットマシンである必要があります。ハードウェア要件の詳細については，「1.1　ハードウェアおよびソフトウェアを確認する」を参照してください。

NNMi管理サーバーにNNMiをインストールする前に，表1-1のチェックリストでチェックを実施してください。

重要

NNMiのインストールや設定作業を行う前に，リモートデスクトップに次の設定を行ってください。なお，この設定を行うとWindowsの使用リソースが増加しますので，作業終了後に必要に応じて設定を元に戻してください。

設定個所

［ローカル グループ ポリシー エディタ］※＞［コンピューターの構成］＞［管理用テンプレート］＞［Windowsコンポーネント］＞［リモート デスクトップ サービス］＞［リモート デスクトップ セッション ホスト］＞［一時フォルダ］

注※　［ローカル グループ ポリシー エディタ］は，スタート画面で「gpedit.msc」と入力して開くことができます。

設定内容

「セッションごとの一時フォルダを使用しない」と「終了時に一時フォルダを削除しない」を有効に設定する。設定の変更をシステムに反映させるため，一度ログオフし，再度ログオンする。

表1‒1　NNMi管理サーバーのインストール前チェックリスト

チェック欄

（はい/いいえ）

NNMi管理サーバーの準備

NNMiのインストールに失敗した環境で再度インストールを行う場合，リリースノートの付録に記載されているNNMiの手動削除手順を実施してからインストールを実施してください。

NNMiをインストールするサーバーのホスト名は，RFCに準拠したホスト名にしてください。

ホスト名に使用できる文字は，英数字（A-Z，a-z，0-9），ハイフン（-），およびドメイン名を区切るドット（.）です。

RFCに準拠していないホスト名（例：アンダーバー（_）を含むホスト名）が設定されていると，NNMiコンソールの接続やコマンドの実行に失敗する場合があります。

NNMiをインストールするサーバーで，あらかじめ自ホストの名前解決ができること，およびlocalhostが127.0.0.1で名前解決できることを確認してください。

Windows

OSのシステムドライブがCドライブであることを確認してください。システムドライブがCドライブ以外の環境には，NNMiをインストールできません。

Windows

NNMiをインストールするディスクドライブやデータディレクトリを配置するディスクドライブに厳しいセキュリティ設定をしている場合，セキュリティの設定が必要になる場合があります。詳細については，「1.5.1　ディスクドライブのセキュリティ設定（Windowsの場合）」を参照してください。

Windows

SNMPサービスをチェックしてください。SNMP Serviceがインストールされている場合，このサーバーでSNMP Trap Serviceを無効にする必要があります。

対応Webブラウザをインストールして有効にします。「1.1　ハードウェアおよびソフトウェアを確認する」および「1.5.3　NNMiコンソール用のWebブラウザの有効化」を参照してください。

DHCP（Dynamic Host Configuration Protocol）をお使いの場合，NNMi管理サーバーには，常に同じIPアドレスが割り当てられるように設定してください。

NNMiのインストールが完了するまで，ウイルス対策ソフトウェアを無効にしてください。NNMiのインストールが完了したら，各ウイルス対策サービスを再起動してください。

Linux

LinuxサーバーにNNMiをインストールするためには，NNMiが必要とする次のパッケージをインストールしておくことが必要です。また，それぞれの依存関係があるライブラリファイルについてもインストールしてください。

libaio (x86_64)

libXtst (x86_64)

libXi (x86_64)

net-tools (x86_64)

unzip (x86_64)

fontconfig (x86_64)

liberation-sans-fonts (noarch)※

注※ fc-listコマンドで一つ以上のフォントが出力されている場合は，このパッケージは不要です。

RHEL 8.1以降，またはOracle Linux 8.1以降では追加で以下をインストールしてください。

libnsl (x86_64)

詳細については，「1.5.4　Linuxへの必要なライブラリのインストール（Linuxの場合）」を参照してください。

NNMiが使用するデータベースはPostgreSQLです。PostgreSQLがインストールされているサーバーにNNMiをインストールする場合，ポート競合が発生しないようにする必要があります。NNMiで使用するPostgreSQLのポートは，5432／TCPです。そのため，既存のPostgreSQLのポートを5432／TCP以外に変更してからインストールしてください。必要に応じて，インストール後にNNMiで使用するPostgreSQLのポートを変更してください。

NNMiが使用するすべてのポートが利用できることを確認します。NNMiが使用するポート一覧やファイアウォールの通過方向は，「付録E　NNMiが使用するポートの一覧」を参照してください。

自ホストのIPアドレスとの通信をファイアウォールなどでブロックしないでください。

Windows

NNMiは，［コントロールパネル］の言語の設定で，［形式］に設定した言語でインストールされます。［形式］に設定した以外の言語でNNMiを使用することはできません。OSインストール時の言語から変更する場合は，OSインストール時の言語は英語だけとします。NNMiをインストールする前に，次の設定を行ってください。

［コントロールパネル］の言語の設定で，［形式］の言語を［表示言語］の設定に合わせ，日本語または英語または中国語に設定します。

なお，上書きインストールの場合は，ここで指定する言語を上書き前のNNMiの言語と一致させる必要があります。

［設定のコピー］でシステムアカウントに設定をコピーします。

［Unicode対応ではないプログラムの言語］の言語を設定します。

手順1で［形式］に設定した言語と同じ言語を設定します。

Linux

NNMi管理サーバーのロケールには次のどれかを設定してください。

ja_JP.utf8，ja_JP.UTF-8，C，en_US.utf8，en_US.UTF-8，zh_CN.utf8

古いバージョンのNNMをアンインストールしてもその設定情報が残っています。以前の古い情報は，古いバージョンのNNMのリリースノートを参照して，インストール前に削除しておくようにしてください。

Windows

この製品をインストールする前に，Windowsのサービス画面（［コントロール パネル］＞［管理ツール］＞［サービス］より起動される画面）が起動していないことを確認してください。起動している場合はサービス画面を閉じてください。

Windows

システム環境変数Pathに設定されている文字列の長さと次のディレクトリのパスの長さの和が950バイト以上になる場合，この製品のインストールに成功しても，次のパスがシステム環境変数Pathに追加されないことがあります。

%NnmInstallDir%bin¥;

%NnmDataDir%shared¥nnm¥actions¥;

インストール終了後，システム環境変数Pathに上記のパスが追加されていない場合は，手動で追加してください。

環境変数の詳細については，「付録C.1　マニュアルで使用する環境変数」を参照してください。

Windows

NNMiをデフォルト以外のパスにインストールする場合，インストールディレクトリとデータディレクトリの名称に使用できる文字は，英数字（A-Z，a-z，0-9），ハイフン（-），ピリオド（.），アンダーバー（_），半角スペース（ ）です。ただし，複数連続する半角スペースは使用できません。また，それぞれの絶対パスの最大長は60文字です。

Windows

<drive>:¥Documents and Settingsなど接合点を含むパスは指定しないでください。一時ファイルが削除されないなどの不具合が発生する場合があります。

Windows

環境変数%TEMP%と%TMP%の値が異なる環境に，NNMiをインストールすると，インストールに失敗することがあります。インストール前に環境変数%TEMP%と%TMP%の値が同じであることを確認してください。異なる場合は，%TEMP%と%TMP%に同じ値を設定してください。

Windows

環境変数に次の変数を設定しないでください。

LANG

LC_で始まるもの

ほかの製品でこれらの環境変数が設定されている場合は，この製品との共存ができない場合があります。これらの環境変数を設定したまま，NNMiをインストールすると，インストールに失敗する場合があります。

Windows

リモートデスクトップサービスのリモートデスクトップセッションホストがインストールされている場合は，NNMiをインストールする前に次の設定が必要です。

change user /installを実行してインストールモードに変更します。

設定の詳細はリモートデスクトップセッションホストのヘルプを参照してください。

Windows

NNMiをインストールするシステムに，OSの再起動が必要な変更をした場合は，NNMiをインストールする前にOSを再起動してください。

OSの再起動が必要な例として，次のレジストリ値が存在する場合があります。値が存在している場合，NNMiはインストールを中断することがあります。

HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥Session Manager¥PendingFileRenameOperations

通常は，OSを再起動することでこのレジストリ値はなくなります。

Windows

NNMiはインストールおよびアンインストール時に，%TEMP%ディレクトリを最大500MB使用します。ディスク容量が不足していると，インストールやアンインストールが失敗する場合があります。

Linux

NNMiはインストールおよびアンインストール時に，/tmpディレクトリを最大1GB使用します。ディスク容量が不足していると，インストールやアンインストールが失敗する場合があります。

Windows

インストール作業中は，［ローカルグループ ポリシー エディタ］＞［コンピューターの構成］＞［管理用テンプレート］＞［Windows コンポーネント］＞［リモートデスクトップ サービス］＞［リモートデスクトップ セッション ホスト］＞［一時フォルダ］の「セッションごとの一時フォルダを使用しない」と「終了時に一時フォルダを削除しない」を「有効」にしてください。設定の変更をシステムに反映させるため，一度ログオフし，再度ログオンしてください。

Linux

この製品を再インストールした場合は，NNMiを前提としているほかのアプリケーションについても再インストールおよびそれに伴う各種設定をしてください。

Linux

この製品を前提とするアプリケーションのインストールは，この製品のインストール後の環境設定が終了してから行ってください。また，アプリケーションをインストールする際は，必ずovstopコマンドを実行してから行ってください。

Linux

Hitachi PP Installerが実行されているターミナルウィンドウのサイズは，NNMiインストール中は変更しないでください。インストール中にウィンドウサイズを変更すると，NNMiが正常にインストールできない場合があります。

Linux

NNMiでは，UDPの受信バッファに8MB，送信バッファに2MB必要です。

バッファ用に確保されているメモリ容量の設定を変更するには，/etc/sysctl.confファイルを編集して，次のエントリを追加してください。

# NNM settings for UDP receive and send buffer sizes

net.core.rmem_max = 8388608

net.core.wmem_max = 2097152

/etc/sysctl.confファイルの編集後にOSを再起動するか，/sbin/sysctl -pコマンドを実行して変更を反映させてください。

Linux

カーネルパラメータのkernel.shmmaxの値が小さ過ぎる場合があります。その場合，/etc/sysctl.confファイルを編集して次のエントリを追加してください。推奨する値は64GBです。

# NNM settings for embedded database

kernel.shmmax = 68719476736

なお，OSに設定されているkernel.shmmaxの値がNNMiの推奨値より大きい場合は，変更せずにそのままご使用ください。

カーネルパラメータのkernel.shmallの値が小さ過ぎる場合があります。その場合，/etc/sysctl.confファイルを編集してNNMiの推奨値である64ギガページをkernel.shmallに加算してください。

kernel.shmall = 68719476736

なお，OSに設定されているkernel.shmallの値が各製品全体の合計値より大きい場合は，加算せずにそのままご使用ください。

kernel.shmmaxやkernel.shmallの値を設定する場合は，/etc/sysctl.confファイルの編集後にOSを再起動するか，/sbin/sysctl -pコマンドを実行して変更を反映させてください。

Linux

NNMiインストールスクリプトは，2つのグループ（nmsgrpとnmsdb），2つのユーザー（nmsprocとnmsdbmgr），および対応する$HOMEディレクトリを自動的に作成します。これらの操作は，次の理由によって失敗することがあります。

IT部門でuseraddコマンドまたはgroupaddコマンドを無効にしたため，ユーザーおよびグループを作成できない。

$HOMEディレクトリがNFS上に存在する場合に，ルートユーザーが$HOMEディレクトリを作成できない。

NNMiインストーラがこれらのグループ，ユーザー，またはディレクトリの作成に失敗すると，インストールが中止されます。この場合は，インストールを実行する前にユーザーを手動で作成してからインストールしてください。

nmsgrpグループでnmsprocユーザーを作成する。

$HOMEディレクトリを任意のディレクトリに設定しますが，そのディレクトリは存在する必要があります。

nmsdbグループでnmsdbmgr ユーザーを作成する。

$HOMEディレクトリを任意のディレクトリに設定しますが，そのディレクトリは存在する必要があります。

これらの操作に失敗することがわかっていて，ユーザーID，グループID，または$HOMEの場所を制御する必要がある場合は，グループ，ユーザー，および$HOMEディレクトリを作成してからインストーラを起動できます。

useraddコマンドによってユーザーを作成した場合，デフォルトでは/home/<ユーザー名>がホームディレクトリになります。

1.3　DNS設定を確認する

NNMiは，ドメインネームシステム（DNS）を使用してホスト名とIPアドレスの関係を判断します。これによって，自動検出が有効になっている場合は，大量の名前解決要求が行われることがあります。

名前解決要求を解決する際に長時間にわたる遅延を防ぐようDNSサーバーが正しく設定されていることを確認します。NNMiの名前解決要求に応答するDNSサーバーが，次の機能を備えている必要があります。

DNSサーバーは，権限サーバーであり，DNS要求を転送しません。

DNSサーバーには，ホスト名からIPアドレスへの，およびIPアドレスからホスト名への一貫したマッピング情報があります。

ネットワーク内で複数のDNSサーバーが使用される場合，それらのサーバーはすべての名前解決要求に矛盾がないように応答する必要があります。

重要

ラウンドロビンDNS（Webアプリケーションサーバーの負荷分散に使用される）では，任意のホスト名が時間の経過に伴って異なるIPアドレスにマップされるおそれがあります。

メモ

nslookupの応答時間を改善するには，セカンダリDNSサービスをNNMi管理サーバーまたはNNMi管理サーバーと同一のサブセット内の別のシステムに配置します。そして，プライマリDNSサービスの情報をミラーリングするように，このセカンダリDNSサービスを設定してください。また，小規模な環境では，DNSの代わりに次のファイルを使用する設定方法もあります。

Windows：%SystemRoot%¥system32¥drivers¥etc¥hosts

Linux：/etc/hosts

NNMi管理サーバー上で，使用している環境に対して次が適切に設定されているかを確認します。

オペレーティングシステムの設定によって，hostsファイルが優先されます。hostsファイルに最低限次の2つのエントリが含まれていることを確認します。

127.0.0.1 localhost

<NNMi管理サーバーのIPアドレス>＜NNMi管理サーバー名＞

NNMi管理サーバーのIPアドレスは，NNMi管理サーバーのFQDNのIPアドレスです。NNMi管理サーバー名は，インストール時に設定されたNNMi管理サーバーの正式な完全修飾ドメイン名（FQDN）です。

Windows

NNMi管理サーバーが使用するすべてのDNSサーバーに，ホスト名からIPアドレスへの，およびIPアドレスからホスト名への一貫したマッピング情報があることを確認してください。

Linux

nslookup検索が，nsswitch.confファイルで設定されているnslookupコマンド検索順序に適合することを確認してください。

また，認識されているすべてのDNSサーバーに，ホスト名からIPアドレスへの，およびIPアドレスからホスト名への一貫したマッピング情報があることを確認してください。

ネットワークドメイン内のDNSの設定に問題がある（適切に解決されないホスト名やアドレスがある）ことがわかっている場合は，重要ではないデバイスが対象のnslookup要求を避けるように設定します。これを行う利点は次のとおりです。

スパイラル検出の速度向上

NNMiが引き起こすネットワークトラフィックの最小化

NNMiが問題のあるデバイスを識別するには，NNMiの検出を設定する前に次の2つのファイルを作成します。NNMiは，これらのファイルで識別されたホスト名またはIPアドレスのDNS要求を発行しません。

hostnolookup.conf（完全修飾ドメイン名またはホスト名のグループを識別するワイルドカードを入力）

ipnolookup.conf（IPアドレスまたはIPアドレスのグループを識別するワイルドカードを入力）

ファイルを作成するには，テキストエディタを使用します。ファイルをNNMi管理サーバー上の次の場所に配置します。

Windows：%NnmDataDir%shared¥nnm¥conf¥

%NnmDataDir%は，インストール時に指定するデータディレクトリです。

Linux：/var/opt/OV/shared/nnm/conf/

1.4　NNMiクイックスタート設定ウィザードを使用するための準備をする

インストール後にクイックスタート設定ウィザードを起動すると，制限された環境（またはテスト環境）に対して，NNMiを設定できます。このウィザードを使用する場合は，表1-2のチェックリストでチェックを実施してください。

表1‒2　NNMiクイックスタート設定ウィザードのインストール前チェックリスト

チェック欄

（はい/いいえ）

初期環境設定の事前準備

自動検出でのIP設定範囲を決定します※。ライセンス数（管理ノード数）に関する情報は，「2.3　NNMiのライセンスを取得する」を参照してください。

検出シードのIPアドレスを決定します。シードの詳細については，「2.2　クイックスタート設定ウィザードを使用する」の「検出シードおよび自動検出ルールについて」を参照してください。

検出領域内のノードの読み取り専用SNMPコミュニティ文字列を，ネットワーク管理者から取得します。

NNMi管理者アカウントのユーザー名とパスワードを決定します。

注※

ネットワークアドレス変換（NAT）を使用した結果，重複するIPアドレスを含むネットワークでエリアを管理する場合は，クイックスタートウィザードで検出する1つのアドレスドメイン（重複しないアドレス）を選択します。次に，NNMiヘルプの「NAT環境内で重複するアドレス」または「13.　NAT環境の重複IPアドレスの管理」を参照してください。

1.5　インストール時の補足情報

ここでは，NNMiインストール時の補足情報について説明します。

1.5.1　ディスクドライブのセキュリティ設定（Windowsの場合）

NNMiをインストールする前にディスクドライブのセキュリティを設定するには，次の手順に従ってください。

［コンピューター］を開いて，ディスクドライブを表示する。

NNMiのインストールで使用するドライブの［プロパティ］＞［セキュリティ］タブを開く。

管理者権限のユーザーとしてログオンし，（直接，またはグループメンバーシップを介して）［フルコントロール］に設定されていることを確認する。設定されていない場合は，設定を変更する。

［セキュリティ］タブ内の詳細設定を開き，管理者権限のユーザーの［適用先］が［このフォルダー、サブフォルダーおよびファイル］に設定されているかを確認する。設定されていない場合は，設定を変更する。

ビルトインLocal Serviceユーザーが，（直接，または所属するUsersグループから継承して）［読み取りと実行］を選択していることを確認する。設定されていない場合は，設定を変更する。

［セキュリティ］タブ内の詳細設定を開き，ビルトインLocal Serviceユーザーの［適用先］が［このフォルダー、サブフォルダーおよびファイル］に設定されているかを確認する。設定されていない場合は，設定を変更する。

変更を適用する。

NNMiのインストールを続行する。

1.5.2　正式な完全修飾ドメイン名の取得または設定

NNMiユーザーは，正式な完全修飾ドメイン名（FQDN）を使用してNNMiにアクセスします。

NNMi管理サーバーの正式なFQDNを判別するには，次のどちらかの方法を使用する。

nnmofficialfqdn.ovplコマンドを使用して，FQDN設定の値を表示します。詳細については，nnmofficialfqdn.ovplリファレンスページを参照してください。

NNMiコンソールで，［ヘルプ］＞［システム情報］の順にクリックします。［サーバー］タブから完全修飾ドメイン名の値を見つけます。

設定したFQDNを変更する必要がある場合は，nnmsetofficialfqdn.ovplコマンドを使用する。

詳細については，nnmsetofficialfqdn.ovplリファレンスページを参照してください。

1.5.3　NNMiコンソール用のWebブラウザの有効化

NNMiにサインオンする前に，NNMiコンソールと相互動作するようにWebブラウザが設定されていることを確認してください。NNMi管理サーバーにアクセスする各クライアントマシンのWebブラウザで次の項目を設定してください。

JavaScriptを有効にする。

NNMi管理サーバーからのポップアップウィンドウの表示を許可する。

NNMi管理サーバーからのCookieの保存を許可する。

ActiveXを有効にする。

ページの自動読み込みを有効にする。

次の手順は，Webブラウザの設定の一例です。

重要

次の手順を完了するには，NNMi管理サーバーの完全修飾ドメイン名が必要になります。

使用しているNNMi管理サーバーに複数のドメイン名がある場合は，NNMiでは，インストール時にその中から1つを選択します。NNMiが使用している完全修飾ドメイン名を判断するには，nnmofficialfqdn.ovplスクリプトを実行します。詳細については，nnmofficialfqdn.ovplリファレンスページを参照してください。

(1)　Mozilla Firefoxの場合

Mozilla Firefoxでは，デフォルトでJavaScriptの使用が有効になっています。JavaScriptを無効にするにはプライバシー拡張が必要です。NNMiでJavaScriptが無効になっていることを示すエラーが生成される場合，Firefoxの［アドオンマネージャ］の［拡張機能］オプションを確認して，プライバシー拡張が使用されているかどうかを判別します。

ポップアップウィンドウを有効にするには，次の手順を実行する。

a　Mozilla Firefoxで，［ツール］＞［オプション］の順にクリックします。

b　［コンテンツ］をクリックします。

c　［ポップアップウィンドウをブロックする］チェックボックスを有効にします。

d　［ポップアップウィンドウをブロックする］チェックボックスの横にある［許可サイト］をクリックします。

e　NNMi管理サーバーの完全修飾ドメイン名を，許可サイトのリストに追加し，

［許可］をクリックします。

f　［閉じる］をクリックします。

Cookieを有効にするには，次の手順を実行する。

a　Mozilla Firefoxで，［ツール］＞［オプション］の順にクリックします。

b　［プライバシー］をクリックします。

c　［履歴］に移動し，［履歴を記憶させる］を選択します。

Webブラウザを再起動する。

1.5.4　Linuxへの必要なライブラリのインストール（Linuxの場合）

LinuxサーバーにNNMiをインストールするためには，NNMiが必要とする次のパッケージをインストールしておくことが必要です。また，それぞれの依存関係があるライブラリファイルについてもインストールしてください。

libaio (x86_64)

libXtst (x86_64)

libXi (x86_64)

net-tools (x86_64)

unzip (x86_64)

fontconfig (x86_64)

liberation-sans-fonts (noarch)※

注※ fc-listコマンドで一つ以上のフォントが出力されている場合は，このパッケージは不要です。

RHEL 8.1以降，またはOracle Linux 8.1以降では追加で以下をインストールしてください。

libnsl (x86_64)

詳細は，NNMiのリリースノート，およびオペレーティングシステムのドキュメントを参照してください。

1.5.5　システムアカウントのパスワードの設定

システムアカウントのパスワードは，インストール中に設定します。インストール時に設定をスキップした場合，またはパスワードを変更する場合は，nnmchangesyspw.ovplスクリプトを使用して変更できます。次の手順に従います。

ovstop -cコマンドを使用してNNMiプロセスを停止する。

管理者としてnnmchangesyspw.ovplスクリプトを実行し，システムパスワードを設定する。

ovstart -cコマンドを使用してNNMiプロセスを開始する。

詳細については，nnmchangesyspw.ovplリファレンスページを参照してください。

2　NNMiのインストールとアンインストール

ここでは，NNMiのインストールとアンインストールについて説明します。また，インストール後の設定方法やライセンスの取得方法についても記載しています。インストールについての情報は，リリースノートにも記載されています。併せてご覧ください。

2.1　NNMiをインストールする

Windows

ウイルス対策ソフトウェアの無効化も含めて，インストール前のチェックリストが完了していることを確認してください（「1.　インストール前チェックリスト」を参照）。

Linux

インストール前のチェックリストが完了していることを確認してください（「1.　インストール前チェックリスト」を参照）。

NNMiをバージョンアップ（修正版の適用を含む）する場合の手順については，リリースノートを参照してください。

2.1.1　NNMiをインストールする（Windowsの場合）

WindowsシステムにNNMiを新規でインストールする手順を次に示します。

重要

NNMiのインストールや設定作業を行う前に，リモートデスクトップに次の設定を行ってください。なお，この設定を行うとWindowsの使用リソースが増加しますので，作業終了後に必要に応じて設定を元に戻してください。

設定個所

［ローカル グループ ポリシー エディタ］※＞［コンピューターの構成］＞［管理用テンプレート］＞［Windows コンポーネント］＞［リモート デスクトップ サービス］＞［リモート デスクトップ セッション ホスト］＞［一時フォルダ］

注※　［ローカル グループ ポリシー エディタ］は，スタート画面で「gpedit.msc」と入力して開くことができます。

設定内容

「セッションごとの一時フォルダを使用しない」と「終了時に一時フォルダを削除しない」を有効に設定する。設定の変更をシステムに反映させるため，一度ログオフし，再度ログオンする。

NNMiをインストールするシステムに，管理者権限を持つユーザーでログオンする。

UACが有効な場合，ビルトインAdministrator以外のユーザーでは，管理者への昇格が必要です。

NNMiの媒体をドライブにセットする。

HITACHI総合インストーラの画面が表示されます。

HITACHI総合インストーラの指示に従って，インストールを開始する。

インストーラの指示に従って情報を入力する。

デフォルト値を使用する場合は，値を入力しないで，［Enter］キーを押してください。デフォルト値は，角括弧"[ ]"で囲まれた値です。

NNMi WebサーバーのHTTPポート番号の指定

NNMiにアクセスするためのNNMi WebサーバーのHTTPポート番号を入力します。ほかのプログラムが使用していないポート番号を入力してください。デフォルト値は20480です。

（入力例）

** Network Node Manager i Installer **

* Starting NNMi installation.

* Enter default port for HTTP server =>

* [20480]

8004[図データ]

NNMi WebサーバーのHTTPSポート番号の指定

NNMiにアクセスするためのNNMi WebサーバーのHTTPSポート番号を入力します。ほかのプログラムが使用していないポート番号を入力してください。デフォルト値は20481です。

（入力例）

* Enter default port for HTTPS server =>

* [20481]

8443[図データ]

インストールディレクトリの指定

NNMiのプログラムをインストールするディレクトリを入力します。デフォルト値は，次のとおりです。

<drive>:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥

（入力例）

* Enter program install directory =>

* [C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥]

C:¥Hitachi¥Cm2NNMi¥[図データ]

重要

NNMiは<drive>:¥Program Files¥にインストールすることはできません。

データディレクトリの指定

NNMiの設定ファイルやデータベース，ログファイルなどのデータを格納するディレクトリを入力します。デフォルト値は，次のとおりです。

<drive>:¥ProgramData¥Hitachi¥Cm2NNMi¥

（入力例）

* Enter program data directory =>

* [C:¥ProgramData¥Hitachi¥Cm2NNMi¥]

D:¥NNMiData¥[図データ]

入力内容の表示およびインストール開始可否の確認

上記3つの入力内容が表示されるので，入力内容に問題がなくインストールを開始する場合は「yes」を，入力内容を変更したい場合は「no」を入力します。

（入力例）

* http port : 20480

* https port : 20481

* install directory : C:¥Hitachi¥Cm2NNMi¥

* data directory : D:¥NNMiData¥

* Do you start installation with above settings you entered ? (yes/no)

* If you need to change the settings, please enter no.

yes[図データ]

インストール前チェックの実施およびインストール続行可否の確認

インストールが開始すると，初めにインストール前チェック処理が実施されます。

メモ

インストール前チェックでは，「表1‒1　NNMi管理サーバーのインストール前チェックリスト」に記載されている項目を確認するため，NNMiが使用するポートが利用できるかをチェックします。

NNMiが使用するすべてのポートが利用できることを確認します。NNMiが使用するポート一覧やファイアウォールの通過方向は，「付録E　NNMiが使用するポートの一覧」を参照してください。

このインストール前チェックに問題がなければ，そのままインストールを続けます。

インストール前チェックに問題がある場合，インストーラは問題内容を出力し，インストールを続けるかユーザーに確認します。インストールを続ける場合は「yes」，インストールを終了する場合は「no」を入力してください。

（インストール前チェックに問題があった場合の入力例）

* Starting NNMi Precheck ...

* TCP Port: [20481] is used.

* UDP Port: [162] is used.

* NNMi Precheck result: NG

* There are some problem(s) with the settings.

* Do you want to continue NNMi installation ? (yes/no)

* If you enter no, the installation will stop.

no[図データ]

重要

それぞれの入力の際には［Ctrl+z］を入力しないでください。［Ctrl+z］を入力するとインストールを中断します。インストールが中断した場合はインストール手順3から再開してください。

また，インストールは数十分掛かることがありますが，途中でインストールを中断しないでください。中断した場合，不正な状態となり，通常の手段では再インストールできなくなるおそれがあります。

インストール前チェックの結果が「OK」になっても，インストールの成功を保証するものではありません。このため，「1.　インストール前チェックリスト」を参照し，インストール前のチェックリストが完了していることを確認してください。

システムアカウントのパスワードの設定

しばらく経過すると，システムアカウントのパスワードの設定画面が表示されるので，パスワードを入力します。

パスワードは，1文字以上，最大40文字まで入力できます。使用できる文字は，半角英数字（A-Z，a-z，0-9），およびアンダーバー（_）です。

インストール後に設定する場合は，「¥quit」を入力します。

* Setup system password for the initial sign-in to the NNMi console.

* If you want to setup the password later, enter "¥quit".

* Please enter system password:

* Please enter system password again:

メモ

システムアカウントは，インストールプロセスで作成する特別な管理者アカウントです。NNMiコンソールへ最初にサインインするときに使用します。NNMiコンソールで管理者ロールのユーザーを作成したあとは，通常は使用しません。システムアカウントはインストール終了後も有効ですが，コマンドラインの実行や復旧目的にだけ使用されます。システムパスワードの変更方法については，「1.5.5　システムアカウントのパスワードの設定」を参照してください。

インストール完了の確認

インストールが正しく完了すると「Installation complete successfully.」という表示でコマンドプロンプトが止まりますので，Enterキーを押下してください。

インストール結果の確認

%TEMP%¥JP1NNMiInstaller.logファイルの最後の行に，次のようにステータスの値が[0]の終了メッセージが出力されている場合，インストールは成功しています。ステータスが[0]以外の値の場合，インストールに失敗しているおそれがあります。

[Trace] Process finished with [0]

NNMiのコマンドを実行する場合，インストール完了後に開いたコマンドプロンプト画面を使ってください。インストール前から開いている画面ではNNMiの環境変数などが設定されていないため，正しく動作しません。

2.1.2　NNMiをインストールする（Linuxの場合）

LinuxシステムにNNMiを新規でインストールする手順を次に示します。

NNMiをインストールするシステムに，root権限を持つユーザーでログインする。

環境変数「LC_ALL」および「LANG」に，サポート対象のロケールを設定する。

# LC_ALL=ja_JP.UTF-8
# export LC_ALL
# LANG=ja_JP.UTF-8
# export LANG

なお，サポート対象のロケールについてはリリースノートを参照してください。

NNMiの媒体をドライブにセットし，ドライブをマウントする。

ドライブのマウント方法については，NNMiのリリースノートや，OSのマニュアルを参照してください。

Hitachi PP Installerを起動する。

次のコマンドを実行します。<mount_dir>はドライブのマウントディレクトリを示します。

# /<mount_dir>/X64LIN/setup  /<mount_dir>

Hitachi PP Installerの起動方法の詳細は，NNMiのリリースノートを参照してください。

Hitachi PP Installerの起動画面で「I」を入力し，インストールできるソフトウェアの一覧を表示する。

カーソルを「JP1/Network Node Manager i」に移動させ，スペースキーで選択し，「I」を入力する。

インストールを続行するか確認するメッセージが表示されます。

「y」または「Y」を入力する。

インストーラの指示に従って情報を入力する。

デフォルト値を使用する場合は，値を入力しないで［Enter］キーを押してください。デフォルト値は，角括弧"[ ]"で囲まれた値です。

NNMi WebサーバーのHTTPポート番号の指定

NNMiにアクセスするためのNNMi WebサーバーのHTTPポート番号を入力します。ほかのプログラムが使用していないポート番号を入力してください。デフォルト値は20480です。

（入力例）

** Network Node Manager i Installer **

* Starting NNMi installation.

*Enter default port for HTTP server

* [20480]

8004[図データ]

NNMi WebサーバーのHTTPSポート番号の指定

NNMiにアクセスするためのNNMi WebサーバーのHTTPSポート番号を入力します。ほかのプログラムが使用していないポート番号を入力してください。デフォルト値は20481です。

（入力例）

*Enter default port for HTTPS server

* [20481]

8443[図データ]

入力内容の表示およびインストール開始可否の確認

上記の入力内容が表示されるので，入力内容に問題がなくインストール開始する場合は「yes」を，入力内容を変更したい場合は「no」を入力します。

（入力例）

* http port : 20480

* https port : 20481

* Do you start installation with above settings you entered ? (yes/no)

* If you need to change the settings, please enter no.

yes[図データ]

インストール前チェックの実施およびインストール続行可否の確認

インストールが開始すると，初めにインストール前チェック処理が実施されます。

メモ

インストール前チェックでは，「表1‒1　NNMi管理サーバーのインストール前チェックリスト」に記載されている項目を確認するため，NNMiが使用するポートが利用できるかをチェックします。

NNMiが使用するすべてのポートが利用できることを確認します。NNMiが使用するポート一覧やファイアウォールの通過方向は，「付録E　NNMiが使用するポートの一覧」を参照してください。

このインストール前チェックに問題がなければ，そのままインストールを続けます。

インストール前チェックに問題がある場合，インストーラは問題内容を出力し，インストールを続けるかユーザーに確認します。インストールを続ける場合は「yes」，インストールを終了する場合は「no」を入力してください。

（インストール前チェックに問題があった場合の入力例）

* Starting NNMi Precheck ...

* TCP Port: [20481] is used.

* UDP Port: [162] is used.

* NNMi Precheck result: NG

* There are some problem(s) with the settings.

* Do you want to continue NNMi installation ? (yes/no)

* If you enter no, the installation will stop.

no[図データ]

重要

インストールは数十分掛かることがありますが，途中でインストールを中断しないでください。中断した場合，不正な状態となり，通常の手段では再インストールできなくなるおそれがあります。

インストール前チェックの結果が「OK」になっても，インストールの成功を保証するものではありません。このため，「1.　インストール前チェックリスト」を参照し，インストール前のチェックリストが完了していることを確認してください。

システムアカウントのパスワードの設定

しばらく経過すると，システムアカウントのパスワードの設定画面が表示されるので，パスワードを入力します。

パスワードは，1文字以上，最大40文字まで入力できます。使用できる文字は，半角英数字（A-Z，a-z，0-9），およびアンダーバー（_）です。

インストール後に設定する場合は，「¥quit」を入力します。

* Setup system password for the initial sign-in to the NNMi console.

* If you want to setup the password later, enter "¥quit".

* Please enter system password:

* Please enter system password again:

メモ

システムアカウントは，インストールプロセスで作成する特別な管理者アカウントです。NNMiコンソールへ最初にサインインするときに使用します。NNMiコンソールで管理者ロールのユーザーを作成したあとは，通常は使用しません。システムアカウントはインストール終了後も有効ですが，コマンドラインの実行や復旧目的にだけ使用されます。システムパスワードの変更方法については，「1.5.5　システムアカウントのパスワードの設定」を参照してください。

2.1.3　インストール終了後の作業

NNMiのインストール後に必要な作業を説明します。OSの種類に関わらず実施してください。

(1)　ウイルス対策ソフトウェアのウイルスチェック除外設定をする

ウイルス対策ソフトウェアの影響で，NNMiが使用しているファイルおよびディレクトリに対するファイルアクセスに，排他制御によるロックが掛かることがあります。この影響で，NNMiサービスの起動失敗や異常終了，またはコマンドの実行が遅延することがあります。NNMiの稼働中にウイルスチェックをする場合は，次のディレクトリ配下をチェック対象から外してください。

Windowsの場合

NNMiのインストールディレクトリ

NNMiのデータディレクトリ

<drive>:¥Program Files¥Hitachi¥Cm2NNMi（存在しない場合があります）

<HA_mount_point>¥NNM（クラスタ構成の場合）

Linuxの場合

/opt/OV

/var/opt/OV

<HA_mount_point>/NNM（クラスタ構成の場合）

NNMiの停止中にウイルスチェックをしてNNMiを再起動する場合は，上記のディレクトリに対するウイルスチェックが完了したことを確認してから起動してください。

(2)　NNMiのシステムアカウントのパスワードを設定する

NNMiインストール時に，システムアカウントの設定をスキップした場合，NNMiコンソールに最初にサインインするためのアカウントのパスワードを設定します。パスワードの設定には，nnmchangesyspw.ovplスクリプトを使用します。nnmchangesyspw.ovplスクリプトを引数なしで実行し，メッセージに従ってパスワードを登録してください。

(3)　言語環境を設定する（Linuxの場合だけ）

OSの設定などによっては，マシンのリブート時にovstartコマンドがLANG=Cで自動的に起動される場合があります。この場合，バックグラウンド・プロセスでは英語のメッセージが出力されます。意図した言語でメッセージの出力をおこなうためには，システム起動時にovstartコマンドがサポートしているロケールで起動されるように，次の設定を行います。

設定手順

ovstartコマンドが NNMiインストール時の言語で起動されるように，次の設定を行ってください。

[設定個所]

/opt/OV/bin/netmgt ファイル内の /opt/OV/bin/ovstart の前

/opt/OV/bin/nettrap ファイル内の /opt/OV/bin/ovstart nnmtrapreceivermd の前

[設定内容]

次のいずれかが記載されていることを確認し，必要であれば追加してください。

LANG=ja_JP.utf8
export LANG

または

LANG=ja_JP.UTF-8
export LANG

または

LANG=C
export LANG

または

LANG=en_US.utf8
export LANG

または

LANG=en_US.UTF-8
export LANG

または

LANG=zh_CN.utf8
export LANG

(4)　Java最大ヒープサイズを確認する

インストール中に，物理メモリに応じてJava最大ヒープサイズ（-Xmx）の値が自動的に設定されます。リリースノートの「4.　メモリ所要量およびディスク占有量」および「9.1 システム」を参考にして，-Xmxの値を見直してください。監視対象の規模に変更があった場合も，同様に見直してください。

(5)　インシデントの自動トリム設定を確認する

NNMi 12-10以降，新規インストールの場合，インシデントの自動トリムが有効化されます。「21.20　古いSNMPトラップインシデントを自動でトリムする」を参考にして，自動トリムの有無，トリム実施のしきい値と削除量，削除対象の設定を見直してください。監視対象の規模に変更があった場合も，同様に見直してください。

(6)　NNMiサービスを開始する

ovstartコマンドを実行して，NNMiサービスを開始します。

(7)　管理者ロールのアカウントを作成する

NNMiコンソールにサインインして，管理者ロールのアカウントを作成します。

NNMiサインイン用ウィンドウを表示する。

Webブラウザのアドレス入力用のウィンドウに次のURLを入力します。

http://<fully_qualified_domain_name>:<port>/nnm/

<fully_qualified_domain_name>は，NNMi 管理サーバーの完全修飾ドメイン名を表し，<port>は，インストール中に設定したNNMi WebサーバーのHTTPポート番号を表します。

システムアカウントのユーザー名とパスワードを入力し，サインインボタンをクリックする。

ユーザー名：system

パスワード：「(2)　NNMiのシステムアカウントのパスワードを設定する」で作成したシステムアカウントのパスワード

ユーザーアカウントを作成する。

NNMiコンソールの［設定］ワークスペース＞［セキュリティ］＞［ユーザーアカウント］＞［新規作成］アイコンをクリックします。名前とパスワードを入力してから，［保存して閉じる］アイコンをクリックしてユーザーアカウントを保存します。詳細については，NNMiヘルプの「ユーザーアカウントを設定する（［ユーザーアカウント］フォーム）」を参照してください。

重要

名前は，1〜40文字までが入力できます。使用できる文字は，英数字（A-Z，a-z，0-9），ピリオド（.），アンダーライン（_），アットマーク（@），およびハイフン（-）です。

パスワードは，1文字以上の任意の文字数が入力できます。使用できる文字は，英数字（A-Z，a-z，0-9），および半角記号です。

ユーザーアカウントに管理者ロールを割り当てる。

NNMiコンソールの［設定］ワークスペース＞［セキュリティ］＞［ユーザーアカウントのマッピング］＞［新規作成］アイコンをクリックし，次の項目を指定します。

ユーザーアカウント：手順3で作成したユーザーアカウント

ユーザーグループ：NNMi管理者

［保存して閉じる］アイコンをクリックしてマッピングを保存します。詳細については，NNMiヘルプの「ユーザーアカウントのマッピングタスク」を参照してください。

重要

ユーザーグループは新規に作成しないで，デフォルトのユーザーグループから選択してください。

2.2　クイックスタート設定ウィザードを使用する

この項では，NNMiの基本的な設定タスクについて説明します。これらのタスクは，必ずNNMiをインストールしたあとに行ってください。クイックスタート設定ウィザードで設定できる項目は非常に少ないため，NNMiで監視を始めるために必要なすべての設定を行うことはできません。通常は，NNMiコンソールから設定を行うことを推奨します。次のような初期設定（例えばテスト環境）では，クイックスタート設定ウィザードを使用することもできます。

SNMPコミュニティ文字列の設定

限られた範囲のネットワークノードの検出

ネットワークアドレス変換（NAT）を使用した結果，重複するIPアドレスを含むネットワークでエリアを管理する場合は，クイックスタートウィザードで検出する1つのアドレスドメイン（重複しないアドレス）を選択します。次に，NNMiヘルプの「NAT環境内で重複するアドレス」または「13.　NAT環境の重複IPアドレスの管理」を参照してください。

初期管理者アカウントの設定

重要

クイックスタート設定ウィザードを使用して，SNMPバージョン3（SNMPv3）の設定を完了させることはできません。SNMPv3を使用して監視するデバイスがある場合は次を実行します。

NNMiコンソールを開く。

［設定］ワークスペースの［通信の設定］を選択する。

SNMPv3設定を完了する。

初期設定が完了したあとは，NNMiコンソールを使って，ネットワークトポロジへのノードの追加や監視の設定のような，追加の設定タスクを行うことができます。詳細については，NNMiヘルプを参照してください。

メモ

検出シードおよび自動検出ルールについて

検出シードとは，NNMiによるネットワークトポロジの検出を助けるためのノードです。例えば，監視環境内のコアルータなどがシードになります。各シードは，IPアドレスまたはホスト名によって識別されます。NNMiヘルプの「自動検出ルールを設定する」を参照してください。

シードとして指定したデバイスが，追加検出の開始ポイントとなるように検出を設定するには，自動検出ルールを作成して設定してください。NNMiヘルプの「検出シードを指定する」を参照してください。

シードとして指定したデバイスだけが検出されるように検出を設定するには，自動検出ルールを作成しないでください。

検出プロセスの概要については，NNMiヘルプの「スパイラル検出の動作原理」を参照してください。

インストールプロセスが完了したあとで，次の手順でクイックスタート設定ウィザードを起動する。

クイックスタート設定ウィザードは，インストール後すぐに実行する必要があります。クイックスタート設定ウィザードを手動で起動するには，次のURLにアクセスします。

http://<fully_qualified_domain_name>:<port>/quickstart/

<fully_qualified_domain_name>はNNMi管理サーバーの完全修飾ドメイン名で，<port>はインストール時に設定したポート番号です。

使用しているNNMi管理サーバーに複数のドメイン名がある場合は，NNMiでは，インストール時にその中から1つを選択します。NNMiが使用している完全修飾ドメイン名を判断するには，nnmofficialfqdn.ovplスクリプトを実行します。詳細については，nnmofficialfqdn.ovplリファレンスページを参照してください。

NNMiクイックスタート設定ウィザードが，Webブラウザのウィンドウで開きます。

次のようにログインする。

ユーザー名：system

パスワード：「2.1.3　インストール終了後の作業」の「(1)　NNMi のシステムアカウントのパスワードを設定する」で作成したシステムアカウントのパスワードです。

［コミュニティ文字列の設定］ページで，検出範囲内にあるノードのどれかのコミュニティ文字列を入力し，［追加］をクリックする。

メモ

NNMiは，コミュニティ文字列を，既知のデバイスと自動的に照合します。特定のデバイスと各コミュニティ文字列の関連づけを，手動で行う必要はありません。

［SNMPコミュニティ文字列］のリストに，検出範囲内のすべてのノードのコミュニティ文字列が含まれるまで手順3を繰り返し，［次へ］をクリックする。

ここで追加したSNMPコミュニティ文字列が，NNMiデータベースに保存されます。NNMiコンソールでは，SNMPコミュニティ文字列は，［通信の設定］フォームの［デフォルトのSNMPv1/v2コミュニティ文字列］タブに表示されます。

［自動検出ルールの設定］ページで，既存のルール名と［含まれるIPアドレス範囲］との関連づけを行う。検出規則のためのIPアドレス範囲を入力し，［次へ］をクリックする。

次は，有効なIPアドレス範囲の例です。

10.1.1.*

10.1.1.1-99

10.10.50-55.*

10.1-7.1-9.1-9

［シードの設定］ページで，ネットワークに検出シードの情報を入力し，［追加］をクリックする。そのあと，［次へ］をクリックする。

検出シードを，IPアドレスまたは完全修飾ドメイン名の形式で入力します。これらシードで示されたネットワークデバイスによって，NNMiのスパイラル検出プロセスがネットワークを検出できるようになります。

メモ

コマンドラインから，nnmloadseeds.ovplコマンドを使用してシードをロードできます。詳細については，nnmloadseeds.ovplリファレンスページを参照してください。

［シードテストの結果］ページで，通信テストの結果を確認する。

手順3で特定したコミュニティ文字列では，どのシードノードにも到達できない場合には，［前へ］をクリックし，［コミュニティ文字列の設定］ページまで戻ってください。コミュニティ文字列を修正してから，［次へ］をクリックします。

すべてのノードに到達できるまで，手順7を繰り返したら，［次へ］をクリックする。

［管理者アカウントの設定］ページで，NNMiソフトウェアを管理する新規アカウントのユーザー名を入力し，パスワードを設定して［次へ］をクリックする。

［要約］ページで，指定した情報を確認し，次のどちらかを実行する。

設定の変更を行う場合は，［前へ］をクリックします。

現在の設定を使用する場合，［コミット］をクリックします。

［ウィザードは終了しました］ページで，ネットワークの一部を検出するためにNNMiを正常に設定したことが表示されたら，次のどちらかを実行する。

戻ってもう一度実行する場合は，［前へ］をクリックします。

NNMiコンソールユーザーインタフェースを起動する場合は，［UIを起動］をクリックします。NNMiの使用を開始するには，「3.　NNMi入門」を参照してください。

メモ

Windowsの場合，インストール後，ウイルス対策ソフトウェアを再起動します。

2.3　NNMiのライセンスを取得する

恒久ライセンスキーをインストールしていない場合は，NNMi製品には，NNMiのインストール後60日間有効な一時試用ライセンスキーが含まれています。できるだけ早く，恒久ライセンスキーを入手し，インストールしてください。

重要

NNMi 12-60より，ライセンスキーのフォーマットが変更になりました。

NNMi 12-50以前のライセンスキーは，NNMi 12-60以降には適用できません。NNMi 12-60以降にバージョンアップして利用する場合は，事前に日立パスワードセンターから新フォーマットのライセンスキーを入手して，NNMiに適用する必要があります。（バージョンアップ後に新フォーマットのライセンスキーをNNMiに適用してください。）

2.3.1　恒久ライセンスキーのインストールを準備する

一時試用ライセンスでは，250ノードまでの制限が付けられています。一時試用ライセンスキーでNNMiを実行している場合，恒久ライセンスでサポートできる数以上のノードを管理できる場合があります。しかし恒久ライセンスが有効になると，NNMiはライセンスされている数まで自動的に管理対象ノードを減少します。

ライセンス情報を追跡する際には，次の点に注意してください。

消費量：NNMiは，NNMiのライセンス容量限界までノードを検出および管理します（切り上げ）。

VMware環境：デバイスプロファイルがvmwareVMの各デバイスは，1/10のノードと同等です。

ほかのすべてのデバイスは1つの検出されたノードと同等です。

管理対象から除外するノードをご自身で決定する場合は，新規ライセンスキーをインストールする前に，重要でないノードをNNMiコンソールを使用して削除してください。

(1)　ライセンスの種類および管理対象ノードの数の確認

現在，NNMiが使用しているライセンスの種類を確認するには，次の手順に従います。

NNMiコンソールで，［ヘルプ］＞［Network Node Manager iについて］の順にクリックする。

［Network Node Manager iについて］ウィンドウで，［ライセンス情報］をクリックする。

［消費量］フィールドに表示されている値を探す。

この値が，現在NNMiが管理しているノードの数となります。

恒久ライセンスがサポートできるノード数が，現在NNMiが管理しているノード数より少ない場合は，NNMiコンソールを使用して，あまり重要でないノードを削除する。

詳細については，NNMiヘルプの「ノードを削除する」を参照してください。

2.3.2　恒久ライセンスキーを取得してインストールする

恒久ライセンスキーを申請するには，次の情報が必要です。

ソフトウェア使用許諾契約書

NNMi管理サーバーのIPアドレス

ライセンスキーを適用する製品媒体のバージョン・リビジョン

お客様の企業情報または団体情報

恒久ライセンスキーの取得方法およびインストール方法は，リリースノートを参照してください。

2.3.3　一時試用ライセンスの切り替えについて

NNMiのインストール直後は，NNMiの一時試用ライセンスが適用されます。

NNMi Advancedの機能を検証する場合は，一時試用ライセンスを切り替えてください。

NNMiとNNMi Advancedの一時試用ライセンスを切り替える方法については，リリースノートを参照してください。

2.4　NNMiをアンインストールする

2.4.1　NNMiをアンインストールする（Windowsの場合）

NNMiをアンインストールするシステムに，管理者権限を持つユーザーでログオンする。

UACが有効な場合，ビルトインAdministrator以外のユーザーでは，管理者への昇格が必要です。

NNMiのサービスをすべて停止する。

［コントロールパネル］＞［プログラムと機能］で，「Network Node Manager」を選択して［アンインストールと変更］をクリックする。

アンインストールを開始するか確認するメッセージが表示されるので，「yes」を入力し，アンインストールを開始する。

（入力例）

** Network Node Manager i Installer **
* Starting uninstallation ? (yes/no) =>
yes

アンインストールが終了したら，NNMiのインストールディレクトリとデータディレクトリを削除する。

アンインストールを実行しても，NNMiのインストールディレクトリとデータディレクトリが削除されない場合は，手動で削除します。

インストール時にデフォルト値を選択した場合は，次のディレクトリを削除します。

<drive>:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥

<drive>:¥ProgramData¥Hitachi¥Cm2NNMi¥

一時ディレクトリおよび一時ファイルなどを削除する。

NNMiが作成する次の一時ディレクトリおよび一時ファイルなどを削除します。

存在できるものをすべて列挙しているため，存在しなくても問題ありません。なお，アンインストールのログ出力ファイル（NNMUninstall.log）は，必要に応じてコピーを取得してから削除してください。

%TEMP%¥HPOvInstaller¥
%TEMP%¥HPOvLic.log
%TEMP%¥HPOvPerlA-install.log
%TEMP%¥Install_Autopass.log
%TEMP%¥hsperfdata_Administrator
%TEMP%¥InstallerData
%TEMP%¥JP1NNMiMIBLoad.log
%TEMP%¥MicroFocusOvInstaller¥
%TEMP%¥OpenTextInstaller¥
%TEMP%¥NNMUninstall.log
%TEMP%¥NNM_X.X.X_HPOvInstaller.txt (Xには1桁以上の数字が入ります)
%TEMP%¥NNM_X.X.X_MicroFocusOvInstaller.txt (Xには1桁以上の数字が入ります)
%TEMP%¥NNM_X.X_OpenTextInstaller.txt (Xには1桁以上の数字が入ります)
%TEMP%¥nmscreatedb.log
%TEMP%¥nnm_hotfixes.log
%TEMP%¥nnm_installconfig_vbs.log
%TEMP%¥nnm_premigration.log
%TEMP%¥nnm_preinstallcheck_phaseI.log
%TEMP%¥nnm_preinstallcheck_phaseII.log
%TEMP%¥ovRemoveDir.exe
%TEMP%¥ovDetach.exe
%TEMP%¥ovinstallparams.ini
%TEMP%¥ovCleanUp.bat
%TEMP%¥persistent_state
%TEMP%¥preinstallcheck
%TEMP%¥JP1NNMiInstaller.log
%TEMP%¥JP1NNMiPostinstaller.log
%TEMP%¥InstallScript.iap_xml
%TEMP%¥nnm_preupgrade.log
%TEMP%¥nnm_pre_dialogcheck.log
%TEMP%¥OvLauncher.log
%TEMP%¥nnm_pre-uninstall.log
%TEMP%¥nnmilog¥
<drive>:¥ProgramData¥apregid.com.hpe

環境変数を削除する。

NNMiをアンインストールしても環境変数「OVCSL_LOG」，「OVCSL_LOG_APPLICATION」，「OVCSL_LOG_FILE」およびNNMiインストール時に環境変数「PATH」に追加された「<NnmInstallDir>bin¥」は，削除されません。手動で削除してください。

<NnmInstallDir>は環境変数「NnmInstallDir」に設定された値です。

2.4.2　NNMiをアンインストールする（Linuxの場合）

NNMiをアンインストールするシステムに，root権限を持つユーザーでログインする。

NNMiのサービスをすべて停止する。

NNMiのアンインストーラを起動する。

次のコマンドを実行して，Hitachi PP Installerを起動します。

# /etc/hitachi_x64setup

指示に従ってNNMiのアンインストールを選択し，アンインストールを実行する。

アンインストールが終了したら，NNMiのインストールディレクトリとデータディレクトリを削除する。

アンインストールを実行しても，NNMiのインストールディレクトリやデータディレクトリなどが削除されない場合は，手動で削除します。

次のディレクトリを削除します。

インストールディレクトリ

/opt/OV

データディレクトリ

/var/opt/OV

一時ディレクトリおよび一時ファイルなどを削除する。

NNMiが作成する次の一時ディレクトリおよび一時ファイルなどを削除します。

存在できるものをすべて列挙しているため，存在しなくても問題ありません。なお，アンインストールのログ出力ファイル（NNMUninstall.log）は，必要に応じてコピーを取得してから削除してください。

/var/tmp/HPOvPerlA-install.log
/var/tmp/jp1nnmi
/var/tmp/JP1NNMiInstaller.log
/var/tmp/JP1NNMiPostinstaller.log
/var/tmp/rpm-tmp.xxx (xxxには1桁以上の英数字が入ります)
/tmp/install.dir.xxx (xxxには1桁以上の数字が入ります)
/tmp/ia_remove.shxxx.tmp (xxxには1桁以上の数字が入ります)
/tmp/HPOvInstaller
/tmp/MicroFocusOvInstaller
/tmp/OpenTextInstaller
/tmp/NNMUninstall.log
/tmp/NNM_X.X.X_HPOvInstaller.txt (Xには1桁以上の数字が入ります)
/tmp/NNM_X.X.X_MicroFocusOvInstaller.txt (Xには1桁以上の数字が入ります)
/tmp/NNM_X.X_OpenTextInstaller.txt (Xには1桁以上の数字が入ります)
/tmp/debug
/tmp/JP1NNMiMIBLoad.log
/tmp/hsperfdata_bin
/tmp/hsperfdata_nmsdbmgr
/tmp/hsperfdata_nmsproc
/tmp/hsperfdata_root
/tmp/nnm-premigration.log
/tmp/nnm_preinstallcheck_phaseI.log
/tmp/nnm_preinstallcheck_phaseII.log
/tmp/ovinstallparams.ini
/tmp/persistent_state
/tmp/postInstall
/tmp/postRemove
/tmp/preInstall
/tmp/preRemove
/tmp/preinstallcheck
/tmp/nnm-preupgrade.log
/tmp/nnm_pre_dialogcheck.log
/usr/share/apregid.com.hpe

2.5　インストールおよび初期スタートアップのトラブルシューティング

2.5.1　インストールの問題

(1)　問題：NNMiのインストールに，現在のホストシステム上の空き領域以上のディスクの容量が必要である（Linuxの場合）

(a)　解決方法

LinuxにNNMiをインストールする場合，バイナリをインストールする場所（$OV_INST_DIR）やデータファイルを保存する場所（$OV_DATA_DIR）を選択できません。初期設定でのこれらの場所は，次の設定となります。

OV_INST_DIR=/opt/OV

OV_DATA_DIR=/var/opt/OV

/opt/OVまたは/var/opt/OVのどちらかのディスク容量が十分でない場合は，下記の回避方法を使用して状況を改善してください。

必要な場合は，NNMiをアンインストールする。

インストールターゲットから，バイナリをインストールしてデータファイルを保存するのに十分なディスク容量がある大きなパーティションへの，シンボリックリンクを作成する。

シンボリックリンクを作成するための構文は次のとおりです。

ln -s <large disk> /opt/OV
ln -s <large disk> /var/opt/OV

重要

インストール先の上位ディレクトリのアクセス権は555以上にしてください。

NNMiをインストールする。

(2)　問題：インストール時に，プレインストール手順（フェーズII）に失敗し，/tmp/nnm_preinstall_phaseII.logファイルで詳細を確認する必要があることを示すメッセージが表示される（Linuxの場合）

(a)　解決方法

NNMiインストールスクリプトは，2つのグループ（nmsgrpとnmsdb）と2つのユーザー（nmsprocとnmsdbmgr）および対応する$HOMEディレクトリを自動的に作成します。これらの操作は，次の理由によって失敗することがあります。

IT部門でuseraddまたはgroupaddコマンドを無効にしたため，ユーザーおよびグループを作成できない。

$HOMEディレクトリがNFS上に存在する場合に，ルートユーザーが$HOMEディレクトリを作成できない。

NNMiインストーラがこれらのグループ，ユーザー，またはディレクトリの作成に失敗すると，インストールが中止されます。この場合は，ユーザーを手動で作成してインストールを再開できます。

nmsgrpグループでnmsprocユーザーを作成する。

$HOMEディレクトリを任意のディレクトリに設定しますが，そのディレクトリは存在する必要があります。

nmsdbグループでnmsdbmgrユーザーを作成する。

$HOMEディレクトリを任意のディレクトリに設定しますが，そのディレクトリは存在する必要があります。

これらの操作に失敗することがわかっていて，ユーザーID，グループID，または$HOMEの場所を制御する必要がある場合は，グループ，ユーザー，および$HOMEディレクトリを作成してからインストーラを起動できます。

useraddコマンドによってユーザーを作成した場合，デフォルトでは/home/<ユーザー名>がホームディレクトリになります。

2.5.2　初期スタートアップの問題

(1)　問題：NNMiコマンドラインツールをLinuxのNNMi管理サーバーで実行できない

(a)　解決方法

システム環境変数PATHに/opt/OV/binが含まれていることを確認します。含まれていない場合は，システム環境変数PATHに/opt/OV/binを追加します。

(2)　問題：JBossポートの競合

(a)　解決方法

デフォルトでは，JBossアプリケーションサーバーは，NNMiとの通信に複数のポートを使用します。通常これらのポートは，JBoss以外のアプリケーションにも使用されます。

ポートの競合を解決するには，次の手順を実行します。

管理者権限（Windowsの場合）またはroot権限（Linuxの場合）のあるユーザーとして，テキストエディタで次のファイルを開く。

Windows：%NnmDataDir%Conf¥nnm¥props¥nms-local.properties

%NnmDataDir%は，インストール時に指定するデータディレクトリです。

Linux：/var/opt/OV/conf/nnm/props/nms-local.properties

既存のエントリを修正し，競合しているポート番号を使用できるポート番号に変更する。

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop -c
ovstart -c

メモ

Windowsの場合，［ovstop］と［ovstart］のコマンドは，［スタート］メニューからも実行できます。NNMiが使用するポートの詳細については，nnm.portsリファレンスページを参照してください。

(3)　問題：NNMiがノードを検出しない

(a)　解決方法

ワークスペースのナビゲーションパネルで［設定］ワークスペースから［検出］を開く。

［シード］ビューを開く。

［検出シードの結果］列の値を確認する。

検出されたノードの大部分のステータスが，［ノードが作成されました］以外の場合は，NNMiの検出プロセスが正常に動作していなかったということです。

ステータスが［ノードが作成されました（非SNMPデバイス）］の場合は，ノードに対してpingが可能であるか，また，nnmsnmpwalk.ovplコマンドを実行してノードから情報を取得できるかを確認します。詳細については，nnmsnmpwalk.ovplリファレンスページを参照してください。これらのツールが実行できない場合は，次の事項を確認してください。

a　ノードにpingし，応答するか確認してください。

b　ノードでSNMPが有効になっているか確認してください。

c　ノードのSNMPエージェントのアクセスリストに，NNMi管理サーバーが含まれていることを確認してください。

d　NNMiがノードを適切に検出できるよう，ノードの正しいコミュニティ文字列を設定していることを確認してください。この情報は，［通信の設定］フォームの［デフォルトのSNMPv1/v2コミュニティ文字列］タブに表示されています。

e　ルータ，スイッチ，またはファイアウォールについて，検出を制限することのあるアクセス制御リストが設定されていないことを確認します。

詳細については，NNMiヘルプの「検出を設定する」を参照してください。

(4)　問題：NNMi管理サーバーにアクセスしていると，NNMiコンソールを起動できない（Windowsの場合）

WebブラウザでNNMi管理サーバーをポイントしているときに，NNMiコンソールを起動できない場合，ファイアウォールがHTTPポートをブロックしている可能性があります。この問題のトラブルシューティングを行うには，NNMi管理サーバーでブラウザを実行します。このブラウザからはNNMiコンソールにアクセスでき，リモートのブラウザからはアクセスできない場合，ポートをチェックする必要があります。

この問題を解決するには，許可ポートリストに%NnmDataDir%Conf¥nnm¥props¥nms-local.propertiesファイルに示されているnmsas.server.port.web.http値を追加します。詳細については，nnm.portsリファレンスページを参照してください。

%NnmDataDir%は，インストール時に指定するデータディレクトリです。

(5)　問題：NNMiのインストールまたはアップグレードが正常に終了した後，NNMiコンソールが開かない

incidentActions.*.*.logファイル（NNMi管理サーバーの/var/opt/OV/log/nnm/publicディレクトリから入手可能）の最新のコピーに次のエラーメッセージも表示される。

SEVERE: com.hp.ov.nms.events.action.log.ActionLogger createActionServer:

java.io.FileNotFoundExceptionが原因で/var/opt/OV/tmp/actionServer.portからポート番号を取得できませんでした。

/var/opt/OV/tmp/actionServer.port.lock (権限拒否) : java.io.FileNotFoundException:

/var/opt/OV/tmp/actionServer.port.lock (権限拒否)

(a)　解決方法

NNMi管理サーバーで次のコマンドを実行します。

a./opt/OV/bin/ovstop

b.chown root:root /var/opt/OV/tmp

c.chmod 777 /var/opt/OV/tmp

d.chmod g+s /var/opt/OV/tmp

/var/opt/OV/tmpディレクトリでactionServer.portファイルとactionServer.port.lockファイルを探します。 それらのファイルが存在する場合は削除します。

NNMi管理サーバーで次のコマンドを実行します。

/opt/OV/bin/ovstart

第2編　入門編

3　NNMi入門

ここでは，NNMiでネットワーク管理を始める上で必要な，NNMiへのアクセス方法，ネットワークを検出するための設定方法の概要について説明しています。オペレータおよび管理者用の詳細情報は，NNMi ヘルプに記載されています。

3.1　NNMiへアクセスする

NNMiをインストールし，インストール後の設定作業を完了すると，ネットワークの管理を開始できます。ネットワークのモニタリングやイベント処理のタスクについては，Webブラウザのウィンドウで開くNNMiコンソールからアクセスできます。

NNMiコンソールにアクセスするには，次の手順に従います。

対応Webブラウザを使用していることを確認する。

「1.1　ハードウェアおよびソフトウェアを確認する」を参照してください。

WebブラウザでJavaScript，NNMi管理サーバーからのポップアップウィンドウを有効にし，ブラウザがNNMi管理サーバーからのCookieを受け入れるようにする。

「1.5.3　NNMiコンソール用のWebブラウザの有効化」を参照してください。

次のURLをWebブラウザのアドレス入力用のウィンドウに入力する。

http://<fully_qualified_domain_name>:<port>/nnm/

<fully_qualified_domain_name>は，NNMi管理サーバーの完全修飾ドメイン名を表し，<port>は，JBossアプリケーションサーバーがNNMiコンソールとの通信で使用するポートを表します。

使用しているNNMi管理サーバーに複数のドメイン名がある場合は，NNMiでは，インストール時にその中から1つを選択します。NNMiが使用している完全修飾ドメイン名を判断するには，nnmofficialfqdn.ovplスクリプトを実行します。詳細については，nnmofficialfqdn.ovplリファレンスページを参照してください。

ブラウザでWindowsオペレーティングシステムにインストールされているNNMi管理サーバーを指定してもNNMiコンソールを起動できない場合，NNMi管理サーバーでWindowsファイアウォールがhttpポートをブロックしているおそれがあります。「(4)　問題：NNMi管理サーバーにアクセスしていると，NNMiコンソールを起動できない（Windowsの場合）」を参照してください。

NNMiサインイン用ウィンドウで，ユーザーのアカウント名とパスワードを入力したあと［サインイン］をクリックする。

詳細については，次の「ユーザーのアカウントとロール」を参照してください。

ユーザーのアカウントとロール

インストール後のNNMiへの初回アクセスのために，NNMiは特別のシステムアカウントを提供します。通常は，このシステムアカウントは使用しないでください。

通常のご使用のために，NNMi管理者は各ユーザー（またはユーザーのグループ）のアカウントを設定し，各アカウントに対し定義済みのユーザーロールを割り当てます。ユーザーロールによって，NNMiコンソールにアクセスできるユーザーと，各ユーザーが使用できるワークスペースとアクションが決まります。NNMiでは，NNMiコンソールへのアクセスに対して次のユーザーロールが用意されています。これらのロールは，プログラムによってあらかじめ定義されていて修正はできません。

管理者

オペレータレベル2

オペレータレベル1

ゲスト

チームのNNMiサインインのアクセス設定を行う前に，各チームのメンバに，どの定義済みのNNMiロールを割り当てるのがふさわしいかを判断します。ロールは階層的です。つまり，階層内で高位のロールは下位のロールの特権をすべて含みます（管理者が最高位で，ゲストが最低位です）。

コマンドラインへのアクセスと同様，ユーザーのアカウントとロールは，NNMiコンソールで設定します。詳細については，NNMiヘルプの「セキュリティの設定」を参照してください。

NNMiには，インストール時に作成された自己署名証明書を使用してそのまま使用できるhttps設定があります。自己署名証明書の代わりに認証機関による署名入り証明書を使用する場合の詳細については，「10.　NNMiでの証明書の使用」を参照してください。

3.2　NNMiヘルプへアクセスする

NNMiヘルプには，NNMiコンソールの使用方法が記載されています。

NNMiのヘルプにアクセスするには，NNMiコンソールメニューバーの［ヘルプ］をクリックし，メニューにある最初の区切りラインの上の項目の1つをクリックしてください。

メモ

NNMiコンソールには，情報入力フォームが含まれています。フォーム名は，ウィンドウの左上に表示されます。どのNNMiフォームからでも，フォームのヘルプ情報にアクセスできます。［ヘルプ］メニューで，［<xyz>フォームの使用法］（<xyz>は現在のフォームのタイトル）をクリックしてください。

3.3　ネットワーク検出を設定する

NNMiを使ってネットワークの検出や管理を開始するときは，テスト用ネットワークから始め，ごくわずかのインタフェースしか持たない少数のノードを検出，管理するようにNNMiを設定することをお勧めします。クイックスタート設定ウィザード（「2.2　クイックスタート設定ウィザードを使用する」を参照）を使用すると，このような小さな構成が簡単に設定できます。NNMiのインストール直後は，クイックスタート設定ウィザードを使用することを推奨します。

NNMiの操作に慣れると，その豊富な機能がどのようにネットワークの管理に使われているのかを理解できるようになります。NNMiで管理するネットワークトポロジは，検出規則や管理領域を系統的に追加すれば，次第に拡張できます。

ここでは検出プロセスを開始する前に必要となる設定作業について，簡単に概要を説明します。次の表のチェックリストでは，これらの作業についてまとめてあります。

表3‒1　検出設定チェックリスト

チェック欄

（はい/いいえ）

タスク

検出するノードのすべてがネットワークに接続され，それに対応しているSNMPのバージョン（SNMPv1，SNMPv2c，またはSNMPv3）の設定がされているかを検証します。

ネットワーク管理者より，管理するノードの読み取り専用コミュニティ文字列を入手します。

NNMiコンソールを使用して，「3.3.1　コミュニティ文字列を設定する」に記載されている手順でコミュニティ文字列を設定します。

NNMiコンソールを使用して，「3.3.2　自動検出ルールを設定する」に記載されている手順でスパイラル検出プロセスを設定します。

NNMiコンソールを使用して，「3.3.3　検出の進行状況を確認する」に記載されている手順でスパイラル検出プロセスをチェックします。

検出プロセスの詳細については，NNMiヘルプの「ネットワークの検出」を参照してください。

3.3.1　コミュニティ文字列を設定する

コミュニティ文字列を使用してNNMiを設定するには，次の手順に従います。

ワークスペースのナビゲーションパネルで，［設定］ワークスペースを選択する。

次のように，［通信の設定］フォームを開く。

［デフォルトのSNMPv1/v2コミュニティ文字列］タブで，［新規作成］アイコンをクリックする。

［デフォルトの読み取りコミュニティ文字列］フォーム上の，［読み取りコミュニティ文字列］のボックスに，検出範囲内の特定のノードのコミュニティ文字列を入力して，［保存して新規作成］アイコンをクリックする。

手順4を繰り返し実行し，検出範囲内のノードのコミュニティ文字列をすべて入力してから，［保存して閉じる］アイコンをクリックする。

［通信の設定］フォームで，［保存して閉じる］アイコンをクリックする。

デバイスのコミュニティ文字列の設定やファイルからのコミュニティ文字列のロードの詳細については，NNMiヘルプの「通信プロトコルの設定」を参照してください。

3.3.2　自動検出ルールを設定する

ネットワーク管理で最も重要な作業の1つは，常に最新のネットワークトポロジを把握しておくことです。NNMiは，ネットワークノードの継続検出によってこのトポロジを維持します。NNMiの検出プロセスは，根本原因解析やトラブルシューティングのツールが，インシデント解決のための正確な情報を提供することを保証します（メモの「ネットワーク検出」を参照）。

自動検出ルールを設定するには，次の手順に従います。

ワークスペースのナビゲーションパネルで［設定］ワークスペースから［検出］を開く。

［検出の設定］フォームを開く。

［自動検出ルール］タブをクリックし，次に［新規作成］アイコンをクリックする。

［自動検出ルール］フォームの［基本］に，ルールの名前および順序の情報を入力する。

この順序は，ほかの自動検出ルールに対するこのルールの優先度を示す数値です。詳細については，［ヘルプ］＞［自動検出ルール フォームの使用法］の順にクリックします。

［このルールの自動検出開始ポイント］で，この規則に対する適切な自動検出アクションを選択する。

［このルールのIPアドレス範囲］で，［新規作成］アイコンをクリックする。

［IPの自動検出範囲］フォームで，［IPの範囲］を入力し，［範囲のタイプ］は［ルールに含める］という設定のままにして，［保存して閉じる］アイコンをクリックする。

［自動検出のルール］フォームで，［保存して閉じる］アイコンをクリックする。

手順3から手順8までを繰り返し実行し，使用するすべてのルールを追加する。

［検出の設定］フォームで，［保存して閉じる］アイコンをクリックし，すべての新しい自動検出ルールをNNMiデータベースに保存する。

［設定］ワークスペースから［検出］を開き，［シード］をクリックする。

［新規作成］アイコンをクリックする。

［検出シード］のフォームで，ホスト名またはIPアドレスを入力し，［保存して閉じる］アイコンをクリックする。

手順12および手順13を繰り返して，検出シード用のすべてのホスト名またはIPアドレスを追加する。

検出の進行状況を監視する方法は，「3.3.3　検出の進行状況を確認する」を参照してください。

検出の設定の詳細については，NNMiヘルプの「検出を設定する」を参照してください。

メモ

ネットワーク検出

NNMiは，ネットワークにあるデバイス（スイッチやルータなど）に関する情報を収集したり，ユーザーやチームにとって重要なデバイスの管理を積極的に行ったりします。検出モードは，次の2つから選ぶことができます。

検出シード：ユーザーが，デバイスのリストを提供して，NNMiの検出やモニタリングの対象となるデバイスを包括的に管理します。

自動検出ルール：ユーザーが，検出シードとなるアドレスやホスト名のリストを提供し，NNMiは，この情報を包括的な自動検出用の開始ポイントとして使用します。さらに，ユーザーは，IPv4アドレス範囲やMIB II sysObjectIDを提供すれば，NNMiの検出プロセスに制限がかけられます。

検出モードの選択が済むと，NNMiスパイラル検出を行います。NNMiは，さまざまなプロトコルや技術を利用して，ネットワークインベントリについての豊富な情報を収集し，デバイス（サブネットやVLAN）間の関係を確認し，デバイス間の接続関係を正確に描き出します。NNMi Causal Engineは，各デバイス（および，デバイスに関連する各インタフェースやアドレス）の現在のステータスを判定し，発生した問題や潜在的な問題を検出した場合には，積極的に通知を行います。

ダイナミック検出プロセスは，長期的に継続されます。ネットワーク管理ドメインの中で変更があった場合は，NNMiスパイラル検出が自動的に情報を更新します。

ネットワーク検出の詳細については，NNMiヘルプの「ネットワークの検出」を参照してください。

3.3.3　検出の進行状況を確認する

スパイラル検出プロセスの起動後，そのプロセスが正しく実行されているか検証します。

メモ

スパイラル検出は動的であるため，NNMiは継続的にネットワークノードを検出します。NNMiは，検出ルールに新しいノードが追加されるたびに，そのノードを検出し，ノードに関するトポロジ情報を収集し，ノードのモニタリングを開始します。

検出の進行状況の測定には幾つかの方法があります。検出の進行状況を調べるには，次のどれかの処理を実行します。

検出中に，［設定］＞［検出］＞［シード］の順にクリックして，シードのステータスをチェックします。［検出シードの結果］列のステータス情報を確認します。検出が終わりに近づくと，ノードの大半が「ノードが作成されました」のステータスになります。

検出中に，［ヘルプ］＞［システム情報］の順にクリックして，［データベース］タブから検出の進行状況を確認します。［データベースのオブジェクト数］を1時間に数回確認します。ノード，SNMPエージェント，インタフェース，IPアドレス，L2接続のフィールドの数は，やがて一定になります。サンプリング周期を通して，この数字の増加がなければ，検出は完了です。

検出中に，NNMiコンソールで，［インベントリ］ワークスペースから［ノード］を選択します。［合計］フィールドの値を1時間に数回確認します。サンプリング周期を通して，この値が増加していなければ検出は完了です。

検出中に，NNMiコンソールで［ツール］＞［NNMiセルフモニタリングのグラフ］＞［検出の進行状況］をクリックして，検出の進行状況を確認します。

検出中に，NNMiコンソールで［ツール］＞［ステータス分布グラフ］＞［ノードステータス］をクリックして，検出の進行状況を確認します。

検出中に，NNMiコンソールの［トポロジマップ］ワークスペースの［ネットワークの概要］をクリックします。マップの複雑性の成長を1時間監視します。マップの成長が鈍化し，サンプリング周期を通してこの成長が止まれば，検出は完了です。

メモ

検出で問題が発生する場合は，「(3)　問題：NNMiがノードを検出しない」を参照してください。

第3編　設定編

4　設定の一般概念

この章では設定の概念を説明しています。詳細については，このマニュアルの5章以降で説明しています。この章では，すべてのNNMi設定領域に適用されるベストプラクティスについても記載しています。

4.1　タスクフローモデル

このマニュアルの設定編では，次のタスクフローに役立つ情報を記載しています。

概念−設定領域の概略を理解できます。このマニュアルの情報は，NNMiヘルプの情報を補足しています。

計画−設定にどのように取り組むかを決定します。これは，会社のネットワーク管理の文書化を開始または更新する良い機会です。

設定−NNMiコンソール，設定ファイル，コマンドラインインタフェースの組み合わせを使用して，NNMiに設定します。具体的な手順については，NNMiヘルプを参照してください。

評価−NNMiコンソールで，設定結果を確認します。設定を最適なものにするために，必要に応じて調整します。

調整−（任意）設定を調整して，NNMiのパフォーマンスを向上します。

4.2　ベストプラクティス：既存の設定を保存する

大きな設定変更を行う前には，既存の設定内容のコピーを保存しておくことをお勧めします。設定内容を元に戻したい場合に，簡単に戻すことができます。

nnmconfigexport.ovplコマンドを使用して，現在の設定内容を保存します。保存した設定内容を復元するには，nnmconfigimport.ovplコマンドを使用します。

これらのコマンドの使用方法の詳細については，該当するリファレンスページを参照してください。

nnmconfigexport.ovplコマンドではSNMPv3資格情報は保持されません。詳細については，nnmconfigexport.ovplコマンドのリファレンスページを参照してください。

4.3　ベストプラクティス：作成者属性を使用する

多くのNNMi設定フォームには，作成者属性が含まれています。

これらのフォーム上で設定を作成，または変更する場合，［作成者］属性に作成者の組織を識別する値を設定してください。NNMi設定をエクスポートするときに，作成者値を指定して作成者の組織がカスタマイズした項目だけを引き出すことができます。

NNMiをアップグレードする際，作成者の属性値が，ユーザーが作成した作成者になっている設定は上書きされません。

4.4　ユーザーインタフェースモデル

NNMiコンソールフォームの一部では，データベースの更新にトランザクションアプローチが使用されます。NNMiコンソールのフォームで行った変更は，フォームを保存して閉じる操作がNNMiコンソールで行われないと有効になりません。保存されていない変更が含まれるフォームを閉じると，NNMiによって保存されていない変更があるため，終了を続行するか確認するメッセージが表示されます。

4.5　順序

幾つかのNNMiコンソール設定フォームには，設定を適用する優先順位を設定する順序属性が含まれています。ある設定領域で，NNMiは設定内容に対して各項目を，順序番号が最も小さい（低い）ものから大きいものへの順に，NNMiが一致するまで評価し続けます。一致した時点で，NNMiは一致する設定の情報を使用し，これ以上探すのをやめます（通信設定は例外です。NNMiは通信設定を完了するために，そのほかのレベルで情報の検索を続行します）。

順序属性は，NNMiの設定で重要な役割を果たします。予想外の検出結果やステータス結果が出た場合は，その領域の設定の順序を確認してください。

順序番号は次の個所でも使用されますが，その意味は異なります。

メニューおよびメニュー項目の順序は，関連するメニューのローカルコンテキスト内の項目の順序を設定します。

［ノードグループマップの設定］フォームのトポロジマップ順序で，［トポロジマップ］ワークスペースの項目の順序が設定されます。

順序属性が指定の設定領域にどのように影響するかの情報については，その領域のNNMiヘルプを参照してください。

ヒント

各設定領域で，小さい順序番号は最も限定的な設定に適用し，大きな順序番号は限定度の低い設定に適用します。

各設定領域で，すべての順序番号を一意にしてください。初期設定時は，通常の間隔の順序番号を使用して，将来設定を変更できるような柔軟性を確保しておいてください。例えば，1番目から3番目の設定には100，200，300の順序番号を付けます。

4.6　ノードグループおよびインタフェースグループ

ノードグループやインタフェースグループに対し，ビューに表示する内容を絞り込むためのフィルタを設定できます。ノードグループに「重要なCiscoルーター」を設定した場合を例にとると，「重要なCiscoルーター」だけをフィルタに設定すれば，目的のルーターだけをビューに表示できます。

ノードグループは，次のどれか，またはすべての目的に使用できます。

モニタリングの設定

インシデントペイロードのフィルタリング

テーブルフィルタリング

マップビューのカスタマイズ

グローバルネットワーク管理機能のリージョナルマネージャーからグローバルマネージャーに渡されたノードのフィルタリング

インタフェースグループは，次のどれか，またはすべての目的に使用できます。

検出からのインタフェース除外

モニタリングの設定

インシデントペイロードのフィルタリング

テーブルフィルタリング

任意のフィルタリング可能な属性に基づきノードグループの階層を作成し，マップビューのドリルダウン，監視，またはその両方の設定の継承を管理できます。

4.6.1　グループの重複

グループ定義をどのように使用するかに関係なく，最初のステップでは，どのノードまたはインタフェースをグループのメンバーにするかを定義します。さまざまな目的でグループが作成されるため，それぞれの対象が複数のグループに含まれる可能性があります。次の例を考えてみます。

監視を目的とした場合，ベンダーや場所を問わずすべてのスイッチに3分間のポーリング間隔を設定するのがよいでしょう。この場合は，デバイスカテゴリフィルタを使用します。

保守を目的とした場合は，すべてのCiscoスイッチを1つのグループにして，IOSのアップグレードのときに，このグループをまとめてサービス停止にできるようにするのがよいでしょう。この場合は，ベンダーフィルタを使用します。

可視化の場合は，10.10.*.*サイト上のすべてのデバイスを，ステータスを反映したコンテナにグループ化するのがよいでしょう。この場合は，IPアドレスフィルタを使用します。

IPアドレスが10.10.10.3のCiscoスイッチはこの3つのグループすべてに適しています。

設定や表示に便利なようにグループセットを豊富にするのもよいですが，使用されることのない必要以上のエントリを一覧に詰め込み過ぎることのないよう，バランスをとってください。

4.6.2　ノードグループのメンバーシップ

NNMiは，設定されたノードグループと検出したノードを比較して，ノードグループのメンバーシップを判断します。

［追加のノード］タブで指定したノードは，すべてそのノードグループのメンバーです。

メモ

NNMi管理サーバーのリソースを大きく消費するため，［追加のノード］タブを使用したノードグループへのノード追加は極力避けてください。

［子ノードグループ］タブで指定した少なくとも1つのノードグループのメンバーになっているノードは，すべてそのノードグループのメンバーです。

［デバイスフィルター］タブの1つ以上のエントリ（存在する場合），および［追加のフィルター］タブで指定したフィルタに一致するノードは，すべてそのノードグループのメンバーです。

(1)　階層/包含

単純で再利用可能な小さいグループを作成し，これらを監視や可視化のために階層的に組み合わせることができます。階層的なノードのコンテナを使用すると，障害時にオブジェクトの場所やタイプに関する手がかりが得られるような，より良いマップビューを作成できます。NNMiによって，グループの定義とそのドリルダウンの順序を完全にコントロールできます。

単純で再利用可能な小さいグループを最初に作成し，そのあとでより大きなグループを作成するときに，これらを子グループとして指定します。また，最初にいちばん大きな親グループを指定し，それから子グループを作成していくこともできます。

例えば，ネットワークがCiscoスイッチ，Ciscoルーター，Nortelスイッチ，Nortelルーターで構成されているとします。Ciscoデバイスの親グループとすべてのスイッチの親グループを作成できます。親を作成してその子を指定するときに階層が定義されるので，Ciscoスイッチのようなそれぞれの子グループには複数の親ができる可能性があります。

階層は，次の状況で使用すると効果的です。

監視ニーズが類似したノードのタイプ

ノードの地理的な配置

まとめてサービスを停止にするノードのタイプ

オペレータの職務別によるノードのグループ

マップビューおよびテーブルビューでグループを使用すると，伝播された（設定可能な）グループのステータスが表示されます。

メモ

グループ定義を使用して監視設定を指定する際に，階層は設定の順序を示すものではないことを留意してください。小さい順序番号の設定は，ノードに適用されます。順序番号を注意深く増やすことで，設定の継承概念を真似ることができます。

子ノードグループに循環参照となるノードグループを設定して保存すると，警告が表示され，保存に失敗します。

(2)　デバイスフィルター

検出中，NNMiは直接情報をSNMPクエリーで収集し，そこからほかの情報を，デバイスプロファイルを通じて導き出します。詳細については，「6.1.1　デバイスプロファイルとデバイスの属性」を参照してください。システムオブジェクトIDを収集することによって，NNMiは該当するデバイスプロファイルを検索し，次の情報を導き出します。

ベンダー

デバイスカテゴリ

カテゴリ内のデバイスファミリ

デバイスのプロファイル

導き出されたこれらの値は，デバイスプロファイルそのものとともに，フィルタとして使用できます。

例えば，あるベンダー製のすべての対象物を，デバイスタイプやファミリに関係なくグループ化できます。また，ある種類のデバイス（例えばルーター）をすべて，ベンダーを問わずにまとめることができます。

(3)　追加のフィルター

追加のフィルターエディタを使用すると，次のようなフィールドに一致するカスタム論理を作成できます。

hostname（ホスト名）

mgmtIPAddress（管理アドレス）

hostedIPAddress（アドレス）

sysName（システム名）

sysLocation（システムのロケーション）

sysContact（システムの連絡先）

capability（ケーパビリティの一意キー）

customAttrName（カスタム属性名）

customAttrValue（カスタム属性値）

isSnmpNode（エージェント有効）

isNnmSystemLocal（NNMi管理サーバー）

sysOidNode（システムオブジェクトID）

devCategoryNode（デバイスのカテゴリ）

devVendorNode（デバイスのベンダー）

devFamilyNode（デバイスのファミリ）

nnmSystemName（ホスト名，大文字と小文字を区別）

nodeName（ノード名）

securityGroupName（セキュリティグループ名）

securityGroupUuid（セキュリティグループのUUID）

tenantName（テナント名）

tenantUuid（テナントのUUID）

フィルタには，AND，OR，NOT，EXISTS，NOT EXISTS，およびグループ化（括弧）操作を含めることができます。詳細については，NNMiヘルプの「ノードグループの追加のフィルターを指定する」を参照してください。

ケーパビリティは，すでに検出されたデバイスからノード詳細を調べることによって，確認できます。

(4)　追加のノード

ノードグループに対してノードを限定するには，［追加のフィルター］を使用することをお勧めします。フィルタを使用して指定することが難しい重要なデバイスがネットワークに含まれている場合，それらのデバイスは個々のホスト名でグループに追加できます。ホスト名ごとにノードをノードグループに追加するのは，ほかに手段がない場合だけにしてください。

メモ

NNMi管理サーバーの使用リソースが増加するため，［追加のノード］タブを使用してノードグループにノードを追加することはほとんどありません。

4.6.3　ノードグループのステータス

次のどちらかのアルゴリズムを使用してNNMiによってノードグループのステータスが決定されます。

ノードグループの任意のノードの最も重大なステータスと一致するようにノードグループを設定します。このアプローチを使用するには，［ステータスの設定］フォームの［最も重大なステータスを伝達］チェックボックスをオンにします。

各ターゲットステータスに設定されたしきい値を使用してノードグループのステータスを設定します。例えば，警戒域のターゲットステータスのデフォルトしきい値は20％です。NNMiでは，ノードグループ内のノードの20％（または，それ以上）が警戒域ステータスになると，ノードグループのステータスが警戒域に設定されます。このアプローチを使用するには，［ステータスの設定］フォームの［最も重大なステータスを伝達］チェックボックスをオフにします。ターゲットしきい値のパーセントしきい値は，このフォームの［ノードグループのステータス設定］タブで変更できます。

大きなノードグループのステータス計算には大量のリソースが必要になるため，新規インストール時にはノードグループのステータス計算はNNMiのデフォルトでオフに設定されます。ステータスの計算は，各ノードグループの［ノードグループ］フォームの［ステータスの計算］チェックボックスで有効にできます。

4.6.4　インタフェースグループ

インタフェースグループは，ノード内のインタフェースを，ifType別に，またはifAlias，ifDesc，ifName，ifIndex，IPアドレスなどほかの属性別にフィルタリングします。インタフェースグループは階層も包含もありませんが，インタフェースをホストしているノードのノードグループに基づいてメンバーシップをさらに限定できます。

インタフェースグループを，ノードグループと同様のカスタムケーパビリティおよび属性でフィルタリングできます。

インタフェースグループの制限は，タブ内およびタブ間でまとめてANDを適用します。

重要

インタフェースグループのインタフェースは，次の条件での検出中に必ずしも最初から除外されるわけではありません。

インタフェースグループは，インタフェースグループ定義で1つ以上のインタフェース機能をフィルタリングして作成されます。

インタフェースグループは，［除外対象インタフェース］検出の設定オプションで指定されます。インタフェース機能はインタフェースグループのインタフェースに適用されたあとに，再検出中に除外フィルタが再適用されると除外されます。

NNMiで提供されるインタフェース機能と［除外対象インタフェース］検出の設定オプションの詳細については，NNMi ヘルプ「管理」を参照してください。

4.7　ノード／インタフェース／アドレス階層

NNMiはモニタリングの設定を，次のように適用します。

インタフェースの設定−NNMiは，最初に一致したインタフェースの設定定義に基づき，各ノードのインタフェースとIPアドレスに一致するものがないか，照合する。

照合するときに最初に適用されるのは，順序番号が最も小さいインタフェースの設定定義です。

ノードの設定−1.の処理で一致しなかった各インタフェースまたはIPアドレスは，ノードの設定定義に基づき照合される。

このとき，最初に適用されるのは，順序番号が最も小さいノードの設定定義です。

メモ

子ノードグループは，順序階層に含まれます。親ノードグループの順序番号のほうが小さい場合（例えば，親=10，子=20），親ノードグループに指定された監視設定は子ノードグループ内のノードにも適用されます。親ノードグループ監視設定を上書きするには，子ノードグループの順序番号を親よりも小さな番号に設定します（例えば，親=20，子=10）。

デフォルト設定−1.または2.の照合でノード，インタフェース，またはIPアドレスが一致しなかった対象については，デフォルトの監視設定が適用される。

4.8　NNMi設定およびデータベースのリセット

検出を完全に再スタートしてNNMi設定をすべてやり直したい場合，またはNNMiデータベースが破損した場合は，NNMi設定およびデータベースをリセットできます。このプロセスで，NNMi設定，トポロジ，およびインシデントのすべてが削除されます。

次の手順で説明しているコマンドの詳細は，該当するリファレンスページを参照してください。

次の手順に従ってください。

（任意）現在のNNMi設定をとっておきたい場合は，nnmconfigexport.ovplコマンドを使用してNNMi設定をXMLファイルに出力する。

nnmconfigexport.ovplコマンドではSNMPv3資格情報は保持されません。詳細については，nnmconfigexport.ovplコマンドのリファレンスページを参照してください。

（任意）nnmtrimincidents.ovplコマンドを使用して，NNMiインシデントをアーカイブする。

nnmtrimincidents.ovplコマンドのデフォルトではインシデントはアーカイブされないため，-archiveOnlyオプションを付与して実行します。詳細については，nnmtrimincidents.ovplコマンドのリファレンスページを参照してください。

NNMiサービスを，次のコマンドを使用して停止する。

ovstop -c

（任意）既存のデータベースをバックアップする。

この手順によってデータベースが削除されます。実行する前に次のコマンドで既存のデータベースをバックアップしておくことをお勧めします。

nnmbackup.ovpl -type offline -target <backup_directory>

NNMiデータベースを削除して再作成する。

nnmresetembdb.ovpl -nostart

NNMiサービスを，次のコマンドを使用して開始する。

ovstart -c

これで，NNMiを新しいシステムにインストールしたときと同じ，デフォルト設定だけの状態となります。

次のどれかの方法で，NNMiの設定を開始する。

「クイックスタート設定ウィザード」を使用する。

NNMiコンソールの［設定］ワークスペースで情報を入力する。

nnmconfigimport.ovplコマンドを使用して，手順1.で保存したNNMi設定の一部またはすべてをインポートする。

重要

nnmconfigimport.ovplコマンドを使用して大量の設定をインポートする場合（9,500個のノードグループや10,000個のインシデントの設定など），-timeoutオプションを使用して，インポートトランザクションのタイムアウトをデフォルト値の60分（3,600秒）よりも長くなるように調整することを検討してください。詳細については，nnmconfigimport.ovplコマンドのリファレンスページを参照してください。

4.9　NNMi 設定ファイルのモデルファイル

NNMiのインストール時の設定ファイルの内容は，モデルファイルとして以下のフォルダにコピーされます。

Windowsの場合：%NnmInstallDir%support¥JP1Model_VV-RR

Linuxの場合：/opt/OV/support/JP1Model_VV-RR

※VV-RRにはバージョン番号が入ります。（例：13-50）

モデルファイルには，「.model」という拡張子が付いています。

設定ファイルをカスタマイズしたあと，デフォルトの設定に戻したい場合は，モデルファイルをコピーして，拡張子の「.model」を削除してください。

メモ

NNMiのモデルファイルでは，新規インストールの場合は初期設定値が保存されますが，バージョンアップの場合，バージョンアップ前に変更した設定はそのままになります。

NNMiのサポートするserver.propertiesは2種類あるため，以下のようにコピーします。

ファイルパス

コピー名

Windowsの場合：%NnmDataDir%nmsas¥NNM¥server.properties

Linuxの場合：/var/opt/OV/nmsas/NNM/server.properties

server.properties.NNM.model

Windowsの場合：%NnmDataDir%nmsas¥nms¥server.properties

Linuxの場合：/var/opt/OV/nmsas/nms/server.properties

server.properties.nms.model

5　NNMi通信

NNMiは，Simple Network Management Protocol（SNMP）とInternet Control Message Protocol（ICMP ping）の両方のプロトコルを使用して，デバイスを検出し，デバイスのステータスと稼働状態を監視します。お使いの環境で実行可能な通信を確立するには，ネットワークのさまざまなデバイスとエリアについて，アクセス認証，適切なタイムアウトと再試行回数をNNMiに設定します。トラフィックを削減するためやファイアウォールを考慮するために，ネットワークの幾つかの領域でプロトコルを無効にできます。通信の設定の値は，NNMiの検出およびステータスポーリングの基礎となります。NNMiは，検出またはポーリングのクエリーを作成するときに，各デバイスに該当する値を適用します。そのため，ネットワークの幾つかの領域とのSNMP通信を無効にするようNNMiを設定すると，NNMi検出とNNMi状態ポーリングはどちらも，SNMP要求をその領域には送信できません。

5.1　通信の概念

NNMiは，主に要求と応答の方式でSNMPとICMPを使います。ICMP ping要求への応答で，アドレスの応答性を確認します。特定のMIBオブジェクトに対するSNMP要求への応答で，ノードに関するより総合的な情報を取得します。

メモ

（SNMPエージェントに加えて）Webエージェントが設定されている場合，NNMiは追加のプロトコルを使用できます。例えば，VMware環境用のSOAPプロトコルなどです。

次の概念がNNMi通信設定に適用されます。

通信の設定レベル

ネットワーク待ち時間とタイムアウト

SNMPアクセス制御

SNMPバージョンの優先

管理アドレスの優先

ポーリングプロトコル

nnmsnmp*.ovplコマンドの動作

5.1.1　通信の設定レベル

NNMi通信設定には，次のレベルがあります。

特定のノード

領域

グローバルなデフォルト

各レベルで，アクセスの資格情報，タイムアウトと再試行の値，管理プロトコルの有効化（ICMPやSNMPなど），管理プロトコルのアクセス設定（SNMPなど）を指定できます。あるレベルで設定をブランクにしておくと，NNMiは次のレベルのデフォルトを適用します。

指定ノードと通信するとき，NNMiは設定を次のように適用します。

ノードが特定のノードの設定と一致する場合，NNMiはその設定に含まれている通信の値をすべて利用する。

1.の特定ノードの設定に当てはまるものがなければ，NNMiはノードがどの領域に属するか判断する。

領域は重なる可能性があるため，NNMiでは順序番号が最小のものと一致する領域が使用されます。NNMiは，その領域に対して指定された値を，設定が一致したノードに適用します。領域の設定が一致した場合，それ以降の順序番号の大きな領域設定は使用されません。

1.と2.に当てはまる設定がなければ，NNMiはグローバルなデフォルト設定を使用して，残りの空白の設定に取り込む。

特定のデバイスとの管理プロトコル通信に使用される値は，必要な設定がすべて決まるまで，累積的に構築されます。

5.1.2　ネットワーク待ち時間とタイムアウト

通常のネットワーク遅延は，NNMi管理サーバーがICMPクエリーとSNMPクエリーへの応答を得るための待ち時間に影響を与えます。一般に，ネットワークのエリアが異なれば，応答が返る時間も異なります。例えば，NNMi管理サーバーが置かれているローカルネットワークからは，ほぼ即時の応答が返り，ダイヤルアップワイドエリアリンク経由でアクセスする遠隔地にあるデバイスからの応答は，通常はるかに長く時間が掛かります。

さらに，負荷が大きいデバイスは処理量が多いためICMPクエリーまたはSNMPクエリーにただちに応答できません。タイムアウトと再試行の設定を決定するときには，こうした遅延に関する事項を考慮してください。

ネットワーク領域と特定のデバイスの両方について，固有のタイムアウトと再試行の設定を行うことができます。設定によって，応答がない場合に要求を破棄するまでの，NNMiの応答待ち時間，NNMiがデータを要求する回数が決まります。

要求を再試行するたびに，NNMiは設定したタイムアウト値をそれまでのタイムアウト値に加算します。そのため，再試行するごとに停止時間が長くなります。例えば，NNMiの設定を5秒でタイムアウト，再試行は3回とすると，NNMiは最初の要求への応答を5秒待ちます。応答がない場合は再試行1回目の要求への応答は10秒待ち，2回目の要求への応答は15秒待ち，3回目の要求の応答は20秒待ってから次のポーリングサイクルに移ります。

5.1.3　SNMPアクセス制御

管理対象デバイス上のSNMPエージェントとの通信には，アクセス制御資格情報が必要です。

SNMPv1とSNMPv2c

各NNMi要求内のコミュニティ文字列は，応答するSNMPエージェントで設定されているコミュニティ文字列と一致する必要があります。通信はすべて，クリアテキスト（暗号化なし）でネットワークを通過します。

SNMPv3

SNMPエージェントとの通信は，ユーザーベースのセキュリティモデル（USM）に従います。各SNMPエージェントには，設定済みのユーザー名とそれに関連する認証要件のリストがあります（認証プロファイル）。すべての通信のフォーマットは，設定によって制御されます。NNMi SNMP要求は，有効なユーザーを指定し，そのユーザーに対して設定されている認証とプライバシの制御に従う必要があります。

認証プロトコルは，メッセージ認証を使用しないか，HMAC-MD5-96，HMAC-SHA-1，HMAC128-SHA-224，HMAC192-SHA-256，HMAC256-SHA-384，またはHMAC384-SHA-512のどれかを選択したものの，ハッシュベースのメッセージ認証コードを使用します。

プライバシプロトコルは，暗号化を使用しないか，DES-CBC，TripleDES，AES-128，AES-192またはAES-256のどれかを選択したものの，対称暗号化プロトコルを使用します。

DES-CBCは弱い暗号と考えられています。そのため，DES-CBCを使用する場合は，より強い暗号を選択することをお勧めします。NNMiが管理するノードでSNMPv3通信を設定する場合は，DES-CBCの使用はお勧めしません。

暗号の選択を変更する場合は，次の手順で実施します。

NNMiコンソールから，［設定］ワークスペースをクリックする。

［インシデント］フォルダを展開する。

［トラップサーバー］フォルダを展開する。

［トラップ転送設定..］をクリックする。

［プライバシプロトコル］リストで，より強い暗号を選択する。

NNMiは，（IPアドレスフィルタやホスト名フィルタ経由で定義された）ネットワークの領域のマルチSNMPアクセス制御資格情報の仕様をサポートします。NNMiは，設定したすべての値を，所定のSNMPセキュリティレベルで並行して試し，その領域内のデバイスと通信しようとします。NNMiがその領域で使用する最小限のSNMPセキュリティレベルを指定できます。NNMiは，各ノードから返される最初の値（デバイスのSNMPエージェントからの応答）を検出と監視の目的で使用します。

デフォルトのHA環境では，SNMPソースアドレスは物理クラスタノードアドレスに設定されます。SNMPソースアドレスをNNM_INTERFACE（仮想IPアドレスに設定される）に設定するには，ov.confファイルを編集して，IGNORE_NNM_IF_FOR_SNMPの値をOFFに設定する必要があります（デフォルトでは，これはONに設定されます）。

5.1.4　SNMPバージョンの優先

SNMPプロトコルはバージョン1からバージョン2（c）へと長年をかけて発展したもので，現在はバージョン3です。この間，とりわけセキュリティ機能は強化されてきました。NNMiは，どのバージョンでも処理できますし，全バージョンが混在した環境でも処理できます。

NNMiが特定のノードについて受信する最初のSNMP応答によって，そのノードとの通信にNNMiが使用する通信の資格情報とSNMPバージョンが決まります。

ノードのSNMPバージョンによって，NNMiでのノードからのトラップの受け入れが，次のように異なります。

NNMiがSNMPv3を使用して受信トラップのソースノードやソースオブジェクトを検出すると，NNMiは受信するSNMPv1，SNMPv2c，およびSNMPv3のトラップを受け入れます。

NNMiがSNMPv1または複数のSNMPv2cを使用して受信トラップのソースノードやソースオブジェクトを検出すると，NNMiは受信するSNMPv3トラップを廃棄します。

このトラップを受信する必要がある場合は，「21.8.1　SNMPv3以外で管理されているノードまたは監視対象外のノードのSNMPv3トラップを認証するためのNNMiの設定」の手順に従います。

SNMPバージョンと，ネットワークの各領域で受け入れられる最小レベルのセキュリティ設定を指定します。［SNMP最小セキュリティレベル］フィールドのオプションは，次のとおりです。

コミュニティのみ（SNMPv1）

NNMiは，コミュニティ文字列，タイムアウト，および再試行用に設定した値でSNMPv1を使って更新を試みます。NNMiは，SNMPv2cやSNMPv3の設定は試みません。

コミュニティのみ（SNMPv1またはv2c）

NNMiは，コミュニティ文字列，タイムアウト，および再試行用に設定した値でSNMPv2cを使って更新を試みます。SNMPv2を使ったコミュニティ文字列への応答がない場合は，NNMiはコミュニティ文字列，タイムアウト，および再試行用に設定した値でSNMPv1を使って通信を試みます。NNMiは，SNMPv3の設定は試みません。

コミュニティ

NNMiは，コミュニティ文字列，タイムアウト，および再試行用に設定した値でSNMPv2cを使って更新を試みます。SNMPv2を使ったコミュニティ文字列への応答がない場合は，NNMiはコミュニティ文字列，タイムアウト，および再試行用に設定した値でSNMPv1を使って通信を試みます。機能するものがない場合，NNMiはSNMPv3を試みます。

認証なし，プライバシなし

認証もプライバシもないユーザーについて，NNMiはタイムアウトと再試行用に設定した値でSNMPv3を使って通信を試みます。機能するものがない場合，必要に応じて，NNMiは認証はあるがプライバシがないユーザー，次に認証とプライバシがあるユーザーを試みます。

認証，プライバシなし

認証はあるがプライバシはないユーザーについて，NNMiはタイムアウトと再試行用に設定した値でSNMPv3を使って通信を試みます。機能するものがない場合，NNMiは認証とプライバシのあるユーザーを試みます。

認証，プライバシ

認証もプライバシもあるユーザーについて，NNMiはタイムアウトと再試行用に設定した値でSNMPv3を使って通信を試みます。

5.1.5　管理アドレスの優先

ノードの管理アドレスとは，NNMiがノードのSNMPエージェントと通信する場合に使用するアドレスです。ノードの管理アドレスを指定するか（特定ノードの設定で），またはノードに関連するIPアドレスの中からNNMiがアドレスを選択するようにできます。検出設定で検出から特定のアドレスを除外することによって，この動作を微調整できます。NNMiが管理アドレスを決定する方法については，NNMiヘルプの「[ノード] フォーム」を参照してください。

メモ

ハイパーバイザーNNMiを検出するには，管理アドレスではなくノード名が必要です。

NNMiは，デバイスの検出と監視を継続的に行います。最初のNNMi検出サイクルのあと，以前検出したSNMPエージェントが応答しない場合（例えば，デバイスのSNMPエージェントを再設定した場合など）は，［SNMPアドレス再検出を有効にする］フィールドの設定によってNNMiの動作が制御されます。

［SNMPアドレス再検出を有効にする］チェックボックスがオンになっている場合，NNMiは機能するアドレスの検索で設定した値を再試行します。

［SNMPアドレス再検出を有効にする］チェックボックスがオフになっている場合，NNMiはデバイスが「停止中」であると報告し，そのデバイスについて別の通信設定を試みません。

［SNMPアドレス再検出を有効にする］チェックボックスは，通信設定のすべてのレベルで使用できます。

自動検出ルール設定フィールドの［SNMPデバイスの検出］と［非SNMPデバイスの検出］は，NNMiのSNMP使用方法に影響します。詳細については，NNMiヘルプの「自動検出ルールの基本設定を設定する」を参照してください。

5.1.6　SNMPv3トラップと通知

デバイスと通信するためにNNMiでSNMPv3を使用する場合，検出プロセスを使用して，デバイスのエンジンID，ブートカウント，エンジン時間が識別されます。NNMiは，ユーザーおよびプロトコルに関する設定済みの詳細とこの情報を併用して，デバイスへのメッセージ送信を開始します。

デバイスからNNMiにトラップを送信する場合，トラップは単一パケットのトランザクションであり必要な情報を取得する手段がないため，デバイスにNNMi情報が存在しないことがあります。したがって，デバイス自体のエンジンID，ブートカウント，エンジン時間が，ユーザー名およびプロトコルの詳細とともにトラップで使用されます。デバイスの詳細については，NNMiでデバイス用に設定された内容と同じである必要があります。NNMiでは，デバイスごとに複数のSNMPv3ユーザーを設定できません。

通知は確認済みのパケットであるため，最初のパケットを開始するデバイス，および確認に応答するNNMiは対象外となります。このため，NNMiのエンジンID，ブートカウント，エンジン時間を取得するために，デバイスからNNMiに対して検出が実行されます。デバイスで使用されるユーザー名およびプロトコルの設定は，NNMiトラップ転送の設定（つまり，NNMiのSNMPv3エージェント設定）の内容と一致する必要があります。

5.1.7　ポーリングプロトコル

ネットワークの一部でNNMiがSNMPまたはICMP用を使用しないようにできます。例えば，インフラストラクチャ内のファイアウォールがICMPまたはSNMPトラフィックを制限する場合などです。

ネットワークのある領域にあるデバイスへのICMPトラフィックを無効にすると，NNMiでは次のような結果になります。

オプションの自動検出ルールPingスイープ機能は，ネットワーク領域内で追加ノードを見つけられません。すべてのノードが，シードからとして追加されるか，または近隣ARPキャッシュ，Cisco Discovery Protocol（CDP），またはExtreme Discovery Protocol（EDP）など，MIBオブジェクト要求への応答を通して使用できる必要があります。広域ネットワークデバイスは，すべてシードから追加されるようにしておかないと，監視できない場合があります。

State Pollerは，SNMP要求に応答するように設定されていないデバイスは監視できません。

オペレータはトラブルシューティングの間は，［アクション］＞［ノードアクセス］＞［Ping］を使ってデバイス到達可能性をチェックできません。

ネットワークのある領域にあるデバイスへのSNMPトラフィックを無効にすると，NNMiでは次のような結果になります。

検出では，デバイスが存在すること以外の情報は収集できません。すべてのデバイスで「No SNMP」デバイスプロファイルを適用します。

検出では，クエリーによって追加の近隣デバイスを見つけることができません。すべてのデバイスをシードに直接追加する必要があります。

検出では，デバイスから接続情報を収集できないため，デバイスはNNMiマップには未接続として示されます。

「No SNMP」デバイスファイルを持つデバイスについては，State PollerはICMP（ping）だけを使用するデバイスの監視のデフォルトが優先されます。

State Pollerは，コンポーネントの稼働状態やパフォーマンスデータをデバイスから収集できません。

Causal Engineは，近隣接続分析や，インシデントの根本原因を特定するために，デバイスと通信することができません。

5.1.8　nnmsnmp*.ovplコマンドの動作

nnmsnmp*.ovplコマンドは，NNMiデータベースで指定されていないデバイス通信設定の値を検索します。この方法ではovjbossプロセスが動作している必要があります。ovjbossプロセスが動作していない場合，nnmsnmp*.ovplコマンドは次のように動作します。

SNMPv1エージェントとSNMPv2cエージェントの場合，コマンドは未指定通信設定にデフォルト値を使用します。

SNMPv3エージェントの場合，ユーザーIDとパスワードを指定すると，コマンドは未指定通信設定にデフォルト値を使用します。ユーザーIDとパスワードを指定しないとき，コマンドはエラーになります。

5.2　通信の計画作成

次の項目を検討し，通信の計画を作成します。

デフォルトの通信設定

通信設定領域

特定のノードの設定

再試行とタイムアウトの値

アクティブなプロトコル

複数のコミュニティ文字列または認証プロファイル

5.2.1　デフォルトの通信設定を計画する

NNMiは，該当する領域や特定のノードで指定しなかった設定を，デフォルト値を使用して完成させるため，大半のネットワークで妥当なものになるようデフォルトを設定します。

NNMiが試す必要のある一般に使われるコミュニティ文字列がありますか？

ネットワークではどのようなタイムアウトと再試行のデフォルト値が合理的でしょうか？

ネットワークデバイスからNNMiにどのSNMPトラップを送信するのですか？

5.2.2　通信設定領域を計画する

領域とは，ネットワーク内で同じ通信設定を適用するのが妥当なエリアのことです。例えば，NNMi管理サーバーの近くにあるローカルネットワークからは，通常はすぐに応答が戻ってきます。複数ホップ離れたネットワークエリアなら応答にもっと時間がかかるのが普通です。

ネットワークのサブネットやエリアを個別に設定する必要はありません。ラグタイムが近い複数のエリアを1つの領域にまとめることができます。次のネットワークマップについて考えてみてください。

タイムアウトと再試行を考慮した場合，次のように領域を設定できます。

領域A　Net 1

領域B　Net 10，Net 20，およびNet 30を含める

領域C　さらに遠くにある外部のネットワーク

NNMi管理サーバーから1ホップまたは2ホップのパスのどちらを優先するようトラフィック管理構成が設定されているかに従って，Net 170をグループにまとめる最良の方法を決定します。

また，類似したアクセス資格認定を使用するデバイスをグループにまとめる場合にも領域を使用します。ネットワークのすべてのルーターで同じコミュニティ文字列（または数種類のコミュニティ文字列の一部）が使用されていて，命名規約（rtrnnn.yourdomain.comなど）でルーターを識別できる場合は，すべてのルーターを1つの領域に設定すれば，すべてのルーターが同じように処理されます。ワイルドカードを使ってデバイスをグループにまとめられない場合は，各デバイスを特定のノードとして設定できます。

同じタイムアウト／再試行の値とアクセス資格証明設定を1つの領域のすべてのノードに適用できるように，領域設定を計画してください。

領域定義は重複することがあり，1つのデバイスが複数の領域の定義にあてはまることもあります。NNMiは，順序番号が最も小さくて，ほかに一致する領域がない領域から設定を適用します。

5.2.3　特定のノードの設定を計画する

固有の通信設定要件を持つデバイスの場合，特定ノードの設定を使用して，そのノードの通信設定を指定します。特定ノードの設定の使用例として，次の例があります。

SNMPv2c/SNMPv3 GetBulk要求に適切に応答しないノード

ほかの類似ノードと名前のパターンが一致しないノード

特定のデバイスのSNMP通信を有効または無効にできます。NNMiヘルプの「[特定ノードの設定] フォーム (通信設定)」を参照してください。

5.2.4　再試行とタイムアウトの値を計画する

タイムアウトの時間を長く，再試行の回数を多く設定すると，ビジー状態であるか，離れたところにあるデバイスからより多くの応答が集められます。このように応答率が高まると，誤ったダウンメッセージを除外できます。しかし，実際にダウンしているデバイスに気づくのに時間がかかるようにもなります。ネットワークの各領域のバランスを見出すことは重要であり，このためにお使いの環境で値のテストと調整の期間が必要になるかもしれません。

各ホップの現在のタイムラグに関するヒントを得るには，次のコマンドを実行します。

Windows：それぞれのネットワークエリア内のデバイスに対してtracertを実行する。

Linux：それぞれのネットワークエリア内のデバイスに対してtracerouteを実行する。

5.2.5　アクティブなプロトコルを計画する

通信の設定と監視の設定を使用して，ネットワーク内でデバイスと通信を行うときにNNMiが生成するトラフィックの種類を制御できます。インフラストラクチャのファイアウォールで，ICMPまたはSNMPのトラフィックが許可されていない場合は，通信の設定を使用します。デバイスに関するデータの特定のサブセットが必要ない場合は，監視の設定を使用してプロトコルの使用を微調整します。通信または監視の設定のどちらかによってデバイスのプロトコルが無効にされると，NNMiはその種類のトラフィックをデバイスに送信しません。

メモ

SNMP通信を無効にするとデバイスの詳細な情報が得られないため，障害対処など機器の管理が困難になります。

各領域または特定のデバイスはICMPトラフィックを受信する必要があるか注意してください。

アクセスクレデンシャルを与えないデバイスとのSNMP通信を明示的に無効にする必要はありません。デフォルトで，NNMiはこれらのデバイスを「No SNMP」デバイスプロファイルに割り当て，ICMPだけを使ってデバイスを監視します。

（SNMPエージェントに加えて）Webエージェントが設定されている場合，NNMiは追加のプロトコル（例えば，VMware環境用のSOAPプロトコル）を使用できます。

5.2.6　コミュニティ文字列と認証プロファイルを計画する

ネットワークの各エリアで試みるコミュニティ文字列と認証プロファイルの計画を作成します。デフォルト設定と領域設定については，並行して試みる複数のコミュニティ文字列と認証プロファイルを設定できます。

メモ

可能性のあるコミュニティ文字列を試す間に，NNMiクエリーによってデバイスで認証失敗（authentication failure）が生成されることがあります。NNMiが初期検出を完了する間に出された認証失敗は，無視しても問題ないことをオペレータなどに知らせてください。または，領域と試行する関連コミュニティ文字列と認証プロトコルをできる限り厳しく設定して，認証失敗の数を削減することもできます。

環境でSNMPv1またはv2とSNMPv3が使用されている場合は，各領域で受け入れられる最低のセキュリティレベルを決定してください。

(1)　SNMPv1とSNMPv2のコミュニティ文字列

SNMPv1またはSNMPv2cアクセスが可能な領域では，領域内で使用されるコミュニティ文字列と特定のデバイスで必要とされるコミュニティ文字列を集めます。

(2)　SNMPv3の認証プロファイル

SNMPv3アクセスが可能なデバイスを含む領域では，受け入れられる最小限のデフォルト認証プロファイル，各領域に適した認証プロファイル，および特定のデバイスで使用される固有の認証資格証明を決定します。また，ネットワーク内で使用中の認証プロトコルとプライバシプロトコルも判断します。1つの特定ノードの設定，または領域の設定に対して，認証プロトコルとプライバシプロトコルを1つずつ設定することもできます。

NNMiがサポートするSNMPv3通信の認証プロトコル

HMAC-MD5-96

HMAC-SHA-1

HMAC128-SHA-224

HMAC192-SHA-256

HMAC256-SHA-384

HMAC384-SHA-512

NNMiがサポートするSNMPv3通信のプライバシプロトコル

DES-CBC

TripleDES

AES-128

AES-192

AES-256

5.3　通信の設定

この節では，次の項目について説明しています。

SNMPプロキシを設定する

NETCONFを使用するデバイスのサポート

VMwareハイパーバイザーベースの仮想ネットワークの検出と監視

Cisco ACIネットワークの検出と監視

マルチホームNNMi管理サーバー

この節を読んだあと，詳細な手順については，NNMiヘルプの「通信プロトコルの設定」を参照してください。

メモ

大幅な設定変更を行う前には，既存の設定のコピーを保存しておくことをお勧めします。詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

通信の次の領域を設定してください。

デフォルト設定

領域定義とその設定

特定のノードの設定

特定のノードについて，NNMiコンソールまたは構成ファイルで，ノードの設定ができます。

ヒント

定義した領域の順序番号をダブルチェックします。ノードが複数の領域を認証する場合，NNMiはそのノードの順序番号の最も小さい領域の設定を適用します。

5.3.1　SNMPプロキシを設定する

一部のネットワークでは，ネットワークデバイスとの通信にSNMPプロキシエージェントを使用します。次の図に，NNMiコンソールから［設定］＞［通信の設定］を使用して［SNMPプロキシアドレス］と［SNMPプロキシポート］を設定した場合に，NNMiが使用するSNMP通信手順を示します。

ヒント

コマンドラインからSNMPプロキシ設定を行う代わりの方法については，nnmcommunication.ovplリファレンスページを参照してください。

図5‒1　プロキシサーバーの使用

NNMi管理サーバーがSNMPプロキシアドレスとSNMPプロキシポートにSNMP要求を送信し，管理対象ルーターと管理対象スイッチから情報を取得する。

NNMi管理サーバーが特殊なプロキシvarbindであるSecurityPackAgentAddressOid OID（.1.3.6.1.4.1.99.12.45.1.1）で管理対象ルーターとスイッチのリモートアドレスおよびポートをエンコードし，このvarbindをSNMP要求に追加します。

SNMPプロキシサーバーがこの特殊なプロキシvarbindを読み取り，SNMP要求の送信先を判別して，NNMi管理サーバーによって要求された情報を取得するために管理対象ルーターとスイッチにSNMP要求を送信する。

管理対象スイッチとルーターがSNMPプロキシサーバーに応答し（SNMPプロキシアドレスとSNMPプロキシポートを使用），要求された情報を返す。

SNMPプロキシサーバーがNNMi管理サーバーに応答する（設定されたSNMPポートを使用）。

注：NNMiは，SecurityPackAgentAddressOid OID（.1.3.6.1.4.1.99.12.45.1.1）の使用をサポートするSNMPプロキシサーバーに対応しています。SNMPプロキシ設定を使用しているデバイスに対しては，次のプロパティに基づいてこのOIDをSNMP要求に含めます。

com.hp.nnm.snmp.USE_PROXY_VARBIND=true

このプロパティのデフォルトの設定はfalseです。

SNMPプロキシサーバーは，SNMPによる管理対象デバイスからの通知やトラップをNNMiに転送する。

NNMiは，SNMPプロキシから転送されてきたトラップのソースを判定するために，次のOIDの使用をサポートしています。

TrapForwardingAddressTypeOid .1.3.6.1.4.1.11.2.17.2.19.1.1.2.0（HP）

TrapForwardingAddressOid .1.3.6.1.4.1.11.2.17.2.19.1.1.3.0（HP）

Rfc3584TrapAddressOid .1.3.6.1.6.3.18.1.3.0（RFC 3584）

Rfc3584TrapCommunityOid .1.3.6.1.6.3.18.1.4.0（RFC 3584）

SNMPプロキシサーバーでNNMiを使用する場合，プロキシベンダーに連絡してこのリスト内のOIDをサポートしているかどうかを確認してください。

5.3.2　NETCONFを使用するデバイスのサポート

NNMiは，主としてSNMPを使用してサポート対象デバイスの管理情報を収集します。しかし，必要な管理情報がSNMPでは報告されない一部のベンダーのデバイスについては，NETCONFを使用する場合もあります。

現在，NNMiでNETCONFを使用する場合にサポートされているデバイスは，Juniper Networks QFabricシステムだけです。

ここでは，NETCONFについて簡単に紹介し，NNMiで管理対象デバイスをサポートするために，デバイスおよびNNMiの両方で必要な設定について説明します。

(1)　NETCONFとは何か

NETCONFは，SNMPと同様に，ネットワーク管理のためのIETF（Internet Engineering Task Force）規格です。IETF RFC（Request for Comments）4741および4742（Version 1）で定義されており，のちにRFC6241および6242（Version 1.1）によって更新されました。

NETCONFは主としてデバイスの設定手段として使用されますが，監視，ポーリング，障害通知の目的では，SNMPが最も広く使用されています。どのプロトコルを使用しても，NNMiにとって有用な管理情報が収集できます。

NNMiは，検出または再検出の場合にNETCONFを使用してデバイス情報（つまり，読み出し専用の情報）を収集します。デバイスの設定を変更する，または状態やパフォーマンス測定指標を監視する目的では，NETCONFを使用しません。

NETCONFは，XML形式のコマンド応答プロトコルであり，主としてSSH（Secure Shell）トランスポート層で動作します。NETCONFプロトコルは，幾つかの点で従来のデバイスコンソールで使用されるコマンドラインインタフェース（CLI）に似ています。しかし，XML形式のコマンドと結果は，人間とデバイスとの間のインタラクションよりも管理アプリケーションでの使用を念頭に設計されています。

NETCONFは比較的新しい管理プロトコルです。そのため，使用できるデバイスベンダーは，SNMPと比較すると限定的です。

ベンダーがNNMiで管理されているデバイスにNETCONFを実装する場合，次の点に注意してください。

NETCONFのコマンドは概してベンダー固有であることが多く，SNMPの多くの標準のベンダー固有のMIBほどは知られていません。その結果，NNMiがNETCONFを活用できる範囲はきわめて限定的です。

特定のベンダーがデバイスにNETCONFを実装し，NNMiで必要な管理情報をレポートする場合，NNMiでそのデバイス固有のNETCONFに対応する必要があります。

詳細については，「(3)　管理対象デバイスでのNETCONFの有効化と設定」，および「(4)　NNMiにNETCONFデバイスの認証情報を設定する」を参照してください。

(2)　NETCONFプロトコルの運用

NNMiと管理対象デバイスとの間のNETCONF通信の詳細なやり取りは，NNMiのユーザーに対して透過的です。しかし，トラブルシューティングには，次の手順が有効な場合があります。

NETCONFクライアント（NNMiなどの管理アプリケーション）は，管理対象デバイス上のNETCONFサーバー（サブシステム）との間でSSH接続を確立する。

有効なSSHユーザー名およびパスワードの認証情報は，クライアントが指定し，デバイスによって認証される必要があります。

クライアントアプリケーションとデバイスは，<hello>メッセージの形式で機能を交換する。

クライアントは，標準の<get>または<get-config>演算，およびデバイスに定義されたベンダー固有の演算など，RPC（Remote Procedure Call）メッセージ形式によってデバイスに対して要求を開始する。

デバイスは，演算の結果をRPC応答メッセージの形式で返す。

クライアントアプリケーションは，要求の送信および応答の処理を終了したときには，デバイスに<close-session>RPCメッセージを送信する。

デバイスは，<ok>RPC応答メッセージによって受信を確認する。

最後に，双方がSSH接続を終了する。

(3)　管理対象デバイスでのNETCONFの有効化と設定

NNMiが管理対象デバイスと通信できるようにするために，場合によってはデバイスで明示的にNETCONFを有効化し，設定する必要があります。具体的な設定方法については，デバイスのベンダーが提供するマニュアルを参照してください。

一般に，管理対象デバイスは，次の前提要件を満たす必要があります。

デフォルトのNETCONF TCPポート830，または標準的なSSH TCPポート22のどちらかで，NETCONFを有効化する。

NETCONF通信でアクセスできるように，SSHのユーザー名とパスワードの認証情報をデバイスに設定する。

NNMiに対しては，読み出し専用のアクセス権だけが必要です。

(4)　NNMiにNETCONFデバイスの認証情報を設定する

NNMiが，NETCONFを使用する管理対象デバイスと通信できるようにするには，デバイスで設定されているのと同じNETCONF SSHの認証情報をNNMiに設定する必要があります。

デバイスに適切なNETCONF認証情報が設定されていなくても，NNMiの検出（SNMPを使用した検出だけ）は実行されますが，NNMiに報告されたデバイスの管理情報は完全なものではないことがあります。

NNMiコンソールを使用して，［通信の設定］で［特定ノードの設定］，［領域］または［デフォルト設定］のどれかを選択し，［デフォルトデバイスの資格証明］タブにNETCONFデバイスの認証情報を設定してください。

重要

各管理対象デバイスには，SSHユーザーおよびパスワードを1つだけ設定できます。これは，そのデバイスに対する正規のSSHセッション，およびNETCONFセッションに対して，同じ資格情報の組み合わせが使用されることを意味します。

いったん設定されると，NNMiは，指定されたデバイス（ノード）に対して次の検出サイクルの間に新しい資格情報を使用します。

NNMiの［通信の設定］フォームの編集方法の詳細な手順については，NNMi ヘルプ「管理」を参照してください。

5.3.3　VMwareハイパーバイザーベースの仮想ネットワークの検出と監視

(1)　ハイパーバイザー上にホストされた仮想マシンを監視するための前提条件

NNMiでは次の操作がサポートされます。

サポート対象ハイパーバイザーの検出と監視。

ハイパーバイザーのノードフォームでは，各仮想マシンは［ホスト対象ノード］タブに表示されます。

各仮想マシン（ルーター，スイッチ，ノードなど）の検出と監視。

仮想マシンのノードフォームでは，［ホスト元ノード］属性にハイパーバイザーの名前が表示されます。

次の表に，ハイパーバイザーでホストされているハイパーバイザーと仮想マシンを検出するための前提条件を示します。

表5‒1　ハイパーバイザーとその VMを監視するための前提条件

検出対象

前提条件

詳細情報

ハイパーバイザー

ハイパーバイザーはSNMP通信をサポートする必要があり， SNMPを使用して NNMiからアクセスできる必要があります。

該当しない

NNMi は関連するSNMPエージェントと通信するように設定する必要があります（IPアドレスとコミュニティ文字列またはSNMPv3認証）。

NNMiユーザーインタフェースを使用して設定するには，NNMiヘルプ「管理」の「通信プロトコルの設定」に記載されているデフォルト，領域，または特定ノードについてのSNMPの設定方法を参照してください。

コマンドラインインタフェース（CLI）を使用して設定するには，nnmcommunication.ovplのリファレンスページを参照してください。

NNMi は，HTTPSを使用してハイパーバイザーと通信するように設定する必要があります。

注：（VMwareだけ）VMwareのデフォルト証明書（localhost.localdomain）を，ESXiサーバーのホスト名を使用して生成された証明書と置き換える必要があります。詳細については，VMwareのドキュメントを参照してください。

CLIを使用して設定するには，「(3)　ハイパーバイザーとの通信にHTTPSを使用するようにNNMiを設定する」を参照してください。

NNMiユーザーインタフェースを使用して設定するには，NNMiヘルプ「管理」の「通信プロトコルの設定」に記載されているデフォルト，領域，または特定ノードについての信頼された証明書の設定方法を参照してください。

ハイパーバイザー上の仮想マシン

ハイパーバイザーのWebサービスで認証を行うには，ハイパーバイザーについて記載されたSNMP要件の他にハイパーバイザーデバイスの資格証明もNNMiに設定する必要があります。

NNMiユーザーインタフェースを使用して設定するには，NNMiヘルプ「管理」の「通信プロトコルの設定」に記載されているデフォルト，領域，または特定ノードについての資格証明の設定方法を参照してください。

CLIを使用して設定するには， nnmcommunication.ovplのリファレンスページを参照してください。

(2)　VMwareデフォルト証明書の置換

重要

自己署名またはCA署名証明書は，完全修飾ドメイン名をESXiサーバーのホスト名として使用して生成する必要があります。

デフォルトでは，VMware証明書はlocalhost.localdomainをESXiサーバーのホスト名として使用します。

VMwareのデフォルト証明書を，ESXiサーバーのホスト名を使用して生成された証明書と置き換える必要があります。手順の詳細については，VMwareのドキュメントを参照してください。

(3)　ハイパーバイザーとの通信にHTTPSを使用するようにNNMiを設定する

このセクションでは，CLIを使用して証明書をアップロードする方法を説明します。NNMiユーザーインタフェースを使用してアップロードする方法については，NNMiヘルプ「管理」の「通信プロトコルの設定」を参照してください。

メモ

ハイパーバイザーとの通信にHTTPを使用する必要がある場合は，「(4)　ハイパーバイザーとの通信でHTTPを有効にする」も参照してください。

ハイパーバイザー上でホストされている仮想マシン（VMware ESXiなど）を，HTTPSプロトコルを使用してNNMiが監視できるようにするには，次のどちらかの方法でハイパーバイザーの信頼された証明書をNNMiにアップロードする必要があります。

NNMi ユーザーインタフェースを使用して信頼された証明書をアップロードする。

コマンドラインインタフェース（CLI）を使用して信頼された証明書をアップロードする。

信頼された証明書は，HTTPSプロトコルを使用してハイパーバイザーとの信頼性のある接続を確立するためにNNMiが使用するSSL証明書の 1つです。デフォルトレベルと領域レベルでは，これは同じCAによって発行された証明書を使用するハイパーバイザーを信頼するためにNNMiが使用するCA証明書を指します。ノードレベルでは，これはFQDNをサブジェクト名として使用して生成された，ハイパーバイザーのSSL証明書（自己署名またはCA署名）のことです。

信頼された証明書をNNMiにアップロードするには，次の手順を実行します。

ハイパーバイザーの信頼された証明書を取得し，NNMi管理サーバー上の一時的な場所にこれをコピーします。

メモ

（VMwareだけ）VMwareのデフォルト証明書（localhost.localdomain）を，ESXiサーバーのホスト名を使用して生成された証明書と置き換える必要があります。詳細については，VMwareのドキュメントを参照してください。

証明書がサポートされている形式であることを確認します。サポートされている信頼された証明書ファイルの拡張子は，.pem，.crt，.cer，および.derです。

該当するコマンドを実行し，必要なレベルで証明書をアップロードします。次の表から，要件に合うコマンドを選択してください。

レベル

目的

コマンド

デフォ ルト（グローバル）

同じCAによって署名された証明書をハイパーバイザー全体で使用する組織が，信頼された証明書をデフォルトレベルでアップロードするために使用します。

nnmcommunication.ovpl addCertificate -default -cert <fully qualified path to the certificate file>

領域

同じCAによって署名された証明書を特定の領域のハイパーバイザーで使用する組織が，その領域の信頼された証明書をアップロードするために使用します。

nnmcommunication.ovpl addCertificate -region <region name or UUID> -cert <fully qualified path to the certificate file>

ノード

特定のハイパーバイザーで使用するSSL証明書（CA署名または自己署名証明書）をアップロードするために使用します。

注：自己署名またはCA署名証明書は，完全修飾ドメイン名（FQDN）をサブジェクト名として使用して生成する必要があります。

nnmcommunication.ovpl addCertificate -nodeSetting <node name or UUID> -cert <fully qualified path to the certificate file>

コマンド例：

デフォルト：nnmcommunication.ovpl addCertificate -default -cert /tmp/new.pem

領域：nnmcommunication.ovpl addCertificate -region region1 -cert /tmp/region1.der

ノード：nnmcommunication.ovpl addCertificate -nodeSetting node1 -cert /tmp/node1.crt

コマンドが正常に実行されると，コマンド出力に，アップロードされた証明書についての情報が表示されます。証明書の情報を確認します。

ヒント

アップロードした証明書は，listCertificatesコマンドを使用して表示でき，removeCertificateコマンドを使用して削除できます。詳細については，nnmcommunication.ovplのリファレンスページを参照してください。

ハイパーバイザーが検出された後，Webエージェント上でupdateWebAgentSettingsコマンドを使用して証明書を直接アップロード，置き換え，または削除できます。詳細については，nnmcommunication.ovplのリファレンスページを参照してください。

(4)　ハイパーバイザーとの通信でHTTPを有効にする

デフォルトでは，NNMiはHTTPSプロトコルを使用してハイパーバイザーと通信します。

HTTPを使用する必要がある場合は，次の手順でserver.propertiesファイルに必要なプロパティを追加します。

server.propertiesファイルに移動します。

Windowsの場合：%NnmDataDir%nmsas¥NNM¥server.properties

Linuxの場合：$NnmDataDir/nmsas/NNM/server.properties

HA 環境の場合，「19.5.1　NNMiの共有ディスク内のデータ」も参照してください。

次の行を追加します。

#VMware vSphere APIなどのSOAPエージェントとの通信でhttpを使用するかどうかを決定します。
#このプロパティはデモ環境またはテスト環境のみで有効にすること、およびHTTPSは本番環境の場合に
#設定することをお勧めします。
nms.comm.soap.targetconfig.HTTP_ENABLED=true

NNMi 管理サーバーを再起動します。

NNMi管理サーバーでovstopコマンドを実行します。

NNMi管理サーバーでovstartコマンドを実行します。

ハイパーバイザーとの通信でHTTPを無効にするには，次の手順を実行します。

server.propertiesファイルに移動します。

Windowsの場合：%NnmDataDir%nmsas¥NNM¥server.properties

Linuxの場合：$NnmDataDir/nmsas/NNM/server.properties

HA 環境の場合，「19.5.1　NNMiの共有ディスク内のデータ」も参照してください。

HTTP_ENABLED プロパティ値をfalse に変更します。

nms.comm.soap.targetconfig.HTTP_ENABLED=false

NNMi 管理サーバーを再起動します。

NNMi管理サーバーでovstopコマンドを実行します。

NNMi管理サーバーでovstartコマンドを実行します。

「(3)　ハイパーバイザーとの通信にHTTPSを使用するようにNNMiを設定する」の手順を実行します。

5.3.4　Cisco ACIネットワークの検出と監視

Cisco ACIで稼働しているネットワークを検出して監視する場合，次の追加タスクを実行する必要があります。

タスク1：Cisco APICコンソールで読み取り専用ユーザーを作成する

読み取り専用権限を持つCisco APICユーザーを作成します。このユーザーは，Cisco APICのすべてのREST APIへの読み取りアクセス権を持っている必要があります。このユーザーは，NNMiがCisco APICシステムを検出するために使用します。ユーザーの作成中，［Create Local User］ページの［Security Domain］セクションで［all］を選択します。

タスク2：Cisco APICシステムと通信するようにNNMiを設定する

検出するCisco APICシステムごとに，［デバイスの資格証明］フォームを使用してアクセス資格証明を指定します。これらの資格証明により，NNMiはCisco APICシステムに接続できるようになります。NNMiとCisco APICシステム間のHTTPS通信をスムーズに行うには，Cisco ACIまたはCAによって信頼されている証明書をNNMi管理サーバーにアップロードする必要があります。

また，Cisco ACIのノードをCisco ACIのノードとして認識するには，各ノードがSNMPノードとして検出されている必要があります。

このタスクを行うには，以下の手順を実行します。

検出対象のクラスターごとに1つのCisco APICシステムを特定します。SNMPエージェントが，検出対象のすべてのクラスター内のすべてのCisco APICシステムで有効であることを確認します。

NNMiは，APICクラスター内の1つのCisco APICシステムのみを検出することで，クラスター内のすべてのCisco APICシステムを最終的に検出できます。

Cisco APICシステムに使用するためのすべての信頼済み証明書を取得します。

各証明書が特定のCisco APICシステムに固有である証明書一式を使用することも，CA署名証明書を使用することも，この2つの組み合わせを使用することもできます。

Cisco ACI APIにアクセスして，Cisco APICシステムと通信するようにNNMiを設定します。

「タスク1：Cisco APICコンソールで読み取り専用ユーザーを作成する」で作成した資格証明を取得します。

［通信の設定］フォームで，［特定ノードの設定］タブに移動します。

ヒント

領域の設定やデフォルトの設定でも動作します。

新しいノードを追加します。

［特定ノードの設定］タブで，［新規作成］をクリックし，［特定ノードの設定］フォームで新しいノードを定義します。

または，既存のノードをダブルクリックします。

［特定ノードの設定］フォームで，［デバイスの資格証明］タブに移動します。

［新規作成］をクリックします。

［SNMPv1/v2コミュニティ文字列］または［SNMPv3設定］タブで，SNMP v1もしくはv2c通信文字列，またはSNMPv3資格証明を指定します。

［特定のノードデバイスの資格証明］フォームで，［タイプ］に［CiscoACI］を選択し，「タスク1：Cisco APICコンソールで読み取り専用ユーザーを作成する」で作成したCisco ACIユーザーの資格証明を指定します。

信頼済み証明書をアップロードします。HTTP通信を設定する場合は，この手順をスキップしてください。

［特定ノードの設定］フォームで，［信頼済み証明書］タブに移動します。

［証明書のアップロード］をクリックします。

［開く］ウィンドウが表示されます。

［開く］ウィンドウで，証明書を選択して［開く］をクリックします。

以下のどれか1つを使用できます。

Cisco APICシステムと通信するためのCA署名証明書

使用できるのは以下の証明書形式のみです。

.pem

.crt

.cer

.der

［保存して閉じる］をクリックします。

タスク3：検出を設定して実行する

環境内のCisco APICシステムをシードするようにNNMiを設定します。シードを設定するときには，検出対象の各クラスター内の1つのCisco APICシステムの完全修飾ドメイン名またはIPアドレスを指定します。

NNMi検出によって情報が収集されるのを待機します。NNMiによって，APICクラスターとすべてのCisco ACIリーフが検出され，検出されたCisco APICシステムが管理するスパインノードが検出されます。

メモ

上記のタスク1からタスク3までの設定を行わずにCisco ACIのノードを検出している場合に，この機能を利用してCisco ACIで稼働しているネットワークを監視するときは，Cisco APICノードに対して設定ポーリングを2回実行する必要があります。

5.3.5　マルチホームNNMi管理サーバー

複数のIPアドレスを持つようにNNMi管理サーバーを設定する場合，管理対象ノードは常にNNMi管理サーバー上のオペレーティングシステムで設定されたIPアドレスを使用します。管理対象ノードと通信およびデータ交換するときに，デフォルト以外のIPアドレスを使用するようにNNMiを設定するには，次の手順を実行します。

NNMi管理サーバーにログオンします。

テキストエディタで次のファイルを開きます。

Windowsの場合：%NnmDataDir%shared¥nnm¥conf¥props¥nms-communication.properties

Linuxの場合：/var/opt/OV/shared/nnm/conf/props/nms-communication.properties

デフォルト以外のIPv6アドレスを設定するには，com.hp.ov.nms.comm.snmp.sourceAddress.IPv6プロパティのコメントを解除して，このプロパティに選択したIPv6アドレスを設定します。

デフォルト以外のIPv4アドレスを設定するには，com.hp.ov.nms.comm.snmp.sourceAddress.IPv4プロパティのコメントを解除して，このプロパティに選択したIPv4アドレスを設定します。

重要

高可用性（HA）で設定を行う場合は，ov.confファイルのNNM_INTERFACEプロパティの値は，nms-communication.propertiesファイルのcom.hp.ov.nms.comm.snmp.sourceAddress.IPv4プロパティの値と同じである必要があります。ov.confファイルの場所は，「19.9.1　NNMi HA設定ファイル」を参照してください。

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopコマンドおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

変更を保存します。

次のコマンドを実行して，NNMiを再起動します。

ovstop -c
ovstart -c

5.4　通信の評価

この節では，通信設定の進行と成功を評価する方法を挙げます。多くの作業が完了するのは，検出が完了したあとです。

次について考えます。

すべてのノードに対してSNMPの設定をしましたか？

「5.4.1　ノードのSNMPの設定を確認する」を参照してください。

現在デバイスに対してSNMPアクセスは可能ですか？

「5.4.2　SNMPアクセスを確認する」を参照してください。

管理IPアドレスは正しいですか？

「5.4.3　SNMPデバイスの管理IPアドレスを確認する」を参照してください。

NNMiは正しい通信設定を使っていますか？

「5.4.4　通信設定を確認する」を参照してください。

State Poller設定は通信設定と一致していますか？

「5.4.5　監視設定と通信設定の一致を確認する」を参照してください。

5.4.1　ノードのSNMPの設定を確認する

［ノード］インベントリビューを開く。

［デバイスのプロファイル］列を，文字列「No SNMP」が含まれるようにフィルタリングする。

管理するデバイスごとに，特定ノードの通信設定を行います。その代わりに，領域を拡張して，ノードを組み入れ，アクセスクレデンシャルを更新することもできます。

通信設定が正しい場合は，デバイスのSNMPエージェントが実行中であり，適切に設定されていることを確認します（ACLを含みます）。

5.4.2　SNMPアクセスを確認する

インベントリビューでノードを選択する。

［アクション］＞［ポーリング］＞［ステータスのポーリング］または［アクション］＞［ポーリング］＞［設定のポーリング］を選択する。

結果にSNMPの値が表示された場合，通信は動作中です。

コマンドラインからnnmsnmpwalk.ovplコマンドで通信をテストすることもできます。詳細については，nnmsnmpwalk.ovplのリファレンスページを参照してください。

5.4.3　SNMPデバイスの管理IPアドレスを確認する

デバイスに対してNNMiが選択した管理アドレスを判定するには，次の手順を実行します。

インベントリビューでノードを選択する。

［アクション］＞［設定の詳細］＞［通信設定］を選択する。

［通信設定］ウィンドウで，［アクティブなSNMP エージェント設定］リストにあるSNMPエージェントの管理アドレスが正しいことを確認する。

5.4.4　通信設定を確認する

SNMPコミュニティ文字列が欠落しているか，または正しくない場合は，検出が不完全になる可能性があり，検出パフォーマンスに悪影響を及ぼす可能性もあります。

デバイスの通信設定を確認するには，nnmcommconf.ovplコマンドを使用するか，次の手順を実行します。

インベントリビューでノードを選択する。

［アクション］＞［設定の詳細］＞［通信設定］を選択する。

NNMiは，表示された値を求めるために，特定のノード一致，順序番号による領域設定，デフォルト設定をすべて評価します。

［通信設定］ウィンドウで，SNMP設定テーブルにリストされた値が，NNMiでこのノードに使用する設定であることを確認する。

通信設定が正しくない場合，問題解決の手始めとして，SNMP設定テーブル内のソース情報を使用します。領域や特定ノードの設定や順序番号を変更する必要がでてくる場合もあります。

メモ

VMware通信の場合，［Webエージェント］フォームでアクティブ設定を確認するか，またはnnmcommunication.ovpl listWebAgentSettingsコマンドを使用します。

詳細については，NNMiヘルプ「管理」を参照してください。

5.4.5　監視設定と通信設定の一致を確認する

通信設定によってネットワークの領域へのプロトコルトラフィックが許可される場合でも，その種類のトラフィックは監視設定で無効にされることがあります。設定が上書きされるかどうかを知る手順は次のとおりです。

インベントリビューでノードを選択する。

［アクション］＞［設定の詳細］＞［モニタリングの設定］を選択する。

監視設定または通信設定のどちらかによってある種類のデバイスへのトラフィックが無効にされる場合，そのトラフィックはNNMiから送信されません。

5.5　通信の調整

認証失敗の削減

検出の間にNNMiがあまりにも多くの認証失敗トラップを生成している場合は，NNMiが試行するアクセスクレデンシャルのグループを小さくし，小さい領域または特定のノードに設定します。

タイムアウトと再試行の調整

NNMiがノード検出中にSNMPを使ってデバイス通信を試みるとき，通信の設定によってNNMiが必要なデバイス情報を収集できるかが決まります。通信の設定に正しいSNMPコミュニティ文字列が含まれていない場合，またはNNMiが非SNMPデバイスの検出をしている場合，NNMiは設定されているSNMPタイムアウトと再試行回数を使用します。この場合，タイムアウトの値が大きいか，または再試行の回数が多いと，検出の全般的パフォーマンスに悪影響が及ぶ可能性があります。SNMP/ICMP要求に低速で応答することがわかっているデバイスがネットワークにある場合は，［通信の設定］フォームの［領域］タブまたは［特定ノードの設定］タブを使って，これらのデバイスについてだけタイムアウト値と再試行値を微調整することを考えてください。

デフォルトコミュニティ文字列の削減

デフォルトコミュニティ文字列が多数あると，検出パフォーマンスに悪影響が及ぶことがあります。多数のデフォルトコミュニティ文字列を入力する代わりに，［通信の設定］フォームの［領域］タブまたは［特定ノードの設定］タブを使って，ネットワークの特定エリアのコミュニティ文字列設定を微調整します。

6　NNMi検出

ネットワーク管理で最も重要な作業の1つは，常に最新のネットワークトポロジを把握しておくことです。NNMi検出によって，トポロジインベントリにネットワーク内のノードに関する情報が挿入されます。NNMiでは，継続的なスパイラル検出によってこのトポロジ情報が維持されます。これによって，根本原因解析ツールとトラブルシューティングツールで，インシデントに関する正確な情報を把握できるようになります。

この章では，NNMi検出を設定するために役立つ情報を記載しています。検出がどのようにして行われるのかと検出の設定方法については，NNMiヘルプの「ネットワークの検出」を参照してください。

6.1　検出の概念

ルーターとスイッチだけを検出するNNMiのデフォルト動作によって，ネットワーク管理を最も重要なデバイスに集中させることができます。つまり，最初にネットワークの基幹をターゲットにします。一般に，末端ノード（例えばパソコンやプリンタ）を管理対象にするのは，それらを重大リソースと見なすのでないかぎり避けるべきでしょう。例えば，データベースやアプリケーションサーバーがクリティカルなリソースとして考えられます。

NNMiで検出するデバイスを管理してNNMiトポロジに加えるには，幾つかの方法があります。ネットワークをどのように構成するかやNNMiで何を管理するかによって，検出構成を単純にしたり，複雑にしたり，その間の適当なレベルに設定したりできます。

重要

NNMiは，デフォルトでの検出を実行しません。各種のデバイスがNNMiトポロジに現れる前に，検出の事前設定をする必要があります。

検出された各ノード（物理または仮想ホスト）は，NNMiがそのノードを能動的に管理しているかどうかに関わらず，ライセンスの限度までカウントします。所有しているNNMiライセンスの数は，検出方法にも影響を及ぼします。

ライセンス情報を追跡する際には，次の点に注意してください。

消費量：NNMiは，NNMiのライセンス容量限界までノードを検出および管理します（切り上げ）。

VMware環境：デバイスプロファイルがvmwareVMの各デバイスや仮想スイッチは，1/10のノードと同等です。

疑似オブジェクト：疑似ノードのライセンス消費量は，1/10のノードと同等です。

ほかのすべてのデバイスは1つの検出されたノードと同等です。

検出されたノードの数がライセンスされた容量限界に到達したかまたは超えた場合，次のどちらかが行われないかぎり，新しいノードは検出されません。

ライセンス拡張をインストールする。

設定を確認し，NNMi検出をネットワーク環境内の重要なノードだけに限定する。次にノードを削除し，NNMiの再検出でノードの管理対象インベントリをリセットする。

メモ

多数のノードを検出する設定については，NNMiヘルプを参照してください。

多数のノードを検出する設定については，NNMiヘルプを参照してください。

ステータス監視の考慮事項も，選択肢に影響を及ぼします。State Pollerは，デフォルトではNNMiが検出したデバイスに接続したインタフェースしか監視しません。ネットワークの幾つかの領域ではこのデフォルト設定を変更できるため，担当する範囲の先にあるデバイスの検出をすることも可能になります（State Pollerの詳細については，「7.　NNMiステータスポーリング」を参照してください）。

NNMiには，次の2つの基本的な検出設定モデルがあります。

リストベース検出−NNMiに，リストのシードによってどのデバイスをデータベースに追加し，監視するかを明示的に指定します。

ルールベース検出−NNMiに，ネットワークのどの領域とデバイスタイプをデータベースに追加するかを指定します。各領域の開始アドレスを指定することで，NNMiに定義済みのデバイスを検出させます。

リストベース検出とルールベース検出を自由に組み合わせて，NNMiの検出対象を設定できます。初回の検出によってこれらのデバイスがNNMiトポロジに追加され，スパイラル検出でネットワークが日常的に再検出されるため，トポロジは常に最新の状態が維持されます。

NNMiでは，テナントを使用して重複アドレスドメインを含むネットワークに対応します。重複アドレスドメインは，ネットワーク管理ドメインの静的ネットワークアドレス変換（NAT），動的ネットワークアドレス変換（NAT），またはポートアドレス変換（PAT）領域内に存在することがあります。そのようなネットワークの場合，NNMiはシード検出を使用して重複アドレスドメインを異なるテナントに配置します。詳細については，NNMiヘルプを参照してください。

重要

NNMiを使用してVMwareハイパーバイザーベースの仮想ネットワークを管理する場合は，NNMiヘルプ「管理」の「仮想環境内のテナント」のヘルプトピックを参照してください。

マルチテナントを設定する場合は，ネットワーク検出を開始する前に，テナントを設定してください。

6.1.1　デバイスプロファイルとデバイスの属性

NNMiはデバイスを検出する際に，SNMPを使用して幾つかの属性を直接収集します。重要な属性の1つはMIB IIシステムオブジェクトID（sysObjectID）です。システムオブジェクトIDから，NNMiはベンダー，デバイスカテゴリ，デバイスファミリなどの追加属性を導き出します。

検出中，NNMiはMIB II systemグループを収集して，データベースのトポロジ部分に格納します。Systemのケーパビリティは，［ノード］フォームに表示されます。ただし，これらのケーパビリティはNNMiの監視設定では使用されません。NNMiでは，デバイスカテゴリ（システムオブジェクトIDのデバイスプロファイルによる）を使用して，デバイスをノードグループに分類します。ノードビューのテーブルでは，［デバイスのカテゴリ］列に各ノードのデバイスカテゴリが明示されます。

メモ

（SNMPエージェントに加えて）Webエージェントが設定されている場合，NNMiは追加のプロトコル（例えば，VMware環境用のSOAPプロトコル）を使用できます。

NNMiには，リリース時に多くのシステムオブジェクトIDのデバイスプロファイルが付属しています。ご使用の環境内のデバイスがデバイスプロファイルにない場合は，デバイスプロファイルをカスタム設定して，これらのデバイスをカテゴリ，ベンダーなどに対応づけることができます。

6.2　検出の計画

次の内容を検討します。

基本的な検出方法を選択する

自動検出ルール

ノード名の解決

サブネット接続ルール

検出シード

再検出の間隔

オブジェクトを検出しない

インタフェースの検出範囲

6.2.1　基本的な検出方法を選択する

リストベース検出だけを行うのか，ルールベース検出だけを行うのか，それともこの2つの方法を組み合わせて使用するのかを決定します。

(1)　リストベース検出

リストベース検出では，NNMiで検出する各ノードを検出シードとして明確に指定します。

NNMiでは，テナントを使用して重複アドレスドメインを含むネットワークに対応します。重複アドレスドメインは，ネットワーク管理ドメインの静的ネットワークアドレス変換（NAT），動的ネットワークアドレス変換（NAT），またはポートアドレス変換（PAT）領域内に存在することがあります。そのようなネットワークの場合，NNMiはシード検出を使用して重複アドレスドメインを異なるテナントに配置します。詳細については，NNMiヘルプを参照してください。

重要

NNMiを使用してVMwareハイパーバイザーベースの仮想ネットワークを管理する場合は，NNMiヘルプ「管理」の「仮想環境内のテナント」のヘルプトピックを参照してください。

マルチテナントを設定する場合は，リストベース検出を使用することをお勧めします。

リストベース検出だけを使用することのメリットを次に示します。

NNMiの管理対象を厳密に管理できます。

検出時にデフォルト以外のテナントの機能が利用できます。

設定が最も簡単です。

固定的なネットワークに適しています。

NNMiを初めて使用する場合に適した方法です。自動検出ルールを，徐々に追加していくことができます。

リストベース検出だけを使用することのデメリットを次に示します。

ネットワークに新規ノードが追加されても検出されません。

検出対象とするノードのリストを指定しなければなりません。

(2)　ルールベースの検出

ルールベース検出では，NNMiが検出してNNMiトポロジに入れるネットワークの領域を定義するために1つ以上の自動検出ルールを作成します。それぞれのルールに対して，1つ以上の検出シードを（シードを明確に指定するかPingスイープを有効にすることによって）指定する必要があります。それによってNNMiがネットワークを自動的に検出します。

ルールベース検出を使用することのメリットを次に示します。

大規模なネットワークに適しています。NNMiは大量のデバイスを，最低限の設定項目に基づいて検出できます。

頻繁に変わるネットワークに適しています。ネットワークに追加した新しいデバイスは，管理者が介在しなくても検出されます（各デバイスは自動検出ルールの適用範囲内であることが前提）。

ルールベース検出を使用することのデメリットを次に示します。

すぐにライセンス限度に達してしまいます。

ネットワークの構造によっては，自動検出ルールの調整が複雑になることがあります。

自動検出ルールが非常に広範囲で，管理しようとしている数以上のデバイスをNNMiが検出する場合，不要なデバイスをNNMiトポロジから削除できますが，ノードの削除には時間が掛かることがあります。

シードでないノードは，検出時にデフォルトのテナントに割り当てられます。NNMiのマルチテナント機能を使用したい場合は，検出後にテナントの割り当てを変更する必要があります。

6.2.2　自動検出ルールを計画する

(1)　自動検出ルールの設定

自動検出ルールを設定するときは，次の内容を指定します。

自動検出ルールの順序

検出から除外するデバイス

Pingスィープを使用するかどうか

該当するものがある場合，使用する検出シード

(2)　自動検出ルールの順序

自動検出ルールの順序属性の値は，次のように検出範囲に影響します。

IPアドレス範囲

デバイスが2つの自動検出ルールに該当すると，順序番号が小さい方の自動検出ルールの設定が適用されます。例えばある自動検出ルールによってIPアドレスの一式が除外されると，それより大きな順序番号の自動検出ルールはこれらのノードを処理せず，そのアドレス範囲内のノードは，検出シードとしてリストされないかぎり検出されません。

システムオブジェクトIDの範囲

−自動検出ルールにIPアドレス範囲が含まれていない場合は，システムオブジェクトIDの設定が，それより大きな順序番号の自動検出ルールに適用されます。

−自動検出ルールにIPアドレス範囲が含まれている場合，システムオブジェクトID範囲は自動検出ルール内でだけ適用されます。

(3)　デバイスを検出から除外

特定のオブジェクトタイプが検出されないようにするには，検出したくないシステムオブジェクトIDを無視する自動検出ルールを，小さな順序番号で作成します。このルールにIPアドレス範囲を含めないでください。この自動検出ルールに小さい順序番号を付けることで，検出プロセスはこのルールに一致するオブジェクトを早い段階で読み飛ばします。

IPアドレス範囲リストまたはシステムオブジェクトID範囲リストの中の［ルールにより無視された］とマークされたエントリは，その自動検出ルールだけに影響します。無視される範囲内に含まれるデバイスは，別の自動検出ルールに含めることができます。

［検出の設定］フォームの［除外対象IPアドレス］タブでリストされるアドレスは，すべての自動検出ルールで除外されます。これらのアドレスは検出シードとして設定されないかぎり，NNMiトポロジには追加されません（検出シードは常に検出されます）。

メモ

一部のネットワークではHSRPやVRRPなどのルーティングプロトコルを使用してルーターに冗長性を持たせています。ルーターがルーター冗長グループで設定されている場合，ルーター冗長グループで設定されているルーターは保護されたIPアドレス（1つがアクティブで，1つがスタンバイ）を共有します。NNMiは，同じ保護されたIPアドレスを使用して設定された複数のルーター冗長グループの検出および管理をサポートしません。それぞれのルーター冗長グループには固有の保護されたIPアドレスが必要です。

(4)　Pingスイープ

NNMiでは，Pingスイープを使用して，設定した自動検出ルールのIPアドレス範囲内のデバイスを検索できます。初期検出では，すべてのルールでPingスイープを有効にするとよいでしょう。これによって十分な情報がNNMi検出に提供されるので，検出シードを設定する必要がなくなります。

メモ

Pingスイープは，16ビットまたはそれより小さいサブネット（例えば10.10.*.*）で機能します。

Pingスイープは，特にISPネットワークのように制御が不要なWAN全体でのデバイスの検出に便利です。

ファイアウォールはPingスイープをネットワークに対する攻撃として見なすことがよくあります。その場合，ファイアウォールはPingスイープを発信したデバイスからのすべてのトラフィックをブロックすることがあります。

ヒント

Pingスイープは，小さな検出範囲にだけ有効にしてください。

(5)　SNMPトラップからの検出ヒント

NNMiは，受信したSNMPトラップのソースIPアドレスを自動検出ルールに対するヒントとして処理します。SNMPトラップインシデントの詳細については，NNMiヘルプ「管理」を参照してください。

(6)　自動検出ルールの検出シード

自動検出ルールごとに少なくとも1つの検出シードを指定してください。検出シードを指定するには次の方法があります。1つまたは複数を組み合わせて検出シードを指定してください。

［設定］ワークスペース＞［検出］＞［シード］＞［検出シード］フォームでシードを入力します。

nnmloadseeds.ovplコマンドを使用して，シードファイルから情報をロードします。

少なくとも初回の検出で，Pingスイープをルールに対して有効にします。

SNMPトラップをNNMi管理サーバーに送信するようにデバイスを設定します。

(7)　自動検出ルールのベストプラクティス

NNMiはすべての検出対象デバイスを自動的に管理するため，管理したいネットワークの範囲と厳密に一致するIPアドレス範囲を使用してください。

−複数のIPアドレス範囲を1つの自動検出ルール内で使用して，検出を限定できます。

−自動検出ルールに大きなIPアドレス範囲を追加したあとに，そのルール内の検出から幾つかのIPアドレスを除外できます。

システムオブジェクトID範囲の指定は接頭部分であり，絶対値ではありません。例えば，範囲1.3.6.1.4.1.11は1.3.6.1.4.1.11.*と同じです。

(8)　例

検出ルールの重複

図6-1は，重複する2つの検出範囲を示しています。左側の円は，NNMi検出で無視されるIPアドレス範囲またはシステムオブジェクトID範囲を表しています。右側の円は，NNMi検出で検出に含まれるIPアドレス範囲またはシステムオブジェクトID範囲を表しています。重複している領域は，これらの自動検出ルールの順序に応じて検出に含まれるか無視されます。

図6‒1　重複している検出範囲

デバイスタイプ検出を制限する

ネットワーク内のプリンタ以外のすべてのHPデバイスを検出するには，HPエンタープライズシステムオブジェクトID（1.3.6.1.4.1.11）を含む範囲を持つ1つの自動検出ルールを作成します。この自動検出ルールで，HPプリンタ（1.3.6.1.4.1.11.2.3 9）のシステムオブジェクトIDを無視する2番目の範囲を作成します。IPアドレス範囲を未設定のままにしてください。

6.2.3　ノード名の解決順序を計画する

デフォルトでは，NNMiはノードを次の順序で識別します。

短いDNS名

短いsysName

IPアドレス

重要

パフォーマンス向上のために，NNMiは名前解決情報をキャッシュします。そのため，ノードのホスト名を変更してもNNMiのデータにはすぐには反映されません。

次の場合は，ノード名解決のデフォルト順序を変更してください。

組織がDNS設定の更新を第三者にまかせている場合，ネットワークに新しいデバイスが追加されるごとにそのsysNameを定義するポリシーを設定するでしょう。この場合，ノード名解決の最初の選択肢としてsysNameを設定して，新しいデバイスがネットワークに導入されるとすぐにNNMiが検出できるようにします（sysNameを，そのデバイスを使用している間は維持します）。

組織が管理対象デバイスのsysNameの設定や維持をしない場合，sysNameをノード名解決の3番目の選択肢として選択します。

ヒント

DNS完全名またはDNS短縮名を基本的な命名規則としている場合，NNMi管理サーバーからすべての管理対象デバイスへの順方向と逆方向のDNS解決があることを確認してください。

DNS完全名を命名規則としている場合，トポロジマップ上のラベルを長くできます。

NNMiでは，最小のループバックアドレスをCiscoデバイスの管理アドレスとして選択されるため，各Ciscoデバイスの最小のループバックアドレス上にDNS解決を配置してください。

6.2.4　サブネット接続ルールを計画する

リストベース検出だけ

リストベース検出では，サブネット接続ルールを使用してWAN上の接続を検出します。NNMiは予測される接続の各末端で検出したデバイスのサブネットメンバーシップを評価し（IPアドレスとサブネット接頭部を調べて），サブネット接続ルールで一致があるか調べます。

ルールベース検出だけ

自動検出ルールが有効でNNMiが「/28」と「/31」の間のサブネット接頭部で設定されたデバイスを見つけると，次を実施します。

NNMiは適用可能なサブネット接続ルールについて調べます。

一致が見つかると，NNMiはサブネット内の有効な各アドレスをヒントとして使用して，そのアドレスでの検出を試みます。

ヒント

デフォルトの接続ルールを使用してください。問題がある場合だけそれらを変更してください。

6.2.5　検出シードを計画する

検出シードとして使用するデバイスについて説明します。

ヒント

優先する管理IPアドレスを選択するルールの1つによって，最初に検出したIPアドレスを管理アドレスとして使用することが指定されます。優先IPアドレスをシードアドレスとして設定することによって，NNMiに影響を与えることができます。

Ciscoデバイスの場合，ループバックアドレスを検出シードとして使用してください。ループバックアドレスが，デバイス上のほかのアドレスより確実に到達可能であるためです。DNSが，デバイスホスト名からループバックアドレスを解決するように正しく設定されていることを確認してください。

リストベース検出だけ

リストベース検出の場合，NNMiの管理対象にするすべてのデバイスをリスト化します。このリストは，資産管理ソフトウェアまたはほかのツールからエクスポートできるでしょう。

NNMiは，このリストに自動的にデバイスを追加しないので，担当しているすべてのデバイスや，監視やステータス計算に影響を及ぼすすべてのデバイスが，リストに含まれるようにしてください。

ルールベース検出だけ

ルールベース検出の場合，検出シードは任意で指定します。

Pingスイープが自動検出ルールに対して有効な場合，そのルールのシードを指定する必要はありません。

Pingスイープが無効な各自動検出ルールでは，ルールごとに少なくとも1つのシードを確認してください。ルールにIPアドレス範囲が複数含まれる場合，ルーターはWANリンクを横断したARPエントリを保持しないため，それぞれのルーティング可能範囲でシードが必要になります。

ヒント

ルールベース検出を完全なものにするためには，スイッチではなくルーターを検出シードとして使用してください。一般にルーターはスイッチより大きなARPキャッシュを持っているためです。検出したいネットワークにコアルーターが接続されていれば，検出シードとしては最適な選択肢になります。

6.2.6　再検出の間隔を計画する

NNMiは，データベース内の各デバイスの設定情報を，設定された再検出間隔に従って再チェックします。さらに，NNMiは自動検出ルールの対象となる各ルーターからARPキャッシュを収集して，ネットワーク上に新しいノードがあるか調べます。

デバイスの通信関連の設定に，インタフェースの番号変更のような変更があると，NNMiは自動的に，そのデバイスとその隣接デバイスに関するデータを更新します。

次のような変更では自動再検出のきっかけになりません。デバイスは設定された再検出間隔に基づいて更新されます。

ノード内の変更（例えば，ファームウェアアップグレードまたはシステムの連絡先）。

ネットワークに新しいノードが追加された。

ネットワーク内の変更のレベルに合った再検出間隔を選択します。構成が頻繁に変化するネットワークでは，最低24時間の間隔を使用することをお勧めします。構成が安定したネットワークでは，再検出間隔を広げることができます。

6.2.7　オブジェクトを検出しない方法を計画する

NNMiでは，NNMiが特定のオブジェクトを無視するように設定する5つの方法があります。

［通信の設定］フォームで，ICMP通信やSNMP通信（またはその両方）を，グローバルレベル，通信領域レベル，または特定のホスト名またはIPアドレスのレベルの異なるレベルでオフにできます。これらのプロトコルのどちらかまたは両方を無効にした場合の影響の詳細については，「5.1.7　ポーリングプロトコル」を参照してください。

［検出の設定］フォームで，特定のIPアドレスやSNMPシステムオブジェクトIDからヒントを収集しない自動検出ルールを設定できます。この基準に一致するノードはマップとデータベース上で存在し続けますが，スパイラル検出ではこれらのIPアドレスまたはオブジェクトタイプを超える隣接デバイスの検出はしません。

［検出の設定］フォームで，特定のIPアドレス範囲や特定のIPアドレス（またはその両方）をデータベースから除外する自動検出ルールを設定できます。スパイラル検出では，あらゆるノードのアドレスリストでこれらのアドレスを表示したり，デバイス間に接続を確立するとき，これらのアドレスを使用したりすることがないので，NNMiがこれらのアドレスの使用状況を監視することはありません。

［検出の設定］フォームの［除外対象IPアドレス］タブで，除外対象IPアドレスフィルタを設定して，IPアドレス範囲を検出から除外できます。

あるノードがすでに検出されたあとに，そのノードのすべてのIPアドレスを［除外対象IPアドレス］リストに入力しても，NNMiはそのノードを削除しません。さらに，NNMiの管理者が意図的にNNMiデータベースからそのノードを削除しないかぎり，NNMiはそのノードの履歴全体を削除しません。

IPアドレス範囲を除外する場合，ネットワーク管理ドメインの静的ネットワークアドレス変換（NAT），動的ネットワークアドレス変換（NAT），またはポートアドレス変換（PAT）領域内の重複アドレスも除外されます。

NNMiでは，テナントを使用して重複アドレスドメインを含むネットワークに対応します。そのようなネットワークの場合，NNMiはシード検出を使用して重複アドレスドメインを異なるテナントに配置します。詳細については，NNMiヘルプを参照してください。

［検出の設定］フォームの［除外対象インタフェース］タブで，インタフェースグループを選択して，特定のタイプのインタフェースを検出プロセスから除外できます。詳細については，NNMiヘルプを参照してください。

6.2.8　インタフェースの検出範囲

NNMiでは，フィルタを定義して検出されるインタフェース範囲を指定できます。これは，ノードが大きく，インタフェースのサブセットだけを検出する場合に特に便利です。［除外対象インタフェース］オプションを使用する場合は，デバイスから情報を取得したあとでインタフェースがフィルタリングされますが，検出するインタフェース範囲を指定する場合は，NNMiから範囲外のインタフェースに関する情報は要求されません。そのため，範囲ベースの検出では，一部のインタフェースを管理する場合，大きいデバイスの検出パフォーマンスを向上できます。

［検出の設定］フォームの［含まれるインタフェース範囲］タブで，システムオブジェクトIDプレフィック値およびifIndex値を使用してインタフェース範囲を定義します。詳細については，NNMiヘルプを参照してください。

6.3　検出の設定

ここでは，設定のヒントを一覧にし，幾つかの設定例について説明します。この項を読んだあとで，特定の手順のNNMiヘルプの「検出を設定する」を参照してください。

重要

NNMiは，［検出シード］フォームを［保存して閉じる］とすぐにシードから検出を開始するので，シードを設定する前に次のことを必ず行ってください。

すべての通信設定を完了する。

すべての自動検出ルールを完了する（設定が必要な場合）。

サブネット接続ルールを設定する。

名前解決を設定する。

コンソールまでさかのぼって，すべての設定フォームの［保存して閉じる］を実行する。

メモ

ルールベース検出の場合，大幅な設定変更を行う前には，既存の設定のコピーを保存しておくことをお勧めします。詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

6.3.1　自動検出ルールを設定する場合のヒント

新しい自動検出ルールを定義するときは，それぞれの設定を慎重に確認してください。新しいルールの定義では，自動検出はデフォルトで有効になっており，IPアドレス範囲はデフォルトで含まれており，システムオブジェクトID範囲はデフォルトで無視されます。

6.3.2　シードを設定する場合のヒント

シードを設定するときは，次のベストプラクティスを検討してください。

検出対象ノードがリスト化されたファイルがすでにある場合は，この情報をシードファイルとして書式設定して，nnmloadseeds.ovplコマンドでNNMiにインポートします。

NNMiが選択するIPアドレスに影響を与えるために，シードファイルに管理アドレスとしてIPアドレスを指定します（ホスト名を使用すると，DNSが各ノードのIPアドレスを提供します）。

シードファイルのエントリの書式を，次に示します。

IP_address # node name
IP_address2, "<テナント名またはテナントのUUID>" # node name

保守目的のため，使用するシードファイルは1つだけにすることをお勧めします。必要に応じてノードを追加して，nnmloadseeds.ovplコマンドを再度実行します。NNMiは新しいノードを検出しますが，既存のノードは再判定しません。

ノードをシードファイルから削除しても，NNMiトポロジからは削除されません。NNMiトポロジからのノード削除は直接NNMiコンソールで実施してください。

ノードをマップやインベントリビューから削除しても，シードは削除されません。

NNMiでノードを再検出したい場合は，そのノードをマップまたはインベントリビューと，NNMiコンソールの［設定］＞［検出］＞［シード］ビューから削除してから，そのノードをNNMiコンソールの［検出シード］フォームで再度入力するか，nnmloadseeds.ovplコマンドを実行します。

ルールベース検出だけ

検出ルールは，そのルールに対するシードを指定する前に設定します。つまり，［検出の設定］フォームで［保存して閉じる］をクリックします（［検出シード］フォームで情報を保存すると，シード設定はすぐに更新されます）。

6.3.3　リンクアグリゲーションの検出

リンクアグリゲーションには，NNMi Advancedライセンスが必要です。

リンクアグリゲーション（LAG）プロトコルによって，ネットワーク管理者はアグリゲータインタフェースとしてスイッチでインタフェースのセットを設定できます。この設定によって，帯域幅，データ通信速度，冗長性の向上と並行して，複数のインタフェースを使用して別のデバイスにアグリゲータレイヤー2接続を作成します。

詳細については，NNMiヘルプでリンクアグリゲーションを検索してください。

6.3.4　サーバーからスイッチへのリンクアグリゲーション（S2SLA）の検出について

リンクアグリゲーションには，NNMi Advancedライセンスが必要です。

ネットワーク管理者は，信頼性の向上およびサーバーとスイッチ間のリソースのさらなる活用を頻繁に求められます。多くのネットワーク管理者が，ネットワーク機器プロバイダーでは広範な使用法があるために，Link Aggregation Configuration Protocol（LACP）の使用を選択します。LACPは，ITエンジニアがサーバーからスイッチへの設定の両側でポートを結合したあとに，自動的にネゴシエーションされます。

ネットワーク管理者は多くの場合，信頼性および必要なサーバーとスイッチ間のリソースの使用を実現するために，2種類のうちどちらかのスイッチからサーバーへの接続を使用することを選択します。

オプション1：サーバーの2つ以上のポートを結合し，スイッチにある同じ番号のポートに接続します。サーバーまたはスイッチのポートに障害が発生すると，バックアップポートがアクティブ化されます。

オプション2：サーバーとスイッチの両方を結合し，集約してすべてのポートの集約合計帯域幅を提供します。

NNMiは，サーバーからスイッチへのリンクアグリゲーション（S2SLA）の検出機能を提供し，スイッチからサーバーへの接続の管理を容易にします。NNMiがノードのS2SLA情報を適切に検出できるか確認するには，次のタスクを実行してください。

デフォルトで，LinuxはSNMPエージェントパッケージ，Net-SNMPをインストールしません。Net-SNMPがNNMi管理サーバーにない場合，インストールする必要があります。

Linux上で結合しているインタフェースは，集約されたインタフェースの1つのMACアドレスを前提とすることがありますが，必須ではありません。結合されたインタフェースは，どのサーバーのインタフェースにも属さないMACアドレスを持つことができます。

メモ

集約でのすべてのインタフェースで同じMACアドレスが使用されます。SNMPインタフェーステーブルを確認して，アグリゲータインタフェースおよび集約されたインタフェースに同じMACアドレスを返します。共有MACアドレスは送信パケットで使用されます。アクセススイッチのFDBテーブルは，スイッチの集約されたインタフェースを介して伝えられると，このMACアドレスを示します。

元のMACアドレスを表示するには，次のコマンドを実行します。

cat /proc/net/bonding/bond0

6.4　検出の評価

ここでは，検出の進行状況と成功したかどうかを判定する方法を説明します。

6.4.1　初期検出の進行状況をたどる

NNMi検出は，動的かつ継続的です。完了することはないため，「検出完了」のメッセージが表示されることはありません。初回の検出と接続には，多少の時間が掛かります。初期検出の進行状況を測定する方法を次に示します。

［システム情報］ウィンドウの［データベース］タブで，ノードカウントが予想レベルに達して一定になるのを監視します。このウィンドウは自動的に更新されません。初期検出時に，［システム情報］ウィンドウを複数回開きます。

［設定］＞［検出］＞［シード］ビューを見てください。このビューを，すべてのシードに「ノードが作成されました」の結果が表示されるまで更新してください。「ノードが作成されました」の結果は，デバイスがトポロジデータベースに追加されたことを示します。この結果は，NNMiがデバイスからすべての情報を収集してデバイスの接続を処理したことを示すものではありません。

代表ノードの［ノード］フォームを開きます。［検出状態］フィールドが「検出が完了」に移行するときには，NNMiはノードの基本特性，ノードのARPキャッシュ，隣接検出プロトコル（該当する場合）の収集を済ませています。この状態は，NNMiがデバイスの接続解析を完了したことを示すものではありません。

［ノード］インベントリビューで，ネットワークのさまざまな領域のキーデバイスが存在していることを確認します。

代表ノードの［レイヤー2の近隣接続ビュー］を開き，その領域の接続解析が完了したかどうかを確認します。

［レイヤー2の接続］および［VLAN］インベントリビューを調べて，レイヤー2処理の進行状況を測定します。

6.4.2　シードの検出を確認する

［シード］ビューを開く。

［シード］ビューで，ノードのリストを［検出シードの結果］列でソートする。

ノードがエラー状態の場合は，次について検討してください。

ノードに到達できなかった，またはDNS名が解決されなかったために検出が失敗した−これらのタイプの失敗に対しては，ノードへのネットワーク接続を確認して，DNS名解決が正しいかどうかを調べてください。DNS問題に対処するには，IPアドレスを使用してノードをシードするか，ホスト名をhostnolookup.confファイルに加えます。

IPアドレスが原因で名前解決されない場合には，該当するIPアドレスをipnolookup.confファイルに含めます。詳細については，hostnolookup.confおよびipnolookup.confのリファレンスページを参照してください。

ライセンスノード数超過−この状況は，検出されたデバイス数がライセンス限度に達したときに発生します。検出したノードを幾つか削除するか，ライセンスの追加を検討してください。

ライセンス情報を追跡する際には，次の点に注意してください。

消費量：NNMiは，NNMiのライセンス容量限界までノードを検出および管理します（切り上げ）。

VMware環境：デバイスプロファイルがvmwareVMの各デバイスは，1/10のノードと同等です。

ほかのすべてのデバイスは1つの検出されたノードと同等です。

ノードが検出されたがSNMP応答がない−SNMP通信の問題は，シードされたデバイスだけでなく，自動検出によって検出されたデバイスにも発生します。詳細については，「5.4　通信の評価」を参照してください。

6.4.3　有効なデバイスプロファイルを確認する

［ノード］インベントリビューを開く。

［デバイスのプロファイル］列を，「No Device Profile」文字列が含まれるようにフィルタリングする。

ノードが検出されてもデバイスプロファイルがない場合は，［設定］＞［デバイスのプロファイル］で新規デバイスプロファイルを追加してから，ノードに対して設定のポーリングを実行してそのデータを更新する。

6.4.4　ノードの検出を確認する

すべてのノードが正しく検出されるために，管理ドメイン内のほかのドメインには表示されない固有のIPアドレスを使用するノードだけをNNMiで管理するようにします。例えば，ノードが突然消えたり，データベース内の別のノードとマージされたりして，そのノードがルーター冗長グループの一部になっている場合，ルーター冗長グループに参加しているルーターを管理するには，ルーターの管理アドレスとして保護されたアドレス以外の固有のIPアドレスを使用し，そのアドレスでSNMPを有効にする必要があります。保護されたIPアドレスを管理アドレスとして使用しようとすると，NNMiはルーターを適切に管理できません。

［ノード］インベントリビューでデータを調べます。管理アドレスがないノードがある場合は，これらのノードの通信設定を「5.4.1　ノードのSNMPの設定を確認する」の説明に従って確認します。

予想したノードが［ノード］インベントリビューにない場合は，次について確認します。

見つからなかったノードごとに，検出プロトコル（例えばCDP）が正しく設定されていることを確認します。

見つからないノードがWAN上にある場合，そのノードを含む自動検出ルールのPingスイープを有効にします。

6.4.5　自動検出ルールを評価する（ルールベース検出だけ）

予期しない検出結果に遭遇した場合は，自動検出ルールを再検討します。

NNMi検出でアドレスヒントが見つかる場合は，最初の一致ルールを使用してノードを作成するかどうかを判定しています。一致するルールがない場合，NNMi検出はヒントを廃棄します。自動検出ルールの順序番号によって，自動検出ルール設定が適用される順序が決まります。

それぞれの自動検出ルールで，次の設定を確認してください。

［マッチングノードの検出］を有効にし，自動検出がルールで実行されるようにする必要があります。

次の設定が，検出したいノードのタイプに対して正しいかどうかを確認します。

−SNMPデバイスの検出

−非SNMPデバイスの検出

デフォルトではルーターとスイッチだけが検出されて，SNMP以外のノードは検出されません。［SNMPデバイスの検出］を有効にすると，すべてのSNMPデバイスを検出します。［非SNMPデバイスの検出］を有効にすると，非SNMPデバイスも検出します。ご使用の環境を考慮せずにこれらの設定を有効にすると，予期した以上のノードを検出してしまうおそれがあります。

(1)　IPアドレス範囲

検出ヒントのIPアドレスは，IPアドレス範囲リスト内の［ルールに含める］エントリと一致する必要があります。含まれるIPアドレス範囲が自動検出ルールの中にない場合，すべてのアドレスヒントが一致と見なされます（この場合は，「6.3.1　自動検出ルールを設定する場合のヒント」を参照してください）。さらに，アドレスは「ルールにより無視された」とマークされたエントリと一致してはなりません。すべてのチェックが正常に一致すると，そのルールの設定が検出ヒントの処理に使用されます。

予想したデバイスの幾つかが検出されない場合，そのデバイスのIPアドレスが範囲の中に含まれていているか，また小さい順序番号のルールで無視されていないかを確認してください。

必要以上のデバイスが検出されている場合は，検出範囲を変更するか，検出したくないデバイスのIPアドレスが無視される範囲を追加してください。また，［SNMPデバイスの検出］も有効かどうかを確認します。

(2)　システムオブジェクトIDの範囲

検出ヒントのシステムオブジェクトID（OID）は，システムオブジェクトID範囲リストの中の［ルールに含める］エントリと一致する必要があります。含まれるシステムオブジェクトID範囲が自動検出ルールの中にない場合，すべてのオブジェクトIDが一致と見なされます。さらに，OIDは「ルールにより無視された」とマークされたエントリと一致してはなりません。すべてのチェックが正常に一致すると，そのルールの設定は検出ヒントの処理に使用されます。

システムオブジェクトID範囲を使用して，自動検出を拡大し，デフォルトのルーターおよびスイッチ以外も含めるか，特定のルーターおよびスイッチを除外します。

検出された各ノードは，トポロジデータベースに追加される前に指定されたIPアドレス範囲とシステムオブジェクトID範囲の両方と一致する必要があります。

6.4.6　接続とVLANを評価する

NNMiはレイヤー2接続とVLANを，デバイスがトポロジに追加されたあとの別のステップとして作成します。接続とVLANを評価する前の初期検出として十分な時間を考慮してください。

レイヤー2の接続を評価するには，対象とする各ネットワーク領域のノードグループを作成し，続いてそのノードグループのトポロジマップを表示します（［ノードグループ］インベントリで，ノードグループを選択して，［アクション］＞［マップ］＞［ノードグループマップ］をクリックします）。このマップでほかのノードに接続していないノードを探します。

VLANを評価するには，［VLAN］インベントリビューからそれぞれの［VLAN］フォームを開いて，そのVLANのポートのリストを調べます。

6.4.7　デバイスを再検出する

デバイスの削除を確認するには，次の手順を実行します。

デバイスの設定ポーリングを実行する。

デバイスを削除する。

そのデバイスがシードの場合，シードを削除してから再度シードを追加します。

6.5　検出の調整

標準的な検出が行われるようにするためには，検出設定を調整して重大なデバイスと重要なデバイスだけが検出されるようにしてください。

IPアドレス範囲やシステムオブジェクトID（またはその両方）でフィルタリングします。

非SNMPデバイスとSNMPデバイス（スイッチでもルーターでもないデバイス）の検出を制限します。

コマンドラインでNNMiデータベースからノードを削除するには，nnmnodedelete.ovplコマンドを使用します。このコマンドで，NNMiデータベースからノードが削除されますが，シード定義は削除されません。コマンドラインでNNMiデータベースからシード定義を削除するには，nnmseeddelete.ovplコマンドを使用します。

検出プロトコルコレクションを無効にすることで修復できる特別な検出状況もあります。詳細については，「21.24　特定ノードに対して検出プロトコルを使用しないように設定する」を参照してください。

6.5.1　応答のないオブジェクトを削除する

応答がなくなってから削除するまでの日数を指定して，次のオブジェクトを削除できます。

応答のないノード

停止中の接続

応答のないノードを削除するには，次の手順を実行します。

［設定］ワークスペースで，［検出］＞［検出の設定］を選択する。

［非応答オブジェクト制御の削除］領域で，対象のオブジェクトを削除するまでの日数を入力する。

オブジェクトを削除しない場合は，「0」を入力します。指定した日数が経過したあとに，応答のないオブジェクトはデータベースから削除されます。

メモ

［非応答ノードの削除］が有効な場合，NNMiは次の状況下にある仮想マシンノードを削除しません。

VMがSNMPエージェントをサポートしていない

VMware ToolsがインストールされていないためにVMにIPアドレスがない

VMのIPアドレス障害モニタリングが設定されていない

詳細については，NNMiヘルプ「管理」の「スケジュールを設定する」のヘルプトピック記載されている「応答のないノードを削除するかどうか設定する」を参照してください。

7　NNMiステータスポーリング

この章では，NNMi State Pollerサービスを設定し，ネットワーク監視を拡張および微調整するための情報を示します。

この章は，NNMiヘルプの情報を補充するものです。監視動作方法の紹介，および監視設定方法の詳細は，NNMiヘルプの「ネットワークの稼働状態をモニタリングする」を参照してください。

7.1　ステータスポーリングの概念

この節では，State Pollerがポーリンググループの評価に使う順序など，ネットワーク監視の簡単な概要を示します。この項を読んだあと，さらに詳細な情報については「7.2　ステータスポーリングの計画」に進んでください。

ネットワーク検出と同じように，ネットワークでクリティカル，または最も重要なデバイスのネットワーク監視に関心を集中する必要があります。NNMiは，トポロジデータベースにあるデバイスにだけポーリングを実施できます。どのネットワークデバイスを監視するか，使用するポーリングの種類，およびポーリングする間隔を制御できます。

［モニタリングの設定］フォームのインタフェースとノードの設定を使って，デバイスのステータスポーリングを高度化し，さまざまなクラス，インタフェースの種類，およびノードの種類についてポーリングの種類と間隔を設定できます。

State Pollerのデータ収集がICMP（ping）応答を基礎にするか，またはSNMPデータを基礎にするかを設定できます。NNMiは，ユーザーが有効にするデータ収集の種類から，実際のMIBオブジェクトへの内部的なマップを自動処理し，設定を大幅に簡略化します。

メモ

（SNMPエージェントに加えて）Webエージェントが設定されている場合，NNMiは追加のプロトコル（例えば，VMware環境用のSOAPプロトコル）を使用できます。

ポーリング設定の計画を作成するときは，State Pollerサービス用にインタフェースグループとノードグループをセットアップする方法について考える必要があります。グループという概念については「4.6　ノードグループおよびインタフェースグループ」と「4.7　ノード／インタフェース／アドレス階層」を参照してください。

7.1.1　評価の順序

インタフェースまたはノードは複数のグループに属することがあるので，State Pollerは，定義された評価順序で，設定されたポーリング間隔およびポーリング種類を適用します。検出されたトポロジ内の各オブジェクトについて次のように評価されます。

オブジェクトがインタフェースの場合，State Pollerは基準を満たすインタフェースグループを探す。

グループは小さい順序番号から大きい順序番号へ順に評価されます。最初に一致するグループが見つかると，その時点で評価は停止します。

オブジェクトに一致するインタフェースグループがない場合，ノードグループが小さい順序番号から大きい順序番号へ順に評価される。

最初に一致するグループが見つかると，その時点で評価は停止します。インタフェースのうち，独自の特性に関してインタフェースグループと一致しないものは，所属するノードからポーリング設定を継承します。

検出されたものの，ノードまたはインタフェースの設定定義に含まれないデバイスは，グローバルな監視設定（［モニタリングの設定］フォームの［デフォルト設定］タブ）によって監視動作が確定される。

7.2　ステータスポーリングの計画

この節では，ポーリング設定チェックリストなど，State Poller設定の計画作成について説明します。監視の計画作成に便利な詳細情報によって，ポーリンググループの作成法が決まり，ポーリングプロセスの間にどの種類のデータを取得する必要があるかが決まります。

7.2.1　ポーリングチェックリスト

次のチェックリストを使って，State Poller設定の計画を作成できます。

□NNMiで何を監視できますか？

□オブジェクトの種類，場所，相対的重要性，そのほかの基準に基づいて，監視対象は論理的にどのように分類できますか？

□NNMiは，各グループをどのくらいの頻度で監視する必要がありますか？

□監視されるアイテムの情報を取得するために，何のデータを収集する必要がありますか？次のものが含まれることがあります。

−ICMP（ping）応答

−SNMP障害データ

−追加のSNMPコンポーネント稼働状態データ

メモ

（SNMPエージェントに加えて）Webエージェントが設定されている場合，NNMiは追加のプロトコル（例えば，VMware環境用のSOAPプロトコル）を使用できます。

(1)　ポーリング設定の例

ポーリング設定プロセスの理解を深めるために，次の例について考えます。ネットワークにProximiTの最新のプロキシサーバーが含まれていると仮定します。これらのデバイスに到達できることを確認する必要がありますが，プロキシサーバーのSNMP監視は要求しません。

NNMiで何を監視できますか？

監視できるのは検出されたものだけであるため，自動検出ルールを設定して，NNMiのデータベースに自分のプロキシサーバーがあることを確認します。検出の設定の詳細は，「6.　NNMi検出」を参照してください。

監視対象は論理的にどのように分類できますか？

複数のプロキシサーバーを1つのグループに分類し，同じ監視設定を適用するのが合理的です。デバイスのインタフェース（SNMP）監視を行っていないので，インタフェースグループは必要ありません。

このノードグループを使ってビューをフィルタし，プロキシサーバーのステータスをグループとしてチェックし，グループをサービス停止中にしてファームウェアを更新することもできます。

NNMiは，各グループをどのくらいの頻度で監視する必要がありますか？

サービスレベル契約条項で，プロキシサーバーについて5分間のポーリング間隔で十分です。

どのデータを収集する必要がありますか？

監視設定がほかのグループと異なるのは次の点です。プロキシサーバーの例として，ICMP障害の監視を有効にし，SNMP障害ポーリングの監視を無効にします。グループについてのSNMP障害監視がない場合，コンポーネント稼働状態監視は適用されません。

ネットワークデバイスからNNMiにどのSNMPトラップを送信するのですか？

次のポーリング間隔を待機しないでトラップが受信される場合，NNMiは一部のSNMPトラップを使用してデバイスをポーリングします。

これらの設定選択肢に関する計画作成情報の詳細は，次の項を参照してください。

「7.2.2　NNMi で監視できる項目」

「7.2.3　監視の停止」

「7.2.4　監視されないノードへのインタフェース」

「7.2.5　モニタリングの拡張」

「7.2.6　ノードグループとインタフェースグループを作成する」

「7.2.7　ポーリング間隔を計画する」

「7.2.8　収集するデータを計画する」

「7.2.9　SNMPトラップがNNMiに送信する内容を決定する」

7.2.2　NNMi で監視できる項目

State Poller サービスは，検出された各インタフェース，アドレス，および管理ドメインでアクティブに監視されるように指定されているSNMP エージェントを監視します。 State Poller サービスは，カード，シャーシ，ノードセンサー，物理センサー，ルーター冗長性グループなどを監視するようにも設定できます。

メモ

ほとんどの場合，インタフェースに接続されたポーリングによってだけ，十分に正確な根本原因分析ができます。監視対象インタフェースのセットを拡張すると，ポーリングのパフォーマンスに影響が及ぶおそれがあります。

NNMi がハイパーバイザーネットワーク環境を監視している場合は，さらに次のものを含むオブジェクトも監視されます。

ハイパーバイザー

ハイパーバイザーでホストされている仮想マシン（VM）

仮想スイッチ

アップリンク（インタフェースオブジェクトとして表される）

ヒント

仮想マシンにVMware Toolsがインストールされていることを確認し，NNMiによって提供されている仮想マシンノードグループを使用して，仮想マシンに関連付けられているIPアドレスの障害ポーリングを有効にしてください。基盤となる仮想マシンが削除された場合やNNMiが管理できないハイパーバイザーに移動された場合にも，NNMiがすべてのVMノードを特定できるようにするには，この方法を実践することをお勧めします。障害ポーリングを有効にする方法の詳細については，NNMiヘルプ「管理」の「デフォルト設定」を参照してください。

仮想マシン（VM）に関連付けられているIPアドレスに対して障害ポーリングを有効にするには，NNMiが提供している仮想マシンノードグループを使用してください。基盤となる仮想マシンが削除された場合やNNMiが管理できないハイパーバイザーに移動された場合にも，NNMiがすべてのVMノードを特定できるようにするには，この方法を実践することをお勧めします。詳細については，NNMiヘルプ「管理」の「スケジュールを設定する」のヘルプトピック記載されている「応答のないノードを削除するかどうか設定する」を参照してください。

モニタリングの詳細については，NNMiヘルプを参照してください。「7.2.5　モニタリングの拡張」も参照してください。

7.2.3　監視の停止

NNMi 管理モードを使用して，デバイスまたはインタフェースを［管理対象外］または［サービス停止中］に設定できます。［管理対象外］は恒久的な状況と見なされます。オブジェクトのステータスを知る心配をする必要はありません。［サービス停止中］は一時的な状況と見なされます。 1 つ以上のオブジェクトがオフラインになり，停止中のインシデントが過剰になります。

すべてのグループ設定全体のオーバーレイとして，管理モードを考えてください。グループ，ポーリング間隔，種類に関係なく，オブジェクトのステータスが［管理対象外］または［サービス停止中］に設定されている場合，State Pollerはそのオブジェクトと通信しません。

ヒント

検出を行い，データベースに配置することを選択したデバイスやインタフェース（またはその両方）の中には，ポーリングの必要がないものもあります。［管理対象外］に恒久的に設定するオブジェクトに注意してください。1つ以上のノードグループを作成し，管理モードを簡単に設定することもできます。

7.2.4　監視されないノードへのインタフェース

直接管理していないデバイスに接続されているインタフェースのステータスを知る必要があることがあります。例えば，アプリケーションまたはインターネットサーバーへの接続が確立されているかどうか知る必要があるものの，そのサーバーのメンテナンスは担当していないことがあります。検出ルールにそのサーバーを組み入れていないと，NNMiはそのサーバーに接するインタフェースを未接続と見なします。

監視されていないノードに接続する重要なインタフェースのステータスを監視する方法には次の2つがあります。

監視されていないノードの検出。

監視されていないノードをNNMiトポロジに追加するとき，NNMiは，トポロジの残りの部分にノードを接続しているインタフェースを接続済みと見なします。この場合，監視設定に従ってこれらのインタフェースをポーリングできます。NNMiはノードを管理対象として検出します。NNMiに監視させたくないノードを非管理対象にしてください。

メモ

検出された各ノードは，そのノードを管理しているかどうかにかかわらず，ライセンスの最大数まで数えられます。

未接続インタフェースのポーリング。

未検出ノードの接続を含むネットワークデバイスのノードグループを作成できます。次に，ノードグループの未接続インタフェースのポーリングを有効にします。

NNMiは，ノードグループのデバイス上のインタフェースをすべてポーリングするので，多数のインタフェースのあるデバイスに対するトラフィックが大量に追加されます。

7.2.5　モニタリングの拡張

監視を拡張して，次が含まれるようにできます。

未接続インタフェース。

デフォルトでは，NNMiが監視する未接続インタフェースはIPアドレスのあるものだけであり，ルーターノードグループに含まれます。

メモ

NNMiは，次のように，NNMiが検出した別のデバイスに接続されていないインタフェースとして未接続インタフェースを定義します。

ルーターインタフェースのように，IPアドレスのあるインタフェース。

SNMPをサポートしないデバイス用のICMPポーリング。

デフォルトでICMPポーリングは，非SNMPデバイスノードグループについて有効です。

7.2.6　ノードグループとインタフェースグループを作成する

ノードグループとインタフェースグループをセットアップしてから，監視を設定する必要があります。したがって，ノードグループとインタフェースグループを設定するときはポーリング要求について考慮します。重要なデバイスを頻繁に監視できるようにノードグループとインタフェースグループを設定するのが理想的です。クリティカルでないデバイスをチェックする場合，チェック回数を減らすこともできます。

ヒント

ネットワークを監視するノードおよびインタフェースグループのセットを1つ設定します。マップでネットワークの可視化用に異なるノードグループのセットを設定します。

これらグループは，［設定］＞［オブジェクトグループ］＞［ノードグループ］または［設定］＞［オブジェクトグループ］＞［インタフェースグループ］ワークスペースを使用して定義します。これらグループは，デフォルトで，インシデント，ノード，インタフェース，およびアドレスビューをフィルタするのに使うのと同じグループです。監視設定用に，別のノードフィルタまたはインタフェースフィルタ定義を作成するには，ノードグループまたはインタフェースグループを開き，［ノードグループ］フォームまたは［インタフェースグループ］フォームで［ビューフィルターリストに追加］チェックボックスをオンにします。［保存して閉じる］をクリックして定義を保存します。

［モニタリングの設定］フォームの［ノードの設定］タブと［インタフェースの設定］タブにあるノードグループまたはインタフェースグループのレベルで，ポーリングの種類とポーリングの間隔を設定します。

類似のポーリングのニーズごとに，インタフェースやデバイス（またはその両方）をグループにまとめる基準を決定します。計画作成に際して考慮する必要がある要因は次のとおりです。

ネットワークのどのエリアにこれらのデバイスがありますか？タイミング制限がありますか？

デバイスの種類ごとにポーリング間隔または収集するデータを変更しますか？インタフェースの種類ごとに変更しますか？

NNMiが提供する事前設定されたグループを使用できますか？

ヒント

同時にサービス停止中になりそうなオブジェクトのグループ定義を，場所ごとまたはそのほかの基準ごとに作成できます。例えば，IOSアップグレードを適用する間は，すべてのCiscoルーターをサービス停止中モードにできます。

(1)　インタフェースグループ

基準に基づいて，どのインタフェースグループを作成するか決定します。インタフェースグループが最初に評価されることを覚えておいてください（「7.1　ステータスポーリングの概念」参照）。インタフェースグループはノードグループのメンバーを参照できるので，インタフェースグループの設定を実施する前に，ノードグループの設定を完了した方がよいケースもあります。

事前設定されたインタフェースグループ

NNMiには，設定済みの便利なインタフェースグループが幾つかあります。例えば，次のとおりです。

ISDN接続に関連づけられたIFTypeのある全インタフェース

音声接続用のインタフェース

ポイントツーポイント通信用のインタフェース

ソフトウェアループバックインタフェース

VLANインタフェース

リンクアグリゲーションプロトコルに関与するインタフェース

既存のグループを使用するか，それらを変更するか，または自分専用のグループを作成できます。

インタフェースグループには次の2種類の設定項目があります。つまり，所属するノードが含まれるノードグループとインタフェースのIFTypeまたはほかの属性です。これらは次のように組み合わせられます。

IFTypeと無関係に，ノードグループ内のノードのすべてのインタフェースをグループにまとめる。IFTypeまたは属性（名前，エイリアス，説明，速度，インデックス，アドレス，またはそのほかのIFType属性など）は選択しない。

インタフェースが存在するノードに関係なく，特定のIFTypeまたは属性のすべてのインタフェースをグループにまとめる。

特定のノードグループに存在する特定のIFTypeまたは属性のインタフェースだけをグループにまとめる。

(2)　ノードグループ

インタフェースグループの計画を作成してから，ノードグループの計画を作成します。監視用に作成されたノードグループがビューのフィルタに意味があるとは限らないので，それらは個別に設定できます。

事前設定されたノードグループ

設定作業を簡単にするために，ノードグループのデフォルト集合を用意しています。これらの基礎になっているのは，検出プロセスの間にシステムオブジェクトIDから導出されたデバイスカテゴリです。デフォルトのノードグループには次が含まれます。

ルーター

ネットワーキングインフラストラクチャデバイス（スイッチ，ルーターなど）

Microsoft Windowsシステム

SNMPコミュニティ文字列がわからないデバイス

重要ノード。Causal Engineによって内部的に使用されており，コネクタ障害の危険にさらされているデバイスの特殊処理を提供します。詳細については，NNMiヘルプの「定義済ビューフィルターとして使用されるノードグループ」を参照してください。

仮想マシン

既存のグループを使用するか，それらを変更するか，または自分専用のグループを作成できます。

次のノード属性を使用して，関連するノードの定義に条件を付けることができます。

ノード上のIPアドレス

ホスト名のワイルドカード抽出

デバイスプロファイルから得られる情報（例えば，カテゴリ，ベンダー，ファミリ）

MIB II sysName，sysContact，sysLocation

使われない余分なエントリがリストに追加されないように，設定および表示用に豊富なグループのセットを作成し，バランスを取ってください。

ヒント

シンプルで再使用可能な小さいグループを作成し，監視または視覚化のためにこれらを組み合わせて，階層的なまとまりにできます。例えば，「すべてのルーター」と「IPアドレスの末尾が100のすべてのシステム」のように，グループ定義は重なることがあります。ノードは複数のグループに属することがあります。

デバイスプロファイルとの相互作用

各デバイスが検出されると，NNMiはシステムオブジェクトIDを使用して，使用可能なデバイスプロファイルのリストを検索します。デバイスプロファイルは，ベンダー，製品，ファミリ，デバイスカテゴリなど，デバイスの追加属性を導出するために使用されます。

ノードグループを設定するとき，これら導出された属性を使用して，監視設定に適用するデバイスをカテゴリにまとめられます。例えば，ベンダーを問わずに，ネットワーク全体のすべてのスイッチを特定のポーリング間隔でポーリングすることもできます。デバイスカテゴリの「スイッチ」を自分のノードグループの定義特性として使えます。システムオブジェクトIDがカテゴリ「スイッチ」にマップされるデバイスはすべて，そのノードグループの設定が反映されます。

ヒント

NNMiがハイパーバイザーネットワーク環境を管理している場合は，仮想マシン(VM) だけが含まれるノードグループを作成できます。これらのノードは，vmwareVMデバイスプロファイルを使用して識別できます。このノードグループを使用すると，ハイパーバイザーでホストされなくなったVMがないかをチェックすることもできます。このノードグループを選択したあと，Hosted On = nullでフィルターし，これらのVMを特定します。このノードグループを使用して，VMに関連付けられているIPアドレスの障害ポーリングを有効にすることもできます。これは，関連付けられたハイパーバイザーが削除されている場合でもVMを継続的に監視できるようにするベストプラクティスでもあります。

7.2.7　ポーリング間隔を計画する

NNMiがデータを収集するのに使うポーリング間隔をオブジェクトグループごとに，選択します。サービスレベル契約条項に一致するように，間隔は1分間と短くすることもできますし，数日間と長くすることもできます。

ヒント

間隔が短いと，迅速にネットワーク問題を認識するのに役立ちます。しかし，あまりに短い間隔であまりに多くのオブジェクトをポーリングすると，State Pollerにバックログを発生させる可能性があります。リソース利用と間隔の間でお使いの環境にとって，最良のバランスを見つけてください。

メモ

根本原因分析エンジンは，24時間に一回ステータスポーリングを実施し，ステータス，結果およびインシデントの情報を更新します。このステータスポーリングは，デバイスに設定されたポーリング周期には影響しません。

7.2.8　収集するデータを計画する

State Pollerサービスは，ポーリングを使って，ネットワークで監視されているデバイスに関する状態情報を収集します。ポーリングはICMPやSNMP（またはその両方）を使って実行できます。

ICMP（ping）

ICMPアドレス監視は，ping要求を使って，管理対象の各IPアドレスが使用可能かどうかを確認します。

SNMPポーリング

SNMP監視は，監視されている各SNMPエージェントがSNMPクエリーに応答していることを確認します。

State Pollerは，間隔ごとに1つのクエリーで監視されている各オブジェクトから，設定済みのSNMP情報を収集するよう最適化されています。設定の変更をすると，State Pollerは各オブジェクトのグループメンバーシップを再計算し，収集する間隔とデータセットに再適用します。

SNMP監視は，監視されているすべてのインタフェースとコンポーネントにSNMPクエリーを発行し，MIB IIインタフェーステーブル，HostResources MIB，およびベンダー固有MIBから現在の値を要求します。障害監視に使われる値もあります。

Webポーリング

（SNMPエージェントに加えて）Webエージェントが設定されている場合，NNMiは追加のプロトコルを使用できます。例えば，VMware環境用のSOAPプロトコルなどです。

SNMPコンポーネント稼働状態データ

コンポーネントヘルス監視をグローバルなレベルで有効または無効にできます。障害に関するコンポーネント稼働監視は，デバイスの障害ポーリング間隔設定に従います。

ポーリングごとに追加データを収集しても，ポーリングの実行時間への影響はありません。しかし，各オブジェクトに関して格納される追加データによって，State Poller用に必要なメモリ容量が増加する可能性があります。

ヒント

監視設定変更をまとめて実施すると，State Pollerの進行中の操作への影響を少なくできます。

7.2.9　SNMPトラップがNNMiに送信する内容を決定する

NNMiは，SNMPトラップを受信したとき，次のポーリング間隔を待つのではなく，デバイスのポーリングに次のSNMPトラップを使用します。

CempMemBufferNotify

CiscoColdStart

CiscoEnvMonFanNotification

CiscoEnvMonFanStatusChangeNotif

CiscoEnvMonRedundantSupplyNotification

CiscoEnvMonSuppStatusChangeNotif

CiscoEnvMonTemperatureNotification

CiscoEnvMonTempStatusChangeNotif

CiscoEnvMonVoltageNotification

CiscoEnvMonVoltStatusChangeNotif

CiscoFRUInserted

CiscoFRURemoved

CiscoLinkDown

CiscoLinkUp

CiscoModuleDown

CiscoModuleUp

CiscoModuleStatusChange

CiscoRFProgressionNotif

CiscoRFSwactNotif

CiscoWarmStart

HSRPStateChange

IetfVrrpStateChange

Rc2kTemperature

RcAggLinkDown

RcAggLinkUp

RcChasFanDown

RcChasFanUp

RcChasPowerSupplyDown

RcChasPowerSupplyUp

Rcn2kTemperature

RcnAggLinkDown

RcnAggLinkUp

RcnChasFanDown

RcnChasFanUp

RcnChasPowerSupplyDown

RcnChasPowerSupplyUp

RcnSmltIstLinkDown

RcnSmltIstLinkUp

RcSmltIstLinkUp

RcVrrpStateChange

SNMPColdStart

SNMPLinkDown

SNMPLinkUp

SNMPWarmStart

トラップを受信したときにNNMiにデバイスをポーリングさせるには，これらのトラップをNNMiに送信するようにネットワークデバイスを設定します。

メモ

SNMPトラップインシデント設定の詳細については，NNMiコンソールから，［設定］ワークスペースに移動し，［インシデント］＞［SNMPトラップの設定］の順に選択します。

「(5)　SNMPトラップからの検出ヒント」も参照してください。

7.3　ステータスポーリングの設定

この節では，設定のヒントを示し，設定例を幾つか挙げます。この節を読んだあと，特定の手順については，NNMiヘルプの「NNMiモニタリング動作を設定する」を参照してください。

メモ

大幅な設定変更を行う前には，既存の設定のコピーを保存しておくことをお勧めします。詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

7.3.1　監視するインタフェースグループとノードグループを設定する

ポーリングにノードグループとインタフェースグループを使用すべき理由については，前のセクション「7.2.6　ノードグループとインタフェースグループを作成する」を参照してください。

NNMiコンソールまたはCSVファイルを使用して，ノードグループまたはインタフェースグループを作成できます。例えば，ノードグループ情報がMicrosoft Excelワークシートにある場合，この情報をCSVファイルとして保存してから，nnmloadnodegroups.ovplコマンドを使用して，NNMiに追加できます。同様に，nnmloadinterfacegroups.ovplコマンドを使用して，インタフェースグループ情報をNNMiに追加できます。詳細については，nnmloadnodegroups.ovplおよびnnmloadinterfacegroups.ovplのリファレンスページを参照してください。

NNMiコンソールでノードグループおよびインタフェースグループを作成するには，［設定］ワークスペースを使用します。詳細については，NNMiヘルプの「ノードまたはインタフェースのグループ作成」を参照してください。

（例）

ProximiTプロキシサーバー用にノードグループを設定する方法は次のとおりです。

［設定］＞［オブジェクトグループ］＞［ノードグループ］を開き，［新規作成］をクリックする。

グループProxy Serversという名前を付け，［ビューフィルターリストに追加］をオンにする。

［追加のフィルター］タブで，hostname属性を選択し，演算子の設定をlikeにする。

ノードのホスト名にprox*.yourdomain.comとして入力し，［保存して閉じる］をクリックする。

値は，prox*.example.comのようにワイルドカードを入力します。

ProximiTデバイスについてDevice Profile（デバイスプロファイル）とCategory（カテゴリ）を設定してある場合は，［デバイスフィルター］タブを使って［デバイスのカテゴリ］の選択個所にアクセスし，作成したProxy Serverカテゴリをグループのベースにできます。

グループ定義で［保存して閉じる］をクリックする。

メモ

インタフェースグループ設定で参照する前に，ノードグループを設定する必要があります。

7.3.2　インタフェースの監視を設定する

State Pollerは，ノードグループの前にインタフェースグループのメンバーを分析します。作成した各インタフェースグループ，および使用する既存のインタフェースグループについて，［モニタリングの設定］フォームの［インタフェースグループの設定］タブを開き，State Pollerがそのグループを処理する方法に関する個別の設定を作成します。設定には次のものが含まれます。

障害モニタリングの有効化または無効化

障害ポーリング間隔の設定

NNMiがグループ内の未接続インタフェース（またはIPアドレスをホストしている未接続インタフェース）を監視するかどうかの選択

インタフェースグループごとに異なる設定ができます。State Pollerは，小さい順序番号から順にリストを評価します。

ヒント

複数のグループにあてはまるオブジェクトは順序番号の小さいグループから設定を適用されることを頭に入れておきつつ，順序番号をダブルチェックします。

7.3.3　ノードの監視を設定する

あるオブジェクトが設定済みのインタフェースグループにあてはまらない場合，State Pollerはノードグループ内のメンバーシップについて，そのオブジェクトを評価します。設定は小さい順序番号から順に評価し，最初に合致するノードグループに適用されます。

ノードグループごとに，［モニタリングの設定］フォームを開いてから［ノードの設定］タブを開きます。State Pollerがそのグループを処理する方法に関する個別の設定を作成します。設定には次のものが含まれます。

障害モニタリングの有効化または無効化

障害ポーリング間隔の設定

NNMiがグループ内の未接続インタフェース（またはIPアドレスをホストしている未接続インタフェース）を監視するかどうかの選択

ノードグループごとに異なる設定ができます。

ヒント

複数のグループにあてはまるオブジェクトは順序番号の小さいグループから設定を適用されることを頭に入れておきつつ，順序番号をダブルチェックします。

7.3.4　監視のデフォルトを設定する

State Pollerは，定義済みのインタフェースの設定またはノードの設定に合致しないオブジェクトについて［デフォルト設定］タブの設定を適用します。このタブの設定を検討し，デフォルトレベルで自分の環境に合致することを確認します。例えば，デフォルト設定としてすべての未接続インタフェースをポーリングすることはほとんどないでしょう。

メモ

変更を有効にするためには，コンソールに戻るまでに，すべての［モニタリングの設定］フォームを必ず［保存して閉じる］ようにしてください。

7.4　ステータスポーリングの評価

この節では，監視設定の進行と成功を評価する方法を説明します。

7.4.1　ネットワーク監視の設定を確認する

NNMiが指定のノードまたはインタフェースの監視に使う設定をすると，ステータスポーリングをいつでも開始できます。

ネットワーク監視の設定を確認するには，次の点をチェックします。

(1)　インタフェースまたはノードは正しいグループのメンバーでしょうか？

(2)　どの設定が適用されていますか？

(3)　どのデータが収集されていますか？

(1)　インタフェースまたはノードは正しいグループのメンバーでしょうか？

あるグループにどのインタフェースまたはノードが属するか確認するには，［設定］ワークスペースで次の1つを選択します。

ノードグループ

インタフェースグループ

ヘルプの指示に従って，グループのメンバーを表示します。オブジェクトは複数のグループのメンバーになれること，ほかのグループの順序番号の方が小さい可能性があることを頭に入れておいてください。

その代わりに，オブジェクト（インタフェースまたはノード）を開き［ノードグループ］タブまたは［インタフェースグループ］タブをクリックして，オブジェクトが属するグループの完全なリストを表示することもできます。このリストは，グループ名でソートされているため，どの設定が適用されるかを決定する順序番号とは関係ありません。

オブジェクトがグループのメンバーでない場合は次のとおりです。

［インベントリ］ビューで，ノードのデバイスプロファイルを調べる。

［設定］＞［デバイスのプロファイル］で，そのデバイスプロファイルに関する属性の情報を確認する。

ノードグループ定義の属性要件を確認する。

不一致がある場合は，［デバイスのプロファイル］のカテゴリを修正して，その種類のデバイスがノードグループに当てはまるようにできます。ノードの属性を更新してグループに一致させるためには，［アクション］＞［ポーリング］＞［設定のポーリング］を実行する必要があります。

(2)　どの設定が適用されていますか？

特定のノード，インタフェース，またはアドレスに有効な監視設定をチェックするには，該当する［インベントリ］ビュー内のそのオブジェクトを選択し，［アクション］＞［設定の詳細］＞［モニタリングの設定］を選択します。NNMiに現在の監視設定が表示されます。

［障害SNMPポーリングの有効化］と［障害のポーリング間隔］の値を調査します。これらの値が予想どおりでない場合は，［ノードグループ］または［インタフェースグループ］の値を見て，どのグループが適用されるか調べます。

オブジェクトに対する通信が無効にされていないことを確認するために，オブジェクトの［アクション］＞［設定の詳細］＞［通信の設定］をチェックします。

(3)　どのデータが収集されていますか？

特定のデバイスのステータスポーリングを開始し，予想された種類のポーリング（SNMP，ICMP）がそのデバイスについて実行されていることを確認できます。

ヒント

（SNMPエージェントに加えて）Webエージェントが設定されている場合，NNMiは追加のプロトコルを使用できます。例えば，VMware環境用のSOAPプロトコルなどです。

ノードを選択し，［アクション］＞［ポーリング］＞［ステータスのポーリング］をクリックします。NNMiはデバイスのリアルタイムのステータスチェックを実行します。実行中のポーリングの種類と結果が出力されます。ポーリングの種類が予想したものでない場合は，ノードの監視設定，および監視設定のそれぞれのグローバル，インタフェース，またはノードに関する設定をチェックします。

7.4.2　ステータスポーリングのパフォーマンスの評価

自分の環境のステータスポーリングのパフォーマンスを評価するには，State Poller稼働状態チェックの情報を使って，State Pollerサービスの動作を数値で表し，評価します。

State Poller稼働状態情報は，Status Pollerがポーリング要求に応じることができるかどうかを示します。

(1)　State Pollerは最新の状態が反映されていますか？

次の表に説明されているように，［システム情報］ウィンドウの［ステートポーラー］タブでState Pollerサービスの現在の稼働状態情報をいつでもチェックできます。

表7‒1　State Poller稼働状態情報

情報

説明

ステータス

State Pollerサービスの全般的なステータス

ポーリングカウンタ

過去5分以内に要求された収集

過去5分以内に完了した収集

処理中の収集

収集要求の遅延

過去5分以内にスキップを実行した時刻

設定済みのポーリング間隔内で完了しなかった定期的に実行するポーリングの数。値が0でない場合は，ポーリングエンジンの処理が追いついていないか，または応答が戻ってくるまえにポーリングが実施されています。

監視する必要があるもの：この値が増加し続ける場合は，ターゲットとの通信に問題があるか，またはNNMiの負荷が過剰です。

実行する必要があるアクション：nnm.logファイルで文字列com.hp.ov.nms.statepollerで始まるクラスのメッセージを探して，スキップされたポーリングのターゲットを特定します。

スキップされたポーリングのターゲットが同じ場合，設定を変更して，これらのターゲットのポーリング頻度を低くするか，またはタイムアウトを増やします。

スキップされたポーリングのターゲットが異なる場合，NNMiのシステムパフォーマンス（特にovjbossの使用可能メモリ）を確認します。

過去5分以内の古い収集

古い収集というのは，少なくとも10分間，ポーリングエンジンから応答を受信していない収集のことです。稼働状態が良好なシステムでは古い収集はありません。

監視する必要があるもの：この値が一定して増加する場合は，ポーリングエンジンに問題があります。

実行する必要があるアクション：nnm.logファイルで文字列com.hp.ov.nms.statepollerで始まるクラスのメッセージを探して，古い収集のターゲットを特定します。

古い収集のターゲットが1つの場合，この問題を解決できるまでターゲットを管理から除きます。

古い収集のターゲットが異なる場合，NNMiシステムとNNMデータベースのパフォーマンスを確認します。NNMiを停止して再起動します。

ポーラーの結果キューの長さ

監視する必要があるもの：値が0または0に近いことを確認してください。0よりも大きい場合，次のアクションを実行してください。

実行する必要があるアクション：キューのサイズがきわめて大きい場合，ovjbossはメモリ領域不足の可能性があります。

状態マッパーキュー期間

監視する必要があるもの：値が0または0に近いことを確認してください。0よりも大きい場合，次のアクションを実行してください。

実行する必要があるアクション：このキューのサイズがきわめて大きい場合は，NNMiシステムとNNMiデータベースのパフォーマンスをチェックします。

状態アップデータキュー期間

監視する必要があるもの：値が0または0に近いことを確認してください。0よりも大きい場合，次のアクションを実行してください。

実行する必要があるアクション：このキューのサイズがきわめて大きい場合は，NNMiシステムとNNMiデータベースのパフォーマンスをチェックします。

状態アップデータ例外

監視の要点：この値は0になるはずです。

7.5　ステータスポーリングの調整

ステータスポーリングのパフォーマンスは次の重要な変数の影響を受けます。

ポーリングされるデバイス／インタフェースの数

設定されるポーリングの種類

各デバイスのポーリングの頻度

これらの変数は，ネットワーク管理のニーズによって決まります。ステータスポーリングについてパフォーマンス上の問題がある場合は，次の設定を確認してください。

個別のノードのポーリング設定はノードグループとインタフェースグループ内のメンバーシップによって制御されるので，類似のポーリング要求のあるノードまたはインタフェースがグループに含まれていることを確認します。

未接続インタフェースまたはIPアドレスをホストするインタフェースをポーリングしている場合は，設定をチェックして，必要なインタフェースだけをポーリングしていることを確認します。特別な制御を用意し，最小のインタフェースのサブセットを選んでポーリングするために，（［モニタリングの設定］フォームの［デフォルト設定］にではなく）［ノードの設定］フォームまたは［インタフェースの設定］フォームでこれらのポーリングを有効にしてください。

未接続インタフェースのポーリングでは，未接続のすべてのインタフェースが監視されることを覚えておいてください。IPアドレスのある未接続のインタフェースだけを監視するには，IPアドレスをホストするインタフェースのポーリングを有効にします。

監視設定とは無関係に，ステータスポーリングは，ネットワーク応答性に左右され，全般的なシステムパフォーマンスの影響を受ける可能性があります。デフォルトのポーリング間隔でのステータスポーリングは多くのネットワーク負荷を掛けませんが，NNMiサーバーとポーリングされているデバイスの間のネットワークリンクのパフォーマンスが低い場合，ステータスポーリングのパフォーマンスも低くなる可能性があります。タイムアウトを大きくし，再試行の数を小さく設定すると，ネットワーク負荷を低減できますが，これらの設定変更はあまり効果がないかもしれません。タイミングの良いポーリングを行うには，適切なネットワークパフォーマンスと十分なシステムリソース（CPU，メモリ）が必要です。

コンポーネント稼働状態監視を有効または無効にしても，ポーリングのタイミングには影響がありません。スケジュールされた時刻に，追加のMIBオブジェクトが収集されるだけです。ただし，コンポーネントヘルス監視を無効にすると，State Pollerが使用するメモリの量が減少する可能性があります。

8　NNMiインシデント

NNMiには，多数のデフォルトインシデントと相関処理が用意されています。デフォルトインシデントを利用すると，NNMiコンソールにすぐにインシデントを表示できます。また，相関処理を利用すると，インシデントを管理する数を減らすことができます。この章では，NNMiインシデントを設定することでネットワーク管理を微調整するのに役立つ情報を説明します。この章は，NNMiヘルプの情報を補充するものです。

NNMiインシデントの概要およびインシデント設定方法の詳細については，NNMiヘルプの「インシデントを設定する」を参照してください。

8.1　インシデントの概念

NNMiでは，次のソースからネットワークステータス情報が収集されます。

NNMiのCausal Engineではネットワークの稼働状態が分析され，継続的に各デバイスの稼働状態ステータス値が提供されます。Causal Engineでは，可能な場合は常にネットワーク障害の根本原因も広範囲に評価され，決定されます。

ネットワークデバイスからのSNMPトラップ。NNMiのCausal Engineは，分析中にトラップを症状に関する情報として使用します。

NNMiは，これらの情報をネットワーク管理に有用な情報を提供するネットワークステータス情報に変換します。NNMiには，ネットワークオペレータが考慮する必要があるインシデント数を減らす多くのデフォルトインシデント相関処理が用意されています。

デフォルトのインシデント相関処理をカスタマイズして，環境のネットワーク管理要件に一致する新規インシデント相関処理を作成できます。

NNMiコンソールのインシデント設定によって，NNMiが作成できるインシデントタイプが定義されます。インシデント設定が受信したSNMPトラップと一致しない場合，その情報は廃棄されます。ソースオブジェクトの管理モードが，NNMiデータベースで［非管理対象］もしくは［サービス停止中］に設定されている場合，またはデバイスが障害ポーリングで監視されていない場合，NNMiでは常に受信トラップは廃棄されます。

nnmtrapconfig.ovpl -dumpBlockListは，インシデント設定がないか，または無効なため，インシデントパイプラインに渡されなかったSNMPトラップなど，現在のインシデント設定に関する情報を出力します。

さらに，NNMiではNNMiトポロジにないネットワークデバイスからのSNMPトラップは廃棄されます。このデフォルト動作の変更の詳細については，NNMiヘルプの「未解決の受信トラップを処理する」を参照してください。

詳細については，NNMiヘルプの「NNMiによるインシデントの収集方法」を参照してください。

8.1.1　インシデントライフサイクル

次の表は，インシデントのライフサイクルの段階を説明したものです。

表8‒1　NNMiインシデントライフサイクル

ライフサイクル

状態

説明

状態設定者

インシデント

使用者

なし

NNMiイベントパイプラインはすべてのソースから入力を受領し，必要に応じてインシデントを作成します。

該当なし

NNMi

ダンプニング済み

インシデントは保管場所にあり，別のインシデントとの相関処理待ちです。インシデントビューアのインシデントを減らすために，この待機期間があります。

ダンプニング周期はインシデントタイプによって異なります。詳細については，「8.1.7　インシデントの抑制，強化，およびダンプニング」を参照してください。

NNMi

NNMi

登録済み

インシデントは，インシデントビューで見ることができます。

インシデントは任意の設定済み宛先へ転送されます（近隣またはグローバルマネージャー）。

NNMi

ユーザーはインシデントビューでこの状態を設定することもできます。

ユーザー

ライフサイクル移行アクション

進行中

インシデントは問題を調査するユーザーに割り当てられています。

ネットワーク管理者によってこの状態の特定の意味が定義されます。

ユーザー

ユーザー

ライフサイクル移行アクション

完了

インシデントによって指定された問題は，対処が完了し，解決しています。

ネットワーク管理者によってこの状態の特定の意味が定義されます。

ユーザー

ユーザー

ライフサイクル移行アクション

解決済み

このインシデントによってレポートされた問題が解決したことをNNMiが確認したことを示します。例えば，デバイスからインタフェースを取り外すと，そのインタフェースに関するインシデントはすべて，自動的に「解決済み」になります。

ユーザーまたはNNMi

ユーザー

ライフサイクル移行アクション

8.1.2　トラップおよびインシデント転送

次の表は，トラップおよびインシデントをNNMi管理サーバーから別の宛先へ転送する方法を要約したものです。

表8‒2　トラップおよびNNMiインシデント転送でサポートされている方法

項目

NNMiトラップ転送

NNMi Northboundインタフェーストラップ転送

グローバルネットワーク管理のトラップ転送

転送対象

ネットワークデバイスからのSNMPトラップ

ネットワークデバイスからのSNMPトラップ

ネットワークデバイスからのSNMPトラップ

転送フォーマット

受信したままのSNMPv1，SNMPv2c，またはSNMPv3トラップ（SNMPv3トラップはSNMPv2cトラップへ変換可能）

NNMiインシデントから作成されたSNMPv2cトラップ

NNMiインシデント

追加情報

ほとんどの場合，NNMiはvarbindを追加して元のソースオブジェクトを識別します。

NNMiがSNMPv1トラップを変更することはありません。

NNMiはvarbindを追加して元のソースオブジェクトを識別します。

リージョナルマネージャープロセスによってインシデントに追加された情報はすべて，転送済みインシデントに保持されます。

設定先

［設定］ワークスペースの［インシデント］＞［トラップサーバー］＞［トラップ転送設定］

［統合モジュールの設定］ワークスペースの［Northboundインタフェース］

［SNMPトラップの設定］フォームまたはsyslog設定の［グローバルマネージャーへの転送］タブ

注

−

−

グローバルマネージャーのインシデントビューに表示されるリモートインシデントを転送します。転送済みインシデントはグローバルマネージャー上での相関処理に参加します。

詳細情報

NNMiヘルプの「トラップ転送を設定する」

−

NNMiヘルプの「SNMPトラップインシデントのグローバルマネージャーへの転送を設定する (NNMi Advanced)」

（凡例）　−：該当なし。

8.1.3　受信済みSNMPトラップ

NNMiが管理デバイスから受信するSNMPトラップを別のアプリケーションに転送する場合は，次のどちらかの方法を使用します。

NNMi SNMPトラップ転送を使用します。

NNMi NorthboundインタフェースのSNMPトラップ転送メカニズムを使用します。

受信側アプリケーションがトラップを識別する方法は次のように異なります。

Windows（すべて）およびLinux（元のトラップではない場合）

デフォルトおよびSNMPv3からSNMPv2cへの変換転送オプションに該当します。

Windows NNMi管理サーバー上のNNMi SNMPトラップ転送メカニズムによって，送信先へ転送する前に各SNMPトラップが改編されます。トラップはNNMi管理サーバーからのものと考えられます（この情報は，［トラップ転送先］フォームで元のトラップ転送オプションが選択されていないLinux NNMi管理サーバーにも適用されます）。

トラップ送信元デバイスと受信するアプリケーションでのイベントとの関連づけを正しくするため，これらのトラップに関するルールを，追加されるvarbindによってカスタマイズする必要があります。originIPAddress(.1.3.6.1.4.1.11.2.17.2.19.1.1.3)varbindからの値を解釈します。originIPAddressの値は汎用タイプInetAddressのバイト文字列で，originIPAddressType(.1.3.6.1.4.1.11.2.17.2.19.1.1.2)varbindの値によって決まるInetAddressIPv4またはInetAddressIPv6です。ルールによってoriginIPAddressType varbindを読み取って，originIPAddress varbindのインターネットアドレスタイプ（ipv4(1)，ipv6(2)）の値を決定する必要があります。ルールによってoriginIPAddressの値を表示文字列に変換する必要もあります。

NNMiが転送されたトラップに追加するvarbindの詳細については，NNMiヘルプの「NNMiが提供するトラップvarbinds」，RFC2851および次のファイルを参照してください。

Windows：%NNM_SNMP_MIBS%¥Vendor¥Hewlett-Packard¥hp-nnmi.mib

Linux：$NNM_SNMP_MIBS/Vendor/Hewlett-Packard/hp-nnmi.mib

元のトラップ転送が設定されたLinux

Linux NNMi管理サーバーによって，NNMiが受信するものと同じフォーマットでトラップを転送できます。各トラップは管理対象デバイスがトラップ転送先に直接送信したように表示されるため，受信するアプリケーションに設定された既存のトラップ処理は変更なしで動作します。

NNMi Northboundインタフェース（全オペレーティングシステム）

NNMi Northboundインタフェースは各SNMPトラップを強化してから，トラップ転送先に転送します。トラップはNNMi管理サーバーからのものと考えられます。受信側アプリケーションのトラップ送信デバイスとイベント間の関連づけを正しくするため，これらのトラップのルールを収集したvarbindに対してカスタマイズする必要があります。nnmiIncidentSourceNodeHostname(1.3.6.1.4.1.11.2.17.19.2.2.21)およびnnmiIncidentSourceNodeMgmtAddr(1.3.6.1.4.1.11.2.17.19.2.2.24)varbindによって元のソースオブジェクトが識別されます。

8.1.4　MIB

NNMiでは，次の管理情報ベース（MIB）ファイルをNNMiデータベースにロードする必要があります。

カスタムポーラー機能，折れ線グラフ，またはその両方のMIB式で使用するすべてのMIB変数

NNMiが稼働状態を監視するセンサー（ファン，または電源など）

NNMiでは，管理情報ベース（MIB）ファイル，またはMIBファイルで定義されているトラップをNNMiデータベースにロードする必要があります。

8.1.5　カスタムインシデント属性

NNMiでは，カスタムインシデント属性（CIA）を使用して，インシデントに追加情報が追加されます。

SNMPトラップインシデントの場合，NNMiでは元のトラップvarbindはインシデントのCIAとして格納されます。

管理イベントインシデントの場合，NNMiでは関連情報（com.hp.ov.nms.apa.symptomなど）はインシデントのCIAとして追加されます。

インシデントCIAを使用すると，インシデントライフサイクル移行アクション，抑制，重複削除，強化などの範囲を絞り込むことができます。CIAを使用して，インシデントビューまたはフォームのアプリケーションメニュー項目の信頼性を絞り込むこともできます。

指定のインシデントにNNMiがどのCIAを追加するかを決定するには，インシデントビューのサンプルインシデントを開き，［カスタム属性］タブの情報を確認します。

(1)　解決済み管理イベントインシデントに追加されるCIA

管理イベントインシデントの原因となった状態が該当しなくなったとNNMi Causal Engineが判断すると，NNMiはそのインシデントのライフサイクル状態を［解決済み］に設定し，次の表にリストされているCIAをインシデントに追加します。NNMiコンソールユーザーは，［インシデント］フォームの［相関処理の注］フィールドでこの情報を確認できます。ライフサイクル移行アクションでは，CIAの値が直接使用されることがあります。

表8‒3　解決済みインシデントのカスタムインシデント属性

名前

説明

cia.reasonClosed

NNMiがインシデントをキャンセルしたか解決済みにした理由。

この理由は，NodeUpやInterfaceUpなど結果の名前にもなります。このフィールドが設定されていない場合は，NNMiコンソールユーザーがインシデントを解決済みにしたということになります。cia.reasonClosed CIAのNNMiの期待値を判断するには，NNMiヘルプの「NNMiによるインシデントの解決方法」を参照してください。

cia.incidentDurationMs

機能停止のタイムスタンプ（単位：ミリ秒）。

ステータスが停止中になってから動作中に戻るまでNNMiが測定します。この値は，cia.timeIncidentDetectedMsとcia.timeIncidentResolvedMsのCIAの差です。停止中インシデントと動作中インシデントのタイムスタンプを比較するより正確な測定値です。

cia.timeIncidentDetectedMs

NNMi Causal Engineが最初に問題を検出したときのタイムスタンプ（単位：ミリ秒）。

cia.timeIncidentResolvedMs

問題が解決したことをNNMi Causal Engineが検出したときのタイムスタンプ（単位：ミリ秒）。

NNMiは，多くの一次的根本原因インシデントと二次的根本原因インシデントに，表8-3に示したCIAを追加します。例えばNodeDownインシデントには，InterfaceDownインシデントとAddressNotRespondingインシデントが二次的根本原因として含まれることがあります。NNMiがNodeDownインシデントを解決済みにすると，NNMiは二次的インシデントも解決済みにして，それぞれのインシデントのコンテキストの値を含むCIAを二次的インシデントに追加します。

NNMiは，次のデフォルト管理イベントインシデントタイプには表8-3に示したCIAを追加しません。

NNMiコンソールユーザーが手動で解決済みにしたインシデント

NNMiデータベースから削除されたオブジェクトに応答してNNMiが解決済みにしたインシデント

IslandGroupDownインシデント

NnmClusterFailover，NnmClusterLostStandby，NnmClusterStartup，NnmClusterTransferの各インシデント

次のファミリのインシデント

相関処理

ライセンス

NNMi稼働状態

トラップ分析

8.1.6　インシデント数の削減

NNMiには，ネットワークオペレータがNNMiコンソールで見るインシデント数を削減する次のカスタマイズ可能相関処理が用意されています。

Pairwise相関処理

CiscoLinkDownに続くCiscoLinkUpのように，論理的な関係があり，［インシデント］ビューに両方を表示させる必要がない場合に，関連するインシデントとしてまとめて管理します。具体的には，インタフェースがLinkDownからLinkUpしたときにLinkDown/LinkUpのメッセージを抑止します。

重複削除相関処理

指定した時間ウィンドウ内に複数のインシデントのコピーを受信すると，重複削除インシデントの重複が相関処理されます。新たに受信した各重複インシデントの時間ウィンドウが再開始されます。このように，NNMiでは相関処理時間ウィンドウの全期間中，重複を受信しなくなるまで重複インシデントが相関処理されます。

レート相関処理

指定時間帯内にインシデントに関する指定コピー数を受信すると，レートインシデントの重複が相関処理されます。時間ウィンドウの残り時間にかかわらず，指定数のインシデントを受信するとNNMiによってレートインシデントが生成されます。

8.1.7　インシデントの抑制，強化，およびダンプニング

NNMiには，インシデントからほとんどの値を取得する便利な機能セットが用意されています。各インシデントタイプに対して，次のインシデント設定オプションでインシデントが関連する場合を具体的に指定できます。

抑制

インシデントが抑制設定に一致すると，そのインシデントはNNMiコンソールインシデントビューに表示されません。インシデントの抑制は，あるノード（ルーター，スイッチなど）にとっては重要であるが，ほかにとっては重要ではないインシデント（SNMPLinkDownトラップなど）の場合に便利です。

強化

インシデントが強化設定に一致すると，インシデントのコンテンツに応じて，NNMiによって1つ以上のインシデント値（重大度，メッセージなど）が変更されます。インシデントの強化は，トラップvarbind（ペイロード）に識別情報を継承するトラップ処理（RMONFallingAlarmなど）の場合に便利です。

ダンプニング

インシデントがダンプニング設定に一致すると，ダンプニング周期中，NNMiによってインシデントビューの表示更新，アクション実行などが遅延されます。インシデントのダンプニングは，NNMi Causal Engineがインシデントの根本原因分析を実行する時間が必要なときに，NNMiコンソールのインシデント数を減らせるため，分析の精度を上げることができます。

NNMiには，各インシデントタイプに抑制，強化，ダンプニングに対する次の設定レベルが用意されています。

インタフェースグループ設定

ソースオブジェクトがNNMiインタフェースグループのメンバーである場合のインシデント動作が指定されます。各インタフェースグループに異なる動作を指定できます。

ノードグループ設定

ソースオブジェクトがNNMiノードグループのメンバーである場合のインシデントの動作が指定されます。各ノードグループに異なる動作を指定できます。

デフォルト設定

デフォルトのインシデント動作が指定されます。

NNMiでは，各インシデントの設定領域（抑制，強化，ダンプニング）に対して，次の手順を使用して特定のインシデントの動作が決定されます。

インタフェースグループ設定をチェックする。

ソースオブジェクトが任意のインタフェースグループ設定に一致する場合は，一致内で最も小さい順序番号で定義された動作を実行し，一致検索を停止します。

ソースオブジェクトがどのインタフェースグループ設定とも一致しない場合は，手順2.を続行します。

ノード グループ設定をチェックする。

ソースオブジェクトが任意のノードグループ設定に一致する場合は，一致内で最も小さい順序番号で定義された動作を実行し，一致検索を停止します。

ソースオブジェクトがどのノードグループ設定とも一致しない場合は，手順3.を続行します。

デフォルト設定で定義された動作を実行する（ある場合）。

8.1.8　ライフサイクルの移行アクション

ライフサイクル移行アクションは管理者が提供するコマンドであり，インシデントのライフサイクル状態が変化してアクション設定と一致したときに実行されます。インシデントのアクション設定は，各インシデントタイプのそれぞれのライフサイクル状態ごとに設定されます。このインシデントタイプが特定のライフサイクル状態に移行すると，アクション設定によって，実行するコマンドが特定されます。コマンドには引数を指定でき，引数でインシデント情報がアクションコードに渡されます。

アクションコードは，NNMi管理サーバーで正しく実行されるJythonファイル，スクリプト，実行可能ファイルのどれかにできます。アクションコードは各インシデントタイプに固有のものにしたり，多くのインシデントタイプを処理するようにしたりできます。例えば，ConnectionDown，NodeDown，NodeOrConnectionDownのどれかのインシデントをNNMiが作成したときにネットワークオペレータを呼び出すアクションコードを作成できます。それぞれのインシデントタイプの［登録済み］ライフサイクル状態に1つのインシデントアクションというように，3つのインシデントアクションを設定できます。

同じように，アクションコードを1つのライフサイクル状態の変化に固有にしたり，複数のライフサイクル状態の変化に対応させたりできます。例えば，NNMiがInterfaceDownインシデントを作成したときにトラブルチケットを生成し，InterfaceDownインシデントがキャンセルされたときにトラブルチケットを解決済みにするアクションコードを作成できます。［登録済み］状態に1つ，［解決済み］状態に1つというように，InterfaceDownインシデントに2つのインシデントアクションを設定できます。

それぞれのアクション設定には，CIAに基づいてペイロードフィルタを組み込んで，アクションが実行されるときを制限できます。さらにフィルタリングするには，インシデントの強化を使用してCIAをインシデントに追加できます。NNMiはインシデントソースからその属性の値を判別します。例えば，一部のノードにカスタム属性を追加した場合は，この情報をインシデントにCIAとして追加し，インシデントアクションのペイロードフィルタをこの属性値に基づくようにできます。

8.2　インシデントの計画

次の領域で決定します。

処理するSNMPトラップ

表示するインシデント

インシデントに対するNNMiの対応方法

8.2.1　処理するSNMPトラップを計画する

ネットワークに関連するデバイストラップを識別し，各トラップのインシデント設定を計画します。NNMiでは，MIBをNNMiにロードしないでトラップを処理できます。

NNMiのnnmincidentcfg.ovpl -loadTrapsスクリプトを使用すると，SNMPトラップのインシデント設定の作成や更新を，MIBファイルを使用して自動化できます。MIBファイルにTRAP-TYPEまたはNOTIFICATION-TYPEマクロが含まれる場合は，インシデント設定に必要な情報を取得できます。

NNMiトポロジにないデバイスからのトラップを表示するかどうかを決定します。

8.2.2　表示するインシデントを計画する

インシデントのデフォルトセットで開始することをお勧めします。インシデント設定は徐々に拡大および削減できます。

重複削除，レート設定，Pairwise相関処理によって削減できるインシデントを計画します。

詳細については，NNMiヘルプ「管理」を参照してください。

8.2.3　インシデントに対するNNMiの対応方法を計画する

インシデントが発生した場合に，どのようなNNMiのアクション（例えば，ネットワークオペレータへの電子メール送信など）を実行するか，各アクションを実行するライフサイクルの状態を計画します。

詳細については，NNMiヘルプ「管理」を参照してください。

8.3　インシデントの設定

インシデントの設定手順については，NNMiヘルプの「インシデントを設定する」を参照してください。

メモ

大きな設定変更を行う前には，既存の設定のコピーを保存しておくことをお勧めします。詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

8.3.1　インシデントの抑制・強化・ダンプニングを設定する

インシデントの抑制，強化，ダンプニングを設定するときは，次のことに注意してください。

各インタフェースグループ，ノードグループ，またはデフォルト設定に対して設定を適用できる場合に，さらに絞り込むためのペイロードフィルタを指定できます。

インシデント設定フォームの［インタフェースの設定］タブにインタフェースグループを設定します。

インシデント設定フォームの［ノードの設定］タブにノードグループを設定します。

インシデント設定フォームの［抑制］，［強化］，および［ダンプニング］タブにデフォルトを設定します。

8.3.2　ライフサイクル移行アクションを設定する

ライフサイクル移行アクションを設定するときは，次のことに注意してください。

デフォルトでは，NNMiは次の場所でアクションを実行します。

Windows：%NnmDataDir%shared¥nnm¥actions

Linux：$NnmDataDir/shared/nnm/actions

アクションがこの場所にない場合は，［ライフサイクルの移行アクション］フォームの［コマンド］フィールドでアクションの絶対パスを指定します。

重要

Jythonファイルはactionsディレクトリに配置する必要があります。

アクション設定を変更するたびに，NNMiによってactionsディレクトリでJythonファイルが再読み取りされてNNMiにロードされます。

アクションは，グループとしてインシデントタイプに対して有効になります。

アクションに渡すことができるNNMi情報については，NNMiヘルプの「インシデントアクションを設定するための有効なパラメーター」を参照してください。

8.3.3　トラップログを設定する

NNMiでは，すべての着信SNMPトラップをログファイル（テキストファイルまたはCSVファイル）に記録できます。トラップは次の場所に記録されます。

Windows：%NnmDataDir%log¥nnm

Linux：$NnmDataDir/log/nnm

トラップログファイルは，nnmtrapconfig.ovplスクリプトを使用して設定します。次の形式を選択できます。

CSV（デフォルト）：トラップはCSV形式で記録されます（trap.csv）。

LOG：トラップはテキスト形式で記録されます（trap.log）。

BOTH：トラップはCSVとテキストの両方の形式で記録されます（2つのログファイル）。

OFF：トラップは記録されません。

例えば，BOTHモードでトラップを記録する場合は，次のコマンドを使用します。

nnmtrapconfig.ovpl -setProp trapLoggingMode BOTH -persist

-persist引数を使用することで，トラップサービスの再起動後もすべてのトラップサーバープロパティがそのまま有効になります。-persist引数を使用しない場合，すべてのトラップサーバープロパティはサービスが停止されるまでの間だけが有効です。

トラップはロールファイルに書き込まれます。ログファイルのサイズが定義された上限（nnmtrapconfig.ovplスクリプトを使用して定義）に達すると，ファイル名がtrap.<format>.oldに変更され，既存のファイルは置き換えられます。

詳細については，nnmtrapconfig.ovplリファレンスページを参照してください。NNMiヘルプの「トラップログ記録を設定する」もあわせて参照してください。

8.3.4　インシデントログを設定する

受信インシデント情報がincident.csvファイルに書き込まれるように，インシデントログを設定できます。この機能は，インシデント履歴を追跡およびアーカイブする場合に役立ちます。

インシデントログを設定して有効にするには，［設定］ワークスペースの［インシデントの設定］エリアにある［インシデントログの設定］タブに移動して設定します。詳細については，NNMiヘルプを参照してください。

8.3.5　トラップサーバープロパティを設定する

トラップサーバープロパティ（nnmtrapserver.properties）を設定するには，nnmtrapconfig.ovplスクリプトを使用します。

nnmtrapserver.propertiesファイルを直接編集しないでください。nnmtrapconfig.ovplスクリプトを使用してこのファイルを変更してください。

トラップサーバープロパティには次のデフォルト値が設定されています。

表8‒4　トラップサーバープロパティとそのデフォルト値

トラップサーバープロパティ

デフォルト値

com.hp.ov.nms.trapd.udpPort

162

com.hp.ov.nms.trapd.trapInterface

すべてのインタフェース

com.hp.ov.nms.trapd.recvSocketBufSize

53,248キロバイト

com.hp.ov.nms.trapd.pipeline.qSize

50,000トラップ

com.hp.ov.nms.trapd.blocking

true

com.hp.ov.nms.trapd.blockTrapRate

50トラップ/秒

com.hp.nms.trapd.unblockTrapRate

50トラップ/秒

com.hp.ov.nms.trapd.overallBlockTrapRate

150トラップ/秒

com.hp.nms.trapd.overallUnblockTrapRate

150トラップ/秒

com.hp.ov.nms.trapd.analysis.minTrapCount

100トラップ

com.hp.ov.nms.trapd.database.fileSize

100メガバイト

com.hp.ov.nms.trapd.database.fileCount

5ファイル

com.hp.ov.nms.trapd.database.qSize

300,000トラップ

com.hp.ov.nms.trapd.discohint.cacheSize

5,000エントリ

com.hp.ov.nms.trapd.discohint.cacheEntryTimeout

3,600ミリ秒

詳細については，nnmtrapconfig.ovplリファレンスページを参照してください。

8.4　インシデント設定のバッチロード

nnmincidentcfgdump.ovplとnnmincidentcfgload.ovplの2つのスクリプトをインシデント設定のバッチロードと併用できます。

8.4.1　nnmincidentcfgdump.ovplでインシデント設定ファイルを生成する

NNMiでは，nnmincidentcfgdump.ovplスクリプトを使用して，インシデント設定を作成または更新し，その後nnmincidentcfgload.ovplスクリプトを使用してNNMiデータベースにロードできます。ファイルは非XML形式で生成されます。

次のディレクトリにある形式の説明を使用して，ファイルを編集できます。

Windows：%NnmInstallDir%examples¥nnm¥incidentcfg

Linux：/opt/OV/examples/nnm/incidentcfg

インシデント設定のファイルを生成するには，次の構文の例を使用します。

nnmincidentcfgdump.ovpl -dump <file_name> -uuid -u <NNMiadminUsername> -p <NNMiadminPassword>

詳細については，nnmincidentcfgdump.ovplリファレンスページを参照してください。

8.4.2　nnmincidentcfgload.ovplでインシデント設定をロードする

NNMiでは，nnmincidentcfgload.ovplスクリプトを使用して，フォーマットされた設定ファイルからNNMiデータベースにインシデント設定をロードできます。

必要な形式については，次のディレクトリを参照してください。

Windows：%NnmInstallDir%examples¥nnm¥incidentcfg

Linux：/opt/OV/examples/nnm/incidentcfg

インシデント設定ファイルをNNMiデータベースにロードする前に検証するには，次の構文の例を使用します。

nnmincidentcfgload.ovpl -validate <file_name> -u <NNMiadminUsername> -p <NNMiadminPassword>

インシデント設定をロードするには，次の構文の例を使用します。

nnmincidentcfgload.ovpl -load <file_name> -u <NNMiadminUsername> -p <NNMiadminPassword>

次の点に注意してください。

NNMiは，名前またはそのほかのキー識別子が一致するすべての設定を更新します。

nnmincidentcfgdump.ovplスクリプトを使用して，既存のインシデント設定の設定ファイルを非XML形式で作成します。その後必要に応じて，NNMiデータベースにロードする前にこのファイルを編集できます。

NNMiは，これらの設定に関連づけられたコード値（インシデントファミリなど）の上書きも行います。

NNMiは，NNMiデータベースにないキー識別子のすべてのインシデント設定を追加します。

NNMiは，エクスポートされたファイル内で一致しないキー識別子の既存のインシデント設定は変更しません。

NNMiは，設定ファイルで提供されていない場合は一意のオブジェクトID（UUID）を解決します。

NNMiがUUIDを解決できない場合は，UUIDが作成されます。

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopコマンドおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

詳細については，nnmincidentcfgload.ovplリファレンスページを参照してください。

8.5　インシデントの評価

このセクションでは，インシデント設定を評価する方法を説明します。

NNMiがネットワークのすべての管理対象デバイスからトラップを受信したことを確認します。

NNMiがトラップを受信していない場合は，NNMi管理サーバーでファイアウォールの設定を確認します。

メモ

一部のウイルス対策ソフトウェアにはファイアウォールが組み込まれ，システムのファイアウォールとは別に設定されています。

最も重要なトラップがインシデントに変換されることを確認します。

正しいライフサイクルの状態移行でインシデントアクションが実行されていることを確認します。

NNMiがインシデントを期待どおり処理していることを確認します。

［アクション］＞［インシデントの設定レポート］メニューには，既存のインシデントをそのインシデントタイプの現在の設定に対してテストする複数のオプションがあります。これらのメニュー項目のどれかを使用しても，現在NNMiコンソールにあるインシデントは変更されません。

8.6　インシデントの調整

NNMiコンソールインシデントビューのインシデント数を削減します。次のメソッドのどれかを使用します。

NNMiコンソールでは必要のないインシデントタイプのインシデント設定を無効にします。

監視する必要がないネットワークオブジェクトの管理モードを［非管理対象］または［サービス停止中］に設定します。NNMiでは，これらのノードとそのインタフェースからのほとんどの受信トラップを廃棄します。

NNMiでネットワークオブジェクトが監視されないように設定します。NNMiでは，監視されないソースオブジェクトからのほとんどの受信トラップを廃棄します。

受信インシデントの追加条件または関係を識別します。これらの条件または関係が発生すると，NNMiでは受信管理イベントやSNMPトラップの条件またはパターンを識別して，関連するインシデントどうしを相関関係の子として入れ子にすることで，インシデントのフローが変更されます。

8.6.1　未定義のトラップのインシデントを有効化にする

NNMiはデフォルトでインシデント定義のないSNMPトラップを破棄します。

インシデント定義のないSNMPトラップを「UndefinedSNMPTrap」インシデントとして生成するには，次の手順を実行します。

次のファイルをテキストエディタで開く。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を検索する。

#!com.hp.nnm.events.allowUndefinedTraps=false

次のように編集します。

com.hp.nnm.events.allowUndefinedTraps=true

（任意）インシデントの重大度を指定する。

次の行を検索します。

#!com.hp.nnm.events.undefinedTrapsSeverity=NORMAL

「YourSpecifiedSeverity」にインシデントの重大度を指定します。

com.hp.nnm.events.undefinedTrapsSeverity=YourSpecifiedSeverity

有効な値は，NORMAL, WARNING, MINOR, MAJOR, CRITICAL です。

（任意）インシデントの根本原因を指定する。

次の行を検索します。

#!com.hp.nnm.events.undefinedTrapsNature=INFO

「YourSpecifiedNature」にインシデントの根本原因を指定します。

com.hp.nnm.events.undefinedTrapsNature=YourSpecifiedNature

有効な値は，ROOTCAUSE，SECONDARYROOTCAUSE，SYMPTOM，SERVICEIMPACT，NONE，INFOです。

（任意）UndefinedSNMPTrapインシデントを複数回出すかどうかを指定する。

各トラップOIDにつき1度だけUndefinedSNMPTrapインシデントを生成するか，トラップを受信するたびに毎回UndefinedSNMPTrapインシデントを生成するかを選択できます。

デフォルトでは，1度だけ生成します。毎回生成するように変更する場合は，次の行を検索します。

#!com.hp.nnm.events.allowMultipleUndefinedTrapIncidents=false

次のように編集します。

com.hp.nnm.events.allowMultipleUndefinedTrapIncidents=true

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

「UndefinedSNMPTrap」インシデントの一覧を見直す。

インシデントとして表示したいSNMPトラップは，インシデント定義を設定する必要があります。詳細については，NNMiヘルプを参照してください。

8.6.2　SNMPトラップのMIBデータの文字列を正しく解釈し表示する

SNMPトラップのMIBデータは，どのような文字セットで解釈すればよいか判断できません。

そのため，NNMiはSNMPトラップのMIBデータ(sysDescriptionやsysContactなど)を，文字化けして表示する場合があります。

正しく表示するためには，次の手順を実行し，NNMiがMIBデータの文字列を解釈するときに使用する文字セットを設定します。

メモ

新規インストール，かつ，日本語環境の場合，デフォルトで下記が設定されています。

UTF-8，EUC_JP，windows-31j，Shift_JIS

次のファイルをテキストエディタで開く。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を検索し，コメントアウト(#!com.hp.nnm.sourceEncoding=)されている場合は，コメント記号(#!)を削除する。

#!com.hp.nnm.sourceEncoding=

com.hp.nnm.sourceEncodingプロパティを編集する。

nms-jboss.propertiesファイルの例を参考にして，com.hp.nnm.sourceEncodingプロパティに，使用される環境でサポートしている文字セットをコンマ（,）区切りで追加します。

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

文字セットによる解釈をしないで，MIBデータを16進形式で表示する場合は，次の手順を実行します。

次のファイルをテキストエディタで開く。

Windows：%NnmDataDir%shared¥nnm¥conf¥nnmvbnosrcenc.conf

Linux：$NnmDataDir/shared/nnm/conf/nnmvbnosrcenc.conf

トラップOIDとVarBind OIDの組み合わせを追加する。

nnmvbnosrcenc.confファイルの例を参考にして，対象となるMIBデータのトラップOIDとVarBind OIDの組み合わせを追加します。

NNMiはインシデントフォームのカスタム属性値で，指定したMIBデータを16進形式で表示します。

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

9　NNMiコンソール

この章では，NNMiコンソールを使用してNNMiの機能を設定する具体的な方法について説明します。

9.1　ノードグループの使用例

ここでは，実際的な例を示して，ノードグループの設定について説明します。

設定するノードグループ

My Network：ほかのノードグループを含んでいる最上位レベルのコンテナノードグループ

USA：ほかのノードグループを含んでいる中間レベルのコンテナノードグループ

Colorado：Coloradoに存在するノードを含んでいるノードグループ

この例で，Coloradoはノードが含まれている唯一のノードグループです。

ノードグループの設定で，次のことに注意してください。

事前にノードグループマップのレイアウトを設計するのが効果的です。

ネットワーク監視のために，ノードグループとインタフェースグループのセットを1つ設定するのが効果的です。マップによって，ネットワーク可視化用に異なるノードグループのセットを設定します。

NNMiでは，幾つかの方法でノードグループとノードグループマップを設定できます。ここで説明する手順を理解することで，ノードグループやノードグループマップをより効率良く作成する方法を見つけることもできます。

ここでは，ノードグループとノードグループマップを設定する場合の手順について説明します。

ノードグループの作成

手順1：My Networkノードグループを作成する。

手順2：USAノードグループを作成する。

手順3：フィルタを使用してColoradoノードグループを作成する。

手順4：ノードグループメンバーを表示してノードグループのフィルタ結果を確認する。

手順5：My Networkノードグループのノードグループ階層を設定する。

手順6：USAノードグループのノードグループ階層を作成する。

親ノードグループには，ノードが含まれていない場合があります。その代わり，定義に子ノードグループだけが含まれています。この例では，My NetworkおよびUSAノードグループが，子ノードグループだけを含む親ノードグループです。

ノードグループマップの設定

手順1：ノードグループマップを作成する。

手順2：ノードグループマップを表示する。

手順3：ノードグループのステータスを設定する。

手順4：ノードグループマップの順序を設定する。

手順5：ノードグループマップに背景イメージを追加する。

9.1.1　ノードグループを作成する

ノードグループを作成してノードグループマップに追加します。

(1)　手順1：My Networkノードグループを作成する

次の手順で，My Networkノードグループを作成します。

［設定］ワークスペースに移動する。

［オブジェクトグループ］から［ノードグループ］を選択する。

［新規作成］アイコンをクリックする。

［名前］属性に，「My Network」と入力する。

［注］属性に，「最上位のノードグループです」と入力する。

［保存して閉じる］をクリックしてこの設定を保存する。

(2)　手順2：USAノードグループを作成する

［設定］ワークスペースに移動する。

［オブジェクトグループ］から［ノードグループ］を選択する。

［新規作成］アイコンをクリックする。

［名前］属性に，「USA」と入力する。

［保存して閉じる］をクリックしてこの設定を保存する。

(3)　手順3：フィルタを使用してColoradoノードグループを作成する

Coloradoノードグループを作成するには，フィルタエディタを使用してノードを選択するフィルタを設定します。

メモ

できれば，［追加のノード］タブを使用して一連のノードを指定するのではなく，［追加のフィルター］タブを使用してください。ノードグループフィルタを使用すると，NNMiでは，新規ノードがネットワークに追加されるときに，ノードを正しいノードグループに自動的に配置できます。

［設定］ワークスペースに移動する。

［オブジェクトグループ］から［ノードグループ］を選択する。

［新規作成］アイコンをクリックする。

［名前］属性に，「Colorado」と入力する。

［追加のフィルター］タブを選択する。

ノードが入力したホスト名値のどれかと一致する場合にNNMiがノードを照合するよう指定するには，［OR］をクリックする。

フィルタエディタの［属性］フィールドで，［hostname］を選択する。

［hostname］を選択すると，ノードがこのノードグループに属するかどうかを判断するときに，NNMiはホスト名値と照合します。

［演算子］フィールドで，［like］を選択する。

［like］を選択すると，検索でワイルドカード文字を使用できます。

［値］フィールドに，ノードグループに含めるデバイスを表す値を入力する。

例えば，cisco*.ntc.example.comは，cisco<値>.<network_domain>という名前のデバイスを表します。

［追加］をクリックする。

［属性］フィールドで，［hostname］を選択する。

［演算子］フィールドで，［like］を選択する。

［値］フィールドに，Coloradoノードグループに追加する残りのデバイス名を表すワイルドカードを入力する。

この例では，「cisco?*」を使用します。

［追加］をクリックする。

［保存］をクリックして，ウィンドウを閉じずにノードグループを保存する。

(4)　手順4：ノードグループのフィルタ結果を確認する

ノードグループフィルタを確認するため，作成したノードグループのメンバーを表示できます。

［アクション］＞［ノードグループの詳細］＞［メンバーの表示］を選択して，ノードグループ内のすべてのノードを含んだビューを開きます。

メモ

ノードグループフィルタが正しく動作すると確信できるまで，ノードグループフィルタ定義の結果を調べてください。

(5)　手順5：My Networkノードグループのノードグループ階層を設定する

My Networkノードグループを最上位レベルにして，ノードグループの階層を作成します。

［設定］ワークスペースの［オブジェクトグループ］＞［ノードグループ］ビューに戻り，作成したノードグループの一覧を表示する。

My Networkノードグループに移動して，［開く］をクリックする。

［子ノードグループ］タブをクリックする。

［新規作成］アイコンをクリックする。

［子ノードグループ］属性で，［検索］アイコンをクリックして［クイック検索］を選択する。

重要

［クイック検索］を使用して，ノードグループなどのオブジェクトがすでに存在する場合にはそれを選択します。

［USA］を子ノードグループとして選択する。

［OK］をクリックする。

［保存して閉じる］をクリックして変更を保存し，［ノードグループの階層］フォームを閉じる。

［保存して閉じる］をクリックして変更を保存し，［ノードグループ］フォームを閉じる。

(6)　手順6：USAノードグループのノードグループ階層を作成する

ColoradoをUSAノードグループの子ノードグループとして設定します。「(5)　手順5：My Networkノードグループのノードグループ階層を設定する」の手順を繰り返して行い，ColoradoノードグループをUSAノードグループの子に指定します。

これで，作成したノードグループごとにノードグループマップを作成する準備ができました。

9.1.2　ノードグループマップを設定する

作成したノードグループを使用してノードグループマップを設定するには，次の手順を実行します。

(1)　手順1：ノードグループマップを作成する

各ノードグループのノードグループマップを作成するには，［アクション］メニューを使用します。

マップを作成するノードグループを開く。

a　［設定］ワークスペースの［オブジェクトグループ］＞［ノードグループ］オプションに戻り，作成したノードグループの一覧を表示します。

b　対象のノードグループに移動し，［開く］アイコンをクリックします。

［アクション］＞［マップ］＞［ノードグループマップ］を選択して，ノードグループマップを表示する。

ノードおよびノードグループマップのアイコンの位置を決める。

［マップを保存］アイコンをクリックして，ノードマップアイコンを作成する。

メモ

ノードの位置を変更しない場合でも，ノードグループマップを作成するときには，いつでも［マップを保存］を使用してください。［マップを保存］によってノードグループマップが作成されます。

ノードグループマップが正常に作成されたことを知らせるダイアログボックスが表示されます。

［OK］をクリックする。

作成した各ノードグループで，手順1.〜手順5.までを繰り返す。

(2)　手順2：ノードグループマップを表示する

ノードグループマップを表示するには，次の手順を実行します。

［トポロジマップ］ワークスペースに移動する。

［ノードグループの概要］を選択する。

最上位レベルマップ［My Network］を選択する。

アイコンをダブルクリックして，子ノードグループのマップに移動する。

マップ上部の階層リンクを使用して前のマップに戻る。

(3)　手順3：ノードグループのステータスを設定する

NNMiによって，ノードグループのステータスの計算方法を設定できます。ノードグループのステータスを設定するときには，次の中からNNMiで使用する方法を決めます。

ノードグループ内で最も深刻なノードのステータスを使用する。

NNMiで使用するパーセンテージの計算結果を指定する。

メモ

［ステータスの設定］はグローバル設定です。NNMiは，デフォルトでノードグループ内の最も深刻なノードのステータスを使用します。

［設定］ワークスペースに移動する。

［ステータスの設定］を選択する。

［ステータスの設定］フォームを調べ，デフォルトのパーセンテージを把握する。

パーセンテージを使用するには，［最も重大なステータスを伝達］チェックボックスをオフにしてから，変更を保存する必要があります。

(4)　手順4：ノードグループマップの順序を設定する

ノードグループマップの順序は，［トポロジマップ］ワークスペースに表示されるマップの順序を決めるのに役立ちます。この例では，ノードグループマップの順序を使用して，［トポロジマップ］ワークスペースのリストの最初にMy Networkノードグループマップが表示されるよう指定します。

［設定］ワークスペースに移動する。

［ユーザーインタフェース］から［ノードグループマップの設定］を選択する。

メモ

次の例では，デフォルトの［トポロジマップ順序］の値は，すべてのユーザー定義マップで50です。

My Networkを［トポロジマップ］ワークスペースの最初のマップとして一覧に表示するようNNMiに指示するには，［トポロジマップ順序］の値をほかのどのマップの［トポロジマップ順序］の値よりも小さい数字（例えば5）にします。

My Networkノードグループマップを開く。

［トポロジマップ順序］属性で，値を5に変更する。

［保存して閉じる］をクリックして変更を保存し，フォームを閉じる。

マップを最初にNNMiコンソールに表示するかどうかも指定できます。それには，［設定］ワークスペースで［ユーザーインタフェースの設定］オプションを使用します。

［設定］ワークスペースに移動する。

［ユーザーインタフェース］から［ユーザーインタフェースの設定］をクリックする。

［初期ビュー］属性で，ドロップダウンメニューを使用して［クイックアクセスマップフォルダの最初のノードグループ］ワークスペースを選択する。

これによって，My Networkマップが初期ビューに表示されます。

初期ビューを確認するには，NNMiからサインアウトしてからもう一度サインインします。My NetworkマップがNNMiコンソールに表示されるビューになります。

(5)　手順5：ノードグループマップに背景イメージを追加する

マップに背景グラフィックを含めるには，選択したノードグループマップで［ノードグループマップの設定］を使用します。

まず，事前準備として，背景イメージファイル（例：user.png）を以下に配置します。

Windowsの場合：%NnmDataDir%shared¥nnm¥www¥htdocs¥images

Linuxの場合：$NnmDataDir/shared/nnm/www/htdocs/images

［設定］ワークスペースに移動する。

［ユーザーインタフェース］をクリックする。

［ノードグループマップの設定］をクリックする。

My Networkノードグループマップを開く。

［背景イメージ］タブに移動する。

［http://MACHINE:PORT/nnmdocs/images/］をクリックする。

NNMiに，グラフィックの一覧が表示されます。

［user.png］を右クリックする。

リンクの場所をコピーする。

ディレクトリのリストウィンドウを閉じる。

メモ

コピーしたリンクの「/nnmdocs/images/ファイル名」の部分（/nnmdocs/images/user.png）を［背景イメージ］属性に貼り付けます。

あとで変更する場合のために，［背景イメージのスケール］の値をメモします。

［保存して閉じる］をクリックして変更を保存する。

［トポロジマップ］ワークスペースの［クイックアクセスマップ］に移動し，［My Network］を選択して，新しいマップを背景グラフィックと一緒に表示する。

9.1.3　ノードグループを削除する

作成したColoradoノードグループを削除します。

［設定］ワークスペースに移動する。

［オブジェクトグループ］から［ノードグループ］をクリックする。

リストでColoradoノードグループを選択し，［開く］ボタンをクリックする。

Coloradoノードグループに移動してColoradoノードグループの内容が表示されます。

［ノードグループを削除］ボタンをクリックする。

ダイアログボックスが表示されます。ノードグループを削除するとノードグループに含まれるすべてのオブジェクトと参照も削除されることが警告されます。

［OK］をクリックしてノードグループを削除する。

9.2　ネットワークの概要マップに表示されるノードの最大数を削減する

［ネットワークの概要］マップには，レイヤー3ネットワークで最も高度に接続された250までのノードを含むマップが表示されます。このマップに含まれるノード数が多過ぎると，ノードを移動するときのマップの反応が遅くなったり，複雑過ぎて実際の表示に適さなくなったりするおそれがあります。［ネットワークの概要］マップに表示されるノードの最大数は次の例のように増減できます。

（例）：［ネットワークの概要］マップに表示されるノードの最大数を250から100に変更する。

次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-ui.properties

Linux：$NNM_PROPS/nms-ui.properties

次の行を探す。

#!com.hp.nnm.ui.networkOverviewMaxNodes=250

表示されるノードの最大値を次のように指定します。

com.hp.nnm.ui.networkOverviewMaxNodes=100

重要

行の先頭の「#!」を忘れずに削除してください。

変更を保存する。

次のコマンドを実行してNNMiを再起動する。

ovstop
ovstart

9.3　ノードグループマップに表示されるノードの最大数を削減する

数百単位のノードを含むようにノードグループマップを設定すると，ノードグループを表示するマップには，予期される詳細なノードアイコンではなく，多くの小さいノードアイコンが表示されます。より詳細なマップを表示するには，ズーム機能を使用する必要があります。ズーム機能を使用すると，マップを表示するときのNNMiコンソールのパフォーマンスが低下するおそれがあります。

次の手順を実行して，表示されるノードまたは表示されるエンドポイント，またはその両方の数を制限してください。

NNMiコンソールで，［設定］をクリックする。

［ユーザーインタフェース］の下にある［ユーザーインタフェースの設定］をクリックする。

［デフォルトのマップ設定］タブを選択する。

［表示するノードの最大数］フィールドに表示された値を変更する。

［表示するエンドポイントの最大数］フィールドに表示された値を変更する。

［保存して閉じる］をクリックする。

詳細は，NNMiヘルプの「デフォルトマップ設定を定義する」を参照してください。

9.4　分析ペインのゲージの設定

分析ペインの［ゲージ］タブには， State Poller とカスタムポーラーの SNMP データを示すために，リアルタイムの SNMP ゲージが表示されます。これらのゲージには，ノード，インタフェース，カスタムノード収集のデータや，CPU ，メモリ，バッファー，バックプレーンタイプのノードコンポーネントのデータが表示されます。

次のプロパティファイルを編集してゲージを設定できます。

Windowsの場合：%NNM_PROPS%¥nms-ui.properties

Linuxの場合：$NNM_PROPS/nms-ui.properties

設定する各プロパティで，行の始めにコメント文字（#!）が存在する場合は削除します。

メモ

後続の項で説明するプロパティはすべてのノードに適用されます（個別のノードグループにプロパティを適用することはできません）。

ヒント

変更を行う前にnms-ui.propertiesファイルのバックアップコピーを作成します。バックアップコピーは，編集するプロパティファイルが格納されているディレクトリに配置しないでください。

詳細については，nms-ui.propertiesファイル内のコメントも参照してください。

9.4.1　分析ペインを無効にする

NNMi コンソールからアナリシス（分析）ペインを無効にするには，次の手順で実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-ui.properties

Linux：$NNM_PROPS/nms-ui.properties

次のプロパティが含まれる行を探す。

#!com.hp.nnm.ui.analysisPaneDisabled = true

次のように行の先頭の「#! 」を削除して，アナリシス（分析）ペインを無効にします。

com.hp.nnm.ui.analysisPaneDisabled = true

変更を保存する。

次のコマンドを実行して NNMi を再起動する。

ovstop
ovstart

9.4.2　表示されるゲージ数の制限

次の行を編集して目的の値を入力し，表示するゲージの最大数を設定します。

com.hp.nnm.ui.maxGaugePerAnalysisPanel =

ヒント

ゲージ数が多いほど，分析ペインの表示時のパフォーマンスに影響します。ゲージ数が少ないほどゲージのサイズが大きくなります。

9.4.3　分析ペインにあるゲージの更新間隔の設定

次のプロパティ値を編集して，分析ペインに表示されるゲージの更新間隔（秒）を設定します。

com.hp.nnm.ui.analysisGaugeRefreshSecs =

ヒント

値を「0」に設定すると，ゲージが更新されなくなります。更新間隔を10秒より速くすると，一部のSNMPエージェントでは短時間で値がキャッシュされ，結果が同じになります。

9.4.4　ゲージの非表示

次の行を編集し，非表示にするゲージのリストを入力して，（すべてのゲージビューの）表示しないゲージを定義します。

com.hp.nnm.ui.analysisGaugeNoDisplayKeyPatterns =

次の点に注意してください。

関連するすべての行からコメント文字を削除してください。

ゲージのリスト内にコメントを含めることはできません。

ゲージのリスト内に空白行を含めないようにします。

空白行がある場所でエントリが終了します。

コメント内の設定がこのプロパティのデフォルト設定です。

この設定を拡張または修正する場合，これらの設定を含める必要があります。含めないと，予期しない数のゲージが表示されます。

9.4.5　表示されるノードゲージの順序の制御

ノードゲージが表示される順序を制御するには，次の行を編集します。

com.hp.nnm.ui.analysisGaugeNodeComponentKeys =

次の点に注意してください。

このプロパティ設定では，ワイルドカードはサポートされていません。

リストにコメントまたは空白行が含まれていないことを確認してください。

このプロパティのデフォルト設定がコメントとして表示されます。この設定を拡張または修正する場合，これらの設定を含める必要があります。含めないと，設定した順序で表示されません。

9.4.6　表示されるインタフェースゲージの順序の制御

インタフェースゲージが表示される順序を制御するには，次の行を編集します。

com.hp.nnm.ui.analysisGaugeInterfaceKeys =

次の点に注意してください。

このプロパティ設定では，ワイルドカードはサポートされていません。

リストにコメントまたは空白行が含まれていないことを確認してください。

コメント内の設定がこのプロパティのデフォルト設定です。この設定を拡張または修正する場合，これらの設定を含める必要があります。含めないと，意図した順序で表示されません。

9.4.7　表示されるカスタムポーラーゲージの順序の制御

カスタムポーラーゲージが表示される順序を制御するには，次の行を編集します。

com.hp.ov.nnm.ui.analysisGaugeCustomPolledInstanceKeys =

メモ

この属性にデフォルト設定はありません。

9.4.8　ゲージプロパティの適用方法の理解

ゲージプロパティは次の順序で適用されます。

すべてのゲージのリストがState Pollerから取得されます。

analysisGaugeNoDisplayKeyPatternsが最初に適用されて，指定のゲージがリストから削除されます。

analysisGaugeNodeComponentKeys，analysisGaugeInterfaceKeys，またはanalysisGaugeCustomPolledInstanceKeysが必要に応じて適用され，表示されるゲージのリストの順序が決まります。

最後に，maxGaugePerAnalysisPanelが適用されて，表示されるリストが切り捨てられます。

9.4.9　ゲージに関する問題のトラブルシューティング

このセクションでは，ゲージに関する次の問題のトラブルシューティングについて説明します。

「(1)　表示されるゲージが多すぎる」

(1)　表示されるゲージが多すぎる

ゲージが多すぎる場合は，次のどちらかを実行します。

maxGaugePerAnalysisPanelプロパティを使用して，表示されるゲージ数を制限します。

詳細については，「9.4.2　表示されるゲージ数の制限」を参照してください。

analysisGaugeNoDisplayKeyPatternsプロパティを使用して，不要なゲージを削除します。

詳細については，「9.4.4　ゲージの非表示」を参照してください。

9.5　マップラベルのスケールサイズと境界の設定

NNMi 管理者は，nms-ui.propertiesファイルを使用してマップビューに次の調整を加えることができます。

マップとしてのノードラベルおよびポートラベルのスケール値は，ズーム機能によってサイズ変更される。

マップ上でのノードまたはポートとそれらのラベル間のサイズ差を決定するために使用できる最大相対スケール係数。

ノードとポートのラベルが黒い枠で囲まれるかどうか。

メモ

デフォルトでは，ラベルが重なるときに読みやすいように，ノードとポートのラベルは黒い枠で囲まれます。

次の表に変更するプロパティを示します。

ヒント

各スケール調整プロパティ値は，NNMiで使用される実際のスケール係数を掛けたものです。例えば，labelScaleAdjust値を0.50に変更すると，マップ上に表示されるラベルはその通常のサイズの半分になります。

表9‒1　nms-ui.propertiesファイルで変更するプロパティ

プロパティ

デフォルト値

説明

com.hp.nnm.ui.labelScaleAdjust

1.0

ノードとポートのマップラベルのスケールサイズを調整します。

com.hp.nnm.ui.omitLabelRectangle

false

ノードラベルとポートラベルを囲むために黒い枠を使用するかどうかを決定します。

注：枠を表示しない場合，この値をtrueに設定します。

メモ

変更を適用するには，マップビューを開き直すか，または変更します。

9.6　Loom 図および Wheel 図の自動折りたたみしきい値の設定

NNMi 管理者は，Loom 図と Wheel 図が相当複雑になったときに読みやすくするために，これらの図が初期動作として自動的にノードの折りたたみ（インタフェースの非表示）とスイッチの折りたたみ（ポートの非表示）を行うポイントを設定できます。この設定は，nms-ui.propertiesファイルの次のプロパティを調整して行います。

表9‒2　Loom およびWheel の自動折りたたみしきい値

プロパティ

説明

com.hp.nnm.ui.wheelAutoCollapseThreshold

このプロパティは，Wheel図の自動的な折りたたみが開始されるまでに境界線の周囲に必要なラベル数を指定するために使用します。

com.hp.nnm.ui.loomAutoCollapseThreshold

このプロパティは，Loom図の自動的な折りたたみが開始されるまでに図全体で必要なラベル数を指定するために使用します。

自動折りたたみしきい値を設定するには，次の手順を実行します。

次のファイルを編集します。

Windowsの場合：%NNM_PROPS¥nms-ui.properties

Linuxの場合：$NNM_PROPS/nms-ui.properties

必要に応じて，必要なプロパティをコメント解除します。詳細については， nms-ui.propertiesファイル内のコメントを参照してください。

必要に応じてしきい値を更新し，変更を保存します。

変更を適用するには，NNMiコンソールで図を開き直します。

9.7　デバイスのプロファイルアイコンをカスタマイズする

NNMiでは，デバイスのプロファイルまたは特定のノードに関連づけられているアイコンをカスタマイズできます。これらのアイコンはテーブルビューやメニュー項目に表示されます。また，NNMiトポロジマップの前景イメージとしても表示されます。

［設定］ワークスペースの［ユーザーインタフェース］フォルダにある［アイコン］オプションからアイコンを変更できます。

また，コマンドラインを使ってアイコンを変更または削除するには，nnmicons.ovplコマンドを使用してください。詳細については，nnmicons.ovplリファレンスページ，またはNNMiヘルプを参照してください。

9.8　テーブルビューのリフレッシュレートをオーバーライドする

NNMiでは，NNMi管理者がNNMiコンソールにあるテーブルビューのデフォルトのリフレッシュレートをオーバーライドできます。

推奨される最小リフレッシュレートは，30秒です。リフレッシュレートを30秒未満に設定すると，パフォーマンスが低下することがあります。

NNMiテーブルビューのデフォルトのリフレッシュレートをオーバーライドするには，次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-ui.properties

Linux：$NNM_PROPS/nms-ui.properties

リフレッシュレートを変更するビューのURL内のviewInfoIdパラメーターを特定する。

a　リフレッシュレートを変更するビューを開きます。

b　［新しいウィンドウでビューを表示］をクリックします。

c　URL内のviewInfoIdパラメーターをメモします。

（例）

viewInfoId=allIncidentsTableView

次の形式を使用して，ビューとそのリフレッシュレートを秒数で指定する行をnms-ui.propertiesに追加する。

com.hp.ov.nms.ui.refreshViewSecs.VIEWKEYWORD = SECS

重要

VIEWKEYWORDは，ビューのURL内のviewInfoIdパラメーターです。

SECSは，リフレッシュレート（秒数）です。

コマンドラインの末尾に余分なスペースがないことを確認してください。

例えば，［すべてのインシデント］ビューのリフレッシュレートを120秒に変更するには，nms-ui.propertiesに下記の行を追加します。

com.hp.ov.nms.ui.refreshViewSecs.allIncidentsTableView = 120

変更を保存する。

新しいリフレッシュレートを確認するには，別のビューを開いてから，リフレッシュレートを変更したビューに戻る。

第4編　詳細設定編

10　NNMiでの証明書の使用

証明書は，Webサーバーの識別情報をブラウザに示すものです。この証明書には，自己署名するかCA（認証機関）による署名を付けることができます。nnm-key.p12ファイルでは，プライベートキーと証明書は対応するパブリックキーとともに格納されます。nnm-trust.p12ファイルには，通信する他者の証明書，または他者を識別するときに信頼する認証機関の証明書が保存されています。NNMiは，nnm-key.p12ファイルとnnm-trust.p12ファイルの両方に自己署名証明書を含めます。特定のNNMi機能を使用するため，NNMi管理サーバーはそれぞれの証明書を相互に共有する必要があります。この章では，NNMi管理サーバー間でこれらの証明書をコピーする方法と，nnmcertmerge.ovplスクリプトを使用してnnm-key.p12ファイルおよびnnm-trust.p12ファイルに証明書をマージする方法について説明します。

10.1　NNMi 証明書について

注意

NNMi 11-50以降のバージョンでは，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50以降の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイルベースの証明書管理方法を利用できます。以前のバージョンのNNMiからアップグレードした環境では，引き続きJKSリポジトリが証明書の格納に使用されます。

アップグレードした環境で，PKCS #12リポジトリに移行するには，「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従います。

証明書を使用する上で参考となる用語について説明します。

表10‒1　証明書関連の用語

コンセプト

説明

キーストアーとトラストストアー

トラストストアー：NNMiトラストストアーは，NNMiが信頼するソースから取得した公開キーを格納するファイルです。

新たにNNMi 11-50以降のバージョンをインストールした環境では，トラストストアーファイルの名前はnnm-trust.p12です。

注意

NNMiが旧バージョンからバージョン11-50以降にアップグレードされた管理サーバーでは，トラストストアーファイルの名前はnnm.truststoreです。ただし，追加の手順（「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」に記載）を実行してnnm.truststoreファイルをnnm-trust.p12ファイルに移行できます。

キーストアー：NNMiキーストアーは，NNMiサーバーのプライベートキーをインポートするファイルです。

新たにNNMi 11-50以降のバージョンをインストールした環境では，キーストアーファイルの名前はnnm-key.p12です。

注意

NNMiが旧バージョンからバージョン11-50以降にアップグレードされた管理サーバーでは，キーストアーファイルの名前はnnm.keystoreです。ただし，追加の手順（「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」に記載）を実行してnnm.keystoreファイルをnnm-key.p12ファイルに移行できます。

これらのファイルは，次の場所に格納されています。

Windowsの場合：%NNM_DATA%¥shared¥nnm¥certificates¥

Linuxの場合：$NNM_DATA/shared/nnm/certificates/

デフォルトの NNMi 証明書

NNMi は，デフォルトのプロパティを使用して生成される自己署名証明書とともにインストールされます。このデフォルトの証明書は，別の自己署名証明書または CA 署名の証明書に置き換えることができます。

ツール

（Java の Keytool ユーティリティを使用する）nnmkeytool.ovplユーティリティを使用して証明書を生成および管理します。 NNMi には，証明書をマージして NNMi システムでの信頼性を確立する nnmmergecert.ovpl ユーティリティも付属しています。このプログラムは，高可用性，フェイルオーバー，およびグローバルネットワーク環境のセットアップで使用します。

サポートされる暗号化アルゴリズム

NNMi は， RSA アルゴリズムを使用して生成された証明書を受け入れます。 DSA アルゴリズムはサポートされません。

自己署名証明書

自己署名証明書は，一般にサーバーと既知のクライアントグループ間にセキュア通信を確立するために使用します。 NNMi は，デフォルトのプロパティを使用して生成される自己署名証明書とともにインストールされます。

注：自己署名証明書を使用するように設定されている NNMi インスタンスは，ユーザーが Web ブラウザーで NNMi Web コンソールへのアクセスを試みると警告メッセージを表示します。

CA 署名証明書

証明書署名要求に対する応答として受け取る署名付きサーバー証明書には， CA 署名付きの NNMi 証明書と，1 つ以上の CA 証明書が含まれます（1 つ以上の CA 証明書が存在する場合は証明書チェーンとも呼びます）。

注：これらの証明書は1つのファイルに入っていることもあれば，2つの別々のファイルに入っていることもあります。

ルート署名証明書

サーバーおよびユーザーの証明書の署名について信頼できる認証機関を示します。

中間 CA 証明書

サーバーまたはユーザーではなく，ルート CA または中間 CA（それ自体が署名機関）のどちらかで署名される証明書です。

注：中間 CA 証明書を含め，NNMi サーバー証明書からルート CA 証明書までの証明書のリストは，証明書チェーンと呼ばれます。

10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定

NNMi 11-50より前のバージョンでは，NNMiは証明書を保存するためにJava KeyStore (JKS) リポジトリを提供していました。NNMi 11-50以降のバージョンでは，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50以降の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイルベースの証明書管理方法を利用できます。

ただし，古いバージョンのNNMiをバージョン11-50以降にアップグレードした場合，PKCS #12ファイルベースの証明書管理はすぐには利用できず，NNMiでは証明書管理にJKSリポジトリが引き続き使用されます。

追加的な設定作業により，アップグレードされたNNMi管理サーバーを設定して，PKCS #12ファイルベースの証明書管理の新しい方法が使用されるようにすることができます。

アップグレードされたNNMi管理サーバーを設定して，PKCS #12ファイルベースの証明書管理が使用されるようにするには，次の手順を実行します。

ルートまたは管理者としてNNMi管理サーバーにログオンします。

次のコマンドを実行して，新しいキーストアーファイルに移行します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -importkeystore -srckeystore
%NnmDataDir%shared¥nnm¥certificates¥nnm.keystore -destkeystore
%NnmDataDir%shared¥nnm¥certificates¥nnm-key.p12 -srcstoretype JKS -deststoretype PKCS12 -srcprovidername SUN -destprovidername SunJSSE -alias <src_alias>

Linuxの場合：

/opt/OV/bin/nnmkeytool.ovpl -importkeystore -srckeystore
/var/opt/OV/shared/nnm/certificates/nnm.keystore -destkeystore
/var/opt/OV/shared/nnm/certificates/nnm-key.p12 -srcstoretype JKS -deststoretype PKCS12 -srcprovidername SUN -destprovidername SunJSSE -alias <src_alias>

注意

コマンド実行後，「出力先キーストアのパスワードを入力してください」，「新規パスワードを再入力してください」，および「ソース・キーストアのパスワードを入力してください」と3回パスワードの入力を求められますので，すべてにnnmkeypassと入力してください。

この新しい証明書管理の方法では，キーストアーに同時に複数の証明書を保持することはできません。このインスタンスで，<src_alias>は，移行したい以前のキーストアーファイルに含まれている証明書のエイリアスです。

以前のキーストアーファイルに含まれている証明書エイリアスについては，次のファイルに設定されているcom.hp.ov.nms.ssl.KEY_ALIASの設定値を指定してください。

Windowsの場合：%NNM_CONF%¥nnm¥props¥nms-local.properties

Linuxの場合：$NNM_CONF/nnm/props/nms-local.properties

メモ

アプリケーションフェイルオーバー構成のNNMi管理サーバーの場合は，<src_alias>にコマンドを実行するサーバーの証明書のエイリアスを指定してください。

次のコマンドを実行して，新しいトラストストアーファイルに移行します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -importkeystore -srckeystore
%NnmDataDir%shared¥nnm¥certificates¥nnm.truststore -destkeystore
%NnmDataDir%shared¥nnm¥certificates¥nnm-trust.p12 -srcstoretype JKS -deststoretype PKCS12 -srcprovidername SUN -destprovidername SunJSSE

Linuxの場合：

/opt/OV/bin/nnmkeytool.ovpl -importkeystore -srckeystore
/var/opt/OV/shared/nnm/certificates/nnm.truststore -destkeystore
/var/opt/OV/shared/nnm/certificates/nnm-trust.p12 -srcstoretype JKS -deststoretype PKCS12 -srcprovidername SUN -destprovidername SunJSSE

注意

コマンド実行後，「出力先キーストアのパスワードを入力してください」，「新規パスワードを再入力してください」，および「ソース・キーストアのパスワードを入力してください」と3回パスワードの入力を求められますので，すべてにovpassと入力してください。

次の場所にあるserver.propertiesファイルをテキストエディタで開きます。

Windowsの場合：%NnmDataDir%nmsas¥nms

Linuxの場合：/var/opt/OV/nmsas/nms

HA 環境の場合，「19.5.1　NNMiの共有ディスク内のデータ」も参照してください。

ファイルの現在の内容を削除します。

ファイルに次の内容を追加します。

nmsas.server.security.keystore.type=PKCS12
nmsas.server.security.keystore.file=${com.hp.ov.DataDir}/shared/nnm/certificates/nnm-key.p12
nmsas.server.security.keystore.cred=nnmkeypass
nmsas.server.security.truststore.file=${com.hp.ov.DataDir}/shared/nnm/certificates/nnm-trust.p12
nmsas.server.security.truststore.cred=ovpass
nmsas.server.security.keystore.alias=
nms.comm.soap.https.PROTOCOLS=TLSv1.2

ファイルを保存します。

次の場所にあるnms-local.propertiesファイルをテキストエディタで開きます。

Windowsの場合：%NnmDataDir%conf¥nnm¥props

Linuxの場合：/var/opt/OV/conf/nnm/props

すべてのjavaxパラメーターの値を変更します。

パラメーター

値

javax.net.ssl.trustStore

${NnmDataDir}/shared/nnm/certificates/nnm-trust.p12

javax.net.ssl.trustStoreType

PKCS12

javax.net.ssl.keyStore

${NnmDataDir}/shared/nnm/certificates/nnm-key.p12

javax.net.ssl.keyStoreType

PKCS12

ファイルを保存します。

nnm.keystoreファイルおよびnnm.truststoreファイルを次のディレクトリから削除します。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：/var/opt/OV/shared/nnm/certificates

NNMiを再起動します。

10.3　PKCS #12リポジトリを使った証明書の使用

NNMi 11-50より前のバージョンでは，NNMiは証明書を保存するためにJava KeyStore (JKS) リポジトリを提供していました。NNMi 11-50以降のバージョンでは，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50以降の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイルベースの証明書管理方法を利用できます。

ただし，古いバージョンのNNMiをバージョン11-50以降にアップグレードした場合，PKCS #12ファイルベースの証明書管理はすぐには利用できず，NNMiでは証明書管理にJKSリポジトリが引き続き使用されます。

このセクションでは，新しくインストールしたNNMi（または証明書リポジトリがPKCS #12形式に移行された環境）で証明書を操作する手順を説明します。

メモ

NNMi 13-00以降のバージョンを新規インストールした場合，NNMiの自己署名証明書に，Subject Alternative Name (SAN) が付与されます。

NNMi 12-60以前のバージョンからアップグレードした環境では，NNMiの自己署名証明書にSANが付与されません。NNMiの自己署名証明書を使用してNNMiにSSL通信している環境で，SANが付与された自己署名証明書への入れ替えが必要な場合は，この製品のリリースノートを参照してください。

また，Microsoft EdgeやGoogle Chromeなどの一部のブラウザで，証明書の認証にSANを使用する場合があります。CA署名証明書を使用する場合は，必要に応じてCA署名機関にSANが付加された証明書を発行するように依頼してください。

10.3.1　自己署名証明書の生成

注意

NNMi 11-50以降のバージョンでは，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50以降の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイル ベースの証明書管理方法を利用できます。以前のバージョンのNNMiからアップグレードした環境では，引き続きJKSリポジトリが証明書の格納に使用されます。

アップグレードした環境で，PKCS #12リポジトリに移行するには，「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従います。

自己署名証明書を生成するには，次の手順を実行します。

nnm-key.p12ファイルおよびnnm-trust.p12ファイルが存在する NNMi 管理サーバーのディレクトリに変更します。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：$NnmDataDir/shared/nnm/certificates

nnm-key.p12ファイルのバックアップコピーを保存します。

既存のnnm-key.p12ファイルを削除します。

システムからプライベートキーを生成します。

このプライベートキーを生成するには，nnmkeytool.ovplコマンドを使用します。

次のコマンドをそのまま実行します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -genkeypair -validity 36500 -keyalg rsa -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -alias <alias_name> -ext SAN=DNS:<FQDN>

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -genkeypair -validity 36500 -keyalg rsa -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -alias <alias_name> -ext SAN=DNS:<FQDN>

メモ

エイリアス（この例では<alias_name>）は，この新規作成キーを識別する名前です。エイリアスには任意の文字列を使用できますが，正しいバージョンを簡単に識別できるように完全修飾ドメイン名（FQDN）に続けてサフィックスを指定することをお勧めします。例えば，myserver.mydomain-<number>やmyserver.mydomain-<date>のようなエイリアス名を使用できます。

また，<FQDN>には，システムのFQDN（ブラウザでNNMiコンソールにアクセスする際に使用するFQDN）を入力してください。

必要な情報を入力します。

メモ

姓名の入力を求められたら，システムのFQDN（ブラウザでNNMiコンソールにアクセスする際に使用するFQDN）を入力してください。

自己署名証明書が生成されます。

CA 署名証明書を取得するためには，さらに CSR ファイルを生成し， CA に送信する必要があります。詳細については，「10.3.2　CA 署名証明書の生成」を参照してください。

10.3.2　CA 署名証明書の生成

注意

NNMi 11-50以降のバージョンでは，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50以降の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイルベースの証明書管理方法を利用できます。以前のバージョンのNNMiからアップグレードした環境では，引き続きJKSリポジトリが証明書の格納に使用されます。

アップグレードした環境で，PKCS #12リポジトリに移行するには，「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従います。

CA 署名証明書を取得してインストールするには，次の手順を実行します。

自己署名証明書を生成します。詳細については，「10.3.1　自己署名証明書の生成」を参照してください。

次のコマンドを実行して，CSR（証明書署名要求）ファイルを作成します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -keystore nnm-key.p12 -certreq -storetype PKCS12 -storepass nnmkeypass -alias <alias_name> -ext SAN=DNS:<FQDN> -file CERTREQFILE

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -keystore nnm-key.p12 -certreq -storetype PKCS12 -storepass nnmkeypass -alias <alias_name> -ext SAN=DNS:<FQDN> -file CERTREQFILE

メモ

上記のコマンドでは，<alias_name>，<FQDN>は証明書の生成時に指定したエイリアス，およびシステムのFQDNです。

CSRファイルの内容を確認するには，次のコマンドを実行します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -printcertreq -file CERTREQFILE -storetype PKCS12

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -printcertreq -file CERTREQFILE -storetype PKCS12

CA 署名機関に CSR を送信します（CA 署名機関が証明書ファイルに署名して返します）。各種の CA 証明書についての詳細は，「(1)　CA 署名証明書のタイプ」を参照してください。

注意

Microsoft EdgeやGoogle ChromeなどのブラウザでJP1/IM3のインテリジェント統合管理基盤のカスタムUI連携を使用する，かつ，コンソール画面への通信にSSLを使用する場合，証明書のSubject Alternative Name (SAN) にシステムのFQDNを設定し，そのFQDNを使用してブラウザにアクセスする必要があります。

そのため，JP1/IM3のインテリジェント統合管理基盤のカスタムUI連携を使用する場合は，CA署名機関へCSRを送信する際にSANが付加された証明書を発行するように依頼し，必ず証明書にSANを付加するようにしてください。

JP1/IM3のインテリジェント統合管理基盤については，「26.1　JP1/IM3のインテリジェント統合管理基盤との連携」を参照してください。

CA署名機関から，次のどちらかが返されます。

単一の署名付きサーバー証明書ファイル（このセクションではmyserver.crtファイル）。サーバー証明書（CA署名NNMi証明書），1つ以上の中間CA証明書，およびルートCA証明書を含む単一のファイル。この単一のファイル内のすべての証明書が証明書チェーンを形成します。

次の一対のファイル。一方が署名付きサーバー証明書ファイル（このセクションではmyserver.crtファイル）で，もう一方（myca.crtファイル）にCA証明書が含まれています。myserver.crtファイルには，1つのサーバー証明書または証明書チェーンが含まれていますが，myca.crtファイル内にあるルートCA証明書は含まれていません。

メモ

CAから返される証明書のフォームがこれと異なる場合は，証明書チェーンおよびルートCA証明書を取得する方法の詳細をCA提供者に問い合わせてください。なお，サポートしている証明書の形式は PEM (Privacy Enhanced Mail) 形式のみです。PEM 形式の証明書を入手してください。

証明書ファイルを用意します。

証明書チェーンをキーストアーファイルにインポートし，ルートCA証明書をトラストストアーファイルにインポートしてください。

手順3.で単一のファイルを受け取った場合

そのファイル内のすべてのルートCA証明書を別のmyca.crtファイルにコピーします。

手順3.で一対のファイルを受け取った場合

myca.crt（ルートCA証明書）ファイルの内容をmyserver.crtファイルの末尾に追加します。また，不要な中間証明書があればそれらをmyca.crtファイルからすべて削除します。これにより，完全な証明書チェーンを含んでいる1つのファイルmyserver.crtファイルと，ルートCA証明書を含んでいる1つのファイルmyca.crtファイルが生成されます。

これらの証明書が記録されているファイルを NNMi 管理サーバーの任意の場所にコピーします。

この例では，次の場所にファイルをコピーします。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：$NnmDataDir/shared/nnm/certificates

キーストアーおよびトラストストアーファイルの存在する NNMi 管理サーバー上のディレクトリに移動します。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：$NnmDataDir/shared/nnm/certificates

次のコマンドを実行して，証明書をキーストアーファイルにインポートします。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -importcert -trustcacerts -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -alias <alias_name> -file <path_to_myserver.crt>

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -importcert -trustcacerts -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -alias <alias_name> -file <path_to_myserver.crt>

メモ

上記のコマンドで，

<path_to_myserver.crt>は，CA署名サーバー証明書を保存した場所への絶対パスです。

<alias_name>は，証明書の生成時に指定したエイリアスです。

証明書の信頼を確認するメッセージが表示されたら，yを入力します。

証明書をキーストアにインポートするときの出力例

このコマンドによる出力形式は次のとおりです。

Owner:CN=NNMi_server.example.com
Issuer:CN=NNMi_server.example.com
Serial number:494440748e5
Valid from:Tue Oct 28 10:16:21 MST 2008 until:Thu Oct 04 11:16:21 MDT 2108
Certificate fingerprints:
MD5:29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02
SHA1:C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03
Trust this certificate?[no]:y
Certificate was added to keystore

次のコマンドを実行して，ルート証明書をトラストストアーファイルにインポートします。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -import -alias <alias_name> -storetype PKCS12 -keystore nnm-trust.p12 -file <path_to_myca.crt> -storepass ovpass

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -import -alias <alias_name> -storetype PKCS12 -keystore nnm-trust.p12 -file <path_to_myca.crt> -storepass ovpass

メモ

上記のコマンドで，

<path_to_myca.crt>は，ルート証明書を保存した場所の絶対パスです。

<alias_name>は，証明書の生成時に指定したエイリアスです。

トラストストアーの内容を確認します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -list -keystore nnm-trust.p12 -storetype PKCS12 -storepass ovpass

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -list -keystore nnm-trust.p12 -storetype PKCS12 -storepass ovpass

トラストストアーの出力例

トラストストアーの出力形式は次のとおりです。

Keystore type: PKCS12
Keystore provider:BCFIPS
Your keystore contains 1 entry
nnmi_ldap, Nov 14, 2008, trustedCertEntry,
Certificate fingerprint (MD5):29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02

ヒント

トラストストアーには複数の証明書を含めることができます。

(1)　CA 署名証明書のタイプ

メモ

CA によって証明書が別のフォームで返される場合は，証明書チェーンとルート CA 証明書を取得する方法について，CA 提供者に問い合わせてください。

認証機関（CA）からは次のどちらかが提供されます。

サーバー証明書（CA によって署名された NNMi 証明書）と 1 つ以上の CA 証明書が含まれる署名付きサーバー証明書ファイル。このセクションでは，署名付きサーバー証明書をmyserver.crtファイルとして示しています。

CA 証明書には，次のどちらかを指定できます。

ルート CA 証明書：サーバーおよびクライアントの証明書の署名について信頼できる機関を示します。

中間 CA 証明書：サーバーまたはユーザーではなく，ルート CA または中間 CA（それ自体が署名機関）のどちらかで署名される証明書。

メモ

中間 CA 証明書を含め， NNMi サーバー証明書からルート CA 証明書までの証明書のリストは，証明書チェーンと呼ばれます。

署名付きサーバー証明書と，1 つ以上の CA 証明書が含まれる別のファイル。このセクションでは，署名付きサーバー証明書をmyserver.crtファイル，CA 証明書をmyca.crtファイルとして示しています。myserver.crtファイルは，1 つのサーバー証明書または証明書チェーンを含んでいる必要がありますが，myca.crtファイル内にあるルート CA 証明書を含んでいる必要はありません。

NNMi に新しい証明書を設定するには，証明書チェーンをnnm-key.p12ファイルにインポートし，ルート CA 証明書をnnm-trust.p12ファイルにインポートする必要があります。サーバー証明書をnnm-key.p12ファイルにインポートする場合はmyserver.crtファイルを使用し，CA 証明書をnnm-trust.p12ファイルにインポートする場合はmyca.crtファイルを使用します。

メモ

CA によって証明書が別のフォームで返される場合は，別個の証明書チェーンとルート CA 証明書を取得する方法について， CA 提供者に問い合わせてください。

完全な証明書チェーンを含んでいる 1 つのファイルで提供された場合，そのファイルからルート CA 証明書フォームをmyca.crtファイルにコピーします。myca.crtファイルを使用してnnm-trust.p12ファイルへインポートすると，NNMi が証明書を発行した CA を信頼するようになります。

2 つのファイルで提供された場合，myca.crtファイルの内容をmyserver.crtファイルの末尾に追加します（ファイルに含まれていない場合）。また，余分な中間証明書がある場合は，それらをmyca.crtファイルからすべて削除します。これにより，次のファイルが生成されます。

myserver.crt（完全な証明書チェーンを含んでいる）

myca.crt（ルート CA 証明書を含んでいる）

メモ

CA だけを使用している場合，一般にルート CA 証明書がnnm-trust.p12ファイルに追加されます。中間 CA またはサーバー証明書を nnm-trust.p12ファイルに追加すると，それらの証明書は明示的に信頼済みとなり，取り消しなどの追加情報についてのチェックはされません。 CA が要求する場合には，追加の証明書だけをnnm-trust.p12ファイルに追加してください。

CA 署名機関から受け取るファイルの例を次に示します。

独立サーバーで，複数の CA 証明書ファイルがある場合

-----BEGIN CERTIFICATE-----
Sample/AVQQKExNQU0EgQ29ycG9yYXRpb24gTHRkMRAwDgYDVQQLEwdOZXR3b3JseGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlw
................................................................
................................................................
TZImiZPyLGQBGRYDaW50MRIwEAYKCZImiZPyLGQBGRYCc2cxEzARBgNVBAMTCmNbpSo6o/76yShtT7Vrlfz+mXjWyEHaIy/QLCpPebYhejHEg4dZgzWWT/lQt==
-----END CERTIFICATE-----

結合サーバーで，1つのファイルに複数のCA証明書がある場合

-----BEGIN CERTIFICATE-----
Sample1/VQQKExNQU0EgQ29ycG9yYXRpb24gTHRkMRAwDgYDVQQLEwdOZXR3b3JseGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlw
................................................................
................................................................
TZImiZPyLGQBGRYDaW50MRIwEAYKCZImiZPyLGQBGRYCc2cxEzARBgNVBAMTCmNbpSo6o/76yShtT7Vrlfz+mXjWyEHaIy/QLCpPebYhejHEg4dZgzWWT/lQt==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Sample2/Gh0dHA6Ly9jb3JwMWRjc2cyLnNnLmludC5wc2FnbG9iYWwuY29tL0NlcRaOCApwwggKYMB0GA1UdDgQWBBSqaWZzCRcpvJWOFPZ/Be9b+QSPyDAfBgNVHSMC
................................................................
................................................................
Wp5Lz1ZJAOu1VHbPVdQnXnlBkx7V65niLoaT90Eqd6laliVlJHj7GBriJ90uvVGuBQagggEChoG9bGRhcDovLy9DTj1jb3JwMWRjc2cyL==
-----END CERTIFICATE-----

10.3.3　NNMi キーストアーからの証明書の削除

NNMi キーストアーに同時に複数の証明書を保持することはできません。NNMi 管理サーバー上の証明書を置換または更新する前に，既存の証明書をNNMi キーストアーから削除してください。

NNMi キーストアーから証明書を削除するには，次の手順を実行します。

nnm-key.p12ファイルおよびnnm-trust.p12ファイルが存在するNNMi 管理サーバーのディレクトリに変更します。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：$NnmDataDir/shared/nnm/certificates

nnm-key.p12ファイルのバックアップコピーを保存します。

キーストアーの内容を確認し，既存の証明書のエイリアスを書き留めます。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -list -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -list -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass

次のコマンドを実行して，キーストアーから既存の証明書を削除します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -delete -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -alias <alias>

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -delete -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -alias <alias>

メモ

エイリアス（この例では<alias>）は，既存の証明書を識別する名前です。

次のコマンドを実行して，NNMi を再起動します。

メモ

NNMi を再起動するまで，変更は反映されません。

Windowsの場合：

%NnmInstallDir%bin¥ovstop -c
%NnmInstallDir%bin¥ovstart -c

Linuxの場合：

$NnmInstallDir/bin/ovstop -c
$NnmInstallDir/bin/ovstart -c

10.3.4　既存の証明書と新規の自己署名証明書またはCA署名証明書との置き換え

自己署名証明書は， NNMi のインストール時に作成され，インストールされます。証明書の置き換えは一般に次の目的で行います。

デフォルトの証明書の代わりに新規の自己署名証明書または CA 署名証明書を使用する。

期限の切れた証明書を更新する。

証明書を置き換えるには，次の手順を実行します。

自己署名証明書を生成します。詳細については，「10.3.1　自己署名証明書の生成」を参照してください。

また，組織でCAの署名した証明書が必要な場合は，CSR（証明書署名要求）ファイルを生成してCA署名証明書を取得します。詳細については，「10.3.2　CA 署名証明書の生成」を参照してください。

次の構文を使用して，NNMi コンソールへの HTTPS アクセスをテストします。

https://<fully_qualified_domain_name>:<port_number>/nnm/.

CA 署名証明書を使用した場合，ブラウザーによって CA が信頼されると， NNMi コンソールへの HTTPS 接続が信頼されます。

自己署名証明書を使用した場合， NNMi コンソールへの信頼性のない HTTPS 接続についての警告メッセージがブラウザーに表示されます。

10.3.5　アプリケーションフェイルオーバー環境での証明書の使用

図10‒1　アプリケーションフェイルオーバーでの証明書の使用法

注意

NNMi 11-50以降のバージョンでは，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50以降の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイルベースの証明書管理方法を利用できます。以前のバージョンのNNMiからアップグレードした環境では，引き続きJKSリポジトリが証明書の格納に使用されます。

アップグレードした環境で，PKCS #12リポジトリに移行するには，「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従います。

アプリケーションフェイルオーバー機能を設定するときには，両方のノードのトラストストアーファイルの内容をマージして，1つのnnm-trust.p12ファイルを作成する必要があります。

次の手順を実行し，自己署名証明書またはCA署名証明書を使用するようにアプリケーションフェイルオーバー機能を設定します。

注意

NNMi およびアプリケーションフェイルオーバー機能で自己署名証明書を使用する場合，次の手順を完了しないと，NNMiのプロセスがスタンバイNNMi管理サーバー（この例のServer Y）で正常に起動しません。

Server Yで次のディレクトリに変更します。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：$NnmDataDir/shared/nnm/certificates

nnm-trust.p12ファイルを，Server YからServer Xの一時保存場所にコピーします。

以降の手順では，これらのファイルの保存場所を<truststore>と呼びます。

Server Xで次のコマンドを実行し，Server YのトラストストアーをServer Xのnnm-trust.p12ファイルにマージします。

nnmcertmerge.ovpl -truststore <truststore>

マージしたnnm-trust.p12ファイルをserver Xからserver Yにコピーし，どちらのノードにもマージ済みファイルがあるようにします。

このファイルの保存場所は，次のとおりです。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：$NnmDataDir/shared/nnm/certificates

Server XとServer Yの両方で次のコマンドを実行します。

完全修飾ドメイン名を含め，両方のサーバーからの表示結果が一致することを確認します。一致しない場合は続行しないで，最初からやり直します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -list -keystore
%NnmDataDir%shared¥nnm¥certificates¥nnm-trust.p12 -storetype PKCS12 -storepass ovpass

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -list -keystore
$NnmDataDir/shared/nnm/certificates/nnm-trust.p12 -storetype PKCS12 -storepass ovpass

「18.　アプリケーションフェイルオーバー構成のNNMiを設定する」から，アプリケーションフェイルオーバー機能の設定を続行します。

10.3.6　高可用性環境での証明書の使用

このセクションでは，HA環境で自己署名証明書またはCA証明書を使用するようにNNMi を設定する方法について説明します。

図10‒2　HAでの証明書の使用法

注意

NNMi 11-50以降のバージョンでは，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50以降の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイルベースの証明書管理方法を利用できます。以前のバージョンのNNMiからアップグレードした環境では，手動でPKCS #12リポジトリに移行する必要があります。

アップグレードした環境で，PKCS #12リポジトリに移行するには，「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従います。

(1)　デフォルト証明書を使用した高可用性の設定

NNMiでHAを正しく有効にするための設定プロセスでは，プライマリクラスタノードとセカンダリクラスタノードの間でデフォルトの自己署名証明書を共有します。HA下で実行されるNNMiでデフォルトの証明書を使用するために，追加の手順を実行する必要はありません。

(2)　新しい証明書を使用した高可用性の設定

このセクションでは，newcertという新規の自己署名証明書またはCA証明書を作成します。次の手順を実行して，この新規のCA証明書または自己署名証明書を使用するようにHAを設定します。

重要

高可用性（HA）でファイルの変更を行うとき，クラスターの両方のノードに変更を加える必要があります。変更によってNNMi管理サーバーを停止して再起動する必要がある場合，ノードをメンテナンスモードにしてからovstopコマンドおよびovstartコマンドを実行する必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

ヒント

この手順は，「19.5　共有NNMiデータ」の説明に従って，NNMi にHAを設定する前または後に実行できます。

NNMi_HA1で次のディレクトリに変更します。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：$NnmDataDir/shared/nnm/certificates

NNMi_HA1で，次のコマンドを実行して，newcertをnnm-key.p12ファイルにインポートします。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -import -alias <newcert_Alias> -storetype PKCS12 -keystore nnm-key.p12 -file newcert -storepass nnmkeypass

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -import -alias <newcert_Alias> -storetype PKCS12 -keystore nnm-key.p12 -file newcert -storepass nnmkeypass

10.3.7　グローバルネットワーク管理環境での証明書の使用

注意

NNMi 11-50以降のバージョンでは，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50以降の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイルベースの証明書管理方法を利用できます。以前のバージョンのNNMiからアップグレードした環境では，引き続きJKSリポジトリが証明書の格納に使用されます。

アップグレードした環境で，PKCS #12リポジトリに移行するには，「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従います。

NNMiのインストール時には，インストールスクリプトによってNNMi管理サーバーの自己署名証明書が作成されます。この証明書には，ノードの完全修飾ドメイン名を含むエイリアスが記録されています。インストールスクリプトは，この自己署名証明書をNNMi管理サーバーのnnm-key.p12ファイルおよびnnm-trust.p12ファイルに追加します。

次の手順を実行し，次の図に基づいて自己署名証明書またはCA署名証明書を使用するようにグローバルネットワーク管理機能を設定します。

開始する前に，必要な証明書がリージョナルマネージャーシステムで作成されていることを確認してください。詳細については，「10.3.4　既存の証明書と新規の自己署名証明書またはCA署名証明書との置き換え」を参照してください。

メモ

新たにインストールしたNNMi 11-50以降のインスタンスと，旧バージョンからバージョン11-50以降にアップグレードしたNNMi管理サーバーを組み合わせて使用する場合は，「バージョン11-50にアップグレードされたNNMi管理サーバー」のガイドラインに従ってください。

図10‒3　グローバルネットワーク管理

regional1およびregional2で次のディレクトリに変更します。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：$NnmDataDir/shared/nnm/certificates

nnm-trust.p12ファイルを，上記のregional1およびregional2の場所から，global1の任意の一時保管場所にコピーします。

global1で次のコマンドを実行し，regional1およびregional2の証明書をglobal1のnnm-trust.p12ファイルにマージします。

nnmcertmerge.ovpl -truststore <regional1_nnm-trust.p12_location>
nnmcertmerge.ovpl -truststore <regional2_nnm-trust.p12_location>

global1で，次のコマンドを実行して，NNMiを再起動します。

ovstop
ovstart

重要

高可用性（HA）でファイルの変更を行う場合は，クラスターの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopコマンドおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

10.3.8　ディレクトリサービスへのSSL接続を設定する

注意

NNMi 11-50以降のバージョンでは，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50以降の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイルベースの証明書管理方法を利用できます。以前のバージョンのNNMiからアップグレードした環境では，引き続きJKSリポジトリが証明書の格納に使用されます。

アップグレードした環境で，PKCS #12リポジトリに移行するには，「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従います。

デフォルトでは，ディレクトリサービス通信を有効にすると，NNMiは，ディレクトリサービスからデータを取得するときにLDAPプロトコルを使用します。ディレクトリサービスでSSL接続が必要な場合は，SSLプロトコルを有効にして，NNMiとディレクトリサービスの間を流れるデータを暗号化する必要があります。

SSLでは，ディレクトリサービスホストとNNMi管理サーバーの間で信頼関係を確立する必要があります。この信頼関係を確立するには，証明書をNNMiトラストストアーに追加します。証明書は，ディレクトリサービスホストの識別情報をNNMi管理サーバーに示すものです。

SSL通信用のトラストストアー証明書をインストールするには，次の手順を実行します。

ディレクトリサーバーから会社のトラストストアー証明書を取得します。

ディレクトリサービス管理者からこの証明書のテキストファイルのコピーを入手できます。

なお，トラストストアー証明書の所有者CNは，ディレクトリサーバーのホスト名と一致している必要があります。

NNMiトラストストアーが格納されているディレクトリに移動します。

Windowsの場合：%NnmDataDir%shared¥nnm¥certificates

Linuxの場合：$NnmDataDir/shared/nnm/certificates

certificatesディレクトリから，この手順のコマンドすべてを実行します。

会社のトラストストアー証明書をNNMiトラストストアーにインポートします。

メモ

LDAPディレクトリサーバーのルートCA証明書（中間証明書なし）をNNMiトラストストアーにインポートします。

複数のLDAPディレクトリサーバーのルートCA証明書をインポートする必要がある場合，2個目以降をインポートする際に，手順中の「nnmi_ldap」を，任意の名称に置き換えてください（例：nnmi_ldap2）。

次のコマンドを実行します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -import -alias nnmi_ldap -storetype PKCS12 -keystore nnm-trust.p12 -storepass ovpass -file <Directory_Server_Certificate.txt>

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -import -alias nnmi_ldap -storetype PKCS12 -keystore nnm-trust.p12 -storepass ovpass -file <Directory_Server_Certificate.txt>

<Directory_Server_Certificate.txt>は，会社のトラストストアー証明書です。

証明書の信頼を確認するメッセージが表示されたら，yと入力します。

証明書をトラストストアーにインポートするときの出力例

このコマンドによる出力形式は次のとおりです。

Owner:CN=NNMi_server.example.com
Issuer:CN=NNMi_server.example.com
Serial number:494440748e5
Valid from:Tue Oct 28 10:16:21 MST 2008 until:Thu Oct 04 11:16:21 MDT 2108
Certificate fingerprints:
MD5:29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02
SHA1:C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03
Trust this certificate?[no]:y
Certificate was added to keystore

トラストストアーの内容を確認します。

Windowsの場合：

%NnmInstallDir%bin¥nnmkeytool.ovpl -list -storetype PKCS12 -keystore nnm-trust.p12 -storepass ovpass

Linuxの場合：

$NnmInstallDir/bin/nnmkeytool.ovpl -list -storetype PKCS12 -keystore nnm-trust.p12 -storepass ovpass

トラストストアーの出力例

トラストストアーの出力形式は次のとおりです。

Keystore type:PKCS12
Keystore provider:SunJSSE
Your keystore contains 1 entry
nnmi_ldap, Nov 14, 2008, trustedCertEntry,
Certificate fingerprint (MD5):29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02

ヒント

トラストストアーには複数の証明書を含めることができます。

次のコマンドを実行して，NNMiを再起動します。

ovstop
ovstart

重要

高可用性（HA）でファイルの変更を行うとき，クラスターの両方のノードに変更を加える必要があります。変更によってNNMi管理サーバーを停止して再起動する必要がある場合，ノードをメンテナンスモードにしてからovstopコマンドおよびovstartコマンドを実行する必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

11　NNMiで使用するTelnetおよびSSHプロトコルの設定

NNMiコンソールを現在実行中のWebブラウザから［アクション］＞［ノードアクセス］＞［Telnet... (クライアントから)］メニュー項目によって，選択したノードに対するtelnetコマンドが呼び出されます。［アクション］＞［ノードアクセス］＞［Secure Shell... (クライアントから)］メニュー項目によって，選択したノードに対するsecure shell（SSH）コマンドが呼び出されます。デフォルトでは，Microsoft Edge，Mozilla FirefoxのいずれでもtelnetコマンドやSSHコマンドは定義されていないため，どちらのメニュー項目を使用する場合でもエラーメッセージが生成されます。システムごとにTelnetプロトコル，SSHプロトコル，または両方のプロトコルを各NNMiユーザーに設定して，NNMiコンソールメニュー項目を変更できます。この章では，NNMiで使用するTelnetおよびSSHプロトコルの設定について説明します。

11.1　TelnetまたはSSHメニュー項目を無効にする

導入環境のNNMiユーザーが，NNMiコンソールからTelnetまたはSSH接続する必要がない場合は，それぞれのメニュー項目を無効化してNNMiコンソールから削除できます。

NNMiコンソールのメニュー項目の無効化は，NNMi管理サーバー上でNNMiコンソールにサインインするすべてのユーザーに適用されます。［Telnet］または［Secure Shell］メニュー項目を無効にするには，次の手順を実行します。

［設定］ワークスペースで［ユーザーインタフェース］を展開して，［メニュー項目］を選択する。

［メニュー項目］ビューで，［Telnet... (クライアントから)］行または［Secure Shell... (クライアントから)］行を選択して，ダブルクリックする。

［メニュー項目］フォームで，［有効にする］チェックボックスをオフにしてから，［作成者］フィールドを適切な値に設定する。

作成者値を変更すると，このメニュー項目はNNMiをアップグレードしても無効化されたままです。

フォームを保存し，閉じる。

詳細については，NNMiヘルプの「NNMiコンソールメニューを制御する」を参照してください。

11.2　Windows上のブラウザにTelnetまたはSSHクライアントを設定する

NNMiユーザーのWebブラウザにオペレーティングシステム提供のtelnetコマンドを設定します。この手順は，［アクション］＞［ノードアクセス］＞［Telnet... (クライアントから)］メニュー項目を実行する必要があるNNMiユーザーの各コンピュータおよびWebブラウザで実行します。

NNMiユーザーのWebブラウザにサードパーティのSSHコマンドを設定します。この手順は，［アクション］＞［ノードアクセス］＞［Secure Shell... (クライアントから)］メニュー項目を実行する必要があるNNMiユーザーの各コンピュータおよびWebブラウザで実行します。

このセクションの手順を完了するには，コンピュータの管理権限が必要です。特定の手順は，ブラウザおよびオペレーティングシステムのバージョン（32ビットまたは64ビット）によって異なります。

Microsoft EdgeはChromium版のみ使用できます。Microsoft EdgeがChromium版であることを確認するには，［設定など］＞［ヘルプとフィードバック］＞［Microsoft Edge について］をクリックします。バージョンの下にテキスト［このブラウザーは、Chromium オープン ソースプロジェクトおよび他のオープンソースソフトウェアに基づいて機能します。］が含まれる場合，このMicrosoft EdgeはChromium版です。

Firefoxは32ビットバージョンでだけ使用できます。

次の表は，各ブラウザとオペレーティングシステムの組み合わせで使用する手順を示したものです。

表11‒1　WindowsでのTelnetおよびSSH設定手順のマトリクス

Webブラウザ

Windowsオペレーティングシステムアーキテクチャ

適用手順

Microsoft Edge

64ビット

「11.2.1　Windowsオペレーティングシステム提供のTelnetクライアント」

「11.2.2　サードパーティTelnetクライアント（標準Windows）」

「11.2.4　サードパーティSSHクライアント（標準WindowsおよびWindows on Windows）」

Firefox

32ビット

「11.2.1　Windowsオペレーティングシステム提供のTelnetクライアント」

「11.2.2　サードパーティTelnetクライアント（標準Windows）」

「11.2.4　サードパーティSSHクライアント（標準WindowsおよびWindows on Windows）」

64ビットWindows 10，Windows 11

「11.2.2　サードパーティTelnetクライアント（標準Windows）」

「11.2.4　サードパーティSSHクライアント（標準WindowsおよびWindows on Windows）」

64ビットWindows 10，Windows 11以外

「11.2.3　サードパーティTelnetクライアント（Windows on Windows）」

「11.2.4　サードパーティSSHクライアント（標準WindowsおよびWindows on Windows）」

このセクションのタスクの多くではWindowsレジストリの編集が必要です。レジストリを直接編集せずにシステム上で各ユーザーが実行できる.regファイルを作成できます。.regファイルの例は，「11.3　Windowsレジストリを変更するファイル例」を参照してください。このセクションで説明するタスクの詳細については，次のMicrosoftの記事を参照してください。

Microsoft提供のTelnetクライアントをインストールする

http://technet.microsoft.com/en-us/library/cc771275%28WS.10%29.aspx

Windowsレジストリの概要

http://support.microsoft.com/kb/256986

Windowsレジストリをバックアップおよびリストアする

http://support.microsoft.com/kb/322756

11.2.1　Windowsオペレーティングシステム提供のTelnetクライアント

この手順は，次の場合に適用されます。

32ビットオペレーティングシステム上の32ビットFirefox

64ビットオペレーティングシステム上の64ビットMicrosoft Edge

Webブラウザで使用するオペレーティングシステム提供のTelnetクライアントを設定するには，次の手順を実行します。

Windows 10，Windows 11，Windows Server 2016，Windows Server 2019，Windows Server 2022，またはWindows Server 2025オペレーティングシステムに該当する手順に従い，コンピュータにオペレーティングシステムTelnetクライアントをインストールする。

Windows 10，またはWindows 11

a　［コントロールパネル］で，［プログラム］をクリックしてから，［プログラムと機能］をクリックします。

b　［タスク］で，［Windowsの機能の有効化または無効化］をクリックします。

c　［Windowsの機能］ダイアログボックスで，［Telnetクライアント］チェックボックスをオンにして，［OK］をクリックします。

Windows Server 2016，Windows Server 2019，Windows Server 2022，またはWindows Server 2025

a　［サーバーマネージャー］の［ダッシュボード］で，［役割と機能の追加］をクリックします。

b　［役割と機能の追加ウィザード］で，［Telnetクライアント］チェックボックスをオンにして，［次へ］，［インストール］の順にクリックします。

URL:Telnetプロトコルファイルタイプのファイル関連づけを設定する。

a　Windowsレジストリをバックアップします。

b　Windowsレジストリエディタを使用して，［HKEY_CLASSES_ROOT¥telnet¥shell¥open¥command］キーを次の値で変更します。

名前

タイプ

データ

（デフォルト）

REG_SZ

rundll32.exe url.dll,TelnetProtocolHandler %l

%l（小文字のL）はTelnetに渡される引数で，通常はノードのIPアドレスまたは完全修飾ドメイン名。

制御を厳しくするには，キーのバイナリへのパスを1行としてコード化できます。

例を次に示します。

"C:¥Windows¥system32¥rundll32.exe"
"C:¥Windows¥system32¥url.dll",TelnetProtocolHandler %l

Webブラウザを再起動してから，ブラウザのアドレスバーにtelnetコマンドを入力する。

telnet://<node>

<node>はTelnetサーバーを実行するノードのIPアドレスまたは完全修飾ドメイン名です。セキュリティ警告が表示される場合は，アクションを許可します。Firefoxで，［今後telnetリンクは同様に処理する］チェックボックスをオンにします。

11.2.2　サードパーティTelnetクライアント（標準Windows）

この手順は，次の場合に適用されます。

32ビットオペレーティングシステム上の32ビットFirefox

64ビットオペレーティングシステム上の64ビットMicrosoft Edge

Webブラウザで使用するサードパーティTelnetクライアントを設定するには，次の手順に従います。

サードパーティTelnetクライアントを取得してインストールする。

この手順では，C:¥Program Files¥PuTTY¥putty.exeにインストールしたPuTTYクライアントを例に挙げます。PuTTYクライアントは，次のWebサイトから使用できます。

http://www.putty.org

URL:Telnetプロトコルファイルタイプのファイル関連づけを設定する。

a　Windowsレジストリをバックアップします。

b　Windowsレジストリエディタを使用して，［HKEY_CLASSES_ROOT¥telnet¥shell¥open¥command］キーを次の値で変更します。

名前

タイプ

データ

（デフォルト）

REG_SZ

"C:¥Program Files¥PuTTY¥putty.exe" %l

%l（小文字のL）はTelnetに渡される引数で，通常はノードのIPアドレスまたは完全修飾ドメイン名。

.regファイルでは，各引用符（"）と円記号（¥）は円記号（¥）でエスケープします。

Webブラウザを再起動してから，ブラウザのアドレスバーにtelnetコマンドを入力する。

telnet://<node>

<node>はTelnetサーバーを実行するノードのIPアドレスまたは完全修飾ドメイン名です。

セキュリティ警告が表示される場合は，アクションを許可します。

Firefoxで，［今後telnetリンクは同様に処理する］チェックボックスをオンにします。

11.2.3　サードパーティTelnetクライアント（Windows on Windows）

この手順は，次の場合に適用されます。

64ビットオペレーティングシステム上の32ビットFirefox

Webブラウザで使用するサードパーティTelnetクライアントを設定するには，次の手順に従います。

サードパーティTelnetクライアントを取得してインストールする。

この手順では，C:¥Program Files¥PuTTY¥putty.exeにインストールしたPuTTYクライアントを例に挙げます。PuTTYクライアントは次のWebサイトから使用できます。

http://www.putty.org

URL:Telnetプロトコルファイルタイプのファイル関連づけを設定する。

a　Windowsレジストリをバックアップします。

b　Windowsレジストリエディタを使用して，［HKEY_CLASSES_ROOT¥Wow6432Node¥telnet¥shell¥open¥command］キーを次の値で変更します。

名前

タイプ

データ

（デフォルト）

REG_SZ

"C:¥Program Files¥PuTTY¥putty.exe" %l

%l（小文字のL）はTelnetに渡される引数で，通常はノードのIPアドレスまたは完全修飾ドメイン名。

.regファイルでは，各引用符（"）と円記号（¥）は円記号（¥）でエスケープします。

Webブラウザを再起動してから，ブラウザのアドレスバーにtelnetコマンドを入力する。

telnet://<node>

<node>はTelnetサーバーを実行するノードのIPアドレスまたは完全修飾ドメイン名です。

セキュリティ警告が表示される場合は，アクションを許可します。

Firefoxで，［今後telnetリンクは同様に処理する］チェックボックスをオンにします。

11.2.4　サードパーティSSHクライアント（標準WindowsおよびWindows on Windows）

この手順は，次の場合に適用されます。

32ビットまたは64ビットオペレーティングシステム上の32ビットFirefox

64ビットオペレーティングシステム上の64ビットMicrosoft Edge

Webブラウザで使用するサードパーティSSHクライアントを設定するには，次の手順を実行します。

サードパーティSSHクライアントを取得してインストールする。

この手順では，C:¥Program Files¥PuTTY¥putty.exeにインストールしたPuTTYクライアントを例に挙げます。

PuTTYは「ssh://<node>」入力を正しく構文解析できないため，この例には入力引数から「ssh://」を取り除くスクリプトが含まれています。スクリプトC:¥Program Files¥PuTTY¥ssh.jsには，次のコマンドが含まれます。

host = WScript.Arguments(0).replace(/ssh:/,"").replace(/¥//g,"");
shell = WScript.CreateObject("WScript.Shell");
shell.Run("¥"c:¥¥Program Files¥¥PuTTY¥¥putty.exe¥" -ssh " + host);

このスクリプトはこの例のために作成されたもので，PuTTYには含まれません。

SSHプロトコルを定義する。

a　Windowsレジストリをバックアップします。

b　Windowsレジストリエディタを使用して，［HKEY_CLASSES_ROOT¥ssh］キーに次の値を追加します。

名前

タイプ

データ

（デフォルト）

REG_SZ

URL:SSH Protocol

EditFlags

REG_DWORD

2

FriendlyTypeName

REG_SZ

SSH

URL Protocol

REG_SZ

値なし

URL:SSHプロトコルファイルタイプのファイル関連づけを設定する。

a　Windowsレジストリをバックアップします。

b　Windowsレジストリエディタを使用して，［HKEY_CLASSES_ROOT¥ssh¥shell¥open¥command］キーを次の値で変更します。

名前

タイプ

データ

（デフォルト）

REG_SZ

"C:¥Windows¥System32¥WScript.exe" "C:¥Program Files¥PuTTY¥ssh.js" %l

%l（小文字のL）は完全ssh引数で，プロトコル指定が含まれます。ssh.jsスクリプトはSSHターゲットをPuTTYに渡します。

.regファイルでは，各引用符（"）と円記号（¥）は円記号（¥）でエスケープします。

Webブラウザを再起動してから，ブラウザのアドレスバーにsshコマンドを入力する。

ssh://<node>

<node>はTelnetサーバーを実行するノードのIPアドレスまたは完全修飾ドメイン名です。

セキュリティ警告が表示される場合は，アクションを許可します。

Firefoxで，［今後sshリンクは同様に処理する］チェックボックスをオンにします。

11.3　Windowsレジストリを変更するファイル例

多くのNNMiユーザーがTelnetまたはSSHプロトコルを使用してNNMiコンソールから管理対象ノードにアクセスする必要がある場合は，Windowsレジストリ更新を1つ以上の.regファイルで自動化できます。このセクションには，独自の.regファイル作成の基準にできる.regファイル例が含まれます。レジストリキーは，アプリケーションとオペレーティングシステムが一致する場合と，64ビットのWindowsバージョンで32ビットのアプリケーションを実行する場合では異なるパスにあります。

詳細については，http://support.microsoft.com/kb/310516のMicrosoftの記事を参照してください。

11.3.1　nnmtelnet.regの例

このレジストリの内容例は，「11.2.1　Windowsオペレーティングシステム提供のTelnetクライアント」に適用されます。

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT¥telnet¥shell¥open¥command]
@="¥"C:¥¥Windows¥¥system32¥¥rundll32.exe¥"
¥"C:¥¥Windows¥¥system32¥¥url.dll¥",TelnetProtocolHandler %l"

11.3.2　nnmputtytelnet.regの例

このレジストリの内容例は，「11.2.2　サードパーティTelnetクライアント（標準Windows）」に適用されます。

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT¥telnet¥shell¥open¥command]
@="¥"C:¥¥Program Files¥¥PuTTY¥¥putty.exe¥" %l"

11.3.3　nnmtelnet32on64.regの例

このレジストリの内容例は，「11.2.3　サードパーティTelnetクライアント（Windows on Windows）」に適用されます。

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT¥Wow6432Node¥telnet¥shell¥open¥command]
@="¥"C:¥¥Program Files¥¥PuTTY¥¥putty.exe¥" %l"

11.3.4　nnmssh.regの例

このレジストリの内容例は，「11.2.4　サードパーティSSHクライアント（標準WindowsおよびWindows on Windows）」に適用されます。

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT¥ssh]
@="URL:ssh Protocol"
"EditFlags"=dword:00000002
"FriendlyTypeName"="Secure Shell"
"URL Protocol"=""

[HKEY_CLASSES_ROOT¥ssh¥shell¥open¥command] @="¥"C:¥¥Windows¥¥System32¥¥WScript.exe¥" ¥"c:¥¥Program Files¥¥PuTTY¥¥ssh.js¥" %l"

12　NNMiとLDAPによるディレクトリサービスの統合

この章では，NNMiとディレクトリサービスを統合することで，ユーザー名，パスワード，および任意でNNMiユーザーグループの割り当ての保存場所を統合する方法について説明します。

12.1　NNMiユーザーのアクセス情報と設定の方法

NNMiユーザーは，次の項目によって定義されます。

ユーザー名は，NNMiユーザーを一意に識別します。ユーザー名によってNNMiへのアクセスが許可され，インシデント割り当てを受け取ることができます。

パスワードは，ユーザー名と関連づけられ，NNMiコンソールまたはNNMiコマンドへのアクセスを制御するために使用されます。

NNMiユーザーグループメンバーシップによって，提供する情報およびNNMiコンソールでユーザーが実行可能なアクションのタイプを制御します。ユーザーグループメンバーシップに従って，ユーザーが使用可能なNNMiコマンドの制御も行われます。

重要

お使いの機器がSNMPv1またはSNMPv2cの場合，次の点にご注意ください。

SNMPv1およびSNMPv2cは，クリアテキストで情報パケットを送ります。

セキュアな環境にするため，お使いの機器から発信されるSNMPトラップや情報の集まりが流れるように，SNMPv3を使用するか，またはファイアウォールコントロールなどの保護を追加してください。

NNMiには，NNMiユーザーアクセス情報の保存先として幾つかの方法が用意されています。

設定の方法ごとにNNMiユーザーアクセス情報を保存するデータベースを，次に示します。

表12‒1　ユーザー情報の保存オプション

モード

ユーザーアカウント

ユーザーグループ

ユーザーグループメンバーシップ

内部（オプション1）

NNMi

NNMi

NNMi

混合（オプション2）

混合（NNMiのアカウント名，LDAPのアカウントのパスワード）

NNMi

NNMi

外部（オプション3）

ディレクトリサービス

両方

ディレクトリサービス

NNMiは，LDAP（Lightweight Directory Access Protocol）を使用してディレクトリサービスと通信します。NNMiでLDAPを使用する場合は，表に示す次のどちらかの方法を使用します。

混合モード（元の名称は「オプション2」）：NNMiユーザー情報の一部をNNMiデータベースに，一部をディレクトリサービスに格納します。

混合モードを使用するには，ユーザー名，ユーザーグループ，およびユーザーグループのマッピングをNNMiデータベースに格納し，ユーザー名とパスワード（ユーザーアカウントの定義）をディレクトリサービスに格納するように設定します。つまり，アカウント名の情報はNNMiとLDAPの両方に格納する必要がありますが，アカウントのパスワードはLDAPだけに格納します。

外部モード（元の名称は「オプション3」）：すべてのNNMiユーザー情報をディレクトリサービスに格納します。

外部モードを使用する場合は，すべてのユーザーアカウント情報がLDAPを使用して格納されますので，NNMiにユーザーアカウント情報を追加する必要はありません。

混合モードを使用して新規ユーザーアカウントを追加するか既存アカウントを修正する場合は，［ディレクトリサービスアカウント］のチェックボックスを選択する必要があります。ユーザーアカウントを設定する際に，内部モード，混合モードおよび外部モードを組み合わせて使用する方法として，一部のユーザーについては［ディレクトリサービスアカウント］を選択し，またほかのユーザーについては選択しないという設定は避けてください。このような設定は，サポート対象外です。

12.1.1　内部モード：NNMiデータベースにすべてのNNMiユーザー情報を保存

NNMiは，すべてのユーザーアクセス情報を取得するためにNNMiデータベースにアクセスします。それらの情報は，NNMi管理者がNNMiコンソールで定義およびメンテナンスします。ユーザーアクセス情報は，NNMiにとってローカルの情報となります。NNMiはディレクトリサービスにアクセスしません。また，NNMiはLDAP設定ファイルから情報を取得するように設定されていません。

この方法での情報フローを次の図に示します。この情報フローは，次のような状況に適しています。

NNMiユーザーの数が少ない。

ディレクトリサービスを使用していない。

図12‒1　内部モードのNNMiユーザーサインインの情報フロー

12.1.2　混合モード：一部のNNMiユーザー情報をNNMiデータベースに，一部のNNMiユーザー情報をディレクトリサービスに保存

NNMiは，ユーザー名とパスワードを取得するためにディレクトリサービスにアクセスします。それらの情報は，NNMiの外部で定義され，ほかのアプリケーションでも使用できます。ユーザーからNNMiユーザーグループへのマッピングは，NNMiコンソールでメンテナンスします。NNMiユーザーアクセス情報の設定およびメンテナンスは，次で説明するように共同で行われます。

ディレクトリサービス管理者は，ディレクトリサービス内のユーザー名とパスワードをメンテナンスします。

NNMi管理者は，（ディレクトリサービスで定義されている）ユーザー名，ユーザーグループ定義，ユーザーグループのマッピングをNNMiコンソールで入力します。

NNMi管理者は，NNMiに対するユーザー名のディレクトリサービスデータベーススキーマを記述するNNMiのLDAP設定ファイルを設定します。

次の図のコマンドラインは，NNMiがNNMiユーザーグループ情報をディレクトリサービスから引き出さないことを示しています。

ユーザー名は，2か所で入力する必要があるため，両方の場所でユーザー名のメンテナンスを行う必要があります。

図12‒2　混合モードのNNMiユーザーサインインの情報フロー

この図では，この方法での情報フローを示しています。この情報フローは，次のような状況に適しています。

NNMiユーザーの数が少なく，ディレクトリサービスを使用できる。

ユーザーグループの変更ごとにディレクトリサービスの変更を必要とするのではなく，NNMi管理者がユーザーグループを管理する。

ディレクトリサービスのグループ定義を使用できる。

ユーザー名とパスワードを保存するディレクトリサービスとの統合に関する詳細については，この章の以降の説明と，NNMiヘルプの「NNMiアクセスを制御するためのLightweight Directory Access Protocol (LDAP)」を参照してください。

12.1.3　外部モード：すべてのNNMiユーザー情報をディレクトリサービスに保存

NNMiは，すべてのユーザーアクセス情報を取得するためにディレクトリサービスにアクセスします。それらの情報は，NNMiの外部で定義され，ほかのアプリケーションが使用できます。1つ以上のディレクトリサービスグループでのメンバーシップで，ユーザーのNNMiユーザーグループが決まります。

NNMiユーザーアクセス情報の設定およびメンテナンスは，次で説明するように共同で行われます。

ディレクトリサービス管理者は，ディレクトリサービス内のユーザー名，パスワード，グループメンバーシップをメンテナンスします。

NNMi管理者は，ディレクトリサービスグループをNNMiユーザーグループにNNMiコンソールでマッピングします。

NNMi管理者は，NNMiに対するユーザー名およびグループのディレクトリサービスデータベーススキーマを記述するNNMiのLDAP設定ファイルを設定します。

次の図に，この方法での情報フローを示します。これは，NNMiにアクセスする必要があるユーザーで構成されるユーザーグループを含めるようにディレクトリサービスを変更できる環境に適しています。

図12‒3　外部モードのNNMiユーザーサインインの情報フロー

この方法は混合モードの例を拡張した形態であるため，次の設定プロセスを推奨します。

ディレクトリサービスからNNMiユーザー名とパスワードを取得するよう設定して検証する。

ディレクトリサービスからNNMiユーザーグループを取得するよう設定する。

すべてのユーザー情報を保存するディレクトリサービスとの統合に関する詳細については，この章の以降の説明と，NNMiヘルプの「NNMiアクセスを制御するためのLightweight Directory Access Protocol (LDAP)」を参照してください。

12.2　ディレクトリサービスへのアクセスを設定する

ディレクトリサービスへのアクセスは，nms-auth-config.xmlファイルで設定できます。

このファイルは，次の場所にあります。

Windowsの場合：%NnmDataDir%nmsas¥NNM¥conf

Linuxの場合：$NnmDataDir/nmsas/NNM/conf

HA 環境の場合，「19.5.1　NNMiの共有ディスク内のデータ」も参照してください。

デフォルトでは，この場所にあるnms-auth-config.xmlファイルにはLDAP設定に必要なXMLエレメントは含まれていません。

必要なすべてのXMLエレメントをこのファイルに手動で追加するには，このセクションの手順に従います。

NNMiによって，参照用のサンプルnms-auth-config.xmlファイルが別の場所に格納されます。

サンプルnms-auth-config.xmlファイルは次の場所にあります。

Windowsの場合：%NnmInstallDir%newconfig¥HPOvNnmAS¥nmsas¥conf

Linuxの場合：$NnmInstallDir/newconfig/HPOvNnmAS/nmsas/conf

ヒント

サンプルnms-auth-config.xmlファイルから<ldapLogin>エレメント全体をコピーし，必要な変更を加えることもできます。

nms-auth-config.xmlファイルの詳細については，「12.6　LDAP設定ファイルリファレンス」を参照してください。

ディレクトリサービスの一般的な構造の詳細については，「12.3　ディレクトリサービスのクエリー」を参照してください。

「混合モード」の設定の場合は，次のタスクを実行します。

12.2.1　タスク1：現在のNNMiユーザー情報をバックアップする

12.2.2　タスク2：（任意）ディレクトリサービスへのセキュア接続を設定する

12.2.3　タスク3：ディレクトリサービスからのユーザーアクセスを設定する

12.2.4　タスク4：ユーザー名とパスワードの設定をテストする

12.2.9　タスク9：クリーンアップしてNNMiの予期せぬアクセスを防止する

12.2.10　タスク10：（任意）ユーザーグループをセキュリティグループにマッピングする

「外部モード」の設定の場合は，次のタスクを実行します。

12.2.1　タスク1：現在のNNMiユーザー情報をバックアップする

12.2.2　タスク2：（任意）ディレクトリサービスへのセキュア接続を設定する

12.2.3　タスク3：ディレクトリサービスからのユーザーアクセスを設定する

12.2.4　タスク4：ユーザー名とパスワードの設定をテストする

12.2.5　タスク5：（「外部モード」の設定だけ）ディレクトリサービスからのグループの取得を設定する

メモ

ディレクトリサービスにNNMiユーザーグループを保存する場合は，NNMiユーザーグループによってディレクトリサービスを設定する必要があります。詳細については，「12.4　NNMiユーザーグループを保存するディレクトリサービスの設定」を参照してください。

12.2.6　タスク6：（「外部モード」の設定だけ）ディレクトリサービスグループをNNMiユーザーグループにマッピングする

12.2.7　タスク7：（「外部モード」の設定だけ）NNMiユーザーグループ設定をテストする

12.2.8　タスク8：（「外部モード」の設定だけ）インシデント割り当てのNNMiユーザーグループを設定する

12.2.9　タスク9：クリーンアップしてNNMiの予期せぬアクセスを防止する

12.2.10　タスク10：（任意）ユーザーグループをセキュリティグループにマッピングする

12.2.1　タスク1：現在のNNMiユーザー情報をバックアップする

NNMiデータベースのユーザー情報をバックアップします。

nnmconfigexport.ovpl -c account -u <user> -p <password> -f NNMi_database_accounts.xml

12.2.2　タスク2：（任意）ディレクトリサービスへのセキュア接続を設定する

ディレクトリサービスでSecure Socket Layer（SSL）を使用する必要がある場合は，「10.3.8　ディレクトリサービスへのSSL接続を設定する」の説明に従って，自社の証明書をNNMiトラストストアーにインポートします。

12.2.3　タスク3：ディレクトリサービスからのユーザーアクセスを設定する

「混合モード」および「外部モード」の場合のみ次のタスクを実行します。ディレクトリサービスに応じた適切な手順に従ってください。

次のディレクトリに移動します。

Windowsの場合：%NnmDataDir%nmsas¥NNM¥conf

Linuxの場合：$NnmDataDir/nmsas/NNM/conf

NNMiに付属するnms-auth-config.xmlファイルをバックアップしてから，そのファイルを任意のテキストエディタで開きます。

次のエレメントの値を指定します。

ヒント

NNMiによって，参照用のサンプルnms-auth-config.xmlファイルが別の場所に格納されます。 サンプルnms-auth-config.xmlファイルは次の場所にあります。

Windowsの場合：%NnmInstallDir%newconfig¥HPOvNnmAS¥nmsas¥conf

Linuxの場合：$NnmInstallDir/newconfig/HPOvNnmAS/nmsas/conf

サンプルnms-auth-config.xmlファイルから<ldapLogin>エレメント全体をコピーし，必要な変更を加えることもできます。

表12‒2　nms-auth-config.xmlファイルのldapLoginセクションのエレメント

<enabled>

</enabled>

trueに設定してnms-auth-config.xmlファイルの使用を指定します。デフォルトでは，falseに設定されています。

<userRoleFilterList>

</userRoleFilterList>

NNMiユーザーがインシデントを割り当てることのできるNNMiロールを指定します。

すべてのオペレータ，管理者，およびゲストにインシデントを 割り当てるには，次を追加します。

<userRoleFilterList>
admin guest level2 level1
</userRoleFilterList>

<connectTimeLimit>

</connectTimeLimit>

接続のタイムアウト値をミリ秒単位で指定します。デフォルト値は10000（10秒）です。NNMiユーザーのサインイン中にタイムアウトになる場合は，この値を増やします。

例：<connectTimeLimit>10000</connectTimeLimit>

<searchTimeLimit>

</searchTimeLimit>

検索のタイムアウト値をミリ秒単位で指定します。デフォルト値は30000（30秒）です。NNMiユーザーのサインイン中にタイムアウトになる場合は，この値を増やします。

例：<searchTimeLimit>30000</searchTimeLimit>

<server>

すべてのLDAP設定情報を含むコンテナエレメント。

<hostname>

</hostname>

LDAPサーバーのURLとポート番号。

例：

HTTPを使用する場合：

ldap://hostname.domain.com:389

HTTPSを使用する場合：

ldaps://hostname.domain.com:636

注：HTTPを使用する場合は，ldap://と指定してください。HTTPSを使用する場合は，ldap://またはldaps://と指定してください。

<secure>

</secure>

HTTPSを使用する場合は，trueに設定します。HTTPSを使用しない場合は，falseに設定します。

</server>

注：serverエレメントは，冗長化されたLDAPサーバー構成で，複数台から同じ情報が取得できる場合，複数指定することができます。その場合，上に書いた接続先から順に接続を試行します。

<bindCredential>

バインド資格証明が含まれているコンテナエレメント（匿名ログオンをサポートしていないディレクトリサービスでは必須）。

<bindDN>

</bindDN>

バインドDNを指定します。

<bindCredential>

</bindCredential>

バインドDNのパスワードを暗号化された形式で指定します。

"nnmldap.ovpl -encrypt <mypassword>"コマンドを実行してパスワードを暗号化します。

</bindCredential>

<users>

すべてのユーザー設定情報が含まれているコンテナエレメント。

<userSearch>

ユーザーを検索するための設定情報が含まれているコンテナエレメント。

<userSearch></userSearch>の設定は1つだけ設定してください。複数設定することはサポートしていません。

<base>

</base>

例：

Active Directoryの場合：

<base> CN={0} </base>

その他のLDAP技術の場合：

<base> SAMAccountName={0} </base>

<baseContextDN>

</baseContextDN>

Active Directoryの場合，ディレクトリサービスのドメインでユーザーレコードを保存する部分を指定します。

例：

Active Directoryの場合：

OU=Users,OU=Accounts,DC=mycompany,DC=com

その他のLDAP技術の場合：

ou=People,o=example.com

</userSearch>

</users>

注：混合モードの場合は，<roleSearch></roleSearch>を次のように1つだけ設定してから，手順4を実行してください。

<roleSearch>
   <roleBase></roleBase>
   <roleContextDN></roleContextDN>
</roleSearch>

nms-auth-config.xmlファイル（%NnmDataDir%nmsas¥NNM¥conf（Windows）または$NnmDataDir/nmsas/NNM/conf（Linux））の編集後，次のコマンドを実行します。

Windowsの場合：

%NnmInstallDir%bin¥nnmldap.ovpl -reload

Linuxの場合：

$NnmInstallDir/bin/nnmldap.ovpl -reload

12.2.4　タスク4：ユーザー名とパスワードの設定をテストする

LDAP設定ファイルで，テスト用にdefaultRoleをguestと設定する。

この値はいつでも変更できます。

nms-auth-config.xmlファイルで，次の内容をusersearchエレメントよりも前に追加します。

<defaultRoles>

<role>guest</role>

</defaultRoles>

LDAP設定ファイルを保存する。

次のコマンドを実行して，NNMiにLDAP設定ファイルを再読み込みさせる。

nnmldap.ovpl -reload

ディレクトリサービスで定義されているユーザー名とパスワードを使用して，NNMiコンソールにサインインする。

このテストは，NNMiデータベースでまだ定義されていないユーザー名を使用して実行してください。

NNMiコンソールのタイトルバーで，ユーザー名とNNMiロール（ゲスト）を確認する。

ユーザーサインインが正しく動作したら，このタスクの手順8.に進みます。

ユーザーサインインが正しく動作しない場合は，次は手順6.に進みます。

各テストのあとで，NNMiコンソールからサインアウトしてセッション資格証明をクリアします。

次のコマンドを実行し，あるユーザーの設定をテストする。

nnmldap.ovpl -diagnose <NNMi_user>

<NNMi_user>は，ディレクトリサービスで定義したNNMiユーザーのサインイン名で置き換えます。

コマンド出力を検討し，適切に応答します。推奨事項は次のとおりです。

「12.2.3　タスク3：ディレクトリサービスからのユーザーアクセスを設定する」が正常に完了したことを確認します。

「12.3.4　ユーザー識別」の詳細な設定プロセスに従います。

メモ

混合モードの場合，次のようなメッセージが出力されますが，混合モードではLDAPグループを参照しないため，動作に問題ありません。次のメッセージは無視してください。

!!!!!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!
!  このユーザー識別名のLDAPグループが見つかりません。
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!
!  LDAPの設定が誤っているようです。詳細は、上記を参照してください。
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

NNMiコンソールへのサインイン時に期待する結果が表示されるまで，手順1.から手順5.を繰り返す。

サインインできたら，設定方法を選択する。

NNMiユーザーグループメンバーシップをNNMiデータベースに保存する（「混合モード」の設定）場合は，「12.2.9　タスク9：クリーンアップしてNNMiの予期せぬアクセスを防止する」に進みます。

NNMiユーザーグループメンバーシップをディレクトリサービスに保存する（「外部モード」の設定）場合は，次はタスク5に進みます。

12.2.5　タスク5：（「外部モード」の設定だけ）ディレクトリサービスからのグループの取得を設定する

このタスクは，「外部モード」の場合に実行します。ディレクトリサービスに応じた適切な手順に従ってください。

次のディレクトリに移動します。

Windowsの場合：%NnmDataDir%nmsas¥NNM¥conf

Linuxの場合：$NnmDataDir/nmsas/NNM/conf

nms-auth-config.xmlファイルのバックアップを作成し，このファイルをテキストエディタで開きます。

次のエレメントの値を指定します。

ヒント

NNMiによって，参照用のサンプルnms-auth-config.xmlファイルが別の場所に格納されます。 サンプルnms-auth-config.xmlファイルは次の場所にあります。

Windowsの場合：%NnmInstallDir%newconfig¥HPOvNnmAS¥nmsas¥conf

Linuxの場合：$NnmInstallDir/newconfig/HPOvNnmAS/nmsas/conf

サンプルnms-auth-config.xmlファイルから<ldapLogin>エレメント全体をコピーし，必要な変更を加えることもできます。

表12‒3　nms-auth-config.xmlファイルのldapLoginセクションのエレメント

<roleSearch>

ユーザーロール情報が含まれているプレースホルダーエレメント。

<roleSearch></roleSearch>の設定は1つだけ設定してください。複数設定することはサポートしていません。

<roleBase>member= {1}

</roleBase>

memberを，ディレクトリサービスドメインのディレクトリサービスユーザーIDを保存するグルー プ属性の名前で置き換えます。

<roleContextDN>

</roleContextDN>

ディレクトリサーバードメインの中でグループレコードを保存する部分を指定します。

形式は，ディレクトリサービスの属性名と値のカンマ区切りリストです。

例：

Active Directoryの場合：

CN=Users,DC=ldapserver,DC=mycompany,DC=com

その他のLDAP技術の場合：

ou=Groups,o=example.com

</roleSearch>

ファイルを保存します。

次のコマンドを実行します。

nnmldap.ovpl -reload

12.2.6　タスク6：（「外部モード」の設定だけ）ディレクトリサービスグループをNNMiユーザーグループにマッピングする

NNMiコンソールで，定義済みのNNMiユーザーグループをディレクトリサービスのユーザーグループにマッピングする。

［ユーザーグループ］ビューを開きます。

［設定］ワークスペースで［セキュリティ］を展開してから［ユーザーグループ］をクリックします。

［admin］行をダブルクリックします。

［ディレクトリサービス名］フィールドに，NNMi管理者のディレクトリサービスグループの完全識別名を入力します。

［保存して閉じる］をクリックします。

guest，level1，level2の行ごとに手順bから手順dを繰り返します。

このマッピングによって，NNMiコンソールにアクセスできるようになります。NNMiコンソールにアクセスするすべてのユーザーは，この手順で指定した，定義済みのNNMiユーザーグループのうちどれかにマッピングされているディレクトリサービスグループに含まれている必要があります。

ディレクトリサービスで1人以上のNNMiユーザーを含むそのほかのグループに，NNMiコンソールで新しいユーザーグループを作成する。

［ユーザーグループ］ビューを開きます。

［設定］ワークスペースで［セキュリティ］を展開してから［ユーザーグループ］をクリックします。

［新規作成］をクリックしてから，グループの情報を入力します。

　−［名前］は一意の値に設定します。短い名前にすることをお勧めします。

　−［表示名］は，ユーザーに表示される値に設定します。

　−［ディレクトリサービス名］は，ディレクトリサービスグループの完全識別名に設定します。

　−［説明］は，このNNMiユーザーグループの目的を説明するテキストに設定します。

［保存して閉じる］をクリックします。

NNMiユーザーのディレクトリサービスグループごとに手順bと手順cを繰り返します。

このマッピングによって，NNMiコンソールのトポロジオブジェクトにアクセスできるようになります。各ディレクトリサービスグループは，複数のNNMiユーザーグループにマッピングできます。

12.2.7　タスク7：（「外部モード」の設定だけ）NNMiユーザーグループ設定をテストする

NNMiのLDAP設定ファイル（nms-auth-config.xmlファイル）を保存する。

次のコマンドを実行して，NNMiにLDAP設定ファイルを再読み込みさせる。

nnmldap.ovpl -reload

ディレクトリサービスで定義されているユーザー名とパスワードを使用して，NNMiコンソールにサインインする。

NNMiデータベースでまだ定義されていないで，admin，level1，level2のNNMiユーザーグループにマッピングされているディレクトリサービスグループのメンバーであるユーザー名で，このテストを実行します。

ユーザー名とNNMiロール（［ユーザーグループ］ビューの［表示名］フィールドで定義したもの）をNNMiコンソールのタイトルバーで，確認する。

ユーザーサインインが正しく動作したら，タスク8に進みます。

ユーザーサインインが正しく動作しない場合は，次は手順5.に進みます。

各テストのあとで，NNMiコンソールからサインアウトしてセッション資格証明をクリアします。

次のコマンドを実行し，ユーザーの設定をテストする。

nnmldap.ovpl -diagnose <NNMi_user>

<NNMi_user>は，ディレクトリサービスで定義したNNMiユーザーのサインイン名で置き換えます。

コマンド出力を検討し，適切に応答します。推奨事項は次のとおりです。

「12.2.5　タスク5：（「外部モード」の設定だけ）ディレクトリサービスからのグループの取得を設定する」が正常に完了したことを確認します。

定義済みのNNMiユーザーグループごとに，「12.2.6　タスク6：（「外部モード」の設定だけ）ディレクトリサービスグループをNNMiユーザーグループにマッピングする」が正常に完了したことを確認します。

「12.3.5　ユーザーグループ識別」の詳細な設定プロセスに従います。

NNMiコンソールへのサインイン時に期待する結果が表示されるまで，手順1.から手順4.を繰り返す。

12.2.8　タスク8：（「外部モード」の設定だけ）インシデント割り当てのNNMiユーザーグループを設定する

ディレクトリサービスで定義されているユーザー名とパスワードを使用して，NNMiコンソールにサインインする。

任意のインシデントビューでインシデントを選択し，［アクション］＞［割り当て］＞［インシデントの割り当て］をクリックする。

userRoleFilterListパラメーターによって指定されている各NNMiロールのユーザーに，インシデントを割り当てることができることを確認します。

12.2.9　タスク9：クリーンアップしてNNMiの予期せぬアクセスを防止する

（任意）LDAP設定ファイルで，defaultRoleパラメーターの値を変更するか，またはコメントにする。

defaultRoleパラメーターの値を変更した，またはコメントにした場合は，次のコマンドを実行して，NNMi にLDAP設定ファイルを再読み込みさせてください。

nnmldap.ovpl -reload

（「混合モード」の設定だけ）NNMiデータベースにユーザーグループメンバーシップを保存するには，次の手順を実行して，NNMiデータベースのユーザーアクセス情報をリセットする。

既存のユーザーアクセス情報すべてを削除します（［ユーザーアカウント］ビューのすべての行を削除します）。

詳細については，NNMiヘルプの「ユーザーアカウントを削除する」を参照してください。

NNMiユーザーごとに，ユーザー名の［ユーザーアカウント］ビューに新しいオブジェクトを作成します。

　−［名前］フィールドに，ディレクトリサービスに定義されているユーザー名を入力します。

　−［ディレクトリサービスアカウント］チェックボックスを選択します。

　−パスワードは指定しないでください。

詳細については，NNMiヘルプの「ユーザーアカウントタスク」を参照してください。

NNMiユーザーごとに，1つ以上のNNMiユーザーグループにユーザーアカウントをマッピングします。

詳細については，NNMiヘルプの「ユーザーアカウントをユーザーグループにマップする ([ユーザーアカウントのマッピング] フォーム)」を参照してください。

インシデント所有権を更新して，各割り当てインシデントが有効なユーザー名と関連づけられるようにします。

詳細については，NNMiヘルプの「インシデント割り当てを管理する」を参照してください。

（「外部モード」の設定だけ）ディレクトリサービスからのユーザーグループメンバーシップを使用するには，次の手順を実行して，NNMiデータベースのユーザーアクセス情報をリセットする。

既存のユーザーアクセス情報すべてを削除します（［ユーザーアカウント］ビューのすべての行を削除します）。

詳細については，NNMiヘルプの「ユーザーアカウントを削除する」を参照してください。

インシデント所有権を更新して，各割り当てインシデントが有効なユーザー名と関連づけられるようにします。

詳細については，NNMiヘルプの「インシデント割り当てを管理する」を参照してください。

12.2.10　タスク10：（任意）ユーザーグループをセキュリティグループにマッピングする

詳細については，NNMiヘルプの「セキュリティグループマッピングタスク」を参照してください。

12.3　ディレクトリサービスのクエリー

NNMiは，LDAPを使用してディレクトリサービスと通信します。NNMiが要求を送信すると，ディレクトリサービスは保存されている情報を返します。NNMiは，ディレクトリサービスに保存されている情報を変更できません。

12.3.1　ディレクトリサービスアクセス

LDAPは，次の形式でディレクトリサービスに対してクエリーを実行します。

ldap://<directory_service_host>:<port>/<search_string>

ldapはプロトコル指定子です。この指定子は，ディレクトリサービスへの標準接続とSSL接続の両方で使用してください。

<directory_service_host>は，ディレクトリサービスをホストするコンピュータの完全修飾名です。

<port>は，LDAP通信でディレクトリサービスが使用するポートです。非SSL接続のデフォルトポートは389です。SSL接続のデフォルトポートは636です。

<search_string>には要求情報が指定されます。詳細については，「12.3.2　ディレクトリサービスの情報」と，次のサイトにあるRFC 1959「An LDAP URL Format」を参照してください。

http://www.ietf.org/rfc/rfc1959.txt

WebブラウザでLDAPクエリーをURLとして入力し，アクセス情報が正しく，検索文字列の構造が正しいことを確認できます。

ディレクトリサービス（例えば，Active Directory）が匿名アクセスを許可しない場合，そのディレクトリはWebブラウザからのLDAPクエリーを拒否します。この場合は，サードパーティ製のLDAPブラウザ（Apache Directory Studioに含まれるLDAPブラウザなど）を使用し，設定パラメーターの有効性を検証できます。

12.3.2　ディレクトリサービスの情報

ディレクトリサービスには，ユーザー名，パスワード，およびグループメンバーシップなどの情報が保存されています。ディレクトリサービス内の情報にアクセスするには，情報の保存場所を参照する識別名を知っている必要があります。サインインアプリケーションの場合の識別名は，可変情報（ユーザー名など）と固定情報（ユーザー名の保存場所など）の組み合わせです。識別名を構成するエレメントは，ディレクトリサービスの構造と内容によって決まります。

次の例は，USERS-NNMi-Adminというユーザーグループの場合に考えられる定義を示しています。このグループは，NNMiへの管理アクセス権を持つディレクトリサーバーのユーザーIDのリストで構成されます。次の情報は，これらの例に関係しています。

Active Directoryの例は，Windowsオペレーティングシステムの場合です。

ほかのディレクトリサービスの例は，Linuxオペレーティングシステムの場合です。

それぞれの例に示すファイルは，LDIF（lightweight directory interchange format）ファイルの一部です。LDIFファイルによって，ディレクトリサービスの情報を共有できます。

それぞれの例の図は，ディレクトリサービスドメインをグラフィカルに表現したものです。この図は，引用したLDIFファイルに含まれる情報を拡張して表示したものです。

Active Directoryの情報構造例

この例での関心の対象は次の項目です。

ユーザーJohn Doeの識別名：

CN=john.doe@example.com,OU=Users,OU=Accounts,DC=example,DC=com

USERS-NNMi-Adminグループの識別名：

CN=USERS-NNMi-Admin,OU=Groups,OU=Accounts,DC=example,DC=com

ディレクトリサービスユーザーIDを保存するグループ属性：member

LDIFファイルの引用例：

groups |USERS-NNMi-Admin
dn: CN=USERS-NNMi-Admin,OU=Groups,OU=Accounts,DC=example,DC=com
cn: USERS-NNMi-Admin
description: Group of users for NNMi administration.
member: CN=john.doe@example.com,OU=Users,OU=Accounts,
  DC=example,DC=com
member: CN=chris.smith@example.com,OU=Users,OU=Accounts,
  DC=example,DC=com

次の図に，このディレクトリサービスドメインの例を示します。

図12‒4　Active Directoryのドメイン例

ほかのディレクトリサービスの情報構造例

この例での関心の対象は次の項目です。

ユーザーJohn Doeの識別名：

uid=john.doe@example.com,ou=People,o=example.com

USERS-NNMi-Adminグループの識別名：

cn=USERS-NNMi-Admin,ou=Groups,o=example.com

ディレクトリサービスユーザーIDを保存するグループ属性：member

LDIFファイルの引用例：

groups |USERS-NNMi-Admin
dn: cn=USERS-NNMi-Admin,ou=Groups,o=example.com
cn: USERS-NNMi-Admin
description: Group of users for NNMi administration.
member: uid=john.doe@example.com,ou=People,o=example.com
member: uid=chris.smith@example.com,ou=People,o=example.com

図12‒5　ほかのディレクトリサービスのドメインの例

12.3.3　ディレクトリサービス管理者が所有する情報

「表12‒4　ディレクトリサービスからユーザー名およびパスワードを取得する場合の情報」および「表12‒5　ディレクトリサービスからグループメンバーシップを取得する場合の情報」に，LDAPを使用してディレクトリサービスにアクセスするようにNNMiを設定する前に，ディレクトリサービス管理者から入手する情報を示します。

ユーザー名とパスワードについてだけディレクトリサービスを使用する場合（「混合モード」の設定）は，「表12‒4　ディレクトリサービスからユーザー名およびパスワードを取得する場合の情報」の情報を収集します。

すべてのNNMiアクセス情報についてディレクトリサービスを使用する場合（「外部モード」の設定）は，「表12‒4　ディレクトリサービスからユーザー名およびパスワードを取得する場合の情報」および「表12‒5　ディレクトリサービスからグループメンバーシップを取得する場合の情報」の情報を収集します。

表12‒4　ディレクトリサービスからユーザー名およびパスワードを取得する場合の情報

情報

Active Directory例

そのほかのディレクトリサービス例

ディレクトリサービスをホストするコンピュータの完全修飾名

directory_service_host.example.com

LDAP通信でディレクトリサービスが使用するポート

非SSL接続の場合は389

SSL接続の場合は636

ディレクトリサービスでのSSL接続情報

SSL接続が必要な場合は，会社のトラストストアー証明書のコピーを取得し，「10.3.8　ディレクトリサービスへのSSL接続を設定する」を参照します。

ディレクトリサービスに保存される1つのユーザー名の識別名（ディレクトリサービスドメインを示す）

CN=john.doe@example.com,

OU=Users,OU=Accounts,

DC=example,DC=com

uid=john.doe@example.com,

ou=People,o=example.com

表12‒5　ディレクトリサービスからグループメンバーシップを取得する場合の情報

情報

Active Directory例

そのほかのディレクトリサービス例

ユーザーが割り当てられているグループを識別する識別名

memberOfユーザー属性でグループを識別します。

ou=Groups,o=example.com

cn=USERS-NNMi-*,

ou=Groups,o=example.com

グループ内のユーザーを識別する方法

CN=john.doe@example.com,

OU=Users,OU=Accounts,

DC=example,DC=com

CN=john.doe@example.com

cn=john.doe@example.com,

ou=People,o=example.com

cn=john.doe@example.com

ディレクトリサービスユーザーIDを保存するグループ属性

member

member

NNMiアクセスに適用するディレクトリサービスのグループの名前

CN=USERS-NNMi-Admin,

OU=Groups,OU=Accounts,

DC=example,DC=com

CN=USERS-NNMi-Level2,

OU=Groups,OU=Accounts,

DC=example,DC=com

CN=USERS-NNMi-Level1,

OU=Groups,OU=Accounts,

DC=example,DC=com

CN=USERS-NNMi-Client,

OU=Groups,OU=Accounts,

DC=example,DC=com

CN=USERS-NNMi-Guest,

OU=Groups,OU=Accounts,

DC=example,DC=com

cn=USERS-NNMi-Admin,

ou=Groups,o=example.com

cn=USERS-NNMi-Level2,

ou=Groups,o=example.com

cn=USERS-NNMi-Level1,

ou=Groups,o=example.com

cn=USERS-NNMi-Client,

ou=Groups,o=example.com

cn=USERS-NNMi-Guest,

ou=Groups,o=example.com

12.3.4　ユーザー識別

ユーザー識別は，「混合モード」および「外部モード」に適用されます。

ユーザー識別のための識別名は，1人のユーザーをディレクトリサービスで特定するための完全に修飾する方法です。NNMiは，ユーザー識別名をLDAP要求でディレクトリサービスに渡します。

LDAP設定ファイルにおけるユーザー識別名は，nms-auth-config.xmlファイル内の<base>エレメントと<baseContextDN>エレメントを連結したものです。ディレクトリサービスによって返されたパスワードが，NNMiコンソールにユーザーが入力したサインインパスワードと一致する場合，ユーザーサインインが続行されます。

「混合モード」の場合は，次の情報が適用されます。

NNMiコンソールアクセスの場合，NNMiは次の情報を検討し，できるだけ高い権限をユーザーに与えます。

　−LDAP設定ファイルのdefaultRoleパラメーターの値

　−NNMiコンソールで定義済みのNNMiユーザーグループでの，このユーザーのメンバーシップ

NNMiトポロジオブジェクトアクセスの場合，NNMiは，NNMiコンソールでこのユーザーが属するNNMiユーザーグループのセキュリティグループマッピングに従ってアクセス権を与えます。

「外部モード」の場合は，次の情報が適用されます。

NNMiコンソールアクセスの場合，NNMiは次の情報を基に，できるだけ高い権限をユーザーに与えます。

　−LDAP設定ファイルのdefaultRoleパラメーターの値

　−NNMiコンソールで定義済みのNNMiユーザーグループにマッピングされている（［ディレクトリサービス名］フィールド）ディレクトリサービスグループでの，このユーザーのメンバーシップ

NNMiトポロジオブジェクトアクセスの場合，NNMiは，このユーザーがディレクトリサービス（NNMiコンソールでNNMiユーザーがマッピングされている）で属するグループのセキュリティグループマッピングに従ってアクセス権を与えます。

Active Directoryでのユーザー識別例

nms-auth-config.xmlファイルの内容が<base>CN={0}</base><baseContextDN>OU=Users,OU=Accounts,DC=example,DC=com</baseContextDN>で，ユーザーがNNMiにjohn.doeとしてサインインする場合，ディレクトリサービスに渡される文字列は次のとおりです。

CN=john.doe,OU=Users,OU=Accounts,DC=example,DC=com

そのほかのディレクトリサービスでのユーザー識別例

nms-auth-config.xmlファイルの内容が<base>uid={0}@example.com</base><baseContextDN>ou=People,o=example.com</baseContextDN>で，ユーザーがNNMiにjohn.doeとしてサインインする場合，ディレクトリサービスに渡される文字列は次のとおりです。

uid=john.doe@example.com,ou=People,o=example.com

12.3.5　ユーザーグループ識別

ユーザーグループ識別は，「外部モード」の設定に適用されます。

NNMiは，NNMiユーザーのユーザーグループを次のように判断します。

NNMiコンソールで設定されているすべてのユーザーグループの外部名の値をディレクトリサービスグループの名前と比較する。

ユーザーグループが一致する場合，NNMiユーザーがディレクトリサービスのそのグループのメンバーであるかどうかを判断する。

NNMiコンソールで，短いテキスト文字列によって，NNMiコンソールアクセスを許可する，定義済みのNNMiユーザーグループの一意の名前が識別されます。LDAP設定ファイルのdefaultRoleおよびuserRoleFilterListパラメーターも，このテキスト文字列を必要とします。次の表では，このグループの一意の名前を表示名にマッピングしています。

表12‒6　NNMiユーザーグループ名のマッピング

NNMiコンソールのNNMiロール名

NNMi設定ファイルのユーザーグループの一意の名前およびテキスト文字列

管理者

admin

グローバルオペレーター

globalops

オペレータレベル2

level2

オペレータレベル1

level1

ゲスト

guest

Webサービスクライアント

client

NNMiグローバルオペレータユーザーグループ（globalops）では，すべてのトポロジオブジェクトだけにアクセス権が与えられます。ユーザーがNNMiコンソールにアクセスするには，ユーザーをほかのどれかのユーザーグループ（admin，level2，level1，またはguest）に割り当てる必要があります。

globalopsユーザーグループはデフォルトですべてのセキュリティグループにマッピングされるため，管理者はこのユーザーグループをセキュリティグループにマッピングしないようにする必要があります。

(1)　ディレクトリサービスからのユーザーグループ取得の設定（詳細な方法）

「12.2　ディレクトリサービスへのアクセスを設定する」の「12.2.5　タスク5：（「外部モード」の設定だけ）ディレクトリサービスからのグループの取得を設定する」の説明にある簡単な方法では正常に機能しない場合は，次の手順を実行します。

必要なユーザー情報をディレクトリサービス管理者から取得する。

適切な手順を完了し，ディレクトリサービスでのグループ名およびグループメンバーの形式を確認する。

Active Directoryの場合にLDAPブラウザを使用する方法：以降の「(2)　ディレクトリサービスでグループおよびグループメンバーシップを識別する方法の判別（Active Directoryの場合にLDAPブラウザを使用する方法）」を参照してください。

ほかのディレクトリサービスの場合にLDAPブラウザを使用する方法：以降の「(3)　ディレクトリサービスでグループおよびグループメンバーシップを識別する方法の判別（ほかのディレクトリサービスの場合にLDAPブラウザを使用する方法）」を参照してください。

ほかのディレクトリサービスの場合にWebブラウザを使用する方法：以降の「(4)　ディレクトリサービスでグループを識別する方法の判別（Webブラウザを使用する方法）」を参照してください。

LDAP設定ファイルを設定する。

nms-auth-config.xmlファイルを任意のテキストエディタで開く。

ディレクトリサービスでグループにユーザー名が保存されるときの方法とユーザー名が相関するように，roleエレメントを設定する。

実際のユーザー名を次の式のどちらかで置き換えます。

サインインのために入力されたユーザー名を意味する場合は{0}を使用します（たとえば，john.doe）。

ディレクトリサービスによって返された認証済みユーザーの識別名を意味する場合は，{1}を使用します（たとえば，uid=john.doe@example.com,ou=People,o=example.com）。

ディレクトリサービスのドメインでグループレコードを保存する部分をroleContextDNエレメントに設定する。

形式は，ディレクトリサービスの属性名と値のカンマ区切りリストです。

例：

Active Directoryの場合：

CN=Users,DC=ldapserver,DC=mycompany,DC=com

その他のLDAP技術の場合：

ou=Groups,o=example.com

「12.2　ディレクトリサービスへのアクセスを設定する」の説明に従って設定をテストする。

(2)　ディレクトリサービスでグループおよびグループメンバーシップを識別する方法の判別（Active Directoryの場合にLDAPブラウザを使用する方法）

サードパーティのLDAPブラウザで，次の手順を実行します。

ディレクトリサーバードメインの中でユーザー情報を保存する領域にナビゲートする。

NNMiにアクセスする必要があるユーザーを識別し，そのユーザーに関連づけられているグループの識別名の形式を調べる。

ディレクトリサーバードメインの中でグループ情報を保存する領域にナビゲートする。

NNMiユーザーグループに対応するグループを識別して，グループに関連づけられているユーザーの名前の形式を調べる。

(3)　ディレクトリサービスでグループおよびグループメンバーシップを識別する方法の判別（ほかのディレクトリサービスの場合にLDAPブラウザを使用する方法）

サードパーティのLDAPブラウザで，次の手順を実行します。

ディレクトリサーバードメインの中でグループ情報を保存する領域にナビゲートする。

NNMiユーザーグループに対応するグループを識別して，それらのグループの識別名の形式を調べる。

グループに関連づけられているユーザーの名前の形式も調べる。

(4)　ディレクトリサービスでグループを識別する方法の判別（Webブラウザを使用する方法）

サポートされるWebブラウザで，次のURLを入力する。

ldap://<directory_service_host>:<port>/<group_search_string>

<directory_service_host>は，ディレクトリサービスをホストするコンピュータの完全修飾名です。

<port>は，LDAP通信でディレクトリサービスが使用するポートです。

<group_search_string>は，ディレクトリサービスに保存されるグループ名の識別名です（例：cn=USERS-NNMi-Admin,ou=Groups,o=example.com）。

ディレクトリサービスのアクセステストの結果を評価する。

ディレクトリサービスに要求されたエントリが存在しないことを示すメッセージが表示された場合は，<group_search_string>の値を確認してから，手順1.の操作を繰り返してください。

該当するグループのリストが表示された場合，そのアクセス情報は正しいことになります。

グループのプロパティを調べ，そのグループに関連づけられているユーザーの名前の形式を判断する。

12.4　NNMiユーザーグループを保存するディレクトリサービスの設定

NNMiユーザーグループをディレクトリサービスに保存する場合（「外部モード」の設定）は，NNMiユーザーグループ情報を使用してディレクトリサービスを設定する必要があります。原則として，ディレクトリサービスには適切なユーザーグループがすでに含まれています。含まれていない場合，ディレクトリサービス管理者は，特にNNMiユーザーグループ割り当て用の新規ユーザーグループを作成できます。

ディレクトリサービスの設定およびメンテナンス手順は，特定のディレクトリサービスソフトウェアと企業のポリシーに応じて異なるため，ここではそれらの手順について説明していません。

12.5　ディレクトリサービス統合のトラブルシューティング

次のコマンドを実行して，NNMi LDAP設定を検証する。

nnmldap.ovpl -info

報告された設定が期待どおりの設定ではない場合は，LDAP設定ファイルで設定を確認してください。

次のコマンドを実行して，NNMiにLDAP設定ファイルを再読み込みさせる。

nnmldap.ovpl -reload

次のコマンドを実行して，ユーザーの設定をテストする。

nnmldap.ovpl -diagnose <NNMi_user>

<NNMi_user>は，ディレクトリサービスで定義したNNMiユーザーのサインイン名で置き換えます。

コマンド出力を検討し，適切に応答します。

メモ

混合モードの場合，次のようなメッセージが出力されますが，混合モードではLDAPグループを参照しないため，動作に問題ありません。次のメッセージは無視してください。

!!!!!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!
!  このユーザー識別名のLDAPグループが見つかりません。
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!
!  LDAPの設定が誤っているようです。詳細は、上記を参照してください。
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

ディレクトリサービスに期待されるレコードが含まれていることを確認する。

WebブラウザまたはサードパーティのLDAPブラウザ（Apache Directory Studioに含まれるLDAPブラウザなど）を使用して，ディレクトリサービスの情報を調べます。

ディレクトリサービスに対するクエリーの形式に関する詳細については，次のサイトのRFC 1959「An LDAP URL Format」を参照してください。

http://www.ietf.org/rfc/rfc1959.txt

%NnmDataDir%log¥nnm¥nnm.log（Windows）または/var/opt/OV/log/nnm/nnm.log（Linux）のログファイルを表示し，サインイン要求が正しいことを確認して，エラーが発生しているかどうかを判断する。

次の行のようなメッセージは，ディレクトリサービスでHTTPS通信が必要であることを示しています。この場合は，「10.3.8　ディレクトリサービスへのSSL接続を設定する」の説明に従ってSSLを有効にします。

javax.naming.AuthenticationNotSupportedException：［LDAP:error code 13 - confidentiality required］

次の行のようなメッセージは，ディレクトリサービスとのやり取り中にタイムアウトが発生したことを示します。この場合は，LDAP設定ファイルのsearchTimeLimitの値を増やします。

javax.naming.TimeLimitExceededException：［LDAP: error code 3 - Timelimit Exceeded］

12.6　LDAP設定ファイルリファレンス

12.6.1　nms-auth-config.xmlファイル

nms-auth-config.xmlファイルには，ディレクトリサービスと通信して，それに対するLDAP照会を作成するための設定がXML形式で保存されています。このセクションでは，LDAP設定に関連するエレメントのみをリファレンス用として提供します。

このファイルは次の場所にあります。

Windowsの場合：%NnmDataDir%nmsas¥NNM¥conf

Linuxの場合：$NnmDataDir/nmsas/NNM/conf

デフォルトでは，この場所にあるnms-auth-config.xmlファイルにはLDAP設定に必要なXMLエレメントは含まれていません。

必要なすべてのXMLエレメントをこのファイルに手動で追加するには，このセクションの手順に従います。

NNMiによって，参照用のサンプルnms-auth-config.xmlファイルが別の場所に格納されます。

サンプルnms-auth-config.xmlファイルは次の場所にあります。

Windowsの場合：%NnmInstallDir%newconfig¥HPOvNnmAS¥nmsas¥conf

Linuxの場合：$NnmInstallDir/newconfig/HPOvNnmAS/nmsas/conf

ヒント

サンプルnms-auth-config.xmlファイルから<ldapLogin>エレメント全体をコピーし，必要な変更を加えることもできます。

nms-auth-config.xmlファイル（%NnmDataDir%nmsas¥NNM¥conf（Windows）または$NnmDataDir/nmsas/NNM/conf（Linux））の編集後，次のコマンドを実行してNNMiにLDAP設定を再度読み込ませます。

Windowsの場合：

%NnmInstallDir%bin¥nnmldap.ovpl -reload

Linuxの場合：

$NnmInstallDir/bin/nnmldap.ovpl -reload

<ldapLogin>
<!-- これはLDAP認証をオン/オフするスイッチです。trueのときLDAPベースの認証が使用されます-->
  <enabled>true</enabled>
<!-- このエレメントにより、インシデントの割り当てが行えるユーザーを指定できます。-->
  <userRoleFilterList>admin guest level2 level1</userRoleFilterList>
<!-- <enabled>がtrueの場合、<configuration>エレメントを定義してLDAPパラメーターを指定します-->
  <configuration>
<!-- ログオンを試みたユーザーとフィルター(オプション) を照合して、適切な設定が使用されているか確認します。複数の設定が指定されている場合、これにより適用外のLDAPサーバーをスキップしてログオン時間を短縮できます。-->
    <filter>
      <usernamePattern>.*@hpe¥.com</usernamePattern>
    </filter>
<!-- LDAPサーバーの検索を実行するときの時間制限-->
    <searchTimeLimit>30000</searchTimeLimit>
    <connectTimeLimit>10000</connectTimeLimit>
<!-- サーバーURLを定義-->
    <server>
      <hostname>ldaps://ldap.domain1.com</hostname>
      <secure>true</secure>
    </server>
<!---オプション。匿名アクセスをサポートしていないLDAPサーバーに接続するためのバインド資格証明と暗号化パスワード。"nnmldap.ovpl -encrypt" を使用して暗号化パスワードを作成します。--->
    <bindCredential>
      <bindDN>someUser@some.com</bindDN>
      <bindCredential>someEncryptedPassword</bindCredential>
    </bindCredential>
<!-- このエレメントは、このLDAP設定でユーザーを検索するためのルールを定義します-->
    <users>
<!-- オプション。ログオンを試みたユーザーと照合されるフィルター。適用外のLDAP設定をスキップしてログオン時間を短縮するために使用されます。これはJavaの正規表現です。-->
      <filter>
        <usernamePattern>.*some¥.com</usernamePattern>
      </filter>
<!-- オプション。NNMiコンソールに表示される表示名の式。-->
      <displayName>${sn},${givenName} (HPE)</displayName>
<!-- オプション。この設定で認証されるすべてのユーザーに付与されるデフォルトのロール-->
      <defaultRoles>
        <role>guest</role>
      </defaultRoles>
<!-- ユーザーアカウントを見つけるための検索設定。文字列中のパターン"{0}" は、ユーザーがログオン画面に入力したログオン名に置き換えられます。-->
      <userSearch>
        <base>uid={0}</base>
        <baseContextDN>ou=People,o=domain.com</baseContextDN>
      </userSearch>
    </users>
<!-- このLDAP設定でユーザーのロールまたはグループを検索するためのルールを定義します-->
    <roles>
<!-- オプション。この設定でロールを検索するための対象となるユーザーを定義するフィルター。これはJavaの正規表現です。-->
      <filter><usernamePattern>x</usernamePattern></filter>
<!-- 認証されたユーザーDNが含まれているLDAPグループを見つけるための検索設定。ユーザーのDNが含まれる箇所で文字列"{1}" を使用します。-->
      <roleSearch>
        <roleBase>member={1}</roleBase>
        <roleContextDN>ou=Groups,o=some.com</roleContextDN>
      </roleSearch>
      <roleSearch>
        <roleBase>GroupMember={1}</roleBase>
        <roleContextDN>CN=Groups,DC=mycompany,DC=com</roleContextDN>
      </roleSearch>
    </roles>
  </configuration>
</ldapLogin>

12.7　nms-auth-config.xmlファイルへの切り替え

11-10から11-50以降へバージョンアップすると自動的にldap.propertiesファイルの設定がnms-auth-config.xmlファイルへ移行されます。

重要

ldap.propertiesファイルでdefaultRoleを次のようにコメントアウトしている状態で，11-50以降へバージョンアップした場合，バージョンアップ時に生成されたnms-auth-config.xmlファイルはそのままご利用いただけません。

#defaultRole=guest

nms-auth-config.xmlファイルの次の設定個所をコメントアウトするか削除して，nnmldap.ovpl -reloadコマンドを実行し，LDAP設定ファイルを再読み込みしてください。

<defaultRoles>
 <role/>
</defaultRoles>

13　NAT環境の重複IPアドレスの管理

NAT（ネットワークアドレス変換）では，多数のローカルネットワークを1つの動的な外部（パブリック）IPアドレスを使用してグローバルインターネットに接続することでIPアドレスを節約できます。また，内部アドレスを外部ネットワークから隠ぺいすることで，プライベートネットワークのセキュリティが強化できます。この章では，NNMiで使用するNATの設定および重複するIPアドレスの設定について説明します。

13.1　NATとは

通常，ネットワークアドレス変換は，ローカルネットワークを外部インターネットと相互接続するために使用します。このテクノロジは，より多くのIPv4アドレスを求めるニーズの高まりに対応するソリューションとして開発されました。また，IPアドレスの特定範囲（RFC1918を参照）は，内部専用として設計されていた（インターネット上でルーティングできない）ため，NATのようなテクノロジを求める声が強くなっていました。

NATではIPヘッダー情報を変換します。パブリックネットワークを通過する必要があるIPパケットの内部アドレスを外部アドレスに置き換えます。NATでは，静的または動的な外部アドレスを使用することで内部アドレスを外部アドレスに変換します。

13.2　NATの利点

NATには，次のような利点があります。

多数のホストが1つの動的な外部IPアドレスを使用してグローバルインターネットに接続するため，IPアドレス空間を節約できる

プライベートIPアドレスを再利用できる

内部アドレスを外部ネットワークから隠ぺいすることで，プライベートネットワークのセキュリティが強化される

13.3　サポートされるNATタイプ

NNMiでは，次のタイプのNATプロトコルがサポートされます。

静的NAT：

内部IPアドレスが，常に同じ外部IPアドレスにマップされるNATタイプ（各ノードは静的な内部／外部アドレスペアを持つ）。このタイプでは，Webサーバーなどの内部ホストに未登録（プライベート）IPアドレスを割り当てたまま，インターネット上で到達可能な状態にすることができます。

動的NAT：

外部アドレスと内部アドレスのバインドをセッションごとに変更できるNATスキーム。このNATスキームでは，利用可能な登録済み（パブリック）IPアドレスのプールから得られるパブリックIPアドレスに内部IPアドレスがマップされます。通常，ネットワーク内のNATルーターで登録済みIPアドレスのテーブルが保持されています。内部IPアドレスからインターネットへのアクセスが要求されると，別の内部IPアドレスで現在使用されていないIPアドレスがルーターによってテーブルから選択されます。

動的ポートアドレス変換（動的PAT）（ネットワークアドレスおよびポート変換（NAPT）とも呼ばれる）：

このタイプのNATでは，IPアドレスだけでなくポート番号も変換されます。アドレスとポート番号を変換することで，複数の内部アドレスが1つの外部アドレスを使用してインターネット上で同時に通信できるようになります。

13.4　NNMiにNATを実装する方法

NNMiでは，テナント／IPアドレスのペアを使用して各ノードを識別することによって，NAT環境を管理します。NNMi管理者は，NATアドレスドメインごとにテナント定義を作成します。テナントによって，ノードの論理グループが識別されます。例えば，インターネットプロバイダーのネットワークに，プライベートIPアドレスを実装した顧客が複数存在するとします。インターネットプロバイダーは，NNMi内で各顧客のノードを，個々の顧客を識別する特定のテナント名に割り当てることができます。そのテナントの論理グループ内では，次のようになります。

NNMi管理者は，検出シードを使用して，テナント／IPアドレスのペアを使用するテナントメンバーのノードを識別します。

サブネット接続ルールは，各テナントのノードグループ内で独立して適用されます。

ルーター冗長グループは，ほかのテナントノードグループから独立し，各テナント内でモニタリングされます。

NNMiは，各テナントのノードグループ内，および定義済みのそのテナントのノードとデフォルトテナントに割り当てられたノード間だけでL2接続を検出します。

複数のNATドメイン（NATゲートウェイルーターなど）と相互接続するインフラストラクチャーデバイスは，すべてデフォルトテナントに割り当てます。これによって，ワークグループ（および顧客）が確認する必要があるレイヤー2接続がNNMiに表示されるようになります。

NNMiユーザーが表示できるテナント数は，セキュリティグループによって決まります。割り当てられたセキュリティグループには，複数のテナントのノードを含めることができます。詳細については，「14.　NNMiのセキュリティおよびマルチテナント」を参照してください。

メモ

ネットワーク管理環境のすべてのNATドメインで，ドメインネームシステム（DNS）名が重複しないようにすることを推奨します。

使用しているNATプロトコルによって，NNMiの実装方法や要件が異なる場合があります。例えば，動的NATまたは動的PATを使用している場合，追加のハードウェアおよびライセンスが必要になります。NATプロトコルのタイプに基づいて，適切な節を参照してください。

「13.5　静的NATの考慮事項」

「13.6　動的NATおよび動的PATの考慮事項」

詳細については，「13.6.6　ネットワークアドレス変換（NAT）環境でのNNMiの配備」および「13.6.7　状態とステータスのNNMi計算」を参照してください。

13.5　静的NATの考慮事項

各インスタンスが一意のテナントで設定されていれば，1つのNNMi管理サーバーで任意の数の静的NATインスタンスを監視できます。テナントの詳細については，「14.　NNMiのセキュリティおよびマルチテナント」およびNNMiヘルプの「テナントを設定する」を参照してください。

静的NATの設定例として次の図を参照してください。

図13‒1　静的NATの設定例

デフォルトテナントに属するノードは，任意のテナントの任意のノードにレイヤー2接続できます。デフォルトテナント以外のテナント内のノードは，同じテナントかデフォルトテナント内のデバイスにしかレイヤー2接続できません。

サブネットはテナントに固有です（サブネットは複数のテナントにまたがらない）。このメリットは，同じサブネットを異なるテナントで使用できる点にあります。

ルーター冗長グループ（RRG）はテナントをまたがることができません。

複数のNATドメイン（NATゲートウェイなど）と相互接続するインフラストラクチャーデバイスは，すべてデフォルトテナントに割り当てます。これによって，ワークグループ（および顧客）が確認する必要があるレイヤー2接続がNNMiに表示されるようになります。

デフォルトのセキュリティグループ内のデバイスはすべてのビューで表示されます。デバイスへのアクセスを制御するには，該当するデバイスをデフォルトのセキュリティグループ以外のセキュリティグループに割り当てます。

13.5.1　静的NATのハードウェアとソフトウェアの要件

静的NATでは，特別なハードウェアまたはソフトウェアの要件はありません。1つのNNMi管理サーバーで，NNMi，NNMi Advancedを使用する静的NATドメインを幾つでも管理できます。

13.5.2　静的NATでの通信

NNMiでは，使用可能な重複するアドレスマッピングを自動的に使用して静的NAT通信用のテナント／外部IPアドレスのペアを識別することによって，静的NATファイアウォールを通して正常な通信が行われます。この利点については，「13.7　重複するIPアドレスマッピング」を参照してください。

(1)　静的NAT環境での管理アドレスのICMPポーリングの管理

NAT環境では，ファイアウォールによって，NNMiがノードのIPアドレス（プライベートIPアドレス）を使用してNATノードとのやり取りがブロックされます。これを解決するには，NATアドレス（パブリックIPアドレス）を使用してNNMiと通信します。

NAT環境では，ノードの管理アドレスが，ノードでホストされるIPアドレスと異なることがあります。NNMiがNAT環境でノードを検出できるようにするには，NATアドレスを検出シードとしてNNMiに追加する必要があります。NNMiは，このNATアドレスがノードのipAddressTableに存在しなくても，それを通信に使用します。

NNMiはこの機能を提供することで，誤ったノード停止中インシデントの生成を回避し，根本原因分析をより正確にします。

(2)　NAT環境での管理アドレスのICMPポーリングの概要

(a)　NAT環境の管理アドレスのICMPポーリング

NAT環境がある場合，この設定を無効にしないことをお勧めします。

管理アドレスのICMPポーリングが無効になっている場合，有効にするには，次の手順を実行します。

ワークスペースのナビゲーションパネルで，［設定］ワークスペースを選択して［モニタリング］フォルダーを展開し，［モニタリングの設定］を選択して［デフォルト設定］タブを探す。

［ICMP障害モニタリング］セクションの［管理アドレスポーリングを有効にする］を有効にする。

NNMiヘルプの「モニタリングのデフォルト設定」を参照してください。

SNMPエージェントに対して［アクション］＞［モニタリングの設定］を実行したあとにNNMiが表示する情報を確認します。表示される情報に，NNMiが管理アドレスのポーリングを有効にしているかどうかが示されます。

ICMP管理アドレスポーリングが有効になっていると，NNMiが次のように変更されます。

［管理アドレスICMPの状態］フィールドが次のフォームおよびテーブルビューに表示されます。

［ノード］フォーム

［SNMPエージェント］フォーム

［SNMPエージェント］テーブルビュー

NNMiは，管理アドレスICMP状態の表示場所とSNMPエージェントステータスの判断方法を変更します。

管理アドレスICMPおよびIPアドレスの状態ポーリングアクションを次の表に示します。NNMiは，ICMP管理アドレスポーリング設定およびICMP障害ポーリング設定に対応して，これらのアクションを実行します。

表13‒1　ICMP設定および結果の状態ポーリング

ICMP管理アドレスポーリング

ICMP障害ポーリング

管理ICMPアドレス状態

IPアドレス状態

有効※

無効※

ポーリング※

ポーリングなし※

有効

有効

ポーリング

ポーリング

無効

無効

ポーリングなし

ポーリングなし

無効

有効

ポーリングなし

ポーリング

注※　デフォルトの設定

SNMPエージェントと管理アドレスICMPの応答のためにAPAが判断するSNMPエージェントステータス，および生成されるインシデントの変化を次の表に示します。APAは，管理アドレスのICMPポーリングで，結論とインシデントの生成時に，管理アドレスICMP応答とSNMPエージェント応答を考慮します。

表13‒2　SNMPエージェントステータスの判断および生成されるインシデント

SNMPエージェント応答

管理アドレスICMP応答

SNMPエージェントステータス

生成されるインシデント

応答

応答

正常域

なし

応答

無応答

警戒域

そのほかのネットワークの問題で，生成されるインシデントは次のとおりです。

なし

AddressNotResponding

無応答

応答

危険域

SNMPAgentNotResponding

無応答

無応答

危険域

そのほかのネットワークの問題で，生成されるインシデントは次のとおりです。

なし

NodeDown

13.5.3　検出と静的NAT

NNMi管理者は，ネットワーク管理環境内の各静的NATドメインを識別するために，テナント定義を作成する必要があります。スパイラル検出では，NNMiが各ノードを検出して監視する前に各ノードを識別するための検出シード（テナントとアドレスのペア）が必要です。

NNMi管理者は，静的NATドメインのノードごとに検出シードを作成する必要があります。検出シードでは，ノードごとに次の情報を指定します。

外部IPアドレス（外部/内部IPアドレスペアのパブリックアドレス）

テナント名

詳細については，NNMiヘルプを参照してください。

重要

検出シードを静的NAT環境内に追加する場合（nnmloadseeds.ovplコマンドまたはNNMiコンソールを使用），必ずノードの外部（パブリック）IPアドレスを使用してください。詳細については，nnmloadseeds.ovplリファレンスページを参照してください。

ドメインネームシステム（DNS）名が重複しないようにすることをお勧めします。

13.5.4　静的NATのモニタリングの設定

ネットワーク環境によって，NNMi管理者はICMP障害モニタリングの設定を使用するかどうかを選択できます。「13.6.7　状態とステータスのNNMi計算」も参照してください。

［モニタリングの設定］＞［ノードの設定］タブ

ノードグループのモニタリングを設定します。［ICMP障害モニタリング］セクションで選択します。詳細については，NNMiオンラインヘルプを参照してください。

管理アドレスポーリング（デフォルトで有効な，強く推奨される機能）

IPアドレス障害ポーリング（省略可能）

［モニタリングの設定］＞［デフォルト設定］タブ

［ICMP障害モニタリング］セクションで選択します。詳細については，NNMiオンラインヘルプを参照してください。

重要

ネットワーク環境に動的NATドメインも設定されている場合，動的NATドメインとは異なる設定が静的NATドメインで必要になることがあるため，デフォルト設定が適切でない可能性があります。

13.5.5　トラップと静的NAT

NNMi管理サーバーでNATゲートウェイの背後にあるノードからSNMPトラップを受信するには，管理対象ノードを変更する必要があります。この項では，SNMPv2cとSNMPv1の2種類のSNMPトラップについて説明します。

NNMiでは，受信した各トラップのソースアドレスを一義的に解決する必要があります。

(1)　SNMPv2cトラップ

次の図に，SNMPv2cトラップの形式を示します。この図の上部のセクションはIPヘッダー，下部のセクションはSNMPトラップのProtocol Data Unit (PDU)で構成されています。

SNMPv2cトラップのPDUには，エージェントアドレスフィールドがありません。そのため，トラップの唯一のソースフィールドがIPパケットヘッダー内に存在します。ソースフィールドは，NATルーターによって適切に変換されます。

ソースノードのプライベート内部IPアドレスに関連づけられているインタフェースで，NATルーターの背後にあるデバイスのすべてのトラップのソースが明らかになっていることを確認します。これで，NATゲートウェイがトラップを適切なパブリックアドレスに変換できます。

次の図に，NATゲートウェイからの適切な変換の例を示します。NATゲートウェイによって，192.168.1.2のソースアドレスで始まるトラップのアドレスが15.2.12.2に適切に変換されます。次に，NNMi管理サーバーによってこのアドレスが適切に解決されます。

図13‒2　SNMPv2cの例

(2)　SNMPv1トラップ

SNMPv1トラップの場合，SNMPトラップのPDU内にエージェントアドレスが組み込まれています。次の図に，SNMPv1トラップの形式を示します。上部のセクションはIPヘッダー，下部のセクションはSNMPトラップのPDUで構成されています。

エージェントアドレスはヘッダーではなくPDUに組み込まれているため，通常，この値はNATルーターによって変換されません。ヘッダーのアドレスを認識して，ペイロードのエージェントアドレスを無視するようにNNMiを設定するには，次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を探す。

#!com.hp.nnm.trapd.useUdpHeaderIpAddress=false

次のように値をtrueに変更して#!文字を削除する。

com.hp.nnm.trapd.useUdpHeaderIpAddress=true

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

次の図に，競合するエージェントアドレスフィールドがNNMiで無視されるSNMPv1トラップの例を示します。

図13‒3　SNMPv1の例

NNMiでは，関連する次のカスタムインシデント属性（CIA）が提供されます。

cia.agentAddress−トラップを生成したSNMPエージェントのSNMPv1トラップデータに保存されるIPアドレス。

cia.internalAddress−静的NATがネットワーク管理ドメインに含まれている場合，NNMi管理者は，選択したインシデントのソースノードの外部管理アドレスにマップされる内部IPアドレスを表示するようにこの属性を設定できます。

［重複するIPアドレスマッピング］フォームを使用して，この内部アドレス（プライベートアドレス）に外部管理IPアドレス（パブリックアドレス）をマップする必要があります。詳細については，NNMiヘルプを参照してください。

13.5.6　サブネットと静的NAT

サブネットおよびNATに関しては，次の点に注意してください。

サブネットはテナントに固有です（サブネットは複数のテナントにまたがらない）。このメリットは，同じサブネットを異なるテナントで使用できる点にあります。

サブネットフィルタではテナントとアドレスのペアが使用されます。

サブネット接続ルールを設定する場合，そのルールはすべてのテナントに適用されます。サブネットのメンバーは，すべてのテナントで一意である必要があります（各ノードは1つのテナントにだけ割り当てられます）。サブネット接続ルールで，デフォルトテナントと別のテナント間にリンクを確立できます。ただし，2つのテナント間のリンクは，どちらかのテナントがデフォルトテナントである場合にだけ使用できます。

13.5.7　グローバルネットワーク管理と静的NAT

リージョナルマネージャーごとに，少なくとも1つの静的またはルーティング可能（非変換）アドレスがある必要があります。これによって，NNMi管理サーバーが相互に通信ができ，通信を隠ぺいしてセキュリティを確保できます。グローバルネットワーク管理の詳細については，「15.　グローバルネットワーク管理」を参照してください。

13.6　動的NATおよび動的PATの考慮事項

1つのNNMi管理サーバーで1つの動的NATドメインまたは動的PATドメインを管理できます。このドメイン内にあるすべてのノードは一意の同じテナントに属している必要があります。NNMi管理サーバーは，リージョナルマネージャーとしてグローバルネットワーク管理環境に参加している必要があります。動的NATの設定例として次の図を参照してください。

リージョナルマネージャーがNATファイアウォールの背後にある場合，その外部（パブリック）アドレスは静的アドレスである必要があります。

図13‒4　動的NATの設定例

複数の動的NATドメイン，および動的PATドメインを監視するには，NNMiのグローバルネットワーク管理機能を使用します。テナントは，NNMiグローバルネットワーク管理設定全体で一意である必要があります。NAT環境内のグローバルネットワーク管理設定の例として次の図を参照してください。

図13‒5　NAT環境内のグローバルネットワーク管理設定の例

デフォルトテナントに属するデバイスは，任意のテナントの任意のデバイスにレイヤー2接続できます。デフォルトテナント以外のテナント内のデバイスは，同じテナントかデフォルトテナント内のデバイスにしかレイヤー2接続できません。

複数のNATドメイン（NATゲートウェイなど）と相互接続するインフラストラクチャーデバイスは，すべてデフォルトテナントに割り当てます。これによって，ワークグループ（および顧客）が確認する必要があるレイヤー2接続がNNMiに表示されるようになります。

デフォルトのセキュリティグループ内のデバイスはすべてのビューで表示されます。デバイスへのアクセスを制御するには，該当するデバイスをデフォルトのセキュリティグループ以外のセキュリティグループに割り当てます。

グローバルネットワーク管理の詳細については，「15.　グローバルネットワーク管理」を参照してください。テナントの設定の詳細については，NNMiヘルプの「テナントを設定する」を参照してください。

13.6.1　動的NATおよび動的PATのハードウェアとソフトウェアの要件

動的NATおよび動的PAT環境では，NNMi Advancedが必要になります。動的NATまたは動的PATで設定されたアドレスドメインごとにNNMiリージョナルマネージャーが必要です。

13.6.2　検出と動的NATおよび動的PAT

NNMiでは，テナントを使用して重複アドレスドメインを含むネットワークに対応します。重複アドレスドメインは，ネットワーク管理ドメインの動的NATまたは動的PAT領域内に存在することがあります。そのようなネットワークの場合，重複アドレスドメインを異なるテナントに配置します（これはシード検出を使用して行います）。詳細については，NNMiヘルプを参照してください。

動的NATまたは動的PAT環境内に検出シードを追加する場合（nnmloadseeds.ovplコマンドまたはNNMiコンソールを使用），必ずノードの内部IPアドレスを使用してください。

詳細については，nnmloadseeds.ovplリファレンスページ，またはNNMiヘルプを参照してください。

13.6.3　動的NATのモニタリングの設定

ネットワーク環境によって，NNMi管理者はICMP障害モニタリングの設定を使用するかどうかを選択できます。「13.6.7　状態とステータスのNNMi計算」も参照してください。

［モニタリングの設定］＞［ノードの設定］タブ

ノードグループのモニタリングを設定します。［ICMP障害モニタリング］セクションで選択します。詳細については，NNMiオンラインヘルプを参照してください。

管理アドレスポーリング（デフォルトで有効な，強く推奨される機能）

IPアドレス障害ポーリング（省略可能）

［モニタリングの設定］＞［デフォルト設定］タブ

［ICMP障害モニタリング］セクションで選択します。詳細については，NNMiオンラインヘルプを参照してください。

重要

ネットワーク環境に静的NATドメインも設定されている場合，動的NATドメインとは異なる設定が静的NATドメインで必要になることがあるため，デフォルト設定が適切でない可能性があります。

13.6.4　サブネットと動的NATおよび動的PAT

サブネット，動的NATおよび動的PATに関しては，次の点に注意してください。

サブネットはテナントに固有です（サブネットは複数のテナントにまたがらない）。このメリットは，同じサブネットを異なるテナントで使用できる点にあります。

サブネットフィルタではテナントとアドレスのペアが使用されます。

サブネット接続ルールを設定する場合，そのルールはすべてのテナントに適用されます。サブネットのメンバーは，すべてのテナントで一意である必要があります（各ノードは1つのテナントにだけ割り当てられます）。サブネット接続ルールで，デフォルトテナントと別のテナント間にリンクを確立できます。ただし，2つのテナント間のリンクは，どちらかのテナントがデフォルトテナントである場合にだけ使用できます。

13.6.5　グローバルネットワーク管理と動的NATおよび動的PAT

リージョナルマネージャーごとに，少なくとも1つの静的またはルーティング可能（非変換）アドレスがある必要があります。これによって，NNMi管理サーバーが相互に通信ができ，通信を隠ぺいしてセキュリティを確保できます。

リージョナルマネージャーがNATファイアウォールの背後にある場合，その外部アドレスは静的アドレスである必要があります。

グローバルネットワーク管理の詳細については，「15.　グローバルネットワーク管理」を参照してください。NNMiヘルプの「グローバルネットワーク管理のためのテナントのベストプラクティス」も参照してください。

13.6.6　ネットワークアドレス変換（NAT）環境でのNNMiの配備

NAT環境でNNMiを配備するには，次の手順を実行します。

ネットワーク管理環境の各NATドメインのリストを特定して作成する。

各NATドメイン内で使用されるサポート対象NATのタイプを調べる。

各NATドメイン（NATドメインの内部IPアドレス領域内外）に関して，必要に応じて各NNMi管理サーバーを配備する。

次の特別な考慮事項を参照してください。

「13.5　静的NATの考慮事項」

「13.6　動的NATおよび動的PATの考慮事項」

NNMiの［設定］＞［検出］＞［テナント］ワークスペースを使用して，各NATドメインで一意のテナント名を定義する。

重要

配備でグローバルネットワーク管理を使用している場合，この名前はすべてのNNMi管理サーバー（リージョナルマネージャーとグローバルマネージャー）で一意である必要があります。

NNMiでモニタリングする必要のある各NATドメイン内のノードを決定する。

静的NATドメインのみ: 重複するアドレスマッピングを作成して，各ノードの割り当てられたNAT外部/内部IPアドレスのペアを識別する。

重複するアドレスマッピングを作成する利点については，「13.7　重複するIPアドレスマッピング」を参照してください。

次の情報を入力します。

テナント名

外部IPアドレス

内部IPアドレス

NNMiの［設定］＞［検出］＞［重複するアドレスマッピング］ワークスペースまたはnnmloadipmappings.ovplコマンドラインツールのどちらかを使用します。

詳細については，NNMiオンラインヘルプを参照してください。

ネットワーク環境のNNMi管理サーバーの配備先によっては，NNMiでノードの内部アドレスを使用する場合に，ファイアウォールによってNNMiとNATドメイン内のノードの通信がブロックされる可能性がある。そのため，［設定］＞［通信の設定］設定で，適切な［優先管理アドレス］設定（NATの外部または内部IPアドレス）を使用する。

ネットワーク環境のNATの［モニタリングの設定］設定を確認する。

「13.5.4　静的NATのモニタリングの設定」

「13.6.3　動的NATのモニタリングの設定」

［モニタリングの設定］の詳細については，NNMiオンラインヘルプを参照してください。

各ノードの検出シードを設定する。

重要

複数のNATドメイン（NATゲートウェイルーターなど）と相互接続するインフラストラクチャーデバイスは，すべてデフォルトテナントに割り当てます。

NNMiの［設定］＞［検出］＞［シード］ワークスペースまたはloadseeds.ovplコマンドラインツールのどちらかを使用します。

NNMi管理サーバーが内部IPアドレス領域内にある場合，内部IPアドレスを使用して検出シードを設定します。

・ホスト名/IP（内部IPアドレスを使用）

・テナント名

NNMi管理サーバーが内部IPアドレス領域外にある場合，外部IPアドレスを使用して検出シードを設定します。

・ホスト名/IP（外部IPアドレスを使用）

・テナント名

詳細については，NNMiオンラインヘルプを参照してください。

NNMi検出で，期待どおりノードが検出されることを確認する。

検出されない場合，設定（上記）をダブルチェックします。

NNMi設定がチームのニーズを満たしていることを確認する。

各ノードのセキュリティグループの割り当てを微調整して，NNMiコンソールで各ノードを表示できるチームメンバー/顧客を制御します。NNMiの［設定］＞［セキュリティ］＞［セキュリティグループ］ワークスペースを使用します。

これらのノードに適用される［モニタリングの設定］設定を確認して，必要に応じて微調整します。NNMiの［設定］＞［モニタリング］＞［モニタリングの設定］ワークスペースを使用します。

NNMiマップにノード間の接続が期待どおりに表示されることを確認する。

表示されない場合，次の作業を行います。

接続に含まれる両方のノードのテナントの割り当て（デフォルトテナントまたはその他のテナント）が正しいことを確認します。

［設定］＞［検出］＞［検出の設定］の［サブネット接続ルール］タブの設定が正しいことを確認します。

自動的に検出されない接続をNNMiで強制的に追加するには，nnmconnedit.ovplコマンドラインツールを使用します。詳細については，nnmconnedit.ovplリファレンスページを参照してください。

適切なNNMi管理サーバーのIPアドレスが含まれるように各ノードのSNMPエージェントのSNMPトラップ転送ルールが設定されていることを確認する。

静的NATドメインのみ: NNMiの［重複するアドレスマッピング］の［内部アドレス］に関連づけられたインタフェースが，NNMi管理サーバーに送信されるすべてのトラップのソースになるように，各静的NATノードのSNMPエージェントを設定する。

ネットワーク環境にSNMPv1が含まれている場合，NNMi設定で必要な変更を適切に行う。

「13.5.5　トラップと静的NAT」を参照してください。

13.6.7　状態とステータスのNNMi計算

デフォルトのNNMiでは，NAT環境に存在するノードを含め，各ノードの管理アドレスのICMPポーリングが自動的に有効になります（［設定］＞［モニタリング］＞［モニタリングの設定］，［デフォルト設定］タブ，［ICMP障害モニタリング］セクションの［管理アドレスポーリングを有効にする］設定）。NAT環境がある場合，この設定を無効にしないことをお勧めします。

重要

［インベントリ］＞［ノード］ビューでノードを選択し，［アクション］＞［設定の詳細］＞［モニタリングの設定］コマンドを使用します。表示される情報に，NNMiでこの管理アドレスポーリングが有効になっているかどうかが示されます。

管理アドレスポーリングが有効の場合は，［エージェントICMP状態］フィールドが，次の場所に表示されます。

［ノード］フォーム

［SNMPエージェント］フォーム

［SNMPエージェント］テーブルビュー

次の表に，［ICMP障害モニタリング］設定に基づいてNNMiの動作がどのように変化するかを示します。

表13‒3　モニタリングの設定の内容および結果としてのState Poller動作

ICMP障害モニタリングの設定

管理ICMPアドレス状態

IPアドレス状態

管理アドレスポーリングを有効にする

IPアドレス障害ポーリングを有効にする

エージェントICMP状態

IPアドレス状態

有効※

無効※

ポーリング

未ポーリング

有効

有効

ポーリング

ポーリング

無効

無効

未ポーリング

未ポーリング

無効

有効

未ポーリング

ポーリング

注※　デフォルトの設定

管理アドレスポーリングを有効にすると，結果の計算時とインシデントの生成時に，管理アドレスのICMP応答とSNMPエージェントの応答の両方がNNMiで考慮されます。

次の表に，ICMP応答とSNMP応答の組み合わせによって決定される，SNMPエージェントステータスの計算を示します。

表13‒4　SNMPエージェントステータスの判断

SNMPエージェントの応答

管理アドレスのICMP応答

結果としてのSNMPエージェントステータス

応答

応答

正常域

応答

無応答

警戒域

無応答

応答

危険域

無応答

無応答

危険域

13.7　重複するIPアドレスマッピング

ネットワーク管理環境に重複アドレスドメインが含まれている場合，一意のテナントとして各ドメインを設定する必要があります。詳細については，NNMiヘルプの「テナントを設定する」および「14.　NNMiのセキュリティおよびマルチテナント」を参照してください。

静的NATがネットワーク管理ドメインに含まれていて，NNMi管理サーバーが静的NATドメイン外にある場合，識別されたテナント／NAT内部IPアドレス（プライベートIPv4アドレスなど）ペアの［IPアドレス］フォームの［マップされたアドレス］属性にNAT外部IPアドレス（パブリックアドレス）が表示されるようにNNMiを設定できます。

動的NATおよび動的PATを使用しているネットワーク管理ドメインの領域に対してNNMiを設定している場合，［重複するIPアドレスマッピング］フォームは使用しないでください。「13.6　動的NATおよび動的PATの考慮事項」を参照してください。

ネットワークドメインの静的NAT設定は，パブリックIPアドレス，プライベートIPアドレスまたはその両方に適用されることがあります。

識別されたテナントとNAT内部IPアドレスペアの［IPアドレス］フォームの［マップされたアドレス］属性に静的NAT外部IPアドレスが表示されるようにNNMiを設定するには，次のどちらかを実行します。

NNMiコンソールで，［重複するIPアドレスマッピング］フォームを使用します。

nnmloadipmappings.ovplコマンドを使用します。

詳細については，NNMiヘルプ，またはnnmloadipmappings.ovplのリファレンスページを参照してください。

13.7.1　プライベートIPアドレスの範囲

Internet Engineering Task Force（IETF）およびInternet Assigned Numbers Authority（IANA）では，次のIPアドレス範囲をプライベートネットワーク（企業のローカルエリアネットワーク（LAN），企業のオフィス，または住宅用のネットワークなど）用に予約しています。

IPv4プライベートアドレス範囲（RFC1918）：

10.0.0.0〜10.255.255.255（24ビットブロック）

172.16.0.0〜172.31.255.255（20ビットブロック）

192.168.0.0〜192.168.255.255（16ビットブロック）

IPv6プライベートアドレス範囲：

fc00::/7アドレスブロック=RFC4193ユニークローカルアドレス（ULA）

fec0::/10アドレスブロック=非推奨（RFC3879）

14　NNMiのセキュリティおよびマルチテナント

NNMiセキュリティおよびマルチテナントでは，NNMiデータベースのオブジェクトに関する情報へのユーザーアクセスを制限できます。この制限は，ネットワークオペレータのビューをその責任範囲に合わせてカスタマイズする場合やサービスプロバイダがNNMiを組織ごとに設定する場合に役立ちます。この章では，NNMiセキュリティおよびテナントモデルについて説明し，設定の推奨事項について記載します。デフォルトでは，NNMiコンソールユーザーがNNMiデータベースのすべてのオブジェクトを参照できます。使用環境でデフォルト設定を許容できる場合，この章は必要ありません。

14.1　オブジェクトのアクセス制限による影響

NNMiセキュリティを設定すると次のような影響があります。

トポロジインベントリオブジェクト：

NNMiコンソールユーザーには，そのユーザーのNNMiユーザーアカウント設定に対応するノードだけが表示されます。

インタフェースなどのサブノードオブジェクトは，そのノードからアクセス制御を継承します。

接続などのノード間オブジェクトは，NNMiコンソールユーザーが関連するノードを1つ以上表示できる場合にだけ表示されます。

NNMiコンソールユーザーには，ノードグループの中の1つ以上のノードにそのユーザーがアクセスできるノードグループだけが表示されます。

マップおよびパスビュー：

マップには，関与している両方のノードを表示する権限をNNMiコンソールユーザーが持っている接続が表示されます。

パスビューでは，NNMiコンソールユーザーがアクセスできないすべての中間ノードは省略されるか，クラウドとして表示されます。

インシデント：

ソースノードがNNMiトポロジ内にあるインシデントについては，NNMiコンソールユーザーがソースノードにアクセスできるインシデントだけが表示されます。

NNMiの稼働状態およびライセンス管理イベントのインシデントなど，ソースノードが含まれないインシデントは，1つのグループとして処理されます。NNMi管理者は，ユーザーに［未解決のインシデント］セキュリティグループを関連づけることで，どのNNMiコンソールユーザーにそれらのインシデントが表示されるかを決定します。

ソースノードがNNMiトポロジ内にないトラップから生じたインシデントは，ソースノードが含まれないインシデントと同様に処理されます。これらのインシデントを生成するようにNNMiが設定されている場合，NNMi管理者は，ユーザーに［未解決のインシデント］セキュリティグループを関連づけることで，どのNNMiコンソールユーザーにそれらのインシデントが表示されるかを決定します。

インシデントの割り当てアクションでは，ユーザーのアクセス権はチェックされません。NNMi管理者によって，あるインシデントがそのインシデントを表示する権限を持たないNNMiコンソールユーザーに割り当てられるおそれがあります。

NNMiコンソールアクション：

何も選択しないで実行されるアクションの場合，NNMiコンソールユーザーが実行する権限を持っているアクションだけが表示されます。

選択された1つ以上のオブジェクトに対して実行されるアクションの場合，NNMiコンソールユーザーは，選択されたオブジェクトに対する適切なアクセスレベルを持っている必要があります。セキュリティ設定によっては，NNMiコンソールビューに表示されている一部のオブジェクトに対して有効ではないアクションがNNMiコンソールに表示される場合もあります。これらの無効なアクションを実行すると，この制限に関するエラーメッセージが表示されます。

マップビューについては，NNMiは，不明なノードと，NNMiトポロジ内に存在するが現在のユーザーがアクセスできないノードの区別ができません。

MIBブラウザおよび線グラフ：

NNMiコンソールユーザーは，ユーザーがアクセスできるノードのMIBデータとグラフを表示できます。

NNMiコンソールユーザーは，ユーザーがSNMPコミュニティ文字列を認識しているノードのMIBデータを表示できます。

NNMiコンソールURL：

ダイレクトURLからNNMiコンソールビューにアクセスするには，NNMiにサインインする必要があります。NNMiは，NNMiセキュリティ設定に応じてユーザーのアクセス権を適用し，それに従って，使用できるトポロジを制限します。

14.2　NNMiのセキュリティモデル

NNMiセキュリティモデルでは，NNMiデータベースのオブジェクトへのユーザーアクセスを制御できます。このモデルは，NNMiユーザーのアクセスを特定のオブジェクトやインシデントに制限するネットワーク管理組織で使用する場合に適しています。NNMiセキュリティモデルには，次の利点があります。

NNMiコンソールオペレータのネットワークのビューを制限できます。オペレータは特定のデバイスタイプまたはネットワーク領域に集中できます。

NNMiトポロジへのオペレータアクセスをカスタマイズできます。オペレータアクセスのレベルは，ノードごとに設定できます。

［ノード（すべての属性）］ビューをセキュリティグループでフィルタリングできます。

セキュリティ設定で構成されるノードグループの設定およびメンテナンスが簡素化されます。

NNMiテナントモデルとは独立して使用できます。

NNMiセキュリティは，次のような場合に使用されます。

NNMiオペレータがサイト（カスタムマップ）内の機器タイプに集中できるようにします。

特定のサイト（カスタムマップ）のノードだけが表示される各サイトビューをNNMiオペレータに提供します。

導入時にノードをステージングします。NNMi管理者にはすべてのノードが表示されますが，NNMiオペレータには導入したノードだけが表示されます。

すべてのNOCオペレータにフルアクセスを付与し，NOCユーザーのアクセスを制限します。

中央のNOCオペレータに完全なネットワークビューを提供し，地域のNOCオペレータのビューを制限します。

14.2.1　セキュリティグループ

NNMiセキュリティモデルでは，ノードへのユーザーアクセスはユーザーグループおよびセキュリティグループを介して間接的に制御されます。NNMiトポロジ内の各ノードは，1つのセキュリティグループだけに関連づけられます。セキュリティグループは複数のユーザーグループに関連づけることができます。

各ユーザーアカウントは，次のユーザーグループにマッピングされます。

次に示す事前設定された1つ以上のNNMiユーザーグループ

NNMi管理者

NNMiグローバルオペレーター

NNMiレベル1オペレーター

NNMiレベル2オペレーター

NNMiゲストユーザー

マッピングはNNMiコンソールのアクセスに必要です。これによって，NNMiコンソール内で使用できるアクションが決まります。ユーザーアカウントがこれらの複数のNNMiユーザーグループにマッピングされている場合，許可されるアクションのスーパーセットがユーザーに付与されます。

［NNMi Webサービスクライアント］ユーザーグループでは，NNMiコンソールへのアクセス権は付与されませんが，すべてのNNMiオブジェクトへの管理者レベルのアクセス権が付与されます。

NNMiグローバルオペレータユーザーグループ（globalops）では，すべてのトポロジオブジェクトだけにアクセス権が与えられます。ユーザーがNNMiコンソールにアクセスするには，ユーザーをほかのどれかのユーザーグループ（level2，level1，またはguest）に割り当てる必要があります。

globalopsユーザーグループはデフォルトですべてのセキュリティグループにマッピングされるため，管理者はこのユーザーグループをセキュリティグループにマッピングしないようにする必要があります。

セキュリティグループにマッピングされるカスタムユーザーグループ

これらのマッピングでは，NNMiデータベースのオブジェクトへのアクセスが提供されます。各マッピングには，セキュリティグループのノードに適用されるオブジェクトアクセス権レベルが含まれています。オブジェクトアクセス権レベルは，インタフェースやインシデントなどの関連するデータベースオブジェクトにも適用されます。例えば，インタフェースXおよびYを含むノードAへのオブジェクトオペレータレベル1のアクセス権があるユーザーには，次のすべてのデータベースオブジェクトへのオブジェクトオペレータレベル1のアクセス権があります。

ノードA

インタフェースXおよびY

ソースオブジェクトがノードA，インタフェースX，またはインタフェースYのインシデント

NNMiには，次のセキュリティグループがあります。

デフォルトのセキュリティグループ

新しいNNMiインストール済み環境では，［デフォルトのセキュリティグループ］がすべてのノードに対する初期セキュリティグループとして割り当てられます。デフォルトでは，すべてのユーザーに，［デフォルトのセキュリティグループ］内のすべてのオブジェクトが表示されます。NNMi管理者は，［デフォルトのセキュリティグループ］に関連づけられるノードと，［デフォルトのセキュリティグループ］内のオブジェクトにアクセスできるユーザーを設定できます。

未解決のインシデント

［未解決のインシデント］セキュリティグループは，ソースノードがNNMiトポロジ内にない受信トラップからNNMiが作成するインシデントへのアクセス権を提供します。デフォルトでは，すべてのユーザーに，［未解決のインシデント］セキュリティグループに関連づけられたすべてのインシデントが表示されます。NNMi管理者は，［未解決のインシデント］セキュリティグループに関連づけられたインシデントにアクセスできるユーザーを設定できます。

すべてのセンサーは，ノードのセキュリティグループの割り当てを継承します。

ベストプラクティス

次のベストプラクティスがNNMiセキュリティ設定に適用されます。

各ユーザーアカウントを事前設定された1つのNNMiユーザーグループだけにマッピングします。

事前設定されたNNMiユーザーグループをセキュリティグループにマッピングしないでください。

［NNMi管理者］ユーザーグループにマッピングされたすべてのユーザーアカウントには，NNMiデータベースのすべてのオブジェクトに対する管理者レベルのアクセス権が付与されるため，このユーザーアカウントをほかのユーザーグループにマッピングしないでください。

Webサービスクライアントロール専用のユーザーアカウントを別個に作成します。このユーザーアカウントはNNMiトポロジ全体にアクセスできるため，このユーザーアカウントは［NNMi Web サービスクライアント］ユーザーグループにだけマッピングしてください。

14.2.2　セキュリティグループ構造の例

次の図に示すユーザーの枠は，NNMiトポロジの例で，ユーザーに表示する必要のあるノードのプライマリグループを示しています。ユーザーアクセスを完全に制御するには，サブグループが一意のセキュリティグループに対応している必要があります。一意の各セキュリティグループを1つ以上のユーザーグループにマッピングして，そのセキュリティグループ内のオブジェクトに対して使用できるユーザーアクセスのレベルを表すことができます。

表14-1に，トポロジでのセキュリティグループと考えられるカスタムユーザーグループ間のマッピングを示します。セキュリティモデルを実際に実装する場合，これらのカスタムユーザーグループの一部は不要になることがあります。

表14-2に，このトポロジでの幾つかのユーザーアカウントとユーザーグループのマッピングを示します。

図14‒1　ユーザーアクセス要件に対応するトポロジの例

表14‒1　セキュリティグループマッピングの例

セキュリティグループ

セキュリティグループのノード

ユーザーグループ

オブジェクトアクセス権

SG1

A，B，C

UG1管理者

オブジェクト管理者

UG1レベル2

オブジェクトオペレータレベル2

UG1レベル1

オブジェクトオペレータレベル1

UG1ゲスト

オブジェクトゲスト

SG2

D，E

UG2管理者

オブジェクト管理者

UG2レベル2

オブジェクトオペレータレベル2

UG2レベル1

オブジェクトオペレータレベル1

UG2ゲスト

オブジェクトゲスト

SG3

F，G

UG3管理者

オブジェクト管理者

UG3レベル2

オブジェクトオペレータレベル2

UG3レベル1

オブジェクトオペレータレベル1

UG3ゲスト

オブジェクトゲスト

SG4

H，I，J

UG4管理者

オブジェクト管理者

UG4レベル2

オブジェクトオペレータレベル2

UG4レベル1

オブジェクトオペレータレベル1

UG4ゲスト

オブジェクトゲスト

表14‒2　ユーザーアカウントマッピングの例

ユーザーアカウント

ユーザーグループ

ノードアクセス

注

ユーザーQ

NNMiレベル2オペレータ

なし

ユーザーQの枠に含まれるノードへのオペレータレベル2のアクセス権があります。

UG1レベル2

A，B，C

UG2レベル2

D，E

UG3レベル2

F，G

ユーザーR

NNMiレベル1オペレータ

なし

ユーザーRの枠に含まれるノードへのオペレータレベル1のアクセス権があります。

UG2レベル1

D，E

ユーザーS

NNMiレベル2オペレータ

なし

ユーザーSの枠に含まれるノードへのオペレータレベル2のアクセス権があります。

UG3レベル2

F，G

UG4レベル2

H，I，J

ユーザーT

NNMiレベル2オペレータ

なし

ユーザーTは，トポロジの例に含まれるすべてのノードに（各権限レベルで）アクセスできます。

このユーザーには，ノードDおよびEへの管理アクセス権がありますが，管理アクセス権が必要なツールのメニュー項目は表示できません。ユーザーにNNMi管理サーバーへのアクセス権がある場合は，ノードDおよびEに対してだけ，管理アクセス権が必要なコマンドラインツールを実行できます。

UG1ゲスト

A，B，C

UG2管理者

D，E

UG3レベル2

F，G

UG4レベル1

H，I，J

14.3　NNMiのテナントモデル

NNMiテナントモデルでは，トポロジ検出とトポロジデータが各テナント（組織または顧客とも呼ばれる）で完全に分離されます。このモデルは，サービスプロバイダ（特に管理対象サービスプロバイダ）や大規模エンタープライズに適しています。

NNMiテナントモデルには，次の利点があります。

各ノードが属する組織が明確になります。

［ノード（すべての属性）］インベントリビューを，テナントとセキュリティグループでフィルタリングできます。

顧客データへのオペレータアクセスを分離する規制要件に適合します。

テナント設定で構成されるノードグループの設定およびメンテナンスが簡素化されます。

NNMiセキュリティの設定が簡素化されます。

NNMiマルチテナントを使用すると，同じNNMi管理サーバーで複数の顧客（テナント）を管理するサービスプロバイダに，異なる顧客ビューを提供できます。

14.3.1　テナント

NNMiテナントモデルでは，組織という概念がセキュリティ設定に加わります。NNMiトポロジ内の各ノードが属するテナントは1つだけです。テナントによって，NNMiデータベースが論理的に分離されます。オブジェクトアクセスはセキュリティグループで管理されます。

ノードが最初に検出されてNNMiデータベースに追加されるときに，各ノードで初期検出テナントの割り当てが発生します。シード済みのノードで，各ノードに割り当てるテナントを指定できます。NNMiによって，検出されたほかのすべてのノード（自動検出ルールに含まれているが直接シードされないノード）がデフォルトテナントに割り当てられます。NNMi管理者は，検出後にいつでもノードのテナントを変更できます。

各テナント定義には，初期検出セキュリティグループが含まれます。NNMiによって，初期検出セキュリティグループが初期検出テナントとともにノードに割り当てられます。NNMi管理者は，検出後にいつでもノードのセキュリティグループを変更できます。

ノードのテナントの割り当てを変更しても，セキュリティグループの割り当ては自動的に変更されません。

NNMiには，デフォルトテナントが備わっています。デフォルトでは，すべてのNNMiユーザーが，［デフォルトのセキュリティグループ］を介して，テナントに関連づけられたすべてのオブジェクトにアクセスできます。

すべてのセンサーは，ノードのテナントおよびセキュリティグループの割り当てを継承します。

ベストプラクティス

次のベストプラクティスがNNMiテナント設定に適用されます。

小規模な組織の場合，テナントごとに1つのセキュリティグループで十分です。

大規模な組織を複数のセキュリティグループに分割できます。

ユーザーが組織を超えてノードにアクセスできないようにするには，各セキュリティグループに，1つのテナントだけに対応するノードしか含まれないようにします。

14.3.2　テナント構造の例

次の図では，NNMiトポロジ内に2つのテナントが含まれている様子を示します。ユーザーL，M，Nの枠は，ユーザーにノードを表示する必要があるプライマリグループを表しています。テナント1のトポロジは1つのグループとして管理されるため，1つのセキュリティグループだけが必要です。テナント2のトポロジは重複しているセットで管理されるため，3つのセキュリティグループに分割されます。

表14-3に，トポロジでのセキュリティグループと考えられるカスタムユーザーグループ間のマッピングを示します（このセキュリティモデルを実際に実装する場合，これらのカスタムユーザーグループの一部は不要になることがあります）。

表14-4に，このトポロジでの幾つかのユーザーアカウントとユーザーグループのマッピングを示します。

図14‒2　複数のテナントのトポロジの例

表14‒3　複数のテナントのセキュリティグループマッピングの例

セキュリティグループ

セキュリティグループのノード

ユーザーグループ

オブジェクトアクセス権

T1 SG

A，B，C，D，E

T1管理者

オブジェクト管理者

T1レベル2

オブジェクトオペレータレベル2

T1レベル1

オブジェクトオペレータレベル1

T1ゲスト

オブジェクトゲスト

T2 SGa

F，G

T2_a管理者

オブジェクト管理者

T2_aレベル2

オブジェクトオペレータレベル2

T2_aレベル1

オブジェクトオペレータレベル1

T2_aゲスト

オブジェクトゲスト

T2 SGb

H

T2_b管理者

オブジェクト管理者

T2_bレベル2

オブジェクトオペレータレベル2

T2_bレベル1

オブジェクトオペレータレベル1

T2_bゲスト

オブジェクトゲスト

T2 SGc

I，J

T2_c管理者

オブジェクト管理者

T2_cレベル2

オブジェクトオペレータレベル2

T2_cレベル1

オブジェクトオペレータレベル1

T2_cゲスト

オブジェクトゲスト

表14‒4　複数のテナントのユーザーアカウントマッピングの例

ユーザーアカウント

ユーザーグループ

ノードアクセス

注

ユーザーL

NNMiレベル2オペレータ

なし

ユーザーLには，テナント1のすべてのノードをグループ化する，ユーザーLの枠に含まれるノードへのオペレータレベル2のアクセス権があります。

T1レベル2

A，B，C，D，E

ユーザーM

NNMiレベル1オペレータ

なし

ユーザーMには，テナント2のノードのサブセットをグループ化する，ユーザーMの枠に含まれるノードへのオペレータレベル1のアクセス権があります。

T2_aレベル1

F，G

T2_bレベル1

H

ユーザーN

NNMiレベル2オペレータ

なし

ユーザーNには，テナント2のノードのサブセットをグループ化する，ユーザーNの枠に含まれるノードへのオペレータレベル2のアクセス権があります。

T2_bレベル2

H

T2_cレベル2

I，J

14.4　NNMiのセキュリティおよびマルチテナントを設定する

NNMiのセキュリティおよびマルチテナント設定は，NNMiデータベース全体に適用されます。NNMi管理者であれば，すべてのテナントのすべてのオブジェクトへのオペレータアクセス権を表示および設定できます。

NNMi管理者が1つ以上のカスタムセキュリティグループを定義すると，［セキュリティグループ］がすべての［ノード］フォームに表示されます。また，［ノード］および［ノード（すべての属性）］インベントリビューの列としても表示されます。

NNMi管理者が1つ以上のカスタムテナントを定義すると，［テナント］フィールドがすべての［ノード］フォームに表示されます。また，［ノード］および［ノード（すべての属性）］インベントリビューの列としても表示されます。

ノードグループ

セキュリティ設定またはマルチテナント設定の一部と適合するようにノードグループを作成するには，セキュリティグループUUID，セキュリティグループ名，テナントUUID，またはテナント名に基づいて，ノードグループの追加のフィルターを指定します。これらのノードグループを使用して，監視アクションおよびインシデントライフサイクル移行アクション用のポーリングサイクルを，セキュリティグループまたはテナントごとに設定します。

ヒント

セキュリティグループとテナントの名前は変更できるため，追加のフィルターにはセキュリティグループまたはテナントのUUIDを指定します。この情報は，設定フォームと，nnmsecurity.ovplコマンド出力で使用できます。

ユーザーグループ：NNMiコンソールアクセス

事前に定義されたNNMiユーザーグループの1つにユーザーアカウントをマッピングすると，NNMiロールと，NNMiコンソールで表示されるメニュー項目が設定されます。各ユーザーアカウントには，そのユーザーのトポロジオブジェクトに対する最も高いオブジェクトのアクセス権に対応するNNMiロールを付与することをお勧めします。

ただし，NNMi管理者はすべてのトポロジオブジェクトへのアクセス権を持つため，管理者レベルの権限を付与することは避けてください。NNMiトポロジ内の一部のノードに対してだけ，NNMiコンソールユーザーを管理者として設定するには，そのユーザーをNNMiレベル1オペレータまたはNNMiレベル2オペレータのユーザーグループに割り当てます。また，オブジェクト管理者オブジェクトアクセス権を使用して，トポロジ内のノードのサブセットを含むセキュリティグループにマッピングされたカスタムユーザーグループを作成し，ユーザーをそのグループに割り当てます。

ユーザーグループ：ディレクトリサービス

ユーザーグループメンバーシップをNNMiデータベースに保存する場合，すべてのオブジェクトアクセス設定は，NNMi設定エリア内で，ユーザーグループ，ユーザーアカウントマッピング，セキュリティグループ，およびセキュリティグループマッピングを使用します。

ユーザーグループメンバーシップをディレクトリサービスに保存する場合，オブジェクトアクセス設定は，NNMi設定（セキュリティグループおよびセキュリティグループマッピング）と，ディレクトリサービスコンテンツ（ユーザーグループメンバーシップ）の間で共有されます。NNMiデータベースに，ユーザーアカウントまたはユーザーアカウントマッピングを作成しないでください。ディレクトリサービス内の適用可能なグループごとに，NNMiデータベースに1つ以上のユーザーグループを作成してください。NNMiで，各ユーザーグループ定義の［ディレクトリサービス名］フィールドに，ディレクトリサービス内のそのグループの識別名を設定します。

詳細については，「12.　NNMiとLDAPによるディレクトリサービスの統合」を参照してください。

14.4.1　セキュリティおよびマルチテナントの設定ツール

NNMiには，マルチテナントとセキュリティを設定するための幾つかのツールが備わっています。

セキュリティウィザード

NNMiコンソールの［セキュリティウィザード］は，セキュリティ設定の可視化に役立ちます。NNMiコンソール内でノードをセキュリティグループに割り当てるには，このウィザードを使用する方法が最も簡単です。［変更概要の表示］ページには，現在のウィザードセッションで保存されていない変更点のリストが表示されます。また，セキュリティ設定に関する潜在的な問題も示されます。

［セキュリティウィザード］の使用法の詳細については，ウィザード内のNNMiヘルプリンクをクリックしてください。

メモ

［セキュリティウィザード］は，NNMiセキュリティ設定に関してだけ使用できます。テナント情報は含まれていません。

NNMiコンソールフォーム

NNMiコンソール内の個々のセキュリティオブジェクトおよびマルチテナントオブジェクトのフォームは，設定の1つの側面を同時に集中的に捉える場合に便利です。これらのフォームの使用法の詳細については，各フォームのNNMiヘルプを参照してください。

［テナント］ビューにはNNMiマルチテナント設定情報が含まれています。このビューは，［設定］ワークスペースの［検出］の下に表示されます。各［テナント］フォームには1つのNNMiテナントが記述され，現在そのテナントに割り当てられているノードが表示されます。ノードの割り当て情報は読み取り専用です。

ノードに割り当てられているテナントまたはセキュリティグループを変更するには，［ノード］フォームまたはnnmsecurity.ovplコマンドを使用します。

次のNNMiコンソールビューは，［設定］ワークスペースの［セキュリティ］の下に表示されます。これらのビューには，次のNNMiセキュリティ設定情報が含まれています。

ユーザーアカウント

・各［ユーザーアカウント］フォームには1つのNNMiユーザーが記述され，そのユーザーが属するユーザーグループが表示されます。メンバーシップ情報は読み取り専用です。

・ユーザーグループメンバーシップをディレクトリサービスに保存すると，ユーザーアカウントはNNMiコンソールに表示されません。

ユーザーグループ

各［ユーザーグループ］フォームには1つのNNMiユーザーグループが記述され，そのユーザーグループにマッピングされたユーザーアカウントとセキュリティグループが表示されます。マッピング情報は読み取り専用です。

ユーザーアカウントのマッピング

・各［ユーザーアカウントのマッピング］フォームには，1つのユーザーアカウントとユーザーグループの関連づけが表示されます。

・ユーザーアカウントマッピングを変更しても，現在のNNMiコンソールユーザーにその変更は反映されません。現在のユーザーは，NNMiコンソールに次回のサインインで，変更を受け取ります。

・ユーザーグループメンバーシップをディレクトリサービスに保存すると，ユーザーアカウントマッピングはNNMiコンソールに表示されません。

セキュリティグループ

各［セキュリティグループ］フォームには1つのNNMiセキュリティグループが記述され，そのセキュリティグループに現在割り当てられているノードが表示されます。ノードの割り当て情報は読み取り専用です。

セキュリティグループのマッピング

・各［セキュリティグループのマッピング］フォームには，1つのユーザーグループとセキュリティグループの関連づけが表示されます。

・初期設定のあと，セキュリティグループマッピングに関連づけられたオブジェクトのアクセス権は読み取り専用になっています。セキュリティグループマッピングのオブジェクトアクセス権を変更するには，そのマッピングを削除して，再度作成します。

コマンドライン

nnmsecurity.ovplコマンドラインインタフェースは，自動操作や一括操作する場合に便利です。このツールは，セキュリティ設定に関する潜在的な問題のレポートも提供します。

nnmsecurity.ovplオプションの多くは，コンマ区切り値（CSV）ファイルからの入力データのロードをサポートしています。設定データは，nnmsecurity.ovplコマンドで使用するために，CSV出力を生成できるファイルまたはシステムに保持できます。このコマンドは，NNMiの外部で生成されたUUIDも受け入れます。

ヒント

セキュリティグループとテナントの名前は一意である必要はないため，nnmsecurity.ovplコマンドへの入力値としてセキュリティグループまたはテナントのUUIDを指定します。

次のスクリプト例では，nnmsecurity.ovplコマンドを使用して，2つのユーザーアカウントと5つのノードにセキュリティ設定を作成しています。

#!/bin/sh
# ユーザーを2つ作成する
nnmsecurity.ovpl -createUserAccount user1 -password password -role level1
nnmsecurity.ovpl -createUserAccount user2 -password password -role level2
# グループを2つ作成する
nnmsecurity.ovpl -createUserGroup local1
nnmsecurity.ovpl -createUserGroup local2
# 新しいユーザーグループにユーザーアカウントを割り当てる
nnmsecurity.ovpl -assignUserToGroup -user user1 -userGroup local1
nnmsecurity.ovpl -assignUserToGroup -user user2 -userGroup local2
# セキュリティグループを2つ作成する
nnmsecurity.ovpl -createSecurityGroup secgroup1
nnmsecurity.ovpl -createSecurityGroup secgroup2
# 新しいセキュリティグループに新しいユーザーグループを割り当てる
nnmsecurity.ovpl -assignUserGroupToSecurityGroup -userGroup local1 -securityGroup secgroup1 -role level1
nnmsecurity.ovpl -assignUserGroupToSecurityGroup -userGroup local2 -securityGroup secgroup2 -role level2
# セキュリティグループをノードに割り当てる
nnmsecurity.ovpl -assignNodeToSecurityGroup -node mplspe01 -securityGroup secgroup1
nnmsecurity.ovpl -assignNodeToSecurityGroup -node vwan_router-1 -securityGroup secgroup1
nnmsecurity.ovpl -assignNodeToSecurityGroup -node vwan_router-2 -securityGroup secgroup1
nnmsecurity.ovpl -assignNodeToSecurityGroup -node data_center_1 -securityGroup secgroup2
nnmsecurity.ovpl -assignNodeToSecurityGroup -node mplspe03 -securityGroup secgroup2

14.4.2　マルチテナントを設定する

次の方法でマルチテナントを設定できます。

NNMiコンソールの［テナント］フォーム

個々のテナントを処理する際に役立ちます。

nnmsecurity.ovplコマンドラインインタフェース

自動操作や一括操作する場合に便利です。このツールは，テナント設定に関する潜在的な問題のレポートも提供します。

それぞれのNNMiトポロジオブジェクトをテナント（組織）に割り当てるため，NNMiマルチテナントを定義および設定するプロセスは循環的なプロセスです。

NNMiマルチテナントの設定に関しては，次の点に注意してください。

検出されたノードに割り当てられるセキュリティグループは，そのノードに関連づけられたテナントの［初期検出セキュリティグループ］の値によって設定されます。

NNMiテナントを設定しないで，NNMiセキュリティモデルを使用すると，すべてのノードにデフォルトテナントが割り当てられます。

NNMi検出用にノードをシードするときに，そのノードが属するテナントを指定できます。自動検出ルールを使用してNNMiでノードが検出されると，NNMiによって，そのノードはデフォルトテナントに割り当てられます。検出後，ノードに対するテナントの割り当てを変更できます。

NNMiマルチテナントを計画および設定するための概略的な方法を次に示します。この概略的な手順では，NNMiマルチテナントを設定するための1つの方法を説明します。

ユーザー要件を分析して，NNMi環境で必要なテナントの数を判別する。

1つのNNMi管理サーバーで複数のネットワークを個々に管理する場合だけ，テナントを使用することをお勧めします。

管理対象のネットワークトポロジを分析して，各テナントにどのノードが属するかを判別する。

各テナントのトポロジを分析して，NNMiユーザーがアクセスする必要のあるノードのグループを判別する。

事前に定義されたNNMiユーザーグループと，［デフォルトのセキュリティグループ］および［未解決のインシデント］セキュリティグループの間のデフォルトの関係を削除する。

この手順によって，ユーザーが管理してはならないノードへのアクセス権が，そのユーザーに誤って付与されないようにします。この時点では，NNMiトポロジ内のオブジェクトにアクセスできるのはNNMi管理者だけです。

特定されたテナントを設定する。

a　特定されたセキュリティグループを作成します。

b　特定されたテナントを作成します。

テナントごとに，［デフォルトのセキュリティグループ］，またはアクセスが制限されたテナント固有のセキュリティグループのどれかに，［初期検出セキュリティグループ］を設定します。これを行うことで，NNMi管理者がアクセス権を設定するまで，テナントの新しいノードが全体に表示されることはなくなります。

テナントをシードに割り当てて，検出の準備をする。

ノードのグループを検出したあと，［初期検出セキュリティグループ］の値を変更できます。これを行うことで，ノードをセキュリティグループに手動で再割り当てする処理が制限されます。

検出が完了したら，次を実行する。

ノードごとにテナントを確認し，必要に応じて変更します。

ノードごとにセキュリティグループを確認し，必要に応じて変更します。

カスタムユーザーグループを設定する。

カスタムユーザーグループの設定については，「14.4.4　セキュリティ設定を確認する」を参照してください。

14.4.3　セキュリティグループを設定する

ディレクトリサービスとNNMiを統合して，ユーザー名，パスワード，およびオプションとしてNNMiユーザーグループの割り当ての保管場所を統合する場合は，NNMiセキュリティを設定する前に，その統合の設定を実行してください。

NNMiでは，次の方法でセキュリティを設定できます。

NNMiコンソールの［セキュリティウィザード］

セキュリティ設定の可視化に役立ちます。［変更概要の表示］ページには，現在のウィザードセッションで保存されていない変更点のリストが表示されます。また，セキュリティ設定に関する潜在的な問題も示されます。

個々のセキュリティオブジェクトに対応したNNMiコンソールのフォーム

セキュリティ設定の1つの側面を同時に集中的に捉える場合に便利です。

nnmsecurity.ovplコマンドラインインタフェース

自動操作や一括操作する場合に便利です。このツールは，セキュリティ設定に関する潜在的な問題のレポートも提供します。

NNMiトポロジ内のオブジェクトに対するユーザーのアクセス権を制限するために，NNMiセキュリティを定義および設定するプロセスは，循環的なプロセスです。

メモ

この設定方法は，セキュリティグループからユーザーアカウントに移動します。例えば，ユーザーアカウントからセキュリティグループにNNMiセキュリティを設定する場合，NNMiヘルプで「セキュリティの設定例」を検索してください。

NNMiセキュリティの設定に関しては，次の点に注意してください。

検出されたノードに割り当てられるセキュリティグループは，そのノードに関連づけられたテナントの［初期検出セキュリティグループ］の値によって設定されます。

NNMiテナントを設定しないで，NNMiセキュリティモデルを使用すると，すべてのノードがデフォルトテナントに割り当てられます。

NNMiセキュリティを計画および設定するための概略的な方法を次に示します。この概略的な手順では，NNMiセキュリティを設定するための1つの方法を説明します。

管理対象のネットワークトポロジを分析して，NNMiユーザーがアクセスする必要のあるノードのグループを判別する。

事前に定義されたNNMiユーザーグループと，［デフォルトのセキュリティグループ］および［未解決のインシデント］セキュリティグループの間のデフォルトの関係を削除する。

この手順によって，ユーザーが管理してはならないノードへのアクセス権が，そのユーザーに誤って付与されることがないようにします。この時点では，NNMiトポロジ内のオブジェクトにアクセスできるのはNNMi管理者だけです。

ノードの各サブセットのセキュリティグループを設定する。

特定のノードは1つのセキュリティグループにだけ属することができます。

a　セキュリティグループを作成します。

b　適切なノードを各セキュリティグループに割り当てます。

カスタムユーザーグループを設定する。

a　セキュリティグループごとに，NNMiユーザーアクセスの各レベルに対応するユーザーグループを設定します。

ユーザーグループメンバーシップをNNMiデータベースに保存しても，それらのユーザーグループにユーザーはマッピングされません。

ユーザーグループメンバーシップをディレクトリサービスに保存する場合は，各ユーザーグループの［ディレクトリサービス名］フィールドに，ディレクトリサービス内のそのグループの識別名を設定します。

b　各カスタムユーザーグループを，適切なセキュリティグループにマッピングします。マッピングごとに適切なオブジェクトアクセス権を設定します。

ユーザーアカウントを設定する。

ユーザーグループメンバーシップをNNMiデータベースに保存する場合は，次の手順を実行します。

NNMiコンソールにアクセスできるユーザーごとに，ユーザーアカウントオブジェクトを作成します。ユーザーアカウントを設定するプロセスは，NNMiコンソールログオンにディレクトリサービスを使用しているかどうかによって異なります。

各ユーザーアカウントをNNMiコンソールにアクセスするために，事前に定義したNNMiユーザーグループの1つにマッピングします。

各ユーザーアカウントをトポロジオブジェクトにアクセスするために，1つ以上のカスタムNNMiユーザーグループにマッピングします。

ユーザーグループメンバーシップをディレクトリサービスに保存する場合，各ユーザーが，事前に定義されたNNMiユーザーグループの1つ，および1つ以上のカスタムユーザーグループに属していることを確認します。

「14.4.4　セキュリティ設定を確認する」の説明に従って，設定を確認する。

セキュリティ設定を管理する。

［デフォルトのセキュリティグループ］に追加されたノードに注目し，これらのノードを適切なセキュリティグループに移動します。

新しいNNMiコンソールユーザーを適切なユーザーグループに追加します。

14.4.4　セキュリティ設定を確認する

セキュリティ設定が適切であるかを確認するために，設定のそれぞれの側面を個別に確認することが必要です。ここでは，設定を確認するための幾つかの方法を説明します。ここに記載されていない方法も使用できます。

メモ

NNMiには，潜在的なセキュリティ設定エラーのレポートが備わっています。これらのレポートには，NNMiコンソールの［ツール］＞［セキュリティレポート］からアクセスします。または，-displayConfigReportオプションをnnmsecurity.ovplコマンドに指定して使用することもできます。

セキュリティグループとノード間の割り当てを確認する

各ノードが適切なセキュリティグループに割り当てられていることを次の方法で確認します。

セキュリティグループごとに［ノード］または［ノード（すべての属性）］インベントリビューをソートし，グループ分けを調べます。

-listNodesInSecurityGroupオプションをnnmsecurity.ovplコマンドに指定して使用します。

ユーザーグループとセキュリティグループ間の割り当てを確認する

どのユーザーグループが各セキュリティグループにマッピングされているかを次の方法で確認します。

ユーザーグループまたはセキュリティグループごとに［セキュリティグループのマッピング］ビューをソートして，グループ分けを調べます。また，各マッピングのオブジェクトアクセス権も確認します。

［セキュリティウィザード］の［ユーザーグループとセキュリティグループのマップ］ページで，同時に1つのユーザーグループまたはセキュリティグループを選択して，そのオブジェクトに対する現在のマッピングを確認します。

-listUserGroupsForSecurityGroupオプションをnnmsecurity.ovplコマンドに指定して使用します。

各ユーザーがNNMiコンソールアクセス権を持っているかを確認する

NNMiコンソールアクセス権について，事前に設定されたNNMiユーザーグループの1つに各ユーザーが割り当てられていることを確認します。

NNMi管理者

NNMiレベル1オペレータ

NNMiレベル2オペレータ

NNMiゲストユーザー

そのほかのすべてのユーザーグループ割り当てで，NNMiデータベースのオブジェクトへのアクセス権が付与されます。

NNMiコンソールアクセス権を持たないユーザーは，［セキュリティウィザード］の［変更概要の表示］ページに表示されます。［ツール］>［セキュリティレポート］メニュー項目や，-displayConfigReport usersWithoutRolesオプションをnnmsecurity.ovplコマンドに設定して，この情報を得ることもできます。

ユーザーとユーザーグループ間の割り当てを確認する

ユーザーグループメンバーシップを次の方法で確認します。

ユーザーアカウントまたはユーザーグループごとに［ユーザーアカウントのマッピング］ビューをソートして，グループ分けを調べます。

［セキュリティウィザード］の［ユーザーアカウントとユーザーグループのマップ］ページで，同時に1つのユーザーアカウントまたはユーザーグループを選択して，そのオブジェクトに対する現在のマッピングを確認します。

-listUserGroupsオプションと-listUserGroupMembersオプションをnnmsecurity.ovplコマンドに指定して使用します。

テナントとノード間の割り当てを確認する

各ノードが適切なテナントに割り当てられていることを確認する方法として，テナントごとに［ノード］または［ノード（すべての属性）］インベントリビューをソートし，グループ分けを調べる方法があります。

現在のユーザー設定を確認する

現在ログオンしているユーザーのNNMiコンソールアクセス権を確認するには，［ヘルプ］＞［システム情報］をクリックします。［製品］タブの［ユーザー情報］セクションに，現在のNNMiセッションに関する次の情報が表示されます。

NNMiデータベースのユーザーアカウント，またはアクセス対象のディレクトリサービスに定義されているユーザー名。

NNMiロール。これは，ユーザーがマッピングされる，事前に定義されたNNMiユーザーグループ（NNMi管理者，NNMiレベル1オペレータ，NNMiレベル2オペレータ，およびNNMiゲストユーザー）の中で最も高い権限を持つものに対応します。マッピングによって，NNMiコンソールで使用できるアクションが決まります。

ユーザー名にマッピングされたユーザーグループ。このリストには，NNMiロールの設定前に設定されたNNMiユーザーグループと，NNMiデータベース内のオブジェクトへのアクセス権を付与するそのほかのすべてのユーザーグループが含まれています。

14.4.5　セキュリティおよびマルチテナントの設定をエクスポートする

次の表は，NNMiのセキュリティおよびマルチテナント設定をエクスポートするための設定エリアを示しています。nnmconfigexport.ovpl -cコマンドで使用できます。エクスポートエリアは，特にグローバルネットワーク管理環境で，複数のNNMi管理サーバーにわたって設定を管理するのに役立ちます。

表14‒5　NNMiのセキュリティおよびマルチテナント設定のエクスポートエリア

設定エリア

説明

account

ユーザーアカウント，ユーザーグループ，およびユーザーアカウントとユーザーグループ間のマッピングをエクスポートします。

複数のNNMiデータベースにわたってユーザー定義を共有するのに便利です。

security

テナントおよびセキュリティグループをエクスポートします。

複数のNNMiデータベースにわたってセキュリティ定義を共有するのに便利です。

この情報をインポートすると，新しいオブジェクトが作成され，既存のオブジェクトが更新されますが，現在のエクスポートに含まれていないオブジェクトは削除されません。このため，ローカルで定義されたオブジェクトがNNMiデータベースに含まれている場合でも，このオプションは安全に使用できます。

securitymappings

ユーザーグループとセキュリティグループ間のマッピングをエクスポートします。

セキュリティとマルチテナント設定を完全にエクスポートするには，account，security，およびsecuritymappings設定エリアの同時エクスポートを実行してください。

14.5　NNMiセキュリティとマルチテナントをグローバルネットワーク管理に定義する

グローバルネットワーク管理環境では，ノードのテナントは，そのノードを管理するNNMi管理サーバーに設定されます。グローバルネットワーク管理環境では，指定されたノードのテナントUUIDは各グローバルマネージャーとリージョナルマネージャーで同じです。

ノードのセキュリティグループは，トポロジにそのノードが含まれる各NNMi管理サーバーに設定されます。したがって，トポロジ内のオブジェクトへのユーザーアクセスは，グローバルネットワーク管理環境の各NNMi管理サーバーに別個に設定されます。グローバルマネージャーとリージョナルマネージャーが使用するセキュリティグループ定義は，同じである場合も，異なる場合もあります。

グローバルマネージャーとリージョナルマネージャーに同様のユーザーアクセスを設定する場合，幾つかの方法を使用して設定することもできますが，大部分の場合，各NNMi管理サーバーにカスタム設定する必要があります。

ヒント

グローバルマネージャーにすべてのテナントとセキュリティグループを定義します。nnmconfigexport.ovpl -c securityを使用して，テナントとセキュリティグループ定義をエクスポートします。各リージョナルマネージャーで，nnmconfigimport.ovplを使用してテナントとセキュリティグループ定義をインポートします。あるいは，nnmsecurity.ovplコマンドを使用して，別のNNMi管理サーバーのUUIDと同じUUIDを使用して，テナントおよびセキュリティグループを作成できます。この推奨手順に従うことで，グローバルネットワーク管理環境内で，各テナントとセキュリティグループのUUIDを同じにできます。

ユーザーがグローバルマネージャーからNPSレポートを開始する場合，このベストプラクティスは設定の必須部分になります。

テナントUUIDは一意である必要がありますが，テナント名は再利用できます。NNMiは，名前が同じでUUIDが異なる2つのテナントを，共有設定を持たない2つの別個のテナントであると見なします。

組織ごとに1つのリージョナルマネージャーをセットアップする場合は，リージョナルマネージャーのすべてのノードを1つのテナントに入れられます。ただし，各リージョナルマネージャーに一意のテナントを設定し，グローバルマネージャーでトポロジデータが確実に分離されるようにしてください。

リージョナルマネージャーからグローバルマネージャーに転送されたインシデントに，セキュリティ情報とテナント情報を伝達する幾つかの追加カスタムインシデント属性（CIA）が含まれる場合があります。

このようなインシデントのソースオブジェクトがデフォルトテナント以外のテナントに属している場合，転送されるインシデントには次のCIAが含まれます。

cia.tenant.name

cia.tenant.uuid

このようなインシデントのソースオブジェクトが［デフォルトのセキュリティグループ］以外のセキュリティグループに属している場合，転送されるインシデントには次のCIAが含まれます。

cia.securityGroup.name

cia.securityGroup.uuid

14.5.1　グローバルネットワーク管理にセキュリティおよびマルチテナントの初期設定をする

グローバルネットワーク管理の初期設定後，リージョナルマネージャーは，グローバルネットワーク管理の設定に従って，リージョナルトポロジ内のノードに関する情報を使用して，グローバルマネージャーを更新します。

デフォルトテナントだけとのトポロジの同期

カスタムセキュリティグループとデフォルトテナントを持つグローバルネットワーク管理環境の場合，グローバルマネージャーでは，リモートで管理されているすべてのノードが，次の設定でグローバルマネージャートポロジに追加されます。

デフォルトテナント

デフォルトテナントの［初期検出セキュリティグループ］として設定されるセキュリティグループ。

カスタムテナントとのトポロジの同期

カスタムセキュリティグループとカスタムテナントを持つグローバルネットワーク管理環境の場合，グローバルマネージャーでは，リモートで管理されているすべてのノードが，そのノードに割り当てられているテナントのUUIDを使用して，グローバルマネージャートポロジに追加されます。そのテナントUUIDがグローバルマネージャーにない場合，次のように，グローバルネットワーク管理プロセスによってグローバルマネージャーのNNMi設定にテナントが作成されます。

テナントUUIDは，リージョナルマネージャーの場合と同じ値です。

テナント名は，リージョナルマネージャーの場合と同じ値です。

［初期検出セキュリティグループ］の値は，テナントと同じ名前のセキュリティグループに設定されます。なお，セキュリティグループがグローバルマネージャーにない場合，NNMiによってそのセキュリティグループが作成されます。

グローバルマネージャーのトポロジにノードが追加されると，そのノードは，グローバルマネージャーに設定されたテナントUUIDに対応する［初期検出セキュリティグループ］に割り当てられます。このため，グローバルマネージャー上でのセキュリティグループの関連づけは，リージョナルマネージャー上でのセキュリティグループの関連づけから独立しています。

ヒント

グローバルマネージャーでのセキュリティ設定を簡素化するための推奨を次に示します。

各リージョナルマネージャーによって管理されるノードのスプレッドシート，またはそのほかのレコードを保持します。ノードごとに，リージョナルマネージャーとグローバルマネージャーのそれぞれに必要なセキュリティグループをメモしておきます。グローバルネットワーク管理の設定が完了したら，nnmsecurity.ovplコマンドを使用して，セキュリティグループの割り当ての確認および更新をします。

グローバルネットワーク管理環境で，複数のリージョナルマネージャーによって1つのグローバルマネージャーが更新されている場合，そのグローバルマネージャーに対してグローバルネットワーク管理の設定を有効にするには，各リージョナルマネージャーから1つずつ設定してください。

各リージョナルマネージャーをグローバルネットワーク管理の設定に追加する前に，デフォルトテナント（またはカスタムテナント）の［初期検出セキュリティグループ］の値を変更できます。これを実行した場合，以前に設定されたリージョナルマネージャーのトポロジに新しいノードが追加されると，さまざまな結果が生じるおそれがあることに注意してください。

グローバルネットワーク管理を有効にする前に，グローバルマネージャー上で，リージョナルマネージャーで使用される各テナントの［初期検出セキュリティグループ］を，オペレータがアクセスできない専用セキュリティグループに設定してください。これによって，グローバルマネージャー上の管理者は，ほかのNNMiコンソールオペレータのために，ノードを適切なセキュリティグループに明示的に移動しなくてはならなくなります。

14.5.2　セキュリティおよびマルチテナントの割り当てのグローバルネットワーク管理への影響

次の表は，リージョナルマネージャーでのノードのテナントまたはセキュリティグループの割り当てへの変更が，グローバルマネージャーにどのように影響を及ぼすかを示しています。

表14‒6　リージョナルマネージャーでの設定変更がグローバルマネージャーに及ぼす影響

アクション

影響

リージョナルマネージャーで，ノードを別のテナントに割り当てる。

グローバルマネージャーのノードは，その別のテナントに割り当てられるように変更されます。テナントUUIDがグローバルマネージャーにない場合は作成されます。

リージョナルマネージャーで，ノードを別のセキュリティグループに割り当てる。

グローバルマネージャーでは変更されません。NNMi管理者は，その変更を手動で複製するように選択できます。

リージョナルマネージャーで，テナントの設定（名前，説明，または初期検出セキュリティグループ）を変更する。

グローバルマネージャーでは変更されません。NNMi管理者は，その変更を手動で複製するように選択できます。

リージョナルマネージャーで，セキュリティグループの設定（名前または説明）を変更する。

グローバルマネージャーでは変更されません。NNMi管理者は，その変更を手動で複製するように選択できます。

15　グローバルネットワーク管理

この章では，グローバルネットワークを管理する方法について説明します。

15.1　グローバルネットワーク管理の前提条件

グローバルネットワーク管理機能を利用する場合，グローバルネットワーク管理を構成するNNMi管理サーバーは同じバージョン・リビジョンである必要があります（リビジョンまで同じ必要があります）。修正版のバージョンは同じである必要はありません。

15.2　グローバルネットワーク管理の利点

NNMiを地理的位置が異なる複数のNNMi管理サーバーに導入しているとします。各NNMi管理サーバーでは，検出と監視のニーズに合うように，ネットワークの検出および監視を行っています。こうした既存のNNMi管理サーバーと設定を使用して，特定のNNMi管理サーバーをグローバルマネージャーとして指定することで，新たな検出を追加したり監視の設定を変更したりせずに，集約したノードオブジェクトデータを表示できます。

NNMiグローバルネットワーク管理機能で，地理的位置が異なるネットワークを管理しながら，複数のNNMi管理サーバーを連携させることができます。特定のNNMi管理サーバーをグローバルマネージャーとして指定し，複数のリージョナルマネージャーを集約したノードオブジェクトデータを表示します。

NNMiグローバルネットワーク管理機能には，次の利点があります。

グローバルマネージャーから見た，企業のネットワークの全体像を表示できます。

次のように容易に設定できます。

リージョナルマネージャーの管理者はそれぞれ，すべてのノードオブジェクトデータを指定するか，またはグローバルマネージャーレベルで参加する特定のノードグループを指定します。

各グローバルマネージャーの管理者は，情報の提供を許可するリージョナルマネージャーを指定します。

各サーバーごとに，インシデントの生成と管理を行うことができます（各サーバーで使用可能なトポロジのコンテキスト内で生成されます）。

詳細については，NNMiヘルプの「NNMiのグローバルネットワーク管理機能 (NNMi Advanced)」を参照してください。

動的ネットワークアドレス変換（NAT），動的ポートアドレス変換（PAT），または動的ネットワークアドレスおよびポート変換（NAPT）の各グループには，NNMiグローバルネットワーク管理設定全体で一意のテナントに加え，NNMiリージョナルマネージャーが必要です。詳細については，「13.　NAT環境の重複IPアドレスの管理」およびNNMiヘルプを参照してください。

15.3　グローバルネットワーク管理の適用を検討する

15.3.1　複数サイトのネットワークを継続的に監視する

ITグループは，複数のサイトに配備されているネットワーク機器を週7日，24時間体制で管理している場合，NNMiのグローバルネットワーク管理機能を使用すれば，トポロジとインシデントを集約して表示し，監視できるようになります。

15.3.2　重要なデバイスを選択して監視する

複数の場所に配備された重要デバイスのステータスとインシデントを，1つのNNMi管理サーバーで表示できる場合，リージョナルマネージャーに転送フィルタを設定します。このフィルタによって，リージョナルマネージャーからグローバルマネージャーに送信するノードオブジェクトデータを選択できます。例えば，リージョナルマネージャーに対し転送フィルタを設定して，重要デバイスに関する情報だけをグローバルマネージャーに転送するようにできます。

15.3.3　ライセンスを考慮する

グローバルマネージャーとして使用するNNMi管理サーバーには，NNMi Advancedライセンスを購入してインストールする必要があります。NNMi管理サーバーをリージョナルマネージャーとして使用する場合は，NNMi Advancedライセンスは必要ありません。

グローバルネットワーク管理機能を使用しながら，グローバルマネージャーに必要な新しいライセンスの数を抑えることができます。例えば，ITグループが複数のサイトに配備された重要な装置を監視する必要がある場合は，リージョナルマネージャーに転送フィルタを設定して，グローバルマネージャーに重要な装置に関する情報だけが転送されるようにできます。このようなフィルタ設定を使用することで，既存のグローバルマネージャーのライセンスを最大限に活用し，NNMiへの投資をむだなく使用できます。

ライセンスを取得したノードの総数がグローバルマネージャーのNNMi Advancedライセンスより多くなるように，リージョナルマネージャー用にNNMiライセンスを増やします。グローバルマネージャーには，すべての領域のすべてのノードの完全なインベントリがありません。グローバルマネージャーをすべてのリージョナルマネージャーと同期させて，ライセンスが不十分だったために前回省略したノードを検索して作成する場合，グローバルマネージャーで十分なNNMi Advancedライセンスを購入してインストールし，リージョナルマネージャーでインストールしたライセンス総数を上回るようにする必要があります。

十分なライセンスをインストールしたら，次のどちらかの方法で対処します。

すべてのリージョナルマネージャーで設定されている，すべての再検出間隔の時間が経過して，すべての領域ですべてのノードが再検出されるまで待ちます。リージョナルマネージャーは，すべての領域ですべてのノードを再検出したら，再検出されたノードの情報をグローバルマネージャーに送信します。

グローバルマネージャーはこのノード情報を受信し，各領域でノードごとにグローバルノードを作成します。

各リージョナルマネージャーでnnmnoderediscover.ovpl -allスクリプトを実行します。

メモ

2番目の方法では，ネットワーク上のトラフィックが増加し，NNMiマネージャーのセット全体から多くのNNMiリソースが消費されることにもなります。このオプションは，最初のNNMi検出ほどリソースの多くを消費しませんが，最初の検出を実行することに似ています。最適な方法では，ある程度の時間をおくか，現在のリージョナルマネージャーの負荷が減って正常になるのを待ち，領域ごとに間隔をおいてスクリプトを実行してから，次のリージョナルマネージャーの再検出を始めます。

15.4　実践的なグローバルネットワーク管理の例

次の図を参照してください。地理的位置が異なる2つの運用サイトがあるとします。本社は，運用サイトとは別の地理的位置にあります。つまり，全部で3か所でNNMi管理サーバーが機能しています。

本社のIT担当者が，ローカルネットワーク機器およびリージョナルサイト1と2の両方に配備された重要ネットワーク機器を，ネットワークの観点から監視する必要があります。リージョナルサイト1と2両方のIT担当者は，それぞれのサイトに配備されている重要なネットワーク機器を監視する必要があります。

図15‒1　ネットワークの例

15.4.1　要件のレビュー

本社，リージョナルサイト1，リージョナルサイト2のNNMi管理サーバーが，それぞれのサイトに配備された複数のルーターとスイッチを管理すると想定します。この例では，NNMi管理サーバーをそれぞれglobal1，regional1およびregional2と呼びます。それぞれの場所に配備された重要なスイッチとルーターの検出と監視を行うようにNNMi管理サーバーを設定したとします。グローバルネットワーク管理機能を使用するために，これらのサイトにあるNNMi管理サーバーでの検出を再設定する必要はありません。

メモ

グローバルネットワーク管理機能の設定中，nnmbackup.ovplスクリプトを使って1つのNNMi管理サーバーをバックアップし，nnmrestore.ovplスクリプトを使ってこのバックアップを第2のNNMi管理サーバーに復元し，この両方のNNMi管理サーバーをリージョナルNNMi管理サーバーに接続することはしないでください。あるNNMi管理サーバーから2番目のNNMi管理サーバーにバックアップデータを配置すると，これらの両方のサーバーに同じデータベースUUIDが存在することになります。NNMiを第2のNNMi管理サーバーに復元したあと，元のNNMi管理サーバーからNNMiをアンインストールする必要があります。

本社ITグループでは，リージョナルサイト1と2に配備された重要な機器だけの監視を行い，ほかのデバイスの管理はしない予定です。次の表に，監視のニーズをまとめます。

表15‒1　グローバルネットワーク管理のネットワーク要件

サイト

NNMi管理サーバー

重要なスイッチ

管理するリージョナル機器

本社

global1

15台のHP ProCurve 2620 Switch

各リージョナルサイトのHP ProCurve 2620 Switch

すべて

リージョナルサイト1

regional1

15台のHP ProCurve 2620 Switch

該当なし

リージョナルサイト2

regional2

15台のHP ProCurve 2620 Switch

該当なし

要約すると，NNMi管理サーバーglobal1が本社を監視し，NNMi管理サーバーregional1とregional2が，各リージョナルサイトを監視しています。リージョナルサイト1と2に配備されたHP ProCurve 2620 Switchのインシデントとデバイス情報を，本社で表示する必要があります。この例では，regional1とregional2の両方で，リージョナルサイト1に配備された複数の共通スイッチを管理しています。

(1)　リージョナルマネージャーとグローバルマネージャーの接続

グローバルネットワーク管理接続を設定するときに，次の情報を考慮します。

NNMiでは，リージョナルマネージャーと通信する1つ以上のグローバルマネージャーを設定できます。例えば，regional1と通信するために第2のグローバルマネージャー，global2が必要な場合，NNMiでは，regional1と通信するglobal1とglobal2の両方を設定できます。詳細については，リリースノートを参照してください。

グローバルネットワーク管理は，1つの接続レイヤーで動作します。例えば，この章の例では，1つの接続レイヤー，regional1と通信するglobal1とregional2と通信するglobal1について検討します。NNMiは，複数の接続レベルを設定しないでください。例えば，global1はregional1と通信し，かつregional1がregional2と通信するようには設定しないでください。グローバルネットワーク管理機能は，この3つのレイヤー設定用に設計されていません。

2つのNNMi管理サーバーは，相互に両方向に通信する設定にはしないでください。例えば，global1がregional1と通信し，かつregional1がglobal1と通信するようには設定しないでください。

15.4.2　初期準備

(1)　ポート可用性：ファイアウォールの設定

グローバルネットワーク管理機能が正しく機能するためには，global1からregional1とregional2へのTCPアクセス用に，特定のウェルノウンポートが開いているかどうかを確認する必要があります。NNMiインストールスクリプトでは，デフォルトとしてポート20480，20481を設定します。ただし，インストール中にこの値は変更できます。

メモ

ここで説明した例では，global1がregional1とregional2へのTCPアクセスを確立します。ファイアウォールは，一般的に接続を開始するサーバーに基づいて設定されます。global1がregional1とregional2への接続を確立すると，トラフィックは両方向に流れます。

現在の値を確認したりポート設定を変更したりするには，次のファイルを編集します。

Windows：%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：$NNM_CONF/nnm/props/nms-local.properties

次の表に，アクセス可能にしておく必要があるウェルノウンポートを示します。

表15‒2　アクセス可能にしておく必要があるソケット

セキュリティ

パラメーター

TCPポート

非SSL

nmsas.server.port.web.http

20480

nmsas.server.port.hq

4457

SSL

nmsas.server.port.web.https

20481

nmsas.server.port.hq.ssl

4459

(2)　証明書の設定

global1と2つのリージョナルNNMi管理サーバー（regional1とregional2）間で安全な通信プロトコルによるグローバルネットワーク管理機能を使用する場合は，証明書を設定する必要があります。NNMiのインストール中，NNMiインストールスクリプトでは，ほかのエンティティに対して自身を識別できるよう，NNMi管理サーバーに自己署名証明書を作成します。使用するNNMi管理サーバーには，正しい証明書を持つグローバルネットワーク管理機能を設定する必要があります。「10.3.7　グローバルネットワーク管理環境での証明書の使用」に示した手順を実行してください。

バージョン11-50にアップグレードされたNNMi管理サーバー

現在使用している複数のNNMi管理サーバーのうち，一部が以前のバージョンのNNMiからNNMi 11-50にアップグレードしたもので，一部が新たにインストールしたNNMi 11-50インスタンスである場合は，GNMを設定する前に追加的な設定タスクを実行する必要があります。

NNMi 11-50より前のバージョンでは，NNMiは証明書を保存するためにJava KeyStore (JKS) リポジトリを提供していました。NNMi 11-50では，証明書を保存するためにPublic Key Cryptography Standards (PKCS) #12リポジトリが導入されています。NNMi 11-50の新しいインスタンスをシステムにインストールすると，新しいPKCS #12ファイルベースの証明書管理方法を利用できます。

ただし，古いバージョンのNNMiをバージョン11-50にアップグレードした場合，PKCS #12ファイルベースの証明書管理はすぐには利用できず，NNMiでは証明書管理にJKSリポジトリが引き続き使用されます。

このような環境でGNMを設定する場合は，事前に「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従い，アップグレードしたすべてのNNMi管理サーバーでPKCS #12ファイルベースの証明書管理方法を使用するように設定を行ってください。

(3)　NNMi管理サーバー規模の考慮事項

この例では，グローバルネットワーク管理設定で既存のNNMi管理サーバーを使用することを想定しています。

NNMiのインストールが必要となるサーバーのサイズに関する具体的な情報については，リリースノートを参照してください。

(4)　システムクロックの同期化

global1，regional1，およびregional2サーバーをグローバルネットワーク管理設定に接続する前に，これらのNNMi管理サーバークロックを同期化することが重要です。グローバルネットワーク管理（グローバルマネージャーとリージョナルマネージャー）やシングルサインオン（SSO）に属するネットワーク環境内のすべてのNNMi管理サーバーは，それぞれの内部タイムクロックを世界標準時で同期化する必要があります。例えば，LinuxツールのNetwork Time Protocol Daemon（NTPD）や使用可能なWindowsオペレーティングシステムツールなどの時刻の同期プログラムを使用します。詳細については，NNMiヘルプの「クロック同期化の問題 (SSO / グローバルネットワーク管理)」または「グローバルネットワーク管理をトラブルシューティングする」と「15.11.2　クロック同期」を参照してください。

メモ

サーバークロック同期の問題など，リージョナルマネージャーとの接続に問題がある場合，NNMiではNNMiコンソールの下部に警告メッセージが表示されます。

(5)　グローバルネットワーク管理で自己署名証明書を使用する場合のアプリケーションフェイルオーバー機能の使用法

アプリケーションフェイルオーバー設定で，自己署名証明書を使用したグローバルネットワーク管理機能を使用する場合は，追加の手順を実行する必要があります。

(6)　グローバルネットワーク管理での自己署名証明書の使用法

グローバルネットワーク管理機能で自己署名証明書を使用する場合は，追加の手順を実行する必要があります。「10.3.7　グローバルネットワーク管理環境での証明書の使用」を参照してください。

(7)　グローバルネットワーク管理での認証機関の使用法

グローバルネットワーク管理機能で認証機関を使用する場合は，追加の手順を実行する必要があります。「10.3.7　グローバルネットワーク管理環境での証明書の使用」を参照してください。

(8)　監視する重要な機器の一覧作成

各リージョナルマネージャーによって管理され，グローバルマネージャーからモニタリングされる機器のリストを作成します。例えば，global1からモニタリングされるregional1とregional2の管理対象機器リストを作成します。この情報を転送フィルターで使用します。詳細については，「15.5　リージョナルマネージャーで転送フィルタを設定する」を参照してください。

regional1とregional2からglobal1に転送する情報を制限した場合に得られる結果については，慎重に考慮する必要があります。計画を立てるときに，次の点を考慮してください。

global1で完全な分析を行って正確なインシデントを生成するには，regional1とregional2から得られる完全なトポロジが必要になるため，除外するデバイスが多くなり過ぎないように注意します。

重要ではないデバイスを除外すると，global1のシステムパフォーマンスコストを節約できます。

重要ではないデバイスを除外すると，ソリューションの全体的な拡張性が改善され，NNMiで必要となるネットワークトラフィックを削減できます。

(9)　グローバルマネージャーとリージョナルマネージャーの管理ドメインの検討

リージョナルマネージャーからグローバルマネージャーに転送する情報を決定するために，グローバルマネージャーとリージョナルマネージャーの管理ドメインを検討します。

この例では，NNMi管理サーバーglobal1，regional1，およびregional2は，独自のノードセットを管理しています。この例では，あとでregional1とregional2からglobal1に，それぞれが管理する機器に関する情報を転送するよう設定します。

次の手順に従って，global1，regional1，およびregional2が現在監視している機器を確認します。機器を確認しておくと，regional1とregional2からglobal1に転送する重要な機器を選択するときに役立ちます。

この例では，次の手順を実行してこの情報を確認します。

ブラウザでglobal1のNNMiコンソールを指定する。

サインインする。

［インベントリ］ワークスペースをクリックする。

このワークスペースでglobal1が現在監視していて検出されたインベントリを確認できる。

ブラウザでregional1のNNMiコンソールを指定する。

サインインする。

［インベントリ］ワークスペースをクリックする。

regional1が監視しているノードを確認し，global1で監視するデバイスの一覧を作成する。

ブラウザでregional2のNNMiコンソールを指定する。

サインインする。

［インベントリ］ワークスペースをクリックする。

regional2が監視しているノードを確認し，global1で監視するデバイスの一覧を作成する。

(10)　NNMiヘルプトピックの確認

グローバルネットワーク管理に関するすべてのヘルプトピックを確認するには，次の手順を実行します。

NNMiヘルプで，［検索］をクリックする。

［検索］フィールドに「グローバルネットワーク管理」と入力する。

［検索］をクリックする。

この検索によって，グローバルネットワーク管理に関連する50以上のトピックが見つかります。

15.5　リージョナルマネージャーで転送フィルタを設定する

この例では，global1はregional1とregional2の両方と通信します。グローバルマネージャーglobal1がリージョナルマネージャーregional1とregional2から受け取るノードオブジェクトデータを制御するには，regional1とregional2の両方で転送フィルタを設定する必要があります。

15.5.1　転送されるノードを制限する転送フィルタを設定する

この例では，HP ProCurve 2620 Switchのノード情報だけをregional1からglobal1に転送できるノードグループを作成します。新しいノードグループを作成し，グループに制限を設定するには，次の手順を実行します。

NNMiコンソールのregional1の［設定］＞［オブジェクトグループ］から，［ノードグループ］をクリックする。

［新規作成］をクリックする。

メモ

この例では，ノードフィルタの新規作成し，そのフィルタを使用してregional1とregional2の転送フィルタを作成する方法を説明していますが，既存のフィルタを使用して，リージョナルNNMi管理サーバーからグローバルNNMi管理サーバーへの転送フィルタを設定することもできます。

独自のデバイスもフィルタも含まれていないコンテナノードグループを作成して，子ノードグループを指定できます。この方法を使用すると，1つのコンテナノードグループを使用して，ノードオブジェクトデータをグローバルNNMi管理サーバーに転送できます。

フィルタ名として名前フィールドにglobal1と入力し，［注］フィールドに作成するフィルタの説明を入力する。

［デバイスフィルター］タブで［新規作成］アイコンをクリックして，［ノードデバイスフィルター］フォームを開く。

プルダウンメニューを使用して，［デバイスのカテゴリ］では［スイッチ-ルーター］，［デバイスのベンダー］では［Hewlett-Packard］，および［デバイスのファミリー］では［HP ProCurve 2620 Fixed-port Switch］を選択する。

プルダウンメニューから，［クイック検索］をクリックして，［デバイスのプロファイル］フォームを開く。

HP ProCurve 2620 Switchのプロファイルを検索して選択し，［OK］をクリックする。

設定フォームごとに，［保存して閉じる］をクリックする。

このフィルタをテストするため，［global1］を選択する。

［アクション］＞［ノードグループの詳細］メニューから，［メンバーの表示］をクリックする。

NNMiではすでにHP ProCurve 2620 Switchが1つ検出されている。これは，作成したフィルタが，設定した特定のスイッチモデルを検索していることを示している。次のステップでは，今作成したこのノードフィルタを使用して転送フィルタを設定する。

NNMiコンソールのregional1の［設定］ワークスペースから，［グローバルネットワーク管理］をクリックする。

［転送フィルター］タブをクリックする。

［クイック検索］をクリックする。

［global1］フィルタを選択し，［OK］をクリックする。

［保存して閉じる］をクリックする。

これで，regional1の転送フィルターの設定作業は完了です。regional2についても手順1.から手順16.を実行し，「15.6　グローバルマネージャーとリージョナルマネージャーを接続する」の説明に従って，global1をregional1とregional2に接続します。

15.6　グローバルマネージャーとリージョナルマネージャーを接続する

この例では，regional1とregional2の両方で，共通のスイッチを複数管理します。

この共通のスイッチ情報をregional1かglobal1に転送するには，必要な接続を設定する必要があります。

そのためには，global1を先にregional1に接続してからregional2に接続する必要があります。この接続順によって，global1はregional1をこれらの共通スイッチの監視を行うNNMi管理サーバーであると見なし，regional2から受け取るこれらの共通スイッチに関する情報を無視します。

メモ

この機能の動作を理解するには，まずは小さな規模で使用してから，それぞれのネットワーク管理ニーズに合わせて拡張することを推奨します。

global1を先にregional1に接続し，次にregional2に接続するには，次の手順を実行します。

先ず，NNMi管理サーバーのクロックをglobal1，regional1，およびregional2と同期してから，グローバルネットワーク管理設定内のこれらのサーバーを接続する。

詳細については，NNMiヘルプの「クロック同期化の問題 (SSO / グローバルネットワーク管理)」を参照してください。

メモ

サーバークロック同期の問題など，リージョナルマネージャーとの接続に問題がある場合は，NNMiでは警告メッセージが表示されます。

global1からregional1への接続を設定する。

a　global1のNNMiコンソールで，［設定］ワークスペースの［グローバルネットワーク管理］をクリックします。

b　［リージョナルマネージャ接続］をクリックします。

c　［新規作成］アイコンをクリックして，リージョナルマネージャーを新規作成します。

d　regional1の名前と説明情報を追加します。

e　［接続］タブをクリックします。

f　［新規作成］アイコンをクリックします。

g　regional1の接続情報を追加します。

メモ

このフォームの実行に関する個別の情報については，NNMiヘルプの「グローバルマネージャー: リージョナルマネージャーに接続する」を参照してください。

h　各設定フォームで［保存して閉じる］をクリックし，変更を保存します。

global1からregional2への接続を確立するため，手順2.のaからhまでを実行する。

15.7　global1からregional1とregional2への接続ステータスを確認する

global1からregional1およびregional2への接続の状態を確認するには，次の手順を実行します。

global1のNNMiコンソールで，［設定］ワークスペースの［グローバルネットワーク管理］をクリックする。

［リージョナルマネージャ接続］タブをクリックする。

regional1とregional2の接続ステータスを確認する。

［接続済み］と表示されたら，正しく機能していることを意味します。

詳細については，NNMiヘルプの「リージョナルマネージャーとの接続状態を確認する」を参照してください。

NNMiが検出を完了するまで，次のセクションには進まないでください。詳細については，「3.3.3　検出の進行状況を確認する」を参照してください。

15.8　global1のインベントリを確認する

NNMiが検出を完了するまで，このセクションは実行しないでください。詳細については，「3.3.3　検出の進行状況を確認する」を参照してください。

global1に転送されるノード情報regional1を表示するには，次の手順を実行します。

［インベントリ］ワークスペースに配置されている［管理サーバーのノード］フォームに，global1のNNMiコンソールから移動する。

スイッチnode102130に関する情報がregional1からglobal1に転送されたと仮定する。

regional1を選択すると，インベントリは次のように表示されます。

手順1.から手順2.を実行して，接続されているほかのリージョナルマネージャーからglobal1に転送されたデバイスインベントリも表示します。

15.9　global1とregional1との通信を切断する

（一時的または完全に）グローバルマネージャー（global1など）をシャットダウンするには，グローバルマネージャーとリージョナルマネージャー間の通信を切断する必要があります。

この例では，global1では対regional1のサブスクリプションがまだアクティブであると想定します。

global1とregional1間の通信を切断するには，次の手順を実行します。

global1のNNMiコンソールで，［設定］ワークスペースの［グローバルネットワーク管理］をクリックする。

［リージョナルマネージャ接続］をクリックする。

接続状態が［接続されています］であることを確認する。

接続状態が［接続されています］ではない場合，処理を続行する前に，NNMiヘルプの「グローバルネットワーク管理をトラブルシューティングする」を参照して問題を診断します。

regional1を選択して［開く］アイコンをクリックする。

［接続］をクリックして［regional1.xx.x.xx］を選択してから［削除］アイコンをクリックする。

［保存して閉じる］をクリックする。

［リージョナルマネージャ接続］タブでは，regional1の［名前］属性に注意する（大文字小文字は区別される）。

手順9.で，この［名前］属性が必要になります。

［保存して閉じる］をクリックする。

global1のコマンドラインで次のコマンドを入力する。

nnmnodedelete.ovpl -rm regional1 -u NNMiadminUserName -p
NNMiadminPassword

-rmには，手順7.で確認した名前を指定します。

これらのコマンドで，regional1から転送されたノードレコードをglobal1から削除する。

コマンドでは，regional1からglobal1に転送されたノードに関連するインシデントも閉じます。詳細については，NNMiヘルプの「リージョナルマネージャーとの接続を解除する」を参照してください。

regional1の設定レコードを削除するには，次を実行する。

a　［設定］ワークスペースをクリックします。

b　［グローバルネットワーク管理］フォームを選択します。

c　［リージョナルマネージャ接続］タブを選択します。

d　regional1を選択して［削除］アイコンをクリックします。

e　［保存して閉じる］をクリックして削除を保存します。

15.10　グローバルネットワーク管理の追加情報

15.10.1　検出とデータの同期化

ネットワーク管理者がネットワーク上のデバイスの追加，削除，または変更を行うと，regional1やregional2などのリージョナルサーバーはそうした変更を検出して，この章の例でのglobal1などのグローバルサーバーを更新します。regional1とregional2では，これらが管理するノードの管理モードに対して管理者が行う変更についてもglobal1に通知します。

メモ

整合性を保つため，regional1とregional2はデバイスの状態の変化を検出すると，global1を継続的に更新するので，グローバルサーバーとリージョナルサーバーの両方でノードの状態が同じに保たれます。

regional1またはregional2が管理するノードに関する情報をglobal1が要求するたびに，regional1またはregional2は要求された情報をglobal1に返します。global1からノードに直接要求することはありません。global1が検出を実行するとき，デバイスに対するSNMPクエリーは重複しません。

global1は，regional1またはregional2が検出を完了するたびに，regional1とregional2を同期します。NNMiはFDB（転送データベース）データを使用して，レイヤー2接続を計算します。FDBデータは非常にダイナミックなもので，特に，1つのグローバルサーバーに複数のリージョナルサーバーが接続しているような場合には，検出するごとに大きく異なります。

メモ

ユーザーが修正した属性やアプリケーションが修正した属性に対する変更は，グローバルサーバーでは同期中に更新されません。

［再検出間隔］は，各リージョナルサーバーで調整でき，global1とリージョナルマネージャーとの間の検出の精度を変更できます。［再検出間隔］が短くなるほど，検出の精度が上がり，NNMiが行うネットワークトラフィックも増えます。［再検出間隔］が長くなるほど，検出の精度は下がり，NNMiが行うネットワークトラフィックも減ります。これは，ネットワークが大きくなるほど，ユーザーが行う再検出の頻度が少なくなることを意味します。［再検出間隔］を設定するには，次の手順を実行します。

regional1またはregional2のNNMiコンソールから，［設定］ワークスペースの［検出］＞［検出の設定］をクリックする。

リージョナルサーバーで検出を開始する頻度に従い，［再検出間隔］を調整する。

グローバルサーバーは，リージョナルサーバーが検出を完了するとすぐに検出を開始します。

［保存して閉じる］をクリックする。

15.10.2　リージョナルマネージャーからグローバルマネージャーへのカスタム属性の複製

NNMiでは，リージョナルマネージャーでカスタム属性を設定して，それらのカスタム属性をグローバルマネージャーに複製できます。例えば，カスタム属性データをリージョナルマネージャーのノードに追加して，そのデータをグローバルマネージャーに複製したあとで，そのデータを使用してそれらのノードのインシデントを強化できます。

メモ

NNMiでは，リージョナルマネージャーからグローバルマネージャーにノードおよびインタフェースのカスタム属性を複製できます。

NNMiコンソールで，グローバルマネージャーの［カスタム属性の複製］タブ（［グローバルネットワーク管理］設定内）を使用してカスタム属性の複製を設定できます。

メモ

NNMiでは，ユーザーによる設定や入力を行わずに無番号インタフェースのカスタム属性が複製されます。詳細については，NNMiヘルプを参照してください。

15.10.3　デバイスに対するステータスポーリングまたは設定ポーリング

この例では，次の2つを前提としています。

リージョナルNNMi管理サーバーregional2は，Node Xを検出および管理する。

グローバルNNMi管理サーバーglobal1は，リージョナルNNMi管理サーバーregional2と接続する。

次の図を参照してください。

図15‒2　ノードのステータスポーリングまたは設定ポーリング

global1からNode Xのステータスをポーリングするには，次を実行します。

global1から，［インベントリ］ワークスペースの［ノード］をクリックする。

ノードインベントリからNode Xを選択する。

［アクション］＞［ポーリング］＞［ステータスのポーリング］メニュー項目を使用して，Node Xのステータスポーリングを要求する。

NNMi管理サーバーglobal1は，リージョナルNNMi管理サーバーregional2からのステータスポーリングを要求し，結果を画面に表示する。

ステータスポーリング要求は，global1とregional2のどちらから発行しても問題ありません。

ステータスポーリングの結果は同じものが表示されます。

global1でNode Xの最新の検出情報を取得するようにするには，次を実行してglobal1からNode Xの設定ポーリングを行います。

global1から，［インベントリ］ワークスペースの［ノード］をクリックする。

ノードインベントリからNode Xを選択する。

［アクション］＞［ポーリング］＞［設定のポーリング］メニュー項目を使用して，Node Xの設定ポーリングを要求する。

NNMi管理サーバーglobal1は，リージョナルNNMi管理サーバーregional2からの設定ポーリングを要求し，結果を画面に表示する。

設定ポーリング要求は，global1とregional2のどちらから発行しても問題はありません。設定ポーリングの結果は同じものが表示されます。

15.10.4　グローバルマネージャーでのデバイスステータスの判定とインシデントの生成

NNMi管理サーバーglobal1は，リージョナルマネージャーregional1とregional2からくるステータス変更をリッスンし，ローカルデータベースにあるステータスを更新します。

NNMi管理サーバーregional1とregional2のNNMi StatePollerサービスは，監視するデバイスの状態の値を計算します。global1は，regional1とregional2から状態の値の更新を受け取ります。global1は，自分が検出するノードにポーリングしますが，regional1とregional2によって管理されているノードにはポーリングしません。

regional1によって管理されているノードの管理モードを変更したあと，global1上の管理モードも変更されます。ネットワーク管理者がregional1またはregional2によって管理されるネットワーク機器の追加，削除，変更を行うと，regional1またはregional2はそれらのネットワークデバイスの変更についてglobal1を更新します。

global1は，regional1とregional2によって転送されてきたノードオブジェクトデータなど，独自のCausal Engineとトポロジを使用してインシデントを生成します。これは，生成するインシデントが，トポロジに違いがある場合に，regional1とregional2のインシデントとは少し異なる場合があることを意味します。

フィルタリングがglobal1の接続性に影響する可能性があるため，転送フィルタをregional1やregional2に使用することは避けた方がよいでしょう。ここで生じる差異が，global1と2つのリージョナル（regional1とregional2）との間の根本原因分析での差異になる可能性があります。ほとんどの場合，転送フィルタの使用しないことを選択すると，グローバルNNMi管理サーバーのトポロジは大きくなります。これは，より正確な根本原因分析の結果を得るのに役立ちます。

追加の設定をしないと，regional1はトラップをglobal1に転送しません。これを行うには，特定のトラップをglobal1に転送するようにregional1を設定する必要があります。グローバルマネージャーに過剰な負荷がかからないように，リージョナルマネージャーは量の少ない，重要なトラップを転送するよう設定することをお勧めします。NNMiは，転送されたトラップがTrapStormインシデントを引き起こすような場合，転送されたトラップを削除します。NNMiコンソールでTrapStorm 管理イベントの詳細を参照してください。

15.11　グローバルネットワーク管理のトラブルシューティングのヒント

15.11.1　NNMiヘルプのトラブルシューティング情報

グローバルネットワーク管理のトラブルシューティング情報については，NNMiヘルプの「グローバルネットワーク管理をトラブルシューティングする」を参照してください。

15.11.2　クロック同期

グローバルネットワーク管理（グローバルマネージャーとリージョナルマネージャー）やシングルサインオン（SSO）に属するネットワーク環境内のすべてのNNMi管理サーバーは，それぞれの内部タイムクロックを世界標準時で同期化する必要があります。例えば，LinuxツールのNetwork Time Protocol Daemon（NTPD）や使用可能なWindowsオペレーティングシステムツールなどの時刻の同期プログラムを使用します。

NNMiコンソールの下部に次のメッセージが表示される場合の対応は，次のとおりです。

NNMiのセルフモニタリングが問題を検出しました（警戒域）。詳細は，［ヘルプ］＞［システム情報］＞［ヘルス］を参照してください。

グローバルマネージャーのnnm.logファイルに次のメッセージがないか確認します。

致命的
[com.hp.ov.nms.topo.spi.server.bridge.BridgeConnectionSelectorImpl] <number of seconds>のクロックの違いにより、システム<server_name>には接続されません。リモート時間は、<date/time>です。

クロックが合っていないため，再同期化が必要です。

このメッセージがログに出力されて数分以内に，NNMiはリージョナルマネージャー接続を切断します。

また，NNMiセルフモニタリングが次の問題を検出します。

[警戒域] リージョナルマネージャー '<name>' への接続は停止しています。

15.11.3　グローバルネットワーク管理のシステム情報

グローバルネットワーク管理接続に関する情報を表示するには，［ヘルプ］＞［システム情報］を選択して［グローバルネットワーク管理］タブをクリックします。

15.11.4　グローバルマネージャーとリージョナルマネージャーの検出情報の同期

global1とregional2の間で情報に矛盾があることに気が付いた場合は，global1からnnmnoderediscover.ovplスクリプトを実行して，global1とregional2を同期します。実行の結果，regional2は新しい検出結果を使用してglobal1を更新します。

この例では，次の図に示すネットワークを使用します。

図15‒3　グローバルネットワーク管理

次のコマンドを実行してノードX，Y，およびZとglobal1を同期化します。

nnmnoderediscover.ovpl -u username -p password -rm regional2

詳細については，nnmnoderediscover.ovplのリファレンスページを参照してください。

次のことに注意してください。

NNMiは，手動再同期の後，トポロジ，状態，およびステータスを自動的に再同期します。

15.12　グローバルネットワーク管理環境でのNNMiのバージョンアップ手順

グローバルネットワーク管理環境で設定されているNNMi 管理サーバーをバージョンアップする場合は「24.3　NNMi 13-10からのグローバルマネージャーとリージョナルマネージャーのアップグレード」を参照してください。

15.13　グローバルネットワーク管理とアドレス変換プロトコル

動的ネットワークアドレス変換（NAT），動的ポートアドレス変換（PAT），または動的ネットワークアドレスおよびポート変換（NAPT）の各グループには，NNMiグローバルネットワーク管理設定全体で一意のテナントに加え，NNMiリージョナルマネージャーが必要です。「13.　NAT環境の重複IPアドレスの管理」を参照してください。NNMiヘルプも参照してください。

16　NNMi IPv6管理機能

IPv6管理機能を使用するには，NNMi Advancedライセンスを購入してインストールする必要があります。この章でのNNMiは，NNMi AdvancedライセンスがインストールされているNNMiを指します。NNMiのIPv6管理で，インタフェース，ノード，サブネットも含めたIPv6アドレスの検出と監視が可能になります。シームレスな統合を提供するため，NNMiはIPv4とIPv6両方のアドレスを含めるようIPアドレスモデルを拡張します。NNMiでは，可能なかぎりすべてのIPアドレスが等しく扱われます。IPv4アドレスに関連するほとんどの機能はIPv6アドレスについても使用できます。ただし，幾つか例外があります。NNMiコンソールに表示されるIPv6情報の詳細については，NNMiヘルプを参照してください。

16.1　NNMi IPv6管理機能の概要

NNMi IPv6管理機能には，次の機能があります。

IPv6専用デバイスおよびデュアルスタックデバイスのIPv6インベントリ検出

IPv6アドレス

IPv6サブネット

IPv6アドレス，サブネット，インタフェースおよびノード間の関連づけ

次のためのネイティブIPv6 SNMP通信

ノードの検出

インタフェースの監視

トラップと通知の受信と転送

デュアルスタックデバイスでのIPv4またはIPv6通信（管理アドレス）の自動選択

NNMiコンソールを使用し，［設定］ワークスペースの［通信の設定］で，SNMP管理アドレス設定をIPv4またはIPv6に設定します。

IPv6アドレスフォルト監視のためのネイティブICMPv6通信

IPv6アドレスまたはホスト名をシードに使用したデバイスの検出

IPv6レイヤー3隣接検出ヒントを使用したIPv6デバイスの自動検出

LLDP（Link Layer Discovery Protocol） IPv6隣接情報を使用するレイヤー2隣接検出ヒントを使用したIPv6デバイスの自動検出

IPv4，IPv6情報の統合表示

ノード，インタフェース，アドレス，サブネットおよび関連づけのインベントリビュー

IPv4デバイスとIPv6デバイス用のレイヤー2隣接ビューおよびトポロジマップ

IPv4デバイスとIPv6デバイス用のレイヤー3隣接ビューおよびトポロジマップ

インシデント，結果，根本原因分析

NNMiコンソールアクション：IPv6アドレスとノードに対するpingとtraceroute

IPv6アドレスとアドレス範囲を使用したNNMi設定

通信の設定

検出の設定

監視の設定

ノードとインタフェースグループ

インシデントの設定

IPv6インベントリとインシデント用のDTK Webサービスサポート

NNMi IPv6管理機能では，次はサポートしていません。

検出のためのIPv6 Pingスイープの使用

IPv6ネットワークパスビュー（Smart Path）

IPv6リンクローカルアドレス障害監視

検出シードとしてのIPv6リンクローカルアドレスの使用

16.2　NNMi IPv6管理機能を使用するための必要条件

管理サーバーの仕様およびNNMiのインストールの詳細については，リリースノートを参照してください。

ネイティブIPv6通信を使用するには，NNMi管理サーバーはデュアルスタックシステムであることが必要です。つまり，IPv4とIPv6両方を使用して通信するということです。

IPv6の追加要件は次のとおりです。

少なくとも1つのネットワークインタフェースでIPv4を有効化し設定する必要があります。

IPv6を有効にして管理する必要のある，IPv6ネットワークに接続する少なくとも1つのネットワークインタフェースで，リンクローカルユニキャストアドレス以外のユニキャストアドレス（例：グローバルユニキャストアドレス，ユニークローカルIPv6ユニキャストアドレス）を持つ必要があります。

NNMi管理サーバーにIPv6ルートを設定し，IPv6を使用してNNMiで検出と監視を行うデバイスとNNMiが通信できるようにする必要があります。

メモ

IPv4専用のNNMi管理サーバーを使用することもできますが，IPv4/IPv6デュアルスタックデバイスをNNMiで完全に管理することはできなくなります。例えば，IPv4専用管理サーバーを使用すると，NNMiはIPv6専用デバイスの検出，IPv6シードとヒントを使用した検出，およびIPv6アドレスを持つデバイス上での障害の監視はできません。

NNMi管理サーバーで使用されるDNSサーバーは，ホスト名からIPv6アドレスおよびIPv6アドレスからホスト名を名前解決する必要があります。つまり，DNSサーバーはホスト名を128ビットIPv6アドレスにマッピングする必要があります。IPv6対応DNSサーバーが使用できない場合でも，NNMiは正しく機能しますが，NNMiではIPv6アドレスを使用するノードのDNSホスト名の判定や表示は行いません。

16.3　NNMi IPv6管理機能を使用するためのライセンス

すでに説明したように，IPv6管理機能を使用するにはNNMi Advancedライセンスを購入してインストールする必要があります。NNMi Advancedライセンスの取得とインストールの詳細については，「2.　NNMiのインストールとアンインストール」を参照してください。

NNMi製品には，インスタントオンライセンス用パスワードが含まれています。これは一時的なものですが，有効なNNMi Advancedライセンスです。できるだけ早く，恒久ライセンスキーを入手してインストールしてください。

16.4　NNMi IPv6管理機能がサポートする環境

NNMiをサポートするオペレーティングシステム構成の詳細については，リリースノートを参照してください。

16.4.1　NNMi管理サーバーの種類とサポートする機能

次の表に，IPv4専用およびデュアルスタック両方のNNMi管理サーバーの機能を示します。

表16‒1　管理サーバーの機能

機能

IPv4専用

デュアルスタック

IPv4通信（SNMP，ICMP）

対応

対応

IPv6通信（SNMP，ICMPv6）

非対応

対応

デュアルスタック管理ノード

対応

対応

IPv4シードを使用した検出

対応

対応

IPv6シードを使用した検出

非対応

対応

IPv4アドレスおよびサブネットインベントリ

対応

対応

IPv6アドレスおよびサブネットインベントリ

対応

対応

SNMPを使用したインタフェースステータスとパフォーマンス

対応

対応

ICMPを使用したIPv4アドレスステータス

対応

対応

ICMPv6を使用したIPv6アドレスステータス

非対応

対応

IPv6専用管理ノード

非対応

対応

IPv4専用管理ノード

対応

対応

16.4.2　IPv6をサポートしているSNMP MIB

NNMiでは，IPv6用の次のSNMP MIBがサポートされています。

RFC 4293（現在のIETF標準）

RFC 2465（元のIETF提案）

Cisco IP-MIB

16.5　NNMiのインストールとIPv6管理機能の有効化

NNMiのインストール中に，インストールスクリプトがIPv6機能をアクティブにします。ただし，必要に応じてnms-jboss.propertiesファイルを編集し，これらのIPv6機能を手動で非アクティブにできます。

非アクティブにしたあとで，IPv6機能を再度アクティブにできます。詳細については，「16.6　IPv6管理機能を無効にする」および「16.7　IPv6管理機能を再度有効にする」を参照してください。

16.6　IPv6管理機能を無効にする

次のどちらかの方法を使用して，管理上IPv6機能を無効化できます。

nms-jboss.propertiesファイルのIPv6マスタースイッチをオフにし，NNMiを再起動する。

NNMi Advancedライセンスを期限切れにするか，または基本NNMiライセンスに置き換える。

1の方法で管理上IPv6機能を無効化する手順は，次のとおりです。

nms-jboss.propertiesファイルを開く。

次の場所を探してください。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

NNMiでは，各プロパティの完全な記述を用意しており，nms-jboss.propertiesファイルのコメントとして示しています。

NNMiのIPv6通信を非アクティブ化するには，次の手順を実行する。

a　# Enable Java IPv6 Communicationで始まるテキストを探します。

b　次の行を見つけます。

　java.net.preferIPv4Stack=false

c　この行を次のように編集します。

　java.net.preferIPv4Stack=true

　行がコメント化されていないことを確認します。

NNMiでIPv6管理全体を非アクティブ化するには，次の手順を実行する。

a　# Enable NNMi IPv6 Managementで始まるテキストを探します。

b　次の行を見つけます。

　com.hp.nnm.enableIPv6Mgmt=true

c　この行を次のように編集します。

　com.hp.nnm.enableIPv6Mgmt=false

　行がコメント化されていないことを確認します。

d　nms-jboss.propertiesファイルを保存して閉じます。

次のコマンドを実行して，NNMiを再起動する。

　ovstop
　ovstart

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

次のコマンドを使用して，NNMiプロセスを確認する。

　ovstatus -v ovjboss

次のセクションでは，IPv6を無効化したあとのNNMiの動作とインベントリのクリーンアップについて説明します。

16.6.1　IPv6管理機能を無効にしたあとのIPv6監視

IPv6管理またはIPv6通信が完全に無効になると，StatePollerサービスはICMPv6によるIPv6アドレスの監視をすぐに停止します。NNMiは，これらのアドレスのIPアドレス状態を［未ポーリング］に設定します。アドレスを選択し，このアドレスに対して［アクション］＞［設定の詳細］＞［モニタリングの設定］を使用すると，関連する［モニタリングの設定］ルールで［IPアドレス障害のポーリングを有効にする］が有効になっている場合でも，NNMiは「ICMPポーリングの管理アドレス : false」と表示します。

16.6.2　IPv6管理機能を無効にしたあとのIPv6インベントリ

一度NNMiが完全にIPv6インベントリを検出すると，次の場合には，NNMiにそのインベントリを自動的に消去させることができます。

マスターIPv6スイッチをオンにしたあとで，オフにしてNNMiを再起動した。

NNMiはIPv6インベントリをすぐに削除しません。NNMiはSNMPノードのIPv6インベントリを次の検出サイクルで削除します。ただし，管理アドレスがIPv6アドレスであったノードの場合，管理アドレスがIPv6アドレスのまま残ります。また，NNMiはSNMP IPv6でないノードを削除しません。IPv6データが残ったノードは，NNMiインベントリから手動で削除する必要があります。

16.6.3　IPv6インベントリクリーンアップ時の既知の問題点

IPv6インベントリが残る場合があります。例えば，NNMiがSNMPを使用して，あるIPv6ノードを正常に管理し，次の検出の前にそのノードにアクセスできなくなったような場合です。既存の検出システムの設計上，検出プロセスはSNMPを使用した通信ができなくなったノードを更新できません。このようにして残ったノードを削除するには，通信の問題を解決してから，NNMiコンソールの［アクション］＞［ポーリング］＞［設定のポーリング］コマンドを使用してそれらのノードの設定情報を取得する必要があります。ネイティブIPv6ノードの場合，NNMiコンソールから直接ノードを削除します。

16.7　IPv6管理機能を再度有効にする

IPv6専用デバイスの検出やIPv6アドレスステータスの監視など，IPv6通信を必要とする機能では，NNMi管理サーバーにIPv6グローバルユニキャストアドレスが設定され機能を果たすことが必要です。

次に示す手順で非アクティブにしたあとで，IPv6機能を再度アクティブにする方法を説明します。

nms-jboss.propertiesファイルを編集する。

次の場所を探してください。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

NNMiでは，各プロパティの完全な記述を用意しており，nms-jboss.propertiesファイルのコメントとして示しています。

# Enable NNMi IPv6 Managementで始まるテキストを探す。

NNMiでIPv6通信を有効化するには，次のプロパティをコメント解除する。

java.net.preferIPv4Stack=false

プロパティをコメント解除するには，行の先頭から#!文字を削除します。

# Enable NNMi IPv6 Managementで始まるテキストを探す。

NNMiでIPv6通信全体を有効化するには，次のプロパティをコメント解除する。

com.hp.nnm.enableIPv6Mgmt=true

nms-jboss.propertiesファイルを保存して閉じる。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

次のコマンドを使用して，NNMiプロセスが起動していることを確認する。

ovstatus -v

IPv6を再度アクティブにすると，NNMiビューには，新たに検出されたノードのIPv6インベントリが表示される。

次の検出サイクルの間に，NNMiビューにはその前の検出ノードに関連するIPv6インベントリが表示されます。

必要に応じて，デュアルスタック管理ノードのSNMP管理アドレス設定を指定する。

デュアルスタック管理ノードは，IPv4またはIPv6のどちらかを使用して通信できるノードです。これを行うには，次の手順を実行します。

a　NNMiコンソールで，［設定］ワークスペースにある［通信の設定］をクリックします。

b　［管理アドレスの選択］セクションを見つけます。［IPバージョン設定］フィールドで，［IPv4］，［IPv6］，または［任意］を選択します。

c　変更を保存します。

d　次のコマンドを実行して，NNMiを再起動する。

　ovstop
　ovstart

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

スピードアップを図るには，デュアルスタックノードとわかっているノードを選択し，NNMiコンソールで［アクション］＞［設定のポーリング］コマンドを使用します。nnmnoderediscover.ovplスクリプトを使用して，NNMi検出キューにノードを追加することもできます。詳細については，nnmnoderediscover.ovplのリファレンスページを参照してください。

NNMi管理サーバーでIPv6通信を有効化すると，NNMiはICMPv6を使用してIPv6アドレスフォルトがないかノードの監視を開始します。

第5編　高可用性環境設定編

17　NNMiがサポートするデータの保護

この章では，ハードウェア障害の場合のNNMiデータを保護するため，NNMiがサポートしている方法について説明します。

17.1　NNMiがサポートするデータ保護の仕組み

NNMiでは，ハードウェア障害の場合にNNMiデータを保護するため，次の2つの方法をサポートしています。

アプリケーションフェイルオーバー構成

NNMiのアプリケーションフェイルオーバーでは，NNMiデータベースのトランザクションログのコピーが同一設定システムで維持され，ディザスタリカバリが提供されます。詳細については，「18.　アプリケーションフェイルオーバー構成のNNMiを設定する」を参照してください。

高可用性（HA）クラスタでの動作

HAクラスタでNNMiを実行すると，NNMiデータベースと設定ファイルが共有ディスクに保持され，NNMi管理サーバーのほぼ100パーセントの可用性が提供されます。詳細については，「19.　高可用性クラスタにNNMiを設定する」を参照してください。

これらの方法では，現在のNNMi管理サーバーで障害が発生すると，第2システムが自動的にNNMi管理サーバーになります。

17.2　NNMiがサポートするデータ保護の仕組みの比較

NNMiがサポートするデータ保護の仕組みの比較を，次の表に示します。

表17‒1　NNMiがサポートするデータ保護の仕組みの比較

比較項目

NNMiのアプリケーションフェイルオーバー

HAクラスタで動作するNNMi

必要なソフトウェア製品

NNMi

NNMi

個別に購入するHA製品

フェイルオーバーに掛かる

時間

トランザクションログを処理する時間（通常の状態では10分〜60分）

通常の状態では5分〜30分

フェイルオーバーの透過性

部分的。

NNMi管理サーバーのIPアドレスは，スタンバイサーバーの物理アドレスに変わります。ユーザーは新しいIPアドレスで，NNMiコンソールに接続してください。

完全。

すべての接続はHAクラスタの仮想IPアドレスが使用され，これはフェイルオーバー時にも変わりません。

アクティブサーバーとスタンバイサーバーの相対的な近接性

LANまたはWAN

LANまたはWAN（一部のHA製品だけ）

グローバルネットワーク管理とのインタラクション

アプリケーションフェイルオーバー

アプリケーションフェイルオーバー用にグローバルマネージャー，リージョナルマネージャーを設定できません。

HA

・HA用に各グローバルマネージャー，リージョナルマネージャーを設定できます。

・それぞれの設定には，2つの物理システムが必要です。

・グローバルマネージャーまたはリージョナルマネージャーがフェイルオーバーすると，NNMiは，グローバルマネージャーとリージョナルマネージャー間の接続を再確立します。

NNMiのメンテナンス

修正版の適用またはバージョンアップをする前に，NNMiのアプリケーションフェイルオーバークラスタを停止する必要があります。

HAを設定解除しないで，NNMiに修正版の適用またはバージョンアップができます。

18　アプリケーションフェイルオーバー構成のNNMiを設定する

重要なネットワーク機器の障害発生を知らせ，その障害の根本原因を示すNNMiは，多くのITプロフェッショナルから信頼を寄せられています。NNMi管理サーバーに障害が発生した場合でも，引き続きNNMiがネットワーク機器の障害発生を知らせてくれる必要があります。このニーズを満たすのがNNMiのアプリケーションフェイルオーバーで，NNMiプロセスのアプリケーションコントロールをアクティブなNNMi管理サーバーからスタンバイNNMi管理サーバーに引き渡すことで，NNMiの機能は中断なく提供されます。

18.1　アプリケーションフェイルオーバーの概要

アプリケーションフェイルオーバーは，クラスタソフトや共有ディスクなしでNNMi管理サーバーを多重化する機能です。

2台のNNMi管理サーバーをアクティブサーバーおよびスタンバイサーバーとして構成し，NNMiが稼働するアクティブサーバーに障害が発生したときに，スタンバイサーバーにNNMiを引き継ぐことでネットワーク監視を継続できます。

このアプリケーションフェイルオーバー機能は，NNMi独自のクラスタマネージャー（nnmclusterプロセス）の制御によって実現していて，クラスタソフトと連携するHA構成とは異なった特徴があります。なお，マニュアルやヘルプでは，アプリケーションフェイルオーバーの構成をNNMiクラスタ（または単にクラスタ）と表記している場合がありますので適宜読み替えてください。

アプリケーションフェイルオーバー機能は，NNMiデータベースを使用してNNMiをインストールすることで利用できるようになります。システムにアプリケーションフェイルオーバー機能を設定すると，NNMiはNNMi管理サーバーの障害を検出した場合に，スタンバイサーバーにNNMiの機能を引き渡します。

NNMiのアプリケーションフェイルオーバー設定では，次の用語と定義を使用しています。

アクティブ：ネットワーク監視を実行中のサーバー。

スタンバイ：フェイルオーバーのイベントを待機しているNNMiクラスタ内のサーバー。このサーバーはネットワーク監視を実行していません。

Cluster Member：クラスタに接続するためにJGroups技術を使用しているシステムで実行中のJavaプロセス。1つのシステムに複数のメンバーを登録できます。

Postgres：トポロジ，インシデント，設定情報などの情報を保存するためにNNMiが使用するデータベース。

Cluster Manager：アプリケーションフェイルオーバー機能でサーバーの監視と管理に使用されるnnmclusterプロセスおよびツール。

18.2　アプリケーションフェイルオーバーの基本セットアップ

アプリケーションフェイルオーバー機能を導入するには，NNMiを2つのサーバーにインストールします。ここでは，この2つのNNMi管理サーバーをアクティブサーバーとスタンバイサーバーとして説明します。通常の運用では，アクティブサーバーだけがネットワーク監視を実行します。

アクティブおよびスタンバイNNMi管理サーバーは，各NNMi管理サーバーのハートビートを監視するクラスタの一部です。アクティブサーバーに障害が発生し，そのハートビートが消失すると，スタンバイサーバーがアクティブサーバーになります。

アプリケーションフェイルオーバー機能は，次のどちらかの方法で設定できます。

手動によるアプリケーションフェイルオーバーの設定

NNMiクラスタセットアップウィザードを使用したアプリケーションフェイルオーバーの設定

18.2.1　アプリケーションフェイルオーバーを設定するための前提条件

アプリケーションフェイルオーバーが正しく機能するには，NNMi管理サーバーが次の要件を満たしている必要があります。

NNMiを単独で使用する構成だけをサポートしています。

ほかのJP1などの関連製品と連携して使用する構成はサポートしていませんので，この場合は，クラスタソフトによるHA構成を使用してください。

両方のNNMi管理サーバーで，アクティブサーバーのホスト名とIPアドレス，スタンバイサーバーのホスト名とIPアドレスが名前解決できる必要があります。

両方のNNMi管理サーバーの持つすべてのIPv4アドレスが，ネットワーク上で重複していない必要があります。

両方のNNMi管理サーバーが同じ種類のオペレーティングシステムを実行している必要があります。例えば，アクティブサーバーがMicrosoft(R) Windows Server(R) 2012 R2 Datacenterを実行している場合，スタンバイサーバーもMicrosoft(R) Windows Server(R) 2012 R2 Datacenterを実行している必要があります。

両方のNNMi管理サーバーは同じバージョン（修正版のバージョンを含む）のNNMiを実行している必要があります。例えば，アクティブサーバーでNNMi 12-00を実行している場合，スタンバイサーバーでも同一のNNMi 12-00がインストールされている必要があります。

両方のNNMi管理サーバーのsystemユーザーのパスワードが同一である必要があります。

アプリケーションフェイルオーバーを設定する前にNNMiへのHTTPアクセスを完全に無効にしないでください。詳細については，「21.18　リモートアクセスには暗号化を必須とするようにNNMiを設定する」を参照してください。アプリケーションフェイルオーバークラスターの設定が正常に完了したあと，HTTPおよびその他の非暗号化アクセスを無効にできます。

（Windowsの場合）両方のNNMi管理サーバーはNNMiのインストール先が同一で，%NnmDataDir%および%NnmInstallDir%のシステム変数を同一の値に設定している必要があります。

両方のNNMi管理サーバーのライセンス属性（管理ノード数，NNMiかNNMi Advancedか）が同一である必要があります。例えば，ノードカウントおよびライセンス取得済みの機能が同一である必要があります。

重要

スタンバイサーバーにも同一のライセンスが必要です。

NNMiが初回検出の高度なステージに入るまで，アプリケーションフェイルオーバーを有効にしないでください。詳細については，「6.4　検出の評価」を参照してください。

アプリケーションフェイルオーバーが正しく機能するには，アクティブサーバーとスタンバイサーバーは相互のネットワークアクセスに制限のないことが必要です。ファイルをロックしたり，ネットワークのアクセスを制限したりするソフトウェアが原因で，NNMiの通信の問題が発生する場合があります。こうしたアプリケーションで，NNMiが使用するファイルとポートを無視するように設定します。

アクティブサーバーとスタンバイサーバーは，クラスタ通信に使用するNICの持つすべてのIPv4アドレスで，アプリケーションフェールオーバーを構成する相手のNNMi管理サーバーと通信ができる必要があります。相手と通信できないIPv4アドレスが存在する場合，アプリケーションフェールオーバーの構築に失敗したり，構築済みのアプリケーションフェールオーバー環境の動作が不正になったりします。クラスタ通信に使用するNICの設定方法については，「18.3.3　アプリケーションフェイルオーバー通信の設定」を参照してください。

アクティブサーバーとスタンバイサーバーの間に，ファイアウォールを設置することは推奨しません。ファイアウォールを設置する場合は，両サーバーがすべてのポートで通信できるように設定してください。

NNMi管理サーバー内でファイアウォールを実行する場合，自サーバー内のプロセス同士の通信および相手サーバーとの通信を，すべてのポートで許可するように設定してください。アプリケーションフェイルオーバーは動的に任意のポートで通信します。

プロセス単位で通信許可を設定するファイアウォールの場合（例：Windows Firewall）は，クラスタマネージャー（nnmcluster.exe）の通信を許可してください。

ポート単位で通信許可を設定するファイアウォールの場合，次の通信を許可してください。

IPアドレス：自サーバーと相手サーバーに割り当てられたすべてのIPアドレス

ポート：すべてのポート

アクティブサーバーとスタンバイサーバーのNNMiデータベースは同じパスワードが設定されている必要があります。

NNMiデータベースのパスワードを変更した場合は，アプリケーションフェイルオーバーの設定を行う前に，すべてのサーバーで同じパスワードを設定してください。

この条件を満たしたら，「18.3　アプリケーションフェイルオーバー構成のNNMiを設定する」に示した手順を実行してください。詳細については，「付録E　NNMiが使用するポートの一覧」を参照してください。

18.2.2　アプリケーションフェイルオーバーの注意事項

アプリケーションフェイルオーバーについての注意事項を説明します。

アプリケーションフェイルオーバー構成では，サーバー停止時にはNNMiがフェイルオーバーしますが，（nnmcluster以外の）NNMiのプロセスが停止してもフェイルオーバーはしません。詳しくは「18.4.2　アプリケーションフェイルオーバーのシナリオ」を参照してください。

NNMiプロセスが停止したときにフェイルオーバーさせたい場合は，HAクラスタソフトによる HA構成を使用してください。

スタンバイサーバーが停止している場合（切り替え先がない状態）にそれを通知する機能は提供していません。

フェイルオーバー時に何らかの処理を実行するためのユーザー指定コマンドを実行する機能は提供していません。

NNMi が稼働するサーバーのIP アドレスがフェイルオーバー時に変わります。IP アドレスは引き継ぎません。このため，次の点に注意してください。

SNMP トラップの送信先は，両方のNNMi 管理サーバーに設定してください。

Web ブラウザに両方のNNMi 管理サーバーのブックマークを登録しておき，アクティブサーバー側に接続してください。

バックアップを定期的に行い，万一データが壊れた場合に備えてください。アプリケーションフェイルオーバー機能でスタンバイサーバーに複製されるデータは，バックアップの代替としては使用できません。

アプリケーションフェイルオーバー構成では，データベース部分は通常構成に比べて3倍のディスク容量が必要です。データベースの構成について「18.4.1　アプリケーションフェイルオーバーの動作」を参照してください。

18.3　アプリケーションフェイルオーバー構成のNNMiを設定する

アプリケーションフェイルオーバー構成のNNMiの設定方法について説明します。

18.3.1　手動によるアプリケーションフェイルオーバーの設定

アプリケーションフェイルオーバー構成のNNMiを設定するには，次の手順を実行します。

アクティブサーバー（サーバーX）とスタンバイサーバー（サーバーY）にNNMiをインストールする。

「2.3　NNMiのライセンスを取得する」に記載されているように，各サーバーに恒久ライセンスを導入する。

各サーバーでovstopコマンドを実行してNNMiをシャットダウンする。

nms-cluster.propertiesファイルに含まれる指示を参考にして，サーバーX（アクティブ）およびサーバーY（スタンバイ）のアプリケーションフェイルオーバー機能を設定する。

次の手順を実行します。次の手順では，ファイルのテキストブロックの行のコメント（先頭の#!）を解除し，テキストを変更することを編集と呼びます。

a　次のファイルを編集します。

Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

b　NNMiクラスタに一意の名前を宣言します。アクティブサーバーとスタンバイサーバーが同じ名前を使用するように設定します。名前は英数字で指定してください。大小文字は区別されます。

このパラメーターを指定することで，アプリケーションフェイルオーバー機能が有効化されます。

com.hp.ov.nms.cluster.name=MyCluster

c　nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.member.hostnamesパラメーターに，クラスタのすべてのノードのホスト名を追加します。

com.hp.ov.nms.cluster.member.hostnames = fqdn_for_active,fqdn_for_standby

重要

両方のノードのどちらかが複数のIPv4アドレスを持つ場合は，com.hp.ov.nms.cluster.member.hostnamesパラメーターに，各ノードのNNMiの通信に使用するIPv4アドレスを記載してください。

NNMiの証明書（nnm-key.p12ファイルおよびnnm-trust.p12ファイル，または認証機関を使用する）を設定する。

選択した方法に基づき，「10.3.5　アプリケーションフェイルオーバー環境での証明書の使用」に示されている指示を実行します。

重要

アプリケーションフェイルオーバー機能を設定するときには，両方のノードのnnm-trust.p12ファイルをマージして，1つのnnm-trust.p12ファイルを作成する必要があります。選択した方法の指示を参照してください。

次のファイルをサーバーXからサーバーYにコピーする。

コピーする前に，アプリケーションフェイルオーバー構成を解除するときのために元のファイルをバックアップしてください。

Windows：%NnmDataDir%shared¥nnm¥conf¥nnmcluster¥cluster.keystore

Linux：$NnmDataDir/shared/nnm/conf/nnmcluster/cluster.keystore

両ノード間のクラスタ通信に使用するNICを設定する。

詳細については，「18.3.3　アプリケーションフェイルオーバー通信の設定」を参照してください。

重要

両方のノードのどちらかが複数のNICを持つ場合は，必ず設定を実施してください。

サーバーXとサーバーYの両方で次のコマンドを実行する。

nnmcluster

各サーバーに，次のように表示されます。

================== 現在のクラスタ状態 =====================
状態ID: 000000001000000005
日付/時間: 15 3 2011 - 09:37:58 (GMT+0900)
クラスタ名: ThisCluster (キー CRC:626,187,650)
自動フェールオーバー: Enabled
NNMデータベースの種類: 組み込み
NNMで設定済みのACTIVEノード: NO_ACTIVE
NNMの現在のACTIVEノード: NO_ACTIVE
クラスタメンバー:

 ローカル?  ノード タイプ 状態 OvStatus ホスト名/アドレス
-------  -------- ----- -------- ---------------------------
* REMOTE ADMIN     N/A   N/A      serverX.xxx.yyy.yourcompany.com/16.78.61.68:7800
(SELF)   ADMIN     N/A   N/A      serverY.xxx.yyy.yourcompany.com/16.78.61.71:7800
==========================================================

重要

コマンドを終了する場合はEnterキーを押下後，「quit」と入力してください。

画面には，サーバーXとサーバーYの両方がリストされます。両方のノードの情報が表示されない場合，それらのノードはお互いに通信していません。手順を進める前に，次のことを確認して，修正してください。

次に示す両方のサーバーのクラスタ名「com.hp.ov.nms.cluster.name」に，同じクラスタ名を設定してください。

・Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

・Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

キーCRCが，サーバーXとサーバーYで異なっているかどうか。

サーバーXとサーバーYの両方で，次のファイルの内容を確認してください。

・Windows：%NnmDataDir%shared¥nnm¥conf¥nnmcluster¥cluster.keystore

・Linux：$NnmDataDir/shared/nnm/conf/nnmcluster/cluster.keystore

異なっている場合は，手順6.を実施してください。

サーバーXまたはサーバーYのファイアウォールによって，ノードの通信が妨げられているかどうか。

ノードが通信できる状態に設定してください。

nnm-trust.p12ファイルがマージされているかどうか。

このエラーが表示されるのは，nnmclusterコマンドを実行した後です。

com.hp.ov.nms.cluster.interfaceに指定したNICから取得できるIPアドレスとcom.hp.ov.nms.cluster.member.hostnamesに指定したホスト名から解決できるIPアドレスを一致させてください。

com.hp.ov.nms.cluster.interfaceは次のファイル内に指定します。

・Windows：%NnmDataDir%Conf¥nnm¥props¥nms-cluster-local.properties

・Linux：$NnmDataDir/conf/nnm/props/nms-cluster-local.properties

com.hp.ov.nms.cluster.member.hostnamesは次のファイル内に指定します。

・Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

・Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

相手サーバーの待機IPアドレスと，相手サーバーとして指定したIPアドレスが一致しているかどうか。

相手サーバーがクラスタ通信のために待機しているIPアドレスと，クラスタ通信の相手サーバーとして指定したIPアドレスが一致しているかどうかを確認してください。

クラスタ通信のために使用するポートはデフォルト7800です。

待機しているIPアドレスはnetstatコマンドで確認できます。

クラスタ通信の相手サーバーとして指定したIPアドレスは，nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.member.hostnamesパラメーターで確認できます。

com.hp.ov.nms.cluster.member.hostnamesにホスト名を指定している場合は，ホスト名から解決できるIPアドレスを確認してください。

サーバーXとサーバーYで，異なるオペレーティングシステムが実行されているかどうか。

例えば，サーバーXでLinuxオペレーティングシステムが実行され，サーバーYでWindowsオペレーティングシステムが実行されている場合などです。同じオペレーティングシステムが実行されている環境で設定してください。

サーバーXとサーバーYが，異なるバージョンのNNMiを実行しているかどうか。

例えば，サーバーXがNNMi 11-00を実行しており，サーバーYがNNMi 11-00の修正版を実行している場合などです。同じバージョンのNNMiをインストールした環境で設定してください。

サーバーXで，NNMiクラスタマネージャーを開始する。

nnmcluster -daemon

nnmcluster -daemonコマンドをNNMi管理サーバーXで実行すると，NNMiクラスタマネージャーが次の起動ルーチンを実行します。

NNMi管理サーバーXをクラスタに接続します。

ほかのNNMi管理サーバーが存在しないことを検知します。

NNMi管理サーバーXはアクティブ状態に変わります。

NNMi管理サーバーX（アクティブサーバー）のNNMiサービスを開始します。

データベースのバックアップを作成します。

詳細については，nnmclusterのリファレンスページを参照してください。

サーバーXがクラスタの最初のアクティブサーバーになるまで数分待ったあと，サーバーXでnnmcluster -displayコマンドを実行する。

「ACTIVE_NNM_STARTING」または「ACTIVE_SomeOtherState」と表示されていることを確認してください。サーバーXがアクティブサーバーであることを確認するまで手順11.に進まないでください。

サーバーYでNNMiクラスタマネージャーを開始する。

nnmcluster -daemon

nnmcluster -daemonコマンドをNNMi管理サーバーYで実行すると，NNMiクラスタマネージャーが次の起動ルーチンを実行します。

NNMi管理サーバーYをクラスタに接続します。

NNMi管理サーバーXが存在し，アクティブな状態であることが検出されます。画面に「STANDBY_INITIALIZING」と表示されます。

NNMi管理サーバーYのデータベースバックアップが NNMi管理サーバーXのバックアップと比較されます。一致しない場合は，新しいデータベースバックアップがNNMi管理サーバーX（アクティブ）からNNMi管理サーバーY（スタンバイ）に送信されます。画面に「STANDBY_RECV_DBZIP」と表示されます。

NNMi管理サーバーYは，スタンバイ状態に該当するバックアップに最低限必要となる，トランザクションログの最小限のセットを受信します。画面に「STANDBY_RECV_TXLOGS」と表示されます。

NNMi管理サーバーYは待機状態になり，新しいトランザクションログとハートビート信号をNNMi管理サーバーXから受信し続けます。画面に「STANDBY_READY」と表示されます。

詳細については，nnmclusterのリファレンスページを参照してください。

フェイルオーバーが発生した場合，サーバーXのNNMiコンソールは機能しなくなる。サーバーXのNNMiコンソールセッションを閉じて，サーバーY（新たにアクティブになったサーバー）にサインインする。

NNMiユーザーに，サーバーX（アクティブサーバー）とサーバーY（スタンバイサーバー）への2つのブックマークを登録するように指示します。フェイルオーバーが発生すると，ユーザーはサーバーY（スタンバイNNMi管理サーバー）に接続できます。

サーバーXとサーバーYの両方にトラップを送信するように，NNMiの監視対象機器の設定を変更する。

サーバーX（アクティブ）が実行している間，サーバーXは転送されたトラップを処理し，サーバーY（スタンバイ）はそのトラップを無視します。

18.3.2　NNMiクラスタセットアップウィザードを使用したアプリケーションフェイルオーバーの設定

NNMiクラスタセットアップウィザードは，アプリケーションフェイルオーバーで使用するNNMi内のクラスタの設定プロセスを自動化します。ウィザードでは，次の操作ができます。

クラスタノードの指定および検証を行う

クラスタのプロパティおよびポートを定義する

両方のノードのnnm-key.p12ファイルおよびnnm-trust.p12ファイルの内容をマージして，1つのnnm-key.p12ファイルおよびnnm-trust.p12ファイルにする

サポートされるWebブラウザに次のURLを入力して，クラスタセットアップウィザードを起動する。

http://<NNMiserver>:<port>/cluster

<NNMiserver>は，NNMiホストの値です。

<port>は，NNMiポートの値です。

システムの［ユーザー名］と［パスワード］を入力して［ログイン］ボタンをクリックし，NNMiにログインする。

［ローカルホスト名］と［リモートクラスタノード］の値を入力してクラスタノードを定義し，［次へ］をクリックする。

重要

両方のノードのどちらかが複数のIPv4アドレスを持つ場合は，［ローカルホスト名］と［リモートクラスタノード］に，各ノードのNNMiの通信に使うIPv4アドレスを記載してください。

［通信結果］ページで，通信の検証結果を確認する。

エラーが発生した場合は［前へ］をクリックして問題を修正します。エラーが発生しなかった場合は［次へ］をクリックします。

緑のステータスメッセージは，リモートクラスタノードに正常に接続されたことを示します。

［クラスタプロパティを定義］ページで，［クラスタ名］を入力して［バックアップ周期(時間)］を定義する。

［クラスタ名］は，英数字で指定してください。次に自動フェイルオーバーを有効にするかどうかを指定します。［次へ］をクリックします。

［クラスタポートを定義］ページで，［開始クラスタポート］と［ファイル転送ポート］の値を入力する。

NNMiクラスタでは，［開始クラスタポート］で始まる4個の連続したポートが使用されます。

［次へ］をクリックする。

［要約］ページで，入力した情報の概要を確認する。

戻って設定情報を変更する場合は［前へ］をクリックします。変更しない場合は［コミット］をクリックしてクラスタ設定を保存します。

最後の概要には，設定が成功したかどうかが示されます。

両方のノードでovstopを実行して，両方のノードのNNMiを直ちに停止する。

両ノード間のクラスタ通信に使用するNICを設定する。

詳細については，「18.3.3　アプリケーションフェイルオーバー通信の設定」を参照してください。

重要

両方のノードのどちらかが複数のNICを持つ場合は，必ず設定を実施してください。

両方のノードでnnmclusterコマンドを実行して，2つのノードをクラスタ構成にできることを確認する。

ノードをクラスタ構成にできない場合は，「18.3　アプリケーションフェイルオーバー構成のNNMiを設定する」を参照してください。

nnmcluster -daemonコマンドを使用して，アクティブにするノード上のNNMiを起動する。

NNMiがACTIVEをレポートするまで待機します。詳細は「18.3　アプリケーションフェイルオーバー構成のNNMiを設定する」を参照してください。

nnmcluster -daemonコマンドを使用して，スタンバイノードを起動する。

18.3.3　アプリケーションフェイルオーバー通信の設定

インストール時に，NNMiはシステム上のすべてのネットワークインタフェースカード（NIC）に対してクエリーを実行し，クラスタ通信に使用するNICを特定します。システムに複数のNICが存在する場合，次の手順を実行して，nnmcluster操作に使用するNICを選択できます。

重要

両方のノードのどちらかが複数のNICを持つ場合は，必ず設定を実施してください。

nnmcluster -interfacesを実行して，使用可能なすべてのインタフェースをリスト表示する。

詳細については，nnmclusterのリファレンスページを参照してください。

次のファイルを編集する。

Windows：%NnmDataDir%Conf¥nnm¥props¥nms-cluster-local.properties

Linux：$NnmDataDir/conf/nnm/props/nms-cluster-local.properties

次のような内容のテキストが含まれる行を見つける。

com.hp.ov.nms.cluster.interface=<値>

必要に応じて値を変更する。

インタフェースの値は，有効なインタフェースである必要があります。インタフェースの値が無効の場合は，クラスタが開始できない場合があります。

設定する値は手順1.のnnmcluster -interfacesで出力されたeth3などの値です。

Windowsの場合は，eth3などの値に続いてシステムのインタフェースの説明が表示されます。

ipconfig /allコマンドなどによって，インタフェースの説明を確認することで，使用するインタフェースとeth3などの値を対応させてください。

Linuxの場合は，インタフェースの名前が表示されます。ifconfigコマンドなどによって，使用するインタフェースの名前を確認してください。

重要

アクティブサーバーとスタンバイサーバーは，クラスタ通信に使用するNICの持つすべてのIPv4アドレスで，アプリケーションフェールオーバーを構成する相手のNNMi管理サーバーと通信ができる必要があります。相手と通信できないIPv4アドレスが存在する場合，アプリケーションフェールオーバーの構築に失敗したり，構築済みのアプリケーションフェールオーバー環境の動作が不正になったりします。

nms-cluster-local.propertiesファイルを保存する。

com.hp.ov.nms.cluster.interfaceパラメーターを使用すると，NNMiの管理者はnnmclusterの通信に使用する通信インタフェースを選択できるようになります。com.hp.ov.nms.cluster.interfaceに指定したNICから取得できるIPアドレスとcom.hp.ov.nms.cluster.member.hostnamesに指定したホスト名から解決できるIPアドレスを一致させるように設定してください。複数のIPアドレスが同一のホスト名に名前解決される環境では，com.hp.ov.nms.cluster.member.hostnamesパラメーターにホスト名ではなく，アプリケーションフェイルオーバーの通信に使用するIPアドレスを設定してください。com.hp.ov.nms.cluster.member.hostnamesパラメーターは，次のファイルで設定します。

Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

18.4　アプリケーションフェイルオーバー機能の使用

両方のNNMi管理サーバーでクラスタマネージャーが実行しているため（アクティブサーバーとスタンバイサーバー），クラスタマネージャーを使用してクラスタのステータスを表示できます。クラスタマネージャーには3つのモードがあります。

デーモンモード：クラスタマネージャーのプロセスはバックグラウンドで実行し，ovstopおよびovstartコマンドを使用してNNMiサービスを開始および停止します。

インタラクティブモード：クラスタマネージャーは，NNMi管理者がクラスタの属性を表示および変更できるインタラクティブセッションを実行します。例えば，NNMi管理者はこのセッションを使用して，アプリケーションフェイルオーバー機能を有効または無効にしたり，デーモンプロセスをシャットダウンしたりできます。

コマンドラインモード：NNMi管理者は，コマンドプロンプトでクラスタの属性を表示および変更します。

詳細については，nnmclusterのリファレンスページを参照してください。

18.4.1　アプリケーションフェイルオーバーの動作

次の図は，NNMiデータベースを使用した2つのNNMi管理サーバーのアプリケーションフェイルオーバー設定を示します。この章の以降のセクションについて，この図を参照してください。

図18‒1　アプリケーションフェイルオーバーの設定（NNMiデータベース）

クラスタからスタンバイサーバーを削除し，そのサーバーをスタンドアロンサーバーとして動作させて，次にそのサーバーを再度クラスタに戻すと，データベースのエラーになる場合があります。この場合，コマンドラインから次のコマンドを実行します。

nnmcluster dbsync

NNMi 11-00には，アプリケーションフェイルオーバー内にストリーミングレプリケーション機能が含まれており，スタンバイサーバーとアクティブサーバーが同期した状態のまま，データベーストランザクションがアクティブサーバーからスタンバイサーバーに送信されます。これによって，（以前のバージョンのNNMiのように）フェイルオーバーでデータベーストランザクションログをスタンバイサーバーにインポートする必要がなくなり，スタンバイサーバーがアクティブサーバーを引き継ぐのに要する時間が大幅に短縮されます。この機能には，データベースバックアップファイルが必要な場合だけノード間で送信されるという利点もあり，データベーストランザクションファイルの通常の転送で，大きなデータベースバックアップファイルを送信する頻度が少なくなります。

アクティブサーバーとスタンバイサーバーの両方を開始すると，スタンバイサーバーはアクティブサーバーを検知してアクティブサーバーにデータベースのバックアップをリクエストしますが，ネットワーク監視は開始しません。このデータベースのバックアップは1つのZIPファイルとして保存されます。すでにスタンバイサーバーに以前のクラスタ接続から得たZIPファイルがあり，そのファイルがすでにアクティブサーバーと同期されていることを確認した場合は，ファイルは再送されません。

アクティブサーバーとスタンバイサーバーの両方が実行している間，アクティブサーバーは定期的にデータベースのトランザクションログをスタンバイサーバーに送信します。nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.timeout.archiveパラメーターの値を変更すると，このデータの転送頻度を変更できます。これらのトランザクションログはスタンバイサーバーに蓄積されるため，スタンバイからアクティブになったときにすぐに利用できます。

標準のデータの転送頻度は，次のとおりです。

6時間ごとに，データベースのフルバックアップを転送します。

15分ごとに，トランザクションログ（データベースの更新情報）を転送します。なお，データベースが大量に更新された場合は，より短い間隔で転送する場合があります。

データが転送されるまでの間に更新した内容は引き継がれません。

スタンバイサーバーがアクティブサーバーからデータベースの完全バックアップを受信すると，その情報をNNMiデータベースに取り込みます。また，recovery.confファイルを作成して受信したすべてのトランザクションログを取り込んでからでないと，ほかのサービスがデータベースを使用できません。そのことをNNMiデータベースに知らせます。何らかの理由でアクティブサーバーが利用できなくなると，スタンバイサーバーはNNMiサービスを開始するovstartコマンドを実行してアクティブになります。スタンバイサーバーは，残りのNNMiサービスを開始する前に，トランザクションログをインポートします。

データベースのファイルは，次のディレクトリ下に格納されます。

Windows：%NnmDataDir%shared¥nnm¥databases¥

Linux：$NnmDataDir/shared/nnm/databases/

アプリケーションフェイルオーバー構成では，上のディレクトリ下に三つのディレクトリ（Postgres，Postgres_standby，Postgres_OLD）が作成されます。それぞれの用途は次のとおりです。

Postgres：稼働中またはスタンバイ用に受信したデータベース本体のデータを格納

Postgres_standby：アクティブサーバーからスタンバイサーバーへ転送・受信したデータを格納

Postgres.OLD：スタンバイサーバーがデータ受信時の旧Postgresデータを退避するために使用

アクティブサーバーに障害が発生すると，スタンバイサーバーは，ディスカバリとポーリングアクティビティを開始します。このようにシステムを切り替えることによって，障害が発生したシステムの診断と修理を行う間，NNMiはネットワークを監視およびポーリングし続けます。

重要

NNMiではアプリケーションフェイルオーバー構成でのフェイルオーバー後に再同期が行われるためステータスおよびインシデントの更新が遅延する可能性があります。

この再同期中に次のメッセージが表示されても問題はありません。

Causal Engineのキューサイズが大きいため，ステータスおよびインシデントの更新が遅延しています。これは，アプリケーションフェイルオーバー構成でのフェイルオーバー，バックアップの復元，または手動による再同期のあとに再同期が行われることが原因で発生する可能性があります。

18.4.2　アプリケーションフェイルオーバーのシナリオ

アクティブNNMi管理サーバーがハートビートを送信しなくなり，フェイルオーバーが発生してしまう原因には幾つかあります。

ここでは障害発生時のNNMi管理サーバーのフェイルオーバーについて，障害発生時の状況を場合分けしたシナリオを使用して説明します。

表18‒1　想定障害とシナリオの対応

想定する障害

障害の発生個所

アクティブ側

スタンバイ側

サーバー

サーバーダウン※1

シナリオ1

シナリオ6

OSの停止

シナリオ2

シナリオ6

プロセス

nnmclusterの停止

シナリオ3

シナリオ6

nnmcluster以外の停止

シナリオ5

該当なし※2

ネットワーク

相手と通信不可

シナリオ4

シナリオ4

注※1　サーバーダウンはハード障害やOS障害などで停止した場合を想定しています。

注※2　スタンバイサーバーのNNMiは停止しているため，該当する場合はありません。

(1)　フェイルオーバーが発生する場合

次のシナリオ1〜3の場合，自動フェイルオーバーが有効になっていればNNMiがスタンバイサーバーへフェイルオーバーし，NNMiのネットワーク監視が継続されます。

シナリオ1：アクティブNNMi管理サーバーに障害が発生した。

アクティブサーバーがハード障害やOS 障害によってOS のシャットダウン処理が行われないで停止した場合です。スタンバイサーバーは相手が停止したことを検知し，アクティブになって自動的にNNMiを起動し，ネットワーク監視は継続されます。元のアクティブサーバーは，起動するとスタンバイとして動作します。

シナリオ2：システム管理者がアクティブなNNMi管理サーバーをシャットダウンまたはリブートした。

アクティブサーバーがOSのシャットダウン処理を行って停止した場合です。スタンバイサーバーは相手が停止したことを検知し，アクティブになって自動的にNNMiを起動し，ネットワーク監視は継続されます。元のアクティブサーバーは，起動するとスタンバイとして動作します。

ただし，NNMi管理サーバーがLinuxオペレーティングシステムの場合は，OSの停止時に終了スクリプトが実行されると，ovstopコマンドが自動的に実行されるため，アプリケーションフェイルオーバーが無効になり，フェイルオーバーが発生しません。

シナリオ3：NNMi管理者がクラスタをシャットダウンした。

クラスタマネージャー（nnmclusterプロセス）が，管理者の操作または何らかの要因で停止した場合です。スタンバイサーバーは相手が停止したことを検知し，アクティブになって自動的にNNMiを起動し，ネットワーク監視は継続されます。

重要

アクティブサーバーのnnmclusterだけが何らかの要因で停止して，ほかのNNMiのプロセスが残ったまま動作している状態になった場合，シナリオ3の障害と同様の状態になり，元のアクティブサーバーと新たなアクティブサーバーの2台でNNMiが動作する状況になる場合があります。この場合は，元のアクティブサーバーのOSを再起動して回復してください。

(2)　フェイルオーバーが発生しない場合

「(1)　フェイルオーバーが発生する場合」で挙げたシナリオに該当しない現象が起こった場合，フェイルオーバーは発生しません。例えば，次のような場合があります。

シナリオ4：アクティブNNMi管理サーバーとスタンバイNNMi管理サーバーの間のネットワーク接続に障害が発生した。

両サーバーの通信ができなくなった場合です。クラスタマネージャー（nnmcluster プロセス）の間のハートビート通信ができないため， 次の状態に陥ります。

アクティブサーバーは相手が停止したと検知し，そのまま動作します。

スタンバイサーバーも相手が停止したと検知し，アクティブとなってNNMiを起動します。

シナリオ4では，両方のNNMi管理サーバーがアクティブな状態で稼働します。ネットワークデバイスが復旧すると，2つのNNMi管理サーバーは自動的にネゴシエーションしてアクティブサーバーとして稼働するサーバーを決定し，片方のサーバーがスタンバイとなりNNMiを停止します。

なお，両方のサーバーがアクティブになる状態は，クラスタソフトでのHA構成の場合はスプリットブレインと呼ばれる問題が発生します。しかし，アプリケーションフェイルオーバーの場合は仕組みが異なるため，通信障害が回復すると次のように問題なく回復します。

通信が回復すると片方がスタンバイサーバーとなり通常の構成に回復します。

アプリケーションフェイルオーバーのデータベースは，共有ディスクを使用しないで，スタンバイ側がアクティブ側へデータベースの転送を要求してデータベースを同期する方式です。このため，両方のサーバーでNNMiが動作しても整合性に問題は発生しません。

シナリオ5：NNMiのプロセスが停止した。

何らかの要因でクラスタマネージャー（nnmclusterプロセス）以外のNNMiのプロセスが停止しても，フェイルオーバーは発生しません。

クラスタマネージャーのハートビート通信によって相互にサーバーの動作監視をしていますが，自サーバー内のNNMiのプロセスの監視は行っていないため，このような動作となります。

NNMiプロセスが停止した時にフェイルオーバーさせたい場合は，クラスタソフトによるHA構成を使用してください。

シナリオ6：スタンバイサーバーで障害が発生した。

スタンバイサーバー側で，シナリオ1〜3の障害（サーバーダウン，OSの停止またはnnmclusterプロセスの停止）が発生した場合です。この場合，スタンバイサーバーがクラスタ構成のメンバーからは外れますが，アクティブサーバーのNNMiは動作し続け，NNMiによるネットワーク監視は継続できます。

重要

スタンバイサーバーがない状態（片系運用）になったことは通知されません。

18.4.3　アプリケーションフェイルオーバー構成のNNMi管理サーバーで使用するovstartおよびovstopコマンド

アプリケーションフェイルオーバーが設定されたNNMi管理サーバーでovstopコマンドおよびovstartコマンドを使用した場合，実際にはNNMiは次のコマンドを実行します。これらはNNMiの起動や停止の完了を待たないですぐに終了します。

ovstart: nnmcluster -daemon

ovstop: nnmcluster -disable -shutdown

メモ

ovstopコマンドを実行すると，NNMiはスタンバイサーバーにフェイルオーバーしません。ovstopコマンドは，メンテナンスによる一時的な停止をサポートするように設計されています。フェイルオーバーを手動で行うには，ovstopコマンドに-failoverオプションを使用します。詳細については，ovstopのリファレンスページを参照してください。

ovstopコマンドを実行するとnnmclusterの-disableオプションが指定されているため，自動フェイルオーバーが無効化されますので注意してください。フェイルオーバーの有効無効を確認するにはnnmcluster -displayで「自動フェールオーバー」の項を確認します。フェイルオーバーを有効化するにはnnmcluster -enableを実行します。

ovstopコマンドに使用する次のオプションは，アプリケーションフェイルオーバークラスタに構成されたNNMi管理サーバーで使用します。

ovstop -failover：ローカルのデーモンモードのクラスタプロセスを停止し，スタンバイNNMi管理サーバーに強制的にフェイルオーバーします。以前にフェイルオーバーモードが無効にされている場合は，このコマンドで有効になります。このコマンドはnnmcluster -enable -shutdownと同等です。

ovstop -nofailover：フェイルオーバーモードを無効にし，ローカルのデーモンモードのクラスタプロセスを停止します。フェイルオーバーは行われません。このコマンドはnnmcluster -disable -shutdownと同等です。

ovstop -cluster：アクティブサーバーとスタンバイサーバーを停止し，これらをクラスタから削除します。このコマンドはnnmcluster -haltと同等です。

重要

Linuxオペレーティングシステムを実行しているNNMi管理サーバーでOSの停止時にNNMiの終了スクリプトが実行されると，ovstopコマンドが自動的に実行され，アプリケーションフェイルオーバーが無効になります。メンテナンス中にアプリケーションフェイルオーバーを制御するには，OSの停止コマンドを実行する前に，nnmcluster -acquireコマンドとnnmcluster -relinquishコマンドを使用してアクティブサーバーとスタンバイサーバーを目的の動作に設定します。詳細については，nnmclusterのリファレンスページを参照してください。

18.4.4　アプリケーションフェイルオーバーのインシデント

nnmclusterプロセスまたはnnmclusterコマンドを使用するユーザーが，ノードをアクティブとして開始すると，NNMiではそのたびに次のどちらかのインシデントが生成されます。

NnmClusterStartup：NNMiクラスタは，アクティブサーバーがない状態で開始されました。したがって，このサーバーはアクティブ状態で起動されました。このインシデントの重大度は「正常域」です。

NnmClusterFailover：NNMiクラスタでアクティブサーバーの障害が検出されました。そのため，スタンバイサーバーがアクティブサーバーになり，そのノードでNNMiサービスが開始されました。このインシデントの重大度は「重要警戒域」です。

18.5　フェイルオーバーの問題解決後の設定

アクティブノードで障害が発生し，スタンバイノードがアクティブノードとして機能している場合，以前のアクティブノードで問題を解決したあとで，元の設定に戻すことができます。

次の手順を実行します。

以前のアクティブノードで問題を解決する。

目的のアクティブノードで次のコマンドを実行し，元の設定に戻す。

nnmcluster -acquire

詳細については，nnmclusterのリファレンスページを参照してください。

18.6　アプリケーションフェイルオーバーを無効にする

アプリケーションフェイルオーバーを設定し，数日間使用したあとに，完全に無効化するとします。次の情報は，アプリケーションフェイルオーバーを完全に無効にする方法を説明しています。アプリケーションフェイルオーバークラスタに構成された，アクティブおよびスタンバイNNMi管理サーバーでのアクションを含め，次の指示に従ってください。

アクティブNNMi管理サーバーでnnmcluster -enableコマンドを実行する。

アクティブNNMi管理サーバーでnnmcluster -shutdownコマンドを実行する。

既存のスタンバイNNMi管理サーバーが新しくアクティブNNMi管理サーバーになるまで数分待つ。

新しいアクティブ（以前のスタンバイ）NNMi管理サーバーでnnmcluster -displayコマンドを実行する。

表示された結果で，ACTIVE_NNM_RUNNINGステータスを検索する。

ACTIVE_NNM_RUNNINGステータスを確認できるまで，手順4.を繰り返します。

新しいアクティブ（以前のスタンバイ）NNMi管理サーバーでnnmcluster -shutdownコマンドを実行する。

新しいアクティブ（以前のスタンバイ）でnnmcluster -displayコマンドを実行する。

コマンド実行結果でノードタイプ列がDAEMONの行がなくなるまで繰り返し実行します。

クラスタに構成されている両方のNNMi管理サーバーで，次のファイルを編集する。

Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

両方のNNMi管理サーバーのcom.hp.ov.nms.cluster.nameオプションをコメントにし（行の先頭に#!を付ける），各ファイルを保存する。

両方のNNMi管理サーバーの次のファイルを編集する。

Windows：%NnmDataDir%shared¥nnm¥databases¥Postgres¥postgresql.conf

Linux：$NnmDataDir/shared/nnm/databases/Postgres/postgresql.conf

postgresql.confを編集する場合は，改行コードがLF（0x0A）だけのファイルを編集できるエディタを使用してください（Windowsの場合は，メモ帳は使用しないで，ワードパットを使用する。Linuxの場合はviを使用する）。

各ファイルで，次の行を削除する。

次の例は，WindowsのNNMi管理サーバーの表示例です。サーバーによって，表示がやや異なります。

# The following lines were added by the NNM cluster.
archive_command = 'nnmcluster.exe -archive  -logCONFIG "%p" "file:/C:/ProgramData/Hitachi/Cm2NNMi/shared/nnm/databases/Postgres_standby/TxWALs_send/%f"'
archive_timeout = 900
max_wal_senders = 4
archive_mode = 'on'
wal_level = 'hot_standby'
hot_standby = 'on'
wal_keep_segments = 500
listen_addresses = 'localhost,XX.XX.XX.XX'

必ず変更を保存してください。

Windows NNMi管理サーバーの場合，［サービス(ローカル)］コンソールに移動し，各サーバーで次の手順を実行する。

a　NNM Cluster Managerの［スタートアップの種類］を［無効］に設定します。

b　NNM Process Managerの［スタートアップの種類］を［自動］に設定します。

次のトリガーファイルを作成する。

このファイルは，Postgresにスタンバイモードでの実行を中止し，完全に実行するように指示します。

Windows：%NnmDataDir%tmp¥postgresTriggerFile

Linux：$NnmDataDir/tmp/postgresTriggerFile

両方のNNMi管理サーバーでovstartコマンドを実行する。

両方のNNMi管理サーバーが正常に開始したら，スタンバイおよびアクティブNNMi管理サーバーから次のディレクトリを削除する。

Windows：%NnmDataDir%shared¥nnm¥databases¥Postgres_standby

Linux：$NnmDataDir/shared/nnm/databases/Postgres_standby

メモ

このディレクトリはデフォルトのディレクトリで，nms-cluster.propertiesファイルにあるcom.hp.ov.nms.cluster.archivedirパラメーターの値です。この手順では，この値が変更されていないことを前提としています。nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.archivedirパラメーターの値を変更した場合は，変更後の新しい値に相当するディレクトリを削除します。

スタンバイおよびアクティブNNMi管理サーバーから次のディレクトリを削除する。

Windows：%NnmDataDir%shared¥nnm¥databases¥Postgres.OLD

Linux：$NnmDataDir/shared/nnm/databases/Postgres.OLD

18.7　管理タスクとアプリケーションフェイルオーバー

次は，NNMi管理サーバーへのパッチ適用や再起動などの管理タスクを行うときに，アプリケーションフェイルオーバーを効果的に管理する方法を説明します。

18.7.1　NNMiのバージョンアップ（修正版の適用を含む）

アプリケーションフェイルオーバー構成のNNMi管理サーバーをバージョンアップする場合は「24.4　アプリケーションフェイルオーバー構成のNNMi 13-50へのアップグレード」を参照してください。

18.7.2　NNMiの起動と停止および再起動

(1)　NNMiの起動と停止

アプリケーションフェイルオーバー構成のNNMiは，ovstartコマンドで起動，またはovstopコマンドで停止を行う際に，nnmclusterコマンドに置き換えられて実行します。置き換え後のコマンドは，「18.4.3　アプリケーションフェイルオーバー構成のNNMi管理サーバーで使用するovstartおよびovstopコマンド」を参照してください。

アプリケーションフェイルオーバー構成のNNMiは，起動時にサーバーがアクティブになるかスタンバイになるかが自動的に調整され，先にnnmclusterを起動したサーバーがアクティブになります。起動時の動作については，「18.4　アプリケーションフェイルオーバー機能の使用」を参照してください。

起動時の処理が完了すると次の通常運用時の状態になります。サーバーの状態は，nnmclusterコマンドをオプションなしで実行（インタラクティブモード）またはnnmcluster -displayコマンドを実行してState列の表示を参照して確認します。

＜通常運用時の状態＞

アクティブサーバー：ACTIVE_NNM_RUNNING

スタンバイサーバー：STANDBY_READY

NNMiの起動時はサーバーが上記の通常運用時の状態になることを確認してください。主なサーバーの状態には次の種類があります。

状態（Stateの表示）

役割

説明

ACTIVE_NNM_STARTING

アクティブ

NNMiの起動処理中です

ACTIVE_DB_BACKUP

アクティブ

NNMiのDBのバックアップ処理中です

ACTIVE_NNM_RUNNING

アクティブ

NNMiが稼働している状態です

STANDBY_RECV_DBZIP

スタンバイ

アクティブ側のNNMiからDBを転送中です

STANDBY_READY

スタンバイ

スタンバイとして準備完了となったNNMiの状態です

アプリケーションフェイルオーバーの運用操作，例えばアクティブとスタンバイの切り替えなどを行う場合は，通常運用時の状態になっていることを確認してから行ってください。この状態になる前にフェイルオーバーをした場合，サーバー間が正しく同期できずにNNMiの起動が失敗してACTIVE_NNM_FAILEDの状態になる場合があります。この場合は両サーバーを停止してから起動を行ってください。データベースの問題で起動できない場合は，データベースをリセットし，バックアップデータをリストアしてから再起動してください。

(2)　NNMiの再起動

スタンバイNNMi管理サーバーは，いつでも再起動でき，再起動に関する特別な指示はありません。スタンバイおよびアクティブの両方のNNMi管理サーバーを再起動する場合，アクティブNNMi管理サーバーを先に再起動します。

アクティブまたはスタンバイNNMi管理サーバーを再起動するには，次の手順を実行します。

NNMi管理サーバーでnnmcluster -disableコマンドを実行し，アプリケーションフェイルオーバー機能を無効にする。

次のコマンドを実行して，NNMi管理サーバーを再起動する。

ovstop
ovstart

NNMi管理サーバーでnnmcluster -enableコマンドを実行し，アプリケーションフェイルオーバー機能を有効にする。

重要

NNMiのTrapReceiverプロセス，およびそのフェイルオーバーとの関連に関する重要情報については，「21.16　NNMi NmsTrapReceiverプロセス」を参照してください。

通信障害後のアプリケーションフェイルオーバーの制御

2つのクラスタノード間の通信障害が解決したあとは，その通信障害が発生するまでに最も長時間動作していた（つまり以前にアクティブだった）NNMi管理サーバーが，アクティブサーバーに指定されます。

(3)　NNMiのフェイルオーバー

アプリケーションフェイルオーバー構成のシステムでサーバーの障害が発生した場合は，「18.4.2　アプリケーションフェイルオーバーのシナリオ」に示すように状況に応じて自動的にフェイルオーバーし，アクティブサーバーでNNMiが起動されます。

手動でアクティブサーバーを切り替えたい場合は，次の手順を実行します。

アクティブサーバーでovstop -failoverを実行する。

NNMiが停止してからクラスタマネージャー（nnmcluster）が停止し，スタンバイサーバーが新たなアクティブサーバーとなってNNMiが起動します。

手順1.を実行した状態では，操作を行った元のアクティブサーバーはクラスタ構成のメンバーから外れている。スタンバイサーバーとしてクラスタに参加するにはovstartを実行する。

ovstartは，nnmcluster -daemonに置き換えられて実行します。

18.7.3　NNMiのバックアップとリストア

(1)　NNMiのバックアップ

アプリケーションフェイルオーバー構成のNNMiは，通常のシステムと同様の手順でバックアップを実行できます。ただし，-forceオプション（強制的にバックアップに適した状態にする）は使用できませんので，事前にバックアップに適した状態にしてからバックアップをします。

アクティブサーバー側で，次の手順を実行してください。

バックアップに適した次の状態にする。

nnmbackup.ovplを使用する場合

オンラインバックアップの場合：NNMiサービスを起動状態にする

オフラインバックアップの場合：NNMiサービスを停止状態にする

nnmbackupembdb.ovplを使用する場合

NNMiサービスを起動状態にする

バックアップを実行する。

nnmbackup.ovplまたはnnmbackupembdb.ovplコマンドを実行します。

重要

バックアップは，アクティブサーバー側（オフラインバックアップでNNMiを停止する場合は，直前まで稼働していたサーバー）で行ってください。

あるサーバーセット上のNNMiアプリケーションフェイルオーバー環境で取得したバックアップを異なるサーバーセット上のNNMiアプリケーションフェイルオーバー環境で復元するには，NNMiアクティブおよびスタンバイシステム両方のバックアップを取得してください。

(2)　NNMiのリストア

アクティブおよびスタンバイNNMi管理サーバーがアプリケーションフェイルオーバー構成の場合に，以前のバックアップからNNMiデータベースをリストアするには，次の手順を実行します。

アクティブNNMi管理サーバーでnnmcluster -haltコマンドを実行する。

アクティブサーバーとスタンバイサーバーの両方のNNMiが停止します。nnmclusterコマンドをオプションなしで実行（インタラクティブモード）またはnnmcluster -displayコマンドを実行し，NNMiサービスが停止したことを確認します。

アクティブおよびスタンバイNNMi管理サーバーの次のディレクトリを削除または移動する。

Windows

%NnmDataDir%shared¥nnm¥databases¥Postgres_standby
%NnmDataDir%shared¥nnm¥databases¥Postgres.OLD

Linux

$NnmDataDir/shared/nnm/databases/Postgres_standby
$NnmDataDir/shared/nnm/databases/Postgres.OLD

アクティブNNMi管理サーバーでデータベースをリストアする。

アプリケーションフェイルオーバー構成の設定を一時的に解除します。

次のファイルのクラスタ名「com.hp.ov.nms.cluster.name」をコメントに（行の先頭に #! を付ける）してください。

Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

通常どおり，データベースをリストアします。nnmrestore.ovplまたはnnmrestoreembdb.ovplを-forceオプションを指定して実行します。-forceオプションを指定してリストアに必要なサービスが起動したあと，リストアが実行されます。これらのコマンドについては，「20.3　NNMiデータをリストアする」を参照してください。

nnmbackup.ovplでバックアップしたデータをリストアした場合は，手順aの変更がリストアしたファイルで上書きされているおそれがあるため，もう一度手順aを実施してください。

アクティブNNMi管理サーバーでovstopコマンドを実行します。手順bでリストア処理のために起動したサービスが停止します。

アプリケーションフェイルオーバー構成を再設定します。

次のファイルでクラスタ名「com.hp.ov.nms.cluster.name」のコメントを解除（手順aで付けた#!を削除）してください。

Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

アクティブNNMi管理サーバーでovstartコマンドを実行する。

アクティブNNMi管理サーバーが新しいバックアップ（アクティブとスタンバイが同期を取るためのZIPファイル）を生成するまで待つ。

この手順が完了したことを確認するには，nnmcluster -displayコマンドを実行し，ACTIVE_NNM_RUNNINGメッセージを検索します。

スタンバイNNMi管理サーバーでovstartコマンドを実行する。

スタンバイNNMi管理サーバーは新しいバックアップ（手順5.で作成されたZIPファイル）をコピーして抽出します。この手順が完了したことを確認するには，nnmcluster -displayコマンドを実行し，STANDBY_READYメッセージを検索します。

(3)　異なるサーバーセット上のNNMiフェイルオーバー環境にリストア

異なるサーバーセット上のNNMiフェイルオーバー環境を復元するには，NNMiアクティブおよびスタンバイシステム両方のバックアップを取得し，必要なサーバー上でそれらを復元するとともに，所定のプロパティファイルでホスト名を変更する必要があります。

NNMiフェイルオーバー環境を復元するには，次の手順を実行します。

ソースフェイルオーバー環境内のアクティブシステムとスタンバイシステムのすべてのNNMiデータの完全なオフラインバックアップを取得します。詳細については，「20.2　NNMiデータをバックアップする」を参照してください。

バックアップファイルを，それぞれの送り先であるアクティブシステムとスタンバイシステムにコピーします。

バックアップデータの場合と同じバージョンおよびパッチレベルのNNMiをインストールします。

アクティブシステムとスタンバイシステムの両方でNNMiデータを復元します。

アクティブシステムとスタンバイシステムの両方で「(2)　NNMiのリストア」の手順3.を実施してください。

アクティブおよびスタンバイNNMi管理サーバーの両方で，次の手順を実行します。

アクティブおよびスタンバイNNMiサーバーの両方のホスト名を確認します。

次のファイルを開きます。

Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

アクティブノードおよびスタンバイノードのホスト名をcom.hp.ov.nms.cluster.member.hostnamesパラメーターに追加します。

com.hp.ov.nms.cluster.member.hostnames = fqdn_for_active, fqdn_for_standby

セキュア通信用のSSL証明書を使用するようにNNMiフェイルオーバー環境を設定します。詳細については，「10.　NNMiでの証明書の使用」を参照してください。

18.7.4　NNMiの設定の変更

(1)　設定の変更

アプリケーションフェイルオーバー構成で，NNMiの設定を変更する場合について説明します。

(a)　NNMiの設定ファイル

NNMiの設定ファイルを変更する場合は，アクティブサーバーとスタンバイサーバーの両方で設定変更を行い，同じ内容になるようにしてください。

重要

NNMiの再起動を伴う設定変更は，両方のサーバーを停止して設定変更を行ってください。

なお，NNMiの運用を停止しないで変更したい場合は，次の手順で設定変更を行ってください。各手順はnnmcluster -displayを実行して，処理が完了していることを確認しながら，次の手順に進んでください。

サーバーAでovstop -failoverを実行する。

サーバーAが停止し，サーバーBがアクティブになります。

サーバーAで設定変更を行う。

サーバーAでovstartを実行し，スタンバイとして起動する。

サーバーBでovstop -failoverを実行する。

サーバーBが停止し，サーバーAがアクティブになります。

サーバーBで設定変更を行う。

サーバーBでovstartを実行し，スタンバイとして起動する。

(b)　NNMiのデータベース

NNMiのデータベースはアクティブサーバーとスタンバイサーバーが自動的に同期を行っていますので，システム管理者の操作は不要です。

詳しい動作については，「18.4　アプリケーションフェイルオーバー機能の使用」を参照してください。

(2)　データベースのリセット

「4.8　NNMi設定およびデータベースのリセット」で説明されているデータベースのリセットを行う場合，一時的にアプリケーションフェイルオーバー構成を解除する必要があります。次の手順を行ってください。

（任意）現在のNNMi設定を保存しておきたい場合は，アクティブサーバーで，次の手順を実行する。

nnmconfigexport.ovplコマンドを使用して，NNMi設定をXMLファイルに出力します。

nnmtrimincidents.ovplコマンドを使用して，NNMiインシデントをアーカイブします。

アクティブサーバーで，nnmcluster -haltコマンドを実行する。

アクティブサーバーとスタンバイサーバーの両方のNNMiが停止します。

nnmclusterコマンドをオプションなしで実行（インタラクティブモード）またはnnmcluster -displayコマンドを実行し，NNMiサービスが停止されたことを確認します。

アクティブサーバーで，NNMiのデータベースをリセットする。

a　アプリケーションフェイルオーバー構成の設定を一時的に解除します。

次のファイルのクラスタ名com.hp.ov.nms.cluster.nameをコメントに（行の先頭に #! を付ける）してください。

Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

b　（任意）データベースのデータが削除される前に，必要に応じて次のコマンドで既存のデータベースをバックアップします。

nnmbackup.ovpl -type offline -target <backup_directory>

c　NNMiデータベースを削除して再作成します。

nnmresetembdb.ovpl -nostart

d　アクティブNNMi管理サーバーでovstopコマンドを実行します。手順cで起動したサービスが停止します。

e　アプリケーションフェイルオーバー構成を再設定します。

次のファイルでクラスタ名com.hp.ov.nms.cluster.nameのコメントを解除（手順aで付けた#!を削除）してください。

Windows：%NnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

Linux：$NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

アクティブおよびスタンバイサーバーの次のディレクトリを削除または移動する。

Windows

%NnmDataDir%shared¥nnm¥databases¥Postgres_standby
%NnmDataDir%shared¥nnm¥databases¥Postgres.OLD

Linux

$NnmDataDir/shared/nnm/databases/Postgres_standby
$NnmDataDir/shared/nnm/databases/Postgres.OLD

アクティブNNMi管理サーバーでovstartコマンドを実行する。

この手順が完了したことを確認するには，nnmcluster -displayコマンドを実行し，ACTIVE_NNM_RUNNINGメッセージを検索します。

スタンバイNNMi管理サーバーでovstartコマンドを実行する。

この手順が完了したことを確認するには，nnmcluster -displayコマンドを実行し，STANDBY_READYメッセージを検索します。

これでNNMiのデータベースはデフォルト設定だけになりました。

アクティブサーバーでNNMiの設定を行ってください。なお，手順1.で保存したNNMi設定をインポートするにはnnmconfigimport.ovplコマンドを使用します。

18.7.5　NNMiデータベースパスワードの変更

「18.6　アプリケーションフェイルオーバーを無効にする」を実施し，一時的にアプリケーションフェイルオーバー構成を無効にする。

それぞれのNNMi管理サーバーで，パスワードを変更する。

手順の詳細については，nnmchangeembdbpw.ovplのリファレンスページを参照してください。

「18.3.2　NNMiクラスタセットアップウィザードを使用したアプリケーションフェイルオーバーの設定」を実施し，再度アプリケーションフェイルオーバー構成を有効にする。

18.8　ネットワークレイテンシ/帯域に関する考慮

NNMiアプリケーションフェイルオーバーは，クラスタのノード間で継続的なハートビート信号を交換することによって機能します。これには，NNMiデータベース，データベーストランザクションログ，そのほかのNNMi設定ファイルなどのデータファイルの交換に使用されるネットワークチャネルが使用されます。WAN（広域ネットワーク）にNNMiアプリケーションフェイルオーバーを導入する場合，パフォーマンスが高く，レイテンシが低い接続を使用することをお勧めします。

NNMiデータベースは必ず圧縮されていますが，非常に容量が大きくなり，1GB以上に増大することがあります。また，NNMiは，ビルトインバックアップインターバル（設定パラメーター，デフォルトは6時間）の間に膨大な数のトランザクションログを生成します。各トランザクションログのサイズは数メガバイトから最大16MBになることもあります。（これらのファイルは圧縮されています）。次は，テスト環境から収集されたデータの例です。

Number of nodes managed: 15,000
Number of interfaces: 100,000
Time to complete spiral discovery of all expected nodes: 12 hours
Size of database: 850MB (compressed)
During initial discovery: ~10 transaction logs per minute (peak of ~15/min)
-------------------------------------------
10 TxLogs/minute X 12 hours = 7200 TxLogs @ ~10MB = ~72GB

これでは，ネットワークで送信するにはデータ量が多過ぎます。2つのノード間のネットワークがNNMiアプリケーションフェイルオーバーの帯域幅の要求に応じられない場合，スタンバイサーバーへのデータベースファイルの送信に遅延が発生してしまいます。このため，アクティブサーバーに障害が発生した場合，潜在的なデータ喪失の可能性が高くなります。

同様に，2つのノード間のネットワークのレイテンシが高いか信頼性が低い場合，ノード間で偽のハートビート喪失となります。例えば，ハートビート信号が直ちに応答しない場合に，スタンバイサーバーは，アクティブサーバーに障害が発生したと判断します。ハートビート喪失の検出に関与する要素には幾つかあります。NNMiは，ネットワークがアプリケーションフェイルオーバーのデータ転送の要求に応答できる限り，偽のフェイルオーバー通知を回避します。

18.8.1　アプリケーションフェイルオーバーとNNMiデータベース

アプリケーションフェイルオーバーにデータベースを使用するようにNNMiを設定すると，NNMiは次のように動作します。

アクティブサーバーがデータベースのバックアップを実行し，1つのZIPファイルにデータを保存する。

ネットワークを通して，動作1.のZIPファイルをスタンバイサーバーに送信する。

スタンバイサーバーはZIPファイルを展開し，データベースを設定して最初の起動でトランザクションログをインポートする。

アクティブサーバーのデータベースは，データベースアクティビティによって，トランザクションログを生成する。

アプリケーションフェイルオーバーでは，トランザクションログがネットワークを通してスタンバイサーバーに送信され，ディスクに蓄積される。

スタンバイサーバーがアクティブになると，NNMiが起動されて，データベースがネットワークを通してすべてのトランザクションログをインポートする。

これに掛かる時間は，ファイル数，およびそのファイルに保存されている情報の複雑さによって決まります。

スタンバイサーバーにすべてのトランザクションログがインポートされると，データベースが使用可能になり，スタンバイサーバーは残りのNNMiプロセスを開始する。

元のスタンバイサーバーがアクティブになり，動作1.がやり直しされる。

(1)　アプリケーションフェイルオーバー環境でのネットワークトラフィック

アプリケーションフェイルオーバー環境では，NNMiはアクティブサーバーからスタンバイサーバーにネットワークを介して次の項目を転送します。

データベースアクティビティ（1つのZIPファイルでのデータベースバックアップ）

トランザクションログ

それぞれのアプリケーションフェイルオーバーノードが，他方のノードが動作していることを確認するための定期的なハートビート

ファイルがアクティブサーバーのものと同期していることをスタンバイサーバーが確認できるようにするファイル比較リスト

パラメーターの変更（フェイルオーバーやそのほかの有効／無効），およびクラスタでのノードの追加や除外などのイベント

データベースアクティビティとトランザクションログで，アプリケーションフェイルオーバーで使用されるネットワークトラフィックのほとんどが生成されます。ここでは，この2つの項目について説明します。

データベースアクティビティ

NNMiはすべてのデータベースアクティビティのトランザクションログを生成します。

データベースアクティビティには，NNMiのすべてが含まれます。アクティビティには，次のデータベースアクティビティが含まれますが，そのほかにも含まれるものがあります。

新しいノードの検出

ノード，インタフェース，VLAN，そのほかの管理対象オブジェクトに関する属性の検出

状態ポーリングとステータス変更

インシデント，イベント，根本原因分析

NNMiコンソールでのオペレータのアクション

データベースアクティビティを制御することはできません。例えば，ネットワークが停止すると，NNMiは多くのインシデントとイベントを生成します。このインシデントとイベントで，ネットワーク上のデバイスの状態ポーリングが開始され，NNMiでデバイスのステータスが更新されます。停止が復旧されると，ノード開始インシデントによってステータスがさらに変化します。このすべてのアクティビティによって，NNMiデータベースのエントリが更新されます。

NNMiデータベース自体はデータベースアクティビティによって拡大しますが，時間の経過とともに拡大は穏やかになり，環境でのサイズは安定します。

データベーストランザクションログ

NNMiデータベースは，空の16MBのファイルを作成してからデータベーストランザクション情報をそのファイルに書き込むことで動作します。NNMiは，15分が経過した時点か，16MBのデータがファイルに書き込まれた時点のどれかの早い時点でこのファイルを閉じて，アプリケーションフェイルオーバーで使用できるようにします。つまり，完全にアイドル状態のデータベースで，15分ごとに1つのトランザクションログファイルが生成されますが，このファイルは本質的に空です。アプリケーションフェイルオーバーでは，すべてのトランザクションログが圧縮され，空の16MBのファイルは1MB未満に圧縮されます。満杯の16MBのファイルは約8MBに圧縮されます。データベースアクティビティが多い期間は，それぞれのファイルがすぐに満杯になるため，アプリケーションフェイルオーバーによって短時間により多くのトランザクションログが生成されます。

(2)　アプリケーションフェイルオーバーのトラフィックテスト

次のテストモードでは，1分ごとにおよそ2個のトランザクションログファイルが生成され，1つのファイルの平均ファイルサイズは7MBになります。これは，それぞれのフェイルオーバーイベントで追加される5,000個のノードの検出に関連するデータベースアクティビティによるものです。このテストケースのデータベースは，最終的に約1.1GBで安定し（バックアップのZIPファイルのサイズで測定），ノードは31,000個，インタフェースは960,000個になります。

テストモード

最初の4時間でテスト担当者が5,000個のノードをNNMiにシードして，検出が安定するまで待機しました。4時間後，テスト担当者がフェイルオーバーを誘発し，スタンバイサーバーがアクティブになり，以前のアクティブサーバーがスタンバイになりました。テスト担当者はフェイルオーバー直後に約5,000個のノードをさらに追加し，また4時間待機してNNMiの検出プロセスを安定させてから，別のフェイルオーバーを誘発し，以前のアクティブサーバーに戻りました。

テスト担当者は，フェイルオーバー間の時間を，4時間，6時間，2時間というよう変更して，このサイクルを数回繰り返しました。テスト担当者は，それぞれのフェイルオーバーイベント後に，次の項目を測定します。

ノードが初めてアクティブになったときに作成されるデータベース

バックアップのZIPファイルのサイズ

トランザクションログ

ファイル総数，およびディスク容量の使用量

フェイルオーバーを誘発する直前のNNMiデータベースのノードとインタフェースの数

フェイルオーバーが完了するまでの時間

アクティブサーバーでovstopコマンドを最初に実行してから，スタンバイサーバーが完全にアクティブになってNNMiが動作するまでの時間。

結果

結果は次の表のとおりです。

表18‒2　アプリケーションフェイルオーバーのテスト結果

時間

DB.zipサイズ（単位：MB）

トランザクションのログの数

トランザクションログのサイズ（単位：GB）

ノード数

インタフェース数

フェイルオーバーの時間（単位：分）

4

6.5

50

0.3

5,000

15,000

5

8

34

500

2.5

12,000

222,000

10

12

243

500

2.5

17,000

370,000

25

16

400

500

3.5

21,500

477,000

23

20

498

500

3.5

25,500

588,000

32

26

618

1,100

7.5

30,600

776,000

30

28

840

400

2.2

30,600

791,000

31

30

887

500

2.5

30,700

800,000

16

所見

NNMiがアクティブサーバーからスタンバイサーバーにファイルを転送する場合，転送は4時間ごとに平均で約5GB，連続スループットは約350KB／秒，または2.8MB／秒になっています。

メモ

このデータには，ハートビート，ファイル整合性チェック，そのほかのアプリケーションフェイルオーバー通信など，アプリケーションフェイルオーバートラフィックは含まれていません。また，パケットヘッダーなどのネットワークI／Oのオーバーヘッドも除外されています。このデータには，ネットワークで移動する各ファイルの内容の実ネットワークペイロードだけが含まれます。

NNMiのアプリケーションフェイルオーバー環境で生成されるトラフィックは非常に膨大です。アプリケーションフェイルオーバーでは，5分ごとにアクティブサーバーで新しいトランザクションログが識別され，スタンバイサーバーに送信されます。ネットワークの速度によって，スタンバイサーバーではすべての新しいファイルが短時間で受信され，この5分間隔の残りの間，ネットワークはアイドル状態となることが多くなります。

アクティブサーバーとスタンバイサーバーがロールを切り替えるたびに，すなわち，スタンバイサーバーがアクティブになり，アクティブサーバーがスタンバイになるたびに，新しいアクティブサーバーは完全なデータベースバックアップを生成し，ネットワークを介して新しいスタンバイサーバーに送信します。このデータベースバックアップも定期的に発生し，デフォルトで24時間ごとにバックアップされます。NNMiは，新しいバックアップを生成するたびに，このバックアップをスタンバイサーバーに送信します。この新しいバックアップがスタンバイサーバーで使用可能になると，その24時間にNNMiが生成したすべてのトランザクションログがデータベースに反映されて，フェイルオーバー時にインポートする必要がなくなるため，フェイルオーバー時間が短縮されます。

このことによって，NNMiデータベースを使用してアプリケーションフェイルオーバーでNNMiを使用するとき，フェイルオーバー後にネットワークがどのようなパフォーマンスになるかを理解できます。

19　高可用性クラスタにNNMiを設定する

高可用性（HA）とは，構成された動作中のハードウェアおよびソフトウェアの一部に障害が発生しても中断されないサービスを提供するシステムです。HAクラスタは，フェイルオーバー発生時の機能とデータの継続性を保証するために，協調して動作するハードウェアとソフトウェアのグループ化を定義します。この章では，HA環境で実行するNNMiを設定するためのテンプレートについて説明します。この章では，HA製品の詳細な設定手順については説明しません。NNMiに用意されているHA設定コマンドは，サポートされるHA製品用のコマンドに関するものです。NNMi HAコマンドを使用して，NNMi用にHAを適切に設定します。

19.1　HAの概念

クラスタアーキテクチャには，クラスタ内の複数のノードのプロセスとリソース用の単一のグローバルに徹底した管理ビューが備わっています。次の図に，クラスタアーキテクチャの例を示します。

図19‒1　高可用性クラスタのアーキテクチャ

クラスタ内の各ノードは，1つ以上のパブリックネットワークと1つのプライベートインターコネクト（クラスタノード間のデータ伝送用の通信チャネル）に接続されます。

Veritas Cluster Server，Symantec Cluster Server，Windows Server Failover Clusterなどの最新のクラスタ環境では，アプリケーションはリソースの複合体として表現され，単純な操作でアプリケーションをクラスタ環境で実行できます。リソースは，クラスタ環境で動作するアプリケーションを表す，HAリソースグループに構成されます。次の図に，HAリソースグループの例を示します。

図19‒2　典型的なHAリソースグループのレイアウト

このマニュアルでは，各種のクラスタ環境内のリソースの集合を指すために，HAリソースグループという用語を使います。各HA製品では，HAリソースグループに対して，異なる名前が使われています。次の表に，このマニュアルのHAリソースグループに相当する，サポート対象のHA製品で使われている用語を示します。

表19‒1　サポート対象のHA製品でHAリソースグループに相当する名前

HA製品

略語

HAリソースグループに相当する名前

Veritas Cluster Server

VCS

サービスグループ

Symantec Cluster Server

SCS

サービスグループ

Windows Server Failover Cluster

WSFC※

リソースグループ

HAモニタ

HAモニタ

サーバー

CLUSTERPRO X

CLUSTERPRO

フェイルオーバグループ

注※

WSFCは，MSFC（Microsoft Failover Cluster）と表記する場合もありますが，このマニュアルではWSFCと表記します。

表19-1のHA製品は，すべてのOSで使用できるわけではありません。

対応するクラスタソフト，そのバージョンについての詳細は，弊社ホームページからご確認ください。

19.1.1　HA用語集

次の表に，一般的なHA用語の定義を示します。

表19‒2　一般的なHA用語

用語

説明

HAリソースグループ

クラスタ環境内（HA製品下）で動作する各種リソースの集合です。

ボリュームグループ

大規模ストレージエリアを形成するよう設定された1つ以上のディスクドライブです。

論理ボリューム

ボリュームグループ内で，個別のファイルシステムまたはデバイススワップ空間として使われる任意のサイズの領域です。

プライマリクラスタノード

ソフトウェア製品が最初にインストールされるシステムであり，かつ，HAが最初に設定されるシステムです。初期セットアップでは，共有ディスクはプライマリクラスタノードにマウントされます。プライマリクラスタノードは，通常，最初のアクティブなクラスタノードになりますが，HAの設定完了後には，プライマリとしての役割を解除できます。HA設定を変更すると，ほかのノードをプライマリクラスタノードにできます。

セカンダリクラスタノード

プライマリクラスタノードでのHA設定の完了後に，HA設定に追加される任意のシステムです。

アクティブなクラスタノード

現在HAリソースグループを実行中のシステムです。

パッシブなクラスタノード

HA用に設定されているが，現在HAリソースグループを実行していないシステムです。アクティブなクラスタノードで障害が発生すると，HAリソースグループはパッシブなクラスタノードにフェイルオーバーし，そのノードがアクティブなクラスタノードになります。

19.1.2　NNMi HAクラスタのシナリオ

NNMi HA設定では，NNMiは各システムにインストールされ，HAリソースグループの一部になります。NNMiデータベースは独立したディスクにインストールされ，各システムで動作中のNNMiプログラムからアクセスされます（任意の時点で共有ディスクにアクセスできるのは，アクティブなクラスタノードである1つのシステムだけです）。

メモ

NNMiデータベースのバックアップスクリプトとリストアスクリプトを実行できるのは，アクティブなクラスタノードだけです。

NNMiだけのシナリオ

次の図に，NNMi HAクラスタのシナリオを示します。

ノードAとノードBは，どちらも，すべてのソフトウェアがインストールされたNNMi管理サーバーであり，そのシステムで実行するNNMiプログラムが含まれています。アクティブなクラスタノードが，共有ディスクのランタイムデータにアクセスします。ほかの製品は，HAリソースグループの仮想IPアドレスを使って，NNMiに接続します。

図19‒3　NNMi HAクラスタ用の基本的なシナリオ

このシナリオの実装方法については，「19.4.2　HA用にNNMiを設定する」を参照してください。

19.1.3　manページ

NNMiには，NNMi高可用性設定に役立つ次のmanページがあります。

nnm-ha

nnmhaconfigure.ovpl

nnmhaunconfigure.ovpl

nnmhadisk.ovpl

nnmhaclusterinfo.ovpl

nnmhastartrg.ovpl

nnmhastoprg.ovpl

Windowsオペレーティングシステムでは，これらのmanページはテキストファイルで提供されます。

19.2　HA用NNMiを設定するための前提条件の検証

NNMiを動作させるHAクラスタは，次の要件を満たしている必要があります。

システム構成全般について

複数のHA製品をインストールした構成ではNNMiは使用できません。NNMiがHA製品の種類を正しく認識できず正常に動作しない場合があります。

Windows：すべてのクラスタノードで，NNMiのインストール先（%NnmDataDir%と%NnmInstallDir%）を一致させてください。

両方のNNMi管理サーバーは同じバージョン（修正版のバージョンを含む）のNNMiを実行している必要があります。例えば，アクティブサーバーで NNMi 11-00-01 を実行している場合，スタンバイサーバーでも同一の NNMi 11-00-01 がインストールされている必要があります。

Windows（WSFC）の場合：NNMiは，クラスタシステムでcluster.exeコマンドを使用しますが，デフォルトではインストールされません。

［サーバーマネージャー］＞［役割と機能の追加］より，［機能］＞［リモートサーバー管理ツール］＞［機能管理ツール］＞［フェールオーバークラスタリング ツール］＞［フェールオーバー クラスター コマンドインターフェイス］をインストールしてください。

必要なディスク容量は，リリースノートの「4.　メモリ所要量およびディスク占有量」の表に記載されている次の項目を参照してください。

ローカルディスクのディスク容量

「アプリケーションインストール用のディスク容量」の値と「実行時のデータベースとデータ用のディスク容量」の値

共有ディスクのディスク容量

「実行時のデータベースとデータ用のディスク容量」の値

リソースグループについて

NNMiは，設定するリソースグループがない状態からセットアップする必要があります。NNMiを既存のリソースグループに追加することはできません。

仮想IPアドレスおよび共有ディスクの使用がサポートされ，NNMiから使用できる構成にしてください。

共有ディスクについて

NNMiの共有データは次の場所に格納されます。ディレクトリ名に空白を含めることはできません。ディレクトリ名「NNM」は固定です。

Windows：<ドライブ文字>:¥NNM （例 Y:¥NNM）または<ドライブ文字>:¥<任意のディレクトリ>¥NNM （例 Y:¥JP1¥NNM）

Linux：<マウントポイント>/NNM （例 /shdsk1/NNM）

共有ディスクは，Fibre（FC-SAN），SCSI，iSCSIで接続されたストレージを使用してください。NFS接続やCIFS接続のNASなどを使う構成はNNMiではサポートしていません。

Windows：共有ディスクには，ドライブ文字を割り当てたディスクを使用してください。 [ディスクの管理]でのマウント設定やmountvolコマンドによってマウントしたディスクは使用しないでください。マニュアル上にマウントと書かれている個所はLinuxを対象とした説明です。

Windows：Microsoft Cluster Serviceを使用しているWindows Serverのクラスタリングでは，ダイナミックディスクはサポートされていません。

NNMiの前提とするOSやクラスタソフトが，NNMiが共有ディスクと同様にアクセスできるようにディスク（ファイル）領域を提供するのであれば，そのようなディスク領域の使用もサポートします。

具体的には，次が条件となります。

NNMiから，ディスクの「マウントするディレクトリ」にアクセスできる。

アクティブ側のNNMiからは上記ディレクトリに制限なくアクセスでき，スタンバイ側のNNMiからはアクセスできない。

フェイルオーバーの前後で，ディスクの「マウントするディレクトリ」内のデータに差異がない。

仮想IPアドレスについて

仮想IPアドレスと仮想ホスト名は，DNSなどのネームサービスまたはhostsファイルに対して，ホスト名からIPアドレスおよび逆にIPアドレスからホスト名が変換できるように設定してください。

DNSなどのネームサービスを使う場合も，hostsファイルに仮想IPアドレスと仮想ホスト名が名前解決できるように設定してください。これは通信障害が発生してフェイルオーバーする場合に，名前解決ができないでフェイルオーバー処理が失敗することを防止するためです。

IPv6の論理IPアドレスをリソースとして設定する場合，「19.4　HAを設定する」の手順のあとに手動で追加してください。設定手順については，クラスタソフトのマニュアルなどを参照してください。

IPv6が使用できるクラスタソフトのバージョン，IPv6を使用する場合の構成，IPv6/IPv4の混在可否などは，クラスタソフトの仕様に依存します。

仮想ホスト名について

クラスタ環境構築時，仮想ホスト名はIPv4のアドレスで名前解決されるようにしてください。

19.3　HA設定の注意事項

HA設定の注意事項を次に示します。

19.3.1　関連製品を使用する場合の注意

NNMiの関連製品，例えば，JP1/SNMP System Observer（JP1/SSO）やJP1/Integrated Management 3 - Event Gateway for Network Node Manager i（JP1/IM-EG）などを使用する場合は，次のように設定してください。

最初にNNMiをセットアップし，その後に関連製品をセットアップしてください。なお，HA構成を解除する場合は，セットアップ時と逆順にしてください。（NNMiを最後に解除してください。）

NNMiと，関連製品は，同一のリソースグループに登録します。

このとき，クラスタソフトに設定するリソースの依存関係は次のとおりです。

関連製品は，NNMiを前提とする依存関係を設定します。

NNMiは，共有ディスクおよび仮想IPアドレスを前提とする依存関係を設定します。Windowsの場合，追加でネットワーク名リソースについても依存関係を設定します。

JP1/Integrated Management 2（JP1/IM2）またはJP1/Integrated Management 3（JP1/IM3）のカスタムUI連携を使用する場合，JP1/IM2またはJP1/IM3とNNMiは同一のリソースグループに登録する必要があります。ただし，NNMiとの依存関係の設定は任意です。

関連製品の設定方法は，それぞれのマニュアル，リリースノート，取扱説明書を参照してください。

19.3.2　設定作業や運用操作の注意

NNMiのHA構成を設定や操作する場合は，次の状態で操作してください。

操作するOSユーザーには，クラスタソフトの全操作が可能な権限を付与してください。クラスタソフトに対してNNMiのリソース作成やリソースグループの起動停止などの操作を行うため，これらの操作権限が必要です。

クラスタソフトが動作している状態で操作をしてください。NNMiのHA構成用の各種コマンドは，クラスタソフトに対し，設定や構成確認などの処理を行います。クラスタソフトが停止している場合はエラーが発生します。

このマニュアルおよびリリースノートに記載されている手順によってNNMiサービスを再起動する場合，特に断りのないかぎり，HAクラスタ環境ではメンテナンスモードに設定してから実行してください。

ドキュメントなどで特に断りのないかぎり，コマンド実行やローカルファイルの編集はNNMiのリソースグループがオンラインの状態で実施してください。

また，実施後3分以内にフェイルオーバーしないようにしてください。

リソースグループがオフラインの状態でコマンド実行やローカルファイルの編集を実施した場合や，実施後3分以内にフェイルオーバーした場合は，古い設定で上書きされるおそれがあります。

NNMiリソースは，障害が発生した場合にフェイルオーバーすることを想定しています。

そのため，リソースグループで障害が発生した場合は，障害が発生した系で再起動しないで，フェイルオーバーするように設定してください。

設定方法についてはクラスタソフトのヘルプなどを参照してください。

障害によってフェイルオーバーが発生した環境で，フェイルバックでフェイルオーバー元に戻す場合は，発生した障害を回復し，残存するNNMiのプロセスをすべて停止したあとにフェイルバックしてください。

HAクラスタ環境でNNMiを使用する場合，プロセスダウンやディスク障害に伴い，ごくまれにNNMiのデータベースが破損することがあります。このため，定期的にバックアップを取得してください。

19.3.3　そのほかの注意

環境によっては，NNMiサービスの起動に10分以上掛かる場合があります。

（Windows（WSFC）の場合）フェイルオーバークラスタ管理コンソールに表示される<resource_group>-APPの状態には，「オンライン待ち」，「オフライン待ち」が表示されません。<resource_group>-APPが待ち状態であるかどうかは，フェイルオーバークラスタ管理コンソールの次の状態が「保留中」となっていることを確認してください。

［<クラスタ名>］＞［サービスとアプリケーション］＞［<resource_group>］の［<resource_group>の概要］の状態

（Windows（WSFC）の場合）資料採取ツールを実行したときにcluster.exe log /gを実行してcluster.logを作成してください。

19.4　HAを設定する

ここでは，NNMi用の新規HA設定の設定手順を説明します。

19.4.1　HA用のNNMi証明書を設定する

NNMiのインストールプロセスでは，NNMiコンソールとNNMiデータベースの間でセキュア通信が行われるよう，自己署名証明書を設定します。NNMi HAを正しく設定するプロセスでは，プライマリクラスタノードとセカンダリクラスタノードの間で自己署名証明書を共有します。HA下で実行されるNNMiでデフォルトの証明書を使用するために，追加の手順を実行する必要はありません。

NNMiの通信で別の自己署名証明書，または認証機関（CA）署名の証明書を使用する場合は，追加の手順を実行する必要があります。新しい証明書を入手してから，「10.3.6　高可用性環境での証明書の使用」に従って手順を実行します。この手順は，HA用NNMiを設定する前，または後に実行できます。

19.4.2　HA用にNNMiを設定する

ここでは，HA用にNNMiを設定する作業の流れ，および検討段階で決めておく設定情報について説明します。

HA用にNNMiを設定する場合の主な作業は，次の2つです。

NNMiデータファイルを共有ディスクにコピーする。

プライマリクラスタノードでこの作業を行います。

HA下でNNMiを実行するように，設定する。

プライマリクラスタノードでこの作業を行います。

セカンダリクラスタノードでこの作業を行います。

設定作業の流れを次に示します。

1つのHAクラスタノードを，プライマリNNMi管理サーバーとして割り当てます。これが大部分の時間にアクティブとなるノードです。プライマリクラスタノードとして設定します。次にHAクラスタ内の残りのノードをセカンダリクラスタノードとして設定します。

重要

HTTPS通信を使用してNNMiサーバーにアクセスする場合，プライマリクラスタノードの起動確認の前に，証明書を使用するように設定します。詳細については，「10.3.6　高可用性環境での証明書の使用」を参照してください。

メモ

HA用のNNMiの設定は，複数のクラスタノードで同時には行えません。プライマリクラスタノードでHA設定プロセスが完了したあと，セカンダリクラスタノードでのHA設定プロセスを開始する，というように，クラスタ環境内のノードを1つずつHA用に設定してください。

HAモニタおよびCLUSTERPROの場合は，nnmhaconfigure.ovplを使わないで設定作業を行います。設定方法については，リリースノートを参照してください。

フェイルオーバー中にはNNMiコンソールは応答しません。フェイルオーバーが完了してから，NNMiユーザーは，サインインしてNNMiコンソールのセッションを続行してください。

NNMiのTrapReceiverプロセス，およびそのフェイルオーバーとの関連に関する重要情報については，「21.16　NNMi NmsTrapReceiverプロセス」を参照してください。

(1)　NNMi HA設定情報

HA設定スクリプト（nnmhaconfigure.ovpl）は，NNMi HAリソースグループに関する情報を収集します。次の表に，プライマリクラスタノードの設定で必要になる情報を示します。設定作業を開始する前に，これらの情報を用意してください。

これらの情報は，設定作業時にHA設定スクリプト（nnmhaconfigure.ovpl）を実行して対話形式で入力します。入力要求がOSやHA製品の種類およびシステム構成に合わせて表示されますので，画面表示に従って入力してください。

表19‒3　NNMi HAプライマリクラスタノードの設定情報

HA設定項目

説明

HAリソースグループ

NNMiを含むHAクラスタのリソースグループの名前です。この名前はNNMiに対して一意であり，現在使用されていない名前にする必要があります。

（例）：nnmtest1

注記：HAリソースグループの名前に，空白を含む文字列は使用できません。

注記：名前に使用できる文字種，文字数はクラスタソフトによって異なります。詳しくは，表の欄外の説明を参照してください。

注記：HAリソースグループの名前は，ほかのリソース名やリソースグループ名の部分文字列（相手の文字列の一部または全部に一致する文字列）にならないようにしてください。例えば，リソースグループtestAが存在する場合，testやestなどの名称は使用できません。

注記：HAリソースグループ作成後に名前を変更することはできません。名前を変更するには，NNMiのHA設定を解除し，新しい名称でHA設定をし直してください。

仮想ホストの名前

仮想ホストの名前です。ドメイン名を含むFQDN名ではなく短い名前を指定します。このホスト名は，HAリソースグループの仮想IPアドレスにマッピングする必要があります。仮想ホストの短い名前と仮想IPアドレスを名前解決できる必要があります。

注記：HA設定の完了後に仮想ホスト名を変更することはできません。仮想ホスト名を変更するには，NNMiのHA設定を解除し，新しい名前でHA設定をし直してください。

注記：NNMiが仮想ホストの短い名前と仮想IPアドレスを解決できない場合は，HA設定スクリプトによって，システムが不安定な状態になる可能性があります。したがって，NNMi HAの設定中にDNSが利用できない場合に備えて，予備の手段（例えば，Windowsオペレーティングシステムの場合は，%SystemRoot%¥system32¥drivers¥etc¥hostsファイルに，Linuxオペレーティングシステムの場合は，/etc/hostsファイルに，それぞれ情報を記述する）を用意しておくことをお勧めします。

仮想ホストのネットマスク

仮想ホストIPアドレスで使われるサブネットマスクです。これは，IPv4アドレスであることが必要です。

仮想ホストのネットワークインタフェース

仮想ホストIPアドレスが使われるネットワークインタフェースです。

（例）

Windows：ローカルエリア接続

Linux：eth0

共有ファイルシステムのタイプ

HAリソースグループで使われる共有ディスクの設定タイプです。次のどちらかになります。

disk：共有ディスクは，標準のファイルシステムタイプを使う，物理的に接続されたディスクです。HA設定スクリプトは，共有ディスクを設定できます。詳細については，この表のファイルシステムタイプの欄を参照してください。

none：共有ディスクには，diskオプションで説明している設定以外のSANやNFS構成などを使います。HA設定スクリプトを実行すると，共有ディスクが設定されます。

注記：JP1/NNMiではnoneを指定した場合の動作はサポートしていません。必ずdiskを指定してください。

ファイルシステムタイプ

（Linuxだけ）

共有ディスクのファイルシステムタイプです（共有ファイルシステムのタイプがdiskの場合）。HA設定スクリプトは，ディスクの検証方法を調べるために，この値をHA製品に渡します。

次の共有ディスクフォーマットはテスト済みです。

VCSまたはSCSにはext2，ext3，およびvxfs

ディスクグループ

（Linuxだけ）

NNMi共有ファイルシステムのディスクグループの名前です。

（例）：shdg01

ボリュームグループ

（Linuxだけ）

NNMi共有ファイルシステムのボリュームグループの名前です。

例：vg03

マウントするディレクトリ

（マウントポイント）

NNMiの共有ディスクをマウントするディレクトリの場所です。このマウントポイントは，すべてのシステムで同じである必要があります（つまり，各ノードでは，マウントポイントに同じ名前を使う必要があります）。Windowsの場合，<ドライブ文字> または<ドライブ文字>:¥<任意のディレクトリ> を指定します。ディレクトリ名に空白を含めることはできません。

（例）

Windows：　Y:またはY:¥JP1

Linux：　/nnmmount

注記：NNMiの共有データは，上で指定したディレクトリ直下に作成されるNNMという格納先ディレクトリ内に保存されます（格納先ディレクトリのパスを次に示します）。格納先ディレクトリ名（NNM）は固定です。

Windows：　<ドライブ文字>:¥NNMまたは <ドライブ文字>:¥<任意のディレクトリ>¥NNM

Linux：　<マウントポイント>/NNM

注記：HAの設定完了後にマウントポイントを変更することはできません。Windowsの場合は，HAの設定完了後にマウントポイントのドライブ文字も変更することはできません。変更が必要な場合は，「19.7　HAクラスタ内のNNMiの設定を解除する」の手順でHAの設定を解除したあと，「19.4　HAを設定する」の手順で再度HAを設定してください。

NNMiのHAリソースグループの名前に使える文字の種類および文字数は，クラスタソフトによって異なります。NNMi用のHAリソースグループでは，次の範囲で名称を指定してください。

Windows WSFCの場合

文字種：

英字（a-z，A-Z），数字（0-9），ハイフン（-），アンダーバー（_），ピリオド（.）

文字数：%NnmDataDir%hacluster¥<resource_group>のパス名を含む文字列全体で247文字まで

Linux VCSまたはLinux SCSの場合

文字種：

英字（a-z，A-Z），数字（0-9），ハイフン（-），アンダーバー（_）

ただし先頭は英字

文字数：255文字まで

Linux HAモニタの場合

文字種：

英字（a-z，A-Z），数字（0-9）

ただし先頭は英字

文字数：8文字まで

Windows CLUSTERPROまたはLinux CLUSTERPROの場合

文字種：

英字（a-z，A-Z），数字（0-9），ハイフン（-），アンダーバー（_）

ただし先頭は英字

文字数：16文字まで

19.4.3　HA用にNNMiを設定する（Windowsの場合）

ここでは，Windows環境でHA用にNNMiを設定する手順を説明します。

NNMiのHA設定では，新規にNNMi用のリソースグループを作成します。このため，対象のリソースグループがない状態から設定作業を行ってください。

NNMiのHA設定を行うスクリプト（nnmhaconfigure.ovpl）は，内部的にクラスタソフトに対してリソースグループや各リソースを作成する処理を行います。設定作業が完了すると，次のリソースグループが設定されます。

表19‒4　WSFCでのNNMi用リソースグループの構成

リソースの名前

リソースの種類

説明

仮想ホスト名

ネットワーク名

仮想ホスト名を制御する

<resource_group>-IP

IPアドレス

仮想IPアドレスを制御する

<resource_group>-mount

物理ディスク

共有ディスクを制御する

<resource_group>-APP

汎用スクリプト

NNMiの起動/停止/監視を制御する

WSFCの場合，nnmhaconfigure.ovplがcluster.exeなどのコマンドを内部的に実行して上記のリソースの設定処理を行います。

<resource_group>の部分はHAリソースグループ名に置き換わります。

リソースの依存関係は，NNMi用の汎用スクリプトリソース<resource_group>-APPの前提に，<IPアドレスリソース>，<ディスクリソース>，<ネットワーク名リソース>を設定します。

重要

CLUSTERPROの場合は，nnmhaconfigure.ovplを使わずに設定作業を行います。設定方法については，リリースノートを参照してください。

(1)　WSFCの各リソースの設定内容の例

設定が完了したときのWSFCの各リソースの設定内容の例を次に示します。なお，<resource_group>の部分はHAリソースグループ名に置き換わります。

表19‒5　<ネットワーク名リソース>

項目

詳細

［全般］

リソース名：(仮想ホスト名)

リソースの種類：ネットワーク名

DNS名：(仮想ホスト名)

フルネーム：(仮想ホスト名).test.com

ネットワーク：192.168.100.0/24

IPアドレス：192.168.100.24

NetBIOS状態：OK

DNS状態：OK

kerberos状態：OK

［依存関係］

<IPアドレスリソース>

［ポリシー］

［リソースが失敗状態になった場合は，現在のノードで再起動を試みる］を有効

再起動間隔：15:00

指定期間内での再起動の試行回数：0

［再起動に失敗した場合は，このサービスまたはアプリケーションのすべてのリソースをフェールオーバーする］を有効

保留タイムアウト：03:00

［詳細なポリシー］

基本的なリソース正常性チェックの間隔［リソースの種類の標準間隔を使用する］

完全なリソース正常性チェックの間隔［リソースの種類の標準間隔を使用する］

［このリソースを別のリソース モニタで実行する］を無効

表19‒6　<IPアドレスリソース>

項目

詳細

［全般］

リソース名：<resource_group>-IP

リソースの種類：IPアドレス

ネットワーク：192.168.100.0/24

静的IPアドレス：192.168.100.24 ※

［このアドレスのNetBIOSを有効にする］を有効

［依存関係］

依存関係なし

［ポリシー］

［リソースが失敗状態になった場合は，現在のノードで再起動を試みる］を有効

再起動間隔：15:00

指定期間内での再起動の試行回数：0

［再起動に失敗した場合は，このサービスまたはアプリケーションのすべてのリソースをフェールオーバーする］を有効

保留タイムアウト：03:00

［詳細なポリシー］

基本的なリソース正常性チェックの間隔［リソースの種類の標準間隔を使用する］

完全なリソース正常性チェックの間隔［リソースの種類の標準間隔を使用する］

［このリソースを別のリソース モニタで実行する］を無効

注※　DHCPは有効にしません。

表19‒7　<物理ディスクリソース>

項目

詳細

［全般］

リソース名：<resource_group>-mount

リソースの種類：物理ディスク

ボリューム：Y:

［依存関係］

依存関係なし

［ポリシー］

［リソースが失敗状態になった場合は，現在のノードで再起動を試みる］を有効

再起動間隔：15:00

指定期間内での再起動の試行回数：0

［再起動に失敗した場合は，このサービスまたはアプリケーションのすべてのリソースをフェールオーバーする］を有効

保留タイムアウト：03:00

［詳細なポリシー］

基本的なリソース正常性チェックの間隔［リソースの種類の標準間隔を使用する］

完全なリソース正常性チェックの間隔［リソースの種類の標準間隔を使用する］

［このリソースを別のリソース モニタで実行する］を無効

表19‒8　<汎用スクリプトリソース>

項目

詳細

［全般］

リソース名：<resource_group>-APP

リソースの種類：汎用スクリプト

スクリプトのパス※：

%NnmDataDir%hacluster/<resource_group>/hamscs.vbs

［依存関係］

<ネットワーク名リソース>，<IPアドレスリソース>および <ディスクリソース>

［ポリシー］

［リソースが失敗状態になった場合は，現在のノードで再起動を試みる］を有効

再起動間隔：15:00

指定期間内での再起動の試行回数：0

［再起動に失敗した場合は，このサービスまたはアプリケーションのすべてのリソースをフェールオーバーする］を有効

保留タイムアウト：30:00

［詳細なポリシー］

基本的なリソース正常性チェックの間隔［リソースの種類の標準間隔を使用する］

完全なリソース正常性チェックの間隔［リソースの種類の標準間隔を使用する］

［このリソースを別のリソース モニタで実行する］を有効

注※

スクリプトのパスは，環境変数を展開したフルパスが設定されます。

（例）

C:/ProgramData/Hitachi/Cm2NNMi/hacluster/jp1ha1/hamscs.vbs

(2)　プライマリクラスタノードでのNNMiの設定

プライマリクラスタノードで次の手順を実行します。

(a)　前準備

「19.2　HA用NNMiを設定するための前提条件の検証」の作業が完了していることを確認する。

NNMiがインストールされていない場合は，インストールする。そして，NNMiが正しく動作することを確認する。

次のコマンドを使って，NNMi設定をバックアップする。

（例）

nnmbackup.ovpl -scope all -target nnmi_backups

このコマンドの詳細については，「20.　NNMiのバックアップおよびリストアツール」を参照してください。

NNMiのクラスタ環境構成において初期状態では，プライマリクラスタノードのデータと，セカンダリクラスタノードのデータが完全に一致している必要があります。このため，ここで取得したバックアップデータを，セカンダリクラスタノードの設定手順でリストアし，データを一致させます。

(b)　データの共有ディスクへのコピー

NNMi HAリソースグループ用に，共有ディスクを用意する。

Windows Explorerとディスクの管理ツールを使用してドライブ名を割り当てます。

重要

用意した共有ディスクが，次の条件を満たすことを確認してください。

ディスクの管理ツールを使用して，共有ディスクで［オンライン］と表示されるようにします。［予約］と表示される場合，これはWSFCが共有ディスクを制御することを示しています。WSFCユーザーインタフェースから［削除］アクションを使用して，共有ディスクをWSFCコントロールから削除します。また，ディスクの管理ツールを使用して，［予約］フラグが［オンライン］に変更されることも確認します。

フォーマット済みである

十分な空き容量がある

ほかのリソースグループで使用されていない

管理者権限のユーザーへの「フルコントロール」，およびビルトインLocal Serviceユーザー（Usersグループ）への「読み取りと実行」の権限がある

NNMiを停止する。

%NnmInstallDir%bin¥ovstop -c
net stop NnmTrapReceiver

NNMiファイルを共有ディスクにコピーする。

%NnmInstallDir%misc¥nnm¥ha¥nnmhadisk.ovpl NNM -to <HA_mount_point>

重要

<HA_mount_point>には，共有ディスクのドライブまたは共有ディスクドライブ配下の任意のディレクトリを指定します（例 Y:またはY:¥JP1など）。

ディレクトリ名に空白を含めることはできません。

指定したパス直下に，ディレクトリ「NNM」が作成されます（例 Y:¥NNM または Y:¥JP1¥NNM）。

格納先ディレクトリ名は変更できません。

(c)　NNMiのHA設定

NNMi HAリソースグループを新規に作成する。

%NnmInstallDir%misc¥nnm¥ha¥nnmhaconfigure.ovpl NNM

このコマンドの設定項目については，「19.9.2　NNMiに付属しているHA設定スクリプト」を参照してください。

共有ディスクタイプはnoneではなく，必ずdiskを指定してください。また，共有ディスクのパスは，(b)の手順3.で指定したパスを指定してください。

（設定例）

HA設定項目は，nnmhaconfigure.ovplに対話形式で入力する項目を表示順に並べています。「19.4.2　HA用にNNMiを設定する」の「表19‒3　NNMi HAプライマリクラスタノードの設定情報」の説明によって検討した内容を入力してください。

HA設定項目

設定例

HAリソースグループの名前

jp1ha1

仮想ホストの名前

lhost1

仮想ホストのネットワークインタフェース

ローカルエリア接続

共有ファイルシステムのタイプ

disk（必ずdiskを指定）

マウントするディレクトリ

Yドライブ

重要

設定コマンドを実行する前に，次の注意事項を確認してください。

既にほかのリソースグループやリソースで使われている値をnnmhaconfigure.ovplに指定すると，リソースの作成が失敗するなどエラーが発生します。ほかで使われていないことを確認してから，nnmhaconfigure.ovplを実行してください。

既に使われているリソースグループ名，IPアドレスやディスクを指定した場合，リソースを作成するために実行したクラスタソフトのコマンドがエラーとなります。エラー発生時点でnnmhaconfigure.ovplは異常終了し，それまでに作成されたリソースグループやリソースは残ったままとなります。エラーを対処してnnmhaconfigure.ovplを再実行する前に，クラスタソフトの操作で残っているリソースを削除してください。

仮想アドレスを設定するネットワークインタフェースは次を確認してください。

フェイルオーバークラスタ管理コンソールの［ネットワーク］で論理IPアドレスのネットワークアドレスを含むリソースを確認します。

（実行例）

設定例の値を指定した場合の画面表示例です。" ? "の後ろが入力する項目です。

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥misc¥nnm¥ha>nnmhaconfigure.ovpl NNM
質問: HA リソース グループの名前を入力してください:  ? jp1ha1

プライマリ ノードの設定が検出されました。

質問: 有効な仮想ホストの名前を入力してください:  ? lhost1
使用可能なネットワーク インタフェース:

ネットワーク サブネット マスク  ネットワーク インタフェース
255.255.255.0           クラスタ ネットワーク 3
255.255.255.0           クラスタ ネットワーク 1

選択可能な値:
1: クラスタ ネットワーク 3
2: クラスタ ネットワーク 1
質問: 仮想ホストのネットワーク インタフェースを入力してください:  ? 2
選択可能な値:
1: disk
2: none
質問: 共有ファイル システムのタイプを入力してください (disk，none):  ? 1
質問: ディスクをマウントするディレクトリを入力してください:  ? Y:
リソース グループを作成しています。

リソース グループ 'jp1ha1' を作成しています...

グループ             ノード          状態
-------------------- --------------- ------
jp1ha1               NNMX64-33       オフライン

リソース 'lhost1' を作成しています...

リソース             グループ             ノード          状態
-------------------- -------------------- --------------- ------
lhost1               jp1ha1               NNMX64-33       オフライン

リソース 'lhost1' をリソース 'jp1ha1-IP' に依存させています...

HA 値の C:/ProgramData/Hitachi/Cm2NNMi/shared/nnm/conf/ov.conf を設定しています。
HP OpenView Process Manager サービスの自動スタートアップを無効にしています。
[SC] ChangeServiceConfig SUCCESS
注: 指定されている仮想ホスト名に一致するようにNNMi FQDNを更新しています。fqdn を lhost1.xxx.xxx に設定しています

ドメインを xxx.xxx に設定しています

Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

新しい SSL 証明書を生成しています。

lhost1.xxx.xxx.selfsigned のキーストアの証明書を生成しています。
[成功]

生成された証明書をトラストストアにエクスポートしています。

証明書がファイル<temporary.cert>に保存されました。
証明書がキーストアに追加されました。

C:¥Program Files (x86)¥ Hitachi¥Cm2NNMi¥misc¥nnm¥ha>

監視プロセスに異常が発生した場合，フェイルオーバーするよう<resource_group>を設定する。

<resource_group>-APPのプロパティを開き，［ポリシー］タブを押下する。

［リソースが失敗状態になった場合は，現在のノードで再起動を試みる］が選択されていることを確認し，［指定期間内での再起動の試行回数］を0に設定する。

［再起動の試みがすべて失敗した場合は，指定した時間（hh:mm）後にもう一度再起動を開始する(S)］にチェックがある場合は外してください。

重要

<resource_group>および<resource_group>に登録したリソースの設定によって，エラー発生時の動作などを指定します。各設定項目の役割についてはクラスタサービスのヘルプを参照ください。

プライマリクラスタノード上で，NNMTrapReceiverサービスの自動起動を無効にする。

スタートメニューの［管理ツール］＞［サービス］で［NNM Trap Receiver］および［NNM Trap Receiver Manager］を選択し，「スタートアップの種類」を「手動」に設定してください。

プライマリクラスタノード上で，クラスタサービスを再起動する。

再起動によって，これまでの設定内容が反映され，NNMiの環境変数が読み込まれます。なおnet stop ClusSvc，net start ClusSvcコマンドを実行することで，サービスの起動停止ができます。

重要

HTTPS通信を使用してNNMiサーバーにアクセスする場合，証明書を使用するように設定します。詳細については，「10.3.6　高可用性環境での証明書の使用」を参照してください。

(d)　起動の確認

NNMi HAリソースグループを起動する。

起動コマンドは，プライマリクラスタノードで実行します。

次の起動コマンドを実行します。

%NnmInstallDir%misc¥nnm¥ha¥nnmhastartrg.ovpl NNM <resource_group>

<resource_group>が起動したことを確認します。

NNMiを正常に起動できなかった場合は，「19.8　HA設定のトラブルシューティング」を参照してください。

これで，NNMiがHA下で動作するようになりました。

重要

HA構成のNNMiの通常のオペレーションでは，ovstartコマンドやovstopコマンドは使わないでください。これらのコマンドは，メンテナンスを目的として操作手順に明示されている場合だけ使用します。HA構成のNNMiの起動や停止は，クラスタソフトの操作によってHAリソースグループを起動または停止するようにしてください。

(3)　セカンダリクラスタノードでのNNMiの設定

(a)　前準備

「19.2　HA用NNMiを設定するための前提条件の検証」の作業が完了していることを確認する。

NNMiがインストールされていない場合は，NNMiをインストールし，正しく動作することを確認する。

リストアをする。

「(2)　プライマリクラスタノードでのNNMiの設定」の(a)の手順3.で取得したバックアップデータをセカンダリクラスタノードにリストアします。

%NnmInstallDir%bin¥nnmrestore.ovpl -force -partial -source <backup_data>

このコマンドの詳細については，「20.　NNMiのバックアップおよびリストアツール」を参照してください。

(b)　NNMiのHA設定

NNMiを停止する。

%NnmInstallDir%bin¥ovstop -c
net stop NnmTrapReceiver

NNMi HAリソースグループを設定する。

%NnmInstallDir%misc¥nnm¥ha¥nnmhaconfigure.ovpl NNM

コマンドの要求に応じて，HAリソースグループ名を指定します。

（実行例）

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥misc¥nnm¥ha>nnmhaconfigure.ovpl NNM
質問: HA リソース グループの名前を入力してください:  ? jp1ha1
セカンダリ ノードの設定が検出されました。

HP OpenView Process Manager サービスの自動スタートアップを無効にしています。
[SC] ChangeServiceConfig SUCCESS
注: 指定されている仮想ホスト名に一致するようにNNMi FQDNを更新しています。fqdn を lhost1.xxx.xxx に設定しています

ドメインを xxx.xxx に設定しています

Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

新しい SSL 証明書を生成しています。

C:¥Program Files (x86)¥ Hitachi¥Cm2NNMi¥misc¥nnm¥ha>

セカンダリクラスタノード上で，NNMTrapReceiverサービスの自動起動を無効にする。

スタートメニューの［管理ツール］＞［サービス］で［NNM Trap Receiver］および［NNM Trap Receiver Manager］を選択し，「スタートアップの種類」を「手動」に設定してください。

設定が正常に行われたことを確認する。

%NnmInstallDir%misc¥nnm¥ha¥nnmhaclusterinfo.ovpl -group <resource_group> -nodes

このコマンドの出力には，指定したHAリソースグループに設定されたすべてのノードがリストされます。

セカンダリクラスタノード上で，クラスタサービスを再起動する。

再起動によって，これまでの設定内容が反映され，NNMiの環境変数が読み込まれます。なおnet stop ClusSvc，net start ClusSvcコマンドを実行することで，サービスの起動停止ができます。

（任意）プライマリクラスタノードのリソースグループをオフラインにし，セカンダリクラスタノードのリソースグループをオンラインにすることで，設定をテストする。

重要

作成したリソースグループについて，リソースグループおよびリソースの設定をNNMiの標準値から変更することでサービスが正常に起動しないなどの問題が発生するおそれがあります。

特に，次の設定を標準値より小さい値に変更する場合は，注意が必要です。

リソースに障害が発生したときに，Clusterサービスがリソースを再起動するまでの期間

WSFC標準インストールの場合

<resource_group>-APPのプロパティ［ポリシー］タブの保留タイムアウトの値（標準設定値30:00分）

<resource_group>-APPのDeadlockTimeoutの値（標準設定値2,700,000ミリ秒)

19.4.4　HA用にNNMiを設定する（Linuxの場合）

ここでは，Linux環境でHA用にNNMiを設定する手順を説明します。

NNMiのHA設定では，新規にNNMi用のリソースグループを作成します。このため，対象のリソースグループがない状態から設定作業を行ってください。

NNMiのHA設定を行うスクリプト（nnmhaconfigure.ovpl）は，内部的にクラスタソフトに対してリソースグループや各リソースを作成する処理を行います。設定作業が完了すると，次のリソースグループが設定されます。

表19‒9　Veritas Cluster ServerまたはSymantec Cluster ServerでのNNMi用リソースグループの構成

リソース名

リソースタイプ

説明

<resource_group>-ip

IP

仮想IP アドレスを制御する

<resource_group>-dg

DiskGroup

ディスクグループを制御する

<resource_group>-volume

Volume

ボリュームを制御する

<resource_group>-mount

Mount

共有ファイルシステムを制御する

<resource_group>-app

Application

NNMiの起動/停止/監視を制御する

VCSまたはSCSの場合，nnmhaconfigure.ovplがhagrpやharesなどのコマンドを内部的に実行して上記のリソースの設定処理を行います。

<resource_group>の部分はHAリソースグループ名に置き換わります。

リソースの依存関係は，Volumeの前提にDiskGroupとIP，Mountの前提にVolume，およびApplicationの前提にMountとIPがそれぞれ設定されます。

VCSまたはSCSがネットワークインタフェースを監視するリソース（VCSまたはSCSのNIC）は設定されません。必要に応じて追加設定をしてください。

NNMiの起動処理に時間が掛かりタイムアウトが発生する場合は，「19.8　HA設定のトラブルシューティング」を参照して，<resource_group>-appのOnlineTimeout設定を調整してください。

各リソースの設定内容の例を次に示します。

（例）VCSまたはSCSの設定ファイルmain.cfの定義例

<>で囲んだ部分は，nnmhaconfigure.ovplで指定した設定項目の値になります。

group <resource_group> (
  SystemList = { <node1> = 1 , <node2> = 1}
  UserStrGlobal = "NNM_INTERFACE=<virtual_host>;HA_LOCALE=<LOCALE>;HA_MOUNT_POINT=<mountpoint>"
  )

  Application <resource_group>-app (
     StartProgram = "/opt/OV/misc/nnm/ha/nnmharg.ovpl NNM -start <resource_group>"
     StopProgram = "/opt/OV/misc/nnm/ha/nnmharg.ovpl NNM -stop <resource_group>"
     CleanProgram = "/opt/OV/misc/nnm/ha/nnmharg.ovpl NNM -clean <resource_group>"
     MonitorProgram = "/opt/OV/misc/nnm/ha/nnmharg.ovpl NNM -monitor
                       <resource_group>"
     OnlineTimeout = 1800
     )
  DiskGroup <resource_group>-dg (
     DiskGroup = <disk_group>
     )
  IP <resource_group>-ip (
     Device = <network_interface_of_virtual_host>
     Address = "10.208.228.159"
     NetMask = "255.255.255.0"
     )
  Mount <resource_group>-mount (
     MountPoint = "<mountpoint>"
     BlockDevice = "/dev/vx/dsk/<disk_group>/<volume_group>"
     FSType = <type_of_shared_file_systems>
     FsckOpt = "-y"
     )
  Volume <resource_group>-volume (
     Volume = <volume_group>
     DiskGroup = <disk_group>
     )
  <resource_group>-app requires <resource_group>-ip
  <resource_group>-app requires <resource_group>-mount
  <resource_group>-mount requires <resource_group>-volume
  <resource_group>-volume requires <resource_group>-dg
  <resource_group>-volume requires <resource_group>-ip

表19‒10　HAモニタでのNNMi用リソースグループの構成

設定項目

設定内容（制御スクリプト）

name （起動）

/var/opt/OV/hacluster/<resource_group>/cm2_start.sh

termcommand （停止）

/var/opt/OV/hacluster/<resource_group>/cm2_stop.sh

patolcommand （監視）

/var/opt/OV/hacluster/<resource_group>/cm2_monitor.sh

<resource_group>の部分はHAリソースグループ名に置き換わります。

重要

HAモニタおよびCLUSTERPROの場合は，nnmhaconfigure.ovplを使わずに設定作業を行います。設定方法については，リリースノートを参照してください。

(1)　プライマリクラスタノードでのNNMiの設定

プライマリクラスタノードで次の手順を実行します。

(a)　前準備

「19.2　HA用NNMiを設定するための前提条件の検証」の作業が完了していることを確認する。

NNMiがインストールされていない場合は，インストールする。そして，NNMiが正しく動作することを確認する。

次のコマンドを使って，NNMi設定をバックアップする。

（例）

/opt/OV/bin/nnmbackup.ovpl -scope all -target <directory>

このコマンドの詳細については，「20.　NNMiのバックアップおよびリストアツール」を参照してください。

NNMiのクラスタ環境構成において初期状態では，プライマリクラスタノードのデータと，セカンダリクラスタノードのデータが完全に一致している必要があります。このため，ここで取得したバックアップデータを，セカンダリクラスタノードの設定手順でリストアし，データを一致させます。

(b)　データの共有ディスクへのコピー

共有ディスクのマウントポイントになるディレクトリを作成する。

NNMi HAリソースグループ用に，共有ディスクを用意する。

重要

用意した共有ディスクが，次の条件を満たすことを確認してください。

フォーマット済みである

十分な空き容量がある

ほかのリソースグループで使用されていない

共有ディスクをアクティブ化して，マウントする。

（例）

Linux VCSまたはSCSでディスク管理にVxVM/VxFSを使う構成の場合

vxdg import <disk_group>
vxvol -g <disk_group> startall
mount -t vxfs /dev/vx/dsk/<disk_group>/<volume> <HA_mount_point>

共有ディスクのマウントポイントディレクトリが，ユーザーはroot，グループはrootで，パーミッションには755が設定されていることを確認します。

（例）

ls -l

NNMiを停止する。

/opt/OV/bin/ovstop -c

/opt/OV/bin/nettrap stop

NNMiファイルを共有ディスクにコピーする。

/opt/OV/misc/nnm/ha/nnmhadisk.ovpl NNM -to <HA_mount_point>

重要

指定したマウントポイント直下に，ディレクトリ「NNM」が作成されます（<HA_mount_point>/NNM）。

格納先ディレクトリ名を変更することはできません。

共有ディスクをマウント解除し，非アクティブ化する。

（例）

VCSまたはSCSかつVxVM/VxFS使用構成の場合

umount <HA_mount_point>

vxvol -g <disk_group> stopall

vxdg deport <disk_group>

(c)　NNMiのHA設定

NNMi HAリソースグループを新規に作成する。

/opt/OV/misc/nnm/ha/nnmhaconfigure.ovpl NNM

このコマンドの設定項目については，「19.9.2　NNMiに付属しているHA設定スクリプト」を参照してください。

共有ディスクタイプはnoneではなく，必ずdiskを指定してください。

（設定例）

HA設定項目は，nnmhaconfigure.ovplに対話形式で入力する項目を表示順に並べています。「19.4.2　HA用にNNMiを設定する」の「表19‒3　NNMi HAプライマリクラスタノードの設定情報」の説明によって検討した内容を入力してください。

HA設定項目

設定例

HAリソースグループの名前

jp1ha1

仮想ホストの名前

lhost1

仮想ホストのネットワークインタフェース

lan0

共有ファイルシステムのタイプ

disk（必ずdiskを指定）

ディスクタイプ

vxfs

ディスクグループ（VCSまたはSCSだけ）

shdg3

ボリュームグループ

vg03

マウントするディレクトリ

/shdsk1

重要

設定コマンドを実行する前に，次の注意事項を確認してください。

HA構成のNNMiはnnmhaconfigure.ovpl実行時のロケールを使用して起動します。nnmhaconfigure.ovpl実行時に操作する画面に適切なロケール（LANG環境変数）が設定されていることを確認してください。

Linux VCSまたはLinux SCSの場合：ja_JP.utf8，ja_JP.UTF-8，C，en_US.utf8，en_US.UTF-8，またはzh_CN.utf8

HA構成の設定後にロケールを変更する場合は，「19.6　HA設定のメンテナンス」を参照してください。

すでにほかのリソースグループやリソースで使われている値をnnmhaconfigure.ovplに指定すると，リソースの作成が失敗するなどエラーが発生します。ほかで使われていないことを確認してから，nnmhaconfigure.ovplを実行してください。

すでに使われているリソースグループ名，IP アドレスやディスクを指定した場合，リソースを作成するために実行したクラスタソフトのコマンドがエラーとなります。エラー発生時点でnnmhaconfigure.ovplは異常終了し，それまでに作成されたリソースグループやリソースは残ったままとなります。エラーを対処してnnmhaconfigure.ovplを再実行する前に，クラスタソフトの操作で残っているリソースを削除してください。

nnmhaconfigure.ovpl実行時に，次のメッセージが出力される場合がありますが，内部処理でのメッセージであり問題ありません。

「ディスク グループが見つかりません。インポートを試みます。」

「Unable to perform the security token exchange with cmclconfd on node xxxxx

Cannot connect to configuration daemon (cmclconfd) on node xxxxx」

（実行例）

設定例の値を指定した場合の画面表示例です。" ? "の後ろが入力する項目です。

VCSまたはSCS (Linux)の場合の実行例

# /opt/OV/misc/nnm/ha/nnmhaconfigure.ovpl NNM
質問: HA リソース グループの名前を入力してください:  ? jp1ha1

プライマリ ノードの設定が検出されました。

質問: 有効な仮想ホストの名前を入力してください:  ? lhost1
情報: ネットワーク インタフェース情報の使用:

ネットワーク インタフェース: bond0
ネットワーク サブネット マスク: 255.255.255.0

選択可能な値:
1: disk
2: none
質問: 共有ファイル システムのタイプを入力してください (disk，none):  ? 1

選択可能な値:
1: vxfs
2: ext2
3: ext3
質問: ディスク タイプの名前を入力してください:  ? 1
質問: ディスク グループの名前を入力してください:  ? shdg3
ディスク グループが見つかりません。インポートを試みます。
質問: ボリューム グループの名前を入力してください:  ? shvol3
質問: ディスクをマウントするディレクトリを入力してください:  ? /shdsk1
リソース グループを作成しています。
VCS NOTICE V-16-1-10136 Group added; populating SystemList and setting the Parallel attribute recommended before adding resources
HA 値の /var/opt/OV/shared/nnm/conf/ov.conf を設定しています。
ブート スクリプトを削除しています。
注: 指定されている仮想ホスト名に一致するようにNNMi FQDNを更新しています。fqdn を lhost1 に設定しています。

ドメインを xxx.xxx に設定しています。

新しい SSL 証明書を生成しています。

lhost1.xxx.xxx.selfsigned のキーストアの証明書を生成しています。
[成功]

生成された証明書をトラストストアにエクスポートしています。

証明書がファイル<temporary.cert>に保存されました。
証明書がキーストアに追加されました。
#

プライマリクラスタノード上で，サービスの自動起動を無効にする。

次のコマンドを実行し，サービスの自動起動を無効化します。

systemctl disable netmgt.service

systemctl disable nettrap.service

systemctl stop netmgt.service

systemctl stop nettrap.service

VCSまたはSCSの場合，作成したリソースを有効化（Enabledを1に設定）する。

例

hares -modify <resource_group>-app Enabled 1

hares -modify <resource_group>-dg Enabled 1

hares -modify <resource_group>-ip Enabled 1

hares -modify <resource_group>-mount Enabled 1

hares -modify <resource_group>-volume Enabled 1

その後，VCSまたはSCSの設定を読み取り専用にして，VCSまたはSCSの設定ファイルmain.cf を出力させます。

haconf -dump -makero

VCSまたはSCSがネットワークインタフェースを監視するリソース（VCSまたはSCSのNIC，MultiNICA，MultiNICBなど）は設定されていませんので，必要に応じて追加設定をしてください。

重要

HTTPS通信を使用してNNMiサーバーにアクセスする場合，証明書を使用するように設定します。詳細については，「10.3.6　高可用性環境での証明書の使用」を参照してください。

(d)　起動の確認

NNMi HAリソースグループを起動する。

/opt/OV/misc/nnm/ha/nnmhastartrg.ovpl NNM <resource_group>

このコマンドは， HAリソースグループの起動を待ってから，プロンプトを返します。本コマンドでリソースグループの起動を確認してください。

NNMiを正常に起動できなかった場合は，「19.8　HA設定のトラブルシューティング」を参照してください。

これで，NNMiがHA下で動作するようになりました。

重要

HA構成のNNMiの通常のオペレーションでは，ovstartコマンドやovstopコマンドは使わないでください。これらのコマンドは，メンテナンスを目的として操作手順に明示されている場合だけ使用します。HA構成のNNMiの起動や停止は，クラスタソフトの操作によってHAリソースグループを起動または停止するようにしてください。

(2)　セカンダリクラスタノードでのNNMiの設定

(a)　前準備

「19.2　HA用NNMiを設定するための前提条件の検証」の作業が完了していることを確認する。

NNMiがインストールされていない場合は，NNMiをインストールし，正しく動作することを確認する。

リストアをする。

「(1)　プライマリクラスタノードでのNNMiの設定」の(a)の手順3.で取得したバックアップデータをセカンダリクラスタノードにリストアします。

/opt/OV/bin/nnmrestore.ovpl -force -partial -source <backup_data>

このコマンドの詳細については，「20.　NNMiのバックアップおよびリストアツール」を参照してください。

(b)　NNMiのHA設定

共有ディスクのマウントポイントを作成する。

このマウントポイントでは，「(1)　プライマリクラスタノードでのNNMiの設定」の(b)の手順1.で作成したマウントポイントと同じ名前を使う必要があります。

NNMiを停止する。

/opt/OV/bin/ovstop -c

/opt/OV/bin/nettrap stop

NNMi HAリソースグループを設定する。

/opt/OV/misc/nnm/ha/nnmhaconfigure.ovpl NNM

コマンドの要求に応じて，HAリソースグループ名を指定します。

（実行例）

# /opt/OV/misc/nnm/ha/nnmhaconfigure.ovpl NNM

質問: HA リソース グループの名前を入力してください:  ? jp1ha1
セカンダリ ノードの設定が検出されました。
Completed the cluster update
ブート スクリプトを削除しています。
注: 指定されている仮想ホスト名に一致するようにNNMi FQDNを更新しています。fqdn を lhost1.xxx.xxx に設定しています。

ドメインを .xxx.xxx に設定しています。

新しい SSL 証明書を生成しています。

#

セカンダリクラスタノード上で，サービスの自動起動を無効にする。

次のコマンドを実行し，サービスの自動起動を無効化します。

systemctl disable netmgt.service

systemctl disable nettrap.service

systemctl stop netmgt.service

systemctl stop nettrap.service

VCSまたはSCSの場合，HAクラスタに設定変更を反映させる。

haconf -dump -makero

設定が正常に行われたことを確認する。

/opt/OV/misc/nnm/ha/nnmhaclusterinfo.ovpl -group <resource_group> -nodes

このコマンドの出力には，指定したHAリソースグループに設定されたすべてのノードがリストされます。

（任意）プライマリクラスタノードのリソースグループをオフラインにし，セカンダリクラスタノードのリソースグループをオンラインにすることで，設定をテストする。

19.5　共有NNMiデータ

HA環境で実行するNNMiは，HAクラスタ内のNNMiノード間でファイルを共有するために，各NNMiノードからアクセス可能でHA製品によって制御された共有ディスクを使う必要があります。

重要

共有ディスクにNFS接続やCIFS接続を使う構成はサポートしていません。

19.5.1　NNMiの共有ディスク内のデータ

NNMiをHA下で実行する場合に，共有ディスクで管理されるNNMiのデータファイルは次のとおりです。

ファイルの場所は，次のように，共有ディスク内の場所にマッピングされます。

Windows

−%NnmDataDir%は，%HA_MOUNT_POINT%¥NNM¥dataDirにマッピングされます。

Linux

−$NnmDataDirは，$HA_MOUNT_POINT/NNM/dataDirにマッピングされます。

共有ディスクに移動される主なディレクトリは，次のとおりです。

Windows

−%NnmDataDir%shared¥nnm¥databases¥Postgres

組み込みデータベース。

−%NnmDataDir%log¥nnm

NNMiのロギングディレクトリ。

−%NnmDataDir%shared¥nnm¥databases¥custompoller

カスタムポーラー収集のエクスポートディレクトリ

−%NnmDataDir%nmsas¥NNM¥log

NNMiの監査ログディレクトリ。

−%NnmDataDir%nmsas¥NNM¥conf

監査ログファイルを設定するためのNNMiのディレクトリ。

−%NnmDataDir%nmsas¥NNM¥data

ovjbossで使われるトランザクションストア。

Linux

−$NnmDataDir/shared/nnm/databases/Postgres

組み込みデータベース。

−$NnmDataDir/log/nnm

NNMiのロギングディレクトリ。

−$NnmDataDir/shared/nnm/databases/custompoller

カスタムポーラー収集のエクスポートディレクトリ

−$NnmDataDir/nmsas/NNM/log

NNMiの監査ログディレクトリ。

−$NnmDataDir/nmsas/NNM/conf

監査ログファイルを設定するためのNNMiのディレクトリ。

−$NnmDataDir/nmsas/NNM/data

ovjbossで使われるトランザクションストア。

これらのファイルは，nnmhadisk.ovplコマンドによって，ローカルディスクと共有ディスクの間でコピーされます。この項の手順に従って，このコマンドを実行します。コマンド構文の概要については，nnm-haのmanページを参照してください。

ただし，以下の設定ファイルについては，HA構成のNNMiは共有ディスクにコピーされたファイルを直接参照します。

そのため，HA構成のNNMiで，これらの設定値を変更する際は，事前にメンテナンスモードに設定後，ローカルディスクにあるファイルではなく，共有ディスクにあるファイルを直接編集してください。

Windowsの場合

−%NnmDataDir%nmsas¥NNM¥server.properties

HA構成の場合，%HA_MOUNT_POINT%¥NNM¥dataDir¥nmsas¥NNM¥server.propertiesを使用します。

−%NnmDataDir%nmsas¥nms¥server.properties

HA構成の場合，%HA_MOUNT_POINT%¥NNM¥dataDir¥nmsas¥nms¥server.propertiesを使用します。

−%NnmDataDir%nmsas¥NNM¥conf¥nms-auth-config.xml

HA構成の場合，%HA_MOUNT_POINT%¥NNM¥dataDir¥nmsas¥NNM¥conf¥nms-auth-config.xmlを使用します。

Linuxの場合

−/var/opt/OV/nmsas/NNM/server.properties

HA構成の場合，$HA_MOUNT_POINT/NNM/dataDir/nmsas/NNM/server.propertiesを使用します。

−/var/opt/OV/nmsas/nms/server.properties

HA構成の場合，$HA_MOUNT_POINT/NNM/dataDir/nmsas/nms/server.propertiesを使用します。

−/var/opt/OV/nmsas/NNM/conf/nms-auth-config.xml

HA構成の場合，$HA_MOUNT_POINT/NNM/dataDir/nmsas/NNM/conf/nms-auth-config.xmlを使用します。

19.5.2　設定ファイルの複製

HA環境で実行するNNMiは，ファイルレプリケーションを使って，HAクラスタ内のすべてのNNMiノードのNNMi設定ファイルのコピーを管理します。デフォルトでは，NNMiコマンドのnnmdatareplicator.ovplが，ファイルレプリケーションを管理します。このコマンドは，ローカルディスクにある設定ファイルの更新を監視し，設定ファイルが更新された場合は共有ディスクにファイルをコピーします。フェイルオーバーが発生した場合，共有ディスクにコピーしておいた最新の設定ファイルをフェイルオーバー先のノードにコピーします。その後，NNMiの起動処理が行われます。

上記の設定ファイルの更新確認とコピー処理は，HAクラスタから定期的に実行されるNNMiの監視処理の中で行われます。このため，設定ファイル変更後のコピー処理前にノード切り替えが発生すると，変更された設定が反映されません。このような場合は，再度設定を変更してください。

nnmdatareplicator.confファイルには，データレプリケーションに含めるNNMiのフォルダとファイルを指定します。

データレプリケーションプロセスの詳細については，nnm-haのmanページを参照してください。

19.6　HA設定のメンテナンス

19.6.1　NNMiをメンテナンスモードにする

メンテナンスモードは，NNMiのメンテナンス作業を行うために一時的にフェイルオーバーを抑止する機能です。

HA環境で実行するNNMiは，HA製品によってNNMiの稼働状態が監視されていて，NNMiが停止した場合，異常発生と判定されて別ノードにフェイルオーバーをします。このため，メンテナンス作業を行うために意図的にNNMiを停止してもフェイルオーバーが発生してしまいます。

メンテナンスモードでは，NNMiの監視を抑止することによってフェイルオーバーの発生を抑止します。これによってアクティブなクラスタノード上でovstartコマンドやovstopコマンドを実行してメンテナンス作業を行うことができます。なお，パッシブなクラスタノードではovstartコマンドやovstopコマンドは絶対に実行しないでください。

重要

NNMiを前提としている関連製品を実行している場合，NNMiだけをメンテナンスモードにしても関連製品に異常が起きるとフェイルオーバーが発生します。この場合は，関連製品を停止またはメンテナンスモード相当の状態にしてから，NNMiをメンテナンスモードにしてください。

(1)　NNMiをメンテナンスモードにする

NNMiをメンテナンスモードにすると，NNMiの監視が無効になります。NNMiがメンテナンスモードになっていると，そのHAリソースグループのNNMiの停止や起動を行ってもフェイルオーバーは行われません。

NNMiをメンテナンスモードにするには，アクティブなクラスタノードで次のファイルを作成します。ファイルは空でかまいません。

Windows：%NnmDataDir%hacluster¥<resource_group>¥maintenance

Linux：$NnmDataDir/hacluster/<resource_group>/maintenance

(2)　NNMiのメンテナンスモードを解除する

NNMiのメンテナンスモードを解除すると，NNMiの監視が再び有効になります。NNMiを停止すると，HAリソースグループはパッシブなクラスタノードへフェイルオーバーします。

HAリソースグループのメンテナンスモードの解除は，次の手順を実行します。

NNMiが正しく実行していることを確認する。

ovstatus -c

すべてのNNMiサービスで，［実行中］状態が表示される必要があります。

メンテナンスが開始される前にアクティブだったクラスタノードから，メンテナンスファイルを削除する。

メンテナンスファイルについては，「(1)　NNMiをメンテナンスモードにする」を参照してください。

19.6.2　HAクラスタ内のNNMiをメンテナンスする

メモ

HAモニタおよびCLUSTERPROの場合は，手順が一部異なります。手順については，リリースノートを参照してください。

(1)　NNMiの起動と停止

NNMiをHA下で実行している場合は，HAのメンテナンスが目的の指示がないかぎり，ovstartコマンドやovstopコマンドは，使わないでください。通常のオペレーションでは，HA製品の適切なコマンドまたはNNMiのHAコマンド（nnmhastartrg.ovplやnnmhastoprg.ovpl）を使って，HAリソースグループの起動や停止を行います。

(2)　クラスタ環境でNNMiのホスト名やIPアドレスを変更する

(a)　仮想ホスト名の変更

HA設定の完了後にNNMiの仮想ホスト名を変更することはできません。仮想ホスト名を変更するには，NNMiのHA設定を解除し，新しい仮想ホスト名でHA設定をし直してください。

(b)　仮想IPアドレスの変更

NNMi HAリソースグループの仮想IPアドレスを変更するには，アクティブなクラスタノードで次の手順を実行します。

NNMi HAリソースグループを停止する。

Windows：%NnmInstallDir%misc¥nnm¥ha¥nnmhastoprg.ovpl NNM <resource_group>

net stop NnmTrapReceiver

Linux：/opt/OV/misc/nnm/ha/nnmhastoprg.ovpl NNM <resource_group>

/opt/OV/bin/nettrap stop

新しいIPアドレスを使うように，クラスタ設定を変更する。

Windows：クラスタの管理コンソールでIPアドレスリソースの設定を変更します。リソースグループを開き，<resource_group>-ipをダブルクリックしてパラメータータブを選択し，新しいIPアドレスを入力します。

Linux：/opt/OV/misc/nnm/ha/nnmhargconfigure.ovpl NNM <resource_group> -set_value <resource_group>-ip Address <new_IP_address>

haconf -dump -makeroを実行してHAクラスタに設定変更を反映させます。

NNMi HAリソースグループを起動する。

Windows：%NnmInstallDir%misc¥nnm¥ha¥nnmhastartrg.ovpl NNM <resource_group>

Linux：/opt/OV/misc/nnm/ha/nnmhastartrg.ovpl NNM <resource_group>

NNMiを正常に起動できたことを確認する。

Windows：%NnmInstallDir%bin¥ovstatus -c

Linux：/opt/OV/bin/ovstatus -c

(c)　物理ホスト名の変更

クラスタ環境で物理ホスト名を変更する場合，NNMiを停止してからシステムの物理ホスト名を変更してください。NNMiとして必要な設定はありません。物理ホスト名を変更後，NNMiを起動してください。

なお，Windowsのクラスタ環境では，物理ホスト名（コンピューター名）を変更することはできません。

(d)　物理IPアドレスの変更

手順については，「22.4　スタンドアロンのNNMi管理サーバーのIPアドレスを変更する」を参照してください。

(3)　フェイルオーバーを行わせないようにNNMiを停止する

NNMiのメンテナンスを行う必要がある場合は，アクティブなクラスタノードのNNMiを，パッシブなクラスタノードへフェイルオーバーさせないように停止できます。アクティブなクラスタノードで次の手順を実行します。

NNMiを前提としている関連製品がある場合，まず関連製品を停止またはメンテナンスモード相当の状態にする。

「(1)　NNMiをメンテナンスモードにする」に従って，HAリソースグループをメンテナンスモードにする。

NNMiを停止する。

ovstop -c

(4)　メンテナンス後にNNMiを再起動する

フェイルオーバーしないようにNNMiを停止した場合は，次の手順を実行して，NNMiとHA監視を再起動します。

NNMiを起動する。

ovstart -c

NNMiを正常に起動できたことを確認する。

ovstatus -c

すべてのNNMiサービスで，［実行中］状態が表示される必要があります。

「(2)　NNMiのメンテナンスモードを解除する」に従って，HAリソースグループのメンテナンスモードを解除する。

NNMiの関連製品を停止またはメンテナンスモード相当の状態にしていた場合は，元の状態に戻す。

(5)　HA構成のNNMiのバックアップ

(a)　オンラインバックアップ

オンラインバックアップを行う場合は，アクティブなクラスタノードで共有ディスクにアクセスできることを確認してから，通常のバックアップ手順を実施してください。

(b)　オフラインバックアップ

HA構成のNNMiのオフラインバックアップデータを取得する場合は，次の手順を実施します。手順に記載しているメンテナンスモードについては「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

HAクラスタ内のアクティブなクラスタノードを特定する。

Windows：%NnmInstallDir%misc¥nnm¥ha¥nnmhaclusterinfo.ovpl -group <resource_group> -activeNode

Linux：/opt/OV/misc/nnm/ha/nnmhaclusterinfo.ovpl -group <resource_group> -activeNode

アクティブなクラスタノードをメンテナンスモードにする。

NNMiを停止する。

ovstop -c

HA製品の操作で共有ディスクがオンラインであることを確認する。オフラインであればオンラインに変更する。

共有ディスクにアクセスできることを確認したあと，nnmbackup.ovplコマンドを実行してオフラインバックアップを実施し，バックアップデータを取得する。

NNMiを起動させる。

ovstart -c

NNMiの起動が完了するのを待ちます。

NNMiサービス起動後，メンテナンスモードを解除する。

(6)　HA構成のNNMiのリストア

バックアップデータをリストアするときは次の手順を実施します。手順に記載しているメンテナンスモードについては「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

重要

シングル構成のNNMiで取得したバックアップデータをクラスタ構成のNNMiにリストアしないでください。

クラスタとして正常に動作し，NNMiがHA構成に設定されている状態にする。

例えば，ハードウェア障害などでシステムの一部または全体が失われた場合，NNMiがHA構成として動作できる状態にシステムを復旧してください。

リストアを実施するノードをアクティブなクラスタノードにする。

アクティブなクラスタノードをメンテナンスモードにする。

リストアを実施する。

nnmbackup.ovplコマンドで取得したバックアップデータの場合

nnmrestore.ovplコマンドを使用してリストアを実施してください。

nnmbackupembdb.ovplコマンドで取得したバックアップデータの場合

nnmrestoreembdb.ovplコマンドを使用してリストアを実施してください。

重要

別ノードで取得したバックアップデータを使用して，nnmrestore.ovplコマンドでリストアを実行する場合は，別ノードのライセンスが適用されないよう，-licオプションを付与しないでください。

NNMiを起動する。

ovstart -c

メンテナンスモードを解除する。

もう一方のノードで手順2.〜手順6.を実施する。

この手順は各ノードのローカルディスク上の設定ファイルを同じ状態にするために行います。同じバックアップデータを使ってリストアを行ってください。

なお，nnmrestoreembdb.ovplコマンドでのリストアは共有ディスク上のデータベースへのリストアを行うため，任意の1つのノードだけで実施してください。

(7)　データベースの初期化

HAクラスタ内のアクティブなクラスタノードを特定する。

Windows：%NnmInstallDir%misc¥nnm¥ha¥nnmhaclusterinfo.ovpl -group <resource_group> -activeNode

Linux：/opt/OV/misc/nnm/ha/nnmhaclusterinfo.ovpl -group <resource_group> -activeNode

アクティブなクラスタノードをメンテナンスモードにする。

共有ディスクにアクセスできることを確認する。

nnmresetembdb.ovplコマンドを引数なしで実行して，データベースを初期化する。

Windows：%NnmInstallDir%bin¥nnmresetembdb.ovpl

Linux：/opt/OV/bin/nnmresetembdb.ovpl

ovstatus -cを実行し，NNMiサービスが起動していることを確認する。

メンテナンスモードを解除する。

19.7　HAクラスタ内のNNMiの設定を解除する

NNMiノードをHAクラスタから削除する手順には，NNMiのインスタンスのHA設定を解除する手順も含まれます。設定を解除すると，NNMiのインスタンスをスタンドアロン管理サーバーとして実行できます。また，そのノードからNNMiをアンインストールできます。

HAクラスタのNNMiの設定を完全に解除するには，次の順序で解除作業をしてください。

19.7.1　アクティブなクラスタノードの特定

19.7.2　パッシブなクラスタノードでの設定解除

19.7.3　アクティブなクラスタノードでの設定解除

なお，アクティブなクラスタノードの設定解除では，NNMiのデータを削除する場合と，HA解除以降もシングルサーバーとしてNNMiのデータを続けて使う場合の両方を説明します。

メモ

HAモニタおよびCLUSTERPROの場合は，nnmhaunconfigure.ovplを使わないで設定解除作業を行います。設定方法については，リリースノートを参照してください。

19.7.1　アクティブなクラスタノードの特定

HAクラスタ内のアクティブなクラスタノードを特定する。

Windows：%NnmInstallDir%misc¥nnm¥ha¥nnmhaclusterinfo.ovpl -group <resource_group> -activeNode

Linux：/opt/OV/misc/nnm/ha/nnmhaclusterinfo.ovpl -group <resource_group> -activeNode

19.7.2　パッシブなクラスタノードでの設定解除

パッシブなクラスタノードで，HAクラスタからNNMiの設定を解除する。

Windows：net stop NnmTrapReceiver

%NnmInstallDir%misc¥nnm¥ha¥nnmhaunconfigure.ovpl NNM <resource_group>

Linux：/opt/OV/bin/nettrap stop

/opt/OV/misc/nnm/ha/nnmhaunconfigure.ovpl NNM <resource_group>

このコマンドによってHAリソースグループのノード一覧から該当するノードを解除します。ほかのノードでHA構成のNNMiを実行するための設定や共有ディスクのデータへの変更は行いません。

なお，次のメッセージが出力される場合がありますが，問題ありません。

Windowsの場合

警告:クラスタレジストリにあるリソースグループxxxxxのパブリックエントリPUBLIC.HA_MOUNT_POINTに値がありません。

重要

VCSまたはSCSでNNMiがHA構成の時に物理ホスト名を変更した環境の場合，HA設定を解除する前にHA設定時の物理ホスト名に戻す必要があります。シングルサーバー構成に移行した後に継続して変更後のホスト名を使用する場合は，HA設定を解除した後に「22.5　NNMi管理サーバーのホスト名またはドメイン名を変更する」を参照して設定を行ってください。

VCSまたはSCSの場合，HAクラスタに設定変更を反映させる。

haconf -dump -makero

NNMiノードのFQDN設定を物理ホスト名に変更する。

a　nms-local.propertiesファイルを編集します。

ファイルのパス

・Windows：%NnmDataDir%conf¥nnm¥props¥nms-local.properties

・Linux：/var/opt/OV/conf/nnm/props/nms-local.properties

編集内容

com.hp.ov.nms.fqdn = 仮想ホスト名

ここでは物理ホスト名ではなく仮想ホスト名を設定してください。

b　nmsetofficialfqdn.ovplコマンドを実行します。

<FQDN>には物理ホスト名（hostnameコマンドで表示されるホスト名）のFQDNを指定してください。

Windows：%NnmInstallDir%bin¥nnmsetofficialfqdn.ovpl -force <FQDN>

Linux：/opt/OV/bin/nnmsetofficialfqdn.ovpl -force <FQDN>

このコマンドによってHA設定時に仮想ホスト名に変更したFQDN設定を，物理ホスト名のFQDNに変更します。

なお，コマンド実行時に次のメッセージが出力される場合があります。

「シングルサインオンが正しく機能するには，新しい証明書を手動で生成する必要があります。」が表示された場合

シングルサインオンはサポートしていないため，このメッセージは無視してください。

これによって自己署名証明書が使用されます。NNMiの通信で別の自己署名証明書，または認証機関（CA）署名の証明書を使用する場合は，追加の手順を実行する必要があります。証明書の詳細については，「10.　NNMiでの証明書の使用」を参照してください。

NNMi HAリソースグループ固有のファイルを安全に保持できるように別の場所に移動する。

NNMi HAリソースグループを再設定する予定がない場合，次のファイルのコピーを保存する必要はありません。この時点でファイルを削除してかまいません。

Windows

エクスプローラで，%NnmDataDir%hacluster¥<resource_group>¥フォルダを削除します。

Linux

cd /var/opt/OV/hacluster/

rm -r <resource_group>

次のファイルを削除します。

ファイルのパス

・Windows

エクスプローラで，%NnmDataDir%shared¥nnm¥databases¥nnmdatareplicator¥DataReplicator.dbを削除します。

・Linux

rm /var/opt/OV/shared/nnm/databases/nnmdatareplicator/DataReplicator.db

サービスの自動起動を有効にする。

Windows

スタートメニューの［管理ツール］＞［サービス］で［NNM Trap Receiver］および［NNM Trap Receiver Manager］を選択し，「スタートアップの種類」を「自動」に設定してください。

Linux

systemctl enable netmgt.service

systemctl enable nettrap.service

systemctl start netmgt.service

systemctl start nettrap.service

なお，systemctl startコマンドを実行するとNNMiサービスが起動します。

以上の手順で終了です。

HAクラスタからNNMiを完全に解除する場合は，パッシブなクラスタノードを解除後，アクティブなクラスタノードでの設定解除を実施してください。

19.7.3　アクティブなクラスタノードでの設定解除

アクティブなクラスタノードで，NNMi HAリソースグループ，NnmTrapReceiverを停止する。

Windows：%NnmInstallDir%misc¥nnm¥ha¥nnmhastoprg.ovpl NNM <resource_group>

net stop NnmTrapReceiver

Linux：$NnmInstallDir/misc/nnm/ha/nnmhastoprg.ovpl NNM <resource_group>

/opt/OV/bin/nettrap stop

メモ

VCSまたはSCSでNNMiがHA構成の時に物理ホスト名を変更した環境の場合，リソースグループを停止する前にHA設定時の物理ホスト名に戻す必要があります。シングルサーバー構成に移行した後に継続して変更後のホスト名を使用する場合は，HA設定を解除した後に「22.5　NNMi管理サーバーのホスト名またはドメイン名を変更する」を参照して設定を行ってください。

アクティブなクラスタノードで，HAクラスタからNNMiの設定を解除する。

Windows：%NnmInstallDir%misc¥nnm¥ha¥nnmhaunconfigure.ovpl NNM <resource_group>

Linux：$NnmInstallDir/misc/nnm/ha/nnmhaunconfigure.ovpl NNM <resource_group>

このコマンドによってHAリソースグループのフェイルオーバー対象一覧から該当するノードを解除します。

このコマンドによって，共有ディスクへのアクセス権は失われますが，ディスクグループやボリュームグループの設定が解除されるわけではありません。

なお，次のメッセージが出力される場合がありますが，問題ありません。

WSFCの場合

警告:クラスタレジストリにあるリソースグループ xxxxxのパブリックエントリPUBLIC.HA_MOUNT_POINT に値がありません。

VCSまたはSCSの場合

VCS WARNING V-16-1-10133 Group does not exist: <resource_group>

アクティブなクラスタノードで，NNMi HAリソースグループ固有のファイルを安全に保持できるように別の場所に移動する。

NNMi HAリソースグループを再設定する予定がない場合，次のファイルのコピーを保存する必要はありません。この時点でファイルを削除してかまいません。

Windows

エクスプローラで，%NnmDataDir%hacluster¥<resource_group>¥フォルダを削除します。

Linux

cd /var/opt/OV/hacluster

rm -r <resource_group>

次のファイルを削除します。

ファイルのパス

・Windows

エクスプローラで，%NnmDataDir%shared¥nnm¥databases¥nnmdatareplicator¥DataReplicator.dbを削除します。

・Linux

rm /var/opt/OV/shared/nnm/databases/nnmdatareplicator/DataReplicator.db

共有ディスクをマウントする。

OSやクラスタの操作によって，共有ディスクにアクセスできる状態にしてください。

（例）

［サーバーマネージャ］の［記憶域］サービスのディスクの管理画面で，共有ディスクがマウントされていたディスクを右クリックして，［オンライン］をクリックします。

元のアクティブなクラスタノードに共有ディスクのNNMiファイルをコピーする。

この手順は次の条件のどちらかに該当する場合に，実施してください。

HA構成時のデータベースをシングルサーバー構成に移してNNMiを運用する場合

HA構成時に，nnmchangeembdbpw.ovplによってDBのパスワードを変更した場合

次のコマンドを実行し，元アクティブなクラスタノードに共有ディスクのNNMiファイルをローカルディスク上にコピーします。

Windows：%NnmInstallDir%misc¥nnm¥ha¥nnmhadisk.ovpl NNM -from <HA_mount_point>

Linux：/opt/OV/misc/nnm/ha/nnmhadisk.ovpl NNM -from <HA_mount_point>

NNMiノードのFQDN設定を物理ホスト名に変更する。

a　nms-local.propertiesファイルを編集します。

ファイルのパス

・Windows：%NnmDataDir%conf¥nnm¥props¥nms-local.properties

・Linux：/var/opt/OV/conf/nnm/props/nms-local.properties

編集内容

com.hp.ov.nms.fqdn = 仮想ホスト名

ここでは物理ホスト名ではなく仮想ホスト名を設定してください。

b　nnmsetofficialfqdn.ovpl コマンドを実行します。

<FQDN>には物理ホスト名（hostnameコマンドで表示されるホスト名）のFQDNを指定してください。

Windows：%NnmInstallDir%bin¥nnmsetofficialfqdn.ovpl -force <FQDN>

Linux：/opt/OV/bin/nnmsetofficialfqdn.ovpl -force <FQDN>

このコマンドによってHA設定時に仮想ホスト名に変更したFQDN設定を，物理ホスト名のFQDNに変更します。

なお，コマンド実行時に次のメッセージが出力される場合があります。

「シングルサインオンが正しく機能するには，新しい証明書を手動で生成する必要があります。」が表示された場合

シングルサインオンはサポートしていないため，このメッセージは無視してください。

これによって自己署名証明書が使用されます。NNMiの通信で別の自己署名証明書，または認証機関（CA）署名の証明書を使用する場合は，追加の手順を実行する必要があります。

証明書の詳細については，「10.　NNMiでの証明書の使用」を参照してください。

共有ディスク上のNNMフォルダまたはNNMディレクトリを削除する。

共有ディスクのマウントを解除する。

（例）

［サーバーマネージャ］の［記憶域］サービスのディスクの管理画面で，共有ディスクがマウントされているディスクを右クリックして，［オフライン］をクリックします。

サービスの自動起動を有効にする。

Windows

スタートメニューの［管理ツール］＞［サービス］で［NNM Trap Receiver］および［NNM Trap Receiver Manager］を選択し，「スタートアップの種類」を「自動」に設定してください。

Linux

systemctl enable netmgt.service
systemctl enable nettrap.service
systemctl start netmgt.service
systemctl start nettrap.service

なお，systemctl startコマンドを実行するとNNMiサービスが起動します。

メモ

元のアクティブなクラスタノードでNNMiを実行する場合は，ここまでの手順で準備が完了しています。

ovstartを実行してNNMiを起動してください。

以降の手順は次の条件のどちらかに該当する場合に，実施してください。

HA構成時のデータベースをシングルサーバー構成に移して，元のパッシブなクラスタノードでNNMiを運用する場合

HA構成時に，nnmchangeembdbpw.ovplによってDBのパスワードを変更した場合

元のアクティブなクラスタノードで次のコマンドを使って，NNMi設定をバックアップする。

これによって手順7.で共有ディスクからローカルにコピーしたデータを含めたバックアップが取得されます。

Windows：%NnmInstallDir%bin¥nnmbackup.ovpl -type offline -scope all -target <directory>

Linux：/opt/OV/bin/nnmbackup.ovpl -type offline -scope all -target <directory>

HA構成時のデータを使ってNNMiを実行したい元のパッシブなクラスタノードで，手順11.で取得したアクティブなクラスタノードのバックアップデータをパッシブなクラスタノードにリストアする。

Windows：%NnmInstallDir%bin¥nnmrestore.ovpl -force -source <backup_data>

Linux：/opt/OV/bin/nnmrestore.ovpl -force -source <backup_data>

このコマンドの詳細については，「20.　NNMiのバックアップおよびリストアツール」を参照してください。

19.8　HA設定のトラブルシューティング

19.8.1　一般的な設定の誤り

HA設定での一般的な誤りの例を次に示します。

ディスク設定が正しくない。

VCSまたはSCSを使用している場合で，リソースをプローブできないときは，設定に何らかの間違いがあります。ディスクをプローブできないとき，オペレーティングシステムはディスクにアクセスできなくなることがあります。

手動でディスク設定をテストし，設定が適切であることをHA製品のマニュアルを参照して確認してください。

ディスクが使用中で，HAリソースグループで起動できない。

HAリソースグループを起動する前に，ディスクがアクティブでないことを必ず確認してください。

WSFCのネットワーク設定が正しくない。

ネットワークトラフィックが複数のNICカード上を流れる場合は，ovjbossプロセスなどのネットワーク帯域幅を大量に消費するプログラムをアクティブ化するとRDPセッションが失敗します。

一部のHA製品がブート時に自動的に再起動しない。

ブートアップ時の自動再起動の設定方法については，HA製品のマニュアルを参照してください。

NFS，またはほかのアクセスがOSに直接追加される。

リソースグループ設定でこの動作を管理している必要があります。

フェイルオーバーの間，またはHAリソースグループをオフラインにする間に，カレントディレクトリを共有ディスクのマウントポイントにしている。

HAは，共有ディスクのマウント解除を阻止するプロセスをすべて抹消します。フェイルオーバーまたはリソースグループのオフライン時には別のディレクトリに移動してください。

HAクラスタの仮想IPアドレスをHAリソースの仮想IPアドレスとして再使用している。

一方のシステムで有効で，他方では無効となります。それぞれに異なるIPアドレスを設定してください。

タイムアウトが短過ぎる。

製品に不具合があると，HA製品はHAリソースをタイムアウトさせ，フェイルオーバーが実行されます。

WSFCで，［リソースが開始するまでの待機時間］の設定値を確認します。NNMiでは，この値は15分に設定されますが，この値を増やすことができます。

メンテナンスモードを使用していない。

メンテナンスモードは，HAの障害をデバッグするためのモードです。リソースグループがシステムでオンラインになった直後にすぐフェイルオーバーしてしまうような場合に，メンテナンスモードは，システムでリソースグループを維持し，実際に障害のある部分を見つけるのに役立ちます。

クラスタログを再確認していない。

クラスタログで多くの一般的な間違いを確認できます。

19.8.2　HAリソーステスト

ここでは，NNMi HAリソースグループのリソースをテストするための一般的な方法を説明します。

このテストで，ハードウェア設定の問題が特定されます。HA用NNMiを設定する前に，このテストを実行することをお勧めします。好ましい結果を出した設定値を記録しておき，NNMi HAリソースグループの設定で，それらの値を使用します。

ここに記載されているコマンドの詳細については，HA製品のマニュアルを参照してください。

HAリソースのテスト手順を次に示します。

HAクラスタを起動する。

（Windowsの場合）HAクラスタに，次の仮想IPアドレスが定義されていることを確認する。

HAクラスタの仮想IPアドレス

HAリソースグループの仮想IPアドレス

これらのIPアドレスは，別の場所で使用しないでください。

HAリソースグループをHAクラスタに追加する。

このHAリソースグループには，testなど，商用名でない名称を使用してください。

HAリソースグループへの接続をテストする。

仮想IPアドレスと，リソースグループに対応する仮想ホスト名を，リソースとしてHAリソースグループに追加します。

あとで，NNMi HAリソースグループに関連づける値を使用します。

アクティブなクラスタノードからパッシブなクラスタノードにフェイルオーバーし，HAクラスタが正常にフェイルオーバーすることを確認します。

新しいアクティブなクラスタノードから新しいパッシブなクラスタノードにフェイルオーバーし，フェイルバックを確認します。

リソースグループが正しくフェイルオーバーしない場合，アクティブなノードにログオンして，IPアドレスが正しく設定され，アクセスできることを確認します。また，ファイアウォールによってIPアドレスがブロックされていないことも確認します。

アクティブなクラスタノードからパッシブなクラスタノードにフェイルオーバーし，HAクラスタが正常にフェイルオーバーすることを確認します。

新しいアクティブなクラスタノードから新しいパッシブなクラスタノードにフェイルオーバーし，フェイルバックを確認します。

リソースグループが正しくフェイルオーバーしない場合，アクティブなクラスタノードにログオンして，ディスクがマウントされ，使用できることを確認します。

共有ディスクの設定に使用したコマンドおよび入力値の記録を取っておく。

NNMi HAリソースグループを設定するときに，この情報が必要になる場合があります。

各ノードからリソースグループを削除する。

IPアドレスエントリを削除します。

リソースグループをオフラインに設定して，ノードからリソースグループを削除します。

この時点で，NNMiに付属しているツールを使用して，HA下で実行するようにNNMiを設定できます。

19.8.3　一般的なHAのトラブルシューティング

(1)　リソースをホストするサブシステムプロセスが予期せず停止する

Windows Server 2016オペレーティングシステムで，HAクラスタリソースを起動すると，リソースをホストするサブシステム（rhs.exe）プロセスが予期せずに停止します。

この問題の詳細については，次のWebサイトを参照してください。

http://support.microsoft.com/kb/978527

重要

NNMiリソースを実行するときは，必ず，リソースグループに固有の別個のリソースモニタ（rhs.exe）で実行してください。

(2)　製品の監視タイムアウト

システムログに，次の例のようなメッセージが含まれます。

VCS ERROR V-16-2-13027 Thread(...) Resource(<resource group>-app) - monitor procedure did not complete within the expected time.

このメッセージは，製品がVeritas Cluster ServerまたはSymantec Cluster Serverに設定されたタイムアウト値の範囲内でリソースを監視できなかったことを示しています。

Veritas Cluster ServerまたはSymantec Cluster Serverのデフォルトで，タイムアウトは60秒が適用されます。

Veritas Cluster ServerまたはSymantec Cluster Serverに設定されたタイムアウト値を変更するには，次のコマンドを，次の順番で，実行します。

/opt/VRTSvcs/bin/haconf -makerw
/opt/VRTSvcs/bin/hares -override <resource_group>-app MonitorTimeout
/opt/VRTSvcs/bin/hares -modify <resource_group>-app MonitorTimeout <value in seconds>
/opt/VRTSvcs/bin/haconf -dump -makero

(3)　アクティブなクラスタノードのログファイルが更新されない

これは正常です。ログファイルは，共有ディスクにリダイレクトされているため，このような状況になります。

NNMiの場合は，ov.confファイル内のHA_NNM_LOG_DIRで指定された場所にあるログファイルを調べてください。

(4)　HAリソースグループが特定のクラスタノードでは起動できない

nnmhargconfigure.ovplコマンド，またはnnmhastartrg.ovplコマンドでNNMi HAリソースグループを正常に起動／停止／切り替えできない場合は，次の情報を調べてください。

WSFCの場合

−フェイルオーバークラスタ管理で，リソースグループおよびそれを構成するリソースの状態を調べてください。

−イベントビューアのログにエラーが記録されていないか調べてください。

VCSまたはSCSの場合

−/opt/VRTSvcs/bin/hares -stateを実行して，リソースの状態を調べます。

−障害が発生しているリソースでは，障害が発生しているリソース用の/var/VRTSvcs/log/<resource>.logファイルを調べます。リソースは，IP*.log，Mount*.log，Volume*.logなどのエージェントタイプで指定します。

原因となっているリソースを特定できない場合は，HA製品のコマンドを使って，HAリソースグループを手動で起動します。

共有ディスクをマウントする。

ネットワークインタフェースに仮想ホストを割り当てる。

WSFCの場合

−フェイルオーバークラスタ管理を起動します。

−リソースグループを展開します。

−［<resource_group>-ip］を右クリックして，［このリソースをオンラインにする］をクリックします。

VCSまたはSCSの場合

/opt/VRTSvcs/bin/hares -online <resource_group>-ip -sys <local_hostname>

HAリソースグループを起動する。

例：

Windows：%NnmInstallDir%misc¥nnm¥ha¥nnmhastartrg.ovpl NNM -start <resource_group>

Linux：$NnmInstallDir/misc/nnm/ha/nnmhastartrg.ovpl NNM -start <resource_group>

リターンコード0は，NNMiを正常に起動できたことを意味します。

リターンコード1は，NNMiを正常に起動できなかったことを意味します。

(5)　「システム エラー XXXXが発生しました」が表示された（Windowsの場合）

システム（OSやクラスタソフト）のエラーが発生している場合があります。詳しくはOSやクラスタソフトのマニュアルなどを確認してください。

エラーの例：WSFCでのエラー発生例について説明します。

例「システム エラー 5054 が発生しました (0x000013be)。クラスタ ネットワークが無効です。」

NNMi用のIPアドレスに，ハートビート用の内部用ネットワークのIPアドレスを指定した場合，IPアドレスリソースの作成のため実行したcluster.exeコマンドで上記のエラーが発生します。

例「システム エラー 5057 が発生しました (0x000013c1)。そのクラスタ IP アドレスは既に使われています。」

NNMi用のIPアドレスに，既に使われているIPアドレスを指定した場合， IPアドレスリソースの作成のため実行したcluster.exeコマンドで上記のエラーが発生します。

対処：システムエラーの内容について確認し，問題を対策してください。上記の例のようにNNMi用のIPアドレスの指定が適切でない場合は，使用するIPアドレスの見直しを行ってください。

19.8.4　NNMi固有のHAのトラブルシューティング

この項の内容が適用されるのは，NNMiだけのHA設定です。

(1)　NNMiをHA下で正常に起動できない

NNMiが正しく起動しない場合，仮想IPアドレスまたはディスクに関するハードウェアの問題であるのか，アプリケーション障害の問題であるのかをデバッグする必要があります。このデバッグプロセスの間，システムをメンテナンスモードにします。

この問題を解決するには，次の手順を実行します。

HAクラスタのアクティブなクラスタノードで，次のメンテナンスファイルを作成して，HAリソースグループの監視を無効にする。

Windows：%NnmDataDir%hacluster¥<resource_group>¥maintenance

Linux：$NnmDataDir/hacluster/<resource_group>/maintenance

NNMiを起動する。

ovstart

NNMiを正常に起動できたことを確認する。

ovstatus -c

すべてのNNMiサービスで，［実行中］状態が表示される必要があります。このように表示されない場合，正しく開始していないプロセスをトラブルシューティングします。

トラブルシューティングが完了したら，メンテナンスファイルを削除する。

Windows：%NnmDataDir%hacluster¥<resource_group>¥maintenance

Linux：$NnmDataDir/hacluster/<resource_group>/maintenance

(2)　NNMiデータへの変更がフェイルオーバーのあとに表示されない

NNMiの設定で，NNMiを実行中のシステム以外のシステムが設定されています。この問題を解決するには，ov.confファイルに次の項目に対応した適切なエントリがあることを確認します。

NNM_INTERFACE=<virtual_hostname>

HA_RESOURCE_GROUP=<resource_group>

HA_MOUNT_POINT=<HA_mount_point>

NNM_HA_CONFIGURED=YES

HA_POSTGRES_DIR=<HA_mount_point>/NNM/dataDir/shared/nnm/databases/Postgres

HA_CUSTOMPOLLER_DIR=<HA_mount_point>/NNM/dataDir/shared/nnm/databases/custompoller

HA_NNM_LOG_DIR=<HA_mount_point>/NNM/dataDir/log/nnm

HA_JBOSS_DATA_DIR=<HA_mount_point>/NNM/dataDir/nmsas/NNM/data

HA_LOCALE=<ロケール>（Linuxだけ）

HA_PERFSPI_ADAPTER_DIR=<HA_mount_point>/NNM/dataDir/shared/perfSpi/datafiles

ov.confファイルの場所は，「19.9.1　NNMi HA設定ファイル」を参照してください。

(3)　HAの設定後，nmsdbmgrを起動できない

この状況は，通常，nnmhaconfigure.ovplコマンドを実行したが，-toオプションを指定してnnmhadisk.ovplコマンドを実行しないで，NNMiを起動した場合に発生します。この状況では，ov.confファイルのHA_POSTGRES_DIRエントリは，共有ディスクの場所を指していますが，この場所はNNMiからはアクセスできません。

この問題を解決するには，次の手順を実行します。

HAクラスタのアクティブなクラスタノードで，次のメンテナンスファイルを作成して，HAリソースグループの監視を無効にする。

Windows：%NnmDataDir%hacluster¥<resource_group>¥maintenance

Linux：$NnmDataDir/hacluster/<resource_group>/maintenance

NNMiデータベースを共有ディスクにコピーする。

Windows：

%NnmInstallDir%misc¥nnm¥ha¥nnmhadisk.ovpl NNM -to <HA_mount_point>

Linux：

$NnmInstallDir/misc/nnm/ha/nnmhadisk.ovpl NNM -to <HA_mount_point>

NNMi HAリソースグループを起動する。

Windows：

%NnmInstallDir%misc¥nnm¥ha¥nnmhastartrg.ovpl NNM <resource_group>

Linux：

$NnmInstallDir/misc/nnm/ha/nnmhastartrg.ovpl NNM <resource_group>

NNMiを起動する。

ovstart

NNMiを正常に起動できたことを確認する。

ovstatus -c

すべてのNNMiサービスで，［実行中］状態が表示される必要があります。

トラブルシューティングが完了したら，メンテナンスファイルを削除する。

Windows：%NnmDataDir%hacluster¥<resource_group>¥maintenance

Linux：$NnmDataDir/hacluster/<resource_group>/maintenance

(4)　NNMiが1つのHAクラスタノードでだけ正常に実行される（Windowsの場合）

Windowsオペレーティングシステムには，HAクラスタ用とHAリソースグループ用の2つの異なる仮想IPアドレスが必要です。HAクラスタの仮想IPアドレスとNNMi HAリソースグループの仮想IPアドレスが同じ場合，NNMiは，HAクラスタのIPアドレスと関連づけられているノードでだけ正常に実行されます。

この問題を修正するには，HAクラスタの仮想IPアドレスをネットワークで一意の値に変更します。

(5)　ディスクフェイルオーバーが行われない

この状況は，オペレーティングシステムが共有ディスクをサポートしていない場合に発生します。HA製品，オペレーティングシステム，ディスクのメーカーのマニュアルなどを参照して，これらの製品を混在させて使用できるか確認してください。

ディスク障害が発生すると，NNMiはフェイルオーバーでは起動しません。nmsdbmgrが失敗する理由の多くは，HA_POSTGRES_DIRディレクトリが存在しないことです。共有ディスクがマウント済みであり，該当するファイルにアクセスできる状態になっていることを確認してください。

(6)　共有ディスクにアクセスできない（Windowsの場合）

nnmhaclusterinfo.ovpl -config NNM -get HA_MOUNT_POINTコマンドを実行しても何も表示されない場合，共有ディスクのマウントポイントの設定が不適切のため，共有ディスクにアクセスできません。

共有ディスクのマウントポイントのドライブは，HA設定時に次のように完全に指定します。

（例）Y:

この問題を修正するには，HAクラスタの各ノードでnnmhaconfigure.ovplコマンドを実行します。

(7)　フェイルオーバー後にセカンダリクラスタノードで共有ディスク上のファイルが見つからない

この状況は，通常，共有ディスクがマウントされていないときに，-toオプションを付けたnnmhadisk.ovplコマンドを実行した場合に発生します。この場合は，データファイルはローカルディスクにコピーされ，共有ディスクには格納されません。

この問題を解決するには，次の手順を実行します。

HAクラスタのアクティブなクラスタノードで，次のメンテナンスファイルを作成して，HAリソースグループの監視を無効にする。

Windows：%NnmDataDir%hacluster¥<resource_group>¥maintenance

Linux：$NnmDataDir/hacluster/<resource_group>/maintenance

アクティブなクラスタノードにログオンして，ディスクがマウントされ，使用できることを確認する。

NNMiを停止する。

ovstop

Windows：net stop NnmTrapReceiver

Linux：/opt/OV/bin/nettrap stop

NNMiデータベースを共有ディスクにコピーする。

Windows：

%NnmInstallDir%misc¥nnm¥ha¥nnmhadisk.ovpl NNM -to <HA_mount_point>

Linux：

$NnmInstallDir/misc/nnm/ha/nnmhadisk.ovpl NNM -to <HA_mount_point>

NNMi HAリソースグループを起動する。

Windows：

%NnmInstallDir%misc¥nnm¥ha¥nnmhastartrg.ovpl NNM <resource_group>

Linux：

$NnmInstallDir/misc/nnm/ha/nnmhastartrg.ovpl NNM <resource_group>

NNMiを起動する。

ovstart

NNMiを正常に起動できたことを確認する。

ovstatus -c

すべてのNNMiサービスで，［実行中］状態が表示される必要があります。

トラブルシューティングが完了したら，メンテナンスファイルを削除する。

Windows：%NnmDataDir%hacluster¥<resource_group>¥maintenance

Linux：$NnmDataDir/hacluster/<resource_group>/maintenance

19.9　HA設定リファレンス

ここでは，NNMi HA設定ファイルとNNMi HA設定のスクリプトおよびログファイルについて説明します。

19.9.1　NNMi HA設定ファイル

次の表に，NNMi HA設定ファイルを示します。これらのファイルは，NNMiに適用され，次の場所にインストールされます。

Windows：%NnmDataDir%shared¥nnm¥conf

Linux：$NnmDataDir/shared/nnm/conf

表19‒11　NNMi HA設定ファイル

ファイル名

説明

ov.conf

このファイルは，NNMi HA実装の状態を示し，nnmhaclusterinfo.ovplコマンドによって更新されます。NNMiの各プロセスは，このファイルを読み取って，HA設定を確認します。

nnmdatareplicator.conf

このファイルは，nnmdatareplicator.ovplコマンドで，アクティブなクラスタノードからパッシブなクラスタノードへのデータレプリケーションに含むNNMiのフォルダとファイルを調べるために使われます。NNMi設定のレプリケーション用に異なる手段を実装する場合は，含めるデータのリストは，このファイルを参照してください。

詳細については，このファイルのコメントを参照してください。

19.9.2　NNMiに付属しているHA設定スクリプト

次の表に，NNMiに付属しているHA設定スクリプトを示します。NNMiに付属しているスクリプトは，カスタマPerlモジュールを持つすべての製品にHAを設定する場合に使用できる便利なスクリプトです。必要に応じて，HA製品に付属しているコマンドを使って，NNMi用にHAを設定できます。

NNMi管理サーバーでは，NNMiに付属しているHA設定スクリプトは，次の場所にインストールされます。

Windows：%NnmInstallDir%misc¥nnm¥ha

Linux：$NnmInstallDir/misc/nnm/ha

表19‒12　NNMi HA設定スクリプト

スクリプト名

説明

nnmhaconfigure.ovpl

NNMiをHAクラスタ用に設定します。

このスクリプトは，HAクラスタ内のすべてのノードで実行してください。

nnmhaunconfigure.ovpl

HAクラスタのNNMiの設定を解除します。

必要に応じて，HAクラスタ内の1つ以上のノードでこのスクリプトを実行します。

nnmhaclusterinfo.ovpl

NNMiに関するクラスタ情報を取得します。

このスクリプトは，必要に応じて，HAクラスタ内の任意のノードで実行します。

nnmhadisk.ovpl

データファイルを，NNMiと共有ディスクの間でコピーします。

HAの設定時には，このスクリプトはプライマリクラスタノードで実行します。

それ以外の場合は，この章の手順に従って，このスクリプトを実行します。

nnmhastartrg.ovpl

HAクラスタでNNMi HAリソースグループを起動します。

HAの設定時には，このスクリプトはプライマリクラスタノードで実行します。

nnmhastoprg.ovpl

HAクラスタでNNMi HAリソースグループを停止します。

HAの設定解除時には，このスクリプトはアクティブなクラスタノードで実行します。

表19-13に示したNNMi付属のスクリプトは，表19-12に示したスクリプトで使用します。表19-13に示したスクリプトは直接実行しないでください。

表19‒13　NNMi HAサポートスクリプト

スクリプト名

説明

nnmdatareplicator.ovpl

nnmdatareplicator.conf設定ファイルを調べて，リモートシステムに送信するファイルの変更やコピーを確認します。

nnmharg.ovpl

HAクラスタのNNMiを起動／停止／監視します。

VCSまたはSCS設定では，VCSまたはSCSの起動／停止／監視のスクリプトで使用します（nnmhargconfigure.ovplで，この使用法を設定します）。

また，トレースを有効／無効にするために，nnmhastartrg.ovplでも使われます。

nnmhargconfigure.ovpl

HAのリソースとリソースグループを設定します。nnmhaconfigure.ovplとnnmhaunconfigure.ovplで使われます。

nnmhastart.ovpl

HAクラスタでNNMiを起動します。nnmharg.ovplで使われます。

nnmhastop.ovpl

HAクラスタのNNMiを停止します。nnmharg.ovplで使われます。

nnmhamonitor.ovpl

HAクラスタのNNMiプロセスを監視します。nnmharg.ovplで使われます。

nnmhamscs.vbs

WSFCのHAクラスタで，NNMiプロセスを起動／停止／監視するスクリプトを作成するためのテンプレートです。生成されるスクリプトは，次の場所に格納され，WSFCで使われます。

%NnmDataDir%hacluster¥<resource_group>¥hamscs.vbs

19.9.3　NNMi HA設定のログファイル

次のログファイルは，NNMiのHA設定に適用されます。

Windows設定

−%NnmDataDir%tmp¥HA_nnmhaserver.log

−%NnmDataDir%log¥haconfigure.log

Linux設定

−$NnmDataDir/tmp/HA_nnmhaserver.log

−$NnmDataDir/log/haconfigure.log

Windows実行時

−イベントビューアのログ

−%HA_MOUNT_POINT%¥NNM¥dataDir¥log¥nnm¥ovspmd.log

−%HA_MOUNT_POINT%¥NNM¥dataDir¥log¥nnm¥postgres.log

−%HA_MOUNT_POINT%¥NNM¥dataDir¥log¥nnm¥nmsdbmgr.log

−%SystemRoot%¥Cluster¥cluster.log

これは，リソースとリソースグループの追加／削除，ほかの設定上の問題点，起動／停止上の問題点を含むクラスタ実行時の問題点に関するログファイルです。

VCSまたはSCS用のLinux

リソース

ログファイル

<resource_group>-app

/var/VRTSvcs/log/Application_A.log

$HA_MOUNT_POINT/NNM/dataDir/log/nnm/ovspmd.log

$HA_MOUNT_POINT/NNM/dataDir/log/nnm/public/postgres.log

$HA_MOUNT_POINT/NNM/dataDir/log/nnm/public/nmsdbmgr.log

Linuxの場合：/var/log/messages*

Solarisの場合：/var/adm/messages*

<resource_group>-dg

<resource_group>-volume

<resource_group>-mount

/var/VRTSvcs/log/DiskGroup_A.log

/var/VRTSvcs/log/Volume_A.log

/var/VRTSvcs/log/Mount_A.log

Linuxの場合：/var/log/messages*

Solarisの場合：/var/adm/messages*

<resource_group>-ip

/var/VRTSvcs/log/IP_A.log

Linuxの場合：/var/log/messages*

Solarisの場合：/var/adm/messages*

注：オペレーティングシステム固有のHAリソース関連の問題は，/var/adm/messages*または/var/log/messages*ファイルを調べてください。<resource_group>-appでは，プロセスを起動できなかったことに関するメッセージを探してください。

第6編　NNMiのメンテナンス編

20　NNMiのバックアップおよびリストアツール

どのようなビジネスでも，中断することなく業務を確実に継続するには，バックアップおよびリストアに関して優れた方針を持つことが重要です。NNMiは，ネットワークを運用する上で重要な資産であり，定期的にバックアップする必要があります。NNMiインストールに関連した重要データは，ファイルシステム内のファイル，およびリレーショナルデータベースのデータの2種類です。この章では，重要なNNMiファイルおよびデータをバックアップおよびリストアするためにNNMiで装備しているツールについて説明しています。

20.1　バックアップコマンドとリストアコマンド

NNMiには，NNMiデータをバックアップおよびリストアするために次のスクリプトがあります。

nnmbackup.ovpl

必要なすべてのファイルシステムデータ（設定情報を含む）とNNMiデータベースに保管されたデータをバックアップします。

nnmrestore.ovpl

nnmbackup.ovplスクリプトを使用して作成されたバックアップをリストアします。

nnmbackupembdb.ovpl

NNMiデータベース（ファイルシステムデータではない）の完全バックアップを，NNMiの稼働中に作成します。

nnmrestoreembdb.ovpl

nnmbackupembdb.ovplスクリプトを使用して作成されたバックアップをリストアします。

nnmresetembdb.ovpl

NNMiデータベーステーブルをドロップします。ovstartコマンドを実行してテーブルを再作成します。

コマンド構文については，該当するリファレンスページを参照してください。

20.2　NNMiデータをバックアップする

NNMiバックアップコマンド（nnmbackup.ovpl）は，主要なNNMiファイルシステムデータおよびNNMi Postgresデータベースのテーブルの一部またはすべてを，指定されたターゲットディレクトリにコピーします。各バックアップ操作によって，ターゲットディレクトリ内のnnm-bak-<TIMESTAMP>という名前の親ディレクトリにファイルが格納されます。-noTimeStampオプションを指定すると，ディスクスペースを節約できます。-noTimeStampオプションを使用した場合，親ディレクトリの名前はnnm-bakになります。前回のバックアップ後に-noTimeStampオプションを使用してバックアップが行われると，前回のバックアップの名前がnnm-bak.previousに変更されて，ローリングバックアップが作成されます。この名前変更は，2回目のバックアップの完了後，バックアップデータの喪失を防止するために行われます。

NNMiバックアップコマンドは，バックアップデータのtar形式のアーカイブを作成できます。また，ユーザー独自のツールを使用してバックアップファイルの圧縮もできます。次に，適切なツールを使用して，バックアップのコピーを保存できます。詳細については，nnmbackup.ovplのリファレンスページを参照してください。

20.2.1　バックアップタイプ

NNMiのバックアップコマンドでは，2種類のバックアップがサポートされます。

オンラインバックアップはNNMiの稼働中に行われます。NNMiでは，バックアップされたデータ内でデータベーステーブルが確実に同期されます。オンラインバックアップ中でも，オペレータは制約を受けることなくNNMiコンソールを使用でき，ほかのプロセスはNNMiデータベースとやり取りできます。オンラインバックアップを実行することで，バックアップ領域に記載されているように，機能に応じてNNMiのデータすべてまたはデータの一部だけをバックアップできます。NNMiデータベースの場合は，nmsdbmgrサービスが実行されている必要があります。

オフラインバックアップは，NNMiが完全に停止している間に行われます。オフラインバックアップでは，バックアップ領域がファイルシステムのファイルにだけ適用されます。オフラインバックアップには，バックアップ領域に関係なく，必ずNNMiデータベースの全体が含まれます。NNMiデータベースの場合，このバックアップではPostgresデータベースのファイルがコピーされます。

20.2.2　バックアップ領域

NNMiバックアップコマンドでは，NNMiのバックアップ量を定義する領域を幾つか指定できます。

設定領域

設定領域（-scope config）は，大まかにはNNMiコンソールの［設定］ワークスペース内の情報と一致します。

設定領域には次のデータが含まれます。

オンラインバックアップの場合は，NNMi設定情報を保存しているデータベーステーブルだけ。

オフラインバックアップの場合は，データベース全体。

オンラインバックアップ，オフラインバックアップともに，「表20‒1　設定領域ファイルとディレクトリ」のリストに示すファイルシステム内のNNMi設定情報。

トポロジ領域

トポロジ領域（-scope topology）は，大まかにはNNMiコンソールの［インベントリ］ワークスペース内の情報と一致します。ネットワークトポロジが依存している設定はそのトポロジの検出に使用されているため，トポロジ領域には設定領域が含まれます。

トポロジ領域には次のデータが含まれます。

オンラインバックアップの場合は，NNMi設定情報とネットワークトポロジ情報を保存しているデータベーステーブルだけ。

オフラインバックアップの場合は，データベース全体。

オンラインバックアップ，オフラインバックアップともに，「表20‒1　設定領域ファイルとディレクトリ」のリストに示すファイルシステム内のNNMi設定情報。現在，トポロジ領域に関連づけられているファイルシステムのファイルはありません。

イベント領域

イベント領域（-scope events）は，大まかにはNNMiコンソールの［インシデントの参照］ワークスペース内の情報と一致します。イベントはこれらのイベントに関連したネットワークトポロジに依存しているため，イベント領域には設定領域とトポロジ領域が含まれます。

イベント領域には次のデータが含まれます。

オンラインバックアップの場合は，NNMi設定情報，ネットワークトポロジ情報およびイベント情報を保存しているデータベーステーブルだけ。

オフラインバックアップの場合は，データベース全体。

オンラインバックアップ，オフラインバックアップともに，「表20‒1　設定領域ファイルとディレクトリ」のリストに示すファイルシステム内のNNMi設定情報と，「表20‒2　イベント領域ファイルとディレクトリ」のリストに示すNNMiイベント情報。

全領域

完全バックアップ（-scope all）には，NNMiのすべての重要ファイルとデータベース全体が含まれます。

表20‒1　設定領域ファイルとディレクトリ

ディレクトリまたはファイル名

説明

%NnmInstallDir%conf（Windowsだけ）

設定情報

%NnmInstallDir%misc¥nms¥lic

$NnmInstallDir/misc/nms/lic

そのほかのライセンス情報

%NnmDataDir%nmsas¥NNM¥conf

$NnmDataDir/nmsas/NNM/conf

JBossの設定

%NnmDataDir%conf

$NnmDataDir/conf

設定情報

%NnmDataDir%conf¥nnm¥props

$NnmDataDir/conf/nnm/props

ローカルNNMi設定のプロパティファイル

%NnmDataDir%shared¥nnm¥conf¥licensing¥LicFile.txt

$NnmDataDir/shared/nnm/conf/licensing/LicFile.txt

ライセンス情報

%NnmDataDir%NNMVersionInfo

$NnmDataDir/NNMVersionInfo

NNMiバージョン情報ファイル

%NnmDataDir%shared¥nnm¥user-snmp-mibs

$NnmDataDir/shared/nnm/user-snmp-mibs

共有ユーザー追加のSNMP MIB情報

%NnmDataDir%shared¥nnm¥actions

$NnmDataDir/shared/nnm/actions

共有ライフサイクルの移行アクション

%NnmDataDir%shared¥nnm¥certificates

$NnmDataDir/shared/nnm/certificates

共有NNMi SSL証明書

%NnmDataDir%shared¥nnm¥conf

$NnmDataDir/shared/nnm/conf

共有NNMi設定情報

%NnmDataDir%shared¥nnm¥conf¥licensing

$NnmDataDir/shared/nnm/conf/licensing

共有NNMiライセンス設定情報

%NnmDataDir%shared¥nnm¥lrf

$NnmDataDir/shared/nnm/lrf

共有NNMiコンポーネント登録ファイル

%NnmDataDir%shared¥nnm¥conf¥props

$NnmDataDir/shared/nnm/conf/props

共有NNMi設定のプロパティファイル

%NnmDataDir%shared¥nnm¥www¥htdocs¥images

$NnmDataDir/shared/nnm/www/htdocs/images

共有NNMiノードグループマップ背景イメージ

このコンテキストで共有ディレクトリのファイルは，NNMiアプリケーションフェイルオーバーまたは高可用性環境の別のNNMi管理サーバーと共有されるファイルです。

表20‒2　イベント領域ファイルとディレクトリ

ディレクトリまたはファイル名

説明

%NnmDataDir%log¥nnm¥signin.log

$NnmDataDir/log/nnm/signin.log

NNMiコンソールサインインログ

20.3　NNMiデータをリストアする

NNMiリストアスクリプト（nnmrestore.ovpl）は，バックアップデータをNNMi管理サーバーに配置します。バックアップの種類と領域によって，NNMiでリストア可能なバックアップデータが決まります。

メモ

nnmrestore.ovplスクリプトを使用してデータベースレコードを2番目のNNMi管理サーバーに配置する場合は，どちらのNNMi管理サーバーも同じタイプのオペレーティングシステム，NNMiバージョンおよびパッチレベルである必要があります。

重要

クラスタ構成のNNMiで取得したバックアップデータをシングル構成のNNMiにリストアしないでください。

グローバルネットワーク管理機能を使用する場合は，バックアップデータを2番目のNNMi管理サーバーに配置することは，どちらのサーバーのデータベースUUIDも同じであることを意味します。2番目のNNMi管理サーバーにNNMiをリストアしたら，元のNNMi管理サーバーからNNMiをアンインストールします。

オンラインバックアップをリストアするため，NNMiは，ファイルシステムデータを正しい場所にコピーし，バックアップのデータベーステーブルの内容を上書きします。バックアップ以後に削除されたオブジェクトはリストアされます。バックアップ以後に作成されたオブジェクトは削除されます。また，バックアップの実行後に変更されたすべてのオブジェクトは，バックアップ時の状態に戻されます。NNMiデータベースの場合は，nmsdbmgrサービスが実行されている必要があります。

オフラインバックアップをリストアするため，NNMiは，ファイルシステム内のPostgresファイルを上書きし，データベースファイルをバックアップデータで完全に置き換えます。

-forceオプションを指定すると，nnmrestore.ovplコマンドはすべてのNNMiプロセスを停止し，nmsdbmgrサービスを開始し（NNMiデータベースのオンラインバックアップからのリストアの場合），データをリストアし，その後すべてのNNMiプロセスを再開始します。

指定されたソースがtarファイルの場合は，NNMiリストアコマンドで，現在の作業ディレクトリの一時フォルダにtarファイルが抽出されます。この場合，現在の作業ディレクトリに十分な空き容量があることを確認するか，リストアコマンドを実行する前にアーカイブを抽出してください。

メモ

NNMiのあるバージョンから次のバージョンへデータベースのスキーマが変わるおそれがあるため，データバックアップをNNMiの異なるバージョン間で共有することはできません。

20.3.1　同じシステムでのリストア

1つのシステムでバックアップコマンドとリストアコマンドを使用することで，データを復旧できます。バックアップの実行時からリストアの実行時までの間に，次の項目が変更されていないようにする必要があります。

NNMiのバージョン（パッチを含む）

オペレーティングシステムタイプ

キャラクタセット（言語）

ホスト名

ドメイン

20.3.2　異なるシステムでのリストア

バックアップコマンドとリストアコマンドを使用して，NNMi管理サーバーからほかの管理サーバーへデータを転送できます。異なるシステムでのリストアは，システム障害時の復旧や，オペレーティングシステムのバージョンアップでNNMiの異なるシステムへの転送などに使用します。

ヒント

グローバルネットワーク管理機能を使用する場合は，NNMi UUIDがデータベースのリストア中にターゲットシステムにコピーされるため，ソースとターゲットの両システムがNNMiの同じインスタンスを実行するおそれがあります。ソースシステムからNNMiをアンインストールしてください。

メモ

グローバルネットワーク管理を導入する間など，同様の設定で機能するNNMi管理サーバーを複数作成する場合，nnmconfigexport.ovplコマンド，およびnnmconfigimport.ovplコマンドを使用します。

異なるシステムでのリストアは，両方のシステムで次の項目が同じである必要があります。

NNMiのバージョン（パッチを含む）

オペレーティングシステムタイプ

キャラクタセット（言語）

次の項目は，2つのシステム間で異なっていてもかまいません。

ホスト名

ドメイン

異なるシステムでのリストアの場合，nnmrestore.ovplコマンドはライセンス情報を新規システムにコピーしません。新しいNNMi管理サーバーの新規ライセンスを取得して適用してください。詳細については，ライセンスのマニュアルを参照してください。

20.4　バックアップとリストアの方針

20.4.1　すべてのデータを定期的にバックアップする

ディザスタリカバリ計画には，すべてのNNMiデータの完全バックアップを定期的に実行するスケジュールを含めてください。このバックアップを作成するためにNNMiを停止する必要はありません。バックアップをスクリプトに組み込む場合は，-forceオプションを使用して，バックアップが開始される前にNNMiが正しい状態になるようにしてください。

（例）

nnmbackup.ovpl -force -type online -scope all -archive -target nnmi_backups¥periodic

ハードウェアの障害のためにNNMiデータの復旧が必要になった場合は，次の手順を実行します。

ハードウェアを再構成するか，新規ハードウェアを取得する。

バックアップデータの場合と同じバージョンおよびパッチレベルのNNMiをインストールする。

NNMiデータをリストアする。

リカバリNNMi管理サーバーが「20.3.1　同じシステムでのリストア」にある要件を満たす場合は，次の例のようなコマンドを実行します。

nnmrestore.ovpl -force -lic -source nnmi_backups¥periodic¥newest_backup

リカバリNNMi管理サーバーが同じシステムでのリストアを行うのに適格ではなくても，「20.3.2　異なるシステムでのリストア」の一覧にある要件を満たす場合は，次の例のようなコマンドを実行します。

nnmrestore.ovpl -force -source nnmi_backups¥periodic¥newest_backup

必要に応じてライセンスを更新します。

20.4.2　設定変更前のデータをバックアップする

設定変更を開始する前に，領域を限定したバックアップを必要に応じて実施してください。バックアップの領域については，「20.2.2　バックアップ領域」を参照してください。領域を限定したバックアップをすると，設定を変更しても期待した効果が見られない場合，周知の作動設定に戻すことが可能になります。

（例）

nnmbackup.ovpl -type online -scope config -target nnmi_backups¥config

このバックアップを同じNNMi管理サーバーにリストアするには，すべてのNNMiプロセスを停止してから，次の例のようなコマンドを実行します。

nnmrestore.ovpl -force -source nnmi_backups¥config¥newest_backup

20.4.3　NNMiまたはオペレーティングシステムのバージョンアップ前のデータをバックアップする

大規模なシステム変更（NNMiまたはオペレーティングシステムのアップグレードを含む）を行う前に，すべてのNNMiデータの完全バックアップを実行します。バックアップの実行後NNMiデータベースが変更されないようにするため，すべてのNNMiプロセスを停止し，オフラインバックアップを作成してください。

（例）

nnmbackup.ovpl -type offline -scope all -target nnmi_backups¥offline

システムの変更後にNNMiが正常に実行されなくなった場合は，変更をロールバックするか，または異なるNNMi管理サーバーをセットアップし，「20.3.2　異なるシステムでのリストア」の一覧にある要件が確実に満たされるようにしてください。その後，次の例のようなコマンドを実行します。

（例）

nnmrestore.ovpl -source nnmi_backups¥offline¥newest_backup

必要に応じてライセンスを更新します。

20.4.4　ファイルシステムのファイルだけをリストアする

データベーステーブルに影響を与えることなくNNMiファイルを上書きするには，次の例のようなコマンドを実行します。

（例）

nnmrestore.ovpl -partial -source nnmi_backups¥offline¥newest_backup

20.5　データベースをバックアップおよびリストアする

NNMiでは，nnmbackupembdb.ovplコマンドとnnmrestoreembdb.ovplコマンドによって，NNMiデータベースだけをバックアップおよびリストアします。この機能は，NNMiの設定でデータのスナップショットを作成する場合に便利です。

nnmbackupembdb.ovplコマンドは，オンラインバックアップだけを実行します。最低でも，nmsdbmgrサービスが実行されている必要があります。

各バックアップ操作によって，ターゲットディレクトリ内のnnm-bak-<TIMESTAMP>という名前の親ディレクトリにファイルが格納されます。-noTimeStampオプションを指定すると，ディスクスペースを節約できます。-noTimeStampオプションを使用した場合，親ディレクトリの名前はnnm-bakになります。前回のバックアップ後に-noTimeStampオプションを使用してバックアップが行われると，前回のバックアップの名前がnnm-bak.previousに変更されて，ローリングバックアップが作成されます。この名前変更は，2回目のバックアップの完了後，バックアップデータの喪失を防止するために行われます。

ヒント

nnmresetembdb.ovplコマンドは，データベースにデータをリストアする前に実行してください。このコマンドによってデータベースにエラーが含まれないようになるため，データベース制約違反が発生するおそれがなくなります。データベースリセットコマンドの実行については，nnmresetembdb.ovplのリファレンスページを参照してください。

21　NNMiの保守

NNMi管理サーバーが機能するようになったら，複数のNNMi機能を最適化するためにメンテナンス作業を実施できます。

21.1　NNMiフォルダのアクセス制御リストの管理

NNM Action Serverを実行するユーザー名の変更が必要な場合があります。権限を変更しないでアクションサーバーを実行するユーザー名を変更すると，NNM Action Serverが起動しなくなり，インシデントアクションの実行中にNNMiがメッセージを記録しなくなるおそれがあります。この発生を防ぐ方法について説明します。

NNMiには，次のフォルダを変更する権限が含まれています。

/var/opt/OV/log/nnm/public

/var/opt/OV/shared/perfSpi

NNMiの/var/opt/OV/log/nnm/publicフォルダに対する既定の権限は755ですが，NNMiはACLを使用して，データベースユーザー（nmsdbmgr）およびnnmactionユーザー（bin）のアクセス権を調整します。NNMiのポストインストール（インストールまたはアップグレードスクリプトの一部）中に，インストールスクリプトによって/var/opt/OV/log/nnm/publicフォルダの権限が変更され，ACLが追加されます。

インストールスクリプトが予期しないエラーによって/var/opt/OV/log/nnm/publicフォルダにACLを設定できない場合，スクリプトは/var/opt/OV/log/nnm/publicフォルダをワールド（そのほかのユーザー）によって書き込み可能にし，NNMiインストールは正常に完了します。NNMiインストールの成功後，/var/opt/OV/log/nnm/publicフォルダへのワールドによる書き込み権限を制限するには，NNMi管理サーバーのオペレーティングシステムにACLを設定するためのシステム管理者マニュアルを参照してください。

/var/opt/OV/log/nnm/publicフォルダのユーザーアクセスを調整するには，Linux ACL（アクセス制御リスト）を使用します。ACLの設定は，owner/group/otherの権限を拡張するのに役立ちます。ACLは，Linuxでサポートされています。

例えば，次のコマンドの実行後，USER変数で示されたユーザーは/var/opt/OV/log/nnm/publicフォルダへの書き込み権限を取得します。次のコマンドを実行しない場合，/var/opt/OV/log/nnm/publicフォルダの権限は755で，ルート以外のユーザーはディレクトリ内のファイルに書き込めません。

setfacl -m user:<USER>:rwx /var/opt/OV/log/nnm/public

setfaclコマンドの使用方法の詳細については，該当するリファレンスページを参照してください。

21.2　ノードグループの設定

NNMiには，ノードグループの設定を自動化できるコマンドラインツールが用意されています。nnmnodegroup.ovplコマンドでは，ノードグループの作成，表示，変更，および削除ができます。

詳細については，nnmnodegroup.ovplのリファレンスページを参照してください。

21.3　ノードグループマップ設定の構成

ノードグループマップの設定は，NNMiコンソールだけでなく，nnmnodegroupmapsettings.ovplコマンドラインツールを使用して行うこともできます。nnmnodegroupmapsettings.ovplツールでは，ノードグループマップの設定を作成，変更，および削除できます。このツールを使用して，TXT，XML，またはCSV形式で現在のノードグループマップの設定を表示することもできます。

メモ

NNMiを現在実行しているWebブラウザをリフレッシュすると，ノードグループマップの設定に加えた変更がただちに反映されます。

詳細については，nnmnodegroupmapsettings.ovplのリファレンスページを参照してください。

21.4　通信設定の構成

nnmcommunication.ovplコマンドラインツールを使用して，NNMi通信設定を行うことができます。nnmcommunication.ovplツールでは，通信設定を作成，表示，変更，削除できます。このツールでは，テキストテーブル，テキストリスト，またはXML形式でリストを生成できます。

管理者は，nnmcommunication.ovplツールを使用して，管理アドレスやコミュニティ文字列などのフィールドのSNMPエージェント設定をロックして直接管理することで，通常の設定をバイパスすることもできます。

nnmcommunication.ovplツールは，デフォルト，ノード固有，リージョン固有，およびSNMPエージェント固有の各設定において，コマンドラインインタフェース（CLI）によるSNMPプロキシポートやSNMPプロキシアドレスの作成，更新，および削除をサポートしています。

詳細については，nnmcommunication.ovplのリファレンスページを参照してください。

21.5　カスタムポーラー収集エクスポートの管理

カスタムポーラー機能では，SNMP MIB式を使用してNNMiがポーリングする必要のある追加情報を指定することによって，積極的にネットワーク管理を行えます。カスタムポーラー収集は，収集（ポーリング）する情報およびそれらの情報のNNMiによる処理方法を定義します。詳細については，NNMiヘルプの「カスタムポーラー収集を作成する」および「カスタムポーラー設定を作成する」を参照してください。

カスタムポーラー機能を使用する場合でも，処理が終わったファイルをエクスポートディレクトリから削除するのはユーザーの責任です。長期の保存にエクスポートファイルを使用しないでください。設定された最大ディスク容量を超えると，NNMiによって古いファイルが削除され，新しいファイルが作成されます。これらのファイルを別の場所に保存していないと，ファイルは失われます。

21.5.1　カスタムポーラー収集のエクスポートディレクトリを変更する

NNMiは，ユーザーがエクスポートした収集データを次のディレクトリに書き込みます。

Windows：%NNM_DATA%¥shared¥nnm¥databases¥custompoller¥export

Linux：$NNM_DATA/shared/nnm/databases/custompoller/export

NNMiがカスタムポーラーファイルを書き込むディレクトリを変更するには，次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-custompoller.properties

Linux：$NNM_PROPS/nms-custompoller.properties

exportdirエントリを特定する。

このエントリは次の行のように記述されています。

#!com.hp.nnm.custompoller.exportdir=<base directory to export custom poller metrics>

NNMiがカスタムポーラー収集情報をC:¥CustomPollerディレクトリに書き込むように設定するには，次のように行を変更します。

com.hp.nnm.custompoller.exportdir=C:/CustomPoller

行の始めにある#!文字を必ず削除してください。

重要

Windowsの場合も，ディレクトリの区切り文字には「¥」ではなく「/」を使用してください。

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.5.2　カスタムポーラー収集のエクスポートに使用する最大ディスク容量を変更する

collection_name.csvファイルにデータをエクスポートするときにNNMiが使用する最大ディスク容量を変更するには，次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-custompoller.properties

Linux：$NNM_PROPS/nms-custompoller.properties

maxdiskspaceエントリを特定する。

このエントリは次の行のように記述されています。

#!com.hp.nnm.custompoller.maxdiskspace=1000

各collection_name.csvファイルに最大2,000MB（2GB）のストレージ容量を確保するようにNNMiを設定するには，その行を次のように変更します。

com.hp.nnm.custompoller.maxdiskspace=2000

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.5.3　カスタムポーラーメトリックスの累積周期を変更する

NNMiは，データをファイルに書き込む前に，カスタムポーラー収集メトリックスを累積する期間を分単位で設定します。カスタムポーラーメトリックスの累積周期を変更するには，次の手順に従います。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-custompoller.properties

Linux：$NNM_PROPS/nms-custompoller.properties

次のような行を特定する。

#!com.hp.nnm.custompoller.accumulationinterval=5

デフォルト値である5分間ではなく10分間，メトリックスを収集するようにNNMiを設定するには，その行を次のように変更します。

com.hp.nnm.custompoller.accumulationinterval=10

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.6　インシデントアクションの管理

アクションは，インシデントライフサイクルの任意の時点で自動的に実行されるように設定できます。例えば，設定しているタイプのインシデントが生成されるときにあるアクションが発生するように設定します。詳細については，NNMiヘルプの「インシデントのアクションを設定する」を参照してください。

アクションのパラメーターを調整するには，次のセクションに示す手順に従ってください。

21.6.1　同時アクション数を設定する

NNMiが実行できる同時アクション数を変更するには，次の手順に従います。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nnmaction.properties

Linux：$NNM_PROPS/nnmaction.properties

次のような行を特定する。

#!com.hp.ov.nms.events.action.numProcess=10

デフォルト値ではなく，20個の同時アクションを実行できるようにNNMiを設定するには，その行を次のように変更します。

com.hp.ov.nms.events.action.numProcess=20

行の始めにある#!文字を必ず削除してください。

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.6.2　Jythonアクションのスレッド数を設定する

jythonスクリプトを実行するためにアクションサーバーが使用するスレッド数を変更するには，次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nnmaction.properties

Linux：$NNM_PROPS/nnmaction.properties

次のような行を探す。

#!com.hp.ov.nms.events.action.numJythonThreads=10

デフォルトのスレッド数ではなく，20個のスレッドでjythonスクリプトを実行できるようにNNMiを設定するには，その行を次のように変更します。

com.hp.ov.nms.events.action.numJythonThreads=20

行の始めにある#!文字を必ず削除してください。

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.6.3　アクションサーバー名のパラメーターを設定する

WindowsのNNMi管理サーバーでアクションサーバーを実行するユーザー名を変更するには，次の手順を実行してください。

NNM Action ServerサービスのLogOnプロパティを変更する。

(管理者権限を持つユーザー名を指定してください)

次のコマンドを実行して，アクションサーバーを停止する。

ovstop nnmaction

重要

クラスタ構成の場合は，事前にメンテナンスモードにし，手順4. 実施後に解除してください。

対象ディレクトリ配下の，条件に合致するファイルをすべて削除する。

対象ディレクトリ：

-シングル構成の場合：%NnmDataDir%log¥nnm

-クラスタ構成の場合：<HA_MOUNT_POINT>¥NNM¥log¥nnm

上記ディレクトリ配下の以下のファイル

- "nnmaction"で始まる名前のファイル

- "incidentActions"で始まる名前のファイル

次のコマンドを実行して，アクションサーバーを起動する。

ovstart nnmaction

LinuxのNNMi管理サーバーでアクションサーバーを実行するユーザー名を変更するには，次の手順を実行します。

次のファイルを編集する。

$NNM_PROPS/nnmaction.properties

次のような行を特定する。

#!com.hp.ov.nms.events.action.userName=bin

デフォルト値ではなく，「system」というユーザがアクションサーバーを実行するようにNNMiを設定するには，その行を次のように変更します。

com.hp.ov.nms.events.action.userName=system

行の始めにある#!文字を必ず削除してください。

変更を保存する。

次のコマンドを実行して，アクションサーバーを停止する。

ovstop nnmaction

重要

クラスタ構成の場合は，事前にメンテナンスモードにし，手順7. 実施後に解除してください。

次のコマンドを実行し，インシデントアクションログディレクトリに権限を追加する。

-シングル構成の場合:

setfacl -m user:<ユーザー名>:rwx /var/opt/OV/log/nnm/public

-クラスタ構成の場合:

setfacl -m user:<ユーザー名>:rwx <HA_MOUNT_POINT>/NNM/log/nnm/public

※<ユーザー名> には，手順2.で指定したユーザーを指定します。

対象ディレクトリ配下の，条件に合致するファイルをすべて削除する。

対象ディレクトリ：

- シングル構成の場合：/var/opt/OV/log/nnm/public

- クラスタ構成の場合：<HA_MOUNT_POINT>/NNM/log/nnm/public

上記対象ディレクトリ配下の以下のファイル

- "nnmaction"で始まる名前のファイル

- "incidentActions"で始まる名前のファイル

次のコマンドを実行して，アクションサーバーを起動する。

ovstart nnmaction

21.6.4　アクションサーバーのキューサイズを変更する

短期間に大量に発生するインシデントに長時間終了しないコマンドをインシデントアクションとして設定した場合，アクションサーバーは多くのメモリを使用するおそれがあります。アクションサーバーのパフォーマンスを上げるために，アクションサーバーで使用可能なメモリサイズが制限されています。

これらの制限を変更するには，次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nnmaction.properties

Linux：$NNM_PROPS/nnmaction.properties

次のような2行を探す。

com.hp.ov.nms.events.action.jvmargs.minMemsize=-Xms6m
com.hp.ov.nms.events.action.jvmargs.maxMemsize=-Xmx30m

上記のパラメーターでは，最小メモリサイズが6MBに，最大が30MBに設定されていることがわかる。これらのパラメーターをニーズに合わせて調整する。

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.6.5　インシデントアクションのログ

アクションが実行されると，実行結果がインシデントアクションのログファイルに記録されます。このログの内容を確認するためには，［ツール］＞［インシデントアクションログ］を実行します。このログファイルに記録される項目については，次の表を参照してください。

表21‒1　インシデントアクションログに記録される項目一覧

項目

説明

コマンド

インシデントが設定されたライフサイクル状態になったときに実行されるコマンド

インシデント名

インシデントの名前

インシデントUUID

インシデントのUUID（［登録］タブに表示）

コマンドのタイプ

コマンドのタイプ（Jython，またはScriptOrExecutable）

ライフサイクル状態

インシデントのライフサイクル状態（Registered，In Process，Completed，またはClosed）

終了コード

コマンドの戻り値

標準出力

標準出力への出力内容

標準エラー

標準エラー出力への出力内容

実行ステータス

アクションの実行結果

21.7　server.propertiesファイルの設定の上書き

システムには2つのserver.propertiesファイルがある場合があります。

次のファイルは製品のインストーラーによって作成され，アプリケーションインスタンス用にアプリケーションサーバーをカスタマイズするプロパティが含まれています。このファイルはユーザーによる変更は不可能で，コードメンテナンス（アップグレードおよびパッチ）で置き換えられます。

Windows：%NnmInstallDir%NNM¥server¥server.properties

Linux：$NnmInstallDir/NNM/server/server.properties

次のファイルは，ユーザーによって独自の環境用にアプリケーションを設定するために使用され，製品によってアップグレードまたはパッチで変更されることはありません。このファイルは，その他のファイルで設定された値を上書きします。そのため，すべてのカスタマイズはこのファイルで実行されます。

Windows：%NnmDataDir%nmsas¥NNM¥server.properties

Linux：$NnmDataDir/nmsas/NNM/server.properties

21.7.1　ブラウザのロケール設定の上書き

次のserver.propertiesファイルを使用して，ブラウザのロケール値に関係なく，指定されたロケール値をすべてのNNMiクライアントに強制的に適用できます。

Windows：%NnmDataDir%nmsas¥NNM¥server.properties

Linux：$NnmDataDir/nmsas/NNM/server.properties

server.propertiesファイルを使用してこの値が設定されている場合，ブラウザのロケール値は無視されます。

ブラウザのロケール設定を上書きするには，次の手順を実行します。

server.propertiesファイルを開く。

Windows：%NnmDataDir%nmsas¥NNM¥server.properties

Linux：$NnmDataDir/nmsas/NNM/server.properties

HA 環境の場合，「19.5.1　NNMiの共有ディスク内のデータ」も参照してください。

nmsas.server.forceClientLocaleに移動する。

nmsas.server.forceClientLocaleを次のどちらかに設定する。

nmsas.server.forceClientLocale= <2文字のISO言語コード>

例えば，ISO言語コードだけを使用してロケールを英語に設定するには，次のように入力します。

（例）

nmsas.server.forceClientLocale = en

nmsas.server.forceClientLocale= <2文字のISO言語コード>_<2文字のISO国コード>

例えば，ISO言語コードと国コードを使用してロケールを英語に設定するには，次のように入力します。

（例）

nmsas.server.forceClientLocale = en_US

次のコマンドをNNMi管理サーバーで実行して，NNMi ovjbossサービスを再起動する。

ovstop ovjboss
ovstart

server.propertiesファイルへの変更は，ovjbossの起動時にだけ読み取られます。

詳細については，server.propertiesファイル内のコメントを参照してください。

21.7.2　SNMP Setオブジェクトアクセス権限の設定

次のファイルを使用して，ユーザーがアクセスできるノードでSNMP Set機能を使用するために必要なオブジェクトアクセス権限を設定できます。

Windows：%NnmDataDir%nmsas¥NNM¥server.properties

Linux：$NnmDataDir/nmsas/NNM/server.properties

SNMP Set機能の詳細については，NNMiヘルプを参照してください。オブジェクトアクセス権限の詳細については，NNMiヘルプ「管理」を参照してください。

SNMP Set機能に対するオブジェクトアクセス権限を設定するには，次の手順を実行します。

server.propertiesファイルを開く。

Windows：%NnmDataDir%nmsas¥NNM¥server.properties

Linux：$NnmDataDir/nmsas/NNM/server.properties

HA 環境の場合，「19.5.1　NNMiの共有ディスク内のデータ」も参照してください。

次の行を追加する。

permission.override.com.hp.nnm.SNMP_SET=<オブジェクトアクセスロール>

<オブジェクトアクセスロール>で有効な値は次のとおりです。

com.hp.nnm.ADMIN
com.hp.nnm.LEVEL2
com.hp.nnm.LEVEL1
com.hp.nnm.GUEST

例えば，［オブジェクト管理者］および［オブジェクトオペレーターレベル2］オブジェクトアクセス権限でSNMP Set機能を使用できるようにするには，次のように入力します。

（例）

permission.override.com.hp.nnm.SNMP_SET=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2

アクセスを有効にする各オブジェクトアクセス権限を含める。

次のコマンドをNNMi管理サーバーで実行して，NNMi ovjbossサービスを再起動する。

ovstop ovjboss
ovstart

server.propertiesファイルへの変更は，ovjbossの起動時にだけ読み取られます。

21.8　SNMPトラップの管理

ここでは，タスクの実行方法について説明します。

21.8.1　SNMPv3以外で管理されているノードまたは監視対象外のノードのSNMPv3トラップを認証するためのNNMiの設定

NNMiが次のいずれかの条件を満たしているノードからSNMPv3トラップを受信している場合，このセクションの手順を実行します。

デバイスがSNMPv2またはSNMPv1を使用して管理されている。

デバイスが非SNMPノードとして管理されている。

デバイスがNNMiによって検出されていない。

これらのデバイスのSNMPv3エンジンIDをSNMPv3キャッシュに追加するようにNNMiを設定できます。

このようにNNMiを設定することで，NNMiはこれらのSNMPv3トラップを認証して保存できます。

SNMPv3以外で管理されているノードまたは検出されていないノードのSNMPv3トラップを受信して保存するようにNNMiを設定するには，次の手順を実行します。

NNMiコンソールで，［設定］＞［通信の設定］に移動する。

各受信トラップにトラップの認証に使用するための対応する設定が適用されるように，［領域］または［特定ノードの設定］レベルのデフォルトのエントリを設定します。詳細については，NNMiヘルプの「デフォルトSNMPv3を設定する」を参照してください。

メモ

SNMPv3ノードの含まれるアドレス範囲の領域を使用するか，それぞれに対して［特定ノードの設定］を設定することをお勧めします。

NNMiコンソールで，［設定］＞［インシデント］＞［インシデントの設定］に移動する。

NNMiが検出していないデバイスからのSNMPv3トラップを受信する場合，［未解決のSNMPトラップおよびSyslogメッセージを破棄する］を選択解除する。

メモ

［未解決のSNMPトラップおよびSyslogメッセージを破棄する］の選択を解除すると，NNMi は検出していないデバイスから送信されたSNMPトラップを受信して保存するようになります。

NNMi管理サーバーでovstopコマンドを実行する。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-communication.properties

Linux：$NNM_PROPS/nms-communication.properties

ファイルの最下部に次の行を追加する。

com.hp.nnm.snmp.engineid.file=<ファイルへのパス>file.txt

<ファイルへのパス>file.txtエントリは，デバイスを含むファイルの完全なパスとファイル名です。

これらの設定の変更によって，NNMiはNNMiプロセスが再起動されるたびにこのファイルからのエントリをSNMPv3キャッシュに読み込みます。

重要

Linux NNMi管理サーバーでは，ファイルパスは/var/opt/OV/etcなどの通常の形式です。

Windows NNMi 管理サーバーでは，区切り文字としてスラッシュを使用します。例えば，C:/temp/file.txtなどの形式になります。

変更を保存する。

<ファイルへのパス>file.txtファイルを編集する。

a　デバイスのIPアドレス，ポート，およびエンジンIDの各項目をカンマで区切って追加します。

b　個別の行にデバイスごとに1つのエントリを追加します。

エンジンIDは一連の16進数バイトです。NNMiは大文字と小文字を区別しないで，スペースを認識します。

次の例を使用してエントリを作成します。

16.1.2.3,161,80 00 00 09 30 00 00 1f e9 a3 33 01
16.1.2.4,161,80 00 00 11 03 00 00 2d 51 99 30 00
1050:0000:0000:0000:0005:0600:300c:326b, 161, 800000090300001f9ea33000
ff06::c3,161,80 00 00 09 03 00 00 1f 9A A3 30 00

a　NNMi管理サーバーでovstartコマンドを実行し，NNMiを起動して<ファイルへのパス>file.txtファイルを読み込みます。

b　Boot.logファイルで，NNMiがファイルを読み込んでいることを確認します。

このファイルに，ファイルが読み込まれたことを示す次のようなログメッセージが含まれていることを確認します。

2012-10-17 14:44:44.876 INFO ［NnmTrapService］Start: Populate engineIDs from file
2012-10-17 14:45:08.017 INFO ［SnmpV3EngineIdCachePopulator］Successfully loaded 3 V3
Engine IDs from file /temp/patch2/v3hosts.txt

ノードの有効な設定へのマッピングエラーが発生した場合は，次のようなメッセージが含まれています。

2012-10-17 14:45:03.485 WARNING ［SnmpV3EngineIdCachePopulator］V3
Engine IDs: Could not resolve SNMPv3 configuration for 16.1.2.6

上記のようなメッセージが含まれている場合は，このノードの［設定］＞［通信の設定］設定を調整します。

メモ

<ファイルへのパス>file.txtファイルだけでなくキャッシュからもエントリを削除する必要がある場合，<ファイルへのパス>file.txtからエントリを削除してから，次のコマンドを実行して，NNMiを再起動することが最良の方法です。

ovstop

ovstart

21.8.2　SNMPv1トラップまたはSNMPv2cトラップのブロック

SNMPv3のみを使用するようにデバイス検出を設定したにもかかわらず，一部の管理対象ノードが，引き続きNNMi管理サーバーにSNMPv1トラップまたはSNMPv2cトラップの送信を試みる場合があります。SNMPv1トラップまたはSNMPv2cトラップがNNMi管理サーバーに到達しないように，SNMPv3トラップのみを受け入れ，SNMPv1トラップおよびSNMPv2cトラップをすべてブロックするようにNNMiを設定することをお勧めします。

注：この設定手順を完了する前に，SNMPv3プロトコルを使用するネットワークを検出するようにNNMiが設定されていることを確認します。

NNMi管理サーバーにログオンします。

次のコマンドを実行します。

Windowsの場合：

%NnmInstallDir%bin¥nnmtrapconfig.ovpl -setProp disallowV1V2 -persist

Linuxの場合：

/opt/OV/bin/nnmtrapconfig.ovpl -setProp disallowV1V2 -persist

次のいずれかを実行します。

Windowsの場合：［サービス］ウィンドウからNNM TrapReceiverサービスを再起動します。

Linuxの場合：次のコマンドを実行します。

/opt/OV/bin/nettrap stop
/opt/OV/bin/nettrap start

21.8.3　Causal Engineがトラップを受け入れる期間の設定

広範囲のネットワークが一定の予測できる時間に利用できなくなる場合，NNMiではCausal Engineへのトラップの配信を阻止することで，Causal Engineの分析負荷を抑制できます。トラップの配信を阻止するには，NNMi管理者として，NNMi Causal Engineがイベントシステムからのトラップの受け入れを停止する期間を設定します。

重要

この機能は，NNMiコンソールに配信されるトラップには影響しません。

Causal Engineに配信されるトラップは，StatePollerをトリガーし，StatePollerのポーリングポリシーによって指示されたスケジュールよりも早くノードをポーリングする場合に使用されます。トラップの配信を阻止する場合，NNMiはStatePollerから更新情報を取得する前に，スケジュールされたポーリング間隔まで待機する必要があります。あらゆる場合に，NNMi Causal EngineはNNMi StatePollerからのステートフローを使用して，トラップがあるかないかにかかわらず同じ結論に達します。

Causal Engineがトラップの受け入れを停止する期間を設定するには，次の手順を実行します。

次のファイルを作成する。

Windows：%NNM_PROPS%¥nms-apa.properties

Linux：$NNM_PROPS/nms-apa.properties

ファイルに次の内容を追加する。

PROPERTY NAME: com.hp.ov.nms.apa.trapGateSchedule

次の例をガイドラインとして使用します。

次の例では，トラップは深夜に流れ，午前8:30に阻止され，午前10:00に再度流れてから，午後4:30に再度阻止されます。

com.hp.ov.nms.apa.trapGateSchedule = ENABLE_APA_TRAPS 08:30 10:00 16:30

次の例では，トラップは深夜に阻止され，午前8:30に再度流れ，午前10:00に阻止されてから，午後4:30に再度流れます。

com.hp.ov.nms.apa.trapGateSchedule = DISABLE_APA_TRAPS 08:30 10:00 16:30

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.9　trapFilter.confファイルでインシデントをブロックする

NNMi管理サーバー上のインシデントの数が一定のレートに達して，新しく到着するインシデントをNNMiがブロックする場合，次の点に注意してください。

NNMiはTrapStormインシデントを生成し，インシデントがブロックされていることを示します。

NNMiは主要なヘルスメッセージも生成し，インシデントレートが高くてインシデントがブロックされていることを示すことがあります。

インシデント数を削減するには，次のどちらかの方法を使用します。

nnmtrapd.confファイルを使用し，インシデントがNNMiに入るのをブロックしてインシデントトラフィックの削減を試みます。

重要

nnmtrapd.confファイルによる方法を使用すると，NNMiは引き続きこれらのインシデントを使用してトラップレートを計算し，トラップバイナリストアに書き込みます。nnmtrapd.confファイルによる方法を使用しても，インシデントがデータベースで作成されたり保存されたりすることを停止することしかできません。

詳細については，nnmtrapd.confのリファレンスページを参照してください。

trapFilter.confファイルを使用し，NNMiイベントパイプラインで早期にインシデントをブロックして，このインシデントがトラップレート計算で分析されること，またはNNMiトラップバイナリストアに保存されることを回避します。

メモ

デバイスのIPアドレスまたはOIDをtrapFilter.confファイルに追加すると，この大量のインシデントをブロックして，インシデントのボリュームの問題を回避できます。

詳細については，trapFilter.confおよびnnmtrapconfig.ovplのリファレンスページを参照してください。

21.10　NNMiの文字セットエンコードの設定

NNMi管理サーバーに設定したロケールに応じて，NNMiでSNMP OCTETSTRINGデータの解釈に使用するソースエンコードの設定が必要な場合があります。これを行うには，nms-jboss.propertiesファイルを次のように編集します。

環境に応じて次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を含むテキストブロックを探す。

#!com.hp.nnm.sourceEncoding=UTF-8

この行のコメントを解除する。

com.hp.nnm.sourceEncoding=UTF-8

nms-jboss.propertiesファイルに記述されているコメント文の例に従って，手順3.で示されたプロパティ値（UTF-8）を変更する。

nms-jboss.propertiesファイルを保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.11　MIBブラウザパラメータの変更

NNMi MIB ブラウザ（［アクション］＞［MIB 情報］＞［MIB を参照］メニュー）を使用して，ノードの情報を取得し， SNMP コミュニティ文字列（省略可能）をそのノードに指定する場合は，NNMi MIB ブラウザは，MIB ブラウザ SNMP 通信用のnms-ui.propertiesファイルにある MIB ブラウザパラメータを使用します。

重要

MIBブラウザを使用するときにコミュニティ文字列を使用しない場合は，NNMiではノードで確立されている［通信の設定］設定（ある場合）を使用します。これらの設定は，［設定］ワークスペースの［通信の設定］ビューを使用してNNMiコンソールで設定されます。詳細については，NNMi ヘルプの「通信プロトコルを設定する」を参照してください。

環境に応じて次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-ui.properties

Linux：$NNM_PROPS/nms-ui.properties

次の行を含むテキストブロックを探す。

# MIB Browser Parameters

次のテキストを含む行を検索し，# MIB Browser Parametersの下にある MIB ブラウザパラメータを探す。

mibbrowser

nms-ui.propertiesファイル内の手順に従って，MIB ブラウザパラメータを変更する。

nms-ui.propertiesファイルを保存する。

次のコマンドを実行して，NNMi を再起動する。

ovstop
ovstart

21.12　レベル 2 オペレータがノードおよびインシデントを削除できるように構成する

デフォルトの NNMi では， NNMi は NNMi 管理者に対して NNMi でのノードまたはインシデントの作成，編集，削除を許可します。 NNMi オペレーターレベル2（L2）ユーザーグループに割り当てられたアカウントに対しても，ノードまたはインシデントの削除を許可するように設定できます。この設定は次のいずれかの方法で実行できます。

（推奨）必要なノードまたはインシデントを削除するため L2 ユーザーの必要な権限を引き上げる。この設定は， NNMi Web コンソールを使用して行うことができます。詳細については，NNMi 管理者ヘルプを参照してください。

L2 ユーザーが全体的にノードまたはインシデントを削除できるように NNMi を設定する。この設定は，一定の NNMi プロパティファイルを変更してデフォルト権限を上書きすることで行うことができます。

重要

上書きによる方法は，全体的に許可する場合だけに使用してください。一度許可すると，NNMi WebコンソールでL2ユーザーアクセス権限を制御できなくなります。

L2 ユーザーがノード，ノードに関連するインシデント，またはこの両方を編集または削除できるようにするには，次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-topology.properties

Linux：$NNM_PROPS/nms-topology.properties

必要に応じて次の行を追加します。

L2 ユーザーがノードを削除できるようにするには，次の行を追加します。

permission.override.com.hp.nnm.DELETE_OBJECT=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2

L2 ユーザーがインシデントを削除できるようにするには，次の行を追加します。

permission.override.com.hp.nnm.incident.DELETE=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2

ファイルを保存します。

次のコマンドを実行して， NNMi を再起動する。

ovstop
ovstart

HA 下でファイルに変更を加えるときには，クラスタの両方のノードで変更を加える必要があります。 HA 構成を使用している NNMi の場合， NNMi 管理サーバーの停止と再起動が必要な変更を加えたときには，ovstopおよびovstartコマンドを実行する前に，ノードをメンテナンスモードにする必要があります。

21.13　レベル2オペレータがマップを編集できるように構成する

デフォルトのNNMiでは，NNMi管理者は，ノードグループの作成，変更，および削除によって，マップを編集できます。NNMiレベル2オペレータのユーザーグループに割り当てられたアカウントを構成して，この編集を可能にすることもできます。

NNMiを変更して，NNMiレベル2オペレータのユーザーグループに割り当てられたユーザーアカウントが，アクセス権を持つノード上のノードグループを作成，変更，および削除する必要がある場合は，次のようにします。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-ui.properties

Linux：$NNM_PROPS/nms-ui.properties

次のテキストブロックを探し，コメントを解除する。

#!com.hp.nnm.ui.level2MapEditing = true

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

HA下でファイルに変更を加えるときには，クラスタの両方のノードで変更を加える必要があります。HA構成を使用しているNNMiでは，NNMi管理サーバーの停止と再起動が必要な変更を加えた場合には，ovstopおよびovstartコマンドを実行する前に，ノードをメンテナンスモードにする必要があります。

手順1.から手順5.までを行うと，NNMiコンソールは次のように変化します。

［インベントリ］＞［ノードグループ］メニューに，NNMiレベル2オペレータの［新規作成］および［削除］ツールバーアイコンが表示される。

ノードグループフォームのツールバーに［保存して新規作成］および［ノードグループを削除］ボタンが含まれる。

［すべてのノードグループ］フォルダが［トポロジマップ］ワークスペースに表示される。詳細については，NNMiオンラインヘルプの「ワークスペースについて」を参照してください。

ノードグループマップの場合，NNMiコンソールに［マップの保存］ツールバーボタンと，［ファイル］＞［マップの保存］メニュー項目が含まれます。

［レイアウトの保存］動作は，ノードグループマップにノードグループマップの設定が存在するかどうかによって異なります。ノードグループマップにノードグループマップの設定が存在しない場合は，作成する必要があります。

NNMiレベル2オペレータのユーザーにノードグループマップ設定の作成権限を付与するようにNNMiを設定することもできます。

NNMiコンソールから，［トポロジマップ］>［ノードグループの概要］を開く。

関心のある［ノードグループ］アイコンをダブルクリックする。

NNMiは，選択したノードグループに関連づけられたノードグループマップを開きます。

次の手順を実行して，変更するノードグループマップの設定を開く。

［ファイル］＞［ノードグループマップの設定を開く］を選択します。

［マップの保存のための最小NNMiロール］を［オペレーターレベル2］に設定する。

変更を保存する。

これで，NNMiレベル2オペレータは，ノードグループマップビューからノードグループマップの設定，編集，および削除ができます。

21.14　レベル1オペレータがステータスのポーリングおよび設定のポーリングを実行できるように構成する

NNMiでは，NNMiレベル2オペレータのユーザーグループに割り当てられたユーザーアカウントは，アクセス権があるノードに対してステータスのポーリングと設定のポーリングを実行できます。それぞれのnms-topology.propertiesファイルでオブジェクトアクセス権限レベルを変更するだけでなく，NNMiコンソールで［メニュー項目］設定も変更する必要があります。

NNMiを変更して，NNMiレベル1オペレータのユーザーグループに割り当てられたユーザーアカウントがステータスのポーリングおよび設定ポーリングを実行する場合は，次のようにします。

［設定］>［ユーザーインタフェース］>［メニュー項目］>［ステータスのポーリング］フォームを開く。

［メニュー項目コンテキスト］タブから，変更しなければならない［必要なNNMiロール/オブジェクトのタイプ］項目の各エントリを開く。

レベル1オペレータにステータスのポーリングを実行させたい各オブジェクトタイプについて，［必要なNNMiロール］の値を［オペレータレベル1］に変更する。

この手順によって，NNMiレベル1オペレータユーザーグループに割り当てられたユーザーアカウントは，指定されたオブジェクトタイプのステータスのポーリングアクションを表示できるようになります。

NNMiレベル1オペレータのユーザーグループに割り当てられたユーザーアカウントに［設定のポーリング］メニュー項目の表示を許可するようにNNMiを変更するには，次のようにします。

［設定］>［ユーザーインタフェース］>［メニュー項目］>［設定のポーリング］フォームを開く。

［メニュー項目コンテキスト］タブから，変更しなければならない［必要なNNMiロール/オブジェクトのタイプ］項目の各エントリを開く。

レベル1オペレータに設定のポーリングを実行させたい各オブジェクトタイプについて，［必要なNNMiロール］の値を［オペレータレベル1］に変更する。

この手順によって，NNMiレベル1オペレータのユーザーグループに割り当てられたユーザーアカウントは，指定されたオブジェクトタイプの設定のポーリングアクションを表示できるようになります。

次に，nms-topology.propertiesファイルを手順7.から手順10.に示されているように編集して，NNMiレベル1オペレータのユーザーグループに割り当てられたユーザーアカウントが，NNMiコンソールからステータスのポーリングと設定のポーリングの両方のコマンドを実行できるようにします。これらのステップを完了しなかった場合，NNMiはアクションメニューにステータスのポーリングおよび設定のポーリングオプションを表示しますが，ユーザーがステータスのポーリングまたは設定のポーリングコマンドを実行しようとすると，エラーメッセージが表示されます。

ステータスのポーリングと設定のポーリングに必要なアクセスレベル（必要なオブジェクトアクセス権限レベル）を変更するには，次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-topology.properties

Linux：$NNM_PROPS/nms-topology.properties

ファイルの最後までスクロールして，ステータスのポーリング変更のために次の行を追加する。

permission.override.com.hp.nnm.STATUS_POLL=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2,com.hp.nnm.LEVEL1

設定のポーリング変更のために次の行を追加する。

permission.override.com.hp.nnm.CONFIG_POLL=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2,com.hp.nnm.LEVEL1

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

HA下でファイルに変更を加えるときには，クラスタの両方のノードで変更を加える必要があります。HA構成を使用しているNNMiの場合，NNMi管理サーバーの停止と再起動が必要な変更を加えた場合には，ovstopおよびovstartコマンドを実行する前に，ノードをメンテナンスモードにする必要があります。

21.15　プロキシSNMPゲートウェイによって送信されたトラップから元のトラップアドレスを判別する

NNMiのデフォルト設定を使用している場合，プロキシSNMPゲートウェイによって送信されたトラップには元のトラップアドレスが表示されない可能性があります。管理者は，元のトラップアドレスを判別するようにNNMiを設定できます。

次の点に注意してください。

NNMiにはカスタムインシデント属性cia.originaladdressが含まれます。NNMiはcom.hp.nnm.trapd.useUdpHeaderIpAddressプロパティと併せてcia.originaladdress属性の意味を判別します。

com.hp.nnm.trapd.useUdpHeaderIpAddressパラメーターの値はデフォルトでfalseであるため，NNMiは通常cia.originaladdress属性を無視します。

com.hp.nnm.trapd.useUdpHeaderIpAddress値をtrueに設定すると，cia.originaladdress属性によってSNMPエージェントアドレスの値が提供されます。

NNMiでソースとしてUDPヘッダーアドレスを使用する一方で，管理対象デバイスの実際のSNMPアドレスへのアクセスが必要な場合，com.hp.nnm.trapd.useUdpHeaderIpAddress値をtrueに設定すると便利です。

重要

com.hp.nnm.trapd.useUdpHeaderIpAddress属性がfalse（デフォルト設定）の場合，cia.originaladdressとcia.addressの両方の属性には同じ値が含まれます。

cia.originaladdressの値を使用して元のトラップアドレスを判別するようにNNMiを設定するには，次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を含むテキストブロックを探す。

#!com.hp.nnm.trapd.useUdpHeaderIpAddress=false

この行をコメント解除し，次のように編集する。

com.hp.nnm.trapd.useUdpHeaderIpAddress=true

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

NNMiはcia.originaladdressの値を使用して元のトラップアドレスを判別します。

21.15.1　トラップアドレスの順序

NNMiは，ソースアドレスを次のように分析します。

com.hp.nnm.trapd.useUdpHeaderIpAddressプロパティがtrueに設定されたSNMPv1およびSNMPv2cトラップは，次のアドレス順序を使用する。

rfc3584TrapAddress (.1.3.6.1.6.3.18.1.3.0)
nnmTrapForwardingAddress (.1.3.6.1.4.1.11.2.17.2.19.1.1.3.0)
securityPackNotificationAddress (.1.3.6.1.4.1.99.12.45.2.1.0)
proxyOid (.1.3.6.1.4.1.11.2.17.5.1.0)
IPヘッダーのソースアドレス

com.hp.nnm.trapd.useUdpHeaderIpAddressプロパティがfalseに設定されたSNMPv1トラップは，次のアドレス順序を使用する。

rfc3584TrapAddress (.1.3.6.1.6.3.18.1.3.0)
nnmTrapForwardingAddress (.1.3.6.1.4.1.11.2.17.2.19.1.1.3.0)
securityPackNotificationAddress (.1.3.6.1.4.1.99.12.45.2.1.0)
proxyOid (.1.3.6.1.4.1.11.2.17.5.1.0)
v1トラップのagent-addrフィールド
IPヘッダーのソースアドレス

21.16　NNMi NmsTrapReceiverプロセス

NNMiには，フェイルオーバー時にSNMPトラップの損失を最小限に抑えるのに役立つスタンドアロンNmsTrapReceiverプロセスが備えられています。NmsTrapReceiverは，アクティブノードとスタンバイノードの両方で実行されます。

21.16.1　NmsTrapReceiverの設定

NNMiには，ユーザーが構成できる次の設定があります。

trapReceiverJmsTTL

trapReceiverJmsTTLオプションは，TrapReceiverでトラップをキャッシュする最大時間を設定します。デフォルト設定は5分です。jbossのダウン時間がこの時間を超えると，データが失われます。

メモ

この設定を行う前に，フェイルオーバーの所要時間を計ってベンチマークを判断してから，trapReceiverJmsTTLをその時間の2倍に設定します。

このような設定の変更方法については，nnmtrapconfig.ovplのリファレンスページを参照してください。

重要

正しく動作するには，アクティブノードとスタンバイノードの間でクロックが同期されていることが重要です。同期されていないと，トラップの大量の重複または損失が生じる可能性があります。

詳細については，nnmtrapconfig.ovplのリファレンスページを参照してください。

21.16.2　NmsTrapReceiverプロセスの開始と停止

NmsTrapReceiverプロセスは，オペレーティングシステム（Linuxの場合：systemdのnettrap.service，Windowsの場合：HP NNM NmsTrapReceiverサービス）によって自動的に開始されます。また，ovstartで NmsTrapReceiverプロセスが実行されていないことが検出された場合も，ovstartによって開始されます。

NmsTrapReceiverを手動で開始または停止する必要がある場合は，オペレーティングシステムのサービスを使用します。

重要

ovstartおよびovstopコマンドは，リモートトラップサーバーではなく，トラップ処理のjbossパイプラインを開始および停止するだけです。

21.17　NNMiコンソールにHTTPSだけで接続する

NNMiコンソールへのHTTPアクセスを防止する最も効果的な方法は，保護されたシステムへのHTTPSアクセスだけを許可するファイアウォールの後ろにNNMi管理サーバーを配置することです。

HTTPアクセスを防止するファイアウォール設定によって，Webサービスを使用してNNMiと通信し，HTTPだけをサポートする統合で問題が発生することがあります。統合製品のマニュアルを参照し，HTTPSをサポートしているかどうかを確認します。

より安全性に劣る方法では，次の手順によって，HTTPポートからのNNMiコンソールアクセスリクエストをHTTPSポートにリダイレクトします。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-ui.properties

Linux：$NNM_PROPS/nms-ui.properties

文字列httpsを検索し，次の行が含まれるテキストブロックを探す。

#! com.hp.ov.nms.ui.https.only=false

次の行のコメントを解除し，次のように編集する。

com.hp.ov.nms.ui.https.only=true

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

メモ

このプロパティを設定してHTTP要求をNNMiコンソールのHTTPSにリダイレクトすると，NNMiにクロス起動するアプリケーションに問題が発生することがあります。このような問題が発生する場合は，このHTTPSリダイレクトを無効にします。

21.18　リモートアクセスには暗号化を必須とするようにNNMiを設定する

NNMiをインストールしてHTTPS通信を使用するように設定したあとでも，通信のHTTPモードを引き続き使用できます。HTTPを経由したNNMiへのリモートアクセスを制限できるようにするには，次の手順を実行してください。

暗号化リモートアクセスだけを許可するようにNNMiを設定する前に，グローバルネットワーク管理およびそのほかの連携製品がSSLをサポートしていることを確認します。暗号化リモートアクセスだけを許可するようにNNMiを設定する前に，グローバルネットワーク管理およびそのほかの連携製品のSSLを設定してください。

アプリケーションフェイルオーバークラスターを設定したいと検討中で，まだ設定していない場合は，このタスクを実行しないでください。NNMiアプリケーションフェイルオーバークラスターをセットアップしたあと，次の手順を実行して，HTTPおよびその他の非暗号化アクセスを無効にできます。

ネットワークからNNMiへのHTTPアクセスを無効にするには，server.propertiesファイルを次のように編集します。

次のファイルを編集する。ファイルが存在しない場合は作成する。

Windows：%NnmDataDir%nmsas¥NNM¥server.properties

Linux：$NnmDataDir/nmsas/NNM/server.properties

HA 環境の場合，「19.5.1　NNMiの共有ディスク内のデータ」も参照してください。

server.propertiesファイルに次の4行を追加する。

nmsas.server.net.bind.address = 127.0.0.1
nmsas.server.net.bind.address.ssl = 0.0.0.0
nmsas.server.net.hostname = localhost
nmsas.server.net.hostname.ssl = ${com.hp.ov.nms.fqdn}

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.19　以前にサポートされていたvarbind順序を保持するようにNNMiを構成する

すべてのSNMPv2トラップは，最初と2番目のvarbindとしてsysUpTime.0およびsnmpTrapOID.0 OIDを含みます。

重要

SNMPv2トラップ定義がsysUpTime.0またはsnmpTrapOID.0をトラップパラメーターとして含む場合，varbindリストの最初と2番目以外の位置に追加のvarbindとして現れる可能性があります。

NNMi 10-10より前では，NNMiはsysUpTime.0およびsnmpTrapOID.0 OIDのすべてのインスタンスをvarbindリストから削除していました。NNMi 10-10からは，NNMiは，これらのOIDがトラップ定義の一部であるときにこれらのOIDを保持し，受信したトラップのvarbindリストの最初と2番目以外の位置にある可能性があります。この変更によって，sysUpTime.0またはsnmpTrapOID.0 OIDをトラップパラメーターとして持つトラップのvarbind順序が変更されることがあります。

次の例では，1番目のボールドのvarbindにsnmpTrapOID.0の値が含まれ，2番目のボールドのvarbindにsysUpTime.0の値が含まれています。この例に示されているように，これらのvarbindはvarbindリストの1番目と2番目以外の位置に追加varbindとして表示されます。

//0: SNMP MESSAGE (0x30): 115 bytes
//2: INTEGER VERSION (0x2) 1 bytes: 1 (SNMPv2C)
//5: OCTET-STR COMMUNITY (0x4) 6 bytes: "public"
//13: V2-TRAP-PDU (0xa7): 102 bytes
//15: INTEGER REQUEST-ID (0x2) 2 bytes: 18079
//19: INTEGER ERROR-STATUS (0x2) 1 bytes: noError(0)
//22: INTEGER ERROR-INDEX (0x2) 1 bytes: 0
//25: SEQUENCE VARBIND-LIST (0x30): 90 bytes
//27: SEQUENCE VARBIND (0x30): 13 bytes
//29: OBJ-ID (0x6) 8 bytes: .1.3.6.1.2.1.1.3.0
//39: TIMETICKS (0x43) 1 bytes: 9
//42: SEQUENCE VARBIND (0x30): 32 bytes
//44: OBJ-ID (0x6) 10 bytes: .1.3.6.1.6.3.1.1.4.1.0
//56: OBJ-ID (0x6) 18 bytes: .1.3.6.1.6.3.1.1.5.3.1.3.6.1.4.1.9.1.14
//76: SEQUENCE VARBIND (0x30): 14 bytes
//78: OBJ-ID (0x6) 9 bytes: .1.3.6.1.2.1.2.2.1.1
//89: INTEGER (0x2) 1 bytes: 92
//92: SEQUENCE VARBIND (0x30): 23 bytes
//94: OBJ-ID (0x6) 10 bytes: .1.3.6.1.6.3.1.1.4.3.0
//106: OBJ-ID (0x6) 9 bytes: .1.3.6.1.4.1.11.2.3.14

メモ

NNMiでsysUpTime.0 OIDとsnmpTrapOID.0 OIDのすべてのインスタンスをvarbindリストから削除する場合にだけ，com.hp.nnm.events.preserveOldVarbindListOrderプロパティをtrueに設定します。

NNMi 10-10より前と同じ動作にしたい場合は，次のようにします。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を追加する。

com.hp.nnm.events.preserveOldvarbindListOrder=true

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.20　古いSNMPトラップインシデントを自動でトリムする

NNMiのパフォーマンスを高いレベルで維持するために，データベースに一定数のSNMPトラップインシデントが存在すると，それ以上のSNMPトラップ（syslogメッセージを含む）はインシデント化されません。しかし，SNMPトラップインシデントの自動トリム機能を使って，データベースに保存されているSNMPトラップインシデントの数を調整し，受信したSNMPトラップを継続してインシデント化できます。

重要

NNMi 12-00 までは，NNMi は根本原因ではない SNMP トラップインシデントだけをトリムしました。

NNMi 12-10 以降は，「すべてのインシデント」または「 SNMP トラップインシデントだけ」のいずれかを設定できます。デフォルトは「すべてのインシデント」です。

NNMi 12-10 以降，SNMP トラップインシデントの自動トリム機能は新規インストール時に有効化されており，NNMi は古いインシデントをデータベースから削除します。（デフォルトではアーカイブは作成されません。）バージョンアップの場合は以前の設定が引き継がれます。

com.hp.nnm.events.snmpTrapAutoTrimSetting

自動トリム機能の有効化・無効化，トリム対象のSNMPトラップのみ・すべてのインシデントの切り替えなどは以下の具体例を参考に設定してください。

メモ

SNMPトラップインシデントを手動でデータベースから削除する場合は，nnmtrimincidents.ovplコマンドを使用してください。詳細については，nnmtrimincidents.ovplのリファレンスページを参照してください。

21.20.1　インシデントの自動トリムを有効にする（インシデントのアーカイブを作成しない場合）

データベース中のインシデント数（SNMP トラップ以外のすべての種別のインシデント，およびsyslogメッセージを含む）が50,000を超えた場合に，インシデントの自動トリム機能によって，10,000個のインシデントを削除したいとき，次の手順を実行してください。インシデントは古いものから優先的に削除されます。なお，この手順ではインシデントのアーカイブは作成しません。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の文字列を含む行を探す。

com.hp.nnm.events.snmpTrapAutoTrimStartPercentage

コメント記号を削除し，次のように修正する。

com.hp.nnm.events.snmpTrapAutoTrimStartPercentage=50

次の文字列を含む行を探す。

com.hp.nnm.events.snmpTrapAutoTrimPercentageToDelete

コメント記号を削除し，次のように修正する。

com.hp.nnm.events.snmpTrapAutoTrimPercentageToDelete=20

次の文字列を含む行を探す。

com.hp.nnm.events.snmpTrapAutoTrimSetting

コメント記号を削除し，次のように修正する。

com.hp.nnm.events.snmpTrapAutoTrimSetting=TrimOnly

アーカイブが必要な場合は TrimAndArchive を指定します。

次の文字列を含む行を探す。

com.hp.nnm.events.allowAutoTrimAllIncidents

コメント記号を削除し，次のように修正する。

com.hp.nnm.events.allowAutoTrimAllIncidents=true

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

インシデント件数の上限設定であるcom.hp.nnm.events.snmpTrapMaxStoreLimitのデフォルト値は100,000 です。この場合，データベース中のインシデント数が上限の50%である50,000 を超えた場合に，次の式によって10,000 個のインシデントが古いものから削除されます。

(com.hp.nnm.events.snmpTrapAutoTrimStartPercentage / 100) X com.hp.nnm.events.snmpTrapMaxStoreLimit X (com.hp.nnm.events.snmpTrapAutoTrimPercentageToDelete / 100)
※「X」は乗算記号です。

21.20.2　SNMPトラップインシデントの自動トリムを有効にする（インシデントのアーカイブを作成する場合）

データベース中のSNMPトラップインシデント数（syslogメッセージを含む）が50,000を超えた場合に，SNMPトラップインシデントの自動トリム機能によって，10,000個のSNMPトラップインシデントを削除したいときには，次の手順を実行してください。SNMPトラップインシデントは古いものから優先的に削除されます。なお，この手順ではインシデントのアーカイブを作成します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の文字列を含む行を探す。

com.hp.nnm.events.snmpTrapAutoTrimStartPercentage

コメント記号を削除し，次のように修正する。

com.hp.nnm.events.snmpTrapAutoTrimStartPercentage=50

次の文字列を含む行を探す。

com.hp.nnm.events.snmpTrapAutoTrimPercentageToDelete

コメント記号を削除し，次のように修正する。

com.hp.nnm.events.snmpTrapAutoTrimPercentageToDelete=20

次の文字列を含む行を探す。

com.hp.nnm.events.snmpTrapAutoTrimSetting

コメント記号を削除し，次のように修正する。

com.hp.nnm.events.snmpTrapAutoTrimSetting=TrimAndArchive

アーカイブが不要な場合は TrimOnly を指定します。

次の文字列を含む行を探す。

com.hp.nnm.events.allowAutoTrimAllIncidents

コメント記号を先頭につける。またはコメント記号を削除し，次のように修正する。

com.hp.nnm.events.allowAutoTrimAllIncidents=false

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

インシデント件数の上限設定であるcom.hp.nnm.events.snmpTrapMaxStoreLimit のデフォルト値は100,000 です。この場合，データベース中のSNMP トラップインシデント数（syslog メッセージを含む）が上限の50%である50,000 を超えた場合に，次の式によって10,000 個のSNMP トラップインシデントが古いものから削除されます。

(com.hp.nnm.events.snmpTrapAutoTrimStartPercentage / 100) X com.hp.nnm.events.snmpTrapMaxStoreLimit X (com.hp.nnm.events.snmpTrapAutoTrimPercentageToDelete / 100)
※「X」は乗算記号です。

削除したインシデントは次のファイルにアーカイブされます。

Windows：%NNM_TMP%¥incidentArchive."<日付>".csv.gz

Linux：$NNM_TMP/incidentArchive."<日付>".csv.gz

NNMiサービスを再起動するまではアーカイブファイル名は固定であり，同じファイルに追記されます。

21.20.3　アーカイブファイルのローテーション

デフォルト設定では，自動トリム機能によって作成されるアーカイブファイルのファイルサイズに上限はありません。アーカイブファイルは，特定のファイルサイズでローテーションしてディスク使用量を節約できます。サイズが10MBに到達したときに，アーカイブファイルを3回ローテーションするとします。次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を含むテキストブロックを探す。

#!com.hp.nnm.events.autoTrimArchiveRotationEnabled=false

この行のコメントを解除し，次のように編集する。

com.hp.nnm.events.autoTrimArchiveRotationEnabled=true

次の行を含むテキストブロックを探す。

#!com.hp.nnm.events.autoTrimArchiveRotationArchiveSize=128

この行のコメントを解除し，次のように編集する。

com.hp.nnm.events.autoTrimArchiveRotationArchiveSize=10

次の行を含むテキストブロックを探す。

#!com.hp.nnm.events.autoTrimArchiveRotationRotateNumber=5

この行のコメントを解除し，次のように編集する。

com.hp.nnm.events.autoTrimArchiveRotationRotateNumber=3

NNMi管理サーバーを再起動する。

NNMi管理サーバーでovstopコマンドを実行する。

NNMi管理サーバーでovstartコマンドを実行する。

重要

高可用性（HA）でファイルの変更を行う場合は，クラスターの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，NNMi管理サーバーを停止および再起動する必要のある変更の場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。

この設定では，トリムされたインシデントは以下のファイルにアーカイブされます。ファイル名にタイムスタンプは含まれないことに注意してください。

Windows：%NNM_TMP¥incidentArchive.csv.gz

Linux：$NNM_TMP/incidentArchive.csv.gz

アーカイブファイルのファイルサイズが指定した値 （この例では10，単位MB）に到達すると，アーカイブファイルの名前が「incidentArchive.csv.gz.1」に変更されます。新しいインシデントは，新しいincidentArchive.csv.gzにアーカイブされます。「incidentArchive.csv.gz.<n>」は，ローテーションによって「incidentArchive.csv.gz.<n+1>」に名前が変更されます。アーカイブファイル名の<n>が指定した値（この例では3）になると，ローテーションによって名前が変更される代わりにファイルが削除されます。

21.20.4　保存されるSNMPトラップインシデント数の最大値を変更する

SNMPトラップインシデントを長期間保存する必要がある場合や，長期間保存する必要がない場合に対応するために，データベースに保存されるSNMPトラップインシデント数の最大値を変更できます。

重要

デフォルトではデータベース中のSNMPトラップインシデント数（syslogメッセージを含む）が100,000を超えると，それ以上のSNMPトラップ（syslogメッセージを含む）はインシデント化されません。最大値を100,000以上に変更することはパフォーマンス上の問題を引き起こすおそれがあるため，推奨されません。変更する場合は，十分に評価してご使用ください。

(1)　最大値を100,000未満に変更する場合

ここでは50,000に変更します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を探す。

#!com.hp.nnm.events.snmpTrapMaxStoreLimit=100000

コメント記号を削除し，次のように修正する。

com.hp.nnm.events.snmpTrapMaxStoreLimit=50000

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

(2)　最大値を100,000以上に変更する場合

ここでは200,000に変更します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を探す。

#!com.hp.nnm.events.snmpTrapEnforce100KLimit=true

コメント記号を削除し，次のように修正し，ファイルを保存する。

com.hp.nnm.events.snmpTrapEnforce100KLimit=false

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を探す。

#!com.hp.nnm.events.snmpTrapMaxStoreLimit=100000

コメント記号を削除し，次のように修正する。

com.hp.nnm.events.snmpTrapMaxStoreLimit=200000

変更を保存する。

次のコマンドを実行してNNMiを再起動する。

ovstop
ovstart

21.20.5　SNMPトラップインシデントの自動トリムの状態を監視する

SNMPトラップインシデントの自動トリム機能の状態をチェックするためには，NNMi コンソールの［ヘルプ］＞［システム情報］＞［ヘルス］にSNMPトラップ数に関するメッセージが表示されていないかを確認します。また，SNMPトラップインシデントの自動トリム機能に関連して，NNMiは次のインシデントを登録します。

データベースに保存されたSNMPトラップインシデント（syslogメッセージを含む）がcom.hp.nnm.events.snmpTrapMaxStoreLimitの値の100%に到達した場合，NNMiはSnmpTrapLimitCriticalを登録します。

データベースに保存されたSNMPトラップインシデント（syslogメッセージを含む）がcom.hp.nnm.events.snmpTrapMaxStoreLimitの値の95%に到達した場合，NNMiはSnmpTrapLimitMajorを登録します。

データベースに保存されたSNMPトラップインシデント（syslogメッセージを含む）がcom.hp.nnm.events.snmpTrapMaxStoreLimitの値の90%に到達した場合，NNMiはSnmpTrapLimitWarningを登録します。

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

21.20.6　SNMPトラップインシデントの自動トリムを無効にする

SNMPトラップインシデントの自動トリムを無効にするには，次の手順を実行します。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次のプロパティを含む行を探す。

com.hp.nnm.events.snmpTrapAutoTrimSetting

次のように修正する。

com.hp.nnm.events.snmpTrapAutoTrimSetting=Disabled

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.21　NNMi正規化プロパティを変更する

NNMiでは，ホスト名とノード名の両方が大文字と小文字を区別して保存されます。NNMiコンソールのすべての検索，ソート，およびフィルタの結果も大文字と小文字を区別して返されます。使用するDNSサーバーが，すべて大文字，すべて小文字，大文字と小文字の混合などのように大文字と小文字を区別してさまざまなノード名とホスト名を返す場合，最良の結果が得られない場合があります。

ユーザーの特定のニーズに合うように，NNMiの正規化プロパティを変更できます。NNMiの初期検出シードを行う前に，これらの変更を行うことを推奨します。

導入中の初期検出を実行する前に，このセクションの設定を調整することを推奨します。

初期検出を実行してから正規化プロパティの変更を行う場合は，完全な検出を開始するnnmnoderediscover.ovpl -allスクリプトを実行できます。詳細については，nnmnoderediscover.ovplのリファレンスページを参照してください。

次のプロパティを変更できます。

検出されるノード名を，UPPERCASE，LOWERCASE，またはOFFに正規化します。

検出されるホスト名をUPPERCASE，LOWERCASE，またはOFFに正規化します。

正規化プロパティを変更するには，次の手順に従います。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-topology.properties

Linux：$NNM_PROPS/nms-topology.properties

検出される名称を正規化するようにNNMiを設定するには，次のような行を探す。

#!com.hp.ov.nms.topo.NAME_NORMALIZATION=OFF

a　プロパティのコメントを解除します。

com.hp.ov.nms.topo.NAME_NORMALIZATION=OFF

プロパティのコメントを解除するには，行の先頭から#!文字を削除します。

b　OFFをLOWERCASEまたはUPPERCASEに変更します。

c　変更を保存します。

検出されるホスト名を正規化するようにNNMiを設定するには，次のような行を探す。

#!com.hp.ov.nms.topo.HOSTNAME_NORMALIZATION=OFF

a　プロパティのコメントを解除します。

com.hp.ov.nms.topo.HOSTNAME_NORMALIZATION=OFF

プロパティのコメントを解除するには，行の先頭から#!文字を削除します。

b　OFFをLOWERCASEまたはUPPERCASEに変更します。

c　変更を保存します。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.21.1　初期検出後の正規化プロパティ変更時の注意事項

初期検出を実行したあとに正規化プロパティを変更すると，NNMiは，次回検出までプロパティ変更との食い違いが続きます。これを解消するには，NNMi正規化プロパティを変更した後に，nnmnoderediscover.ovpl -allスクリプトを実行して完全検出を開始します。

21.22　データベースポートを変更する

データベースに異なるポートを使用するようにNNMiを設定するには，次の手順を実行します。

環境に応じて次のファイルを編集する。

Windows：%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：$NNM_CONF/nnm/props/nms-local.properties

次のような行を探す。

#!com.hp.ov.nms.postgres.port=5432

プロパティのコメントを解除する。

com.hp.ov.nms.postgres.port=5432

プロパティのコメントを解除するには，行の先頭から#!文字を削除します。

既存の値を新しいポート番号に変更する。

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.23　NNMi自己監視

21.23.1　NNMiのステータスメッセージを無効にするための設定

NNMiでは，メモリ，CPU，ディスクリソースなどの自己監視チェックが実行されます。NNMi管理サーバーのリソースが少なくなる，または重大な状態が検出されると，NNMiによってインシデントが生成されます。

NNMiの稼働状態情報を表示するには，次のどれかの方法を使用します。

NNMiコンソールで，［ヘルプ］＞［システム情報］をクリックしてから，［ヘルス］タブをクリックします。

nnmhealth.ovplスクリプトを実行します。

NNMiが自己監視稼働状態の例外を検出すると，NNMiコンソールの下部とフォームの上部にステータスメッセージが表示されます。次の手順を実行すると，この警告メッセージを無効にできます。

次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-ui.properties

Linux：$NNM_PROPS/nms-ui.properties

次の行を含むテキストブロックを探す。

#!com.hp.nms.ui.health.disablewarning=false

次の行のコメントを解除し，次のように編集する。

com.hp.nms.ui.health.disablewarning=true

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.23.2　ヘルスインシデントを抑制するための設定

NNMi管理サーバーが自己監視の異常な結果を検出すると，NNMiによってインシデントが生成されます。特定の結果のヘルスインシデントを抑制するには，次のコマンドを実行します。<conclusions>は，カンマで区切られた結果名のリストです。

Windowsの場合：

%InstallDir%¥bin¥nnmhealth.ovpl -suppress <conclusions>

Linuxの場合：

$InstallDir/bin/nnmhealth.ovpl -suppress <conclusions>

nnmhealth.ovplによる変更は，管理者がNNMiを再起動するまで続きます。NNMiの再起動後も設定を維持する場合は，次の手順を実行します。

次のファイルを開く。

Windows：%NNM_PROPS¥nms-topology.properties

Linux：$NNM_PROPS/nms-topology.properties

次の行を含むテキストブロックを探す。

#!com.hp.ov.nms.health.SUPPRESSED_CONCLUSIONS=

次の行のコメントを解除し，次のように編集する。

com.hp.ov.nms.health.SUPPRESSED_CONCLUSIONS=<conclusions>

<conclusions>は，カンマで区切られた結果名のリストです。

変更を保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

結果の名前を確認する方法の詳細については，nnmhealth.ovplのリファレンスページを参照してください。

重要

高可用性（HA）でファイルの変更を行う場合は，クラスターの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，NNMi管理サーバーを停止および再起動する必要のある変更の場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。

21.24　特定ノードに対して検出プロトコルを使用しないように設定する

NNMiでは複数のプロトコルを使用し，ネットワークデバイス間のレイヤー2接続を検出しています。定義されている検出プロトコルは多数あります。例えばLink Layer Discovery Protocol（LLDP）は標準プロトコルですが，Ciscoデバイス用のCisco Discovery Protocol（CDP）のように，ベンダー固有のプロトコルも多数あります。

指定したデバイスの検出プロトコルを使用しないようにNNMiを設定できます。検出プロトコルを使用しないようにすることで解決できる例を次に示します。

Enterasysデバイス：

SNMPを使用してEnterasys Discovery Protocol（EnDP）およびLLDPのテーブルから一部のEnterasysデバイスに関する情報を収集すると，NNMiでメモリが不足するという問題が発生することがあります。この場合，EnterasysデバイスでEnDPおよびLLDPの処理をスキップするようにNNMiを設定すると，この問題を防止できます。これを実行するには，デバイスの管理アドレスをdisco.SkipXdpProcessingファイルに追加します。詳細については，「21.24.1　検出プロトコルを使用しないように設定する」を参照してください。

一部のEnterasysデバイスの新バージョンのオペレーティングシステムでは，set snmp timefilter breakコマンドがサポートされています。このようなEnterasysデバイスでは，set snmp timefilter breakコマンドを実行します。このコマンドを使用してデバイスを設定した場合，このデバイスをdisco.SkipXdpProcessingファイルに追加する必要はありません。

Nortelデバイス：

多くのNortelデバイスではSynOptics Network Management Protocol（SONMP）を使用し，レイヤー2レイアウトおよび接続を検出します。一部のデバイスでは複数のインタフェースで同一MACアドレスを使用するため，このプロトコルで適切に動作しません。相互接続した2つのNortelデバイスがインタフェースの誤ったセット間でレイヤー2接続を示し，接続が接続ソースSONMPを示す場合，この問題が発生することがあります。

この例では，SONMPプロトコルを使用しないようにNNMiを設定し，デバイスのレイヤー2接続を引き出して，誤った接続に関与しているとして表示しないことを推奨します。これを実行するには，2つのデバイスの管理アドレスをdisco.SkipXdpProcessingファイルに追加します。詳細については，「21.24.1　検出プロトコルを使用しないように設定する」を参照してください。

21.24.1　検出プロトコルを使用しないように設定する

検出プロトコルを使用しないように設定する必要がある場合は，次の手順を実行します。

次のファイルを作成する。

Windows：%NnmDataDir%shared¥nnm¥conf¥disco¥disco.SkipXdpProcessing

Linux：$NnmDataDir/shared/nnm/conf/disco/disco.SkipXdpProcessing

disco.SkipXdpProcessingファイルでは，大文字と小文字が区別されます。

検出プロトコルを使用しないように設定するすべてのデバイスについて，デバイスの管理アドレスをdisco.SkipXdpProcessingファイルに追加する。

詳細については，disco.SkipXdpProcessingのリファレンスページを参照してください。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

重要

1つまたは複数のノードの検出プロトコルを使用しないように設定すると，管理対象ネットワークのレイヤー2レイアウトの精度が多少落ちることがあります。

ovjbossサービスは起動時にdisco.SkipXdpProcessingファイルを読み込みます。NNMi管理サーバーの起動後に変更をした場合は，この手順で示すようにNNMi管理サーバーを再起動してください。

Enterasysデバイスでset snmp timefilter breakコマンドを実行した場合は，デバイスの管理アドレスをdisco.SkipXdpProcessingファイルから削除し，この手順で示すようにNNMi管理サーバーを再起動します。NNMiは，検出プロトコルを使用したとき，より正確なレイヤー2マップを表示します。

詳細については，disco.SkipXdpProcessingのリファレンスページを参照してください。

21.25　二次的な根本原因管理イベントにアクションを設定する

NNMiはデフォルトでは二次的な根本原因管理イベントに対してアクションを実行しません。

このことは不要なアクションの生成を抑止することに役立っています。例えば，NNMiがInterfaceDownインシデントを検知し，その直後に対応するカードがダウンしたと判別したら，ダンプニングが使用されている場合，CardDownインシデントが根本原因となり，InterfaceDownインシデントは二次的な根本原因インシデントとなります。

この場合，アクションは新しい根本原因（CardDown）に対して適用されるため，InterfaceDownインシデントに対しては要求されません。

二次的な根本原因管理イベントに対するアクションを有効化するには，次の手順を実行します。

環境に応じて次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-jboss.properties

Linux：$NNM_PROPS/nms-jboss.properties

次の行を含むテキストブロックを探す。

#!com.hp.nnm.events.action.runActionOnSecRootCauseMgmtEvent=false

この行のコメントを解除し，次のように編集する。

com.hp.nnm.events.action.runActionOnSecRootCauseMgmtEvent=true

nms-jboss.propertiesファイルを保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

21.26　計画停止

NNMiでは，nnmscheduledoutage.ovplコマンドを使用して任意のノードセットの停止をスケジュールできます。例えば，ルーターセットの毎週のメンテナンスで停止をスケジュールしたり，特定のノードの電源を交換したりできます。

詳細については，nnmscheduledoutage.ovplのリファレンスページを参照してください。

メモ

NNMiを使用した停止のスケジュールの詳細については，NNMiヘルプを参照してください。

21.27　センサーステータスの設定

NNMiには，ステータス判別用に監視できる次の物理センサーとノードセンサーが含まれています。

表21‒2　物理センサーとノードセンサー

物理センサー

デフォルトで物理コンポーネントにステータスを伝達

ノードセンサー

デフォルトでノードにステータスを伝達

FAN

はい

CPU

いいえ

POWER_SUPPLY

はい

MEMORY

はい

TEMPERATURE

いいえ

BUFFERS

いいえ

VOLTAGE

いいえ

DISK_SPACE

いいえ

BACK_PLANE

はい

重要

デフォルトでは，FAN，POWER_SUPPLY，BACK_PLANE，およびMEMORYがステータスを物理コンポーネントレベルに伝達します。例えば，ファンが赤色のステータスインジケーターを示している場合，対応する物理コンポーネント（シャーシ）は黄色のステータスインジケーターを受け取ります。この場合，シャーシのステータスを表示しているユーザーには，そのシャーシのコンポーネントに何らかの障害があることが警告されます。

21.27.1　物理センサーステータスの設定

次のセクションの手順を実行して，物理センサーでステータスを物理コンポーネント（シャーシなど）レベルに伝達するかどうかを設定できます。

(1)　物理コンポーネントへの物理センサーステータスの伝達

次のディレクトリにnnm-apa.propertiesという名前の新しいプロパティファイルを作成する（このファイルが存在しない場合）。

Windows：%NnmDataDir%shared¥nnm¥conf¥props

Linux：$NnmDataDir/shared/nnm/conf/props

テキストエディタを使用して，プロパティファイル内に次のテキストを挿入する。

com.hp.ov.nms.apa.PhysSensorPropagateToPhysicalComponentStatus_<タイプ>=true

<タイプ>は物理センサーです。詳細については，「21.27　センサーステータスの設定」を参照してください。

プロパティファイルを保存する。

次のコマンドを実行してNNMiを再起動する。

ovstop
ovstart

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

(2)　物理コンポーネントに伝達しない物理センサーステータスの設定

次のディレクトリにnnm-apa.propertiesという名前の新しいプロパティファイルを作成する（このファイルが存在しない場合）。

Windowsの場合：%NnmDataDir%shared¥nnm¥conf¥props

Linuxの場合：$NnmDataDir/shared/nnm/conf/props

テキストエディタを使用して，プロパティファイル内に次のテキストを挿入する。

com.hp.ov.nms.apa.PhysSensorNoPropagateToPhysicalComponentStatus_<タイプ>=true

<タイプ>は物理センサーです。詳細については，「21.27　センサーステータスの設定」を参照してください。

プロパティファイルを保存する。

次のコマンドを実行してNNMiを再起動する。

ovstop
ovstart

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

(3)　物理センサーステータス値の上書き

デフォルトでは，3つのセンサーのステータス値（［なし］，［注意域］，および［利用不可］）は，Causal Engineによって［正常域］ステータスにマッピングされます。デフォルトのステータスマッピングは，［なし］，［注意域］，［利用不可］を［危険域］にマッピングするように上書きできます。

物理センサーのステータス値を上書きするには，次の手順を実行します。

次のディレクトリにnnm-apa.propertiesという名前の新しいプロパティファイルを作成する（このファイルが存在しない場合）。

Windowsの場合：%NnmDataDir%shared¥nnm¥conf¥props

Linuxの場合：$NnmDataDir/shared/nnm/conf/props

テキストエディタを使用して，プロパティファイル内に必要に応じて次の行の1つ，2つ，または3つすべてを挿入する。

com.hp.ov.nms.apa.PhysSensorValueReMappedToDown_NONE=true
com.hp.ov.nms.apa.PhysSensorValueReMappedToDown_Warning=true
com.hp.ov.nms.apa.PhysSensorValueReMappedToDown_Unavailable=true

プロパティファイルを保存する。

次のコマンドを実行してNNMiを再起動する。

ovstop
ovstart

重要

［利用不可］の状態を［未ポーリング］状態にマッピングできます（［利用不可］は測定機能が利用できないことを指すため）。この状態は，多くの場合コンポーネントの機能不全ではなくセンサーの機能不全で発生します。［利用不可］を［未ポーリング］にマッピングするには，手順2で次のテキストを使用する以外は上記と同じ手順を実行します。

com.hp.ov.nms.apa.PhysicalSensorValueReMappedToUnpolled_Unavailable= true

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

21.27.2　ノードセンサーステータスの設定

次のセクションの手順を実行して，ノードセンサーでステータスをノードレベルに伝達するかどうかを設定できます。

(1)　ノードへのノードセンサーステータスの伝達

次のディレクトリにnnm-apa.propertiesという名前の新しいプロパティファイルを作成する（このファイルが存在しない場合）。

Windowsの場合：%NnmDataDir%shared¥nnm¥conf¥props

Linuxの場合：$NnmDataDir/shared/nnm/conf/props

テキストエディタを使用して，プロパティファイル内に次のテキストを挿入する。

com.hp.ov.nms.apa.NodeSensorPropagateToNodeStatus_<タイプ>=true

<タイプ>は物理センサーです。詳細については，「21.27　センサーステータスの設定」を参照してください。

プロパティファイルを保存する。

次のコマンドを実行してNNMiを再起動する。

ovstop
ovstart

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

(2)　ステータスをノードに伝達しないようにするためのノードセンサーの設定

次のディレクトリにnnm-apa.propertiesという名前の新しいプロパティファイルを作成する（このファイルが存在しない場合）。

Windowsの場合：%NnmDataDir%shared¥nnm¥conf¥props

Linuxの場合：$NnmDataDir/shared/nnm/conf/props

テキストエディタを使用して，プロパティファイル内に次のテキストを挿入する。

com.hp.ov.nms.apa.NodeSensorNoPropagateToNodeStatus_<タイプ>=true

<タイプ>は物理センサーです。詳細については，「21.27　センサーステータスの設定」を参照してください。

プロパティファイルを保存する。

次のコマンドを実行してNNMiを再起動する。

ovstop
ovstart

重要

高可用性（HA）でファイルを変更する場合は，クラスタの両方のノードに変更を加える必要があります。HA設定を使用するNNMiでは，変更でNNMi管理サーバーの停止と再起動が必要な場合，ovstopおよびovstartコマンドを実行する前にノードをメンテナンスモードにする必要があります。詳細については，「19.6.1　NNMiをメンテナンスモードにする」を参照してください。

21.28　Destination Unreachable を受信した場合でも，リトライ処理を継続するように設定する

NNMiはデフォルトの設定の場合，監視ノードに対してステータスポーリングを実行した際にICMPのDestination Unreachableを受信した場合，通信不可と判断し，ICMPのリトライ処理を行いません。

Destination Unreachableを受信してもリトライ処理を継続する場合は，次の手順を実行します。

環境に応じて次のファイルを編集する。

Windows：%NNM_PROPS%¥nms-communication.properties

Linux：$NNM_PROPS/nms-communication.properties

次のような行を探す。

#!com.hp.ov.icmp.allowRetryIcmpIfDestinationUnreachable=false

プロパティのコメントを解除し，次のように編集する。

com.hp.ov.icmp.allowRetryIcmpIfDestinationUnreachable=true

nms-communication.propertiesファイルを保存する。

次のコマンドを実行して，NNMiを再起動する。

ovstop
ovstart

22　NNMi管理サーバーの変更

ほかのシステムでNNMi設定を複製できます。例えば，テスト環境から運用環境に移動したり，NNMi管理サーバーのハードウェアを変更したりできます。NNMi設定に影響を及ぼさないで，NNMi管理サーバーのIPアドレスを変更できます。

22.1　NNMi設定移動の準備のベストプラクティス

次のベストプラクティスは，NNMiの設定を異なるシステムへ移動するときに有効です。

ノードグループ設定で，管理対象ノードの識別にホスト名を使っている場合，運用環境およびテスト環境のNNMi管理サーバーは同じDNSサーバーを使う必要があります。運用環境とテスト環境で異なるDNSサーバーを使っている場合，管理対象ノードの解決済みの名前が変更されると，2つのNNMi管理サーバーの間でポーリング設定に差異が生じる場合があります。

設定の作成者を限定して，エクスポートできます。自分のグループまたは会社で一意の新しい［作成者］を作成します。次の項目を作成または変更するときは，この作成者の値を指定します。

−デバイスのプロファイル

−インシデントの設定

−メニュー

−メニュー項目

−カスタム相関処理の設定

−アイコン

−MIB式

−トラップログ記録設定

22.2　NNMi設定およびデータベースを移動する

NNMiの設定とデータベースを，例えばテストシステムから本番システムなどへ移動するには，ソース（テスト）システム上のすべてのNNMiデータをバックアップしてから，バックアップをターゲット（本稼働）システムにリストアします。バックアップの実行後NNMiデータベースが変更されないようにするため，すべてのNNMiプロセスを停止し，オフラインバックアップを作成してください。

（例）

nnmbackup.ovpl -type offline -scope all -target nnmi_backups¥offline

「20.3.2　異なるシステムでのリストア」にリストされた項目が両方のシステムで同じであることを確認してから，次の例のようなコマンドを実行します。

（例）

nnmrestore.ovpl -source nnmi_backups¥offline¥newest_backup

重要

NNMiは同じSSL証明書を使用して，データベースへのアクセスおよびNNMiコンソールへのHTTPSアクセスをサポートします。データベースへアクセスするための証明書は，ソースシステム上でNNMiプロセスを最初に開始したときに作成されました。この証明書はバックアップおよびリストアデータに含まれています。この証明書がないと，NNMiはターゲットシステムからデータベースにアクセスできません。

ただし，NNMiコンソールへのHTTPSアクセスの場合は，SSL証明書をターゲットシステムに生成する必要があります。JBossの現在の実装が証明書のマージをサポートしていないため，NNMiは別のシステムからのデータをリストアして設定されたシステム上でのNNMiコンソールへのHTTPSアクセスはサポートしていません。ターゲットシステムがNNMiコンソールへのHTTPSアクセスをサポートする必要がある場合は，「22.3　NNMi設定を移動する」の手順を実行してから，ターゲットシステム上で新たにデータ収集を開始します。

22.3　NNMi設定を移動する

nnmconfigexport.ovplコマンドを使用して，NNMi設定をXMLファイルに出力します。次に，nnmconfigimport.ovplコマンドを使って，XMLファイルから新しいシステムのNNMiにこの設定をインポートします。

重要

nnmconfigimport.ovplスクリプトを使用してファイルをインポートする前に，nnmconfigexport.ovplスクリプトでエクスポートしたファイルを編集しないでください。

これらのコマンドの詳細については，該当するリファレンスページを参照してください。

メモ

nnmconfigexport.ovplコマンドではSNMPv3資格情報は保持されません。詳細については，nnmconfigexport.ovplのリファレンスページを参照してください。

NNMi設定だけを移動できます。あるNNMi管理サーバーから異なるNNMi管理サーバーへのトポロジまたはインシデントデータの移動をサポートしません。

22.4　スタンドアロンのNNMi管理サーバーのIPアドレスを変更する

NNMi管理サーバーのIPアドレスを変更する必要がある場合は，NNMiを停止してから実施してください。アドレス変更後には，変更前のアドレスに対応するライセンスキーを削除し，変更後のアドレスに対応するライセンスキーを適用してから，NNMiを起動してください。

22.5　NNMi管理サーバーのホスト名またはドメイン名を変更する

重要

NNMi管理サーバーがNNMiアプリケーションフェイルオーバーを構成している，グローバルネットワーク管理を構成している，または高可用性（HA）クラスタのメンバーの場合は，サポートサービスに問い合わせてください。

NNMi管理サーバーをディレクトリサービスとSSLで接続するよう設定している場合は，ディレクトリサーバーの証明書をトラストストアーに追加し直す必要があります。この節の手順を実行したあと，「10.3.8　ディレクトリサービスへのSSL接続を設定する」の手順を実施してください。

NNMi管理サーバーのホスト名，ドメイン名，またはその両方を変更するには，NNMi管理サーバーの新しい完全修飾ドメイン名（FQDN）を使用するようにNNMiを設定します。

（例）

nnmsetofficialfqdn.ovpl -force newnnmi.servers.example.com

nnmsetofficialfqdn.ovpl実行後，設定を反映するためにNNMiを再起動してください。

詳細については，nnmsetofficialfqdn.ovplのリファレンスページを参照してください。

重要

FQDNは，ドメイン名と組み合わされたホスト名です。このどちらかを変更すると，NNMi管理サーバーのFQDNを変更することになります。SSL証明書は，常にFQDNにリンクされます。証明書の共通名（CN）フィールドは，サーバーのFQDNと一致する必要があります。このため，FQDNを変更する場合は，一致するCNを持つ新しいSSL証明書が必要になります。nnmsetofficialfqdn.ovplコマンドは，NNMi管理サーバーのFQDNを更新し，新しいFQDNと一致する新しい自己署名証明書も作成します。ただし，CA証明書を使用している場合は，新しいCA証明書を生成する必要があります。詳細については，「10.3.2　CA 署名証明書の生成」を参照してください。

FQDNを変更したかどうかに関係なく，NNMi管理サーバーのIPアドレスを変更する場合は，新しいライセンスを取得する必要があります。詳細については，「22.4　スタンドアロンのNNMi管理サーバーのIPアドレスを変更する」を参照してください。

23　NNMiセキュリティ

セキュリティについて説明します。

23.1　組み込みデータベースツールのパスワードを入力する

NNMiで組み込みデータベースツール（psqlなど）を実行するには，パスワードを入力する必要があります。NNMiによってデフォルトのパスワードが設定されており，ユーザーはnnmchangeembdbpw.ovplスクリプトを使用してこのパスワードを変更する必要があります。nnmchangeembdbpw.ovplスクリプトを実行するには，Windowsシステムの場合は管理者，Linuxシステムの場合はルートとしてログインする必要があります。詳細については，nnmchangeembdbpw.ovplリファレンスページを参照してください。

HA環境では，プライマリクラスタノードでだけ，nnmchangeembdbpw.ovplスクリプトを実行します。アプリケーションによって自動的にセカンダリクラスタノードにパスワードがコピーされるため，その後のユーザーの操作は必要ありません。

23.2　TLSプロトコルの設定

NNMiはデフォルトでは，HTTPS通信に対してTLSv1.2およびTLSv1.3プロトコルをサポートしています。

従来のクライアントをサポートするために，以前の安全性の低いプロトコルが必要な場合を除き，NNMiではTLSv1.2以降のみを使用することをお勧めします。

使用するプロトコルバージョンを変更するには，次の手順に従います。

NNMi管理サーバーにログオンします。

テキストエディタで次のファイルを開きます。

Windowsの場合：%NnmDataDir%nmsas¥NNM¥server.properties

Linuxの場合：/var/opt/OV/nmsas/NNM/server.properties

HA 環境の場合，「19.5.1　NNMiの共有ディスク内のデータ」も参照してください。

使用するプロトコルのカンマ区切りリストを使用して，com.hp.ov.nms.ssl.PROTOCOLSプロパティを追加，または更新します。

例えば，TLSv1，TLSv1.1，TLSv1.2，およびTLSv1.3プロトコルを使用する場合は，次のような設定行がserver.propertiesファイルに存在するようにします。

com.hp.ov.nms.ssl.PROTOCOLS=TLSv1.3,TLSv1.2,TLSv1.1,TLSv1

次のコマンドを実行して，NNMiプロセスを再起動します。

Windowsの場合：

%NnmInstallDir%bin¥ovstop -c
%NnmInstallDir%bin¥ovstart -c

Linuxの場合：

/opt/OV/bin/ovstop -c
/opt/OV/bin/ovstart -c

第7編　移行編

24　バージョン9・10・11・12のNNMiからの移行

この章では，幾つかの想定されるバージョンアップの例について説明します。NNMiアプリケーションフェイルオーバー設定で実行しているバージョン9，バージョン10，バージョン11，バージョン12のNNMi管理サーバーをバージョンアップする場合，一時的なアプリケーションフェイルオーバーの設定解除，NNMi管理サーバーのバージョンアップ，アプリケーションフェイルオーバーの再設定という順番のアップグレードパスがサポートされています。高可用性クラスタ（HA）で実行しているバージョン9，バージョン10，バージョン11，バージョン12のNNMiをバージョンアップする場合は，リリースノートを参照してください。

24.1　NNMi管理サーバーをバージョンアップする

24.1.1　バージョン13-10のNNMi管理サーバーをバージョンアップする

ここでは，バージョン13-10で実行中のNNMi管理サーバーをバージョンアップする手順を次に示します。

メモ

NNMi管理サーバーをバージョンアップする前に，「1.　インストール前チェックリスト」を参照してください。

nnmbackup.ovplスクリプトを使用して，NNMi管理サーバーをバックアップする。

このバックアップを使用するのは移行が失敗した場合だけです。詳細については，nnmbackup.ovplのリファレンスページを参照してください。

「2.　NNMiのインストールとアンインストール」の手順に従って，NNMi 13-50のNNMi管理サーバーにインストールする。

NNMi管理サーバーの情報が正しく移行されたことを確認する。

24.1.2　バージョン9・10・11・12のNNMi管理サーバーをバージョンアップする

ここでは，バージョン9，バージョン10，バージョン11，バージョン12で実行中のNNMi管理サーバーをバージョンアップする手順を次に示します。

NNMi 13-10のセットアップガイド※，およびリリースノートの手順に従って，実行中のNNMi管理サーバーをバージョン13-10のNNMi管理サーバーにバージョンアップする。

注※　セットアップガイドとは，次のマニュアルを指します。

JP1/Network Node Manager iセットアップガイド（3021-3-L32）

「24.1.1　バージョン13-10のNNMi管理サーバーをバージョンアップする」を参照して，バージョン13-10で実行中のNNMi管理サーバーをバージョンアップする。

24.2　別のNNMi管理サーバーにバージョンアップする

ここでは，既存（以降，ソースといいます）のNNMi管理サーバーの設定を維持しながら，新規システム上でNNMi 13-50にバージョンアップする手順について説明します。

メモ

NNMi管理サーバーをバージョンアップする前に，「1.　インストール前チェックリスト」を参照してください。

次の手順は，ソースのNNMi管理サーバーからターゲットのNNMi管理サーバーにデータをコピーする方法を説明したものです。この手順は，NNMi 13-10がソースのNNMi管理サーバーで実行されていることを前提としています。

nnmbackup.ovplスクリプトを使用して，ソースのNNMi管理サーバーをバックアップする。バックアップファイルにラベルを付ける。

このバックアップを使用するのは移行が失敗した場合だけです。詳細については，nnmbackup.ovplのリファレンスページを参照してください。

「2.　NNMiのインストールとアンインストール」の手順に従って，ソースのNNMi管理サーバー上にNNMi 13-50をインストールする。

NNMi 13-50がソースのNNMi管理サーバー上で正しく動作していることを確認する。

nnmbackup.ovplスクリプトを使用して，NNMi 13-50をソースのNNMi管理サーバー上にバックアップする。このバックアップファイルにラベルを付ける。

データをターゲットのNNMi管理サーバーにコピーしてください。詳細については，nnmbackup.ovplのリファレンスページを参照してください。

「2.　NNMiのインストールとアンインストール」の手順に従って，ターゲットのNNMi管理サーバー上にNNMi 13-50をインストールする。

手順4.からデータを移行するには，ターゲットのNNMi管理サーバーが同じオペレーティングシステムで実行中である必要があります。NNMiでは，別のオペレーティングシステム上で実行中のNNMi管理サーバーへのデータ移行はサポートされていません。

nnmrestore.ovplスクリプトを使用して，NNMiのデータベース情報をターゲットサーバーにコピーする。

詳細については，nnmrestore.ovplのリファレンスページを参照してください。

新規ライセンスを取得し，ターゲットのNNMi管理サーバーにインストールする。

ターゲットのNNMi管理サーバー情報が既存のNNMi管理サーバーから正常に移行されたことを確認する。

24.3　NNMi 13-10からのグローバルマネージャーとリージョナルマネージャーのアップグレード

24.3.1　グローバルネットワーク管理によってサポートされているNNMiのバージョン

NNMi 13-50が実行されているグローバルマネージャーに接続された，NNMi 13-10以前が実行されているリージョナルマネージャーはサポートしていません。グローバルマネージャーとリージョナルマネージャーの両方で，同一バージョンのNNMiを実行する必要があります。

24.3.2　グローバルネットワーク管理のアップグレード手順

グローバルネットワーク管理環境で設定されたNNMi管理サーバーをNNMi 13-50にアップグレードする場合，グローバルマネージャーとリージョナルマネージャー間の接続は，グローバルマネージャーとリージョナルマネージャーの両方がNNMi 13-50にアップグレードされるまで切断されます。そのため，全体のダウンタイムを最小限に抑えるには，すべてのサーバーをほぼ同時にアップグレードすることをお勧めします。

例えば，次の手順でNNMi管理サーバーをアップグレードできます。

リージョナルマネージャーをNNMi 13-50にアップグレードし，正しく動作することを確認する。

アップグレード後，リリースノートの手順に従って新しいライセンスを適用してください。

証明書のリポジトリをPKCS #12リポジトリに移行していない場合は，アップグレード完了後に，リージョナルマネージャーにて「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従い，PKCS #12リポジトリに移行してください。

リージョナルマネージャーのアップグレード中，グローバルマネージャーは切断されたままになります。

グローバルマネージャーをNNMi 13-50にアップグレードする。

アップグレード後，リリースノートの手順に従って新しいライセンスを適用してください。

証明書のリポジトリをPKCS #12リポジトリに移行していない場合は，アップグレード完了後に，グローバルマネージャーにて「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従い，PKCS #12リポジトリに移行してください。

重要

次の点に注意してください。

アップグレード後，ステータスおよびインシデントへの更新が遅延することがあります。

24.4　アプリケーションフェイルオーバー構成のNNMi 13-50へのアップグレード

24.4.1　アプリケーションフェイルオーバー構成のNNMi 13-10からのアップグレード

NNMiアプリケーションフェイルオーバー設定で実行している13-10のNNMiをアップグレードする場合，次の手順に従ってください。

(1)　アプリケーションフェイルオーバー構成のNNMi 13-50へのアップグレード

アプリケーションフェイルオーバーを設定しているNNMi 管理サーバーをアップグレードするには，次の手順を実行します。

万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーの両方で，nnmconfigexport.ovplスクリプトを実行する。

詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーのNNMiデータをバックアップする。

詳細については，「20.2.2　バックアップ領域」を参照してください。

アクティブNNMi管理サーバーで次の手順を実行する。

nnmclusterの手順が機能するには，NNMiを実行している必要があります。この手順を完了すると，手順7.で示すスタンバイNNMi管理サーバーの起動が速くなります。

a　nnmclusterコマンドを実行します。

b　NNMiに入力を求められたら，「dbsync」と入力し，［Enter］キーを押します。表示される情報に次のメッセージが含まれていることを確認します。

ACTIVE_DB_BACKUP：アクティブNNMi管理サーバーが新しいバックアップを実行しています。

ACTIVE_NNM_RUNNING：アクティブNNMi管理サーバーが，前のメッセージによって示されたバックアップを完了しました。

STANDBY_RECV_DBZIP：スタンバイNNMi管理サーバーは，アクティブNNMi管理サーバーから新しいバックアップを取得しています。

STANDBY_READY：スタンバイNNMi管理サーバーは，アクティブNNMi管理サーバーで障害が発生した場合に実行できる準備が整えられています。

c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

スタンバイNNMi管理サーバーでnnmcluster -shutdownコマンドを実行する。

スタンバイNNMi管理サーバーのすべてのnnmclusterプロセスをシャットダウンします。

スタンバイNNMi管理サーバーでnnmclusterノードが動作していないことを確認するには，スタンバイNNMi管理サーバーで次の手順を実行する。

a　nnmclusterコマンドを実行します。

b　(SELF)とマークされているもの以外にnnmclusterノード(ローカル)が存在しないことを確認します。1つ以上のリモートノードが存在する場合があります。

c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

次の手順をスタンバイNNMi管理サーバーで実行し，アプリケーションフェイルオーバーを一時的に無効にする。

a　次のファイルを編集します。

Windows：%NNM_SHARED_CONF%¥props¥nms-cluster.properties

Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

b　com.hp.ov.nms.cluster.nameパラメーターをコメントにします。

c　変更を保存します。

d　次のファイルを編集します。

Windows：%NNM_DB%¥Postgres¥postgresql.conf

Linux：$NNM_DB/Postgres/postgresql.conf

e　次に示すアプリケーションフェイルオーバーの設定内容を削除します。

　・"# The following lines were added by the NNM cluster."で始まる行

　・"archive_command = "で始まる行

　・"archive_timeout = "で始まる行

　・"max_wal_senders = "で始まる行

　・"archive_mode = "で始まる行

　・"wal_level = "で始まる行

　・"hot_standby = "で始まる行

　・"wal_keep_segments = "で始まる行

　・"listen_addresses = "で始まる行

f　変更を保存します。

g　次の空ファイルを作成します。

Windows：%NNM_TMP%¥postgresTriggerFile

Linux：$NNM_TMP/postgresTriggerFile

スタンバイNNMi管理サーバーでプロセスを開始してから停止する。

a　スタンバイNNMi管理サーバーでovstartコマンドを実行します。ovstartコマンドを実行すると，スタンバイNNMi管理サーバーはトランザクションログをアクティブNNMi管理サーバーからインポートします。

b　ovstartコマンドの完了後，ovstatus -vコマンドを実行します。すべてのNNMiサービスで，［実行中］状態が表示されます。

c　スタンバイNNMi管理サーバーでovstopコマンドを実行します。

「2.　NNMiのインストールとアンインストール」およびリリースノートの指示に従い，スタンバイNNMi管理サーバーをNNMi 13-50にアップグレードする。

アップグレード後，リリースノートの手順に従って新しいライセンスを適用してください。

証明書のリポジトリをPKCS #12リポジトリに移行していない場合は，アップグレード完了後に，以前のスタンバイ NNMi 管理サーバーにて「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従い，PKCS #12リポジトリに移行してください。

以前のアクティブNNMi管理サーバーがNNMi 13-10以前を実行し，以前のスタンバイNNMi管理サーバーがNNMi 13-50を実行しています。両方のNNMi管理サーバーが個別に動作し，データベースは同期していません。つまり両方のNNMi管理サーバーがネットワークを並行して監視しています。

アップグレードを完了してこの状況を解決するには，以前のアクティブなクラスタノードをNNMi 13-50にアップグレードします。このアップグレードを完了する間，以前のスタンバイノードをオペレータに一時的に使用させてネットワークを監視させます。

この手順の残りの部分では，以前のアクティブなクラスタノードのデータベース情報を維持して，以前のスタンバイノードのデータベース情報を破棄することを想定しています。

以前のアクティブNNMi管理サーバーでnnmcluster -haltコマンドを実行する。

以前のアクティブNNMi管理サーバーでnnmclusterノードが動作していないことを確認するには，以前のアクティブNNMi管理サーバーで次の手順を実行する。

a　nnmclusterコマンドを実行します。

b　(SELF)とマークされているもの以外にnnmclusterノード(ローカル)が存在しないことを確認します。1つ以上のリモートノードが存在する場合があります。

c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

次の手順を以前のアクティブNNMi管理サーバーで実行し，アプリケーションフェイルオーバーを一時的に無効にする。

a　次のファイルを編集します。

Windows：%NNM_SHARED_CONF%¥props¥nms-cluster.properties

Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

b　com.hp.ov.nms.cluster.nameパラメーターをコメントにします。

c　変更を保存します。

「2.　NNMiのインストールとアンインストール」の指示に従い，以前のアクティブNNMi管理サーバーをNNMi 13-50にアップグレードする。

アップグレード後，リリースノートの手順に従って新しいライセンスを適用してください。

証明書のリポジトリをPKCS #12リポジトリに移行していない場合は，アップグレード完了後に，以前のアクティブ NNMi 管理サーバーにて「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従い，PKCS #12リポジトリに移行してください。

2つのサーバーでNNMi 13-50を実行していますが，データベースが同期していないため，まだ個別に動作しています。

以前のアクティブNNMi管理サーバーで次の手順を実行する。

a　ovstopコマンドを実行します。

b　次のファイルを編集します。

Windows：%NNM_SHARED_CONF%¥props¥nms-cluster.properties

Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

c　13-10からアップグレードした場合，com.hp.ov.nms.cluster.nameパラメーターの値を入力します。

　13-10からアップグレードした場合コメントにしたプロパティは保持されません。したがって，クラスタ名は再入力する必要があります。

d　com.hp.ov.nms.cluster.nameパラメーターのコメントを解除します。

e　変更を保存します。

ovstartコマンドまたはnnmcluster -daemonコマンドを以前のアクティブNNMi管理サーバーで実行する。これがアクティブなクラスタノードとなる。

アクティブなクラスタノードを使用してネットワークを監視するように，オペレータに指示する。

以前のスタンバイNNMi管理サーバーは，手順9.から手順13.のメンテナンス中に発生したすべてのデータベースアクティビティを破棄します。

以前のスタンバイNNMi管理サーバーで次の手順を実行する。

a　ovstopコマンドを実行します。

b　次のファイルを編集します。

Windows：%NNM_SHARED_CONF%¥props¥nms-cluster.properties

Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

c　13-10からアップグレードした場合，com.hp.ov.nms.cluster.nameパラメーターの値を入力します。

d　com.hp.ov.nms.cluster.nameパラメーターのコメントを解除します。

e　変更を保存します。

ovstartコマンドまたはnnmcluster -daemonコマンドを以前のスタンバイNNMi管理サーバーで実行する。

このNNMi管理サーバーはスタンバイノードになり，アクティブなクラスタノードからデータベースのコピーを受信します。

(2)　アプリケーションフェイルオーバー構成のNNMi 13-50への修正パッチ適用手順

両方のNNMi管理サーバーで同じバージョンとパッチレベルのNNMiを実行している必要があります。アクティブおよびスタンバイのNNMi管理サーバーにパッチを追加するには，次のどちらかの方法を使用します。

アプリケーションフェイルオーバー用にパッチを適用する（アクティブとスタンバイの両方をシャットダウン）

ネットワーク監視が中断されても問題にならない場合は，この手順を使用してください。

アプリケーションフェイルオーバー用にパッチを適用する（1つのアクティブNNMi管理サーバーを保持）

ネットワーク監視の中断を回避する必要がある場合は，この手順を使用してください。

(a)　アプリケーションフェイルオーバー用にパッチを適用する（アクティブとスタンバイの両方をシャットダウン）

この手順を実行すると，パッチプロセス中の一定期間，両方のNNMi管理サーバーが非アクティブになります。アプリケーションフェイルオーバーを設定しているNNMi管理サーバーにパッチを適用するには，次の手順を実行します。

万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーの両方で，nnmconfigexport.ovplスクリプトを実行する。

詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーのNNMiデータをバックアップする。

詳細については，「20.2.2　バックアップ領域」を参照してください。

万一に備えて，アクティブNNMi管理サーバーで，次の手順を実行する。

a　nnmclusterコマンドを実行します。

b　NNMiに入力を求められたら，「dbsync」と入力し，［Enter］キーを押します。表示される情報に次のメッセージが含まれていることを確認します。

ACTIVE_DB_BACKUP：アクティブNNMi管理サーバーが新しいバックアップを実行しています。

ACTIVE_NNM_RUNNING：アクティブNNMi管理サーバーが，前のメッセージによって示されたバックアップを完了しました。

STANDBY_READY：スタンバイNNMi管理サーバーの前のステータスを示します。

STANDBY_RECV_DBZIP：スタンバイNNMi管理サーバーは，アクティブNNMi管理サーバーから新しいバックアップを取得しています。

STANDBY_READY：スタンバイNNMi管理サーバーは，アクティブNNMi管理サーバーで障害が発生した場合に実行できる準備が整えられています。

c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

アクティブNNMi管理サーバーでnnmcluster -haltコマンドを実行する。

アクティブおよびスタンバイNNMi管理サーバーのすべてのnnmclusterプロセスをシャットダウンします。

両方のサーバーでnnmclusterノードが実行していないことを確認するには，アクティブおよびスタンバイNNMi管理サーバーの両方で次の手順を実行する。

a　nnmclusterコマンドを実行します。

b　(SELF)とマークされているもの以外にnnmclusterノードが存在しないことを確認します。

c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

アクティブNNMi管理サーバーで，nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.nameパラメーターをコメントにする。

a　次のファイルを編集します。

Windows：%NNM_SHARED_CONF%¥props¥nms-cluster.properties

Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

b　com.hp.ov.nms.cluster.nameパラメーターをコメントにします。

c　変更を保存します。

パッチに同梱されているRELEASE.TXTの指示に従い，アクティブNNMi管理サーバーにNNMiパッチを適用する。

アクティブNNMi管理サーバーで，nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.nameパラメーターのコメントを解除する。

a　次のファイルを編集します。

Windows：%NNM_SHARED_CONF%¥props¥nms-cluster.properties

Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

b　com.hp.ov.nms.cluster.nameパラメーターのコメントを解除します。

c　変更を保存します。

アクティブNNMi管理サーバーでovstartコマンドを実行する。

NNMiコンソールの［ヘルプ］＞［システム情報］ウィンドウにある［製品］タブで情報を表示し，アクティブNNMi管理サーバーにパッチが正しくインストールされたことを確認する。

nnmcluster -dbsyncコマンドを実行して，新しいバックアップを作成する。

手順6.のa〜cに示されているように，スタンバイNNMi管理サーバーで，nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.nameパラメーターをコメントにする。

NNMiパッチをスタンバイNNMi管理サーバーに適用する。

手順8.のa〜cに示されているように，スタンバイNNMi管理サーバーで，nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.nameパラメーターのコメントを解除する。

スタンバイNNMi管理サーバーでovstartコマンドを実行する。

(b)　アプリケーションフェイルオーバー用にパッチを適用する（1つのアクティブNNMi管理サーバーを保持）

この手順を実行すると，パッチプロセスの間，1つのNNMi管理サーバーが常にアクティブになります。

このプロセスでは，ネットワークが継続的に監視されますが，NNMiでパッチプロセス中に生じたトランザクションログは失われます。

アプリケーションフェイルオーバーを設定しているNNMi管理サーバーにNNMiパッチを適用するには，次の手順を実行します。

万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーの両方で，nnmconfigexport.ovplスクリプトを実行する。

詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーのNNMiデータをバックアップする。

詳細については，「20.2.2　バックアップ領域」を参照してください。

ノードのどれかでnnmclusterコマンドを実行する。

前の手順で2つのデータベースの同期に使用したNNMi管理サーバーでdbsyncを入力する。

dbsyncオプションは，組み込みデータベースを使用するNNMi管理サーバーで機能します。

アクティブNNMi管理サーバーがACTIVE_NNM_RUNNINGに戻り，スタンバイNNMi管理サーバーがSTANDBY_READYに戻るまで待機してから，次に進む。

nnmclusterを終了または中断させる。

次のコマンドをスタンバイNNMi管理サーバーで実行して，スタンバイNNMi管理サーバーのクラスタを停止する。

nnmcluster -shutdown

次のプロセスとサービスが終了しているのを確認してから，次に進む。

postgres
ovjboss

nnmclusterプロセスが終了しているのを確認してから，次に進む。

nnmclusterプロセスが終了していない場合，ほかに方法がなければ，nnmclusterプロセスを手動で強制終了します。

スタンバイNNMi管理サーバーで，次のファイルを編集する。

Windows：%nnmDataDir%shared¥nnm¥conf¥props¥nms-cluster.properties

Linux：$nnmDataDir/shared/nnm/conf/props/nms-cluster.properties

行の先頭に#を入れてクラスタ名をコメントにして変更を保存する。

#com.hp.ov.nms.cluster.name = NNMicluster

スタンバイNNMi管理サーバーにNNMiパッチをインストールする。

この時点で，スタンバイNNMi管理サーバーはパッチが適用済みで停止中，アクティブNNMi管理サーバーはパッチが未適用で実行中である。

アクティブNNMi管理サーバーを停止し，ただちにスタンバイNNMi管理サーバーを起動してネットワークを監視させます。

アクティブNNMi管理サーバーで次のコマンドを実行して，アクティブNNMi管理サーバーのクラスタをシャットダウンする。

nnmcluster -halt

nnmclusterプロセスの終了を確認する。

数分以内に終了しない場合は，nnmclusterプロセスを手動で終了してください。

スタンバイNNMi管理サーバーで，nms-cluster.propertiesファイルからクラスタ名のコメントを解除する。

次のコマンドをスタンバイNNMi管理サーバーで実行して，スタンバイNNMi管理サーバーのクラスタを起動する。

nnmcluster -daemon

アクティブNNMi管理サーバーにNNMiパッチをインストールする。

この時点で，以前のアクティブNNMi管理サーバーはパッチが適用済みですが，オフラインである。

次の手順を実行して，（スタンバイNNMi管理サーバーとして）クラスタに復帰させます。

a　アクティブNNMi管理サーバーで，nms-cluster.propertiesファイルのエントリのコメントを解除します。

b　次のコマンドを使用して，アクティブNNMi管理サーバーを起動します。

nnmcluster -daemon

進行状況を監視するには，アクティブとスタンバイの両方のNNMi管理サーバーで次のコマンドを実行する。

nnmcluster

以前のアクティブNNMi管理サーバーが，以前のスタンバイNNMi管理サーバーからデータベースの取得を完了するまで待機します。

以前のアクティブNNMi管理サーバーにSTANDBY_READYが表示されたら，以前のアクティブNNMi管理サーバーで次のコマンドを実行する。

nnmcluster -acquire

第8編　NNMiとの統合編

25　NNMi Northboundインタフェース

NNMiには，NNMi Northboundインタフェースが用意されています。NNMi Northboundインタフェースを使用すると，SNMPv2cトラップを受信できるアプリケーションにNNMiインシデントを転送できます。各NNMi管理サーバーに，別々に設定された複数のNNMi Northboundインタフェースを実装できます。この章では，NNMiインシデントを任意のNorthboundアプリケーションに転送するようにNNMiを設定する方法を説明します。特定のNorthboundアプリケーションの詳細については，アプリケーションのマニュアルを参照してください。なお，異なるNorthboundアプリケーションとの統合についても，記載されています。

25.1　NNMi Northboundインタフェースの概要

NNMi Northboundインタフェースの概要を次に示します。

NNMi管理イベントをSNMPv2cトラップとしてNorthboundアプリケーションに転送します。

Northboundアプリケーションは，NNMiトラップをフィルタリング，処理，および表示します。Northboundアプリケーションには，NNMiトラップのコンテキストでNNMiコンソールにアクセスするツールも用意されています。

インシデントライフサイクルの状態変更通知，インシデント相関処理通知，およびインシデント削除通知をNorthboundアプリケーションに送信できます。

このように，NorthboundアプリケーションはNNMiの因果関係分析の結果を複製できます。

NNMiが受信するSNMPトラップをNorthboundアプリケーションに転送することもできます。

サードパーティまたはカスタムイベント統合アプリケーションでイベント統合を実行できます。

そのほかのアプリケーションとNNMiの統合に使用できる情報でイベントを強化します。

この章では，次の用語を使用します。

Northboundアプリケーション：SNMPv2cトラップを受信および処理できる任意のアプリケーションです。

トラップ受信コンポーネント：SNMPトラップを受信する，Northboundアプリケーションの一部分です。

一部のアプリケーションには，SNMPトラップを受信して処理用に別のコンポーネントに転送する，個別にインストール可能なコンポーネントが含まれます。

そのようなコンポーネントがないNorthboundアプリケーションの場合，「トラップ受信コンポーネント」は「Northboundアプリケーション」と同義語です。

NNMi Northboundインタフェース：NNMiインシデントをSNMPv2cトラップとしてNorthboundアプリケーションに転送するNNMiの機能です。

Northbound転送先：Northboundアプリケーションのトラップ受信コンポーネントへの接続を定義し，NNMiがそのNorthboundアプリケーションに送信するトラップのタイプを指定するNNMi Northboundインタフェースの設定の1つです。

25.2　NNMi Northboundインタフェースの有効化

NNMiは，UDPを使用してSNMPトラップで送信される情報の量を制限しません。トラップデータのサイズが大きくて処理できないネットワークハードウェアが伝送経路上にあったり，ネットワークトラフィックの量が多かったりすると，トラップが失われることがあります。そのため，Northboundアプリケーションのトラップ受信コンポーネントをNNMi管理サーバーにインストールすることをお勧めします。Northboundアプリケーションは，信頼性のある情報を転送する役割を担います。

NNMi Northboundインタフェースを有効にするには，次の手順を実行します。

必要に応じて，NNMiトラップ定義を認識できるようにNorthboundアプリケーションを設定する。

NNMi管理サーバーで，NNMiインシデント転送を設定する。

a　NNMiコンソールで，［HP NNMi-Northboundインタフェースデスティネーション］フォーム（［統合モジュールの設定］＞［Northbound インタフェース］）を開き，［新規作成］をクリックします。

使用できる転送先を選択してある場合，［リセット］をクリックして，［新規作成］ボタンを使用できるようにしてください。

b　［有効にする］チェックボックスをオンにし，フォームの残りのフィールドを入力できるようにします。

c　Northbound アプリケーションへの接続情報を入力します。

これらのフィールドの詳細は，「25.8.1　NNMi Northboundアプリケーションの接続パラメーター」を参照してください。

d　送信オプションおよびNorthboundアプリケーションに送信する内容に対するインシデントフィルターを指定します。

これらのフィールドの詳細は，「25.8.2　NNMi Northboundインタフェース統合の内容」を参照してください。

e　フォームの下部にある［送信］をクリックします。

新しいウィンドウが開き，ステータスメッセージが表示されます。設定に問題があることを示すメッセージが表示されたら，［戻る］をクリックして，エラーメッセージを参考に値を調整してください。

（任意）NorthboundアプリケーションからNNMiビューにアクセスするためのURLを作成し，NNMiとのコンテキストインタラクションを作成する。

NNMiは，UDPを使用してSNMPトラップで送信される情報の量を制限しません。トラップデータのサイズが大きくて処理不能なネットワークハードウェアが伝送経路上にあったり，ネットワークトラフィックの量が多かったりすると，トラップが失われることがあります。そのため，Northboundアプリケーションのトラップ受信コンポーネントをNNMi管理サーバーにインストールすることをお勧めします。Northboundアプリケーションは，信頼性のある情報を転送する役割を担います。

詳細については，NNMiコンソールで，［ヘルプ］＞［NNMIドキュメントライブラリ］＞［NNMiを別の場所でURLと統合］をクリックしてください。

25.3　NNMi Northboundインタフェースの使用法

NNMi Northboundインタフェースを有効にすると，Northbound転送先によってNNMiがNorthboundアプリケーションに送信する情報が決まります。Northboundアプリケーションを設定して，転送されるトラップがネットワーク環境に応じて表示および解釈されるようにします。NNMiがNorthboundアプリケーションに送信するトラップの内容および形式の詳細については，hp-nnmi-nbi.mibおよびhp-nnmi-registrations.mibファイルを参照してください。

NNMiは，各管理イベント，SNMPトラップ，または通知トラップのコピーを1つだけNorthbound転送先に送信します。NNMiはトラップをキューに入れません。NNMiがトラップを転送するときにNorthboundアプリケーションのトラップ受信コンポーネントに接続できないと，トラップは失われます。

このセクションでは，統合で送信できるトラップのタイプを説明します。コンテンツ設定の詳細については，「25.8.2　NNMi Northboundインタフェース統合の内容」を参照してください。

25.3.1　インシデント転送

(1)　管理イベント

Northboundに管理イベントが含まれる場合，そのインシデントのライフサイクル状態が［登録済み］に変更されると，NNMiは各管理イベントをNorthboundアプリケーションに転送します。

転送される管理イベントのOIDは，NNMiコンソールの［管理イベントの設定］フォームに表示されるSNMPオブジェクトIDです。NNMiは，OIDが1.3.6.1.4.1.11.2.17.19.2.0.9999のすべてのカスタム管理イベントを転送します。

(2)　サードパーティSNMPトラップ

Northbound転送先にサードパーティのSNMPトラップが含まれる場合，関連インシデントのライフサイクル状態が［登録済み］に変更されると，NNMiはSNMPv1，v2c，またはv3形式の各受信ラップをNorthboundアプリケーションに転送します。NNMiは，MIBで定義される元のトラップvarbindの順序を維持し，メッセージペイロードにNNMi固有のvarbindを追加します。元のトラップに含まれていない定義済みvarbindがある場合，NNMiは，その欠落しているvarbindの部分にNULL値を付与します。MIBがNNMiにロードされていない場合，NNMi固有のvarbindだけがトラップに追加され，次にこのトラップが転送されます。

サードパーティのSNMPトラップの場合は，次の点に注意してください。

NNMiはSNMPトラップインシデントからのトラップを再構成するため，転送されるトラップの形式は，NNMiが受信した元のトラップの形式に関係なく，SNMPv2cとなります。

転送されるSNMPトラップは，NNMi管理サーバーをソースオブジェクトとして示します。元のソースオブジェクトを判断するには，（n＋21）番目のvarbindの値nnmiIncidentSourceNodeHostname（1.3.6.1.4.1.11.2.17.19.2.2.21）と，（n＋24）番目のvarbindの値nnmiIncidentSourceNodeMgmtAddr（1.3.6.1.4.1.11.2.17.19.2.2.24）を調べてください。nはMIBでトラップに定義されているvarbindの数です。

NNMiが管理するデバイスのどれかがNorthboundアプリケーションにトラップを送信する場合，Northboundアプリケーションで重複デバイストラップを管理する必要があります。

トラップ転送メカニズムの比較については，「8.1.2　トラップおよびインシデント転送」を参照してください。

25.3.2　インシデントライフサイクル状態変化通知

このセクションの情報は，［NNMi-Northboundインタフェースデスティネーション］ページの［送信オプション］の選択によって異なります。

(1)　エンハンスド解決済みしたトラップ

Northbound転送先にエンハンスド解決済み通知が含まれる場合，NNMiのインシデントのライフサイクル状態が［解決済み］に変化したときに，NNMiはnnmiEvClosed（1.3.6.1.4.1.11.2.17.19.2.0.1000）トラップをNorthboundアプリケーションに転送します。nnmiEvClosedトラップは，元のインシデントのデータの多くを含んでいます。前のライフサイクル状態の値は含んでいません。

nnmiEvClosedトラップは，6番目のvarbindであるnnmiIncidentUuid（1.3.6.1.4.1.11.2.17.19.2.2.6）で元のインシデントを識別します。

(2)　状態変化トラップ

Northbound転送先にライフサイクル状態変更通知が含まれる場合，NNMiのインシデントのライフサイクル状態が［進行中］，［完了］，または［解決済み］に変化したときに，NNMiはnnmiEvLifecycleStateChanged（1.3.6.1.4.1.11.2.17.19.2.0.1001）トラップをNorthboundアプリケーションに送信します。Northboundアプリケーションは，nnmiEvLifecycleStateChangedと元のインシデントを関連づけできます。

nnmiEvLifecycleStateChangedトラップは，次のvarbindで元のインシデントとライフサイクル状態の変化を識別します。

nnmiIncidentUuid，6番目のvarbind（1.3.6.1.4.1.11.2.17.19.2.2.6）

この値は，管理イベントの6番目のvarbindの値，またはサードパーティSNMPトラップvarbindの（n＋6）番目のvarbindの値と一致します。

nnmiIncidentLifecycleStatePreviousValue，7番目のvarbind（1.3.6.1.4.1.11.2.17.19.2.2.200）

nnmiIncidentLifecycleStateCurrentValue，8番目のvarbind（1.3.6.1.4.1.11.2.17.19.2.2.201）

次の表は，ライフサイクル状態に使用できる整数値を示したものです。

名前

整数値

登録済み

1

進行中

2

完了

3

解決済み

4

抑止済み

5

25.3.3　インシデント相関処理通知

Northbound転送先にインシデント相関処理通知が含まれる場合，NNMiの因果関係分析でインシデントが相関処理されると，NNMiはインシデント相関処理トラップをNorthboundアプリケーションに送信します。Northboundアプリケーションはトラップ内の情報を使用して相関変更を複製できます。

(1)　単一相関トラップ

単一相関トラップオプションの場合，この統合では，次の相関トラップを送信します。

nnmiEvCorrelationDedup（1.3.6.1.4.1.11.2.17.19.2.0.1100）

nnmiEvCorrelationImpact（1.3.6.1.4.1.11.2.17.19.2.0.1101）

nnmiEvCorrelationPairwise（1.3.6.1.4.1.11.2.17.19.2.0.1102）

nnmiEvCorrelationRate（1.3.6.1.4.1.11.2.17.19.2.0.1103）

nnmiEvCorrelationApa（1.3.6.1.4.1.11.2.17.19.2.0.1104）

nnmiEvCorrelationCustom（1.3.6.1.4.1.11.2.17.19.2.0.1105）

各トラップは，次のvarbindで，1つの親子インシデント相関関係を示します。

nnmiIncidentUuid，6番目のvarbind（1.3.6.1.4.1.11.2.17.19.2.2.6）

nnmiCorrelatedChildUuid，7番目のvarbind（1.3.6.1.4.1.11.2.17.19.2.2.300）

(2)　グループ相関トラップ

グループ相関トラップオプションの場合，この統合では，次の相関トラップを送信します。

nnmiEvCorrelationGrpDedup（1.3.6.1.4.1.11.2.17.19.2.0.2100）

nnmiEvCorrelationGrpImpact（1.3.6.1.4.1.11.2.17.19.2.0.2101）

nnmiEvCorrelationGrpPairwise（1.3.6.1.4.1.11.2.17.19.2.0.2102）

nnmiEvCorrelationGrpRate（1.3.6.1.4.1.11.2.17.19.2.0.2103）

nnmiEvCorrelationGrpApa（1.3.6.1.4.1.11.2.17.19.2.0.2104）

nnmiEvCorrelationGrpCustom（1.3.6.1.4.1.11.2.17.19.2.0.2105）

各トラップは，次のvarbindで，親子インシデント相関関係を示します。

nnmiIncidentUuid，6番目のvarbind（1.3.6.1.4.1.11.2.17.19.2.2.6）

nnmiCorrelatedChildrenCount，7番目のvarbind（1.3.6.1.4.1.11.2.17.19.2.2.301）

nnmiCorrelatedChildrenUuidCsv，8番目のvarbind（1.3.6.1.4.1.11.2.17.19.2.2.302）

この値は子インシデントUUIDのコンマ区切りリストです。

25.3.4　インシデント削除通知

Northbound転送先にインシデント削除通知が含まれる場合，インシデントがNNMiで削除されると，NNMiはnnmiEvDeleted（1.3.6.1.4.1.11.2.17.19.2.0.3000）トラップをNorthboundアプリケーションに送信します。nnmiEvDeletedトラップは，6番目のvarbindであるnnmiIncidentUuid（1.3.6.1.4.1.11.2.17.19.2.2.6）で元のインシデントを識別します。

25.3.5　イベント転送フィルター

Northbound転送先にインシデントフィルターが含まれる場合，選択した設定オプションに応じて，フィルターのオブジェクトID（OID）には，次のイベントタイプが包含または除外されます。

NNMi管理イベントインシデント

サードパーティSNMPトラップ

nnmiEvClosedトラップ

nnmiEvLifecycleStateChangedトラップ

nnmiEvDeletedトラップ

相関関係通知トラップ ※

注※　相関関係通知トラップについて次の注意が必要です。

インシデントフィルターが相関処理に親インシデントを転送しない場合，NNMiは相関関係通知トラップをNorthboundアプリケーションに送信しません。

インシデントフィルターが相関処理に子インシデントを転送しない場合，転送される相関関係通知トラップにその子インシデントのUUIDは含まれません。つまり，相関関係通知トラップに子インシデントUUIDが含まれない場合，NNMiはそのトラップをNorthboundアプリケーションに送信しません。

DuplicateCorrelation管理イベントは，nnmiEvCorrelationDedupまたはnnmiEvCorrelationGrpDedup相関関係通知トラップとは無関係に転送されます。同様に，RateCorrelation管理イベントはnnmiEvCorrelationRateまたはnnmiEvCorrelationGrpRate相関関係通知トラップとは無関係に転送されます。インシデントフィルターがこれらの相関関係通知トラップのどれかを転送しない場合でも，NNMiによって関連管理イベントが転送される場合があります。

25.4　NNMi Northboundインタフェースの変更

NNMi Northboundインタフェースの設定パラメーターを変更するには，次の手順を実行します。

NNMiコンソールで，［NNMi-Northboundインタフェースデスティネーション］フォーム（［統合モジュールの設定］＞［Northboundインタフェース］）を開く。

転送先を選択し，［編集］をクリックする。

該当するように値を変更する。

このフォームのフィールドの詳細は，「25.8　［NNMi-Northboundインタフェースデスティネーション］フォームのリファレンス」を参照してください。

フォームの上端の［有効にする］チェックボックスがオンであることを確認し，フォームの下端の［送信］をクリックする。

変更は直ちに有効になります。

25.5　NNMi Northboundインタフェースの無効化

Northbound転送先が無効な間は，SNMPトラップはキューイングされません。

NorthboundアプリケーションへのNNMiの転送を中止するには，次の手順を実行します。

NNMiコンソールで，［NNMi-Northboundインタフェースデスティネーション］フォーム（［統合モジュールの設定］＞［Northboundインタフェース］）を開く。

転送先を選択し，［編集］をクリックする。または，［削除］をクリックして，選択した転送先の設定をすべて削除する。

フォームの上端の［有効にする］チェックボックスをオフにし，フォームの下端の［送信］をクリックする。

変更は直ちに有効になります。

25.6　NNMi Northboundインタフェースのトラブルシューティング

NNMi Northboundインタフェースが正常に機能しない場合は，次の手順を実行して問題を解決してください。

トラップ転送先ポートがファイアウォールによってブロックされていないことを確認する。

NNMi管理サーバーが，ホストとポートによってNorthboundアプリケーションを直接処理できることを確認します。

統合が正常に実行されていることを確認する。

a　NNMiコンソールで，［NNMi-Northboundインタフェースデスティネーション］フォーム（［統合モジュールの設定］＞［Northbound インタフェース］）を開きます。

b　転送先を選択し，［編集］をクリックします。

c　［有効にする］オプションが選択されていることを確認します。

Northbound転送先に管理イベントが含まれる場合は，この機能を確認する。

a　NNMiコンソールの［解決済みの重要なインシデント］ビューで，任意のインシデントを開きます。

b　インシデントライフサイクル状態を［登録済み］に設定して，［保存］をクリックします。

c　インシデントライフサイクル状態を［解決済み］に設定して，［保存して閉じる］をクリックします。

d　30秒後，NorthboundアプリケーションがこのインシデントのnnmiEvClosedトラップ（またはnnmiEvLifecycleStateChangedトラップ）を受信したかどうかを確認します。

Northboundアプリケーションがトラップを受信した場合は，手順4.を続行します。

Northboundアプリケーションがトラップを受信しなかった場合は，異なるNorthboundアプリケーションに接続する新規Northbound転送先を設定してから，手順aからこのテストを繰り返します。

再テストに合格した場合，問題は最初のNorthboundアプリケーションにあります。アプリケーションのドキュメントでトラブルシューティング情報を参照してください。再テストに不合格になった場合は，サポートサービスに問い合わせてください。

Northbound転送先にSNMPトラップが含まれる場合は，この機能を確認する。

a　NNMi管理サーバーで次のコマンドを入力することで，NNMiトポロジ内のノードに対するSNMPトラップを生成します。

nnmsnmpnotify.ovpl -a ¥
discovered_node NNMi_node .1.3.6.1.6.3.1.1.5.1

discovered_nodeは，NNMiトポロジのノードのホスト名またはIPアドレスです。NNMi_nodeは，NNMi管理サーバーのホスト名またはIPアドレスです。

b　30秒後に，Northboundアプリケーションが転送されたトラップを受信したかどうかを確認します。

Northboundアプリケーションがトラップを受信した場合，NNMi Northboundインタフェースは正常に機能しています。

Northboundアプリケーションがトラップを受信しなかった場合は，異なるNorthboundアプリケーションに接続する新規Northbound転送先を設定してから，手順aからこのテストを繰り返します。

再テストに合格した場合，問題は最初のNorthboundアプリケーションにあります。アプリケーションのドキュメントでトラブルシューティング情報を参照してください。再テストに不合格になった場合は，サポートサービスに問い合わせてください。

25.7　アプリケーションフェイルオーバーとNNMi Northboundインタフェース

NNMi管理サーバーがNNMiアプリケーションフェイルオーバーに関係することになる場合，ここでの情報は，Northboundレシーバーにトラップを送信するNNMi Northboundアプリケーションを実装するすべての統合に適用されます。

NNMiがNorthboundアプリケーションに送信するトラップには，NmsUrl varbind（1.3.6.1.4.1.11.2.17.19.2.2.2）のNNMi URLが含まれます。アプリケーションフェイルオーバー前に受信したトラップは，現在のスタンバイNNMi管理サーバーを参照します。

URLがスタンドバイNNMi管理サーバーを指す場合，そのURL値を使用するすべてのアクション（例えば，NNMiコンソールの起動）は失敗します。

25.7.1　ローカルNorthboundアプリケーション

Northboundアプリケーションのトラップ受信コンポーネントがNNMi管理サーバー上にある場合は，次のことがNNMi Northboundインタフェースの設定に適用されます。

Northboundアプリケーションのトラップ受信コンポーネントは，アクティブおよびスタンバイNNMi管理サーバーに同じようにインストールおよび設定する必要があります。両方のNNMi管理サーバーの同じポートでSNMPトラップ受信を設定します。

プライマリNNMi管理サーバーだけでNNMi Northboundインタフェースを設定します。

［NNMi-Northboundインタフェースデスティネーション］フォームの［ホスト］識別で，［NNMi FQDN］または［ループバックを使用］オプションを選択します。

NNMi Northboundインタフェースは，起動時に，現在のNNMi管理サーバーの正しい名前またはIPアドレスを判断します。このように，Northboundインタフェースは，トラップをアクティブなNNMi管理サーバー上のNorthboundアプリケーションのトラップ受信コンポーネントに送信します。

25.7.2　リモートNorthboundアプリケーション

Northboundアプリケーションのトラップ受信コンポーネントがNNMi管理サーバー上にない場合は，NNMi NorthboundインタフェースをプライマリNNMi管理サーバーだけで設定します。［NNMi-Northboundインタフェースデスティネーション］フォームの［ホスト］識別で，［その他］オプションを選択します。

25.8　［NNMi-Northboundインタフェースデスティネーション］フォームのリファレンス

［HP NNMi-Northboundインタフェースデスティネーション］フォームには，NNMiとNorthboundアプリケーション間の通信設定パラメーターがあります。このフォームは，［統合モジュールの設定］ワークスペースから使用できます。［NNMi-Northboundインタフェースデスティネーション］フォームで，［新規作成］をクリックするか，または転送先を選択して，［編集］をクリックします。

AdministratorロールのNNMiユーザーだけが［NNMi-Northboundインタフェースデスティネーション］フォームにアクセスできます。

［NNMi-Northboundインタフェースデスティネーション］フォームには，次の領域の情報が表示されます。

「25.8.1　NNMi Northboundアプリケーションの接続パラメーター」

「25.8.2　NNMi Northboundインタフェース統合の内容」

「25.8.3　NNMi Northboundインタフェース転送先のステータス情報」

統合設定に変更を適用するには，［NNMi-Northboundインタフェースデスティネーション］フォームの値を更新し，［送信］をクリックします。

25.8.1　NNMi Northboundアプリケーションの接続パラメーター

次の表は，NNMi Northboundアプリケーションへの接続設定用パラメーターを示したものです。

表25‒1　NNMi Northboundアプリケーションの接続情報

フィールド

説明

ホスト

Northboundアプリケーションのトラップ受信コンポーネントを含むサーバーの完全修飾ドメイン名（推奨）またはIPアドレス。

統合では，次のサーバーの識別方法がサポートされています。

NNMi FQDN

NNMiがNNMi管理サーバー上のNorthboundアプリケーションへの接続を管理し，［ホスト］フィールドが読み取り専用になります。

これが，NNMi管理サーバー上でのNorthboundアプリケーションの推奨設定です。

ループバックを使用

NNMiがNNMi管理サーバー上のNorthboundアプリケーションへの接続を管理し，［ホスト］フィールドが読み取り専用になります。

その他

Northboundアプリケーションサーバーを識別するホスト名またはIPアドレスを，［ホスト］フィールドに入力します。

NNMiは，［ホスト］フィールドのホスト名またはIPアドレスがループバックアダプターとして設定されていないことを確認します。

これがデフォルト設定です。

注　NNMi管理サーバーがNNMiアプリケーションフェイルオーバーに参加する場合にアプリケーションフェイルオーバーが統合に与える影響については，「25.7　アプリケーションフェイルオーバーとNNMi Northboundインタフェース」を参照してください。

ポート

NorthboundアプリケーションがSNMPトラップを受信するUDPポート。

Northboundアプリケーション固有のポート番号を入力します。

注　Northboundアプリケーションのトラップ受信コンポーネントがNNMi管理サーバー上にある場合，このポート番号は，NNMiコンソールの［通信の設定］フォームの［SNMPポート］フィールドで設定した，NNMiがSNMPトラップを受信するために使用するポートと別にする必要があります。

コミュニティ文字列

トラップを受信するNorthboundアプリケーションの読み取り専用コミュニティ文字列。

Northboundアプリケーション設定で，受信したSNMPトラップにコミュニティ文字列が必要な場合は，その値を入力します。

Northboundアプリケーション設定で，特定のコミュニティ文字列が不要な場合は，デフォルト値のpublicを使用します。

25.8.2　NNMi Northboundインタフェース統合の内容

NNMi NorthboundインタフェースがNorthboundアプリケーションに送信する内容を設定するためのパラメーターを次の表に示します。

表25‒2　NNMi Northboundインタフェースの内容設定情報

フィールド

説明

インシデント

インシデント転送の指定。

管理

NNMiは，NNMiが生成した管理イベントだけをNorthboundアプリケーションに転送します。

サードパーティSNMPトラップ

NNMiは，NNMiが管理対象デバイスから受信するSNMPトラップだけをNorthboundアプリケーションに転送します。

Syslog

NNMiは，NNMiが管理対象デバイスから受信するArcSight SyslogメッセージだけをNorthbound 統合モジュールを使用してNorthboundアプリケーションに転送します。

NNMiは，Northbound転送先を有効にすると直ちにインシデントの転送を開始します。詳細については，「25.3.1　インシデント転送」を参照してください。

ライフサイクル状態の変化

インシデント変更通知の仕様。

エンハンスド解決済み

NNMiは，ライフサイクル状態が［解決済み］に変化したインシデントごとに，インシデント解決済みトラップをNorthboundアプリケーションに送信します。

これがデフォルト設定です。

変化した状態

NNMiは，ライフサイクル状態が［進行中］，［完了］，または［解決済み］に変化したインシデントごとに，インシデントのライフサイクル状態変化トラップをNorthboundアプリケーションに送信します。

両方

NNMiは，ライフサイクル状態が［解決済み］に変化したインシデントごとに，インシデント解決済みトラップをNorthboundアプリケーションに送信します。また，この統合では，ライフサイクル状態が［進行中］，［完了］，または［解決済み］に変化したインシデントごとに，インシデントのライフサイクル状態変化トラップをNorthboundアプリケーションに送信します。

注　この場合，インシデントが［解決済み］ライフサイクル状態に変化するたびに，インシデント解決済みトラップとインシデントライフサイクル状態変更トラップの2つの通知トラップが統合によって送信されます。

詳細については，「25.3.2　インシデントライフサイクル状態変化通知」を参照してください。

相関処理

インシデント相関処理通知の仕様。

なし

NNMiは，NNMi因果関係分析によるインシデント相関処理結果をNorthboundアプリケーションに通知しません。

これがデフォルト設定です。

単一

NNMiは，NNMi因果関係分析で判明した親子インシデント相関関係ごとにトラップを1つ送信します。

グループ

NNMiは，親インシデントに相関するすべての子インシデントをリストした相関処理ごとに，トラップを1つ送信します。

詳細については，「25.3.3　インシデント相関処理通知」を参照してください。

削除

インシデント削除の仕様。このセクションは，［インシデント］フィールドでの選択内容に対して，削除トラップをNorthboundアプリケーションに送信するかどうかを設定します。

送信しない

NNMiは，インシデントがNNMiで削除されてもNorthboundアプリケーションに通知しません。

これがデフォルト設定です。

送信

NNMiは，NNMiで削除されるインシデントごとに，削除トラップをNorthboundアプリケーションに送信します。

詳細については，「25.3.4　インシデント削除通知」を参照してください。

NNMiコンソールアクセス

NorthboundアプリケーションからNNMiコンソールを参照するURLの接続プロトコル仕様。NNMiがNorthboundアプリケーションに送信するトラップのNmsUrl varbind（1.3.6.1.4.1.11.2.17.19.2.2.2）には，NNMi URLが含まれます。

設定ページのデフォルトは，NNMi設定と一致する設定になります。

NNMiコンソールがHTTPとHTTPS両方の接続を承認するよう設定されている場合，NNMi URLでHTTP接続プロトコルの指定を変更できます。例えば，Northboundアプリケーションのすべてのユーザーがイントラネット上にある場合は，NorthboundアプリケーションからNNMiコンソールへのアクセスをHTTP経由に設定できます。

NorthboundアプリケーションからNNMiコンソールに接続するプロトコルを変更する場合は，必要に応じて，［HTTP］オプションまたは［HTTPS］オプションを選択します。

Incident Filter（インシデントフィルター）

Northboundアプリケーションに送信されたイベントをフィルターするために統合で使用されるオブジェクトID（OID）のリスト。各フィルターエントリーは，有効な数値OID（例えば，.1.3.6.1.6.3.1.1.5.4.1.3.6.1.4.1.9）またはOIDプレフィックス（例えば，.1.3.6.1.6.3.1.1.5.*）にすることができます。

次のオプションの1つを選択します。

なし

NNMiはすべてのイベントをNorthboundアプリケーションに送信します。

これがデフォルト設定です。

含む

NNMiは，フィルターで識別されたOIDと一致する特定のイベントだけを送信します。

除外する

NNMiは，フィルターで識別されたOIDと一致する特定のイベントを除くすべてのイベントを送信します。

インシデントフィルターを指定します。

フィルターエントリーを追加するには，下側のテキストボックスにテキストを入力してから，［追加］をクリックします。

フィルターエントリーを削除するには，上側のボックスのリストからエントリーを選択して，［削除］をクリックします。

詳細については，「25.3.5　イベント転送フィルター」を参照してください。

25.8.3　NNMi Northboundインタフェース転送先のステータス情報

Northbound転送先の読み取り専用ステータス情報を次の表に示します。この情報は，統合が現在機能しているか確認する場合に役立ちます。

表25‒3　NNMi Northboundインタフェース転送先のステータス情報

フィールド

説明

トラップ転送先IPアドレス

転送先ホスト名の解決先となるIPアドレス。

この値は，このノースバウンド転送先に固有です。

アップタイム（秒）

Northboundコンポーネントが最後に起動されてからの時間（秒）。NNMiがNorthboundアプリケーションに送信するトラップのsysUptimeフィールド（1.3.6.1.2.1.1.3.0）にはこの値が含まれます。

この値は，NNMi Northboundインタフェースを使用するすべての統合に対して同じです。最新の値を表示するには，リフレッシュするか，フォームを閉じて再び開いてください。

NNMi URL

NNMiコンソールに接続するためのURL。NNMiがNorthboundアプリケーションに送信するトラップのNmsUrl varbind（1.3.6.1.4.1.11.2.17.19.2.2.2）にはこの値が含まれます。

この値は，このノースバウンド転送先に固有です。

25.8.4　NNMi Northboundインタフェースで使用されるMIB情報

特定のMIBをNNMiにロードし，NNMi Northbound統合によって送信されるインシデント通知で使用される管理情報を表示するには，次の手順を実行します。

次のディレクトリに移動する。

Windows：%NnmInstallDir%misc¥nnm¥snmp-mibs¥Vendor¥Hewlett-Packard

Linux：/opt/OV/misc/nnm/snmp-mibs/Vendor/Hewlett-Packard

次のコマンドを実行して，hp-nnmi.mibファイルをロードする。

nnmloadmib.ovpl -load hp-nnmi.mib

次のコマンドを実行して，hp-nnmi-registrations.mibファイルをロードする。

nnmloadmib.ovpl -load hp-nnmi-registrations.mib

次のコマンドを実行して，hp-nnmi-nbi.mibファイルをロードする。

nnmloadmib.ovpl -load hp-nnmi-nbi.mib

NNMiコンソールから，［設定］ワークスペースを開く。

［MIB］＞［ロード済みMIB］をクリックします。

ロードした各MIBをダブルクリックし，［MIB変数］をクリックしてMIB情報を表示します。

25.8.5　NNMi Northboundインタフェースで使用されるSNMPトラップ情報

Northboundインタフェースで使用されるSNMPトラップについては，hp-nnmi-nbi.mibファイルに定義されています。

NNMiをNorthboundアプリケーションとして使用する場合は，次の手順を実行してSNMPトラップインシデントの定義を追加してください。

「25.8.4　NNMi Northboundインタフェースで使用されるMIB情報」の手順1.から手順4.を実行する。

次のコマンドを実行して，SNMPトラップインシデントの定義を追加する。

nnmincidentcfg.ovpl -loadTraps HP-NNMI-NBI-MIB

第9編　連携編

26　JP1/IM3のインテリジェント統合管理基盤との連携

26.1　JP1/IM3のインテリジェント統合管理基盤との連携

JP1/IM3のインテリジェント統合管理基盤と連携することで，下記ができるようになります。

NNMiが管理しているノードの情報をJP1/IM3の統合オペレーション・ビューアーに表示できる

JP1/IM3の統合オペレーション・ビューアーから，NNMiのコンソール画面やノードフォーム，L2/L3近接接続ビューなどを表示できる

JP1/IM3の対処アクション提案機能によって，JP1イベント（NNMiインシデント）が発生したノードに対し，ステータスポーリングの実行やノードフォームの表示などの対処アクションを行うことができる

JP1/IM3のカスタムUI連携機能によって，JP1/IM3の統合オペレーション・ビューアー上で選択したノードのノードフォームやL2近接接続ビューを表示できる

JP1/IM3のインテリジェント統合管理基盤と連携するためには，JP1/IM3用のプラグインをセットアップする必要があります。

なお，JP1/IM2をご使用の場合は，上記のJP1/IM3をJP1/IM2に読み替えてください。

連携機能の詳細，およびセットアップ方法については，リリースノートを参照してください。

27　RESTful API

NNMiのRESTful APIを用いて，NNMiとほかの製品を連携させることができます。

27.1　RESTful API

RESTful APIでは，NNMiのインシデント，ノード，IPアドレス，およびインタフェースの情報を取得したり，更新したりできます。

ほかの製品やWebポータルなどから，RESTful APIを使用してNNMiと連携することで，ほかの製品やWebポータルでNNMiの情報を表示したり，更新したりできます。

RESTful APIの詳細については，リリースノートを参照してください。

付録

付録A　NNMiのmanページを表示できない場合（Linux)

NNMi管理サーバーにNNMiのmanページを表示できない場合は，MANPATH変数に/opt/OV/manの場所が含まれていることを確認します。含まれていない場合は，/opt/OV/manの場所をMANPATH変数に追加します。

付録B　新規インストール中に読み込むMIB一覧

次の表は，NNMiが新規インストール中に読み込むMIBを一覧で示しています。

NNMiをバージョンアップした場合は読み込まれません。

なお，表に示すMIBファイルは，次のパスからの相対パスになります。

Windows：%NnmInstallDir%misc¥nnm¥snmp-mibs¥

また，Windowsの場合，パスの区切り文字が/ではなく¥になります。

Linux：$NnmInstallDir/misc/nnm/snmp-mibs/

表B‒1　NNMiが新規インストール中に読み込むMIB

MIB名

MIBファイル

ATM-FORUM-MIB

Vendor/Cisco/ATM-FORUM-MIB.my

ATM-FORUM-TC-MIB

Vendor/Cisco/ATM-FORUM-TC-MIB.my

ATM-MIB

Standard/rfc2515-ATM-MIB.mib

ATM-TC-MIB

Standard/rfc2514-ATM-TC-MIB.mib

ATM2-MIB

Standard/rfc3606-ATM2-MIB.mib

ArcsightModule

Vendor/Hewlett-Packard/hp-arcsight.mib

BGP4-MIB

Standard/rfc4273-BGP4-MIB.mib

BRIDGE-MIB

Standard/rfc4188-BRIDGE-MIB.mib

CISCO-AAL5-MIB

Vendor/Cisco/CISCO-AAL5-MIB.my

CISCO-ATM-IF-MIB

Vendor/Cisco/CISCO-ATM-IF-MIB.my

CISCO-ATM-SWITCH-ADDR-MIB

Vendor/Cisco/CISCO-ATM-SWITCH-ADDR-MIB.my

CISCO-C2900-MIB

Vendor/Cisco/CISCO-C2900-MIB.my

CISCO-CDP-MIB

Vendor/Cisco/CISCO-CDP-MIB.my

CISCO-DOT11-ASSOCIATION-MIB

Vendor/Cisco/CISCO-DOT11-ASSOCIATION-MIB.my

CISCO-DOT11-IF-MIB

Vendor/Cisco/CISCO-DOT11-IF-MIB.my

CISCO-ENTITY-FRU-CONTROL-MIB

Vendor/Cisco/CISCO-ENTITY-FRU-CONTROL-MIB.my

CISCO-ENTITY-VENDORTYPE-OID-MIB

Vendor/Cisco/CISCO-ENTITY-VENDORTYPE-OID-MIB.my

CISCO-ENVMON-MIB

Vendor/Cisco/CISCO-ENVMON-MIB.my

CISCO-FLASH-MIB

Vendor/Cisco/CISCO-FLASH-MIB.my

CISCO-FRAME-RELAY-MIB

Vendor/Cisco/CISCO-FRAME-RELAY-MIB.my

CISCO-HSRP-MIB

Vendor/Cisco/CISCO-HSRP-MIB.my

CISCO-IETF-IP-MIB

Vendor/Cisco/CISCO-IETF-IP-MIB.my

CISCO-IETF-IPMROUTE-MIB

Vendor/Cisco/CISCO-IETF-IPMROUTE-MIB.my

CISCO-IETF-PIM-EXT-MIB

Vendor/Cisco/CISCO-IETF-PIM-EXT-MIB.my

CISCO-IETF-PIM-MIB

Vendor/Cisco/CISCO-IETF-PIM-MIB.my

CISCO-IETF-PW-ENET-MIB

Vendor/Cisco/CISCO-IETF-PW-ENET-MIB.my

CISCO-IETF-PW-MIB

Vendor/Cisco/CISCO-IETF-PW-MIB.my

CISCO-IETF-PW-MPLS-MIB

Vendor/Cisco/CISCO-IETF-PW-MPLS-MIB.my

CISCO-IETF-PW-TC-MIB

Vendor/Cisco/CISCO-IETF-PW-TC-MIB.my

CISCO-MEMORY-POOL-MIB

Vendor/Cisco/CISCO-MEMORY-POOL-MIB.my

CISCO-MVPN-MIB

Vendor/Cisco/CISCO-MVPN-MIB.my

CISCO-NBAR-PROTOCOL-DISCOVERY-MIB

Vendor/Cisco/CISCO-NBAR-PROTOCOL-DISCOVERY-MIB.my

CISCO-PIM-MIB

Vendor/Cisco/CISCO-PIM-MIB.my

CISCO-PRODUCTS-MIB

Vendor/Cisco/CISCO-PRODUCTS-MIB.my

CISCO-QOS-PIB-MIB

Vendor/Cisco/CISCO-QOS-PIB-MIB.my

CISCO-RF-MIB

Vendor/Cisco/CISCO-RF-MIB.my

CISCO-RHINO-MIB

Vendor/Cisco/CISCO-RHINO-MIB.my

CISCO-RTTMON-MIB

Vendor/Cisco/CISCO-RTTMON-MIB.my

CISCO-RTTMON-TC-MIB

Vendor/Cisco/CISCO-RTTMON-TC-MIB.my

CISCO-SMI

Vendor/Cisco/CISCO-SMI.my

CISCO-STACK-MIB

Vendor/Cisco/CISCO-STACK-MIB.my

CISCO-TC

Vendor/Cisco/CISCO-TC.my

CISCO-VTP-MIB

Vendor/Cisco/CISCO-VTP-MIB.my

CISCOWAN-SMI

Vendor/Cisco/CISCOWAN-SMI.my

DHCP-MIB

Vendor/Microsoft/dhcp.mib

DIFFSERV-DSCP-TC

Standard/rfc3289-DIFFSERV-DSCP-TC.mib

DIFFSERV-MIB

Standard/rfc3289-DIFFSERV-MIB.mib

DISMAN-NSLOOKUP-MIB

Standard/rfc4560-DISMAN-NSLOOKUP-MIB.mib

DISMAN-PING-MIB

Standard/rfc4560-DISMAN-PING-MIB.mib

DISMAN-TRACEROUTE-MIB

Standard/rfc4560-DISMAN-TRACEROUTE-MIB.mib

DRAFT-MSDP-MIB

Vendor/Cisco/MSDP-MIB.my

DS1-MIB

Standard/rfc4805-DS1-MIB.mib

DS3-MIB

Standard/rfc3896-DS3-MIB.mib

DVMRP-MIB

Vendor/Nortel/DVMRP-MIB.mib

ENTITY-MIB

Standard/rfc4133-ENTITY-MIB.mib

ENTITY-STATE-MIB

Standard/rfc4268-ENTITY-STATE-MIB.mib

ENTITY-STATE-TC-MIB

Standard/rfc4268-ENTITY-STATE-TC-MIB.mib

EXTREME-BASE-MIB

Vendor/Extreme/v730b49.mib

EXTREME-CABLE-MIB

Vendor/Extreme/v730b49.mib

EXTREME-DLCS-MIB

Vendor/Extreme/v730b49.mib

EXTREME-DOS-MIB

Vendor/Extreme/v730b49.mib

EXTREME-EAPS-MIB

Vendor/Extreme/v730b49.mib

EXTREME-EDP-MIB

Vendor/Extreme/v730b49.mib

EXTREME-ENH-DOS-MIB

Vendor/Extreme/v730b49.mib

EXTREME-ESRP-MIB

Vendor/Extreme/v730b49.mib

EXTREME-FDB-MIB

Vendor/Extreme/v730b49.mib

EXTREME-FILETRANSFER-MIB

Vendor/Extreme/v730b49.mib

EXTREME-NETFLOW-MIB

Vendor/Extreme/v730b49.mib

EXTREME-NP-MIB

Vendor/Extreme/v730b49.mib

EXTREME-OSPF-MIB

Vendor/Extreme/v730b49.mib

EXTREME-PBQOS-MIB

Vendor/Extreme/v730b49.mib

EXTREME-POE-MIB

Vendor/Extreme/v730b49.mib

EXTREME-PORT-MIB

Vendor/Extreme/v730b49.mib

EXTREME-POS-MIB

Vendor/Extreme/v730b49.mib

EXTREME-QOS-MIB

Vendor/Extreme/v730b49.mib

EXTREME-RTSTATS-MIB

Vendor/Extreme/v730b49.mib

EXTREME-SERVICES-MIB

Vendor/Extreme/v730b49.mib

EXTREME-SLB-MIB

Vendor/Extreme/v730b49.mib

EXTREME-SNMPV3-MIB

Vendor/Extreme/v730b49.mib

EXTREME-STP-EXTENSIONS-MIB

Vendor/Extreme/v730b49.mib

EXTREME-SYSTEM-MIB

Vendor/Extreme/v730b49.mib

EXTREME-TRAP-MIB

Vendor/Extreme/v730b49.mib

EXTREME-TRAPPOLL-MIB

Vendor/Extreme/v730b49.mib

EXTREME-V2TRAP-MIB

Vendor/Extreme/v730b49.mib

EXTREME-VC-MIB

Vendor/Extreme/v730b49.mib

EXTREME-VLAN-MIB

Vendor/Extreme/v730b49.mib

EXTREME-WIRELESS-MIB

Vendor/Extreme/v730b49.mib

EXTREMEdot11AP-MIB

Vendor/Extreme/v730b49.mib

EXTREMEdot11f-MIB

Vendor/Extreme/v730b49.mib

EtherLike-MIB

Standard/rfc3635-EtherLike-MIB.mib

FDDI-SMT73-MIB

Standard/Historic/rfc1512-FDDI-SMT73-MIB.mib

FOUNDRY-SN-ROOT-MIB

Vendor/Foundry/FOUNDRY-SN-ROOT-MIB.mib

FRAME-RELAY-DTE-MIB

Standard/rfc2115-FRAME-RELAY-DTE-MIB.mib

FtpServer-MIB

Vendor/Microsoft/ftp.mib

HC-RMON-MIB

Standard/rfc3273-HC-RMON-MIB.mib

HCNUM-TC※

NNM/server/lib/nms-mib-model.jar/com/hp/ov/nms/mib/model/hibernate/rfc2856-HCNUM-TC.mib

HOST-RESOURCES-MIB

Standard/rfc2790-HOST-RESOURCES-MIB.mib

HOST-RESOURCES-TYPES

Standard/rfc2790-HOST-RESOURCES-TYPES.mib

HP-ICF-OID

Vendor/Hewlett-Packard/ProCurve/hpicfOid.mib

HP-SITESCOPE-MIB

Vendor/Hewlett-Packard/HP-SITESCOPE-MIB.mib

HP-SN-AGENT-MIB

Vendor/Hewlett-Packard/hpEtherSwitch/hp-sn-agent.mib

HP-SN-ROOT-MIB

Vendor/Hewlett-Packard/hpEtherSwitch/hp-sn-root.mib

HP-SN-SWITCH-GROUP-MIB

Vendor/Hewlett-Packard/hpEtherSwitch/hp-sn-switch.mib

HP-UNIX

Vendor/Hewlett-Packard/hp-unix

HttpServer-MIB

Vendor/Microsoft/http.mib

IANA-ADDRESS-FAMILY-NUMBERS-MIB

Standard/IANA-ADDRESS-FAMILY-NUMBERS-MIB.mib

IANA-MAU-MIB

Standard/rfc4836-IANA-MAU-MIB.mib

IANA-RTPROTO-MIB

Vendor/Cisco/IANA-RTPROTO-MIB.my

IANATn3270eTC-MIB

Standard/IANATn3270eTC-MIB.mib

IANAifType-MIB

Standard/IANAifType-MIB.mib

IEEE8021-TC-MIB

IEEE/IEEE8021-TC-MIB.mib

IEEE8023-LAG-MIB

IEEE/IEEE8023-LAG-MIB.mib

IEEE802dot11-MIB

IEEE/IEEE802dot11-MIB.mib

IF-MIB

Standard/rfc2863-IF-MIB.mib

IGMP-MIB

Vendor/Cisco/IGMP-MIB.my

IGMP-STD-MIB

Vendor/Cisco/IGMP-STD-MIB.my

INET-ADDRESS-MIB

Standard/rfc4001-INET-ADDRESS-MIB.mib

INTEGRATED-SERVICES-MIB

Standard/rfc2213-INTEGRATED-SERVICES-MIB.mib

IP-FORWARD-MIB

Standard/rfc4292-IP-FORWARD-MIB.mib

IP-MIB

Standard/rfc4293-IP-MIB.mib

IPMCAST-MIB

Standard/rfc5132-IPMCAST-MIB.mib

IPMROUTE-MIB

Vendor/Cisco/IPMROUTE-MIB.my

IPMROUTE-STD-MIB

Vendor/Cisco/IPMROUTE-STD-MIB.my

IPV6-FLOW-LABEL-MIB

Standard/rfc3595-IPV6-FLOW-LABEL-MIB.mib

IPV6-MIB

Standard/rfc2465-IPV6-MIB.mib

IPV6-TC

Standard/rfc2465-IPV6-TC.mib

ISDN-MIB

Standard/rfc2127-ISDN-MIB.mib

InternetServer-MIB

Vendor/Microsoft/inetsrv.mib

JUNIPER-CHASSIS-DEFINES-MIB

Vendor/Juniper/mib-jnx-chas-defines

JUNIPER-JS-IF-EXT-MIB

Vendor/Juniper/mib-jnx-js-if-ext

JUNIPER-JS-SMI

Vendor/Juniper/mib-jnx-js-smi

JUNIPER-MIB

Vendor/Juniper/mib-jnx-chassis

JUNIPER-SMI

Vendor/Juniper/mib-jnx-smi

JUNIPER-V1-TRAPS

Vendor/Juniper/v1_traps

JUNIPER-VPN-MIB

Vendor/Juniper/mib-jnx-vpn

Juniper-MIBs

Vendor/Juniper/Juniper-MIBs.mib

Juniper-UNI-SMI

Vendor/Juniper/Juniper-UNI-SMI.mib

LANGTAG-TC-MIB

Standard/rfc5131-LANGTAG-TC-MIB.mib

LLDP-MIB

IEEE/lldp.mib

LanMgr-Mib-II-MIB

Vendor/Microsoft/lmmib2.mib

MAU-MIB

Standard/rfc4836-MAU-MIB.mib

MGMD-STD-MIB

Standard/rfc5519-MGMD-STD-MIB.mib

MPLS-L3VPN-STD-MIB

Standard/rfc4382-MPLS-L3VPN-STD-MIB.mib

MPLS-LSR-MIB

Vendor/Cisco/MPLS-LSR-MIB.my

MPLS-LSR-STD-MIB

Standard/rfc3813-MPLS-LSR-STD-MIB.mib

MPLS-MIB

Vendor/Juniper/mib-jnx-mpls

MPLS-TC-STD-MIB

Standard/rfc3811-MPLS-TC-STD-MIB.mib

MPLS-TE-MIB

Vendor/Cisco/MPLS-TE-MIB.my

MPLS-TE-STD-MIB

Standard/rfc3812-MPLS-TE-STD-MIB.mib

MPLS-VPN-MIB

Vendor/Cisco/MPLS-VPN-MIB.my

MSDP-MIB

Vendor/Nortel/MSDP-MIB.mib

Nortel-Magellan-Passport-StandardTextualConventionsMIB

Vendor/Nortel/Nortel-Magellan-Passport-StandardTextualConventionsMIB.mib

Nortel-Magellan-Passport-TextualConventionsMIB

Vendor/Nortel/Nortel-Magellan-Passport-TextualConventionsMIB.mib

Nortel-Magellan-Passport-UsefulDefinitionsMIB

Vendor/Nortel/Nortel-Magellan-Passport-UsefulDefinitionsMIB.mib

Nortel-MsCarrier-MscPassport-StandardTextualConventionsMIB

Vendor/Nortel/Nortel-MsCarrier-MscPassport-StandardTextualConventionsMIB.mib

Nortel-MsCarrier-MscPassport-TextualConventionsMIB

Vendor/Nortel/Nortel-MsCarrier-MscPassport-TextualConventionsMIB.mib

Nortel-MsCarrier-MscPassport-UsefulDefinitionsMIB

Vendor/Nortel/Nortel-MsCarrier-MscPassport-UsefulDefinitionsMIB.mib

OLD-CISCO-CHASSIS-MIB

Vendor/Cisco/OLD-CISCO-CHASSIS-MIB.my

OLD-CISCO-INTERFACES-MIB

Vendor/Cisco/OLD-CISCO-INTERFACES-MIB.my

OLD-CISCO-SYS-MIB

Vendor/Cisco/OLD-CISCO-SYS-MIB.my

OSPF-MIB

Standard/rfc4750-OSPF-MIB.mib

P-BRIDGE-MIB

Standard/rfc4363-P-BRIDGE-MIB.mib

PIM-MIB

Vendor/Cisco/PIM-MIB.my

PIM-STD-MIB

Standard/rfc5060-PIM-STD-MIB.mib

POWER-ETHERNET-MIB

Standard/rfc3621-POWER-ETHERNET-MIB.mib

PerfHist-TC-MIB

Standard/rfc3593-PerfHist-TC-MIB.mib

Q-BRIDGE-MIB

Standard/rfc4363-Q-BRIDGE-MIB.mib

RAPID-CITY

Vendor/Nortel/RAPID-CITY.mib

RFC-1212※

NNM/server/lib/nms-mib-model.jar/com/hp/ov/nms/mib/model/hibernate/rfc1212-RFC1212.mib

RFC-1215

Standard/rfc1215-RFC1215.mib

RFC1155-SMI※

NNM/server/lib/nms-mib-model.jar/com/hp/ov/nms/mib/model/hibernate/rfc1155-RFC1155-SMI.mib

RFC1213-MIB※

NNM/server/lib/nms-mib-model.jar/com/hp/ov/nms/mib/model/hibernate/rfc1213-RFC1213-MIB.mib

RFC1271-MIB※

NNM/server/lib/nms-mib-model.jar/com/hp/ov/nms/mib/model/hibernate/rfc1271-RFC1271-MIB.mib

RFC1315-MIB

Standard/rfc1315-RFC1315-MIB.mib

RIPv2-MIB

Standard/rfc1724-RIPv2-MIB.mib

RMON-MIB

Standard/rfc2819-RMON-MIB.mib

RMON2-MIB

Standard/rfc4502-RMON2-MIB.mib

RS-232-MIB

Standard/rfc1659-RS-232-MIB.mib

SMON-MIB

Standard/rfc2613-SMON-MIB.mib

SNMP-FRAMEWORK-MIB

Standard/rfc3411-SNMP-FRAMEWORK-MIB.mib

SNMP-REPEATER-MIB

Standard/rfc2108-SNMP-REPEATER-MIB.mib

SNMP-TARGET-MIB

Standard/rfc3413-SNMP-TARGET-MIB.mib

SNMP-VIEW-BASED-ACM-MIB

Standard/rfc3415-SNMP-VIEW-BASED-ACM-MIB.mib

SNMPv2-CONF※

NNM/server/lib/nms-mib-model.jar/com/hp/ov/nms/mib/model/hibernate/rfc1904-SNMPv2-CONF.mib

SNMPv2-MIB※

NNM/server/lib/nms-mib-model.jar/com/hp/ov/nms/mib/model/hibernate/rfc3418-SNMPv2-MIB.mib

SNMPv2-SMI※

NNM/server/lib/nms-mib-model.jar/com/hp/ov/nms/mib/model/hibernate/rfc2578-SNMPv2-SMI.mib

SNMPv2-TC※

NNM/server/lib/nms-mib-model.jar/com/hp/ov/nms/mib/model/hibernate/rfc2579-SNMPv2-TC.mib

SONET-MIB

Standard/rfc3592-SONET-MIB.mib

TOKEN-RING-RMON-MIB

Standard/Historic/rfc1513-TOKEN-RING-RMON-MIB.mib

TRANSPORT-ADDRESS-MIB

Standard/rfc3419-TRANSPORT-ADDRESS-MIB.mib

TUNNEL-MIB

Standard/rfc4087-TUNNEL-MIB.mib

VMWARE-AGENTCAP-MIB

Vendor/VMware/VMWARE-AGENTCAP-MIB.mib

VMWARE-ENV-MIB

Vendor/VMware/VMWARE-ENV-MIB.mib

VMWARE-OBSOLETE-MIB

Vendor/VMware/VMWARE-OBSOLETE-MIB.mib

VMWARE-PRODUCTS-MIB

Vendor/VMware/VMWARE-PRODUCTS-MIB.mib

VMWARE-RESOURCES-MIB

Vendor/VMware/VMWARE-RESOURCES-MIB.mib

VMWARE-ROOT-MIB

Vendor/VMware/VMWARE-ROOT-MIB.mib

VMWARE-SYSTEM-MIB

Vendor/VMware/VMWARE-SYSTEM-MIB.mib

VMWARE-TC-MIB

Vendor/VMware/VMWARE-TC-MIB.mib

VMWARE-VC-EVENT-MIB

Vendor/VMware/VMWARE-VC-EVENT-MIB.mib

VMWARE-VMINFO-MIB

Vendor/VMware/VMWARE-VMINFO-MIB.mib

VPN-TC-STD-MIB

Standard/rfc4265-VPN-TC-STD-MIB.mib

VRRP-MIB

Standard/rfc2787-VRRP-MIB.mib

WINDOWS-NT-PERFORMANCE

Vendor/Microsoft/WINDOWS-NT-PERFORMANCE.mib

WINS-MIB

Vendor/Microsoft/wins.mib

X-DDI-MIB

Vendor/Nortel/x-ddi-adapter-mib

XYLAN-BASE-MIB

Vendor/OTHER-VENDORS/XYLAN-BASE-MIB.mib

XYLAN-HEALTH-MIB

Vendor/OTHER-VENDORS/XYLAN-HEALTH-MIB.mib

注※　一部のMIBファイルは，jarファイルに含まれています。表中のMIBファイルは，次に示すjarファイル内での相対パスとなります。

Windows：%NnmInstallDir%NNM¥server¥lib¥nms-mib-model.jar

Linux：$NnmInstallDir/NNM/server/lib/nms-mib-model.jar

付録C　NNMi環境変数

NNMiには，ファイルシステム内の移動やスクリプトの作成に使用できる多数の環境変数があります。

付録C.1　マニュアルで使用する環境変数

このマニュアルでは，主に次の2つのNNMi環境変数を使用して，ファイルやディレクトリの場所を参照します。次に示す変数はデフォルト値です。実際の値は，NNMiのインストール時に行った選択内容によって異なります。

Windows

−%NnmInstallDir%: <drive>:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥

−%NnmDataDir%: <drive>:¥ProgramData¥Hitachi¥Cm2NNMi¥

メモ

Windowsシステムでは，NNMiのインストールプロセスによってこれらのシステム環境変数が作成されるため，すべてのユーザーがいつでも使用できます。

重要

パス名にスペースを含む場合，必ずクォート（""）で囲んでください。

（例）

"%NnmInstallDir%bin¥ovstatus" -c

Linux

−$NnmInstallDir: /opt/OV

−$NnmDataDir: /var/opt/OV

メモ

Linuxシステムでは，これらの環境変数を使用する場合は手動で作成する必要があります。

また，このドキュメントには，NNMi管理サーバーでユーザーログオン設定を行うときに使用するNNMi環境変数も一部掲載されています。これらの変数の形式はNNM_*です。NNMi環境変数の詳細リストについては，「付録C.2　ほかの使用可能な環境変数」を参照してください。

付録C.2　ほかの使用可能な環境変数

NNMi管理者は，NNMiのファイルには定期的にアクセスします。NNMiには，通常アクセスする場所へ移動するための環境変数を設定するスクリプトが用意されています。

NNMi環境変数の拡張リストをセットアップするには，次の例のようなコマンドを使用します。

Windows

"%NnmInstallDir%bin¥nnm.envvars.bat"

Linux

. /opt/OV/bin/nnm.envvars.sh

「.」と「/」の間には必ず空白を入れてください。

上記の各OS用のコマンドを実行したあとで，表C-1（Windows）または表C-2（Linux）で示すNNMi環境変数を使用して，頻繁に使用するNNMiファイルの場所へ移動できます。

表C‒1　Windows OSでの環境変数のデフォルトの場所

変数

Windows（例）

%NNM_BIN%

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥bin

%NNM_CONF%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥Conf

%NNM_DATA%

C:¥ProgramData¥Hitachi¥Cm2NNMi

%NNM_DB%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥shared¥nnm¥databases

%NNM_JAVA%

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥nonOV¥jdk¥hpsw¥bin¥java.exe

%NNM_JAVA_DIR%

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥java

%NNM_JBOSS%

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥nmsas

%NNM_JBOSS_DEPLOY%

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥nmsas¥server¥nms¥deploy

%NNM_JBOSS_LOG%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥log¥nnm

%NNM_JBOSS_SERVERCONF%

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥nmsas¥server¥nms

%NNM_JRE%

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥nonOV¥jdk¥hpsw

%NNM_LOG%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥log

%NNM_LRF%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥shared¥nnm¥lrf

%NNM_PRIV_LOG%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥log

%NNM_PROPS%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥shared¥nnm¥conf¥props

%NNM_SHARED_CONF%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥shared¥nnm¥conf

%NNM_SHARE_LOG%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥log

%NNM_SNMP_MIBS%

C:¥Program Files (x86)¥Hitachi¥Cm2NNMi¥misc¥nnm¥snmp-mibs

%NNM_TMP%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥tmp

%NNM_USER_SNMP_MIBS%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥shared¥nnm¥user-snmp-mibs

%NNM_WWW%

C:¥ProgramData¥Hitachi¥Cm2NNMi¥shared¥nnm¥www

表C‒2　Linux OSでの環境変数のデフォルトの場所

変数

Linux（例）

$NNM_BIN

/opt/OV/bin

$NNM_CONF

/var/opt/OV/conf

$NNM_DATA

/var/opt/OV

$NNM_DB

/var/opt/OV/shared/nnm/databases

$NNM_JAVA

/opt/OV/nonOV/jdk/hpsw/bin/java

$NNM_JAVA_DIR

/opt/OV/java

$NNM_JBOSS

/opt/OV/nmsas

$NNM_JBOSS_DEPLOY

/opt/OV/nmsas/server/nms/deploy

$NNM_JBOSS_LOG

/var/opt/OV/log/nnm

$NNM_JBOSS_SERVERCONF

/opt/OV/nmsas/server/nms

$NNM_JRE

/opt/OV/nonOV/jdk/hpsw

$NNM_LOG

/var/opt/OV/log

$NNM_LRF

/var/opt/OV/shared/nnm/lrf

$NNM_PRIV_LOG

/var/opt/OV/log

$NNM_PROPS

/var/opt/OV/shared/nnm/conf/props

$NNM_SHARED_CONF

/var/opt/OV/shared/nnm/conf

$NNM_SHARE_LOG

/var/opt/OV/log

$NNM_SNMP_MIBS

/opt/OV/misc/nnm/snmp-mibs

$NNM_USER_SNMP_MIBS

/var/opt/OV/shared/nnm/user-snmp-mibs

$NNM_TMP

/var/opt/OV/tmp

$NNM_WWW

/var/opt/OV/shared/nnm/www

付録D　Causal EngineとNNMiインシデント

通信とデータネットワークは規模と複雑さが著しく伸び，発生する障害の数も増えています。障害が1つ発生しただけでもたくさんの警報が発生することもあり，ネットワークオペレータにとっての障壁は，あらゆる逸話的警報の中から本当の問題を見分けることになりました。従来のイベント相関システムによって警報の数を減らすことはできましたが，これらのシステムは根本原因を自動化された方法で突き止めるという点で劣る傾向があります。

NNMi Causal Engine技術は，因果関係ベースのアプローチを使用して，根本原因解析（RCA）をネットワーク症状に適用します。

付録D.1　因果関係解析−高度な考察

Causal Engine技術によって，次の高度な機能が可能になります。

NmsApa jbossサービスを使用して，ネットワークを解析する

RCAへのモデルベースのアプローチ

−管理対象オブジェクト同士の間の行動的関連をモデル化する

−イベント因果関係に加えてオブジェクトモデルを使用して解析を進める

−根本原因と影響を判定する

−MINCAUSEアルゴリズムをベースにする

−あいまい性および部分的症状に対処可能である

動的

−解析中に症状を積極的に誘発させる

−トポロジの変化に動的に反応する

拡張性

−モジュールの階層を採用する（インポート／エクスポート）

−ネットワーク障害のエンドツーエンドの診断を提供する

−将来の製品でのルールセット追加を可能にする

付録D.2　Causal Engineの概念

Causal Engine技術では，次の逐次的アプローチを使用します。

根本原因問題と症状を形式的に定義する。

モデルを使用して症状を根本原因問題に関連づけることで，解析を行う。

症状の源は，次の2つです。

StatePoller（症状が状態の変化の場合）

イベント（症状がトラップの場合）

根本原因に関連する結論を生み出す。

Causal Engineの結論には，モデルに関連したアーチファクト（成果物）が含まれています。アーチファクトには，次の詳細が含まれます。

インシデント発生

インシデント相関

インシデント抑制

インシデント中止

関連するオブジェクトのステータス

付録D.3　ステータスの概念

インシデント操作に加えて，NmsApaサービスは関連オブジェクトのステータスを設定します。ステータスはオブジェクトの状態全般を示すために使用され，未解決結論の結果として計算されます。どの結論にも重大度が関連づけられてあり，報告されるステータスはすべての未解決結論のうちで最も深刻なものになります。さらに，結論はユーザーに，オブジェクトのステータスについての根本原因（つまり理由）を知らせます。

NmsApaサービスは，次のオブジェクトを管理します。

SNMPエージェント

IPv4アドレス

インタフェース

接続

ノード

ノードグループ

NmsApaサービスは，重大度の高いものから順に次のステータスカテゴリを使用します。

不明

使用不可

危険域

重要警戒域

警戒域

注意域

正常域

ステータスなし

付録D.4　エピソードとは

NmsApaサービスの目標は，オペレータやネットワークエンジニアが対処できるたった1つのインシデントを提示することです。そのために，NmsApaサービスはエピソードの概念を使用します。エピソードは特定の期間存在し，その間に2番目の障害は設定に基づいて相関付けられるか抑制されます。

例

AddressNotRespondingインシデントは，InterfaceDownインシデントによって，次のシナリオに従って抑制されます。

IPv4アドレスがICMPへの応答を停止すると，エピソードが開始して60秒間存続します。

その期間内に，IPv4アドレスに関連づけられたインタフェースが停止すると，NmsApaサービスはインタフェース停止状態が原因でIPv4アドレスが応答を停止したと結論付けます。

したがって，AddressNotRespondingインシデントは発生しません。InterfaceDownインシデントだけが発生します。

InterfaceDownインシデントがその期間内に検出されるようにするために，NmsApaサービスは指定ポーリングをそのインタフェースに対して発行します。これによってネットワークエンジニアは，問題の根本原因（この場合はインタフェース）を修正できるようになります。

インタフェースがエピソード中に停止しない場合，NmsApaサービスはAddressNotRespondingインシデントを発生します。インタフェースがエピソード後に停止すると，InterfaceDownインシデントが発生します。この場合，ネットワークエンジニアは2つの問題に個々に対処しなければなりません。

NodeDownインシデントは，1ホップネイバー（隣接）インタフェースからのInterfaceDownインシデントを，次のシナリオに従って相関付けします。

インタフェースが停止すると，NodeDownエピソードが隣接ノードに対して開始され，300秒間存続します。

その期間内に，ノードが停止すると，InterfaceDownインシデントがNodeDownインシデントの下で相関付けされます。

すべての1ホップネイバーからのInterfaceDownインシデントがNodeDownインシデントの下に相関付けされます。InterfaceDownインシデントを，NodeDownインシデントを裏付ける証拠として検討できます。

付録D.5　NNMiは何を解析するのか？

NNMiはSNMPプロトコルを使用して管理対象ノードから情報を，SNMPエージェント（管理対象ノードで稼働しているプロセスで，管理機能を提供する）を使用して取得します。SNMPエージェントは，管理対象ノード上のインタフェースおよびポートを管理し，1つ以上のノードと関連づけが可能です。

SNMPエージェントに関連づけられた可能なNNMiステータスカテゴリの一覧を次に示します。

不明−適用不可。

使用不可−適用不可。

危険域−SNMPエージェントはSNMPクエリーに応答しません。

警戒域−適用不可。

注意域−適用不可。

正常域−SNMPエージェントはSNMPクエリーに応答します。

ステータスなし−SNMPエージェントはポーリングされません。

IPv4アドレスは，ICMPに応答するルーティング可能なアドレスです。IPv4アドレスは，通常はノードに関連づけされます。NNMiは，ノードのステータスを次のように報告します。

不明−適用不可。

使用不可−このIPv4アドレスに関連づけられたインタフェースは管理できないまたは使用不可にされています。

危険域−IPv4アドレスはICMPクエリーに応答しません（デバイスをpingします）。

警戒域−適用不可。

注意域−適用不可。

正常域−IPv4アドレスはICMPクエリーに応答します。

ステータスなし−IPv4アドレスはポーリングされません。

インタフェースとは，ノードをネットワークに接続するために使用する物理的なポートです。NNMiはインタフェースのステータスを次のように報告します。

不明−インタフェースに関連づけられたSNMPエージェントは，SNMPクエリーに応答しません。不明は，NmsApaサービスが，ifAdminStatusとifOperStatusを測定できないため，稼働状況を判定できないことを示します。

使用不可−インタフェースは管理できません（ifAdminStatus=down）。

危険域−インタフェースは操作できません（ifOperStatus=down）。

警戒域−適用不可。

注意域−適用不可。

正常域−インタフェースは操作可能です（ifOperStatus=up）。

ステータスなし−インタフェースはポーリングされていません。

ノードとは，NNMiがスパイラル検出プロセスの結果として見つけ出すデバイスです。ノードには，インタフェース，ボード，およびポートを含むことができます。ノードは，次の2つのカテゴリに分けることができます。

ネットワークノード：スイッチ，ルーター，ブリッジおよびハブなどのアクティブデバイス

エンドノード：LinuxサーバーやWindowsサーバーなど

NNMiは通常はネットワークノードを管理し，ノードステータスを次のように報告します。

不明−ノードに関連したSNMPエージェントはSNMPクエリーに応答せず，ポーリングしたIPv4アドレスはICMPクエリーに応答しません。これは，NNMiがノードを管理できないことを示します。

使用不可−適用不可。

危険域−次のどれかになります。

ノードは，隣接解析の決定によって停止しています。

ノードは重要とマークされており，管理が困難です（ノードにNNMiサーバーからアクセスできません）。

ノードはアイランドであり（近隣ノードがない），そのため管理が困難です。

NmsApaサービスは，ノードが停止しているか，または着信接続が停止しているかを判定できません。

警戒域−次のどれかになります。

ノードに関連づけられたSNMPエージェントは，SNMPクエリーに応答しません。

ノード内の1つ以上のインタフェースが停止しています。

ノード上の1つ以上のIPv4アドレスがICMPに応答していません。

注意域−適用不可。

正常域−ノードのSNMPエージェント，ポーリングしたインタフェース，およびポーリングしたIPv4アドレスは稼働しています。

ステータスなし−ノードのSNMPエージェント，すべてのインタフェース，およびすべてのIPv4アドレスはポーリングされていません。

接続はレイヤー2物理接続とレイヤー3ネットワーク接続です。NNMiは，転送データベース（FDB）表をほかのネットワークデバイスから読み取り，CDPやEDPなどの検出プロトコルをサポートするデバイスを使用することで，接続情報を検出します。NNMiは接続のステータスを，次のように報告します。

不明−接続のすべてのエンドポイントが不明なステータスを持っています。

使用不可−接続のどれか1つのエンドポイントが使用不可です。

危険域−すべてのエンドポイントは操作できません。

警戒域−エンドポイントのどれか1つが停止しています。

注意域−エンドポイントは，不明だが危険でないステータスを持っています。

正常域−すべてのエンドポイントは，操作可能です。

ステータスなし−どれか1つのエンドポイントがポーリングされません。

ノードグループはノードの論理的コレクションで，ポーリング設定を分離するために使用します。管理者は，ノードタイプのグループ化を作成します。例えばルーターなど一部のノードは業務上絶対不可欠であるため，これらのルーターはより頻繁にポーリングするのがよいでしょう。そのためには，重要なルーターが入ったノードグループを定義して，これらのグループによって短いポーリングサイクルを設定します。

NNMiは，ノードグループのステータスを次のように報告します。

不明−グループ内のすべてのノードが不明なステータスを持っています。

使用不可−適用不可。

危険域−グループ内のすべてのノードが危険なステータスを持っています。

警戒域−グループ内の1つ以上のノードが危険なステータスを持っています。

注意域−ノードは，不明だが危険でないステータスを持っています。

正常域−グループ内のすべてのノードが正常なステータスを持っています。

ステータスなし−グループ内のすべてのノードがステータスを持っていません。

付録D.6　失敗のシナリオは何ですか？

次のシナリオは，ネットワークでの問題の例と，Causal Engineがこれらの問題を診断するために行う作業を示しています。これらのシナリオが示すインシデントの例をほかの例とともに次の表に示します。

表D‒1　インシデントの定義

インシデント名

説明

AddressNotResponding

IPv4アドレスはICMPに応答していません。次の理由が考えられます。

ノードが停止している。

デバイス（ルーターなど）の設定に誤りがあるため，幾つかのIPv4アドレスに到達できない。

InterfaceDown

インタフェースの動作状態が停止中であることを意味します。

ConnectionDown

接続の末端部の両方（またはすべて）が停止しています。

NodeDown

このインシデントは，NmsApaサービスが次の解析に基づいてノードが停止していると判定したことを示しています。

このノードに割り当てられているIPv4アドレスの100%が到達できない。

このマシンにインストールされているSNMPエージェントが応答していない。少なくとも2つの隣接デバイスが到達可能であり，このノードへの接続性について問題を報告している。

NodeOrConnectionDown

このインシデントは，ノードがICMPまたはSNMPクエリーに応答していないことを示します。また，隣接インタフェースが1つだけ停止しているため，ノードが停止しているのか接続が停止しているのかNmsApaサービスが判断できないことを示しています。

(1)　SNMPエージェントがSNMPクエリーに応答しない

シナリオ：SNMPエージェントが応答していません。例えば，このSNMPエージェントのコミュニティ文字列が変更され，NNMiの通信設定がまだ更新されていないが，ノードが稼働しています（IPv4アドレスをping可能です）。

根本原因：SNMPエージェントが応答していません。

インシデント：SNMPAgentNotRespondingインシデントが発生しました。

ステータス：SNMPエージェントが危険な状態です。

結論：SNMPAgentNotResponding

結果：ノードステータスは警戒域であり，ノードについての結論はUnresponsiveAgentInNodeです。ポーリングされたすべてのインタフェースは，NNMiで管理できないため，不明ステータスです。各インタフェースについての結論はInterfaceUnmanageableです。

(2)　SNMPエージェントがSNMPクエリーに応答している

シナリオ：このシナリオは，「(1)　SNMPエージェントがSNMPクエリーに応答しない」のシナリオに続いています。NNMi管理者が通信設定を更新して新しいコミュニティ文字列を含めることを想定します。管理対象ノードのSNMPエージェントがSNMPクエリーへの応答を開始します。

根本原因：SNMPエージェントが応答しています。

インシデント：発生なし。SNMPAgentNotRespondingインシデントがクローズしました。

ステータス：SNMPエージェントは正常な状態です。

結論：SNMPAgentResponding

結果：ノードステータスは正常域であり，ノードについての結論はResponsiveAgentInNodeです。InterfaceUnmanageableはポーリングされたすべてのインタフェースから除去されて，インタフェースは前のステータスに戻ります。

(3)　IPv4アドレスがICMPに応答しない

シナリオ：S1のIPv4アドレス1が応答していません。例えば，ルーター1（R1）の経路がインタフェース1からインタフェース2に変わったことによって，S1のインタフェース1を宛て先としていたパケットが現在はR1のインタフェース2からルーティングされていると想定します。関連づけられているインタフェースは稼働しており，幾つかのIPv4アドレスをpingできるので，ノードは到達可能です。SNMPエージェントは稼働しています。

根本原因：IPv4アドレスが応答していません。

インシデント：AddressNotRespondingインシデントが発生しました。

ステータス：IPv4アドレスは危険な状態です。

結論：AddressNotResponding

結果：ノードステータスは警戒域であり，ノードについての結論はSomeUnresponsiveAddressesInNodeです。

(4)　ICMPへのIPv4アドレス応答

シナリオ：このシナリオは，「(3)　IPv4アドレスがICMPに応答しない」のシナリオに続いています。IPv4アドレスが現在は応答しており，関連づけられたインタフェースが稼働しており，ノードに到達可能であることを想定してください。例えば，幾つかのIPv4アドレスをpingできたり，SNMPエージェントが稼働していたりする状況です。

根本原因：IPv4アドレスが応答しています。

インシデント：発生なし。AddressNotRespondingインシデントがクローズしました。

ステータス：IPv4アドレスは正常な状態です。

結論：AddressResponding

結果：ノードステータスは正常域であり，ノードについての結論はResponsiveAddressesInNodeです。

(5)　インタフェースを操作できない

シナリオ：R1インタフェース1は操作できず（ifOperStatus=down），管理可能（ifAdminStatus=up）です。R1はLinkDownトラップを送信します。R1は到達可能です。幾つかのIPv4アドレス（IPv4アドレス2など）をpingできるためです。SNMPエージェントは稼働しています。IPv4アドレス1はインタフェース1に関連づけられており，ICMPへの応答を停止しました。

根本原因：インタフェースは停止しています。

インシデント：InterfaceDownインシデントが発生しました。LinkDownインシデントがInterfaceDownインシデントの下に相関付けされています。

ステータス：インタフェースは危険な状態です。

結論：InterfaceDown

結果：ノードステータスは警戒域であり，ノードについての結論はInterfacesDownInNodeです。AddressNotRespondingインシデントがIPv4アドレスに関連づけられていません。

(6)　インタフェースは操作可能である

シナリオ：このシナリオは，「(5)　インタフェースを操作できない」のシナリオに続いています。R1インタフェース1が現在は操作可能であると想定します（ifOperStatus=up）。ノードは到達可能です。そのIPv4アドレスをすべてpingできます。SNMPエージェントは稼働しています。

根本原因：インタフェースは稼働しています。

インシデント：発生なし。InterfaceDownインシデントがクローズしました。

ステータス：インタフェースは正常な状態です。

結論：InterfaceUp

結果：ノードステータスは正常域であり，ノードについての結論はInterfacesUpInNodeです。

(7)　インタフェースを管理できない

シナリオ：R1インタフェース1は管理できません（ifAdminStatus=down）が，ノードは到達可能です。例えば，インタフェース2をpingしてSNMPエージェントが稼働していると想定します。R1インタフェース1を無効にすると，そのインタフェースが操作できなくなります。このインタフェースIPv4アドレス1に関連づけられたIPv4アドレスがICMPへの応答を停止します。

根本原因：R1インタフェース1は使用不可です。

インシデント：発生なし。

ステータス：インタフェースは使用不可の状態です。

結論：InterfaceDisabled

結果：R1インタフェース1に関連づけられたIPv4アドレスはステータスが使用不可です。IPv4アドレスについての結論はAddressDisabledです。

(8)　インタフェースを管理できる

シナリオ：このシナリオは，「(5)　インタフェースを操作できない」のシナリオに続いています。R1インタフェース1が現在管理可能であり（ifAdminStatus=up），そのインタフェースの幾つかのIPv4アドレスをpingすることでこのノードに到達できると想定します。SNMPエージェントは稼働しています。R1インタフェース1を有効にすることによって，操作可能になります。このインタフェースに関連づけられたIPv4アドレスがICMPへの応答を開始します。

根本原因：インタフェースは有効です。

インシデント：発生なし。

ステータス：インタフェースは正常な状態です。

結論：InterfaceEnabled

結果：R1インタフェース1に関連づけられたIPv4アドレスはステータスが有効です。IPv4アドレスについての結論はAddressEnabledです。

(9)　接続を操作できない

シナリオ：スイッチ1（IF13）に接続しているスイッチ3のインタフェースと，スイッチ3（IF31）に接続しているスイッチ1のインタフェースとの間の接続が停止しています。トラフィックは，管理サーバーからスイッチ1（SW1）とスイッチ2（SW2）を通って流れます。IF13とIF31の両方が停止とマークされます。

根本原因：IF13とIF31の間の接続が停止しています。

インシデント：ConnectionDownインシデントが発生します。IF13とIF31からのInterfaceDownインシデントはConnectionDownの下に相関付けされます。

ステータス：接続は危険な状態です。

結論：ConnectionDown

(10)　接続を操作できる

シナリオ：このシナリオは，「(9)　接続を操作できない」のシナリオに続いています。IF13とIF31の間の接続が現在稼働していると想定します。

根本原因：IF13とIF31の間の接続が稼働しています。

インシデント：発生なし。ConnectionDownインシデントがクローズしました。

ステータス：接続は正常な状態です。

結論：ConnectionUp

(11)　直接接続しているノードが停止している

シナリオ：アクセススイッチASW11，ASW12，ASW21，およびASW22は，上で示すように分散ルーターに重複して接続されていると想定します。分散ルーターDR1とDR2は相互に直接接続しています。分散ルーターDR1が停止します。

根本原因：ノードDR1が隣接解析に従って停止しています。

インシデント：NodeDownインシデントが発生しました。1ホップネイバーからのInterfaceDownインシデントがNodeDownインシデントの下に相関付けされます。

ステータス：ノードは危険な状態です。

結論：NodeDown

(12)　直接接続されたノードは稼働している

シナリオ：このシナリオは，「(11)　直接接続しているノードが停止している」のシナリオに続いています。分散ルーターDR1が復帰していると想定します。

根本原因：ノードDR1は稼働しています。

インシデント：発生なし。NodeDownインシデントがクローズしています。

ステータス：ノードは正常な状態です。

結論：NodeUp

(13)　間接接続されたノードは停止している

メモ

上記図は概念図です。実際のNNMiトポロジマップまたはワークスペースビューを示していません。

シナリオ：このシナリオは，間接接続でNNMiが媒介デバイスを検出できない場合に発生します。この例では，ルーターR1とルーターR2はNNMiトポロジマップで直接接続しているように見えますが，実際は，これらの2つのルーターは光中継器経由で間接的に接続しています（光中継器はSNMPまたはICMPのクエリーに応答しないため，NNMiによって検出されません）。

ルーターR2は到達できません。原因は，接続されたインタフェースが停止しているか，または光中継器との接続が切断されているかのどちらかです。間接的にルーターR2に接続しているルーターR1のインタフェースは，光中継器がまだ稼働中であるため，稼働中です。

根本原因：ルーターR2が隣接解析に従って停止しています。

インシデント：NodeDownインシデントが発生しました。

ステータス：ノードR2は危険な状態です。

結論：NodeDown

(14)　間接接続されたノードは稼働している

メモ

上記図は概念図です。実際のNNMiトポロジマップまたはワークスペースビューを示していません。

シナリオ：このシナリオは，「(13)　間接接続されたノードは停止している」のシナリオに続いています。失敗した接続がバックアップされて，ルーターR2が到達可能になったと想定します。

根本原因：R1とR2の間の接続が稼働しています。

インシデント：発生なし。NodeDownインシデントがクローズしました。

ステータス：ルーターR2のステータスは正常域です。接続ステータスは正常域です。

結論：NodeUp

(15)　直接接続されたノードが停止しており，シャドウを作成する

シナリオ：ルーター2（R2）が上で示すように停止します。

根本原因：ノードR2がNNMiの隣接解析に従って停止しています。

インシデント：NodeDownインシデントが発生しました。1ホップネイバーからのInterfaceDownインシデントがNodeDownインシデントの下に相関付けされます。

ステータス：ノードは危険な状態です。

結論：NodeDown

結果：すべてのアクセススイッチが到達できません。シャドウ内のすべてのノードのステータスが不明であり，各ノードについての結論がNodeUnmanageableです。

(16)　直接接続されたノードが稼働しており，シャドウを除去している

シナリオ：このシナリオは，「(15)　直接接続されたノードが停止しており，シャドウを作成する」のシナリオに続いています。図で示すようにR2が復帰していると想定します。

根本原因：ノードR2は稼働しています。

インシデント：発生なし。NodeDownインシデントがクローズしています。

ステータス：ノードは正常な状態です。

結論：NodeUp

結果：すべてのアクセススイッチが到達できるようになっています。シャドウ内のすべてのノードのステータスは正常です。

(17)　重要ノードが到達できない

シナリオ：あるノードは重要ノードグループの一部ですが，このノードが到達できなくなっています。

メモ

NmsApaサービスがノードを解析する前にノードを重要ノードグループに，追加する必要があります。ノードを重要ノードグループに追加する前に到達できなくなると，NmsApaサービスはNodeDownインシデントを発生しません。

根本原因：ノードは停止しています。NmsApaサービスは隣接解析を行いませんが，ノードが停止している理由は重要とマークされているためだけだと結論づけます。

インシデント：NodeDownインシデントが発生しました。相関インシデントは発生しません。

ステータス：ノードは危険な状態です。

結論：NodeDown

(18)　重要ノードが到達可能である

シナリオ：このシナリオは，「(17)　重要ノードが到達できない」のシナリオに続いています。重要ノードが復帰しており，到達できるようになったと想定します。

根本原因：ノードは稼働しています。

インシデント：発生なし。NodeDownインシデントがクローズしています。

ステータス：ノードは正常な状態です。

結論：NodeUp

(19)　ノードまたは接続が停止している

シナリオ：ルーター2（R2）に対して冗長性がありません。R2が停止しているか，ルーター1（R1）とR2の間の接続が停止しています。

根本原因：ノードまたは接続は停止しています。

インシデント：NodeOrConnectionDownインシデントが発生しました。このシナリオのソースノードはR2です。

ステータス：ノードは危険な状態です。接続は警戒域の状態です。

結論：NodeOrConnectionDown

(20)　ノードまたは接続が稼働している

シナリオ：このシナリオは，「(19)　ノードまたは接続が停止している」のシナリオに続いています。R2が稼働状態になったと想定します。

根本原因：NodeUp

インシデント：発生なし。NodeOrConnectionDownインシデントがクローズしました。

ステータス：ノードは正常な状態です。接続は正常な状態です。

結論：NodeUp

(21)　アイランドグループが停止している

メモ

上記図は概念図です。実際のNNMiトポロジマップまたはワークスペースビューを示していません。

シナリオ：NNMiはネットワークを2つのアイランドグループに分割しました。NNMi管理サーバーは，アイランドグループ1のノードに接続されます。アイランドグループ2は，サービスプロバイダのWANに問題が発生したため，到達できなくなっています。

メモ

アイランドグループには，そのほかのネットワークに接続されていないか，または最低限接続しているノードの高度に接続されたセットが含まれています。例えば，NNMiは，WANによって接続された地理的に分散されたサイトでエンタープライズネットワークの複数のアイランドグループを識別できます。アイランドグループはNNMiによって作成され，ユーザーは変更できません。アイランドグループに関する詳細については，NNMiヘルプのNNMiコンソールを参照してください。

根本原因：アイランドグループ2が隣接解析に従って停止しています。

インシデント：IslandGroupDownインシデントが発生しました。NNMiはインシデントのソースノードとしてアイランドグループ2から代表ノードを使用します。

ステータス：アイランドグループ2のステータスは［不明］に設定されています。アイランドグループ2のオブジェクトは不明ステータスを持っています。アイランドグループ1の接続インタフェースは，稼働WANへの接続がまだ稼働しているため，稼働しています。

結論：アイランドグループへの適用不可

(22)　アイランドグループが稼働している

メモ

上記図は概念図です。実際のNNMiトポロジマップまたはワークスペースビューを示していません。

シナリオ：このシナリオは，「(21)　アイランドグループが停止している」のシナリオに続いています。サービスプロバイダのWAN問題が修正され，アイランドグループ2が到達可能になったと想定します。

根本原因：アイランドグループ2へのWAN接続はバックアップです。

インシデント：発生なし。IslandGroupDownインシデントがクローズしました。

ステータス：アイランドグループ2のステータスは［正常域］に設定されています。アイランドグループ2のオブジェクトは正常域ステータスに戻ります。

結論：アイランドグループへの適用不可

(23)　リンク集約ポート（NNMi Advanced）

アグリゲーターが動作中

シナリオ：ポートアグリゲーター内のすべてのポートが運用上および管理上，動作中です。

根本原因：すべての操作および管理の状態が動作中です。

インシデント：インシデントは生成されません。

ステータス：アグリゲーターのステータスは［正常域］に設定されています。

結論：AggregatorUp

アグリゲーターの性能が低下している

シナリオ：ポートアグリゲーター内の一部（すべてではない）のポートが運用上停止しています。

根本原因：一部のポートの運用状態が停止中です。

インシデント：AggregatorDegradedインシデントが生成されます。

ステータス：アグリゲーターのステータスは［警戒域］に設定されています。

結論：AggregatorDegraded

アグリゲーターが機能を停止している

シナリオ：ポートアグリゲーター内のすべてのポートが運用上停止しています。

根本原因：すべてのポートの運用状態が停止中です。

インシデント：AggregatorDownインシデントが生成されます。

ステータス：アグリゲーターのステータスは［危険域］に設定されています。

結論：AggregatorDown

(24)　リンク集約接続（NNMi Advanced）

リンク集約接続は動作中

シナリオ：接続のすべてのポートアグリゲーターメンバーが動作中です。

根本原因：接続のすべてのメンバーでアグリゲーターが動作中です。

インシデント：インシデントは生成されません。

ステータス：集約接続のステータスは［正常域］に設定されています。

結論：AggregatorLinkUp

リンク集約接続の性能が低下している

シナリオ：接続の一部（すべてではない）のポートアグリゲーターメンバーが停止中です。

根本原因：接続の一部のメンバーでアグリゲーターが停止中です。

インシデント：AggregatorLinkDegradedインシデントが生成されます。

ステータス：集約接続のステータスは［警戒域］に設定されています。

結論：AggregatorLinkDegraded

リンク集約接続が機能を停止している

シナリオ：接続のすべてのポートアグリゲーターメンバーが停止中です。

根本原因：接続のすべてのメンバーでアグリゲーターが停止中です。

インシデント：AggregatorLinkDownインシデントが生成されます。

ステータス：集約接続のステータスは［危険域］に設定されています。

結論：AggregatorLinkDown

(25)　ルーター冗長グループ：HSRPおよびVRRP（NNMi Advanced）

ルーター冗長グループにプライマリがない

シナリオ：ルーター冗長グループにプライマリメンバーが存在しません。正常に機能しているHSRPまたはVRRPルーターグループには，動作しているプライマリルーターとセカンダリルーターが1台ずつなければなりません。

根本原因：このシナリオは，セカンダリルーターがアクティブでない場合にプライマリルーターのインタフェースに障害が発生していたか，ルーター冗長グループの設定に誤りがあったことが原因である可能性があります。

インシデント：RrgNoPrimaryインシデントが生成されます。RrgNoPrimaryがインパクトを受けます。InterfaceDownのような判明している根本原因がある場合は，RrgNoPrimaryとInterfaceDownの間にインパクトの相関関係が生成されます。

ステータス：ルーター冗長グループのステータスは［危険域］に設定されています。

結論：RrgNoPrimary

ルーター冗長グループに複数のプライマリがある

シナリオ：ルーター冗長グループに自身をプライマリルーターとして報告している複数のルーターが存在します。正常に機能しているHSRPまたはVRRPルーターグループは，動作中のプライマリルーターを1台だけ持っている必要があります。

根本原因：このシナリオは，ルーター冗長グループの設定の誤りが原因である可能性があります。

インシデント：RrgMultiplePrimaryインシデントが生成されます。RrgMultiplePrimaryがインパクトを受けます。

ステータス：ルーター冗長グループのステータスは［重要警戒域］に設定されています。

結論：RrgMultiplePrimary

ルーター冗長グループでフェイルオーバーが起こった

シナリオ：ルーター冗長グループのプライマリルーターに障害が発生し，セカンダリルーターがプライマリルーターの役割を引き継ぎました。通常，スタンバイがセカンダリになり，それ自体は問題ではありません（グループは正しく機能しています）。このシナリオに対して生成されるインシデントは，グループでフェイルオーバーが発生したことを報告するためのものです。

根本原因：このシナリオはプライマリルーターの障害が原因である可能性が最も高いです。

インシデント：RrgFailoverインシデントが生成されます。RrgFailoverの相関処理特性がインパクトを受け，InterfaceDownのような判明している根本原因がある場合は，RrgFailoverインシデントとInterfaceDownインシデントとの間の相関関係がインパクトを受けます。

ステータス：この場合，ステータスは生成されません。

結論：RrgFailover

ルーター冗長グループにセカンダリがない

シナリオ：ルーター冗長グループのセカンダリルーターに障害が発生しました。スタンバイが存在しないか，スタンバイがセカンダリの役割を引き継ぎませんでした。

根本原因：このシナリオは，ルーターのインタフェースの障害か，ルーターグループの何らかの設定ミスが原因である可能性があります。

インシデント：RrgNoSecondaryインシデントが生成されます。RrgNoSecondaryの性質がインパクトを受け，InterfaceDownのような判明している根本原因がある場合は，RrgNoSecondaryインタフェースとInterfaceDownインタフェースとの間の相関関係がインパクトを受けます。

ステータス：ルーター冗長グループのステータスは［警戒域］に設定されています。

結論：RrgNoSecondary

ルーター冗長グループに複数のセカンダリがある

シナリオ：ルーター冗長グループに自身をセカンダリルーターとして報告している複数のルーターが存在します。正常に機能しているHSRPまたはVRRPルーターグループは，動作しているセカンダリルーターを1台だけ持っていなければいけません。

根本原因：このシナリオは，ルーター冗長グループの設定ミスが原因である可能性があります。

インシデント：RrgMultipleSecondaryインシデントが生成されます。RrgMultipleSecondaryの性質がインパクトを受けます。

ステータス：ルーター冗長グループのステータスは［警戒域］に設定されています。

結論：RrgMultipleSecondary

ルーター冗長グループの性能が低下した

シナリオ：ルーター冗長グループに何らかの変更がありました。グループは機能しており，1台のプライマリルーターと1台のセカンダリルーターがありますが，問題となりかねない何らかの異常な状態が存在します。例えば，幾つかのルーターが動作可能状態になっていない可能性があります。

根本原因：このシナリオは，ルーターグループの何らかの設定ミスが原因である可能性があります。

インシデント：RrgDegradedインシデントが生成されます。RrgDegradedの性質がインパクトを受けます。

ステータス：ルーター冗長グループのステータスは［注意域］に設定されています。

結論：RrgDegraded

(26)　コンポーネントヘルスに関するシナリオ

ファンの故障または誤動作

シナリオ：ファンセンサーがシャーシ内のファンの故障を検出しました。

インシデント：FanOutOfRangeOrMalfunctioningインシデントが生成されます。

ステータス：ファンセンサーノードコンポーネントのステータスは［危険域］です。［重要警戒域］というステータスがノードに伝えられます。

結論：FanOutOfRangeOrMalfunctioning

電源の故障または誤動作

シナリオ：電源センサーがシャーシ内の電源の故障を検出しました。

インシデント：PowerSupplyOutOfRangeOrMalfunctioningインシデントが生成されます。

ステータス：電源ノードコンポーネントのステータスは［危険域］です。［重要警戒域］というステータスがノードに伝えられます。

結論：PowerSupplyOutOfRangeOrMalfunctioning

温度の超過または誤動作

シナリオ：温度センサーがシャーシ内の高温を検出しました。

インシデント：TemperatureOutOfRangeOrMalfunctioningインシデントが生成されます。

ステータス：温度センサーノードコンポーネントのステータスは［危険域］です。ノードのステータスは変化しません。

結論：TemperatureOutOfRangeOrMalfunctioning

電圧の逸脱または誤動作

シナリオ：電圧センサーがシャーシ内の電圧の問題を検出しました。

インシデント：VoltageOutOfRangeOrMalfunctioningインシデントが生成されます。

ステータス：電圧センサーノードコンポーネントのステータスは［危険域］です。ノードのステータスは変化しません。

結論：VoltageOutOfRangeOrMalfunctioning

付録D.7　ネットワーク設定の変更

NNMiオペレータは設定変更を1日のうちで，何度か行うことがあります。次のシナリオは，共通ネットワーク設定の変更について説明し，NNMiがこれらの変更に対してどう対応するかを示しています。

(1)　ノード更新中

例えば故障したインタフェースボードを，ネットワークオペレータが正常な代替品と交換して，ノードを変更する場合を想定します。NNMiがこの変更を認識すると，検出プロセスはNmsApaサービスに通知を送信します。NmsApaサービスはこの通知を使用して，次のタスクを完了します。

ノードのステータスを再計算します。

ノード上の削除したIPv4アドレスおよびインタフェースのすべての登録済インシデントをクローズします。

(2)　インタフェースが接続に加入および離脱する

ネットワークオペレータがネットワークデバイスの接続方法を変更する場合を想定します。インタフェースが接続に加入したり1つの接続を離れて別の接続に加入したりすると，NNMi検出プロセスはNmsApaサービスに通知を送信します。NmsApaサービスはこの通知を使用して，接続のステータスを再計算します。

(3)　デバイスがトラップを発生した場合

ColdStartトラップとWarmStartトラップ−NmsApaサービスは，ColdStartトラップとWarmStartトラップのイベントシステムからの通知を登録します。これらの通知が行われると，NmsApaサービスはそのトラップを発生したノードからのデバイス情報の再検出を開始します。

LinkUpトラップとLinkDownトラップ−NmsApaサービスは，LinkUpトラップおよびLinkDownトラップのイベントシステムからだけでなく，ベンダー固有のリンクトラップからの通知も登録します。これらの通知が行われると，NmsApaサービスはそのトラップを発生したノードからのデバイス情報の再検出を開始します。

メモ

NNMiが提供するトラップインシデント設定の一覧は，NNMiヘルプを参照するか，［設定］ワークスペースの［インシデント］から［SNMPトラップの設定］を選択してください。

付録D.8　NNMi管理設定の変更

NNMiツール管理者はNNMi設定変更を，1日のうちで何度か行うことがあります。次のシナリオは，共通NNMi管理設定の変更を説明し，NNMiがこれらの変更に対してどう対応するかを示しています。

NNMi管理者はIPv4アドレスの管理を解除するか，サービス停止にする

NmsApaサービスは，StatePollerからの通知を，pingStateがポーリングなしに設定されたあとで受け取ります。NmsApaサービスはこの通知に反応して，IPv4アドレスのステータスをステータスなしに設定します。

NNMi管理者はIPv4アドレスを管理するか，サービス状態に戻す

NmsApaサービスは，StatePollerからの通知を，pingStateが測定された値に設定されたあとで受け取ります。NmsApaサービスはこの通知に反応して，IPv4アドレスのステータスを，測定された値に基づいて計算します。

NNMi管理者はインタフェースの管理を解除するか，サービス停止にする

NmsApaサービスは，StatePollerからの通知を，operStateがポーリングなしに設定されたあとで受け取ります。NmsApaサービスはこの通知に反応して，インタフェースのステータスをステータスなしに設定します。

NNMi管理者はインタフェースを管理するか，サービス状態に戻す

NmsApaサービスは，StatePollerからの通知を，operStateが測定された値に設定されたあとで受け取ります。NmsApaサービスはこの通知に反応して，インタフェースのステータスを，測定された値に基づいて計算します。

NNMi管理者はノードの管理を解除するか，サービス停止にする

NmsApaサービスは，StatePollerからの通知を，agentStateがポーリングなしに設定されたあとで受け取ります。すべてのインタフェースでoperStateがポーリングなしに設定され，すべてのIPv4アドレスでpingStateがポーリングなしに設定されます。NmsApaサービスはこの通知に反応して，ノードのステータスをステータスなしに設定します。

NNMi管理者はノードを管理するか，サービス状態に戻す

NmsApaサービスは，StatePollerからの通知を，agentStateが測定された値に設定されたあとで受け取ります。すべてのインタフェースでoperStateが測定された値に設定され，すべてのIPv4アドレスでpingStateが測定された値に設定されます。NmsApaサービスはこの通知に反応して，ノードのステータスを計算します。

付録E　NNMiが使用するポートの一覧

次の表は，NNMiが管理サーバーで使用するポートを一覧で示しています。NNMiはこれらのポートをリスニングします。ポートの衝突が発生した場合，こうしたポート番号の多くは「設定の変更」欄で示した方法によって変更できます。

重要

アプリケーションフェイルオーバーが正しく機能するには，次のように設定してください。

TCPポート7800-7810をオープンにしてください。

アクティブNNMi管理サーバーとスタンバイNNMi管理サーバーは相互のネットワークアクセスに制限のないことが必要です。

NNMiをHA構成にしてクラスタシステムで運用する場合は，プライマリクラスタノードとセカンダリクラスタノードで使用するポート番号の設定を同じにしてください。nms-local.propertiesファイルでポートを変更する場合，ノードごとに設定する必要があります（HA構成のファイルレプリケーションでは複製されません）。

表E‒1　NNMi管理サーバーで使用されるポート

ポート

タイプ

名称

目的

設定の変更

162

UDP

trapPort

SNMPトラップポート。

nnmtrapconfig.ovpl Perlスクリプトを使用して変更します。

1098

TCP

nmsas.server.port.naming.rmi

NNMiコマンドラインツールで使用され，NNMiで使用されるさまざまなサービスと通信します。

システムのファイアウォールを設定して，これらのポートへのアクセスをローカルホストだけに制限することをお勧めします。

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

1099

TCP

nmsas.server.port.naming.port

NNMiコマンドラインツールで使用され，NNMiで使用されるさまざまなサービスと通信します。

システムのファイアウォールを設定して，これらのポートへのアクセスをローカルホストだけに制限することをお勧めします。

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

3873

TCP

nmsas.server.port.remoting.ejb3

NNMiコマンドラインツールで使用され，NNMiで使用されるさまざまなサービスと通信します。

システムのファイアウォールを設定して，これらのポートへのアクセスをローカルホストだけに制限することをお勧めします。

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

4444

TCP

nmsas.server.port.jmx.jrmp

NNMiコマンドラインツールで使用され，NNMiで使用されるさまざまなサービスと通信します。

システムのファイアウォールを設定して，これらのポートへのアクセスをローカルホストだけに制限することをお勧めします。

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

4445

TCP

nmsas.server.port.jmx.rmi

NNMiコマンドラインツールで使用され，NNMiで使用されるさまざまなサービスと通信します。

システムのファイアウォールを設定して，これらのポートへのアクセスをローカルホストだけに制限することをお勧めします。

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

4446

TCP

nmsas.server.port.invoker.unified

NNMiコマンドラインツールで使用され，NNMiで使用されるさまざまなサービスと通信します。

システムのファイアウォールを設定して，これらのポートへのアクセスをローカルホストだけに制限することをお勧めします。

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

4457

TCP

nmsas.server.port.hq

グローバルネットワーク管理の非暗号化トラフィックで使用します。

メッセージングでは，グローバルマネージャーからリージョナルマネージャーへ通信が行われます。

このポートが開くと，双方向となります。

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

4459

TCP

nmsas.server.port.hq.ssl

グローバルネットワーク管理の暗号化トラフィックで使用します。

メッセージングでは，グローバルマネージャーからリージョナルマネージャーへ通信が行われます。

このポートが開くと，双方向となります。

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

4712

TCP

nmsas.server.port.ts.recovery

内部トランザクションサービスのポート

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

4713

TCP

nmsas.server.port.ts.status

内部トランザクションサービスのポート

nms-local.properties ファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

4714

TCP

nmsas.server.port.ts.id

内部トランザクションサービスのポート

nms-local.properties ファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

5432

TCP

com.hp.ov.nms.postgres.port

このPostgreSQLポートは，このNNMi管理サーバーに対して組み込みデータベースが待機するポートです。

nms-local.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

5447

TCP

trapReceiverNettyPort

TrapReceiverでJBoss からの接続を待機するポート。

nnmtrapconfig.ovpl Perlスクリプトを使用して変更します。

7500

UDP

nnmcluster

nnmclusterが使用するポート。

設定変更できません。

7800-7810

TCP

−

アプリケーションのフェイルオーバーで使用するJGroupsポート。

アプリケーションフェイルオーバーを使用していない場合，システムのファイアウォールを設定して，これらのポートへのアクセスを制限することをお勧めします。

nms-cluster.propertiesファイルを変更します。

Windows：

%NNM_CONF%¥nnm¥props¥nms-cluster.properties

Linux：

$NNM_CONF/nnm/props/nms-cluster.properties

8886

TCP

OVsPMD_MGMT

NNMi ovspmd（プロセスマネージャー）管理ポート。

1. ovstopコマンドを実行し，NNMiサービスを停止します。

2. servicesファイルを開きます。

Windows：

%Windir%¥system32¥drivers¥etc¥services

Linux：

/etc/services

3. 次の行をファイルに追加します。

ovspmd_mgmt <ポート番号>/tcp

4. ovstartコマンドを実行し，NNMiサービスを開始します。

8887

TCP

OVsPMD_REQ

NNMi ovsmpd（プロセスマネージャー）リクエストポート。

1. ovstopコマンドを実行し，NNMiサービスを停止します。

2. servicesファイルを開きます。

Windows：

%Windir%¥system32¥drivers¥etc¥services

Linux：

/etc/services

3. 次の行をファイルに追加します。

ovspmd_req <ポート番号>/tcp

4. ovstartコマンドを実行し，NNMiサービスを開始します。

8989

TCP

com.hp.ov.nms.events.action.server.port

アクションサーバーポートを有効化して設定可能にします。

nnmaction.propertiesファイルを変更します。

Windows：

%NnmDataDir%shared¥nnm¥conf¥props¥nnmaction.properties

Linux：

$NnmDataDir/shared/nnm/conf/props/nnmaction.properties

20480

TCP

nmsas.server.port.web.http

デフォルトHTTPポート

Web UIおよびWebサービスに使用

GNM設定では，NNMiはこのポートを使用してグローバルマネージャーからリージョナルマネージャーへの通信を確立します。

このポートが開くと，双方向となります。

JP1/IM3との連携に使用

nms-local.propertiesファイルを変更します。インストール作業中に変更することもできます。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

20481

TCP

nmsas.server.port.web.https

デフォルトのセキュアーHTTPSポート（SSL）

Web UIとWebサービスに使用

JP1/IM3との連携に使用

nms-local.propertiesファイルを変更します。インストール作業中に変更することもできます。

Windows：

%NNM_CONF%¥nnm¥props¥nms-local.properties

Linux：

$NNM_CONF/nnm/props/nms-local.properties

20482

TCP

−

JP1/IM3連携機能の，カスタム性能情報連携を使用する場合に設定するポートです。

リリースノートの「9.23 JP1/IM3連携機能（アノマリー検知／しきい値監視）」を確認してください。

（凡例）　−：名称はありません。

次の表は，NNMiがほかのシステムとの通信に使用するポートの一部を一覧で示しています。NNMiがファイアウォールによってこれらのシステムと分離されている場合は，ファイアウォールでこれらのポートの多くを開く必要があります。実際にどのポートを開くかは，NNMiと連携するシステムおよびそのシステムの設定によって異なります。

表E‒2　ファイアウォールの通過方向

目的

ポート番号

（ポート／タイプ）

ファイアウォールの通過方向

SNMPリクエスト

161／udp

NNMi→監視対象ノード

SNMPレスポンス

ANY／udp

NNMi←監視対象ノード※1

SNMPトラップ／SNMP Informリクエスト

162／udp

NNMi←監視対象ノード

SNMP Informリクエストのレスポンス

ANY／udp

NNMi→監視対象ノード※2

SNMPトラップ転送

162／udp

NNMi→SNMPマネージャー

NNMi→Northboundアプリケーション

LDAP

389／tcp

NNMi→LDAPサーバー

SSL接続によるLDAP

636／tcp

NNMi→LDAP サーバー

メッセージングbisocketコネクタ

4457／tcp

NNMi（グローバルマネージャー）→NNMi（リージョナルマネージャー）

SSL接続によるメッセージング

bisocketコネクタ

4459／tcp

NNMi（グローバルマネージャー）→NNMi（リージョナルマネージャー）

アプリケーションフェイルオーバー

7800-7810／tcp

NNMi（アクティブ）← →NNMi（スタンバイ）

NNMiコンソール

20480／tcp

NNMi←Webブラウザ

NNMi（グローバルマネージャー）→NNMi（リージョナルマネージャー）

SSL接続によるNNMiコンソール

20481／tcp

NNMi←Webブラウザ

NNMi（グローバルマネージャー）→NNMi（リージョナルマネージャー）

JP1/IM3連携

20480／tcp

IM3-Manager→NNMi

SSL接続によるJP1/IM3連携

20481／tcp

IM3-Manager→NNMi

（凡例）

← →：

tcpの場合，コネクションを張る方向を示します。

udpの場合，パケットを送る方向を示します。

注※1　SNMPレスポンスはSNMPリクエストの送信先ポートを送信元とし，SNMPリクエストの送信元ポートを送信先とする通信です。

注※2　SNMP InformリクエストのレスポンスはSNMP Informリクエストの送信先ポートを送信元とし，SNMP Informリクエストの送信元ポートを送信先とする通信です。

注1　NNMiと監視ノード間で，ICMPについても通過させる必要があります。

注2　ポート番号はデフォルト設定の場合です。

注3　アプリケーションフェイルオーバーの場合の設定については，「18.　アプリケーションフェイルオーバー構成のNNMiを設定する」を参照してください。

ICMP障害ポーリングを使用する，またはノード検出用のためにPingスイープを使用するようにNNMiを設定する場合は，ICMPパケットの通過を許可するようにファイアウォールを設定する必要があります。

グローバルネットワーク管理機能を使用する場合は，グローバルNNMi管理サーバーからリージョナルNNMi管理サーバーに対して，表E-3に示すポートがアクセス可能になっている必要があります。グローバルネットワーク管理機能では，グローバルNNMi管理サーバーからリージョナルNNMi管理サーバーのこれらのTCPポートへ通信できる必要があります。リージョナルNNMi管理サーバーからは，グローバルNNMi管理サーバーのこれらのポートに対して接続しません。

表E‒3　グローバルネットワーク管理で必須のアクセス可能ソケット

セキュリティ

パラメーター

TCPポート

非SSL

nmsas.server.port.web.http

20480

nmsas.server.port.hq

4457

SSL

nmsas.server.port.web.https

20481

nmsas.server.port.hq.ssl

4459

注

ポート番号はデフォルト設定の場合です。

付録F　リファレンスページ（User Commands）

付録F.1　nnm.envvars

NNMiの共通パスの環境変数を定義するスクリプト

SYNOPSIS

Windowsオペレーティングシステム：

nnm.envvars.bat

Linuxオペレーティングシステム：

nnm.envvars.sh

nnm.envvars.csh

DESCRIPTION

nnm.envvarsは，共通パスのNNMiの環境変数を定義するスクリプトです。共通パスは，すべてのOSプラットフォームに共通のパス名およびファイル名を提供することによって，NNMiの使用を簡素化します。共通パスは，WindowsコマンドインタープリターまたはLinuxシェルに応じて提供されます。

Linuxでは，システムにログオンするたびにシェルスクリプトが起動されるように，.profileまたは.loginあるいは，現在の環境に記述することで，個別の端末，ユーザー，またはセッションにファイル内容を適用できます。

定義されている共通パスを参照する場合は，%NnmInstallDir%bin（Windowsの場合）にあるnnm.envvars.batファイル，または，$NnmInstallDir/bin（Linuxの場合）にあるnnm.envvars.shファイルを参照してください。

EXAMPLES

.profileまたは.loginファイルを変更する場合は，次の例から適切な行をファイルに追加してください。

nnm.envvarsスクリプトを有効にするには，次のコマンドを実行します。

Windowsのコマンドラインから

%NnmInstallDir%bin¥nnm.envvars.bat

説明：$NnmInstallDirはNNMiのインストールディレクトリです。NNMiインストーラが環境変数として登録します。

Linux形式のシェルがインストールされたWindowsから

sh，ksh，またはbashを使用する場合：

$NnmInstallDir/bin/nnm.envvars.sh

説明：$NnmInstallDirはNNMiのインストールディレクトリです。

cshを使用する場合：

source $NnmInstallDir/bin/nnm.envvars.csh

説明：$NnmInstallDirはNNMiのインストールディレクトリです。

Linuxオペレーティングシステムから

sh，ksh，またはbashを使用する場合：

. /opt/OV/bin/nnm.envvars.sh

cshを使用する場合：

source /opt/OV/bin/nnm.envvars.csh

AUTHOR

nnm.envvars was developed by Micro Focus.

FILES

Windowsオペレーティングシステム：

%NnmInstallDir%bin¥nnm.envvars.bat（Windowsのコマンドラインの場合）

%NnmInstallDir%bin¥nnm.envvars.sh（sh，kshまたはbashの場合）

%NnmInstallDir%bin¥nnm.envvars.csh（cshの場合）

Linuxオペレーティングシステム：

$NnmInstallDir/bin/nnm.envvars.sh（sh，ksh，またはbashの場合）

$NnmInstallDir/bin/nnm.envvars.csh（cshの場合）

EXTERNAL INFLUENCES

International Code Set Support：1バイトまたはマルチバイト文字コードセットをサポートします。

付録F.2　nnmfindattachedswport.ovpl

エンドノードが接続されているスイッチポートを見つけます。

SYNOPSIS

nnmfindattachedswport.ovpl [-u <user name>] [-p <password>] { -i <end node file> | -n <end node> } [-o <output file>]

DESCRIPTION

NNMiコマンドラインツールを頻繁に実行する場合は，nnm.propertiesファイルを作成しておくことを推奨します。このファイルには，コマンドラインオプションの-uおよび-pに代わって使用されるユーザー名およびパスワードが格納されます。nnm.propertiesファイルを使用することで，パスワードを入力せずに多数のコマンドを実行できます。詳細はnnm.propertiesリファレンスページを参照してください。

nnmfindattachedswport.ovplコマンドは，エンドノードに接続されているスイッチポートを表示します。nnmfindattachedswport.ovplコマンドを使用する場合，エンドノードをMACアドレス，IPアドレス，またはホスト名として指定します。MACアドレスは，先頭に0xや0Xを付けずに大文字で指定します。また，シードファイル内で一つのエントリごとに1行を使用して，入力をシードファイルとして指定することができます。

次が表示されます。

エンドノード

スイッチのホスト名

エンドノードに接続されているスイッチポートのインタフェース名

エンドノードが属するVLAN名

エンドノードが属するVLAN ID

インタフェースのステータスコード

ステータスコードは，NNMiがエンドノード情報を正しく取得した場合はSuccess（成功）を示し，そうでない場合はエラーコードを示します。表示はカンマ区切り（CSV）形式です。存在しない値に対しては，-1が代わりに表示されます。NNMiは，すべての値が-1の行を表示することにより，コマンドの完了を示します。

NNMiは，最初に値のそれぞれを指定するヘッダーをCSVに出力します。出力をファイルに転送するオプションがあります。その後，ファイルはMicrosoft™Excelにインポートすることができます。

Parameters

nnmfindattachedswport.ovplコマンドは，次のパラメータをサポートします。

-u <user name>

コマンドの実行に必要なNNMiのユーザー名を指定します。ユーザーは，システム，管理者，またはレベル2のオペレータが指定できます。nnm.propertiesファイルが存在していない限り，これが必要になります。

-p <password>

コマンドの実行に必要なNNMiのユーザーパスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。

-i <end node file>

エンドノードのリストを含む入力ファイルを指定するには，-iを使用します。NNMiは各エンドノードに接続されているスイッチポートを検索します。ファイルは，1行当たり1エントリだけを持つ必要があります。各行の値は，MACアドレス，IPアドレス，またはホスト名を指定します。MACアドレスは，先頭に0xや0Xを付けずに大文字で指定します。-nを指定しない場合，このパラメータが必要です。

-n <end node>

エンドノードを指定するには，-nを使用します。nnmfindattachedswport.ovplコマンドは，このエンドノードに接続されているスイッチポートを見つけます。エンドノードは，MACアドレス，IPアドレス，またはホスト名を指定します。MACアドレスは，先頭に0xや0Xを付けずに大文字で指定します。

-o <output file>

nnmfindattachedswport.ovplコマンドの出力が転送されるファイル名を指定するには，-oを使用します。

EXAMPLES

入力ファイルの一例を次に示します。

      10.45.130.2
      # これはコメント行です。
       con5.acme.com
      000087D064CB
      10.12.149.4
      laserj.acme.com

表示例は次のようになります。

      Input,SwitchName,IfName,VLANName,VLANId,StatusCode
      10.45.130.2,-1,-1,-1,-1,UNABLE_TO_LOCATE_ENTRY_IN_FDB
      con5.acme.com,-1,-1,-1,-1,UNABLE_TO_LOCATE_ENTRY_IN_ARP_CACHE
      000087D064CB,10.45.130.143,2/1,Network_B_IPv4,4,SUCCESS
      10.12.149.4,sw1-loop0.acme.com,Fa2/21,VLAN0490,490,SUCCESS
      laserj.acme.com,sw1-loop0.acme.com,Fa2/12,mpls-intercon,169,SUCCESS
      -1,-1,-1,-1,-1,-1

AUTHOR

nnmfindattachedswport.ovpl was developed by Micro Focus.

付録F.3　nnmprops

NNMiプロパティの値の問い合わせ

SYNOPSIS

nnmprops [-l] [-q prop] [-m match] [-e expand]

DESCRIPTION

nnmpropsはNNMiプロセスを実行するために使用されるプロパティ値を問い合わせるために使用されます。nnmpropsコマンドは，ファイルシステム内の複数の場所に格納された，これらのプロパティを統合して表示します。このコマンドは，NNMiシステムプロパティの値を問い合わせて，操作する必要のあるほかのスクリプトで使用できます。

Parameters

nnmpropsコマンドは，次のオプションをサポートします。

-l

すべてのプロパティを一覧表示します。

-q PROP

指定したプロパティを問い合わせます。複数のプロパティを問い合わせるときは，オプションを何度も指定できます。

-m STRING

プレフィックスがSTRINGであるすべてのプロパティを問い合わせます。

-e STRING

STRINGにあるプロパティを該当する値で展開します。

RETURN VALUE

エラーが発生しなかった場合は常にステータス0（ゼロ），それ以外の場合は1で終了します。

EXAMPLES

nnmprops -l

すべてのプロパティとその値を一覧表示します。

nnmprops -q com.hp.ov.nms.trapd.blocking -q com.hp.ov.nms.trapd.udpPort

"com.hp.ov.nms.trapd.blocking"と"com.hp.ov.nms.trapd.udpPort"プロパティの値を問い合わせます。

nnmprops -m com.hp.nms.trapd

"com.hp.nms.trapd"で始まるすべてのプロパティを問い合わせます。例えば，".notifySourcesPeriod"，".updateSourcesPeriod"，".overallUnblockTrapRate"，".unblockTrapRate"の値が返されます。

nnmprops -e "The values for com.hp.ov.nms.trapd.blocking are ${com.hp.ov.nms.trapd.blocking}."

${com.hp.ov.nms.trapd.blocking}の値が展開されて，指定した文字列が表示されます。プロパティ名を識別するために，"${"と"}"が必要となることに注意してください。

AUTHOR

nnmprops was developed by Micro Focus.

FILES

nnmpropsプログラムは，いくつかのプロパティファイルを使用します。これらのファイルは二つのカテゴリに分類されます。インストール時に設定されるデフォルト値，またユーザーが修正した優先される値です。インストール時に設定されるデフォルト値は，将来のバージョンで変更する場合があります。しかしながら，ユーザーが変更した値は，デフォルト値より常に優先されます。

%NnmInstallDir%misc¥nnm¥props（Windows）および$NnmInstallDir/misc/nnm/props（Linux）ディレクトリ階層の配下にあるファイルは，インストール時のデフォルト値を定義しています。

Note

NNMiの将来のバージョンで変更が上書きされる可能性があるため，この場所のファイルを編集しないでください。

%NnmDataDir%shared¥nnm¥conf¥props（Windows），%NnmDataDir%Conf¥nnm¥props（Windows），$NnmDataDir/shared/nnm/conf/props（Linux），および$NnmDataDir/conf/nnm/props（Linux）ディレクトリ配下にあるファイルは，ユーザーが変更した値や，インストール時や実行時にプログラムで変更した値を定義しています。これらの値は，最初はインストール時に提供される値のコピーをコメントアウトしたものです。これらのファイルを編集するには，コメントを削除して，値を変更します。この新しい値は，インストール時に提供されるデフォルト値より優先されます。

二つのディレクトリの違いは次のとおりです。

%NnmDataDir%shared¥nnm¥conf¥props（Windows）および$NnmDataDir/shared/nnm/conf/props（Linux）は，クラスタ（例えば，HAクラスタあるいは NNMi アプリケーションフェイルオーバークラスタ）で共有されるプロパティを含みます。

%NnmDataDir%Conf¥nnm¥props（Windows）および$NnmDataDir/conf/nnm/props（Linux）は，共有されない値を定義します。例えば，クラスタ内の各ノードは，同じプロパティに対して異なる値を持っている場合があります。

付録F.4　nnmsetcmduserpw.ovpl

スクリプトを実行するときに，実行ユーザーとして -uオプションまたは-p オプションの代わりに使用されるアカウントクレデンシャルを設定します。

SYNOPSIS

nnmsetcmduserpw.ovpl

DESCRIPTION

nnmsetcmduserpw.ovplは，通常-uオプションまたは-pオプションの指定が必要なスクリプトを実行する際に使用されるNNMiアカウントクレデンシャルを設定するときに使用できます。ユーザー名とパスワードの値は，コマンドラインに-uオプションまたは-pオプションを指定せずにスクリプトが実行された場合に使用されます。

注意：Windowsシステムの管理者またはLinuxシステムのrootユーザーはこのコマンドを実行しないでください。管理者または root ユーザーは，デフォルトで -u/-p を指定する必要はありません。

このコマンドを実行するには，コマンドラインスクリプトを実行するユーザーとしてシステムにログインする必要があります。ユーザー名とパスワードの値は，ユーザー単位で設定します。

Parameters

サポートするパラメータはありません。

EXAMPLES

-u オプションまたは -p オプションを通常指定するコマンドラインスクリプトを実行するときに使用するアカウントのユーザー名とパスワードを設定しておくと，コマンドラインにパスワードを指定することを回避できます。

使用方法：

# nnmsetcmduserpw.ovpl

警告:この変更は、このユーザーがこれらを必要とするスクリプトを実行するたびに

         -u/-pコマンドラインオプションの代わりに使用される

         資格証明に影響します。このスクリプトを実行する前に、

         希望のユーザーとしてログインしていることを確認してください。

         このスクリプトを実行すると、.nnm/nnm.propertiesファイルが

         ユーザーのホームディレクトリに作成され、編集されます。

続行しますか? [Y/N]:
Y
ユーザーコマンドパスワードの変更を続行します

ユーザー名を入力してください:
myuser
パスワードを入力してください:
mypass
パスワードを再入力してください:
mypass
ユーザー/パスワード値は /home/user/.nnm/nnm.properties に正常に保存されました

AUTHOR

nnmsetcmduserpw.ovpl was developed by Micro Focus.

FILES

nnmsetcmduserpw.ovplは，次のディレクトリにあります。

Windows：%NNM_BIN%

Linux：$NNM_BIN

SEE ALSO

nnm.properties.

付録F.5　nnmsnmpnotify.ovpl

SNMP 通知（TrapリクエストまたはInformリクエスト）を発行します。

SYNOPSIS

nnmsnmpnotify.ovpl [-v version] [-c community] [-p port(default:162)] [-A] [-t timeout] [-r retries] [-d] [-T] [-a agent_addr] [-e enterprise] node trap-oid variable type value [variable type value]...

DESCRIPTION

nnmsnmpnotify.ovplコマンドは，ローカルシステム上のイベントを別のシステムに知らせるため，SNMP 通知リクエストを送信します。ユーザーは，通知の肯定応答（SNMPv2 Inform）または否定応答（SNMPv1 または SNMPv2 Trap）を実行することができます。ただし，SNMP Version 1しかサポートしていないシステムに対しては，肯定応答の通知を送信することができません。

デフォルトでは，通知が否定応答されます。nnmsnmpnotify.ovplコマンドは，指定されたプロトコルバージョンに基づいて，SNMP Version 1またはSNMP Version 2のTrapを送信します。デフォルトバージョンを使用する場合，SNMP Trapリクエストの送信直後にnnmsnmpnotify.ovplコマンドが終了します。通知内容が相手側システムに実際に到着したという確認はありません。

肯定応答の通知を送信するには-Aオプションを使用します。nnmsnmpnotify.ovplコマンドは，相手側システムに対してSNMP Version 2のInformリクエストを送信します。このコマンドは，対応する肯定応答を待ち，必要に応じて再送信を実施します。再送信が必要な場合，nnmsnmpnotify.ovplコマンドは，コマンドライン上で指定されたtimeoutおよびretriesを使用します。指定した時間および再試行内に肯定応答が表示された場合，通知が相手側システムに到着したことが分かります。指定した時間および再試行内に肯定応答が表示されなかった場合，通知は相手側システムに到着していません。

nodeは，IPアドレスを持つSNMPをサポートしているシステムです。IPアドレスまたはホスト名により指定できます。nodeに空の文字列（""）が指定された場合，送信先はlocalhostになります。

トラップタイプは，コマンドラインのtrap-oid引数にオブジェクト識別子として指定します。ユーザーは，オブジェクト識別子の書式ですべての通知を識別する必要があります。SNMPv2 MIBで定義された通知を指定することができますが，ベンダー固有のSNMPv1 MIBをnnmsnmpnotify.ovplに直接指定することも可能です。しかし，nnmsnmpnotify.ovplへの入力として指定する前に，ベンダー固有のSNMPv1 MIBで定義されているトラップをオブジェクト識別子の書式で変換しなければなりません。SNMP Version 1トラップでtrap-oidの代わりに空の文字列（""）が指定された場合，汎用トラップタイプの値は6，特定のトラップタイプの値は0になります。SNMP Version 2通知の場合，trap-oidのvarBindは設定されません。

nnmsnmpnotify.ovplにトラップオブジェクト識別子を指定するときは次の目安に従ってください。

6種類の一般 SNMPトラップ（coldStart, warmStart, linkDown, linkUp, authenticationFailure, egpNeighborLoss）を生成するには，該当トラップに対応するオブジェクト識別子（RFC 1907 で定義されています）を使用します（例えば, coldStart トラップイベントのオブジェクト識別子は1.3.6.1.6.3.1.1.5.1です）。

SNMP一般ではないがSNMPv2の書式で定義されているトラップを生成するには，SNMPv2対応のMIBからNOTIFICATION-TYPE識別子を使用します。

SNMP一般ではないがSNMPv1の書式で定義されているトラップを生成するには，SNMPv1対応のMIBからトラップエンタープライズおよび特定ナンバーを使用します。次に，書式enterprise.0.specific field 欄でオブジェクト識別子を作成します。例えば，デバイステストに対するベンダー固有の MIB を考慮してください。MIBでは，enterprise 1.3.6.1.4.1.11.2.17.1 および特定トラップフィールド 4 でトラップを定義します。この結果，トラップのオブジェクト識別子は 1.3.6.1.4.1.11.2.17.1.0.4になります。

nnmsnmpnotify.ovplによりリモートノードに渡されるデータは，variable,type,valueの三つ一組で指定されます。ユーザーは，この組を少なくとも一つコマンドラインの引数で指定する必要があります。

各変数は，10進ドット形式またはニモニック文字列のオブジェクトインスタンス識別子です。例えば, .1.3.6.1.4.1.11.2.17.2.1.0 または openViewSourceId.0 形式のいずれかを使用できます。

各typeは，次のタイプのいずれかとします。

INTEGER

INTEGER32

IPADDRESS

COUNTER

COUNTER32

COUNTER64（SNMPv2c に対応しているリモートノード用）

GAUGE

GAUGE32

OBJECTIDENTIFIER

OCTETSTRING

OCTETSTRINGASCII

OCTETSTRINGHEX

OCTETSTRINGOCTAL

OPAQUE

OPAQUEASCII

OPAQUEHEX

OPAQUEOCTAL

TIMETICKS

UNSIGNED32

各typeの詳細説明は, RFC 1155およびRFC 1902を参照してください。

このときのvalueパラメータは，指定されたタイプで有効ある必要があります。16進数または8進数の値が必要なタイプを使用する場合，ユーザーがこの値の各バイトを完全に定義する必要があります。例えば，fff（または17377）を指定すると，1バイト足りないため動作しません。代わりに0fff（または017377）を使用してください。valueは，コマンドラインで指定する必要があります。このvalueは，512バイトを超えてはなりません。

Parameters

-v version

リモートノードとの通信に使用するSNMPのバージョンを指定します。versionに有効な値は，1または2cです。

-c community

リモートノード上で認証に使用するコミュニティ文字列を指定します。

注記：シェルに影響する文字がコミュニティ文字列に含まれている場合は，必要に応じて一つ以上のエスケープ文字または引用符を使用してください。

-p port

リモートノードと通信するときに使用するポートを指定します。

-t timeout

SNMP Version 2 Informリクエストの応答を待つタイムアウト期間を10分の1秒単位で指定します。このオプションは-Aオプションを使用する場合に有効です。

-r retries

SNMP Version 2 Informリクエストの応答が受信されない場合に試みるリトライ数を指定します。このオプションは-Aオプションを使用する場合に有効です。

-d

ASN.1 パケットトレースをダンプします。

-T

OID を10進ドット形式で出力します。

-a agent_addr

ローカルホストを指定エージェントアドレスの通知ソースとみなして無視します。agent_addrは，IP アドレスまたはホスト名でなければなりません。

-e enterprise

指定したenterprise 値の通知に対してエンタープライズオブジェクト識別子のデフォルトを無視します。

EXAMPLES

次のコマンドは，ノードv2c_node に対してSNMPリンクダウンInformリクエストを送信します。

nnmsnmpnotify.ovpl -A -v2c v2c_node .1.3.6.1.6.3.1.1.5.3

次のコマンドは，エージェントアドレスをagentに設定して，ノードv1_nodeに対しSNMPリンクダウンTrapリクエストを送信します。

nnmsnmpnotify.ovpl -a agent v1_node .1.3.6.1.6.3.1.1.5.3

AUTHOR

nnmsnmpnotify.ovpl was developed by Micro Focus.

FILES

次の環境変数は，ユーザー自身のシェルおよびプラットフォームの要求条件に従って確立される一般的なパスです。

Windows：%NNM_BIN%¥nnmsnmpnotify.ovpl

Linux：$NNM_BIN/nnmsnmpnotify.ovpl

SEE ALSO

nnmsnmpwalk.ovpl，nnmsnmpset.ovpl，nnmsnmpbulk.ovpl.

RFC 1155, 1157, 1212: SNMP Version 1.

RFC 1901 - 1908, 2576, 2578, 3416 - 3418: SNMP Version 2.

RFC 3411 - 3415: SNMP Version 3.

EXTERNAL INFLUENCES

Environmental Variables

$LANGは，メッセージを表示するときの言語を決定します。$LANGが指定されていない場合，または空の文字列に設定された場合，$LANGではなくCがデフォルトに使用されます。国際化変数のどれかに無効な設定値がある場合，nnmsnmpnotify.ovplは，国際化変数のすべてがCに設定されているように処理します。

International Code Set Support

シングルバイトまたはマルチバイトの文字コードセットをサポートします。

注記：タイプoctetstringasciiのSNMP MIB値はVT-ASCIIに限定されています。

付録F.6　ovstatus

NNMi 管理対象プロセスの状態の報告

SYNOPSIS

ovstatus [ [-c] [-d] [-v] [managed_process_names...] ]

DESCRIPTION

ovstatusは NNMi 管理対象プロセスの現在の状態を報告します。ovstatusは状態要求（OVS_REQ_STATUS）をプロセス管理プロセス（Linux オペレーティングシステム）またはサービス（Windows オペレーティングシステム）である ovspmdに送信します。一つ以上のmanaged_process_name引数で呼び出された場合，ovstatusは指定された管理対象プロセスの状態を報告します。引数なしで呼び出された場合，ovstatusは NNMi 起動ファイル（SUF）に追加された，（ovspmd自身を含む）すべての管理対象プロセスの状態を報告します。

ovstartとは異なり，ovstatusは ovspmdが既に起動中ではなくてもこれを起動しません。

管理対象プロセスは ovaddobjによってローカル登録ファイルの情報から構成されます。管理対象プロセスは，その管理対象プロセスを記述しているLRFの第1フィールドによって命名されます。

Parameters

ovstatusコマンドは，次のオプションをサポートします。オプションではない第1引数と，以降のすべての引数は状態を報告する管理対象プロセスの名前として解釈され，状態要求で ovspmdに渡されます。

-c

各管理対象プロセスの状態行を1行出力します。

-d

ovspmdへの連絡と状態要求の送信，および通信チャネルの閉鎖を含む処理の重要な段階を報告します。

-v

管理対象プロセスからの冗長メッセージを印刷します。特に，このオプションは現在のすべてのovwセッションを記述しているovuispmdからの冗長メッセージを表示します。

RETURN VALUE

通常，ovstatusはステータス0（ゼロ）で終了します。ゼロ以外の状態を返すのは，ovspmdが起動していないなど，システムに問題がある場合だけです。

DIAGNOSTICS

ovstatusは特定のコマンドラインエラー（特に引数過多）およびシステムエラーを報告します。メッセージの先頭には「ovstatus:」が付与され，内容が一目瞭然であることを目的としています。ovstatusはovspmdから受信したエラーメッセージも出力します。これらのメッセージの先頭には「ovspmd:」が付与されます。ovstatusはサポートしていないオプションは無視します。

ovstatusは，すべてのOVs_WELL_BEHAVEDプロセスおよびOVs_NON_WELL_BEHAVEDプロセスの既知の状態を報告します。OVs_DAEMONプロセスはovspmdの制御外で動作します。ovspmdはこれらのプロセスを把握できないので，該当プロセスはPID，unknown状態，および最終メッセージDoes not communicate with ovspmdを報告します。

ovspmdは複数の要求（ovstart，ovstop，ovstatus）を一度に処理できることに注意してください。これらのコマンドのどれかが処理中の場合，新規要求は前回のコマンドが完了するまでタイプ別に待ち行列に入れられます。

AUTHOR

ovstatus was developed by the Micro Focus.

FILES

次に示す環境変数は，お使いのシェルおよびプラットフォーム要件に応じて確立された汎用パス名を表します。次に示すファイルの環境変数の使用については，nnm.envvars リファレンスページを参照してください。

Windows：

%NNM_BIN%¥ovstatus

%NNM_BIN%¥ovspmd

Linux：

$NNM_BIN/ovstatus

$NNM_BIN/ovspmd

EXTERNAL INFLUENCES

Environmental Variables

$LANGは，国際化変数 LC_ALL，LC_CTYPE，LC_MESSAGES が未設定，NULL，または無効な場合にデフォルト値を提供します。

$LANGが未設定，NULL，または無効な場合，デフォルト値の C（Windows の場合 English_UnitedStates.1252）が使用されます。

LC_ALL（または $LANG）はovspmdが起動したほかのすべてのプロセスのロケールを決定します。

LC_CTYPEは，テキストをシングルバイト文字，マルチバイト文字，あるいはその両方として解釈すること，文字の分類は印刷可能とすること，正規表現の文字クラス表現によって文字を一致させることを決定します。

LC_MESSAGESは，メッセージを表示する言語を決定します。

SEE ALSO

ovstart, ovstop, ovspmd, nnmcluster.

付録G　リファレンスページ（Administrator Commands）

付録G.1　jp1nnmiinitconfig.ovpl

設定値変更簡易化コマンド（本コマンドにより，一部の設定を簡単に設定できます。）

SYNOPSIS

jp1nnmiinitconfig.ovpl help

jp1nnmiinitconfig.ovpl setUndefTrap [-template (once|multiple) | [-severity <string>] [-nature <string>] [-multiple (true|false)]]

jp1nnmiinitconfig.ovpl setImportantNodeGroup [-force]

DESCRIPTION

本コマンドでは，UndefinedSNMPTrapインシデントに関する設定, および，"重要なノード"にすべてのノードを登録する設定が可能です。

本コマンドを実行すると，既存の設定を上書きしますので，本機能に関連する設定を実施していない状態で使用してください。

UndefinedSNMPTrapインシデントについての説明

本設定を行うことで，NNMiが"SNMPトラップの設定" に定義がないOIDのSNMPトラップを受け取った際に"UndefinedSNMPTrap"インシデントを生成することができます。

UndefinedSNMPTrapインシデントには，破棄したSNMPトラップのOID情報が含まれます。

NNMiは"SNMPトラップの設定" に定義のないOIDのSNMPトラップを破棄しますが，本設定を有効にすると，破棄したSNMPトラップのOIDがわかるため，"SNMPトラップの設定"に追加すべきトラップ定義を把握するのに役立ちます。

本コマンドによる設定では，UndefinedSNMPTrapインシデントの重大度，原因のほか，各OIDにつき1度だけUndefinedSNMPTrapを生成するか，受信するたびに毎回UndefinedSNMPTrapを生成するかを選択できます。

※注：本設定実施時の注意事項

本コマンドで設定を実施した場合，OIDが完全一致していなくても，前方一致しているSNMPトラップインシデント定義が存在していれば，その定義が使用されるようになります。

本コマンドは，設定ファイルnms-jboss.propertiesを変更します。手動で変更する場合は，「8.6.1　未定義のトラップのインシデントを有効化にする」に従って，設定ファイルを変更してください。

重要なノードノードグループについての説明

本設定を行うことで， "重要なノード"ノードグループにすべてのノードが所属するようになります。すべてのノードについて，無応答時に，根本原因ではなくてもインシデントを通知したい場合は，本設定を行ってください。

※注：重要なノードについて

"重要なノード"ノードグループに含めたノードは，NNMiの根本原因解析機能で特別扱いされるようになり，ノードが無応答になった際，ノードが停止したことを示すインシデント（NodeDownなど）が必ず発生するようになります。

NNMiは，障害発生時，発生した事象のすべてをそのまま通知するのではなく，監視結果を解析し，根本原因に絞って通知します。この根本原因解析は，問題に迅速に対応でき，運用負担を低減する機能ですが，運用によっては弊害が生じるケースもあります。

例えばサーバーAが，ネットワーク経路上のルーター障害によって通信できなくなった場合，根本原因としてルーター障害がインシデントが通知されます。その際，サーバーAと通信ができない現象は，ルーター障害の影響による副次的な事象（根本原因ではない）と判定され，サーバーAが停止したことを示すインシデントが通知されないことがあります。

そのため，無応答になったノードすべてについてインシデントを発行したい場合，本設定を使用し，"重要なノード"にすべてのノードを登録してください。

なお，本設定を実施後，設定を元に戻す場合や，一部のノードを除外する場合は，GUIの下記から，設定を編集してください。（本コマンドを実施した場合 [追加のフィルター]に"hostname is not null"が設定されています。）

[設定]-[オブジェクトグループ]-[ノードグループ]-[重要なノード]ノードグループ-[追加のフィルター]タブ

Commands

help

コマンドの使用方法を表示します。

setUndefTrap

UndefinedSNMPTrapインシデントに関する設定を変更します。

本コマンドを使用することで，UndefinedSNMPTrapインシデントを有効化します。

オプションを指定することで，指定したパラメータに従ってUndefinedSNMPTrapインシデントが生成されるようになります。オプションは，-templateによるテンプレート設定，もしくは-severity，-nature，-multipleによる個別設定が選択できます。

本コマンドの設定後，設定を有効化するためには，NNMiを再起動してください。

※注：オプション省略時の動作について

本コマンドは，オプションを省略した場合，省略した部分の設定は変更しません（すべてのオプションを省略した場合，UndefinedSNMPTrapインシデントの有効化のみを行います）。

オプションを省略した場合，指定しなかった設定は未定義になり，undefinedと表示されます。undefinedとなった設定は，以下の内容で動作します。

重大度：NORMAL（正常域），原因：INFO（情報），-multiple false 相当（UndefinedSNMPTrapインシデントを，各OIDにつき1回だけ生成する）

setImportantNodeGroup

NNMiに重要なノード ノードグループにすべてのノードを登録する設定を行います。

本設定を行うことで，"重要なノード"ノードグループにすべてのノードが所属するようになります。すべてのノードについて，無応答時に，根本原因ではなくてもインシデントを通知したい場合は，本コマンドを使用してください。

本コマンドを使用する際は，NNMiを起動する必要があります。NNMi停止時に実行する場合は，-forceオプションを使用することで，NNMiを起動できます。

Parameters

-severity <string>

UndefinedSNMPTrapインシデントの重大度を指定します。下記のいずれかが指定可能です。

NORMAL, WARNING, MINOR, MAJOR, CRITICAL

-nature <string>

UndefinedSNMPTrapインシデントの原因に設定される値を指定します。下記のいずれかが指定可能です。

ROOTCAUSE，SECONDARYROOTCAUSE，SYMPTOM，SERVICEIMPACT，NONE，INFO

-multiple (true|false)

UndefinedSNMPTrapインシデントを，各OIDにつき 1回だけ生成するか，受信するたびに毎回生成するかを選択します。

true：同じOIDのSNMPトラップを複数回受け取った場合，毎回インシデントを生成します。

false：SNMPトラップの各OIDにつき1度だけUndefinedSNMPTrapインシデントを生成します。

-template (once|multiple)

設定テンプレート名（once，multiple）を指定します。他のサブオプションとは同時に指定できません。

onceを実行した場合，下記と同じ設定となります。

-severity WARNING -nature INFO -multiple false

multipleを実行した場合，下記と同じ設定になります。

-severity NORMAL -nature INFO -multiple true

-force

NNMi停止時に指定した場合，NNMiを起動します。

EXAMPLES

setUndefTrap の設定例

未定義のOIDのSNMPトラップ受信時，各OIDにつき1度だけUndefinedSNMPTrapインシデントを生成する場合は，下記を実行します（テンプレートを使用した設定例）。

jp1nnmiinitconfig.ovpl setUndefTrap -template once

未定義のOIDのSNMPトラップ受信時，毎回UndefinedSNMPTrapインシデントを生成する場合は，下記を実行します（テンプレートを使用した設定例）。

jp1nnmiinitconfig.ovpl setUndefTrap -template multiple

重大度や原因の値を細かく指定したい場合は，-severity，-nature，-multipleオプションで設定します。

以下は，UndefinedSNMPTrapインシデントの重大度を「MINOR(警戒域)」，原因を「SYMPTOM(症状)」にし，未定義のトラップ受信時，毎回インシデントを生成する例です。

jp1nnmiinitconfig.ovpl setUndefTrap -severity MINOR -nature SYMPTOM -multiple true

setImportantNodeGroupの設定例

NNMi停止時に，NNMiを起動し，すべてのノードを"重要なノード" ノードグループに登録する場合，下記を実行します。

jp1nnmiinitconfig.ovpl setImportantNodeGroup -force

NOTES

本コマンドにおいて，setImportantNodeGroupを設定する際は，NNMiを起動する必要があります。

また，setUndefTrapを設定する場合，設定を反映するためにはNNMiを再起動する必要があります。

両方のメインオプションを設定する場合は，下記手順で設定できます。

NNMi停止時に設定する場合

jp1nnmiinitconfig.ovpl setUndefTrap [オプション]

jp1nnmiinitconfig.ovpl setImportantNodeGroup -force

※完了後，NNMiが起動した状態になりますので，必要に応じてNNMiを停止してください。

NNMi起動時に設定する場合

jp1nnmiinitconfig.ovpl setImportantNodeGroup

jp1nnmiinitconfig.ovpl setUndefTrap [オプション]

ovstop

ovstart

AUTHOR

jp1nnmiinitconfig.ovpl was developed by Hitachi Ltd.

FILES

$NNM_BIN/jp1nnmiinitconfig.ovpl

付録G.2　nmsdbmgr

このコマンドは，データベース接続性の定期テストを含め，NNMiの組み込みデータベースを制御します。

SYNOPSIS

nmsdbmgr [-ovspmd] [-start] [-test] [-initnmsdb] [-stop] [-status] [-kill]

DESCRIPTION

nmsdbmgrは，ovspmdプロセスでNNMiの組み込みデータベースを制御するための，インターフェイスを提供するプログラムです。このプログラムを使用すると，ovspmdプロセスで，組み込みデータベースの起動，停止，およびステータスの検査ができます。

実行中，このプログラムは，データベースの接続性を5分間隔でテストし，接続性テストの結果に応じてovspmdプロセスに報告するステータスメッセージを更新します。データベースのテストが成功したときに報告されるメッセージはDatabase Availableです。データベースのテストが失敗したときに報告されるメッセージはData Warehouse inaccessibleです。失敗のメッセージが表示された場合，NNMi にデータベース関連の問題が発生している可能性があります。例えば，NNMiコンソールでノードインベントリの取得・表示ができないなどです。

このコマンドをovspmdプロセスと独立して実行することも技術的に可能ですが，予期しない結果になるおそれがあるので，この方法は推奨されません。

注意：nmsdbmgrプログラムの実行中にプロセステーブルを確認すると，このプログラムから，プラットフォームに応じてpostgresまたはpostgres.exeという名前の子プロセスが多数生成されていることが分かります。これらの子プロセスは，組み込みデータベースそれ自体を表しています。これらの子プロセスのインスタンスが複数存在しても問題はありません。

EXAMPLES

このコマンドの通常の使用法は，ovspmdプロセスを使用した間接的な使用です。

典型的な使用法は，同プロセスを次のように起動または停止することです。

# ovstart -c nmsdbmgr
# ovstop -c nmsdbmgr
# ovstatus -c nmsdbmgr

AUTHOR

nmsdbmgr was developed by Micro Focus.

FILES

Windows：

%NNM_DB%¥Postgres

%NnmInstallDir%nonOV¥Postgres

Linux：

$NNM_DB/Postgres

$NnmInstallDir/nonOV/Postgres

SEE ALSO

ovspmd，ovstart，ovstop，ovstatus.

付録G.3　nnmaction

NNMi Action Server（アクションサーバー）のラッパープロセス

SYNOPSIS

nnmaction

DESCRIPTION

nnmactionはアクションサーバーと呼ばれるプロセスで，ovspmdプロセスによって管理されます。nnmaction.propertiesファイルにエントリを追加することで，アクションサーバーに引数が渡されます。

nnmactionコマンドは絶対に手動で実行しないでください。nnmactionプロセスの起動および管理は，ovspmdプロセスが行います。nnmactionプロセスを再起動するには，ovstop nnmactionコマンド，ovstart nnmactionコマンドの順に実行します。nnmactionプロセスのステータスを確認するには，ovstatus nnmactionコマンドを実行します。

ovstartコマンドまたはovstopコマンドを実行するには，Windowsシステムの管理者またはLinuxシステムのrootとしてログオンする必要があります。

AUTHOR

nnmaction was developed by Micro Focus.

FILES

Windows：%NNM_SHARED_CONF%¥props¥nnmaction.properties

Linux：$NNM_SHARED_CONF/props/nnmaction.properties

アクションサーバーが使用するパラメータファイルです。

SEE ALSO

ovspmd，ovstart，ovstop，ovstatus.

付録G.4　nnmbackup.ovpl

NNMi のデータおよびファイルのバックアップに使用するコマンドです。

SYNOPSIS

nnmbackup.ovpl [-?|-h|-help] [-type (online|offline)] [-scope (config|topology|events|all)] [-force] [-archive] [-noTimeStamp] -target <directory>

DESCRIPTION

nnmbackup.ovplは，NNMi の主要なバックアップコマンドです。このコマンドは，バックアップ動作に対してどのディレクトリとテーブルを考慮するかを決定するために%NNM_DATA%¥shared¥nnm¥backup.propertiesファイル（Windows）または$NNM_DATA/shared/nnm/backup.propertiesファイル（Linux）を使用します。backup.propertiesファイルは，リストア時に特別な処理が必要なファイルやディレクトリも定義しています。nnmbackup.ovplコマンドは，バックアップ領域（config, topology, events, all），バックアップロケーション，バックアップタイプ（onlineまたはoffline）などの項目を決定するために，種々の引数を指定します。

nnmbackup.ovplコマンドを使用してNNMiのバックアップを作成し，次にnnmrestore.ovplコマンドを使用してデータベースレコードを別のNNMi管理サーバーに配置する場合は，どちらのNNMi管理サーバーも同種のオペレーティングシステムと同一バージョンのNNMiがインストールされ，同一のパッチレベルが適用されている必要があります。バックアップデータをあるNNMi管理サーバーから別のNNMi管理サーバーに配置するということは，どちらのサーバーも同一のデータベースUUIDを持つことを意味します。グローバルネットワーク管理機能を使用する場合は，2台目のNNMi管理サーバーにNNMiをリストアした場合，元のNNMi管理サーバーからNNMiをアンインストールしてください。

このコマンドを実行する前に，ターゲットディレクトリに十分な保存領域があることを確認してください。ほとんどのNNMiインストール環境において，NNMiインストール環境（Windowsでは%NNM_DATA%ディレクトリ，Linuxでは$NNM_DATAディレクトリ）のコンテンツを保存するだけの十分な空き容量があれば，保存領域も十分に取れているはずです。次のディレクトリで，使用可能な保存領域を確認してください。

Windows：%NnmInstallDir%

Linux：$NnmInstallDir

組み込みデータベースのデータは，%NNM_DATA%¥shared¥nnm¥databases¥Postgres ディレクトリ（Windows）または$NNM_DATA/shared/nnm/databases/Postgresディレクトリ（Linux）に格納されます。

ターゲットディレクトリを構成するのは，指定されたバックアップオプションに適用できるファイルのすべてか，-archiveオプションを使用する場合は単独のtarファイルです。各バックアップ動作では，指定されたターゲットディレクトリの下の親ディレクトリnnm-bak-<TIMESTAMP>にファイルを保存します。バックアップの実行中に何かデータベース操作が行われた場合，その操作はバックアップ対象となります。バックアップ完了後にファイルを圧縮することができます。

リストア時に特別な処理が必要なファイルは，ターゲットディレクトリ/nnm-bak-<TIMESTAMP>/special_filesの下に保存されます。リストア時は，除外，リストア，またはマージ対象のファイルがNNMiによって選択されます。詳細については，nnmrestore.ovplリファレンスページを参照してください。

nnmbackup.ovplコマンドには，リストア操作の実行に必要なデータが含まれています。このコマンドを実行するには，Windowsシステムの管理者またはLinuxシステムのrootでログインする必要があります。

Parameters

nnmbackup.ovplコマンドは，次のオプションをサポートします。

-type (online|offline)

このオプションでは，実行するバックアップのタイプを決定します。onlineオプションを指定する場合，nnmbackup.ovplコマンドを実行するときに，NNMiが稼働中である必要があります（所要のプロセスはnmsdbmgrのみ）。offlineオプションを指定する場合，NNMiを完全に停止してからnnmbackup.ovplコマンドを実行します。

-scope (config|topology|events|all)

このオプションでは，バックアップ操作の領域を指定します。バックアップ対象のデータには，ファイルシステム内のファイルとデータベース内のテーブルの2種類があります。ファイルシステム内のファイルに使用する-scopeオプションの値は，選択するバックアップタイプに関わらず常に適用されます（-typeオプションの項を参照）。ただし，データベース内のテーブルに使用する-scopeオプションの値は，-type onlineオプションを使用してオンラインバックアップを実行する場合にだけ適用されます。オフラインバックアップの場合は，要求した領域だけでなく，データベースの内容全体がバックアップされます。このため，オフラインバックアップを実行する場合は，領域を指定しないことを推奨します（デフォルトはallです）。指定可能な領域は，config，topology，events，および allです。各領域には，下位の領域のデータとファイルが含まれます（all→events→topology→config）。%NNM_DATA%¥shared¥nnm¥backup.propertiesファイル（Windows）または$NNM_DATA/shared/nnm/backup.propertiesファイル（Linux）には，各領域でバックアップされるファイルおよびテーブルの一覧が指定されます。

-force

このオプションを指定すると，要求したバックアップのタイプに応じてて，nnmbackup.ovplコマンドがNNMiを起動および停止します。オンラインバックアップの場合，NNMiが実行中でないときは，nmsdbmgrプロセスが起動されます（バックアップに必要なため）。オフラインバックアップの場合，NNMiが実行中であれば，すべてのNNMiプロセスを停止します。

-archive

このオプションを指定すると，バックアップファイルがターゲットディレクトリにtarファイルとして保存されます。

-noTimeStamp

このオプションを指定すると，nnmbackup.ovplコマンドは，タイムスタンプの入らない名前（単にnnm-bakというディレクトリ名またはnnm-bak.tarというファイル名）でバックアップファイルを対象ディレクトリに保存します。同一のファイル名やディレクトリ名を持つ，以前のバックアップが存在する場合は，.previousというサフィックスが付けられてリネームされます。.previousの付いたバックアップが既に存在する場合，そのファイルまたはディレクトリは削除されます。このオプションの目的は，日常的なバックアップ作業において，実行したすべてのバックアップを保存する代わりに，成功した最新の二つのバックアップのみを維持することによって，ディスク使用量を削減することにあります。

-target <directory>

バックアップファイルを保存する出力ディレクトリを指定します。ターゲットディレクトリ内にnnm-bak-<TIMESTAMP>という親ディレクトリが作成され，すべてのバックアップファイルがこのディレクトリに保存されます。-archiveオプションが指定されている場合，一時的にnnm-bak-<TIMESTAMP>ディレクトリが作成された後，このディレクトリが同じ名前のtarファイルに置き換えられます。

-?|-h|-help

コマンドの使用方法を表示します。

EXAMPLES

ネットワークの検出結果は保存せずに，検出前のNNMiの設定を保存したい場合，onlineオプションとconfigオプションを使用して，次のようにバックアップを実行します。

#./nnmbackup.ovpl -type online -scope config -target /tmp/bak/config

アプリケーションを停止せずに，NNMiの設定，検出されたトポロジ，およびイベントデータを保存する場合，online，events，およびforceオプションを使用して，次のようにバックアップを実行します。

#./nnmbackup.ovpl -force -type online -scope events -target /tmp/bak/evt

計画されたバックアップを定期的に実行する場合，offlineオプションとallオプションを使用して，次のようにバックアップを実行します。

#./nnmbackup.ovpl -type offline -scope all -target /tmp/bak/all

AUTHOR

nnmbackup.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_DATA%¥shared¥nnm¥backup.properties

Linux：$NNM_DATA/shared/nnm/backup.properties

SEE ALSO

nnmrestore.ovpl.

付録G.5　nnmbackupembdb.ovpl

NNMi組み込みデータベースの完全なバックアップを取得します。

SYNOPSIS

nnmbackupembdb.ovpl [-?|-h|-help] [-noTimeStamp] -target <target directory> [-force]

DESCRIPTION

NNMi組み込みデータベースの完全なバックアップを取得するときに，nnmbackupembdb.ovplコマンドを使用します。バックアップの内容は，指定したファイルに圧縮されない状態で格納されます。このファイルは，nnmrestoreembdb.ovplコマンドでリストアを行うときに必要となります。

nnmbackupembdb.ovpl コマンドを使用してNNMi組み込みデータベースのバックアップを作成し，次にnnmrestoreembdb.ovplコマンドを使用して組み込みデータベースレコードを別のNNMi管理サーバーに配置する場合は，どちらのNNMi管理サーバーも同種のオペレーティングシステムと同一バージョンのNNMiがインストールされ，同一のパッチレベルが適用されている必要があります。

nnmbackupembdb.ovplコマンドを実行する前に，バックアップ先ディレクトリに十分な空き容量があることを確認してください。組み込みデータベースのデータは，%NNM_DATA%¥shared¥nnm¥databases¥Postgresディレクトリ（Windows）または$NNM_DATA/shared/nnm/databases/Postgresディレクトリ（Linux）に保存されます。バックアップ先ディレクトリにバックアップファイルを格納するために必要な空き容量があるか確認するために，このディレクトリのサイズをチェックしてください。必要に応じて，バックアップ後にファイルを圧縮してもかまいません。

バックアップ先ディレクトリに作成されるバックアップファイルには，バックアップ操作を開始したときのデータベースの内容が格納されます。バックアップ実行中にデータベース内で実行されるステートメントはバックアップ対象外です。

このコマンドは，NNMiの稼動中にも実行できますが，一時的にパフォーマンスが低下する場合があります。このコマンドが正常に実行されるには，最低限nmsdbmgrプロセスが起動している必要があります。-forceオプションを指定すると，このコマンドによって（起動していない場合は）nmsdbmgrプロセスが起動し，対話式のメッセージは非表示となります。

このコマンドを実行するには，Windowsシステムの管理者またはLinuxシステムのrootとしてログインする必要があります。

Parameters

-target <target directory>

バックアップファイルを保存するディレクトリの名前を指定します（存在しないディレクトリを指定した場合は作成されます）。

-force

このオプションを指定すると，nmsdbmgrプロセスが起動していない場合は自動的に起動します。

-noTimeStamp

このオプションを指定すると，nnmbackupembdb.ovplコマンドは，タイムスタンプの入らない名前（単にnnm-bak.pgdというファイル名）でバックアップファイルを対象ディレクトリに保存します。同一のファイル名を持つ，以前のバックアップが存在する場合は，.previousというサフィックスが付けられてリネームされます。.previousの付いたバックアップが既に存在する場合，そのファイルは削除されます。このオプションの目的は，日常的なバックアップ作業において，実行したすべてのバックアップを保存する代わりに，成功した最新の二つのバックアップのみを維持することによって，ディスク使用量を削減することにあります。

--?|-h|-help

コマンドの使用方法を表示します。

EXAMPLES

このコマンドを使用すると，"オンデマンド"バックアップを実行できます。また，バックアップコマンドの実行を，定期的に実行されるタスクとして追加することもできます。次のように実行します。

# nnmbackupembdb.ovpl -target /backups/nnm

警告: 許可されていても、NNMの実行中にこのコマンドを実行すると
         一時的なパフォーマンスの問題が発生します。少なくとも、nmsdbmgrプロセスが
         実行している (ovstart nmsdbmgr) ことを確認してください。

フルデータベースバックアップの実行を今すぐ開始してもよいですか? [n]
y
組み込みデータベースのフルバックアップを実行しています...

NNM組み込みデータベース nnm は、/backups/nnm/nnm-bak-20070929064743.pgd に正常にバックアップされました。

#

AUTHOR

nnmbackupembdb.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmbackupembdb.ovpl

Linux：$NNM_BIN/nnmbackupembdb.ovpl

SEE ALSO

ovstart, ovstop, ovstatus, nmsdbmgr, nnmrestoreembdb.ovpl.

付録G.6　nnmcertmerge.ovpl

自動でキーストアとトラストストアを証明書ストアにマージします。

SYNOPSIS

nnmcertmerge.ovpl [-?|-h|-help] [-keystore <file> -truststore <file>]|[-directory <directory>]

DESCRIPTION

証明書ストアをnnm.keystoreおよびnnm.truststoreファイルに自動でマージするときに，nnmcertmerge.ovplを使用します。このコマンドは，グローバルネットワーク管理，HA構成，およびアプリケーションフェイルオーバーの機能を使用する場合に，すべての証明書のマージ作業を簡単にします。

このコマンドを実行するには，Windowsシステムの管理者またはLinuxシステムのrootとしてログインする必要があります。

Parameters

nnmcertmerge.ovplコマンドは，次のオプションをサポートします。

-keystore <file>

このオプションを使用すると，指定したファイルがnnm.keystoreファイルにマージされます。-truststoreオプションと同時に使用できます。

-truststore <file>

このオプションを使用すると，指定したファイルがnnm.truststoreファイルにマージされます。-keystoreオプションと同時に使用できます。

-directory <directory>

-directoryオプションは単独で使用する必要があります。このオプションを使用すると，指定したディレクトリにあるすべてのファイルが，次のように処理されます。

.keystoreで終わるすべてのファイルがnnm.keystoreファイルにマージされます。

.truststoreで終わるすべてのファイルがnnm.truststoreファイルにマージされます。

-?|-h|-help

コマンドの使用方法を表示します。

EXAMPLES

キーストアをNNMiにマージします。

nnmcertmerge.ovpl -keystore /tmp/hostA.keystore

トラストストアをNNMiにマージします。

nnmcertmerge.ovpl -truststore /tmp/hostA.truststore

キーストアとトラストストアをNNMiにマージします。

nnmcertmerge.ovpl -keystore /tmp/hostA.keystore -truststore /tmp/hostA.truststore

ディレクトリにあるすべてのキーストアとトラストストアをNNMiにマージします。

nnmcertmerge.ovpl -directory /tmp/AppFailoverHosts/

AUTHOR

nnmcertmerge.ovpl was developed by Micro Focus.

FILES

nnmcertmerge.ovplは，次のディレクトリにあります。

Windows：%NNM_BIN%

Linux：$NNM_BIN

付録G.7　nnmchangeembdbpw.ovpl

NNMi組み込みデータベースの認証に使用されているパスワードを変更します。

SYNOPSIS

nnmchangeembdbpw.ovpl

DESCRIPTION

nnmchangeembdbpw.ovplを使用すると，NNMiが組み込みデータベースに接続する際に使用するデータベースパスワードを変更できます。このコマンドは，組み込みデータベースオプションでNNMiをインストールした場合に有効です。このコマンドは，組み込みデータベース用に作成されたデフォルトパスワードを変更するときにだけお使いください。このコマンドを実行しなくてもNNMiは正常に機能します。

nnmchangeembdbpw.ovplコマンドを実行するには，nmsdbmgrだけが起動していて，ほかのNNMiプロセスは停止している必要があります。このコマンドは，必要に応じて自動的にシステムをこの状態にします。つまり，自動的にovstopを実行してからovstart nmsdbmgrを実行します。

このコマンドが完了すると，組み込みデータベースパスワードは対話式に入力された値に変更され，NNMiサーバーは新しいパスワードを使用してデータベースに接続するよう再設定されます。

このコマンドを実行するには，Windowsシステムの管理者またはLinuxシステムのrootとしてログインする必要があります。

Parameters

サポートするパラメータはありません。

EXAMPLES

NNMi組み込みデータベースのパスワードを頻繁に変更する必要がある場合，nnmchangeembdbpw.ovplコマンドを使用します。

nnmchangeembdbpw.ovplコマンドでは，入力したパスワードは表示されません。

nnmchangeembdbpw.ovplコマンドを使用した場合，次のメッセージが表示されます。

# nnmchangeembdbpw.ovpl
警告：このツールを実行する前に、NNMが停止したことを確認してください。
          NNMを停止できない場合、予期しないデータベースエラーが発生する可能性があります。
          NNMを停止した後、ovstart nmsdbmgrを実行してデータベースのみを開始します。
NNMを停止しましたか (ovstop)? [Y/N]:
Y
組み込みデータベースのパスワードの変更を続行します
パスワードを入力してください:
mynewpw
パスワードを再入力してください:
mynewpw
ユーザー/パスワードが正常に変更されました!
#

AUTHOR

nnmchangeembdbpw.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmchangeembdbpw.ovpl

Linux：$NNM_BIN/nnmchangeembdbpw.ovpl

SEE ALSO

ovstart, ovstop, ovstatus, nmsdbmgr.

付録G.8　nnmchangesyspw.ovpl

NNMiのインストール時に通常設定されるシステムアカウントのパスワードを変更します。

SYNOPSIS

nnmchangesyspw.ovpl

DESCRIPTION

nnmchangesyspw.ovplコマンドを使用すると，NNMiシステムパスワードを変更できます。通常，NNMiシステムパスワードはインストール時に設定され，復旧を行うときに使用されます。このコマンドは，インストール時に設定されたシステムパスワードをリセットする場合にだけ使用します。

nnmchangesyspw.ovplコマンドを実行する前に，ovstopコマンドを実行してNNMiを停止してください。nnmchangesyspw.ovplコマンドの実行後，ovstartコマンドを実行してNNMiを起動します。この操作により，新しいパスワード値が即座に有効になります。

このコマンドを実行するには，Windowsシステムの管理者またはLinuxシステムのrootとしてログインする必要があります。

Parameters

サポートするパラメータはありません。

EXAMPLES

管理者権限が付与されたほかのユーザーアカウントをすべて削除してしまった上，NNMiのインストール時に設定したシステムパスワードを覚えていないような場合に，システムパスワードを変更します。

nnmchangesyspw.ovplコマンドでは，入力したパスワードは表示されません。

nnmchangesyspw.ovplコマンドを使用した場合，次のメッセージが表示されます。

# nnmchangesyspw.ovpl

警告: この変更は NNM が再起動されない限り直ちには反映
         されません。このスクリプトを実行する前に ovstop を実行し、
         実行後に ovstart を実行して変更が即時に反映されるようにしてください。
続行しますか?[Y/N]:
Y
システムのパスワードの変更を続行します
パスワードを入力してください:
mynewpw
パスワードを再入力してください:
mynewpw
システム パスワードが正常に変更されました
#

AUTHOR

nnmchangesyspw.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmchangesyspw.ovpl

Linux：$NNM_BIN/nnmchangesyspw.ovpl

SEE ALSO

ovstart, ovstop, ovstatus.

付録G.9　nnmcluster

NNMiクラスタサービスを開始します。

SYNOPSIS

nnmcluster [-disable|-enable] [-display] [-interfaces] [-startnnm|-stopnnm] [-acquire|-relinquish] [-shutdown] [-dbsync] [-halt] [-node nodename] [-daemon]

DESCRIPTION

nnmclusterは，NNMiクラスタプロセスを開始します。NNMiクラスタは，二つのシステムを使用することによって，一方のシステムに障害が発生した場合のNNMiサービスの運用を保証します。両方のノードでnnmclusterコマンドを実行すると，両ノードが互いに相手を検出し，クラスタを形成します。先にクラスタに参加したノードは"アクティブ"状態となり，（ovstartコマンドにより）NNMiサービスを開始します。後でクラスタに参加したノードは，既にアクティブなノードが存在していることを検出し，"スタンバイ"状態となります。システムのシャットダウンや障害などで，スタンバイノードとアクティブノードとの接続が切断されると，スタンバイノードはアクティブ状態となり，NNMiサービスを開始します。

nnmclusterをコマンドラインパラメータなしで呼び出すと，クラスタは対話モードで起動します。対話モードでは，クラスタの設定を対話式の操作で表示したり変更したりできます。対話モードで表示したり変更したりできる設定には，自動フェイルオーバーの有効化/無効化の切り替え，クラスタ内ノードのシャットダウン，NNMiサービスのアクティブノードからスタンバイノードへの移行などがあります。

nnmcluster が -daemonパラメータを付けて呼び出された場合，NNMiクラスタはバックグラウンドデーモンプロセス，または，Windowsサービスとして起動します。

ほかのパラメータを指定してnnmclusterコマンドを呼び出した場合，コマンドラインに指定されたアクションが開始されます。これらのアクションは通常，ローカルノードのNNMiクラスタデーモンプロセスを対象としますが，-node nodenameオプションを使用すると，指定したノードのNNMiクラスタデーモンプロセスが対象となります。

コマンドラインに指定できるオプションのほとんどは対話モードでも使用できます。例えば，コマンドラインでの"-shutdown"オプションの指定は，対話モードでの"shutdown"コマンドに対応します。対話モードだけで使用できるコマンドもいくつかあります。例えば，使用できるコマンドを一覧表示する"help"コマンドや，対話モードを終了する"quit"コマンドがその一例です。"-node nodename"コマンドも対話モードに用意されています。

なお，NNMiサービスを開始できるのは，NNMiクラスタデーモンプロセスだけです。対話モードおよびコマンドラインのアクション指定は，クラスタ内ノードの一方のデーモンプロセスの動作を実行するための方法です。例えば，"-acquire"を指定した場合は，ローカルノード（-nodeオプションでノードを指定した場合は指定されたノード）上のデーモンプロセスが，アクティブな状態を取得し，NNMiサービスを開始します。いったん開始されたNNMiクラスタデーモンプロセスとのやりとりは，コマンドラインまたは対話モード設定を通じて行います。例えば，開始されたNNMiクラスタデーモンプロセスを終了したい場合は，nnmcluster -shutdownコマンドを使用します。

NNMiクラスタアプリケーションは，アクティブノードとスタンバイノードとの間で組み込みデータベースを同期します。この動作は，データベースの完全なバックアップをスタンバイノードに送信した後，定期的に増分データベーストランザクションログを送信することで実現されます。完全バックアップとトランザクションログを送信する頻度（間隔）は，ほかのクラスタパラメータと一緒にnms-cluster.propertiesファイルに定義します。

NNMiクラスタアプリケーションにはスタートアップ期間があり，この期間を経てからデータベースをアクティブノードからスタンバイノードへ送信できるようになります。このスタートアップ期間の間は，アクティブな状態をスタンバイノードへ移動させるコマンドオプションが無効になります。このようなオプションとしては，shutdown，acquire，relinquish，その他の使用可能オプションがあります。これらのオプションにより，スタンバイノードのデータベースが不完全な状態となり，NNMiを実行できない状態になるため，これらは無効にされます。しかしながら，スタンバイノードがデータベース全体を受信すると，その時点以降に問題となる期間はなく，両方のシステムが動作を継続します（再起動を行うと，スタンバイノードがアクティブノードと同期状態であるかどうかを検証し直します）。

Parameters

nnmclusterコマンドは，次のオプションをサポートします。サポートされないオプションを指定した場合，使用方法のメッセージが表示されます。オプションは，常に指定した順序で処理されます。例えば，"-display -disable"と指定する場合と，"-disable -display"と指定する場合は，結果が異なります。

-node nodename

オプションを指定時以外は，すべてのパラメータがローカルノード上のNNMi クラスタデーモンプロセスを参照します。

-disable

自動フェイルオーバー機能を無効にします（自動フェイルオーバー機能はデフォルトでは有効となります）。システム管理者は，管理作業を行うため短時間，アクティブノードをシャットダウンする場合があります。-disableパラメータを指定すると，スタンバイノードをアクティブにしてNNMiサービスを起動することなく，アクティブノードをシャットダウンできます。-acquireオプションに続けて-enableオプションを指定すると，同じノードをアクティブ状態のまま再起動できます。

-enable

上述の方法で無効化された自動フェイルオーバー機能を再び有効化します。

-interfaces

システムに搭載されているネットワークインタフェース（NIC）の一覧を作成し，システムの命名規則とJavaの命名規則を表示します。Linuxプラットフォームでは，"eth0"，"lan1"，"bge3"など，両者は同じ値になります。Windowsでは，"Network Interface 1"が"eth3"にマッピングされるなど，名称が異なります。このオプションの目的は，データNICの代わりに管理NICを選択するなど，NNMiクラスタの通信で使用するNICを制御することです。上記のWindowsの例では，NNMiクラスタは"eth3"などのJava名を知っている必要があります。

-display

クラスタに接続し，現在のクラスタ状態を問い合わせ，状態を管理者に対して表示します。

-startnnm

-stopnnmオプションでNNMiサービスを停止した場合など，NNMiサービスがアクティブノードで稼働しているとは限りません。-startnnmオプションはこれらのNNMiサービスをアクティブノードで起動します。

-stopnnm

アクティブノードのNNMiサービスをシャットダウンしますが，"アクティブ"状態は解除されません。このオプションを指定した場合，フェイルオーバーイベントは発生しません。つまり，スタンバイノードにアクティブ状態が移行するわけではありません。

-acquire

システム管理者は，現在"アクティブ"状態のノードから"スタンバイ"状態のほかのノードにNNMiサービスを移行する場合があります。-nodeオプションでノードを指定しない場合は，ローカルシステムが新しいアクティブなノードとなります。-node nodenameオプションでノードを指定した場合は，指定したノードが新しいアクティブなノードとなります。

-relinquish

ローカル（アクティブ）ノードのアクティブ状態を放棄し，NNMiサービスをスタンバイノードに移行するためのオプションです。アクティブ状態を放棄するノードはNNMiサービスを停止し，スタンバイ状態となります。

-dbsync

アクティブなノード上でデータベースをバックアップして，スタンバイなノードのデータベースへ同期させます。

-shutdown

ローカルノード上のNNMiクラスタデーモンプロセスをシャットダウンします。-nodeオプションでノードを指定した場合は，指定したノード上の NNMiクラスタデーモンプロセスをシャットダウンします。NNMiクラスタプログラムは，クラスタのシャットダウンによってスタンバイノードのデータ完全性が損なわれる可能性がある場合は，クラスタのシャットダウンを禁止します。例えば，スタンバイノードがアクティブノードからデータベースの完全なバックアップを受信しているときに，フェイルオーバーイベントが生じるのは好ましくありません。シャットダウンを行ったときに，クラスタが移行状態にあることを通知するメッセージを受信することがあります。つまり，スタンバイノードが重要なデータを受信しているため，それが完了してからシャットダウンを行う必要があるということです。また，アクティブノードが存在しない状態でスタンバイノードをシャットダウンすることはできませんので注意してください。アクティブノードとスタンバイノードの両方を停止させる場合は，-haltオプションの使用を推奨します。このオプションでは，スタンバイノードが停止してからアクティブノードが停止します。

-halt

クラスタ内のすべてのノードのNNMiクラスタデーモンプロセスをシャットダウンします。このオプションを指定した場合，フェイルオーバーを無効にしてからすべてのスタンバイノードをシャットダウンし，最後にアクティブノードをシャットダウンします。

-node nodename

コマンドラインで指定された一つまたは複数のアクションが，指定したノード上のNNMiクラスタデーモンプロセスに実行されます。このオプションを指定しない場合，コマンドラインで指定されたアクションは，ローカルノード上のNNMiクラスタデーモンに適用されます。

-daemon

NNMiクラスタをデーモンとして起動します。コマンドはバックグラウンドで即時実行されます。デーモンモードでは，コマンドラインにほかのパラメータを指定できません。

RETURN VALUE

コマンドラインオプションを指定したnnmclusterコマンドが成功した場合，コマンドはステータス0（ゼロ）で終了します（エラーなし）。一方，コマンドラインオプションを指定したnnmclusterコマンドが失敗した場合，コマンドはステータス1で終了します（エラー発生）。対話モードでは，終了ステータスは常に0となります。

デーモンモードでは，nnmclusterコマンドはバックグラウンドプロセスとして動作し，シェルプロンプトが即座に返されます。デーモンプロセスを開始した場合，クラスタの状態はnnmcluster -displayコマンドまたはovstatusコマンドで確認できます。つまり，（クラスタ内のほかのノードとの兼ね合いで，ノードのアクティブ/スタンバイ状態により）NNMiクラスタはNNMiサービスを開始するタイミングを判定します。ovstatusコマンドは，スタンバイノードの"稼働していない"状態を通知しますが，nnmcluster -displayコマンドはノードがスタンバイ状態にあることを通知します。

DIAGNOSTICS

nnmcluster は，NNMiログディレクトリ（Windowsの場合は%NNM_DATA%¥log¥nnm，Linuxの場合は$NNM_DATA/log/nnm）にログを出力します。デーモンの動作モードが対話モードであってもコマンドラインであっても，動作中のnnmclusterプロセスのアクティブなインスタンスごとに個別のログファイルが生成されます。最新の実行スレッドは常に"nnmcluster.0.*.log"となります。NNMiクラスタは内部的に"JGroups"と呼ばれるオープンソースの技術を使用します。JGroupsのログファイルは，"jgroups.log"という名前で上記のディレクトリに保存されます。

EXAMPLES

nnmcluster -daemon

nnmcluster -display

最初のコマンドを実行すると，NNMiクラスタがデーモンプロセスとして起動し，シェルプロンプトが即座に返されます。デーモンプロセスはバックグラウンドで実行されます。対話モードまたはコマンドラインモードを使用すると，このデーモンプロセスに対して照会，シャットダウン，またはその他のアクションの適用を行うことができます。2番目は繰り返して使用するコマンドで，クラスタ（特にローカルデーモンプロセス）の状態を監視し，起動状態がアクティブかスタンバイかを確認できます。

nnmcluster -shutdown -node xyz.mycompany.com

指定したノード上のNNMiクラスタデーモンプロセスをシャットダウンします。指定したノードがアクティブノードの場合，自動フェイルオーバーが有効のときは，NNMiサービスはスタンバイノードに移行します。

nnmcluster

NNMiクラスタコマンドの対話モードを開始し，クラスタパラメータを表示または変更します。このプログラムを終了するには，"exit"コマンドまたは"quit"コマンドを使用します。

nnmcluster -acquire

デーモンモードで動作している，ローカルシステムのNNMiクラスタプロセスをアクティブノードに切り替えます。現在アクティブなノードがスタンバイモードに設定され，NNMiサービスがローカルノードで開始されます。

一般的なシステム管理手順を次に示します。管理者は，アクティブノードのNNMiクラスタを一時的にシャットダウンし，スタンバイノードへのフェイルオーバーイベントを発生させずに，アクティブノードをアクティブノードのまま後で再起動します。

手順1：nnmcluster -disable -shutdown コマンドを実行します。

手順2：必要なシステム管理タスクを実行します。

手順3：nnmcluster -daemon コマンドを実行します。

手順4：nnmcluster -display コマンドを実行します。このコマンドを使用して，デーモンがいつ起動するかを確認します。

手順5：nnmcluster -enable コマンドを実行します。

手順1に示すコマンドを実行すると，まずフェイルオーバーが無効になり，ローカルデーモンプロセスがシャットダウンされます。手順2では，フェイルオーバーをトリガーするおそれがない状態で，システム管理者が管理タスクを実行します。手順3に示すコマンドにより，デーモンモードのNNMiクラスタプロセスが再起動します。手順4に示すコマンドを繰り返し使用すると，ローカルデーモンプロセスが起動して NNMiが実行されるタイミングを確認できます。手順5に示すコマンドで，アクティブノードのNNMiが起動した後に自動フェイルオーバーを再度有効にします。

AUTHOR

nnmcluster was developed by Micro Focus.

FILES

Windows：%NNM_PROPS%¥nms-cluster.properties

Linux： $NNM_PROPS/nms-cluster.properties

このファイルはクラスタパラメータを定義します。具体的には，クラスタに一意な名前を付け，同じネットワークに存在するほかのNNMiクラスタと区別する必要があります。オプションで，タイムアウトなどのほかのパラメータを設定できます。

SEE ALSO

ovstart, ovstop.

付録G.10　nnmcommconf.ovpl

通信の構成情報を表示します。

SYNOPSIS

nnmcommconf.ovpl [-u username] [-p password] -proto <icmp | snmp> -host <hostname>

DESCRIPTION

nnmcommconf.ovplは，特定のプロトコルを使用して，特定のホストとNNMiがどのように通信を行うかについて，NNMiから情報を読み取り，表示するコマンドです。nnmcommconf.ovplは，SNMPまたはICMPプロトコルに基づいて情報を表示します。

Parameters

nnmcommconf.ovplコマンドは，次のオプションをサポートします。

-proto <protocol>

プロトコル：SNMPまたはICMP

-host <hostname>

情報の取得元となるホストの名前を指定します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

nnmcommconf.ovpl -u foo -p bar -proto icmp -host baz

このコマンドを実行すると，次のような情報を取得できます。

       address              = 10.2.1.2
      timeout              = 2000
      retries              = 1
      enabled              = true
      region name          = default
nnmcommconf.ovpl -u foo -p bar -proto snmp -host baz

このコマンドを実行すると，次のような情報を取得できます。

       name                   = baz
      management address     = 10.2.1.1
      addressForced          = false
      preferredVersion       = null
      minimum security level = コミュニティのみ (SNMPv1 またはv2c)
      readCommunity          = public
      writeCommunity         = *******
      timeout                = 5000
      retries                = 1
      port                   = 161
      proxyPort              = null
      proxyAddress           = null
      SNMPv3 user names      = null
      SNMPv3 context names   = null
      enabled                = true
      address disco enabled  = false
      get bulk enabled       = true
      region name            = region
      node setting description = null
      active address         = 10.2.1.1
      active readCommunity   = public
      active SNMPv3 user     = null
      active SNMPv3 context  = null

AUTHOR

nnmcommconf.ovpl was developed by Micro Focus.

FILES

nnmcommconf.ovplは，次のディレクトリにあります。

Windows：%NNM_BIN%

Linux：$NNM_BIN

SEE ALSO

nnm.properties, nnmcommload.ovpl.

付録G.11　nnmcommload.ovpl

CSVファイルから通信設定を読み込みます。

SYNOPSIS

nnmcommload.ovpl [-u username] [-p password] -file <filepath | filename>

DESCRIPTION

nnmcommload.ovplコマンドを使用すると，複数のデバイスの通信設定を一括してインポートできます。このコマンドは，コミュニティ文字列が変更制御機構で管理されているときに有用です。NNMiに一括して指定項目を挿入できます。設定ファイルに入力したデータの形式に応じて，各指定項目が個別エントリとして，NNMiコンソールの［通信の設定］フォームの［領域］タブまたは［特定ノードの設定］タブに表示されます。

IPアドレスとしてホスト名を指定した場合，nnmcommload.ovplコマンドは，IPアドレスを完全修飾名へと解決しません。実際のホスト名を指定すると，nnmcommload.ovplコマンドは，DNSを使用してホスト名を完全修飾名へと解決します。サイズが大きいインポートファイルを処理するには，時間がかかる場合があります。500行を超えるファイルについては，500行のバッチに分けてエントリをデータベースに保存します。500行をインポートファイルから読み込んだ後，各行のSNMP構成エントリは既存のSNMP領域またはデフォルト設定に基づいて解決され，データベースに保存されます。

インポートを実行するには，次に示す項目が，示されたとおりの順序で指定されたテキストファイルを作成します。デバイス一つにつき1行とします。1行に指定する各項目はカンマで区切ります。「#」で始まる行はコメント行となります。行に指定された項目は厳密に指定位置によって解釈されるため，値のない項目についてもカンマを打つ必要があります。カンマを含む値を指定する場合は，二重引用符で囲みます（例："comm,string"）。

ターゲットホスト名またはIPアドレス（必須：［特定ノードの設定］の設定）

";;"で区切られた一つ以上のホスト名フィルター（任意：［領域］の設定）

一つの読み取りコミュニティ文字列（任意：［特定ノードの設定］の設定）

";;"で区切られた一つ以上の読み取りコミュニティ文字列（任意：［領域］の設定）

コミュニティ文字列に順序を設定したい場合は，"#PRI#"という文字列に続いて，各領域のコミュニティ文字列に割り当てる優先順位を指定します。例えば，"public#PRI#5"は，コミュニティ文字列"public"に順位番号 5 が割り当てられます。

管理アドレス（任意：［特定ノードの設定］の設定）

";;"で区切られた一つ以上のアドレス範囲（任意：［領域］の設定）

書き込みコミュニティ文字列（任意）

ミリ秒単位のタイムアウト値（任意）

リトライ数（任意）

ポート（任意）

プロキシアドレス（任意）

プロキシポート（任意）

ユーザー名（SNMP v3 任意：［特定ノードの設定］の設定）

";;"で区切られた一つ以上のユーザー名（SNMP v3任意：［領域］の設定）

コンテキスト名（SNMP v3 任意：［特定ノードの設定］の設定）

";;"で区切られた一つ以上のコンテキスト名（SNMP v3任意：［領域］の設定）

認証プロトコル（SNMP v3 任意：［特定ノードの設定］の設定- MD5|SHA）

";;"で区切られた一つ以上の認証プロトコル（SNMP v3任意：［領域］の設定）

認証パスフレーズ（SNMP v3 任意：［特定ノードの設定］の設定）

";;"で区切られた一つ以上の認証パスフレーズ（SNMP v3任意：［領域］の設定）

プライバシプロトコル（SNMP v3 任意：［特定ノードの設定］の設定- DES|3DES|AES|AES192|AES256）

";;"で区切られた一つ以上のプライバシプロトコル（SNMP v3任意：［領域］の設定）

プライバシパスフレーズ（SNMP v3 任意：［特定ノードの設定］の設定）

";;"で区切られた一つ以上のプライバシパスフレーズ（SNMP v3任意：［領域］の設定）

SNMP優先バージョン（任意- 1|2|3：［特定ノードの設定］の設定限定）

「SNMPの通信を有効にする」フラグ（任意- true|false）

「SNMP アドレス再検出を有効にする」フラグ（任意- true|false）

「SNMP GetBulkを有効にする」フラグ（任意- true|false）

説明（任意：［特定ノードの設定］の設定または［領域］の設定）

「ICMPの通信を有効にする」フラグ（任意- true|false）

ミリ秒単位のICMPのタイムアウト値（任意）

ICMPのリトライ数（任意）

デバイスの資格証明のユーザー名（任意）

デバイスの資格証明のパスワード（任意）

デバイスの資格証明のタイプ（任意）

現在サポートされているタイプは，"Shell"だけです。

領域の名前（任意：［領域］の設定 - 指定しない場合，Region15のようにデフォルトで "Region" + 順序が設定されます）

領域の順序（任意：［領域］の設定 - 指定しない場合，既存の領域の順序における最大値 + 1が設定されます）

SNMP 最小セキュリティレベル（任意：［領域］の設定 - V1-ONLY|V1V2-ONLY|COMMUNITY|NOAUTH-NOPRIV|AUTH-NOPRIV|AUTH-PRIV）指定しない場合，「コミュニティ」が設定されます。

例えば，特定ノードの設定を読み込むための次のエントリはすべて有効と考えられます。

hostname
hostname,
hostname,,
hostname,public
hostname,,10.2.2.3,,1000,2,161
node1,community,10.3.7.96,writecommunity
node2, community,10.3.7.95 (community の前のスペースは削除されます)
10.2.23.34,community,10.2.23.8
10.2.23.34,community,10.2.23.88,writecommunity,2000,2,161,10.56.22.199,162

次は，複数のホスト名フィルター，アドレス範囲，読み取りコミュニティ文字列，SNMPv3設定，およびデバイスの資格証明を持つ領域の設定を読み込む例です。コミュニティ文字列の順序も割り当てられています。

testv3*;;cisco*.fc.usa.hp.com, region description,true,3,3,user1,password1,Shell,myregion,10,Community

public;;readcommunity#PRI#1,3.3.3.3;;4.4.4.4,writecommunity,3330,3,161,7.7.7.7,777,v3User1;;v3User2,v3Context1;;v3Context2,MD5;;SHA,authPass1;;authPass2,AES;;DES,privPass1;;privPass2,3,true,true,true,my region description,true,3,3,user1,password1,Shell,myregion,10,Community

次は，複数のSNMPv3設定を持つ領域の設定を読み込む例です。v3と領域のパラメータだけが指定されています。

v3User1は認証なし，プライバシなしのユーザーです

v3User2はMD5認証，プライバシなしのユーザーです

v3User3はSHA認証，3DESプライバシを持つユーザーです

";;"を区切り文字として使用しているため，必要に応じて認証とプライバシ情報の指定が省略されていることに注意してください。

,,,,,,,,,v3User1;;v3User2;;v3User3,v3Context1;;;;v3Context3,;;MD5;;SHA,;;authPass2;;authPass3,;;;;3DES,;;;;privPass3,3,,,,,,,,,,,myregion,10,Community

Parameters

nnmcommload.ovplコマンドは，次のオプションをサポートします。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-file <filepath | filename>（必須）

読み込むデータを上述の形式で指定したファイルのファイル名またはフルパスを指定します。

EXAMPLES

nnmcommload.ovpl -u joe -p secret -file import.txt

nnmcommload.ovpl -u joe -p secret -file C:¥temp¥import.txt

nnmcommload.ovpl -u joe -p secret -file /tmp/import.txt

AUTHOR

nnmcommload.ovpl was developed by Micro Focus.

FILES

nnmcommload.ovplは，次のディレクトリにあります。

Windows：%NNM_BIN%

Linux：$NNM_BIN

SEE ALSO

nnm.properties, nnmcommconf.ovpl.

付録G.12　nnmcommunication.ovpl

通信設定の管理を可能にします。

SYNOPSIS

nnmcommunication.ovpl -h|-help

nnmcommunication.ovpl addCertificate (-default|-region (<name>|<uuid>)| -nodeSetting (<name>|<uuid>))(-cert <cert_file>)

nnmcommunication.ovpl addCommunity (-default|-region <region>) -community <value> [-ordering <order>]

nnmcommunication.ovpl addCredential (-default|-region <region>| -nodeSetting <nodeName>) -type (SHELL|VMWARE|CISCOACI) -username <username> -password <password>

nnmcommunication.ovpl addSnmpV3Setting (-default | -region (<name>|<uuid>)) -snmpV3Setting (<name>|<uuid>)

nnmcommunication.ovpl createAddressRange [-uuid <uuid>] -region <region> -range <ip_range>

nnmcommunication.ovpl createHostnameFilter -hostname <pattern> -region <region> [-uuid <uuid>]

nnmcommunication.ovpl createNodeSettings -name <name> [-addressDiscovery (true|false)] [-description <description>] [-icmpEnabled (true|false)] [-icmpRetries <number>] [-icmpTimeout <timeout>] [-managementAddress <ip>] [-shellCredential <credential>] [-shellUser <username>] [-snmpCommunity <string>] [-snmpEnabled (true|false)] [-snmpGetBulk (true|false)] [-snmpPort <port>] [-snmpPreferredVersion (V1|V2C|V3)] [-snmpProxyAddress <ip>] [-snmpProxyPort <port>] [-snmpRetries <number>] [-snmpTimeout <timeout>] [-snmpV3Setting (<name>|<uuid>)] [-snmpWriteCommunity <community_string>] [-uuid <uuid>]

nnmcommunication.ovpl createRegionSettings -name <name> -ordering <order> [-addressDiscovery (true|false)] [-addressFilter <filter>] [-description <description>] [-hostnameFilter <filter>] [-icmpEnabled (true|false)] [-icmpRetries <number>] [-icmpTimeout <timeout>] [-shellCredential <credential>] [-shellUser <username>] [-snmpCommunities <strings>] [-snmpEnabled (true|false)] [-snmpGetBulk (true|false)] [-snmpPort <port>] [-snmpProxyAddress <ip>] [-snmpProxyPort <port>] [-snmpRetries <number>] [-snmpSecurityLevel (COMMUNITY_ONLY|COMMUNITY|NO_AUTH_NO_PRIV|AUTH_NO_PRIV|AUTH_PRIV|COMMUNITY_ONLY_V1)] [-snmpTimeout <timeout>] [-snmpV3Settings (<name>|<uuid>)] [-snmpWriteCommunity <community_string>] [-uuid <uuid>]

nnmcommunication.ovpl createSnmpV3Settings -name <name> -username <name> [-authPass <string>] [-authProtocol (HMAC_MD5_96|HMAC_SHA_1|HMAC128_SHA_224|HMAC192_SHA256|HMAC256_SHA_384|HMAC384_SHA_512)] [-contextName <string>] [-privPass <string>] [-privProtocol (DES_CBC|TripleDES|AES_128|AES_192|AES_256)] [-uuid <uuid>]

nnmcommunication.ovpl delete (-region <region>| -nodeSetting <nodeSetting>| -snmpV3Setting <v3Setting>)

nnmcommunication.ovpl deleteAddressRange (-region (<name>|<uuid>) | -range <ip_range> | -uuid <uuid>)

nnmcommunication.ovpl deleteHostnameFilter (-hostname <pattern> -region <region> | -uuid <uuid>)

nnmcommunication.ovpl listAddressRanges [-range <ip_range>] [-region (<name>|<uuid>)] [-uuid <uuid>]

nnmcommunication.ovpl listCertificates (-default|-region (<name>|<uuid>)| -nodeSetting (<name>|<uuid>))

nnmcommunication.ovpl listCommunities (-default|-region <region>)

nnmcommunication.ovpl listDefaults

nnmcommunication.ovpl listCredentials (-default|-region <region>| -nodeSetting <nodeName>)[-type(SHELL|VMWARE|CISCOACI)]

nnmcommunication.ovpl listEffective-node (<name>|<uuid>)

nnmcommunication.ovpl listHostnameFilters (-hostname <pattern> -region <region>) |(-uuid <uuid>)

nnmcommunication.ovpl listNodeSettings -name <name>

nnmcommunication.ovpl listRegionSettings [-name <name>]

nnmcommunication.ovpl listSnmpAgentSettings [-node (<name>|<uuid>)]

nnmcommunication.ovpl listSnmpV3Settings [(-name <name>|-uuid <uuid>)]

nnmcommunication.ovpl listWebAgentSettings [-node (<name>|<uuid>)]

nnmcommunication.ovpl removeCertificate (-default|-region (<name>|<uuid>)| -nodeSetting (<name>|<uuid>)) (-uuid <uuid>|-fingerPrint <fingerPrint>| -serialNumber <serialNumber>)

nnmcommunication.ovpl removeCommunity (-default|-region <region>) (-community <value>|-ordering <order>) -uuid <uuid>: The object unique identifier.

nnmcommunication.ovpl removeCredential (-default|-region <region>| -nodeSetting <nodeName>) -type (SHELL|VMWARE|CISCOACI) [-username <username>] [-password <password>]

nnmcommunication.ovpl removeSnmpV3Setting (-default | -region (<name>|<uuid>)) -snmpV3Setting (<name>|<uuid>)

nnmcommunication.ovpl updateCredential (-default | -region <region>| -nodeSetting <nodeName>) -type (VMWARE|CISCOACI) (-username <username> | -password <password>)

nnmcommunication.ovpl updateDefaults [-addressDiscovery (true|false)] [-default] [-icmpRetries <number>] [-icmpTimeout <timeout>] [-interfaceMatcher <value>] [-managementAddressSelection <ALG1,ALG2,ALG3>] [-preferIPVersion (IPv4|IPv6|IPAny)] [-shellCredential <credential>] [-shellUser <username>] [-snmpCommunities <strings>] [-snmpGetBulk (true|false)] [-snmpPort <port>] [-snmpProxyAddress <ip>] [-snmpProxyPort <port>] [-snmpRetries <number>] [-snmpSecurityLevel (COMMUNITY_ONLY|COMMUNITY|NO_AUTH_NO_PRIV|AUTH_NO_PRIV|AUTH_PRIV|COMMUNITY_ONLY_V1)] [-snmpTimeout <timeout>] [-snmpV3Settings (<name>|<uuid>)] [-snmpWriteCommunity <community_string>]

nnmcommunication.ovpl updateSnmpAgentSettings -node (<name> | <uuid>) [-address <ip>] [-community <string>] [-enabled (true|false)] [-mode (AUTO|LOCKED)] [-port <port>] [-retries <integer>] [-snmpProxyAddress <ip>] [-snmpProxyPort <port>] [-timeout <duration>] [-version (V1|V2C|V3)] [-writeCommunity <string>]

nnmcommunication.ovpl updateNodeSettings -nodeSetting (<name>|<uuid>) [-addressDiscovery (true|false)] [-description <description>] [-icmpEnabled (true|false)] [-icmpRetries <number>] [-icmpTimeout <timeout>] [-managementAddress <ip>] [-name <newName>] [-shellCredential <credential>] [-shellUser <username>] [-snmpCommunity <string>] [-snmpEnabled (true|false)] [-snmpGetBulk (true|false)] [-snmpPort <port>] [-snmpPreferredVersion (V1|V2C|V3)] [-snmpProxyAddress <ip>] [-snmpProxyPort <port>] [-snmpRetries <number>] [-snmpTimeout <timeout>] [-snmpV3Setting (<name>|<uuid>)] [-snmpWriteCommunity <community_string>]

nnmcommunication.ovpl updateRegionSettings -region (<name>|<uuid>) [-addressDiscovery (true|false)] [-addressFilter <filter>] [-description <description>] [-hostnameFilter <filter>] [-icmpEnabled (true|false)] [-icmpRetries <number>] [-icmpTimeout <timeout>] [-name <newName>] [-ordering <integer>] [-shellCredential <credential>] [-shellUser <username>] [-snmpCommunities <strings>] [-snmpEnabled (true|false)] [-snmpGetBulk (true|false)] [-snmpPort <port>] [-snmpProxyAddress <ip>] [-snmpProxyPort <port>] [-snmpRetries <number>] [-snmpSecurityLevel (COMMUNITY_ONLY|COMMUNITY|NO_AUTH_NO_PRIV|AUTH_NO_PRIV|AUTH_PRIV|COMMUNITY_ONLY_V1)] [-snmpTimeout <timeout>] [-snmpV3Settings (<name>|<uuid>)] [-snmpWriteCommunity <community_string>]

nnmcommunication.ovpl updateSnmpV3Setting -snmpV3Setting (<name>|<uuid>) [-authPass <string>] [-authProtocol (HMAC_MD5_96|HMAC_SHA_1|HMAC128_SHA_224|HMAC192_SHA256|HMAC256_SHA_384|HMAC384_SHA_512)] [-contextName <string>] [-name <newName>] [-privPass <string>] [-privProtocol (DES_CBC|TripleDES|AES_128|AES_192|AES_256)] [-username <name>]

nnmcommunication.ovpl updateWebAgentSettings -node (<name>|<uuid>) [-mode <AUTO>|<LOCKED>] [-agentEnabled (true|false)] [-username <string>] [-password <string>] [-port <port>] [-scheme (HTTP|HTTPS)] [-timeout <duration>] [-cert <cert_file>]

DESCRIPTION

nnmcommunication.ovplコマンドラインの一般的なフォーマットは次のとおりです。

nnmcommunication.ovpl <command> <options>

下記の「Commands」項には，使用可能なコマンドの選択肢が一覧表示されています。同様に「Options」項には，各コマンドで使用可能なオプションが一覧表示されています。多くのコマンドで類似のオプションを使用できます。各コマンドで使用できる正しいオプションについては，上記の「SYNOPSIS」項を参照してください。

Commands

-h | -help

コマンドの使用方法を表示します。

addCertificate

デバイスの信頼済み証明書を通信の設定のデフォルト，特定のノード，または領域の設定に追加します。

addCommunity

デフォルトまたは領域の設定にコミュニティ文字列を追加します。順序が設定されていない場合，指定したコミュニティ文字列は最後に試行されます。

addCredential

デバイスの資格証明を通信の設定のデフォルト，特定ノード，または領域の設定に追加します。

addSnmpV3Setting

デフォルト設定または領域の設定に指定されたSNMPv3の設定を割り当てます。

createAddressRange

領域<region>に新しいアドレス範囲のエントリを作成します。領域には複数のアドレス範囲を設定できます。

createHostnameFilter

新しいホスト名フィルターエントリを作成します。

createNodeSettings

新しい特定ノードの設定を作成します。

createRegionSettings

新しい領域の設定を作成します。

createSnmpV3Settings

新しいSNMPv3設定を作成します。

delete

領域の設定，特定ノードの設定，またはSNMPv3の設定を削除します。

deleteAddressRange

一つ以上のアドレス範囲のエントリを削除します。

deleteHostnameFilter

一つ以上のホスト名フィルターのエントリを削除します。

listAddressRanges

アドレス範囲のエントリを一覧表示します。

listCertificates

通信の設定のデフォルト，特定ノード，または領域の設定に設定された，デバイスの信頼済み証明書のリストを表示します。

listCommunities

デフォルトまたは領域の設定のコミュニティ文字列を一覧表示します。

listCredentials

通信の設定のデフォルト，特定のノード，または領域の設定に設定された，デバイスの資格証明リストを表示します。

listDefaults

デフォルトの通信の設定を一覧表示します。

listEffective

ノードに設定されている有効な通信の設定を一覧表示します。

listHostnameFilters

ホスト名フィルターのエントリを一覧表示します。

listNodeSettings

特定ノードの設定を一覧表示します。

listRegionSettings

設定済みの領域を一覧表示します。領域名が指定されている場合は，その領域だけを一覧表示します。領域名が指定されていない場合は，すべての領域を一覧表示します。

listSnmpAgentSettings

ローカルNNMiサーバーで管理しているSNMPエージェントのアクティブな設定を一覧表示します。

listWebAgentSettings

ローカルのNNMi管理サーバーによって管理されるすべてのWeb Agentの設定を表示します。特定ノードで実行されているWeb Agentのリストを表示するには，ノードのホスト名またはUUIDをコマンドで指定します。

listSnmpV3Settings

SNMPv3設定を一覧表示します。固有名またはUUIDが指定されている場合は，その値に一致するSNMPv3設定だけを一覧表示します。固有名またはUUIDが指定されていない場合は，すべてのSNMPv3設定を一覧表示します。

removeCertificate

通信の設定のデフォルト，特定ノード，または領域に設定されているデバイスの信頼済み証明書を削除します。

removeCommunity

デフォルトまたは領域の設定から，コミュニティ文字列を削除します。

removeCredential

通信の設定のデフォルト，特定ノード，または領域に設定されているデバイスの資格証明を削除します。

removeSnmpV3Setting

デフォルトまたは領域の設定から，指定したSNMPv3設定を削除します。

updateSnmpAgentSettings

ローカルのNNMiサーバーが管理するノードのエージェントの設定を直接更新します。エージェントの設定を直接更新すると，コマンドに-mode AUTO引数を指定しない限り，エージェントのモードがLOCKED になります。

updateCredential

通信の設定のデフォルト，特定ノード，または領域に設定されているデバイスの資格証明を更新します。

updateDefaults

デフォルトの通信の設定フィールドを更新します。

updateNodeSettings

特定ノードの設定のフィールドを更新します。

updateRegionSettings

領域設定のフィールドを更新します。

updateSnmpV3Setting

SNMPv3設定を変更します。

updateWebAgentSettings

ローカルのNNMi管理サーバーによって管理されるノードでホストされるWeb Agentの設定を直接更新します。エージェントの設定を直接更新する場合，コマンドで-mode AUTO引数を指定しないときは，エージェントモードがLOCKEDになります。値を指定しないで"-cert"オプションを指定すると，Web Agent設定から信頼済み証明書を削除できます。

Options

このセクションでは，上記のコマンドに共通のオプションを示します。

-address <ip>

ノードに使用する管理アドレスです。

-addressDiscovery (true|false)

true の場合，NNMiは古い管理アドレスが応答しなくなったときに，新しい管理アドレスを検出しようとします。

-addressFilter <filter>

領域に含まれるノードをアドレスの範囲で指定します。例えば，10.1.0.0/16, 192.168.1-20.* または fc00::/7です。複数のエントリはセミコロンで区切ります。

-authPass <string>

SNMPv3認証パスフレーズです。

-authProtocol (HMAC_MD5_96|HMAC_SHA_1|HMAC128_SHA_224|HMAC192_SHA256|HMAC256_SHA_384|HMAC384_SHA_512)

SNMPv3 認証プロトコルです。

-cert <cert_file>

信頼済み証明書ファイルに対する完全修飾パスです。サポートされる信頼済み証明書ファイルの拡張子は，.pem，.crt，.cer，および.derです。

-community <string>

コミュニティ文字列です。

-contextName <string>

SNMPv3コンテキスト名です。

-default

add/update/removeオプションを指定した場合にデフォルト設定の値を変更します。listオプションの場合は，デフォルト設定を列挙します。

-description <description>

設定の説明です。

-enabled (true|false)

SNMPエージェントの有効，無効を設定します。

-fingerPrint <fingerPrint>

信頼済み証明書の公開鍵のフィンガープリントです。

-hostnameFilter <filter>

含まれるノードのホスト名のパターンです。例えば，*.usa.myco.comです。

-icmpEnabled (true|false)

trueの場合はICMP通信を有効にし，falseの場合は無効にします。

-icmpRetries <number>

ICMPのリトライ数です。

-icmpTimeout <timeout>

ミリ秒単位でのICMPのタイムアウトです。

-interfaceMatcher <value>

優先管理アドレスとして使用するインタフェースに一致する式です。

-managementAddress <ip>

ノードに使用する管理アドレスです。

-managementAddressSelection <ALG1,ALG2,ALG3>

管理アドレス選択アルゴリズムを実行する順番です。有効な値は，LOW_LOOPBACK, HIGH_LOOPBACK, SEED, またはINTERFACEです。INTERFACEを指定する場合は，<interfaceMatcher>パラメータも指定する必要があります。

-mode (AUTO|LOCKED)

エージェントのモードです。AUTOは設定からの適用を意味します。LOCKEDはユーザーによる明示的な設定を意味します。

-name <name>

名前で出力をフィルタリングします; ワイルドカードとして * と ? がサポートされています。

-name <name>

設定名です。

-name <newName>

更新後の名前です。

-node (<name>|<uuid>)

ノード名で出力をフィルタリングします; FQDN，短縮名，IPアドレス，およびUUIDがサポートされています。

-nodeSetting (<name>|<uuid>)

特定ノードの設定を指定します; 有効な入力はターゲットホスト名またはUUIDです。

-ordering <integer>

設定の優先順序です。設定は，1から大きい数値へと，優先順序に従って試行されます。同じ優先順序を持つ2つの項目があるとエラーになります。

-password <password>

デバイス通信のパスワードです。

-port <port>

SNMPエージェントのUDPポートです。

-preferIPVersion (IPv4|IPv6|IPAny)

（NNMi Advancedだけ）優先するIPバージョン設定です。

-privPass <string>

SNMPv3プライバシパスフレーズです。

-privProtocol (DES_CBC|TripleDES|AES_128|AES_192|AES_256)

SNMPv3プライバシプロトコルです。

-range <ip_range>

IPアドレス範囲です。例えば，192.168.1.0/24や192.168.1-10.*です。

-retries <integer>

SNMPのリトライ数です。

-region (<name>|<uuid>)

領域を指定します。有効な値は領域名またはUUIDです。

-serialNumber <serialNumber>

信頼済み証明書のシリアル番号です。

-shellCredential <credential>

デバイスの資格証明のパスワードです。

-shellUser <username>

デバイスの資格証明のユーザー名です。

-snmpCommunities <strings>

セミコロンで区切られたSNMP読み取りコミュニティ文字列のリストです。Linuxプラットフォーム上のシェルは，セミコロンを特殊文字として扱います。したがって，セミコロンが特殊文字として解釈されないように，リストを引用符で囲む必要があります。

-snmpCommunity <string>

ノードに使用するSNMPコミュニティです。

-snmpEnabled (true|false)

SNMP通信を有効または無効にします。

-snmpGetBulk (true|false)

trueの場合，NNMiはSNMPv2c GetBulkコマンドを使用します。

-snmpPort <port>

SNMP通信に使用するポートです。

-snmpPreferredVersion (V1|V2C|V3)

使用するSNMP優先バージョンです。

-snmpProxyAddress <ip>

使用するSNMPプロキシのIPアドレスです。SNMPプロキシを利用できるようにするには，SNMPプロキシポートも指定する必要があります。

-snmpProxyPort <ip>

SNMPプロキシによる通信に使用するポートです。SNMPプロキシを利用できるようにするには，SNMPプロキシアドレスも指定する必要があります。

-snmpRetries <number>

SNMPのリトライ数です。

-snmpSecurityLevel (COMMUNITY_ONLY|COMMUNITY|NO_AUTH_NO_PRIV|AUTH_NO_PRIV|AUTH_PRIV|COMMUNITY_ONLY_V1)

SNMP最小セキュリティレベルです。

-snmpTimeout <timeout>

ミリ秒単位でのSNMPのタイムアウトです。

-snmpV3Setting (<name>|<uuid>)

名前またはUUIDによりSNMPv3設定を指定します。

-snmpV3Settings (<name>|<uuid>)

名前またはUUIDによりSNMPv3設定を指定します。

-snmpWriteCommunity <community_string>

SNMP書き込みコミュニティ文字列です。

-timeout <duration>

SNMP AgentまたはWeb Agentのタイムアウトです。SNMP Agentの場合，1秒を1000またはPT1S，Web Agentの場合は1秒をPT1Sの形式で指定します。

-type <SHELL|VMWARE|CISCOACI>

資格情報のタイプ。有効な値はSHELL，VMWARE, CISCOACIです。

-username <name>

この設定のユーザー名です。

-uuid <uuid>

オブジェクトの一意の識別子です。

-version (V1|V2C|V3)

このエージェントが使用するSNMPバージョンです。有効な値はV1，V2CまたはV3です。

-writeCommunity <string>

SNMP書き込みコミュニティ文字列です。

-agentEnabled (true|false)

Web Agentの通信を有効または無効にします。

-scheme (HTTP|HTTPS)

Web Agentの通信に使用されるスキームです。

Additional Parameters

-fields <fields>

出力するフィールドを選択します。

-format <style>

テーブルデータの出力形式を設定します; 有効な値はTEXT, LIST, CSVまたはXMLです。

-http.host <host>

サーバーホストです;デフォルトはlocalhostです。

-http.port <port>

サーバーポートです;デフォルトは80です。

-p <password>

ユーザーのパスワードです。

-quiet

通常の出力を抑制し，エラーだけを出力します。

-u <username>

このコマンドを実行するためのユーザー名です。

EXAMPLES

米国内（ホスト名によって判定）のすべてのノードについて地域の設定を作成し，順序を10に設定します。

nnmcommunication.ovpl createRegionSettings -name UsaNodes -ordering 10 -hostnameFilter *.usa.myco.com.

一部のフィールドを設定するために上記で作成した領域設定を更新します。

nnmcommunication.ovpl updateRegionSettings -region UsaNodes -addressDiscovery true -snmpTimeout 200

上記で作成した領域設定を一覧表示します。

nnmcommunication.ovpl listRegionSettings -name UsaNodes

SNMPv3設定を作成します。

nnmcommunication.ovpl createSnmpV3Settings -name xyzSettings -username xyzUser -contextName xyzContext -authProtocol HMAC_MD5_96 -authPass myPass -privProtocol AES_192 -privPass myPrivPass

上記で作成したSNMPv3設定を一覧表示します。

nnmcommunication.ovpl listSnmpV3Settings -name xyzSettings

上記で作成したSNMPv3設定を使用して，ノードxyz.myco.comの特定ノードの設定を作成します。

nnmcommunication.ovpl createNodeSettings -name xyz.myco.com -snmpPreferredVersion V3 -snmpV3Setting xyzSettings

xyz.myco.comの有効なノードの設定を一覧表示します。

nnmcommunication.ovpl listEffective -node xyz.myco.com

xyz.myco.comのノードの設定を更新し，ICMPを無効にします。

nnmcommunication.ovpl updateNodeSettings -nodeSetting xyz.myco.com -icmpEnabled false

管理アドレスを更新し，ノードmynodeのエージェント設定をロックします。

nnmcommunication.ovpl updateSnmpAgentSettings -node mynode -address 192.168.1.1

mynodeのエージェント設定をロックせずに管理アドレスを更新します。

nnmcommunication.ovpl updateSnmpAgentSettings -node mynode -address 192.168.1.1 -mode AUTO

mynodeでホストされるWeb Agentを更新し，ポートを80に設定し，HTTPを使用し，3分でタイムアウトします。

nnmcommunication.ovpl updateWebAgentSettings -node mynode -port 80 -scheme HTTP -timeout PT3M

mynodeでホストされるWeb Agentを更新して，指定した信頼済み証明書を設定します。

nnmcommunication.ovpl updateWebAgentSettings -node mynode -cert /tmp/trustedCert-host1.pem

デフォルトの資格情報を新たに追加して，VMwareハイパーバイザーと通信します

nnmcommunication.ovpl addCredential -default -type VMWARE -username vmwareuser -password vmwarepass

デフォルトの資格情報をすべてリスト表示します。

nnmcommunication.ovpl listCredentials -default

デフォルトのVMWARE 資格情報を削除します。

nnmcommunication.ovpl removeCredential -default -type VMWARE

デフォルトのVMWARE資格情報を更新します。

nnmcommunication.ovpl updateCredential -default -type VMWARE -username username -password password

通信の設定のデフォルトの設定で，信頼済み証明書を追加します。

nnmcommunication.ovpl addCertificate -default -cert /tmp/trustedCert-host1.pem

通信の設定で「アメリカ」領域に設定された，すべての信頼済み証明書を表示します。

nnmcommunication.ovpl listCertificates -region Americas

デフォルトに設定された信頼済み証明書を対応するシリアル番号とともに削除します。

nnmcommunication.ovpl removeCertificate -default -serialNumber "1111111111"

AUTHOR

nnmcommunication.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmcommunication.ovpl

Linux：$NNM_BIN/nnmcommunication.ovpl

付録G.13　nnmconfigexport.ovpl

構成情報をファイルにエクスポートします。このファイルから，ほかのシステムに構成情報をインポートすることができます。

SYNOPSIS

nnmconfigexport.ovpl -? | -c <configuration>[,configuration...] [-a <author_key>] [-u <username> -p <password>] [-x <file_prefix>] [-f <output file or directory>]

DESCRIPTION

nnmconfigexport.ovplはカスタム構成情報を標準出力またはファイルにエクスポートするPerlスクリプトです。

Parameters

nnmconfigexport.ovplコマンドは，次のオプションをサポートします。

-?

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-c <configuration>[,configuration...]

指定した構成情報のXMLスキーマをエクスポートします。複数のファイルを指定するときは，カンマ（,）で区切ります。なお，複数の構成情報ファイルがある場合，-fオプションには必ずディレクトリを指定します。

指定可能な構成情報ファイル：

account

ユーザーアカウント，ユーザーグループおよびユーザーアカウントのマッピングをエクスポートします。

author

作成者をエクスポートします。-aオプションでフィルターすることもできます。

customCorrelation

カスタム相関処理の設定をエクスポートします。-aオプションでフィルターすることもできます。

comm

通信の設定をエクスポートします。SNMPv3の通信の設定はエクスポートされません。このデータに対する暗号化アルゴリズムは，NNMi固有の内部キーに依存しています。このデータはインポートできないため，エクスポート対象から除外しています。

custpoll

カスタムポーラーの設定をエクスポートします。

device

デバイスのプロファイルをエクスポートします。-aオプションでフィルターすることもできます。

disco

検出の設定（シードを除く）をエクスポートします。

discoseed

検出シードをエクスポートします。

icons

アイコンをエクスポートします。-aオプションでフィルターすることもできます。

ifgroup

インタフェースグループをエクスポートします。

iftype

インタフェース種別（ifTypes）をエクスポートします。

incident

インシデントの設定をエクスポートします。-aオプションでフィルターすることもできます。

menu

メニューをエクスポートします。-aオプションでフィルターすることもできます。

menuitem

アクションメニューに設定されたすべてのメニュー項目をエクスポートします。-aオプションが指定された場合，関連する親のメニューやサブメニューも出力に含まれます。

mibexpr

MIB式をエクスポートします。-aオプションでフィルターすることもできます。

mibtypes

MIB OIDタイプをエクスポートします。

monitoring

モニタリングの設定をエクスポートします。

nodegroup

ノードグループをエクスポートします。

ngmap

ノードグループマップをエクスポートします。ノードの座標を正しくインポートするには，両マシン間でノードのホスト名を一致させる必要があります。

oam

重複するIPアドレスマッピングをエクスポートします。

security

セキュリティグループおよびテナントをエクスポートします。

securitymappings

セキュリティグループのマッピングをエクスポートします。

status

ノードグループのステータス設定をエクスポートします。

trap

トラップログ記録設定をエクスポートします。-aオプションでフィルターすることもできます。

ui

ユーザーインタフェースの設定をエクスポートします。

all

有効な構成領域をすべてエクスポートします。このオプションに関しては，出力先はディレクトリでなければなりません。

-a <author_key>

指定した作成者キーを持つ作成者が作成した構成項目だけを，インクリメンタルインポート用の特殊なXML形式でエクスポートします。nnmconfigimport.ovplはこのXML形式を自動的に検出するので，特別なオプションを指定する必要はありません。このオプションは，author，customCorrelation，device，icons，incident，menu，menuitem，mibexpr，およびtrapの各構成情報ファイルに対してだけ有効です。有効な作成者キーは，作成者のインポートを行うことで調べることができます。「EXAMPLES」の項に示す例を参照してください。

-f <output file or directory>

指定したファイルまたはディレクトリに出力内容を保存します。

-x <file_prefix>

出力先としてディレクトリを指定した場合に，出力ファイルの命名に使用するファイル名プレフィックスを指定します。ファイルは <prefix>-<area>.xmlの名前になります。

EXAMPLES

nnmconfigexport.ovpl -u myusername -p myadminpassword -c comm

通信の設定を標準出力にエクスポートします。

nnmconfigexport.ovpl -u myusername -p myadminpassword -c comm,disco -f /tmp -x my

通信の設定と検出の設定を/tmp/my-comm.xmlファイルおよび/tmp/my-disco.xmlファイルにエクスポートします。

nnmconfigexport.ovpl -u myusername -p myadminpassword -c author

作成者キーおよびラベルを持つ作成者すべてを標準出力にエクスポートします。

nnmconfigexport.ovpl -u myusername -p myadminpassword -c menuitem -a com.mycorp.nnm.author -f /tmp/mycorpmenuitems.xml

作成者キーがcom.mycorp.nnm.authorの作成者によって作成されたメニュー項目の設定を/tmp/mycorpmenuitems.xmlファイルにエクスポートします。

AUTHOR

nnmconfigexport.ovpl was developed by Micro Focus.

SEE ALSO

nnmconfigimport.ovpl, nnm.properties.

付録G.14　nnmconfigimport.ovpl

nnmconfigexport.ovplのXML出力をNNMiデータベースにインポートします。

SYNOPSIS

nnmconfigimport.ovpl -? | [-u <username> -p <password>] -f <input file or directory> [-x <file_prefix>] [-memory <number of megabytes>] [-timeout <time in seconds>]

DESCRIPTION

nnmconfigimport.ovplは，nnmconfigexport.ovplの出力をNNMiデータベースにインポートするPerlスクリプトです。

注意：アクションをインポートし，変更内容を有効にするには，NNMi コンソールを再起動（サインアウトしてからサインイン）する必要があります。

Parameters

nnmconfigimport.ovpl コマンドは，次のオプションをサポートします。

-?

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-f <input file or directory>

指定した構成XMLファイルをインポートします。ディレクトリが指定された場合は，ディレクトリ内のファイルすべてをインポートします。

-x <file_prefix>

-fオプションを使用してディレクトリを指定する場合に，インポート対象となるファイルをフィルタリングするためのファイルプレフィックスを指定します。依存関係でソートされ，指定したディレクトリ内にある，名前が<prefix>-*のファイルがインポートされます。

-memory <memory in megabytes>

nnmconfigimport.ovplコマンドを動作させるために割り当て可能なメモリサイズを指定します。デフォルトは1536MBですが，サイズの大きいファイルに対しては，この値を2048に設定する必要があるかもしれません。このオプションは実際にインポートを行うツールに渡されるのではなく，ただ単にnnmconfigimport.ovplを動作させるために使用するものであるため，使用方法メッセージ（Usage）には表示されません。

-timeout <time in seconds>

特定のファイルのインポートを完了するために利用できる時間を指定します。インシデントなど一部の構成情報の形式は，データ量に応じてより大きなタイムアウト値を必要とすることがあります。デフォルト値は3600秒(60分)です。このオプションは実際にインポートを行うツールに渡されるのではなく，ただ単にnnmconfigimport.ovplを動作させるために使用するものであるため，使用方法メッセージ（Usage）には表示されません。

NOTES

nnmconfigimport.ovplコマンドは，大部分のエリアでは，既存の設定に追加を行います。また，検出，通信，モニタリング，およびステータスのような一部のエリアでは，既存の設定を置き換えます。詳細は，NNMi ヘルプ［エクスポート/インポート時の動作と依存関係］を参照してください。

設定項目を追加するためには，作成者キーを指定して nnmconfigexport.ovpl を実行してください。

nnmconfigimport.ovplは自動的にnnmconfigexport.ovpl が作成者キーを指定して実行されたかを検知して，設定を置き換える代わりに追加します。

インポートする前に，nnmconfigexport.ovpl の出力を編集しないでください。

EXAMPLES

nnmconfigimport.ovpl -u username -p password -f /tmp/nnmconfig.xml

カスタム構成情報を/tmp/nnmconfig.xmlファイルからNNMiデータベースにインポートします。（NNMiユーザー名とパスワードを指定する必要があります。この例では，ユーザー名はusername，パスワードはpasswordです。）

AUTHOR

nnmconfigimport.ovpl was developed by Micro Focus.

SEE ALSO

nnmconfigexport.ovpl，nnm.properties.

付録G.15　nnmconfigpoll.ovpl

ノードに対してポーリングを行って検出情報を取得します。

SYNOPSIS

nnmconfigpoll.ovpl [-v] [-t timeout in secs] [-u <username> -p <password>] [-tenant <name>] node

DESCRIPTION

nnmconfigpoll.ovpl コマンドは，要求を検出サービスに送信して，ノードにポーリングを行って検出情報を取得します。ノードは，検出されたトポロジに存在する必要があります。node パラメータは，トポロジでのノード名またはノードに関連する IP アドレスを指定できます。

nnmconfigpoll.ovpl コマンドを実行すると，ノードに対してレイヤー2 接続解析が開始されます。検出サービスがデバイスにポーリングを行うと，NNMi コンソールにレイヤー3 検出情報のステータスメッセージが表示されます。

なお，このコマンドによるポーリングで得られるのは検出情報です。ステータス情報のポーリングを行うには，nnmstatuspoll.ovpl コマンドを使用します。

Parameters

nnmconfigpoll.ovpl コマンドは，次のパラメータおよびオプションをサポートします。

-v

検出ポーリングに関する詳細な情報を表示します。

-t <timeout in secs>

クライアントは，秒単位で指定したタイムアウトの秒数だけ応答を待ちます。

-u <username>

コマンドの実行に必要な NNMi の管理者名を指定します。nnm.properties ファイルが存在していない限り，これが必要になります。詳細はnnm.properties リファレンスページを参照してください。

-p <password>

コマンドの実行に必要な NNMi の管理者パスワードを指定します。nnm.properties ファイルが存在していない限り，これが必要になります。詳細はnnm.properties リファレンスページを参照してください。

-tenant <name>

ノードが属するテナントを指定します。重複した IP アドレスを使用しているなど，ノード名がネットワーク内で一意でない場合に使用する必要があります。デフォルトはありません。

EXAMPLES

nnmconfigpoll.ovpl コマンドを使用して，ノードのポーリングを行う方法の例を次に示します。

ノード名を使用してノードのポーリングを行う場合の例：

nnmconfigpoll.ovpl -u username -p password thisnode

完全修飾されたノード名を使用してノードのポーリングを行う場合の例：

nnmconfigpoll.ovpl -u username -p password thisnode.x.y.z

IP アドレスを使用してノードのポーリングを行う場合の例：

nnmconfigpoll.ovpl -u username -p password 10.97.247.129

IP アドレスとテナント名を使用してノードのポーリングを行う場合の例：

nnmconfigpoll.ovpl -u username -p password -tenant myDuplicateAddressesDomain 10.97.247.129

AUTHOR

nnmconfigpoll.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmconfigpoll.ovpl

Linux：$NNM_BIN/nnmconfigpoll.ovpl

SEE ALSO

nnmstatuspoll.ovpl.

付録G.16　nnmconnedit.ovpl

L2（レイヤー2）接続トポロジを修正します。ユーザーは接続を追加したり削除したりできます。

SYNOPSIS

nnmconnedit.ovpl -f corrections file -t [add|delete] [-help] [-u <username> -p <password>]

DESCRIPTION

さまざまな要因により，NNMi L2 接続トポロジの検出には誤りが混入する可能性があります。nnmconnedit.ovpl コマンドは，ユーザーが接続を追加したり削除したりする方法を提供します。修正ファイルは，次の構造の XML 形式で管理者が作成します。

<connectionedits>
    <connection>
        <operation>add または delete</operation>
        <node>ショートネーム，ロングネーム，または IP アドレス</node>
        <interface>ifName, ifAlias, ifDescr または ifIndex</interface>
        <node>ショートネーム，ロングネーム，または IP アドレス</node>
        <interface>ifName, ifAlias, ifDescr または ifIndex</interface>
    </connection>
</connectionedits>

各要素の説明：

operation 接続を追加するのか削除するのかを指定します。

node ショートネーム，ロングネーム（DNS 名），または IP アドレスで識別されます。

interfaceifIndex, ifName, ifDescr, または ifAlias の順で識別されます。 この値は一意である必要があります。ただし， ifIndex の使用は，デバイスによっては，サポートされているインタフェース再ナンバリング機能によって妨げられることがあります。 非 SNMP ノードでは， ifAlias または ifDescr の使用を推奨します。

connection ごとに，node および interface が少なくとも二つずつ必要です。node の数と interface の数は一致している必要があります。node および interface のペアはエンドポイントとして知られ， connection 一つに，エンドポイントを二つ以上指定できます。修正ファイルに複数の connection を指定できます。

接続を追加するときは，所属している可能性のある既存の接続から各エンドポイントが削除され，新しい接続へ追加されます。connection に三つ以上のエンドポイントが指定されている場合，接続はマップ上に共有メディア接続シンボルとして表示されます。connection に，NNMi データベースに既に存在する接続を指定している場合は，何も変更されません。

接続を削除する場合は，同じ組み合わせのエンドポイントを持つ接続が既に NNMi データベースに存在している場合を除いて，何も変更されません。その場合，指定したエンドポイントすべてが切断状態のままとなります。ネットワーク機器が接続を報告している場合，その接続を一時的に削除するだけです。この場合，削除された接続は，NNMi が次回その接続先にあるノードを検出したときに再表示されます。

Parameters

nnmconnedit.ovpl コマンドは，次のパラメータおよびオプションをサポートします。

-f corrections file

接続追加および削除命令が指定された定型ファイルの名前を指定します。

-t [add | delete]

修正ファイルを作成するときに使用できるテンプレートファイルを生成します。addを指定すると追加操作テンプレートが作成され，delete を指定すると削除操作テンプレートが作成されます。

-u <username>

コマンドの実行に必要な NNMi の管理者名を指定します。nnm.properties ファイルが存在していない限り，これが必要になります。詳細は nnm.properties リファレンスページを参照してください。

-p <password>

コマンドの実行に必要な NNMi の管理者パスワードを指定します。nnm.properties ファイルが存在していない限り，これが必要になります。詳細はnnm.properties リファレンスページを参照してください。

help

このオプションを指定すると，コマンドの使用方法が表示されます。

EXAMPLES

NNMi の検出サービスが，異なるメーカーの二つのスイッチ間の L2 接続を見つけられなかったとします。この場合は，まず各デバイスで接続の必要があるノード名とインタフェース名を取得します。そして，nnmconnedit.ovplコマンドに-t オプションを指定して add テンプレートファイルを作成します。次に，作成したテンプレートファイルを編集してノードおよびインタフェースの情報を指定します。編集が終わったら，mychg.xmlファイルとして保存します。

mychg.xml（add テンプレートファイル）の例を次に示します。

<connectionedits>
    <connection>
        <operation>add</operation>
        <node>nodeA.x.y.z</node>
        <interface>fa/09</interface>
        <node>nodeB.x.y.z</node>
        <interface>fa/05</interface>
    </connection>
</connectionedits>

最後に，mychg.xmlファイルを-fオプションに指定してnnmconnedit.ovplコマンドを実行します。

nnmconnedit.ovpl -u username -p password -f mychg.xml

NNMi の検出サービスが，存在しないはずの L2 接続を作成する問題があるとします。 この場合は，まず不正な connection から，ノード名とインタフェース名を取得します。そして，nnmconnedit.ovplコマンドに -t オプションを指定して delete テンプレートファイルを作成します。次に，作成したテンプレートファイルを編集してノードおよびインタフェースの情報を指定します。編集が終わったら，mychg.xmlファイルとして保存します。

mychg.xml（delete テンプレートファイル）の例を次に示します。

<connectionedits>
    <connection>
        <operation>delete</operation>
        <node>nodeA.x.y.z</node>
        <interface>fa/09</interface>
        <node>nodeB.x.y.z</node>
        <interface>fa/05</interface>
    </connection>
</connectionedits>

最後に， mychg.xml ファイルを -f オプションに指定して nnmconnedit.ovpl コマンドを実行します。

nnmconnedit.ovpl -u username -p password -f mychg.xml

AUTHOR

nnmconnedit.ovpl was developed by Micro Focus.

付録G.17　nnmcustompollerconfig.ovpl

nnmcustompollerconfig.ovpl は，カスタムポーラー設定を表示，更新します。

SYNOPSIS

nnmcustompollerconfig.ovpl

nnmcustompollerconfig.ovpl createDeltaMap [-uuid <object uuid>] -variable <name>|<uuid> -stateMapping <statemapping> (-increaseInValue <increase in value> | -dropInValue <drop in value>| -increaseInValue <increase in value> -dropInValue <drop in value> )

nnmcustompollerconfig.ovpl deleteDeltaMap -deltaMap <uuid> | -list <csv list of identifiers>

nnmcustompollerconfig.ovpl listDeltaMap [-uuid <object uuid>] [-variable <name>|<uuid>] [-stateMapping <state mapping>] [-increaseInValue <increase in value>] [-dropInValue <drop in value>]

nnmcustompollerconfig.ovpl updateDeltaMap -deltaMap <uuid> { [-stateMapping <state mapping>] [-increaseInValue <increase in value>] [-dropInValue <drop in value> ] }

nnmcustompollerconfig.ovpl listCollection [-name <name>]

nnmcustompollerconfig.ovpl listPolicy [-activeState <active state>] [-collection <name>|<uuid>] [-name <name>] [-nodeGroup <name>|<uuid>] [-uuid <object uuid>]

nnmcustompollerconfig.ovpl updatePolicy -policy <name>|<uuid> [-activeState <active state>]

DESCRIPTION

nnmcustompollerconfig.ovpl コマンドラインの一般的なフォーマットは次のとおりです。

nnmcustompollerconfig.ovpl <command> <options>

下記のCommands項には，使用可能なコマンドの選択肢が一覧表示されています。同様にOptions項には，各コマンドで使用可能なオプションが一覧表示されています。 多くのコマンドで類似のオプションを使用できます。各コマンドで使用できる正しいオプションについては，上記のSynopsis項を参照してください。

Commands

createDeltaMap

MIB変数に対する差分マップを作成します。

deleteDeltaMap

MIB変数から差分マップを削除します。

listDeltaMap

オプションのフィルタに基づいて差分ベースのしきい値を一覧表示します。

updateDeltaMap

差分マップのフィールドをアップデートします。

listCollection

オプションのフィルターに基づいて，収集の一覧を表示します。フィルターを指定しない場合，すべての収集が一覧表示されます。

listPolicy

オプションのフィルターに基づいて，ポリシーの一覧を表示します。フィルターを指定しない場合，すべてのポリシーが一覧表示されます。

updatePolicy

ポリシーのフィールドを更新します。

Options

-activeState <active state>

ポリシーのアクティブ状態を指定します。( active | inactive | suspended )

-collection <name>|<uuid>

収集の名前または uuid を指定します。

-name <name>

設定の名前を指定します。

-nodeGroup <name>|<uuid>

ポリシーが適用されているノードグループの名前または uuid を指定します。

-policy <name>|<uuid>

ポリシーの名前または uuid を指定します。

Additional Parameters

-fields <fields>

表形式のデータが存在しているときに出力フィールドを選択します。

-format <style>

表形式のデータが存在しているときに出力形式を変更します。指定できる値は，"TEXT", "LIST", "CSV", または "XML" です。

-http.host <host>

サーバーのホスト。デフォルトは localhost です。

-http.port <port>

サーバーのポート。デフォルトは 80 です。

-u <username>

コマンドの実行に必要な NNMi の管理者名を指定します。

-p <password>

コマンドの実行に必要な NNMi の管理者パスワードを指定します。

-quiet

通常の出力を抑制し，エラーだけを表示します。

EXAMPLES

カスタムポーラーポリシーを一括でACTIVEにする場合は，以下のようなサンプルバッチファイルまたはサンプルシェルスクリプトを参考にスクリプトを作成し実行してください。

Windows の場合のサンプルバッチファイル:

@echo off for /f "usebackq" %%i in (`nnmcustompollerconfig.ovpl listPolicy -format CSV -fields uuid`) do ( if not %%i == UUID ( nnmcustompollerconfig.ovpl updatePolicy -policy %%i -activeState ACTIVE ) )

Linux の場合のサンプルシェルスクリプト:

#!/bin/sh /opt/OV/bin/nnmcustompollerconfig.ovpl listPolicy -format CSV -fields uuid | while read line do if [ ! $line == UUID ]; then /opt/OV/bin/nnmcustompollerconfig.ovpl updatePolicy -policy $line -activeState ACTIVE fi done

差分マップの作成

nnmcustompollerconfig.ovpl createDeltaMap -variable TestVariable -stateMapping major -increaseInValue 100 -dropInValue 5

差分マップの更新

nnmcustompollerconfig.ovpl updateDeltaMap -deltaMap <uuid> -increaseInValue 90

差分ベースのしきい値の一覧表示

nnmcustompollerconfig.ovpl listDeltaMap -variable TestVariable

差分マップの削除

nnmcustompollerconfig.ovpl deleteDeltaMap -deltamap <uuid>

nnmcustompollerconfig.ovpl deleteDeltaMap -list uuid1,uuid2,uuid3

AUTHOR

nnmcustompollerconfig.ovpl was developed by Micro Focus.

FILES

$NNM_BIN/nnmcustompollerconfig.ovpl

付録G.18　nnmdeleteattributes.ovpl

CSVファイルまたはコマンドラインから，ノード，インタフェース，および物理コンポーネント（カード/シャーシ）に対してカスタム属性を削除します。

SYNOPSIS

nnmdeleteattributes.ovpl [-h | -help] -t <type> (-f <path & filename of csv file>) |(-s <"csv formatted line">) [-u <username> -p <password>]

DESCRIPTION

nnmdeleteattributes.ovplは，CSVファイルに指定したカスタム属性を削除します。以前作成した不要なカスタム属性を削除するときに有用です。ノード，インタフェースまたは物理コンポーネントからカスタム属性を削除します。ノードからカスタム属性を削除すると，カスタム属性を参照して形成されたノードグループからノードが削除されます。

Parameters

nnmdeleteattributes.ovplコマンドは，次のオプションをサポートします。

-h | -help

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-t <type>

削除対象のオブジェクトタイプを指定します。"node"，"interface"または "physcomp"です。

-f <path & filename of csv file>

削除するカスタム属性を含むCSVファイル名（パス名。例: /tmp/csvfile.csv）を指定します。

-s <"csv formatted line">

CSV形式の1行を指定します。小さな変更に対してファイル作成を省略できます。

Syntax of Comma Separated File for Nodes

ノードからカスタム属性を削除するときに指定するCSVファイルの構文は次のとおりです。

空の行は無視されます。

"#"で始まる行は無視されます。

Column 1(A)：Node DNS|IP Address

ノードのDNS名か，IPアドレスを指定します。このフィールドは必須です。

Column 2(B)：Attribute Name

カスタム属性の名前。

削除するカスタム属性は，同じ行に指定できます。または，別の行で同じノードを指定します。

例）

192.168.1.1,Project,Service Type

192.168.1.1,Asset Tracking

192.168.2.2,Project,Service Type,Asset Tracking

Syntax of Comma Separated File for Interfaces

インタフェースからカスタム属性を削除するときに指定するCSVファイルの構文は次のとおりです。

空の行は無視されます。

"#"で始まる行は無視されます。

Column 1(A)：Node DNS|IP Address

ノードのDNS名か，IPアドレスを指定します。このフィールドは必須です。

Column 2(B)：Interface Id

前のフィールドで指定したノードのインタフェースの識別子を指定します。インタフェースのインデックス，エイリアス，インタフェース名，または説明が指定でき，この順序で検索されます。すべての一致するインタフェースに対して，属性が削除されます。このフィールドは必須です。

Column 3(C)：Attribute Name

カスタム属性の名前。

削除するカスタム属性は，同じ行に指定できます。または，別の行で同じノードとインタフェース識別子を指定します。

例）

192.168.1.1,1001,Project,Service Type

192.168.1.1,1001,Asset Tracking

192.168.2.2,A1,Project,Service Type,Asset Tracking

Syntax of Comma Separated File For PhysComp Attributes

物理コンポーネント（カード/シャーシ）からカスタム属性を削除するときに指定するCSVファイルの構文は次のとおりです。

空の行は無視されます。

"#"で始まる行は無視されます。

Column 1(A)：Node DNS | IP Address

ノードのDNS名か，IPアドレスを指定します。このフィールドは必須です。

Column 2(B)：PhysComp Id

前のフィールドで指定したノードの物理コンポーネントの識別子を指定します。物理コンポーネントの物理インデックス，名前，または説明が指定でき，この順序で検索されます。すべての一致する物理コンポーネントに対して，属性が削除されます。このフィールドは必須です。

Column 3(C)：PhysComp Type

物理コンポーネントのタイプを識別する名前。"card"と"chassis"が有効なタイプです。

Column 4(D)：Attribute Name

カスタム属性の名前。

削除するカスタム属性は，同じ行に指定できます。または，別の行で同じノードと物理コンポーネント識別子，物理コンポーネントタイプを指定します。

例）

192.168.1.1,7,chassis,Location,Service Type

192.168.1.1,7,chassis,Asset Tracking

192.168.2.2,/AmdFE,card,Location,Service Type,Asset Tracking

EXAMPLES

CSVファイルの内容例は次のようになります（ノードの場合）：

192.168.2.2,Project,Service Type,Asset Tracking

CSVファイルからノードのカスタム属性を削除します：

nnmdeleteattributes.ovpl -t node -f /tmp/test.csv

コマンドラインからノードのカスタム属性を削除します：

nnmdeleteattributes.ovpl -t node -s "192.168.1.1,Project"

CSVファイルの内容例は次のようになります（インタフェースの場合）：

192.168.2.2,1001,Project,Service Type,Asset Tracking

CSVファイルからインタフェースのカスタム属性を削除します：

nnmdeleteattributes.ovpl -t interface -f /tmp/test.csv

コマンドラインからインタフェースのカスタム属性を削除します：

nnmdeleteattributes.ovpl -t interface -s "192.168.1.1,7,Project"

CSVファイル（/tmp/test.csv）の内容例は次のようになります（物理コンポーネントの場合）：

192.168.2.2,7,chassis,Location,Service Type,Asset Tracking

CSVファイルから物理コンポーネントのカスタム属性を削除します：

nnmdeleteattributes.ovpl -t physcomp -f /tmp/test.csv

コマンドラインから物理コンポーネントのカスタム属性を一つ削除します：

nnmdeleteattributes.ovpl -t physcomp -s "192.168.1.1,/AmdFE,card,Project"

Error Codes

問題を特定するのに役立ついくつかのエラーコードがあります：

INFO：情報メッセージ。

ATTR_ERROR：指定された属性で問題が見つかりました。

DEL_FAIL_ERROR：指定された属性の削除に失敗しました。

OBJECT_ERROR：指定されたオブジェクトが見つかりませんでした。

BAD_LINE_ERROR：指定された行のフォーマットが正しくありません。

IO_ERROR：CSVファイルが見つからないか，読めませんでした。

BAD_NAME_WARNING：指定された属性名が長すぎます(最大 50 文字)。

BAD_VALUE_WARNING：指定された値が長すぎます(最大 2000 文字)。

AUTHOR

nnmdeleteattributes.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmdeleteattributes.ovpl

Linux：$NNM_BIN/nnmdeleteattributes.ovpl

SEE ALSO

nnmloadattributes.ovpl, nnmloadnodegroups.ovpl, nnm.properties.

付録G.19　nnmdeleteurlaction.ovpl

指定した作成者キーのメニューやメニュー項目を削除します。

SYNOPSIS

nnmdeleteurlaction.ovpl [-? | -h | -help] <authorKey> [-u username] [-p password]

DESCRIPTION

nnmdeleteurlaction.ovplは，指定した作成者キーに関するメニューやメニュー項目を削除するPerlスクリプトです。

注：メニューやメニュー項目を削除するためにnnmdeleteurlaction.ovplコマンドを使用した場合，変更を反映するために，NNMiコンソールを再起動（サインアウトしてからサインイン）する必要があります。

Parameters

nnmdeleteurlaction.ovplコマンドは，次のオプションをサポートします。

-? | -h | -help

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

nnmdeleteurlaction.ovpl -u username -p password com.mycompany

作成者キーcom.mycompanyのメニューとメニュー項目を削除します。

AUTHOR

nnmdeleteurlaction.ovpl was developed by Micro Focus.

SEE ALSO

nnmconfigimport.ovpl, nnmconfigexport.ovpl.

付録G.20　nnmdiscocfg.ovpl

SYNOPSIS

nnmdiscocfg.ovpl -autodisco rule=rulename rangetype=ignore|include [ -f ipAddressRangeFile | -n ipAddressRanges] [-u <username> -p <password>]

nnmdiscocfg.ovpl -excludeipaddrs [ -f ipAddressRangeFile | -n ipAddressRanges] [-u <username> -p <password>]

DESCRIPTION

nnmdiscocfg.ovplコマンドを使用すると，IPアドレスの範囲を既存の自動検出ルールに追加できます。IPアドレスの自動検出範囲は，検出機能がネットワーク上でどのようにデバイスを見つけるかを制御します。

また，IPアドレス範囲除外フィルターを追加することで，NNMiトポロジ内に望ましくないIPアドレスが作成されるのを防ぐことができます。フィルターに一致したアドレスは，ノードにもインタフェースにも関連付けされず，IPアドレスインベントリに表示されることもありません。IPアドレス範囲フィルターは，ネットワーク上のデバイスを自動検出が検索および識別する方法を制御しません。

Parameters

nnmdiscocfg.ovplコマンドは，次のパラメータおよびオプションをサポートします。

-autodisco rule=ruleName rangetype=ignore|include

ruleNameで指定した既存の自動検出ルールにIPアドレス範囲を追加します。この範囲は，「rangetype=include」または「rangetype=ignore」を指定することで，ルールに追加できます。

-excludeipaddrs

検出の「除外対象IPアドレス」設定にIPアドレス範囲を追加します。

-f ipAddressRangeFile

IPアドレス範囲が含まれる読み込み元テキストファイルを指定します。

-n ipAddressRanges

コマンドラインから直接読み込むIPアドレス範囲を指定します。複数のIPアドレス範囲を指定する場合はスペースで区切ります。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

IPアドレス範囲のリストを既存の自動検出ルールに追加する場合：

nnmdiscocfg.ovpl -u username -p password -autodisco rule=bld1floor2 rangetype=include -n 10.2.112.21-34 10.2.112.36 10.1.*.1-98

IPアドレス除外設定にIPアドレス範囲を追加する場合：

nnmdiscocfg.ovpl -u username -p password -excludeipaddrs -n 198.2.*.117

tmpディレクトリ内のローカルファイルシステムにあるファイルlab3devices.txtから，IPアドレス範囲を読み込む場合：

nnmdiscocfg.ovpl -u username -p password -autodisco rule=bld1floor2 rangetype=include -f /tmp/lab3devices.txt

tmpディレクトリ内のローカルファイルシステムにあるファイルignoreAddresses.txtから，IPアドレス範囲フィルターを読み込む場合：

nnmdiscocfg.ovpl -u username -p password -excludeipaddrs -f /tmp/ignoreAddresses.txt

AUTHOR

nnmdiscocfg.ovpl was developed by Micro Focus.

SEE ALSO

nnmnoderediscover.ovpl, nnm.properties.

付録G.21　nnmengineidfile.ovpl

SNMP V3 Engine IDファイルの管理が可能になります。

SYNOPSIS

nnmengineidfile.ovpl reload

nnmengineidfile.ovpl validate

DESCRIPTION

このコマンドでは，SNMP V3 Engine IDファイルのリロードや検証を行うことができます。コマンドを使用する前に，ファイルのパスをcom.hp.nnm.snmp.engineid.fileプロパティに指定する必要があります。SNMP V3 Engine IDファイルの詳細については，NNMiリリースノートの「21.8.1　SNMPv1またはSNMPv2cを使用して管理されているノードまたは監視対象外のノードのSNMPv3トラップを認証するためのNNMiの設定」の章を参照してください。

nnmengineidfile.ovplコマンドラインの一般的な形式は以下のとおりです。

nnmengineidfile.ovpl <command>

「Commands」セクションで，command部分に設定可能な選択肢をそれぞれ説明します。

Commands

reload

SNMP V3 Engine IDファイルの内容をリロードします。

validate

SNMP V3 Engine IDファイルの内容を検証します。現在のSNMPv3キャッシュには影響しません。

Additional Parameters

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。

AUTHOR

nnmengineidfile.ovpl was developed by Micro Focus.

FILES

$NNM_BIN/nnmengineidfile.ovpl

付録G.22　nnmhealth.ovpl

NNMiの自己監視情報を表示します。

SYNOPSIS

nnmhealth.ovpl [-u <username> -p <password>] ( -print [quiet|brief|detailed|conclusions|verbose|agents|history] [-refresh] | -activate <conclusions> | -suppress <conclusions> ) | -help

DESCRIPTION

nnmhealth.ovplは，NNMiの自己監視情報を出力します。戻り値のみで出力がない(quiet)から，すべての自己監視情報をレポートする(verbose)まで，いくつかのレベルをサポートします。

NNMiの現在の自己監視情報を表示することに加えて，個々の状態の自己監視結果を抑制したり，有効化したりするために使用できます。管理者は，問題を監視し，問題が解決されるまでそれ以上の警告が表示されることを望まないのであれば，自己監視結果を抑制できます。

管理者がnnmhealth.ovplコマンドを使用して抑制リストを編集した場合，次の自己監視スキャン時に有効になります。管理者が有効化するか，NNMiを再起動するまで，抑制は継続します。

NNMiの再起動後も抑制を継続したい場合は，nms-topology.propertiesのcom.hp.ov.nms.health.SUPPRESSED_CONCLUSIONSプロパティが使用できます。このプロパティの値の書式は，nnmhealth.ovplコマンドの-suppressオプションと同じ書式です。

Parameters

nnmhealth.ovplコマンドは，次のオプションをサポートします。

-u <username>

コマンドの実行に必要な NNMi の管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-print <level>

NNMiの自己監視の情報を出力します。レベルは次のいずれかです。

brief|conclusions|detailed|agents|quiet|verbose|history

レベルが指定されていない場合，デフォルトはbriefになります。

-print brief：システムの全体ステータスを出力します。値は次のいずれかです。

正常域

注意域

警戒域

重要警戒域

危険域

-print conclusions：有効な結果と抑制の結果を出力します。

-print detailed：システムの詳細な自己監視情報を出力します。

-print agents：登録されているエージェントを出力します。

-print quiet：システムのステータスを表す整数値を返します。値は次のいずれかです。

0 - 正常域

1 - 注意域

2 - 警戒域

3 - 重要警戒域

4 - 危険域

-print verbose [-filter AgentList]：登録されているすべてのエージェントの詳細な自己監視情報を出力します。必要に応じて，-filterオプションを使用して，カンマ区切りのエージェント名を指定することができます。詳細な出力はサポートにだけ使用します。

-print history：登録されているエージェントの履歴情報を出力します。

-refresh

-printのオプション引数です。このオプションを使用すると，監視システムがレポートを返す前に情報を更新します。

-suppress <conclusions>

NNMiが次に再起動されるか，結果が再度有効化されるまで，指定した結果を抑制します。結果は，カンマ区切りのリストで指定できます。抑制できる有効な結果は-print conclusionsで表示されます。

抑制している結果は，それまで有効であったということではないことに注意してください。

-activate <conclusions>

抑制リストから指定した結果を削除します。結果は，カンマ区切りのリストで指定できます。 再度有効化できる結果は-print conclusionsで取得できます。

-help

コマンドの使用方法を表示します。

EXAMPLES

nnmhealth.ovpl -u username -p password -print brief

NNMiの全体ステータスを出力します。

nnmhealth.ovpl -u username -p password -print brief -refresh

NNMiの現在のステータスを更新して出力します。

nnmhealth.ovpl -u username -p password -print detailed

現在の自己監視の警告一覧を出力します。

nnmhealth.ovpl -u username -p password -print agents

自己監視の関連情報を報告する登録済みエージェントの現在の一覧を出力します。

nnmhealth.ovpl -u username -p password -print history

登録済み自己監視エージェントの履歴情報を出力します。

nnmhealth.ovpl -u username -p password -suppress "SystemLowSwap,SystemLowSwapPercent"

スワップ領域の絶対値とパーセンテージに関する自己監視のチェックをスキップするようNNMiを設定します。

nnmhealth.ovpl -u username -p password -activate "SystemLowSwap"

SystemLowSwap結果に対して，再度チェックするようNNMiを設定します。

AUTHOR

nnmhealth.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_PROPS%¥nms-topology.properties

UNIX：$NNM_PROPS/nms-topology.properties

付録G.23　nnmicons.ovpl

NNMiのUI設定

SYNOPSIS

nnmicons.ovpl -help

nnmicons.ovpl -list | -create (<iconSpec1,iconSpec2,...> | -file <file>) | -update (<iconSpec1,iconSpec2,...> | -file <file>) | -delete (<iconName1,iconName2,...> | -file <file>) [-u <username> -p <password>]

DESCRIPTION

nnmicons.ovplは，NNMiのデータベースに保存されているアイコンへのアクセスを提供します。アイコンは，一覧表示，作成，更新，および削除することができます。

Parameters

nnmicons.ovplコマンドは，次のオプションをサポートします。

-list

NNMiデータベースに保存されているアイコンの一覧を表示します。

-create (<iconSpec1,iconSpec2,...> | -file <file>)

アイコンの定義，または入力ファイルのいずれかを使用して，アイコンを作成します。

<iconSpec1,iconSpec2,...>

アイコンの定義のリストはカンマで区切ります。iconSpecNは，次の形式で指定します。iconName:authorKey[:<iconImageSpec1>[:<iconImageSpec2>]]

iconImageSpecNは，size:pathの形式で指定します。sizeはピクセル単位の正方形の画像の大きさで，16または32である必要があります。pathは画像ファイルへのファイルパスを指定します。画像ファイルは，GIF，JPEG，またはPNG形式で，対応するファイルの拡張子は，.gif，.jpeg，.jpg，または.pngのいずれかである必要があります。

-file

1行につき一つのiconSpecのリストが含まれるファイルへのパスです。空白行やコメントをファイルに含めることができます。コメントは，行の先頭の'#'記号で表します。

-update (<iconSpec1,iconSpec2,...> | -file <file>)

アイコンの定義，または入力ファイルのいずれかを使用して，アイコンを更新します。アイコンが存在しない場合は，作成されます。

<iconSpec1,iconSpec2,...>

アイコンの定義のリストはカンマで区切ります。iconSpecNは，次の形式で指定します。iconName:authorKey:<iconImageSpec1>:<iconImageSpec2>:...

iconImageSpecは，size:pathの形式で指定します。sizeはピクセル単位の正方形の画像の大きさです。pathは画像ファイルへのファイルパスです。画像ファイルは，GIF，JPEG，またはPNG形式で，対応するファイルの拡張子は，.gif，.jpeg，.jpg，または.pngのいずれかである必要があります。

-file

1行につき一つのiconSpecのリストが含まれるファイルへのパスです。空白行やコメントをファイルに含めることができます。コメントは，行の先頭の'#'記号で表します。

-delete (<iconName1,iconName2,...> | -file <file>)

アイコン名，または入力ファイルのいずれかを使用して，アイコンを削除します。アイコンが存在しない場合は，これらは無視されます。

<iconName1,iconName2,...>

iconNameNは，アイコンに関連付けられているアイコン名です。

-file

1行につき一つのアイコン名のリストが含まれるファイルへのパスです。空白行やコメントをファイルに含めることができます。コメントは，行の先頭の'#'記号で表します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-help

コマンドの使用方法を表示します。

EXAMPLES

NNMi データベース内のアイコンの一覧を表示します。

nnmicons.ovpl -list

アイコンの定義を使用して，アイコンを作成します。

nnmicons.ovpl -create iconName1:com.customer.author:16:image16.gif:32:image32.gif,iconName2:com.customer.author:16:anotherimage16.gif

定義ファイルを使用して，アイコンを更新します。

nnmicons.ovpl -update -file /tmp/iconSpecificationFile.txt

アイコン名を使用して，アイコンを削除します。

nnmicons.ovpl -delete iconName1,iconName2

AUTHOR

nnmicons.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmicons.ovpl

Linux：$NNM_BIN/nnmicons.ovpl

付録G.24　nnmincidentcfg.ovpl

SNMP MIB から，インシデント構成を作成します。

SYNOPSIS

nnmincidentcfg.ovpl [ [-loadTraps mib_module_name [[-authorLabel author_label -authorKey author_key] [-skipExisting] | [-validate]]] | -deleteAuthor author_key | -deleteCategory category_key | -deleteFamily family_key | -disableAllTraps <true|false> | -unloadTraps mib_module_name [-u username] [-p password] ]

DESCRIPTION

nnmincidentcfg.ovplコマンドは，MIBファイルにTRAP-TYPEまたは，NOTIFICATION-TYPE マクロで定義されたSNMPトラップのインシデント構成を作成するときに使用します。MIB式の定義や，数値のオブジェクトIDをテキストで表示するためにMIBをロードするには，nnmloadmib.ovplコマンドを使用します。

作成直後のインシデントは次のデフォルト値を持ちます（値はNNMiコンソールで更新できます）。

"名前" は，MIBファイル内に指定されたトラップ/通知の名前となります。

"SNMPのオブジェクトID"は，MIBファイル内に指定されたトラップ/通知のOIDとなります。

"有効にする"は，"true"となります。

"カテゴリ"は，"ステータス"となります。

"ファミリー"は，"ノード"となります。

"重大度"は，"正常域"となります。

"メッセージの形式"は，インシデント構成の名前となります。

"説明"は，MIBファイル内に指定されたトラップ/通知の説明文となります。

作成されたインシデントに対する操作は，［SNMPトラップの設定］フォームで行えますので，必要に応じてカスタマイズできます。

nnmincidentcfg.ovplは，#SUMMARYと呼ばれる特殊な注釈をサポートします。#SUMMARY注釈の値は，インシデント設定項目中のメッセージ形式として適用されます。この注釈は，MIBファイル内のトラップ説明の直後に，MIBコメントとして適用されます。次に例を示します。

    MyTrap TRAP-TYPE
    ENTERPRISE   hp
    VARIABLES {
            serverName, trapTime, volumeName, volumeNum
    }
    DESCRIPTION "The disk volume is out of space. Please consult your sysop, and/or the proper manual."
    --#SUMMARY  "Volume $1 on system $2 is out of space."

Parameters

nnmincidentcfg.ovplコマンドは，次のオプションをサポートします。

-loadTraps <mib_module_name>

トラップ定義を持つMIBモジュール名を指定します。nnmincidentcfg.ovplは，MIBファイル内のトラップ/通知定義（TRAP-TYPEまたはNOTIFICATION-TYPEマクロ）を解析し，それらに対応するインシデント定義を作成します。

-authorLabel <author_label>

対象インシデント構成の作成者のラベルを指定します。 これは任意指定のパラメータです。作成者ラベルを指定した場合は，作成者キーも指定する必要があります。

-authorKey <author_key>

対象インシデント構成の作成者のキーを指定します。これは任意指定のパラメータです。作成者キーを指定した場合は，作成者ラベルも指定する必要があります。com.example.nnm.authorのように，会社のドメインによるjavaのパッケージ表記の使用を推奨します。

-skipExisting

このオプションが存在する場合，既存のインシデント構成は上書きされません。

-validate

トラップ定義が既に NNMi データベースに存在するかどうか確認し，結果を出力します。このオプションを指定した場合，トラップ定義は NNMi データベースにロードされません。

-deleteAuthor <author_key>

インシデント構成を使用しなくなった作成者を削除した方がよい場合があります。このオプションに作成者キーの値を指定すると作成者を削除できます。ただし，作成者オブジェクトを参照している設定がない場合に限ります。

-deleteCategory <category_key>

インシデント構成によって使用されなくなったカテゴリを削除した方がよい場合があります。このオプションにカテゴリキーの値を指定するとカテゴリを削除できます。ただし，カテゴリオブジェクトを参照している設定がない場合に限ります。

-deleteFamily <family_key>

インシデント構成によって使用されなくなったファミリーを削除した方がよい場合があります。このオプションにファミリーキーの値を指定するとファミリーを削除できます。ただし，ファミリーオブジェクトを参照している設定がない場合に限ります。

-disableAllTraps <true|false>

この引数にtrueを指定した場合，インシデントの設定にすべてのトラップが無効として読み込まれます。デフォルトはfalseで，インシデント設定は有効です。

-unloadTraps <mib_module_name>

トラップ定義があるMIBモジュール名を指定します。そのMIBモジュール内で見つかったトラップ定義や通知定義（TRAP-TYPEマクロまたはNOTIFICATION-TYPEマクロ）をnnmincidentcfg.ovplが解析し，エントリの各OIDのインシデント設定を削除します。

-u <username>

コマンドの実行に必要な NNMi の管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要な NNMi の管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

nnmincidentcfg.ovpl -loadTraps "CISCO-VTP-MIB" -authorLabel "Cisco" -authorKey com.example.cisco.nnm.author

nnmincidentcfg.ovpl -loadTraps "mpls"

AUTHOR

nnmincidentcfg.ovpl was developed by Micro Focus.

SEE ALSO

RFC 2578 Structure of Management Information Version 2 (SMIv2)

RFCs 1155, 1212, 1215: SNMP Version 1 Structure of Management Information

RFCs 1902, 1903, 1904: SNMP Version 2 Structure of Management Information

nnnloadmib.ovpl, nnm.properties.

付録G.25　nnmincidentcfgdump.ovpl

インシデント構成をNNMiデータベースからタグフォーマットファイルに出力します。

SYNOPSIS

nnmincidentcfgdump.ovpl { -dump <filename> [-uuid] [-authorKey <author(s)> | -name <name(s)> | -oid <oid pattern(s)> | -mib <mib name(s)>] [-type <type(s)>] [-timeout <timeout>] [-memory <memory>] [-u <user name> -p <password>] } { -listAuthors [-u <user name> -p <password>] }

DESCRIPTION

nnmincidentcfgdump.ovplは，インシデント構成を，NNMiデータベースからタグフォーマットファイルに出力します。このタグフォーマットファイルは，編集後nnmincidentcfgload.ovplを用いることでNNMiデータベースにロードすることができます。

nnmincidentcfgdump.ovplがサポートするインシデント構成の種別を次に示します。

*MgmtEventConfig
*PairwiseConfig
*SnmpTrapConfig
*SyslogMessageConfig

なお，出力するインシデント構成は，事前にNNMiコンソールで作成するか，nnmincidentcfg.ovplコマンドを用いてNNMiデータベースにロードされている必要があります。

Parameters

nnmincidentcfgdump.ovplコマンドは，次のオプションをサポートします。

-dump <filename>

インシデント構成をコピーするファイルを指定します。指定したファイルが既に存在する場合，nnmincidentcfgdump.ovplは警告を表示して終了します。

-uuid

UUIDをほかのインシデント構成と共に出力したい場合に指定します。このコマンドを実行する際には，このオプションを指定して実行することを推奨します。

-authorKey <author(s)>

特定の作成者キーを持つインシデント構成だけを出力したい場合に指定します。このオプションの指定が無い場合は，すべての作成者キーを持つインシデントが出力されます。

-nameや-oid，または-mibオプションと同時に指定することはできません。

-name <name(s)>

特定の名前を持つインシデント構成だけを出力したい場合に指定します。1つ以上のインシデントの名前を指定することができます。このオプションの指定が無い場合はすべてのインシデント構成が出力されます。

-authorKeyや-oid，または-mibオプションと同時に指定することはできません。

-oid <oid pattern(s)>

特定のOIDを持つインシデント構成だけを出力したい場合に指定します。1つ以上のOIDを指定することができます。指定するOIDは，次の書式に従う必要があります。

*ワイルドカード "*" を1つだけ使用することができます。
*OIDは "." から始まる必要があります。
*OIDに使える文字は，区切り文字の "." と，数字とワイルドカードだけです。

-nameや-authorKey，または-mibや-typeオプションと同時に指定することはできません。

-mib <mib name(s)>

特定のMIBモジュールを含むインシデント構成だけを出力したい場合に指定します。 指定するMIBモジュールは，次を満たしている必要があります。

*すでにMIBモジュールがNNMiデータベースにロードされている。
*すでに MIB モジュールのトラップ定義がNNMiデータベースにロードされている。

-nameや-authorKey，または-oidや-typeオプションと同時に指定することはできません。

-type <type(s)>

特定のインシデント構成の種別だけ出力したい場合に指定します。1つ以上のインシデント構成の種別を指定することができます。このオプションの指定が無い場合はすべてのインシデントの構成の種別が出力されます。

指定可能なインシデント構成の種別を次に示します。

注意：次の設定値は，大文字小文字を区別しません。

*MgmtEventConfig
*PairwiseConfig
*SnmpTrapConfig
*SyslogMessageConfig

-oidや-mibオプションと同時に指定することはできません。

-timeout <timeout>

nnmincidentcfgdump.ovplコマンドのためのトランザクションタイムアウト時間を変更したい場合に秒で指定します。

-memory <memory>

最大ヒープサイズをMBで指定します。デフォルトは1536MBで，指定できる最小値は512MBです。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-listAuthors

すべての作成者キーと，そのラベルを出力します。

EXAMPLES

すべてのインシデント構成を出力します。

nnmincidentcfgdump.ovpl -dump full-dump.tag

すべての管理イベントと，SNMPトラップの構成を出力します。

nnmincidentcfgdump.ovpl -dump type-dump.tag -type MgmtEventConfig SnmpTrapConfig

作成者キーがNetwork Node Managerとカスタマのインシデント構成を出力します。

nnmincidentcfgdump.ovpl -dump nnm-and-customer-author-dump.tag -authorKey com.hp.nms.author.nnm com.customer.author

作成者キーがNetwork Node Managerの管理イベントの構成を出力します。

nnmincidentcfgdump.ovpl -dump author-type-dump.tag -authorKey com.hp.nms.author.nnm -type MgmtEventConfig

名前がNodeDownまたはDuplicateCorrelationのインシデント構成を出力します。

nnmincidentcfgdump.ovpl -dump names-dump.tag -name NodeDown DuplicateCorrelation

CISCO-VTP-MIB MIBモジュールからロードされたSNMPトラップの構成を出力します。

nnmincidentcfgdump.ovpl -dump ciscoVtpMib.tag -mib CISCO-VTP-MIB

SnmpLinkDownとSnmpLinkUpトラップの構成を出力します。

nnmincidentcfgdump.ovpl -dump snmpLinkDownAndUp.tag -oid .1.3.6.1.6.3.1.1.5.3 .1.3.6.1.6.3.1.1.5.4

すべてのLinkDownトラップを出力します。CiscoLinkDownが含まれます。

nnmincidentcfgdump.ovpl -dump linkDownTraps.tag -oid .1.3.6.1.6.3.1.1.5.3.*

すべてのCiscoのSNMPトラップ構成を出力します。

nnmincidentcfgdump.ovpl -dump ciscoSnmpTraps.tag -oid .1.3.6.1.6.3.1.1.5.*.1.3.6.1.4.1.9

すべての作成者キーと，そのラベルを出力します。

nnmincidentcfgdump.ovpl -listAuthors

AUTHOR

nnmincidentcfgdump.ovpl was developed by Micro Focus.

FILES

NNMiは，インシデント構成ファイルの例と，タグフォーマットファイルの正しい書式を次の場所で提供しています。

Windows：%NnmInstallDir%examples¥nnm¥incidentcfg

Linux：/opt/OV/examples/nnm/incidentcfg

SEE ALSO

nnmincidentcfgload.ovpl.

incidentconfiguration.format.

付録G.26　nnmincidentcfgload.ovpl

インシデント構成ファイルをロード，または検証します。

SYNOPSIS

nnmincidentcfgload.ovpl { -load filename [-timeout timeout] [-memory memory] [-u <user name> -p <password>] } { -validate filename [-timeout timeout] [-memory memory] [-u <user name> -p <password>] } { -formats sourceFilename -formatd destinationFilename [-u <user name> -p <password>] }

DESCRIPTION

nnmincidentcfgload.ovplはインシデント構成ファイルのロード，または評価を行います。このインシデント構成ファイルは，incidentconfiguration.formatで説明されたタグフォーマットの書式に従う必要があります。

nnmincidentcfgload.ovplがサポートするインシデント構成の種別を次に示します。

*MgmtEventConfig
*PairwiseConfig
*SnmpTrapConfig
*SyslogMessageConfig

nnmincidentcfgload.ovplコマンドを利用する前に，次の1つを実施してください。

*nnmincidentcfgdump.ovplコマンドでタグフォーマットファイルを出力し，incidentconfiguration.formatで説明された書式に従いファイルを編集してください。
で説明された書式に従ってタグフォーマットファイルをテキストエディタで作成してください。

nnmincidentcfgload.ovpl コマンドを使用するとき，次の点に注意してください。

*複雑なインシデント構成を作成する場合，エラーを回避するために，まずnnmincidentcfgdump.ovplコマンドを使用してタグフォーマットファイルを作成してください。
*タグフォーマットファイルの記述内容は，既存のNNMiデータベースの内容を置き換えます。
*nnmincidentcfgload.ovplを使用してタグフォーマットファイルの再フォーマットを行うと，タグの階層を表すためのホワイトスペースが挿入されます。ただし，コメントはすべて削除されます。

Parameters

nnmincidentcfgload.ovplコマンドは，次のオプションをサポートします。

-load <filename>

NNMiデータベースにロードするためのインシデント構成ファイルを指定します。不正なフォーマットのファイルはロードされません。NNMiはエラーをファイルの行番号とともに報告します。

-validate <filename>

指定されたインシデント構成ファイルを検証し，エラーを行番号とともに出力します。このオプションでは，インシデント構成ファイルはNNMiデータベースにロードされません。

-formats <sourceFilename>

指定されたファイルを再フォーマットし，-formatd <destinationFilename>で指定されたファイルに出力します。

-formatd <destinationFilename>

-formats <sourceFilename>で指定したファイルを再フォーマットした結果を出力するためのファイルを指定します。

-timeout <timeout>

nnmincidentcfgload.ovplコマンドのためのトランザクションタイムアウト時間を変更したい場合に秒で指定します。

-memory <memory>

最大ヒープサイズをMBで指定します。デフォルトは1536MBで，指定できる最小値は512MBです。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

インシデント構成ファイルをロードします。

nnmincidentcfgload.ovpl -load dumped-config.tag

インシデント構成ファイルを検証します。

nnmincidentcfgload.ovpl -validate modified-config.tag

インシデント構成ファイルを再フォーマットします。

nnmincidentcfgload.ovpl -formats custom.tag -formatd formatted-output.tag

次の構成ファイル例は，SnmpTrapConfigのためのすべての必須タグを含みます。

*ConfigurationType=SnmpTrapConfig
	*Name MinimalistTrapConfig
	*Oid .1.3.4.5.6
	-Author
		-Key com.customer.author
	-Category
		-Key com.hp.nms.incident.category.Fault
	-Family
		-Key com.hp.nms.incident.family.Node
	-MessageFormat Custom message format
	-Severity MINOR

次の構成ファイル例は，SNMPトラップにアクションを追加します。

*ConfigurationType=SnmpTrapConfig
	*Name MinimalistTrapConfig
	*Oid .1.3.4.5.6
	-Author
		-Key com.customer.author
	-Category
		-Key com.hp.nms.incident.category.Fault
	-ActionConfiguration
	    -Actions
	        -Action
                -Command echo "hello" > /tmp/hello.test
                -CommandType SCRIPT_OR_EXECUTABLE
                -LifecycleState InProgress
	-Family
		-Key com.hp.nms.incident.family.Node
	-MessageFormat Custom message format
	-Severity MINOR

AUTHOR

nnmincidentcfgload.ovpl was developed by Micro Focus.

FILES

NNMiは，インシデント構成ファイルの例と，タグフォーマットファイルの正しいフォーマットを次の場所で提供しています。

Windows：%NnmInstallDir%examples¥nnm¥incidentcfg

Linux：/opt/OV/examples/nnm/incidentcfg

SEE ALSO

nnmincidentcfgdump.ovpl.

incidentconfiguration.format.

付録G.27　nnmldap.ovpl

LDAP 設定の再読み込みまたは参照

SYNOPSIS

nnmldap.ovpl -reload | -info | -diagnose <username> | -encrypt <password>

DESCRIPTION

nnmldap.ovplは，NNMiの再起動なしで，Lightweight Directory Access Protocol（LDAP）のサインイン設定の再読み込みや，参照，評価をするコマンドです。

Parameters

nnmldap.ovplコマンドは，次のオプションをサポートします。

-info

LDAP設定を次のように表示します。

Configuration=providerURL:"ldap://example.com:636/". Number of available Incident assignment users:0

-reload

LDAP設定を再読み込みします。

-diagnose <username>

LDAP設定パラメータを使用してディレクトリサービスの<username>にアクセスし，ldap.propertiesファイルの設定を検証します。このコマンドはLDAP設定の問題を特定する手助けとなる情報を返します。

<username>は，ディレクトリサービスで有効なユーザー名でなければなりません。NNMiログイン画面のNNMiコンソールのユーザー名プロンプトで使用されているものと同じユーザー名です。

-encrypt <password>

ldap.propertiesファイルに安全に格納できるように，指定したLDAPバインドパスワードを暗号化します。

このコマンドの出力は，ldap.propertiesファイル内のbindCredentialプロパティにコピーする必要があります。暗号化されたパスワードは{ENC}というプレフィックスで始まります。

暗号化されたパスワードは，それを作成したのと同じNNMiによってだけ解読することができます。データベースがリセットされたり，プロパティが新しいNNMiシステムにコピーされたりした場合，暗号化されたパスワードを新たに生成するために，このコマンドを再実行する必要があります。これに対する例外は，アプリケーションフェイルオーバーまたはHA（高可用性）構成でNNMiを使用している場合です。アプリケーションフェイルオーバーまたはHA構成では，nnmldap.ovplコマンドで生成した暗号化パスワードは，両方のNNMi管理サーバーで有効です。これは，両方のNNMi管理サーバーでデータベースが同一であるためです。

EXAMPLES

nnmldap.ovpl -info

現在のLDAP設定を返します。

nnmldap.ovpl -reload

ldap.properties（LDAPの有効化や無効化など）の変更を読み込みます。

nnmldap.ovpl -diagnose <username>

ldap.properties ファイルの設定を表示して，ディレクトリサービスから情報が抽出できるか検証します。

nnmldap.ovpl -encrypt password

指定したパスワード文字列の暗号化された値を返します。次に例を示します。

{ENC}Mgnb1w007XYYenHvAFf3dQ==

AUTHOR

nnmldap.ovpl was developed by Micro Focus.

付録G.28　nnmlicense.ovpl

Network Node Manager iのライセンス管理を行います。

SYNOPSIS

nnmlicense.ovpl [-h | -help]

nnmlicense.ovpl [ <PRODUCT> [(-install|-f <LicenseFile>)|-r <LicenseIndex>|(-l|-long)] ]

DESCRIPTION

nnmlicense.ovplは，NNMiのライセンスを管理します。

ライセンスの追加は，ライセンスデータベースの更新と，実行中のNNMiプロセスに新しいライセンスが有効になったことの通知の，二つのステップで行います。自動的に実行中のNNMiプロセスに通知されるため，NNMiの再起動は必要ありません。

Parameters

PRODUCT

ライセンスされている製品のショートネーム。

-f|-install <LicenseFile>

指定したライセンスファイルに格納されているライセンスをインストールします。

-r|-remove <LicenseIndex>

インデックスで指定したライセンスを削除し，現在のライセンスステータスに反映します。ライセンスインデックスは，nnmlicense ovpl NNM -lコマンドによって返されたものと同じインデックスです。

-l|-long

現在のライセンスのステータスを表示します。

EXAMPLES

ファイル"license.txt"に格納されたライセンスパスワードをインストールする場合は，次のコマンドを実行します。

nnmlicense.ovpl NNM -f license.txt

これにより，ライセンスデータベースが更新され，ライセンス変更がNNMiに通知されます。

nnmlicense.ovpl NNM -lコマンドで表示されたライセンスインデックス「2」のライセンスを削除するには，以下を実行します。

$NnmInstallDir/bin/nnmlicense.ovpl NNM -l

$NnmInstallDir/bin/nnmlicense.ovpl NNM -r 2

AUTHOR

nnmlicense.ovpl was developed by Micro Focus.

FILES

Windows：%NnmInstallDir%misc¥nms¥lic¥NNM.pdf

Linux：$NnmInstallDir/misc/nms/lic/NNM.pdf

ライセンス管理が使用する製品定義ファイル。

Windows：%NnmDataDir%shared¥nnm¥conf¥licensing¥NNM.bin

Linux：$NnmDataDir/shared/nnm/conf/licensing/NNM.bin

ovjbossによって使用されるライセンス情報を表すデータファイル。

SEE ALSO

Installation Guide for future details on licensing.

付録G.29　nnmloadattributes.ovpl

CSVファイルまたはコマンドラインから，ノード，インタフェース，および物理コンポーネント（カード/シャーシ）に対してカスタム属性をロードします。

SYNOPSIS

nnmloadattributes.ovpl [-h | -help] [[-r <true | false>] | [-list]] -t <type> (-f <path & filename of csv file>) | (-s <"csv formatted line">) [-u <username> -p <password>]

DESCRIPTION

nnmloadattributes.ovplは，CSVファイルからカスタム属性をロードします。外部データストアに定義されている多くのノード，インタフェースまたは物理コンポーネントがあり，NNMiにこれらの属性をロードしたい場合，このコマンドは有用です。ノードについては，NNMiへロードした後に，それらのカスタム属性によってノードをグループ化するためにノードグループ形式を使用することができます。

Parameters

nnmloadattributes.ovplコマンドは，次のオプションをサポートします。

-h | -help

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-r <true | false>

この引数が値trueで指定されていない場合，既存の属性値は変更されません。

-t <type>

ロードおよび表示対象のオブジェクトタイプを指定します。"node"，"interface" または "physcomp"です。

-f <path & filename of csv file>

ロードするカスタム属性を含むCSVファイル名（パス名。例：/tmp/csvfile.csv）を指定します。

-s <"csv formatted line">

CSV形式の1行を指定します。小さな変更に対してファイル作成を省略できます。

-list

指定されたオブジェクトタイプに応じたCSV形式でカスタム属性を表示します。

Syntax of Comma Separated File For Node Attributes

ノードにカスタム属性を追加するときに指定するCSVファイルの構文は次のとおりです。

空の行は無視されます。

"#"で始まる行は無視されます。

Column 1(A)：Node DNS|IP Address

ノードのDNS名か，IPアドレスを指定します。このフィールドは必須です。

Column 2(B)：Attribute Name

カスタム属性の名前。

Column 3(C)：Attribute Value

カスタム属性の値。

追加のカスタム属性の名前と値の組み合わせは，同じ行に指定できます。または，別の行で同じノードを指定します。

例）

192.168.1.1,Location,Building Five Upper,Service Type,eCommerce

192.168.1.1,Asset Tracking,N1234

192.168.2.2,Location,Fort Collins,Service Type,IT,Asset Tracking,F4321

Syntax of Comma Separated File For Interface Attributes

インタフェースにカスタム属性を追加するときに指定するCSVファイルの構文は次のとおりです。

空の行は無視されます。

"#" で始まる行は無視されます。

Column 1(A)：Node DNS|IP Address

ノードのDNS名か，IPアドレスを指定します。このフィールドは必須です。

Column 2(B)：Interface Id

前のフィールドで指定したノードのインタフェースの識別子を指定します。インタフェースのインデックス，エイリアス，インタフェース名，または説明が指定でき，この順序で検索されます。すべての一致するインタフェースに対して，属性がロードされます。このフィールドは必須です。

Column 3(C)：Attribute Name

カスタム属性の名前。

Column 4(D)：Attribute Value

カスタム属性の値。

追加のカスタム属性の名前と値の組み合わせは，同じ行に指定できます。または，別の行で同じノードとインタフェース識別子を指定します。

例）

192.168.1.1,1001,Location,Building Five Upper,Service Type,eCommerce

192.168.1.1,1001,Asset Tracking,N1234

192.168.2.2,A1,Location,Fort Collins,Service Type,IT,Asset Tracking,F4321

Syntax of Comma Separated File For PhysComp Attributes

物理コンポーネント（カード/シャーシ）にカスタム属性を追加するときに指定するCSVファイルの構文は次のとおりです。

空の行は無視されます。

"#"で始まる行は無視されます。

Column 1(A)：Node DNS | IP Address

ノードのDNS名か，IPアドレスを指定します。このフィールドは必須です。

Column 2(B)：PhysComp Id

前のフィールドで指定したノードの物理コンポーネントの識別子を指定します。物理コンポーネントの物理インデックス，名前，または説明が指定でき，この順序で検索されます。すべての一致する物理コンポーネントに対して，属性がロードされます。このフィールドは必須です。

Column 3(C)：PhysComp Type

物理コンポーネントのタイプを識別する名前。"card"と"chassis"が有効なタイプです。

Column 4(D)：Attribute Name

カスタム属性の名前。

Column 5(E)：Attribute Value

カスタム属性の値。

追加のカスタム属性の名前と値の組み合わせは，同じ行に指定できます。 または，別の行で同じノードと物理コンポーネント識別子，物理コンポーネントタイプを指定します。

例）

192.168.1.1,7,chassis,Location,Building Five Upper,Service Type,eCommerce

192.168.1.1,7,chassis,Asset Tracking,N1234

192.168.2.2,/AmdFE,card,Location,Fort Collins,Service Type,IT,Asset Tracking,F4321

Error Codes

問題を特定するのに役立ついくつかのエラーコードがあります：

INFO：情報メッセージ。

ATTR_ERROR：指定された属性で問題が見つかりました。

DEL_FAIL_ERROR：指定された属性の削除に失敗しました。

OBJECT_ERROR：指定されたオブジェクトが見つかりませんでした。

BAD_LINE_ERROR：指定された行のフォーマットが正しくありません。

IO_ERROR：CSVファイルが見つからないか，読めませんでした。

BAD_NAME_WARNING：指定された属性名が長すぎます(最大50文字)。

BAD_VALUE_WARNING：指定された値が長すぎます(最大2000文字)。

EXAMPLES

CSVファイル(/tmp/test.csv)の内容例は次のようになります (ノードの場合)：

192.168.2.2,Location,Fort Collins,Service Type,IT,Asset Tracking,F4321

CSVファイルからノードのカスタム属性を既存の値を上書きしてロードする場合：

nnmloadattributes.ovpl -t node -f /tmp/test.csv -r true

コマンドに指定したノードのカスタム属性を一つロードする場合：

nnmloadattributes.ovpl -t node -s "192.168.1.1,Project,IT Update of Building Five"

CSVファイル(/tmp/test.csv)の内容例は次のようになります(インタフェースの場合)：

192.168.2.2,A1,Location,Fort Collins,Service Type,IT,Asset Tracking,F4321

CSVファイルからインタフェースのカスタム属性を既存の値を上書きしてロードする場合：

nnmloadattributes.ovpl -t interface -f /tmp/test.csv -r true

コマンドに指定したインタフェースのカスタム属性を一つロードする場合：

nnmloadattributes.ovpl -t interface -s "192.168.1.1,1001,Project,IT Update of Building Five"

CSVファイル (/tmp/test.csv) の内容例は次のようになります(物理コンポーネントの場合)：

192.168.2.2,7,chassis,Location,Fort Collins,Service Type,IT,Asset Tracking,F4321

CSVファイルから物理コンポーネントのカスタム属性を既存の値を上書きしてロードする場合：

nnmloadattributes.ovpl -t physcomp -f /tmp/test.csv -r true

コマンドに指定した物理コンポーネントのカスタム属性を一つロードする場合：

nnmloadattributes.ovpl -t physcomp -s "192.168.1.1,/AmdFE,card,Project,IT Update of Building Five"

AUTHOR

nnmloadattributes.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmloadattributes.ovpl

Linux：$NNM_BIN/nnmloadattributes.ovpl

SEE ALSO

nnmdeleteattributes.ovpl, nnmloadnodegroups.ovpl, nnm.properties.

付録G.30　nnmloadinterfacegroups.ovpl

このコマンドは，CSVファイルからインタフェースグループ定義を読み込みます。

SYNOPSIS

nnmloadinterfacegroups.ovpl [-?] [-u <username> -p <password>] [-r true | false] -f <csv_filename>[-list]

DESCRIPTION

nnmloadinterfacegroups.ovplコマンドは，CSVファイルからインタフェースグループの定義を読み込みます。このコマンドは，外部データストアで定義されているインタフェースデータが多数あり，かつ，インタフェースグループの定義としてNNMiのデータベースに読み込みたい場合に便利です。NNMiに読み込んだ後，インタフェースグループフォームを使用すると，インタフェースグループの定義を変更できます。

Parameters

nnmloadinterfacegroups.ovplコマンドは，次のオプションをサポートします。

-?

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-r true | false

このオプションを使用する前に，既存のインタフェースグループ設定をバックアップしてください。

-r false（デフォルト設定）の場合，インタフェースグループ名が既にNNMiデータベースに存在すると，nnmloadinterfacegroups.ovplコマンドは以前の設定を変更しません。

-r trueの場合，同じName（Column 1）の既存のインタフェースグループのすべての設定が，CSVファイルの値で上書きされます。

注意：マージではなく，そのインタフェースグループのすべての設定が完全に置き換えられます。

-f <csv_filename>

インタフェースグループを定義したCSVファイルを指定します。

-list

「Syntax of Comma-Separated File」で指定された形式でインタフェースグループを表示します。

Syntax of Comma-Separated File

注意：改行文字，カンマ，引用符などの特殊文字を含むフィールドは，CSVファイルでは二重引用符で囲む必要があります。二重引用符が埋め込まれたフィールドも，RFC4180（CSVファイルの一般的書式，およびMIMEタイプ）の仕様に準拠し，二重引用符で囲まれたフィールド中の二つの二重引用符によるエスケープされた形式を使用する必要があります。

ユーザーが指定するCSVファイルには次の構文が必要です。

（必須：Column1）インタフェースグループ名を指定する必要があります。

（任意：Column2-Column7）値のないカラムは空にしてください。

Column7の終わりを示すカンマは必要ありません。カラム内で最後の項目の後（とカンマ「,」の間）にセミコロン「;」は必要ありません。

NNMiは次の方法で，すべての設定の結果を統合します。

NNMiは最初にifType Filters（Column6）を評価します。このインタフェースグループに含まれるためには，インタフェースは少なくとも一つの定義に一致する必要があります。

NNMiは次にAdditional Filters（Column7）を評価します。このインタフェースグループに含まれるためには，すべてのAdditional Filtersの定義もパスする必要があります。

Node Group（Column5）がこのインタフェースグループに指定されている場合，このグループ内の任意のインタフェースは，そのノードグループのメンバーであるノードに含まれている必要があります。

空白行または「#」で始まる行はコメントとして無視されます。次のコメントを1行目に追加することで，必要となるカラムの構文の参考になります。

#InterfaceGroupName,[Notes],[AddtoFilterList],[AddtoPerformanceFilterList],[NodeGroupName],[ifType1;...],[AdditionalFilters]

Column1(A)：Interface Group Name

（必須）インポートしたいインタフェースグループの名前を指定します（インタフェースグループフォームの名前属性の値になります）。

Column2(B)：Notes

（任意）インタフェースグループの説明を記述します（インタフェースグループフォームの「注」フィールドのテキストになります）。

Column3(C)：Add to View Filter List

（任意）インタフェースグループフォームの「ビューフィルターリストに追加」を設定します。

1（デフォルト設定）の場合，インタフェースビューなどのテーブルビューを表示するとき，ドロップダウンリストでこのインタフェースグループが利用可能になります。

0の場合，ビュードロップダウンフィルターリストにこのインタフェースグループを含めません。

推奨：使用頻度が最も多いインタフェースグループでのみ，この値を 1 に設定してください。極端に多くのインタフェースグループで設定すると，リストが長くなり使用しにくくなります。

Column4(D)：Add to Performance Filter List

（任意）インタフェースグループフォームの「NNMi iSPI Performance」を設定します。NNMiでは使用できませんので，何も指定しないでください。

Column5(E)：Node Group Name

（任意）指定されたノードグループは，このインタフェースグループのフィルタとして機能します。

注意：既にNNMiデータベースに存在するノードグループを指定してください。

Column6(F)：ifType Filters

（任意）「;」で区切って，ifTypeフィルターの設定を追加します（インポート後，これらの定義はインタフェースグループフォームのifType フィルタータブに表示されます）。それぞれのifTypeはifType 名によって識別されます。

NNMiのコンソールに表示される正確なifType名を指定します。

ifTypeフィルターに指定するエントリの例は次のとおりです。

ds0;ds0Bundle;ds1;ds1FDL;ds3;g703at2mb

ppp;pppMultilinkBundle;propPointToPointSerial;slip

ethernetCsmacd

Column7(G)：Additional Filters

（任意）インタフェースグループに含まれるインタフェースを絞り込むために使用される追加のフィルター式を指定します。追加のフィルターのフォーマットは次のとおりです。

一致する括弧のセット内に，フィルターの条件演算子とそれに関連付けられているフィルター条件を定義します。

フィルター属性，フィルター演算子，フィルター値の順番で指定して，フィルターを定義します。

インタフェースグループフォームで使用可能なすべてのフィルター属性と演算子がサポートされています。複数のフィルター値を指定する場合は，「:」を区切り文字として使用します。一つのフィルター条件演算子に複数のフィルターを指定する場合は，「;」を区切り文字として使用します。スペースは，フィルター属性とフィルター演算子，フィルター演算子とフィルター値を区切るために使用されます。

フィルター属性：

ifAlias

ifDesc

ifIndex

ifName

ifSpeed

hostedOn

ipAddress

isSnmpInterface

sysOidInterface

devCategoryInterface

devVendorInterface

devFamilyInterface

customAttrName

customAttrValue

capability

vlanId

vlanName

ifPhysAddress

configuredDuplexSetting

フィルター演算子：

!=

>

>=

<

<=

=

between

in

is_not_null

is_null

like

not_between

not_in

not_like

フィルター条件演算子：

AND

OR

NOT

EXISTS

NOT_EXISTS

例：

(AND hostedOn like *.mycompany.com (OR (EXISTS (AND customAttrName = circuit; customAttrValue = 12) ) (EXISTS (AND customAttrName = circuit; customAttrValue = 15) ) ) )

(AND hostedOn like *.mycompany.com (EXISTS (AND customAttrName = circuit; customAttrValue in 12:15) ) )

hostedOn like *.mycompany.com

ifAlias = " Alias with leading and trailing spaces "

ifAlias = Alias with embedded ¥"double quotes¥"¥

カラム7では，ダブルクォートをダブルクォートでエスケープする，RFC4180の規則は適用されません。その結果，次のようなファイルを作成します。

"My Group",,,,,,"ifAlias = Alias with embedded ¥"double quotes¥""

Note

フィルター値を入力する場合，特殊文字「"」，「(」，「)」，「:」および「;」は使用しないでください。特殊文字を使用したい場合は，「¥」でエスケープしてください。例えば

'circuit:57' は 'circuit¥:57' のように入力します。

'circuit(57)' は 'circuit¥(57¥)' のように入力します。

'circuit"57"' は 'circuit¥"57¥"' のように入力します。

'circuit;57' は 'circuit¥;57' のように入力します。

'circuit¥:57' は 'circuit¥¥¥:57' のように入力します。

カラム7では，ダブルクォートをダブルクォートでエスケープする，RFC4180の規則は適用されません。その結果，次のようなファイルを作成します。

"My Group",,,,,,"ifAlias = circuit¥(57¥)"

"My Group",,,,,,"ifAlias = circuit¥"57¥""

Use of Microsoft Excel

カンマ区切りファイルを作成する場合，Microsoft Excelが手ごろなツールですが，CSVファイルではカラム幅，コメントなどが維持されません。nnmloadinterfacegroups.ovplの入力ファイルをネイティブのXLSフォーマットとして保存後に，"名前を付けて保存(A)..."を実行してCSVファイルを作成するのが賢明です。この場合，XLSフォーマットのファイルにExcelコメントを追加し，カラム幅を拡大することが可能であり，カンマ文字をエスケープする必要もありません。

Microsoft Excel で先頭に#がある行でカンマを入力すると，XLSファイルをCSVファイルとして保存したときに，コメントなしのエントリができます（#で始まる名前を持つインタフェースグループが作成されます）。

EXAMPLES

CSVファイルの内容例は次のようになります。

Point to Point Interfaces,Point to Point Interfaces are usually associated with dial-up.,1,,,ppp;pppMultilinkBundle;propPointToPointSerial;slip

CSVファイルのカラム1に定義したNameに一致する既存のインタフェースグループを上書きしないように，CSVファイルからインタフェースグループを読み込むには；

nnmloadinterfacegroups.ovpl -u system -p myadminpasswd -f /tmp/test.csv

CSVファイルのカラム1に定義したNameに一致する既存のインタフェースグループを上書きして，CSVファイルからインタフェースグループを読み込むには：

nnmloadinterfacegroups.ovpl -u system -p myadminpasswd -r true -f /tmp/test.csv

AUTHOR

nnmloadinterfacegroups.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmloadinterfacegroups.ovpl

Linux：$NNM_BIN/nnmloadinterfacegroups.ovpl

SEE ALSO

nnmconfigimport.ovpl, nnmloadnodegroups.ovpl, nnm.properties.

付録G.31　nnmloadipmappings.ovpl

重複するIPアドレスマッピングの情報を読み込みます。

SYNOPSIS

nnmloadipmappings.ovpl -f mapping file [-u <username> -p <password>]

DESCRIPTION

nnmloadipmappings.ovplを使用すると，静的NAT［RFC2663］環境で設定したIPアドレスのマッピングをテキストファイルからロードできます。ロードされたマッピングは，対応するIPアドレスのインベントリに追加されます。

-fオプションは，1行に1エントリを指定したファイルを受け付けます。各行の形式を次に示します。

Tenant Name, "Public IP Address", "Private IP Address"

指定内容の説明：

Tenant Name=テナント名。Public IP Address=外部ネットワークにさらされる，ネットワークアドレス変換（NAT）した特定のIPv4アドレス。Private IP Address=ネットワークアドレス変換（NAT）したパブリックIPアドレスに対応する，ある特定の内部IPv4アドレス。

#を区切り文字として複数のコメントを指定できます。

一つのパブリックIPアドレスは，一つのテナント内の一つのプライベートIPアドレスに対してのみマッピングできることに注意してください。同様に，一つのテナント内のプライベートIPアドレスは一つのパブリックIPアドレスに対してのみマッピングできます。ただし，デバイス上の複数のマッピングがサポートされています。

Parameters

nnmloadipmappings.ovplコマンドは，次のオプションをサポートします。

-f mapping file

IPアドレスマッピングの読み込み元テキストファイルを指定します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

Tenant1Mappings.txtという名前のファイルからIPアドレスマッピングを読み込みます。

nnmloadipmappings.ovpl -f /tmp/Tenant1Mappings.txt

ユーザー名とパスワードを指定して，Tenant2Mappings.txtという名前のファイルからIPアドレスマッピングを読み込みます。

nnmloadipmappings.ovpl -u username -p password -f /tmp/Tenant2Mappings.txt

AUTHOR

nnmloadipmappings.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmloadipmappings.ovpl

Linux：$NNM_BIN/nnmloadipmappings.ovpl

付録G.32　nnmloadmib.ovpl

SNMP MIBのロードとアンロードを行います。

SYNOPSIS

nnmloadmib.ovpl [ [-load mib-file] [-unload mib-module[:mib-module...]] [-list] [-u username] [-p password] ]

DESCRIPTION

nnmloadmib.ovplは，NNMiがSNMP Object Identifiers（OIDs）を数値形式から可読テキスト形式に変換するために，Internet SMI（Structure of Management Information）形式のSNMP MIB（Management Information Base）を読み込みます。NNMiコンソールでMIB式を作成する前に，MIBをロードする必要があります。NNMiはSMI Version 1（RFC1155，1212，1215）およびSMI Version 2（RFC2578）形式をサポートします。

nnmloadmib.ovplコマンドは，NNMiで使用するために，MIBモジュールをコンパイルしてロードし，得られる情報をNNMiデータベースに格納します。

MIBからTRAP-TYPEおよびNOTIFICATION-TYPEマクロをNNMiのインシデントの設定にロードする場合は，nnmloadmib.ovplコマンドでNNMiのMIBデータベースにMIBをロードした後に，nnmincidentcfg.ovplコマンドを使用します。

Parameters

nnmloadmib.ovplコマンドは，次のオプションをサポートします。

-load mib-file

mib-fileに指定したファイルのコンテンツをMIBデータベースに読み込みます。

注意：nnmloadmib.ovplコマンドを実行する前に，mib-fileファイルを%NNM_DATA%¥shared¥nnm¥user-snmp-mibs（Windows）ディレクトリまたは，$NNM_DATA/shared/nnm/user-snmp-mibs（Linux）ディレクトリ（またはその配下のディレクトリ）にコピーすることを推奨します。これにより，アクション->MIBファイルを表示メニューと-listオプションで，MIBファイルの元の場所を見つけることができます。

-unload mib-module[:mib-module...]

MIBデータベースからmib-moduleのリストをアンロードします。mib-moduleとは，MIBデータベースに読み込まれているMIBモジュールの名前です。

注意：もしnnmloadmib.ovplスクリプトを使ってMIBをアンロードしてnnmincidentcfg.ovplスクリプトを使ってMIBからのインシデント設定をアンロードしたい場合，先にインシデント設定のアンロードをしてください。これはnnmincidentcfg.ovplスクリプトではアンロードされたMIBモジュール名は指定できないためです。

-list

データベースに読み込まれているMIBの一覧を表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

Loading/Unloading Validation

MIBのロードおよびアンロード時に，既存のすべてのロード済みMIBは，ロード/アンロード操作が問題なく実行されることを保障するために解析されます。そのため，ロードおよびアンロード対象のMIBとは必ずしも関係のない警告（OIDが重複しているなど）が表示されることがあります。コマンドラインの実行時に成功のステータスが返されていれば問題はないため，これらの警告は無視することができます。

Syntax of MIB Files

MIBファイルに関連する構文のほとんどは，さまざまなRFCドキュメントに記述されています。このページの「SEE ALSO」の項を参照してください。

Diagnostics

nnmloadmib.ovplコマンドは，次の終了コードを返します。

0

コマンドの実行に成功しました。

1

コマンドラインの指定が正しくありません。

20

コマンドを実行した後に予期しない例外が発生しました。

21

指定した資格情報を使ってコマンドを実行することは許可されませんでした。

22

MIBファイル内に構文エラーを検出したか，サービスに不具合があったためMIBを読み込めませんでした。

23

不正な引数が使用されました。多くの場合，必要なファイル名を指定せずに，-load のようなオプションが指定されています。

24

コマンドは，NNMiで実行されているMIBローダーサービスと通信できませんでした。

25

引数が指定されていません。このコマンドには，引数を指定する必要があります。

27

NNMiは動作中ですが，MIBローダーサービスを解決できません。

30

データベースに問題があるため，一覧表示操作に失敗しました。

nnmloadmib.ovplコマンドに失敗すると，MIBに関する潜在的な問題を分析し解決するために，説明的なエラーメッセージが表示されます。すべてのエラーメッセージは，同じような形式です。

SEVERITY: MESSAGE FILENAME:LINE_NUMBER:COLUMN_NUMBER: DETAIL_MESSAGE

一般的な障害と推奨される解決策を次に示します。

ERROR : Cannot find symbol file:///tmp/CHECKPOINT-MIB.mib:Line 2620:Column 16:cpvTNlMonCurrAddr

記載されているシンボル名は，読み込まれるMIB内に宣言として見つからなかったか，MIB定義の上部にimportとして記載されていません。これは，シンボル名の入力ミスか，import宣言がないために発生している可能性があります。

ERROR : Cannot find symbol file:///var/opt/OV/shared/nnm/user-snmp-mibs/example.mib:Line 13233:Column 16:COUNTER64

MIBファイルをNNMiに適切にロードするには，MIBファイルがSNMP SMI v1（RFC1155）またはSMI v2（RFC2578）のいずれかの規格に準拠している必要があります。大文字と小文字の区別や正しいMIB定義からのオブジェクトのインポートについて，特に注意する必要があります。場合によっては，旧バージョンのNNMiで正しくロードされていたMIBを修正する必要があるかもしれません。一般的な例としては，Counter64が正しい定義のときに誤ってCOUNTER64を使用してしまう場合です。例えば，"SYNTAX COUNTER64"などは，"SYNTAX Counter64"に修正する必要があります。

ERROR : Found symbol file:///tmp/CHECKPOINT-MIB.mib:Line 3509:Column 27:routingDest but expected a class org.jsmiparser.smi.SmiType instead of class org.jsmiparser.smi.SmiVariable

記載されているシンボル名は，期待されていたタイプではありません。この場合，SMIタイプが期待されていましたが，MIB変数名が代わりに提供されました。このケースの解決策は，正しいSMIタイプ，つまりIPアドレスを指定することです。

ERROR : Cannot find module file:///tmp/rfc1472-PPP-SEC-MIB.mib:Line 9:Column 26:PPP-LCP-MIB

このエラーは，importとして記載されているMIBモジュールが読み込まれていないため，結果として，パーサーがimportできないことを示しています。解決策は，参照されているMIBを最初に読み込むことです。

ERROR file:///tmp/vinemib2:Line 4360:Column 17: Parse error: unexpected token: --#

NNMiは，TRAP-TYPEまたはNOTIFICATION-TYPEのマクロ定義で指定できる，一部のカスタムトラップメッセージ形式情報をサポートしています。有効な値を次に示します。

                  --#TYPE
                  --#SUMMARY
                  --#ARGUMENTS
                  --#SEVERITY
                  --#GENERIC
                  --#CATEGORY
                  --#SOURCE_ID
                  --#TIMEINDEX
                  --#HELP
                  --#HELPTAG
                  --#STATE

このエラーは，--#の後に無効なキーワード，またはNNMiが予期しない一連のキーワードを指定したことを示しています。この問題を修正するには，上記のリストに対応しない --# エントリを削除するか，行の始めに余分なコメント文字シーケンス（--）を追加します。

EXAMPLES

MIBファイル $NNM_DATA/shared/nnm/user-snmp-mibs/corp.mibを読み込む場合，次のようにnnmloadmib.ovplコマンドを実行します。

nnmloadmib.ovpl -load $NNM_DATA/shared/nnm/user-snmp-mibs/corp.mib -u user -p password

ロードされているMIBの一覧を表示する場合，次のようにnnmloadmib.ovplコマンドを実行します。

nnmloadmib.ovpl -list -u user -p password

AUTHOR

nnmloadmib.ovpl was developed by Micro Focus.

FILES

Windows：

%NnmInstallDir%misc¥nnm¥snmp-mibs¥*

%NNM_DATA%¥shared¥nnm¥user-snmp-mibs¥*

Linux：

$NnmInstallDir/misc/nnm/snmp-mibs/*

$NNM_DATA/shared/nnm/user-snmp-mibs/*

SEE ALSO

RFC 2578 Structure of Management Information Version 2 (SMIv2)

RFCs 1155, 1212, 1215: SNMP Version 1 Structure of Management Information

RFCs 1902, 1903, 1904: SNMP Version 2 Structure of Management Information

nnmincidentcfg.ovpl, nnmsnmpwalk.ovpl.

付録G.33　nnmloadnodegroups.ovpl

このコマンドは，CSV ファイルからノードグループ定義を読み込みます。

SYNOPSIS

nnmloadnodegroups.ovpl [-?] [-u <username> -p <password> ] [-r true | false] -f <csv_filename>

DESCRIPTION

nnmloadnodegroups.ovplは，CSVファイルからノードグループの定義を読み込みます。このコマンドは，外部データストアで定義されているノードデータが多数あり，かつ，ノードグループの初期定義としてNNMiのデータベースに読み込みたい場合に便利です。NNMiに読み込んだ後，ノードグループフォームを使用すると，ノードグループの定義を変更できます。

次の設定は，CSVファイルで設定することはできません。ノードグループを読み込んでから，ノードグループフォームを使用してデフォルト設定を変更する必要があります。

ステータスの計算 = true（NNMiはこのノードグループのステータスを計算します）

Parameters

nnmloadnodegroups.ovplコマンドは，次のオプションをサポートします。

-?

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要な NNMi の管理者名を指定します。 nnm.properties ファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要な NNMi の管理者パスワードを指定します。 nnm.properties ファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-r true | false

このオプションを使用する前に，既存のノードグループ設定をバックアップしてください。

-r false（デフォルト設定）の場合，ノードグループ名が既にNNMiデータベースに存在すると，nnmloadnodegroups.ovplコマンドは以前の設定を変更しません。

-r trueの場合，同じName（Column 1）の既存のノードグループのすべての設定が，CSVファイルの値で上書きされます。

注意：マージではなく，そのノードグループのすべての設定が完全に置き換えられます。

注意：階層内のグループでこの置き換えオプションを使用する場合は，すべての子グループが同一のCSVファイルに存在する必要があります。また，子ノードグループは親ノードグループよりも先に記載してください。

-f <csv_filename>

ノードグループを定義したCSVファイルを指定します。

Syntax of Comma Separated File

ユーザーが指定するCSVファイルには次の構文が必要です。

（必須: Column 1）Node Group Nameの値を指定する必要があります。

（任意: Column 2 - Column 14）値のないカラムは空にしてください。

Column 14の終わりを示すカンマは必要ありません。カラム内で最後の項目の後（とカンマ「,」の間）にセミコロン「;」は必要ありません。

NNMiは次の方法で，すべての設定の結果を統合します。

NNMiは最初にDevice Filters（Column 5）を評価します。このノードグループに含まれるためには，ノードは少なくとも一つの定義に一致する必要があります。

NNMiは次にAdditional Filters（Column 7 - Column 14）を評価します。このノードグループに含まれるためには，すべてのAdditional Filtersの定義もパスする必要があります。

注意：読み込んだ後で，ノードグループフォームの追加のフィルタータブにカラム7-14の設定が統合されて表示されます。ノードグループフォームの追加のフィルターエディタで，デフォルトの論理演算を変更できます。

フィルターに関係なく，すべてのAdditional Nodes（Column 6）はノードグループに含まれます。

すべての Child Node Groups（Column 4）の結果は，Additional Nodesと同様の扱いになります。

空のラインまたは「#」で始まるラインはコメントとして無視されます。次のコメントを1行目に追加することで，必要となるカラムの構文の参考になります。

#[NodeGroupName],[Notes],[AddtoFilterList],[ChildNodeGroup:0/1;...],DeviceFilter[Category1:Vendor1:Family1:Profile1;...],AdditionalNodes[Fully-Qaul-hostname;...],AdditionalFilters > [hostname;...],[hostedIPAddress;...],[mgmtIPAddress;...],[customAttrName/customAttrValue;...],[capability;...],[SecurityGroupDetails;...],[TenantDetails;...],[NodeName;...]

Column 1(A)：Node Group Name

（必須）インポートしたいノードグループの名前を指定します（ノードグループフォームの名前属性の値になります）。

Column 2(B)：Notes

（任意）ノードグループの説明を記述します（ノードグループフォームの「注」フィールドのテキストになります）。

Column 3(C)：Add to View Filter List

（任意）ノードグループフォームの「ビューフィルターリストに追加」を設定します。

1（デフォルト設定）の場合，ノードビューなどのテーブルビューを表示するとき，ドロップダウンリストでこのノードグループが利用可能になります。

0の場合，ビュードロップダウンリストにこのノードグループを含めません。

推奨：最上位の親ノードグループまたは使用頻度が最も多いノードグループでのみ，この値を1に設定してください。極端に多くのノードグループで設定すると，リストが長くなり使用しにくくなります。

Column 4(D) ：Child Node Groups

（任意）「;」で区切って，子のノードグループの一覧を指定します（ノードグループフォームの子のノードグループタブに表示されます）。

注意：子のノードグループを設定する場合，既に NNMiデータベースに存在するか，同じCSVファイルで定義されているノードグループを指定してください。

例：ChildNodeGroup1:1[;ChildNodeGroup2:0;...]

0（デフォルトの設定）の場合，子のノードグループが親のノードグループのマップにノードグループアイコンで表示されます。

1の場合，親のノードグループのマップに子のノードグループを拡張します。親ノードグループに定義されているかように，すべてのノードを表示します。

子ノードグループに対する有効なエントリは次のとおりです。

computers:1

computers:0

computers:

computers:;printers:1

Column 5(E) ：Device Filters

（任意）「;」で区切って，デバイスフィルターを追加します（ノードグループフォームのデバイスフィルタータブに表示されます）。各フィルターは，次の書式のように，「:」で区切られた四つの部分で構成されています。

Category1:Vendor1:Family1:Profile1[;Category2:Vendor2:Family2:Profile2 ...]

一致するフィルターの件数を増やすために，フィルター指定の一部を省略することができます。例えば，Category1およびVendor1に対する任意のファミリを一致させたい場合，次のエントリを追加してください。

Category1:Vendor1::

filter1に対するファミリ，およびfilter2に対するファミリとプロファイルを入力したくない場合，次のエントリを指定してください。

Category1:vendor1::profile1;Category2:vendor2::;

デバイスプロファイルに対する有効なエントリの例は次のとおりです。

com.hp.ov.nms.devices.printer:com.hp.ov.nms.devices.hewlettpackard::.1.3.6.1.4.1.9.1.380

com.mycomp.ov.nms.devices.printer:com.hp.ov.nms.devices.mycompanyname::

com.hp.ov.nms.devices.printer:::

:::.1.3.6.1.4.1.9.1.380

Column 6(F) ：Additional Nodes

（任意）「;」で区切られたこのノードグループに追加したいノードホスト名の一覧を指定します（ノードグループフォームの追加のノードタブに表示されます）。ホスト名はノードフォームのホスト名属性に表示される現在の完全な大文字小文字を区別した値を指定します。

例えば：hostname1.x.y.z;hostname2.x.y.z;hostname3.x.y.z

Column 7(G) ：Additional Filters "hostname" code (Hostname Wildcards)

（任意）「;」で区切られたホスト名ワイルドカードの一覧を指定します（演算子「like」と同じ）。その他の演算子を使用する場合は，ノードグループフォームを使用してください（追加のフィルタータブに表示されます）。

例えば：*.cnd.hp.com;*snmp.hp.com

Column 8(H) ：Additional Filters "hostedIPAddress" code (Hosted IP Address Ranges)

（任意）「;」で区切られた所有するIPアドレスの範囲の一覧を指定します（演算子「between」と同じ）。その他の演算子を使用する場合は，ノードグループフォームを使用してください（追加のフィルタータブに表示されます）。範囲の指定には，下方アドレスと上方アドレスをダッシュで区切ってください。両端のアドレスが範囲に含まれます。単一のIPアドレスを範囲に指定する場合，下方アドレスと上方アドレスの両方に同一の値を使用してください。ノード上の任意のアドレスがこの範囲に一致する場合，ノードグループにこのノードが指定されます。

有効な例：10.20.30.1-10.20.30.254;192.168.177.1-192.168.180.254;1.1.1.1-1.1.1.1

Column 9(I) ：Additional Filters "mgmtIPAddress" code (Management Address Ranges)

（任意）「;」で区切られた管理アドレス範囲の一覧を指定します（演算子「between」と同じ）。範囲は所有するIPアドレスの範囲と同じ形式です。その他の演算子を使用する場合は，ノードグループフォームを使用してください（追加のフィルタータブに表示されます）。SNMPをサポートしているノードのみ，スパイラル検出が管理IPアドレスを作成することに注意してください。スパイラル検出で管理アドレスを選択する方法の詳細については，ノードフォームの管理アドレスフィールドに対するオンラインヘルプを参照してください。

Column 10(J) ：Additional Filters "customAttrName:customAttrValue" codes (Custom Node Attributes)

（任意）'"カスタム属性名" オペレータ "カスタム属性値"[;...]' のフォーマットで，ノードのカスタム属性を記述します。名前と値は引用符で囲む必要があることに注意してください（単一引用符（'）は定義に含みません。このヘルプで先頭と末尾を示すためにのみ使用）。Custom Node Attributesの設定は，ノードフォームの追加のフィルタータブに表示されます。

オペレータの有効な値は次のとおりです。

=, !=, like, not like, >, >=, <, <=（その他の演算子を使用する場合は，ノードグループフォームを使用してください）。

複数のカスタム属性文は，セミコロンで区切って指定できます。例えば，'"Location" = "Bldg. Five";"Service Type" = "eCommerce"' です。複数の "customAttrName:customAttrValue" の記述は「AND」で処理されます。つまり，ノードがノードグループに含まれるには，すべての文がtrueである必要があります。

Column 11(K) ：Additional Filters "capability" code (Capabilities)

（任意）'capability オペレータ "ケーパビリティ値"[;...]' のフォーマットで，ノードのケーパビリティを記述します。値は引用符で囲む必要があることに注意してください（単一引用符（'）は定義に含みません。このヘルプで先頭と末尾を示すためにのみ使用）。Capabilities の設定は，ノードフォームの追加のフィルタータブに表示されます。

オペレータの有効な値は次のとおりです。

=, !=, like, not like（その他の演算子を使用する場合は，ノードグループフォームを使用してください）。

複数のケーパビリティ文はセミコロンで区切って指定できます。例えば，'capability = "com.hp.ov.nms.isLANSwitch";capability != "com.hp.ov.nms.isIPv4Router"' です。 複数のケーパビリティ文は「AND」で処理されます。つまり，ノードがノードグループに含まれるには，すべての文がtrueである必要があります。

Column 12(L) ：Security Group Details

（任意）このノードグループに追加するセキュリティグループのプロパティの一覧を，セミコロン「;」で区切って指定します。このノードグループをUUIDでセキュリティグループに関連付けるには，セキュリティグループのUUIDを（xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx）形式で入力します。ここで，（x）は16進数（0～9a～fA～F）であり，そうでない場合は，ノードグループは名前によってセキュリティグループに関係付けられていると仮定されます。

例えば，12345678-1234-1234-1234-123456123456;test_security_group_name です。

Column 13(M) ：Tenant Details

（任意）このノードグループに追加するテナントのプロパティの一覧を，セミコロン「;」で区切って指定します。このノードグループをUUIDでテナントに関連付けるには，テナントの UUID を（xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx）形式で入力します。ここで，（x）は 16進数（0～9a～fA～F）であり，そうでない場合は，ノードグループは名前によってテナントに関係付けられていると仮定されます。

例えば，12345678-1234-1234-1234-123456123456;test_tenant_name です。

Column 14(N) ：Node Name

（任意）このノードグループに追加するノードの一覧をセミコロン「;」で区切って指定します。このノードグループをノード名でノードに関連付けるには，セミコロン区切りの値の一覧にノード名を含めます。

例えば，test_node_name;node_name_2 です。

Use of Microsoft Excel

カンマ区切りファイルを作成する場合，Microsoft Excelが手ごろなツールですが，CSVファイルではカラム幅，コメントなどが維持されません。nnmloadnodegroups.ovpl入力ファイルをネイティブのXLSフォーマットとして保存後に，"名前を付けて保存(A)..." を実行してCSVファイルを作成するのが賢明です。この場合，XLSフォーマットのファイルにExcelコメントを追加し，カラム幅を拡大することが可能であり，カンマ文字をエスケープする必要もありません。また，Microsoft Excelでは，子ノードグループのリストを作成することが容易です。Column 4(D)に次のような計算値を指定するだけです。

=$A1&":0;"&$A2&":0;"&$A3&":0;"&$A4&":0;"&$A5&":0;"&$A6&":0;"&$A7&":0;"

この例では最初の 7行分の最初のカラムで定義されたノードグループを現在の行の最初のセルで定義されたノードグループ名を持つノードグループの子として統合します。このExcel参照を利用すると，最初のカラムで子ノードグループをリネームしても，元に返って親ノードグループのカラムにある参照を変更する必要がありません。Microsoft Excelで先頭に # がある行でカンマを入力すると，XLSファイルをCSVファイルとして保存したときに，コメントなしのエントリができます（#で始まる名前を持つノードグループが作成されます）。

EXAMPLES

CSV ファイルの内容例は次のようになります。

SNMP,Nodes that support SNMP and that are present in Colorado,,,,server1.myco.com;server2.myco.com,*.hp.com

メモ

CSV ファイルにデータを入力する場合，その他の目的で区切り文字「:」と「;」を使用しないでください（例えば，子ノードグループの名前など）。区切り文字を使用したい場合は，「¥」でエスケープしてください。例えば：

"computer:1" は "computer¥:1" のように入力します。

"computer;1" は "computer¥;1" のように入力します。

"computer¥:1" は "computer¥¥:1" のように入力します。

CSV ファイルのカラム1 に定義した Name に一致する既存のノードグループを上書きしないように，CSV ファイルからノードグループを読み込むには：

nnmloadnodegroups.ovpl -u system -p myadminpasswd -f /tmp/test.csv

CSV ファイルのカラム1 に定義した Name に一致する既存のノードグループを上書きして，CSV ファイルからノードグループを読み込むには：

nnmloadnodegroups.ovpl -u system -p myadminpasswd -r true -f /tmp/test.csv

AUTHOR

nnmloadnodegroups.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmloadnodegroups.ovpl

Linux：$NNM_BIN/nnmloadnodegroups.ovpl

SEE ALSO

nnmconfigimport.ovpl, nnmloadinterfacegroups.ovpl, nnm.properties.

付録G.34　nnmloadseeds.ovpl

検出ノードのシード情報を読み込みます。

SYNOPSIS

nnmloadseeds.ovpl -f seedFile [-t tenant] | -n seeds [-t tenant] -list [-format LIST|TEXT|CSV|XML] [-fields name,tenant,results,modified,notes] [-u <username> -p <password>]

DESCRIPTION

nnmloadseeds.ovplコマンドを使用すると，検出シードをコマンドライン引数の指定（-nオプション）またはテキストファイルから（-fオプション）読み込むことができます。また，一覧表示（-listオプション）することができます。シードとは，NNMiにスパイラル検出プロセスの開始点として使用させるデバイスのことです。シードの値はIPアドレスまたはホスト名です。-nオプションを使用する場合，シードはスペース区切りでコマンドラインに指定します。シードは，SNMPをサポートしていなくても常にNNMiに追加されます。

-f オプションは，1行に1エントリを指定したファイルを受け付けます。各行の形式を次に示します。

IPAddress|HostName, "任意で，テナント名または UUID"#（任意で，ノードの識別を容易にするためのコメントを指定可能）

指定内容の説明

IPAddress = 追加するノードのIPアドレス。

HostName = 追加するノードのホスト名。

テナントは，任意でテナント名またはテナント UUID を使用して指定できます。テナントの指定は，引用符で囲んで行う必要があります。シードから検出されたノードは，指定したテナントに割り当てられます。テナントを指定しない場合，ノードはデフォルトのテナントに割り当てられます。

#を区切り文字として複数のコメントを指定できます。また，INCLUDE-FILE<ファイル名>を使用してほかのシードファイルを含めることもできます。

-tオプションを指定すると，指定されたテナントは，-nオプションで渡されたすべてのノード，または-fオプションで指定されたシードファイルのすべてのノードに使用されます。-tオプションと-fオプションを共に使用する場合，シードファイルにおいて，-tオプションで指定したテナントとは異なるテナントが指定されたシードは，すべて無効なシードとして拒否されます。

このコマンドを実行する前に，読み込み対象のデバイスのSNMP構成をセットアップする必要があります。

Parameters

nnmloadseeds.ovpl コマンドは，次のパラメータおよびオプションをサポートします。

-f seedFile

シードの読み込み元テキストファイルを指定します。

注：シードファイルのディレクトリとファイル名は，Windowsシステムの場合は管理者以外，Linuxシステムの場合はroot以外のユーザーがアクセスできる必要があります。

-n seeds

コマンドラインから直接読み込むシードを指定します。複数のシードを指定する場合は，スペースで区切ります。

-list

NNMiが検出のためにロードしたすべてのシードを一覧表示します。ユーティリティは，ほかのNNMiのツール用に定義された次の標準フォーマットを使用しています。TEXT,CSV,XML,LIST。シードデータのフィールドは，次の値を指定して限定できます: name, tenant, results, modified, notes。これらは，NNMi UI に表示されるカラムヘッダーの別称です。

-t tenant name or UUID

読み込むすべてのシードに使用されるテナントを指定します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

シードとしてのデバイスの一覧を読み込みます。

nnmloadseeds.ovpl -u username -p password -n mimcisco8540 15.2.112.22

完全修飾名を指定してノードからシードを読み込みます。

nnmloadseeds.ovpl -u username -p password -n mimcisco8540.superpoller3.mim

seeds_to_load.txt ファイルからシードを読み込みます。

nnmloadseeds.ovpl -u username -p password -f /tmp/seeds_to_load.txt

完全修飾名および特定のテナント割り当てを指定して，ノードからシードを読み込みます。

nnmloadseeds.ovpl -u username -p password -n mimcisco8540.superpoller3.mim -t Customer1

seeds_to_load.txt ファイルからシードを読み込み，特定のテナントにすべてのシードを割り当てます。

nnmloadseeds.ovpl -u username -p password -f /tmp/seeds_to_load.txt -t Customer2

ロードされたすべてのシードを CSV 形式で一覧表示します。一覧には，名前と検出シードの結果が表示されます。

nnmloadseeds.ovpl -u username -p password -list -format CSV -fields name,results

AUTHOR

nnmloadseeds.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmloadseeds.ovpl

Linux：$NNM_BIN/nnmloadseeds.ovpl

SEE ALSO

nnmseeddelete.ovpl, nnmnodedelete.ovpl, nnmnoderediscover.ovpl, nnm.properties.

付録G.35　nnmmanagementmode.ovpl

1つまたは複数のノードやインターフェイス，IPアドレスのNNMi管理モードを変更します。

SYNOPSIS

nnmmanagementmode.ovpl -node.name <nodename> -mode <mode> [-u <username> -p <password>]

nnmmanagementmode.ovpl -t <object type> -f <csv_filename> [-b <batch size>] [-u <username> -p <password>]

nnmmanagementmode.ovpl -t <object type> -s <csv_line> [-u <username> -p <password>]

nnmmanagementmode.ovpl -t <object type> -f <uuid_file> [-b <batch size>] -mode <MODE_SPEC> [-format <format>] [-fields <fields>] [-u <username> -p <password>]

nnmmanagementmode.ovpl -h | -help

DESCRIPTION

nnmmanagementmode.ovplを使用すると，システム管理者はNNMiデータベース内のノードやインターフェイス，IPアドレスの管理モードを設定できます。

Parameters

nnmmanagementmode.ovplコマンドは次のオプションをサポートします。サポートされないオプションはヘルプメッセージで通知されます。

-h | -help

コマンドの使用方法を表示します。

-node.name <nodename>

管理モードをオンにするノードの名前を指定します。

-mode <mode>

設定する管理モードを指定します。有効な値は，"MANAGED"，"NOTMANAGED"または"OUTOFSERVICE"です。インターフェイスとIPアドレスについては，NNMiが"MANAGED"を"INHERITED"と読み変えます。

-mode <MODE_SPEC>

入力uuidファイルを使用して一括変更を実行する場合は，モードの引数として2種類のスタイルが使用できます。1つ目は，値がMANAGED，NOTMANAGEDまたはOUTOFSERVICE（インターフェイスとIPアドレスについてはNNMiがMANAGEDをINHERITEDと読み変えます）のシンプルモードです。2つ目のスタイルは現在および最新のモードで，形式はCURRENT:NEWとなります。CURRENTとNEWにはMANAGED，NOTMANAGEDまたはOUTOFSERVICEと同じ値が入ります。2つ目のスタイルでは，ツールはCURRENTと同じ現在値を持つオブジェクトだけを更新し，異なる値を持つオブジェクトはスキップします。

-t <object type>

管理モードを設定するオブジェクトタイプを指定します。指定できる値は，"node"，"interface"または"ipaddress"です。

-f <csv_filename>

管理モードを設定するCSVファイル名（パス名つきで，例えば /opt/tmp/mynodes.csv）を指定します。ファイルに不正な定義（カラムが多い/少ない，モードが不正など）がある場合，コマンドはその定義を出力し，すべての定義が実行されません。

-b <batch_size>

ファイルを指定した場合，コマンドはすべてのエントリを処理し，このオプションに指定された単位でサーバーに要求を送ります。デフォルトは1000エントリです。

-s <csv_line>

CSV形式の1行を指定します。単純な変更に対してファイル作成を省略できます。

-format (csv|list|text|xml)

表形式のデータが存在しているときに出力形式を変更します

-fields <comma_separated_fields>

表形式のデータが存在しているときに出力フィールドを選択します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。

nnm.propertiesファイルが存在していない限り，これが必要になります。詳細は nnm.propertiesリファレンスページを参照してください。

Batch changing management modes

管理モードの一括変更を実行するために，次のコマンドを使用できます。このコマンドへの入力は，更新するオブジェクトのUUIDを含むファイルから行い，モードはコマンドラインから指定します。ファイルに記載されたすべてのオブジェクトが，指定されたモードに従って処理されます。

nnmmanagementmode.ovpl -t <type> -f <filepath> -mode <MODE_SPEC>

このモードでは，コマンドの出力は入力したUUIDと，そのオブジェクトの結果コードのテーブルで構成されます。結果コードは，次のとおりです。

UPDATED - オブジェクトは，新しいモードに更新されました。

NOT_FOUND - 指定されたUUIDのオブジェクトがシステム内に見つかりませんでした。

SKIPPED - オブジェクトは，現在のモードフィルターと一致しませんでした。

NO_CHANGE - オブジェクトは，既に要求されたモードを持っています。

ACCESS_DENIED - ユーザーは，オブジェクトの管理モードを変更する権限がありません。

例えば，neighbors.txtファイルに，1行に 1つずつUUIDが記載された，インタフェースのUUIDのリストが含まれている場合があります。次のコマンドを実行すると，現在MANAGEDであるインタフェースに限り，それぞれのインタフェースがOUTOFSERVICEモードに変更されます。NOTMANAGEDモードのインタフェースは，変更されないままです。

nnmmanagementmode.ovpl -t interface -f neighbors.txt -mode MANAGED:OUTOFSERVICE

+--------------------------------------+---------+
| UUID                                 | 状態    |
+--------------------------------------+---------+
| 6f988a0f-c759-42d0-8e99-f3adce84fdd7 | UPDATED |
| 4dd87c33-9d0d-4713-b484-68c964ede6a6 | UPDATED |
| bc0af80f-d729-40d6-bb2f-ad8bd68e2deb | SKIPPED |
| bed3fff5-2385-4b09-9e3a-2572caaa624d | UPDATED |
| bd0723c0-6c53-47b1-ac13-41ecab16994e | UPDATED |
+--------------------------------------+---------+

ノードの管理モードに対するCSVファイルの構文

ノードの管理モードを設定するときに指定するCSVファイルは次の構文です。

空の行は無視されます。

"#"で始まる行は無視されます。

すべてのカラムが必要です。

Column 1(A) : Node DNS|IP Address

ノードのDNS名か，IPアドレスを指定します。検索アルゴリズムは次のとおりです。

一致する管理IPアドレスを持つノードを検索します。

デフォルトのドメインで一致するIPアドレスを持つノードを検索します。

一致するホスト名を持つノードを検索します。

一致する名前を持つノードを検索します。

Column 2(B) : Management mode

ノードに設定するモードを指定します。有効な値は，"MANAGED", "NOTMANAGED", または"OUTOFSERVICE" です。

例）

192.168.1.1,OUTOFSERVICE

my.fqdn.com, MANAGED

インタフェースの管理モードに対するCSVファイルの構文

インタフェースの管理モードを設定するときに指定するCSVファイルは次の構文です。

空の行は無視されます。

"#"で始まる行は無視されます。

すべてのカラムが必要です。

Column 1(A) : Node DNS|IP Address

ノードのDNS名か，IPアドレスを指定します。検索アルゴリズムは次のとおりです。

一致する管理IPアドレスを持つノードを検索します。

デフォルトのドメインで一致するIPアドレスを持つノードを検索します。

一致するホスト名を持つノードを検索します。

一致する名前を持つノードを検索します。

Column 2(B) : Interface id

前のフィールドで指定したノードのインタフェースの識別子を指定します。検索アルゴリズムは次のとおりです。

ifIndex

ifName

ifAlias

ifDescription

Column 3(C) : Mode

インタフェースに設定するモードを指定します。有効な値は，"INHERITED", "NOTMANAGED", "OUTOFSERVICE" です。

例）

192.168.1.1,1,OUTOFSERVICE

my.fqdn.com, myAlias, INHERITED

IPアドレスの管理モードに対するCSVファイルの構文

IP アドレスの管理モードを設定するときに指定するCSVファイルは次の構文です。

空の行は無視されます。

"#" で始まる行は無視されます。

すべてのカラムが必要です。

Column 1(A) : IP Address

IP アドレスを指定します。同じ値のIPアドレスが複数ある場合は，次のカラムにテナント名を指定して区別します。

Column 2(B) : Tenant name

IP アドレスのホスト元ノードが属するテナントの名前。この値が空の場合は，すべてのテナントからIPアドレスのオブジェクトが検索されます。

Column 3(C) : Mode

IPアドレスに設定するモードを指定します。有効な値は，"INHERITED", "NOTMANAGED", "OUTOFSERVICE" です。

例）

192.168.1.1, my tenant, OUTOFSERVICE

192.168.1.1, ,INHERITED

RETURN VALUE

エラーが発生しなかった場合，nnmmanagementmode.ovplは0（ゼロ）を返します。それ以外の場合，1を返します。

AUTHOR

nnmmanagementmode.ovpl was developed by Micro Focus.

付録G.36　nnmmonconfig.ovpl

SYNOPSIS

nnmmonconfig.ovpl

nnmmonconfig.ovpl listGlobalSettings

nnmmonconfig.ovpl updateGlobalSettings [-statePolling <true|false>]

nnmmonconfig.ovpl listEffective -node <node|uuid> [-interface <interface> | -interfaces]

DESCRIPTION

nnmmonconfig.ovplスクリプトは，State Poller設定を一覧表示，更新するオプションとパラメーターを提供します。nnmmonconfig.ovpl コマンドラインの一般的なフォーマットは次のとおりです。

nnmmonconfig.ovpl <command> <options>

下記のCommands項には，使用可能なコマンドの選択肢が一覧表示されています。同様にOptions項には，各コマンドで使用可能なオプションが一覧表示されています。多くのコマンドで類似のオプションを使用できます。各コマンドで使用できる正しいオプションについては，上記のSynopsis項を参照してください。

Commands

listGlobalSettings

グローバルな監視設定の一覧を表示します。

updateGlobalSettings

グローバルな監視設定のフィールドを更新します。

listEffective

ノードやインターフェイスに設定された監視設定の一覧を表示します。

Options

-statePolling <true|false>

状態ポーリングを有効または無効にします。

-node <node|uuid>

監視設定を表示するノードを指定します。nodeにはノードの名前またはホスト名を指定します。

-interface <interface>

監視設定を表示するインターフェイスを指定します。interfaceにはインターフェイスの名前を指定します。

-interfaces

指定されたノードのすべてのインタフェースを一覧表示します。

Additional Parameters

-fields <fields>

表形式のデータが存在しているときに出力フィールドを選択します。

-format <style>

表形式のデータが存在しているときに出力形式を変更します。指定できる値は，"TEXT", "LIST", "CSV", または "XML" です。

-http.host <host>

サーバーのホスト。デフォルトはlocalhostです。

-http.port <port>

サーバーのポート。デフォルトは80です。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。

-quiet

通常の出力を抑制し，エラーだけを表示します。

付録G.37　nnmnodedelete.ovpl

NNMiトポロジデータベースからノードと関連データを削除します。

SYNOPSIS

nnmnodedelete.ovpl -help | -node <hostName> | -rm <Regional NNMi management server> | -file <filename> | -all [-u <username> -p <password>]

DESCRIPTION

nnmnodedelete.ovplはシステムからノードと関連データ（インタフェース，IPアドレスなど）を削除します。この処理の結果，VLANやサブネットが空になると，これらも同様に削除されます。インシデントがこのノードを指している場合は，ソースノードフィールドが空白になりますが，インシデントは削除されません。ノードはホスト名フィールドを使用して特定されます。

-rmオプションはリージョナルNNMiサーバーの名前を指定します。リージョナルマネージャに管理されているノードは，ローカルのデータベースから削除されます。

-fileオプションでは，1行ごとに単一エントリがあるファイルを受け入れます。各行のフォーマットは次のとおりです。

HostName #（ノードを識別するために役に立つ任意のコメント，必要な場合）

ここで，HostNameは追加するノードのホスト名です。コメントは#文字の後に追加します。

Parameters

nnmnodedelete.ovplコマンドは，次のオプションをサポートします。

-node <hostName>

削除するノードのホスト名を指定します。

-rm <Regional NNMi management server>

リージョナルNNMiサーバーの名前を指定します。

-file <fileName>

ノードを読み込む元のテキストファイルを指定します。

-all

すべてのノードを削除します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要な NNMi の管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-help

コマンドの使用方法を表示します。

EXAMPLES

nnmnodedelete.ovpl -u username -p password -node myNode

ノードmyNodeを削除します。（NNMi ユーザー名とパスワードを指定する必要があります。）

nnmnodedelete.ovpl -u username -p password -rm myRegionalManager

myRegionalManagerに関連するすべてのノードを削除します。（NNMiユーザー名とパスワードを指定する必要があります。）

nnmnodedelete.ovpl -u username -p password -file myFile

myFileファイルで指定したノードを読み込み，データベースからノードを削除することを試みます。（NNMiユーザー名とパスワードを指定する必要があります。）

Diagnostics

nnmnodedelete.ovplコマンドは，次の終了コードを返します。

0

処理は成功しました。

1

エラーが発生しました。詳細はエラーメッセージを参照してください。

2

一部成功しましたが，削除されなかったノードがあります。詳細はエラーメッセージを参照してください。

AUTHOR

nnmnodedelete.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmnodedelete.ovpl

Linux：$NNM_BIN/nnmnodedelete.ovpl

NOTES

削除したノードが自動検出ルールによって作成されたノードだった場合，そのノードは再検出されることがあります。これを回避するには，［検出の設定］フォームの［除外対象IPアドレス］タブに対象ノードのIPアドレスを追加します。

SEE ALSO

nnmseeddelete.ovpl, nnmnoderediscover.ovpl, nnmtopodump.ovpl, nnmresetembdb.ovpl, nnm.properties.

付録G.38　nnmnodegroup.ovpl

ノードグループおよびノードグループ階層を管理します。

SYNOPSIS

nnmnodegroup.ovpl -h | -help

nnmnodegroup.ovpl -add -group (<name>|<uuid>) [-file <file>|-node <nodeList>] [-deviceType <deviceType>] [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -create -name <name> [-file <file>|-node <nodeList>] [-filter <filter>] [-notes <notes>] [-parent <parent> [-expand (true|false)]] [-uuid <uuid>] [-addToViewFilterList (true|false)] [-calculateStatus (true|false)] [-deviceType <deviceType>] [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -delete -group (<name>|<uuid>) [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -list [-fields <fields>] [-format <format>] [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -listChildGroups -group <group> [-fields <fields>] [-format <format>] [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -listMembers -group (<name>|<uuid>) [-deep] [-fields <fields>] [-format <format>] [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -listParentGroups -group <group> [-fields <fields>] [-format <format>] [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -printNodes <group name> [ -hostName | -shortName | -uuid | -ip ] [-u <username> -p <password>]

nnmnodegroup.ovpl -relate -child <child> -parent <parent> [-expand (true|false)] [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -reload [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -remove -group (<name>|<uuid>) [-file <file>|-node <nodeList>] [-deviceType <deviceType>] [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -unrelate -child <child> -parent <parent> [-u <username> -p <password>] [-quiet]

nnmnodegroup.ovpl -update -group (<name>|<uuid>) [-addToViewFilterList (true|false)] [-calculateStatus (true|false)] [-deviceType <deviceType>] [-filter <filter>] [-name <newName>] [-notes <notes>] [-u <username> -p <password>] [-quiet]

DESCRIPTION

ノードグループおよびノードグループの階層を管理するために，nnmnodegroup.ovplコマンドを使用します。このコマンドによって，ノードグループの作成，更新，および削除や，ノードグループの階層の作成および削除することができます。また，ノードの追加またはノードグループフィルタの設定により，ノードグループに関連付けられているノードを管理することができます。

nnmnodegroup.ovplコマンドは，次を含む，複数の一覧表示の機能を提供します。

子ノードグループまたは親ノードグループのどちらかを一覧表示することによって，ノードグループの情報と階層を一覧表示します。

ノードグループ内のノードを一覧表示するには，-listMembersオプションを使用します。

データベース内のすべてのノードグループを一覧表示するには，-listオプションを使用します。

-printNodesオプションは，特定のノードグループに属するノード属性を出力します。ノード属性を出力する場合，グループ名は必須の引数です。ほかの引数が与えられていない場合，各ノードのホスト名，短縮名，UUID，および管理IPアドレス属性がダンプされます。ノードごとに一つのカンマで行が区切られます。-printNodesオプションは，以前のバージョンのNNMiで提供されていた，非推奨/従来のコマンドであることに注意してください。この使用法は，後方互換性のために残してあります。このため，行頭にダッシュ記号を指定する必要があります。すなわち，-printNodesは動作しますが，printNodesは動作しません。新しいlistMembersオプションはprintNodesに置き換わるものです。

Parameters

nnmnodegroup.ovplコマンドは，次のオプションをサポートします。

-add -group (<name>|<uuid>) [-file <file>|-node <nodeList>] [-deviceType <deviceType>]

ノードグループにノードまたはデバイスタイプのフィルターを追加します。-group に加えて，少なくとも一つの追加の引数を指定する必要があります。

-group (<name>|<uuid>)

ノードグループの名前またはUUIDです。

-file <file>

ノード名，UUID，およびIPアドレスを含むテキストファイルです。

-node <nodeList>

ノード名，UUID，およびIPアドレスのカンマ区切りリストです。

-deviceType <deviceType>

ノードグループのノードを選択するために使用します。デバイスタイプのパラメータは，文字列をコロンで区切ったリストです。各カテゴリの形式は次のとおりです。

category:vendor:family:profile

-create -name <node group name> [-addToViewFilterList (true|false)] [-calculateStatus (true|false)] [-deviceType <deviceType>] [-expand (true|false)] [-file <file>|-node <nodeList>] [-filter <filter>] [-notes <notes>] [-parent <parent>] [-uuid <uuid>]

新しいノードグループを作成します。

-name <name>

作成されるノードグループの名前です。

-addToViewFilterList (true|false)

テーブルを表示するときに，ドロップダウンフィルターリストにノードグループが含まれます。

-calculateStatus (true|false)

ノードグループのステータスを計算します。

-deviceType <deviceType>

ノードグループのノードを選択するために使用します。デバイスタイプのパラメータは，文字列をコロンで区切ったリストです。各カテゴリの形式は次のとおりです。

category:vendor:family:profile

-expand (true|false)

親マップでノードグループを展開します。-parentオプションを指定する必要があります。

-file <file>

ノード名，UUID，およびIPアドレスを含むテキストファイルです。

-filter <filter>

ノードグループ内のノードを選択するために使用されるフィルター式です。属性が式に一致するノードがグループに含められます。

-node <nodeList>

ノード名，UUID，およびIPアドレスのカンマ区切りリストです。

-notes <notes>

ノードグループに添付する注記です。

-parent <parent>

追加しようとしているノードグループが，子ノードグループとして追加される場合の，親ノードグループの名前です。

-uuid <uuid>

ノードグループに割り当てる UUID です。

-delete -group (<name>|<uuid>)

ノードグループを削除します。

-group (<name>|<uuid>)

削除するノードグループの名前またはUUIDです。

-list [-fields <fields>] [-format <format>]

データベース内のノードグループの名前を出力します。

-fields <fields>

表データを出力するフィールドを選択します。

-format <format>

テーブルデータの出力形式を設定します；有効な値はTEXT，LIST，CSVまたはXMLです。

-listChildGroups -group <group> [-fields <fields>] [-format <format>]

指定されたノードグループの子ノードグループを一覧表示します。

-group <group>

子ノードグループを一覧表示するためのノードグループ名です。

-fields <fields>

表データを出力するフィールドを選択します。

-format <format>

テーブルデータの出力形式を設定します；有効な値はTEXT，LIST，CSVまたはXMLです。

-listMembers -group (<name>|<uuid>) [-deep] [-fields <fields>] [-format <format>]

指定されたノードグループのノードを出力します

-group (<name>|<uuid>)

ノードグループの名前またはUUIDです。

-deep

デフォルトでは，listMembersはノードグループのノードだけを出力します。-deepオプションは，ノードグループのすべてのノードとすべての子ノードグループのノードが一覧表示されます。

-fields <fields>

表データを出力するフィールドを選択します。

-format <format>

テーブルデータの出力形式を設定します；有効な値は TEXT，LIST，CSVまたはXMLです。

-listParentGroups -group <group> [-fields <fields>] [-format <format>]

指定されたノードグループの親ノードグループを一覧表示します。

-group <group>

親グループを一覧表示するためのノードグループ名です。

-fields <fields>

表データを出力するフィールドを選択します。

-format <format>

テーブルデータの出力形式を設定します；有効な値はTEXT，LIST，CSVまたはXMLです。

-printNodes <node group name> [-hostName | -shortName | -uuid | -ip]

指定したノードグループに属するノードの属性を出力します。追加のパラメータが指定されていない場合，各ノードのホスト名，短縮名，UUID，および管理IPアドレス属性が出力されます。ノードごとに一つのカンマで行が区切られます。

必要に応じて，次のパラメータの一つを指定することができます。指定した属性だけが出力されます。

-hostName

ノードグループに属する各ノードのホスト名を出力します。

-shortName

ノードグループに属する各ノードの短縮名を出力します。

-uuid

ノードグループに属する各ノードのUUIDを出力します。

-ip

ノードグループに属する各ノードの管理 IP アドレスを出力します。管理IPアドレスが決定できない場合は，nullが出力されます。

-relate -child <child> -parent <parent> [-expand (true|false)]

親と子の関係を作成するために，別のノードグループにノードグループをリンクします。

-child <child>

子ノードグループの名前です。

-parent <parent>

親ノードグループの名前です。

-expand (true|false)

親マップでノードグループを展開します。

-reload

ノードグループのキャッシュを再ロードします。追加ノードのリストまたはノードグループのフィルターを更新することによって，ノードを追加または削除した場合，数分間はキャッシュに変更が反映されないことがあるため，この操作が必要になることがあります。

-remove -group (<name>|<uuid>) [-file <file>|-node <nodeList>] [-deviceType <deviceType>]

ノードグループからノードを削除します。-groupに加えて，少なくとも一つの追加の引数を指定する必要があります。

-group (<name>|<uuid>)

ノードグループの名前またはUUIDです。

-file <file>

ノード名，UUID，およびIPアドレスを含むテキストファイルです。

-node <nodeList>

ノード名，UUID，およびIPアドレスのカンマ区切りリストです。

-deviceType <deviceType>

ノードグループのノードを選択するために使用します。デバイスタイプのパラメータは，文字列をコロンで区切ったリストです。各カテゴリの形式は次のとおりです。

category:vendor:family:profile

-unrelate -child <child> -parent <parent>

子と親のノードグループ間のノードグループ階層を削除します。

-child <child>

子ノードグループの名前です。

-parent <parent>

親ノードグループの名前です。

-update -group (<name>|<uuid>) [-addToViewFilterList (true|false)] [-calculateStatus (true|false)] [-deviceType <deviceType>] [-filter <filter>] [-name <newName>] [-notes <notes>]

ノードグループの属性を設定します。-groupに加えて，少なくとも一つの追加の引数を指定する必要があります。

-group (<name>|<uuid>)

ノードグループの名前またはUUIDです。

-addToViewFilterList (true|false)

テーブルを表示するときに，ドロップダウンフィルターリストにノードグループが含まれます。

-calculateStatus (true|false)

ノードグループのステータスを計算します。

-deviceType <deviceType>

ノードグループのノードを選択するために使用します。デバイスタイプのパラメータは，文字列をコロンで区切ったリストです。各カテゴリの形式は次のとおりです。

category:vendor:family:profile

-filter <filter>

ノードグループ内のノードを選択するために使用されるフィルター式です。属性が式に一致するノードがグループに含められます

-name <newName>

ノードグループの名前を，指定したnewNameに変更します。

-notes <notes>

ノードグループに添付する注記です。

-h | -help

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.properties ファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-quiet

通常の出力を抑制し，エラーだけを表示します。

EXAMPLES

"mygroup"という名前のノードグループを作成する場合：

nnmnodegroup.ovpl -create -name mygroup

ノード"a"と"b"を含む"mygroups2"という名前のノードグループを作成する場合：

nnmnodegroup.ovpl -create -name mygroup2 -node "a,b"

親として"mygroup"，子として"mygroup2"を持つノードグループ階層を作成する場合：

nnmnodegroup.ovpl -relate -parent mygroup -child mygroup2

ノードグループ"ルーター"に属するすべてのノードのホスト名，短縮名，UUID，および管理IPアドレスを出力する場合：

nnmnodegroup.ovpl -printNodes ルーター

ノードグループ"Non-SNMP Devices"に属するすべてのノードのホスト名だけを出力する場合：

nnmnodegroup.ovpl -printNodes "Non-SNMP Devices" -hostName

データベース内のノードグループ名を一覧表示する場合：

nnmnodegroup.ovpl -list

既存のノードグループの名前を変更し，ステータスの計算をfalseに変更する場合：

nnmnodegroup.ovpl -update -group myGroup -name newName -calculateStatus false

RETURN VALUE

エラーが発生しなかった場合はステータス0（ゼロ），それ以外の場合は1で終了します。

AUTHOR

nnmnodegroup.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmnodegroup.ovpl

Linux：$NNM_BIN/nnmnodegroup.ovpl

付録G.39　nnmnodegroupmapsettings.ovpl

ノードグループマップの設定およびノードグループマップのレイアウトを新規作成，更新，変更，および削除するために使用するコマンドラインツールです。

SYNOPSIS

nnmnodegroupmapsettings.ovpl -h | -help

nnmnodegroupmapsettings.ovpl create -nodeGroup <name|uuid> [-bgImage <string>] [-bgScale <float>] [-connThresh <number>] [-connType <string>] [-ifaceFilter <string>] [-isConnNodeGroups (true|false)] [-isConnNodes (true|false)] [-isL2Conn (true|false)] [-isL2ConnEdit (true|false)] [-isNeighborConn (true|false)] [-isShowIncidents (true|false)] [-mapRefresh <interval>] [-maxEndpoints <number>] [-maxNodes <number>] [-neighborConnFilter <string>] [-order <number>] [-role <string>]

nnmnodegroupmapsettings.ovpl list (-nodeGroup <name|uuid>|-uuid <uuid>)

nnmnodegroupmapsettings.ovpl update (-nodeGroup <name|uuid>|-uuid <uuid>) [-bgImage <string>] [-bgScale <float>] [-connThresh <number>] [-connType <string>] [-ifaceFilter <string>] [-isConnNodeGroups (true|false)] [-isConnNodes (true|false)] [-isL2Conn (true|false)] [-isL2ConnEdit (true|false)] [-isNeighborConn (true|false)] [-isShowIncidents (true|false)] [-mapRefresh <interval>] [-maxEndpoints <number>] [-maxNodes <number>] [-neighborConnFilter <string>] [-order <number>] [-role <string>]

nnmnodegroupmapsettings.ovpl delete (-nodeGroup <name|uuid>|-uuid <uuid>)

nnmnodegroupmapsettings.ovpl exists (-nodeGroup <name|uuid>|-uuid <uuid>)

nnmnodegroupmapsettings.ovpl pin list -nodeGroup <name|uuid>

nnmnodegroupmapsettings.ovpl pin update (-nodeGroup <name|uuid> -nodeName <name> [-x <value>] [-y <value>]) | -f <csv_file>

nnmnodegroupmapsettings.ovpl annotation create -nodeGroup <name|uuid> [-text <string>] [-style <string>] [-fontFamily <string>] [-fgColor <color>] [-bgColor <color>] [-bgAlpha <value>] [-x <value>] [-y <value>] [-scale <value>] [-width <value>] [-height <value>] [-zIndex <value>]

nnmnodegroupmapsettings.ovpl annotation list -nodeGroup <name|uuid>

nnmnodegroupmapsettings.ovpl annotation update -uuid <annotation_uuid> [-text <string>] [-style <string>] [-fontFamily <string>] [-fgColor <color>] [-bgColor <color>] [-bgAlpha <value>] [-x <value>] [-y <value>] [-scale <value>] [-width <value>] [-height <value>] [-zIndex <value>]

nnmnodegroupmapsettings.ovpl annotation delete -uuid <annotation_uuid>

DESCRIPTION

nnmnodegroupmapsettings.ovplは，ノードグループマップの設定を新規作成，更新，変更，および削除するために使用するコマンドラインツールです。ノードグループマップの設定は，ノードグループごとに個別に作成されます。ノードグループマップの設定は，ノードグループ名またはUUIDまたはマップ設定UUIDによって更新または削除される場合があります。さらに，任意のノードグループ設定の詳細を画面に一覧表示したり，CVSやXMLなどの各種形式にフォーマットしたりできます。

nnmnodegroupmapsettings.ovplは，ノードグループマップビューのノードやサブネットなどのマップオブジェクトの位置の調整やマップ注釈の編集も可能です。この機能を使うためには，ユーザーはノードグループマップの設定で指定されたマップの保存に必要なロールを満たす必要があります。

Commands

nnmnodegroupmapsettings.ovplコマンドは，次のサブコマンドの先頭に-（ハイフン）をつけた場合も動作可能です。

create

指定したノードグループ用の新しいノードグループマップの設定を作成します。

list

指定したノードグループ名またはUUIDのノードグループマップの設定情報を一覧表示します。ノードグループ名またはUUIDを指定しない場合は，すべてのノードグループのすべての設定を一覧表示します。

update

指定されたノードグループマップの設定を更新します。ノードグループマップの設定フィールドにnullを設定する場合は，値なしで引数を指定してください。例えば，

nnmnodegroupmapsettings.ovpl -update -nodeGroup ルーター -ifaceFilter

ノードグループ，接続タイプ，およびロールのフィールドは値を必要とし，nullに設定することはできません。

delete

指定したノードグループマップの設定を削除します。

exists

指定したノードグループのノードグループマップ設定が存在するかどうかを確認します。ノードグループマップ設定が存在する場合は"true"を出力し，存在しない場合はその旨のメッセージを出力します。

pin list

ノードグループマップで保存されたマップオブジェクトの位置を一覧表示します。あるノードグループマップビューに新たに追加されたマップオブジェクトは，位置が保存されるまではこの一覧には表示されません。マップオブジェクトの位置を保存するには，NNMiコンソールのノードグループマップビューで「マップを保存」を使用してください。

「-format csv」オプションを使用したこのコマンドの出力は，ヘッダー行を削除することで「pin update」の入力に使用可能です。

pin update

ノードグループマップの指定したマップオブジェクトの位置を更新します。コマンドライン引数を使用した単一のマップオブジェクトの位置を更新と，CSVファイルを使用した複数の位置の更新が可能です。このコマンドを使用する前に，NNMiコンソールのノードグループマップビューで「マップを保存」を使用しマップオブジェクトの位置を保存する必要があります。

このコマンドによって，NNMiコンソールでは編集できない位置にマップオブジェクトを移動することが可能になる場合があります。そのようになった場合は，このコマンドを用いて有効な位置にマップオブジェクトを移動するか，NNMiコンソールのノードグループマップビューで「レイアウトのクリア」を使用してください。

annotation create

指定したノードグループマップにマップ注釈を作成します。

annotation list

指定したノードグループマップのマップ注釈を一覧表示します。

annotation update

指定したマップ注釈を更新します。

annotation delete

指定したマップ注釈を削除します。

Parameters

nnmnodegroupmapsettings.ovplコマンドは，次のオプションをサポートします。

-h | -help

コマンドの使用方法を表示します。

-bgAlpha <value>

マップ注釈のボックスの背景色の透明度です。有効な値の範囲は0.0から1.0です。

-bgColor <value>

マップ注釈のボックスの背景色です。値の形式は"<Red>,<Green>,<Blue>"で有効な値の範囲は0から255です。例："0,128,255"

-bgImage <string>

ノードグループマップに関連付けられる，背景イメージファイルの名前です。

-bgScale <float>

ノードグループマップに関連付けられる，背景イメージファイルのスケールです。浮動小数点の値として解釈されます。デフォルト値は1.0です。

-connThresh <number>

複数接続しきい値です。接続を多重接続に折りたたまないで表示する，ノード間またはノードグループ間の接続の最大数です。

-connType <string>

接続タイプです。接続のタイプは，関連するノードグループマップに表示されます。有効な値は，"none"，"L2" または"L3"です。引数は大文字と小文字を区別しない方法で解釈されます。デフォルト値は"none"です。

-f <CSV file>

マップオブジェクトの位置の更新に使うCSVファイルです。

CSVファイルは以下の形式に従う必要があります。

空行は無視されます。"#"から始まる行は無視されます。全ての列は必須です。

列1(A)：ノードグループの名前またはUUID

列2(B)：位置を更新するマップオブジェクトの名前

このマップオブジェクトの名前は，pin listコマンドに表示される名前と同じにします。インベントリやノードグループマップビューに表示される名前とは異なる可能性があります。

列3(C)：マップオブジェクトの位置のX座標

列4(D)：マップオブジェクトの位置のY座標

行の例：

ルーター,test-node,100,200

-fgColor <value>

マップ注釈の文字色です。値の形式は"<Red>,<Green>,<Blue>"で有効な値の範囲は 0 から255です。例:"0,128,255"

-fontFamily <value>

マップ注釈のテキストのフォントです。有効な値は"sans-serif"，"serif"，"monospace"または"cursive"です。

-height <value>

マップ注釈の領域の高さです。

-ifaceFilter <string>

関連するノードグループマップに適用する，終了ポイントインタフェースのフィルターの名前です。

-isConnNodeGroups (true|false)

関連するノードグループマップにノードグループを接続するかどうかを示すフラグです。ブール値として解釈します。"true"は，どのような大文字と小文字の組み合わせで設定してもtrueと解釈されますが，その他すべての引数の値はfalseと解釈されます。

-isConnNodes (true|false)

関連するノードグループマップにノードを接続するかどうかを示すフラグです。ブール値として解釈します。"true"は，どのような大文字と小文字の組み合わせで設定してもtrueと解釈されますが，その他すべての引数の値はfalseと解釈されます。

-isL2Conn (true|false)

IPv4サブネット接続ルールによって判別されたレイヤー2接続を，関連するノードグループマップ上に表示するかどうかを示すフラグです。ブール値として解釈します。"true"は，どのような大文字と小文字の組み合わせで設定してもtrueと解釈されますが，その他すべての引数の値はfalseと解釈されます。

-isL2ConnEdit (true|false)

nnmconnedit.ovplコマンドラインツールを使用して追加したレイヤー2接続編集を，関連するノードグループマップ上に表示するかどうかを示すフラグです。ブール値として解釈します。"true"は，どのような大文字と小文字の組み合わせで設定してもtrueと解釈されますが，その他すべての引数の値はfalseと解釈されます。

-isNeighborConn (true|false)

ノードグループのメンバーではない（1ホップ離れた距離にある）主要なネットワークデバイスへの追加接続を行うかどうかを示すフラグです。ブール値として解釈します。"true"は，どのような大文字と小文字の組み合わせで設定してもtrueと解釈されますが，その他すべての引数の値はfalseと解釈されます。フィルターが提供されていない場合は，「ネットワーキングインフラストラクチャデバイス」ノードグループがフィルターとして使用されます。子ノードグループのデバイスフィルターがあっても無視されます。

-isShowIncidents (true|false)

ノードグループマップ上で重要なインシデントと関連するノードのマップシンボルを拡大表示するかどうかを示すフラグです。ブール値として解釈します。"true"は，どのような大文字と小文字の組み合わせで設定してもtrueと解釈されますが，その他すべての引数の値はfalseと解釈されます。

-mapRefresh <interval>

分と秒で指定するマップのリフレッシュ間隔です。フォーマットはmmMssSの形で，mm，ssには0～59の数値を入れます。例：59M59S(最大値)，1S(1秒)，5M(5 分)，5M30S(5分30秒)

-maxEndpoints <number>

関連するノードグループマップ上に表示される，エンドポイントの最大数です。

-maxNodes <number>

関連するノードグループマップ上に表示される，ノードの最大数です。

-neighborConnFilter <string>

ノードグループに所属していない，1ホップ近隣のノードをノードグループマップに表示する場合に，フィルターの役割を果たすノードグループです。ノードグループに対して定義されたデバイスフィルターがあれば，候補となる近隣ノードに適用されます。重要な注意 - フィルターを適用するとき，子ノードグループは無視されます。isNeighborConnオプションの説明も参照してください。

-nodeGroup (<name>|<uuid>)

ノードグループの名前です。

-nodeName <name>

マップオブジェクトの名前です。

-order <number>

整数で指定された，ノードグループマップの設定の優先順序です。番号が低いほど優先度が高くなります。例えば，1は10よりも高い優先順序です。

-role <string>

ノードグループマップ設定にアクセスするために必要なユーザーロールです。有効な値は"admin"，"client"，"level1"，"level2"です。引数は大文字と小文字を区別しない方法で解釈されます。デフォルト値は"admin"です。

-scale <value>

マップ注釈のテキストのスケールです。有効な値の範囲は0.2から10000です。

-style <value>

マップ注釈のテキストのスタイルです。有効な値は"normal"，"bold"，"italic"または"bold-italic"です。

-text <string>

マップ注釈のテキストです。

-uuid <value>

ノードグループマップ設定かマップ注釈のUUIDです。

-width <value>

マップ注釈の領域の幅です。

-x <value>

マップ注釈かマップオブジェクト位置のX座標です。

-y <value>

マップ注釈かマップオブジェクト位置のY座標です。

-zIndex <value>

マップ注釈のZ-indexです。

Additional Parameters

-fields <fields>

表形式のデータが存在しているときに出力フィールドを選択します。

-format <style>

一覧表示の出力形式です。'text','list','csv'および'xml'が利用できます。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-quiet

通常の出力を抑制し，エラーだけを表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

FORMATTING RULES

ノードグループ名を指定するとき，スペースが存在する場合は，名前を二重引用符で囲みます。（例："Important Nodes"）

EXAMPLES

必須の引数だけでノードグループマップの設定を作成します。

nnmnodegroupmapsettings.ovpl create -nodeGroup Routers -connType L3 -role admin

オプションの引数でノードグループマップの設定を作成します。

nnmnodegroupmapsettings.ovpl create -nodeGroup Switches -connType L2 -bgImage /images/Colorado.png -bgScale .75 -connThresh 3 -ifaceFilter "VLAN Interfaces" -isConnNodeGroups true -isConnNodes t -isL2Conn true -isL2ConnEdit True -mapRefresh 5M -maxEndpoints 200 -maxNodes 100 -order 10 -role admin

指定されたノードグループのノードグループマップ設定を一覧表示します。属性データがテーブルに表示されます。

nnmnodegroupmapsettings.ovpl list -nodeGroup "Important Nodes"

ノードグループマップ設定のすべてを一覧表示します。属性データがテーブルに表示されます。

nnmnodegroupmapsettings.ovpl list

指定されたノードグループのノードグループマップの設定をCSV形式で一覧表示します。

nnmnodegroupmapsettings.ovpl list -nodeGroup "Non-SNMP Devices" -format csv

ノードグループ名によってノードグループマップ設定を削除します。

nnmnodegroupmapsettings.ovpl delete -nodeGroup "Routers"

設定のUUIDによってノードグループマップ設定を削除します。

nnmnodegroupmapsettings.ovpl delete -uuid 204846c0-a35b-4a92-9726-4ce0a8be596d

ノードグループのノードグループマップ設定を更新します。

nnmnodegroupmapsettings.ovpl update -nodeGroup Routers -bgImage /images/Denver.png -bgScale .75 -connThresh 2 -ifaceFilter "Point to Point Interface" -isConnNodeGroups true -isConnNodes t -isL2Conn false -isL2ConnEdit False -mapRefresh 4M30S -maxEndpoints 200 -maxNodes 100 -order 15 -role admin

AUTHOR

nnmnodegroupmapsettings.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmnodegroupmapsettings.ovpl

Linux：$NNM_BIN/nnmnodegroupmapsettings.ovpl

付録G.40　nnmnoderediscover.ovpl

ノードの再検出

SYNOPSIS

nnmnoderediscover.ovpl -help | -node <hostName> [-tenant <name>] [-fullsync] | -rm <Regional NNMi management server> [-fullsync] | -file <filename> [-tenant <name>] [-fullsync] | -all [-fullsync] [-u <username> -p <password>]

DESCRIPTION

nnmnoderediscover.ovplはNNMi検出キューにノードを挿入します。ノードが検出を始める前の時間の量は，キュー中のノードに到着するために，NNMiがどれくらいの時間がかかるかに依存します。

ノードが既に検出キューにある場合，それが再び加えられることはありません。

NNMi Advancedのグローバルネットワーク管理機能を使用している場合，リージョナルマネージャによって管理されるノードは，リージョナルマネージャで検出され，グローバルマネージャで再検出されません。

-rmオプションは，NNMi Advancedのグローバルネットワーク管理機能で，グローバルマネージャでnnmnoderediscover.ovplコマンドを実行する場合に使用します。NNMiは，リージョナルマネージャに対して，リージョナルマネージャからグローバルなマネージャへ最新の利用可能な検出結果を送ることを要求するリクエストを送ります。

-fileオプションは，1行に一つの項目を指定したファイルを受けつけます。それぞれの行には短い名前，完全修飾DNSドメインネーム，あるいはIPアドレスを含めます。それぞれの行は次のフォーマットです：HostName#（必要に応じてノードを識別するためのコメント）HostNameは挿入したいノードの短い名前，完全修飾DNSドメインネーム，あるいはIPアドレスです。

-allオプションは，ローカルのNNMi管理サーバーによって管理されたノードをすべて再検出します。NNMi Advancedのグローバルネットワーク管理機能を使用していて，グローバルマネージャでnnmnoderediscover.ovplコマンドを実行する場合，リージョナルマネージャによって管理されるノードは，リージョナルマネージャからグローバルマネージャの元へ最新の利用可能な検出結果を送ります。

-tenantオプションは，アドレスのドメインが重複している場合など，名前またはIPアドレスが一意でないノードを特定します。この引数によって渡される名称は，そのノードが属しているテナント名です。

-fullsyncオプションは，ノードの再検出後に，そのノードの状態およびステータスを再同期します。グローバルマネージャから実行した場合，グローバルマネージャのノードがリージョナルマネージャ上のノード情報に基づいて更新されます。リージョナルマネージャから実行した場合，コマンドはリージョナルのノードについて再同期を実行し，さらにそのリージョナルマネージャに属するノードについてグローバルマネージャ上で再同期を実行します。これはオプションのフラグであり，再検出する対象ノードを選択するアルゴリズムには影響を与えません。

Parameters

nnmnoderediscover.ovplコマンドは，次のオプションをサポートします。

-node <hostName>

再検出するノードのホスト名を指定します。

-rm <Regional NNMi management server>

NNMi Advancedのグローバルネットワーク管理機能を使用していて，グローバルマネージャでnnmnoderediscover.ovplコマンドを実行する場合，リージョナルマネージャの接続の設定の「名前」属性です。

-file <filename>

ノードを読み込むテキストファイルを指定します。

-all

すべてのノードを再検出するときに指定します。

-tenant <name>

ノードの名前またはIPアドレスと組み合わせて，名前またはIPアドレスが一意でない可能性のあるドメインでノードを特定するための任意のオプションです。

-fullsync

各ノードの再検出後に，ノードの状態とステータスを再同期するようNNMiに指示する任意のオプションです。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-help

コマンドの使用方法を表示します。

EXAMPLES

nnmnoderediscover.ovpl -u username -p password -node myNode -tenant myTenant

テナント myTenant のメンバーであるノードmyNodeを再検出します。有効なNNMi管理者のユーザー名とパスワードを指定する必要があります。

nnmnoderediscover.ovpl -u username -p password -rm myRegionalManager

myRegionalManagerに関連するすべてのノードを再検出します。有効なNNMi管理者のユーザー名とパスワードを指定する必要があります。

nnmnoderediscover.ovpl -u username -p password -file myFile -fullsync

myFileファイルに指定されたノードを読み込み，NNMi検出キューに挿入します。各ノードの再検出後に，ノードの状態とステータスを再同期します。有効なNNMi管理者のユーザー名とパスワードを指定する必要があります。

Diagnostics

nnmnoderediscover.ovplコマンドは，次の終了コードを返します。

0

処理は成功しました。

1

エラーが発生しました。詳細はエラーメッセージを参照してください。

AUTHOR

nnmnoderediscover.ovpl was developed by Micro Focus.

SEE ALSO

nnmdiscocfg.ovpl, nnmloadseeds.ovpl, nnmseeddelete.ovpl, nnm.properties.

付録G.41　nnmnotes.ovpl

1つまたは複数のノードの注を表示または更新します。

SYNOPSIS

nnmnotes.ovpl print -type <object type> (-name <name> | -uuid <uuid> | -filter <filter> | -all) [-format <format>] [-fields <fields>]

nnmnotes.ovpl update -type <object type> { ( (-name <name> | -uuid <uuid>) -notes <notes>) | -file <file>} [-format <format>] [-fields <fields>]

DESCRIPTION

nnmnotes.ovplを使用すると，NNMiデータベース内の1つまたは複数のノードの注を表示または更新できます。

Parameters

nnmnotes.ovpl printコマンドは，次のオプションをサポートします。

-h

コマンドの使用方法を表示します。

-all

引数"-type"で指定されたタイプのすべてのオブジェクトを選択します。

-filter <filter>

オブジェクトを選択するためのスペースを含まないフィルター文字列を指定します。フィルター文字列を含む注を持つオブジェクトが選択されます。

-name <name>

オブジェクトの名前を指定します。オブジェクトのタイプが"node"である場合はノードの名前を指定します。

-type <object type>

注を出力または更新するオブジェクトのタイプを指定します。有効な値は"node"です。

-uuid <uuid>

オブジェクトのUUIDを指定します。

Options for print command

nnmnotes.ovpl printコマンドは，次のオプションをサポートします。

-h

コマンドの使用方法を表示します。

-all

引数"-type"で指定されたタイプのすべてのオブジェクトを選択します。

-filter <filter>

オブジェクトを選択するためのスペースを含まないフィルター文字列を指定します。フィルター文字列を含む注を持つオブジェクトが選択されます。

-name <name>

オブジェクトの名前を指定します。オブジェクトのタイプが"node"である場合はノードの名前を指定します。

-type <object type>

注を出力または更新するオブジェクトのタイプを指定します。有効な値は"node"です。

-uuid <uuid>

オブジェクトのUUIDを指定します。

Options for update command

nnmnotes.ovpl updateコマンドは，次のオプションをサポートします。

-h

コマンドの使用方法を表示します。

-file <file>

CSVファイル名（パス名付きで，例えば/opt/tmp/mynodes.csv）を指定します。ファイルに不正な定義（カラムが多い，または少ないなど）がある場合，コマンドはその定義を出力し，すべての定義が実行されません。

-name <name>

オブジェクトの名前を指定します。オブジェクトのタイプが"node"である場合はノードの名前を指定します。

-notes <notes>

指定された文字列で注を更新します。文字列にスペースが含まれている場合は，文字列をダブルクォーテーション（"）で囲んでください。文字列が空文字（""），または文字列が指定されていない場合は，注を空文字で更新します。

-type <object type>

注を出力または更新するオブジェクトのタイプを指定します。有効な値は"node"です。

-uuid <uuid>

オブジェクトのUUIDを指定します。

Additional Parameters

-fields <comma_separated_fields>

表形式のデータが存在しているときに出力フィールドを選択します。

-format <style>

表形式のデータの出力形式を設定します。有効な値は，"TEXT"，"LIST"，"CSV"，または"XML"です。

-jndiHost <hostname>

jndiサーバーのホスト名です。デフォルトの値は"localhost"です。

-jndiPort <port>

jndiサーバーのポート番号です。デフォルト値は1099です。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，この引数の指定が必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-quiet

通常の出力を抑制し，エラーだけを表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，この引数の指定が必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

"-fields"引数がサポートする値

オブジェクトのタイプが"node"である場合，有効な値は，"name"，"uuid"，"tenant"，"notes"です。

updateコマンドに対するCSVファイルがサポートする文字コード

注を更新するときに指定するCSVファイルの文字コードはNNMiサーバーのロケールに一致している必要があります。例えばWindows日本語環境の場合はShift-JIS（Windows-31J）を指定してください。

updateコマンドに対するCSVファイルの構文

注を更新するときに指定するCSVファイルは次の構文です。

空の行は無視されます。

"#"で始まる行は無視されます。

すべてのカラムが必要です。

Column 1(A): Object's Name|UUID

オブジェクトの名前，またはUUIDを指定します。

Column 2(B): Notes

注を指定します。オブジェクトの注は指定された文字列に更新されます。

文字列にスペースやカンマ（,）が含まれている場合は，文字列をダブルクォーテーション（"）で囲んでください。

文字列が空文字（""），または文字列が指定されていない場合は，注を空文字で更新します。

EXAMPLES

オブジェクトの名前を指定して注を表示します。

nnmnotes.ovpl print -type node -name mynode

オブジェクトのUUIDを指定して注を表示します。

nnmnotes.ovpl print -type node -uuid d913a5c6-e297-4243-8c18-4ea2ff61e32b

フィルター文字列を指定して注を表示します。

nnmnotes.ovpl print -type node -filter server

指定したタイプのすべてのオブジェクトの注を表示します。

nnmnotes.ovpl print -type node -all

オブジェクトの名前を指定して注を更新します。

nnmnotes.ovpl update -type node -name mynode -notes "This is test machine."

オブジェクトのUUIDを指定して注を更新します。

nnmnotes.ovpl update -type node -uuid d913a5c6-e297-4243-8c18-4ea2ff61e32b -notes "This is test machine."

CSVファイルを指定して注を更新します。

nnmnotes.ovpl update -type node -file /opt/tmp/mynodes.csv

RETURN VALUE

エラーが発生しなかった場合，nnmnotes.ovplは0（ゼロ）を返します。それ以外の場合，1を返します。

AUTHOR

nnmnotes.ovpl was developed by Micro Focus.

付録G.42　nnmofficialfqdn.ovpl

NNMi 管理サーバーの正式な完全修飾名（FQDN）を表示します。

SYNOPSIS

nnmofficialfqdn.ovpl

DESCRIPTION

nnmofficialfqdn.ovplは，正式な完全修飾名（FQDN）を表示する場合に使用します。正式FQDNは，インストール時にNNMiが設定します。インストール後は，nnmsetofficialfqdn.ovplコマンドで変更できます。

Parameters

デフォルトでnnmofficialfqdn.ovplはpingのテストを含めた，冗長な結果を表示します。nnmofficialfqdn.ovplコマンドは，次のオプションをサポートします。

-d

正式FQDNのドメイン名を表示します。FQDNがショートホスト名またはIPアドレスの場合，および-tオプション（簡易表示モード）を使用した場合，NNMiは値を表示しません。それ以外の場合，NNMiはドメイン名が見つからなかった旨のメッセージを表示します。

-t

簡易表示モード。FQDNまたはドメイン名の値だけを表示します。FQDNまたはドメイン名が見つからなかった場合に，警告メッセージ等のテキストは表示されません。このオプションを指定した場合は，pingテストも省略されます。

-m

デフォルトFQDNを照会し，値を表示します。NNMiは次の順序で照会を行って，最初に見つかった値を表示します。

FQDN

ショートホスト名

IPアドレス

どれも見つからなかった場合は，'localhost'が表示されます。

-h

すべてのオプションを一覧表示したヘルプメニューを表示します。

EXAMPLES

オプションを何も指定せずにコマンドを実行した場合は，正式FQDNを表示し，pingテストを行います。

# nnmofficialfqdn.ovpl
      FQDN:
      hostname.somedomain
      pingテスト: hostname.somedomainに対してpingを行っています。しばらくお待ちください
      pingが正常に完了しました

-tオプションを指定してコマンドを実行した場合は，正式 FQDN が次のように表示されます。

# nnmofficialfqdn.ovpl -t
      hostname.somedomain

-dオプションを指定してコマンドを実行した場合は，ドメイン名が次のように表示されます。

# nnmofficialfqdn.ovpl -d
       ドメイン:
       somedomain

-dオプションおよび-tオプションを指定してコマンドを実行した場合は，ドメイン名だけが表示されます。

# nnmofficialfqdn.ovpl -dt
      somedomain

AUTHOR

nnmofficialfqdn.ovpl was developed by Micro Focus.

FILES

nnmofficialfqdn.ovplは，次のディレクトリにあります。

Windows：%NNM_BIN%

Linux：$NNM_BIN

SEE ALSO

nnmsetofficialfqdn.ovpl.

付録G.43　nnmpseudoobject.ovpl

擬似オブジェクトの追加または削除，一覧表示に使用します。

SYNOPSIS

nnmpseudoobject.ovpl [-add [-s <"csv formatted line"> | -f <path to csv file>] | -delete [-s <"csv formatted line"> | -f <path to csv file>] | -list ] -t <type of pseudo object> [-u <username> -p <password>] [-jndiHost <hostName>] [-jndiPort <port>]

DESCRIPTION

nnmpseudoobject.ovplは，擬似オブジェクトの追加または削除，一覧表示に使用します。このコマンドは，多くの擬似オブジェクトを扱う場合や，外部サービスから連携されたデータを使用して擬似オブジェクトを扱う場合に便利です。このコマンドで，擬似オブジェクトの追加（-add），および表示（-list）が可能なロールは，System，管理者，Webサービスクライアント，レベル1オペレータ，またはレベル2オペレータに限定されます。また，擬似オブジェクトの削除（-delete）が可能なロールは，System，管理者，またはWebサービスクライアントに限定されます。

Parameters

nnmpseudoobject.ovplコマンドは，次のオプションをサポートします。

-?

使用法の説明を表示します。

-add

擬似オブジェクトを追加します。

-delete

擬似オブジェクトを削除します。

-list

擬似オブジェクトの一覧を表示します。

-t <type of pseudo object>

オブジェクトタイプを指定します。有効な値は"node"です。

-f <path to csv file>

追加または削除する擬似オブジェクトが含まれるCSVファイルのファイル名を含むパス（例: /tmp/csvfile.csv）を指定します。

-s <"csv formatted line">

擬似オブジェクト追加または削除のための単一のCSV形式の行を指定します。

Additional Parameters

-jndiHost <hostname>

サーバーのJNDIホスト。デフォルトはlocalhostです。

-jndiPort <port>

サーバーのJNDIポート。デフォルトは1099です。

-p <password>

コマンドを実行するためのNNMiのユーザーパスワードを指定します。nnm.propertiesファイルを使用しない限り，このコマンドにはNNMiのユーザーパスワードが必要です。詳細については，nnm.propertiesのリファレンスページを参照してください。

-u <username>

コマンドを実行するためのNNMiのユーザー名を指定します。nnm.propertiesファイルを使用しない限り，このコマンドにはNNMiのユーザー名が必要です。詳細については，nnm.propertiesのリファレンスページを参照してください。

addオプションおよびdeleteオプションに対するCSVファイルがサポートする文字コード

指定するCSVファイルの文字コードはNNMiサーバーのロケールに一致している必要があります。例えばWindows日本語環境の場合はShift-JIS(Windows-31J)を指定してください。

擬似ノードの追加または削除に使用するCSVファイルの構文

指定するCSVファイルで次の構文を使用しなければなりません。

空行は無視されます。

"#"で始まる行は無視されます。

CSV形式の構文は使用するオプションによって異なります。詳細については後述のセクションを参照してください。

addオプションに対するCSV形式の構文

必須：列1に擬似ノードの名前を指定する必要があります。

任意：列2から列6の値の指定は任意です。ただし，すべてのカラムが必要です。値を指定しない場合，空文字（""）を指定してください。

列1(A)：擬似ノード名

必須。追加したい擬似ノードの名前を指定します。

列2(B)：テナント名またはテナントUUID

任意。追加するノードを割り当てるテナントの名前もしくはUUIDを指定します。空文字（""）を指定した場合はデフォルトテナントに割り当てられます。同名のテナントが複数存在する場合はUUIDを指定してください。

列3(C)：システムの名前

任意。システムの名前の値を指定します。

列4(D)：システムの連絡先

任意。システムの連絡先の値を指定します。

列5(E)：システムのロケーション

任意。システムのロケーションの値を指定します。

列6(F)：システムの説明

任意。システムの説明の値を指定します。

CSVファイルの定義例

以下のように定義した場合，192.168.2.2，192.168.2.3，およびmyPseudoNodeが追加されます。

"192.168.2.2", "デフォルトテナント", "IT_Management_System", "IT Service Team", "Fort Collins", "Primary Server"
"192.168.2.3", "", "IT_Management_System", "IT Service Team", "Fort Collins", "Second Server"
"myPseudoNode", "1b96011e-8829-4e5d-8ab7-f93b7b10ac79", "", "", "", ""

deleteオプションに対するCSV形式の構文

必須：列1に擬似ノードの名前を指定する必要があります。

列1(A)：擬似ノード名

必須。削除したい擬似ノードの名前を指定します。

CSVファイルの定義例

以下のように定義した場合，192.168.2.2，192.168.2.3，およびmyPseudoNodeが削除されます。

192.168.2.2
192.168.2.3
myPseudoNode

EXAMPLES

CSV形式のファイルを使用して擬似ノードを追加：

nmpseudoobject.ovpl -add -f /tmp/pseudonodes_to_add.csv -t node

CSV形式で定義された行を使用して擬似ノードを追加：

nnmpseudoobject.ovpl -add -s "192.168.2.2, default tenant, IT_Management_System, IT Service Team, Fort Collins, Primary Server" -t node

CSV形式のファイルを使用して擬似ノードを削除：

nnmpseudoobject.ovpl -delete -f /tmp/pseudonodes_to_delete.csv -t node

CSV 形式で定義された行を使用して擬似ノードを削除：

nnmpseudoobject.ovpl -delete -s "myPseudoNode" -t node

擬似ノードの一覧を表示：

nnmpseudoobject.ovpl -list -t node

注意

オプション-sまたは-fで指定される擬似オブジェクトの情報は，RFC4180で定義されているCSV形式で指定してください。

CSV列の値に特殊文字（「,」または「"」）を含む場合，RFC定義に従い，値が「"」で囲われている必要があります。また，値に特殊文字「"」を含む場合は，「""」とエスケープしてください。

-sオプションを使用する場合，値全体をWindowsの場合は「¥"」，Linuxの場合は「"」で囲んでください。また，値に「"」が含まれる場合，環境に応じて適切にエスケープしてください。

使用できる特殊文字についてはNNMiヘルプ[疑似オブジェクトの管理]を参照してください。

AUTHOR

nnmpseudoobject.ovpl was developed by Open Text.

付録G.44　nnmresetembdb.ovpl

NNMiが組み込みデータベースと連携するように設定されている場合は，組み込みデータベースを空に（削除）してから再作成します。

SYNOPSIS

nnmresetembdb.ovpl [-?|-h|-help] [-silent] [-nostart]

DESCRIPTION

nnmresetembdb.ovpl は，NNMi 組み込みデータベースを空に（削除）してから再作成するときに使用します。このコマンドは，組み込みデータベースオプションでNNMiをインストールした場合にだけ有用です。このコマンドは，データベースが破損した場合にデータをすべて破棄してよいとき，または単にデータベースをインストール直後の初期状態に戻すときにだけ使用してください。

このコマンドを実行するときにNNMiが起動していると，このコマンドはまず（ovstop によって）NNMiを停止してから，（ovstartによって）データベースと連携するためのnmsdbmgrプロセスを開始します。-nostartオプションが指定された場合を除いて，初期化プロセスの完了時に（ovstartによって）NNMi を再起動します。

データベースの初期化が完了すると，組み込みデータベースにはテーブルもデータもなくなります。テーブルは，ovstartコマンドでNNMiを再起動したとき，またはnnmresetembdb.ovplコマンドによってNNMiが自動的に起動したときに再作成されます。

このコマンドを実行するには，Windowsシステムの管理者またはLinuxシステムのrootとしてログインする必要があります。

Parameters

nnmresetembdb.ovplコマンドは，次のパラメータをサポートします。

-silent

このオプションを使用すると，nnmresetembdb.ovplコマンドは実行結果の表示を抑止します。

-nostart

このオプションを使用すると，nnmresetembdb.ovplコマンドはデータベースの初期化後にNNMiを起動しません。

-?|-h|-help

コマンドの使用方法を表示します。

EXAMPLES

検出性能が悪い場合，データベースが破損した場合，またはデータベース（データベースに格納された設定項目を含む）をインストール直後の初期状態にしたい場合，このコマンドを使用してデータベースを初期化できます。

次のメッセージが表示されます。

# nnmresetembdb.ovpl -nostart

警告: このツールを実行すると、NNMが停止し、データベースが破棄および再作成され、
         NNMが再起動されます。現在、重要なアクティビティが発生していないことを
         確認してください。

NNMを停止してもよいですか (ovstop)? [n]
y
ありがとうございます!

警告: これにより、すべての設定データと検出済みデータが削除されます。
         バックアップを取得していない限り、リセットから回復できません。

データベースをリセットしてもよいですか? [n]
y

組み込みデータベースのリセットを試みています...

NNMを停止しています...

NNMは正常に停止しました。

データベースのリセットのnmsdbmgrプロセスを開始しています...

データベースリセットのnmsdbmgrプロセスを正常に開始しました。

組み込みデータベース nnm を正常にリセットしました。

メッセージングフォルダを正常に削除しました

#

AUTHOR

nnmresetembdb.ovpl was developed by Micro Focus.

FILES

nnmresetembdb.ovplは%NNM_BIN%（Windows）または$NNM_BIN（Linux）ディレクトリにあります。

SEE ALSO

nmsdbmgr, nnmnodedelete.ovpl, ovstart, ovstop, ovstatus.

付録G.45　nnmrestore.ovpl

このコマンドは，nnmbackup.ovplコマンドで作成されたバックアップをリストアします。

SYNOPSIS

nnmrestore.ovpl [-?|-h|-help] [-force] [-lic] [-partial] -source <directory>

DESCRIPTION

nnmrestore.ovplコマンドは，NNMiに対する主要リストアコマンドして機能します。このコマンドは，バックアップファイルで保存された状態にNNMiをリストアするため，nnmbackup.ovplコマンドで実行された以前のNNMiバックアップを使用します。リストアの範囲は，バックアップの内容と，指定されたコマンドライン引数により決まります。バックアップ内に存在しているデータのみがリストアの対象です。

nnmbackup.ovplコマンドを使用してNNMiのバックアップを作成し，次にnnmrestore.ovplコマンドを使用してデータベースレコードを別のNNMi管理サーバーに配置する場合は，どちらのNNMi管理サーバーも同種のオペレーティングシステムと同一バージョンのNNMiがインストールされ，同一のパッチレベルが適用されている必要があります。バックアップデータをあるNNMi管理サーバーから別のNNMi管理サーバーに配置するということは，どちらのサーバーも同一のデータベースUUIDを持つことを意味します。グローバルネットワーク管理機能を使用する場合は，2台目のNNMi管理サーバーにNNMiをリストアした場合，元のNNMi管理サーバーからNNMiをアンインストールしてください。

このコマンドは，次の状況を検出します。

対象システムでバックアップが作成されたかどうか。-licを指定すると，同一システムでバックアップが作成された場合のみ，ライセンス情報をリストアできます。

ソースディレクトリには，指定のリストア動作に要求されるファイルのすべてが単一のtarファイルとして指定されています。ソースがtarファイルの場合，このtarファイルは現在の作業ディレクトリで一時フォルダとして展開されます。この一時フォルダは，リストア完了後に削除されます。

リストア動作を完了するには，必ずNNMiを停止する必要があります。-forceオプションを指定すると，このコマンドはNNMiを停止します。当初のバックアップがオンラインバックアップであったとソースフォルダに存在するファイルに表示されている場合，リストア動作はnmsdbmgrプロセスを起動し，組み込みデータベースが利用できるかどうかを確認します。つまり，オンラインバックアップからリストアするには，-forceオプションの使用が絶対条件であることを意味しています。

nnmrestore.ovplコマンドを実行するには，Windowsシステムの管理者またはLinuxシステムのrootとしてログオンする必要があります。

Parameters

nnmrestore.ovplコマンドは，次のオプションをサポートします。

-force

このオプションを指定すると，このコマンドは，リストア手順が実行される前にNNMiを停止します。また，リストアが準拠しているバックアップのタイプをリストアする必要がある場合，このコマンドはnmsdbmgrプロセスを起動します。このオプションは，オンラインバックアップからリストアする場合に必要です。

-lic

このオプションを指定すると，このコマンドによりライセンス情報がリストアされます。同じシステムでバックアップが作成されたことが確認された場合にのみ，このコマンドでライセンス情報がリストアされるということに注意が必要です。

-partial

このオプションを指定しないと，データベースおよび対応するSSL証明書がリストアされます。システムからシステムへのリストアの場合，nnm.keystoreとnnm.truststoreが対象のシステムのものとマージされます。マージはターゲットシステムに存在しない，バックアップに格納されたすべての証明書エイリアスを統合します。例外として，両方のストアにFQDNの自己証明書が存在する場合，ターゲットシステムのキーエイリアスは削除され，バックアップのものと入れ替えられます。証明書がマージまたはリストアされる前に，バックアップが作成され，同じディレクトリに格納されます。名前は *.backupになります。

-partialオプションを指定すると，データベースおよび対応するSSL証明書がリストアされません。これは，設定ファイルのみをリストアする場合に便利です。

-source <directory>

-sourceオプションの引数には，nnmbackup.ovplコマンドで取得した，バックアップデータのディレクトリまたはtarファイルを指定してください。ユーザーが指定するソースがtarファイルの場合，このtarファイルは現在の作業ディレクトリで一時フォルダとして展開されます。この一時フォルダは，リストア完了時に削除されます。

-?|-h|-help

コマンドの使用方法を表示します。

EXAMPLES

以前のバックアップをリストアするには：

#./nnmrestore.ovpl -source /tmp/bak/config

-force オプションを指定してリストアするには：

#./nnmrestore.ovpl -force -source /tmp/bak/all

-partialオプションを使用して，データベース，SSL証明書，およびライセンスを除くすべてのバックアップデータをリストアするには：

#./nnmrestore.ovpl -partial -source /tmp/bak/all

-licオプションを使用して，ローカルシステムのライセンス情報を含め，すべてをリストアするには：

#./nnmrestore.ovpl -lic -source /tmp/bak/all

AUTHOR

nnmrestore.ovpl was developed by Micro Focus.

SEE ALSO

nnmbackup.ovpl.

付録G.46　nnmrestoreembdb.ovpl

このコマンドは，nnmbackupembdb.ovplコマンドで作成されたバックアップをリストアします。

SYNOPSIS

nnmrestoreembdb.ovpl [-?|-h|-help] [-force] -source <backup file>

DESCRIPTION

nnmrestoreembdb.ovplコマンドを使用すると，NNMi組み込みデータベースの完全なバックアップを復元することができます。復元を行うときに必要なバックアップファイルは，nnmbackupembdb.ovplコマンドを使用して作成されます。

nnmbackupembdb.ovplコマンドを使用してNNMi組み込みデータベースのバックアップを作成し，次にnnmrestoreembdb.ovplコマンドを使用して組み込みデータベースレコードを別のNNMi管理サーバーに配置する場合は，どちらのNNMi管理サーバーも同種のオペレーティングシステムと同一バージョンのNNMiがインストールされ，同一のパッチレベルが適用されている必要があります。

nnmrestoreembdb.ovplコマンドを実行する前に，nnmresetembdb.ovplコマンドを実行して組み込みデータベースを空にしておくことを推奨します。データベースを空にしておかなかった場合は，復元中にこのコマンドが自動的に実行されますが，もしもこのコマンドが失敗すると復元も失敗します。

このコマンドは，-forceオプション指定時を除いて，NNMiの起動中に実行しないでください。このコマンドを実行するときに起動してよい（していなければならない）のはnmsdbmgrプロセスだけです。

このコマンドを実行するには，Windowsシステムの管理者またはLinuxシステムのrootとしてログインする必要があります。

Parameters

-source <backup file>

バックアップの復元元とするファイル名。nnmbackupembdb.ovplコマンドで作成したファイルを指定します。

-force

このオプションを指定した場合，起動中のNNMiを停止してnmsdbmgrプロセスを開始します。

-?|-h|-help

コマンドの使用方法を表示します。

EXAMPLES

このスクリプトは，バックアップからの回復が必要な場合に，データベースの完全な回復を実行するときに使用できます。

次のメッセージが表示されます。

# nnmrestoreembdb.ovpl -source /backups/nnm-bak-20070929064743.pgd

警告: NNMの実行中にこのコマンドを実行すると、
         アクティブセッションにエラーが発生することがあります。このコマンド (ovstart nmsdbmgr) の実行時に、
         nmsdbmgrプロセスのみが実行していることを確認してください。
データベースの全復元の実行を今すぐ開始してもよいですか? [n]
y
組み込みデータベースの全復元を実行しています...
データベース nnm の復元と統計情報の分析が正常に完了しました。

NNM組み込みデータベースは、/backups/nnm-bak-20070929064743.pgd から正常に復元されました。
#

AUTHOR

nnmrestoreembdb.ovpl was developed by Micro Focus.

FILES

nnmrestoreembdb.ovplは，次のディレクトリにあります。

Windows：%NNM_BIN%

Linux：$NNM_BIN

SEE ALSO

ovstart, ovstop, ovstatus, nmsdbmgr, nnmbackupembdb.ovpl.

付録G.47　nnmsamlconfig.ovpl

nnmsamlconfig.ovplは，Network Node Manager i（NNMi）でサービスプロバイダー（SP）メタデータとSecurity Assertion Markup Language（SAML）認証設定を生成します。

SYNOPSIS

nnmsamlconfig.ovpl -spEntityID <spEntityID> -nameIDFormat <nameIDFormat> -idpMetadata <full path to idp metadata file> -aliasForSigning <alias> [-aliasForEncryption <aliasForEncryption> | -useSameAlias]

nnmsamlconfig.ovpl -help

DESCRIPTION

nnmsamlconfig.ovplコマンドは，NNMiでSPメタデータ（nnm_spmetadata.xml）とSAML設定を生成します。

コマンドが正常に実行されると，次のディレクトリにNNMiサービスプロバイダーのメタデータファイルが作成されます。

Windowsの場合：%NnmDataDir%¥nmsas¥NNM¥conf¥nnm_spmetadata.xml

Linuxの場合：$NnmDataDir/nmsas/NNM/conf/nnm_spmetadata.xml

メモ

nnmsamlconfig.ovplコマンドを実行すると，現在のSAML認証設定が存在する場合は，常にその設定が上書きされます。

nnmsamlconfig.ovpl -helpオプションはヘルプを表示します。コマンドの各種オプションと使用法が表示されます。

Parameters

nnmsamlconfig.ovplコマンドは，次のオプションをサポートします。

-spEntityID <spEntityID>

IDプロバイダー（IdP）でNNMiをSAMLサービスプロバイダー（SP）として識別するための固有名です。このサーバーの完全修飾ドメイン名（FQDN）またはURLを指定します。

-nameIDFormat <nameIDFormat>

ユーザー名（Subject NameIDフィールド）のオプションのSAML NameID形式を指定します。指定する場合は，サポートされている形式（サポートされているNameID形式を参照）およびIdPでの選択と一致する必要があります。

デフォルト値は，urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifiedです。

サポートされているNameID形式は次のとおりです。

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

urn:oasis:names:tc:SAML:2.0:nameid-format:transient

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName

urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName

urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos

urn:oasis:names:tc:SAML:2.0:nameid-format:entity

urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted

-idpMetadata <full path to idp metadata file>

IdPによって提供されるメタデータファイルの絶対パスを指定します。メタデータファイルにはIdPとの通信のためにNNMiによって使用される設定と証明書が含まれています。

-aliasForSigning <aliasForSigning>

NNMiが送信するSAML要求の署名に使用される証明書のエイリアスです。

-aliasForEncryption <aliasForEncryption>

NNMiへの応答を暗号化するためにIdPが使用する証明書のエイリアスです。

-useSameAlias

このオプションは，署名と暗号化の両方に同じ証明書を使用する場合に指定します。

-help

コマンドの使用法を表示します。

Additional Parameters

-jndiHost <hostname>

jndiサーバーのホスト名です。デフォルトの値は"localhost"です。

-jndiPort <port>

jndiサーバーのポート番号です。デフォルト値は1099です。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，この引数の指定が必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，この引数の指定が必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

LinuxおよびWindowsの場合：

nnmsamlconfig.ovpl -spEntityID <mfserver.net> -nameIDFormat urn:oasis:names:tc:SAML:2.0:nameid-format:persistent -idpMetadata <metadata_File_location> -aliasForSigning <mfserver.net.selfsigned> -aliasForEncryption <mfserver.net.selfsigned>

付録G.48　nnmscheduledoutage.ovpl

ノードの停止を計画するために使用するコマンドラインツールです。

SYNOPSIS

nnmscheduledoutage.ovpl -u <user> -p <password> [-h | -help]

-create (-node <NODE>| -nodeGroup <NODEGROUP>| -file <FILE) <TIME-SPEC> -name <NAME> [ -description <DESCRIPTION>] [-retroactive]

-delete (-name <NAME> [-node <NODE>]) | -uuid <UUID>

-list [-v] [-node <NODE> | -uuid <UUID> | -name <NAME> ] [-format <FORMAT>]

-dump {-node <NODE> | <TIME-SPEC>} [-retroactive] [-format <FORMAT>]

-update (-name <NAME> [-node <NODE>] | -uuid <UUID>) (<TIME-SPEC> | -addNode <NODE> | -removeNode <NODE>)

[-newName <NEWNAME>] [-description <DESCRIPTION>] [-enable | -disable] <TIME-SPEC> ::= -start <TIME> (-duration <DURATION> | -end <TIME>) [-tz <TIMEZONE>]

DESCRIPTION

nnmscheduledoutage.ovplコマンドは，ノードの計画停止を作成するために使用するコマンドラインツールです。計画された停止の期間中，停止中のノードは管理モードが「サービス停止中」に変更され，停止の期間が終了すると「管理対象」に戻されます。テキストファイルを使用して，複数のノードをノードグルーブ単位で個別の停止グループにまとめたり，既存の停止グループに追加したりできます。計画停止は，停止名，停止に含まれるノード，または計画停止のUUIDの単位で削除できます。計画停止は，任意の参加ノード別に画面に詳細を一覧表示したり，CSVなどの各種形式でフォーマットしたりできます。計画停止を更新して，ノードを追加または削除したり，停止の時間指定を変更したりできます。

Parameters

nnmscheduledoutage.ovplコマンドは，次のオプションをサポートします。

-h | -help

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細は nnm.properties リファレンスページを参照してください。

-addNode <NODE>

指定した計画停止にノードを追加するために，計画停止を更新するときに使用します。

-create

指定したシステムの計画停止を新規作成します。

-delete

指定した計画停止を削除します。

-description <DESCRIPTION>

計画停止についての追加の説明情報を提供します。

-disable

計画停止を無効化します。

-duration <DURATION>

計画停止の期間を分単位で設定します。これは，「分」を示す"m"（"m" を省略した場合はデフォルトで「分」を示す），「時間」を示す "h"，または「日」を示す"d"を，数字の後につけて指定できます。例えば，"3h"は3時間の停止です。

-enable

計画停止を有効化します。

-end <TIME>

計画停止の終了日時です。構文については，下記の「FORMATTING RULES」項を参照してください。終了日時が現在日時より前である場合，"-retroactive"フラグが必要です。

-file <FILE>

計画停止に関連付けるノードのリストを含むテキストファイルの名前です。ファイルには，空白行や"#"文字で始まるコメントを含めることができ，残りの行はノードと見なされます。ノードは，ホスト名，IPアドレス，またはノードのUUIDのどれかを指定することができます。ホスト名またはIPアドレスが一意でない場合は，停止が適用されるノードを決定することができないので，エラーが発生します。

-format <FORMAT>

一覧表示の出力形式です。'text', 'list', 'csv' および 'xml'が利用できます。

-nodeGroup <NODEGROUP>

ノードグループ名を指定します。

-list

指定したシステムの計画停止の情報を一覧表示します。システムを指定しない場合は，すべての計画停止を一覧表示します。詳細表示フラグが立っている場合は，影響を受けるノードなど，詳細な情報が表示されます。UUIDによる一覧表示は，常に指定した計画停止の詳細な情報を提供します。

-dump

開始日時と終了日時を持ったノード停止の履歴を一覧表示します。停止の履歴には，ノードが管理対象状態から非管理対象またはサービス停止中に変更されてから（開始日時），管理対象状態に戻った場合には（終了日時），いつでも記録されます。

When the -retroactiveオプションを指定した場合は，さかのぼって作成された停止のみが出力されます。

ノードパラメータを付与した場合は，指定されたノードの停止をダンプします。

時間指定を付与した場合は，その時間枠内に完了した停止をダンプします。時間指定には開始日時を含める必要があり，さらに期間や終了日時を含めることもできます。期間や終了日時がない場合は，実質的に，"開始日時以降のすべての停止をダンプする" ことを意味します。 開始日時は時間枠に含まれますが，終了日時は含まれません。

ノードか開始日時を指定する必要があることに注意してください。 両方を指定した場合は，指定したノードの時間枠内の停止を一覧表示します。

-name <NAME>

計画停止の名前です。名前は当該の停止に一意に準じる名前であり，その名前で停止を参照できます。しかし，停止の名前は必ずしも一意である必要はなく，同じ名前を持つ2つの停止がある場合は，対象の停止に含まれるノードを一覧表示して，さらに指定を絞り込むことができます。

-newName <NEWNAME>

計画停止の新しい名前です。

-node <NODE>

ノード名，ホスト名，管理アドレス，またはUUIDを指定します。

-retroactive

さかのぼって，過去に計画停止を作成します。これは，事前に計画されずに発生した，いくつかの過去の停止のために，データベース内の停止エントリを作成するために使用されます。

-removeNode <NODE>

指定した計画停止からノードを削除します。

-start <TIME>

計画停止の開始日時です（「FORMATTING RULES」項を参照してください）。

-tz <TIMEZONE>

タイムゾーンの指定です（「FORMATTING RULES」項を参照してください）。

-update

指定した計画停止を更新します。停止のタイミングも，含まれるノードと同様に変更できます。

-uuid

計画停止のUUIDです。

FORMATTING RULES

開始日時と終了日時は，YYYY-MM-DDTHH:MM として指定します。例えば，2013-05-08T14:56は2013年5月8日午後2時56分です。開始日時と終了日時はまた，すぐに計画停止を開始するため，または，現在進行中の計画停止を終了するため，"now"として指定することができます。

上述したように，期間はそれぞれ，数字（分），または"m"，"h"，"d"に続く数字を指定することで，それぞれ分，時間，日となります。大文字小文字は無視されます。そのため，"1d"と"1D"は同じです。

タイムゾーンパラメータは，任意の有効なJavaタイムゾーンパラメータを指定できます。例えば，"US/Mountain"や"Australia/Perth"です。タイムゾーンのパラメータも"target"（大文字/小文字は区別しない）にできます。これは，計画停止の時間を対象ノードのタイムゾーンで指定することを意味します。"target"を指定した場合は，すべてのノードが同じタイムゾーンに存在する必要があります。さらに，"target"を指定する場合は，そのノードがタイムゾーン属性を持っている必要があります。タイムゾーンには，"server"を指定することもできます。これは，ユーザーのシェルプロセスのタイムゾーンと異なるNNMiサーバーのタイムゾーンを使用する場合があることを意味します。タイムゾーンが指定されていない場合，ユーザーのシェルプロセスのタイムゾーンが使用されます。

注：計画停止を作成するときは，開始日時と，終了日時または期間のどちらか（両方ではない）を指定しなければなりません。

注：計画停止の最小継続時間は15分です。15分より短い停止は拒否されます。また，開始日時から15分経過していない場合に，停止を"今すぐ(now)"終了させようとした場合も拒否されます。

EXAMPLES

ノードのタイムゾーンを使用して，1日持続する，ノードの計画停止を作成します（2013年5月21日を将来の日付と仮定します）。

nnmscheduledoutage.ovpl -create -node cisco6509 -start 2013-05-21T09:00 -tz TARGET -duration 1d -name "Replace power supply"

同上ですが，遡及停止です（2013年5月21日を，前の例の未来に代わり，過去の日付と仮定します）。

nnmscheduledoutage.ovpl -create -node cisco6509 -retroactive -start 2013-05-21T09:00 -tz TARGET -duration 1d -name "Replace power supply" -retroactive

ローカルの開始日時および終了日時を使用して，ノードの計画停止を作成します。

nnmscheduledoutage.ovpl -create -node cisco6509 -start 2013-05-21T10:00 -end 2013-05-21T14:00 -name "Replace power supply"

指定されたタイムゾーンで計画停止を作成します。

nnmscheduledoutage.ovpl -create -node cisco6509 -start 2013-05-21T09:00 -end 2013-05-21T10:00 -tz Australia/Perth -name "Replace power supply"

"nodes.txt"ファイルに記載されているノードのリストの停止を計画します。

nnmscheduledoutage.ovpl -create -file nodes.txt -start 2013-05-21T09:00 -tz TARGET -duration 1d -name "Weekly Maintenance"

指定されたタイムゾーンで，経過時間で計画停止を作成します。ノードグループ名がこの例で使用されています。

nnmscheduledoutage.ovpl -create -nodeGroup Routers -start 2013-05-25T09:00 -duration 2h -tz Australia/Perth -name "Weekly Router Maintenance"

指定されたノードの計画停止を一覧表示します。計画停止のUUID，名前，開始時間，終了時間および説明がテーブルに表示されます。

nnmscheduledoutage.ovpl -list -node cisco6509

CSV形式で計画停止を一覧表示します。

nnmscheduledoutage.ovpl -list -node cisco6509 -format csv

2013年7月1日以降のすべての停止について，CSV形式でノードの停止履歴をダンプします。

nnmscheduledoutage.ovpl -dump -node cisco6509 -format csv -start 2013-07-01T00:00

2013年12月のすべての遡及停止をCSV形式でダンプします。

nnmscheduledoutage.ovpl -dump -retroactive -start 2013-12-01T00:00 -end 2014-01-01T00:00 -format csv

名前から計画停止を削除します。複数の計画停止が同じ名前を持つ場合，それらはすべて削除されます。

nnmscheduledoutage.ovpl -delete -name "Weekly Router Maintenance"

指定した計画停止だけが削除されるように，一意な計画停止のUUIDによって停止を削除します。

nnmscheduledoutage.ovpl -delete -uuid 204846c0-a35b-4a92-9726-4ce0a8be596d

新たな停止終了日時により，指定した名前の計画停止の停止期間を拡張します。

nnmscheduledoutage.ovpl -update -name "Weekly Router Maintenance" -end 2013-05-21T12:00

計画停止のUUIDと新しい期間（計画された開始日時からの相対）により，計画停止の停止期間を拡張します。

nnmscheduledoutage.ovpl -update -uuid 204846c0-a35b-4a92-9726-4ce0a8be596d -duration 2h

ノードと名前と新しい開始日時（ただし，同じ終了日時を維持）により，計画された停止を遅らせます。

nnmscheduledoutage.ovpl -update -node cisco6509 -name "Replace power supply" -start 2013-05-21T08:00

AUTHOR

nnmscheduledoutage.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmscheduledoutage.ovpl

Linux：$NNM_BIN/nnmscheduledoutage.ovpl

付録G.49　nnmsecurity.ovpl

NNMiセキュリティ管理

SYNOPSIS

nnmsecurity.ovpl -help

nnmsecurity.ovpl -assignNodeToSecurityGroup ((-node <name or hostname or management address or uuid> -securityGroup <name or uuid>) | -file <name>) | -assignNodeToTenant ((-node <name or hostname or management address or uuid> -tenant <name or uuid>) | -file <name>) | -assignSecurityGroupToTenant (-tenant <name or uuid> -securityGroup <name or uuid>) | -assignUserGroupToSecurityGroup ((-userGroup <name> -securityGroup <name or uuid> -role <role>) | -file <name>) | -assignUserToGroup ((-user <name> -userGroup <name>) | -file <name>) [-u <username> -p <password>]

nnmsecurity.ovpl -createSecurityGroup ((<name> [-securityGroupUuid <uuid>] [-description <description>]) | -file <name>) | -createTenant (<name> [-tenantUuid <uuid>] [-securityGroupUuid <uuid>] [-description <description>]) | -createUserAccount ((<username> -role <role> [-password <password>] [-directoryServiceAccount <true|false>]) | -file <name>) | -createUserGroup ((<name> [-displayName <user friendly group name>] [-description <description>] [-directoryServiceName <dn>]) | -file <name>) [-u <username> -p <password>]

nnmsecurity.ovpl -deleteSecurityGroup (<groupName or uuid> | -file <name>) | -deleteUserAccount (<name> | -file <name>) | -deleteUserGroup <name> [-u <username> -p <password>]

nnmsecurity.ovpl -displayConfigReport [<report>[, <report>]] [-u <username> -p <password>]

nnmsecurity.ovpl -listNode <nodeName> | -listNodesInSecurityGroup <groupName or uuid> | -listSecurityGroupForTenant <tenantName or uuid> | -listSecurityGroups | -listTenants | -listUserGroupMembers <groupName> | -listUserGroups | -listUserGroupsForSecurityGroup <groupName or uuid> [-u <username> -p <password>

nnmsecurity.ovpl -removeUserFromGroup ((-user <name> -userGroup <name>) | -file <name>) | -deleteUserGroup (<name> | -file <name>) | -removeUserGroupFromSecurityGroup ((-userGroup <groupName> -securityGroup <groupName or uuid> [-role <role>]) | -file <file>) | -updateUserGroup ((<name> [-displayName <user friendly group name>] [-description <description>] [-directoryServiceName <dn>]) | -file <name>) [-u <username> -p <password>]

DESCRIPTION

nnmsecurity.ovplは，NNMiセキュリティ構成を管理するために使用します。これにより，ユーザーアカウント，ユーザーグループ，セキュリティグループなどのセキュリティオブジェクトを作成，更新，削除するため，およびこれらのオブジェクトの関係を構成するためのコマンドが提供されます。

Parameters

nnmsecurity.ovplコマンドは，次のパラメータをサポートします。

-help

コマンドの使用方法を表示します。

-assignNodeToSecurityGroup (-node <name or hostname or management address or uuid> -securityGroup <name or uuid>) | -file <name>

コマンドライン引数または入力ファイルを使用して，セキュリティグループにノードを割り当てます。

-node

名前，ホスト名，管理アドレス，またはUUIDによってノードを識別します。

-securityGroup

名前またはUUIDによってセキュリティグループを識別します。

-file

セキュリティグループに割り当てる，securitygroup，nodeという形式のノードのリストが含まれるCSV形式のファイルへのパスです。

-assignNodeToTenant (-node <name or hostname or management address or uuid> -tenant <name or uuid>) | -file <name>

コマンドライン引数または入力ファイルを使用して，テナントにノードを割り当てます。ノードからテナントへの割り当ては，両方のオブジェクトを直接管理するNNMi管理サーバーで行う必要があります。グローバルなノードからテナントへの割り当てはサポートされていません。

-node

名前，ホスト名，管理アドレス，またはUUIDによってノードを識別します。

-tenant

名前またはUUIDによってテナントを識別します。

-file

テナントに割り当てる，node，tenantという形式のノードのリストが含まれるCSV形式のファイルへのパスです。

-assignSecurityGroupToTenant -tenant <name or uuid> -securityGroup <name or uuid>

テナントのデフォルトのセキュリティグループを変更します。新しいノードがテナントに対して設定された場合，どのセキュリティグループを使用するかを指定するため，テナントのデフォルトのセキュリティグループを使用します。この値を変更しても，既存のノードは影響を受けません。

-tenant

修正するテナントの名前またはUUIDです。

-securityGroup

テナントのデフォルトとして設定するセキュリティグループの名前またはUUIDです。

-assignUserGroupToSecurityGroup (-userGroup <name> -securityGroup <name or uuid> -role <role>) | -file <name>

ユーザーグループをセキュリティグループに割り当てます。セキュリティグループ内のノードへのアクセスをグループ内のユーザーに付与するために，ユーザーグループはセキュリティグループに割り当てられます。各割り当ては，ノードのユーザーがどのアクションを利用できるかを制御する割り当ての一部としてロールを含みます。

-userGroup

名前によって割り当てるユーザーグループを識別します。

-securityGroup

ユーザーグループを受け入れるために，名前またはUUIDによってセキュリティグループを識別します。

-role

キーによって割り当てに使用するロールを識別します。利用できるロールは，admin，level2，level1，guest です。

-file

userGroup，securityGroup，roleという形式の割り当てのリストを含むCSV形式のファイルへのパスです。

-assignUserToGroup (-user <name> -userGroup <name>) | -file <name>

ユーザーをユーザーグループに割り当てます。ユーザーは，オブジェクトへのアクセスができるグループに割り当てられます。ユーザーは，複数のグループに割り当てられ，そのグループのすべてからすべてのオブジェクトにアクセスできます。また，admin，client，level2，level1，およびguestのデフォルトグループは，それらに割り当てられたユーザーに NNMi 自体で同じ名前の一致するロールを与えます。

-user

名前によって割り当てるユーザーを識別します。

-userGroup

名前によって割り当てるユーザーグループを識別します。

-file

user，userGroupという形式の割り当てのリストを含むCSV形式のファイルへのパスです。

-createSecurityGroup (<name> [-securityGroupUuid <uuid>] [-description <description>]) | -file <name>

新しいセキュリティグループを作成します。セキュリティグループは，セキュリティ構成を簡単にするために類似するトポロジオブジェクトをグループ化します。各セキュリティグループは，名前，UUID，および説明で構成されています。

-securityGroupUuid

(オプション) 新しいセキュリティグループのUUIDです。このパラメータを指定しない場合，NNMiが値を生成します。

-description

(オプション) 新しいセキュリティグループの説明です。

-file

name，uuid，descriptionという形式のセキュリティグループのリストを含むCSV形式のファイルへのパスです。

-createTenant <name> [-tenantUuid <uuid>] [-securityGroupUuid <uuid>] [-description <description>]

同じ名前の一致するセキュリティグループと共に新しいテナントを作成します。

-tenantUuid

(オプション) 新しいテナントのUUIDです。このパラメータを指定しない場合，NNMiが値を生成します。

-securityGroupUuid

(オプション) 新しいセキュリティグループのUUIDです。このパラメータを指定しない場合，NNMiが値を生成します。

-description

(オプション) 新しいテナントの説明です。

-createUserAccount (<username> -role <role> [-password <password>] [-directoryServiceAccount <true|false>]) | -file <name>

新しいユーザーアカウントを作成します。

-role

内部アカウントでは，ロールが指定されている必要があります。NNMiは，一致するユーザーグループに，新しいユーザーを自動的に割り当てます。ディレクトリサービスがロールを提供することがあるため，外部アカウントはロールを必要としません。

-password

新しいユーザーのパスワードです。内部アカウントにだけ使用されます。

-directoryServiceAccount

外部ディレクトリサービスが，このユーザーアカウントを管理するかどうかを指定します。NNMiデータベース内部に格納されているアカウントにはfalseを使用します。ディレクトリサービスに格納されている外部アカウントにはtrueを使用します。デフォルト値はfalseです。

-file

username，password，role，directoryServiceAccountという形式のユーザーアカウントのリストを含むCSV形式のファイルへのパスです。

-createUserGroup (<name> [-displayName <user friendly group name>] [-description <description>] [-directoryServiceName <dn>]) | -file <name>

新しいユーザーグループを作成します。

-displayName

(オプション) ユーザーグループの表示名です。

-description

(オプション) 新しいグループの説明です。

-directoryServiceName

(オプション) ディレクトリサービスユーザーのためのオプションです。ディレクトリサービスで区別された名前をユーザーグループと組み合わせるために，このオプションを使用します。

-file

name，displayName，description，directoryServiceNameという形式のユーザーグループのリストを含む CSV 形式のファイルへのパスです。

-deleteSecurityGroup <groupName or uuid> | -file <name>

名前またはUUIDによってセキュリティグループを削除します。セキュリティグループは，割り当てられたノードまたはテナントを持つことはできません。

-file

name，uuid，descriptionという形式のセキュリティグループのリストを含むCSV形式のファイルへのパスです。この形式はcreateSecurityGroupのものと同じですが，名前だけ（または存在する場合はUUID）が使用されます。

-deleteUserAccount <name> | -file <name>

名前によってユーザーアカウントを削除します。

-file

username，password，role，directoryServiceAccountという形式のユーザーアカウントのリストを含むCSV形式のファイルへのパスです。この形式はcreateUserAccountのものと同じですが，削除するアカウントを一致させるために，ユーザー名だけを使用します。

-deleteUserGroup <name>

名前によってユーザーグループを削除します。

-displayConfigReport [<report>[, <report>]]

セキュリティ構成レポートを表示します。利用できるレポートは，emptySecurityGroups，emptyUserGroups，securityGroupsWithSameName，usersWithoutGroups，tenantsWithSameName，usersWithoutRolesです。

レポートを指定しない場合，利用可能なすべてのレポートが実行されます。

-listNode <node name>

セキュリティグループのUUIDおよび指定したノードに関連するテナントを表示します。ノードは，名前またはUUIDとして指定することができます。出力には，ノードのUUIDおよびホスト名，セキュリティグループのUUIDおよび名前，テナントのUUIDおよび名前が別の行に表示されます。

-listNodesInSecurityGroup <groupName or uuid>

セキュリティグループ名またはUUIDによってセキュリティグループ内のノードを一覧表示します。

-listSecurityGroupForTenant <tenantName or uuid>

指定したテナント名またはUUIDに対して構成された，初期検出セキュリティグループを表示します。

-listSecurityGroups

すべての構成されたセキュリティグループの名前を一覧表示します。

-listTenants

すべての構成されたテナントの名前を一覧表示します。

-listUserGroupMembers <groupName>

指定したユーザーグループのユーザーを一覧表示します。

-listUserGroups

すべての構成されたユーザーグループを一覧表示します。

-listUserGroupsForSecurityGroup <groupName or uuid>

指定したセキュリティグループ名または UUID に関連するユーザーグループを一覧表示します。

-removeUserFromGroup (-user <name> -userGroup <name>) | -file <filename>

ユーザーアカウントとユーザーグループ間のマッピングを削除します。

-user

修正するユーザーアカウントのユーザー名です。

-userGroup

指定したユーザーアカウントからマッピングを解除するユーザーグループの名前です。

-file

user，userGroupという形式のユーザーグループマッピングへのユーザーのリストを含むCSV形式のファイルへのパスです。

-deleteUserGroup <name> | -file <name>

名前によってユーザーグループを削除します。ユーザーグループとユーザーアカウントの間のマッピングおよびセキュリティグループも削除されます。

-file

name，displayName，description，directoryServiceNameという形式のユーザーグループマッピングへのユーザーのリストを含むCSV形式のファイルへのパスです。この形式はcreateUserGroupのものと同じですが，削除するグループに一致させるために，名前だけを使用します。

-removeUserGroupFromSecurityGroup (-userGroup <groupName> -securityGroup <groupName or uuid> [-role <role>]) | -file <name>

ユーザーグループとセキュリティグループの間のマッピングを削除します。

-userGroup

ユーザーグループの名前です。

-securityGroup

セキュリティグループの名前または UUID です。

-role

オプションのロールです。ロールが指定されていない場合，すべてのロールのマッピングが削除されます。

-file

userGroup，securityGroup，roleという形式のユーザーグループマッピングへのユーザーのリストを含むCSV形式のファイルへのパスです。

-updateUserGroup <name> ([-displayName <user friendly group name>] [-description <description>] [-directoryServiceName <dn>]) | -file <name>

ユーザーグループを更新します。名前を除くすべてのユーザーグループ属性を更新できます。

-displayName

(オプション) ユーザーグループの表示名です。

-description

(オプション) ユーザーグループの説明です。

-directoryServiceName

(オプション) ディレクトリサービスユーザーのためのオプションです。ディレクトリサービスで区別された名前をユーザーグループと組み合わせるために，このオプションを使用します。

-file

name，displayName，description，directoryServiceNameという形式のユーザーグループのリストを含むCSV形式のファイルへのパスです。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

nnmsecurity.ovpl -createTenant myTenant

"myTenant"という名前のテナントを作成します。

nnmsecurity.ovpl -listTenants

すべての構成されたテナントを一覧表示します。

nnmsecurity.ovpl -createTenant "Tenant with a space"

nnmsecurity.ovpl -createTenant ¥!Tenant

使用するシェルに基づいて，名前にスペースが含まれるテナントを作成するために，テナント名の前後に引用符を使用したり，名前内に特殊文字があるテナントを作成するために，エスケープ文字を使用したりすることができます。

nnmsecurity.ovpl -createSecurityGroup mySecurityGroup

セキュリティグループ"mySecurityGroup"を作成します。

nnmsecurity.ovpl -createSecurityGroup "Group with a space"

nnmsecurity.ovpl -createSecurityGroup ¥!MyGroup

使用するシェルに基づいて，名前にスペースが含まれるセキュリティグループを作成するために，セキュリティグループ名の前後に引用符を使用したり，名前内に特殊文字があるセキュリティグループを作成するために，エスケープ文字を使用したりすることができます。

nnmsecurity.ovpl -listSecurityGroups

すべての構成されたセキュリティグループを一覧表示します。

nnmsecurity.ovpl -listNode myNode

関連するセキュリティグループおよび提供されたノードのテナントを一覧表示します。

DIAGNOSTICS

nnmsecurity.ovplコマンドは，次の終了コードを返します。

0

処理は成功しました。

1

エラーが発生しました。詳細はエラーメッセージを参照してください。

AUTHOR

nnmsecurity.ovpl was developed by Micro Focus.

FILES

次の環境変数は，使用するシェルおよびプラットフォームの要件に従って設定される共通パスです。

Windows：%NNM_BIN%¥nnmsecurity.ovpl

Linux：$NNM_BIN/nnmsecurity.ovpl

SEE ALSO

nnm.properties.

付録G.50　nnmseeddelete.ovpl

NNMiトポロジデータベースからシードを削除します。

SYNOPSIS

nnmseeddelete.ovpl -help | -f <seedFile> | -seed <seed> | -all [-u <username> -p <password>]

DESCRIPTION

nnmseeddelete.ovplコマンドは，システムからシードを削除します。

Parameters

nnmseeddelete.ovplコマンドは，次のオプションをサポートします。

-help

コマンドの使用方法を表示します。

-seed <seed>

削除するシードを指定します。シードはホスト名またはIPアドレスで，シードリストに記載されている内容に一致する必要があります。

-f <seedFile>

シードの読み込み元であるテキストファイルを指定します。

-all

すべてのシードを削除します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

nnmseeddelete.ovpl -u username -p password -seed 10.1.2.3

シード10.1.2.3が削除されます。（NNMi 管理者のユーザー名とパスワードを指定する必要があります。）

nnmseeddelete.ovpl -f /tmp/seeds_to_delete.txt

ファイルに記載されている各シードが削除されます。

Diagnostics

nnmseeddelete.ovplコマンドは，次の終了コードを返します。

0

処理は成功しました。

1

エラーが発生しました。詳細はエラーメッセージを参照してください。

2

エラーが発生しました。詳細はエラーメッセージを参照してください。

AUTHOR

nnmseeddelete.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmseeddelete.ovpl

Linux：$NNM_BIN/nnmseeddelete.ovpl

SEE ALSO

nnmloadseeds.ovpl, nnm.properties.

付録G.51　nnmsetdampenedinterval.ovpl

すべてのインシデントの設定に対するダンプニングの期間を設定します。

SYNOPSIS

nnmsetdampenedinterval.ovpl [ [-hours hours] [-minutes minutes] [-seconds seconds] [-u username] [-p password] ]

DESCRIPTION

nnmsetdampenedinterval.ovplコマンドは，すべてのインシデントの設定に対するダンプニングの期間を設定します。設定できるダンプニングの期間の最大は60分です。設定する場合，ダンプニングの期間は少なくとも6分を推奨します。少なくとも，hours, minutes, secondsの一つを指定する必要があります。ダンプニングを無効にするには，hours, minutes, secondsに0を設定します。

Parameters

-hours hours

ダンプニング期間の時間を指定します。指定する場合，値は0以上を指定してください。

-minutes minutes

ダンプニング期間の分を指定します。指定する場合，値は0以上を指定してください。

-seconds seconds

ダンプニング期間の秒を指定します。指定する場合，値は0以上を指定してください。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

EXAMPLES

すべてのインシデント設定のダンプニングの期間を10分10秒に設定します。

nnmsetdampenedinterval.ovpl -hours 0 -minutes 10 -seconds 10

すべてのインシデントの設定のダンプニングの期間を1時間に設定します。

nnmsetdampenedinterval.ovpl -hours 1

すべてのインシデントの設定のダンプニングの期間を6分に設定します。

nnmsetdampenedinterval.ovpl -minutes 6

すべてのインシデントの設定のダンプニングの期間を30秒に設定します。

nnmsetdampenedinterval.ovpl -seconds 30

すべてのインシデント設定のダンプニングの期間を10分10秒に設定します。

nnmsetdampenedinterval.ovpl -minutes 10 -seconds 10

すべてのインシデント設定のダンプニングを無効にします。

nnmsetdampenedinterval.ovpl -hours 0 -minutes 0 -seconds 0

AUTHOR

nnmsetdampenedinterval.ovpl was developed by Micro Focus.

SEE ALSO

nnm.properties

付録G.52　nnmsetofficialfqdn.ovpl

NNMi管理サーバーの正式な完全修飾名（FQDN）を設定します。

SYNOPSIS

nnmsetofficialfqdn.ovpl [-f | -force] <fqdn>

DESCRIPTION

インストール後にNNMi管理サーバーの正式な完全修飾ドメイン名（FQDN）を変更するには，nnmsetofficialfqdn.ovplスクリプトを使用します。このスクリプトを引数なしで実行すると，正式なFQDNをデフォルト値に設定します。デフォルト値は，ホスト名のルックアップの実行により取得されます。デフォルトのホスト名ルックアップについては，-mオプションを使用するnnmofficialfqdn.ovplスクリプトのリファレンスページを参照してください。

FQDNが変更されると，ユーザーは新しい自己署名SSL証明書を新しいホスト用に生成するよう求められます。また，CA署名の証明書を使用している場合は，新しいホスト名で，CAから新しい証明書を入手する必要があります。

Parameters

nnmsetofficialfqdn.ovplコマンドに任意で指定できる引数は2種類あります。

<fqdn>

ユーザーに確認した上で，正式な完全修飾名を指定値<fqdn>に変更します。

-force|-f

確認メッセージを表示せず，強制的に正式FQDNを変更するときに指定するフラグです。-fオプションを単独で指定した場合は，デフォルト値が正式FQDNとして設定されます。このオプションの後に<fqdn>を指定した場合は，指定値が正式FQDNとして設定されます。

EXAMPLES

FQDNをデフォルト値に設定する場合：

nnmsetofficialfqdn.ovpl

FQDNを"somehost.somedomain"に変更する場合：

nnmsetofficialfqdn.ovpl somehost.somedomain

正式 FQDN を強制的にデフォルト値に設定する場合：

nnmsetofficialfqdn.ovpl -f

AUTHOR

nnmsetofficialfqdn.ovpl was developed by Micro Focus.

FILES

nnmsetofficialfqdn.ovplは%NNM_BIN%（Windows）または$NNM_BIN（Linux）ディレクトリにあります。

SEE ALSO

nnmofficialfqdn.ovpl.

付録G.53　nnmsnmpbulk.ovpl

SNMPv2c GetBulk リクエストでノード情報について問い合わせを行います。

SYNOPSIS

nnmsnmpbulk.ovpl -u username -p password [options] node object-id [object-id]...

options: [-d] [-v version] [-c community] [-port port(default:161)] [-t timeout(default:5000)] [-r retries(default:1)] [-T] [-n non-repeaters] [-m max-repetitions] [-pp Proxy Port] [-pa Proxy Address] [-a Authentication Protocol] [-A Authentication Pass phrase] [-x Privacy Protocol] [-X Privacy Passphrase] [-N Context Name] [-oen OID and Output Encoding] [-oex OIDs that are not encoded] [-v3u SNMPv3 user name]

DESCRIPTION

nnmsnmpbulk.ovplコマンドは，SNMPエージェントから情報を取得するため，SNMPv2c/v3 GetBulkリクエストを使用します。SNMP GetBulkリクエストは，大量の情報を取得するときに必要なプロトコル交換の回数を最小限に抑えます。リモートノードから管理情報を取得するときに必要なリクエストの回数が減少するため，性能が向上します。

nodeが SNMPv1のみのエージェントの場合，このコマンドは，GetBulkリクエストをSNMPv1対応のGetNextリクエストに自動的にダウングレードします。

nodeは，IPアドレスを持つSNMPをサポートしているシステムです。IPアドレスまたはホスト名により指定できます。

コマンドに対する引数として，単数または複数のOIDを指定することができます。各OIDは，オブジェクト識別子を10進ドット形式またはニモニック名で表したものです。ニモニック名で指定した場合，OIDを定義するMIBをnnmloadmib.ovplコマンドを使用してロードする必要があります。

このコマンドを実行できるのは，ロールが System，管理者，またはWebサービスクライアントのユーザーに限定されます。ロールがレベル1オペレータ，レベル2オペレータ，またはゲストのユーザーは，このコマンドを実行することができません。

Parameters

-d

SNMPパケットを16進数形式とASN.1形式で標準出力にダンプします。

-v version

リモートノードとの通信に使用するSNMPのバージョンを指定します。versionに有効な値は，1，2，2cまたは3です。

このトポロジに存在しないノードで，値が指定されていない場合，デフォルトは2cになります。

-c community

リモートノード上で認証に使用するコミュニティ文字列を指定します。

注記：シェルに影響する文字がコミュニティ文字列に含まれている場合は，必要に応じて一つ以上のエスケープ文字または引用符を使用してください。

-port port

リモートノードと通信するときに使用するポートを指定します。

-t timeout

リモートノードと通信するときに使用するタイムアウト期間をミリ秒単位で指定します。

-r retries

リモートノードと通信するときに使用するリトライ数を指定します。

-T

10進ドット形式のOIDおよびテキスト形式の規定が適用されていないMIB変数値を出力します。

-n non-repeaters

non-repeatersは辞書的な順序で次候補を一つ返す変数の数を指定します。この値は，nnmsnmpbulk.ovplコマンドで取得する繰り返しのない varbind（値）の数を示しています。

-m max-repetitions

max-repetitionsは，残りの変数に対して，辞書的な順序で次候補をいくつ返すかを指定します。この値は，繰り返しのあるvarbind（値）に対して取得する行の数を示します。繰り返しのあるvarbindは，各テーブル行にあります。

-pp Proxy Port

ノードと通信するときに使用するプロキシポートを指定します。

-pa Proxy Address

ノードと通信するときに使用するプロキシIPアドレスを指定します。

-a Authentication Protocol

SNMPv3認証プロトコル(MD5|SHA|SHA224|SHA256|SHA384|SHA512)

-A Authentication Passphrase

SNMPv3認証パスフレーズ

-x Privacy Protocol

SNMPv3プライバシプロトコル(DES|3DES|AES|AES192|AES256)

-X Privacy Passphrase

SNMPv3プライバシパスフレーズ

-N Context Name

SNMPv3コンテキスト名 (例えばvlan1)

-oen <OID> : <encoding>

OIDおよび出力エンコード（例えば1.3.6.1.2.1.1.4:UTF-8）

-oex <OID1,OID2,...>

エンコードされていないOID

-v3u SNMPv3 user name

SNMPv3ユーザー名(例えばtestV3user)

-u <username>

コマンドの実行に必要な NNMi の管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

nnmsnmpbulk.ovplコマンドは，応答が受信されなかった場合に，線形のバックオフアルゴリズムを使用し，timeoutとretriesに基づいてSNMPリクエストを再送信します。 例えば，timeoutが2000（2秒）でretriesが3の場合，初期リクエストは2秒後にタイムアウトし，最初のリトライは4秒後にタイムアウトし，2番目のリトライは6秒後にタイムアウトし，最後のリトライは8秒後にタイムアウトします。設定を解決するには，さらに時間が必要になることもあります。

EXAMPLES

次のコマンドは，システムMIBオブジェクト識別子の下にあるすべての情報をノードtestnodeから取得します。

nnmsnmpbulk.ovpl -c community testnode .1.3.6.1.2.1.1.0

AUTHOR

nnmsnmpbulk.ovpl was developed by Micro Focus.

FILES

Windows：%NNM_BIN%¥nnmsnmpbulk.ovpl

Linux：$NNM_BIN/nnmsnmpbulk.ovpl

SEE ALSO

nnmloadmib.ovpl, nnmsnmpnotify.ovpl, nnmsnmpset.ovpl, nnmsnmpwalk.ovpl.

RFC 1155, 1157, 1212: SNMP Version 1.

RFC 1901 - 1908, 2576, 2578, 3416 - 3418: SNMP Version 2.

RFC 3411 - 3415: SNMP Version 3.

EXTERNAL INFLUENCES

Environmental Variables

$LANGは，メッセージを表示するときの言語を決定します。$LANGが指定されていない場合，または空の文字列に設定された場合，$LANGではなくCがデフォルトに使用されます。国際化変数のどれかに無効な設定値がある場合，nnmsnmpbulk.ovplは，国際化変数のすべてがCに設定されているように処理します。

International Code Set Support

シングルバイトまたはマルチバイトの文字コードセットをサポートします。

注記：DISPLAY STRINGタイプのSNMP MIB値はVT-ASCIIに限定されています。

付録G.54　nnmsnmpset.ovpl

SNMPセットリクエストを発行します。

SYNOPSIS

nnmsnmpset.ovpl -u username -p password [options] node object-id asnType value [object-id asnType value]...

options: [-d] [-v version] [-c write community] [-port port(default:161)] [-t timeout(default:5000)] [-r retries(default:1)(] [-T] [-pp Proxy Port] [-pa Proxy Address] [-a Authentication Protocol] [-A Authentication Pass phrase] [-x Privacy Protocol] [-X Privacy Passphrase] [-N Context Name] [-v3u SNMPv3 user name]

DESCRIPTION

nnmsnmpset.ovplコマンドは，リモートnode上のMIBオブジェクトを変更するためにSNMPセットリクエストを発行します。

object-id , asnType , valueの三つを一組としてnnmsnmpset.ovplコマンドからリモートノードに渡されるデータを指定します。ユーザーは，この組を少なくとも一つコマンドラインの引数で指定する必要があります。

各object-idは，10進ドット形式のオブジェクトインスタンス識別子（例えば，.1.3.6.1.4.1.11.2.17.2.1.0）またはニモニックの文字列（例えば，openViewSourceId.0）です。

各asnTypeは，次のasnTypesのいずれかとします。

integer

integer32

unsigned32

octetstring

octetstringhex

octetstringoctal

octetstringascii

objectidentifier

null

ipaddress

counter

counter32

counter64(SNMPv2c またはv3に対応するリモートノードの場合)

gauge

gauge32

timeticks

opaque

opaquehex

opaqueoctal

opaqueascii

各asnTypeの詳細説明は，RFC 1155およびRFC 1902を参照してください。

このときのvalueパラメータは，指定されたasnType で有効である必要があります。16進数または8進数の値が必要なasnTypeを使用する場合，ユーザーがこの値の各バイトを完全に定義する必要があります。例えば，fff(または17377)を指定すると，1バイト足りないため動作しません。代わりに0fff(または017377)を使用してください。asnTypeがnullの場合，ユーザーはコマンドライン上でvalueを指定する必要があります。リクエストの生成時，このvalueが無視されます。このvalueは，512バイトを超えてはなりません。

このコマンドを実行できるのは，ロールがSystem，管理者，またはWebサービスクライアントのユーザーに限定されます。ロールがレベル1オペレータ，レベル2オペレータ，またはゲストのユーザーは，このコマンドを実行することができません。

Parameters

-d

SNMPパケットを16進数形式とASN.1形式で標準出力にダンプします。

-v version

リモートノードとの通信に使用するSNMPのバージョンを指定します。versionに有効な値は，1，2cまたは 3です。

このトポロジに存在しないノードで，値が指定されていない場合，デフォルトは 2cになります。

-c write community

リモートノード上で認証に使用する書き込みコミュニティ文字列を指定します。

注記：シェルに影響する文字がコミュニティ文字列に含まれている場合は，必要に応じて一つ以上のエスケープ文字または引用符を使用してください。

-port port

リモートノードと通信するときに使用するポートを指定します。

-t timeout

リモートノードと通信するときに使用するタイムアウト期間をミリ秒単位で指定します。

-r retries

リモートノードと通信するときに使用するリトライ数を指定します。

-T

10進ドット形式のOIDおよびテキスト形式の規定が適用されていないMIB変数値を出力します。

-pp Proxy Port

ノードと通信するときに使用するプロキシポートを指定します。

-pa Proxy Address

ノードと通信するときに使用するプロキシIPアドレスを指定します。

-a Authentication Protocol

SNMPv3認証プロトコル(MD5|SHA|SHA224|SHA256|SHA384|SHA512)

-A Authentication Passphrase

SNMPv3認証パスフレーズ

-x Privacy Protocol

SNMPv3プライバシプロトコル(DES|3DES|AES|AES192|AES256)

-X Privacy Passphrase

SNMPv3プライバシパスフレーズ

-N Context Name

SNMPv3コンテキスト名(例えばvlan1)

-v3u SNMPv3 user name

SNMPv3ユーザー名(例えばtestV3user)

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

nnmsnmpset.ovplコマンドは，応答が受信されなかった場合に，線形のバックオフアルゴリズムを使用し，timeoutと retriesに基づいてSNMPリクエストを再送信します。例えば，timeoutが 2000(2秒)で retriesが3の場合，初期リクエストは2秒後にタイムアウトし，最初のリトライは4秒後にタイムアウトし，2番目のリトライは6秒後にタイムアウトし，最後のリトライは8秒後にタイムアウトします。設定を解決するには，さらに時間が必要になることもあります。

EXAMPLES

次のコマンドは，ノードtestnodeのsysContactの値をBob Jonesに設定します。

nnmsnmpset.ovpl -c writeCommunity testnode system.sysContact.0 octetstring "Bob Jones"

このコマンドの出力は次のとおりです。

sysContact.0 : OCTET STRING- (ascii): Bob Jones

AUTHOR

nnmsnmpset.ovpl was developed by Micro Focus.

FILES

Windows：

%NNM_BIN%¥nnmsnmpset.ovpl

%NnmInstallDir%¥doc¥rfc*.txt

Linux：

$NNM_BIN/nnmsnmpset.ovpl

$NnmInstallDir/doc/rfc*.txt

SEE ALSO

nnmsnmpwalk.ovpl, nnmsnmpget.ovpl, nnmsnmpnext.ovpl, nnmsnmpbulk.ovpl, nnmsnmpnotify.ovpl.

RFC 1155, 1157, 1212: SNMP Version 1.

RFC 1901 - 1908, 2576, 2578, 3416 - 3418: SNMP Version 2.

RFC 3411 - 3415: SNMP Version 3.

EXTERNAL INFLUENCES

Environmental Variables

$LANGは，メッセージを表示するときの言語を決定します。$LANGが指定されていない場合，または空の文字列に設定された場合，$LANGではなくCがデフォルトに使用されます。国際化変数のどれかに無効な設定値がある場合，nnmsnmpset.ovplは，国際化変数のすべてがCに設定されているように処理します。

International Code Set Support

シングルバイトまたはマルチバイトの文字コードセットをサポートします。

注記：asnTypeがoctetstringasciiのSNMP MIB値はVT-ASCIIに限定されています。

付録G.55　nnmsnmpwalk.ovpl, nnmsnmpget.ovpl, nnmsnmpnext.ovpl

SNMP GETリクエストまたはSNMP GETNEXTリクエストを使用してノードについて問い合わせを行います。

SYNOPSIS

nnmsnmpwalk.ovpl -u username -p password [options] node object-id

nnmsnmpget.ovpl -u username -p password [options] node object-id [object-id]...

nnmsnmpnext.ovpl -u username -p password [options] node object-id [object-id]...

options: [-d] [-v version] [-c community] [-port port(default:161)] [-t timeout(default:5000)] [-r retries(default:1)] [-T] [-pp Proxy Port] [-pa Proxy Address] [-a Authentication Protocol] [-A Authentication Pass phrase] [-x Privacy Protocol] [-X Privacy Passphrase] [-N Context Name] [-oen OID and Output Encoding] [-oex OIDs that are not encoded] [-v3u SNMPv3 user name]

DESCRIPTION

nnmsnmpwalk.ovplコマンドは，SNMP GETNEXTリクエストを繰り返し発行し，nodeで登録されているMIBオブジェクトのすべてのインスタンスの値を取得します。nnmsnmpwalk.ovplコマンドは，-vオプションの値およびリモートノードのタイプに基づき，SNMP Version1またはCommunity対応のSNMP Version2（SNMPv2c）またはversion3のいずれを使用するかを自動的に決定します。変数を指定しなかった場合，nnmsnmpwalk.ovplコマンドは，object.iso.orgの下にあるすべての値を取得します。その他の場合，検索対象のオブジェクト識別子空間の開始点が変数の値で決定されます。指定変数下のオブジェクト情報がすべて返ってきたとき， nnmsnmpwalk.ovplが終了します。例えば，システムグループ全体を検索するには.1.3.6.1.2.1.1 を使用します。

nnmsnmpget.ovplコマンドは，SNMP Getリクエストを使用してnodeについての情報を照会します。

一般に，SNMPインスタンス番号を追加する必要があります（例えば，system.sysDescr.0値の取得には.1.3.6.1.2.1.1.1.0を使用します）。

nnmsnmpnext.ovplコマンドはnnmsnmpwalk.ovplコマンドと同様の動作をしますが，nnmsnmpnext.ovplコマンドが単一の値のみを返す点が異なります。

nodeは，IPアドレスを持つSNMPをサポートしているシステム，またはSNMPプロキシ構成を定義するターゲット名です。IPアドレスまたはホスト名により指定できます。

コマンドに対する引数として，単数または複数の変数を指定することができます。各変数は，オブジェクト識別子を10進ドット形式またはニモニック名で表したものです。ニモニック名で指定した場合，オブジェクト識別子を定義するMIBはnnmloadmib.ovplコマンドを使用してロードする必要があります。

nnmsnmpwalk.ovplまたはnnmsnmpnext.ovplでリモートノードのMIBを超えて検索すると，「MIBビューの終了。」というメッセージが返ってきます。

このコマンドを実行できるのは，ロールがSystem，管理者，またはWebサービスクライアントのユーザーに限定されます。ロールがレベル1オペレータ，レベル2オペレータ，またはゲストのユーザーは，このコマンドを実行することができません。

Parameters

-d

SNMPパケットを16進数形式とASN.1形式で標準出力にダンプします。

-v version

リモートノードとの通信に使用する SNMP のバージョンを指定します。versionに有効な値は，1，2cまたは3です。

このトポロジに存在しないノードで，値が指定されていない場合，デフォルトは2cになります。

-c community

リモートノード上で認証に使用するコミュニティ文字列を指定します。

注記：シェルに影響する文字がコミュニティ文字列に含まれている場合は，必要に応じて一つ以上のエスケープ文字または引用符を使用してください。

-port port

リモートノードと通信するときに使用するポートを指定します。

-t timeout

リモートノードと通信するときに使用するタイムアウト期間をミリ秒単位で指定します。

-r retries

リモートノードと通信するときに使用するリトライ数を指定します。

-T

10進ドット形式のOIDおよびテキスト形式の規定が適用されていないMIB変数値を出力します。

-pp Proxy Port

ノードと通信するときに使用するプロキシポートを指定します。

-pa Proxy Address

ノードと通信するときに使用するプロキシIPアドレスを指定します。

-a Authentication Protocol

SNMPv3認証プロトコル(MD5|SHA|SHA224|SHA256|SHA384|SHA512)

-A Authentication Passphrase

SNMPv3認証パスフレーズ

-x Privacy Protocol

SNMPv3プライバシプロトコル(DES|3DES|AES|AES192|AES256)

-X Privacy Passphrase

SNMPv3プライバシパスフレーズ

-N Context Name

SNMPv3コンテキスト名 (例えばvlan1)

-oen <OID> : <encoding>

OIDおよび出力エンコード

収集されたMIBのオクテット文字列のエンコードされた文字列が，そのオクテット文字列が提供されたとおりにエンコードされた場合にのみ，出力に示されます。オクテット文字列が指定されたエンコーディングでエンコードされない場合，コマンドは16進数の文字列を示します。

-oex <OID1,OID2,...>

エンコードされていないOID

エンコード対象から除外されたOIDを指定します。このオプションで指定されたOIDはエンコードされず，16進数として出力されます。

-v3u SNMPv3 user name

SNMPv3ユーザー名(例えば testV3user)

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

nnmsnmpget.ovpl，nnmsnmpnext.ovpl，およびnnmsnmpwalk.ovplコマンドは，応答が受信されなかった場合に，線形のバックオフアルゴリズムを使用し，timeoutとretriesに基づいてSNMPリクエストを再送信します。例えば，timeoutが2000（2秒）で retriesが 3の場合，初期リクエストは2秒後にタイムアウトし，最初のリトライは4秒後にタイムアウトし，2番目のリトライは6秒後にタイムアウトし，最後のリトライは8秒後にタイムアウトします。設定を解決するには，さらに時間が必要になることもあります。

EXAMPLES

次のコマンドで，testnodeに対するシステムサブツリーを要求します。

nnmsnmpwalk.ovpl -c community testnode system

通常，上記コマンドの出力は下記のとおりです。

sysDescr.0 : OCTET STRING- (ascii): Ethernet Switch 470-24T-PWR
sysObjectID.0 : OBJECT IDENTIFIER: .1.3.6.1.4.1.45.3.63.1
sysUpTime.0 : Timeticks: (2975913) 8:15:59.13
sysContact.0 : OCTET STRING- (ascii): Bob Jones 933-558-3453
sysName.0 : OCTET STRING- (ascii): wr3-2-front-storage-n91-60-2
sysLocation.0 : OCTET STRING- (ascii): Woods Run 3 2nd floor
sysServices.0 : INTEGER: 3

以下に，ノード192.168.50.1にオプション-oenと-oexを使用する例を示します。

nnmsnmpwalk.ovpl -v 2c -c public -oen .1.3.6.1.2.1.1.4:shift-jis 192.168.50.1 .1.3.6.1.2.1.1

収集されたMIBのオクテット文字列のShift-JISにエンコードされた文字列が，そのオクテット文字列が有効なShift-JISである場合にのみ，出力に示されます。オクテット文字列が指定されたエンコーディングでエンコードされない場合，コマンドは16進数の文字列を示します。

nnmsnmpwalk.ovpl -v 2c -c public -oen .1.3.6.1.2.1.1.4:shift-jis -oex .1.3.6.1.2.1.1.4.0 192.168.50.1 .1.3.6.1.2.1.1

.1.3.6.1.2.1.1のMIBの戻り値と，1.3.6.1.2.1.1.4.0を除く1.3.6.1.2.1.1.4の子である 16進数の値をShift-JISでエンコードした文字列が出力に示されます。

AUTHOR

nnmsnmpwalk.ovpl, nnmsnmpget.ovpl, and nnmsnmpnext.ovpl were developed by Micro Focus.

FILES

Windows：

%NNM_BIN%¥nnmsnmpwalk.ovpl

%NNM_BIN%¥nnmsnmpget.ovpl

%NNM_BIN%¥nnmsnmpnext.ovpl

Linux：

$NNM_BIN/nnmsnmpwalk.ovpl

$NNM_BIN/nnmsnmpget.ovpl

$NNM_BIN/nnmsnmpnext.ovpl

ユーザーのプラットフォームおよびシェルに対する一般的なパスの詳細は，付録F.1　nnm.envvarsのリファレンスページを参照してください。

SEE ALSO

nnmsnmpset.ovpl, nnmsnmpbulk.ovpl, nnmsnmpnotify.ovpl.

RFC 1155, 1157, 1212: SNMP Version 1.

RFC 1901 - 1908, 2576, 2578, 3416 - 3418: SNMP Version 2.

RFC 3411 - 3415: SNMP Version 3.

EXTERNAL INFLUENCES

Environmental Variables

$LANGは，メッセージを表示するときの言語を決定します。$LANGが指定されていない場合，または空の文字列に設定された場合，$LANGではなくCがデフォルトに使用されます。国際化変数のどれかに無効な設定値がある場合，nnmsnmpget.ovpl，nnmsnmpnext.ovplおよび nnmsnmpwalk.ovplは，国際化変数のすべてがCに設定されているように処理します。

International Code Set Support

シングルバイトまたはマルチバイトの文字コードセットをサポートします。

注記：タイプDISPLAY STRINGのSNMP MIB値はVT-ASCIIに限定されています。

付録G.56　nnmstatuspoll.ovpl

このスクリプトは，状態ポーラーによりノードの状態を更新します。

SYNOPSIS

nnmstatuspoll.ovpl [ -help | -node <nodename|IP Address> [-tenant tenant name] [-t timeout in secs] [-v] [-u <username> -p <password>] ]

DESCRIPTION

nnmstatuspoll.ovplコマンドを使用すると，監視対象のデバイスを動的にポーリングすることができます。この結果，キー収集された状態値が更新されます。状態要求ポーリングに対する情報がすべて収集・表示されると，nnmstatuspoll.ovplコマンドは，ユーザーが要求したタスクが完了したことをユーザーに知らせます。

Parameters

-node <nodename|IP Address>

ターゲットノード名またはIPアドレスを指定します。

-tenant <tenant name>

特定のノードと組み合わせるテナントを指定します。このオプションは，アドレスのドメイン環境が重複しているなどの理由で，ノードの名前およびIPアドレスがトポロジにおいて一意でない場合に便利です。

-t <timeout in secs>

指定されたタイムアウト時間（秒単位）までクライアントが待ちます。

-v

詳細なログメッセージをコンソールに表示します。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-help

コマンドの使用方法を表示します。

RETURN VALUE

nnmstatuspoll.ovplは，上記パラメータセクションに表示されている適当な出力を返してきます。

-vオプションを使用すると，下記のカラムに情報が表示されます。

カラム1：データの収集にどのプロトコルを使用するかを表示します。

カラム2：ポーリングの対象であったデバイス名を表示します。

カラム3：ポーリングの対象であったMIBインスタンスを表示します。

カラム4：ポーリングの結果を表示します。

カラム5：マップされた値があれば，その値を表示します。

AUTHOR

nnmstatuspoll.ovpl was developed by Micro Focus.

SEE ALSO

nnm.properties

付録G.57　nnmtopodump.ovpl

NNMi トポロジデータベースの内容を出力します。

SYNOPSIS

nnmtopodump.ovpl -h | -u <username> -p <password> -type <type> [-legacy <format>] [-filter <filter>] [-http.host <host>] [-http.port <port>]

DESCRIPTION

nnmtopodump.ovpl はトポロジデータベースの内容を出力します。デフォルトでは，-legacy オプションを指定しない限り，xml 形式で出力されます。

Parameters

nnmtopodump.ovpl コマンドは，次のパラメータをサポートします。

-h

コマンドの使用方法を表示します。

-u <username>

コマンドの実行に必要な NNMi の管理者名を指定します。 nnm.properties ファイルが存在していない限り，これが必要になります。詳細は nnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要な NNMi の管理者パスワードを指定します。nnm.properties ファイルが存在していない限り，これが必要になります。詳細はnnm.properties リファレンスページを参照してください。

-http.host <host>

サーバーのホスト。デフォルトは localhost です。

-http.port <port>

サーバーのポート。デフォルトは 80です。

-type <type>

出力するオブジェクトのタイプ。次のいずれかが指定できます。

node|interface|incident|ip|subnet|rrp|vlan|nodeSensor|interfaceAggregation|card|l2connection|physcomp|physSensor

-legacy [long]

-legacyオプションを指定すると，データをテキスト形式で出力します。このオプションを指定しない場合，xml 形式で出力されます。このオプションは，次のタイプ値とだけ使用できます。

node, interface, ip, l2connection および interfaceAggregation。

-filter <filter>

出力をプロパティで絞り込みます。nnmtopodump.ovplコマンドは，次に示すフィルターをサポートします。

node - node.name | node.shortname | node.id | node.uuid | node.status | node.snmpaddress | node.managementMode | node.deviceCategory | node.deviceDescription | node.deviceFamily | node.deviceVendor

interface - node.name | node.shortname | node.id | node.snmpaddress | node.managementMode | node.deviceCategory | node.deviceDescription | node.deviceFamily | node.deviceVendor | interface.ifType | interface.id | interface.uuid | interface.managementMode | interface.managementState

ip - interface.id | node.id | ip.value | ip.id

vlan - node.name | node.id | vlan.id | vlan.name | vlan.value

nodeSensor - node.name | node.hostname | node.id | nodeSensor.id |nodeSensor.name | nodeSensor.type

interfaceAggregation - master.id | master.uuid | master.index | master.alias |slave.id | slave.uuid | slave.index | slave.alias

card - node.name | node.hostname | node.uuid | comp.uuid | comp.name

l2connection - connection.name | connection.id | connection.uuid

physcomp - node.name | node.hostname | node.uuid | comp.uuid | comp.name | comp.type

physSensor - node.name | node.hostname | node.id | physcomp.name |physcomp.id | physSensor.id | physSensor.name | physSensor.type

EXAMPLES

nnmtopodump.ovpl -u username -p password -type node

トポロジデータベースにあるすべてのノードの情報を xml 形式で表示します。 （NNMi 管理者のユーザー名とパスワードを指定する必要があります。）

nnmtopodump.ovpl -u username -p password -legacy long -type node

ノードをテキスト形式で出力する場合，legacy オプションを使用する必要があります。すべてのノードとそのインタフェースの情報を表示するには， -legacy と -type node オプションを使用します。

NNM 6.x/7.x での同等コマンド： ovtopodump -l

nnmtopodump.ovpl -u username -p password -type node -filter node.name=foo.microfocus.com

ノード foo.microfocus.com の情報を xml 形式で出力します。

nnmtopodump.ovpl -u username -p password -legacy long -type node -filter node.name=foo.microfocus.com

ノード foo.microfocus.com の情報をテキスト形式で出力します。ノードとそのインタフェースの情報を表示するには， -legacy と -type node オプションを使用します。

NNM 6.x/7.x での同等コマンド： ovtopodump -lr foo.microfocus.com

nnmtopodump.ovpl -u username -p password -legacy long -type node -filter node.id=2345

ノードの id が2345のノードの情報をテキスト形式で出力します。NNMi はノードのすべてのインタフェースの情報も表示します。

NNM 6.x/7.x での同等コマンド： ovtopodump -lr 2345

nnmtopodump.ovpl -u username -p password -type interface -filter interface.managementState=MANAGED

トポロジデータベースにあるすべての管理されているインタフェースの情報を xml 形式で出力します。フィルターには，MANAGED，NOTMANAGED および OUTOFSERVICE が指定できます。

FILTER

nnmtopodump.ovpl コマンドは以下のフィルターをサポートします。

-type node

node.name - ノードのホスト名。

node.shortname - ノード名。

node.id - ノードのID。

node.uuid - ノードのUUID。

node.status - ノードのステータス。フィルターの値は NORMAL，WARNING，MINOR，MAJOR および CRITICAL が使用できます。

node.snmpaddress - ノードの管理アドレス。

node.managementMode - ノードのノード管理モード。フィルターの値は MANAGED，NOTMANAGED および OUTOFSERVICE が使用できます。

node.deviceCategory - ノードのデバイスのプロファイルのカテゴリ。

node.deviceDescription - ノードのデバイスのプロファイルの説明。

node.deviceFamily - ノードのデバイスのプロファイルのファミリ。

node.deviceVendor - ノードのデバイスのプロファイルのベンダー。

-type interface

node.name - ホスト元ノードのホスト名。

node.shortname - ホスト元ノードのノード名。

node.id - ホスト元ノードのID。

node.snmpaddress - ホスト元ノードの管理アドレス。

node.managementMode - ホスト元ノードのノード管理モード。フィルターの値は MANAGED, NOTMANAGED および OUTOFSERVICE が使用できます。

node.deviceCategory - ホスト元ノードのデバイスのプロファイルのカテゴリ。

node.deviceDescription - ホスト元ノードのデバイスのプロファイルの説明。

node.deviceFamily - ホスト元ノードのデバイスのプロファイルのファミリ。

node.deviceVendor - ホスト元ノードのデバイスのプロファイルのベンダー。

interface.ifType - インターフェイスのifType。

interface.id - インターフェイスのID。

interface.uuid - インターフェイスのUUID。

interface.managementMode - インターフェイスの直接管理モード。フィルターの値は INHERITED, NOTMANAGED および OUTOFSERVICE が使用できます。

interface.managementState - インターフェイスの管理モード。フィルターの値は MANAGED, NOTMANAGED および OUTOFSERVICE が使用できます。

-type ip

interface.id - インターフェイスのID。

node.id - ホスト元ノードのID。

ip.value - IPアドレスのアドレス。

ip.id - IPアドレスのID。

-type vlan

node.name - ポートのホスト元ノードのホスト名。

node.id - ポートのホスト元ノードのID。

vlan.id - VLANのデータベース上でのID。

vlan.name - VLANの名前。

vlan.value - VLANのVLAN ID。

-type nodeSensor

node.name - ホスト元ノードのノード名。

node.hostname - ホスト元ノードのホスト名。

node.id - ホスト元ノードのID。

nodeSensor.id - ノードセンサーのID。

nodeSensor.name - ノードセンサーの名前。

nodeSensor.type - ノードセンサーのタイプ。フィルターの値は com.hp.nnm.sensor.CPU，com.hp.nnm.sensor.MEMORY，com.hp.nnm.sensor.BUFFERS，com.hp.nnm.sensor.DISK，com.hp.nnm.sensor.BGP_PEER および com.hp.nnm.sensor.WLAN が使用できます。

-type interfaceAggregation

master.id - 集約インターフェイスのID。

master.uuid - 集約インターフェイスのUUID。

master.index - 集約インターフェイスのifIndex。

master.alias - 集約インターフェイスのifAlias。

slave.id - 集約メンバーインターフェイスのID。

slave.uuid - 集約メンバーインターフェイスのUUID。

slave.index - 集約メンバーインターフェイスのifIndex。

slave.alias - 集約メンバーインターフェイスのifAlias。

-type card

node.name - 管理ノードのノード名。

node.hostname - 管理ノードのホスト名。

node.uuid - 管理ノードのUUID。

comp.uuid - カードのUUID。

comp.name - カードの名前。

-type l2connection

connection.name - レイヤー2の接続の名前。

connection.id - レイヤー2の接続のID。

connection.uuid - レイヤー2の接続のUUID。

-type physcomp

node.name - 管理ノードのノード名。

node.hostname - 管理ノードのホスト名。

node.uuid - 管理ノードのUUID。

comp.uuid - 物理コンポーネントのUUID。

comp.name - 物理コンポーネントの名前。

comp.type - 物理コンポーネントのタイプ。フィルターの値は com.hp.nnm.CHASSIS，com.hp.nnm.CARD，com.hp.nnm.BACKPLANE，com.hp.nnm.POWER，com.hp.nnm.FAN，com.hp.nnm.SENSOR および com.hp.nnm.CPU が使用できます。

-type physSensor

node.name - 管理ノードのノード名。

node.hostname - 管理ノードのホスト名。

node.id - 管理ノードのID。

physComp.id - コンポーネントのID。

physComp.name - コンポーネントの名前。

physSensor.id - 物理センサーのID。

physSensor.name - 物理センサーの名前。

physSensor.type - 物理センサーのタイプ。フィルターの値は com.hp.nnm.physSensor.FAN，com.hp.nnm.physSensor.POWER_SUPPLY，com.hp.nnm.physSensor.TEMPERATURE，com.hp.nnm.physSensor.VOLTAGE，com.hp.nnm.physSensor.BACKPLANE および com.hp.nnm.physSensor.RADIO が使用できます。

OUTPUT FIELDS

-type node

/topo/node/id - ノードのID。

/topo/node/uuid - ノードのUUID。

/topo/node/shortname - ノード名。

/topo/node/name - ノードのホスト名。

/topo/node/description - ノードのシステムの説明。

/topo/node/status - ノードのステータス。

/topo/node/managementMode - ノードのノード管理モード。

/topo/node/contact - ノードのシステムの連絡先。

/topo/node/location - ノードのシステムのロケーション。

/topo/node/nodesnmpsysname - ノードのシステムの名前。

/topo/node/nodesnmpaddress - ノードの管理アドレス。

/topo/node/systemObjectId - ノードのシステムのオブジェクトID。

/topo/node/notes - ノードの注。

/topo/node/nodecreatetime - ノードの作成日時。

/topo/node/nodemodifiedtime - ノードの最終変更日時。

/topo/node/nodelaststatuschange - ノードのステータスの最終変更日時。

/topo/node/protocolversion - このフィールドは非サポートです。

/topo/node/snmpAgent - このフィールドは非サポートです。

/topo/node/discoveryState - ノードの検出状態。

/topo/node/deviceDescription - ノードのデバイスのプロファイルの説明。

/topo/node/deviceCategory - ノードのデバイスのプロファイルのカテゴリ。

/topo/node/deviceFamily - ノードのデバイスのプロファイルのファミリー。

/topo/node/deviceVendor - ノードのデバイスのプロファイルのベンダー。

/topo/node/capabilities - ノードのケーパビリティの一覧。

/topo/node/capabilities/capability - ノードのケーパビリティ。

/topo/node/extendedAttributes - ノードのカスタム属性の一覧。

/topo/node/extendedAttributes/attribute - ノードのカスタム属性。

/topo/node/extendedAttributes/attribute/name - カスタム属性の名前。

/topo/node/extendedAttributes/attribute/value - カスタム属性の値。

/topo/node/hostedOnId - ノードのホスト元ノードのID。このフィールドは仮想インスタンスか仮想マシンでのみ表示されます。

/topo/node/hostedOnName - ノードホスト元ノードのノード名。このフィールドは仮想インスタンスか仮想マシンでのみ表示されます。

/topo/node/hostedOnHostname - ノードホスト元ノードのホスト名。このフィールドは仮想インスタンスか仮想マシンでのみ表示されます。

/topo/node/powerState - ノードの電源状態。 このフィールドはVMWare仮想マシンでのみ表示されます。

/topo/node/lastStateChange - ノードの状態の最終変更日時。このフィールドはVMWare仮想マシンでのみ表示されます。

-type node -legacy long

ホスト名： - ノードのホスト名。

短縮名： - ノード名。

ノードID： - ノードのID。

ノードUUID： - ノードのUUID。

作成時間： - ノードの作成日時。

修正時間： - ノードの最終変更日時。

ステータス： - ノードのステータス。

管理モード： - ノード管理モード。

再度のステータス変更： - ノードのステータスの最終変更日時。

説明： - ノードのシステムの説明。

場所： - ノードのシステムのロケーション。

連絡先： - ノードのシステムの連絡先。

SNMP SYSNAME：- ノードのシステムの名前。

SNMP オブジェクトID： - ノードのシステムのオブジェクト ID。

サポートされているSNMPバージョン： - このフィールドは非サポートです。

SNMPアドレス： - ノードの管理アドレス。

ノードの説明： - ノードのデバイスのプロファイルの説明。

ノードカテゴリ： - ノードのデバイスのプロファイルのカテゴリ。

ノードファミリ： - ノードのデバイスのプロファイルのファミリー。

ノードベンダー： - ノードのデバイスのプロファイルのベンダー。

ノードエージェント： - このフィールドは非サポートです。

ルートグループ/ポート： - このフィールドは非サポートです。

ノードラベル： - ノードのホスト名。

ケーパビリティ： - ノードのケーパビリティ。

CUSTOM-ATTRIBUTE： - ノードのカスタム属性。

ノードのホスト元ID： - ノードのホスト元ノードのID。

ノードのホスト元名： - ノードのホスト元ノードのノード名。

ノードのホスト元ホスト名： - ノードのホスト元ノードのホスト名。

インターフェイスの数： - ノードのインターフェイスの数。

-type interface

/topo/interface/id - インターフェイスのID。

/topo/interface/uuid - インターフェイスのUUID。

/topo/interface/ifName - インターフェイスのifName。

/topo/interface/ifAlias - インターフェイスのifAlias。

/topo/interface/ifType - インターフェイスのifType。

/topo/interface/ifIndex - インターフェイスのifIndex。

/topo/interface/ifDescr - インターフェイスのifDescr。

/topo/interface/physicalAddress - インターフェイスの物理アドレス。

/topo/interface/cdp - このフィールドは非サポートです。

/topo/interface/speed - インターフェイスのifSpeed。

/topo/interface/ifcreatetime - インターフェイスの作成日時。

/topo/interface/ifmodtime - インターフェイスの最終変更日時。

/topo/interface/status - インターフェイスのステータス。

/topo/interface/managementMode - インターフェイスの直接管理モード。

/topo/interface/managementState - インターフェイスの管理モード。

/topo/interface/hostedOnId - インターフェイスのホスト元ノードのID。

/topo/interface/hostedOnName - インターフェイスのホスト元ノードのホスト名。

/topo/interface/capabilities - インターフェイスのケーパビリティの一覧。

/topo/interface/capabilities/capability - インターフェイスのケーパビリティ。

/topo/interface/extendedAttributes - インターフェイスのカスタム属性の一覧。

/topo/interface/extendedAttributes/attribute -インターフェイスのカスタム属性。

/topo/interface/extendedAttributes/attribute/name - カスタム属性の名前。

/topo/interface/extendedAttributes/attribute/value - カスタム属性の値。

-type interface -legacy long

インターフェイス名： - インターフェイスのifName。

インターフェイスの説明： - インターフェイスのifDescr。

IF_ALIAS： - インターフェイスのifAlias。

インターフェイスID： - インターフェイスのID。

インターフェイスUUID： - インターフェイスのUUID。

作成時間： - インターフェイスの作成日時。

修正時間： - インターフェイスの最終変更日時。

ステータス： - インターフェイスのステータス。

管理モード： - インターフェイスの直接管理モード。

管理状態： - インターフェイスの管理モード。

IF 番号： - インターフェイスのifIndex。

IF タイプ： - インターフェイスのifType。

物理アドレス： - インターフェイスの物理アドレス。

ノードID： - インターフェイスのホスト元ノードのID。

CDP： - このフィールドは非サポートです。

速度： - インターフェイスのifSpeed。

ノード名： - インターフェイスのホスト元ノードのホスト名。

ケーパビリティ： - インターフェイスのケーパビリティ。

CUSTOM-ATTRIBUTE： - インターフェイスのカスタム属性。

-type incident

/topo/incident/id - インシデントのID。

/topo/incident/uuid - インシデントのUUID。

/topo/incident/name - インシデントの名前。

/topo/incident/severity - インシデントの重大度。

/topo/incident/formattedMessage - インシデントのメッセージ。

/topo/incident/sourceName - インシデントのソースオブジェクトの名前。

/topo/incident/sourceType - インシデントのソースオブジェクトのタイプ。

/topo/incident/sourceUuid - インシデントのソースオブジェクトのUUID。

/topo/incident/nodeName - インシデントのソースノードの名前。

/topo/incident/nodeUuid - インシデントのソースノードのUUID。

/topo/incident/nature - インシデントの相関特性。

/topo/incident/assignedTo - インシデントの割り当て先。

/topo/incident/origin - インシデントの発生元。

/topo/incident/originOccurrenceTime - インシデントの元の発生日時。

/topo/incident/firstOccurrenceTime - インシデントの最初の発生日時。

/topo/incident/lastOccurrenceTime - インシデントの最後の発生日時。

/topo/incident/notes - インシデントの相関の注。

/topo/incident/rcaActive - インシデントのRCAアクティブ。

/topo/incident/duplicateCount - インシデントの重複数。

/topo/incident/lifecycleState - インシデントのライフサイクル状態。

/topo/incident/priority - インシデントの優先度。

/topo/incident/category - インシデントのカテゴリ。

/topo/incident/family - インシデントのファミリ。

/topo/incident/cias - インシデントのカスタムインシデント属性の一覧。

/topo/incident/cias/cia - インシデントのカスタムインシデント属性。

/topo/incident/cias/cia/id - カスタムインシデント属性のID。

/topo/incident/cias/cia/name - カスタムインシデント属性の名前。

/topo/incident/cias/cia/type - カスタムインシデント属性のタイプ。

/topo/incident/cias/cia/value - カスタムインシデント属性の値。

-type ip

/topo/ip/id - IPアドレスのID。

/topo/ip/uuid - IPアドレスのUUID。

/topo/ip/name - IPアドレス。

/topo/ip/status - IPアドレスのステータス。

/topo/ip/value - IPアドレス。

/topo/ip/prefixLength - IPアドレスのプレフィックス長。

/topo/ip/interface - IPアドレスのインターフェイスのID。

/topo/ip/node - IPアドレスのホスト元ノードのID。

/topo/ip/subnet - IPアドレスのサブネットのID。

/topo/ip/extendedAttributes - このフィールドは非サポートです。

-type ip -legacy long

IPAddress ID： - IPアドレスのID。

UUID： - IPアドレスのUUID。

名前： - IPアドレスのアドレス。

ステータス： - IPアドレスのステータス。

IP アドレス： - IPアドレスのアドレス。

プレフィックス長： - IPアドレスのプレフィックス長。

インターフェイス ID： - IPアドレスのインターフェイスのID。

ノード ID： - IPアドレスのホスト元ノードのID。

サブネット ID： - IPアドレスのサブネットのID。

-type subnet

/topo/subnet/id - IPサブネットのID。

/topo/subnet/uuid - IPサブネットのUUID。

/topo/subnet/name - IPサブネットの名前。

/topo/subnet/status - このフィールドは非サポートです。

/topo/subnet/prefix - IPサブネットのプレフィックス。

/topo/subnet/prefixLength - IPサブネットのプレフィックス長。

/topo/subnet/extendedAttributes - このフィールドは非サポートです。

-type rrp

/topo/routerRedundancyGroup/id - ルーター冗長グループのID。

/topo/routerRedundancyGroup/name - ルーター冗長グループの名前。

/topo/routerRedundancyGroup/groupNumber - ルーター冗長グループのグループ番号。

/topo/routerRedundancyGroup/protocol - ルーター冗長グループのプロトコル。

/topo/routerRedundancyGroup/extendedAttributes - このフィールドは非サポートです。

/topo/routerRedundancyGroup/protectedIPs - ルーター冗長グループの仮想IPアドレスの一覧。

/topo/routerRedundancyGroup/protectedIPs/value - ルーター冗長グループの仮想IPアドレスの値

/topo/routerRedundancyGroup/protectedIPs/extendedAttributes - このフィールドは非サポートです。

/topo/routerRedundancyGroup/status - ルーター冗長グループのステータス。

/topo/routerRedundancyGroup/members - ルーター冗長グループのルーター冗長メンバーの一覧。

/topo/routerRedundancyGroup/members/member - ルーター冗長グループのルーター冗長メンバー。

/topo/routerRedundancyGroup/members/member/id - ルーター冗長メンバーのID

/topo/routerRedundancyGroup/members/member/name - ルーター冗長メンバーの名前。

/topo/routerRedundancyGroup/members/member/isOwner - ルーター冗長メンバーが所有者であるかどうか。

/topo/routerRedundancyGroup/members/member/hostedOnId - ルーター冗長メンバーのホスト元ノードのID。

/topo/routerRedundancyGroup/members/member/hostedOnName - ルーター冗長メンバーのホスト元ノードの名前

/topo/routerRedundancyGroup/members/member/redundancyInterfaceId - ルーター冗長メンバーの冗長インターフェイスのID。

/topo/routerRedundancyGroup/members/member/currentState - ルーター冗長メンバーの現在の状態。

/topo/routerRedundancyGroup/members/member/previousState - ルーター冗長メンバーの以前の状態。

/topo/routerRedundancyGroup/members/member/priority - ルーター冗長メンバーの優先度。

/topo/routerRedundancyGroup/members/member/extendedAttributes - このフィールドは非サポートです。

/topo/routerRedundancyGroup/members/member/trackedObjects - ルーター冗長メンバーの追跡対象オブジェクトの一覧。

/topo/routerRedundancyGroup/members/member/trackedObjects/trackedObject - ルーター冗長メンバーの追跡対象オブジェクト。

/topo/routerRedundancyGroup/members/member/trackedObjects/trackedObject/id - 追跡対象オブジェクトのID。

/topo/routerRedundancyGroup/members/member/trackedObjects/trackedObject/type - 追跡対象オブジェクトのタイプ。

/topo/routerRedundancyGroup/members/member/trackedObjects/trackedObject/objectUuid - 追跡対象オブジェクトのUUID。

/topo/routerRedundancyGroup/members/member/trackedObjects/trackedObject/hostedOnId - 追跡対象オブジェクトのホスト元ノードのID。

/topo/routerRedundancyGroup/members/member/trackedObjects/trackedObject/hostedOnName - 追跡対象オブジェクトのホスト元ノードの名前。

/topo/routerRedundancyGroup/members/member/trackedObjects/trackedObject/trackPriority - 追跡対象オブジェクトの追跡の優先度。

/topo/routerRedundancyGroup/members/member/trackedObjects/trackedObject/extendedAttributes - このフィールドは非サポートです。

-type vlan

/topo/vlan/vlanId - VLANのデータベース上でのID。

/topo/vlan/vlanValue - VLANのVLAN ID。

/topo/vlan/vlanName - VLANの名前。

/topo/vlan/portId - VLANのポートのID。

/topo/vlan/portName - VLANのポートの名前。

/topo/vlan/nodeId - VLANのポートのホスト元ノードのID。

/topo/vlan/nodeName - VLANのポートのホスト元ノードのホスト名。

-type nodeSensor

/topo/nodeSensor/id - ノードセンサーのID。

/topo/nodeSensor/uuid - ノードセンサーのUUID。

/topo/nodeSensor/name - ノードセンサーの名前。

/topo/nodeSensor/type - ノードセンサーのタイプ。

/topo/nodeSensor/node - ノードセンサーのホスト元ノード。

/topo/nodeSensor/node/id - ホスト元ノードのID。

/topo/nodeSensor/node/uuid - ホスト元ノードのUUID。

/topo/nodeSensor/node/name - ホスト元ノードのノード名。

/topo/nodeSensor/node/hostname - ホスト元ノードのホスト名。

/topo/nodeSensor/monitoredAttributes - ノードセンサーの監視対象属性の一覧。

/topo/nodeSensor/monitoredAttributes/attribute - ノードセンサーの監視対象属性。

/topo/nodeSensor/monitoredAttributes/attribute/id - 監視対象属性のID。

/topo/nodeSensor/monitoredAttributes/attribute/name - 監視対象属性の名前。

/topo/nodeSensor/monitoredAttributes/attribute/state - 監視対象属性の状態。

/topo/nodeSensor/monitoredAttributes/attribute/modified - 監視対象属性の最終変更日時。

/topo/nodeSensor/extendedAttributes - このフィールドは非サポートです。

-type interfaceAggregation

/topo/interfaceAggregation - 集約インターフェイスと集約メンバーインターフェイスの関連。

/topo/interfaceAggregation/master - 集約インターフェイス。

/topo/interfaceAggregation/master/id - 集約インターフェイスのID。

/topo/interfaceAggregation/master/uuid - 集約インターフェイスのUUID。

/topo/interfaceAggregation/master/index - 集約インターフェイスのifIndex。

/topo/interfaceAggregation/master/alias - 集約インターフェイスのifAlias。

/topo/interfaceAggregation/slave - 集約メンバーインターフェイス。

/topo/interfaceAggregation/slave/id - 集約メンバーインターフェイスのID。

/topo/interfaceAggregation/slave/uuid - 集約メンバーインターフェイスのUUID。

/topo/interfaceAggregation/slave/index - 集約メンバーインターフェイスのifIndex。

/topo/interfaceAggregation/slave/alias - 集約メンバーインターフェイスのifAlias。

-type interfaceAggregation -legacy long

マスター - 集約インターフェイス。

ID： - 集約インターフェイスのID。

UUID： - 集約インターフェイスのUUID。

インデックス： - 集約インターフェイスのifIndex。

エイリアス： - 集約インターフェイスのifAlias。

スレーブ - 集約メンバーインターフェイス。

ID： - 集約メンバーインターフェイスのID。

UUID： - 集約メンバーインターフェイスのUUID。

インデックス： - 集約メンバーインターフェイスのifIndex。

エイリアス： - 集約メンバーインターフェイスのifAlias。

-type l2connection

/topo/l2connection/id - レイヤー2の接続のID。

/topo/l2connection/name - レイヤー2の接続の名前。

/topo/l2connection/status - レイヤー2の接続のステータス。

/topo/l2connection/source - レイヤー2の接続のトポロジソース。

/topo/l2connection/uuid - レイヤー2の接続のUUID。

-type l2connection -legacy long

L2Connection ID： - レイヤー2の接続のID。

L2Connection 名： - レイヤー2の接続の名前。

L2Connection ステータス： - レイヤー2の接続のステータス。

L2Connection ソース： - レイヤー2の接続のトポロジソース。

L2Connection UUID： - レイヤー2の接続のUUID。

-type physcomp , -type card

/topo/physcomp/uuid - 物理コンポーネントのUUID。

/topo/physcomp/name - 物理コンポーネントの名前。

/topo/physcomp/type - 物理コンポーネントのタイプ。

/topo/physcomp/index - 物理コンポーネントのコンポーネントID。

/topo/physcomp/slots - このフィールドは非サポートです。

/topo/physcomp/modelName - 物理コンポーネントのモデル名。

/topo/physcomp/modelType - 物理コンポーネントのモデルタイプ。

/topo/physcomp/serialNumber - 物理コンポーネントのシリアル番号。

/topo/physcomp/firmwareVersion - 物理コンポーネントのファームウェアバージョン。

/topo/physcomp/hardwareVersion - 物理コンポーネントのハードウェアバージョン。

/topo/physcomp/softwareVersion - 物理コンポーネントのソフトウェアバージョン。

/topo/physcomp/description - 物理コンポーネントの説明。

/topo/physcomp/parent - 物理コンポーネントの親コンポーネント。

/topo/physcomp/capabilities - 物理コンポーネントのケーパビリティの一覧。

/topo/physcomp/capabilities/capability - 物理コンポーネントのケーパビリティ。

/topo/physcomp/extendedAttributes - 物理コンポーネントのカスタム属性の一覧。

/topo/physcomp/extendedAttributes/attribute - 物理コンポーネントのカスタム属性。

/topo/physcomp/extendedAttributes/attribute/name - カスタム属性の名前。

/topo/physcomp/extendedAttributes/attribute/value - カスタム属性の値。

/topo/physcomp/node - 物理コンポーネントの管理ノード。

/topo/physcomp/node/uuid - 管理ノードのUUID。

/topo/physcomp/node/name - 管理ノードのノード名。

/topo/physcomp/node/hostname - 管理ノードのホスト名。

/topo/physcomp/hostedNodes - 物理コンポーネントのホスト対象ノードの一覧。

/topo/physcomp/hostedNodes/hostedNode - 物理コンポーネントのホスト対象ノード。

/topo/physcomp/hostedNodes/hostedNode/idホスト対象ノードのID

/topo/physcomp/hostedNodes/hostedNode/nameホスト対象ノードのノード名

/topo/physcomp/hostedNodes/hostedNode/hostnameホスト対象ノードのホスト名

/topo/physcomp/monitoredAttributes - 物理コンポーネントの状態。

/topo/physcomp/monitoredAttributes/administrativeState - 物理コンポーネントの管理状態。

/topo/physcomp/monitoredAttributes/operationalState - 物理コンポーネントの運用状態。

/topo/physcomp/monitoredAttributes/standByState - 物理コンポーネントのスタンバイ状態。

/topo/physcomp/monitoredAttributes/previousStandByState - 物理コンポーネントの以前のスタンバイ状態。

/topo/physcomp/monitoredAttributes/modified - 物理コンポーネントの状態の最終変更日時。

/topo/physcomp/redundancyGroup - 物理コンポーネントの冗長グループ。

/topo/physcomp/redundancyGroup/uuid - 物理コンポーネントの冗長グループのUUID。

/topo/physcomp/redundancyGroup/name - 物理コンポーネントの冗長グループの名前。

/topo/physcomp/status - 物理コンポーネントのステータス。

/topo/physcomp/status/timestamp - 物理コンポーネントのステータスの最終変更日時。

/topo/physcomp/status/value - 物理コンポーネントのステータスの値。

/topo/physcomp/status/conclusion - 物理コンポーネントの結果。

/topo/physcomp/status/conclusion/name - 物理コンポーネントの結果の名前。

/topo/physcomp/status/conclusion/status - 物理コンポーネントの結果のステータス。

/topo/physcomp/status/conclusion/timestamp - 物理コンポーネントの結果のタイムスタンプ。

/topo/physcomp/optStrings - このフィールドは非サポートです。

-type physSensor

/topo/physSensor/id - 物理センサーのID。

/topo/physSensor/uuid - 物理センサーのUUID。

/topo/physSensor/name - 物理センサーの名前。

/topo/physSensor/type - 物理センサーのタイプ。

/topo/physSensor/physComp - 物理センサーのコンポーネント。

/topo/physSensor/physComp/id - 物理センサーのコンポーネントのID。

/topo/physSensor/physComp/uuid - 物理センサーのコンポーネントのUUID。

/topo/physSensor/physComp/name - 物理センサーのコンポーネントの名前。

/topo/physSensor/node - 物理センサーの管理ノード。

/topo/physSensor/node/id - 物理センサーの管理ノードのID。

/topo/physSensor/node/uuid - 物理センサーの管理ノードのUUID。

/topo/physSensor/node/name - 物理センサーの管理ノードの名前。

/topo/physSensor/node/hostname - 物理センサーの管理ノードのホスト名。

/topo/physSensor/monitoredAttributes - 物理センサーの監視対象属性の一覧。

/topo/physSensor/monitoredAttributes/attribute - 物理センサーの監視対象属性。

/topo/physSensor/monitoredAttributes/attribute/id - 監視対象属性のID。

/topo/physSensor/monitoredAttributes/attribute/name - 監視対象属性の名前。

/topo/physSensor/monitoredAttributes/attribute/state - 監視対象属性の状態。

/topo/physSensor/monitoredAttributes/attribute/modified - 監視対象属性の最終変更日時。

/topo/physSensor/extendedAttributes - このフィールドは非サポートです。

AUTHOR

nnmtopodump.ovpl was developed by Micro Focus.

SEE ALSO

nnmnodedelete.ovpl, nnm.properties.

付録G.58　nnmtopoquery.ovpl

NNMi トポロジ上のクエリーを実行します。

SYNOPSIS

nnmtopoquery.ovpl findConnectedNeighborInterfacesByNode -node (<name>|<uuid>)

nnmtopoquery.ovpl findL2ConnectionsByNode -node (<name>|<uuid>)

nnmtopoquery.ovpl findWebAgentSettingsByNode -node (<name>|<uuid>)

nnmtopoquery.ovpl listWebAgentSettings

DESCRIPTION

nnmtopoquery.ovplはNNMi管理サーバに対してクエリを実行して，選択可能な形式で結果を出力します。

Parameters

nnmtopoquery.ovpl以下のオプションを認識します。

-h

使用方法を出力します。

-node (<name>|<uuid>)

入力として受け入れるクエリのノードを指定します。ノードはノード名，ホスト名またはUUIDによって参照することができます。

-format (csv|list|text|xml)

出力形式を変更します。可能な出力モードは，CSV，LIST，TEXTおよびXMLです。

-fields <comma_separated_fields>

CSVファイルで出力フィールドを選択します。この引数が提供されない場合，すべてのフィールドがデフォルトで出力されます。この引数が提供された場合，フィールドが指定した順序で出力されます。

-u <username> -p <password>

スクリプトを実行するための資格情報を指定します。このスクリプトは，nnm.propertiesファイルを使用しない限り，有効なNNMi資格情報が必要です。詳細については，nnm.propertiesのリファレンスページを参照してください。

Listing connected neighbor interfaces for a node

findConnectedNeighborInterfacesByNodeクエリーを使用して，特定のノードに接続されたすべての隣接インタフェースをリストします。

このクエリーで利用可能な出力フィールドは，次のとおりです。

uuid，name，NodeUUID，NodeName，ifIndex, ifAlias, speed, inSpeed, outSpeed, ifDescr, ifName, ifType, physicalAddress および managementMode

Example

nnmtopoquery.ovpl findConnectedNeighborInterfacesByNode -node mynode -fields nodeName,name,physicalAddress,managementMode

Listing Layer 2 Connections for a Node

findL2ConnectionsByNode クエリーを使用して，特定のノードのすべてのレイヤー2接続をリストします。

このクエリーで利用可能な出力フィールドは，次のとおりです。

connUUID, connName, connStatus, connStatusTimestamp, localNodeUUID, localNodeName, localIfUUID, localIfIndex, localIfAlias, localIfName, localIfDesc, localIfAddr, remoteNodeUUID, remoteNodeName, remoteIfUUID, remoteIfIndex, remoteIfAlias, remoteIfName, remoteIfDesc および remoteIfAddr

Example

nnmtopoquery.ovpl findL2ConnectionsByNode -node mynode -fields connUUID,connName,localIfIndex,remoteIfIndex

Listing Web Agent Settings of a Node

findWebAgentSettingsByNode クエリーを使用して，特定のノードの Web Agent 設定をリストします。

このクエリーで利用可能な出力フィールドは，次のとおりです。

agentUuid, hostname, name, nodeUuid, nodeName, mode, agentEnabled, username, port, scheme, timeout, lastModifiedBy, lastModified, validTo および subjectDN

Example

nnmtopoquery.ovpl findWebAgentSettingsByNode -node mynode -fields agentUuid,hostName,nodeUuid,nodeName,mode,userName

Listing All Web Agent Settings

listWebAgentSettingsクエリーを使用して，すべてのWeb Agent設定をリストします。

このクエリーで利用可能な出力フィールドは，次のとおりです。

agentUuid, hostName, name, nodeUuid, nodeName, mode, agentEnabled, userName, port, scheme, timeout, lastModifiedBy および lastModified

Example

nnmtopoquery.ovpl listWebAgentSettings -node mynode -fields agentUuid,hostName,nodeUuid,nodeName,mode,userName

RETURN VALUE

nnmtopoquery.ovplエラーが発生しなければステータス0(ゼロ)，そうでなければ1で終了します。

AUTHOR

nnmtopoquery.ovpl was developed by Micro Focus.

付録G.59　nnmtrapconfig.ovpl

NNMi トラップサービスを構成します

SYNOPSIS

nnmtrapconfig.ovpl -u <username> -p <password> [-showProp] [-start] [-stop] [-readFilter] [-dumpBlockList] [-resetBlockCache]

nnmtrapconfig.ovpl -setProp -u <username> -p <password> [trapInterface <ip_addr>] [unsetTrapInterface] [trapPort <port>] [recvSocketBufSize <size>] [disallowV1V2] [allowV1V2] [loopbackAddrOverride <ip_addr>] [resetLoopbackAddrOverride] [blockTraps] [unblockTraps] [thresholdRate <rate>] [rearmRate <rate>] [overallThresholdRate <rate>] [overallRearmRate <rate>] [minTrapCount <count>] [databaseQSize <count>] [pipelineQSize <count>] [databaseFileSize <size>] [databaseFileCount <count>] [trapLoggingMode <log_mode>] [trapLoggingCompression <boolean>] [trapLoggingMaxFileSize <size>] [trapLoggingTaskInterval <time>] [trapLoggingBatchSize <size>] [trapReceiverNettyPort <port>] [trapReceiverJmsTTL <time miliseconds>] [-persist]

DESCRIPTION

nnmtrapconfig.ovplを使用すると，トラップサービスの現在のプロパティを表示したり変更したりできます。さらに，トラップサービスの起動や停止もできます。nnmtrapconfig.ovplは，フィルター構成ファイルの読み込み，現在のフィルター構成およびブロッキングキャッシュの印刷，ブロッキングキャッシュのリセットなどのフィルター関連機能も提供します。

Parameters

nnmtrapconfig.ovplコマンドは，次のパラメータをサポートします。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要な NNMi の管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-showProp

トラップサービスに関連付けられたプロパティ，および現在のプロパティ値を示します。

-start

トラップサービスを起動します。

注意：このコマンドは，JBossの中で実行されているトラップサーバーを起動します。スタンドアロンのトラップレシーバーの起動については，『NNMi NmsTrapReceiver プロセス』の章を参照してください。

-stop

トラップサービスを停止します。

注意：このコマンドは，JBossの中で実行されているトラップサーバーを停止します。スタンドアロンのトラップレシーバーの停止については，『NNMi NmsTrapReceiver プロセス』の章を参照してください。

-readFilter

トラップサービスにフィルター構成ファイルを読み込ませます。

-dumpBlockList

トラップサービスが作成するフィルター構成およびブロッキングキャッシュを印刷します。

-resetBlockCache

トラップサービスのブロッキングキャッシュをリセットします。

一つ以上のプロパティの値を設定する場合は，nnmtrapconfig.ovplに次のオプションを付けて実行してください。

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-setProp

トラップサービスに関連付けられたプロパティの値を設定します。

trapInterface ip_addr

トラップサービスがトラップをリッスンするIPアドレスを設定します。デフォルトでは，すべてのインタフェース上でリッスンします。

unsetTrapInterface

トラップサービスがすべてのインタフェース上でリッスンするよう設定します。

trapPort port

トラップサービスがトラップをリッスンするポートを設定します。デフォルトのポートは162です。

recvSocketBufSize size

トラップサービスがトラップをリッスンするソケットバッファのサイズをキロバイト単位で設定します。

disallowV1V2

受信するSNMPv1およびv2トラップをすべてブロックし，v3トラップのみを転送します。デフォルトで無効にされています。

allowV1V2

受信するSNMPトラップをv1およびv2を含めすべて受け付けます。これは，デフォルトです。

loopbackAddrOverride ip_addr

ソースアドレスがループバックアドレスである場合に，トラップを転送する前にトラップのソースアドレスと交換するIPアドレスを設定します。

resetLoopbackAddrOverride

ループバックオーバーライドアドレスをリセットします。このオプションを実行すると，ユーザー指定のループバックオーバーライドアドレスは削除されます。この場合，NNMiはサーバーのアドレスの一つをループバックオーバーライドアドレスとして選択します。

blockTraps

フィルター構成およびしきい値構成に基づいてトラップをブロックします。

unblockTraps

トラップをブロックしません。

thresholdRate rate

トラップの送信元やトラップのOIDをブロックするレートをトラップ/秒の形式で設定します。

rearmRate rate

ブロックされたトラップの送信元やトラップのOIDのブロックを解除するレートをトラップ/秒の形式で設定します。このレートは，thresholdRateの値以下である必要があります。

overallThresholdRate rate

すべての受信トラップをブロックする割合を，1秒あたりのトラップ数で設定します。

overallRearmRate rate

すべての受信トラップをブロック解除する割合を，1秒あたりのトラップ数で設定します。この値はoverallThresholdRateの値以下にしてください。

minTrapCountcount

最低何個のトラップをソースから受信したらブロッキングを検討するのかを設定します。また，同じトラップを最低何個受信したらブロッキングを検討するのかも設定してください。

databaseQSize count

トラップをデータベースに書き込む待ち行列に保持できる最大トラップ数を設定します。

pipelineQSize count

トラップパイプラインの各ステージの待ち行列に保持できる最大トラップ数を設定します。

databaseFileSize size

トラップデータベース内の一つのファイルの最大サイズをMB単位で設定します。ファイルサイズがこの値に到達すると，ロールオーバーが発生します。

databaseFileCount count

トラップデータベース内の最大ファイル数を設定します。

trapLoggingMode log_mode

トラップロガーの動作モードです。有効な値は，OFF，CSV，LOG，BOTHです。デフォルトはCSVです。

OFF:  すべてのトラップのロギングをオフにします。
CSV:  トラップは CSV 形式で記録されます。
LOG:  トラップは trapd.log に似たテキスト形式で記録されます。
BOTH: トラップは CSV 形式とテキスト形式の両方で記録されます。

trapLoggingCompressionboolean

trueの場合，トラップはgz圧縮形式で書き込まれます。デフォルトはfalseです。

trapLoggingMaxFileSize size

トラップログファイルのファイルサイズがMB単位の最大値に近づいた場合は，拡張子が.oldのファイルにまとめてアーカイブされます。拡張子が .old のファイルは，各ログ形式に1ファイルのみ保持されます。デフォルトは5MBです。

trapLoggingTaskInterval time

ファイルシステムにトラップを書き込む前にトラップロガーが待機する時間を秒単位で設定します。デフォルトは 2秒です。

trapLoggingBatchSize size

各間隔の間にファイルシステムに書き込まれるトラップの最大数を設定します。デフォルトは2048です。

trapReceiverNettyPortport

TrapReceiverでJBossからの接続を待機するポートを設定します。デフォルトは5447です。

trapReceiverJmsTTL time miliseconds

JMSメッセージのTTLをミリ秒単位で設定します。負の値は使用できません。これはトラップがTrapReceiverによってキャッシュされる時間です。JBossがこの時間以上ダウンした場合，データは失われます。デフォルトは5分（300000）です。

-persist

将来の再起動にプロパティ値を使用できるように，現在のプロパティを維持します。

EXAMPLES

トラップサービスに関連付けられたプロパティ，およびプロパティ値を示します。

nnmtrapconfig.ovpl -u user -p pass -showProp

トラップサービスを起動します。

nnmtrapconfig.ovpl -u user -p pass -start

トラップポートを1162に設定します。

nnmtrapconfig.ovpl -u user -p pass -setProp trapPort 1162

ログは両方のフォーマット，最大ファイルサイズは32MB，タスクの実行間隔は30秒，バッチサイズは1024の設定を使用してトラップを受信します。将来のトラップサービス起動用に現在の値も維持します。

nnmtrapconfig.ovpl -u user -p pass -setProp trapLoggingMode BOTH trapLoggingMaxFileSize 32 trapLoggingTaskInterval 30 trapLoggingBatchSize 1024 -persist

ブロッキングを有効にし，将来のトラップサービス起動用に現在の値を維持します。

nnmtrapconfig.ovpl -u user -p pass -setProp blockTraps -persist

将来のトラップサービス起動用に現在の値を維持します。

nnmtrapconfig.ovpl -u user -p pass -setProp -persist

FILES

NNMi トラップサービスプロパティは次に示すファイルに格納されています。

Windows：%NNM_PROPS%¥nnmtrapserver.properties

Linux：$NNM_PROPS/nnmtrapserver.properties

ブロッキングフィルターは次に示すファイルに設定できます。

Windows：%NNM_SHARED_CONF%¥nnmtrapd.conf

Linux：$NNM_SHARED_CONF/nnmtrapd.conf

AUTHOR

nnmtrapconfig.ovpl was developed by Micro Focus.

付録G.60　nnmtrapdump.ovpl

バイナリトラップストアにロギングされたトラップをコンソールに出力します

SYNOPSIS

nnmtrapdump.ovpl [-t] [-from date] [-to date] [-source IP address] [-trapid Trap OID] [-last minutes] [-short] [-nodns] [-hexDump]

DESCRIPTION

すべての受信トラップはNNMiトラップサービスによってバイナリトラップストアにロギングされます。nnmtrapdump.ovplは，ロギングされたトラップの確認に使用できます。新規受信トラップの監視にも使用できます。トラップツールを使用する場合，ログやエラーメッセージは標準出力には表示されません。標準エラー出力を別のファイルにリダイレクトすることで，実際のトラップダンプ出力とそれらのメッセージが混ざることを防止できます。

Parameters

nnmtrapdump.ovplコマンドは，次のパラメータをサポートします。

-t

受信トラップを連続して出力する場合に使用します。このオプションは-fromオプションと一緒に使用できます。

-from date

トラップ出力の開始日を指定します。日付はISO 8601標準形式：yyyy-mm-ddThh:mm:ss[+ or -]hh:mmで指定します。このオプションは-lastオプションと一緒には使用できません。

-to date

トラップ出力の終了日を指定します。日付はISO 8601標準形式：yyyy-mm-ddThh:mm:ss[+ or -]hh:mmで指定します。

-source IP address

出力するトラップのソースIPアドレスを指定します。指定されたソースのトラップだけが出力されます。

-trapid Trap OID

出力するトラップのトラップOIDを指定します。指定されたOIDを持つトラップだけが出力されます。

-last minutes

出力するトラップの期間を指定します。値は分単位です。指定した分数をさかのぼった時点から現在までのトラップが出力されます。このオプションは-fromオプションと一緒には使用できません。

-short

-shortを使用すると，受信したトラップを短い形式で表示します。OIDと到着時刻，送信元アドレスのみが表示されます。

-nodns

-nodnsを使用すると，IPアドレスの名前解決を抑止します。これは，トラップ出力を高速化します。

-hexDump

-hexDump を使用すると，16進形式でトラップを表示します。

EXAMPLES

バイナリトラップストアのすべてのトラップをコンソールに出力する場合

nnmtrapdump.ovpl

ループ状態で待って，すべての受信トラップを出力する場合

nnmtrapdump.ovpl -t

2008年7月31日，午前9:00から午前9:05（MDT）までの5分間枠のトラップを出力する場合

nnmtrapdump.ovpl -from 2008-07-31T09:00:00-06:00 -to 2008-07-31T09:05:00-06:00

過去5分間に受信したトラップを出力してから受信トラップを待つ場合

nnmtrapdump.ovpl -last 5 -t

IPアドレス 192.168.0.1 からのトラップを出力する場合

nnmtrapdump.ovpl -source 192.168.0.1

FILES

%NNM_DB%¥traps（Windows）または$NNM_DB/traps（Linux）は，トラップデータベースを構成するファイルが格納されたディレクトリです。

%NNM_LOG%¥nnm¥trapanalytics.log（Windows）または$NNM_LOG/nnm/trapanalytics.log（Linux）は，最もトラップ送信が多いトラップIDとソースに関する情報を含む分析ログファイルです。

AUTHOR

nnmtrapdump.ovpl was developed by Micro Focus.

付録G.61　nnmtrimincidents.ovpl

インシデントの削除および（必要に応じて）アーカイブへの保存

SYNOPSIS

nnmtrimincidents.ovpl [ [ [-age age -incr incr] | -date date | -trimOldest numberToTrim ] [-nature nature] [-lifecycle lifecycleState] [-severity severity] [-origin origin] [-name name] [-family family] [-sysobjectid sysobjectid] [-path path] [-archiveOnly] [-trimOnly] [-trimAndArchive] [-batch batchSize] [-u username] [-p password] [-quiet] ]

DESCRIPTION

nnmtrimincidents.ovpl は，インシデントをインシデントテーブルから削除するために使用します。削除されたインシデントは，（必要に応じて）圧縮されたアーカイブファイルに保存されます。

Windows：%NNM_DATA%¥tmp¥incidentArchive.ISO 8601 Date.Time Ms.csv.gz

Linux：$NNM_DATA/tmp/incidentArchive.ISO 8601 Date.Time Ms.csv.gz

デフォルトの動作では，アーカイブせずにインシデントを削除します。

ARCHIVE-FORMAT

インシデントは，csv 形式を使用してアーカイブされます。カラム名は，次のように並べられます。

LastOcurranceTimeStamp,Name,SourceNodeName,SourceObjectName,SysObjectID,FormattedMessage,LifeCycleState,Severity,Priority,AssignedTo,JournalNotes,Category,Family,Nature,Origin,IncidentNotes,DuplicateCount,FirstOccuranceTimeStamp,OriginOccuranceTimeStamp,PayloadList,ElementOID

LastOcurranceTimeStamp   - このインシデントが最後に発生した日時の読解可能な文字列形式のタイムスタンプ
Name             - インシデント名
SourceNodeName   - ソースノードの短縮名
SourceObjectName - ソースオブジェクト名
SysObjectID      - 常に空のこのフィールドは下位互換性のために維持されます
FormattedMessage - インシデントを説明するフォーマットされたメッセージ
LifeCycleState   - インシデントのライフサイクル状態
Severity         - インシデントの重大度
Priority         - インシデントの優先度をローカライズしたラベル
AssignedTo       - インシデントを割り当てられているアカウント
JournalNotes     - インシデントの注
Category         - インシデントのカテゴリをローカライズしたラベル
Family           - インシデントのファミリーをローカライズしたラベル
Nature           - インシデントの相関特性処理
Origin           - インシデントの発生元
IncidentNotes    - 相関処理の注
DuplicateCount   - システムでインシデントが発生した回数
FirstOccuranceTimeStamp  - 重複したインシデントの場合の最初の発生日時
OriginOccuranceTimeStamp - トラップ/syslog がシステムに到達したときのタイムスタンプ（該当する場合）
PayloadList: すべての CIA（"Name[Type]=Value" の形式で，複数の CIA がある場合は「|」で区切られます）
       Name      - CIA の名前（最大 50 文字）
       Type      - CIA のタイプ
       Value     - CIA の値（最大 2000 文字）
ElementOID       - インシデントの OID（存在する場合）

Parameters

-age age

削除するインシデントの時間を指定します。このオプションはincrオプションと一緒に使用してください。ageには必ず0より大きい値を指定してください。

-incr incr

ageオプションの増加単位を指定します。サポートされている増加単位はhours（時間），days（日），weeks（週），months（月）です。

-trimOldest numberToTrim

データベースから削除するインシデントの数を指定します。指定したオプションに基づいて，最も古いnumberToTrimインシデントがデータベース内のすべてのインシデントから選択されます。

-date date

日付を指定し，その日付より古いインシデントが削除されます。日付はISO 8601標準形式yyyy-mm-ddThh:mm:ss[+ or -]hh:mmで指定します。

-archiveOnly

アーカイブファイルを作成しますが，インシデントは削除しません。このオプションはage オプションまたは dateオプションと共に指定する必要があります。

-trimOnly

インシデントを削除しますが，削除されたインシデントはアーカイブに保存しません。これはデフォルトの動作です。

-trimAndArchive

削除対象のインシデントをアーカイブして，削除します。

-batch batchSize

インシデントを削除するときのバッチサイズを指定します。0より大きく，1000以下の値が指定できます。

-path path

アーカイブファイル名を完全パスで指定します。このパスはデフォルトのアーカイブファイルより優先されます。

Windows： %NNM_DATA%¥tmp¥incidentArchive.ISO 8601 Date.Time Ms.csv.gz

Linux：$NNM_DATA/tmp/incidentArchive.ISO 8601 Date.Time Ms.csv.gz

-lifecycle lifecycleState

削除対象のageまたはdateに一致するインシデントのライフサイクル状態を指定します。

lifecycleStateの例としては次のものがあります。

Registered（登録済み）

InProgress（進行中）

Completed（完了）

Closed（解決済み）

-severity severity

削除対象のageまたはdateに一致するインシデントの重大度を指定します。

severityの例としては次のものがあります。

Critical（危険域）

Major（重要警戒域）

Minor（警戒域）

Warning（注意域）

Normal（正常域）

-name name

削除対象のageまたはdateに一致するインシデント名を指定します。

-family family

削除対象のageまたはdateに一致するインシデントのファミリーの「一意のキー」を指定します。

-sysobjectid sysobjectid

削除対象のageまたはdateに一致するインシデントのデバイスのシステムオブジェクトIDを指定します。

-nature nature

削除対象のageまたはdateに一致するインシデントの相関処理特性を指定します。

natureの例としては次のものがあります。

RootCause（根本原因）

SecondaryRootCause（二次的な根本原因）

Symptom（症状）

ServiceImpact（サービスインパクト）

StreamCorrelation（ストリームの相関処理）

None（なし）

Info（情報）

Dedup_Stream_Correlation（重複削除ストリームの相関処理）

Rate_Stream_Correlation（レートストリームの相関処理）

-origin origin

削除対象のageまたはdateに一致するインシデントの発生元を指定します。

originの例としては次のものがあります。

ManagementSoftware（NNMi）

ManuallyCreated（手動作成）

RemotelyGenerated（遠隔生成）

SnmpTrap（SNMPトラップ）

Syslog（システムログ）

Other（その他）

-u <username>

コマンドの実行に必要なNNMiの管理者名を指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-p <password>

コマンドの実行に必要なNNMiの管理者パスワードを指定します。nnm.propertiesファイルが存在していない限り，これが必要になります。詳細はnnm.propertiesリファレンスページを参照してください。

-quiet

非プロンプトモードを指定します。

EXAMPLES

6日前より古いインシデントを削除します。

nnmtrimincidents.ovpl -age 6 -incr days

6週間より古い，相関処理特性が Symptom のインシデントを削除します。

nnmtrimincidents.ovpl -age 6 -incr weeks -nature Symptom

6か月より古い，ライフサイクル状態が Closed のインシデントを削除します。

nnmtrimincidents.ovpl -age 6 -incr months -lifecycle Closed

6か月より古い，重大度が Normal のインシデントを削除します。

nnmtrimincidents.ovpl -age 6 -incr months -severity Normal

指定日付より古いインシデントを削除します。

nnmtrimincidents.ovpl -date 2007-07-16T19:20:30

指定日付より古い，相関処理特性が Symptom のインシデントを削除します。

nnmtrimincidents.ovpl -date 2007-07-16T19:20:30+01:00 -nature Symptom

指定日付より古い，ライフサイクル状態が Closed のインシデントを削除します。

nnmtrimincidents.ovpl -date 2007-07-16T19:20:30-01:00 -lifecycle Closed

6日前より古いインシデントを削除し，アーカイブ用に指定したファイル名を使って，アーカイブに保存します。

nnmtrimincidents.ovpl -trimAndArchive -age 6 -incr days -path "C:¥BkupDir¥saveIncidents.gz"

6日前より古いインシデントを削除します（アーカイブへの保存はしません）。

nnmtrimincidents.ovpl -age 6 -incr days

相関処理特性が Symptom の最も古い10,000個の SNMP トラップを削除します。

nnmtrimincidents.ovpl -trimOldest 10000 -nature Symptom -origin SnmpTrap

6日前より古いインシデントを削除します（アーカイブへの保存はしません）。

nnmtrimincidents.ovpl -trimOnly -age 6 -incr days

6日前より古いインシデントをアーカイブに保存します（削除はしません）。

nnmtrimincidents.ovpl -archiveOnly -age 6 -incr days

6日前より古いインシデントを削除し，アーカイブに保存します。

nnmtrimincidents.ovpl -trimAndArchive -age 6 -incr days

AUTHOR

nnmtrimincidents.ovpl was developed by Micro Focus.

SEE ALSO

nnm.properties

付録G.62　ovjboss

jbossアプリケーションサーバーのラッパー

SYNOPSIS

ovjboss

DESCRIPTION

ovjbossはovspmdの管理下にあるサービスコンポーネントです。ovjbossは，%NNM_DATA%¥shared¥nnm¥conf¥props（Windows）または$NNM_DATA/shared/nnm/conf/props（Linux）ディレクトリにあるプロパティファイル（nms-support.properties，nms-jboss.propertiesおよびovjboss.jvmargs）を使用してjbossアプリケーションサーバーに引数を渡します。各ファイルには，制御する設定の変更方法を記載した資料が格納されています。

このコマンドは絶対に直接実行してはいけませんが，ovspmdの管理下にあります。このコマンドはovstartまたはovstart -c ovjbossの実行時に起動されます。このコマンドを停止するには，ovstopまたはovstop -c ovjbossを実行してください。このコマンドが監視している内部サービスの状態を参照するには，ovstatus -v ovjbossを呼び出してください。

ovbjossの起動に問題がある場合，ovjboss.logおよびnnm.logログファイルを参照して，問題解決に役立つ情報があるかどうか確認できます。

EXAMPLES

ovjbossを含めたNNMiを起動するには，次のコマンドを実行します。

ovstart

ovjbossだけを起動するには，次のコマンドを実行します。

ovstart -c ovjboss

ovjbossが起動したサービスの状態を参照するには，次のコマンドを実行します。

ovstatus -v ovjboss

AUTHOR

ovjboss was developed by Micro Focus.

FILES

Windows：%NNM_DATA%¥shared¥nnm¥conf¥props¥nms-jboss.properties

Linux：$NNM_DATA/shared/nnm/conf/props/nms-jboss.properties

ovjboss内部で起動したサービスが使用するパラメータファイル

Windows：%NNM_DATA%¥shared¥nnm¥conf¥props¥nms-support.properties

Linux：$NNM_DATA/shared/nnm/conf/props/nms-support.properties

ovjboss内部で起動したサービスが使用するパラメータファイル

Windows：%NNM_DATA%¥shared¥nnm¥conf¥props¥ovjboss.jvmargs

Linux：$NNM_DATA/shared/nnm/conf/props/ovjboss.jvmargs

jbossを実行するJVMに渡すパラメータ

Windows：%NNM_DATA%¥Conf¥nnm¥props¥nms-local.properties

Linux：$NNM_DATA/conf/nnm/props/nms-local.properties

ポートの設定を含むローカル設定ファイル

Windows：%NNM_DATA%¥log¥nnm¥nnm.log

Linux：$NNM_DATA/log/nnm/nnm.log

（あれば）例外を格納するログファイル

Windows：%NNM_DATA%¥log¥nnm¥ovjboss.log

Linux：$NNM_DATA/log/nnm/ovjboss.log

標準エラー出力メッセージを格納するログファイル

SEE ALSO

ovspmd

nnm.ports

付録G.63　ovspmd

NNMi プロセス管理サービス

SYNOPSIS

ovspmd [ [install] [start] [stop] [remove] [-W] [-d] [-V] [-f startup_file] ]

DESCRIPTION

ovspmdはNNMiの一部である各サービスプロセスを管理します。ovspmdはovstart，ovstop，およびovstatusからの要求に応じてこれらプロセスの起動，停止，状態の報告を行います。通常，ovspmdはovstartが自動的に起動します。Windowsでは，ovspmdはサービスとして登録されています。ovspmdはサービス名HP OpenView Process Manager 配下に登録します。

ovstartは，NNMi起動ファイル（SUF）に指定したオブジェクトマネージャプログラムの開始要求をovspmdに送信します。SUFのデフォルトはovsufです。NNMi管理対象プロセスはローカル登録ファイル（LRF）で構成され，ovaddobjによってSUFに追加されます。引数なしでovstartを呼び出した場合，ovspmdは自動的に起動するように構成された（つまり初期開始フラグOVs_YES_STARTをLRFに設定した）すべての管理対象プロセスを起動します。

ovstopは構成済みの管理対象プロセスの停止要求をovspmdに送信します。ovstopを引数なしで呼び出す場合，ovspmdは現在実行中のすべての管理対象プロセスを停止，終了します。

ovstatusは，構成済みの管理対象プロセスの現在の実行状態の報告要求をovspmdに送信します。

管理対象プロセスはovspmdによってサービスとして（つまり標準入力，標準出力，標準エラー出力のすべてを無視した状態のバックグラウンドで）起動されます。

各管理対象プロセスは，依存関係リスト（プロセスの起動を成功させるためにあらかじめ起動しておく必要がある他プロセスのリスト）を付けて構成できます。ovspmdは管理対象プロセスが依存しているすべてのプロセスの初期化が成功していなければ，その管理対象プロセスを起動しません。起動時には，ovspmd はLRF指定の依存関係が循環形式になっていないことを確認します。（循環例は A -> B -> C -> Aです。）この依存関係で，起動の相対的な順序付けも停止の逆順序も決定します。

ovspmd には，予期せず失敗したプロセスを自動的に再起動する仕組みがあります。このプロセスでは，%NNM_SHARED_CONF%¥ovspmd.restart.propertiesファイル（Windows），または，$NNM_SHARED_CONF/ovspmd.restart.propertiesファイル（Linux）に一覧表示しているようにデーモンプロセスのリトライ数を追加する必要があります。デフォルトでは，リトライ数は0です。プロセスが予期せず終了すると，この数が0に達するまで一つずつ減ります。その時点では，プロセスは自動的に再起動されません。

ovstartでプロセスを起動しようとすると，リトライ数がリセットされ，プロセスが再度起動されます。プロセスが2時間実行を続けた場合，そのプロセスはリトライカウンターをリセットします。エントリを削除すると，ovspmdは再起動を行わなくなります。これはリトライ数が0である場合にも当てはまります。

ovspmdはオブジェクトマネージャの三つのクラスを区別します。

OVs_WELL_BEHAVED

well-behavedなプロセスはOVsPMD API（OVsPMD_API(3)参照）を使ってovspmdと通信します。このプロセスは，初期化の成否や正常終了と異常終了に関するovspmd状態情報を送信するように構成されている場合は，これらの情報を送信します。well-behavedなプロセスから初期化の成功が明示的に報告された場合にのみ，ovspmdはこのプロセスの初期化が成功したと見なします。また，well-behavedなプロセスは，ovspmdからOVS_CMD_EXITコマンドを受信したときに終了します。

管理対象プロセスがovspmdに渡した状態情報は，ovstart，ovstop，ovstatusのうち現在実行中のものに転送されます。各管理対象プロセスから受信した最後のメッセージは，保存されてから，要求があり次第ovstatusに転送されます。well-behavedなプロセスから受信したメッセージもアプリケーションイベントログ（イベントビューアで調べることができます）にロギングされます。

OVs_NON_WELL_BEHAVED

ovspmdはOVsPMDAPI(non-well-behaved processes)を使わないオブジェクトマネージャ（non-well-behavedなプロセス）が自発的にバックグラウンドに突入しない場合に限り，これらも管理できます（下記OVs_DAEMONを参照）。non-well-behaved なプロセスは状態メッセージを返さないので，ovspmdはこのようなプロセスが LRF 指定のタイムアウト時間内に終了しなくても，プロセスの初期化が成功したものと見なします。

設定されたタイムアウト内に non-well-behavedなプロセスが終了しない場合は，Terminal Processで終了されます。

OVs_DAEMON

バックグラウンドに突入する管理対象プロセスは，通信チャネルまたは信号を使って管理できません。ovspmdはこのようなプロセスを起動できますが，必要な通信チャネルもプロセスIDもないので，プロセスを停止したり意味のある状態を報告したりできません。

Parameters

install

ovspmd をサービスとしてインストールします。

start

ovspmdサービスを起動します。

stop

ovspmdサービスを停止します。

remove

ovspmd サービスを削除します。

-W

ovspmdの起動時に管理対象プロセスを起動しません。ovstartからの起動要求を待ちます。

-d

デバッグ用に使用します。このオプションを使用した場合，ovspmdはサービスになりません。

-V

超冗長モードで実行します。このモードでは，ovspmdは管理対象プロセスの構成に関する非常に詳しい情報を出力します。これは通常の使用では詳細過ぎる情報です。

-f startup_file

デフォルトではなくstartup_fileを起動ファイル（SUF）として読み込みます。なお，startup_fileは絶対パスである必要があります。

Application Authorization

ovspmdはNNMiサービスの管理を統制します。ovspmdはどのホスト，ユーザー，アプリケーションがNNMiサービスを起動および停止できるのかをovspmd.authファイルを使って制御します。ovspmd.authファイルの格納場所は%NNM_SHARED_CONF%（Windows）または$NNM_SHARED_CONF（Linux）です。

ovspmdはovspmd.authファイルのエントリを先頭から終わりまで検索します。検討中のアクセスを明示的に許可または拒否しているエントリを見つけ次第，ovspmdは検索を中止します。従って，より具体的なエントリのほうが一般的なエントリより優先されます。

ファイルには，権限があるホスト，ユーザー，およびアプリケーションを指定する行が含まれています。各行には，ovspmdへの接続権限がある単一のホスト，ユーザー，およびアプリケーションリストを表示します。ファイルの各行の形式は次のとおりです。

#comment

hostname [username [appname1 appname2 appname3... ]]

ナンバー記号（#）およびそれに続く部分はコメントであり，無視されます。空白行も無視されます。

usernameとappnameは任意指定です。アプリケーションを指定しない場合，その行はどのアプリケーションからのアクセスも許可（または拒否）します。ユーザー名を指定しない場合，その行はどのアプリケーションで動作しているどのユーザーからのアクセスも許可（または拒否）します。

hostnameにプラス記号（+）を指定すると，その行はどのホストからのアクセスも参照します。usernameにプラス記号（+）を指定すると，その行はどのユーザーからのアクセスも参照します。hostnameの先頭にマイナス記号（-）を指定すると，その行はそのホストからのすべてのアクセスを明示的に拒否します（同じ行にユーザー名やアプリケーション名が指定されていても無視されます）。usernameの先頭にマイナス記号（-）を指定すると，その行は指定ホストのユーザーによるアクセスを明示的に拒否します（同じ行にアプリケーション名が指定されていても無視されます）。

アプリケーションが一覧表示されている場合，その行は表示されたアプリケーションへの（指定ホストからの指定ユーザーによる）アクセスだけを許可します。登録アプリケーション名に含まれる空白はアンダースコアに置換する必要があるという点を除いて，権限ファイルに一覧表示されたアプリケーション名はアプリケーションの登録名に一致しなければならないことに注意してください。

インストール時に作成されるovspmd.auth ファイルには，ファイル形式の例がさらに格納されており，いくつかの例は「EXAMPLES」の項にも記載されています。

DIAGNOSTICS

ovspmdは構成エラーおよびシステム呼び出し障害に関するエラーメッセージを発行します。これらのメッセージは内容が一目瞭然であることを目的としています。ovspmdが現在ovstart，ovstop，ovstatusのいずれかとオープン通信チャネルを持っている場合，ovspmdはこれらのエラーメッセージをプログラムが出力する通信チャネル経由で転送します。

ovspmdは複数の要求（start，stop，status）を一度に処理できます。追加の要求は現在の要求が完了するまでタイプ別に待ち行列に入れられます。

さらに，ovspmdはERRORレベルのOVSサブシステム内の nettl を使って，処理，構成，システムエラーなどをロギングします。初期化成功などの通常イベントを示すメッセージはINFORMATIVEレベルでロギングされます。初期化失敗または異常終了を示すメッセージはWARNINGレベルでロギングされます。

EXAMPLES

ovspmd.authファイルの内容例を次に示します。

# Normally, you should authorize any application
# run by any user on the same host on which ovspmd is running.
# To do so, use a single line listing the
# name of the host on which this file is located
# (for example, "thishost"):

thishost

# Similarly, if you are running Management
# Consoles, you should authorize any application
# run by any user on all the client hosts and on
# the server host. For example, if your server
# system named "bigsystem" has one client named
# "hohum", list each of them on a separate line in
# this file on bigsystem:

bigsystem
hohum

# It is possible to permit specific users to run
# specific applications from a remote system. The
# following line permits the user "shem" from host
# "blimp" to run the applications "Toaster Manager"
# and "Blender". Note that, because the application's
# registered name "Toaster Manager" contains white
# space, you must replace the whitespace with the
# underscore character in the authorization file:

shem blimp Toaster_Manager Blender

# It is not possible to exclude specific applications,
# except by explicitly permitting all non-excluded
# applications.

# The following line denies access by the user "fred"
# from any host:

+ -fred

# The following line denies any application access
# from the host "badguy":

-badguy

AUTHOR

ovspmd was developed by Micro Focus.

FILES

次に示すファイルの環境変数の使用については，nnm.envvarsリファレンスページを参照してください。

Windows：

%NNM_BIN%¥ovspmd

%NNM_SHARED_CONF%¥ovsuf

Linux：

$NNM_BIN/ovspmd

$NNM_SHARED_CONF/ovsuf

再起動プロパティ構成については，%NNM_SHARED_CONF%¥ovspmd.restart.properties（Windows）または$NNM_SHARED_CONF/ovspmd.restart.properties（Linux）を参照してください。

EXTERNAL INFLUENCES

Environmental Variables

$LANGは，国際化変数 LC_ALL，LC_CTYPE，LC_MESSAGESが未設定，NULL，または無効な場合にデフォルト値を提供します。

$LANGが未設定，NULL，または無効な場合，デフォルト値のC（Windowsの場合English_UnitedStates.1252）が使用されます。

LC_ALL（または$LANG）はovspmdが起動したほかのすべてのプロセスのロケールを決定します。

LC_CTYPEは，テキストをシングルバイト文字，マルチバイト文字，あるいはその両方として解釈すること，文字の分類は印刷可能とすること，正規表現の文字クラス表現によって文字を一致させることを決定します。

LC_MESSAGESは，メッセージを表示する言語を決定します。

他のすべての環境変数はovspmdを実行しているシェル（またはovspmdを起動した初回 ovstart）から引き継がれます。ovspmdおよびすべてのサービスプロセスはこの環境を共有します。結果として，環境変更を有効にするためには ovspmd を停止し，再起動する必要があります（ovstart参照）。

SEE ALSO

ovstatus, ovstart, ovstop, nnmcluster.

付録G.64　ovstart

NNMi 管理対象プロセスの起動

SYNOPSIS

ovstart [ [-c] [-d] [-o ovspmd_path] [-v] [--] [ovspmd_options...] [managed_process_names...] ]

DESCRIPTION

ovstartはNNMi 監視対象プロセスを起動します。一つ以上のmanaged_process_name引数を指定して呼び出された場合，ovstartは指定した管理対象プロセスが依存している他の管理対象プロセスを最初に起動してから，指定した管理対象プロセスを起動します。引数なしで呼び出された場合，ovstartはデフォルトで起動するように構成されているすべての管理対象プロセスを起動します。

ovstartは，起動しようとしたすべての管理対象プロセスが応答またはタイムアウト（LRF指定のタイムアウト時間内の応答に失敗）するまで終了しません。デフォルトでは，ovstartは，管理対象プロセスが失敗するまで出力を作成しません。ovstartをコマンドラインから実行した場合は，操作の進捗を把握するために-cまたは-vオプションを使用するとよいでしょう。前回のが成功した後でovstartを再度起動してもまったく害はありません。

ovstartは，起動要求（OVS_REQ_START）をプロセス管理サービスであるovspmdに送信します。ovspmdがまだ起動中でない場合，ovstartはまずこれを起動します。

ovstartはWindowsシステムの管理者またはLinuxシステムのrootが実行する必要があります。

管理対象プロセスはovaddobjによってローカル登録ファイルの情報から構成されます。管理対象プロセスは，その管理対象プロセスを記述しているLRFの第1フィールドによって命名されます。

NNMiクラスタ（nnmcluster参照）用に構成されたノードでovstartを使用した場合，ovstartの動作は上記とは異なります。具体的に言うと，ovstartは"nnmcluster -daemon"コマンドとまったく同じ動作をします。

NNMiクラスタ環境では，ovstartは（バックグラウンドのNNMiクラスタを起動後）すぐに返ります。その代わりに，nnmcluster コマンドがほかのNNMiプロセスを起動するかどうか，またはいつ起動するのかを決定します。ovstatus出力を監視して，NNMiプロセスの起動が完了したかどうか判断してください。

NNMiクラスタ環境では，ovstartのほかのコマンドラインオプションはサポートしていません。

なお，NNMiクラスタ属性をきめ細かく制御するために，nnmclusterコマンドを直接使用してください。NNMiクラスタ環境でのovstartコマンドは，よく知られたコマンドを使ってNNMiを起動する場合の便宜のために提供されています。

Parameters

ovstartコマンドは，次のオプションをサポートします。サポートされないオプションを指定した場合，使用方法のメッセージが表示されます。

-c

各管理対象プロセスの成否に関する1行分の情報を作成します。

-d

ovspmdの起動，連絡，および起動要求の送信，および通信チャネルの閉鎖を含む処理の重要な段階を報告します。

-o ovspmd_path

ovspmdの実行可能ファイルをデフォルト位置（Windowsの場合：%NNM_BIN%，Linuxの場合：$NNM_BIN）ではなくovspmd_pathに格納するように指定します。ovspmdが既に起動中の場合は，このオプションは無視されます。

-v

各管理対象プロセスの成否に関する複数行の情報を作成します。

- ovspmd_options

ovstartに知られていないオプションがあればovspmdに渡します。-dオプションは両方のプログラムに対して有効なので，ovstartオプションと解釈され，ovspmdには渡されません。同様に，-Vオプションはovstartに対して有効ではないので，ovspmdに渡されます。オプションがどちらにも認識されない場合，使用方法メッセージは ovstartからではなくovspmdから出力されます。

--

ovstartコマンドラインのoptionsセクションを終了します。コメントトークン（--）の後のすべての引数は，起動する管理対象プロセス名と解釈され，ovspmdに渡されます。

RETURN VALUE

非NNMiクラスタ環境では，ovstartは起動に成功しなかったオブジェクトマネージャ数を開始行から示す状態で終了します。要求されたすべての管理対象プロセスが起動に成功した場合，ovstartはステータス0（ゼロ）で終了します。

NNMiクラスタ環境では，ovstartは常にステータス0（ゼロ）で即時終了します。

DIAGNOSTICS

ovstartは特定のコマンドラインエラー（特に引数過多）およびシステムエラーを報告します。メッセージの先頭には「ovstart:」が付与され，内容が一目瞭然であることを目的としています。ovstartはovspmdから受信したエラーメッセージも出力します。これらのメッセージの先頭には「ovspmd:」が付与されます。ovstartはサポートしていないオプションをエラーとして扱いませんが，ovspmdはこれらをエラーとして扱います。

ovspmdは複数の要求（ovstart，ovstop，ovstatus）を一度に処理できることに注意してください。これらのコマンドのどれかが処理中の場合，新規要求は前回のコマンドが完了するまでタイプ別に待ち行列に入れられます。

EXAMPLES

ovstart

デフォルトで起動するように構成されているすべての管理対象プロセスの起動をovspmdに要求します。ovspmdがまだ起動中でない場合，オプションなしでこれを起動します。失敗のみが報告されます。

ovstart -v -V -- ovjboss

ovjbossプロセスの起動をovspmdに要求します。これにより，ovjbossプロセスが依存しているほかの管理対象プロセスを最初に起動してから，JbossアプリケーションサーバーおよびJboss内で一緒に展開されているすべてのNNMiサービスが起動されます。ovspmdがまだ起動中でない場合，冗長モードで起動します（-Vオプション）。プログラム起動の成否を報告します（-vオプション）。ovstartがovjbossをサポートされていない-Vオプションの引数と解釈しないように，コメントトークン（--）オプションが必要であることに注意してください。

AUTHOR

ovstart was developed by Micro Focus.

FILES

次に示すファイルの環境変数の使用については，nnm.envvarsリファレンスページを参照してください。

Windows：

%NNM_BIN%¥ovstart

%NNM_BIN%¥ovspmd

Linux：

$NNM_BIN/ovstart

$NNM_BIN/ovspmd

EXTERNAL INFLUENCES

Environmental Variables

$LANGは，国際化変数LC_ALL, LC_CTYPE, LC_MESSAGESが未設定，NULL，または無効な場合にデフォルト値を提供します。

$LANGが未設定，NULL，または無効な場合，デフォルト値のC（Windowsの場合English_UnitedStates.1252）が使用されます。

LC_ALL（または$LANG）はovspmdが起動したほかのすべてのプロセスのロケールを決定します。

LC_CTYPEは，テキストをシングルバイト文字，マルチバイト文字，あるいはその両方として解釈すること，文字の分類は印刷可能とすること，正規表現の文字クラス表現によって文字を一致させることを決定します。

LC_MESSAGESは，メッセージを表示する言語を決定します。

ovstartが実行され，かつ現在実行中のovspmdプロセスがない場合，ovspmdは実行シェルの環境を引き継ぎます。ovspmdが起動したすべての管理対象プロセスはこの同じ環境を引き継ぎます。

ovspmdまたは管理対象プロセスの環境を変更するには，正しい環境でovspmdを再起動する必要があります。このためには，すべての管理対象プロセスを停止する必要があります（ovspmdはすべての管理対象プロセスがシャットダウンされるまで終了しません）。

結果として，ovstartまたはovspmdから起動した管理対象プロセスの環境を変更するには，下記を実行する必要があります。

引数なしでovstopを実行して，すべての管理対象プロセスおよびovspmdをシャットダウンします。

正しい環境変数を設定します。

ovstartを実行して，ovspmdおよび一部またはすべての管理対象プロセスを再起動します。

NNMi Cluster

com.hp.ov.nms.cluster.nameが%NNM_DATA%¥shared¥nnm¥conf¥props¥nms-cluster.propertiesファイル（Windowsの場合）または，$NNM_DATA/shared/nnm/conf/props/nms-cluster.propertiesファイル（Linuxの場合）で定義されている場合，ovstartは起動をnnmclusterコマンドに任せます。

SEE ALSO

ovstatus, ovstop, ovspmd, nnmcluster.

付録G.65　ovstop

NNMi 管理対象プロセスの停止

SYNOPSIS

ovstop [ [-c] [-d] [-v] [ managed_process_names...] ] [ [-failover|-nofailover|-cluster] ]

DESCRIPTION

ovstopはNNMi監視対象プロセスを停止します。ovstop は停止要求（OVS_REQ_STOP）をプロセス管理プロセス（Linuxオペレーティングシステム）またはサービス（Windowsオペレーティングシステム）であるovspmdに送信します。一つ以上の managed_process_name引数で呼び出された場合，ovstop は最初に依存プロセスの一つを停止してから，指定した管理対象プロセスを停止します。引数なしで呼び出された場合，または名前付き引数の一つがovspmd である場合，ovstopはovspmd 自身を含む現在実行中のすべての管理対象プロセスを停止します。

LRFで指定したタイムアウト時間内に管理対象プロセスがovstop要求に対して応答しない場合，ovspmdはプロセスに終了信号をSIGTERM，SIGKILL（kill参照）の順で送信することによってプロセスを強制終了します。ovstopが強制終了を報告するのは，-vまたは-cオプションを使用している時（例えばovstop -v [managed_process_name]）だけですので注意してください。停止要求時に管理対象プロセスがタイムアウトした場合は，すぐにタイムアウト値を大きくするとよいでしょう。プロセスがovstop要求に応答するまでovspmdが待つ時間（秒）を大きくするには，%NNM_LRF%¥ov*（Windowsオペレーティングシステム）または$NNM_LRF/ov*（Linuxオペレーティングシステム）の指示に従ってください。

ovstartとは異なり，ovstopはovspmdが既に起動中ではなくてもこれを起動しません。

管理対象プロセスはovaddobjによってローカル登録ファイルの情報から構成されます。管理対象プロセスは，その管理対象プロセスを記述しているLRFの第1フィールドによって命名されます。ovstartと同様，ovstopはLRFにある依存情報を使用します。ほかの管理対象プロセスが，停止している管理対象プロセスに依存する場合，ovspmdは依存関係を記録し，適切なすべての管理対象プロセスをLRFの依存順序とは逆の順序で終了します。

ovstopはWindowsオペレーティングシステムの管理者またはLinuxオペレーティングシステムのrootが実行する必要があります。

OVs_DAEMONプロセスがLRFエントリ内のStop Commandを用いて構成される場合，ovstopはコマンドを実行します。この機能はovspmdとはもう連絡していないプロセスの停止に使用します。Stop Commandは必要に応じてプロセスの開発者が提供し，構成します。

前回のovstart操作で起動されたNNMi管理対象プロセスの名前は，ovstatus -cコマンドの実行によって取得できます。

ovstop ovjbossコマンドはJbossアプリケーションサーバーおよびJboss内で一緒に展開されたすべてのNNMiサービスを停止します。Jboss展開されたNNMiサービスの名前はovstatus -v ovjbossコマンドの実行によって取得できます。ovstop ovjbossの実行によって，すべてのNNMiサービスの停止のみが可能です。一部のNNMiサービスをほかのNNMiサービスとは無関係に個別に停止するということはサポートしていません。

NNMiクラスタ（nnmcluster参照）用に構成されたノードでovstopを使用した場合，ovstopの動作は上記とは異なります。具体的に言うと，ovstop（パラメータ指定なし）は"nnmcluster -disable -shutdown"コマンドとまったく同じ動作をします。

NNMiクラスタ環境では，ovstopは（バックグラウンドのNNMiクラスタにシャットダウン信号を送信後）すぐに返ります。次にnnmclusterコマンドが，スタンバイクラスタノードへのNNMiサービスのフェイルオーバーの契機となり得るNNMiプロセスをシャットダウンします。ovstatusの出力を監視して，NNMiプロセスがシャットダウンを完了したかどうか判断してください。

NNMiクラスタ環境では，ovstopが認識するコマンドラインオプションは-failover, -nofailover,-clusterだけです。

なお，NNMiクラスタ属性をきめ細かく制御するために，nnmclusterコマンドを直接使用してください。NNMiクラスタ環境でのovstopコマンドは，よく知られたコマンドを使ってNNMiサービスをシャットダウンする場合の便宜のために提供されています。

Parameters

ovstopコマンドは，次のオプションをサポートします。オプションではない第1引数と，以降のすべての引数は停止させる管理対象プロセスの名前として解釈され，停止要求でovspmdに渡されます。

-c

各管理対象プロセスの成否に関する1行分の情報を作成します。

-d

ovspmdへの連絡と停止要求の送信，および通信チャネルの閉鎖を含む処理の重要な段階を報告します。

-v

各管理対象プロセスの成否に関する複数行の情報を作成します。

-failover

（NNMiクラスタのみ）ローカルNNMiノード（アクティブノードである場合）に各NNMiプロセスをシャットダウンさせ，NNMiクラスタプロセスを終了します。同時に，自動フェイルオーバーを有効にしてNNMiサービスがスタンバイノードに移動するようにします。

-nofailover

（NNMiクラスタのみ）ローカルNNMiノード（アクティブノードである場合）に各NNMiプロセスをシャットダウンさせ，NNMiクラスタプロセスを終了します。同時に，自動フェイルオーバーを無効にしてNNMiサービスがスタンバイノードに移動しないようにします。

-cluster

（NNMiクラスタのみ）NNMiクラスタ内の全ノードをシャットダウンさせます。スタンバイノードのNNMiクラスタプロセスは最初にシャットダウンされ，次にアクティブノードがNNMiサービスを停止し，最後に現用ノードのNNMiクラスタプロセスがシャットダウンします。

RETURN VALUE

ovstopは，停止に成功しなかった管理対象プロセス数を示す状態で終了します。要求されたすべての管理対象プロセスが停止に成功した場合，ovstopはステータス0（ゼロ）で終了します。

DIAGNOSTICS

ovstopは特定のコマンドラインエラー（特に引数過多）およびシステムエラーを報告します。メッセージの先頭には「ovstop:」が付与され，内容が一目瞭然であることを目的としています。ovstopはovspmdから受信したエラーメッセージも出力します。これらのメッセージの先頭には「ovspmd:」が付与されます。ovstopはサポートしていないオプションは無視します。

管理対象プロセスの状態がPAUSED,PAUSE_ERROR,PAUSE_TIMEOUT,RESUME_ERROR,RESUME_TIMEOUT,またはDEPENDENCY_ERRのいずれかである場合，その管理対象プロセスは停止されます。ただし，警告メッセージが印刷されて，実行中状態ではないプロセスに対してovstopが使われたことを通知します。

ovspmdは複数の要求(ovstart,ovstop,ovstatus)を一度に処理できることに注意してください。これらのコマンドのどれかが処理中の場合，新規要求は前回のコマンドが完了するまでタイプ別に待ち行列に入れられます。

AUTHOR

ovstop was developed by Micro Focus.

FILES

次に示す環境変数は，お使いのシェルおよびプラットフォーム要件に応じて確立された汎用パス名を表します。お使いのプラットフォームおよびシェルの汎用パス名については，nnm.envvarsリファレンスページを参照してください。

次に示すファイルの環境変数の使用については，nnm.envvarsリファレンスページを参照してください。

Windows：

%NNM_BIN%¥ovstop

%NNM_BIN%¥ovspmd

Linux：

$NNM_BIN/ovstop

$NNM_BIN/ovspmd

EXTERNAL INFLUENCES

Environmental Variables

$LANGは，国際化変数LC_ALL，LC_CTYPE，LC_MESSAGESが未設定，NULL，または無効な場合にデフォルト値を提供します。

$LANGが未設定，NULL，または無効な場合，デフォルト値のC（Windows の場合English_UnitedStates.1252）が使用されます。

LC_ALL（または$LANG）はovspmdが起動したほかのすべてのプロセスのロケールを決定します。

LC_CTYPEは，テキストをシングルバイト文字，マルチバイト文字，あるいはその両方として解釈すること，文字の分類は印刷可能とすること，正規表現の文字クラス表現によって文字を一致させることを決定します。

LC_MESSAGESは，メッセージを表示する言語を決定します。

NNMi Cluster

com.hp.ov.nms.cluster.name が %NNM_DATA%¥shared¥nnm¥conf¥props¥nms-cluster.properties ファイル（Windows オペレーティングシステムの場合）または，$NNM_DATA/shared/nnm/conf/props/nms-cluster.properties ファイル（Linux オペレーティングシステムの場合）で定義されている場合，ovstop は停止を nnmcluster コマンドに任せます。

SEE ALSO

ovstatus, ovstart, ovspmd, nnmcluster.

付録H　リファレンスページ（File Formats）

付録H.1　disco.NoVLANIndexing

検出のポーリング時に VLAN Indexing を省略するノードを指定します。

SYNOPSIS

disco.NoVLANIndexing

DESCRIPTION

NNMi が管理対象ネットワーク内のスイッチ間のレイヤー2 接続の状況を知る方法の一つは，各スイッチからdot1dTpFdbTable（FDB）を読み出すことです。しかし，Cisco製スイッチの場合は，FDB全体を読み出すためにVLAN Indexingを使用する必要があります。VLAN Indexingを使用することで，NNMiはCisco製スイッチに設定された各VLANのFDBをその都度読み出します。各デバイス上に設定されているVLANの数が多い場合は，VLAN Indexingを使用したFDBの読み出しは，完了までに非常に長い時間がかかり，場合によっては数時間かかることもあります。

Cisco製スイッチは，多くの場合，Cisco Discovery Protocol（CDP）を使用する設定になっています。CDPは，レイヤー2接続の状況を知るためのより優れた方法と考えられています。ネットワークのコアに位置する大規模なスイッチには，多数のVLAN が設定されている場合があります。こうしたスイッチでは，通常はスイッチ自身に直接接続されているエンドノードがありません。管理対象スイッチにエンドノードが直接接続されていない場合，こうした大規模なスイッチではFDBの収集を抑制する設定にした方が良いかもしれません。FDBの収集を抑制しても，NNMiはCDPから収集したデータを使用してレイヤー2の検出を実行できます。VLAN Indexingを抑制する対象としては，まず，こうした大規模なスイッチが最初の候補となります。一方，ネットワークの端に位置し，多数のエンドノードが接続されている小規模なスイッチ（多くの場合，アクセススイッチと呼ばれます）では，VLAN Indexingを抑制しないでください。

VLAN Indexingを抑制するようにNNMiを設定できます。これを行うには，NNMiの管理者は，disco.NoVLANIndexingファイルを作成する必要があります。このファイルの名前は大文字と小文字を区別します。disco.NoVLANIndexingファイルは，ovjbossプロセスの起動時に読み込まれます。NNMi管理者がovjbossプロセスの起動後にdisco.NoVLANIndexingファイルを変更した場合，その変更は次にovjbossプロセスが起動されるまで有効になりません。disco.NoVLANIndexingファイルは初期状態では用意されていません。disco.NoVLANIndexingファイルが存在しない場合はこの機能が無効になるため，NNMiはVLAN Indexingを使用し，すべてのデバイスについてFDBテーブル全体を収集しようとします。

disco.NoVLANIndexingファイルには，IPアドレス，IPアドレスの範囲およびコメントを記述できます。コメントは，ポンド（ハッシュ）記号（#）と，#から行末までのすべての文字で構成されます。NNMiでは空白行はコメントとして扱われます。IPアドレスは，IPバージョン4の場合は標準のドット付き10進数表記，IPバージョン6の場合は標準形式（RFC 2373）で指定します。

IPアドレス範囲のフォーマットの詳細については，NNMiヘルプ［領域のアドレス範囲を設定する］を参照してください。

リストされているIPアドレスのどれかとノードの管理アドレスが一致する場合，そのノードは一致ノードと見なされます。ノードに設定されているほかのIPアドレスは考慮されません。ノードがdisco.NoVLANIndexingファイルに含まれるアドレスのどれかに一致すると，NNMiはデフォルトのFDB（@vlan-id のサフィックスが追加されていないコミュニティ文字列を使用してアクセス可能なFDB）だけを収集します。

FDB全体の収集を無効にすると，管理ネットワークのレイヤー2マップのレイアウトが不正確になる場合があります。どのスイッチをdisco.NoVLANIndexingファイルに含めるかについて，慎重に検討してください。

EXAMPLES

disco.NoVLANIndexingファイルの例を次に示します。

#This entry suppresses VLAN-indexing for the node whose management address is 10.2.37.149
10.2.37.149

192.168.100-101.1 #This entry causes the nodes 192.168.100.1 and 192.168.101.1 to be skipped, too

# Here are some examples of IPv6 addresses and ranges:
   2136::8:800:200C:417a
   fd01::a352:1245:fc4B
   2001:D88:2:0:a07:ffff:0a01:3200-37ff

AUTHOR

disco.NoVLANIndexing was developed by Micro Focus.

FILES

Windows：%NnmDataDir%shared¥nnm¥conf¥disco¥disco.NoVLANIndexing

Linux：$NnmDataDir/shared/nnm/conf/disco/disco.NoVLANIndexing

SEE ALSO

詳細については，『NNMiの保守』の章およびNNMiヘルプ［領域のアドレス範囲を設定する］を参照してください。

付録H.2　disco.SkipXdpProcessing

NNMiが検出プロトコル情報を問い合わせるべきでないノードの，管理IPアドレスのリストが含まれます。

SYNOPSIS

disco.SkipXdpProcessing

DESCRIPTION

NNMiが管理ネットワークに含まれるネットワークデバイス間のレイヤー2接続を検出するとき，一つの方法として，検出プロトコル関連の情報をデバイスから収集する方法を使用します。検出プロトコルには，さまざまなプロトコルが定義されています。例えば，Link Layer Discovery Protocol（LLDP）は業界標準のプロトコルですが，Cisco製デバイスに使用するCisco Discovery Protocol（CDP）のように，ベンダー固有のプロトコルが多数存在します。これらのプロトコルはすべて，NNMiの検出機能のXdpAnalyzer によって処理されます。

指定したデバイスの検出プロトコル収集を行わないようにNNMiを設定できます。この機能では，NNMi管理者が作成する設定ファイルdisco.SkipXdpProcessingを使用します。このファイルの名前は大文字と小文字を区別します。disco.SkipXdpProcessingは，ovjbossプロセスの起動時に読み込まれます。NNMi管理者がovjbossプロセスの起動後にこのファイルを変更した場合，その変更は次にovjbossプロセスが起動されるまで有効になりません。disco.SkipXdpProcessingファイルは初期状態では用意されていません。disco.SkipXdpProcessingが存在しない場合はこの機能が無効になるため，NNMiはすべての管理ノードから検出プロトコル情報を収集しようとします。

この機能によって修正される既知の問題の詳細については，下記の「SEE ALSO」の項を参照してください。

disco.SkipXdpProcessingファイルには，IPアドレスとコメントを記述できます。コメントは，ポンド（ハッシュ）記号（#）と，#から行末までのすべての文字で構成されます。NNMiでは空白行はコメントとして扱われます。IPアドレスは，IPバージョン4 の場合は標準のドット付き10進数表記，IPバージョン6の場合は標準形式（RFC 2373）で指定します。

リストされているIPアドレスのどれかとノードの管理アドレスが一致する場合，そのノードは一致ノードと見なされます。ノードに設定されているほかのIPアドレスは考慮されません。ノードの管理アドレスとdisco.SkipXdpProcessingファイルに含まれるアドレスのどれかが一致すると，そのノードのXdpAnalyzer サービスは省略され，検出プロトコル情報は収集されません。

ノードの検出プロトコル処理を無効にすると，管理ネットワークのレイヤー2 マップのレイアウトが不正確になる場合があります。

EXAMPLES

disco.SkipXdpProcessingファイルの例を次に示します。

#このエントリにより，管理アドレスが 10.2.37.149 のノードの XdpAnalyzer 処理が行われなくなります。
10.2.37.149

192.168.100.1 #このエントリにより，ノード 192.168.100.1 も省略対象となります。

#IPv6 アドレスの例を次に示します。:
   2136::8:800:200C:417a
   fd01::a352:1245:fc4B

AUTHOR

disco.SkipXdpProcessing was developed by Micro Focus.

FILES

Windows：%NnmDataDir%shared¥nnm¥conf¥disco¥disco.SkipXdpProcessing

Linux：$NnmDataDir/shared/nnm/conf/disco/disco.SkipXdpProcessing

SEE ALSO

詳細については，『NNMiの保守』の章を参照してください。

付録H.3　hostnolookup.conf

システムIPネームサーバーを使用したIPアドレス解決の対象から除外するホスト名またはワイルドカード指定のホスト名を格納したファイル

SYNOPSIS

hostnolookup.conf

DESCRIPTION

hostnolookup.confは，ovjbossプロセスが，システムIPネームサーバーを使用してIPアドレスを解決するかどうかを決定するのに使用するファイルです。NNMiプロセスovjbossは，ホスト名からIPアドレスを解決する前に，ホスト名とこのファイルの各エントリとを突き合わせチェックします。一致するエントリが見つかった場合，ovjbossプロセスはシステムIPネームサーバーを使用したIPアドレス解決を行いません。

このファイルには，一つのホスト名またはホスト名のワイルドカードを含むエントリを追加します。一つのエントリを複数の行に記述することはできません。コメントを追加するには，コメントの前に記号（#）を追加します。このようにすると，その行の#以降の部分が無視されます。hostnolookup.confファイルには空白行を追加できます。

hostnolookup.confファイルは，特定のホスト名（またはホスト名の範囲）をシステムIPネームサーバーを使用したIPアドレス解決から除外するときに使用します。

hostnolookup.confファイルは管理者が作成する必要があります。初期状態ではこのファイルは用意されていません。

NNMiプロセスが起動しているときにhostnolookup.confファイルの変更を反映する場合は，%NnmInstallDir%support¥nmsdnssync.ovplコマンド（Windows の場合）または$NnmInstallDir/support/nmsdnssync.ovplコマンド（Linuxの場合）を引数なしで実行します。

EXAMPLES

hostnolookup.confファイルの例を次に示します。

# 特定のホスト名を指定する例
badsys.mydomain.mycorp.com
# ワイルドカードを使用したホスト名の指定例
*.baddomain.mycorp.com

最初の例では，DNSサーバーが予期しない結果を返すホスト名を指定しています。二番目の例では，解決できないドメイン名を指定しています。上記のエントリをhostnolookup.confファイルに追加すると，NNMiでホスト名解決が行われなくなります。

AUTHOR

hostnolookup.conf was developed by Micro Focus.

FILES

Windows：%NNM_DATA%¥shared¥nnm¥conf¥hostnolookup.conf

Linux：$NNM_DATA/shared/nnm/conf/hostnolookup.conf

SEE ALSO

ipnolookup.conf.

付録H.4　ipnolookup.conf

システムIPネームサーバーを使用したホスト名解決の対象から除外するIPアドレスまたはワイルドカード指定のIPアドレスを格納したファイル

SYNOPSIS

ipnolookup.conf

DESCRIPTION

ipnolookup.confは，すべてのNNMiプロセスが，システムIPネームサーバーを使用してホスト名を解決するかどうかを決定するのに使用するファイルです。各NNMiプロセスは，IPアドレスからホスト名を解決する前に，IPアドレスとこのファイルの各エントリとを突き合わせチェックします。一致するエントリが見つかった場合，NNMiプロセスはシステムIPネームサーバーを使用したホスト解決を行いません。

このファイルには，各行に一つのIPアドレスまたはIPアドレスのワイルドカードを含むエントリを追加します。一つのエントリを複数の行に記述することはできません。コメントを追加するには，コメントの前に記号（#）を追加します。このようにすると，その行の#以降の部分が無視されます。ipnolookup.confファイルには空白行を追加できます。

ipnolookup.confファイルは，特定のIPアドレス（またはIPアドレスの範囲）をシステムIPネームサーバーを使用したホスト名解決から除外するときに使用します。

ipnolookup.confファイルは管理者が作成する必要があります。初期状態ではこのファイルは用意されていません。

NNMiプロセスが起動しているときにipnolookup.confファイルの変更を反映する場合は，%NnmInstallDir%support¥nmsdnssync.ovplコマンド（Windowsの場合）または$NnmInstallDir/support/nmsdnssync.ovplコマンド（Linuxの場合）を引数なしで実行します。

EXAMPLES

ipnolookup.confファイルの例を次に示します。

# 特定の IP アドレスを指定する例
192.168.1.100
# ワイルドカードを使用した IP アドレスの指定例
10.*.*.*
# IP アドレスの範囲指定例
192.168.1.101-255

最初の例では，多くのWebサイトがIPアドレスに192.168.*.*を使用するため，この単独IPアドレスはインターネットにルーティングされる可能性があります。二番目の例に示すワイルドカードを使用したIPアドレス範囲指定は，NATアドレスとなる可能性があります。したがって，この指定方法は通信には不向きです。三番目の例では，IPのワイルドカード範囲が，プライマリIPアドレス以外の目的で使用されるアドレスの組である可能性があります。

AUTHOR

ipnolookup.conf was developed by Micro Focus.

FILES

Windows：%NNM_DATA%¥shared¥nnm¥conf¥ipnolookup.conf

Linux：$NNM_DATA/shared/nnm/conf/ipnolookup.conf

SEE ALSO

hostnolookup.conf.

付録H.5　macdedupexceptions.txt

MACアドレスベースのノードの重複削除ロジックの例外と見なされているノードタイプのsysObjectIDの値を含むファイル

SYNOPSIS

macdedupexceptions.txt

DESCRIPTION

NNMiは，ノードが実際にはデータベース内の他のノードと重複していることを検出するために，様々な複雑なアルゴリズムを使用します。場合によっては，NNMiはMACアドレスを比較し，DHCPリースの期限切れのためにノードが新しいIPアドレスを割り当てられたかどうか判断します。これは，ファイアウォールやロードバランサーなどの一部のネットワークデバイスで問題が発生する場合があります。これらのデバイスは，複数の異なるデバイス間で共通のIPアドレスとMACアドレスを使用することがあります。通常，NNMiはSNMP sysNameの違いにより，これらのデバイスを区別します。しかし，異なるSNMP sysNameを設定できない場合もあります。これらのケースでは，NNMiは，デバイスが重複していると判断して，データベースからいずれかのデバイスを削除することがあります。

このようなロードバランサーやファイアウォールのようなデバイスについては，macdedupexceptions.txtファイルに，これらのデバイスのSNMP sysObjectIDの値を記載することによって，重複削除アルゴリズムを修正するようNNMiに指示することができます。このファイルに含めるための良い候補となるデバイスには，次の特性があります。

デバイスは，DHCPサーバからIPアドレスを取得してはいけません。IPアドレスは静的に割り当てられる必要があります。

デバイスは，一意の管理IPアドレスを使用する必要があります。

この設定ファイルに有用なデバイスの例を次に示します。

デバイスは，いくつかの共通IPアドレスとMACアドレスを使用し，同一のSNMP sysNameを共有している別のデバイスと共に，冗長構成として設定されています。

デバイスは，いくつかの仮想インスタンスをサポートする物理デバイスであり，そこでは各インスタンスが同様のIPアドレスとMACアドレスを使用し，同一のSNMP sysNameを共用している可能性があります。

正しく検出されることが必要なデバイスに関するエントリのみを，NNMiの管理者がこのファイルに追加することを推奨します。不要なエントリを追加すると，予期しない結果になるおそれがあります。

ファイルには，一つ以上のSNMP sysObjectIDの値（各行に一つの値）を含めることができます。「#」で始まる行は，空行と同様にコメント行として扱われます。コメントはsysObjectIDに続けて，「#」で開始し行末まで指定することもできます。sysObjectIDの前後の空白は無視されます。また，sysObjectID値の先頭のドット（.）はオプションです。

初期状態ではこのファイルは用意されていません。必要な場合，NNMiの管理者が作成する必要があります。ファイルはNNMiの起動時に読み込まれます。NNMiの起動後に行われた変更は，NNMiが再起動されるまで有効になりません。

EXAMPLES

macdedupexceptions.txtファイルの例を次に示します。

# F5 BIG-IP Pb200 ロードバランサー機器
.1.3.6.1.4.1.3375.2.1.3.4.19

1.3.6.1.4.1.9.1.1291  #Cisco ACE サービスモジュール

AUTHOR

macdedupexceptions.txt was developed by Micro Focus.

FILES

Windows：%NNM_DATA%¥shared¥nnm¥conf¥disco¥macdedupexceptions.txt

Linux：$NNM_DATA/shared/nnm/conf/disco/macdedupexceptions.txt

付録H.6　nnm.ports

次の情報は，NNMi管理サーバーのリッスンポートを示します。ポート競合の場合には，これらのポート番号の多くを変更してください。

SYNOPSIS

nnm.ports

コマンドの概要はありません。nnm.portsリファレンスページには，nms-local.propertiesファイルの修正によって変更できるウェルノウンポートが記載されています。

DESCRIPTION

ポート番号を変更するには，次の手順を実施します。

NNMiが使用するポートを変更するために，次のファイルを編集します。

Windows：%NnmDataDir%Conf¥nnm¥props¥nms-local.properties

Linux：$NnmDataDir/conf/nnm/props/nms-local.properties

変更するポートを含む行を特定します。

必要に応じて行の先頭の#!を削除します。

ポート番号を修正し，変更を保存します。

コマンドプロンプトでovstopとovstartを実行し，NNMiを再起動します。

現在定義されているポートを次に示します。

nmsas.server.port.web.http=80

このTCPポートは，Web UIとWebサービスで，デフォルトのHTTPポートとして使用されます。NNMiのインストール時に，この値を設定するよう求められます。このポートの値は，NNMiのインストール中，またはnms-local.propertiesファイルを修正することで変更できます。

nmsas.server.port.web.https=443

このTCPポートは，Web UIとWebサービスで，デフォルトのセキュアHTTPSポート(SSL)として使用されます。

nmsas.server.port.naming.rmi=1098

RMIネーミングサービスのデフォルトのTCPポートです。

nmsas.server.port.naming.port=1099

JNPサービス(JNDIプロバイダ)のデフォルトのTCPポートです。

nmsas.server.port.remoting.ejb3=3873

このTCPポートは，グローバルNNMi管理サーバー上で実行されるコマンドラインツールが，リモートアクセスのために使用します。

nmsas.server.port.jmx.jrmp=4444

このTCPポートは，RMIがデータ転送に使用するRMIオブジェクトポート(Java Remote Method Protocol)です。

nmsas.server.port.jmx.rmi=4445

このTCPポートは，RMI要求をプールするときに使用されるデフォルトのポートです。

nmsas.server.port.invoker.unified=4446

このTCPポートは，デフォルトのRMIリモーティングサーバーコネクタポートです。jbossリモーティングサービスによって使用されます。

nmsas.server.port.hq=4457

このTCPポートは，グローバルネットワーク管理の暗号化されていない通信のために使用します。

nmsas.server.port.hq.ssl=4459

このTCPポートは，グローバルネットワーク管理の暗号化された通信のために使用します。

nmsas.server.port.ts.recovery=4712

このTCPポートは，NNMiの内部で使用されるトランザクション・サービス・ポートです。

nmsas.server.port.ts.status=4713

このTCPポートは，NNMiの内部で使用されるトランザクション・サービス・ポートです。

nmsas.server.port.ts.id=4714

このTCPポートは，NNMiの内部で使用されるトランザクション・サービス・ポートです。

com.hp.ov.nms.postgres.port=5432

このTCPポートは，組み込みデータベースがNNMi 管理サーバーとの通信のためにリッスンするポート(PostgreSQLのポート)です。

AUTHOR

nnm.ports was developed by Micro Focus.

FILES

Windows：%NnmDataDir%Conf¥nnm¥props¥nms-local.properties

Linux：$NnmDataDir/conf/nnm/props/nms-local.properties

SEE ALSO

ovstatus, ovstart, ovstop.

付録H.7　nnm.properties

コマンドラインツールの実行に必要なユーザー名およびパスワードを格納するファイル。

SYNOPSIS

nnm.properties

DESCRIPTION

NNMiコマンドラインツールを頻繁に実行する場合は，nnm.propertiesファイルを作成しておくことを推奨します。このファイルには，コマンドラインオプションの-uおよび-pに代わって使用されるユーザー名およびパスワードが格納されます。nnm.propertiesファイルを使用することで，パスワードを入力せずに多数のコマンドを実行できます。nnm.propertiesファイルには，パスワードが暗号化されて格納されます。このファイルは，nnmsetcmduserpw.ovplコマンドを実行して作成する必要があります。nnm.propertiesファイルは決して手動で編集しないでください。

nnmsetcmduserpw.ovplコマンドでファイルを作成または編集すると，次のホームディレクトリの配下の".nnm"サブディレクトリにファイルが配置されます。

Windows：drive:¥Users¥username¥.nnm¥

Linux：~/.nnm/

このファイルの内容は次のように定義する必要があります。

nnm.username

アカウントのユーザー名

nnm.password

アカウントの暗号化されたパスワード

ほとんどのコマンドラインツールは，管理者ロールが割り当てられた管理者権限のユーザーとして実行する必要があります。

AUTHOR

nnm.properties was developed by Micro Focus.

FILES

次の環境変数は，使用するシェルおよびプラットフォームの要件に従って設定される共通パスです。

Windows：drive:¥Users¥username¥.nnm¥nnm.properties

Linux：$HOME/.nnm/nnm.properties

SEE ALSO

nnmsetcmduserpw.ovpl.

付録H.8　incidentconfiguration.format

NNMiデータベースにロードできるインシデント構成を格納するファイル。このファイルはnnmincidentcfgdump.ovplによって作成され，nnmincidentcfgload.ovplによってNNMiデータベースにロードされます。

SYNOPSIS

incidentconfiguration.format

DESCRIPTION

incidentconfiguration.formatファイルはNNMiデータベースにロードできるインシデント構成を格納します。このファイルでは，構成内容を表現するために規定されたタグを使用します

それぞれのインシデント構成は，次の4つの構成種別タグから始まる必要があります。

*ConfigurationType=MgmtEventConfig
*ConfigurationType=PairwiseConfig
*ConfigurationType=SnmpTrapConfig
*ConfigurationType=SyslogMessageConfig

インシデント構成を修正する場合，次の点に注意してください。

*(#) 記号はコメントを示します。
*コメントは構成種別タグの前に記載する必要があります。
*(#) 記号が構成データの中に記載された場合，それらは記載されたタグの値の一部として扱われます。
*コメントは NNMi データベースに保存されません。そのため，その後に実行された nnmincidentdump.ovpl コマンドの出力には含まれません。
*構成種別タグの後に記載されたすべてのタグは，そのインシデント構成種別の一部と判断されます。
*(-) で始まるタグは編集することができます。
*(*) で始まるタグは，一度インポートされた後は編集することはできません。
*(OPTIONAL) はそのタグがオプションであることを示します。
*([]) は，タグの値を，特定のフォーマットや，決められた一覧からの値として指定する必要があることを示します。
*"(Direct child tags may occur multiple times)" と注釈が付いたタグには，複数の子となるタグを指定することができます。
*UUID タグはオプションです。UUID は NNMi にデータベース上でのユニークな識別子として利用されます。
*Label タグを指定しない場合，NNMi が自動的に作成します。
*Label を NNMi が Key タグの値から決定できない場合，エラーとなります。

次の例外に注意してください。：NNMiは変更されたインシデントの構成に対して，"Customer"作成者キーと，そのラベルを割り当てます。

インシデント構成ファイルをロードする前に，次の作業を実施することを推奨します。

1. nnmincidentcfgdump.ovpl -name コマンドを使用して，編集したいインシデントの例を選択してください。
2. 1. の出力を基に，タグの階層を確認してください。
3. ファイルの書式を確認した後，本リファレンスに記載する書式のリストから編集する構成種別を見つけ，編集箇所を決定し，指定された場所に編集したい値を記載してください。
4. nnmincidentcfgload.ovpl -validate コマンドを使用して，編集内容を検証してください。
5. nnmincidentcfgload.ovpl -load コマンドを使用して NNMi データベースにロードし，編集内容をテストしてください。

注意：nnmincidentcfgload.ovpl コマンドは，書式に一致しない値に対して，エラーを出力します。

FILES

NNMiは，インシデント構成ファイルの例と，タグフォーマットファイルの正しい書式を次の場所で提供しています。

Windows：%NnmInstallDir%examples¥nnm¥incidentcfg

Linux：/opt/OV/examples/nnm/incidentcfg

EXAMPLES

管理イベントを必須タグのみで作成します。

*ConfigurationType=MgmtEventConfig
	*Name MinimnalistMgmtConfig
	*Oid .1.3.6.1.4.1.11.2.17.19.2.0.9999
	-Author
		-Key com.customer.author
	-Category
		-Key com.hp.nms.incident.category.Fault
	-Family
		-Key com.hp.nms.incident.family.Node
	-MessageFormat Custom message format
	-Severity MINOR

強化設定を管理イベントに追加します。

*ConfigurationType=MgmtEventConfig
	*Name MinimnalistMgmtConfig
	*Oid .1.3.6.1.4.1.11.2.17.19.2.0.9999
	-Author
		-Key com.customer.author
	-Category
		-Key com.hp.nms.incident.category.Fault
	-Family
		-Key com.hp.nms.incident.family.Node
	-MessageFormat Custom message format
    -EnrichConfiguration
        -Enable true
        -Enrichments
            -Enrichment
                -PayloadFilter
                    -Expression ciaName notEquals "varArg"

syslog messageインシデント構成の構成種別タグの前に，コメントを追加しています。

#
# Insert comments before the configuration type tag
#
# NNMi does not store comments in the NNMi database
#
# This example includes only the required tabs for the syslog message configuration
#
*ConfigurationType=SyslogMessageConfig
	*Name MinimalistSyslogConfig
	-Author
		-Key com.minimal.customer
		-Label MinimalCustomer
	-Category
		-Key com.hp.nms.incident.category.Fault
	-Family
		-Key com.hp.nms.incident.family.AggregatePort
	-MessageFormat $.1.3.6.1.4.1.11937.1.54.5: $.1.3.6.1.4.1.11937.1.4
	-Severity CRITICAL

PAIRWISE CONFIGURATION FORMAT

次の例は，PairwiseConfig構成種別のための書式を示します。

*ConfigurationType=PairwiseConfig (ROOT TAG)
    *Name
    -SetOfPairItems (OPTIONAL TAG) (Direct child tags may occur multiple times)
        -SetOfPairItem (OPTIONAL TAG)
            -FirstInPair
            -FirstParamType
            -SecondInPair
            -SecondParamType
            *UUID (OPTIONAL TAG)
    -Author
        -Key
        -Label (OPTIONAL TAG)
    -DeleteWhenClosed (OPTIONAL TAG)
    -Description (OPTIONAL TAG)
    -Duration
    -Enable (OPTIONAL TAG)
    -FirstIncidentConfigRef
        -Key
        -Type = [MgmtEventConfig, SnmpTrapConfig, SyslogMessageConfig]
    -FirstIncidentName
    -FirstIncidentPayloadFilter (OPTIONAL TAG)
        -Expression [Format = Formatted Expression String]
        *UUID (OPTIONAL TAG)
    -SecondIncidentConfigRef
        -Key
        -Type = [MgmtEventConfig, SnmpTrapConfig, SyslogMessageConfig]
    -SecondIncidentName
    -SecondIncidentPayloadFilter (OPTIONAL TAG)
        -Expression [Format = Formatted Expression String]
        *UUID (OPTIONAL TAG)

MANAGEMENT EVENT CONFIGURATION FORMAT

次の例は，MgmtEventConfig構成種別のための書式を示します。

*ConfigurationType=MgmtEventConfig (ROOT TAG)
    *Name
    *Oid
    -Author
        -Key
        -Label (OPTIONAL TAG)
    -Category
        -Key
        -Label (OPTIONAL TAG)
    -Enable (OPTIONAL TAG)
    -ActionConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -Actions (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -Action (OPTIONAL TAG)
                -Command (OPTIONAL TAG)
                -CommandType
                -LifecycleState = [Registered, InProgress, Completed, Closed, Dampened]
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
    -DampenConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        -HourInterval
        -MinuteInterval
        -SecondInterval
        *UUID (OPTIONAL TAG)
        -PayloadFilter (OPTIONAL TAG)
            -Expression [Format = Formatted Expression String]
            *UUID (OPTIONAL TAG)
    -DedupConfiguration (OPTIONAL TAG)
        -ComparisonCriteria
        -CorrelationIncidentConfig (OPTIONAL TAG)
            *Name
        -DedupCount (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        -HourInterval (OPTIONAL TAG)
        -MinuteInterval (OPTIONAL TAG)
        -SecondInterval (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -ComparisonParamList (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -ComparisonParam (OPTIONAL TAG)
                -ParamType (OPTIONAL TAG)
                -ParamValue
                *UUID (OPTIONAL TAG)
    -Description (OPTIONAL TAG)
    -Family
        -Key
        -Label (OPTIONAL TAG)
    -MessageFormat
    -Severity
    -EnrichConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -Enrichments (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -Enrichment (OPTIONAL TAG)
                -AssignedTo (OPTIONAL TAG)
                -Category (OPTIONAL TAG)
                    -Key
                    -Label (OPTIONAL TAG)
                -Description (OPTIONAL TAG)
                -Family (OPTIONAL TAG)
                    -Key
                    -Label (OPTIONAL TAG)
                -MessageFormat (OPTIONAL TAG)
                -Nature (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
                -Priority (OPTIONAL TAG)
                    -Key
                    -Label (OPTIONAL TAG)
                -EnrichCias (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -EnrichCia (OPTIONAL TAG)
                        -CiaName
                        -EnrichCiaType
                        -Expression [Format = Formatted Expression String]
                        *UUID (OPTIONAL TAG)
                -Severity (OPTIONAL TAG)
    -SuppressConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -PayloadFilter (OPTIONAL TAG)
            -Expression [Format = Formatted Expression String]
            *UUID (OPTIONAL TAG)
    -InterfaceGroups (OPTIONAL TAG) (Direct child tags may occur multiple times)
        -InterfaceGroup (OPTIONAL TAG)
            -Enable
            *UUID (OPTIONAL TAG)
            -DampenConfiguration
                -Enable (OPTIONAL TAG)
                -HourInterval
                -MinuteInterval
                -SecondInterval
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
            -EnrichConfiguration
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Enrichments (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Enrichment (OPTIONAL TAG)
                        -AssignedTo (OPTIONAL TAG)
                        -Category (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -Description (OPTIONAL TAG)
                        -Family (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -MessageFormat (OPTIONAL TAG)
                        -Nature (OPTIONAL TAG)
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
                        -Priority (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -EnrichCias (OPTIONAL TAG) (Direct child tags may occur multiple times)
                            -EnrichCia (OPTIONAL TAG)
                                -CiaName
                                -EnrichCiaType
                                -Expression [Format = Formatted Expression String]
                                *UUID (OPTIONAL TAG)
                        -Severity (OPTIONAL TAG)
            *InterfaceGroup
            -Ordering
            -ActionConfiguration
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Actions (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Action (OPTIONAL TAG)
                        -Command (OPTIONAL TAG)
                        -CommandType
                        -LifecycleState = [Registered, InProgress, Completed, Closed, Dampened]
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
            -SuppressConfiguration
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
    -NodeGroups (OPTIONAL TAG) (Direct child tags may occur multiple times)
        -NodeGroup (OPTIONAL TAG)
            -Enable (OPTIONAL TAG)
            *UUID (OPTIONAL TAG)
            -DampenConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                -HourInterval
                -MinuteInterval
                -SecondInterval
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
            -EnrichConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Enrichments (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Enrichment (OPTIONAL TAG)
                        -AssignedTo (OPTIONAL TAG)
                        -Category (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -Description (OPTIONAL TAG)
                        -Family (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -MessageFormat (OPTIONAL TAG)
                        -Nature (OPTIONAL TAG)
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
                        -Priority (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -EnrichCias (OPTIONAL TAG) (Direct child tags may occur multiple times)
                            -EnrichCia (OPTIONAL TAG)
                                -CiaName
                                -EnrichCiaType
                                -Expression [Format = Formatted Expression String]
                                *UUID (OPTIONAL TAG)
                        -Severity (OPTIONAL TAG)
            *NodeGroup
            -Ordering
            -ActionConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Actions (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Action (OPTIONAL TAG)
                        -Command (OPTIONAL TAG)
                        -CommandType
                        -LifecycleState = [Registered, InProgress, Completed, Closed, Dampened]
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
            -SuppressConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
    -RateConfiguration (OPTIONAL TAG)
        -ComparisonCriteria
        -CorrelationIncidentConfig (OPTIONAL TAG)
            *Name
        -Enable (OPTIONAL TAG)
        -HourInterval (OPTIONAL TAG)
        -MinuteInterval (OPTIONAL TAG)
        -RateCount (OPTIONAL TAG)
        -SecondInterval (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -ComparisonParamList (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -ComparisonParam (OPTIONAL TAG)
                -ParamType (OPTIONAL TAG)
                -ParamValue
                *UUID (OPTIONAL TAG)

SNMP TRAP CONFIGURATION FORMAT

次の例は，SnmpTrapConfig 構成種別のための書式を示します。

*ConfigurationType=SnmpTrapConfig (ROOT TAG)
    *Name
    *Oid
    -Author
        -Key
        -Label (OPTIONAL TAG)
    -Category
        -Key
        -Label (OPTIONAL TAG)
    -Enable (OPTIONAL TAG)
    -ActionConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -Actions (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -Action (OPTIONAL TAG)
                -Command (OPTIONAL TAG)
                -CommandType
                -LifecycleState = [Registered, InProgress, Completed, Closed, Dampened]
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
    -DampenConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        -HourInterval
        -MinuteInterval
        -SecondInterval
        *UUID (OPTIONAL TAG)
        -PayloadFilter (OPTIONAL TAG)
            -Expression [Format = Formatted Expression String]
            *UUID (OPTIONAL TAG)
    -DedupConfiguration (OPTIONAL TAG)
        -ComparisonCriteria
        -CorrelationIncidentConfig (OPTIONAL TAG)
            *Name
        -DedupCount (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        -HourInterval (OPTIONAL TAG)
        -MinuteInterval (OPTIONAL TAG)
        -SecondInterval (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -ComparisonParamList (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -ComparisonParam (OPTIONAL TAG)
                -ParamType (OPTIONAL TAG)
                -ParamValue
                *UUID (OPTIONAL TAG)
    -Description (OPTIONAL TAG)
    -Family
        -Key
        -Label (OPTIONAL TAG)
    -GeoCentralForwardConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -PayloadFilter (OPTIONAL TAG)
            -Expression [Format = Formatted Expression String]
            *UUID (OPTIONAL TAG)
    -MessageFormat
    -Severity
    -EnrichConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -Enrichments (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -Enrichment (OPTIONAL TAG)
                -AssignedTo (OPTIONAL TAG)
                -Category (OPTIONAL TAG)
                    -Key
                    -Label (OPTIONAL TAG)
                -Description (OPTIONAL TAG)
                -Family (OPTIONAL TAG)
                    -Key
                    -Label (OPTIONAL TAG)
                -MessageFormat (OPTIONAL TAG)
                -Nature (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
                -Priority (OPTIONAL TAG)
                    -Key
                    -Label (OPTIONAL TAG)
                -EnrichCias (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -EnrichCia (OPTIONAL TAG)
                        -CiaName
                        -EnrichCiaType
                        -Expression [Format = Formatted Expression String]
                        *UUID (OPTIONAL TAG)
                -Severity (OPTIONAL TAG)
    -SuppressConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -PayloadFilter (OPTIONAL TAG)
            -Expression [Format = Formatted Expression String]
            *UUID (OPTIONAL TAG)
    -InterfaceGroups (OPTIONAL TAG) (Direct child tags may occur multiple times)
        -InterfaceGroup (OPTIONAL TAG)
            -Enable
            *UUID (OPTIONAL TAG)
            -DampenConfiguration
                -Enable (OPTIONAL TAG)
                -HourInterval
                -MinuteInterval
                -SecondInterval
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
            -EnrichConfiguration
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Enrichments (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Enrichment (OPTIONAL TAG)
                        -AssignedTo (OPTIONAL TAG)
                        -Category (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -Description (OPTIONAL TAG)
                        -Family (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -MessageFormat (OPTIONAL TAG)
                        -Nature (OPTIONAL TAG)
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
                        -Priority (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -EnrichCias (OPTIONAL TAG) (Direct child tags may occur multiple times)
                            -EnrichCia (OPTIONAL TAG)
                                -CiaName
                                -EnrichCiaType
                                -Expression [Format = Formatted Expression String]
                                *UUID (OPTIONAL TAG)
                        -Severity (OPTIONAL TAG)
            *InterfaceGroup
            -Ordering
            -ActionConfiguration
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Actions (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Action (OPTIONAL TAG)
                        -Command (OPTIONAL TAG)
                        -CommandType
                        -LifecycleState = [Registered, InProgress, Completed, Closed, Dampened]
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
            -SuppressConfiguration
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
    -NodeGroups (OPTIONAL TAG) (Direct child tags may occur multiple times)
        -NodeGroup (OPTIONAL TAG)
            -Enable (OPTIONAL TAG)
            *UUID (OPTIONAL TAG)
            -DampenConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                -HourInterval
                -MinuteInterval
                -SecondInterval
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
            -EnrichConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Enrichments (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Enrichment (OPTIONAL TAG)
                        -AssignedTo (OPTIONAL TAG)
                        -Category (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -Description (OPTIONAL TAG)
                        -Family (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -MessageFormat (OPTIONAL TAG)
                        -Nature (OPTIONAL TAG)
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
                        -Priority (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -EnrichCias (OPTIONAL TAG) (Direct child tags may occur multiple times)
                            -EnrichCia (OPTIONAL TAG)
                                -CiaName
                                -EnrichCiaType
                                -Expression [Format = Formatted Expression String]
                                *UUID (OPTIONAL TAG)
                        -Severity (OPTIONAL TAG)
            *NodeGroup
            -Ordering
            -ActionConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Actions (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Action (OPTIONAL TAG)
                        -Command (OPTIONAL TAG)
                        -CommandType
                        -LifecycleState = [Registered, InProgress, Completed, Closed, Dampened]
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
            -SuppressConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
    -RateConfiguration (OPTIONAL TAG)
        -ComparisonCriteria
        -CorrelationIncidentConfig (OPTIONAL TAG)
            *Name
        -Enable (OPTIONAL TAG)
        -HourInterval (OPTIONAL TAG)
        -MinuteInterval (OPTIONAL TAG)
        -RateCount (OPTIONAL TAG)
        -SecondInterval (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -ComparisonParamList (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -ComparisonParam (OPTIONAL TAG)
                -ParamType (OPTIONAL TAG)
                -ParamValue
                *UUID (OPTIONAL TAG)
    -UserRootCause (OPTIONAL TAG)

SYSLOG MESSAGE CONFIGURATION FORMAT

次の例は，SyslogMessageConfig構成種別のための書式を示します。

*ConfigurationType=SyslogMessageConfig (ROOT TAG)
    *Name
    -Author
        -Key
        -Label (OPTIONAL TAG)
    -Category
        -Key
        -Label (OPTIONAL TAG)
    -Enable (OPTIONAL TAG)
    -ActionConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -Actions (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -Action (OPTIONAL TAG)
                -Command (OPTIONAL TAG)
                -CommandType
                -LifecycleState = [Registered, InProgress, Completed, Closed, Dampened]
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
    -DampenConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        -HourInterval
        -MinuteInterval
        -SecondInterval
        *UUID (OPTIONAL TAG)
        -PayloadFilter (OPTIONAL TAG)
            -Expression [Format = Formatted Expression String]
            *UUID (OPTIONAL TAG)
    -DedupConfiguration (OPTIONAL TAG)
        -ComparisonCriteria
        -CorrelationIncidentConfig (OPTIONAL TAG)
            *Name
        -DedupCount (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        -HourInterval (OPTIONAL TAG)
        -MinuteInterval (OPTIONAL TAG)
        -SecondInterval (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -ComparisonParamList (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -ComparisonParam (OPTIONAL TAG)
                -ParamType (OPTIONAL TAG)
                -ParamValue
                *UUID (OPTIONAL TAG)
    -Description (OPTIONAL TAG)
    -Family
        -Key
        -Label (OPTIONAL TAG)
    -GeoCentralForwardConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -PayloadFilter (OPTIONAL TAG)
            -Expression [Format = Formatted Expression String]
            *UUID (OPTIONAL TAG)
    -MessageFormat
    -Severity
    -EnrichConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -Enrichments (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -Enrichment (OPTIONAL TAG)
                -AssignedTo (OPTIONAL TAG)
                -Category (OPTIONAL TAG)
                    -Key
                    -Label (OPTIONAL TAG)
                -Description (OPTIONAL TAG)
                -Family (OPTIONAL TAG)
                    -Key
                    -Label (OPTIONAL TAG)
                -MessageFormat (OPTIONAL TAG)
                -Nature (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
                -Priority (OPTIONAL TAG)
                    -Key
                    -Label (OPTIONAL TAG)
                -EnrichCias (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -EnrichCia (OPTIONAL TAG)
                        -CiaName
                        -EnrichCiaType
                        -Expression [Format = Formatted Expression String]
                        *UUID (OPTIONAL TAG)
                -Severity (OPTIONAL TAG)
    -SuppressConfiguration (OPTIONAL TAG)
        -Enable (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -PayloadFilter (OPTIONAL TAG)
            -Expression [Format = Formatted Expression String]
            *UUID (OPTIONAL TAG)
    -InterfaceGroups (OPTIONAL TAG) (Direct child tags may occur multiple times)
        -InterfaceGroup (OPTIONAL TAG)
            -Enable
            *UUID (OPTIONAL TAG)
            -DampenConfiguration
                -Enable (OPTIONAL TAG)
                -HourInterval
                -MinuteInterval
                -SecondInterval
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
            -EnrichConfiguration
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Enrichments (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Enrichment (OPTIONAL TAG)
                        -AssignedTo (OPTIONAL TAG)
                        -Category (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -Description (OPTIONAL TAG)
                        -Family (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -MessageFormat (OPTIONAL TAG)
                        -Nature (OPTIONAL TAG)
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
                        -Priority (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -EnrichCias (OPTIONAL TAG) (Direct child tags may occur multiple times)
                            -EnrichCia (OPTIONAL TAG)
                                -CiaName
                                -EnrichCiaType
                                -Expression [Format = Formatted Expression String]
                                *UUID (OPTIONAL TAG)
                        -Severity (OPTIONAL TAG)
            *InterfaceGroup
            -Ordering
            -ActionConfiguration
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Actions (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Action (OPTIONAL TAG)
                        -Command (OPTIONAL TAG)
                        -CommandType
                        -LifecycleState = [Registered, InProgress, Completed, Closed, Dampened]
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
            -SuppressConfiguration
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
    -NodeGroups (OPTIONAL TAG) (Direct child tags may occur multiple times)
        -NodeGroup (OPTIONAL TAG)
            -Enable (OPTIONAL TAG)
            *UUID (OPTIONAL TAG)
            -DampenConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                -HourInterval
                -MinuteInterval
                -SecondInterval
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
            -EnrichConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Enrichments (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Enrichment (OPTIONAL TAG)
                        -AssignedTo (OPTIONAL TAG)
                        -Category (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -Description (OPTIONAL TAG)
                        -Family (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -MessageFormat (OPTIONAL TAG)
                        -Nature (OPTIONAL TAG)
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
                        -Priority (OPTIONAL TAG)
                            -Key
                            -Label (OPTIONAL TAG)
                        -EnrichCias (OPTIONAL TAG) (Direct child tags may occur multiple times)
                            -EnrichCia (OPTIONAL TAG)
                                -CiaName
                                -EnrichCiaType
                                -Expression [Format = Formatted Expression String]
                                *UUID (OPTIONAL TAG)
                        -Severity (OPTIONAL TAG)
            *NodeGroup
            -Ordering
            -ActionConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -Actions (OPTIONAL TAG) (Direct child tags may occur multiple times)
                    -Action (OPTIONAL TAG)
                        -Command (OPTIONAL TAG)
                        -CommandType
                        -LifecycleState = [Registered, InProgress, Completed, Closed, Dampened]
                        *UUID (OPTIONAL TAG)
                        -PayloadFilter (OPTIONAL TAG)
                            -Expression [Format = Formatted Expression String]
                            *UUID (OPTIONAL TAG)
            -SuppressConfiguration (OPTIONAL TAG)
                -Enable (OPTIONAL TAG)
                *UUID (OPTIONAL TAG)
                -PayloadFilter (OPTIONAL TAG)
                    -Expression [Format = Formatted Expression String]
                    *UUID (OPTIONAL TAG)
    -RateConfiguration (OPTIONAL TAG)
        -ComparisonCriteria
        -CorrelationIncidentConfig (OPTIONAL TAG)
            *Name
        -Enable (OPTIONAL TAG)
        -HourInterval (OPTIONAL TAG)
        -MinuteInterval (OPTIONAL TAG)
        -RateCount (OPTIONAL TAG)
        -SecondInterval (OPTIONAL TAG)
        *UUID (OPTIONAL TAG)
        -ComparisonParamList (OPTIONAL TAG) (Direct child tags may occur multiple times)
            -ComparisonParam (OPTIONAL TAG)
                -ParamType (OPTIONAL TAG)
                -ParamValue
                *UUID (OPTIONAL TAG)
    -UserRootCause (OPTIONAL TAG)

AUTHOR

incidentconfiguration.format was developed by Micro Focus.

SEE ALSO

nnmincidentcfgload.ovpl.

nnmincidentcfgdump.ovpl.

付録H.9　nnmtrapd.conf

SYNOPSIS

IP アドレスおよびOIDに基づいてトラップをブロックするためのフィルターファイル

nnmtrapd.conf

DESCRIPTION

IP アドレスおよびトラップ OID の両方に基づいてトラップをブロックするためのフィルターを構成するために，nnmtrapd.confファイルを使用します。

1行に一つのフィルターを入力してください。各フィルターは，IPアドレス，アドレスの範囲またはワイルドカードと，一つ以上のトラップOID，トラップOIDの範囲，またはワイルドカードがカンマで区切られて構成されています。

フィルターの形式は次のとおりです。

<IP Address, OID[,OID]*>

IP Addressは，単一のIPアドレスでも，プレフィックス/プレフィックス長の表記法もしくは範囲のワイルドカードの表記法のパターンでもかまいません。 "*" という特別な表記法はすべてのアドレスを示します。同じアドレスでプレフィックス/プレフィックス長の表記法と，範囲のワイルドカード表記法を組み合わせないでください。アドレスの代わりにホスト名を指定しないでください。すべてのフィルターエントリには，一意のアドレス（単一，ワイルドカード，または範囲）が必要です。プレフィックス/プレフィックス長の表記法のアドレスの例は，次のとおりです。

10.2.112.0/20

1080:0:a00::/44

同じアドレスを，範囲のワイルドカード表記法で表すと次のようになります。

10.2.112-127.*

1080:0:a00-a0f:*:*:*:*:*

トラップOIDも，範囲またはワイルドカードとして指定することができます。一つのOIDでは，範囲またはワイルドカードのどちらかを使用します。OIDの最後のサブOIDだけを範囲またはワイルドカードとして指定します。".*"という特別な表記法はすべてのOIDを示しています。例は次のとおりです。

.1.3.6.1.4.1.11.2.17.1.0.58915834-58915868

.1.3.6.1.4.1.11.*

linkUpのような一般トラップについては，特定のベンダーをブロックするために，トラップOIDにベンダーのエンタープライズOIDを追加することができます。反対に，すべてのベンダーからの一般トラップをブロックするためには，トラップOIDにワイルドカードを追加する必要があります。

すべてのアドレスからすべてのトラップをブロックすることは許可されていません。このため，次のエントリは無視されます。

<*, .*>

フィルターの変更を実行中のNNMiに適用するには，次のコマンドを実行します。

nnmtrapconfig.ovpl -readFilter

EXAMPLES

次の例は，10.2.120から10.2.127の範囲のすべてのサブネットからのすべての一般トラップをブロックします。

<10.2.120.0/21, .1.3.6.1.6.3.1.1.5.*>

次の例は，10.6.112/21サブネットにあるエンタープライズOIDが.1.3.6.1.4.1.11.2.3.7.11.17であるすべてのデバイスからのlinkUpトラップをブロックします。

<10.6.112.0/21, .1.3.6.1.6.3.1.1.5.4.1.3.6.1.4.1.11.2.3.7.11.17>

次の例は，10.6.112/21サブネットにあるすべてのデバイスからのlinkUpトラップをブロックします。

<10.6.112.0/21, .1.3.6.1.6.3.1.1.5.4.*>

次の例は，一つのIPv6アドレスからの，OIDが .1.3.6.1.4.1.11.2.17で始まるすべてのトラップ，および認証失敗トラップをブロックします。

<1080::8:800:200c:417a, .1.3.6.1.4.1.11.2.17.*, .1.3.6.1.6.3.1.1.5.5.*>

AUTHOR

nnmtrapd.conf was developed by Micro Focus.

FILES

Windows：%NnmDataDir%shared¥nnm¥conf¥nnmtrapd.conf

Linux：$NnmDataDir/shared/nnm/conf/nnmtrapd.conf

SEE ALSO

nnmtrapconfig.ovpl.

付録H.10　trapFilter.conf

IPアドレスおよびOIDに基づいてトラップをブロックするためのフィルターファイル

SYNOPSIS

trapFilter.conf

DESCRIPTION

IPアドレスおよびトラップOIDの両方に基づいてトラップをブロックするためのフィルターを構成するために，trapFilter.confファイルを使用します。これはnnmtrapd.confファイルの使用に似ていますが，trapFilter.confファイルによってブロックされたトラップは，バイナリトラップストアに格納されず，トラップ率を分析するために使用されないところが違います。トラップ率は，trapFilter.confファイルによってブロックされたトラップの影響を受けません。NNMiは，trapFilter.confファイルによってブロックされたトラップを格納しません。

1行に一つのフィルターを入力してください。各フィルターは，IPアドレス，アドレスの範囲またはワイルドカードと，一つ以上のトラップOID，トラップOIDの範囲，またはワイルドカードがカンマで区切られて構成されています。

フィルターの形式は次のとおりです。

<IP Address, OID[,OID]*>

IP Addressは，単一のIPアドレスでも，プレフィックス/プレフィックス長の表記法もしくは範囲のワイルドカードの表記法のパターンでもかまいません。 "*" という特別な表記法はすべてのアドレスを示します。同じアドレスでプレフィックス/プレフィックス長の表記法と，範囲のワイルドカード表記法を組み合わせないでください。アドレスの代わりにホスト名を指定しないでください。すべてのフィルターエントリには，一意のアドレス（単一，ワイルドカード，または範囲）が必要です。プレフィックス/プレフィックス長の表記法のアドレスの例は，次のとおりです。

10.2.112.0/20

1080:0:a00::/44

同じアドレスを，範囲のワイルドカード表記法で表すと次のようになります。

10.2.112-127.*

1080:0:a00-a0f:*:*:*:*:*

トラップOIDも，範囲またはワイルドカードとして指定することができます。一つのOIDでは，範囲またはワイルドカードのどちらかを使用します。OIDの最後のサブOIDだけを範囲またはワイルドカードとして指定します。".*"という特別な表記法はすべてのOIDを示しています。例は次のとおりです。

.1.3.6.1.4.1.11.2.17.1.0.58915834-58915868

.1.3.6.1.4.1.11.*

linkUpのような一般トラップについては，特定のベンダーをブロックするために，トラップOIDにベンダーのエンタープライズOIDを追加することができます。反対に，すべてのベンダーからの一般トラップをブロックするためには，トラップOIDにワイルドカードを追加する必要があります。

すべてのアドレスからすべてのトラップをブロックすることは許可されていません。このため，次のエントリは無視されます。

<*, .*>

フィルターの変更を実行中のNNMiに適用するには，次のコマンドを実行します。

nnmtrapconfig.ovpl -readFilter

EXAMPLES

次の例は，10.2.120から10.2.127の範囲のすべてのサブネットからのすべての一般トラップをブロックします。

<10.2.120.0/21, .1.3.6.1.6.3.1.1.5.*>

次の例は，10.6.112/21サブネットにあるエンタープライズOIDが.1.3.6.1.4.1.11.2.3.7.11.17であるすべてのデバイスからのlinkUpトラップをブロックします。

<10.6.112.0/21, .1.3.6.1.6.3.1.1.5.4.1.3.6.1.4.1.11.2.3.7.11.17>

次の例は，10.6.112/21サブネットにあるすべてのデバイスからのlinkUpトラップをブロックします。

<10.6.112.0/21, .1.3.6.1.6.3.1.1.5.4.*>

次の例は，一つのIPv6アドレスからの，OIDが .1.3.6.1.4.1.11.2.17で始まるすべてのトラップ，および認証失敗トラップをブロックします。

<1080::8:800:200c:417a, .1.3.6.1.4.1.11.2.17.*, .1.3.6.1.6.3.1.1.5.5.*>

AUTHOR

trapFilter.conf was developed by Micro Focus.

FILES

Windows：%NnmDataDir%shared¥nnm¥conf¥trapFilter.conf

Linux：$NnmDataDir/shared/nnm/conf/trapFilter.conf

SEE ALSO

nnmtrapconfig.ovpl.

付録I　各バージョンの変更内容

付録I.1　13-50の変更内容

(1)　資料番号（3021-3-L32-20）の変更内容

インストール前チェックリストのkernel.shmmaxおよびkernel.shmallの値に関する記載を変更した。

「NNMi をアンインストールする（Windows の場合）」の手順で，削除が必要な一時ディレクトリおよび一時ファイルに，次のディレクトリおよびファイルを追加した。

%TEMP%¥OpenTextInstaller¥

%TEMP%¥NNM_X.X_OpenTextInstaller.txt

「NNMi をアンインストールする（Linux の場合）」の手順で，削除が必要な一時ディレクトリおよび一時ファイルに，次のディレクトリおよびファイルを追加した。

/tmp/OpenTextInstaller

/tmp/NNM_X.X_OpenTextInstaller.txt

NNMiのインストール時の設定ファイルの内容がコピーされるフォルダについての説明を変更した。

server.properties，nms-auth-config.xmlの説明個所にNNMi の共有ディスク内のデータへの参照を追加した。

ライセンス情報を追跡する際の注意についての説明を変更した。

適用OSにWindows Server 2025を追加した。

NNMiが起動に成功した場合のコマンドの実行結果例を削除した。

HA構成の場合，設定ファイルを変更する際にローカルディスクではなく共有ディスクにコピーされたファイルの設定値を直接編集するよう，手順を追加した。

HAクラスタ内のアクティブなクラスタノードでのNNMiの設定解除について，nnmsetofficialfqdn.ovplコマンドの実行順序を変更した。

NNMi管理サーバーでアクションサーバーを実行するユーザー名を変更する手順を変更した。

「バージョン9・10・11・12 のNNMi からの移行」の説明を，13-50 へバージョンアップするための説明に変更した。

環境変数（%jdkdir%および$jdkdir）についての記載を削除した。

Nodedownインシデントのクローズについて記載を変更した。

NNMi管理サーバーで使用されるポートの一覧に，次のとおり追加した。

ポート20480と20481の目的にJP1/IM3連携を追加した。

ポート20482の設定の変更についての説明を追加した。

また，ファイアウォールの通過方向の表にポート番号20480と20481を追加した。

nnmincidentcfg.ovplコマンドにvalidateオプションを追加した。

nnmloadattributes.ovplコマンドにlistオプションを追加した。また，t オプションの説明を変更した。

nnmloadinterfacegroups.ovplコマンドにlistオプションを追加した。

nnmpseudoobject.ovplコマンドの説明を追加した。

NNMiデータ暗号化に関する記述を削除した。

付録I.2　13-10の変更内容

(1)　資料番号（3021-3-L32-10）の変更内容

Application Experienceサービスに関する記述を削除した。

次のトラップサーバープロパティを削除した。

com.hp.nms.trapd.updateSourcesPeriod

com.hp.nms.trapd.notifySourcesPeriod

com.hp.ov.nms.trapd.hosted.object.trapstorm.enabled

com.hp.ov.nms.trapd.hosted.object.trapstorm.threshold

com.hp.ov.nms.trapd.analysis.windowSize

com.hp.ov.nms.trapd.analysis.numSources

com.hp.ov.nms.trapd.rmiPort

com.hp.ov.nms.trapd.connectToWinSNMP

高可用性（HA）に関する記述を次のとおり追加・変更した。

CLUSTERPROの追加

Windowsの場合の説明を，WSFCも含める説明に変更

共有ディスクについての説明の追加

HA構成を解除する順番の説明の追加

SNMPv3以外で管理されているノードまたは監視対象外のノードのSNMPv3トラップを認証するための設定について記述を変更した。

NNMiの再起動後も設定を維持する手順にあるプロパティファイル内の検索用コメントを変更した。

Destination Unreachableを受信した場合でも，リトライ処理を継続するように設定する手順を追加した。

スタンドアロンのNNMi 管理サーバーのIPアドレスを変更した後の説明を変更した。

サポートするTLSプロトコルにTLSv1.3を追加した。

「バージョン9・10・11・12のNNMi からの移行」の説明を，13-10へバージョンアップするための説明に変更した。

SNMPv3通信の認証プロトコルの設定値を変更した。

nnmsamlconfig.ovplコマンドの説明を追加した。

付録I.3　13-00の変更内容

(1)　資料番号（3021-3-L32）の変更内容

LinuxサーバーにNNMiをインストールする際に必要なライブラリファイル，コマンド，およびパッケージを変更した。

次の適用OSを追加した。

Linux 9.1

Oracle Linux 9.1

また，次の適用OSを削除した。

Windows Server 2012

CentOS

Linux 6.1

Oracle Linux 6.1

WebブラウザのInternet Explorerのサポート終了に伴い，関連する記述を変更または削除した。

NNMiが使用するHTTPポートおよびHTTPSポートのデフォルト値を変更した。

systemdを使用しないディストリビューションに関する記述を削除した。

ノードグループのステータス設定時の［ステータスの設定］フォームのチェックボックスのタイトルを［最も重大なステータスに伝達］に変更した。

NNMiのインストール時の設定ファイルの内容のコピー先フォルダを変更した。

NNMiがサポートするSNMPv3通信の認証プロトコルを追加した。

ノードグループマップに背景イメージを追加する手順を変更した。

Subject Alternative Name（SAN）に関する記述を追加した。

Telnetクライアントが動作するWindowsオペレーティングシステムに関する説明を変更した。

HA設定の関連製品を使用する場合の注意を追加した。

NNMiノードのFQDN設定変更時に出力されるメッセージについての注意事項を変更した。

NNMiの自己監視で，ヘルスインシデントを抑制するための設定方法の説明を追加した。

NNMi管理サーバーのホスト名またはドメイン名の変更時の注意事項を追加した。

「バージョン 9・10・11・12のNNMiからの移行」の説明を，13-00へバージョンアップするための説明に変更した。

JP1/IM3のサポートに伴い，関連する記述を追加または変更した。

環境変数（%jdkdir%および$jdkdir）のパス名を変更した。

Administrator Commandsのリファレンスnnmnotes.ovplを追加した。

JKSリポジトリを使った証明書の使用に関する記載を削除した。

HP-UXまたはSolarisオペレーティングシステムからのNNMiの移行に関する記載を削除した。

バージョン8以前のJP1/Cm2/Network Node Manager（NNM）に関する記述を削除した。

JP1/Universal CMDB 10.3 Fullに関する記述を削除した。

付録I.4　12-60の変更内容

(1)　資料番号（3021-3-E02-30）の変更内容

Linuxの場合に設定できるロケールを変更した。

システムアカウントのパスワードをNNMiのインストール中に設定するように変更した。

NNMiのライセンスキーのフォーマット変更についての説明を追加した。

恒久ライセンスキーの申請に必要な情報を追加した。

NNMi設定ファイルのモデルファイルについての説明を追加した。

UndefinedSNMPTrapインシデントを複数回出すかどうかを指定する手順を追加した。

SNMPトラップのMIBデータの文字列を正しく解釈し表示する方法についての説明を変更した。

適用OSにWindows Server 2022 を追加した。

グローバルネットワーク管理の例で使用するスイッチ名を変更した。

グローバルネットワーク管理のアップグレード手順についての説明を追加した。

アプリケーションフェイルオーバー構成のアップグレードについて説明を追加した。

リファレンスページを追加した。

付録I.5　12-50の変更内容

(1)　資料番号（3021-3-E02-20）の変更内容

NNMi管理サーバーのインストール前チェックリストにkernel.shmallに関する説明を追加した。

NNMi をインストールする際に設定する環境変数として，LANG を追加した。

サポートしている証明書の形式について説明を追加した。

NNMiのインストール時に作成される証明書を置き換える手順を変更した。

複数のLDAPディレクトリサーバーのルートCA証明書をインポートする場合の説明を追加した。

Telnet およびSSH クライアントの設定対象として，Microsoft Edge を追加した。

Internet Explorer またはFirefox が動作するWindows オペレーティングシステムに関する説明を変更した。

serverエレメントに関する説明を変更した。

NNMiインストールスクリプトで設定するデフォルトのポート番号を追加した。

共有ディスクの使用条件を確認する手順を変更した。

インシデントの自動トリムを有効にする場合の式を変更した。

SNMP トラップインシデントの自動トリムを有効にする場合の式を変更した。

アーカイブファイルのローテーションに関する説明を追加した。

「バージョン9・10・11 のNNMi からの移行」の説明を，12-50 へバージョンアップするための説明に変更した。

NNMi管理サーバーが使用するポートの一覧で，ポート443の設定の変更について説明を追加した。

付録I.6　12-10の変更内容

(1)　資料番号（3021-3-E02-10）の変更内容

NNMi管理サーバーのインストール前チェックリストの説明を変更した。

Internet Explorerを使用する場合の互換表示設定について説明を追加した。

NNMiが必要とするパッケージとして，次の項目を追加した。

fontconfigパッケージ

liberation-sans-fonts パッケージ

libnsl パッケージ

WindowsシステムへのNNMiインストール完了の確認に関する説明を追加した。

ウイルスチェック除外設定の対象から，次のディレクトリを削除した。

/etc/opt/OV

systemd でサービスを管理しているディストリビューションの場合の説明を追加した。

インシデントの自動トリム設定に関する説明を追加または変更した。

NNMiをアンインストールしたあとに削除するディレクトリおよびファイルの対象を変更した。

自己署名証明書を生成する手順で，システムからプライベートキーを生成するコマンドを変更した。

CA署名証明書を生成する手順で，証明書をキーストアーファイルにインポートするコマンドを変更した。これに伴い，コマンドについてのメモを変更した。

トラストストアー証明書の所有者CNについて説明を追加した

Web ブラウザで使用するサードパーティ SSH クライアントを設定する手順を変更した。

「バージョン9・10・11 のNNMi からの移行」の説明を，12-10 へバージョンアップするための説明に変更した。

JP1/IM2 のインテリジェント統合管理基盤と連携について説明を追加した。

マニュアルで使用する環境変数についての説明を追加または削除した。

NodeOrConnectionDownインシデントに関する説明を変更した。

次の適用OSを追加した。

CentOS 8.1以降

Linux 8.1以降

Oracle Linux 8.1以降

Windows Server 2019

付録I.7　12-00の変更内容

(1)　資料番号（3021-3-E02）の変更内容

適用OSからWindows Server 2008 R2を削除した。

NNMi管理サーバーのインストール前チェックリストの説明を変更した。

NNMiコンソール用のWebブラウザの有効化で，Internet Explorerの設定についてのメモを変更した。

「NNMiをインストールする（Windowsの場合）」の説明に，次の項目を追加した。

インストール結果の確認

NNMiのインストール後に必要な作業として，次の項目を追加した。

ウイルス対策ソフトウェアのウイルスチェック除外設定をする

LinuxサーバーにNNMiをインストールしたあとに，言語環境を設定する手順の説明を変更した。

NNMiとNNMi Advancedの一時試用ライセンスを切り替える場合についての説明を追加した。

「NNMiをアンインストールする（Windowsの場合）」の手順で，削除が必要な一時ディレクトリおよび一時ファイルに，次のディレクトリおよびファイルを追加した。

%TEMP%¥MicroFocusOvInstaller¥

%TEMP%¥NNM_X.X.X_MicroFocusOvInstaller.txt

%TEMP%¥ovinstallparams.ini

%TEMP%¥nnmilog¥

<drive>:¥ProgramData¥apregid.com.hpe

「NNMiをアンインストールする（Linuxの場合）」の手順で，削除が必要な一時ディレクトリおよび一時ファイルに，次のディレクトリおよびファイルを追加した。

/var/tmp/jp1nnmi

/tmp/MicroFocusOvInstaller

/tmp/NNM_X.X.X_MicroFocusOvInstaller.txt

/usr/share/apregid.com.hpe

NNMiヘルプの詳細情報についての説明を削除した。

「仮想環境における通信の設定」のタイトルを，「VMwareハイパーバイザーベースの仮想ネットワークの検出と監視」に変更した。

ハイパーバイザー上の仮想ネットワークを検出して監視する場合に必要な設定の手順例，および注意事項を削除した。これに伴い，VMwareのデフォルト証明書を置き換える手順について，VMwareのドキュメントを参照するよう説明を変更した。

「ハイパーバイザーとの通信にHTTPSを使用するようにNNMiを設定する」の説明から，NNMi管理サーバーでTLSv1暗号プロトコルを有効にする手順を削除した。

「通信の設定」で，次の説明を追加した。

Cisco ACIネットワークの検出およびモニタリング

マルチホームNNMi管理サーバー

インシデントの概念の詳細について，NNMiヘルプの参照先を変更した。

トラップサーバープロパティcom.hp.ov.nms.trapd.recvSocketBufSizeのデフォルト値を変更した。

CA署名証明書を生成する手順で，次の説明を追加または変更した。

CSRファイルの内容を確認するコマンドについてのメモを追加した。

トラストストアーの出力形式の内容を変更した。

nnmkeytool.ovplコマンドでトラストストアーにアクセスする実行例に，storepassオプションを追加した。

ldap.propertiesファイルの廃止に伴い，関連する記述を変更または削除した。

NNMi IPv6管理機能でサポートしていない機能の記述から次の項目を削除した。

IPv6サブネット接続の検出

アプリケーションフェイルオーバーを設定するための前提条件に，IPv4アドレスに関する条件を追加した。

アプリケーションフェイルオーバーの設定手順で，どちらかのノードが複数のIPv4アドレスまたはNICを持つ場合の注意事項を追加した。

HAの設定完了後に，共有ディスクのマウントポイントを変更する場合の注意事項を追加した。

「NNMiの保守」から，次の説明を削除した。

厳格にSNMPv3インフォームを処理するようにNNMiを構成する

「NNMiセキュリティ」から，次の説明を削除した。

「NNMiがovjbossバージョン番号を報告しないように設定する」

「バージョン9・10・11のNNMiからの移行」の説明を，12-00へバージョンアップするための説明に変更した。

付録I.8　11-50の変更内容

(1)　資料番号（3021-3-A72-21）の変更内容

NNMi管理サーバーにNNMiをインストールする前のチェック項目として，インストールスクリプトの挙動とその対応に関する説明を追加した。

LinuxサーバーにNNMiをインストールするために必要なコマンドとして，unzipコマンドを追加した。

「通信の設定」で，次の説明を変更した。

SNMPプロキシを設定する

NNMi 11-50を新規インストールした環境で，TLSv1暗号プロトコルを使用する手順を追加した。

「NNMiでの証明書の使用」で，「PKCS #12形式」および「JKS形式」の証明書リポジトリを使用する場合の説明に変更した。それに伴い，次の説明を削除した。

アプリケーションフェイルオーバー機能でCA証明書を使用する

認証機関を使用するようにグローバルネットワーク管理機能を設定する

PKCS #12形式の証明書リポジトリのサポートに伴い，関連する説明を追加または変更した。

「NNMiでの証明書の使用」の説明を，JKS形式の証明書リポジトリを使用する場合の説明として変更した。また，次のトピックで，実行するコマンドを変更した。

自己署名証明書の生成

CA署名証明書の生成

アプリケーションフェイルオーバー機能で自己署名証明書を使用する

新規証明書を使用するように高可用性クラスタを設定する

ディレクトリサービスへのSSL 接続を設定する

LDAP 設定ファイルとして「nms-auth-config.xmlファイル」を追加した。それに伴い，関連する説明を追加，および既存のLDAP 設定ファイルである「ldap.propertiesファイル」の説明を変更した。

「タスク3：ディレクトリサービスからのユーザーアクセスを設定する」および「タスク5：（「外部モード」の設定だけ）ディレクトリサービスからのグループの取得を設定する」から，次の説明を削除した。

Microsoft Active Directoryの場合の簡単な方法

ほかのディレクトリサービスの場合の簡単な方法

LDAP設定ファイルの設定時，混合モードの場合は無視してよいメッセージについて，メモを追加した。

defaultRoleパラメーターの値を変更した場合に実行するコマンドを追加した。

「ユーザー識別」から，次の説明を削除した。

ディレクトリサービスからのNNMi ユーザーアクセスの設定（詳細な方法）

ディレクトリサービスでユーザーを識別する方法の判別（LDAPブラウザを使用する方法）

ディレクトリサービスでユーザーを識別する方法の判別（Webブラウザを使用する方法）

LDAP設定ファイルを「ldap.propertiesファイル」から「nms-auth-config.xml」に切り替える手順を追加した。

「グローバルネットワーク管理」の「初期準備」で，証明書の設定についての説明を変更した。また，次の説明を追加した。

バージョン11-50にアップグレードされたNNMi管理サーバー

NNMiへのHTTPアクセスについての説明を追加した。

異なるサーバーセット上のNNMiフェイルオーバー環境にリストアする場合の手順，およびそのリストアをする際に必要なバックアップについて，注記を追加した。

「高可用性クラスタにNNMiを設定する」で，次の説明を変更した。

仮想IPアドレスの変更

物理ホスト名の変更

HAクラスタ内のNNMiの設定を解除する

パッシブなクラスタノードでの設定解除

アクティブなクラスタノードでの設定解除

「NNMiの保守」で，次の説明を変更した。

通信設定の構成

リモートアクセスには暗号化を必須とするようにNNMiを設定する

Windows NNMi管理サーバーでのファイルパスの指定について，説明を変更した。

「SNMPトラップの管理」で，次の説明を追加した。

SNMPv1トラップまたはSNMPv2cトラップのブロック

「NNMiの保守」の「SNMPトラップインシデントの自動トリムを有効にする」で，説明中の値を変更した。

「物理センサーステータスの設定」の次のトピックで，プロパティファイルに挿入するテキストを変更した。

物理コンポーネントへの物理センサーステータスの伝達

物理コンポーネントに伝達しない物理センサーステータスの設定

物理センサーステータス値の上書き

「NNMiセキュリティ」で，次の説明を変更した。

TLSプロトコルの設定

「バージョン9・10・11のNNMiからの移行」の説明を，11-50へバージョンアップするための説明に変更した。また，次のトピックに，11-50にアップグレードした後の手順を追加した。

グローバルネットワーク管理のアップグレード手順

アプリケーションフェイルオーバー構成のNNMi 11-50 へのアップグレード

NNMi10-50で，UCMDBと連携した状態で11-00にアップグレートする場合に必要な設定についての説明を削除した。

「第8編　NNMiとの統合編」に，「30.　Restful API」を追加した。

環境変数（%jdkdir%および$jdkdir）の説明を追加した。

付録I.9　11-10の変更内容

(1)　資料番号（3021-3-A72-10）の変更内容

適用OSにWindows Server 2016を追加した。

LinuxサーバーにNNMiをインストールする場合に必要なライブラリファイルから，次のファイルを削除した。

/usr/lib/libstdc++.so.6

LinuxサーバーにNNMiをインストールしたあとに，言語環境を設定する手順の説明を変更した。

ライセンス情報を追跡する際の注意事項を追加した。

「初期スタートアップの問題」に，次の説明を追加した。

NNMiのインストールまたはアップグレードが正常に終了した後，NNMiコンソールが開かない

SNMPエージェントとWebエージェントが設定されている場合，NNMiは追加のプロトコルが使用できることの説明を追加した。

「SNMPアクセス制御」で，SNMPv3のプライバシプロトコルについての説明を変更した。

ハイパーバイザーNNMiを検出するには，管理アドレスではなくノード名が必要であることの説明を追加した。

仮想環境における通信の設定についての説明を追加した。

「通信設定を確認する」に，VMware通信の場合の説明を追加した。

「検出の概念」に，NNMiで検出されたノードの数がライセンスされた容量限界に到達または超えた場合の説明を追加した。

「応答のないオブジェクトを削除する」に，仮想マシンノードを削除しない条件についての説明を追加した。

「ステータスポーリングの計画」で，次の説明を追加または変更した。

NNMiで監視できる項目

監視の停止

監視されないノードへのインタフェース

モニタリングの拡張

ノードグループの説明に，デフォルトのノードグループに含まれる内容として「仮想マシン」を追加した。

State Pollerサービスで収集される情報に，「Webポーリング」の情報を追加した。

「State Poller稼働状態情報」の表に，「状態アップデータ例外」を追加した。

「トラップおよびNNMiインシデント転送でサポートされている方法」の表にある，「転送対象」の説明を変更した。

「NNMiコンソール」で，次の説明を追加または変更した。

分析ペインのゲージの設定

マップラベルのスケールサイズと境界の設定

Loom図およびWheel図の自動折りたたみしきい値の設定

「NNMiでの証明書の使用」で，次の説明を追加または変更した。

NNMi証明書について

既存の証明書と新規の自己署名証明書またはCA署名証明書との置き換え

「NNMiの保守」で，次の説明を追加または変更した。

MIBブラウザパラメータの変更

レベル2オペレータがノードおよびインシデントを削除できるように構成する

レベル2オペレータがマップを編集できるように構成する

「NNMiセキュリティ」に，次の説明を追加した。

TLSプロトコルの設定

「バージョン9・10・11のNNMiからの移行」に，次の説明を追加した。

バージョン11-00のNNMi管理サーバーをバージョンアップする

「HP-UXまたはSolarisオペレーティングシステムからのNNMiの移行」に，次の説明を追加した。

アプリケーションフェイルオーバー構成のHP-UXまたはSolarisからLinuxへのNNMiの変更

グローバルマネージャーとリージョナルマネージャーのHP-UXまたはSolarisからLinuxへのNNMiの変更

高可用性クラスタ（HA）構成のHP-UXまたはSolarisからLinuxへのNNMiの変更

新規インストール中に読み込むMIBから，次のMIBを削除した。

AX-BFD-MIB

AX-BOOTMANAGEMENT-MIB

AX-DEVICE-MIB

AX-FDB-MIB

AX-FLOW-MIB

AX-LOGIN-MIB

AX-MANAGEMENT-MIB

AX-NOTIFICATION

AX-OSPF-MIB

AX-OSPFV3-MIB

AX-QUEUE-MIB

AX-SMC-MIB

AX-SMCSERVICE-MIB

AX-SMI-MIB

AX-STATS-MIB

AX-SYSTEM-MIB

AX-TRACK-MIB

AX-VLAN-MIB

AX-VRF-MIB

AX1230S

AX1240S

AX2000R

AX2430S

AX2530S

AX3630S

AX4630S

AX5400S-TRAP

AX6300S

AX7700R-TRAP

AX7800R

AX7800R-TRAP

AX7800S

AX7800S-TRAP

AXS-6700S-TRAP

AXS-AX1240S-TRAP

AXS-AX1250S-TRAP

AXS-AX2230S-TRAP

AXS-AX3630S-TRAP

AXS-AX3640S-TRAP

AXS-AX3650S-TRAP

AXS-AX3830S-TRAP

AXS-AX4630S-TRAP

AXS-AX6300S-TRAP

AXS-AX6600S-TRAP

Apresia-Series

Apresia-SeriesLightFMGM

BFD-TC-STD-MIB

COMETAGT-AIX

COMETAGT-LINUX

COMETAGT-SOLARIS

COMETAGT-TRU64

RFC1253-MIB

cmSmsAgt

cometAgt

cometAgtEx

windowsNTAgt

NNMi環境変数の詳細リストから，次の環境変数を削除した。

%NNM_SUPPORT%　（Windows）

$NNM_SUPPORT　（Linux）

付録I.10　11-00の変更内容

(1)　資料番号（3021-3-A72）の変更内容

次の適用OSを追加した。

Windows Server 2008 R2 (x64) SP2

CentOS 6.1以降

CentOS 7.1以降

Linux 6.1 (x64)以降

Linux 7.1以降

Oracle Linux 6.1以降

Oracle Linux 7.1以降

SUSE Linux 12

次の適用OSを削除した。

HP-UX (IPF)

Solaris

「第1編　準備編」に，「1.　インストール前チェックリスト」，「2.　NNMiのインストールとアンインストール」を追加した。

「第2編　入門編」に，「3.　NNMi入門」を追加した。

デバイスと通信するためにNNMiでSNMPv3を使用する際に注意する点についての説明を追加した。

「付録」に「付録A　NNMiのmanページを表示できない場合（Linux)」と「付録B　新規インストール中に読み込むMIB一覧」を追加した。

リンクアグリゲーションを使用した検出についての説明を追加した。

SNMPトラップを受信したときにNNMiにデバイスをポーリングさせる方法についての説明を追加した。

NNMiにNATを実装する方法についての説明を，全面的に書き換えた。

静的NATのモニタリング，および動的NATのモニタリングの設定方法についての説明を追加した。

ネットワークアドレス変換（NAT）環境でNNMiを配備する手順を追加した。

管理アドレスポーリングを有効にした場合の，ICMP応答とSNMP応答の組み合わせによって決定される，SNMPエージェントステータスの計算についての説明を追加した。

リージョナルマネージャーからグローバルマネージャーへのカスタム属性の複製についての説明を追加した。

IPv6機能を再度アクティブにする手順を追加した。

ノードグループ設定をコマンドラインツールを使って自動化する方法を追加した。

ノードグループマップをコマンドラインツール使って設定する方法を追加した。

通信設定をコマンドラインツールで実施する方法を追加した。

server.propertiesファイルの設定を上書きする方法についての説明を追加した。

SNMPv1またはSNMPv2cを使用して管理されているノードまたは検出されていないノードのSNMPv3トラップを受信して保存するようにNNMiを設定する手順，およびCausal Engineがトラップの受け入れを停止する期間を設定する手順を追加した。

プロキシSNMPゲートウェイによって送信されたトラップから元のトラップアドレスを判別する手順を追加した。

SNMPv1およびSNMPv2cトラップアドレスの順序についての説明を追加した。

フェイルオーバー時にSNMPトラップの損失を最小限に抑えるのに役立つスタンドアロンNmsTrapReceiverプロセスについての説明を追加した。

NNMiを使用して任意のノードセットの停止をスケジュールする方法についての説明を追加した。

ステータスを監視するために，物理センサーステータスとノードセンサーステータスを設定する手順を追加した。

NNMiを設定してSSLv3サイファーを有効化または無効化する手順を追加した。

NNMiのデータ暗号化についての説明を追加した。

付録I.11　10-50の変更内容

(1)　資料番号（3021-3-242-20）の変更内容

インタフェースグループが検出除外インタフェース構成で使用されている場合の説明を追加した。

通信の設定にNETCONFを使用したデバイスのサポートの説明を追加した。

除外IPアドレス機能を使ったオブジェクトを検出しない方法の説明を変更した。

NNMi Northboundインタフェースの説明を追加した。

認証機関証明書を生成するときの，システムからプライベートキーを生成するコマンドのパラメータを変更した。

NNMiとLDAPによるディレクトリサービスの統合方法の説明を変更した。

オブジェクトのアクセス制限による影響の，マップおよびパスビューの項目についての説明を変更した。

アプリケーションフェイルオーバー機能の設定方法の説明を変更した。

アプリケーションフェイルオーバーのNNMiデータベースで，削除したスタンバイサーバーを再度同じクラスタに戻すときのコマンドを追加した。

通信障害後に再起動した際のアプリケーションフェイルオーバーの制御についての説明を追加した。

HAクラスタのソフトウェアとして，Symantec Cluster Server（SCS）を追加した。

HA設定の注意事項を追加した。

WSFCの各リソースの設定内容の例を追加した。

二次的な根本原因管理イベントに対するアクションを有効化する説明を追加した。

新しく作成した作成者を指定して，作成または変更する項目を変更した。

NNMi設定およびデータベースをシステム間で移動する場合のSSL証明書をマージする説明を追加した。

NNMi管理サーバーのホスト名またはドメイン名を変える説明を変更した。

次のNNMiセキュリティの説明を追加した。

組み込みデータベースツールのパスワードを入力する

NNMiがovjbossバージョン番号を報告しないように設定する

(2)　資料番号（3021-3-343-20）の変更内容

次の適用OSを追加した。

Microsoft(R) Windows Server(R) 2012 R2 Datacenter

Microsoft(R) Windows Server(R) 2012 R2 Standard

Windows Server 2008以降では，リモートデスクトップからコンソールセッションにログインできないため，関連する記述を削除した。

NNMi管理サーバーのインストール前チェックリストの説明を変更した。

「NNMiをインストールする（Windowsの場合）」の説明に，次の項目を追加した。

インストール前チェックの実施およびインストール続行可否の確認

「NNMiをインストールする（UNIXの場合）」の説明に，次の項目を追加した。

インストール前チェックの実施およびインストール続行可否の確認

NNMiのインストール後に必要な作業として，次の項目を追加した。

言語環境を設定する（UNIXの場合だけ）

Java最大ヒープサイズを確認する

「ディスクドライブのセキュリティ設定（Windowsの場合）」の手順の説明を変更した。

新規インストール中に読み込むMIBに，次のMIBを追加した。

AX-BOOTMANAGEMENT-MIB

AX-DEVICE-MIB

AX-FLOW-MIB

AX-LOGIN-MIB

AX-NOTIFICATION

AX-OSPF-MIB

AX-OSPFV3-MIB

AX-QUEUE-MIB

AX-SMI-MIB

AX-STATS-MIB

AX-SYSTEM-MIB

AX-VRF-MIB

インタフェースグループが検出除外インタフェース構成で使用されている場合の説明を追加した。

通信の設定にNETCONFを使用したデバイスのサポートの説明を追加した。

除外IPアドレス機能を使ったオブジェクトを検出しない方法の説明を変更した。

NNMi Northboundインタフェースの説明を追加した。

認証機関証明書を生成するときの，システムからプライベートキーを生成するコマンドのパラメーターを変更した。

NNMiとLDAPによるディレクトリサービスの統合方法の説明を変更した。

オブジェクトのアクセス制限による影響の，マップおよびパスビューの項目についての説明を変更した。

アプリケーションフェイルオーバー機能の設定方法の説明を変更した。

アプリケーションフェイルオーバーのNNMiデータベースで，削除したスタンバイサーバーを再度同じクラスタに戻すときのコマンドを追加した。

通信障害後に再起動した際のアプリケーションフェイルオーバーの制御についての説明を追加した。

HAクラスタのソフトウェアとして，Symantec Cluster Server（SCS）を追加した。

HA設定の注意事項を追加した。

WSFCの各リソースの設定内容の例を追加した。

二次的な根本原因管理イベントに対するアクションを有効化する説明を追加した。

新しく作成した作成者を指定して，作成または変更する項目を変更した。

NNMi設定およびデータベースをシステム間で移動する場合のSSL証明書をマージする説明を追加した。

NNMi管理サーバーのホスト名またはドメイン名を変える説明を変更した。

次のNNMiセキュリティの説明を追加した。

組み込みデータベースツールのパスワードを入力する

NNMiがovjbossバージョン番号を報告しないように設定する

付録I.12　10-10の変更内容

(1)　資料番号（3021-3-242-10）の変更内容

作成者属性の使用方法の説明を変更した。

メニューおよびメニュー項目の設定の説明を変更した。

監視設定をモニタリングの設定に変更した。

nnmconfigimport.ovplコマンドを使用して大量の設定をインポートする場合の注意事項を追加した。

次のSNMP通信の説明を追加した。

SNMPv3通信使用時の暗号方式を変更する

特定のデバイスのSNMP通信を有効または無効に設定できる

SNMPプロキシエージェントを使用した場合のSNMP通信手順

テナントを使用した重複アドレスドメインを含んだネットワークの場合の検出についての説明を追加した。

オブジェクトを検出しない設定に，除外対象IPアドレスを指定する方法と，除外対象インタフェースグループを指定する方法を追加した。

フィルタを定義して検出するインタフェース範囲を指定する方法の説明を追加した。

シードの検出で問題が起こった場合の対処として，該当するIPアドレスをipnolookup.confファイルに含める方法の説明を追加した。

応答のないオブジェクトを削除する場合の説明を変更した。

NNMiステータスポーリングで次の項目を変更した。

プロキシサーバーではなく，スイッチに変更した

監視するインタフェースグループとノードグループの設定方法の説明を変更した

NNMiインシデントについて次の説明を追加または変更した。

インシデントの概念

トラップおよびインシデント転送

受信済みSNMPトラップ

解決済み管理イベントインシデントに追加されるCIA

インシデントに対するNNMiの対応方法を計画する

トラップログの設定方法

インシデントログの設定方法

トラップサーバープロパティの設定方法

インシデント設定のバッチロード

インシデントの評価

インシデントの調整

NNMiコンソールについて次の説明を追加または変更した。

ノードグループを作成する

ノードグループマップを設定する

ノードグループを削除する

分析ペインを無効にする

デバイスのアイコンをカスタマイズする

テーブルビューのリフレッシュレートをオーバーライドする

NNMiでの証明書の使用方法で次の手順を変更した。

認証機関証明書を生成する

ディレクトリサービスへのSSL接続の設定の説明を変更した。

次のNNMiとLDAPによるディレクトリサービスの統合の説明を変更した。

NNMiユーザーのアクセス情報と設定の方法

ディレクトリサービスへのアクセスを設定する

ディレクトリサービスのアクセス設定にNNMiのセキュリティモデルを設定する

ディレクトリサービス管理者が所有する情報

ディレクトリサービス統合のトラブルシューティング

NNMiグローバルオペレータユーザーグループ（globalops）では，すべてのトポロジオブジェクトだけにアクセス権が与えられることを記載した。

NAT環境の設定方法を追加した。

NNMiのセキュリティおよびマルチテナントの設定の説明を変更した。

グローバルネットワーク管理の場合，NAT，PATおよびNAPTのときの注意事項を追加した。

初期準備のファイアウォールの設定で，アクセス可能にしておく必要があるソケットのパラメータを変更した。

グローバルネットワーク管理でNNMiウィンドウおよび説明を変更した。

グローバルネットワーク管理のトラブルシューティングのヒントで次の説明を変更した。

グローバルマネージャとリージョナルマネージャの検出情報の同期

グローバルネットワーク管理環境でのNNMiのバージョンアップ手順の説明を変更した。

グローバルネットワーク管理とアドレス変換プロトコルの説明を追加した。

NNMi IPv6管理機能で次の説明を追加または変更した。

NNMi IPv6管理機能の概要

NNMi IPv6管理機能を使用するための必要条件

IPv6管理機能を有効にする

IPv6管理機能を無効にしたあとのIPv6インベントリ

アプリケーションフェイルオーバーを設定するための前提条件を追加した。

次のアプリケーションフェイルオーバーの設定方法を追加または変更した。

アプリケーションフェイルオーバー構成のNNMiを設定する

クラスタセットアップウィザードを使用したアプリケーションフェイルオーバーの設定方法

アプリケーションフェイルオーバー通信の設定方法

アプリケーションフェイルオーバーの動作

アプリケーションフェイルオーバーシナリオ

アプリケーションフェイルオーバーを無効にする

NNMiのバージョンアップ（修正版の適用を含む）

NNMiデータベースパスワードの変更

HAの設定で説明を追加または変更した。

HA用NNMiを設定するための前提条件の検証

NNMi HA設定情報

プライマリクラスタノードでのNNMiの設定

セカンダリクラスタノードでのNNMiの設定

パッシブなクラスタノードでの設定解除

アクティブなクラスタノードでの設定解除

NNMiデータのバックアップの説明を変更した。

NNMiの保守で次の説明を追加または変更した。

フォルダのアクセス権限の管理

アクションサーバーのキューサイズを変更する

インシデントアクションのログ

文字セットエンコードの設定方法

レベル2オペレータがノードを削除できるように構成する

レベル2オペレータがマップを編集できるように構成する

レベル2オペレータがステータスのポーリングおよび設定のポーリングを実行できるように構成する

監視対象外のノードについてSNMPv3トラップを認証するようにNNMiを構成する

プロキシSNMPゲートウェイによって送信されたトラップからオリジナルトラップアドレスを特定するようにNNMiを構成する

リモートアクセス時に暗号化を必須とするようにNNMiを設定する

厳格にSNMPv3インフォームを処理するようにNNMiを構成する

以前にサポートされていたvarbind順序を保持するようにNNMiを構成する

データベースポートを変更する

NNMi管理サーバーのホスト名，ドメイン名，またはその両方を変更する場合に，新しい証明書でHTTPS設定を更新する説明を変更した。

バージョン9・10-00のNNMiからの移行で次の説明を追加した。

バージョン10-00のNNMi管理サーバーのバージョンアップ

バージョン9のNNMi管理サーバーのバージョンアップ

NNMi 10-00以前からのグローバルマネージャとリージョナルマネージャのアップグレードの方法

アプリケーションフェイルオーバー構成のNNMi 10-10へのアップグレードの方法

バージョン8以前のNNMからの移行で次の説明を変更した。

SNMPを設定する

デバイスプロファイルをカスタマイズする

検出のスケジュールを設定する

自動検出ルールを設定する

ポーリング間隔を設定する

ポーリングプロトコルを選択する

デバイスからのトラップを表示する

環境変数のデフォルトの場所を変更した。

NNMiが使用するポートの一覧を変更した。

(2)　資料番号（3021-3-343-10）の変更内容

Windows Server 2012に対応する説明を追加した。

ノードを検出する場合，ネットワークアドレス変換（NAT）を使用したときの注意事項を追加した。

クイックスタート設定ウィザードの画面と説明を変更した。

NNMiをアンインストールする場合の説明を変更した。

NNMiヘルプウィンドウおよび［通信の設定］フォームを変更した。

Windowsの場合のディスクドライブのセキュリティ設定の説明を追加および変更した。

Webブラウザの有効化の設定項目および手順の説明を変更した。

Linuxへの必要なライブラリのインストールの説明を追加および変更した。

インストールの問題に次の内容を追加した。

インストール時に，プレインストール手順（フェーズII）に失敗し，/tmp/nnm_preinstall_phaseII.logファイルで詳細を確認する必要があることを示すメッセージが表示される

新規インストール中に読み込むMIB一覧の説明を追加および変更した。

作成者属性の使用方法の説明を変更した。

メニューおよびメニュー項目の設定の説明を変更した。

監視設定をモニタリングの設定に変更した。

nnmconfigimport.ovplコマンドを使用して大量の設定をインポートする場合の注意事項を追加した。

次のSNMP通信の説明を追加した。

SNMPv3通信使用時の暗号方式を変更する

特定のデバイスのSNMP通信を有効または無効に設定できる

SNMPプロキシエージェントを使用した場合のSNMP通信手順

テナントを使用した重複アドレスドメインを含んだネットワークの場合の検出についての説明を追加した。

オブジェクトを検出しない設定に，除外対象IPアドレスを指定する方法と，除外対象インタフェースグループを指定する方法を追加した。

フィルタを定義して検出するインタフェース範囲を指定する方法の説明を追加した。

シードの検出で問題が起こった場合の対処として，該当するIPアドレスをipnolookup.confファイルに含める方法の説明を追加した。

応答のないオブジェクトを削除する場合の説明を変更した。

NNMiステータスポーリングで次の項目を変更した。

プロキシサーバーではなく，スイッチに変更した

監視するインタフェースグループとノードグループの設定方法の説明を変更した

NNMiインシデントについて次の説明を追加または変更した。

インシデントの概念

トラップおよびインシデント転送

受信済みSNMPトラップ

解決済み管理イベントインシデントに追加されるCIA

インシデントに対するNNMiの対応方法を計画する

トラップログの設定方法

インシデントログの設定方法

トラップサーバープロパティの設定方法

インシデント設定のバッチロード

インシデントの評価

インシデントの調整

NNMiコンソールについて次の説明を追加または変更した。

ノードグループを作成する

ノードグループマップを設定する

ノードグループを削除する

分析ペインを無効にする

デバイスのアイコンをカスタマイズする

テーブルビューのリフレッシュレートをオーバーライドする

NNMiでの証明書の使用方法で次の手順を変更した。

認証機関証明書を生成する

ディレクトリサービスへのSSL接続の設定の説明を変更した。

次のNNMiとLDAPによるディレクトリサービスの統合の説明を変更した。

NNMiユーザーのアクセス情報と設定の方法

ディレクトリサービスへのアクセスを設定する

ディレクトリサービスのアクセス設定にNNMiのセキュリティモデルを設定する

ディレクトリサービス管理者が所有する情報

ディレクトリサービス統合のトラブルシューティング

NNMiグローバルオペレータユーザーグループ（globalops）では，すべてのトポロジオブジェクトだけにアクセス権が与えられることを記載した。

NAT環境の設定方法を追加した。

NNMiのセキュリティおよびマルチテナントの設定の説明を変更した。

グローバルネットワーク管理の場合，NAT，PATおよびNAPTのときの注意事項を追加した。

初期準備のファイアウォールの設定で，アクセス可能にしておく必要があるソケットのパラメーターを変更した。

グローバルネットワーク管理でNNMiウィンドウおよび説明を変更した。

グローバルネットワーク管理のトラブルシューティングのヒントで次の説明を変更した。

グローバルマネージャーとリージョナルマネージャーの検出情報の同期

グローバルネットワーク管理環境でのNNMiのバージョンアップ手順の説明を変更した。

グローバルネットワーク管理とアドレス変換プロトコルの説明を追加した。

NNMi IPv6管理機能で次の説明を追加または変更した。

NNMi IPv6管理機能の概要

NNMi IPv6管理機能を使用するための必要条件

IPv6管理機能を有効にする

IPv6管理機能を無効にしたあとのIPv6インベントリ

アプリケーションフェイルオーバーを設定するための前提条件を追加した。

次のアプリケーションフェイルオーバーの設定方法を追加または変更した。

アプリケーションフェイルオーバー構成のNNMiを設定する

クラスタセットアップウィザードを使用したアプリケーションフェイルオーバーの設定方法

アプリケーションフェイルオーバー通信の設定方法

アプリケーションフェイルオーバーの動作

アプリケーションフェイルオーバーシナリオ

アプリケーションフェイルオーバーを無効にする

NNMiのバージョンアップ（修正版の適用を含む）

NNMiデータベースパスワードの変更

HAの設定で説明を追加または変更した。

HA用NNMiを設定するための前提条件の検証

NNMi HA設定情報

プライマリクラスタノードでのNNMiの設定

セカンダリクラスタノードでのNNMiの設定

パッシブなクラスタノードでの設定解除

アクティブなクラスタノードでの設定解除

NNMiデータのバックアップの説明を変更した。

NNMiの保守で次の説明を追加または変更した。

フォルダのアクセス権限の管理

アクションサーバーのキューサイズを変更する

インシデントアクションのログ

文字セットエンコードの設定方法

レベル2オペレータがノードを削除できるように構成する

レベル2オペレータがマップを編集できるように構成する

レベル2オペレータがステータスのポーリングおよび設定のポーリングを実行できるように構成する

監視対象外のノードについてSNMPv3トラップを認証するようにNNMiを構成する

プロキシSNMPゲートウェイによって送信されたトラップからオリジナルトラップアドレスを特定するようにNNMiを構成する

リモートアクセス時に暗号化を必須とするようにNNMiを設定する

厳格にSNMPv3インフォームを処理するようにNNMiを構成する

以前にサポートされていたvarbind順序を保持するようにNNMiを構成する

データベースポートを変更する

NNMi管理サーバーのホスト名，ドメイン名，またはその両方を変更する場合に，新しい証明書でHTTPS設定を更新する説明を変更した。

バージョン9・10-00のNNMiからの移行で次の説明を追加した。

バージョン10-00のNNMi管理サーバーのバージョンアップ

バージョン9のNNMi管理サーバーのバージョンアップ

NNMi 10-00以前からのグローバルマネージャーとリージョナルマネージャーのアップグレードの方法

アプリケーションフェイルオーバー構成のNNMi 10-10へのアップグレードの方法

バージョン8以前のNNMからの移行で次の説明を変更した。

SNMPを設定する

デバイスプロファイルをカスタマイズする

検出のスケジュールを設定する

自動検出ルールを設定する

ポーリング間隔を設定する

ポーリングプロトコルを選択する

デバイスからのトラップを表示する

環境変数のデフォルトの場所を変更した。

NNMiが使用するポートの一覧を変更した。

付録J　このマニュアルの参考情報

このマニュアルを読むに当たっての参考情報を示します。

付録J.1　関連マニュアル

このマニュアルの関連マニュアルを次に示します。必要に応じてお読みください。

JP1 Version 13 ネットワーク管理 基本ガイド（3021-3-L31）

JP1 Version 13 JP1/Network Node Manager i Developer's Toolkit ガイド（3021-3-L33）

付録J.2　このマニュアルでの表記

このマニュアルでは，日立製品およびそのほかの製品の名称を省略して表記しています。製品の正式名称と，このマニュアルでの表記を次の表に示します。

このマニュアルでの表記

正 式 名 称

Firefox

Mozilla Firefox(R)

JP1/IM2

JP1/Integrated Management 2

JP1/IM3

JP1/Integrated Management 3

Linux

Linux 7.1

Red Hat Enterprise Linux(R) Server 7.1（64-bit x86_64）

Linux 8.1

Red Hat Enterprise Linux(R) Server 8.1（64-bit x86_64）

RHEL 8.1

Linux 9.1

Red Hat Enterprise Linux(R) Server 9.1（64-bit x86_64）

Oracle Linux 7.1

Oracle Linux(R) Operating System 7.1

Oracle Linux 8.1

Oracle Linux(R) Operating System 8.1

Oracle Linux 9.1

Oracle Linux(R) Operating System 9.1

SUSE Linux 12

SUSE Linux(R) Enterprise Server 12

NNMi

NNMi

JP1/Network Node Manager i

NNMi Advanced

JP1/Network Node Manager i Advanced

付録J.3　このマニュアルで使用する英略語

このマニュアルで使用する英略語を，次の表に示します。

このマニュアルでの表記

正式名称

ACL

Access Control List

APA

Active Problem Analyzer

ARP

Address Resolution Protocol

BIND

Berkeley Internet Name Domain

CA

Certification Authority

CIA

Custom Incident Attribute

DNS

Domain Name System

FQDN

Fully Qualified Domain Name

HSRP

Hot Standby Routing Protocol

HTTP

Hypertext Transfer Protocol

HTTPS

Hypertext Transfer Protocol Security

ICMP

Internet Control Message Protocol

IPF

Itanium(R) Processor Family

ISP

Internet Services Provider

IT

Information Technology

MD5

Message Digest 5

MIB

Management Information Base

NFS

Network File System

NOC

Network Operations Center

REST

REpresentational State Transfer

SCS

Symantec Cluster Server※

SHA

Secure Hash Algorithm

SNMP

Simple Network Management Protocol

TCP/IP

Transmission Control Protocol/Internet Protocol

TLS

Transport Layer Security

UUID

Universally Unique IDentifier

VCS

Veritas Cluster Server※

VLAN

Virtual LAN

VRRP

Virtual Router Redundancy Protocol

WAN

Wide Area Network

注※

JP1 10-50以降では，Veritas Cluster ServerまたはSymantec Cluster Serverをサポートしています。JP1 10-10以前では，Veritas Cluster Serverをサポートしています。

付録J.4　このマニュアルで使用する記号

このマニュアルで使用する記号を次に示します。

記 号

説 明

［ ］

メニュー項目やボタンを表します。

［ ］＞［ ］

メニュー項目を連続して選択することを表します。

［Enter］キーを押すことを表します。

付録J.5　KB（キロバイト）などの単位表記について

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

付録K　用語解説

A

ARPキャッシュ

ARP（アドレス解決プロトコル）キャッシュは，データリンク層（OSIレイヤー2）アドレスをネットワーク層（OSIレイヤー3）アドレスにマップするオペレーティングシステムテーブルです。データリンク層アドレスは通常はMACアドレスですが，ネットワーク層アドレスは通常はIPアドレスです。ルールベースの検出では，NNMiは，検出されたノードでARPキャッシュエントリ（ならびにほかのテクニック）を使って，現在の検出ルールに照らしてチェックできる追加ノードを見つけます。

C

Causal Engine

因果関係ベースの方法を使って，根本原因解析（RCA）をネットワーク現象に適用するNNMiテクノロジ。Causal Engine RCAのきっかけとなるのは，ステータスポーリング，SNMPトラップ，特定のインシデントの結果として検出された変更など，特定の事象です。Causal EngineはRCAを使って，管理対象オブジェクトのステータスを調べ，これらオブジェクトに関する結論を明確化し，根本原因インシデントを生成します。

H

HA

「高可用性」を参照してください。

HAリソースグループ

Veritas Cluster Server，Symantec Cluster Server，Microsoft Cluster Serviceなどの最新の高可用性環境では，アプリケーションは，アプリケーション自体，その共有ファイルシステム，仮想IPアドレスのようなリソースの複合物として表されます。リソースはHAリソースグループで構成されます。これはクラスタ環境で実行中のアプリケーションを表します。

I

ICMP

「インターネット制御メッセージプロトコル」を参照してください。

J

JBossアプリケーションサーバー

Java Platform, Enterprise Edition（Java EE），Enterprise Java Beans（EJB）と組み合わせて使用するアプリケーションサーバープログラムです。

L

L2

「レイヤー2」を参照してください。

L3

「レイヤー3」を参照してください。

M

MIB

「管理情報ベース」を参照してください。

N

NNMi

JP1/Network Node Manager iおよびJP1/Network Node Manager i Advancedの略称です。

ネットワーク管理の支援や統合のために設計されたソフトウェア商品です。ネットワークノードの継続検出，イベントの監視，ネットワーク障害管理といった機能を備えています。主にNNMiコンソールからアクセスします。

NNMi Northboundインタフェース

NNMiインシデントをSNMPv2cトラップとしてNorthboundアプリケーションに転送するNNMiの機能です。

NNMi管理サーバー

NNMiソフトウェアがインストールされ，NNMiプロセスやサービスが実行されるコンピュータシステムのことです。

NNMiコンソール

NNMiユーザーインタフェース。オペレータや管理者は，NNMiコンソールを使用してNNMiネットワーク管理タスクを実行できます。

NNMイベント

古いNNM管理ステーションからNNMiに転送されたイベント用のNNMi用語。NNMiには，転送されたイベントからNNMiが生成するインシデントを参照するためのインシデントビューがあります。

Northboundアプリケーション

SNMPv2cトラップを受信および処理できる任意のアプリケーションです。

Northbound転送先

Northboundアプリケーションのトラップ受信コンポーネントへの接続を定義し，NNMiがそのNorthboundアプリケーションに送信するトラップのタイプを指定するNNMi Northboundインタフェースの設定の1つです。

O

OID

「オブジェクト識別子」を参照してください。

ovstartコマンド

NNMiの管理プロセスを起動するためのコマンドです。コマンドプロンプトで起動します。ovstartのリファレンスページを参照してください。

ovstatusコマンド

NNMiが管理するプロセスの現在のステータスを報告するコマンドです。NNMiコンソール（［ツール］＞［NNMiステータス］）またはコマンドプロンプトで起動できます。ovstatusのリファレンスページを参照してください。

ovstopコマンド

NNMiの管理プロセスを停止するためのコマンドです。コマンドプロンプトで起動します。ovstopのリファレンスページを参照してください。

P

Pingスイープ

ICMP ECHO要求を複数のIPアドレスに送信し，応答するノードにどのアドレスが割り当てられているか調べるネットワークプローブテクニック。ルールベースの検出で有効にすると，NNMiは，設定されたIPアドレスの範囲でPingスイープを使用して，そのほかのノードを検索できます。サービスの拒絶にPingスイープを使用できるので，ICMP ECHO要求をブロックするネットワーク管理者もいます。

PostgreSQL

トポロジ，インシデント，設定情報のような情報を保存するためにNNMiがデフォルトで使用するオープンソースリレーショナルデータベース。

R

RCA

「根本原因解析」を参照してください。

S

SNMP

「簡易ネットワーク管理プロトコル（SNMP）」を参照してください。

SNMPトラップ

ポーリングを使ったネットワーク管理（SNMP マネージャーからの要求とSNMP エージェントからの応答）は，処理をできるだけ簡単にするためのSNMPの設計原則です。しかし，このプロトコルは，SNMPエージェントからSNMPマネージャープロセス（この場合，NNMi）への要請されないメッセージの通信も提供します。要請されないエージェントメッセージは，「トラップ」として知られており，内部状態の変化または障害条件に応答してSNMPエージェントが生成します。NNMiは，受信したSNMPトラップ（［SNMPトラップ］インシデントの参照ビューに表示）からインシデントを生成します。

SNMPトラップストーム

要請されない大量のSNMPエージェントメッセージ。SNMPマネージャープロセス（この場合，NNMi）を圧迫する可能性があります。nnmtrapconfig.ovplコマンドを使用してNNMiにSNMPトラップストームしきい値を指定できます。受信トラップレートが指定のしきい値レートを超えるとき，NNMiは，トラップレートが再対応レート未満に下がるまでトラップをブロックします。

sysObjectID

「システムオブジェクトID」を参照してください。

あ

アカウント

「ユーザーアカウント」を参照してください。

アクティブなクラスタノード

アプリケーションフェイルオーバーまたは高可用性設定でNNMiプロセスを現在実行しているサーバーです。

アドレスのヒント

「検出のヒント」を参照してください。

アプリケーションフェイルオーバー

NNMiで，現在アクティブなサーバーが停止した場合に，NNMiのプロセスの制御をスタンバイサーバーに移行するオプション機能です。このオプション機能はユーザーが設定する必要があります。また，JBossクラスタリングサポートを利用しています。

い

因果関係

あるイベント（原因）と別のイベント（影響）の間の関係を示します。イベント（影響）は最初のイベント（原因）の直接的な結果です。NNMiは，因果関係分析アルゴリズムを使用して，イベントのサイクルを分析し，ネットワーク問題を解決するソリューションを明らかにします。

インシデント

NNMiでは，ネットワークに関連する事象の通知は，NNMiコンソールインシデントビューとフォームに表示されます。NNMiには，インシデント属性に基づいてユーザーがインシデントをフィルタできるようにする幾つもの［インシデントの管理］ビューと［インシデントの参照］ビューがあります。ほとんどのインシデントビューには，NNMi（管理イベントと呼ばれることもあります）が直接生成したインシデントが表示されます。NNMiには，SNMPトラップから生成されたインシデントおよびNNMイベントから生成されたインシデントを参照するビューもあります。

インターネット制御メッセージプロトコル

中核的なインターネットプロトコルスイート（TCP/IP）の1つです。ICMP pingは，状態ポーリング用のSNMPクエリーとともにNNMiで使用されます。

インタフェース

ネットワークで用いられる各仕様や規約を利用するための論理的な接続端。

インタフェースグループ

NNMiの主要なフィルタテクニックの1つ。ただし，グループごとに，グループまたはフィルタ視覚化に設定を適用する目的で，インタフェースはグループにまとめられます。インタフェースグループは，監視の設定，テーブルビューのフィルタ，マップビューのカスタマイズのどれか，またはすべてに使用できます。「ノードグループ」も参照してください。

え

エピソード

NNMi根本原因解析で，特定の持続時間を指すのに使う用語。この持続時間は一次的な障害によって引き起こされ，その間，二次障害は抑制されるか，または一次的障害の下で相互に関連づけられます。

お

オブジェクト識別子

SNMPで，管理情報ベースデータオブジェクトを識別する数字のシーケンスです。OIDは，小数点で分離された数字で構成されます。各数字は，MIB階層のそのレベルにおける特定のデータオブジェクトを表します。OIDはMIBオブジェクト名と同等の数字です。例えば，MIBオブジェクト名iso.org.dod.internet.mgmt.mib-2.bgp.bgpTraps.bgpEstablishedはそのOID 1.3.6.1.2.1.15.0.1と同等です。

か

仮想IPアドレス

特定のネットワークハードウェアに結び付かれていないIPアドレス。現在のフェイルオーバーまたはロードバランシングのニーズに基づいて，最も該当するサーバーに中断されないネットワークトラフィックを送信するため，高可用性設定で使われます。

仮想ホスト名

仮想IPアドレスと関連づけられたホスト名。

簡易ネットワーク管理プロトコル（SNMP）

OSIモデルのアプリケーション層（レイヤー7）で機能する簡易なプロトコルです。リモートユーザーは，このプロトコルによって，ネットワーク要素の管理情報を検査または変更できます。SNMPは，管理対照ノード上のエージェントプロセッサーとネットワーク管理情報を交換するためにNNMiが使う主要なプロトコルです。NNMiは，SNMPの最も一般的なバージョンであるSNMPv1，SNMPv2c，およびSNMPv3の3つをサポートしています。

管理サーバー

NNMi管理サーバーは，NNMiがインストールされるコンピュータシステムです。NNMiのプロセスとサービスは，NNMi管理サーバーで稼働します（以前のNNMリビジョンはこのシステムについて「NNM管理ステーション」という用語を使用していました）。

管理情報ベース

SNMPで，管理対照ネットワークに関するデータの階層的に組織化された集合のことです。管理情報ベース内のデータオブジェクトは管理対照デバイスの特色を参照します。NNMiは，ネットワーク管理情報を収集する場合，MIBデータオブジェクト（「MIBオブジェクト」，「オブジェクト」，「MIB」と呼ばれることもあります）を使用して，管理対象ノードとの間でSNMPクエリーを出し，またはSNMPトラップを受け取ります。

く

クイックスタート設定ウィザード

クイックスタート設定ウィザードは，NNMiのインストールが完了した直後に自動的に実行されます。クイックスタート設定ウィザードを使用して，SNMPv1またはSNMPv2c環境の読み取りコミュニティ文字列を準備したり，検出されるノードの範囲に制限を設定したり，管理者アカウントを設定したりできます。

クラスタ

NNMiの関係では，高可用性テクノロジまたはjbossクラスタ化機能の使用によってリンクされるハードウェアおよびソフトウェアのグループ化のことです。これらは，一緒に機能して，コンポーネントに過剰負荷または障害が発生した場合，機能とデータの連続性を確保します。クラスタ内のコンピュータは一般に高速LAN経由でお互いに接続されます。クラスタは，通常，可用性またはパフォーマンス，もしくはその両方を向上させるために導入します。

クラスタメンバーまたはノード

NNMiの関係では，NNMi高可用性またはアプリケーションフェイルオーバーをサポートするよう設定された，または設定される予定の高可用性またはjbossクラスタ内のシステム。

グローバルネットワーク管理

地理的に分散している1つ以上のリージョナルマネージャーからのデータを統合する1つ以上のグローバルマネージャーを持つ，NNMiの分散型の配備です。

グローバルマネージャー

分散NNMiリージョンマネージャーサーバーからのデータを統合する，グローバルネットワーク管理配備内のNNMi管理サーバーです。グローバルマネージャーは，環境全体のトポロジおよびインシデントの統合ビューを提供します。グローバルマネージャーには，NNMi Advancedライセンスが必要です。

け

結論

NNMiで，管理対象オブジェクト用にCausal Engineがステータスと根本原因インシデントを決定した方法を明らかにするCausal Engineが生成および使用するサポート詳細。

検出シード

「シード」を参照してください。

検出のヒント

SNMP ARPキャッシュクエリー，CDP，EDP，またはその他の検出プロトコルクエリー，またはpingスィープを使用してNNMiが見つけたIPアドレスです。NNMiはさらに，検出ヒントとして見つかったIPアドレスについてクエリーを実行し，結果をルールベース検出内の現在の検出ルールに照らしてチェックします。

検出プロセス

NNMiが，ネットワークノードを管理下におくために，これらの情報を収集するプロセス。初期検出は，まずデバイスインベントリの情報を収集し，次にネットワーク接続情報を収集するという2つのフェーズのプロセスで実行されます。

最初の検出のあとも検出プロセスは継続されます。つまり，リストに基づいた検出では，シードリスト内のデバイスは，設定が変更されると更新されます。ルールベースの検出では，新しいデバイスは現在の検出ルールに合致すると追加されます。検出プロセスは，NNMiコンソールまたはコマンドラインから，デバイスまたはデバイスセットについてオンデマンドで開始できます。

「スパイラル検出」，「ルールベースの検出」および「リストに基づいた検出」も参照してください。

検出ルール

ルールベース検出プロセスを制限するのに使用される，ある範囲のユーザー定義IPアドレスかシステムオブジェクトID（オブジェクト識別子），またはその両方です。検出ルールは，NNMiコンソールの［自動検出ルール］の［検出の設定］部分に設定します。「ルールベースの検出」も参照してください。

こ

高可用性

このマニュアルでは，設定の一部に障害があっても中断されないサービスを提供するハードウェアおよびソフトウェアの設定のことです。高可用性（HA）とは，コンポーネントに障害があった場合でもアプリケーションを実行し続けるよう冗長コンポーネントを備えた構成を意味します。NNMiは，市販されている幾つかのHAソリューションの1つをサポートするように設定できます。「アプリケーションフェイルオーバー」も参照してください。

コミュニティ文字列

SNMPエージェントでSNMPクエリーを認証するために，SNMPv1およびSNMPv2Cシステムで使用されるパスワードのような仕組み。コミュニティ文字列はSNMPパケット内のクリアテキストに渡されるので，パケット傍受に対してもろくなります。SNMPv3は，認証用の強力なセキュリティメカニズムを用意します。

コンソール

「NNMiコンソール」を参照してください。

コントローラ

NNMiアプリケーションフェイルオーバーでの，マスタークラスタの状態を持つクラスタメンバーを表すJGroups用語。コントローラは，常にクラスタで最も古いメンバーです。

根本原因インシデント

Correlation Nature（相関関係の性質）属性がRoot Cause（根本原因）に設定されているNNMiインシデント。NNMiは，関連問題の現象が処理されていない場合，根本原因解析（RCA）を使って現象をすぐ解決できる課題として根本原因インシデントを確定します。「根本原因解析」を参照してください。

根本原因解析

NNMiで，根本原因解析（RCA）とは，ネットワーク問題の原因を調べるためにNNMiが使う問題解決方法のクラスのことです。根本原因とは，解決されることによって，関連づけられた問題の症状も解決するような問題のことです。NNMiは，次の2つの主要な方法で根本原因の識別を使います。根本原因が解決されるまで，すぐに実施できる問題についてユーザーに通知し，二次的問題の現象を報告しないようにします。根本原因を判別すると，管理対象オブジェクトのステータス変更または根本原因インシデント，もしくはその両方の生成が行われることがあります。

NNMiがRCAを使用する例として，管理対象ルーターで障害が発生し，NNMi管理サーバーから見てルーターの反対側にある管理対象ノードがステータスポーリングクエリーに応答できなくなることが挙げられます。NNMiはRCAを使用し，ステータスポーリング障害が二次的問題の現象であるか調べます。ルーターが根本原因インシデントであることを報告し，根本原因ルーター障害が解決されるまでダウンストリームノードで発生している問題の現象を報告することは差し控えます。

し

シード

ネットワーク検出プロセスの開始点として機能することによって，NNMiのネットワーク検出を補助するネットワークノードのことです。例えば，管理環境内のコアルーターなどがシードになることができます。各シードは，IPアドレスやホスト名によって識別されます。ルールベース検出が設定されていない場合，NNMiの検出プロセスは指定シードのリストベース検出に制限されます。

シード検出

シード，またはシードファイルを基にしたプロセスで，シードとして指定したノードについてだけ検出し，レイヤー2の接続情報を返します。シード検出は，特定したクエリーとタスクのネットワークインベントリだけを保守します。自動検出と比べてください。「スパイラル検出」も参照してください。

シードによる検出

「リストに基づいた検出」を参照してください。

システムアカウント

NNMiのインストール時に使うために備わっている特別なアカウントです。NNMiシステムアカウントは，インストール終了後は，コマンドラインのセキュリティや復旧目的だけに使用されます。「ユーザーアカウント」と読み比べてください。

システムオブジェクトID

NNMiで，ネットワーク要素のモデルまたは種類を識別するSNMPオブジェクト識別子の専門化された用語。システムオブジェクトIDは，ネットワーク要素のMIBオブジェクトの一部です。このオブジェクトは，検出の間に個別のノードからNNMiがクエリーします。システムオブジェクトIDによって分類できるネットワーク要素の種類の例には，HP ProCurveスイッチファミリ，HP J8715A ProCurve Switch，HP IPFシステム用のHP SNMPエージェントがあります。ほかのベンダーのネットワーク要素も同じようにシステムオブジェクトIDに従って分類できます。システムオブジェクトIDの重要な使用法はNNMiデバイスプロファイルの定義にあります。デバイスプロファイルは，ネットワーク要素の種類がわかると，推定できるネットワーク要素の特徴を指定します。

自動検出

「ルールベースの検出」を参照してください。

障害ポーリング

主要なNNMi監視アクティビティ。このアクティビティでは，NNMiは，管理対象の各オブジェクトの状態を調べるために，管理対象インタフェース，IPアドレス，SNMPエージェントすべてに関し，ステータスMIBのSNMP読み取り専用クエリーまたはICMP ping，もしくはその両方を発行します。ユーザーは，NNMiコンソールの［設定］ワークスペースの［モニタリングの設定］で，さまざまなインタフェースグループ，ノードグループ，ノードすべてについて実行された障害ポーリングの種類をカスタマイズできます。障害ポーリングはステータスポーリングのサブセットです。

状態

NNMiでは，一般的に，MIB II ifAdminStatus，MIB II ifOperStatus，パフォーマンス，または可用性に関連する自己報告された管理対象オブジェクト応答について状態という用語を使用します。「ステータス」と読み比べてください。

状態ポーリング

NNMiのState Pollerが実行する指令された監視。障害，パフォーマンス，コンポーネント稼働状態，管理対象オブジェクトの可用性データを取得するためにICMP pingとSNMPクエリーを使います。「障害ポーリング」も参照してください。

す

ステータス

NNMiでは，全般的な稼働状態を示す管理対象オブジェクトの属性。ステータスは，管理対象オブジェクトの未解決結論からCausal Engineが計算します。「状態」と読み比べてください。

スパイラル検出

NNMiの管理するネットワークのインベントリ，包含，リレーションシップ，接続についての情報などのネットワークトポロジ情報をNNMiが常時更新する処理のことです。「検出プロセス」，「ルールベースの検出」および「リストに基づいた検出」も参照してください。

と

トポロジ（ネットワーク）

ネットワークのノードや接続などが，通信ネットワーク上でどのように配置されているのかを示す図のことです。

トラップ

「SNMPトラップ」を参照してください。

トラップ受信コンポーネント

SNMPトラップを受信する，Northboundアプリケーションの一部分です。

一部のアプリケーションには，SNMPトラップを受信して処理用に別のコンポーネントに転送する，個別にインストール可能なコンポーネントが含まれます。

そのようなコンポーネントがないNorthboundアプリケーションの場合，「トラップ受信コンポーネント」は「Northboundアプリケーション」と同義語です。

の

ノード

ネットワーク関係で，ネットワークに接続されているコンピュータシステムやデバイス（プリンタ，ルーター，ブリッジなど）のことです。SNMPクエリーに応答できるノードは最も包括的な情報をNNMiに提供しますが，NNMiは非SNMPノードの制限された管理も実行できます。

ノードグループ

NNMiの主要なフィルタテクニックの1つ。ただし，グループごとに，グループまたはフィルタの視覚化に設定を適用する目的で，ノードはグループにまとめられます。ノードグループは，監視の設定，テーブルビューのフィルタ，マップビューのカスタマイズのどれか，またはすべてに使用できます。「インタフェースグループ」も参照してください。

は

パブリックキー証明書

ネットワークセキュリティおよび暗号化で使用されます。デジタル署名を組み込み，パブリックキーと識別情報を結合するファイルです。証明書は，パブリックキーが個人または組織に属することの確認に使われます。NNMiはSSL証明書を使います。これにはクライアントとサーバーの通信の認証と暗号化のために，パブリックキーおよびプライベートキーが含まれています。

ほ

ポート

ネットワークハードウェアで，ネットワークデバイスの情報の受け渡しを行う場所です。

ボリュームグループ

コンピュータストレージ仮想化の用語。1つの大規模ストレージエリアを形成するよう設定された1つまたは複数のディスクドライブ。NNMiがサポートする幾つかの高可用性製品は，共有ファイルシステムでボリュームグループを使用します。

み

未接続インタフェース

NNMiの観点からは，未接続インタフェースはほかのデバイスに接続されていないインタフェースのことです。デフォルトでは，NNMiが監視する未接続インタフェースはIPアドレスのあるものだけであり，［ルーター］ノードグループのノードに含まれます。

ゆ

ユーザーアカウント

NNMiでは，ユーザーまたはユーザーグループがNNMiにアクセスする方法を提供します。NNMiユーザーアカウントはNNMiコンソールにセットアップされ，事前定義されたユーザーロールを実装します。「システムアカウント」および「ユーザーロール」を参照してください。

ユーザーロール

NNMi管理者は，ユーザーアクセス設定の一環として，NNMiの各ユーザーアカウントに定義済みのユーザーロールを割り当てます。ユーザーロールによって，NNMiコンソールにアクセス可能なユーザーアカウント，および各ユーザーアカウントで使用可能なワークスペースとアクションが決まります。NNMiには，プログラムによってあらかじめ定義され，変更することのできない次の階層型ユーザーロールがあります。

管理者

Webサービスクライアント

オペレータレベル2

オペレータレベル1

ゲスト

など

「ユーザーアカウント」も参照してください。

り

リージョナルマネージャー

デバイスの検出，ポーリングおよびトラップ受信を行い，情報をグローバルマネージャーに転送する，グローバルネットワーク管理配備内のNNMi管理サーバーです。

リストに基づいた検出

シードのリストに基づいたプロセス。シードとして指定するノードだけに関する詳細ネットワーク情報を検出し，返します。リストに基づいた検出は，特定したクエリーとタスクのネットワークインベントリだけを保守します。ルールベース検出と比べてください。「検出プロセス」および「スパイラル検出」も参照してください。

領域

NNMiで，タイムアウト値やアクセスクレデンシャルのような通信設定を行うためにグループにまとめられたデバイス。

る

ルール

「検出ルール」を参照してください。

ルールベースの検出

自動検出と呼ばれることがよくあります。NNMiは，ルールベースの検出を使用し，ユーザー指定検出ルールに従って，NNMiがデータベースに追加する必要のあるノードを探し出します。NNMiは，検出されたノードのデータ内で検出ヒントを探してから，指定の検出ルールに照らしてこれらの候補をチェックします。検出ルールは，NNMiコンソールの［自動検出ルール］の［検出の設定］部分に設定します。リストベース検出と比べてください。

れ

レイヤー2

階層化通信モデルであるOpen Systems Interconnection（OSI）のデータリンク層です。データリンク層では，ネットワークの物理リンクを介してデータの伝送を行います。NNMiレイヤー2ビューは，デバイスの物理接続に関する情報を提供します。

レイヤー3

階層化通信モデルであるOpen Systems Interconnection（OSI）のネットワーク層です。ネットワーク層は，ネットワーク上の隣接するノードのアドレスの取得，データ伝送経路の選択，サービス品質などに関与します。NNMiレイヤー3ビューは，ルーティングの観点から接続に関する情報を提供します。

ろ

ロール

「ユーザーロール」を参照してください。

論理ボリューム

個別のファイルシステムまたはデバイススワップ空間として使えるボリュームグループ内の任意のサイズの容量を指すコンピュータストレージ仮想化の用語。NNMiがサポートする幾つかの高可用性製品は共有ファイルシステムで論理ボリュームを使います。

索引

A

AddressNotRespondingインシデント[1]

Application_A.logファイル[1]

ARPキャッシュ[1], [2]

C

Causal Engine[1], [2]

Cisco

スイッチ[1]

ルーター[1]

Cisco ACIネットワークの検出と監視[1]

cluster.logファイル[1]

Cluster Manager[1]

Cluster Member[1]

com.hp.ov.nms.cluster.timeout.archive[1]

ConnectionDownインシデント[1]

CPUリソース[1]

D

DHCP[1]

DiskGroup_A.logファイル[1]

DNS設定を確認する[1]

H

HA[1]

HA_nnmhaserver.logファイル[1]

haconfigure.logファイル[1]

HAクラスタ

IPアドレスの変更[1]

NNMi[1]

アーキテクチャ[1]

概念[1]

起動の問題[1]

共有データ[1]

サポート対象の製品[1]

シナリオ[1]

スクリプト[1]

設定のトラブルシューティング[1]

ファイル[1]

HAクラスタ内のNNMiをメンテナンスする[1]

HAクラスタの設定解除[1]

HA情報

NNMi[1]

HA設定[1]

共有ディスク[1]

スクリプト[1]

ファイル[1]

リファレンスページ[1]

ログファイル[1]

HA設定のメンテナンス[1]

HAプライマリクラスタノード

設定情報[1]

HA用のクラスタアーキテクチャ[1]

HAリソースグループ[1]

起動できない[1]

設定[1]

説明[1]

停止[1]

hostnolookup.confファイル[1]

I

ICMP[1]

IPv4アドレス[1]

アドレス監視[1]

トラフィックの無効化[1]

ICMP ping[1]

InterfaceDownインシデント[1]

ipnolookup.confファイル[1]

IPv4アドレス[1]

IPアドレス

HA用に変更[1]

管理サーバー[1]

検出シードの入力[1]

範囲[1]

IPアドレス範囲[1]

J

JavaScriptの有効化[1]

JBossアプリケーションサーバー[1]

JBossポートの競合[1]

JP1/IM3のインテリジェント統合管理基盤との連携[1]

L

L2[1]

L3[1]

LDAP設定ファイル[1]

Linuxへの必要なライブラリのインストール（Linuxの場合）[1]

M

manページ[1]

MIB[1]

MIB II変数[1]

MINCAUSEアルゴリズム[1]

Mount_A.logファイル[1]

N

NAT[1]

NAT環境の重複IPアドレスの管理[1]

NATタイプ[1]

NATの利点[1]

NETCONFとは何か[1]

NETCONFプロトコルの運用[1]

NETCONFを使用するデバイスのサポート[1]

nms-auth-config.xmlファイル[1]

nms-cluster.propertiesファイル[1]

NmsApaサービス

Causal Engine[1]

オブジェクトステータスの設定[1]

設定変更[1]

デバイスが発生したトラップ[1]

ネットワーク接続[1]

nmsdbmgrサービス

起動の問題[1]

ディスクフェイルオーバー[1]

nnm.envvars.batコマンド[1]

nnm.envvars.shコマンド[1]

nnmbackup.ovpl[1]

NnmClusterFailoverインシデント[1]

NnmClusterStartupインシデント[1]

nnmclusterコマンド[1]

nnmcommconf.ovplコマンド[1]

nnmconfigexport.ovpl

設定のXMLへの出力[1]

nnmconfigimport.ovplコマンド[1]

nnmdatareplicator.confファイル[1]

nnmdatareplicator.ovpl

スクリプト[1]

nnmhaclusterinfo.ovplスクリプト[1], [2]

nnmhaconfigure.ovpl

スクリプト[1]

nnmhadisk.ovpl

nmsdbmgrのトラブルシューティング[1]

nnmhadisk.ovplコマンド

nmsdbmgrのトラブルシューティング[1]

nnmhadisk.ovplスクリプト[1]

nnmhamonitor.ovplスクリプト[1]

nnmhamscs.vbsスクリプト[1]

nnmharg.ovplスクリプト[1]

nnmhargconfigure.ovpl

コマンド[1]

スクリプト[1]

nnmhargconfigure.ovplコマンド[1]

nnmhastart.ovplスクリプト[1]

nnmhastartrg.ovpl[1]

nnmhastartrg.ovplスクリプト[1]

nnmhastop.ovplスクリプト[1]

nnmhastoprg.ovpl[1]

nnmhaunconfigure.ovplスクリプト[1]

NNMi[1]

データベースの移動[1]

NNMi Northboundアプリケーションの接続パラメーター[1]

NNMi Northboundインタフェース[1], [2], [3]

NNMi Northboundインタフェースで使用されるMIB情報[1]

NNMi Northboundインタフェースで使用されるSNMPトラップ情報[1]

NNMi Northboundインタフェース転送先のステータス情報[1]

NNMi Northboundインタフェース統合の内容[1]

NNMi Northboundインタフェースの概要[1]

NNMi Northboundインタフェースの使用法[1]

NNMi Northboundインタフェースのトラブルシューティング[1]

NNMi Northboundインタフェースの変更[1]

NNMi Northboundインタフェースの無効化[1]

NNMi Northboundインタフェースの有効化[1]

NNMi管理サーバー[1], [2]

ドメイン名を変更する[1]

ホスト名を変更する[1]

NNMi管理サーバーをバージョンアップする[1]

NNMi管理サーバーを変更する[1]

NNMiクイックスタート設定ウィザード[1]

NNMiコンソール[1]

URL[1]

Webブラウザの有効化[1]

アクセス[1]

サインイン[1]

トランザクションベースの更新[1]

NNMiスパイラル検出[1]

NNMi設定移動の準備[1]

NNMi設定およびデータベースのリセット[1]

NNMi設定およびデータベースを移動する[1]

NNMiデータベースパスワードの変更[1]

NNMiとLDAPによるディレクトリサービスの統合[1]

NNMiとディレクトリサービスの統合[1]

NNMiとの統合

ディレクトリサービス[1]

NNMiにNATを実装する方法[1]

NNMiにNETCONFデバイスの認証情報を設定する[1]

NNMiのアンインストール

（Linuxの場合）[1]

（Windowsの場合）[1]

NNMiのインストール

ディスク容量が足りない場合[1]

NNMiの起動と停止および再起動[1]

NNMiの設定の移動[1]

NNMiの設定の変更[1]

NNMiのバージョンアップ（修正版の適用を含む）[1]

NNMiのバックアップとリストア[1]

NNMiのポート一覧[1]

NNMiのライセンスを取得する[1]

NNMiへアクセスする[1]

NNMiヘルプへアクセスする[1]

NNMiユーザーアクセス情報[1]

NNMiユーザーグループ[1]

NNMiをアンインストールする[1], [2]

NNMiをインストールする[1]

（Linuxの場合）[1]

（Windowsの場合）[1]

nnmloadseeds.ovplコマンド[1]

nnmofficialfqdn.ovplスクリプト[1]

nnmrestore.ovplスクリプト[1]

nnmsnmpwalk.ovplコマンド[1]

NNMイベント[1]

NodeDownインシデント[1]

NodeOrConnectionDownインシデント[1]

Nortel

スイッチ[1]

ルーター[1]

Northboundアプリケーション[1], [2]

Northbound転送先[1], [2]

nslookupの応答時間の改善[1]

nslookup要求を避ける[1]

nsswitch.confファイル[1]

O

OID[1]

ov.conf

HA設定[1]

ov.confファイル[1], [2]

ovstartコマンド[1], [2], [3]

ovstatusコマンド[1]

ovstopコマンド[1], [2], [3]

P

ping

コマンド[1]

要求[1]

Pingスイープ[1], [2]

Postgres[1]

PostgreSQL[1]

R

RCA[1]

recovery.confファイル[1]

root権限[1]

S

SNMP[1], [2]

エージェントステータス[1]

監視[1]

コンポーネント稼働状態[1]

設定の調整[1]

対応バージョン[1]

通信[1]

通信の問題[1]

ノードの設定[1]

バージョンの優先[1]

プロトコル[1]

要求[1]

SNMPv1トラップ[1]

SNMPv2cトラップ[1]

SNMPv3資格情報[1]

SNMPv3トラップと通知[1]

SNMPトラップ[1]

SNMPトラップがNNMiに送信する内容を決定する[1]

SNMPトラップストーム[1]

SNMPプロキシを設定する[1]

State Poller

概念[1]

稼働状態情報[1]

監視できる項目[1]

計画作成[1]

症状[1]

設定[1]

設定の評価[1]

調整[1]

通信設定[1]

Symantec Cluster Server

HAリソースグループ[1]

sysObjectID[1]

T

TLSプロトコルの設定[1]

V

Veritas Cluster Server

HAリソースグループ[1]

nnmharg.ovplスクリプト[1]

VMwareハイパーバイザーベースの仮想ネットワークの検出と監視[1]

Volume_A.logファイル[1]

W

Webブラウザ

NNMiコンソールへのアクセス[1]

Webブラウザの有効化[1]

Windows Server Failover Cluster

HAリソースグループ[1]

nnmhamscs.vbsスクリプト[1]

X

XMLファイル[1], [2]

あ

アーキテクチャ[1]

アカウント[1]

アクティブ[1]

プロトコル[1]

アクティブなクラスタノード[1], [2]

アドレスのヒント[1]

アプリケーションフェイルオーバー[1], [2]

NNMi管理サーバーの要件[1]

NNMiの設定[1]

インシデント[1]

クラスタマネージャー〔モード〕[1]

シナリオ[1]

セットアップ[1]

ネットワークレイテンシ/帯域に関する考慮[1]

無効にする[1]

アプリケーションフェイルオーバーとNNMiデータベース[1]

アプリケーションフェイルオーバーの使用[1]

アプリケーションフェイルオーバーの動作[1]

アプリケーションフェイルオーバーとNNMi Northboundインタフェース[1]

い

一時試用ライセンス[1], [2]

一時試用ライセンスキー[1]

移動

NNMi管理サーバー[1]

NNMi設定[1]

インタフェース[1]

イベント転送フィルター[1]

イベント領域[1]

因果関係[1]

インシデント[1]

アプリケーションフェイルオーバー[1]

インシデント削除通知[1]

インシデント相関処理通知[1]

インシデント転送[1]

インシデントの概念[1]

インシデントの計画[1]

インシデントの設定[1]

インシデントの調整[1]

インシデントの評価[1]

インシデントの例[1]

インシデントライフサイクル状態変化通知[1]

インストール

インストール前チェックリスト[1]

インストールおよび初期スタートアップのトラブルシューティング[1]

インストールの問題[1]

インストール前チェックリスト[1]

NNMi管理サーバー[1]

NNMiクイックスタート設定ウィザード[1]

インターネット制御メッセージプロトコル[1]

インタフェース[1]

HA設定の仮想ホストネットワーク[1]

移動[1]

管理[1]

グループ[1]

ステータス[1]

設定[1]

操作[1]

モデル[1]

インタフェースグループ[1]

［インタフェースグループの設定］フォーム[1]

［インタフェースグループ］フォーム[1]

［インタフェースグループ］ワークスペース[1]

インタラクティブモード[1]

う

ウイルスチェック除外設定[1]

え

エージェント[1]

エージェントクエリー

応答性[1]

無反応[1]

エピソード[1], [2]

エンドツーエンドの診断[1]

お

応答性

ICMPへのIPv4Address[1]

オブジェクト〔ステータス設定〕[1]

オブジェクト識別子[1]

オブジェクトのグループ定義[1]

オフラインバックアップ[1]

オペレータレベル1[1]

オペレータレベル2[1]

オンラインバックアップ[1]

か

解析〔管理対象ノード〕[1]

階層〔ノードグループ〕[1]

概念

Causal Engine[1]

HA[1]

ステータスポーリング[1]

設定[1]

通信[1]

確認

SNMPアクセス[1]

SNMP用に設定されたノード[1]

インタフェースグループ[1]

管理IPアドレス[1]

順序番号[1]

通信設定[1]

ノードグループ[1]

仮想IPアドレス[1]

仮想ホスト〔HA設定〕

ネットマスク[1]

ネットワークインタフェース[1]

仮想ホストの名前[1]

仮想ホスト名[1]

カテゴリ

ステータス[1]

稼働

管理[1]

シャドウの除去[1]

操作[1]

ノード[1]

分散ルーター[1]

稼働状態情報[1]

簡易ネットワーク管理プロトコル（SNMP）[1]

環境変数[1]

MANPATH〔Linux〕[1]

アプリケーションフェイルオーバー[1]

概要[1]

管理[1]

監視[1]

拡張[1]

ノード〔ネットワーク〕[1]

監視の拡張[1]

完全修飾ドメイン名[1]

完全修飾ドメイン名の判断[1]

管理

設定変更[1]

管理アドレスの優先[1]

管理サーバー[1]

DHCP[1]

IPアドレス[1]

管理者

権限[1]

管理者権限[1]

管理者ロール[1]

管理情報ベース[1]

管理対象デバイスてのNETCONFの有効化と設定[1]

管理対象ノードの解析[1]

管理対象ノードの数の確認[1]

き

起動

HAメンテナンス後のNNMi[1]

HAリソースグループ[1]

起動の問題

nmsdbmgr[1]

NNMi[1]

基本的な検出方法を選択する[1]

キャッシュ〔ARP〕[1]

共有HA データ[1]

共有ディスク

データ[1]

データファイルのコピー[1]

共有ディスクのディレクトリ[1]

共有ディスクフォーマット[1]

共有ファイルシステムのタイプ〔HA設定〕[1]

く

クイックスタート設定ウィザード[1]

URL[1]

クイックスタート設定ウィザードを使用する[1]

組み込みデータベースツールのパスワードを入力する[1]

クラスタ[1]

クラスタメンバーまたはノード[1]

グループ

インタフェース〔フィルタリング〕[1]

事前設定[1]

設定[1]

ディスク[1]

フィルタリング[1]

ボリューム[1]

目的[1]

グローバルネットワーク管理[1]

グローバルネットワーク管理と静的NAT[1]

グローバルネットワーク管理と動的NATおよび動的PAT[1]

グローバルマネージャー[1]

け

計画作成

ステータスポーリング[1]

通信[1]

ポーリング間隔[1]

継続検出[1]

ゲストロール[1]

結論[1]

権限サーバー[1]

検出[1]

検出シード[1]

検出設定チェックリスト[1]

検出モード[1]

再スタート[1]

自動検出ルール[1]

進行状況を確認する[1]

スイッチ[1]

スパイラル[1], [2]

ノードの削除[1]

パフォーマンス[1]

評価[1]

ルーター[1]

検出シード[1], [2]

検出設定チェックリスト[1]

検出と静的NAT[1]

検出と動的NATおよび動的PAT[1]

検出の進行状況[1]

検出の調整[1]

検出のデメリット[1]

検出のヒント[1]

検出プロセス[1]

検出ルール[1]

こ

高可用性[1]

高可用性クラスタ[1]

恒久ライセンス[1]

恒久ライセンスキー[1]

恒久ライセンスキーのインストールを準備する[1]

恒久ライセンスキーを取得してインストールする[1]

更新中

ノード[1]

コマンド

nnm.envvars.bat[1]

nnm.envvars.sh[1]

nnmbackup.ovpl[1]

nnmcluster[1]

nnmcommconf.ovpl[1]

nnmconfigimport.ovpl[1]

nnmdatareplicator.conf[1]

nnmdatareplicator.ovpl[1]

nnmhargconfigure.ovpl[1]

nnmloadseeds.ovpl[1]

nnmsnmpwalk.ovpl[1]

ovstart[1], [2]

ovstop[1], [2]

ping[1]

コマンドラインのセキュリティ[1]

コマンドラインモード[1]

コミュニティ文字列[1], [2]

コンソール[1]

コントローラ[1]

コンポーネント稼働状態監視[1]

根本原因[1]

結論を生み出す[1]

根本原因インシデント[1]

根本原因解析[1]

さ

サーバー

NNMiの移動[1]

サーバーからスイッチへのリンクアグリゲーション（S2SLA）の検出について[1]

サービス〔NmsApa〕

ステータス[1]

設定変更[1]

デバイスが発生したトラップ[1]

ネットワーク接続[1]

ノードを更新[1]

サービスレベル契約条項[1]

再試行

値[1]

調整[1]

再スタート

HAメンテナンス後のNNMi[1]

検出[1]

サインイン[1]

SNMPv1トラップまたはSNMPv2cトラップのブロック[1]

削減

デフォルトコミュニティ文字列[1]

認証失敗[1]

削除

検出されたノード[1]

作成者属性[1]

作成中

オブジェクトグループ定義[1]

再使用可能なノードグループ[1]

シャドウ[1]

サブネットと静的NAT[1]

サブネットと動的NATおよび動的PAT[1]

し

シード[1]

ルールベース検出[1]

シード検出[1]

シードによる検出[1]

システム

共有ファイルタイプ〔HA 設定〕[1]

リソース[1]

システムアカウント[1], [2]

システムアカウントのパスワードの設定[1]

システムオブジェクトID[1]

システムオブジェクトID範囲

自動検出[1]

評価[1]

事前設定

インタフェースグループ[1]

ノードグループ[1]

失敗

ネットワークシナリオ[1]

自動検出[1]

設定[1]

自動検出ルール[1], [2]

規則[1]

自動検出ルールの順序[1]

シナリオ

HAクラスタ[1]

ネットワーク失敗[1]

シャドウ

作成中[1]

除去[1]

順序〔評価〕[1]

順序属性

自動検出ルール[1]

ベストプラクティス[1]

順序番号〔確認〕[1]

障害ポーリング[1]

状態[1]

状態とステータスのNNMi計算[1]

状態ポーリング[1]

証明書

自己署名[1]

認証機関[1]

初期スタートアップの問題[1]

新規インストール中に読み込むMIB[1]

シンボリックリンク[1]

す

スィープ[1]

スイッチ

階層[1]

検出[1]

デフォルト[1]

ノードグループの定義[1]

スクリプト

HA設定[1]

nnmbackup.ovpl[1]

nnmbackupembdb.ovpl[1]

nnmhaclusterinfo.ovpl[1]

nnmofficialfqdn.ovpl[1]

nnmresetembdb.ovpl[1]

nnmrestore.ovpl[1]

nnmrestoreembdb.ovpl[1]

データをリストアする[1]

スタンドアロンのNNMi管理サーバーのIPアドレスを変更する[1]

スタンバイ[1]

ステータス[1], [2]

SNMPエージェント[1]

インタフェース[1]

オブジェクト[1]

ノード[1]

ノードグループ[1]

ステータスポーリング

調整[1]

ステータスポーリングの開始[1]

ステータスポーリングの調整[1]

ステータスポーリングを高度化[1]

スパイラル検出[1], [2], [3]

せ

正式な完全修飾ドメイン名の取得または設定[1]

静的NAT[1]

静的NATでの通信[1]

静的NATの考慮事項[1]

セカンダリDNSサービス[1]

セカンダリクラスタノード[1]

接続

操作〔稼働〕[1]

操作〔停止〕[1]

ルーター〔稼働〕[1]

ルーター〔停止〕[1]

設定

DNS[1]

HAのトラブルシューティング[1]

HAを設定する[1]

manページ[1]

NNMi移動の準備[1]

NNMiを移動する[1]

オブジェクトステータス[1]

概念[1]

クイックスタート設定ウィザード[1]

コミュニティ文字列[1]

情報〔NNMi〕[1]

スクリプト〔HA クラスタ〕[1]

ステータスポーリング[1]

ステータスポーリングの評価[1]

通信の設定[1]

トランザクションベースの更新[1]

ネットワーク検出[1]

ノード[1]

ポーリングの例[1]

リストベース検出[1]

領域[1]

ルールベース検出[1]

ログファイル[1]

設定ファイルの複製[1]

設定領域[1]

［設定］ワークスペース

ステータスポーリングの設定[1]

ステータスポーリングの評価[1]

前提条件

ハードウェア[1]

全領域[1]

そ

属性

作成者[1]

順序[1]

ソフトウェア[1]

ソフトウェア使用許諾契約書[1]

た

帯域に関する考慮[1]

対応Webブラウザ[1]

対応バージョン

SNMP[1]

タイムアウト[1]

値[1]

調整[1]

タスク

ネットワーク検出の設定[1]

ち

チェックリスト[1]

調整

ステータスポーリング[1]

通信[1]

重複するIPアドレスマッピング[1]

つ

通信

概念[1]

計画作成[1]

設定[1]

設定の評価[1]

設定領域[1]

調整[1]

通信設定の構成[1]

て

定義[1]

定義済みのユーザーロール[1]

停止

NNMi〔HAリソースグループ〕[1]

NNMi〔HAフェイルオーバーを行わせないため〕[1]

管理〔インタフェース〕[1]

シャドウの作成〔ノード〕[1]

接続[1], [2]

操作〔インタフェース〕[1]

分散ルーター〔ノード〕[1]

ルーター〔ノード〕[1]

ディスク

グループ〔HA 設定〕[1]

ディレクトリ〔共有ディスク〕[1]

データファイルのコピー〔共有ディスク〕[1]

フェイルオーバー[1]

ディスクグループ[1]

ディレクトリサービス内のユーザー名とパスワード[1]

データ

共有ディスク[1]

収集〔State Poller〕[1]

収集の確認[1]

データの収集

確認〔ステータスのポーリング〕[1]

データベース

トポロジ[1]

リセット[1]

データベースをバックアップおよびリストアする[1]

データをリストアする

スクリプト[1]

デーモンモード[1]

テスト

通信設定[1]

デバイス

発生したトラップ[1]

フィルタ[1]

デバイスの検出[1]

デバイスの通信設定を確認する[1]

デバイスを検出から除外[1]

デフォルト

検出[1]

コミュニティ文字列[1]

スイッチ[1]

設定[1]

ルーター[1]

ルールベース検出[1]

デフォルト値〔Linux〕

環境変数[1]

デフォルト値〔Windows〕

環境変数[1]

デメリット

リストベース検出[1]

ルールベース検出[1]

と

到達可能なノード[1]

到達できないノード[1]

動的NAT[1]

動的NATおよび動的PATの考慮事項[1]

動的NATおよび動的PATのハードウェアとソフトウェアの要件[1]

動的ポートアドレス変換（動的PAT）[1]

トポロジ[1]

データベース[1]

トポロジ（ネットワーク）[1]

ドメインネームシステム[1]

トラップ[1]

発生中[1]

トラップ受信コンポーネント[1], [2]

トラップと静的NAT[1]

トラフィック

無効化[1]

トラブルシューティング

HA設定[1]

NNMi固有のHA[1]

NNMiコンソールが開かない[1]

NNMiコンソールを起動できない[1]

インストール[1]

検出[1]

初期スタートアップ[1]

に

認証失敗の削減[1]

認証プロファイル[1]

ね

ネットマスク〔HA設定の仮想ホスト〕[1]

ネットワーク

基幹[1]

失敗のシナリオ[1]

接続[1]

接続の確認[1]

ノード[1]

負荷[1]

ネットワークアドレス変換（NAT）環境でのNNMiの配備[1]

ネットワークインタフェース〔HA設定の仮想ホスト〕[1]

ネットワーク監視の設定を確認する[1]

ネットワーク検出[1]

ネットワーク失敗のシナリオ[1]

ネットワーク接続の確認[1]

ネットワーク設定の変更[1]

ネットワークトポロジ[1]

ネットワーク待ち時間[1]

ネットワークレイテンシに関する考慮[1]

の

ノード[1]

監視[1]

グループ[1]

更新済み[1]

更新中[1]

削除する[1]

シャドウの除去[1]

ステータス[1]

設定[1], [2]

到達可能[1]

到達不可能[1]

分散ルーター[1]

ルーター[1]

ノードグループ[1]

インタフェースグループ[1]

階層[1]

確認[1]

事前設定[1]

ステータス[1]

設定[1]

定義[1]

デバイスフィルター[1]

非SNMPデバイス[1]

ノードグループのステータス[1]

ノードグループの設定[1]

［ノードグループの設定］フォーム[1]

ノードグループのメンバーシップ[1]

［ノードグループ］フォーム[1]

ノードグループマップ設定の構成[1]

［ノードグループ］ワークスペース[1]

ノードにpingを送る[1]

は

バージョン

SNMP優先[1]

バージョンアップ前のデータをバックアップする[1]

ハードウェア[1]

ハードウェアおよびソフトウェア[1], [2]

パスワード

サインイン[1]

パソコン〔検出の概念〕[1]

バックアップ

イベント領域[1]

オフライン[1]

オンライン[1]

設定領域[1]

全領域[1]

トポロジ領域[1], [2]

バックアップとリストア

方針[1]

バックアップの方針[1]

パッシブなクラスタノード[1]

発生中

トラップ[1]

パフォーマンス〔ステータスポーリング〕[1]

パブリックキー証明書[1]

範囲〔IPアドレス〕[1]

ひ

非SNMPデバイスノードグループ[1]

評価

ステータスポーリング設定[1]

通信設定[1]

評価の順序[1]

ヒント

IPアドレス範囲[1]

システムID範囲[1]

ヒント〔設定のヒント〕

シード検出[1]

自動検出[1]

ふ

ファイアウォール

ネットワークアクセスの無効化[1]

ファイル

HAクラスタ[1]

HA設定[1]

HA用のレプリケーション[1]

hostnolookup.conf[1]

ipnolookup.conf[1]

nms-auth-config.xml[1]

nms-cluster.properties[1]

nnmdatareplicator.conf[1]

nsswitch.conf[1]

ov.conf[1]

XML[1]

クラスタノードで更新されない[1]

システムタイプ[1]

レプリケーション[1]

ファイルシステムのタイプ〔HA設定〕[1]

フィルタ

デバイス[1]

フィルタリング

インタフェースグループ[1]

ノードグループ[1]

フェイルオーバー〔ディスク〕[1]

フォーム

インタフェースグループ[1]

［インタフェースグループの設定］[1]

ノードグループ[1]

［ノードグループの設定］[1]

モニタリングの設定[1], [2]

複数[1]

複数のDNSサーバーが使用される場合[1]

不合格

認証の削減[1]

不十分なディスク容量[1]

プライベートIPアドレスの範囲[1]

プライマリクラスタノード[1]

プリンタ〔検出の概念〕[1]

フローモデル〔タスク〕[1]

プロトコル

SNMP[1]

アクティブ[1]

通信[1]

ポーリング[1]

プロファイル〔デバイス〕

概念[1]

へ

ページ[1]

ベストプラクティス

NNMi設定移動の準備[1]

オブジェクトグループ定義[1]

既存の設定を保存する[1]

再使用可能なノードグループ[1]

作成者属性[1]

順序属性[1]

順序番号の確認[1]

短いポーリング間隔[1]

変更

管理[1]

ネットワーク[1]

変数〔MIB II〕[1]

ほ

ポイント〔マウント〕[1]

包含〔ノードグループ〕[1]

方法

リストベース検出[1]

ルールベースの検出[1]

ポート[1]

JBossポートの競合[1]

ポート一覧[1]

ポーリング

開始[1]

間隔の計画作成[1]

設定の例[1]

チェックリスト[1]

調整〔ステータス〕[1]

パフォーマンスの評価[1]

プロトコル[1]

ホスト〔HA設定用の仮想〕

NNMi[1]

ホスト名〔HA用に変更する場合〕[1]

ホスト名の変更

NNMi[1]

保存

既存[1]

ボリュームグループ[1], [2], [3]

ま

マウントポイント[1]

待ち時間〔ネットワーク〕[1]

末端ノード〔検出の概念〕[1]

マルチホームNNMi管理サーバー[1]

み

未接続インタフェース[1]

む

無効化

SNMP[1]

トラフィック[1]

無反応

ICMPへのIPv4Address[1]

め

メモリリソース[1]

メリット

リストベース検出[1]

ルールベース検出[1]

メンテナンスモード[1]

も

モデル

ユーザーインタフェース[1]

モニタリング

設定[1]

［モニタリングの設定］フォーム[1], [2]

ステータスポーリングの調整[1]

説明[1]

ポーリングの種類と間隔の設定[1]

モニタリングの設定フォーム[1]

問題〔HAの起動〕

nmsdbmgr[1]

NNMi[1]

ゆ

有効なIPアドレス範囲[1]

ユーザー[1]

サインイン[1]

ユーザーアカウント[1]

ユーザーインタフェースモデル[1]

ユーザーロール[1]

システムアカウント[1]

優先

SNMPのバージョン[1]

よ

要求〔SNMP/ICMP要求〕[1]

用語集

HA[1]

ら

ライセンス[1]

限度[1]

ライセンスの種類の確認[1]

ライセンスの追加[1]

ラウンドロビンDNS[1]

り

リージョナルマネージャー[1]

リージョナルマネージャーからグローバルマネージャーへのカスタム属性の複製[1]

リストア

スクリプト[1]

ファイルシステムだけ[1]

リストアの方針[1]

リストに基づいた検出[1]

リストベース検出

概要[1]

リセット

設定[1]

リソース〔システム〕[1]

リソースグループ[1]

リモートNorthboundアプリケーション[1]

領域[1]

通信設定領域[1]

リリースノート[1]

リンクアグリゲーションの検出[1]

る

ルーター

階層[1]

監視[1]

検出[1]

デフォルト[1]

ノードグループの定義[1]

ルール[1]

ルール〔自動検出〕

順序[1]

ルールベースの検出[1]

概要[1]

れ

例

アプリケーションフェイルオーバー[1]

ノードグループの設定[1]

ポーリング設定[1]

レイヤ2[1]

レイヤ3[1]

ろ

ローカルNorthboundアプリケーション[1]

ロール[1], [2]

ログファイル〔HAクラスタ〕

設定[1]

論理ボリューム[1], [2]

わ

ワークスペース

インタフェースグループ[1]

ステータスポーリングの設定[1]

ノードグループ[1]

マニュアル発行元

株式会社 日立製作所

〒100-8280　東京都千代田区丸の内一丁目6番6号