クラスタ化されたSOA環境のアップグレード

8 クラスタ化されたSOA環境のアップグレード

クラスタ化されたSOA環境へのアップグレード・プロセスと、アップグレード後の構成タスクを実行するプロセスについて説明します。

クラスタ化トポロジのアップグレード
SOAクラスタ・アップグレード・トポロジの理解
クラスタ化トポロジでの保護されたタスク・フォームの使用
タスク・フォームは、Java Server Page XML (.jspx)ファイルです。このファイルは、ヒューマン・タスクが含まれるSOAコンポジットを作成したOracle JDeveloper Designerで作成します。
別のホストへのドメイン構成の伝播
アップグレードの成功を確認したら、ここに示すステップを実行して、新しくアップグレードしたファイルをもう一方のホストに伝播します。
クラスタ・アップグレードのアップグレード後タスク

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

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

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

タスク	詳細情報
アップグレード・トポロジを確認して、設定で`SOAHOST1`および`SOAHOST2`を特定します。	「SOAクラスタ・アップグレード・トポロジの理解」を参照
`SOAHOST1`または`SOAHOST2`で実行中の管理サーバー、すべての管理対象サーバーおよびノード・マネージャを停止します。	「サーバーとプロセスの停止」を参照
`SOAHOST1`で、11gデプロイメントの完全アップグレードを実行します。環境に適用するアップグレード後の構成を実行します。	「SOA SuiteおよびBusiness Process Managementの11gからのアップグレード」を参照関連項目: Business Activity Monitoring (BAM)がドメインの一部である場合は、「Oracle BAMドメインを含むSOAの12cへのアップグレード」を参照 Oracle Service Bus (OSB)がドメインの一部である場合は、「Oracle Service Bus (Oracle SOA Suiteなし)の11gからのアップグレード」を参照
アップグレードが成功したら、`SOAHOST1`のドメイン構成を`SOAHOST2`に伝播します。これを行うには、`SOAHOST1`上のドメインを圧縮し、それを`SOAHOST2`上の新しいドメイン内で解凍する必要があります。	「別のホストへのドメイン構成の伝播」を参照
`SOAHOST1`と`SOAHOST2`で、管理サーバーと管理対象サーバーを再起動します。	「管理サーバーおよびSOA管理対象サーバーの起動」
ご使用の環境のためのその他のアップグレード後構成作業を実行します。	「アップグレード後タスクの実行」を参照してください

親トピック: クラスタ化されたSOA環境のアップグレード

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

図8-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環境に適用できます。

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

ノート:

SOAを含むOracle BAMをアップグレードする場合は、「Oracle BAMドメインを含むSOAの12cへのアップグレード」を参照してください。

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

「図8-1 クラスタ化されたSOAのトポロジ」の説明

親トピック: クラスタ化されたSOA環境のアップグレード

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

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

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

親トピック: クラスタ化されたSOA環境のアップグレード

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

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

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

親トピック: クラスタ化されたSOA環境のアップグレード

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

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

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

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

12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12c (12.2.1.3.0)ビットのインストール・ディレクトリ)への実際のパスを表します。
11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。
domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。
domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。
デフォルトでは、domainupgradetemplateは、現行ディレクトリ(packコマンドを実行したディレクトリ)に作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。
```
ORACLE_COMMON_HOME/common/bin/
```

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

親トピック: 別のホストへのドメイン構成の伝播

SOAHOST2の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ホーム・ディレクトリ(12c (12.2.1.3.0)のインストール・ディレクトリ)への実際のパスを表します。
NEW_DOMAIN_LOCATIONを、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。
domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。
domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

親トピック: 別のホストへのドメイン構成の伝播

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

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

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

scp soadomaintemplate.jar company@SOAHOST2:12c_ORACLE_HOME/oracle_common/common/bin

親トピック: 別のホストへのドメイン構成の伝播

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

11gドメインからのsetDomainEnv.shスクリプトのWL_HOME、SOA_ORACLE_HOME、UMS_ORACLE_HOMEが、12cを指していることを確認します。

