1. Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの構成
  3. エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

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

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

上位トピック: 「エンタープライズ・ドメインの構成」

初期インフラストラクチャ・ドメインについて

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

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

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

エンタープライズ・デプロイメントの初期インフラストラクチャ・ドメインの作成には、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の理解に関する項を参照してください。

親トピック: 初期インフラストラクチャ・ドメインについて

ドメインの特徴

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

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

ドメインの特徴 詳細情報

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

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

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

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

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

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

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

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

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

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

親トピック: 初期インフラストラクチャ・ドメインについて

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

この章のタスクを実行する際には、この項にリストされているディレクトリ変数を参照します。

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

  • 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.example.com)

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

Infrastructureドメインでの動的クラスタのサポート

Infrastructureドメインは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。

静的クラスタは、構成済クラスタとも言い、各サーバー・インスタンスを手動で構成して追加する従来型のクラスタです。動的クラスタには、新しい"server-template"オブジェクトが含まれています。このオブジェクトは、すべての生成された(動的)サーバー・インスタンスの一元的な構成を定義するために使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。この機能により、追加のサーバー容量が必要になったときに、動的クラスタ内のサーバー・インスタンスの数をスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。

この項に示すステップには、静的トポロジまたは動的トポロジの両方に対応するドメインの構成ステップが含まれています。この2種類の構成の相違点は次のとおりです。

  • 構成ウィザードのプロセスは、それぞれのケースに応じて異なることがあります。たとえば、サーバーではなく動的クラスタ用のサーバー・テンプレートの定義が必要になります。

  • 動的クラスタの場合は、サーバー固有の構成(リスニング・アドレスの設定、アップロードとステージングのディレクトリの構成、キーストアの構成など)をサーバーではなくサーバー・テンプレートで実行する必要があります。

  • 動的クラスタの場合は、サービス移行が異なる方法で構成されます。動的クラスタは移行可能ターゲットを使用しないかわりに、JMSリソースはクラスタにターゲット指定され、移行ポリシーが使用されます。動的クラスタおよび静的クラスタの場合、サービス移行に関連するすべての構成は構成ウィザードで自動的に実行でき、これはこのガイドで使用されているアプローチです。

複合クラスタ(動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を備えたクラスタ)は、Oracle SOA Suiteエンタープライズ・デプロイメントではサポートされません。

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

SOAHOST1でのOracle Fusion Middleware Infrastructureのインストール

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

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

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

Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (JDK)がシステムにインストールされている必要があります。

親トピック: SOAHOST1でのOracle Fusion Middleware Infrastructureのインストール

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のダウンロードに必ず移動してください。

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

アプリケーション層ホストの/u01/oracle/productsにマウントされている共有記憶域ボリュームVOL1とVOL2にJDKをインストールします。JDKをアップグレードする際に再構成の問題を回避するため、JDKのフォルダ名にはバージョン番号を含めないでください。たとえば、/u01/oracle/products/jdkです。

ノート:

推奨されるマウント・ポイントが複数製品の共有ボリュームを使用するため、複数のインストールが必要になる場合があります。

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

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

  1. ディレクトリを、JDKアーカイブ・ファイルをダウンロードした場所に変更します。
    cd download_dir
  2. JDKホーム・ディレクトリにアーカイブを解凍してから、次のコマンドを実行します。
    tar -xzvf jdk-8u241-linux-x64.tar.gz
    ここに記載されたJDKバージョンは、このドキュメントの発行時点のものです。サポートされている最新のJDKについては、Oracle Fusion Middlewareのシステム要件と仕様で現在のOracle Fusion Middlewareリリースを参照してください。
  3. JDKディレクトリを、ディレクトリ構造内の推奨される場所に移動します。
    たとえば:
    mv ./jdk1.8.0_241 /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バージョンは「1.8.0_241」と表示されます。
  6. 適切な1つのホスト上で共有される一意の製品ごとに、ステップ1から5を繰り返します。たとえば、SOAHOST1とSOAHOST2です。

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ファイルはダウンロード可能な圧縮ファイル内にパッケージされています。

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

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

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

親トピック: SOAHOST1でのOracle Fusion Middleware Infrastructureのインストール

Infrastructureインストール画面のナビゲート

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面についての詳細情報が必要な場合は、画面名をクリックするか、画面上で「ヘルプ」ボタンをクリックしてください。

表10-1 Infrastructureインストール画面のナビゲート

画面 説明

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

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

『Oracle Universal Installerによるソフトウェアのインストール』のOracleセントラル・インベントリに関する項を参照してください。

ノート:

製品の共有ボリューム上に、中央インベントリ・ディレクトリを構成することをお薦めします。例: /u01/oracle/products/oraInventory

