Oracle® Fusion Middleware

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

12c (12.1.2)

E48063-02(原本部品番号:E28093-03)

2014年2月

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

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

E48063-02

Copyright © 2007, 2014, 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の登録商標です。

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

目次

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

はじめに

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

- 表記規則

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

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

- WebLogic Serverのログ・ファイル

3 ノード・マネージャの一般的な構成

- ノード・マネージャの構成の概要

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

- ステップ1: ノード・マネージャを実行するためのコンピュータの構成

- ステップ2: ノード・マネージャのユーザー名およびパスワードの指定

- ステップ3: ノード・マネージャを使用するためのマシンの構成

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

- ステップ5: リモート起動引数の構成

- ステップ6: サーバーの起動プロパティの設定

- startup.properties

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

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

- ステップ7: 管理サーバー・アドレスの定義

- ステップ8(オプション): ノード・マネージャ環境変数の設定

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

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

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

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

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

- nodemanager.propertiesのレビュー

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

- スクリプトの場所

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

- 起動スクリプトの使用

- 停止スクリプトの使用

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

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

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

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

- 概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 共有のキーと値のペア

- 個々のキーと値のペア

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

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

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

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

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

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

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

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

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

- 管理対象サーバーの起動

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

はじめに

ここでは、このガイド『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プログラミング言語について読者が精通していることを前提としています。

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

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

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

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

- 第3章「ノード・マネージャの一般的な構成」では、Javaバージョンおよびスクリプト・バージョンのノード・マネージャの双方に適用される構成手順について説明します。

- 第4章「Javaノード・マネージャの構成」では、Javaバージョンのノード・マネージャの構成手順について説明します。

- 第5章「スクリプト・ノード・マネージャの構成」では、スクリプト・バージョンのノード・マネージャの構成手順について説明します。

- 第6章「ノード・マネージャの使用」では、ノード・マネージャおよびサーバーの起動手順について説明します。この章では、WebLogic Serverのフェイルオーバー機能および移行機能を利用するためにサーバーを起動する際の推奨事項についても説明します。

関連ドキュメント

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

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

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

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

このリリースでは、Javaベース・バージョンのノード・マネージャには、簡素化され、すぐに使用できる構成があります。デフォルトで、作成する各WebLogicドメインについて、セキュリティ資格証明、プロパティ・ファイル、ドメイン登録、およびノード・マネージャをWindowsサービスとしてインストールおよびアンインストールするための構成済スクリプトをはじめとする起動スクリプトを備えた、ドメイン固有のノード・マネージャ構成が作成されます。詳細は、「ノード・マネージャのデフォルト構成」を参照してください。

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

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

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

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

- 概要

- ノード・マネージャのバージョン

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

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

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

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

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

はじめに

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

以前のリリースでは、ノード・マネージャ・プロセスは特定のWebLogicドメインではなくホスト・マシンに関連付けられていました。サーバー・インスタンスがノード・マネージャ・プロセスと同じマシン上に存在しているかぎり、同じノード・マネージャ・プロセスを使用して任意のWebLogicドメインのサーバー・インスタンスを制御しており、マシンにスコープ指定されたホストごとのノード・マネージャでした。　このリリースのWebLogic Serverでは、デフォルトでJavaバージョンのノード・マネージャが、同じドメインに属するすべてのサーバー・インスタンスを制御するように構成されており、ドメインごとのノード・マネージャになります。サーバー・インスタンスは同じマシンに存在する必要はありません。ドメイン固有のJavaベースのノード・マネージャを、それぞれ異なる構成で実行できるようになりました。詳細は、「ノード・マネージャのデフォルト構成」を参照してください。

ノード・マネージャは、ノード・マネージャを使用して制御するWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)をホストするコンピュータごとに実行する必要があります。

ノード・マネージャのバージョン

WebLogic Serverには、Javaベースのノード・マネージャとスクリプト・ベースのノード・マネージャという、同じような機能を持つ2つのバージョンのノード・マネージャが用意されています。ただし、それぞれのバージョンでは、構成とセキュリティに関する考慮事項が異なっています。

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

Javaベースのノード・マネージャは、Java仮想マシン(JVM)プロセスで動作します。ノード・マネージャは、WindowsプラットフォームではWindowsサービスとして、UNIXプラットフォームではオペレーティング・システムのサービスとして実行することをお薦めします。これにより、システムの再起動時にノード・マネージャを自動的に再起動できるようになります。

Oracleでは、Windows、Solaris、Linux on Intel、Linux on Z-SeriesおよびAIXオペレーティング・システム用のネイティブ・ノード・マネージャ・ライブラリを提供しています。

注意:

ノード・マネージャは、Open VMS、OS/390、AS400、UnixWare、またはTru64 UNIXではサポートされていません。

このバージョンのノード・マネージャの構成は、nodemanager.propertiesファイルで指定されます。「nodemanager.propertiesのレビュー」を参照してください。

