この章の推奨事項は、継続可用性をサポートするすべてのMAAアーキテクチャに適用されます。特定のアーキテクチャ固有の推奨事項は、後続の章で説明します。
この章の内容は次のとおりです:
潜在的な障害シナリオには、予想外のサイト全体またはサイトの一部の障害からメンテナンス機能停止まで含まれます。
このドキュメントで説明されている設計に関する考慮事項および推奨事項は、次の潜在的障害シナリオに適用されます。
完全サイト障害 - 完全サイト障害では、本番環境の負荷に対応するよう準備されたセカンダリ・サイトにデータベース、中間層アプリケーション・サーバーおよびすべてのユーザー接続をフェイルオーバーします。
部分サイト障害 - このドキュメントの文脈では、部分障害は中間層で発生します。中間層での部分サイト障害は、中間層全体(WebLogic ServerおよびCoherence)、WebLogic Serverのみの障害、Coherenceクラスタ障害、またはOracle Traffic Directorで2つのインスタンスに高可用性が構成されているときの一方のインスタンス内の障害から構成されることがあります。
ネットワークの分断 - サイト間の通信が失敗します。
メンテナンス機能停止 - 計画済メンテナンス中にサイトのすべてのコンポーネントが段階的に停止されます。スイッチオーバーがサイトからサイトへと実行されます。
異なる障害シナリオにおける継続的可用性の機能の動作を次の項で説明します。
プライマリサイト障害の場合に、スタンバイ・サイトが本番ロールをとった後、グローバル・ロード・バランサがユーザー・リクエストをスタンバイ・サイトへ再ルーテイングするために使用されます。F5 –BigIP Global Traffic Manager (GTM)およびCisco –Global Site Selector (GSS)などのグローバル・ロード・バランサは、(解決プロセスを従来型のDNSサーバーからオフロードすることで)DNSサーバー解決も処理します。
通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、スタンバイ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだスタンバイ・サイトにリクエストが送信されるようになります。
DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバー(計画済)およびフェイルオーバー(計画外)として機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。DNSスイッチオーバーの実行手順は、ディザスタ・リカバリ・ガイドのDNS名の手動変更を参照してください。
2つのOracle Traffic Directorインスタンスが高可用性を提供するために仮想IPアドレス(VIP)でグループ化されている場合、アクティブ/パッシブ・フェイルオーバー・モードになります。VIPはリクエストを受信して、プライマリ・インスタンスと指定されているOracle Traffic Directorインスタンスにルーティングします。プライマリ・インスタンスに到達できない場合、リクエストはバックアップ・インスタンスにルーティングされます。
アクティブ/アクティブ・フェイルオーバー・モードには、2つのフェイルオーバー・グループが必要です。各フェイルオーバー・グループは一意のVIPを持つ必要があり、それぞれプライマリ・ロールとバックアップ・ロールが逆となる同じノードで構成されています。フェイルオーバー・グループ内の各インスタンスは、プライマリ・インスタンスおよびバックアップとして指定され、それぞれにVIPが1つずつ割り当てられます。『Oracle Traffic Directorの管理』の「高可用性を提供するための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プロキシ・プラグインの詳細は次を参照してください。
クラスタリング、シングルトン・サービス、セッション・レプリケーション、その他のWebLogic Server機能は、継続的可用性の機能と組み合せて使用し、最高レベルの可用性を達成できます。
継続的可用性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およびトランザクション・データの重要度によります。これは、共有ストレージが提供する保護のレベルがデータベースが保証するよりはるかに低いためです。
(Oracle Databaseパーティショニングが使用できる場合)索引にグローバル・ハッシュ・パーティションなどのテクニックを使用することで、データベース・ストアのパフォーマンスの影響を、特に並行性が大きい場合に最小限にとどめることができます。パフォーマンスへの影響を最小限にすることに関する推奨事項については、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のエンタープライズ・デプロイメントでのTLOGおよび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形式を参照してください。
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秒(デフォルト) |
フェデレーテッド・キャッシュ、永続性およびGoldenGate Hot CacheなどのCoherence機能は、継続的可用性の機能と組み合せて使用し、最高レベルの可用性を達成できます。
継続的可用性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 RAC。
ミッション・クリティカルなOracle Databaseに対する単一点障害を排除するOracle Data Guard。これは、リモートの場所に同期化された本番データベースの物理レプリカを維持することによって、データ損失および停止時間を防止します。本番データベースがどのような理由で使用不可になっている場合でも、クライアント接続が短時間で、また一部の構成では透過的に、同期されたレプリカにフェイルオーバーされてサービスを回復します。アプリケーションは、わずかな変更または変更なしでOracle Data Guardを利用できます。
WebLogic Serverの継続的可用性のMAAアーキテクチャでは、Oracle Data Guardの最大限の可用性の保護モードを使用することをお薦めします。この保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します。特定の二重障害の場合(スタンバイ・データベースの障害が発生した後にプライマリ・データベースの障害が発生した場合など)を除いて、データ消失がないことを保証します。『Oracle Data Guard概要および管理』の「Oracle Data Guardの保護モード」を参照してください。
注意:
Oracle Data Guardはアクティブ/パッシブ構成でのみ使用できますが、ゼロデータ損失が保証されます。
Oracle Active Data Guardは、Oracle Data Guardのインフラストラクチャの組込みオプションで、プライマリ・データベースから変更が適用されている間も、フィジカル・スタンバイ・データベースを読取り専用で開くことができます。これにより、読取り専用アプリケーションは、プライマリ・データベースで非常に大きいトランザクション・ボリュームの処理中であっても、スタンバイ・データベースとプライマリ・データベース上のデータ間での遅延を最小限に抑えながら、フィジカル・スタンバイを使用できます。これはリアルタイム問合せと呼ばれることもあります。
Oracle Active Data Guardスタンバイ・データベースは、アプリケーションに透過的に、プライマリ・データベースにより検出されたデータ破損の自動修復に使用されます。プライマリ・データベースでの計画外停止の場合も、スタンバイ・データベースへの迅速なフェイルオーバーにより高可用性が保たれます。Active Data Guardスタンバイ・データベースは、プライマリ・データベースのブロック対ブロックのフィジカル・レプリカであるため、特定のプライマリ・データベースから高速増分バックアップをオフロードすることもできます。
Oracle Active Data Guardには、ゼロ・データ損失構成でパフォーマンスを向上する遠隔同期機能があります。 Oracle Data Guard遠隔同期インスタンスは、プライマリ・データベースからREDOを受け取り、それをOracle Data Guard構成の他のメンバーに送信する、リモートのOracle Data Guardの宛先です。スタンバイ・データベースとは異なり、遠隔同期インスタンスにはデータ・ファイルがなく、オープンすることもできず、受け取ったREDOを適用することもできません。これらの制限のために、ディスクと処理リソースの使用量が少なくなる利点があります。より重要なこととして、遠隔同期インスタンスは、同期転送モードを使用してREDOデータを受け取り、構成保護モードが最大可用性に設定されている場合、データ損失なしでターミナル・データベースにフェイルオーバーすることができます。『Oracle Data Guard概要および管理』の「遠隔同期」を参照してください。
Oracle Data Guardブローカは、Data Guard構成の作成、メンテナンス、監視を自動化および集中化する分散管理フレームワークです。Data Guard Brokerが実行できる操作の一部として、Data Guard構成の作成、管理、監視、構成内のすべてのデータベースにわたる複雑なロール変更を開始および制御するためのスイッチオーバーまたはフェイルオーバーの起動、およびフェイルオーバーを自動発生させるための構成があります。
プライマリ・データベースが使用できなくなった場合に、Oracle Data Guardのファスト・スタート・フェイルオーバーを有効化して、すぐにフェイルオーバーを自動的に行うことができます。ファスト・スタート・フェイルオーバーが有効化されている場合、Oracle Data Guardブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。データベース管理者による操作は不要です。『Oracle Data Guard Broker』のファスト・スタート・フェイルオーバーの管理に関する項を参照してください。
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の管理』の「アクティブ/アクティブ型高可用性のための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をサイト間でのスイッチオーバーおよびフェイルオーバーのために構成する方法の詳細は、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を使用した障害時リカバリの自動化ホワイト・ペーパーを参照してください。