Oracle® Fusion Middleware

Oracle WebLogic Serverノード・マネージャの管理

12c (12.2.1.2.0)

E82881-01(原本部品番号:E77981-02)

2016年11月

このドキュメントでは、WebLogic Server環境内でサーバーを制御および管理するためのノード・マネージャの構成と使用の方法について説明します。

Oracle Fusion Middleware Oracle WebLogic Server ノード・マネージャの管理, 12c (12.2.1.2.0)

E82881-01

Copyright © 2007, 2016, Oracle and/or its affiliates All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- このリリースでの新機能と変更された機能

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

- 概要

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

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

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

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

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

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

- Javaベースのノード・マネージャ

- スクリプト・ベースのノード・マネージャ

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

- ノード・マネージャへのアクセス

- WebLogic Server環境でのノード・マネージャの機能

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

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

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

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

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

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

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

- ノード・マネージャの構成ファイルとログ・ファイル

- 構成ファイル

- nodemanager.properties

- nodemanager.domains

- nm_password.properties

- boot.properties

- startup.properties

- server_name.addr

- server_name.lck

- server_name.pid

- server_name.state

- ログ・ファイル

- nodemanager.log

- server_name.out

- ログ・ファイルのローテーション

3 ノード・マネージャのチュートリアル

- 新しいドメインでのノード・マネージャの作成

- ノード・マネージャの起動

- ノード・マネージャを使用した管理対象サーバーの起動

4 Javaノード・マネージャの構成

- 概要

- ノード・マネージャのデフォルト構成

- ホストごとのノード・マネージャの構成

- 複数マシンでのノード・マネージャの構成

- WLSTを使用したノード・マネージャの制御および構成

- WLSTオフラインを使用したノード・マネージャの構成

- Javaベースのノード・マネージャのセキュリティの構成

- ノード・マネージャのユーザー名とパスワードの指定

- Javaベースのノード・マネージャ用のリモート・サーバー起動セキュリティ

- Javaベースのノード・マネージャでのSSLの使用

- ノード・マネージャの拡張構成

- 管理サーバーのアドレスの定義

- 起動および停止スクリプトを使用するためのノード・マネージャの構成

- スクリプトの場所

- 起動および停止スクリプト使用時のベスト・プラクティス

- 起動スクリプトの使用

- 停止スクリプトの使用

- nodemanager.domainsファイルの構成

- nodemanager.propertiesのレビュー

- ノード・マネージャのプロパティ

- サーバー・インスタンスのグループのためのマシン・レベルのノード・マネージャ設定

- リモート起動引数の構成

- サーバーの起動プロパティの設定

- startup.properties

- WLSTを使用して起動プロパティを設定する

- サーバーの起動プロパティ

- ノード・マネージャの環境変数の設定

- xinetdサービスとしてのノード・マネージャの構成

- init.dサービスとしてのノード・マネージャの構成

- init.dサービスとしてのドメインごとのノード・マネージャの構成

- init.dサービスとしてのホストごとのノード・マネージャの構成

5 スクリプト・ベースのノード・マネージャの構成

- 概要

- ステップ1: ユーザー・アカウントの作成

- ステップ2: ノード・マネージャのセキュリティの構成

- ステップ3: WebLogic Serverのインストール

- ステップ4: WebLogicドメインの作成

- ステップ5: nodemanager.domainsファイルの構成

- ステップ6: 管理サーバーの起動

- ステップ7: 管理対象サーバーでのノード・マネージャの構成

- ステップ8: 管理対象サーバーの起動によるノード・マネージャの設定と構成のテスト

- ステップ9: UNIXマシンの構成

- ステップ10: マシンへのサーバーの割当

- ステップ11: 管理対象サーバーの起動

- スクリプト・ベースのノード・マネージャのセキュリティの構成

- デフォルトのSSHポートのオーバーライド

- WebLogic Serverスクリプトのセキュリティの構成

- スクリプト・ベースのノード・マネージャ用のリモート・サーバー起動セキュリティの構成

- キーと値のペアの生成と配布

- 共有のキーと値のペア

- 個々のキーと値のペア

6 ノード・マネージャの使用

- ノード・マネージャの起動と停止

- 起動サービスとしてのノード・マネージャの実行

- スクリプトを使用したJavaベースのノード・マネージャの起動

- Javaベースのノード・マネージャを起動するためのコマンド構文

- スクリプト・ベースのノード・マネージャの実行

- ノード・マネージャの停止

- ノード・マネージャを使用したサーバーの制御

- ノード・マネージャを使用した管理サーバーの起動

- WLSTを使用した管理対象サーバーの起動

- 管理コンソールを使用した管理対象サーバーの起動

- ノード・マネージャを使用するためのマシンの構成

- マシンへのサーバー・インスタンスの割当て

- 管理サーバーを使用しない管理対象サーバーの起動

はじめに

ここでは、このガイド『Oracle WebLogic Serverノード・マネージャの管理』で使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、このガイド『Oracle WebLogic Serverノード・マネージャの管理』の内容と構成について説明します。

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

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- このリリースでの新機能と変更された機能

ドキュメントのスコープと対象読者

このドキュメントでは、WebLogic Server環境内のサーバー・インスタンスを制御および管理するためのノード・マネージャの構成および使用方法について説明します。

このドキュメントは、ノード・マネージャの使用に携わるシステム管理者およびオペレータを対象としています。その内容は、デプロイメントからテストおよび本番まで、ソフトウェア・プロジェクトのすべての段階に関連しています。

Java Platform, Enterprise Edition (Java EE)技術、Web技術、オブジェクト指向プログラミング技術、およびJavaプログラミング言語について読者が精通していることを前提としています。

このドキュメントの手引き

このドキュメントの構成は次のとおりです。

- この章「概要とロードマップ」では、ガイドの構成および関連ドキュメントについて説明します。

- 「ノード・マネージャの概要」では、ノード・マネージャについて全般的に説明し、WebLogicドメイン内でどのように機能するのかについて説明します。また、ノード・マネージャによって使用される構成ファイルおよびログ・ファイルについても詳述します。

- 「ノード・マネージャのチュートリアル」では、管理サーバーと管理対象サーバーの両方をホストする単一マシン・ドメイン内でWebLogic Serverインスタンスを起動および停止するために、ドメインごとのJavaベース・ノード・マネージャを作成して使用する方法の基本的な例を示します。

- 「Javaノード・マネージャの構成」では、Java実装のノード・マネージャの構成手順について説明します。

- 「スクリプト・ベースのノード・マネージャの構成」では、スクリプト・ベース実装のノード・マネージャの構成手順について説明します。

- 「ノード・マネージャの使用」では、ノード・マネージャおよびサーバー・インスタンスの起動手順について説明します。

関連ドキュメント

- 構成ウィザードによるWebLogicドメインの作成

- Oracle WebLogic Serverドメイン構成の理解

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプ

- Oracle WebLogic Serverサーバーの起動と停止の管理

このリリースでの新機能と変更された機能

このリリースで導入されたWebLogic Serverの総合的な新機能一覧は、「Oracle WebLogic Serverの新機能」 12.2.1.2.0を参照してください。

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

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

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

- 概要

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

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

- ノード・マネージャへのアクセス

- WebLogic Server環境でのノード・マネージャの機能

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

- ノード・マネージャの構成ファイルとログ・ファイル

はじめに

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モードで起動することはできません。

注意:

ノード マネージャは、スクリプトまたはコマンド行で管理対象サーバーを起動するときに指定するものと同じコマンド引数を使用します。起動引数の詳細は、『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-2は、ノード・マネージャによる管理サーバー起動プロセスを示します。

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

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

図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 管理対象サーバーの起動

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 管理サーバーの再起動

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 管理対象サーバーの再起動

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 ノード・マネージャの制御下にあるサーバー・インスタンスの停止

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

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

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

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

5. オペレーティング・システムが管理対象サーバー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に示すように、ノード・マネージャは複数の構成ファイルを使用し、ログ・ファイルを複数のディレクトリに出力します。

図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.propertiesでLogCountを設定することで有効にできます。

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

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

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

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

次の方法で、特定のサーバー・インスタンスに関するノード・マネージャのログ・ファイルを表示できます。

- 「診断」>「ログ・ファイル」を選択します。

- WLSTのnmServerLogコマンドを使用します。

ノード・マネージャが作成できるサーバー出力ログ数に制限はありません。

ログ・ファイルのローテーション

12.1.3.0より前のバージョンのWebLogic Serverでは、NativeVersionEnabledがfalseに設定されている場合は、表2-2に示されているノード・マネージャ・ログ・ファイル・ローテーション・プロパティを構成できます。WebLogic Server 12.1.3.0以降、ノード・マネージャでは、ログ・ファイル・ローテーションのためにLogFileMBeanプロパティが使用されます。ただし、NativeVersionEnabledはまだfalseに設定されている必要があります。

注意:

NativeVersionEnabledがtrueに設定されている場合は、ログ・ファイルをローテーションできます。これを行うには、管理対象サーバーの起動引数に次のプロパティを追加します。

-Dweblogic.nmservice.RotationEnabled=true

ノード・マネージャでは、5分間隔でログ・ファイル・サイズがチェックされます。ファイルのローテーションは、ログ・ファイルが最大しきい値以上になったことがノード・マネージャで確認された後にのみ開始されます。

管理対象サーバーの起動引数の構成方法の詳細は、管理対象サーバーの起動引数の構成を参照してください。

Coherenceおよびその他のプラグイン実装済のシステム・コンポーネントについては、表2-3に示すログ・ファイル・ローテーションのプロパティが使用されます。

表2-2 ノード・マネージャのログ・ファイル・ローテーション・プロパティ

プロパティ

説明

デフォルト

FileSizeKB

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

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

500

FileTimeSpan

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

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

24

FileTimeSpanFactor

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

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

360000

NumberOfFilesLimited

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

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

true

RotatedFileCount

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

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

7

RotationTimeStart

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

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

00:00

RotationType

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

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

SIZE

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

プロパティ

説明

デフォルト

process.FileSizeKB

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

500

process.FileTimeSpan

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

24

process.FileTimeSpanFactor

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

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

360000

process.NumberOfFilesLimited

古いメッセージを保存するためにこのサーバー・インスタンスが作成するファイルの数を制限するかどうかを示します。process.RotationTypeでSIZEまたは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

3 ノード・マネージャのチュートリアル

この章では、デフォルトのドメインごとのノード・マネージャの基本的な使用例を示します。このチュートリアルでは、管理サーバーと管理対象サーバーの両方をホストする単一マシン・ドメイン内でWebLogic Server インスタンスを起動および停止するための、Javaベースのノード・マネージャの作成および使用手順を示します。

ドメインごとのノード・マネージャの詳細は、「ノード・マネージャのデフォルト構成」を参照してください

本チュートリアルは、次のステップからなっています。

- 新しいドメインでのノード・マネージャの作成

- ノード・マネージャの起動

- ノード・マネージャを使用した管理対象サーバーの起動

新しいドメインでのノード・マネージャの作成

ドメインごとの、Javaベースのノード・マネージャのインスタンスを新しいドメインに作成するには、次の手順を実行します。

1. 構成ウィザードを起動します。

a. コマンド・ウィンドウで、ORACLE_HOME/oracle_common/common/binディレクトリに移動します。ORACLE_HOMEは、WebLogic Serverのインストール時にOracleホームとして指定したディレクトリを表します。

b. Windowsの場合はconfig.cmdコマンド、UNIXの場合はconfig.shコマンドを実行します。

2. 構成ウィザードを使用して新しい、基本的なドメインを作成します。

a. 「ドメインの作成」画面で、「新規ドメインの作成」を選択し、ドメイン・ディレクトリの場所を選択します。これがDOMAIN_HOMEディレクトリとなります。「次へ」をクリックします。

b. 「テンプレート」画面では、デフォルト値である「製品テンプレートを使用してドメインを作成」をそのままにします。「次へ」をクリックします。

c. 「管理者アカウント」画面で、WebLogic Server管理者の資格証明を入力します。「次へ」をクリックします。

d. 「ドメイン・モードおよびJDK」画面では、「ドメイン・モード」と「JDK」をデフォルト値のままにします。「次へ」をクリックします。

3. ノード・マネージャ・インスタンス、管理対象サーバーおよびマシンをドメイン内に作成します。

a. 「拡張構成」画面で、「ノード・マネージャ」オプションと「管理対象サーバー、クラスタおよびCoherence」オプションを選択します。「次へ」をクリックします。

b. 「ノード・マネージャ」画面では、「ノード・マネージャ・タイプ」をデフォルト値である「ドメインごとのデフォルトの場所」のままにして、ノード・マネージャ管理者の資格証明を入力します。「次へ」をクリックします。

c. 「管理対象サーバー」画面で、「追加」をクリックします。デフォルトのサーバー名、リスニング・アドレスおよびリスニング・ポート(7003)をそのままにします。「次へ」をクリックします。

d. 「クラスタ」画面で、「次へ」をクリックします。

e. 「マシン」画面で、「追加」をクリックします。デフォルトのマシン名、ノード・マネージャ・リスニング・アドレスおよびノード・マネージャ・リスニング・ポートをそのままにします。「次へ」をクリックします。

4. 管理サーバーと管理対象サーバーをマシンに割り当てます。

a. 「サーバーのマシンへの割当」画面の左側の列で、管理サーバーと管理対象サーバーを選択します。

b. 右矢印ボタンを使用して、管理サーバーと管理対象サーバーを右側の列にあるマシンに割り当てます。

c. 「次へ」をクリックします。

5. ドメインの構成を完了します。

a. 「構成のサマリー」画面で、構成を確認して「作成」をクリックします。

b. 構成プロセス画面に、ドメインが正常に作成されたというメッセージが表示されたら、「次へ」をクリックします。

c. 「構成に成功しました」画面で、「管理サーバーの起動」を選択してドメインを起動します。「終了」をクリックします。

ノード・マネージャの起動

ドメイン内のノード・マネージャを起動するには、次の手順を実行します。

1. コマンド・ウィンドウで、DOMAIN_HOME/binディレクトリに移動します。DOMAIN_HOMEは、WebLogic Serverドメインが構成されているディレクトリを表します。

2. 環境を設定するため、Windowsの場合はsetDomainEnv.cmdコマンド、UNIXの場合はsetDomainEnv.shコマンドを実行します。

3. DOMAIN_HOME/binディレクトリに戻ります。

4. ドメイン内のノード・マネージャを起動するため、Windowsの場合はstartNodeManager.cmdコマンド、UNIXの場合はstartNodeManager.shコマンドを実行します。

ノード・マネージャが正常に起動すると、次のような出力が表示されます。

<DATE TIME> <INFO> <12.2.1.0.0>
<DATE TIME> <INFO> <Secure socket listener started on port 5556, host localhost/127.0.01>

ノード・マネージャを使用した管理対象サーバーの起動

ノード・マネージャを使用してドメイン内の管理対象サーバーを起動するには、次の手順を実行します。

1. WebLogic Server管理コンソールを起動します。

a. 管理サーバーが実行中であることを確認します。
構成ウィザードで「管理サーバーの起動」オプションを選択した場合は、管理サーバーが実行中となっているはずです。

管理サーバーが実行中ではない場合は、DOMAIN_HOME/binディレクトリに移動して、Windowsの場合はstartWebLogic.cmdコマンド、UNIXの場合はstartWebLogic.shコマンドを実行します。

b. Webブラウザを起動して次のURLを入力します。

http://hostname:port/console

ここで、hostnameは管理サーバーのDNS名またはIPアドレスで、portは管理サーバーでリクエストがリスニングされるリスニング・ポート(デフォルトでは7001)です。

c. ログイン・ページが表示されたら、構成ウィザードでドメインを作成したときに入力したユーザー名とパスワードを入力します。

2. ノード・マネージャが実行中であることを確認します。

a. WebLogic Server管理コンソールの左ペインで、「環境」→「マシン」を選択します。

b. 「マシン」の表で、マシンの名前を選択します。

c. 「監視」→「ノード・マネージャのステータス」を選択します。

d. ノード・マネージャが実行中の場合は、「ステータス」が「アクセス可能」となります。

注意:

ノード・マネージャの設定をWebLogic Server管理コンソールで構成するには、「環境」→「マシン」→「machine_name」→「構成」→「ノード・マネージャ」ページに移動します。

3. WebLogic Server管理コンソールの左ペインで、「環境」→「サーバー」を選択します。

4. 「制御」ページを選択します。

5. 「サーバー」の表で、管理対象サーバーの横のチェック・ボックスを選択します。

6. 「起動」をクリックします。
選択されたサーバー・インスタンスがノード・マネージャによって起動されることを確認するメッセージが表示されます。WebLogic Server管理コンソール・ページをリフレッシュすると、管理対象サーバーの状態がSHUTDOWNからRUNNINGに変化します。

これで、管理対象サーバーがドメイン内で実行されている状態になりました。

4 Javaノード・マネージャの構成

この章では、Java実装のノード・マネージャを構成する方法を説明します。

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

- 概要

- ノード・マネージャのデフォルト構成

- ホストごとのノード・マネージャの構成

- 複数マシンでのノード・マネージャの構成

- WLSTを使用したノード・マネージャの制御および構成

- WLSTオフラインを使用したノード・マネージャの構成

- Javaベースのノード・マネージャのセキュリティの構成

- ノード・マネージャの拡張構成

概要

