1. Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの共通の構成および管理手順
  3. エンタープライズ・デプロイメントのスケーリング手順

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

エンタープライズ・デプロイメントのスケーリング手順には、スケール・アウト、スケール・イン、スケール・アップおよびスケール・ダウンがあります。スケール・アウト操作の間に、管理対象サーバーを新規ノードに追加します。スケール・イン操作を実行することで、これらの管理対象サーバーを削除できます。スケール・アップ操作の間に、管理対象サーバーを既存のホストに追加します。スケール・ダウン操作を実行することで、これらのサーバーを削除できます。

この章では、静的クラスタおよび動的クラスタについてスケール・アウト/インとスケール・アップ/ダウンの手順を説明します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

トポロジのスケール・アウト

トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。

この項では、静的クラスタおよび動的クラスタについてIdentity Managementトポロジをスケール・アウトする手順について説明します。

ノート:

動的クラスタが適用できるのは、Oracle SOA SuiteやOracle Identity GovernanceなどのGovernanceドメイン・コンポーネントについてのみです。

親トピック: エンタープライズ・デプロイメント用のスケーリング手順

静的クラスタのトポロジのスケール・アウト

この項では、前提条件を示してから、静的クラスタについてトポロジをスケール・アウトする手順と、スケール・アウト・プロセスを検証するステップ、最後にスケール・ダウン(縮小)するステップを説明します。

親トピック: トポロジのスケール・アウト

スケール・アウトの前提条件

トポロジのスケール・アウトを実行する前に、次の前提条件を満たしていることを確認してください。

  • 出発点は、管理対象サーバーがすでに実行されているクラスタです。

  • 新しいノードが、WebLogic ServerとGovernanceの既存のホーム・ディレクトリにアクセスできること。共有記憶域で既存のインストールを使用します。WebLogic ServerまたはIDMのバイナリを新しい場所にインストールする必要はありません。ただし、packおよびunpackコマンドを実行して、新しいノードでドメイン構成をブートストラップする必要はありません。

  • 内部RMI呼出し、JMSアダプタなどにはすべて、クラスタ構文を使用すると想定しています。

静的クラスタのスケール・アウト
この手順で提供されるステップでは、参照としてIDM EDGトポロジを使用します。初めは2つのアプリケーション層ホストがあり(OAMHOST1とOAMHOST2、またはOIMHOST1とOIMHOST2)、それぞれが各クラスタの管理対象サーバー1つを実行します。3番目の管理対象サーバーでクラスタをスケール・アップするために、新しいホストHOST3を追加します。WLS_XYZnは、クラスタに追加する新しい管理対象サーバーに付けられる汎用の名前です。拡張しようとするクラスタと既存のノード数によって、実際の名前はWLS_OAM3、WLS_AMA3、WLS_SOA3などになります。

クラスタをスケール・アウトするには、次のステップを実行します。

  1. 新しいノードで、既存のFMWホームをマウントします。これには、IDMインストールとドメイン・ディレクトリが含まれている必要があります。新しいノードが、ドメイン内の残りのノードと同様に、このディレクトリにアクセスできることを確認します。また、マウントするFMWホームが拡張しているドメインに関連付けられたものであることを確認してください。
  2. オラクルの推奨に従って、共有ディレクトリでインベントリを探します(たとえば/u01/oracle/products/oraInventory)。したがって、ホームを追加する必要はありませんが、スクリプト/u01/oracle/products/oraInventory/createCentralInventory.shを実行しても良いでしょう。

    このコマンドは、oraInventoryの場所を指すように、新しいノードでローカル・ファイル/etc/oraInst.locを作成または更新します。

    新しいホストで他にインベントリの場所がある場合はそれを使用できますが、更新の場合は、いずれの場合にも、それに応じて/etc/oraInst.locファイルを更新する必要があります。

  3. 「DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認」での説明に従って/etc/hostsファイルを更新し、新しいホスト名(DNSを使用しているのでなければ)を追加します。OIMHOSTのようなホスト別名を使用している場合、そのホストのエントリを必ず追加してください。

    たとえば:

    10.229.188.204 host1-vip.example.com host1-vip ADMINVHN
