ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド
11g リリース1 (10.3.6)
B60998-04
  目次へ移動
目次

前
 
次
 

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

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

概要

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

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

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

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


注意:

UNIXプラットフォームでは、ノード・マネージャをルート・ユーザーとして実行しないでください。

例:

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

ステップ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


    注意:

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

  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マシンの構成

管理コンソールを使用して、管理サーバーまたは管理対象サーバーをホストする各マシン(バックアップ・マシンも含む)に新しい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_103/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です。この設定は、以下の方法でオーバーライドできます。

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

サーバーの移行などのタスクを実行するには、wlscontrol.shなどのスクリプトを実行するユーザーIDに十分なセキュリティ・許可が必要です。たとえば、ネットワーク・インタフェースを通じてIPアドレスをオンラインにしたり、オフラインにしたりできる許可などです。

サーバーの移行は、サーバーに障害が発生したことを検出したときに、クラスタ・マスターによって実行されます。クラスタ・マスターはSSHを使用してターゲット・マシンにあるスクリプトを起動し、移行を開始します。ターゲット・マシンにあるスクリプトは、クラスタのマスター上でサーバーを実行しているのと同じユーザーIDで実行されます。

サーバーの移行を実行するために必要なコマンドはwlsifconfigarpingです。これらのスクリプトには高度なOS権限が必要になるため、セキュリティ・ホールの可能性を防止できる点に留意することが重要です。sudoを使用すると、高度な権限によるwlsifconfigarpingの実行のみを許可するようにSSHを構成できます。

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

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

ノード・マネージャによって起動されたサーバー・インスタンスでは、自動再起動に使用するために、サーバーの起動に使用された資格証明が暗号化され、サーバー固有の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ファイルに公開鍵を追加します。