Java実装のノード・マネージャは、デフォルトで同じドメインに属するすべてのサーバー・インスタンスを制御するように構成される、ドメインごとのノード・マネージャです。サーバー・インスタンスは同じマシンに存在する必要はありません。1つのマシンに複数のドメインがある場合は、ドメインごとのノード・マネージャを使用すると、複数のノード・マネージャ・プロセス・インスタンスが存在することになります。ドメインごとのノード・マネージャの詳細は、「ノード・マネージャのデフォルト構成」を参照してください

以前のバージョンのWebLogic Serverでは、ノード・マネージャに特定のWebLogicドメインが関連付けられることはなく、関連付けられるのはホスト・マシンのみでした。どのWebLogicドメインに存在するサーバー・インスタンスであっても、同じマシン上に存在しているサーバー・インスタンスであるかぎり、同じノード・マネージャ・プロセスを使用して制御されていました。つまり、マシン・スコープ指定の、ホストごとのノード・マネージャでした。ホストごとのノード・マネージャも引き続き使用できますが、追加の構成が必要になります。一般的に、ホストごとのノード・マネージャを使用する目的は、複数のドメインを1つのノード・マネージャ・インスタンスで管理することです。ホストごとのノード・マネージャの詳細は、「ホストごとのノード・マネージャの構成」を参照してください

ドメインごとのノード・マネージャを使用する場合、WebLogic Serverでは、ノード・マネージャの構成をカスタムの場所に置くこともできます。構成ウィザードまたはWLSTオフラインを使用し、PerDomainまたはCustomLocationのJavaベースのノード・マネージャ構成を選択できます。いずれのタイプのノード・マネージャ構成にも、一意のノード・マネージャ証明書を指定できますが、「ノード・マネージャのデフォルト構成」で説明しているように、NodeManagerHomeがデフォルトの場所です。NodeManagerHomeとして固有の場所を指定する場合は、CustomLocationを選択して空のディレクトリを指定するか、ディレクトリの作成を選択します。

ノード・マネージャをWebLogic Server 12.1.1以前のバージョンから最新のバージョンにアップグレードする場合、またはWebLogic Server 12.1.2以上のバージョンから最新のバージョンにアップグレードする場合は、『Oracle WebLogic Serverのアップグレード』のノード・マネージャのアップグレード手順の特定に関する項を参照してください。

ノード・マネージャのデフォルト構成

作成するWebLogic Serverドメインのそれぞれについて、ドメイン固有のノード・マネージャ・インスタンスがデフォルトで作成されます。デフォルトであるドメインごとのノード・マネージャ構成を使用する場合は、特に追加の手順を実行しなくてもノード・マネージャを使用してWebLogic Serverドメイン内のサーバー・インスタンスの起動と停止ができるようになります。

管理サーバーに提供されたセキュリティ資格証明を使用して、nm_password.propertiesがDOMAIN_HOME\config\nodemanagerに作成されます。ここでDOMAIN_HOMEは、通常ORACLE_HOME\user_projects\domains\domain_nameにあります。nodemanager.propertiesファイルおよびnodemanager.domainsファイルが、DOMAIN_HOME\nodemanagerの下に作成されます。デフォルトのノード・マネージャ構成では、NodeManagerHomeの場所、DOMAIN_HOME\nodemanagerは編集はできません。

ノード・マネージャをWindowsサービスとして起動、停止、インストールおよびアンインストールするためのドメイン固有のスクリプトは、DOMAIN_HOME\binにあります。ノード・マネージャをWindowsサービスとしてインストールするには、installNodeMgrSvc.cmdスクリプトを編集して適切なリスニング・アドレスとリスニング・ポートの値を指定することが必要になる可能性があります。

1. DOMAIN_HOME\binディレクトリに移動します。

2. installNodeMgrSvc.cmdを編集して、ノード・マネージャのリスニング・アドレスとリスニング・ポートを指定します。

installNodeMgrSvc.cmdの場合と同じ編集をuninstallNodeMgrSvc.cmdでも行います。そうすれば、今後必要に応じてサービスを正常にアンインストールできます。

3. installNodeMgrSvc.cmdを実行して、ノード・マネージャをサービスとして再インストールし、更新したアドレスとポートでリスニングします。

注意:

複数のドメインごとノード・マネージャ・インスタンスを同じマシン上で構成する場合は、ドメインごとに一意のノード・マネージャ・アドレス(hostname:port)を使用する必要があります。一意のポートを使用するのでも、一意のホスト名を使用するのでもかまいません。たとえば、ドメインごとのノード・マネージャ・インスタンス3つを同じマシン上で実行する場合に、アドレスlocalhost:5556をドメイン1に、アドレスlocalhost:5557をドメイン2に、localhost:5558をドメイン3に使用します。

ホストごとのノード・マネージャの構成

ホストごとのノード・マネージャを使用する場合は(そのスクリプトはWL_HOME\server\binにあります)、次に示す、前提条件となっている構成手順を最初に実行する必要があります。

注意:

ホストごとのノード・マネージャ構成の場合は、JAVA_OPTIONSの中のweblogic.RootDirectoryの設定としてドメイン・ホームを選択しないでください。weblogic.RootDirectoryが既存のドメインを指している場合は、セキュリティ・サブシステムのデフォルトの場所が、ノード・マネージャ固有の場所ではなくドメインとなります。このときは、ノード・マネージャがドメイン固有のセキュリティ設定をデフォルトで使用することがあるため、別のドメインがそのノード・マネージャとの通信を試行した場合にSSLハンドシェイクに失敗するおそれがあります。

さらに、SSLをホストごとのノード・マネージャ構成で使用する場合は、独自の証明書ファイルを作成する必要があります。

1. ホストごとのNodeManagerHomeの場所であるORACLE_HOME\oracle_common\common\nodemanagerに、このノード・マネージャ・インスタンスが制御するドメインを指定するnodemanager.domainsファイルを作成します。

- このファイルは、手動で作成するかコピーできます。「nodemanager.domainsファイルの構成」を参照してください

- あるいは、WLSTコマンドnmEnrollを使用して、WebLogicドメインをノード・マネージャに登録することも可能です。

nodemanager.domainsファイルに複数のドメインを指定することにより、以前のWebLogic Serverリリースからのノード・マネージャ機能と同様、複数のWebLogic Serverドメインに属するサーバー・インスタンスを管理する、マシンにスコープ指定された単独ノード・マネージャ・プロセスを構成できます。

2. ノード・マネージャ・プロセスを実行するマシンごとに、マシン定義を構成します。詳細は、「ノード・マネージャを使用するためのマシンの構成」を参照してください

3. デモ用のIDキーストアおよび信頼キーストアは、開発目的またはテスト目的に限定して使用することをお薦めしますが、次の例に示すようにCertGenおよびImportPrivateKey Javaユーティリティを使用して作成できます。

a. PATH変数およびCLASSPATH変数を適切に設定するには、コマンド・プロンプトからWL_HOME\server\bin\setWLSEnv.cmdを実行します。

注意:

UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行してください。

b. 証明書と秘密鍵を生成します。

java utils.CertGen -keyfilepass DemoIdentityPassPhrase -certfile democert -keyfile demokey

デフォルトではutils.CertGenは、生成される証明書で所有者CNの値として短いホスト名を使用します。完全修飾DNホスト名を使用するには、前述のコマンドに-cnオプションを追加します。例:

java utils.CertGen -keyfilepass DemoIdentityPassPhrase -certfile democert -keyfile demokey -cn abc.oracle.com

c. 秘密鍵と証明書をインポートします。

java utils.ImportPrivateKey -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -keyfile demokey -keyfilepass
DemoIdentityPassPhrase -certfile democert.pem -keyfile demokey.pem -alias demoidentity

DemoIdentity.jksキーストアに、1つの秘密鍵と証明書エントリが格納されました。他のファイルは削除できます。

d. DemoIdentity.jksキーストアを、NodeManagerHome \securityディレクトリにコピーします。

本番環境でのノード・マネージャ用のSSLの構成方法については、「Javaベースのノード・マネージャでのSSLの使用」を参照してください

Oracle JRFを含むドメインでは、Oracle Platform Security Servicesのキーストア・サービス(OPSS)を使用するようにノード・マネージャを構成できます。『Oracle Fusion Middlewareの管理』のOPSSキーストア・サービスを使用するノード・マネージャの構成に関する項を参照してください。

注意:

デフォルトでは、ノード・マネージャでのSSLの使用は有効です。必要ない場合は、nodemanager.propertiesファイルでSecureListener=falseに変更することで無効にできます。nodemanager.propertiesのSSL関連プロパティを確認するには、表4-1を参照してください。

複数マシンでのノード・マネージャの構成

1つのドメインの管理対象サーバーが複数の物理マシン上に存在している場合は、次の手順を実行します。

1. ノード・マネージャが各マシン上にインストールされて構成されていることを確認します。

複数マシン上でノード・マネージャを構成するときは、どのタイプのノード・マネージャも使用できます(ドメインごと、ホストごと、カスタム)。ただし、同じノード・マネージャ・タイプをすべてのマシンに使用してください。

NodeManagerHomeの場所とnodemanager.propertiesファイルを作成します。デフォルトでは、NodeManagerHomeはDOMAIN_HOME\nodemanagerです。本番環境では、ノード・マネージャのルート・ディレクトリの場所をカスタマイズすることが必要な場合があります。nodemanager.propertiesファイルは、NodeManagerHomeで指定されたディレクトリに作成され、このファイルでノード・マネージャのプロパティが指定されます。「nodemanager.propertiesのレビュー」を参照してください。

注意:

NodeManagerHomeの場所を複数のノード・マネージャ・インスタンスで共用しないでください。

したがって、共有ドライブを使用するシナリオでは、NodeManagerHomeの場所がマシンごとに異なっている必要があります。たとえば、ホスト名サブディレクトリをNodeManagerHomeの下に作成し、すべてのファイルをこのホスト名サブディレクトリにコピーします。

2. ドメインをノード・マネージャに登録するには、packおよびunpackコマンドを使用してすべての必須ドメインおよび構成情報をマシン間でコピーすることをお薦めします。『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のノード・マネージャの構成に関する項を参照してください。WLSTのコマンドnmEnrollを使用してこのアクションを実行することもできます。

3. 管理サーバー内に、各ノード・マネージャ・インスタンスを指す対応MachineMBeanを作成し、どのマシンからでもノード・マネージャを使用して管理対象サーバーを起動できるようにします。

管理対象サーバーの起動に管理サーバーが関与する場合は、ターゲットであるMachineMBean内の情報を使用して正しいノード・マネージャ・インスタンスとの接続が作成されます。これは、WebLogic Server管理コンソールを使用するときも、WLSTを使用するときも(nmConnectコマンドの実行後)行われます。対応するMachineMBeanを物理マシンごとに作成すると、各ノード・マネージャ・インスタンスを指してサーバー・インスタンスと適切なMachineMBeanとを関連付けるのに役立ちます。

MachineMBeanを管理サーバー内に作成するには、次のアクションのいずれかを実行します。

- WebLogic Server管理コンソールで、「環境」→「マシン」を選択して新しいマシンを作成します。ノード・マネージャのリスニング・アドレスとリスニング・ポートを指すようにMachineMBeanとそのNodeManagerMBean内の情報を構成します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのマシンの作成と構成に関する項を参照してください。

- WLSTを使用してcreateコマンドでMachineMBeanを作成します。次に、ノード・マネージャのリスニング・アドレスとリスニング・ポートを指すようにMachineMBeanの設定を変更します。

4. ノード・マネージャをローカルで作成した場合は、必要に応じて、これまでに実行した構成手順を繰り返します。

詳細は、『WebLogic Server WLSTコマンド・リファレンス』のノード・マネージャへのアクセスに関する項およびnmEnrollに関する項を参照してください。

WLSTを使用したノード・マネージャの制御および構成

WebLogic Scripting Tool (WLST)はコマンド行スクリプト・インタフェースです。システム管理者およびオペレータは、このインタフェースでWebLogic Serverのインスタンスやドメインの監視と管理を行います。WLSTをノード・マネージャ・クライアントとして使用することで、サーバー・インスタンスをリモートまたはローカルで起動、停止、および再起動できます。加えて、WLSTではサーバーのステータスを取得し、サーバー出力のログとノード・マネージャのログの内容を取得できます。WLSTノード・マネージャ・コマンドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のWLSTコマンドおよび変数リファレンスに関する項を参照してください。

WLSTオフラインを使用したノード・マネージャの構成

必要に応じて、WLSTオフラインを使用して次のノード・マネージャ構成タスクを実行できます。

- ノード・マネージャのユーザー名とパスワードの設定

- ノード・マネージャ・プロパティの設定

- ノード・マネージャ・タイプの設定

例4-1に、ドメインのノード・マネージャ・リスニング・アドレスとリスニング・ポート、ノード・マネージャのユーザー名とパスワード、およびノード・マネージャ・タイプを設定する方法を示します。

注意:

ノード・マネージャ・タイプがManualNodeManagerSetupの場合、WLSTオフラインを使用してノード・マネージャ・プロパティは編集できません。

例4-1 ノード・マネージャの構成

# set the Node Manager listen address and listen port.
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
# Set the Node Manager user name and password.
cd('/')
cd('SecurityConfiguration/domain_name')
set('NodeManagerUsername','username')
set('NodeManagerPasswordEncrypted','password')

# Set the Node Manager type to custom location type and set the custom location Node Manager home.
setOption('NodeManagerType','CustomLocationNodeManager')
setOption('NodeManagerHome','C:/mydomains/nodemanager')

詳細は、『WebLogic Server WLSTコマンド・リファレンス』のsetOptionに関する項を参照してください。

Javaベースのノード・マネージャのセキュリティの構成

Javaベースのノード・マネージャのセキュリティには、SSLがデフォルトで使用され、各ドメインに固有の資格証明セットに対して、着信接続が認証されます。

WebLogic Server Scripting Tool (WLST)のnmConnectコマンドを使用してJavaノード・マネージャへのコマンド行接続を確立する場合は、ノード・マネージャのユーザー名とパスワードを指定します。ノード・マネージャは、ドメインのnm_password.propertiesファイルに対してユーザー名とパスワードを検証します。

ノード・マネージャの資格証明は、WebLogic Server管理コンソールの「domain_name」→「セキュリティ」→「全般」→詳細オプション・ページにあります。

WebLogic Server管理コンソール・ユーザーは、ノード・マネージャに接続するための資格証明を明示的に指定する必要はありません。ノード・マネージャのユーザー名とパスワードはドメイン構成で使用可能であり、自動的に指定されます。

この項には次のトピックが含まれます:

- ノード・マネージャのユーザー名とパスワードの指定

- Javaベースのノード・マネージャ用のリモート・サーバー起動セキュリティ

- Javaベースのノード・マネージャでのSSLの使用

ノード・マネージャのユーザー名とパスワードの指定

nm_password.propertiesファイルには、ノード・マネージャのユーザー名とパスワードが暗号化された状態で格納されます。ユーザー名とパスワードは、クライアント(たとえば管理サーバー)とノード・マネージャの間の接続を認証するために使用します。

注意:

このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。サーバー管理IDとパスワードとは別のものです。

このファイルは、ドメインの作成時または構成ウィザードの使用時に、nmEnrollを使用して必要な構成ファイルをあるマシンから別のマシンにコピーするときに作成されます。ファイルは、DOMAIN_HOME/config/nodemanagerにあります。ここでDOMAIN_HOMEは、WebLogicドメインの場所(通常ORACLE_HOME\user_projects\domains\domain_name)です。

構成ウィザードから、初期構成用のノード・マネージャのユーザー名とパスワードを求められます。この値は、必要なファイルにローカルに移入されますが、リモートに配布するためにはnmEnrollコマンドを使用する必要があります。

nm_password.propertiesが作成された後で、WebLogic Server管理コンソールを使用してノード・マネージャのパスワードやプロパティの値を変更できます。変更は、nm_password.propertiesファイルに伝播され、ノード・マネージャによって使用されます。

次の手順を使用して、ノード・マネージャの資格証明を変更できます。

1. 管理サーバーを起動します。

2. WebLogic Server管理コンソールを使用し、「domain_name」→「セキュリティ」→「全般」の「詳細」オプションを使用してノード・マネージャの資格証明を更新します。

3. WLSTを呼び出し、connectコマンド使用して管理サーバーに接続します。『WebLogic Scripting Toolの理解』を参照してください。

4. 以下の構文を使用してnmEnrollを実行します。

nmEnroll([domainDir], [nmHome])

次に例を示します。

nmEnroll('C:/oracle/user_projects/domains/prod_domain',
'C:/oracle/user_projects/domains/prod_domain/nodemanager')

nmEnroll()を実行すると、各管理対象サーバーへ、確実に正しいノード・マネージャのユーザーおよびパスワード・トークンが提供されます。

注意:

管理対象サーバーを実行している各マシン上でnmEnrollを実行する必要があります。加えて、各マシン上の各ドメイン・ディレクトリについて、nmEnrollを実行することが必要です。

注意:

nm_password.propertiesを手動で編集した場合(非推奨)、変更が反映されるようにノード・マネージャを再起動する必要があります。ノード・マネージャを実行している状態でWebLogic Server管理コンソールを使用して値を変更した場合は、再起動は必要ありません。

