| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server クラスタ ユーザーズ ガイド > WebLogic Server クラスタ化の概要 |
|
WebLogic Server クラスタ ユーザーズ ガイド
|
この章では、WebLogic Server クラスタの概要について簡単に説明します。説明する内容は以下のとおりです。
WebLogic Server クラスタは、同時に動作し、共同で高度なスケーラビリティと信頼性を実現する WebLogic Server プログラムの複数のコピーで構成されます。クラスタはクライアントからは単一の WebLogic Server インスタンスのように見えます。クラスタを構成する複数のサーバ インスタンスは同じマシン上で実行することも、複数のマシンに分散配置することもできます。クラスタの能力は、既存のマシン上のクラスタにサーバ インスタンスを追加することによって強化できます。 また、新たにサーバ インスタンスを配置するためのマシンをクラスタに追加することもできます。クラスタ内の各サーバ インスタンスでは、同じバージョンの WebLogic Server が動作している必要があります。
クラスタは特定の WebLogic Server ドメインの一部です。
ドメインとは、関連性があり 1 つの単位として管理される WebLogic Server リソースの集合のことです。ドメインには 1 つ以上の WebLogic Server インスタンスが含まれます。 これらのインスタンスはクラスタ構成にも非クラスタ構成にもでき、クラスタ化されたインスタンス群とそうでないインスタンス群を組み合わせて構成することもできます。ドメインには、複数のクラスタを構成できます。またドメインには、ドメインにデプロイされるアプリケーション コンポーネントと、それらのアプリケーション コンポーネントおよびドメイン内のサーバ インスタンスが必要とするリソースおよびサービスも含まれます。アプリケーションおよびサーバ インスタンスで使用されるリソースとサービスの例には、マシン定義、オプションのネットワーク チャネル、コネクタ、スタートアップ クラスなどがあります。
WebLogic Server インスタンスは、さまざまな基準によってドメインに分類できます。たとえば、稼働するアプリケーションの論理区分、地理的な考慮事項、あるいは管理対象リソースの数または複雑さに基づいて、複数のドメインにリソースを選択的に割り当てることができます。ドメインの詳細については、『WebLogic Server ドメイン管理』を参照してください。
各ドメイン内で、1 つの WebLogic Server インスタンスが管理サーバとして機能します。 このサーバ インスタンスでは、ドメイン内のその他のサーバ インスタンスおよびリソースのすべてをコンフィグレーション、管理、およびモニタします。各管理サーバでは 1 つのドメインだけを管理します。ドメインに複数のクラスタが含まれる場合、ドメイン内の各クラスタは同じ管理サーバによって管理されます。
あるクラスタ内のすべてのサーバ インスタンスは同じドメイン内になければなりません。クラスタを複数のドメインに「分割する」ことはできません。同様に、コンフィグレーション対象のリソースまたはサブシステムを複数のドメイン間で共有することはできません。たとえば、あるドメイン内に JDBC 接続プールを作成する場合、別のドメイン内のサーバ インスタンスまたはクラスタからその接続プールを使用することはできません (代わりに、そのサーバ インスタンスまたはクラスタが属するドメイン内に同様の接続プールを作成する必要があります)。
クラスタ化される WebLogic Server インスタンスの動作は、フェイルオーバとロード バランシングの機能を備えること以外は、クラスタ化されないインスタンスと同様です。クラスタ化される WebLogic Server インスタンスのコンフィグレーションに使用するプロセスおよびツールは、クラスタ化されないインスタンスの場合と同じです。ただし、クラスタ化によって可能になるロード バランシングとフェイルオーバの効果を実現するためには、クラスタのコンフィグレーションに関する特定のガイドラインに従う必要があります。
WebLogic Server で使用されるフェイルオーバおよびロード バランシングのメカニズムと、個別のコンフィグレーション オプションとの関係については、クラスタでのロード バランシングおよびクラスタのフェイルオーバとレプリケーションを参照してください。
コンフィグレーション上の推奨事項については、WebLogic クラスタの設定の手順説明で詳しく示しています。
WebLogic Server クラスタを利用することによってもたらされる利点には、以下のものがあります。
WebLogic Server インスタンスのクラスタ化は、アプリケーション開発者およびクライアントからは意識されません。ただし、クラスタ化を可能にする技術インフラストラクチャを理解しておくことは、プログラマおよび管理者が、各自が扱うアプリケーションのスケーラビリティと可用性を最大限に高める上で役立ちます。
この節では、スケーラビリティと高可用性を実現する重要なクラスタ化の機能を、技術的でない観点から定義します。
フェイルオーバは単純に言うと、特定の「ジョブ」、つまり何らかの処理タスクの集合を実行しているアプリケーション コンポーネント (以下の節では一般に「オブジェクト」と呼称します) が何らかの理由によって使用不可になったときに、障害を起こしたオブジェクトのコピーがそのジョブを引き継いで完了することを意味します。
WebLogic Server では、標準に基づいた通信技術および通信機能であるマルチキャスト、IP ソケット、および JNDI (Java Naming and Directory Interface) を利用して、クラスタ内のオブジェクトの可用性に関する情報を共有および維持します。WebLogic Server ではこれらの技術によって、ジョブを完了する前にオブジェクトが停止したことと、中断されたジョブを完了するためのオブジェクトのコピーが存在する場所を特定します。
あるジョブに関してどのような処理が完了しているかについての情報をステートと呼びます。WebLogic Server では、セッション レプリケーションおよびレプリカ対応スタブと呼ばれる技術を利用して、ステートについての情報を維持します。レプリケーション技術により、特定のオブジェクトが不意にそのジョブの実行を停止したとき、障害を起こしたオブジェクトがどこで停止したかをオブジェクトの別のコピーが認識し、代わりにそのジョブを完了することが可能になります。
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 オブジェクトをコンフィグレーションする場合は、各オブジェクトの対象をクラスタにします。
マルチプールは、アプリケーション接続を同じように処理できる、複数の異なるデータベース インスタンスがある場合にのみ役立ちます。アプリケーション システムでは、アプリケーションの作業がデータベース間に分散されている場合に、データベースの同期化を行います。同じデータベース インスタンスに対する複数のプールを異なるユーザとして持つと便利な場合もあります。これは、DBA があるユーザを無効にし、別のユーザを有効にしている場合に便利です。
デフォルトでは、クラスタ化されたプールは高可用性 (DBMS フェイルオーバ) を提供しますロード バランシングを提供するためにマルチプールをコンフィグレーションすることもできます。
JDBC の詳細については、『管理者ガイド』の「JDBC コンポーネント (接続プール、データ ソース、およびマルチプール)」を参照してください。
JDBC リクエストをどのクラスタ メンバーでも処理できるようにするには、クラスタ内の各管理対象サーバが、同じように命名または定義されたプール、および可能であればマルチプールを持つ必要があります。外部クライアントで使用することを想定したデータ ソースの場合は、クラスタを対象とする必要があります。これによりデータ ソースはクラスタ対応となり、どのクラスタ メンバーへの接続も可能になります。
JDBC オブジェクトをクラスタ化しても接続のフェイルオーバは有効になりませんが、接続に障害が発生した場合の再接続のプロセスを簡略化することができます。レプリケートされたデータベース環境では、データベースのフェイルオーバ、および必要に応じて接続のロード バランシングをサポートするために、マルチプールをクラスタ化できます。詳細については、以下のトピックを参照してください。
WebLogic JMS (Java Messaging Service) のアーキテクチャでは、クラスタ内のあらゆる WebLogic Server サーバ インスタンスから送り先への透過的なアクセスをクラスタ全体でサポートすることによって、複数の JSP サーバのクラスタ化を実装しています。WebLogic Server では、JMS の送り先および接続ファクトリをクラスタ全体に分散させることができますが、同じ JMS トピックまたは JMS キューは引き続き、クラスタ内の個々の WebLogic Server インスタンスによって個別に管理されます。
ロード バランシングは JMS に対してサポートされています。ロード バランシングを有効にするには、JMS サーバの対象をコンフィグレーションする必要があります。ロード バランシングと JSM コンポーネントの詳細については、JMS のロード バランシングを参照してください。クラスタ化された JMS の設定手順については、固定サービスの移行可能対象をコンフィグレーションするおよび移行可能サービスをデプロイ、活性化、および移行するを参照してください。
自動フェイルオーバは、このリリースの WebLogic JMS ではサポートされていません。
以下の API および内部サービスは、WebLogic Server でクラスタ化できません。
これらのサービスは、クラスタ内の個々の WebLogic Server インスタンスでは使用できます。ただし、これらのサービスに関してロード バランシングやフェイルオーバ機能は利用できません。
WebLogic Server 7.0 の新しいクラスタ化機能
以降の節では、クラスタ化に関連する WebLogic Server 7.0 の新機能について説明します。
1 台のマシン上で 1 つの IP アドレスを使用してクラスタを作成可能
WebLogic Server 7.0 では、サーバ インスタンスがリスン アドレスを共有するものの異なるリスン ポートを使用するクラスタを設定し、クラスタ内の複数のサーバ インスタンスが単一の非マルチホーム マシンに存在するようにすることができます。1 台のマシン上で 1 つの IP アドレスだけでクラスタを設定できることにより、設定とサポートが容易になるため、この機能はデモンストレーション、開発、およびテスト用の環境で役立ちます。
旧リリースのクラスタでは、各サーバ インスタンスが異なるリスン アドレス、同じリスン ポート番号を持っていなければなりませんでした。1 台のコンピュータ上にクラスタを作成するには、1 台のコンピュータ上で複数の IP アドレスを使用するマルチホーム環境を設定する必要がありました。
また必要であれば、以前のリリースと同様に、1 台のマシン上で複数の IP アドレスと 1 つのリスン ポート番号を使用してクラスタを設定することもできます。
クラスタ内の複数のサーバ インスタンスで 1 つの IP アドレスを共有する場合、クラスタ内の各サーバ インスタンスにユニークなリスン ポート番号を割り当てます。クラスタ内の各サーバ インスタンスの IP アドレスが異なる場合、各インスタンスが使用するリスン ポート番号は同じであってもそれぞれ異なっていてもかまいません。必要なのは、サーバ インスタンスごとにユニークな IP アドレスとリスン ポートの組み合わせです。
WebLogic Server 7.0 には、ドメインおよびクラスタを容易に作成するための新しいユーティリティであるドメイン コンフィグレーション ウィザードが付属します。ウィザードの機能の詳細とその使用方法については、『WebLogic Server ドメイン管理』の「コンフィグレーション ウィザードを使用した新しいドメインの作成」を参照してください。
バージョン 7.0 より前の WebLogic Server のクラスタには、JMS などのクラスタ化されないサービスで、クラスタが提供する冗長性を利用するためのメカニズムがありませんでした。WebLogic Server 7.0 では、管理者が、クラスタ化されないサービスを、あるサーバ インスタンスからクラスタ内の別のインスタンスに移行することができます。 これは、サーバ インスタンスの障害への対応として、あるいは定期的な保守の一環として行います。この機能により、ホストのサーバ インスタンスで障害が発生した場合に冗長サーバ インスタンス上でサービスを速やかに再開できるため、クラスタ内のクラスタ化されないサービスの可用性が向上します。
WebLogic JMS 7.0 では、管理者は複数の送り先をクラスタ内部で単一の分散送り先セットの一部としてコンフィグレーションできます。プロデューサおよびコンシューマは、分散送り先との送受信ができます。クラスタの内部で単一のサーバ インスタンスに障害が発生した場合、WebLogic JMS は、分散送り先セットに登録され、その時点で使用可能なすべての物理送り先に負荷を分散します。
バージョン 7.0 では、クラスタ化環境向けに WebLogic Server コアで実装された移行フレームワークも利用されます。これにより、WebLogic JMS は、移行要求に適切に対応することができ、JMS サーバを通常の方法でオンラインやオフラインにすることができます。これには、あらかじめ予定された移行と、WebLogic Server インスタンスの障害に対応して行われる移行の両方が含まれます。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
