| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-01 |
|
前 |
次 |
この章では、Oracle Business Intelligenceのエンタープライズ・トポロジで必要となるデータベースおよびネットワーク環境の事前構成、および共有記憶域とディレクトリ構造に対する推奨事項について説明します。
|
重要: セットアップのプロセスを開始する前に、『Oracle Fusion Middlewareリリース・ノート』に目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。 |
この章の内容は次のとおりです。
Oracle Fusion Middlewareコンポーネントを構成する前に、データベースをインストールしてからそこにOracle Business Intelligenceスキーマをロードする必要があります。Oracle Business Intelligenceスキーマは、リポジトリ作成ユーティリティ(RCU)を使用してロードします。
エンタープライズ・トポロジでのデータ層の可用性の向上には、Oracle Real Application Clusters(Oracle RAC)データベースを強くお薦めします。Oracle Business Intelligenceをインストールすると、インストーラによって必要なスキーマを含むデータベースに接続するための情報の入力が求められます。
この項の内容は次のとおりです。
データベースにOracle Business Intelligenceスキーマをロードする前に、そのデータベースが次の項で説明する要件を満たしていることを確認してください。
データ層内のCUSTDBHOST1およびCUSTDBHOST2には、次の要件があります。
Oracle Clusterware
Linux用11g リリース1(11.1)については、Oracle Clusterwareインストレーション・ガイドfor Linuxを参照してください。
Oracle Real Application Cluster
Linux用11g リリース1(11.1)については、Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIXを参照してください。Linux用10g リリース2(10.2)については、Oracle Database Oracle ClusterwareおよびOracle Real Application Clusterインストレーション・ガイドfor Linuxを参照してください。
自動ストレージ管理 (オプション)
ASMでは、ノードが全体としてインストールされます。OracleデータベースのOracleホームとは別のOracleホームにインストールすることをお薦めします。このオプションは、runInstallerの実行時に選択できます。「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択し、ASM用に個別のOracleホームを作成します。
Oracle Business Intelligenceには、サポートされているデータベースとスキーマが存在する必要があります。使用しているデータベースが認証済かどうかの確認、または認証済のすべてのデータベースの確認を行うには、次のOracle Technology NetworkのOracle Fusion Middlewareのサポートされているシステム構成のページにあるOracle Fusion Middleware 11gリリース1(11.1.1.x)の製品領域を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
データベースのリリースをチェックするには、次のようにPRODUCT_COMPONENT_VERSIONビューに問い合せます。
|
注意: Oracle Business Intelligenceでサポートされるデータベース(Oracle Database 10gまたは11g)として使用するデータベースでは、AL32UTF8の文字セットをサポートしている必要があります。データベースの文字セットの選択に関する情報は、データベースのドキュメントを確認してください。 |
Oracle Enterprise Managerのクラスタ管理サービスページを使用して、クライアント・アプリケーションがデータベースへの接続に使用するデータベース・サービスを作成することをお薦めします。データベース・サービスの作成手順の詳細は、Oracle Database Oracle ClusterwareおよびOracle Real Application Clusters管理およびデプロイメント・ガイドのワークロード管理に関する章を参照してください。
また、データベースは次のようにSQL*Plusを使用して構成することもできます。
CREATE_SERVICEサブプログラムを使用し、biedg.mycompany.comデータベース・サービスを作成します。SYSDBAユーザーとしてSQL*Plusにログオンし、次のコマンドを実行します。
SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE (SERVICE_NAME => 'biedg.mycompany.com', NETWORK_NAME => 'biedg.mycompany.com');
データベースにサービスを追加し、これをsrvctlを使用してインスタンスに割り当てます。
prompt> srvctl add service -d custdb -s biedg -r custdb1,custdb2
srvctlを使用してサービスを開始します。
prompt> srvctl start service -d custdb -s biedg
|
注意: SRVCTLコマンドの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。 |
同じデータベースを共有する場合でも、特定のデータベース・サービスを製品スイート用に使用することをお薦めします。また、使用されるデータベース・サービスはデフォルトのデータベース・サービスとは別のものをお薦めします。この場合、データベースはcustdb.mycompany.comになり、デフォルトのサービスは同じ名前のものになります。biedg.mycompany.comサービスを使用するようにOracle Business Intelligenceインストーラは構成されます。
次の手順を実行して、データベースにOracle Business Intelligenceスキーマをロードします。
リポジトリ作成ユーティリティ(RCU)のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。
prompt> cd RCU_HOME/bin
prompt> ./rcu
「ようこそ」画面で、「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。
「データベース接続の詳細」画面で、次のデータベース接続情報を入力します。
データベース・タイプ: 「Oracle Database」を選択します。
ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合は、VIP名またはノード名のいずれかをホスト名(CUSTDBHOST1-VIP)として指定します。
ポート: データベースのリスニング・ポート番号である1521を指定します。
サービス名: データベースのサービス名を指定します(biedg.mycompany.com)。
ユーザー名: DBA権限またはSYSDBA権限のあるユーザーの名前(SYS)を指定します。
パスワード: SYSユーザーのパスワードを入力します。
ロール: データベース・ユーザーのロール(SYSDBA)をリストで選択します(SYSユーザーに必要)。
「次へ」をクリックします。
「接頭辞の新規作成」を選択し、データベース・スキーマに使用する接頭辞を入力します(DEV、PRODなど)。6文字まで接頭辞として指定できます。接頭辞は、データベースで複数のリポジトリの論理グループを作成するために使用されます。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
|
ヒント: スキーマ名を書き留めておきます。この情報は後続の手順で必要になります。 |
AS共通スキーマ: Metadata Services(自動選択されます)
Oracle Business Intelligence: Business Intelligenceプラットフォーム
「次へ」をクリックします。
図2-1に「コンポーネントの選択」画面を示します。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択できます。
「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。
|
ヒント: スキーマ・パスワードの名前を書き留めておきます。この情報は後続の手順で必要になります。 |
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択し、「次へ」をクリックします。
「サマリー」画面で、「作成」をクリックします。
「完了サマリー」画面で、「閉じる」をクリックします。
|
注意: Oracle WSMポリシーを格納するには、アイデンティティ管理用のデータベースを使用することをお薦めします(第9章「Oracle Identity Managementとの統合」を参照)。そのため、OWSM MDSスキーマのアイデンティティ管理データベース情報が使用されることが予想されます。これは、その他のBIスキーマで使用されるものとは異なります。アイデンティティ管理データベースで必要なスキーマを作成するには、アイデンティティ管理データベース情報を使用して前述の手順を繰り返します。ただし、(ステップ5の)「コンポーネントの選択」画面では「AS共通スキーマ」: 「Metadata Services」のみを選択します。 |
データベースにOracle Business Intelligenceスキーマをロードしたら、バックアップを作成します。
データベースをバックアップすると、今後の手順で問題が発生した場合に迅速にリカバリできます。この目的のためにデータベースのバックアップ計画を使用することも、オペレーティング・システムのツールやOracle Recovery Manager(RMAN)を使用して単純にバックアップすることもできます。データベース用にRMANを使用することをお薦めします(特に、Oracle ASMを使用してデータベースを作成した場合)。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。
Oracle Business Intelligenceを実行する計画のあるすべてのコンピュータで、完全修飾ドメイン名を使用してクラスタのプライマリ・ホスト・コンピュータにアクセス(ping)できることを確認する必要があります。インストールが成功するには、インストールをスケール・アウトするすべてのコンピュータが、クラスタのプライマリ・ホスト上の管理サーバーとの双方向通信をサポートできる必要があります。
この項の内容は次のとおりです。
BIエンタープライズ・トポロジでは、次の仮想サーバー名を使用します。
bi.mycompany.com
admin.mycompany.com
biinternal.mycompany.com
仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するノードは、これらの仮想サーバー名を解決できるようになっている必要があります。
bi.mycompany.comは、ランタイムOracle BIコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。SSLへのトラフィックが構成されます。クライアントはbi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサで定義されます。
admin.mycompany.comは、Oracle WebLogic管理サーバー・コンソールやOracle Enterprise Managerなどの管理サービスに転送されるすべての内部HTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。
クライアントからの受信トラフィックは、SSL対応ではありません。クライアントはadmin.mycompany.com:80のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。この仮想サーバーは、ロード・バランサで定義されます。
このエンタープライズ・トポロジでは外部のロード・バランサを使用します。ロード・バランサの詳細は、第4章「Web層の構成」を参照してください。
|
注意: 検証済のロード・バランサのリストおよびその構成は、Oracle Technology Network(http://www.oracle.com/technology)に記載されています。
|
次の手順を実行して、ロード・バランサを構成します。
サーバーのプールを作成します。このプールを仮想サーバーに割り当てます。
Oracle HTTP Serverホストのアドレスをプールに追加します。例:
WEBHOST1:7777
WEBHOST2:7777
bi.mycompany.com:443用のロード・バランサで仮想サーバーを構成します。
この仮想サーバーでは、システムのフロントエンド・アドレスを仮想サーバーのアドレス(たとえば、bi.mycompany.com)として使用します。フロントエンド・アドレスは、システムで使用され外部に公開されているホスト名であり、インターネットに公開されます。
ポート80とポート443でこの仮想サーバー名を構成します。ポート80に入力するリクエストはすべて、ポート443にリダイレクトされる必要があります。
HTTPをプロトコルとして指定します。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
ステップ1で作成したプールを仮想サーバーに割り当てます。
この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。
admin.mycompany.com:80用のロード・バランサで仮想サーバーを構成します。
この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス(たとえば、admin.mycompany.com)として使用します。このアドレスは一般的に外部化されません。
HTTPをプロトコルとして指定します。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
必要に応じて、この仮想サーバーの/consoleと/emのみへのアクセスを許可するルールを作成します。
ステップ1で作成したプールを仮想サーバーに割り当てます。
biinternal.mycompany.com:80用のロード・バランサで仮想サーバーを構成します。
この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス(たとえば、biinternal.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秒で試してみることができます。
タイムアウト時間については、使用するBIシステムで予測できる最長レスポンス時間の説明として妥当な値を指定します。つまり、HTTPサーバーのリクエスト処理における最長所要時間より大きな値を指定します。
表2-1に、様々な仮想ホストの説明を示します。
表2-1 仮想ホスト
| 仮想IP | VIPのマップ先 | 説明 |
|---|---|---|
|
VIP1 |
ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名です。管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバーのプロセスが実行されているノード(デフォルトはAPPHOST1)で有効にされます。 |
|
|
VIP2 |
APPHOST1VHN1は、bi_server1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、bi_server1プロセスが実行されているノード(デフォルトはAPPHOST1)で有効化されます。 |
|
|
VIP3 |
APPHOST2VHN1は、bi_server2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、bi_server2プロセスが実行されているノード(デフォルトはAPPHOST2)で有効化されます。 |
BIドメインでは、Oracle Business Intelligenceの管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。これらのホスト名を2つのBIコンピュータ(APPHOST1のVIP2とAPPHOST2のVIP3)にマップしてVIPを有効にし、トポロジで使用するネットワーク・システムの仮想ホスト名に(DNSサーバーまたはホスト解決によって)正しく解決される必要があります。
管理対象サーバーで仮想IPアドレスをリスニングするよう構成する前に、管理対象サーバーを実行しているホスト上のネットワーク・インタフェース・カードのいずれかを、この仮想IPアドレスをリスニングするように構成する必要があります。
適切な仮想IPアドレス(APPHOST1のVIP2およびAPPHOST2のVIP3)が有効になるよう、各ホストで1回ずつ次の手順を実行します。UNIX環境では、コマンドはrootユーザーとして実行する必要があります。
適切なホスト(APPHOST1でまたはAPPHOST2)でifconfigコマンドを実行し、ネットマスクの値を取得します。UNIX環境では、rootユーザーとしてこのコマンドを実行します。たとえば、APPHOST1で次を行います:
[root@APPHOST1 ~] # /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:11:43:D7:5B:06
inet addr:139.185.140.51 Bcast:139.185.140.255 Mask:255.255.255.0
inet6 addr: fe80::211:43ff:fed7:5b06/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10626133 errors:0 dropped:0 overruns:0 frame:0
TX packets:10951629 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4036851474 (3.7 GiB) TX bytes:2770209798 (2.5 GiB)
Base address:0xecc0 Memory:dfae0000-dfb00000
ifconfigを使用し、仮想IPアドレスをネットワーク・インタフェース・カードにバインドします。UNIX環境ではこのコマンドをrootユーザーとして実行します。ステップ1で取得したネットマスク値を使用します。
ifconfigコマンドの構文および用法は次のとおりです。
/sbin/ifconfig networkCardInterface Virtual_IP_Address netmask netMask
例:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
arpingを使用し、ルーティング表を更新します。UNIX環境では、このコマンドをrootユーザーとして実行します。
/sbin/arping -q -U -c 3 -I networkCardInterface Virtual_IP_Address
例:
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
APPHOST1の管理サーバーでのVIP1の有効化の詳細は、第5.5.1項「APPHOST1上のADMINVHNの有効化」を参照してください。
多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにする必要があります。
ほとんどのポート番号はインストール中に割り当てられます。
表2-2にはOracle BIトポロジで使用されるポートのリストが記載されています。トポロジにあるファイアウォールで開く必要のあるポートも記載されています。
ファイアウォール表記法:
FW0は外側のファイアウォールを示します。
FW1は、Web層とアプリケーション層との間におけるファイアウォールを示します。
FW2は、アプリケーション層とデータ層との間におけるファイアウォールを示します。
表2-2 使用されるポート
| タイプ | ファイアウォール | ポートとポート範囲 | プロトコル/アプリケーション | インバウンド/アウトバウンド | その他の考慮事項とタイムアウトのガイドライン |
|---|---|---|---|---|---|
|
ブラウザによるリクエスト |
FW0 |
80 |
HTTP/ロード・バランサ |
インバウンド |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
ブラウザによるリクエスト |
FW0 |
443 |
HTTPS/ロード・バランサ |
インバウンド |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
なし |
7777 |
HTTP |
なし |
第2.2.2項「ロード・バランサ」を参照してください。 |
|
|
管理サーバーへのOracle HTTP Serverの登録 |
FW1 |
7001 |
HTTP/t3 |
インバウンド |
タイムアウトを短い時間(5から10秒)に設定します。 |
|
管理サーバーによるOracle HTTP Serverの管理 |
FW1 |
OPMNポート(6701)およびOracle HTTP Server管理ポート(7779) |
それぞれTCPとHTTP |
アウトバウンド |
タイムアウトを短い時間(5から10秒)に設定します。 |
|
FW1 |
9704 |
HTTP/bi_servern |
インバウンド |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプによって異なります。 |
|
|
BIクラスタ・メンバー間の通信 |
なし |
9704 |
TCP/IPユニキャスト |
なし |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
WebLogic Serverクラスタ内におけるセッション・レプリケーション |
なし |
なし |
なし |
なし |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
FW1 |
7001 |
HTTP/管理サーバーとEnterprise Manager |
両方 |
管理コンソールへのアクセスのタイプ(アプリケーション層のクライアントから管理コンソールを使用する予定があるか、またはアプリケーション層の外部のクライアントから使用する予定があるか)に基づいてこのタイムアウト時間をチューニングする必要があります。 |
|
|
なし |
9556 |
TCP/IP |
なし |
なし 実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートの構成に関する項を参照してください。 |
|
|
アクセス・サーバーのアクセス |
FW1 |
6021 |
OAP |
インバウンド |
実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートの構成に関する項を参照してください。 |
|
アイデンティティ・サーバーのアクセス |
FW1 |
6022 |
OAP |
インバウンド |
なし |
|
BI ServerおよびBI PublisherのJDBCデータ・ソース用のデータベース・アクセス |
FW1 |
クライアントがリスナーに接続するためのリスニング・ポート |
SQL*Net |
両方 |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテキストによって異なります。 |
|
FW2 |
1521 |
SQL*Net |
両方 |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテキストによって異なります。 |
|
|
Oracle Internet Directoryのアクセス |
FW2 |
389 |
LDAP |
インバウンド |
ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。 |
|
Oracle Internet Directoryのアクセス |
FW2 |
636 |
LDAP SSL |
インバウンド |
ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。 |
|
OWSM用JOC |
なし |
9991 |
TCP/IP |
なし |
なし |
|
注意: ファイアウォール・ポートはTCP/IPポートの定義によって異なります。 |
この項では、このガイドの参照エンタープライズ・デプロイメント・トポロジにお薦めするディレクトリとディレクトリ構造について詳しく説明します。他のディレクトリ・レイアウトも可能でサポートされていますが、このガイドで採用されているモデルは、可用性を最大にするために選択されました。これによって、コンポーネントが適切に分離されながら、構成における対称性が実現されます。さらに、バックアップと障害時リカバリが容易になります。ドキュメントの残りの部分では、このディレクトリ構造とディレクトリ用語が使用されます。
この項の内容は次のとおりです。
このエンタープライズ・デプロイメント・ガイドでは、次のディレクトリの場所への参照を使用します。
ORACLE_BASE: この環境変数と関連ディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指しています。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが常駐している場所を指しています。
WL_HOME: この環境変数および関連ディレクトリ・パスには、Oracle WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。
ORACLE_HOME: この環境変数および関連ディレクトリ・パスは、Oracle Business Intelligenceを実行するために必要なバイナリがインストールされているディレクトリを指しています。
ORACLE_COMMON_HOME: この環境変数および関連ディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリ・ファイルとライブラリ・ファイルを含むOracleホームを指しています。
DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指しています。同じノードに存在している場合でも、異なるWLSサーバーでは異なるドメイン・ディレクトリを使用できます。
ORACLE_INSTANCE: Oracleインスタンス・ディレクトリには、1つ以上のOracleシステム・コンポーネントの構成ファイル、ログ・ファイル、一時ファイルがあります。コンポーネントの例には、Oracle BI Server、Oracle BI Presentation Services、Oracle HTTP Serverなどがあります。
|
ヒント: この項で説明している場所には、ショートカットとして環境変数を使用し、ディレクトリに簡単に移動できます。たとえば、Linuxでは$ORACLE_BASEという環境変数を使用し、/u01/app/oracle(つまり、推奨されるORACLE_BASEの場所)を参照できます。Windowsでは、%ORACLE_BASE%とWindowsに固有のコマンドを使用できます。 |
Oracle Business Intelligence 11gでは、単一バイナリ・インストールからの複数のプロセス(管理対象サーバー、BIサーバー、プレゼンテーション・サービス・サーバーなど)のデプロイメントとインスタンス化をサポートしています。この機能により、パッチ適用、アップグレード、テストから本番への移行などのライフサイクル操作のほか、Oracle Business Intelligenceのデプロイメントのスケール・アウト処理が簡略化されます。ただし、可用性を最大限にするには、冗長バイナリ・インストールの使用をお薦めします。EDGモデルでは、2つのOracle Fusion Middlewareホーム(MW_HOME) - それぞれが製品スイートごとにWL_HOMEとORACLE_HOMEを持ちます - が、共有記憶域にインストールされます。(スケール・アウトまたはスケール・アップの際の)同じタイプの追加サーバーは、さらなるインストールをしなくてもこれらの2つの場所のどちらかを使用できます。理想的には、ユーザーは冗長バイナリの場所として2つの異なるボリューム(後続の説明では、それぞれVOL1、VOL2と呼びます)を使用する必要があり、そうすることによって、各ボリュームでの障害が可能なかぎり隔離されます。さらに保護を強化するために、これらのボリュームでディスクをミラー化することをお薦めします。複数ボリュームが利用できない場合は、共有記憶域上の異なるディレクトリで同じマウント場所をシミュレートするマウント・ポイントを使用することをお薦めします。これによって複数ボリュームが提供するような保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護は可能になります。
ORACLE_HOMEまたはWL_HOMEが、異なるコンピュータの複数のサーバーによって共有されている場合、これらのコンピュータのOracleインベントリ(oraInventory)とミドルウェア・ホーム・リストを常に最新の状態にする必要があります。そうすることによって、今後インストールを行うときやパッチを適用するときの整合性が保証されます。コンピュータのoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してミドルウェア・ホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。これは、このEDGで使用されている2つのコンピュータ以外にOracle Business Intelligenceが追加インストールされているすべてのコンピュータで必要です。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリを使用することをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有記憶域に配置する必要があります。管理対象サーバーのドメイン・ディレクトリは、ローカルまたは共有記憶域に配置できます。
異なるコンピュータ上のすべての管理対象サーバーで共有のドメイン・ディレクトリを使用することも、コンピュータごとに1つのドメイン・ディレクトリを使用することもできます。管理対象サーバーがドメイン・ディレクトリを共有すると、スケール・アウト手順が容易になります。この場合、ストレージ・システムの要件があればデプロイメントではその要件に適合する必要があります。これによって、複数のコンピュータで同じ共有ボリュームのマウントが容易になります。
複数のローカル・ドメインに該当するすべての手順は、1つの共有ドメインにも該当します。したがって、このエンタープライズ・デプロイメント・ガイドでは1つのドメイン・ディレクトリが各コンピュータで使用されるモデルを使用しています。このディレクトリは、ローカルにも共有記憶域にも配置できます。前述の前提条件に基づいて、次に示す各項目では推奨のディレクトリについて説明します。共有記憶域の場所が直接指定されている場合は必ず、そのディレクトリでは共有記憶域が必要とされることを意味します。ローカル・ディスクが使用されたり共有記憶域がオプションの場合、マウント指定では「共有記憶域を使用している場合」の語句で修飾されます。共有記憶域の場所は例であり、指定されたマウント・ポイントが使用されているかぎり変更できます。ただし、共有記憶域デバイスでは整合性と単純化のためこの構造をお薦めします。
/u01/app/oracle
ORACLE_BASE/product/fmw
マウント・ポイント: ORACLE_BASE/product/fmw
共有記憶域の場所: ORACLE_BASE/product/fmw(VOL1とVOL2)
マウント元: 少なくとも半分のノードで1つのインストールを使用し、残りの半分で他方のインストールを使用するように、ノードではVOL1とVOL2を互換的にマウントします。Oracle Business IntelligenceのEDGでは、APPHOST1ではVOL1をマウントし、APPHOST2ではVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域の2つの別のディレクトリを互換的にマウントします(つまり、APPHOST1ではORACLE_BASE/product/fmw1、APPHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します)。
|
注意: 共有記憶域に利用できるボリュームが1つしかない場合に、誤ってファイルを削除しないように、あるいはパッチを適用できるように、別のディレクトリを使用して冗長に構成することができます。2つのMW_HOMEを使用できます。その場所は、少なくとも1つはORACLE_BASE/product/fmw1、もう一方はORACLE_BASE/product/fmw2とします。これらのMW_HOMEは、すべてのノードで同じマウント・ポイントにマウントされます。 |
ORACLE_BASE/product/fmw/web
マウント・ポイント: ORACLE_BASE/product/fmw
共有記憶域の場所: ORACLE_BASE/product/fmw(VOL1とVOL2)
マウント元: 共有記憶域へのインストールの場合、少なくとも半分のノードで1つのインストールを使用し、残りの半分で他方のインストールを使用するように、ノードではVOL1とVOL2を互換的にマウントします。BIのEDGでは、WEBHOST1ではVOL1をマウントし、WEBHOST2ではVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域の2つの推奨ディレクトリを互換的にマウントします(つまり、WEBHOST1ではORACLE_BASE/product/fmw1、WEBHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します)。
|
注意: Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用する場合は、層を横断する記憶域デバイスへのアクセスには、適切なセキュリティ制限をかけることを検討してください。 |
MW_HOME/wlserver_10.3
MW_HOME/Oracle_BI1
MW_HOME/oracle_common
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
マウント元: このディレクトリをマウントする必要があるのは、管理サーバーが稼働しているノードのみです。管理サーバーが別のノードに再配置(フェイルオーバー)されたら、そのノードが同じマウント・ポイントで同じ共有記憶域をマウントします。トポロジ内の残りのノードがこの場所をマウントする必要はありません。
ORACLE_BASE/admin/domain_name/mserver/domain_name
共有記憶域を使用している場合、このシステムのマウント・ポイントは、 ORACLE_BASE/admin/domain_name/Noden/mserver/にマウントされたORACLE_BASE/admin/domain_name/mserverです(各ノードでは管理対象サーバー用に異なるドメイン・ディレクトリが使用されます)。
|
注意: この手順は実際、共有記憶域によって異なります。前述の箇条書きの例はNASに特有ですが、他の記憶域タイプでは別のタイプのマッピングによりこの冗長性が実現される場合があります。 |
ORACLE_BASE/admin/domain_name/cluster_name/jms
ORACLE_BASE/admin/domain_name/cluster_name/tlogs
マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name/
共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name/
マウント元: BIコンポーネントが稼働するすべてのノードでは、別のノードへのサーバー移行が発生したときにトランザクション・ログおよびJMSストアを使用できるように、この共有記憶域の場所をマウントする必要があります。
Oracle BI Presentation Catalogの場所:
ORACLE_BASE/admin/domain_name/cluster_name/catalog/customCatalog(ここでcustomCatalogは、カタログ名の例です)
マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name/
共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name/
マウント元: クラスタ内のプレゼンテーション・サービスのインスタンスを含むすべてのノードではこの場所をマウントします(すべてのノードには読取りと書込みの権限が必要です)。
Oracle BI Presentation Catalogは、Fusion Middleware Controlではプレゼンテーション・サービス・リポジトリということを留意してください。
ORACLE_BASE/admin/domain_name/cluster_name/ClusterRPD
マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name/
共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name/
マウント元: クラスタ内のBIサーバーのインスタンスを含むすべてのノードではこの場所をマウントします。マスターBIサーバーは、このディレクトリに対する読取りおよび書込み権限が必要です。その他のすべてのBIサーバーには読取り権限が必要です。
リポジトリ公開ディレクトリは、Fusion Middleware ControlではBIサーバー・リポジトリの共有の場所であることを留意してください。
ORACLE_BASE/admin/domain_name/cluster_name/GlobalCache
マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name/
共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name/
マウント元: クラスタ内のBIサーバーのインスタンスを含むすべてのノードではこの場所をマウントします。マスターBIサーバーは、このディレクトリに対する読取りおよび書込み権限が必要です。その他のすべてのBIサーバーには読取り権限が必要です。
ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/config
マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name/
共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name/
マウント元: クラスタ内のBI Publisherのインスタンスを含むすべてのノードでは、この場所を読取りと書込みの権限付きでマウントします。
BI Publisherスケジューラの一時ディレクトリの場所:
ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/temp
マウント・ポイント: ORACLE_BASE/admin/domain_name/cluster_name/
共有記憶域の場所: ORACLE_BASE/admin/domain_name/cluster_name/
マウント元: クラスタ内のBI Publisherのインスタンスを含むすべてのノードでは、この場所を読取りと書込みの権限付きでマウントします。
ORACLE_BASE/admin/domain_name/aserver/applications
マウント・ポイント: ORACLE_BASE/admin/domain_name/aserver/applications
共有記憶域の場所: ORACLE_BASE/admin/domain_name/aserver
ORACLE_BASE/admin/domain_name/mserver/applications
|
注意: このディレクトリはOracle Business IntelligenceのEDGにおいてローカルです。 |
図2-2に推奨するディレクトリ構造を示します。
図2-2のディレクトリ構造には、oracle_commonなどのその他の必要な内部ディレクトリがないことに留意してください。共有のコンポーネント・ディレクトリも表示されていません。共有ディレクトリの詳細は、第2.3.3項「共有ディレクトリの構成」を参照してください。
表2-3では、図2-2の様々な色付きの要素の意味を説明しています。
表2-3 ディレクトリ構造要素
| 要素 | 説明 |
|---|---|
|
|
管理サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体は共有ディスク上に配置されます。 |
|
|
管理対象サーバーのドメイン・ディレクトリは、ローカルのディスクにも共有ディスクにも配置できます。管理対象サーバーのドメイン・ディレクトリを複数のコンピュータで共有する場合、それらのコンピュータ全体において同じ共有ディスクの場所をマウントする必要があります。Web層のinstance_nameディレクトリは、ローカルのディスクにも共有ディスクにも配置できます。 |
|
|
固定名です。 |
|
|
インストール依存名です。 |
次の手順は、共有記憶域の場所を作成してマウントする方法を示しています。この手順によって、APPHOST1とAPPHOST2が2つの別々のボリュームのバイナリ・インストール用に同じ場所を参照できるようになります。
nasfilerは共有記憶域ファイラです。
APPHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/product/fmw /u01/app/oracle/product/fmw -t nfs
APPHOST2から:
APPHOST2> mount nasfiler:/vol/vol2/u01/app/oracle/product/fmw /u01/app/oracle/product/fmw -t nfs
利用できるボリュームが1つのみの場合、ユーザーは共有記憶域で別々のディレクトリを2つ使用して、それらをAPPHOSTサーバーの同じディレクトリにマウントすることで、バイナリの冗長性を実現できます。
APPHOST1から:
APPHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/product/fmw1 /u01/app/oracle/product/fmw -t nfs
APPHOST2から:
APPHOST2> mount nasfiler:/vol/vol2/u01/app/oracle/product/fmw2 /u01/app/oracle/product/fmw -t nfs
次のコマンドは、異なるノード間においてBI TXログを共有する方法を示します。
APPHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/stores/bifoundation_domain/ bi_cluster/tlogs /u01/app/oracle/stores/bifoundation_domain/ bi_cluster/tlogs -t nfs APHOST2> mount nasfiler:/vol/vol1/u01/app/oracle/stores/bifoundatin_domain/ bi_cluster/tlogs /u01/app/oracle/stores/bifoundation_domain/ bi_cluster/tlogs -t nfs
|
注意: 共有記憶域には、NASデバイスまたはSANデバイスを使用できます。次は、NASデバイスの記憶域をAPPHOST1から作成する例を示しています。オプションは異なる場合があります。
APPHOST1> mount nasfiler:/vol/vol1/fmw11shared ORACLE_BASE/wls -t
nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
使用する環境に適切なオプションについては、ストレージ・ベンダーとコンピュータ管理者と相談してください。 |
通常Windows環境では、共有記憶域は汎用命名規則(UNC)を使用して指定します。UNCは、ローカル・エリア・ネットワーク上のリソースの場所を指定するためのPCにおける形式です。UNCでは、次の形式を使用します。
\\server_name\shared_resource_path_name
また、共有ネットワーク・ファイルにアクセスできるように、Windows環境では名前付きユーザーを使用してOPMNプロセスを実行する必要があります。
名前付きユーザーを使用してOPMNプロセスを実行するには:
「サービス」ダイアログを開きます。たとえば、「スタート」→「プログラム」→「管理ツール」→「サービス」の順に選択します。
「OracleProcessManager_instancen」を右クリックし、「プロパティ」を選択します。
「ログオン」タブを選択します。
「アカウント」を選択し、ユーザー名とパスワードを入力します。
「OK」をクリックします。