nm_password.propertiesファイルは、ノード・マネージャを実行する各物理マシンのドメイン・ディレクトリに存在している必要があります。ドメインのノード・マネージャのユーザー名とパスワードを変更した場合、nm_password.propertiesファイルを同期させるために各マシンでnmEnrollを実行する必要があります。マシンに複数のドメインを構成した場合、各ドメインで異なるノード・マネージャのユーザー名とパスワードを使用できます。

一般的な開発環境では、ドメイン作成時にノード・マネージャのユーザー名とパスワードの入力を求められないことがあります。ノード・マネージャのユーザー名とパスワードは、デフォルトでは管理者の資格証明ですが、これは、WebLogic Server管理コンソールまたはWLSTで変更できます。ただし、本番環境では、ノード・マネージャのユーザー名とパスワードを明示的に設定する必要があります。

Javaベースのノード・マネージャ用のリモート・サーバー起動セキュリティ

ノード・マネージャを使用してサーバー・インスタンスを起動するには、リモート起動ユーザーのユーザー名とパスワードが必要です。管理サーバーと管理対象サーバーでは、これらの資格証明の指定方法が異なります。

- 管理対象サーバーの資格証明 - 管理対象サーバーを起動するためにノード・マネージャを呼び出す場合、リモート起動のユーザー名とパスワードはノード・マネージャによって管理サーバーから取得されます。

- 管理サーバーの資格証明: ノード・マネージャを起動して管理サーバーを起動すると、次の方法でリモート起動ユーザー名およびパスワードが付与されます。

- コマンド行。ノード・マネージャによる管理サーバーの起動方法に関する項を参照してください

- 管理サーバーのboot.propertiesファイルから。
構成ウィザードは、ドメインの作成時に管理サーバーのboot.propertiesファイルおよびstartup.propertiesファイルを初期化します。

- 次の手順で保護および暗号化された方法で生成されます。

- フラグ-Dweblogic.nodemanager.ServiceEnabled=trueで管理サーバーを起動します。

- DOMAIN_HOME\servers\AdminServer\data\nodemanagerディレクトリを作成します。

- 管理サーバーとノード・マネージャの両方が稼働している間に、任意の起動プロパティまたはサーバーの資格証明を更新します。

ノード・マネージャによって起動されたサーバー・インスタンスでは、自動再起動に使用するために、サーバーの起動に使用された資格証明が暗号化され、サーバー固有のboot.propertiesファイルに保存されます。

Javaベースのノード・マネージャでのSSLの使用

管理サーバーと管理対象サーバーは、一方向SSLを使用してJavaベースのノード・マネージャと通信します。

WebLogic Serverのデフォルト・インストールには、SSLを即時利用可能にするデモ用のアイデンティティ・キーストアおよび信頼キーストアが含まれています。DemoIdentity.jksはDOMAIN_HOME\securityディレクトリにインストールされ、DemoTrust.jksはWL_HOME\server\libにインストールされます。開発目的やテスト目的の場合は、このキーストア構成で十分です。

nodemanager.propertiesにあるCustomIdentityKeyStoreFileNameのプロパティを構成してノード・マネージャの証明書を設定します。ノード・マネージャは、独自の証明書を持つことも、そのドメインの他の機能と証明書を共有することもできます。ただし、クライアントがノード・マネージャ・インスタンスと通信するには、クライアントがノード・マネージャ証明書内のアイデンティティを信頼する必要があります。ノード・マネージャ・インスタンスごとに別の証明書を用意しなくてもかまいませんが、必要であればそのように構成することもできます。本番環境では、ノード・マネージャがすべてのサーバー・インスタンスに対して同じ公開証明書を使用できます。

本番環境用のSSLの構成には、ノード・マネージャのIDを取得してから、ノード・マネージャが通信する管理サーバーおよび管理対象サーバーについて、それぞれIDと信頼を構成することが必要です。また、ホスト名検証の使用と管理ポートを考慮に入れる必要があります。nodemanager.propertiesのSSL関連プロパティを確認するには、表4-1を参照してください。本番用のSSLコンポーネントの構成方法については、『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。

管理対象サーバーが非SSLポートを無効にする場合、ノード・マネージャはサーバーから受信する証明書を信頼する必要があります。ノード・マネージャの信頼ストアを構成するには、ノード・マネージャの起動スクリプトに-Djavax.net.ssl.trustStoreを追加します。起動スクリプトの詳細は、起動スクリプトの使用を参照してください。

ノード・マネージャの拡張構成

この項には次のトピックが含まれます:

- 管理サーバーのアドレスの定義

- 起動および停止スクリプトを使用するためのノード・マネージャの構成

- nodemanager.domainsファイルの構成

- nodemanager.propertiesのレビュー

- リモート起動引数の構成

- サーバーの起動プロパティの設定

- ノード・マネージャの環境変数の設定

- xinetdサービスとしてのノード・マネージャの構成

- init.dサービスとしてのノード・マネージャの構成

管理サーバーのアドレスの定義

ノード・マネージャ・プロセスに接続する各管理サーバーのリスニング・アドレスを確実に定義する必要があります。管理サーバーのリスニング・アドレスが定義されていない場合、ノード・マネージャは、管理対象サーバーの起動時に、その管理対象サーバーに対してlocalhostにアクセスして構成情報を取得するように指示します。

リスニング・アドレスは、WebLogic Server管理コンソールの「サーバー」→「構成」→「全般」ページで設定します。

起動および停止スクリプトを使用するためのノード・マネージャの構成

スクリプトを使用して管理対象サーバーを起動、またはサーバーの停止が完了した後にスクリプトを実行するように、ノード・マネージャを構成できます。これらのスクリプトは、サーバー・インスタンスの起動前や停止後に実行する必要のあるタスクの実行に使用できます。スクリプトを使用して実行可能なタスクの一例としては、リモート・ディスクのマウントおよびアンマウントがあります。

注意:

ノード・マネージャは、起動スクリプトを使用して任意の必要な構成を実行し、その後でサーバー・インスタンスを起動します。対照的に、停止スクリプトはサーバー・インスタンスの停止後に実行されます。

スクリプトの場所

起動スクリプトと停止スクリプトは双方とも、以下のディレクトリに格納されています。

DOMAIN_HOME\bin

スクリプトは、このディレクトリを基準として実行されます。

起動および停止スクリプト使用時のベスト・プラクティス

起動スクリプトおよび停止スクリプトを使用してサーバーの動作を制御する際には、提供されているスクリプトの一番上の行のみの編集をお薦めします。これにより、スクリプトの実行時に、必要なすべての環境変数が確実に使用されます。

起動スクリプトの使用

起動スクリプトを使用すると、必要な起動プロパティの指定、および起動時に実行が必要なその他の任意の作業の実行ができます。起動スクリプトを定義するには:

1. nodemanager.propertiesファイル内のweblogic.StartScriptEnabledプロパティをtrueに設定します。(デフォルト値はtrueです。)起動スクリプトの名前がstartWebLogic.shまたはstartWebLogic.cmdの場合は、ノード・マネージャはそれらのスクリプトのいずれかをデフォルトとして使用します。

2. カスタム起動スクリプトを指定する場合は、nodemanager.propertiesファイル内のweblogic.StartScriptNameプロパティでスクリプトの名前またはパスを設定します。

注意:

カスタムの起動スクリプトを作成する場合、startWebLogic.shをバックグラウンドで実行するのではなく、その場でサーバー・インスタンスを起動します。このようにすると、サーバー・インスタンスが実行中のときはカスタム・スクリプトのプロセスも実行中になります。例:

# custom stuff
# custom stuff
startWebLogic.sh

ノード・マネージャは、JAVA_VENDOR、JAVA_HOME、JAVA_OPTIONS、SECURITY_POLICY、CLASSPATH、およびADMIN_URLを設定します。WebLogic Server管理コンソールを使用してサーバー・インスタンスを起動したり、WebLogic Server管理サーバーに接続されたWLSTを使用すると、これらの値がServerMBean、ServerStartMBeanおよびSSLMBeanから取り出されます。ノード・マネージャに直接接続されたWLSTを使用する場合は、値を指定できますが、使用しない場合は空白にします。

ノード・マネージャは、ServerStartMBean Arguments属性で指定されるすべてのコマンド行起動オプション(-Dフラグ)とSSLArgumentsを組み合わせ、JAVA_OPTIONSという1つの環境変数にします。SSLArgumentsは、SSLMBeanの値から取得されます。SSLMBeanは、ignoreHostnameVerification、HostnameVerifier、およびReverseDNSAllowedの各値があるか検査し、それらの値は-Dフラグに付加されます。すべてのフラグは、SSLArgumentsパラメータから構成されます。ServerStartMBean内のSSLArgumentsおよびArgumentsのすべての値は、起動スクリプトに定義されるJAVA_OPTIONS環境変数から構成されます。また、スクリプトは独自に定義した任意の値を環境変数に付加します。

この値のセットで結果としてオーバーラップが発生する場合、Javaコマンド行で次のように表示されます。

java -Dflag1=value1 -Dflag1=value2 weblogic.Server

Javaを呼び出すと、重複した値を解決できます。

停止スクリプトの使用

停止スクリプトを使用すると、サーバー・インスタンスの障害発生または停止の後に必要となるタスクを実行できます。

停止スクリプトを定義するには:

1. nodemanager.propertiesファイル内のweblogic.StopScriptEnabledプロパティをtrueに設定します。

2. nodemanager.propertiesファイル内のweblogic.StopScriptNameプロパティで、スクリプトの名前を設定します。

次の例では、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

nodemanager.domainsファイルの構成

nodemanager.domainsファイルには、ノード・マネージャ・インスタンスが制御するドメインを指定します。このため、スタンドアロンのクライアントではドメイン・ディレクトリを明示的に指定する必要はありません。

注意:

ドメインごとのノード・マネージャを使用する場合は、nodemanager.domainsファイルに変更を加えないでください。ただし、ホストごとのノード・マネージャや、カスタムのノード・マネージャ・インスタンスを使用する場合は、nodemanager.domainsファイルでドメインを指定することが必要になる可能性があります。

このファイルには、ノード・マネージャ・インスタンスが制御する各ドメインのドメイン・ディレクトリを次の形式で指定するエントリが含まれている必要があります。

domain-name=domain-directory

ユーザーがドメインに対してコマンドを発行すると、ノード・マネージャはnodemanager.domainsからドメイン・ディレクトリをルックアップします。

このファイルではノード・マネージャ・クライアントのアクセスがファイル内に表示されたドメインに制限されるので、セキュリティがさらに強化されます。クライアントは、nodemanager.domainsに表示されたドメインに対してのみコマンドを実行できます。

Javaベースのノード・マネージャの場合、このファイルは通常、ORACLE_HOME\user_projects\domains\domain_name\nodemanagerにあります。構成ウィザードを使用してドメインを作成した場合は、nodemanager.domainsファイルは自動的に作成されています。ホストごとのノード・マネージャ・インスタンスを構成する場合は、nodemanager.domainsファイルをORACLE_HOME\oracle_common\common\nodemanagerの下、つまりホストごとのNodeManagerHomeの場所に手動で作成するかコピーする必要があります。詳細は、「ホストごとのノード・マネージャの構成」を参照してください

必要であれば、nodemanager.domainsを手動で編集して、ドメインを追加したり、1つのドメイン名の下で複数のドメインの場所を登録することもできます。

複数ドメイン登録を構成するには、手動で代替パスを次の形式でnodemanager.domainsファイルに入力します。

domainName=primaryDomainPath;alternateDomainPath1;alternateDomainPath2

primaryDomainPathは、管理対象サーバーが存在するドメインの場所へのパスで、管理対象サーバーはこの場所から実行されます。一般的に、ドメインにアクセスするためのパスが管理サーバーからノード・マネージャに渡されることはありません。ドメインには、名前によってのみアクセス可能です。

alternateDomainPathは名前とパスによるアクセスのみが可能であり、一般的には管理サーバーの場所です。ノード・マネージャに直接接続するクライアントは、ドメイン名値とドメイン・パス値の両方を使用して代替ドメイン・パスにアクセスできます。

注意:

nodemanager.domainsでバックスラッシュ文字(\)を使用している場合は、(\\)としてエスケープする必要があります。

例4-2 nodemanager.domainsファイル

#Domains and directories created by Configuration Wizard
#Mon Jan 07 10:57:18 EST 2013
base_domain=C\:\\Oracle\\Middleware\\Oracle_Home\\user_projects\\domains\\base_domain
prod_domain=C\:\\Oracle\\Middleware\\Oracle_Home\\user_projects\\domains\\prod_domain

nodemanager.propertiesのレビュー

ノード・マネージャ・プロパティは、Javaベースのノード・マネージャ・プロセスの様々な構成設定を定義します。ノード・マネージャ・プロパティは、コマンド行で指定するかnodemanager.propertiesファイルで定義できます。コマンド行で指定された値は、nodemanager.propertiesの値をオーバーライドします。

nodemanager.propertiesは、NodeManagerHomeで指定されたディレクトリ内に作成されます。ここでNodeManagerHomeは、通常ORACLE_HOME\user_projects\domains\domain_name\nodemanagerになります。NodeManagerHomeが定義されていなければ、nodemanager.propertiesはカレント・ディレクトリ内に作成されます。

ノード・マネージャを起動すると、そのたびにカレント・ディレクトリ内にnodemanager.propertiesが存在するかどうかが検索され、存在しない場合はこのファイルが作成されます。ノード・マネージャを1回は起動しない限り、このファイルにはアクセスできません。

ノード・マネージャのプロパティ

多くの環境において、明示的に定義する必要のあるノード・マネージャ・プロパティはnodemanager.propertiesのSSL関連のプロパティのみです。ただし、nodemanager.propertiesには、環境やプリファレンスによっては指定する必要のある、SSL以外のプロパティも格納されます。例:

- Windows以外のインストールでは、weblogic.StartScriptEnabledプロパティおよびNativeVersionEnabledプロパティを指定することが適当な場合もあります。

- ノード・マネージャがマルチホーム・システムで動作し、それが使用するアドレスとポートを管理する必要がある場合は、ListenAddressおよびListenPortを定義します。

表4-1に、ノード・マネージャのプロパティを示します。

表4-1 ノード・マネージャのプロパティ

ノード・マネージャ・プロパティ

説明

デフォルト

AuthenticationEnabled

trueに設定すると、ノード・マネージャはドメインに対して資格証明を認証します。

true

certificateFile

SSL認証に使用される証明書ファイルのパスを指定します。

注意: このプロパティは、WebLogic Serverバージョン7.xからバージョン9.xにアップグレードするプロセスでのみ使用されます。

none

CipherSuite

SSLリスナーで使用される暗号スイートの名前。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、「CipherSuites」を参照してください。

デフォルト値はJDKで、プラットフォームに依存しています。

CipherSuites

SSLリスナーで使用される暗号スイートの名前。複数の暗号スイート値を、次の例のようにカンマで区切って指定できます。

CipherSuites=SUITE_A, SUITE_B, SUITE_C

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにCipherSuiteを使用します。

デフォルト値はJDKで、プラットフォームに依存しています。

CoherenceStartScriptEnabled

スタンドアロンのCoherenceサーバーを起動するときに、ノード・マネージャがCoherenceインスタンスの起動スクリプトを使用するか直接Java呼出しを使用するかを指定します。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、「coherence.StartScriptEnabled」を参照してください。

true

CoherenceStartScriptName

coherence.StartScriptEnabled=trueのとき、スタンドアロンのCoherenceサーバーを起動するのに使用される起動スクリプトの名前またはパスを指定します。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、「coherence.StartScriptName」を参照してください。

none

coherence.StartScriptEnabled

スタンドアロンのCoherenceサーバーを起動するときに、ノード・マネージャがCoherenceインスタンスの起動スクリプトを使用するか直接Java呼出しを使用するかを指定します。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにCoherenceStartScriptEnabledを使用します。

true

coherence.StartScriptName

coherence.StartScriptEnabled=trueのとき、スタンドアロンのCoherenceサーバーを起動するのに使用される起動スクリプトの名前またはパスを指定します。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにCoherenceStartScriptNameを使用します。

none

coherence.startup.JavaHome

適用されるのは、coherence.StartScriptEnabled=falseでノード・マネージャがJavaを直接呼び出すときです。このマシン上の管理対象サーバーを起動するためにノード・マネージャが使用するJavaホーム・ディレクトリです(その管理対象サーバーのリモート起動ページでJavaホームが構成されていない場合)。どちらでも指定されていない場合、ノード・マネージャはノード・マネージャ・プロセスに対して定義されているJavaホームを使用します。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにJavaHomeを使用します。

none

CrashRecoveryEnabled

システム・クラッシュのリカバリを有効にします。

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

false

CustomIdentityAlias

秘密鍵をキーストアにロードするときの別名を指定します。このプロパティは、KeystoresプロパティがCustomIdentityAndCustomTrustまたはCustomIdentityAndJavaStandardTrustに設定されている場合に必須です。

none

CustomIdentityKey

StoreFileName

IDキーストア(ノード・マネージャの秘密鍵を格納するキーストア)のファイル名を指定します。このプロパティは、KeystoresプロパティがCustomIdentityおよびCustomTrustまたはCustomIdentityAndJavaStandardTrustに設定されている場合に必須です。

none

CustomIdentity

KeyStorePassPhrase

IDキーストアの作成時に定義されたパスワードを指定します。このフィールドが必須か省略可能かは、キーストアのタイプによって異なります。すべてのキーストアで、キーストアに書き込むためにはパスワードが必須です。ただし、一部のキーストアでは読込みにパスワードを必要としません。WebLogic Serverはキーストアから読み込むだけなので、このプロパティを定義するかどうかはキーストアの要件によります。