10.229.188.205 host1.example.com host1 OIMHOST1
10.229.188.206 host2.example.com host2 OIMHOST2
10.229.188.207 host3.example.com host3 WEBHOST1
10.229.188.208 host4.example.com host4 WEBHOST2
10.229.188.209 host5.example.com host5 OIMHOST3
  4. Oracle WebLogic管理コンソールにログインして新しいマシンを作成します。
    1. 「環境」→「マシン」に移動します。
    2. 「新規」をクリックして、新しいノードに新しいマシンを作成します。
    3. 「名前」をOIMHOSTnまたはOAMHOSTnに設定します。
    4. 「マシンのOS」を「Linux」に設定します。
    5. 「次」をクリックします。
    6. 「タイプ」を「プレーン」に設定します。
    7. 「リスニング・アドレス」を新しいホスト名に設定します。たとえば、OIMHOST3です。
    8. 「終了」をクリックし、「変更のアクティブ化」をクリックします。
  5. Oracle WebLogic Server管理コンソールを使用して、クラスタの最初の管理対象サーバーから新しい管理対象サーバーにクローンを作成します。
    1. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
    2. 「環境」→「サーバー」に移動します。
    3. スケール・アウトするクラスタの最初の管理対象サーバーを選択し、「クローン」をクリックします。
    4. 「スケール・アウトするクラスタの詳細」を参照し、スケール・アウトするクラスタに応じて対応する名前、リスニング・アドレス、リスニング・ポートを設定します。
    5. 新しい管理対象サーバーをクリックし、「構成」→「一般」の順にクリックします。
    6. 「マシン」をOIMHOST1からOIMHOSTnに更新します。
    7. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

    表23-1 スケール・アウトするクラスタの詳細

    スケール・アウトするクラスタ クローンを作成するサーバー 新しいサーバー名 サーバー・リスニング・アドレス サーバー・リスニング・ポート

    WSM-PM_Cluster

    WLS_WSM1

    WLS_WSMn

    OIMHOSTn

    7010

    SOA_Cluster

    WLS_SOA1

    WLS_SOAn

    OIMHOSTn

    8001

    OIM_Cluster

    WLS_OIM1

    WLS_OIMn

    OIMHOSTn

    14000

    OAM_Cluster

    WLS_OAM1

    WLS_OAMn

    OAMHOSTn

    14100

    AMA_Cluster

    WLS_AMA1

    WLS_AMAn

    OAMHOSTn

    14150

  6. 「uploadおよびstageディレクトリの絶対パスへの変更」での説明に従って、新しいサーバーのデプロイメント・ステージング・ディレクトリ名を更新します。
  7. 「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」での説明に従って、新しいキー証明書を作成しサーバーの秘密キーの別名を更新します。
  8. デフォルトでは、クローンのサーバーはTLOGにデフォルトのストアを使用します。スケール・アウトするクラスタ内の残りのサーバーがJDBC永続ストアでTLOGを使用している場合は、新しい管理対象サーバーのTLOG永続ストアを更新します。
    1. 「環境」→「サーバー」→「WLS_XYZn」→「構成」→「サービス」の順に移動します。
    2. 「トランザクション・ログ・ストア」を「JDBC」に変更します。
    3. 「データ・ソース」を「WLSSchemaDatasource」に変更します。
    4. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

    次の表を参照して、デフォルトでJDBC TLOGを使用するクラスタを識別します。

    表23-2 デフォルトでJDBC TLOGを使用するクラスタの名前

    スケール・アウトするクラスタ 新しいサーバー名 TLOG永続ストア

    WSM-PM_Cluster

    WLS_WSMn

    デフォルト(ファイル)

    SOA_Cluster

    WLS_SOAn

    JDBC

    OIM_Cluster

    WLS_OIMn

    デフォルトJDBC

    OAM_Cluster

    WLS_OAMn

    適用なし

    AMA_Cluster

    WLS_AMAn

    適用なし
  9. スケール・アウトしようとしているクラスタで自動サービス移行が構成されている場合には、「JTA移行ポリシー」を必要な値に更新します。
    1. 「環境」→「サーバー」→「WLS_XYZn」→「構成」→「移行」の順に移動します。
    2. scaling-procedures-enterprise-deployment.html#GUID-0F483475-83C5-4FFE-A5F2-0E9566DFC17E__GUID-888AED4E-E432-4DAA-AEFB-17E20927838Bを参照し、スケール・アウトするクラスタに応じてJTA移行ポリシーを設定します。

      表23-3 スケール・アウトするクラスタに推奨されるJTA移行ポリシー

      スケール・アウトするクラスタ 新しいサーバー名 JTA移行ポリシー

      WSM-PM_Cluster

      WLS_WSMn

      手動

      SOA_Cluster

      WLS_SOAn

      障害リカバリ

      OAM_Cluster

      WLS_OAMn

      適用なし

      AMA_Cluster

      WLS_AMAn

      適用なし

      OIM_Cluster

      WLS_OIMn

      障害リカバリ
    3. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
    4. 明日にすでに存在する残りのサーバーについては、JTA移行に新しいサーバーが含まれるように、「JTA候補サーバー」のリストを更新します。

      • 「環境」→「サーバー」→「server」→「構成」→「移行」の順に移動します。

      • 「JTA候補サーバー」に移動します。リストは空のままにしておきます(クラスタのサーバーがJTA候補サーバーだからです)。

      • 「保存」をクリックし、「変更のアクティブ化」をクリックします。この変更を有効にするためにサーバーを再起動する必要がありますが、必要な構成変更をすべて完了した後に、再起動を1回だけ実行するようにできます。

  10. スケール・アウトしようとしているクラスタで自動サービス移行が構成されている場合には、Oracle WebLogic Server管理コンソールを使用して、自動作成されたWLS_XYZn (移行可能)を、推奨の移行ポリシーで更新します。デフォルトでは「サービスの手動での移行のみ」に設定されているためです。

    更新する移行可能ターゲットのリストは、次の表を参照してください。

    表23-4 推奨される更新する移行可能ターゲット

    スケール・アウトするクラスタ 更新する移行可能ターゲット 移行ポリシー

    WSM-PM_Cluster

    適用なし

    適用なし

    SOA_Cluster

    WLS_SOAn (移行可能)

    障害回復サービスの自動移行

    OIM_Cluster

    WLS_OIMn (移行可能)

    障害回復サービスの自動移行

    OAM_Cluster

    適用なし

    適用なし

    AMA_Cluster

    適用なし

    適用なし
    1. 「環境」→移行可能サーバーに移動します。
    2. 「ロックして編集」をクリックします。
    3. Click WLS_XYZ3 (移行可能)
    4. 「構成」タブ→「移行」に移動します。
    5. 「サービス移行ポリシー」を、表に示されている値に変更します。
    6. 選択したサーバーがある場合、「控えの候補サーバー」リストは空のままにしておきます。サーバーが選択されていない場合は、この移行可能ターゲットをクラスタの任意のサーバーに移行できます。
    7. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  11. スケーリングしているクラスタの既存の移行可能サーバーで、「控えの候補サーバー」リストを更新します。デフォルトでは、WLS_XYZ1サーバーとWLS_XYZ2サーバーしか事前に移入されていないためです。
    1. 各移行可能サーバーに移動します。
    2. 「構成」タブ→「移行」→「控えの候補サーバー」に移動します。

      新しく作成した管理対象サーバーも含めて、このクラスタの任意のサーバーに移行可能ターゲットを移行できるようにサーバー・リストは空のままにしておくことができます。

      次の表を参照して、更新する必要がある移行可能サーバーを識別します。

      表23-5 更新する既存の移行可能ターゲット

      スケール・アウトするクラスタ 更新する既存の移行可能ターゲット 控えの候補サーバー

      WSM-PM_Cluster

      適用なし

      空のままにします

      SOA_Cluster

      WLS_SOA1 (移行可能)

      WLS_SOA2 (移行可能)

      空のままにします

      OIM_Cluster

      WLS_OIM1 (移行可能)

      WLS_OIM2 (移行可能)

      空のままにします
    3. 「保存」をクリックし、「変更のアクティブ化」をクリックします。この変更を有効にするためにサーバーを再起動する必要がありますが、必要な構成変更をすべて完了した後に、再起動を1回だけ実行するようにできます。
  12. JMSサーバーに必要な永続ストアを作成します。
    1. WebLogicコンソールにログインし、「サービス」→「永続ストア」に移動します。
    2. 「新規」をクリックして、「JDBCストアの作成」を選択します。

    次の表を参照して、必要な永続ストアを作成します。

    ノート:

    既存のリソースの名前と接頭辞にある数字は、ドメインの作成時に構成ウィザードによって自動的に割り当てられたものです。たとえば:

    • BPMJMSJDBCStore_auto_1 — soa_1

    • BPMJMSJDBCStore_auto_2 — soa_2

    • JDBCStore-OIM_auto_1 - oim1

    • JDBCStore-OIM_auto_2 - oim2

    • SOAJMSJDBCStore_auto_1 - soa_1

    • SOAJMSJDBCStore_auto_2 - soa_2

    • UMSJMSJDBCStore_auto_1 - soa_1

    • UMSJMSJDBCStore_auto_2 - soa_2

    したがって、既存の接頭辞を見直して、新しい永続ストアごとに新しく一意の接頭辞と名前を選択してください。

    名前の競合を避けて構成を単純化するために、新しいリソースはscaledタグで修飾されます。ここに、その例を示しています。

    表23-6 Scaledタグで修飾された新しいリソース

    スケール・アウトするクラスタ 永続ストア 接頭辞名 データ・ソース ターゲット

    WSM-PM_Cluster

    適用なし

    適用なし

    適用なし

    適用なし

    SOA_Cluster

    UMSJMSJDBCStore_soa_scaled_3

    soaums_scaled_3

    WLSSchemaDataSourc

    WLS_SOA3 (移行可能)

    SOAJMSJDBCStore_ soa_scaled_3

    soajms_scaled_3

    WLSSchemaDataSourc

    WLS_SOA3 (移行可能)

    BPMJMSJDBCStore_ soa_scaled_3

    soabpm_scaled_3

    WLSSchemaDataSourc

    WLS_SOA3 (移行可能)

    (Insightを使用する場合のみ) ProcMonJMSJDBCStore_soa_scaled_3

    soaprocmon_scaled_3

    WLSSchemaDataSource

    WLS_SOA3 (移行可能)

    OIM_Cluster

    該当なし

    JDBCStore-OIM_scaled_3

    WLSSchemaDataSource

    WLS_OIM3 (移行可能)
  13. 新しい管理対象サーバーに必要なJMSサーバーを作成します。
    1. WebLogicコンソールから、「サービス」→「メッセージング」→「JMSサーバー」に移動します。
    2. 「ロックして編集」をクリックします。
    3. 「新規」をクリックします。

    次の表を参照して、必要なJMSサーバーを作成します。各JMSサーバーに、前に作成した永続ストアを割り当てます。

    ノート:

    既存のリソースの名前にある数字は、ドメインの作成時に構成ウィザードによって自動的に割り当てられたものです。

    したがって、既存のJMSサーバー名を見直して、新しいJMSサーバーごとに新しく一意の名前を選択してください。

    名前の競合を避けて構成を単純化するために、新しいリソースはproduct_scaled_Nタグで修飾されます。ここに、その例を示しています。

    スケール・アウトするクラスタ JMSサーバー名 永続ストア ターゲット

    WSM-PM_Cluster

    適用なし

    適用なし

    適用なし

    SOA_Cluster

    UMSJMSServer_soa_scaled_3

    UMSJMSJDBCStore_soa_scaled_3

    WLS_SOA3 (移行可能)

    SOAJMSServer_ soa_scaled_3

    SOAJMSJDBCStore_ soa_scaled_3

    WLS_SOA3 (移行可能)

    BPMJMSServer_ soa_scaled_3

    BPMJMSJDBCStore_ soa_scaled_3

    WLS_SOA3 (移行可能)

    適用なし

    ProcMonJMSJDBCStore_soa_scaled_3

    WLS_SOA3 (移行可能)

    OIM_Cluster

    OIMJMSServer_scaled_3

    JDBCStore-OIM_scaled_3

    WLS_OIM3 (移行可能)

    ノート:

    (*) BamCQServiceJmsServersはBAM CQService (連続検索エンジン)のローカル・キューをホストし、ローカル専用です。意図的に、移行可能ターゲットではなく、WebLogicサーバーを直接のターゲットとしています。
  14. JMSモジュール(適用可能な場合)のサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
    1. 「サービス」→「メッセージング」→「JMSモジュール」の順に開きます。
    2. 「JMSモジュール」をクリックします。たとえば、BPMJMSModuleです。

      次の表を参照して、スケール・アウトしようとしているクラスタに応じて、更新するJMSモジュールを識別します。

      表23-7 更新するJMSモジュール

      スケール・アウトするクラスタ 更新するJMSモジュール サブデプロイメントに追加するJMSサーバー

      WSM-PM_Cluster

      適用なし

      適用なし

      SOA_Cluster

      UMSJMSSystemResource *

      UMSJMSServer_soa_scaled_3

      SOAJMSModule

      SOAJMSServer_soa_scaled_3

      BPMJMSModule

      BPMJMSServer_soa_scaled_3

      (Insightを構成した場合のみ) ProcMonJMSModule *

      ProcMonJMSServer_soa_scaled_3

      OIM_Cluster

      OIMJMSModule

      OIMJMSServer_scaled_3
      (*)一部のモジュール(UMSJMSystemResource、ProcMonJMSModule)は、複数のクラスタをターゲットにしている場合があります。それぞれのケースで適切なサブデプロイメントを更新していることを確認します。
    3. 「構成」→「サブデプロイメント」に移動します。
    4. 対応するJMSサーバーを既存のサブデプロイメントに追加します。

      ノート:

      このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。
    5. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  15. OIMHOST3の管理対象サーバー・ドメイン・ディレクトリにあるノード・マネージャを起動します。次のステップに従って、管理対象サーバー・ホームからノード・マネージャを更新および起動します
    1. 次のステップを実行して、nodemanager.propertiesファイルのリスニング・アドレスが正しく設定されていることを確認します

      • ディレクトリをMSERVER_HOMEバイナリ・ディレクトリに変更します。

        cd MSERVER_HOME/nodemanager

      • nodemanager.propertiesファイルを開いて編集します。

      • ListenAddressプロパティが、次に示すように正しいホスト名になっていることを確認します。

        OIMHOST3: ListenAddress=OIMHOST3

      • ListenPortプロパティを適切なリスニング・ポートの詳細で更新します。

      • QuitEnabledがtrueに設定されていることを確認します。この行がnodemanager.propertiesファイルに存在しない場合は、次の行を追加します。

        QuitEnabled=true

    2. ディレクトリをMSERVER_HOMEバイナリ・ディレクトリに変更します。
      cd MSERVER_HOME /bin
    3. 次のコマンドを使用してノード・マネージャを起動します。

      nohup ./startNodeManager.sh > $MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

      追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

  16. 前の変更を有効にするために、すべてのサーバー(新しく作成したサーバーを除く)を再起動します。ローリング形式で再起動すると、ダウンタイムをなくすことができます。
  17. 構成が完了します。次に、新しいホストにサインインし、次のようにpackコマンドを実行してテンプレート・パックを作成します。
    cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true 
          -domain=ASERVER_HOME
          -template=/full_path/scaleout_domain.jar
          -template_name=scaleout_domain_template
          -log_priority=DEBUG -log=/tmp/pack.log

    この例では、次のようになります。

    • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

    • full_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、そのファイルをサーバー間で手動でコピーすることをお薦めします。

      テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。
      SHARED_CONFIG_DIR/domains/template_filename.jar

    • scaleout_domain.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

    • scaleout_domain_templateは、テンプレート・ファイルに格納されるテンプレート・データに割り当てられるラベルです。

  18. 次のように、unpackコマンドをSOAHOSTNで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
    cd ORACLE_COMMON_HOME/common/bin
