プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3 ノード・マネージャの管理
12c (12.1.3)
E56251-06
  目次へ移動
目次

前
 
次
 

2 ノード・マネージャの概要

この章では、WebLogic Server 12.1.3ユーティリティの1つであるノード・マネージャについて紹介します。また、ノード・マネージャが管理サーバーと管理対象サーバーをコントロールする仕組みについても説明します。

この章には次の項が含まれます:

はじめに

WebLogic Serverの本番環境では、サーバー・インスタンスが複数のドメイン、マシン、および地理的な場所にまたがって分散することがよくあります。ノード・マネージャは、離れた場所から管理サーバー・インスタンスや管理対象サーバー・インスタンスを起動、停止、および再起動できるWebLogic Server付属のユーティリティです。ノード・マネージャの使用は必須ではありませんが、高可用性が要求されるアプリケーションをWebLogic Server環境でホストする場合には、複数の分散しているサーバー・インスタンスの実行状態を一元的に制御できるようになるため、これを使用することをお薦めします。

ノード・マネージャは、ノード・マネージャを使用して制御するWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)をホストするコンピュータごとに実行する必要があります。詳細は、「起動サービスとしてのノード・マネージャの実行」を参照してください。

管理対象サーバーの起動と停止を行うためにデフォルトのドメインごとのノード・マネージャ・インスタンスを単一マシン・ドメイン内に作成する方法を示す基本的なチュートリアルは、第3章「ノード・マネージャのチュートリアル」を参照してください。

ノード・マネージャの機能

次の項では、基本的なノード・マネージャの機能について説明します。

管理サーバーの起動、停止、および再起動

WebLogic Scripting Tool(またはスクリプト・ベースのノード・マネージャを使用する場合のみSSHクライアント)を使用して、管理サーバーをホストするマシン上のノード・マネージャ・プロセスに接続し、管理サーバーを起動、停止または再起動するためのコマンドを発行します。管理サーバーとノード・マネージャの関係は、シナリオに応じて異なります。

  • 管理サーバーをノード・マネージャの制御下に置くことができます。ノード・マネージャを使用して管理サーバーを起動、モニター、および再起動できます。

  • 管理サーバーをノード・マネージャ・クライアントにできます。WebLogic Server管理コンソールから管理対象サーバーを起動または停止するときには、管理サーバーを使用してノード・マネージャにアクセスします。

  • 管理サーバーは、管理対象サーバーをノード・マネージャ経由で起動するプロセスをサポートします。ノード・マネージャまたは起動スクリプトを使用して管理対象サーバーを起動すると、その管理対象サーバーは管理サーバーにアクセスして未処理の構成の更新を取得します。

管理対象サーバーの起動、停止、一時停止、および再起動

WebLogic Server Scripting Tool (WLST)コマンド行、WebLogic Server管理コンソールまたはスクリプトから、管理対象インスタンスやクラスタの起動、停止、一時停止および再起動のコマンドをノード・マネージャに対して発行できます。

ノード・マネージャは、管理サーバーにアクセスできない場合でも管理対象サーバー独立(MSI)モードが有効になっていれば、管理対象サーバー・インスタンスを障害後に再起動できます。デフォルトでは、これは有効になっています。


注意:

packコマンドとunpackコマンドを使用する場合は、ノード・マネージャから管理対象サーバーを初めて起動するときにMSIモードで起動できます。ただし、nmEnrollを使用する場合は、管理対象サーバーが自身の構成を設定を取得するのにドメインの管理サーバーにアクセスできる必要があるため、ノード・マネージャが管理対象サーバーを初めて起動するときにMSIモードで起動することはできません。


注意:

ノード マネージャは、スクリプトまたはコマンド行で管理対象サーバーを起動するときに指定するものと同じコマンド引数を使用します。起動引数の詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド行リファレンスに関する項を参照してください。

管理サーバーおよび管理対象サーバーの自動再起動

ノード・マネージャを使用して起動されたサーバー・インスタンスに障害が発生した場合、ノード・マネージャはそのインスタンスを自動的に再起動します。


注意:

ノード・マネージャで再起動できるのは、ノード・マネージャを使用して起動されたサーバー・インスタンスのみです。

再起動機能は構成可能です。ノード・マネージャのデフォルトの動作は、以下のとおりです。

  • 障害の発生した、制御下にあるサーバー・インスタンスを自動的に再起動します。この機能は無効にできます。

  • 障害の発生したサーバー・インスタンスを特定の回数まで再起動します。再起動の回数は、ノード・マネージャのstartup.propertiesファイルでRestartMaxプロパティを設定して定義します。

