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

以下の節ではノードマネージャの概要を説明します。

概要
ノードマネージャのバージョン
ノードマネージャへのアクセス
ノードマネージャの機能
WebLogic Server 環境でのノードマネージャの機能
ノードマネージャとシステムクラッシュの回復
ノードマネージャのコンフィグレーションファイルとログファイル

概要

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

ノードマネージャプロセスは、特定の WebLogic ドメインではなく、マシンに関連付けられます。サーバインスタンスがノードマネージャプロセスと同じマシン上に存在している限り、同じノードマネージャプロセスを使用して任意の WebLogic Server ドメインのサーバインスタンスを制御できます。ノードマネージャは、ノードマネージャを使用して制御する WebLogic Server インスタンス (管理サーバまたは管理対象サーバ) をホストするコンピュータごとに実行する必要があります。

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

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

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

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

Oracle では、Windows、Solaris、HP-UX、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 クライアントが用意されています)。

管理サーバ
- Administration Console の [環境｜マシン｜コンフィグレーション｜ノードマネージャ] ページ
たとえば、管理サーバに通信して ServerLifeCycleRuntimeMBean に対するオペレーションを実行する JMX ユーティリティを作成できます。この ServerLifeCycleRuntimeMBean は、内部でノードマネージャを使用して、オペレーションを実行します。JMX の詳細については『Oracle Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』を参照してください。
WLST コマンドおよびスクリプト - WLST オフラインは実行中の管理サーバが存在しない場合に実行可能なノードマネージャコマンドラインインタフェースとして機能します。WLST コマンドを使用すると、管理サーバに接続せずにサーバインスタンスの起動、停止、およびモニタを行うことができます。管理サーバの起動が、スタンドアロンクライアントの主な目的です。しかし、以下の目的にも使用することができます。
- ノードマネージャを使用して起動されたサーバインスタンスの停止
- 管理対象サーバの起動
- ノードマネージャのログファイルの内容へのアクセス
- ノードマネージャで起動されたサーバのステータスの取得
- サーバ出力ログの内容の取得

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

ノードマネージャの機能

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

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

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

管理サーバをノードマネージャの制御下に置くことができる。ノードマネージャを使用して管理サーバを起動、モニタ、および再起動できます。
管理サーバをノードマネージャクライアントにできる。Administration Console から管理対象サーバを起動または停止するときには、管理サーバを使用してノードマネージャにアクセスしています。
管理サーバではノードマネージャを使用して管理対象サーバを起動するプロセスがサポートされている。ノードマネージャを使用して管理対象サーバを起動するときには、管理対象サーバは管理サーバにアクセスして未処理のコンフィグレーションの更新を取得します。

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

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

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

注意 :

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

注意 :

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

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

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

注意 :

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

再起動機能はコンフィグレーション可能です。ノードマネージャのデフォルトの動作は、以下のとおりです。

障害の発生した、制御下にあるサーバインスタンスを自動的に再起動する。この機能は無効にできます。
障害の発生したサーバインスタンスを特定の回数まで再起動する。再起動の回数は、ノードマネージャの startup.properties ファイルで RestartMax プロパティを設定して定義します。

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

注意 :

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

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

ノードマネージャは、ノードマネージャプロセスのログファイルと、自身が制御する各サーバインスタンスのサーバ出力ログファイルを作成します。これらのログファイルは、サーバインスタンスのログファイルと同様に Administration Console または WLST またはコマンドを使用して表示できます。

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

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

ノードマネージャとサーバの図
ノードマネージャが管理サーバを起動する仕組み
ノードマネージャが管理対象サーバを起動する仕組み
ノードマネージャが管理サーバを再起動する仕組み
ノードマネージャが管理対象サーバを再起動する仕組み
ノードマネージャがサーバインスタンスを停止する仕組み

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

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

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

「図 2-1 WebLogic Server 環境でのノードマネージャ」の説明

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

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

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

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

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

「図 2-2 管理サーバの起動」の説明

