プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
12c (12.2.1.1)
E77231-01
目次へ移動
目次

前
次

10 エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

次の各項では、エンタープライズ・デプロイメントの開始点として使用できる初期ドメインのインストールおよび構成方法について説明します。このガイドの後の章では、デプロイしようとしているエンタープライズ・トポロジを構成する各種製品およびコンポーネントを含めることで、この初期ドメインを拡張する方法について説明します。

10.1 インフラストラクチャ・ドメインの作成時に使用する変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

これらのディレクトリ変数については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

  • ORACLE_HOME

  • ASERVER_HOME

  • MSERVER_HOME

  • APPLICATION_HOME

  • JAVA_HOME

  • NM_HOME

さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名を参照することになります。

  • ADMINVHN

  • SOAHOST1

  • SOAHOST2

  • DBHOST1

  • DBHOST2

  • Oracle RACデータベースのSCANアドレス(DB-SCAN.examle.com)

10.2 初期インフラストラクチャ・ドメインの理解

初期インフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。

10.2.1 インフラストラクチャ・ディストリビューションについて

エンタープライズ・デプロイメントの初期インフラストラクチャ・ドメインの作成には、Oracle Fusion Middleware Infrastructureディストリビューションを使用します。このディストリビューションには、Oracle WebLogic ServerソフトウェアとOracle JRFソフトウェアの両方が含まれています。

Oracle JRFソフトウェアは、Oracle Web Services Manager、Oracle Application Development Framework (Oracle ADF)、Oracle Enterprise Manager Fusion Middleware Control、リポジトリ作成ユーティリティ(RCU)およびOracle Fusion Middleware製品のサポートに必要なその他のライブラリおよびテクノロジで構成されています。

このガイドの後のほうでは、エンタープライズ・デプロイメントに必要なOracle Fusion Middleware製品をサポートするために、そのドメインを拡張します。

詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middleware Infrastructureの理解に関する項を参照してください。

10.2.2 ドメインの特徴

次の表に、作成するドメインの主な特徴を示します。これらの特徴を確認して理解することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。

これらの特徴の多くについては、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

ドメインの特徴 詳細情報

管理サーバーに別個の仮想IP (VIP)アドレスを使用。

管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

ドメイン内の管理サーバーと管理対象サーバーに別個のドメイン・ディレクトリを使用。

管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

Oracle Web Services Managerの専用クラスタを含む。

アプリケーション層でのOracle Web Services Managerの使用

ホストごとのノード・マネージャ構成を使用します。

標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

別途インストールされたLDAPベースの認証プロバイダが必要。

OPSSおよび認証ストアと認可ストアへのリクエストの理解

10.3 エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール

エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

10.3.1 サポートされているJDKのインストール

Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (JDK)がシステムにインストールされている必要があります。詳細は、次の各項を参照してください。

10.3.1.1 JDKソフトウェアの検索とダウンロード

動作保証されているJDKを調べるには、Oracle Fusion Middlewareのサポートされるシステム構成ページで、ご使用のリリース向けの動作保証ドキュメントを参照してください。

現在のOracle Fusion MiddlewareリリースのOracle JDKを特定したら、Oracle Technology Networkの次の場所からOracle JDKをダウンロードできます。

http://www.oracle.com/technetwork/java/index.html

Java SE JDKのダウンロードに必ず移動してください。

10.3.1.2 JDKソフトウェアのインストール

JDKを次の場所にインストールします。

  • アプリケーション層の各ホスト・コンピュータからアクセスできる共有記憶域デバイス/u01/oracle/products/jdkディレクトリにJDKをインストールします。

  • Web層の各ホスト・コンピュータのローカル記憶域デバイス

    DMZに配置されるWeb層ホスト・コンピュータは、アプリケーション層の共有記憶域に必ずしもアクセスできるとはかぎりません。

JDKソフトウェアの推奨場所の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。

次の例では、JDK 1.8の最新バージョンをインストールする方法について説明します。

  1. ディレクトリを、JDKアーカイブ・ファイルをダウンロードした場所に変更します。
  2. アーカイブをJDKホーム・ディレクトリに解凍してから、次のコマンドを実行します。
    cd download_dir
    tar -xzvf jdk-8u74-linux-x64.tar.gz
    

    ここに記載されたJDKバージョンは、このドキュメントの発行時点のものです。サポートされている最新のJDKについては、Oracle Fusion Middlewareのシステム要件と仕様で現在のOracle Fusion Middlewareリリースを参照してください。

  3. JDKディレクトリを、ディレクトリ構造内の推奨される場所に移動します。

    例:

    mv ./jdk1.8.0_74/u01/oracle/products/jdk

    詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

  4. ホスト・コンピュータでJavaを実行するためのJAVA_HOMEおよびPATH環境変数を定義します。

    例:

    export JAVA_HOME=/u01/oracle/products/jdk
    export PATH=$JAVA_HOME/bin:$PATH
    
  5. 次のコマンドを実行して、適切なjava実行可能ファイルがそのパスにあり、環境変数が適切に設定されていることを確認します。
    java -version
      java version "1.8.0_74"
      Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
      Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)

10.3.2 SOAHOST1でのInfrastructureインストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

  1. SOAHOST1にログインします。
  2. インストール・プログラムがダウンロードされたディレクトリに移動します。
  3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。
    JAVA_HOME/bin/java -d64 -jar distribution_file_name.jar
    

    この例では、次のようになります。

    • JAVA_HOMEを、ご使用のシステムの環境変数または実際のJDKの場所に置き換えます。

    • distribution_file_nameを、ディストリビューションJARファイルの実際の名前に置き換えます。

      ディストリビューションをOracle Technology Network (OTN)からダウンロードする場合、通常、JARファイルはダウンロード可能なZIPファイル内にパッケージされています。

      初期Infrastructureドメインに必要なソフトウェアをインストールする場合は、インストールするディストリビューションはfmw_12.2.1.0.0_infrastructure_generic.jarです。

      各ディストリビューションの実際のファイル名の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明については、「インストール画面のナビゲート」を参照してください。

10.3.3 インフラストラクチャ・インストール画面のナビゲート

インストール・プログラムでは、次の表にリストされている順序で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面 説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解に関する項を参照してください。

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

エンタープライズ・デプロイメントのためには、表7-2に示すORACLE_HOME変数の値を入力します。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

このトポロジの場合は、「Fusion Middleware Infrastructure」を選択します。

注意: このドキュメントのトポロジには、サーバーの例は含まれていません。例を本番環境にインストールしないことを強くお薦めします。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告またはエラー・メッセージが表示される場合、Oracle Technology Network (OTN)のOracle Fusion Middlewareシステム要件と仕様を参照してください。

セキュリティ・アップデート

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、この手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、その選択を後続のダイアログ・ボックスで確認します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

10.3.4 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

SOAHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、SOAHOST2にもインフラストラクチャをインストールする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「SOAHOST1でのInfrastructureインストーラの起動」「Infrastructureインストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

注意:

前のリリースでは、推奨されるエンタープライズ・トポロジに、同じ場所に配置されたOracle HTTP Serverインスタンスのセットが含まれていました。こうしたリリースでは、InfrastructureをWeb層ホストにインストールする必要がありました(WEBHOST1およびWEBHOST2)。しかし、このリリースの場合、エンタープライズ・デプロイメント・トポロジでは、Webサーバーがスタンドアロン・モードでインストールおよび構成されると想定しているため、これらがアプリケーション層ドメインに含まれるとは考えられていません。詳細は、「エンタープライズ・デプロイメント用のOracle HTTP Serverの構成」を参照してください

10.3.5 ディレクトリ構造のチェック

Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、この項にリストされたディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。

ディレクトリ構造をチェックするには:

  1. InfrastructureをインストールしたORACLE_HOMEディレクトリに移動します。
  2. 次のコマンドを入力します。
    ls -l
    システム上のディレクトリ構造は、次の例に示す構造と一致する必要があります。
    /u01/oracle/products/fmw/
    
    cfgtoollogs
    coherence
    em
    install
    inventory
    OPatch
    oracle_common
    oraInst.loc
    oui
    wlserver
    インストールの完了後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリに関する項を参照してください。

10.4 データベース・スキーマの作成

