4 クラスタの構成の理解
Oracle WebLogic Serverクラスタの構成を定義する情報を格納およびメンテナンスする仕組みと、構成タスクを実施するために使用できる方法を学習します。
ノート:
この項の情報は、サーバー・インスタンスがクラスタ化されていないWebLogicドメインの構成に関連します。
この章の内容は次のとおりです。
- クラスタの構成とconfig.xml
config.xml
ファイルは、WebLogic Serverドメインの構成を記述したXMLドキュメントです。 - 管理サーバーの役割
管理サーバーは、そのドメイン内のWebLogic Serverインスタンス群を構成および管理するWebLogic Serverインスタンスです。 - 動的構成の仕組み
WebLogic Serverでは、ドメイン・リソースの構成属性を動的に(サーバー・インスタンスの動作中に)変更できます。ほとんどの場合では、変更を有効にするためにサーバー・インスタンスを再起動する必要はありません。属性を構成しなおすと、新しい値が、実行時の現在の属性値とconfig.xml
に格納されている永続的な値の両方にただちに反映されます。 - クラスタ化された構成でのアプリケーションのデプロイメント
ここでは、アプリケーションのデプロイメント・プロセスについて簡単に説明します。 - クラスタを構成する方法
クラスタを構成するには、構成ウィザード、WebLogic Server管理コンソール、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
ディレクトリに格納すると、ドメインにおいてパフォーマンスの問題が発生する可能性があります。
管理サーバーが正常に起動するたびに、config.xml.booted
という名前のバックアップ構成ファイルがドメイン・ディレクトリに作成されます。サーバー・インスタンスの存続期間中に万一config.xml
ファイルが破損した場合、このファイルを使用して以前の構成に戻すことができます。
図4-1は、1つの管理サーバーと複数のWebLogic Serverインスタンスで構成される典型的な本番環境を示しています。このようなドメインでサーバー・インスタンスを起動すると、まず管理サーバーが起動します。その他の各サーバー・インスタンスは、起動時に管理サーバーにアクセスしてその構成情報を取得します。このように、管理サーバーはドメイン全体の構成の一元的な制御エンティティとして動作します。
親トピック: クラスタの構成の理解
管理サーバーに障害が発生した場合
ドメインの管理サーバーで障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。管理対象のサーバー・インスタンスが(クラスタ化されているかいないかには関係なく)動作しているときにドメインの管理サーバーが使用できなくなっても、その管理対象サーバーは処理を続けます。ドメインにクラスタ化サーバー・インスタンスがある場合は、管理サーバーに障害が発生しても、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバー機能を使用できます。
ノート:
ホスト・マシン上のハードウェアまたはソフトウェアに障害が発生したために管理サーバーに障害が発生した場合、同じマシン上の他のサーバー・インスタンスも同様に影響を受けることがあります。ただし、管理サーバー自体で障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。
管理サーバーを再起動する手順は、Oracle WebLogic Serverサーバーの起動と停止の管理のサーバー障害のリカバリとサーバー障害からのリカバリを参照してください。
親トピック: 管理サーバーの役割
動的構成の仕組み
WebLogic Serverでは、ドメイン・リソースの構成属性を動的に(サーバー・インスタンスの動作中に)変更できます。ほとんどの場合では、変更を有効にするためにサーバー・インスタンスを再起動する必要はありません。属性を構成しなおすと、新しい値が、実行時の現在の属性値とconfig.xml
に格納されている永続的な値の両方にただちに反映されます。
しかし、構成へのすべての変更が動的に適用されるわけではありません。たとえば、管理対象サーバーのListenPort
値を変更した場合、新しいポートは管理対象サーバーを次に起動するまで使用されません。更新された値はconfig.xml
に保存されますが、実行時の値は影響を受けません。
WebLogic Server管理コンソールは、範囲外エラーやデータ型の不一致エラーをチェックして属性の変更を検証し、エラーがあるエントリではエラー・メッセージを表示します。
WebLogic Server管理コンソールの起動後に、管理サーバーに割り当てられたリスニング・ポートを別のプロセスが獲得した場合、ポートを獲得したプロセスを停止することをお薦めします。リスニング・ポートを獲得したプロセスを削除できない場合、config.xml
ファイルを編集して、ListenPort
値を変更します。
親トピック: クラスタの構成の理解
クラスタ化された構成でのアプリケーションのデプロイメント
アプリケーションのデプロイメント・プロセスの概要は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
一般的なデプロイメント・タスクの実行手順については、「アプリケーションをデプロイする」を参照してください
デプロイメント方法
次の方法を使用して、クラスタにアプリケーションをデプロイできます。
-
WebLogic Server管理コンソール
WebLogic Server管理コンソールは管理サービスにアクセスするためのグラフィカル・ユーザー・インタフェース(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では、クラスタへのデプロイメントに関して次の制限が課せられていました:
-
部分的なデプロイメントの禁止: クラスタ内の1つまたは複数の管理対象サーバーが使用できない場合、デプロイメント・プロセスは終了し、デプロイメントを試行する前に、アクセスできない管理対象サーバーを再起動するか、クラスタから削除することを指示するエラー・メッセージが生成されます。
-
固定サービスはクラスタ内の複数の管理対象サーバーにデプロイできない: あるアプリケーションがクラスタにデプロイされていない場合、そのアプリケーションはクラスタ内の1つの管理対象サーバーにのみデプロイできます。
親トピック: クラスタへのデプロイメントのガイドライン
部分的なクラスタへのデプロイメントの許可
デフォルトでは、Oracle WebLogic Serverは部分的なクラスタへのデプロイメントを許可します。クラスタ内の1つまたは複数の管理対象サーバーが使用できない場合は、次のメッセージが表示されます。
Unable to contact "servername". Deployment is deferred until "servername" becomes available.
アクセスできない管理対象サーバーが使用可能になると、そのサーバー・インスタンスへのデプロイメントが開始されます。デプロイメント・プロセスが完了するまで、管理対象サーバーでは、クラスが見つからない、またはクラスが古いなどのエラーが発生する可能性があります。
WebLogic Serverの完全なクラスタへのデプロイメント
ClusterConstraintsEnabled
を設定すると、クラスタ内のすべての管理対象サーバーがアクセス可能な場合にのみデプロイメントが実行されるようにできます。ClusterConstraintsEnabled
を「true」に設定すると、クラスタ内のすべてのメンバーがアクセス可能で、指定したファイルをデプロイできる場合のみクラスタへのデプロイメントが成功します。詳細は、Oracle 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管理コンソール、FMWC、WebLogic Server API、WLST、Java Management Extensions (JMX)など、WebLogic Serverのいくつかの管理ツールや方法のいずれかを使用できます。
-
構成ウィザード
新しいドメインやクラスタを作成するには、構成ウィザードを使用することをお薦めします。詳細は、構成ウィザードによるWebLogicドメインの作成の概要を参照してください。
クラスタの作成および構成の詳細は、『構成ウィザードによるWebLogicドメインの作成』の「クラスタ」を参照してください。
-
WebLogic Server管理コンソールおよびFMWC
WebLogic Server管理コンソールおよびFMWCは、管理サービスにアクセスするためのGUIです。これらから、各種のドメイン構成およびモニター機能を実行できます。
-
WebLogic Server API
WebLogic Serverに付属する構成APIに基づいて、構成属性を変更するプログラムを記述することができます。この方法は、初期のクラスタ実装に対してはお薦めできません。
-
WebLogic Scripting Tool (WLST)
WLSTはコマンド行スクリプト・インタフェースです。システム管理者およびオペレータは、このインタフェースでWebLogic Serverのインスタンスやドメインの監視と管理を行います。『WebLogic Scripting Toolの理解』を参照してください。
-
Java Management Extensions (JMX)
JMXは、ネットワーク上のリソースをモニターおよび管理するためのJava EEソリューションです。WebLogic Serverには、JMXを使用してWebLogic Serverリソースを構成、モニター、および管理するための様々なMBeanが用意されています。
親トピック: クラスタの構成の理解