1. Oracle WebLogic Server ドメイン構成の理解
  2. Oracle WebLogic Serverドメインの理解

2 Oracle WebLogic Serverドメインの理解

Oracle WebLogic Serverドメインとそのコンテンツについて学習します。コンテンツには管理サーバーと、通常は管理対象サーバーが1つ以上含まれています。

次のトピックでは、WebLogic Serverドメインの概要、ドメインの内容、およびドメイン構成に関する特定の制限事項について説明します。

ドメインとは

Oracle WebLogic Serverの管理ドメインは、Oracle WebLogic Serverリソースの論理的に関連したグループです。

ドメインには、管理サーバーと呼ばれる特殊なOracle WebLogic Serverインスタンスが含まれます。管理サーバーでは、ドメイン内のすべてのリソースを一元的に構成および管理します。通常は、管理対象サーバーと呼ばれるOracle WebLogic Serverインスタンスも含めてドメインを構成します。Webアプリケーション、EJB、Webサービスなどのリソースは管理対象サーバーにデプロイし、管理サーバーは構成や管理の目的にのみ使用します。

ドメインの構成

単一のOracle WebLogic Serverインストールを使用して複数のドメインを作成および実行したり、複数のインストールを使用して単一のドメインを実行したりできます。

図2-1に、単一インストールに基づく複数のドメインと、単一インストールのための複数のドメインを示します。

図2-1 Oracle WebLogic Serverインストールとドメイン

図2-1の説明が続きます
「図2-1 Oracle WebLogic Serverインストールとドメイン」の説明

インストールされたOracle WebLogic Serverをどのようなドメインに構成するかは、ビジネス上のニーズによって異なります。システム管理者の責任範囲、アプリケーションの境界、サーバーを実行するマシンの設置場所などに応じて、複数のドメインを定義できます。また、ドメインを1つにして、すべてのOracle WebLogic Server管理アクティビティを一元化することも可能です。

特定のビジネス上のニーズやシステム管理者の慣習に応じて、次のような条件に基づいてドメインの構成を決定することができます。

  • アプリケーションの論理的な区分。たとえば、ショッピング・カートのようなエンドユーザー機能専用のドメインと、バックエンドの会計アプリケーション専用のドメインを持つことができます。

  • 物理的な場所。企業の所在地や支店ごとに別々のドメインを作成できます。物理的な場所ごとに、別々のOracle WebLogic Serverインストールが必要です。ドメインは、複数の物理ホストにまたがる複数のドメイン・ディレクトリから構成できます。それらはすべて、同じドメインに構成する必要があります。

  • サイズ。ドメインをより効率的に管理したり、別々のシステム管理者が管理したりできるように、ドメインを小さな単位で構成することができます。一方、1つのドメインや少数のドメインにした方が、構成の一貫性を保ちやすくなります。

単一のサーバー・インスタンスから構成される単純なドメインを作成できます。この単一のインスタンスは管理サーバーとして動作し、開発中のアプリケーションをホストします。Oracle WebLogic Serverと一緒にインストールできるwl_serverドメインはこのタイプのサンプル・ドメインです。

ドメインの内容

Oracle WebLogic Serverドメインは、管理サーバーと管理対象サーバー、および管理対象サーバーやデプロイされたアプリケーションで必要となるリソースとサービスで構成されています。

図2-2に、管理サーバー、3つのスタンドアロンの管理対象サーバー、3つの管理対象サーバーを含むクラスタで構成されたプロダクション環境を示します。

図2-2 ドメインの内容

図2-2の説明が続きます
「図2-2 ドメインの内容」の説明

ドメインの範囲と目的は多種多様ですが、ほとんどのOracle WebLogic Serverドメインには、この節で説明するコンポーネントが含まれます。

管理サーバー

管理サーバーは、ドメイン全体の構成の一元的な制御エンティティとして動作します。ドメインの構成ドキュメントを管理し、構成ドキュメントでの変更を管理対象サーバーに配布します。また、ドメイン内のすべてのリソースを一元的に監視するための場所として使用することもできます。

管理サーバーと相互作用するには、Oracle WebLogic Serverの理解のシステム管理ツールおよびAPIの概要にリストされている管理ツールのいずれかを使用します。ドメイン構成の変更の詳細は、Oracle WebLogic Serverの理解のシステム管理を参照してください。

各Oracle WebLogic Serverドメインには、管理サーバーとして機能する1つのサーバー・インスタンスが必要です。

管理サーバーの詳細と、Oracle WebLogic ServerのJMX管理システムにおける管理サーバーの役割については、Oracle WebLogic Serverの理解のシステム管理を参照してください。

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

