1. SOA SuiteおよびBusiness Process Managementのアップグレード
  2. クラスタ化環境のアップグレード

5 クラスタ化環境のアップグレード

マルチノード環境へのアップグレード・プロセスと、アップグレード後の構成タスクを実行するプロセスについて説明します。

ノート:

OHSで構成されたOracleウォレットが、アップグレード・アシスタントが起動されているマシンと同じマシン上に存在しない場合は、アップグレード・プロセス中にウォレットを処理できません。ウォレットが使用可能であることを確認するには、次のステップを実行する必要があります。

クラスタ化トポロジのアップグレード

表5-1は、クラスタ化された複数ホストのOracle SOA Suiteサンプル・トポロジ(図5-1)をアップグレードするために必要なステップを示しています。

表5-1 Oracle SOA SuiteおよびBPMクラスタのアップグレード・ロードマップ

タスク 関連情報

アップグレード・トポロジを確認して、設定でSOAHOST1およびSOAHOST2を特定します。

「SOAクラスタ・アップグレード・トポロジの理解」を参照

SOAHOST1またはSOAHOST2で実行中の管理サーバー、すべての管理対象サーバーおよびノード・マネージャを停止します。

「サーバーとプロセスの停止」を参照

SOAHOST1で、既存のデプロイメントの完全アップグレードを実行します。環境に適用するアップグレード後の構成を実行します。

「SOA SuiteおよびBusiness Process Managementのアップグレード」を参照してください

アップグレードが成功したら、SOAHOST1のドメイン構成をSOAHOST2に伝播します。

これを行うには、SOAHOST1上のドメインを圧縮し、それをSOAHOST2上の新しい14c (14.1.2.0.0)ドメイン内で解凍する必要があります。

「別のホストへのドメイン構成の伝播」を参照

SOAHOST1とSOAHOST2で、管理サーバーと管理対象サーバーを再起動します。

「管理サーバーおよびSOA管理対象サーバーの起動」

ご使用の環境のためのその他のアップグレード後構成作業を実行します。

「アップグレード後タスクの実行」を参照してください

SOAクラスタ・アップグレード・トポロジの理解

図5-1は、クラスタ化されたOracle SOA Suiteデプロイメントのサンプル・トポロジを示しています。このトポロジでは、SOA、Oracle Web Services Manager (OWSM)、Oracle Service Bus (OSB)およびOracle Business Activity Monitoring (Oracle BAM)が、2つのアプリケーション・ホスト(SOAHOST1とSOAHOST2)に渡る個別のクラスタに含まれています。Oracle HTTP Server、管理サーバー、Oracle Enterprise Manager Fusion Middleware Controlおよびデータベースは、両方のホストで共有されています。

この章では、特に、複数のホスト・コンピュータにスケール・アウトされた複数のWebLogic Serverクラスタが含まれているWebLogicドメインのアップグレードに必要なステップを説明します。この章の概念と手順は、ユーザー独自のOracle SOA Suite環境に適用できます。

このサンプル・トポロジのアップグレードに必要なステップは、次の項の表5-1で説明しています。

図5-1 クラスタ化されたSOAのトポロジ

図5-1の説明が続きます
「図5-1 クラスタ化されたSOAのトポロジ」の説明

クラスタ化トポロジでの保護されたタスク・フォームの使用

タスク・フォームは、Java Server Page XML (.jspx)ファイルです。このファイルは、ヒューマン・タスクが含まれるSOAコンポジットを作成したOracle JDeveloper Designerで作成します。

SOAコンポジットにヒューマン・タスク・フォームが含まれている場合や、タスク・フォームが非SOAサーバーにデプロイされている場合は、アップグレード後にタスク・フォームを保護する必要があります。

別のホストへのドメイン構成の伝播

アップグレードの成功を確認したら、ここに示すステップを実行して、新しくアップグレードしたファイルをもう一方のホストに伝播します。

HOST1で単一ノードのアップグレードを完了したら、ここに示すステップを実行して、新しくアップグレードしたファイルを別のノード(この例では、セカンダリ・ホストをHOST2と呼びます)に伝播します。

管理サーバーといずれかの管理対象サーバーがインストールされているサーバーでのpackコマンドの実行

このサンプル・トポロジの場合は、HOST1で次を実行します。

cd /14c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/12c_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

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

  • 14c_ORACLE_HOMEは、14c Oracleホーム・ディレクトリ(14c (14.1.2.0.0)ビットのインストール・ディレクトリ)への実際のパスを表します。

  • 12c_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

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

  • domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

  • デフォルトでは、domainupgradetemplateは、現行ディレクトリ(packコマンドを実行したディレクトリ)に作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。 

    ORACLE_COMMON_HOME/common/bin/

packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。

HOST2の12c Oracleホームからのunpackコマンドの実行。

管理サーバーと管理対象サーバーが停止していることを確認してから、unpackコマンドを実行して、リモート・マシンの管理対象サーバー・ドメイン・ディレクトリに使用する完全ドメイン(またはドメインのサブセット)を作成します。unpackは、現在のインストールと互換性のあるテンプレートでのみ使用できます。

