クラスタの構成の理解

3 クラスタの構成の理解

Oracle WebLogic Serverクラスタの構成を定義する情報を格納およびメンテナンスする仕組みと、構成タスクを実施するために使用できる方法を学習します。

ノート:

この項の情報は、サーバー・インスタンスがクラスタ化されていないWebLogicドメインの構成に関連します。

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

クラスタの構成とconfig.xml
config.xmlファイルは、WebLogic Serverドメインの構成を記述したXMLドキュメントです。
管理サーバーの役割
管理サーバーは、そのドメイン内のWebLogic Serverインスタンス群を構成および管理するWebLogic Serverインスタンスです。
動的構成の仕組み
WebLogic Serverでは、ドメイン・リソースの構成属性を動的に(サーバー・インスタンスの動作中に)変更できます。ほとんどの場合では、変更を有効にするためにサーバー・インスタンスを再起動する必要はありません。属性を構成しなおすと、新しい値が、実行時の現在の属性値とconfig.xmlに格納されている永続的な値の両方にただちに反映されます。
クラスタ化された構成でのアプリケーションのデプロイメント
ここでは、アプリケーションのデプロイメント・プロセスについて簡単に説明します。
クラスタを構成する方法
クラスタを構成するには、構成ウィザード、WebLogicリモート・コンソール、FMWC、WebLogic Server API、WLST、Java Management Extensions (JMX)など、いくつかのWebLogic Server管理ツールや方法のいずれかを使用できます。

クラスタの構成とconfig.xml

config.xmlファイルは、WebLogic Serverドメインの構成を記述したXMLドキュメントです。

config.xmlファイルは、一連のXML要素で構成されています。<domain>要素はトップレベルの要素であり、ドメイン内のすべての要素は<domain>要素の子要素です。<domain>要素には、<server>、<cluster>、<application>などの子要素があります。子要素の中にさらに子要素がある場合もあります。たとえば、<server>要素には、子要素として<WebServer>、<SSL>,、および<Log>があります。<application>要素には<EJBComponent>と<WebAppComponent>という子要素があります。

各要素には、1つ以上の構成可能な属性があります。config.dtdに定義されている属性には、構成APIに対応する属性があります。たとえば、Server要素にはListenPort属性があり、同様に、weblogic.management.configuration.ServerMBeanにもListenPort属性があります。構成可能な属性は読取り可能かつ書込み可能であり、言い換えると、ServerMBeanにはgetListenPortメソッドとsetListenPortメソッドがあります。

config.xmlファイルについてさらに学習するには、Oracle WebLogic Serverドメイン構成の理解のドメイン構成ファイルを参照してください。

親トピック: クラスタの構成の理解

管理サーバーの役割

管理サーバーは、そのドメイン内のWebLogic Serverインスタンス群を構成および管理するWebLogic Serverインスタンスです。

ドメインには複数のWebLogic Serverクラスタと、クラスタ化されないWebLogic Serverインスタンスが存在できます。厳密に言うと、ドメインは1つのWebLogic Serverインスタンスだけでも構成できます。ただしその場合、各ドメインには必ず1つの管理サーバーが存在しなければならないため、その唯一のサーバー・インスタンスが管理サーバーになります。

「クラスタを構成する方法」で説明されているように、管理サーバーのサービスを呼び出して構成タスクを実施する方法はいくつかあります。どの方法を使用する場合でも、構成を修正するときはクラスタの管理サーバーが稼働している必要があります。

管理サーバーが起動すると、ドメインのconfig.xmlがロードされます。config.xmlは、次のディレクトリで検索されます。

ORACLE_HOME/user_projects/domains/domain_name/config

domain_nameはドメインに固有のディレクトリで、その名前はドメインと同じです。

ノート:

configディレクトリまたはサブディレクトリに構成ファイル以外のファイルを追加しないでください。構成ファイル以外のファイルにはログ(.log)ファイルおよびロック(.lck)ファイルが含まれます。管理サーバーは、すべての管理対象サーバー・インスタンスのconfigディレクトリをレプリケートします。構成ファイル以外のファイルをconfigディレクトリに格納すると、ドメインにおいてパフォーマンスの問題が発生する可能性があります。

