| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server ドメイン管理 > WebLogic Server ドメインの概要 |
|
WebLogic Server ドメイン管理
|
以下の節では、WebLogic Server ドメインとその内容について説明します。
ドメインは、WebLogic Server インスタンスの基本的な管理単位です。 1 つまたは複数の WebLogic Server インスタンス (および、それに関連付けられたリソース) で構成され、それらのインスタンスが単一の管理サーバで管理されます。 各システム管理者の責任範囲、アプリケーションの境界、サーバの設置場所などに基づいて、複数のドメインを定義できます。 また、ドメインを 1 つにして、すべての WebLogic Server 管理アクティビティを一元化することも可能です。
複数のドメインを作成した場合は、各ドメインのコンフィグレーション ファイル（config.xml）が別々になります。そのため、コンフィグレーション タスクまたはデプロイメント タスクを複数のドメインで同時に行うことはできません。 Administration Console でコンフィグレーション タスクを行う場合、変更は現在選択されているドメインに対して適用されます。 別のドメインで変更を行うには、そのドメインを選択しなくてはなりません。 したがって、あるドメイン内のサーバ インスタンス、アプリケーション、リソースは、別のドメイン内のサーバ、アプリケーション、リソースから独立したものとして扱う必要があります。
ドメインには複数の WebLogic Server クラスタと、クラスタ化されていない WebLogic Server インスタンスが存在できます。 厳密に言うと、1 つの WebLogic Server インスタンスだけでもドメインを構成できます。ただしその場合、その唯一のサーバ インスタンスが管理サーバになります。これは、各ドメインには必ず 1 つの管理サーバが存在する必要があるためです。 ドメインの範囲と目的は多種多様ですが、この節では、ほとんどの WebLogic Server ドメインに含まれるコンポーネントについて説明します。
次の図に、管理サーバ、3 つのスタンドアロン管理対象サーバ、および 3 つの管理対象サーバを含むクラスタで構成されたプロダクション環境を示します。
各 WebLogic Server ドメインには、管理サーバとして動作するサーバ インスタンスが 1 つ必要です。 その管理サーバをプログラム的に、または Administration Console を介して使用することで、ドメイン内にある他のすべてのサーバ インスタンスおよびリソースをコンフィグレーションします。
ドメイン内の管理対象サーバを起動するには、まず管理サーバを起動します。 スタンドアロンの管理対象サーバ、またはクラスタ化された管理対象サーバを起動すると、その管理対象サーバは管理サーバにアクセスしてコンフィグレーション情報を取得します。 このように、管理サーバはドメイン全体のコンフィグレーションの一元的な制御エンティティとして動作します。
どの方法を使用する場合でも、ドメインの管理サーバが実行されていなければ、ドメインのコンフィグレーションを修正することはできません。
管理サーバを起動すると、その管理サーバではドメインの config.xml がロードされます。 config.xml は、カレント ディレクトリで検索されます。 ドメインの作成時に別のディレクトリを指定しない限り、config.xml は次のディレクトリに格納されます。
BEA_HOME/user_projects/mydomain
mydomain は、特定のドメインと同じ名前を持つそのドメイン固有のディレクトリです。
管理サーバが正常に起動すると、そのたびに、config.xml.booted という名前のバックアップ用コンフィグレーション ファイルがドメイン専用のディレクトリに作成されます。 これにより、万が一サーバが終了するまでの間に config.xml ファイルが壊れるようなことがあっても、以前の状態のコンフィグレーションに戻ることができます。
管理サーバおよび WebLogic Server JMX 管理システムにおけるロールについては、『管理者ガイド』の「システム管理ツール」を参照してください。
ドメインの管理サーバで障害が発生しても、ドメイン内の管理対象サーバの動作には影響しません。 ドメインの管理サーバが使用できなくなっても、その管理サーバが管理対象とする (クラスタ化された、またはされていない) サーバ インスタンスが起動および実行されていれば、それらの管理対象サーバは処理を続けます。 ドメインにクラスタ化されたサーバ インスタンスがある場合には、管理サーバに障害が発生しても、ドメイン コンフィグレーションでサポートされているロード バランシングおよびフェイルオーバー機能を引き続き使用できます。
ホスト マシン上のハードウェアまたはソフトウェアの障害が原因で管理サーバに障害が発生した場合、同じマシン上の他のサーバ インスタンスも同様に影響を受けることがあります。 ただし、管理サーバ自体の障害がドメイン内の管理対象サーバの動作を妨げることはありません。
管理サーバを再起動する手順については、管理対象サーバの動作中における管理サーバの再起動を参照してください。
管理サーバ以外のドメイン内のサーバ インスタンスは、管理対象サーバと呼ばれます。 管理対象サーバには、アプリケーションを構成するコンポーネントと関連するリソース (JSP や EJB など) がホストされます。 管理対象サーバは起動時にドメインの管理サーバに接続し、コンフィグレーションとデプロイメントの設定を取得します。
注意: 管理サーバが使用不可能な状態のときに、管理サーバから独立してドメイン内の管理対象サーバを起動できます。 詳細については、障害が発生したサーバの回復を参照してください。
複数の管理対象サーバを WebLogic Server クラスタとしてコンフィグレーションすると、アプリケーションのスケーラビリティと可用性を向上させることができます。 WebLogic Server クラスタ内では、リソースとサービスのほとんどが (単一の管理対象サーバにではなく) 各々の管理対象サーバにデプロイされ、それによってフェイルオーバーとロード バランシングが実現されます。 どのコンポーネント タイプおよびサービスをクラスタ化できるのか (クラスタ内のすべてのサーバ インスタンスにデプロイできるのか) については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ化可能なオブジェクトの種類」を参照してください。
クラスタ化されていない管理対象サーバを作成した後でそのサーバをクラスタに追加するには、そのサーバ インスタンスとクラスタに適切なコンフィグレーション パラメータをコンフィグレーションします。 逆に、クラスタから管理対象サーバを削除するには、追加時にコンフィグレーションしたパラメータを適切に再コンフィグレーションします。 管理対象サーバをクラスタ化した場合とクラスタ化しない場合の主な違いは、フェイルオーバーおよびロード バランシングをサポートするかどうかです。これらの機能は、管理対象サーバをクラスタ化した場合にのみ利用できます。
管理対象サーバをクラスタ化するかどうかは、スケーラビリティと信頼性に対する要件の度合いによって決まります。 たとえば、アプリケーションが負荷の変化に影響を受けず、アプリケーション サービスで起こる可能性のある中断を許容できる場合には、クラスタ化の必要はありません。
WebLogic Server クラスタのメリットと機能の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「WebLogic Server クラスタ化の概要」を参照してください。単一ドメインには、クラスタとしてコンフィグレーションされていない複数の管理対象サーバを設定できるのと同様に、複数の WebLogic Server クラスタを設定することもできます。
ドメインには、管理サーバと管理対象サーバだけでなく、ドメイン内にデプロイされている管理対象サーバとその管理対象サーバにホストされるアプリケーションで必要とされる、リソースとサービスも含まれます。
ドメイン内の管理対象サーバは、そのドメイン独自のリソースとサービスをホストします。 選択した管理対象サーバまたはクラスタに対して、リソースおよびサービスをデプロイできます。 デプロイ可能なリソースの例を次に示します。
アプリケーションのパフォーマンス、スループット、または可用性を高度に保つ必要のあるプロダクション環境では、複数の管理対象サーバをクラスタとしてコンフィグレーションできます。 クラスタ化を行うと、複数の管理対象サーバが 1 つのユニットとして機能して、アプリケーションおよびリソースをホストできるようになります。 スタンドアロンの管理対象サーバとクラスタ化された管理対象サーバの違いについては、管理対象サーバとクラスタ化された管理対象サーバを参照してください。
注意: プロダクション環境では、ドメイン内の管理対象サーバだけにアプリケーションをデプロイすることをお勧めします。管理サーバは管理タスク用に確保しておく必要があリます。
WebLogic Server のインストール環境は単一のドメインで構成されることが多く、アプリケーションをホストするために必要なすべての管理対象サーバをそのドメインに含む形で利用されています。 ドメインを複数作成する場合には、以下の制限事項に注意してください。
ドメインのコンフィグレーションは、そのドメインの config.xml ファイルに格納されます。 config.xml には、ドメインの名前と、ドメイン内の各サーバ インスタンス、クラスタ、リソース、およびサービスのコンフィグレーション パラメータ設定が指定されます。 ドメインの config.xml は、そのドメインの作成時に指定したドメイン ディレクトリに格納されます。
ドメイン ディレクトリには、ドメイン内の管理サーバと管理対象サーバの起動に使用できるデフォルトのスクリプト ファイルも格納されます。 それらのスクリプト、およびサーバ インスタンスを起動する他の方法の詳細については、『管理者ガイド』の「WebLogic Server の起動と停止」を参照してください。
WebLogic Server 7.0 より前のリリースでは、Weblogic Server のディレクトリ構造内にドメイン ディレクトリが作成されていました。 WebLogic Server 7.0 以降では、製品のディレクトリ ツリー外部の、WebLogic Server および JDK にアクセスできるシステム上の任意の位置にドメイン ディレクトリを設定できます。
この新しいディレクトリ構造にはさらに高度な柔軟性があり、WebLogic Server の実行可能ファイルやその関連ファイルとは独立したディレクトリ構造に、アプリケーション コードを格納できます (この方法をお勧めします)。
注意: WebLogic Server の自動デプロイメント機能 (ドメインが開発モードで動作している場合に利用可能) を使用する場合、アプリケーションのサブディレクトリは applications という名前にする必要があります。 自動デプロイメントの詳細については、『WebLogic Server アプリケーションの開発』の「自動デプロイメント」を参照してください。
ドメイン ディレクトリ構造には必要に応じて他のディレクトリを作成することもできます。 ドメイン内のサーバ インスタンスの初回起動時には、ドメイン ディレクトリに以下のサブディレクトリが作成されます。
ドメインは、コンフィグレーション ウィザードを使用して作成、コンフィグレーションできます。 カスタム インストールを行うと、手順の最後に、コンフィグレーション ウィザードを実行するかどうかを尋ねるプロンプトが表示されます。 コンフィグレーション ウィザードは、[スタート] メニューまたはスクリプトを使用して起動することもできます。 詳細については、コンフィグレーション ウィザードを使用した新しいドメインの作成を参照してください。
コンフィグレーション ウィザードを使用してドメインを作成すると、ドメインのコンテナとなる user_projects ディレクトリが BEA ホーム ディレクトリに作成されます。 また、新しいドメインのルート ディレクトリ、およびドメイン作成時に選択したドメイン テンプレートに指定されているその他のディレクトリもすべて作成されます。
一般的なドメイン管理タスクについては、以下の節を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
