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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 新しいノードが、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などになります。

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

  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. Oracle WebLogic管理コンソールにログインして新しいマシンを作成します。
    1. 「環境」→「マシン」に移動します。
    2. 「新規」をクリックして、新しいノードに新しいマシンを作成します。
    3. 「名前」をSOAHOSTn (またはMFTHOSTnかBAMHOSTn)に設定します。
    4. 「マシンのOS」を「Linux」に設定します。
    5. 「次」をクリックします。
    6. 「タイプ」を「プレーン」に設定します。
    7. 「リスニング・アドレス」をSOAHOSTnに設定します。
    8. 「終了」をクリックし、「変更のアクティブ化」をクリックします。
  6. Oracle WebLogic Server管理コンソールを使用して、クラスタの最初の管理対象サーバーから新しい管理対象サーバーにクローンを作成します。
    1. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
    2. 「環境」→「サーバー」に移動します。
    3. スケール・アウトするクラスタの最初の管理対象サーバーを選択し、「クローン」をクリックします。
    4. 表24-1を参照し、スケール・アウトするクラスタに応じて対応する名前、リスニング・アドレス、リスニング・ポートを設定します。
    5. 新しい管理対象サーバーをクリックし、「構成」→「一般」の順にクリックします。
    6. 「マシン」をSOAHOST1からSOAHOSTnに更新します。
    7. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

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

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

    WSM-PM_Cluster

    WLS_WSM1

    WLS_WSM3

    SOAHOST3

    7010

    SOA_Cluster

    WLS_SOA1

    WLS_SOA3

    SOAHOST3

    8001

    ESS_Cluster

    WLS_ESS1

    WLS_ESS3

    SOAHOST3

    8021

    OSB_Cluster

    WLS_OSB1

    WLS_OSB3

    SOAHOST3

    8011

    BAM_Cluster

    WLS_BAM1

    WLS_BAM3

    SOAHOST3

    9001

    MFT_Cluster

    WLS_MFT1

    WLS_MFT3

    MFTHOST3

    7500

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

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

    表24-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
  10. スケール・アウトしようとしているクラスタで自動サービス移行が構成されている場合には、「JTA移行ポリシー」を必要な値に更新します。
    1. 「環境」→「サーバー」→「WLS_XYZn」→「構成」→「移行」の順に移動します。
    2. 表24-3を参照し、スケール・アウトするクラスタに応じてJTA移行ポリシーを設定します。

      表24-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. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
    4. 明日にすでに存在する残りのサーバーについては、JTA移行に新しいサーバーが含まれるように、「JTA候補サーバー」のリストを更新します。

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

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

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

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

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

    表24-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. 「ロックして編集」をクリックします。
    3. Click WLS_XYZ3 (移行可能)
    4. 「構成」タブ→「移行」に移動します。
    5. 「サービス移行ポリシー」を、表に示されている値に変更します。
    6. 選択したサーバーがある場合、「控えの候補サーバー」リストは空のままにしておきます。サーバーが選択されていない場合は、この移行可能ターゲットをクラスタの任意のサーバーに移行できます。
    7. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  12. 複数の移行可能ターゲットを使用しているコンポーネントについては、ステップ11に加えて、移行可能ターゲットをもう1つ作成する必要があります。例として、ここではBAMを使用します。Oracle WebLogic Server管理コンソールを使用して、WLS_BAM3 (移行可能)のクローンを新しい移行可能ターゲットに作成します。
    1. 「環境」→「クラスタ」→移行可能なサーバーに移動します。
    2. 「ロックして編集」をクリックします。
    3. WLS_BAM3 (移行可能)をクリックして、「クローン」をクリックします。
    4. 新しいターゲットにWLS_BAM3_bam-exactly-once (migratable)という名前を付けます。
    5. 新しい移行可能サーバーをクリックします。
    6. 「構成」タブ→「移行」に移動します。
    7. 設定されていない場合には、「サービス移行ポリシー」を「必ず1回のサービスを自動移行」に変更します。
    8. 「控えの候補サーバー」リストは空のままにしておきます。サーバーが選択されていない場合は、この移行可能ターゲットをクラスタの任意のサーバーに移行できます。
    9. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  13. スケーリングしているクラスタの既存の移行可能サーバーで、「控えの候補サーバー」リストを更新します。デフォルトでは、WLS_XYZ1サーバーとWLS_XYZ2サーバーしか事前に移入されていないためです。
    1. 各移行可能サーバーに移動します。
    2. 「構成」タブ→「移行」→「控えの候補サーバー」に移動します。

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

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

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

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

      WSM-PM_Cluster

      該当なし

      空のままにします

      SOA_Cluster

      WLS_SOA1 (移行可能)

      WLS_SOA2 (移行可能)

      空のままにします

      ESS_Cluster

      該当なし

      空のままにします

      OSB_Cluster

      WLS_OSB1 (移行可能)

      WLS_OSB2 (移行可能)

      空のままにします

      BAM_Cluster

      WLS_BAM1 (移行可能)

      WLS_BAM2 (移行可能)

      WLS_BAM1_bam-exactly-once (移行可能)

      WLS_BAM2_bam-exactly-once (移行可能)

      空のままにします

      MFT_Cluster

      WLS_MFT1 (移行可能)

      WLS_MFT2 (移行可能)

      空のままにします
    3. 「保存」をクリックし、「変更のアクティブ化」をクリックします。この変更を有効にするためにサーバーを再起動する必要がありますが、必要な構成変更をすべて完了した後に、再起動を1回だけ実行するようにできます。
  14. JMSサーバーに必要な永続ストアを作成します。
    1. WebLogicコンソールにログインし、「サービス」→「永続ストア」に移動します。
    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タグで修飾されます。ここに、その例を示しています。

    表24-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 (移行可能)

    ESS_Cluster

    該当なし

    該当なし

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSJDBCStore_osb_scaled_3

    osbums_scaled_3

    WLSSchemaDataSourc

    WLS_OSB3 (移行可能)

    OSBJMSJDBCStore_osb_scaled_3

    osbjms_scaled_3

    WLSSchemaDataSourc

    WLS_OSB3 (移行可能)

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

    osbprocmon_scaled_3

    WLSSchemaDataSource

    WLS_OSB3 (移行可能)

    BAM_Cluster

    UMSJMSJDBCStore_bam_scaled_3

    bamums_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamPersistenceJmsJDBCStore_bam_scaled_3

    bamP_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamReportCacheJmsJDBCStore_bam_scaled_3

    bamR_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamAlertEngineJmsJDBCStore_bam_scaled_3

    bamA_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamJmsJDBCStore_bam_scaled_3

    bamjms_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamCQServiceJmsJDBCStore_bam_scaled_3

    bamC_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3*

    MFT_Cluster

    MFTJMSJDBCStore_mft_scaled_3

    mftjms_scaled_3

    WLSSchemaDataSourc

    WLS_MFT3 (移行可能)

    注意:

    (*) BamCQServiceJmsServersはBAM CQService (連続検索エンジン)のローカル・キューをホストし、ローカル専用です。意図的に、移行可能ターゲットではなく、WebLogicサーバーを直接のターゲットとしています。
  15. 新しい管理対象サーバーに必要な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 (移行可能)

    ESS_Cluster

    該当なし

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSServer_osb_scaled_3

    UMSJMSJDBCStore_osb_scaled_3

    WLS_OSB3 (移行可能)

    wlsbJMSServer_osb_scaled_3

    OSBJMSJDBCStore_osb_scaled_3

    WLS_OSB3 (移行可能)

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

    ProcMonJMSJDBCStore_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サーバーを直接のターゲットとしています。

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

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

      表24-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

      ESS_Cluster

      該当なし

      該当なし

      OSB_Cluster

      UMSJMSSystemResource *

      UMSJMSServer_osb_scaled_3

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

      wlsbJMSServer_osb_scaled_3

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

      ProcMonJMSServer_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、ProcMonJMSModule)は、複数のクラスタをターゲットにしている場合があります。それぞれのケースで適切なサブデプロイメントを更新していることを確認します。
    3. 「構成」→「サブデプロイメント」に移動します。
    4. 対応するJMSサーバーを既存のサブデプロイメントに追加します。

      注意:

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

    5. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  17. BAMクラスタをスケール・アウトする場合は、BamCQServiceJmsSystemModuleモジュールで、新しいサーバーのローカル・キューを作成する必要があります。これらを作成するには、次のステップに従います。
    1. WebLogicコンソールから、「サービス」→「メッセージング」→「JMSモジュール」に移動します。
    2. 「ロックして編集」をクリックします。
    3. BamCQServiceJmsSystemModuleの中をクリックします。
    4. 「ターゲット」をクリックします。
    5. ターゲットにWLS_BAM3を追加して、「保存」をクリックします。
    6. 「新規」をクリックします。
    7. 「キュー」を選択し、「次へ」をクリックします。
    8. 名前をBamCQServiceAlertEngineQueue_auto_3に変え、「次」をクリックします。
    9. BamCQServiceJmsServer_bam_scaled_3をターゲットにして新しいサブデプロイメントを作成し、それをキューに選択します。
    10. 「終了」をクリックします。
    11. 新しく選択したキューBamCQServiceAlertEngineQueue_auto_3の中をクリックします。
    12. 「構成」→「全般」→「詳細」タブに移動します。
    13. 「ローカルJNDI名」をqueue/oracle.beam.cqservice.mdbs.alertengineに設定します。
    14. 「保存」をクリックします。
    15. 同じステップを繰り返し、表24-8の情報を使用してもう1つのキューBamCQServiceReportCacheQueue_auto_3を作成します。
    16. 完了すると、新しいローカル・キューを使用できるようになります。

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

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

      BamCQServiceAlertEngineQueue_auto_3

      キュー

      queue/oracle.beam.cqservice.mdbs.alertengine

      BamCQServiceJmsServer_auto_3

      BamCQServiceReportCacheQueue_auto_3

      キュー

      queue/oracle.beam.cqservice.mdbs.reportcache

      BamCQServiceJmsServer_auto_3
    17. 「変更のアクティブ化」をクリックします。
  18. 前の変更を有効にするために、すべてのサーバー(新しく作成したサーバーを除く)を再起動します。ローリング形式で再起動すると、ダウンタイムをなくすことができます。
  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
          -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は、テンプレート・ファイルに格納されるテンプレート・データに割り当てられるラベルです。

  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. SOA_Clusterをスケール・アウトする場合:
    1. BPM Webフォームを使用する場合は、「WebフォームのSOA BPMサーバーの更新」での説明に従って、BPM向けのstartWebLogic.shのカスタマイズを更新し、新しいノードを追加します。
    2. 「Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加」での説明に従って、setDomain.shを更新し、appTrustKeyStore.jksを追加します。
  22. OSB_Clusterをスケール・アウトする場合:
    1. 管理サーバーを再起動し、Service Busダッシュボードで新しいサーバーを確認します。
  23. MFT_Clusterをスケール・アウトする場合:
    1. 新しいサーバーでは、デフォルトのSFTP/FTPポートが使用されます。デフォルトを使用しない場合は、「SFTPポートの構成」での説明に従って、SFTPサーバーのポートを構成します。
  24. 新しいホストでノード・マネージャを起動します。
    cd $NM_HOME
nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &
  25. 新しい管理対象サーバーを起動します。
  26. 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. ロード・バランサ上のアプリケーションにアクセスします。
      soa.example.com/soa-infra
    2. 新しいサーバーでもアクティビティがあることを確認します。
      「クラスタ」→「デプロイメント」→「soa-infra」→「モニタリング」→「ワークロード」の順に移動します。
    3. 新しいサーバーでWebセッションが作成されることも確認できます。

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

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

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

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

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

      WSM-PM_Cluster

      http://soainternal.example.com/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. 「JMSサーバー」に移動します。
    2. 「JMSサーバー」→「モニタリング」の順にクリックします。
  3. 「静的クラスタでの自動サービス移行の検証」での説明に従って、サービスの移行を確認します。

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

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

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

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

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

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

  • 新しいノードが、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などになります。

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

  1. 新しいノードで、表7-4に従って、既存のFMWホーム(NFS Volume1)、共有構成(NFS Volume 3)およびランタイム(NFS Volume 4)をマウントします。
  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. Oracle WebLogic管理コンソールにログインして、新しいノードの新しいマシンを作成します。
  6. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
  7. Oracle WebLogic Server管理コンソールを使用し、新しい管理対象サーバーを含むように動的クラスタを増やします。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「クラスタ」に移動します。
    3. スケール・アウトするクラスタを選択します。
    4. 「構成」→「サーバー」に移動します。
    5. 「動的クラスタ・サイズ」を3に設定します。デフォルトでは、クラスタ・サイズは2です。

      注意:

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

  8. 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
          -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. SOA_Clusterをスケール・アウトする場合:
    1. BPM Webフォームを使用する場合は、「WebフォームのSOA BPMサーバーの更新」での説明に従って、BPM向けのstartWebLogic.shのカスタマイズを更新し、新しいノードを追加します。
    2. 「Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加」での説明に従って、setDomain.shを更新し、appTrustKeyStore.jksを追加します。
  11. OSB_Clusterをスケール・アウトする場合:
    1. 管理サーバーを再起動し、Service Busダッシュボードで新しいサーバーを確認します。
  12. MFT_Clusterをスケール・アウトする場合:
    1. 新しいサーバーでは、デフォルトのSFTP/FTPポートが使用されます。デフォルトを使用しない場合は、「SFTPポートの構成」での説明に従って、SFTPサーバーのポートを構成します。
  13. 新しいホストでノード・マネージャを起動します。
    cd $NM_HOME
nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &
  14. 新しい管理対象サーバーを起動します。
  15. Web層の構成を更新してこの新しいサーバーを追加します。
    1. OTDを使用している場合は、「必要なオリジン・サーバー・プールの作成」で説明されているように、Enterprise Managerにログインして対応するオリジン・プールを更新し、新しいサーバーをプールに追加します。
    2. OHSを使用している場合は、新しいサーバーをOHSに追加する必要はありません。

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

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

      例:

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

    例:

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

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

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

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

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

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

      WSM-PM_Cluster

      http://soainternal.example.com/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. 「JMSサーバー」に移動します。
    2. 「JMSサーバー」→「モニタリング」の順にクリックします。
  3. 「動的クラスタでの自動サービス移行の検証」での説明に従って、サービスの移行を確認します。

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

トポロジのスケール・インでは、新しいホストに追加された管理対象サーバーを削除します。

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

静的クラスタのトポロジのスケール・イン

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

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

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

    注意:

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

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

    注意:

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

  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

    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. 削除したサーバーに作成されたJMSサーバーの選択を解除します。
    6. 「保存」をクリックします。
    7. 「変更のアクティブ化」をクリックします。
  7. BAMクラスタをスケール・インする場合は、Oracle WebLogic Server管理コンソールを使用して、新しいサーバーに作成されるローカル・キューを削除します
    1. 「ロックして編集」をクリックします。
    2. WebLogicコンソールから、「サービス」→「メッセージング」→「JMSモジュール」に移動します。
    3. BamCQServiceJmsSystemModuleの中をクリックします。
    4. 新しいサーバーに作成されたローカル・キューを削除します。

      • BamCQServiceAlertEngineQueue_auto_3

      • BamCQServiceReportCacheQueue_auto_3

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

