Administration Console オンライン ヘルプ
|
 |
 |
|
[サーバに関する属性と Administration Console 画面のリファレンス]
ドメインの管理サーバが動作中であれば、Administration Console を使用してドメイン内のサーバの追加や削除を行い、ドメインのプロパティをすべてコンフィグレーションできます。また、Administration Console では、ドメインのパフォーマンスおよび全体的な状態をモニタすることもできます。
新しいドメインを作成する場合は、コンフィグレーション ウィザードを使用します。また、コンフィグレーション ウィザードを使うと、ドメイン内のサーバ インスタンスを起動することなく、ドメインのコンフィグレーションにおける多くの機能を変更できます。コンフィグレーション ウィザードでコンフィグレーションできるのは、ドメインの機能のサブセットのみです。詳細については、「コンフィグレーション ウィザードを使用したドメインの作成とコンフィグレーション」を参照してください。
以下の節では、Administration Console によるサーバの作成、コンフィグレーション、およびモニタの方法について説明します。
ドメインには、複数の WebLogic Server インスタンスを含めることができます。最小のドメインは、1 つだけの WebLogic Server インスタンスで構成されています。これは管理サーバとしても、管理対象サーバとしても機能します。このようなドメインは、アプリケーションの開発中には有用な場合がありますが、プロダクション環境での使用はお勧めしません。
管理対象サーバは、ドメインの管理サーバからコンフィグレーション データを取得する WebLogic Server インスタンスです。ドメイン内に管理対象サーバは複数作成できますが、管理サーバは 1 つしか作成できません。通常、サーバ インスタンスは、プロダクション環境でビジネス アプリケーションを実行するための管理対象サーバとして作成および起動します。この標準的なシナリオでは、管理サーバとして起動するサーバ インスタンスがビジネス アプリケーションを実行することはありません。ドメイン内のリソースを管理するのみです。信頼性とパフォーマンスを向上させるために、WebLogic Server を複数のコンピュータにインストールして、さまざまな WebLogic Server ホスト上で作成したサーバを実行できます。管理対象サーバと管理サーバの詳細については、「WebLogic Server のドメイン」を参照してください。
ドメインに対して定義したサーバ インスタンスはすべて、管理サーバとしても管理対象サーバとしても実行できます。サーバのコンフィグレーションには、このサーバを管理サーバまたは管理対象サーバとして指定する属性はありません。その代わり、ドメイン内で最初に起動するサーバ インスタンスが、常に管理サーバとして機能します。ドメイン内でさらに別のサーバを起動する場合は、管理対象サーバとして起動しなければなりません。詳細については、サーバの起動と停止を参照してください。
既存のドメインで管理対象サーバを作成するには、次の手順に従います。
管理サーバの起動を参照してください。
WebLogic 環境の各サーバ インスタンスは、それが置かれているドメインまたはクラスタに関係なく、それが管理サーバと管理対象サーバのどちらであるかにも関係なく、その名前がユニークでなければなりません。 ドメイン内では、各サーバ、マシン、クラスタ、JDBC 接続プール、仮想ホスト、および他の一切のリソース タイプに、ユニークな名前を指定する必要があります。また、これらにドメインと同じ名前を付けることはできません。
サーバ名は、サーバ上にデプロイするアプリケーションの URL の一部ではなく、識別用にのみ使用する。Administration Console にサーバ名が表示される。WebLogic Server コマンド ライン ユーティリティまたは API を使用している場合、この名前でサーバを識別する。
左ペインの [サーバ] ノードに、新しいサーバが表示されます。新しいサーバのコンフィグレーション データで、ドメインの config.xml ファイルが更新されます。
サーバのクローンの作成では、元のサーバと同じ属性を持つ新しいサーバ インスタンスを作成します。
左ペインの [サーバ] ノードに、新しいサーバが表示されます。新しいサーバのコンフィグレーション データで、ドメインの config.xml ファイルが更新されます。
サーバを削除すると、そのサーバに関連するコンフィグレーション データがドメインのコンフィグレーション ファイル (config.xml) から削除されます。削除されるデータを確認するには、Administration Console の左ペインでサーバを選択します。右ペインに表示されるデータがすべて削除されます。たとえば、サーバ用に作成したネットワーク チャネルはすべて削除されますが、サーバにデプロイされているアプリケーションや EJB は削除されません。
現在アクティブなサーバは削除できません。したがって、Administration Console が管理サーバ上で動作している場合、Administration Console で管理サーバを削除することはできません。詳細については、管理サーバの削除を参照してください。
固定サービスを実行しているサーバは削除できません。そのようなサーバを削除するには、先にサービスを移行可能な対象に移行する必要があります。「固定サービスの移行」を参照してください。
管理サーバとして使用しているサーバ インスタンスを削除するには、次の手順に従います。
java weblogic.Server コマンドによる管理サーバの起動を参照してください。
各 WebLogic Server インスタンスには、プロトコル、リスン アドレス、およびリスン ポートのデフォルト設定があります。これら設定を介して WebLogic Server にアクセスできます。これらの設定は、一括してデフォルト ネットワーク チャネルと呼ばれます。デフォルト ネットワーク チャネルには、2 つのリスン ポートがあります。1 つは非 SSL 要求を受信するリスン ポート、もう 1 つは SSL 要求を受信するリスン ポートです。いずれかのポートを無効にできますが、最低 1 つのポートは有効にしなければなりません。
以下の節では、サーバ インスタンスのデフォルト ネットワーク チャネルをコンフィグレーションする方法について説明します。
さまざまな接続要件に対応するために、またはシステム リソースおよびネットワーク リソースの利用効率を高めるために、追加のネットワーク チャネルをコンフィグレーションできます。追加のネットワーク チャネルのコンフィグレーションについては、「ネットワーク リソースのコンフィグレーション」を参照してください。
サーバには次の URL からアクセスできます。 protocol://listen-address:listen-port
デフォルト ネットワーク チャネルでは、サーバ インスタンスと通信するためのプロトコルを複数サポートしています。デフォルトでは、クライアントは HTTP および HTTPS プロトコルでサーバ インスタンスと通信します。BEA ユーティリティ (weblogic.Admin コマンド ライン ユーティリティなど) を使用すると、独自の T3 および T3S プロトコルでサーバに接続することもできます。
以下の節では、WebLogic Server インスタンスの通信プロトコルを有効化およびコンフィグレーションする方法について説明します。
HTTP プロトコルをコンフィグレーションするサーバ インスタンスは、実行中である必要はありません。実行中に [HTTP] タブで設定を変更した場合は、再起動の必要があります。[プロトコル｜一般] タブでの変更は、サーバを再起動しなくても有効になります。
HTTP プロトコルをコンフィグレーションするには、次の手順に従います。
管理サーバの起動を参照してください。
また、「HTTP トンネリングのための WebLogic Server の設定」も参照してください。
T3 プロトコルをコンフィグレーションするサーバ インスタンスは、実行中である必要はありません。実行中の場合、T3 プロトコルの設定の変更はすべて直ちに有効になります。
T3 プロトコルをコンフィグレーションするには、次の手順に従います。
管理サーバの起動を参照してください。
注意: これらの設定は、サーバのデフォルト ネットワーク コンフィグレーションの全プロトコルに適用されます。「デフォルト ネットワーク チャネル」を参照してください。
注意: これらの設定は、トンネリングをサポートするサーバのデフォルト ネットワーク コンフィグレーションの全プロトコルに適用されます。
注意: デフォルト チャネルを経由して送信されるメッセージには、発信元または送信先のホストに関する DNS 情報を含めることができます。 ネットワーク アドレス変換 (NAT) が有効になっているファイアウォールを経由して T3 接続が確立されると、ファイアウォールの内側のネットワーク コンフィグレーションに関する情報が漏洩するおそれがあります。 この問題は、ファイアウォールを経由した T3 接続を行なわないようにすることで回避できます。
IIOP (Internet Inter-ORB Protocol) プロトコルを利用すると、異なるプログラミング言語で記述された分散プログラムをインターネット経由で通信できるようになります。アプリケーションでの RMI-IIOP の使用については、『WebLogic RMI over IIOP プログラマーズ ガイド』を参照してください。
IIOP プロトコルを有効化およびコンフィグレーションするサーバ インスタンスは、実行中である必要はありません。実行中の場合、手順完了後に再起動する必要があります。
IIOP プロトコルを有効化し、コンフィグレーションするには、次の手順に従います。
管理サーバの起動を参照してください。
注意: これらの設定は、サーバのデフォルト ネットワーク コンフィグレーションの全プロトコルに適用されます。「デフォルト ネットワーク チャネル」を参照してください。
WebLogic jCOM は、WebLogic Server にデプロイされる Java または J2EE オブジェクトと、Microsoft Office 製品ファミリ内で利用できる Microsoft ActiveX コンポーネント、Visual Basic オブジェクト、C++ オブジェクトなどの COM 環境または DCOM 環境との双方向アクセスを可能にするソフトウェア ブリッジです。WebLogic jCOM の詳細については、『WebLogic jCOM プログラマーズ ガイド』を参照してください。
jCOM プロトコルを有効化およびコンフィグレーションするサーバ インスタンスは、実行中である必要はありません。実行中の場合、手順完了後に再起動する必要があります。
jCOM プロトコルを有効化し、コンフィグレーションするには、次の手順に従います。
管理サーバの起動を参照してください。
サーバには次の URL からアクセスできます。 protocol://listen-address:listen-port
デフォルトでは、サーバのリスン アドレス属性は未定義になっており、次のいずれかのリスン アドレスでサーバにアクセスできます。
サーバ インスタンスが localhost としてアクセスできる必要があり (たとえば、localhost に接続する管理スクリプトを作成する場合など)、リモート プロセスからもアクセスできる必要がある場合は、リスン アドレスを空白にしておきます。サーバの有効なリスン アドレスを制限する場合は、リスン アドレスを指定する際のガイドラインとして表 330-2 を参照してください。
注意: マルチホーム Windows NT マシンの場合、リスン アドレスを未定義のままにするか、または DNS 名を指定すると、サーバ インスタンスは利用可能なすべての IP アドレスにバインドされます。
リスン アドレスをコンフィグレーションするサーバ インスタンスは、実行中である必要はありません。実行中の場合、手順完了後に再起動する必要があります。
Administration Console でリスン アドレスをコンフィグレーションするには、次の手順に従います。
管理サーバの起動を参照してください。
サーバには次の URL からアクセスできます。 protocol://listen-address:listen-port
各 WebLogic Server インスタンスでは、デフォルト ネットワーク チャネルでリスン ポートを 2 つ定義します。1 つは (HTTP や T3 などのプロトコルによる) 通常の非セキュアな要求用のリスン ポート、もう 1 つは (HTTPS や T3S などのプロトコルによる) セキュアな要求用のリスン ポートです。
注意: デフォルトでは、サーバ インスタンスはデモ用証明書を使用して、セキュア ポートからの要求を認証します。プロダクション環境では、SSL をコンフィグレーションして認証局からの証明書を使用する必要があります。『WebLogic Security の管理』の「SSL プロトコルのコンフィグレーション」を参照してください。
デフォルトの非 SSL リスン ポートまたは SSL リスン ポートは無効にできます。ただし、サーバに 1 つまたは複数のネットワーク チャネルを作成する場合でも、最低 1 つのリスン ポートが有効でなければなりません。
任意の有効なポート番号を指定できますが、ポート 80 を指定する場合は、HTTP 経由でリソースにアクセスするために使用する HTTP リクエストのポート番号を省略できます。たとえば、リスン ポートとしてポート 80 を定義した場合、http://hostname:portnumber/myfile.html の代わりに、http://hostname/myfile.html の形式を使用できます。
一部のオペレーティング システムでは、ポート 80 へのアクセスは、特権のあるユーザまたはグループ ID によって実行されるプロセスに限定されます。このような場合は、Post-Bind UID または Post-Bind GID を定義した UNIX マシンにサーバ インスタンスを割り当てることができます。詳細については、「マシン」を参照してください。
1 台のコンピュータ上で WebLogic Server のインスタンスを複数、実行する場合は、各インスタンスでユニークなリスン ポートとリスン アドレスの組み合わせを使用する必要があります。マルチホーム コンピュータ (複数の IP アドレスを通じてアクセスできるコンピュータ) では、同じリスン ポートを使用して、サーバごとにリスン アドレスにユニークな IP アドレスを使用できます。コンピュータが複数の IP アドレスをサポートしていない場合は、アクティブなインスタンスごとに別々のリスン ポートを使用する必要があります。
リスン ポートをコンフィグレーションするサーバ インスタンスは、実行中である必要はありません。実行中の場合、手順完了後に再起動する必要があります。
Administration Console でリスン ポートをコンフィグレーションするには、次の手順に従います。
接続要件の変更に対応するために、またはシステム リソースおよびネットワーク リソースの利用効率を高めるために、カスタム ネットワーク チャネルをコンフィグレーションできます。「ネットワーク リソースのコンフィグレーション」を参照してください。
注意: このサーバがクラスタに属している場合は、「クラスタにおけるネットワーク チャネルのコンフィグレーション」を参照してください。
カスタム ネットワーク チャネルをコンフィグレーションするサーバ インスタンスは、実行中である必要はありません。実行中の場合、手順完了後に再起動する必要があります。
Administration Console を使ってカスタム ネットワーク チャネルをコンフィグレーションするには、次の手順に従います。
管理サーバの起動を参照してください。
通常、プロダクション環境では、開発環境よりセキュリティの要件がかなり厳しくなります。ネットワーク環境がより複雑になり、モニタおよび可用性に対する要求も大きくなります。
最初は開発環境用にコンフィグレーションしたサーバを、プロダクション環境に遷移させる論理的手順の概要を以下に示します。
Windows または Linux プラットフォームでは、WebLogic JRockit SDK の JVM を使用することをお勧めします。この JVM では最大限の動作パフォーマンスが得られますが、初期の起動サイクルにかかる時間が他の JVM より長いことがあります。
実行時モードはドメイン全体にわたる設定です。 各管理対象サーバは、起動する際に管理サーバのモードを参照して、実行時モードを決定します。 デフォルトでは、すべてのサーバは開発モードで実行されます。 ドメインがプロダクション モードで実行されるようにコンフィグレーションすると、その設定は、管理サーバによってドメインの config.xml ファイルに保存されます。
既存のドメインのモードを変更するのではなく、最初にドメインを作成するときにモードを設定しておくことをお勧めします。 「プロダクション モードと開発モード」を参照してください。
ドメイン内のすべてのサーバが動作するモードを変更するには、次の手順に従います。
管理サーバの起動を参照してください。
以下の節では、その他のコンフィグレーション タスクについて説明します。
管理対象サーバ独立 (MSI) レプリケーションをコンフィグレーションするサーバ インスタンスは、実行中である必要はありません。実行中の場合、手順完了後に再起動する必要があります。
ドメインのコンフィグレーション ファイルをレプリケートするように管理対象サーバをコンフィグレーションするには、次の手順に従います。
管理対象サーバは、起動時に管理サーバと通信して、そのコンフィグレーション情報を取得しようとします。起動時に管理サーバと通信できない場合は、直接コンフィグレーション ファイルおよびセキュリティ ファイルを読み込んでコンフィグレーション情報を取得できます。このような方法で起動する管理対象サーバは、管理対象サーバ独立 (MSI) モードで動作しています。MSI モードの詳細については、「管理対象サーバ独立モード」を参照してください。
MSI を無効化するサーバ インスタンスは、実行中である必要はありません。実行中の場合、手順完了後に再起動する必要があります。
以下のタスクでは、サーバのパフォーマンスおよび状態をモニタします。
WebLogic Server のモニタの詳細については、「WebLogic Server ドメインのモニタ」を参照してください。
WebLogic Server Administration Console では、サーバ インスタンスのコンフィグレーションおよび状態情報を視覚的にわかりやすい形式で表示できます。
モニタするサーバ インスタンスは、動作している必要があります。WebLogic Server では、パフォーマンスの統計はアーカイブしません。
Administration Console でサーバ インスタンスをモニタするには、次の手順に従います。
サーバの起動と停止を参照してください。
サーバ インスタンスが実行されているプラットフォームを判断するには、次の手順に従います。
JRockit 仮想マシン (VM) でサーバを実行している場合、基盤となる JRockit VM および VM をホストするコンピュータのメモリとプロセッサに関する実行時データを表示できます。
JRockit VM をモニタするには、次の手順に従います。
管理サーバの起動を参照してください。
特定のメソッドの処理時間など、VM に関する詳細データを表示するには、JRockit 管理コンソールを使用します。JRockit 管理コンソールを使用する場合、サーバの起動時に -XManagement 起動オプションを指定する必要があります(VM のモニタに WebLogic Server Administration Console を使用する場合、このオプションは不要です)。詳細については、JRockit ドキュメントの Web ページを参照してください。
サーバでは、サブシステムが正常に機能しない場合に、サブシステムの重要な側面をモニタしてレポートすることもできます。ノード マネージャでサーバが動作している場合、サブシステムが異常なサーバを自動的に再起動できます。
自動状態モニタするサーバ インスタンスは、実行中である必要はありません。実行中の場合、手順完了後にノード マネージャを使用して再起動する必要があります。
管理対象サーバをモニタ、停止、および再起動するようにノード マネージャの機能をコンフィグレーションするには、次の手順に従います。
|
|
|
![[サーバ] フォルダの名前をクリック](wwimages/click-on-server.gif "[サーバ] フォルダの名前をクリック")
をクリックします。 
をクリックします。 