WebLogic Server のクラスタ化の概要



\| WebLogic Server ホーム \| WebLogic Server クラスタ \| 前へ \| 次へ \| 目次 \| 索引 \| PDF 版

以下の節では、WebLogic Server クラスタについて説明します。

WebLogic Server クラスタとは

WebLogic Server クラスタはより強力で、より信頼性のあるアプリケーションプラットフォームを提供するためのサーバ群です。クラスタはそのクライアントにとって単一のサーバに見えますが、実際には、一体で機能するサーバ群です。クラスタは、単一のサーバを越える下記の 2 つの重要な機能を提供します。

スケーラビリティ : クラスタの能力は 1 つのサーバまたは 1 つのマシンに制限されません。新しいサーバをクラスタに動的に追加して能力を増大させることができます。ハードウェアがさらに必要な場合は、新しいサーバを新しいマシン上に追加できます。1 つのサーバが既存のマシンを完全に使用しきっていない場合は、そのマシンに別のサーバを追加できます。
高可用性 : クラスタは複数サーバの冗長性を利用して、クライアントを障害から保護します。クラスタ内の複数のサーバが同じサービスを提供できます。1 つのサーバで障害が発生しても、別のサーバが引き継ぎます。障害が発生したサーバから機能しているサーバへのフェイルオーバ機能によって、クライアントに対するアプリケーションの可用性が増大します。

WebLogic Server クラスタは、J2EE アプリケーションにスケーラビリティと高可用性を提供するよう設計されています。これらの機能はアプリケーションの作成者とクライアントには透過的な方法で提供されます。ただし、アプリケーションのスケーラビリティと可用性を最大にするには、プログラマと管理者がクラスタ化固有の問題を理解しておく必要があります。

クラスタ化されたサービス

クラスタ化されたサービスは、クラスタ内の複数のサーバで利用できる API とインタフェースです。WebLogic Server が提供する主なクラスタサービスは、HTTP セッションステートのクラスタ化とオブジェクトのクラスタ化の 2 つです。以降の節で説明するように、WebLogic Server では JMS 送り先と JDBC 接続のクラスタ化にも対応しています。

HTTP セッションステート

WebLogic Server は、クラスタ化されたサーブレットと JSP にアクセスするクライアントの HTTP セッションステートをレプリケートすることで、サーブレットと JSP 向けのクラスタ化サポートを提供します。HTTP セッションステートのクラスタ化のメリットを活かすには、インメモリレプリケーション、ファイルシステムの永続性、または JDBCの永続性をコンフィグレーションすることで、セッションステートを永続的にしておく必要があります。 HTTP セッションステートのレプリケーションについてでは、クラスタ化されたサーブレットと JSP 向けのインメモリレプリケーションについて説明しています。ファイルの永続性と JDBC 永続性の詳細については、『WebLogic HTTP サーブレットプログラマーズガイド』の「セッションの永続化」を参照してください。

EJB と RMI オブジェクト

EJB と RMI オブジェクトのロードバランシングとフェイルオーバは、特殊なレプリカ対応スタブを使用して処理されます。このスタブは、クラスタ全体の中でオブジェクトのインスタンスを見つけることができます。EJB と RMI オブジェクト用のレプリカ対応スタブを作成するには、適切なデプロイメントプロパティを指定するか、またはコマンドラインオプションを rmic に追加します。クラスタ化されたオブジェクトをデプロイする場合は、クラスタ内のすべてのサーバインスタンスにオブジェクトをデプロイします（均一デプロイメント）。オブジェクトのクラスタ化の詳細については、オブジェクトのクラスタ化についてを参照してください。

JMS

WebLogic の JMS アーキテクチャでは、複数の JMS サーバの「クラスタ化」を実装するため、クラスタ内のすべてのサーバから送り先へのクラスタワイドで透過的なアクセスがサポートされています。WebLogic Server は、JMS の送り先と接続ファクトリのクラスタ全体への分散をサポートしますが、JMS のキューおよびトピックはクラスタ内の個々の WebLogic Server インスタンスによって管理されます。

WebLogic JMS のクラスタ化には、次のような利点があります。

複数の接続ファクトリをコンフィグレーションし、対象を使用してそれらを WebLogic Server に割り当てることで、クラスタ内のあらゆるサーバから送り先へのクラスタワイドで透過的なアクセスを確立できます。各接続ファクトリは、複数の WebLogic Server にデプロイできます。
複数の JMS サーバをコンフィグレーションし、対象を使用してそれらを定義済みの WebLogic Server に割り当てることで、クラスタ内の複数のサーバインスタンスに送り先のロードバランシングを行うことができます。個々の JMS サーバは、ただ 1 つの WebLogic Server インスタンスにデプロイされて、一群の送り先に対する要求を処理します。

WebLogic JMS の詳細と、JMS を対象としたクラスタのサポートについては、『WebLogic JMS プログラマーズガイド』の「WebLogic JMSの概要」を参照してください。

JDBC 接続