./unpack.sh -domain=MSERVER_HOME
            -overwrite_domain=true
            -template=/full_path/scaleout_domain.jar
            -log_priority=DEBUG
            -log=/tmp/unpack.log
            -app_dir=APPLICATION_HOME

    この例では、次のようになります。

    • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

    • /full_path/scaleout_domain.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます

    • APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

  19. OAM_Clusterをスケール・アウトする場合:

    Oracle Access Managementに新しい管理対象サーバーを登録する手順は、次のとおりです。

    1. http://IADADMIN.example.com/oamconsoleで、レスポンス・ファイルの作成時に指定したユーザーとして、アクセス管理コンソールにログインします。

    2. 「構成」タブに移動します。

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

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

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

      • サーバー名: WLS_OAM3

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

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

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

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

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

    7. WebLogic管理サーバーを再起動します。

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

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

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

    2. 「アプリケーション・セキュリティ」タブに移動します。

    3. 「エージェント」をクリックします。

    4. 「検索」をクリックします。Webゲート・エージェントWebgate_IDMが表示されます。

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

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

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

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

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

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

    11. 使用中のすべてのWebゲートにステップを繰り返して、新しい管理対象サーバーを再起動します。

  20. 新しいホストでノード・マネージャを起動します。
    cd $NM_HOME
nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &
  21. 新しい管理対象サーバーを起動します。
  22. Web層の構成を更新して新しいサーバーを追加します。
    1. OTDを使用している場合は、「必要なオリジン・サーバー・プールの作成」で説明されているように、Enterprise Managerにログインして対応するオリジン・プールを更新し、新しいサーバーをプールに追加します。
    2. OHSを使用している場合は、新しいサーバーをOHSに追加する必要はありません。デフォルトでは、動的なサーバー・リストが使用されます。つまり、クラスタのサーバーのリストは、新しいノードがクラスタの一部になったとき自動的に更新されます。リストへの追加が必須でないのは、そのためです。部分的に停止した場合の初期接続を保証するためにWebLogicClusterディレクトリで必要なのは、十分な数の冗長なserver:portの組合せだけです。

      Oracle HTTP Serverを再起動したときに新しいサーバーしか稼働しないシナリオが想定される場合には、WebLogicClusterディレクティブを更新して、新しいサーバーを追加してください。

      たとえば:

      <Location /osb>
 WLSRequest ON
 WebLogicCluster SOAHOST1:8011,SOAHOST2:8011,SOAHOST3:8011
 WLProxySSL ON
 WLProxySSLPassThrough ON
</Location>
静的クラスタのスケール・アウトの確認
スケール・アウトを実行してサーバーを起動したら、次のような確認に進んでください。
  1. Webアプリケーションへのルーティングが正しいことを確認します。

    たとえば:

    1. ロード・バランサ上のアプリケーションにアクセスします。
      https://igdinternal.example.com:7777/soa-infra
    2. 新しいサーバーでもアクティビティがあることを確認します。
      「クラスタ」→「デプロイメント」→「soa-infra」→「モニタリング」→「ワークロード」の順に移動します。
    3. 新しいサーバーでWebセッションが作成されることも確認できます。

      • 「クラスタ」→「デプロイメント」に移動します。

      • 「soa-infra」を開き、soa-infra Webアプリケーションをクリックします。

      • 「モニタリング」に移動して、各サーバーのWebセッションをチェックします。

      次の表にまとめたサンプルURLおよび対応するWebアプリケーションを使用すると、スケール・アウトしているクラスタの新しいサーバーでセッションが作成されるかどうかをチェックできます。

      確認するクラスタ テストするサンプルURL Webアプリケーション・モジュール

      WSM-PM_Cluster

      http://igdinternal.example.com/wsm-pm

      wsm-pm > wsm-pm

      SOA_Cluster

      http://igdinternal.example.com:7777/soa-infra

      soa-infra > soa-infra

      OAM_Cluster

      http://login.example.com/oam

      AMA_Cluster

      http://iadadmin.example.com/access

      OIM_Cluster

      https://prov.example.com/identity

      ノート:

      OAMを検証すると、OAMが示すOAMサーバー・エラーが表示されます。これは通常、OAMがアクセスされていることを示すためのテストです。適切な引数が通常操作の一部としてサーバーに渡されると、エラーは消失します。
  2. 3つのサーバーで、JMSメッセージが宛先に対して生成および使用されていることと、宛先から生成および使用されていることを確認します。
    1. 「JMSサーバー」に移動します。
    2. 「JMSサーバー」→「モニタリング」の順にクリックします。
  3. 「静的クラスタでの自動サービス移行の検証」での説明に従って、サービスの移行を確認します。
静的クラスタのトポロジのスケール・イン
静的クラスタのトポロジをスケール・インするには:
  1. 削除する管理対象サーバーを停止します。
  2. 自動サービス移行を使用している場合は、クラスタを縮小およびスケールする前に、そのサーバーに対応するリソースが残りのサーバー上にないことを確認します。必ず1回の移行ポリシーを使用している場合は、すべてのサーバーを停止します
  3. OAMコンソールを使用して、OAMサーバーをWebゲート構成から削除します(OAMサーバーを削除する場合)。
    1. http://iadadmin.example.com/oamconsoleで、レスポンス・ファイルの作成時に指定したユーザーとして、アクセス管理コンソールにログインします。
    2. 「システム構成」タブに移動します。
    3. 「サーバー・インスタンス」をクリックします。
    4. 削除するサーバー・インスタンスを選択し、「アクション」メニューから「削除」を選択します。
    5. 「適用」をクリックします。
  4. Oracle WebLogic Server管理コンソールを使用して、削除しようとしているサーバーによって使用されている移行可能ターゲットを削除します。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「クラスタ」→「移行可能なターゲット」に移動します。
    3. 削除する移行可能なターゲットを選択します。
    4. 「削除」をクリックします。
    5. 「はい」をクリックします。
    6. 「変更のアクティブ化」をクリックします。
  5. Oracle WebLogic Server管理コンソールを使用して、新しいサーバーを削除します。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「サーバー」に移動します。
    3. 削除するサーバーを選択します。
    4. 「削除」をクリックします。
    5. 「はい」をクリックします。
    6. 「変更のアクティブ化」をクリックします。

    ノート:

    前のステップで、移行可能ターゲットが削除されなかった場合は、次のエラー・メッセージが表示されます。

    The following failures occurred: --MigratableTargetMBean WLS_SOA3_soa-failure-recovery (migratable) does not have a preferred server set.
