| Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B55899-03 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B55899-03 |
|
前 |
次 |
この章は、Oracle Business Activity Monitoring(BAM)をエンタープライズ環境で使用するユーザーを対象としています。その内容は次のとおりです。
BAMシステムは、第4章「ドメインの作成」で作成したWL_HOMEおよびORACLE_HOMEを使用して共有記憶域にインストールします。BAMHOST1およびBAMHOST2は、MW_HOMEをマウントして、既存のWLSおよびSOAのインストールを再利用します。packユーティリティおよびunpackユーティリティを使用して、この2つの新しいノードでWLS_BAM1サーバーおよびWLS_BAM2サーバーのドメイン構成をブートストラップします。この結果、各ノードにソフトウェアをインストールする必要がなくなります。BAMシステムが正常に機能するには、SOAHOST1およびSOAHOST2にOracle FMWをインストールするときに必要としたシステム構成と同一の構成をBAMHOST1およびBAMHOST2で保持しておく必要があります。このシステム構成がないと、バイナリの実行で予期しない動作が発生することがあります。
構成ウィザードを使用する前に、『Oracle Fusion Middleware管理者ガイド』の説明に従ってドメインをバックアップする必要があります。
この項では、第4章「ドメインの作成」で作成したドメインにBAMを追加する方法を説明します。
ステップ1: BAMHOST1でのVIP4の有効化
ステップ2: BAMを追加するためのドメインの拡張
ステップ3: BAM UMS用のJMS永続ストアの構成
ステップ4: トランザクション・リカバリ用デフォルト永続ストアの構成
ステップ6: pack/unpackユーティリティを使用した、BAMHOST1およびBAMHOST2へのドメイン構成の伝播
ステップ8: BAMシステムの起動
ステップ12: WLS_BAM1サーバーのサーバー移行の構成
BAMシステムでは、BAMサーバー・コンポーネントをホストする管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。この仮想ホスト名とそれに対応する仮想IPは、BAMサーバー・コンポーネントでサーバー移行を有効にするときに必要となります。BAMHOST1でVIP(VIP4)のマッピングBAMHOST1VHN1を有効にして、トポロジ(DNSサーバーとホスト解決のいずれか)で使用されるネットワーク・システムでBAMHOST1VHN1ホスト名を正しく解決する必要があります。
VIP4を有効にするには、第4.3項「SOAHOST1でのVIP1の有効化」で説明している手順に従ってください。
この手順では、第4章「ドメインの作成」で作成したドメインを、BAMを扱うことができるように拡張します。この項の手順は、SOAのデプロイメントと同じデータベース・サービス(soaedg.mycompany.com)をBAMのデプロイメントでも使用することを前提としています。ただし、BAM専用の別のデータベース・サービスをデプロイメントに使用することもできます。
|
注意: これらの手順を実行する前に、『Oracle Fusion Middleware管理者ガイド』の説明に従ってドメインをバックアップします。 |
ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。
SOAHOST1> cd ORACLE_HOME/common/bin
構成ウィザードを起動します。
SOAHOST1> ./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
「WebLogicドメイン・ディレクトリ」画面で、WebLogicドメイン・ディレクトリ(ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>)を選択し、「次へ」をクリックします。
「拡張ソースの選択」画面で、次の手順を実行します。
「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。
次の製品を選択します。
Oracle Business Activity Monitoring 11.1.1.1
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面(図7-1)で、次の手順を実行します。
「BAM Schema」を選択します。
「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面(図7-2)で、次の手順を実行します。
「BAM Schema」を選択します。その他のデータ・ソースはそのままにします。
次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。
サービス名: データベースのサービス名を入力します(soaedg.mycompany.comなど)。
ユーザー名: スキーマの完全なユーザー名(接頭辞を含む)を入力します。図7-2に示すユーザー名では、RCUから作成されたスキーマの接頭辞にsoedgが使用されたことが前提となっています。
パスワード: スキーマへのアクセスに使用するパスワードを入力します。
「追加」をクリックし、最初のRACインスタンスの詳細を入力します。
この手順をRACインスタンスごとに実行します。
|
注意: SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマの情報はそのままにしておきます。 |
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。
「オプションの構成」画面で、次の項目を選択します。
JMS分散宛先
管理対象サーバー、クラスタ、およびマシン
デプロイメントとサービス
「JMS分散宛先タイプの選択」画面で、すべてのFusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストから「UDD」を選択します。
|
注意: Fusion Middlewareコンポーネントでは、WDDの使用はサポートされていません。 |
「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
bam_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_BAM1に変更し、WLS_BAM2という新しいサーバーを追加します。表7-1に示す属性をこれらのサーバーに割り当てます。この画面に表示されている他のサーバーは、このまま変更しません。
表7-1 管理対象サーバー
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WLS_BAM1 |
BAMHOST1VHN1 |
9001 |
なし |
いいえ |
|
WLS_BAM2 |
BAMHOST2 |
9001 |
なし |
いいえ |
「次へ」をクリックします。
「クラスタの構成」画面で、表7-2に示す次のクラスタを追加します。この画面に表示されている他のクラスタは、このまま変更しません。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次の項目を追加します。この画面に表示されている他の割当ては、このまま変更しません。
BAM_Cluster
WLS_BAM1
WLS_BAM2
「次へ」をクリックします。
「マシンの構成」画面で、次の手順を実行します。
デフォルトで表示される「LocalMachine」を削除します。
「Unixマシン」タブをクリックします。マシンBAMHOST1およびBAMHOST2を追加して、次のように入力します。
その他すべてのフィールドはデフォルト値のままにします。
「次へ」をクリックします。
WLS_BAM1をBAMHOST1に割り当てます。
WLS_BAM2をBAMHOST2に割り当てます。
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
usermessagingserverおよびusermessagingdriver-emailは、SOA_ClusterおよびBAM_Clusterにのみターゲット設定する必要があります (usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。
WSM-PMはWSM-PM_Clusterにのみターゲット設定する必要があります。
「DMSアプリケーション」は、BAM_Cluster、SOA_Cluster、WSM-PM_Clusterおよび「管理サーバー」にターゲット設定する必要があります。
oracle.rules.*、oracle.sdp.*の各デプロイメントは、SOA_ClusterおよびBAM_Clusterのみにターゲット設定する必要があります。oracle.soa.*デプロイメントは、SOA_Clusterにのみターゲット設定する必要があります。
oracle.wsm.seedpoliciesライブラリは、WSM-PM_Clusterにのみターゲット設定する必要があります。
このライブラリは、SOA_ClusterまたはBAM_Clusterにもターゲット設定します。ただしこれは、WebLogic WebServicesをそれらにデプロイする場合のみです。
oracle.bam*は、BAM_Clusterにのみターゲット設定する必要があります。
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
mds-owsm、mds-owsm-rac0およびmds-owsm-rac1は、WSM-PM_ClusterおよびAdminServerの両方にターゲット設定する必要があります。
mds-soa、mds-soa-rac0およびmds-soa-rac1は、SOA_ClusterおよびAdminServerの両方にターゲット設定する必要があります
OraSDPMDatasource、OraSDPMDatasource-rac0およびOraSDPMDatasource-rac1は、SOA_ClusterおよびBAM_Clusterの両方にターゲット設定する必要があります。
JOC起動クラスとJOC停止クラスは、WSM-PM_Clusterにのみターゲット設定します。
「次へ」をクリックします。
「構成のサマリ」画面で、「拡張」をクリックします。
|
注意: ドメインを拡張するので、「構成のサマリ」画面に表示されている値は変更しないでください。 |
ドメインのポートの競合に関する警告ダイアログで「OK」をクリックします。
「ドメインの作成中」画面で、「完了」をクリックします。
管理サーバーを再起動して、ここまでの変更を有効にします。
管理サーバーは、第4.7項「SOAHOST1での管理サーバーの起動」の手順で再起動します。
すべての永続ストアの場所を、両ノードから認識できるディレクトリとして構成します。詳細は、第4.1項「Oracle Fusion Middlewareホームのインストール」を参照してください。次のように、この共有ベース・ディレクトリを使用するようにすべての永続ストアを変更する必要があります。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「サービス」ノードを開き、「永続ストア」ノードをクリックします。「永続ストアの概要」ページが表示されます。
表の「名前」列で、永続ストア「UMSJMSFileStore_auto_3」(これはハイパーリンクとして表示されています)を選択します。その永続ストアの「設定」ページが表示されます。
「構成」タブの「ディレクトリ」フィールドに、クラスタにある他のサーバーで使用できる永続記憶域ソリューション(NASやSANなど)上の場所を入力します。この場所を指定すると、JMSの保留メッセージを送信できます。この場所は、次のディレクトリ構造であることが必要です。
ORACLE_BASE/admin/<domain_name>/<bam_cluster_name>/jms
「保存してアクティブ化」をクリックします。
この手順をUMSJMSFileStore_auto_4についても実行します。
各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーからアクセスできる場所にトランザクション・ログを格納します。
|
注意: デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。 |
デフォルト永続ストアの場所を設定するには、WLS_BAM1について次の手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_BAM1」(これはハイパーリンクとして表示されています)をクリックします。WLS_BAM1サーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。
「サービス」タブをクリックします。
表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/tlogs
「保存」をクリックします。
|
注意: トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。BAMHOST1とBAMHOST2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。 |
BAMのBAMサーバー・コンポーネントはシングルトンなので、そのコンポーネントをサーバー移行用に構成する前に、いずれかのWLS_BAMサーバーのターゲット設定を解除する必要があります。
次の手順では、BAMサーバーのランタイムをWLS_BAM2から削除します。この手順を実行して、WLS_BAM2からBAMサーバー・アーティファクトのターゲット設定を解除します。
http://ADMINVHN:7001/consoleのOracle WebLogic管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択します。「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_BAM2」を選択します。WLS_BAM2の「設定」ページが表示されます。
「デプロイメント」タブをクリックします。
表の「名前」列でoracle-bamアプリケーションを選択します。oracle-bamアプリケーションの「設定」ページが表示されます。
「ターゲット」タブをクリックします。
「ロックして編集」をクリックします。
表7-4に従って各モジュールのターゲットを変更します。
表7-4 oracle-bamコンポーネントのターゲット・タイプ
| コンポーネント | タイプ | ターゲット |
|---|---|---|
|
oracle-bam(11.1.1) |
エンタープライズ・アプリケーション |
BAM_Cluster |
|
/oracle/bam |
WEBAPP |
WLS_BAM1 |
|
oracle-bam-adc-ejb.jar |
EJB |
WLS_BAM1 |
|
oracle-bam-ems-ejb.jar |
EJB |
WLS_BAM1 |
|
oracle-bam-eventengine-ejb.jar |
EJB |
WLS_BAM1 |
|
oracle-bam-reportcache-ejb.jar |
EJB |
WLS_BAM1 |
|
OracleBAM |
WEBAPP |
BAM_Cluster |
|
OracleBAMWS |
WEBAPP |
BAM_Cluster |
新しいドメイン構成を伝播するには:
SOAHOST2と同様のディレクトリと共有記憶域構成がBAMHOST1に存在することを確認します(第2章「データベースと環境の事前構成」を参照)。BAMHOST1およびBAMHOST2では、第4章「ドメインの作成」で作成したMW_HOMEディレクトリをマウントしている必要があります。
次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
次のコマンドを実行します。
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
次のようにpackコマンドを実行します。
SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/v -template=soadomaintemplateBAM.jar -template_name=soa_domain_templateBAM
次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをBAMHOST1にコピーします。
SOAHOST1> scp soadomaintemplateBAM.jar
oracle@BAMHOST1:/ORACLE_COMMON_HOME/common/bin
次のように、BAMHOST1でunpackコマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。
BAMHOST1> cd ORACLE_COMMON_HOME/common/bin BAMHOST1> ./unpack.sh -domain= ORACLE_BASE/admin/domain_name/mserver/domain_name -template=soadomaintemplateBAM.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
BAMHOST2に対してcopyコマンドとunpackコマンドを実行します。
この手順は、管理サーバーで様々なノードを認証するための適切な証明書を設定していない場合に必要です(第8章「ノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、様々なWebLogicサーバーを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際にホスト名の検証を無効にし、EDGトポロジの構成完了後に第8章「ノード・マネージャの設定」の説明に従って再びホスト名の検証を有効にします。
ホスト名検証を無効にする手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
管理コンソールで、「WLS_BAM1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
管理コンソールで、「WLS_BAM2」→「SSL」→「詳細」を選択します。
変更を保存してアクティブ化します。
次の手順を実行して、BAMHOST1およびBAMHOST2でノード・マネージャを起動します。
ノード・マネージャを起動する前に、各サーバーのORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
BAMHOSTn> cd ORACLE_COMMON_HOME/common/bin BAMHOSTn> ./setNMProps.sh
|
注意: クラスのロード失敗などの問題を回避するために、StartScriptEnabledプロパティを使用する必要があります。第10.7.5項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」も参照してください。 |
|
注意: 第2章「データベースと環境の事前構成」の共有記憶域構成で示しているように、BAMサーバーがローカル記憶域または共有記憶域でSOAとMW_HOMEを共有している場合には、setNMProps.shを再度実行する必要はありません。この場合、ノード・マネージャはすでに起動スクリプトを使用するように構成されています。 |
次のコマンドを実行し、BAMHOST1でノード・マネージャを起動します。
BAMHOST1> cd WL_HOME/server/bin BAMHOST1> ./startNodeManager.sh
次のコマンドを実行し、BAMHOST2でノード・マネージャを起動します。
BAMHOST2> cd WL_HOME/server/bin BAMHOST2> ./startNodeManager.sh
次の手順を実行して、BAMHOST1でWLS_BAM1管理対象サーバーを起動します。
WLS_BAM1管理対象サーバーを起動します。
http://ADMINVHN:7001/consoleのOracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
「制御」タブをクリックします。
表の「サーバー」列の「WLS_BAM1」を選択します。
「起動」をクリックします。
http://BAMHOST1VHN1:9001/OracleBAMにアクセスしてWLS_BAM1のステータスを確認します。
管理対象サーバーの起動に失敗すると次のメッセージが表示されます。
Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was <db_connect_string>
この場合は、データベースのPROCESSES初期化パラメータが十分に高い値に設定されていることを確認してください。詳細は、第2.1.1.3項「初期化パラメータ」を参照してください。このエラーが発生する可能性があるのは、1台のサーバーを起動した後で別のサーバーを起動した場合です。
WLS_BAM2管理対象サーバーを起動します。
http://ADMINVHN:7001/consoleのOracle WebLogic管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
「制御」タブをクリックします。
表の「サーバー」列の「WLS_BAM2」を選択します。
「起動」をクリックします。
http://BAMHOST2:9001/OracleBAMにアクセスしてWLS_BAM2のステータスを確認します。
|
注意: ここで示す手順は、SOAHOST2でWS-MまたはSOAの管理対象サーバーについて事前にホスト名の検証が行われており、さらに、SOAHOST2でノード・マネージャがすでに実行されていることを前提としています。 |
次の手順を実行して、BAMHOST1でBAMサーバーを使用するようにOracleBamWeb(WLS_BAM1)アプリケーションおよびOracleBamWeb(WLS_BAM2)アプリケーションを構成します。
http://ADMINVHN:7001/emのOracle Enterprise Manager Fusion Middleware Controlにアクセスします。
ナビゲーション・ツリーの「BAM」を開きます。
「OracleBamWeb(WLS_BAM1)」を右クリックします。
コンテキスト・メニューから「BAM Webプロパティ」を選択します。「BAM Webプロパティ」ページが表示されます。
次のプロパティを定義します。
アプリケーションURLにhttps://soa.mycompany.com:443と入力します。
サーバー名にBAMHOST1VHN1と入力します。第2.2.3項「IPと仮想IP」の表2-2も参照してください。
Mbeanブラウザを使用し、サーバーのリスニング・ポートを変更します。これを実行する手順は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlにログインします。
左側のナビゲーション・ツリーのドメイン名を展開します。
左側のナビゲーション・ツリーのBAM項目を展開します。
右上のBAMドロップダウン・メニューから「MBeanブラウザ」を選択します。
右側で「oracle.bam.web」→「サーバー」→「アプリケーション」→「構成」→「BAMWebConfig」に移動します。
「ServerPort」フィールドの「デフォルト」値を「9001」に置き換えます。
ナビゲーション・ツリーで「OracleBamWeb(WLS_BAM2)」を選択し、同じ手順を繰り返します。
WLS_BAMn管理対象サーバーが属するBAM_ClusterにOracle HTTP Serverからルーティングをできるようにするには、次のようにWebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。
次の行をORACLE_BASE/admin/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに追加します。
# BAM Web Application
<Location /OracleBAM >
SetHandler weblogic-handler
WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /OracleBAMWS >
SetHandler weblogic-handler
WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
WEBHOST1およびWEBHOST2の両方で、次のようにOracle HTTP Serverを再起動します。
WEBHOST1> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs2
URLを検証して、HTTP ServerからBAM_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。URLを検証する手順は次のとおりです。
WLS_BAM2が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_BAM1を停止します。
WebHost1:7777/OracleBAMにアクセスして正常に機能していることを確認します (BAMサーバーが停止しているので、レポートやデータは取得できません)。
Oracle WebLogic Server管理コンソールでWLS_BAM1を起動します。
Oracle WebLogic Server管理コンソールでWLS_BAM2を停止します。
WebHost1:7777/OracleBAMにアクセスして正常に機能していることを確認します
BAMの高可用性アーキテクチャでは、サーバーの移行を使用してBAMサーバーのシングルトン・サービスを障害から保護します。障害が発生した場合にBAMHOST2で再起動できるようにWLS_BAM1管理対象サーバーを構成します。この構成では、WebLogic Serverの移行によってフェイルオーバーの対象となる特定の浮動IPをWLS_BAM1でリスニングします。WLS_BAM1管理対象サーバーのサーバー移行を構成する手順は次のとおりです。
ステップ1: サーバー移行リース・テーブルのユーザーおよび表領域の設定
ステップ3: ノード・マネージャのプロパティ・ファイルの編集
ステップ6: サーバー移行ターゲットの構成
ステップ7: サーバー移行のテスト
|
注意: SOAに対してサーバーの移行を構成済であれば、それと同じデータ・ソースとデータベース・スキーマをBAMステムで使用できます。この場合、ステップ1から4は不要な場合もありますが、対応するサーバー移行/リース・データソースもBAMクラスタにターゲット設定する必要があります。 |
次の手順を実行してユーザーと表領域を作成します。
leasingという表領域を作成します。たとえば、SYSDBAユーザーとしてSQL*Plusにログオンし、次のコマンドを実行します。
SQL> create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;
次のように、leasingという名前のユーザーを作成し、leasing表領域に割り当てます。
SQL> create user leasing identified by welcome1; SQL> grant create table to leasing; SQL> grant create session to leasing; SQL> alter user leasing default tablespace leasing; SQL> alter user leasing quota unlimited on LEASING;
次のように、leasing.ddlスクリプトを使用してリース・テーブルを作成します。
WL_HOME/server/db/oracle/920ディレクトリにあるleasing.ddlファイルを、使用するデータベース・ノードにコピーします。
leasingユーザーとしてデータベースに接続します。
次のように、leasing.ddlスクリプトをSQL*Plusで実行します。
SQL> @copy_location/leasing.ddl;
Oracle WebLogic Server管理コンソールを使用して、リース・テーブル用のマルチデータ・ソースを作成します。マルチデータ・ソースの設定プロセス中に、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバル・リース・マルチデータ・ソースの両方に対して作成します。このデータ・ソースを作成する手順は次のとおりです。
該当のデータソースが非XAデータ・ソースであることを確認します。
マルチ・データ・ソースの名前は、<MultiDS>-rac0や<MultiDS>-rac1という形式にします。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10または11を使用します。
データソースは、グローバル・トランザクションのサポートを必要としません。したがって、データソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
これらのデータ・ソースのターゲットをBAMクラスタに設定します。
データソースの接続プールの初期容量が0に設定されていることを確認してください。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」をクリックして「接続プール」タブをクリックし、「初期容量」フィールドに「0」と入力します。
Oracle WebLogic Server管理コンソールによるマルチデータ・ソース作成の詳細は、第9.2項「Oracle WebLogic Server管理コンソールでのマルチデータ・ソースの作成」を参照してください。
nodemanager.propertiesファイルは、WL_HOME/common/nodemanagerディレクトリにあります。
次のプロパティを追加してサーバー移行が正常に動作するようにします。
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
Interface
このプロパティは浮動IP(eth0など)のインタフェース名を指定します。
|
注意: eth0:1やeth0:2のようなサブ・インタフェースは指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値はeth0、eth1、eth2、eth3またはethnで、いずれになるかは、構成されているインタフェースの数によって異なります。 |
NetMask
このプロパティは浮動IP用インタフェースのネット・マスクを指定します。
UseMACBroadcast
このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。
サーバーを実行する2つのノードでこの構成を行います。ノード・マネージャの出力(ノード・マネージャを起動するシェル)で、これらのプロパティが使用されていることを確認します。使用されていないプロパティがあると、移行中に問題が発生することがあります。出力は次のようになります。
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
|
注意: サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。 |
nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動できるようにするために必要です。
WL_HOME/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。
|
注意: 共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、NetMaskプロパティやInterfaceプロパティにはノードごとに異なる値が必要です。この場合、環境変数を使用してノードごとに個別のパラメータを指定します。たとえば、SOAHOSTnで異なるインタフェース(eth3)を使用するには、SOAHOSTn> export JAVA_OPTIONS=-DInterface=eth3としてInterface環境変数を使用します。この環境変数をシェルに設定した後、ノード・マネージャを起動します。 |
次の手順を実行してwlsifconfig.shスクリプトの環境とスーパー・ユーザー権限を設定します。
表7-5に示すファイルをPATH環境変数で指定していることを確認します。
sudoの構成をwlsifconfig.shスクリプトに付与します。
パスワードの要求がなくても動作するようにsudoを構成します。
セキュリティ上の理由から、sudoの付与はwlsifconfig.shスクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパー・ユーザー権限を設定する手順は次のとおりです。
パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
|
注意: この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。 |
クラスタの移行を構成すると、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。次の手順を実行して、クラスタでクラスタの移行を構成します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
表の「名前」列で、移行を構成するクラスタ(BAM_Cluster)をクリックします。
「移行」タブをクリックします。
「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。この場合は、「BAMHOST1」と「BAMHOST2」を選択します。
自動移行に使用するデータソースを選択します。この場合は、リース・データソースを選択します。
「保存」をクリックします。
サーバー移行の候補となるマシンを次のように設定します。
|
注意: WLS_BAM2はサーバーの移行には使用しないため、この作業はWLS_BAM1のみに行ってください。 |
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。WLS_BAM1についてBAMHOST2を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。
「保存」をクリックします。
管理サーバーとWLS_BAM1サーバーを再起動します。
管理サーバーを再起動するには、第4.7項「SOAHOST1での管理サーバーの起動」の手順を使用します。
次の手順を実行して、サーバー移行が適切に機能することを確認します。
ノード1で次の操作を実行します。
WLS_BAM1管理対象サーバーを停止します。
停止するには、次のコマンドを実行します。
BAMHOST1> kill -9 <pid>
<PID>には管理対象サーバーのプロセスIDを指定します。ノード内のPIDは、次のコマンドを実行して識別できます。
BAMHOST1> ps -ef | grep WLS_BAM1
ノード・マネージャのコンソールを確認します。WLS_BAM1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_BAM1の2回目の再起動を試行するまで待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再び再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
ノード2で次の操作を実行します。
ローカル・ノード・マネージャのコンソールを確認します。ノード1でのWLS_BAM1の再起動が前回試行されてから30秒間経過した後に、WLS_BAM1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。
BAMHOST1VHN1とsoa.mycompany.com/OracleBAMを使用してOracle BAMコンソールにアクセスします。
移行は次のように管理コンソールで確認することもできます。
管理コンソールにログインします。
左のコンソールで「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」タブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。
クラスタ化された環境でOracle BAMを使用している場合、あるノードにおいてOracle Enterprise Managerで構成プロパティを変更したら、それをすべてのノードに反映させる必要があります(1つのサーバーに構成変更を適用しても、BAMクラスタのすべてのサーバーに自動的に適用されるわけではありません)。また、BAM EDGトポロジでBAMサーバーに構成変更を行う場合には、次の作業も検討してください。
サーバーの移行機能を使用すると、BAMサーバーは別のノードのドメイン・ディレクトリに移動します。BAMサーバー構成は、フェイルオーバー・ノード内であらかじめ作成しておく必要があります。このBAMサーバー構成ファイルは、次のディレクトリにあります。
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> /servers/<servername>/tmp/_WL_user/oracle-bam_11.1.1
/*/APP-INF/classes/config/
「*」はOracle WebLogic Serverによってデプロイメント時にランダムに生成されるディレクトリ名、たとえば3682yqを表します。
フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。たとえば、BAMの場合の手順は次のとおりです。
WLS_BAM1のドライバをBAMHOST1内で構成します。
BAMHOST2へのWLS_BAM1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内のBAMサーバーのディレクトリ構造を確認してください。
cd ORACLE_BASE/admin/<domain_name>/mserver/
<domain_name>/servers/<servername>/tmp/_WL_user/oracle-bam_11.1.1
/*/APP-INF/classes/config/
「*」はOracle WebLogic Serverによってデプロイメント時にランダムに生成されるディレクトリ名、たとえば3682yqを表します。
BAMアダプタ(rmi)を使用しOracle BAM Serverにアクセスする場合、接続にはBAMサーバー(BAMHOST1VNH1)の仮想ホスト名を使用する必要があります。SOAPリクエストはHTTPで受信されるので、この場合にアダプタを使用する場合はLBRアドレスを使用する必要があります。
拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、このガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、このガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、このガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ガイドも参照してください。
次の手順を実行して、この時点でのインストールをバックアップします。
Web層をバックアップする手順は次のとおりです。
opmnctlを使用してインスタンスを停止します。
ORACLE_BASE/admin/<instance_name>/bin/opmnctl stopall
次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
opmnctlを使用してインスタンスを起動します。
ORACLE_BASE/admin/<instance_name>/bin/opmnctl startall
データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。
管理サーバーのドメイン・ディレクトリをバックアップします。バックアップを実行してドメイン構成を保存します。構成ファイルは、すべてORACLE_BASE/admin/<domain_name>ディレクトリの下にあります。
SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/<domain_name>