ノート:

既存のドメインの上にドメインを解凍しないようにしてください。ドメイン・アップグレード・テンプレートのjarファイルのコンテンツは、新しいドメイン・ロケーションに解凍することをお薦めします。

ドメインの解凍時に -overwrite_domain=true引数を使用する場合でも、既存ドメインのコンテンツは所定の場所に残り、サーバー起動時に問題が発生します。このため、ドメイン・テンプレートのjarファイルを新しい場所に解凍するか、解凍前に既存の場所のコンテンツを手動で削除することをお薦めします。

サンプルのunpackコマンドのコード・スニペットを次に示します。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=NEW_DOMAIN_LOCATION

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

  • 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(14c (14.1.2.0.0)のインストール・ディレクトリ)への実際のパスを表します。

  • NEW_DOMAIN_LOCATIONを、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

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

  • domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

HOST 1で作成したテンプレート・ファイルをHOST2にコピーします。

HOST1のデプロイメントの完全アップグレードを実行し、新しい環境に適用されるアップグレード後構成を完了した後、ドメイン・テンプレートをHOST2にコピーする必要があります。

次のコマンドを使用して、アップグレード中に作成されたドメイン・アップグレード・テンプレートJARファイルをHOST1からコピーします。

scp domaintemplate.jar company@HOST2:14c_ORACLE_HOME/oracle_common/common/bin

unpack後の次の確認ステップの完了

  1. 12cドメインのsetDomainEnv.shスクリプトにあるWLS_HOMEおよびORACLE_HOMEの設定が14c (14.1.2.0.0)を指していることを確認します。

  2. HOST1とHOST2のノード・マネージャ、WebLogic管理サーバーおよび管理対象サーバーを次の順序で起動します。

    1. HOST1およびHOST2で、ノード・マネージャを起動します。

    2. HOST1で、WebLogic管理サーバーを起動します。

    3. HOST1およびHOST2で、管理対象サーバーを起動します。

詳細は、「サーバーおよびプロセスの起動」を参照してください。管理対象サーバーを起動する順序を十分に確認してください。

クラスタ・アップグレードのアップグレード後タスク

クラスタのアップグレードが正常に完了した後で、追加のアップグレード後構成タスクを実行する必要があります。目的のクラスタ化環境に当てはまるタスクのみを実行してください。

アップグレード後のドメイン・モードの変更

アップグレード後、ドメインは元のアップグレード前のドメイン・セキュリティ・モード設定を保持します。たとえばセキュリティを強化する目的で、ドメイン・モードを変更する場合は、WebLogicリモート・コンソールを使用するか、DomainMBeanを変更して、明示的に設定を変更する必要があります。

現在ドメインが本番モードに設定されていて、追加のセキュリティを有効にする場合は、アップグレード後にWebLogicリモート・コンソールを使用してドメイン・モードを変更し、保護された本番モードを有効にします。Oracle WebLogicリモート・コンソール・オンライン・ヘルプのドメイン・モードの変更。

注意:

ドメイン・モードの変更には、ドメイン全体の再起動が必要です。ローリング再起動では足りません。ドメイン・モードを変更する前に、すべての管理対象サーバーを停止する必要があります。

ドメインを14c (14.1.2.0.0)にアップグレードするときに、明示的なセキュア・モード設定がない場合、再構成ウィザードによって、アップグレード後のドメインではセキュア・モードが明示的に「無効」に設定されます。これは、元のドメインに存在していた動作を保持するためです。明示的な保護モード設定がある場合は、アップグレード後のドメインでもそれが保持されます。詳細は、『Oracle WebLogic Server本番環境の保護』のドメイン・モードがデフォルトのセキュリティ構成に与える影響の理解に関する項を参照してください。

ノート:

保護された本番モードでは、より制限的で厳しいセキュリティ設定が強制され、脅威に対する脆弱性が軽減されます。ドメインがセキュアであることを確認するには、保護された本番モードを有効にしてから、証明書の取得および格納、ユーザー・アカウントの保護、ドメインが実行されるネットワークの保護など、ドメインが実行される環境に適したセキュリティ構成オプションを選択する必要があります。これらのオプションが適切に構成されていない場合、WebLogic Serverの使用はブロックされます。

WebLogicドメインの作成後には、適切なセキュリティ構成の選択など、整合性を確保するための主要なステップがいくつか残っています。詳細は、『Oracle WebLogic Serverセキュリティの管理』の作成後のドメインの保護に関する項を参照してください。

管理サーバーおよびSOA管理対象サーバーの起動

Oracle WebLogic管理サーバーおよびその他のSOA管理対象サーバーを再起動します。

管理サーバーの起動

ノート:

この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Serverリモート・コンソールを使用することもできます。管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。

リリース14c (14.1.2.0.0)以降、WebLogic Server管理コンソールは削除されました。同等の機能を使用するには、WebLogicリモート・コンソールを使用する必要があります。詳細は、Oracle WebLogicリモート・コンソールを参照してください。