インストーラが完了したら、oraInventoryからrootとしてcreateCentralinventory.shスクリプトを実行することが必要になる場合もあります。

ようこそ

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

自動更新

この画面を使用して、使用可能なパッチを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の使用」を参照してください。

インストールの進行状況

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

インストール完了

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

親トピック: SOAHOST1でのOracle Fusion Middleware Infrastructureのインストール

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

セカンダリ・ホストに別の共有記憶域ボリュームまたはパーティションを構成している場合は、それらのホストにもソフトウェアをインストールする必要があります。

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

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

ノート:

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

親トピック: SOAHOST1でのOracle Fusion Middleware Infrastructureのインストール

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

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

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

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

親トピック: SOAHOST1でのOracle Fusion Middleware Infrastructureのインストール

Derbyデータベースの無効化

組込みDerbyデータベースを無効化します。このデータベースは、ファイルベースのデータベースであり、Oracle WebLogic Serverにパッケージ化されています。Derbyデータベースは主に開発環境に使用されます。そのため、本番対応のエンタープライズ・デプロイメント環境を構成する場合は無効にする必要があります。そうしないと、管理対象サーバーの起動時にDerbyデータベース・プロセスが自動的に起動されます。
Derbyデータベースを無効にするには:
  1. Oracleホーム内の次のディレクトリに移動します。
    cd WL_HOME/common/derby/lib
  2. Derbyライブラリjarファイルの名前を変更します。
    mv derby.jar disable_derby.jar
  3. 各ホストで別々のファイル・システムを使用する場合は、各ホストでステップ1から2を繰り返します。

親トピック: SOAHOST1でのOracle Fusion Middleware Infrastructureのインストール

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

Oracle Fusion Middlewareコンポーネントでは、Fusion Middleware Infrastructureドメインを構成する前に、データベースにスキーマが存在していることが必要になります。このトピックの動作保証されたデータベースにリストされているスキーマを、このリリースのOracle Fusion Middlewareと組み合せて使用するためにインストールします。

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

  • 監査サービス(IAU)

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

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

  • OPSS (Oracle Platform Security Services)

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

  • WebLogicサービス(WLS)

  • 共通インフラストラクチャ・サービス(STB)

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

必要なスキーマをインストールするには、次のステップを実行します。

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

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

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

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

親トピック: データベース・スキーマの作成

