|
|
この章の以下の節では、クラスタのコンフィグレーションを定義する情報が格納および保持される仕組みと、コンフィグレーション作業を実施する方法について説明します。
| 注意 : | この章の情報の多くは、サーバ インスタンスがクラスタ化されていない WebLogic ドメインのコンフィグレーション プロセスに関連するものです。 |
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 ドメインの作成』の「コンフィグレーション ウィザードを使用した新しいドメイン作成の概要」を参照してください。クラスタの作成とコンフィグレーションについては、「環境のカスタマイズ」を参照してください。
Administration Console は、BEA Administration Service にアクセスするためのグラフィカル ユーザ インタフェース (GUI) です。コンソールからは、各種のドメイン コンフィグレーションおよびモニタ機能を実行できます。
WebLogic Server に付属するコンフィグレーション API に基づいて、コンフィグレーション属性を変更するプログラムを記述することができます。この方法は、初期のクラスタ実装に対してはお勧めできません。
WebLogic Scripting Tool (WLST) は、システム管理者やオペレータが、WebLogic Server インスタンスおよびドメインのモニタと管理に使用する、コマンドライン スクリプト インタフェースです。詳細については、『WebLogic Scripting Tool ガイド』を参照してください。
JMX は、ネットワーク上のリソースをモニタおよび管理するための Java EE ソリューションです。BEA WebLogic Server には、JMX を使用して WebLogic Server リソースをコンフィグレーション、モニタ、および管理するためのさまざまな MBean が用意されています。
  
|
