ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド
11gリリース2 (11.1.2.2.0)
B71694-10
  目次へ移動
目次

前
 
次
 

14 エンタープライズ・デプロイメントのスケーリング

このガイドで取り上げている参照エンタープライズ・トポロジはスケーラビリティが高くなっています。スケール・アップもスケール・アウトも可能です。この章では、その方法を説明します。

トポロジをスケール・アップするには、すでに1つ以上のコンポーネント・インスタンスを実行しているノードに、新しいコンポーネント・インスタンスを追加します。トポロジをスケール・アウトするには、新しいノードに新しいコンポーネント・インスタンスを追加します。

この章の内容は次のとおりです。

14.1 トポロジのスケーリング

このガイドで説明しているOracle Identity and Access Managementトポロジには、ディレクトリ層、アプリケーション層およびWeb層の3つの層があります。このガイドで説明しているOracle Identity and Access Managementトポロジの3つすべての層内のコンポーネントは、スケール・アップまたはスケール・アウトが可能です。

このリリースでは、Identity and Access Managementデプロイメント・ツールを使用してコンポーネントをスケール・アウトまたはスケール・アップすることはできません。この章で説明するように、スケール・アップまたはスケール・アウトは手動の処理になります。

トポロジのスケールアップは、すでに1つ以上のサーバー・インスタンスが実行しているノードに、新しいサーバー・インスタンスを追加して実行します。トポロジのスケール・アウトは、新しいノードに新しいコンポーネントを追加して実行します。

14.2 LDAPディレクトリのスケーリング

LDAPディレクトリは次のようにスケーリングします。

14.2.1 スケール・アウト時のMiddlewareホームのマウント

OracleバイナリはLDAPホスト間で共有されます。スケール・アウト時、新しいホストに共有バイナリ・ディレクトリをマウントする必要があります。これを行うには、第5.7項「共有記憶域のホストへのマウント」の手順を実行してください。

14.2.2 Oracle Unified Directoryのスケーリング

Oracle Unified DirectoryのバイナリはIDM_TOPにあり、これはLDAPHOST間で共有されています。Oracle Unified Directoryを新しいホストにスケール・アウトする際、このディレクトリが新しいホストにマウントされていることを確認します。第5.7項「共有記憶域のホストへのマウント」を参照してください。

ディレクトリ層には2つのOracle Unified Directoryノード(LDAPHOST1とLDAPHOST2)があり、それぞれでOracle Unified Directoryインスタンスを実行しています。いずれかのノードのOracle Unified Directoryバイナリを使用して、Oracle Unified Directoryの新しいインスタンスを作成できます。

次のようにします。

  1. 第14.2.2.1項「Oracle Unified Directoryをスケーリングするための情報収集」に示されるように情報を収集します。

  2. スケール・アウトの場合、共有記憶域を新しいLDAPHOSTにマウントします。

  3. 第14.2.2.2項「追加のOracle Unified Directoryインスタンスの構成」の手順に従います。

  4. 第14.2.2.3項「新しいOracle Unified Directoryインスタンスの検証」の手順に従います。

  5. 第14.2.2.4項「新しいOracle Unified Directoryインスタンスのロード・バランサへの追加」の手順に従います。

  6. 第14.4.5項「ロード・バランサの再構成」に記載されているように、新しいOracle Unified Directoryインスタンスのホストおよびポートの情報を使用して、ロード・バランサを再構成します。

14.2.2.1 Oracle Unified Directoryをスケーリングするための情報収集

Oracle Unified Directoryをスケーリングする前に次の情報を収集します。

説明 変数 ドキュメント内での値 実際の値

新しいOracle Unified Directoryのホスト名

LDAP_HOST

LDAPHOST3.mycompany.com


Oracle Unified Directoryのリスニング・ポート

LDAP_PORT

1389


Oracle Unified DirectoryのSSLポート

LDAP_SSL_PORT

1636


Oracle Unified Directory管理ポート

LDAP_ADMIN_PORT

4444


Oracle Unified Directoryのレプリケーション・ポート

LDAP_REPLIC_PORT

8989


Oracleインスタンスの場所

OUD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oudn


Oracle Unified Directoryの既存のインスタンス/コンポーネント名

oudn

oud1


新しく作成されたインスタンス/コンポーネント名

oudn

oud3


Oracle Unified Directoryの管理者パスワード

COMMON_IDM_PASSWORD



共通のパスワード

COMMON_IDM_PASSWORD




14.2.2.2 追加のOracle Unified Directoryインスタンスの構成

別のマシンにスケール・アウトする場合、ポート1389 (LDAP_PORT)、1636 (LDAP_SSL_PORT)、4444 (LDAP_ADMIN_PORT)および8989を使用できます。スケール・アップする場合には、これらのポートはすでに使用されており、一意のポートを選択する必要があります。使用しているオペレーティング・システムに対して次のコマンドを発行して、使用を計画しているポートがコンピュータ上の他のサービスに使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても出力は何も返されません。

netstat -an | grep "1389"

ポートが使用されている(コマンドからどちらかのポートを識別する出力が返された)場合は、ポートを解放する必要があります。

解放したポートのエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

環境変数JAVA_HOMEを設定します

環境変数INSTANCE_NAME../../../../u02/private/oracle/config/instances/oud3などの新しいインスタンス値に設定します。

ツールはインスタンス・ホームをOUD_ORACLE_HOMEを基準にして作成するため、前のディレクトリを含めてOUD_ORACLE_INSTANCEで作成したインスタンスを取得する必要があります。

ディレクトリをOUD_ORACLE_HOMEに変更します

次のコマンドを実行してOracle Unified Directory構成アシスタントを起動します。