図3-1は、1つの管理サーバーと複数のWebLogic Serverインスタンスで構成される典型的な本番環境を示しています。このようなドメインでサーバー・インスタンスを起動すると、まず管理サーバーが起動します。その他の各サーバー・インスタンスは、起動時に管理サーバーにアクセスしてその構成情報を取得します。このように、管理サーバーはドメイン全体の構成の一元的な制御エンティティとして動作します。

図3-1 WebLogic Serverの構成

「図3-1 WebLogic Serverの構成」の説明

管理サーバーに障害が発生した場合

親トピック: クラスタの構成の理解

管理サーバーに障害が発生した場合

ドメインの管理サーバーで障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。管理対象のサーバー・インスタンスが(クラスタ化されているかいないかには関係なく)動作しているときにドメインの管理サーバーが使用できなくなっても、その管理対象サーバーは処理を続けます。ドメインにクラスタ化サーバー・インスタンスがある場合は、管理サーバーに障害が発生しても、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバー機能を使用できます。

ノート:

ホスト・マシン上のハードウェアまたはソフトウェアに障害が発生したために管理サーバーに障害が発生した場合、同じマシン上の他のサーバー・インスタンスも同様に影響を受けることがあります。ただし、管理サーバー自体で障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。

管理サーバーを再起動する手順は、Oracle WebLogic Serverサーバーの起動と停止の管理のサーバー障害のリカバリとサーバー障害からのリカバリを参照してください。

親トピック: 管理サーバーの役割

動的構成の仕組み

WebLogic Serverでは、ドメイン・リソースの構成属性を動的に(サーバー・インスタンスの動作中に)変更できます。ほとんどの場合では、変更を有効にするためにサーバー・インスタンスを再起動する必要はありません。属性を構成しなおすと、新しい値が、実行時の現在の属性値とconfig.xmlに格納されている永続的な値の両方にただちに反映されます。

しかし、構成へのすべての変更が動的に適用されるわけではありません。たとえば、管理対象サーバーのListenPort値を変更した場合、新しいポートは管理対象サーバーを次に起動するまで使用されません。更新された値はconfig.xmlに保存されますが、実行時の値は影響を受けません。

WebLogicリモート・コンソールは、範囲外エラーやデータ型の不一致エラーをチェックして属性の変更を検証し、エラーのあるエントリではエラー・メッセージを表示します。

WebLogicリモート・コンソールが管理サーバーに接続した後、管理サーバーに割り当てられたリスニング・ポートを別のプロセスが取得した場合、ポートを取得したプロセスを停止する必要があります。リスニング・ポートを獲得したプロセスを削除できない場合、config.xmlファイルを編集して、ListenPort値を変更します。

親トピック: クラスタの構成の理解

クラスタ化された構成でのアプリケーションのデプロイメント

ここでは、アプリケーションのデプロイメント・プロセスについて簡単に説明します。

アプリケーションのデプロイメント・プロセスの概要は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

一般的なデプロイメント・タスクの実行手順については、「アプリケーションをデプロイする」を参照してください

親トピック: クラスタの構成の理解

デプロイメント方法

次の方法を使用して、クラスタにアプリケーションをデプロイできます。

WebLogicリモート・コンソール

WebLogicリモート・コンソールは、管理サービスに対するグラフィカル・ユーザー・インタフェース(GUI)です。
Fusion Middleware Control (FMWC)

FMWCは、管理サービスに対するグラフィカル・ユーザー・インタフェース(GUI)です。
weblogic.Deployer

weblogic.Deployerユーティリティは、WebLogic ServerデプロイメントAPIにコマンド行インタフェースを提供するJavaベースの開発ツールです。
WebLogic Scripting Tool (WLST)

WLSTは、アプリケーション・デプロイメント構成およびデプロイ操作を含めたドメイン構成タスクを自動化できるコマンド行インタフェースです。

これらのデプロイメント・ツールは、Oracle WebLogic Serverへのアプリケーションのデプロイのデプロイメント・ツールで説明されています。

使用するデプロイメント・ツールに関係なく、デプロイメント・プロセスを開始するときは、デプロイするコンポーネントとデプロイ先のターゲット(クラスタ、またはクラスタかドメイン内の個々のサーバー・インスタンス)を指定します。