WebLogic Server では、データソース、接続プール、マルチプールなどの JDBC オブジェクトをクラスタ化して、クラスタ環境で運用されるアプリケーションの可用性を高めることができます。JDBC オブジェクトをコンフィグレーションし、そのターゲットをクラスタに設定するとき、クラスタ用にコンフィグレーションする各 JDBC オブジェクトは、クラスタ内の各管理対象サーバ上に存在している必要があります。

データソース-クラスタ内で、外部クライアントは JNDI ツリー上の JDBC データソースを通じて接続を取得する必要があります。データソースは WebLogic Server RMI ドライバを使用して接続を獲得します。外部クライアントアプリケーション内の WebLogic データソースはクラスタに対応しているため、以前の接続のホストであったサーバインスタンスが停止した場合、クライアントは別の接続を要求できます。必ずしも従う必要はありませんが、BEA では、サーバ側のクライアントも JNDI ツリー上のデータソースを介して接続を取得する構成を推奨しています。
接続プール-接続プールは、使用の準備ができたデータベース接続のコレクションです。接続プールはその起動時に、指定された数の同じ物理データベース接続を作成します。接続プールが起動時に接続を確立することにより、各アプリケーション用にデータベース接続を作成するオーバーヘッドが解消されます。BEA では、クライアント側とサーバ側の両方のアプリケーションが、JNDI ツリー上のデータソースを通じて接続プールから接続を取得する構成を推奨しています。アプリケーションは接続が不要になった時点で、その接続を接続プールに返却します。
マルチプール-マルチプールは基本の接続プールを多重化したものです。マルチプールはアプリケーションにとっては基本のプールと同じように機能しますが、マルチプールを使用すると、接続プールのプールを確立して、接続プールごとに特性の異なる多様な接続を利用できるようになります。1 つの接続プール内の接続はすべて等質ですが、あるプールに予測される障害がマルチプール内の別のプールを巻き添えにしたりしないように、マルチプール内の接続プールごとに接続の性質はある程度異なっているのが一般的です。これらのプールは通常、同じデータベースの異なったインスタンスを接続先とします。
マルチプールが効果を発揮するのは、アプリケーションの接続を同じように処理する複数の異なったデータベースインスタンスが存在し、アプリケーションの作業が複数のデータベース間に分散されるときにアプリケーションシステムがデータベースの同期を正しく処理する場合に限られます。まれに、同じデータベースインスタンスを指す複数のプールを異なったユーザとして用意すると役に立つ場合があります。これは、DBA が他のユーザを有効にしたままある特定のユーザを無効にする場合などに役立ちます。

デフォルトでは、クラスタ化されるマルチプールは高可用性（DBMS のフェイルオーバ）を実現します。必要に応じて、ロードバランシングにも対応するようにマルチプールをコンフィグレーションすることができます。

JDBC の詳細については、『管理者ガイド』の「JDBC コンポーネント（接続プール、データソース、およびマルチプール）」を参照してください。

クラスタ化された JDBC を使用しての接続の取得

どのクラスタメンバーによってもすべての JDBC リクエストを同様に処理できることを保証するには、クラスタ内の各管理サーバのプールと（使用する場合の）マルチプールが、同じ名前を付けて同じように定義される必要があります。外部クライアントでの使用を想定する場合、データソースのターゲットをクラスタに設定することをお勧めします。これによりデータソースがクラスタ対応になり、データソースの接続をどのクラスタメンバーからも利用できるようになります。

外部クライアント接続-データベース接続を必要とする外部クライアントは JNDI ルックアップを実行し、データソースのレプリカ対応スタブを取得します。データソースのスタブには、データソースのホストであるサーバインスタンスのリスト（通常はクラスタ内のすべての管理対象サーバ）が含まれます。レプリカ対応スタブは、ホストのサーバインスタンス間で負荷を分散させるためのロードバランシングロジックを備えています。
サーバサイドクライアント接続-サーバサイドでの使用のために、アプリケーションコードでは JNDI ルックアップとデータソースの代わりにサーバサイドプールドライバを直接使用できますが、データソースが使用される場合、そのデータソースはローカルオブジェクトになります。サーバサイドのデータソースは、その JDBC 接続については別のクラスタメンバーに向かうことはありません。データソースはその参照先のプールから接続を取得します。データベーストランザクションが継続し、アプリケーションコードが接続を保持する間（接続がクローズされるまで）、接続はローカルサーバインスタンスに固定されます。

JDBC 接続のフェイルオーバとロードバランシング

JDBC オブジェクトをクラスタ化しても接続のフェイルオーバは実現されませんが、接続に障害が発生したときの再接続のプロセスを簡略化することができます。複製されたデータベース環境では、マルチプールをクラスタ化することによってデータベースのフェイルオーバを、また必要に応じて接続のロードバランシングを実現できます。詳細については、以下の各節を参照してください。

クラスタ化される JDBC オブジェクトがフェイルオーバ発生時にどのように動作するかについては、クラスタ化されたサービスのフェイルオーバサポートを参照してください。
マルチプールのクラスタ化によって接続のロードバランシングが実現されるしくみの詳細については、クラスタ化されたサービスのロードバランシングを参照してください。

クラスタ化されていないサービスと API