Fusion Middleware Infrastructureドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに、この項にリストされたスキーマをインストールする必要があります。

  • メタデータ・サービス(MDS)

  • 監査サービス(IAU)

  • 監査サービスへの追加(IAU_APPEND)

  • 監査サービス・ビューア(IAU_VIEWER)

  • OPSS (Oracle Platform Security Services)

  • ユーザー・メッセージング・サービス(UMS)

  • WebLogicサービス(WLS)

  • Common Infrastructure Services (STB)

リポジトリ作成ユーティリティ(RCU)を使用して、スキーマを作成します。このユーティリティは各Oracle Fusion Middleware製品のOracleホームにインストールされています。RCUの詳細とスキーマを作成してデータベースに格納する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でスキーマ作成の準備に関する項を参照してください。

この項の手順に従って、必要なスキーマをインストールします。

10.4.1 動作保証されたデータベースのインストールと構成

動作保証されたデータベースを適切にインストールして構成し、そのデータベースを起動して稼働させておく必要があります。

詳細は、「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。

10.4.2 リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

  1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。
  2. 対象のシステムで、JAVA_HOME環境変数に、動作保証されたJDKの場所が設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

    UNIXオペレーティング・システムの場合:

    export JAVA_HOME=/u01/oracle/products/jdk
  3. RCUを起動します。

    UNIXオペレーティング・システムの場合:

    ./rcu

10.4.3 スキーマ作成のためのRCU画面のナビゲート

Fusion Middleware Infrastructureドメインにスキーマを作成するには、この項の手順に従います。

タスク1   RCUの導入

「ようこそ」画面でRCUのバージョン番号を確認します。「次へ」をクリックして開始します。

タスク2   スキーマ作成の方法の選択

データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「リポジトリの作成」画面で「システム・ロードおよび製品ロード」を選択します。このドキュメントの手順では、必要な権限があることを想定しています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。これによってSQLスクリプトが生成され、これをデータベース管理者が利用できます。リポジトリ作成ユーティリティを使用したスキーマの作成のシステム・ロードおよび製品ロードの理解に関する項を参照してください。

ヒント:

この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でリポジトリの作成に関する項を参照してください。

タスク3   データベース資格証明の指定

「データベース接続の詳細」画面に、データベースに接続するためのRCUに関するデータベース接続の詳細が表示されます。

「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

ヒント:

この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でデータベース接続の詳細に関する項を参照してください。

タスク4   カスタム接頭辞の指定とスキーマの選択
  1. Oracle Fusion Middlewareスキーマの識別に使用するカスタム接頭辞を指定します。

    カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。このガイドでは、FMW1221という接頭辞を使用します。

    ヒント:

    ここで入力したカスタム接頭辞を書き留めてください。これは後でドメインの作成時に必要になります。

    カスタム接頭辞の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のカスタム接頭辞の理解に関する項を参照してください。

  2. 「AS共通スキーマ」を選択します。

    「AS共通スキーマ」を選択すると、このセクションのすべてのスキーマが自動的に選択されます。

    このセクションのスキーマが自動的に選択されない場合、必要なスキーマを選択してください。

Common Infrastructure Servicesと呼ばれるスキーマも自動的に作成されます。このスキーマはグレー表示されており、選択も選択解除もできません。このスキーマ(STBスキーマ)を使用すると、ドメインの構成中にRCUから情報を取得できます。詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

ヒント:

マルチドメイン環境でスキーマを編成する方法の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のスキーマ作成の計画に関する項を参照してください。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。

このガイドでは、残りの画面のデフォルト設定を受け入れるか、RCUでのOracle Fusion Middlewareスキーマの作成方法および必要な表領域の使用方法をカスタマイズします。

RCUおよびその機能と概念については、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

10.5 Infrastructureドメインの構成

次の各項では、Fusion Middleware構成ウィザードを使用してWebLogic Serverドメインを作成するための手順を示します。

ドメイン作成に使用可能なその他の方法の詳細は、構成ウィザードを使用したWebLogicドメインの作成のWebLogicドメインの作成、拡張および管理のための追加ツールに関する項を参照してください。

10.5.1 構成ウィザードの起動

ドメインの構成を開始するには、Oracle Fusion Middleware Oracleホームで次のコマンドを実行します。

ORACLE_HOME/oracle_common/common/bin/config.sh

10.5.2 Infrastructureドメインを構成するための構成ウィザード画面のナビゲート

この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「新規ドメインの作成」を選択します。

「ドメインの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。

ヒント:

構成ウィザードのこの画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面では、「製品テンプレートを使用してドメインを作成」が選択されていることを確認し、次のテンプレートを選択します。

  • Oracle Enterprise Manager - 12.2.1.0 [em]

    このテンプレートを選択すると、次の依存性が自動的に選択されます。

    • Oracle JRF - 12.2.1.0 [oracle_common]

    • WebLogic Coherenceクラスタの拡張 - 12.2.1.0 [wlserver]

  • Oracle WSM Policy Manager - 12.2.1.0 [oracle_common]

GUID-A1464A2D-0AB5-43D0-ACD7-58E662A72A9D-default.pngの説明が続きます
図GUID-A1464A2D-0AB5-43D0-ACD7-58E662A72A9D-default.pngの説明

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

タスク3   アプリケーション・ホームの場所の選択

「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「アプリケーションの場所」に関する項を参照してください。

タスク4   管理者アカウントの構成

「管理者アカウント」画面では、ドメインに対するデフォルトのWebLogic管理者アカウントにユーザー名とパスワードを指定します。

この画面で指定したユーザー名およびパスワードを書き留めておいてください。これらの資格証明は後でドメインの管理サーバーを起動して接続する際に必要になります。

タスク5   ドメイン・モードとJDKの指定

「ドメイン・モードおよびJDK」画面では、次の操作を実行します。

  • 「ドメイン・モード」フィールドで、「本番」を選択します。

  • 「JDK」フィールドで「Oracle Hotspot JDK」を選択します。

「本番モード」をこの画面で選択すると、環境で高度なセキュリティが実現され、アプリケーションのデプロイと管理サーバーの起動でユーザー名とパスワードが必要になります。

ヒント:

開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。

本番モードでは、起動アイデンティティ・ファイルを作成することで、管理サーバーの起動時に必要なユーザー名とパスワードの指定を省略できます。詳細は、「boot.propertiesファイルの作成」を参照してください。

タスク6   データベース構成タイプの指定

「RCUデータ」を選択して、この画面に示されるフィールドをアクティブ化します。

「RCUデータ」オプションによってデータベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に受け取るように構成ウィザードで指定できます。

注意:

この画面の「手動構成」を選択した場合は、「JDBCコンポーネント・スキーマ」画面でスキーマのパラメータを手動で入力する必要があります。

「RCUデータ」を選択したら、次の表に示すフィールドに入力します。図10-1のサンプルの「データベース構成タイプ」画面の部分的なスクリーン・ショットを参照してください。

フィールド 説明

DBMS/サービス

製品スキーマをインストールするOracle RACデータベースのサービス名を入力します。例:

orcl.example.com

必ずOracle RACデータベース内のすべてのインスタンスの識別に使用される共通サービス名を指定してください。ホスト固有のサービス名は使用しないでください。

ホスト名

Enterprise Deployment Workbookに入力したOracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

ポート

データベースがリスニングするポート番号を入力します。例: 1521

スキーマ所有者

スキーマ・パスワード

データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。

これはRCUの「スキーマ・パスワード」画面でサービス表コンポーネントに指定したスキーマ(「データベース・スキーマの作成」を参照)のユーザー名およびパスワードです。

デフォルトのユーザー名はprefix_STBであり、この場合prefixはRCUで定義したカスタム接頭辞です。

図10-1 エンタープライズ・デプロイメントのデータベース構成タイプの設定

図10-1の説明が続きます
「図10-1 エンタープライズ・デプロイメントのデータベース構成タイプの設定」の説明

データベース接続情報の指定が完了したら、「RCU構成の取得」をクリックします。操作に成功すると、「接続結果ログ」に次の出力が示されます。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

データベースへの接続に成功したら、「次へ」をクリックします。

ヒント:

「RCUデータ」オプションの詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のサービス表スキーマの理解に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「データソース・デフォルト」に関する項を参照してください。

タスク7   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面に示される値が、すべてのスキーマに対して適切であることを確認します。

前の画面でRCUデータの取得を選択しているため、スキーマ表は移入済のはずです。その結果、構成ウィザードはこのドメインに必要なすべてのスキーマのデータベース接続値を見つけることができます。