none

CustomIdentity

KeyStoreType

IDキーストアのタイプを指定します。通常はJKS。このプロパティは省略可能です。

java.securityのデフォルト・キーストア・タイプ

CustomIdentity

PrivateKeyPassPhrase

IDキーストアからWebLogic Serverの秘密鍵を取得するために使用するパスワードを指定します。このプロパティは、KeystoresプロパティがCustomIdentityAndCustomTrustまたはCustomIdentityAndJavaStandardTrustに設定されている場合に必須です。

none

DomainsDirRemoteSharingEnabled

ノード・マネージャが共有ドメイン・ディレクトリをモニターするかどうかを指定します。指定すると、複数のノード・マネージャが別々のマシンから共有ディレクトリをモニターできます。

trueに設定すると、共有ドメイン・ディレクトリ(マウントされたディレクトリまたはWindows NFS)を持つことを示し、複数のノードが共有されることになります。このプロパティを有効にすると、複数のノード・マネージャが相互に影響を及ぼしあわずにドメインを共有できます。

false

DomainsFile

nodemanager.domainsファイルの名前。

NodeManagerHome\nodemanager.domains

DomainsFileEnabled

trueに設定されている場合は、DomainsFileで指定されているファイルが使用されます。falseに設定されている場合は、カレント・ディレクトリのドメインまたはWL_HOMEのドメインが想定されます。

true

DomainRegistrationEnabled

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

複数のドメインの場所をnodemanager.domainsファイルに登録するには、「nodemanager.domainsファイルの構成」を参照してください

false

IfConfigDir

この構成プロパティでは、wlsifconfig.sh/.cmdスクリプトの場所として別のディレクトリを設定します。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、「weblogic.IfConfigDir」を参照してください。

この場所はデフォルトで適切に設定されていますが、このプロパティを使用してスクリプトの場所を変更できます。

Interface

移行可能サーバーで使用されるプライマリ・インタフェース名。サーバーの移行では、各移行可能サーバーが使用するプライマリ・インタフェース名は同じである必要があります。

関連項目: <InterfaceName>プロパティを使用すると、複数のインタフェース、および特定のインタフェースにバインドする必要がある対応するIPアドレスの範囲をより柔軟に指定できます。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。詳細は、「<InterfaceName>」を参照してください。

なし

<InterfaceName>

インタフェース名、および移行可能サーバーが起動されたときにこの特定のネットワーク・インタフェースにバインドする必要がある対応するIPアドレスの範囲とオプションのネットマスク値。

構文: <InterfaceName>=<IP_RANGE_MIN>-<IP_RANGE_MAX>、(オプション) NetMask=<NETMASK_ADDRESS>

たとえば、1 - 4のアドレスをeth0インタフェースに、5 - 8のアドレスをbond0インタフェースにバインドするときに使用する構文は次のとおりです:

eth0=1-4,NetMask=255.255.255.0
bond0=5-8,NetMask=255.255.248.0

NetMaskの値を省略したい場合は省略して、単に次のように入力することもできます:

eth0=200.10.10.1-200.10.10.255
bond0=199.0.0.1-199.0.0.255

元のNetMaskおよびInterfaceプロパティもサポートされており、これらを指定した場合、IP範囲内で定義されていない任意のアドレスに適用されます。

たとえば、これらのプロパティを次のように元の形式で指定した場合:

Interface=oldEth0
NetMask=255.255.255.0

これを新しい形式で次のように指定した場合と同じになります:

oldEth0=*,Netmask=255.255.255.0

アスタリスク(*)は、すべてのIPを表します。

なし

JavaHome

管理対象サーバーのリモート起動ページにJavaホームが構成されていない場合、このマシン上の管理対象サーバーを起動するためにノード・マネージャで使用するJavaホーム・ディレクトリ。どちらでも指定されていない場合、ノード・マネージャはノード・マネージャ・プロセスに対して定義されているJavaホームを使用します。

注意: このプロパティはWLST setコマンドで設定しないことをお薦めします。WLSTで設定した場合、nodemanager.propertiesファイルでこのプロパティはデフォルト値に戻ります。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、WebLogic Serverプロセスの場合は「weblogic.startup.JavaHome」を、Coherenceプロセスの場合は「coherence.startup.JavaHome」を参照してください。

none

JavaStandardTrustKey

StorePassPhrase

信頼キーストアの作成時に定義されたパスワードを指定します。このフィールドが必須か省略可能かは、キーストアのタイプによって異なります。すべてのキーストアで、キーストアに書き込むためにはパスワードが必須です。ただし、一部のキーストアでは読込みにパスワードを必要としません。WebLogic Serverはキーストアから読み込むだけなので、このプロパティを定義するかどうかはキーストアの要件によります。このプロパティは、KeystoresプロパティがCustomIdentityAndJavaStandardTrustまたはDemoIdentityAndDemoTrustに設定されている場合に必須です。

none

keyFile

管理サーバーでSSL通信に使用する秘密鍵・ファイルのパス。

注意: このプロパティは、WebLogic Serverバージョン7.xからバージョン9.xにアップグレードするプロセスでのみ使用されます。

none

keyPassword

キー・ファイル内の暗号化された秘密鍵にアクセスするためのパスワード。

注意: このプロパティは、WebLogic Serverバージョン7.xからバージョン9.xにアップグレードするプロセスでのみ使用されます。

none

KeyStores

ID(秘密鍵とデジタル証明書)および信頼(信頼性のあるCA証明書)を検索するためにノード・マネージャで使用する、キーストア構成を示します。指定できる値は次のとおりです。

- DemoIdentityAndDemoTrust
デフォルトで構成されるDOMAIN_HOME\securityおよびWL_HOME\server\libディレクトリに配置されたデモ用のIDキーストアおよび信頼キーストアを使用します。デモ用の信頼キーストアは、Java標準信頼キーストア(JAVA_HOME\jre\lib\security\cacerts)のすべての認証局を信頼します。

- CustomIdentityAndJava

- StandardTrust
独自に作成したキーストアおよびJAVA_HOME\jre\lib\security\cacertsディレクトリのcacertsファイルで定義されている信頼性のあるCAを使用します。

- CustomIdentityAndCustomTrust
独自に作成したIDキーストアおよび信頼キーストアを使用します。

DemoIdentityAndDemoTrust

ListenAddress

ノード・マネージャを実行しているマシンが接続リクエストをリスニングできるアドレス。この引数により、weblogic.nodemanager.listenAddressは非推奨になります。

null

この設定を使用すると、ノード・マネージャはマシンのIPアドレスでリスニングします。

ListenBacklog

リスナーが受け付けるノード・マネージャのバックログ・リクエストの最大数。バックログされたリクエストが処理されるまで、追加の着信リクエストは削除されます。通常、このプロパティを調整する必要はありません。

50

ListenPort

ノード・マネージャが接続リクエストをリスニングするTCPポート番号。この引数により、weblogic.nodemanager.listenPortは非推奨となります。

5556

LogAppend

trueに設定されている場合は、ノード・マネージャの再起動時に新しいログ・ファイルが作成されません。かわりに既存のログに追加されます。

true

LogCount

LogLimitを超過した場合に作成されるログ・ファイルの最大数。

1

LogFile

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

NodeManagerHome\nodemanager.log

LogFormatter

ノード・マネージャのログ・メッセージに使用されるフォーマッタ・クラス名。

weblogic.nodemanager.server.LogFormatter

LogLevel

ノード・マネージャのログに使用されるロギングの重大度。ノード・マネージャは、java.util.logging.levelパッケージ(http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html)から、標準ロギング・レベルを使用します。

INFO

LogLimit

ノード・マネージャのログの大まかな最大サイズを整数として指定します。この上限に達すると、新しいログ・ファイルが開始されます。

unlimited

LogToStderr

trueに設定されている場合は、ログ出力も標準エラー出力に送信されます。

false

NativeVersionEnabled

trueに設定すると、オペレーティング・システムのネイティブ・ライブラリが使用されます。

SolarisまたはLinux以外のUNIXシステムでは、このプロパティをfalseに設定してノード・マネージャを非ネイティブ・モードで実行します。このようにすると、ノード・マネージャはweblogic.StartScriptEnabledプロパティで指定された起動スクリプトを使用して管理対象サーバーを起動します。

NativeVersionEnabled=falseの場合、次のことに注意してください。

- ノード・マネージャはPIDがアライブかどうかを問い合せたり、特定のプロセスを強制停止することはできません。

- ノード・マネージャはモニターする必要のある既存のプロセスがあるかどうかを判断できず、クラッシュ・リカバリは完全には実装されていません。

- nmKillは、NativeVersionEnabled=falseかつweblogic.StartScriptEnabled=trueのときはサポートされません。

true

NetMask

ネットワークのサブネット・マスク。サーバーの移行では、サーバー間のユニキャストおよびマルチキャストの通信が行えるように、各管理対象サーバーが同じサブネット・マスクを使用する必要があります。

関連項目: <InterfaceName>プロパティを使用すると、複数のインタフェースおよび対応するネットマスク値をより柔軟に入力できます。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。詳細は、「<InterfaceName>」を参照してください。

なし

NodeManagerHome

次の構成およびログ・ファイルが格納されたノード・マネージャのルート・ディレクトリ。

- nodemanager.domains

- nodemanager.log

- nodemanager.properties

これらのファイルの詳細は、「ノード・マネージャの構成ファイルとログ・ファイル」を参照してください。

注意: デフォルトでは、NodeManagerHomeは、DOMAIN_HOME\nodemanagerになります。本番環境では、ノード・マネージャのルート・ディレクトリの場所をカスタマイズすることが必要な場合があります。

注意: このプロパティはWLST setコマンドで設定しないことをお薦めします。WLSTで設定した場合、nodemanager.propertiesファイルでこのプロパティはデフォルト値に戻ります。

NodeManagerHome

PropertiesVersion

nodemanager.propertiesファイルのバージョンを指定します。この値は変更しないでください。

none

QuitEnabled

trueに設定すると、ノード・マネージャをリモートで停止できるようになります。

WLSTは、stopNodeManager()コマンドを使用してノード・マネージャを停止時にデフォルト値falseをオーバーライドします。

false

SecureListener

trueに設定されている場合はSSLリスナーが使用され、その他の場合はプレーン・ソケットが使用されます。

true

StartScriptEnabled

trueの場合は、StartScriptNameで指定された起動スクリプトを使用してサーバー・インスタンスが起動されます。詳細は、「起動および停止スクリプトを使用するためのノード・マネージャの構成」を参照してください。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、「weblogic.StartScriptEnabled」を参照してください。

true

StartScriptName

ドメイン・ディレクトリにある起動スクリプトの名前またはパス。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、「weblogic.StartScriptName」を参照してください。

startWebLogic.sh (UNIX)

または

startWebLogic.cmd (Windows)

StateCheckInterval

ノード・マネージャがサーバーの状態チェックを実行するまでに待機する間隔を指定します。

500 milliseconds

StopScriptEnabled

trueの場合は、StopScriptNameで指定された停止スクリプトをサーバー・インスタンス停止後に実行します。詳細は、「起動および停止スクリプトを使用するためのノード・マネージャの構成」を参照してください。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、「weblogic.StopScriptEnabled」を参照してください。

false

StopScriptName

サーバー停止後に実行されるスクリプトの名前。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、「weblogic.StopScriptName」を参照してください。

none

UseMACBroadcast

ARPパケット送信時にノードのMACアドレスを使用するかどうか、つまりarpingコマンドの-bフラグを使用するかどうかを指定します。ノード・マネージャは、自動サーバー移行のためにIPアドレスをバインドするときに、arpingコマンドも使用して、マシンが仮想IPアドレスを使用するようになったことをネットワーク内のノードに通知します。weblogic.UseMACBroadcast=trueのときは、ノード・マネージャはarpingコマンドで-bフラグを使用します。

このプロパティはWebLogic Server 12.1.3.0で非推奨となりましたが、WebLogic Server 12.2.1ではまだ完全にサポートされます。置換プロパティの詳細および現在のサポート制限は、「weblogic.UseMACBroadcast」を参照してください。

false

WebLogicHome

WebLogic Serverがインストールされるルート・ディレクトリ。リモート起動ページにルート・ディレクトリが構成されていない管理対象サーバーで-Dweblogic.RootDirectoryのデフォルト値として使用されます。どちらの場所でも指定されていない場合、ノード・マネージャは、ノード・マネージャが実行されているディレクトリで管理対象サーバーを起動します。

none

weblogic.IfConfigDir

この構成プロパティでは、wlsifconfig.sh/.cmdスクリプトの場所として別のディレクトリを設定します。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにIfConfigDirを使用します。

この場所はデフォルトで適切に設定されていますが、このプロパティを使用してスクリプトの場所を変更できます。

weblogic.StartScriptEnabled

trueの場合は、weblogic.StartScriptNameで指定された起動スクリプトを使用してサーバー・インスタンスが起動されます。詳細は、「起動および停止スクリプトを使用するためのノード・マネージャの構成」を参照してください。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにStartScriptEnabledを使用します。

true

weblogic.StartScriptName

ドメイン・ディレクトリにある起動スクリプトの名前またはパス。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにStartScriptNameを使用します。

startWebLogic.sh (UNIX)

または

startWebLogic.cmd (Windows)

weblogic.startup.JavaHome

適用されるのは、weblogic.StartScriptEnabled=falseでノード・マネージャがJavaを直接呼び出すときです。このマシン上の管理対象サーバーをノード・マネージャが起動するために使用するJavaホーム・ディレクトリを指定します(その管理対象サーバーのリモート起動ページでJavaホームが構成されていない場合)。どちらでも指定されていない場合、ノード・マネージャはノード・マネージャ・プロセスに対して定義されているJavaホームを使用します。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにJavaHomeを使用します。

none

weblogic.StopScriptEnabled

trueの場合は、weblogic.StopScriptNameで指定された停止スクリプトをサーバー・インスタンス停止後に実行します。詳細は、「起動および停止スクリプトを使用するためのノード・マネージャの構成」を参照してください。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにStopScriptEnabledを使用します。

false

weblogic.StopScriptName

サーバー停止後に実行されるスクリプトの名前。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにStopScriptNameを使用します。

none

weblogic.UseMACBroadcast

ARPパケット送信時にノードのMACアドレスを使用するかどうか、つまりarpingコマンドの-bフラグを使用するかどうかを指定します。ノード・マネージャは、自動サーバー移行のためにIPアドレスをバインドするときに、arpingコマンドも使用して、マシンが仮想IPアドレスを使用するようになったことをネットワーク内のノードに通知します。weblogic.UseMACBroadcast=trueのときは、ノード・マネージャはarpingコマンドで-bフラグを使用します。

WebLogic Server 12.1.3で導入されたこのプロパティは、WLSTオフラインまたはpackおよびunpackコマンドでは現在サポートされていません。これらのユーティリティを使用する場合は、かわりにUseMACBroadcastを使用します。

false

サーバー・インスタンスのグループのためのマシン・レベルのノード・マネージャ設定

サーバー・インスタンスのグループを同じノード・マネージャ・インスタンスで起動する場合は、特定のマシン・レベル設定をnodemanager.propertiesファイル内で一度構成するだけで、その設定をグループ内のすべてのサーバー・インスタンスに適用できます。マシン・レベルの属性を設定しておくと、共通の設定をサーバー・インスタンスごとにServerStartMBean内で構成する必要がなくなるため、構成が単純になります。

サーバー・インスタンス固有の設定を直接ServerStartMBean内で構成した場合は、その値はnodemanager.propertiesファイル内で構成された値よりも優先されます。

表4-2は、同じノード・マネージャ・インスタンスで起動されるサーバー・インスタンスのグループのためにnodemanager.propertiesで構成できる、マシン・レベルの設定の説明です。

表4-2 サーバー・インスタンスのグループのためのマシン・レベルのノード・マネージャ・プロパティ

プロパティ名

説明

coherence.startup.Arguments

サーバー・インスタンスの起動時に使用されるJava引数。

これらは、起動コマンドのJava部分の直後に付加する最初の引数です。たとえば、Javaヒープ・メモリーの設定や、任意のweblogic.nodemanager.server.provider.WeblogicCacheServerオプションの指定を行うことができます。

引数はスペースで区切ります。

coherence.startup.MW_Home

このサーバー・インスタンスの起動時に使用されるMW_HOMEディレクトリ(ノード・マネージャを実行しているマシン上のパス)。

ノード・マネージャ・マシン上の、すべてのOracle Middleware製品がインストールされているディレクトリを指定します。たとえば、C:\Oracle\Middlewareです。

weblogic.startup.Arguments

サーバー・インスタンスの起動時に使用されるJava引数。

ノード・マネージャは、JAVA_OPTIONS環境変数を使用してこの値を起動スクリプトに渡します。Javaコマンド行を発行してサーバー・インスタンスを起動するときは、ノード・マネージャは引数をオプションとして渡します。

weblogic.startup.Arguments.prepend

サーバー・インスタンス用に構成された引数の前にフラグを付加します。

weblogic.startup.ClassPath

このサーバー・インスタンスの起動時に使用するクラスパス(ノード・マネージャを実行しているマシン上のパス)。