親トピック: トポロジのスケール・イン

動的クラスタのトポロジのスケール・イン

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

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

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

    注意:

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

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

    注意:

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

    • 動的クラスタ内の、削除するサーバーで実行されている、移行ポリシーとして「常時」を使用するJMSサーバーは、この時点でクラスタ内の別のメンバーに移行されます(そのサーバーは単に停止されています)。それらをホストするメンバーを次に再起動したときは、これらのJMSサーバーは起動されません。これは、それらの優先サーバーがクラスタ内に存在しなくなったためです。ただし、メッセージが失われた可能性があるため、この合間に新しいメッセージを取得したかどうかを確認する必要があります。メッセージを保持するには、クラスタ内のサーバーを再起動する前に、これらのJMSサーバーからのメッセージの生成およびエクスポートを一時停止します。

  4. Oracle WebLogic Server管理コンソールを使用して、動的クラスタを減らします。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「クラスタ」に移動します。
    3. スケール・インするクラスタを選択します。
    4. 「構成」→「サーバー」に移動します。
    5. 「動的クラスタ・サイズ」を2に設定します。
  5. OSBを使用している場合は、管理サーバーを再起動します。

親トピック: トポロジのスケール・イン

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

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

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

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

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

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

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

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などになります。

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

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

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

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

    WSM-PM_Cluster

    WLS_WSM1

    WLS_WSM3

    SOAHOST1

    7011

    SOA_Cluster

    WLS_SOA1

    WLS_SOA3

    SOAHOST1

    8002

    ESS_Cluster

    WLS_ESS1

    WLS_ESS3

    SOAHOST1

    8022

    OSB_Cluster

    WLS_OSB1

    WLS_OSB3

    SOAHOST1

    8012

    BAM_Cluster

    WLS_BAM1

    WLS_BAM3

    SOAHOST1

    9002

    MFT_Cluster

    WLS_MFT1

    WLS_MFT3

    MFTHOST1

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

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

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

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

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

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

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

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

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

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

    表24-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. 「ロックして編集」をクリックします。
    3. Click WLS_XYZ3 (移行可能)
    4. 「構成」タブから、「移行」に移動します。
    5. 「サービス移行ポリシー」を、表に示されている値に変更します。
    6. 選択したサーバーがある場合、「控えの候補サーバー」リストは空のままにしておきます。サーバーが選択されていない場合は、この移行可能ターゲットをクラスタの任意のサーバーに移行できます。
    7. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  7. BAMのように、複数の移行可能ターゲットを使用しているコンポーネントについては、ステップ6に加えて、移行可能ターゲットをもう1つ作成します。例として、ここではBAMを使用します。Oracle WebLogic Server管理コンソールを使用して、WLS_BAM3 (移行可能)のクローンを新しい移行可能ターゲットに作成します。
    1. 「環境」→「クラスタ」→移行可能なサーバーに移動します。
    2. 「ロックして編集」をクリックします。
    3. WLS_BAM3 (移行可能)をクリックして、「クローン」をクリックします。
    4. 新しいターゲットにWLS_BAM3_bam-exactly-once (migratable)という名前を付けます。
    5. 新しい移行可能サーバーをクリックします。
    6. 「構成」タブに移動して、「移行」を選択します。
    7. 設定されていない場合には、「サービス移行ポリシー」を「必ず1回のサービスを自動移行」に変更します。
    8. 「控えの候補サーバー」リストは空のままにしておきます。サーバーが選択されていない場合は、この移行可能ターゲットをクラスタの任意のサーバーに移行できます。
    9. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  8. スケーリングしているクラスタの既存の移行可能サーバーで、「控えの候補サーバー」リストを更新します。デフォルトでは、WLS_XYZ1サーバーとWLS_XYZ2サーバーしか事前に移入されていないためです。

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

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

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

    WSM-PM_Cluster

    該当なし

    空のままにします

    SOA_Cluster

    WLS_SOA1 (移行可能)

    WLS_SOA2 (移行可能)

    空のままにします

    ESS_Cluster

    該当なし

    空のままにします

    OSB_Cluster

    WLS_OSB1 (移行可能)

    WLS_OSB2 (移行可能)

    空のままにします

    BAM_Cluster

    WLS_BAM1 (移行可能)

    WLS_BAM2 (移行可能)

    WLS_BAM1_bam-exactly-once (移行可能)

    WLS_BAM2_bam-exactly-once (移行可能)

    空のままにします

    MFT_Cluster

    WLS_MFT1 (移行可能)

    WLS_MFT2 (移行可能)

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

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

    3. 「保存」をクリックして、「変更のアクティブ化」をクリックしますこの変更を有効にするためにサーバーを再起動する必要がありますが、必要な構成変更をすべて完了した後に、再起動を1回だけ実行するようにできます。
  9. JMSサーバーに必要な永続ストアを作成します。
    1. WebLogicコンソールにサインインし、「サービス」→「永続ストア」に移動します。
    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タグで修飾されます。ここに、その例を示しています。

    表24-14 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 (移行可能)

    ESS_Cluster

    該当なし

    該当なし

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSJDBCStore_osb_scaled_3

    osbums_scaled_3

    WLSSchemaDataSourc

    WLS_OSB3 (移行可能)

    OSBJMSJDBCStore_osb_scaled_3

    osbjms_scaled_3

    WLSSchemaDataSourc

    WLS_OSB3 (移行可能)

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

    osbprocmon_scaled_3

    WLSSchemaDataSource

    WLS_OSB3 (移行可能)

    BAM_Cluster

    UMSJMSJDBCStore_bam_scaled_3

    bamums_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamPersistenceJmsJDBCStore_bam_scaled_3

    bamP_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamReportCacheJmsJDBCStore_bam_scaled_3

    bamR_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamAlertEngineJmsJDBCStore_bam_scaled_3

    bamA_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamJmsJDBCStore_bam_scaled_3

    bamjms_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3_bam-exactly-once (移行可能)

    BamCQServiceJmsJDBCStore_bam_scaled_3

    bamC_scaled_3

    WLSSchemaDataSourc

    WLS_BAM3*

    MFT_Cluster

    MFTJMSJDBCStore_mft_scaled_3

    mftjms_scaled_3

    WLSSchemaDataSourc

    WLS_MFT3 (移行可能)

    注意:

    (*) BamCQServiceJmsServersはBAM CQService (連続検索エンジン)のローカル・キューをホストし、ローカル専用です。意図的に、移行可能ターゲットではなく、WebLogicサーバーを直接のターゲットとしています。
  10. 新しい管理対象サーバーに必要な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 (移行可能)

    ESS_Cluster

    該当なし

    該当なし

    該当なし

    OSB_Cluster

    UMSJMSServer_osb_scaled_3

    UMSJMSJDBCStore_osb_scaled_3

    WLS_OSB3 (移行可能)

    wlsbJMSServer_osb_scaled_3

    OSBJMSJDBCStore_osb_scaled_3

    WLS_OSB3 (移行可能)

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

    ProcMonJMSJDBCStore_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モジュール」の順に開きます。
    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

      ESS_Cluster

      該当なし

      該当なし

      OSB_Cluster

      UMSJMSSystemResource *

      UMSJMSServer_osb_scaled_3

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

      wlsbJMSServer_osb_scaled_3

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

      ProcMonJMSServer_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、ProcMonJMSModule)は、複数のクラスタをターゲットにしている場合があります。それぞれのケースで適切なサブデプロイメントを更新していることを確認します。
    3. 「構成」→「サブデプロイメント」に移動します。
    4. 対応するJMSサーバーを既存のサブデプロイメントに追加します。

      注意:

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

    5. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  12. BAMクラスタをスケール・アップする場合は、BamCQServiceJmsSystemModuleモジュールで、新しいサーバーのローカル・キューを作成する必要があります。これらを作成するには、次のステップに従います。
    1. WebLogicコンソールから、「サービス」→「メッセージング」→「JMSモジュール」に移動します。
    2. 「ロックして編集」をクリックします。
    3. BamCQServiceJmsSystemModuleの中をクリックします。
    4. 「ターゲット」をクリックします。
    5. ターゲットにWLS_BAM3を追加して、「保存」をクリックします。
    6. 「新規」をクリックします。
    7. 「キュー」を選択し、「次へ」をクリックします。
    8. 名前をBamCQServiceAlertEngineQueue_auto_3,に変え、「次」をクリックします。
    9. BamCQServiceJmsServer_bam_scaled_3をターゲットにして新しいサブデプロイメントを作成し、それをキューに選択します。
    10. 「終了」をクリックします。
    11. 新しく選択したキューBamCQServiceAlertEngineQueue_auto_3の中をクリックします。
    12. 「構成」→「全般」→「詳細」タブに移動します。
    13. 「ローカルJNDI名」をqueue/oracle.beam.cqservice.mdbs.alertengineに設定します。
    14. 「保存」をクリックします。
    15. 同じステップを繰り返し、表24-8の情報を使用してもう1つのキューBamCQServiceReportCacheQueue_auto_3を作成します。
    16. 完了すると、新しいローカル・キューを使用できるようになります。表24-8の情報を使用して、新しいサーバーに2つのローカル・キューを作成する必要があります。

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

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

      BamCQServiceAlertEngineQueue_auto_3

      キュー

      queue/oracle.beam.cqservice.mdbs.alertengine

      BamCQServiceJmsServer_auto_3

      BamCQServiceReportCacheQueue_auto_3

      キュー

      queue/oracle.beam.cqservice.mdbs.reportcache

      BamCQServiceJmsServer_auto_3
    17. 「変更のアクティブ化」をクリックします。
  13. 前のすべての変更を有効にするために、すべてのサーバー(新しく作成したサーバーを除く)を再起動します。ローリング形式で再起動すると、ダウンタイムをなくすことができます。
  14. 新しい管理対象サーバーを起動します。
  15. MFT_Clusterをスケール・アップする場合:

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

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

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

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

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

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

    例:

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

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

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

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

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

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

      WSM-PM_Cluster

      http://soainternal.example.com/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. 「JMSサーバー」に移動します。
    2. 「JMSサーバー」→「モニタリング」の順にクリックします。
  3. 「静的クラスタでの自動サービス移行の検証」での説明に従って、サービスの移行を確認します。

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

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

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_ESS4などになります。

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

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

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

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

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

    ドメイン内のマシン MachineNameMatchExpression構成 動的サーバーのマシン割当
    SOAHOST1、SOAHOST2 SOAHOST*

    dyn-server-1: SOAHOST1

    dyn-server-2: SOAHOST2

    dyn-server-3: SOAHOST1

    dyn-server-4: SOAHOST2

    ...
    SOAHOST1、SOAHOST2、SOAHOST3 SOAHOST*

    dyn-server-1: SOAHOST1

    dyn-server-2: SOAHOST2

    dyn-server-3: SOAHOST3

    dyn-server-4: SOAHOST1

    ...

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

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

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

    例: 
    10.229.188.204 host1-vip.example.com host1-vip ADMINVHN 
