Sun Java System Messaging Server 6.3 管理ガイド

A.3 Solaris 10 OS 用の SNMP サポートを設定する

デフォルトでは、Messaging Server 内での SNMP 監視は無効になっています。このデフォルト設定は、デフォルトの Messaging Server 設定によって提供されるサービスの数を最小限に抑えることを目的としています。このデフォルト設定を、SNMP 監視を使用することでパフォーマンスに不利な条件が発生するという意味には解釈しないでください。実際には、Messaging Server の SNMP サポートによるリソース消費はごくわずかであり、Messaging Server への影響を最小限に抑えるように意図されています。以上のことから、当然ながら、Messaging Server の SNMP サポートを使用する前に、設定手順を 1 回実行する必要があります。さらに、Messaging Server などのサブエージェントを実行するためには、通常、プラットフォームの Net-SNMP マスターエージェントである snmpd のデフォルト設定を変更する必要があります。この変更については、次の節で取り上げます。

A.3.1 Net-SNMP の設定

Messaging Server の Net-SNMP ベースの SNMP サブエージェントは、AgentX プロトコルを使用してプラットフォームの SNMP マスターエージェントと通信します (RFC 2741)。Net-SNMP のマスターエージェントである snmpd は、AgentX プロトコルを使用できるように設定する必要があります。そのためには、プラットフォームの snmpd.conf ファイルに次の行が含まれていることを確認します。

master agentx

この行が含まれていない場合は、この行を追加し、snmpd デーモンを再起動します。このデーモンに SIGHUP シグナルを送信するだけでは十分ではありません。snmpd デーモンの再起動後、snmpd が AgentX 通信のために作成した UNIX ドメインソケットを探します。Solaris および Linux システムでは、このソケットはデフォルトで特殊ファイル /var/agentx/master として表示されますが、その場所と名前は snmpd.conf によって変更されている場合があります。

Solaris 10 OS の snmpd 設定を次に示します。

%cp /etc/sma/snmp/snmpd.conf /etc/sma/snmp/snmpd.conf.save
% cat >> /etc/sma/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
^D
% cat >> /etc/sma/snmp/snmpd.conf
% ls -al /var/agentx/
srwxrwxrwx 1 root root 0 Aug 9 13:58 /var/agentx/master

また、Red Hat Enterprise Linux AS 3 システムのデフォルトの snmpd.conf ファイルは、「パブリック」の SNMP コミュニティーによって参照される可能性がある情報を制限しています。このため、その制限を削除するか、制限を緩和して Messaging Server のサブエージェントから提供される MIB を含める必要があります。初期のテストでは、後者をお勧めします。この作業は、次に示すように、「systemview」という名前のビューに OID サブツリーの mib-2.27 と mib-2.28 を追加することによって行います。実際の配備では、サイトごとに全体的なセキュリティーポリシーを考慮する必要があります。SNMP サブエージェントによって提供される情報は「読み取り専用」です。

% cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.save
% cat >>/etc/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
# Messaging Server's subagent exports mib-2.27 and .28
# Add the mib-2.27 and .28 OID subtrees to the systemview
view systemview included .1.3.6.1.2.1.27
view systemview included .1.3.6.1.2.1.28
^D
% /sbin/service snmpd restart
% ls -al /var/agentx/master
srwxr-xr-x 1 root root 0 Aug 8 21:20 /var/agentx/master

また、SNMP v3 コンテキスト名を使用して、同じホストコンピュータ上で同時に実行されている複数の Messaging Server インスタンスの MIB を識別する場合は、SNMP v3 クエリーで使用する SNMP v3 ユーザー名およびパスワードを少なくとも 1 つ設定する必要があります。

A.3.2 Messaging Server サブエージェントの設定

Messaging Server の SNMP サブエージェントの基本的な操作については、サブエージェントを有効にし、手動の開始コマンドを 1 回発行するだけで済みます。その後は、Messaging Server が開始または終了するたびに、サブエージェントも同様に開始または終了します。この設定を有効にするのに必要なコマンドは、Solaris と Linux のどちらでも次のとおりです。

% configutil -o local.snmp.enable -v 1
% start-msg snmp

実行後、コマンド行から snmpwalk コマンドを実行することにより、サブエージェントをテストできます。Solaris および Linux に対応する例については、次のスクリーンショットを参照してください。rfc2248.txt ファイルと rfc2249.txt ファイルは、それぞれ Network Services MIB と MTA MIB のコピーです。Solaris システムでは、これらのファイルが NETWORK-SERVICES-MIB.txt および MTA-MIB.txt という名前で /etc/sma/snmp/mibs/ ディレクトリにも存在する場合があります。これらのファイルを snmpwalk ツールに指定しなくてもかまいませんが、指定すると、snmpwalk は個々の MIB 変数をオブジェクト識別子 (OID) の数値ではなく名前で出力します。