リポジトリ作成ユーティリティ(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

    ノート:

    データベースで透過的データ暗号化(TDE)が有効化されており、RCUによって作成された表領域を暗号化する場合は、RCUの起動時に-encryptTablespace trueオプションを指定します。

    これによって、RCUの実行中に追加で操作することなく、「表領域のマップ」画面で適切なRCU GUI「表領域の暗号化」チェック・ボックスが選択されるようにデフォルト指定されます。『リポジトリ作成ユーティリティによるスキーマの作成』で表領域の暗号化に関する項を参照してください。

親トピック: データベース・スキーマの作成

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

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

タスク1   RCUの導入

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

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

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

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

「次」をクリックします。

ヒント:

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

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。

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

  2. RACデータベース・スキャン・リスナーのポート番号(1521など)を入力します。

  3. データベースのRAC「サービス名」を入力します。

  4. スキーマとスキーマ・オブジェクトを作成する権限を持つユーザーの「ユーザー名」、たとえば「SYS」などを入力します。

  5. ステップ4で指定した名前のユーザーの「パスワード」を入力します。

  6. SYSユーザーを選択した場合は、ロールを必ずSYSDBAに設定してください。

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

ヒント:

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

タスク4   カスタム接頭辞の指定とスキーマの選択

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

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

    ヒント:

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

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

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

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

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

デフォルトで選択される必須のスキーマが2つあります。「共通インフラストラクチャ・サービス」(STBスキーマ)と「WebLogicサービス」(WLSスキーマ)で、この2つの選択は解除できません。「共通インフラストラクチャ・サービス」スキーマを使用すると、ドメインの構成中にRCUから情報を取得できるようになります。『リポジトリ作成ユーティリティによるスキーマの作成』でサービス表スキーマの理解に関する項を参照してください。

ヒント:

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

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

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

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。パスワードが、データベースのセキュリティ要件を満たすくらい複雑であることを確認してから続行します。パスワード・ポリシーを満たしていない場合でも、この時点でRCUでは処理が続行されます。したがって、次のチェックはRCU以外で実行します。

「次」をクリックします。

ヒント:

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

タスク6   必須スキーマの表領域の検証

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

ノート:

構成ウィザードを使用して、JMSサーバーのJDBCストアおよびトランザクション・ログを使用するようにFusion Middlewareコンポーネントを構成できます。これらのJDBCストアは、Weblogicサービス・コンポーネント表領域に配置されています。環境内でより高度なレベルのトランザクションおよびJMSアクティビティが使用されることが予想される場合、<PREFIX>_WLS表領域のデフォルトのサイズを環境負荷により適したサイズに増大できます。

「次」をクリックして続行し、表領域作成の確認ダイアログで「OK」をクリックします。

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

タスク7 スキーマの作成

ロードするスキーマのサマリーを確認し、「作成」をクリックするとスキーマの作成が完了します。

ノート:

エラーが発生した場合は、リストされているログ・ファイルを確認して根本原因を特定し、問題を解決し、RCUを使用してスキーマを削除してから再作成します。

タスク8 レビュー完了のサマリーとRCU実行の完了

「完了サマリー」画面まで進んだら、スキーマ作成がすべて正常に完了していることを確認し、「閉じる」をクリックしてRCUを閉じます。

親トピック: データベース・スキーマの作成

スキーマ・アクセスの確認

RCUによって作成された新しいスキーマ・ユーザーとしてデータベースに接続することにより、スキーマのアクセスを確認します。接続にはSQL*Plusなどのユーティリティを使用し、RCUで入力した適切なスキーマ名とパスワードを指定します。

たとえば:

ノート:

データベースがプラガブル・データベース(PDB)の場合、PDBを指す適切なtns別名をsqlplusコマンドで使用する必要があります。 
./sqlplus FMW12214_WLS/<WLS_schema_password>

SQL*Plus: Release 19.0.0.0.0 - Production on Tue May 26 06:04:29 2020 
Version 19.6.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Last Successful login time: Tue Apr 07 2020 01:04:10 -07:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - 64bit Production
Version 19.6.0.0.0

SQL>

親トピック: データベース・スキーマの作成

Infrastructureドメインの構成

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

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

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

構成ウィザードの起動

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

ORACLE_HOME/oracle_common/common/bin/config.sh

親トピック: Infrastructureドメインの構成

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

次の各項に示す手順に従って、静的または動的クラスタを含むトポロジのドメインを作成および構成します。

親トピック: Infrastructureドメインの構成

静的クラスタを含めるドメインの作成

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

ドメインを作成して構成するためのタスクは次のとおりです。
タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

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

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

ヒント:

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

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

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

  • Oracle Enterprise Manager [em]

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

    • Oracle JRF - [oracle_common]

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

  • Oracle WSMポリシー・マネージャ[oracle_common]

ヒント:

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

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

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

ヒント:

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

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

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

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

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

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

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

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

    ノート:

    JDKをインストールしたフォルダを指していることを確認します。「JDKソフトウェアのインストール」を参照してください。

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

ヒント:

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

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

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

「データベース構成タイプ」画面で、次のようにします。

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

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

  • 「ベンダー」がOracle、「ドライバ」が*Oracle's Driver (Thin) for Service Connections; Versions: Anyであることを確認します。

  • 「接続パラメータ」が選択されていることを確認します。

ノート:

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

「RCUデータ」を選択したら、次の表に示すフィールドに入力します。

フィールド 説明

ホスト名

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

エンタープライズ・デプロイメント・ワークブックの詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください。

DBMS/サービス

製品スキーマをインストールする、このドメインに適切なOracle RACデータベースのサービス名を入力します。たとえば:

soaedg.example.com

「エンタープライズ・デプロイメント用のデータベースの準備」の項ですでに構成している値に基づいて、サービス名を指定します。

ポート

データベースがリスニングするポート番号を入力します。たとえば、1521などです。

スキーマ所有者

スキーマ・パスワード

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

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

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

データベース接続情報の指定を完了したら、「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 12cデータベース以上のバージョンを使用している場合、これらの値は必要ありません。

Oracle 11gデータベースを使用している場合のみ、次の値を入力します:
  • 「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。
  • 「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

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

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

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

タスク9   JDBC接続のテスト

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

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

ヒント:

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

タスク10   拡張構成の選択

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

  • 管理サーバー

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

  • ノード・マネージャ

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

  • トポロジ

    サーバー・テンプレート、管理対象サーバー、クラスタ、仮想ターゲットおよびCoherenceの設定の追加、削除または変更に必要です。

ノート:

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

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

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

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

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

  1. 「サーバー名」フィールドは、デフォルト値(AdminServer)のままにします。

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

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

  3. 「リスニング・ポート」フィールドに、管理サーバーにアクセスするポート番号を入力します。このガイドでは、デフォルトのポート7001を使用することをお薦めしています。

    他のフィールドでは、デフォルト値をそのまま使用します。特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。

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

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

ヒント:

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

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

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

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

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

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

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

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

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

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

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

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

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

    ノート:

    Oracle Web ServicesのNonceキャッシュは、WSM-CACHE-SVRサーバー・グループによって自動的に初期化され、ほとんどのアプリケーションに適しています。この初期化は、JRFを実行しているSOA、OSBおよび他のFMWサーバーで自動的に実行され、Coherenceクラスタを作成します。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。Nonceキャッシュは、Webサービス・アプリケーションを実行する追加された管理対象サーバーの台数に、無理なく合わせられます。

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

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

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

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

ヒント:

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

タスク14   クラスタの構成

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

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

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

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

ノート:

フロントエンド・ホストとフロントエンド・ポートを指定する場合は、この時点ではまだWeb層が設定されていないため、ドメイン構成後のURLの検証に失敗します。したがって、ホストされたアプリケーションでのリダイレクトはすべて、フロントエンド・アドレスに戻ります。LBRを通じてURLにアクセスするには、Web層を構成する必要があります。

フロントエンドのポートおよびアドレスは、後から構成できます。手順については、「WebLogicクラスタのフロントエンド・ホストおよびポートの設定」を参照してください。

ヒント:

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

タスク15   サーバー・テンプレートの割当て

「次」をクリックします。

タスク16 動的サーバーの構成

静的クラスタとして残そうとするクラスタに対して、動的サーバーのすべてのオプションが無効になっていることを確認します。

  1. この画面の「計算済リスニング・ポート」および「計算済マシン名」チェックボックスの選択が解除されていることを確認します。

  2. 「サーバー・テンプレート」の選択および「動的サーバー・グループ」が未指定であることを確認します。

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

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

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

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

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

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

      または

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

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

ヒント:

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

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

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

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

ノート:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。

タスク19   マシンの作成

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

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

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

    表10-2の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。

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

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

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

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

ADMINHOST

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

5556

SOAHOST1

SOAHOST1ホスト名変数またはSOAHOST1別名の値。たとえば、SOAHOST1.example.com。

5556

SOAHOST2

SOAHOST2ホスト名変数またはSOAHOST2別名の値。たとえば、SOAHOST2.example.com。

5556

ヒント:

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

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

「サーバーのマシンへの割当」画面を使用して、静的に定義された管理対象を適切なマシンに割り当てます。動的クラスタの一部であるサーバーは、計算済マシン名に自動的に割り当てられます。

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

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

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

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

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

ヒント:

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

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

「次」をクリックします。

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

「次」をクリックします。

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

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

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

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

終了したら、「構成の進行状況」画面で「次へ」をクリックします。

ヒント:

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

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

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

  • ドメインの場所

  • 管理サーバーURL

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

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

静的クラスタを含めるドメインの作成が完了したら、「エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成」に進みます。

動的クラスタを含めるドメインの作成

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

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

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

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

ヒント:

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

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

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

  • Oracle Enterprise Manager [em]

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

    • Oracle JRF - [oracle_common]

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

  • Oracle WSMポリシー・マネージャ[oracle_common]

ヒント:

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

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

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

ヒント:

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

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

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

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

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

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

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

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

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

ヒント:

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

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

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

「データベース構成タイプ」画面で、次のようにします。

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

    「RCUデータ」オプションは、構成ウィザードでデータベースとサービス表(STB)スキーマに接続するよう指示します。この接続は、スキーマがドメインを構成するためのスキーマ情報を自動的に取得します。

  • 「ベンダー」がOracle、「ドライバ」が*Oracle's Driver (Thin) for Service Connections; Versions: Anyであることを確認します。

  • 「接続パラメータ」が選択されていることを確認します。

ノート:

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

「RCUデータ」を選択したら、次の表に示すフィールドに入力します。

フィールド 説明

ホスト名

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

DBMS/サービス

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

orcl.example.com

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

ポート

データベースがリスニングするポート番号を入力します。たとえば、1521などです。

スキーマ所有者

スキーマ・パスワード

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

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

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

データベース接続情報の指定を完了したら、「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 12cデータベース以上のバージョンを使用している場合、これらの値は必要ありません。

Oracle 11gデータベースを使用している場合のみ、次の値を入力します:
  • 「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。
  • 「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

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

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

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

タスク9   JDBC接続のテスト

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

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

ヒント:

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

タスク10   拡張構成の選択

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

  • 管理サーバー

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

  • ノード・マネージャ

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

  • トポロジ

    サーバー・テンプレート、管理対象サーバー、クラスタ、仮想ターゲットおよびCoherenceの設定の追加、削除または変更に必要です。

ノート:

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

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

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

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

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

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

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

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

  3. 「リスニング・ポート」フィールドに、管理サーバーにアクセスするポート番号を入力します。このガイドでは、デフォルトのポート7001を使用することをお薦めしています。

    他のフィールドでは、デフォルト値をそのまま使用します。特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。

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

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

ヒント:

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

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

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

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

静的な管理対象サーバー値は構成しないでください。すべてのサーバーは動的に割り当てられます。

「次」をクリックします。

タスク14   クラスタの構成

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

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

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

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

ノート:

フロントエンド・ホストとフロントエンド・ポートを指定する場合は、この時点ではまだWeb層が設定されていないため、ドメイン構成後のURLの検証に失敗します。したがって、ホストされたアプリケーションでのリダイレクトはすべて、フロントエンド・アドレスに戻ります。LBRを通じてURLにアクセスするには、Web層を構成する必要があります。

フロントエンドのポートおよびアドレスは、後から構成できます。手順については、「WebLogicクラスタのフロントエンド・ホストおよびポートの設定」を参照してください。

ヒント:

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

タスク15   サーバー・テンプレートの割当て

「サーバー・テンプレート」画面を使用して、テンプレートを構成します。

  1. 「名前」フィールドでwsmpm-server-templateが選択されていることを確認します。

  2. 「リスニング・ポート」フィールドで、7009を指定します。

  3. 「SSLの有効化」オプションは未選択のままにしておきます。

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

タスク16 動的サーバーの構成
「動的クラスタ」画面を使用して、必要なクラスタを構成します。

  1. 「クラスタ名」フィールドにWSM-PM_Clusterがリストされていることを確認します。

  2. 「サーバー・テンプレート」ドロップダウン・リストで、「wsmpm-server-template」を選択します。

  3. 「サーバー名の接頭辞」フィールドで、WLS_WSMを指定します。

  4. 「動的クラスタ・サイズ」フィールドに2を指定します。

  5. 「マシン名マッチング式」フィールドでSOAHOST*を指定し、「計算済マシン名」を選択します。

    ノート:

    動的クラスタの「計算済マシン名」および「マシン名マッチング式」属性は、動的クラスタ内のサーバー・インスタンスをマシンに割り当てる方法を制御します。「計算済マシン名」属性がFalseに設定されている場合、動的サーバーはマシンに割り当てられません。「計算済マシン名」属性が「true」に設定されている場合は、「マシン名マッチング式」属性を使用して、動的クラスタに使用される一連のマシンが選択されます。「マシン名マッチング式」属性が設定されていない場合、ドメイン内のすべてのマシンが選択されます。割当は、ラウンド・ロビン・アルゴリズムを使用して行われます。

    作業を簡単にするために、タスク18「マシンの作成」で説明しているように、実際の物理的なホスト名とは関係なく、WebLogicマシン名としてSOAHOSTnを使用することをお薦めします。このnは連番です。この規則によって、動的クラスタは各クラスタ・メンバーをどこで起動するかを決定しやすくなっています。この規則に従う場合は、「マシン・マッチング式」フィールドに「SOAHOST*」と入力します。

    この規則に従わない場合、クラスタ・メンバーはタスク18「マシンの作成」で定義する各マシンで起動します。これには、ADMINHOSTも含まれます。この状況は、同じ物理サーバーで実行されているが2つ別々のドメイン・ホームにアタッチされている2つのクラスタ・メンバーがあるときには、望ましくありません。

  6. 「計算済リスニング・ポート」フィールドを選択します。

    ノート:

    「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、自動的に作成される動的管理対象サーバーごとに増分でポート番号が割り当てられます。つまり、動的サーバー1にはリスニング・ポート+1、動的サーバー2にはリスニング・ポート+2が使用されます。

    構成済のリスニング・ポートは7009で、計算済のポートがチェックされるので、WSMPM動的サーバーは次のポートを使用します。

    • WLS_WSM1サーバーは、ポート7010でリスニングします

    • WLS_WSM2サーバーは、ポート7011でリスニングします

  7. 「動的サーバー・グループ」で「WSMPM-DYN-CLUSTER」を選択します。

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

ノート:

構成ウィザードで、動的サーバーに対して特定のリスニング・アドレスを指定することはできません。動的クラスタのメンバーであるWebLogicサーバーへの特定リスニング・アドレスの設定については、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。

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

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

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

ノート:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。

タスク18   マシンの作成

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

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

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

    表10-2の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。

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

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

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

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

ADMINHOST

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

5556

SOAHOST1

SOAHOST1ホスト名変数またはSOAHOST1別名の値。たとえば、SOAHOST1.example.com。

5556

SOAHOST2

SOAHOST2ホスト名変数またはSOAHOST2別名の値。たとえば、SOAHOST2.example.com。

5556

ノート:

マシンの名前は、「マシン・マッチング式」フィールドで指定した値に連番が付いた名前になります。つまり、「マシン・マッチング式」フィールドにSOAHOST*を指定しておくと、マシンの名前はSOAHOST1、SOAHOST2のようになります。

ヒント:

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

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

「サーバーのマシンへの割当」画面を使用して、静的に定義された管理対象を適切なマシンに割り当てます。動的クラスタの一部であるサーバーは、計算済マシン名に自動的に割り当てられます。

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

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

「次」をクリックします。

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

「次」をクリックします。

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

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

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

「作成」をクリックすると、ドメインの作成が開始されます。

終了したら、「構成の進行状況」画面で「次へ」をクリックします。

ヒント:

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

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

「構成に成功しました」画面には、構成したドメインに関する次の項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

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

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

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

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

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

  • ホストごとのノード・マネージャ構成の作成
    ホストごとのノード・マネージャの構成のステップでは、構成ディレクトリおよび2つの新規ノード・マネージャ構成ファイルを作成します。デフォルトのstartNodeManager.shファイルを編集する必要もあります。
  • boot.propertiesファイルの作成
    管理サーバーの資格証明を要求されることなく管理サーバーを起動する必要がある場合は、boot.propertiesを作成する必要があります。このステップは、エンタープライズ・デプロイメントで必要です。管理サーバーを起動すると、このファイルに入力した資格証明が暗号化されます。
  • SOAHOST1でのノード・マネージャの起動
    ホストごとのノード・マネージャ構成を使用するようノード・マネージャを手動で設定したら、startNodeManager.shスクリプトを使用して、SOAHOST1でノード・マネージャを起動できます。
  • ノード・マネージャ資格証明およびタイプの構成
    デフォルトでは、ホストごとのノード・マネージャ構成では、ノード・マネージャからサーバーへの通信にSecure Socket Layer (SSL)は使用されません。このため、ドメイン内の各システムを、SSLではなくプレーン通信タイプを使用するように構成する必要があります。また、ドメイン内の管理サーバーおよび管理対象サーバーに接続できるようにノード・マネージャ資格証明を設定する必要があります。

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

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

ホストごとのノード・マネージャの構成のステップでは、構成ディレクトリおよび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. WL_HOME/server/binディレクトリでstopNodeManager.shスクリプトを検索します。ノード・マネージャ・ホーム・ディレクトリにコピーします。コピーしたファイルを編集し、(startNodemanager.shファイルの場合と同様に)ノード・マネージャ・ホームを指すNODEMGR_HOMEプロパティを編集します:
    NODEMGR_HOME="NM_HOME"

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

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

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

  9. SOAHOST2でステップ1から8を実行します。
  10. 次のエントリを新しい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.4.0
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

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

boot.propertiesファイルの作成

管理サーバー資格証明を要求されずに管理サーバーを起動したい場合は、boot.propertiesを作成する必要があります。このステップは、エンタープライズ・デプロイメントで必要です。管理サーバーを起動すると、このファイルに入力した資格証明が暗号化されます。

管理サーバーのboot.propertiesファイルを作成するには:

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

    ノート:

    管理サーバーの起動時には、このファイルのusernameとpasswordのエントリは暗号化されています。

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

  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>

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

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

デフォルトでは、ホストごとのノード・マネージャ構成では、ノード・マネージャからサーバーへの通信に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. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
    8. AdminServerを再起動します。
  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','<password>','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]を押して、管理サーバーのプロセスを停止します。

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

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

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

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

  • ノード・マネージャを使用した管理サーバーの起動
    ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。
  • 管理サーバーの検証
    構成ステップに進む前に、管理サーバーが正常に起動して実行されていることを検証するために、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlへのアクセス権があることを確認します。
  • SOAHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成
    エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。これで、SOAHOST1とSOAHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。
  • SOAHOST1でのWLS_WSM1管理対象サーバーの起動と検証
    ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してSOAHOST1でWLS_WSM1管理対象サーバーを起動できます。

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

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

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