10.229.188.205 host1.example.com host1 SOAHOST1 SOAHOST3
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

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

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

      注意:

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

  4. SOA_Clusterをスケール・アップする場合:

    BPM Webフォームを使用する場合は、「WebフォームのSOA BPMサーバーの更新」での説明に従って、BPM向けのMSERVER_HOMEカスタマイズでstartWebLogic.shを更新し、新しいノードを追加します。

  5. OSB_Clusterをスケール・アップする場合:
    管理サーバーを再起動し、Service Busダッシュボードで新しいサーバーを確認します。
  6. MFT_Clusterをスケール・アップする場合:
    新しいサーバーでは、デフォルトのSFTP/FTPポートが使用されます。デフォルト値を使用しない場合は、「SFTPポートの構成」での説明に従って、SFTPサーバーのポートを構成します。

    スケール・アップする場合、新しいサーバーには、同じマシンの既存のサーバーと競合しない別のSFTP/FTPポートを使用してください。

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

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

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

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

      例:

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

    例:

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

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

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

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

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

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

      WSM-PM_Cluster

      http://soainternal.example.com/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. 「JMSサーバー」に移動します。
    2. 「JMSサーバー」→「モニタリング」の順にクリックします。
  3. 「動的クラスタの自動サービス移行の構成」での説明に従って、サービスの移行を確認します。

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