Solaris 上での基本テスト:

% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
    -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/SUNWmsgsr MTA on mail.siroe.com
...
% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28
MTA-MIB::mtaReceivedMessages.1 = Counter32: 1452
MTA-MIB::mtaStoredMessages.1 = Gauge32: 21
...

Linux 上での基本テスト:

% export D=/opt/sun/messaging/examples/mibs
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/sun/messaging MTA on mail.siroe.com
...
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28
MTA-MIB::mtaReceivedMessages.1 = Counter32: 21278
MTA-MIB::mtaStoredMessages.1 = Gauge32: 7
...

A.3.3 スタンドアロン SNMP エージェントとしての実行

スタンドアロン SNMP エージェントとして実行されるように Messaging Server の SNMP サブエージェントを設定する場合は、最初にエージェントが SNMP 要求を待機する Ethernet インタフェースと UDP ポートを決定する必要があります。デフォルトでは、UDP ポート 161 を使用し、利用可能なすべての Ethernet インタフェースで待機します。ほとんどの場合、プラットフォームの SNMP マスターエージェントである snmpd を妨害しないようにポート番号を変更する必要があります。HA フェイルオーバーなど、状況によっては、Ethernet インタフェースも、利用可能なすべてのインタフェース (INADDR_ANY) から IP アドレスで識別される特定のインタフェースに変更する必要があります。Ethernet インタフェースと UDP ポートという 2 つの概念は、local.snmp.listenaddr オプションと local.snmp.port オプションによって制御されます。

Ethernet インタフェースと UPD ポートを選択したら、local.snmp.standalone オプションの値を 1 に設定し、サブエージェントを再起動するようにしてください。再起動後のサブエージェントは、snmpd やほかのサブエージェントとは独立した SNMP エージェントとして動作します。

たとえば、IP アドレスが 10.53.1.37 である Ethernet インタフェースの UDP ポート 9161 で待機するスタンドアロンエージェントとして実行するには、次に示すコマンドを発行します。

スタンドアロンエージェントとして実行するための設定:

% configutil -o local.snmp.port -v 9161
% configutil -o local.snmp.listenaddr -v 10.53.1.37
% configutil -o local.snmp.standalone -v 1
% stop-msg snmp
% start-msg snmp
% snmpwalk -v 1 -c public 10.53.1.37:9161 .
SNMPv2-SMI::mib-2.27.1.1.2.1 = STRING: "/opt/SUNWmsgsr MTA on mail.siroe.com"
...

A.3.4 複数の Messaging Server インスタンスの監視

ここでは、同じホストコンピュータ上で実行されている複数の Messaging Server インスタンスを監視する 2 つの方法について説明します。1 つはサブエージェントをスタンドアロンモードで実行する方法で、Messaging Server の個々のインスタンスがホストコンピュータ間を動的に移動する可能性がある高可用性フェイルオーバー (HA) 設定に適しています。もう 1 つは SNMP v3 コンテキスト名を使用する方法で、複数の Messaging Server インスタンスの場所が 1 つのシステムに限られており、SNMP 監視ソフトウェアによってポーリングされる IP アドレスの数を制限するのが望ましい場合 (たとえば、監視ソフトウェアのライセンスに IP アドレス単位で課金されるコンポーネントが含まれる場合など) に、ある程度のメリットがあります。この 2 つ目の方法は、HA フェイルオーバー設定にも使用できますが、その場合はスタンドアロンモードの方法と同じ数の IP アドレスをポーリングする必要があります。

A.3.5 高可用性フェイルオーバー用のスタンドアロンエージェントの使用

Messaging Server の SNMP 監視が必要な高可用性フェイルオーバー設定では、「A.3.3 スタンドアロン SNMP エージェントとしての実行」の説明に従って、Messaging Server の SNMP サブエージェントをスタンドアロンエージェントとして実行することをお勧めします。サブエージェントをスタンドアロンモードで実行する場合は、Messaging Server の各 HA インスタンスの local.snmp.listenaddr オプションをそのインスタンスのフェイルオーバー IP アドレスの値に設定するようにしてください。管理を簡単にするため、各インスタンスは同じ UDP ポートを使用するべきですが、各物理クラスタホスト上で実行されている snmpd デーモンが使用するポートとは異なるポートを使用するようにしてください。通常、これらのデーモンは UDP ポート 161 を使用するので、local.snmp.port オプションを使用して明示的に異なるポート番号を指定してください。