ノード・マネージャを使用して管理サーバーを起動するには:

  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()

親トピック: ドメイン・ディレクトリの構成とSOAHOST1上のサーバーの起動

管理サーバーの検証

構成ステップに進む前に、管理サーバーが正常に起動して実行されていることを検証するために、管理サーバーにインストールおよび構成されている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

親トピック: ドメイン・ディレクトリの構成とSOAHOST1上のサーバーの起動

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

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

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

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

管理対象サーバーのドメイン・ディレクトリを作成するには:

  1. SOAHOST1にサインインし、次のようにpackコマンドを実行してテンプレートを作成します。
    cd ORACLE_COMMON_HOME/common/bin
 
./pack.sh -managed=true \ 
          -domain=ASERVER_HOME \ 
          -template=/full_path/create_domain.jar \ 
          -template_name=create_domain_template \
	  -log_priority=DEBUG \ 
          -log=/tmp/pack.log

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

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

    • full_pathを、ドメイン・テンプレートJARファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートJARファイルをコピーまたは解凍する際に、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、サーバー間でファイルを手動でコピーすることをお薦めします。

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

      SHARED_CONFIG_DIR/domains/template_filename.jar

    • create_domain.jarファイルは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

    • create_domain_templateラベルは、テンプレート・ファイルに格納されているテンプレート・データに割り当てられるラベルです。

  2. packコマンドで作成したばかりのcreate_domain.jarファイルの場所をノートにとります。

    ヒント:

    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=/full_path/create_domain.jar \
	    -log_priority=DEBUG \
            -log=/tmp/unpack.log \
            -app_dir=APPLICATION_HOME

    ノート:

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

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

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

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

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

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

    ヒント:

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

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

