4 クラスタの構成の理解

この章では、クラスタの構成を定義する情報が格納および保持される仕組みと、構成作業を実施するために使用できる方法について説明します。

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

• クラスタの構成とconfig.xml

• 管理サーバーの役割

• 動的構成の仕組み

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

• クラスタを構成する方法

  注意:

  この章の情報の多くは、サーバー・インスタンスがクラスタ化されていないWebLogicドメインの構成プロセスに関連するものです。

クラスタの構成とconfig.xml

config.xmlファイルは、WebLogic Serverドメインの構成を記述したXMLドキュメントです。config.xmlは、一連のXML要素で構成されます。Domain要素はトップレベルの要素であり、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.xml.bootedという名前のバックアップ構成ファイルがドメイン・ディレクトリに作成されます。サーバー・インスタンスの存続期間中に万一config.xmlファイルが破損した場合、このファイルを使用して以前の構成に戻すことができます。

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

図4-1 WebLogic Serverの構成

「図4-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

  WebLogic Scripting Tool (WLST)は、アプリケーションのデプロイメント構成やデプロイメント操作などドメインの構成タスクの自動化に使用できるコマンド行インタフェースです。

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

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

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

注意:

WebLogic Serverにデプロイする前にアプリケーションをパッケージ化する必要があります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイとパッケージ化に関する項にあるパッケージ化に関するトピックを参照してください。

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

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

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

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

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

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

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

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

• ターゲット・サーバー・インスタンスへのデプロイ中に失敗した場合は、サーバー・インスタンスがADMIN状態で起動します。『Oracle WebLogic Serverサーバーの起動と停止の管理』のADMIN状態に関する項を参照してください。

• クラスタ・メンバーがアプリケーションのデプロイに失敗した場合は、デプロイできなかったアプリケーションが使用不可能になります。

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

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

注意:

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

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

• 対象のクラスタへの管理対象サーバーの追加または削除

• 対象のクラスタ内の管理対象サーバーの停止

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

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

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

• 固定サービスはクラスタ内の複数の管理対象サーバーにデプロイできない - あるアプリケーションがクラスタにデプロイされていない場合、そのアプリケーションはクラスタ内の1つの管理対象サーバーにのみデプロイできます。

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

デフォルトでは、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ドメインの作成』の概要に関する項を参照してください。クラスタの作成と構成の詳細は、「クラスタ」を参照してください。

• WebLogic Server管理コンソール

  WebLogic Server管理コンソールは管理サービスにアクセスするためのグラフィカル・ユーザー・インタフェース(GUI)です。コンソールからは、各種のドメイン構成およびモニター機能を実行できます。

• WebLogic Serverアプリケーション・プログラミング・インタフェース(API)

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

• WebLogic Scripting Tool (WLST)

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

• Java Management Extensions (JMX)

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