ドメインの構成

WebLogic Remote Consoleを使用して、管理サーバーを介してWebLogic Serverドメインの構成を変更します。

管理サーバーへの接続

管理サーバーを介して実行中のWebLogic Serverドメインに接続し、WebLogic Remote Consoleを使用してその構成を管理できます。

  1. 管理サーバーを起動します。

    手順については、「Oracle WebLogic Serverのサーバーの起動と停止の管理」の「サーバーの起動と停止」を参照してください。

  2. 「プロバイダ」ドロワーを開き、「その他」をクリックします。

  3. リストから、「管理サーバー接続プロバイダの追加」を選択します。

  4. 管理サーバーの名前を入力します。

    この名前はプロバイダのプロジェクト・リストに表示されるため、接続先のドメインを識別できます。

  5. WebLogic Server 14.1.2.0.0以降を実行しているドメインの場合のみ: ブラウザを使用して認証を外部サービスに委任するようにWebLogic Serverを構成した場合は、Web認証の使用オプションを有効にします。 それ以外の場合は、ステップ6の説明に従って、選択を解除したままにして、ローカル・ユーザー・アカウントの資格証明を入力します。

    詳細については、「Web認証の構成」を参照してください。

  6. ドメイン内のユーザー・アカウントのユーザー名とパスワードを入力します。

    実行する予定のタスクに必要な権限を持つユーザーでログインします。 認可されていない変更を防ぐために、WebLogic Remote Consoleは、ユーザーがロールに基づいてどのタスクおよび画面を使用できるかを制限します。

  7. URLフィールドに、管理サーバーのURLを入力します。

    例えば:

    http://localhost:7001

    管理サーバーのmanagement/*エンドポイントがWebLogic Remote Consoleからアクセス可能であることを確認します。 管理サーバーのエンドポイントがファイアウォール、ロード・バランサ、または外部で使用できない場合は、エンドポイントを手動で公開する必要があります。

    ホストWebLogic Remote Consoleを使用している場合は、rconsole/*エンドポイントも公開する必要があります。

  8. WebLogic Remote Consoleで、管理サーバーへの接続時に期限切れ、信頼できない、または欠落している証明書に関する警告を無視する場合は、「安全でない接続にします」チェック・ボックスを選択します。 この設定は、開発環境またはデモンストレーション環境でのみ有効にすることをお薦めします。

  9. このWebLogic Serverドメインが別のネットワークに存在する場合でも、そのドメインとWebLogic Remote Consoleの間の通信を容易にできます。 「プロキシの上書き」フィールドに、プロキシ・サーバー・アドレスを入力します。

    すべての管理サーバー接続に適用されるプロキシ・アドレスを設定することもできます。 「プロキシ・サーバーを使用した接続」を参照してください。

  10. 「OK」をクリックします。

正常に接続した後、WebLogic Serverドメインの管理を開始できます。 WebLogic Remote Consoleがドメイン構造をどのように表すかを理解するには、「管理サーバー・プロバイダのパースペクティブ」を参照してください。

「プロバイダ」ドロワーで管理サーバー・プロバイダの接続詳細を表示および更新できます。

SSL/TLSを使用した接続

SSL/TLSを使用してWebLogic Serverドメインに接続する場合は、WebLogic Remote Consoleでいくつかの追加の構成ステップを実行する必要があります。

管理サーバーへの接続時にドメインURLにHTTPSを指定した場合、WebLogic Remote ConsoleはSSL/TLSを使用してドメインと通信します。

SSL/TLS接続では、信頼構成が基礎となるJDK JSSEサポートによって処理されるWebLogic Serverドメインへの信頼が必要です。 デフォルトでは、JDKはJDKで提供されているcacertsトラスト・ストアを使用します。 ドメインに追加の信頼が必要な場合、個別の信頼が必要な場合、またはWebLogic Serverデモ・トラストを使用している場合は、SSL/TLS信頼を構成する必要があります。

WebLogic Remote Consoleを使用してトラスト・ストアのタイプとロケーションを指定するか(後述)、keytoolユーティリティを使用して、必要なトラスト証明書をJDKに付属のcacertsトラスト・ストアにインポートできます。 「Java Development Kitバージョン17ツール仕様」の「keytoolコマンド」を参照してください。

  1. WebLogic Remote Consoleで、「ファイル」、「設定」に移動します。 (macOSでは、WebLogic Remote Console、「設定」に移動します。)

  2. 「ネットワーキング」セクションの「トラスト・ストア・タイプ」フィールドに、トラスト・ストアのアルゴリズム名を入力します。 指定したトラスト・ストア・タイプによっては、追加のフィールドが表示される場合があります。

    特定のアルゴリズム名については、「Javaセキュリティ開発者ガイド」の「JDKプロバイダのドキュメント」を参照してください。

  3. 「トラスト・ストア・ファイルの選択」をクリックして、トラスト・ストアのファイルのロケーションを参照します。

  4. 「トラスト・ストア・キー」の横にある「変更」をクリックし、トラスト・ストア・キーのシークレットを入力します。

  5. 「保存」をクリックしてシークレットを追加します。

  6. 「保存」をクリックして変更を適用します。

Web認証の構成

ユーザーの認証をWebLogic Remote Consoleから外部認証サービスに委任できます。

デフォルトでは、WebLogic Remote ConsoleはBasic HTTP認証スキームを使用してユーザーを認証します。 Basic認証を別の認証スキームに置換する場合(場合によってはシングル・サインオン・フローをサポートする場合)、「Web認証の使用」オプションを有効にして、ブラウザを使用して代替ログイン・プロセスを介してユーザーを送信できます。

web認証が有効な場合、デフォルトのBasic認証HTTPヘッダーは、REST通信にWebLogic Serverトークンを使用して置き換えられます。 ユーザーは、接続された管理サーバーのドメインURLを取得し、リモート・コンソール・ヘルパー・コンテキスト・パス(デフォルトはconsole)を追加して生成されたログイン・エンドポイントに送信され、次にloginが追加されます。 たとえば、完全なURLは次のようになります: https://administrationServer:7002/console/login。

URLで、プロトコルがhttpsで、ポート番号が7002 (SSL/TLSリスニング・ポートのデフォルトのポート番号)であることを確認します。 web認証を使用するには、SSL/TLSを構成する必要があります。

WebLogic Remote ConsoleのWeb認証は、WebLogic Serverに含まれるアプリケーションであるWebLogic Remote Consoleヘルパーによって容易になります。 必要に応じて、web認証プロセスにあわせてこのアプリケーションの設定をカスタマイズできます。

組込みLDAPサーバー(WebLogic認証プロバイダ)またはサポートされている別のLDAPまたはRDBMS認証プロバイダを介して認証されるユーザー・アカウントの場合、それ以降の構成を実行する必要はありません。

ただし、仮想ユーザーを認証する場合は、WebLogic Remote ConsoleからのREST通信では仮想ユーザーの使用が直接サポートされないため、これらのユーザーをLDAPまたはRDBMS認証プロバイダに追加してWebLogic Serverに認識させる必要があります。

web認証を設定する一般的なプロセスは次のとおりです:

  1. ドメインのSSL/TLSを構成します。 「SSL/TLSの設定」を参照してください。

  2. 認証プロバイダを構成します。

    「Oracle WebLogic Serverのセキュリティの管理」で、次を参照してください:

  3. 管理サーバーのログイン・エンドポイントと管理エンドポイント(それぞれconsole/およびmanagement/)の両方にWebLogic Remote Consoleからアクセスできることを確認します。管理サーバーのエンドポイントがファイアウォール、ロード・バランサ、または外部で使用できない場合は、それらのエンドポイントを手動で公開する必要があります。

  4. リモート・コンソール・ヘルパーをカスタマイズします。

    1. 「編集ツリー」で、「環境」、「ドメイン」の順に移動します。

    2. 「拡張フィールドの表示」をクリックします。

    3. 必要に応じて、次のリモート・コンソール・ヘルパー属性を編集します:

      • リモート・コンソール・ヘルパーが有効
      • リモート・コンソール・ヘルパー・コンテキスト・パス
      • リモート・コンソール・ヘルパーCookie名
      • リモート・コンソール・ヘルパー・セッション・タイムアウト
      • リモート・コンソール・ヘルパーの保護されたCookieが有効
      • リモート・コンソール・ヘルパー・トークン・タイムアウト

    4. 「保存」をクリックします。

  5. 仮想ユーザーの認証をサポートする場合は、各仮想ユーザーをデフォルトの認証プロバイダ(WebLogic認証プロバイダ)または構成された別のLDAPまたはRDBMSプロバイダに追加する必要があります。 WebLogic Remote ConsoleからのREST通信では、仮想ユーザーの使用を直接サポートしていません。

    ユーザーを、管理者、オペレータなどの職責を達成する権限を持つグループのメンバーとして必ず追加してください。

    WebLogic認証プロバイダに仮想ユーザーを追加する場合、「ユーザーの作成」の説明に従ってWebLogic Remote Consoleを使用してユーザーを作成できます。 そうでない場合は、プロバイダに仮想ユーザーを追加するには、プロバイダに固有の外部ツールを使用する必要があります。

  6. WebLogic Remote Consoleを使用して管理サーバーに接続する場合:

    1. 「Web認証の使用」オプションを有効にします。

    2. 管理サーバーURLがhttpsおよびSSL/TLSリスニング・ポートを使用していることを確認します(デフォルトは7002です)。 管理ポートが有効になっている場合、デフォルトのポート値は9002になります。

      例えば:

      • https://administrationServer:7002
      • https://administrationServer:9002

WebLogic Remote ConsoleのSAML 2.0 SSOの有効化

WebLogic ServerをSAML 2.0サービス・プロバイダ・サイトとして構成する場合は、このサイトを使用して、WebLogic Remote Consoleのシングル・サインオン(SSO)機能を実装できます。

WebLogic Remote Consoleでのweb認証の設定に必要なステップの概要は、「Web認証の構成」を参照してください。

  1. 「Oracle WebLogic Serverのセキュリティの管理」の「SAML 2.0シングル・サインオンのサービス・プロバイダ・サイトの構成」の説明に従って、WebLogic ServerをSAML 2.0サービス・プロバイダ・サイトとして構成します。

    次のことを確認してください:

    • アイデンティティ・プロバイダ・パートナのリダイレクトURIのリストに/console/loginを追加します。 「Oracle WebLogic Serverのセキュリティの管理」の「リダイレクトURIの構成」を参照してください。

    • httpsおよびSSL/TLSリスニング・ポートを使用して、公開されたサイトURLを保護します。 たとえば、https://wls.example.com:7002/saml2です。 「Oracle WebLogic Serverのセキュリティの管理」の「SAML 2.0一般サービスについて」を参照してください。

  2. 仮想ユーザーの認証をサポートする場合は、LDAPまたはRDBMS認証プロバイダを構成し、各仮想ユーザーをそのプロバイダに追加する必要があります。 WebLogic Remote ConsoleからのREST通信では、仮想ユーザーの使用を直接サポートしていません。

    WebLogic認証プロバイダに仮想ユーザーを追加する場合、「ユーザーの作成」の説明に従ってWebLogic Remote Consoleを使用してユーザーを作成できます。 そうでない場合は、プロバイダに仮想ユーザーを追加するには、プロバイダに固有の外部ツールを使用する必要があります。

    ユーザーを管理者グループのメンバーとして追加してください。

  3. SAML 2.0 SSOをサポートするようにリモート・コンソール・ヘルパー属性を更新します。

    1. WebLogic Remote Consoleの「編集ツリー」で、「環境」、「ドメイン」の順に移動します。

    2. 「拡張フィールドの表示」をクリックします。

    3. 次のリモート・コンソール・ヘルパー属性の値を指定どおりに更新します:

      • リモート・コンソール・ヘルパーCookie名: JSESSIONID
      • リモート・コンソール・ヘルパー保護Cookie有効: false

    4. 「保存」をクリックします。

プロキシ・サーバーを使用した接続

WebLogic Remote Consoleと、別のネットワークに存在するWebLogic Serverドメイン間の通信を容易にするために、プロキシ・サーバーの設定を構成する必要がある場合があります。

すべての管理サーバー接続に適用されるグローバル・プロキシ・サーバーを構成することも、プロキシ・サーバー設定を各管理サーバー接続に個別に割り当てることもできます。

グローバル設定と個別設定の組合せを構成することもできます。個々のプロキシ・サーバー設定によってグローバル・プロキシ・サーバー設定がオーバーライドされます。

  • すべての管理サーバー接続に影響するグローバル・プロキシ・サーバーを適用するには:

    1. 「ファイル」、「設定」の順に移動します。 (macOSでは、WebLogic Remote Console、「設定」に移動します。)

    2. 「ネットワーキング」セクションの「プロキシ・アドレス」フィールドに、ホスト名とポート番号の両方を含むプロキシ・サーバーのアドレスを入力します。

    3. 「保存」をクリックして変更を適用します。

    Javaシステム・プロパティを使用して複数のグローバル・プロキシ・サーバーを作成することは可能ですが、お薦めしません。 複数のグローバル・プロキシ・サーバーを構成すると、予期しない動作や不要な動作が発生する可能性があります。 これは、プロキシ・サーバーが異なるプロトコルを使用している場合でも適用されます: Javaシステム・プロパティを使用してHTTPSを使用するプロキシ・サーバーを追加し、その後SOCKSを使用する別のプロキシ・サーバーを追加する場合、WebLogic Remote ConsoleはSOCKSプロキシ・サーバーを無視します。

    「設定」ダイアログ・ボックスのプロキシ・サーバー値は、Javaシステム・プロパティを使用して設定されたグローバル・プロキシ・サーバー設定よりも優先されます。

  • プロキシ・サーバー設定を単一の管理サーバー接続に適用するには:

    1. 「プロバイダ」ドロワーを開きます。

    2. プロキシ・サーバーを構成する管理サーバー・プロバイダの横にある「設定」をクリックします。

    3. 「プロキシの上書き」フィールドに、ホスト名とポート番号の両方を含むプロキシ・サーバーのアドレスを入力します。

    4. 「OK」をクリックします。

ネットワーク・タイムアウト設定の変更

WebLogic Serverドメインで使用される接続および読取りタイムアウト制限のデフォルト設定は、WebLogic Remote Consoleから変更できます。

  1. 「ファイル」、「設定」の順に移動します。 (macOSでは、WebLogic Remote Console、「設定」に移動します。)

  2. 「ネットワーキング」セクションの「管理サーバー接続タイムアウト」フィールドで、間隔(ミリ秒)を指定して、WebLogic Remote Consoleがドメインへの接続の成功を待機する時間を決定します。 デフォルトは10秒(10 000ミリ秒)です。

  3. 「管理サーバーの読取りタイムアウト」フィールドで、WebLogic Remote Consoleがサーバーからのレスポンスを待機する時間を決定する間隔(ミリ秒単位)を指定します。 デフォルトは20秒(20 000ミリ秒)です。

  4. 「保存」をクリックして変更を適用します。

ネットワーク・タイムアウト設定を変更すると、主な影響はコンソール・スレッドのレスポンス時間になりますが、タイムアウトが発生するとアプリケーションはデータを表示しません。 タイムアウトは、サーバーの実行時モニタリング・アクション中など、WebLogic Serverの初期化または実行時間が長いリクエスト中に発生する可能性が高くなります。

ドメインへの接続でのホスト名検証の無効化

WebLogicデモ・トラストを使用してドメインに接続する場合、ホスト名の検証を無効にする必要がある場合があります。

ホスト名検証が無効になっている場合、WebLogic Remote Consoleは、接続先のURLのホスト名が、サーバーがSSL接続の一部として返送するデジタル証明書のホスト名と一致することを検証しません。

  1. 「ファイル」、「設定」の順に移動します。 (macOSでは、WebLogic Remote Console、「設定」に移動します。)

  2. 「ネットワーキング」セクションの「ホスト名検証の無効化」で、ホスト名検証を無効にするにはYesを、ホスト名検証を有効にするにはNoを選択します。

  3. 「保存」をクリックして変更を適用します。

Javaシステム・プロパティの使用

WebLogic Remote Consoleでは、特定の設定が使用できない場合、コンソールをカスタマイズするためのJavaシステム・プロパティの使用がサポートされています。

Javaシステム・プロパティをWebLogic Remote Consoleに追加するには:

  1. 「ファイル」、「設定」の順に移動します。 (macOSでは、WebLogic Remote Console、「設定」に移動します。)
  2. 「その他のJavaシステム・プロパティ」セクションで、+をクリックして新しい行を追加し、=で区切られた名前と値のペアとしてJavaシステム・プロパティを入力します。 たとえば、server.port=8092です。

プロパティを削除するには、行を選択して-をクリックします。

例

サポートされているJavaシステム・プロパティの例をいくつかリスト
使用 構文

webブラウザのサポートに必要な場合は、SameSite cookie属性を設定します。

WebLogic Remote ConsoleがWebLogic Serverドメインとの接続を確立すると、Webブラウザ・セッションでHTTP cookieが確立されます。

セキュリティ上の理由から、HTTP cookieのSameSite属性は、WebブラウザがHTTPセッションcookieを受け入れるように設定する必要がある場合があります。

両方のプロパティを設定します:

  • console.enableSameSiteCookieValue=true

  • console.valueSameSiteCookie=Lax|Strict

    デフォルトはLaxです。

JDKの代替のロケーションを指定します。

 javaPath=pathToJDK

WebLogic Remote Consoleが収集するロギング情報を制御できるように、カスタム・ロギング構成ファイルを指定します。

カスタム・ロギング構成ファイルは、構成ファイルのJava形式に従う必要があります。 Javaロギング構成ファイルの例は、$JAVA_HOME/conf/logging.propertiesを参照してください。

カスタム・ロギング構成ファイルで問題が発生した場合、WebLogic Remote Consoleはデフォルトのロギング構成ファイルを使用するようにフォールバックします。 STDOUT には、使用されたファイルを示すログ・メッセージが含まれます。

java.util.logging.config.file=<path-to-logging.properties>

WebLogic Serverドメインの構成

WebLogic Remote Consoleを使用して管理サーバーに接続すると、ドメインの構成を変更できるようになります。

WebLogic Serverのドメイン構成の包括的な説明は、「Oracle WebLogic Serverのドメイン構成について」の「Oracle WebLogic Serverドメインの理解」を参照してください。

WebLogic Remote Consoleでは、通常、ドメインに構成変更を適用する2つのステップ・プロセスです。

ステップ1: 編集

ドメインを変更すると、「保留中」状態で保存されます。 ドメインではアクティブではありませんが、他の領域で変更内容を失うことなく変更を加えることができます。また、WebLogic Remote Consoleからログアウトしても、これらの変更はドメインに保持されます。

保留中の変更はショッピング・カートに表示されます。 ショッピング・カートで、「変更の表示」をクリックします。 ショッピング・カートに特定の変更が表示されない場合は、「WebLogic Remote Console拡張機能のインストール」を参照してください。

WebLogic Remote Consoleは、編集セッション中に他のユーザーがドメインを変更できないようにする構成ロックを適用することで、編集が他のユーザーによって上書きされないように保護します。 変更をコミット(破棄)するまで、このロックは保持されます。

ステップ2: コミット

変更内容に問題がない場合は、変更をドメインに適用するためにコミットする必要があります。 ショッピング・カートを開き、「変更のコミット」をクリックします。

一部の構成変更は、すぐにドメインに適用されます - これらは動的変更と呼ばれます。 その他の構成変更を有効にするには、サーバーの再起動が必要で、動的ではない変更と呼ばれます。 サーバーの再起動に必要なアイコン再起動が必要ですが、動的でない属性の横に表示されます。

WebLogic Remote Consoleは、変更のコミット後に構成ロックを解放します。

動的でない変更を適用するために、すべてのサーバーを再起動する必要がない場合があります。 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動して、再起動が必要なサーバーを確認します。

構成ファイルのバックアップ

WebLogic Serverを設定して、保留中の変更がコミットされる前にドメインの既存の構成状態を保存できます。 変更を元に戻す必要がある場合、WebLogic Serverには、バックアップとして使用可能な構成ファイルの以前のセット(中央構成ファイルconfig.xmlを含む)があります。

  1. 「編集ツリー」で、「環境」、「ドメイン」の順に移動します。

  2. 「拡張フィールドの表示」をクリックします。

  3. 「構成アーカイブ使用可能」オプションをオンにします。

  4. 「アーカイブ構成数」フィールドに、保持するアーカイブ・ファイルの数を入力します。

    アーカイブ・ファイルの最大数に達すると、古いアーカイブ・ファイルは破棄されます。

  5. 「保存」をクリックします。

以前の構成ファイルのバックアップは、DOMAIN_HOME/configArchiveディレクトリ、config-1.jar、config-2.jarなどのJARファイルに保存されます。 アーカイブされたファイルはローテーションされ、最新のファイルのサフィクスが最大数になります。 詳細は、「Oracle WebLogic Serverのドメイン構成の理解」のconfigArchiveを参照してください。

管理サーバー・プロバイダのパースペクティブ

管理サーバー・プロバイダは複数のパースペクティブに分割され、それぞれがWebLogic Serverドメインの異なる管理領域に焦点を当てています。

  • 編集ツリー: WebLogic Serverドメインの編集可能なビュー。 このパースペクティブは、変更を加えてドメインにコミットする場合に使用します。
  • 構成ビュー・ツリー: WebLogic Serverドメインの読取り専用ビュー。 変更を行わずにドメインの現在の設定を表示する場合は、このパースペクティブを入力します。
  • モニタリング・ツリー: 実行中のドメインの実行時統計の概要。 サーバーごとの統計を表示することも、ドメイン内のすべてのサーバー間で集計することもできます。 たとえば、Server1で実行されているアプリケーションと、1つ以上のサーバーで実行されているアプリケーションを比較します。 モニタリング・ツリーには、サーバーやアプリケーションの起動や停止などの制御操作も用意されています。
  • セキュリティ・データ・ツリー: セキュリティ・レルム内のセキュリティ・プロバイダのデータを編集可能なビュー。 これには、ユーザー、グループ、ポリシーなどが含まれます。

どうすればよいですか。

ドメイン構成の大部分は、「編集ツリー」のパースペクティブで実行されます。 ただし、モニタリング・ツリーまたはセキュリティ・データ・ツリーのパースペクティブで実行されるタスクもあります。 これらのタスクはコミット・ステップを必要とせず、変更が保存された直後にアクティブになります。

表1. 各パースペクティブでのタスク。 様々な管理タスクを担当するパースペクティブを識別します。
タスク ツリーを編集 モニタリング・ツリー セキュリティ・データ・ツリー
サーバーの起動または停止   ✔  
アプリケーションをデプロイします ✔    
アプリケーションの開始または停止   ✔  
サーバー、クラスタおよびマシンの構成 ✔    
アクセス制御の管理     ✔
ユーザー、グループ、ロール、ポリシーの管理     ✔
セキュリティ・プロバイダの構成 ✔    
データベース接続の構成 ✔    
メッセージングの構成 ✔    
ドメインの問題の診断   ✔  
SSL/TLSの構成 ✔    
ダッシュボードの作成   ✔  

アクセス制限

WebLogic Serverドメインへの不正な変更を防止するために、WebLogic Remote Consoleはユーザーのロールに基づいてその機能を制限します。

権限が制限されたロールを持つユーザーとしてログインすると、WebLogic Remote Consoleによってユーザー・インタフェースが自動的に調整され、アクセス権のない領域が隠されます。 管理者ロールを持つユーザーは、WebLogic Remote Consoleへのフル・アクセス権を持ちます。

WebLogic Remote Consoleの完全なユーザー・インタフェースを表示する場合は、現在のロールに関係なく、「ファイル」、「設定」の順に開きます。 (macOSでは、WebLogic Remote Console、「設定」に移動します。) 「ロール・チェック」セクションで、「ロールに基づくコンテンツの制限」を「いいえ」に設定し、「保存」をクリックします。 権限が制限されたユーザーは、すべてのものを「参照」できるようになりましたが、そのロールの範囲を超えるアクションの実行はブロックされています。

「表2」には、管理者以外のロールで発生する可能性のある制限の例がいくつか示されています。

表2. ロールに基づくアクセス制限。 ロールに基づく制限の例をいくつか示します。
ロール 制限事項
デプロイヤ ユーザーはサーバー構成やドメイン構成を表示することはできますが、編集はできません。 また、一部のJDBCおよびJMSリソースを含む、アプリケーション・デプロイメントに関連する領域を変更することもできます。
モニター WebLogic Remote Consoleへのユーザー・アクセスは完全に読取り専用です。
オペレータ ユーザーはサーバーを起動および停止できますが、「ツリーの編集」パースペクティブは表示されません。

管理対象サーバーの構成

管理対象サーバーは、ドメインの管理サーバーを介して間接的に管理される下位サーバーです。

通常の本番環境では、ビジネス・アプリケーションをホストするためにドメイン内に1つ以上の管理対象サーバーを作成し、管理サーバーのみを使用して管理対象サーバーを構成および監視する必要があります。

管理対象サーバーは、スタンドアロン・インスタンスとして構成することも、クラスタに編成することもできます。 「Oracle WebLogic Serverの理解」の「管理対象サーバーおよび管理対象サーバー・クラスタ」を参照してください。

管理対象サーバーの作成

  1. 「編集ツリー」で、「環境」、「サーバー」の順に移動します。

  2. 「新規」をクリックします。

  3. 新しいサーバー名を入力します。

    「Oracle WebLogic Serverのドメイン構成の理解」の「ドメインおよびサーバー名の制限」を参照してください。

  4. 設定は、既存のサーバーから新しいサーバーにコピーできます。 「他のサーバーから設定をコピー」ドロップダウン・リストからサーバーを選択します。

    サーバーの設定のみがコピーされます。 チャネルなどの子はコピーされません。 WebLogic Server REST APIでサポートされていない設定もコピーされません。

  5. 「作成」をクリックします。

このプロセスでは、スタンドアロン管理対象サーバーが作成されます。 管理対象サーバーをクラスタに追加する場合は、「クラスタへの管理対象サーバーの割当て」の手順に従います。

管理対象サーバーの起動

WebLogic Remote Consoleから管理対象サーバーを起動します。

  1. 管理対象サーバーで使用するノード・マネージャを構成します。

    ノード・マネージャをすでに構成している場合は、次のステップにスキップできます。

    1. ノード・マネージャ実装を選択します。 「Oracle WebLogic Serverのノード・マネージャの管理」の「ノード・マネージャの実装」を参照してください。

    2. ノード・マネージャ実装を構成します。 「Oracle WebLogic Serverのノード・マネージャの管理」の「Javaノード・マネージャの構成」または「スクリプト・ベースのノード・マネージャの構成」を参照してください。

    3. 管理対象サーバーをホストするコンピュータでノード・マネージャを起動します。

  2. ノード・マネージャと通信するように管理対象サーバーを構成します。

    管理対象サーバーとノード・マネージャ間の通信をすでに構成している場合は、次のステップにスキップできます。

    1. マシンの構成

    2. 「サーバー・インスタンスのマシンへの割当て」.

    3. 「管理対象サーバーの起動引数の構成」.

  3. 管理対象サーバーの起動モードを変更します。 デフォルトはRUNNINGです。 「起動モードの指定」を参照してください。

  4. 管理対象サーバーをホストするコンピュータでノード・マネージャを起動します。

    ノード・マネージャは、WebLogic Serverのカスタム・インストール・プロセスによって、WindowsシステムにWindowsサービスとしてオプションでインストールおよび起動されます。 ノード・マネージャが実行されていない場合は、コマンド・プロンプトまたはスクリプトを使用して手動で起動できます。 「Oracle WebLogic Serverのノード・マネージャの管理」の「ノード・マネージャの起動と停止」を参照してください。

  5. 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動します。

  6. 起動するサーバーを選択し、「開始」をクリックします。

ノード・マネージャによって、ターゲット・マシン上のサーバーが起動されます。 ノード・マネージャの起動順序が終了すると、サーバーの状態が「状態」列に示されます。

管理対象サーバーの起動引数の構成

ほとんどの環境では、ノード・マネージャは起動オプションを指定せずにサーバーを起動できます。 ただし、WebLogic Serverクラス・パスにクラスを追加するなど、環境を変更した場合は、WebLogic Remote Consoleを使用してサーバーを起動する前に起動オプションを指定する必要があります。

  1. 「編集ツリー」で、「環境」、「サーバー」の順に移動します。

  2. 起動引数を構成する管理対象サーバーを選択します。

  3. 「拡張」タブで、「ノード・マネージャ」サブタブを選択します。

  4. サーバー・インスタンスを別のWebLogic Serverユーザー・アカウントで実行する場合は、「ユーザー名」および「パスワード」フィールドに既存のユーザーのユーザー名とパスワードを入力します。 ユーザーには、サーバーを起動する権限を持つロールが必要です。

    既存のユーザー名とパスワードは、WebLogic Remote Consoleまたは構成ウィザードを使用してサーバーを作成したときに指定した値です。

  5. ノード・マネージャによって提供されるデフォルト値を上書きする他のフィールドを更新します。

    ノード・マネージャのデフォルト値はWebLogic Remote Console 「置換」で、新しい値はデフォルト値に追加されません。 詳細は、「Oracle WebLogic Serverのノード・マネージャの管理」の「nodemanager.propertiesの確認」を参照してください。

    すべてのパスは、ノード・マネージャ・マシン上のパスを参照します。

    • 「クラスパス」フィールドに値を指定する場合は、管理対象サーバーの起動に必要なフル・クラス・パスを指定していることを確認してください。

    • 「引数」を追加する場合は、-Dweblogic.management.startupMode=MODEのように、各引数の前に-Dを追加してください。

      WebLogic Serverインスタンスの実行時動作を設定するJavaオプションの詳細は、「Oracle WebLogic Serverのコマンド・リファレンス」の「weblogic.Serverコマンドライン・リファレンス」、JAVA_OPTIONSの結合方法および重複値の処理方法の詳細は、「Oracle WebLogic Serverのノード・マネージャの管理」の「起動および停止スクリプトを使用するノード・マネージャの構成」を参照してください。

  6. 「保存」をクリックします。

  7. 該当する管理対象サーバーごとに繰り返します。

起動モードの指定

起動モードでは、サーバー・インスタンスが起動されるときの状態を指定します。 デフォルトでは、RUNNING状態から起動されます。

  1. 「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。

  2. 「一般」タブで、「拡張フィールドの表示」をクリックします。

  3. 「起動モード」フィールドに、次の起動モードのいずれかを(大文字で)入力します:

    • RUNNING (default): サーバーはクライアントにサービスを提供し、クラスタの完全なメンバーとして動作できます。
    • ADMIN: サーバーは稼働していますが、管理操作でのみ使用できるため、アプリケーションを実行するリスクなく、サーバーおよびアプリケーション・レベルの管理タスクを実行できます。
    • STANDBY: サーバーは、ドメイン全体の管理ポートでのみ管理リクエストをリスニングし、サーバー・インスタンスをRUNNINGまたはSHUTDOWN状態に遷移するライフサイクル・コマンドのみを受け入れます。 それ以外の管理リクエストは受け付けられません。 STANDBYを指定した場合、ドメイン全体の管理ポートも有効化する必要があります。 「ドメイン全体の管理ポートの構成」を参照してください。 「Oracle WebLogic Serverのサーバーの起動と停止の管理」の「サーバーのライフサイクルについて」を参照してください。

  4. 「保存」をクリックします。

クラスタの構成

WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。

クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。 クラスタを構成するサーバー・インスタンスは、同じマシン上で実行することも、異なるマシン上に配置することもできます。 クラスタの容量を増やすには、既存のマシン上のクラスタにサーバー・インスタンスを追加するか、またはクラスタにマシンを追加して増分サーバー・インスタンスをホストします。 クラスタ内の各サーバー・インスタンスでは、同じバージョンのWebLogic Serverが動作している必要があります。 「Oracle WebLogic Serverクラスタの管理」の「WebLogic Serverクラスタリングの理解」を参照してください。

また、アプリケーションのリソース・ニーズを満たすために動的にスケール・アップまたはスケール・ダウンできるサーバー・インスタンスで構成される動的クラスタを作成することもできます。 動的クラスタは、指定した数の生成された(動的)サーバー・インスタンスの構成を定義する単一のサーバー・テンプレートを使用します。 詳細は、「Oracle WebLogic Serverクラスタの管理」の「動的クラスタ」を参照してください。

クラスタの作成

WebLogic Serverクラスタを作成します。

  1. 「編集ツリー」で、「環境」、「クラスタ」の順に移動します。

  2. 「新規」をクリックします。

  3. クラスタの名前を入力します。

  4. 「作成」をクリックします。

クラスタへの管理対象サーバーの割当て

クラスタに既存の管理対象サーバーを追加できます。

  1. まだ作成していない場合は、クラスタを作成します。 「クラスタの作成」を参照してください。

  2. 管理対象サーバーを停止します。 実行中のサーバーのクラスタは変更できません。

  3. 「編集ツリー」で、「環境」、「サーバー」の順に移動します。

  4. クラスタに追加する管理対象サーバーを選択します。

  5. 「クラスタ」ドロップダウン・リストから、この管理対象サーバーを割り当てるクラスタを選択します。

  6. 「保存」をクリックし、変更をコミットします。

  7. 管理対象サーバーを起動します。

動的クラスタの作成

アプリケーションのリソース・ニーズに応じて動的にスケーリングするクラスタを作成します。

  1. まだ作成していない場合は、クラスタとサーバー・テンプレートを作成します。 「クラスタの作成」および「サーバー・テンプレートの作成」を参照してください。

  2. 「環境」、「クラスタ」、myClusterの順に移動し、「動的」タブを選択します。

  3. 「サーバー・テンプレート」ドロップダウン・リストからサーバー・テンプレートを選択します。

    サーバー・テンプレートがない場合、または新しいテンプレートを作成する場合は、「サーバー・テンプレート」ドロップダウン・リストの横にある「その他」をクリックして、「新規サーバー・テンプレートの作成」を選択します。 新しいサーバー・テンプレートの一意の名前を入力します。

  4. 「動的クラスタ・サイズ」フィールドに、この動的クラスタでのスケール・アップ操作に許可される実行中の動的サーバー・インスタンスの最大数を入力します。 この数は、「動的クラスタ・サイズ」と、スケール・アップ操作が可能な動的サーバー・インスタンスの追加数の合計です。

  5. 「サーバー名のプレフィクス」で、クラスタ内の動的サーバーに使用するネーミング規則を指定します。

  6. クラスタ内の動的サーバーのマシン間での分散方法を指定する場合は、「計算済マシン関連付けの有効化」をオンにして、「マシン名一致式」を構成します。

    マシン分布は、「マシン名一致式」で設定されたパターンによって決まります。 ドメイン内のマシンが式と一致した場合、これらの動的サーバーで使用されるマシン群に追加されます。 式は、照合するマシンを指定する値のカンマ区切りセットです。 この値は、マシン名と正確に一致することも、末尾の*を使用して複数のマシン名に一致させることもできます。 パターンを入力しない場合、ドメイン内のすべてのマシンが動的サーバーで使用可能になります。

  7. リスニング・ポートを計算するかどうかを指定する場合は、「計算済リスニング・ポートの有効化」をオンにします。

  8. 「保存」をクリックします。

クラスタのスケール・アップまたはスケール・ダウン方法を制御するために、クラスタでの弾力性の構成を検討してください。 詳細は、「Oracle WebLogic Serverの動的クラスタの拡張度の構成」の「動的クラスタの構成」を参照してください。

クラスタからのサーバーの削除

ドメインからサーバー・インスタンスを削除せずに、クラスタから管理対象サーバーを削除できます。

  1. 「編集ツリー」で、「環境」、「サーバー」の順に移動します。

  2. クラスタから削除する管理対象サーバーを選択して、スタンドアロン・サーバー・インスタンスにします。

  3. 「クラスタ」ドロップダウン・リストから、「なし」を選択します。

  4. 「保存」をクリックします。

シングルトン・サービスの定義

シングルトン・サービスとは、管理対象サーバーで実行されるサービスであり、1度にクラスタ内の1つのメンバー上でのみ使用可能になります。 WebLogic Serverでは、シングルトン・サービスを自動的に監視したり、あるサーバーから別のサーバーに移行したりできます。

  1. 「編集ツリー」で、「環境」、「シングルトン・サービス」の順に移動します。

  2. 「新規」をクリックします。

  3. シングルトン・サービスの名前を入力します。

  4. 「作成」をクリックします。

  5. 「クラスタ」ドロップダウン・リストから、このシングルトン・サービスを適用するクラスタを選択します。

  6. 「クラス名」フィールドで、クラスの完全修飾名を定義します。 クラスもサーバー・クラス・パスに含まれている必要があります。

    「クラス名」で指定されたクラスは、移行可能なシングルトン・サービスとして機能するシングルトン・サービス・インタフェースを実装する必要があります。 「Oracle WebLogic Serverクラスタの管理」の「サービス移行」を参照してください。

  7. 「追加の移行試行」フィールドに、構成可能なすべてのサーバー・インスタンスでサービスが1回以上失敗した後に、移行可能サービスに到達しようとする必要のある追加の試行回数を入力します。

  8. 「試行間のスリープ時間」フィールドに、移行の試行間隔を入力します。

  9. 「保存」をクリックします。

  10. このターゲットの移行動作を指定する場合は、「移行」タブに移動します。

    1. 「ユーザー優先サーバー」ドロップダウン・リストから、このシングルトン・サービスの優先サーバー・インスタンスを選択します。

    2. 「制約付き候補者サーバー」フィールドで、このシングルトン・サービス上のサービスのバックアップとして使用するクラスタ内のサーバー・インスタンスを選択します。 選択したサーバー・インスタンスを「使用可能」から「選択済」に移動します。

  11. 「保存」をクリックします。

デフォルトでは、シングルトン・サービスはクラスタ内のすべてのサーバーを反復処理して、移行の候補サーバーのリストを決定します。

サーバー・テンプレートの作成

サーバー・テンプレートは、一連のサーバー・インスタンスに適用できるデフォルト以外の設定および属性を定義します。

サーバー・テンプレートを作成してから管理対象サーバーに適用する場合、構成属性を1回指定してから、新しい属性設定をサーバー・インスタンスに伝播できます。それぞれを手動で構成する必要はありません。 属性を更新する必要がある場合は、サーバー・テンプレートの値を変更するだけで、そのサーバー・テンプレートを使用するすべてのサーバー・インスタンスで新しい値が有効になります。 サーバー・テンプレートをクラスタに追加して、クラスタ内のすべてのサーバーがサーバー・テンプレートを継承することもできます。 「Oracle WebLogic Serverのドメイン構成の理解」の「サーバー・テンプレート」を参照してください。

サーバー固有の属性を定義する必要がある場合、個別のサーバー・レベルでサーバー・テンプレートを簡単にオーバーライドできます。

  1. 「編集ツリー」で、「環境」、「サーバー・テンプレート」の順に移動します。

  2. 「新規」をクリックします。

  3. サーバー・テンプレートの一意の名前を入力します。

  4. 「作成」をクリックします

サーバー・テンプレートを作成した後は、従来の管理対象サーバーの構成と同様に、その属性を構成できます。

サーバー・テンプレートの適用

サーバー・テンプレートは、一元化されたロケーションの一連のサーバー・インスタンスの共通構成属性を定義します。 サーバー・テンプレートを管理対象サーバーまたはクラスタに適用すると、サーバー・インスタンスはサーバー・テンプレートから構成を継承します。

  • スタンドアロン管理対象サーバーにサーバー・テンプレートを適用するには:

    1. 「編集ツリー」で、「環境」、「サーバー」の順に移動します。

    2. サーバー・テンプレートを適用する管理対象サーバーを選択します。

    3. 「テンプレート」ドロップダウン・リストから、テンプレートを選択します。 「その他」をクリックして、新しいサーバー・テンプレートを作成および適用することもできます。

    4. 「保存」をクリックします。

  • サーバー・テンプレートをクラスタに適用するには:

    1. 「編集ツリー」で、「環境」、「クラスタ」の順に移動します。

    2. サーバー・テンプレートを適用するクラスタを選択します。

    3. 「テンプレート」ドロップダウン・リストから、テンプレートを選択します。 「その他」をクリックして、新しいサーバー・テンプレートを作成および適用することもできます。

    4. 「保存」をクリックします。

マシンの構成

マシンとは、1つ以上のWebLogic Serverインスタンスをホストするコンピュータの論理表現です。 管理対象サーバーは、それぞれ1台のマシンに割り当てる必要があります。

マシン構成プロセスの一部として、WebLogic Serverインスタンスの制御に使用されるプログラムであるノード・マネージャと通信するように、ドメイン内の各マシンも構成します。 単一のノード・マネージャ・インスタンスで、同一の物理的マシン上で実行されているすべてのサーバー・インスタンスが制御されます。 これらのインスタンスは、異なるクラスタ、ドメインなどに配置できます。 「Oracle WebLogic Serverのノード・マネージャの管理」の「ノード・マネージャについて」を参照してください。

  1. 「編集ツリー」で、「環境」、「マシン」の順に移動します。

  2. 「新規」をクリックします。

  3. 新しいマシンの名前を入力します。

  4. UNIXプラットフォームで実行するマシンを作成する場合は、「タイプ」ドロップダウン・リストから「UNIXマシン」を選択します。

  5. 「作成」をクリックします。

  6. 「環境」、「マシン」、myMachineの順に、新しいマシンの設定を構成します。

  7. 「ノード・マネージャ」タブで、次のプロパティを構成します:

    1. 「タイプ」ドロップダウン・リストで、ノード・マネージャのタイプを選択します。

    2. 「リスニング・アドレス」フィールドに、ノード・マネージャが受信リクエストをリスニングするDNS名またはIPアドレスを入力します。

      リスニング・アドレスをIPアドレスで定義する場合は、ノード・マネージャにアクセスする管理サーバーのホスト名検証を無効にする必要があります。 詳細および手順は、「Oracle WebLogic Serverのセキュリティの管理」および「ホスト名検証の有効化」の「ホスト名検証の使用」を参照してください。

    3. 「リスニング・ポート」フィールドに、ノード・マネージャが受信リクエストをリスニングするポート値を入力します。

    4. 「タイプ」をSSHまたはRSHに設定した場合、「ノード・マネージャ・ホーム」および「シェル・コマンド」フィールドに値も指定する必要があります。

    5. ノード・マネージャのデバッグを有効にする場合は、「デバッグ有効」をオンにします。

    6. 「保存」をクリックします。

新しいマシン・エントリでは、ここで、マシン上で実行されるWebLogic Serverインスタンスの指定に加えて、マシン上で実行されるノード・マネージャ・プロセスへの接続に必要な属性を指定します。

次に、「サーバー・インスタンスのマシンへの割当て」を参照してください。

サーバー・インスタンスのマシンへの割当て

管理対象サーバーを管理するためのノード・マネージャの設定プロセスの一環として、サーバー・インスタンスをマシンに割り当てる必要があります。

  1. 管理対象サーバーを停止します。 実行中のサーバーのマシンは変更できません。

  2. 「編集ツリー」で、「環境」、「サーバー」の順に移動します。

  3. マシンに割り当てる管理対象サーバーを選択します。

  4. 「マシン」ドロップダウン・リストで、このサーバーを割り当てるマシンを選択します。

  5. 「保存」をクリックします。

仮想ホストの構成

仮想ホストは、サーバーまたはクラスタが応答するホスト名のセットです。 仮想ホスト機能を使用する場合、DNSを使用して、サーバーまたはクラスタのIPアドレスにマップする1つまたは複数のホスト名を指定します。 また、それぞれの仮想ホストによって提供されるWebアプリケーションを指定します。

  1. 「編集ツリー」で、「環境」、「仮想ホスト」の順に移動します。

  2. 「新規」をクリックします。

  3. 仮想ホストの名前を入力します。

  4. 「作成」をクリックします。

  5. 「仮想ホスト名」フィールドに、この仮想ホストがリクエストを処理するホスト名を入力します。 改行を使用してホスト名を区切ります。

  6. 「ネットワーク・アクセス・ポイント名」フィールドに、この仮想ホストがHTTPリクエストを処理する専用サーバー・チャネル名(NetworkAccessPoint)を入力します。

  7. 「保存」をクリックします。

  8. HTTPタブで、必要に応じて仮想ホストのHTTP属性を構成します。 「保存」をクリックします。

  9. 「ログ」タブで、必要に応じて仮想ホストのデフォルト・ログ・ファイル設定を構成します。 「保存」をクリックします。

  10. 「ターゲット」タブで、この仮想ホストをデプロイするサーバーまたはクラスタを選択します。

  11. 「保存」をクリックします。

カスタム・クラスを使用したサーバーの構成

サーバー機能を拡張したり、サーバー・インスタンスの起動時または停止時に一部のタスクを実行するカスタムJavaクラスを作成できます。

これらの起動クラスまたは停止クラスは、システム・クラス・ローダーによってロードされるため、サーバー・インスタンス上のすべてのリソース(別のコンテナで管理されるリソースを含む)から利用できます。 たとえば、EJBおよびJMXクライアントは、そのコンテナが独自の、より高次のレベルのクラス・ローダーを使用している場合でも、起動クラスまたは停止クラスにアクセスすることができます。

これらはシステム・レベルのクラスであるため、サーバーのクラス・パスに配置する必要があります。 カスタム・クラスを複数のアプリケーションで使用可能にするが、クラスをシステム・レベルで使用可能にする必要がない場合は、それらをアプリケーション起動クラスとしてデプロイすることを検討してください。

詳細は、「Oracle WebLogic Serverのサーバーの起動と停止の管理」の「サーバー・レベルの起動および停止クラスの構成」を参照してください。

起動クラスの構成

サーバー機能を拡張したり、サーバー・インスタンスの起動時にタスクを実行するカスタムJavaクラスを作成できます。

  1. 「編集ツリー」で、「環境」、「起動クラス」の順に移動します。

  2. 「新規」をクリックします。

  3. 起動クラスの名前を入力し、「作成」をクリックします。

  4. 新しい起動クラスの構成ページの「クラス名」フィールドに、起動クラスの完全修飾名を入力します。

    次に例を示します: mycompany.myclasses.startupclass。

  5. 必要に応じて、その他の起動クラスの属性を変更します。

  6. 「保存」をクリックします。

  7. 「ターゲット」タブで、この起動クラスをデプロイするサーバー・インスタンスまたはクラスタを「選択済」に移動します。

  8. 「保存」をクリックします。

  9. 起動クラスは、デプロイされる各サーバーのクラス・パスに追加する必要があります。

  10. スクリプトを使用してサーバー・インスタンスを起動する場合は、次のステップを実行します。

    1. テキスト・エディタで起動スクリプトをオープンします。

    2. クラスパスを設定するコマンドで、クラス・ルート・パッケージを含むディレクトリのパスを追加し、スクリプトを保存します。

      たとえば、StartBrowserという名前の起動クラスをcom.mycompany.startupという名前のパッケージに作成し、そのクラス・ファイルを/myDomain/src/myJAR.jarという名前のJARファイルにアーカイブする場合、サーバーの起動スクリプトは/myDomain/src/myJAR.jarをサーバーのクラス・パスに追加する必要があります。

    3. サーバーを再起動します。

  11. ノード・マネージャを使用してサーバー・インスタンスを起動する場合は、起動クラスを実行するすべてのサーバーで次のステップを実行します。

    1. 「環境」、「サーバー」、変更するサーバーを選択します。

    2. 「拡張」タブで、「ノード・マネージャ」サブタブを選択します。

    3. 「クラスパス」フィールドに、クラスまたはクラスを含むJARファイルのパス名を追加します。

      たとえば、com.mycompany.startupという名前のパッケージにStartBrowserという起動クラスを作成し、そのクラス・ファイルを/myDomain/src/myJAR.jarという名前のJARファイルにアーカイブする場合、「クラスパス」フィールドにこの値が含まれている必要があります: サーバーのクラス・パスへの/myDomain/src/myJAR.jar。

    4. 「保存」をクリックします。

    5. 追加のサーバーで繰り返します。

停止クラスの構成

サーバー機能を拡張したり、サーバー・インスタンスの停止時にタスクを実行するカスタムJavaクラスを作成できます。

  1. 「編集ツリー」で、「環境」、「停止クラス」の順に移動します。

  2. 「新規」をクリックします。

  3. 停止クラスの名前を入力し、「作成」をクリックします。

  4. 新しい停止クラスの構成ページの「クラス名」フィールドに、停止クラスの完全修飾名を入力します。

    次に例を示します: mycompany.myclasses.shutdownclass。

  5. 必要に応じて、その他の停止クラスの属性を変更します。

  6. 「保存」をクリックします。

  7. 「ターゲット」タブで、この停止クラスをデプロイするサーバー・インスタンスまたはクラスタを「選択済」に移動します。

  8. 「保存」をクリックします。

  9. 停止クラスは、デプロイされる各サーバーのクラス・パスに追加する必要があります。

  10. スクリプトを使用してサーバー・インスタンスを停止する場合は、次のステップを実行します。

    1. テキスト・エディタで停止スクリプトを開きます。

    2. クラスパスを設定するコマンドで、クラス・ルート・パッケージを含むディレクトリのパスを追加し、スクリプトを保存します。

      たとえば、StopBrowserという名前の停止クラスをcom.mycompany.shutdownという名前のパッケージに作成し、そのクラス・ファイルを/myDomain/src/myJAR.jarという名前のJARファイルにアーカイブする場合、サーバーの停止スクリプトは/myDomain/src/myJAR.jarをサーバーのクラス・パスに追加する必要があります。

    3. サーバーを再起動します。

  11. ノード・マネージャを使用してサーバー・インスタンスを停止する場合は、停止クラスを実行するすべてのサーバーで次のステップを実行します。

    1. 「環境」、「サーバー」、変更するサーバーを選択します。

    2. 「拡張」タブで、「ノード・マネージャ」サブタブを選択します。

    3. 「クラスパス」フィールドに、クラスまたはクラスを含むJARファイルのパス名を追加します。

      たとえば、com.mycompany.shutdownという名前のパッケージにStopBrowserという名前の停止クラスを作成し、そのクラス・ファイルを/myDomain/src/myJAR.jarという名前のJARファイルにアーカイブする場合、「クラスパス」フィールドにこの値が含まれている必要があります: サーバーのクラス・パスへの/myDomain/src/myJAR.jar。

    4. 「保存」をクリックします。

    5. 追加のサーバーで繰り返します。

ネットワーク接続の構成

ドメインのネットワーク・リソースを構成します。

ドメインの複雑さが増すにつれ、サーバーとアプリケーション間の安全で信頼性の高い通信を確保するために、ドメイン内のネットワーク・リソースと接続を慎重に管理することが不可欠です。

WebLogic Serverは、ネットワーク・チャネルを使用して、ネットワーク接続の属性を編成および定義します。 ネットワーク・チャネルでは、次のような属性を定義できます:

  • 接続がサポートするプロトコル
  • リスニング・アドレス
  • セキュア通信および非セキュア通信のリスニング・ポート

「Oracle WebLogic Serverのサーバー環境の管理」の「ネットワーク・チャネルの理解」を参照してください。

各WebLogic Serverインスタンスには、インスタンスへのアクセスに利用されるプロトコル、リスニング・アドレス、およびリスニング・ポートについてデフォルトの設定が用意されています。 これらの設定は、ひとくくりにデフォルト・ネットワーク・チャネルとして参照されます。 このデフォルトのネットワーク・チャネルは、リクエストを受信する2つのリスニング・ポートを提供: 1つはSSL/TLS以外のリクエスト用、もう1つはSSL/TLSリクエスト用です。 このうち1つのポートを無効にすることもできますが、少なくとも1つは有効にする必要があります。

独自のカスタム・ネットワーク・チャネルを構成することもできます。

ドメイン全体の管理ポートの構成

管理ポートは、WebLogic Serverドメイン内のサーバー・インスタンス間のすべての管理トラフィックを単一のポートに制限します。 また、セキュアなSSL/TLSトラフィックのみが受け入れられ、ポート経由のすべての接続にはサーバー管理者による認証が必要です。

管理ポートを有効にすると、ドメインに以下の制約が課せられます。

  • ドメイン内の管理サーバーおよびすべての管理対象サーバーは、SSL/TLSプロトコルをサポートするように構成する必要があります。
  • 管理サーバーを含むドメイン内のすべてのサーバーで、同時に管理ポートを有効化または無効化します。

「Oracle WebLogic Serverの本番環境の保護」の「ドメインの管理ポートの構成」を参照してください。

  1. ドメイン内のすべての管理対象サーバーを停止します。 管理ポートを、管理対象サーバー上で動的に有効化することはできません。

  2. SSL/TLSを使用するようにドメイン内のすべてのサーバーが適切に構成されていることを確認します。 「SSL/TLSの設定」を参照してください。

  3. 「編集ツリー」で、「環境」、「ドメイン」の順に移動します。

  4. 「管理ポートの有効化」オプションをオンにします。

  5. 「管理ポート」フィールドに、ドメイン内のサーバー・インスタンスが管理ポートとして使用するSSL/TLSポート番号を入力します。

  6. ドメイン全体の管理ポートを使用するドメイン内の同じコンピュータで複数のサーバー・インスタンスを実行する場合は、次のいずれかのアクションを実行する必要があります:

    • サーバー・インスタンスをマルチホーム・マシンでホストし、各サーバー・インスタンスに一意のリスニング・アドレスを割り当てます
    • マシン上の1つのサーバー・インスタンスを除くすべてのサーバー・インスタンスでドメイン全体の管理ポートをオーバーライドします。 On the 環境: サーバー: 各管理対象サーバーのmyServerページで、ローカル管理ポートの上書きフィールドに一意のポート値を入力します。

  7. 「保存」をクリックし、変更をコミットします。

  8. 管理サーバーを再起動し、ドメイン内のすべての管理対象サーバー・インスタンスを起動します。

管理対象サーバーと管理サーバー間の接続で管理ポートが使用されていることを確認します。

カスタム・ネットワーク・チャネルの構成

ネットワーク・チャネルは、WebLogic Serverに対するネットワーク接続の属性を定義する構成可能なリソースです。

  1. 「編集ツリー」で、「環境」、「サーバー」、myServer、Channelsの順に移動します。

  2. 「新規」をクリックします。

  3. 新しいネットワーク・チャネルの名前を入力します。

  4. 「作成」をクリックします。

    新しいネットワーク・チャネルのノードがChannelsノードの下に表示されます。

  5. 新しいノードに移動して、新しいネットワーク・チャネルの構成を定義します。

    少なくとも、次の情報を定義する必要があります:

    • リスニング・アドレス
    • リスニング・ポート
    • 外部リスニング・アドレス
    • 外部リスニング・ポート外部リスニング・アドレスとポートは、ネットワーク・アドレス変換(NAT)ファイアウォールをサポートするために使用されます。 これらは、クライアントでサーバー上のアプリケーションへのアクセスに使用するIPアドレスまたはDNS名と一致している必要があります。

  6. 「保存」をクリックします。

リスニング・アドレスの指定

サーバーが着信接続に使用するリスニング・アドレスを定義します。

  1. 「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。

  2. 「リスニング・アドレス」フィールドに、受信接続のリスニングに使用するこのサーバーのIPアドレスまたはDNS名を入力します。

    リスニング・アドレスに指定する値がホスト・マシンのURLではないこと、また通信プロトコル、リスニング・ポートまたはチャネルを含んでいないことに注意してください。

    サーバーは次のURLからアクセスできます: protocol://listen-address:listen-port

  3. 「保存」をクリックします。

リスニング・ポートの指定

セキュア通信および非セキュア通信のリスニング・ポートを定義します。

  1. 「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。

  2. 「リスニング・ポート有効」を有効にし、ポート番号を入力します。

  3. 「SSLリスニング・ポート有効」を有効にし、ポート番号を入力します。

  4. 「保存」をクリックします。

ドメイン全体の管理ポートを構成する場合は、「SSLリスニング・ポート」と「管理ポート」が異なるポート番号に設定されていることを確認します。

一般的なプロトコル設定の構成

各WebLogic Serverインスタンスは、HTTP、T3、IIOPなど、様々なプロトコルで通信するように構成できます。 すべてのプロトコルに適用される通信設定のグループを構成することもできます。

一般的なプロトコル設定は、サーバーのデフォルトのリスニング・ポートおよびリスニング・アドレスを使用する接続に適用されます。 このサーバーのネットワーク・チャネルを作成する場合は、各チャネルでこれらの設定をオーバーライドできます。 詳細は、「Oracle WebLogic Serverのサーバー環境の管理」の「ネットワーク・リソースの構成」を参照してください。

  1. 「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。

  2. 「プロトコル」タブの「一般」タブで、必要に応じてプロトコルのデフォルト設定を変更します。

  3. 「保存」をクリックします。

  4. 該当するサーバーで繰り返します。

HTTPの構成

HTTP接続の設定を定義できます。

  1. 「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。

  2. 「プロトコル」タブで、HTTPサブタブに移動し、必要に応じてHTTPの設定を更新します。

  3. 接続のトンネリングを有効にする場合は、「トンネリングの有効化」オプションを有効にしてから、「TunnelingクライアントPing」および「トンネリング・クライアントのタイムアウト」フィールドに値を入力します。

  4. 「保存」をクリックします。

T3プロトコルの構成

T3は、Remote Method Invocation (RMI)プロトコルを実装するOracle独自のリモート・ネットワーク・プロトコルです。

  1. 「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。

  2. 「プロトコル」タブの「完了メッセージ・タイムアウト」フィールドに、このサーバーが完全なメッセージの受信を待機する最大秒数を入力します。

  3. 「最大メッセージ・サイズ」フィールドに、プロトコル固有の設定またはカスタム・チャネル設定によってオーバーライドされないかぎり、サポートされているすべてのプロトコルで受信されるメッセージで許可される最大バイト数を入力します。

  4. 「トンネリングの有効化」オプションを有効にしてから、「TunnelingクライアントPing」および「トンネリング・クライアントのタイムアウト」フィールドに値を入力します。

  5. 「保存」をクリックします。

IIOPの構成

IIOP (Internet Inter-ORB Protocol)は、異なるプログラミング言語で書かれた分散プログラムがインターネット上で通信することを可能にします。

アプリケーションでのRMI-IIOPの使用の詳細は、「Oracle WebLogic ServerのRMIアプリケーションの開発」の「WebLogic RMIの理解」を参照してください。

  1. 「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。

  2. 「プロトコル」タブで、IIOPサブタブに移動します。

  3. 「IIOPの有効化」をオンにします。

  4. IIOPのデフォルト構成(デフォルトのIIOPユーザー資格証明を含む)を変更する場合は、「拡張フィールドの表示」をクリックして、必要に応じてオプションを更新します。

  5. 「保存」をクリックします。

ドメイン・モードの変更

WebLogic Serverドメインのドメイン・モードによって、デフォルトのセキュリティ構成が決まります。 WebLogic Serverが実行される環境のセキュリティ要件に最も適したドメイン・モードを選択します。

ドメイン・モードは、最小から最大まで、開発モード、本番モードおよび保護本番モードです。 開発またはデモンストレーション環境では、ドメインにのみ開発モードを使用することをお薦めします。

様々なセキュリティ構成のデフォルト値は、選択したドメイン・モードと一致するように変更されます。 「Oracle WebLogic Serverの本番環境の保護」の「ドメイン・モードがデフォルトのセキュリティ構成に与える影響の理解」を参照してください。

  1. ドメイン内のすべての管理対象サーバーを停止します。

    ドメイン・モードの変更には、ドメイン全体の再起動が必要で、ローリング再起動では不十分です。

  2. 「編集ツリー」で、「環境」、「ドメイン」の順に移動します。

  3. ドメイン・モードを変更します:

ドメイン・モードを変更する方法について説明します。
ターゲット・ドメイン・モード 次のステップを実行します
開発モード 「生産モード」オプションを無効にして、ドメインを開発モードに変換します。
本番モード 「生産モード」オプションを有効にして、ドメインを本番モードに変換します。
ノート: WebLogic Server 14.1.2.0.0では、本番モードを選択すると、デフォルトで保護された本番モードが有効になります。

基本的な本番モードの機能のみを適用する場合は、「保護された本番モード」オプションを明示的に無効にする必要があります。 ノード・マネージャを使用して管理対象サーバーを起動する場合は、-Dweblogic.securemode.SecureModeEnabled=false起動引数も各管理対象サーバーに追加する必要があります。 「管理対象サーバーの起動引数の構成」を参照してください。

保護された本番モード 「生産モード」および「保護された本番モード」オプションを有効にします。

ノート: 詳細は、Oracle WebLogic Serverのセキュリティの管理の保護された本番モードの使用を参照してください。

  1. 「保存」をクリックします。

  2. 変更を確定し、管理サーバーを再起動します。 その後、管理対象サーバーを起動できます。

ドメイン・モードを変更すると、管理サーバーのデフォルトURL(特にプロトコルとポート番号)に影響する可能性があります。 SSL/TLSおよび管理ポートが有効になっている場合(デフォルトでは、両方ともセキュア本番モードで有効になっている)、デフォルトのURLはhttps://hostname:9002です。 SSL/TLSおよび管理ポートが無効になっている場合(デフォルトでは、両方とも開発モードでは無効)、デフォルトのURLはhttp://hostname:7001です。

サーバーの再開

STANDBYまたはADMIN状態のサーバーで、サーバーが管理リクエスト以外のリクエストを受信する準備ができている場合は、サーバーを再開してRUNNING状態に遷移できます。

様々なサーバーの状態の詳細は、「Oracle WebLogic Serverのサーバーの起動と停止の管理」の「サーバーのライフサイクルについて」を参照してください。

  1. 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動します。

  2. RUNNING状態に遷移するサーバーを選択し、「再開」をクリックします。

サーバーの一時停止

サーバーを一時停止すると、サーバー・インスタンスはRUNNING状態からADMIN状態に遷移します。 ADMIN状態では、サーバーは実行中ですが、管理操作でのみ使用できます。 これにより、アプリケーションを実行するリスクなく、サーバー・レベルおよびアプリケーション・レベルの管理タスクを実行できます。

様々なサーバーの状態の詳細は、「Oracle WebLogic Serverのサーバーの起動と停止の管理」の「サーバーのライフサイクルについて」を参照してください。

  1. 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動します。

  2. ADMIN状態に遷移するサーバーを選択します。

  3. 「一時停止」をクリックし、サーバーが現在のタスクを完了する方法を選択します:

    • 作業完了時: 正常な停止を開始します。これにより、WebLogic Serverサブシステムおよびサービスに、現在進行中の特定のアプリケーション処理を完了する時間が与えられます。
    • 今すぐ強制停止: 強制的な一時停止を開始します。この中断では、サーバーは、処理中のリクエストをただちに削除するようにサブシステムに指示します。

サーバーの停止

WebLogic Remote Consoleを使用して、WebLogic Serverのサーバー・インスタンスを停止できます。

WebLogic Remote Consoleは、サーバー・インスタンスの停止に使用できるいくつかのツールの1つです。 その他のオプションについては、「Oracle WebLogic Serverのサーバーの起動と停止の管理」の「WebLogic Serverのインスタンスの停止」を参照してください。

管理サーバーを停止すると、ドメインが再起動されるまでWebLogic Remote Consoleからドメインを管理できなくなります。

  1. サーバーを正常に停止し、一部のWebLogic Serverサブシステムが既存のタスクを完了できるようにする場合は、正常な停止設定を構成できます。

    これらのオプションは、サーバーが正常に停止している場合にのみ適用されます。 強制的な停止では無視されます。

    1. 「編集ツリー」で、「環境」、「サーバー」の順に進み、正常な停止設定を適用するサーバーを選択します。

    2. 「拡張」タブで、「起動/停止」サブタブを選択します。

    3. 「停止中にセッションを無視」をオンにすると、サーバーがすべてのHTTPセッションを完了またはタイムアウトするのを待たずにただちに削除するように強制されます。

      放棄されたHTTPセッションがタイムアウトになるのを待つと、デフォルトのセッション・タイムアウトは1時間なので、正常な停止のプロセスが大幅に長くなる場合があります。

    4. 「正常な停止タイムアウト」を秒単位で指定して、サーバーが停止を強制するまでに待機する時間を決定します。

    5. 該当するサーバーで繰り返します。

  2. 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動します。

  3. 停止するサーバーを選択します。

  4. 「停止」をクリックし、サーバーがタスクを完了する方法を選択します:

    • 作業完了時: 正常な停止を開始します。これにより、WebLogic Serverサブシステムが、現在進行中の特定のアプリケーション処理を完了するまでの時間が得られます。
    • 今すぐ強制停止: 強制的な停止を開始します。この停止では、サーバーは処理中のリクエストをただちに削除するようにサブシステムに指示します。 Oracle WebLogic Serverのサーバーの起動と停止の管理のサーバーのライフサイクルの理解を参照してください。