親トピック: ドメイン・ディレクトリの構成とSOAHOST1上のサーバーの起動

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

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

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

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

  2. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。たとえば、weblogicを使用します。
  3. 「サーバー」ペインを選択して、ドメイン内の管理対象サーバーを表示します。
  4. WLS_WSM1管理対象サーバーのみを選択し、割り当てられたポート番号を書き留めてください。
  5. ツールバーで「制御」→「起動」をクリックし、選択したWLS_WSM1管理対象サーバーを起動します。
  6. 管理対象サーバーが正しく機能していることを検証するには、ブラウザを開き、次のURLを入力します。
    SOAHOST1:7010/wsm-pm/

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

    ノート:

    静的または動的クラスタへの割当てに従って、適切なポート番号を使用してください。リスニング・ポートの計算オプションを選択する場合、自動的に作成される動的な管理対象サーバーごとのポート番号は1ずつ増分されます。 動的サーバー1は「リスニング・ポート」+1、動的サーバー2は「リスニング・ポート」+2を使用します。

    動的クラスタに構成済のリスニング・ポートは7009で、計算済のポートがチェックされるので、WSMPM動的サーバーは次のポートを使用します。

    • http://SOAHOST1:7010/wsm-pm/
    • http://SOAHOST2:7011/wsm-pm/

