2 WebLogic Serverのクラスタリングの理解

この章では、Oracle WebLogic Serverクラスタにおける概要について説明します。

この章の内容は次のとおりです。

• WebLogic Serverクラスタとは
  WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。
• 動的クラスタとは
  動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタは、指定した数の生成された(動的)サーバー・インスタンスの構成を定義する単一のサーバー・テンプレートを使用します。
• クラスタとドメインの関係
  クラスタは特定のWebLogic Serverドメインの一部です。
• クラスタリングの利点とは
  WebLogic Serverクラスタにより、スケーラビリティと高可用性という利点が提供されます。
• クラスタの重要な機能とは
  スケーラビリティと高可用性を実現する重要なクラスタリング機能は、アプリケーションのフェイルオーバー、サーバーの移行、およびロード・バランシングです。
• クラスタリング可能なオブジェクトの種類
  クラスタ化されるアプリケーションまたはアプリケーション・コンポーネントは、クラスタ内の複数のWebLogic Serverインスタンス上で利用可能なものです。フェイルオーバーおよびロード・バランシングは、クラスタ化されたオブジェクトで使用できます。クラスタ内のすべてのサーバー・インスタンスにオブジェクトを均一にデプロイして、クラスタの管理、保守およびトラブルシューティングを簡略化します。WebLogic Serverデプロイメントでクラスタ化できるオブジェクトの種類を学習します。
• クラスタリングできないオブジェクトの種類
  特定のAPIおよび内部サービスは、WebLogic Serverでクラスタリングできません。

WebLogic Serverクラスタとは

WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。

クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは、同じマシン上で実行することも、複数のマシン上で実行することもできます。

クラスタの容量は、次のいずれかの手順で増やすことができます:

• 既存のマシン上のクラスタにサーバー・インスタンスを追加します。
• クラスタにマシンを追加して、増分サーバー・インスタンスをホストします。

クラスタ内の各サーバー・インスタンスでは、同じバージョンのWebLogic Serverが動作している必要があります。

動的クラスタとは

動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタは、指定した数の生成された(動的)サーバー・インスタンスの構成を定義する単一のサーバー・テンプレートを使用します。

動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。これにより、追加のサーバー容量が必要な場合に動的クラスタ内のサーバー・インスタンスの数を簡単にスケール・アップできます。動的サーバーは、手動での構成やクラスタへの追加を行わずに起動できます。

「動的クラスタ」および『Oracle 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では、クラスタ化サーバー・インスタンスを、あるマシンから別のマシンに、自動的にまたは手動で移行できます。移行できる管理対象サーバーは、移行可能サーバーと呼ばれます。この機能は、高可用性が求められる環境に向けて設計されています。サーバー移行機能は、次の場合に役立ちます。

  • シングルトン・サービスの継続的な可用性の保証。シングルトン・サービスとは、ホストとなるサーバー・インスタンスで障害が発生した場合に、常に1つのサーバー・インスタンス上のみで実行する必要があるサービスのことです(Java Messaging Service (JMS)やJava Transaction API (JTA)トランザクション・リカバリ・システムなど)。障害が発生した場合、自動移行のために構成されている管理対象サーバーは別のマシンに自動的に移行されます。

  • 管理対象サーバーとそれがホストするすべてのサービスの再配置プロセスの簡略化(計画的なシステム管理プロセスの一環として)。管理対象サーバーの移行を開始するには、Oracle WebLogic Serverの理解のシステム管理ツールおよびAPIの概要にリストされたいずれかの管理ツールを使用できます。

  サーバー移行プロセスによって、管理対象サーバー(IPアドレスおよびホストされるアプリケーションを含む)は、そのまま全部が定義済の使用可能なホスト・マシンの1つに再配置されます。

