| Oracle® Fusion Middleware高可用性ガイド 11gリリース1 (11.1.1) B55898-11 |
|
 前 |
 次 |
この章では、高可用性トポロジにおいて重要となるOracle Fusion Middlewareの機能について説明します。次の項目が含まれます。
Oracle Fusion Middlewareには、次の2種類のコンポーネントが用意されています。
Javaコンポーネント: Javaコンポーネントは、システム・コンポーネントと対等なものですが、1つ以上のJava EEアプリケーションおよび一連のリソースとしてデプロイされます。Javaコンポーネントは、ドメイン・テンプレートの一部としてOracle WebLogic Serverドメインにデプロイされます。Javaコンポーネントの例としては、Oracle SOA SuiteおよびWebCenter Portalがあります。
システム・コンポーネント: システム・コンポーネントは、Javaアプリケーションとしてデプロイされない管理可能なプロセスです。システム・コンポーネントは、Oracle Process Manager and Notification (OPMN)で管理されます。システム・コンポーネントの例には、Oracle HTTP ServerおよびOracle Internet Directoryが含まれます。
Javaコンポーネントとシステム・コンポーネントはピアです。
Oracle Fusion Middlewareをインストールして構成すると、Oracle Fusion Middleware環境には、次が含まれます。
Oracle WebLogic Serverドメイン: 1つの管理サーバーと1つまたは複数の管理対象サーバーが含まれます。
1つ以上のシステム・コンポーネント・ドメイン(環境にシステム・コンポーネントが含まれている場合)。
Oracle Metadata Repository(インストールしたコンポーネントで必要な場合)。たとえば、Oracle SOA SuiteにはOracle Metadata Repositoryが必要です。
図2-1に、Oracle Fusion Middlewareの環境(1つの管理サーバーと2つの管理対象サーバーを含むOracle WebLogic Serverドメイン、システム・コンポーネント・ドメイン、およびOracle Metadata Repositoryで構成されています)を示します。
環境には、Middlewareホームも含まれます。これは、Oracle WebLogic Serverホーム、および必要に応じて1つ以上のOracleホームで構成されます。
WebLogic Serverドメインは、Javaコンポーネントの論理的関係があるグループです。ドメインには、管理サーバーと呼ばれる特別なWebLogic Serverインスタンスが含まれます。これは、ドメインのすべてのリソースを構成して管理する中核部分です。通常、管理対象サーバーと呼ばれるWebLogic Serverの追加インスタンスを含めて、ドメインを構成します。Webアプリケーション、EJB、Webサービス、その他のリソースなどのJavaコンポーネントを管理対象サーバーにデプロイし、管理サーバーを構成および管理の目的にのみ使用します。
ドメイン内の管理対象サーバーは、クラスタにグループ化できます。
Oracle WebLogic Serverドメインは、システム・コンポーネント・ドメインと同格です。どちらにも、Oracleホームの外部に固有の構成があります。
WebLogic Serverドメインのディレクトリ構造とWebLogic Serverホームのディレクトリ構造は別です。場所はどこでもよく、Middlewareホーム・ディレクトリ内にある必要はありません。
図2-2に、1つの管理サーバー、3つのスタンドアロンの管理対象サーバー、およびクラスタ化された3つの管理対象サーバーで構成されるOracle WebLogic Serverドメインを示します。
|
関連項目: ドメイン構成の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverのドメイン構成の理解を参照してください。 |
次の項では、ドメインのエンティティについて説明します。
管理サーバーは、ドメイン全体を構成するための集中管理エンティティとして動作します。ここにはドメインの構成ドキュメントが保持され、構成ドキュメントの変更がここから管理対象サーバーに配布されます。管理サーバーは、ドメイン内のリソースをすべて監視するための中央拠点として使用できます。
WebLogic Serverのドメインごとに、管理サーバーとして動作するサーバー・インスタンスが1つ必要です。
管理サーバーと対話するために、Oracle WebLogic Server管理コンソールであるOracle WebLogic Scripting Tool (WLST)を使用するか、または独自のJMXクライアントを作成できます。また、一部のタスクには、Oracle Enterprise Manager Fusion Middleware Controlを使用することもできます。
Fusion Middleware ControlとWebLogic管理コンソールは、管理サーバーで稼働します。Fusion Middleware Controlは、Oracle Fusion Middlewareの管理に使用するWebベースの管理コンソールであり、Oracle Fusion Middlewareには、Oracle HTTP Server、Oracle SOA Suite、Oracle WebCenter Portalなどのコンポーネント、Oracle Portal、Forms、Reports、Discoverer、およびOracle Identity Managementコンポーネントが含まれています。Oracle WebLogic Server管理コンソールは、ドメイン内の管理サーバーや管理対象サーバーなど、Oracle WebLogic Serverドメイン内のリソースの管理に使用されるWebベースの管理コンソールです。
管理対象サーバーでは、ビジネス・アプリケーション、アプリケーション・コンポーネント、Webサービス、およびそれらに関係するリソースがホストされます。パフォーマンスを最適化するために、管理対象サーバーには、ドメインの構成ドキュメントの読取り専用のコピーが保持されます。管理対象サーバーが起動すると、ドメインの管理サーバーに接続して、その構成ドキュメントと管理サーバーに保持されているドキュメントが同期化されます。
ドメインの作成時には、特定のドメイン・テンプレートを使用して作成します。そのテンプレートでは、特定のコンポーネントまたはOracle SOA Suiteのようなコンポーネントのグループがサポートされます。ドメイン内の管理対象サーバーは、それらの特定のOracle Fusion Middlewareシステム・コンポーネントをホストすることのみを目的として作成されます。
Oracle Fusion MiddlewareのJavaコンポーネント(Oracle SOA Suite、Oracle WebCenter Portal、一部のIdentity Managementコンポーネントなど)は、顧客が開発したアプリケーションとともに、ドメイン内の管理対象サーバーにデプロイされます。
別のコンポーネントをサポートするテンプレートを使用して作成されたドメインに、Oracle WebCenter Portalなど、他のコンポーネントを追加する場合には、ドメイン内に追加の管理対象サーバーを作成し、追加するコンポーネント用のドメイン・テンプレートを使用して、ドメインを拡張できます。
アプリケーションのパフォーマンス、スループットまたは高可用性の向上が要求される本番環境では、クラスタとして動作するように複数の管理対象サーバーを構成できます。クラスタとは、同時に稼働し、協調動作によってスケーラビリティと信頼性の向上を実現する、WebLogic Serverの複数のサーバー・インスタンスの集合です。クラスタでは、(単一の管理対象サーバーでなく)管理対象サーバーごとに、ほとんどのリソースおよびサービスがまったく同じようにデプロイされるため、フェイルオーバーとロード・バランシングが可能になります。1つのドメインには、複数のWebLogic Serverクラスタが存在していても、クラスタとして構成されていない複数の管理対象サーバーが存在していてもかまいません。管理対象サーバーがクラスタ化されている場合とされていない場合の重要な違いは、フェイルオーバーとロード・バランシングに対するサポートです。これらの機能は、管理対象サーバーがクラスタ化されている場合にのみ利用できます。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のWebLogic Serverのクラスタリングの理解に関する項 |
ノード・マネージャは、Oracle WebLogic Serverとは別のプロセスとして稼働するJavaユーティリティであり、これを使用すると、管理サーバーを基準とした場所に関係なく、管理対象サーバーに対して共通操作を実行できます。ノード・マネージャを使用するかどうかはオプションですが、高可用性を要求するアプリケーションがWebLogic Server環境でホストされている場合には、ノード・マネージャを使用すると貴重な利点が得られます。
管理対象サーバーをホストするシステムでノード・マネージャを実行する場合、管理コンソールまたはコマンド行を使用して、管理対象サーバーをリモートで起動または停止できます。ノード・マネージャを使用して、予期しない障害が発生した後に、管理対象サーバーを自動的に再起動することもできます。
|
関連項目: Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド |
システム・コンポーネント・ドメインには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。システム・コンポーネント・ドメイン内のシステム・コンポーネントは、同じシステム上にある必要があります。システム・コンポーネント・ドメイン・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。
システム・コンポーネント・ドメインは、Oracle WebLogic Serverドメインと同格です。どちらにも、Oracleホームの外部に固有の構成があります。
システム・コンポーネント・ドメインのディレクトリ構造とOracleホームのディレクトリ構造は別です。場所はどこでもよく、Middlewareホーム・ディレクトリ内にある必要はありません。
Middlewareホームは、Oracle WebLogic Serverホーム、およびオプションで1つ以上のOracleホームから構成されています。
Middlewareホームは、ローカル・ファイル・システム上、またはNFS経由でアクセスできるリモート共有ディスク上に配置できます。
Oracleホームの詳細は、第2.1.4項「Oracleホームとは」を参照してください。Oracle WebLogic Serverホームの詳細は、第2.1.1項「WebLogic Serverドメインとは」を参照してください。
複数のホストがクラスタ化されている高可用性インストールでは、Middlewareホームのバイナリを、クラスタ内のすべてのホスト上で同一ディレクトリ・パスのディレクトリにインストールする必要があります。
Oracleホームには、特定の製品をホストするために必要なインストール済ファイルが含まれています。たとえば、SOA Oracleホームには、Oracle SOA Suiteのバイナリ・ファイルおよびライブラリ・ファイルで構成されるディレクトリが含まれています。
Oracleホームは、Middlewareホームのディレクトリ構造の中にあります。それぞれのOracleホームには、複数のシステム・コンポーネント・ドメインまたはOracle WebLogic Serverドメインを関連付けることができます。
複数のホストがクラスタ化されている高可用性インストールでは、Oracleホームのバイナリを、クラスタ内のすべてのホスト上で同一ディレクトリ・パスのディレクトリにインストールする必要があります。
この項で一覧表示されている用語の定義は、このマニュアルで説明されている概念の理解に役立ちます。
フェイルオーバー: 高可用性システムのメンバーに予期しない障害(計画外停止)が発生した場合、コンシューマへのサービス提供を継続するために、フェイルオーバー操作が実行されます。アクティブ/アクティブ・システムの場合、ロード・バランサのエンティティがアクティブ・メンバーにリクエストを配信することにより、フェイルオーバーが実行されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。
アクティブ/パッシブ・システムの場合、フェイルオーバー操作によってパッシブ・メンバーがアクティブになり、コンシューマはそのメンバーに接続されます。フェイルオーバー・プロセスは手動で実行できますが、障害を検出したらクラスタのリソースを障害ノードからスタンバイ・ノードに移動するようハードウェア・クラスタ・サービスを設定することにより、フェイルオーバー操作を自動化することもできます。
フェイルバック: 計画外停止後に計画されている操作です。システムがフェイルオーバー操作に成功した後、障害が発生した元のメンバーを修復して、スタンバイ・メンバーとしてシステムに再導入できます。フェイルバック・プロセスを開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。このプロセスによって、システムが障害発生前の構成に戻されます。
共有記憶域: クラスタ内の各ノードが、各自のプロセス・セットを実行するスタンドアロン・サーバーの場合でも、クラスタ内のすべてのノードから統一アクセスが必要なファイル・システム・ベースのデータおよび構成要素があります。共有記憶域とは、クラスタ内のいずれかのノードから同じ記憶域(通常はディスク)にアクセスできるクラスタの機能のことです。
SANベースのデプロイメントでは、OCFSなど、クラスタ化されたファイル・システムが必要になる場合もあります。この使用例として、JMSファイル・ベースの永続ストア、トランザクション・ログ永続ストア、コールド・フェイルオーバー・クラスタ設定時のドメイン構成などがあります。
1次ノード: クラスタ内で常にOracle Fusion Middlewareをアクティブに実行しているノードです。このノードで障害が発生すると、Oracle Fusion Middlewareは2次ノードにフェイルオーバーされます。1次ノードではアクティブなOracle Fusion Middlewareインストールが実行されているため、このノードで障害が発生すると、Oracle Fusion Middlewareは2次ノードにフェイルオーバーされます。この項の2次ノードの定義を参照してください。
2次ノード: アクティブなOracle Fusion Middlewareインストールが実行されている1次ノードで障害が発生すると、Oracle Fusion Middlewareはこのノードにフェイルオーバーされます。この項の1次ノードの定義を参照してください。
ネットワーク・ホスト名: /etc/hostsファイル(UNIXの場合)、C:\WINDOWS\system32\drivers\etc\hostsファイル(Windowsの場合)またはDNS解決のいずれかで指定される、IPアドレスに割り当てられる名前です。この名前は、システムが接続しているネットワークで参照可能です。多くの場合、ネットワーク・ホスト名と物理ホスト名は同じものを指します。しかし、各システムが持つ物理ホスト名は1つのみですが、ネットワーク・ホスト名は複数持つことができます。したがって、システムのネットワーク・ホスト名が常に物理ホスト名になるわけではありません。
物理ホスト名: このガイドでは、物理ホスト名とネットワーク・ホスト名の用語が区別されます。このガイドでは、物理ホスト名は、現行システムの内部名を表すために使用されます。UNIXでは、hostnameコマンドにより返される名前です。
スイッチオーバーとスイッチバック: 計画された操作です。通常の運用時に、システムのアクティブ・メンバーのメンテナンスまたはアップグレードが必要になることがあります。スイッチオーバー・プロセスを開始して、メンテナンス、アップグレードまたはなんらかの計画停止が必要なメンバーによって処理されているワークロードを、他のメンバーに引き継がせることができます。スイッチオーバー操作によって、システムのコンシューマにサービスを継続して提供できます。
メンテナンスやアップグレードが完了すると、スイッチバック操作を実行して、アップグレードしたメンバーをアクティブ化し、スイッチオーバー前のシステム構成に戻すことができます。
仮想IP: ネットワーク・クライアントに対してクラスタの単一システム・ビューを提供するために、クラスタのメンバーであるサーバーのグループに対して、仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPは、サーバーのロード・バランサまたはハードウェア・クラスタに割り当てることができます。
また、ロード・バランサも一連のサーバーのエントリ・ポイントとして仮想IPを使用します。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーに割り当てられるのではなく、サーバーとクライアントの間のプロキシとして機能するロード・バランサに割り当てられます。
仮想ホスト名: クラスタで、クラスタ内のいずれかのノードに常時バインドされた仮想IPに割り当てられるネットワーク・ホスト名です。
|
注意: このドキュメントで仮想ホスト名という用語を使用する場合、仮想IPアドレスに関連付けられることを前提としています。単にIPアドレスを必要とする場合または使用する場合には、その旨を明示的に記載します。 |
ハードウェア・クラスタ: コンピュータの集合であり、ネットワーク・サービス(IPアドレスなど)またはアプリケーション・サービス(データベースやWebサーバーなど)の単一のビューをこれらのサービスのクライアントに提供します。ハードウェア・クラスタ内の各ノードは、それぞれのプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは相互に通信して、アプリケーション、システム・リソースおよびデータを協調してユーザーに提供する単一のシステムのように機能します。
ハードウェア・クラスタは、専用のハードウェア(クラスタ・インターコネクト、共有記憶域)とソフトウェア(ヘルス・モニター、リソース・モニター)を使用して、高可用性とスケーラビリティを実現します。(クラスタ・インターコネクトは、ハートビート情報によりノード障害が検出される場合に、ハードウェア・クラスタで使用されるプライベート・リンクです。)専用のハードウェアとソフトウェアが必要であるため、通常、ハードウェア・クラスタはSun、HP、IBM、Dellなどのハードウェア・ベンダーによって提供されます。1つのハードウェア・クラスタ内で構成可能なノード数は、ベンダーによって異なりますが、Oracle Fusion Middlewareの高可用性では2つのノードのみを必要とします。そのため、このドキュメントでは、2つのノードを持つハードウェア・クラスタを高可用性ソリューションで使用することを前提とします。
クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアで、可用性とパフォーマンスの操作を他のノードと協調させます。クラスタウェアは、リソースのグループ化やモニタリング、およびサービスを移行させる機能を提供します。クラスタ・エージェントによって、サービスのフェイルオーバーを自動化できます。
クラスタウェア: クラスタ・メンバーの操作をシステムとして管理するソフトウェアです。これにより、クラスタ・メンバー間のハートビート・メカニズムを使用して、監視対象のリソースとサービスのセットを定義したり、これらのリソースとサービスをクラスタ内の別のメンバーにできるだけ効率的かつ透過的な方法で移動できます。
この項では、ローカル高可用性の概要およびOracle Fusion Middlewareの高可用性テクノロジについて説明します。この項の内容は次のとおりです。
ローカル高可用性ソリューションは、アクティブ/アクティブとアクティブ/パッシブいずれかのソリューションに分類できます。Oracle Fusion Middlewareでは、アクティブ/アクティブ・デプロイメントもアクティブ/パッシブ・デプロイメントもサポートされます。
図2-3に、Oracle Fusion Middlewareの高可用性のアクティブ/アクティブ・デプロイメント・トポロジを示します。
図2-3 Oracle Fusion Middlewareのエンタープライズ・ デプロイメント・アーキテクチャ
図2-3に示すように、このトポロジは複数層アーキテクチャを表しています。ユーザーはクライアント層からシステムにアクセスします。リクエストはハードウェア・ロード・バランサを通過し、そこで、Web層のOracle HTTP ServerおよびOracle Web Cacheが稼働しているWebサーバー・クラスタにルーティングされます。Webサーバーでは、プロキシ・プラグイン(mod_wl_ohs)を使用して、リクエストをアプリケーション層のWebLogicクラスタにルーティングします。次に、アプリケーション層のWebLogicクラスタで稼働しているアプリケーションが、データ層のデータベース・クラスタと対話して、リクエストに応じます。
アーキテクチャ全体で、シングル・ポイント障害はありません。第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」で説明しているように、WebLogic管理サーバーは、コールド・フェイルオーバー・クラスタ・モードで構成され、外部のクラスタウェアを使用して保護されます。
Oracle Fusion Middlewareインフラストラクチャには、次の高可用性機能があります。
プロセス障害の検出と自動再起動
WebLogic Serverで稼働するJava EEコンポーネントの場合、ノード・マネージャで管理対象サーバーを監視します。管理対象サーバーが停止すると、ノード・マネージャは、構成された回数にわたって、管理対象サーバーの再起動を試行します。
システム・コンポーネントの場合、OPMNでプロセスを監視します。システム・コンポーネント・プロセスが停止すると、OPMNは、構成された回数、再起動を試行します。
クラスタリング
Oracle Fusion MiddlewareのJava EEコンポーネントは、クラスタリングを実現するための基盤となる優れたWebLogic Serverクラスタリング機能を活用しています。Oracle Fusion Middlewareでは、冗長性、フェイルオーバー、セッション状態レプリケーション、クラスタワイドのJNDIサービス、サーバー全体の移行、クラスタワイドの構成など、WebLogicが持つクラスタリング機能を使用します。
これらの機能により、クライアントに透過的なすべてのJava EE Oracle Fusion Middlewareシステム・コンポーネントのシームレスなフェイルオーバーが実現し、セッションおよびトランザクションのデータが保持され、データの整合性も保証されます。これらの機能の詳細は、第3章「WebLogic Serverの高可用性」を参照してください。
システム・コンポーネントは、実行時クラスタにデプロイすることもできます。これらのフロントエンドには通常、トラフィックをルーティングするロード・バランサが配置されます。
状態のレプリケーションとルーティング
Oracle WebLogic Serverは、ステートフル・アプリケーションの状態をレプリケートするように構成できます。そのためには、クラスタ・メンバーである別の管理対象サーバー上で状態情報のレプリカを保持します。ADFやWebCenter Portalなど、ステートフルなOracle Fusion Middlewareコンポーネントは、この機能を活用して、クラスタの他のメンバーに対するシームレスなフェイルオーバーを保証します。
Oracle Internet Directory、Oracle HTTP Server、Oracle Web Cacheなどのシステム・コンポーネントはステートレスです。
Oracle FormsやOracle Reportsなど、いくつかのOracle Fusion Middlewareコンポーネントには、Cで実装された機能の一部があります。それらはステートフルであり、状態のレプリケーション機能はありません。これらのコンポーネントのフェイルオーバーの詳細は、次のパラグラフを参照してください。
フェイルオーバー
一般的には、Oracle Fusion MiddlewareのJava EEコンポーネントが稼働する管理対象サーバーには、Oracle HTTP ServerなどのWebサーバーがあり、管理対象サーバーの前面にクラスタ化されています。Webサーバーのプロキシ・プラグイン(mod_wl_ohs)は、様々な管理対象サーバーの実行時の可用性、および状態のレプリカが保持される管理対象サーバーの場所を認識しています。プライマリ管理対象サーバーが使用できなくなると、プラグインによって、アプリケーションが使用可能なサーバーにリクエストがルーティングされます。Oracle ADFやOracle WebCenter Portalなどのステートフル・アプリケーションの場合、新しい管理対象サーバーへのルーティング時にレプリカの場所も考慮されます。
ステートレス・システム・コンポーネントの場合、それらの複数のインスタンスは実行時クラスタとして、ロード・バランサの背後にデプロイされます。ロード・バランサは、コンポーネント・インスタンスの定期的なヘルス・チェックを実行するように構成します。インスタンスが使用できない場合、ロード・バランサは後続のリクエストを別の使用可能なインスタンスにルーティングして、フェイルオーバーをシームレスに行います。
Cをベースとした部品を持ち、状態のレプリケーションを持たないステートフル・コンポーネントの場合、スティッキーなルーティングにより、状態が最初に確立されたクラスタ・メンバーに後続のリクエストが送信されるようになります。これは、Webサーバーのプロキシ・プラグインおよびコンポーネントのJava EE部品により保証されます。コンポーネント・インスタンスに障害が発生すると、後続のリクエストは、クラスタ内の別の使用可能なメンバーにルーティングされます。このような状況では、状態情報は失われ、ユーザーはセッションを再作成する必要があります。
一部のコンポーネントの内部実装はEJBを使用します。EJBフェイルオーバーは、レプリカ対応のWebLogic Serverスタブでシームレスに処理されます。
必要に応じて、コンポーネントはJTAに準拠し、フェイルオーバーの場合にデータの整合性が保持されます。
シングルトン・サービスは、シングルトンSOAアダプタなどの組込みフェイルオーバー機能を活用するか、または、サーバー全体の移行など、基礎となるWebLogic Serverインフラストラクチャを使用します。
サーバーの移行
SOAなど、Oracle Fusion Middlewareのコンポーネントは、JMSやJTAなどの固定サービスを使用し、WebLogic Serverの機能を活用して、フェイルオーバー時に別のクラスタ・メンバー上で自動的に再起動されます。
統合された高可用性
Oracle Fusion Middlewareには、Oracle RACデータベースの可用性およびスケーラビリティを活用するため、ロード・バランシングおよびフェイルオーバーの周囲に総合的な機能セットがあります。Oracle Fusion Middlewareのすべてのコンポーネントには、計画停止または計画外停止によってOracle RACインスタンスが使用できなくなったことが原因で発生した、サービス、データまたはトランザクションの消失に対する組込みの保護が用意されています。これを実現するには、Oracle WebLogic Serverのマルチ・データ・ソースを使用します。また、障害発生時に進行中のトランザクションをシームレスにフェイルオーバーするために、コンポーネントには適切な例外処理および構成可能な再試行ロジックが用意されています。
Oracle SOAコンポーネントなど、XAに準拠したアプリケーションでは、WebLogic Serverはトランザクション・コーディネータとして機能し、トランザクションのすべてのブランチが、Oracle RACインスタンスのいずれかに固定されるようになります。
管理対象サーバーに障害が発生した場合には、トランザクション・サービスはクラスタ内の別のノードに自動的に移行され、トランザクションのリカバリが実行されます。
Webサーバーと管理対象サーバー間の通信において、プロキシ・プラグインには、組込みのロード・バランシングおよびフェイルオーバーの機能があり、使用可能なクラスタ・メンバーにクライアントのリクエストがシームレスに再ルーティングされます。
ローリング・パッチ適用
Oracle WebLogic Serverでは、ローリング・パッチを使用できます。ローリング・パッチでは、クラスタ全体を停止することなく、マイナーなメンテナンス・パッチをローリング形式で製品バイナリに適用できます。
クラスタにローリング・パッチを適用する際は、クラスタ内の各サーバーで個別にパッチを適用して再起動する一方、クラスタ内の他のサーバーではアプリケーションを引き続きホストします。パッチ、メンテナンス・パック、またはマイナー・リリースを、ローリング形式でアンインストールすることもできます。
構成管理
Oracle Fusion Middlewareコンポーネントのほとんどは、クラスタ・レベルで構成できます。Oracle Fusion Middlewareでは、データ・ソース、EJB、JMSなど、サーバーを構成するためのWebLogic Serverのクラスタワイドの構成機能、およびコンポーネントのアプリケーション・アーティファクト、ADFおよびWebCenter Portal Frameworkアプリケーションを使用します。
バックアップとリカバリ
Oracle Fusion Middlewareのバックアップとリカバリは、中間層コンポーネントのファイル・システム・コピーに基づく単純なソリューションです。Oracle DatabaseにはRMANが使用されます。オンライン・バックアップのサポートもあります。Oracle Fusion Middlewareを使用すると、バックアップとリカバリを行う既存のツールに統合するか、またはOracle Fusion Middleware Enterprise Managerまたはcronジョブを介して、スケジュールされたバックアップ・タスクを使用できます。
通常、Oracle Fusion Middlewareの高可用性デプロイメントのフロントエンドにはロード・バランサが配置され、様々なアルゴリズムを使用して受信したリクエストを分散するように構成できます。
Oracle Fusion Middlewareには、コンポーネント内で対話するための組込みのロード・バランシング機能もあります。たとえば、Webサーバーと管理対象サーバーや、管理対象サーバーとデータベース・サーバーで対話できます。
Oracle Fusion Middleware 11gでは、外部ロード・バランサは提供されていません。使用する外部ロード・バランサとOracle Fusion Middlewareとの互換性を保証するには、その外部ロード・バランサが次に示す要件を満たしていることを確認してください。
仮想サーバーとポートの構成: ロード・バランサは、外部ロード・バランサで仮想サーバー名およびポートを構成する機能を備えている必要があります。仮想サーバー名とポートは次の要件を満たす必要があります。
ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、Oracle Fusion Middleware Identity Managementの場合は、HTTP / HTTPSトラフィック用の1つの仮想サーバーとポート、およびLDAPとLDAPSトラフィック用の個別の仮想サーバーとポートでロード・バランサを構成する必要があります。
仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは、仮想サーバー名を介して外部ロード・バランサにアクセスできるようにします。
永続性/振分け: 一部のOracle Fusion Middlewareコンポーネントでは、外部ロード・バランサの永続性や振分けを使用します。使用する外部ロード・バランサで、Cookieの永続性をURIレベルで設定できない場合は、Cookieの永続性をすべてのHTTPトラフィックに設定します。いずれの場合も、ブラウザのセッションが失効するときにCookieも失効するように設定します。詳細は、使用する外部ロード・バランサのドキュメントを参照してください。
Oracle Fusion Middlewareでは、Oracle HTTP ServerのフロントエンドとしてWeb層にロード・バランサ、Oracle HTTP Serverのバックエンドとしてアプリケーション層にOracle WebLogic Serverを配置するアーキテクチャをお薦めします。
Oracle WebLogic ServerをWeb層のロード・バランサの直後に配置する場合は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のロード・バランサとWebLogicセッションCookieの項の説明を確認してください。これは、Oracle Fusion Middlewareで推奨されるデプロイメント・アーキテクチャではありません。
リソースの監視/ポートの監視/プロセス障害検出: 外部ロード・バランサを、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへのトラフィック送信を停止するように構成します。外部ロード・バランサによっては、障害の自動検出機能を備えているものもあります。
たとえば、Oracle Fusion Middleware Identity Managementでは、外部ロード・バランサでOracle Internet Directory、Oracle Fusion Middleware Single Sign-OnおよびOracle Delegated Administration Serviceを監視する必要があります。これらのコンポーネントを監視するには、次のプロトコルのモニターを設定します。
LDAPおよびLDAPS用リスニング・ポート
HTTPおよびHTTPS用リスニング・ポート(デプロイメント・タイプによる)
これらのモニターは個別のプロトコルを使用してサービスを監視します。つまり、LDAPポートにはLDAP、LDAP SSLポートにはSSL経由のLDAP、Oracle HTTP ServerポートにはHTTP/HTTPSを使用します。外部ロード・バランサがこれらのモニターを提供していない場合は、そのロード・バランサのドキュメントを参照し、着信リクエストが使用不可のサービスに自動ルーティングされないようにするための最適な構成方法を確認してください。
ネットワーク・アドレス変換(NAT): ロード・バランサには、クライアントからOracle Fusion Middlewareのノードにルーティングされるトラフィックに対するネットワーク・アドレス変換(NAT)機能が必要です。
ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。
プロトコル変換: ロード・バランサには、異なるプロトコルを実行するシステム間のプロトコル変換機能が必要です。これにより、発行元デバイスとターゲット指定されたホストに関連付けられているネイティブ・プロトコル・スタックが異なる場合も、あるネットワークに接続しているユーザーが別のネットワーク上のホストにアクセスできます。たとえば、HTTPSリクエストを受信して、HTTPリクエストを送信することができます。
この機能は推奨されますが、必須ではありません。
SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。
この機能は推奨されますが、必須ではありません。
フォルト・トレラント・モード: ロード・バランサがシステムのシングル・ポイント障害にならないように、ロード・バランサをフォルト・トレラント・モードで構成することを強くお薦めします。これにより、単一のプロセス/インターセプタに基づくほとんどのソフトウェア・ロード・バランサは、信頼できるソリューションから除外されます。
クライアントIPアドレス保持機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入する機能またはクライアントIPアドレスを保持する同様の機能が必要です。
その他: トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、すぐにコール元クライアントに戻るようロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。この構成は、クライアント・システムのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。
前述のすべての要件を満たす必要はありません。外部ロード・バランサの要件は、検討しているトポロジ、およびロード・バランシングを行うOracle Fusion Middlewareコンポーネントにより異なります。
Oracle Fusion Middlewareは、Oracle Fusion Middleware Cold Failover Clustersを使用して、すべてのコンポーネントにアクティブ/パッシブ・モデルを提供します。Oracle Fusion Middleware Cold Failover Cluster構成では、複数の管理対象サーバー・インスタンスが同じアプリケーション・ワークロードを提供するように構成されますが、アクティブとなるインスタンスは常に1つのみです。
図2-4に、アクティブ/パッシブ・デプロイメントの例を示します。
図2-4では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。Middlewareホームとドメイン・ディレクトリは、ある時点でノード1またはノード2にマウントされている共有ディスク上にあります。Middlewareホームとドメイン・ディレクトリは両方とも、同じ共有ディスク上、またはいっしょにフェイルオーバーできる複数の共有ディスク上にあります。複数のアプリケーションまたは環境用に複数のFusion Middlewareドメインがある企業では、管理サーバーの高可用性にはこのトポロジが最適です。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。それぞれの管理サーバーでは、その仮想IPおよび一連の共有ディスクを使用して、ドメイン・サービスの高可用性を実現できます。
アクティブ/パッシブの概要およびOracle Cold Failover Clustersの構成手順の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。
可能な場合は、 アクティブ/アクティブ・ソリューションの使用をお薦めします。これは最大限の可用性を実現するための第一の推奨事項です。アクティブ/アクティブ・ソリューションは、ノード、インスタンスおよびコンポーネントの障害に対して、迅速なフェイルオーバー、スケーラビリティ、および保護を提供します。さらに、アクティブ/アクティブ・ソリューションでは、透過的なフェイルオーバーが可能となり、垂直および水平スケーリングのためのリソースの追加も容易です。
Oracle Fusion Middlewareの高可用性ソリューションを設計するときは、スケーラビリティに関する要件が重要な検討事項になります。アクティブ/アクティブ・ソリューションは、同一ノード内にインスタンスやコンポーネントを追加することで(垂直に)スケール・アップします。
同一ノードに複数の冗長なサービスを追加するとシステムの可用性は向上しますが、これはノード障害ではなくインスタンス障害に対してのみ有効です。さらに、第2.3.2項「Oracle Fusion Middlewareの高可用性テクノロジ」で説明されているように、Oracle Fusion Middlewareには、コンポーネントの障害検出機能と自動再起動機能も用意されています。アクティブ/アクティブの高可用性ソリューションには、異なるノードにインストールされた複数のアクティブ・インスタンスが含まれます。その結果、1つのノードが完全に失われた場合でも、他のインスタンスが使用できるため、システムは絶え間なく稼働し続けます。異なるノードで複数のインスタンスを使用することにより、水平スケーラビリティ、すなわちスケール・アウトが提供されます。
アクティブ/アクティブ・ソリューションには、アクティブなOracle Fusion Middlewareインスタンスの間でリクエストのロード・バランシングやフェイルオーバーを行うためのロジックが必要です。ロード・バランシングは、着信リクエストを異なる複数のサービス・プロバイダに分散させることにより実現します。フェイルオーバーは、これらのサービス・プロバイダで障害を検出し、リクエストを他の使用可能なサービス・プロバイダに再ルーティングすることにより実現します。このロジックは様々な方法で実装されます。
直接的な実装: クライアントがシステムにリクエストすることによって直接実装されます。たとえば、JDBCクライアントは、Oracle Database (Real Application Cluster)の複数のインスタンスに接続するロード・バランシングおよびフェイルオーバーのロジックを実装します。外部ハードウェアのロード・バランサで実装することも可能です。
サード・パーティによる実装: クライアントのリクエストを捕捉し複数のOracleインスタンスに負荷を分散するサード・パーティのコンポーネントによって実装されます。複数のOracleインスタンスがグループ化されて連動する場合、これらのインスタンスはシステムへの単一の仮想エントリ・ポイントとして機能します。これにより複数のインスタンスの構成は隠ぺいされます。外部ロード・バランサは、クラスタ内のどの管理対象サーバー・インスタンスにもリクエストを送信できます。これは、いずれのインスタンスもすべてのリクエストを処理できるためです。
アクティブ/アクティブ構成のスケーラビリティ特性とは異なり、アクティブ/パッシブ構成ではパッシブ・コンポーネントはアクティブ・コンポーネントに障害が発生したときのみ使用されます。アクティブ/アクティブ・ソリューションでは、すべてのインスタンスがリクエストを並行に処理します。その結果、アクティブ/アクティブ・システムでは、アクティブ/パッシブ・システムよりも高い透過性と優れたスケーラビリティが提供されます。
アクティブ/パッシブ・ソリューションは、1つのノードのみがアクティブな状態で維持される垂直スケーラビリティに制限されます。アクティブ/パッシブ・ソリューションでは、障害発生時に暗黙のフェイルオーバー時間も発生します。通常、このフェイルオーバー時間は、障害後アクティブになったノードにおいてコンポーネントの再起動にかかる時間によって決まります。一方、アクティブ/パッシブ・モデルの運用コストやライセンス費用はアクティブ/アクティブ・デプロイメントよりも安価です。
状況によっては、アクティブ/パッシブ・ソリューションが適している場合があります。次のシナリオでは、ハードウェア・クラスタベースのアクティブ/パッシブ・ソリューションを使用することをお薦めします。
ロード・バランサのライセンス取得、管理、および所有権にかかわる総費用の面からアクティブ/アクティブ・ソリューションが除外される場合。特に、使用可能なハードウェア・クラスタがある場合。ハードウェア・クラスタには、2つのノード、ノードを接続するスイッチ、および両方のハードウェア・ノードから到達可能な共有記憶域が必要です。
シングルトン・サービスを保護する場合に検討すべき点について次に示します。シングルトン・サービスを使用する場合、実行時に存続できるアクティブ・インスタンスは1つだけです。シングルトン・サービスは他のコンポーネントに対して重要な場合があります。シングルトン・サービスは通常、複数のコンポーネントに対して基本的なサービスを提供するため、使用不可の場合は他の多くのサービスやプロセスが使用できなくなる可能性があります。シングルトン・サービスを保護する場合に検討すべき点について次に示します。
リカバリ時間: シングルトン・サービスまたはシングルトン・コンポーネントは、アクティブ/アクティブ構成では実行できません。クライアントのリクエストは、サービスの複数インスタンスに対して透過的にロード・バランシングされません。これは、障害が発生した場合、暗黙的なリカバリ時間を要することを意味します。このリカバリ時間は、採用するシングルトン保護モデルのタイプにより異なります。
障害検出における信頼性: 偽陽性を防止する必要があります。ほとんどのシングルトン・サービスはデータ・リポジトリにアクセスしますが、データ・リポジトリは、同時アクセス用に設計されている場合とそうでない場合があります。シングルトン・サービスが動作不能と報告され、システムが別のインスタンスを起動しようとした場合、スプリット・ブレインのシナリオが生じる可能性があります。動作不能となったサービスについては、同時実行性の影響、および障害検出のメカニズムに基づいて誤判定が生じる可能性を分析する必要があります。
再起動時のサービスの一貫性: シングルトン・コンポーネントはフェイルオーバー後も一貫したサービスを提供する必要があります。これらのコンポーネントは障害からのリカバリ後も同じ動作を持続することが要求されます。サービスで使用する構成および永続リポジトリは、障害時も使用可能でなければなりません。さらに、起動がフェイルオーバーに依存している必要があります。たとえば、シングルトン・サービスの再起動が必要となった場合、その再起動は他のサービスに依存している場合があるため、それらのサービスを維持する必要があります。
コスト(必要なハードウェア/ソフトウェア・リソース): 様々な保護メカニズムにより、純粋なソフトウェア・ベースのソリューションまたは暗黙のコストを伴うハードウェア・ベースのソリューションが必要になる場合があります。
インストール/構成/管理: シングルトン・サービス用の様々な保護メカニズムを使用することで、システムの複雑性が増加しないようにする必要があります。
メンテナンス(パッチ、アップグレード): シングルトン・サービス用の保護モデルでは、パッチやアップグレードの適用が容易にかつ最小限のダウンタイムで行われる必要があります。
これらの条件に基づき、Oracle Fusion Middleware Singleton Componentsでは、特定のシングルトン・サービスに関する要件に応じて、次のようなソリューションを使用できます。
コールド・フェイルオーバー・クラスタ・ソリューション: このソリューションでは、共有記憶域とハードウェア障害検出用の接続が必要です。フェイルオーバー・プロシージャを介したVHNの移行によるリクエストの再ルーティングには、クライアントやロード・バランサのインテリジェント機能は必要ありません。
サーバー全体の移行: 障害が発生した場合に、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを別の場所に移動するプロセスです。サーバー全体の移行の場合は、障害が発生すると、サーバー・インスタンスが物理的に別のシステムに移行されます。サービスレベルの移行の場合は、サービスをクラスタ内の別のサーバー・インスタンスに移動します。
ソフトウェア・ブロッキング・メカニズムに基づくカスタム・アクティブ/パッシブ・モデル: このロジックは、同じコンポーネントの他のインスタンスが同時にアクティブになるのを防止するコンポーネントに含まれます。一般的なソリューションでは、データベースでロックを使用するか、同時実行性を防止するメモリー内のアクティブな通知をカスタマイズします。
多くの場合、障害検出の信頼性は、1つのソリューションを別のソリューションに採用する上で重要な要因となります。これは、特に同時実行性によりシングルトン・サービスで使用されるリソースに破損が生じるような場合に当てはまります。通常、ファイルは異なるアクティブ・インスタンスで同時に書き込まれる可能性があります。
この項で説明した問題には、各種のコンポーネントに別のソリューションを採用することもできます。
図2-5に、障害時リカバリ用に構成されたOracle Fusion Middlewareのアーキテクチャを示します。Oracle Fusion Middlewareの製品バイナリ、構成ファイルおよびメタデータ・ファイルの場合、ディスク・レプリケーション・ベースのソリューションでは、NAS/SANデバイスにOracle Fusion Middlewareがデプロイされます。Oracleホームに格納されている製品バイナリおよび構成データは、ホスト・システムからマウントされた場所を使用して、NAS/SANデバイスに格納されます。また、ディスク・レプリケーション・テクノロジを使用して、本番サイトの共有記憶域システムからスタンバイ・サイトの共有記憶域システムに定期的に製品バイナリおよび構成をレプリケートします。スタンバイ・サイトのサーバーも、スタンバイ・サイトのディスクにマウントされます。本番(アクティブ)サイトに障害または計画停止が発生すると、スタンバイ(パッシブ)サイトへのレプリケーションは停止されます。その後、サービスおよびアプリケーションが、スタンバイ・サイトで開始されます。それ以降、ネットワーク・トラフィックはスタンバイ・サイトにルーティングされます。
Oracle Fusion Middlewareコンポーネントの障害時リカバリの詳細は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』を参照してください。
図2-5 Oracle Fusion Middlewareの障害時リカバリ・トポロジでの本番サイトとスタンバイ・サイト
次の表に、発生しうる計画停止および計画外停止と、それぞれに対してお薦めするソリューションを一覧表示します。表2-1は、計画停止についての説明です。
表2-1 計画停止のソリューション
| 操作 | ソリューション |
|---|---|
|
アプリケーションのデプロイと再デプロイ |
ホット・デプロイ |
|
パッチ適用 |
ローリング・パッチ適用 |
|
構成の変更 |
構成のオンライン変更 変更の通知 変更のバッチ処理 アクティブ化の延期 |
|
スケーラビリティおよびトポロジの拡張 |
クラスタのスケールアウト |
表2-2は、計画外停止についての説明です。
表2-2 計画外停止のソリューション
| 障害 | ソリューション |
|---|---|
|
ソフトウェア障害 |
Java EEコンポーネントにはノード・マネージャ、システム・コンポーネントにはOPMNを使用した障害検出および再起動 サーバー・クラスタ&ロード・バランシング コールド・フェイルオーバー・クラスタ サーバーの移行 サービスの移行 状態のレプリケーションおよびレプリカ対応スタブ |
|
ハードウェア障害 |
サーバー・クラスタ&ロード・バランシング サーバーの移行 クラスタウェアの統合 |
|
データ障害 人為的なエラー |
バックアップとリカバリ |
|
サイト障害 |
Oracle Fusion Middlewareの障害時リカバリ・ソリューション |
|
注意: このガイドで定義されているアーキテクチャとデプロイメント手順を使用することにより、単純なクラスタ・デプロイメントを実現できます。各章に記載されている手順は、このトポロジおよび他の類似する高可用性トポロジを、該当するFusion Middlewareコンポーネントで実現する場合の基礎的要素として使用できます。また、本番デプロイメントでは、セキュリティ・ポリシーと一元的なLDAPサーバーを関連付けるなど、この他にも必要な手順を使用することが予想されます。セキュアな複数層アーキテクチャおよびデプロイメント手順の詳細は、構成対象のコンポーネントのエンタープライズ・デプロイメント・ガイドを参照してください。 |