認可されたユーザが、管理サーバをホストするマシン上のノードマネージャプロセスに接続するための WLST オフラインコマンド nmConnect を発行し、管理サーバを起動するためのコマンドを発行します (ノードマネージャインスタンスが SSH バージョンである場合は、ユーザは SSH クライアントを使用して接続できます)。

起動コマンドは起動するドメインおよびサーバインスタンスを特定し、Java ベースのノードマネージャの場合はノードマネージャユーザのユーザ名とパスワードを指定します。

注意 :

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

ノードマネージャが nodemanager.domains でドメインディレクトリをルックアップし、暗号化されたユーザ名とパスワードを格納するローカルファイルを使用してユーザの資格を認証します。
ノードマネージャが管理サーバのプロセスを作成します。
管理サーバが、その config ディレクトリからドメインコンフィグレーションを取得します。

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

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

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

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

「図 2-3 管理対象サーバの起動」の説明

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

注意 :
スタンドアロンクライアントは、管理対象サーバの起動コマンドを発行することもできます。
管理サーバが、管理対象サーバ 1 用にコンフィグレーションされたリモート起動プロパティを指定して、マシン B 上のノードマネージャに管理対象サーバ 1 の起動コマンドを発行します。引数とその指定方法の詳細については、「手順 5: リモート起動引数のコンフィグレーション」を参照してください。
ノードマネージャが管理対象サーバ 1 を起動します。

ノードマネージャは、ノードマネージャプロセスが実行されているものと同じルートディレクトリを使用してその管理対象サーバを起動します。別のディレクトリで管理対象サーバを実行するには、[サーバ｜コンフィグレーション｜サーバの起動] コンソールページで [ルートディレクトリ] 属性を設定します。
管理対象サーバ 1 が管理サーバにアクセスし、コンフィグレーション情報の更新をチェックします。
ドメインコンフィグレーションに未処理の変更がある場合、管理対象サーバ 1 はコンフィグレーションデータのローカルキャッシュを更新します。

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

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

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

注意 :

サーバインスタンスの AutoRestart 属性が false に設定されている場合、ノードマネージャはそのインスタンスを再起動しません。

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

「図 2-4 管理サーバの再起動」の説明

ノードマネージャが管理サーバプロセスの終了コードから再起動が必要であると判断します。
ノードマネージャが boot.properties ファイルから管理サーバの起動に使用するユーザ名とパスワードを取得し、server_name/data/nodemanager/startup.properties ファイルからサーバの起動プロパティを取得します。
ノードマネージャが管理サーバを起動します。
管理サーバがそのコンフィグレーションデータを読み込み、起動します。

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

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

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

注意 :

サーバインスタンスの AutoRestart 属性が false に設定されている場合、ノードマネージャはそのインスタンスを再起動しません。

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

「図 2-5 管理対象サーバの再起動」の説明

ノードマネージャが管理対象サーバ 1 の最新の既知の状態から再起動が必要であると判断します。
ノードマネージャが boot.properties ファイルから管理対象サーバ 1 の起動に使用するユーザ名とパスワードを取得し、startup.properties ファイルからサーバの起動プロパティを取得します。これらのサーバ固有のファイルは、管理対象サーバ 1 のサーバディレクトリにあります。
ノードマネージャが管理対象サーバ 1 を起動します。

注意 :
ノードマネージャは、サーバインスタンスに障害が発生した後から RestartDelaySeconds で指定された秒数待機してから再起動を行います。
管理対象サーバ 1 が管理サーバにアクセスし、コンフィグレーションデータの更新をチェックします。管理サーバにアクセスし、コンフィグレーションデータの更新を取得すると、管理対象サーバ 1 は config ディレクトリのローカルキャッシュを更新します。
管理対象サーバ 1 が管理サーバにアクセスできなかった場合に管理対象サーバ独立 (MSI) モードが有効になっていると、管理対象サーバ 1 はローカルにキャッシュされたコンフィグレーションデータを使用します。

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

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

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

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

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

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