• ロード・バランシング

  ロード・バランシングとは、環境内のコンピューティング・リソースおよびネットワーキング・リソース間で、ジョブとそれに関連する通信を均等に分配することです。

  ロード・バランシングが実行されるには:

  • 特定のジョブを実行できるオブジェクトの複数のコピーが存在している必要があります。

  • WebLogic Serverでは、オブジェクトをクラスタリング、つまり複数のサーバー・インスタンス上にデプロイすることにより、同じジョブを実行する代替オブジェクトを用意することができます。WebLogic Serverは、デプロイされるオブジェクトの可用性および場所の情報を、ユニキャスト、IPソケット、およびJNDIを利用して共有し、保持します。

    ノート:

    以前のバージョンのWebLogic Serverとの互換性を維持するため、クラスタ間の通信にマルチキャストを使用することも可能です。

    すべてのオブジェクトの場所および動作のステータスについての情報が入手できることが必要です。

WebLogic Serverでの通信およびレプリケーション技術の利用形態について、詳しくは「クラスタでの通信」を参照してください

クラスタリング可能なオブジェクトの種類

クラスタ化されるアプリケーションまたはアプリケーション・コンポーネントは、クラスタ内の複数のWebLogic Serverインスタンス上で利用可能なものです。フェイルオーバーおよびロード・バランシングは、クラスタ化されたオブジェクトで使用できます。クラスタ内のすべてのサーバー・インスタンスにオブジェクトを均一にデプロイして、クラスタの管理、保守およびトラブルシューティングを簡略化します。WebLogic Serverデプロイメントでクラスタ化できるオブジェクトの種類を学習します。

Webアプリケーションは、Enterprise JavaBeans (EJB)、サーブレット、Java Server Pages (JSPs)などを含む様々な種類のオブジェクトで構成できます。それぞれのオブジェクトの種類ごとに、制御、呼び出し、およびアプリケーション内部での機能に関連する動作の一意の集合が定義されています。この理由から、クラスタリングをサポートし、またその結果としてロード・バランシングとフェイルオーバーを実現するためにWebLogic Serverで利用される手法は、オブジェクトの種類ごとに異なる可能性があります。WebLogic Serverのデプロイメントでは、次の種類のオブジェクトのクラスタリングが可能です。

• サーブレット

• JSP

• EJB

• Remote Method Invocation (RMI)オブジェクト

• JMS宛先

• バッチ・アプリケーション

種類の異なるオブジェクト間で、一部の動作が共通している可能性があります。その場合、類似したオブジェクト・タイプについては、クラスタリングのサポートおよび実装上の考慮事項が一致することがあります。次の項では、次のオブジェクト・タイプ別に説明と手順を組み合せています:

• サーブレットとJSP

• EJBとRMIオブジェクト

次の項では、WebLogic Serverでのクラスタリング、フェイルオーバー、およびロード・バランシングのサポートについて、オブジェクトのタイプ別に簡単に説明します:

• サーブレットとJSP
  
• EJBとRMIオブジェクト
  
• JMSとクラスタリング
  
• バッチ・アプリケーション
  

サーブレットとJSP

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オブジェクトのフェイルオーバーは、オブジェクトのレプリカ対応スタブを使用して実現されます。クライアントがレプリカ対応スタブを通じて障害が発生したサービスに対して呼出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼出しを再試行します。様々な種類のオブジェクトに対するフェイルオーバーのサポートについては、「EJBとRMIのレプリケーションとフェイルオーバー」を参照してください

WebLogic Serverクラスタは、クラスタ化されるEJBおよびRMIオブジェクト間でロード・バランシングを行うための複数のアルゴリズム(ラウンドロビン、重みベース、ランダム、ラウンドロビン・アフィニティ、重みベース・アフィニティ、およびランダム・アフィニティ)をサポートしています。デフォルトでは、WebLogic Serverクラスタはラウンドロビン方式を使用します。WebLogic Server管理コンソールを使用して、他の方式を使用するようにクラスタを構成できます。選択した方式は、クラスタ化オブジェクト用に取得したレプリカ対応スタブの内部で保持されます。詳細は、「EJBとRMIオブジェクトのロード・バランシング」を参照してください。

JMSとクラスタリング

