親トピック: 高可用性の概要
スケール・アウトを行う前に、重要な概念について理解してください。
表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クラスタの管理』のクラスタでの通信に関する項を参照してください
一般的に、ロード・バランサは、高可用性デプロイメントのフロントエンド処理を行います。
ロード・バランシングとは、環境内のコンピューティングおよびネットワーキング・リソース全体において、ジョブとそれに関係する通信を均等に分散することです。
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 Directoryの2つを提供しています。
表2-2 サーバーのロード・バランシング製品
製品 | 説明 |
---|---|
Oracle HTTP Server(OHS) |
WebLogic Serverプロキシ・プラグイン・モジュールが組み込まれたWebサーバーで、WebLogic ServerのHTTPフロントエンドとして機能します。クライアントからのリクエストを受信し、WebLogic Serverへの各リクエストの負荷のバランスを取ります。OHSの 詳細は、Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用のOracle HTTP Serverのmod_wl_ohsプラグインの構成を参照してください。
|
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クラスタの管理』のクラスタにおけるフェイルオーバーおよびレプリケーションに関する項を参照してください。
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の概要に関する項
各標準インストール・トポロジ(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 (オフライン)を使用します。
ドメインの作成、更新、構成の詳細は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの構成に関する項を参照してください。
12c (12.2.1.2)のインストレーション・ガイドには、標準インストール・トポロジである単一マシンのマルチサーバー・ドメインを設定する手順が示されています。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 |
|
フェイルオーバー |
WebLogic Serverにおける移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスのことです。
サーバー全体の移行は、障害発生時にサーバー・インスタンスが物理的に別のシステムに移行するときに行われます。
サービスレベルの移行は、クラスタ内の別のサーバー・インスタンスにサービスを移動することを意味します。
次のトピックでは、JMSおよびJTAのサーバーとサービスのフェイルオーバーについて説明します。
WebLogic Server内のサービスレベルの移行とは、あるサーバー・インスタンスからクラスタ内の別の利用可能なサーバー・インスタンスに固定サービスを移動するプロセスのことです。
移行可能ターゲットを使用すると、JMSサービスやJTAサービスを構成して可用性を高めることができます。移行可能ターゲットとは、クラスタ内のサーバーから別のサーバーに移行できる特別なターゲットです。移行可能ターゲットを使用することにより、一緒に移行する必要のある移行可能サービスをグループ化できます。元のサーバー上で問題が発生した場合に、移行可能ターゲットをクラスタ・サーバー間で移行することにより、高可用性が実現します。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。
製品で自動サービス移行がサポートされていない場合、全体サービス移行を使用できます。
注意:
詳細は、Oracle Fusion Middleware Oracleクラスタの管理のサービスの移行で、次のトピックを参照してください。
サービス移行フレームワークの理解
移行前の要件
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. 管理サーバーの高可用性の構成 |
管理サーバーの高可用性を構成します。 |