ヘッダーをスキップ
Oracle® Fusion Middleware高可用性ガイド
12c (12.1.2)
E47984-02
  目次へ移動
目次
前
前 		 次
次		  

2 高可用性の概要

この章では、高可用性の概要と次の項目について説明します。

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クラスタの管理』のクラスタ内での通信に関する項

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

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

通常、Oracle Fusion Middlewareの高可用性デプロイメントのフロントエンドには、受信したリクエストを分散するように、様々なアルゴリズムを使用して構成できるロード・バランサが配置されます。様々なコンポーネントまたはアプリケーション間のロード・バランシングを構成できます。

また、Oracle HTTP Serverを使用するか、Oracle Traffic Director (Exalogicのみに搭載)を使用して、様々なコンポーネント間やアプリケーション間で、ロード・バランシングを構成することもできます。詳細は、第2.1.3項「Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシング」を参照してください。

この項の内容は次のとおりです。

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

Oracle Fusion Middlewareの高可用性デプロイメントには、サード・パーティ製のロード・バランサを使用できます。その場合、外部ロード・バランサは次の機能を備えている必要があります。

  • 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。


    注意:

    通常は、ロード・バランサがOracle HTTP Serverインスタンス全体のバランスを取り、その後でOracle HTTP Serverがアプリケーション・サーバー全体のバランスを取ります。

  • ポート変換の構成。

  • ポート(HTTPおよびHTTPS)の監視。

  • 仮想サーバーとポートの構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。さらに、仮想サーバー名とポートは次の要件を満たしている必要があります。

    • ロード・バランサでは、複数の仮想サーバーの構成が可能である必要があります。各仮想サーバーについては、複数のポート上のトラフィック管理を構成できることが必要です。たとえば、Oracle WebLogicクラスタの場合は、1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートを指定してロード・バランサを構成する必要があります。

    • 仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。

  • ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。

  • リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を(通知またはその他の方法によって)検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。外部ロード・バランサに障害の自動検出機能がある場合は、それを使用することをお薦めします。

  • フォルト・トレラント・モード: ロード・バランサはフォルト・トレラント・モードで構成することをお薦めします。

  • コール元クライアントに戻るように構成された仮想サーバー: トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。この構成は、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。

  • SSLアクセラレーション。この機能の使用をお薦めしますが、必須ではありません。

  • クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。

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

ロード・バランサの詳細な構成手順は、次の内容によって異なります。

  • ロード・バランサを使用する環境

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

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

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

この項では、ロード・バランシングの実装に使用できるOracle製品について説明します。

Oracle HTTP Serverを使用したサーバーのロード・バランシング

Oracle HTTP Serverは、WebLogic Serverプロキシ・プラグイン・モジュールが組み込まれたWebサーバーであり、1つ以上のWebLogic ServerのHTTPフロントエンドとして機能します。この組込み機能がクライアントからのリクエストを受信し、1つ以上のWebLogic Serverで負荷のバランスを取ります。

Oracle HTTP Serverには、Oracle WebLogic Serverにリクエストをルーティングするmod_wl_ohsモジュールがあります。mod_wl_ohsモジュールは、Apache HTTP Server用のOracle WebLogic Serverプラグイン(mod_weblogic)と同じロード・バランシング機能を提供します。詳細は、Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用のOracle HTTP Serverのmod_wl_ohsプラグインの構成に関する項を参照してください。mod_wl_ohsモジュールの詳細は、第7.8.1.4項「mod_wl_ohs.confの構成」を参照してください。

Oracle Traffic Directorを使用したサーバーのロード・バランシング

Oracle Traffic Directorは、可用性に優れたアプリケーション・デリバリ・コントローラの役割を果たし、WebLogicとの相互運用性の強化により、1つ以上のWebLogic Serverクラスタで受信リクエストを効率よく処理できます。Oracle Traffic Directorは高速で、かつ信頼性と拡張性のあるレイヤー7のソフトウェア・ロード・バランサです。バック・エンドのアプリケーション・サーバーおよびすべてのWebサーバーへのすべてのHTTP、HTTPS、TCPトラフィックに対する信頼できるエントリ・ポイントとして機能するように、Oracle Traffic Directorを設定できます。Oracle Traffic Directorは、クライアントから受信したリクエストの、指定されたロード・バランシング・メソッドに基づくバック・エンドのサーバーへの分散、指定されたルールに基づくリクエストのルーティング、頻繁にアクセスされるデータのキャッシュ、トラフィックの優先付け、およびサービス品質の制御を行います。Oracle Traffic Directorは、Exalogicでのみ使用可能です。

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

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

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

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

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