./oud-setup
  1. 「ようこそ」画面で、「次へ」をクリックします。

  2. 「サーバー設定」画面で、次を入力します。

    • ホスト名: Oracle Unified Directoryが実行されているホストの名前(たとえばLDAPHOST3)

    • LDAPリスナー・ポート: スケール・アウトの場合1389 (LDAP_PORT)、スケール・アップの場合一意のポート。

    • 管理コネクタ・ポート: 4444 (LDAP_ADMIN_PORT)

    • LDAPセキュア・アクセス

      • 「構成」をクリックします

      • 「SSLアクセス」を選択します

      • ポートでSSLを有効化: 1636 (LDAP_SSL_PORT)

      • 証明書: 自己署名証明書を生成するまたは独自の証明書の詳細を提供します。

      • 「OK」をクリックします。

    • ルート・ユーザーDN: 管理ユーザーを入力します(たとえば、cn=oudadmin)

    • パスワード: ouadminユーザーに割り当てるパスワードを入力します。COMMON_IDM_PASSWORDを使用することをお薦めします。

    • パスワード(確認): パスワードを再入力します。

    • 「次へ」をクリックします。

  3. トポロジ・オプション画面で、次を入力します。

    • このサーバーは、レプリケーション・トポロジの一部になります

    • レプリケーション・ポート: (LDAP_REPLIC_PORT) 8989

    • レプリケーション・トラフィックを暗号化する場合には、「セキュアとして構成する」を選択します。

    • トポロジにはすでにサーバーがあります: 選択済。

      次の内容を入力します。

      • ホスト名: このインスタンス用のOracle Unified Directoryサーバー・ホストの名前(たとえばLDAPHOST1.mycompany.com)

      • 管理者コネクタ・ポート: 4444 (LDAP_ADMIN_PORT)

      • 管理ユーザー: LDAPHOST1のOracle Unified Directory管理ユーザーの名前(たとえば、cn=oudadmin)

      • 管理者パスワード: 管理者パスワード。COMMON_IDM_PASSWORDを使用することをお薦めします。

      「次へ」をクリックします。

      信頼されていない証明書ダイアログが表示される場合、これは自己署名証明書を使用しているためです。「永久受入れ」をクリックします。

    「次へ」をクリックします。

  4. グローバル管理者の作成画面で、次を入力します。

    • グローバル管理者ID: Oracle Unified Directoryレプリケーションを管理するために使用するアカウントの名前(たとえば、oudmanager)

    • グローバル管理者パスワード / 確認: このアカウントのパスワードを入力します。COMMON_IDM_PASSWORDを使用することをお薦めします。

    「次へ」をクリックします。

  5. データ・レプリケーション画面で、dc=mycompany,dc=comを選択し、「次へ」をクリックします。

  6. Oracleコンポーネントの統合画面で、「次へ」をクリックします。

  7. ランタイム・オプション画面で、「次へ」をクリックします。

  8. 「確認」画面で、表示された情報が正しいことを確認し、「終了」をクリックします。

  9. 「終了」画面で、「閉じる」をクリックします。

14.2.2.3 新しいOracle Unified Directoryインスタンスの検証

構成後、単純検索を実行することによってOracle Unified Directoryが動作することを検証できます。これを実行するには、次のコマンドを発行します。

OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h LDAPHOST3.mycompany.com -p 1389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl

Oracle Unified Directoryが正常に動作している場合、リストsupportedControlエントリが返されます。

14.2.2.4 新しいOracle Unified Directoryインスタンスのロード・バランサへの追加

新しいOracle Unified Directoryインスタンスを、インスタンス間でリクエストを分散するためにロード・バランサで定義された既存のサーバー・プールに追加します。

14.3 Identity and Access Managementアプリケーションのスケーリング

アプリケーション層にはOracle Access Management Access Manager用の管理対象サーバーを実行する2つのノード(OAMHOST1およびOAMHOST2)と、Oracle Identity Managerの管理対象サーバーを実行する2つのノード(OIMHOST1およびOIMHOST2)があります。オプションで、アプリケーション層にはOracle Adaptive Access Managerの管理対象サーバーを実行する2つのノード(OAMHOST1およびOAMHOST2)がある場合もあります。

この項には次のトピックが含まれます:

14.3.1 情報の収集

次の表を使用して、必要な値を収集します。

14.3.1.1 Access Managerのスケーリングのための情報収集

Access Managerをスケーリングする前に次の情報を収集します。

説明 変数 ドキュメント内での値 実際の値

ホスト名

NEWHOSTn



既存のAccess Managerサーバー


WLS_OAM1


新しいAccess Managerのサーバー名

WLS_OAMn

WLS_OAM3


サーバー・リスニング・ポート

OAM_PORT

14100


WebLogic管理ホスト

WLS_ADMIN_HOST

IADADMINVHN.mycompany.com


WebLogic管理ポート

IAD_WLS_PORT

7001


WebLogic管理ユーザー


weblogic_idm


WebLogic管理パスワード





14.3.1.2 Oracle Identity Managerのスケーリングのための情報収集

説明 変数 ドキュメント内での値 実際の値

ホスト名

NEWHOSTn



SOAの仮想サーバー名


SOAHOSTxVHN


Oracle Identity Managerの仮想サーバー名


OIMHOSTxVHN


クローニングする既存のSOA管理対象サーバー

WLS_SOAn

WLS_SOA1


クローニングする既存のOracle Identity Manager管理対象サーバー

WLS_OIMn

WLS_OIM1


新しいSOA管理対象サーバー名

WLS_SOAn

WLS_SOA3


新しいOracle Identity Manager管理対象サーバー名

WLS_OIMn

WLS_OIM3


新しいJMSサーバー用の数値拡張

n

3


WebLogic管理ホスト

WLS_ADMIN_HOST

IGDADMINVHN.mycompany.com


WebLogic管理ポート

WLS_ADMIN_PORT

7101


WebLogic管理ユーザー


weblogic_idm


WebLogic管理パスワード





14.3.1.3 Oracle Adaptive Access Managerのスケーリングのための情報収集

Oracle Adaptive Access Managerをスケーリングする前に次の情報を収集します。

説明 変数 ドキュメント内での値 実際の値

ホスト名

NEWHOSTn



既存のOAAMサーバー


WLS_OAAM1


新しいOAAMのサーバー名

WLS_OAAMn

WLS_OAAM3


サーバー・リスニング・アドレス




OAAM管理対象サーバーのポート

OAAM_PORT

14200


OAAM管理サーバーのポート

OAAM_ADMIN_PORT

14300


WebLogic管理ホスト

WLS_ADMIN_HOST

IADADMINVHN.mycompany.com脚注 1 


WebLogic管理ポート

WLS_ADMIN_PORT

7001


WebLogic管理ユーザー


weblogic_idm


WebLogic管理パスワード





脚注 1 これはスケーリングするドメインのことです。

14.3.2 スケール・アウト時のMiddlewareホームのマウントと新しいマシンの作成

OAMアプリケーション層のコンポーネントをスケール・アウトする前に、Middlewareホームをマウントして、新しいマシンを作成します。

