| Oracle® WebLogic Server SIP Container管理者ガイド 11g リリース1(11.1.1) B61429-02 |
|
 前 |
 次 |
次の項では、サーバーがネットワークから物理的に切断されたときに、SIPデータ層のフェイルオーバー・パフォーマンスを向上するために、Oracle WebLogic Server SIP Containerの「エコー・サーバー」処理の使用を構成する方法を説明します。
サーバー・インスタンスの障害は、さまざまな出来事によって引き起こされます。1つの障害が別の障害のきっかけになることも少なくありません。停電、ハードウェアの故障、オペレーティング・システムのクラッシュ、ネットワーク・パーティション、アプリケーションの予期しない動作は、いずれもサーバー・インスタンスの障害の一因になり得ます。
Oracle WebLogic Server SIP Containerは、障害イベントの影響を最小化するための基礎として、高度にクラスタリングされたアーキテクチャを使用します。ただし、クラスタリングした環境でも、各サーバーまたはサーバー・マシンで障害が発生するイベントにおいて正常なリカバリ処理を準備することは重要となります。
次の項では、Oracle WebLogic Server SIP Containerの障害を保護する機能およびリカバリする機能についてまとめており、Oracle WebLogic Server SIP Containerドメインの各部をリストアするために必要な構成アーティファクトを説明しています。
Oracle WebLogic Server SIP Containerおよび基礎となるWebLogic Serverプラットホームによって、サーバー障害に対する多数の保護機能が提供されます。本番システムでは、無中断のサービスを保証するためにすべての使用可能な機能が使用されます。
Oracle WebLogic Server SIP Containerは、デプロイ済SIPサーブレットのパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出し、あらかじめ定義された負荷のしきい値に達するとメッセージの処理を自動的に規制します。
過負荷保護を使用すると、予期しないレベルのアプリケーション・トラフィックやリソース使用率が原因で発生する障害を回避することができます。
Oracle WebLogic Server SIP Containerは、特定の条件が発生したとき、障害の回避を試みます:
SIPセッションの作成レートが構成された値に到達するか、または
SIPタイマーおよびSIPリクエスト処理実行キューのサイズが構成された値に到達した。
基盤となるWebLogic Serverプラットフォームは、デプロイ済アプリケーションのパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出します。WebLogic Serverではあらかじめ定義されたロードのしきい値で自動的に発生する障害回避アクションの構成を管理者に許可します。自動過負荷保護は、次によって示される、予期しないレベルのアプリケーション・トラフィックやリソース使用が原因で発生する障害を回避するのに役立ちます:
超過しつつあるワークロード・マネージャのキャパシティ
事前定義されたしきい値まで増大しているHTTPセッション数
差し迫ったメモリー不足状態
専用SIPデータ層クラスタ内の複数のSIPデータ層サーバー(レプリカ)とともに、専用クラス内の複数のエンジン層サーバーを使用することによって、アプリケーションの信頼性と可用性を向上できます。エンジン層クラスタはSIPダイアログ(呼出し)に関するステートフルな情報を保持しないので、エンジン層サーバーの障害によってデータ損失や呼出しの喪失が生じることはありません。SIPデータ層パーティション内の複数のレプリカは、呼出し状態情報の冗長なコピーを保存し、レプリカが失敗した場合は自動的に相互にフェイルオーバーを行います。
WebLogic Serverの自己ヘルス監視機能は、ドメイン内のサーバー・インスタンスの信頼性および可用性を向上させます。各サーバー・インスタンス内の選択されたサブシステムは、サブシステム固有の基準に基づいてヘルス状態を監視します。(たとえば、JMSサブシステムは、コア・サーバーのサブシステムがデフォルトおよびユーザー定義の実行キュー統計を監視する間に、JMSスレッド・プールの条件を監視します)各サブシステムは、一貫性のある信頼できる方法でもう稼働できないと判定される場合、ホスト・サーバーにヘルス・ステータスを「失敗」として登録します。
次に各WebLogic Serverインスタンスは、全体的に稼働が可能であるか判断するために、登録されたサブシステムの状態をチェックします。1つまたは複数のクリティカルのサブシステムがFAILED状態に達した場合、サーバー・インスタンスはアプリケーションを確実にホストできないことを示すためにそれ自体の状態をFAILEDにマークします。
ノード・マネージャと組み合せて使用されるとき、サーバーの自己ヘルス監視によって、自動的に障害が発生したサーバーを再起動することができるようになります。これによって、ドメインの全体の信頼性が向上し、管理者からの直接介入が必要なくなります。
管理対象サーバーは、ドメイン構成のローカル・コピーを保持します。管理対象サーバーは起動時に、管理対象サーバーが最後にシャットダウンされてから行われたドメイン構成に対する変更を取得するために、管理サーバーに接続します。管理対象サーバーが起動中に管理サーバーに接続できない場合、ローカルにキャッシュされた構成情報を使用できます。この情報は、管理対象サーバーが最後にシャットダウンされたときの構成です。構成の更新をチェックするために管理サーバーに接続せずに起動する管理対象サーバーは、管理対象サーバーの独立(MSI)モードで稼働しています。デフォルトでは、MSIモードは有効化されています。
LinuxまたはUNIXオペレーティング・システムを使用するとき、WebLogic Serverのサーバー移行機能を使用すると、ネットワーク層サーバーのマシンで障害が発生する場合またはネットワークからパーティション化されている場合に、候補(バックアップ)サーバーを自動的に起動できます。サーバー移行機能は、wlsifconfig.shスクリプトとともにノード・マネージャを使用し、フローティングIPアドレスを使用して候補サーバーを自動的に起動できます。候補サーバーは、ネットワーク層インスタンスをホストしているプライマリ・サーバーがアクセスできなくなる場合にのみ、起動されます。サーバー移行機能の使用の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のサーバー全体の移行に関する項を参照してください。
サーバー・インスタンスの障害からのリカバリでは、ドメインの構成データにアクセスする必要があります。デフォルトでは、管理サーバーはdomain_name/config/config.xmlと呼ばれるファイルにドメインのプライマリ構成データを保存します。ここで、domain_nameはドメインのルート・ディレクトリです。プライマリ構成ファイルは、JDBCやJMSなどの固有のWebLogic Serverサービスの追加構成ファイルや、SIPコンテナ・プロパティやSIPデータ層構成などのOracle WebLogic Server SIP Containerサービスの追加構成ファイルを参照できます。固有のサービスの構成は、Oracle WebLogic Server SIP Container構成ファイルのdomain_name/config/jms、domain_name/config/jdbc、およびdomain_name/config/customなどの、domain_name/configディレクトリのサブディレクトリ内にある追加XMLファイルに保存されます。
管理サーバーは、ドメイン構成(domain-name/configディレクトリ全体)の複数バージョンを自動的にアーカイブできます。構成アーカイブは、間違って変更した構成を元に戻す必要がある場合に、システムをリストアするために使用されます。たとえば、管理者が構成されたリソースを間違って削除した場合、最新の自動バックアップを使用して以前の構成をリストアできます。
管理サーバーは、有限の数の自動バックアップのみをローカルでdomain_name/configに保存します。このため、自動ドメイン・バックアップは、ハードディスク障害などのデータ破損に対する保護機能に限定されます。また、自動バックアップは、LDAPリポジトリ・データやサーバー起動スクリプトなどのフル・ドメイン・リストアに必要な特定の構成データも保存しません。ソース制御システムで、構成およびセキュリティ・オフラインの複数のバックアップ・コピーも保持することをお薦めします。
この項では、Oracle WebLogic Server SIP Containerが自動的に実行するファイル・バックアップ、および管理者が定期的に実行する必要がある手動バックアップ処理を説明しています。
ドメインの管理サーバー上で、自動ドメイン構成バックアップを有効するには、次の手順に従います。
ドメインの管理コンソールにアクセスします。
管理コンソールの左ペインで、ドメイン名を選択します。
右ペインで、「構成」>「全般」タブをクリックします。
「詳細設定」を選択し、詳細オプションを表示します。
「構成アーカイブの有効化」を選択します。
「アーカイブ構成数」ボックスに、保存する構成ファイル・リビジョンの最大数を入力します。
「保存」をクリックします。
構成のアーカイブを有効化すると、管理サーバーは自動的に構成JARファイル・アーカイブを作成します。JARファイルには、以前の構成の完全なコピー(domain-name\configディレクトリの完全コンテンツ)が含まれます。JARファイルのアーカイブ・ファイルは、domain-name\configArchiveディレクトリに保存されます。これらのファイルは、config-number.jarというネーミング・ルールを使用します。ここで、numberはアーカイブの連続番号です。
ドメインの構成への変更を保存するとき、管理サーバーは以前の構成をdomain-name\configArchive\config.xml#nに保存します。管理サーバーは、configArchiveディレクトリにファイルを保存するたびに、#n接尾辞の値を構成可能なコピー数(デフォルトは5)まで増加させます。その後、ドメイン構成を変更するたびに、次のような処理が行われます。
アーカイブ済のファイルが循環し、最新のファイルに最も大きい番号のサフィックスが付けられます。
以前にアーカイブされたファイルの名前に付いた番号は1つずつ小さくなります。
最も古いファイルが削除されます。
構成アーカイブはドメイン・ディレクトリ内にローカルで保存され、選択したリビジョンの最大数に従ってオーバーライドされる可能性があることを覚えておいてください。このため、5.1.2.2項「ドメイン構成オフラインの保存」で説明されているように、独自のドメイン構成のオフライン・アーカイブも作成する必要があります。
自動バックアップにより偶発的な構成への変更は防止できますが、ドメイン構成を格納するハード・ディスクの障害によって発生するデータ損失やドメイン・ディレクトリの偶発的削除は防げません。これらの障害から保護するには、できればソース・コントロール・システムでドメイン構成オフライン全体のコピーを格納する必要があります。
定期的にドメイン構成のコピーを保存することをお薦めます。たとえば、次の場合には、構成の最新の改訂をバックアップします。
本番システムを最初にデプロイした場合
デプロイされたアプリケーションを追加または除去した場合
構成をパフォーマンスを向上させるためにチューニングした場合
その他の恒久的変更を行った場合
ドメイン構成バックアップには、domain_name/configディレクトリの完全なコンテンツが含まれる必要があります。例:
cd ~/user_projects/domains/mydomain tar cvf domain-backup-06-17-2007.jar config
ソース・コントロール・システムで新しいアーカイブを格納する場合、過去のある時点のドメイン構成を回復するために必要な以前のバージョンを保存します。
Oracle WebLogic Server SIP Containerデプロイメントでは、エンジンおよびSIPデータ層サーバーの起動に使用される起動スクリプトは、通常、次のようなドメイン固有の構成情報を含むようにカスタマイズされます。
JVMガベージ・コレクション・パラメータは、SIPメッセージ処理のスループット・ターゲットを達成するために必要になります(5.8項「本番デプロイメントときのJVMガベージ・コレクションのチューニング」を参照)。異なるパラメータ(および、そのために異なる起動スクリプト)は、通常、エンジンおよびSIPデータ層サーバーの起動に使用されます。
Oracle WebLogic Server SIP Containerハートビート・メカニズムの構成パラメータおよび起動情報。ハートビート・メカニズムを使用する場合、エンジン層サーバーの起動スクリプトには、ハートビート・メカニズムを有効化して構成するための起動オプションが含まれる必要があります。SIPデータ層サーバーの起動スクリプトには、ハートビートを有効化してWlssEchoServerプロセスを開始するための起動オプションが含まれる必要があります。
ドメイン内のエンジン層サーバー、SIPデータ層サーバー、またはDiameterリレー・サーバーの起動に使われる個別の起動スクリプトをバックアップします。
SIPメッセージの定期的なロギングまたは監査を実行するためにOracle WebLogic Server SIP Containerロギング・サーブレット(5.7項「SIPリクエストおよびレスポンスのロギング」を参照)を使用する場合、ステージング・サーバーで障害が発生したり元のデプロイメント・ディレクトリが破損したりする場合でも容易にアプリケーションを再デプロイできるように、完全なアプリケーション・ソース・ファイルをバックアップしてください。
WebLogicセキュリティ・サービスは、構成データのconfig.xmlファイルをLDAPリポジトリや他のファイルにも保存します。
すべてのサーバーは、SerializedSystemIni.datという名前のファイルを作成し、それをサーバーのルート・ディレクトリに配置します。このファイルには、サーバーを起動するために必要な暗号化されたセキュリティ・データが含まれます。このファイルをバックアップする必要があります。
サーバーでSSLを使用する場合は、セキュリティ証明書とキーもバックアップします。これらのファイルの場所はユーザーが構成できます。
Oracle WebLogic Server SIP Containerにインストールされるデフォルトの認証、認可、ロール・マッパー、および資格証明マッパーは、それらのデータをLDAPサーバーに保存します。それぞれのOracle WebLogic Server SIP Containerには、組込みLDAPサーバーが含まれます。管理サーバーにはマスターLDAPサーバーが含まれ、すべての管理対象サーバー上でレプリケートされます。任意のセキュリティ・レルムがこれらのインストールされたプロバイダを使用する場合、次のディレクトリ・ツリーの最新バックアップを保持する必要があります。
domain_name\adminServer\ldap
ここで、domain_nameはドメインのルート・ディレクトリで、adminServerは管理サーバーがランタイム・データおよびセキュリティ・データを保存するディレクトリです。
それぞれのOracle WebLogic Server SIP ContainerにはLDAPディレクトリが含まれますが、管理サーバー上のLDAPデータのみバックアップする必要があります。ここで、マスターLDAPサーバーは、セキュリティ・データの更新時に各管理対象サーバーのLDAPデータをレプリケートします。WebLogicセキュリティ・プロバイダは、ドメインの管理サーバーが使用できない間は、セキュリティ・データを変更できません。各管理対象サーバーのLDAPリポジトリはレプリカなので変更できません。
ldap/ldapfilesサブディレクトリには、LDAPサーバーのデータ・ファイルが含まれます。このディレクトリのファイルには、ユーザー、グループ、グループ・メンバーシップ、ポリシー、およびロール情報が含まれます。ldapの他のサブディレクトリには、レプリケートされたLDAPサーバーに関するLDAPサーバー・メッセージ・ログおよびデータが含まれます。
LDAPデータのバックアップ中はセキュリティ・プロバイダの構成を更新しないでください。ldapディレクトリ・ツリーのバックアップ中に変更が行われた場合(たとえば、管理者がユーザーを追加する場合)、ldapfilesサブディレクトリ内のバックアップは一致しなくなる可能性があります。これが起こった場合、内容が一致しても古い可能性があるLDAPデータのバックアップを使用できます。
1日に1回、サーバーは書込み操作を一時停止してLDAPデータの独自バックアップを作成します。このバックアップをldap\backupディレクトリのZIPファイルにアーカイブ化した後、書込み操作を再開します。このバックアップは、内容が一致することが保証されていますが、最新のセキュリティ・データを含んでいない可能性があります。
オペレーティング・システム・レベルで保持される特定のファイルも、システム障害からの回復において非常に重要な役割を果たします。システムの必要に応じて、以下の情報をバックアップすることを検討してください。
ロード・バランサの構成スクリプト。たとえば、エンジン層クラスタのロード・バランサ・プールと仮想IPアドレス、およびNAT構成の設定を構成するために使われる自動化スクリプト。
エンジン層サーバーとSIPデータ層サーバーのシステム時計を同期するために使用されるNTPクライアントの構成スクリプト。
それぞれのOracle WebLogic Server SIP Containerマシンのホスト構成ファイル(ホスト名、マルチ・ホーム・マシンの仮想/実際のIPアドレス、IPルーティング表情報)。
障害が発生した管理サーバーを再起動するときに、特別な手順に従う必要はありません。通常どおりの方法で管理サーバーを起動してください。
管理対象サーバーの実行中に管理サーバーが停止した場合、ドメインの管理を回復するために、実行されている管理対象サーバーを再起動する必要はありません。アクティブなドメインの管理を回復する手順は、ドメインの開始時に実行されていたのと同じマシンで管理サーバーを再起動できるかどうかによって異なります。
管理対象サーバーの実行中にWebLogic管理サーバーを再起動した場合、デフォルトでは、管理サーバーは実行中の管理対象サーバーの存在を検出することができます。
|
注意: 起動コマンドまたは起動スクリプトに-Dweblogic.management.discover=falseが含まれていないことを確認してください。これが含まれていると、管理サーバーは稼働中の管理対象サーバーを検出できません。 |
ドメインのルート・ディレクトリには、running-managed-servers.xmlというファイルが含まれています。このファイルには、ドメイン内の管理対象サーバーのリストがあり、稼働中かどうかが記述されています。管理サーバーが再起動するとき、稼働を呈する前にどの管理対象サーバーが制御下にあるかを判定するためにこのファイルをチェックします。
管理対象サーバーが正常または強制的にシャットダウンされるとき、running-managed-servers.xmlにおけるそのステータスは「非稼働中」に更新されます。管理サーバーが再起動するとき、「非稼働中」ステータスの管理対象サーバーを検出しようとしません。システム・クラッシュのために稼働を停止する管理対象サーバーや、実行中のJVMまたはコマンド・プロンプト(シェル)を停止することによって停止される管理対象サーバーでは、running-managed-servers.xmlにおけるステータスは「稼働中」のままになります。管理サーバーはそれらを検出しようと試行し、管理対象サーバーがもう稼働していないと判定するとき例外を表示します。
管理サーバーを再起動すると、管理対象サーバーが静的な属性の構成を更新しません。静的な属性とは、起動プロセス中にのみサーバーが参照する属性です。サーバー・インスタンスは、静的な構成属性に対する変更を考慮して再起動される必要があります。管理対象サーバーの検出によって、管理サーバーは管理対象サーバーの監視またはサーバーの稼働中(動的な属性)に構成可能な属性におけるランタイム変更のみ可能になります。
マシンのクラッシュにより、同じマシンで管理サーバーを再起動できない場合は、次のようにして実行中の管理対象サーバーの管理を回復できます。
Oracle WebLogic Server SIP Containerソフトウェアを新しい管理マシンにインストールしてください(未インストールの場合)。
アプリケーション・ファイルをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバーがこれらのファイルを使用できるようにします。新しいファイル・システム上でのアプリケーション・ファイルの相対位置は、元の管理サーバーのファイル・システムと同じにする必要があります。
バックアップからコピーするか、または共有ディスクを使用することによって、構成データおよびセキュリティ・データを新しい管理マシンで使用可能にします。詳細は、5.1.2.2項「ドメイン構成オフラインの保存」および5.1.2.5項「セキュリティ・データのバックアップ」を参照してください。
新しいマシンで管理サーバーを再起動します。
起動コマンドまたは起動スクリプトに-Dweblogic.management.discover=falseが含まれていないことを確認してください。これが含まれていると、管理サーバーは稼働中の管理対象サーバーを検出できません。
管理サーバーは、起動時に管理対象サーバーと通信して、管理サーバーが異なるIPアドレスで動作していることを通知します。
障害が発生した管理対象サーバーが稼働するマシンがドメインの管理サーバーにアクセスできる場合、ノード・マネージャを使用して管理対象サーバーを手動または自動で再起動します。自動再起動をサポートするように、ノード・マネージャおよび管理対象サーバーを構成する必要があるので注意してください。
管理対象サーバーが起動時に管理サーバーに接続できない場合、ローカルにキャッシュされた構成データを読み取ることによって、サーバーの構成データを取得できます。このようにして起動される管理対象サーバーは、管理対象サーバー(MSI)の独立モードで稼働しています。
MSIモードで管理対象サーバーを起動するには、次の手順に従います。
次のファイルが管理対象サーバーのルート・ディレクトリで使用できることを確認してください。
msi-config.xml
SerializedSystemIni.dat
boot.properties
これらのファイルが管理対象サーバーのルート・ディレクトリにない場合、
config.xmlおよびSerializedSystemIni.datファイルを管理サーバーのルート・ディレクトリ(またはバックアップ)から管理対象サーバーのルート・ディレクトリにコピーします。
構成ファイルの名前を変更して、msi-config.xmlにします。サーバーを起動するとき、コピーした構成ファイルを使用します。
|
注意: または、-Dweblogic.RootDirectory=path起動オプションを使用し、これらのファイルをすでに含むルート・ディレクトリを指定します。 |
コマンド・ラインまたはスクリプトで管理対象サーバーを起動します。
管理対象サーバーは、管理サーバーによって接続されるまでMSIモードで稼働します。このシナリオにおける管理サーバーの詳細は、5.1.3項「障害が発生した管理サーバーの再起動」を参照してください。
本番システムでは、呼出し状態データの取得して書き込むために、エンジン層サーバーが継続的にSIPデータ層のレプリカにアクセスします。Oracle WebLogic Server SIP Containerアーキテクチャは、SIPデータ層サーバーで障害が発生するか、または接続が切断されるときを検出するためにエンジン層ノードに依存します。レプリカが利用できないためエンジンが呼出し状態データにアクセスできないか、または書き込むことができないとき、エンジンは同一パーティション内の別レプリカに接続してオフライン・サーバーに報告します。レプリカは、オフライン・サーバーを考慮するためにSIPデータ層の現在のビューを更新した後、他のエンジンが呼出し状態データにアクセスして取得するときに更新されたビューがエンジンに通知されます。
デフォルトでは、エンジン層サーバーはレプリカへのRMI接続を使用し、レプリカで障害が発生したかどうか、または接続が切断されたどうかを判定します。RMI接続の障害を判定するために使用されるアルゴリズムは信頼できますが、結局は、接続を診断するためにTCPプロトコルの再送信タイマーに依存します(たとえば、レプリカへのネットワーク・ケーブルが切断される場合)。TCP再送信タイマーは通常、丸1分以上継続するため、Oracle WebLogic Server SIP Containerは、数秒で切断されたレプリカを診断できる代替障害検出メソッドを提供します。
WlssEchoServerは、同じサーバー・ハードウェア上でSIPデータ層のレプリカとして実行できる個別のプロセスです。WlssEchoServerの目的は、ネットワーク・ケーブルが切断されたときなどの、SIPデータ層サーバーがオフラインになるときを判定するために使用できるように、エンジン層ノードに単純なUDPエコー・サービスを提供することです。WlssEchoServerを使用した障害検出アルゴリズムは次のとおりです。
すべての標準トラフィックでは、エンジン層サーバーはTCPを使用してSIPデータ層のレプリカと通信します。TCPは、WlssEchoServerが使用されているかどうかに関係なく、エンジン層とSIPデータ層間の基本トランスポートとして使用されます。
エンジン層サーバーは、UDP経由で構成済の各WlssEchoServerに定期的なハートビート・メッセージを送信します。標準操作中、WlssEchoServerは、エンジン・ノードとレプリカ間の接続が検証されるようにハートビートに応答します。
SIPデータ層スタックの完全な障害が発生した場合、またはネットワーク・ケーブルが切断された場合、ハートビート・メッセージがエンジン・ノードに戻されます。この場合、エンジン・ノードは標準TCP接続タイムアウトを待機する必要がなく、レプリカをオフラインとしてマークできます。
オフライン状態にあるサーバーを特定した後、エンジン・ノードは利用可能なSIPデータ層のレプリカに障害を報告し、前の節で説明したようにSIPデータ層のビューが更新されます。
また、SIPデータ層サーバーがローカルのWlssEchoServerプロセスの停止を検出する場合、自動的にシャットダウンします。この動作によって、5.2項「フェイルオーバー検出の概要」で説明されているように、エンジン・ノードが障害を検出して報告するのにかかる時間を短縮するため、より素早いフェイルオーバーが保証されます。
必要に応じてフェイルオーバー検出のパフォーマンスを向上するために、エンジン層サーバー上のハートビート・メカニズムを構成できます。また、SIPデータ層サーバー上でWlssEchoServer が使用するリスニング・ポートおよびログ・ファイルも構成できます。
別のエンジン層サーバーが特定のレプリカで交信することができない場合、エンジンはSIPデータ層でオフライン・サーバーを報告するために、別の利用可能なレプリカにアクセスします。レプリカは、影響を受けるパーティションのビューを更新してオフライン・サーバーを削除します。次に更新されたビューはその後パーティションにアクセスするすべてのエンジン層サーバーに配布されます。このようにビューを伝播することで、エンジン・サーバーのオフライン・レプリカへのアクセスを防止することができます。
また、ビューを更新するレプリカは、シャットダウンを求める1回かぎりのリクエストをオフライン・レプリカに発行します。これは、ネットワーク障害によって1つ以上のエンジン・サーバーによってアクセスできない稼働中のレプリカ・サーバーをシャットダウンしようとするために実行されます。アクティブなレプリカが「オフライン」としてマークされたレプリカに到達できる場合、オフライン・レプリカはシャットダウンされます。
|
注意: WlssEchoServerの使用は、すべてのOracle WebLogic Server SIP Containerインストールで必要ではありません。エコー・サーバーは、システムが構成済のTCPタイムアウト間隔よりも速くネットワーク障害またはレプリカの障害を検出する必要がある場合のみ有効化してください。 |
WlssEchoServerを使用してレプリカの障害を検出するとき、次の要件および制約を順守してください。
障害の検出にハートビート・メカニズムを使用する場合、WlssEchoServerプロセスが各レプリカ・サーバー・マシン上で常に稼働していることを確認する必要があります。WlssEchoServerプロセスに障害が発生するか、または停止される場合、サーバー・プロセスが影響を受けない場合でもレプリカは「オフライン」として処理されます。
WlssEchoServerは、サーバー・マシン上で使用可能なすべてのIPアドレスでリスニングするので注意してください。
WlssEchoServerには、ハートビート・メッセージのリスニング用に専用のポート番号が必要です。
WlssEchoServerとは、シェルまたはコマンド・プロンプトから直接起動できるJavaプログラムです。WlssEchoServerを起動するための基本構文は次のようです。
java -classpath WLSS_HOME/server/lib/wlss/wlssechosvr.jar options com.bea.wcp.util.WlssEchoServer
ここで、WLSS_HOMEはOracle WebLogic Server SIP Containerインストールのパスで、optionsには表5-1で説明されるオプションのいずれかが含まれる場合があります。
表5-1 WlssEchoServerオプション
| オプション | 説明 |
|---|---|
-Dwlss.ha.echoserver.ipaddress |
|
-Dwlss.ha.echoserver.port |
ハートビート・メッセージをリスニングするために使用されるポート番号を指定します。指定するポート番号は、サーバー・マシン上の他のプロセスによって使用されていないことを確認してください。デフォルトでは、 |
-Dwlss.ha.echoserver.logfile |
ログ・ファイルの場所および名前を指定します。デフォルトでは、ログ・メッセージは |
WlssEchoServerを起動するためのコマンドは、それぞれのOracle WebLogic Server SIP ContainerのSIPデータ層インスタンスを起動するために使用するのと同じスクリプトに組み込むことをお薦めします。startManagedWebLogic.shスクリプトをエンジンまたはSIPデータ層サーバー・インスタンスの起動に使用する場合、サーバーの起動に使用される最終コマンドの前にWlssEchoServerを起動するためのコマンドを追加してください。たとえば、次の行を変更します。
"$JAVA_HOME/bin/java" ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} \
-Dweblogic.Name=${SERVER_NAME} \
-Dweblogic.management.username=${WLS_USER} \
-Dweblogic.management.password=${WLS_PW} \
-Dweblogic.management.server=${ADMIN_URL} \
-Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" \
weblogic.Server
読取り対象:
"$JAVA_HOME/bin/java" -classpath WLSS_HOME/server/lib/wlss/wlssechosvr.jar \ -Dwlss.ha.echoserver.ipaddress=192.168.1.4 \ -Dwlss.ha.echoserver.port=6734 com.bea.wcp.util.WlssEchoServer & "$JAVA_HOME/bin/java" ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} \ -Dweblogic.Name=${SERVER_NAME} \ -Dweblogic.management.username=${WLS_USER} \ -Dweblogic.management.password=${WLS_PW} \ -Dweblogic.management.server=${ADMIN_URL} \ -Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" \ weblogic.Server
WlssEchoServerハートビート・メカニズムを有効化するには、-Dreplica.host.monitor.enabledのJVM引数を、すべてのエンジンおよびSIPデータ層サーバーの起動に使用するコマンドに組み込む必要があります。システムにおける管理対象サーバーの起動に使用されるスクリプトに、このオプションを直接追加することをお薦めします。たとえば、startManagedWebLogic.shスクリプトで次の行を変更します。
# JAVA_OPTIONS="-Dweblogic.attribute=value -Djava.attribute=value"
読取り対象:
JAVA_OPTIONS="-Dreplica.host.monitor.enabled=true"
いくつかの追加JVMオプションによって、ハートビート・メカニズムの機能が構成されます。表5-1では、障害検出を構成するために使用されるオプションを説明しています。
表5-2 WlssEchoServerオプション
| オプション | 説明 |
|---|---|
-Dreplica.host.monitor.enabled |
ハートビート・メカニズムを有効にするには、エンジン層サーバーとSIPデータ層サーバーの両方でこのシステム・プロパティを指定する必要があります。 |
-Dwlss.ha.heartbeat.interval |
ハートビート・メッセージの間隔をミリ秒単位で指定します。デフォルトでは、ハートビート・メッセージは1,000ミリ秒ごとに送信されます。 |
-Dwlss.ha.heartbeat.count |
レプリカがオフラインと判定される前に、ハートビートが連続して何回失敗できるかを指定します。デフォルトでは、サーバー上の |
-Dwlss.ha.heartbeat.SoTimeout |
UDPソケットのタイムアウト値を指定します。 |
Oracle WebLogic Server SIP Containerには、エンジン層およびSIPデータ層サーバー・インスタンス上のアクティビティを監視するための専用のSNMP MIBが含まれます。Oracle WebLogic Server SIP Container MIBは、ドメインの管理対象サーバーおよび管理サーバーの両方で使用できます。ただし、Oracle WebLogic Server SIP ContainerエンジンおよびSIPデータ層のトラップは、各層を構成する管理対象サーバー・インスタンスによってのみ生成されます。管理サーバーがsipserverカスタム・リソースのターゲットではない場合、WebLogic Server SNMPトラップのみ生成します(たとえば、クラスタ内のサーバーで障害が発生したとき)。管理者は、ドメイン全体の動作を評価するために、WebLogic ServerおよびOracle WebLogic Server SIP Containerのトラップの両方を監視する必要があります。
|
注意: Oracle WebLogic Server SIP Container MIBオブジェクトは読取り専用です。SNMPを使用してOracle WebLogic Server SIP Container構成を変更することはできません。 |
Oracle WebLogic Server SIP Container MIBファイルは、WLSS_HOME/server/lib/wlss/BEA-WLSS-MIB.asn1にインストールされます。使用可能なSNMP管理ツールまたはMIBブラウザを使用すると、このファイルのコンテンツを表示できます。共通SNMPトラップの詳細は、5.5.2項「トラップの説明」を参照してください。
Oracle WebLogic Server SIP Containerドメイン全体のSNMP監視を有効化するには、次の手順に従ってください。
Oracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。
左ペインで、「診断」>「SNMP」ノードを選択します。
Server SNMPエージェントの表で「新規」ボタンをクリックし、新規エージェントを作成します。
|
注意: Domain-Scopedエージェントではなく新しいServer SNMPエージェントを作成することを確認します。 |
新規SNMPエージェントの一意の名前(たとえば「engine1snmp」)を入力し、「OK」をクリックします。
Server SNMPエージェント表から、作成した新しいSNMPエージェントを選択します。
「構成」>「全般」タブで
「有効化」チェック・ボックスを選択し、エージェントを有効にします。
SNMP UDPポート・フィールドで非使用のポート番号を入力します。
|
注意: 複数の管理対象サーバー・インスタンスを同じマシンで実行する場合、各サーバー・インスタンスは一意のSNMPポート番号で専用SNMPエージェントを使用する必要があります。 |
「保存」をクリックします。
デプロイメント内の各サーバー(SIPデータ層サーバー、エンジン層サーバーおよび管理サーバー)に対して一意のSNMPエージェントを生成するには、上記の手順を繰り返します。
次の項では、Oracle WebLogic Server SIP Container SNMPトラップの詳細を説明します。各トラップへの応答に関するリカバリ手順も適宜含まれます。
次のOracle WebLogic Server SIP Containerログおよび構成ファイルは、問題のトラブルシューティングに役立つことが多く、技術サポートの連絡に必要になる場合があります。
$DOMAIN_DIR/config/config.xml
$DOMAIN_DIR/config/custom/sipserver.xml
$DOMAIN_DIR/servername/*.log (server and message logs)
sip.xml (アプリケーションの/WEB-INFサブディレクトリ内)
web.xml (アプリケーションの/WEB-INFサブディレクトリ内)
テクニカル・サポート・チームが問題を解決する上で、次のような一般情報が役立つことがあります。
以下のソフトウェアの具体的なバージョン番号
Oracle WebLogic Server SIP Container
Java SDK
オペレーティング・システム
停止Oracle WebLogic Server SIP Containerプロセスのスレッド・ダンプ
ネットワーク・アナライザ・ログ
表5-3は、Oracle WebLogic Server SIP Container SNMPトラップを一覧表示し、エンジン層またはSIPデータ層のサーバーによってトラップが生成されるかどうかを示します。各トラップは次の項で説明します。
表5-3 Oracle WebLogic Server SIP Container SNMPトラップ
| トラップが生成されるサーバー・ノード | トラップ名 |
|---|---|
|
エンジン層サーバー |
5.5.2.1項「connectionLostToPeer」 |
|
5.5.2.2項「connectionReestablishedToPeer」 |
|
|
5.5.2.4項「overloadControlActivated、overloadControlDeactivated」 |
|
|
|
|
|
|
|
|
5.5.2.11項「sipAppFailedToDeploy」 |
|
|
エンジン層サーバーとSIPデータ層サーバー(サーバーがクラスタのメンバーである場合) |
|
|
SIPデータ層サーバー |
5.5.2.3項「dataTierServerStopped」 |
|
5.5.2.5項「replicaAddedToPartition」 |
|
|
5.5.2.6項「replicaRemovedEnginesRegistration」 |
|
|
5.5.2.7項「replicaRemovedFromPartition」 |
エンジン層のサーバー・インスタンスがSIPデータ層のレプリカに接続できなくなった場合は、そのエンジン層サーバーでこのトラップが生成されます。エンジン層とSIPデータ層の間でネットワーク接続の問題が起きている可能性があります。また、SIPデータ層のサーバーで障害が発生している場合は、このトラップとともに追加のトラップが生成されることがあります。
このトラップは、前の障害の後(connectionLostToPeerトラップが生成された後)にSIPデータ層サーバーに正常に再接続される場合、エンジン層サーバー・インスタンスによって生成されます。このトラップの繰り返されたインスタンスは、エンジンおよびSIPデータ層の間の断続的ネットワーク障害を示す場合があります。
Oracle WebLogic Server SIP ContainerのSIPデータ層ノードは、SIPデータ層の一部であるWebLogic Serverインスタンスでリカバリ不能なエラーが発生したときに、このアラームを生成します。このトラップは、シャットダウン中のサーバー、同一パーティション内の別のレプリカ、または場合によっては両方のサーバーによって生成されることがあるので注意してください(ネットワーク停止によって両サーバーが同一のトラップを生成することがあります)。
Oracle WebLogic Server SIP Containerエンジン層ノードは、構成可能なスロットル・メカニズムを使用し、これは処理対象の新規SIPリクエストの数を管理するのに役立ちます。構成されたオーバーロード条件が監視された後、Oracle WebLogic Server SIP Containerは、「503 Service Unavailable」を呼出し元に応答することによって、新規SIPリクエストを破棄します。サーバーは、構成されたしきい値制御値に従ってオーバーロード条件が解決されるまで、新規リクエストを破棄し続けます。このアラームは、スロットル・メカニズムがアクティブ化されると生成されます。スロットル動作は最終的に、サーバーをオーバーロードではない状態に戻すので、それ以上の操作は必要ありません。
Oracle WebLogic Server SIP ContainerのSIPデータ層ノードは、サーバー・インスタンスがSIPデータ層のパーティションに追加されるときに、このアラームを生成します。
SIPデータ層ノードは、登録されていなかった(または登録済エンジンのリストから削除された)エンジン・サーバー・クライアントがSIPデータ層と通信しようとすると、このアラームを生成します。このトラップの生成後、SIPデータ層の一貫性を保つためにエンジン層サーバーがシャットダウンされたことを示すserverStoppedトラップが生成されます。
Oracle WebLogic Server SIP ContainerのSIPデータ層ノードは、正常に停止された操作または障害によるシャットダウンのいずれかによって、サーバーがSIPデータ層から削除されるときに、このアラームを生成します。このトラップを生成するには、パーティション内に少なくとも1つのレプリカが残っている必要があります。パーティション内にレプリカが1つしかなく、そのレプリカに障害が発生した場合、このトラップは生成できません。また、エンジン層ノードはレプリカに障害が発生したときを判定するため、エンジン層ノードはこのトラップが生成されるために稼働している必要があります。
このトラップは、WebLogic Serverインスタンスが現在ダウンしていることを示します。このトラップはエンジン層とSIPデータ層の両方のサーバー・インスタンスに適用されますが、それは、サーバーが名前付きのWebLogic Serverクラスタのメンバーである場合に限られます。このトラップが、制御された停止によって発生したのではなく、自然に生成された場合は、次の手順に従います。
次のリカバリ手順を実行します。
次のコマンドを使用して、ハングしているプロセスを特定します。
ps –ef | grep java
マシンで実行中のWebLogic Serverインスタンスごとに、対応するPIDが1つだけあるはずです。
影響を受けているPIDを特定したら、次のコマンドを使ってプロセスを強制停止します。
kill -3 [pid]
このコマンドを実行すると、実際のスレッド・ダンプが生成されます。プロセスが直ちに停止しない場合は、潜在的なデッドロックの問題の診断に役立つように、プロセスが停止するまで5 - 10秒間隔でコマンドを何度か繰り返します。
Oracle WebLogic Server SIP Containerを速やかに再起動しようとします。
トラブルシューティングに役立つように、影響を受けたサーバーのすべてのSIPログのバックアップ・コピーを作成します。ログの場所は、サーバーの構成によって異なります。
Tier 4サポートが問題を解決する際に役立つように、各ログをコピーします。
|
注意: Oracle WebLogic Server SIP Containerログは、システム構成に従って切り捨てられます。クリティカルなトラブルシューティング情報の損失を避けるには、速やかにバックアップ・ログを作成します。 |
Tier 4サポートに連絡し、トラブル・チケットにログ・ファイルを含めます。
その後24時間にわたり、サーバーを注意深くモニターします。ログ・ファイルで問題の原因を特定できない場合は、ハードウェアやネットワークに問題があり、それが時間をおいて再発することがあります。
Oracle WebLogic Server SIP Containerのエンジン層ノードは、SIPサーブレットがコンテナにデプロイされるときに、このアラームを生成します。
Oracle WebLogic Server SIP Containerのエンジン層ノードは、SIPアプリケーションがシャットダウンするときか、またはSIPアプリケーションがデプロイ解除される場合に、このアラームを生成します。これは通常、アクティブなリクエストが存在している間にOracle WebLogic Server SIP Containerがシャットダウンされるときに発生します。
Oracle WebLogic Server SIP Containerのエンジン層ノードは、アプリケーションがWebアプリケーションとして正常にデプロイされても、SIPアプリケーションとしてデプロイするのには失敗するときに、このトラップを生成します。
WebLogic診断フレームワーク(WLDF)は、WebLogic Serverインスタンスとそのアプリケーションに関する診断情報の収集、アーカイブ化、およびアクセスを行うために機能する多数のコンポーネントから構成されます。Oracle WebLogic Server SIP Containerバージョンは、エンジン層ノード/SIPデータ層ノードおよびデプロイ済SIPサーブレットの操作を監視および診断するためのWLDFコンポーネントのいくつかを統合しています。
データ・コレクタ: Oracle WebLogic Server SIP Containerは、ランタイムMBeanから上表を収集するためにハーベスタ・サービスと統合しており、SIPリクエストおよびレスポンスをアーカイブ化するためにロガー・サービスと統合しています。
監視と通知: 管理者は、Oracle WebLogic Server SIP ContainerランタイムMBean属性に基づいて、複雑なルールを作成するために「監視と通知」コンポーネントを使用できます。このルールは、JMS、JMX、SNMP、SMTPなどを使用して自動通知のトリガーとなります。
イメージのキャプチャ: Oracle WebLogic Server SIP Containerインスタンスは、特定の診断データを収集し、管理者によってリクエストされた場合そのデータをイメージ・ファイルに書き込むことができます。このデータはその後、稼働中のサーバーにおける問題の診断に使用されます。
インストゥルメンテーション: Oracle WebLogic Server SIP Containerは、サーバーおよびアプリケーション・コードをモニターに備え付けます。これは、特定の基準に一致するSIPメッセージ(リクエストおよびレスポンス)上で実行される診断アクションを構成するのに役立ちます。
次の項では、Oracle WebLogic Server SIP Containerが、前述の各WLDFコンポーネントを統合する方法に関する詳細を説明します。
Oracle WebLogic Server SIP Containerは、WLDFハーベスタ・サービスを使用し、次のランタイムMBeanの属性からデータを収集します。
ReplicaRuntimeMBean
SipApplicationRuntimeMBean
SipServerRuntimeMBean
WLDFコンソール拡張を使用して、このデータのチャートやグラフを独自のカスタム・ビューに追加できます。これを行うためには、JARファイルをドメイン・ディレクトリのconsole-extサブディレクトリにコピーすることにより、最初にWLDFコンソール拡張を有効化します。
cp ~/bea/wlserver_10.3/server/lib/console-ext/diagnostics-console-extension.jar ~/bea/user_projects/domains/mydomain/console-ext
WLDFコンソール拡張にアクセスするとき、Oracle WebLogic Server SIP ContainerのランタイムMBean属性は、拡張の「メトリック」タブで使用できます。
また、Oracle WebLogic Server SIP Containerは、WLDFロガー・サービスも使用し、SIPおよびDiameterメッセージを独立した専用ログ・ファイル(デフォルトでは、domain_home/logs/server_name/sipMessages.log)にアーカイブ化します。SIPサーバー管理コンソール拡張の「構成」>「メッセージのデバッグ」タブを使用して、ログ・ファイルの名前と場所、およびログ・ローテーション・ポリシーを構成できます。独立したロギングおよびログ・ローテーションを初期化するためには、サーバーを再起動する必要があります。
Oracle WebLogic Server SIP ContainerのランタイムMBeanから収集されたデータは、自動監視またはサーバーの診断状態を観察する「監視」を作成するために使用できます。その後、構成した監視条件およびルールが発生するときにSMTP、SNMP、JMX、またはJMSを使用してメッセージを生成するために、1つ以上の通知が監視によって使用されるように構成できます。
監視と通知を使用するためには、管理コンソールの左ペインで「診断」>「診断モジュール」ノードを選択し、監視ルールとサーバー監視に必要な通知を使用して新しいモジュールを作成します。監視ルールは、Oracle WebLogic Server SIP ContainerランタイムMBeanから収集されたメトリック、ログ・ファイルに書き込まれたメッセージ、または診断フレームワークによって生成されたイベントを使用できます。
Oracle WebLogic Server SIP Containerは、独自のイメージ・キャプチャ情報をWLDFによって生成された診断イメージに追加します。必要に応じて、または監視ルールを構成することによって自動的に診断イメージを作成できます。
診断イメージに含まれている情報については、Oracleのテクニカル・サポート担当者がサーバーの問題のトラブルシューティングに使用することを意図しています。これには以下の情報が含まれます。
SIPデータ層のパーティションおよびレプリカの構成
呼出し状態およびタイマー統計
ワーク・マネージャ統計
WLDFインストゥルメンテーション・システムは、診断監視を作成し、それをOracle WebLogic Server SIP Containerまたはアプリケーション・コードの実行フローにおける特定のポイントに挿入します。Oracle WebLogic Server SIP Containerは、組込みのDyeInjection監視を提供するためにインストゥルメンテーション・サービスに統合します。有効にすると、特定のSIPメッセージがシステムに入力またはシステムから出力された場合、このモニターは仕分けフラグを診断コンテキストに注入します。仕分けフラグは、監視の構成プロパティおよび特定のリクエスト属性に基づいて組み込まれます。
Oracle WebLogic Server SIP Containerは、次の表5-4で説明されている仕分けフラグ、およびWebLogic Server仕分けフラグのUSER/ADDRを追加します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方』を参照してください。
表5-4 Oracle WebLogic Server SIP Container DyeInjectionフラグ
| 仕分けフラグ | 説明 |
|---|---|
|
PROTOCOL_SIP |
すべてのSIPプロトコル・メッセージの診断コンテキストに設定されます。 |
|
SIP_REQ |
プロパティSIP_REQの値に一致するすべてのSIPリクエストの診断コンテキストに設定されます。 |
|
SIP_RES |
SIPレスポンスがプロパティSIP_RESの値に一致する場合に設定されます。 |
|
SIP_REQURI |
SIPリクエストのreqURIがプロパティSIP_REQURIの値に一致する場合に設定されます。 |
|
SIP_ANY_HEADER |
SIPリクエストが、プロパティSIP_ANY_HEADERの値に一致するヘッダーを含む場合に設定されます。 |
|
SIP_RES |
このフラグは、プロパティSIP_RESの値に一致するすべてのSIPレスポンス用診断コンテキストに設定されます。 |
|
SIP_REQURI |
このフラグは、SIPリクエストのリクエストURIがプロパティSIP_REQURIの値に一致する場合に設定されます。 |
|
SIP_ANY_HEADER |
このフラグは、SIPリクエストがプロパティSIP_ANY_HEADERの値に一致するヘッダーを含む場合に設定されます。SIP_ANY_HEADERの値は、 |
仕分けフラグは、受信および送信SIPメッセージの両方に適用できます。フラグは仕分けのフィルタ処理に役立ち、委任監視によって以降の診断アクションをトリガーするために使用できます。
Oracle WebLogic Server SIP Containerは、アプリケーションおよびサーバー・スコープに適用可能な委任監視をいくつか提供し、DyeInjection監視によって設定される仕分けフラグを確認できます。委任監視は表5-4で説明されています。
表5-5 Oracle WebLogic Server SIP Container診断監視
| 監視名 | 監視タイプ | スコープ | ポイントカット |
|---|---|---|---|
|
occas/Sip_Servlet_Before_Service |
前 |
アプリケーション |
すべての実装サブクラスの |
|
occas/Sip_Servlet_After_Service |
後 |
アプリケーション |
すべての実装サブクラスの |
|
occas/Sip_Servlet_Around_Service |
前後 |
アプリケーション |
すべての実装サブクラスの |
|
occas/Sip_Servlet_Before_Session |
前 |
アプリケーション |
|
|
occas/Sip_Servlet_After_Session |
後 |
アプリケーション |
|
|
occas/Sip_Servlet_Around_Session |
前後 |
アプリケーション |
|
|
occas/SipSessionDebug |
前後 |
アプリケーション |
固定のポイントカットおよび固定のデバッグ・アクションを持つ、組込みのアプリケーション・スコープのモニターです。ポイントカットの前後で、監視は モニターのポイントカットは次のとおりです。
注意: 注意: Apache Antを使用してアプリケーションをコンパイルする場合、必要なデバッグ情報を生成されたクラス・ファイルに組み込むために |
|
occas/Sip_Servlet_Before_Message_Send_Internal |
前 |
サーバー |
メッセージをワイヤに書き込むOracle WebLogic Server SIP Containerコードの入力時。 |
|
occas/Sip_Servlet_After_Message_Send_Internal |
後 |
サーバー |
メッセージをワイヤに書き込むOracle WebLogic Server SIP Containerコードの終了時。 |
|
occas/Sip_Servlet_Around_Message_Send_Internal |
前後 |
サーバー |
メッセージをワイヤに書き込むOracle WebLogic Server SIP Containerコードの入力時および終了時。 |
サーバー・スコープ・モニターを使用するためには、新しい診断モジュールを作成し、モジュール内に1つ以上の監視を構成する必要があります。組込みのDyeInjection監視では、固有の仕分けフラグを定義するために監視プロパティを追加します。occas/Sip_Servlet_Before_Message_Send_Internalなどの委任監視では、診断アクションを定義するために監視プロパティを追加します。
Oracle WebLogic Server SIP Container DyeInjection監視および委任監視を構成し、仕分けフィルタ処理を有効化するには、次の手順を実行します。
ドメインの管理コンソールにアクセスします。
コンソールの左ペインで「診断」>「診断モジュール」ノードを選択します。
「新規」をクリックして新規診断モジュールを作成します。モジュールに「instrumentationModule」などの説明的な名前を付け、「OK」をクリックします。
表のモジュール・リストから新規の「instrumentationModule」を選択します。
「ターゲット」タブを選択します。
このモジュールをターゲットとするサーバーを選択して、「保存」をクリックします。
「診断」>「診断モジュール」ノードに戻り、モジュールのリストからinstrumentationModuleを選択します。
「構成」>「インストゥルメンテーション」タブを選択します。
「有効化」を選択し、サーバー・レベルでのインストゥルメンテーションを有効にして、「保存」をクリックします。
モジュールにDyeInjectionモニターを追加するには、以下の手順に従います。
「追加と削除」をクリックします。
利用可能なリストからモニターの名(たとえば、DyeInjection)を選択し、矢印を使って選択したリストに移動します。
「OK」をクリックします。
利用可能なモニターのリストから新たに作成したモニターを選択します。
モニターが有効になっていることを確認し、「プロパティ」フィールドを編集して必要なプロパティを追加します。DyeInjectionモニターのサンプル・プロパティには、以下が含まれています。
SIP_RES=180 SIP_REQ=INVITE SIP_ANY_HEADER=request.Contact=sip:sipp@localhost:5061
「保存」をクリックします。
モジュールに1つまたは複数の委任モニターを追加するには、次の手順に従います。
新規モジュールの「構成」>「インストゥルメンテーション」タブに戻ります。
「追加と削除」をクリックします。
「使用可能」リスト(occas/Sip_Servlet_Before_Message_Send_Internalなど)から委任監視の名前を選択し、矢印を使用して「選択済み」リストに移動します。
「OK」をクリックします。
利用可能なモニターのリストから新たに作成したモニターを選択します。
モニターが有効化されていることを確認し、使用可能なリストから1つ以上のアクションを選択してから、矢印を使用してアクションを「選択済み」リストに移動します。occas/Sip_Servlet_Before_Message_Send_Internalモニターでは、サンプル・アクションにはDisplayArgumentsAction、StackDumpAction、ThreadDumpAction、およびTraceActionが含まれます。
「EnableDyeFiltering」の横にあるチェック・ボックスを選択します。
利用可能なリストからSIP_REQのような1つまたは複数の仕分けマスクを選択し、矢印を使って選択したリストに移動します。
「保存」をクリックします。
|
注意: 委任モニターを追加して作成するには、上記の手順を繰り返します。 |
weblogic-diagnostics.xmlという名前のXML構成ファイルでアプリケーション・スコープ・モニターを構成します。SIPモジュールまたはエンタープライズ・アプリケーションのMETA-INFディレクトリにweblogic-diagnostics.xmlファイルを保存する必要があります。
XMLファイルはアプリケーション・レベルでインストゥルメンテーションを有効化し、ポイントカットを定義し、また、委任監視の仕分けマスクおよびアクションを定義します。例5-1は、occas/Sip_Servlet_Before_Serviceモニターを使用するサンプル構成ファイルを示します。
例5-1 サンプルweblogic-diagnostics.xmlファイル
<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics">
<instrumentation>
<enabled>true</enabled>
<include>demo.ProxyServlet</include>
<wldf-instrumentation-monitor>
<name>occas/Sip_Servlet_Before_Service</name>
<enabled>true</enabled>
<dye-mask>SIP_ANY_HEADER</dye-mask>
<dye-filtering-enabled>true</dye-filtering-enabled>
<action>DisplayArgumentsAction</action>
</wldf-instrumentation-monitor>
</instrumentation>
</wldf-resource>
この例では、受信リクエストの診断コンテキストがSIP_ANY_HEADER仕分けフラグを含む場合、occas/Sip_Servlet_Before_Serviceモニターがトリガーされ、DisplayArgumentsActionが実行されます。
Oracle WebLogic Server SIP Containerによって、処理対象のSIPリクエストおよびレスポンスのプロトコル・データ・ユニット(PDU)ロギングを実行することができます。ログ対象のSIPメッセージは、Oracle WebLogic Server SIP Containerのドメイン全体ログ・ファイル、または各管理対象サーバー・インスタンスのログ・ファイルのいずれかに配置されます。SIPメッセージはOracle WebLogic Server SIP Containerインスタンスと同一のログ・ファイルを共有するため、ログ対象SIPメッセージを管理するときに、ログ・ローテーション、ドメイン・ログ・フィルタ処理、最大ログ・サイズ構成などの高度なサーバー・ロギング機能を使用できます。
管理者は、com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImplクラスを使用して1つ以上のSIPサーブレットを定義することによって、SIP PDUロギングを構成します。ロギング基準は、定義されたサーブレットへのパラメータとしてか、またはアプリケーションでパッケージ化された個別のXMLファイルのいずれかで構成されます。
SIPリクエストが処理されるか、SIPレスポンスが生成される際に、ロギング・サーブレットはスタンドアロンのXML構成ファイルまたはサーブレットのパラメータで定義されたフィルタ処理のパターンをメッセージと照合します。指定されたパターンと一致するSIPリクエストとレスポンスは、ロギング・サーブレットの名前、構成されているロギング・レベル、その他の詳細とともにログ・ファイルに書き込まれます。無駄なパターン・マッチングを避けるために、サーブレットは最初のパターンが一致すると新しいSIPセッションにマークして、そのセッションのそれ以降のリクエストとレスポンスを自動的にログに記録します。
ロギング基準は、ロギング・サーブレットへのパラメータとしてsip.xmlまたは外部XML構成ファイルのいずれかのディレクトリで定義されます。詳細は、5.7.3項「ロギング・メッセージの基準の指定」を参照してください。
|
注意: エンジニアは、サーブレットのinit()メソッドでTraceMessageListenerFactoryを使用して委任を作成するか、またはデプロイされたJavaアプリケーションでトレース・クラスを使用するかのいずれかによって、サーブレットでPDUロギング機能を実装できます。委任を使用すると、デフォルトのトレース・メッセージ・リスナー実装を使用してカスタム・ロギングまたは受信SIPメッセージの操作を実行できます。サーブレットのinit()メソッドでファクトリを使用する例については、5.7.7項「トレース機能のSIPサーブレット・コードへの追加」を参照してください。 |
SIPメッセージのロギング・サーブレットは、実装クラスcom.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImplを持つサーブレットを定義することによって作成されます。サンプルmsgTraceLoggerの定義は、例5-2で示されます。
例5-2 サンプル・ロギング・サーブレット
<servlet>
<servlet-name>msgTraceLogger</servlet-name>
<servlet-class>com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl</servlet-class>
<init-param>
<param-name>domain</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>level</param-name>
<param-value>full</param-value>
</init-param>
<load-on-startup/>
</servlet>
ロギング詳細のレベルやSIPメッセージの宛先ログ・ファイルなどのロギング属性は、ロギング・サーブレットへの初期化パラメータとして渡されます。表5-5は、init-paramエントリとして指定できるパラメータおよびパラメータ値を一覧を表示します。例5-2は、SIPメッセージ情報をドメインログ・ファイルに記録するサーブレットのサンプルinit-paramエントリを示します。
SIPメッセージをロギングするための基準は、ロギング・サーブレットのアプリケーションにパッケージされるXMLファイル、またはサーブレットのsip.xmlデプロイメント記述子で初期化パラメータとして定義できます。次の項では、各メソッドを説明します。
ロギング基準をロギング・サーブレットへの初期化パラメータとして指定しない場合、サーブレットはロギング・アプリケーションの最上位にあるXML記述子ファイルのペアでロギング基準を検索します。これらの記述子ファイルは、request-pattern.xmlおよびresponse-pattern.xmlという名前で、Oracle WebLogic Server SIP Containerがログ・ファイルに配置するためのSIPリクエストおよびレスポンスを選択するために使用するパターンを定義します。
|
注意: デフォルトでは、Oracle WebLogic Server SIP Containerはリクエストおよびレスポンスの両方をロギングします。レスポンスはロギングしない場合、response-pattern.xmlファイルを空の照合基準で定義する必要があります。 |
通常のパターン定義は、SIPメッセージ・ヘッダーにおける特定の値に一致する条件を定義します。たとえば、msgTraceLoggerサーブレットで使用されるサンプルresponse-pattern.xmlは、すべてのMESSAGEリクエストに一致します。この記述子のコンテンツは次で示されます。
例5-3 msgTraceLoggerサーブレットのサンプルresponse-pattern.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pattern
PUBLIC "Registration//Organization//Type Label//Definition Language"
"trace-pattern.dtd">
<pattern>
<equal>
<var>response.method</var>
<value>MESSAGE</value>
</equal>
</pattern>
SIPメッセージ照合の追加演算子および条件は、5.7.6項「trace-pattern.dtdリファレンス」で説明されています。例5-3で説明されているequal条件などの大半の条件には、評価対象のSIPメッセージの部分を識別する変数(var要素)が必要です。表5-5では、共通変数およびサンプル値の一部を一覧を表示しています。追加の変数名および例については、SIPサーブレットAPI 1.1仕様書(http://jcp.org/en/jsr/detail?id=289)の16項「リクエストのサーブレットへのマッピング」を参照してください。Oracle WebLogic Server SIP Containerによって、リクエストおよびレスポンスの変数をロギング・サーブレットにマップできるようになります。
表5-6 パターン・マッチングの変数と値の例
| 変数 | サンプル値 |
|---|---|
|
request.method、response.method |
MESSAGE、INVITE、ACK、BYE、CANCEL |
|
request.uri.user、response.uri.user |
guest、admin、joe |
|
request.to.host、response.to.host |
server.mydomain.com |
request-pattern.xmlおよびresponse-pattern.xmlの両方が同一のDocument Type Definition (DTD)を使用します。詳細は、5.7.6項「trace-pattern.dtdリファレンス」を参照してください。
パターン照合基準は、個別のXMLドキュメントとしてではなく、ロギング・サーブレットへの初期化パラメータとしても指定できます。照合基準の指定に使用されるパラメータ名は、request-pattern-stringおよびresponse-pattern-stringです。これらは、5.7.2項「ロギング・レベルおよび宛先の構成」で説明されているように、ロギング・レベルおよび宛先に従って定義されます。
各パターン照合パラメータの値は、スタンドアロン・パターン定義ドキュメントのDTDに準拠している有効なXMLドキュメントから構成される必要があります(5.7.3.1項「ロギング基準を指定するためのXMLドキュメントの使用」を参照)。パターンや値を定義するXMLドキュメントは、sip.xml記述子の部分として解析されてはならないので、CDATAタグ内にコンテンツを囲い込む必要があります。例5-4では、サンプル・ロギング・サーブレットであるinvTraceLoggerのフルsip.xmlエントリを示しています。最後の2つのinit-param要素は、サーブレットがINVITEリクエスト・メソッドおよびOPTIONSレスポンス・メソッドのみをロギングすることを指定します。
例5-4 init-param要素として指定されたロギング基準
<servlet>
<servlet-name>invTraceLogger</servlet-name>
<servlet-class>com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl</servlet-class>
<init-param>
<param-name>domain</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>level</param-name>
<param-value>full</param-value>
</init-param>
<init-param>
<param-name>request-pattern-string</param-name>
<param-value>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pattern
PUBLIC "Registration//Organization//Type Label//Definition Language"
"trace-pattern.dtd">
<pattern>
<equal>
<var>request.method</var>
<value>INVITE</value>
</equal>
</pattern>
]]>
</param-value>
</init-param>
<init-param>
<param-name>response-pattern-string</param-name>
<param-value>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pattern
PUBLIC "Registration//Organization//Type Label//Definition Language"
"trace-pattern.dtd">
<pattern>
<equal>
<var>response.method</var>
<value>OPTIONS</value>
</equal>
</pattern>
]]>
</param-value>
</init-param>
<load-on-startup/>
</servlet>
デフォルトでは、Oracle WebLogic Server SIP Containerは文字列フォーマット(UTF-8エンコーディング)を使用して、テキストまたはapplication/sdp Content-Type値を持つSIPメッセージのコンテンツをロギングします。他のすべてのContent-Type値では、Oracle WebLogic Server SIP Containerは、指定されている場合にメッセージのcharsetパラメータで指定される文字セットを使用して、メッセージ・コンテンツをロギングする試行を行います。charsetパラメータが指定されていない場合、あるいはcharset値が無効またはサポートされていない場合、Oracle WebLogic Server SIP ContainerはBase-64エンコーディングを使用して、メッセージをロギングする前にメッセージ・コンテンツを暗号化します。
このような状況でメッセージのコンテンツを暗号化しない場合、sipserver.xmlでstring-rep要素を使用して、文字列が表示可能なContent-Type値のリストを指定してください。string-rep要素には、照合対象の1つ以上のcontent-type要素が含まれる可能性があります。ロギングされたメッセージが、構成されたcontent-type要素のいずれかに一致する場合、Oracle WebLogic Server SIP Containerは、charsetパラメータが含まれるかどうかに関係なく、UTF-8エンコーディングを使用して文字列フォーマットでコンテンツをロギングします。
|
注意: text/*またはapplication/sdpのコンテンツ・タイプはデフォルトとして文字列フォーマットにログされているため、指定する必要はありません。 |
例5-5では、text/* and application/sdpコンテンツに加えて、3つの追加Content-Type値の文字列コンテンツをロギングするサンプルmessage-debug構成を示しています。
Oracle WebLogic Server SIP Containerのロギング・インフラストラクチャによって、既存のログ・ファイルが指定されたサイズに到達したときに、新しいログ・ファイルに自動的に書き込むことができるようになります。管理コンソールを使用してログ・コンテンツを表示するか、ログに書き込まれる追加サーバー・レベル・イベントを構成できます。
trace-pattern.dtdは、request-pattern.xmlおよびresponse-pattern.xmlの必須コンテンツ、ドキュメント、request-pattern-stringおよびresponse-pattern-stringサーブレットのinit-param変数の値を定義します。
例5-6 trace-pattern.dtd
<!--
The different types of conditions supported.
- >
<!ENTITY % condition "and | or | not |
equal | contains | exists | subdomain-of">
<!--
A pattern is a condition: a predicate over the set of SIP requests.
- >
<!ELEMENT pattern (%condition;)>
<!--
An "and" condition is true if and only if all its constituent conditions
are true.
- >
<!ELEMENT and (%condition;)+>
<!--
An "or" condition is true if at least one of its constituent conditions
is true.
- >
<!ELEMENT or (%condition;)+>
<!--
Negates the value of the contained condition.
- >
<!ELEMENT not (%condition;)>
<!--
True if the value of the variable equals the specified literal value.
- >
<!ELEMENT equal (var, value)>
<!--
True if the value of the variable contains the specified literal value.
- >
<!ELEMENT contains (var, value)>
<!--
True if the specified variable exists.
- >
<!ELEMENT exists (var)>
<!--
- >
<!ELEMENT subdomain-of (var, value)>
<!--
Specifies a variable. Example:
<var>request.uri.user</var>
- >
<!ELEMENT var (#PCDATA)>
<!--
Specifies a literal string value that is used to specify rules.
- >
<!ELEMENT value (#PCDATA)>
<!--
Specifies whether the "equal" test is case sensitive or not.
- >
<!ATTLIST equal ignore-case (true|false) "false">
<!--
Specifies whether the "contains" test is case sensitive or not.
- >
<!ATTLIST contains ignore-case (true|false) "false">
<!--
The ID mechanism is to allow tools to easily make tool-specific
references to the elements of the deployment descriptor. This allows
tools that produce additional deployment information (i.e information
beyond the standard deployment descriptor information) to store the
non-standard information in a separate file, and easily refer from
these tools-specific files to the information in the standard sip-app
deployment descriptor.
- >
<!ATTLIST pattern id ID #IMPLIED>
<!ATTLIST and id ID #IMPLIED>
<!ATTLIST or id ID #IMPLIED>
<!ATTLIST not id ID #IMPLIED>
<!ATTLIST equal id ID #IMPLIED>
<!ATTLIST contains id ID #IMPLIED>
<!ATTLIST exists id ID #IMPLIED>
<!ATTLIST subdomain-of id ID #IMPLIED>
<!ATTLIST var id ID #IMPLIED>
<!ATTLIST value id ID #IMPLIED>
トレース機能は、TraceMessageListenerFactoryを使用して、独自のサーブレットまたはJavaコードに追加できます。TraceMessageListenerFactoryは、インスタンスを作成してそれに委譲することによって、クライアントがデフォルトのトレース・メッセージ・リスナー実装の動作を再利用できるようにします。ファクトリ実装インスタンスは、TraceMessageListenerFactory.TRACE_MESSAGE_LISTENER_FACTORY属性の値を検出することによって、SIPサーブレットのサーブレット・コンテンツで検索できます。
|
注意: ファクトリによって作成されたインスタンスは、SIPメッセージの受信および送信時にコールバックを受信するために、Oracle WebLogic Server SIP Containerに登録されません。 |
サーブレット内のトレースを実装するためには、ファクトリ・クラスを使用し、例5-7で示されているように、サーブレットのinit()メソッドで委任を作成します。
例5-7 TraceMessageListenerFactoryの使用
public final class TraceMessageListenerImpl extends SipServlet implements MessageListener {
private MessageListener delegate;
public void init() throws ServletException {
ServletContext sc = (ServletContext) getServletContext();
TraceMessageListenerFactory factory = (TraceMessageListenerFactory) sc.getAttribute(TraceMessageListenerFactory.TRACE_MESSAGE_LISTENER_FACTORY);
delegate = factory.createTraceMessageListener(getServletConfig());
}
public final void onRequest(SipServletRequest req, boolean incoming) {
delegate.onRequest(req,incoming);
}
public final void onResponse(SipServletResponse resp, boolean incoming) {
delegate.onResponse(resp,incoming);
}
}
リスナーとロギング・サーブレットが両方ともデプロイされている場合は、最初にリスナー・クラスがロードされ、その後でサーブレットがロードされます。各ロギング・サーブレットがデプロイされる順序は、Webアプリケーションのデプロイメント記述子で指定されているロード順序に従います。
Oracle WebLogic Server SIP Containerの本番インストールは通常、サーバー・ロードのピークときでさえも、いつもクライアントに極端に短いレスポンス時間(50ミリ秒未満)を要求します。短いレスポンス時間を維持するキー・ファクタは、エンジン層におけるOracle WebLogic Server SIP ContainerインスタンスのJVMガベージ・コレクション(GC)アルゴリズムを適切に選択してチューニングすることです。
一部のチューニング方式はガベージ・コレクションの平均時間を最短にすることや完全なガベージ・コレクションの実行頻度を最小に抑えることを目的として設計されていますが、これらの方式では、長短のGC間隔を組み合せて総合的にGCの影響を軽減する方針が採用されているので、結果的に1回または数回、非常に時間のかかる(数秒間に及ぶことが多い)ガベージ・コレクションが発生することがあります。本番のSIP Serverでは、レスポンス時間の目標を維持するために、長いGC間隔が一切発生しないようにする必要があります。
次の項では、通常は結果として最高のレスポンス時間パフォーマンスになるJRockitおよびSunのJVMのGCチューニング手法を説明しています。
|
注意: JRockitの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの紹介』を参照してください。 |
Oracle WebLogic Server SIP Containerエンジンおよびレプリカを起動するためにカスタム起動スクリプトを使用する場合、スクリプトを編集して、次の項で説明されているお薦めのJVMオプションを含めるようにします。
構成ウィザードは、新しいドメインを構成するときに、デフォルトの起動スクリプトもインストールします。このスクリプトは、デフォルトでMIDDLEWARE_HOME/user_projects/domains/domain_name/binディレクトリにインストールされ、次を含みます。
startWebLogic.cmd、startWebLogic.sh: これらのスクリプトは、ドメインの管理サーバーを起動します。
startManagedWebLogic.cmd、startManagedWebLogic.sh: これらのスクリプトは、ドメイン内の管理対象エンジンおよびレプリカを起動します。
エンジンおよびレプリカの起動にOracleのインストールしたスクリプトを使用する場合、コマンド・シェルで最初にUSER_MEM_ARGS環境変数を設定することによって、JVMメモリー引数をオーバーライドできます。
|
注意: USER_MEM_ARGSの環境変数を設定することでOracleのインストールしたスクリプトで指定されたすべてのデフォルトのJVMメモリー引数をオーバーライドすることができます。常に使用する意向があるJVMメモリー引数の完全なリストにUSER_MEM_ARGSを設定します。たとえば、デフォルトのヒープ領域(-Xms、-Xmx)パラメータだけ変更する意向がある場合でも、Sun JVMを使用する場合、常に-XX:MaxPermSize=128mをUSER_MEM_ARGSの値に追加します。 |
JRockitには、任意の時点のJVMヒープを分析するために役立つ次のようなモニタリング・ツールが用意されています。
JRockitランタイム・アナライザ: ガベージ・コレクションのランタイム動作への表示および休止時間を提供します。
JRockitスタック・ダンプ: トラブルシューティングまたはパフォーマンスの向上(あるいはその両方)に役立てるためのアプリケーションのスレッド・アクティビティを表示します。
制御された環境でこれらのツールや他のツールを使用すると、本番デプロイメントで設定を使用する前に、JVM設定の効果を判定できます。
次の項では、JRockitを使用したお薦めの起動JVMオプションを説明しています。JRockitを確定的ガベージ・コレクタ(お薦め)を使用する場合、5.8.3項「Oracle JRockitリアルタイム(確定的ガベージ・コレクション)の使用」に関する項で説明されているオプションを使用してください。
確定的ガベージ・コレクタを実装するJRockitリアルタイムを使用することによって、極端に短いレスポンス時間はかなり容易に達成されます。
レプリケートされたクラスタ構成のエンジン層サーバーに次のJVM引数を使用することをお薦めします。
-Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc
|
注意: 先述の設定は、JRockit JVMを使用して新規ドメインを作成するために構成ウィザードを使用するとき、$WLSS_HOME/common/bin/wlssCommenv.shファイルにデフォルトで構成されます。
割当てインテンシブなアプリケーションに対して、 デプロイ済アプリケーションで使用される実データの量に応じて、ヒープ・サイズを調整します。開始点として、ヒープ・サイズをアプリケーションが必要とする合計の2から3倍まで設定します。必要な合計の3倍に近い値は、通常、最良のパフォーマンスをもたらします。 |
レプリカ・サーバーのため、利用可能なメモリーの容量を増大させます。
-Xms3072m -Xmx3072m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc
これらの設定は、ヒープ・サイズを修正し、確定的ガベージ・コレクションを使用して動的ガベージ・コレクタを有効化します。-XpauseTargetは最大休止時間を設定し、-XXtlasize=3kはスレッド・ローカル領域サイズを設定します。-XXnosystemgcによって、System.gc()アプリケーション・コールが強制的にガベージ・コレクションを実行しないようになります。
確定的ガベージ・コレクションを使用せずにOracleのJRockit JVMを使用するとき(本番デプロイメントではお薦めしません)、ベスト・レスポンス時間のパフォーマンスは、世代別同時実行ガベージ・コレクタを使用することによって取得されます。
エンジン層サーバーの起動オプション例の一覧は以下のとおりです。
-Xms1024m -Xmx1024m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m
|
注意: デプロイ済アプリケーションで使用される実データの量に応じて、ヒープ・サイズを微調整します。 |
レプリカ・サーバーの起動オプション例の一覧は以下のとおりです。
-Xms3072m -Xmx3072m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m
SunのJDKを使用するとき、ガベージ・コレクションのパフォーマンスをチューニングする際の目標は、フル・ガベージ・コレクション・サイクルを実行するために必要な時間を削減することです。フル・ガベージ・コレクションの頻度を最小化するためにJVMをチューニングする試行は行わないでください。これを行うと、通常は完了までに数秒かかる場合がある強制ガベージ・コレクション・サイクルになってしまうからです。
本番サーバーの存続期間におけるガベージ・コレクション時間の短縮を実現する最も単純で信頼性の高い方法は、ヒープのサイズを固定してデフォルト・コレクタと若い世代用の並行コレクタを使用することにより、新しい世代のサイズを最大でもヒープ全体の1/3までに制限することです。
ほとんどのエンジン層サーバーには以下のJVM設定例をお勧めします。
-server -Xmx1024m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC
レプリカ・サーバーには、以下の設定例を使用します。
-server -Xmx3072m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC
上記のオプションには、それぞれ次のような効果があります。
-XX:+UseTLAB: スレッド・ローカル・オブジェクトの割当てブロックを使用します。これは、共有ヒープ・ロックにおける競合を削減することによって、同時実行性を向上します。
-XX:+UseParNewGC: 同時実行マーク・アンド・スイープ・コレクタに従って、若い世代のコピー・コレクタの並列バージョンを使用します。これは、すべての使用可能なCPUを並列に使用することによって、休止時間を最小化します。このコレクタは、デフォルトのコレクタおよび同時実行マーク・アンド・スイープ(CMS)コレクタと互換性があります。
-Xms, -Xmx: ガベージ・コレクションの予測可能性を向上するために、ヒープ・サイズ上の境界を設定します。ヒープ・サイズは、フルGCでさえもSIP再送信をトリガーしないようにレプリカ・サーバーで限定されます。-Xmsは、ヒープの拡大によって生じる休止を防ぐために開始サイズを設定します。
-XX:MaxTenuringThreshold=0: フルNewSizeを各NewGCサイクルに使用できるようにし、古いオブジェクトを評価しないことによって、休止時間を削減します。技術的には、この設定によってコピーするのではなく、すべてのライブ・オブジェクトが古い世代に昇格されます。
-XX:SurvivorRatio=128: サバイバがない場合にほとんど領域が予約されないことを保証するためのゼロ保有しきい値を伴う、高いサバイバ率を指定します。
SunのJVMにおける乱数生成で使用されるライブラリは、UNIXプラットホームの場合、デフォルトで/dev/randomに依存します。一部のオペレーティング・システムでは、結果が戻される前に/dev/randomがホスト・マシン上で特定の量の「ノイズ」が生成されるまで待機するため、Oracle WebLogic Server SIP Containerプロセスをブロックする可能性があります。/dev/randomはセキュリティ性がより向上していますが、デフォルトのJVM構成がOracle WebLogic Server SIP Containerの起動を遅延する場合、/dev/urandomを使用することをお薦めします。
実際に使用しているオペレーティング・システムでこの遅延の問題が発生するかどうかを確認するには、このファイルの一部分を表示する次のコマンドをシェル・プロンプトから実行します。
head -n 1 /dev/random
テキスト・エディタで$JAVA_HOME/jre/lib/security/java.securityファイルを開きます。
次の行を変更します。
securerandom.source=file:/dev/random
読取り対象:
securerandom.source=file:/dev/urandom
変更を保存して、テキスト・エディタを終了します。
