1. Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの構成
  3. エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

19 エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

この章で説明する手順では、エンタープライズ・デプロイメント・ドメインにOracle Managed File Transferを追加するプロセスを示します。

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

Oracle Managed File Transferについて

Oracle Managed File Transfer (MFT)は、標準ベースのファイル・ゲートウェイを提供します。転送の優先度付け、ファイルの暗号化、スケジューリング、埋込みFTPサーバーと埋込みsFTPサーバーなどの機能を備えたWebベースのデザインタイム・コンソールで、ファイル転送の設計、デプロイメントおよび監視を実行できます。

Oracle MFTの詳細は、『Oracle Managed File Transferの使用』のOracle Managed File Transferの理解に関する項を参照してください。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

エンタープライズ・デプロイメントでのManaged File Transferについて

Managed File Transferは、Oracle SOA Suite、Oracle Service Bus、Business Activity Monitoringなどの他のコンポーネントとは別に、独自のドメイン内で実行されます。通常、単一の構成ウィザード・セッションで、ドメインを作成してManaged File Transferの管理対象サーバーを構成します。

Managed File Transferは、Oracle Web Services Manager (OWSM)を使用して、Managed File Transferアプリケーションと同じサーバー上でOWSMサービスを実行します。

Web層を構成する場合、Managed File Transferでは、Managed File TransferのSFTPリクエストのTCP通信をロード・バランシングする、Oracle Traffic Directorが必要です。

図19-1に、Managed File Transferのデプロイメント・トポロジを示します。

ダイアグラムに示す標準的な要素の説明は、「標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解」を参照してください。

ダイアグラムに示す要素の説明は、「プライマリOracle SOA Suiteトポロジ・ダイアグラムの理解」を参照してください。

図19-1 Managed File Transferトポロジ

図19-1の説明が続きます
「図19-1 Managed File Transferトポロジ」の説明

Managed File Transferドメインは、他のFMWコンポーネントと同じホスト上に構成できます。このため、ホストごとのノード・マネージャ構成を使用することをお薦めします。この構成で、単一のノード・マネージャは、同じマシン上の異なるドメインを制御できます。「エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成」を参照してください。

親トピック: Oracle Managed File Transferについて

Managed File Transferドメインの特徴

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

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

ドメインの特徴 詳細情報

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

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

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

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

Managed File Transferと同じサーバーにデプロイされるOracle Web Services Managerを使用

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

Web層からSFTPリクエストをルーティングするためにOracle Traffic Directorが必要です。

エンタープライズ・デプロイメントでのOracle Traffic Directorについて

単一の構成ウィザード・セッションを使用して、Managed File Transfer管理対象サーバーでInfrastructureおよびManaged File Transferソフトウェアを構成。ドメインは、後でOracle Traffic Directorを含めるように拡張されます。

エンタープライズ・デプロイメント用のManaged File Transferドメインの作成

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

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

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

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

親トピック: Oracle Managed File Transferについて

Managed File Transferの構成時に使用される変数

Managed File Transfer参照をインストールして構成する手順では、環境内で使用される実際の値に置換できる一連の変数を使用します。

これらの手順では、次のディレクトリの場所の変数が使用されます。

  • WEB_ORACLE_HOME

  • ASERVER_HOME

  • MSERVER_HOME

  • WEB_DOMAIN_HOME

  • JAVA_HOME

  • NM_HOME

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

さらに、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で定義されている、次の仮想IP (VIP)アドレスを参照します。

  • ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

  • APPHOST1

  • APPHOST2

  • WEBHOST1

  • WEBHOST2

ノート:

この章では、APPHOST1とAPPHOST2は、アプリケーション層ホストのより汎用的な変数を示すことに注意してください。この理由は、作成されるドメインに応じて、ホスト名変数が異なるためです。

たとえば、Oracle SOA Suiteドメイン用にOracle Traffic Directorを構成する場合、APPHOST1はSOAHOST1と同じです。ただし、通常は独自のドメイン内に構成されるOracle Managed File Transferドメイン用にOracle Traffic Directorを構成する場合、APPHOST1はMFTHOST1と同じです。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

Managed File Transferでの動的クラスタのサポート

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

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

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

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

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

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

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

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

システム・クロックの同期

Oracle SOA Suiteを含むようにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。

ネットワーク・タイム・プロトコル(NTP)の使用をお薦めします。「NTP (時間)サーバーを使用するためのホストの構成」を参照してください。

時刻同期を確認するには、それぞれのホストでntpstatコマンドを実行してNTPサービスに問合せを実行します。

出力例:

$ ntpstat
synchronised to NTP server (10.132.0.121) at stratum 3
 time correct to within 42 ms
 polling server every 16 s

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

Managed File Transferドメインを作成するための前提条件

