| Oracle® Fusion Middleware Oracle WebLogic Serverのための継続的可用性 12c (12.2.1) E70050-01 |
|
 前 |
 次 |
Oracle WebLogic Server Continuous Availabilityは、地理的に分散した場所にまたがってデータ・センターを展開する、最大可用性アーキテクチャを構築するための統合ソリューションを提供します。この章では、継続的可用性とその主機能の概要について説明します。
内容は次のとおりです。
継続的可用性とは、必要時にアプリケーションを必ず使用できるように、高可用性および障害時リカバリの両ソリューションを採用することで最大限の可用性を提供するシステムの機能です。一般的に、高可用性ソリューションは1つのデータ・センターにおける冗長性を提供します。障害時リカバリ・ソリューションは、自然災害などによる計画外の本番サイトの機能停止に対する防護機能を提供します。アプリケーションとデータを地理的に離れたスタンバイ・サイトに置くリカバリ戦略を使用します。
Oracle WebLogic Server Continuous Availabilityは、地理的に分散した場所にまたがってデータ・センターを展開する、最大可用性アーキテクチャ(MAA)を構築するための統合ソリューションを提供します。統合されたコンポーネントにはOracle WebLogic Server、Oracle Coherence、Oracle Traffic DirectorおよびOracle SiteGuardが含まれます。この統合ソリューションの主な利点は迅速なフェイルオーバーまたはスイッチオーバー、アプリケーション全体の可用性の向上、データの整合性、人的エラーおよびリスクの軽減、作業のリカバリ、およびリアルタイム・データのローカル・アクセスです。
継続的可用性の主な機能について、次の項で説明します。このドキュメントで使用される共通用語については、「継続的可用性の用語」で説明します。
継続的可用性は計画的アップグレードや予期せぬ障害の際に、最大限の可用性、信頼性およびアプリケーションの安定性を提供します。これはOracle WebLogic Server、Oracle CoherenceおよびOracle Fusion Middlewareの既存の高可用性機能の上に構築され、次の項で説明する主な機能をサポートしています。
自動クロスドメイン・トランザクション・リカバリは、ドメイン全体、あるいは別ドメインまたは別サイトで実行中のサーバーを備えるサイト全体における、XAトランザクションの自動リカバリを提供します。アクティブ/アクティブ・アーキテクチャでは、同一サイトまたは別サイトのいずれかに配置された別ドメインでアクティブ・サーバーを稼働することで、ドメイン全体またはサイト全体の障害発生時にトランザクションをリカバリできます。アクティブ/パッシブ・アーキテクチャでは、別の場所にあるパッシブ(スタンバイ)・サイトのサーバーを、本番サイトが使用できないときに起動できます。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』の複数サイトまたはデータ・センターにまたがるトランザクション・リカバリに関する項を参照してください。
自動クロスドメイン・トランザクション・リカバリは、「WebLogic Serverの高可用性トランザクションおよびデータ・ソース機能」で説明されているWebLogic Serverの高可用性機能も活用します。
WebLogic Serverゼロ・ダウンタイム・パッチ適用は、停止時間またはセッションの消失を回避しながら、パッチの公開を編成するための自動メカニズムを提供します。これによって、パッチの適用中に可用性および予測性が求められる重要なアプリケーションのリスクと停止時間が軽減されます。
定義したワークフローを使用することで、手動操作をほとんど行わずにドメイン内の任意の数のノードをパッチ適用または更新することができます。変更は1回に1ノードに対して公開されるため、ノードが更新されるまでOracle Traffic Directorなどのロード・バランサが受信トラフィックを残りのノードにリダイレクトできます。
詳細は、『ゼロ・ダウンタイム・パッチ適用ワークフローの管理』を参照してください。
WebLogic Serverマルチテナント環境では、アプリケーション・ユーザーに影響を及ぼさずに、あるクラスタ/サーバーからドメイン内の別のクラスタ/サーバーへ実行中のパーティション・リソース・グループを移行できます。リソース・グループを移行する主な利点は、計画的イベントのアプリケーション停止時間が排除されることです。
リソース・グループは、(通常は)デプロイ可能な関連リソースのコレクションです(たとえば、Java EEアプリケーションとそのデータ・リソース、JMSアーティファクト、およびアプリケーションが使用する他のリソースなどです)。リソース・グループを移行する場合、リソース・グループが使用している仮想ターゲットを、ある物理ターゲット(クラスタ/サーバー)から別の物理ターゲットに変更します。移行後、仮想ターゲットは新しい物理ターゲット(クラスタ/サーバー)を参照します。
リソース・グループおよび移行の詳細は、『WebLogic Server MTの使用』の次の項を参照してください。
リソース・グループの構成
リソース・グループの移行: 主な手順とWLSTの例
Oracle Coherenceフェデレーテッド・キャッシュ機能は、複数の地理的に分散したクラスタにまたがってキャッシュ・データを非同期にレプリケートします。アクティブ/アクティブ、アクティブ/パッシブ、ハブ/スポークおよびセントラル/レプリケーションなどの多彩なレプリケーション・トポロジがサポートされています。キャッシュされたデータがクラスタ間でレプリケートされることで冗長性、オフサイト・バックアップ、および地理的に異なる場所にいるアプリケーション・ユーザーに対する複数アクセス・ポイントが提供されます。
フェデレーテッド・キャッシュでは多彩なレプリケーション・テクノロジがサポートされています。これには次のものがあります。
アクティブ/パッシブ - アクティブ・クラスタからパッシブ・クラスタへデータをレプリケートします。パッシブ・サイトは読取り専用操作とオフサイト・バックアップをサポートしています。
アクティブ/アクティブ - アクティブ・クラスタ間でデータをレプリケートします。あるアクティブ・クラスタ内に配置されるデータは、別のアクティブ・クラスタでレプリケートされます。異なるサイトにあるアプリケーションはローカル・クラスタ・インスタンスへのアクセスを保有します。
ハブ・アンド・スポーク - 単一ハブ・クラスタから複数のスポーク・クラスタへデータをレプリケートします。ハブ・クラスタはデータの送信のみ可能で、スポーク・クラスタはデータの受信のみ可能です。このトポロジには複数の地理的に分散したクラスタのコピーが必要です。各スポーク・クラスタは読取り専用を実行するためにローカル・アプリケーションで使用できます。
フェデレーテッド・キャッシュの詳細は、『Oracle Coherenceの管理』のクラスタ間のキャッシュのレプリケートに関する項を参照してください。
Oracle Coherence GoldenGate HotCache機能は、リアルタイムでキャッシュ内のデータベース変更を検出して反映します。データベースに対するサード・パーティの更新により、Coherenceアプリケーションで、最新でない失効した可能性のあるデータが使用されることがあります。Coherence GoldenGate HotCacheは、リアルタイムでデータベースをモニタリングし、変更をCoherenceキャッシュにプッシュすることでこの問題を解決します。これには、失効したデータのみを処理する効率的なプッシュ・モデルが採用されています。データベースに変更が行われる際にデータがプッシュされるため、待機時間の短さが保証されます。
最大可用性アーキテクチャでは、フェイルオーバー中にデータベースが二次サイトにレプリケートされると、GoldenGate HotCacheを使用してデータベース変更がキャッシュに反映されます。
詳細は、Oracle Coherenceの統合のOracle Coherence GoldenGate HotCacheとの統合に関する項を参照してください。
Oracle Traffic Directorは、ネットワーク上のアプリケーション・サーバーおよびWebサーバーへのHTTP、HTTPSおよびTCPトラフィックをルーティングする、高速かつ信頼性および拡張性の高いソフトウェア・ロード・バランサです。クライアントから受信したリクエストの、指定されたロード・バランシング・メソッドに基づく使用可能サーバーへの分散、指定されたルールに基づくリクエストのルーティング、頻繁にアクセスされるデータのキャッシュ、トラフィックの優先付け、およびサービス品質の制御を行います。
Oracle Traffic Directorのアーキテクチャでは、大量のアプリケーション・トラフィックを低遅延で処理できます。高可用性を図るために、アクティブ/パッシブまたはアクティブ/アクティブのいずれかのフェイルオーバーに対するOracle Traffic Directorインスタンスのペアを設定できます。ネットワークのへのトラフィック量の増大に伴い、リクエストのルーティング先となるバックエンド・サーバーを追加してOracle Traffic Directorを再構成することで、環境を簡単に拡張できます。
詳細は、『Oracle Traffic Directorの管理』を参照してください。
Oracle Enterprise Manager Cloud ControlのコンポーネントであるOracle Site Guardは障害時リカバリ・ソリューションであり、管理者はサイトの完全なスイッチオーバーやフェイルオーバーを自動化することでエンタープライズ・デプロイメントの停止時間を最小限に抑えることができます。Oracle Site Guardはサイト・レベルで動作するので、アプリケーション、ミドルウェアおよびデータベースなどの個々のサイト・コンポーネントに対して面倒な障害時リカバリを手動で実行する必要がなくなります。本番サイト全体のトラフィックは、単一の操作でスタンバイ・サイトにリダイレクトできます。
管理者には、データベース、アプリケーションおよびストレージ・レプリケーションなどの領域での特別な知識またはドメインの専門知識は不要です。Oracle Site Guardを使用することにより、本番サイトに影響を与えることなく、障害時リカバリの準備状況を継続してモニターできます。
Oracle Site Guard構成は、Enterprise Managerコマンド行インタフェース(EMCLI)または互換バージョンのOracle Enterprise Manager Cloud Control (Cloud Control)のいずれかを使用して管理できます。
Oracle Site Guardの詳細は、Site Guard管理者ガイドを参照してください。
「継続的可用性の主な機能」で説明した機能以外に、次の項で説明するように、Oracle Continuous AvailabilityはWebLogic ServerおよびCoherenceに付属する高可用性機能も活用します。
次の高可用性トランザクションおよびデータ・ソース機能を、継続的可用性のための自動クロスドメイン・トランザクション・リカバリで使用できます。
Oracle RACノードの迅速な障害検出と、継続的接続のための残りノードへのフェイルオーバーを提供するために高速接続フェイルオーバーを使用するActive GridLinkデータ・ソース。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のActive GridLinkデータ・ソースの使用に関する項を参照してください。
サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納する、データベース内のトランザクション・ログ(JDBC Tlog)。WebLogic Serverでは、システムのクラッシュやネットワーク障害からのリカバリ時にTLogが使用されます。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のトランザクション・ログ・ファイルを使用したトランザクションのリカバリに関する項を参照してください。
TLogストアへのトランザクション・チェックポイントの書込みをなくす、トランザクションTLog書込みなし(No TLOG)。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のトランザクションTLog書込みなしのXAトランザクションに関する項を参照してください。
1つの非XAリソースがXAと同じACID(原子性、整合性、分離性、耐久性)保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のためのオプションである、ロギング・ラスト・リソース(LLR)によるトランザクションの最適化。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のロギング・ラスト・リソース・トランザクションの最適化に関する項を参照してください。
これらの機能はデータベースをレプリケートするOracle Data Guardと連携して、リカバリに必要なトランザクション・ログの可用性を高めます。Oracle Data Guardの詳細は、Data Guard概要および管理を参照してください。
Coherence永続性は、Coherence分散キャッシュの永続性およびリカバリを管理する、一連のツールおよびテクノロジです。致命的障害や、計画的メンテナンスによるクラスタ再起動の後に迅速なリカバリができるように、キャッシュされたデータは保持されます。永続性とフェデレーテッド・キャッシュは必要に応じて共に使用できます。Coherence永続性の詳細は、『Oracle Coherenceの管理』のキャッシュの保持に関する項を参照してください。
Coherenceクラスタは、アプリケーションのスケーラビリティ、可用性およびパフォーマンスを向上させるためにデータをメモリー内に分散する、複数のCoherenceサーバー・インスタンスで構成されています。アプリケーション・データは自動的かつ透過的に分散され、クラスタ・メンバーをまたがってバックアップされます。Coherenceクラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』のCoherenceクラスタの構成および管理に関する項を参照してください。
Oracle Continuous AvailabilityはOracle Data Guard、Oracle Data Guard BrokerおよびOracle Clusterwareを使用して、既存のデータベース・フェイルオーバーおよびスイッチオーバー機能も利用します。これらのコンポーネントはすべて、次のようにOracle Databaseのフェイルオーバーおよびスイッチオーバーの管理および編成に機能します。
Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。1つ以上のスタンバイ・データベースを作成、維持、管理、モニターして、本番のOracleデータベースが障害やデータ破損に耐えられるようにするための包括的なサービス・セットが用意されています。Oracle Data Guardでは、これらのスタンバイ・データベースが、トランザクション的に一貫性のあるプライマリ・データベースのコピーとして維持されます。計画的または計画外の障害によりプライマリ・データベースが使用できなくなると、Oracle Data Guardは任意のスタンバイ・データベースを本番ロールに切り替えることができるため、障害に関連する停止時間が最短に抑えられます。
Oracle Data Guard Brokerでは、これらのプライマリ・データベースとスタンバイ・データベースを統合ユニットとしてまとめて管理およびモニターできるようにブローカ構成として論理的にグループ化されます。これによって通知がWebLogic Active GridLinkに送信されると、そこでフェイルオーバー・サイトのデータベースへの新規接続が行われ、Oracle Clusterwareと連携してロールベース・サービスがフェイルオーバーされます。
Oracle Clusterwareは、Oracle RACデータベースのインスタンスの可用性を管理します。プライマリ・データベースを使用可能な状態に保つために、障害が発生したインスタンスを迅速にリカバリしようとします。障害が発生したインスタンスをOracle Clusterwareがリカバリできない場合、ブローカは自動的に1つ少なくなったインスタンスで引き続き動作します。プライマリ・データベースの最後のインスタンスに障害が発生すると、ブローカは指定されたスタンバイ・データベースにフェイルオーバーする手段を提供します。プライマリ・データベースの最後のインスタンスに障害が発生し、ファスト・スタート・フェイルオーバーが有効化されている場合は、事前決定済のスタンバイ・データベースへのフェイルオーバーが自動的に実行され、継続的な高可用性を提供できます。
Oracle Site Guardは、Data Guard Brokerを使用してデータベースのフェイルオーバー/スイッチオーバーを実行します。これらの全製品の統合によって、高速かつ自動的なデータベースのフェイルオーバーが実現します。
次のリストで、継続的可用性に適用される共通用語について説明します。
アクティブ/アクティブ - アクティブ/アクティブ・ソリューションは、複数のアクティブなサーバーをデプロイすることで、スケーラビリティを向上して高可用性を提供します。アクティブ/アクティブ・デプロイでは、すべてのインスタンスは、同時にリクエストを処理します。ドメイン全体またはサイト全体に障害が発生するとき、同一サイトまたは別サイトのいずれかに配置された別ドメイン内のアクティブ・サーバーによってトランザクションをリカバリできます。
アクティブ/パッシブ - アクティブ/パッシブ・ソリューションには、アクティブな(本番)サイトとは地理的に異なる位置で、スタンバイ・サイトを設定してペアにする作業が含まれます。スタンバイ・サイトは本番サイトと比較して、サービスやリソースの数が同じか下回る場合があります。アプリケーション・データ、メタデータ、構成データおよびセキュリティ・データが、定期的にスタンバイ・サイトにレプリケートされます。通常の場合、スタンバイ・サイトはパッシブ・モードであり、本番サイトが使用できないときに起動されます。通常、このモデルは、2つのサイトがWAN経由で接続されていて、ネットワーク待機時間の関係で2つのサイトにまたがるクラスタリングができない場合に採用されます。
WebLogic Serverクラスタ - 同時に動作し、連携して高度なスケーラビリティと信頼性を実現するWebLogic Serverサーバー・インスタンスの集合。クラスタでは、管理対象サーバーごとに、ほとんどのリソースおよびサービスがまったく同じようにデプロイされるため、フェイルオーバーとロード・バランシングが可能になります。
Coherenceクラスタ - Coherenceを実行する、Coherenceサーバーと呼ばれるJVMプロセスの集合。Coherenceクラスタは、アプリケーションのスケーラビリティ、可用性およびパフォーマンスを向上させるためにデータをメモリー内に分散する、複数のCoherenceサーバー・インスタンスで構成されています。アプリケーション・データは自動的かつ透過的に分散され、クラスタ・メンバーをまたがってバックアップされます。
ストレッチ・クラスタ - 地理的に近い範囲内でノードがデータ・センターを拡張できるクラスタのことで、通常はサイト間の比較的に低遅延のネットワーキングが保証されています。ストレッチ・クラスタは、拡張クラスタとも呼ばれています。
高可用性 - 必要なシステムまたはデバイスに対して、常にアクセス可能な状態を維持する能力。高可用性アーキテクチャにより、サービスを中断することなく、ユーザーはシステムにアクセスできます。高可用性システムをデプロイすることで、システムの停止時間つまり使用不可の時間が最小化され、システムの稼働時間つまり使用可能な時間が最大化されます。
障害時リカバリ - 自然災害などによる計画外の本番サイトの機能停止に対する防護機能。アプリケーションとデータを地理的に離れたスタンバイ・サイトに置くリカバリ戦略を使用します。
スイッチオーバー - 本番サイトとスタンバイ・サイトの役割を逆転するプロセス。スイッチオーバーは、定期的な検証のために行う、または現在の本番サイトで計画メンテナンスを実行するための計画済の操作です。スイッチオーバー中に、現在のスタンバイ・サイトが新しい本番サイトになり、現在の本番サイトが新しいスタンバイ・サイトになります。
フェイルオーバー - (本番サイトの災害などが原因で)本番サイトが予期せず使用できなくなった後、現在のスタンバイ・サイトを新しい本番サイトにするプロセス。