ノード・マネージャは、CLASSPATH環境変数を使用してこの値を起動スクリプトに渡します。Javaコマンド行を発行してサーバー・インスタンスを起動するときは、クラスパスは-Djava.class.path=で定義されます。

weblogic.startup.JavaVendor

サーバー・インスタンスの起動時に使用されるJavaベンダー値。

Javaコマンド行を呼び出してサーバー・インスタンスを起動するときは、この値はノード・マネージャから渡されません。この値は、環境変数JAVA_VENDORで起動スクリプトに渡されます。

weblogic.startup.MW_Home

このサーバー・インスタンスの起動時に使用されるMW_HOMEディレクトリ(ノード・マネージャを実行しているマシン上のパス)。

この値は、ノード・マネージャから起動スクリプトに渡されません。Javaコマンド行を発行してサーバー・インスタンスを起動するときは、MW_HOMEが-Dbea.home=で指定されます。

weblogic.startup.SecurityPolicyFile

このサーバー・インスタンスの起動時に使用されるセキュリティ・ポリシー・ファイル(ノード・マネージャを実行しているマシン上のディレクトリおよびファイル名)。

ノード・マネージャが起動スクリプトを使用するときは、セキュリティ・ポリシー・ファイルは環境変数SECURITY_POLICYで定義されます。Javaコマンド行を発行してサーバー・インスタンスを起動するときは、セキュリティ・ポリシーが-Djava.security.policy=で定義されます。

weblogic.startup.ServerGID

サーバー・インスタンスのグループID。

weblogic.startup.ServerUID

サーバー・インスタンスのユーザーID。

リモート起動引数の構成

WebLogic Server管理コンソールの、管理対象サーバーの「サーバー」→「構成」→「サーバーの起動」ページで、ノード・マネージャが管理対象サーバーの起動に使用する起動引数を指定します。管理対象サーバーの起動引数を指定しなかった場合は、その管理対象サーバーに適したデフォルト値が使用されます。Javaベース実装を使用する場合は、ノード・マネージャ独自のプロパティが管理対象サーバー起動時のデフォルトとして使用されます。スクリプト・ベース実装を使用する場合は、起動スクリプトによってデフォルト値が設定されます。詳細は、nodemanager.propertiesのレビューを参照してください

それらのデフォルトでも管理対象サーバーを起動することができますが、起動プロセスの一貫性と信頼性を確保するためには、管理対象サーバー・インスタンスごとに起動引数を構成します。指定された起動引数は管理対象サーバーの起動にのみ使用されます。ノード・マネージャによって起動される管理サーバー・インスタンスで使用されることはありません。

「起動サービスとしてのノード・マネージャの実行」に説明されているように、ノード・マネージャをWindowsサービスとして実行する場合は、ノード・マネージャの制御下に置かれる管理対象サーバーごとに-Xrs JVMプロパティを構成する必要があります。

このオプションを設定しない場合、ノード・マネージャはシステムの再起動後に管理対象サーバーを再起動できません。それは、次のような一連のイベントが発生するためです。

1. 再起動が行われると、ノード・マネージャ・サービスと管理サーバーのオペレーティング・システム・サービスが停止される前に、実行中の管理対象サーバーが強制終了されます。

2. 管理対象サーバーの強制終了と、ノード・マネージャ・サービスの停止の間の間隔に、ノード・マネージャは継続して管理対象サーバーをモニターし、それが強制終了されたことを検出し、再起動を行おうとします。

3. マシンが停止しようとしているので、オペレーティング・システムは管理対象サーバーの再起動を許可しません。

4. ノード・マネージャは障害が発生したものとして管理対象サーバーにマークを付け、マシンが再起動したときにそのサーバーを起動しません。

-Xrsオプションまたは-Xnohup オプションを使用して管理対象サーバーを起動すると、マシンの停止時に管理対象サーバーを即座に停止しないようになり、このような一連のイベントが回避されます。

サーバーの起動プロパティの設定

ノード・マネージャを使用して、サーバー・インスタンスの起動プロパティを設定できます。これらのプロパティは、startup.propertiesで定義することも、WLSTなどの管理ユーティリティを使用してオブジェクトとして渡すこともできます。起動プロパティと、その有効な値を設定する方法を、次の項で概説します。

startup.properties

ノード・マネージャは、startup.propertiesファイルを使用して、サーバー・インスタンス起動時の起動構成を決定します。このファイルは、サーバー・インスタンスごとに定義されており、下記の場所に置かれています。DOMAIN_HOME/servers/server_name/data/nodemanager/startup.properties

startup.propertiesの内容は、サーバーMBeanから導出されるか、サーバー・インスタンスがクラスタの一部である場合は、クラスタMBeanから導出されます。詳細は、Oracle WebLogic Server MBeanリファレンスを参照してください。

WLSTを使用して起動プロパティを設定する

WLSTのnmStartコマンドを使用するときは、サーバーの構成を直接特定することはできません。したがって、サーバーの起動プロパティをWLSTプロパティ・オブジェクトとしてnmStartコマンドに渡す必要があります。

サーバーの起動プロパティ

次に示すサーバー起動プロパティは、ノード・マネージャを使用してサーバー・インスタンスを起動するときにサーバー・インスタンスに渡すことができます。

表4-3 サーバーの起動プロパティ

プロパティ

説明

AdminURL

管理サーバーのURL。

注意:この値は、管理対象サーバーのstartup.propertiesファイルにおいてのみ指定します。

Arguments

サーバー・インスタンスの起動時に使用される引数。

AutoKillIfFailed

サーバー・インスタンスがノード・マネージャによって起動されるときに、この属性によって、OverloadProtectionMBeanの設定がFailureAction == FORCE_SHUTDOWNおよびPanicAction == SYSTEM_EXITに変更されます。FailureActionおよびPanicActionの詳細は、OverloadProtectionMBeanに関する項を参照してください。

AutoRestart

このサーバー・インスタンスで障害が発生した場合にノード・マネージャが自動的に再起動できるかどうかを指定します。

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

ClassPath

サーバー・インスタンスの起動時に使用されるクラス・パス。

JavaHome

サーバー・インスタンスの起動時に使用されるJavaホーム・ディレクトリを定義します。

OracleHome

サーバー・インスタンスの起動時に使用されるOracleホーム・ディレクトリ。

RestartDelaySeconds

ノード・マネージャがサーバー・インスタンスの再起動を試行する前に待機する秒数。

RestartInterval

障害が発生したサーバー・インスタンスの再起動をノード・マネージャが試行する時間の長さ。この期間中、ノード・マネージャはRestartMaxで定義された回数まで、障害の発生したサーバーを再起動しようとします。デフォルトでは、ノード・マネージャはFAILED_NOT_RESTARTABLE状態に到達するまで無期限にサーバー・インスタンスの再起動を試行します。

RestartMax

ノード・マネージャが、RestartIntervalで定義した間隔内で障害の発生したサーバーの再起動を試行する回数。RestarMaxは、RestartIntervalが定義されている場合のみ認識されます。

SecurityPolicyFile

このサーバーを起動する際に使用するセキュリティ・ポリシー・ファイルを指定します。

ServerIP

サーバーのIPアドレス。

SSLArguments

これらの引数は、ドメイン全体の管理ポートを有効化した場合に使用されます。

ノード・マネージャの環境変数の設定

デフォルトでは、ノード・マネージャを起動する前に追加の環境変数を設定する必要はありません。WebLogic Serverとともに提供されるノード・マネージャのサンプル起動スクリプトおよびインストール・サービス・スクリプトでは、必須の変数が設定され、ノード・マネージャのデフォルト・アドレスlocalhostへのリスニングを開始します。

デフォルト以外のアドレスでノード・マネージャのリスニングを開始するには、次のいずれかの方法を使用します。

- nodemanager.propertiesファイルを編集します。
LISTEN_ADDRESS変数を<host>に、LISTEN_PORT変数を<port>に設定してからstartNodeManagerスクリプトを呼び出します。「nodemanager.propertiesのレビュー」を参照してください。

- startNodeManagerスクリプトの実行時に値を設定します。
startNodeManagerスクリプトは、コマンド行から入力した最初の2つの位置指定パラメータをLISTEN_ADDRESSおよびLISTEN_PORTに設定します。

たとえば、ノード・マネージャをホストllamaおよびポート7777で起動するには次のコマンドを入力します。

startNodeManager.cmd llama 7777 (Windows)
sh startNodeManager.sh llama 7777 (UNIX)

ノード・マネージャをホストllamaで起動するには次のコマンドを入力します。

startNodeManager.cmd llama (Windows)
sh startNodeManager.sh llama (UNIX)

本番環境では、ノード・マネージャに対してデフォルト以外のリスニング・アドレスを構成すると、他のマシンからのトラフィックがノード・マネージャまで到達しやすくなります。また、マルチホーム・マシンや複数のネットワーク・インタフェース・カードがあるマシンでは、ノード・マネージャはマシン上のいずれかのアドレスをリスニングできます。

表4-4 ノード・マネージャの環境変数

環境変数

説明

CLASSPATH

ノード・マネージャCLASSPATHは、ノード・マネージャを起動するためのjavaコマンド行のオプション、または環境変数として設定できます。

Windows NTの例:

set CLASSPATH=.;%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\
weblogic.jar

JAVA_HOME

ノード・マネージャで使用されるJDKルート・ディレクトリ。例:

set JAVA_HOME=c:\jdk1.7.0_06

ノード・マネージャには、WebLogic Serverと同じJDKのバージョンに関する必要条件があります。

LD_LIBRARY_PATH

(UNIXおよびLinux)

Solarisシステムの場合、ネイティブ・ノード・マネージャ・ライブラリのパスを指定する必要があります。

Solarisの例:

LD_LIBRARY_PATH:$WL_HOME/server/lib/solaris:$WL_HOME/server/lib/solaris/oci816_8

Linuxの例:

LD_LIBRARY_PATH:$WL_HOME/server/native/linux:$WL_HOME/server/native/linux/i686

注意: Linuxはi686、ia64、またはx86_64アーキテクチャが可能です。該当するアーキテクチャに応じてパスは変わる可能性があります。

PATH

WebLogic ServerのbinディレクトリとJava実行ファイルのパスを指定する必要があります。例:

set PATH=%WL_HOME%\server\bin;%JAVA_HOME%\bin;%PATH%

WL_HOME

WebLogic Serverのインストール・ディレクトリ。例:

set WL_HOME=c:\Oracle\Middleware\Oracle_Home\wlserver

xinetdサービスとしてのノード・マネージャの構成

inetdまたはxinetdサービスとして実行するようにノード・マネージャを構成する場合は、次の考慮事項が適用されます。

- NodeManagerHomeおよび他のシステム・プロパティが定義されていることを確認します。

- xinetdがlibwrapと共に構成されている場合は、NOLIBWRAPフラグを追加する必要があります。

- hosts.denyおよびhosts.allowファイルが適切に構成されていることを確認します。

- ネットワーク環境によっては、追加の構成が必要になる場合があります。

次の例では、xinetd内にノード・マネージャを構成する方法を示します。

#
# Create the $domaindir/bin/startNMService.sh script or the
# $WL_HOME/server/bin/startNMService.sh script to produce output to a file.
#

#!/bin/sh

$domaindir/bin/startNodeManager.sh >> $NM_HOME/nmservice.out 2>&1

#
# The service can now take advantage of the startNMService script.
#

# default: off
# description:nodemanager as a service

service nodemanager-svc
{
type            = UNLISTED
disable         = yes
socket_type     = stream
protocol        = tcp
wait            = yes
user            = <username>
port            = 5556
flags           = NOLIBWRAP
log_on_success += DURATION HOST USERID
server          = /scratch/jdorr/dom1213/bin/startNMService.sh
env             = MW_HOME=/Oracle/Middleware/Oracle_Home_WLS_12.2.1 JAVA_HOME=/Java/jdk1.7.0_51LD_LIBRARY_PATH=/Oracle/Middleware/Oracle_Home_WLS_12.2.1/bea/wlserver/server/native/linux/x86_64:/usr/lib:/lib:/usr/X11R6/lib
}

init.dサービスとしてのノード・マネージャの構成

ノード・マネージャは、init起動スクリプトを使用してinit.dサービスとして構成できます。この項には次のトピックが含まれます:

- init.dサービスとしてのドメインごとのノード・マネージャの構成

- init.dサービスとしてのホストごとのノード・マネージャの構成

init.dサービスとしてのドメインごとのノード・マネージャの構成

ドメインごとのノード・マネージャをinit.dサービスとしてインストールおよび構成するには、次の手順を実行します。すべてのアクションをrootユーザーとして実行します。

注意:
ノード・マネージャがinit.dサービスとして実行されている場合、起動された管理対象サーバーはrootユーザーによって所有されています。管理対象サーバーをroot以外のユーザーとして起動するには、管理コンソールを使用して、「ドメイン」→「環境」→「マシン」→「構成」→「一般」ページで「バインド後のユーザーID」属性および「バインド後のグループID」属性を有効にします。その後、ノード・マネージャおよび管理サーバーを再起動してから、管理対象サーバーを再起動します。

1. サービス名を決定します。以降の手順では、このサービス名を<service name>と表記します。

命名のパターンをDOMAIN_NAME-nodemanager (base_domain-nodemanagerなど)とすることをお薦めします。

2. 例4-3のサンプル・スクリプトを/etc/init.d/<service name>にコピーします。

3. /etc/init.d/<service name>を編集し、次に示す変数を実際の環境およびインストールに合せて変更します。

- 例4-3の###BEGIN INIT INFOセクションにあるProvides設定。

- 例4-3の###BEGIN CUSTOM ENVセクションにあるDOMAIN_HOME設定。

4. chmod +xコマンドを使用して/etc/init.d/<service name>を実行可能にします。

5. init.dサービスを、sudo /sbin/chkconfig --add <service name>で追加します。

6. サービスを起動、停止、再起動する、またはステータスを表示するには、次のコマンドを使用します。

タスク

コマンド

サービスを起動するには:

sudo /sbin/service <service name> start

サービスを停止するには:

sudo /sbin/service <service name> stop

サービスを再起動するには:

sudo /sbin/service <service name> restart

サービスのステータスを表示するには:

sudo /sbin/service <service name> status

例4-3 init.dサービスとしてのドメインごとのノード・マネージャの構成

#!/bin/sh
#
# chkconfig:   345 85 15
# description: per domain Oracle Weblogic Node Manager service init script

### BEGIN INIT INFO
# Provides: jtest-dom1213-nodemanager
# Required-Start: $network $local_fs
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start: 3 4 5
# Default-Stop: 0 1 2 6
# Short-Description: per domain Oracle Weblogic Node Manager service.
# Description: Starts and stops per domain Oracle Weblogic Node Manager.
### END INIT INFO

. /etc/rc.d/init.d/functions

#### BEGIN CUSTOM ENV
DOMAIN_HOME="/scratch/jdorr/dom1213"
MW_HOME=/Oracle/Middleware/Oracle_Home_WLS_12.2.1
JAVA_HOME=/Java/jdk1.7.0_51
LD_LIBRARY_PATH=/Oracle/Middleware/Oracle_Home_WLS_12.2.1/bea/wlserver/server/native/linux/x86_64:/usr/lib:/lib:/usr/X11R6/lib
#### END CUSTOM ENV

PROCESS_STRING="^.*$DOMAIN_HOME.*weblogic.NodeManager.*"
PROGRAM_START="$DOMAIN_HOME/bin/startNodeManager.sh"
NODEMANAGER_DIR=$DOMAIN_HOME/nodemanager
NODEMANAGER_LOCKFILE="$NODEMANAGER_DIR/nodemanager.log.lck"
OUT_FILE="$NODEMANAGER_DIR/nodemanager.out"

SERVICE_NAME=`/bin/basename $0`
LOCKFILE="/var/lock/subsys/$SERVICE_NAME"

RETVAL=0

start() {
OLDPID=`/usr/bin/pgrep -f $PROCESS_STRING`
if [ ! -z "$OLDPID" ]; then
echo "$SERVICE_NAME is already running (pid $OLDPID) !"
echo
exit
fi
echo -n $"Starting $SERVICE_NAME ... "
echo "`date` Starting $SERVICE_NAME ... " > $OUT_FILE 2>&1
export MW_HOME
export JAVA_HOME
export LD_LIBRARY_PATH
$PROGRAM_START >> $OUT_FILE 2>&1  &

RETVAL=$?
if [ $RETVAL -eq 0 ] ; then
wait_for "socket listener started on port"
else
echo "FAILED: $RETVAL. Please check $OUT_FILE for more information."
fi
echo
}

wait_for() {
res=$(cat "$OUT_FILE" | fgrep -c "$1")
count=60
while [[ ! $res -gt 0 ]] && [[ $count -gt 0 ]]
do
sleep 1
count=$(($count - 1))
res=$(cat "$OUT_FILE" | fgrep -c "$1")
done
res=$(cat "$OUT_FILE" | fgrep -c "$1")
if [ ! $res -gt 0 ]; then
echo "FAILED or took too long time to start. Please check $OUT_FILE for more information."
else
echo "OK"
touch $LOCKFILE
fi
}

stop() {
echo -n $"Stopping $SERVICE_NAME ... "
OLDPID=`/usr/bin/pgrep -f $PROCESS_STRING`
if [ "$OLDPID" != "" ]; then
echo -n "(pid $OLDPID) "
/bin/kill -TERM $OLDPID

RETVAL=$?
echo "OK"
/bin/rm -f $NODEMANAGER_LOCKFILE
[ $RETVAL -eq 0 ] && rm -f $LOCKFILE
else
/bin/echo "$SERVICE_NAME is stopped"
fi
echo
}

