EDQの高可用性

3 EDQの高可用性

EDQは様々な方法でデプロイして、高可用性要件をサポートできます。可用性の高いEDQシステムをサポートするうえで、最も一般的で推奨されるのは、WebLogicクラスタリングを使用する方法です。WebLogicクラスタリングでは、複数のEDQサーバーで同じインストールと構成を共有することが可能で、組込みの冗長性を使用すれば、これらを1つのシステムとして管理して操作できます。ただし、EDQリアルタイム・サービスでシンプルな高可用性を実現できるのは、各サーバーの構成が同一で、リアルタイム・サービスとロード・バランシング・リクエストがサーバー間でサポートされている場合のみです。どちらの場合も、データベース層の高可用性を保証するにはOracle Real Application Clusters (RAC)が推奨されますが、ほとんどのEDQリアルタイム・サービスは一度実行されれば、データベースの可用性は必要ありません。

この章では、EDQをWebLogicクラスタにデプロイするとどのように動作するかについて説明します。内容は次のとおりです。

テクノロジ要件

EDQクラスタリングはWebLogicとCoherenceのテクノロジをベースとしており、WebLogicとCoherenceのクラスタリングを使用する適切なライセンスが必要です。データベース層の高可用性では、Oracle Real Application Clusters (RAC)が使用されるため、RACを使用する適切なライセンスが必要です。

WebLogicクラスタにおけるEDQ

EDQでは、WebLogicクラスタの操作がすべてサポートされます。EDQをクラスタにインストールする場合の詳細は、Enterprise Data Qualityのインストールと構成の「Oracle WebLogic Serverを使用したEnterprise Data Qualityの構成」の章を参照してください。

WebLogicクラスタの構成と管理の詳細は、高可用性ガイドを参照してください。

図3-1に、WebLogicクラスタにおけるEDQを示します。

図3-1 WebLogicクラスタにおけるEDQ

WebLogic ClusterにおけるEDQの特徴

クラスタにデプロイされたEDQには、次のような一般的な特徴があります。

クラスタのすべてのサーバーが、リポジトリ・データベースの同じスキーマ(EDQ構成、EDQ結果およびEDQステージング)を共有します。WebLogicでは、これらのスキーマへの接続は、JNDIデータ・ソースとして定義されます。これらのデータ・ソースをOracle RAC用に構成し、複数のデータベース・ノードを使用したり、接続をロード・バランシングしたりすることも可能で、可用性を高めるために推奨されています。
ステートレス・リアルタイム・ジョブが、クラスタのすべての管理対象サーバーで実行されます。システムでステートレス・リアルタイム・ジョブが検出される仕組みの詳細は、「クラスタで実行する場合のジョブの定義」を参照してください。
クラスタ内の管理対象サーバーの1つ(通常は、最も余裕のあるサーバー)でバッチ・ジョブが実行されます。たとえば、2つのサーバーで構成されるクラスタにおいて、サーバーAでバッチ・ジョブを実行中に、別のバッチ・ジョブが発行された場合、新しいバッチ・ジョブはサーバーBで実行されます。
Oracle RACが使用されていて、いずれかのノードが停止した場合、または障害が発生した場合は、次のようになります。
- 実行中のリアルタイム・ジョブは、通常、正常に処理が続行されます。
- 実行中のバッチ・ジョブで、障害が発生したノードへの接続が使用されている場合、そのジョブは失敗しますが、新しく発行されたバッチ・ジョブとして再開することが可能で、アクティブなノードへの新しい接続がリクエストされます。
- システムがアイドルな場合、影響はありません。
Oracle RACが使用されておらず、データベースを使用できない場合は、次のようになります。
- 実行中のリアルタイム・ジョブは、通常、正常に処理が続行されます。
- 実行中のバッチ・ジョブは失敗し、データベースが再度使用可能になるまで、正常に再開できません。
- システムがアイドルな場合、影響はありません。
- データベースが再度使用可能になれば、JNDI接続プールは中断されないため、EDQアプリケーション・サーバーを再起動する必要はありません。
クラスタの管理対象サーバーで障害が発生すると、ロード・バランサによって検出され、リクエスト・ルーター(Oracle HTTP Serverなど)が、この管理対象サーバーにリクエストをルーティングしなくなります。バッチ・ジョブは、稼働中のサーバーのいずれかで処理されます。

クラスタで実行する場合のジョブの定義

EDQでは、ジョブが、クラスタのすべてのサーバーで実行可能なステートレス・リアルタイム本番ジョブであるか、バッチ処理または結果の書込みが含まれ、クラスタ内の1つのサーバーで実行する必要があるジョブかどうかが自動的に検出されます。

クラスタのすべてのサーバーで実行するリアルタイム・ジョブとして検出されるには、ジョブに次の特性が必要です。