この時点では、これらの値は単一インスタンスのデータベースに接続するように構成されています。ただし、エンタープライズ・デプロイメントの場合、「エンタープライズ・デプロイメント用のデータベースの準備」の説明のように、可用性の高いReal Application Clusters (RAC)データベースを使用する必要があります。

さらに、各コンポーネント・スキーマでアクティブなGridLinkデータ・ソースを使用することをお薦めします。GridLinkデータ・ソースを使用してRACデータベースに接続する利点の詳細は、高可用性ガイドのデータベースの考慮事項に関する項を参照してください。

データ・ソースをGridLinkに変換する手順は次のとおりです。

  1. スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。

  2. 「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク8   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素 説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

図10-2 「GridLink Oracle RACコンポーネント・スキーマ」画面のサンプル値

図10-2の説明が続きます
「図10-2 「GridLink Oracle RACコンポーネント・スキーマ」画面のサンプル値」の説明

この画面で情報を指定する方法の詳細および適切なSCANアドレスの特定方法については、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。

また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。

タスク9   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「コンポーネント・スキーマのテスト」に関する項を参照してください。

タスク10   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

  • 管理サーバー

    これは、管理サーバーのリスニング・アドレスを適切に構成するために必要です。

  • ノード・マネージャ

    これは、ノード・マネージャを構成するために必要です。

  • 管理対象サーバー、クラスタおよびCoherence

    これは、管理対象サーバーとクラスタの構成で必要ですが、マシンを構成して管理対象サーバーをマシンにターゲット指定するためにも必要です。

  • JMSファイル・ストア

    これは、JMS永続ストア用に適切な共有記憶域を構成するために必要です。

注意:

構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。

  • この画面で前述のオプションのいずれかが使用可能でない場合は、「テンプレート」画面に戻り、このトポロジに必要なテンプレートが選択されていることを確認します。

  • 「ドメイン・フロントエンド・ホストのキャプチャ」拡張構成オプションを選択しないでください。後で、ドメインに対してではなく特定のクラスタに対してフロントエンド・ホスト・プロパティを構成します。

タスク11   管理サーバーのリスニング・アドレスの構成

「管理サーバー」画面で、次の手順を実行します。

  1. 「サーバー名」フィールドで、デフォルト値(「AdminServer」)を維持します。

  2. 「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得し、「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化した、ADMINVHNのVIPに対応する仮想ホスト名を入力します。

    ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

  3. 他のフィールドでは、デフォルト値をそのまま使用します。

    特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。

タスク12   ノード・マネージャの構成

ノード・マネージャ・タイプとして「手動ノード・マネージャ・セットアップ」を選択します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のノード・マネージャに関する項を参照してください。

ドメインごとおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

詳細は、『Oracle WebLogic Serverノード・マネージャの管理』複数マシンでのノード・マネージャの構成に関する項を参照してください。

タスク13   管理対象サーバーの構成

「管理対象サーバー」画面で、2台の管理対象サーバーを新規作成します。

  1. 「追加」ボタンをクリックして、1台の管理対象サーバーを新規作成します。

  2. 「サーバー名」列でWLS_WSM1を指定します。

  3. 「リスニング・アドレス」列にSOAHOST1と入力します。

    SOAHOST1に対応するホスト名を必ず入力して、IPアドレスは使用しないでください。

  4. 「リスニング・ポート」列に7010と入力します。

  5. 「サーバー・グループ」ドロップダウン・リストで、JRF-MAN-SVRWSM-CACHE-SVR、およびWSMPM-MAN-SVRを選択します。(図10-3を参照。)

    これらのサーバー・グループによって、Oracle JRFとOracle Web Services Manager (OWSM)のサービスが、作成中の管理対象サーバーにターゲット設定されます。

    サーバー・グループは、定義されたアプリケーション・サービスのグループをそれぞれに定義されたサーバー・グループにマッピングすることで、Fusion Middlewareアプリケーションおよびサービスを1つ以上のサーバーにターゲット設定します。特定のサーバー・グループにマップされた任意のアプリケーション・サービスは、そのグループに割り当てられたすべてのサーバーに自動的にターゲット指定されます。詳細は、『ドメイン・テンプレート・リファレンス』のアプリケーション・サービス・グループ、サーバー・グループおよびアプリケーション・サービス・マッピングに関する項を参照してください。

    注意:

    Oracle Web ServicesのNonceキャッシュは、WSM-CACHE-SVRサーバー・グループによって自動的に構成され、ほとんどのアプリケーションに適しています。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。Nonceキャッシュは、追加されたWebサービス・アプリケーションを実行中の管理対象サーバーの数によって必然的に拡大します。

    拡張キャッシュ構成については、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOracle CoherenceによるNonceのキャッシュに関する項を参照してください。この項では、NonceキャッシュとWSM-CACHE-SVRサーバー・グループの使用に関する追加のガイダンスを提供します。

  6. このプロセスを繰り返して、WLS_WSM2という名前の2つ目の管理対象サーバーを作成します。

    「リスニング・アドレス」SOAHOST2と入力します。「リスニング・ポート」に7010と入力します。最初の管理対象サーバーに適用したものと同じサーバー・グループをWLS_WSM2に適用します。

この手順で推奨する管理対象サーバー名(WLS_WSM1およびWLS_WSM2)はこのドキュメント全体で参照します。別の名前を選択した場合は、必要に応じてそれらの名前に置き換えてください。

図10-3 エンタープライズ・デプロイメント用に管理対象サーバーを定義するための構成ウィザードの使用

図10-3の説明が続きます
「図10-3 エンタープライズ・デプロイメント用に管理対象サーバーを定義するための構成ウィザードの使用」の説明

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「管理対象サーバー」に関する項を参照してください。

タスク14   クラスタの構成

「クラスタ」画面を使用して、新しいクラスタを作成します。

  1. 「追加」ボタンをクリックします。

  2. 「クラスタ名」フィールドで、WSM-PM_Clusterを指定します。

  3. 他のフィールドは空のままにします。

ヒント

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。

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

「サーバーのクラスタへの割当」画面を使用して、WLS_WSM1およびWLS_WSM2を新規クラスタWSM-PM_Clusterに割り当てます。

  1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではWSM-PM_Cluster)を選択します。

  2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_WSM1WSM-PM_Clusterに割り当てます。

    • WLS_WSM1」を1回クリックして選択し、右矢印をクリックして「クラスタ」ペインの選択されているクラスタ(WSM-PM_Cluster)の下に移動します。

      または

    • WLS_WSM1」をダブルクリックして、クラスタ・ペインの選択されているクラスタ(WSM-PM_Cluster)の下に移動します。

  3. これらの手順を繰り返して、WLS_WSM2管理対象サーバーをWSM-PM_Clusterに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク16   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。

「クラスタ・リスニング・ポート」9991と入力します。

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報』のOracle Coherenceに関する項を参照してください。

タスク17   マシンの作成

「マシン」画面を使用して、ドメイン内に3つの新規マシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。

  1. 「Unixマシン」タブを選択します。

  2. 「追加」ボタンをクリックし、3つの新しいUnixマシンを作成します。

    表10-1の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。図10-4は、各マシンの値の例が入力された「マシン」画面の一部を示しています。

  3. 「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。

    この例に示されているポート番号5556は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。

表10-1 Unixマシンの作成時に使用する値

名前 ノード・マネージャのリスニング・アドレス ノード・マネージャのリスニング・ポート

SOAHOST1

SOAHOST1ホスト名変数の値。例: SOAHOST1.example.com

5556

SOAHOST2

SOAHOST2ホスト名変数の値。例: SOAHOST2.example.com

5556

ADMINHOST

ADMINVHN変数の値を入力します。

5556

図10-4 構成ウィザードの「Unixマシン」画面の値の例

図10-4の説明が続きます
「図10-4 構成ウィザードの「Unixマシン」画面の値の例」の説明

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンに関する項を参照してください。

タスク18   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、管理サーバーと2つの管理対象サーバーを適切なマシンに割り当てます。

「サーバーのマシンへの割当」画面は、管理対象サーバーのクラスタへの割当て画面に似ています。「マシン」列でターゲット・マシンを選択し、左の列で管理対象サーバーを選択した後、右矢印をクリックしてそのサーバーを適切なマシンに割り当てます。