Javaベースのノード・マネージャは、スクリプト・ベースのノード・マネージャよりセキュリティ面で優れています。「Javaベースのノード・マネージャのセキュリティの構成」を参照してください。

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

UNIXおよびLinuxシステムに対しては、スクリプト・ベース・バージョンのノード・マネージャが提供されます。このスクリプトはUNIXシェル・スクリプトに基づいていますが、セキュリティ向上のためにSSHを使用します。SSHではユーザーIDベースのセキュリティが使用されます。

スクリプト・バージョンのノード・マネージャの構成については、「スクリプト・ノード・マネージャの構成」を参照してください。

このバージョンのノード・マネージャでは、Javaベースのノード・マネージャほどのセキュリティは提供されません。しかし、スクリプト・ベースのノード・マネージャの利点は、SSHを使用するように構成されたネットワーク上でサーバーをリモート管理できることです。サーバーを追加でインストールする必要はありません。スクリプトをリモート・マシンにコピーするだけです。

注意:

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

使用するノード・マネージャ・バージョンの決定

どのバージョンのノード・マネージャを使用するかは、お使いのWebLogic Server環境の要件によって異なります。現在の環境に最適なバージョンを判断する際は、以下の点を考慮してください。

- WebLogic ServerをWindowsシステムにインストールしている場合は、Javaバージョンのノード・マネージャを使用する必要があります。スクリプト・バージョンのノード・マネージャは、Windowsではサポートされません。

- コンセンサス・リースを使用する場合は、Javaバージョンのノード・マネージャを使用するとパフォーマンスが向上する可能性があります。

- スクリプト・ベースのノード・マネージャの場合は、セキュリティ構成をJavaバージョンよりもかなり単純にする必要があります。RSHおよびSSHは、Javaバージョンのノード・マネージャで使用するSSLよりも一般的で構成も容易なセキュリティ手法です。スクリプト・バージョンのノード・マネージャの場合は、必要なサイズもJavaバージョンに比べて小さくなります。

- Javaバージョンのノード・マネージャは、サポートされるUNIXシステムでinetdと組み合わせて使用できます。inetdを使用すると、構成されたポートでリクエストを受信したときにノード・マネージャを自動的に再起動できます。

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

ノード・マネージャ・クライアントは、通信するノード・マネージャのローカルにあってもリモートにあってもかまいません。以下のクライアントから、Javaバージョンまたはスクリプト・ベース(SSH)バージョンのノード・マネージャのうち、いずれかにアクセスします(また、スクリプト・ベースのノード・マネージャで使用するための、シェル・コマンド・テンプレート形式によるSSHクライアントが用意されています)。

- 管理サーバー

- 管理コンソールの「環境」>「マシン」>「構成」>ノード・マネージャページ

たとえば、管理サーバーに通信してServerLifeCycleRuntimeMBeanに対する操作を実行するJMXユーティリティを作成できます。このServerLifeCycleRuntimeMBeanは、内部でノード・マネージャを使用して、操作を実行します。JMXの詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。

- WLSTコマンドおよびスクリプト - WLSTオフラインは実行中の管理サーバーが存在しない場合に実行可能なノード・マネージャ・コマンド・ライン・インタフェースとして機能します。WLSTコマンドを使用すると、管理サーバーに接続せずにサーバー・インスタンスの起動、停止、および監視を行うことができます。管理サーバーの起動が、スタンドアロン・クライアントの主な目的です。ただし、次の目的にも使用できます。

- ノード・マネージャを使用して起動されたサーバー・インスタンスの停止

- 管理対象サーバーの起動

- ノード・マネージャのログ・ファイルの内容へのアクセス

- ノード・マネージャで起動されたサーバーのステータスの取得

- サーバー出力ログの内容の取得

WLSTおよびノード・マネージャを使用したサーバーの制御の詳細は、「ノード・マネージャを使用したサーバーの制御」を参照してください。

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

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

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

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

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

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

- 管理サーバーではノード・マネージャを使用して管理対象サーバーを起動するプロセスがサポートされています。ノード・マネージャを使用して管理対象サーバーを起動するときには、管理対象サーバーは管理サーバーにアクセスして未処理の構成の更新を取得します。

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

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

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

注意:

ノード・マネージャは、最初からMSIモードで管理対象サーバーを起動することはできません。管理対象サーバーが自身の構成を設定を取得するには、ドメインの管理サーバーにアクセスできなくてはならないからです。

注意:

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

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

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

注意:

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

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

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

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

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

注意:

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

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

