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

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

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

この章では、クラスタのスケール・アウト/インとスケール・アップ/ダウンの手順を説明します。

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

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

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

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

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

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

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

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

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

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

クラスタのスケール・アウト

この手順で示されるステップでは、基準としてSOA EDGトポロジを使用します。最初は、2つのアプリケーション層ホスト(SOAHOST1とSOAHOST2)があり、それぞれで各クラスタの管理対象サーバーが1つ実行されています。3番目の管理対象サーバーでクラスタをスケール・アップするには、新しいホストSOAHOST3を追加します。WLS_XYZnは、クラスタに追加する新しい管理対象サーバーに付けられる汎用の名前です。拡張するクラスタ、および既存のノードの数によって、実際の名前はWLS_SOA3、WLS_OSB3、WLS_ESS3などになります。
スケール・アウト手順では、サービス移行がデフォルトの移行ポリシー(手動)とは異なる移行ポリシーを使用して構成されている場合、スケーリング対象のWLSクラスタ内の既存のサーバーにダウンタイムが必要です。また、既存の移行可能ターゲットが空の候補サーバー・リストを使用しない場合も、ダウンタイムが発生します。空の候補リストを使用することがベスト・プラクティスとなります。これは、クラスタ内のすべてのサーバーが移行の候補であることを意味するためです。WebLogicリモート・コンソールを使用して、各移行可能ターゲットの候補のリストを確認できます:

  1. WebLogicリモート・コンソールでドメインにアクセスします。

  2. リモート・コンソール画面の左上隅で、「ツリーの編集」をクリックします

  3. ナビゲーション・ツリーの「環境」を開きます。

  4. ナビゲーション・ツリーの「移行可能ターゲット」を開きます。

  5. 各移行可能ターゲットをクリックし、「移行」タブの「控えの候補サーバー」リストを確認します。

エンタープライズ・デプロイメント・ガイドに従って環境を作成した場合、これらのリストはデフォルトで空です。クラスタに新しいサーバーを追加すると、サーバーは自動的に移行対象とみなされ、既存のサーバーを再起動する必要はありません。

クラスタの特定のサーバーのみへの移行を制限する場合、候補サーバー・リストは空になりません。クラスタに新しいサーバーを追加する場合は、新しいサーバーを追加するためにサーバーを変更する必要がある場合があります。この場合、スケールアウト・プロセス中に既存のノードを再起動する必要があります。新しいサーバーで移行ポリシーを手動のポリシーから変更すると、クラスタ内の既存メンバーの再起動も求められます。Oracleでは、これらの2つの変更を一括処理し、これらの変更(移行ポリシーと候補リスト)を両方とも完了した後に1回だけ再起動を実行することをお薦めします。

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

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

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

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

  3. 「DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認」での説明に従って/etc/hostsファイルを更新し、新しいノードの別名SOAHOSTnを追加します。

    たとえば:

    10.229.188.204 host1-vip.example.com host1-vip ADMINVHN
