高可用性の概要

2 高可用性の概要

高可用性には、ロード・バランシング、フェイルオーバー、Real Application Clustersおよびプロファイル(設定)などの要素が関連します。

Oracle Fusion Middlewareの概念
スケール・アウトを行う前に、重要な概念について理解してください。
高可用性環境でのサーバーのロード・バランシング
一般的に、ロード・バランサは、高可用性デプロイメントのフロントエンド処理を行います。
アプリケーション・フェイルオーバー
フェイルオーバーとアプリケーション動作には、様々な種類があります。
Real Application Clusters
Oracle Real Application Clusters (RAC)を使用すると、Oracle Databaseのクラスタを構成できます。クラスタは、相互に接続された複数のコンピュータまたはサーバーで構成され、エンド・ユーザーおよびアプリケーションからは1つのサーバーとして認識されます。
Coherenceクラスタと高可用性
各標準インストール・トポロジ(SIT)には、標準のCoherenceクラスタが含まれています。このクラスタは、追加構成の開始点になります。
障害時リカバリ
可用性を最大限に高めるために、地理的に離れた複数の場所にサービスをデプロイして、予期せぬ障害や自然災害によるサイト全体の障害に備えることが必要な場合があります。
インストール時の構成(プロファイル)
SITを構成する際に考慮する必要があるドメイン、ファイルおよびデータベースベースのプロファイル・タイプがあります。
JMSおよびJTAのアプリケーションおよびサービス・フェイルオーバー
WebLogic Serverにおける移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスのことです。
高可用性トポロジの設定ステップ
高可用性トポロジのサンプルを設定するための特定の順序に従って、インストールと構成ステップを完了することをお薦めします。

Oracle Fusion Middlewareの概念

スケール・アウトを行う前に、重要な概念について理解してください。

表2-1は、Oracle Fusion Middleware Oracle Fusion Middlewareコンセプトの理解の関連するトピックを示します。

表2-1 Oracle Fusion Middlewareの概要

情報	参照先
Oracleホーム、Oracle Common、WebLogic Serverドメイン	Oracle Fusion Middlewareの主要ディレクトリとは
WebLogic Serverドメイン	Oracle WebLogic Serverドメインとは
管理サーバー	管理サーバーとは
管理対象サーバーおよびクラスタ	管理対象サーバーおよび管理対象サーバー・クラスタの理解
ノード・マネージャ	ノード・マネージャとは

注意:

『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』のクラスタ内での通信に関する項を参照してください

親トピック: 高可用性の概要

高可用性環境でのサーバーのロード・バランシング

一般的に、ロード・バランサは、高可用性デプロイメントのフロントエンド処理を行います。

ロード・バランシングについて
ロード・バランシングとは、環境内のコンピューティングおよびネットワーキング・リソース全体において、ジョブとそれに関係する通信を均等に分散することです。
サード・パーティ製のロード・バランサの要件
特定の機能を持ったサード・パーティ製のロード・バランサであれば、高可用性デプロイメント内で使用できます。
サード・パーティ製のロード・バランサの構成
ロード・バランサの詳細な構成ステップは、このトピックで説明する2つの要素によって決まります。
Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシング
オラクル社は、サーバーのロード・バランシング製品としてOracle HTTP ServerとOracle Traffic Directoryの2つを提供しています。

親トピック: 高可用性の概要

ロード・バランシングについて

ロード・バランシングとは、環境内のコンピューティングおよびネットワーキング・リソース全体において、ジョブとそれに関係する通信を均等に分散することです。

Oracle HTTP ServerまたはOracle Traffic Directorを使用して、異なるコンポーネントまたはアプリケーション間のロード・バランシングを構成します。Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシングを参照してください。

また、(図1-1に示されているように)ロード・バランサとOracle HTTP Serverを組み合せて、最大限の高可用性を実現することも可能です。

親トピック: 高可用性環境でのサーバーのロード・バランシング

サード・パーティ製のロード・バランサの要件

特定の機能を持ったサード・パーティ製のロード・バランサであれば、高可用性デプロイメント内で使用できます。