ノード・マネージャは、ノード・マネージャ・プロセスのログ・ファイルと、自身が制御する各サーバー・インスタンスのサーバー出力ログ・ファイルを作成します。これらのログ・ファイルは、サーバー・インスタンスのログ・ファイルと同様に管理コンソールまたはWLSTまたはコマンドを使用して表示できます。詳細は、「ログ・ファイル」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 認可されたユーザーは、WLSTオフライン・コマンドnmConnectを発行し、管理サーバーをホストするマシン上のノード・マネージャ・プロセスに接続します。(ノード・マネージャ・インスタンスがSSHバージョンである場合は、ユーザーはSSHクライアントを使用して接続できます)。nmConnectコマンドによってノード・マネージャのユーザー名とパスワードが提供され、これらを使用してユーザーはノード・マネージャの認証を受けます。
次に、ユーザーはnmStartコマンドを発行し、管理サーバーを起動するための資格証明を提供します。例:

prps = makePropertiesObject("AdminURL=http://listen_address:listen_port;Username=username;Password=password")
nmStart("AdminServer",props=prps)

注意:

ユーザーが以前にノード・マネージャに接続したことがある場合にはboot.propertiesファイルが存在するので、ユーザーはユーザー名とパスワードを指定する必要はありません。

nmStartコマンドは、起動するドメインおよびサーバー・インスタンスを識別します。

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

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

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

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

注意:

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

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

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

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

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

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

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

注意:

スタンドアロン・クライアントは、管理対象サーバーの起動コマンドを発行することもできます。

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

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はローカルにキャッシュされた構成データを使用します。

注意:

デフォルトでは、管理対象サーバー独立モードは有効になっています。

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

図2-6は、ノード・マネージャの制御下にある管理対象サーバーの停止に伴う通信について説明しています。管理対象サーバーの状態と可用性によっては、ノード・マネージャは別の方法で停止を始める必要があります。

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

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

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

2. 管理サーバーは管理対象サーバー1に直接シャットダウン・コマンドを発行します。管理対象サーバー1へのアクセスが成功すると、管理対象サーバー1は、『Oracle WebLogic Serverサーバーの起動と停止の管理』の正常な停止に関する項で説明されている停止シーケンスを実行します。

3. 前の手順で管理対象サーバー1へのアクセスが失敗した場合、管理サーバーはマシンB上のノード・マネージャに管理対象サーバー1の停止コマンドを発行します。

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

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

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

システム・クラッシュの後に、ノード・マネージャによってサーバーが確実に再起動されるようにするには、以下を実行する必要があります。

- Javaベースのノード・マネージャの場合、CrashRecoveryEnabledがtrueに設定されていることを確認します。
CrashRecoveryEnabled構成プロパティを使用すると、ノード・マネージャがシステム・クラッシュの後にサーバーを再起動できます。このプロパティは、デフォルトでは有効になっていません。

注意:

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

- スクリプト・ベースのノード・マネージャの場合、この行をマシン起動スクリプトに配置するか、必要に応じて指定スケジュールで定期的に実行します。

wlscontrol.sh -d domain_name CRASHRECOVERY

- 管理サーバーをノード・マネージャを使用して起動します。

- すべての管理対象サーバーを管理サーバーを使用して起動します。この操作は、WLSTまたは管理コンソールで実行できます。

システムの再起動後、ノード・マネージャは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

このファイルには、ノード・マネージャによって管理されるドメインの名前と、それに対応するディレクトリのマッピングが格納されます。「ステップ4: 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

このファイルは、ノード・マネージャのユーザー名とパスワードを保存します。「ステップ2: ノード・マネージャのユーザー名およびパスワードの指定」を参照してください。

このファイルは、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の詳細は、「ステップ6: サーバーの起動プロパティの設定」を参照してください。これらのプロパティは、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を設定することで有効にできます。

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

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

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

server_name.out

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

注意:

ノード・マネージャが作成するこのログ・ファイルのサイズは制限できません。stdoutへのロギングはデフォルトでは無効になっています。

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

ノード・マネージャによって、サーバー・インスタンスのlogsディレクトリにそのサーバー・インスタンスのサーバー出力ログが次の名前で作成されます。

server_name.out

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

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

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

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

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

NativeVersionEnabled=falseの場合は、ノード・マネージャのログ・ファイルのローテーションを構成できます。ただし、表4-1「ノード・マネージャのプロパティ」に記載されている制限を参照してください。

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

プロパティ

説明

デフォルト

FileCount

サーバーがログをローテーションする際に作成するログ・ファイルの最大数。この数には、現在のメッセージを格納するためにサーバーで使用されているファイルは含まれません。NumberOfFilesLimitedを有効にする必要があります。

7

FileMinSize

サーバーがログ・メッセージを別のファイルに移動するきっかけとなるサイズ(1-2097150KB)。デフォルトは500KBです。ログ・ファイルが指定の最小サイズに到達すると、以後サーバーは、ファイル・サイズをチェックする際に、現在のログ・ファイルの名前をSERVER_NAME.lognnnnnに変更し、それ以降のメッセージを保存するための新規ログ・ファイルを作成します。RotationTypeにSIZEを指定する必要があります。

500