親トピック: ドメイン・ディレクトリの構成とSOAHOST1上のサーバーの起動

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

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

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

SOAHOST2でのドメインの解凍

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

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

./unpack.sh -domain=MSERVER_HOME \
            -overwrite_domain=true \
            -template=/full_path/create_domain.jar \ 
            -log_priority=DEBUG \
            -log=/tmp/unpack.log \
            -app_dir=APPLICATION_HOME

    ノート:

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

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

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

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

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

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

    ヒント:

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

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

親トピック: ドメインの伝播とSOAHOST2上のサーバーの起動

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

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

親トピック: ドメインの伝播とSOAHOST2上のサーバーの起動

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

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

親トピック: ドメインの伝播とSOAHOST2上のサーバーの起動

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

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。「エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更」を参照してください。

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

動的クラスタを使用する際のリスニング・アドレスの構成

動的クラスタにおける動的な管理対象サーバーのデフォルト構成では、使用可能なネットワーク・インタフェースすべてでリスニングするようになっています。ほとんどの場合、デフォルトの構成では不適切です。

動的クラスタを使用する際に、リスニング・アドレスを特定のアドレスに限定するには、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。前の項でリスニング・アドレスを変更したときに指定されたテストURLを再確認し、クラスタ化された管理対象サーバーを再起動します。

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

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

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

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

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

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

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

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

  • Oracle Unified Directory

  • Oracle Internet Directory

  • Microsoft Active Directory