WebLogic JMSのアーキテクチャでは、クラスタ内のあらゆるWebLogic Serverインスタンスから宛先への透過的なアクセスをクラスタ全体でサポートすることによって、複数のJMSサーバーのクラスタリングを実装しています。WebLogic Serverでは、JMS宛先および接続ファクトリをクラスタ全体に分散させることができますが、同じJMSトピックまたはJMSキューは引き続き、クラスタ内の個々のWebLogic Serverインスタンスによって個別に管理されます。

ロード・バランシングはJMSに対してサポートされています。ロード・バランシングを有効にするには、JMSサーバーのターゲットを構成する必要があります。ロード・バランシングとJMSコンポーネントの詳細は、「JMSのロード・バランシング」を参照してください。クラスタ化されたJMSの設定方法については、「固定サービス用の移行可能ターゲットを構成する」および「移行可能サービスをデプロイ、アクティブ化、および移行する」を参照してください。

バッチ・アプリケーション

WebLogic Serverでは、バッチ・アプリケーションをクラスタにデプロイする機能と、そのクラスタ内の各管理対象サーバーの個々のバッチのランタイム・インスタンスを実行する機能がサポートされています。クラスタ内のサーバー数を増やすと、通常、そのクラスタにデプロイされるアプリケーションの全体的なバッチ処理能力が向上します。ただし、個々のバッチ・ジョブの処理はクラスタ内の単一の管理対象サーバーで実行され、クラスタ内の管理対象サーバー全体には分散できません。

バッチ・アプリケーションをクラスタにデプロイして実行する場合は、次の点に注意してください。

• 個々のバッチ・ランタイムは、クラスタ内の各管理対象サーバー・インスタンスで構成する必要があります。管理対象サーバーのインスタンスでバッチ・ジョブが開始されると、ジョブは完了までそのインスタンスで実行されます。この動作のロード・バランシングへの影響に関する重要な考慮事項について、『Oracle WebLogic Serverサーバー環境の管理』の複数のバッチ・ランタイム・インスタンスの使用に関する項を参照してください。

• バッチ・ランタイムのリファレンス実装(RI)では、データベースを使用してジョブ・リポジトリをモデル化し、ジョブ・リポジトリには過去および現在のジョブの詳細が含まれます。 クラスタ環境で使用するためにジョブ・リポジトリを構成するには、次のものが必要です:

  1. ジョブ・リポジトリを保持するデータベースにアクセスするためのデータ・ソースの構成

  2. そのデータ・ソースのクラスタへのターゲット設定

  3. そのデータ・ソースを使用するための各バッチのランタイム・インスタンスの構成

  ジョブ・リポジトリの構成、およびジョブ・リポジトリとバッチのランタイム・インスタンスの両方で使用されるデータ・ソースの構成の詳細は、『Oracle WebLogic Serverサーバー環境の管理』の専用データベースを使用するためのバッチ・ランタイムの構成に関する項を参照してください。

• バッチ・ランタイムでは状態のレプリケーションは使用できないため、従来のフェイルオーバーは使用できません。したがって、異なる管理対象サーバー・インスタンスで実行されているバックアップ・コピーで失敗したバッチ・ジョブの再開はできません。ただし、クラスタ内のすべてのバッチのランタイム・インスタンスが同じジョブ・リポジトリを指していて、そのジョブ・リポジトリを含むデータベースのデータ・ソースもそのクラスタをターゲットにしている場合は、管理対象サーバー・インスタンス上の障害が発生したバッチ・ジョブは、問合せが可能であり、そのクラスタ内の他の管理対象サーバー・インスタンス上で再開できます。

クラスタリングできないオブジェクトの種類

特定のAPIおよび内部サービスは、WebLogic Serverでクラスタリングできません。

• ファイルの共有を含むFileサービス

これらのサービスは、クラスタ内の個々のWebLogic Serverインスタンスでは使用できます。ただし、これらのサービスに関してロード・バランシングやフェイルオーバー機能は利用できません。