RotationType

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

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

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

- TIME: FileTimeSpanに指定した間隔で、ファイル名がSERVER_NAME.lognnnnnに変更されます。

SIZE

FileTimeSpan

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

24

FileTimeSpanFactor

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

360000

RotationTime

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

00:00

NumberOfFilesLimited

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

true

WebLogic Serverのログ・ファイル

ノード・マネージャによって作成されるログ・ファイルとは別に、ノード・マネージャの制御下にあるサーバー・インスタンスには独自のログ・ファイルがあります。

サーバー・インスタンスのログ・ファイルを表示するには、「診断」>「ログ・ファイル」を選択し、サーバーのログ・ファイルを選択して「ビュー」をクリックします。

3 ノード・マネージャの一般的な構成

この章では、ノード・マネージャ構成プロセスと、Javaバージョンおよびスクリプトベース・バージョンのノード・マネージャに適用される一般的な手順について説明します。

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

- ノード・マネージャの構成の概要

- ステップ1: ノード・マネージャを実行するためのコンピュータの構成

- ステップ2: ノード・マネージャのユーザー名およびパスワードの指定

- ステップ3: ノード・マネージャを使用するためのマシンの構成

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

- ステップ5: リモート起動引数の構成

- ステップ6: サーバーの起動プロパティの設定

- ステップ7: 管理サーバー・アドレスの定義

- ステップ8(オプション): ノード・マネージャ環境変数の設定

ノード・マネージャの構成の概要

この項では、ノード・マネージャの一般的な構成手順について説明します。この項の内容は、Javaバージョンおよびスクリプト・バージョンのノード・マネージャに適用されます。ノード・マネージャの一般的な構成を実施した後は、使用するノード・マネージャのバージョンに応じて、第4章「Javaノード・マネージャの構成」または第5章「スクリプト・ノード・マネージャの構成」の構成手順を実施する必要があります。

このリリースでは、Javaベース・バージョンのノード・マネージャには、簡素化され、すぐに使用できる構成があります。詳細は、「ノード・マネージャのデフォルト構成」を参照してください。

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

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

ステップ1: ノード・マネージャを実行するためのコンピュータの構成

ノード・マネージャは、ノード・マネージャを使用して制御するWebLogic Serverインスタンスをホストする各コンピュータ上で実行する必要があります。理想としては、システム障害の発生時や再起動時にノード・マネージャが自動的に再起動されるように、ノード・マネージャはオペレーティング・システムのサービスまたはデーモンとして実行する必要があります。

デフォルトでオペレーティング・システム・サービスは、ノード・マネージャを起動しlocalhost:5556でリスニングします。ノード・マネージャでリモート・システムからのコマンドを受け付けるようにする場合は、localhost以外のリスニング・アドレスでリスニングするようにスクリプトを編集します。詳細は、「起動サービスとしてのノード・マネージャの実行」を参照してください。

注意:

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

ステップ2: ノード・マネージャのユーザー名およびパスワードの指定

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

注意:

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

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

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

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

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

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

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

3. WLSTを呼び出し、connectコマンド使用して管理サーバーに接続します。詳細は、『WebLogic Scripting Toolの理解』の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を手動で編集した場合(非推奨)、変更が反映されるようにノード・マネージャを再起動する必要があります。ノード・マネージャを実行している状態で管理コンソールを使用して値を変更した場合は、再起動は必要ありません。

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

ステップ3: ノード・マネージャを使用するためのマシンの構成

WebLogic Serverマシン・リソースでは、特定のマシンとそれがホストするサーバー・インスタンスを関連付け、そのシステム上のノード・マネージャ・プロセスの接続属性を指定します。

管理コンソールの「環境」>「マシン」>machine_name>ノード・マネージャページを使用して、ノード・マネージャ・プロセスを実行するマシンごとにマシン定義を構成します。「リスニング・アドレス」フィールドに、ノード・マネージャがリスニングするDNS名またはIPアドレスを入力します。

注意:

指定するリスニング・アドレスは、ノード・マネージャSSLサーバーのデジタル証明書のサブジェクトDNのCNコンポーネントに表示されるホスト名と正確に一致する必要があります。

各コンピュータを1つのマシン・リソースとして構成した後、ノード・マネージャを使用して制御する各サーバー・インスタンスを、ノード・マネージャが実行されるマシンに割り当てる必要があります。

1. 管理コンソールの「環境」→「サーバー」→「server_name」→「構成」→「全般」を選択します。

2. 「マシン」フィールドで、サーバーを割り当てるマシンを選択します。

注意:

管理サーバーのマシンは、管理コンソールを使用して変更できません。実行中のサーバーのクラスタおよびマシンは変更できません。

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

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

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

domain-name=domain-directory

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

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