トポロジのスケール・ダウンでは、既存のホストに追加された管理対象サーバーを削除します。

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

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

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

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

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

    注意:

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

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

    注意:

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

  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

    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. 削除したサーバーに作成されたJMSサーバーの選択を解除します。
    6. 「保存」をクリックします。
    7. 「変更のアクティブ化」をクリックします。
  7. BAMクラスタをスケール・ダウンする場合は、Oracle WebLogic Server管理コンソールを使用して、新しいサーバーに作成されるローカル・キューを削除します
    1. 「ロックして編集」をクリックします。
    2. WebLogicコンソールから、「サービス」→「メッセージング」→「JMSモジュール」に移動します。
    3. BamCQServiceJmsSystemModuleの中をクリックします。
    4. 新しいサーバーに作成されたローカル・キューを削除します。

      • BamCQServiceAlertEngineQueue_auto_3

      • BamCQServiceReportCacheQueue_auto_3

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

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

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

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

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

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

    注意:

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

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

    注意:

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

    • 動的クラスタ内の、削除するサーバーで実行されている、移行ポリシーとして「常時」を使用するJMSサーバーは、この時点でクラスタ内の別のメンバーに移行されます(そのサーバーは単に停止されています)。それらをホストするメンバーを次に再起動したときは、これらのJMSサーバーは起動されません。これは、それらの優先サーバーがクラスタ内に存在しなくなったためです。ただし、メッセージが失われた可能性があるため、この合間に新しいメッセージを取得したかどうかを確認する必要があります。メッセージを保持するには、クラスタ内のサーバーを再起動する前に、これらのJMSサーバーからのメッセージの生成およびエクスポートを一時停止します。

  4. Oracle WebLogic Server管理コンソールを使用して、動的クラスタを減らします。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン」→「環境」→「クラスタ」に移動します。
    3. スケール・ダウンするクラスタを選択します。
    4. 「構成」→「サーバー」に移動します。
    5. 再度、「動的クラスタ・サイズ」を2に設定します。

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