一部の API と内部サービスは、WebLogic Server ではクラスタ化できません。その内容は次のとおりです。

File サービス
Time サービス
WebLogic Event（WebLogic Server 6.0 より非推奨）
ワークスペース（WebLogic Server 6.0 より非推奨）
ZAC

これらのサービスは、クラスタ内の個々の WebLogic Server インスタンスでは使用できます。ただし、これらのサービスに関してロードバランシングやフェイルオーバ機能は利用できません。

WebLogic Server バージョン 6.1 のクラスタの新機能

WebLogic Server バージョン 6.1 では、Weblogic Server バージョン 5.x と比較して、サーバインスタンスのクラスタとしてコンフィグレーションする際の以下の機能と改良点を新たに取り入れました。

ロードバランシングハードウェアの統合サポート

WebLogic Server は、クライアントがサポート対象のロードバランシングハードウェアを使ってクラスタに直接アクセスする場合に、クラスタ化されたサーブレットと JSP 向けのロードバランシングとフェイルオーバをサポートするようになりました。HttpClusterServlet または WebLogic Server のプロキシプラグインを使用して HTTP リクエストをクラスタにプロキシする場合に、クラスタ化されたシステムは不要となりました。詳細については、「 HTTP セッションステートのレプリケーションについて」を参照してください。

ステートフルセッション EJB のクラスタ化

WebLogic Server は、ステートフルセッション EJB インスタンスの EJBObject（と EJBHome オブジェクト）のクラスタ化をサポートするようになりました。WebLogic Server は、HTTP セッションステートをレプリケートするのと似た方法で、ステートフルセッション EJB をメモリ内にレプリケートします。詳細については、オブジェクトのクラスタ化についてを参照してください。

クラスタ化された JMS

WebLogic Server は、クラスタ全体への JMS の送り先と接続ファクトリの配布をサポートするようになりました。ただし、JMS のトピックとキューがクラスタ内の個々の WebLogic Server インスタンスによって管理される点は変わりません。

HTTP セッションステートレプリケーションに関する変更

WebLogic Server バージョン 6.1 では、クラスタ化されたサーバインスタンス間でサーブレットのセッションステートをレプリケートするためのより堅牢なメカニズムを導入しました。以前のサーババージョンと同じく、WebLogic Server は、サーブレットのセッションステートの 2 つのコピー（プライマリとセカンダリ）をクラスタ内の別々のサーバインスタンス上で維持します。バージョン 6.1 では、次の方法によって、レプリケーションシステムを改良しました。

WebLogic Server がセッションステートのレプリカを作成する場所を、管理者が制御できるようになりました。
WebLogic Server クラスタ内でのクライアントの接続先とは無関係に、クライアントがセカンダリセッションステートにフェイルオーバできるようになりました。

これらの変更によって、より幅広いシナリオでのフェイルオーバに対応できるようになると共に、WebLogic Server がロードバランシングハードウェアと直接連携して処理を行えるようになります。詳細については、 HTTP セッションステートのレプリケーションについてを参照してください。

WebLogic Server バージョン 6.1 での管理に関する変更

以下の変更に合わせて、WebLogic Server 6.1 でクラスタを管理する方法も WebLogic Server バージョン 5.x の方法から変更されました。

マルチキャストメッセージに関する変更

複数の WebLogic Server バージョン 6.1 クラスタは、ブロードキャストメッセージの競合を起こさずに、単一のマルチキャストアドレスを「共有」できるようになりました。クラスタごとに専用のマルチキャストアドレスを割り当てる必要はありません。

ただし、ほかのアプリケーションが WebLogic Server のマルチキャストアドレスを使用しないようにする必要はあります。他のアプリケーションがクラスタのマルチキャストアドレスに対してブロードキャストする場合、クラスタ内のすべてのサーバは、それらのメッセージをデシリアライズして、クラスタ関連のメッセージでないことを調べなければなりません。これによって無用なオーバーヘッドが生まれるので、サーバが実際のクラスタ関連のブロードキャストメッセージの送信に失敗する可能性があります。

均一デプロイメント

WebLogic Server バージョン 6.1 は、クラスタ化されたオブジェクトの均一デプロイメントだけをサポートします。オブジェクトをクラスタ可能オブジェクトとしてコンパイルした場合（オブジェクトがレプリカ対応スタブを持つ場合）は、そのオブジェクトをクラスタのすべてのメンバーに対してデプロイする必要があります。

クラスタ化されていないオブジェクト（EJB と RMI クラス）は、クラスタ内の個々のサーバにデプロイできます。

管理サーバのコンフィグレーション

WebLogic Server 6.1 クラスタのコンフィグレーションはすべて、Administration Console を使用して行います。Administration Console は、クラスタのコンフィグレーション情報を 1 つの XML コンフィグレーションファイルに保存します。また、Administration Console は、クラスタメンバーへのオブジェクトおよび Web アプリケーションのデプロイメントも管理します。

WebLogic Server 6.1 のコンフィグレーション全般については、『管理者ガイド』を参照してください。Administration Console を使用したクラスタのコンフィグレーションについては、「 WebLogic クラスタの管理」を参照してください。