固定セッション・ルーティングをサポートするロード・バランサの使用をお薦めします。固定セッション・ルーティングは、最初のリクエストを処理するサーバーに、セッション全体を通じてトラフィックをルーティングする機能です。

外部ロード・バランサは次の機能を備えている必要があります。

仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは、実際のホスト名ではなく、仮想ホスト名を使用してサービスにアクセスします。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。通常は、ロード・バランサがOracle HTTP Serverインスタンス全体のバランスを取り、その後でOracle HTTP Serverがアプリケーション・サーバー全体のバランスを取ります。
ポート変換の構成。
ポート(HTTPおよびHTTPS)のモニタリング。
仮想サーバー名およびポートをロード・バランサ上に構成する機能。
複数の仮想サーバーの構成。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、クラスタの場合、ロード・バランサを1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートに構成する必要があります。
仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。
リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。外部ロード・バランサで障害の自動検出が可能な場合は、それを使用することをお薦めします。
フォルト・トレラント・モード: ロード・バランサはフォルト・トレラント・モードで構成することをお薦めします。
コール元クライアントに戻るように構成された仮想サーバー: トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。この構成は、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。
SSLアクセラレーション。この機能の使用をお薦めしますが、必須ではありません。
クライアントIPアドレス(保持):ロード・バランサは、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持できる必要があります。

親トピック: 高可用性環境でのサーバーのロード・バランシング

サード・パーティ製のロード・バランサの構成

ロード・バランサの詳細な構成ステップは、このトピックで説明する2つの要素によって決まります。

ロード・バランサを使用する環境
使用するロード・バランサのタイプ

これらの理由から、ご使用のロード・バランサのマニュアルに従うことをお薦めします。高度なロード・バランサの構成ステップについては、操作するコンポーネントのエンタープライズ・デプロイメント・ガイドを参照してください。

親トピック: 高可用性環境でのサーバーのロード・バランシング

Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシング

オラクル社では、サーバーのロード・バランシング製品としてOracle HTTP ServerとOracle Traffic Directoryの2つを提供しています。

表2-2 サーバーのロード・バランシング製品

製品説明

製品	説明
Oracle HTTP Server(OHS)	WebLogic Serverプロキシ・プラグイン・モジュールが組み込まれたWebサーバーで、WebLogic ServerのHTTPフロントエンドとして機能します。クライアントからのリクエストを受信し、WebLogic Serverへの各リクエストの負荷のバランスを取ります。OHSの`mod_wl_ohs`モジュールは、リクエストをWebLogicサーバーにルーティングします。`mod_weblogic` (Apache HTTP Server用のOracle WebLogic Serverプラグイン)と同じロード・バランシング機能を提供します。『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』のOracle HTTP Serverのmod_wl_ohsプラグインの構成に関する項を参照してください。 `mod_wl_ohs`モジュールの詳細は、mod_wl_ohs.confの構成を参照してください。
Oracle Traffic Director	高速で、信頼性と拡張性のあるレイヤー7のソフトウェア・ロード・バランサです。すべてのHTTP、HTTPSおよびTCPトラフィックに対する信頼できるエントリ・ポイントです。指定されたロード・バランシング・メソッドに基づくクライアントから受信したリクエストの分散、指定されたルールに基づくリクエストのルーティング、頻繁にアクセスされるデータのキャッシュ、トラフィックの優先付け、およびサービス品質の制御を行います。「Oracle Traffic Directorの機能」を参照してください。

Oracle HTTP Server(OHS)

WebLogic Serverプロキシ・プラグイン・モジュールが組み込まれたWebサーバーで、WebLogic ServerのHTTPフロントエンドとして機能します。クライアントからのリクエストを受信し、WebLogic Serverへの各リクエストの負荷のバランスを取ります。OHSのmod_wl_ohsモジュールは、リクエストをWebLogicサーバーにルーティングします。mod_weblogic (Apache HTTP Server用のOracle WebLogic Serverプラグイン)と同じロード・バランシング機能を提供します。