単一フェーズのみであること。
すべてのプロセス・チェーンが、リアルタイム・マッピングを使用するよう構成された、リアルタイム・リーダーまたはデータ・インタフェース・リーダーに接続されていること。
ステージングされたデータまたは参照データへの書込みを行わないこと。

注:

ランディング領域にのみ書込みを行うジョブは、データ・インタフェース経由でデータをエクスポートするものとみなされ、ステージングされたデータを書き込んでいるとはみなされません。ジョブの実行中に無効化されている間、ジョブは、ジョブ定義や実行プロファイルなどに、そのようなライターを含んでいる場合があります。
ステージングされたデータに結果を公開しないこと。
実行ラベルを使用して実行すること。

注:

結果データの書込み、一致レビューのレビュー結果の書込み、またはダッシュボードへの公開に間隔モードを使用するジョブを、すべてのサーバーで実行することはできません。

理論的には、次のようなタイプのジョブが考えられます。すべてのサーバーでの実行が試行されますが、どのサーバーでも正常に実行されません。

バッチ・ジョブを実行する'before'フェーズ・トリガーを含むリアルタイム・ジョブ。このタイプのジョブは、リアルタイム・ジョブがバッチ・ジョブの最後にトリガーされるように再構成する必要があります。
参照データまたはステージングされたデータへの書込みを行うリアルタイム・ジョブ。このタイプのジョブは、1つのサーバーでは正常に実行されますが、その他のサーバーでは、すでにロックされているというメッセージが表示されて失敗します。本番では、このタイプのジョブを使用しないでください。実行ラベルを使用しての実行をやめ、1つのサーバーで実行することにより、結果データや書き込まれるデータを確認できます。すべてのサーバーで実行される本番のステートレス・リアルタイム・ジョブからデータを書き出す必要がある場合は、追加モードで実行され、データ・インタフェースを介してエクスポートに書き込むライターを使用して実行してください。
同時に複数回実行されるリアルタイム・ジョブ。ジョブの最初のインスタンスはすべてのサーバーで実行されますが、後続のインスタンスは失敗します。

結果を書き込んだり、実行ラベルがないバッチ・ジョブやリアルタイム・ジョブなど、その他すべてのタイプのジョブは、クラスタの最も余裕のある管理対象サーバーで実行されます。つまり、12.2.1より前のバージョンのEDQで作成されたものや、現在リアルタイム・ジョブとして扱われているものなど、一部のタイプのジョブは、すべてのサーバーで実行可能とみなされません。これは特に、最初のフェーズにおいて、一括でデータ(リアルタイム照合処理の参照データなど)を準備し、後続のフェーズでリアルタイム処理を行うジョブに当てはまります。すべてのサーバーでそのようなジョブのリアルタイム・フェーズを実行する必要がある場合は、参照データを準備するバッチ・ジョブと、前述の要件を満たすリアルタイム・ジョブの2つにジョブを分割する必要があります。バッチ・ジョブには、リアルタイム・ジョブを開始する最終フェーズの終了トリガーが必要です。これにより、バッチ・ジョブは1つのサーバーで実行され、リアルタイム・ジョブはすべてのサーバーで実行されます。

EDQ Webサービスの監視

ほとんどのロード・バランサで、管理対象サーバーが実行中かどうかを把握できますが、そのことが、アプリケーションのサービスの準備ができているということかどうかを把握する必要があるわけではありません。WebサービスをサポートしているEDQリアルタイム・ジョブは、通常は、管理対象サーバーが稼働しているときには必ず実行されているものであるため、サーバーの起動時に開始されるようスケジュールします。これは、「自動実行」処理の使用で可能になります。ここに、クラスタ環境の強みがあります。ステートレス・リアルタイム・ジョブはクラスタのすべてのサーバーで実行されるため、実行中のリアルタイム・ジョブは、手動で操作しなくても、クラスタに新しく追加された管理対象サーバーで自動的に起動されます。

また、EDQはFusion Middlewareの準備完了アプリケーション機能と統合できるため、アプリケーションでWebサービス・リクエストを受信する準備ができているかどうかを確認するために、URLをチェックすることが可能です。