Errors must be corrected before proceeding.
  6. Oracle WebLogic Server管理コンソールを使用して、縮小しようとしているクラスタによって使用されている各JMSモジュールのサブデプロイメントを更新します。

    次の表を参照して、各クラスタのモジュールを識別し、各モジュールに対してこのアクションを実行します。

    スケール・インするクラスタ 永続ストア サブデプロイメントから削除するJMSサーバー

    WSM-PM_Cluster

    適用なし

    適用なし

    SOA_Cluster

    UMSJMSSystemResource

    SOAJMSModule

    BPMJMSModule

    UMSJMSServer_soa_scaled_3

    SOAJMSServer_soa_scaled_3

    BPMJMSServer_soa_scaled_3

    OIM_Cluster

    OIMJMSModule

    OIMJMSServer_scaled_3
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「サービス」→「メッセージング」→「JMSモジュール」に移動します。
    3. 「JMSモジュール」をクリックします。
    4. 「サブデプロイメント」をクリックします。
    5. 削除したサーバーに作成されたJMSサーバーの選択を解除します。
    6. 「保存」をクリックします。
    7. 「変更のアクティブ化」をクリックします。
  7. Oracle WebLogic Server管理コンソールを使用して、JMSサーバーを削除します。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「サービス」→「メッセージング」→「JMSモジュール」に移動します。
    3. 新しいサーバーに作成したJMSサーバーを選択します。
    4. 「削除」をクリックします。
    5. 「はい」をクリックします。
    6. 「変更のアクティブ化」をクリックします。
  8. Oracle WebLogic Server管理コンソールを使用して、JMS永続ストアを削除します。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「サービス」→「永続ストア」の順に移動します。
    3. 新しいサーバーに作成した永続ストアを選択します。
    4. 「削除」をクリックします。
    5. 「はい」をクリックします。
    6. 「変更のアクティブ化」をクリックします。
  9. Web層の構成を更新して、新しいサーバーへの参照を削除します。

動的クラスタのトポロジのスケール・アウト

この項では、前提条件を示してから、動的クラスタについてトポロジをスケール・アウトする手順と、スケール・アウト・プロセスを検証するステップ、最後にスケール・ダウン(縮小)するステップを説明します。

親トピック: トポロジのスケール・アウト

スケール・アウトの前提条件

トポロジのスケール・アウトを実行する前に、次の前提条件を満たしていることを確認してください。

  • 出発点は、管理対象サーバーがすでに実行されているクラスタです。

  • 新しいノードが、WebLogic ServerとGovernanceの既存のホーム・ディレクトリにアクセスできること。共有記憶域で既存のインストールを使用します。WebLogic ServerまたはIDMのバイナリを新しい場所にインストールする必要はありません。ただし、packおよびunpackコマンドを実行して、新しいノードでドメイン構成をブートストラップする必要はありません。

  • 内部RMI呼出し、JMSアダプタなどにはすべて、クラスタ構文を使用すると想定しています。

動的クラスタのスケール・アウト
この手順で提供されるステップでは、参照としてIAM EDGトポロジを使用します。最初は、2つのアプリケーション層ホスト(OIMHOST1とOIMHOST2)があり、それぞれで各クラスタの管理対象サーバーが1つ実行されています。3番目の管理対象サーバーでクラスタをスケール・アップするために、新しいホストOIMHOST3が追加されます。WLS_XYZnは、クラスタに追加する新しい管理対象サーバーに付けられる汎用の名前です。拡張するクラスタ、および既存のノードの数によって、実際の名前はWLS_SOA3とWLS_OIM3になります。

動的クラスタでトポロジをスケール・アウトするには、次のステップを実行します。

  1. 「エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー」で説明したとおり、新しいノードで、FMWホーム(Binaries1)、共有構成(sharedConfig)およびランタイム(runTime)用に既存の共有ボリュームをマウントします

    ノート:

    必ずIdentity Governanceバイナリに関連付けられたファイル・システムをマウントしてください。
  2. オラクルの推奨に従って、共有ディレクトリでインベントリを探します(たとえば/u01/oracle/products/oraInventory)。したがって、ホームを追加する必要はありませんが、スクリプト/u01/oracle/products/oraInventory/createCentralInventory.shを実行しても良いでしょう。

    このコマンドは、oraInventoryの場所を指すように、新しいノードでローカル・ファイル/etc/oraInst.locを作成または更新します。

    新しいホストで他にインベントリの場所がある場合はそれを使用することもできますが、それぞれのケースでの更新に応じて/etc/oraInst.locファイルを更新する必要があります。

  3. 「DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認」での説明に従って/etc/hostsファイルを更新し、新しいホスト名(DNSを使用しているのでなければ)を追加します。OIMHOSTのようなホスト別名を使用している場合、そのホストのエントリを必ず追加してください。

    たとえば:

    10.229.188.204 host1-vip.example.com host1-vip ADMINVHN
10.229.188.205 host1.example.com host1 OIMHOST1
10.229.188.206 host2.example.com host2 OIMHOST2
10.229.188.207 host3.example.com host3 WEBHOST1
10.229.188.208 host4.example.com host4 WEBHOST2
10.229.188.209 host5.example.com host5 OIMHOST3
  4. https://docs.oracle.com/pls/topic/lookup?ctx=en/middleware/fusion-middleware/12.2.1.3/imedg&id=SOEDG-GUID-38510079-BCDE-4888-877E-6BF7580B7181で説明したとおりに、新しいノードでドメインごとのノード・マネージャを構成します。
  5. Oracle WebLogic管理コンソールにログインして、新しいノードの新しいマシンを作成します。
  6. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
  7. Oracle WebLogic Server管理コンソールを使用し、新しい管理対象サーバーを含むように動的クラスタを増やします。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「クラスタ」に移動します。
    3. スケール・アウトするクラスタを選択します。
    4. 「構成」→「サーバー」に移動します。
    5. 「動的クラスタ・サイズ」を3に設定します。デフォルトでは、クラスタ・サイズは2です。

      ノート:

      4つ以上のサーバーへのスケール・アウトの場合、「クラスタ・アドレス内のサーバー数」(デフォルトで3)も更新する必要があります。t3のコールにはクラスタ構文を使用することをお薦めしますが、t3を介して外部要素から、EJBスタブに対してなどでコールする場合には、クラスタ・アドレスが使用されます。

  8. OIMHOST1にサインインし、次のようにpackコマンドを実行してテンプレート・パックを作成します。
    cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true
          -domain=ASERVER_HOME
          -template=/full_path/scaleout_domain.jar
          -template_name=scaleout_domain_template
          -log_priority=DEBUG -log=/tmp/pack.log

    この例では、次のようになります。

    • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

    • full_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、そのファイルをサーバー間で手動でコピーすることをお薦めします。

      テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。
      SHARED_CONFIG_DIR/domains/template_filename.jar

    • scaleout_domain.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

    • scaleout_domain_templateは、テンプレート・ファイルに格納されるテンプレート・データに割り当てられるラベルです。

  9. 次のように、unpackコマンドをSOAHOSTNで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
    cd ORACLE_COMMON_HOME/common/bin
./unpack.sh -domain=MSERVER_HOME
            -overwrite_domain=true
            -template=/full_path/scaleout_domain.jar
            -log_priority=DEBUG
            -log=/tmp/unpack.log
            -app_dir=APPLICATION_HOME

    この例では、次のようになります。

    • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

    • /full_path/scaleout_domain.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます

    • APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

  10. 新しいホストでノード・マネージャを起動します。
    cd $NM_HOME
nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &
  11. 新しい管理対象サーバーを起動します。
  12. Web層の構成を更新してこの新しいサーバーを追加します。
    1. OTDを使用している場合は、「必要なオリジン・サーバー・プールの作成」で説明されているように、Enterprise Managerにログインして対応するオリジン・プールを更新し、新しいサーバーをプールに追加します。
    2. OHSを使用している場合は、新しいサーバーをOHSに追加する必要はありません。

      デフォルトでは、動的なサーバー・リストが使用されます。つまり、クラスタのサーバーのリストは、新しいノードがクラスタの一部になったとき自動的に更新されます。新しいノードをリストに追加する必要がないのは、そのためです。部分的に停止した場合の初期接続を保証するためにWebLogicClusterディレクトリで必要なのは、十分な数の冗長なserver:portの組合せだけです。

      Oracle HTTP Serverを再起動したときに新しいサーバーしか稼働しないシナリオが想定される場合には、WebLogicClusterディレクティブを更新して、新しいサーバーを追加してください。

      たとえば:

      <Location /soa-infra>
 WLSRequest ON
 WebLogicCluster OIMHOST1:8011,OIMHOST2:8012,OIMHOST3:8013
 WLProxySSL ON
 WLProxySSLPassThrough ON