10.229.188.205 host1.example.com host1 SOAHOST1
10.229.188.206 host2.example.com host2 SOAHOST2
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 SOAHOST3
  4. 「ホストごとのノード・マネージャ構成の作成」での説明に従って、新しいノードでホストごとのノード・マネージャを構成します。ただし、まだ起動しないでください。これは後で起動します。
  5. WebLogicリモート・コンソールにログインして、新しいマシンを作成します:
    1. 「環境」に移動し、「マシン」を選択します。
    2. 「新規」をクリックして、新しいノードに新しいマシンを作成します。
    3. 「名前」をSOAHOSTn (またはMFTHOSTnかBAMHOSTn)に設定します。
    4. 「ノード・マネージャ」タブをクリックします。
    5. 「タイプ」を「SSL」に設定します。
    6. 「リスニング・アドレス」をSOAHOSTnに設定します。
    7. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  6. Oracle WebLogicリモート・コンソールを使用して、クラスタの最初の管理対象サーバーから新しい管理対象サーバーにクローンを作成します。
    1. 「環境」に移動し、「サーバー」を選択します。
    2. 「作成」をクリックし、「別のサーバーから設定をコピー」で、スケール・アウトするクラスタの最初の管理対象サーバーを選択し、「作成」をクリックします。
    3. スケール・アウトするクラスタの最初の管理対象サーバーを選択し、「作成」をクリックします。
    4. 表21-1を参照し、スケール・アウトするクラスタに応じて対応する名前、リスニング・アドレス、SSLリスニング・ポートを設定します。
    5. 新しい管理対象サーバーをクリックし、「構成」を選択してから「一般」を選択します。
    6. 「マシン」をSOAHOST1からSOAHOSTnに更新します。
    7. サーバーの管理ポートも、クラスタ内の他のサーバーと一致するように更新します。たとえば、SOAサーバーではポート9004を使用し、OSBサーバーでは9007を使用します。適切な管理ポートについては、既存のサーバーを参照してください。
    8. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。

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

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

    WSM-PM_Cluster

    WLS_WSM1

    WLS_WSM3

    SOAHOST3

    7010

    9003

    SOA_Cluster

    WLS_SOA1

    WLS_SOA3

    SOAHOST3

    7004

    9004

    ESS_Cluster

    WLS_ESS1

    WLS_ESS3

    SOAHOST3

    7008

    9006

    OSB_Cluster

    WLS_OSB1

    WLS_OSB3

    SOAHOST3

    8003

    9007

    BAM_Cluster

    WLS_BAM1

    WLS_BAM3

    SOAHOST3

    7006

    9005

    MFT_Cluster

    WLS_MFT1

    WLS_MFT3

    MFTHOST3

    7010

    9014

  7. 「エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更」での説明に従って、新しいサーバーのデプロイメント・ステージング・ディレクトリ名を更新します。
  8. 「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」の章の「WebLogicドメインの証明書および証明書ストアの作成」での説明に従って、新しいキー証明書を作成し、ドメイン証明書ストアを更新します。(config.xmlで検出されたすべてのアドレスのかわりに)新しいアドレスのみを追加する場合は、次の構文でgenerate_perdomainCACERTS.shスクリプトを使用します:
    ./generate_perdomainCACERTS.sh [WLS_DOMAIN_DIRECTORY] [WL_HOME] [KEYSTORE_HOME] [KEYPASS] [NEWADDR]

    ここで、NEWADDRは、追加される新しいサーバーのリスニング・アドレスです。

  9. 新しいサーバーのキーストアの場所とSSL構成は、コピーされたサーバー(WLS_SOA1)から引き継がれますが、パスワード(新しいサーバーに対して再度暗号化されるため)と、この新しいサーバーの「サーバーの秘密キーの別名」エントリを再度更新する必要があります。

    1. 「環境」→「サーバー」に移動します。

    2. 新しいサーバーをクリックします。

    3. 「セキュリティ」→「キーストア」に移動します。

    4. 「カスタム・アイデンティティ・キー・ストア・パスフレーズ」および「カスタム信頼キー・ストア・パスフレーズ」を、generate_perdomainCACERTS.shスクリプトに指定されたパスワードで更新します。

    5. 「セキュリティ」の下の「SSL」タブをクリックします。

    6. 「サーバーの秘密キーのパスフレーズ」を、generate_perdomainCACERTS.shスクリプトに指定されたパスワードで更新します

    7. 前のステップ(新しいサーバーの証明書の生成)で使用したリスニング・アドレスを、「サーバーの秘密キーの別名」として追加します。

  10. 新しい管理対象サーバーのTLOG JDBC永続ストアを更新します:
    1. WebLogicリモート・コンソールにログインします。
    2. 「環境」に移動し、左側のナビゲーション・ツリーで「サーバー」リンクを開きます。
    3. 新しいサーバーWLS_XYZnをクリックします。
    4. 「サービス」→「JTA」タブをクリックします。
    5. JDBCで「トランザクション・ログ・ストア」が選択されていることを確認し、「トランザクション・ログ接頭辞」の名前をTLOG_WLS_XYZnに変更します。
    6. 残りのフィールドは、コピーされたサーバー(JDBCストアに使用されるデータソースWLSRuntimeSchemaDataSourceを含む)から引き継がれます。
    7. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。

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

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

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

    WSM-PM_Cluster

    WLS_WSM3

    デフォルト(ファイル)

    SOA_Cluster

    WLS_SOA3

    JDBC

    ESS_Cluster

    WLS_ESS3

    デフォルト(ファイル)

    OSB_Cluster

    WLS_OSB3

    JDBC

    BAM_Cluster

    WLS_BAM3

    JDBC

    MFT_Cluster

    WLS_MFT3

    JDBC
  11. スケール・アウトしようとしているクラスタで自動サービス移行が構成されている場合には、「JTA移行ポリシー」を必要な値に更新します。
    1. 「環境」に移動し、「サーバー」を開きます。サーバーのリストから「WLS_XYZn」を選択し、「JTA移行可能ターゲット」をクリックします。
    2. 表21-3を参照し、スケール・アウトするクラスタに応じて推奨されるJTA移行ポリシーが設定されていることを確認します。

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

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

      WSM-PM_Cluster

      WLS_WSM3

      手動

      SOA_Cluster

      WLS_SOA3

      障害リカバリ

      ESS_Cluster

      WLS_ESS3

      手動

      OSB_Cluster

      WLS_OSB3

      障害リカバリ

      BAM_Cluster

      WLS_BAM3

      障害リカバリ

      MFT_Cluster

      WLS_MFT3

      障害リカバリ
    3. クラスタにすでに存在するサーバーで、JTA移行のJTA候補サーバーのリストが空であることを確認します。
      1. 「環境」をクリックし、「サーバー」を開きます。
      2. サーバーを選択します。
      3. コンテキスト・メニューで「JTA移行可能ターゲット」を選択します。
      4. 「控えの候補サーバー」リストをチェックして、リストが空であることを確認します(空のリストは、クラスタ内のすべてのサーバーがJTA候補サーバーであることを示します)。リストはデフォルトで空になるため、変更は不要です。
      5. サーバー・リストが空でない場合は、リストを空白にするように変更する必要があります。または、移行を特定のサーバーのみに制限することを明示的に決定したためにリストが空でない場合は、新しいサーバーに対応するようにプリファレンスに従って変更します。「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。候補リストを変更するには、クラスタ内の既存のサーバーの再起動が必要であることに注意してください。
  12. スケール・アウトしようとしているクラスタで自動サービス移行が構成されている場合には、Oracle WebLogicリモート・コンソールを使用して、自動作成されたWLS_XYZn (移行可能)ターゲットを、推奨の移行ポリシーで更新します。デフォルトでは「サービスの手動での移行のみ」に設定されているためです。

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

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

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

    WSM-PM_Cluster

    該当なし

    該当なし

    SOA_Cluster

    WLS_SOA3 (移行可能)

    障害リカバリ

    ESS_Cluster

    該当なし

    該当なし

    OSB_Cluster

    WLS_OSB3 (移行可能)

    障害リカバリ

    BAM_Cluster

    WLS_BAM3 (移行可能)

    必ず1回

    MFT_Cluster

    WLS_MFT3 (移行可能)

    障害リカバリ
    1. 「環境」→「移行可能ターゲット」に移動します。
    2. Click WLS_XYZ3 (移行可能)
    3. 「サービス移行ポリシー」を、表に示されている値に変更します。
    4. 選択したサーバーがある場合、「控えの候補サーバー」リストは空のままにしておきます。サーバーが選択されていない場合は、この移行可能ターゲットをクラスタの任意のサーバーに移行できます。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。デフォルトの移行ポリシー(手動)から変更するには、クラスタ内の既存のサーバーの再起動が必要であることに注意してください。
  13. 複数の移行可能ターゲットを使用するコンポーネントの場合、ステップ11に加えて、Oracle WebLogic Serverリモート・コンソールで、クラスタ内の既存のターゲットから設定をコピーして新しい(移行可能)ターゲットを作成します。前述のステップを使用して、必要となるカスタマイズ可能な設定を行います。
  14. クラスタ内の既存の移行可能サーバーの「控えの候補サーバー」リストが空であることを確認します。構成ウィザードはこれを空のままにするため、デフォルトで空になります。候補リストが空の場合は、クラスタ内のすべてのサーバーが候補であることを意味します。これはベスト・プラクティスです。
    1. 各移行可能サーバーに移動します。
    2. 「移行」タブをクリックし、「控えの候補サーバー」リストを確認します。
    3. 「選択済」サーバー・リストが空であることを確認します。デフォルトでは空になります。
    4. サーバー・リストが空でない場合は、リストを空白にするように変更する必要があります。または、移行を特定のサーバーのみに制限することを明示的に決定したためにリストが空でない場合は、新しいサーバーに対応するようにプリファレンスに従って変更します。「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。候補リストを変更するには、クラスタ内の既存のサーバーの再起動が必要であることに注意してください。
  15. 新しいサーバーで使用されるJMSサーバーに必要な永続ストアを作成します。
    1. WebLogicリモート・コンソールにログインします。「ツリーの編集」で、「サービス」を開き、「JDBCストア」を選択します。
    2. 「新規」をクリックします。

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

    ノート:

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

    • UMSJMSJDBCStore_auto_1 — soa_1

    • UMSJMSJDBCStore_auto_2 — soa_2

    • BPMJMSJDBCStore_auto_1 — soa_3

    • BPMJMSJDBCStore_auto_2 — soa_4

    • SOAJMSJDBCStore_auto_1 — soa_5

    • SOAJMSJDBCStore_auto_2 — soa_6

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

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

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

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

    WSM-PM_Cluster

    該当なし

    該当なし

    該当なし

    該当なし

    SOA_Cluster

    UMSJMSJDBCStore_soa_scaled_3

    soaums_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_SOA3 (移行可能)

    SOAJMSJDBCStore_ soa_scaled_3

    soajms_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_SOA3 (移行可能)

    BPMJMSJDBCStore_ soa_scaled_3

    soabpm_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_SOA3 (移行可能)

    ESS_Cluster

    該当なし

    該当なし

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSJDBCStore_osb_scaled_3

    osbums_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_OSB3 (移行可能)

    OSBJMSJDBCStore_osb_scaled_3

    osbjms_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_OSB3 (移行可能)

    BAM_Cluster

    UMSJMSJDBCStore_bam_scaled_3

    bamums_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamPersistenceJmsJDBCStore_bam_scaled_3

    bamP_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamReportCacheJmsJDBCStore_bam_scaled_3

    bamR_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamAlertEngineJmsJDBCStore_bam_scaled_3

    bamA_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamJmsJDBCStore_bam_scaled_3

    bamjms_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamCQServiceJmsJDBCStore_bam_scaled_3

    bamC_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3*

    MFT_Cluster

    MFTJMSJDBCStore_mft_scaled_3

    mftjms_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_MFT3 (移行可能)

    ノート:

    (*) BamCQServiceJmsServersはBAM CQService (連続検索エンジン)のローカル・キューをホストし、ローカル専用です。意図的に、移行可能ターゲットではなく、WebLogicサーバーを直接のターゲットとしています。
  16. 新しい管理対象サーバーに必要なJMSサーバーを作成します。
    1. WebLogicリモート・コンソールに移動します。「ツリーの編集」で、「サービス」を選択し、「JMSサーバー」をクリックします。
    2. 「新規」をクリックします。

    次の表を参照して、必要な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 (移行可能)

    ESS_Cluster

    該当なし

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSServer_osb_scaled_3

    UMSJMSJDBCStore_osb_scaled_3

    WLS_OSB3 (移行可能)

    wlsbJMSServer_osb_scaled_3

    OSBJMSJDBCStore_osb_scaled_3

    WLS_OSB3 (移行可能)

    BAM_Cluster

    UMSJMSServer_bam_scaled_3

    UMSJMSJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BamPersistenceJmsServer_bam_scaled_3

    BamPersistenceJmsJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BamReportCacheJmsServer_bam_scaled_3

    BamReportCacheJmsJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BamAlertEngineJmsServer_bam_scaled_3

    BamAlertEngineJmsJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BAMJMSServer_bam_scaled_3

    BamJmsJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BamCQServiceJmsServer_bam_scaled_3

    BamCQServiceJmsJDBCStore_bam_scaled_3

    WLS_BAM3*

    MFT_Cluster

    MFTJMSServer_mft_scaled_3

    MFTJMSJDBCStore_mft_scaled_3

    WLS_MFT3 (移行可能)

    ノート:

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

      「サブ・デプロイメント」を開き、ターゲットを更新するために対応するデプロイメントを選択します。次の表を参照して、スケール・アウトしようとしているクラスタに応じて、更新するJMSモジュールを識別します:

      表21-6 更新するJMSモジュール

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

      WSM-PM_Cluster

      該当なし

      該当なし

      SOA_Cluster

      UMSJMSSystemResource *

      UMSJMSServer_soa_scaled_3

      SOAJMSModule

      SOAJMSServer_soa_scaled_3

      BPMJMSModule

      BPMJMSServer_soa_scaled_3

      ESS_Cluster

      該当なし

      該当なし

      OSB_Cluster

      UMSJMSSystemResource *

      UMSJMSServer_osb_scaled_3

      jmsResources (グローバル・スコープ)

      wlsbJMSServer_osb_scaled_3

      BAM_Cluster

      BamPersistenceJmsSystemModule

      BamPersistenceJmsServer_bam_scaled_3

      BamReportCacheJmsSystemModule

      BamReportCacheJmsServer_bam_scaled_3

      BamAlertEngineJmsSystemModule

      BamAlertEngineJmsServer_bam_scaled_3

      BAMJMSSystemResource

      BAMJMSServer_bam_scaled_3

      BamCQServiceJmsSystemModule

      N/A (既存のサブデプロイメントは更新しません。新しいサーバーの新しいサブデプロイメントは次のステップで作成されます)

      UMSJMSSystemResource *

      UMSJMSServer_bam_scaled_3

      MFT_Cluster

      MFTJMSModule

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

      ノート:

      このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。
    4. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  18. BAMクラスタをスケール・アウトする場合は、BamCQServiceJmsSystemModuleモジュールに、新しいサーバーの追加リソース(サブデプロイメントおよびローカル・キュー)を作成する必要があります。これらを作成するには、次のステップに従います。
    1. WebLogicリモート・コンソールに移動します。「ツリーの編集」をクリックし、「環境」→「サービス」を選択します
    2. 「JMSモジュール」をクリックし、「BamCQServiceJmsSystemModule」を選択します。
    3. 「ターゲット」をクリックします。
    4. ターゲットにWLS_BAM3を追加して、「保存」をクリックします。
    5. BamCQServiceJmsSystemModule JMSモジュールに、BamCQServiceAlertEngineSubdeployment_scaled_3という名前の新しいサブデプロイメントを作成します。次に、このサブデプロイメントのターゲットとしてBamCQServiceJmsServer_bam_scaled_3を選択します。

      表21-7 ローカル・キューの追加サブデプロイメントを作成するときの情報

      サブデプロイメント名 サブデプロイメント・ターゲット

      BamCQServiceAlertEngineSubdeployment_scaled_3

      BamCQServiceJmsServer_bam_scaled_3
    6. 「モジュール」の下の「キュー」を選択し、「新規」をクリックします。
    7. 「作成」をクリックします。
    8. BamCQServiceAlertEngineQueue_auto_3という名前を付けます。
    9. 新しく選択したキューBamCQServiceAlertEngineQueue_auto_3の中をクリックします。
    10. 「一般」タブを選択します。
    11. 「ローカルJNDI名」をqueue/oracle.beam.cqservice.mdbs.alertengineに設定します。
    12. 「サブ・デプロイメント名」をBamCQServiceAlertEngineSubdeployment_scaled_3に設定します。
    13. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
    14. 同じステップを繰り返し、表21-8の情報を使用してもう1つのキューBamCQServiceReportCacheQueue_auto_3を作成します。
    15. 完了すると、新しいローカル・キューを使用できるようになります。

      表21-8 ローカル・キューを作成するときの情報

      名前 タイプ ローカルJNDI名 サブデプロイメント

      BamCQServiceAlertEngineQueue_auto_3

      キュー

      queue/oracle.beam.cqservice.mdbs.alertengine

      BamCQServiceAlertEngineSubdeployment_scaled_3

      BamCQServiceReportCacheQueue_auto_3

      キュー

      queue/oracle.beam.cqservice.mdbs.reportcache

      BamCQServiceAlertEngineSubdeployment_scaled_3
  19. 構成が完了します。次に、SOAHOST1にサインインし、次のように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
          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は、テンプレート・ファイルに格納されるテンプレート・データに割り当てられるラベルです。

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

  21. OSB_Clusterをスケール・アウトする場合:
    1. 管理サーバーを再起動し、Service Busダッシュボードで新しいサーバーを確認します。
  22. MFT_Clusterをスケール・アウトする場合:
    1. 新しいサーバーでは、デフォルトのSFTP/FTPポートが使用されます。デフォルトを使用しない場合は、「SFTPポートの構成」での説明に従って、SFTPサーバーのポートを構成します。
  23. 新しいホストでノード・マネージャを起動します。
    cd $NM_HOME
nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &
  24. 新しい管理対象サーバーを起動します。
  25. Web層の構成を更新して新しいサーバーを追加します。
    1. OHSを使用している場合は、新しいサーバーをOHSに追加する必要はありません。デフォルトでは、動的なサーバー・リストが使用されます。つまり、クラスタのサーバーのリストは、新しいノードがクラスタの一部になったとき自動的に更新されます。リストへの追加が必須でないのは、そのためです。部分的に停止した場合の初期接続を保証するためにWebLogicClusterディレクトリで必要なのは、十分な数の冗長なserver:portの組合せだけです。

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

      たとえば:

      <Location /soa-infra>
 WLSRequest ON
 WebLogicCluster SOAHOST1:7004,SOAHOST2:7004,SOAHOST3:7004
</Location>

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

スケール・アウトの確認

スケール・アウトを実行してサーバーを起動したら、次のような確認に進んでください。
  1. Webアプリケーションへのルーティングが正しいことを確認します。

    たとえば:

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

      • リモート・コンソールで、「モニタリング・ツリー」に移動し、「デプロイメント」→「アプリケーション・ランタイム・データ」→「soa-infra」に移動します。

      • 「コンポーネント・ランタイム」に移動し、「<WLS_SOA3_/soa-infra」をクリックします。

      • セッションがあるかどうかを確認します。

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

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

      WSM-PM_Cluster

      https://soainternal.example.com:444/wsm-pm

      wsm-pm > wsm-pm

      SOA_Cluster

      https://soa.example.com/soa-infra

      soa-infra > soa-infra

      ESS_Cluster

      https://soa.example.com/ESSHealthCheck

      ESSHealthCheck

      OSB_Cluster

      https://osb.example.com/sbinspection.wsil

      Service Bus WSIL

      MFT_Cluster

      https://mft.example.com/mftconsole

      mftconsole

      BAM_Cluster

      https://soa.example.com/bam/composer

      BamComposer > /bam/composer
  2. 3つのサーバーで、JMSメッセージが宛先に対して生成および使用されていることと、宛先から生成および使用されていることを確認します。
    1. リモート・コンソールで、「モニタリング・ツリー」に移動します。
    2. 「ダッシュボード」→「JMS宛先」に移動します。
  3. 「自動サービス移行の検証」での説明に従って、サービスの移行を確認します。

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