restart() {
stop
sleep 10
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart|force-reload|reload)
restart
;;
condrestart|try-restart)
[ -f $LOCKFILE ] && restart
;;
status)
OLDPID=`/usr/bin/pgrep -f $PROCESS_STRING`
if [ "$OLDPID" != "" ]; then
/bin/echo "$SERVICE_NAME is running (pid: $OLDPID)"
else
/bin/echo "$SERVICE_NAME is stopped"
fi
echo
RETVAL=$?
;;
*)
echo $"Usage: $0 {start|stop|status|restart|reload|force-reload|condrestart}"
exit 1
esac

exit $RETVAL

init.dサービスとしてのホストごとのノード・マネージャの構成

ホストごとのノード・マネージャをinit.dサービスとしてインストールおよび構成するには、次の手順を実行します。すべてのアクションをrootユーザーとして実行します。

開始する前に、ホストごとのノード・マネージャがドメイン内で正しく構成されていることを確認し、その後でこのスクリプトを使用してください。「ホストごとのノード・マネージャの構成」を参照してください

1. サービス名を決定します。以降の手順では、このサービス名を<service name>と表記します。

命名のパターンを<a brief name for MW_HOME>-nodemanager (wls12.2.1-nodemanagerなど)とすることをお薦めします。

2. 例4-4のサンプル・スクリプトを/etc/init.d/<service name>にコピーします。

3. /etc/init.d/<service name>を編集し、次に示す変数を実際の環境およびインストールに合せて変更します。

- 例4-4の###BEGIN INIT INFOセクションにあるProvides設定。

- 例4-4の###BEGIN CUSTOM ENVセクションにあるMW_HOME設定。

4. chmod +xコマンドを使用して/etc/init.d/<service name>を実行可能にします。

5. init.dサービスを、sudo /sbin/chkconfig --add <service name>で追加します。

6. サービスを起動、停止、再起動する、またはステータスを表示するには、次のコマンドを使用します。

タスク

コマンド

サービスを起動するには:

sudo /sbin/service <service name> start

サービスを停止するには:

sudo /sbin/service <service name> stop

サービスを再起動するには:

sudo /sbin/service <service name> restart

サービスのステータスを表示するには:

sudo /sbin/service <service name> status

例4-4 init.dサービスとしてのホストごとのノード・マネージャの構成

#!/bin/sh
#
# chkconfig:   345 85 15
# description: global (per host) Oracle Weblogic Node Manager service init script

### BEGIN INIT INFO
# Provides: jjjnm
# Required-Start: $network $local_fs
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start: 3 4 5
# Default-Stop: 0 1 2 6
# Short-Description: per host Oracle Weblogic Node Manager service
# Description: Starts and stops per host Oracle Weblogic Node Manager
### END INIT INFO

. /etc/rc.d/init.d/functions

#### BEGIN CUSTOM ENV
MW_HOME=/Oracle/Middleware/Oracle_Home_WLS_12.2.1
JAVA_HOME=/Java/jdk1.7.0_51
LD_LIBRARY_PATH=/Oracle/Middleware/Oracle_Home_WLS_12.2.1/bea/wlserver/server/native/linux/x86_64:/usr/lib:/lib:/usr/X11R6/lib
#### END CUSTOM ENV

PROGRAM_START="$MW_HOME/wlserver/server/bin/startNodeManager.sh"
NODEMANAGER_DIR="$MW_HOME/wlserver/../oracle_common/common/nodemanager"
NODEMANAGER_LOCKFILE="$NODEMANAGER_DIR/nodemanager.log.lck"
OUT_FILE="$NODEMANAGER_DIR/nodemanager.out"
PROCESS_STRING="^.*\-Dweblogic.RootDirectory=$NODEMANAGER_DIR.*weblogic.NodeManager.*"

SERVICE_NAME=`/bin/basename $0`
LOCKFILE="/var/lock/subsys/$SERVICE_NAME"

RETVAL=0

start() {
OLDPID=`ps -e -o pid,command:1000 | grep "$PROCESS_STRING" | grep -v " grep " | awk '{print $1}'`
if [ ! -z "$OLDPID" ]; then
echo "$SERVICE_NAME is already running (pid $OLDPID) !"
echo
exit
fi

if [ ! -e "$NODEMANAGER_DIR" ]; then
echo "$NODEMANAGER_DIR does not exist. The per host Node Manager is not configured correctly."
echo "Please follow steps in Pre-Condition section before using this script."
echo
exit
fi

echo -n $"Starting $SERVICE_NAME ... "
echo "`date` Starting $SERVICE_NAME ... " > $OUT_FILE 2>&1
export MW_HOME
export JAVA_HOME
export LD_LIBRARY_PATH
$PROGRAM_START >> $OUT_FILE 2>&1  &

RETVAL=$?
if [ $RETVAL -eq 0 ] ; then
wait_for "socket listener started on port"
else
echo "FAILED: $RETVAL. Please check $OUT_FILE for more information."
fi
echo
}

wait_for() {
res=$(cat "$OUT_FILE" | fgrep -c "$1")
count=60
while [[ ! $res -gt 0 ]] && [[ $count -gt 0 ]]
do
sleep 1
count=$(($count - 1))
res=$(cat "$OUT_FILE" | fgrep -c "$1")
done
res=$(cat "$OUT_FILE" | fgrep -c "$1")
if [ ! $res -gt 0 ]; then
echo "FAILED or took too long time to start. Please check $OUT_FILE for more information."
else
echo "OK"
touch $LOCKFILE
fi
}

stop() {
echo -n $"Stopping $SERVICE_NAME ... "
OLDPID=`ps -e -o pid,command:1000 | grep "$PROCESS_STRING" | grep -v " grep " | awk '{print $1}'`
if [ "$OLDPID" != "" ]; then
echo -n "(pid $OLDPID) "
/bin/kill -TERM $OLDPID

RETVAL=$?
echo "OK"
/bin/rm -f $NODEMANAGER_LOCKFILE
[ $RETVAL -eq 0 ] && rm -f $LOCKFILE
else
/bin/echo "$SERVICE_NAME is stopped"
fi
echo
}

restart() {
stop
sleep 10
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart|force-reload|reload)
restart
;;
condrestart|try-restart)
[ -f $LOCKFILE ] && restart
;;
status)
OLDPID=`ps -e -o pid,command:1000 | grep "$PROCESS_STRING" |grep -v " grep " | awk '{print $1}'`
if [ "$OLDPID" != "" ]; then
/bin/echo "$SERVICE_NAME is running (pid: $OLDPID)"
else
/bin/echo "$SERVICE_NAME is stopped"
fi
echo
RETVAL=$?
;;
*)
echo $"Usage: $0 {start|stop|status|restart|reload|force-reload|condrestart}"
exit 1
esac

exit $RETVAL

5 スクリプト・ベースのノード・マネージャの構成

この章では、スクリプトベースのノード・マネージャを構成する方法について説明します。

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

- 概要

- ステップ1: ユーザー・アカウントの作成

- ステップ2: ノード・マネージャのセキュリティの構成

- ステップ3: WebLogic Serverのインストール

- ステップ4: WebLogicドメインの作成

- ステップ5: nodemanager.domainsファイルの構成

- ステップ6: 管理サーバーの起動

- ステップ7: 管理対象サーバーでのノード・マネージャの構成

- ステップ8: 管理対象サーバーの起動によるノード・マネージャの設定と構成のテスト

- ステップ9: UNIXマシンの構成

- ステップ10: マシンへのサーバーの割当

- ステップ11: 管理対象サーバーの起動

- デフォルトのSSHポートのオーバーライド

- WebLogic Serverスクリプトのセキュリティの構成

- スクリプト・ベースのノード・マネージャ用のリモート・サーバー起動セキュリティの構成

- キーと値のペアの生成と配布

概要

スクリプト・ベースのノード・マネージャは、WL_HOME/common/bin/にあるシェル・スクリプトwlscontrol.shです。wlscontrol.shファイルは、ノード・マネージャを使用して制御するサーバー・インスタンスをホストするマシンごとに存在していなければなりません。このスクリプトは、サイト固有の要件を満たすようにカスタマイズできます。

ノード・マネージャまたはノード・マネージャ・クライアントを実行するマシンごとにSSHクライアントが実行可能でなければなりません。また、このスクリプトはユーザーIDが実行するパス内になければなりません。通常、SSHクライアントはUNIXまたはLinuxインストールの標準的な一部です。

ステップ1: ユーザー・アカウントの作成

ノード・マネージャを実行する前に、ノード・マネージャ機能の実行専用のUNIXユーザー・アカウントを作成する必要があります。このユーザーを、スクリプト・ベースのノード・マネージャをホストするすべてのマシンと、ノード・マネージャ・クライアント(これには管理サーバーも含まれます)をホストするすべてのマシンに追加します。

注意:

UNIXプラットフォームでは、ノード・マネージャのrootユーザーとしての実行はお薦めしません。ただし、バインド後のグループIDを取得するには、ノード・マネージャをrootユーザーとして実行する必要があります。バインド後のグループIDを使用すると、ご使用のマシンで稼働するサーバーが、すべての権限のある起動アクションの実行後に、UNIXグループID (GID)にバインドできるようになります。

例:

1. 各ホスト・マシンで、ルート・ユーザーとして、2つの新しいオペレーティング・システム(OS)ユーザー(beaおよびndmgr)を作成し、これらをbeaという新しいグループに関連づけます。

- beaはWebLogic Serverのインストールにのみ使用します。

- ndmgrは、WebLogicドメインの作成や、管理サーバーとリモート管理対象サーバーの起動をノード・マネージャで実行するために使用します。

2. ndmgrでWebLogicスクリプトおよび実行可能ファイルを実行できる適切な許可が与えられるよう、どちらのOSユーザーのOSグループも同じ(bea)にする必要があります。
例:

> groupadd bea

> useradd -g bea -m bea

> passwd bea

> useradd -g bea -m ndmgr

> passwd ndmgr

ステップ2: ノード・マネージャのセキュリティの構成

ノード・マネージャのSSHシェル・スクリプトは、異なるマシン上のユーザー間のセキュアな信頼関係を提供する、SSHユーザー・ベースのセキュリティに依存します。認証は必要ありません。ノード・マネージャのコマンドおよびスクリプトを実行するためのUNIXユーザー・アカウントを作成します(通常はドメインごとに1つ)。このユーザーとしてログインしたユーザーは、ユーザー名とパスワードを指定しなくてもノード・マネージャ・コマンドを発行できます。

注意:

ノード・マネージャ・コマンドとWebLogic Serverコマンドが、コマンドの実行に使用されるUNIXユーザーIDのパスで使用可能になっていることを確認する必要もあります。ユーザーの環境ファイルを変更し、WL_HOME/common/bin/またはDOMAIN_HOME/bin/server_migrationへのパスが含まれるようにします。

例:

PATH=/usr/bin:/bin:ORACLE_HOME/user_projects/domains/domain_name/bin/server_migration

WebLogic Serverインスタンスを実行する各マシン上のndmgrユーザーと、同じマシン上の同じndmgrユーザー、さらに他の各マシン上の対応するndmgrユーザーの間でSSHによる信頼関係を構成します。

すなわち、あるマシン上の任意のndmgrユーザーは、同じマシンまたは異なるマシン上の同じ名前のndmgrユーザーと、セキュリティ資格証明を求められることなくSSHセッションを確立できる必要があります。これは、管理対象サーバーが移行可能なサーバーのクラスタ・マスターになり、SSHを使用してクラスタ内の他のリモート管理対象サーバーを起動するコマンドを発行できるために必要です。ndmgrユーザーがSSHを使用してwlscontrol.shスクリプトを実行できさえすれば、管理対象サーバーの移行は機能します。詳細は、「WebLogic Serverスクリプトのセキュリティの構成」を参照してください。

たとえば、SSH version2で、ユーザーのあるインスタンスが別のインスタンスを信頼するように構成するには:

1. ターミナルからndmgrユーザーとしてログインします。
> ssh-keygen -t dsa

2. プロンプトが表示された場合はデフォルトの場所を受け入れ、パスフレーズに対して「Enter」を押し、パスフレーズを指定しないようにします。

3. ndmgrユーザーの公開鍵を、同じマシンおよびその他すべてのマシン上のndmgrユーザーのホーム・ディレクトリにコピーします。
> scp .ssh/id_dsa.pub ndmgr@192.168.1.101:./

4. ndmgrユーザーとしてターゲット・マシンとSSHセッションを確立し、リモートndmgrユーザーの信頼関係を設定します。
> ssh -l ndmgr 192.168.1.101 (you should be prompted for password)

> mkdir .ssh

> chmod 700 .ssh

> touch .ssh/authorized_keys

> chmod 700 .ssh/authorized_keys

> cat id_dsa.pub >> .ssh/authorized_keys

> rm id_dsa.pub

> exit

5. パスワードを要求せずに、リモート・マシン上のndmgrユーザーとSSHセッションを確立できるかどうかをテストします。
> ssh -l ndmgr 192.168.1.101

6. すべてのマシンの組み合わせでこのプロセスを繰り返します。

あるいは、各マシンでキーと値のペアを生成し、すべての公開鍵を1つのauthorized_keysファイルに連結し、そのファイルをすべてのマシンにコピー(scp)しても、同じ結果が得られます。すべてのマシンの組み合わせでSSHセッションの確立を試行し、~/.ssh/known_hostsファイルが適切に構成されていることを確認します。詳細は、「キーと値のペアの生成と配布」を参照してください。

ステップ3: WebLogic Serverのインストール

beaユーザーとして、WebLogic Serverを実行するすべてのマシンで、WebLogic Serverインスタンスをベース・ディレクトリORACLE_HOME/wlserver内にインストールします。ORACLE_HOMEは、WebLogic Serverのインストール時にOracleホームとして指定するディレクトリを表します(C:\Oracle\Middleware\Oracle_Homeなど)。

例:

> java -jar wls_jrf_generic.jar

詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』のインストール・プログラムの起動に関する項を参照してください。

ステップ4: WebLogicドメインの作成

ndmgrユーザーのホーム・ディレクトリで、管理サーバーのみをホストするマシン上にWebLogicドメインを作成します。

このドメイン・ディレクトリのconfigサブディレクトリにある構成は、後で管理サーバーを起動する際、管理サーバーとドメインの設定を特定するために使用されます。

多くの場合、管理対象サーバー・インスタンスは、管理サーバーに対してリモートに実行されます。したがって、これらの管理対象サーバーは、管理サーバーのドメイン構成ディレクトリに直接アクセスすることはありません。代わりに、管理対象サーバーは、個々のマシンのndmgrホーム・ディレクトリにあるスケルトン・ドメイン・ディレクトリから実行され、起動時に、リモートに実行されている管理サーバーからネットワークを介して構成を取得します。

ndmgrユーザーとして、WebLogicドメインを作成します。

例:

1. 構成ウィザードを実行します。
> ORACLE_HOME/wlserver/common/bin/config.sh

2. デフォルトのWebLogic Serverテンプレートに基づき、WebLogicドメインを新たに作成します。

3. 管理サーバーには、固定IPアドレス(192.168.1.100など)を指定します。

4. 「環境とサービスの設定のカスタマイズ」で「はい」を選択します。

5. 「管理対象サーバーの構成」で、2つの管理対象サーバー、MS1およびMS2を追加します。
管理対象サーバーには、浮動IPアドレス(192.168.1.201および192.168.1.202など)を指定します。

6. クラスタの構成で、クラスタCLUSTを追加し、このクラスタにMS1およびMS2を割り当てます。
マシンやUNIXマシンの指定は後で手動で行うため、ここでは実行しません。

7. ドメインの名前をclustdomainとして、ORACLE_HOME/clustdomainに保存します。

ステップ5: nodemanager.domainsファイルの構成

nodemanager.domainsファイルには、ノード・マネージャ・インスタンスが制御するドメインを指定します。このため、スタンドアロンのクライアントではドメイン・ディレクトリを明示的に指定する必要はありません。

このファイルには、ノード・マネージャ・インスタンスが制御する各ドメインのドメイン・ディレクトリを次の形式で指定するエントリが含まれている必要があります。

domain-name=domain-directory

ユーザーがドメインに対してコマンドを発行すると、ノード・マネージャはnodemanager.domainsからドメイン・ディレクトリをルックアップします。

このファイルではノード・マネージャ・クライアントのアクセスがファイル内に表示されたドメインに制限されるので、セキュリティがさらに強化されます。クライアントは、nodemanager.domainsに表示されたドメインに対してのみコマンドを実行できます。

スクリプト・ベースのノード・マネージャでは、このファイルのデフォルトの場所はWL_HOME/common/nodemanagerになります。WL_HOMEはWebLogic Serverのインストール先ディレクトリ(ORACLE_HOME/wlserverなど)です。

スクリプト・ベース実装のノード・マネージャを使用する場合は、NodeManagerHomeに、ノード・マネージャ・インスタンスで制御するドメインを指定するnodemanager.domainsファイルを作成またはコピーする必要があります。あるいは、WLSTコマンドnmEnrollを使用して、WebLogicドメインをスクリプトベースのノード・マネージャに登録することも可能です。詳細は、「nodemanager.domainsファイルの構成」を参照してください

ステップ6: 管理サーバーの起動