次のように、サーバーを割り当てます。

  • AdminServerをADMINHOSTマシンに割り当てます。

  • WLS-WSM1管理対象サーバーをSOAHOST1マシンに割り当てます。

  • WLS-WSM2管理対象サーバーをSOAHOST2マシンに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク19 JMSファイル・ストアの構成

Oracle WSM Policy Manager構成テンプレートを使用してドメインを構成する場合、特にエンタープライズ・デプロイメントを構成しているときには、メタデータ・サービス(MDS)のJMSファイル・ストアの適切な場所を選択する必要があります。

「JMSファイル・ストア」画面の「ディレクトリ」列に次の場所を入力します。

ORACLE_RUNTIME/domain_name/WSM-PM_Cluster/jms

注意:

このストアには、非共有記憶域の場所を指定できます。これは、WSMの開発モードでのみ使用されます。本番環境では、これをホストするためにかわりにデータベースが使用されます。

「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ORACLE_RUNTIMEを変数の実際の値に置き換えます。

domain_nameを作成しているドメインの名前に置き換えます。

タスク20   仮想ターゲットの作成

「次へ」をクリックして次の画面に進みます。

タスク21   パーティションの作成

「次へ」をクリックして次の画面に進みます。

タスク22   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

ドメイン作成は、「作成」をクリックするまでは開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク23   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

10.6 エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成

エンタープライズ・デプロイメントによっては、デフォルトのドメインごとのノード・マネージャではなく、ホストごとのノード・マネージャを構成した方がよい場合があります。

ホストごとのノード・マネージャの利点の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください

10.6.1 ホストごとのノード・マネージャ構成の作成

ホストごとのノード・マネージャの構成の手順では、構成ディレクトリおよび2つの新規ノード・マネージャ構成ファイルを作成します。デフォルトのstartNodeManager.shファイルを編集する必要もあります。

ホストごとのノード・マネージャ構成を作成するには、次のタスクをまずSOAHOST1で実行し、その後SOAHOST2で実行します。

  1. SOAHOST1にログインして、ノード・マネージャ構成ファイルのディレクトリを作成します。

    例:

    mkdir —p /u02/oracle/config/nodemanager

    このディレクトリはホストに固有であるため、ローカル・ディスクに配置する必要があります。このディレクトリの場所はノード・マネージャ・ホームと呼ばれており、このガイドの各例ではNM_HOMEディレクトリ変数によって識別されます。

  2. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd NM_HOME
  3. nodemanager.propertiesという新しいテキスト・ファイルを作成し、例10-1に示されている値をこの新しいファイルに追加します。

    nodemanager.propertiesファイルに追加できるプロパティの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのプロパティに関する項を参照してください。

    nodemanager.propertiesファイルのこの構成の一部として、ノード・マネージャに対してクラッシュ・リカバリを有効にします。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャとシステム・クラッシュ・リカバリに関する項を参照してください。

  4. 次のディレクトリでstartNodeManager.shファイルを見つけます。
    WL_HOME/server/bin
  5. startNodeManager.shファイルをノード・マネージャ・ホーム・ディレクトリにコピーします。
  6. 新しいstartNodeManager.shファイルを編集し、NODEMGR_HOMEプロパティを次のように追加します。
    NODEMGR_HOME="NM_HOME"

    この例では、NM_HOMEをノード・マネージャ・ホームの実際のパスに置き換えます。

  7. ノード・マネージャ・ホーム・ディレクトリに、nodemanager.domainsという新しいファイルを作成します。

    nodemanager.domainsファイルではノード・マネージャ・クライアントのアクセスがファイル内に表示されたドメインに制限されるので、セキュリティがさらに強化されます。

  8. SOAHOST2で手順1から7を実行します。
  9. 次のエントリを新しいnodemanager.domainsファイルに追加します。

    SOAHOST1で、管理サーバー・ドメイン・ホームと管理対象サーバー・ドメイン・ホームの値を追加します。

    soaedg_domain=MSERVER_HOME;ASERVER_HOME

    注意:

    最初に指定されたパス(MSERVER_HOME)は、primaryDomainPathとみなされ、管理対象サーバーはこの場所から実行されます。

    SOAHOST2で、管理対象サーバー・ドメイン・ホームのみの値を追加します。

    soaedg_domain=MSERVER_HOME

    これらの例では、ASERVER_HOMEおよびMSERVER_HOMEを、「このガイドで使用するファイル・システムとディレクトリ変数」に示されているそれぞれの変数に置き換えます。

例10-1 nodemanager.propertiesファイルのコンテンツ

DomainsFile=/u02/oracle/config/nodemanager/nodemanager.domains
LogLimit=0
PropertiesVersion=12.2.1
AuthenticationEnabled=true
NodeManagerHome=/u02/oracle/config/nodemanager
#Include the specific JDK home
JavaHome=/u01/oracle/products/jdk
LogLevel=INFO
DomainsFileEnabled=true
StartScriptName=startWebLogic.sh
#Leave blank for listening on ANY
ListenAddress=
NativeVersionEnabled=true
ListenPort=5556
LogToStderr=true
SecureListener=false
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=true
StartScriptEnabled=true
LogFile=/u02/oracle/config/nodemanager/nodemanager.log
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50

10.6.2 boot.propertiesファイルの作成

ノード・マネージャの資格証明を要求されることなくノード・マネージャを起動する必要がある場合、boot.propertiesを作成します。この手順は、エンタープライズ・デプロイメントで必要です。このファイルに入力した資格証明は、管理サーバーの起動時暗号化されます。

管理サーバーのboot.propertiesファイルを作成する手順は次のとおりです。

  1. 次のようなディレクトリ構造を作成します。
    mkdir -p ASERVER_HOME/servers/AdminServer/security
    
  2. テキスト・エディタで、前述の手順で作成したsecurityディレクトリにboot.propertiesというファイルを作成し、構成ウィザードを実行してドメインを作成したときに定義した、次の管理サーバー資格証明を入力します。
    username=adminuser
    password=password

    注意:

    管理サーバーを起動すると、ファイル内のusernamepasswordのエントリは暗号化されます。

    セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を短くします。ファイルを編集した後、できるかぎり速やかにサーバーを起動し、エントリを暗号化してください。

  3. ファイルを保存してエディタを閉じます。

10.6.3 SOAHOST1でのノード・マネージャの起動

ホストごとのノード・マネージャ構成を使用するようノード・マネージャを手動で設定したら、startNodeManager.shスクリプトを使用してSOAHOST1でノード・マネージャを起動できます。

SOAHOST1でノード・マネージャを起動するには、次のようにします。
  1. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd NM_HOME
  2. 次のコマンドを実行してノード・マネージャを起動し、コマンドの出力を現在のターミナル・シェルではなく出力ファイルに送信します。
    nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &
  3. nodemanager.outファイルを監視し、ノード・マネージャが正常に起動することを確認します。出力には最終的に、次のような文字列が含まれます。
    <INFO><Plain socket listener started on port 5556>

10.6.4 ノード・マネージャ資格証明およびタイプの構成

デフォルトでは、ホストごとのノード・マネージャ構成では、ノード・マネージャからサーバーへの通信にSecure Socket Layer (SSL)は使用されません。このため、ドメイン内の各マシンを、SSLではなく"プレーン"通信タイプを使用するように構成する必要があります。また、ドメイン内の管理サーバーおよび管理対象サーバーに接続できるようにノード・マネージャ資格証明を設定する必要があります。

