この章には次の項が含まれます:
WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシン、および地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、離れた場所から管理サーバー・インスタンスや管理対象サーバー・インスタンスを起動、停止、および再起動できるWebLogic Server付属のユーティリティです。ノード・マネージャの使用は必須ではありませんが、高可用性が要求されるアプリケーションをWebLogic Server環境でホストする場合には、複数の分散しているサーバー・インスタンスの実行状態を一元的に制御できるようになるため、これを使用することをお薦めします。
ノード・マネージャは、ノード・マネージャを使用して制御するWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)をホストするコンピュータごとに実行する必要があります。詳細は、「起動サービスとしてのノード・マネージャの実行」を参照してください
管理対象サーバーの起動と停止を行うためにデフォルトのドメインごとのノード・マネージャ・インスタンスを単一マシン・ドメイン内に作成する方法を示す基本的なチュートリアルは、「ノード・マネージャのチュートリアル」を参照してください。
次の項では、基本的なノード・マネージャの機能について説明します。
WebLogic Scripting Tool(またはスクリプト・ベースのノード・マネージャを使用する場合のみSSHクライアント)を使用して、管理サーバーをホストするマシン上のノード・マネージャ・プロセスに接続し、管理サーバーを起動、停止または再起動するためのコマンドを発行します。管理サーバーとノード・マネージャの関係は、シナリオに応じて異なります。
管理サーバーをノード・マネージャの制御下に置くことができます。ノード・マネージャを使用して管理サーバーを起動、モニター、および再起動できます。
管理サーバーをノード・マネージャ・クライアントにできます。WebLogic Server管理コンソールから管理対象サーバーを起動または停止するときには、管理サーバーを使用してノード・マネージャにアクセスします。
管理サーバーは、管理対象サーバーをノード・マネージャ経由で起動するプロセスをサポートします。ノード・マネージャまたは起動スクリプトを使用して管理対象サーバーを起動すると、その管理対象サーバーは管理サーバーにアクセスして未処理の構成の更新を取得します。
WebLogic Server Scripting Tool (WLST)コマンド行、WebLogic Server管理コンソールまたはスクリプトから、管理対象インスタンスやクラスタの起動、停止、一時停止および再起動のコマンドをノード・マネージャに対して発行できます。
ノード・マネージャは、管理サーバーにアクセスできない場合でも管理対象サーバー独立(MSI)モードが有効になっていれば、管理対象サーバー・インスタンスを障害後に再起動できます。デフォルトでは、これは有効になっています。
注意:
pack
コマンドとunpack
コマンドを使用する場合は、ノード・マネージャから管理対象サーバーを初めて起動するときにMSIモードで起動できます。ただし、nmEnroll
を使用する場合は、管理対象サーバーが自身の構成を設定を取得するのにドメインの管理サーバーにアクセスできる必要があるため、ノード・マネージャが管理対象サーバーを初めて起動するときにMSIモードで起動することはできません。
注意:
ノード マネージャは、スクリプトまたはコマンド行で管理対象サーバーを起動するときに指定するものと同じコマンド引数を使用します。起動引数の詳細は、weblogic.Serverコマンドライン・リファレンスを参照してください。
ノード・マネージャを使用して起動されたサーバー・インスタンスに障害が発生した場合、ノード・マネージャはそのインスタンスを自動的に再起動します。
注意:
ノード・マネージャで再起動できるのは、ノード・マネージャを使用して起動されたサーバー・インスタンスのみです。
再起動機能は構成可能です。ノード・マネージャのデフォルトの動作は、以下のとおりです。
障害の発生した、制御下にあるサーバー・インスタンスを自動的に再起動します。この機能は無効にできます。
障害の発生したサーバー・インスタンスを特定の回数まで再起動します。再起動の回数は、ノード・マネージャのstartup.properties
ファイルでRestartMax
プロパティを設定して定義します。
ノード・マネージャに障害が発生した場合や、ノード・マネージャが明示的に停止された場合、ノード・マネージャは再起動時に前回の終了時に制御下にあったサーバー・インスタンスを判別します。ノード・マネージャは必要に応じて障害の発生したサーバー・インスタンスを再起動できます。
注意:
ノード・マネージャをオペレーティング・システムのサービスとして実行することをお薦めします。これにより、ホスト・マシンの再起動時にノード・マネージャを自動的に再起動できるようになります。
ノード・マネージャは、ノード・マネージャ・プロセスのログ・ファイルと、自身が制御する各サーバー・インスタンスのサーバー出力ログ・ファイルを作成します。詳細は、「ログ・ファイル」を参照してください。
WebLogic Serverのノード・マネージャの実装は、Javaベースとスクリプト・ベースの2つがあり、これらの機能はよく似ています。ただし、構成とセキュリティに関する考慮事項は実装ごとに異なります。
Javaベースのノード・マネージャは、Java仮想マシン(JVM)プロセスで動作します。これは、WindowsプラットフォームではWindowsサービスとして、UNIXプラットフォームではオペレーティング・システムのサービスとして実行することをお薦めします。このようにすると、システムの再起動時に自動的に再起動できるようになります。Javaベースのノード・マネージャを構成するには、構成ウィザードまたはWLSTをオフラインで使用します。
Oracleでは、Windows、Solaris、Linux on Intel、Linux on Z-SeriesおよびAIXオペレーティング・システム用のネイティブ・ノード・マネージャ・ライブラリを提供しています。
注意:
ノード・マネージャは、OpenVMS、OS/390、AS400、UnixWareおよびTru64 UNIXではサポートされていません。
この実装のノード・マネージャの構成は、nodemanager.properties
ファイルで指定されます。「nodemanager.propertiesのレビュー」を参照してください。
Javaベースのノード・マネージャのほうがセキュリティ・モデルが細分化されており、ノード・マネージャにアクセスするための管理者資格証明はドメイン管理者のものとは別になっています。「Javaベースのノード・マネージャのセキュリティの構成」を参照してください。
UNIXおよびLinuxのシステムに対しては、スクリプト・ベース実装のノード・マネージャが用意されています。このスクリプトは、UNIXシェル・スクリプトに基づいています。
スクリプト実装のノード・マネージャの構成方法は、「スクリプト・ベースのノード・マネージャの構成」を参照してください
スクリプト・ベースのノード・マネージャは、本番環境に対してはお薦めしません。ただし、ノード・マネージャが使用される環境のセキュリティの要件によっては、スクリプト・ベース実装が許容されることもあります。スクリプト・ベースのノード・マネージャの利点は、SSHを使用するように構成されたネットワークを介してサーバー・インスタンスをリモート管理できることです。サーバーを追加でインストールする必要はありません。スクリプトをリモート・マシンにコピーするだけです。
注意:
スクリプト・ベースのノード・マネージャは、オペレーティング・システムのサービスとして実行することをお薦めします。このようにすると、システムの再起動時に自動的に再起動できるようになります。
どの実装のノード・マネージャを使用するかは、WebLogic Server環境の要件によって異なります。実際の環境に最適な実装を判断する際は、次の事項を参考にしてください。
WebLogic ServerをWindowsシステムにインストールする場合は、Java実装のノード・マネージャを使用する必要があります。スクリプト実装のノード・マネージャは、Windowsではサポートされません。
Javaベースのノード・マネージャは、ドメイン作成時に構成できます。スクリプト・ベースのノード・マネージャは、ドメインの作成後に構成されます。
コンセンサス・リースを使用する場合は、Java実装のノード・マネージャを使用するとパフォーマンスが向上する可能性があります。
スクリプト・ベースのノード・マネージャの場合は、セキュリティ構成をJava実装よりもかなり単純にする必要があります。Javaベースのノード・マネージャの唯一の保護方法であるSSLに比べると、RSHおよびSSHは一般的に構成が容易です。スクリプト実装のノード・マネージャは、必要なフットプリントもJava実装に比べて小さくなります。
Java実装のノード・マネージャは、サポートされるUNIXシステム上でinetd
と併用できます。inetd
デーモンを利用すると、構成済ポートでリクエストを受け取ったときにノード・マネージャを自動的に再起動できます。Java実装のノード・マネージャは、Windowsサービスとしてインストールすることもできます。
ノード・マネージャにアクセスするには、Javaベース実装とスクリプト・ベース実装のどちらの場合も、WebLogic Server管理コンソールまたはWLSTを使用します。さらに、スクリプト・ベースのノード・マネージャには、用意されているシェル・コマンド・テンプレートからもアクセスできます。JMXを使用して管理サーバーと通信することもできます。
WebLogic Server管理コンソール - 「環境」→「マシン」→「構成」→「ノード・マネージャ」ページを使用します。
WLSTコマンドおよびスクリプト - WLSTオフラインは実行中の管理サーバーが存在しない場合に実行可能なノード・マネージャ・コマンド行インタフェースとして機能します。WLSTコマンドを使用すると、管理サーバーに接続せずにサーバー・インスタンスの起動、停止、および監視を行うことができます。WLSTとノード・マネージャを使用してサーバー・インスタンスを制御する方法の詳細は、「ノード・マネージャを使用したサーバーの制御」を参照してください
次の各項では、WebLogic Server環境におけるノード・マネージャの役割の「全体像」の図を示し、ノード・マネージャがサーバー・インスタンスとの通信に使用するプロセスについても図を使用して説明します。
図2-1は、ノード・マネージャ、ノード・マネージャのクライアント、およびノード・マネージャが制御するサーバー・インスタンスの関係を示します。
この図では、マシンAが管理サーバーをホストし、マシンBとマシンCが管理対象サーバーをホストしています。各マシンにノード・マネージャ・インスタンスがあります。ノード・マネージャを使用して、マシンAにある管理サーバーの起動、監視および再起動を行うことができます。管理サーバーをノード・マネージャ・クライアントとして使用して、マシンBとマシンCにある管理対象サーバーの起動や停止を行うことができます。
ノード・マネージャにアクセスするには、WebLogic Server管理コンソール、WLSTまたはJMXクライアントを使用します。WLSTのコマンドを使用すると、WLSTが直接ノード・マネージャ・インスタンスに接続されているときでも、WLSTが管理サーバーに接続されているときでも、サーバー・インスタンスを起動、停止および監視できます。WebLogic Server管理コンソールを使用するときは、管理サーバーを使用してノード・マネージャにアクセスすることになります。JMXクライアントを使用して管理サーバーと通信することもできます。
図2-2は、ノード・マネージャによる管理サーバー起動プロセスを示します。
この項では、すでに管理サーバーをインストールし、構成ウィザードを使用してドメイン・ディレクトリを作成していることを前提としています。
ノード・マネージャは、管理サーバーをホストするマシンAで実行されています。スタンドアロンのノード・マネージャ・クライアントはリモートにあります。
認可されたユーザーは、WLSTオフライン・コマンドnmConnect
を発行し、管理サーバーをホストするマシン上のノード・マネージャ・プロセスに接続します。nmConnect
コマンドによってノード・マネージャのユーザー名とパスワードが提供され、これらを使用してユーザーはノード・マネージャの認証を受けます。
注意:
ノード・マネージャ・インスタンスがスクリプト・ベース実装の場合は、ユーザーはSSHクライアントを使用して接続できます。
次に、ユーザーはnmStart
コマンドを発行し、管理サーバーを起動するための資格証明を提供します。例:
prps = makePropertiesObject(Username=username;Password=password") nmStart("AdminServer",props=prps)
注意:
ユーザーがすでに管理サーバーを起動し、資格証明を提供している場合は、boot.properties
ファイルが生成されます。
nmStart
コマンドでは、起動するサーバー・インスタンスを指定します。
ノード・マネージャがnodemanager.domains
でドメイン・ディレクトリをルックアップし、暗号化されたユーザー名とパスワードを格納するローカル・ファイルを使用してユーザーの資格証明を認証します。
ノード・マネージャは、管理サーバーの起動プロパティを取得します。
nmStart
コマンドでは、管理対象サーバーの起動に使用されるプロパティを渡すこともできます。このようなパラメータが渡されると、それまで保存されていたプロパティ(ノード・マネージャがそのプロパティを使用していた可能性があります)が上書きされます。プロパティがnmStart
コマンドで渡されなかった場合は、startup.properties
ファイル内の、前回の起動時またはWLSTのnmGenBootStartupProps
コマンドの使用時から維持されている値が使用されます。
ノード・マネージャが管理サーバーのプロセスを作成します。
管理サーバーが、そのconfig
ディレクトリからドメイン構成を取得します。
注意:
管理サーバーの実行後、WLSTオンライン・コマンド(nmGenBootStartupProps
)を使用して、ユーザー資格証明と起動プロパティを更新できます。
または、管理サーバーとノード・マネージャの実行中に、WebLogic Server管理コンソールの「AdminServer」→「構成」→「サーバーの起動」ページで、ユーザー資格証明と起動プロパティを更新できます。管理サーバーは、実行中のノード・マネージャに更新内容をプッシュし、ノード・マネージャは情報をディスクに書き込みます。
図2-3は、管理コンソールを使用してノード・マネージャを介して管理対象サーバーを起動するプロセスを示します。WLSTまたはJMXクライアントを使用して管理サーバーに接続することもできます。
ノード・マネージャは、管理対象サーバー1をホストするマシンBで実行されています。ドメインの管理サーバーはマシンAで実行されています。
WebLogic Server管理コンソールから、ユーザーが管理対象サーバー1の起動コマンドを発行します。
管理サーバーが、管理対象サーバー1用に構成されたリモート起動プロパティを指定して、マシンB上のノード・マネージャに管理対象サーバー1の起動コマンドを発行します。引数とその指定方法の詳細は、「リモート起動引数の構成」を参照してください。
ノード・マネージャが管理対象サーバー1を起動します。
ノード・マネージャは管理対象サーバーをドメイン・ディレクトリ内で起動します。
管理対象サーバー1が管理サーバーにアクセスし、構成情報の更新をチェックします。
ドメイン構成に未処理の変更がある場合、管理対象サーバー1は構成データのローカル・キャッシュを更新します。
図2-4は、ノード・マネージャによる管理サーバー再起動プロセスを示します。
ノード・マネージャは、管理サーバーをホストするマシンで実行されています。ノード・マネージャを使用して最初に起動された管理サーバーはすでに終了しています。管理サーバーのAutoRestart
属性はtrue
に設定されています。
注意:
サーバー・インスタンスのAutoRestart
属性がfalse
に設定されている場合、ノード・マネージャはそのインスタンスを再起動しません。ただし、クラッシュ・リカバリのシナリオにおいて、CrashRecoveryEnabled
プロパティは、AutoRestart
プロパティよりも優先されます。たとえば、あるサーバー・インスタンスに対してAutoRestart=false
と設定されているがCrashRecoveryEnabled=true
の場合は、ノード・マネージャが実行されていないときにサーバー・インスタンスに障害が発生すると、ノード・マネージャの再起動時に、そのサーバー・インスタンスのリカバリが試行されます。
ノード・マネージャが管理サーバー・プロセスの終了コードから再起動が必要であると判断します。
ノード・マネージャがboot.properties
ファイルから管理サーバーの起動に使用するユーザー名とパスワードを取得し、server_name
/data/nodemanager/startup.properties
ファイルからサーバーの起動プロパティを取得します。
ノード・マネージャが管理サーバーを起動します。
管理サーバーがその構成データを読み込み、起動します。
図2-5は、ノード・マネージャによる管理対象サーバー再起動プロセスを示します。
ノード・マネージャは、管理対象サーバー1をホストするマシンBで実行されています。ノード・マネージャを使用して最初に起動された管理対象サーバー1はすでに終了しています。管理対象サーバー1のAutoRestart
属性はtrue
に設定されています。
注意:
サーバー・インスタンスのAutoRestart
属性がfalse
に設定されている場合、ノード・マネージャはそのインスタンスを再起動しません。ただし、クラッシュ・リカバリのシナリオにおいて、CrashRecoveryEnabled
プロパティは、AutoRestart
プロパティよりも優先されます。たとえば、あるサーバー・インスタンスに対してAutoRestart=false
と設定されているがCrashRecoveryEnabled=true
の場合は、ノード・マネージャが実行されていないときにサーバー・インスタンスに障害が発生すると、ノード・マネージャの再起動時に、そのサーバー・インスタンスのリカバリが試行されます。
ノード・マネージャは、管理対象サーバー1プロセスの終了コードから、この管理対象サーバーの再起動が必要であると判断します。
ノード・マネージャがboot.properties
ファイルから管理対象サーバー1の起動に使用するユーザー名とパスワードを取得し、startup.properties
ファイルからサーバーの起動プロパティを取得します。これらのサーバー固有のファイルは、管理対象サーバー1のserver_name
/data/nodemanager/
ディレクトリにあります。
ノード・マネージャが管理対象サーバー1を起動します。
注意:
ノード・マネージャは、サーバー・インスタンスに障害が発生した後からRestartDelaySeconds
で指定された秒数待機してから再起動を行います。
管理対象サーバー1が管理サーバーにアクセスし、構成データの更新をチェックします。管理サーバーにアクセスし、構成データの更新を取得すると、管理対象サーバー1はconfig
ディレクトリのローカル・キャッシュを更新します。
管理対象サーバー1が管理サーバーにアクセスできなかった場合に管理対象サーバー独立(MSI)モードが有効になっていると、管理対象サーバー1はローカルにキャッシュされた構成データを使用します。
注意:
管理対象サーバー独立(MSI)モードはデフォルトで有効になっています。MSIモードは、次のときにも有効になります。
admin_url
が指定されていない。admin_url
では、ドメインの管理サーバーのリスニング・アドレス(ホスト名、IPアドレスまたはDNS名)およびポート番号が指定されます。
admin_url
が指定されているが、管理サーバーがなんらかの理由で到達不可となっている。
管理対象サーバーは周期的に管理サーバーへの再接続を試行するので、MSIモードは一時的なものということもあります。
図2-6は、ノード・マネージャの制御下にある管理対象サーバーの停止に伴う通信について説明しています。管理対象サーバーの状態と可用性によっては、ノード・マネージャによる強制シャットダウンが必要になることがあります。ノード・マネージャは、管理対象サーバーの正常な停止を行うことはできません。
ノード・マネージャは、管理対象サーバー1をホストするマシンBで実行されています。
認可されたユーザーが、WebLogic Server管理コンソールを使用して管理対象サーバー1の停止コマンドを発行します。
管理サーバーは管理対象サーバー1への接続を試行し、停止コマンドを直接、管理対象サーバー1に対して発行します。管理サーバーから管理対象サーバー1への接続に成功すると、管理対象サーバー1は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のWebLogic Serverのインスタンスの停止に関する項で説明している停止シーケンスを実行します。管理対象サーバー自身が正常に停止するには、管理対象サーバーが管理サーバーに接続している必要があります。
前の手順で管理サーバーが管理対象サーバー1に接続できなかった場合は、管理サーバーはノード・マネージャに接続して管理サーバー1のkillコマンドを発行します。
ノード・マネージャが、オペレーティング・システムに管理対象サーバー1を強制停止するようにリクエストを発行します。
オペレーティング・システムが管理対象サーバー1のプロセスを終了させます。
システム・クラッシュの後、ノード・マネージャが適切にサーバー・インスタンスを再起動するようにするには、次のことを実行する必要があります。
Javaベースのノード・マネージャの場合、CrashRecoveryEnabled
がtrue
に設定されていることを確認します。
CrashRecoveryEnabled
構成プロパティを設定しておくと、ノード・マネージャがシステム・クラッシュの後にサーバー・インスタンスを再起動できます。このプロパティは、デフォルトでは有効になっていません。
注意:
クラッシュ・リカバリのシナリオにおいて、CrashRecoveryEnabled
構成プロパティは、AutoRestart
サーバー起動プロパティよりも優先されます。たとえば、あるサーバー・インスタンスに対してAutoRestart=false
と設定されているがCrashRecoveryEnabled=true
の場合は、ノード・マネージャが実行されていないときにサーバー・インスタンスに障害が発生すると、ノード・マネージャの再起動時に、そのサーバー・インスタンスのリカバリが試行されます。
スクリプト・ベースのノード・マネージャの場合、この行をマシン起動スクリプトに配置するか、必要に応じて指定スケジュールで定期的に実行します。
wlscontrol.sh -d domain_name
CRASHRECOVERY
管理サーバーをノード・マネージャを使用して起動します。
すべての管理対象サーバーを管理サーバーを使用して起動します。このようにするには、WLSTまたはWebLogic Server管理コンソールを使用します。
システムの再起動後、ノード・マネージャはnodemanager.domains
ファイルで指定された各管理対象ドメインをチェックして、停止に問題のあったサーバー・インスタンスがあるかどうかを判断します。これは、WebLogic Serverプロセスの作成時にノード・マネージャによって作成されたロック・ファイルが存在するかどうかによって決まります。このロック・ファイルには、WebLogic Server起動スクリプトのプロセス識別子が含まれています。ロック・ファイルが存在するが、そのプロセスIDが実行中ではない場合、ノード・マネージャは自動的にサーバー・インスタンスの再起動を試行します。
プロセスが実行中であれば、ノード・マネージャはさらにチェックを行ってプロセス内で実行されている管理サーブレットにアクセスし、プロセスIDに対応するプロセスが、WebLogic Serverインスタンスであることを確認します。
注意:
ノード・マネージャがチェックを実行して管理サーブレットにアクセスする際、不適切な資格証明に関し、サーバー・ログ内にアラートが示されることがあります。
複数のサーバー・インスタンスを管理する場合、図2-7に示すように、ノード・マネージャは複数の構成ファイルを使用し、ログ・ファイルを複数のディレクトリに出力します。
以下の項では、ノード・マネージャの構成ファイルとログ・ファイルについて説明します。
言及されていない限り、構成ファイルはJavaベースのノード・マネージャとスクリプト・ベースのノード・マネージャの両方に適用されます。
Javaベース実装のノード・マネージャによって使用される構成ファイルです。「nodemanager.propertiesのレビュー」を参照してください。
デフォルトでは、このファイルはNodeManagerHome
(通常ORACLE_HOME
\user_projects\domains\
domain_name
\nodemanager
)にあります。ここでORACLE_HOME
は、WebLogic Serverのインストール時にOracleホームとして指定した場所です。
このファイルには、ノード・マネージャによって管理されるドメインの名前と、それに対応するディレクトリのマッピングが格納されます。「nodemanager.domainsファイルの構成」を参照してください
Javaベースのノード・マネージャの場合、このファイルはNodeManagerHome
(通常ORACLE_HOME\user_projects\domains\domain_name\nodemanager
)にあります。
スクリプトベースのノード・マネージャの場合、このファイルのデフォルトのNodeManagerHome
の場所はWL_HOME/common/nodemanager
です。ここでWL_HOME
は、WebLogic Serverをインストールした場所(ORACLE_HOME/wlserver
など)です。
このファイルは、ノード・マネージャのユーザー名とパスワードを保存します。「ノード・マネージャのユーザー名とパスワードの指定」を参照してください
このファイルは、DOMAIN_HOME
/config/nodemanager
にあります。ここでDOMAIN_HOME
は、WebLogicドメインの場所(通常ORACLE_HOME\user_projects\domains\domain_name
)です。
ノード・マネージャはこのファイルを使用して、サーバー・インスタンスの起動時にユーザー資格証明を指定します。
このファイルはDOMAIN_HOME
/servers/
server_name
/data/nodemanager
にあります。
各管理対象サーバー・インスタンスには、ノード・マネージャによるサーバー・インスタンスの起動および管理方法を制御するプロパティが含まれた独自のstartup.properties
ファイルがあります。このファイルは、前回管理サーバーを使用してそのサーバー・インスタンスが起動されたときにノード・マネージャに渡されたプロパティを使用して自動的に作成されます。これにより、ノード・マネージャ・クライアントまたは起動スクリプトは、管理サーバーによって最後に使用されたものと同じプロパティを使用して管理対象サーバーを再起動できるようになります。
startup.properties
の詳細は、「サーバーの起動プロパティの設定」を参照してください。これらのプロパティは、ServerStartMBean
のサーバー起動属性とServerStartMBean
の状態モニター属性に対応しています。
このファイルはDOMAIN_HOME
/servers/
server_name
/data/nodemanager
にあります。
server_name
.addr
には、サーバー・インスタンスが起動または移行されたときに追加されたIPアドレスが格納されます。このファイルは、移行中にサーバーIPアドレスが正常にオンラインになった後に生成されます。IPアドレスがオフラインになると、server_name
.addr
は削除されます。サーバー・インスタンスを停止するときにアドレスが誤って削除されるのを防止するために、サーバーIPアドレスを使用して削除リクエストが検証されます。
このファイルはDOMAIN_HOME
/servers/
server_name
/data/nodemanager
にあります。
server_name
.lck
は各サーバー・インスタンスによって生成され、内部的に使用されるロックIDが格納されます。
このファイルはDOMAIN_HOME
/servers/
server_name
/data/nodemanager
にあります。
server_name
.pid
は各サーバー・インスタンスによって生成され、そのサーバー・インスタンスのプロセスIDが格納されます。ノード・マネージャは、サーバー・インスタンスによって生成されたプロセスIDをクラッシュ・リカバリ時にチェックします。
このファイルはDOMAIN_HOME
/servers/
server_name
/data/nodemanager
にあります。
個々の管理対象サーバーの起動または停止に関する問題を解決するには、ノード・マネージャおよびWebLogic Serverのログ・ファイルを利用します。
表2-1 ノード・マネージャ・ログ・ファイルの場所
ログ・ファイル | 場所 |
---|---|
ノード・マネージャのログ・ファイル |
Javaベースのノード・マネージャのみ、 |
ノード・マネージャ・サーバー・インスタンスのログ・ファイル |
|
WebLogic Serverのログ・ファイル |
|
nodemanager.log
は、スクリプトベース・ノード・マネージャではなく、Javaベース・ノード・マネージャに対してのみ作成されます。このログ・ファイルは、ノード・マネージャによって生成され、ノード・マネージャによって制御される特定のドメインに関するデータが格納されます。このファイルは、通常ORACLE_HOME
\user_projects\domains\
domain_name
\nodemanager
にあります。
ログ出力は、現在のnodemanager.log
に追加されます。ログ・ローテーションはデフォルトでは無効になっていますが、nodemanager.properties
でLogCount
を設定することで有効にできます。
次の方法で、ノード・マネージャのログ・ファイルを表示できます。
WebLogic Server管理コンソールで「マシン」→「監視」→「ノード・マネージャのログ」ページを選択します。
WLSTのnmLog
コマンドを使用します。
ノード・マネージャは制御対象の各サーバー・インスタンスについて、サーバー・インスタンスで生成されるstdout
メッセージおよびstderr
メッセージを格納するログ・ファイルを保持します。サーバー・インスタンスのリモート起動プロパティとしてリモート起動デバッグ・プロパティが有効になっている場合や、ノード・マネージャのデバッグ・プロパティが有効になっている場合には、ノード・マネージャによってサーバーの出力ログ情報にデバッグ情報が追加されます。デフォルトでは、このファイルはDOMAIN_HOME/servers/server_name/logs
にあります。server_nameはサーバー・インスタンスの名前です。
ただし、ユーザーがServerStartMBean
のArguments
フィールドに-Dweblogic.Stdout=
を追加した場合、この値がデフォルトの場所をオーバーライドし、ノード・マネージャでは指定されたパスが出力用のファイルとして使用されます。server_name.out
のデフォルトの場所は、nodemanager.properties
ファイルのweblogic.startup.Arguments.prepend
プロパティを使用してオーバーライドすることはできません。このプロパティは、複数のサーバー・インスタンスに適用されるからです。
ノード・マネージャによって、サーバー・インスタンスのlogs
ディレクトリにそのサーバー・インスタンスのサーバー出力ログが次の名前で作成されます。
server_name
.out
次の方法で、特定のサーバー・インスタンスに関するノード・マネージャのログ・ファイルを表示できます。
「診断」>「ログ・ファイル」を選択します。
WLSTのnmServerLog
コマンドを使用します。
ノード・マネージャが作成できるサーバー出力ログ数に制限はありません。
WebLogic Server 12.1.3.0よりも前のリリースでは、NativeVersionEnabled=false
のときに、表2-2に示すノード・マネージャのログ・ファイル・ローテーションのプロパティを構成できました。WebLogic Server 12.1.3.0では、ノード・マネージャはログ・ファイル・ローテーションにLogFileMBean
のプロパティを使用し、ノード・マネージャが作成するサーバー出力ファイルはNativeVersionEnabled=false
の場合にローテーションされます。
注意:
管理対象サーバーの起動引数に次のプロパティを追加すると、NativeVersionEnabled=true
を使用してログ・ファイルをローテーションすることができます。
-Dweblogic.nmservice.RotationEnabled=true
Coherenceおよびその他のプラグイン実装済のシステム・コンポーネントについては、表2-3に示すログ・ファイル・ローテーションのプロパティが使用されます。
表2-2 ノード・マネージャのログ・ファイル・ローテーション・プロパティ
プロパティ | 説明 | デフォルト |
---|---|---|
|
このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。 ログ・ファイル・ローテーションの値を調整するには、サーバー |
|
|
このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。 ログ・ファイル・ローテーションの値を調整するには、サーバー |
|
|
このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。 ログ・ファイル・ローテーションの値を調整するには、サーバー |
|
|
このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。 ログ・ファイル・ローテーションの値を調整するには、サーバー |
|
|
このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。 ログ・ファイル・ローテーションの値を調整するには、サーバー |
|
|
このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。 ログ・ファイル・ローテーションの値を調整するには、サーバー |
|
|
このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。 ログ・ファイル・ローテーションの値を調整するには、サーバー |
|
表2-3 ノード・マネージャのログ・ファイル・ローテーション・プロパティ(Coherenceおよびシステム・コンポーネント)
プロパティ | 説明 | デフォルト |
---|---|---|
|
ファイルの最大サイズを指定します。このサイズに達するとファイルがローテーションされます。 |
|
|
古いログ・メッセージを別のファイルに保存する間隔(単位は時間)です。 |
|
|
ログ・ローテーションを別の頻度でテストできるようになります。 注意: このプロパティの変更や設定が必要になることはほとんどありません。 |
|
|
古いメッセージを保存するためにこのサーバー・インスタンスが作成するファイルの数を制限するかどうかを示します。 |
|
|
|
|
|
時間ベースのローテーション順序の開始時間(時間および分)を指定します。この値で指定された時刻に、現在のログ・ファイルの名前が変更されます。それ以後は、 |
|
|
古いログ・メッセージを別のファイルに移動するための基準を指定します。
|
|