トポロジのスケール・イン

この項では、クラスタのトポロジをスケール・インする方法を説明します。

クラスタのトポロジをスケール・インするには、次のステップを実行します:
  1. JMSのデータ損失なしでクラスタをスケール・インするには、SOAサーバーでのJMSメッセージの管理で説明されているステップを実行します。

    それらのステップが完了したら、スケール・インの手順を続行します。

  2. 保留中のJTAを確認します。サーバーを停止する前に、削除するサーバーにアクティブなJTAトランザクションがあるかどうか確認します。WebLogicリモート・コンソールのモニタリング・ツリーに移動し、「サーバー」→「<server name>」→「サービス」→「トランザクション」→「JTAランタイム」をクリックして、「トランザクション」タブを選択します。

    ノート:

    JTAの「停止リカバリ」ポリシーを使用している場合は、サーバーを停止した後、別のサーバーでトランザクションが回復されます。

  3. 「作業完了時」オプションを使用して、サーバーを停止します。

    ノート:

    サーバーにアクティブなHTTPセッションまたは長いトランザクションがある場合、この操作に長い時間がかかることがあります。正常な停止の詳細は、Oracle WebLogic Serverサーバーの起動と停止の管理のサーバーのライフサイクル・コマンドの使用を参照してください。

  4. Oracle WebLogicリモート・コンソールを使用して、新しいサーバーを削除します:
    1. 「ツリーの編集」をクリックします。
    2. 「環境」→「サーバー」に移動します。
    3. 削除するサーバーを選択します。
    4. 「削除」をクリックします。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。

    ノート:

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

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

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

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

    WSM-PM_Cluster

    該当なし

    該当なし

    SOA_Cluster

    UMSJMSSystemResource

    SOAJMSModule

    BPMJMSModule

    UMSJMSServer_soa_scaled_3

    SOAJMSServer_soa_scaled_3

    BPMJMSServer_soa_scaled_3

    ESS_Cluster

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSSystemResource

    jmsResources (グローバル・スコープ)

    UMSJMSServer_osb_scaled_3

    wlsbJMSServer_osb_scaled_3

    BAM_Cluster

    BamPersistenceJmsSystemModule

    BamReportCacheJmsSystemModule

    BamAlertEngineJmsSystemModule

    BAMJMSSystemResource

    BamCQServiceJmsSystemModule

    BamPersistenceJmsServer_bam_scaled_3

    BamReportCacheJmsServer_bam_scaled_3

    BamAlertEngineJmsServer_bam_scaled_3

    BAMJMSServer_bam_scaled_3

    該当なし(既存のサブデプロイメントはスケール・アウト時に変更されません)

    MFT_Cluster

    MFTJMSModule

    MFTJMSServer_mft_scaled_3
    1. 「ツリーの編集」をクリックします。
    2. 「サービス」→「JMSシステム・リソース」に移動します。
    3. 「JMSモジュール」をクリックします。
    4. 「サブ・デプロイメント」をクリックします。
    5. 「サブ・デプロイメント・モジュール」を選択します
    6. 削除したサーバーに作成されたJMSサーバーの選択を解除します。
    7. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  6. BAMクラスタをスケール・インする場合は、Oracle WebLogicリモート・コンソールを使用して、新しいサーバーに作成されるローカル・キューを削除します:
    1. 「ツリーの編集」をクリックします。
    2. 「サービス」→「JMSモジュール」に移動します。
    3. 「JMSモジュール」をクリックします。
    4. BamCQServiceJmsSystemModuleの中をクリックします。
    5. 新しいサーバーに作成されたローカル・キューを削除します。

      • BamCQServiceAlertEngineQueue_auto_3

      • BamCQServiceReportCacheQueue_auto_3

    6. サーバー用に作成された次のサブデプロイメントを削除します:
      BamCQServiceAlertEngineSubdeployment_scaled_3
    7. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  7. Oracle WebLogicリモート・コンソールを使用して、JMSサーバーを削除します:
    1. 「ツリーの編集」をクリックします。
    2. 「サービス」→「JMSサーバー」に移動します。
    3. 新しいサーバーに作成したJMSサーバーを選択します。
    4. 「削除」をクリックします。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  8. Oracle WebLogicリモート・コンソールを使用して、JMS永続ストアを削除します:
    1. 「ツリーの編集」をクリックします。
    2. 「サービス」→「JDBCストア」に移動します。
    3. 新しいサーバーに作成したJDBCストアを選択します。
    4. 「削除」をクリックします。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  9. 削除されたサーバーをホストしていたマシンが他のサーバーで使用されていない場合は、次のステップを実行して削除する必要があります:
    1. 「ツリーの編集」をクリックします。
    2. 「環境」→「マシン」に移動します。
    3. 新しいサーバーに作成したマシンを選択します。
    4. 「削除」をクリックします。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  10. Web層の構成を更新して、削除されたサーバーへの参照を削除します。

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

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