次の手順では、これらのタスクを実行できるように、一時的に管理サーバーをデフォルトの起動スクリプトで起動します。これらのタスクを実行したら、この一時セッションを停止し、ノード・マネージャを使用して管理サーバーを起動できます。

  1. デフォルトの起動スクリプトを使用して管理サーバーを起動します。
    1. ディレクトリを次のディレクトリに変更します。
      cd ASERVER_HOME/bin
    2. 起動スクリプトを実行します。
      ./startWebLogic.sh

      次が表示されるまで、端末への出力を確認します。

      <Server state changed to RUNNING>
  2. WebLogic管理者ユーザーおよびパスワードを使用してWebLogic Server管理コンソールにログインします。
  3. ノード・マネージャ・タイプを構成します。

    注意:

    ドメイン内のWebLogic Serverマシンごとに必ずこのタスクを実行してください。

    1. 「ロックして編集」をクリックします。
    2. 「ドメイン構造」ナビゲーション・ツリーで「ドメイン」「環境」の順に開きます。
    3. 「マシン」をクリックします。
    4. ADMINHOSTマシンのリンクをクリックします。
    5. 「ノード・マネージャ」タブをクリックします。
    6. 「タイプ」プロパティをSSLから「プレーン」に変更します。
    7. 「保存」をクリックします。
    8. ドメイン内のマシンごとに、このタスクを繰り返します。
    9. 「変更のアクティブ化」をクリックします。
  4. ノード・マネージャ資格証明を設定します。
    1. 「ロックして編集」をクリックします。
    2. 「ドメイン構造」ナビゲーション・ペインでドメイン名をクリックします。
    3. 「セキュリティ」タブを選択します。
      「セキュリティ」>「一般」タブが選択されているはずです。
    4. 下方向にスクロールして「詳細」セキュリティ・オプションを開きます。
    5. 「ノード・マネージャのユーザー名」フィールドのユーザー名を書き留めます。
      オプションで、値を編集して新しいノード・マネージャ・ユーザー名を作成できます。
    6. 「ノード・マネージャのパスワード」および「ノード・マネージャのパスワードを確認」フィールドに新しいパスワードを入力します。
    7. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
  5. 新しいターミナル・ウィンドウで、次の手順を使用してSystemSerialized.datファイルをリフレッシュします。この手順を行わないと、ノード・マネージャに接続してドメイン内のサーバーを起動することができません。
    1. ディレクトリを次に変更します
      cd ORACLE_COMMON_HOME/common/bin
    2. WebLogic Server Scripting Tool (WLST)を起動します。
      ./wlst.sh
    3. 次のWLSTコマンドを使用して管理サーバーに接続します。
      connect('admin_user','admin_password','admin_url')

      例:

      connect('weblogic','mypassword','t3://ADMINVHN:7001')

    4. nmEnrollコマンドを使用して、ノード・マネージャが指定したWebLogicドメイン内のサーバーを管理できるようにします。
      nmEnroll('ASERVER_HOME')

      例:

      nmEnroll('/u01/oracle/config/domains/soaedg_domain')

  6. オプションで、管理サーバーの起動プロパティをカスタマイズする場合は、次のWLSTコマンドを使用して管理サーバー用のstartup.propertiesファイルを作成できます。
    nmGenBootStartupProps('AdminServer')

    次のディレクトリに、startup.propertiesファイルが作成されます。

    ASERVER_HOME/servers/AdminServer/data/nodemanager/
  7. 起動スクリプトで管理サーバーを起動したターミナル・ウィンドウに戻ります。
  8. [Ctrl]+[C]を押して、管理サーバーのプロセスを停止します。

    管理サーバーのプロセスが停止し、ターミナル・コマンド・プロンプトが表示されるのを待ちます。

10.7 ドメイン・ディレクトリの構成とMFTHOST1上のサーバーの起動

ドメインを作成し、ノード・マネージャを構成したら、MFTHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。

10.7.1 ノード・マネージャを使用した管理サーバーの起動

ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。

  1. WebLogic Scripting Tool(WLST)を起動します。
    cd ORACLE_COMMON_HOME/common/bin
    ./wlst.sh
  2. ノード・マネージャ資格証明を使用してノード・マネージャに接続します。
    wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
                'ADMINVHN','5556','domain_name',
                'ASERVER_HOME','PLAIN')

    注意:

    このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

    ASERVER_HOME/config/nodemanager
  3. 管理サーバーを起動します。
    nmStart('AdminServer')
    

    注意:

    管理サーバーを起動すると、WebServicesポリシーのためにOracle Web Services Managerに接続しようとします。WSM-PM管理対象サーバーはまだ起動されていないため、管理サーバー・ログには次のメッセージが表示されると予想されます。

    <Warning><oracle.wsm.resources.policymanager>
    <WSM-02141><Unable to connect to the policy access service due to Oracle WSM policy manager host server being down.>
  4. WLSTを終了します。
    exit()

10.7.2 管理サーバーの検証

構成手順に進む前に、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、管理サーバーが正常に起動したことを確認します。

Fusion Middleware Controlに移動するには、次のURLを入力し、Oracle WebLogic Server管理者の資格証明を使用してログインします。

ADMINVHN:7001/em

Oracle WebLogic Server管理コンソールに移動するには、次のURLを入力し、同じ管理者資格証明を使用してログインします。

ADMINVHN:7001/console

10.7.3 Derbyデータベースの無効化

管理対象サーバー・ディレクトリを作成して管理対象サーバーを起動する前に、Oracle WebLogic Serverに含まれるファイルベースのデータベースである組込みDerbyデータベースを無効にします。Derbyデータベースは主に開発環境に使用されます。そのため、本番対応のエンタープライズ・デプロイメント環境を構成する場合は無効にする必要があります。そうしないと、管理対象サーバーの起動時にDerbyデータベース・プロセスが自動的に起動されます。
Derbyを無効にするには、次のようにします。
  1. Oracleホームの次のディレクトリに移動します。
    WL_HOME/common/derby/lib
  2. Derberライブラリjarファイル名を変更します。
    mv derby.jar disable_derby.jar
  3. SOAHOST1およびSOAHOST2の各ORACLE_HOMEで手順1から2を完了します(別個の共有ファイル・システムを使用している場合)。

10.7.4 SOAHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。これで、SOAHOST1SOAHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

サーバーが共有記憶域にログを書き込むことによって発生する潜在的な競合とオーバーヘッドを排除するために、MSERVER_HOMEをローカル記憶域に配置することをお薦めします。また、必要なクラスおよびjarをドメイン・ディレクトリからロードするほうが高速であるため、管理対象サーバーがドメイン・ディレクトリから使用するtmpまたはキャッシュのデータのほうがより迅速に処理されます。

「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のように、管理サーバー・ドメイン・ホームのパスはASERVER_HOME変数によって表され、管理対象サーバー・ドメイン・ホームのパスはMSERVER_HOME変数によって表されます。

管理対象サーバーのドメイン・ディレクトリを作成する手順は次のとおりです。

  1. SOAHOST1にログインし、次のようにpackコマンドを実行してテンプレートを作成します。
    cd ORACLE_COMMON_HOME/common/bin
     
    ./pack.sh -managed=true 
              -domain=ASERVER_HOME 
              -template=complete_path/soadomaintemplate.jar 
              -template_name=soa_domain_template
    

    この例では、次のようになります。

    • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

    • complete_pathを、ドメイン・テンプレートJARファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートJARファイルをコピーまたは解凍する際に、この場所を参照する必要があります。

    • soadomaintemplate.jarは作成するJARファイルのサンプル名であり、これにはドメイン構成ファイルが含まれます。

    • soa_domain_templateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

  2. packコマンドで作成したばかりのsoadomaintemplate.jarファイルの場所を書き留めます。

    テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。

    ORACLE_COMMON_HOME/common/bin/

    ヒント:

    packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

  3. まだ作成していない場合は、SOAHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
  4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=MSERVER_HOME \
                -overwrite_domain=true \
                -template=complete_path/soadomaintemplate.jar \ 
                -log_priority=DEBUG \
                -log=/tmp/unpack.log \
                -app_dir=APPLICATION_HOME \

    注意:

    unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

    また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shというファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うよう構成できます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

    この例では、次のようになります。

    • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

    • complete_pathを、テンプレートJARファイルを作成またはコピーした場所の完全なパスに置き換えます。

    • soadomaintemplate.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートJARファイルの名前です。

    ヒント:

    packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

  5. ディレクトリを、新しく作成した管理対象サーバー・ディレクトリに変更して、ドメイン構成ファイルがSOAHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

10.7.5 SOAHOST1でのWLS_WSM1管理対象サーバーの起動と検証

ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してSOAHOST1でWLS_WSM1管理対象サーバーを起動できます。

  1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
    http://ADMINVHN:7001/em
    

    この例では、次のようになります。

    • ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

    • ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

      ヒント:

      Oracle Enterprise Manager Fusion Middlewareを使用したOracle Fusion Middlewareの管理の詳細は、Oracle Fusion Middlewareの管理のOracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイドを参照してください。

  2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
  3. 「サーバー」ペインを選択して、ドメイン内の管理対象サーバーを表示します。
    Fusion Middleware Control
  4. WLS_WSM1管理対象サーバーのみを選択して、ツールバーで「コントロール」>「起動」をクリックします。
  5. 管理対象サーバーが正しく機能していることを検証するには、ブラウザを開き、次のURLを入力します。
    SOAHOST1:7010/wsm-pm/
    

    要求に従って、ドメイン管理ユーザー名とパスワードを入力します。