Javaベースのノード・マネージャの場合、このファイルは通常、ORACLE_HOME\user_projects\domains\domain_name\nodemanagerにあります。スクリプトベースのノード・マネージャの場合、このファイルのデフォルトの場所はWL_HOME/common/nodemanagerです。ここでWL_HOMEは、WebLogic Serverをインストールした場所(ORACLE_HOME/wlserverなど)です。

構成ウィザードを使用してドメインを作成した場合は、nodemanager.domainsファイルは自動的に作成されています。ただし、WebLogic Serverのこのリリースでは、スクリプト・バージョンのノード・マネージャを使用している場合、ノード・マネージャ・インスタンスで制御するドメインを指定するnodemanager.domainsファイルを、NodeManagerHomeに作成またはコピーする必要があります。あるいは、WLSTコマンドnmEnrollを使用して、WebLogicドメインをスクリプトベースのノード・マネージャに登録することも可能です。

ドメインごとのノード・マネージャではなく、ホストごとのノード・マネージャを構成する場合は、nodemanager.domainsファイルを、ORACLE_HOME\oracle_common\common\nodemanagerの下のホストごとのNodeManagerHomeの場所に手動で作成またはコピーする必要があります。詳細は、「ノード・マネージャのデフォルト構成」を参照してください。

必要に応じて、nodemanager.domainsを手動で編集し、ドメインを追加できます。

注意:

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

例3-1 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

ステップ5: リモート起動引数の構成

管理コンソールで、管理対象サーバーの「サーバー」>「構成」>サーバーの起動のページで、ノード・マネージャが管理対象サーバーの起動に使用する起動引数を指定します。管理対象サーバーの起動引数を指定しない場合、ノード・マネージャは独自のプロパティをデフォルトとして使用して管理対象サーバーを起動します。詳細は、「nodemanager.propertiesのレビュー」を参照してください。管理対象サーバーを起動するにはこれらのデフォルトで十分ですが、起動プロセスの一貫性と信頼性を確保するには、管理対象サーバーのインスタンスごとに起動引数を構成してください。指定された起動引数は管理対象サーバーの起動にのみ使用されます。ノード・マネージャによって起動される管理サーバー・インスタンスで使用されることはありません。

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

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

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

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

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

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

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

ステップ6: サーバーの起動プロパティの設定

ノード・マネージャを使用して、サーバーの起動プロパティを設定できます。これらのプロパティは、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コマンドに渡す必要があります。

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

以下のサーバーの起動プロパティを、ノード・マネージャを使用して起動する際にサーバーに渡すことができます。

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

プロパティ

説明

JavaHome

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

Arguments

サーバーを起動する際に使用される引数。

SSLArguments

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

RestartInterval

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

RestartMax

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

RestartDelaySeconds

ノード・マネージャがサーバーの再起動を試行するまでに待機する秒数。

ClassPath

サーバーを起動する際に使用されるクラスパス。

OracleHome

サーバーを起動する際に使用されるOracleホーム・ディレクトリ。

AdminURL

管理サーバーのURL。

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

AutoRestart

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

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

AutoKillIfFailed

サーバーのステータスがfailedになった場合に、ノード・マネージャで自動的にサーバーを強制終了するかどうかを指定します。

SecurityPolicyFile

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

ServerIP

サーバーのIPアドレス。

ステップ7: 管理サーバー・アドレスの定義

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

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

ステップ8(オプション): ノード・マネージャ環境変数の設定

デフォルトでは、ノード・マネージャを起動する前に追加の環境変数を設定する必要はありません。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)

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

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

環境変数

説明

JAVA_HOME

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

set JAVA_HOME=c:\jdk1.7.0_06

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

WL_HOME

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

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

PATH

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

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

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アーキテクチャが可能です。該当するアーキテクチャに応じてパスは変わる可能性があります。

CLASSPATH

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

Windows NTの例:

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

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

この章では、ノード・マネージャのJavaバージョンを構成する方法について説明します。

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

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

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

- nodemanager.propertiesのレビュー

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

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

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

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

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

このリリースでは、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に自動的に作成され、ノード・マネージャをWindowsサービスとして起動、停止、インストール、アンインストールするためのドメイン固有のスクリプトは、DOMAIN_HOME\binにあります。ノード・マネージャのデフォルト構成では、NodeManagerHomeの場所であるDOMAIN_HOME\nodemanagerは編集できません。

構成ウィザードまたはWLSTオフラインを使用し、PerDomainまたはCustomLocationのJavaベースのノード・マネージャ構成を選択できます。固有のノード・マネージャ資格証明を提供できる点を除けば、PerDomain構成は、デフォルト構成の内容とまったく同じです。NodeManagerHomeとして固有の場所を指定する場合は、CustomLocationを選択して空のディレクトリを指定するか、ディレクトリの作成を選択します。その結果、ノード・マネージャもドメインごとのプロセスとして実行されます。

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

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

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

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

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

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

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

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

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

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

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

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

4. 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を参照してください。

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ベースのノード・マネージャのセキュリティの構成

