| Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方 11g リリース1 (10.3.3) B60992-01 |
|
 前 |
 次 |
この章では、WebLogic Serverクラスタの概要について簡潔に説明します。次の情報が含まれます。
WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは同じマシン上で実行することも、複数のマシンに分散配置することもできます。クラスタの能力は、既存のマシン上のクラスタにサーバー・インスタンスを追加することによって強化できます。また、新たにサーバー・インスタンスを配置するためのマシンをクラスタに追加することもできます。クラスタ内の各サーバー・インスタンスでは、同じバージョンのWebLogic Serverが動作している必要があります。
クラスタは特定のWebLogic Serverドメインの一部です。
ドメインとは、関連性があり1つの単位として管理されるWebLogic Serverリソースの集合のことです。ドメインには1つ以上のWebLogic Serverインスタンスが含まれます。これらのインスタンスはクラスタ構成にも非クラスタ構成にもでき、クラスタ化されたインスタンス群とそうでないインスタンス群を組み合わせて構成することもできます。ドメインには、複数のクラスタを構成できます。またドメインには、ドメインにデプロイされるアプリケーション・コンポーネントと、それらのアプリケーション・コンポーネントおよびドメイン内のサーバー・インスタンスが必要とするリソースおよびサービスも含まれます。アプリケーションおよびサーバー・インスタンスで使用されるリソースとサービスの例には、マシン定義、オプションのネットワーク・チャネル、コネクタ、起動クラスなどがあります。
WebLogic Serverインスタンスは、様々な基準によってドメインに分類できます。たとえば、ホストするアプリケーションの論理的な区分、地理的な考慮事項、あるいは管理対象リソースの数や複雑度に基づいてリソースを複数のドメインに割り当てることができます。ドメインの詳細は、「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トランザクション・リカバリ・システムなど)のことです。障害が発生した場合、自動移行が構成されている管理対象サーバーは別のマシンに自動的に移行されます。
管理対象サーバーとそれがホストするすべてのサービスを計画的なシステム管理プロセスの一部として再配置する場合のプロセスの簡略化。管理者は管理コンソールまたはコマンド・ラインから管理対象サーバーの移行を開始できます。
サーバー移行プロセスによって、管理対象サーバー(IPアドレスおよびホストされるアプリケーションを含む)は、そのまま全部が定義済の使用可能なホスト・マシンの1つに再配置されます。
ロード・バランシング
ロード・バランシングとは、環境内のコンピューティング・リソースおよびネットワーキング・リソース間で、ジョブとそれに関連する通信を均等に分配することです。ロード・バランシングが実行されるには:
特定のジョブを実行できるオブジェクトの複数のコピーが存在している必要があります。
すべてのオブジェクトの場所および動作のステータスについての情報が入手できることが必要です。
WebLogic Serverでは、オブジェクトをクラスタ化、つまり複数のサーバー・インスタンス上にデプロイすることにより、同じジョブを実行する代替オブジェクトを用意することができます。WebLogic Serverは、デプロイされるオブジェクトの可用性および場所の情報を、ユニキャスト、IPソケット、およびJNDIを利用して共有し、保持します。
|
注意: 以前のバージョンのWebLogic Serverとの互換性を維持するため、クラスタ間の通信にマルチキャストを使用することも可能です。 |
WebLogic Serverでの通信およびレプリケーション技術の利用形態について、詳しくは「クラスタでの通信」を参照してください。
クラスタ化されるアプリケーションまたはアプリケーション・コンポーネントは、クラスタ内の複数のWebLogic Serverインスタンス上で利用可能なものです。オブジェクトをクラスタ化すると、そのオブジェクトに対してフェイルオーバーとロード・バランシングが有効になります。クラスタの管理、保守、およびトラブルシューティングの手順を簡素化するには、オブジェクトを均一に、つまりクラスタ内のすべてのサーバー・インスタンスにデプロイします。
Webアプリケーションは、Enterprise 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クラスタはラウンドロビン方式を使用します。管理コンソールで、他の方式を使用するようにクラスタを構成できます。選択した方式は、クラスタ化されたオブジェクト用に取得したレプリカ対応スタブの内部で保持されます。詳細は、「EJBとRMIオブジェクトのロード・バランシング」を参照してください。
WebLogic Serverでは、クラスタがホストとなるアプリケーションの可用性を向上させるために、データ・ソースやマルチ・データ・ソースなどのJDBCオブジェクトをクラスタ化できます。クラスタ用に構成する各JDBCオブジェクトは、クラスタ内の各管理対象サーバーに存在する必要があります。JDBCオブジェクトを構成するときに、それらをクラスタに割り当てます。
データ・ソース - クラスタ内で、外部クライアントは、JNDIツリー内のJDBCデータ・ソースを介して接続を取得する必要があります。データ・ソースは、WebLogic Server RMIドライバを使用して接続を取得します。外部クライアント・アプリケーションのWebLogicデータ・ソースはクラスタ対応なので、接続をホストするサーバー・インスタンスに障害が発生した場合、クライアントは別の接続をリクエストできます。必須ではありませんが、サーバー側クライアントもJNDIツリー内のデータ・ソースを介して接続を取得することをお薦めします。
マルチ・データ・ソース - マルチ・データ・ソースは、マルチ・データ・ソースと関連付けられたデータ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供する、データ・ソースのグループを抽象化したものです。マルチ・データ・ソースは、データ・ソースがJNDIツリーにバインドされるのと同じように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされます。アプリケーションは、データ・ソースの場合と同じようにJNDIツリー上のマルチ・データ・ソースをルックアップし、その後データベース接続をリクエストします。マルチ・データ・ソースは、そのマルチ・データ・ソースの構成内で選択されるアルゴリズムに応じて、リクエストを満たすためにロード・バランシングとフェイルオーバーのうちどちらのデータ・ソースを使用するかを決定します。
JDBCの詳細は、『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の設定手順については、「固定サービスの移行可能ターゲットを構成する」および「移行可能サービスをデプロイ、アクティブ化、および移行する」を参照してください。