この項では、トポロジをスケール・アップする方法を説明します。

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

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

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

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

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

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

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

スケール・アップ

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

スケール・アップ手順では、サービス移行がデフォルトの移行ポリシー(手動)とは異なる移行ポリシーを使用して構成されている場合、スケーリング対象のWLSクラスタ内の既存のサーバーにダウンタイムが必要です。また、既存の移行可能ターゲットが空の候補サーバー・リストを使用しない場合も、ダウンタイムが発生します(クラスタ内のサーバーの正確なサブセットが候補として使用されます)。空の候補リストを使用することがベスト・プラクティスとなります。これは、クラスタ内のすべてのサーバーが移行の候補であることを意味するためです。WebLogicリモート・コンソールを使用して、各移行可能ターゲットの候補のリストを確認できます:

  1. WebLogicリモート・コンソールでドメインにアクセスします。

  2. リモート・コンソールの左上にある「ツリーの編集」をクリックします。

  3. 左側のナビゲーション・ツリーの「環境」を開きます。

  4. 左側のナビゲーション・ツリーの「移行可能ターゲット」を開きます。

  5. 各移行可能ターゲットをクリックし、「移行」タブの「控えの候補サーバー」リストを確認します。

エンタープライズ・デプロイメント・ガイドに従って環境を作成した場合、これらのリストはデフォルトで空です。クラスタに新しいサーバーを追加すると、サーバーは自動的に移行対象とみなされ、既存のサーバーを再起動する必要はありません。