ノード・マネージャのセキュリティは、クライアントとサーバーの間の一方向SSL接続に依存します。

WebLogic Server Scripting Tool (WLST)のnmConnectコマンドを使用してJavaノード・マネージャへのコマンドライン接続を確立する場合は、ノード・マネージャのユーザー名とパスワードを指定します。ノード・マネージャは、ドメインのnm_password.propertiesファイルに対してユーザー名とパスワードを検証します。nm_password.propertiesの詳細は、「手順2: ノード・マネージャのユーザー名およびパスワードの指定」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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回は起動しない限り、このファイルにはアクセスできません。

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

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

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

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

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

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

説明

デフォルト

PropertiesVersion

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

none

AuthenticationEnabled

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

true

LogFile

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

NodeManagerHome\nodemanager.log

LogLimit

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

unlimited

LogCount

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

1

LogAppend

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

true

LogToStderr

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

false

LogLevel

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

INFO

LogFormatter

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

weblogic.nodemanager.server.LogFormatter

ListenBacklog

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

50

CrashRecoveryEnabled

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

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

false

SecureListener

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

true

CipherSuite

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

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

StartScriptEnabled

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

true

StartScriptName

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

startWebLogic.sh (UNIX)

または

startWebLogic.cmd (Windows)

StopScriptEnabled

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

false

StopScriptName

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

none

QuitEnabled

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

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

false

DomainsFile

nodemanager.domainsファイルの名前。

NodeManagerHome\nodemanager.domains

DomainsFileEnabled

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

true

StateCheckInterval

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

500 milliseconds

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

JavaHome

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

none

JavaStandardTrustKey

StorePassPhrase

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

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アドレスでリスニングします。

ListenPort

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

5556

NativeVersionEnabled

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

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

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

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

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

- nmKillは、NativeVersionEnabled=falseおよびStartScriptEnabled=trueの場合はサポートされません。

true

NodeManagerHome

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

- nodemanager.domains

- nodemanager.log

- nodemanager.properties

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

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

NodeManagerHome

WebLogicHome

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

none

keyFile

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

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

none

keyPassword

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

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

none

certificateFile

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

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

none

NetMask

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

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

none

Interface

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

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

none

<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を表します。

なし

DomainsDirRemoteSharingEnabled

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

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

false

DomainRegistrationEnabled

デフォルトでは、クライアントは動的に新しいドメインを登録できず、ドメイン作成時か、ノード・マネージャを起動する前にドメインを構成する必要があります。

trueに設定した場合、クライアントは自動的に新しいドメインを登録できますが、これはセキュリティ上リスクを伴うため、お薦めしません。

false

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

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

注意:

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

スクリプトの場所

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

DOMAIN_HOME\bin\service_migration

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

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

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

起動スクリプトの使用

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

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

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

注意:

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

# custom stuff
# custom stuff
startWebLogic.sh

ノード・マネージャは、JAVA_VENDOR、JAVA_HOME、JAVA_OPTIONS、SECURITY_POLICY、CLASSPATH、およびADMIN_URLを設定します。管理コンソールを使用してサーバーを起動するか、または管理サーバーに接続された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ファイルで、StopScriptEnabledプロパティをtrueに設定します。

2. nodemanager.propertiesファイルで、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

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

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

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

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

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

複数の物理マシン上に管理対象サーバーがあるドメインでは、ノード・マネージャが各マシンにインストールされ、構成されていることを確認する必要があります。必要なすべてのドメインおよび構成情報をマシンからマシンへコピーするには、WLSTコマンドのnmEnrollを使用します。詳細は、『WebLogic Server WLSTコマンド・リファレンス』のノード・マネージャへのアクセスに関する項およびnmEnrollに関する項を参照してください。

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

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

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

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

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

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

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

# default: off
# description:nodemanager as a service
service nodemgrsvc
{
type            = UNLISTED
disable         = no
socket_type     = stream
protocol        = tcp
wait            = yes
user            = <username>
port            = 5556
flags           = NOLIBWRAP
log_on_success += DURATION HOST USERID
server          = <path-to-java>/java
env             = CLASSPATH=<cp> LD_LIBRARY_PATH=<ldpath>
server_args     = -client -DNodeManagerHome=<NMHome> <java options>
<nodemanager options> weblogic.NodeManager -v
}

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

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

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

- 概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

概要

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

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

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

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

注意:

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:/home/username/bea/user_projects/domains/domain_name/bin/server_migration

このファイルはUSER_HOME/.ssh/にあります。

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

すなわち、あるマシン上の任意のndmgrユーザーは、同じマシンまたは異なるマシン上の同じ名前のndmgrユーザーと、セキュリティ資格証明を求められることなくSSHセッションを確立できる必要があります。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_keys2

> chmod 700 .ssh/authorized_keys2

> cat id_dsa.pub >> .ssh/authorized_keys2

