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 のノード マネージャをホストするすべてのマシンと、ノード マネージャ クライアント (管理サーバを含む) をホストするすべてのマシンに追加します。

次に例を示します。

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

   • bea は WebLogic Server のインストールにのみ使用。

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

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/nodemanager へのパスが含まれるようにします。 次に例を示します。 PATH=/usr/bin:/bin:/home/username/bea/user_projects/domains/ domain_ name/bin/nodemanager このファイルは 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_103 に、WebLogic Server インスタンスをインストールします。

次に例を示します。

> ./ wlserver_103_linux32.bin

手順 4: WebLogic ドメインの作成

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

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

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

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

次に例を示します。

1. コンフィグレーション ウィザードを実行します。

   > /opt/bea/wlserver_103/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_103/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_103/common/bin/wlst.sh

   > connect('weblogic','welcome1','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_103/common/nodemanager.domains ですが、このディレクトリは製品のインストール ディレクトリ内にあり、他のユーザが所有するため、使用しないことをお勧めします。

手順 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. setDonainEnv.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=welcome1

   
   

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

   
   

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

   たとえば、管理対象サーバ MS1 を起動するには、次のように指定します。

   > opt/bea/wlserver_103/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_103/common/bin/wlscontrol.sh -d clustdomain -n /home/ndmgr -c -f startManagedWebLogic.sh -s MS1 START

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

手順 8: UNIX マシンのコンフィグレーション

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

表 5-1 UNIX マシンの設定

プロパティ	値
OS の種類	UNIX
ノード マネージャの種類	SSH
ノード マネージャのリスン アドレス	<プライマリ IP アドレス> (浮動 IP アドレスではない)
ノード マネージャのリスン ポート	22
ノード マネージャのホーム ディレクトリ	/home/ndmgr
ノード マネージャのシェル コマンド	ssh -l ndmgr -o PasswordAuthentication=no -p %P %H /opt/bea/wlserver_103/common/bin/wlscontrol.sh -d %D -n /home/ndmgr -c -f startManagedWebLogic.sh -s %S %C
ノード マネージャのデバッグの有効化	true
サーバ	<マシンでホストされる管理サーバまたは管理対象サーバの名前>

手順 9: マシンへのサーバの割り当て

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

手順 10: 管理対象サーバの起動

Administration Console で、各管理対象サーバを起動します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「Administration Console からの管理対象サーバの起動」を参照してください。

各管理対象サーバの /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 をコンフィグレーションできます。

スクリプトベースのノード マネージャ用のリモート サーバ起動セキュリティのコンフィグレーション

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

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

• 管理サーバの資格 - 管理サーバを起動するためにノード マネージャを呼び出す場合、リモート起動ユーザのユーザ名はコマンドラインで指定することも、管理サーバの 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=command は、公開鍵を使用してマシンとのセッションを確立するユーザが nodemanager.sh で指定されたコマンドしか実行できないことを保証しています。これによりユーザはノード マネージャ機能を実行するだけになり、データ、システム ユーティリティなどのマシン上のリソースへの権限のないアクセスが防止されます。

   
   

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

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

   /home/bea$ ssh montgomery VERSION

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

   +OK NodeManager v9.1.0

個々のキーと値のペア

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

1. 前の節の手順 1 の説明に従って、ノード マネージャ ユーザの個々の RSA キー値ペアを生成します。

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