10.8 ドメインの伝播とMFTHOST2上のサーバーの起動

MFTHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、MFTHOST2で次のタスクを実行できます。

10.8.1 MFTHOST2でのドメイン構成の解凍

MFTHOST1で管理サーバーと最初のWLS_WSM1管理対象サーバーを実行した後、MFTHOST2でドメインを構成できます。

  1. MFTHOST2にログインします。
  2. まだ作成していない場合は、MFTHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
  3. MFTHOST2からmftdomaintemplate.jarにアクセスできることを確認します。
    たとえば、MFTHOST2に別の共有記憶域ボリュームまたはパーティションを使用している場合は、MFTHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。
  4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=MSERVER_HOME
                -overwrite_domain=true
                -template=complete_path/mftdomaintemplate.jar 
                -log_priority=DEBUG
                -log=/tmp/unpack.log
                -app_dir=APPLICATION_HOME
    

    この例では、次のようになります。

    • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

    • complete_path/mftdomaintemplate.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

    • APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

    ヒント:

    packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

  5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがMFTHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

10.8.2 SOAHOST2でのドメインの解凍

この手順では、以前に作成したファイルを、SOAHOST1SOAHOST2の両方からアクセスできる場所(たとえば、共有記憶域ファイラ上のASERVER_HOMEディレクトリなど)にコピー済であることを想定しています。

  1. SOAHOST2にログインします。
  2. まだ作成していない場合は、SOAHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
  3. SOAHOST2からsoadomaintemplate.jarにアクセスできることを確認します。
    たとえば、SOAHOST2に別の共有記憶域ボリュームまたはパーティションを使用している場合は、SOAHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。
  4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=MSERVER_HOME
                -overwrite_domain=true
                -template=complete_path/soadomaintemplate.jar 
                -log_priority=DEBUG
                -log=/tmp/unpack.log
                -app_dir=APPLICATION_HOME
    

    この例では、次のようになります。

    • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

    • complete_path/soadomaintemplate.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

    • APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

    ヒント:

    packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

  5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがSOAHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

10.8.3 SOAHOST2でのノード・マネージャの起動

ホストごとのノード・マネージャ構成を使用するようにノード・マネージャを手動で設定したら、SOAHOST2で次のコマンドを使用してノード・マネージャを起動できます。
  1. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd NM_HOME
  2. 次のコマンドを実行してノード・マネージャを起動し、コマンドの出力を現在のターミナル・シェルではなく出力ファイルに送信します。
    nohup ./startNodeManager.sh > nodemanager.out 2>&1 &

10.8.4 SOAHOST2でのWLS_WSM2管理対象サーバーの起動と検証

SOAHOST1でのWLS_WSM1管理対象サーバーの起動と検証」の手順を使用して、SOAHOST2上のWLS_WSM2管理対象サーバーを起動および検証します。

10.9 uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しい管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールにログインします。

  2. 左側のナビゲーション・ツリーで、「ドメイン」「環境」を開きます。

  3. 「ロックして編集」をクリックします。

  4. 「サーバー」をクリックします。

  5. 管理対象サーバー・ドメイン・ホーム・ディレクトリ内の新しい管理対象サーバーごとに次の操作を実行します。

    1. 管理対象サーバーの名前をクリックします。

    2. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

    3. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。

      MSERVER_HOME/servers/server_name/stage
      

      MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換え、server_nameを編集しているサーバーの名前に置き換えます。

    4. 「アップロード・ディレクトリ名」を次の値に更新します。

      ASERVER_HOME/servers/AdminServer/upload
      

      ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

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

    6. 「サーバーのサマリー」画面に戻ります。

  6. 各管理対象サーバーについてこれらの値を変更したら、「変更のアクティブ化」をクリックします。

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

10.10 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング

Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

次の各項では、Oracle WebLogic Server管理コンソールを使用してエンタープライズ・デプロイメント・ドメイン用の新しい認証プロバイダを作成する方法を説明します。この手順では、サポートされているLDAPディレクトリ(Oracle Unified DirectoryやOracle Internet Directoryなど)をすでにインストールおよび構成していることを想定しています。

10.10.1 サポートされている認証プロバイダについて

Oracle Fusion Middlewareでは、様々なLDAP認証プロバイダをサポートしています。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・タイプおよびWebLogicオーセンティケータに関する項を参照してください。

このガイドの手順では、次のいずれかのプロバイダを使用していることを想定しています。

  • Oracle Unified Directory

  • Oracle Internet Directory

  • Oracle Virtual Directory

注意:

ここに示す手順では、デフォルトで単一のLDAPアイデンティティ・ストアに対する問合せをサポートするようにアイデンティティ・サービス・インスタンスを構成する方法を説明します。

ただし、LibOVDを使用して、複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。

複数LDAP参照に関する詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・サービスの構成に関する項を参照してください。

10.10.2 エンタープライズ・デプロイメント・ユーザーおよびグループについて

次の各項では、エンタープライズ・デプロイメント管理ユーザーおよびグループの用途と特性に関する重要な情報を提供します。

10.10.2.1 各ドメインで一意の管理ユーザーの使用について

集中LDAPユーザー・ストアを使用すると、複数のOracle WebLogic Serverドメインで使用するユーザーおよびグループをプロビジョニングできます。その結果、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。

このようなアプローチはお薦めしません。かわりに、Oracle Fusion Middlewareドメインの管理用にプロビジョニングするユーザーおよびグループにディレクトリ・ツリー内で一意の識別名(DN)を割り当てる方法をお薦めします。

たとえば、Oracle SOA Suiteエンタープライズ・デプロイメント・ドメインをインストールおよび構成する場合は、weblogic_soaというユーザーとSOA Administratorsという管理グループを作成します。

10.10.2.2 ドメイン・コネクタ・ユーザーについて

Oracleでは、LDAPディレクトリに別個のドメイン・コネクタ・ユーザー(soaLDAPなど)を作成することをお薦めしています。こうすることで、ドメインでユーザー認証のためにLDAPディレクトリに接続できます。このユーザーは非管理ユーザーにすることをお薦めします。

標準的なOracle Identity and Access Managementデプロイメントでは、このユーザーはsystemidsコンテナで作成します。このコンテナは、通常ユーザーには表示されないシステム・ユーザーに使用されます。このユーザーをsystemidsコンテナに配置することで、Oracle Identity Managerを持つユーザーがこのユーザーを調整しないようにできます。

10.10.2.3 集中LDAPディレクトリへのユーザーの追加について

集中LDAPディレクトリをエンタープライズ・ドメインのオーセンティケータとして構成した後は、すべての新規ユーザーをデフォルトのWebLogic Serverオーセンティケータではなく新しいオーセンティケータに追加する必要があります。

集中LDAPディレクトリに新規ユーザーを追加する際、WebLogic管理コンソールは使用できません。かわりに、ldapbrowserやJXplorerなどの適切なLDAP変更ツールを使用する必要があります。

複数のオーセンティケータを使用している場合(エンタープライズ・デプロイメントの要件)、ログインや認証は実行できますが、ロール取得は実行できません。ロールは、最初のオーセンティケータからのみ取得できます。他のオーセンティケータを使用してロールを取得する場合は、ドメインの仮想化を有効にする必要があります。

仮想化の有効化には、次の手順が含まれます。

  1. 次の構成ファイルを探してテキスト・エディタで開きます。

    DOMAIN_HOME/config/fmwconfig/jps-config.xml
  2. name="idstore.ldap"およびprovider="idstore.ldap.provider"を持つserviceInstanceタグで、次のプロパティを追加または更新します。

    <property name="virtualize" value="true"/>

    仮想化プロパティの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のOPSSシステムおよび構成プロパティに関する項を参照してください。

10.10.2.4 Oracle SOA Suiteの製品固有のロールとグループについて

Oracle Fusion Middleware製品ごとに、管理および監視のために事前定義された独自のロールおよびグループが実装されます。