> rm id_dsa.pub

> exit

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

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

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

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

beaユーザーとして、WebLogic Serverを実行するすべてのマシン上のベース・ディレクトリ/opt/bea/wlserverに、WebLogic Serverインスタンスをインストールします。

例:

> ./ wls_generic.jar

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

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

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

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

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

例:

1. 構成ウィザードを実行します。
> /opt/bea/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にし、/opt/bea/clustdomainに保存します。

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

ndmgrユーザーとして、wlscontrol.shノード・マネージャ・スクリプトを使用してターミナルからローカルに管理サーバーを起動します。

例:

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

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

正常に起動したら、管理サーバーを停止してからSSHを使用してリモートに起動します。

例:

> ssh -l ndmgr -o PasswordAuthentication=no %p 22 192.168.1.100
/opt/bea/wlserver_
103/common/bin/wlscontrol.sh -d clustdomain -r /home/ndmgr/clustdomain -c -f
startWebLogic.sh -s AdminServer START

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

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

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

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

> opt/bea/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を指定する必要があります。ノード・マネージャのデフォルトのホーム・ディレクトリは/opt/bea/wlserver/common/nodemanagerですが、このディレクトリは製品のインストール・ディレクトリ内にあり、他のユーザーが所有するため、使用しないことをお薦めします。

注意:

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

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

1. ノード・マネージャの新しいドメイン・ホームに、WebLogicスクリプト・ディレクトリ(bin)を作成します。
例:

> mkdir ~/clustdomain/bin

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

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

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

2. LONG_DOMAIN_HOME=/home/ndmgr/clustdomain

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

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

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

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

注意:

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

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

username=weblogic

password=password

注意:

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

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

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

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

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

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

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

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

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

表5-1 UNIXマシンの設定

プロパティ

値

OSの種類

UNIX

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

SSH

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

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

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

22

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

/home/ndmgr

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

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

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

true

サーバー

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

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

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

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

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

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

デフォルトの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="/home/bea/server90/common/nodemanager/nodemanager.sh" 1024 33 23...2323

ここで、例で示した次の文字列を、id_rsa.pubに格納されている生成した公開鍵で置き換えます。

1024 33 23...2323

注意:

接頭辞command=コマンドは、公開鍵を使用してマシンとのセッションを確立するユーザーがnodemanager.shで指定されたコマンドしか実行できないことを保証しています。これによりユーザーはノード・マネージャ機能を実行するだけになり、データ、システム・ユーティリティなどのマシン上のリソースへの権限のないアクセスが防止されます。

3. ノード・マネージャのサーバー・インスタンスまたはクライアントをホストする各マシンにキーと値のペアを手動で配布します。

4. クライアント・マシン上で次のコマンドを実行して、ノード・マネージャ・クライアントがノード・マネージャにアクセスできることを確認します。
/home/bea$ ssh montgomery VERSION

次のレスポンスは、クライアントがノード・マネージャに正常にアクセスしたことを示します。

+OK NodeManager v9.1.0

個々のキーと値のペア

ノード・マネージャ・クライアントをホストするマシンごとに、次の手順を行います。

1. 前の項のステップ1の説明に従って、ノード・マネージャ・ユーザーの個々のRSAキー値ペアを生成します。

2. 前の項のステップ2の説明に従って、マシン上の ~/.ssh/authorized_keysファイルに公開鍵を追加します。

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

この章では、Javaベースおよびスクリプトベースのノード・マネージャを起動と停止する方法について説明します。また、ノード・マネージャを使用してサーバーを起動する際の推奨ステップも示します。

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

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

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

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

次の方法で、ノード・マネージャの起動と停止を行います。

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

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

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

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

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

スタートアップ・サービスとして、ノード・マネージャのインストールをお薦めします。これによって、システムが再起動されるたびに、ノード・マネージャが自動で起動されます。

注意:

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.

デフォルトでは、ノード・マネージャはローカル・ホストのみからリスニングします。ノード・マネージャでリモート・システムからのコマンドを受け付けるようにする場合は、localhost以外のリスニング・アドレスでリスニングするようにスクリプトを編集します。

注意:

WL_HOME\server\bin\installNodeMgrSvc.cmdを使用して、ホストごとのノード・マネージャをWindowsサービスとして実行するには、「ノード・マネージャのデフォルト構成」に説明されているように、前提条件の構成手順を最初に実行する必要があります。

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

オペレーティング・システム・サービスとしてノード・マネージャを実行することをお薦めしますが、コマンド・プロンプトまたはスクリプトを使用してノード・マネージャを手動で起動することもできます。ノード・マネージャで必要な環境変数については、「ステップ8(オプション): ノード・マネージャ環境変数の設定」を参照してください。