ノート:

既存のセキュリティ設定によっては、保護された本番モードが有効になっているドメインを起動または管理する前に、追加の構成を実行する必要がある場合があります。詳細は、保護された本番モードの使用を参照してください。

管理サーバーを起動するときには、WebLogicリモート・コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも起動します。

管理サーバーを起動するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows)DOMAIN_HOME\bin\startWebLogic.cmd

ノート:

保護された本番モードを使用する場合は、管理サーバーを起動するための追加パラメータを指定する必要があります。『Oracle WebLogic Serverのセキュリティの管理』のWLSTを使用した管理サーバーへの接続に関する項を参照してください。

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

管理対象サーバーを起動します

次のスクリプトでWebLogic Server管理対象サーバーを起動します。

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

ノート:

保護された本番モードを使用する場合は、管理対象サーバーを起動するための追加パラメータを指定する必要があります。『Oracle WebLogic Serverセキュリティの管理』の起動スクリプトを使用した管理対象サーバーの起動に関する項を参照してください。

プロンプトが表示されたら、ユーザー名とパスワードを入力します。

SOAサーバーおよびプロセスを次の順番で起動します。
  1. Oracle Web Services Manager (OWSM)管理対象サーバー

  2. Service-Oriented Architecture (SOA)管理対象サーバーおよびManaged File Transfer (MFT)

  3. Oracle Service Bus (OSB)管理対象サーバー

  4. Business Activity Monitoring (BAM)管理対象サーバー

ノート:

通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが起動します。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

SOAおよびOSBクラスタからのOWSMターゲットの削除

12cドメインの専用クラスタにOracle Web Services Manager (OWSM)が含まれていて、そのドメインをSOAクラスタとOSBクラスタで拡張している場合は、アップグレード後に、SOAクラスタとOSBクラスタからwsm-pmのターゲット設定を手動で解除する必要があります。

SOAクラスタとOSBクラスタからowsm-pmターゲットを削除するには:

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

    ブラウザに次のURLを入力します。

    http://host name:port_number/console

    ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は7001です。

    ログイン・ページが表示されます。

  2. 「ドメイン構造」で「デプロイメント」を選択します。

  3. 「デプロイメント」からwsm-pmを選択します。

  4. 「wsm-pmの設定」で、「ターゲット」を選択します。

  5. タイプが「エンタープライズ・アプリケーション」のwsm-pmコンポーネントを選択して、「ターゲットの変更」を選択します。

  6. SOAクラスタとOSBクラスタの選択を解除します。

  7. プロンプトが表示されたら、「はい」をクリックして変更内容を適用します。

  8. 必須: wsm-pmのターゲットをOWSMクラスタのみに設定した後、「OWSMクロス・コンポーネント・ワイヤリングの更新」の説明に従ってコンポーネントを再接続する必要があります。

OWSMクロス・コンポーネント・ワイヤリングの更新

「SOAおよびOSBクラスタからのOWSMターゲットの削除」で説明しているように、SOAおよびOSBクラスタからOWSMターゲットを削除した後、次に説明するようにOWSMポリシー・マネージャを再接続する必要があります。

  1. 管理(admin)サーバーと1つのOWSMサーバーを起動します。

  2. Oracle Enterprise Manager Fusion Middleware Control 12cコンソールにログインし、「クロス・コンポーネント・ワイヤリング」→「コンポーネント」オプションに移動します。

    cross_menu.pngの説明が続きます
    図cross_menu.pngの説明

  3. 使用可能なコンポーネントの一覧からOWSM Policy Managerを選択します。

    owsm_comp.pngの説明が続きます
    図owsm_comp.pngの説明

  4. 「サービス・エンド・ポイント」表から、OWSM Policy Manager t3接続エントリを選択し、「公開」をクリックします。ステータスが「同期外れ」から「公開」に変更されます。

    owsm_publish.pngの説明が続きます
    図owsm_publish.pngの説明

  5. 「コンポーネント・タイプ」リストからOWSM Agentを選択します。t3接続エントリを選択し、「バインド」をクリックします。

    bind.pngの説明が続きます
    図bind.pngの説明

  6. サービス・エンドポイントの「サービス・タイプ」がOWSM Policy Managerであることを確認します。

    bind_config.pngの説明が続きます
    図bind_config.pngの説明

  7. ステップ5と6を繰り返して残りのコンポーネント・タイプをバインドします。この例では、com.oracle.essとFusion Middleware Controlを選択します。

クラスタ・アッグレード後のSOA JMSモジュールへのEDNTopicの再適用

SOAクラスタ・ドメインを14c (14.1.2.0.0)にアップグレードすると、アップグレード後のSOA JMSモジュールにEDNTopicがない場合があります。JMSモジュールにEDNTopicがない場合は、管理コンソールまたはWLSTを使用して、このトピックにトピックまたはUDDを手動で追加する必要があります。

EDNTopicの再適用の詳細は、リモート・コンソールのオンライン・ヘルプを参照してください。