| Oracle® Fusion Middleware高可用性ガイド 12c (12.2.1.0.0) E69925-01 |
|
 前 |
 次 |
この項では、高可用性の概要と次の項目について説明します。
Oracle Fusion Middlewareの概要については、『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クラスタの管理』のクラスタ内での通信に関する項 |
この項の内容は次のとおりです。
ロード・バランシングとは、環境内のコンピューティングおよびネットワーキング・リソース全体において、ジョブとそれに関係する通信を均等に分散することです。
一般的に、ロード・バランサは、高可用性デプロイメントのフロントエンド処理を行います。Oracle HTTP ServerまたはOracle Traffic Directorを使用して、異なるコンポーネントまたはアプリケーション間のロード・バランシングを構成します。第2.2.4項「Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシング」を参照してください。
また、(図1-1に示されているように)ロード・バランサとOracle HTTP Serverを組み合せて、最大限の高可用性を実現することも可能です。
Oracle Fusion Middlewareの高可用性デプロイメントには、サード・パーティ製のロード・バランサを使用できます。固定セッション・ルーティングをサポートするロード・バランサの使用をお薦めします。固定セッション・ルーティングは、最初のリクエストを処理するサーバーに、セッション全体を通じてトラフィックをルーティングする機能です。
その場合、外部ロード・バランサは次の機能を備えている必要があります。
仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは、実際のホスト名ではなく、仮想ホスト名を使用してサービスにアクセスします。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。通常は、ロード・バランサがOracle HTTP Serverインスタンス全体のバランスを取り、その後でOracle HTTP Serverがアプリケーション・サーバー全体のバランスを取ります。
ポート変換の構成。
ポート(HTTPおよびHTTPS)のモニタリング。
仮想サーバー名およびポートをロード・バランサ上に構成する機能。
複数の仮想サーバーの構成。各仮想サーバーについては、複数のポート上のトラフィック管理を構成できることが必要です。たとえば、クラスタの場合、ロード・バランサを1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートに構成する必要があります。
仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。
リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。外部ロード・バランサで障害の自動検出が可能な場合は、それを使用することをお薦めします。
フォルト・トレラント・モード: ロード・バランサはフォルト・トレラント・モードで構成することをお薦めします。
コール元クライアントに戻るように構成された仮想サーバー: トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。この構成は、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。
SSLアクセラレーション。この機能の使用をお薦めしますが、必須ではありません。
クライアントIPアドレス(保持):ロード・バランサは、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持できる必要があります。
ロード・バランサの詳細な構成手順は、次の内容によって異なります。
ロード・バランサを使用する環境
使用するロード・バランサのタイプ
これらの理由から、ご使用のロード・バランサのマニュアルに従うことをお薦めします。高度なロード・バランサの構成手順については、操作するコンポーネントのエンタープライズ・デプロイメント・ガイドを参照してください。
この項では、Oracleのロード・バランシング製品について説明します。
表2-2 サーバーのロード・バランシング製品
| 製品 | 説明 |
|---|---|
|
Oracle HTTP Server(OHS) |
WebLogic Serverプロキシ・プラグイン・モジュールが組み込まれたWebサーバーで、1つ以上のWebLogic ServerのHTTPフロントエンドとして機能します。クライアントからのリクエストを受信し、1つ以上のWebLogic Serverでリクエストごとに負荷のバランスを取ります。OHSの |
|
Oracle Traffic Director |
WebLogicの相互運用性が強化された可用性に優れたアプリケーション・デリバリ・コントローラです。1つ以上のクラスタへのリクエストを効率的に処理します。高速で、信頼性と拡張性のあるレイヤー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クラスタの管理』のクラスタにおけるフェイルオーバーおよびレプリケーションに関する項を参照してください。 |
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およびCoherenceのインストールと構成』または製品固有のインストレーション・ガイドの手順に従っている場合、標準的なインストール・トロポジには、追加構成の開始点となる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ファイルをデプロイします。次の表に、Coherenceに関する参照情報を示します。
可用性を最大限に高めるために、地理的に離れた複数の場所にサービスをデプロイして、予期せぬ障害や自然災害によるサイト全体の障害に備えることが必要な場合があります。Oracle Fusion Middleware製品は、バックアップとして機能する、地理的に離れたスタンバイ・サイトの構成をサポートしています。本番サイトで自然災害や計画外停電が発生した場合は、このバックアップにアプリケーションやサービスをフェイルオーバーすることができます。
障害時リカバリに関する詳細は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』を参照してください。
この項の内容は次のとおりです。
ドメインを設定するには、構成ウィザードまたはWebLogic Scripting Tool (オフライン)を使用します。ドメインの作成、更新、構成の詳細は、『Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成』を参照してください。
12c (12.2.1.0.0)のすべてのインストレーション・ガイドには、標準インストール・トポロジである単一マシンのマルチサーバー・ドメインを設定する手順が示されています。第1.6項「Oracle Fusion Middlewareの標準的なHAトポロジの理解」では、このトポロジの詳細を説明します。詳細は、次を参照してください。
Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成
Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成
永続性プロファイルとは、特定の永続環境の実現をするためにお薦めする設定の集合です。データベースとファイル・ベースの2種類の永続性プロファイルがあります。次の表に、それぞれのプロファイルの永続性タイプを示します。
表2-4 データベースおよびファイルの永続性プロファイルの永続性タイプ
| コンポーネント/サービス | データベース永続性プロファイル | ファイル永続性プロファイル |
|---|---|---|
|
JMS |
データベース・ストア内のWLS JMS |
ファイル・ストア内のWebLogic Server JMS |
|
JTA |
データベース・ストア内のJTA |
ファイル・ストア内のJTA |
|
OPSS |
データベース・ストア |
データベース・ストア |
|
MDS |
データベース・ストア |
データベース・ストア |
|
サービス表 |
データベース・ストア |
データベース・ストア |
|
フェイルオーバー |
サーバー全体の移行 |
サーバー全体の移行 |
永続性プロファイルはコンポーネントやサービスと様々な組合せが可能ですが、永続性タイプのグループは最適な組合せで処理されます。それぞれのプロファイル内では、すべて同じオプションを使用することをお薦めします。
|
注意: MDSデータ・ソースには、WebLogic Serverファイル永続性ストアがデータ・ソースとともに割り当てられています。ファイル永続性ストアを開発モードのみで使用するため、高可用性目的では無視できます。障害発生時にファイル永続性ストアをリカバリする必要ありません。 |
|
関連項目: 特定の製品および機能におけるデータベースのバージョン要件は、『相互運用性および互換性ガイド』のサポートされるデータベースとの相互運用性に関する項を参照してください。 |
標準的なインストールの後、ドメインはファイル・ベースの永続性プロファイルで設定されます。JMS/JTAリソースにデータベース・ベースの永続性を構成するには、第7章「JMSおよびJTAの高可用性」を参照してください。サーバー全体の移行を設定するには、第3章「サーバー全体の移行」を参照してください。
|
注意: 一部の製品は、共有ファイル・ストアに対して特定の要件が適用される場合がありますので、ご使用の製品の要件をよく確認してください。 |
次の表に、その他の参照情報を示します。
表2-5 ドメインの構成に関する各項
| 詳細情報 | 参照先 |
|---|---|
|
共有ファイル・システムでのファイル永続性プロファイルの使用 |
|
|
JMSおよびJTA |
第7.2項「JMSおよびJTAサービスのための移行可能ターゲットについて」 |
|
フェイルオーバー |
|
WebLogic Serverにおける移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスのことです。サーバー全体の移行は、サーバー・インスタンスを物理的に別のシステムに移行したときに行います。サービスレベルの移行は、クラスタ内の別のサーバー・インスタンスにサービスを移動することを意味します。
この項では、JMSおよびJTAのサーバーとサービスのフェイルオーバーについて説明します。
WebLogic Server内のサービスレベルの移行とは、あるサーバー・インスタンスからクラスタ内の別の利用可能なサーバー・インスタンスに固定サービスを移動するプロセスのことです。
移行可能ターゲットを使用すると、JMSサービスやJTAサービスを構成して可用性を高めることができます。移行可能ターゲットとは、クラスタ内のサーバーから別のサーバーに移行できる特別なターゲットです。移行可能ターゲットを使用することにより、一緒に移行する必要のある移行可能サービスをグループ化できます。元のサーバー上で問題が発生した場合に、移行可能ターゲットをクラスタ・サーバー間で移行することにより、高可用性が実現します。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。
製品で自動サービス移行がサポートされていない場合、全体サービス移行を使用できます。
|
関連項目: 詳細は、『Oracle Fusion Middleware Oracleクラスタの管理』で次のトピックを含むサービスの移行に関する項を参照してください。
|
次の表に、高可用性ミドルウェア・トポロジのサンプルを設定するために必要な高度な手順を示します。
表2-6 高可用性トポロジの設定手順
| 作業 | 説明 | マニュアル |
|---|---|---|
|
1. Real Application Clustersのインストール |
Real Application Clustersをインストールします。 |
Oracle Real Application Clusters管理およびデプロイメント・ガイド |
|
2. ミドルウェア・コンポーネントのインストールおよび構成 |
アプリケーションのインストレーション・ガイドの手順に従って、アプリケーションをインストールおよび構成します。 |
『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』または製品のインストレーション・ガイド |
|
3. Oracle HTTP Serverのインストールおよび構成 |
同じドメインにOracle HTTP Serverをインストールおよび構成します。 |
Oracle HTTP Serverのインストールと構成 |
|
4. ロード・バランサの構成 |
特定の要件を満たすサード・パーティ製のロード・バランサ、またはOracle HTTP Server、Oracle Traffic Directorのいずれかを構成します。 |
第2.2項「高可用性環境でのサーバーのロード・バランシング」 |
|
5. Oracle Fusion Middleware Oracle Fusion Middlewareのトポロジのスケールアウト(マシンのスケールアウト) |
手順に従って、Fusion Middleware WebLogic Serverドメイン内のすべての製品にトポロジをスケール・アウト(マシンをスケール・アウト)します。 |
第6章「トポロジのスケール・アウト(マシンのスケール・アウト)」 |
|
6. 管理サーバーの高可用性の構成 |
管理サーバーの高可用性を構成します。 |
|