ノード・マネージャに障害が発生した場合や、ノード・マネージャが明示的に停止された場合、ノード・マネージャは再起動時に前回の終了時に制御下にあったサーバー・インスタンスを判別します。ノード・マネージャは必要に応じて障害の発生したサーバー・インスタンスを再起動できます。


注意:

ノード・マネージャをオペレーティング・システムのサービスとして実行することをお薦めします。これにより、ホスト・マシンの再起動時にノード・マネージャを自動的に再起動できるようになります。

サーバーのモニターとログ・データの表示

ノード・マネージャは、ノード・マネージャ・プロセスのログ・ファイルと、自身が制御する各サーバー・インスタンスのサーバー出力ログ・ファイルを作成します。詳細は、「ログ・ファイル」を参照してください。

ノード・マネージャの実装

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を使用するように構成されたネットワークを介してサーバー・インスタンスをリモート管理できることです。サーバーを追加でインストールする必要はありません。スクリプトをリモート・マシンにコピーするだけです。


注意:

スクリプト・ベースのノード・マネージャは、オペレーティング・システムのサービスとして実行することをお薦めします。このようにすると、システムの再起動時に自動的に再起動できるようになります。

使用するノード・マネージャ実装の決定

どの実装のノード・マネージャを使用するかは、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環境でのノード・マネージャの機能

次の各項では、WebLogic Server環境におけるノード・マネージャの役割の「全体像」の図を示し、ノード・マネージャがサーバー・インスタンスとの通信に使用するプロセスについても図を使用して説明します。

ノード・マネージャとサーバーの図

図2-1は、ノード・マネージャ、ノード・マネージャのクライアント、およびノード・マネージャが制御するサーバー・インスタンスの関係を示します。

この図では、マシンAが管理サーバーをホストし、マシンBとマシンCが管理対象サーバーをホストしています。各マシンにノード・マネージャ・インスタンスがあります。ノード・マネージャを使用して、マシンAにある管理サーバーの起動、監視および再起動を行うことができます。管理サーバーをノード・マネージャ・クライアントとして使用して、マシンBとマシンCにある管理対象サーバーの起動や停止を行うことができます。

ノード・マネージャにアクセスするには、WebLogic Server管理コンソール、WLSTまたはJMXクライアントを使用します。WLSTのコマンドを使用すると、WLSTが直接ノード・マネージャ・インスタンスに接続されているときでも、WLSTが管理サーバーに接続されているときでも、サーバー・インスタンスを起動、停止および監視できます。WebLogic Server管理コンソールを使用するときは、管理サーバーを使用してノード・マネージャにアクセスすることになります。JMXクライアントを使用して管理サーバーと通信することもできます。

図2-1 WebLogic Server環境でのノード・マネージャ

図2-1の説明が続きます
「図2-1 WebLogic Server環境でのノード・マネージャ」の説明

ノード・マネージャが管理サーバーを起動する仕組み

図2-2は、ノード・マネージャによる管理サーバー起動プロセスを示します。

この項では、すでに管理サーバーをインストールし、構成ウィザードを使用してドメイン・ディレクトリを作成していることを前提としています。

ノード・マネージャは、管理サーバーをホストするマシンAで実行されています。スタンドアロンのノード・マネージャ・クライアントはリモートにあります。

図2-2 管理サーバーの起動

