N1 Provisioning Server 3.1, Blades Edition システム管理ガイド

監視の問題の障害追跡

この節では、一部の一般的な監視の問題を説明します。問題を診断する方法と、可能な修正処置を紹介します。監視の概念の解説については、第 4 章「監視とメッセージ」を参照してください。

最も一般的な問題には次のものがあります。

1 つまたは複数のリソースプールサーバーから UP メッセージが受信されない。
Control Center の「Element Monitor」ウィンドウで、モニターに色が表示されない。
UP メッセージが送信されたにもかかわらず、ファームが起動しない。
頻繁に UP メッセージと DOWN メッセージが受信される。

これらの問題の多くには、相互に関連する根本原因があります。最も多い原因には次のものがあります。

ネットワーク、DNS、または DHCP の問題。
コントロールプレーンサーバーで監視プロセスが動作していない。
リソースプールサーバーでエージェントプロセスが動作していない。

この節では、これらの症状の診断方法を説明します。「監視に関する修正処置」では、これらの問題を解決するための修正処置が説明されています。

1 つまたは複数のサーバーから UP メッセージが受信されない

次の条件が存在するかどうかを確認することで、コントロールプレーンサーバー上で UP メッセージの問題を確認できます。

/var/adm/tspr.debug ファイルでは、メッセージは次のような形式になっています。
"Still waiting for 1 device(s) in 2879974 ms"

次の例にあるように、ファームの起動では ERROR 50 が示されています。

FARM_ID    FARM_NAME   CUSTOMER   STATE   ISTATE       ERROR  
123        Farm_Name   Customer   NEW      DISPATCHED   50

次の図に、この問題の診断と解決に必要な手順を示します。

図 7–2 監視の問題の解決

上記の図は、次の一連の障害追跡を表しています。

ネットワーク、DNS、または DHCP の問題を確認します。この方法の詳細については、「ネットワーク、DNS、または DHCP の問題」を参照してください。
監視プロセスがコントロールプレーンサーバー上で動作中であることを確認します。詳細については、「監視プロセスがコントロールプレーン上で動作していない」を参照してください。この節の指示に従ってプロセスを再起動します。
エージェントプロセスがリソースプールサーバー上で動作中であることを確認します。詳細については、「エージェントプロセスがリソースプールサーバー上で動作していない」を参照してください。エージェントプロセスが動作中でない場合は、この節の指示に従ってエージェントプロセスを再起動します。

Control Center の「Element Monitor」ウィンドウで、モニターに色が表示されない

ファーム固有のモニターが Control Center に表示されない場合があります。この状態の原因としては、次のいずれかの問題が考えられます。

サーバーでエージェントプロセスが動作していない。
gw-mon-vip と Control Center サーバーソフトウェアの IP アドレスとのマッピングが、コントロールプレーンサーバーの /etc/hosts ファイルで設定されていない。
Control Center 上のリスナーが動作していない。この状態を確認する方法の詳細については、「コントロールプレーンサーバーから Control Center へのメッセージが機能していない」を参照してください。

図 7–2 に、上記のエラー状態を診断および解決するために従うべき一連の手順を示します。これらの問題の解決方法の詳細については、「コントロールプレーンサーバーから Control Center へのメッセージが機能していない」を参照してください。

ファームが起動しない

監視システムにより UP メッセージが送信された場合であっても、セグメントマネージャが動作していない場合があります。この場合、セグメントマネージャを再起動します。この手順の詳細については、「ブロックされた要求の確認」を参照してください。

頻繁に UP と Down のメッセージが受信される

N1 Provisioning Server 上でのインタフェースの設定ミスの結果として、あるサーバーに関して多数の UP と DOWN のメッセージが受信される場合があります。

clearNicInterface コマンドを実行して、コントロールプレーンサーバー上の重複する Ethernet インタフェースをクリアします。このコマンドの使用法の詳細については、マニュアルページを参照してください。

一般的な監視の症状の診断

数多くの問題に共通する数多くの症状が存在します。この節では、次の症状を診断する方法を説明します。

ネットワーク、DNS、または DHCP の問題

ネットワーク、DNS、または DHCP の問題に関して、次の表の項目を確認します。

表 7–4 エラーの確認


確認するエラー	エラーを確認する対象
コントロールプレーンサーバーで次のコマンドを実行して、すべてのリソースプールサーバーが `ping` の信号を受信できることを確認する。 `/opt/terraspring/sbin/mls -lf farm-ID`. 注 – このコマンドにより、`ping` の信号を受信できる、ファーム内の全サーバーが表示される。	`ADDED` として表示されているすべてのサーバー
各サーバーに対して `telnet` を実行することで、すべてのリソースプールサーバーに到達可能であることを確認する。	`telnet` を使用しても到達不能なすべてのサーバー

注 –

