| Oracle® Fusion Middleware Oracle WebLogic Serverのための継続的可用性 12c (12.2.1.1.0) E77314-02 |
|
 前 |
内容は次のとおりです。
この項の設計に関する考慮事項および推奨事項は、サポートされているMAAソリューションのすべてに適用され、継続的可用性を提供するために使用できます。MAAアーキテクチャでは、地理的に分散した場所にデータ・センターが展開されます。「継続的可用性に関してサポートされているMAAアーキテクチャ」を参照してください。
Oracle Maximum Availability Architecture(MAA)は、Oracleにおける実証済の高可用性テクノロジ、専門家の推奨事項およびお客様の経験に基づくOracleのベスト・プラクティスのブループリントです。MAAの目的は、コストおよび複雑さを最小限に抑えてOracleのお客様にとって最適な高可用性アーキテクチャを実現することです。
ここでは、次の項目について説明します。
この章で説明されている設計に関する考慮事項および推奨事項は、次の潜在的障害シナリオに適用されます。
完全サイト障害 - 完全サイト障害では、本番環境の負荷に対応するよう準備されたセカンダリ・サイトにデータベース、中間層アプリケーション・サーバーおよびすべてのユーザー接続をフェイルオーバーします。
部分サイト障害 - このドキュメントの文脈では、部分障害は中間層で発生します。中間層での部分サイト障害は、中間層全体(WebLogic ServerおよびCoherence)、WebLogic Serverのみの障害、Coherenceクラスタ障害、またはOracle Traffic Directorで2つのインスタンスに高可用性が構成されているときの一方のインスタンス内の障害から構成されることがあります。
ネットワークの分断 - サイト間の通信が失敗します。
メンテナンス機能停止 - 計画済メンテナンス中にサイトのすべてのコンポーネントが段階的に停止されます。スイッチオーバーがサイトからサイトへと実行されます。
異なる障害シナリオにおける継続的可用性の機能の動作を次の項で説明します。
グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。
プライマリサイト障害の場合に、スタンバイ・サイトが本番ロールをとった後、グローバル・ロード・バランサがユーザー・リクエストをスタンバイ・サイトへ再ルーテイングするために使用されます。F5 –BigIP Global Traffic Manager (GTM)およびCisco –Global Site Selector (GSS)などのグローバル・ロード・バランサは、(解決プロセスを従来型のDNSサーバーからオフロードすることで)DNSサーバー解決も処理します。
通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、スタンバイ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだスタンバイ・サイトにリクエストが送信されるようになります。
DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバー(計画済)およびフェイルオーバー(計画外)として機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。DNSスイッチオーバーの実行手順は、『ディザスタ・リカバリ・ガイド』のDNS名の手動変更に関する項を参照してください。
MAA環境では、Oracle Traffic Directorフェイルオーバー・グループを構成する必要があります。Oracle Traffic Directorの2つのインスタンスを1つまたは2つの仮想IP (VIP)アドレスを使用して結合すると、高可用性が保証されます。フェイルオーバー・グループ内の両方のホストでは、同じオペレーティング・システム・バージョンを実行し、同一のパッチおよびサービス・パックを使用し、同じ構成のOracle Traffic Directorインスタンスを実行する必要があります。
2つのOracle Traffic Directorインスタンスが高可用性を提供するために仮想IPアドレス(VIP)でグループ化されている場合、アクティブ/パッシブ・フェイルオーバー・モードになります。VIPはリクエストを受信して、プライマリ・インスタンスと指定されているOracle Traffic Directorインスタンスにルーティングします。プライマリ・インスタンスに到達できない場合、リクエストはバックアップ・インスタンスにルーティングされます。
アクティブ/アクティブ・フェイルオーバー・モードには、2つのフェイルオーバー・グループが必要です。各フェイルオーバー・グループは一意のVIPを持つ必要があり、それぞれプライマリ・ロールとバックアップ・ロールが逆となる同じノードで構成されています。フェイルオーバー・グループ内の各インスタンスは、プライマリ・インスタンスおよびバックアップとして指定され、それぞれにVIPが1つずつ割り当てられます。フェイルオーバー・グループの詳細は、『Oracle Traffic Directorの管理』のフェイルオーバー・グループの作成と管理に関する項を参照してください。
Oracle Traffic DirectorをLinuxプラットフォームで高可用性モード(アクティブ/パッシブとアクティブ/アクティブの両方)で実行している場合、フェイルオーバー・グループを構成するために使用されるすべてのホスト上でOracle Traffic DirectorのみがKeepalivedプロセスのコンシューマであることを確認してください。KeepalivedはLinux上で実行されるプロセスです。これはヘルスチェック・フレームワークで、Hot Standbyプロトコルを実装しています。これらのホスト上で実行され、Keepalivedプロセスを必要とするアプリケーションは他にありません。
Oracle HTTP ServerおよびApacheプラグインも、Continuous AvailabilityアーキテクチャでWebLogic Serversに対するリクエストのロード・バランスをとるために使用できますが、Oracle Traffic Directorで受け取る統合は提供されません。
次の各項で、Oracle Traffic Directorに継続的可用性を構成するための特定のガイドラインを提供します。
ネットワークの準備
Oracle Traffic Directorのフェイルオーバー・グループに使用する各サイトごとに仮想IPアドレスを1つ割り当てます。アドレスは、フェイルオーバー・グループ内のノードと同じサブネットに属している必要があります。このアドレスはDNSで解決可能でネットワーク上でアクセス可能である必要があります。フェイルオーバー・グループの仮想IPが作成されるネットワーク・インタフェースで、すべての管理ノード・ホストで同じアドレスであることを確認してください。これは、フェイルオーバー・グループをプライマリ・サイトからスタンバイ・サイトに円滑に移行するための必要条件です。
スタンバイ・サイトで、プライマリ・サイトのホスト名およびプライマリ・サイトの仮想IPが対応するピア・システムのIPアドレスに解決されることを確認してください。これは、/etc/hostsファイルでホスト名の別名を作成して設定できます。両方の障害時リカバリ・デプロイメント・オプションに対して、すべてのシステム用の別名およびIP名が存在することを確認してください。
ベスト・プラクティス
スタンバイ・サイトを定期的にテストすることをお薦めします。これは、両サイトでの障害を軽減するために役立ちます。スタンバイ・サイトを、現在のプライマリ・サイトとロールを切り替えてテストします:
サイト・スイッチオーバー・プロシージャに従ってスタンバイ・サイトを新規プライマリ・サイトに切り替えます。
一度テストが完了したら、サイト・スイッチバック・プロシージャに従ってロールをリバースします。
定期的テストで、プライマリ・サイトとスタンバイ・サイトの両方が完全に機能していることが検証され、両方のサイトで障害のリスクが軽減されます。スイッチオーバー・プロシージャおよびスイッチバック・プロシージャも検証されます。
同じプロジェクト内でプロジェクトレベルおよび共有レベルのレプリケーションを構成しないでください。
Oracle Traffic Director設定が共有ストレージにあり、リモート・サイトにレプリケートされてOracle Traffic Directorのバイナリおよび最新の構成データがサイト障害またはサイト・メンテナンス・イベント中にスタンバイ・サイトで使用可能になっていることを確認します。Oracle Traffic Directorのすべてのバイナリ、構成データ、ログおよびセキュリティ・データが既存のレプリケーション・テクノロジを使用してリモート・サイトにレプリケートされている必要があります。
次の場合、プロジェクトおよび共有にスケジュール・レプリケーション・モードを使用します。
データが頻繁には変更されません。
リカバリ・ポイントの目標値は、スケジュールされたレプリケーション期間内に入ります。
次の場合、プロジェクトおよび共有に継続的レプリケーション・モードを使用します。
スタンバイ・サイトは可能なかぎりプライマリ・サイトに近いことが必要です。
リカバリ・ポイントの目標値は数秒の範囲で、許容されるのはほとんど発生しないデータ損失に対するものです。データは重要な性質を持ったものです。
バックアップ、テストおよび開発タイプの環境をオフロードするためにスナップショットおよびクローンをターゲット・サイトで使用できます。
ローカル・スタンバイ・サイト(データ・センター内の障害時リカバリ)を構成する場合はレプリケーション・チャネルでSSLを無効にすることを検討します。暗号化アルゴリズムを削除するとレプリケーション・スループットがより高くなります。
レプリケーションがワイド・エリア・ネットワークにわたる場合は常にSSLを有効にします。OTDインスタンス同期ベースのスタンバイ障害時リカバリ・オプションの場合、OTDインスタンスの変更をサイト間で転送するためにリモート同期ツールおよびスケジューラ・アプリケーションが各サイトの管理サーバー・ホストに必要です。NIS設定が構成されNISサービスが開始されていることを確認します
Web層の構成は継続的可用性MAAアーキテクチャではオプションです。Oracle HTTP Server (OHS)およびOracle WebLogic Serverプロキシ・プラグインなどのWeb層製品は、WebLogic Serverアプリケーションを効率的にフロントエンド化にするように設計されています。
可能な場合、Oracle Traffic Director (OTD)を使用してWebLogic Serverインスタンスに対するすべてのロード・バランシングを処理することをお薦めします。次の場合は、Oracle Traffic Directorを含むWeb層をフロントエンドにしないでください。
HTML、イメージ、JavaScriptなどのような静的コンテンツ。Oracle Traffic Directorは、ロールアウト処理中に最大可用性を提供するゼロ・ダウンタイム・パッチ適用や、MTパーティション内のアプリケーションおよびリソースのWebLogicクラスタ間での移行中に継続的可用性を提供するライブ・パーティション移行などのContinuous Availability機能と統合されています。
Oracle HTTP ServerまたはWebLogic Serverプロキシ・プラグインをすでに使用しているミドルウェア構成。
既存のレプリケーション・テクノロジまたは方法を使用して、Web層のバイナリおよび構成をサイト間で整合性のあるものにします。
OHSおよびWebLogic Serverプロキシ・プラグインはその他のWebLogic Server Continuous Availability機能とともに使用できますが、手動操作が必要な場合がありOracle Traffic Directorと同様レベルの可用性が提供されません。
Oracle HTTP ServerおよびWebLogic Serverプロキシ・プラグインの詳細は次を参照してください。
Oracle HTTP Serverの管理
Oracle WebLogic Serverプロキシ・プラグイン12.2.1.1の使用
継続的可用性MAAアーキテクチャでのWebLogic Serverの設計に関する考慮事項の詳細は、次の各項を参照してください。
WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティ、信頼性および高可用性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは同じマシン上で実行することも、複数のマシンに配置することもできます。クラスタの能力は、既存のマシン上のクラスタにサーバー・インスタンスを追加することによって強化できます。また、新たにサーバー・インスタンスを配置するためのマシンをクラスタに追加することもできます。クラスタ内の各サーバー・インスタンスでは、同一バージョンのWebLogic Serverを実行する必要があります。
WebLogic Serverでは、次の2種類のクラスタがサポートされます。
動的クラスタ - 動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。これにより、追加のサーバー容量が必要な場合に動的クラスタ内のサーバー・インスタンスの数を簡単にスケール・アップできます。動的クラスタにより、ルールおよびポリシーを定義および構成して動的クラスタをスケール・アップまたは縮小できます。
動的クラスタでは、管理対象サーバーの構成は単一の共有テンプレートに基づいています。クラスタ化された管理対象サーバーの構成が非常に簡素化され、マシン・リソースへのサーバーの動的割当ておよび最小構成を使用したリソース使用率の増加が可能になります。
動的クラスタの拡張度により、ユーザーが識別した条件に基づいてクラスタをスケール・アップまたはダウンできます。クラスタのスケーリングは、要求時に(管理者により対話的に)特定の日時に、または様々なサーバー・メトリックで見られるパフォーマンスに基づいて実行できます。
動的クラスタを縮小する場合、管理対象サーバーは段階的に停止され、作業/トランザクションを完了できます。必要に応じて、シングルトン・サービスが自動的にクラスタ内の別のインスタンスに移行されます。
静的クラスタ - 静的クラスタでは、エンドユーザーが新規サーバーを構成してクラスタに追加し、手動で起動および停止する必要があります。クラスタの拡張および縮小は自動ではないため、管理者が実行する必要があります。
多くの場合、動的クラスタを使用して拡張度をWebLogicデプロイメントに提供することをお薦めします。動的クラスタの利点は、最小構成、クラスタの拡張度およびクラスタ縮小時のJMSとJTAシングルトン・サービスの適切な移行です。
ただし、一部のインスタンスでは静的クラスタの使用が必要なものがあります。
手動でシングルトン・サービスを移行する必要がある場合。動的クラスタはシングルトン・サービスの手動の移行をサポートしていません。
お使いの構成がOracle SOA SuiteおよびOracle Business Process Managementなど、Oracle Fusion Middlewareの上位スタック製品を含む場合。これらの製品は、このリリースでは動的クラスタのサポートを提供していません。
シングルトン・サービスとは、管理対象サーバーで実行されるサービスであり、1度にクラスタ内の1つのメンバー上でのみ使用可能になります。WebLogic Serverでは、シングルトン・サービスを自動的に監視したり、あるサーバー・インスタンスから別のサーバー・インスタンスに移行したりできます。
JMS関連サービスおよびユーザー定義シングルトン・サービスなどの固定サービスは、WebLogicクラスタ内の個々のサーバー・インスタンスにホストされています。シングルトンJMSまたはJTAサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、シングルトン・サービスをクラスタ内の任意のサーバー・インスタンスに自動または手動で移行できるようにWebLogic Serverを構成できます。
アプリケーション内に、クラスタの複数のメンバーで同時に実行したくないタスクを実行するためのシングルトン・サービスを定義できます。シングルトン・サービスの自動移行では、ユーザー定義シングルトン・サービスのヘルス・モニタリングと移行を自動化できます。
シングルトン・サービスについては、次の項で説明します。内容は次のとおりです。
Oracle WebLogic Serverでは、次の2種類の自動移行メカニズムをサポートしています。
サーバー全体の移行では、移行可能なサーバー・インスタンスとそのすべてのサービスが、障害発生時に物理的に別のマシンに移行されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。サーバー全体の移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。
サービスの移行では、失敗したサービスが1つのサービス・インスタンスからクラスタ内で使用可能な別のサーバー・インスタンスに移行されます。状況によっては、サービスの移行のほうがサーバー全体の移行よりはるかに良好に機能します。これは、サーバー全体とは対照的にシングルトン・サービスの移行のみを実行しているためです。サービスの移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項を参照してください。
サーバー全体の移行およびサービスの移行は、どちらもデータベースのリース表を構成する必要があります。詳細は、「リース」を参照してください
MAA環境でサーバーおよびサービスの移行を使用するためのWebLogicサーバーの構成の詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のエンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用に関する項を参照してください。
Oracle WebLogic Serverのトランザクション・ログおよびOracle WebLogic ServerのJMSには、データベース・ベースおよびファイル・ベースの2種類の永続データ・ストアがあります。
永続ストアをデータベースに保持することにより、基礎となるデータベース・システムに固有のレプリケーションおよび高可用性の利点が提供されます。JMS、TLogおよびアプリケーションが同じデータベースおよびOracle Data Guardで処理されたレプリケーション内にある場合、クロスサイトの同期が簡素化され、NASやSANなどの共有ストレージ・サブシステムの必要性は中間層で軽減されます。データベースを参照してください。
ただし、TLogおよびJMSストアをデータベースに格納すると、システム・パフォーマンスに対するペナルティがあります。このペナルティは、サイトの1つが他のサイトのデータベースと相互通信する必要がある場合に増加します。理想的には、パフォーマンスの観点から見て、各サイトに対してローカルな共有ストレージを両方の種類のストアに使用し、パフォーマンスの低下なしでゼロ・データ損失を保証するためにストレージ・レベルでの適切なレプリケーション戦略とバックアップ戦略をプロビジョニングする必要があります。データベース・ストアを使用したほうがシステム用の共有ストレージより適しているかどうかは、JMSおよびトランザクション・データの重要度によります。これは、共有ストレージが提供する保護のレベルがデータベースが保証するよりはるかに低いためです。
アクティブ/アクティブ・トポロジおよびアクティブ/パッシブ・トポロジでは、データベースにデータ・ストアを維持することが必須です。JMSおよびJTAストアなどのWebLogic Serverストアを、Oracle RACなどの高可用性のデータベースに維持し、最大のパフォーマンスおよび可用性を得るためにActive GridLinkデータソースを使用してデータベースに接続することをお薦めします。
アクティブ/アクティブ・ストレッチ・クラスタの場合、データ・ストアをNASやSANなどの共有ストレージ・サブシステムに維持するか、データベースに維持するかを選択できます。
リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタ全体エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に1つしか存在しません。また、サーバーやクラスタの障害時にはリースをフェイルオーバーさせることができ、シングル・ポイント障害を回避するために役立ちます。リースの詳細は、Oracle WebLogic Serverクラスタの管理のリースに関する項を参照してください。
データベース・リースの場合、次をお薦めします。
Oracle RACおよびActive GridLink (AGL)などの高可用性データベース。
スタンバイ・データベース、および2つのデータベース間のレプリケーションを提供するOracle Data Guard。
データベース・リースを使用する際、データベースが(スイッチオーバーまたはフェイルオーバー中に)サーバー移行の分離時間よりも長い期間使用不可を続けている場合、Oracle WebLogic Serversが停止する場合があります。サーバー移行の分離時間は、『Oracle WebLogic Serverクラスタの管理』の次のトピックに説明されているように調整できます。
WebLogic Serverでは、クラスタ内の複数のサーバー間でHTTPセッション状態をレプリケートするために次の3つの方法が用意されています。
メモリー内レプリケーション - WebLogic Serverはメモリー内レプリケーションを使用して、1つのサーバー・インスタンスから別のインスタンスにセッション状態をコピーします。プライマリ・サーバーはクライアントが最初に接続するサーバー上にプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンス上に予備のレプリカを作成します。サーブレットのホストとなっているサーバーで障害が起きた場合に使用できるように、レプリカは最新の状態に保たれます。
JDBCベースの永続性 - JDBCベースの永続性では、WebLogic Serverはファイル・ベースまたはJDBCベースの永続性メカニズムを使用して、サーブレットまたはJSPのHTTPセッション状態を保持します。それぞれの永続性メカニズムの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のセッションの永続性の構成に関する項を参照してください。
Coherence*Web - Coherence*Webは、WebLogic ServerのインメモリーHTTP状態レプリケーション・サービスの代替ではありません。ただし、アプリケーションに大量くのHTTPセッション状態オブジェクトがある場合、HTTPセッション状態オブジェクト・データの格納によってメモリー制約が発生する場合、または既存のCoherenceクラスタを再利用する場合は、Coherence*Webを使用することをお薦めします。詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のWebLogic ServerでのCoherence*Webの使用方法に関する項を参照してください。
遅延モデル、セッション損失に対する許容度およびパフォーマンスに応じて、もっとも要件に適した方法を選択する必要があります。
遅延が小さい場合、たとえばMANネットワーク(ストレッチ・クラスタ・トポロジ)などでは、WebLogic Serverインメモリー・セッション・レプリケーションをお薦めします。ただし、サイトで障害が発生した場合はセッション損失の可能性があります。
遅延が大きく(WANネットワーク)、アクティブ/アクティブまたはアクティブ/パッシブ・トポロジの場合、およびお使いのアプリケーションがセッション損失を許容できない場合、データベース・セッション・レプリケーションをお薦めします。
多くの場合、インメモリー・セッション・レプリケーションのほうがデータベース・セッション・レプリケーションよりはるかに良好に機能します。詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタのフェイルオーバーとレプリケーションに関する項を参照してください。
WebLogic Active GridLink Data Sourcesは、Oracle RACデータベースおよびOracle Data Guardと統合されて最高のパフォーマンス、高いスケーラビリティおよび最高の可用性を提供します。Oracle RACとの統合により、Active GridLinkは高速接続フェイルオーバー(FCF)、ランタイム接続ロード・バランシング(RCLB)およびアフィニティの各機能を実行できます。Active GridLinkは、データベース内の計画済メンテナンスを、エンドユーザーに対する中断なしで処理する一方ですべての作業が完了するようにできます。
JMSおよびJTAストアなどのWebLogic Serverストアおよびリース表を、Oracle RACなどの高可用性のデータベースに維持し、Active GridLinkデータソースを使用してデータベースに接続することをお薦めします。データベース内でストアおよびリース表を格納する方法には、次のメリットがあります。
基礎となるデータベース・システムに固有のレプリケーションおよびその他の高可用性の側面を利用します。
障害時リカバリ・シナリオの処理を強化します。JMS、TLogおよびアプリケーションが同じデータベース内にありレプリケーションがData Guardにより処理される場合、クロスサイトの同期について心配する必要はありません。
NASまたはSANなどの共有ストレージ・サブシステムの必要性を軽減します。データベースの使用により全体的なシステムの複雑さも減ります。これは多くの場合、データベースが標準のランタイム/アプリケーション作業用にすでに存在しているためです。
お使いのActive GridLink URLを構成してフェイルオーバー時間をデータベース間で最小化できます。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の次のトピックを参照してください。
サポートされるAGLデータソースURL形式
AGLデータソースURLに関する推奨事項
WebLogic ServerとJava EEアプリケーションを本番環境にデプロイする前に、セキュリティ・ニーズを決定し、適切なセキュリティ対策を講じることが重要です。詳細は、『Oracle WebLogic Server本番環境の保護』の本番環境のセキュリティの確保に関する項を参照してください。
通常、特定の環境内のOracle Fusion Middlewareコンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。MAA環境で考慮が必要な一部のストレージ・アーティファクトは静的および動的として分類されています。
静的アーティファクトは、頻繁には変更されないファイルやディレクトリです。これには次のものがあります。
ホーム: Oracleホームは通常、OracleホームとOracle WebLogic Serverホームで構成されます。
Oracleインベントリ: これには、/etcディレクトリにある、oraInst.locおよびoratabファイルが含まれます。
動的またはランタイム・アーティファクトは、頻繁に変更されるファイルです。ランタイム・アーティファクトには、次のものが含まれています。
ドメイン・ホーム: 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。
Oracleインスタンス: Oracleインスタンスのホーム・ディレクトリ。
.earファイルや.warファイルなどのアプリケーション・アーティファクト。
MDSリポジトリなどのデータベース・アーティファクト。
Oracle Fusion Middlewareで使用されるデータベース・メタデータ・リポジトリ。
JMSプロバイダやトランザクション・ログなどの永続ストア。データ・ストアを参照してください。
デプロイメント・プラン: ファイル・アダプタやJMSアダプタなどのテクノロジ・アダプタの更新に使用されます。これらは、アーティファクトがデプロイされるクラスタ内のすべてのノードにアクセスできる場所に保存する必要があります。
可用性が最大になるように、バイナリの冗長インストールを使用することをお薦めします。各ノードは独自のOracleホームを持ち、ゼロ・ダウンタイム・パッチの適用時に1つのノード内のサーバーのみが一度に停止されるようにする必要があります。
ゼロ・ダウンタイム・パッチ適用(ZDTパッチ適用)では、アップグレードのロールアウト処理中に継続的なアプリケーション可用性が提供されます。これはロールアウト処理中の障害の可能性が常に存在しても変わりません。MAA環境では、一度に1つのサイトに対してパッチを適用し、その他のサイトに対する更新の時間をずらしてサイトの同期が残るようにすることをお薦めします。サイト障害シナリオの場合、失敗したサイトがZDTパッチ適用を再開する前に再開できるようにします。
ZDTパッチ適用を使用する場合、次を考慮してください。
ロールアウトは一度に1つのノードを停止するため、クラスタ内のノードが増えるほどクラスタのトラフィック処理能力への影響が少なくなります。
クラスタのノードが2つのみで一方のノードがパッチ適用のために停止している場合、高可用性は保証されません。クラスタ内には2個を超えるノードを持つことをお薦めします。
管理対象サーバーを管理サーバーと同じノードに含めた場合、両方のサーバーをともに停止してOracleホームを更新する必要があります。
2つのクラスタでOracleホームを共有する同じノード上にサーバーを持つことができますが、両方のクラスタを停止して同時にパッチを適用する必要があります。
Oracleホームが2つ含まれている構成の場合、適用するパッチをテストできるように、本番マシン以外に2つ目のOracleホームを作成してパッチを適用することをお薦めしますが、必須ではありません。そのノードのOracleホームは、本番ドメインで使用しているOracleホームと同じである必要があります。
クロスサイトXAトランザクション・リカバリはリース・フレームワークを使用してクロスサイト・リカバリを自動化しています。クロスサイト・トランザクション・リカバリのためのリース表の設計要件は、リースで説明されているように基本的にトランザクション・リカバリ・サービスのデータベース・リース用に定義された要件と同じです。リース表は管理対象サーバーが起動されてサイトが構成されるときに自動的に作成されます。サイトのすべてのドメインについて、サイト当たり1つのリース表があります。
詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』の複数サイトまたはデータ・センターにまたがるトランザクション・リカバリに関する項を参照してください。
管理対象サーバーのリスニング・アドレスを指定するには(静的IPではなく)ホスト名を常に使用し、すべてのサイトに同一のホスト名を構成することをお薦めします。サイト間でホスト名は同一で、IPは同一ではないため、同じように構成されたサーバーまたはドメインをリカバリ・サイトで単純に開始する動的な機能がホスト名により提供されます。
表3-1は、継続的可用性のMAAトポロジで構成できるJTA MBeanプロパティに対してお薦めする設定を示しています。詳細は、Oracle WebLogic Server MBeanリファレンスのJTAMBeanに関する項を参照してください。
表3-1 クロスサイトXAトランザクション・リカバリ用の構成可能なMBeanプロパティ
| 構成プロパティ | 説明 | お薦めする設定 |
|---|---|---|
CrossSiteRecoveryLeaseExpiration |
リースが期限切れになり、その後別のサイトによるリカバリの対象となる時間を秒数を指定します。 |
30秒(デフォルト) |
CrossSiteRecoveryRetryInterval |
リカバリ・サイト・サーバーがリース表をチェックしてリースが期限切れになっていないか、所有するサーバーが停止していないかを確認する間隔を指定します。 |
60秒(デフォルト) |
CrossSiteRecoveryLeaseUpdate |
サーバーがそのリースを更新する頻度を指定します |
10秒(デフォルト) |
継続的可用性MAAアーキテクチャでのCoherenceの設計に関する考慮事項の詳細は、次の各項を参照してください。
(ストレッチ・クラスタではなく)フェデレーテッド・キャッシュを実行しているCoherenceの場合、問題のいくつかを次に示します。
Coherenceデータが、ネットワークの分断またはリモート・クラスタの機能停止の後も他のサイトのなんらかのポイントに順序付け方式で到達しています(Coherenceでは順序付けはCoherenceパーティションごとです)。
リモート・サイトはローカル・サイトが更新された後の一定期間に失効データを読み取る場合があります。
更新競合の可能性があり、これらを識別してアプリケーション固有の競合解消機能を呼び出します。
Coherenceフェデレーテッド・キャッシュは、次の理由でサイト間に最終競合モデルを実装しています。
データ・センターはどこにでも配置でき、場所は遅延または使用可能な帯域幅に制約されません。
リモートのデータ・センターまたはクラスタの使用不可状態が許容されることは、きわめて望ましいことです。通信が停止していることとリモート・クラスタが停止していることの違いを述べることは非常に困難であり、区別する必要はありません。
アクティブ/アクティブ構成における完全整合性にはなんらかの種類の分散センターの並行制御および同期書込みが必要です。これは、パフォーマンスに大きな影響を与えることがあり、望ましいことではありません。かわりに、整合性が重要なところでは、同期レプリケーションを伴うストレッチ・クラスタを使用できます。この場合、データ・センター間に保証帯域幅とともに最大遅延をアサートすることが妥当です。
致命的障害や、計画的メンテナンスによるクラスタ再起動の後に迅速なリカバリができるように、キャッシュされたデータは保持されます。マルチデータ・センター環境では、Coherence永続性およびフェデレーテッド・キャッシュの両方を使用して障害時または計画メンテナンス・イベント中の最高レベルの保護を確保することをお薦めします。
永続性は、分散キャッシュに対してのみ使用可能で、集中パーティション割当て戦略を使用する必要があります。次の2つの永続性モードがあります。
アクティブ永続性 – キャッシュの内容はすべてのミューテーションで自動的に永続化され、クラスタ/サービスの起動時に自動的にリカバリされます。
オンデマンド永続性 – キャッシュ・サービスは手動で永続化され、リクエスト時に永続性コーディネータを使用してリカバリされます。
詳細は、『Oracle Coherenceの管理』の永続キャッシュに関する項を参照してください。
データの混合を伴う単一Coherenceクラスタ内では、データの一部がデータベースにより所有され、一部がCoherenceにより所有され、Coherence Read-ThroughキャッシュとCoherence GoldenGate Hot Cacheの両方を使用できます。
HotCacheおよびRead-Throughキャッシュ間の選択は、(1) データベースがCoherenceのバックで更新された場合にRead-Throughが失効読取りにつながる場合があるか、(2) HotCacheのリアルタイム性が他の理由で優先されるかということになります。HotCacheおよびRead-Throughの両方を併用して、たとえばHotCache経由でリアルタイム更新をプッシュするが、その後は削除または期限切れのためにデータが削除されたケースを処理するという状況もありえます。
Oracle Databaseの障害時リカバリに説明されているように、OracleではMAAアーキテクチャでデータベースの高可用性を提供するために統合できる製品をいくつか提供しています。トポロジに関係なく、目標はデータベースのスイッチオーバーおよびフェイルオーバーにかかる時間を最小化することです。
計画済および計画外の両方の停止に備えてお使いのデータベースの高可用性を達成するには、次の製品を組み合せたアクティブ/パッシブ構成を使用することをお薦めします。
可用性の高いデータベースとしてのOracle RAC。
ミッション・クリティカルなOracle Databaseに対する単一点障害を排除するOracle Data Guard。これは、リモートの場所に同期化された本番データベースの物理レプリカを維持することによって、データ損失および停止時間を防止します。本番データベースがどのような理由で使用不可になっている場合でも、クライアント接続が短時間で、また一部の構成では透過的に、同期されたレプリカにフェイルオーバーされてサービスを回復します。アプリケーションは、わずかな変更または変更なしでOracle Data Guardを利用できます。
注意:
Oracle Data Guardはアクティブ/パッシブ構成でのみ使用できますが、ゼロデータ損失が保証されます。
Oracle Active Data Guardは、Oracle Data Guardのインフラストラクチャの組込みオプションで、プライマリ・データベースから変更が適用されている間も、フィジカル・スタンバイ・データベースを読取り専用で開くことができます。これにより、読取り専用アプリケーションは、プライマリ・データベースで非常に大きいトランザクション・ボリュームの処理中であっても、スタンバイ・データベースとプライマリ・データベース上のデータ間での遅延を最小限に抑えながら、フィジカル・スタンバイを使用できます。これはリアルタイム問合せと呼ばれることもあります。
Oracle Active Data Guardスタンバイ・データベースは、アプリケーションに透過的に、プライマリ・データベースにより検出されたデータ破損の自動修復に使用されます。プライマリ・データベースでの計画外停止の場合も、スタンバイ・データベースへの迅速なフェイルオーバーにより高可用性が保たれます。Active Data Guardスタンバイ・データベースは、プライマリ・データベースのブロック対ブロックのフィジカル・レプリカであるため、特定のプライマリ・データベースから高速増分バックアップをオフロードすることもできます。
Oracle Data Guardブローカは、Data Guard構成の作成、メンテナンス、監視を自動化および集中化する分散管理フレームワークです。Data Guard Brokerが実行できる操作の一部として、Data Guard構成の作成、管理、監視、構成内のすべてのデータベースにわたる複雑なロール変更を開始および制御するためのスイッチオーバーまたはフェイルオーバーの起動、およびフェイルオーバーを自動発生させるための構成があります。
Data GuardブローカをOracle Data Guardとともにデプロイすることは、Oracle Site Guardを障害時リカバリに使用できるようにする前に必須のことです。
Active GridLinkは、データベース・サーバーのスケジュール済メンテナンス・プロセスをアプリケーションに対して透過的にします。データベース・サーバーでメンテナンスのためにインスタンスを停止する場合、セッション排出によって、そのノードでインスタンスを使用しているすべての作業が完了し、アイドル・セッションが削除されることが保証されます。セッションは、処理中の作業に影響を与えることなく排出されます。
Application Continuityは、計画済および計画外の停止中にユーザーを保護します。計画外の停止イベント中に最大の可用性を得るにはApplication ContinuityおよびActive GridLinkを使用します。
サイトにまたがって排出する高速アプリケーション通知(FAN)を伴うGlobal Data Services (GDS)またはData Guardブローカ。Active Data Guardを使用する場合、セカンダリ・データベースにスイッチオーバーされる前に作業が完了する可能性があります。
お使いの構成でアクティブ/アクティブ・データベース構成が必要な場合、次をお薦めします。
Oracle GoldenGate。データベースをアクティブ/アクティブ・モードにできます。読取りおよび書込みサービスの両方が両方のサイトのデータベースでアクティブ/アクティブであること。詳細は、『Oracle GoldenGateの管理for Windows and UNIX』のアクティブ/アクティブ型高可用性のためのOracle GoldenGateの構成に関する項を参照してください。
Oracle Golden Gateを使用する際、Application ContinuityおよびActive GridLinkをサイト内(イントラサイト)で使用して計画済および計画外の停止のデータベース・イベントを処理できます。Application Continuityは、サイト間(インターサイト)のフェイルオーバーまたはスイッチオーバー操作中に使用してトランザクションをリプレイすることはできません。Application Continuityは、Oracle Logical StandbyおよびOracle Golden Gateを含めた論理的に異なるデータベースに対するフェイルオーバーをサポートしていません。リプレイには、トランザクション・ロスがないことが検証済のデータベースに適用される厳密な要件があります。
注意:
Oracle GoldenGateの非同期レプリケート特性のため、アプリケーションはネットワークの遅れが原因のデータ損失を許容する必要があります。
Oracle GoldenGateを使用するすべてのアプリケーション/スキーマに対して完全なアクティブ/アクティブを備えた競合解決を実装すること。
失効データ(対話中のサイトに限定)の表示を避けるためにWebアフィニティを必要とする環境を設計すること。Global Data Services (GDS)は、サイトにローカルなデータベースに対するアフィニティを提供してグローバル・サービスを管理できます。
環境でアクティブ/アクティブ・データベースが必要な場合、これらのテクノロジの組合せを使用して計画済メンテナンス・イベントで可用性を最大限、データ損失を最小限にできます。
Oracle Site GuardはOracle Enterprise Managerの一部であり、障害時リカバリ・サイトの間に柔軟でシームレスなスイッチオーバーとフェイルオーバーの編成を提供することでエンタープライズ・デプロイメントの停止時間を最小限に抑えることができます。Oracle Site Guardの障害時リカバリ自動化機能により、ヒューマン操作の必要性が排除され、スイッチオーバーまたはフェイルオーバー・プロセスでの人為的エラーが防止されます。
Oracle Site Guardをサイト間でのスイッチオーバーおよびフェイルオーバーのために構成する方法の詳細は、『Site Guard管理者ガイド』のOracle Site Guardの構成に関する項を参照してください。
Site Guardのベスト・プラクティスは、http://www.oracle.com/technetwork/database/availability/maa-site-guard-exalogic-exadata-1978799.pdfにあるOracle Exalogic用Oracle Site Guardを使用した障害時リカバリの自動化ホワイト・ペーパーを参照してください。
一般的な設計に関する考慮事項および推奨事項に説明されているようにすべての継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層に示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。
アクティブ/アクティブ・トポロジで継続的可用性の機能を最大限に利用するには、次を考慮してください。
アクティブ/アクティブ・ドメインは対称的トポロジで構成する必要があります。これらは類似しており、同じドメイン構成(ドメインおよびサーバーの名前、ポート番号、ユーザー・アカウント、ロード・バランサおよび仮想サーバー名など)と同じソフトウェア・バージョンを使用する必要があります。ホスト名(静的IPではない)は、管理対象サーバーのリスニング・アドレスの指定に使用する必要があります。このトポロジでクロスサイト・トランザクション・リカバリを構成すると、構成可能なMBeanプロパティ、SiteName、RecoverySiteNameはサイト固有です。サイトを同期状態に維持するために現在使用している既存のレプリケーション・テクノロジまたは方法はすべて使用できます。
注意:
クロスサイトXAトランザクション・リカバリを利用する際、いくつかの構成パラメータ(表3-1を参照)が、サイトに固有の「サイト名」および「リカバリ・サイト名」とともに存在します。構成をレプリケートするときにこれらのパラメータおよび名前を上書きしないでください。
このトポロジ・ネットワークの遅延は、通常大です(WANネットワーク)。アプリケーションでサイト間のセッションのレプリケーションが必要な場合、データベース・セッション・レプリケーションまたはCoherence*Webのいずれかを選択する必要があります。セッション・レプリケーションを参照してください。
サーバーおよびサービスの移行は、アクティブ/アクティブ・トポロジのイントラサイト(サイト内)でのみ適用されます。詳細は、サーバーおよびサービスの移行を参照してください。
JMSはこのトポロジのイントラサイトでのみサポートされています。フェイルオーバーまたは計画済メンテナンス中のJMSリカバリはサイト間ではサポートされていません。
ゼロ・ダウンタイム・パッチ適用は、アクティブ/アクティブ・トポロジのイントラサイト(サイト内)でのみ適用されます。各サイトのWebLogicホーム、Javaおよびアプリケーションは別々にアップグレードできます。アップグレード・バージョンを同期状態に維持し、両方のサイトのドメインを対称に維持してください。
異なるContinuous Availability機能を組み合せることにより、障害時のデータ損失を最小限にするようにアプリケーションを設計できます。たとえば、クロスサイトXAトランザクション・リカバリ、Coherenceフェデレーテッド・キャッシュ、Coherence HotCacheまたはCoherence Read-Throughキャッシュを組み合せて使用できます。
Coherenceデータがデータベースにバックアップされており、ネットワーク・パーティション障害が発生した場合、フェデレーテッド・キャッシュはレプリケーションを実行できず、Coherenceクラスタが独自に作業を継続できるため、両方のサイトのデータの整合性が失われます。サイト間の通信が再開すると、バックアップされたデータがデータベースからCoherenceにCoherence HotCacheまたはCoherence Read-Throughキャッシュ経由で送られ、最終的にはCoherenceキャッシュのデータが同期されます。Coherenceを参照してください。
アクティブ/アクティブ・トポロジでは、Oracle Site Guardはデータベースのスイッチオーバーまたはフェイルオーバーのみを実行できます。アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の障害シナリオを参照してください。
図3-1および図3-2は、クロスサイト・トランザクション・リカバリのデフォルト・パラメータ設定を使用したベンチマーク・テスト中に見つかった結果を表しています。この図は、中間層が失敗したときのサイト間でのトランザクションのリカバリで生じた遅延を示しています。図3-1は、サイト間の遅延が1秒の場合に平均リカバリ時間が170から180ミリ秒の範囲であったことを表しています。図3-2は、サイト間の遅延が77ミリ秒の場合に平均トランザクション・リカバリ時間が90から100ミリ秒の範囲であったことを表しています。
遅延が増加するに伴って、クロスサイト・トランザクション・リカバリ・パラメータのCrossSiteRecoveryLeaseExpiration、CrossSiteRecoveryRetryIntervalおよびCrossSiteRecoveryLeaseUpdateを増やして遅延にあわせる必要があります。クロスサイト・トランザクション・リカバリのリース表が維持されているデータベースがサイトの1つに対してリモートである場合、これらの値のチューニングが特に重要です。「クロスサイトXAトランザクション・リカバリ」を参照してください。
表3-2は、アクティブ/アクティブ・アプリケーション層トポロジに対する異なる障害シナリオのそれぞれでContinuous Availabilityの機能がどのように使用されているかを説明しています。
表3-2 アクティブ/アクティブ・アプリケーション層およびアクティブ/パッシブ・データベース層の障害シナリオ
| 継続的可用性の機能 | 完全サイト障害 | 部分サイト/中間層障害(WebLogic Server/Coherence/OTD) | メンテナンス機能停止 | ネットワークの分断障害 |
|---|---|---|---|---|
サイト間のトランザクション・リカバリ |
|
プライマリ・サイトのリース表が期限切れになった場合、サイト2のサーバーが自動的にTLog表の所有権をとり、トランザクション・リカバリを開始します。 |
|
|
Oracle Traffic Director |
サイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。 |
サイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。 |
|
サイト1のOracle Traffic Directorおよびサイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。 |
Oracle Site Guard |
Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがデータベース内のロールをプライマリからセカンダリに切り替えます。 |
何もしません。 |
|
何もしません。 |
Coherenceフェデレーテッド・キャッシュ |
サイト2のCoherenceクラスタがアクティブになります。 |
レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。 |
レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。 |
レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはネットワーク接続が2つのサイト間で再確立されたときに整合します。 |
一般的な設計に関する考慮事項および推奨事項に説明されているようにすべての継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層に示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。
アクティブ/パッシブ・トポロジで継続的可用性の機能を最大限に利用するには、次を考慮してください。
すべてのアクティブ/パッシブ・ドメインのペアは対称的トポロジで構成する必要があります。これらは同等であり、同じドメイン構成(ディレクトリの名前およびパス、ポート番号、ユーザー・アカウント、ロード・バランサおよび仮想サーバー名など)と同じソフトウェア・バージョンを使用する必要があります。ホスト名(静的IPではない)は、管理対象サーバーのリスニング・アドレスの指定に使用する必要があります。サイト間でホスト名は同一で(IPは同一ではない)、同じように構成されたサーバーまたはドメインをリカバリ・サイトで単純に開始する動的な機能がホスト名により提供されます。
このトポロジで遅延に関する考慮事項はありません。唯一の要件は、JMSおよびJTA TLogなどのストアがデータベースに維持されることです。
パッシブ・モードでWebLogic Serverのサーバーは構成されますが、稼働していません。障害がある場合、パッシブ・サイトのWebLogic Serverのサーバーが起動され、JTAおよびJMSのトランザクション/メッセージがリカバリされてセカンド・サイトで作業が実行されます。
JMSはこのトポロジでサポートされています。パッシブ・サイトはプライマリ・サイトのドメインの正確なコピーを含む必要があります。これにより、JMSのサーバー、ストアおよび宛先が同じことが保証されます。
フェイルオーバーまたはスイッチオーバーの場合、ストアまたはJMSサーバー(あるいはその両方)がクラスタをターゲットとしている場合は同数のサーバーをクラスタで起動する必要があります。これは、JMSサーバー+ストア+宛先のそれぞれが、実行していたサーバーに固有のものであるためです。MyServer1およびMyServer2がプライマリ・ドメインにある場合、そのそれぞれにJMSサーバー+ストアを持ち、これらの各サーバー上にメッセージがある場合があります。1つのサーバーのみを再起動すると、リカバリされるのはその1つのサーバーに対するメッセージのみです。
スタンバイ・ドメインは、レプリケーション・フェーズ中は実行できず、最初のデータ・センターの停止が確認された後にのみ起動する必要があります。このプロセスは、データの破損を防いでリカバリを強制するために必要です。2つのJMSサーバー/ストアがまったく同じデータを書込み/更新している場合、予期できない結果が発生します。また、メッセージ・リカバリはJMSの起動時にのみ発生します。その際、JMSサーバーはストアの完全な内容を読み取って宛先状態を再作成します。
非同期レプリケーションは喪失メッセージ(メッセージがプライマリ・データ・センターに書き込まれたがコピーされていない)または重複メッセージ(メッセージがプライマリ・データ・センターで消費/削除されたがレプリケートされたデータ・センターに残っている)になる可能性があります。
詳細は、『ディザスタ・リカバリ・ガイド』のOracle WebLogic Server Java Message Service (JMS)およびトランザクション・ログ(TLog)の推奨事項に関する項を参照してください。
ゼロ・ダウンタイム・パッチ適用は、お使いのWebLogicホーム、Javaおよびアプリケーションをアクティブなサイトでローリング方式でアップグレードします。計画済メンテナンスおよびパッシブ・サイトへのスイッチオーバー中、およびサーバーの起動後に、ゼロ・ダウンタイム・パッチ適用を使用してWebLogic、Javaまたはアプリケーションをアップグレードします。アップグレード・バージョンを両方のサイトで同期状態に維持し、両方のサイトのドメインを対称に維持します。
アクティブ/パッシブ・トポロジでは、Coherenceはスタンバイ・モードにあり、WebLogic Serverのようなパッシブ・モードではありません。スタンバイ・サイトにはアクティブなサイトからのキャッシュ・データのバックアップがあります。Coherenceフェデレーテッド・キャッシュをアクティブ/パッシブ・モードで使用すると、このレプリケーションは非同期ですが絶えず発生します。
このトポロジでは、Oracle Site Guardを使用してすべてのサイト・コンポーネント(Oracle Traffic Director、WebTier、WebLogic Server、Coherenceおよびデータベース)のフェイルオーバー/スイッチオーバーを編成することをお薦めします。
表3-3は、アクティブ/パッシブ・アプリケーション層トポロジに対する異なる障害シナリオのそれぞれでContinuous Availabilityの機能がどのように使用されているかを説明しています。
表3-3 アクティブ/パッシブ・アプリケーション層およびアクティブ/パッシブ・データベース層の障害シナリオ
| 継続的可用性の機能 | 完全サイト障害 | 部分サイト/中間層障害(WebLogic Server/Coherence/OTD) | メンテナンス機能停止 | ネットワークの分断障害 |
|---|---|---|---|---|
サイト間のトランザクション・リカバリ |
|
|
|
何もしません。 |
Oracle Traffic Director |
スタンバイ・サイトのOracle Traffic Directorインスタンスが、(Oracle Site Guardによって、何がどのような順序で発生するかを指定するスクリプトを使用して)アクティブ化されます。(スクリプトはフェイルオーバーの前または後に実行できます。) |
|
スタンバイ・サイトのOracle Traffic Directorインスタンスが、(Oracle Site Guardによって、何がどのような順序で発生するかを指定するスクリプトを使用して)アクティブ化されます。(スクリプトはフェイルオーバーの前または後に実行できます。) |
何もしません。 |
Oracle Site Guard |
Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがロールをプライマリからセカンダリに切り替えます。 |
Oracle Site Guardは中間層でのみフェイルオーバーします。 |
|
何もしません。 |
Coherenceフェデレーテッド・キャッシュ |
サイト2のCoherenceクラスタがアクティブになります。キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して整合します。 |
サイト2のCoherenceクラスタがアクティブになります。キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはリモート・サイトが稼働状態に戻ったときに整合します。 |
サイト2のCoherenceクラスタがアクティブになります。キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはリモート・サイトが稼働状態に戻ったときに整合します。 |
キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはネットワーク接続が2つのサイト間で再確立されたときに整合します。 |
一般的な設計に関する考慮事項および推奨事項に説明されているようにすべての継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタに示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。
アクティブ/アクティブ・ストレッチ・クラスタで継続的可用性の機能を最大限に利用するには、次を考慮してください。
マルチデータ・センターでは、アクティブ/アクティブ・ストレッチ・クラスタ環境のデータ・センター間のセッション・レプリケーションによってシステムで重大なパフォーマンス低下が引き起こされることがあります。異なる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はデータベースのフェイルオーバー/スイッチオーバーのみを実行できます。
表3-4は、ストレッチ・クラスタ・トポロジでのデータベース・リースに構成する必要があるお薦めの設定のリストを表示しています。詳細は、Oracle WebLogic Server MBeanリファレンスのMBeanに関する次の説明を参照してください。
表3-4 ストレッチ・クラスタでのデータベース・リースにお薦めする設定
| 構成プロパティ | MBean/コマンド | 説明 | お薦めする設定 |
|---|---|---|---|
DatabaseLeasingBasisConnectionRetryCount |
ClusterMBean |
データベース・リースがデータソースから有効な接続を取得するための最大試行回数。 |
5 (デフォルト値は1 |
DatabaseLeasingBasisConnectionRetryDelay |
ClusterMBean |
接続が失敗したときに、データベース・リースがデータソースから新規接続の取得を試行する前に待機する時間の長さ(ミリ秒)。 |
2000 (デフォルト値は1000です) |
TestConnectionOnReserve |
JDBCConnectionPoolParamsBean |
接続をクライアントに渡す前にWebLogic Serverでテストできるようにします。 |
有効。データソースのリース用。サーバーはスイッチオーバー中は稼働状態のままです。 |
-Dweblogic.cluster.jta.SingletonMasterRetryCount |
サーバーの起動コマンド |
シングルトン・マスターが選択されてそのリスニング・ポートをオープンするための試行カウントを指定します。シングルトン・マスターは、JTAを非アクティブ化する最初の試行時にすぐに使用可能にならない場合があります。 |
4 (デフォルト値は20です) DatabaseLeasingBasisConnectionRetryCountが5に設定されているため、このプロパティは4に減らせます。この設定はデータベース・サーバーのブート中の時間コストを減らせます。 |
図3-3および図3-4は、ベンチマーク・テスト中に見つかった、異なる遅延に対するシステム全体のスループット(両方のサイトは一緒に稼働しています)で見られる低下を示す結果を表しています。図3-3は、約20ミリ秒のラウンド・トリップ時間(RTT)の遅延中にスループットが25%程度低下することを表しています。図3-4は、アプリケーションをデプロイするためにかかる時間の増加(同じサイトのすべてのサーバーおよびデータベースのデプロイメントと比較した場合)を表しています。
多くのテストで見られる提供データとパフォーマンスのペナルティを考慮して、アクティブ/アクティブ・ストレッチ・クラスタ・トポロジで遅延が2つのサイト間の通信に影響を及ぼす場合は10ミリ秒の遅延(RTT)を超えないことをお薦めします。
表3-5は、アクティブ/アクティブ・ストレッチ・クラスタ・トポロジに対する異なる障害シナリオのそれぞれでContinuous Availabilityの機能がどのように使用されているかを説明しています。
表3-5 アクティブ/アクティブ・ストレッチ・クラスタおよびアクティブ/パッシブ・データベース層の障害シナリオ
| 継続的可用性の機能 | 完全サイト障害 | 部分サイト/中間層障害(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つのサイト間で再確立されたときに整合します。 |