管理サーバーを起動する標準的な方法は、用意されているstartWebLogicスクリプトを使用するというものですが、かわりにスクリプト・ベース実装のノード・マネージャで管理サーバーを監視して高可用性を保証することもできます。本番ドメインを使用する場合は、正常に起動できるように管理サーバーのboot.propertiesを作成します。ndmgrユーザーとして、wlscontrol.shノード・マネージャ・スクリプトを使用してターミナルからローカルに管理サーバーを起動します。

例:

> ORACLE_HOME/wlserver/common/bin/wlscontrol.sh -d clustdomain -r
ORACLE_HOME/clustdomain -c -f startWebLogic.sh -s AdminServer START

標準出力に冗長ロギングするには、コマンドに-vパラメータを追加します。

注意:

管理サーバーが正常に起動し、boot.propertiesファイルの作成が完了した後は、管理サーバーをリモート起動できます。ノード・マネージャのスクリプトstopWebLogic.shを使用して管理サーバーを停止します。その後で、SSHを使用して管理サーバーをリモート起動します。

例:

> ssh -l ndmgr -o PasswordAuthentication=no 192.168.1.100
ORACLE_HOME/wlserver/common/bin/wlscontrol.sh -d clustdomain -r /home/ndmgr/clustdomain -c -f startWebLogic.sh -s AdminServer START

ステップ7: 管理対象サーバーでのノード・マネージャの構成

管理対象サーバーをホストする各マシンでは、スケルトン・ドメインを作成し、構成します。

1. ローカルのターミナルから、各管理対象サーバー・ホスト・マシンおよびバックアップ・マシンのndmgrユーザーのホーム・ディレクトリに、空のディレクトリ(clustdomain)を新たに作成します。例:
> mkdir clustdomain

2. 各管理対象サーバー・ホスト・マシンおよびバックアップ・マシンで、ndmgrユーザーとしてWLSTを使用し、サーバーのリモート実行用およびノード・マネージャ用のベース・ディレクトリとしてユーザーのホーム・ディレクトリを登録します。
例:

> ORACLE_HOME/wlserver/common/bin/wlst.sh

> connect('weblogic','weblogic','t3://192.168.1.100:7001')

> nmEnroll('/home/ndmgr/clustdomain','/home/ndmgr')

> exit()

nmEnrollは、各リモート・マシンに対して実行してください。このコマンドにより、プロパティ・ファイル/home/ndmgr/nodemanager.domainsが生成され、ドメイン名がホーム・ディレクトリにマップされ、必要なドメイン構成とセキュリティ情報が作成されるため、管理対象サーバーは管理サーバーと通信できるようになります。

このnodemanager.domainsファイルにより、wlscontrol.shの起動時に-rを使用してドメイン・ホーム・ディレクトリを指定せずに済みます。ただし、ノード・マネージャのホーム・ディレクトリを変更したため、-n /home/ndmgrを指定する必要があります。ノード・マネージャのデフォルトのホーム・ディレクトリはORACLE_HOME/wlserver/common/nodemanagerですが、このディレクトリは製品のインストール・ディレクトリ内にあり、他のユーザーが所有するため、使用しないことをお薦めします。

注意:

デフォルトでは、任意のディレクトリからノード・マネージャを起動できます。nodemanager.domainsファイルが見つからない場合、警告が発行されます。ノード・マネージャ・インスタンスで制御するドメインを指定するnodemanager.domainsファイルを、NodeManagerHomeに作成またはコピーするか、WLSTコマンドnmEnrollを使用してWebLogicドメインを登録する必要があります。

ステップ8: 管理対象サーバーの起動によるノード・マネージャの設定と構成のテスト

1. 管理サーバーのドメインbinディレクトリのスクリプトを、各ノード・マネージャ・マシン上の対応するドメインbinディレクトリ(/home/ndmgr/binなど)にコピーします。例:
> scp ndmgr@192.168.1.100:"~/clustdomain/bin/*" ndmgr@192.168.1.101:~/clustdomain/bin

2. バックアップ・マシンを含む各ノード・マネージャ・マシンで、binディレクトリ内のシェル・スクリプトを編集し、ローカル・ドメイン・ホームの適切なパスとリモート管理サーバーのIPアドレスを反映させます。
例:

a. setDomainEnv.shスクリプト内のDOMAIN_HOMEおよびLONG_DOMAIN_HOME変数を編集し、このリモート・ホーム・ディレクトリを適切に反映させます: DOMAIN_HOME=/home/ndmgr/clustdomain

b. LONG_DOMAIN_HOME=/home/ndmgr/clustdomain

c. 同様に、startWebLogic.sh内のDOMAIN_HOME変数を編集します。

