サーバの起動と停止の管理
|
 |
 |
|
以下の節では、ノード マネージャの機能、アーキテクチャ、およびコンフィグレーション手順について説明します。
WebLogic Server のプロダクション環境では、サーバ インスタンスが複数のドメイン、マシン、および地理的な場所にまたがって分散することがよくあります。ノード マネージャは、離れた場所から管理サーバ インスタンスや管理対象サーバ インスタンスを起動、停止、および再起動できる WebLogic Server 付属のユーティリティです。ノード マネージャは任意指定の機能ですが、高可用性が要求されるアプリケーションを WebLogic Server 環境でホストする場合には使用することをお勧めします。
ノード マネージャ プロセスは、特定の WebLogic ドメインではなく、マシンに関連付けられます。サーバ インスタンスがノード マネージャ プロセスと同じマシン上に存在している限り、同じノード マネージャ プロセスを使用して任意の WebLogic Server ドメインのサーバ インスタンスを制御できます。ノード マネージャは、ノード マネージャを使用して制御する WebLogic Server インスタンス (管理サーバまたは管理対象サーバ) をホストするコンピュータごとに実行する必要があります。
WebLogic Server には、Java ベースのノード マネージャとスクリプトベースのノード マネージャという、同じような機能を持つ 2 つのバージョンのノード マネージャが用意されています。ただし、それぞれのバージョンでは、コンフィグレーションとセキュリティに関する考慮事項が異なっています。
Java ベースのノード マネージャは、Java 仮想マシン (JVM) プロセスで動作します。ノード マネージャは、Windows プラットフォームでは Windows サービスとして、UNIX プラットフォームではオペレーティング システムのサービスとして実行することをお勧めします。これにより、システムの再起動時にノード マネージャを自動的に再起動できるようになります。
BEA では、Windows、Solaris、HP UX、Linux on Intel、Linux on Z-Series、および AIX オペレーティング システム用のネイティブ ノード マネージャ ライブラリを提供しています。
注意 : ノード マネージャは、Open VMS、OS/390、AS400、UnixWare、または Tru64 UNIX ではサポートされていません。
このバージョンのノード マネージャのコンフィグレーションは、nodemanager.properties ファイルで指定されます。「Java ベースのノード マネージャのコンフィグレーション」を参照してください。
Java ベースのノード マネージャは、スクリプトベースのノード マネージャよりセキュリティ面で優れています。「Java ベースのノード マネージャのセキュリティのコンフィグレーション」を参照してください。
UNIX および Linux システムに対しては、スクリプトベース バージョンのノード マネージャが提供されます。このスクリプトは UNIX シェル スクリプトに基づいていますが、セキュリティ向上のために SSH を使用します。SSH ではユーザ ID ベースのセキュリティが使用されます。
スクリプト バージョンのノード マネージャのコンフィグレーションについては、「スクリプトベースのノード マネージャのコンフィグレーション」を参照してください。このバージョンのノード マネージャの使い方については、「スクリプトベースのノード マネージャの実行」を参照してください。
このバージョンのノード マネージャでは、Java ベースのノード マネージャほどのセキュリティは提供されません。しかし、スクリプトベースのノード マネージャの利点は、SSH を使用するようにコンフィグレーションされたネットワーク上でサーバをリモート管理できることです。サーバを追加でインストールする必要はありません。スクリプトをリモート マシンにコピーするだけです。
注意 : スクリプトベースのノード マネージャは、オペレーティング システムのサービスとして実行することをお勧めします。これにより、システムの再起動時にノード マネージャを自動的に再起動できるようになります。
ノード マネージャ クライアントは、通信するノード マネージャのローカルにあってもリモートにあってもかまいません。以下のクライアントから、Java バージョンまたはスクリプトベース (SSH) バージョンのいずれかのノード マネージャにアクセスします。さらに、スクリプトベースのノード マネージャを使用する場合には、シェル コマンド テンプレート形式の SSH クライアントが提供されます。
以下の節では、基本的なノード マネージャの機能について説明します。
WebLogic Scripting Tool (またはスクリプトベースのノード マネージャを使用する場合のみ SSH クライアント) を使用して、管理サーバをホストするマシン上のノード マネージャ プロセスに接続し、管理サーバを起動、停止、または再起動するためのコマンドを発行します。管理サーバとノード マネージャの関係は、シナリオに応じて異なります。
WebLogic Server Scripting Tool (WLST) コマンドラインまたはスクリプトを使用してノード マネージャにコマンドを発行し、管理対象サーバ インスタンスやクラスタを起動、停止、中断、および再起動できます。
ノード マネージャは、管理サーバにアクセスできない場合でも管理対象サーバ独立 (MSI) モードが有効になっていれば、管理対象サーバ インスタンスを障害後に再起動できます。デフォルトでは、MSI モードは有効になっています。
注意 : ノード マネージャは、最初から MSI モードで管理対象サーバを起動することはできません。管理対象サーバが自身のコンフィグレーション設定を取得するには、ドメインの管理サーバにアクセスできなくてはならないからです。
注意 : ノード マネージャは、スクリプトまたはコマンドラインで管理対象サーバを起動するときに指定するものと同じコマンド引数を使用します。起動引数の詳細については、『WebLogic Server コマンド リファレンス』の「weblogic.Server コマンドライン リファレンス」を参照してください。
ノード マネージャを使用して起動されたサーバ インスタンスに障害が発生した場合、ノード マネージャはそのインスタンスを自動的に再起動します。
注意 : ノード マネージャは、ノード マネージャを使用して起動されたサーバのみを再起動できます。
再起動機能はコンフィグレーション可能です。ノード マネージャのデフォルトの動作は、以下のとおりです。
startup.properties ファイルで RestartMax プロパティを設定して定義します。ノード マネージャに障害が発生した場合や、ノード マネージャが明示的に停止された場合、ノード マネージャは再起動時に前回の終了時に制御下にあったサーバ インスタンスを判別します。ノード マネージャは必要に応じて障害の発生したサーバ インスタンスを再起動できます。
注意 : ノード マネージャをオペレーティング システムのサービスとして実行することをお勧めします。これにより、ホスト マシンの再起動時にノード マネージャを自動的に再起動できるようになります。
ノード マネージャは、ノード マネージャ プロセスのログ ファイルと、自身が制御する各サーバ インスタンスのサーバ出力ログ ファイルを作成します。これらのログ ファイルは、サーバ インスタンスのログ ファイルと同様に Administration Console または WLST またはコマンドを使用して表示できます。
以下の節では、ノード マネージャがサーバとの通信に使用するプロセスの図および説明と合わせて、ノード マネージャの役割の WebLogic Server 環境における「全体像」を示します。
図 3-1 に、ノード マネージャ、そのクライアント、およびノード マネージャが制御するサーバ インスタンスの間の関係を示します。
図 3-1 WebLogic Server 環境でのノード マネージャ
図 3-2 に、ノード マネージャを使用して管理サーバを起動するプロセスを示します。
この節では、すでに管理サーバをインストールし、コンフィグレーション ウィザードを使用してドメイン ディレクトリを作成していることを前提としています。
ノード マネージャは、管理サーバをホストするマシン A で実行されています。スタンドアロンのノード マネージャ クライアントはリモートにあります。
図 3-3 に、ノード マネージャを使用して管理対象サーバを起動するプロセスを示します。
ノード マネージャは、管理対象サーバ 1 をホストするマシン B で実行されています。ドメインの管理サーバはマシン A で実行されています。
注意 : スタンドアロン クライアントは、管理対象サーバの起動コマンドを発行することもできます。
図 3-4 に、ノード マネージャを使用して管理サーバを再起動するプロセスを示します。
ノード マネージャは、管理サーバをホストするマシンで実行されています。ノード マネージャを使用して最初に起動された管理サーバはすでに終了しています。管理サーバの AutoRestart 属性は true に設定されています。
注意 : サーバ インスタンスの AutoRestart 属性が false に設定されている場合、ノード マネージャはそのインスタンスを再起動しません。
図 3-5 に、ノード マネージャを使用して管理対象サーバを再起動するプロセスを示します。
ノード マネージャは、管理対象サーバ 1 をホストするマシン B で実行されています。ノード マネージャを使用して最初に起動された管理対象サーバ 1 はすでに終了しています。管理対象サーバ 1 の AutoRestart 属性は true に設定されています。
注意 : サーバ インスタンスの AutoRestart 属性が false に設定されている場合、ノード マネージャはそのインスタンスを再起動しません。
boot.properties ファイルから管理対象サーバ 1 の起動に使用するユーザ名とパスワードを取得し、startup.properties ファイルからサーバの起動プロパティを取得します。これらのサーバ固有のファイルは、管理対象サーバ 1 のサーバ ディレクトリにあります。注意 : ノード マネージャは、サーバ インスタンスに障害が発生した後から RestartDelaySeconds で指定された秒数待機してから再起動を行います。
config ディレクトリのローカル キャッシュを更新します。ノード マネージャでは、管理対象サーバについて独自の内部的な状態が定義されています。これらはサーバの再起動時に使用されます。ノード マネージャが管理対象サーバを再起動するようにコンフィグレーションされている場合は、再起動プロセス中に Administration Console に以下の状態が示されます。
FAILED_RESTARTING - ノード マネージャが障害の発生した管理対象サーバを再起動していることを示します。FAILED_NOT_RESTARTABLE - 管理対象サーバで障害が発生したか、または管理対象サーバの AutoKillIfFailed 属性が True に設定されている結果として管理対象サーバがノード マネージャによって強制停止されたが、AutoRestart 属性が False に設定されているためにノード マネージャが管理対象サーバを再起動できないことを示します。 図 3-6 に、ノード マネージャの制御下にある管理対象サーバを停止する中で行われる通信を示します。管理対象サーバの状態と可用性によっては、ノード マネージャは別の方法で停止を始める必要があります。
ノード マネージャは、管理対象サーバ 1 をホストするマシン B で実行されています。
図 3-6 ノード マネージャの制御下にあるサーバ インスタンスの停止
CrashRecoveryEnabled コンフィグレーション プロパティを使用すると、ノード マネージャはシステム クラッシュから回復できます。このプロパティはデフォルトで有効になっています。
システムの再起動後、ノード マネージャは nodemanager.domains ファイルで指定された各管理対象ドメインをチェックして、停止に問題のあったサーバ インスタンスがあるかどうかを判断します。これは、WebLogic Server プロセスの作成時にノード マネージャによって作成されたロック ファイルが存在するかどうかによって決まります。このロック ファイルには、WebLogic Server 起動スクリプトのプロセス識別子が含まれています。ロック ファイルが存在するが、プロセス ID が実行されていない場合、ノード マネージャは自動的にサーバを再起動しようとします。
プロセスが実行中であれば、ノード マネージャはさらにチェックを行ってプロセス内で実行されている管理サーブレットにアクセスし、プロセス ID に対応するプロセスが、WebLogic Server インスタンスであることを確認します。
注意 : ノード マネージャがチェックを実行して管理サーブレットにアクセスする際、不適切な資格に関し、サーバ ログ内に警告が示されることがあります。
複数のサーバを管理する場合、ノード マネージャは、次の図に示すように複数のコンフィグレーション ファイルを使用し、複数のディレクトリにログ ファイルを出力します。これらのファイルの詳細については、「ノード マネージャのログ ファイルとコンフィグレーション ファイル」を参照してください。
図 3-7 ノード マネージャのコンフィグレーションとロギングの環境
ノード マネージャは、ノード マネージャを使用して制御する WebLogic Server インスタンスをホストするコンピュータごとに実行する必要があります。WebLogic Server で各コンピュータを 1 つのマシンとしてコンフィグレーションし、ノード マネージャを使用して制御する各サーバ インスタンスを、ノード マネージャが実行されるマシンに割り当てます。
理想的には、システム障害の発生時や再起動時にノード マネージャが自動的に再起動されるように、ノード マネージャはオペレーティング システムのサービスまたはデーモンとして実行する必要があります。詳細については、『インストール ガイド』の「Windows サービスとしてのノード マネージャのインストール」を参照してください。
ノード マネージャは、ノード マネージャと管理サーバを同じマシンで実行し、デモ用の SSL コンフィグレーションを使用するのであれば WebLogic Server のインストール後すぐに実行することができます。デフォルトでは、以下の動作がコンフィグレーションされます。
以下の節では、ノード マネージャのコンフィグレーション情報について説明します。
WebLogic Scripting Tool (WLST) は、システム管理者やオペレータが、WebLogic Server インスタンスおよびドメインのモニタと管理に使用する、コマンドライン スクリプト インタフェースです。WLST をノード マネージャ クライアントとして使用することで、サーバ インスタンスをリモートまたはローカルで起動、停止、および再起動できます。加えて、WLST ではサーバのステータスを取得し、サーバの出力ログの内容を取得できます。WLST を使用したノード マネージャの制御の詳細については、『WebLogic Scripting Tool ガイド』の「WLST とノード マネージャを使用したサーバ管理」を参照してください。
デフォルトでは、nmConnect() コマンドはプロダクション環境では使用できません。nmConnect をプロダクション環境で使用するには次の手順を実行する必要があります。
nmEnroll('C:/bea/wls900/user_projects/domains/prod_domain',
'C:/bea/wls900/weblogic90/common/nodemanager')
nmEnroll() を実行すると、各管理対象サーバへ、確実に正しいノード マネージャのユーザおよびパスワード トークンが供給されます。これらが各管理対象サーバで使用可能になれば、nmConnect() をプロダクション環境で使用できます。
注意 : 管理対象サーバを実行している各マシン上で nmEnroll() を実行する必要があります。加えて、各マシン上の各ドメイン ディレクトリについて、nmEnroll() を実行することが必要です。
ノード マネージャは、オペレーティング システムのサービスとして、または Windows システムでは Windows サービスとして実行するようにコンフィグレーションすることをお勧めします。デフォルトのオペレーティング システム サービスは、ノード マネージャを起動して localhost:5556 でリスンします。
リモート システムからのコマンドを受け付けるノード マネージャをコンフィグレーションする場合は、デフォルトのノード マネージャ サービスをアンインストールして、その後に localhost 以外のリスン アドレスでリスンするように再インストールします。
お使いのプラットフォームに応じて、「Windows インストール用の起動サービスの再コンフィグレーション」または「Java ベースのノード マネージャのセキュリティのコンフィグレーション」の説明に従ってください。
以下の節では、Java ベースのノード マネージャに固有のコンフィグレーション情報について説明します。
WL_HOME\server\bin ディレクトリ (WL_HOME は WebLogic Server の最上位のインストール ディレクトリ) には、ノード マネージャ サービスをアンインストールするための uninstallNodeMgrSvc.cmd スクリプト、およびノード マネージャをサービスとしてインストールするための installNodeMgrSvc.cmd スクリプトが格納されています。
ノード マネージャのセキュリティは、クライアントとサーバの間の一方向 SSL 接続に依存します。
WebLogic Server Scripting Tool (WLST) の nmConnect コマンドを使用して Java ベースのノード マネージャへのコマンドライン接続を確立する場合は、ノード マネージャ ユーザのユーザ名とパスワードを指定します。ノード マネージャは、ドメインの nm_password.properties ファイルに対してユーザ名とパスワードを検証します。
ノード マネージャの資格は、[セキュリティ｜全般｜詳細] オプションのコンソール ページにあります。
Administration Console ユーザは、ノード マネージャに接続するための資格を明示的に指定する必要はありません。ノード マネージャ ユーザのユーザ名とパスワードはドメイン コンフィグレーションで使用可能であり、自動的に指定されます。
ノード マネージャを使用してサーバ インスタンスを起動するには、リモート起動ユーザのユーザ名とパスワードが必要です。管理サーバと管理対象サーバでは、これらの資格の指定方法が異なります。
boot.properties ファイルから取得することもできる。コンフィグレーション ウィザードは、ドメインの作成時に管理サーバの boot.properties ファイルおよび startup.properties ファイルを初期化します。 ノード マネージャによって起動されたサーバ インスタンスでは、自動再起動に使用するために、サーバの起動に使用された資格が暗号化され、サーバ固有の boot.properties ファイルに保存されます。
ノード マネージャ プロパティは、Java ベースのノード マネージャ プロセスのさまざまなコンフィグレーション設定を定義します。ノード マネージャ プロパティは、コマンドラインで指定することも、nodemanager.properties ファイルで定義することもできます。nodemanager.properties ファイルは、WebLogic Server をインストールした後、最初にノード マネージャを起動したディレクトリに作成されます。コマンドラインで指定された値は、nodemanager.properties の値をオーバーライドします。
nodemanager.properties は、NodeManagerHome で指定されたディレクトリ内に作成されます。NodeManagerHome が定義されていなければ、nodemanager.properties は現在のディレクトリ内に作成されます。
ノード マネージャを起動すると、そのたびにカレント ディレクトリ内に nodemanager.properties が存在するかどうかが検索され、存在しない場合はこのファイルが作成されます。ノード マネージャを 1 回は起動しない限り、このファイルにはアクセスできません。
表 3-1 に、ノード マネージャのプロパティを示します。
多くの環境において、明示的に定義する必要のあるノード マネージャ プロパティは nodemanager.properties の SSL 関連のプロパティのみです。ただし、nodemanager.properties には、環境や設定によっては指定する必要のある、SSL 以外のプロパティも格納されます。次に例を示します。
StartScriptEnabled プロパティおよび NativeVersionEnabled プロパティを指定することが適当な場合もある。 ListenAddress および ListenPort を定義する。|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
スクリプトを使用して管理対象サーバを起動、またはサーバの停止が完了した後にスクリプトを実行するように、ノード マネージャをコンフィグレーションできます。これらのスクリプトは、サーバの起動前、またはサーバの停止後に実行する必要のあるタスクの実行に使用できます。スクリプトを使用して実行可能なタスクの一例としては、リモート ディスクのマウントおよびアンマウントがあります。
注意 : ノード マネージャは起動スクリプトを使用して、任意の必要なコンフィグレーションを実行し、その後サーバを起動します。対照的に、停止スクリプトはサーバの停止後に実行されます。
起動スクリプトを使用すると、必要な起動プロパティの指定、および起動時に実行が必要なその他の任意の作業の実行ができます。起動スクリプトを定義するには、次の手順を行います。
停止スクリプトを使用すると、サーバ停止後に必要となる任意のタスクを実行できます。停止スクリプトを定義するには、次の手順を行います。
次の例では、UNIX システムでディスクのアンマウントに使用できる停止スクリプトを示します。
#!/bin/sh
FS=/cluster/d2
if grep $FS /etc/mnttab > /dev/null 2>&1 ; then
sync
PIDS=\Q/usr/local/bin/lsof $FS | awk
'{if ($2 ~/[0-9]+/) { print $2} }' | sort -u\Q
kill -9 $PIDS
sleep 1
sync
/usr/sbin/umount -f $FS
fi
管理サーバと管理対象サーバは、一方向 SSL を使用して Java ベースのノード マネージャと通信します。
WebLogic Server のデフォルト インストールには、SSL をそのまま使用することを可能にするデモ用の ID キーストアおよび信頼キーストアが含まれています。それらのキーストア (DemoIdentity.jks および DemoTrust.jks) は、WL_HOME/server/lib にインストールされます。開発およびテスト目的の場合は、このキーストア コンフィグレーションで十分です。
プロダクション環境用の SSL のコンフィグレーションには、ノード マネージャと、ノード マネージャが通信する管理サーバおよび管理対象サーバのそれぞれの ID と信頼を取得してから、適切な ID と信頼を使って、ノード マネージャ、管理サーバ、および管理対象サーバをコンフィグレーションすることが必要です。また、ホスト名検証の使用と管理ポートを考慮に入れる必要があります。プロダクション用の SSL コンポーネントのコンフィグレーション方法については、『WebLogic Server のセキュリティ』の「SSL のコンフィグレーション」を参照してください。
管理対象サーバが複数の物理的なマシン上に配置されているドメインがある場合は、ノード マネージャが各マシンにインストールされ、コンフィグレーションされていることを確認する必要があります。WLST の nmEnroll コマンドを使用すると、必要なすべてのドメイン情報およびコンフィグレーション情報をマシン間でコピーできます。詳細については、『WebLogic Scripting Tool ガイド』の「nmEnroll」を参照してください。
この節では、WebLogic Server 9.x で非推奨になったノード マネージャ プロパティのリストを示します。
注意 : これらのプロパティは下位互換性のために公開されているだけなので、使用しないでください。WebLogic Server 9.x に移行しても、SSL コンフィグレーションはそのまま機能します。ただし、ノード マネージャの実行中は信頼キーストアは使用されません。以前のバージョンの WebLogic Server と同様に、ノード マネージャのプライベート キーは、ノード マネージャにアクセスするすべてのクライアント マシンの信頼性のあるキーストアに追加されなければなりません。
SSH ノード マネージャは、NodeManagerHome/ にあるシェル スクリプト wlscontrol.sh です。wlscontrol.sh は、ノード マネージャを使用して制御するサーバ インスタンスをホストするマシンごとに存在しなければなりません。このスクリプトは、サイト固有の要件を満たすようにカスタマイズできます。
ノード マネージャまたはノード マネージャ クライアントを実行するマシンごとに SSH クライアントが実行可能でなければなりません。通常、SSH クライアントは Unix または Linux インストールの標準的な一部です。
以下の節では、スクリプトベースのノード マネージャのコンフィグレーション方法について説明します。
ノード マネージャを実行する前に、ノード マネージャ機能の実行専用の UNIX ユーザ アカウントを作成する必要があります。このユーザは、SSH のノード マネージャをホストするすべてのマシンと、ノード マネージャ クライアント (管理サーバを含む) をホストするすべてのマシンに追加しなければなりません。
ノード マネージャで使用されるデフォルトの SSH ポートは 22 です。この設定は、以下の方法でオーバーライドできます。
~/.ssh/config ファイルで Port= パラメータを設定する。/etc/ssh_config ファイルで Port= パラメータを設定する。-Dweblogic.nodemanager.ShellCommand="ssh -o PasswordAuthentication=no -p %P %H wlscontrol.sh -d %D -r %R -s %S %C"
ノード マネージャの SSH シェル スクリプトは、異なるマシン上のユーザ間のセキュアな信頼関係を提供する、SSH ユーザベースのセキュリティに依存します。認証は必要ありません。ノード マネージャのコマンドおよびスクリプトを実行するための UNIX ユーザ アカウントを作成します (通常はドメインごとに 1 つ)。このユーザとしてログインしたユーザは、ユーザ名とパスワードを指定しなくてもノード マネージャ コマンドを発行できます。
ノード マネージャを使用してサーバ インスタンスを起動するには、リモート起動ユーザのユーザ名とパスワードが必要です。管理サーバと管理対象サーバでは、これらの資格の指定方法が異なります。
boot.properties ファイルから取得することもできる。コンフィグレーション ウィザードは、ドメインの作成時に管理サーバの boot.properties ファイルおよび startup.properties ファイルを初期化します。 ノード マネージャによって起動されたサーバ インスタンスでは、自動再起動に使用するために、サーバの起動に使用された資格が暗号化され、サーバ固有の boot.properties ファイルに保存されます。
スクリプトベースのノード マネージャでは、2 種類のキーと値のペアが使用されます。この節では、キーと値のペアをノード マネージャのクライアントまたはサーバをホストするマシンに配布する手順について説明します。
このオプションでは、同じキーと値のペアをノード マネージャのクライアントまたはサーバをホストするすべてのマシンに配布します。
最も簡単な方法は、ノード マネージャ ユーザのホーム ディレクトリを各マシンにマウントするようにするように LAN を設定することです。これにより、キーと値のペアがすべてのマシンで使用可能になります。この方法を使用しない場合は、次の手順を行います。
プライベート キーと公開鍵のデフォルトの場所はそれぞれ、~/.ssh/id_rsa と ~/.ssh/id_rsa.pub です。
これらのキーが異なる場所に格納されている場合は、ssh コマンドにオプションを追加してキーの場所を指定するように ShellCommand テンプレートを変更します。
command="/home/bea/server90/common/nodemanager/nodemanager.sh" 1024 33 23...2323
ここで、例で示した次の文字列を、id_rsa.pub に格納されている生成した公開鍵で置き換えます。
注意 : プレフィックス command=<command> は、公開鍵を使用してマシンとのセッションを確立するユーザが nodemanager.sh で指定されたコマンドしか実行できないことを保証しています。これによりユーザはノード マネージャ機能を実行するだけになり、データ、システム ユーティリティなどのマシン上のリソースへの権限のないアクセスが防止されます。
ノード マネージャ クライアントをホストするマシンごとに、次の手順を行います。
以下の節では、ノード マネージャのその他のコンフィグレーション情報について説明します。
WebLogic Server マシン リソースでは、特定のマシンとそれがホストするサーバ インスタンスを関連付け、そのシステム上のノード マネージャ プロセスの接続属性を指定します。
Administration Console の [環境｜マシン｜<machine_name>｜ノード マネージャ] ページを使用して、ノード マネージャ プロセスを実行するマシンごとにマシン定義をコンフィグレーションします。[リスン アドレス] ボックスに、ノード マネージャがリスンする DNS 名または IP アドレスを入力します。
nodemanager.domains ファイルには、ノード マネージャ インスタンスが制御するドメインを指定します。このため、スタンドアロンのクライアントではドメイン ディレクトリを明示的に指定する必要はありません。
このファイルには、ノード マネージャ インスタンスが制御する各ドメインのドメイン ディレクトリを次の形式で指定するエントリが含まれている必要があります。
<domain-name>=<domain-directory>
ユーザがドメインに対してコマンドを発行すると、ノード マネージャは nodemanager.domains からドメイン ディレクトリをルックアップします。
このファイルではノード マネージャ クライアントのアクセスがファイル内に表示されたドメインに制限されるので、セキュリティがさらに強化されます。クライアントは、nodemanager.domains に表示されたドメインに対してのみコマンドを実行できます。
コンフィグレーション ウィザードを使用してドメインを作成した場合には、nodemanager.domains ファイルは自動的に作成されています。必要に応じて、nodemanager.domains を手動で編集し、ドメインを追加できます。
注意 : nodemanager.domains でバックスラッシュ文字 (\) を使用している場合は、(\\) としてエスケープする必要があります。
管理対象サーバの [サーバ｜コンフィグレーション｜サーバの起動] ページで、ノード マネージャが管理対象サーバの起動に使用する起動引数を指定します。管理対象サーバの起動引数を指定しない場合、ノード マネージャは独自のプロパティをデフォルトとして使用して管理対象サーバを起動します。詳細については、表 3-1 を参照してください。それらのデフォルトでも管理対象サーバを起動することができますが、起動プロセスの一貫性と信頼性を確保するためには、管理対象サーバ インスタンスごとに起動引数をコンフィグレーションします。
『インストール ガイド』の「Windows サービスとしてのノード マネージャのインストール」に説明されているようにノード マネージャを Windows サービスとして実行する場合は、ノード マネージャの制御下に置かれる管理対象サーバごとに以下の JVM プロパティをコンフィグレーションする必要があります。
このオプションを設定しない場合、ノード マネージャはシステムの再起動後に管理対象サーバを再起動できません。それは、次のような一連のイベントが発生するためです。
-Xrs オプションまたは -Xnohup オプションを使用して管理対象サーバを起動すると、マシンの停止時に管理対象サーバを即座に停止しないようになり、このような一連のイベントが回避されます。
ノード マネージャを使用して、サーバの起動プロパティを設定できます。これらのプロパティは、startup.properties で定義することも、WLST などの管理ユーティリティを使用してオブジェクトとして渡すこともできます。起動プロパティと、その有効な値を設定する方法を、以下の節で概説します。
ノード マネージャは、startup.properties ファイルを使用して、サーバ起動時の起動とコンフィグレーションを決定します。このファイルは、サーバごとに定義されており、下記の場所に置かれています。
domain_home/servers/server_name/data/nodemanager/startup.properties
startup.properties の内容は、サーバ Mbean から派生するか、サーバがクラスタの一部である場合は、クラスタ MBean から派生します。詳細については、Mbean のリファレンスを参照してください。
WLST の nmStart() コマンドを使用する場合、サーバのコンフィグレーションは、直接決定することができません。したがって、サーバの起動プロパティを WLST プロパティ オブジェクトとして nmStart() コマンドに渡す必要があります。
以下のサーバの起動プロパティを、ノード マネージャを通じての起動時にサーバに渡すことができます。
ノード マネージャ プロセスに接続する各管理サーバのリスン アドレスを確実に定義する必要があります。管理サーバのリスン アドレスが定義されていない場合、ノード マネージャは、管理対象サーバの起動時に、その管理対象サーバに対して localhost にアクセスしてコンフィグレーション情報を取得するように指示します。
リスン アドレスは、Administration Console の [サーバ｜コンフィグレーション｜全般] ページで設定します。
ノード マネージャを起動する前に、ノード マネージャの環境変数を設定する必要があります。
コマンドラインでこれらの変数を手動で設定することもできますし、これらの変数を自動で設定する起動スクリプトを作成することもできます。WebLogic Server に付属のサンプル起動スクリプト (startNodeManager.cmd および startNodeManager.sh) では、必須の変数が設定されます。
以下の節では、Java ベースのノード マネージャとスクリプトベースのノード マネージャを起動および実行する方法について説明します。
起動サービスとして実行するようにノード マネージャをインストールすることをお勧めします。これにより、ノード マネージャはシステムが再起動するたびに自動的に起動できるようになります。
デフォルトでは、ノード マネージャはローカル ホストのみからリスンします。ノード マネージャでリモート システムからのコマンドを受け付けるようにする場合は、デフォルトのノード マネージャ サービスをアンインストールして、その後に localhost 以外のリスン アドレスでリスンするように再インストールします。
オペレーティング システム サービスとしてノード マネージャを実行することをお勧めしますが、コマンド プロンプトまたはスクリプトを使用してノード マネージャを手動で起動することもできます。ノード マネージャで必要な環境変数については「ノード マネージャの環境変数の設定」を参照してください。
ノード マネージャのサンプル起動スクリプトは、WL_HOME\server\bin ディレクトリにインストールされます。WL_HOME は、WebLogic Server の最上位のインストール ディレクトリです。Windows システムでは startNodeManager.cmd、UNIX システムでは startNodeManager.sh を使用します。
これらのスクリプトは必須の環境変数を設定し、WL_HOME/common/nodemanager でノード マネージャを起動します。ノード マネージャは、このディレクトリを出力とログ ファイルを格納するための作業ディレクトリとして使用します。別の作業ディレクトリを指定するには、テキスト エディタで起動スクリプトを編集し、NODEMGR_HOME 変数の値を目的のディレクトリに設定します。
サンプル起動スクリプトを編集して、コマンド修飾子で、ノード マネージャ プロセスの適切なリスン アドレスおよびポート番号が設定されるようにしてください。
Java ベースのノード マネージャを起動するための構文は次のとおりです。
java [java_option=value...]-D[nodemanager_property=value]-D[server_property=value] weblogic.NodeManager
java_option は、java 実行可能ファイルの直接引数 (-ms や -mx など)。 注意 : CLASSPATH 環境変数を設定しなかった場合、-classpath オプションを使用して必須のノード マネージャ クラスを指定します。
nodemanager_property は、ノード マネージャ プロパティ。ノード マネージャ プロパティ値をコマンドラインで指定する代わりに、ノード マネージャを起動するディレクトリにインストールされている nodemanager.properties ファイルを編集できます。詳細については、表 3-1 を参照してください。server_property は、ノード マネージャがコマンドラインで受け付ける、サーバ レベルのプロパティ。以下のプロパティがあります。Solaris または HP UX 以外の UNIX オペレーティング システム上でノード マネージャを実行する場合、ノード マネージャの起動時に java コマンドラインに渡すパラメータでスペースを使用することはできません。たとえば次のコマンドは、big iron にスペースが含まれているので無効です。
Solaris、HP UX、および Linux 以外の UNIX オペレーティング システムでは、ノード マネージャの起動時にコマンドラインで weblogic.nodemanager.nativeVersionEnabled オプションを無効にするか、または nodemanager.properties でプロパティを設定して、pure Java バージョンを使用する必要があります。詳細については、「nodemanager.properties の検討」を参照してください。
SSH ノード マネージャのコマンド シェルを使用するには、次のコマンドライン オプションを使用して、管理サーバを起動します。
-Dweblogic.nodemanager.ShellCommand='ssh -o PasswordAuthentication=no %H wlscontrol.sh -d %D -r %R -s %S %C'
weblogic.nodemanager.ShellCommand 属性には、リモートの SSH ノード マネージャとの通信と、制御下にあるサーバ インスタンスに対するノード マネージャ機能の実行に使用するコマンド テンプレートを指定します。
テンプレートは、ノード マネージャをホストしているリモート マシン上のデフォルトの検索パスに wlscontrol.sh があることを前提としています。
ssh -o PasswordAuthentication=no %H wlscontrol.sh -d %D -r %R -s %S %C'
使用可能なコマンドライン オプションを、表 3-4 に示します。使用可能なパラメータ値を、表 3-5 に示します。
ssh -o PasswordAuthentication=no wlscontrol.sh myserver start
SSH サーバのリスン アドレスとリスン ポートは、デフォルトではリモート マシン上のノード マネージャで使用されるリスン アドレスとリスン ポートになります。ドメイン名とドメイン ディレクトリは、対象となるサーバ インスタンス myserver に対して指定されているルート ディレクトリと見なされます。
ssh -o PasswordAuthentication=no 172.11.111.11 wlscontrol.sh -d ProductionDomain -r ProductionDomain -s ServerA'
domains/ProductionDomain ディレクトリにある ProductionDomain というドメインのサーバ インスタンス ServerA に START コマンドが発行されます。
SSH コマンドには、次の文字列が含まれていなければなりません。
-o PasswordAuthentication=no
この文字列によって、SSH PasswordAuthentication オプションが渡されます。値を yes にすると、コンソールから読み込もうとするときにクライアントがハングします。
表 3-4 wlscontrol.sh コマンドライン オプション
ノード マネージャを停止するには、それが実行されているコマンド シェルを閉じます。
以下の節では、ノード マネージャのコンフィグレーション ファイルとログ ファイルについて説明します。
言及されていない限り、コンフィグレーション ファイルは Java ベースのノード マネージャとスクリプトベースのノード マネージャの両方に適用されます。
Java ベースのノード マネージャによって使用されるコンフィグレーション ファイルです。「nodemanager.properties の検討」を参照してください。
このファイルは WL_HOME/common/nodemanager にあります。
このファイルには、ノード マネージャにコマンドを発行できる信頼性のあるホストのリストが格納されます。
このファイルは WL_HOME/common/nodemanager にあります。
このファイルには、ノード マネージャによって管理されるドメインの名前と、それに対応するディレクトリのマッピングが格納されます。「nodemanager.domains ファイルのコンフィグレーション」を参照してください。
このファイルは WL_HOME/common/nodemanager にあります。
このファイルには、ノード マネージャが対称暗号化キーを使用する暗号化データが格納されます。データは暗号化された形で保存されます。
このファイルは WL_HOME/common/nodemanager にあります。
このファイルには、対象のドメインを管理しているノード マネージャ サーバに固有のユーザ名とパスワードのペアが格納されます。ノード マネージャ秘密ファイルとも呼ばれます。ユーザ名とパスワードは、(ドメインの SerializedSystemIni.dat から取得された) Salt 値に付加され、SHA でハッシュ化されます。
このファイルは DOMAIN_HOME/config/nodemanager にあります。
ノード マネージャはこのファイルを使用して、サーバの起動時に起動 ID を指定します。「他のコンフィグレーション情報」を参照してください。
このファイルは domain-name/servers/server_name/data/nodemanager にあります。
各管理対象サーバ インスタンスには、ノード マネージャによるサーバの起動方法および管理方法を指定するプロパティが記載された、独自の startup.properties ファイルがあります。最後に管理サーバを使用してこのサーバを起動したときにノード マネージャに渡されたプロパティを使用して、ノード マネージャはこのファイルを自動的に作成します。これにより、ノード マネージャ クライアントまたは起動スクリプトは、管理サーバによって最後に使用されたものと同じプロパティを使用して管理対象サーバを再起動できるようになります。
startup.properties の詳細については、「サーバ起動プロパテイの設定」を参照してください。これらのプロパティは、ServerStartMBean のサーバ起動属性と ServerStartMBean の状態モニタ属性に対応しています。
このファイルは domain-name/servers/server_name/data/nodemanager にあります。
server_name.addr は、サーバが起動または移行される際に追加された IP アドレスを格納します。このファイルは、移行中にサーバ IP アドレスが正常にオンラインになった後に生成されます。IP アドレスがオフラインになると、server_name.addr は削除されます。サーバ IP アドレスは、サーバの停止中に、アドレスが誤って削除されてしまうことを回避するための、削除要求の検証に使用されます。
このファイルは domain-name/servers/server_name/data/nodemanager にあります。
サーバごとに生成される server_name.lck は、内部的に使用されるロック ID を格納します。
このファイルは domain-name/servers/server_name/data/nodemanager にあります。
サーバごとに生成される server_name.pid は、サーバのプロセス ID を格納します。ノード マネージャは、クラッシュ回復中、サーバによって生成されたプロセス ID をチェックします。
このファイルは domain-name/servers/server_name/data/nodemanager にあります。
サーバごとに生成される server_name.state は、サーバの現在の状態を格納します。ノード マネージャは、このファイルの内容をモニタして、サーバの現在の状態を判別します。
注意 : このファイルは削除も変更もしないでください。このファイルがないと、ノード マネージャはサーバの現在の状態を判別できません。
このファイルは domain-name/servers/server_name/data/nodemanager にあります。
個々の管理対象サーバの起動または停止に関する問題を解決するには、ノード マネージャおよび WebLogic Server のログ ファイルを利用します。
ノード マネージャは、NodeManagerHome/nodemanager.log にログ ファイルを作成します。このログ ファイルには、ノード マネージャによって管理されるすべてのドメインに関するデータが記載されます。
このログ ファイルは、ノード マネージャによって生成され、特定の物理的なマシン上でノード マネージャによって制御されるすべてのドメインに関するデータが格納されます。「nodemanager.log」を参照してください。
このファイルは WL_HOME/common/nodemanager にあります。
ログ出力は、現在の nodemanager.log に追加されます。ログ ローテーションはデフォルトでは無効になっていますが、nodemanager.properties で LogCount を設定することで有効にできます。
以下の方法で、ノード マネージャのログ ファイルを表示できます。
ノード マネージャは制御対象の各サーバ インスタンスについて、サーバ インスタンスで生成される stdout メッセージおよび stderr メッセージを格納するログ ファイルを保持します。サーバ インスタンスのリモート起動プロパティとしてリモート起動デバッグ プロパティが有効になっている場合や、ノード マネージャのデバッグ プロパティが有効になっている場合には、ノード マネージャによってサーバの出力ログ情報に未公開情報が追加されます。
注意 : ノード マネージャが作成するこのログ ファイルのサイズは制限できません。stdout へのロギングはデフォルトでは無効になっています。
このファイルは、domain_name/servers/<server_name>/logs にあります。
ノード マネージャによって、サーバ インスタンスの logs ディレクトリにそのサーバ インスタンスのサーバ出力ログが次の名前で作成されます。
server-name は、サーバ インスタンスの名前です。
以下の方法で、特定のサーバ インスタンスに関するノード マネージャのログ ファイルを表示できます。
ノード マネージャが作成できるサーバ出力ログ数に制限はありません。
ノード マネージャによって作成されるログ ファイルとは別に、ノード マネージャの制御下にあるサーバ インスタンスには独自のログ ファイルがあります。
サーバ インスタンスの通常のログ ファイルを表示するには、[診断｜ログ ファイル] を選択してサーバのログ ファイルを選択し、[表示] をクリックします。
次の表に、一般的なノード マネージャの問題とその解決方法を示します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|