ネイティブ・クラスタリングに基づいたマルチサーバー・ドメインを作成、構成および管理できます。ネイティブ・クラスタリングを使用する場合、ドメインはTOTEMに基づいたネイティブ・クラスタリング実装を受け取りますが、Oracle Event Processingの高可用性とサービス品質オプションを利用できません。高可用性とサービス品質オプションが必要な場合は、Oracle Coherenceを使用してマルチサーバー・ドメインを構築してください。
この章の内容は次のとおりです。
マルチサーバー・ドメインを作成するには、構成ウィザードを使用して1つのサーバーのある1つのドメインを作成することから開始します。これはスタンドアロンサーバー・ドメインです。
スタンドアロンサーバー・ドメインをマルチサーバー・ドメインに変換するには、次の2つのいずれかを実行します。
作成したサーバーをコピーして名前を変更し、各サーバーのconfig.xml
ファイルを編集して、それらのすべてが同じマルチキャスト名、マルチキャスト・ポートおよびドメイン名を持つようにします。
構成ウィザードを使用して追加のスタンドアロン・サーバーを生成し、各サーバーのconfig.xml
ファイルを編集して、それらのすべてが同じマルチキャスト名、マルチキャスト・ポートおよびドメイン名を持つようにします。
この章の手順では、最初の方法を使用します。
ドメインが完全に同一ではないサーバーをサポートする必要がある場合、カスタム・グループを作成して構成します。「カスタム・グループでのマルチサーバー・ドメインの作成」を参照してください。
デフォルト・グループでのマルチサーバー・ドメインの作成:
同一ではないアプリケーションをデプロイする予定であり、カスタム構成が必要な場合は、この手順を使用します。ドメインにあるすべてのサーバーが完全に同一である場合、カスタム・サーバー・グループを作成する必要はありません。
かわりに、事前定義済のデフォルト・サーバー・グループ(シングルトン・グループとドメイン・グループ)を使用します。「デフォルト・グループでのマルチサーバー・ドメインの作成」を参照してください。
この手順では、myServer1
、myServer2
、およびmyServer3
と3つのサーバーを作成していることを想定します。myServer1
は、selector
グループのメンバーであり、myServer2
とmyServer3
は、strategy
グループのメンバーであるとしています。
カスタム・サーバー・グループでのマルチサーバー・ドメインの作成:
構成ウィザードを使用してサーバーを更新する場合、リスニング・ポートおよびJDBCデータ・ソース構成のみを更新できます。サイレント・モードでは、サーバーを追加して、データ値が存在するものすべてを更新できます。
XMLプロパティ・ファイルの次のデータ値について値を指定した既存のサーバーの既存の構成を更新するには、次の手順を実行します。
CONFIGURATION_OPTION
をupdateDomain
に設定します。
DOMAIN_NAME
およびDOMAIN_LOCATION
オプションには既存のドメインの名前と場所を設定します。例では、値はそれぞれmyDomain
とC:\Oracle\Middleware\my_oep\user_projects\domains
です。
SERVER_NAME
オプションには、既存のドメインに追加する新しいサーバーの名前を設定します。例では、この値はmyServer2
です。
このサーバーをマルチサーバー・ドメインの他のサーバーと同じコンピュータで実行する場合は、NETIO_PORT
などの新しいサーバー構成オプションが、ドメインの既存サーバーのオプションと重複しないようにする必要があります。新しいサーバーから既存のサーバーと同じデータベースに接続する場合は、データ・ベース・オプションを同じにすることができます。
マルチサーバー・ドメインの他のサーバーとは異なるマシンにサーバーがある場合は、ポートを別にする必要はありません。
次の例は、マルチサーバー・ドメイン内の既存のサーバーを更新するXMLプロパティ・ファイルです。
<?xml version="1.0" encoding="UTF-8"?> <bea-installer xmlns="http://www.bea.com/plateng/wlevs/config/silent"> <input-fields> <data-value name="CONFIGURATION_OPTION" value="createDomain" /> <data-value name="USERNAME" value="wlevs" /> <data-value name="PASSWORD" value="wlevs" /> <data-value name="SERVER_NAME" value="myServer1" /> <data-value name="DOMAIN_NAME" value="myDomain" /> <data-value name="DOMAIN_LOCATION" value="C:\Oracle\Middleware\my_oep\user_projects\domains" /> <data-value name="NETIO_PORT" value="9102" /> <data-value name="KEYSTORE_PASSWORD" value="my_keystore_password" /> <data-value name="PRIVATEKEY_PASSWORD" value="my_privatekey_password" /> <data-value name="DB_URL" value="jdbc:bea:oracle://localhost:1521:XE" /> <data-value name="DB_USERNAME" value="db_user" /> <data-value name="DB_PASSWORD" value="db_password" /> </input-fields> </bea-installer>
マルチサーバーに関係するメッセージを変換することで、マルチサーバー・ドメインのサーバーはその状態を更新します。これらのメッセージは整合性をチェックする必要があります。
整合性を確実にするために秘密鍵を使用できます。秘密鍵はドメイン内のすべてのサーバーで共有する必要があります。
サーバー間で送信されるメッセージの保護
アプリケーションでこの動作を有効にするには、通常はイベント・シンクのロールにあるアダプタまたはイベントBeanが次のインタフェースを実装する必要があります。
com.bea.wlevs.ede.api.cluster.GroupMembershipListener
このインタフェースにより、マルチサーバー・ドメイン・グループのメンバーシップの変更をイベント・シンクでリスニングできるようになります。実行時には、メンバーシップに変更が発生するたびに、Oracle Event ProcessingがonMembershipChange
コールバック・メソッドを呼び出します。
コールバック・メソッドのシグネチャは次のとおりです。
onMembershipChange(Server localIdentity, Configuration groupConfiguration);
onMembershipChange
コールバック・メソッドの実装では、イベント・シンクがServer
オブジェクト(localIdentity
)を使用してリーダーかどうかを検証します。この検証は、localIdentity
と、第2パラメータgroupConfiguration
でのConfiguration.getCoordinator()
の実行結果を比較して行うことができます。また、このパラメータを使用すると、Configuration.getMembers()
を実行して、現在のグループのメンバーをサーバーに知らせることもできます。
メンバーがコーディネータである場合にのみイベントを保持するために、イベント・シンクはグループのメンバーシップに変更があるたびに新しいServer
IDを取得する必要があります。グループ・メンバーシップに変更が発生するのは、たとえば、グループ内の他のサーバーでエラーが発生し、そのサーバーがコーディネータではなくなった場合です。
次のインタフェースは、サーバー・グループに対する変更ではなく、ドメイン全体としてのメンバーシップ変更をリスニングするためのものです。
com.bea.wlevs.ede.api.cluster.DomainMembershipListener
ホット-ホット構成には、失敗の通知にゼロ以外の遅延があります。クラスタリングの実装に通知APIを使用する場合、サーバー障害とマスター・サーバーに配信される通知の間の時間ウィンドウで発生するイベントを失って、処理できません。
Oracle Event Processing Java APIリファレンスを参照してください。
マルチサーバー・ドメインのサーバーを起動するには、起動スクリプトを実行して各サーバーを個別に起動します。これは、スタンドアロン・サーバー・ドメインのサーバーを起動する方法と同じです。
詳細は、「スタンドアロンサーバー・ドメインでのサーバーの起動と停止」を参照してください。
マルチ・サーバー・ドメインのカスタム・グループを構成しなかった場合、単純にすべてのサーバーは事前定義されたドメイン・グループ(マルチ・サーバー・ドメイン内のすべてのサーバーが含まれる)とシングルトン・グループ(メンバーのサーバーごとに1つ)のメンバーになります。つまり、マルチ・サーバー・ドメインに3つのサーバーが存在する例では、シングルトン・グループも3つになります。
これに対し、マルチサーバー・ドメインにカスタム・グループを構成した場合、サーバーは事前定義されたグループのメンバーであると同時に、構成されたグループのメンバーにもなります。