この項では、エンタープライズ・デプロイメント環境で実行する必要がある構成および管理タスクについて説明します。
ここに示すのは、Oracle Fusion Middlewareエンタープライズ・デプロイメントで実行する必要性が高い一般的な構成および管理タスクです。
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する手順は、これ以降の項で詳細に説明します。
前提条件:
管理サーバーを、localhostまたは任意のアドレスではなく、ADMINVHN上でリスニングするように構成します。
ADMINVHN仮想IPアドレスの詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。
この手順では、管理サーバーのドメイン・ホーム(ASERVER_HOME)が両方のホスト・コンピュータにマウントされていることを前提にしています。これにより、管理サーバーのドメイン構成ファイルと永続ストアが、共有記憶域デバイスに保存されるようになります。
管理サーバーはSOAHOST1からSOAHOST2アプリケーションにフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。
SOAHOST1: 100.200.140.165
SOAHOST2: 100.200.140.205
ADMINVHN : 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、SOAHOST1 or SOAHOST2で使用可能な仮想サブインタフェース(eth0:1など)に割り当てられます。
Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、SOAHOST2にインストールされています。
具体的には、両方のホスト・コンピュータは、まったく同じパスを使用してOracleホームのバイナリ・ファイルを参照します。
次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。
この手順では、「ホストごとのノード・マネージャ構成の作成」の説明に従って、エンタープライズ・トポロジにホストごとのノード・マネージャが構成されていることを前提としています。詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。
管理サーバーを別のホストにフェイルオーバーするには:
SOAHOST1で管理サーバーを停止します。
SOAHOST1でノード・マネージャを停止します。
このガイドの前半で示した手順を使用してホストごとのノード・マネージャを起動した場合、ノード・マネージャを起動したターミナル・ウィンドウに戻り、[Ctrl]キーを押しながら[C]キーを押してプロセスを停止します。
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
SOAHOST1で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
cd NM_HOME
nodemanager.domains
ファイルを編集し、ASERVER_HOMEへの参照を削除します。
SOAHOST1 nodemanager.domains
ファイルで次のようなエントリが生成されます。
soaedg_domain
=MSERVER_HOME;
SOAHOST2で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
cd NM_HOME
nodemanager.domains
ファイルを編集し、MSERVER_HOMEへの参照を追加します。
SOAHOST2 nodemanager.domains
ファイルで次のようなエントリが生成されます。
soaedg_domain
=MSERVER_HOME;ASERVER_HOME
SOAHOST1でノード・マネージャを起動し、SOAHOST2でノード・マネージャを再起動します。
SOAHOST2で管理サーバーを起動します。
次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。
次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN:7001/console
次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。
http://ADMINVHN:7001/em
管理サーバーの手動フェイルオーバーを実行したら、標準の管理URLを使用して管理サーバーにアクセスできるかを確認することが重要です。
ロード・バランサから次のURLにアクセスして、SOAHOST2で稼働中の管理サーバーにアクセスできることを確認します。
http://admin.example.com/console
このURLはWebLogic Server管理コンソールを表示するはずです。
http://admin.example.com/em
このURLはOracle Enterprise Manager Fusion Middleware Controlを表示するはずです。
管理サーバーの手動フェイルオーバーをテストし、フェイルオーバー後に管理URLにアクセスできることを確認したら、管理サーバーを元のホストに戻すことができます。
この手順では、「ホストごとのノード・マネージャ構成の作成」の説明に従って、エンタープライズ・トポロジにホストごとのノード・マネージャが構成されていることを前提としています。詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。
中間層とハードウェア・ロード・バランサ間の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設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造について」に記載されているKEYSTORE_HOMEの場所に対するファイル・システムの指定に関する情報を参照してください。
かわりに信頼できるCA証明書を使用する方法は、Oracle Fusion Middleware Oracle WebLogic Serverセキュティの管理でアイデンティティとトラストの構成に関する情報を参照してください。
パスワードについて
このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。
自己署名証明書を作成する手順は次のとおりです。
この項では、SOAHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。
前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、すべてのホストとADMINVHNのために作成した証明書と秘密鍵を新しいアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
注意:
アイデンティティ・ストアは、utils.ImportPrivateKey
ユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。
SSLハンドシェイクが適切に行われるには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。追加するには、次の手順を実行します。
注意:
WLSサーバー・トラスト・ストアにロード・バランサ証明書を追加する必要があるのは、自己署名証明書の場合のみです。サードパーティの認証局が発行したロード・バランサ証明書の場合は、ルートの公開証明書と中間証明書をトラスト・ストアにインポートする必要があります。
setDomainEnv.sh
スクリプトは、Oracle WebLogic Serverによって提供され、ドメイン内の管理サーバーと管理対象サーバーの起動に使用されます。各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetDomainEnv.sh
スクリプトを次のように編集します。IDキーストアおよび信頼キーストアを構成するには:
1つのエンタープライズ・デプロイメント・ドメインで各製品を効果的に管理するには、どの製品が特定の管理ロールまたはグループを必要とするか、また製品固有の管理ロールをエンタープライズ・デプロイメント管理グループにどのように追加するかを理解する必要があります。
各エンタープライズ・デプロイメントは複数の製品で構成されています。製品の一部には、各製品への管理アクセスの制御に使用される、特定の管理ユーザー、ロールまたはグループが存在します。
ただし、複数の製品で構成されているエンタープライズ・デプロイメントでは、単一のLDAPベースの認可プロバイダと、単一の管理ユーザーおよびグループを使用して、デプロイメントのあらゆる側面に対するアクセスを制御できます。認可プロバイダの作成と、エンタープライズ・デプロイメントの管理ユーザーおよびグループのプロビジョニングの詳細は、「新しいLDAPオーセンティケータの作成と新しいエンタープライズ・デプロイメント管理者ユーザーおよびグループのプロビジョニング」を参照してください。
単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理できるようにするには、特定の管理ロールまたはグループを必要とする製品を理解すること、単一の共通エンタープライズ・デプロイメントの管理グループに特定の製品管理ロールを追加する方法を知ること、さらに必要な場合は、必須の製品固有の管理グループにエンタープライズ・デプロイメントの管理ユーザーを追加する方法を知ることが必要になります。
詳細な情報は、次のトピックを参照してください
次の表に、エンタープライズ・デプロイメント用にLDAP認可プロバイダで定義した、エンタープライズ・デプロイメントの管理グループ(SOA Administrators
)に追加する必要のある特定の管理ロールを持つ、Fusion Middleware製品のリストを示します。
次の表の情報と「エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。
製品 | アプリケーション・ストライプ | 割り当てられる管理ロール |
---|---|---|
Oracle Web Services Manager。 |
wsm-pm |
policy.updater |
SOAインフラストラクチャ |
soa-infra |
SOAAdmin |
Oracle Service Bus |
Service_Bus_Console |
MiddlewareAdministrator |
エンタープライズ・スケジューラ・サービス |
ESSAPP |
ESSAdmin |
Oracle B2B |
b2bui |
B2BAdmin |
Oracle MFT |
mftapp |
MFTAdmin |
Oracle MFT |
mftes |
MFTESAdmin |
Oracle Insight |
insight |
InsightAdmin |
表22-1には、特定の管理グループを使用する必要のあるOracle SOA Suite製品のリストを示します。
これらのコンポーネントごとに、共通エンタープライズ・デプロイメントの管理ユーザーを製品固有の管理グループに追加する必要があります。追加しなければ、「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」で作成したEnterprise Managerの管理ユーザーを使用して製品リソースを管理できません。
表22-1の情報と「製品固有の管理グループへのエンタープライズ・デプロイメントの管理ユーザーの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。
表22-1 製品固有の管理グループを持つOracle SOA Suite製品
製品 | 製品固有の管理グループ |
---|---|
Oracle Business Activity Monitoring |
BAMAdministrators |
Oracle Business Process Management |
Administrators |
Oracle Service Bus統合 |
IntegrationAdministrators |
MFT |
OracleSystemGroup |
注意:
MFTでは、集中LDAPに特定のユーザー(OracleSystemUser)を追加する必要があります。このユーザーは、OracleSystemGroupグループに属している必要があります。MFTジョブの作成および削除が適切に動作するように、ユーザー名とユーザー・グループの両方を集中LDAPに追加する必要があります。製品固有の管理ロールを必要とする製品では、次の手順を使用して、その管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。
エンタープライズ・デプロイメントの場合、トランザクション・ログ(TLOG)とJMSにはJDBC永続ストアを使用することをお薦めします。
この項では、JDBCとファイル永続ストアを比較して利点を分析し、サポートされるデータベースで永続ストアを構成する手順を説明します。JDBCストアではなくファイル永続ストアを使用する場合に、これを構成する手順も、この項で説明します。
Oracle Fusion MiddlewareではOracle WebLogic Serverトランザクション・ログ(TLOG)とJMSに対して、データベース・ベースとファイル・ベース両方の永続ストアをサポートしています。お使いの環境の永続ストア戦略を決定する前に、各方法の長所と短所を検討してください。
注意:
選択するストレージ方法に関係なく、トランザクションの整合性および一貫性を確保するために、JMSとTLOGの両方に同じタイプのストアを使用することをお薦めします。
TLOGおよびJMSデータをOracleデータベースに格納する場合、データベースの複製機能と高可用性機能を利用できます。たとえば、OracleData Guardを使用してサイト間の同期を簡易化できます。これは、Oracle Fusion Middlewareを障害回復構成でデプロイする場合に特に重要です。
また、TLOGおよびJMSデータをデータベースに格納するということは、このデータ専用の共有記憶域の場所を識別する必要がないことを意味します。ただし、エンタープライズ・デプロイメントの他の局面では、共有記憶域は依然として必要です。たとえば、管理サーバー構成(管理サーバーのフェイルオーバーをサポートするため)、デプロイメント・プラン、ファイル/FTPアダプタ制御や処理ファイルなどのアダプタ・アーティファクトには必要です。
TLOGおよびJMSストアを共有記憶域デバイスに格納する場合、適切な複製およびバックアップ戦略を使用してデータ損失ゼロを保証することで、このデータを保護できます。また、システム・パフォーマンスも向上する可能性があります。ただし、ファイル・システム保護は常に、Oracle Databaseによって提供される保護よりも弱くなります。
データベース・ベースのTLOGおよびJMSストアを使用する場合のパフォーマンスへの影響の詳細は、「TLOGおよびJMS永続ストアへのパフォーマンスの影響」を参照してください。
どのインストール済製品およびコンポーネントが永続ストアを利用しているかは、WebLogic Serverコンソールの「ドメイン構造」ナビゲーションのドメイン名→「サービス」→「永続ストア」で判別できます。このリストには、ストア名、ストア・タイプ(通常はFileStore)、ターゲットの管理対象サーバー、およびターゲットを移行できるかどうかが示されます。
移行可能なターゲットを持つ永続ストアは、JDBC永続ストアの使用を考慮するうえで適切な候補となります。リストされたMDS関連のストアは、この章の範囲外であり、ここでは検討しません。
トランザクション・ログのストレージ方法およびJMS永続ストアを選択する際の考慮事項の1つとして、パフォーマンスへの影響があげられます。この項では、TLOGおよびJMSにJDBC永続ストアを使用する場合のパフォーマンスへの影響を明らかにするのに役立つ、ガイドラインや詳細をいくつか示します。
トランザクション・ログとJMSストアのパフォーマンスへの影響
トランザクション・ログの場合、ログは本質的に一時的であるため、JDBCストアの使用による影響は比較的小さくて済みます。通常、システム内の他のデータベース操作と比較した場合、影響はほとんどありません。
他方、アプリケーションがJMS集約型である場合、JMSデータベース・ストアはパフォーマンスに大きな影響を及ぼす可能性があります。たとえば、SOA Fusion Order Demo (Oracle SOA Suite環境をテストするために使用されるサンプル・アプリケーション)を使用している場合、JMSデータベース操作はより重い他の多くのSOAデータベース起動によってマスクされるため、ファイル・ベースからデータベース・ベースの永続ストアへの切替えの影響は非常に小さくなります。
パフォーマンスに影響を与える要素
カスタム宛先にJMS DBストアを使用する場合、複数の要素がパフォーマンスに影響を与えます。主なものは、次のとおりです。
関与するカスタム宛先とそのタイプ
永続化されるペイロード
SOAシステムの同時実行性(宛先のコンシューマおよびプロデューサ)
上述のいずれかの影響に応じて、次の領域に様々な設定を構成し、パフォーマンスを向上させることができます。
JMS表に使用されるデータ型のタイプ(RAWの使用対LOBの使用)
JMS表のセグメント定義(索引および表レベルでのパーティション)
JMSトピックの影響
システムでトピックが集中的に使用されている場合、同時実行性が高まるにつれて、Oracle RACデータベースのパフォーマンス低下はキューの場合よりも大きくなります。OracleがJMSに対して実施したテストでは、様々なペイロード・サイズおよび様々な同時実行性での平均パフォーマンス低下率は、キューの場合は30%未満でした。トピックの場合、影響は40%を超えていました。データベース・ストアを使用するかどうかを決定する際、リカバリの観点からこれらの宛先の重要性を検討してください。
データ型およびペイロード・サイズの影響
ペイロードにRAWデータ型を使用するかSecureFiles LOBデータ型を使用するかを選択する場合、永続化されるペイロードのサイズを考慮してください。たとえば、ペイロード・サイズの範囲が100bから20kの場合、SecureFiles LOBデータ型で必要とされるデータベース時間の量はRAWデータ型よりも若干多くなります。
具体的に言うと、ペイロード・サイズが約4kに達すると、SecureFilesはより多くのデータベース時間を必要とするようになります。これは、4kでは書込みが行外になるためです。約20kのペイロード・サイズで、SecureFilesデータはより効率的になり始めます。ペイロード・サイズが20kを超えると、RAWデータ型に設定されたペイロードのデータベース時間は悪化します。
SecureFilesのもう1つの利点は、500kを超えた時点からペイロードが増加してもデータベース時間が安定化し始める点です。すなわち、その時点で、(SecureFilesにとって)データが500k、1MBまたは2MBのいずれのペイロードを格納しているかは関係なくなります。書込みが非同期化され、すべてのケースで競合が同じになるためです。
ペイロード・サイズが50kに達するまで、キューのスループットに対する同時実行性(プロデューサおよびコンシューマ)の影響はRAWでもSecureFilesでも同じです。ペイロードが小さい場合、同時実行性が変化してもその影響はほぼ同じですが、RAWの方がスケーラビリティがやや優れています。ペイロードが50kを超える場合、SecureFilesの方がスケーラビリティが優れています。
同時実行性、ワーカー・スレッド、データベースのパーティション化の影響
永続ストアに定義された同時実行性とワーカー・スレッドは、索引レベルおよびグローバル・キャッシュ・レベルでRACデータベースの競合の原因になることがあります。1つの単一サーバーで複数のワーカー・スレッドを有効にする場合、または複数のOracle WebLogic Serverクラスタを使用する場合、リバース索引を使用することで様々なことを改善できます。ただし、Oracle Databaseのパーティション化オプションを使用できる場合、かわりにグローバル・ハッシュ・パーティション索引を使用する必要があります。これにより、索引の競合およびグローバル・キャッシュ・バッファ待機が減少し、アプリケーションのレスポンス時間が改善されます。パーティション化はどのケースでも適切に機能しますが、リバース索引で大幅な改善が認められない場合もあります。
この項では、トランザクション・ログ(TLOG)およびJMSにJDBC永続ストアを使用するためのガイドラインを説明します。サポートされているデータベースで永続ストアを構成するための手順も説明します。
トランザクション・ログにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。
JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。
エンタープライズ・デプロイメントでは、TLOGおよびJMSストアにGridLinkデータ・ソースを使用する必要があります。GridLinkデータ・ソースを作成する手順は次のとおりです。
データベースでユーザーと表領域を作成し、データ・ソースを作成したら、必要な各管理対象サーバーにTLOG永続ストアを割り当てることができます。
データベースでJMS永続ストア・ユーザーと表領域を作成し、JMS永続ストアのデータ・ソースを作成したら、管理コンソールを使用してストアを作成できます。
データベースでJMS表領域とユーザーを作成し、JMSデータ・ソースを作成し、JMSストアを作成したら、必要な各JMSサーバーにJMS永続ストアを割り当てることができます。
Oracle WebLogic Serverでは、トランザクション・ログを使用してシステムのクラッシュやネットワーク障害からリカバリします。
各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。
Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、各管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。
注意:
トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。クラスタ内のすべての管理対象サーバーがこのディレクトリにアクセスできる必要があります。また、このディレクトリは、サーバーを再起動する前にも存在している必要があります。
お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。記憶域で障害が発生した場合に確実に保護できるように、記憶域レベルで適切なレプリケーションとバックアップのメカニズムを設定することが重要です。
この情報はファイルベースのトランザクション・ログに該当します。また、トランザクション・ログのためにデータベースベースの永続ストアを構成することもできます。詳細は、エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用を参照してください。
静的クラスタでのデフォルト永続ストアの構成手順は、静的クラスタでのトランザクション・リカバリ用のデフォルト永続ストアの構成を参照してください。
デフォルトでは、Webサービスの永続性にはWebLogic Serverデフォルト永続ストアが使用されます。このストアはWebサービスに対して高パフォーマンスの記憶域ソリューションを提供します。
信頼性のあるメッセージング
接続
セキュア通信
メッセージ・バッファリング
デフォルト・ストアではなく、JDBC永続ストアをWebLogic ServerのWebサービスで使用することもできます。Webサービスの永続性の詳細は、Webサービスの永続性の管理を参照してください。
Oracle SOA Suiteエンタープライズ・デプロイメントに必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。
注意:
この項で示す静的なランタイム・アーティファクトの一部は、Network Attached Storage (NAS)からホストされています。可能であれば、これらのボリュームはアプリケーション・サーバーからでなく、NASファイラから直接バックアップおよびリカバリしてください。
Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、Oracle Fusion Middleware Oracle Fusion Middlewareの管理の次の項を参照してください。
環境のバックアップ
環境のリカバリ
表22-2 は、一般的なOracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。
表22-2 Oracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト
タイプ | ホスト | 層 |
---|---|---|
データベースのOracleホーム |
DBHOST1およびDBHOST2 |
データ層 |
Oracle Fusion Middleware Oracleホーム |
WEBHOST1およびWEBHOST2 |
Web層 |
Oracle Fusion Middleware Oracleホーム |
SOAHOST1およびSOAHOST2 (またはNASファイラ) |
アプリケーション層 |
インストール関連ファイル |
WEBHOST1、WEHOST2および共有記憶域 |
なし |
表22-3は、一般的なOracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。
表22-3 Oracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト
タイプ | ホスト | 層 |
---|---|---|
管理サーバーのドメイン・ホーム(ASERVER_HOME) |
SOAHOST1 (またはNASファイラ) |
アプリケーション層 |
アプリケーション・ホーム(APPLICATION_HOME) |
SOAHOST1 (またはNASファイラ) |
アプリケーション層 |
Oracle RACデータベース |
DBHOST1およびDBHOST2 |
データ層 |
スクリプトとカスタマイズ |
ホスト当たり |
アプリケーション層 |
デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME) |
SOAHOST1 (またはNASファイラ) |
アプリケーション層 |
OHS構成ディレクトリ |
WEBHOST1およびWEBHOST2 |
Web層 |
Oracle SOA Suiteエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの主要な構成および管理タスクについて説明します。
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 Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理の次の項を参照してください。
SOAコンポジット・アプリケーションのデプロイ
SOAコンポジット・アプリケーションのモニタリング
SOAコンポジット・アプリケーションの管理
SOAクラスタ内のSOAインフラストラクチャ・アプリケーションまたはリソース・アダプタを再デプロイするときは、デプロイメント・プランとアプリケーション・ビットに、クラスタ内の全サーバーからアクセスできる必要があります。
SOAのアプリケーションおよびリソース・アダプタは、nostageデプロイメント・モードを使用してインストールされます。nostageデプロイメント・モードを選択した場合、管理サーバーはアーカイブ・ファイルをソースの場所からコピーしないため、各サーバーが同じデプロイメント・プランにアクセスできるようにしておく必要があります。
デプロイメント・プランの場所がドメイン内のすべてのサーバーで利用できるようにするには、「このガイドで使用するファイル・システムとディレクトリ変数」で示され、エンタープライズ・デプロイメント・ワークブック内のDEPLOY_PLAN_HOME変数で表される、デプロイメント・プランのホームの場所を使用します。
Oracle SOA Suiteデータベースのデータ量が非常に多くなると、特に多くのコンポジット・アプリケーションがデプロイされている可能性のあるOracle SOA Suiteエンタープライズ・デプロイメントでは、データベースの保守が難しくなることがあります。
詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理の次の項を参照してください。
データベース増分管理戦略の策定
データベース増分の管理
クロス・コンポーネント・ワイヤリング(CCW)を利用すると、FMWコンポーネントは、特定のAPIを使用することによってWLSドメインで使用可能なサービスの一部をパブリッシュし、それにバインドすることができます。
CCWがワイヤリング情報のバインドを実行するのは、構成ウィザードのセッション中のみ、またはWLSドメイン管理者によって手動で強制実行されたときだけです。Weblogic Serverをクラスタに追加すると(静的クラスタでのスケール・アウト/アップ操作で)、新しいサーバーのサービスは公開されますが、サービスを使用するすべてのクライアントの更新および新しいサービス・プロバイダへのバインドは自動的に実行されません。CCW表にすでにバインドされている既存のサーバーは、クラスタに新しいメンバーが追加されたことを自動的に認識しないため、更新は実行されません。これは、ESSおよびWSMPMがSOAにサービスを提供する場合と同じです(両者はサービスをサービス表に動的に公開しますが、SOAサーバーはバインドが再び強制されないかぎり、これらの更新を認識しません)。
注意:
Oracle Fusion Middleware Oracle Fusion Middlewareの管理の連携するコンポーネントのワイヤリング。
Oracle Fusion Middleware Oracle HTTP Serverの管理のOracle HTTP Serverのオラクル社開発モジュール
クロス・コンポーネント・ワイヤリングのt3情報は、JNDI呼出しURLで使用されるサーバーのリスト取得する際に、WSMPMとESSによって使用されます。
CCWのt3情報は、動的更新が欠落していてもその影響を制限します。呼出しが完了すると、JNDI URLを使用してRMIスタブとクラスタのメンバーのリストが取得されます。JNDI URLが、サーバーのリスト全体を含んでいる必要はありません。RMIスタブには常にクラスタ内のすべてのサーバーのリストが含まれており、それら全体でのリクエストのロード・バランスに使用されます。そのため、バインドなしに、クラスタに追加されたサーバーが(バインドURLに存在していなくても)使用されます。唯一の欠点は、クラスタの拡張または縮小時にシステムを動作させ続けるために、最初のCCWバインドで指定される元のサーバーのうち少なくとも1つが稼働している必要があるという点です。この問題を回避するために、メンバーの静的リストを使用するかわりにサービス表でクラスタ名構文を使用できます。
cluster:t3_cluster_name
cluster:t3_cluster_name
を使用すると、CCW呼出しによって常にクラスタ内のすべてのメンバーのリストがフェッチされるため、初期サーバーに依存することなく、そのとき存在するすべてのメンバーが対象になります。
Oracle SOA SuiteサーバーをホストするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。これらの値は、ドメインのプロパティを指定する際に構成ウィザードで指定できます。ただし、Oracle SOA Suiteエンタープライズ・デプロイメントの一部にSOAクラスタを追加する場合、このタスクはSOA管理対象サーバーの検証後に実行することをお薦めします。
Weblogic Server管理コンソールでフロントエンド・ホストおよびポートを設定する手順は次のとおりです。