『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』のOracle HTTP Serverのmod_wl_ohsプラグインの構成に関する項を参照してください。

mod_wl_ohsモジュールの詳細は、mod_wl_ohs.confの構成を参照してください。

Oracle Traffic Director

高速で、信頼性と拡張性のあるレイヤー7のソフトウェア・ロード・バランサです。すべてのHTTP、HTTPSおよびTCPトラフィックに対する信頼できるエントリ・ポイントです。指定されたロード・バランシング・メソッドに基づくクライアントから受信したリクエストの分散、指定されたルールに基づくリクエストのルーティング、頻繁にアクセスされるデータのキャッシュ、トラフィックの優先付け、およびサービス品質の制御を行います。「Oracle Traffic Directorの機能」を参照してください。

親トピック: 高可用性環境でのサーバーのロード・バランシング

アプリケーション・フェイルオーバー

フェイルオーバーとアプリケーション動作には、様々な種類があります。

フェイルオーバー、アプリケーションのフェイルオーバーと状態について
フェイルオーバーとは、過負荷のリソースや障害の発生したリソース(サーバー、ディスク・ドライブ、ネットワークなど)を、バックアップの場所に移動させる機能のことです。
セッションのフェイルオーバー要件
シームレスなフェイルオーバーを実現するために、アプリケーションは特定の条件を満たす必要があります。
アプリケーションのフェイルオーバーの予想される動作
環境を正しく構成している場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、ユーザーは気が付きません。

親トピック: 高可用性の概要

フェイルオーバー、アプリケーションのフェイルオーバーと状態について

フェイルオーバーとは、過負荷のリソースや障害の発生したリソース(サーバー、ディスク・ドライブ、ネットワークなど)を、バックアップの場所に移動させる機能のことです。

アプリケーション・フェイルオーバーでは、特定のジョブを実行するアプリケーション・コンポーネントが使用できなくなった場合に、障害の発生したコンポーネントのコピーがかわりにジョブを完了します。

状態とは、ジョブに対して何が実行されたかに関する情報を指します。WebLogic Serverでは、セッション・レプリケーションおよびレプリカ対応スタブを使用して、状態の情報を保持します。コンポーネントでジョブの実行が予期せず停止すると、レプリケーション手法によって、障害の発生したコンポーネントが停止した箇所をコンポーネントのコピーで特定し、ジョブを完了できます。

親トピック: アプリケーション・フェイルオーバー

セッションのフェイルオーバー要件

シームレスなフェイルオーバーを実現するために、アプリケーションは特定の条件を満たす必要があります。

注意:

Oracleのアプリケーションは、特定の例外がアプリケーションに適用されないかぎり、これらのセッションのフェイルオーバー要件を満たします。

シームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。

アプリケーションがクラスタ内にあり、クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できます。
ステートフル・アプリケーションに対し、状態のレプリケーションが正しく構成されています。
Oracle HTTP Serverを使用している場合は、WebLogic Clusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されています。
ハードウェア・ロード・バランサを使用する場合は、ロード・バランサが:
- 利用可能なインスタンスすべてに対してトラフィックをルーティングしています
- 利用できないインスタンスをマークするように、ヘルス・モニターで正しく構成されています
- セッションの状態の永続性をサポートするように構成されています

親トピック: アプリケーション・フェイルオーバー

アプリケーションのフェイルオーバーの予想される動作

環境を正しく構成している場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、ユーザーは気が付きません。

たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。

ユーザーがリクエストを行います。ハードウェア・ロード・バランサによって、そのリクエストがアプリケーションのインスタンスAにルーティングされます。
ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。
ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。
ユーザーが別のリクエストを行います。このリクエストがインスタンスBにルーティングされます。
インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。
インスタンスBのセッションの状態を使用してアプリケーションが開始されます。ユーザーは、中断なく作業を続行します。

注意:

高可用性をサポートするドメイン・テンプレートおよび拡張テンプレートの詳細は、ドメイン・テンプレート・リファレンスを参照してください。