そのため、ドメインを拡張して他の製品を追加するときに、これらの製品固有のロールをSOA Administratorsグループに割り当てることができます。ロールがSOA Administratorsグループに追加されると、各製品管理者ユーザーは管理タスクを実行するための同じ権限セットを使用してドメインを管理できます。

SOA Administratorsグループに他のロールを追加する手順については、「エンタープライズ・デプロイメントの共通の構成および管理タスク」を参照してください。

10.10.2.5 このガイドで使用するサンプル・ユーザーとサンプル・ロール

このガイドで使用するサンプルでは、下に示すDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。

  • 管理ユーザーのDN:

    cn=weblogic_soa,cn=users,dc=example,dc=com
    
  • 管理グループDN:

    cn=SOA Administrators,cn=groups,dc=example,dc=com
  • 製品固有のLDAPコネクタ・ユーザー:
    cn=soaLDAP,cn=systemids,dc=example,dc=com
    これは、WebLogic管理対象サーバーをLDAP認証プロバイダに接続するときに使用するユーザーです。このユーザーには、ディレクトリに対する読取り権限および書込み権限が必要です。
    cn=users,dc=example,dc=com
    cn=groups,dc=example,dc=com

注意:

Oracle Unified Directoryを使用する場合、このユーザーに次のグループのメンバーシップが付与され、読取りおよび書込みアクセス権が付与される必要があります。

cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com

10.10.3 新しい認証プロバイダの作成とユーザーおよびグループのプロビジョニングの前提条件

新しいLDAP認証プロバイダを作成する前に、関連する構成ファイルをバックアップする必要があります。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

さらに、次のディレクトリにある管理サーバーのboot.propertiesファイルをバックアップする必要があります。

DOMAIN_HOME/servers/AdminServer/security

10.10.4 LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

この例では、集中LDAPディレクトリでsoaLDAPというユーザーを作成する方法を示します。

LDAPプロバイダでユーザーをプロビジョニングするには:

  1. 次に示す内容のdomain_user.ldifという名前のldifファイルを作成して保存します。

    dn: cn=soaLDAP,cn=systemids,dc=example,dc=com
    changetype: add
    orclsamaccountname: soaLDAP
    userpassword: password
    objectclass: top
    objectclass: person
    objectclass: organizationalPerson
    objectclass: inetorgperson
    objectclass: orcluser
    objectclass: orcluserV2
    mail: soaLDAP@example.com
    givenname: soaLDAP
    sn: soaLDAP
    cn: soaLDAP
    uid: soaLDAP

    注意:

    Oracle Unified Directoryを使用する場合、次の4つのグループ・メンバーシップをLDIFファイルの最後に追加して適切な読取り/書込み権限を付与します。

    dn:
    cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=example,dc=example
    changetype: modify
    add: uniquemember
    uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=example
    
    dn: cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com
    changetype: modify
    add: uniquemember
    uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=example
    
    dn: cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=example
    changetype: modify
    add: uniquemember
    uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=com
    
    dn: cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com
    changetype: modify
    add: uniquemember
    uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=com
  2. LDAPディレクトリでユーザーをプロビジョニングします。

    たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

    OUD_INSTANCE_HOME/bin/ldapmodify -a \
                                     -h oudhost.example.com
                                     -D "cn=oudadmin" \
                                     -w password \
                                     -p 1389 \
                                     -f domain_user.ldif

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \
                                 -p 3060 \
                                 -D cn="orcladmin" \
                                 -w password \
                                 -c \
                                 -v \
                                 -f domain_user.ldif
    

10.10.5 新しい認証プロバイダの作成

新しいLDAPベースの認証プロバイダを構成する手順は次のとおりです。

  1. WebLogic Server管理コンソールにログインします。

  2. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

  3. myrealmというデフォルト・レルム・エントリをクリックします。

  4. 「プロバイダ」タブをクリックします。

    このレルムに対してDefaultAuthenticatorというプロバイダが構成されていることに注目してください。これは、デフォルトのWebLogic Server認証プロバイダです。

  5. 「チェンジ・センター」で「ロックして編集」をクリックします。

  6. 「認証プロバイダ」表の下の「新規」ボタンをクリックします。

  7. プロバイダの名前を入力します。

    資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかの名前を使用します。

    • OUDAuthenticator (Oracle Unified Directoryの場合)

    • OIDAuthenticator (Oracle Internet Directoryの場合)

    • OVDAuthenticator (Oracle Virtual Directoryの場合)

  8. 「タイプ」ドロップダウン・リストでオーセンティケータ・タイプを選択します。

    資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかのタイプを選択します。

    • OracleUnifiedDirectoryAuthenticator (Oracle Unified Directoryの場合)

    • OracleInternetDirectoryAuthenticator (Oracle Internet Directoryの場合)

    • OracleVirtualDirectoryAuthenticator (Oracle Virtual Directoryの場合)

  9. 「OK」をクリックして「プロバイダ」画面に戻ります。

  10. 「プロバイダ」画面の表で、新しく作成したオーセンティケータをクリックします。

  11. 「制御フラグ」ドロップダウン・メニューで「SUFFICIENT」を選択します。

    制御フラグをSUFFICIENTに設定すると、そのオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。

    認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。以降のすべてのオーセンティケータの制御フラグもSUFFICIENTに設定されていることを確認してください。特にDefaultAuthenticatorをチェックして、その制御フラグがSUFFICIENTに設定されていることを確認します。

  12. 「保存」をクリックして制御フラグの設定を保存します。

  13. 「プロバイダ固有」タブをクリックし、次の表に示すように、使用するLDAPサーバーに固有の詳細を入力します。

    この手順では、必須フィールドのみを説明しています。このページのすべてのフィールドの詳細は、次のリソースを参照してください。

    • 各フィールドの説明を表示するには、「プロバイダ固有」タブの「ヘルプ」をクリックします。

    • 「ユーザー・ベースDN」「名前指定によるユーザー・フィルタ」「ユーザー属性」の各フィールドの設定に関する詳細は、『Oracle WebLogic Serverセキュリティの管理』のOracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成に関する項を参照してください。

    パラメータ サンプル値 値の説明

    ホスト

    例: oud.example.com

    LDAPサーバーのサーバーID。

    ポート

    例: 1689

    LDAPサーバーのポート番号。

    プリンシパル

    例: cn=soaLDAP, cn=systemids,dc=example,dc=com

    LDAPサーバーへの接続に使用されるLDAPユーザーのDN。

    資格証明

    LDAPパスワードを入力します。

    LDAPサーバーへの接続に使用されるパスワード。

    SSL有効

    未チェック(クリア)

    LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

    ユーザー・ベースDN

    例: cn=users,dc=example,dc=com

    ユーザーが開始時に使用するDNを指定します。

    すべてのユーザーのフィルタ

    (&(uid=*)(objectclass=person))

    すべてのユーザーのフィルタのデフォルトの検索条件のかわりにuid値に基づいてすべてのユーザーを検索します。

    LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」uid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」フィールドでそのタイプを変更します。

    たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。

    (&(cn=*)(objectclass=person)))

    名前指定によるユーザー・フィルタ

    例:

    (&(uid=%u)(objectclass=person))

    LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」uid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」の設定で、そのタイプを変更します。

    たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。

    (&(cn=%u)(objectclass=person)))

    ユーザー名属性

    例: uid

    グループの名前を指定するLDAPユーザー・オブジェクトの属性。

    グループ・ベースDN

    例: cn=groups,dc=example,dc=com

    グループ・ノードを指すDNを指定します。

    取得したユーザー名をプリンシパルとして使用する

    チェック・ボックスを選択

    オンにする必要があります。

    GUID属性

    entryuuid

    OUDにOracleUnifiedDirectoryAuthenticatorが使用される場合、この値にはentryuuidが事前に移入されます。認証プロバイダとしてOracle Unified Directoryを使用している場合はこの値を入力します。

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

  15. 右のナビゲーション・ペインで「セキュリティ・レルム」をクリックして、デフォルトのレルム名(myrealm)をクリックし、「プロバイダ」をクリックして「プロバイダ」ページに戻ります。

  16. 「並替え」をクリックし、表示されたページを使用して、作成したプロバイダを認証プロバイダのリストの先頭に配置します。

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

  18. チェンジ・センターで、変更のアクティブ化 をクリックします。

  19. 管理サーバーとすべての管理対象サーバーを再起動します。

    管理対象サーバーを停止するには、Fusion Middleware Controlにログインし、ターゲットのナビゲータで管理対象サーバーを選択して、ツールバーで「停止」をクリックします。

    ノード・マネージャを使用して管理サーバーを停止および起動する手順は次のとおりです。

    1. WLSTを起動します。

      cd ORACLE_COMMON_HOME/common/bin
      ./wlst.sh
      
    2. 構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。

      wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
                  'ADMINVHN','5556','domain_name',
                  'ASERVER_HOME','PLAIN')
      
    3. 管理サーバーを停止します。

      nmKill('AdminServer')
      
    4. 管理サーバーを起動します。

      nmStart('AdminServer')
      
    5. WLSTを終了します。

      exit()
      

    管理対象サーバーを起動するには、Fusion Middleware Controlにログインし、管理対象サーバーを選択して、ツールバーで「起動」をクリックします。

  20. 再起動後に、次のログ・ファイルの内容を確認します。

    ASERVER_HOME/servers/AdminServer/logs/AdminServer.log
    

    LDAP接続エラーが発生していないことを確認します。たとえば、次のようなエラーを探します。

    The LDAP authentication provider named "OUDAuthenticator" failed to make connection to ldap server at ...
    

    ログ・ファイルでこのようなエラーが見つかった場合は、認可プロバイダ接続の詳細をチェックして、それらが適切であることを確認し、管理サーバーの保存と再起動をもう一度試みます。

  21. 再起動後、LDAP接続エラーがログ・ファイルに記述されていないことを確認し、LDAPプロバイダ内に存在するユーザーとグループの参照を試みます。

    管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ユーザーとグループ」ページに移動します。LDAPプロバイダ構造内に存在するすべてのユーザーおよびグループを表示できるようになります。