注意:

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

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

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

環境を正しく構成している場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気が付きません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。

  1. ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、そのリクエストがアプリケーションのインスタンスAにルーティングされます。

  2. ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。

  3. ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。

  4. ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。

  5. インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。

  6. インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。


関連項目:

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

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

2.3 Real Application Clusters

Oracle Real Application Clusters (RAC)を使用すると、Oracle Databaseのクラスタを構成できます。クラスタは、相互に接続された複数のコンピュータまたはサーバーで構成され、エンド・ユーザーおよびアプリケーションからは1つのサーバーとして認識されます。Oracle RACでは、インフラストラクチャとしてOracle Clusterwareを使用し、複数のサーバーを関連付けてそれらが単一のシステムとして動作するように構成します。ハードウェアの集合(クラスタ)とともに、各コンポーネントの処理能力を結合して単一の堅牢なコンピューティング環境を構成します。Oracle RACは同時に、Oracle Fusion Middlewareに対して、スケーラビリティおよび可用性の高いデータベースを提供します。

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


関連項目:

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

  • 『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』

  • 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

  • 『Oracle Clusterware管理およびデプロイメント・ガイド』

2.4 Coherenceクラスタと高可用性

『Oracle Fusion Middleware Oracle WebLogic ServerおよびCoherenceのインストールと構成』またはOracle Fusion Middleware Oracle Application Development FrameworkのためのOracle Fusion Middlewareのインストールと構成などの製品インストレーション・ガイドの手順に従っている場合、標準的なインストール・トポロジには、追加構成の開始点となる標準的なCoherenceクラスタが含まれます。

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

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

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

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

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

情報 参照先

Coherenceの概要と機能

『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のCoherenceの概要に関する項

Coherenceクラスタの作成

『Coherence管理者ガイド』のCoherence用のWebLogic Serverドメイン・トポロジの設定に関する項

Coherenceクラスタの構成

『Oracle WebLogic Serverクラスタの管理』のCoherenceクラスタの構成と管理に関する項

2.5 障害時リカバリ

可用性を最大限に高めるために、地理的に離れた複数の場所にサービスをデプロイして、予期せぬ障害や自然災害によるサイト全体の障害に備えることが必要な場合があります。Oracle Fusion Middleware製品は、バックアップとして機能する、地理的に離れたスタンバイ・サイトの構成をサポートしています。本番サイトで自然災害や計画外停電が発生した場合は、このバックアップにアプリケーションやサービスをフェイルオーバーすることができます。

Oracle Fusion Middlewareコンポーネントの障害時リカバリの詳細は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』を参照してください。

2.6 インストール時の構成

この項の内容は次のとおりです。

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

ドメインを設定するには、構成ウィザードまたはWebLogic Scripting Tool (オフライン)を使用します。ドメインの作成、更新、構成を行う手順は、『Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成』を参照してください。

12c (12.1.2)のすべてのインストレーション・ガイドには、拡張プロファイルを使用して単一マシンのマルチ・サーバー・ドメインを設定する手順が記載されています。詳細は、次のいずれかのガイドを参照してください。

  • 『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』

  • Oracle WebLogic Server Oracle ADFアプリケーションのためのFusion Middlewareのインストールと構成

2.6.2 永続性プロファイル

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

表2-3は、データベースとファイルの永続性プロファイルについて、それぞれの永続性タイプを示しています。

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

コンポーネント/サービス データベース永続性プロファイル ファイル永続性プロファイル

JMS

データベース・ストア内のAQ

ファイル・ストア内のWebLogic Server JMS

JTA

データベース・ストア内のJTA

ファイル・ストア内のJTA

OPSS

データベース・ストア

データベース・ストア