Managed File Transferドメインを作成する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

  • サポートされているJDKをインストールしたことを確認します。

  • Oracle Fusion Middleware Infrastructureソフトウェア・バイナリをインストールした既存のOracleホームが存在する必要があります。これは、Managed File Transferドメイン用の専用のOracleホームである必要があります。Oracleホームは、通常、共有記憶域上にあり、MFTHOST1およびMFTHOST2から使用できます。「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

    Infrastructureドメインを構成するのではなく、Oracle Fusion Middleware Infrastructureソフトウェアのインストールのみを行ってください。

    InfrastructureのOracleホームを作成するには、SOAHOST1におけるOracle Fusion Middleware Infrastructureのインストールを参照してください。

  • インストールをバックアップすること。既存のFusion Middlewareホームをバックアップしていない場合は、今すぐバックアップすることをお薦めします。

    既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

  • 各ホスト・コンピュータのシステム・クロックが同期していることを確認します(まだ確認していない場合)。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。

    別の方法として、この目的のために使用できるサードパーティのオープンソースのユーティリティもあります。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

エンタープライズ・デプロイメント用のソフトウェアのインストール

この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順について説明します。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

MFTHOST1でのManaged File Transferインストーラの起動

インストール・プログラムを起動するには:

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

    これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

    Installer File Nameは、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」にリストされているご使用の製品の実際のインストーラ・ファイルの名前に読み替えてください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

Managed File Transferをインストールする場合のインストール画面のナビゲート

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

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

画面 説明

ようこそ

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

自動更新

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

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。このOracleホームには、Oracle Fusion Middleware Infrastructureが含まれている必要があります。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareインストールの計画のインストールと構成のディレクトリの選択を参照してください。

前提条件のチェック

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

警告メッセージまたはエラー・メッセージが表示された場合は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のシステム環境の検証ロードマップに関する項に記載されているドキュメントのいずれかを参照してください。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを検証できます。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

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

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

他のホスト・コンピュータへのソフトウェアのインストール

SOAHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、SOAHOST2にもソフトウェアをインストールする必要があります。詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

Oracleホーム(ソフトウェア・バイナリが含まれている)をインストールする場所は、ホストによって異なることに注意してください。ご使用のOracleホーム・ディレクトリの正しい場所を特定するには、「このガイドで使用するファイル・システムとディレクトリ変数」のガイドラインを参照してください。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

インストールの確認

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルとその場所の詳細は、『Oracle Universal Installerによるソフトウェアのインストール』のインストール・ログ・ファイルの理解に関する項を参照してください。

親トピック: インストールの確認

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

インストールの内容は、インストール中に選択するオプションによって異なります。

ls --format=single-columコマンドを使用して、/u01/oracle/products/fmwのディレクトリおよびサブディレクトリのリストを確認します。 

cfgtoollogs
coherence
em
inventory
mft
OPatch
oracle_common
oraInst.loc
osb
oui
soa
wlserver

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリに関する項を参照してください。

親トピック: インストールの確認

Managed File Transferデータベース・スキーマの作成

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

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

