![]() ![]() ![]() ![]() |
以下の節では、スクリプトベースのノード マネージャのコンフィグレーション方法について説明します。
SSH ノード マネージャは、WL_HOME/common/bin/
にあるシェル スクリプト wlscontrol.sh
です。wlscontrol.sh
ファイルは、ノード マネージャを使用して制御するサーバ インスタンスをホストするマシンごとに存在していなければなりません。このスクリプトは、サイト固有の要件を満たすようにカスタマイズできます。
ノード マネージャまたはノード マネージャ クライアントを実行するマシンごとに SSH クライアントが実行可能でなければなりません。また、このスクリプトはユーザ ID が実行するパス内になければなりません。通常、SSH クライアントは UNIX または Linux インストールの標準的な一部です。
ノード マネージャを実行する前に、ノード マネージャ機能の実行専用の UNIX ユーザ アカウントを作成する必要があります。このユーザを、SSH のノード マネージャをホストするすべてのマシンと、ノード マネージャ クライアント (管理サーバを含む) をホストするすべてのマシンに追加します。
ノード マネージャの 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 で、ユーザのあるインスタンスが別のインスタンスを信頼するようにコンフィグレーションするには、次の手順に従います。
> scp .ssh/id_dsa.pub ndmgr@192.168.1.101:./
> 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
あるいは、各マシンでキーと値のペアを生成し、すべての公開鍵を 1 つの authorized_keys2
ファイルに連結し、そのファイルをすべてのマシンにコピー (scp
) しても、同じ結果が得られます。すべてのマシンの組み合わせで SSH セッションの確立を試行し、~/.ssh/known_hosts
ファイルが適切にコンフィグレーションされていることを確認します。詳細については、「キーと値のペアの生成と配布」を参照してください。
bea ユーザとして、WebLogic Server を実行するすべてのマシン上のベース ディレクトリ /opt/bea/wlserver_103
に、WebLogic Server インスタンスをインストールします。
> ./ wlserver_103_linux32.bin
ndmgr ユーザのホーム ディレクトリで、管理サーバのみをホストするマシン上に WebLogic ドメインを作成します。
このドメイン ディレクトリの config
サブディレクトリにあるコンフィグレーションは、後で管理サーバを起動する際、管理サーバとドメインの設定を特定するために使用されます。
多くの場合、管理対象サーバ インスタンスは、管理サーバに対してリモートに実行されます。したがって、これらの管理対象サーバは、管理サーバのドメイン コンフィグレーション ディレクトリに直接アクセスすることはありません。代わりに、管理対象サーバは、個々のマシンの ndmgr ホーム ディレクトリにあるスケルトン ドメイン ディレクトリから実行され、起動時に、リモートに実行されている管理サーバからネットワークを介してコンフィグレーションを取得します。
ndmgr ユーザとして、WebLogic ドメインを作成します。
> /opt/bea/wlserver_103/common/bin/config.sh
192.168.1.100
など) を指定します。MS1
および MS2
を追加します。
管理対象サーバには、浮動 IP アドレス (192.168.1.201
および 192.168.1.202
など) を指定します。
CLUST
を追加し、このクラスタに MS1
および MS2
を割り当てます。
マシンや UNIX マシンの指定は後で手動で行うため、ここでは実行しません。
clustdomain
にし、/opt/bea/clustdomain
に保存します。
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
管理対象サーバをホストする各マシンでは、スケルトン ドメインを作成し、コンフィグレーションします。
clustdomain
) を新たに作成します。次に例を示します。
> opt/bea/wlserver_103/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_103/common/nodemanager.domains
ですが、このディレクトリは製品のインストール ディレクトリ内にあり、他のユーザが所有するため、使用しないことをお勧めします。
bin
) を作成します。 bin
ディレクトリのスクリプトを、各ノード マネージャ マシン上の対応するドメイン bin
ディレクトリ (/home/ndmgr/bin
など) にコピーします。次に例を示します。
> scp ndmgr@192.168.1.100: ~/clustdomain/bin/* ndmgr@192.168.1.101:~/clustdomain/bin
bin
ディレクトリ内のシェル スクリプトを編集し、ローカル ドメイン ホームの適切なパスとリモート管理サーバの IP アドレスを反映させます。 setDonainEnv.sh
スクリプト内の DOMAIN_HOME
および LONG_DOMAIN_HOME
変数を編集し、このリモート ホーム ディレクトリを適切に反映させます (DOMAIN_HOME=/home/ndmgr/clustdomain
LONG_DOMAIN_HOME=/home/ndmgr/clustdomain
)。startWebLogic.sh
内の DOMAIN_HOME
変数を編集します。startManagedWebLogic.sh
内の DOMAIN_HOME
変数および ADMIN_URL
変数 (t3://192.168.1.100:7001
など) を編集します。 server/security
サブディレクトリを作成します。
たとえば、管理対象サーバが MS1
の場合は次のように指定します。
> mkdir -p ~/clustdomain/servers/MS1/security
注意 : | バックアップ マシンでは、すべての移行可能管理対象サーバ (たとえば、MS1 と MS2 ) のサーバ ディレクトリを作成します。 |
boot.properties
ファイルを、各管理対象サーバの security
ディレクトリ (/home/ndmgr/clustdomain/servers/MS1/security
など) に新たに作成します。
Username=weblogic
Password=weblogic
注意 : | このファイル内の値は、スクリプトベースのノード マネージャで管理対象サーバを初めて起動するときに暗号化されます。 |
wlscontrol.sh
ノード マネージャ スクリプトを使用してターミナルからローカルに管理対象サーバを起動します。
たとえば、管理対象サーバ MS1
を起動するには、次のように指定します。
> opt/bea/wlserver_103/common/bin/wlscontrol.sh -d clustdomain -n /home/ndmgr -c -f startManagedWebLogic.sh -s MS1 START
標準出力に冗長ロギングするには、コマンドに -x
パラメータを追加します。
> 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
MS1
) の起動を試行してこのプロセスを繰り返します。正常に起動する度に、そのサーバを停止してください。
Administration Console を使用して、管理サーバまたは管理対象サーバをホストする各マシン (バックアップ マシンも含む) に新しい UNIX マシンを追加し、次の設定を含めます。
すべての UNIX マシンを作成したら、Administration Console を使用して各サーバの [マシン] プロパティを設定し、各サーバが対応する UNIX マシンに関連づけられるようにします。Administration Console オンライン ヘルプの「サーバ インスタンスのマシンへの割り当て」を参照してください。
Administration Console で、各管理対象サーバを起動します。Administration Console オンライン ヘルプの「Administration Console からの管理対象サーバの起動」を参照してください。
各管理対象サーバの /home/ndmgr/clustdomain/servers/
<管理対象サーバ名>
/logs
ディレクトリにあるサーバ ログで、サーバがエラーなく起動していることを確認します。
ノード マネージャで使用されるデフォルトの SSH ポートは 22 です。この設定は、以下の方法でオーバーライドできます。
サーバの移行などのタスクを実行するには、wlscontrol.sh
などのスクリプトを実行するユーザ ID に十分なセキュリティ パーミッションが必要です。たとえば、ネットワーク インタフェースを通じて IP アドレスをオンラインにしたり、オフラインにしたりできるパーミッションなどです。
サーバの移行は、サーバに障害が発生したことを検出したときに、クラスタ マスターによって実行されます。クラスタ マスターは SSH を使用して対象のマシンにあるスクリプトを起動し、移行を開始します。対象のマシンにあるスクリプトは、クラスタのマスター上でサーバを実行しているのと同じユーザ ID で実行されます。
サーバの移行を実行するために必要なコマンドは wlsifconfig と arping です。これらのスクリプトには高度な OS 権限が必要になるため、セキュリティ ホールの可能性を防止できる点に留意することが重要です。sudo を使用すると、高度な権限による wlsifconfig と arping の実行のみを許可するように SSH をコンフィグレーションできます。
ノード マネージャを使用してサーバ インスタンスを起動するには、リモート起動ユーザのユーザ名とパスワードが必要です。管理サーバと管理対象サーバでは、これらの資格の指定方法が異なります。
ノード マネージャによって起動されたサーバ インスタンスでは、自動再起動に使用するために、サーバの起動に使用された資格が暗号化され、サーバ固有の boot.properties
ファイルに保存されます。
スクリプトベースのノード マネージャでは、2 種類のキーと値のペアが使用されます。この節では、キーと値のペアをノード マネージャのクライアントまたはサーバをホストするマシンに配布する手順について説明します。
このオプションでは、同じキーと値のペアをノード マネージャのクライアントまたはサーバをホストするすべてのマシンに配布します。
最も簡単な方法は、ノード マネージャ ユーザのホーム ディレクトリを各マシンにマウントするようにするように LAN を設定することです。これにより、キーと値のペアがすべてのマシンで使用可能になります。この方法を使用しない場合は、次の手順を行います。
ssh-keygen
コマンドを使用して、ユーザの RSA キー値ペアを生成します。
プライベート キーと公開鍵のデフォルトの場所はそれぞれ、~/.ssh/id_rsa
と ~/.ssh/id_rsa.pub
です。
これらのキーが異なる場所に格納されている場合は、ssh
コマンドにオプションを追加してキーの場所を指定するように ShellCommand
テンプレートを変更します。
~/.ssh/authorized_keys
ファイルに公開鍵を追加します。
command="/home/bea/server90/common/nodemanager/nodemanager.sh" 1024 33 23...2323
ここで、例で示した次の文字列を、id_rsa.pub
に格納されている生成した公開鍵で置き換えます。
注意 : | プレフィックス command=<command> は、公開鍵を使用してマシンとのセッションを確立するユーザが nodemanager.sh で指定されたコマンドしか実行できないことを保証しています。これによりユーザはノード マネージャ機能を実行するだけになり、データ、システム ユーティリティなどのマシン上のリソースへの権限のないアクセスが防止されます。 |
/home/bea$ ssh montgomery VERSION
ノード マネージャ クライアントをホストするマシンごとに、次の手順を行います。
![]() ![]() ![]() |