MDS

データベース・ストア

データベース・ストア

サービス表

データベース・ストア

データベース・ストア

フェイルオーバー

自動サービス移行

サーバー全体の移行

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


関連項目:

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

構成後のデフォルト設定

拡張ドメインを構成する場合のデフォルト設定は、データベース永続性モードです。コンパクト・ドメインを構成する場合は、ファイル永続性がデフォルトで設定されます。


注意:

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

表2-4は、その他の参照情報です。拡張ドメインを構成した後でファイル永続性を構成する場合(データベース永続性からファイル永続性に移行する場合)は、第5章「JMSおよびJTAの高可用性」を参照してください。

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

詳細情報 参照先

共有ファイル・システムでのファイル永続性プロファイルの使用

第3章「共有記憶域の使用」

JMSおよびJTA

第5.2項「JMSおよびJTAの高可用性サービスの構成」

フェイルオーバー

第2.2項「アプリケーションのフェイルオーバー」

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

WebLogic Serverにおける移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスのことです。サーバー全体の移行は、サーバー・インスタンスを物理的に別のシステムに移行したときに行います。サービスレベルの移行は、クラスタ内の別のサーバー・インスタンスにサービスを移動することを意味します。

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

このセクションの内容は次のとおりです。

2.7.1 サーバー全体の移行

WebLogic Serverクラスタは、クラスタ内の冗長サーバー上にオブジェクトやサービスを複製することによって、高可用性とフェイルオーバーを実現します。一方、JMSサーバーやJTAトランザクション回復サービスなどの一部のサービスは、クラスタ内で動作しているサービスのアクティブなインスタンスが常に1つだけ存在するという前提のもとに設計されています。このようなタイプの場合、サーバー・インスタンス上で同時にアクティブな状態になるのは1つのみであるため、固定サービスと呼ばれます。

WebLogic Serverクラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバー・インスタンスに均一にデプロイされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。ただし、JMSやJTAトランザクション・リカバリ・システムなどの固定サービスは、クラスタ内の個別のサーバー・インスタンスにデプロイされます。このようなサービスの場合、WebLogic Serverは、フェイルオーバーのかわりに、移行による障害リカバリをサポートしています。

WebLogic Serverには、JMSやJTAトランザクション・システムの可用性を高めるための機能(移行可能なサーバー)が用意されています。移行可能なサーバーは、サービスレベルではなく、サーバーレベルで自動または手動で移行できます。

移行可能なサーバーがなんらかの理由(ハング、ネットワークからの切断、ホスト・システムの障害など)で使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能なサーバーは、可能であれば同じシステム上で自動的に再起動されます。障害が発生した同じシステム上で再起動できないときは、別のシステムに移行されます。また、管理者は手動でサーバー・インスタンスの移行を開始することもできます。


関連項目:

サーバー全体の自動移行の準備、サーバー全体の自動移行の構成、サーバー移行のプロセスおよび通信の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。

JMSサービスとJTAサービスの詳細は、第5章「JMSおよびJTAの高可用性」を参照してください。

2.7.2 自動サービス移行

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

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


関連項目:

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』で次のトピックを含むサービスの移行に関する項を参照してください。

  • サービスの移行フレームワークの理解

  • 移行前の要件

  • JMS関連サービスの自動移行を構成する手順

  • JTAトランザクション回復サービスの自動移行を構成する手順

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

この項では、第1.5項「Oracle Fusion Middlewareの標準的なHAトポロジの理解」で説明したトポロジのように、サンプル・ミドルウェアの高可用性トポロジを設定するための一般的な手順を示します。

表2-5に、高可用性トポロジの設定に必要な手順を示します。

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

作業 説明 マニュアル

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.1項「高可用性環境でのサーバーのロード・バランシング」を参照

5. トポロジのスケール・アウト(マシンのスケール・アウト)

手順に従って、Fusion Middleware WebLogic Serverドメイン内のすべてのFusion Middleware製品にトポロジをスケール・アウト(マシンをスケール・アウト)します。

第6章「トポロジのスケール・アウト(マシンのスケール・アウト)」を参照

  前
前 		 次
次
  目次へ移動
目次