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