ここで推奨する方法に従って Messaging Server の SNMP サポートを設定すると、Messaging Server の各インスタンスがどの物理クラスタホスト上で実行されているかに関係なく、監視ステーションは各インスタンスのフェイルオーバー IP アドレスまたはホスト名によってインスタンスを監視できます。さらに、Messaging Server のスタンドアロン SNMP エージェントは、それぞれがそのインスタンス固有のフェイルオーバー IP アドレスによって識別される固有の仮想 Ethernet インタフェースでのみ待機するため、互いに競合しないことが保証されます。これらの仮想 Ethernet インタフェースは、HA フェイルオーバーフレームワークによって自動的に作成されます。UDP ポートが注意深く選択されているため、エージェントはクラスタ内のシステム上で実行されている snmpd デーモンと競合しません。

A.3.6 SNMP v3 コンテキスト名による複数インスタンスの識別

「A.3.3 スタンドアロン SNMP エージェントとしての実行」の説明に従ってスタンドアロンモードで Messaging Server の SNMP サポートを使用することによるマイナス面は特にありませんが、サイトによっては、同じシステム上で同時に実行されている複数の Messaging Server インスタンスを監視する機能を維持しながら、従来のサブエージェントモードを使用するのが望ましい場合があることがわかっています。たとえば、ライセンスモデルによってポーリングできる IP アドレスの数が制限される SNMP 監視システムの場合などです。この目的を達成するには、local.snmp.standalone を 0 に設定したままで Messaging Server の SNMP サブエージェントを実行し続けます。また、local.snmp.enablecontextname オプションに 0 以外の値を指定することにより、異なる SNMP v3 コンテキスト名を使用するように Messaging Server の各インスタンスを設定します。service.defaultdomain の値とは異なるコンテキスト名を使用する必要がある場合は、その名前を local.snmp.contextname オプションに設定します。Messaging Server の SNMP サブエージェントの各インスタンスは、再起動後、適切なコンテキスト名を含む SNMP v3 クエリーによって監視できます。同じシステム上で実行されている 2 つの Messaging Server インスタンスの MIB はそのインスタンスの SNMP v3 コンテキスト名によって識別されるため、MIB のオブジェクト識別子 (OID) の競合は発生しません。

A.3.7 Messaging Server の Net-SNMP ベースの SNMP サブエージェントオプション

次のオプションは、Messaging Server の Net-SNMP ベースの SNMP サブエージェントにのみ適用されます。このようなサブエージェントは、Solaris 10 以降および Linux プラットフォームで使用されます。次に示すオプションは、Solaris 9 以前のオペレーティングシステムを実行する Solaris プラットフォーム用に提供されていた旧バージョンの SNMP サブエージェントには適用されません。

次に示すオプションは、configutil のオプションです。したがって、オプションの値を調べるには、次の形式のコマンドを使用します。

% configutil -o option-name

option-name は、値を表示するオプションの名前です。オプションの値を設定または変更するには、次の形式のコマンドを使用します。

% configutil -o option-name -v option-value

option-value は、設定する値です。これらのオプションの変更を有効にするには、次のように再起動する必要があります。

% stop-msg snmp
% start-msg snmp

各オプションの説明とデフォルト値を次に示します。

表 A–1 SNMP サブエージェンのトオプション