10.10.6 エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

この例では、weblogic_soaというユーザーとSOA Administratorsというグループを作成する方法を示します。

LDAPプロバイダで管理ユーザーおよび管理グループをプロビジョニングする手順は次のとおりです。

  1. 次に示す内容のadmin_user.ldifという名前のldifファイルを作成して保存します。

    dn: cn=weblogic_soa,cn=users,dc=example,dc=com
    changetype: add
    orclsamaccountname: weblogic_soa
    userpassword: password
    objectclass: top
    objectclass: person
    objectclass: organizationalPerson
    objectclass: inetorgperson
    objectclass: orcluser
    objectclass: orcluserV2
    mail: weblogic_soa@example.com
    givenname: weblogic_soa
    sn: weblogic_soa
    cn: weblogic_soa
    uid: weblogic_soa
  2. LDAPディレクトリでユーザーをプロビジョニングします。

    たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

    OUD_INSTANCE_HOME/bin/ldapmodify -a \
                                     -h oudhost.example.com
                                     -D "cn=oudadmin" \
                                     -w password \
                                     -p 1389 \
                                     -f admin_user.ldif

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \
                                 -p 3060 \
                                 -D cn="orcladmin" \
                                 -w password \
                                 -c \
                                 -v \
                                 -f admin_user.ldif
    
  3. admin_group.ldifという名前のldifファイルを作成して、次の内容を入力してからこのファイルを保存します。

    dn: cn=SOA Administrators,cn=Groups,dc=example,dc=com
    displayname: SOA Administrators
    objectclass: top
    objectclass: SOA Administrators
    objectclass: orclGroup
    uniquemember: cn=weblogic_soa,cn=users,dc=example,dc=com
    cn:SOA Administrators
    description: Administrators Group for the Oracle SOA Suite Domain
    
  4. LDAPディレクトリでグループをプロビジョニングします。

    Oracle Unified Directoryの場合:

    OUD_INSTANCE_HOME/bin/ldapmodify -a \
                                     -D "cn=oudadmin" \
                                     -h oudhost.example.com \
                                     -w password \
                                     -p 3060 \
                                     -f admin_group.ldif
    

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h oid.example.com \
                                -p 3060 \
                                -D cn="orcladmin" \
                                -w password \
                                -c \
                                -v \
                                -f admin_group.ldif
    
  5. 変更が正常に行われたことを確認します。

    1. Oracle WebLogic Server管理コンソールにログインします。

    2. コンソールの左ペインで「セキュリティ・レルム」をクリックします。

    3. デフォルト・セキュリティ・レルム(myrealm)をクリックします。

    4. 「ユーザーとグループ」タブをクリックします。

    5. プロビジョニングした管理者ユーザーおよびグループがページに表示されていることを確認します。

10.10.7 管理グループへの新しい管理ユーザーの追加

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内でそのグループに管理ロールを割り当てる必要があります。これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。

管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てる手順は次のとおりです。

  1. 構成ウィザードで指定した管理資格証明を使用してWebLogic管理サーバー・コンソールにログインします。

    作成して新しい認証プロバイダに提供した管理ユーザーの資格証明は使用しないでください。

  2. 管理コンソールの左ペインで「セキュリティ・レルム」をクリックします。
  3. デフォルト・セキュリティ・レルム(myrealm)をクリックします。
  4. 「ロールとポリシー」タブをクリックします。
  5. 表の「グローバル・ロール」エントリを開き、「ロール」をクリックします。
  6. 「管理」ロールをクリックします。
  7. 「ロール条件の表示」ボタンをクリックします。
  8. 「述部リスト」ドロップダウン・メニューで「グループ」を選択し、「次へ」をクリックします。
  9. 「グループ引数名」フィールドにSOA Administratorsと入力して、「追加」をクリックします。

    引数のリスト・ボックスにSOA Administratorsが追加されます。

  10. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

    SOA Administratorsグループが表示されています。

  11. 「保存」をクリックすると、SOA Administratorsグループに管理ロールを追加する処理が終了します。
  12. 新しいweblogic_soaユーザー資格証明を使用してWebLogic管理サーバー・コンソールにログインし、変更されていることを確認します。

    新しい認証プロバイダでプロビジョニングした新しい管理ユーザーの資格証明を使用してOracle WebLogic Server管理コンソールとFusion Middleware Controlにログインできる場合は、プロバイダは正常に構成されています。

10.10.8 boot.propertiesファイルの更新およびシステムの再起動

新しい管理ユーザーおよびグループを作成したら、LDAPディレクトリで作成した管理ユーザー資格証明を使用して管理サーバーのboot.propertiesファイルを更新する必要があります。

  1. SOAHOST1で、次のディレクトリに移動します。
    ASERVER_HOME/servers/AdminServer/security
    
  2. 既存のboot.propertiesファイルの名前を変更します。
    mv boot.properties boot.properties.backup
    
  3. テキスト・エディタを使用して、セキュリティ・ディレクトリにboot.propertiesというファイルを作成します。
  4. 次の行をこのファイルに入力します。
    username=weblogic_soa
    password=password
    
  5. ファイルを保存します。
  6. 管理サーバーを再起動します。

10.11 Administratorsグループへのwsm-pmロールの追加

新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(SOA Administrators)をメンバーとしてwsm-pmアプリケーション・ストライプのpolicy.Updaterロールに追加します。

  1. Oracle WebLogic Server管理サーバーの資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

    これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic_soa)とパスワードを作成したときに作成した資格証明です。

  2. 「WebLogicドメイン」メニューから、「セキュリティ」「アプリケーション・ロール」を選択します。
  3. policy.Updaterロールに対して、「アプリケーション・ストライプ」ドロップダウン・メニューからwsm-pmアプリケーション・ストライプを選択します。
  4. 「アプリケーション・ロールの検索」アイコン検索アイコンをクリックして、ドメインで利用できるすべてのアプリケーション・ロールを表示します。
  5. エンタープライズ・デプロイメントの管理グループに追加するpolicy.Updaterロールの行を選択します。
  6. 「編集」アイコンアプリケーション・ロールの「編集」アイコンをクリックして、ロールを編集します。
  7. 「アプリケーション・ロールの編集」ページの「追加」アイコンアプリケーション・ロールの「追加」アイコンをクリックします。
  8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。
  9. 「プリンシパル名」の「次で始まる」フィールドにグループ名SOA Administratorsを入力し、右矢印をクリックして検索を開始して、エンタープライズ・デプロイメントの管理者グループを検索します。
  10. 検索結果で管理者グループを選択し、「OK」をクリックします。
  11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。