WebLogic Server のコンフィグレーションと管理
|
 |
 |
|
以下の節では、WebLogic Server ドメインについて説明します。
ドメインは、WebLogic Server インスタンスの基本的な管理単位です。1 つまたは複数の WebLogic Server インスタンス (および、それに関連付けられたリソース) で構成され、1 つの管理サーバで管理されます。システム管理者の責任範囲、アプリケーションの境界、サーバの設置場所などに応じて、複数のドメインを定義できます。また、ドメインを 1 つにして、すべての WebLogic Server 管理アクティビティを一元化することも可能です。
各ドメインのコンフィグレーションは、config.xml という独立したコンフィグレーション ファイルに格納されます。このコンフィグレーションは、ログやセキュリティ ファイルなどのファイルと一緒に管理サーバに格納されます。管理サーバでコンフィグレーション タスクを行った場合は、変更はその管理サーバで管理されているドメインのみに適用されます。別のドメインを管理するには、そのドメインの管理サーバを使用します。したがって、あるドメイン内のサーバ インスタンス、アプリケーション、リソースは、別のドメイン内のサーバ、アプリケーション、リソースから独立したものとして扱う必要があります。複数のドメインで同時にコンフィグレーションやデプロイメントのタスクを行うことはできません。
ドメインには複数の WebLogic Server クラスタと、クラスタ化されない WebLogic Server インスタンスが存在できます。最小限のドメインには、1 つの WebLogic Server インスタンスのみ含まれます。その WebLogic Server インスタンスは、管理サーバと管理対象サーバの両方として機能します。このようなドメインはアプリケーションの開発時には便利ですが、プロダクション環境で使用することはお勧めしません。ドメインの範囲と目的は多種多様ですが、ほとんどの WebLogic Server ドメインには、この節で説明するコンポーネントが含まれます。
図 2-1 に、管理サーバ、3 つのスタンドアロン管理対象サーバ、および 3 つの管理対象サーバから成るクラスタで構成されたプロダクション環境を示します。
ドメイン内のサーバは、開発モードとプロダクション モードのいずれかで起動するようにコンフィグレーションできます。開発モードは、アプリケーションを開発するときに使用します。開発モードではセキュリティのコンフィグレーションが緩やかになり、アプリケーションを自動デプロイできます。プロダクション モードは、アプリケーションがその最終的なかたちで実行されるときに使用します。プロダクション モードではセキュリティを万全にし、クラスタなどの高度な機能も使用できます。開発モードとプロダクション モードの相違点については、「コンフィグレーションの起動モードの相違点」を参照してください。
実行時モードはドメイン全体の設定です。各管理対象サーバは、起動する際に管理サーバのモードを参照して、実行時モードを決定します。デフォルトでは、すべてのサーバが開発モードで動作します。ドメインをプロダクション モードで動作するようにコンフィグレーションすると、管理サーバはその設定をドメインの config.xml ファイルに保存します。
ドメインを最初に作成するときにモードを設定することをお勧めします。プロダクション モードで動作するドメインの作成の詳細については、「例 : 管理サーバとクラスタ化された管理対象サーバで構成されるドメインの作成」を参照してください。
既存のドメインのモードを変更することはできますが、お勧めしていません。Administration Console オンライン ヘルプの「実行時モードの変更」を参照してください。
この節では、新しいドメインの作成方法について説明します。ドメインの作成と使用に関する制限の詳細については、「ドメインの制限事項」を参照してください。
WebLogic 環境内の各サーバ インスタンスには、そのインスタンスがどのドメインやクラスタに含まれるかに関係なく、またそれが管理サーバであるか管理対象サーバであるかに関係なく、ユニークな名前を付ける必要があります。ドメインの内部では、サーバ、マシン、クラスタ、仮想ホスト、およびその他のリソース タイプのそれぞれにユニークな名前を付ける必要があり、ドメインと同じ名前を使用することはできません。
WebLogic JMS に関して、この厳密なユニーク命名規則は、ドメイン内の操作性を考えて WebLogic メッセージング ブリッジまたは外部 JMS サーバを使用している場合にマルチドメイン環境の JMS サーバや JMS ストアなどの JMS リソースにも適用されます。その他の命名要件については、Administration Console オンライン ヘルプの「ドメインの相互運用性を実現するための JMS リソースの命名規則」を参照してください。
JTA トランザクションも、ドメイン間トランザクションの厳密なユニーク命名規則に従います。詳細については、Administration Console オンライン ヘルプの「ドメイン間トランザクションに対するドメインのコンフィグレーション」を参照してください。
コンフィグレーション ウィザードは、新しい WebLogic Server ドメインを作成する最も簡単な手段であり、推奨の方法です。コンフィグレーション ウィザードは、作成するドメインのタイプをインタラクティブにユーザに問い合わせ、ドメインで使用する config.xml ファイル、起動スクリプトなどのファイルを作成します。コンフィグレーション ウィザードを使用して以下のことが行えます。
config.xml ファイルのないディレクトリから WebLogic Server インスタンスを起動すると、そのディレクトリに自動的にデフォルト コンフィグレーション (起動スクリプトや config.xml を含む) が作成されます。そのドメイン コンフィグレーションは、Administration Console などのシステム管理ツールを使用して修正できます。
weblogic.Server コマンドでドメインを作成するには、次の手順に従います。
サーバにより、手順 3 で入力したユーザ名とパスワードを含む起動 ID ファイル (boot.properties) が作成されます。このファイルがドメインのルート ディレクトリに存在していれば、起動時にユーザ名とパスワードの入力を求めるプロンプトは表示されません。
Ant スクリプトを使用して新しいドメイン コンフィグレーションを作成するには、wlserver および wlconfig Ant タスクを実行します。詳細については、『WebLogic Server コマンド リファレンス』の「Ant タスクを使用した WebLogic Server ドメインのコンフィグレーション」を参照してください。
各 WebLogic Server ドメインには、管理サーバとして動作する 1 つのサーバ インスタンスが必要です。ドメイン内の他のすべてのサーバ インスタンスおよびリソースをコンフィグレーションするには、その管理サーバをプログラム的に、Administration Console を通じて、またはコマンドラインを利用して使用します。
ドメイン内の管理対象サーバを起動するには、まず管理サーバを起動します。スタンドアロンのまたはクラスタ化された管理対象サーバを起動すると、その管理対象サーバは管理サーバにアクセスしてコンフィグレーション情報を取得します。このように、管理サーバはドメイン全体のコンフィグレーションの一元的な制御エンティティとして動作します。
weblogic.Admin) を使用すると、ドメインの管理を自動化するスクリプトを作成できます。詳細については、『WebLogic Server コマンド リファレンス』を参照してください。どの方法を使用する場合でも、ドメインの管理サーバが実行されていなければ、ドメインのコンフィグレーションを修正することはできません。
管理サーバが起動すると、ドメインの config.xml がロードされます。config.xml は、カレント ディレクトリで検索されます。コンフィグレーション ウィザードを使用して新しいドメインを作成するときには、ドメインの場所を指定できます。デフォルトでは、ドメインは次の場所に配置されます。
BEA_HOME/user_projects/domains/mydomain
mydomain は、ドメインと同じ名前を持つ特定ドメインのディレクトリです。
管理サーバが正常に起動するたび、そしてコンフィグレーションが修正されるたびに、バックアップ コンフィグレーション ファイルが作成されます。管理サーバで維持される config.xml のバックアップ コピー数は、コンフィグレーションできます。詳細については、「config.xml のバックアップ」を参照してください。
ドメインの管理サーバで障害が発生しても、ドメイン内の管理対象サーバの動作には影響しません。管理対象のサーバ インスタンスが (クラスタ化されているかいないかには関係なく) 動作しているときにドメインの管理サーバが使用できなくなっても、その管理対象サーバは処理を続けます。ドメインにクラスタ化されたサーバ インスタンスがある場合は、管理サーバに障害が発生しても、ドメイン コンフィグレーションでサポートされているロード バランシングおよびフェイルオーバ機能を使用できます。
ホスト マシン上のハードウェアまたはソフトウェアに障害が発生したために管理サーバに障害が発生した場合、同じマシン上の他のサーバ インスタンスも同様に影響を受けることがあります。ただし、管理サーバ自体で障害が発生しても、ドメイン内の管理対象サーバの動作には影響しません。
詳細については、「障害が発生したサーバの回復」を参照してください。
ドメイン内で、管理サーバ以外のサーバ インスタンスは管理対象サーバと呼びます。管理対象サーバは、アプリケーションを構成するコンポーネントと関連するリソース (JSP や EJB など) をホストします。管理対象サーバを起動すると、その管理対象サーバはドメインの管理サーバに接続してコンフィグレーションとデプロイメントの設定を取得します。
注意 : 管理サーバが使用できない場合、ドメイン内の管理対象サーバは管理サーバから独立して起動できます。詳細については、「障害が発生したサーバの回復」を参照してください。
複数の管理対象サーバを WebLogic Server クラスタとしてコンフィグレーションすると、アプリケーションのスケーラビリティと可用性を向上させることができます。WebLogic Server クラスタ内では、ほとんどのリソースとサービスが (単一の管理対象サーバではなく) 各管理対象サーバにデプロイされて、フェイルオーバとロード バランシングが利用可能になります。どのコンポーネント タイプおよびサービスをクラスタ化できるのかについては、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ化可能なオブジェクトの種類」を参照してください。
クラスタ化されていない管理対象サーバを作成してそれをクラスタに追加するには、Administration Console などのシステム管理ツールを使用して、そのサーバ インスタンスとクラスタで適切なコンフィグレーション パラメータをコンフィグレーションします。逆に、クラスタから管理対象サーバを削除するには、追加時にコンフィグレーションしたパラメータを適切に再コンフィグレーションします。クラスタ化された管理対象サーバとクラスタ化されていない管理対象サーバの主な違いは、フェイルオーバおよびロード バランシングのサポートです。それらの機能は、管理対象サーバのクラスタでしか利用できません。
管理対象サーバをクラスタ化するかどうかは、スケーラビリティと可用性に対する実際の必要度によって決まります。たとえば、アプリケーションが負荷の変化に影響を受けず、アプリケーション サービスで起こる可能性のある中断が許容可能である場合、クラスタ化は必要ありません。
WebLogic Server クラスタのメリットと機能については、『WebLogic Server クラスタ ユーザーズ ガイド』の「WebLogic Server のクラスタ化の概要」を参照してください。1 つのドメインには、クラスタとしてコンフィグレーションされていない管理対象サーバだけでなく、複数の WebLogic Server クラスタを含めることができます。
ドメインには、管理サーバと管理対象サーバだけでなく、管理対象サーバおよびその管理対象サーバでホストされるドメイン内にデプロイされたアプリケーションで必要とされるリソースとサービスも含まれます。
ドメイン内の管理対象サーバは、それら独自のリソースとサービスをホストします。リソースとサービスは、選択した管理対象サーバまたはクラスタにデプロイできます。デプロイ可能なリソースの例を次に示します。
アプリケーションのパフォーマンス、スループット、または可用性を向上させる必要のあるプロダクション環境では、複数の管理対象サーバをクラスタとしてコンフィグレーションできます。クラスタ化を行うと、複数の管理対象サーバが 1 つのユニットとしてアプリケーションおよびリソースをホストすることができます。スタンドアロンの管理対象サーバとクラスタ化された管理対象サーバの違いについては、「管理対象サーバとクラスタ化された管理対象サーバ」を参照してください。
注意 : プロダクション環境では、アプリケーションはドメイン内の管理対象サーバだけにデプロイします。管理サーバは管理タスク用に確保しておく必要があリます。 詳細については、「コンフィグレーション ウィザードを使用したドメインの作成とコンフィグレーション」を参照してください。
インストールされる WebLogic Server の多くは、アプリケーションをホストするために必要なすべての管理対象サーバを含む単一のドメインで構成されます。ドメインに関する以下の制限事項に注意してください。
この節では、ドメインおよびドメイン内のサーバ インスタンスのディレクトリ構造について説明します。
ドメインのコンフィグレーションは、そのドメインの config.xml ファイルに格納されます。管理サーバの起動時にコマンドライン オプションを指定すれば、このファイルに別の名前を指定できます。config.xml ファイルでは、ドメインの名前と、ドメイン内の各サーバ インスタンス、クラスタ、リソース、およびサービスのコンフィグレーション パラメータ設定が指定されます。config.xml ファイルは、管理サーバのサーバ ルート ディレクトリに格納されている必要があります (「管理サーバのサーバ ルート ディレクトリ」を参照)。
このディレクトリには、ドメイン内の管理サーバと管理対象サーバの起動に使用できるデフォルトのスクリプト ファイルも格納されます。それらのスクリプト、およびサーバ インスタンスを起動する他の方法の詳細については、Administration Consol オンライン ヘルプの「サーバの起動と停止」を参照してください。
バージョン 7.0 より前の WebLogic Server のリリースでは、Weblogic Server のディレクトリ構造内にドメイン ディレクトリが作成されていました。WebLogic Server 8.1 では、製品のディレクトリ ツリー外部の、WebLogic Server および JDK にアクセスできるファイル システム上の任意の位置にドメイン ディレクトリを設定できます。
コンフィグレーション ウィザードを使用してドメインを作成すると、ドメインのコンテナとして使用する user_projects/domains ディレクトリが、BEA ホーム ディレクトリにデフォルトで作成されます (ファイル システム上の別のディレクトリを指定することもできる)。また、新しいドメインのルート ディレクトリ、およびドメイン作成時に選択したドメイン テンプレートに指定されているその他のディレクトリもすべて作成されます。
コンフィグレーション ウィザードで作成されたドメイン ディレクトリ構造の内容は以下のとおりです。
mydomain、petstore)。このディレクトリには以下を格納します。config.xml ファイルapplications)注意 : WebLogic Server の自動デプロイメント機能 (ドメインが開発モードで動作している場合に利用可能) を使用する場合、アプリケーションのサブディレクトリは applications という名前である必要があります。自動デプロイメントの詳細については、『WebLogic Server アプリケーションのデプロイメント』の「自動デプロイメント」を参照してください。
ドメイン内のサーバ インスタンスを初めて起動すると、ドメイン ディレクトリに以下のサブディレクトリが作成されます。
logs ディレクトリ。ドメイン ディレクトリ構造には必要に応じて他のディレクトリを作成することもできます。
WebLogic Server のすべてのインスタンスは、サーバ ルート ディレクトリを使用して、実行時データを格納したり、サーバのコンフィグレーション内での相対パス名のコンテキストを提供したりします。WebLogic Server インスタンスを初めて起動すると、各サーバ インスタンスのサブディレクトリがサーバ ルート ディレクトリに作成されます。そのサブディレクトリには、ログ ファイル、セキュリティ データ、管理上のデータ、およびサーバ インスタンスで使用される他のファイルが格納されます。
サーバ インスタンスごとにサーバ ルート ディレクトリのパスと名前を指定できます。1 つのコンピュータでホストされる複数のサーバ インスタンスで共通のサーバ ルート ディレクトリを指定するか、サーバごとに異なるサーバ ルート ディレクトリを指定できます。ドメインには、1 つまたは複数のサーバ ルート ディレクトリが存在できます。
サーバ ルート ディレクトリには、applications というサブディレクトリも格納できます。このサブディレクトリは、ドメインが開発モードで動作しているときにアプリケーションの自動デプロイメントに使用します。
たとえば図 2-2 で、サーバ ルート ディレクトリは MyServerRootDirectory です。server-1 および server-2 という WebLogic Server インスタンスはそれぞれ、サーバ ルート ディレクトリ内に専用のサブディレクトリを持ちます。それらのサブディレクトリの名前は、ドメインのコンフィグレーションで定義されているサーバの名前です。
サーバ ルート ディレクトリのパスは、以下のいずれかの手段で指定できます。
-Dweblogic.RootDirectory=path オプションを使用する。たとえば次のコマンドでは、java -Dweblogic.RootDirectory=c:\MyServerRootDirectory weblogic.Server
上記の手段でサーバ ルート ディレクトリを指定しない場合、サーバ ルート ディレクトリのパスと名前はサーバ インスタンスが管理対象サーバと管理サーバのどちらであるか、およびサーバ インスタンスの起動にノード マネージャを使用するのかどうかに依存します。次以降の節で、それらのバリエーションについて説明します。
管理サーバは、そのサーバ ルート ディレクトリをドメインのコンフィグレーション データ (config.xml など) およびセキュリティ リソース (デフォルトの組み込み LDAP サーバなど) のリポジトリとして使用します。
管理サーバのルート ディレクトリの判別は以下の手順で行われます。
-Dweblogic.RootDirectory=path オプションが含まれている場合は、path の値がサーバ ルート ディレクトリになる。-Dweblogic.RootDirectory=path が指定されておらず、作業ディレクトリ (起動コマンドを発行したディレクトリ) に config.xml ファイルが格納されている場合は、その作業ディレクトリがサーバ ルート ディレクトリになる。 working-directory/config/domain-name 内で config.xml ファイルを検索する。このディレクトリに config.xml が格納されている場合は、working-directory/config/domain-name がサーバ ルート ディレクトリになります。config.xml ファイルが見つからない場合は、新たにディレクトリを作成するかどうかを尋ねるメッセージが表示される。この方法では、新しいドメインを作成できます。詳細については、『WebLogic Server コマンド リファレンス』の「weblogic.Server コマンドラインを使用したドメインの作成」を参照してください。ノード マネージャで管理対象サーバを起動すると、そのルート ディレクトリはノード マネージャ プロセスをホストするコンピュータ上に配置されます。サーバのルート ディレクトリの位置を判断するために、WebLogic Server は以下のことを行います。
BEA_HOME\WL_HOME\common\nodemanager
各要素の説明は次のとおりです。ノード マネージャで起動した管理対象サーバのサーバ ルート ディレクトリには、各管理対象サーバ インスタンスのサブディレクトリが格納されます。そのサブディレクトリの名前は、ドメインのコンフィグレーションで定義されているサーバの名前です。
ノード マネージャを使用せず、java weblogic.Server コマンドまたはそのコマンドを呼び出すスクリプトを使用して管理対象サーバを起動した場合、WebLogic Server は次のようにルート ディレクトリを判断します。
-Dweblogic.RootDirectory=path オプションが含まれている場合は、path の値がサーバのルート ディレクトリになる。-Dweblogic.RootDirectory=path が指定されていない場合は、作業 (カレント) ディレクトリがルート ディレクトリになる。たとえば、c:\config\MyManagedServer から weblogic.Server コマンドを実行した場合は、c:\config\MyManagedServer がルート ディレクトリになります。注意 : WebLogic Server ソフトウェアがアップグレードされてもドメイン コンフィグレーションとアプリケーションを簡単に維持できるようにするには、サーバ ルート ディレクトリを WebLogic Server ソフトウェアのインストール ディレクトリとは別のディレクトリにします。
|
|
|