Middlewareホームをマウントして新しいマシンを作成する手順:

  1. 新しいノードで、Oracle Fusion Middlewareのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできるようにします。詳細は、第5.7項「共有記憶域のホストへのマウント」を参照してください。

  2. 共有記憶域内のIAD_ORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

    cd IAD_ORACLE_HOME/oui/bin
    ./attachHome.sh -jreLoc JAVA_HOME
    

    注意:

    この項では、例としてIAD_ORACLE_HOMEを使用します。同じ手順をIGD_ORACLE_HOMEに使用します。


  3. Middlewareホーム・リストを更新するには、HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、IAD_MW_HOME/oui/binをこのファイルに追加します。

  4. 第15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、IAMAccessDomainのWebLogic管理コンソールにログインします。

  5. 使用する新しいノード用の新しいマシンを作成して、そのマシンを次のようにドメインに追加します。

    1. 「ナビゲーション」メニューから「環境」→「マシン」を選択します。

    2. 「ロックして編集」をクリックします。

    3. 「マシン・サマリー」画面で「新規」をクリックします。

    4. 次の情報を入力します。

      名前: マシンの名前(NEWHOSTn)

      マシンのOS: UNIXを選択します。

    5. 「次へ」をクリックします。

    6. 「ノード・マネージャのプロパティ」ページで、次の情報を入力します。

      タイプ: SSL。

      リスニング・アドレス: NEWHOSTn.

    7. 「終了」をクリックします。

    8. 「変更のアクティブ化」をクリックします。

14.3.3 スケール・アウト時の新しいノード・マネージャの作成

新しいホスト上のWebLogic管理対象サーバーを起動および停止するにはノード・マネージャを使用します。新しいホスト用の新しいノード・マネージャを作成するには次の手順を実行します。

  1. 新しいノード・マネージャ用の新しいディレクトリを既存のものをコピーして作成します。ディレクトリSHARED_CONFIG/nodemanager/oamhost1.mycompany.comSHARED_CONFIG/nodemanager/newiamhost.mycompany.comにコピーします。

    例:

    cp -r $SHARED_CONFIG/nodemanager/oamhost1.mycompany.com $SHARED_CONFIG/nodemanager/newiamhost.mycompany.com
    
  2. ディレクトリを新しく作成したディレクトリに変更します。

    cd SHARED_CONFIG/nodemanager/NEWHOST3.mycompany.com
    
  3. nodemanager.propertiesファイルを、OAMHOST1に対するエントリをすべてOAMHOST3に変更するよう編集します。次に例を示します。

    DomainsFile=/u01/oracle/config/nodemanager/OAMHOST1.mycompany.com/nodemanager.domain
    

    は次のようになります。

    DomainsFile=/u01/oracle/config/nodemanager/NEWHOST3.mycompany.com/nodemanager.domain
    
  4. startNodeManagerWrapper.shファイルを、OAMHOST1に対するエントリをすべてOAMHOST3に変更するよう編集します。たとえば、

    NM_HOME=/u01/oracle/config/nodemanager/oamhost1.mycompany.com
    

    は次のようになります。

    NM_HOME=/u01/oracle/config/nodemanager/oamhost3.mycompany.com
    
  5. 次のコマンドを実行してノード・マネージャを起動します。

    ./startNodeManagerWrapper.sh
    
  6. 第14.5.3項「ノード・マネージャ構成の更新」の手順に従ってノード・マネージャ構成を更新し、新しいホスト用の証明書が作成されるようにします。

14.3.4圧縮/解凍の実行

ドメインを新しい管理対象サーバーを含むように拡張するときには常に、ドメイン構成で必要になるものをASERVER_HOMEの場所からMSERVER_HOMEの場所へ抽出する必要があります。これは、スケール・アップおよびスケール・アウトのいずれにも適用されます。これを行うには、次の手順を実行します。


注意:

次の手順は、IAMAccessDomainの圧縮および解凍の例です。


  1. 管理サーバーのあるホスト上でドメインを圧縮します(たとえば、OAMHOST1では次のようにします)。

    pack.sh -domain=IAD_ASERVER_HOME -template =/templates/managedServer.jar -template_name="template_name" -managed=true
    

    pack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。

  2. 次のコマンドを使用して、スケール・アウトの場合は新しいホスト上で、スケール・アップの場合は既存のホスト上でドメインを解凍します。

    unpack.sh -domain=IAD_MSERVER_HOME -template=/templates/managedServer.jar -app_dir=IAD_MSERVER_HOME/applications
    

    unpack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。

  3. スケール・アウトする場合、ノード・マネージャを起動して、プロパティ・ファイルを更新します。

    1. 第15.1項「コンポーネントの起動と停止」の説明に従い、ノード・マネージャを起動および停止します。

    2. ORACLE_COMMON_HOME/common/binにあるスクリプトsetNMProps.shを実行して、ノード・マネージャのプロパティ・ファイルを更新します。たとえば、次のように指定します。

      cd ORACLE_COMMON_HOME/common/bin
      ./setNMProps.sh
      
    3. 第15.1項「コンポーネントの起動と停止」の説明に従い、ノード・マネージャをもう一度起動します。

14.3.5 アプリケーション固有の手順の実行

この項には次のトピックが含まれます:

14.3.5.1 既存の管理対象サーバーのクローンの作成

同じタイプの既存の管理対象サーバーをクローニングして新規管理対象サーバーを作成できます。Access Managerをスケール・アウト/アップするには、wls_oam1をクローニングします。同様に、Identity Managerをスケール・アウト/アップするには、wls_oim1をクローニングします。

次の例はAccess Managerの管理対象サーバーのクローニングの例ですが、手順はすべての製品で同じです。

  1. 15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、クローニングする管理対象サーバーのドメイン用のOracle WebLogic管理コンソールにログインします。この例では、ドメインはIAMAccessDomainです。

  2. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーのサマリー」ページが表示されます。

  3. 「チェンジ・センター」メニューで「ロックして編集」をクリックします。

  4. 拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1)。

  5. 「クローンの作成」をクリックします。

  6. 次の情報を入力します。

    • サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。

    • サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。

    • サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。

      スケール・アウトする場合、デフォルトのポート14100 (表7–1のOAM_PORT)を使用できます。スケール・アップする場合には、一意のポートを選択します。

  7. 「OK」をクリックします。

  8. 新しく作成したサーバーWLS_OAM3をクリックします。

  9. 「マシン」第14.3.2項「スケール・アウト時のMiddlewareホームのマウントと新しいマシンの作成」で作成したマシンになるように設定します。

  10. 「保存」をクリックします。

  11. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとNEWHOST内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。

    新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名検証を無効にする手順は次のとおりです。

    1. Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。

    2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

    3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。

    5. 「SSL」タブをクリックします。

    6. 「詳細」をクリックします。

    7. 「ホスト名の検証」を「なし」に設定します。

    8. 「保存」をクリックします。

  12. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

14.3.5.2 Oracle Access Management Access Managerのスケーリング

この項では、Access Manager固有のスケーリング手順について説明します。


注意:

共有記憶域を使用している場合は、その共有記憶域に新しいホストがアクセスできるようにします。


