この章では、Oracle WebLogic Serverドメインとその構成について説明します。構成には管理サーバーと、通常は管理対象サーバーが1つ以上含まれています。
この章には次の項が含まれます:
Oracle WebLogic Serverの管理ドメインは、Oracle WebLogic Serverリソースの論理的に関連したグループです。ドメインには、管理サーバーと呼ばれる特殊なOracle WebLogic Serverインスタンスが含まれます。管理サーバーでは、ドメイン内のすべてのリソースを一元的に構成および管理します。通常は、管理対象サーバーと呼ばれるOracle WebLogic Serverインスタンスも含めてドメインを構成します。Webアプリケーション、EJB、Webサービスなどのリソースは管理対象サーバーにデプロイし、管理サーバーは構成や管理の目的にのみ使用します。
単一のOracle WebLogic Serverインストールを使用して複数のドメインを作成および実行したり、複数のインストールを使用して単一のドメインを実行したりできます。図2-1を参照してください。
インストールされたOracle WebLogic Serverをどのようなドメインに構成するかは、ビジネス上のニーズによって異なります。システム管理者の責任範囲、アプリケーションの境界、サーバーを実行するマシンの設置場所などに応じて、複数のドメインを定義できます。また、ドメインを1つにして、すべてのOracle WebLogic Server管理アクティビティを一元化することも可能です。
特定のビジネス上のニーズやシステム管理者の慣習に応じて、次のような条件に基づいてドメインの構成を決定することができます。
アプリケーションの論理的な区分。たとえば、ショッピング・カートのようなエンドユーザー機能専用のドメインと、バックエンドの会計アプリケーション専用のドメインを持つことができます。
物理的な場所。企業の所在地や支店ごとに別々のドメインを作成できます。物理的な場所ごとに、別々のOracle WebLogic Serverインストールが必要です。
サイズ。ドメインをより効率的に管理したり、別々のシステム管理者が管理したりできるように、ドメインを小さな単位で構成することができます。一方、1つのドメインや少数のドメインにした方が、構成の一貫性を保ちやすくなります。
単一のサーバー・インスタンスから構成される単純なドメインを作成できます。この単一のインスタンスは管理サーバーとして動作し、開発中のアプリケーションをホストします。通常、単一のサーバー・ドメインは開発環境やテスト環境で使用されますが、このドメイン・タイプは本番使用を完全にサポートし、負荷の軽いアプリケーションに適している場合があります。Oracle WebLogic Serverと一緒にインストールできるwl_server
ドメインはこのタイプのサンプル・ドメインです。
図2-2に、管理サーバー、3つのスタンドアロンの管理対象サーバー、3つの管理対象サーバーを含むクラスタで構成されたプロダクション環境を示します。
ドメインの範囲と目的は多種多様ですが、ほとんどの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管理コンソールを使用して管理やモニターの作業を行うときに、複数のドメインを切り替えることができますが、その場合は、別々の管理サーバーに接続します。
クラスタ内のすべての管理対象サーバーは、同じドメインに存在しなければなりません。クラスタを複数のドメインに分割することはできません。
ドメイン内のすべての管理対象サーバーで、同じバージョンのOracle WebLogic Serverソフトウェアを実行する必要があります。管理サーバーで実行するソフトウェアは、ドメイン内の管理対象サーバーと同じバージョンでも、それ以降のパッチ・セットでもかまいません。
サーバー・インスタンスはドメインと同じ名前にはできません。
複数のドメインを作成した場合、各ドメインは、そのドメイン専用のデータベース・スキーマを参照する必要があります。構成したリソースまたはサブシステムをドメイン間で共有することはできません。たとえば、あるドメインでJDBCデータ・ソースを作成した場合、別のドメインの管理対象サーバーまたはクラスタでその接続プールを使用することはできません。かわりに、2番目のドメインで同様のデータ・ソースを作成する必要があります。また、2つ以上のシステム・リソースに同じ名前を付けることはできません。
サーバー・インスタンスに名前を付ける場合、次の制限および考慮事項に注意してください。
サーバー・インスタンスには、英数字からなる名前を使用します。有効なサーバー名には、空白や次の文字を含めることはできません。
カンマ(,)
等号(=)
コロン(:)
アスタリスク(*)
パーセント(%)
疑問符(?)
スラッシュ(/)
サーバー・インスタンスごとに一意の名前を使用します。ドメイン内では、サーバー・インスタンス、マシン、クラスタ、JDBC接続プール、仮想ホストおよびその他のリソース・タイプを含むすべての構成オブジェクトが一意の名前である必要があり、ドメイン内で同じ名前を使用することはできません。
サーバー名は、識別用にのみ使用します。サーバー名は、サーバー・インスタンスにデプロイされるアプリケーションのURLの一部として使用されることはありません。サーバー名は管理コンソールまたはFusion Middleware Controlに表示されます。WebLogic Serverコマンドライン・ユーティリティを使用する場合、サーバー・インスタンスを識別するためにサーバー名を使用します。
サーバー・インスタンスの作成後、サーバー名を変更することはできません。新しい名前を使用するには、サーバー・インスタンスのクローンを作成し、そのクローンに新しい名前を付けます。
WebLogicドメインを構成して、開発モードまたは本番モードのいずれかで実行できます。セキュリティおよびロギングに関するデフォルトの設定は、ドメイン・モードにより決定されます。開発モードでは、セキュリティ構成が比較的緩和されます。起動IDファイルを使用して管理サーバーを起動するか、autodeploy
ディレクトリを使用してアプリケーションをデプロイできます。本番モードでは、アプリケーションのデプロイおよび管理サーバーの起動にはユーザー名とパスワードが必要になるなど、セキュリティ構成がより厳しくなっています。
本番モードのデフォルト設定と、ドメイン・モードのデフォルト設定の間には、次のような相違もあります。
実行キュー内のスレッド数
ログ設定(ログ・ローテーション中に保存されるファイルの最大数、ログ・ローテーションをトリガーするログ・ファイルの最少サイズ、起動時にログをローテーションするかどうかなど)
サーバーのライフサイクル操作のタイムアウトのデフォルト
SNMPセキュリティ・レベル
サーブレット再ロードのチェック間隔
開発および本番モードのデフォルト・チューニング値の詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』の開発モードと本番モードのデフォルト・チューニング値に関する項を参照してください。
ドメイン・モードは、ドメイン作成時に構成した後、いつでも変更できます。構成ウィザードを使用したドメイン・モードの選択方法の詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードに関する項を参照してください。
WebLogic Server管理コンソールを使用した開発モードから本番モードへのドメインの変更方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの本番モードへの変更に関する項を参照してください。(WebLogic Serverでは、本番モードから開発モードへのドメインの変更もサポートしています)。
注意: 本番モードでは、Webサービス・テスト・クライアントを有効にしないことをお薦めします。Webサービス・テスト・クライアントの詳細は、『Webサービスの管理』のWebサービス・テスト・クライアントの使用に関する項を参照してください。 |
本番モードに変更したら、本番ドメインのセキュリティを高めるために、次のことを行うことをお薦めします。
ドメイン起動スクリプトを変更し、-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」を参照してください。
ドメイン内の管理サーバーおよび各管理対象サーバーを再起動します。各サーバー・インスタンスを再起動するためのコマンドに、-Dweblogic.system.RemoveBootIdentity=true
引数を含めます。これにより、起動IDファイルが削除されます。起動IDファイルは、構成を本番モードに変更した後の最初の再起動時にのみ、削除する必要があります。次の方法のいずれかを使用できます。
個別のコマンド・シェルを開き、各サーバー・インスタンスのweblogic.Server
起動コマンドにこの引数を含めます。
JAVA_OPTIONS
変数を定義し、-Dweblogic.system.RemoveBootIdentity=true
を含めた後、サーバーの起動スクリプトを呼び出します。
注意: ドメインを開発モードから本番モードに変更した場合、次のようになります。
|