クラスタの特定のサーバーのみへの移行を制限する場合、候補サーバー・リストは空になりません。クラスタに新しいサーバーを追加する場合は、新しいサーバーを追加するためにサーバーを変更する必要がある場合があります。この場合、スケールアウト・プロセス中に既存のノードを再起動する必要があります。新しいサーバーで移行ポリシーを手動のポリシーから変更すると、クラスタ内の既存メンバーの再起動も求められます。Oracleでは、これらの2つの変更を一括処理し、これらの変更(移行ポリシーと候補リスト)を両方とも完了した後に1回だけ再起動を実行することをお薦めします。

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

  1. Oracle WebLogicリモート・コンソールを使用して、クラスタの最初の管理対象サーバーから新しい管理対象サーバーにクローンを作成します。
    1. 「環境」に移動し、「サーバー」を選択します。
    2. 「作成」をクリックし、「別のサーバーから設定をコピー」で、スケール・アウトするクラスタの最初の管理対象サーバーを選択し、「作成」をクリックします。
    3. 表21-1を参照し、スケール・アウトするクラスタに応じて対応する名前、リスニング・アドレス、SSLリスニング・ポートを設定します。

      ノート:

      すでに作成され同じホストで実行されている管理対象サーバーとバインド競合しないように、ポート値は1ずつ増分します。

    4. 新しい管理対象サーバーをクリックし、「構成」を選択してから「一般」を選択します。
    5. 割り当てられたマシンがSOAHOST1であることを確認します。
    6. サーバーの管理ポートが、クラスタ内の他のサーバーと一致するように更新します。すでに作成され同じホストで実行されている管理対象サーバーとバインド競合しないように、ポート値は1ずつ増分します。

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

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

    WSM-PM_Cluster

    WLS_WSM1

    WLS_WSM3

    SOAHOST1

    7011

    9013

    SOA_Cluster

    WLS_SOA1

    WLS_SOA3

    SOAHOST1

    7005

    9024

    ESS_Cluster

    WLS_ESS1

    WLS_ESS3

    SOAHOST1

    7009

    9016

    OSB_Cluster

    WLS_OSB1

    WLS_OSB3

    SOAHOST1

    8004

    9017

    BAM_Cluster

    WLS_BAM1

    WLS_BAM3

    SOAHOST1

    7007

    9015

    MFT_Cluster

    WLS_MFT1

    WLS_MFT3

    MFTHOST1

    7011

    9024
  2. 「エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更」での説明に従って、新しいサーバーのデプロイメント・ステージング・ディレクトリ名を更新します。
  3. 新しいサーバーのキーストアの場所とSSL構成は、コピーされたサーバー(WLS_SOA1)から引き継がれますが、パスワード(新しいサーバーに対して再度暗号化されるため)と、この新しいサーバーの「サーバーの秘密キーの別名」エントリを再度更新する必要があります。
    1. 「環境」→「サーバー」に移動します。
    2. 新しいサーバーをクリックします。
    3. 「セキュリティ」→「キーストア」に移動します。
    4. 「カスタム・アイデンティティ・キー・ストア・パスフレーズ」および「カスタム信頼キー・ストア・パスフレーズ」を、generate_perdomainCACERTS.shスクリプトに指定されたパスワードで更新します。
    5. 「セキュリティ」の下の「SSL」タブをクリックします。
    6. 「サーバーの秘密キーのパスフレーズ」を、generate_perdomainCACERTS.shスクリプトに指定されたパスワードで更新します
    7. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  4. 新しい管理対象サーバーのTLOG JDBC永続ストアを更新します:
    1. WebLogicリモート・コンソールにログインします。
    2. 「環境」に移動し、左側のナビゲーション・ツリーで「サーバー」リンクを開きます。
    3. 新しいサーバーWLS_XYZnをクリックします。
    4. 「サービス」→「JTA」タブをクリックします。
    5. JDBCで「トランザクション・ログ・ストア」が選択されていることを確認し、「トランザクション・ログ接頭辞」の名前をTLOG_WLS_XYZnに変更します。
      残りのフィールドは、コピーされたサーバー(JDBCストアに使用されるデータソースを含む)から引き継がれます。
    6. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。

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

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

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

    WSM-PM_Cluster

    WLS_WSM3

    デフォルト(ファイル)

    SOA_Cluster

    WLS_SOA3

    JDBC

    ESS_Cluster

    WLS_ESS3

    デフォルト(ファイル)

    OSB_Cluster

    WLS_OSB3

    JDBC

    BAM_Cluster

    WLS_BAM3

    JDBC

    MFT_Cluster

    WLS_MFT3

    JDBC
  5. スケール・アップしようとしているクラスタで自動サービス移行が構成されている場合には、「JTA移行ポリシー」を必要な値に更新します。

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

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

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

    WSM-PM_Cluster

    WLS_WSM3

    手動

    SOA_Cluster

    WLS_SOA3

    障害リカバリ

    ESS_Cluster

    WLS_ESS3

    手動

    OSB_Cluster

    WLS_OSB3

    障害リカバリ

    BAM_Cluster

    WLS_BAM3

    障害リカバリ

    MFT_Cluster

    WLS_MFT3

    障害リカバリ

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

    1. 「環境ツリー」に移動し、「サーバー」を選択します。サーバーのリストから「WLS_XYZn」を選択し、「JTA移行可能」をクリックします。
    2. 表21-11を参照し、スケール・アウトするクラスタに応じて推奨されるJTA移行ポリシーを設定します。
    3. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
    4. クラスタにすでに存在するサーバーで、JTA移行のJTA候補サーバーのリストが空であることを確認します。
      1. 「環境」をクリックし、「サーバー」を開きます。
      2. サーバーを選択します。
      3. コンテキスト・メニューで「JTA移行可能ターゲット」を選択します。
      4. 「控えの候補サーバー」リストをチェックして、リストが空であることを確認します(空のリストは、クラスタ内のすべてのサーバーがJTA候補サーバーであることを示します)。リストはデフォルトで空になるため、変更は不要です。
      5. サーバー・リストが空でない場合は、リストを空白にするように変更する必要があります。または、移行を特定のサーバーのみに制限することを明示的に決定したためにリストが空でない場合は、新しいサーバーに対応するようにプリファレンスに従って変更します。変更を保存してコミットします。既存のサーバーを再起動して、この変更を有効にします。
  6. スケール・アップしようとしているクラスタで自動サービス移行が構成されている場合には、Oracle WebLogicリモート・コンソールを使用して、自動作成されたWLS_XYZn (移行可能)を、推奨の移行ポリシーで更新します。デフォルトでは「サービスの手動での移行のみ」に設定されているためです。

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

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

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

    WSM-PM_Cluster

    該当なし

    該当なし

    SOA_Cluster

    WLS_SOA3 (移行可能)

    障害リカバリ

    ESS_Cluster

    該当なし

    該当なし

    OSB_Cluster

    WLS_OSB3 (移行可能)

    障害リカバリ

    BAM_Cluster

    WLS_BAM3 (移行可能)

    必ず1回

    MFT_Cluster

    WLS_MFT3 (移行可能)

    障害リカバリ
    1. 「環境」→「移行可能ターゲット」に移動します。
    2. 「WLS_XYZ3 (移行可能)」をクリックします。
    3. 「サービス移行ポリシー」を、表に示されている値に変更します。
    4. 選択したサーバーがある場合、「控えの候補サーバー」リストは空のままにしておきます。サーバーが選択されていない場合は、この移行可能ターゲットをクラスタの任意のサーバーに移行できます。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。デフォルトの移行ポリシー(手動)から変更するには、再起動が必要であることに注意してください。
  7. 複数の移行可能ターゲットを使用するコンポーネントの場合、ステップ11に加えて、Oracle WebLogic Serverリモート・コンソールで、クラスタ内の既存のターゲットから設定をコピーして新しい移行可能ターゲットを作成します。前述のステップを使用して、必要となるカスタマイズ可能な設定を行います。
  8. クラスタ内の既存の移行可能サーバーの「控えの候補サーバー」リストが空であることを確認します。構成ウィザードはこれを空のままにするため、デフォルトで空になります。候補リストが空の場合は、クラスタ内のすべてのサーバーが候補であることを意味します。これはベスト・プラクティスです。
    1. 各移行可能サーバーに移動します。
    2. 「移行」タブをクリックし、「控えの候補サーバー」リストを確認します。
    3. 「選択済」サーバー・リストが空であることを確認します。デフォルトでは空になります。
    4. サーバー・リストが空でない場合は、リストを空白にするように変更する必要があります。または、移行を特定のサーバーのみに制限することを明示的に決定したためにリストが空でない場合は、新しいサーバーに対応するようにプリファレンスに従って変更します。「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。既存のサーバーを再起動して、この変更を有効にします。
  9. JMSサーバーに必要な永続ストアを作成します。
    1. WebLogicリモート・コンソールにサインインし、「サービス」に移動して、「JDBCストア」を選択します。
    2. 「新規」をクリックして、「JDBCストアの作成」を選択します。

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

    ノート:

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

    たとえば:
    UMSJMSJDBCStore_auto_1 — soa_1