次の各項の手順を実行して、Oracle Access Management Access Managerをスケーリングします。

14.3.5.2.1 圧縮/解凍の実行

第 15.3.4項「圧縮/解凍の実行」で説明されているようにpackおよびunpackを実行します。

14.3.5.2.2 Oracle Access Management Access Managerへの管理対象サーバーの登録

Oracle Access Management Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをAccess Managerサーバーとして構成する必要があります。これはOracle Access Managementコンソールから行います。次のようにします。

  1. 8.9項「ユーザー名およびパスワードの設定」のエントリで特定されたユーザーとして、http://IADADMIN.mycompany.com/oamconsoleにあるAccess Managementコンソールにログインします。

  2. 「システム構成」タブをクリックします。

  3. 「サーバー・インスタンス」をクリックします。

  4. 「アクション」メニューから「作成」を選択します。

  5. 次の情報を入力します。

    • サーバー名: WLS_OAM3

    • ホスト: サーバーを実行するホスト。

    • ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。

    • OAMプロキシ・ポート: Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。

    • プロキシ・サーバーID: AccessServerConfigProxy

    • モード: 既存のAccess Managerサーバーと同じモードに設定します。

  6. 「コヒーレンス」タブをクリックします。

    「ローカル・ポート」をそのホストで一意の値に設定します。

  7. 「適用」をクリックします。

  8. 第15.1項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを再起動します。

14.3.5.2.3 Webゲート・プロファイルの更新

新しく作成したAccess Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDMWebgate_IDM_11gIAMSuiteAgentなど)にそのサーバーを追加します。

たとえば、Webgate_IDMにAccess Managerサーバーを追加するには、http://IADADMIN.mycompany.com/oamconsoleにあるAccess Managementコンソールにアクセスします。

次の手順を実行します。

  1. Access Manager管理ユーザーとしてログインします。

  2. 「システム構成」タブをクリックします。

  3. 「Access Managerの設定」「SSOエージェント」「OAMエージェント」を開きます。

  4. フォルダを開くアイコンをクリックして「検索」をクリックします。

    Webゲート・エージェントWebgate_IDMが表示されます。

  5. エージェントWebgate_IDMをクリックします。

  6. 「アクション」メニューから「編集」を選択します。

  7. 「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」をクリックします。

  8. 「サーバー」リストから、新しく作成した管理対象サーバーを選択します。

  9. 「接続の最大数」10に設定します。

  10. 「適用」をクリックします。

Webgate_IDM_11gIAMSuiteAgentおよび使用している可能性のあるその他すべてのWebゲートで、手順5から10を繰り返します。

これで第15.1項「コンポーネントの起動と停止」の手順に従い、新しい管理対象サーバーを起動できるようになります。

14.3.5.2.4 Web層の更新

第14.3.6項「Oracle HTTP Server構成ファイルへの新しいWebLogic管理対象サーバーの追加」で説明されているように、新しく追加された管理対象サーバーのホスト名およびポートをWebLogicClusterパラメータのリストに追加します。

このファイルを保存し、第15.1項「コンポーネントの起動と停止」の説明に従ってOracle HTTP Serverを再起動します。

14.3.5.3 Oracle Identity Managerのスケーリング

Oracle SOA SuiteおよびOracle Identity Managerのコンポーネントを使用して構成された管理対象サーバーを実行するノードがすでにあります。このノードには、Middlewareホーム、SOA Oracleホーム、Oracle Identity Manager Oracleホーム、および既存の管理対象サーバーのドメイン・ディレクトリが含まれています。新しい管理対象サーバーWLS_SOAおよびWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にOracle Identity and Access ManagementまたはOracle SOA Suiteバイナリをインストールする必要はありません。

スケール・アップする場合、既存のノードに管理対象サーバーWLS_SOAおよびWLS_OIMを追加します。

いずれの場合にも、圧縮と解凍を実行する必要があります。

トポロジをスケール・アウトする際は、Oracle Identity ManagerおよびSOAを使用して構成された新しい管理対象サーバーを新しいノードに追加します。まず、新しいノードがWebLogic Server、Oracle Identity ManagerおよびSOAの既存のホーム・ディレクトリにアクセスできることを確認します。圧縮および解凍を実行して、新しいノードでドメイン構成をブートストラップする必要はありません。

トポロジをスケーリングするには、次の各項の手順を実行してください。

14.3.5.3.1 新しいJMSサーバーの構成

新しい管理対象サーバー上に、SOA、Oracle Identity Manager、UMSおよびBPMそれぞれのJMSサーバーを作成します。この操作は次のように実行します。

  1. 第15.2項「Identity ManagementコンソールのURLについて」に記載されているように、IAMGovernanceDomainのWebLogic管理サーバーにログインし、「サービス」→「メッセージング」→「JMSサーバー」の順に移動します。

  2. 「新規」をクリックします。

  3. 「名前」に、BPMJMSServer_auto_3などの値を入力します。

  4. 「新規ストアの作成」をクリックします。

  5. リストからFileStoreを選択します。

  6. 「次へ」をクリックします。

  7. 「名前」に、BPMJMSFileStore_auto_3などの値を入力します。

  8. 次の値を入力します。

    ターゲット: 現在作成している新しいサーバー。

    ディレクトリ: IGD_ASERVER_HOME/jms/BPMJMSFileStore_auto_3

  9. 「OK」をクリックします。

  10. 「JMSサーバー」画面に戻り、新しく作成したファイル・ストアをリストから選択します。

  11. 「次へ」をクリックします。

  12. 次の画面で、「ターゲット」を作成しているサーバーに設定します。

  13. 「終了」をクリックします。

作成する管理対象サーバーに応じて、次のJMSキューを作成します。

サーバー JMSサーバー名 ファイル・ストア名 ディレクトリ ターゲット

WLS_SOAn

BPMJMSServer_auto_n

BPMJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/BPMJMSFileStore_auto_n

WLS_SOAn

WLS_SOAn

SOAJMSServer_auto_n

SOAJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/SOAJMSFileStore_auto_n

WLS_SOAn

WLS_SOAn

UMSJMSServer_auto_n

UMSJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/UMSJMSFileStore_auto_n

WLS_SOAn

WLS_OIMn

JRFWSAsyncJmsServer_auto_n

JRFWSAsyncFileStore_auto_n

IGD_ASERVER_HOME/jms/RFWSAsyncFileStore_auto_n

WLS_OIMn

WLS_OIMn

OIMJMSServer_auto_n

OIMJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/OIMJMSFileStore_auto_n

wls_OIMn

WLS_SOAn

PS6SOAJMSServer_auto_n