場合によっては、サーバーが ping の信号を受信できても、シングルユーザーモードでは telnet を使用しても到達不能であることがあります。この問題を解決するには、コンソールポートに接続し、マルチユーザーモードでブートします。

監視プロセスがコントロールプレーン上で動作していない

監視プロセスに関する診断を確定させた後、次のコマンドを実行します。

/usr/ucb/ps -auxww | grep MM

監視プロセスが動作中である場合は、次の例のような出力が表示されます。

USER	 PID %CPU %MEM SZ  RSS TT   S START  TIME  COMMAND
root 14540 0.2	1.14 485 620 608? S Mar 05	 18:32 /bin/../java/bin/..
/bin/sparc/native_threads/java -Dsun.net.inetaddr.ttl=0 com.
terraspring.mon.MM 
root 9529  0.1	0.1	  976 672 pts/2 S 11:49:40 0:00 grep MM

監視プロセスが動作中でない場合は、次の例のような出力が表示されます。

USER PID %CPU %MEM  SZ  RSS TT     S  START TIME     COMMAND
root 9565 0.1  0.1  976 672 pts/2  S  11:50:28  0:00 grep MM

プロセスを再起動する方法の詳細については、「コントロールプレーンサーバーでの監視プロセスの再起動」を参照してください。

エージェントプロセスがリソースプールサーバー上で動作していない

リソースプールサーバーでエージェントプロセスが動作していない可能性があります。次のいずれかの方法で、この状態を確認します。

コントロールプレーンサーバーで、次のコマンドを実行します。
/opt/terraspring/sbin/mls -a IP address of host
このコマンドを使用するためには、サーバーの IP アドレスの情報が必要です。
動作中であることを確認したいエージェント存在がするサーバーで、次のコマンドを実行します。
/usr/ucb/ps -auxww | grep tspragt
エージェントプロセスが動作中である場合は、次の例のような出力が表示されます。
root 7652 0.1 0.1 976 656 pts/1 S 11:37:30 0:00 grep tspragt
root 321 0.1 0.73167213816 ? S 16:26:37 0:10 /usr/bin/../java/bin/.. /bin/sparc/native_threads/java -Dsun.net.inetaddr.ttl=0 com.terraspring.mon.client.tspragt start 10.42.14.2
エージェントプロセスが動作中でない場合は、次の例のような出力が表示されます。
root 7709 0.1 0.1 976 656 pts/1 S 11:39:54 0:00 grep tspragt

プロセスを再起動する方法の詳細については、「リソースプールサーバーでのエージェントプロセスの再起動」を参照してください。

コントロールプレーンサーバーから Control Center へのメッセージが機能していない

さまざまな理由により、コントロールプレーンサーバーと Control Center 間のメッセージが機能しない場合があります。最も一般的な理由には次のものがあります。

gw-mon-vip と Control Center サーバーソフトウェアの IP アドレスとのマッピングが、コントロールプレーンサーバーの /etc/hosts ファイルで設定されていない。適切なエントリが存在することを調べて、この状態を確認します。

以下に例を示します。
10.5.131.19 gw-mon-vip
Control Center サーバーソフトウェア上でリスナーが動作していない。この状態を確認するには、コントロールプレーンサーバー上で finger test@gw-mon-vip を実行します。予測される出力の例は、次の例のようになります。
[gw-mon-vip]
または
[hostname]

監視に関する修正処置

この節では、監視の問題解決に対して適用できる数多くの修正処置を説明します。

コントロールプレーンサーバーでの監視プロセスの再起動

監視プロセスを再起動するには、コントロールプレーンサーバーで次のコマンドを実行します。

/opt/terraspring/sbin/mmd stop

このコマンドにより、関連するすべてのプロセスが停止されます。監視プロセスを再起動するには、次のコマンドを使用します。

/opt/terraspring/sbin/mmd start

リソースプールサーバーでのエージェントプロセスの再起動

コントロールエージェントプロセスがサーバー上で停止した場合、次のコマンドを使用してサーバーでプロセスを起動します。

/etc/init.d/N1PSagt start

プロセスが再起動したことを確認するには、コントロールプレーンサーバーから次のコマンドを実行します。

/opt/terraspring/sbin/mls -a server IP address

エージェントが動作中である場合は、次のような出力が表示されます。

FARM_ID IP_ADDRESS TYPE STATE DB_STATE SINCE 134 10.9.0.35 Server UP UP Feb 05 14:15:32

エージェントがリアルタイム (STATE) ではダウンしている場合も、データベース状態は 5 分ごとに更新されるため、エージェントはまだデータベース (DB_STATE) で UP としてマークされている場合があります。そのため、リアルタイムではアップであっても、データベース状態ではまだダウンである場合もあります。次のような出力が表示されます。

FARM_ID IP_ADDRESS TYPE STATE DB_STATE SINCE 134 10.9.0.35 Server DOWN UP Feb 10 14:20:33