リポジトリ作成ユーティリティ(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「表領域の暗号化」チェック・ボックスが選択されるようにデフォルト指定されます。『リポジトリ作成ユーティリティによるスキーマの作成』で表領域の暗号化に関する項を参照してください。

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

Managed File Transferスキーマを作成するためのRCU画面のナビゲート

スキーマ作成に必要なタスクは、次のとおりです。

タスク1   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. 「新規接頭辞の作成」を選択し、Managed File Transferスキーマに使用する接頭辞を入力します。Managed File Transferの新しいドメインを作成するため、一意のスキーマ接頭辞が必要です。

  2. スキーマのリストから、「Managed File Transfer」スキーマを選択します。

    次の依存スキーマが自動的に選択されます。

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

    • Oracle Enterprise Scheduler

    • Oracle Platform Security Services

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

    • 監査サービス

    • 監査サービスへの追加

    • 監査サービス・ビューア

    • メタデータ・サービス

    • WebLogicサービス

カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。

ヒント:

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

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

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

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

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

ヒント:

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

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

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

「表領域のマップ」画面で情報を確認し、「次へ」をクリックして、デフォルト値を受け入れます。

確認ダイアログ・ボックスで「OK」をクリックします。

タスク7 スキーマの作成

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

ノート:

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

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

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

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

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

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

たとえば:

ノート:

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

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

エンタープライズ・デプロイメント用のManaged File Transferドメインの作成

Fusion Middleware構成ウィザードを使用して別個のManaged File Transferドメインを作成します。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

構成ウィザードの起動

既存のエンタープライズ・デプロイメント・ドメインを拡張する最初のステップとして、構成ウィザードを起動します。

ノート:

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

構成ウィザードを起動するには:

  1. WebLogic Serverコンソールで、このドメイン拡張によって変更されるすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーは、オンラインのままにすることができます。
  2. いずれかの管理対象サーバーを変更する場合は、管理対象サーバーのシャットダウンが完了していることを確認してください。
  3. 管理対象サーバーがすべて安定した状態になったら、管理サーバーを停止します。
  4. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。
    cd ORACLE_HOME/oracle_common/common/bin
./config.sh

親トピック: エンタープライズ・デプロイメント用のManaged File Transferドメインの作成

MFTの構成ウィザード画面のナビゲート

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

親トピック: エンタープライズ・デプロイメント用のManaged File Transferドメインの作成

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

この項で説明する手順を実行して、静的クラスタで使用するMFTのドメインを作成して構成します。

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

ドメイン・ホーム・ディレクトリの場所(Oracleホーム・ディレクトリの外部が最適)を選択する必要があります。

ドメイン・ホームの場所は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリのディレクトリ構造に従って、Oracleホーム・ディレクトリの外に配置することをお薦めします。このディレクトリ構造は、ソフトウェアのアップグレードや再インストールが必要になった場合に問題が発生しないようにするのに役立ちます。

ドメイン・タイプおよびドメインのホーム・ディレクトリを指定するには:

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

  2. 「ドメインの場所」フィールドで、使用するドメイン・ホーム・ディレクトリを指定します。

この画面の詳細は、構成ウィザードを使用したWebLogicドメインの作成の構成タイプを参照してください

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

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

  • Oracle Managed File Transfer [mft]

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

    • Oracle Enterprise Manager

    • Oracle B2B Client

    • Oracle JRF

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

    • WebLogic Coherenceクラスタ拡張

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

タスク3   高可用性オプションの選択

この画面は、自動サービス移行またはJDBCストア、あるいはその両方を使用するクラスタを作成するときに初めて表示されます。クラスタのHAオプションを選択すると、構成ウィザードを使用してドメインに追加される以降のクラスタはすべて、自動的にHAオプションが適用されます(つまり、構成ウィザードによってJDBCストアが作成され、それにASMが構成される)。

「高可用性のオプション」画面で、次の手順を実行します。

  • 「データベース・ベース」で、「自動サービス移行の有効化」を選択します。

  • 「JTAトランザクション・ログ永続性」を「JDBC TLogストア」に設定します。

  • 「JMSサーバー永続性」を「JMS JDBCストア」に設定します。

ノート:

Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。そのため、構成ウィザードの各ステップでは、JDBC永続ストアと自動サービス移行を一緒に使用すると想定しています。

JDBC永続ストアを選択すると、余分な未使用のファイル・ストアが自動的に作成されますが、クラスタをターゲットとしたものではありません。こうしたファイル・ストアは無視してください。

なんらかの理由でファイル・ストアを使用する場合、この画面ではTLOGおよびJMS永続ストアのオプションをデフォルト値のままにしておき、後から共有の場所で構成することができます。「タスク12「詳細構成の選択」」を参照してください。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。

後のステップでは、TLOGおよびJMS永続ストアを手動で構成することもできます。JDBCストアとファイル・ストアの違いや、手動で構成する具体的な手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ノート:

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

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

フィールド 説明

DBMS/サービス

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

orcl.example.com

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

ホスト名

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

ポート

データベースがリスニングするポート番号を入力します。たとえば、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ドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

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

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

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

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

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

データ・ソースをGridLinkに変換するには:

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

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

タスク9   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データ・ソースの構成に関する項を参照してください。

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

タスク10   JDBC接続のテスト

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

デフォルトでは、スキーマの作成時に指定したパスワードが、各スキーマ・コンポーネントのスキーマ・パスワードです。スキーマ・コンポーネントに応じて異なるパスワードを使用する場合は、各行の「スキーマ・パスワード」列に使用するパスワードを入力して、前の画面(JDBCコンポーネント・スキーマ)でそれらを手動で編集します。パスワードを指定した後、パスワードを変更したスキーマに対応するチェック・ボックスを選択し、再度接続をテストします。

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

タスク11 キーストアの指定

構成ウィザードの「キーストア」画面を使用して、ドメインで使用されるキーストアの詳細を指定します。

標準的なエンタープライズ・デプロイメントの場合は、デフォルト値を残すことができます。詳細は、構成ウィザードによるWebLogicドメインの作成のキーストアを参照してください

タスク12   拡張構成の選択

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

  • 管理サーバー

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

  • ノード・マネージャ

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

  • トポロジ

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

ノート:

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

  • 推奨はJDBCストアで、タスク3「高可用性オプションの選択」でも選択されるので、「ファイル・ストア」を構成する必要はありません。

    タスク3「高可用性オプションの選択」で「ファイル・ストア」を選択した場合は、ここで「ファイル・ストア」オプションを選択し、ORACLE_RUNTIME/domain_name/MFT_Cluster/jmsの共有場所でそれを構成する必要があります。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。

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

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

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

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

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

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

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

タスク14 ノード・マネージャ・タイプ(ホストごと)の構成

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

ノート:

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

「管理対象サーバー」画面を使用して、Managed File Transferドメインで必要な管理対象サーバーを作成します。

  1. 「サーバー名」列のデフォルト・サーバー名をWLS_MFT1に変更します。

  2. 「追加」をクリックし、このプロセスを繰り返して、WLS_MFT2という名前の2つ目の管理対象サーバーを作成します。

  3. 表19-*の情報を使用して、MFT管理対象サーバーの残りの列を入力します。

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

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

サーバー名 リスニング・アドレス リスニング・ポート SSLの有効化 SSLリスニング・ポート サーバー・グループ

WLS_MFT1

MFTHOST1

7500

いいえ

無効

MFT-MGD-SVRS

WLS_MFT2

MFTHOST2

7500

いいえ

無効

MFT-MGD-SVRS

選択したサーバー・グループによって、Managed File TransferとOracle Web Services Manager (OWSM)ソフトウェアが、管理対象サーバーにターゲット設定されます。

サーバーに対してOracle Web Services Manager (OWSM)ではなくMFTのみを対象とするMFT-MGD-SVRS-ONLYと呼ばれる別のサーバー・グループがあります。これは、通常、Oracle Web Services Manager (OWSM)がMFTサーバーとは異なるサーバーにある場合に使用されます。

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

タスク16   クラスタの構成

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

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

  2. 「クラスタ名」フィールドにMFT_Clusterを指定します。

  3. 「アドレス」フィールドは、空白のままにしておきます。

  4. 「フロントエンド・ホスト」フィールドにmft.example.comを指定します。

  5. 「フロントエンドHTTPポート」に80を指定し、「フロントエンドHTTPSポート」に443を指定します。

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

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

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

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

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

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

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

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

「サーバーのクラスタへの割当」画面を使用して、管理対象サーバーを新しいクラスタに割り当てます。

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

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

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

      または

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

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

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

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

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

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

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

タスク21   マシンの作成

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

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

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

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

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

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

    ノート:

    追加のドメインがすでに構成されているホスト上にインストールする場合で、ホストごとのノード・マネージャをすでに構成済の場合、この画面で構成されるアドレスおよびポートは、既存のホストごとのノード・マネージャが対象となります。

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

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

MFTHOST1

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

5556

MFTHOST2

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

5556

ADMINHOST

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

5556

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ドメインの場所

  • 管理サーバーURL

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

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

静的クラスタを含めるドメインの拡張を完了したら、「Managed File Transferドメイン用のノード・マネージャの構成」に進みます。

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

この項で説明する手順を実行して、動的クラスタで使用するMFTのドメインを作成して構成します。

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

ドメイン・ホーム・ディレクトリの場所(Oracleホーム・ディレクトリの外部が最適)を選択する必要があります。

ドメイン・ホームの場所は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリのディレクトリ構造に従って、Oracleホーム・ディレクトリの外に配置することをお薦めします。このディレクトリ構造は、ソフトウェアのアップグレードや再インストールが必要になった場合に問題が発生しないようにするのに役立ちます。

ドメイン・タイプおよびドメインのホーム・ディレクトリを指定するには:

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

  2. 「ドメインの場所」フィールドで、使用するドメイン・ホーム・ディレクトリを指定します。

この画面の詳細は、構成ウィザードを使用したWebLogicドメインの作成の構成タイプを参照してください

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

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

  • Oracle Managed File Transfer [mft]

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

    • Oracle B2B Client

    • Oracle Enterprise Manager

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

    • Oracle JRF

    • WebLogic Coherenceクラスタ拡張

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

タスク3   高可用性オプションの選択

この画面は、自動サービス移行またはJDBCストア、あるいはその両方を使用するクラスタを作成するときに初めて表示されます。クラスタのHAオプションを選択すると、構成ウィザードを使用してドメインに追加される以降のクラスタはすべて、自動的にこれらのHAオプションが適用されます。

「高可用性のオプション」画面で、次の手順を実行します。

  1. 「データベース・ベース」で、「自動サービス移行の有効化」を選択します。

  2. 「JTAトランザクション・ログ永続性」を「JDBC TLogストア」に設定します。

  3. 「JMSサーバー永続性」を「JMS JDBCストア」に設定します。

ノート:

JDBCストアは、Oracleデータベースの一貫性、データ保護および高可用性の機能を活用して、クラスタのすべてのサーバーでリソースを利用できるようにすることをお薦めします。そのため、構成ウィザードの各ステップでは、JDBC永続ストアと自動サービス移行を一緒に使用すると想定しています。

JDBC永続ストアを選択すると、余分な未使用のファイル・ストアが自動的に作成されますが、クラスタをターゲットとしたものではありません。こうしたファイル・ストアは無視してください。

なんらかの理由でファイル・ストアを使用する場合、この画面ではTLOGおよびJMS永続ストアのオプションをデフォルト値のままにしておき、後から共有の場所で構成することができます。「タスク12「詳細構成の選択」」を参照してください。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。

後のステップでは、TLOGおよびJMS永続ストアを手動で構成することもできます。JDBCストアとファイル・ストアの違いや、手動で構成する具体的な手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ノート:

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

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

フィールド 説明

DBMS/サービス

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

orcl.example.com

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

ホスト名

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

ポート

データベースがリスニングするポート番号を入力します。たとえば、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ドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

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

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

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

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

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

データ・ソースをGridLinkに変換するには:

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

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

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

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

要素 説明と推奨値

SCAN、ホスト名とポート

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

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

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

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

ONSリストはデータベースからドライバに自動的に提供されるため、Oracle 12cデータベース以上のバージョンを使用している場合、これらの値は必要ありません。

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

FANの有効化

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

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

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

タスク10   JDBC接続のテスト

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

デフォルトでは、スキーマの作成時に指定したパスワードが、各スキーマ・コンポーネントのスキーマ・パスワードです。スキーマ・コンポーネントに応じて異なるパスワードを使用する場合は、前の画面(「JDBCコンポーネント・スキーマ」)でそれらを手動で編集して、使用するパスワードを各行の「スキーマ・パスワード」列に入力します。パスワードを指定した後、パスワードを変更したスキーマに対応するチェック・ボックスを選択し、再度接続をテストします。

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

タスク11 キーストアの指定

構成ウィザードの「キーストア」画面を使用して、ドメインで使用されるキーストアの詳細を指定します。

標準的なエンタープライズ・デプロイメントの場合は、デフォルト値を残すことができます。詳細は、構成ウィザードによるWebLogicドメインの作成のキーストアを参照してください。

タスク12   拡張構成の選択

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

  • 管理サーバー

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

  • ノード・マネージャ

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

  • トポロジ

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

ノート:

  • 推奨はJMS JDBCストアで、タスク3「高可用性オプションの選択」でも選択されるので、「ファイル・ストア」を構成する必要はありません。

    タスク3「高可用性オプションの選択」で「JMSファイル・ストア」を選択した場合は、「ファイル・ストア」オプションを選択し、ORACLE_RUNTIME/domain_name/MFT_Cluster/jmsの共有場所でそれを構成する必要があります。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。

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

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

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

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

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

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

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

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

タスク14 ノード・マネージャ・タイプ(ホストごと)の構成

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

ノート:

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

「管理対象サーバー」画面で、サーバーのリストにOracle Managed File Transfer用の新しい管理対象サーバーが表示されます。

動的クラスタ構成に静的管理対象サーバー定義は必要ありません。デフォルトの管理対象サーバーを削除するには、次のステップを実行します。

  1. デフォルトの管理対象サーバーを削除します。

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

タスク16   クラスタの構成

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

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

  2. 「クラスタ名」フィールドにMFT_Clusterを指定します。

  3. 「アドレス」フィールドは、空白のままにしておきます。

  4. 「フロントエンド・ホスト」フィールドにmft.example.comを指定します。

  5. 「フロントエンドHTTPポート」に80を指定し、「フロントエンドHTTPSポート」に443を指定します。

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

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

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

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

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

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

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

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

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

  1. 「クラスタ名」フィールドにMFT_Clusterを指定します。

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

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

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

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

    ノート:

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

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

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

  6. 「計算済リスニング・ポート」チェック・ボックスを選択します。

    ノート:

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

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

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

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

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

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

ノート:

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

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

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

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

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

タスク20   マシンの作成

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

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

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

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

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

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

    ノート:

    追加のドメインがすでに構成されているホスト上にインストールする場合で、ホストごとのノード・マネージャをすでに構成済の場合、この画面で構成されるアドレスおよびポートは、既存のホストごとのノード・マネージャが対象となります。

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

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

MFTHOST1

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

5556

MFTHOST2

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

5556

ADMINHOST

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

5556

ノート:

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

ヒント:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ドメインの場所

  • 管理サーバーURL

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

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

Managed File Transferドメイン用のノード・マネージャの構成

Managed File Transferドメインでは、ノード・マネージャで同じホスト上の複数のドメインを制御できるように、ホストごとのノード・マネージャを使用します。

MFTHOST1で最初にノード・マネージャを構成する場合、「エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成」に記載されているステップに従ってください。ドメイン名とディレクトリは、Managed File Transferドメインの値に一致している必要があります。

MFTHOST1でホストごとのノード・マネージャをすでに構成している場合、新しいドメインを既存のノード・マネージャ構成に追加できます。

  1. MFTHOST1で、ディレクトリをホストごとのノード・マネージャ・ホーム・ディレクトリに変更します。
    cd NM_HOME
  2. テキスト・エディタを使用してnodemanager.domainsファイルを開きます。
  3. 管理サーバー・ドメイン・ホームと管理対象サーバー・ドメイン・ホームへのパスをnodemanager.domainsファイルに追加します。

    ドメイン・パスはセミコロンで区切ります。たとえば:

    mftedg_domain=/u02/oracle/config/domains/mftedg_domain;/u01/oracle/config/domains/mftedg_domain
  4. MFTHOST2,に対してステップ1から2を実行し、nodemanager.domainsファイルに次のドメイン・ホーム・パスを追加します。
    mftedg_domain=/u02/oracle/config/domains/mftedg_domain

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

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. ファイルを保存してエディタを閉じます。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

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

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

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

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

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

デフォルトでは、ホストごとのノード・マネージャ構成では、ノード・マネージャからサーバーへの通信に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/mftedg_domain')

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

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

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

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

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

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

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

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

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

Derbyデータベースの無効化

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

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

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

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

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

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

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

管理サーバーの検証

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. packコマンドで作成した、テンプレートJARファイルの場所をノートにとります。

    ヒント:

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

  3. まだ作成していない場合は、MFTHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
  4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
    cd ORACLE_COMMON_HOME/common/bin

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

    ノート:

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

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

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

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

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

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

    • APPLICATION_HOMEを、共有記憶域上のそのドメインのapplicationsディレクトリの完全なパスに置き換えます。

    ヒント:

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

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

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

MFTHOST1でのWLS_MFT1管理対象サーバーの起動と検証

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

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

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

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

    ノート:

    • サーバーURLを検証するには、Oracle Traffic Directorの構成が完了するまで、フロントエンド・ホストを無効化(空白に設定)します。フロントエンド・ホストを無効化しない場合、すべてのリクエストはフロントエンド・アドレスにリダイレクトされるため、失敗します。

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

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

      MFTHOST1:7500/wsm-pm/ 
MFTHOST1:7500/mftconsole/

MFTHOST2:7501/wsm-pm/ 
MFTHOST2:7501/mftconsole/

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

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

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

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

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

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

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

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

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

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

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

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

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

    ヒント:

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

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

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

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

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

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

MFTHOST2でのWLS_MFT2管理対象サーバーの起動と検証

「MFTHOST1でのWLS_MFT1管理対象サーバーの起動と検証」で説明されている手順を使用して、MFTHOST2上のWLS_MFT2管理対象サーバーを起動および検証します。

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

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

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

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

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

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

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

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

拡張したドメイン用のWeb層の構成

Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをインスタンスでルーティングできるようにします。

考えられるスケールアウト・シナリオの準備での追加のステップは、クロス・コンポーネント・ワイヤリング情報の更新を参照してください。

  • Managed File Transfer用のOracle Traffic Directorの構成
    Oracle Traffic Directorは、Web層のOracle HTTP Serverのかわりとして使用できます。Oracle HTTP Serverと同様に、これはHTTPリクエストをフロントエンド・ロード・バランサからアプリケーション層のWebLogic管理対象サーバーにルーティングできます。ただし、TCPロード・バランシングおよびフェイルオーバーを提供できるのは、Oracle Traffic Directorのみです。そのため、Oracle Traffic Directorは、セキュアなFTPリクエストのルーティングのためにTCPを必要とするOracle Managed File Transferによって必要とされます。
  • WebLogicプロキシ・プラグインの構成

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

Managed File Transfer用のOracle Traffic Directorの構成

Oracle Traffic Directorは、Web層のOracle HTTP Serverのかわりとして使用できます。Oracle HTTP Serverと同様に、これはHTTPリクエストをフロントエンド・ロード・バランサからアプリケーション層のWebLogic管理対象サーバーにルーティングできます。ただし、TCPロード・バランシングおよびフェイルオーバーを提供できるのは、Oracle Traffic Directorのみです。そのため、Oracle Traffic Directorは、セキュアなFTPリクエストのルーティングのためにTCPを必要とするOracle Managed File Transferによって必要とされます。

Oracle Traffic Directorの構成の詳細は、エンタープライズ・デプロイメント用のOracle Traffic Directorの構成を参照してください。

親トピック: 拡張したドメイン用のWeb層の構成

WebLogicプロキシ・プラグインの構成

リクエストがOracle HTTP ServerまたはOracle Traffic Directorインスタンスを介して正しくルーティングされたことを検証するには、先ほど構成したクラスタに対して「WebLogicプラグインの有効化」パラメータを設定しておく必要があります。WebLogicプロキシ・プラグインを構成するには:

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「ドメイン構造」ペインで「環境」ノードを開きます。
  3. 「チェンジ・センター」で「ロックして編集」をクリックします。
  4. 「クラスタ」をクリックします
  5. Oracle HTTP Serverからのリクエストをプロキシ設定する、クラスタを選択します。

    「構成: 一般」タブが表示されます

  6. 「詳細」セクションまでスクロール・ダウンして、開きます。
  7. 「WebLogicプラグインの有効化」を「はい」に設定します。
  8. 「保存」をクリックします。
  9. 直近のドメイン拡張で複数のクラスタをデプロイした場合は、すべてのクラスタが一貫して更新されるまで、ステップ4から8を繰り返します。
  10. 「チェンジ・センター」の「変更のアクティブ化」をクリックします。
  11. この章で変更したすべてのクラスタ内のすべての管理対象サーバーを再起動します。

親トピック: 拡張したドメイン用のWeb層の構成

ロード・バランサを使用したManaged File Transfer URLの検証

Oracle Traffic Directorの構成を検証し、ハードウェア・ロード・バランサがOTDインスタンスを経由してアプリケーション層にリクエストをルーティングすることを確認するには:
  1. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。別のステータス(「管理」や「失敗」など)が表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。
  2. 次のURLにアクセスできることを確認します。
    https://mft.example.com:443/mftconsole

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

Managed File TransferのSSH-FTPサービスの構成および有効化

Oracle Managed File Transferのエンタープライズ・デプロイメント・トポロジは、ファイル転送用のSecure File Transfer Protocol (SFTP)に基づきます。SFTPは、別個のプロトコルであり、SSHとともにパッケージされ、FTPのように動作しますが、セキュアな接続を使用します。

SFTPでは、ファイル転送接続に使用するポート数を制限できます。これは、その基礎となるセキュリティ機能の存在と標準のSSH接続の使用が可能であることから、FTPより推奨されます。

  • 必要なSSHキーの生成
    SFTPを有効化するには、SSHキーを生成する必要があります。Managed File Transferではクラスタ内のすべてのサーバーで同じSFTPキーが共有されるため、管理対象サーバーの1つで1回のみこの手順を実行する必要があります。
  • SFTPポートの構成
    Oracle Managed File TransferでSecure File Transfer Protocol (SFTP)を使用する前に、SFTPポートを構成する必要があります。
  • Managed File Transferの追加のSFTP構成ステップ
    Managed File TransferでSFTPを使用する場合に実行する必要のある、追加の構成ステップがいくつかあります。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

必要なSSHキーの生成

SFTPを有効化するには、SSHキーを生成する必要があります。Managed File Transferではクラスタ内のすべてのサーバーで同じSFTPキーが共有されるため、管理対象サーバーの1つで1回のみこの手順を実行する必要があります。

有効な秘密キーがないと、SSH-FTPサーバーは起動しません。セキュリティのベスト・プラクティスに準拠するには、常にパスワードで保護された秘密キーを使用する必要があります。使用するパスワードは、Managed File Transferコンソールで指定したパスワードに一致している必要があります。コンソールでパスワードを特定するには、「キーストア」→「SSHキーストア」→「秘密キーのパスワード」を選択します。

  1. a.ssh-keygenコマンドを実行してキーを生成します。

    たとえば:

    ssh-keygen \-t rsa \-b 2048

    ssh-keygenは、標準のUnixおよびLinuxコマンドです。詳細は、オペレーティング・システムのドキュメントを参照してください。

    生成されたキーの場所をノートにとります。この情報は、後で必要になります。

  2. キーをManaged File Transferキーストアにインポートします。
    1. Managed File Transfer管理対象サーバーが稼働中であることを確認します。
    2. ディレクトリを次の場所に変更します。
      ORACLE_COMMON_HOME/common/bin
    3. WebLogic Server Scripting Tool (WLST)を起動します。
      ./wlst.sh
    4. 次のコマンド構文を使用して、最初の管理対象サーバーに接続します。
      connect('admin_user','admin_password','server_url')

      たとえば:

      connect('weblogic','<password>','t3://MFTHOST1:7500')
    5. 次のWLSTコマンドを実行してキーをインポートします。
      importCSFKey('SSH', 'PRIVATE', 'alias', 'pvt_key_file_path')

      aliasは、管理対象サーバーを識別するために使用できる名前に置き換えます。

      pvt_key_file_pathは、この手順で前に生成したキーの名前およびディレクトリの場所に置き換えます。『SOA Suite WLSTコマンド・リファレンス』のimportCSFKeyに関する項を参照してください

  3. SSHキーのインポートに成功したら、SSH-FTPを有効化して秘密キーの別名を選択します。
    1. ドメイン管理ユーザーとパスワードを使用して、次のURLでManaged File Transferコンソールに接続します。
      mft.mycompany.com:80/mftconsole
    2. 「管理」タブから、「キーストア管理」に移動します。
    3. 「SSHキーストア」フィールドに、この手順で前に作成したキーストア・パスワードを入力します。
    4. 変更内容を保存します。
    5. 「管理」タブを選択し、ナビゲーション・ツリーで「埋込みサーバー」を開きます。
    6. SFTPタブで、「有効」を選択します。
    7. 「ホスト・キー・エイリアス」ドロップダウン・メニューから、この手順で前に作成した秘密キーの別名を選択します。
    8. 「認証タイプ」を「パスワード」のままにします。
    9. 変更内容を保存します。
    10. 「起動」をクリックしてSSH-FTPサービスを起動します。

親トピック: Managed File TransferのSSH-FTPサービスの構成および有効化

SFTPポートの構成

Oracle Managed File TransferでSecure File Transfer Protocol (SFTP)を使用する前に、SFTPポートを構成する必要があります。

  1. ドメイン管理ユーザー名とパスワードを使用して、Managed File Transferコンソールに接続します。
    mft.example.com:80/mftconsole
  2. 「管理」タブを選択します。
  3. 左側のナビゲーション・ペインで、「埋込みサーバー」を開きます。
  4. 「ポート」をクリックします。
  5. Managed File TransferサーバーのSFTPサービスに、「構成済ポート」として7022と入力します。
  6. 「保存」をクリックします。
  7. 全選択して「再起動」をクリックすると、サーバー・インスタンスが再起動します。

親トピック: Managed File TransferのSSH-FTPサービスの構成および有効化

Managed File Transferの追加のSFTP構成ステップ

Managed File TransferでSFTPを使用する場合に実行する必要のある、追加の構成ステップがいくつかあります。

  1. 次のURLのManaged File Transferコンソールに接続します。
    mft.example.com:80/mftconsole
  2. 「管理」を選択し、ナビゲーション・ツリーで「埋込みサーバー」を選択します。
    1. 共有記憶域を指すように、ルート・ディレクトリを更新します。

      たとえば:

      ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/ftp_root
    2. 「保存」をクリックします。
  3. 「管理」を選択し、ナビゲーション・ツリーで「サーバー・プロパティ」を選択します。
  4. 高可用性プロパティを更新します。
    1. クラスタ内の異なるサーバーからアクセスできる共有記憶域の場所を指すように、ペイロードおよびコールアウト・ディレクトリを更新します。

      たとえば:

      ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/storage

      ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/callouts

    2. 「制御ディレクトリ」を共有の場所に設定します。

      たとえば:

      ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/control_dir

      制御ディレクトリは、高可用性のユース・ケースを処理するためにManaged File TransferのファイルおよびFTPアダプタによって使用されるディレクトリ・パスです。MFTがHA環境で実行している場合、このフィールドは必須です。クラスタ内で複数のOracle WebLogic Serverインスタンスが稼働している場合は、共有の場所に設定する必要があります。
    3. 次のフィールドの値を確認します。

      • 「インバウンド・データソース」の値がjdbc/MFTDataSourceに設定されていることを確認します。

      • 「アウトバウンド・データソース」の値がjdbc/MFTDataSourceに設定されていることを確認します。

    4. これまでの変更内容を保存します。
    5. ナビゲーション・ツリーで「拡張配信プロパティ」を開きます。

      拡張配信プロパティにより、ロード・バランサで使用される内部アドレスと外部アドレス(IPアドレス)に加え、FTP、FTPSおよびSFTPポートを取得します。

      これらの設定を使用するのは、Oracle Managed File TransferからペイロードがFTPまたはSFTP参照として送信されるときです。値が設定されている場合は、その値を使用してFTP参照(FTP/SFTPホスト・アドレスとポート)が構築されます。

      Managed File Transferが内部および外部プロキシの背後で稼働している場合、内部および外部IPアドレスは必須です。

      • 内部アドレス: SFTPに内部ロード・バランサを使用していないかぎり、このフィールドは空白のままにします。デフォルトのエンタープライズ・デプロイメントでは、内部ロード・バランサではなく外部ロード・バランサを使用します。

      • 外部アドレス: 外部ロード・バランサを通じたSFTリクエストのエントリ・ポイントとして使用するアドレスを入力します。

        たとえば、アドレスとしてsftp.example.comを、SFTPポートとして7022を入力します。

    6. 変更内容を保存し、コンソールを終了します。
  5. WLS_MFT管理対象サーバーを再起動します。
  6. 任意の標準的なSFTPクライアント・アプリケーションを使用して、SFTPを介してManaged File Transferサーバーにアクセスできることを確認します。

    たとえば:

    sftp -o "Port 7022" weblogic@MFTHOST1
Connecting to MFTHOST1 ... 
Password authentication 
Password:
sftp>
  7. 任意の標準的なSFTPクライアント・アプリケーションを使用し、SFTPを使用してロード・バランサを介してManaged File Transferサーバーにアクセスできることを確認します。

    たとえば:

    sftp -o "Port 7022" weblogic@mft.example.com
Connecting to mft.example.com ... 
Password authentication 
Password:
sftp>

親トピック: Managed File TransferのSSH-FTPサービスの構成および有効化

新しいLDAPオーセンティケータの作成とManaged File Transferのユーザーのプロビジョニング

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

新しいOracle Fusion Middlewareドメインごとにこの手順が必要です。Oracle Managed File Transferドメインでは、次のタスクを実行できます。
  1. 「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」を確認して、必要な概念を理解し、新しいLDAPオーセンティケータを作成します。
  2. ユーザーとグループをプロビジョニングする場合、Managed File Transfer管理認証では次のユーザー名およびグループ名を使用します。
    管理ユーザー: weblogic_mft
    管理グループ: MFT Administrators
  3. Oracle Enterprise Manager Fusion Middleware Controlにログインして、製品固有の管理ロールをグループに割り当てます。「エンタープライズ・デプロイメントの管理用のロールの構成」を参照してください。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

Oracle Managed File TransferのJDBC永続ストアの有効化

Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。

このガイドで静的クラスタと静的クラスタの両方について推奨されているように、「高可用性のオプション」画面で次の選択を行った場合、JDBC永続ストアはすでにJMSとTLOGSの両方に対して構成されています:

  • 「JTAトランザクション・ログ永続性」を「JDBC TLogストア」に設定します。

  • 「JMSサーバー永続性」を「JMS JDBCストア」に設定します。

「高可用性のオプション」画面でJMSとTLOGSの永続のためにJDBCを選択していなかった場合は、その後のステップでJDBCストアを手動で構成することもできます。手動で構成する際の具体的な手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

ノート:

「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタを初めて作成するときに、構成ウィザードのセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

Oracle Managed File Transferに対する自動サービス移行の有効化

Oracle Managed File Transfer (MFT)が高可用性を実現するように構成するには、サービス移行に対応するようにMFTサーバーを構成する必要があります。

このガイドで静的クラスタと動的クラスタの両方に推奨されているように、「高可用性のオプション」画面で「データベース・リース」による「自動サービス移行の有効化」を選択した場合、自動サービス移行はすでに構成されています。このオプションを選択すると、データベース・リースが構成され、移行可能ターゲット(静的クラスタを使用している場合)または永続ストア(動的クラスタを使用している場合)がクラスタの適切な移行ポリシーで作成されます。

この設定を実装している場合は、「静的クラスタでの自動サービス移行の検証」の説明に従って構成を検証します。

構成ウィザードのセッション中に、このオプションを選択していない場合でも、その後のステップで自動移行を手動で構成できます。手順は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

ノート:

「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタを初めて作成するときに、構成ウィザードのセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

構成のバックアップ

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

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

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

親トピック: エンタープライズ・デプロイメントでのOracle Managed File Transferの構成