ノート:

ここに示す手順では、デフォルトで、暗号化されていない接続を使用して、単一のLDAPアイデンティティ・ストアに対する問合せをサポートするようにアイデンティティ・サービス・インスタンスを構成する方法を説明します。

アイデンティティ・プロバイダへの接続をSSLで保護する必要がある場合、正しく機能するには、Enterprise Manager Fusion Middleware Controlでのロール管理に追加のキーストーン構成が必要です。構成の詳細は、support.oracle.comでDoc ID 1670789.1を参照してください。

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

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

親トピック: 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループの作成

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

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

親トピック: 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループの作成

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

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

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

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

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

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

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

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

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

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

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

仮想化を有効にするには:

  1. Fusion Middleware Controlに移動して、管理者の資格証明でログインします。

    http://adminvhn:7001/em

  2. 「WebLogicドメイン」 → 「セキュリティ」 → 「セキュリティ・プロバイダ構成」に移動します。

  3. 「セキュリティ・ストア・プロバイダ」を開きます。

  4. 「アイデンティティ・ストア・プロバイダ」を開きます。

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

  6. カスタム・プロパティを追加します。

  7. 次のプロパティを設定します。
    • virtualize (値true)
    • optimize_search (値true)

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

  8. もう一度「OK」をクリックすると、変更が確定します。

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

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