</Location>
動的クラスタのスケール・アウトの確認
スケール・アウトを実行してサーバーを起動したら、次のような確認に進んでください。
  1. Webアプリケーションへのルーティングが正しいことを確認します。

    たとえば:

    1. ロード・バランサ上のアプリケーションにアクセスします。
      https://igdinternal.example.com:7777/soa-infra
    2. 新しいサーバーでもアクティビティがあることを確認します。
      「クラスタ」→「デプロイメント」→「soa-infra」→「モニタリング」→「ワークロード」の順に移動します。
    3. 新しいサーバーでWebセッションが作成されることも確認できます。

      • 「クラスタ」→「デプロイメント」に移動します。

      • 「soa-infra」を開き、soa-infra Webアプリケーションをクリックします。

      • 「モニタリング」に移動して、各サーバーのWebセッションをチェックします。

      次の表にまとめたサンプルURLおよび対応するWebアプリケーションを使用すると、スケール・アウトしているクラスタの新しいサーバーでセッションが作成されるかどうかをチェックできます。

      確認するクラスタ テストするサンプルURL Webアプリケーション・モジュール

      WSM-PM_Cluster

      http://igdinternal.example.com/wsm-pm

      wsm-pm > wsm-pm

      SOA_Cluster

      http://igdinternal.example.com:7777/soa-infra

      soa-infra > soa-infra

      OAM_Cluster

      http://login.example.com/oam

      AMA_Cluster

      http://iadadmin.example.com/access

      OIM_Cluster

      https://prov.example.com/identity

      ノート:

      OAMを検証すると、OAMが示すOAMサーバー・エラーが表示されます。これは通常、OAMがアクセスされていることを示すためのテストです。適切な引数が通常操作の一部としてサーバーに渡されると、エラーは消失します。
  2. 3つのサーバーで、JMSメッセージが宛先に対して生成および使用されていることと、宛先から生成および使用されていることを確認します。
    1. 「JMSサーバー」に移動します。
    2. 「JMSサーバー」→「モニタリング」の順にクリックします。
  3. 「動的クラスタでの自動サービス移行の検証」での説明に従って、サービスの移行を確認します。
動的クラスタのトポロジのスケール・イン
動的クラスタのトポロジをスケール・インするには:
  1. 削除する管理対象サーバーを停止します。
  2. 自動サービス移行を使用している場合は、クラスタを縮小(スケール)する前に、そのサーバーに対応するシングルトン・リソースが残りのサーバー上にないことを確認します。
  3. Oracle WebLogic Server管理コンソールを使用して、動的クラスタを減らします。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「クラスタ」に移動します。
    3. スケール・インするクラスタを選択します。
    4. 「構成」→「サーバー」に移動します。
    5. 「動的クラスタ・サイズ」を2に設定します。
  4. OSBを使用している場合は、管理サーバーを再起動します。

トポロジのスケール・アップ

トポロジのスケール・アップでは、既存のホストに新しい管理対象サーバーを追加します。

この項では、静的クラスタおよび動的クラスタについてトポロジをスケール・アップする手順について説明します。

  • 静的クラスタのトポロジのスケール・アップ
    この項では、前提条件を示してから、静的クラスタについてトポロジをスケール・アップする手順と、スケール・アウト・プロセスを検証するステップ、最後にスケール・ダウン(縮小)するステップを説明します。
  • 動的クラスタのトポロジのスケール・アップ
    この項では、前提条件を示してから、動的クラスタについてトポロジをスケール・アウトする手順と、スケールアップ・プロセスを検証するステップ、最後にスケール・ダウン(縮小)するステップを説明します。

親トピック: エンタープライズ・デプロイメント用のスケーリング手順

静的クラスタのトポロジのスケール・アップ

この項では、前提条件を示してから、静的クラスタについてトポロジをスケール・アップする手順と、スケール・アウト・プロセスを検証するステップ、最後にスケール・ダウン(縮小)するステップを説明します。

Fusion Middlewareコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。このノードには、共有記憶域内にWebLogic ServerホームとOracle Fusion Middleware IAMホームが存在します。新しい管理対象サーバーを作成するには、これらの既存のインストールとドメイン・ディレクトリを使用します。WLSまたはSOAバイナリをインストールする必要も、packやunpackを実行する必要もありません。新しいサーバーは既存のノードで実行されるからです。

親トピック: トポロジのスケール・アップ

スケール・アップの前提条件

トポロジのスケール・アップを実行する前に、次の前提条件を満たしていることを確認してください。

  • 出発点は、管理対象サーバーがすでに実行されているクラスタです。

  • 内部RMI呼出し、JMSアダプタなどにはすべて、クラスタ構文を使用すると想定しています。

静的クラスタのスケール・アップ

IAM EDGトポロジには2つの異なるドメインがあり、1つはOAM用、1つはOIG用です。スケール・アップはスケールするクラスタにかかわらず、だいたい同じです。次の例はHOST1、HOST2およびHOST3を指します。OAMをスケールしている場合、これらのホストはOAMHOST1、OAMHOST2およびOAMHOST3と等しくなります。OIMをスケールしている場合、これらのホストはOIMHOST1、OIMHOST2およびOIMHOST3と等しくなります。

次の例では、HOST1で実行されているクラスタに、3つ目の管理対象サーバーを追加する方法を説明します。WLS_XYZnは、クラスタに追加する新しい管理対象サーバーに付けられる汎用の名前です。拡張するクラスタ、および既存のノードの数によって、実際の名前はWLS_OAM3、WLS_AMA3、WLS_OIM4、WLS_SOA3、WLS_WSM3などになります。

