| Oracle® Fusion Middleware Oracle WebLogic Server 10.3.6クラスタの使用 11gリリース1 (10.3.6) B60992-08 |
|
 前 |
 次 |
この章では、WebLogic Server 10.3.6のクラスタの概要について簡潔に説明します。
この章の内容は次のとおりです。
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つのドメインだけを管理します。ドメインに複数のクラスタが含まれる場合、ドメイン内の各クラスタは同じ管理サーバーによって管理されます。あるクラスタ内のすべてのサーバー・インスタンスは同じドメイン内になければなりません; 1つのクラスタを複数のドメインにまたがって「分割」することはできません。同様に、構成済みのリソースまたはサブシステムを複数のドメインで共有することはできません。
クラスタ化された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では、クラスタ化サーバー・インスタンスを、あるマシンから別のマシンに、自動的にまたは手動で移行できます。移行できる管理対象サーバーは、移行可能サーバーと呼ばれます。この機能は、高可用性が求められる環境に向けて設計されています。サーバー移行機能は、次の場合に役立ちます。
シングルトン・サービスの中断のない可用性の保証: シングルトン・サービスとは、ホストとなるサーバー・インスタンスで障害が発生した場合にJMSやJTAトランザクション・リカバリ・システムなど、常に1つのサーバー・インスタンス上のみで実行する必要があるサービスのことです。障害が発生した場合、自動移行のために構成されている管理対象サーバーは別のマシンに自動的に移行されます。
管理対象サーバーとそれがホストするすべてのサービスを計画的なシステム管理プロセスの一部として再配置する場合のプロセスの簡略化。管理者は管理コンソールまたはコマンド・ラインから管理対象サーバーの移行を開始できます。
サーバー移行プロセスによって、管理対象サーバー(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)の宛先
種類の異なるオブジェクト間で、一部の動作が共通している可能性があります。その場合、類似したオブジェクト・タイプについては、クラスタリングのサポートおよび実装上の考慮事項が一致することがあります。次の項では、次のオブジェクト・タイプの組合せ別に説明および手順を示しています。
サーブレットと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 JMS (Java Messaging Service)のアーキテクチャでは、クラスタ内のあらゆるWebLogic Serverサーバー・インスタンスから宛先への透過的なアクセスをクラスタ全体でサポートすることによって、複数のJMSサーバーのクラスタリングを実装しています。WebLogic Serverでは、JMS宛先および接続ファクトリをクラスタ全体に分散させることができますが、同じJMSトピックまたはJMSキューは引き続き、クラスタ内の個々のWebLogic Serverインスタンスによって個別に管理されます。
ロード・バランシングはJMSに対してサポートされています。ロード・バランシングを有効にするには、JMSサーバーのターゲットを構成する必要があります。ロード・バランシングとJMSコンポーネントの詳細については、「JMSのロード・バランシング」を参照してください。クラスタ化されたJMSの設定手順については、「固定サービスの移行可能ターゲットを構成する」および「移行可能サービスをデプロイ、アクティブ化、および移行する」を参照してください。
