クラスタの使用

クラスタのコンフィグレーションについて

この章の以下の節では、クラスタのコンフィグレーションを定義する情報が格納および保持される仕組みと、コンフィグレーション作業を実施する方法について説明します。

クラスタのコンフィグレーションと config.xml

config.xml ファイルは、WebLogic Server ドメインのコンフィグレーションを記述した 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 の詳細については、『ドメインのコンフィグレーションについて』の「ドメイン コンフィグレーション ファイル」を参照してください。

管理サーバの役割

管理サーバは、そのドメイン内の WebLogic Server インスタンス群をコンフィグレーションおよび管理する WebLogic Server インスタンスです。

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

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

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

BEA_HOME/user_projects/domains/<domain_name>/config

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

管理サーバが正常に起動するたびに、config.xml.booted という名前のバックアップ コンフィグレーション ファイルがドメイン ディレクトリに作成されます。サーバ インスタンスの有効期間中に万一 config.xml ファイルが破損した場合、このファイルを使用して以前のコンフィグレーションに戻すことができます。

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

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

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

管理サーバを再起動する手順については、『サーバの起動と停止の管理』の「サーバ障害の回避とサーバ障害からの回復」を参照してください。

動的コンフィグレーションの仕組み

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

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

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

Administration Console の起動後に、管理サーバに割り当てられたリスン ポートを別のプロセスが獲得した場合、ポートを獲得したプロセスを停止することをお勧めします。リスン ポートを獲得したプロセスを削除できない場合、config.xml ファイルを編集して、ListenPort 値を変更します。

クラスタ化されたコンフィグレーションでのアプリケーションのデプロイメント

この節では、アプリケーションのデプロイメント プロセスについて簡単に説明します。デプロイメントの詳細については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。

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

デプロイメント方法

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

これらのデプロイメント ツールについては、『WebLogic Server アプリケーションのデプロイメント』の「デプロイメント ツールの概要」で説明されています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“servername” にアクセスできません。“servername” が利用可能になるまでデプロイメントは延期されます。

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

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

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

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

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

クラスタ clustername のサーバ servername をモジュール modulename の
対象として追加しています。このモジュールには、別の対象として同じクラスタに
属するサーバ servername が含まれます。クラスタ全体を対象にするのではなく、
クラスタ内の複数の個別のサーバを対象にする場合、ロード バランシングおよび
スケーラビリティが最適化されなくなる場合があります。
このため、通常はお勧めできません。

クラスタをコンフィグレーションする方法

クラスタをコンフィグレーションする複数の方法が用意されています。