クラスタをスケール・アップするには、次のステップを実行します。

  1. Oracle WebLogic Server管理コンソールを使用して、クラスタの最初の管理対象サーバーから新しい管理対象サーバーにクローンを作成します。
    1. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
    2. 「環境」→「サーバー」に移動します。
    3. スケール・アップするクラスタの最初の管理対象サーバーを選択し、「クローン」をクリックします。
    4. 表23-8を参照し、スケール・アウトするクラスタに応じて対応する名前、リスニング・アドレス、リスニング・ポートを設定します。すでに作成され同じホストで実行されている管理対象サーバーとバインド競合しないように、デフォルトのリスニング・ポートは1ずつ増分します。
    5. 新しい管理対象サーバーをクリックし、「構成」→「一般」の順に選択します。
    6. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

    表23-8 スケール・アップするクラスタのリスト

    スケール・アップするクラスタ クローンを作成するサーバー 新しいサーバー名 サーバー・リスニング・アドレス サーバー・リスニング・ポート

    WSM-PM_Cluster

    WLS_WSM1

    WLS_WSMn

    OIMHOSTn

    7011

    SOA_Cluster

    WLS_SOA1

    WLS_SOAn

    OIMHOSTn

    8001

    OIM_Cluster

    WLS_OIM1

    WLS_OIMn

    OIMHOSTn

    14000

    OAM_Cluster

    WLS_OAM1

    WLS_OAMn

    OAMHOSTn

    14100

    AMA_Cluster

    WLS_AMA1

    WLS_AMAn

    OAMHOSTn

    14150

    ノート:

    ポート番号は指定されたホストで一意である必要があるため、前述のポート番号はホストに既存の管理対象サーバーが使用するポートより1つ加算されています。
  2. 「uploadおよびstageディレクトリの絶対パスへの変更」での説明に従って、新しいサーバーのデプロイメント・ステージング・ディレクトリ名を更新します。
  3. 「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」での説明に従って、新しいキー証明書を作成しサーバーの秘密キーの別名を更新します。
  4. デフォルトでは、クローンのサーバーはTLOGにデフォルトのストアを使用します。スケール・アウトするクラスタ内の残りのサーバーがJDBC永続ストアでTLOGを使用している場合は、新しい管理対象サーバーのTLOG永続ストアを更新します。

    次の表を参照して、デフォルトでJDBC TLOGを使用するクラスタを識別します。

    表23-9 デフォルトでJDBC TLOGを使用するクラスタの名前

    スケール・アップするクラスタ 新しいサーバー名 TLOG永続ストア

    WSM-PM_Cluster

    WLS_WSMn

    デフォルト(ファイル)

    SOA_Cluster

    WLS_SOAn

    JDBC

    OIM_Cluster

    WLS_OIMn

    デフォルトJDBC

    OAM_Cluster

    WLS_OAMn

    適用なし

    AMA_Cluster

    WLS_AMAn

    適用なし
    次のステップを実行します
    1. 「環境」→「サーバー」→「WLS_XYZn」→「構成」→「サービス」の順に移動します。
    2. 「トランザクション・ログ・ストア」セクションで、「タイプ」をJDBCに変更します。
    3. 「データ・ソース」を「WLSSchemaDatasource」に変更します。
    4. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  5. スケール・アップしようとしているクラスタで自動サービス移行が構成されている場合には、「JTA移行ポリシー」を必要な値に更新します。

    次の表を参照して、JTA移行ポリシーの更新が必要なクラスタを識別します。

    表23-10 スケール・アップするクラスタに推奨されるJTA移行ポリシー

    スケール・アップするクラスタ 新しいサーバー名 JTA移行ポリシー

    WSM-PM_Cluster

    WLS_WSMn

    手動

    SOA_Cluster

    WLS_SOAn

    障害リカバリ

    OAM_Cluster

    WLS_OAMn

    適用なし

    AMA_Cluster

    WLS_AMAn

    適用なし

    OIM_Cluster

    WLS_OIMn

    障害リカバリ

    ステップは次のとおりです。

    1. 「環境」→「サーバー」→「WLS_XYZn」→「構成」→「移行」の順に移動します。
    2. 表23-10を参照し、スケール・アウトするクラスタに応じてJTA移行ポリシーを設定します。
    3. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
    4. 明日にすでに存在する残りのサーバーについては、JTA移行に新しいサーバーが含まれるように、「JTA候補サーバー」のリストを更新します。

      • 「環境」→「サーバー」→「server」→「構成」→「移行」の順に移動します。

      • 「JTA候補サーバー」に移動します。リストは空のままにしておきます(クラスタ内のすべてのサーバーがJTA候補サーバーであるため)。

      • 「保存」をクリックし、「変更のアクティブ化」をクリックします。この変更を有効にするためにサーバーを再起動する必要がありますが、必要な構成変更をすべて完了した後に、再起動を1回だけ実行するようにできます。

  6. スケール・アップしようとしているクラスタで自動サービス移行が構成されている場合には、Oracle WebLogic Server管理コンソールを使用して、自動作成されたWLS_XYZn (移行可能)を、推奨の移行ポリシーで更新します。デフォルトでは「サービスの手動での移行のみ」に設定されているためです。

    更新する移行可能ターゲットのリストは、次の表を参照してください。

    表23-11 推奨される更新する移行可能ターゲット

    スケール・アップするクラスタ 更新する移行可能ターゲット 移行ポリシー

    WSM-PM_Cluster

    適用なし

    適用なし

    SOA_Cluster

    WLS_SOAn (移行可能)

    障害回復サービスの自動移行

    OIM_Cluster

    WLS_OIMn (移行可能)

    障害回復サービスの自動移行

    OAM_Cluster

    適用なし

    適用なし

    AMA_Cluster

    適用なし

    適用なし
    1. 「環境」→「クラスタ」→移行可能なサーバーに移動します。
    2. 「ロックして編集」をクリックします。
    3. Click WLS_XYZ3 (移行可能)
    4. 「構成」タブから、「移行」に移動します。
    5. 「サービス移行ポリシー」を、表に示されている値に変更します。
    6. 選択したサーバーがある場合、「控えの候補サーバー」リストは空のままにしておきます。サーバーが選択されていない場合は、この移行可能ターゲットをクラスタの任意のサーバーに移行できます。
    7. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  7. スケーリングしているクラスタの既存の移行可能サーバーで、「控えの候補サーバー」リストを更新します。デフォルトでは、WLS_XYZ1サーバーとWLS_XYZ2サーバーしか事前に移入されていないためです。

    次の表を参照して、更新する必要がある移行可能サーバーを識別します。

    表23-12 更新する既存の移行可能ターゲット

    スケール・アップするクラスタ 更新する既存の移行可能ターゲット 控えの候補サーバー

    WSM-PM_Cluster

    適用なし

    空のままにします

    SOA_Cluster

    WLS_SOA1 (移行可能)

    WLS_SOA2 (移行可能)

    空のままにします

    OIM_Cluster

    WLS_OIM1 (移行可能)

    WLS_OIM1 (移行可能)

    空のままにします
    1. 各移行可能サーバーに移動します。
    2. 「構成」タブ→「移行」→「控えの候補サーバー」に移動します。

      新しく作成した管理対象サーバーも含めて、このクラスタの任意のサーバーに移行可能ターゲットを移行できるようにサーバー・リストは空のままにしておくことができます。

    3. 「保存」をクリックして、「変更のアクティブ化」をクリックしますこの変更を有効にするためにサーバーを再起動する必要がありますが、必要な構成変更をすべて完了した後に、再起動を1回だけ実行するようにできます。
  8. JMSサーバーに必要な永続ストアを作成します。
    1. WebLogicコンソールにサインインし、「サービス」→「永続ストア」に移動します。
    2. 「新規」をクリックして、「JDBCストアの作成」を選択します。

    次の表を参照して、必要な永続ストアを作成します。

    ノート:

    既存のリソースの名前と接頭辞にある数字は、ドメインの作成時に構成ウィザードによって自動的に割り当てられたものです。

    たとえば:
    BPMJMSJDBCStore_auto_1 — soa_1
BPMJMSJDBCStore_auto_2 — soa_2
JDBCStore-OIM_auto_1 - oim1
JDBCStore-OIM_auto_2 - oim2
SOAJMSJDBCStore_auto_1 - soa_1
SOAJMSJDBCStore_auto_2 - soa_2
UMSJMSJDBCStore_auto_1 - soa_1
UMSJMSJDBCStore_auto_2 - soa_2

    既存の接頭辞を見直して、新しい永続ストアごとに新しく一意の接頭辞と名前を選択します。

    名前の競合を避けて構成を単純化するために、新しいリソースはscaledタグで修飾されます。ここに、その例を示しています。

    表23-13 Scaledタグで修飾された新しいリソース

    スケール・アップするクラスタ 永続ストア 接頭辞名 データ・ソース ターゲット

    WSM-PM_Cluster

    適用なし

    適用なし

    適用なし

    適用なし

    SOA_Cluster

    UMSJMSJDBCStore_soa_scaled_3

    soaums_scaled_3

    WLSSchemaDataSourc

    WLS_SOA3 (移行可能)

    SOAJMSJDBCStore_ soa_scaled_3

    soajms_scaled_3

    WLSSchemaDataSourc

    WLS_SOA3 (移行可能)

    BPMJMSJDBCStore_ soa_scaled_3

    soabpm_scaled_3

    WLSSchemaDataSourc

    WLS_SOA3 (移行可能)

    (Insightを使用する場合のみ) ProcMonJMSJDBCStore_soa_scaled_3

    soaprocmon_scaled_3

    WLSSchemaDataSource

    WLS_SOA3 (移行可能)

    OIM_Cluster

    JDBCStore-OIM_scaled_3

    oimjms_scaled_3

    WLSSchemaDataSource

    WLS_OIM3 (移行可能)

  9. 新しい管理対象サーバーに必要なJMSサーバーを作成します。
    1. WebLogicコンソールから、「サービス」→「メッセージング」→「JMSサーバー」に移動します。
    2. 「ロックして編集」をクリックします。
    3. 「新規」をクリックします。

    次の表を参照して、必要なJMSサーバーを作成します。各JMSサーバーに、前に作成した永続ストアを割り当てます。

    ノート:

    既存のリソースの名前にある数字は、ドメインの作成時に構成ウィザードによって自動的に割り当てられたものです。既存のJMSサーバー名を見直して、新しいJMSサーバーごとに新しく一意の名前を選択します。名前の競合を避けて構成を単純化するために、新しいリソースはproduct_scaled_Nタグで修飾されます。ここに、その例を示しています。

    スケール・アップするクラスタ JMSサーバー名 永続ストア ターゲット

    WSM-PM_Cluster

    適用なし

    適用なし

    適用なし

    SOA_Cluster

    UMSJMSServer_soa_scaled_3

    UMSJMSJDBCStore_soa_scaled_3

    WLS_SOA3 (移行可能)

    SOAJMSServer_ soa_scaled_3

    SOAJMSJDBCStore_ soa_scaled_3

    WLS_SOA3 (移行可能)

    BPMJMSServer_ soa_scaled_3

    BPMJMSJDBCStore_ soa_scaled_3

    WLS_SOA3 (移行可能)

    (Insightを使用する場合のみ) ProcMonJMSServer_soa_scaled_3

    ProcMonJMSJDBCStore_soa_scaled_3

    WLS_SOA3 (移行可能)

    OIM_Cluster

    OIMJMSServer_scaled_3

    JDBCStore-OIM_scaled_3

    WLS_OIM3 (移行可能)
  10. JMSモジュール(適用可能な場合)のサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
    1. 「サービス」→「メッセージング」→「JMSモジュール」の順に開きます。
    2. 「JMSモジュール」をクリックします。たとえば、BPMJMSModuleです。

      次の表を参照して、スケール・アップしようとしているクラスタに応じて更新するJMSモジュールを識別します。

      スケール・アップするクラスタ 更新するJMSモジュール サブデプロイメントに追加するJMSサーバー

      WSM-PM_Cluster

      適用なし

      適用なし

      SOA_Cluster

      UMSJMSSystemResource *

      UMSJMSServer_soa_scaled_3

      SOAJMSModule

      SOAJMSServer_soa_scaled_3

      BPMJMSModule

      BPMJMSServer_soa_scaled_3

      (Insightを構成した場合のみ) ProcMonJMSModule *

      ProcMonJMSServer_soa_scaled_3

      OIM_Cluster

      OIMJMSModule

      OIMJMSServer_scaled_3
      (*)一部のモジュール(UMSJMSystemResource、ProcMonJMSModule)は、複数のクラスタをターゲットにしている場合があります。それぞれのケースで適切なサブデプロイメントを更新していることを確認します。
    3. 「構成」→「サブデプロイメント」に移動します。
    4. 対応するJMSサーバーを既存のサブデプロイメントに追加します。

      ノート:

      このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

    5. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  11. 前のすべての変更を有効にするために、すべてのサーバー(新しく作成したサーバーを除く)を再起動します。ローリング形式で再起動すると、ダウンタイムをなくすことができます。
  12. 新しい管理対象サーバーを起動します。
  13. Web層の構成を更新してこの新しいサーバーを追加します。

    • OTDを使用している場合は、「必要なオリジン・サーバー・プールの作成」で説明されているように、Enterprise Managerにログインして対応するオリジン・プールを更新し、新しいサーバーをプールに追加します。

    • OHSを使用している場合は、新しいサーバーをOHSに追加する必要はありません。デフォルトでは、動的なサーバー・リストが使用されます。つまり、クラスタのサーバーのリストは、新しいノードがクラスタの一部になったとき自動的に更新されます。そのため、リストへの追加は必須ではありません。一部停止が発生した場合に初期接続を保証するためにWebLogicClusterディレクティブに必要なのは、十分な数の冗長なserver:portの組合せのみです。

      Oracle HTTP Serverを再起動したときに新しいサーバーしか稼働しないシナリオが想定される場合には、WebLogicClusterディレクティブを更新して、新しいサーバーを追加してください。

      <Location /soa-infra>
  WLSRequest ON
  WebLogicCluster OIMHOST1:8011,OIMHOST2:8012,OIMHOST3:8013
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>
静的クラスタのスケール・アップの確認
スケール・アップを実行してサーバーを起動したら、次のような確認に進んでください。
  1. Webアプリケーションへのルーティングが正しいことを確認します。

    たとえば:

    1. ロード・バランサ上のアプリケーションにアクセスします。
      https://igdinternal.example.com:7777/soa-infra
    2. 新しいサーバーでもアクティビティがあることを確認します。
      「クラスタ」→「デプロイメント」→「soa-infra」→「モニタリング」→「ワークロード」の順に移動します。
    3. 新しいサーバーでWebセッションが作成されることも確認できます。

      • 「クラスタ」→「デプロイメント」に移動します。

      • 「soa-infra」を開き、soa-infra Webアプリケーションをクリックします。

      • 「モニタリング」に移動して、各サーバーのWebセッションをチェックします。

      次の表にまとめたサンプルURLおよび対応するWebアプリケーションを使用すると、スケール・アウトしているクラスタの新しいサーバーでセッションが作成されるかどうかをチェックできます。

      確認するクラスタ テストするサンプルURL Webアプリケーション・モジュール

      WSM-PM_Cluster

      http://igdinternal.example.com/wsm-pm

      wsm-pm > wsm-pm

      SOA_Cluster

      http://igdinternal.example.com:7777/soa-infra

      soa-infra > soa-infra

      OAM_Cluster

      http://login.example.com/oam

      AMA_Cluster

      http://iadadmin.example.com/access

      OIM_Cluster

      https://prov.example.com/identity

      ノート:

      OAMを検証すると、OAMが示すOAMサーバー・エラーが表示されます。これは通常、OAMがアクセスされていることを示すためのテストです。適切な引数が通常操作の一部としてサーバーに渡されると、エラーは消失します。
  2. 3つのサーバーで、JMSメッセージが宛先に対して生成および使用されていることと、宛先から生成および使用されていることを確認します。
    1. 「JMSサーバー」に移動します。
    2. 「JMSサーバー」→「モニタリング」の順にクリックします。
  3. 「静的クラスタでの自動サービス移行の検証」での説明に従って、サービスの移行を確認します。