「setDomainEnv.shへのカスタマイズの再適用」を参照してください。
SOAHOST1とSOAHOST2のノード・マネージャ、WebLogic管理サーバーおよび管理対象サーバーを次の順序で起動します。
1. SOAHOST1とSOAHOST2で、ノード・マネージャを起動します。
2. SOAHOST1で、WebLogic管理サーバーを起動します。
3. SOAHOST1とSOAHOST2で、管理対象サーバーを起動します。

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

サーバーを起動できない場合や、その他の技術的問題が発生した場合は、「アップグレードのトラブルシューティング」を参照してください

ノート:

アップグレード時に、ノード・マネージャ構成ファイル(nodermanager.propertiesなど)が、11g_DOMAIN_HOME/wlserver_10.3/の場所から、11g_ORACLE_HOME/ domains/DOMAIN_HOME/nodemanagerの場所に移動されます。そのため、12cのノード・マネージャは、11g_DOMAIN_HOMEドメイン・ディレクトリから起動する必要があります。

親トピック: 別のホストへのドメイン構成の伝播

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

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

管理サーバーおよびSOA管理対象サーバーの起動
Oracle WebLogic管理サーバーおよびその他のSOA管理対象サーバーを再起動します。
SOAおよびOSBクラスタからのOWSMターゲットの削除
OWSMクロス・コンポーネント・ワイヤリングの更新
クラスタ・アップグレード後のSOA JMSモジュールへのEDNTopicの再適用
JMSトランスポート・プロキシ・サービス使用時のメッセージの重複防止

親トピック: クラスタ化されたSOA環境のアップグレード

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

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

管理サーバーの起動

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

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

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows)DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよび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

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

SOAサーバーおよびプロセスを次の順番で起動します。

Oracle Web Services Manager (OWSM)管理対象サーバー
サービス指向アーキテクチャ(SOA)管理対象サーバー
Oracle Service Bus (OSB)管理対象サーバー
Business Activity Monitoring (BAM)管理対象サーバー

ノート:

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

親トピック: クラスタ・アップグレードのアップグレード後タスク

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

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

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

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

ブラウザに次のURLを入力します。
```
http://host name:port_number/console
```
ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は7001です。

ログイン・ページが表示されます。
「ドメイン構造」で「デプロイメント」を選択します。
「デプロイメント」からwsm-pmを選択します。
「wsm-pmの設定」で、「ターゲット」を選択します。
タイプが「エンタープライズ・アプリケーション」のwsm-pmコンポーネントを選択して、「ターゲットの変更」を選択します。
SOAクラスタとOSBクラスタの選択を解除します。
プロンプトが表示されたら、「はい」をクリックして変更内容を適用します。
必須: wsm-pmのターゲットをOWSMクラスタのみに設定した後、「OWSMクロス・コンポーネント・ワイヤリングの更新」の説明に従ってコンポーネントを再接続する必要があります。

親トピック: クラスタ・アップグレードのアップグレード後タスク

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

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

管理(admin)サーバーと1つのOWSMサーバーを起動します。
Oracle Enterprise Manager Fusion Middleware Control 12cコンソールにログインし、「クロス・コンポーネント・ワイヤリング」→「コンポーネント」オプションに移動します。

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

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

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

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

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

親トピック: クラスタ・アップグレードのアップグレード後タスク

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

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

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

親トピック: クラスタ・アップグレードのアップグレード後タスク

JMSトランスポート・プロキシ・サービス使用時のメッセージの重複防止

12cクラスタ・ドメインのjmsServerは、移行可能なターゲットに向けてターゲット設定されています。これは、jmsServerが個別のサーバーに向けてターゲット設定されていた、11gのデフォルト動作とは異なります。

JMSトランスポートに基づいて12cプロキシ・サービスを構成するときには、トピック分散モードをOne-Copy-Per-ApplicationまたはOne-Copy-Per-Serverに設定します。重複メッセージを防止するために、クラスタ化環境では互換性モードを使用しないでください。

親トピック: クラスタ・アップグレードのアップグレード後タスク