| Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方 11g リリース 1 (10.3.1) B55518-01 |
|
 戻る |
 次へ |
この章では、WebLogic Server クラスタの概要について簡単に説明します。説明する内容は以下のとおりです。
WebLogic Server クラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数の WebLogic Server サーバ インスタンスで構成されます。クラスタはクライアントからは単一の WebLogic Server インスタンスのように見えます。クラスタを構成する複数のサーバ インスタンスは同じマシン上で実行することも、複数のマシンに分散配置することもできます。クラスタの能力は、既存のマシン上のクラスタにサーバ インスタンスを追加することによって強化できます。また、新たにサーバ インスタンスを配置するためのマシンをクラスタに追加することもできます。クラスタ内の各サーバ インスタンスでは、同じバージョンの WebLogic Server が動作している必要があります。
クラスタは特定の WebLogic Server ドメインの一部です。
ドメインとは、関連性があり 1 つの単位として管理される WebLogic Server リソースの集合のことです。ドメインには 1 つ以上の WebLogic Server インスタンスが含まれます。これらのインスタンスはクラスタ構成にも非クラスタ構成にもでき、クラスタ化されたインスタンス群とそうでないインスタンス群を組み合わせて構成することもできます。ドメインには、複数のクラスタを構成できます。またドメインには、ドメインにデプロイされるアプリケーション コンポーネントと、それらのアプリケーション コンポーネントおよびドメイン内のサーバ インスタンスが必要とするリソースおよびサービスも含まれます。アプリケーションおよびサーバ インスタンスで使用されるリソースとサービスの例には、マシン定義、オプションのネットワーク チャネル、コネクタ、起動クラスなどがあります。
WebLogic Server インスタンスは、さまざまな基準によってドメインに分類できます。たとえば、稼働するアプリケーションの論理区分、地理的な考慮事項、あるいは管理対象リソースの数または複雑さに基づいて、複数のドメインにリソースを選択的に割り当てることができます。ドメインの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ドメインのコンフィグレーションについて』を参照してください。
各ドメイン内で、1 つの WebLogic Server インスタンスが管理サーバとして機能します。このサーバ インスタンスでは、ドメイン内のその他のサーバ インスタンスおよびリソースのすべてをコンフィグレーション、管理、およびモニタします。各管理サーバでは 1 つのドメインだけを管理します。ドメインに複数のクラスタが含まれる場合、ドメイン内の各クラスタは同じ管理サーバによって管理されます。
あるクラスタ内のすべてのサーバ インスタンスは同じドメイン内になければなりません。クラスタを複数のドメインに「分割する」ことはできません。同様に、コンフィグレーション対象のリソースまたはサブシステムを複数のドメイン間で共有することはできません。たとえば、あるドメインで JDBC 接続プールを作成した場合、別のドメインのサーバ インスタンスまたはクラスタでその接続プールを使用することはできません (代わりに、2 番目のドメインで同様の接続プールを作成する必要があります)。
クラスタ化される WebLogic Server インスタンスの動作は、フェイルオーバとロード バランシングの機能を備えること以外は、クラスタ化されないインスタンスと同様です。クラスタ化される WebLogic Server インスタンスのコンフィグレーションに使用するプロセスおよびツールは、クラスタ化されないインスタンスの場合と同じです。ただし、クラスタ化によって可能になるロード バランシングとフェイルオーバの効果を実現するためには、クラスタのコンフィグレーションに関する特定のガイドラインに従う必要があります。
WebLogic Server で使用されるフェイルオーバおよびロード バランシングのメカニズムと、個別のコンフィグレーション オプションとの関係については、「クラスタでのロード バランシング」および「クラスタのフェイルオーバとレプリケーション」を参照してください。
コンフィグレーション上の推奨事項については、「WebLogic クラスタの設定」の手順説明で詳しく示しています。
WebLogic Server クラスタを利用することによってもたらされる利点には、以下のものがあります。
スケーラビリティ
WebLogic Server クラスタにデプロイされるアプリケーションの能力を、必要に応じて動的に増強することができます。サービスを中断させることなく、つまり、クライアントおよびエンド ユーザへの影響なしにアプリケーションを動作させ続けながら、クラスタにサーバ インスタンスを追加できます。
高可用性
WebLogic Server クラスタでは、サーバ インスタンスで障害が発生してもアプリケーションの処理を継続できます。アプリケーション コンポーネントの「クラスタ化」は、クラスタ内の複数のサーバ インスタンス上にコンポーネントをデプロイすることによって行います。そのため、コンポーネントが動作しているサーバ インスタンスに障害が発生した場合、同じコンポーネントがデプロイされている別のサーバ インスタンスがアプリケーションの処理を継続できます。
WebLogic Server インスタンスのクラスタ化は、アプリケーション開発者およびクライアントからは意識されません。ただし、クラスタ化を可能にする技術インフラストラクチャを理解しておくことは、プログラマおよび管理者が、各自が扱うアプリケーションのスケーラビリティと可用性を最大限に高める上で役立ちます。
この節では、スケーラビリティと高可用性を実現する重要なクラスタ化の機能を、技術的でない分かりやすい用語で定義します。
アプリケーションのフェイルオーバ
フェイルオーバは単純に言うと、特定の「ジョブ」、つまり何らかの処理タスクの集合を実行しているアプリケーション コンポーネント (以下の節では一般に「オブジェクト」と呼称します) が何らかの理由によって使用不可になったときに、障害を起こしたオブジェクトのコピーがそのジョブを引き継いで完了することを意味します。
障害を起こしたオブジェクトの処理を新しいオブジェクトが引き継ぐためには、以下の条件が満たされている必要があります。
ジョブを引き継ぐことのできる、障害を起こしたオブジェクトのコピーが存在していること。
すべてのオブジェクトの場所および動作状態を定義する情報が、他のオブジェクトと、フェイルオーバを管理するプログラムから参照できること。この情報は、最初のオブジェクトがそのジョブを完了する前に障害を起こしたことを特定するために必要です。
実行中のジョブの進捗状況についての情報が、他のオブジェクトと、フェイルオーバを管理するプログラムから参照できること。中断されたジョブを引き継ぐオブジェクトは、この情報を基に、最初のオブジェクトで障害が発生した時点でジョブがどの程度完了しているか (たとえば、どのデータが変更され、プロセス内のどの手順が完了しているか) を認識します。
WebLogic Server では、標準に基づいた通信技術および通信機能である IP ソケット、および JNDI (Java Naming and Directory Interface) を利用して、クラスタ内のオブジェクトの可用性に関する情報を共有および保持します。WebLogic Server ではこれらの技術によって、ジョブを完了する前にオブジェクトが停止したことと、中断されたジョブを完了するためのオブジェクトのコピーが存在する場所を特定します。
|
注意 : 以前のバージョンの WebLogic Server との互換性を維持するため、クラスタ間の通信にマルチキャストを使用することも可能です。 |
あるジョブに関してどのような処理が完了しているかについての情報をステートと呼びます。WebLogic Server では、セッション レプリケーションおよびレプリカ対応スタブと呼ばれる技術を利用して、ステートについての情報を保持します。レプリケーション技術により、特定のオブジェクトが不意にそのジョブの実行を停止したとき、障害を起こしたオブジェクトがどこで停止したかをオブジェクトの別のコピーが認識し、代わりにそのジョブを完了することが可能になります。
WebLogic Server では、クラスタに属するサーバ インスタンスを、あるマシンから別のマシンに、自動的にまたは手動で移行することができます。移行できる管理対象サーバは、移行可能なサーバと呼ばれます。この機能は、高可用性が求められる環境に向けて設計されています。このサーバ移行機能は、以下のことの実現に役立ちます。
ホストとなるサーバ インスタンスで障害が発生した場合のシングルトン サービスの中断のない可用性の保証。シングルトン サービスとは、常に 1 つのサーバ インスタンス上のみで実行されなければならないサービス (JMS や JTA トランザクション回復システムなど) のことです。障害が発生した場合、自動移行がコンフィグレーションされている管理対象サーバは別のマシンに自動的に移行されます。
管理対象サーバとそれがホストするすべてのサービスを計画的なシステム管理プロセスの一部として再配置する場合のプロセスの簡略化。管理者は Administration Console またはコマンドラインから管理対象サーバの移行を開始できます。
サーバの移行プロセスによって、管理対象サーバがそのまま全部 (IP アドレス、およびホストされるアプリケーションを含む)、定義済みの使用可能なホスト マシンの 1 つに再配置されます。
ロード バランシング
ロード バランシングとは、環境内のコンピューティング リソースおよびネットワーキング リソース間で、ジョブとそれに関連する通信を均等に分配することです。ロード バランシングを行うためには、以下の条件が満たされている必要があります。
特定のジョブを実行できるオブジェクトの複数のコピーが存在していること。
すべてのオブジェクトの場所および動作状態についての情報が入手できること。
WebLogic Server では、オブジェクトをクラスタ化、つまり複数のサーバ インスタンス上にデプロイすることにより、同じジョブを実行する代替オブジェクトを用意することができます。WebLogic Server は、デプロイされるオブジェクトの可用性および場所の情報を、ユニキャスト、IP ソケット、および JNDI を利用して共有し、保持します。
|
注意 : 以前のバージョンの WebLogic Server との互換性を維持するため、クラスタ間の通信にマルチキャストを使用することも可能です。 |
WebLogic Server での通信およびレプリケーション技術の利用形態について、詳しくは「クラスタでの通信」を参照してください。
クラスタ化されるアプリケーションまたはアプリケーション コンポーネントは、クラスタ内の複数の WebLogic Server インスタンス上で利用可能なものです。オブジェクトをクラスタ化すると、そのオブジェクトに対してフェイルオーバとロード バランシングが有効になります。クラスタの管理、保守、およびトラブルシューティングの手順を簡素化するには、オブジェクトを均一に、つまりクラスタ内のすべてのサーバ インスタンスにデプロイします。
Web アプリケーションは、エンタープライズ JavaBeans (EJB)、サーブレット、Java Server Pages (JSP) などを含むさまざまな種類のオブジェクトで構成できます。それぞれのオブジェクトの種類ごとに、制御、呼び出し、およびアプリケーション内部での機能に関連する動作のユニークな集合が定義されています。この理由から、クラスタ化をサポートし、またその結果としてロード バランシングとフェイルオーバを実現するために WebLogic Server で利用される手法は、オブジェクトの種類ごとに異なる可能性があります。WebLogic Server のデプロイメントでは、次の種類のオブジェクトのクラスタ化が可能です。
サーブレット
JSP
EJB
Remote Method Invocation (RMI) オブジェクト
Java Messaging Service (JMS) の送り先
Java Database Connectivity (JDBC) 接続
種類の異なるオブジェクト間で、一部の動作が共通している可能性があります。その場合、類似したオブジェクト タイプについては、クラスタ化のサポートおよび実装上の考慮事項が一致することがあります。以下の節では、次のオブジェクト タイプの組み合わせ別に説明および手順を示しています。
サーブレットと JSP
EJB と RMI オブジェクト
以下の節では、WebLogic Server でのクラスタ化、フェイルオーバ、およびロード バランシングのサポートについて、オブジェクトのタイプ別に簡単に説明します。
WebLogic Server は、クラスタ化されたサーブレットと JSP にアクセスするクライアントの HTTP セッション ステートをレプリケートすることで、サーブレットと JSP 向けのクラスタ化サポートを提供します。WebLogic Server では、HTTP セッション ステートをメモリ、ファイルシステム、またはデータベースに保持できます。
サーブレットまたは JSP の自動フェイルオーバを有効にするには、セッション ステートをメモリに保持する必要があります。サーブレットまたは JSP でのフェイルオーバの仕組み、および関連する要件とプログラミングにおける考慮事項については、「HTTP セッション ステートのレプリケーション」を参照してください。
WebLogic Server プロキシ プラグインまたは外部ロード バランシング ハードウェアを使用して、クラスタ間でのサーブレットおよび JSP のロード バランシングが可能になります。WebLogic Server プロキシ プラグインは、ラウンドロビンのロード バランシングを実行します。外部のロード バランサは通常、さまざまなセッション ロード バランシング メカニズムをサポートしています。詳細については、「サーブレットと JSP のロード バランシング」を参照してください。
EJB と RMI オブジェクトのロード バランシングとフェイルオーバは、レプリカ対応スタブを使用して処理されます。このスタブは、クラスタ全体の中からオブジェクトのインスタンスを見つけ出すためのメカニズムです。レプリカ対応スタブは、オブジェクトのコンパイル処理の結果として EJB および RMI オブジェクトに対して作成されます。EJB と RMI オブジェクトは均一に、つまりクラスタ内のすべてのサーバ インスタンスにデプロイされます。
EJB と RMI オブジェクトのフェイルオーバは、オブジェクトのレプリカ対応スタブを使用して実現されます。クライアントがレプリカ対応スタブを通じて障害が発生したサービスに対して呼び出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼び出しを再試行します。さまざまな種類のオブジェクトに対するフェイルオーバのサポートについては、「EJB と RMI のレプリケーションとフェイルオーバ」を参照してください。
WebLogic Server クラスタは、クラスタ化される EJB および RMI オブジェクト間でロード バランシングを行うための複数のアルゴリズム (ラウンドロビン、重みベース、ランダム、ラウンドロビン アフィニティ、重みベース アフィニティ、およびランダム アフィニティ) をサポートしています。デフォルトでは、WebLogic Server クラスタはラウンドロビン方式を使用します。Administration Console で、他の方式を使用するようにクラスタをコンフィグレーションできます。選択した方式は、クラスタ化されたオブジェクト用に取得したレプリカ対応スタブの内部で保持されます。詳細については、「EJB と RMI オブジェクトのロード バランシング」を参照してください。
WebLogic Server では、クラスタがホストとなるアプリケーションの可用性を向上させるために、データ ソースやマルチ データ ソースなどの JDBC オブジェクトをクラスタ化できます。クラスタ用にコンフィグレーションする各 JDBC オブジェクトは、クラスタ内の各管理対象サーバに存在する必要があります。JDBC オブジェクトをコンフィグレーションするときに、それらをクラスタに割り当てます。
データ ソース - クラスタ内で、外部クライアントは、JNDI ツリー内の JDBC データ ソースを介して接続を取得する必要があります。データ ソースは、WebLogic Server RMI ドライバを使用して接続を取得します。外部クライアント アプリケーションの WebLogic データ ソースはクラスタ対応なので、接続をホストするサーバ インスタンスに障害が発生した場合、クライアントは別の接続を要求できます。必須ではありませんが、サーバサイド クライアントも JNDI ツリー内のデータ ソースを介して接続を取得することをお勧めします。
マルチ データ ソース - マルチ データ ソースは、マルチ データ ソースと関連付けられたデータ ソース間のロード バランシングまたはフェイルオーバ処理を提供する、データ ソースのグループ周辺を抽象化したものです。マルチ データ ソースは、データ ソースが JNDI ツリーにバインドされるのと同じように、JNDI ツリーまたはローカル アプリケーション コンテキストにバインドされます。アプリケーションは、データ ソースの場合と同じように JNDI ツリー上のマルチ データ ソースをルックアップし、その後データベース接続を要求します。マルチ データ ソースは、そのマルチ データ ソースのコンフィグレーション内で選択されるアルゴリズムに応じて、要求を満たすためにロード バランシングとフェイルオーバのうちどちらのデータ ソースを使用するかを決定します。
JDBC の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「WebLogic JDBC リソースのコンフィグレーション」を参照してください。
JDBC リクエストをどのクラスタ メンバーでも処理できるようにするには、クラスタ内の各管理対象サーバが、同じように命名または定義されたデータ ソース、および可能であればマルチ データ ソースを持つ必要があります。このためには、データ ソースおよびマルチ データ ソースはクラスタを対象とする必要があります。これによりデータ ソースおよびマルチ データ ソースはクラスタ対応となり、外部クライアントで使用することを想定した場合にどのクラスタ メンバーへの接続も可能になります。
外部クライアント接続 - データベース接続を必要とする外部クライアントは、JNDI ルックアップを実行し、データ ソースのレプリカ対応スタブを取得します。データ ソースのスタブには、データ ソースのホストとなるサーバ インスタンス (クラスタ内の全管理対象サーバ) のリストが格納されています。レプリカ対応スタブには、ホスト サーバ インスタンス間に負荷を分散するためのロード バランシング ロジックが含まれています。
サーバサイド クライアント接続 - サーバサイドで使用する場合、接続リクエストはデータ ソースまたはマルチ データ ソースのローカル インスタンスで処理されます。サーバサイド データ ソースは、その JDBC 接続については別のクラスタ メンバーに向かうことはありません。データベース トランザクションの間、およびアプリケーション コードがそれを保持している間 (接続が閉じられるまで)、接続はローカル サーバ インスタンスに固定されます。
JDBC オブジェクトをクラスタ化しても接続のフェイルオーバは有効になりませんが、接続に障害が発生した場合の再接続のプロセスを簡略化することができます。レプリケートされたデータベース環境では、データベースのフェイルオーバ、および必要に応じて接続のロード バランシングをサポートするために、マルチ データ ソースをクラスタ化できます。詳細については、以下のトピックを参照してください。
クラスタ化された JDBC オブジェクトの障害発生時の動作については、「フェイルオーバと JDBC 接続」を参照。
マルチ データ ソースのクラスタ化によって接続のロード バランシングが実現される仕組みについては、「JDBC 接続のロード バランシング」を参照。
クラスタ化された JDBC オブジェクトのコンフィグレーション手順については、「クラスタ化された JDBC をコンフィグレーションする」を参照。
WebLogic JMS (Java Messaging Service) のアーキテクチャでは、クラスタ内のあらゆる WebLogic Server サーバ インスタンスから送り先への透過的なアクセスをクラスタ全体でサポートすることによって、複数の JMS サーバのクラスタ化を実装しています。WebLogic Server では、JMS の送り先および接続ファクトリをクラスタ全体に分散させることができますが、同じ JMS トピックまたは JMS キューは引き続き、クラスタ内の個々の WebLogic Server インスタンスによって個別に管理されます。
ロード バランシングは JMS に対してサポートされています。ロード バランシングを有効にするには、JMS サーバの対象をコンフィグレーションする必要があります。ロード バランシングと JMS コンポーネントの詳細については、「JMS のロード バランシング」を参照してください。クラスタ化された JMS の設定手順については、「固定サービスの移行可能対象をコンフィグレーションする」および「移行可能サービスをデプロイ、アクティブ化、および移行する」を参照してください。