UMSJMSJDBCStore_auto_2 — soa_2
BPMJMSJDBCStore_auto_1 — soa_3
BPMJMSJDBCStore_auto_2 — soa_4
SOAJMSJDBCStore_auto_1 — soa_5
SOAJMSJDBCStore_auto_2 — soa_6

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

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

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

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

    WSM-PM_Cluster

    該当なし

    該当なし

    該当なし

    該当なし

    SOA_Cluster

    UMSJMSJDBCStore_soa_scaled_3

    soaums_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_SOA3 (移行可能)

    SOAJMSJDBCStore_ soa_scaled_3

    soajms_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_SOA3 (移行可能)

    BPMJMSJDBCStore_ soa_scaled_3

    soabpm_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_SOA3 (移行可能)

    ESS_Cluster

    該当なし

    該当なし

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSJDBCStore_osb_scaled_3

    osbums_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_OSB3 (移行可能)

    OSBJMSJDBCStore_osb_scaled_3

    osbjms_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_OSB3 (移行可能)

    BAM_Cluster

    UMSJMSJDBCStore_bam_scaled_3

    bamums_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamPersistenceJmsJDBCStore_bam_scaled_3

    bamP_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamReportCacheJmsJDBCStore_bam_scaled_3

    bamR_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamAlertEngineJmsJDBCStore_bam_scaled_3

    bamA_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamJmsJDBCStore_bam_scaled_3

    bamjms_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3_bam-exactly-once (移行可能)

    BamCQServiceJmsJDBCStore_bam_scaled_3

    bamC_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_BAM3*

    MFT_Cluster

    MFTJMSJDBCStore_mft_scaled_3

    mftjms_scaled_3

    WLSRuntimeSchemaDataSource

    WLS_MFT3 (移行可能)

    ノート:

    (*) BamCQServiceJmsServersはBAM CQService (連続検索エンジン)のローカル・キューをホストし、ローカル専用です。意図的に、移行可能ターゲットではなく、WebLogicサーバーを直接のターゲットとしています。
  10. 新しい管理対象サーバーに必要なJMSサーバーを作成します。
    1. WebLogicリモート・コンソールに移動します。「ツリーの編集」で、「サービス」を選択し、「JMSサーバー」をクリックします。
    2. 「新規」をクリックします。

    次の表を参照して、必要な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 (移行可能)

    ESS_Cluster

    該当なし

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSServer_osb_scaled_3

    UMSJMSJDBCStore_osb_scaled_3

    WLS_OSB3 (移行可能)

    wlsbJMSServer_osb_scaled_3

    OSBJMSJDBCStore_osb_scaled_3

    WLS_OSB3 (移行可能)

    BAM_Cluster

    UMSJMSServer_bam_scaled_3

    UMSJMSJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BamPersistenceJmsServer_bam_scaled_3

    BamPersistenceJmsJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BamReportCacheJmsServer_bam_scaled_3

    BamReportCacheJmsJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BamAlertEngineJmsServer_bam_scaled_3

    BamAlertEngineJmsJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BAMJMSServer_bam_scaled_3

    BamJmsJDBCStore_bam_scaled_3

    WLS_BAM3_bam-exactly-once (移行可能)

    BamCQServiceJmsServer_bam_scaled_3

    BamCQServiceJmsJDBCStore_bam_scaled_3

    WLS_BAM3*

    MFT_Cluster

    MFTJMSServer_mft_scaled_3

    MFTJMSJDBCStore_mft_scaled_3

    WLS_MFT3 (移行可能)

    ノート:

    (*) BamCQServiceJmsServersはBAM CQService (連続検索エンジン)のローカル・キューをホストし、ローカル専用です。意図的に、移行可能ターゲットではなく、WebLogicサーバーを直接のターゲットとしています。
  11. JMSモジュール(適用可能な場合)のサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
    1. 「サービス」を開き、「JMSモジュール」を選択し、JMSモジュールをクリックします。たとえば、BPMJMSModuleです。
    2. 「サブ・デプロイメント」を開き、対応するデプロイメントを選択してターゲットを更新します。次の表を参照して、スケール・アウトしようとしているクラスタに応じて、更新するJMSモジュールを識別します。

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

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

      WSM-PM_Cluster

      該当なし

      該当なし

      SOA_Cluster

      UMSJMSSystemResource *

      UMSJMSServer_soa_scaled_3

      SOAJMSModule

      SOAJMSServer_soa_scaled_3

      BPMJMSModule

      BPMJMSServer_soa_scaled_3

      ESS_Cluster

      該当なし

      該当なし

      OSB_Cluster

      UMSJMSSystemResource *

      UMSJMSServer_osb_scaled_3

      jmsResources (グローバル・スコープ)

      wlsbJMSServer_osb_scaled_3

      BAM_Cluster

      BamPersistenceJmsSystemModule

      BamPersistenceJmsServer_bam_scaled_3

      BamReportCacheJmsSystemModule

      BamReportCacheJmsServer_bam_scaled_3

      BamAlertEngineJmsSystemModule

      BamAlertEngineJmsServer_bam_scaled_3

      BAMJMSSystemResource

      BAMJMSServer_bam_scaled_3

      BamCQServiceJmsSystemModule

      該当なし(既存のサブデプロイメントは更新しません。新しいサーバーの新しいサブデプロイメントは次のステップで作成されます)

      UMSJMSSystemResource *

      UMSJMSServer_bam_scaled_3 *

      MFT_Cluster

      MFTJMSModule

      MFTJMSServer_mft_scaled_3

      (*)一部のモジュール(UMSJMSystemResource)は、複数のクラスタをターゲットにしている場合があります。それぞれのケースで適切なサブデプロイメントを更新していることを確認します。

    3. 対応するJMSサーバーを既存のサブデプロイメントに追加します。

      ノート:

      このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。
    4. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  12. BAMクラスタをスケール・アウトする場合は、BamCQServiceJmsSystemModuleモジュールに、新しいサーバーの追加リソース(サブデプロイメントおよびローカル・キュー)を作成する必要があります。これらを作成するには、次のステップに従います。
    1. WebLogicリモート・コンソールに移動して、「ツリーの編集」をクリックし、「環境」→「サービス」を選択します。
    2. 「JMSシステム・リソース」をクリックし、「BamCQServiceJmsSystemModule」を選択します。
    3. 「ターゲット」をクリックします。
    4. ターゲットにWLS_BAM3を追加して、「保存」をクリックします。
    5. BamCQServiceJmsSystemModule JMSモジュールに、BamCQServiceAlertEngineSubdeployment_scaled_3という名前の新しいサブデプロイメントを作成します。次に、このサブデプロイメントのターゲットとしてBamCQServiceJmsServer_bam_scaled_3を選択します。

      表21-14 ローカル・キューの追加サブデプロイメントを作成するときの情報

      サブデプロイメント名 サブデプロイメント・ターゲット

      BamCQServiceAlertEngineSubdeployment_scaled_3

      BamCQServiceJmsServer_bam_scaled_3
    6. 「モジュール」の下の「キュー」を選択し、「新規」をクリックします。
    7. BamCQServiceAlertEngineQueue_auto_3という名前を付けます。
    8. 「作成」をクリックします。
    9. 新しく選択したキューBamCQServiceAlertEngineQueue_auto_3の中をクリックします。
    10. 「一般」タブを選択します。
    11. 「ローカルJNDI名」をqueue/oracle.beam.cqservice.mdbs.alertengineに設定します。
    12. 「サブ・デプロイメント名」をBamCQServiceAlertEngineSubdeployment_scaled_3に設定します。
    13. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
    14. 同じステップを繰り返し、表21-15の情報を使用してもう1つのキューBamCQServiceReportCacheQueue_auto_3を作成します。
    15. 完了すると、次の新しいローカル・キューを使用できるようになります。

      表21-15 ローカル・キューを作成するときの情報

      名前 タイプ ローカルJNDI名 サブデプロイメント

      BamCQServiceAlertE ngineQueue_auto_3

      キュー

      queue/ oracle.beam.cqservice .mdbs.alertengine

      BamCQServiceAlertEngineSubdeployment_scaled_3

      BamCQServiceReportCacheQueue_auto_3

      キュー

      queue/oracle.beam.cqservice.mdbs.reportcache

      BamCQServiceAlertEngineSubdeployment_scaled_3
  13. 新しい管理対象サーバーを起動します。
  14. OSB_Clusterをスケール・アップする場合:

    管理サーバーを再起動し、Service Busダッシュボードで新しいサーバーを確認します。

  15. MFT_Clusterをスケール・アップする場合:

    新しいサーバーでは、デフォルトのSFTP/FTPポートが使用されます。デフォルトを使用しない場合は、「SFTPポートの構成」で説明されるステップに従って、SFTPサーバーのポートを構成します。スケール・アップする場合、新しいサーバーには、同じマシンの既存のサーバーと競合しない別のSFTP/FTPポートを使用してください。

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

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

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

      <Location /soa-infra>
  WLSRequest ON
  WebLogicCluster SOAHOST1:7004,SOAHOST2:7004,SOAHOST2:7005