PS6SOAJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/PS6SOAJMSFileStore_auto_n

wls_SOAn


次の手順を実行して、新しく作成したJMSキューを既存のJMSモジュールに追加します。

  1. 第15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、IAMGovernanceDomainのWebLogic管理コンソールにログインします。

  2. 「サービス」→「メッセージング」→「JMSモジュール」に移動します。

  3. SOAJMSModuleなどのJMSモジュールをクリックします。

  4. 「サブデプロイメント」タブをクリックします。

  5. 表示されたサブ・デプロイメントをクリックします。


    注意:

    このサブデプロイメント・モジュール名は、JMSServerNameXXXXXXという形式のランダムな名前で、構成ウィザードJMS構成から生成されます。


  6. 新しく作成したJMSサーバーを割り当てます(SOAJMSServer_autonなど)。

  7. 「保存」をクリックします。

  8. これを、次の表に記載されている各JMSモジュールに対して実行します。

    JMSモジュール JMSサーバー

    BPMJMSModule

    BPMJMSServer_auto_n

    JRFWSAsyncJmsModule

    JRFWSAsyncJmServer_auto_n

    OIMJMSModule

    OIMJMSServer_auto_n

    SOAJMSModule

    SOAJMSServer_auto_n

    UMSJMSSystemResource

    UMSJMSServe_auto_n


  9. 構成のアクティブ化を「チェンジ・センター」メニューでクリックします。

14.3.5.3.2 スケール・アウト時の圧縮/解凍の実行

この項は、スケール・アウトを行う際のみ必要になります。

第14.3.4項「圧縮/解凍の実行」で説明されているようにpackおよびunpackを実行します。

14.3.5.3.3 コンポジットのデプロイでのOracle Coherenceの構成

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。

ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。


注意:

デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。


14.3.5.3.4 ユニキャスト通信を使用したデプロイメントの通信の有効化

tangosol.coherence.wkanシステム・プロパティを使用してノードを指定します(nは1から9の番号)。最大9つのノードを指定できます。番号は、1から開始します。連続した番号を指定する必要があり、途切れていてはなりません。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(例:SOAHOST3VHN)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します。また、既存のエントリに新しいサーバーを追加する必要もあります。


ヒント:

SOAコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。



注意:

SOAHOST3VHNは、SOAHOST3でWLS_SOA3がリスニングする仮想IPにマップされる仮想ホスト名です。


14.3.5.3.5 Oracle Coherenceで使用するホスト名の指定

管理コンソールを使用して、Oracle Coherenceで使用するホスト名を指定します。

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールにログインします。

  2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

  3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  4. 表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの設定ページが表示されます。

  5. 「ロックして編集」をクリックします。

  6. 「サーバーの起動」タブをクリックします。

  7. 「引数」フィールドで、WLS_SOA1、WLS_SOA2およびWLS_SOA3について次のように入力します。

    WLS_SOA1については次の値を入力します。

    -Dtangosol.coherence.wka1=SOAHOST1VHN
    -Dtangosol.coherence.wka2=SOAHOST2VHN
    -Dtangosol.coherence.wka3=SOAHOST3VHN
    -Dtangosol.coherence.localhost=SOAHOST1VHN
    

    WLS_SOA2については次の値を入力します。

    -Dtangosol.coherence.wka1=SOAHOST1VHN
    -Dtangosol.coherence.wka2=SOAHOST2VHN
    -Dtangosol.coherence.wka3=SOAHOST3VHN
    -Dtangosol.coherence.localhost=SOAHOST2VHN
    

    WLS_SOA3については次の値を入力します。

    -Dtangosol.coherence.wka1=SOAHOST1VHN
    -Dtangosol.coherence.wka2=SOAHOST2VHN
    -Dtangosol.coherence.wka3=SOAHOST3VHN
    -Dtangosol.coherence.localhost=SOAHOST3VHN
    

    注意:

    異なる-Dパラメータの間には、空白の行を入れないでください。管理コンソールの引数テキスト・フィールドに、このテキストをコピーまたは貼り付けないでください。Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。



    注意:

    デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。たとえば、次のようにします。

    WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

    -Dtangosol.coherence.wka1=SOAHOST1VHN
    -Dtangosol.coherence.wka2=SOAHOST2VHN
    -Dtangosol.coherence.wka3=SOAHOST3VHN
    -Dtangosol.coherence.localhost=SOAHOST1VHN
    -Dtangosol.coherence.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    -Dtangosol.coherence.wka3.port=8089
    

    WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

    -Dtangosol.coherence.wka1=SOAHOST1VHN
    -Dtangosol.coherence.wka2=SOAHOST2VHN
    -Dtangosol.coherence.wka3=SOAHOST3VHN
    -Dtangosol.coherence.localhost=SOAHOST2VHN
    -Dtangosol.coherence.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    -Dtangosol.coherence.wka3.port=8089
    

    WLS_SOA3(「引数」フィールドに、改行なしで1行で次のように入力):

    -Dtangosol.coherence.wka1=SOAHOST1VHN
    -Dtangosol.coherence.wka2=SOAHOST2VHN
    -Dtangosol.coherence.wka3=SOAHOST3VHN
    -Dtangosol.coherence.localhost=SOAHOST3VHN
    -Dtangosol.coherence.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    -Dtangosol.coherence.wka3.port=8089
    

    Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。


  8. 「保存」「変更のアクティブ化」をクリックします。


注意:

これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります。(これらの変数はサーバーの出力ログに記録されます。)Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。



注意:

マルチキャスト・アドレスとユニキャスト・アドレスは、クラスタ通信においてWebLogic Serverクラスタで使用するアドレスとは異なります。2つのエンティティ(コンポジットの配置先となるグループとWebLogic Serverクラスタ)における通信プロトコルが異なっていても、1つのWebLogic Serverクラスタに属するメンバーにコンポジットが配置されることがSOAで保証されます。