管理サーバーで障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。ただし、ドメインの構成は変更できなくなります。ホスト・マシン上のハードウェアまたはソフトウェアに障害が発生したために管理サーバーに障害が発生した場合、同じマシン上の他のサーバー・インスタンスも同様に影響を受けることがあります。ただし、管理サーバー自体で障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。

管理対象のサーバー・インスタンスが(クラスタリングされているかいないかには関係なく)動作しているときにドメインの管理サーバーが使用できなくなっても、その管理対象サーバーは処理を続けます。そして、定期的に管理サーバーへの再接続を試行します。ドメインにクラスタリングされたサーバー・インスタンスがある場合は、管理サーバーに障害が発生しても、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバー機能を使用できます。

管理サーバーが動作していない場合でも管理対象サーバーを起動できます。その場合、管理対象サーバーは、起動時の構成としてドメインの構成ファイルのローカル・コピーを使用し、その後で、管理サーバーに定期的に接続しようとします。接続したら、構成の状態を管理サーバーのものと同期させます。

管理サーバーを実行せずに管理対象サーバーを起動する方法については、Oracle WebLogic Serverサーバーの起動と停止の管理で、管理対象サーバーの独立モードを参照してください。管理サーバーを再起動する方法については、Oracle WebLogic Serverサーバーの起動と停止の管理で、サーバー障害の回避とサーバー障害からの回復を参照してください。

管理対象サーバーと管理対象サーバー・クラスタ

管理対象サーバーは、ビジネス・アプリケーション、アプリケーション・コンポーネント、Webサービス、およびそれらに関連付けられたリソースをホストします。また、パフォーマンスを最適化するため、ドメインの構成ドキュメントの読取り専用のコピーを保持します。管理対象サーバーを起動すると、その構成ドキュメントを管理サーバーに保持されているドキュメントと同期させるため、そのドメインの管理サーバーに接続します。

アプリケーションのパフォーマンス、スループット、または高可用性を向上させる必要のあるプロダクション環境では、複数の管理対象サーバーがクラスタとして動作するように構成できます。クラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のOracle WebLogic Serverインスタンスで構成されます。クラスタ内では、ほとんどのリソースとサービスが(単一の管理対象サーバーではなく)各管理対象サーバーに同じようにデプロイされています。1つのドメインには、クラスタとして構成されていない複数の管理対象サーバーだけでなく、複数のOracle WebLogic Serverクラスタを含めることができます。クラスタリングされた管理対象サーバーとクラスタリングされていない管理対象サーバーの主な違いは、フェイルオーバーとロード・バランシングのサポートです。これらの機能は、管理対象サーバーのクラスタでしか利用できません。Oracle WebLogic Serverクラスタのメリットと機能の詳細は、Oracle WebLogic Serverクラスタの管理のWebLogic Serverのクラスタリングの理解を参照してください。

リソースとサービス

ドメインには、管理サーバーと管理対象サーバーだけでなく、管理対象サーバーやデプロイされたアプリケーションで必要となるリソースとサービスも含まれます。

管理対象サーバーでは、以下のリソースを使用できます。

  • マシン定義 - 特定の物理的なハードウェアを識別します。マシン定義によって、コンピュータとそのコンピュータがホストする管理対象サーバーが関連付けられます。ノード・マネージャは、障害の発生した管理対象サーバーを再起動する際に、この情報を使用します。また、クラスタリングされた管理対象サーバーは、レプリケートされたセッション・データを格納する最適な場所を選択する際に、この情報を使用します。ノード・マネージャの詳細は、Oracle WebLogic Serverノード・マネージャの管理のノード・マネージャの概要を参照してください。

  • ネットワーク・チャネル - 管理対象サーバーがクライアントとの通信に使用するデフォルトのポート、プロトコル、およびプロトコル設定を定義します。ネットワーク・チャネルを作成したら、ドメイン内の任意の数の管理対象サーバーとクラスタに割り当てることができます。『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。

  • 仮想ホスト - Oracle WebLogic Serverインスタンス(サーバー)またはクラスタが応答するホスト名のセットを定義します。仮想ホスト機能を使用する場合、DNSを使用して、サーバーまたはクラスタのIPアドレスにマップする1つまたは複数のホスト名を指定します。また、各仮想ホストでどのWebアプリケーションを処理するかについても指定します。