アプリケーション・レベルにおけるフェイルオーバーおよびレプリケーションの詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタにおけるフェイルオーバーおよびレプリケーションに関する項を参照してください。

親トピック: アプリケーション・フェイルオーバー

Real Application Clusters

Oracle Real Application Clusters (RAC)を使用すると、Oracle Databaseのクラスタを構成できます。クラスタは、相互に接続された複数のコンピュータまたはサーバーで構成され、エンド・ユーザーおよびアプリケーションからは1つのサーバーとして認識されます。

Oracle RACは、Oracle Clusterwareをインフラストラクチャとして使用し、複数のサーバーを結び付けて1つのシステムとして機能させます。ハードウェアの集合(クラスタ)とともに、各コンポーネントの処理能力を結合して単一の堅牢なコンピューティング環境を構成します。Oracle RACは、Oracle Fusion Middlewareに対して、スケーラビリティおよび可用性の高いデータベースを提供します。

クラスタ内のすべてのOracle RACインスタンスは、同じアクセス権および認可レベルを持ちます。ノードおよびインスタンスに障害が発生しても、障害が発生していないサーバー・インスタンスでデータベース・サービスが利用可能であるか、利用可能な状態にすることができるため、パフォーマンスに影響を及ぼす場合はありますが、停止することはありません。

注意:

Oracle RACの詳細は、次を参照してください。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』の概要とロードマップに関する項
『Oracle Clusterware管理およびデプロイメント・ガイド』のOracle Clusterwareの概要に関する項
『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle RACの概要に関する項

親トピック: 高可用性の概要

Coherenceクラスタと高可用性

各標準インストール・トポロジ(SIT)には、標準のCoherenceクラスタが含まれています。このクラスタは、追加構成の開始点になります。

Coherenceクラスタは、Coherenceを実行するJava Virtual Machine (JVM)プロセスの集合です。12cでは、これらのプロセスをWebLogic管理対象Coherenceサーバーと呼びます。クラスタに参加しているJVMはクラスタ・メンバーまたはクラスタ・ノードです。クラスタ・メンバーには次のものが含まれます。

専用記憶域メンバー
記憶域が無効になっているクライアント・メンバー
プロキシ・メンバー(Coherenceキャッシュにアクセスできる非クラスタ・メンバー)

クラスタ・メンバーどうしは、Tangosol Cluster Management Protocol (TCMP)を使用して通信します。クラスタ・メンバーでは、マルチキャスト通信(ブロードキャスト)とユニキャスト通信(Point-to-Point通信)の両方でTCMPを使用します。

Coherenceの特徴は次のとおりです。

各ドメインには通常、1つのCoherenceクラスタが含まれます。
ドメイン内の各管理対象Coherenceサーバーは、Coherenceクラスタ・システム・リソースを通じて定義されるCoherenceクラスタに関連付けられます。
各アプリケーションのCoherence構成は、アプリケーションとともにすべての専用記憶域ノードにデプロイされるグリッド・アーカイブ(GAR)ファイル内にあります。

Coherenceを使用するすべてのアプリケーションは、管理対象Coherenceサーバーに関連付けられたクラスタを使用し、各アプリケーションと同じ場所にそれぞれのGARファイルをデプロイします。表2-3に、Coherenceに関する参照情報を示します。

表2-3 CoherenceおよびCoherenceクラスタ

情報	参照先
Coherenceの概要と機能	Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発のCoherenceの概要
Coherenceクラスタの作成	Coherence管理者ガイドのCoherence用のWebLogic Serverドメイン・トポロジの設定
Coherenceクラスタの構成	Oracle WebLogic Serverクラスタの管理のCoherenceクラスタの構成と管理

親トピック: 高可用性の概要

障害時リカバリ

可用性を最大限に高めるために、地理的に離れた複数の場所にサービスをデプロイして、予期せぬ障害や自然災害によるサイト全体の障害に備えることが必要な場合があります。

Oracle Fusion Middleware製品は、バックアップとして機能する、地理的に離れたスタンバイ・サイトの構成をサポートしています。本番サイトで自然災害や計画外停電が発生した場合は、このバックアップにアプリケーションやサービスをフェイルオーバーすることができます。

