| Oracle® Fusion Middleware Oracle WebLogic Serverのための継続的可用性 12c (12.2.1.3.0) E90354-01 |
|
 前 |
アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、クラスタ・ノードは地理的に近い範囲内のデータ・センターを拡張でき、通常はサイト間の比較的に低遅延のネットワーキングが保証されています。
「一般設計に関する考慮事項および継続的可用性」に説明されているようにすべての継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、「アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタ」に示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。
アクティブ/パッシブ・データベース層とともに動作するアクティブ/アクティブ・ストレッチ・クラスタ・トポロジでの継続的可用性のためには、Oracleのベスト・プラクティスを考慮してください。
アクティブ/アクティブ・ストレッチ・クラスタで継続的可用性の機能を最大限に利用するには、次を考慮してください。
マルチデータ・センターでは、アクティブ/アクティブ・ストレッチ・クラスタ環境のデータ・センター間のセッション・レプリケーションによってシステムで重大なパフォーマンス低下が引き起こされる可能性があります。異なる2つのレプリケーション・グループ(各サイトに1つ)を定義して、2つのサイト間で発生するレプリケーションの可能性を最小限にすることをお薦めします。
注意:
レプリケーション・グループの使用は、同一サイト内のサーバーのみに状態をレプリケートするために最良の方法ですが、決定的な方法ではありません。1つのサーバーが一方のサイトで使用でき、その他のサーバーはもう一方のサイトで使用できる場合、MANの間でレプリケーションが発生し、そのセッションの間はサーバーが同じサイトで元のようにオンラインになっても継続します。
アクティブ/アクティブ型ストレッチ・クラスタはメトロ遅延モデルでのみ機能します。遅延は10ミリ秒より長くできません。
競合およびセキュリティの理由で、サイト間の共有ストレージの使用はお薦めしません。
両方のサイトが、2つのサイトのいずれかにある単一の管理サーバーで管理されます。各サイトが、JMSおよびトランザクションのログ(TLog)用の個別の共有ストレージを使用します。または、データベースが永続ストアとして使用されます。サイト1からサイト2(およびその逆)へのディスク・ミラーリングおよびレプリケーションを使用して、各サイトのこれらのアーティファクトのリカバリ可能なコピーを提供できます。一意のWebLogic Server管理コンソールが、両方のサイトで稼働しているサーバーを構成およびモニターするために使用されます。WebLogic Serverのインフラストラクチャは、ドメインで使用されているすべての異なるドメイン・ディレクトリに構成の変更をコピーする責任があります。
管理サーバー障害の場合、単一データ・センター・トポロジでの管理サーバー障害に適用される同じ考慮事項がマルチデータ・センターのアクティブ/アクティブ・ストレッチ・クラスタ・トポロジにも適用されます。高可用性ガイドの管理サーバーのフェイルオーバーまたはフェイルバックに説明されている標準のフェイルオーバー・プロシージャを使用してノード障害に対処します(管理サーバー・ドメイン・ディレクトリをホストしていた共有ストレージを指す同じデータ・センターにある別のノードで管理サーバーを再起動します)。また、適切なバックアップおよびリストア・プロシージャをデプロイして管理サーバーのドメイン・ディレクトリを定期的にコピーします。管理サーバーをホストしているサイト(ノードを含む)に影響を及ぼす障害がある場合、異なるサイトでサーバーを再起動する必要があります。そのためには、既存のストレージ・レプリケーション・テクノロジを使用して、フェルオーバー・サイトで使用可能な管理サーバーのドメイン・ディレクトリをコピーする必要があります。フェイルオーバー・サイトのサーバー/ディレクトリを(ドメインおよびアプリケーション・ディレクトリの両方を含めて)、元のサイトとまったく同一のドメイン・ディレクトリ構造が管理サーバーのドメイン・ディレクトリに対して作成されるようにリストアします。管理サーバーがリストアされるノードでノード・マネージャを再起動します。
同様に、管理サーバーは異なるサブネットにフェイルオーバーされ、その他のノードによりアクセス可能な異なるIP (VIP)の使用が必要になります。このサブネットのホスト名解決システムに適切な変更を加えて、このVIPが管理サーバーがサイト1でリスニング・アドレスとして使用した元の仮想ホスト名にマップするようにします。たとえば、サイト1でADMINHOSTVHN1が10.10.10.1にマップし、一方、サイト2でローカルの/etc/hostsまたはDNSサーバーのいずれかをADMINHOSTVHN1が20.20.20.1にマップされるように更新する必要があります。すべてのサーバーがADMINHOSTVHN1を管理サーバーにアクセスするアドレスとして使用します。管理サーバーがOracle HTTP ServerおよびLBRのフロント・エンドの場合、クライアントはこの変更に依存しません。クライアントが管理サーバーのリスニング・ホスト名に直接アクセスする場合、DNS解決でも更新する必要があります。
また、管理サーバーに対してホスト名検証が有効になっている場合、適切な信頼ストアとキー・ストアも新規証明書で更新する必要があります。『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の手順を使用します。
Oracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方にアクセスして、管理サーバーが正常に機能していることを確認します。
管理サーバーに対してリモートのサーバーは、配置されているサーバーよりも再起動が長くかかります。その理由は、管理サーバーとのすべての通信(起動時にドメイン構成を取得するためのもの)および最初の通信プール作成およびデータベース・アクセスがサイト間の遅延の影響を受けるためです。高可用性ガイドの管理サーバーの高可用性トポロジを参照してください。
自動化されたサイト間でのサーバー移行は、データベースがJMSおよびTLogの永続性のために使用されていないかぎりお薦めしません。それ以外の場合は、適切な永続ストアの一定のレプリカをサイト間で設定する必要があります。
(顧客サイトのインフラストラクチャによっては)あるサイトで使用されている仮想IPが他のサイトへの移行に有効であるという可能性はありません。最初にサイト1で使用可能なリスニング・アドレスをサイト2で(あるいはその逆で)有効にするためには、通常、追加の操作が必要です。この操作は移行前スクリプトで自動化できますが、(単一データ・センターの範囲内で発生する)標準の自動化サーバー移行と比較すると一般にRTOは増加します。
サイト間のトランザクションおよびJMSリカバリは、WebLogic Serverストレッチ・クラスタ内部のサービスまたはサーバーの移行を使用して発生します。サーバーおよびサービスの移行を参照してください。JMSまたはJTAのサーバーまたはサービス移行の場合、高可用性データベース上でリースしているデータベースの使用をお薦めします。コンセンサス非データベース・リースで構成されている場合、ストレッチ・クラスタ内のサーバーがリブートに失敗し、環境でネットワークの分断障害が発生したときにドメイン全体の再起動が必要になる可能性があります。
アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでのゼロ・ダウンタイム・パッチ適用では、ストレッチ・クラスタ内のすべてのサーバーに対する更新が両方のサイト間で編成されます。ゼロ・ダウンタイム・パッチ適用を参照してください。
アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、2つのサイト間でWebLogic Serverクラスタのみを拡張します。Coherenceでは、2つのアクティブなサイト間でデータをレプリケートするためにフェデレーテッド・キャッシュを使用して各サイトにCoherenceクラスタを持つ必要があります。Coherenceクラスタがサイト間で拡張されると、スプリット・ブレインの影響を受けやすくなります。
Oracle Site Guardはアクティブ/パッシブ・トポロジまたはコンポーネントでのみ機能しますアクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、Oracle Site Guardはデータベースのフェイルオーバー/スイッチオーバーのみを実行できます。
表6-1は、ストレッチ・クラスタ・トポロジでのデータベース・リースに構成するお薦めの設定のリストを示しています。Oracle WebLogic Server MBeanリファレンスのMBeanに関する次の説明を参照してください。
表6-1 ストレッチ・クラスタでのデータベース・リースにお薦めする設定
| 構成プロパティ | MBean/コマンド | 説明 | お薦めする設定 |
|---|---|---|---|
DatabaseLeasingBasisConnectionRetryCount |
ClusterMBean |
データベース・リースがデータソースから有効な接続を取得するための最大試行回数。 |
5 (デフォルト値は1) |
DatabaseLeasingBasisConnectionRetryDelay |
ClusterMBean |
接続が失敗したときに、データベース・リースがデータソースから新規接続の取得を試行する前に待機する時間の長さ(ミリ秒)。 |
2000 (デフォルト値は1000) |
TestConnectionOnReserve |
JDBCConnectionPoolParamsBean |
接続をクライアントに渡す前にWebLogic Serverでテストできるようにします。 |
有効。データソースのリース用。サーバーはスイッチオーバー中は稼働状態のままです。 |
-Dweblogic.cluster.jta.SingletonMasterRetryCount |
サーバーの起動コマンド |
シングルトン・マスターが選択されてそのリスニング・ポートをオープンするための試行カウントを指定します。シングルトン・マスターは、JTAを非アクティブ化する最初の試行時にすぐに使用可能にならない場合があります。 |
4 (デフォルト値は20) DatabaseLeasingBasisConnectionRetryCountが5に設定されているため、このプロパティは4に減らせます。この設定はデータベース・サーバーのブート中の時間コストを減らせます。 |
図6-1および図6-2は、ベンチマーク・テスト中に見つかった、異なる遅延に対するシステム全体のスループット(両方のサイトは一緒に稼働しています)で見られる低下を示す結果を表しています。図6-1は、約20ミリ秒のラウンド・トリップ時間(RTT)の遅延中にスループットが25%程度低下することを示しています。図6-2は、アプリケーションをデプロイするためにかかる時間の増加(同じサイトのすべてのサーバーおよびデータベースのデプロイメントと比較した場合)を表しています。
多くのテストで見られる提供データとパフォーマンスのペナルティを考慮して、アクティブ/アクティブ・ストレッチ・クラスタ・トポロジで遅延が2つのサイト間の通信に影響を及ぼす場合は10ミリ秒の遅延(RTT)を超えないことをお薦めします。
アクティブ/アクティブ・ストレッチ・クラスタ・トポロジに対する異なる障害シナリオのそれぞれで継続的可用性の機能がどのように使用されているかについて学習します。
表6-2では、様々な障害シナリオを説明し、継続可用性機能がどのように適用されるかを説明します。様々な障害シナリオの説明については、「潜在的な障害シナリオ」を参照してください。
表6-2 アクティブ/アクティブ・ストレッチ・クラスタおよびアクティブ/パッシブ・データベース層の障害シナリオ
| 継続的可用性の機能 | 完全サイト障害 | 部分サイト/中間層障害(WebLogic Server/Coherence/OTD) | メンテナンス機能停止 | ネットワークの分断障害 |
|---|---|---|---|---|
サイト間のトランザクション・リカバリ |
|
トランザクションが発生してストレッチ・クラスタで使用可能なサーバーにリカバリできるようになるか、サーバー移行が発生してトランザクションが移行済サーバーにリカバリされます。 |
|
|
Oracle Traffic Director |
サイト2のOracle Traffic Directorは、そのサイト上のサーバーへのトラフィックのルーティングを続行します。 |
サイト2のOracle Traffic Directorは、そのサイト上のサーバーへのトラフィックのルーティングを続行します。 |
|
サイト1およびサイト2の両方のOracle Traffic Directorは、それぞれのサイト上のサーバーへのトラフィックのルーティングを続行します。 |
Oracle Site Guard |
Oracle Site Guardはデータベースのフェイルオーバーを編成します |
何もしません。 |
Oracle Site Guardはデータベースのスイッチオーバーを編成します |
何もしません。 |
ゼロ・ダウンタイム・パッチ適用 |
動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールバックが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。 |
動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールアウトが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。 |
動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールバックが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。 |
動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールバックが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。 |
Coherenceフェデレーテッド・キャッシュ |
レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。 |
レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。 |
レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。 |
キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはネットワーク接続が2つのサイト間で再確立されたときに整合します。 |