プロセスの間、ドメインの管理サーバーはクラスタ内の管理対象サーバーと通信しながらデプロイメント・プロセスを管理します。各管理対象サーバーはデプロイするコンポーネントをダウンロードし、ローカルのデプロイメント・タスクを開始します。デプロイメント状態は、デプロイされるコンポーネントの関連するMBeanに保持されます。『デプロイメント管理API』を参照してください。

ノート:

WebLogic Serverにデプロイする前にアプリケーションをパッケージ化する必要があります。Oracle WebLogic Serverアプリケーションの開発のwlpackageを使用したアプリケーションのパッケージ化を参照してください。

親トピック: クラスタ化された構成でのアプリケーションのデプロイメント

2フェーズ・デプロイメントの概要

WebLogic Serverでは、アプリケーションは2つのフェーズでデプロイされます。開始前に、WebLogic Serverはクラスタ内の管理対象サーバーが使用可能かどうかを判断します。

親トピック: クラスタ化された構成でのアプリケーションのデプロイメント

デプロイメントの第1フェーズ

デプロイメントの第1フェーズでは、アプリケーション・コンポーネントがターゲット・サーバー・インスタンスに配布されます。アプリケーション・コンポーネントが正常にデプロイされるように、計画されたデプロイメントが検証されます。このフェーズでは、デプロイされるアプリケーションへのユーザー・リクエストは許可されません。

配布および検証プロセス中に障害が発生した場合は、すべてのサーバー・インスタンス上でデプロイメントが中止されます(検証が成功したインスタンスも含まれます)。ステージングされたファイルは削除されませんが、準備中に実行されたコンテナ側の変更は元に戻されます。

親トピック: 2フェーズ・デプロイメントの概要

デプロイメントの第2フェーズ

アプリケーション・コンポーネントは、ターゲットに配布されて検証された後で、ターゲット・サーバー・インスタンス上に完全にデプロイされます。デプロイされたアプリケーションはクライアントから使用できるようになります。

デプロイメントの第2フェーズ中に障害が発生した場合、サーバーは次のいずれかの動作で起動します。

ターゲット・サーバー・インスタンスへのデプロイ中に失敗した場合は、サーバー・インスタンスがADMIN状態で起動します。Oracle WebLogic Serverサーバーの起動と停止の管理のADMIN状態を参照してください。
クラスタ・メンバーがアプリケーションのデプロイに失敗した場合は、デプロイできなかったアプリケーションが使用不可能になります。

親トピック: 2フェーズ・デプロイメントの概要

クラスタへのデプロイメントのガイドライン

デプロイメント・プロセス中は、クラスタ内のすべての管理対象サーバーが実行中で使用可能になっていることが理想的です。クラスタ内の一部のメンバーが使用できないときにアプリケーションをデプロイすることはお薦めしません。クラスタにアプリケーションをデプロイする前に、クラスタ内のすべての管理対象サーバーを実行し、管理サーバーからアクセスできるようにしておきます。

ノート:

デプロイメント時に分断された管理対象サーバー(実行中だが管理サーバーからアクセスできない状態)にアプリケーションをデプロイすると、その管理対象サーバーがクラスタに復帰するときに、管理対象サーバーへのアクセスについて問題が発生する可能性があります。同期化期間中、クラスタ化された他の管理対象サーバーが以前に分断されたサーバー・インスタンスとの通信を再確立している間、デプロイ済アプリケーションへのユーザー・リクエストや、そのサーバー・インスタンスでのセカンダリ・セッションの作成は失敗します。ClusterConstraintsEnabledを設定することで、この状況が発生するリスクを減らせます。詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイのすべての構成済クラスタ・メンバーへの一貫性のあるデプロイメントの実施を参照してください。

デプロイメント・プロセス中はクラスタ・メンバーシップを変更しないでください。デプロイメント開始後は、次の操作を行わないでください。

ターゲット・クラスタに対して管理対象サーバーを追加または削除します。
ターゲット・クラスタ内の管理対象サーバーを停止します。

WebLogic Serverがサポートする「緩和されたデプロイメント」ルール

親トピック: クラスタ化された構成でのアプリケーションのデプロイメント

WebLogic Serverがサポートする「緩和されたデプロイメント」ルール

以前のバージョンのWebLogic Serverでは、クラスタへのデプロイメントに関して次の制限が課せられていました:

部分的なデプロイメントの禁止: クラスタ内の1つまたは複数の管理対象サーバーが使用できない場合、デプロイメント・プロセスは終了し、デプロイメントを試行する前に、アクセスできない管理対象サーバーを再起動するか、クラスタから削除することを指示するエラー・メッセージが生成されます。
固定サービスはクラスタ内の複数の管理対象サーバーにデプロイできない: あるアプリケーションがクラスタにデプロイされていない場合、そのアプリケーションはクラスタ内の1つの管理対象サーバーにのみデプロイできます。

次の項を参照してください。

親トピック: クラスタへのデプロイメントのガイドライン

部分的なクラスタへのデプロイメントの許可

デフォルトでは、Oracle WebLogic Serverは部分的なクラスタへのデプロイメントを許可します。クラスタ内の1つまたは複数の管理対象サーバーが使用できない場合は、次のメッセージが表示されます。

Unable to contact "servername". Deployment is deferred until "servername" becomes available.

アクセスできない管理対象サーバーが使用可能になると、そのサーバー・インスタンスへのデプロイメントが開始されます。デプロイメント・プロセスが完了するまで、管理対象サーバーでは、クラスが見つからない、またはクラスが古いなどのエラーが発生する可能性があります。

親トピック: WebLogic Serverがサポートする「緩和されたデプロイメント」ルール

WebLogic Serverの完全なクラスタへのデプロイメント

ClusterConstraintsEnabledを設定すると、クラスタ内のすべての管理対象サーバーがアクセス可能な場合にのみデプロイメントが実行されるようにできます。ClusterConstraintsEnabledを「true」に設定すると、クラスタ内のすべてのメンバーがアクセス可能で、指定したファイルをデプロイできる場合のみクラスタへのデプロイメントが成功します。詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイのすべての構成済クラスタ・メンバーへの一貫性のあるデプロイメントの実施を参照してください。

親トピック: WebLogic Serverがサポートする「緩和されたデプロイメント」ルール

固定サービスを複数の管理対象サーバーにデプロイ可能

固定サービスはクラスタ内の複数の管理対象サーバーにターゲット指定できます。この実践はお薦めしません。固定サービスをクラスタ内の複数の管理対象サーバーにデプロイすると、クラスタのロード・バランシング機能とスケーラビリティが悪影響を受ける可能性があります。固定サービスを複数の管理対象サーバーにターゲット指定すると、次のメッセージがサーバー・ログに出力されます。

Adding server servername of cluster clustername as a target for
module modulename. This module also includes server servername that
belongs to this cluster as one of its other targets. Having multiple
individual servers in a cluster as targets instead of having the entire
cluster as the target can result in non-optimal load balancing and
scalability. Hence this is not usually recommended.

親トピック: WebLogic Serverがサポートする「緩和されたデプロイメント」ルール

クラスタを構成する方法

クラスタを構成するには、構成ウィザード、WebLogicリモート・コンソール、FMWC、WebLogic Server API、WLST、Java Management Extensions (JMX)など、いくつかのWebLogic Server管理ツールや方法のいずれかを使用できます。

構成ウィザード

新しいドメインやクラスタを作成するには、構成ウィザードを使用することをお薦めします。詳細は、構成ウィザードによるWebLogicドメインの作成の概要を参照してください。

クラスタの作成および構成の詳細は、『構成ウィザードによるWebLogicドメインの作成』の「クラスタ」を参照してください。
WebLogicリモート・コンソールおよびFMWC

WebLogicリモート・コンソールおよびFMWCは、管理サービスに対するGUIです。これらから、各種のドメイン構成およびモニター機能を実行できます。
WebLogic Server API

WebLogic Serverに付属する構成APIに基づいて、構成属性を変更するプログラムを記述することができます。この方法は、初期のクラスタ実装に対してはお薦めできません。
WebLogic Scripting Tool (WLST)

WLSTはコマンド行スクリプト・インタフェースです。システム管理者およびオペレータは、このインタフェースでWebLogic Serverのインスタンスやドメインの監視と管理を行います。『WebLogic Scripting Toolの理解』を参照してください。
Java Management Extensions (JMX)

JMXは、ネットワーク上のリソースをモニターおよび管理するためのソリューションです。WebLogic Serverには、JMXを使用してWebLogic Serverリソースを構成、モニター、および管理するための様々なMBeanが用意されています。

親トピック: クラスタの構成の理解