| Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11gリリース1（11.1.1） B55899-01 |
|
 戻る |
 次へ |
| Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11gリリース1（11.1.1） B55899-01 |
|
戻る |
次へ |
この章では、SOAエンタープライズ・トポロジで必要なデータベース事前構成とネットワーク環境の事前構成について説明します。この章の項目は次のとおりです。
SOAエンタープライズ・トポロジでは、データベースにはOracle Fusion Middlewareリポジトリが格納されます。これは、様々なOracle Fusion Middlewareコンポーネントによって使用されるスキーマのコレクションです。コンポーネントの例には、SOAコンポーネント、BAMおよびOWSMなどがあります。このデータベースはアイデンティティ管理データベースとは別になっています。これは、Oracle Internet DirectoryやDIPなどのコンポーネントによってアイデンティティ管理のEDGで使用されます。
Oracle Fusion Middlewareコンポーネントを構成するには、まずOracle Fusion Middlewareリポジトリをインストールする必要があります。Oracle Fusion Middlewareメタデータ・リポジトリは、リポジトリ作成ユーティリティ（RCU）を使用して既存のデータベースにインストールします。RCUはRCUのDVDにあるか、表1-2に記載された場所にあります。エンタープライズ・トポロジでは、Real Application Clusters（RAC）データベースを強くお薦めします。
SOAコンポーネントを構成すると、メタデータ・リポジトリを含むデータベースへの接続情報を入力するように構成ウィザードで求められます。
この項の項目は次のとおりです。
メタデータ・リポジトリをデータベースにロードする前に、次の各項で説明されている要件をデータベースが満たしていることを確認してください。
データ層内のCUSTDBHOST1およびCUSTDBHOST2には、次の要件があります。
Oracle Clusterware
Linux用11gリリース1（11.1）については、Oracle Clusterwareのインストレーション・ガイドを参照してください。
Oracle Real Application Clusters
Linux用11gリリース1（11.1）については、Oracle Real Application Clustersのインストレーション・ガイドを参照してください。Linux用10gリリース2（10.2）については、Oracle Database Oracle ClusterwareとOracle Real Application Clustersのインストレーション・ガイドを参照してください。
ASMでは、ノードが全体としてインストールされます。データベースのOracleホームとは別のOracleホームにインストールすることをお薦めします。このオプションはrunInstallerにあります。「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択し、個別のASMホームを作成します。
サポートされているOracle Databaseのバージョンは次のとおりです。
Oracle Database 11g（11.1.0.7以降）: Enterprise Editionのエディションを使用することをお薦めします（特に、障害時リカバリ用サイトを計画している場合や求められている場合）。
Oracle Database 10g（10.2.0.4以降）: Oracle Database 10g Express Edition（Oracle Database XE）は、Oracle Fusion Middleware 11gリリース1ではサポートされていません。Enterprise Editionのエディションを使用することをお薦めします（特に、障害時リカバリ用サイトを計画している場合や求められている場合）。
データベースのリリースをチェックするには、次のようにPRODUCT_COMPONENT_VERSIONビューに問い合わせます。
SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE PRODUCT LIKE 'Oracle%';
必要な最小値に次の初期化パラメータが設定されていることを確認してください。これはRepository Creation Assistantによりチェックされます。
表2-1 必要な初期化パラメータ
| 構成 | パラメータ | 必要な値 | パラメータ・クラス |
|---|---|---|---|
|
SOA |
300以上 |
静的 |
|
|
BAM |
|
100以上 |
静的 |
|
SOAとBAM |
|
400以上 |
静的 |
SQL*Plusを使用して初期化パラメータの値をチェックするには、次のSHOW PARAMETERコマンドを使用します。
SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。
SQL> SHOW PARAMETER processes
次のコマンドを使用して初期化パラメータを設定します。
SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE;
データベースを再起動します。
|
注意: パラメータ値の変更に使用する方法は、パラメータが静的であるか動的であるかと、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用するかによって異なります。パラメータ・ファイル、サーバー・パラメータ・ファイルおよびパラメータ値の変更方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Enterprise Managerの「クラスタ管理サービス」ページを使用して、クライアント・アプリケーションがデータベースへの接続に使用するデータベース・サービスを作成することをお薦めします。データベース・サービスの作成手順の詳細は、Oracle Database Oracle Clusterwareのワークロード管理に関する章および『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
またSQL*Plusを使用して、次の手順に従ってこれを構成することもできます。
CREATE_SERVICEサブプログラムを使用して、soaedg.mycompany.comデータベース・サービスを作成します。SYSDBAユーザーとしてSQL*Plusにログオンし、次のコマンドを実行します。
SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE (SERVICE_NAME => 'soaedg.mycompany.com', NETWORK_NAME => 'soaedg.mycompany.com', );
サービスをデータベースに追加し、srvctlを使用してインスタンスに割り当てます。
prompt> srvctl add service -d soadb -s soaedg -r soadb1,soadb2
srvctlを使用してサービスを開始します。
prompt> srvctl start service -d soadb -s soaedg
|
注意: SRVCTLコマンドの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
同じデータベースを共有する場合でも、特定のデータベース・サービスを製品スイート用に使用することをお薦めします。また、使用されるデータベース・サービスはデフォルトのデータベース・サービスとは別のものをお薦めします。この場合、データベースはsoadb.mycompany.comになり、デフォルトのサービスは同じ名前のものになります。soaedg.mycompany.comサービスを使用するようにSOAインストールは構成されます。bamedg.mycompany.comの名前のサービスはBAMに使用することをお薦めします。
Oracle Fusion Middlewareリポジトリをデータベースにロードする手順は次のとおりです。
リポジトリ作成ユーティリティ（RCU）を起動します。RCUはRCUのDVDにあるか、表1-2に記載された場所にあります。最初にRCUのDVDを挿入します。
binディレクトリでRCUを起動します。
./rcu
「ようこそ」画面で、「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。
「データベース接続の詳細」画面で、次のデータベース接続情報を入力します。
データベース・タイプ: 「Oracle Database」を選択します。
ホスト名: データベースを実行しているノードの名前を入力します。RACデータベースの場合は、VIP名またはノード名のいずれかをホスト名（CUSTDBHOST1-VIP）として指定します。
ポート: データベースのポート番号を入力します(例: 1521）。
サービス名: データベースのサービス名（soaedg.mycompany.com）を入力します。
ユーザー名: SYS
パスワード: SYSユーザーのパスワードを入力します。
ロール: SYSDBA
「次へ」をクリックします。
接続しているデータベースにUTF8以外のCharsetが含まれていることを示す警告メッセージが表示された場合、多言語をサポートするためにこのデータベースを使用すると、データが失われることがあります。多言語をサポートしていない場合は続行できます。サポートしている場合はUTF-8データベースを使用してください。
「無視」または「停止」をクリックします。
「コンポーネントの選択」画面で、次の手順を実行します。
「接頭辞の新規作成」を選択し、データベース・スキーマに使用する接頭辞を入力します。たとえば、DEVまたはPRODとします。データベースで複数のリポジトリの論理グループを作成するために、接頭辞が使用されます。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
|
ヒント: スキーマ名を書き留めておきます。この情報は後続の手順で必要になります。 |
次を選択します。
AS共通スキーマ:
- メタデータ・サービス
SOAインフラストラクチャ:
- SOAインフラストラクチャ
- ユーザー・メッセージング
- Business Activity Monitoring
「次へ」をクリックします。
「スキーマ・パスワード」画面で、メインおよび追加（補助）スキーマ・ユーザーのパスワードを入力し、「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択し、「次へ」をクリックします。
「サマリー」画面で、「作成」をクリックします。
「完了サマリー」画面で、「閉じる」をクリックします。
メタデータ・リポジトリをデータベースにロードしたら、バックアップする必要があります。
データベースのバックアップは、今後の手順で問題が発生した場合に迅速なリカバリを行うために明示的に行います。この目的のために、データベース用のバックアップ計画を使用したり、オペレーティング・システムのツールやRMANを使用して単純にバックアップするように選択できます。データベース用にOracle Recovery Managerを使用することをお薦めします（特に、Oracle ASMを使用してデータベースを作成した場合）。可能な場合、オペレーティング・システムのツール（tarなど）を使用してコールド・バックアップも実行できます。
この項の項目は次のとおりです。
SOAエンタープライズ・トポロジでは、次の仮想サーバー名を使用します。
仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するノードは、これらの仮想サーバー名を解決できるようになっている必要があります。
soa.mycompany.comは、soa-infra、ワークフロー、B2BなどのランタイムSOAコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。SSLへのトラフィックが構成されます。クライアントはsoa.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサで定義されます。
admin.mycompany.comは、WebLogic管理サーバー・コンソールやOracle Enterprise Managerなどの管理サービスに転送されるすべての内部HTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。
クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはadmin.mycompany.com:80のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。
この仮想サーバーは、ロード・バランサで定義されます。
soainternal.mycompany.comは、SOAサービスの内部起動に使用される仮想サーバー名です。このURLはインターネットに公開されずに、イントラネットからのみアクセスできます。SOAシステムの場合、実行時に適切なEM/MBeansやコンポジットをモデリングしているときにユーザーはこれを設定できます。URLはサービスの内部起動に使用されます。
クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはsoainternal.mycompany.com:80のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。
この仮想サーバーは、ロード・バランサで定義されます。
このエンタープライズ・トポロジは外部のロード・バランサを使用します。ロード・バランサの詳細は、第1.5.2項「Web層」を参照してください。
|
注意: Oracle Technology Network（http://www.oracle.com/technology/index.html）には、検証されたロード・バランサと構成の一覧（http://www.oracle.com/technology/products/ias/hi_av/Tested_LBR_FW_SSLAccel.html）が用意されています。 |
ロード・バランサを構成する手順は次のとおりです。
サーバーのプールを作成します。このプールを仮想サーバーに割り当てます。
Oracle HTTP Serverホストのアドレスをプールに追加します。次に例を示します。
WEBHOST1:7777
WEBHOST2:7777
soa.mycompany.com:443用のロード・バランサで仮想サーバーを構成します。
この仮想サーバーでは、システムのフロントエンド・アドレスを仮想サーバーのアドレス（たとえば、soa.mycompany.com）として使用します。フロントエンド・アドレスは、システムで使用され外部に公開されているホスト名であり、インターネットに公開されます。
ポート80とポート443でこの仮想サーバーを構成します。ポート80に入力するリクエストはすべて、ポート443にリダイレクトされる必要があります。
ANYをプロトコルとして指定します（B2BではHTTPでないプロトコルが必要）。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
手順1で作成したプールを仮想サーバーに割り当てます。
この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。
admin.mycompany.com:80用のロード・バランサで仮想サーバーを構成します。
この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス（たとえば、admin.mycompany.com）として使用します。このアドレスは一般的に外部化されません。
HTTPをプロトコルとして指定します。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
手順1で作成したプールを仮想サーバーに割り当てます。
soainternal.mycompany.com:80用のロード・バランサで仮想サーバーを構成します。
この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス（たとえば、soainternal.mycompany.com）として使用します。このアドレスは一般的に外部化されません。
HTTPをプロトコルとして指定します。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
手順1で作成したプールを仮想サーバーに割り当てます。
必要に応じて、この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。
Oracle HTTP Serverノードを監視してノードの障害を検出するように構成します。
「/」のURLコンテキストに定期的にpingを実行するように監視を設定します。
|
ヒント: Oracle HTTP Serverのドキュメント・ルートにindex.htmが存在せずにOracle WebLogic Serverで「/」の404エラーが返される場合は、かわりにGET /\n\nを使用してください。 |
ping実行間隔については、システムに負荷を与えないように値を指定します。とりあえず5秒で試してみることができます。
タイムアウト時間については、使用するSOAシステムで予測できる最長レスポンス時間の説明として妥当な値を指定します。つまり、HTTPサーバーのリクエスト処理における最長所要時間より大きな値を指定します。
図2-1に示すように、異なる仮想IPと物理IPでリスニングするように、管理サーバーと管理対象サーバーを構成してください。図に示すように、各VIPとIPは、使用するWebLogic Serverに割り当てられます。VIP1に障害が発生すると、手動で管理サーバーがSOAHOST2で再起動します。Oracle WebLogic Serverの移行機能により、VIP2とVIP3がそれぞれ、SOAHOST1からSOAHOST2にフェイルオーバーし、SOAHOST2からSOAHOST1にフェイルオーバーします。またWLS_BAM1でもサーバー移行機能が使用されて、VIP4をBAMHOST1からBAMHOST2にフェイルオーバーします。WebLogic Serverの移行機能の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。物理IP（仮想IPでない）が各ノードに固定的に割り当てられます。IP1はSOAHOST1の物理IPで、WLS_WSM1 WebServicesポリシー・マネージャのサーバーで使用されます。IP2はSOAHOST2の物理IPで、WLS_WSM2 WebServicesポリシー・マネージャのサーバーで使用されます。IP3はBAMHOST2の物理IPで、WLS_BAM2サーバーによりリスニング・アドレスとして使用されます。
表2-2には、様々な仮想ホストの説明が記載されています。
表2-2 仮想ホスト
| 仮想IP | VIPのマップ先 | 説明 |
|---|---|---|
|
VIP1 |
SOAHOST1VHN1 |
SOAHOST1VHN1は、管理サーバーのリスニング・アドレスである仮想ホスト名です。管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバーのプロセスが実行されているノード（デフォルトはSOAHOST1）で有効にされます。 |
|
VIP2 |
SOAHOST1VHN2 |
SOAHOST1VHN2は、WLS_SOA1のリスニング・アドレスにマップされている仮想ホスト名です。この管理対象サーバーのサーバー移行機能によりフェイルオーバーします。WLS_SOA1プロセスが実行されているノード（デフォルトはSOAHOST1）で有効にされます。 |
|
VIP3 |
SOAHOST2VHN1 |
SOAHOST2VHN1は、WLS_SOA2のリスニング・アドレスにマップされている仮想ホスト名です。この管理対象サーバーのサーバー移行機能によりフェイルオーバーします。WLS_SOA2プロセスが実行されているノード（デフォルトはSOAHOST2）で有効にされます。 |
|
VIP4 |
BAMHOST1VHN1 |
BAMHOST1VHN1は、WLS_BAM1のリスニング・アドレスにマップされている仮想ホスト名です。この管理対象サーバーのサーバー移行機能によりフェイルオーバーします。WLS_BAM1プロセスが実行されているノード（デフォルトはBAMHOST1）で有効にされます。 |
多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにする必要があります。
ほとんどのポート番号はインストール中に割り当てられます。
表2-3にはSOAトポロジで使用されるポートの一覧が記載されています。トポロジにあるファイアウォールで開く必要のあるポートも記載されています。
ファイアウォール表記法:
FW0は外側のファイアウォールを示します。
FW1は、Web層とアプリケーション層との間におけるファイアウォールを示します。
FW2は、アプリケーション層とデータ層との間におけるファイアウォールを示します。
表2-3 使用されるポート
| タイプ | ファイアウォール | ポートとポート範囲 | プロトコル/アプリケーション | インバウンド/アウトバウンド | その他の考慮事項とタイムアウトのガイドライン |
|---|---|---|---|---|---|
|
ブラウザによるリクエスト |
FW0 |
80 |
HTTP/ロード・バランサ |
インバウンド |
タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
ブラウザによるリクエスト |
FW0 |
443 |
HTTPS/ロード・バランサ |
インバウンド |
タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
Oracle HTTP Serverへのロード・バランサ |
n/a |
7777 |
HTTP |
n/a |
第2.2.2.1項「ロード・バランサの構成」を参照してください。 |
|
管理サーバーによるOHS登録 |
FW1 |
7001 |
HTTP/t3 |
インバウンド |
タイムアウトを短い時間（5〜10秒）に設定します。 |
|
管理サーバーによるOHS管理 |
FW1 |
OPMNポート（6701）とOHS管理ポート（7779） |
それぞれTCPとHTTP |
アウトバウンド |
タイムアウトを短い時間（5〜10秒）に設定します。 |
|
WSM-PMのアクセス |
FW1 |
7010 範囲: 7010〜7999 |
HTTP / WLS_WSM-PMn |
インバウンド |
タイムアウトを60秒に設定します。 |
|
SAOサーバーのアクセス |
FW1 |
8001 範囲: 8000〜8080 |
HTTP / WLS_SOAn |
インバウンド |
タイムアウトは、SOAによって使用されるプロセス・モデルのタイプによって異なります。 |
|
BAMのアクセス |
FW1 |
9001 範囲: 9000〜9080 |
HTTP / WLS_BAMn |
インバウンド |
レポートやブラウザが閉じられるまでBAM WebAppsへの接続は開いたまま維持されます。これによって、ユーザー・セッションの最長持続可能時間と同じ時間のタイムアウトを設定します。 |
|
複数のSOAクラスタ・メンバー間における通信 |
n/a |
8001 |
TCP/IPユニキャスト |
n/a |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
複数のWSMクラスタ・メンバー間における通信 |
n/a |
7010 |
TCP/IPユニキャスト |
n/a |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
WebLogic Serverクラスタ内におけるセッション・レプリケーション |
n/a |
n/a |
n/a |
n/a |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
管理コンソールのアクセス |
FW1 |
7001 |
HTTP/管理サーバーとEnterprise Manager t3 |
両方 |
管理コンソールへのアクセスのタイプ（アプリケーション層のクライアントからOracle WebLogic Server管理コンソールを使用する予定があるか、またはアプリケーション層の外部のクライアントから使用する予定があるか）に基づいてこのタイムアウト時間をチューニングする必要があります。 |
|
ノード・マネージャ |
n/a |
5556 |
TCP/IP |
n/a |
n/a 実際の値については、『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management』のファイアウォールとポートに関する項を参照してください。 |
|
アクセス・サーバーのアクセス |
FW1 |
6021 |
OAP |
インバウンド |
実際の値については、『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management』のファイアウォールとポートに関する項を参照してください。 |
|
アイデンティティ・サーバーのアクセス |
FW1 |
6022 |
OAP |
インバウンド |
|
|
データベースのアクセス |
FW2 |
1521 |
SQL*Net |
両方 |
タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテキストによって異なります。 |
|
デプロイメントの一貫性 |
n/a |
8001 範囲: 8000〜8080 |
n/a |
n/a |
|
|
Oracle Internet Directoryのアクセス |
FW2 |
389 |
LDAP |
インバウンド |
ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。 |
|
Oracle Internet Directoryのアクセス |
FW2 |
636 |
LDAP SSL |
インバウンド |
ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。 |
|
注意: B2BのTCP/IPポートは、ユーザーが構成するポートであり、事前定義されません。同様に、ファイアウォールのポートは、TCP/IPポートの定義によって異なります。 |
この項では、EDGトポロジ用にお薦めするディレクトリとディレクトリ構造について詳しく説明します。他のディレクトリ・レイアウトも可能でサポートされていますが、このガイドで採用されているモデルは、可用性を最大にするために選択されました。これによって、コンポーネントが適切に分離されながら、構成における対称性が実現されます。さらに、バックアップと障害時リカバリが容易になります。ドキュメントの残りの部分では、このディレクトリ構造とディレクトリ用語が使用されます。
この項の項目は次のとおりです。
ORACLE_BASE: この環境変数と関連ディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指しています。
MW_HOME: この環境変数と関連ディレクトリ・パスは、Fusion Middleware（FMW）が存在する場所を指しています。
WL_HOME: この環境変数と関連ディレクトリ・パスには、WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。
ORACLE_HOME: この環境変数と関連ディレクトリ・パスは、Oracle FMW SOA Suiteがインストールされている場所を指しています。
DOMAIN Directory: このディレクトリ・パスは、Oracle WebLogicドメイン情報（構成アーティファクト）が格納されている場所を指しています。次に説明しているように同じノードに存在している場合でも、異なるWLS Serverでは異なるドメイン・ディレクトリを使用できます。
ORACLE_INSTANCE: Oracleインスタンスには、1つ以上のシステム・コンポーネントがあります。コンポーネントの例には、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoyなどがあります。Oracleインスタンスのディレクトリには、更新可能なファイルがあります。それらのファイルの例には、構成ファイル、ログ・ファイル、一時ファイルなどがあります。
Oracle Fusion Middleware 11gでは、単一のバイナリ・インストールから複数のSOAサーバーを作成できます。これによって、共有記憶域上にある単一の場所においてバイナリ・インストールが可能になるだけでなく、異なるノードにおいてサーバーによりこのインストールの再利用も可能になります。ただし、可用性を最大限にするには、冗長バイナリ・インストールの使用をお薦めします。EDGモデルでは、2つのMW HOME（それぞれには、製品スイートごとにORACLE_HOMEとWL_HOMEがあります）が共有記憶域にインストールされます。さらに同じタイプのサーバーを追加する場合（スケールアウトまたはスケールアップ）、これらの2つの場所のどちらかを使用できます。その際、さらにインストールする必要はありません。理想的には、冗長バイナリの場所ではユーザーは別々のボリュームを2つ（次においてそれぞれVOL1とVOL2と呼ばれています）使用する必要があります。これによって、可能なかぎり障害が各ボリュームで隔離されます。さらに保護を強化するために、これらのボリュームではディスクのミラー化をお薦めします。複数のボリュームが利用できない場合、共有記憶域上の異なるディレクトリで同じマウント場所をシミュレートするマウント・ポイントを使用することをお薦めします。複数のボリュームによって実現する保護がこれによって保証されませんが、ユーザーによる削除や個々のファイルの破損から保護できます。
異なるノードで複数のサーバーによりORACLE_HOMEやWL_HOMEが共有されている場合、インストール作業やパッチ適用作業において整合性を保ちながら更新されるこれらのノードにおいて、Oracleインベントリとミドルウェア・ホームの一覧を保持することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールをアタッチするには、ORACLE_HOME/oui/bin/attachHome.shを使用します。ミドルウェア・ホーム・リストでWL_HOMEを追加または削除するには、<user_home>/bea/beahomelistファイルを編集します。これは、このEDGで使用される2つのノードに追加インストールされるノードで必要になります。oraInventoryとbeahomelistを更新する例が、このガイドに記載されているスケールアウト手順で用意されています。
また、管理サーバーで使用されるドメイン・ディレクトリと管理対象サーバーで使用されるドメイン・ディレクトリを別々にすることもお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成ができ、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、共有記憶域に配置する必要があります。これによって、同じ構成の別のノードに対してフェイルオーバーを実行できます。管理対象サーバーのドメイン・ディレクトリは、ローカルの記憶域にも共有記憶域にも配置できます。
異なるノードですべての管理対象サーバー用の共有ドメイン・ディレクトリを使用できますし、ノードごとにドメイン・ディレクトリを1つ使用することもできます。管理対象サーバーのドメイン・ディレクトリを共有すると、スケールアウト手順が容易になります。この場合、ストレージ・システムの要件があればデプロイメントではその要件に適合する必要があります。これによって、複数のマシンで同じ共有ボリュームのマウントが容易になります。
複数のローカル・ドメインに適用される手順はすべて、単一の共有ドメインに適用されます。したがって、ノードごとにドメイン・ディレクトリが1つ使用されるモデルが、このエンタープライズ・デプロイメント・ガイドで使用されています。ディレクトリは、ローカルまたは共有記憶域に配置できます。
サーバーの障害や移行の場合にリカバリで複数のボックスを利用可能にするには、JMSファイル・ストアとJTAトランザクション・ログは共有記憶域に配置する必要があります。
前述の前提条件に基づいて、次に示す各項目では推奨ディレクトリについて説明します。共有記憶域の場所が直接指定されている場合は必ず、そのディレクトリでは共有記憶域が必要とされることを意味します。ローカル・ディスクが使用されたり共有記憶域がオプションの場合、マウント指定では「共有記憶域を使用している場合」の語句で修飾されます。共有記憶域の場所は例であり、指定されたマウント・ポイントが使用されているかぎり変更できます。ただし、共有記憶域デバイスのこの構造を整合性のある状態に維持して単純にすることをお薦めします。
ORACLE_BASE:
/u01/app/oracle
MW_HOME（アプリケーション層）:
ORACLE_BASE/product/fmw
マウント・ポイント: ORACLE_BASE/product/fmw
共有記憶域の場所: ORACLE_BASE/product/fmw（VOL1とVOL2）
MW_HOME（Web層）:
ORACLE_BASE/product/fmw/web
マウント・ポイント: ORACLE_BASE/product/fmw
共有記憶域の場所: ORACLE_BASE/product/fmw（VOL1とVOL2）
WL_HOME:
MW_HOME/wlserver_10.3
ORACLE_HOME:
MW_HOME/soa
ORACLE_INSTANCE:
ORACLE_BASE/admin/<instance_name>
共有記憶域を使用している場合、マシンのマウント・ポイントは、ORACLE_BASE/admin/<instance_name>にマウントされたORACLE_BASE/admin/<instance_name>です（VOL1）。
|
注意: (VOL1)はオプションです。(VOL2)も使用できます。 |
管理ディレクトリのドメイン・ディレクトリ:
ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>（最後の"domain_name"は、構成ウィザードで追加されます）
マシンのマウント・ポイント: ORACLE_BASE/admin/<domain_name>/aserver
共有記憶域の場所: ORACLE_BASE/admin/<instance_name>
管理対象サーバー・ディレクトリのドメイン・ディレクトリ:
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>
共有記憶域を使用している場合、マシンのマウント・ポイントは、/ORACLE_BASE/admin /<domain_name>/Noden/mserver/にマウントされたORACLE_BASE/admin/<domain_name>/mserverです（各ノードでは管理対象サーバー用に異なるドメイン・ディレクトリが使用されます）。
|
注意: この手順は実際、共有記憶域によって異なります。前述の例はNASに特有ですが、他の記憶域タイプでは別のタイプのマッピングによりこの冗長性が実現される場合があります。 |
JMSファイルベース・ストアとTlogs用の場所（SOAのみ）:
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/jms
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/tlogs
マウント・ポイント: ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/
共有記憶域の場所: ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/
アプリケーション・ディレクトリの場所:
ORACLE_BASE/admin/<domain_name>/apps
マウント・ポイント: ORACLE_BASE/admin/<domain_name>/apps
共有記憶域の場所: ORACLE_BASE/admin/<domain_name>/apps（VOL1とVOL2）
図2-2は、このディレクトリ構造を示した図です。
表2-4は、図において様々な色で識別されている要素の意味に関する説明が記載されています。
表2-4 ディレクトリ構造要素
| 要素 | 説明 |
|---|---|
|
|
管理サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体は共有ディスク上に配置されます。 |
|
|
管理対象サーバーのドメイン・ディレクトリは、ローカルのディスクにも共有ディスクにも配置できます。さらに、管理対象サーバーのドメイン・ディレクトリを複数のノードで共有する場合、ノード全体において共有ディスクの同じ場所をマウントする必要があります。Web層の |
|
|
固定名です。 |
|
|
インストール依存名です。 |
図2-3は、SOA用に複数のボリュームを持つ共有記憶域の構成例を示しています。BAMデプロイメントの場合、同じ構造によりこれを類推することができます。
表2-5は、ドメインのディレクトリ構造をまとめたものです。
表2-5 共有記憶域の内容
| サーバー | データのタイプ | 共有記憶域のボリューム | ディレクトリ | ファイル |
|---|---|---|---|---|
|
WLS_SOA1 |
Txログ |
VOL1 |
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/tlogs |
トランザクション・ディレクトリは共通（WebLogic Serverにより決定）ですが、ファイルは別々です。 |
|
WLS_SOA2 |
Txログ |
VOL1 |
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/tlogs |
トランザクション・ディレクトリは共通（WebLogic Serverにより決定）ですが、ファイルは別々です。 |
|
WLS_SOA1 |
JMSストア |
VOL1 |
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/jms |
トランザクション・ディレクトリは共通（WebLogic Serverにより決定）ですが、ファイルは別々です。たとえば、SOAJMSStore1やUMSJMSStore1などです。 |
|
WLS_SOA2 |
JMSストア |
VOL1 |
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/jms |
トランザクション・ディレクトリは共通（WebLogic Serverにより決定）ですが、ファイルは別々です。たとえば、SOAJMSStore2やUMSJMSStore2などです。 |
|
WLS_SOA1 |
WLSインストール |
VOL1 |
ORACLE_BASE/product/fmw |
各ボリューム内で個別のファイル（ただし、両方のサーバーからは同じディレクトリ構造に見える） |
|
WLS_SOA2 |
WLSインストール |
VOL2 |
ORACLE_BASE/product/fmw |
各ボリューム内で個別のファイル（ただし、両方のサーバーからは同じディレクトリ構造に見える） |
|
WLS_SOA1 |
SOAインストール |
VOL1 |
ORACLE_BASE/product/fmw/soa |
各ボリューム内で個別のファイル（ただし、両方のサーバーからは同じディレクトリ構造に見える） |
|
WLS_SOA2 |
SOAインストール |
VOL2 |
ORACLE_BASE/product/fmw/soa |
各ボリューム内で個別のファイル（ただし、両方のサーバーからは同じディレクトリ構造に見える） |
|
WLS_SOA1 |
ドメイン構成 |
VOL1 |
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> |
各ボリューム内で個別のファイル（ただし、両方のサーバーからは同じディレクトリ構造に見える） |
|
WLS_SOA2 |
ドメイン構成 |
VOL2 |
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> |
各ボリューム内で個別のファイル（ただし、両方のサーバーからは同じディレクトリ構造に見える） |
次の手順は、共有記憶域の場所を作成してマウントする方法を示しています。この手順によって、SOAHOST1とSOAHOST2が2つの別々のボリュームのバイナリ・インストール用に同じ場所を参照できるようになります。
nasfilerは共有記憶域ファイラです。
SOAHOST1で次のコマンドを実行します。
SOAHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/product/fmw/u01/app/oracle/product/fmw -t nfs
SOAHOST2で次のコマンドを実行します。
SOAHOST2> mount nasfiler:/vol/vol2/u01/app/oracle/product/fmw/u01/app/oracle/product/fmw -t nfs
利用できるボリュームが1つのみの場合、ユーザーは共有記憶域で別々のディレクトリを2つ使用して、それらをSOAサーバーの同じディレクトリにマウントすることで、バイナリの冗長性を実現できます。
SOAHOST1で次のコマンドを実行します。
SOAHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/product/fmw1 u01/app/oracle/product/fmw -t nfs
SOAHOST2で次のコマンドを実行します。
SOAHOST2> mount nasfiler:/vol/vol2/u01/app/oracle/product/fmw2u01/app/oracle/product/fmw -t nfs
次のコマンドは、異なるノード間においてSOA TXログを共有する方法を示します。
SOAHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/stores/soadomain/soa_cluster/tlogs/u01/app/oracle/stores/soadomain/soa_cluster/tlogs -t nfs
SOAHOST2> nasfiler:/vol/vol1/u01/app/oracle/stores/soadomain/soa_cluster/tlogs /u01/app/oracle/stores/soadomain/soa_cluster/tlogs -t nfs
|
注意: 共有記憶域には、NASデバイスまたはSANデバイスを使用できます。次は、NASデバイスの記憶域をSOAHOST1から作成する例を示しています。オプションは異なる場合があります。SOAHOST1> mount nasfiler:/vol/vol1/fmw11shared ORACLE_BASE/wls -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768 使用する環境に適切なオプションについては、ストレージ・ベンダーとマシン管理者と相談してください。 |