静的クラスタのトポロジのスケール・イン
静的クラスタのトポロジをスケール・インするには:
  1. 削除する管理対象サーバーを停止します。
  2. 自動サービス移行を使用している場合は、クラスタを縮小およびスケールする前に、そのサーバーに対応するリソースが残りのサーバー上にないことを確認します。必ず1回の移行ポリシーを使用している場合は、すべてのサーバーを停止します
  3. OAMコンソールを使用して、OAMサーバーをWebゲート構成から削除します(OAMサーバーを削除する場合)。
    1. http://iadadmin.example.com/oamconsoleで、レスポンス・ファイルの作成時に指定したユーザーとして、アクセス管理コンソールにログインします。
    2. 「システム構成」タブに移動します。
    3. 「サーバー・インスタンス」をクリックします。
    4. 削除するサーバー・インスタンスを選択し、「アクション」メニューから「削除」を選択します。
    5. 「適用」をクリックします。
  4. Oracle WebLogic Server管理コンソールを使用して、削除しようとしているサーバーによって使用されている移行可能ターゲットを削除します。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「クラスタ」→「移行可能なターゲット」に移動します。
    3. 削除する移行可能なターゲットを選択します。
    4. 「削除」をクリックします。
    5. 「はい」をクリックします。
    6. 「変更のアクティブ化」をクリックします。
  5. Oracle WebLogic Server管理コンソールを使用して、新しいサーバーを削除します。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「サーバー」に移動します。
    3. 削除するサーバーを選択します。
    4. 「削除」をクリックします。
    5. 「はい」をクリックします。
    6. 「変更のアクティブ化」をクリックします。

    ノート:

    前のステップで、移行可能ターゲットが削除されなかった場合は、次のエラー・メッセージが表示されます。

    The following failures occurred: --MigratableTargetMBean WLS_SOA3_soa-failure-recovery (migratable) does not have a preferred server set.
Errors must be corrected before proceeding.
  6. Oracle WebLogic Server管理コンソールを使用して、縮小しようとしているクラスタによって使用されている各JMSモジュールのサブデプロイメントを更新します。

    次の表を参照して、各クラスタのモジュールを識別し、各モジュールに対してこのアクションを実行します。

    スケール・インするクラスタ 永続ストア サブデプロイメントから削除するJMSサーバー

    WSM-PM_Cluster

    適用なし

    適用なし

    SOA_Cluster

    UMSJMSSystemResource

    SOAJMSModule

    BPMJMSModule

    UMSJMSServer_soa_scaled_3

    SOAJMSServer_soa_scaled_3

    BPMJMSServer_soa_scaled_3

    OIM_Cluster

    OIMJMSModule

    OIMJMSServer_scaled_3
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「サービス」→「メッセージング」→「JMSモジュール」に移動します。
    3. 「JMSモジュール」をクリックします。
    4. 「サブデプロイメント」をクリックします。
    5. 削除したサーバーに作成されたJMSサーバーの選択を解除します。
    6. 「保存」をクリックします。
    7. 「変更のアクティブ化」をクリックします。
  7. Oracle WebLogic Server管理コンソールを使用して、JMSサーバーを削除します。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「サービス」→「メッセージング」→「JMSモジュール」に移動します。
    3. 新しいサーバーに作成したJMSサーバーを選択します。
    4. 「削除」をクリックします。
    5. 「はい」をクリックします。
    6. 「変更のアクティブ化」をクリックします。
  8. Oracle WebLogic Server管理コンソールを使用して、JMS永続ストアを削除します。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「サービス」→「永続ストア」の順に移動します。
    3. 新しいサーバーに作成した永続ストアを選択します。
    4. 「削除」をクリックします。
    5. 「はい」をクリックします。
    6. 「変更のアクティブ化」をクリックします。
  9. Web層の構成を更新して、新しいサーバーへの参照を削除します。

動的クラスタのトポロジのスケール・アップ

この項では、前提条件を示してから、動的クラスタについてトポロジをスケール・アウトする手順と、スケール・アップ・プロセスを検証するステップ、最後にスケール・ダウン(縮小)するステップを説明します。

Fusion Middlewareコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。このノードには、共有記憶域内にWebLogic ServerホームとOracle Fusion Middleware IAMホームが存在します。新しい管理対象サーバーを作成するには、これらの既存のインストールとドメイン・ディレクトリを使用します。WLSまたはSOAバイナリをインストールする必要も、packコマンドやunpackコマンドを実行する必要もありません。新しいサーバーは既存のノードで実行されるためです。

親トピック: トポロジのスケール・アップ

スケール・アップの前提条件

トポロジのスケール・アップを実行する前に、次の前提条件を満たしていることを確認してください。

  • 出発点は、管理対象サーバーがすでに実行されているクラスタです。

  • 内部RMI呼出し、JMSアダプタなどにはすべて、クラスタ構文を使用すると想定しています。

動的クラスタのスケール・アップ