</Location>

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

クラスタのスケール・アップの確認

スケール・アウトを実行してサーバーを起動したら、次のような確認に進んでください。
  1. Webアプリケーションへのルーティングが正しいことを確認します。

    たとえば:

    1. ロード・バランサ上のアプリケーションにアクセスします。
      https://soa.example.com/soa-infra
    2. 新しいサーバーでもアクティビティがあることを確認します。

      リモート・コンソールで、「モニタリング・ツリー」に移動し、「デプロイメント」→「アプリケーション・ランタイム・データ」→「soa-infra」に移動します。

    3. 新しいサーバーでWebセッションが作成されることも確認できます。

      • リモート・コンソールで、「モニタリング・ツリー」に移動し、「デプロイメント」→「アプリケーション・ランタイム・データ」→「soa-infra」に移動します。

      • 「コンポーネント・ランタイム」に移動し、「WLS_SOA3_/soa-infra」をクリックします。

      • セッションがあるかどうかを確認します。

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

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

      WSM-PM_Cluster

      https://soainternal.example.com:444/wsm-pm

      wsm-pm > wsm-pm

      SOA_Cluster

      https://soa.example.com/soa-infra

      soa-infra > soa-infra

      ESS_Cluster

      https://soa.example.com/ESSHealthCheck

      ESSHealthCheck

      OSB_Cluster

      https://osb.example.com/sbinspection.wsil

      Service Bus WSIL

      MFT_Cluster

      https://mft.example.com/mftconsole

      mftconsole

      BAM_Cluster

      https://soa.example.com/bam/composer

      BamComposer > /bam/composer
  2. 3つのサーバーで、JMSメッセージが宛先に対して生成および使用されていることと、宛先から生成および使用されていることを確認します。
    1. リモート・コンソールで、「モニタリング・ツリー」に移動します。
    2. 「ダッシュボード」→「JMS宛先」に移動します。
  3. 「自動サービス移行の検証」での説明に従って、サービスの移行を確認します。

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

トポロジのスケール・ダウン

この項では、トポロジをスケール・ダウンする方法を説明します。

トポロジをスケール・ダウンするには:
  1. JMSのデータ損失なしでクラスタをスケール・インするには、SOAサーバーでのJMSメッセージの管理で説明されているステップを実行します。

    それらのステップが完了したら、スケール・インの手順を続行します。

  2. 保留中のJTAを確認します。サーバーを停止する前に、削除するサーバーにアクティブなJTAトランザクションがあるかどうか確認します。WebLogicリモート・コンソールに移動し、「モニタリング・ツリー」で「サーバー」→「<server name>」→「サービス」→「トランザクション」→「JTAランタイム」をクリックします。

    ノート:

    JTAの「停止リカバリ」ポリシーを使用している場合は、サーバーを停止した後、別のサーバーでトランザクションが回復されます。

  3. 「作業完了時」オプションを使用して、サーバーを停止します。

    ノート:

    サーバーにアクティブなHTTPセッションまたは長いトランザクションがある場合、この操作に長い時間がかかることがあります。正常な停止の詳細は、Oracle WebLogic Serverサーバーの起動と停止の管理のサーバーのライフサイクル・コマンドの使用を参照してください。

  4. Oracle WebLogic Serverリモート・コンソールを使用して、新しいサーバーを削除します:
    1. 「ツリーの編集」をクリックします。
    2. 「環境」→「サーバー」に移動します。
    3. 削除するサーバーを選択します。
    4. 「削除」をクリックします。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。

    ノート:

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

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

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

    表21-16 各クラスタのモジュールの識別

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

    WSM-PM_Cluster

    該当なし

    該当なし

    SOA_Cluster

    UMSJMSSystemResource

    SOAJMSModule

    BPMJMSModule

    UMSJMSServer_soa_scaled_3

    SOAJMSServer_soa_scaled_3

    BPMJMSServer_soa_scaled_3

    ESS_Cluster

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSSystemResource

    jmsResources (グローバル・スコープ)

    UMSJMSServer_osb_scaled_3

    wlsbJMSServer_osb_scaled_3

    BAM_Cluster

    BamPersistenceJmsSystemModule

    BamReportCacheJmsSystemModule

    BamAlertEngineJmsSystemModule

    BAMJMSSystemResource

    BamCQServiceJmsSystemModule

    BamPersistenceJmsServer_bam_scaled_3

    BamReportCacheJmsServer_bam_scaled_3

    BamAlertEngineJmsServer_bam_scaled_3

    BAMJMSServer_bam_scaled_3

    該当なし(既存のサブデプロイメントはスケール・アップ時に変更されません)

    MFT_Cluster

    MFTJMSModule

    MFTJMSServer_mft_scaled_3
    1. 「ツリーの編集」をクリックします。
    2. 「サービス」→「JMSシステム・リソース」に移動します。
    3. 「JMSモジュール」をクリックします。
    4. 「サブ・デプロイメント」をクリックします。
    5. 「サブ・デプロイメント・モジュール」を選択します。
    6. 削除したサーバーに作成されたJMSサーバーの選択を解除します。
    7. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  6. BAMクラスタをスケール・インする場合は、Oracle WebLogicリモート・コンソールを使用して、新しいサーバーに作成されるローカル・キューを削除します:
    1. 「ツリーの編集」をクリックします。
    2. 「サービス」→「JMSモジュール」に移動します。
    3. 「JMSモジュール」をクリックします。
    4. 「BamCQServiceJmsSystemModule」をクリックします。
    5. 新しいサーバーに作成されたローカル・キューを削除します。
      BamCQServiceAlertEngineQueue_auto_3
      BamCQServiceReportCacheQueue_auto_3
    6. サーバー用に作成されたサブデプロイメントを削除します:
      BamCQServiceAlertEngineSubdeployment_scaled_3
    7. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  7. Oracle WebLogicリモート・コンソールを使用して、JMSサーバーを削除します:
    1. 「ツリーの編集」をクリックします。
    2. 「サービス」→「JMSサーバー」に移動します。
    3. 新しいサーバーに作成したJMSサーバーを選択します。
    4. 「削除」をクリックします。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  8. Oracle WebLogic Serverリモート・コンソールを使用して、JMS永続ストアを削除します:
    1. 「ツリーの編集」をクリックします。
    2. 「サービス」→「JDBCストア」に移動します。
    3. 新しいサーバーに作成したJDBCストアを選択します。
    4. 「削除」をクリックします。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。
  9. Web層の構成を更新して、削除されたサーバーへの参照を削除します。
  10. 削除されたサーバーをホストしていたマシンが他のサーバーで使用されていない場合は、削除することもできます。
    1. 「ツリーの編集」をクリックします。
    2. 「環境」→「マシン」に移動します。
    3. 新しいサーバーに作成したマシンを選択します。
    4. 「削除」をクリックします。
    5. 「ショッピング・カート」の「保存」および「変更のコミット」をクリックします。

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