| Oracle® Fusion Middleware Oracle Stream Explorerの管理 12cリリース(12.2.1) E72512-01 |
|
 前 |
 次 |
ネイティブ・クラスタリングに基づいたマルチサーバー・ドメインを作成、構成および管理できます。ネイティブ・クラスタリングを使用する場合、ドメインはTOTEMに基づいたネイティブ・クラスタリング実装を受け取りますが、Oracle Stream Explorerの高可用性とサービス品質オプションを利用できません。高可用性とサービス品質オプションが必要な場合は、Oracle Coherenceを使用してマルチサーバー・ドメインを構築してください。
この章の内容は次のとおりです。
マルチサーバー・ドメインを作成するには、構成ウィザードを使用して1つのサーバーのある1つのドメインを作成することから開始します。これはスタンドアロンサーバー・ドメインです。スタンドアロンサーバー・ドメインをマルチサーバー・ドメインに変換するには、次のいずれかを実行します。
作成したサーバーをコピーして名前を変更し、各サーバーのconfig.xmlファイルを編集して、それらのすべてが同じマルチキャスト名、マルチキャスト・ポートおよびドメイン名を持つようにします。
構成ウィザードを使用して追加のスタンドアロン・サーバーを生成し、各サーバーのconfig.xmlファイルを編集して、それらのすべてが同じマルチキャスト名、マルチキャスト・ポートおよびドメイン名を持つようにします。
この章の手順では、最初の方法を使用します。
「シングルトン・サーバー・デプロイメント・グループ」で説明したように、2つの事前定義済デプロイメント・グループのみを使用するマルチサーバー・ドメインを作成できます。この事前定義済デプロイメント・グループはシングルトン・グループとドメイン・グループです。デフォルト・グループを使用するドメインでは、すべてのサーバーが完全に同一である必要があります。
ドメインが完全に同一ではないサーバーをサポートする必要がある場合、カスタム・グループを作成して構成します。「カスタム・グループでのマルチサーバー・ドメインの作成」を参照してください。
デフォルト・グループでのマルチサーバー・ドメインの作成:
同一ではないアプリケーションをデプロイする予定であり、カスタム構成が必要な場合は、この手順を使用します。ドメインにあるすべてのサーバーが完全に同一である場合、カスタム・サーバー・グループを作成する必要はありません。かわりに、事前定義済のデフォルト・サーバー・グループ(シングルトン・グループとドメイン・グループ)を使用します。「デフォルト・グループでのマルチサーバー・ドメインの作成」を参照してください。
この手順では、myServer1、myServer2、およびmyServer3と3つのサーバーを作成していることを想定します。myServer1は、selectorグループのメンバーであり、myServer2とmyServer3は、strategyグループのメンバーであるとしています。
カスタム・サーバー・グループでのマルチサーバー・ドメインの作成:
マルチサーバー・ドメイン内のサーバーの更新は、スタンドアロンサーバー・ドメインで1つのサーバーを更新する場合と同様であり、構成ウィザードを起動するか、XMLプロパティ・ファイルを編集してサイレント・モードを使用します。1つのサーバーの更新と複数のサーバーの更新の唯一の違いは、マルチサーバー・ドメインでの場合は各サーバーで個別に更新を実行することです。サイレント・モードでのXMLプロパティ・ファイルの使用が、マルチサーバー・ドメインでの最善の方法です。
構成ウィザードを使用してサーバーを更新する場合、リスニング・ポートおよび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>
マルチサーバーに関係するメッセージを変換することで、マルチサーバー・ドメインのサーバーはその状態を更新します。これらのメッセージは整合性をチェックする必要があります。整合性を確実にするために秘密鍵を使用できます。秘密鍵はドメイン内のすべてのサーバーで共有する必要があります。
サーバー間で送信されるメッセージの保護
アクティブ/アクティブ・システムでは、アクティブに実行されているアプリケーションを複数のサーバーに均一にデプロイします。均一にデプロイされたこれらのアプリケーションから、リードするコーディネータ・アプリケーションを選択する必要が生じる場合があります。この場合、コーディネータ・アプリケーションから発生したイベントは保持され、EPNの次のコンポーネントに渡されます。セカンダリ・サーバーの結果は削除されます。コーディネータにエラーが発生した場合は、いずれかのセカンダリ・サーバーが新しいコーディネータとして選択される必要があります。
アプリケーションでこの動作を有効にするには、通常はイベント・シンクのロールにあるアダプタまたはイベントBeanが次のインタフェースを実装する必要があります。
com.bea.wlevs.ede.api.cluster.GroupMembershipListener
このインタフェースにより、マルチサーバー・ドメイン・グループのメンバーシップの変更をイベント・シンクでリスニングできるようになります。実行時には、メンバーシップに変更が発生するたびに、Oracle Stream ExplorerがonMembershipChangeコールバック・メソッドを呼び出します。
コールバック・メソッドのシグネチャは次のとおりです。
onMembershipChange(Server localIdentity, Configuration groupConfiguration);
onMembershipChangeコールバック・メソッドの実装では、イベント・シンクがServerオブジェクト(localIdentity)を使用してリーダーかどうかを検証します。この検証は、localIdentityと、第2パラメータgroupConfigurationでのConfiguration.getCoordinator()の実行結果を比較して行うことができます。また、このパラメータを使用すると、Configuration.getMembers()を実行して、現在のグループのメンバーをサーバーに知らせることもできます。
メンバーがコーディネータである場合にのみイベントを保持するために、イベント・シンクはグループのメンバーシップに変更があるたびに新しいServerIDを取得する必要があります。グループ・メンバーシップに変更が発生するのは、たとえば、グループ内の他のサーバーでエラーが発生し、そのサーバーがコーディネータではなくなった場合です。
次のインタフェースは、サーバー・グループに対する変更ではなく、ドメイン全体としてのメンバーシップ変更をリスニングするためのものです。
com.bea.wlevs.ede.api.cluster.DomainMembershipListener
ホット-ホット構成には、失敗の通知にゼロ以外の遅延があります。クラスタリングの実装に通知APIを使用する場合、サーバー障害とマスター・サーバーに配信される通知の間の時間ウィンドウで発生するイベントを失って、処理できません。
Oracle Stream Explorer Java APIリファレンスを参照してください。
マルチサーバー・ドメインのサーバーを起動するには、起動スクリプトを実行して各サーバーを個別に起動します。これは、スタンドアロン・サーバー・ドメインのサーバーを起動する方法と同じです。詳細は、「スタンドアロンサーバー・ドメインでのサーバーの起動と停止」を参照してください。
マルチ・サーバー・ドメインのカスタム・グループを構成しなかった場合、単純にすべてのサーバーは事前定義されたドメイン・グループ(マルチ・サーバー・ドメイン内のすべてのサーバーが含まれる)とシングルトン・グループ(メンバーのサーバーごとに1つ)のメンバーになります。つまり、マルチ・サーバー・ドメインに3つのサーバーが存在する例では、シングルトン・グループも3つになります。
これに対し、マルチサーバー・ドメインにカスタム・グループを構成した場合、サーバーは事前定義されたグループのメンバーであると同時に、構成されたグループのメンバーにもなります。
