|
|
以下の節では、Oracle Communications Converged Application Server で SNMP サービスをコンフィグレーションおよび管理する方法について説明します。
Oracle Communications Converged Application Server には、エンジン層と SIP データ層のサーバ インスタンスのアクティビティをモニタするための専用 SNMP MIB が用意されています。Oracle Communications Converged Application Server の MIB は、ドメインの管理サーバと管理対象サーバの両方で生成されます。ただし、Oracle Communications Converged Application Server のエンジン層と SIP データ層のトラップを生成するのは、各層を構成する管理対象サーバ インスタンスだけです。管理サーバが sipserver のカスタム リソースのための対象でなければ、(クラスタ内のサーバで障害が起きた場合などに) WebLogic Server の SNMP トラップのみが生成されます。管理者は、ドメイン全体の動作を評価するために、WebLogic Server と Oracle Communications Converged Application Server の両方のトラップをモニタする必要があります。
| 注意 : | Oracle Communications Converged Application Server の MIB オブジェクトは読み込み専用です。SNMP を使って Oracle Communications Converged Application Server のコンフィグレーションを変更することはできません。 |
Oracle Communications Converged Application Server の MIB ファイルは、WLSS_HOME/server/lib/wlss/BEA-WLSS-MIB.asn1 にインストールされています。このファイルの内容を表示するには、利用可能な SNMP 管理ツールまたは MIB ブラウザを使用してください。共有 SNMP トラップの説明については、「トラップの説明」を参照してください。
Oracle Communications Converged Application Server ドメイン全体の SNMP モニタを有効にするには、次の手順に従います。
| 注意 : | Domain-Scoped エージェントではなく新しい Server SNMP エージェントを作成することを確認します。 |
以下の節では、Oracle Communications Converged Application Server の SNMP トラップについて詳しく説明します。また、個々のトラップに対処するための回復手順についても必要に応じて説明します。
以下の Oracle Communications Converged Application Server のログ ファイルおよびコンフィグレーション ファイルはトラブルシューティングに役立つことが多く、テクニカル サポートへの問い合わせの際に必要になることがあります。
テクニカル サポート チームが問題を解決する上で、次のような一般情報が役立つことがあります。
表 2-1 は、Oracle Communications Converged Application Server の各種 SNMP トラップをエンジン層のサーバで生成されるトラップと SIP データ層のサーバで生成されるトラップに分けて示したものです。それぞれのトラップについては、表に続く各節で説明します。
エンジン層のサーバ インスタンスが SIP データ層のレプリカに接続できなくなった場合は、そのエンジン層サーバでこのトラップが生成されます。エンジン層と SIP データ層の間でネットワーク接続の問題が起きている可能性があります。また、SIP データ層のサーバで障害が発生している場合は、このトラップと共に追加のトラップが生成されることがあります。
サーバの障害を示す他のトラップとは無関係にこのトラップが発生している場合は、一般にネットワークで障害が起きています。ネットワーク コネクションは、関わっているエンジン層のサーバと SIP データ層のサーバの間に質しまたは直します。
SIP データ層のサーバの障害を示す追加のトラップ (たとえば dataTierServerStopped) と共に発生している場合は、そのトラップの回復手順に従います。
以前に接続に失敗したエンジン層のサーバ インスタンスが (connectionLostToPeer トラップが生成された後で) SIP データ層のサーバへの再接続に成功した場合は、そのエンジン層サーバでこのトラップが生成されます。このトラップが繰り返し発生する場合は、エンジン層と SIP データ層の間で断続的なネットワーク障害が起きている可能性があります。
「connectionLostToPeer」を参照してください。
データ層に属する WebLogic Server インスタンスで回復不能なエラーが発生した場合は、Oracle Communications Converged Application Server の SIP データ層ノードでこのアラームが生成されます。このトラップは、エラーによって停止しようとしているサーバ自体で生成される場合と、同じパーティション内の別のレプリカで生成される場合があり、一部のケースでは両方のサーバで生成されることもあります (ネットワークの障害発生時には両方のサーバで同じトラップが生成されることがあります)。
「serverStopped」の回復手順を参照してください。
Oracle Communications Converged Application Server のエンジン層ノードでは、処理される新しい SIP リクエストの数を制御できるように、コンフィグレーション可能なスロットル機能のメカニズムが使われています。コンフィグレーションされている過負荷状態に達すると、Oracle Communications Converged Application Server は新しい SIP リクエストを破棄し、呼び出し側に「“503 Service Unavailable」で応答します。コンフィグレーションされているしきい制御値に従って、過負荷状態が解消するまでサーバは新しいリクエストを破棄し続けます。このアラームは、スロットル機能のメカニズムがアクティブになっているときに生成されます。スロットル機能の動作により、サーバは最終的に過負荷でない状態に戻るので、それ以上のアクションは必要ありません。『コンフィグレーション リファレンス マニュアル』の「Overload」を参照してください。
1. 他のサーバをチェックし、過負荷に近い状態かどうかを確認します。
2. ロード バランサがアプリケーション サーバ間で正しく負荷を分散しているかどうか、それとも 1 つまたは複数のサーバを過負荷状態にしているかどうかを確認します。追加のサーバが過負荷に近い状態の場合は、直ちに Tier 4 サポートに連絡してください。
3. 問題が 1 つのサーバに限られている場合は、1 時間以内に Tier 4 サポートに通知してください。
質問 : 管理サーバを使って負荷をモニタするにはどうすればよいですか。しきい値に近い状態であることはどうすればわかりますか。
回答 : キューの長さを着信呼び出し過負荷制御として設定すると、Administration Console を使ってキューの長さをモニタすることができます。セッション レート制御を指定すると、Administration Console を使ってセッション レートをモニタできません。(Administration Console には、SIP セッションの現在の数だけが表示され、新しいセッションが生成されるレートは表示されません)。
サーバ インスタンスがデータ層のパーティションに追加された場合は、Oracle Communications Converged Application Server の SIP データ層ノードでこのアラームが生成されます。
このトラップは、SIP データ層のサーバを起動した場合の通常の起動処理時に生成されます。
登録されていない (または登録済みエンジンのリストから削除されている) エンジン サーバ クライアントは SIP データ層と通信しようとすると、SIP データ層ノードでこのアラームが生成されます。 一般に、このトラップはserverStopped トラップ後に続いています。これは、SIP データ層の一貫性を保持するためにエンジン層サーバはシャットダウンされていること示しています。
エンジン層サーバを再起動します。このトラップが繰り返し発生する場合は、エンジン層と 1 つまたは複数のレプリカの間でネットワーク接続の問題が起きている可能性があります。
通常の停止操作によって、または障害が原因でサーバが SIP データ層から削除された場合は、Oracle Communications Converged Application Server の SIP データ層ノードでこのアラームが生成されます。このトラップが生成されるのは、サーバの削除後、そのパーティション内で少なくとも 1 つのレプリカが動作し続けている場合だけです。レプリカが 1 つしか存在しないパーティションでそのレプリカに障害が発生した場合は、トラップを生成できません。また、レプリカに障害が発生したことはエンジン層のノードによって検出されるので、このトラップが生成可能であるためには、いずれかのエンジン層ノードが実行されている必要があります。
サーバ インスタンスの障害が原因でこのトラップが生成された場合は、例外を示す追加のトラップが生成されます。replicaRemovedFromPartition と共に生成されたトラップの回復手順を参照してください。
このトラップは、WebLogic Server インスタンスが現在ダウンしていることを示します。このトラップはエンジン層と SIP データ層の両方のサーバ インスタンスに適用されますが、それは、サーバが名前付きの WebLogic Server クラスタのメンバーである場合に限られます。このトラップが、制御された停止によって発生したのではなく、自然に生成された場合は、次の手順に従います。
ps – ef | grep java
マシンで実行中の WebLogic Server インスタンスごとに、対応する PID が 1 つだけあるはずです。
kill -3 [pid]
| 注意 : | Oracle Communications Converged Application Server のログは、システムのコンフィグレーションに従って切り捨てられます。重要なトラブルシューティングの情報が失われないように、バックアップ ログを直ちに作成してください。 |
質問 : サーバが停止した場合、サーバのすべての SNMP トラップが失われるのですか。
回答 : Administration Console が管理対象 WebLogic Server インスタンスの SNMP メッセージを生成するのは、ServerShutDown メッセージを受け取るまでです。それ以降は、追加のメッセージは生成されません。
SIP サーブレットがコンテナにデプロイされた場合は、Oracle Communications Converged Application Server のエンジン層ノードでこのアラームが生成されます。
このトラップは、通常のデプロイメント処理時に生成されます。例外を示しているわけではありません。
SIP アプリケーションが停止した場合、または SIP アプリケーションがアンデプロイされた場合は、Oracle Communications Converged Application Server のエンジン層ノードでこのアラームが生成されます。一般に、アクティブなリクエストがまだ存在するにもかかわらず Oracle Communications Converged Application Server が停止した場合に発生します。
通常の停止の手順では、このアラームは除去されるため、通知されないはずです。通常の運用の最中にこのアラームが発生した場合は、誰かがアプリケーションまたはサーバを突然停止させたか、アプリケーションに問題があることを意味しています。直ちに Tier 4 サポートに連絡してください。
アプリケーションが Web アプリケーションとしては正しくデプロイされたが、SIP アプリケーションとしてデプロイされなかった場合は、Oracle Communications Converged Application Server のエンジン層ノードでこのトラップが生成されます。
無効な sip.xml コンフィグレーション ファイルが原因で起きることが多く、ソフトウェアのインストール時またはアップグレード時にのみ発生します。この問題が発生した場合は、アプリケーションをアンデプロイし、sip.xml ファイルを検証した後、デプロイメントをやり直します。
| 注意 : | 通常の運用時にこのアラームが発生することは決してないはずです。もし発生した場合は、直ちに Tier 4 サポートに連絡してください。 |
|