オプション (デフォルト)	説明
local.snmp.enable (0)	Messaging Server の SNMP サブエージェントは、このオプションの値を `1` または `true` に指定した場合にのみ実行されます。その場合、Messaging Server は通常の起動およびシャットダウン手順の一環としてサブエージェントの停止と開始を自動的に実行します。このオプションは、デフォルトでは 0 に設定され、サブエージェントの実行を無効にします。サブエージェントを有効にする前に、プラットフォームのマスターエージェントが「A.3.3 スタンドアロン SNMP エージェントとしての実行」の説明に従って適切に設定されていることを確認してください。
local.snmp.standalone (0)	Messaging Server の SNMP サポートは、通常、SNMP サブエージェントとして実行され、プラットフォームの SNMP マスターエージェントである `snmpd` を介して SNMP 要求を受信します。この実行モードはデフォルトであり、このオプションの値を 0 または `false` に設定することによって選択されます。しかし、「A.3.3 スタンドアロン SNMP エージェントとしての実行」で説明したように、サブエージェントを「スタンドアロン」モードで実行することにより、`snmpd` とは独立した SNMP エージェントとしてサブエージェントを動作させることができます。サブエージェントをスタンドアロンモードで実行すると、1 つの SNMP エージェントになり、`local.snmp.listenaddr` オプションおよび `local.snmp.port` オプションでそれぞれ指定された Ethernet インタフェースおよび UDP ポートで SNMP 要求を直接待機します。このようにスタンドアロンモードで実行するには、このオプションの値に 1 または `TRUE` を指定します。スタンドアロンモードで実行しても、システム上で実行されているほかの SNMP マスターエージェントやサブエージェントを妨害することはありません。
local.snmp.listenaddr (INADDR_ANY)	スタンドアロンモードでの実行時に SNMP 要求を待機する Ethernet インタフェースのホスト名または IP アドレスです。デフォルトでは、利用可能なすべてのインタフェースで待機します。これは、値に `INADDR_ANY` を指定した場合に相当します。特定のインタフェースに関連付けられた IP アドレスまたはホスト名を指定することにより、そのインタフェースを選択できます。選択するインタフェースは、物理インタフェースと仮想インタフェースのどちらでもかまいません。 `local.snmp.standalone` に 0 または `FALSE` を指定すると、このオプションは無視されます。
local.snmp.cachettl (30)	キャッシュされた監視データの秒単位の有効時間 (TTL) です。このオプションは、サブエージェントが同じ監視データを報告し続け、そのデータを Messaging Server から取得した新しい情報で更新するまでの期間を制御します。メッセージループ情報を除き、デフォルトでは最大 30 秒間データがキャッシュされます。ループ情報は、`.HELD` ファイルのスキャンによって判定され、10 分ごとに 1 回だけ更新されます。その理由は、ディスク上のすべてのメッセージキューをスキャンする際のリソースコストです。サブエージェントは自身の監視データを継続的に更新しません。データは SNMP 要求の受信時にのみ更新され、キャッシュされたデータの有効期限が切れます。つまり、キャッシュされたデータの TTL が無効になります。TTL が 30 秒に設定され、SNMP 要求が 5 分ごとに 1 回だけ行われる場合、サブエージェントは SNMP 要求を受信した時点で Messaging Server から新しいデータを取得します。つまり、Messaging Server からのデータは 5 分ごとに 1 回だけ取得されます。一方、SNMP 要求が 10 秒間隔で行われた場合、サブエージェントは要求の一部に対して最大 29 秒間キャッシュされたデータで応答します。つまり、Messaging Server は 30 秒ごとに 1 回だけポーリングされます。
local.snmp.servertimeout (5)	サブエージェントは、監視対象サービスへの TCP 接続を実際に開き、プロトコル交換を実行することによって、各サービスの実行状態を判定します。このタイムアウト値は、秒単位で測定され、サブエージェントがプロトコル交換の各手順への応答を待機する期間を制御します。デフォルトでは、5 秒のタイムアウト値が使用されます。
local.snmp.directoryscan (1)	このオプションは、サブエージェントがディスク上のメッセージキュー内にある `.HELD` メッセージファイルおよびもっとも古いメッセージファイルのスキャンを実行するかどうかを制御するために使用されます。これらの情報は、MIB 変数の `mtaGroupLoopsDetected`、`mtaGroupOldestMessageStored`、および `mtaGroupOldestMessageId` に相当します。このオプションの値を 1 または `true` に設定すると、これらの情報のキャッシュが保持され、必要に応じて更新されます。キューに何千ものメッセージが格納され、これらの特定の MIB 変数に関心がないサイトでは、このオプションの値を 0 または `false` に設定することを検討するようにしてください。
local.snmp.enablecontextname (0)	サブエージェントには、自身の MIB を SNMP v3 コンテキスト名の下に登録する機能があります。MIB が登録されると、その MIB は SNMP 要求にコンテキスト名を指定する SNMP v3 クライアントからのみ要求されます。コンテキスト名を使用すると、複数の独立したサブエージェントが Network Services MIB と MTA MIB を同じ OID ツリーの下に (つまり、同じ SNMP マスターエージェントの下に) 登録できるようになります。詳細は、「A.3.4 複数の Messaging Server インスタンスの監視」を参照してください。 SNMP v3 コンテキスト名の使用を有効にするには、このオプションの値に 1 または `true` を指定します。このように指定すると、サブエージェントはそのコンテキスト名に `service.defaultdomain` オプションの値を使用するようにデフォルト設定されます。コンテキスト名にほかの値を使用するには、`local.snmp.contextname` オプションを使用します。
local.snmp.contextname (service.defaultdomain)	`local.snmp.enablecontextname` によって SNMP v3 コンテキスト名の使用が有効になっている場合は、このオプションを使用して、サブエージェントがその MIB に使用するコンテキスト名を明示的に設定できます。このオプションに指定する値は、文字列値であり、SNMP v3 コンテキスト名として使用するのに適した文字列である必要があります。`local.snmp.enablecontextname` の値が 0 または `false` である場合、このオプションは無視されます。