アプリケーションでは、以下のリソースおよびサービスを使用できます。

  • セキュリティ・プロバイダ - 認証や認可など、セキュリティの特定の側面を処理するモジュール・コンポーネントです。

  • リソース・アダプタ - エンタープライズ情報システム(EIS)に固有のシステム・ライブラリで、EISへの接続性を提供します。

  • 診断およびモニター・サービス。

  • JDBCデータ・ソース - アプリケーションからデータベースへの接続を可能にします。

  • メール・セッション。

  • XMLパーサーおよびトランスフォーマ・ファクトリのXMLエンティティ・キャッシュおよびレジストリ。

  • メッセージング・サービス(JMSサーバー、ストア・アンド・フォワード・サービスなど)。

  • 永続ストア - データ(永続JMSメッセージなど)を格納する物理リポジトリです。具体的には、JDBC対応のデータベースまたはディスク・ベースのファイルのどちらかです。

  • 起動クラス - システム全体のカスタム・サービスをアプリケーションに提供するために作成するJavaプログラムです。

  • ワーク・マネージャ - ユーザーが定義したルールに基づいて、アプリケーションが実行する作業の優先順位を決定し、実行時の実際のパフォーマンスを監視します。Oracle WebLogic Serverドメイン全体のワーク・マネージャを作成したり、特定のアプリケーション・コンポーネントのワーク・マネージャを作成したりできます。

  • ワーク・コンテキスト - アプリケーションからリモート・コンテキストに、プロパティをリモート呼出しに含めずに渡すことを可能にします。

ドメイン構成の制限

ドメイン構成を設計する際には、記載されている制限事項に注意してください。

  • 各ドメインには、管理アクティビティを実行するための固有の管理サーバーが必要です。WebLogic Server管理コンソールまたはFusion Middleware Control (FMWC)を使用して管理やモニターの作業を行うときに、複数のドメインを切り替えることができますが、その場合は、別々の管理サーバーに接続します。

  • クラスタ内のすべての管理対象サーバーは、同じドメインに存在する必要があります。クラスタを複数のドメインで分割することはできません。「クラスタとドメイン間の関係」を参照してください。

  • ドメイン内のすべての管理対象サーバーで、同じバージョンのOracle WebLogic Serverソフトウェアを実行する必要があります。管理サーバーで実行するソフトウェアは、ドメイン内の管理対象サーバーと同じバージョンでも、それ以降のパッチ・セットでもかまいません。

  • サーバー・インスタンスはドメインと同じ名前にはできません。

複数のドメインを作成した場合、各ドメインは、そのドメイン専用のデータベース・スキーマを参照する必要があります。構成したリソースまたはサブシステムをドメイン間で共有することはできません。たとえば、あるドメインでJDBCデータ・ソースを作成した場合、別のドメインの管理対象サーバーまたはクラスタでその接続プールを使用することはできません。かわりに、2番目のドメインで同様のデータ・ソースを作成する必要があります。また、2つ以上のシステム・リソースに同じ名前を付けることはできません。

ドメイン名およびサーバー名の制限

ドメインまたはサーバー・インスタンスに名前を付ける場合、記載されている制限および考慮事項に注意してください。

  • ドメインおよびサーバー・インスタンスには、英数字からなる名前を使用します。

  • 英数字以外に、有効なドメイン名またはサーバー名に使用できる文字は次のとおりです。

    • アンダースコア (_)

    • ハイフン(-)

    • ピリオド ()

  • サーバー・インスタンスごとに一意の名前を使用します。ドメイン内では、サーバー・インスタンス、マシン、クラスタ、JDBC接続プール、仮想ホストおよびその他のリソース・タイプを含むすべての構成オブジェクトが一意の名前である必要があり、ドメイン内で同じ名前を使用することはできません。

  • サーバー名は、識別用にのみ使用します。サーバー名は、サーバー・インスタンスにデプロイされるアプリケーションのURLの一部として使用されることはありません。サーバー名は管理コンソールまたはFusion Middleware Controlに表示されます。WebLogic Serverコマンドライン・ユーティリティを使用する場合、サーバー・インスタンスを識別するためにサーバー名を使用します。

  • サーバー・インスタンスの作成後、サーバー名を変更することはできません。新しい名前を使用するには、サーバー・インスタンスのクローンを作成し、そのクローンに新しい名前を付けます。

開発モードと本番モード

WebLogicドメインを構成して、開発モードまたは本番モードのいずれかで実行できます。本番モードでは、セキュア本番モードを有効にすることによってドメインをさらに保護できます。

セキュリティおよびロギングに関するデフォルトの設定は、ドメイン・モードにより決定されます。開発モードでは、セキュリティ構成が比較的緩和されます。起動IDファイルを使用して管理サーバーを起動するか、autodeployディレクトリを使用してアプリケーションをデプロイできます。本番モードでは、アプリケーションのデプロイおよび管理サーバーの起動にはユーザー名とパスワードが必要になるなど、セキュリティ構成がより厳しくなっています。セキュア本番モードでは、デフォルトの認可とロール・マッピング・ポリシーがより厳しくなり、セキュリティ構成のデフォルトがよりセキュアになるため、本番ドメインのセキュリティが非常に高くなります。