障害時リカバリに関する詳細は、Oracle Fusion Middleware障害時リカバリの概要に関する項を参照してください。

親トピック: 高可用性の概要

インストール時の構成(プロファイル)

SITを構成する際に考慮すべきドメイン、ファイルおよびデータベースベースのプロファイル・タイプがあります。

ドメイン(トポロジ)プロファイル
ドメインを設定するには、構成ウィザードまたはWebLogic Scripting Tool (オフライン)を使用します。
永続性プロフィルのタイプ
永続性プロファイルとは、特定の永続環境の実現をするためにお薦めする設定の集合です。データベースとファイル・ベースの2種類の永続性プロファイルがあります。
構成後のデフォルト設定
標準的なインストールの後、ドメインはファイル・ベースの永続性プロファイルで設定されます。

親トピック: 高可用性の概要

ドメイン(トポロジ)プロファイル

ドメインを設定するには、構成ウィザードまたはWebLogic Scripting Tool (オフライン)を使用します。

ドメインの作成、更新、構成の詳細は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの構成に関する項を参照してください。

12c (12.2.1.3.0)のインストレーション・ガイドには、標準インストール・トポロジである単一マシンのマルチサーバー・ドメインを設定するステップが示されています。Oracle Fusion Middlewareの標準HAトポロジについてでは、このトポロジの詳細を説明します。関連項目:

『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverのインストールに関する項
『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middlewareインフラストラクチャ・ドメインの構成に関する項。

親トピック: インストール時の構成(プロファイル)

永続性プロファイルのタイプ

永続性プロファイルとは、特定の永続環境の実現をするためにお薦めする設定の集合です。データベースとファイル・ベースの2種類の永続性プロファイルがあります。

表2-4に、それぞれのプロファイルの永続性タイプを示します。

永続性プロファイルはコンポーネントやサービスと様々な組合せが可能ですが、永続性タイプのグループは最適な組合せで処理されます。それぞれのプロファイル内では、すべて同じオプションを使用することをお薦めします。

表2-4 データベースおよびファイルの永続性プロファイルの永続性タイプ

コンポーネント/サービス	データベース永続性プロファイル	ファイル永続性プロファイル
JMS	データベース・ストア内のWLS JMS	ファイル・ストア内のWebLogic Server JMS
JTA	データベース・ストア内のJTA	ファイル・ストア内のJTA
OPSS	データベース・ストア	データベース・ストア
MDS	データベース・ストア	データベース・ストア
サービス表	データベース・ストア	データベース・ストア
フェイルオーバー	サーバー全体の移行	サーバー全体の移行

注意:

MDSデータ・ソースには、WebLogic Serverファイル永続性ストアがデータ・ソースとともに割り当てられています。ファイル永続性ストアを開発モードのみで使用するため、高可用性目的では無視できます。障害発生時にファイル永続性ストアをリカバリする必要ありません。

注意:

特定の製品および機能におけるデータベースのバージョン要件は、相互運用性および互換性ガイドのサポートされるデータベースとの相互運用性を参照してください。

親トピック: インストール時の構成(プロファイル)

構成後のデフォルト設定

標準的なインストールの後、ドメインはファイル・ベースの永続性プロファイルで設定されます。

JMS/JTAリソースのデータベースベースの永続性を構成するには、JMSおよびJTAの高可用性を参照してください。サーバー全体の移行を設定するには、サーバー全体の移行を参照してください。

表2-5は、その他の参照情報です。

注意:

一部の製品は、共有ファイル・ストアに対して特定の要件が適用される場合がありますので、ご使用の製品の要件をよく確認してください。

表2-5 ドメインの構成に関する各項

詳細情報	参照先
ファイル永続性プロファイルで使用する共有ファイル・システム	共有記憶域の使用
JMSおよびJTA	JMSおよびJTAサービスのための移行可能ターゲットについて
フェイルオーバー	アプリケーション・フェイルオーバー

親トピック: インストール時の構成(プロファイル)