14.3.5.3.6 Oracle Identity Manager構成手順の完了
  1. 新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。

    WebLogic管理コンソールで、「Server_name」「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

  2. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。OIMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間の通信用のサーバー証明書を構成した後で、これを再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。

    ホスト名検証を無効にする手順は次のとおりです。

    1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

    2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

    3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。

    5. 「SSL」タブをクリックします。

    6. 「詳細」をクリックします。

    7. 「ホスト名の検証」を「なし」に設定します。

    8. 「保存」をクリックします。

  3. WLS_OIMnの各管理対象サーバーでも、手順6a - 6hを繰り返してホスト名検証を無効にします。手順6dでは、表の「名前」列で「WLS_OIMn」を選択します。

  4. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

  5. 第15.1項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを再起動します。

  6. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

    1. クラスタ内の既存の管理対象サーバーを停止します。

    2. 新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。

    3. 新しく作成した管理対象サーバー(http://vip:port/soa-infra)上のアプリケーションにアクセスします。アプリケーションが機能している必要があります。

  7. 新しく作成した管理対象サーバーを、サーバー移行ができるように構成します。第13.6項「サーバー移行ターゲットの構成」の手順に従って、サーバー移行を構成します。


    注意:

    この新しいノードでは既存の共有記憶域のインストール内容が使用されているため、このノードではすでにノード・マネージャが使用されているとともに、ネットマスク、インタフェースおよびwlsifconfigスクリプトのスーパーユーザー権限が含まれたサーバー移行向けに構成された環境が使用されています。新しいノードには、すでに新しい管理対象サーバーの浮動IPアドレスが存在します。


  8. この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。

    1. 管理対象サーバーWLS_SOAnを停止します。

      このためには、次のコマンドを実行します。

      kill -9 pid
      

      このコマンドでは、その管理対象サーバーのプロセスID (PID)を指定します。ノードのPIDを確認するには、次のコマンドを使用します。

       ps -ef | grep WLS_SOAn
      
    2. ノード・マネージャのコンソールを確認します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。

    3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

    4. ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

    5. WLS_OIMnに対し、aからdの手順を繰り返します。

14.3.5.4 Oracle Adaptive Access Managerの統合の更新

Oracle Adaptive Access Managerでドメインを拡張し、Oracle Identity ManagerをOracle Adaptive Access Managerと統合している場合、Oracle Adaptive Access Managerを新しいOracle Identity Managerサーバーを認識するように更新する必要があります。詳細は、第12.13.3項「Oracle Identity Manager用のOracle Adaptive Access Managerプロパティの設定」を参照してください。

14.3.6 Oracle HTTP Server構成ファイルへの新しいWebLogic管理対象サーバーの追加

アプリケーション層のコンポーネントのスケーリングでは、通常、新しいWebLogic管理対象サーバーを作成する必要があります。トポロジに新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。

Web層では、WEB_ORACLE_INSTANCE/config/OHS/componentname/moduleconfに、admin_vh.confsso_vh.confおよびidminternal_vh.confなどの構成ファイルがいくつかあります。それぞれに、ロケーション・ブロックのエントリが数多く含まれます。ブロックが2つのサーバー・インスタンスを参照しているときに3つ目を追加する場合、そのブロックを新しいサーバーを使用して更新する必要があります。

たとえば、新しいAccess Managerサーバーを追加する場合は、その新しい管理対象サーバーが含まれるようにsso_vh.confを更新する必要があります。新しいサーバーを、ファイル内のWebLogicClusterディレクティブに追加します。次に例を示します。

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100
</Location>
 
<Location /oamfed>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100
</Location>

を次のように変更します。

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100,OAMHOST1.mycompany.com:14101
</Location>
 
<Location /oamfed>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100,OAMHOST3.mycompany.com:14100
</Location>

構成ファイルを更新したら、第15.1項「コンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの停止を防止するため、再起動は順次的に行うことをお薦めします。

14.4 Web層のスケーリング

Web層には、Oracle HTTP Serverのインスタンスが実行されている1つのノードがすでにあります。既存のOracle HTTP Serverバイナリを使用して、新しいOracle HTTP Serverインスタンスを作成できます。

Oracle HTTP Serverをスケーリングするには、次の各項の手順を実行します。

14.4.1 Web層のスケーリング用の情報収集

Web層をスケーリングする前に次の情報を収集します。

説明 変数 ドキュメント内での値 実際の値

ホスト名


WEBHOST1.mycompany.com


OHSポート

WEB_HTTP_PORT

7777


インスタンス名

webn

web1またはweb2


コンポーネント名

webn

web1またはweb2


WebLogic管理ホスト、IAMAccessDomain

IADADMINVHN

IADADMINVHN.mycompany.com


Access Management WLSサーバー・ポート

IAD_WLS_PORT

7001


WebLogic管理ユーザー


weblogic_idm


WebLogic管理パスワード





14.4.2 スケール・アウト時のMiddlewareホームのマウントとOracle HTTP Serverファイルのコピー

新しいノードで、既存のMiddlewareホームをマウントします。

既存のWeb層構成のORACLE_INSTANCE/config/OHS/component/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。

14.4.3 構成ウィザードによるHTTP Serverの構成

次の手順を実行して、Oracle Web層を構成します。

  1. Oracle HTTP Serverが使用するポートを含むファイルを作成します。インストール・メディアのDisk1で、ファイルstage/Response/staticports.iniを探します。これをohs_ports.iniというファイルにコピーします。ohs_ports.iniからOHS PORTOPMN Local Portを除くすべてのエントリを削除します。OPMN Local Portの値を6700に変更します。スケール・アウトする場合、OHS PORTにデフォルト値7777を使用できます。スケール・アップする場合には、マシン上のインスタンスに対して一意の値を選択する必要があります。


    注意:

    ファイルのポート名がOHS PORTおよびOPMN Local Portと若干異なる場合、ファイルでこれらの名前を使用します。


  2. Oracle Fusion Middleware構成ウィザードの場所にディレクトリを変更します。

    cd WEB_ORACLE_HOME/bin
    
  3. 構成ウィザードを起動します。

    ./config.sh
    

構成ウィザードに次の情報を入力します。

  1. 「ようこそ」画面で、「次へ」をクリックします。

  2. 「コンポーネントの構成」画面で「Oracle HTTP Server」を選択します。

    「選択されたコンポーネントとWebLogicドメインの関連付け」が選択されていることを確認します。

    Oracle Web Cacheが選択されていないことを確認してください。

    「次へ」をクリックします。

  3. 「WebLogicドメインの指定」画面で、次を入力します。

    「次へ」をクリックします。

  4. 「コンポーネントの詳細の指定」画面で、次の値を指定します。

    WEBHOSTnに次の値を入力します。ここでnは、新しいホストの番号です(たとえば3など)。

    • インスタンス・ホームの場所: WEB_ORACLE_INSTANCE (例: /u02/local/oracle/config/instances/ohs1)

    • インスタンス名: webn

    • OHSコンポーネント名: webn

    「次へ」をクリックします。

  5. 「ポートの構成」画面で、手順1で作成したohs_ports.iniファイルを使用して、使用するポートを指定します。こうすることによって、自動ポート構成をバイパスできます。

    1. 構成ファイルを使用してポートを指定を選択します。

    2. 「ファイル名」フィールドでohs_ports.iniを指定します。

    3. 「保存」「次へ」をクリックします。

  6. セキュリティ更新の指定画面で、次の値を指定します。

    • 電子メール・アドレス: My Oracle Supportアカウント用の電子メール・アドレスです。

    • My Oracle Supportパスワード: My Oracle Supportアカウント用のパスワードです。

    「セキュリティ・アップデートをMy Oracle Support経由で受け取ります。」を選択します。

    「次へ」をクリックします。

  7. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。

    「構成」をクリックします。

    「構成」画面で、複数のConfiguration Assistantが起動されます。このプロセスは、時間がかかることがあります。終了したら、「次へ」をクリックします。

    「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

14.4.4 WebLogic ServerへのOracle HTTP Serverの登録

Oracle Enterprise Manager Fusion Middleware Controlで新しいOracle HTTP Serverを管理および監視できるようにするには、Oracle HTTP ServerをIAMAccessDomainに登録する必要があります。これを行うには、新しいサーバーが実行しているホスト上で次のコマンドを実行して、WebLogic ServerにOracle HTTP Serverを登録する必要があります。

cd WEB_ORACLE_INSTANCE/bin
./opmnctl registerinstance -adminHost IADADMINVHN.mycompany.com \
   -adminPort WLS_ADMIN_PORT -adminUsername weblogic

14.4.5 ロード・バランサの再構成

新しいOracle HTTP Serverインスタンスを、HTTPインスタンス間でリクエストを分散するためにロード・バランサで定義された既存のサーバー・プールに追加します。

14.5 すべてのコンポーネントのスケーリング後の手順

次のスケーリング後の手順を実行します。

14.5.1 トポロジ・ストアの更新

デプロイメント中に、デプロイされたトポロジの詳細が含まれるトポロジ・ストアが作成されます。環境にパッチ適用する際、ライフサイクル・ツールは、パッチ計画を作成して実行するためにストアを読み取ります。トポロジをスケール・アウトまたはスケール・アップする場合、デプロイメントへの新しい追加に対応するストアへ新しいエントリを追加する必要があります。

これを行うには、付録C「スケーリングのためのトポロジ・ツール・コマンド」の手順に従います。

14.5.2 起動/停止スクリプトの更新

デプロイメントでは、ドメインで定義された管理対象サーバーを起動および停止する一連のスクリプトが作成されます。ドメインに新しい管理対象サーバーを作成する際には、新しく作成された管理対象サーバーもこれらの起動および停止スクリプトで起動できるように、ドメイン構成を更新する必要があります。

ドメイン構成を更新するには、SHARED_CONFIG/scriptsディレクトリにあるserverInstancesCustom.txtファイルを編集します。

14.5.3 ノード・マネージャ構成の更新

次の各項の説明に従って、ノード・マネージャ構成を更新します。

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

新しいマシンでノード・マネージャを起動する場合には、次のようなエントリを追加します。

newmachine.mycompany.com NM nodemanager_pathname nodemanager_port

たとえば、次のようにします。

OAMHOST3.mycompany.com NM /u01/oracle/config/nodemanager/oamhost3.mycompany.com 5556

WLS_OIM3という管理対象サーバーを起動する場合には、次のようなエントリを追加します。

newmachine.mycompany.com OIM ManagedServerName

たとえば、次のようにします。

OAMHOST3 OIM WLS_OIM3

ファイルを保存します。

新しいノード・マネージャを追加した場合、第14.5.3.2項「エンタープライズ・デプロイメント用のノード・マネージャの設定」に従って、そのノードに対してSSLを有効にする必要があります。

14.5.3.2 エンタープライズ・デプロイメント用のノード・マネージャの設定

この項では、Oracleのベスト・プラクティスの推奨事項に従ってノード・マネージャを構成する方法を説明します。この項の内容は次のとおりです。

14.5.3.2.1 ノード・マネージャのホスト名検証証明書の有効化

この項では、ノード・マネージャと管理サーバーとの通信で使用するホスト名検証証明書を設定する方法について説明します。

14.5.3.2.2 utils.CertGenユーティリティを使用した自己署名証明書の作成

この章で(例として)追加する証明書は、ノード・マネージャが物理ホスト名(HOST.mycompany.com)でリスニングし、WebLogic管理対象サーバーが仮想ホスト名(VIP.mycompany.com)でリスニングする構成に対応します。サーバーが仮想ホスト名を使用している場合は、サーバーを1つのノードから別のノードに移行できることを意味します。したがって、キーストアおよびトラスト・キーストアを保持するディレクトリは、理想としては、フェイルオーバーが発生してもアクセス可能な共有記憶域に配置する必要があります。同じノードまたは別のノードで別のホスト名を使用する場合は、この例の手順を次のように拡張する必要があります。

  1. 証明書ストアに必要なホスト名を追加します(必要なホスト名がHOST.mycompany.comおよびVIP.mycompany.comと異なる場合)。

  2. アイデンティティ・ストアおよびトラスト・ストアの場所に関する情報を、ノード・マネージャ(ノード・マネージャで別のホスト名を使用する場合)またはサーバー(管理対象サーバーで別のホスト名を使用する場合)で変更します。

次の手順に従って、HOSTに自己署名証明書を作成します。これらの証明書はネットワーク名または別名を使用して作成する必要があります。かわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。次の例では、HOST.mycompany.comとVIP.mycompany.comの証明書を構成します。すなわち、HOSTで物理ホスト名(HOST)と仮想ホスト名(VIP)の両方を使用することを想定しています。また、HOST.mycompany.comはノード・マネージャが使用するアドレスであり、VIP.mycompany.comは管理対象サーバーまたは管理サーバーが使用するアドレスであることも想定しています。これは、管理サーバーとFusion Middlewareコンポーネントをホストするノードや、共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングし、もう一方が仮想ホスト名を使用(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。

  1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して、環境を設定します。Bourneシェルで、次のコマンドを実行します。

    cd WL_HOME/server/bin
    . ./setWLSEnv.sh
    

    CLASSPATH環境変数が設定されていることを確認します。

    echo $CLASSPATH
    
  2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、ASERVER_HOMEディレクトリにkeystoresという名前のディレクトリを作成します。証明書はWebLogicドメイン間で共有できることに注意してください。

    cd SHARED_CONFIG
    mkdir keystores
    

    注意:

    キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。各種目的(HTTPの起動用のSSL設定など)で使用する証明書には、中央ストアまたは共有ストアを使用することをお薦めします。


  3. ディレクトリを今しがた作成したディレクトリに変更します。

    cd keystores
    
  4. utils.CerGenツールを使用して、トポロジ内の各物理ホストおよび仮想ホストに対する証明書を作成します。

    構文(すべて1行に記述):

    java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name 
    [export | domestic] [Host_Name]

    次に例を示します。

    java utils.CertGen Key_Passphrase NEWHOST.mycompany.com_cert NEWHOST.mycompany.com_key domestic NEWHOST.mycompany.com
    

    また新しい仮想ホストに対しても証明書を作成します。

    java utils.CertGen Key_Passphrase NEWVHN.mycompany.com_cert NEWVHN.mycompany.com_key domestic NEWVHN.mycompany.com
    
14.5.3.2.3 utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成

新しいホストを追加する際には、次の手順を実行します。

  1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreというIDキーストアを新しく作成します。このキーストアの作成場所は、証明書と同じディレクトリ(ASERVER_HOME/keystores)とします。


    注意:

    アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。


  2. 先ほど作成した証明書のそれぞれに対する証明書および秘密鍵を、アイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

    構文(すべて1行に記述):

    java utils.ImportPrivateKey Keystore_File Keystore_Password 
    Certificate_Alias_to_Use Private_Key_Passphrase
    Certificate_File
    Private_Key_File

    [Keystore_Type]

    例:

    java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityNEWHOST Key_Passphrase SHARED_CONFIG/keystores/NEWHOST.mycompany.com_cert.pem SHARED_CONFIG/keystores/NEWHOST.mycompany.com_key.pem
    
14.5.3.2.4 keytoolユーティリティを使用したトラスト・キーストアの作成

次の手順に従って、各新しいホストに対する新しいキーストアを作成します。

  1. 新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書を、証明書が存在するディレクトリにコピーします。たとえば、次のようにします。

    cp WL_HOME/server/lib/cacerts SHARED_CONFIG/keystores/appTrustKeyStoreNEWHOST.jks
    
  2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。それには、keytoolユーティリティを使用します。構文は次のとおりです。

    keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password
    

    たとえば、次のようにします。

    keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStoreNEWHOST.jks -storepass changeit
    
  3. このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用します。これは、WL_HOME/server/libディレクトリにあります。keytoolユーティリティを使用して、このCA証明書をappTrustKeyStoreにインポートする必要があります。構文は次のとおりです。

    keytool -import -v -noprompt -trustcacerts -alias Alias_Name 
    -file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password

    たとえば、次のようにします。

    keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStoreNEWHOST.jks -storepass Key_Passphrase
    
14.5.3.2.5 カスタム・キーストアを使用するためのノード・マネージャの構成

新しいノード・マネージャを追加したら、それを第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」に記載の新しいカスタム・キーストアを使用するように構成する必要があります。カスタム・キーストアを使用するようにノード・マネージャを構成するには、SHARED_CONFIG/nodemanager/hostnameディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します(ここでhostnameは、ノード・マネージャが実行するホストの名前です)。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity_Keystore
CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password
CustomIdentityAlias=Identity_Keystore_Alias
CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate

たとえば、次のようにします。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=SHARED_CONFIG/keystores/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=Key_Passphrase
CustomIdentityAlias=appIdentityNEWHOST
CustomIdentityPrivateKeyPassPhrase=Key_Passphrase

第15.1項「コンポーネントの起動と停止」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。このファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

14.5.3.2.6 カスタム・キーストアを使用するための管理対象WebLogic Serverの構成

次の手順に従って、WLS_SERVERのIDキーストアとトラスト・キーストアを構成します。

  1. 第15.2項「Identity ManagementコンソールのURLについて」で指定されたアドレスで拡張されたドメイン用のOracle WebLogic Server管理コンソールにログインします。

  2. 「ロックして編集」をクリックします。

  3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  5. IDキーストアとトラスト・キーストアを構成するサーバー名(WLS_SERVER)をクリックします。選択したサーバーの設定ページが表示されます。

  6. 「構成」をクリックし、「キーストア」をクリックします。

  7. 「キーストア」フィールドで、秘密鍵とデジタル証明書の組合せおよび信頼できるCA証明書の格納と管理のために「カスタムIDとカスタム信頼」メソッドを選択します。

  8. 「ID」セクションで、IDキーストアの次の属性を定義します。

    • カスタムIDキーストア: IDキーストアへの完全修飾パス。

      SHARED_CONFIG/keystores/appIdentityKeyStore.jks
      
    • カスタムIDキーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

    • カスタムIDキーストアのパスフレーズ: 第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

  9. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

    • カスタム信頼キーストア: トラスト・キーストアへの完全修飾パス。

      SHARED_CONFIG/keystores/appTrustKeyStoreNEWHOST.jks
      
    • カスタム信頼キーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

    • カスタム信頼キーストアのパスフレーズ: 第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(New_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

  10. 「保存」をクリックします。

  11. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

  12. 「構成」をクリックし、「SSL」をクリックします。

  13. 「ロックして編集」をクリックします。

  14. 「秘密鍵の別名」フィールドに、管理対象サーバーでリスニングするホスト名に使用した別名を入力します(例:appIdentityNEWHOST)。

    「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第14.5.3.2.3項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。

  15. 「保存」をクリックします。

  16. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

  17. 第15.1項「コンポーネントの起動と停止」の説明に従って、変更を適用したサーバーを再起動します。

14.5.3.2.7 管理対象サーバーのホスト名検証設定の変更

前述の手順を実行した後、影響を受ける管理対象サーバーのホスト名検証をBea Hostname Verifierに設定します。これを行うには、IAMAccessDomainおよびIAMGovernanceDomainの両方で次の手順を実行します。

  1. Oracle WebLogic Server管理コンソールにログインします。(コンソールのURLは第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されています。)

  2. 「チェンジ・センター」で「ロックして編集」を選択します。

  3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で管理対象サーバーを選択します。選択したサーバーの設定ページが表示されます。

  6. 「SSL」タブを開きます。

  7. ページの「詳細」セクションを開きます。

  8. ホスト名検証をBea Hostname Verifierに設定します。

  9. 「保存」をクリックします。

  10. 「変更のアクティブ化」をクリックします。

14.5.3.2.8 ノード・マネージャの起動

次のコマンドを実行してノード・マネージャを起動します。

cd SHARED_CONFIG/nodemanager/hostname
./startNodeManagerWrapper.sh

注意:

ノード・マネージャの出力にある適切なストアと別名を、そのノード・マネージャで使用していることを確認します。ノード・マネージャの起動時に次の内容が出力されます。

<Loading identity key store:
  FileName=ASERVER_HOME/keystores/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true>

テスト構成の変更を該当のサーバーに適用して、ノード・マネージャからSSLエラーが報告されることなく、それが正常に完了していれば、ホスト名検証は機能しています。