基準としてIAM EDGトポロジを使用します。2つのアプリケーション層ホスト(OIMHOST1とOIMHOST2)があり、それぞれで各クラスタの管理対象サーバーが1つ実行されています。この例では、OIMHOST1で実行されているクラスタに3つ目の管理対象サーバーを追加する方法を説明します。WLS_XYZnは、クラスタに追加する新しい管理対象サーバーに付けられる汎用の名前です。拡張するクラスタ、および既存のノードの数によって、実際の名前はWLS_SOA3とWLS_OIM3になります。

クラスタをスケール・アップするには、次のステップを実行します。

  1. スケール・アップの場合、新しいサーバーが既存のマシンに追加されるので、新しいマシンを追加する必要はありません。

    CalculatedMachineNames 属性がtrueに設定されている場合、MachineNameMatchExpression属性が使用されて、動的サーバーで使用されているマシンのセットが選択されます。割当ては、ラウンド・ロビン・アルゴリズムを使用して行われます。

    次の表に、動的クラスタにおけるマシン割当ての例をリストします。

    表23-14 動的クラスタにおけるマシン割当ての例

    ドメイン内のマシン MachineNameMatchExpression構成 動的サーバーのマシン割当

    OIMHOST1、OIMHOST2

    OIMHOST*

    dyn-server-1: OIMHOST1

    dyn-server-2: OIMHOST2

    dyn-server-3: OIMHOST1

    dyn-server-4: OIMHOST2

    ...

    https://docs.oracle.com/middleware/1212/wls/CLUST/dynamic_clusters.htm#CLUST678を参照してください。

  2. テンプレートでリスニング・アドレスとしてOIMHOST{$id}を使用している場合には、「DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認」での説明に従って/etc/hostsファイルを更新し、新しいノードの別名SOAHOSTNを追加します。

    新しいサーバーWLS_XYZnは、SOAHOSTnでリスニングします。この別名は、新しい管理対象サーバーが実行されるシステム・ホストの、対応するIPアドレスに解決される必要があります。表23-14を参照してください。

    例: 
    10.229.188.204 host1-vip.example.com host1-vip ADMINVHN
10.229.188.205 host1.example.com host1 OIMHOST1
10.229.188.206 host2.example.com host2 OIMHOST2
10.229.188.207 host3.example.com host3 WEBHOST1
10.229.188.208 host4.example.com host4 WEBHOST2
10.229.188.209 host5.example.com host5 OIMHOST3

    テンプレートのリスニング・アドレスで{$dynamic-hostname}を使用している場合、新しいサーバーWLS_xYZnはJAVAプロパティdynamic-hostnameで定義されているアドレスでリスニングします。この場合、動的クラスタをスケール・アップするときに/etc/hostsへの別名の追加は不要です。「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。

  3. Oracle WebLogic Server管理コンソールを使用し、新しい管理対象サーバーを含むように動的クラスタを増やします。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「クラスタ」に移動します。
    3. スケール・アウトするクラスタを選択します。
    4. 「構成」→「サーバー」に移動します。
    5. 「動的クラスタ・サイズ」を3に設定します。デフォルトでは、クラスタ・サイズは2です。
    6. 「保存」、「変更のアクティブ化」の順にクリックします。

      ノート:

      4つ以上のサーバーへのスケール・アウトの場合、「クラスタ・アドレス内のサーバー数」(デフォルトで3)も更新する必要があります。t3のコールにはクラスタ構文を使用することをお薦めしますが、t3を介して外部要素からコールする場合には(EJBスタブに対してなど)、クラスタ・アドレスが使用されます。

  4. Web層の構成を更新してこの新しいサーバーを追加します。

    • OTDを使用している場合は、「必要なオリジン・サーバー・プールの作成」で説明されているように、Enterprise Managerにログインして対応するオリジン・プールを更新し、新しいサーバーをプールに追加します。

    • OHSを使用している場合は、新しいサーバーをOHSに追加する必要はありません。デフォルトでは、動的なサーバー・リストが使用されます。つまり、クラスタのサーバーのリストは、新しいノードがクラスタの一部になったとき自動的に更新されます。そのため、リストへの追加は必須ではありません。一部停止が発生した場合に初期接続を保証するためにWebLogicClusterディレクティブに必要なのは、十分な数の冗長なserver:portの組合せのみです。

      Oracle HTTP Serverを再起動したときに新しいサーバーしか稼働しないシナリオが想定される場合には、WebLogicClusterディレクティブを更新して、新しいサーバーを追加してください。

      たとえば:

      <Location /soa-infra>
  WLSRequest ON
  WebLogicCluster OIMHOST1:8011,OIMHOST2:8012,OIMHOST3:8013
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>
  5. Oracle WebLogic Serverから、新しい管理対象サーバーを起動します。
  6. 新たに作成した管理対象サーバーが実行されていることを検証します。
動的クラスタのスケール・アップの確認
スケール・アウトを実行してサーバーを起動したら、次のような確認に進んでください。
  1. Webアプリケーションへのルーティングが正しいことを確認します。

    たとえば:

    1. ロード・バランサ上のアプリケーションにアクセスします。
      https://igdinternal.example.com:7777/soa-infra
    2. 新しいサーバーでもアクティビティがあることを確認します。
      「クラスタ」→「デプロイメント」→「soa-infra」→「モニタリング」→「ワークロード」の順に移動します。
    3. 新しいサーバーでWebセッションが作成されることも確認できます。

      • 「クラスタ」→「デプロイメント」に移動します。

      • 「soa-infra」を開き、soa-infra Webアプリケーションをクリックします。

      • 「モニタリング」に移動して、各サーバーのWebセッションをチェックします。

      次の表にまとめたサンプルURLおよび対応するWebアプリケーションを使用すると、スケール・アウトしているクラスタの新しいサーバーでセッションが作成されるかどうかをチェックできます。

      確認するクラスタ テストするサンプルURL Webアプリケーション・モジュール

      WSM-PM_Cluster

      http://igdinternal.example.com/wsm-pm

      wsm-pm > wsm-pm

      SOA_Cluster

      http://igdinternal.example.com:7777/soa-infra

      soa-infra > soa-infra

      OAM_Cluster

      http://login.example.com/oam

      AMA_Cluster

      http://iadadmin.example.com/access

      OIM_Cluster

      https://prov.example.com/identity

      ノート:

      OAMを検証すると、OAMが示すOAMサーバー・エラーが表示されます。これは通常、OAMがアクセスされていることを示すためのテストです。適切な引数が通常操作の一部としてサーバーに渡されると、エラーは消失します。
  2. 3つのサーバーで、JMSメッセージが宛先に対して生成および使用されていることと、宛先から生成および使用されていることを確認します。
    1. 「JMSサーバー」に移動します。
    2. 「JMSサーバー」→「モニタリング」の順にクリックします。
  3. 「動的クラスタの自動サービス移行の構成」での説明に従って、サービスの移行を確認します。
動的クラスタでのトポロジのスケール・ダウン
動的クラスタでトポロジをスケール・ダウンするには:
  1. 削除する管理対象サーバーを停止します。
  2. 自動サービス移行を使用している場合は、クラスタをスケール・ダウンする前に、そのサーバーに対応するシングルトン・リソースが残りのサーバー上にないことを確認します。
  3. Oracle WebLogic Server管理コンソールを使用して、動的クラスタを減らします。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「クラスタ」に移動します。
    3. スケール・ダウンするクラスタを選択します。
    4. 「構成」→「サーバー」に移動します。
    5. 再度、「動的クラスタ・サイズ」を2に設定します。

OAM固有のスケーリング・アクション

この項では、アクセス・マネージャおよびWebゲート・エージェントへの新しい管理対象サーバーの登録について簡単に説明します。

OAM管理対象サーバーをスケール・アップまたはスケール・アウトするために、前述のステップに追加して行います。Access ManagerおよびWebゲート・エージェントに新しい管理対象サーバーを登録する必要もあります。そのためには、次のステップを実行する必要があります。

親トピック: エンタープライズ・デプロイメント用のスケーリング手順

新しいOAM管理対象サーバーの登録

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

  1. http://IADADMIN.example.com/oamconsoleで、レスポンス・ファイルの作成時に指定したユーザーとして、アクセス管理コンソールにログインします。
  2. 「システム構成」タブをクリックします。
  3. 「サーバー・インスタンス」をクリックします。
  4. 「アクション」メニューから「作成」を選択します。
  5. 次の情報を入力します。

    • サーバー名: WLS_OAM3

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

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

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

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

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

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

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

  7. 「適用」をクリックします。
  8. WebLogic管理サーバーを再起動します。

親トピック: OAM固有のスケーリング・アクション

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

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

たとえば、Webgate_IDMにAccess Managerサーバーを追加するには、http://IADADMIN.example.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_12c、IAMSuiteAgentおよび使用している可能性のあるその他すべてのWebゲートで、ステップ5から10を繰り返します。

親トピック: OAM固有のスケーリング・アクション