d. startManagedWebLogic.sh内のDOMAIN_HOMEおよびADMIN_URL変数(t3://192.168.1.100:7001など)を編集します。

3. バックアップ・マシンを含む各管理対象サーバー・ホスト・マシンに対し、ndmgrユーザーとして、ドメイン・ディレクトリにserver/securityサブディレクトリを作成します。
たとえば、管理対象サーバーがMS1の場合は次のように指定します。

> mkdir -p ~/clustdomain/servers/MS1/security

注意:

バックアップ・マシンでは、すべての移行可能管理対象サーバー(たとえば、MS1とMS2)のサーバー・ディレクトリを作成します。

4. 適切なユーザー名変数とパスワード変数が指定されたboot.propertiesファイルを、各管理対象サーバーのsecurityディレクトリ(/home/ndmgr/clustdomain/servers/MS1/securityなど)に新たに作成します。
例:

username=weblogic

password=password

注意:

このファイル内の値は、スクリプト・ベースのノード・マネージャで管理対象サーバーを初めて起動するときに暗号化されます。

5. 各管理対象サーバー・マシンについて、ndmgrユーザーとして、wlscontrol.shノード・マネージャ・スクリプトを使用してターミナルからローカルに管理対象サーバーを起動します。
たとえば、管理対象サーバーMS1を起動するには、次のように指定します。

> ORACLE_HOME/wlserver/common/bin/wlscontrol.sh -d clustdomain -n /home/ndmgr -c -f startManagedWebLogic.sh -s MS1 START

標準出力に冗長ロギングするには、コマンドに-vパラメータを追加します。

6. 正常に起動したら、その管理対象サーバーを停止してから、ndmgrユーザーとしてSSHを使用してリモートからの再起動を試みます。
たとえば、MS1を起動するには、次のように指定します。

> ssh -l ndmgr -o PasswordAuthentication=no -p 22 192.168.1.101 ORACLE_HOME/wlserver/common/bin/wlscontrol.sh -d clustdomain -n /home/ndmgr -c -f startManagedWebLogic.sh -s MS1 START

7. 正常に起動したら、その管理対象サーバーを再び停止し、バックエンド・マシン上の各管理対象サーバー(MS1)の起動を試行してこのプロセスを繰り返します。正常に起動する度に、そのサーバーを停止してください。

ステップ9: UNIXマシンの構成

WebLogic Server管理コンソールを使用して、管理サーバーまたは管理対象サーバーをホストするマシンごとに(バックアップ・マシンも含む)新しいUNIXマシンを追加し、次の設定を含めます。

表5-1 UNIXマシンの設定

プロパティ

値

OSの種類

UNIX

ノード・マネージャの種類

SSH

ノード・マネージャのリスニング・アドレス

<primary-ip-address>(浮動IPアドレスではない)

ノード・マネージャのリスニング・ポート

22

ノード・マネージャのホーム・ディレクトリ

/home/ndmgr

ノード・マネージャのシェル・コマンド

ssh -l ndmgr -o PasswordAuthentication=no -p %P %H
ORACLE_HOME/wlserver/common/bin/wlscontrol.sh -d %D
-n /home/ndmgr -c -f startManagedWebLogic.sh -s %S %C

ノード・マネージャのデバッグの有効化

true

サーバー

<マシンでホストした管理サーバー名または管理対象サーバー名>

ステップ10: マシンへのサーバーの割当

すべてのUNIXマシンが作成されたら、WebLogic Server管理コンソールを使用して各サーバーの「マシン」プロパティを設定し、各サーバーが対応するUNIXマシンに関連付けられるようにします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・インスタンスのマシンへの割当てに関する項を参照してください。

ステップ11: 管理対象サーバーの起動

WebLogic Server管理コンソールで、各管理対象サーバーを起動します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理コンソールからの管理対象サーバーの起動に関する項を参照してください。

各管理対象サーバーの/home/ndmgr/clustdomain/servers/managed_server_name/logsディレクトリにあるサーバー・ログで、サーバーがエラーなく起動していることを確認します。

スクリプト・ベースのノード・マネージャのセキュリティの構成

この項には次のトピックが含まれます:

- デフォルトのSSHポートのオーバーライド

- WebLogic Serverスクリプトのセキュリティの構成

- スクリプト・ベースのノード・マネージャ用のリモート・サーバー起動セキュリティの構成

- キーと値のペアの生成と配布

デフォルトの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ポートを編集できます。

WebLogic Serverスクリプトのセキュリティの構成

サーバーの移行などのタスクを実行するには、wlscontrol.shなどのスクリプトを実行するユーザーIDに十分なセキュリティ・許可が必要です。たとえば、ネットワーク・インタフェースを通じてIPアドレスをオンラインにしたり、オフラインにしたりできる許可などです。

サーバーの移行は、サーバーに障害が発生したことを検出したときに、クラスタ・マスターによって実行されます。クラスタ・マスターはSSHを使用してターゲット・マシンにあるスクリプトを起動し、移行を開始します。ターゲット・マシンにあるスクリプトは、クラスタのマスター上でサーバーを実行しているのと同じユーザーIDで実行されます。

サーバーの移行を実行するために必要なコマンドはwlsifconfigとarpingです。これらのスクリプトには高度なOS権限が必要になるため、セキュリティ・ホールの可能性を防止できる点に留意することが重要です。sudoを使用すると、高度な権限によるwlsifconfigとarpingの実行のみを許可するようにSSHを構成できます。

それらのスクリプトは、WL_HOME/common/bin/ディレクトリまたはDOMAIN_HOME/bin/server_migrationディレクトリにあります。「ステップ2: ノード・マネージャのセキュリティの構成」を参照してください。

スクリプト・ベースのノード・マネージャ用のリモート・サーバー起動セキュリティの構成

ノード・マネージャを使用してサーバー・インスタンスを起動するには、リモート起動ユーザーのユーザー名とパスワードが必要です。管理サーバーと管理対象サーバーでは、これらの資格証明の指定方法が異なります。

- 管理対象サーバーの資格証明 - 管理対象サーバーを起動するためにノード・マネージャを呼び出す場合、リモート起動ユーザーのユーザー名とパスワードはノード・マネージャによって管理サーバーから取得されます。

- 管理サーバーの資格証明 - 管理サーバーを起動するためにノード・マネージャを呼び出す場合、リモート起動ユーザーのユーザー名はコマンド行で指定することも、管理サーバーのboot.propertiesファイルから取得することもできます。構成ウィザードは、ドメインの作成時に管理サーバーのboot.propertiesファイルおよびstartup.propertiesファイルを初期化します。

ノード・マネージャによって起動されたサーバー・インスタンスでは、自動再起動に使用するために、サーバーの起動に使用された資格証明が暗号化され、サーバー固有のboot.propertiesファイルに保存されます。

キーと値のペアの生成と配布

スクリプト・ベースのノード・マネージャでは、2種類のキーと値のペアが使用されます。この項では、キーと値のペアをノード・マネージャのクライアントまたはサーバーをホストするマシンに配布する手順について説明します。

- 共有のキーと値のペア

- 個々のキーと値のペア

共有のキーと値のペア

このオプションでは、同じキーと値のペアをノード・マネージャのクライアントまたはサーバーをホストするすべてのマシンに配布します。

最も簡単な方法は、ノード・マネージャ・ユーザーのホーム・ディレクトリを各マシンにマウントするようにするようにLANを設定することです。これにより、キーと値のペアがすべてのマシンで使用可能になります。この方法を使用しない場合は、次の手順を行います。

1. SSHインストールに付属のssh-keygenコマンドを使用して、ユーザーのRSAキー値ペアを生成します。
秘密鍵と公開鍵のデフォルトの場所はそれぞれ、~/.ssh/id_rsaと~/.ssh/id_rsa.pubです。

これらのキーが異なる場所に格納されている場合は、sshコマンドにオプションを追加してキーの場所を指定するようにShellCommandテンプレートを変更します。

2. ノード・マネージャ・マシン上の~/.ssh/authorized_keysファイルに公開鍵を追加します。
例:

command="ORACLE_HOME/wlserver/common/nodemanager/nodemanager.sh" 1024 33 23...2323

ここで、例で示した次の文字列を、id_rsa.pubに格納されている生成した公開鍵で置き換えます。

1024 33 23...2323

注意:

接頭辞command=コマンドは、公開鍵を使用してマシンとのセッションを確立するユーザーがnodemanager.shで指定されたコマンドしか実行できないことを保証しています。これによりユーザーはノード・マネージャ機能を実行するだけになり、データ、システム・ユーティリティなどのマシン上のリソースへの権限のないアクセスが防止されます。

3. ノード・マネージャのサーバー・インスタンスまたはクライアントをホストする各マシンにキーと値のペアを手動で配布します。

4. クライアント・マシン上で次のコマンドを実行して、ノード・マネージャ・クライアントがノード・マネージャにアクセスできることを確認します。
$ ssh montgomery wlscontrol.sh VERSION

次のレスポンスは、クライアントがノード・マネージャに正常にアクセスしたことを示します。

NodeManager version 12.1

個々のキーと値のペア

ノード・マネージャ・クライアントをホストするマシンごとに、次の手順を行います。

1. 前の項のステップ1の説明に従って、ノード・マネージャ・ユーザーの個々のRSAキー値ペアを生成します。

2. 前の項のステップ2の説明に従って、マシン上の~/.ssh/authorized_keysファイルに公開鍵を追加します。

6 ノード・マネージャの使用

この章では、Javaベースおよびスクリプトベースのノード・マネージャを起動と停止する方法について説明します。また、ノード・マネージャを使用してサーバー・インスタンスを起動する際の推奨手順も示します。

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

- ノード・マネージャの起動と停止

- ノード・マネージャを使用したサーバーの制御

ノード・マネージャの起動と停止

次の方法で、ノード・マネージャの起動と停止を行います。

- 起動サービスとしてのノード・マネージャの実行

- スクリプトを使用したJavaベースのノード・マネージャの起動

- スクリプト・ベースのノード・マネージャの実行

- ノード・マネージャの停止

起動サービスとしてのノード・マネージャの実行

ノード・マネージャは、ノード・マネージャを使用して制御するWebLogic Serverインスタンスをホストする各コンピュータ上で実行する必要があります。理想としては、システム障害の発生時や再起動時にノード・マネージャが自動的に再起動されるように、ノード・マネージャはオペレーティング・システムのサービスまたはデーモンとして実行する必要があります。

デフォルトでオペレーティング・システム・サービスは、ノード・マネージャを起動しlocalhost:5556でリスニングします。ノード・マネージャでリモート・システムからのコマンドを受け付けるようにする場合は、localhost以外のリスニング・アドレスでリスニングするようにスクリプトを編集します。

ノード・マネージャは、起動サービスとして実行するようにインストールすることをお薦めします。これによって、システムが再起動されるたびに、ノード・マネージャが自動で起動されます。「xinetdサービスとしてのノード・マネージャの構成」および「init.dサービスとしてのノード・マネージャの構成」を参照してください

注意:

UNIXプラットフォームでは、ノード・マネージャのrootユーザーとしての実行はお薦めしません。ただし、バインド後のグループIDを取得するには、ノード・マネージャをrootユーザーとして実行する必要があります。バインド後のグループIDを使用すると、ご使用のマシンで稼働するサーバーが、すべての権限のある起動アクションの実行後に、UNIXグループID (GID)にバインドできるようになります。

Windowsマシンでドメインごとのノード・マネージャWindowsサービスをインストールするには、次の手順を実行します。

1. 管理者権限でマシンにログインします。

2. DOSコマンド・プロンプトを開きます。

3. DOMAIN_HOME\binディレクトリに移動します。

4. 次のコマンドを入力します。
installNodeMgrSvc.cmd

5. 数秒後に、次のメッセージが表示されます。

Oracle WebLogic <domain-name> NodeManager installed.

サービスはデフォルトのノード・マネージャ・リスニング・ポート(5556)を使用してインストールされます。このリスニング・ポートが使用中の場合、プログラムから別のリスニング・ポートの入力を要求されます。

注意:

ノード・マネージャのWindowsサービスがすでにインストールされている場合、次のメッセージがかわりに表示されます。

CreateService failed - The specified service already exists.

ドメインごとのノード・マネージャWindowsサービスをアンインストールするには、次の手順を実行します。

1. 管理者権限でマシンにログインします。

2. DOSコマンド・プロンプトを開きます。

3. DOMAIN_HOME\binディレクトリに移動します。

4. 次のコマンドを入力します。
uninstallNodeMgrSvc.cmd

5. 数秒後に、次のメッセージが表示されます。

Oracle WebLogic <domain-name> NodeManager removed.

デフォルトでは、NODEMGR_HOSTはinstallNodeMgrSvc.cmdでlocalhostに設定され、ノード・マネージャはローカル・ホストでのみリスニングします。ノード・マネージャがローカル・ホストでのリスニングを行わないようにするには、NODEMGR_HOSTを有効なホスト名またはIPアドレスに設定してからノード・マネージャ・サービスをインストールします。

注意:

WL_HOME\server\bin\installNodeMgrSvc.cmdを使用して、ホストごとのノード・マネージャをWindowsサービスとして実行するには、「ホストごとのノード・マネージャの構成」に説明されているように、前提条件の構成手順を最初に実行する必要があります。

スクリプトを使用したJavaベースのノード・マネージャの起動

オペレーティング・システム・サービスとしてノード・マネージャを実行することをお薦めしますが、コマンド・プロンプトまたはスクリプトを使用してノード・マネージャを手動で起動することもできます。ノード・マネージャに必要な環境変数については、「ノード・マネージャ環境変数の設定」を参照してください

ノード・マネージャのサンプル起動スクリプトは、各DOMAIN_HOME/binおよびWL_HOME\server\binディレクトリにインストールされます。ここでWL_HOMEは、WebLogic Serverの最上位のインストール・ディレクトリです。ただし、WL_HOME\server\binのスクリプトを使用する場合は、「ホストごとのノード・マネージャの構成」に説明されているように、前提条件の手順を最初に実行する必要があります。

WindowsシステムではstartNodeManager.cmd、UNIXシステムではstartNodeManager.shを使用します。

スクリプトにより、必須の環境変数が設定され、NodeManagerHomeディレクトリのノード・マネージャが起動します。ノード・マネージャは、このディレクトリを出力およびログ・ファイルを格納するための作業ディレクトリとして使用します。別の作業ディレクトリを指定するには、テキスト・エディタで起動スクリプトを編集し、NODEMGR_HOME変数の値を目的のディレクトリに設定します。

Javaベースのノード・マネージャを起動するためのコマンド構文

Javaベースのノード・マネージャを起動するための構文は次のとおりです。

java [java_option=value ...] -D[nodemanager_property=value] -D[server_
property=value] weblogic.NodeManager

説明:

- java_optionは、java実行可能ファイルの直接引数(-msや-mxなど)。

注意:

CLASSPATH環境変数を設定しなかった場合、-classpathオプションを使用して必須のノード・マネージャ・クラスを指定します。

- nodemanager_propertyは、ノード・マネージャ・プロパティ。ノード・マネージャ・プロパティ値をコマンド行で指定するかわりに、NodeManagerHomeディレクトリに作成されているnodemanager.propertiesファイルを編集できます。詳細は、「nodemanager.propertiesのレビュー」を参照してください。
nodemanager.propertiesの値は、コマンド行で指定するノード・マネージャ・プロパティ値によってオーバーライドされます。

- server_propertyは、ノード・マネージャがコマンド行で受け付ける、サーバー・レベルのプロパティ。以下のプロパティがあります。

- bea.home - 現在のマシン上のサーバー・インスタンスが使用するBEAホーム・ディレクトリ。

- java.security.policy - 現在のマシン上のサーバー・インスタンスが使用するセキュリティ・ポリシー・ファイルのパス。

注意:

UNIXシステムの場合:

Solaris以外のUNIXオペレーティング・システム上でノード・マネージャを実行する場合、ノード・マネージャの起動時にjavaコマンド行に渡すパラメータで空白は使用できません。たとえば次のコマンドは、"big iron"にスペースが含まれているので無効です。

-Dweblogic.Name="big iron"

SolarisおよびLinux以外のUNIXオペレーティング・システムでは、ノード・マネージャの起動時にコマンド行でweblogic.nodemanager.nativeVersionEnabledオプションを無効にするか、nodemanager.propertiesでプロパティを設定して、pure Java実装を使用する必要があります。詳細は、「nodemanager.propertiesのレビュー」を参照してください。

スクリプト・ベースのノード・マネージャの実行

注意:

このリリースのWebLogic Serverでは、スクリプト・ベース実装のノード・マネージャを実行する前に、NodeManagerHomeに、ノード・マネージャ・インスタンスで制御するドメインを指定するnodemanager.domainsファイルを作成またはコピーする必要があります。「nodemanager.domainsファイルの構成」を参照してくださいあるいは、WLSTコマンドnmEnrollを使用して、WebLogicドメインをノード・マネージャに登録することも可能です。

指定しない場合、デフォルトのNodeManagerHomeの場所はWL_HOME/common/nodemanagerです。

SSHノード・マネージャのコマンド・シェルを使用するには、次のコマンド行オプションを使用して、管理サーバーを起動します。

-Dweblogic.nodemanager.ShellCommand='ssh -o PasswordAuthentication=no %H wlscontrol.sh -d %D -r %R -s %S -x -c -f sample_custom_startscript.sh %C'

注意:

%Cを、wlscontrol.shに渡す最後の引数にする必要があります。

weblogic.nodemanager.ShellCommand属性では、リモートのスクリプト・ベースのノード・マネージャとの通信と、制御下にあるサーバー・インスタンスに対するノード・マネージャ機能の実行に使用するコマンド・テンプレートを指定します。

テンプレートは、ノード・マネージャをホストしているリモート・マシン上のデフォルトのパスにwlscontrol.shがあることを前提としています。

ShellCommand構文は次のとおりです。

ssh -o PasswordAuthentication=no %H wlscontrol.sh -d %D -r %R -s %S %C'

使用可能なコマンド行オプションを、表6-1に示します。使用可能なパラメータ値を、表6-2に示します。

たとえば、次のコマンドを入力したとします。

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にすると、コンソールから読み込もうとするときにクライアントがハングします。

表6-1 wlscontrol.shコマンド行オプション

パラメータ

説明

-n

ノード・マネージャのルート・ディレクトリを指定します。

-s

サーバー名を指定します。

-d

ドメイン名を指定します。

-r

ドメイン・ディレクトリを指定します。

-c

サーバー起動スクリプトを有効化します。

-f

サーバー起動スクリプトの名前。

-p

サーバー停止スクリプトの名前。

-v

冗長な出力を有効にします。

-h

wlscontrol.shの使用方法を出力します。

表6-2 シェル・コマンド・テンプレート

パラメータ

説明

デフォルト

%H

SSHサーバーのホスト名

NodeManagerMBean.ListenAddress

%N

ノード・マネージャのホーム・ディレクトリ

NodeManagerMBean.NodeManagerHome

%P

SSHサーバーのポート番号

NodeManagerMBean.ListenPort

22

%S

WebLogic Server名

なし

%D

WebLogicドメイン名

なし

%R

ドメイン・ディレクトリ(サーバーのルート)

ServerStartMBean.RootDirectory

%C

ノード・マネージャ・スクリプトのコマンド

- START - サーバーを起動する

- KILL - サーバーを強制停止する

- STAT - サーバーのステータスを取得する

- GETLOG - サーバーの出力ログを取得する

- VERSION - ノード・マネージャのバージョンを戻す

注意:この要素を、ファイル内の最後の要素にする必要があります。

none

注意:

ノード・マネージャまたはWebLogic Serverインスタンスの起動に時間がかかる場合、マシンのエントロピが低い可能性があります。

次のようにして、エントロピをチェックします。

cat /proc/sys/kernel/random/entropy_avail

結果が500より小さい場合、システムでエントロピが足りなくなる危険があることを意味します。rngdを実行し、/dev/randomにランダムな数のバイトを補充して/dev/urandomをソースとして使用してください。rngd (rootとして)を起動します。これにより、システムでエントロピが足りなくなることはありません。

$ rngd -r /dev/urandom -o /dev/random -b

/etc/sysconfig/rngdを編集し、次を使用してプロセスを構成できます。

EXTRA OPTIONS="-i -r /dev/urandom -o /dev/random -b -t 60 -W 2048"

60秒ごとに、サイズが2048に達するまでエントロピ・プールにビットを追加します。間隔およびサイズを、-t 60および-W 2048パラメータを使用して変更できます。

詳細は、このトピックについて詳しく説明している次のブログを参照してください。

- WebLogic Serverとエントロピ

- WebLogic Serverの起動に時間がかかる理由

ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。

wls:/nm/mydomain> stopNodeManager()

Stopped Node Manager Process successfully

wls:/offline>

詳細は、『WebLogic Server WLSTコマンド・リファレンス』のstopNodeManagerに関する項を参照してください。

ノード・マネージャを使用したサーバーの制御

一般的に、管理サーバーおよび管理対象サーバーの起動と停止には、WebLogic Scripting Toolとノード・マネージャを使用することをお薦めします。この項では、ノード・マネージャとWLSTを使用してサーバー・インスタンスを起動する際の推奨手順を示します。

詳細は、『WebLogic Server WLSTコマンド・リファレンス』のWLSTとノード・マネージャを使用したサーバー管理に関する項およびノード・マネージャ・コマンドに関する項を参照してください。

WebLogic Serverインスタンスの起動および停止の資格証明を変更するための詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動に使用する資格証明の変更に関する項を参照してください。

ノード・マネージャを使用した管理サーバーの起動

WLSTとノード・マネージャを使用して管理サーバーを起動する場合は、次の一般的な手順に従うことをお薦めします。

nmGenBootStartupPropsコマンドを使用して起動情報を確立します。このコマンドは、ノード・マネージャのプロパティ・ファイルboot.propertiesとstartup.propertiesを生成します。

ドメイン内で初めて管理サーバーを起動するときや、管理サーバーの構成を変更する場合は、次の手順をすべて実行する必要があります。

それ以降の管理サーバーの起動時は、ステップ7に進んで管理サーバーを直接ノード・マネージャで起動します。

1. 次のアクションのいずれかを実行して管理サーバーを手動で起動します。

- startWebLogicスクリプトをDOMAIN_HOME/binディレクトリから実行します。DOMAIN_HOMEは、WebLogic Serverドメインが構成されているディレクトリを表します。

- WLSTを呼び出し、WLSTのstartServerコマンドを使用して管理サーバーを起動します。

2. (省略可能) 管理サーバーについて他にも構成情報がある場合は追加します。

3. WLSTを呼び出します(まだ実行中ではない場合)。

Windowsの場合は、「スタート」メニューのショートカットで環境変数を設定し、WLSTを呼び出すことができます。

4. connectコマンドを使用してWLSTを管理サーバー・インスタンスに接続します。

5. nmGenBootStartupPropsコマンドを使用して起動情報を確立します。このコマンドは、ノード・マネージャのプロパティ・ファイルboot.propertiesとstartup.propertiesを生成します。

6. 管理サーバーを停止します。WLSTとの接続も切断されます。

7. ノード・マネージャを起動します。「ノード・マネージャの起動と停止」を参照してください。

8. WLSTを起動します。

9. nmConnectコマンドを使用してWLSTをノード・マネージャに接続します。

10. nmStartコマンドを使用して管理サーバーを起動します。

次の例では、ノード・マネージャを使用して、指定されたWebLogicドメインで管理サーバーを起動します。この例では、prps変数にシステム・プロパティ設定を格納し、props引数を使用してコマンドに渡されます。

wls:/nm/mydomain> prps = makePropertiesObject("AdminURL=http://

listen_address;listen_port;Username=username;Password=password

;weblogic.ListenPort=8001")

wls:/nm/mydomain> nmStart("AdminServer",props=prps)

Starting server AdminServer...

Server AdminServer started successfully

wls:/nm/mydomain>

管理サーバーが起動したら、WLSTを使用してドメイン内の管理対象サーバーを起動できます。

注意:

nmStartコマンドを使用してサーバー・インスタンスを起動すると、ノード・マネージャが管理サーバーの状態を監視して障害発生時に再起動できるようになります。ノード・マネージャによって再起動できるのは、この方法で起動したサーバー・インスタンスのみです。

nmStartを使用すると、特定のプロパティをサーバー・インスタンスに渡すことができますが、デバッグの際にのみ使用するようにしてください。nmStartで渡したサーバー・プロパティは、次回のサーバー・インスタンス再起動時までは保持されません。

WLSTを使用した管理対象サーバーの起動

WLSTとノード・マネージャを使用して管理対象サーバーを起動する場合は、次の一般的な手順に従うことをお薦めします。

1. ノード・マネージャを起動します。「ノード・マネージャの起動と停止」を参照してください。

2. 管理サーバーを起動します。『Oracle WebLogic Serverサーバーの起動と停止の管理』の起動スクリプトによる管理サーバーの起動に関する項を参照してください。

3. WLSTを呼び出し、connectコマンド使用して管理サーバーに接続します。

4. WLSTのstartコマンドを使用して管理対象サーバーを起動します。

startコマンドを使用した場合は、WLSTが管理サーバーにアクセスして管理対象サーバーの起動プロパティを識別します。これらのプロパティは、最終的にはノード・マネージャに渡され、管理対象サーバーの起動に使用されます。

管理コンソールを使用した管理対象サーバーの起動

WebLogic Server管理コンソールを使用して管理対象サーバーを起動するには、次の一般的な手順をお薦めします。

1. 管理対象サーバーをまだ作成していない場合は作成します。

2. ノード・マネージャは、ノード・マネージャを使用して制御するWebLogic Serverインスタンスのホストとなる各コンピュータ上で実行する必要があります。WebLogic Server内で、各コンピュータをマシンとして構成します。「ノード・マネージャを使用するためのマシンの構成」を参照してください

3. ノード・マネージャで制御する各サーバー・インスタンスを、そのインスタンスを実行するマシンに割り当てます。「マシンへのサーバー・インスタンスの割当て」を参照してください

4. 管理対象サーバーをホストするコンピュータでノード・マネージャを起動します。WebLogic Serverのカスタム・インストール・プロセスでは、必要に応じてノード・マネージャをWindowsシステム上のWindowsサービスとしてインストールおよび起動できます。ノード・マネージャが実行されていない場合は、コマンド・プロンプトまたはスクリプトを使用して手動で起動できます。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理コンソールからの管理対象サーバーの起動に関する項を参照してください。

ノード・マネージャを使用するためのマシンの構成

WebLogic Serverマシン・リソースでは、特定のマシンとそれがホストするサーバー・インスタンスを関連付け、そのシステム上のノード・マネージャ・プロセスの接続属性を指定します。

WebLogic Server管理コンソールの「環境」→「マシン」→「machine_name」→「ノード・マネージャ」ページを使用して、ノード・マネージャ・プロセスを実行するマシンごとにマシン定義を構成します。以下の値を入力します。

1. ノード・マネージャがリスニングするDNS名またはIPアドレスを「リスニング・アドレス」フィールドに入力します。

2. ポート番号を「リスニング・ポート」フィールドに入力します。ポート番号の入力が特に重要になるのは、デフォルト値から変更した場合です。

注意:

ノード・マネージャの「リスニング・アドレス」の値には、クライアント側の構成が反映されます。これは、管理サーバーや管理サーバー上のクライアントに、ノード・マネージャへの接続方法を指示するものです。この属性は、ノード・マネージャを構成するものではありません。

指定するリスニング・アドレスは、ノード・マネージャSSLサーバーのデジタル証明書のサブジェクトDNのCNコンポーネントに表示されるホスト名と正確に一致する必要があります。

マシンへのサーバー・インスタンスの割当て

各コンピュータを1つのマシン・リソースとして構成した後、ノード・マネージャを使用して制御する各サーバー・インスタンスを、ノード・マネージャが実行されるマシンに割り当てる必要があります。

1. WebLogic Server管理コンソールで、「環境」→「サーバー」→「server_name」→「構成」→「全般」を選択します。

2. 「マシン」フィールドで、サーバー・インスタンスの割当て先となるマシンを選択します。

注意:

管理サーバーのマシンを、WebLogic Server管理コンソールを使用して変更することはできません。実行中のサーバー・インスタンスのクラスタやマシンを変更することはできません。

管理サーバーを使用しない管理対象サーバーの起動

管理対象サーバーの起動プロパティの識別に管理サーバーを使用したくない場合は、WLSTとノード・マネージャを使用して、次に示す一般的な手順に従って管理対象サーバーを起動することをお薦めします。

1. ノード・マネージャを起動します。「ノード・マネージャの起動と停止」を参照してください。

2. WLSTを呼び出し、nmConnectコマンドを使用してノード・マネージャに接続します。

3. WLSTのnmStartコマンドを使用して管理対象サーバーを起動します。

注意:

デフォルト・セキュリティ・プロバイダを使用する場合は、管理対象サーバー・インスタンスの初回起動時に、そのサーバー・インスタンスが管理サーバーにアクセスできる状態にある必要があります。

管理サーバーが停止しているときに管理対象サーバーをMSIモードで起動するには、WLSTを使用してノード・マネージャに直接接続する必要があります。

nmStartコマンドを使用すると、管理サーバーを使用しなくても管理対象サーバーを起動でき、任意のサーバー起動プロパティを指定できます。ただし、以下の点を考慮に入れてください。

- nmStartを使用してサーバー・インスタンスを起動するには、boot.propertiesおよびstartup.propertiesが定義済であることを確認する必要があります。

- サーバー・インスタンスの起動プロパティを恒久的に変更するには、nmStartを使用しないでください。次回サーバー・インスタンスが管理サーバーから移行または再起動されるときに、そのプロパティは使用されません。

- サーバー・インスタンスのユーザー名とパスワードをnmStartを使用して渡すと、これらの値は暗号化されません。

次の例では、ノード・マネージャを使用して、現在のWebLogicドメインでmanaged1サーバーを起動します。

wls:/nm/mydomain> nmStart("managed1")

Starting server managed1 ...

Server managed1 started successfully

wls:/nm/mydomain>