図2-2の説明が続きます
「図2-2 管理サーバーの起動」の説明

  1. 認可されたユーザーは、WLSTオフライン・コマンドnmConnectを発行し、管理サーバーをホストするマシン上のノード・マネージャ・プロセスに接続します。nmConnectコマンドによってノード・マネージャのユーザー名とパスワードが提供され、これらを使用してユーザーはノード・マネージャの認証を受けます。


    注意:

    ノード・マネージャ・インスタンスがスクリプト・ベース実装の場合は、ユーザーはSSHクライアントを使用して接続できます。

    次に、ユーザーはnmStartコマンドを発行し、管理サーバーを起動するための資格証明を提供します。例:

    prps = makePropertiesObject(Username=username;Password=password")
    nmStart("AdminServer",props=prps) 
    

    注意:

    ユーザーがすでに管理サーバーを起動し、資格証明を提供している場合は、boot.propertiesファイルが生成されます。

    nmStartコマンドでは、起動するサーバー・インスタンスを指定します。

  2. ノード・マネージャがnodemanager.domainsでドメイン・ディレクトリをルックアップし、暗号化されたユーザー名とパスワードを格納するローカル・ファイルを使用してユーザーの資格証明を認証します。

  3. ノード・マネージャは、管理サーバーの起動プロパティを取得します。

    nmStartコマンドでは、管理対象サーバーの起動に使用されるプロパティを渡すこともできます。このようなパラメータが渡されると、それまで保存されていたプロパティ(ノード・マネージャがそのプロパティを使用していた可能性があります)が上書きされます。プロパティがnmStartコマンドで渡されなかった場合は、startup.propertiesファイル内の、前回の起動時またはWLSTのnmGenBootStartupPropsコマンドの使用時から維持されている値が使用されます。

  4. ノード・マネージャが管理サーバーのプロセスを作成します。

  5. 管理サーバーが、そのconfigディレクトリからドメイン構成を取得します。


注意:

管理サーバーの実行後、WLSTオンライン・コマンド(nmGenBootStartupProps)を使用して、ユーザー資格証明と起動プロパティを更新できます。

または、管理サーバーとノード・マネージャの実行中に、WebLogic Server管理コンソールの「AdminServer」→「構成」→「サーバーの起動」ページで、ユーザー資格証明と起動プロパティを更新できます。管理サーバーは、実行中のノード・マネージャに更新内容をプッシュし、ノード・マネージャは情報をディスクに書き込みます。


ノード・マネージャが管理対象サーバーを起動する仕組み

図2-3は、管理コンソールを使用してノード・マネージャを介して管理対象サーバーを起動するプロセスを示します。WLSTまたはJMXクライアントを使用して管理サーバーに接続することもできます。

ノード・マネージャは、管理対象サーバー1をホストするマシンBで実行されています。ドメインの管理サーバーはマシンAで実行されています。

図2-3 管理対象サーバーの起動

図2-3の説明が続きます
「図2-3 管理対象サーバーの起動」の説明

  1. WebLogic Server管理コンソールから、ユーザーが管理対象サーバー1の起動コマンドを発行します。

  2. 管理サーバーが、管理対象サーバー1用に構成されたリモート起動プロパティを指定して、マシンB上のノード・マネージャに管理対象サーバー1の起動コマンドを発行します。引数とその指定方法の詳細は、「リモート起動引数の構成」を参照してください。

  3. ノード・マネージャが管理対象サーバー1を起動します。

    ノード・マネージャは管理対象サーバーをドメイン・ディレクトリ内で起動します。

  4. 管理対象サーバー1が管理サーバーにアクセスし、構成情報の更新をチェックします。

  5. ドメイン構成に未処理の変更がある場合、管理対象サーバー1は構成データのローカル・キャッシュを更新します。

ノード・マネージャが管理サーバーを再起動する仕組み

図2-4は、ノード・マネージャによる管理サーバー再起動プロセスを示します。

ノード・マネージャは、管理サーバーをホストするマシンで実行されています。ノード・マネージャを使用して最初に起動された管理サーバーはすでに終了しています。管理サーバーのAutoRestart属性はtrueに設定されています。


注意:

サーバー・インスタンスのAutoRestart属性がfalseに設定されている場合、ノード・マネージャはそのインスタンスを再起動しません。ただし、クラッシュ・リカバリのシナリオにおいて、CrashRecoveryEnabledプロパティは、AutoRestartプロパティよりも優先されます。たとえば、あるサーバー・インスタンスに対してAutoRestart=falseと設定されているがCrashRecoveryEnabled=trueの場合は、ノード・マネージャが実行されていないときにサーバー・インスタンスに障害が発生すると、ノード・マネージャの再起動時に、そのサーバー・インスタンスのリカバリが試行されます。

図2-4 管理サーバーの再起動

図2-4の説明が続きます
「図2-4 管理サーバーの再起動」の説明

  1. ノード・マネージャが管理サーバー・プロセスの終了コードから再起動が必要であると判断します。

  2. ノード・マネージャがboot.propertiesファイルから管理サーバーの起動に使用するユーザー名とパスワードを取得し、server_name/data/nodemanager/startup.propertiesファイルからサーバーの起動プロパティを取得します。

  3. ノード・マネージャが管理サーバーを起動します。

  4. 管理サーバーがその構成データを読み込み、起動します。

ノード・マネージャが管理対象サーバーを再起動する仕組み

図2-5は、ノード・マネージャによる管理対象サーバー再起動プロセスを示します。

ノード・マネージャは、管理対象サーバー1をホストするマシンBで実行されています。ノード・マネージャを使用して最初に起動された管理対象サーバー1はすでに終了しています。管理対象サーバー1のAutoRestart属性はtrueに設定されています。


注意:

サーバー・インスタンスのAutoRestart属性がfalseに設定されている場合、ノード・マネージャはそのインスタンスを再起動しません。ただし、クラッシュ・リカバリのシナリオにおいて、CrashRecoveryEnabledプロパティは、AutoRestartプロパティよりも優先されます。たとえば、あるサーバー・インスタンスに対してAutoRestart=falseと設定されているがCrashRecoveryEnabled=trueの場合は、ノード・マネージャが実行されていないときにサーバー・インスタンスに障害が発生すると、ノード・マネージャの再起動時に、そのサーバー・インスタンスのリカバリが試行されます。

図2-5 管理対象サーバーの再起動

図2-5の説明が続きます
「図2-5 管理対象サーバーの再起動」の説明

  1. ノード・マネージャは、管理対象サーバー1プロセスの終了コードから、この管理対象サーバーの再起動が必要であると判断します。

  2. ノード・マネージャがboot.propertiesファイルから管理対象サーバー1の起動に使用するユーザー名とパスワードを取得し、startup.propertiesファイルからサーバーの起動プロパティを取得します。これらのサーバー固有のファイルは、管理対象サーバー1のserver_name/data/nodemanager/ディレクトリにあります。

  3. ノード・マネージャが管理対象サーバー1を起動します。


    注意:

    ノード・マネージャは、サーバー・インスタンスに障害が発生した後からRestartDelaySecondsで指定された秒数待機してから再起動を行います。

  4. 管理対象サーバー1が管理サーバーにアクセスし、構成データの更新をチェックします。管理サーバーにアクセスし、構成データの更新を取得すると、管理対象サーバー1はconfigディレクトリのローカル・キャッシュを更新します。

  5. 管理対象サーバー1が管理サーバーにアクセスできなかった場合に管理対象サーバー独立(MSI)モードが有効になっていると、管理対象サーバー1はローカルにキャッシュされた構成データを使用します。


    注意:

    管理対象サーバー独立(MSI)モードはデフォルトで有効になっています。MSIモードは、次のときにも有効になります。
    • admin_urlが指定されていない。admin_urlでは、ドメインの管理サーバーのリスニング・アドレス(ホスト名、IPアドレスまたはDNS名)およびポート番号が指定されます。

    • admin_urlが指定されているが、管理サーバーがなんらかの理由で到達不可となっている。

    管理対象サーバーは周期的に管理サーバーへの再接続を試行するので、MSIモードは一時的なものということもあります。


ノード・マネージャがサーバー・インスタンスを停止する仕組み

図2-6は、ノード・マネージャの制御下にある管理対象サーバーの停止に伴う通信について説明しています。管理対象サーバーの状態と可用性によっては、ノード・マネージャによる強制シャットダウンが必要になることがあります。ノード・マネージャは、管理対象サーバーの正常な停止を行うことはできません。

ノード・マネージャは、管理対象サーバー1をホストするマシンBで実行されています。

図2-6 ノード・マネージャの制御下にあるサーバー・インスタンスの停止

図2-6の説明が続きます
「図2-6 ノード・マネージャの制御下にあるサーバー・インスタンスの停止」の説明

  1. 認可されたユーザーが、WebLogic Server管理コンソールを使用して管理対象サーバー1の停止コマンドを発行します。

  2. 管理サーバーは管理対象サーバー1への接続を試行し、停止コマンドを直接、管理対象サーバー1に対して発行します。管理サーバーから管理対象サーバー1への接続に成功すると、管理対象サーバー1は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のWebLogic Serverのインスタンスの停止に関する項で説明している停止シーケンスを実行します。管理対象サーバー自身が正常に停止するには、管理対象サーバーが管理サーバーに接続している必要があります。

  3. 前の手順で管理サーバーが管理対象サーバー1に接続できなかった場合は、管理サーバーはノード・マネージャに接続して管理サーバー1のkillコマンドを発行します。

  4. ノード・マネージャが、オペレーティング・システムに管理対象サーバー1を強制停止するようにリクエストを発行します。

  5. オペレーティング・システムが管理対象サーバー1のプロセスを終了させます。

ノード・マネージャとシステム・クラッシュのリカバリ

システム・クラッシュの後、ノード・マネージャが適切にサーバー・インスタンスを再起動するようにするには、次のことを実行する必要があります。

  • Javaベースのノード・マネージャの場合、CrashRecoveryEnabledtrueに設定されていることを確認します。

    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に示すように、ノード・マネージャは複数の構成ファイルを使用し、ログ・ファイルを複数のディレクトリに出力します。

図2-7 ノード・マネージャの構成とロギングの環境

図2-7の説明が続きます
「図2-7 ノード・マネージャの構成とロギングの環境」の説明

以下の項では、ノード・マネージャの構成ファイルとログ・ファイルについて説明します。

構成ファイル

言及されていない限り、構成ファイルはJavaベースのノード・マネージャとスクリプト・ベースのノード・マネージャの両方に適用されます。

nodemanager.properties

Javaベース実装のノード・マネージャによって使用される構成ファイルです。「nodemanager.propertiesのレビュー」を参照してください。

デフォルトでは、このファイルはNodeManagerHome(通常ORACLE_HOME\user_projects\domains\domain_name\nodemanager)にあります。ここでORACLE_HOMEは、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ファイルがあります。このファイルは、前回管理サーバーを使用してそのサーバー・インスタンスが起動されたときにノード・マネージャに渡されたプロパティを使用して自動的に作成されます。これにより、ノード・マネージャ・クライアントまたは起動スクリプトは、管理サーバーによって最後に使用されたものと同じプロパティを使用して管理対象サーバーを再起動できるようになります。

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にあります。

server_name.state

server_name.stateはサーバー・インスタンスによって生成され、そのサーバー・インスタンスの現在の状態が格納されます。ノード・マネージャは、このファイルの内容を監視してサーバー・インスタンスの現在の状態を判別します。


注意:

このファイルは削除も変更もしないでください。このファイルがないと、ノード・マネージャはサーバー・インスタンスの現在の状態を判別できません。

このファイルはDOMAIN_HOME/servers/server_name/data/nodemanagerにあります。

ログ・ファイル

個々の管理対象サーバーの起動または停止に関する問題を解決するには、ノード・マネージャおよびWebLogic Serverのログ・ファイルを利用します。

表2-1 ノード・マネージャ・ログ・ファイルの場所

ログ・ファイル 場所

ノード・マネージャのログ・ファイル

Javaベースのノード・マネージャのみ、NodeManagerHome/nodemanager.log。ここでNodeManagerHomeは、通常ORACLE_HOME\user_projects\domains\domain_name\nodemanagerにあります。

ノード・マネージャ・サーバー・インスタンスのログ・ファイル

DOMAIN_HOME/servers/server_name/logs/server_name.out。ここでDOMAIN_HOMEは、WebLogicドメインをインストールした場所です(ORACLE_HOME\user_projects\domains\domain_nameなど)。

WebLogic Serverのログ・ファイル

DOMAIN_HOME/servers/server_name/logs/server_name.log


nodemanager.log

nodemanager.logは、スクリプトベース・ノード・マネージャではなく、Javaベース・ノード・マネージャに対してのみ作成されます。このログ・ファイルは、ノード・マネージャによって生成され、ノード・マネージャによって制御される特定のドメインに関するデータが格納されます。このファイルは、通常ORACLE_HOME\user_projects\domains\domain_name\nodemanagerにあります。

ログ出力は、現在のnodemanager.logに追加されます。ログ・ローテーションはデフォルトでは無効になっていますが、nodemanager.propertiesLogCountを設定することで有効にできます。

次の方法で、ノード・マネージャのログ・ファイルを表示できます。

  • WebLogic Server管理コンソールで「マシン」「監視」「ノード・マネージャのログ」ページを選択します。

  • WLSTのnmLogコマンドを使用します。

server_name.out

ノード・マネージャは制御対象の各サーバー・インスタンスについて、サーバー・インスタンスで生成されるstdoutメッセージおよびstderrメッセージを格納するログ・ファイルを保持します。サーバー・インスタンスのリモート起動プロパティとしてリモート起動デバッグ・プロパティが有効になっている場合や、ノード・マネージャのデバッグ・プロパティが有効になっている場合には、ノード・マネージャによってサーバーの出力ログ情報にデバッグ情報が追加されます。ただし、ユーザーがServerStartMBeanArgumentsフィールドに-Dweblogic.Stdout=を追加した場合は、出力ファイルとして指定されたパスが使用されます。

このファイルは、DOMAIN_HOME/servers/server_name/logsにあります。ここでserver_nameは、サーバー・インスタンスの名前です。

ノード・マネージャによって、サーバー・インスタンスの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 ノード・マネージャのログ・ファイル・ローテーション・プロパティ

プロパティ 説明 デフォルト

FileSizeKB

このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。

ログ・ファイル・ローテーションの値を調整するには、サーバーLogFileMBeanを使用するか、Coherenceおよびシステム・コンポーネントの場合は、表2-3process.FileSizeKBを使用します。

500

FileTimeSpan

このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。

ログ・ファイル・ローテーションの値を調整するには、サーバーLogFileMBeanを使用するか、Coherenceおよびシステム・コンポーネントの場合は、表2-3process.FileTimeSpanを使用します。

24

FileTimeSpanFactor

このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。

ログ・ファイル・ローテーションの値を調整するには、サーバーLogFileMBeanを使用するか、Coherenceおよびシステム・コンポーネントの場合は、表2-3process.FileTimeSpanFactorを使用します。

360000

NumberOfFilesLimited

このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。

ログ・ファイル・ローテーションの値を調整するには、サーバーLogFileMBeanを使用するか、Coherenceおよびシステム・コンポーネントの場合は、表2-3process.NumberOfFilesLimitedを使用します。

true

RotatedFileCount

このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。

ログ・ファイル・ローテーションの値を調整するには、サーバーLogFileMBeanを使用するか、Coherenceおよびシステム・コンポーネントの場合は、表2-3process.RotatedFileCountを使用します。

7

RotationTimeStart

このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。

ログ・ファイル・ローテーションの値を調整するには、サーバーLogFileMBeanを使用するか、Coherenceおよびシステム・コンポーネントの場合は、表2-3process.RotationTimeStartを使用します。

00:00

RotationType

このプロパティはWebLogic Server 12.1.3.0で非推奨となり、将来のリリースで削除される可能性があります。

ログ・ファイル・ローテーションの値を調整するには、サーバーLogFileMBeanを使用するか、Coherenceおよびシステム・コンポーネントの場合は、表2-3process.RotationTypeを使用します。

SIZE


表2-3 ノード・マネージャのログ・ファイル・ローテーション・プロパティ(Coherenceおよびシステム・コンポーネント)

プロパティ 説明 デフォルト

process.FileSizeKB

ファイルの最大サイズを指定します。このサイズに達するとファイルがローテーションされます。

500

process.FileTimeSpan

古いログ・メッセージを別のファイルに保存する間隔(単位は時間)です。process.RotationTypeTIMEを指定する必要があります。

24

process.FileTimeSpanFactor

ログ・ローテーションを別の頻度でテストできるようになります。

注意: このプロパティの変更や設定が必要になることはほとんどありません。

360000

process.NumberOfFilesLimited

古いメッセージを保存するためにこのサーバー・インスタンスが作成するファイルの数を制限するかどうかを示します。process.RotationTypeSIZEまたはTIMEを指定する必要があります。この上限に達すると、サーバー・インスタンスは最も古いログ・ファイルを削除し、最新の接尾辞を付けた新しいログ・ファイルを作成します。このオプションを有効にしない場合、新しいファイルが無限に作成されていくため、管理者が必要に応じてこれらのファイルを削除する必要があります。

true

process.RotatedFileCount

process.NumberOfFilesLimited=trueのときに、保持するローテーション・ファイルの最大数を指定します。

7

process.RotationTimeStart

時間ベースのローテーション順序の開始時間(時間および分)を指定します。この値で指定された時刻に、現在のログ・ファイルの名前が変更されます。それ以後は、process.FileTimeSpanで指定した間隔でログ・ファイル名が変更されます。WebLogic Serverでは、ログ・ファイルが大きくなり過ぎないように、500MBのしきい値サイズ制限を設定しており、それを超えると強制的にローテーションが行われます。H:mmの形式を使用します。Hは1日の時間数(0-23)で、mm1時間の分数です。

00:00

process.RotationType

古いログ・メッセージを別のファイルに移動するための基準を指定します。

  • NONE: メッセージは1つのファイルに蓄積されます。サイズが大きくなり過ぎた場合、ファイルの内容を消去する必要があります。WebLogic Serverでは、ログ・ファイルが大きくなり過ぎないように、500MBのしきい値サイズ制限を設定しており、それを超えると強制的にローテーションが行われます。

  • SIZE: ログ・ファイルのサイズがFileMinSizeで指定された値に達すると、ファイル名がSERVER_NAME.lognnnnnに変更されます。

  • TIME: FileTimeSpanで指定された時間が経過するたびに、ファイル名がSERVER_NAME.lognnnnnに変更されます。

SIZE