認可されたユーザが、Administration Console を使用して管理対象サーバ 1 の停止コマンドを発行します。
管理サーバが管理対象サーバ 1 に直接停止コマンドを発行します。管理対象サーバ 1 へのアクセスが成功すると、管理対象サーバ 1 は『Oracle Fusion Middleware Oracle WebLogic Server サーバの起動と停止の管理』の「正常な停止」で説明されている停止シーケンスを実行します。
前の手順で管理対象サーバ 1 へのアクセスが失敗した場合、管理サーバはマシン B 上のノードマネージャに管理対象サーバ 1 の停止コマンドを発行します。
ノードマネージャが、オペレーティングシステムに管理対象サーバ 1 を強制停止するように要求を発行します。
オペレーティングシステムが管理対象サーバ 1 のプロセスを終了させます。

ノードマネージャとシステムクラッシュの回復

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

CrashRecoveryEnabled が true に設定されていることを確認する。

CrashRecoveryEnabled コンフィグレーションプロパティを true に設定すると、システムクラッシュの後にノードマネージャがサーバを再起動します。このプロパティは、デフォルトでは有効になっていません。
管理サーバをノードマネージャを使用して起動する。
すべての管理対象サーバを管理サーバを使用して起動する。この操作は、WLST または Administration Console で実行できます。

システムの再起動後、ノードマネージャは nodemanager.domains ファイルで指定された各管理対象ドメインをチェックして、停止に問題のあったサーバインスタンスがあるかどうかを判断します。これは、WebLogic Server プロセスの作成時にノードマネージャによって作成されたロックファイルが存在するかどうかによって決まります。このロックファイルには、WebLogic Server 起動スクリプトのプロセス識別子が含まれています。ロックファイルが存在するが、プロセス ID が実行されていない場合、ノードマネージャは自動的にサーバを再起動しようとします。

プロセスが実行中であれば、ノードマネージャはさらにチェックを行ってプロセス内で実行されている管理サーブレットにアクセスし、プロセス ID に対応するプロセスが、WebLogic Server インスタンスであることを確認します。

注意 :

ノードマネージャがチェックを実行して管理サーブレットにアクセスする際、不適切な資格に関し、サーバログ内に警告が示されることがあります。

ノードマネージャのコンフィグレーションファイルとログファイル

複数のサーバを管理する場合、ノードマネージャは、図 2-7 に示すように複数のコンフィグレーションファイルを使用し、複数のディレクトリにログファイルを出力します。

図 2-7 ノードマネージャのコンフィグレーションとロギングの環境

「図 2-7 ノードマネージャのコンフィグレーションとロギングの環境」の説明

以下の節では、ノードマネージャのコンフィグレーションファイルとログファイルについて説明します。

コンフィグレーションファイル
ログファイル

コンフィグレーションファイル

言及されていない限り、コンフィグレーションファイルは Java ベースのノードマネージャとスクリプトベースのノードマネージャの両方に適用されます。

nodemanager.properties

Java ベースのノードマネージャによって使用されるコンフィグレーションファイルです。「nodemanager.properties の検討」を参照してください。

このファイルは WL_HOME/common/nodemanager にあります。WL_HOME は WebLogic Server のインストール先ディレクトリです。

nodemanager.domains

このファイルには、ノードマネージャによって管理されるドメインの名前と、それに対応するディレクトリのマッピングが格納されます。「手順 4: nodemanager.domains ファイルのコンフィグレーション」を参照してください。

このファイルは WL_HOME/common/nodemanager にあります。

nm_data.properties

このファイルには、ノードマネージャが対称暗号化キーとして使用する暗号化データが格納されます。データは暗号化された形で保存されます。

このファイルは WL_HOME/common/nodemanager にあります。

nm_password.properties

このファイルには、ノードマネージャのユーザ名とパスワードが格納されます。「手順 2: ノードマネージャのユーザ名とパスワードの指定」を参照してください。

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