JMSおよびJTAのアプリケーションとサービスのフェイルオーバー

WebLogic Serverにおける移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスのことです。

サーバー全体の移行は、障害発生時にサーバー・インスタンスが物理的に別のシステムに移行するときに行われます。

サービスレベルの移行は、クラスタ内の別のサーバー・インスタンスにサービスを移動することを意味します。

次のトピックでは、JMSおよびJTAのサーバーとサービスのフェイルオーバーについて説明します。

自動サービス移行(JMS/JTA)について
WebLogic Server内のサービスレベルの移行とは、あるサーバー・インスタンスからクラスタ内の別の利用可能なサーバー・インスタンスに固定サービスを移動するプロセスのことです。

親トピック: 高可用性の概要

自動移行サービス(JMS/JTA)について

WebLogic Server内のサービスレベルの移行とは、あるサーバー・インスタンスからクラスタ内の別の利用可能なサーバー・インスタンスに固定サービスを移動するプロセスのことです。

移行可能ターゲットを使用すると、JMSサービスやJTAサービスを構成して可用性を高めることができます。移行可能ターゲットとは、クラスタ内のサーバーから別のサーバーに移行できる特別なターゲットです。移行可能ターゲットを使用することにより、一緒に移行する必要のある移行可能サービスをグループ化できます。元のサーバー上で問題が発生した場合に、移行可能ターゲットをクラスタ・サーバー間で移行することにより、高可用性が実現します。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。

リリース12c (12.2.1.3.0)以降、構成ウィザードの「高可用性のオプション」画面を使用して、Fusion Middlewareコンポーネントのサービスレベルの移行の構成を自動化できます。この画面は、最初に自動サービス移行、永続ストア、またはその両方を使用するクラスタ、および構成ウィザードを使用してドメインに追加され、選択されたHAオプションが自動的に追加される、すべての後続のクラスタを作成するときに表示されます。

製品で自動サービス移行がサポートされていない場合、全体サービス移行を使用できます。

注意:

これらのトピックについては、『Oracle Fusion Middlewareクラスタの管理』のサービスの移行に関する項を参照してください。

親トピック: JMSおよびJTAのアプリケーションとサービスのフェイルオーバー

高可用性トポロジの設定手順

高可用性トポロジのサンプルを設定するための特定の順序に従って、インストールと構成ステップを完了することをお薦めします。

表2-6に、高可用性ミドルウェア・トポロジのサンプルを設定するために必要な高度なステップを示します。

表2-6 高可用性トポロジの設定手順

作業	説明	ドキュメント
1. Real Application Clustersのインストール	Real Application Clustersをインストールします。	『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle Database 12cソフトウェアおよびOracle RACのインストールに関する項
2. ミドルウェア・コンポーネントのインストールおよび構成	アプリケーションのインストレーション・ガイドの手順に従って、アプリケーションをインストールおよび構成します。	『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』の標準インストール・トポロジのインストールおよび構成のロードマップに関する項または製品のインストレーション・ガイド
3. Oracle HTTP Serverのインストールおよび構成	同じドメインにOracle HTTP Serverをインストールおよび構成します。	『Oracle HTTP Serverのインストールと構成』.のWebLogic ServerドメインでのOracle HTTP Serverのインストールおよび構成のロードマップに関する項
4. ロード・バランサの構成	特定の要件を満たすサード・パーティ製のロード・バランサ、またはOracle HTTP Server、Oracle Traffic Directorのいずれかを構成します。	高可用性環境でのサーバーのロード・バランシング
5. Oracle Fusion MiddlewareOracle Fusion Middlewareのトポロジのスケール・アウト(マシンのスケール・アウト)	ステップに従って、Fusion Middleware WebLogic Serverドメイン内のすべての製品にトポロジをスケール・アウト(マシンをスケール・アウト)します。	トポロジのスケール・アウト(マシンのスケール・アウト)
6. 管理サーバーの高可用性の構成	管理サーバーの高可用性を構成します。	管理サーバーの高可用性

親トピック: 高可用性の概要