開発モード、本番モードおよびセキュア本番モードのデフォルト設定の間には、次のような相違もあります。

  • 実行キュー内のスレッド数

  • ログ設定(ログ・ローテーション中に保存されるファイルの最大数、ログ・ローテーションをトリガーするログ・ファイルの最少サイズ、起動時にログをローテーションするかどうかなど)

  • サーバーのライフサイクル操作のタイムアウトのデフォルト

  • SNMPセキュリティ・レベル

  • サーブレット再ロードのチェック間隔

選択したドメイン・モードによってドメインのデフォルトのセキュリティ構成が決定される方法の詳細は、『Oracle WebLogic Server本番環境の保護』のドメイン・モードがデフォルトのセキュリティ構成に与える影響に関する項を参照してください。このトピックでは、SSLのデフォルト設定、管理ポートとリスニング・ポート、監査、ロギング、内部アプリケーションのデプロイメント、ドメイン構成のロックおよびその他の構成設定が、有効なドメイン・モードによってどのように異なるかについて説明します。

ノート:

本番モードでは、Webサービス・テスト・クライアントを有効にしないことをお薦めします。『Webサービスの管理』のWebサービス・テスト・クライアントの使用に関する項を参照してください。

ドメイン・モードの変更

ドメイン・モードは、ドメイン作成時に構成でき、後からいつでも変更できます。構成ウィザードを使用したドメイン・モードの選択方法の詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードに関する項を参照してください。

WebLogic Serverでは、本番モードから開発モード、開発モードから本番モード、および本番モードからセキュア本番モードへのドメイン変更をサポートしています。WebLogic Server管理コンソールを使用した開発モードから本番モードへのドメインの変更方法については、『Oracle WebLogic Server Administration Consoleオンラインヘルプ』の本番モードへの変更に関する項を参照してください。

本番モードに変更したら、本番環境のセキュリティ標準を高めるために、セキュア本番モードを有効にすることをお薦めします。ただし、12.2.1.3より前に作成されたドメインをセキュア本番モードで実行するようにアップグレードすることはできません。セキュア本番モードに構成できるのは、12.2.1.3以降で作成されたドメインのみです。

次のいずれかの方法を使用して、本番ドメインをセキュア本番モードで実行するように変更できます。

  • WebLogic Server管理コンソールを使用して、本番ドメインに対してセキュア本番モードを有効にします。『Oracle WebLogic Server Administration Consoleオンラインヘルプ』の本番ドメインの保護に関する項を参照してください。

  • Fusion Middleware Controlを使用してセキュア本番モードを有効にし、ドメインの関連するセキュリティ設定を構成します。『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のドメインのセキュリティの構成に関する項を参照してください。

  • setOption WLSTコマンドを使用します。ドメインの作成中に、WLSTコマンドでServerStartModeオプションを使用して、サーバーをセキュア本番モードで起動できます。『WebLogic Server WLSTコマンド・リファレンス』のsetOptionに関する項を参照してください。

  • WLSTオンラインを使用して、ドメインに対してセキュア本番モードを有効にします。『WebLogic Scripting Toolの理解』のWLSTオンラインを使用した既存のWebLogicドメインの更新に関する項を参照してください。

既存の本番ドメインのセキュリティを強化するには、次のことを行います。
  1. -Xverifyフラグの値をnoneからallに変更するために、ドメインの起動スクリプトを変更します。この変更によって、バイトコードの検証が有効化されます。バイトコードの検証の詳細は、Java Security Overview (http://docs.oracle.com/javase/8/docs/technotes/guides/security/overview/jsoverview.html)の「Java Language Security and Bytecode Verification」を参照してください。
  2. ドメイン内の管理サーバーおよび各管理対象サーバーを再起動します。各サーバー・インスタンスを再起動するためのコマンドに、-Dweblogic.system.RemoveBootIdentity=true引数を含めます。これにより、起動IDファイルが削除されます。起動IDファイルは、構成を本番モードに変更した後の最初の再起動時にのみ、削除する必要があります。次の方法のいずれかを使用できます。

    • 個別のコマンド・シェルを開き、各サーバー・インスタンスのweblogic.Server起動コマンドにこの引数を含めます。

    • JAVA_OPTIONS変数を定義し、-Dweblogic.system.RemoveBootIdentity=trueを含めた後、サーバーの起動スクリプトを呼び出します。

ノート:

ドメインを開発モードから本番モードに変更した場合、次のようになります。

  • ドメイン起動スクリプト(および-Xverifyフラグの値)は変わりません。

  • boot.propertiesファイルは引き続き使用されます。