準備ができているかどうかを確認するURLは[http://server:port/weblogic/ready]であるため、EDQ管理対象サーバーの場合は、[http://host234:8001/weblogic/ready]のようになります。

サーバーがリクエストに対応する準備ができている場合、URLはステータス200を戻します。サーバーの準備ができていない場合は、503が戻されます。これにより、ロード・バランサはサービスの可用性を簡単に検出できます。

EDQサーバーが起動されると、自動実行が使用されること、または必要なリアルタイム・ジョブをすぐに開始するスケジュールが想定されます。ただし、なんらかの理由でそれらのジョブが停止または失敗した場合(さらに、管理対象サーバーが稼働し続けている場合)は、トリガーの使用により、準備ができていないことをEDQサーバー自身が宣言できます。準備完了アプリケーション統合のEDQのデフォルト実装では、顧客データ・サービス・パックのリアルタイム・サービスすべての可用性を監視するよう設定されていますが、ユーザーが選択したリアルタイム・サービスを監視するよう変更可能です。これは、EDQのホーム構成ディレクトリにあるEDQトリガーを使用して実装します。

[domain home]/edq/config/fmwconfig/edq/oedq.home/triggers/readyappjobfail.groovy

たとえばこれを、指定されたジョブの別のセットが失敗したら、準備ができていないことをEDQサーバー自身が宣言するよう変更するには、[oedq.local.home]ディレクトリのトリガー・ディレクトリにファイルをコピーし、プロジェクトとミッション・リストを監視するEDQプロジェクトおよびジョブに対応するように変更します。

UIの動作

EDQをクラスタにデプロイすると、Oracle HTTP Serverなどのフロントエンドのロード・バランサを使用して、クラスタ全体のユーザー・セッションをロード・バランシングすることが可能です。このシナリオでは、ロード・バランシングされたURLを使用してシステムにアクセスしているユーザーは、いずれかの管理対象サーバーに接続され、その後のアクションはすべてそのサーバーで処理されます。構成と結果データベースは同じであるため、ほとんどの場合、接続先のサーバーはユーザーには重要ではありません。どの管理対象サーバーに接続されているかに関係なく、Director and Server Consoleのユーザーに、クラスタでアクティブなジョブとタスクが表示されます。それぞれのジョブを実行しているサーバーが、UIに表示されます。

LaunchpadなどのEDQ Webページをカスタマイズして、ユーザー・セッションが接続されている管理対象サーバーの名前をヘッダーに表示するには、EDQのローカル・ホーム・ディレクトリにあるdirector.propertiesに次の行を追加します。

[expr]adf.headerextra = ': ' || weblogic.Name

WebStartアプリケーションとEDQ LaunchpadのどちらのUIセッションも、自動的にはフェイルオーバーされません。管理対象サーバーで障害が発生した場合、その管理対象サーバーに接続されているユーザーは、再度ログインする必要があります。少なくとももう1つの管理対象サーバーが使用可能であるならば、ログインは成功するため、ユーザーはアクティブな管理対象サーバーに接続されます。

チューニング

EDQクラスタリングではCoherenceを使用するため、Coherenceのパラメータを調整することで、システムの特定項目のチューニングを必要とする場合があります。詳細は、『Oracle Coherenceでのアプリケーションの開発』のパフォーマンス・チューニングに関する項を参照してください。

クラスタ内の前に障害が発生したサーバーを再起動する際は、クライアントが(別の管理対象サーバーに)接続できないという問題の原因になる可能性があり、潜在的な問題を回避するために、WebLogicコンソールを使用して、クラスタの「メンバーのウォームアップ・タイムアウト」プロパティを、(デフォルト値の0に対して)「30」(秒)に設定することをお薦めします。この設定は、クラスタの「一般」設定にあります。

Oracle Web Services Managerの使用

ドメイン内にOracle Web Services Managerポリシー・マネージャ('wsm-pm')を使用している別の管理対象サーバーがある場合は、デフォルトで作成されているEDQ管理対象サーバーの起動グループだけでなく、WebLogicドメイン構成ウィザードで、WSMPM-MAN-SVRサーバーの起動グループも参照して、すべてのEDQ管理対象サーバーを作成する必要があります。

管理ポート

EDQを単一の管理対象サーバーとして実行し、WebLogicクラスタを使用していない場合、デフォルトの管理ポートは8090です。 EDQをWebLogicクラスタで実行している場合、EDQには、サーバーの起動時に割り当てられるランダム・ポートが使用されます。サーバー・アクセスMBeanを調べれば、現在のポートを確認できますが、EDQサーバーが再起動されると、それらのポートも変わることに注意してください。

標準のEDQ JMXクライアントは、管理サーバーのMBeanサーバーを使用して、これらのサーバー・アクセスBeanを自動的に問い合せるように更新されました。管理サーバーのホスト名とポートを指定すると、コネクタ・コードにより、適切なポートの管理対象サーバーのいずれかにリクエストがリダイレクトされます。

$ java -jar jmxtools.jar runjob ... adminhost:7001

WebLogicおよびEDQで、jmxtoolsのユーザー名とパスワードが有効になっている必要があります。 OPSSに設定されている認証プロバイダのユーザーを使用してください。単一のEDQサーバーを使用している場合は、クラスタで実行してもメリットはありません。クラスタからサーバーを削除すると、デフォルト・ポートの8090が使用されます。

クラスタ内のサーバーごとに、管理ポートを変えたり、固定にしたりできます。 (複数のサーバーが別々のマシンで実行されている場合は、同じポートを使用できます)。 director.propertiesのoedq.local.homeバージョンを編集し、現在の管理ポートの設定を次の内容に置き換えます。

[expr]management.port = 8090 + servernum - 1

ここで、servernumは事前に計算された値で、edq_server1は1、edq_server2は2のようになります。この例では、edq_server1の管理ポートは8090で、edq_server2のポートは8091というようになります。

特定の管理対象サーバーのポートを使用するには、dnd.propertiesでのSiebel構成が必要になります。 EDQを単一の管理対象サーバーとして実行し、WebLogicクラスタを使用していない場合、デフォルトの管理ポートは8090です。

任意の管理対象サーバーの管理(JMX)ポートを検出するには、Enterprise Manager Fusion Middleware Controlを使用して、次のようにします。

ドメインをクリックして、オプションのドロップダウン・リストを表示し、「システムMBeanブラウザ」を選択します。
「アプリケーション定義のMBean」 > 「EDQ」 > 「サーバー: servername」 > 「ServerAccess」 > 「ServerAccess」に移動します。

前提

EDQは、指定されたサーバーのファイル・システムで多数のファイルを使用します。ほとんどの場合、たとえば、EDQ構成ディレクトリの大部分のファイルは、読取り専用でアクセスされ、変更されることはありません。そのため、複数のマシンでWebLogicドメインを圧縮および解凍することが可能です。

ただし、一部のタイプのEDQジョブ(特にバッチ・ジョブ)は、実行するために、EDQファイルのランディング領域にアクセスする必要があります。クラスタ・システムを適切に運用するには、別々のマシン上の管理対象サーバーがアクセスできるように、このファイルのランティング領域が共有ファイル記憶域(NFSなど)でマウントされている必要があります。つまり、ランディング領域のファイルによってジョブがトリガーされた場合、そのジョブはどのマシンのどの管理対象サーバーでも実行可能であり、あるEDQジョブが別のジョブで消費されるファイルをランディング領域に書き込んだ場合は、両方のジョブでランディング領域へのアクセスを共有しているため、どちらのジョブもどのマシンでも実行できるということです。

Fusion Middleware高可用性のベスト・プラクティスは、共有ファイル記憶域でドメイン全体をマウントすることで、そうすることにより、明示的にランディング領域を移動しなくても、この要件が満たされます。詳細は、Oracle高可用性ベスト・プラクティスを参照してください。

ランティング領域を明示的に共有記憶域に移動した場合、EDQアプリケーション・サーバーを実行するオペレーティング・システムのユーザー・アカウントに、その記憶域に対する読取りおよび書込みアクセス権が必要で、EDQローカル・ホーム・ディレクトリのdirector.propertiesを更新して、その記憶域を指すように次のプロパティを追加する必要があります。

landingarea=[path]

制限事項および例外

前に述べたように、通常の運用やほとんどのユースケースで、リポジトリ・データベースの可用性が中断しても、EDQリアルタイム・ジョブは稼働し続けます。これは、顧客データ・サービス・パックで提供されているすべてのリアルタイム・ジョブと、大部分のカスタム構成のリアルタイム・ジョブに当てはまります。

ただし、次の制限事項に注意してください。

リアルタイム・ジョブが1つ以上の照合プロセッサを使用し、参照データまたはステージングされたデータの参照データ・ポートに対する入力との参照データ照合を実行する場合、プロセスで使用される照合プロセッサは、準備された参照データをメモリーにキャッシュするよう構成されている必要があります。これは、照合プロセッサの「拡張オプション」にあるシンプルなチェック・ボックスを使用して有効にします。
リアルタイム・ジョブがケース管理にデータを公開する場合、データベースが再度使用可能になるまでメッセージが送信されません。リアルタイム・ジョブ自体は実行し続けます。
リアルタイム・ジョブが、通常はメモリーにキャッシュされるステージングされたデータや参照データではなく、外部データベースを直接ルックアップする外部ルックアップを行う場合、ルックアップが失敗し、ルックアップ中のデータベースが再度使用可能になるまで、メッセージが送信されません。
同様に、リアルタイム・ジョブに、ステージングされたデータや参照データを使用した大規模な参照データ・セットが使用される場合、構成可能なキャッシュ制限を超え、メモリーにキャッシュできないと、ルックアップが失敗し、データベースが再度使用可能になるまでメッセージが送信されません。参照データ・セットをキャッシュできるデフォルトの最大行制限は100,000行ですが、EDQローカル・ホームのdirector.propertiesに次の行を追加することで変更できます。
```
resource.cache.maxrows = [rowlimit]
```
ここで、[rowlimit]は最大行数で、100000などです。
リアルタイム・ジョブで外部レルムのユーザー・アカウントが使用される場合は、ユーザー詳細をルックアップするために接続可能なLDAPサーバーに依存します。