| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 12c (12.1.3) E53006-03 |
|
 前 |
 次 |
この章では、エンタープライズ・デプロイメント環境で実行する必要性が高い、構成および管理タスクについて説明します。
この章には次の項が含まれます:
次の項では、Oracle Fusion Middlewareエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの一般的な構成および管理タスクについて説明します。
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次に、SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。
前提条件:
管理サーバーを、localhostまたは任意のアドレスではなく、ADMINVHN上でリスニングするように構成します。
ADMINVHN仮想IPアドレスの詳細は、第5.2項「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。
この手順では、管理サーバーのドメイン・ホーム(ASERVER_HOME)が両方のホスト・コンピュータにマウントされていることを前提にしています。これにより、管理サーバーのドメイン構成ファイルと永続ストアが、共有記憶域デバイスに保存されるようになります。
管理サーバーはSOAHOST1からSOAHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。
SOAHOST1: 100.200.140.165
SOAHOST2: 100.200.140.205
ADMINVHN : 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、SOAHOST1とSOAHOST2からアクセスできます。
Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、SOAHOST2にインストールされています。
具体的には、両方のホスト・コンピュータは、まったく同じパスを使用してOracleホームのバイナリ・ファイルを参照します。
この項には次のトピックが含まれます:
次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。
管理サーバーを別のホストにフェイルオーバーするには:
管理サーバーを停止します。
管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。
ADMINVHN仮想IPアドレスを第2ホストに移行します。
SOAHOST1上で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。
/sbin/ifconfig ethX:Y down
次のコマンドをSOAHOST2上でrootとして実行します。
/sbin/ifconfig <interface:index> ADMINVHN netmask <netmask>
例:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります。 |
次の例のように、arpingを使用してルーティング表を更新します。
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
SOAHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。
詳細は、第10.6.1項「SOAHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動」を参照してください。
SOAHOST2上で管理サーバーを起動します。
詳細は、第10.6.3項「管理サーバーの起動」を参照してください。
次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。
次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN:7001/console
次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。
http://ADMINVHN:7001/em
第11.7.4項「ロード・バランサでの仮想サーバー構成の検証」と同じ手順を実行します。この目的は、SOAHOST2で実行している管理サーバーにもアクセスできることを確認することです。
この手順では、管理サーバーをフェイルバックできること、つまり、SOAHOST2で実行している管理サーバーを停止し、ADMINVHNをSOAHOST1ノードに戻して、SOAHOST1で再び管理サーバーを実行できることを確認します。
ADMINVHNをSOAHOST1に戻す手順は次のとおりです。
管理サーバーを停止します。
SOAHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを停止します。
次のコマンドをSOAHOST2上でrootとして実行します。
/sbin/ifconfig ethZ:N down
次のコマンドをSOAHOST1上でrootとして実行します。
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースは、SOAHOST1で使用可能なネットワーク構成と一致している必要があります。 |
SOAHOST1上でarpingを使用して、ルーティング表を更新します。
/sbin/arping -q -U -c 3 -I ethZ 100.200.140.206
SOAHOST1上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。
SOAHOST1上で管理サーバーを起動します。
次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。
http://ADMINVHN:7001/console
次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。
http://ADMINVHN:7001/em
次の項では、中間層とハードウェア・ロード・バランサ間のSSL通信を有効にする方法を説明します。
|
注意: この手順は、ハードウェア・ロード・バランサにSSLが構成されており、その結果システムのフロント・エンド・アドレスが保護されている場合に使用できます。 |
エンタープライズ・デプロイメントには、中間層で実行されているソフトウェアが、ハードウェア・ロード・バランサのフロントエンドSSLアドレスにアクセスしなければならないシナリオがあります。このシナリオでは、ロード・バランサと起動サーバー間で、適切なSSLハンドシェイクが行われる必要があります。中間層の管理サーバーと管理対象サーバーが適切なSSL構成を使用して起動されていない場合は、このハンドシェイクを実行できません。
たとえば、Oracle SOA Suiteエンタープライズ・デプロイメントでは、次のような例が該当します。
Oracle Business Process Managementは、特定のWebサービス経由でロール情報を取得しようとするときに、フロントエンド・ロード・バランサのURLにアクセスする必要がある。
Oracle Service Busは、ロード・バランサのSSL仮想サーバーで公開されているエンドポイントに対する呼出しを実行する。
Oracle SOA Suiteのコンポジット・アプリケーションとサービスは、ロード・バランサで公開されているSSLアドレスを使用して呼出しを実行する必要のあるコールバックを、頻繁に生成する。
Oracle Enterprise Manager Fusion Middleware ControlでSOA Webサービスのエンドポイントをテストするとき、管理サーバーで実行されているFusion Middleware Controlソフトウェアは、ロード・バランサのフロントエンドにアクセスして、エンドポイントを検証する必要がある。
この項では、SOAHOST1に自己署名証明書を作成する手順を説明します。これらの証明書は、ネットワーク名またはホストの別名を使用して作成します。
キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、SOAHOST2では、SOAHOST1の証明書用に作成されたcertディレクトリを使用します。
かわりに信頼できるCA証明書を使用する方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する情報を参照してください。
パスワードについて
このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。
自己署名証明書を作成する手順は次のとおりです。
WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。
Bourneシェルで次のコマンドを実行します。
. setWLSEnv.sh
CLASSPATH環境変数が設定されていることを確認します。
echo $CLASSPATH
証明書用のユーザー定義ディレクトリを作成します。
mkdir ASERVER_HOME/certs
ディレクトリをユーザー定義ディレクトリに変更します。
cd ASERVER_HOME/certs
ユーザー定義ディレクトリからutils.CertGenツールを実行して、ノード内のサーバーによって使用される物理ホスト名と仮想ホスト名の両方に対応する証明書を作成します。
構文:
java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]
例:
java utils.CertGen password ADMINVHN.example.com_cert \
ADMINVHN.example.com_key domestic ADMINVHN.example.com
java utils.CertGen password SOAHOST1.example.com_cert \
SOAHOST1.example.com_key domestic SOAHOST1.example.com
java utils.CertGen password SOAHOST1VHN1.example.com_cert \
SOAHOST1VHN1.example.com_key domestic SOAHOST1VHN1.example.com
この項では、SOAHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。
前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、SOAHOST1とSOAHOST1VHN1両方の証明書と秘密鍵が新しいアイデンティティ・ストアにインポートされます。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
|
注意: アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。 |
ADMINVHN、SOAHOST1およびSOAHOST1VHN1の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
構文:
java utils.ImportPrivateKey keystore_file keystore_password certificate_alias_to_use private_key_passphrase certificate_file private_key_file keystore_type
|
注意: デフォルトのkeystore_typeはjksです。 |
例:
java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity1 password
ASERVER_HOME/certs/SOAHOST1.example.com_cert.pem
ASERVER_HOME/certs/SOAHOST1.example.com_key.pem
java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity2 password
ASERVER_HOME/certs/SOAHOST1VHN1.example.com_cert.pem
ASERVER_HOME/certs/SOAHOST1VHN1.example.com_key.pem
java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity3 password
ASERVER_HOME/certs/ADMINVHN.example.com_cert.pem
ASERVER_HOME/certs/ADMINVHN.example.com_key.pem
前述の手順を、システム内で使用される残りのすべてのホスト(SOAHOST2、SOAHOST2VHN1、WEBHOST1、WEBHOST2、およびOSBまたはBAMサーバーが使用される場合は、SOAHOST1VHN2、SOAHOST2VHN2など)で繰り返します。
SOAHOST1.example.comに信頼キーストアを作成するには:
新しい信頼キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJava信頼キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアのCA証明書を、証明書のあるディレクトリにコピーします。例:
cp WL_HOME/server/lib/cacerts ASERVER_HOME/certs/appTrustKeyStore.jks
標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。パスワードを変更するにはkeytoolユーティリティを使用します。構文は次のとおりです。
keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password
例:
keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit
このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用され、WL_HOME/server/libディレクトリに存在しています。このCA証明書は、keytoolユーティリティを使用してappTrustKeyStoreにインポートする必要があります。構文は次のとおりです。
keytool -import -v -noprompt -trustcacerts -alias AliasName -file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password
例:
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password
SSLハンドシェイクが適切に行われるには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。追加するには、次の手順を実行します。
ブラウザでSSLのサイトにアクセスします(これにより、サーバーの証明書がブラウザのリポジトリに追加されます)。
ブラウザの証明書管理ツールから、証明書を、SOAサーバーのファイル・システムにある(soa.example.comのようなファイル名を持つ)ファイルにエクスポートします。
keytoolを使用して、ロード・バランサの証明書をトラスト・ストアにインポートします。
keytool -import -file soa.exmaple.com -v -keystore appTrustKeyStore.jks
setDomainEnv.shスクリプトは、Oracle WebLogic Serverによって提供され、ドメイン内の管理サーバーと管理対象サーバーの起動に使用できます。
各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetDomainEnv.shスクリプトを次のように編集します。
SOAHOST1にログインして、テキスト・エディタで次のファイルを開きます。
ASERVER_HOME/bin/setDomainEnv.sh
既存のDemoTrustStoreエントリへの参照を、次に置き換えます。
EXTRA_JAVA_PROPERTIESのすべての値をファイル内に1行で記述し、その後の新規行にexportコマンドを記述する必要があります。
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
-Dsoa.archives.dir=${SOA_ORACLE_HOME}/soa ...
-Djavax.net.ssl.trustStore=/u01/oracle/certs/appTrustKeyStore.jks..."
export EXTRA_JAVA_PROPERTIES
SOAHOST1、SOAHOST2、WEBHOST1、WEBHOST2のMSERVER_HOME/binディレクトリにあるsetDomainEnv.shファイルに、同じ変更を行います。
あるいは、setUserOverrides.shファイルを使用して、これらのオプションを配置できます。この方法では、ドメインのスクリプトが構成ウィザードによって拡張されたり、解凍操作によって更新されたりする場合にも、これらのオプションは上書きされません。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。
カスタム・キーストアを使用するようにノード・マネージャを構成するには、すべてのノード内のASERVER_HOME/nodemanagerディレクトリとMSERVER_HOME/nodemanagerディレクトリの両方にあるnodemanager.propertiesファイルの最後に次の行を追加します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=Identity KeyStore CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd CustomIdentityAlias=Identity Key Store Alias CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate
ノード・マネージャのリスニング・アドレスのCustomIdentityAliasには必ず正しい値を使用してください。たとえば、SOAHOST1では、「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従って、appIdentity1を使用します。
(appIdentity1 mapped to the SOAHOST1 listen address). Example for Node 1: KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=/u01/oracle/config/domains/soaedg_domain/certs/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=password CustomIdentityAlias=appIdentity1 CustomIdentityPrivateKeyPassPhrase=password
「SOAHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリは暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイルのエントリが暗号化されていない状態になる時間は最小限に抑えてください。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。
Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。管理サーバー、WLS_SOAnサーバーや、SSL上のフロント・エンドLBRへのアクセスが必要な他のサーバーに対して、この手順を実行します。
手順6のディレクトリ・パスは例です。キーストアは、aserverディレクトリではなく共有記憶域に配置することをお薦めします。証明書用のディレクトリとは別のディレクトリに配置する方がより適切です。
IDキーストアおよび信頼キーストアを構成するには:
管理コンソールにログインして「ロックして編集」をクリックします。
左ペインで「環境」を開き、「サーバー」を選択します。
アイデンティティと信頼キーストアを構成するサーバーの名前をクリックします。
「構成」を選択して、「キーストア」を選択します。
「キーストア」フィールドで、「変更」をクリックし、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択して、「保存」をクリックします。
「ID」セクションで、アイデンティティ・キーストアの属性を定義します。
カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。
ASERVER_HOME/certs/appIdentityKeyStore.jks
カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。
カスタムIDキーストアのパスフレーズ: 「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します。
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。
「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。
カスタム信頼キーストア: トラスト・キーストアの完全修飾パスを入力します。
ASERVER_HOME/certs/appTrustKeyStore.jks
カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。
カスタム信頼キーストアのパスフレーズ: 「keytoolユーティリティを使用した信頼キーストアの作成」で、新規パスワードとして指定したパスワード。
前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。
「保存」をクリックします。
これらの変更を有効にするために、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。
「ロックして編集」をクリックします。
「構成」をクリックし、「SSL」をクリックします。
「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。
「保存」をクリックします。
「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
変更を適用したサーバーを再起動します。管理コンソール/ノード・マネージャを使用してサーバーを再起動できるということは、ノード・マネージャ、管理サーバー、および管理対象サーバー間の通信が正常であるということです。
SSLが有効になると、Oracle Enterprise Manager FMW Controlから、SSL上のコンポジット・エンドポイントを検証できます。SSLエンドポイントをテストするには、次の手順に従います。
ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
http://ADMINVHN:7001/em
この例では、次のようになります。
ADMINVHNを、第5.3項「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。
ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。
管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
左側のツリーから、SOAを開きます。「soa-infra」(WLS_SOAn)をクリックして、コンポジットがデプロイされたパーティションを選択します。
コンポジットを選択します。
右側のペインで、「テスト」タブをクリックします。
WSDLまたはWADLアドレスで、http://soa.example.com:80をhttps://soa.example.com:443に置き換えます。
「WSDLまたはWADLの解析」をクリックします。
表示されるエンドポイントURLがSSLであることを確認します。
コンポジットをテストします。Webサービスのレスポンスが期待どおりであれば、管理サーバーとロード・バランサ間のSSL通信は正常に構成されています。
次の項では、Oracle SOA Suiteエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの主要な構成および管理タスクについて説明します。
各Oracle SOA Suiteエンタープライズ・デプロイメントは、複数のOracle SOA Suite製品で構成されています。Oracle SOA Suite製品の一部には、各製品への管理アクセスの制御に使用される、特定の管理ユーザー、ロールまたはグループが存在します。
ただし、複数のOracle SOA Suite製品で構成されているエンタープライズ・デプロイメントでは、単一のLDAPベースの認可プロバイダと、単一の管理ユーザーおよびグループを使用して、デプロイメントのあらゆる側面に対するアクセスを制御できます。認可プロバイダの作成と、エンタープライズ・デプロイメントの管理ユーザーおよびグループのプロビジョニングの詳細は、第 10.9項を参照してください。
単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理できるようにするには、特定の管理ロールまたはグループを必要とする製品を理解すること、単一の共通エンタープライズ・デプロイメントの管理グループに特定の製品管理ロールを追加する方法を知ること、さらに必要な場合は、必須の製品固有の管理グループにエンタープライズ・デプロイメントの管理ユーザーを追加する方法を知ることが必要になります。
詳細な情報は、次のトピックを参照してください:
表18-1には、エンタープライズ・デプロイメントの管理グループに追加する必要のある特定の管理ロールを持つ、Oracle SOA Suite製品のリストを示します。
Oracle SOA Suiteエンタープライズ・デプロイメントでは、エンタープライズ・デプロイメント用のLDAP認可プロバイダで定義されているSOA管理グループを使用します。
表にある情報と第18.2.1.3項の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。
表18-2には、特定の管理グループを使用する必要のあるOracle SOA Suite製品のリストを示します。
これらのコンポーネントごとに、共通エンタープライズ・デプロイメントの管理ユーザーを製品固有の管理グループに追加する必要があります。追加しなければ、第10.9.5項「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」で作成したEnterprise Managerの管理ユーザーを使用して製品リソースを管理できません。
表18-2にある情報と第18.2.1.4項の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。
製品固有の管理ロールを必要とする製品では、次の手順を使用して、その管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。
Oracle WebLogic Server管理サーバーの資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。
これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic)とパスワードを作成したときに作成した資格証明です。
「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
表18-2の製品固有のアプリケーション・ロールごとに、「アプリケーション・ストライプ」ドロップダウン・メニューから対応するアプリケーション・ストライプを選択します。
「アプリケーション・ロールの検索」アイコン
をクリックして、ドメインで利用できるすべてのアプリケーション・ロールを表示します。
エンタープライズ・デプロイメントの管理グループに追加するアプリケーション・ロールの行を選択します。
「編集」アイコン
をクリックして、ロールを編集します。
「アプリケーション・ロールの編集」ページの「追加」アイコン
をクリックします。
「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。
「プリンシパル名」の「次で始まる」フィールドに、SOA Administratorsと入力します。右矢印をクリックして、検索します。
「SOA Administrators」を選択して、「OK」をクリックします。
「アプリケーション・ロールの編集」ページで、「OK」をクリックします。
製品固有の管理グループを持つ製品では、次の手順を使用して、エンタープライズ・デプロイメントの管理ユーザーをグループに追加します。これにより、Enterprise Managerの管理者ユーザーを使用して製品を管理できるようになります。
以下に示すような、product_admin_group.ldifというLDIFファイルを作成します。
dn: cn=product-specific_group_name, cn=groups, dc=us, dc=oracle, dc=com displayname: product-specific_group_display_name objectclass: top objectclass: groupOfUniqueNames objectclass: orclGroup uniquemember: cn=weblogic_soa,cn=users,dc=us,dc=oracle,dc=com cn: product-specific_group_name description: Administrators Group for the OSB Domain
この例では、product-specific_group_nameを、表18-2で示す製品管理者グループの実際の名前と置き換えます。
product-specific_group_display_nameを、LDAPサーバーの管理コンソールとOracle WebLogic Server管理コンソールに表示されるグループの表示名と置き換えます。
LDIFファイルを使用して、エンタープライズ・デプロイメントの管理者ユーザーを製品固有の管理グループに追加します。
Oracle Unified Directoryの場合:
OUD_INSTANCE_HOME/bin/ldapmodify -a
-D "cn=Administrator"
-X
-p 1389
-f product_admin_group.ldif
Oracle Internet Directoryの場合:
OID_ORACLE_HOME/bin/ldapadd -h oid.example.com
-p 389
-D cn="orcladmin"
-w <password>
-c
-v
-f product_admin_group.ldif
Oracle SOA Suiteアプリケーションは、様々な種類のOracle SOA Suiteコンポーネントから構成されるコンポジットとしてデプロイされます。SOAコンポジット・アプリケーションには次が含まれます。
サービス・コンポーネント。ルーティングのためのOracle Mediator、オーケストレーションのためのBPELプロセス、オーケストレーションのためのBAMプロセス(Oracle BAM Suiteがインストールされている場合)、ワークフロー承認のためのヒューマン・タスク、SOAコンポジット・アプリケーションにJavaインタフェースを統合するためのSpring、ビジネス・ルールを使用するためのデシジョン・サービスなどがあります。
外部のサービス、アプリケーションおよびテクノロジに対してSOAコンポジット・アプリケーションを接続するバインディング・コンポーネント(サービスと参照)
これらのコンポーネントが、1つのSOAコンポジット・アプリケーションに組み込まれています。
Oracle SOA Suiteコンポジット・アプリケーションをOracle SOA Suiteエンタープライズ・デプロイメントにデプロイするときは、必ず各コンポジットを、ロード・バランサ・アドレス(soa.example.com)ではなく、特定のサーバーまたはクラスタ・アドレスにデプロイしてください。
ロード・バランサ・アドレスにコンポジットをデプロイするには、多くの場合、デプロイヤ・ノードから外部のロード・バランサ・アドレスへの直接接続が必要になります。そのため、ファイアウォールに追加のポートを開く必要があります。
Oracle SOA Suiteコンポジット・アプリケーションの詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理の次の項を参照してください。
SOAコンポジット・アプリケーションのデプロイ
SOAコンポジット・アプリケーションの監視
SOAコンポジット・アプリケーションの管理
第16章のOracle BAMの構成手順には、Oracle BAMが必要とするサーバー固有の固定JMSサービスおよびJTAサービスに対して自動サービス移行を構成する手順が含まれています。
ただし、自動サービス移行が発生した場合、Oracle WebLogic Serverでは、サーバーがオンラインに戻りクラスタに再度参加するときに、サービスが元のサーバーにフェイルバックすることはサポートされません。
そのため、フェイルオーバー中に、自動サービス移行によって特定のJMSサービスがバックアップ・サーバーに移行されたあとは、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。かわりに、サービスを元のサーバーに手動で移行する必要があります。
サービスを元のサーバーにフェイルバックするには、次の手順を実行します。
まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「移行可能なターゲット」を選択します。
1つ以上の移行可能なターゲットを一度に移行するには、「移行可能なターゲットのサマリー」ページで次を実行します。
「制御」タブをクリックします。
チェック・ボックスを使用して、移行する1つまたは複数の移行可能なターゲットを選択します。
「移行」をクリックします。
「新しいホスト・サーバー」ドロップダウンを使用して、移行可能なターゲットのための新しいサーバーを選択します。
「OK」をクリックします。
JMS関連サービスを移行するためのリクエストが発行され、構成編集ロックが解除されます。「移行可能なターゲット」表の「最後の移行のステータス」列に、リクエストされた移行が成功したのか、失敗したのかが示されます。
特定の移行可能なターゲットを移行するには、「移行可能なターゲットの概要」ページで、次の手順を実行します。
移行する移行可能なターゲットを選択します。
「制御」タブをクリックします。
再度、移行する移行可能なターゲットを選択します。
「移行」をクリックします。
「新しいホスト・サーバー」ドロップダウンを使用して、移行可能なターゲットのための新しいサーバーを選択します。
「OK」をクリックします。
SOAクラスタ内のSOAインフラストラクチャ・アプリケーションまたはリソース・アダプタを再デプロイするときは、デプロイメント・プランとアプリケーション・ビットに、クラスタ内の全サーバーからアクセスできる必要があります。
SOAのアプリケーションおよびリソース・アダプタは、nostageデプロイメント・モードを使用してインストールされます。nostageデプロイメント・モードを選択した場合、管理サーバーはアーカイブ・ファイルをソースの場所からコピーしないため、各サーバーが同じデプロイメント・プランにアクセスできるようにしておく必要があります。
デプロイメント・プランの場所がドメイン内のすべてのサーバーで利用できるようにするには、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」で示され、エンタープライズ・デプロイメント・ワークブック内のDEPLOY_PLAN_HOME変数で表される、デプロイメント・プランのホームの場所を使用します。
Oracle SOA Suiteデータベースのデータ量が非常に多くなると、特に多くのコンポジット・アプリケーションがデプロイされている可能性のあるOracle SOA Suiteエンタープライズ・デプロイメントでは、データベースの保守が難しくなることがあります。
詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理の次の項を参照してください。
データベース増分管理戦略の策定に関する項
データベース増分の管理に関する項
この項では、Oracle SOA Suiteエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。
Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。
「環境のバックアップ」
「環境のリカバリ」
表18-3は、一般的なOracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。
表18－3 Oracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト
| タイプ | ホスト | 層 |
|---|---|---|
|
データベースOracleホーム |
DBHOST1およびDBHOST2 |
データ層 |
|
Oracle Fusion Middleware Oracleホーム |
WEBHOST1およびWEBHOST2 |
Web層 |
|
Oracle Fusion Middleware Oracleホーム |
SOAHOST1およびSOAHOST2 |
アプリケーション層 |
|
インストール関連ファイル |
WEBHOST1、WEHOST2および共有記憶域 |
N/A |
表18-4は、一般的なOracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。
表18－4 Oracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト
| タイプ | ホスト | 層 |
|---|---|---|
|
管理サーバーのドメイン・ホーム(ASERVER_HOME) |
SOAHOST1およびSOAHOST2 |
アプリケーション層 |
|
アプリケーション・ホーム(APPLICATION_HOME) |
SOAHOST1およびSOAHOST2 |
アプリケーション層 |
|
Oracle RACデータベース |
DBHOST1およびDBHOST2 |
データ層 |
|
スクリプトとカスタマイズ |
SOAHOST1およびSOAHOST2 |
アプリケーション層 |
|
デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME) |
SOAHOST1およびSOAHOST2 |
アプリケーション層 |
