|
|
以下の節では、WebLogic Server ドメインとその内容について紹介します。
WebLogic Server の管理ドメインは、WebLogic Server リソースの論理的に関連したグループです。ドメインには、管理サーバと呼ばれる特殊な WebLogic Server インスタンスが含まれます。管理サーバでは、ドメイン内のすべてのリソースを一元的にコンフィグレーションおよび管理します。通常は、管理対象サーバと呼ばれる WebLogic Server インスタンスも含めてドメインをコンフィグレーションします。Web アプリケーション、EJB、Web サービスなどのリソースは管理対象サーバにデプロイし、管理サーバはコンフィグレーションや管理の目的にのみ使用します。
単一の WebLogic Server インストールを使用して複数のドメインを作成および実行したり、複数のインストールを使用して単一のドメインを実行したりできます。図 2-1 を参照してください。
インストールされた WebLogic Server をどのようなドメインに構成するかは、ビジネス上のニーズによって異なります。システム管理者の責任範囲、アプリケーションの境界、サーバを実行するマシンの設置場所などに応じて、複数のドメインを定義できます。また、ドメインを 1 つにして、すべての WebLogic Server 管理アクティビティを一元化することも可能です。
特定のビジネス上のニーズやシステム管理者の慣習に応じて、次のような条件に基づいてドメインの構成を決定することができます。
開発環境やテスト環境の場合は、単一のサーバ インスタンスから構成されたシンプルなドメインを作成できます。この単一のインスタンスは管理サーバとして動作し、開発中のアプリケーションをホストします。WebLogic Server と一緒にインストールできる wl_server ドメインはこのタイプのサンプル ドメインです。
図 2-2 に、管理サーバ、3 つのスタンドアロンの管理対象サーバ、3 つの管理対象サーバを含むクラスタで構成されたプロダクション環境を示します。
ドメインの範囲と目的は多種多様ですが、ほとんどの WebLogic Server ドメインには、この節で説明するコンポーネントが含まれます。
管理サーバは、ドメイン全体のコンフィグレーションの一元的な制御エンティティとして動作します。ドメインのコンフィグレーション ドキュメントを管理し、コンフィグレーション ドキュメントでの変更を管理対象サーバに配布します。また、ドメイン内のすべてのリソースを一元的に監視するための場所として使用することもできます。
管理サーバと対話するには、Administration Console または WLST を使用するか、独自の JMX クライアントを作成します。ドメインのコンフィグレーションの変更については、『Oracle WebLogic Server の紹介』の「WebLogic Server システム管理の概要」を参照してください。
各 WebLogic Server ドメインには、管理サーバとして機能する 1 つのサーバ インスタンスが必要です。
管理サーバで障害が発生しても、ドメイン内の管理対象サーバの動作には影響しません。ただし、ドメインのコンフィグレーションは変更できなくなります。ホスト マシン上のハードウェアまたはソフトウェアに障害が発生したために管理サーバに障害が発生した場合、同じマシン上の他のサーバ インスタンスも同様に影響を受けることがあります。ただし、管理サーバ自体で障害が発生しても、ドメイン内の管理対象サーバの動作には影響しません。
管理対象のサーバ インスタンスが (クラスタ化されているかいないかには関係なく) 動作しているときにドメインの管理サーバが使用できなくなっても、その管理対象サーバは処理を続けます。そして、定期的に管理サーバへの再接続を試行します。ドメインにクラスタ化されたサーバ インスタンスがある場合は、管理サーバに障害が発生しても、ドメイン コンフィグレーションでサポートされているロード バランシングおよびフェイルオーバ機能を使用できます。
管理サーバが動作していない場合でも管理対象サーバを起動できます。その場合、管理対象サーバは、起動時のコンフィグレーションとしてドメインのコンフィグレーション ファイルのローカル コピーを使用し、その後で、管理サーバに定期的に接続しようとします。接続したら、コンフィグレーションの状態を管理サーバのものと同期させます。
管理サーバを実行せずに管理対象サーバを起動する方法については、『サーバの起動と停止の管理』の「管理対象サーバ独立モード」を参照してください。管理サーバを再起動する方法については、『サーバの起動と停止の管理』の「サーバ障害の回避とサーバ障害からの回復」を参照してください。
管理対象サーバは、ビジネス アプリケーション、アプリケーション コンポーネント、Web サービス、およびそれらに関連付けられたリソースをホストします。また、パフォーマンスを最適化するため、ドメインのコンフィグレーション ドキュメントの読み取り専用のコピーを保持します。管理対象サーバを起動すると、そのコンフィグレーション ドキュメントを管理サーバに保持されているドキュメントと同期させるため、そのドメインの管理サーバに接続します。
アプリケーションのパフォーマンス、スループット、または高可用性を向上させる必要のあるプロダクション環境では、複数の管理対象サーバがクラスタとして動作するようにコンフィグレーションできます。クラスタは、同時に動作し、共同で高度なスケーラビリティと信頼性を実現する複数の WebLogic Server インスタンスの集まりです。クラスタ内では、ほとんどのリソースとサービスが (単一の管理対象サーバではなく) 各管理対象サーバに同じようにデプロイされています。その結果、フェイルオーバとロード バランシングが可能になります。1 つのドメインには、クラスタとしてコンフィグレーションされていない管理対象サーバだけでなく、複数の WebLogic Server クラスタを含めることができます。クラスタ化された管理対象サーバとクラスタ化されていない管理対象サーバの主な違いは、フェイルオーバとロード バランシングのサポートです。これらの機能は、管理対象サーバのクラスタでしか利用できません。WebLogic Server クラスタのメリットと機能については、『クラスタの使用』の「WebLogic Server のクラスタ化について」を参照してください。
ドメインには、管理サーバと管理対象サーバだけでなく、管理対象サーバやデプロイされたアプリケーションで必要となるリソースとサービスも含まれます。
アプリケーションでは、以下のリソースおよびサービスを使用できます。
ドメイン コンフィグレーションを設計する際には、以下の制限事項に注意してください。
複数のドメインを作成した場合、各ドメインは、そのドメイン専用のデータベース スキーマを参照する必要があります。コンフィグレーションしたリソースまたはサブシステムをドメイン間で共有することはできません。たとえば、あるドメインで JDBC データ ソースを作成した場合、別のドメインの管理対象サーバまたはクラスタでその接続プールを使用することはできません。代わりに、2 番目のドメインで同様のデータ ソースを作成する必要があります。また、2 つ以上のシステム リソースに同じ名前を付けることはできません。
  
|