| Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B55899-03 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B55899-03 |
|
前 |
次 |
この章では、SOAエンタープライズ・トポロジで必要なデータベース事前構成とネットワーク環境の事前構成について説明します。この章の項目は次のとおりです。
SOAエンタープライズ・トポロジでは、データベースにはOracle Fusion Middlewareリポジトリが格納されます。これは、様々なOracle Fusion Middlewareコンポーネントによって使用されるスキーマのコレクションです。コンポーネントの例には、SOAコンポーネント、BAMおよびUMSなどがあります。このデータベースはアイデンティティ管理データベースとは別になっています。これは、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 Cluster
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 SOA Suiteでは、サポートされるデータベースおよびスキーマが存在している必要があります。
ご使用のデータベースが動作保証されているかどうかを確認するか、または動作保証されているデータベースをすべて確認するには、動作保証情報のドキュメントに記載されている、動作保証されているデータベースに関する項を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
データベースのリリースをチェックするには、次のようにPRODUCT_COMPONENT_VERSIONビューに問い合わせます。
SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE PRODUCT LIKE 'Oracle%';
|
注意: Oracle SOA Suiteでは、AL32UTF8キャラクタ・セットをサポートするメタデータ(10gまたは11g)を格納するために、データベースを使用する必要があります。データベースのドキュメントを参照して、データベースで選択できるキャラクタ・セットについて調べてください。 |
必要な最小値に次の初期化パラメータが設定されていることを確認してください。これは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を挿入します。
|
注意: データベースのシードに使用するRCUは、SOAのインストールのパッチ・セット・レベルと一致している必要があります。たとえば、SOA Suite PS1 EDGをインストールする場合はRCU PS1を使用します。SOA Suite PS2 EDGをインストールする場合はPS2 RCUを使用する必要があります。 |
binディレクトリでRCUを起動します。
./rcu
「ようこそ」画面で、「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。
「データベース接続の詳細」画面で、次のデータベース接続情報を入力します。
データベース・タイプ: 「Oracle Database」を選択します。
ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名またはノード名のいずれかをホスト名(CUSTDBHOST1-VIP)として指定します。
ポート: データベースのポート番号を入力します(例: 1521)。
サービス名: データベースのサービス名(soaedg.mycompany.com)を入力します。
ユーザー名: SYS
パスワード: SYSユーザーのパスワードを入力します。
ロール: SYSDBA
「次へ」をクリックします。
接続しているデータベースにUTF8以外のCharsetが含まれていることを示す警告メッセージが表示された場合、多言語をサポートするためにこのデータベースを使用すると、データが失われることがあります。多言語をサポートしていない場合は続行できます。サポートしている場合はUTF-8データベースを使用してください。
「無視」または「停止」をクリックします。
「コンポーネントの選択」画面で、次の手順を実行します。
「新しい接頭辞セットの作成」を選択し、データベース・スキーマで使用する接頭辞を入力します(例: DEVまたはPROD)。接頭辞は1つのデータベースに複数のリポジトリの論理的なグループを作成するために使用します。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
|
ヒント: スキーマ名を書き留めておきます。この情報は後続の手順で必要になります。 |
次を選択します。
AS共通スキーマ:
- メタデータ・サービス
SOAインフラストラクチャ:
- SOAおよびBPMインフラストラクチャ
- ユーザー・メッセージング・サービス
- Business Activity Monitoring
「次へ」をクリックします。
「スキーマ・パスワード」画面で、メインおよび追加(補助)スキーマ・ユーザーのパスワードを入力し、「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択し、「次へ」をクリックします。
「サマリー」画面で、「作成」をクリックします。
「完了サマリー」画面で、「閉じる」をクリックします。
|
注意: Oracle WSMポリシーを格納する場合は、アイデンティティ管理データベースを使用することが推奨されます(第11章「Oracle Identity Managementとの統合」を参照)。そのため、OWSM MDSスキーマのIMデータベース接続情報が使用されることが予想されます。これは、その他のSOAスキーマで使用されるものとは異なります。データベースで必要なスキーマを作成するには、IMデータベース情報を使用して前述の手順を繰り返します(RCUを再度実行します)。ただし、ステップ5の「コンポーネントの選択」画面では「AS共通スキーマ: Metadata Services」のみを選択します。 |
Oracle WebLogic Serverトランザクション・マネージャがトランザクションの状態情報を問い合せて、WebLogic Serverコンテナがクラッシュした後の処理中トランザクションのリカバリ時に、commitやrollbackなどの適切なコマンドを発行できるようにするには、適切なデータベース権限が必要です。
トランザクション・リカバリ権限用のSOAスキーマを構成する手順は次のとおりです。
sysdba権限が付与されたユーザーとしてsqlplusにログオンします。例:
sqlplus "/ as sysdba"
次のコマンドを入力します。
SQL> Grant select on sys.dba_pending_transactions to soa_schema_prefix; Grant succeeded. SQL> Grant force any transaction to soa_schema_prefix; Grant succeeded. SQL>
|
注意: これらの権限は、RCU操作で決定されるsoainfraスキーマの所有者に付与する必要があります。 |
メタデータ・リポジトリをデータベースにロードしたら、バックアップする必要があります。
データベースのバックアップは、今後の手順で問題が発生した場合に迅速なリカバリを行うために明示的に行います。この目的のために、データベース用のバックアップ計画を使用したり、オペレーティング・システムのツールや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 |
ADMINVHN |
ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名であり、管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバーのプロセスが実行されているノード(デフォルトはSOAHOST1)で有効にされます。 |
|
VIP2 |
SOAHOST1VHN1 |
SOAHOST1VHN1は、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コンテンツによって異なります。 |
|
ブラウザによるリクエスト |
FW1 |
80 |
HTTPS/ロード・バランサ |
アウトバウンド(イントラネット・クライアント) |
タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
ブラウザによるリクエスト |
FW1 |
443 |
HTTPS/ロード・バランサ |
アウトバウンド(イントラネット・クライアント) |
タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
コールバックおよびアウトバウンド呼出し |
FW1 |
80 |
HTTPS/ロード・バランサ |
アウトバウンド |
タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
コールバックおよびアウトバウンド呼出し |
FW1 |
443 |
HTTPS/ロード・バランサ |
アウトバウンド |
タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
Oracle HTTP Serverへのロード・バランサ |
なし |
7777 |
HTTP |
なし |
第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クラスタ・メンバー間における通信 |
なし |
8001 |
TCP/IPユニキャスト |
なし |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
複数のWSMクラスタ・メンバー間における通信 |
なし |
7010 |
TCP/IPユニキャスト |
なし |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
WebLogic Serverクラスタ内におけるセッション・レプリケーション |
なし |
なし |
なし |
なし |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
管理コンソールのアクセス |
FW1 |
7001 |
HTTP/管理サーバーとEnterprise Manager t3 |
両方 |
管理コンソールへのアクセスのタイプ(アプリケーション層のクライアントからOracle WebLogic Server管理コンソールを使用する予定があるか、またはアプリケーション層の外部のクライアントから使用する予定があるか)に基づいてこのタイムアウト時間をチューニングする必要があります。 |
|
ノード・マネージャ |
なし |
5556 |
TCP/IP |
なし |
なし 実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の「ファイアウォールとポート」を参照してください。 |
|
アクセス・サーバーのアクセス |
FW1 |
6021 |
OAP |
インバウンド |
実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の「ファイアウォールとポート」を参照してください。 |
|
アイデンティティ・サーバーのアクセス |
FW1 |
6022 |
OAP |
インバウンド |
|
|
データベースのアクセス |
FW2 |
1521 |
SQL*Net |
両方 |
タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテキストによって異なります。 |
|
デプロイメントの一貫性 |
なし |
8088 範囲: 8000から8090 |
なし |
なし |
|
|
Oracle Internet Directoryのアクセス |
FW2 |
389 |
LDAP |
インバウンド |
ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。 |
|
Oracle Internet Directoryのアクセス |
FW2 |
636 |
LDAP SSL |
インバウンド |
ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。 |
|
OWSM用JOC |
なし |
9991 |
TCP/IP |
なし |
なし |
|
注意: B2BのTCP/IPポートは、ユーザーが構成するポートであり、事前定義されません。同様に、ファイアウォールのポートは、TCP/IPポートの定義によって異なります。 |
この項では、EDGトポロジ用にお薦めするディレクトリとディレクトリ構造について詳しく説明します。他のディレクトリ・レイアウトも可能でサポートされていますが、このガイドで採用されているモデルは、可用性を最大にするために選択されました。これによって、コンポーネントが適切に分離されながら、構成における対称性が実現されます。さらに、バックアップと障害時リカバリが容易になります。ドキュメントの残りの部分では、このディレクトリ構造とディレクトリ用語が使用されます。
この項の項目は次のとおりです。
ORACLE_BASE: この環境変数と関連ディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指しています。
MW_HOME: この環境変数と関連ディレクトリ・パスは、Fusion Middleware(FMW)が存在する場所を指しています。
WL_HOME: この環境変数と関連ディレクトリ・パスには、WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。
ORACLE_HOME: この環境変数と関連ディレクトリ・パスは、Oracle FMW SOA Suiteがインストールされている場所を指しています。
ORACLE_COMMON_HOME: この環境変数と関連ディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが含まれるOracleホームを指しています。
DOMAINディレクトリ: このディレクトリ・パスは、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)
|
注意: 共有記憶域に利用できるボリュームが1つしかない場合に、誤ってファイルを削除しないように、あるいはパッチを適用できるように、別のディレクトリを使用して冗長に構成することができます。2つのMW_HOMEを使用できます。その場所は、少なくとも1つはORACLE_BASE/product/fmw1、もう一方はORACLE_BASE/product/fmw2とします。これらのMW_HOMEは、すべてのノードで同じマウント・ポイントにマウントされます。 |
マウント元: 少なくとも半分のノードで一方のインストールを使用し、もう半分で他方のインストールを使用できるように、ノードではVOL1とVOL2を互換的にマウントします。
SOAエンタープライズ・デプロイメント・トポロジでは、SOAHOST1でVOL1をマウントし、SOAHOST2でVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域において、考えられる2つのディレクトリを互換的にマウントします。たとえば、SOAHOST1ではORACLE_BASE/product/fmw1、SOAHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します。
MW_HOME(Web層):
ORACLE_BASE/product/fmw/web
マウント・ポイント: ORACLE_BASE/product/fmw
共有記憶域の場所: ORACLE_BASE/product/fmw(VOL1とVOL2)
|
注意: Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用する場合は、層を横断する記憶域デバイスへのアクセスには、適切なセキュリティ制限をかけることを検討してください。このエンタープライズ・デプロイメント・ガイドでは、Oracle Web Tierがローカル・ディスクにインストールされると想定しています。Oracle Web Tierバイナリ(およびORACLE_INSTANCE)は共有ディスクにインストールできます。その場合、共有ディスクはアプリケーション層で使用している共有ディスクとは別にする必要があります。 |
マウント元: 共有記憶域のインストールでは、少なくとも半分のノードで一方のインストールを使用し、もう半分で他方のインストールを使用できるように、ノードではVOL1とVOL2を互換的にマウントします。
SOAエンタープライズ・デプロイメント・トポロジでは、WEBHOST1でVOL1をマウントし、WEBHOST2でVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域において、考えられる2つのディレクトリを互換的にマウントします。たとえば、WEBHOST1ではORACLE_BASE/product/fmw1、WEBHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します。
WL_HOME:
MW_HOME/wlserver_10.3
ORACLE_HOME:
MW_HOME/soa
ORACLE_COMMON_HOME:
MW_HOME/oracle_common
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/domain_name/aserver
マウント元: このディレクトリをマウントする必要があるのは、管理サーバーが稼働しているノードのみです。管理サーバーが別のノードに再配置(フェイルオーバー)されたら、そのノードが同じマウント・ポイントで同じ共有記憶域をマウントします。トポロジ内の残りのノードがこの場所をマウントする必要はありません。
管理対象サーバーのドメイン・ディレクトリ:
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/
マウント元: SOAまたはBAMが稼働するすべてのノードでは、別のノードへのサーバー移行が発生したときにトランザクション・ログおよびJMSストアを使用できるように、この共有記憶域の場所をマウントする必要があります。
管理サーバーのアプリケーション・ディレクトリの場所
ORACLE_BASE/admin/domain_name/aserver/applications
マウント・ポイント: ORACLE_BASE/admin/domain_name/aserver/
共有記憶域の場所: ORACLE_BASE/admin/domain_name/aserver
マウント元: このディレクトリをマウントする必要があるのは、管理サーバーが稼働しているノードのみです。管理サーバーが別のノードに再配置(フェイルオーバー)されたら、そのノードが同じマウント・ポイントで同じ共有記憶域をマウントします。トポロジ内の残りのノードがこの場所をマウントする必要はありません。
管理対象サーバーのアプリケーション・ディレクトリの場所
ORACLE_BASE/admin/domain_name/mserver/applications
|
注意: このディレクトリは、SOAエンタープライズ・デプロイメントではローカルになります。 |
図2-2は、このディレクトリ構造を示した図です。
図2-2のディレクトリ構造には、oracle_commonやjrockitなど、他に必要な内部ディレクトリが示されていません。
表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 |
MW_HOME |
各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます) |
|
WLS_SOA2 |
WLSインストール |
VOL2 |
MW_HOME |
各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます) |
|
WLS_SOA1 |
SOAインストール |
VOL1 |
MW_HOME/soa |
各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます) |
|
WLS_SOA2 |
SOAインストール |
VOL2 |
MW_HOME/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/vol1/u01/app/oracle/product/fmw /u01/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> mount 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 使用する環境に適切なオプションについては、ストレージ・ベンダーとマシン管理者と相談してください。 |
Oracle Fusion Middlewareでは、WebLogicドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、XMLファイルまたは様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインがLDAPストアを使用する場合は、ポリシーと資格証明のデータはすべて、一元化されたストアで保持および保守されます。ただし、XMLポリシー・ストアを使用している場合、管理対象サーバーへの変更は、同じドメイン・ホームを使用していなければ管理サーバーには伝播されません。
第2.3項「共有記憶域と推奨ディレクトリ構造」の説明にあるように、Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジでは、管理サーバーと管理対象サーバーで異なるドメイン・ホームを使用します。この要因に加えて、整合性および一貫性を保持するため、Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジにおいて、ポリシー・ストアおよび資格証明ストアとしてLDAPを使用する必要があります。Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジを、資格証明ストアおよびポリシー・ストアとしてLDAPを使用するように構成するには、第11.1項「資格証明ストアおよびポリシー・ストアの構成」を参照してください。
