![]() ![]() ![]() ![]() |
以下の節では、ノード マネージャの機能、アーキテクチャ、およびコンフィグレーション手順について説明します。
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 を使用するようにコンフィグレーションされたネットワーク上でサーバをリモート管理できることです。サーバを追加でインストールする必要はありません。スクリプトをリモート マシンにコピーするだけです。
注意 : | スクリプトベースのノード マネージャは、オペレーティング システムのサービスとして実行することをお勧めします。これにより、システムの再起動時にノード マネージャを自動的に再起動できるようになります。 |
どのバージョンのノード マネージャを使用するかは、お使いの WebLogic Server 環境の要件によって異なります。現在の環境に最適なバージョンを判断する際は、以下の点を考慮してください。
inetd
と組み合わせて使用できます。inetd
を使用すると、コンフィグレーションされたポートでリクエストを受信したときにノード マネージャを自動的に再起動できます。
ノード マネージャ クライアントは、通信するノード マネージャのローカルにあってもリモートにあってもかまいません。以下のクライアントから、Java バージョンまたはスクリプトベース (SSH) バージョンのいずれかのノード マネージャにアクセスします。さらに、スクリプトベースのノード マネージャを使用する場合には、シェル コマンド テンプレート形式の SSH クライアントが提供されます。
以下の節では、基本的なノード マネージャの機能について説明します。
WebLogic Scripting Tool (またはスクリプトベースのノード マネージャを使用する場合のみ SSH クライアント) を使用して、管理サーバをホストするマシン上のノード マネージャ プロセスに接続し、管理サーバを起動、停止、または再起動するためのコマンドを発行します。管理サーバとノード マネージャの関係は、シナリオに応じて異なります。
WebLogic Server Scripting Tool (WLST) コマンドラインまたはスクリプトを使用してノード マネージャにコマンドを発行し、管理対象サーバ インスタンスやクラスタを起動、停止、中断、および再起動できます。
ノード マネージャは、管理サーバにアクセスできない場合でも管理対象サーバ独立 (MSI) モードが有効になっていれば、管理対象サーバ インスタンスを障害後に再起動できます。デフォルトでは、これは有効になっています。
注意 : | ノード マネージャは、最初から MSI モードで管理対象サーバを起動することはできません。管理対象サーバが自身のコンフィグレーション設定を取得するには、ドメインの管理サーバにアクセスできなくてはならないからです。 |
注意 : | ノード マネージャは、スクリプトまたはコマンドラインで管理対象サーバを起動するときに指定するものと同じコマンド引数を使用します。起動引数の詳細については、『WebLogic Server コマンド リファレンス』の「weblogic.Server コマンドライン リファレンス」を参照してください。 |
ノード マネージャを使用して起動されたサーバ インスタンスに障害が発生した場合、ノード マネージャはそのインスタンスを自動的に再起動します。
注意 : | ノード マネージャは、ノード マネージャを使用して起動されたサーバのみを再起動できます。 |
再起動機能はコンフィグレーション可能です。ノード マネージャのデフォルトの動作は、以下のとおりです。
ノード マネージャに障害が発生した場合や、ノード マネージャが明示的に停止された場合、ノード マネージャは再起動時に前回の終了時に制御下にあったサーバ インスタンスを判別します。ノード マネージャは必要に応じて障害の発生したサーバ インスタンスを再起動できます。
注意 : | ノード マネージャをオペレーティング システムのサービスとして実行することをお勧めします。これにより、ホスト マシンの再起動時にノード マネージャを自動的に再起動できるようになります。 |
ノード マネージャは、ノード マネージャ プロセスのログ ファイルと、自身が制御する各サーバ インスタンスのサーバ出力ログ ファイルを作成します。これらのログ ファイルは、サーバ インスタンスのログ ファイルと同様に Administration Console または WLST またはコマンドを使用して表示できます。
以下の節では、ノード マネージャがサーバとの通信に使用するプロセスの図および説明と合わせて、ノード マネージャの役割の WebLogic Server 環境における「全体像」を示します。
図 3-1 に、ノード マネージャ、そのクライアント、およびノード マネージャが制御するサーバ インスタンスの間の関係を示します。
図 3-2 に、ノード マネージャを使用して管理サーバを起動するプロセスを示します。
この節では、すでに管理サーバをインストールし、コンフィグレーション ウィザードを使用してドメイン ディレクトリを作成していることを前提としています。
ノード マネージャは、管理サーバをホストするマシン A で実行されています。スタンドアロンのノード マネージャ クライアントはリモートにあります。
起動コマンドは起動するドメインおよびサーバ インスタンスを特定し、Java ベースのノード マネージャの場合はノード マネージャ ユーザのユーザ名とパスワードを指定します。
注意 : | ユーザが以前にノード マネージャに接続したことがある場合には boot.properties ファイルが存在するので、ユーザはユーザ名とパスワードを指定する必要はありません。 |
nodemanager.domains
でドメイン ディレクトリをルックアップし、暗号化されたユーザ名とパスワードを格納するローカル ファイルを使用してユーザの資格を認証します。 config
ディレクトリからドメイン コンフィグレーションを取得します。
図 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
ディレクトリのローカル キャッシュを更新します。注意 : | デフォルトでは、管理対象サーバ独立モードは有効になっています。 |
図 3-6 に、ノード マネージャの制御下にある管理対象サーバを停止する中で行われる通信を示します。管理対象サーバの状態と可用性によっては、ノード マネージャは別の方法で停止を始める必要があります。
ノード マネージャは、管理対象サーバ 1 をホストするマシン B で実行されています。
システム クラッシュの後に、ノード マネージャによってサーバが確実に再起動されるようにするには、以下を実行する必要があります。
システムの再起動後、ノード マネージャは nodemanager.domains ファイルで指定された各管理対象ドメインをチェックして、停止に問題のあったサーバ インスタンスがあるかどうかを判断します。これは、WebLogic Server プロセスの作成時にノード マネージャによって作成されたロック ファイルが存在するかどうかによって決まります。このロック ファイルには、WebLogic Server 起動スクリプトのプロセス識別子が含まれています。ロック ファイルが存在するが、プロセス ID が実行されていない場合、ノード マネージャは自動的にサーバを再起動しようとします。
プロセスが実行中であれば、ノード マネージャはさらにチェックを行ってプロセス内で実行されている管理サーブレットにアクセスし、プロセス ID に対応するプロセスが、WebLogic Server インスタンスであることを確認します。
注意 : | ノード マネージャがチェックを実行して管理サーブレットにアクセスする際、不適切な資格に関し、サーバ ログ内に警告が示されることがあります。 |
複数のサーバを管理する場合、ノード マネージャは、次の図に示すように複数のコンフィグレーション ファイルを使用し、複数のディレクトリにログ ファイルを出力します。これらのファイルの詳細については、「ノード マネージャのコンフィグレーション ファイルとログ ファイル」を参照してください。
以下の節では、ノード マネージャのコンフィグレーション ファイルとログ ファイルについて説明します。
言及されていない限り、コンフィグレーション ファイルは Java ベースのノード マネージャとスクリプトベースのノード マネージャの両方に適用されます。
Java ベースのノード マネージャによって使用されるコンフィグレーション ファイルです。「nodemanager.properties の検討」を参照してください。
このファイルは WL_HOME/common/nodemanager
にあります。
このファイルには、ノード マネージャによって管理されるドメインの名前と、それに対応するディレクトリのマッピングが格納されます。「nodemanager.domains ファイルのコンフィグレーション」を参照してください。
このファイルは WL_HOME/common/nodemanager
にあります。
このファイルには、ノード マネージャが対称暗号化キーを使用する暗号化データが格納されます。データは暗号化された形で保存されます。
このファイルは WL_HOME/common/nodemanager
にあります。
このファイルには、ノード マネージャのユーザ名とパスワードが格納されます。詳細については、「ノード マネージャのユーザ名とパスワードの指定」を参照してください。
このファイルは 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
は、サーバ インスタンスの名前です。
以下の方法で、特定のサーバ インスタンスに関するノード マネージャのログ ファイルを表示できます。
ノード マネージャが作成できるサーバ出力ログ数に制限はありません。
ノード マネージャによって作成されるログ ファイルとは別に、ノード マネージャの制御下にあるサーバ インスタンスには独自のログ ファイルがあります。
サーバ インスタンスの通常のログ ファイルを表示するには、[診断|ログ ファイル] を選択してサーバのログ ファイルを選択し、[表示] をクリックします。
この節では、ノード マネージャの一般的なコンフィグレーションについて説明します。この節の内容は、Java バージョンおよびスクリプト バージョンのノード マネージャに適用されます。以下の節に示す手順を実行する際は、必ずすべての手順項目を実施してください。
ノード マネージャの一般的なコンフィグレーションを実施した後は、使用するノード マネージャのバージョンに応じて、「Java ベースのノード マネージャのコンフィグレーション」または「スクリプトベースのノード マネージャのコンフィグレーション」のコンフィグレーション手順を実施する必要があります。
ノード マネージャは、ノード マネージャを使用して制御する WebLogic Server インスタンスをホストするコンピュータごとに実行する必要があります。WebLogic Server で各コンピュータを 1 つのマシンとしてコンフィグレーションし、ノード マネージャを使用して制御する各サーバ インスタンスを、ノード マネージャが実行されるマシンに割り当てます。
理想としては、システム障害の発生時や再起動時にノード マネージャが自動的に再起動されるように、ノード マネージャはオペレーティング システムのサービスまたはデーモンとして実行する必要があります。詳細については、『インストール ガイド』の「Windows サービスとしてのノード マネージャのインストール」を参照してください。
ノード マネージャは、ノード マネージャと管理サーバを同じマシンで実行し、デモ用の SSL コンフィグレーションを使用するのであれば、WebLogic Server のインストール後すぐに実行することができます。デフォルトでは、以下の動作がコンフィグレーションされます。
WebLogic Scripting Tool (WLST) は、システム管理者やオペレータが、WebLogic Server インスタンスおよびドメインのモニタと管理に使用する、コマンドライン スクリプト インタフェースです。WLST をノード マネージャ クライアントとして使用することで、サーバ インスタンスをリモートまたはローカルで起動、停止、および再起動できます。加えて、WLST ではサーバのステータスを取得し、サーバの出力ログの内容を取得できます。
デフォルトでは、nmConnect()
コマンドはプロダクション環境では使用できません。nmConnect
をプロダクション環境で使用するには次の手順を実行する必要があります。
nmEnroll()
を実行します。
nmEnroll('C:/bea/user_projects/domains/prod_domain',
'C:/bea/wlserver_10.0/common/nodemanager')
nmEnroll()
を実行すると、各管理対象サーバへ、確実に正しいノード マネージャのユーザおよびパスワード トークンが供給されます。これらが各管理対象サーバで使用可能になれば、nmConnect()
をプロダクション環境で使用できます。
注意 : | 管理対象サーバを実行している各マシン上で nmEnroll() を実行する必要があります。加えて、各マシン上の各ドメイン ディレクトリについて、nmEnroll() を実行することが必要です。 |
nm_password.properties ファイルには、ノード マネージャのユーザ名とパスワードが格納されます。ユーザ名とパスワードは、クライアント (たとえば管理サーバ) とノード マネージャの間の接続を認証するために使用します。
注意 : | このユーザ名とパスワードは、ノード マネージャとクライアントの間の接続の認証にのみ使用されます。サーバ管理用の ID およびパスワードとは無関係です。 |
このファイルは、ドメインの作成時に、nmEnroll() を使用して必要なコンフィグレーション ファイルをあるマシンから別のマシンにコピーしたときに作成されます。nm_password.properties が作成されたら、Administration Console を使用してノード マネージャのパスワードやプロパティの値を変更できます。変更は、nm_password.properties ファイルに伝播され、ノード マネージャによって使用されます。
注意 : | nm_password.properties を手動で編集した場合は、ノード マネージャを再起動して変更を有効にする必要があります。 |
nm_password.properties ファイルは、ノード マネージャを実行する物理マシンごとに存在していなければなりません。ただし、ノード マネージャのユーザ名とパスワードを、ドメイン内のすべてのマシンで一致させる必要はありません。
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-4 を参照してください。それらのデフォルトでも管理対象サーバを起動することができますが、起動プロセスの一貫性と信頼性を確保するためには、管理対象サーバ インスタンスごとに起動引数をコンフィグレーションします。
『インストール ガイド』の「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
) では、必須の変数が設定されます。
ノード マネージャは、オペレーティング システムのサービスとして、または 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
ファイルに対してユーザ名とパスワードを検証します。nm_password.properties の詳細については、「ノード マネージャのユーザ名とパスワードの指定」を参照してください。
ノード マネージャの資格は、[セキュリティ|全般|詳細] オプションのコンソール ページにあります。
Administration Console ユーザは、ノード マネージャに接続するための資格を明示的に指定する必要はありません。ノード マネージャ ユーザのユーザ名とパスワードはドメイン コンフィグレーションで使用可能であり、自動的に指定されます。
ノード マネージャを使用してサーバ インスタンスを起動するには、リモート起動ユーザのユーザ名とパスワードが必要です。管理サーバと管理対象サーバでは、これらの資格の指定方法が異なります。
ノード マネージャによって起動されたサーバ インスタンスでは、自動再起動に使用するために、サーバの起動に使用された資格が暗号化され、サーバ固有の boot.properties
ファイルに保存されます。
ノード マネージャ プロパティは、Java ベースのノード マネージャ プロセスのさまざまなコンフィグレーション設定を定義します。ノード マネージャ プロパティは、コマンドラインで指定することも、nodemanager.properties
ファイルで定義することもできます。nodemanager.properties ファイルは、WebLogic Server をインストールした後、最初にノード マネージャを起動したディレクトリに作成されます。コマンドラインで指定された値は、nodemanager.properties
の値をオーバーライドします。
nodemanager.properties
は、NodeManagerHome で指定されたディレクトリ内に作成されます。NodeManagerHome が定義されていなければ、nodemanager.properties はカレント ディレクトリ内に作成されます。
ノード マネージャを起動すると、そのたびにカレント ディレクトリ内に nodemanager.properties
が存在するかどうかが検索され、存在しない場合はこのファイルが作成されます。ノード マネージャを 1 回は起動しない限り、このファイルにはアクセスできません。
表 3-4 に、ノード マネージャのプロパティを示します。
多くの環境において、明示的に定義する必要のあるノード マネージャ プロパティは nodemanager.properties
の SSL 関連のプロパティのみです。ただし、nodemanager.properties
には、環境や設定によっては指定する必要のある、SSL 以外のプロパティも格納されます。次に例を示します。
StartScriptEnabled
プロパティおよび NativeVersionEnabled
プロパティを指定することが適当な場合もある。 ListenAddress
および ListenPort
を定義する。StartScriptName で指定されている起動スクリプトが使用される。詳細については、「起動および停止スクリプトを使用するためのノード マネージャのコンフィグレーション」を参照。
|
||||
true の場合、サーバ停止後に StopScriptName によって指定された停止スクリプトを実行する。詳細については、「起動および停止スクリプトを使用するためのノード マネージャのコンフィグレーション」を参照。
|
||||
|
||||
|
||||
|
||||
|
||||
|
この節では、WebLogic Server 9.x で非推奨になったノード マネージャ プロパティのリストを示します。
注意 : | これらのプロパティは下位互換性のために公開されているだけなので、使用しないでください。WebLogic Server 9.x に移行しても、SSL コンフィグレーションはそのまま機能します。ただし、ノード マネージャの実行中は信頼性のあるキーストアは使用されません。 |
スクリプトを使用して管理対象サーバを起動、またはサーバの停止が完了した後にスクリプトを実行するように、ノード マネージャをコンフィグレーションできます。これらのスクリプトは、サーバの起動前、またはサーバの停止後に実行する必要のあるタスクの実行に使用できます。スクリプトを使用して実行可能なタスクの一例としては、リモート ディスクのマウントおよびアンマウントがあります。
注意 : | ノード マネージャは起動スクリプトを使用して、任意の必要なコンフィグレーションを実行し、その後サーバを起動します。対照的に、停止スクリプトはサーバの停止後に実行されます。 |
起動スクリプトを使用すると、必要な起動プロパティの指定、および起動時に実行が必要なその他の任意の作業の実行ができます。起動スクリプトを定義するには、次の手順を行います。
停止スクリプトを使用すると、サーバ停止後に必要となる任意のタスクを実行できます。停止スクリプトを定義するには、次の手順を行います。
次の例では、UNIX システムでディスクのアンマウントに使用できる停止スクリプトを示します。
#!/bin/sh
FS=/cluster/d2
if grep $FS /etc/mnttab > /dev/null 2>&1 ; then
sync
PIDS=`/usr/local/bin/lsof $FS | awk
'{if ($2 ~/[0-9]+/) { print $2} }' | sort -u`
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 コマンドを使用すると、必要なすべてのドメイン情報およびコンフィグレーション情報をマシン間でコピーできます。詳細については、「WLST を使用したノード マネージャの制御およびコンフィグレーション」および『WebLogic Scripting Tool ガイド』の「nmEnroll()」を参照してください。
inetd
または xinetd
サービスとして実行するようにノード マネージャをコンフィグレーションする場合は、以下の考慮事項が適用されます。
以下の例では、xinetd
内にノード マネージャをコンフィグレーションする方法を示します。
# default: off
# description:nodemanager as a service
service nodemgrsvc
{
type = UNLISTED
disable = no
socket_type = stream
protocol = tcp
wait = yes
user = <username>
port = 5556
flags = NOLIBWRAP
log_on_success += DURATION HOST USERID
server = <path-to-jave>/java
env = CLASSPATH=<cp> LD_LIBRARY_PATH=<ldpath>
server_args = -client -DNodeManagerHome=<NMHome> <java options>
<nodemanager options> weblogic.NodeManager -v
}
SSH ノード マネージャは、{WL_HOME}/common/bin/
にあるシェル スクリプト wlscontrol.sh
です。wlscontrol.sh
は、ノード マネージャを使用して制御するサーバ インスタンスをホストするマシンごとに存在していなければなりません。このスクリプトは、サイト固有の要件を満たすようにカスタマイズできます。
ノード マネージャまたはノード マネージャ クライアントを実行するマシンごとに SSH クライアントが実行可能でなければなりません。また、このスクリプトはユーザ ID が実行するパス内になければなりません。通常、SSH クライアントは Unix または Linux インストールの標準的な一部です。
以下の節では、スクリプトベースのノード マネージャのコンフィグレーション方法について説明します。
ノード マネージャを実行する前に、ノード マネージャ機能の実行専用の UNIX ユーザ アカウントを作成する必要があります。このユーザは、SSH のノード マネージャをホストするすべてのマシンと、ノード マネージャ クライアント (管理サーバを含む) をホストするすべてのマシンに追加しなければなりません。
ノード マネージャで使用されるデフォルトの SSH ポートは 22 です。この設定は、以下の方法でオーバーライドできます。
ノード マネージャの SSH シェル スクリプトは、異なるマシン上のユーザ間のセキュアな信頼関係を提供する、SSH ユーザベースのセキュリティに依存します。認証は必要ありません。ノード マネージャのコマンドおよびスクリプトを実行するための UNIX ユーザ アカウントを作成します (通常はドメインごとに 1 つ)。このユーザとしてログインしたユーザは、ユーザ名とパスワードを指定しなくてもノード マネージャ コマンドを発行できます。
注意 : | ノード マネージャ コマンドと WebLogic Server コマンドが、コマンドの実行に使用される UNIX ユーザ ID のパスで使用可能になっていることを確認する必要もあります。 |
サーバの移行や他のタスクを実行するには、wlscontrol.sh などのスクリプトを実行するユーザ ID に十分なセキュリティ パーミッションが必要です。たとえば、ネットワーク インタフェースを通じて IP アドレスをオンラインにしたり、オフラインにしたりできるパーミッションなどです。
サーバの移行は、サーバに障害が発生したことを検出したときに、クラスタ マスターによって実行されます。クラスタ マスターは SSH を使用して対象のマシンにあるスクリプトを起動し、移行を開始します。対象のマシンにあるスクリプトは、クラスタのマスター上でサーバを実行しているのと同じユーザ ID で実行されます。
サーバの移行を実行するために必要なコマンドは ifconfig と arping です。これらのスクリプトには高度な OS 権限が必要になるため、セキュリティ ホールの可能性を防止できる点に留意することが重要です。
sudo を使用すると、高度な権限による ifconfig と arping の実行のみを許可するように SSH をコンフィグレーションできます。
ノード マネージャを使用してサーバ インスタンスを起動するには、リモート起動ユーザのユーザ名とパスワードが必要です。管理サーバと管理対象サーバでは、これらの資格の指定方法が異なります。
ノード マネージャによって起動されたサーバ インスタンスでは、自動再起動に使用するために、サーバの起動に使用された資格が暗号化され、サーバ固有の boot.properties
ファイルに保存されます。
スクリプトベースのノード マネージャでは、2 種類のキーと値のペアが使用されます。この節では、キーと値のペアをノード マネージャのクライアントまたはサーバをホストするマシンに配布する手順について説明します。
このオプションでは、同じキーと値のペアをノード マネージャのクライアントまたはサーバをホストするすべてのマシンに配布します。
最も簡単な方法は、ノード マネージャ ユーザのホーム ディレクトリを各マシンにマウントするようにするように LAN を設定することです。これにより、キーと値のペアがすべてのマシンで使用可能になります。この方法を使用しない場合は、次の手順を行います。
ssh-keygen
コマンドを使用して、ユーザの RSA キー値ペアを生成します。
プライベート キーと公開鍵のデフォルトの場所はそれぞれ、~/.ssh/id_rsa
と ~/.ssh/id_rsa.pub
です。
これらのキーが異なる場所に格納されている場合は、ssh
コマンドにオプションを追加してキーの場所を指定するように ShellCommand
テンプレートを変更します。
~/.ssh/authorized_keys
ファイルに公開鍵を追加します。次に例を示します。
command="/home/bea/server90/common/nodemanager/nodemanager.sh" 1024 33 23...2323
ここで、例で示した次の文字列を、id_rsa.pub
に格納されている生成した公開鍵で置き換えます。
注意 : | プレフィックス command=<command> は、公開鍵を使用してマシンとのセッションを確立するユーザが nodemanager.sh で指定されたコマンドしか実行できないことを保証しています。これによりユーザはノード マネージャ機能を実行するだけになり、データ、システム ユーティリティなどのマシン上のリソースへの権限のないアクセスが防止されます。 |
/home/bea$ ssh montgomery VERSION
ノード マネージャ クライアントをホストするマシンごとに、次の手順を行います。
以下の節では、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
] w
eblogic.NodeManager
java_option
は、java
実行可能ファイルの直接引数 (-ms
や -mx
など)。 注意 : | CLASSPATH 環境変数を設定しなかった場合、-classpath オプションを使用して必須のノード マネージャ クラスを指定します。 |
nodemanager_property
は、ノード マネージャ プロパティ。ノード マネージャ プロパティ値をコマンドラインで指定する代わりに、ノード マネージャを起動するディレクトリにインストールされている nodemanager.properties
ファイルを編集できます。詳細については、表 3-4 を参照してください。
nodemanager.properties
の値は、コマンドラインで指定するノード マネージャ プロパティ値によってオーバーライドされます。
server_property
は、ノード マネージャがコマンドラインで受け付ける、サーバ レベルのプロパティ。以下のプロパティがあります。注意 : | UNIX システムの場合 : |
注意 : | 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-6 に示します。使用可能なパラメータ値を、表 3-7 に示します。
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
にすると、コンソールから読み込もうとするときにクライアントがハングします。
ノード マネージャを停止するには、それが実行されているコマンド シェルを閉じます。
![]() ![]() ![]() |