10 エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成
- インフラストラクチャ・ドメインの作成時に使用する変数
この章のタスクを実行する際には、この項にリストされているディレクトリ変数を参照します。 - 初期インフラストラクチャ・ドメインについて
初期インフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。 - Infrastructureドメインでの動的クラスタのサポート
Infrastructureドメインは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。 - WCCHOST1へのOracle Fusion Middleware Infrastructureのインストール
エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を使用してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。 - データベース・スキーマの作成
Oracle Fusion Middlewareコンポーネントでは、Fusion Middleware Infrastructureドメインを構成する前に、データベースにスキーマが存在していることが必要になります。このトピックの動作保証されたデータベースにリストされているスキーマを、このリリースのOracle Fusion Middlewareと組み合せて使用するためにインストールします。 - インフラストラクチャ・ドメインの構成
次の各項では、Fusion Middleware構成ウィザードを使用してWebLogic Serverドメインを作成するための手順を示します。 - WCCHOST1でのドメイン・ディレクトリの構成とサーバーの起動
ドメインを作成してノード・マネージャを構成したら、WCCHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。 - WCCHOST2でのドメインの伝播とサーバーの起動
WCCHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、WCCHOST2で次のタスクを実行できます。 - エンタープライズ・ドメインでのuploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。 - 動的クラスタの使用時のリスニング・アドレスの構成
- 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング
Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator
)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。 - Administratorsグループへのwsm-pmロールの追加
新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(WCPAdministrators
)をメンバーとしてwsm-pm
アプリケーション・ストライプのpolicy.Updater
ロールに追加します。 - WebLogicプロキシ・プラグインの構成
- 構成のバックアップ
ベスト・プラクティスとして、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。ここまでのインストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。 - 管理サーバーの手動フェイルオーバーの確認
上位トピック: 「エンタープライズ・ドメインの構成」
インフラストラクチャ・ドメインの作成時に使用する変数
この章のタスクを実行する際には、この項にリストされているディレクトリ変数を参照します。
これらのディレクトリ変数については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。
-
ORACLE_HOME
-
ASERVER_HOME
-
MSERVER_HOME
-
APPLICATION_HOME
-
JAVA_HOME
-
NM_HOME
さらに、「エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名も参照します。
-
ADMINVHN
-
WCCHOST1
-
WCCHOST2
-
WCPHOST1
-
WCPHOST2
-
DBHOST1
-
DBHOST2
-
Oracle RACデータベースのSCANアドレス(
DB-SCAN.example.com
)
初期インフラストラクチャ・ドメインについて
初期インフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。
インフラストラクチャ・ディストリビューションについて
エンタープライズ・デプロイメントの初期インフラストラクチャ・ドメインの作成には、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の専用クラスタを含む。 |
|
ドメインごとのノード・マネージャ構成を使用。 |
|
別途インストールされたLDAPベースの認証プロバイダが必要。 |
親トピック: 初期インフラストラクチャ・ドメインについて
Infrastructureドメインでの動的クラスタのサポート
Infrastructureドメインは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。
静的クラスタは、構成済クラスタとも言い、各サーバー・インスタンスを手動で構成して追加する従来型のクラスタです。動的クラスタには、新しい"server-template"オブジェクトが含まれています。このオブジェクトは、すべての生成された(動的)サーバー・インスタンスの一元的な構成を定義するために使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。この機能により、追加のサーバー容量が必要になったときに、動的クラスタ内のサーバー・インスタンスの数をスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。
-
構成ウィザードのプロセスは、それぞれのケースに応じて異なることがあります。たとえば、サーバーではなく動的クラスタ用のサーバー・テンプレートの定義が必要になります。
-
動的クラスタの場合は、サーバー固有の構成(リスニング・アドレスの設定、アップロードとステージングのディレクトリの構成、キーストアの構成など)をサーバーではなくサーバー・テンプレートで実行する必要があります。
-
動的クラスタの場合は、サービス移行が異なる方法で構成されます。動的クラスタは移行可能ターゲットを使用しないかわりに、JMSリソースがクラスタをターゲットにします。動的クラスタのサービス移行を構成する際の具体的な手順は、このガイドに記載されています。
複合クラスタ(動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を含むクラスタ)は、Oracle WebCenter Portalエンタープライズ・デプロイメントではサポートされていません。
WCCHOST1へのOracle Fusion Middleware Infrastructureのインストール
エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。
- サポートされているJDKのインストール
- WCCHOST1でのインフラストラクチャ・インストーラの起動
- Infrastructureインストール画面のナビゲート
- 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール
- ディレクトリ構造のチェック
Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、この項にリストされたディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。 - Derbyデータベースの無効化
サポートされているJDKのインストール
Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (JDK)がシステムにインストールされている必要があります。
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のインストール
JDKソフトウェアのインストール
アプリケーション層ホストの/u01/oracle/products
にマウントされている共有記憶域ボリュームVOL1
とVOL2
にJDKをインストールします。JDKをアップグレードする際に再構成の問題を回避するため、JDKのフォルダ名にはバージョン番号を含めないでください。たとえば、/u01/oracle/products/jdk
です。
注意:
推奨されるマウント・ポイントが複数製品の共有ボリュームを使用するため、複数のインストールが必要になる場合があります。JDKソフトウェアの推奨場所の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。
次の例では、JDK 1.8.0_131の最新バージョンをインストールする方法について説明します。
親トピック: サポートされているJDKのインストール
WCCHOST1でのインフラストラクチャ・インストーラの起動
インストール・プログラムを起動するには、次のステップを実行します。
インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明については、「インストール画面のナビゲート」を参照してください。
Infrastructureインストール画面のナビゲート
インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。
インストール画面についての詳細情報が必要な場合は、画面名をクリックするか、画面上で「ヘルプ」ボタンをクリックしてください。
表10-1 Infrastructureインストール画面のナビゲート
画面 | 説明 |
---|---|
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の使用」を参照してください。 |
|
この画面では、インストールの進行状況を参照できます。 |
|
インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。 |
他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール
セカンダリ・ホストに別の共有記憶域ボリュームまたはパーティションを構成している場合は、それらのホストにもソフトウェアをインストールする必要があります。
「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。
トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「WCCHOST1でのインフラストラクチャ・インストーラの起動」と「インフラストラクチャ・インストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。
注意:
以前のリリースでは、推奨エンタープライズ・トポロジに、同じ場所に配置された一連のOracle HTTP Serverインスタンスが含まれていました。これらのリリースでは、InfrastructureをWeb層ホスト(WEBHOST1およびWEBHOST2)にインストールする要件がありました。しかし、このリリースの場合、エンタープライズ・デプロイメント・トポロジでは、Webサーバーがスタンドアロン・モードでインストールおよび構成されると想定しているため、これらがアプリケーション層ドメインに含まれるとは考えられていません。「エンタープライズ・デプロイメント用のWeb層の構成」を参照してください
ディレクトリ構造のチェック
Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、この項にリストされたディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。
ディレクトリ構造をチェックするには:
データベース・スキーマの作成
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画面のナビゲート
Fusion Middleware Infrastructureドメインにスキーマを作成するには、この項の手順に従います。
- タスク1 RCUの導入
-
「ようこそ」画面でRCUのバージョン番号を確認します。「次へ」をクリックして開始します。
- タスク2 スキーマ作成の方法の選択
-
データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「リポジトリの作成」画面で「システム・ロードおよび製品ロード」を選択します。このドキュメントの手順では、必要な権限があることを想定しています。
データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。このオプションでは、SQLスクリプトが生成され、それをデータベース管理者に提供できます。『リポジトリ作成ユーティリティによるスキーマの作成』のシステム・ロードと製品ロードの理解に関する項を参照してください。
「次」をクリックします。
ヒント:
この画面の選択内容の詳細は、リポジトリ作成ユーティリティによるスキーマの作成でリポジトリの作成に関する項を参照してください。
- タスク3 データベース接続の詳細の指定
-
RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。
-
「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。
-
RACデータベース・スキャン・リスナーのポート番号(1521など)を入力します。
-
データベースのRAC「サービス名」を入力します。
-
スキーマとスキーマ・オブジェクトを作成する権限を持つユーザーの「ユーザー名」、たとえば「SYS」などを入力します。
-
ステップ4で指定した名前のユーザーの「パスワード」を入力します。
-
SYSユーザーを選択した場合は、ロールを必ずSYSDBAに設定してください。
-
「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。
ヒント:
この画面の選択内容の詳細は、リポジトリ作成ユーティリティによるスキーマの作成でデータベース接続の詳細に関する項を参照してください。
-
- タスク4 カスタム接頭辞の指定とスキーマの選択
-
-
Oracle Fusion Middlewareスキーマの識別に使用するカスタム接頭辞を指定します。
注意:
RCUの制限が12文字であっても、WebCenter Portalスキーマを含める際は、カスタム接頭辞を10文字にする必要があります。これは、WebCenter Portalスキーマのフルネームを検証する際にRCUエラーを回避するためです。スキーマ・ユーザー名の最大長は、合計30文字に制限されます。WebCenter Portalスキーマの接尾辞は、最大20文字まで使用します。カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。このガイドでは、
FMW1221_
という接頭辞を使用しますヒント:
ここで入力したカスタム接頭辞を書き留めてください。これは後でドメインの作成時に必要になります。
カスタム接頭辞の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のカスタム接頭辞の理解に関する項を参照してください。
-
「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に入力した適切なスキーマ名およびパスワードを入力します。
次に例を示します。
./sqlplus
SQL*Plus: Release 12.1.0.2.0 Production on Wed Mar 15 03:17:54 2017
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Enter user-name: FMW1221_WLS
Enter password: WLS_schema_password
Last Successful login time: Tue Feb 28 2017 09:37:25 -07:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Real Application Clusters, Automatic Storage Management, OLAP, Advanced Analytics and Real Application Testing options
SQL>
親トピック: データベース・スキーマの作成
インフラストラクチャ・ドメインの構成
次の各項では、Fusion Middleware構成ウィザードを使用してWebLogic Serverドメインを作成するための手順を示します。
ドメイン作成に使用可能なその他の方法の詳細は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの作成、拡張および管理のための追加ツールに関する項を参照してください。
構成ウィザードの起動
ドメインの構成を開始するには、WCCHOST1のOracle Fusion Middleware Oracleホームで次のコマンドを実行します。
ORACLE_HOME/oracle_common/common/bin/config.sh
親トピック: インフラストラクチャ・ドメインの構成
インフラストラクチャ・ドメインを構成するための構成ウィザード画面のナビゲート
次の各項に示す手順に従って、静的または動的クラスタを含むトポロジのドメインを作成および構成します。
静的クラスタを含めるドメインの作成
この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。
ドメインを作成して構成するためのタスクは次のとおりです。- タスク1 ドメイン・タイプとドメイン・ホームの場所の選択
-
「構成タイプ」画面で、「新規ドメインの作成」を選択します。
「ドメインの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。
ヒント:
構成ウィザードのこの画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。
- タスク2 構成テンプレートの選択
-
「テンプレート」画面では、「製品テンプレートを使用してドメインを作成」が選択されていることを確認し、次のテンプレートを選択します。
-
Oracle Enterprise Manager - 12.2.1.3.0[em]
このテンプレートを選択すると、次の依存性が自動的に選択されます。
-
Oracle JRF - 12.2.1.3.0[oracle_common]
-
WebLogic Coherenceクラスタの拡張 - 12.2.1.3.0 [wlserver]
-
-
Oracle WSM Policy Manager - 12.2.1.3.0[oracle_common]
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。
-
- タスク3 アプリケーション・ホームの場所の選択
-
「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のアプリケーションの場所に関する項を参照してください。
- タスク4 管理者アカウントの構成
-
「管理者アカウント」画面では、ドメインに対するデフォルトのWebLogic管理者アカウントにユーザー名とパスワードを指定します。
この画面で指定したユーザー名およびパスワードを書き留めておいてください。これらの資格証明は後でドメインの管理サーバーを起動して接続する際に必要になります。
- タスク5 ドメイン・モードとJDKの指定
-
「ドメイン・モードおよびJDK」画面では、次の操作を実行します。
-
「ドメイン・モード」フィールドで、「本番」を選択します。
-
「JDK」フィールドで「Oracle Hotspot JDK」を選択します。
この画面で「本番モード」を選択して、環境のセキュリティの程度を高めます。このモードでは、アプリケーションをデプロイして管理サーバーを起動するために、ユーザー名とパスワードが必要になります。
ヒント:
開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。
管理サーバーの起動時に起動IDファイルを作成することで、本番モードでもユーザー名とパスワードを指定する必要をなくすことができます。「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データベースのサービス名を入力します。次に例を示します。
wcedg.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に変換する手順は次のとおりです。
-
スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。
-
「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
)。これらの値は、Oracle 11gデータベースに接続する際には必須で、Oracleデータベース・リリース12c以上に接続する場合はオプションです。Oracle 12cデータベースを使用している場合、ONSリストはデータベースからドライバに自動的に提供されます。
FANの有効化
「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。
この画面で情報を指定する方法および適切なSCANアドレスの特定方法の詳細は、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。
また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。
- タスク9 JDBC接続のテスト
-
「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。
「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。
ヒント:
この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテストに関する項を参照してください
- タスク10 拡張構成の選択
-
目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。
-
管理サーバー
これは、管理サーバーのリスニング・アドレスを構成するために必要です。
-
ノード・マネージャ
これは、ノード・マネージャを構成するために必要です。
-
トポロジ
サーバー・テンプレート、管理対象サーバー、クラスタ、仮想ターゲットおよびCoherenceの設定の追加、削除または変更に必要です。
注意:
構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。
-
この画面で前述のオプションのいずれかが使用可能でない場合は、「テンプレート」画面に戻り、このトポロジに必要なテンプレートが選択されていることを確認します。
-
「ドメイン・フロントエンド・ホストのキャプチャ」拡張構成オプションを選択しないでください。後で、ドメインに対してではなく特定のクラスタに対してフロントエンド・ホスト・プロパティを構成します。
-
- タスク11 管理サーバーのリスニング・アドレスの構成
-
「管理サーバー」画面で、次の手順を実行します。
-
「サーバー名」フィールドで、デフォルト値(「AdminServer」)を維持します。
-
「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得して「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化したADMINVHNのVIPに対応する仮想ホスト名を入力します。
ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。
-
「リスニング・ポート」フィールドに、管理サーバーにアクセスするポート番号を入力します。このガイドでは、デフォルトのポート7001を使用するようお薦めしています。
他のフィールドでは、デフォルト値をそのまま使用します。特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。
-
- タスク12 ノード・マネージャの構成
-
ノード・マネージャ・タイプとして「ドメインごとのデフォルトの場所」を選択し、ノード・マネージャへの接続に使用するノード・マネージャ資格証明を指定します。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のノード・マネージャに関する項を参照してください。
ドメインごとおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。
ノード・マネージャの構成については、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。
- タスク13 管理対象サーバーの構成
-
「管理対象サーバー」画面で、2台の管理対象サーバーを新規作成します。
-
「追加」ボタンをクリックして、1台の管理対象サーバーを新規作成します。
-
「サーバー名」列で
WLS_WSM1
を指定します。 -
「リスニング・アドレス」列にWCCHOST1と入力します。
WCCHOST1に対応するホスト名を必ず入力して、IPアドレスは使用しないでください。
-
「リスニング・ポート」列に
7010
と入力します。 -
「サーバー・グループ」ドロップダウン・リストで、JRF-MAN-SVRおよびWSMPM-MAN-SVRを選択します。
これらのサーバー・グループによって、Oracle JRFとOracle Web Services Manager (OWSM)のサービスが、作成中の管理対象サーバーにターゲット設定されます。
サーバー・グループは、定義されたアプリケーション・サービスのグループをそれぞれに定義されたサーバー・グループにマッピングすることで、Fusion Middlewareアプリケーションおよびサービスを1つ以上のサーバーにターゲット設定します。特定のサーバー・グループにマップされた任意のアプリケーション・サービスは、そのグループに割り当てられたすべてのサーバーに自動的にターゲット指定されます。『ドメイン・テンプレート・リファレンス』のアプリケーション・サービス・グループ、サーバー・グループおよびアプリケーション・サービス・マッピングに関する項を参照してください。
注意:
Oracle Web ServicesのNonceキャッシュは、WSM-CACHE-SVRサーバー・グループによって自動的に初期化され、ほとんどのアプリケーションに適しています。この初期化は、SOA、OSB、およびJRFを実行してCoherenceクラスタを作成する他のFMWサーバーで自動的に実行されます。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。Nonceキャッシュは、Webサービス・アプリケーションを実行する管理対象サーバーの追加された台数にあわせて自然に変化します。
拡張キャッシュ構成の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOracle CoherenceでのNonceのキャッシュに関する項を参照してください。この項では、カスタムWLSサーバーでのNonceキャッシュとWSM-CACHE-SVRサーバー・グループの使用に関する追加のガイダンスを示します。
-
このプロセスを繰り返して、
WLS_WSM2
という名前の2つ目の管理対象サーバーを作成します。「リスニング・アドレス」列にWCCHOST2と入力します。「リスニング・ポート」に7010と入力します。最初の管理対象サーバーに適用したものと同じサーバー・グループをWLS_WSM2に適用します。
この手順で推奨する管理対象サーバー名(WLS_WSM1およびWLS_WSM2)はこのドキュメント全体で参照します。別の名前を選択した場合は、必要に応じてそれらの名前に置き換えてください。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。
-
- タスク14 クラスタの構成
-
「クラスタ」画面を使用して、新しいクラスタを作成します。
-
「追加」ボタンをクリックします。
-
「クラスタ名」フィールドで、
WSM-PM_Cluster
を指定します。 -
「動的サーバー・グループ」ドロップダウン・リストで、
未指定
を選択します。 -
「次」をクリックします。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。
-
- タスク15 サーバー・テンプレートの割当て
-
「次」をクリックします。
- タスク16 動的サーバーの構成
-
静的クラスタとして残そうとするクラスタに対して、動的サーバーのすべてのオプションが無効になっていることを確認します。
-
この画面の「動的クラスタ」、「計算済リスニング・ポート」および「計算済マシン名」チェック・ボックスの選択が解除されていることを確認します。
-
「サーバー・テンプレート」で「未指定」が選択されていることを確認します。
-
「次」をクリックします。
-
- タスク17 クラスタへの管理対象サーバーの割当て
-
「サーバーのクラスタへの割当」画面を使用して、
WLS_WSM1
およびWLS_WSM2
を新規クラスタWSM-PM_Cluster
に割り当てます。-
「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここでは
WSM-PM_Cluster
)を選択します。 -
「サーバー」ペインで、次のいずれかの操作を実行して、
WLS_WSM1
をWSM-PM_Cluster
に割り当てます。-
「
WLS_WSM1
」を1回クリックして選択し、右矢印をクリックして「クラスタ」ペインの選択されているクラスタ(WSM-PM_Cluster
)の下に移動します。または
-
「
WLS_WSM1
」をダブルクリックして、クラスタ・ペインの選択されているクラスタ(WSM-PM_Cluster
)の下に移動します。
-
-
これらのステップを繰り返して、WLS_WSM2管理対象サーバーをWSM-PM_Clusterに割り当てます。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタへのサーバーの割当に関する項を参照してください。
-
- タスク18 Coherenceクラスタの構成
-
「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。
「クラスタ・リスニング・ポート」に
9991
と入力します。注意:
Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。
- タスク19 マシンの作成
-
「マシン」画面を使用して、ドメイン内に新規マシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。
-
「Unixマシン」タブを選択します。
-
「追加」ボタンをクリックし、新しいUNIXマシンを作成します。
表10-2の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。
-
「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。
この例に示されているポート番号
5556
は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。
表10-2 Unixマシンの作成時に使用する値
名前 ノード・マネージャのリスニング・アドレス ノード・マネージャのリスニング・ポート ADMINHOST
ADMINVHN変数の値を入力します。
5556
WCCHOST1
WCCHOST1ホスト名変数またはWCCHOST1別名の値。たとえば、
WCCHOST1.example.com
などです。5556
WCCHOST2
WCCHOST2ホスト名変数またはWCCHOST2別名の値。たとえば、
WCCHOST2.example.com
などです。5556
WCPHOST1
WCPHOST1ホスト名変数の値。たとえば、
WCPHOST1.example.com
となります。5556
WCPHOST2
WCPHOST2ホスト名変数の値。たとえば、
WCPHOST2.example.com
となります。5556
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンに関する項を参照してください。
-
- タスク20 マシンへのサーバーの割当て
-
「サーバーのマシンへの割当」画面を使用して、静的に定義された管理対象を適切なマシンに割り当てます。動的クラスタの一部であるサーバーは、計算済マシン名に自動的に割り当てられます。
「サーバーのマシンへの割当」画面は、管理対象サーバーのクラスタへの割当て画面に似ています。「マシン」列でターゲット・マシンを選択し、左の列でサーバー名を選択した後、右矢印をクリックしてそのサーバーを適切なマシンに割り当てます。
次のように、サーバーを割り当てます。
-
AdminServerをADMINHOSTマシンに割り当てます。
-
WLS-WSM1管理対象サーバーをWCCHOST1マシンに割り当てます。
-
WLS-WSM2管理対象サーバーをWCCHOST2マシンに割り当てます。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のサーバーのマシンへの割当てに関する項を参照してください。
-
- タスク21 仮想ターゲットの作成
-
「次」をクリックします。
- タスク22 パーティションの作成
-
「次」をクリックします。
- タスク23 構成の仕様の確認とドメインの構成
-
「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。
変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで、任意の画面に戻れます。
ドメイン作成は、「作成」をクリックするまでは開始されません。
終了したら、「構成の進行状況」画面で「次へ」をクリックします。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。
- タスク24 ドメイン・ホームと管理サーバーURLのメモ
-
「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。
-
ドメインの場所
-
管理サーバーURL
どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。
「終了」をクリックして、構成ウィザードを閉じます。
-
静的クラスタを含めるドメインの作成が完了したら、「WCCHOST1でのドメイン・ディレクトリの構成とサーバーの起動」に進みます。
動的クラスタを含めるドメインの作成
この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。
- タスク1 ドメイン・タイプとドメイン・ホームの場所の選択
-
「構成タイプ」画面で、「新規ドメインの作成」を選択します。
「ドメインの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。
ヒント:
構成ウィザードのこの画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。
- タスク2 構成テンプレートの選択
-
「テンプレート」画面では、「製品テンプレートを使用してドメインを作成」が選択されていることを確認し、次のテンプレートを選択します。
-
Oracle Enterprise Manager -12.2.1.3.0[em]
このテンプレートを選択すると、次の依存性が自動的に選択されます。
-
Oracle JRF -12.2.1.3.0[oracle_common]
-
WebLogic Coherenceクラスタの拡張 -12.2.1.3.0 [wlserver]
-
-
Oracle WSM Policy Manager -12.2.1.3.0[oracle_common]
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。
-
- タスク3 アプリケーション・ホームの場所の選択
-
「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のアプリケーションの場所に関する項を参照してください。
- タスク4 管理者アカウントの構成
-
「管理者アカウント」画面では、ドメインに対するデフォルトのWebLogic管理者アカウントにユーザー名とパスワードを指定します。
この画面で指定したユーザー名およびパスワードを書き留めておいてください。これらの資格証明は後で管理サーバー・ドメインを起動して接続する際に必要です。
- タスク5 ドメイン・モードとJDKの指定
-
「ドメイン・モードおよびJDK」画面では、次の操作を実行します。
-
「ドメイン・モード」フィールドで、「本番」のみを選択します。
-
「JDK」フィールドで「Oracle Hotspot JDK」を選択します。
この画面で「本番モード」を選択して、環境のセキュリティを高めます。この場合、アプリケーションをデプロイして管理サーバーを起動するために、ユーザー名とパスワードが必要になります。
ヒント:
開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。
管理サーバーの起動時に起動IDファイルを作成することで、本番モードでもユーザー名とパスワードを指定する必要をなくすことができます。「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に変換する手順は次のとおりです。
-
スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。
-
「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
)。これらの値は、Oracle 11gデータベースに接続する際には必須で、Oracleデータベース・リリース12c以上に接続する場合はオプションです。Oracle 12cデータベースを使用している場合、ONSリストはデータベースからドライバに自動的に提供されます。
FANの有効化
「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。
この画面で情報を指定する方法および適切なSCANアドレスの特定方法の詳細は、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。
また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。
- タスク9 JDBC接続のテスト
-
「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。
「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。
ヒント:
この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテストに関する項を参照してください
- タスク10 拡張構成の選択
-
目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。
-
管理サーバー
これは、管理サーバーのリスニング・アドレスを構成するために必要です。
-
ノード・マネージャ
これは、ノード・マネージャを構成するために必要です。
-
トポロジ
サーバー・テンプレート、管理対象サーバー、クラスタ、仮想ターゲットおよびCoherenceの設定の追加、削除または変更に必要です。
注意:
構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。
-
この画面で前述のオプションのいずれかが使用可能でない場合は、「テンプレート」画面に戻り、このトポロジに必要なテンプレートが選択されていることを確認します。
-
「ドメイン・フロントエンド・ホストのキャプチャ」拡張構成オプションを選択しないでください。後で、ドメインに対してではなく特定のクラスタに対してフロントエンド・ホスト・プロパティを構成します。
-
- タスク11 管理サーバーのリスニング・アドレスの構成
-
「管理サーバー」画面で、次の手順を実行します。
-
「サーバー名」フィールドで、デフォルト値(
AdminServer
)を維持します。 -
「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得して「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化したADMINVHNのVIPに対応する仮想ホスト名を入力します。
ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。
-
「リスニング・ポート」フィールドに、管理サーバーにアクセスするポート番号を入力します。このガイドでは、デフォルトのポート7001を使用するようお薦めしています
他のフィールドでは、デフォルト値をそのまま使用します。特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。
-
- タスク12 ノード・マネージャの構成
-
ノード・マネージャ・タイプとして「ドメインごとのデフォルトの場所」を選択し、ノード・マネージャへの接続に使用するノード・マネージャ資格証明を指定します。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のノード・マネージャに関する項を参照してください。
ドメインごとおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。
詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。
- タスク13 管理対象サーバーの構成
-
静的な管理対象サーバー値は構成しないでください。すべてのサーバーは動的に割り当てられます。
「次」をクリックします。
- タスク14 クラスタの構成
-
「クラスタ」画面を使用して、新しいクラスタを作成します。
-
「追加」ボタンをクリックします。
-
「クラスタ名」フィールドで、
WSM-PM_Cluster
を指定します。 -
「動的サーバー・グループ」ドロップダウン・リストで、
WSMPM-DYN-CLUSTER
を選択します。 -
「次」をクリックします。
ヒント:
この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。
-
- タスク15 サーバー・テンプレートの割当て
-
「サーバー・テンプレート」画面を使用して、テンプレートを構成します。
-
「名前」フィールドで
wsmpm-server-template
が選択されていることを確認します。 -
「リスニング・ポート」フィールドで、
7009
を指定します。 -
「SSLの有効化」オプションは未選択のままにしておきます。
-
「次」をクリックします。
-
- タスク16 動的サーバーの構成
-
「動的クラスタ」画面を使用して、必要なクラスタを構成します。
-
「クラスタ名」フィールドに
WSM-PM_Cluster
がリストされていることを確認します。 -
「サーバー名の接頭辞」フィールドで、
WLS_WSM
を指定します。 -
「サーバー・テンプレート」ドロップダウン・リストで、
「wsmpm-server-template」
を選択します。 -
「動的クラスタ・サイズ」フィールドに
2
を指定します。 -
「マシン名マッチング式」フィールドで、
「WCCHOST*」
と指定し、「計算済マシン名」を選択します。注意:
動的クラスタの「計算済マシン名」および「マシン名マッチング式」属性は、動的クラスタ内のサーバー・インスタンスをマシンに割り当てる方法を制御します。「計算済マシン名」属性がFalseに設定されている場合、動的サーバーはマシンに割り当てられません。「計算済マシン名」属性がTrueに設定されている場合、「マシン名マッチング式」属性が使用され、動的サーバーに使用されるマシンのセットが選択されます。「マシン名マッチング式」属性が設定されていない場合、ドメイン内のすべてのマシンが選択されます。割当は、ラウンド・ロビン・アルゴリズムを使用して行われます。
作業を簡単にするために、タスク18「マシンの作成」で説明しているように、実際の物理的なホスト名とは関係なく、WebLogicマシン名として
WCCHOSTn
を使用することをお薦めします。このnは連番です。この規則により、動的クラスタが各クラスタ・メンバーをどこから起動するかを決定しやすくなります。この規則に従う場合、「マシン・マッチング式」フィールドでWCCHOST*
を入力します。この規則に従わない場合、クラスタ・メンバーはタスク18「マシンの作成」で定義する各マシンで起動します。これには、ADMINHOSTも含まれます。この状況は、2つのクラスタ・メンバーが同じ物理サーバー上で動作するが2つの異なるドメイン・ホームにアタッチされる結果となるため、望ましくありません。
-
計算済リスニング・ポートフィールドおよび「動的クラスタ」フィールドを選択します。
注意:
「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、自動的に作成される動的管理対象サーバーごとに増分ポート番号が使用されます。つまり、動的サーバー1にはリスニング・ポート+1、動的サーバー2にはリスニング・ポート+2が使用されます。
構成されたリスニング・ポートは7009で、計算済のポートが選択されているので、WSMPM動的サーバーは次のポートを使用します。
-
WLS_WSM1サーバーは、ポート7010でリスニングします
-
WLS_WSM2サーバーは、ポート7011でリスニングします
-
-
「次」をクリックします。
注意:
構成ウィザードで、動的サーバーに対して特定のリスニング・アドレスを指定することはできません。動的クラスタのメンバーであるWebLogicサーバーへの特定リスニング・アドレスの設定については、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。
-
- タスク17 Coherenceクラスタの構成
-
「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。
「クラスタ・リスニング・ポート」に
9991
と入力します。注意:
Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。
- タスク18 マシンの作成
-
「マシン」画面を使用して、ドメイン内に新規マシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。
-
「Unixマシン」タブを選択します。
-
「追加」ボタンをクリックし、新しいUNIXマシンを作成します。
表10-2の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。
-
「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。
この例に示されているポート番号
5556
は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。
表10-3 Unixマシンの作成時に使用する値
名前 ノード・マネージャのリスニング・アドレス ノード・マネージャのリスニング・ポート ADMINHOST
ADMINVHN変数の値を入力します。
5556
WCCHOST1
WCCHOST1ホスト名変数またはWCCHOST1別名の値。たとえば、
WCCHOST1.example.com
などです。5556
WCCHOST2
WCCHOST2ホスト名変数またはWCCHOST2別名の値。たとえば、
WCCHOST2.example.com
などです。5556
WCPHOST1
WCPHOST1ホスト名変数の値。たとえば、
WCPHOST1.example.com
となります。5556
WCPHOST2
WCPHOST2ホスト名変数の値。たとえば、
WCPHOST2.example.com
となります。5556
注意:
マシンの名前は、「マシン・マッチング式」フィールドで指定した値に連番が付いた名前になります。つまり、「マシン・マッチング式」フィールドに
WCCHOST*
を指定しておくと、マシンの名前はWCCHOST1、WCCHOST2のようになります。ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンに関する項を参照してください。
-
- タスク19 マシンへのサーバーの割当て
-
「サーバーのマシンへの割当」画面を使用して、静的に定義された管理対象を適切なマシンに割り当てます。動的クラスタの一部であるサーバーは、計算済マシン名に自動的に割り当てられます。
AdminServerをADMINHOSTマシンに割り当てます。
- タスク20 仮想ターゲットの作成
-
「次」をクリックします。
- タスク21 パーティションの作成
-
「次」をクリックします。
- タスク22 構成の仕様の確認とドメインの構成
-
「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。
変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで、任意の画面に戻れます。
「作成」をクリックすると、ドメインの作成が開始されます。
終了したら、「構成の進行状況」画面で「次へ」をクリックします。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。
- タスク23 ドメイン・ホームと管理サーバーURLのメモ
-
「構成に成功しました」画面には、構成したドメインに関する次の項目が表示されます。
-
ドメインの場所
-
管理サーバーURL
どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。
「終了」をクリックして、構成ウィザードを閉じます。
-
WCCHOST1でのドメイン・ディレクトリの構成とサーバーの起動
ドメインを作成してノード・マネージャを構成したら、WCCHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。
- WCCHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動
ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動するには、次のステップを使用します。 - boot.propertiesファイルの作成
管理サーバー資格証明を要求されずに管理サーバーを起動したい場合は、boot.properties
を作成する必要があります。このステップは、エンタープライズ・デプロイメントでは必須です。管理サーバーを起動すると、このファイルに入力した資格証明が暗号化されます。 - ノード・マネージャを使用した管理サーバーの起動
ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。 - 管理サーバーの検証
構成ステップに進む前に、管理サーバーが正常に起動していることを検証するために、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認します。 - WCCHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成
エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。次は、WCCHOST1とWCCHOST2の両方のローカル記憶域に、このドメインのコピーを作成できます。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。 - WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動
- WCCHOST1でのWLS_WSM1管理対象サーバーの起動と検証
ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してWCCHOST1でWLS_WSM1管理対象サーバーを起動できます。
WCCHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動
これらのステップを使用して、ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動します。
boot.propertiesファイルの作成
管理サーバー資格証明を要求されずに管理サーバーを起動したい場合は、boot.properties
を作成する必要があります。このステップは、エンタープライズ・デプロイメントでは必須です。管理サーバーを起動すると、このファイルに入力した資格証明が暗号化されます。
管理サーバーのboot.properties
ファイルを作成する手順は次のとおりです。
ノード・マネージャを使用した管理サーバーの起動
ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。
ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。
管理サーバーの検証
構成ステップに進む前に、管理サーバーが正常に起動していることを検証するために、管理サーバーにインストールおよび構成されている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
WCCHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成
エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。次は、WCCHOST1とWCCHOST2の両方のローカル記憶域に、このドメインのコピーを作成できます。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。
サーバーが共有記憶域にログを書き込むことによって発生する潜在的な競合とオーバーヘッドを排除するために、MSERVER_HOMEをローカル記憶域に配置することをお薦めします。また、必要なクラスおよびjarをドメイン・ディレクトリからロードするほうが高速であるため、管理対象サーバーがドメイン・ディレクトリから使用する一時データまたはキャッシュ・データのほうがより迅速に処理されます。
「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のように、管理サーバー・ドメイン・ホームのパスはASERVER_HOME変数によって表され、管理対象サーバー・ドメイン・ホームのパスはMSERVER_HOME変数によって表されます。
管理対象サーバーのドメイン・ディレクトリを作成する手順は次のとおりです。
WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動
管理対象サーバーのドメイン・ディレクトリを作成した後は、2つのドメイン・ホーム・ディレクトリと、それに対応する2つの対応するノード・マネージャ・インスタンスがWCCHOST1上に存在します。1つのノード・マネージャは、管理サーバー・ドメイン・ホームから実行される管理サーバーの制御に使用します。もう1つのノード・マネージャは、管理対象サーバー・ドメイン・ホームから実行される管理対象サーバーの制御に使用します。
2つのノード・マネージャを別々に起動する必要があります。
注意:
管理対象サーバーのMSERVER_HOMEのノード・マネージャは、ドメイン構成が解凍されるたびにリセットされます。ListenAddress
は、正しいホスト名ではなくADMINVHNに変更されます。解凍の実行後、ノード・マネージャ・サービスを開始する前にこの値を正しい値に変更する必要があります。
次のステップに従って、管理対象サーバー・ホームからノード・マネージャを更新および起動します。
追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。
WCCHOST2でのドメインの伝播とサーバーの起動
WCCHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、WCCHOST2で次のタスクを実行できます。
WCCHOST2でのドメイン構成の解凍
WCCHOST1で管理サーバーと1つ目のWLS_WSM1管理対象サーバーを実行したので、WCCHOST2でドメインを構成できます。
親トピック: WCCHOST2でのドメインの伝播とサーバーの起動
WCCHOST2の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動
ドメイン構成をMSERVER_HOMEに解凍すると、WCCHOST2には、ドメイン・ホーム・ディレクトリ構造と、ドメイン構成の対応するマシンに割り当てられた管理対象サーバーを制御するためのノード・マネージャが存在します。
次のステップに従って、管理対象サーバー・ホームからノード・マネージャを更新および起動します。
追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。
親トピック: WCCHOST2でのドメインの伝播とサーバーの起動
WCCHOST2でのWLS_WSM2管理対象サーバーの起動と検証
「WCCHOST1でのWLS_WSM1管理対象サーバーの起動と検証」の手順を使用して、WCCHOST2上のWLS_WSM2管理対象サーバーを起動して検証します。
親トピック: WCCHOST2でのドメインの伝播とサーバーの起動
エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。
このステップは、リモート・デプロイメントの実行時の潜在的な問題の回避と、ステージ・モードが必要なデプロイメントのために必要です。
デプロイメント・ステージおよびアップロードの場所のディレクトリ・パスを更新するには、次のステップを実行します。
-
Oracle WebLogic Server管理コンソールにログインします。
-
左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。
-
「ロックして編集」をクリックします。
-
使用するクラスタ・タイプに適したオブジェクトに移動して編集します。
-
静的クラスタの場合は「サーバー」にナビゲートし、編集する管理対象サーバーの名前をクリックします。
-
動的クラスタの場合、「クラスタ」→「サーバー・テンプレート」に移動し、編集するサーバー・テンプレートの名前をクリックします。
-
-
編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。
-
「構成」タブをクリックし、「デプロイメント」タブをクリックします。
-
「ステージング・ディレクトリ名」が次のように設定されていることを確認します。
MSERVER_HOME/servers/server_or_template_name/stage
MSERVER_HOME
をMSERVER_HOME
ディレクトリのフルパスに置き換えます。静的クラスタを使用する場合、編集対象の管理対象サーバーの正しい名前を使用して更新します。
動的クラスタを使用する場合、テンプレート名はそのままにしておきます。例:
/u02/oracle/config/domains/
wcpedg_domain
/servers/XYZ-server-template/stage -
「アップロード・ディレクトリ名」を次の値に更新します。
ASERVER_HOME/servers/AdminServer/upload
ASERVER_HOME
をASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。 -
「保存」をクリックします。
-
「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。
-
-
新しい管理対象サーバーまたは動的クラスタ・サーバー・テンプレートごとに前のステップを繰り返します。
-
AdminServerの「アップロード・ディレクトリ名」に移動して、その値を更新します。
-
「サーバー」に移動してAdminServerを選択します。
-
「構成」タブをクリックし、「デプロイメント」タブをクリックします。
-
「ステージング・ディレクトリ名」が次のような絶対パスに設定されていることを確認します。
ASERVER_HOME/servers/AdminServer/stage
-
「アップロード・ディレクトリ名」を次の絶対パスに更新します。
ASERVER_HOME/servers/AdminServer/upload
ASERVER_HOME
をASERVER_HOME
ディレクトリのディレクトリ・パスに置き換えます。 -
「保存」をクリックします。
-
-
該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。
注意:
これ以上のドメイン構成を直接続行する場合、この時点ではstageおよびuploadディレクトリの変更を有効にするための再起動は厳密には必要ありません。動的クラスタを使用する際のリスニング・アドレスの構成
動的クラスタにおける動的な管理対象サーバーのデフォルト構成では、使用可能なネットワーク・インタフェースすべてでリスニングするようになっています。ほとんどの場合、デフォルトの構成は望ましくありません。動的クラスタを使用する際に、リスニング・アドレスを特定のアドレスに限定するには、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。リスニング・アドレスを変更した後に前の項で指定したテスト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ユーザー・ストアを使用すると、複数のOracle WebLogic Serverドメインで使用するユーザーおよびグループをプロビジョニングできます。その結果、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。
Oracle Fusion Middlewareドメインの管理用にプロビジョニングするユーザーおよびグループにディレクトリ・ツリー内で一意の識別名(DN)を作成して割り当てる方法をお薦めします。
たとえば、Oracle WebCenter Portalエンタープライズ・デプロイメント・ドメインをインストールおよび構成する場合は、weblogic_wcp
というユーザーとWCPAdministrators
という管理グループを作成します。
ドメイン・コネクタ・ユーザーについて
LDAPディレクトリで個別のドメイン・コネクタ・ユーザー(たとえばwcpLDAP
)を作成することをお薦めします。このユーザーを使用して、ドメインがユーザー認証の目的でLDAPディレクトリに接続できます。このユーザーは管理ユーザー以外にすることをお薦めします。
標準的なOracle Identity and Access Managementデプロイメントでは、このユーザーはsystemids
コンテナで作成します。このコンテナは、通常ユーザーには表示されないシステム・ユーザーに使用されます。このユーザーをsystemids
コンテナに配置することで、Oracle Identity Governanceを所有する顧客がこのユーザーをリコンサイルしないようにします。
集中管理型LDAPディレクトリへのユーザーの追加について
集中LDAPディレクトリをエンタープライズ・ドメインのオーセンティケータとして構成した後は、すべての新規ユーザーをデフォルトのWebLogic Serverオーセンティケータではなく新しいオーセンティケータに追加する必要があります。
集中LDAPディレクトリに新規ユーザーを追加する際、WebLogic管理コンソールは使用できません。かわりに、ldapbrowserやJXplorerなどの適切なLDAP変更ツールを使用する必要があります。
Oracle WebCenter Portalの製品固有のロールとグループについて
Oracle Fusion Middleware製品ごとに、管理および監視のために事前定義された独自のロールおよびグループが実装されます。
その結果、ドメインを拡張して他の製品を追加するときに、これらの製品固有のロールをWCPAdministrators
グループに追加できます。ロールがWCPAdministrators
グループに追加されると、各製品管理者ユーザーは管理タスクを実行するための同じ権限セットを使用してドメインを管理できます。
WCPAdministrators
グループに他のロールを追加する手順については、「エンタープライズ・デプロイメントの共通の構成および管理タスク」を参照してください。
このガイドで使用するサンプル・ユーザーとサンプル・グループ
このガイドで使用するサンプルでは、下に示すDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。
-
管理ユーザーDN:
cn=
weblogic_wcp
,cn=users,dc=example,dc=com -
管理グループDN:
cn=
WCPAdministrators
,cn=groups,dc=example,dc=com -
製品固有のLDAPコネクタ・ユーザー:
cn=
これは、WebLogic管理対象サーバーをLDAP認証プロバイダに接続するときに使用するユーザーです。このユーザーには、ディレクトリに対する読取り権限および書込み権限が必要です。wcpLDAP
,cn=systemids,dc=example,dc=comcn=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
認証プロバイダの仮想化の有効化
複数のオーセンティケータを使用している場合(エンタープライズ・デプロイメントの要件)、ログインや認証は実行できますが、ロール取得は実行できません。ロールは、最初のオーセンティケータからのみ取得できます。他のオーセンティケータを使用してロールを取得する場合は、ドメインの仮想化を有効にする必要があります。
仮想化を有効にする手順は次のとおりです。
-
管理者のアカウントを使用して、Fusion Middleware Controlにサインインします。たとえば、
weblogic
を使用します。http://adminvhn:7001/em
-
「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。
-
「セキュリティ・ストア・プロバイダ」を開きます。
-
「アイデンティティ・ストア・プロバイダ」を開きます。
-
「構成」をクリックします。
-
カスタム・プロパティを追加します。
-
プロパティvirtualizeを値trueで選択し、「OK」をクリックします。
-
もう一度「OK」をクリックすると、変更が確定します。
-
管理サーバーとすべての管理対象サーバーを再起動します。
仮想化プロパティの詳細は、Oracle Platform Security Servicesによるアプリケーションの保護のOPSSシステムおよび構成プロパティに関する項を参照してください。
LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング
この例では、集中管理型LDAPディレクトリにwcpLDAP
というユーザーを作成する方法を示します。
LDAPプロバイダでユーザーをプロビジョニングするには:
-
次に示す内容を指定して
domain_user.ldif
という名前のLDIFファイルを作成し、保存します。dn: cn=
wcpLDAP
,cn=systemids,dc=example,dc=com changetype: add orclsamaccountname:wcpLDAP
userpassword: password objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgperson objectclass: orcluser objectclass: orcluserV2 mail:wcpLDAP
@example.com givenname:wcpLDAP
sn:wcpLDAP
cn:wcpLDAP
uid:wcpLDAP
注意:
Oracle Unified Directoryを使用する場合、次の4つのグループ・メンバーシップをLDIFファイルの最後に追加して適切な読取り/書込み権限を付与します。
dn: cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=example,dc=com changetype: modify add: uniquemember uniquemember: cn=
wcpLDAP
,cn=systemids,dc=example,dc=com dn: cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com changetype: modify add: uniquemember uniquemember: cn=wcpLDAP
,cn=systemids,dc=example,dc=com dn: cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=com changetype: modify add: uniquemember uniquemember: cn=wcpLDAP
,cn=systemids,dc=example,dc=com dn: cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com changetype: modify add: uniquemember uniquemember: cn=wcpLDAP
,cn=systemids,dc=example,dc=com -
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ベースの認証プロバイダを構成する手順は次のとおりです。
-
WebLogic Server管理コンソールにログインします。
-
左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。
-
myrealmというデフォルト・レルム・エントリをクリックします。
-
「プロバイダ」タブをクリックします。
このレルムに対して
DefaultAuthenticator
というプロバイダが構成されていることに注目してください。これは、デフォルトのWebLogic Server認証プロバイダです。 -
「チェンジ・センター」で「ロックして編集」をクリックします。
-
「認証プロバイダ」表の下の「新規」ボタンをクリックします。
-
プロバイダの名前を入力します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかの名前を使用します。
-
OUDAuthenticator
(Oracle Unified Directoryの場合) -
OIDAuthenticator
(Oracle Internet Directoryの場合) -
OVDAuthenticator
(Oracle Virtual Directoryの場合)
-
-
「タイプ」ドロップダウン・リストでオーセンティケータ・タイプを選択します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかのタイプを選択します。
-
OracleUnifiedDirectoryAuthenticator
(Oracle Unified Directoryの場合) -
OracleInternetDirectoryAuthenticator
(Oracle Internet Directoryの場合) -
OracleVirtualDirectoryAuthenticator
(Oracle Virtual Directoryの場合)
-
-
「OK」をクリックして「プロバイダ」画面に戻ります。
-
「プロバイダ」画面の表で、新しく作成したオーセンティケータをクリックします。
-
「制御フラグ」ドロップダウン・メニューで「SUFFICIENT」を選択します。
制御フラグをSUFFICIENTに設定すると、そのオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。
認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。以降のすべてのオーセンティケータの制御フラグもSUFFICIENTに設定されていることを確認してください。特に
DefaultAuthenticator
をチェックして、その制御フラグがSUFFICIENTに設定されていることを確認します。 -
「保存」をクリックして、制御フラグ設定の変更を確定します。
-
「プロバイダ固有」タブをクリックし、次の表に示すように、使用するLDAPサーバーに固有の詳細を入力します。
この手順では、必須フィールドのみを説明しています。このページのすべてのフィールドの詳細は、次のリソースを参照してください。
-
各フィールドの説明を表示するには、「プロバイダ固有」タブの「ヘルプ」をクリックします。
-
「ユーザー・ベースDN」、「名前指定によるユーザー・フィルタ」、「ユーザー属性」の各フィールドの設定に関する詳細は、『Oracle WebLogic Serverセキュリティの管理』のOracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成に関する項を参照してください。
パラメータ サンプル値 値の説明 ホスト
例:
idstore.example.com
LDAPサーバーのサーバーID。
ポート
例:
1389
LDAPサーバーのポート番号。
プリンシパル
例:
cn=
wcpLDAP
, cn=systemids,dc=example,dc=comLDAPサーバーへの接続に使用される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を使用している場合はこの値を入力します。 -
-
「保存」をクリックして変更を保存します。
-
右のナビゲーション・ペインで「セキュリティ・レルム」をクリックして、デフォルトのレルム名(myrealm)をクリックし、「プロバイダ」をクリックして「プロバイダ」ページに戻ります。
-
「並替え」をクリックし、表示されたページを使用して、作成したプロバイダを認証プロバイダのリストの先頭に配置します。
-
「OK」をクリックします。
-
「プロバイダ」ページで、DefaultAuthenticatorをクリックします。
-
「制御フラグ」ドロップダウンから、SUFFICIENTを選択します。
-
「保存」をクリックしてDefaultAuthenticatorの設定を更新します。
-
チェンジ・センターで、変更のアクティブ化をクリックします。
-
すべての管理対象サーバーと管理サーバーを再起動します。
- 管理対象サーバーを停止する手順は次のとおりです。
-
Fusion Middleware Controlにサインインします。
-
サーバーの表で、管理対象サーバーの複数の行を選択します。[Shift]キーを押すと行の範囲を選択できます。
-
ツールバーの「制御」をクリックし、ポップアップ・メニューから「停止」>「ただちに強制停止」を選択します。
-
ポップアップ・ダイアログで「サーバーの強制停止」をクリックして即時停止を確認します。
-
サーバーが停止状態を示すまでドメイン・ビューをリフレッシュします。
-
- ノード・マネージャを使用して管理サーバーを停止および起動する手順は、次のとおりです。
-
WLSTを起動します。
cd ORACLE_COMMON_HOME/common/bin ./wlst.sh
-
構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。
wls:/offline>nmConnect('nodemanager_username','nodemanager_password', 'ADMINVHN','5556','domain_name', 'ASERVER_HOME')
-
管理サーバーを停止します。
nmKill('AdminServer')
-
管理サーバーを起動します。
nmStart('AdminServer')
-
WLSTを終了します。
exit()
-
- 管理サーバーを起動するには
-
Fusion Middleware Controlにサインインします。
-
サーバーの表で、管理対象サーバーの複数の行を選択します。[Shift]キーを押すと行の範囲を選択できます。
-
ツールバーの「制御」をクリックし、ポップアップ・メニューから「起動」を選択します。
-
サーバーが実行中状態を示すまでドメイン・ビューをリフレッシュします。
-
- 管理対象サーバーを停止する手順は次のとおりです。
-
再起動後に、次のログ・ファイルの内容を確認します。
ASERVER_HOME/servers/AdminServer/logs/AdminServer.log
LDAP接続エラーが発生していないことを確認します。たとえば、次のようなエラーを探します。
The LDAP authentication provider named "OUDAuthenticator" failed to make connection to ldap server at ...
ログ・ファイルでこのようなエラーが見つかった場合は、認可プロバイダ接続の詳細をチェックして、それらが適切であることを確認し、管理サーバーの保存と再起動をもう一度試みます。
-
再起動後、LDAP接続エラーがログ・ファイルに記述されていないことを確認し、LDAPプロバイダ内に存在するユーザーとグループの参照を試みます。
管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ユーザーとグループ」ページに移動します。LDAPプロバイダ構造内に存在するすべてのユーザーおよびグループを表示できるようになります。
エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング
この例では、weblogic_wcp
というユーザーとWCPAdministrators
というグループを作成する方法を示します。
LDAPプロバイダで管理ユーザーおよび管理グループをプロビジョニングする手順は次のとおりです。
-
次に示す内容を指定して
admin_user.ldif
という名前のLDIF
ファイルを作成し、保存します。dn: cn=
weblogic_wcp
,cn=users,dc=example,dc=com changetype: add orclsamaccountname:weblogic_wcp
userpassword: password objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgperson objectclass: orcluser objectclass: orcluserV2 mail:weblogic_wcp
@example.com givenname:weblogic_wcp
sn:weblogic_wcp
cn:weblogic_wcp
uid:weblogic_wcp
-
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
-
次に示す内容を指定して
admin_group.ldif
という名前のLDIF
ファイルを作成し、保存します。dn: cn=
WCPAdministrators
,cn=Groups,dc=example,dc=com changetype: add objectclass: top objectclass: groupOfUniqueNames objectclass: orclGroup uniquemember: cn=weblogic_wcp
,cn=users,dc=example,dc=com cn:WCPAdministrators
displayname:WCPAdministrators
description: Administrators Group for the Oracle WebCenter Portal Domain -
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
-
変更が正常に行われたことを確認します。
-
Oracle WebLogic Server管理コンソールにログインします。
-
コンソールの左ペインで「セキュリティ・レルム」をクリックします。
-
デフォルト・セキュリティ・レルム(myrealm)をクリックします。
-
「ユーザーとグループ」タブをクリックします。
-
プロビジョニングした管理者ユーザーおよびグループがページに表示されていることを確認します。
-
新しい管理グループへの管理ロールの追加
Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内でそのグループに管理ロールを割り当てる必要があります。これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。
管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てる手順は次のとおりです。
Administratorsグループへのwsm-pmロールの追加
新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(WCPAdministrators
)をメンバーとしてwsm-pm
アプリケーション・ストライプのpolicy.Updater
ロールに追加します。
WebLogicプロキシ・プラグインの構成
リクエストがOracle HTTP Serverインスタンスを介して正しくルーティングされることを検証するには、「WebLogicプラグインの有効化」
パラメータを設定しておく必要があります。「WebLogicプラグインの有効化」
パラメータはドメイン・レベルで設定することをお薦めします。Web層を介してプラグインを使用しないクラスタまたはサーバーがある場合は、必要に応じて例外的に「WebLogicプラグインの有効化」
パラメータを「いいえ」
に設定できます。
- Oracle WebLogic Server管理コンソールにログインします。
- 「ドメイン構造」ペインで、最上位のドメイン・ノードをクリックします。
- 「チェンジ・センター」で「ロックして編集」をクリックします。
- 「Webアプリケーション」タブをクリックします。
- 「WebLogicプラグインの有効化」オプションを見つけて選択します。
- 「保存」をクリックします。
- 「チェンジ・センター」の「変更のアクティブ化」をクリックします。
- ドメイン全体を停止して再起動します。
構成のバックアップ
ベスト・プラクティスとして、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。ここまでのインストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。
バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。