この章では、エンタープライズ・デプロイメントの開始点として使用できる初期ドメインのインストールおよび構成方法について説明します。このガイドの後の章では、デプロイしようとしているエンタープライズ・トポロジを構成する各種製品およびコンポーネントを含めることで、この初期ドメインを拡張する方法について説明します。
この章には次の項が含まれます:
エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール
ドメイン・ディレクトリの構成とSOAHOST1上のサーバーの起動
ドメインの伝播とSOAHOST2上のサーバーの起動
新しいLDAPオーセンティケータの作成と新しいエンタープライズ・デプロイメント管理者ユーザーおよび管理者グループのプロビジョニング
この章のタスクを実行する際には、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」で定義されている次のディレクトリ変数を参照します。
ORACLE_HOME
ASERVER_HOME
MSERVER_HOME
APPLICATION_HOME
JAVA_HOME
さらに、第5.2.3項「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名を参照することになります。
ADMINVHN
SOAHOST1
SOAHOST2
DBHOST1
DBHOST2
Oracle RACデータベースのSCANアドレス(DB-SCAN.examle.com)
インフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。
エンタープライズ・デプロイメントの初期インフラストラクチャ・ドメインの作成には、Oracle Fusion Middleware Infrastructureディストリビューションを使用します。このディストリビューションには、Oracle WebLogic ServerソフトウェアとOracle JRFソフトウェアの両方が1つのディストリビューションとして含まれています。
Oracle JRFソフトウェアは、Oracle Web Services Manager、Oracle Application Development Framework (Oracle ADF)、Oracle Enterprise Manager Fusion Middleware Control、リポジトリ作成ユーティリティ(RCU)およびOracle Fusion Middleware製品のサポートに必要なその他のライブラリおよびテクノロジで構成されています。
このガイドの後のほうでは、エンタープライズ・デプロイメントに必要なOracle Fusion Middleware製品をサポートするために、そのドメインを拡張します。
詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middleware Infrastructureの理解に関する項を参照してください。
表10-1に、初期インフラストラクチャ・ドメインの主な特徴の一部を示します。これらの特徴を確認して理解することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。
これらの特徴の多くは、第2章で詳しく説明しています。
表10-1 初期インフラストラクチャ・ドメインの特徴
ドメインの特徴 | 詳細情報 |
---|---|
管理サーバーに別個の仮想IP (VIP)アドレスを使用。 |
第2.2.5.1項「管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成」 |
ドメイン内の管理サーバーと管理対象サーバーに別個のドメイン・ディレクトリを使用。 |
第2.2.5.1項「管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成」 |
Oracle Web Services Managerの専用クラスタを含む。 |
第2.2.5.2項「アプリケーション層でのOracle Web Services Managerの使用」 |
各ホスト上の管理サーバーと管理対象サーバーにドメインごとのノード・マネージャと別個のノード・マネージャ・プロセスを使用。 |
第2.2.5.4項「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」 |
別途インストールされたLDAPベースの認証プロバイダが必要。 |
第2.2.5.6項「OPSSおよび認証ストアと認可ストアへのリクエストの理解」 |
エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。
Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (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を次の場所にインストールします。
アプリケーション層の各ホスト・コンピュータからアクセスできる共有記憶域デバイス
Web層の各ホスト・コンピュータのローカル記憶域デバイス
DMZに配置されるWeb層ホスト・コンピュータは、アプリケーション層の共有記憶域に必ずしもアクセスできるとはかぎりません。
JDKソフトウェアの推奨場所の詳細は、第7.3項「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。
次の例では、JDK 1.7の最新バージョンをインストールする方法について説明します。
ディレクトリを、JDKアーカイブ・ファイルをダウンロードした場所に変更します。
アーカイブをJDKホーム・ディレクトリに解凍します。
$ cd download_dir
$ tar -xzvf jdk-7u55-linux-x64.tar.gz
ホスト・コンピュータでJavaを実行するためのJAVA_HOMEおよびPATH環境変数を定義します。
例:
$ export JAVA_HOME=download_dir/jdk1.7.0_55
$ export PATH=$JAVA_HOME/bin:$PATH
次のコマンドを実行して、適切なJava実行可能ファイルがそのパスにあり、環境変数が適切に設定されていることを確認します。
$ java -version $ java version "1.7.0_55" Java(TM) SE Runtime Environment (build 1.7.0_55-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
インストール・プログラムを起動するには、次の手順を実行します。
SOAHOST1にログインします。
インストール・プログラムをダウンロードしたディレクトリに移動します。
次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava
実行可能ファイルを実行し、インストール・プログラムを起動します。
JAVA_HOME/bin/java -d64 -jar distribution_file_name.jar
この例では、次のようになります。
JAVA_HOMEを、ご使用のシステムの環境変数または実際のJDKの場所に置き換えます。
distribution_file_nameを、ディストリビューションJARファイルの実際の名前に置き換えます。
ディストリビューションをOracle Technology Network (OTN)からダウンロードする場合、通常、JARファイルはダウンロード可能なZIPファイル内にパッケージされています。
初期Infrastructureドメインに必要なソフトウェアをインストールする場合は、インストールするディストリビューションはfmw_12.1.3.0.0_infrastructure.jarです。
各ディストリビューションの実際のファイル名の詳細は、第5.3項「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」を参照してください。
インストール・プログラムが表示されると、インストールを開始する準備が完了しています。各インストール・プログラム画面の詳細は、第10.3.3項を参照してください。
インストール・プログラムでは、表10-2に記載された順番で一連の画面が表示されます。
インストール画面に関して詳細な情報が必要な場合は、画面の名前をクリックしてください。
表10-2 Oracle Fusion Middleware Infrastructureのインストール画面
画面 | 説明 |
---|---|
インストール・インベントリの設定 |
UNIXオペレーティング・システムで、初めてOracle製品をこのホストにインストールする場合にこの画面が表示されます。中央インベントリを作成する場所を指定します。この画面で選択されたオペレーティング・システム・グループ名に対して、中央インベントリの場所への書込み権限が付与されていることを確認してください。 中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解に関する項を参照してください。 |
ようこそ |
これは、製品インストーラの開始画面です。 |
インストールの場所 |
この画面を使用して、Oracleホーム・ディレクトリの場所を指定します。 エンタープライズ・デプロイメントのためには、表7-2に示すORACLE_HOME変数の値を入力します。 |
インストール・タイプ |
この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。 このトポロジの場合は、「Fusion Middleware Infrastructure」を選択します。 注意: このドキュメントのトポロジには、サーバーの例は含まれていません。この例を本番環境にインストールしないことを強くお薦めします。 |
前提条件のチェック |
この画面で、システムが最小限の要件を満たしているかどうかが検証されます。 警告またはエラー・メッセージが表示される場合、Oracle Technology Network (OTN)のOracle Fusion Middlewareシステム要件と仕様を参照してください。 |
セキュリティ・アップデートの指定 |
Oracle Supportアカウントをお持ちの場合、この画面を使用して、セキュリティ更新を受け取る方法を指定します。 所有していなくてこの手順をスキップする場合、チェック・ボックスの選択を解除し、フォローアップのダイアログ・ボックスで選択を確認します。 |
インストール・サマリー |
この画面では、選択したインストール・オプションを検証します。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。レスポンス・ファイルは、後でサイレント・インストールに使用できます。 サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。 |
インストールの進行状況 |
この画面では、インストールの進行状況を参照できます。 |
インストール完了 |
インストールが完了すると、この画面が表示されます。画面上の情報を確認し、「終了」をクリックしてインストーラを終了します。 |
InfrastructureをSOAHOST1にインストールした後、WEBHOST1とWEBHOST2のローカル記憶域デバイスにもInfrastructureをインストールする必要があります。Web層のホスト・コンピュータは、DMZに配置され、アプリケーション層の共有記憶域デバイスに必ずしもアクセスできるとは限らないため、ソフトウェアをローカルにインストールする必要があります。
さらに、SOAHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、SOAHOST2にもInfrastructureをインストールする必要があります。詳細は、第7.2項「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。
トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、第10.3.2項と第10.3.3項の手順に従って、適切な記憶域デバイスにOracleホームを作成します。
インストールの内容は、インストール中に選択したオプションによって異なります。
Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、次のディレクトリとサブディレクトリが表示されます。
/u01/oracle/products/fmwnnnn/soa adr BC4J ccr communications configuration internal jlib modules owsm rcu sysman upgrade webcenter atgpf bin common config external jdk lib oracle.xdb_12.1.0.jar plugins rda ucs util webservices
インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。
Fusion Middleware Infrastructureドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに、次のスキーマをインストールする必要があります。
メタデータ・サービス(MDS)
監査サービス(IAU)
監査サービスへの追加(IAU_APPEND)
監査サービス・ビューア(IAU_VIEWER)
Oracle Platform Security Services (OPSS)
ユーザー・メッセージング・サービス(UMS)
WebLogicサービス(WLS)
Common Infrastructure Services (STB)
リポジトリ作成ユーティリティ(RCU)を使用して、スキーマを作成します。このユーティリティは各Oracle Fusion Middleware製品のOracleホームにインストールされています。RCUの詳細とスキーマを作成してデータベースに格納する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でスキーマ作成の準備に関する項を参照してください。
この項の手順に従って、必要なスキーマをインストールします。
動作保証されたデータベースを適切にインストールして構成し、そのデータベースを起動して稼働させておく必要があります。
詳細は、次のリソースを参照してください。
第10章。この章には、データベース・サービスの作成、ラージ・オブジェクト(LOB)でのSecureFilesの使用、およびエンタープライズ・デプロイメントにおいて重要なその他のトピックに関する情報が含まれています。
『Oracle Fusion Middlewareのインストールのプランニング』の動作保証されたデータベースのインストールおよび構成に関する項
リポジトリ作成ユーティリティ(RCU)を起動するには:
サポートされているJDKをインストールした場所を参照するようにJAVA_HOME環境変数を設定します。
詳細は、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。
SOAHOST1上の次のディレクトリに移動します。
ORACLE_HOME/oracle_common/bin
次のようにRCUを起動します。
./rcu
Oracle Fusion Middleware Infrastructureドメインにスキーマを作成するには、この項の手順に従います。
「次へ」をクリックします。
データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「リポジトリの作成」画面で「システム・ロードおよび製品ロードの同時実行」を選択します。このドキュメントの手順では、必要な権限があることを想定しています。
データベースでDBAアクティビティを実行するために必要な権限を持っていない場合は、この画面で「システム・ロードに対するスクリプトの準備」を選択します。これによってSQLスクリプトが生成され、これをデータベース管理者が利用できます。『リポジトリ作成ユーティリティによるスキーマの作成』でシステム・ロードと製品ロードの理解に関する項を参照してください。
ヒント: この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でリポジトリの作成に関する項を参照してください。 |
「データベース接続の詳細」画面に、データベースに接続するためのRCUに関するデータベース接続の詳細が表示されます。
「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。
「次へ」をクリックして続行し、データベースへの接続が成功したことを通知するダイアログ・ウィンドウで「OK」をクリックします。
ヒント: この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でデータベース接続の詳細に関する項を参照してください。 |
Oracle Fusion Middlewareスキーマの識別に使用するカスタム接頭辞を指定します。
カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。このガイドでは、FMW1213
という接頭辞を使用します。
ヒント: ここで入力したカスタム接頭辞を書き留めてください。これは後でドメインの作成時に必要になります。 |
「AS共通スキーマ」を選択します。
「AS共通スキーマ」を選択すると、このセクションのすべてのスキーマが自動的に選択されます。
Common Infrastructure Servicesと呼ばれるスキーマも自動的に作成されます。このスキーマはグレー表示されており、選択も選択解除もできません。このスキーマ(STBスキーマ)を使用すると、ドメインの構成中にRCUから情報を取得できます。詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。
ヒント: カスタム接頭辞の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でカスタム接頭辞の理解に関する項を参照してください。マルチドメイン環境のスキーマを構成する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でスキーマの作成計画に関する項を参照してください。 |
「次へ」をクリックして続行し、スキーマ作成の前提条件チェックが成功したことを通知するダイアログ・ウィンドウで「OK」をクリックします。
データベースでのスキーマ・パスワードの設定方法を指定した後、パスワードを指定して確認します。
ヒント: この画面で設定したパスワードを書き留めておく必要があります。これは後でドメインの作成時に必要になります。 |
残りのRCU画面を最後までナビゲートし、スキーマ作成を完了します。
このガイドでは、残りの画面のデフォルト設定を受け入れるか、RCUでのOracle Fusion Middlewareスキーマの作成方法および必要な表領域の使用方法をカスタマイズします。
RCUおよびその機能と概念については、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。
「完了サマリー」画面が表示されたら、「閉じる」をクリックしてRCUを終了します。
この項では、構成ウィザードを使用してWebLogicドメインを作成するための指示について説明します。ドメイン作成に使用できるその他の方法の詳細は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの作成、拡張および管理のためのその他のツールに関する項を参照してください。
この項では、次の項目について説明します。
ドメインの構成を開始するには、Oracle Fusion Middleware Oracleホームで次のコマンドを実行します。
ORACLE_HOME/oracle_common/common/bin/config.sh
トポロジにドメインを作成して構成するには、この項の手順に従います。
「構成タイプ」画面で、新規ドメインを作成を選択します。
「ドメインの場所」フィールドで、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。
ヒント: 構成ウィザードのこの画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。 |
「テンプレート」画面で「製品テンプレートを使用してドメインを作成(P)」が選択されていることを確認した後に、次のテンプレートを選択します。
Oracle Enterprise Manager - 12.1.3.0 [em]
このテンプレートを選択すると、次の依存性が自動的に選択されます。
Oracle JRF - 12.1.3.0 [oracle_common]
WebLogic Coherence Cluster Extension - 12.1.3.0 [wlserver]
Oracle WSM Policy Manager - 12.1.3.0 [oracle_common]
ヒント: この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。 |
「アプリケーションの場所」フィールドで、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。
ヒント: この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のアプリケーションの場所に関する項を参照してください。 |
「管理者アカウント」画面で、ドメインにおけるデフォルトのWebLogic管理者アカウントのユーザー名とパスワードを指定します。
この画面で指定したユーザー名およびパスワードを書き留めておいてください。これらの資格証明は後でドメインの管理サーバーを起動して接続する際に必要になります。
「ドメイン・モードおよびJDK」画面で次の操作を行います。
「本番(P)」を「ドメイン・モード」フィールドで選択します。
「JDK」フィールドで「Oracle Hotspot JDK」を選択します。
「本番モード」をこの画面で選択すると、環境で高度なセキュリティが実現され、アプリケーションのデプロイと管理サーバーの起動でユーザー名とパスワードが必要になります。
ヒント: 開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。本番モードで、起動IDファイルを作成して、管理サーバー起動時にユーザー名とパスワードを指定する必要性をバイパスできます。詳細は、第10.6.2項「boot.propertiesファイルの作成」を参照してください。 |
この画面のフィールドをアクティブ化するには、「RCUデータ」を選択します。
「RCUデータ」オプションによってデータベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に受け取るように構成ウィザードで指定できます。
注意: この画面で「手動構成」を選択する場合、「JDBCコンポーネント・スキーマ」画面で、スキーマのパラメータを手動で指定する必要があります。 |
「RCUデータ」を選択したら、次の表に示すフィールドに入力します。図10-1のサンプルの「データベース構成タイプ」画面の部分的なスクリーン・ショットを参照してください。
フィールド | 説明 |
---|---|
DBMS/サービス | 製品スキーマをインストールするOracle RACデータベースのサービス名を入力します。例:
orcl.example.com 必ずOracle RACデータベース内のすべてのインスタンスの識別に使用される共通サービス名を指定してください。ホスト固有のサービス名は使用しないでください。 |
ホスト名 | Enterprise Deployment Workbookに入力したOracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。 |
ポート | データベースがリスニングしているポート番号を入力します。たとえば、1521 です。 |
スキーマ所有者
スキーマ・パスワード |
データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。
これはRCUの「スキーマ・パスワード」画面でサービス表コンポーネントに指定されたスキーマ(第10.4項「データベース・スキーマの作成」を参照)のユーザー名およびパスワードです。 デフォルトのユーザー名は |
データベース接続情報の指定が完了したら、「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ドメインの作成』のデータソース・デフォルトに関する項を参照してください。 |
「JDBCコンポーネント・スキーマ」画面の値が、すべてのスキーマについて適切であることを確認し、「次へ」をクリックします。
前の画面でRCUデータの取得を選択しているため、スキーマ表は移入済のはずです。その結果、構成ウィザードはこのドメインに必要なすべてのスキーマのデータベース接続値を見つけることができました。
この時点では、これらの値は単一インスタンスのデータベースに接続するように構成されています。ただし、エンタープライズ・デプロイメントの場合、第9章「エンタープライズ・デプロイメント用のデータベースの準備」の説明のように、可用性の高いReal Application Clusters (RAC)データベースを使用する必要があります。
さらに、各コンポーネント・スキーマでアクティブなGridLinkデータ・ソースを使用することをお薦めします。GridLinkデータ・ソースを使用してRACデータベースに接続する利点の詳細は、高可用性ガイドのデータベースの考慮事項に関する項を参照してください。
データ・ソースをGridLinkに変換する手順は次のとおりです。
スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。
「GridLinkへ変換」をクリックし、「次へ」をクリックします。
「GridLink Oracle RACコンポーネント・スキーマ」画面で、表10-3と図10-2に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。
表10-3 「GridLink Oracle RACコンポーネント・スキーマ」画面で選択したフィールドの推奨値
要素 | 説明と推奨値 |
---|---|
サービス名 |
データベースのサービス名を入力します( |
「サービス・リスナー」、「ポート」、および「プロトコル」 |
「サービス・リスナー」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。 「ポート」フィールドには、データベースのリスニング・ポートを入力します( 「プロトコル」フィールドには、 |
「ONSホスト」と「ポート」 |
「ONSポート」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。 「ポート」フィールドには、ONSリモート・ポートを入力します(通常は |
FANの有効化 |
「FANの有効化」チェック・ボックスを選択して、FANイベントを受信および処理できるようにします。 |
図10-2 「GridLink Oracle RACコンポーネント・スキーマ」画面のサンプル値
この画面で情報を指定する方法の詳細および適切なSCANアドレスの特定方法については、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。
また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。
「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。
「ステータス」列の緑色のチェック・マークは、テスト結果が正常であったことを示します。何か問題があった場合は、画面の「接続結果ログ」セクションのエラー・メッセージを確認して問題を修正した後、接続を再度テストします。
ヒント: この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテストに関する項を参照してください。 |
トポロジのドメイン構成を完了するには、「拡張構成」画面で次のオプションを選択する必要があります。
管理サーバー
管理サーバーのリスニング・アドレスを適切に構成するためにこれが必要です。
ノード・マネージャ
これは、ノード・マネージャの構成で必要です。
管理対象サーバー、クラスタおよびCoherence
これは、管理対象サーバーとクラスタの構成で必要ですが、マシンを構成して管理対象サーバーをマシンにターゲット指定するためにも必要です。
JMSファイル・ストア
これは、JMS永続ストア用に適切な共有記憶域を構成するために必要です。
注意: 構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。
|
「管理サーバー」画面で、次の手順を実行します。
「サーバー名」フィールドで、デフォルト値(「AdminServer」)を維持します。
「リスニング・アドレス」フィールドに、第5章で取得し、第8章で有効化したADMINVHNのVIPに対応する仮想ホスト名を入力します。
ADMINVHN仮想ホストを使用する理由の詳細は、第5.2項「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。
他のフィールドでは、デフォルト値をそのまま使用します。
特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。
ノード・マネージャ・タイプとして「ドメインごとのデフォルトの場所」を選択し、ノード・マネージャへの接続に使用するノード・マネージャ資格証明を指定します。
ヒント: この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のノード・マネージャに関する項を参照してください。ノード・マネージャのタイプの詳細は、Oracle WebLogic Serverのノード・マネージャの管理でノード・マネージャの概要に関する項を参照してください。 |
「管理対象サーバー」画面で、2台の管理対象サーバーを新規作成します。
「追加」ボタンをクリックして、1台の管理対象サーバーを新規作成します。
「サーバー名」列でWLS_WSM1
を指定します。
「リスニング・アドレス」列にSOAHOST1を入力します。
SOAHOST1に対応するホスト名を必ず入力して、IPアドレスは使用しないでください。
「リスニング・ポート」列に7010
と入力します。
「サーバー・グループ」ドロップダウン・リストで、JRF-MAN-SVR、WSM-CACHE-SVR、およびWSMPM-MAN-SVRを選択します。(図10-3を参照。)
これらのサーバー・グループによって、Oracle JRFとOracle Web Services Manager (OWSM)のサービスが、作成中の管理対象サーバーにターゲット設定されます。
サーバー・グループは、定義されたアプリケーション・サービスのグループをそれぞれに定義されたサーバー・グループにマッピングすることで、Fusion Middlewareアプリケーションおよびサービスを1つ以上のサーバーにターゲット設定します。特定のサーバー・グループにマップされたアプリケーション・サービスは、そのグループに割り当てられたすべてのサーバーに自動的にターゲット設定されます。詳細は、『ドメイン・テンプレート・リファレンス』のアプリケーション・サービス・グループ、サーバー・グループおよびアプリケーション・サービス・マッピングに関する項を参照してください。
WSM-CACHE-SVRサーバー・グループに関する注意: Oracle Web ServicesのNonceキャッシュは、WSM-CACHE-SVRサーバー・グループによって自動的に構成され、ほとんどのアプリケーションに適しています。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。Nonceキャッシュは、追加されたWebサービス・アプリケーションを実行中の管理対象サーバーの数によって必然的に拡大します。拡張キャッシュ構成については、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOracle CoherenceによるNonceのキャッシュに関する項を参照してください。この項では、NonceキャッシュとWSM-CACHE-SVRサーバー・グループの使用に関する追加のガイダンスを提供します。 |
このプロセスを繰り返して、WLS_WSM2
という名前の2つ目の管理対象サーバーを作成します。
「リスニング・アドレス」にSOAHOST2を入力します。「リスニング・ポート」に7010と入力します。最初の管理対象サーバーに適用したものと同じサーバー・グループをWLS_WSM2に適用します。
この手順で推奨する管理対象サーバー名(WLS_WSM1およびWLS_WSM2)はこのドキュメント全体で参照します。別の名前を選択した場合は、必要に応じてそれらの名前に置き換えてください。
図10-3 エンタープライズ・デプロイメント用に管理対象サーバーを定義するための構成ウィザードの使用
ヒント: この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。 |
「クラスタ」画面を使用して新規クラスタを作成します。
「追加」ボタンをクリックします。
「クラスタ名」フィールドで、WSM-PM_Cluster
を指定します。
他のフィールドは空のままにします。
ヒント: この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。 |
「サーバーのクラスタへの割当」画面を使用して、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ドメインの作成』のクラスタへのサーバーの割当に関する項を参照してください。 |
「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。
「ユニキャスト・リスニング・ポート」に9991
と入力します。
Coherenceに関する注意: インフラストラクチャ・ドメインでのCoherenceの構成方法およびCoherence構成の変更方法の詳細は、第2.2.5.7項「標準的なエンタープライズ・デプロイメントでのCoherenceクラスタについて」を参照してください。Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報』のOracle Coherenceに関する項を参照してください。 |
「マシン」画面を使用して、ドメイン内に3つの新規マシンを作成します。ノード・マネージャでサーバーの起動と停止ができるようするために、マシンが必要です。
「Unixマシン」タブを選択します。
「追加」ボタンをクリックし、3つの新しいUnixマシンを作成します。
表10-4の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。図10-4は、各マシンの値の例が入力された「マシン」画面の一部を示しています。
「ノード・マネージャ・リスニング・ポート」フィールドのポートを確認します。
ポート番号の5556
がこの例で示されていますが、ドキュメントにあるその他の例で参照される場合があります。必要に応じて、このポート番号をご使用の独自ポート番号で置換します。
表10-4 Unixマシンの作成時に使用する値
名前 | ノード・マネージャのリスニング・アドレス | ノード・マネージャ・リスニング・ポート |
---|---|---|
SOAHOST1 |
SOAHOST1ホスト名変数の値。たとえば、 |
5556 |
SOAHOST2 |
SOAHOST2ホスト名変数の値。たとえば、 |
5556 |
ADMINHOST |
ADMINVHN変数の値を入力します。 |
5556 |
ヒント: この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンに関する項を参照してください。 |
「サーバーのマシンへの割当」画面を使用して、管理サーバーと2つの管理対象サーバーを適切なマシンに割り当てます。
「サーバーのマシンへの割当」画面は、管理対象サーバーのクラスタへの割当て画面に似ています。「マシン」列でターゲット・マシンを選択し、左の列で管理対象サーバーを選択した後、右矢印をクリックしてそのサーバーを適切なマシンに割り当てます。
次のように、サーバーを割り当てます。
AdminServerをADMINHOSTマシンに割り当てます。
WLS-WSM1管理対象サーバーをSOAHOST1マシンに割り当てます。
WLS-WSM2管理対象サーバーをSOAHOST2マシンに割り当てます。
ヒント: この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンへのサーバーの割当に関する項を参照してください。 |
Oracle WSM Policy Manager構成テンプレートを使用してドメインを構成する場合、特にエンタープライズ・デプロイメントを構成しているときには、メタデータ・サービス(MDS)のJMSファイル・ストアの適切な場所を選択する必要があります。
「JMSファイル・ストア」画面の「ディレクトリ」列に次の場所を入力します。
ASERVER_HOME/WSM-PM_Cluster
第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOMEをASERVER_HOME変数の実際の値に置き換えます。
「構成サマリー」画面には、これから作成するドメインの構成情報の詳細が含まれています。画面上で各項目の詳細をチェックし、情報が正しいことを確認します。
変更を行う必要がある場合、「戻る」ボタンを使用するか、画面をナビゲーション・ペインで選択して、前の画面に戻ることができます。
ドメインの作成は、「作成」をクリックするまで開始されません。
ヒント: この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。 |
「構成に成功しました」画面に、構成したドメインに関する次の項目が表示されます。
ドメインの場所
管理サーバーURL
いずれの項目も後で必要になるため、メモしておいてください。ドメインの場所はノード・マネージャと管理サーバーを開始するために使用するスクリプトへのアクセスに必要で、URLは管理サーバーへのアクセスに必要です。
「終了」をクリックして構成ウィザードを閉じます。
ドメインを作成したら、SOAHOST1上で次のタスクを実行できます。
ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動する手順は次のとおりです。
次のディレクトリに進みます。
ASERVER_HOME/bin
次のコマンドを使用してノード・マネージャを起動します。
nohup ./startNodeManager.sh > nm.out&
ノード・マネージャのその他の構成オプションについては、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。
この項では、SOAHOST1での管理サーバー用のboot.properties
ファイルの作成方法について説明します。ノード・マネージャを使用して管理サーバーを起動するには、この手順を必ず実行する必要があります。
管理サーバーのboot.properties
ファイルを作成する手順は次のとおりです。
次のようなディレクトリ構造を作成します。
mkdir -p ASERVER_HOME/servers/AdminServer/security
テキスト・エディタで、前述の手順で作成したセキュリティ・ディレクトリにboot.properties
というファイルを作成し、構成ウィザードを実行してドメインを作成したときに定義した、次の管理サーバー資格証明を入力します。
username=adminuser password=password
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を短くします。ファイルを編集した後、できるかぎり速やかにサーバーを起動し、エントリを暗号化してください。 |
ファイルを保存してエディタを閉じます。
ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。
WLSTを起動します。
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。
wls:/offline>nmConnect('nodemanager_username','nodemanager_password', 'ADMINVHN','5556','domain_name', 'ASERVER_HOME')
注意: このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.properties ファイルに格納されます。
ASERVER_HOME/config/nodemanager
|
管理サーバーを起動します。
nmStart('AdminServer')
WLSTを終了します。
exit()
管理サーバーが正常に起動して実行されていることを検証するには、ブラウザ・ウィンドウを開いて、管理サーバーにインストールおよび構成されている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とSOAHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。サーバーが共有記憶域にログを書き込むことによって発生する潜在的な競合とオーバーヘッドを排除するために、MSERVER_HOMEをローカル記憶域に配置することをお薦めします。また、必要なクラスおよびjarをドメイン・ディレクトリからロードするほうが高速であるため、管理対象サーバーがドメイン・ディレクトリから使用するtmpまたはキャッシュのデータのほうがより迅速に処理されます。
第7章の説明のように、管理サーバー・ドメイン・ホームのパスはASERVER_HOME変数によって表され、管理対象サーバー・ドメイン・ホームのパスはMSERVER_HOME変数によって表されます。
管理対象サーバーのドメイン・ディレクトリを作成する手順は次のとおりです。
SOAHOST1にログインし、次のようにpack
コマンドを実行してテンプレートを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ASERVER_HOME -template=soadomaintemplate.jar -template_name=soa_domain_template
この例では、次のようになります。
ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。
soadomaintemplate.jar
は作成するJARファイルのサンプル名であり、これにはドメイン構成ファイルが含まれます。
soa_domain_template
は、ドメイン・テンプレート・ファイルに割り当てられる名前です。
packコマンドで作成したsoadomaintemplate.jar
ファイルの場所を書き留めます。
デフォルトでは、ドメイン・テンプレートは、packコマンドを実行した現在のディレクトリに作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template
引数の一部としてテンプレートJARファイルのフルパスを指定できます。
ORACLE_COMMON_HOME/common/bin/
ヒント: packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。 |
まだ作成していない場合は、SOAHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。
次のようにunpack
コマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=MSERVER_HOME -overwrite_domain=true -template=soadomaintemplate.jar -log_priority=DEBUG -log=/tmp/unpack.log -app_dir=APPLICATION_HOME
注意: unpackコマンドで-overwrite_domain オプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。
また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shというファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うよう構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。 |
この例では、次のようになります。
MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。
soadomaintemplate.jar
は、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。
ヒント: packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。 |
ディレクトリを、新しく作成した管理対象サーバー・ディレクトリに変更して、ドメイン構成ファイルがSOAHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。
管理対象サーバーのドメイン・ディレクトリを作成した後は、SOAHOST1に2つのドメイン・ホーム・ディレクトリが存在します。1つは管理サーバーで使用され、もう1つはSOAHOST1上の管理対象サーバーで使用されます。
同様に、SOAHOST1に2つのノード・マネージャが存在します。1つのノード・マネージャは、管理サーバー・ドメイン・ホームから実行される管理サーバーの制御およびモニターに使用されます。もう1つは、管理対象サーバー・ドメイン・ホームから実行される管理対象サーバーの制御に使用されます。
2つのノード・マネージャを別々に起動する必要があります。ただし、管理対象サーバー・ディレクトリのノード・マネージャを起動する前に、まず管理サーバー・ドメイン・ホームからコピーしたnodemanager.properties
ファイルを編集する必要があります。
unpack
コマンドは管理サーバー・ドメイン・ディレクトリからnodemanager.properties
ファイルとそのすべての値をコピーするため、この手順が必要となります。
その結果、管理対象サーバー・ディレクトリにあるnodemanager.properties
ファイルを一意のリスニング・アドレスを使用するよう編集する必要があります。このようにしないと、管理対象サーバーのノード・マネージャの起動はアドレスとポートの競合が原因となって失敗します。
次の手順に従ってnodemanager.properties
ファイルを編集し、管理対象サーバーのノード・マネージャを起動します。
次の場所でnodemanager.properties
ファイルを見つけて編集します。
MSERVER_HOME/nodemanager
nodemanager.properties
ファイルで次のエントリを見つけます。
ListenAddress=ADMINVHN
変更を行う前は、ListenAddress
プロパティの値がADMINVHN仮想IPアドレスの値になっています。この値は、タスク 11「管理サーバーのリスニング・アドレスの構成」で、構成ウィザードでノード・マネージャを構成したときに設定したものです。
ListenAddress
プロパティの値を次の値に変更します。
ListenAddress=SOAHOST1
これで、管理対象サーバー・ホームのノード・マネージャはSOAHOST1の物理IPアドレスをリスニングするようになりました。
ファイルを保存します。
管理対象サーバー・ホームからノード・マネージャを起動します。
次のディレクトリに進みます。
MSERVER_HOME/bin
次のコマンドを使用してノード・マネージャを起動します。
nohup ./startNodeManager.sh > nm.out&
追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。
Oracle Enterprise Manager Fusion Middleware Controlを使用してSOAHOST1上の管理対象サーバーを起動します。前述の手順でノード・マネージャと管理サーバーをすでに起動しているため、Fusion Middleware Controlは使用可能な状態です。
ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
http://ADMINVHN:7001/em
この例では、次のようになります。
ADMINVHNを、第5.3項「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。
ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。
ヒント: Oracle Enterprise Manager Fusion Middlewareを使用したOracle Fusion Middlewareの管理の詳細は、Oracle Fusion Middlewareの管理のOracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイドを参照してください。 |
管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
「ターゲット・ナビゲーション」ペインで、ドメインを開きます。ドメインの下で、WSM-PM_Clusterを開き、ドメイン内の管理対象サーバーを表示します。
WLS_WSM1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。
起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_WSM1管理対象サーバーが稼働中であることを確認します。
管理対象サーバーが正しく機能していることを検証するには、ブラウザを開き、次のURLを入力します。
SOAHOST1:7010/wsm-pm/
要求に従って、ドメイン管理ユーザー名とパスワードを入力します。
SOAHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、SOAHOST2で次のタスクを実行できます。
SOAHOST1で管理サーバーと最初のWLS_WSM1管理対象サーバーを実行した後、次のようにSOAHOST2でドメインを構成できます。
この手順では、以前に作成したsoadomaintemplate.jarファイルを、SOAHOST1とSOAHOST2の両方からアクセスできる場所(たとえば、共有記憶域ファイラ上のASERVER_HOMEディレクトリなど)にコピー済であることを想定しています。
SOAHOST2にログインします。
まだ作成していない場合は、SOAHOST2のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。
次のようにunpack
コマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=MSERVER_HOME -overwrite_domain=true -template=soadomaintemplate.jar -log_priority=DEBUG -log=/tmp/unpack.log -app_dir=APPLICATION_HOME
この例では、次のようになります。
MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。
soadomaintemplate.jar
は、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。
SOAHOST2に別の共有記憶域ボリュームまたはパーティション(および冗長Oracleホーム)を使用している場合は、SOAHOST2にマウントされているボリュームまたはパーティションに、まずテンプレートをコピーする必要があります。
APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、第7.4項「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。
ヒント: packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。 |
ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがSOAHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。
ドメイン構成をSOAHOST2に伝播したら、次のようにMSERVER_HOMEドメイン・ディレクトリのノード・マネージャを起動します。
ディレクトリを、SOAHOST2の次のディレクトリに変更します。
MSERVER_HOME/bin
次のコマンドを使用してノード・マネージャを起動します。
nohup ./startNodeManager.sh > nm.out&
ノード・マネージャのその他の構成オプションについては、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。
第10.6.7項「SOAHOST1でのWLS_WSM2管理対象サーバーの起動と検証」の手順を使用して、SOAHOST2上のWLS_WSM2管理対象サーバーを起動および検証します。
ドメインを作成し、管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、管理対象サーバーのupload
ディレクトリとstage
ディレクトリを検証および更新します。
この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。
管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。
「ロックして編集」をクリックします。
「サーバー」をクリックします。
管理対象サーバー・ドメイン・ホーム・ディレクトリ内の各管理対象サーバーについて次の操作を実行します。
管理対象サーバーの名前をクリックします。
「構成」タブをクリックし、「デプロイメント」タブをクリックします。
「ステージング・ディレクトリ名」が次のように設定されていることを確認します。
MSERVER_HOME/servers/server_name/stage
MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換え、server_nameを編集しているサーバーの名前に置き換えます。
「アップロード・ディレクトリ名」を次の値に更新します。
ASERVER_HOME/servers/AdminServer/upload
ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。
「保存」をクリックします。
「サーバーのサマリー」画面に戻ります。
各管理対象サーバーについてこれらの値を変更したら、「変更のアクティブ化」をクリックします。
WLS_WSM1管理対象サーバーとWLS_WSM2管理対象サーバーの両方を再起動します。
Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic認証プロバイダ(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
Oracle Virtual Directory
LibOVDを使用した複数のLDAPアイデンティティ・ストアのサポート: ここに示す手順では、デフォルトで単一のLDAPアイデンティティ・ストアに対する問合せをサポートするようにアイデンティティ・サービス・インスタンスを構成する方法を説明します。ただし、LibOVDを使用して、複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。 複数LDAP参照に関する詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・サービスの構成に関する項を参照してください。 |
次の各項では、エンタープライズ・デプロイメント管理者ユーザーおよび管理者グループの用途と特性に関する重要な情報を提供します。
集中LDAPユーザー・ストアを使用すると、複数のOracle WebLogic Serverドメインで使用するユーザーおよびグループをプロビジョニングできます。その結果、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。
このようなアプローチはお薦めしません。かわりに、Oracle Fusion Middlewareドメインの管理用にプロビジョニングするユーザーおよびグループにディレクトリ・ツリー内で一意の識別名(DN)を割り当てる方法をお薦めします。
たとえば、Oracle SOA Suiteエンタープライズ・デプロイメント・ドメインをインストールおよび構成する場合は、weblogic_soaというユーザーとSOA Administratorsという管理グループを作成します。
各Oracle SOA Suite製品(Oracle SOA Suite、Oracle Business Process Management、Oracle Business Activity Monitoring)は、管理および監視目的で事前に定義された独自のロールとグループを実装しています。
その結果、ドメインを拡張して他のOracle SOA Suite製品を追加するときに、これらの製品固有のロールをSOA Administratorsグループに割り当てることができます。ロールがSOA Administratorsグループに追加されると、各製品管理者ユーザーは管理タスクを実行するための同じ権限セットを使用してドメインを管理できます。たとえば、Oracle B2B Administrationの場合、B2BAdminロールをSOA Administratorsグループに追加できます。
SOA Administratorsグループに他のロールを追加する手順については、第18章「エンタープライズ・デプロイメントの共通の構成および管理タスク」を参照してください。各製品で追加する必要のあるロールは、各製品の構成に関する章に記述されています。
このガイドで使用するサンプルでは、下に示すDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。
管理ユーザーのDN:
cn=weblogic_soa,cn=Users,dc=us,dc=example,dc=com
管理グループのDN:
cn=SOA Administrators,cn=Groups,dc=us,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
ファイルをバックアップする必要があります。
DOMAIN_HOME/servers/AdminServer/security
新しいLDAPベースの認証プロバイダを構成する手順は次のとおりです。
WebLogic Serverコンソールにログインします。
左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。
myrealmというデフォルト・レルム・エントリをクリックします。
「プロバイダ」タブをクリックします。
このレルムに対してDefaultAuthenticator
というプロバイダが構成されていることに注目してください。これは、デフォルトのWebLogicプロバイダです。
「チェンジ・センター」で「ロックして編集」をクリックします。
認証プロバイダのリストの下の「新規」ボタンをクリックします。
プロバイダの名前を入力します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかの名前を使用します。
OUDAuthenticator
(Oracle Unified Directoryの場合)
OIDAuthenticator
(Oracle Internet Directoryの場合)
OVDAuthenticator
(Oracle Virtual Directoryの場合)
「タイプ」ドロップダウン・リストでオーセンティケータ・タイプを選択します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかのタイプを選択します。
IPlanetAuthenticator
(Oracle Unified Directoryの場合)
新しいOracle Unified Directory認証プロバイダを作成するときにIPlanetAuthenticatorを選択する必要があります。
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認証プロバイダでのユーザーおよびグループの構成に関する項を参照してください。
パラメータ | 値の例 | 値の説明 |
---|---|---|
ホスト | 例: oud.example.com |
LDAPサーバーのサーバーID。 |
ポート | 例: 1689 |
LDAPサーバーのポート番号。 |
プリンシパル | 例: cn =orcladmin |
LDAPサーバーへの接続に使用されるLDAPユーザーのDN。 |
資格証明 | LDAPパスワードを入力します。 | LDAPサーバーに接続するために使用されるパスワード。 |
SSLの有効化 | 未チェック(クリア) | LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。 |
ユーザー・ベースDN | 例: cn =users,dc=us,dc=example,dc=com |
ユーザーが開始時に使用するDNを指定します。 |
名前指定によるユーザー・フィルタ | 例:
cn=%u, objectclass=person |
LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がcn以外のタイプである場合は、「名前指定によるユーザー・フィルタ」の設定で、そのタイプを変更します。
たとえば、「ユーザー名属性」のタイプがuidである場合は、このフィールドを次のように設定する必要があります。
|
ユーザー名属性 | 例: cn |
グループの名前を指定するLDAPユーザー・オブジェクトの属性。 |
グループ・ベースDN | 例: cn =groups,dc=us,dc=example,dc=com |
グループ・ノードを指すDNを指定します。 |
取得したユーザー名をプリンシパルとして使用する | チェック・ボックスを選択 | オンにする必要があります。 |
GUID属性 | entryUUID | 認証プロバイダとしてOracle Unified Directoryを使用している場合はこの値を入力します。 |
「保存」をクリックして、変更を保存します。
右のナビゲーション・ペインで「セキュリティ・レルム」をクリックして、デフォルトのレルム名(myrealm)をクリックし、「プロバイダ」をクリックして「プロバイダ」ページに戻ります。
「並替え」をクリックし、表示されたページを使用して、作成したプロバイダを認証プロバイダのリストの先頭に配置します。
「OK」をクリックします。
「チェンジ・センター」で、「変更のアクティブ化」をクリックします。
管理サーバーとすべての管理対象サーバーを再起動します。
管理対象サーバーを停止するには、Fusion Middleware Controlにログインし、ターゲットのナビゲータで管理対象サーバーを選択して、ツールバーで「停止」をクリックします。
ノード・マネージャを使用して管理サーバーを停止および起動する手順は次のとおりです。
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にログインし、管理対象サーバーを選択して、ツールバーで「起動」をクリックします。
再起動後に、次のログ・ファイルの内容を確認します。
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_soaというユーザーとSOA Administratorsというグループを作成する方法を示します。
LDAPプロバイダで管理ユーザーおよび管理グループをプロビジョニングする手順は次のとおりです。
次に示す内容のadmin_user.ldif
という名前のldifファイルを作成して保存します。
dn: cn=weblogic_soa, cn=Users, dc=us, dc=example, dc=com orclsamaccountname: weblogic_soa givenname: weblogic_soa sn: weblogic_soa userpassword: password mail: weblogic_soa objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgperson objectclass: orcluser objectclass: orcluserV2 uid: weblogic_soa cn: weblogic_soa description: Admin User for the SOA Domain
LDAPディレクトリでユーザーをプロビジョニングします。
たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。
OUD_INSTANCE_HOME/bin/ldapmodify -a \ -D "cn=oudadmin" \ -w password \ -p 1389 \ -f admin_user.ldif
Oracle Internet Directoryの場合:
OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \ -p 389 \ -D cn="orcladmin" \ -w password \ -c \ -v \ -f admin_user.ldif
admin_group.ldif
という名前のldif
ファイルを作成して、次の内容を入力してからこのファイルを保存します。
dn: cn=SOA Administrators, cn=Groups, dc=us, dc=example, dc=com displayname: SOA Administrators objectclass: top objectclass: groupOfUniqueNames objectclass: orclGroup uniquemember: cn=weblogic_soa,cn=users,dc=us,dc=example,dc=com cn: SOA Administrators description: Administrators Group for the SOA Domain
LDAPディレクトリでグループをプロビジョニングします。
Oracle Unified Directoryの場合:
OUD_INSTANCE_HOME/bin/ldapmodify -a \ -D "cn=oudadmin" \ -w password \ -p 1389 \ -f admin_group.ldif
Oracle Internet Directoryの場合:
OID_ORACLE_HOME/bin/ldapadd -h oid.example.com
-p 389
-D cn="orcladmin"
-w <password>
-c
-v
-f admin_group.ldif
変更が正常に行われたことを確認します。
Oracle WebLogic Server管理コンソールにログインします。
コンソールの左ペインで「セキュリティ・レルム」をクリックします。
デフォルト・セキュリティ・レルム(myrealm)をクリックします。
「ユーザーとグループ」タブをクリックします。
プロビジョニングした管理ユーザーおよびグループがページに表示されていることを確認します。
Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内でそのグループに管理ロールを割り当てる必要があります。これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。
管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てる手順は次のとおりです。
構成ウィザードで指定した管理資格証明を使用してWebLogic管理サーバー・コンソールにログインします。
作成して新しい認証プロバイダに提供した管理ユーザーの資格証明は使用しないでください。
コンソールの左ペインで「セキュリティ・レルム」をクリックします。
デフォルト・セキュリティ・レルム(myrealm)をクリックします。
「ロールとポリシー」タブをクリックします。
表の「グローバル・ロール」エントリを開き、「ロール」をクリックします。
「管理」ロールをクリックします。
「条件の追加」ボタンをクリックします。
「述部リスト」ドロップダウン・メニューで「グループ」を選択し、「次へ」をクリックします。
「グループ引数名」フィールドにSOA Administrators
と入力して、「追加」をクリックします。
引数のリスト・ボックスにSOA Administrators
が追加されます。
「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。
SOA Administratorsグループが表示されています。
「保存」をクリックすると、SOA管理者グループに管理ロールを追加する処理が終了します。
新しいweblogic_soa
ユーザー資格証明を使用してWebLogic管理サーバー・コンソールにログインし、変更されていることを確認します。
新しい認証プロバイダでプロビジョニングした新しい管理ユーザーの資格証明を使用してOracle WebLogic Server管理コンソールとFusion Middleware Controlにログインできる場合は、プロバイダは正常に構成されています。
新しい管理ユーザーおよびグループを作成したら、LDAPディレクトリで作成した管理ユーザー資格証明を使用して管理サーバーのboot.properties
ファイルを更新する必要があります。
SOAHOST1で、次のディレクトリに移動します。
DOMAIN_HOME/servers/AdminServer/security
既存のboot.properties
ファイルの名前を変更します。
mv boot.properties boot.properties.backup
テキスト・エディタを使用して、セキュリティ・ディレクトリにboot.properties
というファイルを作成します。
次の行をこのファイルに入力します。
username=weblogic_soa
password=password
ファイルを保存します。
管理サーバーを再起動します。
新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動した後、Oracle Web Services Managerのwsm-pm
管理ロールがエンタープライズ・デプロイメント管理グループ(SOA Administrators
)のメンバーになるように新しいプロバイダを更新します。
このタスクを実行するには、第18.2.1項「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。