ノード・マネージャのサンプル起動スクリプトは、各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のこのリリースでは、スクリプト・バージョンのノード・マネージャを実行する前に、ノード・マネージャ・インスタンスで制御するドメインを指定するnodemanager.domainsファイルを、NodeManagerHomeに作成またはコピーする必要があります。「ステップ4: 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属性には、リモートのSSHノード・マネージャとの通信と、制御下にあるサーバー・インスタンスに対するノード・マネージャ機能の実行に使用するコマンド・テンプレートを指定します。

テンプレートは、ノード・マネージャをホストしているリモート・マシン上のデフォルトのパスに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.ListenAddress

22

%S

WebLogic Server名

なし

%D

WebLogicドメイン名

なし

%R

ドメイン・ディレクトリ(サーバーのルート)

ServerStartMBean.RootDirectory

%C

ノード・マネージャ・スクリプトのコマンド

- START - サーバーを起動する

- KILL - サーバーを強制停止する

- STAT - サーバーのステータスを取得する

- GETLOG - サーバーの出力ログを取得する

- VERSION - ノード・マネージャのバージョンを戻す

注意:この要素を、ファイル内の最後の要素にする必要があります。

none

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

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、『WebLogic Server WLSTコマンド・リファレンス』のstopNodeManagerに関する項を参照してください。

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

通常、管理サーバーおよび管理対象サーバーの起動と停止には、WebLogic Scripting Toolとノード・マネージャを使用することをお薦めします。この項では、ノード・マネージャを使用してサーバーを起動する際の推奨手順を示します。

詳細は、『WebLogic Server WLSTコマンド・リファレンス』のWLSTとノード・マネージャを使用したサーバー管理に関する項およびノード・マネージャ・コマンドに関する項を参照してください。

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

WLSTとノード・マネージャを使用して管理サーバーを起動する場合は、次の一般的な手順に従うことをお薦めします。

1. ノード・マネージャを起動します。「ノード・マネージャの起動と停止」を参照してください。

2. WLSTを呼び出します。
Windowsの場合は、「スタート」メニューのショートカットで環境変数を設定し、WLSTを呼び出すことができます。

3. nmConnectコマンドを使用して、WLSTをノード・マネージャに接続します。

4. nmStartコマンドを使用して管理サーバーを起動します。

管理サーバーが起動したら、WLSTを使用してドメイン内の管理対象サーバーを起動できます。

注意:

nmStartコマンドを使用してサーバーを起動した場合は、ノード・マネージャで管理サーバーの状態をモニターし、起動に失敗した場合に再起動することが可能です。ノード・マネージャによって再起動できるのは、この方法で起動したサーバーのみです。

nmStartを使用すると、特定のプロパティをサーバーに渡すことができます。ただし、デバッグの際にのみ使用するようにしてください。nmStartで渡したサーバー・プロパティは、次回のサーバー再起動時までは保持されません。

管理対象サーバーの起動

WLSTとノード・マネージャを使用して管理対象サーバーを起動する場合は、次の一般的な手順に従うことをお薦めします。

1. ノード・マネージャを起動します。「ノード・マネージャの起動と停止」を参照してください。

2. 管理サーバーを起動します。『Oracle WebLogic Serverサーバーの起動と停止の管理』のWebLogic Serverのインスタンスの起動に関する項を参照してください。

3. WLSTを呼出し、connectコマンドを使用して管理サーバーに接続します。

4. WLST startコマンドを使用して管理対象サーバーを起動します。

startコマンドを使用した場合は、WLSTが管理サーバーにアクセスして管理対象サーバーの起動プロパティを識別します。これらのプロパティは、最終的にはノード・マネージャに渡され、管理対象サーバーの起動に使用されます。

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

管理対象サーバーの起動プロパティの識別に管理サーバーを使用したくない場合は、WLSTとノード・マネージャを使用して、次に示す一般的な手順に従って管理対象サーバーを起動することをお薦めします。

1. ノード・マネージャを起動します。「ノード・マネージャの起動と停止」を参照してください。

2. WLSTを呼出し、nmConnectコマンドを使用してノード・マネージャに接続します。

3. WLST nmStartコマンドを使用して管理対象サーバーを起動します。

注意:

デフォルト・セキュリティ・プロバイダを使用する場合は、管理対象サーバー・インスタンスの初回起動時に、そのサーバー・インスタンスが管理サーバーにアクセスできる状態にある必要があります。

nmStartコマンドを使用すると、管理サーバーを使用しなくても、任意のサーバー起動プロパティを指定して管理対象サーバーを再起動できます。ただし、以下の点を考慮に入れてください。

- nmStartでサーバーを起動するには、boot.propertiesとstartup.propertiesが定義済である必要があります。

- nmStartでは、サーバーの起動プロパティを恒久的に変更することはできません。それらのプロパティは、次回そのサーバーを管理サーバーから移行または再起動するときには使用されません。

- サーバーのユーザー名とパスワードをnmStartを使用して渡す場合、これらの値は暗号化されません。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

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の登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。