ノート:

virtualizeをtrueに設定した場合、LDAPのユーザーまたはグループを作成するアプリケーションで、アイデンティティ・ストア・プロバイダ内の次の2つのカスタム・プロパティがさらに必要になります。

  • プロパティuser.create.bases。作成するユーザーのDNを指定するためにあります。例: cn=users,dc=example,dc=com

  • プロパティgroup.create.bases。作成するグループのDNを指定するためにあります。例: cn=groups,dc=example,dc=com

virtualizeプロパティを追加するには、前述のステップに従ってこれらのプロパティを構成します。

SOA製品にはLDAPのユーザーまたはグループを作成するアプリケーションがないため、これは、それを行うアプリケーションを追加でデプロイする場合のみ必要となります。Oracle Platform Security Servicesによるアプリケーションの保護のアイデンティティ・ストアの構成を参照してください。

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

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

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

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

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

このガイドで使用する例では、次の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

ノート:

このユーザーに、次のグループのメンバーシップを付与することで、読取りおよび書込みアクセス権を付与する必要があります。

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

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

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

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

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

ASERVER_HOME/servers/AdminServer/security

親トピック: 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループの作成

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=com
changetype: modify
add: uniquemember
uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=com

dn: cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=com

dn: cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=com
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 idstore.example.com
                                 -D "cn=oudadmin" \
                                 -w password \
                                 -p 1389 \
                                 -f domain_user.ldif

    Oracle Internet Directoryの場合:

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

親トピック: 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループの作成

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

新しい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サーバーに固有の詳細を入力します。

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

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

    ホスト

    たとえば: idstore.example.com

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

    ポート

    たとえば: 1389

    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. 「プロバイダ」ページで、DefaultAuthenticatorをクリックします。

  19. 「制御フラグ」ドロップダウンから、SUFFICIENTを選択します。

  20. 「保存」をクリックしてDefaultAuthenticatorの設定を更新します。

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

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

    管理対象サーバーを停止するには、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にログインし、管理対象サーバーを選択して、ツールバーで「起動」をクリックします。

    ノート:

    中央のLDAPユーザー・メールを使用してただちにシステムにログインする予定の場合は、新しいエンタープライズ・デプロイメント管理グループに管理ロールを割り当てるまで、再起動をスキップすることができます。詳細は、管理グループへの新しい管理ユーザーの追加を参照してください。

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

    ASERVER_HOME/servers/AdminServer/logs/AdminServer.log

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

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

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

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

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

親トピック: 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループの作成

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

この例では、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 idstore.example.com
                                 -D "cn=oudadmin" \
                                 -w password \
                                 -p 1389 \
                                 -f admin_user.ldif

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h idstore.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: GroupOfUniqueNames
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 1380 \
                                 -f admin_group.ldif

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h oidhost.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. プロビジョニングした管理者ユーザーおよびグループがページに表示されていることを確認します。

親トピック: 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループの作成

新しい管理グループへの管理ロールの追加

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にログインできる場合は、プロバイダは正常に構成されています。

親トピック: 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループの作成

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. 管理サーバーを再起動します。

親トピック: 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループの作成

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

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

  1. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。たとえば、weblogic_soaを使用します
  2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
  3. 「アプリケーション・ストライプ」ドロップダウン・メニューからwsm-pmアプリケーション・ストライプを選択します。
  4. ロール名テキスト・ボックスの隣にある三角形のアイコンをクリックし、wsm-pmアプリケーション・ストライプのロール名をすべて検索します。
  5. 編集するpolicy.Updater の行を選択します。
  6. アプリケーション・ロールの「編集」アイコンをクリックして、ロールを編集します。
  7. 「アプリケーション・ロールの編集」ページで、アプリケーション・ロールの「追加」アイコンをクリックします。
  8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。
  9. エンタープライズ・デプロイメントの管理者グループを検索するには、「プリンシパル名」の「次で始まる」フィールドにグループ名SOA Administratorsを入力し、右矢印をクリックして検索を開始します。
  10. 検索結果で適切な管理者グループを選択し、「OK」をクリックします。
  11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

スケール・アウトで想定されるシナリオに備える追加のステップについては、クロス・コンポーネント・ワイヤリングについての考慮事項を参照してください。

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

構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

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

管理サーバーの手動フェイルオーバーの確認

ドメインを構成したら、フェイルオーバーをテストする必要があります。テストする手順は、「管理サーバーの手動フェイルオーバーの検証」を参照してください。

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