|
|
この章では、WebLogic Server クラスタの概要について簡単に説明します。説明する内容は以下のとおりです。
WebLogic Server クラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数の WebLogic Server サーバ インスタンスで構成されます。クラスタはクライアントからは単一の WebLogic Server インスタンスのように見えます。クラスタを構成する複数のサーバ インスタンスは同じマシン上で実行することも、複数のマシンに分散配置することもできます。クラスタの能力は、既存のマシン上のクラスタにサーバ インスタンスを追加することによって強化できます。また、新たにサーバ インスタンスを配置するためのマシンをクラスタに追加することもできます。クラスタ内の各サーバ インスタンスでは、同じバージョンの WebLogic Server が動作している必要があります。
クラスタは特定の WebLogic Server ドメインの一部です。
ドメインとは、関連性があり 1 つの単位として管理される WebLogic Server リソースの集合のことです。ドメインには 1 つ以上の WebLogic Server インスタンスが含まれます。これらのインスタンスはクラスタ構成にも非クラスタ構成にもでき、クラスタ化されたインスタンス群とそうでないインスタンス群を組み合わせて構成することもできます。ドメインには、複数のクラスタを構成できます。またドメインには、ドメインにデプロイされるアプリケーション コンポーネントと、それらのアプリケーション コンポーネントおよびドメイン内のサーバ インスタンスが必要とするリソースおよびサービスも含まれます。アプリケーションおよびサーバ インスタンスで使用されるリソースとサービスの例には、マシン定義、オプションのネットワーク チャネル、コネクタ、起動クラスなどがあります。
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 では、セッション レプリケーションおよびレプリカ対応スタブと呼ばれる技術を利用して、ステートについての情報を保持します。レプリケーション技術により、特定のオブジェクトが不意にそのジョブの実行を停止したとき、障害を起こしたオブジェクトがどこで停止したかをオブジェクトの別のコピーが認識し、代わりにそのジョブを完了することが可能になります。
サーバの移行プロセスによって、管理対象サーバがそのまま全部 (IP アドレス、およびホストされるアプリケーションを含む)、定義済みの使用可能なホスト マシンの 1 つに再配置されます。
ロード バランシングとは、環境内のコンピューティング リソースおよびネットワーキング リソース間で、ジョブとそれに関連する通信を均等に分配することです。ロード バランシングを行うためには、以下の条件が満たされている必要があります。
WebLogic Server での通信およびレプリケーション技術の利用形態について、詳しくは「クラスタでの通信」を参照してください。
クラスタ化されるアプリケーションまたはアプリケーション コンポーネントは、クラスタ内の複数の WebLogic Server インスタンス上で利用可能なものです。オブジェクトをクラスタ化すると、そのオブジェクトに対してフェイルオーバとロード バランシングが有効になります。クラスタの管理、保守、およびトラブルシューティングの手順を簡素化するには、オブジェクトを均一に、つまりクラスタ内のすべてのサーバ インスタンスにデプロイします。
Web アプリケーションは、エンタープライズ JavaBeans (EJB)、サーブレット、Java Server Pages (JSP) などを含むさまざまな種類のオブジェクトで構成できます。それぞれのオブジェクトの種類ごとに、制御、呼び出し、およびアプリケーション内部での機能に関連する動作のユニークな集合が定義されています。この理由から、クラスタ化をサポートし、またその結果としてロード バランシングとフェイルオーバを実現するために WebLogic Server で利用される手法は、オブジェクトの種類ごとに異なる可能性があります。WebLogic Server のデプロイメントでは、次の種類のオブジェクトのクラスタ化が可能です。
種類の異なるオブジェクト間で、一部の動作が共通している可能性があります。その場合、類似したオブジェクト タイプについては、クラスタ化のサポートおよび実装上の考慮事項が一致することがあります。以下の節では、次のオブジェクト タイプの組み合わせ別に説明および手順を示しています。
以下の節では、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 オブジェクトをコンフィグレーションするときに、それらをクラスタに割り当てます。
JDBC の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「WebLogic JDBC リソースのコンフィグレーション」を参照してください。
JDBC リクエストをどのクラスタ メンバーでも処理できるようにするには、クラスタ内の各管理対象サーバが、同じように命名または定義されたデータ ソース、および可能であればマルチ データ ソースを持つ必要があります。このためには、データ ソースおよびマルチ データ ソースはクラスタを対象とする必要があります。これによりデータ ソースおよびマルチ データ ソースはクラスタ対応となり、外部クライアントで使用することを想定した場合にどのクラスタ メンバーへの接続も可能になります。
JDBC オブジェクトをクラスタ化しても接続のフェイルオーバは有効になりませんが、接続に障害が発生した場合の再接続のプロセスを簡略化することができます。レプリケートされたデータベース環境では、データベースのフェイルオーバ、および必要に応じて接続のロード バランシングをサポートするために、マルチ データ ソースをクラスタ化できます。詳細については、以下のトピックを参照してください。
WebLogic JMS (Java Messaging Service) のアーキテクチャでは、クラスタ内のあらゆる WebLogic Server サーバ インスタンスから送り先への透過的なアクセスをクラスタ全体でサポートすることによって、複数の JSP サーバのクラスタ化を実装しています。WebLogic Server では、JMS の送り先および接続ファクトリをクラスタ全体に分散させることができますが、同じ JMS トピックまたは JMS キューは引き続き、クラスタ内の個々の WebLogic Server インスタンスによって個別に管理されます。
ロード バランシングは JMS に対してサポートされています。ロード バランシングを有効にするには、JMS サーバの対象をコンフィグレーションする必要があります。ロード バランシングと JMS コンポーネントの詳細については、「JMS のロード バランシング」を参照してください。クラスタ化された JMS の設定手順については、「固定サービスの移行可能対象をコンフィグレーションする」および「移行可能サービスをデプロイ、アクティブ化、および移行する」を参照してください。
以下の API および内部サービスは、WebLogic Server でクラスタ化できません。
これらのサービスは、クラスタ内の個々の WebLogic Server インスタンスでは使用できます。ただし、これらのサービスに関してロード バランシングやフェイルオーバ機能は利用できません。
  
|
