Fusion Middleware ディザスタ・リカバリ・ガイド

11g リリース1(11.1.1)

B61394-04(原本部品番号:E15250-05)

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 障害時リカバリの紹介

- 1.1 障害時リカバリの概要

- 1.1.1 問題の説明と一般的なソリューション

- 1.1.2 用語

- 1.2 Oracle Fusion Middlewareコンポーネントの障害時リカバリ

- 1.2.1 Oracle Fusion Middleware障害時リカバリ・アーキテクチャの概要

- 1.2.2 このドキュメントに記述されているコンポーネント

2 Fusion Middlewareコンポーネントに関する推奨事項

- 2.1 Oracle WebLogic Serverに関する推奨事項

- 2.1.1 Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項

- 2.1.2 Oracle Platform Security Servicesに関する推奨事項

- 2.2 Oracle ADFに関する推奨事項

- 2.3 Oracle WebCenter Portalに関する推奨事項

- 2.3.1 Oracle WebCenter Portal: Spacesに関する推奨事項

- 2.3.2 Oracle WebCenter Portalのポートレット・プロデューサに関する推奨事項

- 2.3.3 Oracle WebCenter Portalのディスカッション・サーバーに関する推奨事項

- 2.3.4 Oracle WebCenter Contentサーバーに関する推奨事項

- 2.3.5 Oracle WebCenter PortalのAnalyticsコレクタに関する推奨事項

- 2.3.6 Oracle WebCenter Portalアクティビティ・グラフ・エンジンに関する推奨事項

- 2.4 Oracle SOA Suiteに関する推奨事項

- 2.4.1 Oracle SOA Service Infrastructureに関する推奨事項

- 2.4.2 Oracle BPEL Process Managerに関する推奨事項

- 2.4.3 Oracle Mediatorに関する推奨事項

- 2.4.4 Oracle Human Workflowに関する推奨事項

- 2.4.5 Oracle B2Bに関する推奨事項

- 2.4.6 Oracle Web Services Managerに関する推奨事項

- 2.4.7 Oracle User Messaging Serviceに関する推奨事項

- 2.4.8 Oracle JCA Adaptersに関する推奨事項

- 2.4.9 Oracle Business Activity Monitoringに関する推奨事項

- 2.4.10 Oracle Business Process Managementに関する推奨事項

- 2.5 Oracle Identity Managementに関する推奨事項

- 2.5.1 Oracle Internet Directoryに関する推奨事項

- 2.5.2 Oracle Virtual Directoryに関する推奨事項

- 2.5.3 Oracle Directory Integration Platformに関する推奨事項

- 2.5.4 Oracle Identity Federationに関する推奨事項

- 2.5.5 Oracle Directory Services Managerに関する推奨事項

- 2.5.6 Oracle Access Managerに関する推奨事項

- 2.5.7 Oracle Adaptive Access Managerに関する推奨事項

- 2.5.8 Oracle Identity Managerに関する推奨事項

- 2.5.9 Oracle Identity Navigatorに関する推奨事項

- 2.6 Oracle Portal、Forms、ReportsおよびDiscovererに関する推奨事項

- 2.6.1 Oracle Portalに関する推奨事項

- 2.6.2 Oracle Formsに関する推奨事項

- 2.6.3 Oracle Reportsに関する推奨事項

- 2.6.4 Oracle Business Intelligence Discovererに関する推奨事項

- 2.7 Oracle Web Tierコンポーネントに関する推奨事項

- 2.7.1 Oracle HTTP Serverに関する推奨事項

- 2.7.2 Oracle Web Cacheに関する推奨事項

- 2.8 Oracle WebCenter Contentに関する推奨事項

- 2.8.1 Oracle WebCenter Contentに関する推奨事項

- 2.8.2 Oracle WebCenter Content: Inbound Refineryに関する推奨事項

- 2.8.3 Oracle WebCenter Content: Imagingに関する推奨事項

- 2.8.4 Oracle WebCenter Content: Information Rightsに関する推奨事項

- 2.8.5 Oracle WebCenter Content: Recordsに関する推奨事項

- 2.9 Oracle Business Intelligenceに関する推奨事項

- 2.9.1 Oracle Business Intelligence Enterprise Edition(EE)に関する推奨事項

- 2.9.2 Oracle Business Intelligence Publisherに関する推奨事項

- 2.9.3 Oracle Real-Time Decisionsに関する推奨事項

3 設計上の考慮事項

- 3.1 ネットワークに関する考慮事項

- 3.1.1 ホスト名の計画

- 3.1.1.1 ホスト名の解決

- 3.1.1.2 ローカルでのホスト名の解決

- 3.1.1.3 個別のDNSサーバーを使用したホスト名の解決

- 3.1.1.4 グローバルDNSサーバーを使用したホスト名の解決

- 3.1.1.5 ホスト名解決のテスト

- 3.1.2 仮想IPおよび仮想ホスト名に関する考慮事項

- 3.1.3 ロード・バランサに関する考慮事項

- 3.1.4 仮想サーバーに関する考慮事項

- 3.1.5 ワイド・エリアDNSの操作

- 3.1.5.1 グローバル・ロード・バランサの使用

- 3.1.5.2 DNS名の手動変更

- 3.2 ストレージに関する考慮事項

- 3.2.1 Oracle Fusion Middlewareのアーティファクト

- 3.2.2 OracleホームとOracleインベントリ

- 3.2.3 ストレージ・レプリケーション

- 3.2.4 ファイルベースの永続ストア

- 3.3 データベースに関する考慮事項

- 3.3.1 データベースのTNSNAMES.ORAエントリの作成

- 3.3.2 Oracle Data Guardを使用した手動によるデータベースの強制同期

- 3.3.3 データベース・ホスト名の別名の設定

- 3.4 開始ポイント

- 3.4.1 既存のサイトを基にした設計

- 3.4.1.1 共有ストレージへの既存の本番サイトの移行

- 3.4.2 新しいサイトの設計

- 3.5 トポロジに関する考慮事項

- 3.5.1 対称トポロジの設計に関する考慮事項

- 3.5.2 非対称トポロジの設計に関する考慮事項

4 障害時リカバリ・サイトの設定と管理

- 4.1 サイトの設定

- 4.1.1 ディレクトリ構造とボリューム設計

- 4.1.1.1 Oracle SOA Suiteのディレクトリ構造に関する推奨事項

- 4.1.1.1.1 Oracle SOA Suiteのボリューム設計

- 4.1.1.1.2 Oracle SOA Suiteのコンシステンシー・グループに関する推奨事項

- 4.1.1.2 Oracle WebCenter Portalのディレクトリ構造に関する推奨事項

- 4.1.1.2.1 Oracle WebCenter Portalのボリューム設計

- 4.1.1.2.2 Oracle WebCenter Portalのコンシステンシー・グループに関する推奨事項

- 4.1.1.3 Oracle Identity Managementのディレクトリ構造に関する推奨事項

- 4.1.1.3.1 Oracle Identity Managementのボリューム設計

- 4.1.1.3.2 Oracle Identity Managementのコンシステンシー・グループに関する推奨事項

- 4.1.1.4 Oracle Portal、Forms、ReportsおよびDiscovererのディレクトリ構造に関する推奨事項

- 4.1.1.4.1 Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計

- 4.1.1.4.2 Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループに関する推奨事項

- 4.1.1.5 Oracle WebCenter Contentのディレクトリ構造に関する推奨事項

- 4.1.1.5.1 Oracle WebCenter Contentのボリューム設計

- 4.1.1.5.2 Oracle WebCenter Contentのコンシステンシー・グループに関する推奨事項

- 4.1.1.6 Oracle Business Intelligenceのディレクトリ構造に関する推奨事項

- 4.1.1.6.1 Oracle Business Intelligenceのボリューム設計

- 4.1.1.6.2 Oracle Business Intelligenceのコンシステンシー・グループに関する推奨事項

- 4.1.2 ストレージ・レプリケーション

- 4.1.3 データベース

- 4.1.3.1 Oracle Data Guardの設定

- 4.1.3.1.1 前提条件

- 4.1.3.1.2 Oracle Data Guard環境の説明

- 4.1.3.1.3 ファイルの収集とバックアップの実行

- 4.1.3.1.4 スタンバイ・サイトでのOracle Net Servicesの構成

- 4.1.3.1.5 スタンバイ・サイトでのインスタンスおよびデータベースの作成

- 4.1.3.1.6 データベースのスイッチオーバーおよびスイッチバックのテスト

- 4.1.4 ノード・マネージャ

- 4.1.4.1 自己署名証明書の生成

- 4.1.4.2 IDキーストアの作成

- 4.1.4.3 信頼キーストアの作成

- 4.1.4.4 カスタム・キーストアを使用するためのノード・マネージャの構成

- 4.2 本番サイトの作成

- 4.2.1 Oracle SOA Suiteトポロジの本番サイトの作成

- 4.2.2 Oracle Identity Managementトポロジの本番サイトの作成

- 4.2.3 Oracle WebCenter Portalトポロジの本番サイトの作成

- 4.2.4 Oracle WebCenter Contentトポロジの本番サイトの作成

- 4.2.5 Oracle Business Intelligenceトポロジの本番サイトの作成

- 4.2.6 Oracle Portal、Forms、ReportsおよびDiscovererトポロジの本番サイトの構成

- 4.2.7 本番サイトの設定の検証

- 4.3 スタンバイ・サイトの作成

- 4.3.1 スタンバイ・サイトの作成

- 4.3.1.1 データベースの設定

- 4.3.1.2 中間層の設定

- 4.3.2 スタンバイ・サイトの設定の検証

- 4.4 非対称スタンバイ・サイトの作成

- 4.4.1 非対称スタンバイ・サイトの作成

- 4.4.1.1 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイトの作成

- 4.4.2 非対称スタンバイ・サイトの設定の検証

- 4.5 サイトの操作および管理の実行

- 4.5.1 サイトの同期

- 4.5.2 スイッチオーバーの実行

- 4.5.3 スイッチバックの実行

- 4.5.4 フェイルオーバーの実行

- 4.5.5 スタンバイ・サイトの定期テストの実行

- 4.5.6 テストでのpeer-to-peerファイル・コピーの使用

- 4.5.6.1 Oracle Fusion Middleware障害時リカバリ・トポロジでのrsyncとOracle Data Guardの使用

- 4.5.6.1.1 Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用

- 4.5.6.1.2 フェイルオーバー操作およびスイッチオーバー操作の実行

- 4.6 Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用

5 Oracle Site Guardの使用方法

- 5.1 開始前の重要な注意点

- 5.2 Oracle Site Guardの概要

- 5.2.1 Oracle Site Guardのメリット

- 5.2.2 Oracle Site Guardの操作

- 5.2.3 Enterprise Manager Cloud Controlにおけるサイトの説明

- 5.3 Oracle Site Guardのインストール

- 5.4 前提条件

- 5.4.1 プライマリ・サイトおよびスタンバイ・サイトでのターゲットの検出

- 5.4.2 本番システムとスタンバイ・システムの作成

- 5.4.2.1 Enterprise Manager Cloud Controlコンソールを使用した汎用システムの作成

- 5.4.2.2 EMCLIコマンドを使用した汎用システムの作成

- 5.4.3 Oracle Site Guardの資格証明の作成

- 5.4.4 ソフトウェア・ライブラリの構成

- 5.4.5 カスタム・スクリプトの作成

- 5.4.6 ストレージ・スクリプトの作成

- 5.5 Oracle Site Guardの設定

- 5.5.1 Oracle Site Guard構成の作成

- 5.5.2 サイトの資格証明の関連付け

- 5.5.3 前処理スクリプトおよび後処理スクリプトの関連付け

- 5.5.4 ストレージ・スクリプトの関連付け

- 5.6 操作計画の使用

- 5.6.1 操作計画の作成

- 5.6.2 事前チェック・ユーティリティの実行

- 5.6.3 操作計画の送信

- 5.6.4 操作計画の監視

- 5.7 エラー管理フレームワーク

- 5.7.1 エラー・モード

- 5.7.1.1 エラー・モードの停止

- 5.7.1.2 エラー・モードの継続

- 5.7.2 操作計画でのエラー・モードの更新

- 5.7.3 失敗した操作の再試行

- 5.8 Site Guard構成の管理

- 5.8.1 ホストの追加

- 5.8.2 サイトの停止

- 5.8.3 サイトの起動

- 5.8.4 サイト・スイッチオーバーの実行

- 5.8.5 サイト・フェイルオーバーの実行

- 5.9 サンプル・シナリオ: Oracle BI Enterprise Edition

- 5.9.1 タスク1: Oracle Business Intelligence Enterpriseデプロイメントの設定

- 5.9.2 タスク2: プライマリ・サイトおよびスタンバイ・サイトのターゲットの検出

- 5.9.3 タスク3: Oracle Business Intelligenceの本番システムとスタンバイ・システムの作成

- 5.9.4 タスク4: 資格証明の作成

- 5.9.5 タスク5: Oracle Site Guard構成の作成

- 5.9.6 タスク6: サイトの資格証明の関連付け

- 5.9.7 タスク7: 前処理スクリプトおよび後処理スクリプトの作成

- 5.9.7.1 起動および停止スクリプトの作成

- 5.9.7.2 スイッチオーバーおよびフェイルオーバー・スクリプトの作成

- 5.9.8 タスク8: ストレージ・スクリプトの関連付け

- 5.9.9 タスク9: 操作計画の作成

- 5.9.10 タスク10: BISystem1の起動

- 5.9.11 タスク11: BISystem1の停止

- 5.9.12 タスク12: Oracle Site Guard事前チェック・ユーティリティの実行

- 5.9.13 タスク13: サイト・スイッチオーバーの実行

- 5.9.14 タスク14: サイト・フェイルオーバーの実行

6 障害時リカバリのトラブルシューティング

- 6.1 Oracle Fusion Middleware障害時リカバリ・トポロジのトラブルシューティング

- 6.1.1 本番サイトおよびスタンバイ・サイトのホスト名解決の確認

- 6.1.2 障害時リカバリ・トポロジでのコンポーネントの問題の解決

- 6.1.3 共有ストレージにデプロイされたコンポーネントの問題の解決

- 6.2 追加情報

7 Oracle Site Guardのトラブルシューティング

A Oracleインベントリの管理

- A.1 Oracleインベントリの更新

- A.2 Windowsレジストリの更新

B Oracle Site Guardのサンプル・スクリプト

C Oracle Site Guardコマンドライン・インタフェース・リファレンス

- C.1 add_siteguard_script_hosts

- C.2 create_operation_plan

- C.3 create_siteguard_configuration

- C.4 create_siteguard_credential_association

- C.5 create_siteguard_script

- C.6 delete_operation_plan

- C.7 delete_siteguard_configuration

- C.8 delete_siteguard_credential_association

- C.9 delete_siteguard_script

- C.10 delete_siteguard_script_hosts

- C.11 get_operation_plan_details

- C.12 get_operation_plans

- C.13 get_siteguard_configuration

- C.14 get_siteguard_credential_association

- C.15 get_siteguard_script_hosts

- C.16 get_siteguard_scripts

- C.17 run_prechecks

- C.18 submit_operation_plan

- C.19 update_operation_plan

- C.20 update_siteguard_configuration

- C.21 update_siteguard_credential_association

- C.22 update_siteguard_script

索引

例一覧

- 3-1 ローカルでのホスト名解決を使用する場合の指定

- 3-2 DNSによるホスト名解決を使用する場合の指定

- 3-3 本番サイト・ホストの/etc/hostsファイル・エントリの作成

- 3-4 スタンバイ・サイト・ホストの/etc/hostsファイル・エントリの作成

- 3-5 個別のDNSサーバー構成における本番サイト・ホストのDNSエントリ

- 3-6 個別のDNSサーバー構成におけるスタンバイ・サイト・ホストのDNSエントリ

- 3-7 グローバルDNSサーバー構成を使用する場合の本番サイト・ホストおよびスタンバイ・サイト・ホストのDNSエントリ

- 3-8 グローバルDNSサーバー構成を使用する場合のスタンバイ・サイトの/etc/hostsファイル・エントリ

- 3-9 Oracle Data Guardでのデータベース同期の手動強制

- B-1 Oracle Site Guard構成スクリプト

- B-2 Sun Storage ZFS Storage Applianceのロール・リバース・スクリプト

- B-3 NetAppストレージのロール・リバース・スクリプト

- B-4 akshスクリプト

- C-1 ホストの追加

- C-2 操作計画の作成

- C-3 Site Guard構成の作成

- C-4 Site Guard資格証明アソシエーションの作成

- C-5 Site Guardスクリプトの作成

- C-6 操作計画の削除

- C-7 Site Guard構成の削除

- C-8 Site Guard資格証明アソシエーションの削除

- C-9 Site Guardスクリプトの削除

- C-10 Site Guardスクリプト・ホストの削除

- C-11 操作計画の詳細の取得

- C-12 操作計画の取得

- C-13 Site Guard構成の取得

- C-14 Site Guard資格証明アソシエーションの取得

- C-15 Site Guardスクリプト・ホストの取得

- C-16 Site Guardスクリプトの取得

- C-17 事前チェックの実行

- C-18 操作計画の送信

- C-19 操作計画の更新

- C-20 Site Guard構成の更新

- C-21 Site Guard資格証明アソシエーションの更新

- C-22 Site Guardスクリプトの更新

図一覧

- 1-1 Oracle Fusion Middleware障害時リカバリ・トポロジにおける本番サイトとスタンバイ・サイト

- 3-1 Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトで使用するデプロイメント

- 3-2 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名

- 4-1 SOAのディレクトリ構造

- 4-2 Oracle Access Managerを使用したMySOACompanyトポロジ

- 4-3 Oracle Access ManagerおよびBPMを使用したMySOACompanyトポロジ

- 4-4 Oracle Access Managerを使用したMyWCPCompanyトポロジ

- 4-5 Oracle Identity Managementのディレクトリ構造

- 4-6 Oracle Access Managerを使用したMyIMCompanyトポロジ

- 4-7 Oracle Access ManagerおよびOracle Identity Managerを使用したMyIMCompanyトポロジ

- 4-8 Oracle Adaptive Access Managerを使用したMyIMCompanyトポロジ

- 4-9 Oracle Portalのトポロジ・ダイアグラム

- 4-10 Oracle Forms、ReportsおよびDiscovererのトポロジ

- 4-11 Oracle WebCenter Contentのディレクトリ構造

- 4-12 Oracle WebCenter Contentエンタープライズ・デプロイメントの参照トポロジ

- 4-13 Oracle Business Intelligenceのディレクトリ構造

- 4-14 Oracle Business Intelligenceエンタープライズ・デプロイメントの参照トポロジ

- 4-15 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイト

- 5-1 Enterprise Manager Cloud Controlが管理するOracle Fusion Middleware障害時リカバリ・トポロジにおける本番サイトとスタンバイ・サイト

- 5-2 ステータスの詳細

- 5-3 エラー・モードの停止

- 5-4 エラー・モードの継続

- 5-5 エラー・モードの更新

- 5-6 Oracle Fusion Middlewareターゲット

- 5-7 データベース・ターゲット

- 5-8 本番サイトおよびスタンバイ・サイトの汎用システム

- 5-9 BISystem1に関連付けられた資格証明

- 5-10 BISystem1およびBISystem2の操作計画

- 5-11 ステータスの開始

- 5-12 停止ステータス

- 5-13 事前チェック・ユーティリティ

- 5-14 BISystem1のスイッチオーバー・ステータス

- 5-15 BISystem2のスイッチオーバー・ステータス

- 5-16 更新されたSite Guardステータス

- 5-17 BISystem1のフェイルオーバー・ステータス

- 5-18 BISystem2のフェイルオーバー・ステータス

表一覧

- 2-1 Oracle B2Bによって使用されるJMSキューおよびトピック

- 2-2 Oracle User Messaging Serviceによって使用されるJMSリソース

- 3-1 SOA Suiteの本番サイト・ホストのIPアドレスと物理ホスト名

- 3-2 SOA Suiteのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

- 3-3 Oracle WebCenter Portalの本番サイト・ホストのIPアドレスと物理ホスト名

- 3-4 Oracle WebCenter Portalのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

- 3-5 Identity Managementの本番サイト・ホストのIPアドレスと物理ホスト名

- 3-6 Identity Managementのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

- 3-7 浮動IPアドレス

- 3-8 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストのIPアドレスと物理ホスト名

- 3-9 Oracle Portal、Forms、ReportsおよびDiscovererのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

- 3-10 Oracle WebCenter Contentの本番サイト・ホストのIPアドレスと物理ホスト名

- 3-11 Oracle WebCenter Contentのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

- 3-12 Oracle Business Intelligenceの本番サイト・ホストのIPアドレスと物理ホスト名

- 3-13 Oracle Business Intelligenceのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

- 3-14 SOA Suiteの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

- 3-15 SOA Suiteのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

- 3-16 Oracle WebCenter Portalの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

- 3-17 WebCenterのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

- 3-18 Identity Managementの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

- 3-19 Identity Managementのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

- 3-20 浮動IPアドレス

- 3-21 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

- 3-22 Oracle Portal、Forms、ReportsおよびDiscovererのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

- 3-23 Oracle Enterprise Content Managementの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

- 3-24 Oracle WebCenter Contentのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

- 3-25 Oracle Business Intelligenceの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

- 3-26 Oracle Business Intelligenceのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

- 3-27 Oracle SOA Suiteの本番サイトの仮想サーバー

- 3-28 Oracle SOA Suiteのスタンバイ・サイトの仮想サーバー

- 3-29 Oracle WebCenter Portalの本番サイトの仮想サーバー

- 3-30 Oracle WebCenter Portal Suiteのスタンバイ・サイトの仮想サーバー

- 3-31 Oracle Identity Managementの本番サイトの仮想サーバー

- 3-32 Oracle Identity Managementのスタンバイ・サイトの仮想サーバー

- 3-33 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイトの仮想サーバー

- 3-34 Oracle Portal、Reports、FormsおよびDiscovererのスタンバイ・サイトの仮想サーバー

- 3-35 Oracle WebCenter Contentの本番サイトの仮想サーバー

- 3-36 Oracle WebCenter Contentのスタンバイ・サイトの仮想サーバー

- 3-37 Oracle Business Intelligenceの本番サイトの仮想サーバー

- 3-38 Oracle Business Intelligenceのスタンバイ・サイトの仮想サーバー

- 3-39 データベース・ホスト名と接続文字列

- 3-40 データベース・ホストの別名の指定

- 4-1 ディレクトリ構造の要素

- 4-2 Oracle SOA Suiteのボリューム設計に関する推奨事項

- 4-3 Oracle SOA Suiteのコンシステンシー・グループ

- 4-4 Oracle WebCenter Portalのボリューム設計に関する推奨事項

- 4-5 Oracle WebCenter Portalのコンシステンシー・グループ

- 4-6 ディレクトリ構造の要素

- 4-7 Oracle Identity Managementのボリュームに関する推奨事項

- 4-8 Oracle Identity Managementのコンシステンシー・グループ

- 4-9 Oracle Portal、Reports、FormsおよびDiscovererのボリューム設計に関する推奨事項

- 4-10 Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループ

- 4-11 ディレクトリ構造の要素

- 4-12 Oracle WebCenter Contentのボリューム設計に関する推奨事項

- 4-13 Oracle WebCenter Contentのコンシステンシー・グループ

- 4-14 ディレクトリ構造の要素

- 4-15 Oracle Business Intelligenceのボリューム設計に関する推奨事項

- 4-16 Oracle Business Intelligenceのコンシステンシー・グループ

- 4-17 本番サイトのSOAデータベースに使用する環境変数

- 4-18 スタンバイ・サイトのSOAデータベースに使用する環境変数

- 4-19 スタンバイの初期化パラメータ・ファイルで指定するパラメータ

- 7-1 トラブルシューティング

Oracle® Fusion Middleware

ディザスタ・リカバリ・ガイド

11g リリース1(11.1.1)

B61394-04(原本部品番号:E15250-05)

2012年3月

Oracle Fusion Middlewareディザスタ・リカバリ・ガイド, 11g リリース1(11.1.1)

B61394-04

Copyright © 2009, 2012, Oracle and/or its affiliates.All rights reserved.

原本著者:  Showvik Roychowdhuri

原本協力者: Bharath Reddy、Dinu Teofilovici、Fermin Castro、Faouzia EL IDRISSI、Kevin Clugage、Mahesh Desai、Pradeep Bhat、Praveen Sampath、Shailesh Dwivedi、Sunita Sharma、Susan Kornberg

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

ここでは、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このドキュメントは、管理者や開発者など、ストレージ・レプリケーション・テクノロジを使用して、Oracle Fusion Middleware障害時リカバリ・ソリューションをデプロイおよび管理することを役割としている方を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleカスタマは、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/support/contact.htmlまたはhttp://www.oracle.com/accessibility/support.html(聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middlewareのドキュメント・セットにある次のドキュメントを参照してください。

- Oracle Fusion Middleware高可用性ガイド

- Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware管理者ガイド

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 障害時リカバリの紹介

この章では、Oracle Fusion Middleware障害時リカバリについて紹介します。

内容は次のとおりです。

- 障害時リカバリの概要

- Oracle Fusion Middlewareコンポーネントの障害時リカバリ

1.1 障害時リカバリの概要

この項では、Oracle Fusion Middlewareの障害時リカバリの概要について説明します。

内容は次のとおりです。

- 問題の説明と一般的なソリューション

- 用語

1.1.1 問題の説明と一般的なソリューション

いかなるOracle Fusion Middlewareエンタープライズ・デプロイメントにおいても、最大可用性アーキテクチャの実現が重要な要件の一つとなります。Oracle Fusion Middlewareには、広範囲にわたる高可用性機能が組み込まれています。この高可用性機能には、プロセス停止の検出と再起動、サーバー・クラスタリング、サーバー移行、クラスタウェアの統合、GridLink、ロード・バランシング、フェイルオーバー、バックアップとリカバリ、ローリング・アップグレード、ローリング構成変更などが含まれており、計画外の停止からエンタープライズ・デプロイメントのを保護し、計画済の停止についても最小限に抑えます。

また、エンタープライズ・デプロイメントは、予測不可能な障害や天災から保護する必要があります。保護するためのソリューションとして、本番サイトとは別の場所にスタンバイ・サイトを設定する方法があります。スタンバイ・サイトは本番サイトと比較して、サービスやリソースの数が同じか下回る場合があります。アプリケーション・データ、メタデータ、構成データおよびセキュリティ・データが、定期的にスタンバイ・サイトにレプリケートされます。通常の場合、スタンバイ・サイトはパッシブ・モードであり、本番サイトが使用できないときに起動されます。このデプロイメント・モデルは、アクティブ/パッシブ・モデルと呼ばれることがあります。通常、このモデルは、2つのサイトがWAN経由で接続されていて、ネットワーク待機時間の関係で2つのサイトにまたがるクラスタリングができない場合に採用されます。

ホット・プラグ可能性は、Oracle Fusion Middlewareの中核となる戦略の一つであり、重要な機能の一つでもあります。異機種が混在する企業向けに構築されたOracle Fusion Middlewareは、モジュール形式のコンポーネント・ソフトウェアで構成されており、それらのソフトウェアは、一般的な各種プラットフォーム上で稼働し、IBM、Microsoft、SAPなど、他のソフトウェア・ベンダーのミドルウェア・テクノロジやビジネス・アプリケーションと相互運用されます。たとえば、Oracle Fusion Middlewareの製品およびテクノロジ(ADF、Oracle BPEL Process Manager、Oracle Enterprise Service Bus、Oracle Web Services Manager、Adapters、Oracle Access Manager、Oracle Identity Manager、Rules、Oracle TopLink、Oracle Business Intelligence Publisherなど)は、Oracle WebLogic Serverコンテナで稼働することに加えて、IBM WebsphereやJBossなど、Oracle以外のコンテナでも稼働できます。

Oracle Fusion Middleware障害時リカバリ・ソリューションは、Oracle Fusion Middlewareの中間層コンポーネントの障害保護にストレージ・レプリケーション・テクノロジを使用しています。このソリューションでは、ホット・プラグ可能なデプロイメントがサポートされており、サード・パーティ・ベンダーの推奨するソリューションと互換性があります。

Oracle Fusion Middlewareに含まれるOracle Databaseの障害保護は、Oracle Data Guardによって実現されます。

このドキュメントでは、エンタープライズ・デプロイメント向けにOracle Fusion Middleware障害時リカバリ・ソリューションをLinuxとUNIXのオペレーティング・システムにデプロイして、ストレージ・レプリケーション・テクノロジとOracle Data Guardテクノロジを利用する方法について説明します。

1.1.2 用語

この項では、障害時リカバリに関して次の用語を定義します。

- 非対称型トポロジ: Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成に相違があります。たとえば、スタンバイ・サイトのほうが本番サイトより、ホストやインスタンスの数が少ないというようなケースが考えられます。非対称トポロジの作成方法については、第4.4項「非対称スタンバイ・サイトの作成」に記述されています。

- 障害: 容認しがたい損傷や損失を引き起こす、突発的で計画外の惨事のこと。この障害というイベントが発生すると、許容しがたいほどの期間にわたって、重大な機能、プロセスまたはサービスを提供する機会が損なわれるので、組織はそのリカバリ計画を実行します。

- 障害時リカバリ: 本番サイトにおいて、天災による停止や計画外の停止を予防する機能。別の場所に設置したスタンバイ・サイトにアプリケーションやデータをレプリケートするためのリカバリ戦略を使用します。

- ホスト名別名: このガイドでは、「ホスト名別名」という用語と「物理ホスト名」という用語を区別しています。
ホスト名別名とは、実際のネットワーク名を指定する以外に、システムにアクセスするための代替手段です。通常は、システムのネットワーク名と同じIPアドレスに変換されます。これは、DNSのような名前解決システムで定義することも、各システムのローカル・ホスト・ファイルでローカルに定義することもできます。1つのシステムに対して複数のホスト名別名を定義できます。

この項で後述する「物理ホスト名」の定義も参照してください。

- 物理ホスト名: 物理ホスト名とは、gethostname()コールまたはhostnameコマンドで返されるシステムのホスト名です。通常の場合、物理ホスト名は、クライアントがシステムにアクセスするために使用するネットワーク名でもあります。この場合、DNS(または使用中の任意の名前解決メカニズム)でこの名前にIPアドレスが関連付けられます。関連付けられたIPは、システムへのネットワーク・インタフェースのいずれか1つで有効化できます。
1つのシステムには通常、物理ホスト名が1つ設定されています。また、ネットワーク・インタフェースで有効化されているIPアドレスに対応して、クライアントがネットワークを介してアクセスするために使用するネットワーク名を、追加で1つ以上設定することもできます。さらに、各ネットワーク名は、1つ以上のホスト名別名に置き換えることもできます。

この項で前述した「ホスト名別名」の定義も参照してください。

- 仮想ホスト名: 仮想ホスト名はネットワーク・アドレスを指定可能なホスト名で、ロード・バランサまたはハードウェア・クラスタを通じて、1つ以上の物理マシンにマップされます。ロード・バランサの場合、このマニュアルでは仮想サーバー名の名前は仮想ホスト名と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にマシンと通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタにある特定ノードにクラスタの仮想IPが永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。

注意:

このドキュメントで「仮想ホスト名」という用語を使用する場合、それが仮想IPアドレスに関連付けられることを前提とします。IPアドレスが必要とされたり使用される場合、明示的に言及します。

- 仮想IP: クラスタ仮想IP、ロード・バランサ仮想IPとも言います。一般的に、仮想IPはハードウェア・クラスタやロード・バランサに割り当てることができます。クラスタにおいて単一のシステム・ビューをネットワーク・クライアントに対して実現するために、クラスタのメンバーであるサーバー・グループに対して仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPは、サーバーのロード・バランサまたはハードウェア・クラスタに割り当てることができます。
ハードウェア・クラスタではクラスタの仮想IPが使用され、外部の世界に対してクラスタ(スタンドアロンのマシンにも設定可能)へのエントリ・ポイントを実現します。ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。2台のノードによる標準的ハードウェア・クラスタ構成では、各マシンには固有の物理IPアドレスと物理ホスト名が付与されながら、数個のクラスタIPアドレスを付与することもできます。これらのクラスタIPアドレスは、2台のノードにおいて切り替わります。クラスタIPアドレスを現在所有しているノードは、そのアドレスでアクティブになります。

また、ロード・バランサも一連のサーバーのエントリ・ポイントとして仮想IPを使用します。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーに割り当てられるのではなく、サーバーとクライアントの間のプロキシとして機能するロード・バランサに割り当てられます。

- 本番サイトの設定: 本番サイトを作成するプロセス。このマニュアルに記述した手順を使用して本番サイトを作成するには、物理ホスト名およびホスト名別名を計画して作成し、共有ストレージ上でOracle Fusion Middlewareインスタンスのインストール先とするOracleホーム・ディレクトリに対するマウント・ポイントおよびシンボリック・リンク(該当する場合)をホスト上に作成し、バイナリとインスタンスをインストールして、アプリケーションをデプロイする必要があります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

- サイトのフェイルオーバー: (本番サイトに障害が発生したことなどが原因で)本番サイトが突然使用できなくなった後で、現在のスタンバイ・サイトを新しい本番サイトにするプロセス。このドキュメントでは、サイトのフェイルオーバーを指す用語として「フェイルオーバー」も使用します。

- サイトのスイッチバック: 現在の本番サイトおよび現在のスタンバイ・サイトのロールを元に戻すプロセス。スイッチバックは、スイッチオーバー処理の完了後に行う計画済の操作です。スイッチバックを行うと、各サイトの元のロールがリストアされます。具体的には、現在のスタンバイ・サイトが本番サイトになり、現在の本番サイトがスタンバイ・サイトになります。このドキュメントでは、サイトのスイッチバックを指す用語として「スイッチバック」も使用します。

- サイトのスイッチオーバー: 本番サイトとスタンバイ・サイトのロールを逆にするプロセス。スイッチオーバーは、定期的な検証のために行う、または現在の本番サイトで計画メンテナンスを実行するための計画済の操作です。スイッチオーバー中に、現在のスタンバイ・サイトが新しい本番サイトになり、現在の本番サイトが新しいスタンバイ・サイトになります。このドキュメントでは、サイトのスイッチオーバーを指す用語として「スイッチオーバー」も使用します。

- サイトの同期化: 本番サイトで行った変更をスタンバイ・サイトに適用するプロセス。たとえば、本番サイトで新しいアプリケーションがデプロイされたら、同期化を実行して、同じアプリケーションがスタンバイ・サイトでもデプロイされるようにする必要があります。

- スタンバイ・サイトの設定: スタンバイ・サイトを作成するプロセス。このマニュアルに記述した手順を使用して本番サイトを作成するには、物理ホスト名およびホスト名別名を計画して作成し、スタンバイ共有ストレージ上のOracleホーム・ディレクトリに対するマウント・ポイントおよびシンボリック・リンク(該当する場合)を作成する必要があります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

- 対称トポロジ: Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層がまったく同じように構成されます。対称トポロジでは、本番サイトとスタンバイ・サイトで同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションを使用します。また、両方のサイトで同じポートが使用されます。システムはまったく同じように構成され、アプリケーションは同じデータにアクセスします。このマニュアルでは、エンタープライズ構成用に、Oracle Fusion Middleware障害時リカバリで対称トポロジを設定する方法について説明します。

- トポロジ: Oracle Fusion Middleware障害時リカバリ・ソリューションを構成する、本番サイトとスタンバイ・サイトのハードウェアおよびソフトウェアのコンポーネント。

- ターゲット: ターゲットは、エンタープライズ内のインフラストラクチャおよびビジネス・コンポーネントを表すコアEnterprise Managerエンティティです。ビジネスが効率的に機能するには、これらのコンポーネントを監視および管理する必要があります。例: Oracle Fusion MiddlewareファームまたはOracle Database。

- システム: システムとは、相互に機能することでアプリケーションをホスティングする、一連のターゲット(ホスト、データベース、アプリケーション・サーバーなど)を指します。たとえば、Enterprise Managerでアプリケーションを監視するには、最初に、アプリケーションが動作するターゲットであるデータベース、リスナー、アプリケーション・サーバーおよびホストで構成されるメール・システムなどのシステムを作成します。

- サイト: サイトは、アプリケーションのグループを実行するのに必要なデータセンターにある、一連の様々なターゲットを指します。サイトは、たとえば、Oracle Fusion Middlewareインスタンス、データベース、ストレージなどがあります。データセンターは、Oracle Site Guardによって複数のサイトを定義することができ、各データセンターにおけるスイッチオーバーやフェイルオーバーなどの操作は、独立して管理されます。

1.2 Oracle Fusion Middlewareコンポーネントの障害時リカバリ

この項では、Oracle Fusion Middlewareの一般的なエンタープライズ・デプロイメント向けに、障害時リカバリ・ソリューションを設定する作業について紹介します。

内容は次のとおりです。

- Oracle Fusion Middleware障害時リカバリ・アーキテクチャの概要

- このドキュメントに記述されているコンポーネント

1.2.1 Oracle Fusion Middleware障害時リカバリ・アーキテクチャの概要

この項では、Oracle Fusion Middlewareコンポーネントのデプロイメント・アーキテクチャについて説明します。

Oracle Fusion Middlewareコンポーネントおよびアプリケーションの製品バイナリと構成は、中間層のOracleホーム・ディレクトリにデプロイされます。また、製品のほとんどで、メタデータとランタイム・データもデータベース・リポジトリに格納されます。

そのため、Oracle Fusion Middleware障害時リカバリ・ソリューションによって、データベースに格納されている中間層ファイル・システム・データは、本番サイトとスタンバイ・サイトで同期がとられています。

Oracle Fusion Middleware障害時リカバリ・ソリューションでは、Oracle Fusion Middlewareのデータおよびデータベースの内容にデータ保護を実現するために、次の方法がサポートされています。

- Oracle Fusion Middleware製品バイナリ、構成、およびメタデータ・ファイル
ストレージ・レプリケーション・テクノロジを使用します。

- データベースの内容
Oracle DatabaseにはOracle Data Guard(サード・パーティのデータベースにはベンダー推奨のソリューション)を使用します。

図1-1に、Oracle Fusion Middleware障害時リカバリ・トポロジの概要を示します。

図1-1 Oracle Fusion Middleware障害時リカバリ・トポロジにおける本番サイトとスタンバイ・サイト

「図1-1 Oracle Fusion Middleware障害時リカバリ・トポロジにおける本番サイトとスタンバイ・サイト」の説明

図1-1に示したソリューションの重要な側面をいくつか、次に示します。

- このソリューションにはサイトが2つあります。現在の本番サイトは稼働中かつアクティブであり、2番目のサイトはスタンバイ・サイトとして動作し、パッシブ・モードになっています。

- 各サイト上のホストには、そのサイトの共有ストレージ・システムにアクセスするためのマウント・ポイントが定義されています。

- どちらのサイトでも、Oracle Fusion Middlewareコンポーネントはサイトの共有記憶域システムにデプロイされます。そのため、ミドルウェア・コンポーネントの製品バイナリや構成データなど、すべてのOracleホーム・ディレクトリを本番サイトの共有ストレージ上のボリュームに作成し、共有ストレージ上のOracleホーム・ディレクトリにコンポーネントをインストールする必要があります。図1-1では、Oracle Fusion Middlewareホストの各クラスタに対して、別々のボリュームが共有ストレージに作成されています(各サイトの共有ストレージ・システムで、Web、アプリケーション、セキュリティの各ボリュームが、それぞれWebクラスタ、アプリケーション・クラスタおよびセキュリティ・クラスタ用として作成されています)。

- 本番サイトの共有ストレージにマウント・ポイントを作成する必要があります。本番サイトの共有ストレージに作成したマウント・ポイントを使用して、本番サイトのOracle Fusion MiddlewareソフトウェアをOracleホーム・ディレクトリにインストールします。本番サイトの共有ストレージ上のOracle Fusion Middlewareホーム・ディレクトリに対するシンボリック・リンクを、本番サイトのホストに設定する必要もあります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

- スタンバイ・サイトの共有ストレージにマウント・ポイントを作成する必要があります。スタンバイ・サイトの共有ストレージ上のOracle Fusion Middlewareホーム・ディレクトリに対するシンボリック・リンクを、スタンバイ・サイト・ホストに設定する必要もあります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。マウント・ポイントおよびシンボリック・リンクは、スタンバイ・サイト・ホスト用と本番サイト・ホスト用で同一である必要があります。

- 本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージに、中間層のファイル・システムなどのデータをコピーするには、ストレージ・レプリケーション・テクノロジを使用します。

- ストレージ・レプリケーションが有効化されると、アプリケーションのデプロイメント、構成、メタデータ、データおよび製品バイナリ情報が、本番サイトからスタンバイ・サイトにレプリケートされます。

- スタンバイ・サイト・ホストでは、Oracleソフトウェアのインストールを実行する必要はいっさいありません。製品サイトの記憶域がスタンバイ・サイトの記憶域にレプリケートされると、同等のOracleホーム・ディレクトリおよびデータが、スタンバイ・サイトの記憶域に書き込まれます。

- 指定した間隔で増分レプリケーションが行われるようにスケジュールを作成します。中間層の構成を頻繁に変更しない本番デプロイメントには、この間隔として1日に1回をお薦めします。また、本番サイトで中間層の構成を変更するたびに(本番サイトに新しいアプリケーションをデプロイした場合など)、手動による同期化を実施する必要があります。一部のOracle Fusion Middlewareコンポーネントでは、ファイル・システム上にデータが生成されるため、リカバリ・ポイントの目標に応じて、より頻繁なレプリケーションが必要になる場合があります。Oracle Fusion Middlewareコンポーネントの障害時リカバリに関する推奨事項の詳細は、第2章「Fusion Middlewareコンポーネントに関する推奨事項」を参照してください。

- 手動による同期化を実施する前に、サイトのスナップショットを取得して、現時点の状態を取得しておく必要があります。これにより、スナップショットがスタンバイ・サイトの記憶域にレプリケートされるようになります。また必要に応じて、このスナップショットを使用して、スタンバイ・サイトを前の同期状態にロールバックすることもできます。レプリケーションに失敗した場合は、レプリケーションが前回成功した(スナップショットが作成された)ポイントにリカバリできます。

- Oracle Fusion Middlewareリポジトリやカスタム・アプリケーション・データベースなど、すべてのOracle Databaseリポジトリをレプリケートするには、Oracle Data Guardを使用します。Oracle Data Guardを使用してOracle Databaseで障害保護を実現する方法の詳細は、第3.3項「データベースに関する考慮事項」を参照してください。

- Oracle Fusion Middleware障害時リカバリ・トポロジにサード・パーティのデータベースが含まれる場合、それらのデータベースにはベンダーが推奨するソリューションを使用してください。

- ユーザー・リクエストは最初に、本番サイトにルーティングされます。

- 本番サイトに障害または計画外の停止が発生した場合には、次の手順を実行して、トポロジ内でスタンバイ・サイトが本番のロールを引き継げるようにします。

1. 本番サイトからスタンバイ・サイトへのレプリケーションを停止します(障害発生時には、その障害によりレプリケーションがすでに停止している可能性があります)。

2. Oracle Data Guardを使用して、Oracle Databaseのフェイルオーバーまたはスイッチオーバーを実行します。

3. スタンバイ・サイトでサービスとアプリケーションを起動します。

4. グローバルなロード・バランサを使用して、ユーザー・リクエストをスタンバイ・サイトに再ルーティングします。この時点では、スタンバイ・サイトが本番のロールを引き継いでいます。

1.2.2 このドキュメントに記述されているコンポーネント

Oracle Fusion Middleware障害時リカバリ・ソリューションがサポートしている各種Oracle製品群のコンポーネントには、次のようなものがあります。

- Oracle WebLogic Server
Oracle WebLogic Serverのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.1項「Oracle WebLogic Serverに関する推奨事項」を参照してください。

- Oracle ADF
Oracle Application Development Framework(Oracle ADF)向けの障害時リカバリに関する推奨事項については、第2.2項「Oracle ADFに関する推奨事項」を参照してください。

- Oracle WebCenter Portalのコンポーネント:

- Oracle WebCenter Portal: Spaces

- Oracle WebCenter PortalのPortlet Producers

- Oracle WebCenter PortalのDiscussion Server

- Oracle WebCenter Contentサーバー

- Oracle WebCenter Portal Pagelet Producer

- Oracle WebCenter Portal Activity Graph Engines

- Oracle WebCenter PortalのPersonalization

- Oracle WebCenter PortalのAnalytics Collector

- Oracle WebCenter Portal Services Producer

Oracle WebCenter Portalのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.3項「Oracle WebCenter Portalに関する推奨事項」を参照してください。

- Oracle SOA Suiteのコンポーネント:

- Oracle SOA Service Infrastructure

- Oracle BPEL Process Manager

- Oracle Mediator

- Oracle Human Workflow

- Oracle B2B

- Oracle Web Services Manager

- Oracle User Messaging Service

- Oracle JCA Adapters

- Oracle Business Activity Monitoring

- Oracle Business Process Management

Oracle SOA Suiteのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.4項「Oracle SOA Suiteに関する推奨事項」を参照してください。

- Oracle Identity Managementのコンポーネント:

- Oracle Internet Directory

- Oracle Virtual Directory

- Oracle Directory Integration Platform

- Oracle Identity Federation

- Oracle Directory Services Manager

- Oracle Access Manager

- Oracle Adaptive Access Manager

- Oracle Identity Manager

- Oracle Identity Navigator

Oracle Identity Managementのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.5項「Oracle Identity Managementに関する推奨事項」を参照してください。

- Oracle Portal、Forms、ReportsおよびBusiness Intelligence Discovererのコンポーネント:

- Oracle Portal

- Oracle Forms

- Oracle Reports

- Oracle Business Intelligence Discoverer(Discoverer)

これらのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.6項「Oracle Portal、Forms、ReportsおよびDiscovererに関する推奨事項」を参照してください。

- Oracle Web Tierのコンポーネント:

- Oracle HTTP Server

- Oracle Web Cache

Oracle Web Tierのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.7項「Oracle Web Tierコンポーネントに関する推奨事項」を参照してください。

- Oracle WebCenter Content:

- Oracle WebCenter Content

- Oracle WebCenter Content: Inbound Refinery

- Oracle WebCenter Content: Imaging

- Oracle WebCenter Content: Information Rights

- Oracle WebCenter Content: Records

Oracle WebCenter Contentのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.8項「Oracle WebCenter Contentに関する推奨事項」を参照してください。

- Oracle Business Intelligence:

- Oracle Business Intelligence Enterprise Edition(EE)

- Oracle Business Intelligence Publisher

- Oracle Real-Time Decisions
Oracle Enterprise Content Managementコンポーネント向けの障害時リカバリに関する推奨事項については、第2.9項「Oracle Business Intelligenceに関する推奨事項」を参照してください。

2 Fusion Middlewareコンポーネントに関する推奨事項

この章では、様々なOracle製品スイート内のOracle Fusion Middlewareコンポーネントの障害保護の要件について説明し、これらのコンポーネントの同期化に関する推奨事項も示します。前に説明したとおり、ストレージ・レプリケーションを使用して中間層のコンテンツを同期化し、Oracle Data Guardを使用してOracle Fusion Middleware障害時リカバリ・トポロジに含まれているOracle Database・リポジトリまたはカスタム・アプリケーション・データベース内のデータを同期化します。

この章では、次のOracle製品スイート内のコンポーネントの障害時リカバリに関する推奨事項を示します。

- Oracle WebLogic Serverに関する推奨事項

- Oracle ADFに関する推奨事項

- Oracle WebCenter Portalに関する推奨事項

- Oracle SOA Suiteに関する推奨事項

- Oracle Identity Managementに関する推奨事項

- Oracle Portal、Forms、ReportsおよびDiscovererに関する推奨事項

- Oracle Web Tierコンポーネントに関する推奨事項

- Oracle WebCenter Contentに関する推奨事項

- Oracle Business Intelligenceに関する推奨事項

Oracle製品スイート間の共通アーティファクト

Oracleインベントリ、beahomelistファイル、oratabファイル、oraInst.locファイルなどの特定のアーティファクトは、すべてのOracle製品デプロイメント間で共通です。これらのアーティファクトが異なっていることはほとんどなく、通常のストレージ・レプリケーションおよび同期化アクティビティの一部とする必要はありません。Oracleインベントリ、beahomelistファイル、oratabファイルおよびoraInst.locファイルはマシンのローカル・ディスクに配置することをお薦めします。これらのアーティファクトは、作成時およびパッチ・アップデートの適用時に手動で更新する必要があります。環境で必要な場合は、これらのアーティファクトを共有記憶域に配置することも可能です。

2.1 Oracle WebLogic Serverに関する推奨事項

Oracle WebLogic Serverは、エンタープライズ対応のスケーラブルなEnterprise Edition(Java EE)アプリケーション・サーバーです。Oracle WebLogic Serverインフラストラクチャは、様々なタイプの分散アプリケーションのデプロイメントをサポートしており、サービス指向アーキテクチャ(SOA)に基づいてアプリケーションを構築するための理想的な基盤となります。

Oracle WebLogic Serverの共通アーティファクトと考慮事項

コンポーネント固有の推奨事項に加えて、次のアーティファクトと考慮事項がすべてのWebLogic Serverコンポーネントに適用されます。

ファイル・システム上のアーティファクト

MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームから構成されます。

ドメイン・ホーム: ドメイン・ホームには、WebLogicドメインの構成データおよびアプリケーションが含まれます。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。

環境でサーバー全体の移行を構成する必要がある場合、サーバー全体の移行で構成されている管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用することをお薦めします。障害時リカバリ操作後にリスニング・アドレスを手動で更新しなくても済むようにするには、ホスト名をプライマリ・サイトとスタンバイ・サイトの両方で解決できるようにしてください。

本番サイトとスタンバイ・サイトの両方で、WebLogic Serverアプリケーションへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。

この項の残りの部分では、次のOracle WebLogic Serverコンポーネントの障害時リカバリに関する推奨事項を示します。

- Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項

- Oracle Platform Security Servicesに関する推奨事項

2.1.1 Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項

この項では、様々なOracle WebLogic Server JMSおよびトランザクション・ログ・アーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

ファイルベースの永続ストア: JMS/トランザクション・ログのファイル・ストアの場所(ファイルベースの永続ストアを使用する場合)。

データベース内のアーティファクト

JMSメッセージを含むスキーマ(データベース・ベースの永続ストアを使用する場合)。このスキーマには、JDBC LLRオプションを利用するWebLogicアプリケーションのロギング・ラスト・リソース(LLR)トランザクション・ログ・レコードが含まれます。

サーバー全体の自動移行が構成されている場合、必要なリース表はデータベース内にあります。

特別な考慮事項

- システムのリストア・ポイントよりも後にエンキューされていた未処理のメッセージは失われます。システムのリストア・ポイントよりも前にエンキューされており、その後デキューされて確認応答またはコミット(処理)されたメッセージについては、メッセージの複製が作成されます。

- 永続ストアがJMS専用のカスタム・ストアである場合は、ストア全体を削除できます。

- システムのさまざまな部分をさまざまな時点でリストアすると、データに不整合が生じる可能性があります。メッセージ・ストア、トランザクション・ログまたはアプリケーション・データベースが別々に同期化されると、このような状況が発生することがあります。たとえば、存在しないデータベース行をメッセージが参照する場合(またはその逆)などです。これにより、重複メッセージに加えて未処理のメッセージが削除されることがあります。

- ストアがJMS専用でない場合は、Oracle WebLogic Server JMSメッセージ管理ツールを使用します。このツールを使用して、管理コンソール、MBeanおよびWLSTからインポート、エクスポート、移動および削除の各操作を行うことができます。

- アプリケーションがキューとトピックの両方を使用する場合は、キューとトピックの両方のサブスクリプションを処理してください。

同期化に関する推奨事項

- JMSデータの重要性が高い場合には、同期レプリケーションを使用して、トランザクション・ログ・データとJMSデータをリアル・タイムで同期化することをお薦めします。同期レプリケーションを使用するとパフォーマンスに影響する場合があることに注意してください。

- 各層間でのデータの整合性が重要な場合は、データベース層とアプリケーション層が同時にレプリケートされていることを確認します。こうすると、異なる層をまったく同じ時点でリカバリできるようにするために役立ちます。

- データベース・ベースの永続ストアを使用している場合は、Oracle Data Guardを使用して、プライマリ・サイトとスタンバイ・サイトをレプリケートします。

- ブロックレベルのスナップショット機能をサポートしていないストレージ・デバイスを使用している場合は、JMSサーバーを停止して、一貫性バックアップを作成します。これにより、コピー操作の実行中に永続ストアへの書込みが行われないようになります。クラスタ環境の場合は、一度に1つのサーバーを停止し、バックアップを作成して、再起動します。WLSTを使用してこれらの操作を実行するスクリプトを作成することもできます。

リカバリに関する推奨事項

WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーとともに、永続ストアを含むデータベース・スキーマを直近の時点にリカバリします。

さらに、重複メッセージを回避するために、リカバリに関する次の推奨事項に従います。

重複メッセージの回避

リカバリの前に次の手順を実行して、永続ストアのリカバリ後にJMSキュー内のメッセージを排出し、重複メッセージの処理を回避します。

注意:

メッセージを排出および破棄する前に、保存の必要なデータがメッセージに含まれていないことを確認してください。リカバリしたメッセージには、処理済の重複メッセージに加えて、重要なアプリケーション・データが含まれる未処理のメッセージが含まれている可能性があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. リカバリを実行する前に、起動時の生成、挿入および消費の各操作を休止するようにJMSサーバーを構成します。これは、新しいメッセージが生成されたり宛先に挿入されたりしないようにするため、または失効したメッセージを排出する前に宛先から消費されないようにするためです。その手順は次のとおりです。

1. 「サービス」→「メッセージング」→「JMSサーバー」を開きます。

2. 「JMSサーバーのサマリー」ページで、メッセージの休止を構成するJMSサーバーをクリックします。

3. 「構成: 全般」ページで「詳細」をクリックして、メッセージの休止オプションを定義します。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択します。

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

5. 前述の変更をアクティブ化するには、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。

リカバリ後に実行する手順は次のとおりです。

1. 永続ストアのリカバリ後に、管理対象サーバーを起動します。

2. 次の手順を実行して、失効したメッセージをJMS宛先から排出します。

1. 「サービス」→「メッセージング」→「JMSモジュール」を開きます。

2. JMSモジュールを選択して、宛先を選択します。

3. 「監視」→「メッセージの表示」を選択します。

4. 「すべて削除」をクリックします。

次の手順を実行して、操作を再開します。

1. 「サービス」→「メッセージング」→「JMSサーバー」を開きます。

2. 「JMSサーバーのサマリー」ページで、メッセージの休止を構成するJMSサーバーをクリックします。

3. 「構成: 全般」ページで「詳細」をクリックします。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択します。

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

5. 前述の変更をアクティブ化するには、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。

2.1.2 Oracle Platform Security Servicesに関する推奨事項

この項では、様々なOracle Platform Security Servicesアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Platform Security Servicesにはデータベース依存性がないため、適用されません。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをリカバリします。

2.2 Oracle ADFに関する推奨事項

Oracle ADFは、Java Platform, Enterprise Edition(Java EE)標準やオープンソース・テクノロジに基づいて、サービス指向アプリケーションの実装を簡略化および高速化するエンドツーエンド・アプリケーション・フレームワークです。Oracle ADFは、Web、ワイヤレス、デスクトップまたはWebサービス・インタフェースを使用してデータを検索、表示、作成、変更および検証するアプリケーションを作成するエンタープライズ開発者に適しています。

この項では、様々なOracle ADFアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームから構成されます。

Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。

ドメイン・ホーム: ドメイン・ホームには、Oracle ADFドメインの構成データおよびアプリケーションが含まれます。

カスタム・アプリケーション・ディレクトリ: これは、様々なカスタム・アプリケーションおよび関連ライブラリのストレージの場所です。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。

本番サイトとスタンバイ・サイトの両方で、アプリケーションへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。

データベース内のアーティファクト

Oracle ADFアプリケーションでは、MDSリポジトリを使用してアプリケーション・ステータスと構成データが保持される場合があります。データが保持されるかどうかは、アプリケーションがどのようにコード化されているかによって異なります。

ほとんどのOracle ADFアプリケーションは、アプリケーション・データの格納にMDSリポジトリを使用することはなく、その代わりに別のデータ・ストア(通常はデータベース)を使用してアプリケーション・データを格納します。

同期化に関する推奨事項

構成の変更、コンポジットのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

ADFまたはWebCenterアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。

2.3 Oracle WebCenter Portalに関する推奨事項

Oracle WebCenter Portalは、Java Server Faces(JSF)の標準ベースの宣言型開発機能と、ポータルの柔軟性とパワー、および一連の統合されたWeb 2.0サービスを組み合せたものです。

Oracle WebCenter Portalの共通アーティファクトと考慮事項

製品固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle WebCenter Portal製品に適用されます。

ファイル・システム上のアーティファクト

MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle WebCenter Portalバイナリが格納されるOracleホームから構成されます。

Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。

ドメイン・ホーム: ドメイン・ホームには、Oracle WebCenter Portalドメインの構成データが含まれます。

データベース内のアーティファクト

Oracle WebCenter Portalデータベースの一部であるOracle WebCenter Portalメタデータには、一部のOracle WebCenter Portalサービスのデータが格納され、MDSリポジトリには、WebCenterのメタデータおよび構成情報が格納されます。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。

本番サイトとスタンバイ・サイトの両方で、Oracle WebCenter Portal製品へのアクセスに必要なロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data Guardが、Oracle WebCenter Portalスキーマとメタデータ・リポジトリを含むOracle Database用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

Oracle WebCenter Portalアプリケーションを実行している管理対象サーバーとともに、Oracle WebCenter Portalスキーマを含むデータベースを直近の時点にリカバリする必要があります。

この項の残りの部分では、次のOracle WebCenter Portal製品の障害時リカバリに関する推奨事項を示します。

- Oracle WebCenter Portal: Spacesに関する推奨事項

- Oracle WebCenter Portalのポートレット・プロデューサに関する推奨事項

- Oracle WebCenter Portalのディスカッション・サーバーに関する推奨事項

- Oracle WebCenter Contentサーバーに関する推奨事項

- Oracle WebCenter PortalのAnalyticsコレクタに関する推奨事項

- Oracle WebCenter Portalアクティビティ・グラフ・エンジンに関する考慮事項

2.3.1 Oracle WebCenter Portal: Spacesに関する推奨事項

Oracle WebCenter Portal: Spacesは、一連の強力なサービスとアプリケーションによって、ソーシャル・ネットーワーク、通信、コラボレーションおよび個人の生産性向上を実現する、統合された単一のWebベース環境を提供します。

この項では、様々なSpacesアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

WEBCENTERスキーマには、一部のOracle WebCenter Portalサービスのデータが格納され、MDSリポジトリには、WebCenter Portalのメタデータおよび構成情報が格納されます。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data Guardが、WEBCENTERスキーマとメタデータ・リポジトリを含むOracle Database用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle WebCenter Portalドメインとともに、WebCenter PortalスキーマとMDSリポジトリを含むデータベースを直近の時点にリカバリする必要があります。

2.3.2 Oracle WebCenter Portalのポートレット・プロデューサに関する推奨事項

Oracle WebCenter Portalは、標準ベースのポートレット(JSR 168、WSRP 1.0および2.0)と、従来のOracle PDK-Javaベースのポートレットの両方のデプロイメントと実行をサポートしています。Oracle WebCenter Portalには、OmniPortlet、Webクリッピング、リッチ・テキスト・ポートレット、WSRPツールなど、すぐに使用可能なプロデューサがいくつか用意されています。

この項では、様々なポートレット・プロデューサ・アーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle WebCenter Portalスキーマの一部であるPORTLETスキーマには、ユーザー・カスタマイズが格納され、MDSリポジトリには、ポートレットのメタデータおよび構成情報が格納されます。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data Guardが、PORTLETスキーマとメタデータ・リポジトリを含むOracle Database用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle WebCenter Portalドメインとともに、PORTLETスキーマとMDSリポジトリを含むデータベースを直近の時点にリカバリする必要があります。

2.3.3 Oracle WebCenter Portalのディスカッション・サーバーに関する推奨事項

Oracle WebCenter Portalのディスカッション・サーバーは、ディスカッション・フォーラムとお知らせをアプリケーションに統合する機能を提供します。

この項では、様々なディスカッション・サーバー・アーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle WebCenter Portalスキーマの一部であるDISCUSSIONSスキーマには、メタデータとデータが格納されます。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data Guardが、DISCUSSIONSスキーマとメタデータ・リポジトリを含むOracle Database用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle WebCenter Portalドメインとともに、ディスカッション・サーバー・スキーマを含むデータベースを直近の時点にリカバリする必要があります。

2.3.4 Oracle WebCenter Contentサーバーに関する推奨事項

Oracle WebCenter Contentサーバーは、WikiとブログをWebCenter Portalアプリケーションに統合する機能を提供します。アプリケーション・ユーザーが各自のWikiとブログを作成できるようにするための機能もサポートします。

この項では、様々なOracle WebCenter Wiki and Blog Serverアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle WebCenter Portalスキーマの一部であるOCSERVERスキーマには、メタデータとデータが格納されます。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data Guardが、OCSERVERスキーマを含むOracle Database用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle WebCenter Portalドメインとともに、OCSERVERスキーマを含むデータベースを直近の時点にリカバリする必要があります。

2.3.5 Oracle WebCenter PortalのAnalyticsコレクタに関する推奨事項

ポータル管理者およびビジネス所有者は、Oracle WebCenter PortalのAnalyticsコレクタによって、ポータルの使用状況を追跡して分析できます。

この項では、バックアップおよびリストアが必要なOracle WebCenter PortalのAnalyticsコレクタのデータについて説明します。

構成ファイル

構成情報は、AnalyticsスキーマのACTIVITIESに格納されます。

データベース・リポジトリに依存するもの

ACTIVITIESスキーマおよびMDSスキーマ

バックアップに関する推奨事項

Oracleホーム、ドメイン・ホーム、およびACTIVITIESスキーマとMDSスキーマが含まれるデータベースをバックアップします。

リカバリに関する推奨事項

Oracleホームおよびドメイン・ホームをリカバリします。

必要に応じて、データベースを直近の時点にリカバリします。

2.3.6 Oracle WebCenter Portalアクティビティ・グラフ・エンジンに関する推奨事項

Oracle WebCenter Portalアクティビティは、WebCenter Portalのサービスであり、ユーザーが関心を寄せている可能性のある人、項目および空間を提案します。アクティビティ・グラフ・サービスで使用するエンジンは、エンタープライズ・アプリケーションによって収集されるアクション用の中央リポジトリを提供します。アクティビティ・グラフに格納されたデータは、分析され、ノードのランクの計算、新しいアクションの予測および推奨事項の作成に使用されます。

この項では、バックアップおよびリストアが必要なOracle WebCenter Portalアクティビティ・グラフのデータについて説明します。

構成ファイル

構成情報は、ACTIVITIESスキーマに格納されます。

データベース・リポジトリに依存するもの

ACTIVITIESスキーマ

バックアップに関する推奨事項

Oracleホーム、ドメイン・ホーム、およびACTIVITIESスキーマが含まれるデータベースをバックアップします。

リカバリに関する推奨事項

Oracleホームおよびドメイン・ホームをリカバリします。

必要に応じて、データベースを直近の時点にリカバリします。

2.4 Oracle SOA Suiteに関する推奨事項

Oracle SOA Suiteは、Oracle Fusion Middlewareのミドルウェア・コンポーネントです。Oracle SOA Suiteにより、SOAコンポジット・アプリケーションを設計、デプロイおよび管理するサービス・インフラストラクチャ・コンポーネントの完全なセットが提供されます。Oracle SOA Suiteでは、サービスの作成および管理、SOAコンポジット・アプリケーションへの編成が可能です。コンポジットにより、複数のテクノロジ・コンポーネントを1つのSOAコンポジット・アプリケーションに組み込むことができます。SOAコンポジット・アプリケーションは、次のものから構成されています。

- サービス・コンポーネント: サービス・コンポーネントとは、SOAコンポジット・アプリケーションの基本となるビルディング・ブロックです。サービス・コンポーネントにより、SOAコンポジット・アプリケーション全体のビジネス・ロジックの一部が実装されます。サービス・コンポーネントの例としては、Oracle BPEL Process Manager、Oracle Mediator、Oracle Human Workflow、Oracle Business Rulesなどがあります。

- バインディング・コンポーネント: バインディング・コンポーネントは、SOAコンポジット・アプリケーションを外部サービス、アプリケーションおよびテクノロジに接続します。バインディング・コンポーネントは、次の2つのグループから構成されています。

- サービス: SOAコンポジット・アプリケーションへのエントリ・ポイントを外部に提供します。サービスのWSDLファイルによって、そのサービスの機能が外部のアプリケーションに通知されます。サービスのバインディングでは、SOAコンポジット・サービスをどのように呼び出すことができるか(例: SOAP経由で)が定義されます。

- 参照: SOAコンポジット・アプリケーションから外部のサービスにメッセージを送信できます(たとえば、パートナ・リンクがBPELプロセスに対して提供するものと同じ機能であっても、より高度なSOAコンポジット・アプリケーション・レベルで提供されます)。

注意:

Oracle SOA Suiteリリース11.1.1.1では、soa-infraおよびサービス・エンジン構成ファイルは、ドメイン構成の一部としてローカルまたは共有のストレージ・ファイルに格納されていました。

Oracle SOA Suite 11.1.1.2以降、これらのファイルは、メタデータ・リポジトリに移動されています。そのため、soa-infraおよびサービス・エンジン構成変更は、クラスタ全体に即座に伝播されるようになりました。

Oracle SOA Suite 11.1.1.3では、Oracle BPM SuiteをSOA Suiteインストール上にデプロイできます。

Oracle SOA Suiteの障害時リカバリに関する推奨事項では、Oracle SOA Suite 11.1.1.2を使用しているものと想定しています。

Oracle SOA Suiteアーティファクトは、メタデータ・リポジトリだけでなく、ローカルまたは共有のファイル・システムに格納されます。コンポジット・アーティファクトは、メタデータ・リポジトリに格納され、バイナリおよびドメイン関連の構成ファイルは、ローカルまたは共有のファイル・システムに格納されます。

すべてのSOA Suiteコンポーネントの共通アーティファクトと考慮事項

コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのSOA Suiteコンポーネントに適用されます。

ファイル・システム上のアーティファクト

MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle SOA Suiteバイナリが格納されるOracleホームから構成されます。

Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。

ドメイン・ホーム: ドメイン・ホームには、SOAドメインの構成データおよびSOAコンポジットが含まれます。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。IPアドレスを仮想ホスト名に更新する手順については、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

本番サイトとスタンバイ・サイトの両方で、SOA Suiteコンポーネントへのアクセスに必要なロード・バランサの仮想ホストを構成する必要があります。

データベース内のアーティファクト

Oracle SOA Suiteスキーマ、サービス・インフラストラクチャとサービス・エンジンの構成、およびコンポジット定義は、Oracle SOA Suiteのデータベースとメタデータ・リポジトリに格納されます。

同期化に関する推奨事項

ドメイン関連の構成の変更、コンポジットのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

データベースを直近の時点にリカバリして、最新のコンポジット定義および進行中のインスタンスがリストアされるようにする必要があります。

進行中のインスタンスで処理が続行されるようにするには、コンポジット定義が一致している必要があります。このため、メタデータ・リポジトリ(コンポジット定義が格納されている場所)とOracle SOA Suiteデータベース(プロセス・ステータスが維持される場所)は、同じ時点にリカバリされる必要があります。

再デプロイされたコンポジットの場合、データベース・リカバリにより、デハイドレーションされた進行中のプロセスと、対応するそれらの定義間の一貫性が確保されます。これは、デハイドレーションされたインスタンスが格納されているデータベース・リポジトリにプロセス定義が格納されているからです。

この項では、次のOracle SOA Suiteコンポーネントの障害時リカバリに関する推奨事項を示します。

- Oracle SOA Service Infrastructureに関する推奨事項

- Oracle BPEL Process Managerに関する推奨事項

- Oracle Mediatorに関する推奨事項

- Oracle Human Workflowに関する推奨事項

- Oracle B2Bに関する推奨事項

- Oracle Web Services Managerに関する推奨事項

- Oracle User Messaging Serviceに関する推奨事項

- Oracle JCA Adaptersに関する推奨事項

- Oracle Business Activity Monitoringに関する推奨事項

- Oracle Business Process Managementに関する推奨事項

2.4.1 Oracle SOA Service Infrastructureに関する推奨事項

Oracle SOA Service Infrastructureは、Oracle Fusion Middleware SOA Suiteを実行するための基礎となるサービスを提供するJava EEアプリケーションです。このJava EEアプリケーションは、Oracle Fusion Middleware SOA Suiteのインストール時に自動的にデプロイされるランタイム・エンジンです。コンポジット(サービス・コンポーネント・アーキテクチャ内の基本アーティファクト)をOracle SOA Infrastructureにデプロイすると、コンポジットの実行に必要なサービスが提供されます。Oracle SOA Infrastructureは、コンポジット用のデプロイメント、接続およびスレッド管理サービスを提供します。これらのサービスにより、コンポジットのライフサイクルとランタイム操作が維持されます。

この項では、様々なOracle SOA Service Infrastructureアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

コンポジット定義と構成ファイルは、MDSリポジトリに格納されます。コンポジット・インスタンス・ステータスの永続性は、SOA Service Infrastructureデータベース内に格納されます。

同期化に関する推奨事項

ドメイン関連の構成の変更、コンポジットのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

データベースを直近の時点にリカバリして、最新のコンポジット定義および進行中のインスタンスがリストアされるようにする必要があります。

2.4.2 Oracle BPEL Process Managerに関する推奨事項

Oracle BPEL Processエンジンは、BPELプロセスの実行を可能にする、SOA Service Infrastructure内で実行されるサービス・エンジンです。BPELプロセスは、一連の独立したサービスをエンドツーエンドのプロセス・フローに組み込み、エンドツーエンドのBPELプロセス・フローへの同期および非同期サービスを開発するための標準を提供します。それは、長時間実行される非同期プロセスのプロセス編成および格納を可能にします。

この項では、様々なOracle BPEL Process Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

プロセス定義と構成ファイルは、MDSリポジトリに格納されます。BPELプロセス・ステータスの永続性は、Oracle SOA Suiteデータベース内に格納されます。

同期化に関する推奨事項

ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

データベースを直近の時点にリカバリして、最新のプロセス定義および進行中のインスタンスがリストアされるようにする必要があります。Oracle BPEL Process Managerの冪等プロセスを使用すると、障害時リカバリ操作の実行後にクリーンアップする必要がないため、これを使用することをお薦めします。冪等以外のOracle BPEL Process Managerプロセスを使用する場合は、障害時リカバリ操作の実行後に、デハイドレーション・ストアからプロセスをクリーンアップする必要があります(特に、プロセスが進行中の場合)。

2.4.3 Oracle Mediatorに関する推奨事項

Oracle Mediatorは、Oracle SOA Service Infrastructure内のサービス・エンジンです。Oracle Mediatorは、様々なプロバイダとサービスやイベントのコンシューマの間を仲介するフレームワークを提供します。Mediatorサービス・エンジンは、SOA Service Infrastructure Java EEアプリケーションとともに実行されます。

この項では、様々なOracle Mediatorアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Mediatorサービス・エンジンは、パラレル・ルーティング・ルールの非同期ルーティングのために、メッセージをデータベース内に格納します(順次ルーティング・ルールでは、実行時にメッセージがデータベース内に保持されることはありません)。Mediatorコンポーネント・インスタンス・ステータスおよび監査の詳細もデータベース内に格納されます。

メタデータ・リポジトリには、コンポジット定義の一部としてMediatorコンポーネント定義が格納されます。

同期化に関する推奨事項

ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

管理サーバー、およびsoa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。

2.4.4 Oracle Human Workflowに関する推奨事項

Oracle Human Workflowは、人間による対話型プロセスの実行を可能にする、Oracle SOA Service Infrastructure内で実行されるサービス・エンジンです。ヒューマン・ワークフローは、プロセス内またはプロセス外で承認、拒否、再割当てアクションなどの人間による対話型のアクションをサポートします。Human Workflowサービスは、人間がビジネス・プロセスに関するさまざまな操作を実行できるようにするためのいくつかのサービスで構成されています。

この項では、様々なOracle Human Workflowアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

ヒューマン・ワークフロー・インスタンス・データおよび他のワークリスト・データ(休暇ルール、グループ・ルール、フィールド・マッピング、ビュー定義など)は、データベース内に格納されます。

メタデータ・リポジトリは、SOAコンポジットによって使用される共有のヒューマン・ワークフロー・サービス定義およびスキーマの格納に使用されます。

同期化に関する推奨事項

ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。Oracle Human Workflowのエンジンは、Oracle User Messaging Serviceを使用して通知を送信および取得します。Oracle User Messaging Serviceの詳細は、第2.4.7項「Oracle User Messaging Serviceに関する推奨事項」を参照してください。

2.4.5 Oracle B2Bに関する推奨事項

Oracle B2Bは、SOAコンポジット・アプリケーションを外部サービス、アプリケーションおよびテクノロジに接続します。Oracle B2Bは、業界が認めるB2B標準対応マルチプロトコル・ゲートウェイを提供します。Oracle B2Bは、Oracle SOA Suiteを、電子データ交換(EDI)、ebXML、HL7、RosettaNetなどのビジネス・プロトコル標準で拡張します。Oracle B2Bは、SOA Service Infrastructure内のバインディング・コンポーネントとして実装されます。

この項では、様々なOracle B2Bアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

JMS ストア: ファイルベースのJMS永続ストアを含むボリューム。表2-1に、Oracle B2Bによって内部的に使用されるJMSキューおよびトピックを示します。

表2-1 Oracle B2Bによって使用されるJMSキューおよびトピック

JMSアーティファクト名

タイプ

JNDI名

dist_B2BEventQueue_auto

分散キュー

jms/b2b/B2BEventQueue

dist_B2B_IN_QUEUE_auto

分散キュー

jms/b2b/B2B_IN_QUEUE

dist_B2B_OUT_QUEUE_auto

分散キュー

jms/b2b/B2B_OUT_QUEUE

dist_B2BBroadcastTopic_auto

分散トピック

jms/b2b/B2BBroadcastTopic

データベース内のアーティファクト

Oracle B2Bメッセージおよびメッセージ・ステータスの永続性は、パートナ、ドキュメントおよびチャネル定義とともに、Oracle SOA Suiteデータベース内に格納されます。メタデータ・リポジトリは、Oracle B2Bメタデータの格納に使用されます。

特別な考慮事項

これらのアダプタを使用する場合は、スタンバイ・サイトで外部FTPサーバーおよび電子メール・サーバーが使用可能である必要があります。

同期化に関する推奨事項

Oracle B2B JMSキューの同期化とリカバリの詳細は、第2.1.1項「Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項」を参照してください。

ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。Oracle B2Bは、JMSキューおよびSOAランタイム・データベース内に状態情報を格納するので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが正常に実行されるようになります。

2.4.6 Oracle Web Services Managerに関する推奨事項

Oracle Web Services Manager(Oracle WSM)は、組織全体でWebサービスを一貫して管理および保護するポリシー・フレームワークを提供します。それは、セキュリティ、WSRM、MTOM、アドレス指定ポリシーなどのWeb Serviceポリシーを構築、適用、実行および監視する機能を提供します。Oracle Web Services Managerは、ポリシー・マネージャとエージェントから構成されています。

ポリシー・マネージャは、MDSリポジトリから、事前定義されたポリシーとカスタム・ポリシーを含め、セキュリティおよび管理ポリシーの読取りおよび書込みを行います。ポリシー・マネージャは、ステートレスJava EEアプリケーションです。ステートレス・セッションBeanによって、その機能が公開されます。ポリシー・マネージャはデータをキャッシュしませんが、基礎となるMDSインフラストラクチャはデータをキャッシュします。

エージェントは、ポリシーの適用と実行、および実行時統計の収集を行います。エージェントは、すべてのOracle Fusion Middleware管理対象サーバー上で使用可能であり、保護対象のアプリケーションと同じサーバー上に構成されます。エージェントは、ポリシー・アクセス・ポイント(PAP)とポリシー・インターセプタの2つから構成されています。

この項では、様々なOracle Web Services Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

MDSリポジトリは、ポリシーの格納に使用されます。

同期化に関する推奨事項

ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。すべてのポリシーはMDSリポジトリ内に格納されるので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが正常に実行されるようになります。

2.4.7 Oracle User Messaging Serviceに関する推奨事項

Oracle User Messaging Service(Oracle UMS)は、ユーザーとデプロイ済アプリケーション間の双方向通信を可能にします。電子メール、IM、SMS、テキストから音声に変換したメッセージなど、様々なチャネルに対応しています。Oracle User Messaging Serviceは、Oracle BPEL PM、Oracle Human Workflow、Oracle BAM、Oracle WebCenter PortalなどのOracle Fusion Middlewareコンポーネントに統合されます。通常、これは、Oracle SOAサービス・インフラストラクチャとともにデプロイされます。Oracle User Messaging Serviceは、UMSサーバー、UMSドライバおよびUMSクライアント・アプリケーションで構成されています。

この項では、様々なOracle User Messaging Serviceアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

JMS ストア: ファイルベースのJMS永続ストアを含むボリューム。表2-2に、Oracle User Messaging Serviceによって内部的に使用されるJMSリソースを示します。

表2-2 Oracle User Messaging Serviceによって使用されるJMSリソース

JMSアーティファクト名

タイプ

JNDI名

OraSDPMAppDefRcvQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMAppDefRcvQ1

OraSDPMDriverDefSndQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMDriverDefSndQ1

OraSDPMEngineCmdQ_auto

分散キュー

OraSDPM/Queues/OraSDPMEngineCmdQ

OraSDPMEngineRcvQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMEngineRcvQ1

OraSDPMEngineSndQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMEngineSndQ1

OraSDPMWSRcvQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMWSRcvQ1

データベース内のアーティファクト

Oracle User Messaging Serviceは、外部データベース・リポジトリを使用してメッセージおよび構成の状態を維持管理します。

特別な考慮事項

Oracle User Messaging Serviceは、JMSを使用して、メッセージング・アプリケーション間にメッセージを配信します。デフォルトでは、ファイルベースの永続性JMSストアを使用するように構成されているので、それらのファイルが配置されているストレージ・デバイスに依存します。

同期化に関する推奨事項

構成の変更、追加のOracle User Messaging Serviceドライバのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

usermessagingserverアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。Oracle User Messaging Serviceは、外部データベース・リポジトリ内にメッセージおよび構成の状態を保持し、JMSキュー内にメッセージを保持するので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが問題なく機能するようになります。JMSデータの同期化に関する推奨事項は、第2.1.1項「Oracle WebLogic Server JMSおよびトランザクション・ログに関する考慮事項」の「同期化に関する推奨事項」を参照してください。

2.4.8 Oracle JCA Adaptersに関する推奨事項

Oracle JCA Adaptersは、Service Infrastructureが異なるプロトコルを使用してエンドポイントと通信できるようにするJCAバインディング・コンポーネントです。Oracle JCA Adaptersは、Oracle SOA Service Infrastructureの一部としてではなく、JCAリソース(RAR)の一部としてデプロイされます。

Oracle JCA Adaptersには、次のような幅広いカテゴリのものがあります。

- Oracleテクノロジ・アダプタ

- レガシー・アダプタ

- パッケージ化されたアプリケーションのアダプタ

- Oracleアプリケーション用のOracleアダプタ

Oracle JCA Adaptersのタイプの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

この項では、様々なOracle JCA Adapterアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

特定のアダプタは、その特性に応じて、ローカルまたは共有のストレージ・ファイルを使用します。例:

- ファイルベースの永続ストアとともにWebLogic JMSを使用するJMSアダプタ: フェイルオーバー後に処理を再開するには、永続ストアがスタンバイ・サイトと同期化される必要があります。

- FileアダプタまたはFTPアダプタのいずれかからのインバウンドおよびアウトバウンド・ファイル: フェイルオーバー後に処理を再開するには、関連ファイルがスタンバイ・サイトと同期化される必要があります。

アダプタ構成は、ear JCAリソース(RAR)のweblogic-ra.xmlデプロイメント・ディスクリプタ内に保持されます。各weblogic-ra.xmlのファイルの場所は、ファイルの作成時に管理者によって決定されており、スタンバイ・サイトにレプリケートされる必要があります。

データベース内のアーティファクト

アダプタ・アーティファクトは、コンポジット・プロジェクトの一部として設計時に生成されます。これらのアーティファクトは、残りのコンポジット定義とともにメタデータ・リポジトリに格納されます。

同期化に関する推奨事項

ドメイン関連の構成の変更(つまり、アダプタ構成の変更)後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

JCAアダプタを実行している管理対象サーバーおよび管理サーバーとともに、データベースを直近の時点にリカバリする必要があります。

2.4.9 Oracle Business Activity Monitoringに関する推奨事項

Oracle Business Activity Monitoring(BAM)は、エンタープライズ内のビジネス・サービスおよびプロセスを監視するためのツールを提供します。これにより、市場の指標を実際のビジネス・プロセスと相関させることや、ビジネス・プロセスをすばやく変更したり、ビジネス環境の変化に応じて修正を加えたりすることが可能になります。Oracle BAMは、ダッシュボード(リアルタイムのデータ流入を表示し、特定の状況でアラートを送信するためのルールを定義する場所)の作成に必要なツールとランタイム・サービスを提供します。

この項では、様々なOracle BAMアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle BAMデータおよびレポート・メタデータは、Oracle BAMスキーマを含むOracle BAMデータベース内に格納されます。

同期化に関する推奨事項

ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data Guardが、BAMスキーマとメタデータ・リポジトリを含むOracle SOA Suiteデータベース用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle BAMを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。

2.4.10 Oracle Business Process Managementに関する推奨事項

Oracle Business Process Management(BPM) Suiteは、ビジネス・プロセスを中心にしたビジネス・アプリケーションを開発、管理および使用するための統合環境を提供します。それは、設計時および実装からランタイムおよびアプリケーション管理まで、アプリケーション開発ライフサイクルの全ステージをシームレスに統合します。

Oracle BPM SuiteはOracle SOA Suiteの上位レイヤーになり、次を含む製品コンポーネントの多くを共有しています。

- Oracle Business Rules

- ヒューマン・ワークフロー

- 統合のためのOracleアダプタ・フレームワーク

- SOAコンポジット・アーキテクチャ

この項では、様々なOracle BPMアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

BPM JMS永続ストア(BPMJMSFileStore_auto): ファイルベースのJMS永続ストア。フェイルオーバー後に処理を再開するには、永続ストアがスタンバイ・サイトと同期化される必要があります。

データベース内のアーティファクト

プロセス定義、デプロイ済アプリケーションおよび構成ファイルは、メタデータ・サービス(MDS)リポジトリに格納されます。Oracle BPMでは、プロセス・アナリストとプロセス開発者の間でプロジェクトとプロジェクト・テンプレートを共有するために、別のMDSパーティションも使用します。

同期化に関する推奨事項

ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始されると、スタンバイ・データベースも同じ時点まで更新されます。スナップショット・スタンバイ・データベースが使用される場合は、これをお薦めします。

リカバリに関する推奨事項

soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。

2.5 Oracle Identity Managementに関する推奨事項

Oracle Identity Management製品では、様々なサーバー間でユーザー、デバイスおよびサービスのアイデンティティを構成および管理し、それらのアイデンティティの管理を委任して、エンド・ユーザーにセルフサービス権限を付与することができます。これらの製品を使用して、アプリケーション間でシングル・サインオンを構成し、ユーザーの資格証明を処理して、有効な資格証明を持つユーザーのみがログインし、オンライン・リソースにアクセスできるようにすることが可能です。

すべてのOracle Identity Managementコンポーネントの共通アーティファクトと考慮事項

コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle Identity Managementコンポーネントに適用されます。

ファイル・システム上のアーティファクト

MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle Identity Managementバイナリが格納されるOracleホームから構成されます。

Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。

ドメイン・ホーム: ドメイン・ホームには、そのドメインの管理サーバーおよび管理対象サーバーの構成データ、およびアイデンティティ管理アプリケーションが含まれます。

Oracleインスタンス: Oracleインスタンスには、Oracle Internet DirectoryやOracle Virtual Directoryなどの非J2EEアイデンティティ管理アプリケーションの構成データが含まれます。OPMN構成データとEnterprise Managerエージェント構成データも含まれます。

データベース内のアーティファクト

アイデンティティ管理スキーマは、アイデンティティ管理データベース内にあります。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。

本番サイトとスタンバイ・サイトの両方で、アイデンティティ管理コンポーネントへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

該当のアイデンティティ管理コンポーネントとともに、アイデンティティ管理スキーマを含むデータベースを直近の時点にリカバリする必要があります。

この項の残りの部分では、次のOracle Identity Managementコンポーネントの障害時リカバリに関する推奨事項を示します。

- Oracle Internet Directoryに関する推奨事項

- Oracle Virtual Directoryに関する推奨事項

- Oracle Directory Integration Platformに関する推奨事項

- Oracle Identity Federationに関する推奨事項

- Oracle Directory Services Managerに関する推奨事項

- Oracle Access Managerに関する推奨事項

- Oracle Adaptive Access Managerに関する推奨事項

- Oracle Identity Managerに関する推奨事項

- Oracle Identity Navigatorに関する推奨事項

2.5.1 Oracle Internet Directoryに関する推奨事項

Oracle Internet Directoryは、分散するユーザー、ネットワーク構成および他のリソースに関する情報の迅速な取得と一元管理を可能にするLDAPバージョン3対応のサービスです。

この項では、様々なOracle Internet Directoryアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Internet Directoryによって使用されるODSおよびODSSMスキーマは、アイデンティティ管理データベースの一部です。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Internet Directoryに必要なロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Internet DirectoryをODSおよびODSSMスキーマと一緒に最新の時点にリカバリする必要があります。

2.5.2 Oracle Virtual Directoryに関する推奨事項

Oracle Virtual Directoryは、1つ以上のエンタープライズ・データソースの抽象化されたビューを提供するLDAPバージョン3対応のサービスです。Oracle Virtual Directoryは、複数のデータソースを単一のディレクトリ・ビューに統合し、LDAP対応アプリケーションを様々なディレクトリ・サーバーのデータ・ストアに統合することを可能にします。

この項では、様々なOracle Virtual Directoryアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Virtual Directoryには、データベース依存性はありません。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Virtual Directoryに必要なロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。

リカバリに関する推奨事項

Oracle Virtual Directoryインスタンスをリカバリします。

2.5.3 Oracle Directory Integration Platformに関する推奨事項

Oracle Directory Integration Platformは、他のディレクトリまたはデータベースとOracle Internet Directoryの間でデータを同期化できるようにするJ2EEアプリケーションです。Oracle Directory Integration Platformは、他のエンタープライズ・リポジトリとともに同期化ソリューションをデプロイできるようにするためのサービスとインタフェースを提供します。また、これを使用して、サード・パーティのメタディレクトリ・ソリューションとOracle Internet Directoryの相互運用性を実現することもできます。

この項では、様々なOracle Directory Integration Platformアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

ODSおよびODSSMスキーマは、アイデンティティ管理データベースの一部です。Quartzジョブは、ODSSMスキーマ内にあります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層およびデータ層をスタンバイ・サイトと同期化する必要があります。

リカバリに関する推奨事項

Oracle Directory Integration Platformアプリケーションを実行している管理対象サーバーおよび関連付けられたOracle Internet Directoryインスタンスとともに、Oracle Internet DirectoryをODSおよびODSSMスキーマと一緒に直近の時点にリカバリする必要があります。

2.5.4 Oracle Identity Federationに関する推奨事項

企業では、Oracle Identity Federationを使用して、個々のセキュリティ・ドメイン間におけるサービスの提供とアイデンティティの共有、および許可されていないアクセスからの保護を実現できます。

この項では、様々なOracle Identity Federationアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Identity Federationは、アイデンティティ管理データベースの一部であるOIFスキーマを使用します。RDBMSユーザー・ストア、構成ストア、Federationストア、メッセージ・データ・ストアまたはセッション・ストアがOracle Identity Federation用に構成されている場合、これらのストアは、外部データベースに格納されます。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Identity Federation用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Identity Federationアプリケーションを実行している管理対象サーバーとともに、Oracle Identity Federationスキーマを含むデータベースとデータ・ストアを直近の時点にリカバリする必要があります。

2.5.5 Oracle Directory Services Managerに関する推奨事項

Oracle Directory Services Managerは、Oracle Virtual DirectoryとOracle Internet Directoryのための統合されたグラフィカル・ユーザー・インタフェース(GUI)です。Webベースのフォームおよびテンプレートを使用できるようにすることで、Oracle Virtual DirectoryとOracle Internet Directoryの管理と構成を簡略化します。

この項では、様々なOracle Directory Services Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Directory Services Managerアプリケーションにはデータベース依存性がないため、適用されません。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Directory Services Manager用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

管理サーバーとともに、Oracle Directory Services Managerアプリケーションを実行している管理対象サーバーをリカバリします。

2.5.6 Oracle Access Managerに関する推奨事項

Oracle Access Managerは、Webシングル・サインオン、ユーザーのセルフサービスと自己登録、高度なワークフロー機能、監査とアクセス・レポート、ポリシー管理、動的グループ管理、委任管理など、広範なアイデンティティ管理およびセキュリティ機能を提供します。

この項では、様々なOracle Access Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Access Managerは、Oracle Identity Managementデータベースの一部であるOAM、IAU(Audit Services)スキーマおよびODSスキーマ(Oracle Internet Directory用)を使用します。

LDAPストア

Oracle Access Managerは、構成およびユーザー情報をOracle Internet Directoryに格納します。

特別な考慮事項

Oracle Access Managerコンソールは、ドメインの管理サーバーにデプロイされます。本番サイトとスタンバイ・サイトの両方で、Oracle Access Manager用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Access Managerアプリケーションを実行している管理対象サーバー、管理サーバーおよび関連するOracle Internet Directoryインスタンスをリカバリします。OAM、IAUおよびODSスキーマを、最新の時点にリカバリする必要があります。

2.5.7 Oracle Adaptive Access Managerに関する推奨事項

Oracle Adaptive Access Managerは、エンタープライズ向けにWebアクセスのリアルタイム不正検出およびオンライン多要素認証セキュリティを提供するOracle Identity Managementのソリューションです。Oracle Adaptive Access Managerは、異機種が混在する複雑なエンタープライズ環境をサポートするように設計されています。

この項では、様々なOracle Adaptive Access Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Adaptive Access Managerは、Oracle Identity Managementデータベースの一部であるOAAM、OAAM PARTN、MDS、IAU(Audit Services)およびODS(Oracle Internet Directory)スキーマを使用します。

パーティション・スキーマ・サポート付きのOracle Adaptive Access Managerの場合、 Identity Management - Oracle Adaptive Access Manager (パーティション・サポート) スキーマを選択します。デフォルトで、 AS共通スキーマ - メタデータ・サービス ・スキーマも選択されます。

LDAPストア

Oracle Adaptive Access Managerは、構成およびユーザー情報をOracle Internet Directoryに格納します。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Adaptive Access Manager用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Adaptive Access Managerアプリケーションを実行している管理対象サーバーおよび関連するOracle Internet Directoryインスタンスをリカバリします。OAAM、OAAM_PARTN、MDS、IAUおよびODSスキーマを、最新の時点にリカバリする必要があります。

2.5.8 Oracle Identity Managerに関する推奨事項

Oracle Identity Managerは、ユーザー・プロビジョニングおよび管理ソリューションです。これによって、アプリケーションやディレクトリに対してユーザー・アカウントの追加、更新および削除を行うプロセスが自動化されます。さらに、どのユーザーがどのアプリケーションにアクセスできるかを特定するきめ細かいレポートと証明サポートを提供し、法規制のコンプライアンスが向上します。Oracle Identity Managerは、スタンドアロン製品として、またはOracleのIdentity and Access Management Suiteの一部として使用可能です。

Oracle Identity Managerは、ワークフローにOracle SOAを使用します。また、Oracle SOAの障害時リカバリに関する推奨事項にも従う必要があります。詳細は、「Oracle SOA Suiteに関する推奨事項」を参照してください。

この項では、様々なOracle Identity Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

JMS ストア: ファイルベースのJMS永続ストアを含むボリューム。

データベース内のアーティファクト

Oracle Identity Managerは、Oracle Identity Managementデータベースの一部であるOIM、SOAINFRA、ORASPDMおよびMDSスキーマを使用します。

LDAPストア

スタンドアロン・モードで使用した場合、Oracle Identity Managerは、外部のLDAPストアには依存しません。LDAP同期が有効なときや、Oracle Access ManagerまたはOracle Identity Federationに統合されているときは、Oracle Identity Managerは外部LDAPストアとユーザーを同期します。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Identity Manager用のロード・バランサの仮想ホストを構成する必要があります。

Oracle Identity ManagementとSOA管理対象サーバーは、浮動IPアドレスをリスニングするように構成されています。これは、サーバー移行のために必要です。本番サイトとスタンバイ・サイトの両方で、浮動IPアドレスが同じ仮想名で構成されていることを確認してください。

Oracle Identity Managerのコネクタはファイルベースです。これらは、別のエンタープライズ・アプリケーションのレコードをプロビジョニングまたは調整するために使用されます。Oracle Identity Managerおよびアプリケーションでコネクタが使用可能なことを確認してください。

Oracle Identity Managementは、JMS永続性ストアにも依存しています。詳細は、「Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項」を参照してください。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

JMS永続性ストアの詳細は、「Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項」を参照してください。

リカバリに関する推奨事項

Oracle Identity Managerアプリケーションを実行している管理対象サーバーおよび関連するOracle Internet Directoryインスタンスをリカバリします。OIM、SOAINFRA、ORASPDMおよびMDSスキーマを、最新の時点にリカバリする必要があります。LDAP同期が有効なとき、Oracle Identity ManagementはODSスキーマに依存します。その場合は、ODSも最新の時点にリカバリしてください。

2.5.9 Oracle Identity Navigatorに関する推奨事項

Oracle Identity Navigatorは、Oracle Identity Managementの全製品のアプリケーション・コンソールとして機能するように設計されている管理ポータルです。これは、個々の製品コンソールに代わるものではありません。Oracle Identity Navigatorにはブラウザ経由でアクセスし、これを使用してOracle Access Manager、Oracle Adaptive Access Manager、Oracle Identity Manager、Directory Services(ODSM)およびその他のOracle Identity Managementのサービスのコンソールにアクセスします。これらのコンソールに接続するようにOracle Identity Navigatorを構成するには、直接URLを指定するか、製品検出機能を使用します。Oracle Identity Management Navigatorを使用すると、Oracle Identityのすべてのコンソールを1つのサイトから簡単に管理できます。

この項では、様々なOracle Identity Navigatorアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Identity Navigatorでは、スキーマは使用しません。

LDAPストア

Oracle Identity Navigatorは、構成情報をLDAPストアに格納します。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Identity Navigator用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Identity Navigatorアプリケーションを実行している管理サーバーをリカバリします。

2.6 Oracle Portal、Forms、ReportsおよびDiscovererに関する推奨事項

この項では、次のOracleコンポーネント・スイートのアーティファクトおよび障害時リカバリに関する推奨事項を示します。

- Oracle Portal

- Oracle Forms

- Oracle Reports

- Oracle Business Intelligence Discoverer(Discoverer)

Oracle Portal、Forms、ReportsおよびDiscovererの共通アーティファクトと考慮事項

この項で示すアーティファクトと考慮事項は、Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererに共通です。

ファイル・システム上のアーティファクト

MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererのバイナリが格納されるOracleホームから構成されます。

Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。

ドメイン・ホーム: ドメイン・ホームには、そのドメインの管理サーバーおよび管理対象サーバーの構成データ、およびOracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererアプリケーションが含まれます。

Oracleインスタンス: Oracleインスタンスには、Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererコンポーネントの構成データが含まれます。OPMNとEMAgentの構成データも含まれます。

データベース内のアーティファクト

データベース・メタデータ・リポジトリには、Oracle Portal、Oracle ReportsおよびDiscovererコンポーネント・スキーマおよびユーザー構成済データベースが含まれます。

データベース・メタデータ・リポジトリ(RCU)にはOracle Formsコンポーネント・スキーマはありませんが、Oracle Forms経由でアクセスされているユーザー構成済データベース内に顧客データが存在する可能性があります。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。

本番サイトとスタンバイ・サイトの両方で、Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

Oracle Portal、Oracle ReportsおよびDiscovererコンポーネント・スキーマを含むデータベースを最新の時点にリカバリする必要があります。Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererコンポーネント・アプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。

この項の残りの部分では、次のコンポーネントの障害時リカバリに関する推奨事項を示します。

- Oracle Portalに関する推奨事項

- Oracle Formsに関する推奨事項

- Oracle Reportsに関する推奨事項

- Oracle Business Intelligence Discovererに関する推奨事項

2.6.1 Oracle Portalに関する推奨事項

Oracle Portalは、Oracle Fusion Middlewareと密接に統合されたポータルを構築、デプロイおよび管理するするための完全なポータル・フレームワークを提供します。Oracle Portalは、ポータルWebインタフェースを作成して動的データにアクセスするための機能豊富な宣言型環境を、Java EEベースのエンタープライズ・アプリケーションにアクセスするための拡張可能なフレームワークとともに提供します。

この項では、様々なOracle Portalアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Portal、Portal_Demo、Portal_App、Portal_PublicおよびPortal_Approvalスキーマは、Oracle Portalメタデータ・リポジトリの一部です。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、ポータルにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Portalスキーマを含むデータベースを最新の時点にリカバリする必要があります。Oracle Portalアプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。

2.6.2 Oracle Formsに関する推奨事項

Oracle Formsは、エンタープライズ・アプリケーションを迅速かつ効率的に設計および構築するための、長年にわたって築き上げられてきたOracleのテクノロジです。

この項では、Oracle Forms固有のアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Formsアプリケーション用のユーザー構成済データベース。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Formsにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data Guardがユーザー構成済アプリケーション・データベース用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Formsアプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。ユーザー構成済データベースがある場合は、それらを最新の時点にリカバリする必要があります。

2.6.3 Oracle Reportsに関する推奨事項

Oracle Reportsは、Oracle Fusion Middlewareのレポート公開コンポーネントです。それは、形式と場所を問わずどのようなデータでも動的に取得、書式設定および配布する高品質な本番レポートを作成するためのエンタープライズ・レポート・サービスです。Oracle Reportsを使用して、Webベース環境と非Webベース環境の両方でレポートを公開できます。

この項では、様々なOracle Reportsアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

Reportsホーム: レポート定義ファイルを含むユーザー定義の場所です。これは、OracleインスタンスまたはOracleホームの下にある場合もあります。

データベース内のアーティファクト

Oracle Reportsは、スケジュール済ジョブのデータ、過去のジョブのデータ、ジョブ・ステータスのデータなど、ジョブ関連情報をデータベースに格納するように構成できます。これは、ユーザー構成済データベースです。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Reportsにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

構成またはユーザー情報を他のコンポーネント(Oracle PortalやOracle Internet Directoryなど)に格納するようにReports Serverが構成されている場合は、本番サイトとスタンバイ・サイト間でこれらのコンポーネントを確実に同期化するようにしてください。

Oracle Data GuardがOracle Reportsデータベース用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Reportsアプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。ユーザー構成済データベースがある場合は、それらを最新の時点にリカバリする必要があります。また、関連付けられているOracle PortalおよびOracle Internet Directoryインスタンスもリカバリしてください。

2.6.4 Oracle Business Intelligence Discovererに関する推奨事項

Oracle Business Intelligence Discoverer(Discoverer)は、データ分析用のビジネス・インテリジェンス・ツールです。これは、Oracle Fusion Middlewareの重要なコンポーネントです。Discovererでは、直感的な非定型の問合せ、レポート作成、分析およびWeb公開機能で構成される統合化ビジネス・インテリジェンス・ソリューションが提供されます。これらのツールを使用して、技術者ではないユーザーでもデータ・マート、データ・ウェアハウス、マルチディメンショナル(OLAP)データソースおよびオンライン・トランザクション処理システムの情報に即時にアクセスできます。Discovererは、Oracle PortalおよびOracle WebCenter Portalとシームレスに統合されるため、Discovererのワークブックおよびワークシートを各Webポータルに迅速にデプロイできます。

この項では、様々なDiscovererアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

DISCOVERERおよびDISCOVERER_PSスキーマは、Discovererメタデータ・リポジトリの一部です。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Discovererにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Discovererスキーマを含むデータベースを直近の時点にリストアする必要があります。

Discovererアプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。

2.7 Oracle Web Tierコンポーネントに関する推奨事項

J2EEアプリケーション・サーバーのWeb層は、Webブラウザなど、主にHTTPリクエストおよびレスポンスの形式でのエンド・ユーザーとの対話を処理します。これは、HTTPスタックにおける一番外側の層で、エンド・ユーザーに最も近い層です。

この項では、次のOracle Web Tierコンポーネントの障害時リカバリに関する推奨事項を示します。

- Oracle HTTP Serverに関する推奨事項

- Oracle Web Cacheに関する推奨事項

2.7.1 Oracle HTTP Serverに関する推奨事項

Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。それは、Oracle WebLogic Server用のリスナーと、静的ページ、動的ページおよびWeb上のアプリケーションをホストするフレームワークを提供します。

Oracle HTTP Serverは、Apache 2.2.xインフラストラクチャに基づいており、Oracleによって特別に開発されたモジュールを含んでいます。シングル・サインオン、クラスタ・デプロイメントおよび高可用性の機能により、Oracle HTTP Serverの操作が強化されます。

この項では、様々なOracle HTTP Serverアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

Oracleホーム: Oracleホームは、Oracle HTTP Serverバイナリから構成されます。

Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。

Oracleインスタンス: Oracleインスタンスには、Oracle HTTP Serverの構成データと診断データが含まれます。OPMNとEnterprise Managerエージェントの構成データも含まれます。

静的コンテンツ・ボリューム: このボリュームには、Oracle HTTP Serverインスタンスによって処理される静的コンテンツが格納されます。静的なHTMLコンテンツを格納するこのボリュームはオプションです。Oracle Fusion Middlewareは、このボリュームがなくても正常に機能します。

データベース内のアーティファクト

Oracle HTTP Serverにはデータベース依存性がないため、適用されません。

特別な考慮事項

Oracle HTTP Serverの特別な考慮事項は、次のとおりです。

- 本番サイトとスタンバイ・サイトの両方で、Oracle HTTP Serverにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。

- このマニュアルでは、共有記憶域に11g Oracle Fusion Middlewareインスタンス(Oracle HTTP Serverインスタンスを含む)をインストールしたと想定しています。Oracle HTTP Server 11gのOracleインスタンスが、信頼できるファイル・ロック機能を持たない共有記憶域(NASストレージ、NFSストレージ、SANストレージなど)に構成されている場合、Oracle HTTP Serverでパフォーマンスの問題が発生する可能性があります。
一部の共有ストレージ・システムは、11g Oracle HTTP Serverが必要としている、信頼できるファイル・ロック機能を提供していません。その場合、httpd.confファイル内のLockFileディレクティブを、ローカル・ファイル・システムを指すように変更する必要があります。

LockFileディレクティブの詳細は、次のURLにあるApacheのドキュメントを参照してください。

http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex

11g Oracle HTTP Serverインスタンスが共有記憶域にインストールされており、パフォーマンスの問題が発生している場合は、Oracle HTTP Serverインスタンスに対して次の手順を実行して、ローカル・ファイル・システムのLockFileディレクティブを指すようにします。

1. デフォルトでは、LockFileは次の形式で、httpd.confファイル内のprefork MPM構成ブロックとworker MPM構成ブロックの両方の下に構成されています。

${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/${COMPONENT_NAME/http_lock

2. 適切な方法を使用して、$ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.confファイルを編集します。

3. 正しいMPM構成の下のLockFileディレクティブを、ローカル・ファイル・システムを指すように変更します。

LockFile /<local_disk>/<path>/http_lock

4. Oracle HTTP Serverを再起動します。

これらの手順を実行した後、LockFileディレクティブによって指定されたディレクトリにhttp_lockファイルが存在することを確認します。

同期化に関する推奨事項

構成の変更後は、手動でOracle HTTP Serverインスタンスをスタンバイ・サイトと同期化する必要があります。

リカバリに関する推奨事項

スタンバイ・サイトでOracle HTTP Serverインスタンスおよび関連する構成ファイルをリストアします。

2.7.2 Oracle Web Cacheに関する推奨事項

Oracle Web Cacheは、Web層で使用されるコンテンツ認識型のサーバー・アクセラレータ(リバース・プロキシ)です。Oracle HTTP ServerやOracle WebLogic Serverといった任意のWebサーバーまたはアプリケーション・サーバーで稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。

Oracle Web Cacheは、Oracle Fusion Middlewareとともに提供される主要なキャッシュ・メカニズムです。キャッシュにより、頻繁にアクセスされるURLをメモリーに格納して、Oracle Fusion Middleware上で稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を向上させることができます。

この項では、様々なOracle Web Cacheアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

Oracleホーム: Oracleディレクトリ・ホームは、Oracle Web Cacheバイナリから構成されます。

Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。

Oracleインスタンス: Oracleインスタンスには、Oracle Web Cacheの構成データが含まれます。OPMNとEnterprise Managerエージェントの構成データも含まれます。

データベース内のアーティファクト

Oracle Web Cacheにはデータベース依存性がないため、適用されません。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Web Cacheにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後は、手動でOracle Web Cacheインスタンスをスタンバイ・サイトと同期化する必要があります。

リカバリに関する推奨事項

スタンバイ・サイトでOracle Web Cacheインスタンスおよび関連する構成ファイルをリストアします。

2.8 Oracle WebCenter Contentに関する推奨事項

Oracle WebCenter Contentは、コンテンツの管理のために設計された製品の統合スイートです。このOracle WebCenter Contentプラットフォームにより、業界最先端のドキュメント管理、Webコンテンツ管理、デジタル資産管理およびレコード管理機能を利用して、ビジネス・アプリケーションを構築できます。コンテンツおよびアプリケーションの戦略的なエンタープライズ・コンテンツ管理インフラストラクチャを構築すると、コストの削減、エンタープライズ間のコンテンツ共有の容易化、リスクの最小化、高価で時間のかかる手動プロセスの自動化、および単一プラットフォームへの複数Webサイトの統合化が促進されます。

すべてのOracle WebCenter Contentコンポーネントの共通アーティファクトと考慮事項

コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle WebCenter Contentコンポーネントに適用されます。

ファイル・システム上のアーティファクト

MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle WebCenter Contentバイナリが格納されるOracleホームから構成されます。

Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。

ドメイン・ホーム: ドメイン・ホームには、そのドメインの管理サーバーおよび管理対象サーバーの構成データ、およびOracle WebCenter Contentアプリケーションが含まれます。

Oracleインスタンス: Oracleインスタンスには、OPMN構成データやEnterprise Managerエージェント構成データなどの非J2EE Oracle WebCenter Contentアプリケーションの構成データが含まれます。

データベース内のアーティファクト

Oracle WebCenter Contentスキーマは、Oracle WebCenter Contentデータベース内にあります。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。

本番サイトとスタンバイ・サイトの両方で、Oracle Enterprise Content Managementコンポーネントへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

該当のアイデンティティ管理コンポーネントとともに、Oracle WebCenter Contentスキーマを含むデータベースを直近の時点にリカバリする必要があります。

この項の残りの部分では、次のOracle Enterprise Content Managementコンポーネントの障害時リカバリに関する推奨事項を示します。

- Oracle WebCenter Contentに関する推奨事項

- Oracle WebCenter Content: Inbound Refineryに関する推奨事項

- Oracle WebCenter Content: Imagingに関する推奨事項

- Oracle WebCenter Content: Information Rightsに関する推奨事項

- Oracle WebCenter Content: Recordsに関する推奨事項

2.8.1 Oracle WebCenter Contentに関する推奨事項

Oracle WebCenter Contentは、様々な種類のコンテンツ管理を目的とした統合アプリケーションです。

Oracle WebCenter Contentはエンタープライズ・コンテンツ管理プラットフォームであり、これを使用すると、ドキュメント管理、Webコンテンツ管理、デジタル資産管理およびレコード保持機能を活用して、ビジネス・アプリケーションの構築と補完を行うことができます。コンテンツおよびアプリケーションの戦略的なエンタープライズ・コンテンツ管理インフラストラクチャを構築すると、コストの削減、エンタープライズ間のコンテンツ共有の容易化、リスクの最小化、高価で時間のかかる手動プロセスの自動化、および複数のWebサイトの単一プラットフォームへの(一元管理を目的とした)統合化が促進されます。Oracle WebCenter Contentでは、ユーザーフレンドリなインタフェース、ロールベースの認証およびセキュリティ・モデルを使用することによって、全社規模のユーザーでコンテンツに対する表示、共同作業および廃棄ができるようになるため、配布済または公開済のアクセス可能な情報は、すべてセキュア、正確かつ最新な状態であることが保証されます。

この項では、様々なOracle WebCenter Contentアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

Oracle Secure Filesまたはファイルベースの永続ストア。

データベース内のアーティファクト

OCSスキーマは、Oracle WebCenter Contentデータベースの一部です。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle WebCenter Contentに必要なロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

ファイルベースの永続ストアの場合、スタンバイ・サイトのファイルベースの永続ストアを同期化する必要があります。

リカバリに関する推奨事項

OCSおよびMDSスキーマとともに、Oracle WebCenter Contentを最新の時点にリカバリする必要があります。

2.8.2 Oracle WebCenter Content: Inbound Refineryに関する推奨事項

Oracle WebCenter Content: Inbound Refineryは、ドキュメント、デジタル・イメージ、動画などの電子アセット用のファイル変換を管理する変換サーバーです。変換の他に、ドキュメントとイメージに対するサムネイル機能、ビデオのストーリーボード作成機能、デジタル・イメージからEXIFデータを抽出して使用する機能、およびAdobe PhotoshopやAdobe Illustratorなどのプログラムから生成された電子ファイルからXMPデータを抽出して使用する機能があります。Oracle WebCenter Content: Inbound Refineryを使用して、Oracle Content Serverに格納されているコンテンツ項目を変換できます。

この項では、様々なOracle WebCenter Content: Inbound Refineryアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle WebCenter Content: Inbound Refineryには、データベース依存性はありません。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle WebCenter Content: Inbound Refineryに必要なロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。

リカバリに関する推奨事項

Oracle WebCenter Content: Inbound Refineryインスタンスをリカバリします。

2.8.3 Oracle WebCenter Content: Imagingに関する推奨事項

Oracle WebCenter Content: Imagingは、プロセス志向のイメージング・アプリケーションやイメージ利用のソリューションを開発するための、拡張性の高いソリューションを提供します。Oracle Document CaptureおよびOracle Distributed Document Captureを使用したイメージの取込み、イメージの注釈付けとマークアップ、ルーティングと承認の自動化に対するワークフロー・サポート、および数百万件の項目を処理する大容量アプリケーションのサポートなどを利用できます。Oracle WebCenter Content: Imagingを使用すると、Oracle E-Business Suite、PeopleSoft Enterprise、JD Edwards EnterpriseOneなどのOracleエンタープライズ・アプリケーションに、組織のコンテンツとプロセスを迅速に直接統合できます。トランザクション・ベースの全コンテンツに対してソースを一元化することにより、ユーザーは二重入力が不要になるなどの利点を得ることができます。

この項では、様々なOracle WebCenter Content: Imagingアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

IPM入力エージェントは、共通のファイル共有からファイルを取得します。このIPMファイルは、スタンバイ・サイトと同期化される必要があります。

データベース内のアーティファクト

IPMスキーマは、Oracle WebCenter Content: Imagingデータベースの一部です。Oracle WebCenter Content: Imagingは、Oracle WebCenter Content: ImagingリポジトリとしてOracle WebCenter Contentを使用するために、OCSスキーマも必要とします。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層およびデータ層をスタンバイ・サイトと同期化する必要があります。

JMSストアであるIPMJMSServerStoreをファイルベースの永続ストアと同期化する必要があります。詳細は、第2.1.1項「Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項」を参照してください。

リカバリに関する推奨事項

Oracle WebCenter Content: Imagingアプリケーションを実行している管理対象サーバーおよび関連付けられたインスタンスとともに、Oracle WebCenter Content: ImagingとIPMスキーマを直近の時点にリカバリする必要があります。

2.8.4 Oracle WebCenter Content: Information Rightsに関する推奨事項

Oracle WebCenter Content: Information Rightsは、一元管理されているサーバーとデスクトップ・エージェントの間で権利の管理を行います。

Oracle WebCenter Content: Information Rightsでは、Microsoft Windowsデスクトップ、オーサリング・アプリケーション、電子メール・クライアントおよびコンテンツ管理/コラボレーション・リポジトリに統合されているシール・ツールを使用して、ドキュメントや電子メールが、それらのライフサイクルの任意の段階で、自動または手動でシールされるようにできます。シール処理により、強力な暗号化およびデジタル署名によって保護された層に、ドキュメントと電子メールがラップされます。このとき、該当する情報を所有する組織によって運用され、復号化キーおよび関連するアクセス権が格納されている、ネットワークでホストされているサーバーに戻るための消去不能なリンクが一緒に含められます。

シール済ドキュメントおよび電子メールは、電子メール、Web、ファイル共有などの既存の手段で分散できます。

この項では、様々なOracle WebCenter Content: Information Rightsアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

ORAIRMスキーマは、Oracle WebCenter Content: Information Rightsデータベースの一部です。Oracle WebCenter Content: Information Rightsをインストールする際に、Oracle IRM J2EEアプリケーションで使用されるキー・ストアがデータベースとともに作成されます。キー・ストアは、ドメイン・ホームの下のディレクトリに配置することをお薦めします。そうすれば、ドメインのリストア時にキー・ストアが自動的に使用可能になります。キー・ストアがドメインの下に格納されていない場合、手動でキー・ストアをレプリケートされたシステムにコピーする必要があります。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Identity Federation用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle WebCenter Content: Information Rightsアプリケーションを実行している管理対象サーバーとともに、Oracle WebCenter Content: Rightsスキーマおよびデータ・ストアを含むデータベースを直近の時点にリカバリする必要があります。

2.8.5 Oracle WebCenter Content: Recordsに関する推奨事項

Oracle WebCenter Content: Recordsは、各コンテンツ・アイテムのライフ・サイクルを決定する保存スケジュールに従って、コンテンツ・アイテムを効率的に管理します。

レコード管理の主眼は、履歴やアーカイブとして、または法的な目的でコンテンツを保持することに置かれる傾向がありますが、一方で保持管理も実行されます。保持管理の主眼は、コンテンツの保存にかかるコストが、それを保持することにより得られる価値を上回る場合に、スケジュールに従ってコンテンツを削除することに置かれる傾向があります。

Oracle WebCenter Content: Recordsは、レコード管理と保存管理を1つのソフトウェア・システムに統合しています。Oracle WebCenter Content: Recordsを使用すると、必要に応じたコンテンツの追跡および保存、または不要になったコンテンツの処分が可能になります。

この項では、様々なOracle WebCenter Content: Recordsアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

URMSERVERおよびMDSスキーマは、Oracle WebCenter Content: Recordsデータベースの一部です。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle WebCenter Content: Records用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

管理サーバーとともに、Oracle WebCenter Content: Recordsアプリケーションを実行している管理対象サーバーをリカバリします。

2.9 Oracle Business Intelligenceに関する推奨事項

Oracle Business Intelligence(BI)は、テクノロジとアプリケーションの製品ラインであり、業界で最初に統合されたエンドツーエンドのエンタープライズ・パフォーマンス管理システムです。このシステムには、BIのファウンデーションおよびツール、さらに財務実績管理アプリケーション、運用BIアプリケーションおよびデータ・ウェアハウスが含まれます。

すべてのOracle Business Intelligenceコンポーネントの共通アーティファクトと考慮事項

コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle Business Intelligenceコンポーネントに適用されます。

ファイル・システム上のアーティファクト

MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle Business Intelligenceバイナリが格納されるOracleホームから構成されます。

Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。

ドメイン・ホーム: ドメイン・ホームには、そのドメインの管理サーバーおよび管理対象サーバーの構成データ、およびOracle Business Intelligenceアプリケーションが含まれます。

Oracleインスタンス: Oracleインスタンスには、1つ以上のOracleシステム・コンポーネント(Oracle BI Server、Oracle BI Presentation Services、Oracle HTTP Serverなど)の構成ファイル、ログ・ファイルおよび一時ファイルが格納されます。

データベース内のアーティファクト

Oracle Business Intelligenceスキーマは、Oracle Business Intelligenceデータベース内にあります。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。

本番サイトとスタンバイ・サイトの両方で、Oracle Business Intelligenceコンポーネントへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

該当のアイデンティティ管理コンポーネントとともに、Oracle Business Intelligenceスキーマを含むデータベースを直近の時点にリカバリする必要があります。

この項の残りの部分では、次のOracle Business Intelligenceコンポーネントの障害時リカバリに関する推奨事項を示します。

- Oracle Business Intelligence Enterprise Edition(EE)に関する推奨事項

- Oracle Business Intelligence Publisherに関する推奨事項

- Oracle Real-Time Decisionsに関する推奨事項

2.9.1 Oracle Business Intelligence Enterprise Edition(EE)に関する推奨事項

Oracle Business Intelligence Enterprise Edition(Oracle BI EE)は包括的な一連のエンタープライズ・ビジネス・インテリジェンス・ツールおよびインフラストラクチャであり、拡張性のある効率的な問合せおよび分析サーバー、非定型の問合せおよび分析ツール、インタラクティブ・ダッシュボード、プロアクティブ・インテリジェンスとアラート、リアルタイム予測インテリジェンス、エンタープライズ・レポート・エンジンなどが含まれます。Oracle Business Intelligence Enterprise Editionは、ビジネスの可視性と洞察力を幅広いユーザーに向けて高められるように設計されています。

データベース内のアーティファクト

BIPLATFORMスキーマは、Oracle Business Intelligence Enterprise Edition(EE)データベースの一部です。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Business Intelligence Enterprise Edition(EE)用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Middlewareホーム、ドメイン、およびOracle Business Intelligence Enterprise Edition(EE)コンポーネントを含むOracleインスタンスをリカバリします。Windowsに、Oracle Business Intelligence Enterprise Edition(EE)レジストリ・エントリをインポートします。必要に応じて、データベースを直近の時点にリカバリします。

2.9.2 Oracle Business Intelligence Publisherに関する推奨事項

Oracle Business Intelligence Publisher (BI Publisher、旧名はXML Publisher)を使用すると、印刷に適した書式に設定されたレポートを作成できます。BI Publisherレポートは、BI Publisherデータ・モデルに基づいて作成されます。BI Publisherデータ・モデルは、BIサーバーや分析からのサブジェクト・エリア、リレーショナル・データベースに対するSQL問合せ、Subbaseや他のOLAPソースに対するMDX問合せ、LDAP、Webサービス、Microsoft Excel、HTTPフィード、XMLファイルなどの広範なソースからのデータ・セットで構成されます。BI Publisherでは、様々なレイアウト・タイプがサポートされるため、組織で必要なあらゆる種類のドキュメントを作成できます。Oracle BI EE内で、BI Publisherレポートの表示、作成、編集およびスケジュールを行ったり、レポートをダッシュボード・ページに含めたりできます。

データベース内のアーティファクト

BIPLATFORMスキーマは、Oracle Business Intelligence Publisherデータベースの一部です。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Business Intelligence Publisher用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Business Intelligence Publisherコンポーネントを含む管理対象サーバーをリカバリします。

2.9.3 Oracle Real-Time Decisionsに関する推奨事項

Oracle Real-Time Decisions (Oracle RTD)は、適応性の高いエンタープライズ・ソフトウェア・ソリューションの開発を可能にします。こうした適応性のあるソリューションは、ビジネス・トランザクションが実行される際に継続的に学習し、クローズ・ループ型のビジネス・ルールと予測モデルに従って、各トランザクションをリアルタイムで自動的に最適化します。

データベース内のアーティファクト

分析モデルおよびRTDスキーマは、Oracle Real-Time Decisionsデータベースの一部です。

特別な考慮事項

本番サイトとスタンバイ・サイトの両方で、Oracle Real-Time Decisions用のロード・バランサの仮想ホストを構成する必要があります。

同期化に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle Real-Time Decisionsコンポーネントが含まれる管理対象サーバーをリカバリします。

3 設計上の考慮事項

この章では、エンタープライズ・デプロイメントにおけるOracle Fusion Middleware障害時リカバリ・ソリューションに関する設計上の考慮事項について説明します。

内容は次のとおりです。

- ネットワークに関する考慮事項

- ストレージに関する考慮事項

- データベースに関する考慮事項

- 開始ポイント

- トポロジに関する考慮事項

注意:

Oracle Site Guardを使用してスイッチオーバーやフェイルオーバーなどの障害回復操作を自動化することができます。詳細は、第5章「Oracle Site Guardの使用方法」を参照してください。

この章では、LinuxおよびUNIXオペレーティング・システムでOracle Fusion Middleware 11g障害時リカバリの本番サイトとスタンバイ・サイトを設定する際の詳細な手順を説明します。エンタープライズ・デプロイメントのOracle Fusion Middleware 11g障害時リカバリ・ソリューションを設定する方法の例では、主に、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。Oracle SOA Suiteエンタープライズ・トポロジの障害時リカバリを設定する方法を理解したら、この章に記載されているその他の11gエンタープライズ・デプロイメントに関する情報を参照して、それらのデプロイメントの障害時リカバリを設定することもできます。

注意:

この章では、本番サイトとスタンバイ・サイトの両方で、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用するOracle Fusion Middleware 11g障害時リカバリの対称トポロジについて説明します。図3-1は、一方のサイトのみのデプロイメントを示しています。この図では、デプロイメントの詳細をわかりやすくするために、両方のサイトのデプロイメントを1つの図に示していません。

障害時リカバリの対称型の本番サイトとスタンバイ・サイトを1つの図に示したものについては、図1-1を参照してください。

図3-1 Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトで使用するデプロイメント

「図3-1 Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトで使用するデプロイメント」の説明

図3-1は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle Access Managerエンタープライズ・デプロイメントを使用したmySOACompanyを示しています。このOracle SOA Suiteエンタープライズ・デプロイメントのインストールおよび構成に関する詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

設計するOracle Fusion Middleware障害時リカバリ・トポロジは、本番サイトとスタンバイ・サイトで次の点について対称である必要があります。

- ディレクトリ名およびパス
本番サイトのホストに存在するすべてのファイルが、スタンバイ・サイトのピア・ホストの同一ディレクトリおよびパスに存在する必要があります。

つまり、Oracleホームの名前とディレクトリ・パスが本番サイトとスタンバイ・サイトで同じである必要があります。

- ポート番号
ポート番号は、リスナーによってリクエストのルーティングに使用されます。ポート番号は構成に保存され、本番サイトのホストとスタンバイ・サイトのピア・ホストで同じである必要があります。

本番サイトとスタンバイ・サイトのホスト間におけるポートの競合を確認する方法については、第3.4.1項「既存のサイトを基にした設計」を参照してください。

- セキュリティ
本番サイトとスタンバイ・サイトの両方に同じユーザー・アカウントが必要です。また、本番サイトとスタンバイ・サイトで、ファイル・システム、SSLおよびシングル・サインオンを同様に構成する必要があります。たとえば、本番サイトでSSLを使用している場合、スタンバイ・サイトでも、本番サイトとまったく同様に構成したSSLを使用する必要があります。

- ロード・バランサと仮想サーバー名
本番サイトについては、仮想サーバー名を使用してフロントエンド・ロード・バランサを設定する必要があります。スタンバイ・サイトについては、同じ仮想サーバー名を使用して同一のフロントエンド・ロード・バランサを設定する必要があります。

- ソフトウェア
本番サイトとスタンバイ・サイトで同じバージョンのソフトウェアを使用する必要があります。また、両方のサイトでオペレーティング・システムのパッチ・レベルが同じである必要があります。さらに、本番サイトとスタンバイ・サイトの両方にOracleまたはサード・パーティ・ソフトウェアのパッチを適用する必要があります。

3.1 ネットワークに関する考慮事項

この項では、ネットワークに関する次の考慮事項について説明します。

- ホスト名の計画

- 仮想IPおよび仮想ホスト名に関する考慮事項

- ロード・バランサに関する考慮事項

- 仮想サーバーに関する考慮事項

- ワイド・エリアDNSの操作

3.1.1 ホスト名の計画

障害時リカバリ・トポロジでは、本番サイトのホスト名がスタンバイ・サイトの対応するピア・システムのIPアドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。プライマリ・サイトからスタンバイ・サイトへのフェイルオーバー後に、スタンバイ・サイトの中間層ホストのホスト名別名がアクティブになります。スタンバイ・サイトの別名を設定する場合は、スタンバイ・サイトのホストのホスト名を再構成する必要はありません。

物理ホスト名の別名は、ホスト名の解決に単一のグローバルDNSサーバーを使用する場合にのみ作成する必要があります。

この項では、本番サイトとスタンバイ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、物理ホスト名およびホスト名別名を計画する方法を説明します。ホスト名の例として、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。この項に記載されているホスト名の例は、障害時リカバリの対称サイトを設定することを前提としています(つまり、本番サイトとスタンバイ・サイトのホスト数は同じです)。本番サイトとスタンバイ・サイトの各ホストに他方のサイトのピア・ホストがあります。ピア・ホストは、他方のサイトの対応するホストと同じポートを使用するなど、同様に構成されます。

各コンポーネントを構成する際には、コンポーネントでIPベースの構成を使用する必要がある場合を除き、IPベースの構成ではなく、ホスト名ベースの構成を使用してください。たとえば、Oracle Fusion Middlewareコンポーネントのリスニング・アドレスを123.1.2.113のような特定のIPアドレスに構成する場合は、123.1.2.113に解決されるホスト名SOAHOST1.MYCOMPANY.COMを使用します。

この後のサブセクションでは、次のエンタープライズ・デプロイメントの障害時リカバリの本番サイトとスタンバイ・サイトでホスト名を設定する方法を説明します。

- Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

- Oracle WebCenter Portalの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

- Oracle Identity Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

- Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

- Oracle WebCenter Contentの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

- Oracle Business Intelligenceの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

注意:

このマニュアルの例では、最初の本番サイトのホストのIPアドレスは123.1.x.xという形式で、最初のスタンバイ・サイトのホストのIPアドレスは123.2.x.xという形式です。

Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

表3-1に、Oracle SOA Suite EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図3-1を参照してください。

表3-1 SOA Suiteの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.113

SOAHOST1

なし

123.1.2.114

SOAHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-2に、Oracle SOA Suite EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。図3-2に示されているOracle SOA Suiteのスタンバイ・サイト・ホストについては、表3-2に示されているホスト名別名を定義する必要があります。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、表3-2で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-2 SOA Suiteのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST2

123.2.2.113

STBYSOA1

SOAHOST1

123.2.2.114

STBYSOA2

SOAHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

図3-2 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名

「図3-2 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名」の説明

Oracle WebCenter Portalの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

表3-3に、Oracle WebCenter Portal EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle WebCenter Portal EDGデプロイメントの構成については、図4-4を参照してください。

表3-3 Oracle WebCenter Portalの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.113

SOAHOST1

なし

123.1.2.114

SOAHOST2

なし

123.1.2.115

WCPHOST1

なし

123.1.2.116

WCPHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-4に、Oracle WebCenter Portal EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle WebCenter Portal EDGデプロイメントの構成については、図4-4を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、表3-4で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-4 Oracle WebCenter Portalのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST2

123.2.2.113

STBYSOA1

SOAHOST1

123.2.2.114

STBYSOA2

SOAHOST2

123.2.2.115

STBYWCP1

WCPHOST1

123.2.2.116

STBYWCP2

WCPHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

Oracle Identity Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

表3-5に、Oracle Identity Management EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。

表3-5 Identity Managementの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.118

IDMHOST1

なし

123.1.2.119

IDMHOST2

なし

123.1.2.122

OIDHOST1

なし

123.1.2.123

OIDHOST2

なし

123.1.2.124

OVDHOST1

なし

123.1.2.125

OVDHOST2

なし

123.1.2.126

OIFHOST1

なし

123.1.2.127

OIFHOST2

なし

123.1.2.128

OAMHOST1

なし

123.1.2.129

OAMHOST2

なし

123.1.2.130

OAAMHOST1

なし

123.1.2.131

OAAMHOST2

なし

123.1.2.132

OIMHOST1

なし

123.1.2.133

OIMHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-6に、Oracle Identity Management EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、表3-6で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-6 Identity Managementのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST2

123.2.2.117

STBYADM

OAMADMINHOST

123.2.2.118

STBYIDM1

IDMHOST1

123.2.2.119

STBYIDM2

IDMHOST2

123.2.2.122

STBYOID1

OIDHOST1

123.2.2.123

STBYOID2

OIDHOST2

123.2.2.124

STBYOVD1

OVDHOST1

123.2.2.125

STBYOVD2

OVDHOST2

123.2.2.126

STBYOIF1

OIFHOST1

123.2.2.127

STBYOIF2

OIFHOST2

123.2.2.128

STBYOAM1

OAAMHOST1

123.2.2.129

STBYOAM2

OAAMHOST2

123.2.2.130

STBYOAAM1

OAAMHOST1

123.2.2.131

STBYOAAM2

OAAMHOST2

123.2.2.132

STBYOIM1

OIMHOST1

123.2.2.133

STBYOIM2

OIMHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

管理サーバー、Oracle Identity Manager管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-7)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。

表3-7 浮動IPアドレス

物理ホスト名

仮想ホスト名

浮動IP

AdminServer

ADMINVHN

122.1.2.134

OIMHOST1

OIMVHN1

122.1.2.135

OIMHOST2

OIMVHN2

122.1.2.136

SOAHOST1

SOAVHN1

122.1.2.137

SOAHOST2

SOAVHN2

122.1.2.138

注意:

詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

表3-8に、Oracle Portal、Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle Portalエンタープライズ・デプロイメントの構成については、図4-9を参照してください。本番サイトにおけるOracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの構成については、図4-10を参照してください。

表3-8 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.126

APPHOST1

なし

123.1.2.127

APPHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-9に、Oracle Portal、Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。本番サイトにおけるOracle Portalエンタープライズ・デプロイメントの構成については、図4-9を参照してください。本番サイトにおけるOracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの構成については、図4-10を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、表3-9で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-9 Oracle Portal、Forms、ReportsおよびDiscovererのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST1

123.2.2.126

STBYAPP1

APPHOST1

123.2.2.127

STBYAPP2

APPHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-2、表3-4、表3-6および表3-8に示されているホスト名別名は、スタンバイ・サイトではローカルに正しいIPアドレスへと解決されます。Oracle Fusion Middleware障害時リカバリ・トポロジでホスト名解決を構成する2通りの方法については、第3.1.1.1項「ホスト名解決」を参照してください。

Oracle WebCenter Contentの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

表3-10に、Oracle WebCenter Content EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle WebCenter Content EDGデプロイメントの構成については、図4-11を参照してください。

表3-10 Oracle WebCenter Contentの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.113

WCCHOST1

なし

123.1.2.114

WCCHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-11に、Oracle WebCenter Content EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle WebCenter Content EDGデプロイメントの構成については、図4-11を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、表3-11で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-11 Oracle WebCenter Contentのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST2

123.2.2.113

STBYWCC1

WCCHOST1

123.2.2.114

STBYWCC2

WCCHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

Oracle Business Intelligenceの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

表3-12に、Oracle Business Intelligence EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle Business Intelligence EDGデプロイメントの構成については、図4-11を参照してください。

表3-12 Oracle Business Intelligenceの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.113

BIHOST1

なし

123.1.2.114

BIHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-13に、Oracle Business Intelligence EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Business Intelligence EDGデプロイメントの構成については、図4-11を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、表3-11で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-13 Oracle Business Intelligenceのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス

物理ホスト名脚注1

ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST2

123.2.2.113

STBYBI1

BIHOST1

123.2.2.114

STBYBI2

BIHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

3.1.1.1 ホスト名の解決

ホスト名の解決は、通信のためにホスト名を適切なIPアドレスに解決するプロセスです。ホスト名の解決は、次のいずれかの方法で構成できます。

- ローカルでのホスト名の解決
ローカルでのホスト名の解決では、各ホストの/etc/hostsファイルで指定したホスト名とIPアドレスのマッピングが使用されます。

/etc/hostsファイルを使用してローカルでホスト名の解決を実装する方法の詳細は、第3.1.1.2項「ローカルでのホスト名の解決」を参照してください。

- DNSを使用したホスト名の解決
DNSサーバーは、IPネットワークでDNSによる名前解決を提供する専用サーバーまたはサービスです。

DNSサーバーによるホスト名の解決を実装する2通りの方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

Oracle Fusion Middleware障害時リカバリ・トポロジのデプロイメントを計画する際には、トポロジで使用するホスト名の解決方法を決定する必要があります。ほとんどのサイト管理者は、ホスト名を管理する際にこれらの解決方法を優先順位に従って組み合せて使用しています。

各サイトのOracle Fusion Middlewareホストと共有ストレージ・システムは、相互に通信できる必要があります。

ホスト名解決の優先順位

特定のホストで使用するホスト名の解決方法を決定するには、ホストの/etc/nsswitch.confファイルでhostsパラメータの値を検索します。

ホストでローカルにホスト名を解決する場合は、例3-1に示されているように、filesエントリをhostsパラメータの最初のエントリにします。filesがhostsパラメータの最初のエントリである場合、ホストの/etc/hostsファイル内のエントリがホスト名の解決で最初に使用されます。

例3-1 ローカルでのホスト名解決を使用する場合の指定

hosts:   files   dns   nis

ホストでDNSを使用してホスト名を解決する場合は、例3-2に示されているように、dnsエントリをhostsパラメータの最初のエントリにします。dnsがhostsパラメータの最初のエントリである場合、DNSサーバーのエントリがホスト名の解決に最初に使用されます。

例3-2 DNSによるホスト名解決を使用する場合の指定

hosts:   dns    files   nis

わかりやすくすると同時に整合性を保つために、サイト(本番サイトまたはスタンバイ・サイト)内のすべてのホストで同じホスト名の解決方法(ローカルでのホスト名の解決か、個別のDNSサーバーまたはグローバルDNSサーバーを使用したホスト名の解決)を使用することをお薦めします。

次の項に記載されている推奨事項は全般的な推奨事項です。企業で使用しているホスト名解決の標準に合わせて調整できます。

3.1.1.2 ローカルでのホスト名の解決

ローカルでのホスト名の解決では、ホストの/etc/hostsファイルで定義したホスト名とIPのマッピングが使用されます。障害時リカバリ・トポロジでこの方法を使用してホスト名を解決する場合、次のガイドラインが適用されます。

1. 本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

hosts:   files   dns   nis

2. 本番サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされている必要があります。保守を簡潔かつ容易にするために、本番サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-3に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。

例3-3 本番サイト・ホストの/etc/hostsファイル・エントリの作成

127.0.0.1      localhost.localdomain    localhost
123.1.2.111    WEBHOST1.MYCOMPANY.COM    WEBHOST1
123.1.2.112    WEBHOST2.MYCOMPANY.COM    WEBHOST2
123.1.2.113    SOAHOST1.MYCOMPANY.COM    SOAHOST1
123.1.2.114    SOAHOST2.MYCOMPANY.COM    SOAHOST2

3. スタンバイ・サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアの物理ホスト名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-4に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。

例3-4 スタンバイ・サイト・ホストの/etc/hostsファイル・エントリの作成

127.0.0.1      localhost.localdomain    localhost
123.2.2.111    STBYWEB1.MYCOMPANY.COM    WEBHOST1
123.2.2.112    STBYWEB2.MYCOMPANY.COM    WEBHOST2
123.2.2.113    STBYSOA1.MYCOMPANY.COM    SOAHOST1
123.2.2.114    STBYSOA2.MYCOMPANY.COM    SOAHOST2

4. /etc/hostファイル・エントリを使用してホスト名解決を設定したら、pingコマンドを使用してホスト名解決をテストします。例3-3に示されている静的IPアドレス指定と/etc/hostsファイル・エントリを使用して構成したシステムの場合、本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。

5. 同様に、例3-4に示されている静的IPアドレス指定と/etc/hostsファイル・エントリを使用して構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.2.2.111)が返され、WEBHOST1という名前がそのIPアドレスと関連付けられていることがわかります。

3.1.1.3 個別のDNSサーバーを使用したホスト名の解決

このマニュアルでは、本番サイトとスタンバイ・サイトに独自のDNSサーバーがある障害時リカバリ・トポロジを表す場合に「個別のDNSサーバー」という用語を使用します。障害時リカバリ・トポロジで個別のDNSサーバーを使用してホスト名を解決する場合、次のガイドラインが適用されます。

1. 本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

hosts:   dns   files   nis

2. 本番サイトとスタンバイ・サイトのDNSサーバーが相互を認識してはいけません。独自のサイト内で使用されるホスト名のエントリはそれぞれのDNSサーバーで構成されている必要があります。

3. 本番サイトのDNSサーバーのエントリで、物理ホスト名がIPアドレスにマップされている必要があります。例3-5に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトで使用するDNSサーバーのエントリを示します。

例3-5 個別のDNSサーバー構成における本番サイト・ホストのDNSエントリ

WEBHOST1.MYCOMPANY.COM    IN    A    123.1.2.111
WEBHOST2.MYCOMPANY.COM    IN    A    123.1.2.112
SOAHOST1.MYCOMPANY.COM    IN    A    123.1.2.113
SOAHOST2.MYCOMPANY.COM    IN    A    123.1.2.114

4. スタンバイ・サイトのDNSサーバーのエントリで、本番サイトの物理ホスト名がIPアドレスにマップされている必要があります。例3-6に、SOAエンタープライズ・デプロイメント・トポロジのスタンバイ・サイトで使用するDNSサーバーのエントリを示します。

例3-6 個別のDNSサーバー構成におけるスタンバイ・サイト・ホストのDNSエントリ

WEBHOST1.MYCOMPANY.COM    IN    A    123.2.2.111
WEBHOST2.MYCOMPANY.COM    IN    A    123.2.2.112
SOAHOST1.MYCOMPANY.COM    IN    A    123.2.2.113
SOAHOST2.MYCOMPANY.COM    IN    A    123.2.2.114

5. 本番サイトおよびスタンバイ・サイトのいずれのホストについても、/etc/hostsファイルにエントリがないことを確認します。

6. pingコマンドを使用してホスト名解決のテストを行います。例3-5に示されている本番サイトのDNSエントリで構成したシステムの場合、本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。

7. 同様に、例3-6に示されているスタンバイ・サイトのDNSエントリで構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.2.2.111)が返され、ホスト名が完全修飾されていることがわかります。

3.1.1.4 グローバルDNSサーバーを使用したホスト名の解決

このマニュアルでは、本番サイトとスタンバイ・サイト両方に対して1つのDNSサーバーを使用する障害時リカバリ・トポロジを表す場合に「グローバルDNSサーバー」という用語を使用します。障害時リカバリ・トポロジでグローバルDNSサーバーを使用してホスト名を解決する場合、次のガイドラインが適用されます。

1. グローバルDNSサーバーを使用する場合、簡潔にするために、ローカルでのホスト名解決とDNSによるホスト名解決を組み合せることをお薦めします。

2. この例では、本番サイトでDNSによるホスト名解決を使用し、スタンバイ・サイトではローカルでのホスト名解決を使用することを前提とします。

3. グローバルDNSサーバーに、本番サイトとスタンバイ・サイト両方のホストのエントリがある必要があります。例3-7に、SOAエンタープライズ・デプロイメント・トポロジのエントリを示します。

例3-7 グローバルDNSサーバー構成を使用する場合の本番サイト・ホストおよびスタンバイ・サイト・ホストのDNSエントリ

WEBHOST1.MYCOMPANY.COM    IN    A    123.1.2.111
WEBHOST2.MYCOMPANY.COM    IN    A    123.1.2.112
SOAHOST1.MYCOMPANY.COM    IN    A    123.1.2.113
SOAHOST2.MYCOMPANY.COM    IN    A    123.1.2.114
STBYWEB1.MYCOMPANY.COM    IN    A    123.2.2.111
STBYWEB2.MYCOMPANY.COM    IN    A    123.2.2.112
STBYSOA1.MYCOMPANY.COM    IN    A    123.2.2.113
STBYSOA2.MYCOMPANY.COM    IN    A    123.2.2.114

4. 本番サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

hosts:   dns   files   nis

5. スタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

hosts:   files   dns   nis

6. スタンバイ・サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアの物理ホスト名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-8に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。

例3-8 グローバルDNSサーバー構成を使用する場合のスタンバイ・サイトの/etc/hostsファイル・エントリ

127.0.0.1      localhost.localdomain    localhost
123.2.2.111    STBYWEB1.MYCOMPANY.COM    WEBHOST1
123.2.2.112    STBYWEB2.MYCOMPANY.COM    WEBHOST2
123.2.2.113    STBYSOA1.MYCOMPANY.COM    SOAHOST1
123.2.2.114    STBYSOA2.MYCOMPANY.COM    SOAHOST2

7. pingコマンドを使用してホスト名解決のテストを行います。本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。

8. 同様に、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.2.2.111)が返され、ホスト名が完全修飾されていることがわかります。

3.1.1.5 ホスト名解決のテスト

ホスト名が適切に割り当てられていることを検証します。そのためには、本番サイトの各ホストに接続し、pingコマンドを使用して、ホストが本番サイトの他のホストを特定できることを確認します。

続いて、スタンバイ・サイトの各ホストに接続し、pingコマンドを使用して、ホストがスタンバイ・サイトの他のホストを特定できることを確認します。

3.1.2 仮想IPおよび仮想ホスト名に関する考慮事項

Oracle WebLogic管理サーバーをホストしているマシンに障害が発生した際に、リクエストの処理が続行されるようOracle WebLogic管理サーバーを有効にするには、仮想IPアドレスおよび仮想ホスト名が必要です。仮想IPアドレスを使用すると、ドメインの管理サーバーによってサーバー移行が行われます。仮想サーバーは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。

障害時リカバリ・トポロジでは、本番サイトの仮想IPホスト名がスタンバイ・サイトの対応するピア・システムのIPアドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。プライマリ・サイトからスタンバイ・サイトへのフェイルオーバー後に、スタンバイ・サイトの中間層ホストのホスト名別名がアクティブになります。スタンバイ・サイトの別名を設定する場合は、スタンバイ・サイトのホストのホスト名を再構成する必要はありません。

この項では、本番サイトとスタンバイ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、仮想IPホスト名およびホスト名別名を計画する方法を説明します。これは、単一の企業DNSを使用している場合に必要です。

ホスト名の例として、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。この項に記載されているホスト名の例は、障害時リカバリの対称サイトを設定することを前提としています(つまり、本番サイトとスタンバイ・サイトのホスト数は同じです)。本番サイトとスタンバイ・サイトの各ホストに他方のサイトのピア・ホストがあります。ピア・ホストは、他方のサイトの対応するホストと同じポートを使用するなど、同様に構成されます。

この後のサブセクションでは、次のエンタープライズ・デプロイメントの障害時リカバリの本番サイトとスタンバイ・サイトで仮想IPアドレスおよびホスト名を設定する方法を説明します。

- Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

- Oracle WebCenter Portalの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

- Oracle Identity Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

- Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

- Oracle WebCenter Contentの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

- Oracle Business Intelligenceの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

表3-14に、Oracle SOA Suite EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図3-1を参照してください。

表3-14 SOA Suiteの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.1.2.115

ADMINVHN

なし

123.1.2.116

SOAVHN1

なし

123.1.2.117

SOAVHN2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-15に、Oracle SOA Suite EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。図3-2に示されているOracle SOA Suiteのスタンバイ・サイト・ホストについては、表3-15に示されているホスト名別名を定義する必要があります。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、表3-2で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-15 SOA Suiteのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.2.2.115

STBYADMINVHN

ADMINVHN

123.2.2.116

STBYSOAVHN1

SOAVHN1

123.2.2.117

STBYSOAVHN2

SOAVHN2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

Oracle WebCenter Portalの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

表3-16に、Oracle WebCenter Portal EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle WebCenter Portal EDGデプロイメントの構成については、図4-4を参照してください。

表3-16 Oracle WebCenter Portalの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.1.2.111

ADMINVHN

なし

123.1.2.113

SOAVHN1

なし

123.1.2.114

SOAVHN2

なし

123.1.2.115

WCPVHN1

なし

123.1.2.116

WCPVHN2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-17に、Oracle WebCenter Portal EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle WebCenter Portal EDGデプロイメントの構成については、図4-4を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、表3-4で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-17 WebCenterのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.2.2.111

STBYADMINVHN

ADMINVHN

123.2.2.113

STBYSOAVHN1

SOAVHN1

123.2.2.114

STBYSOAVHN2

SOAVHN2

123.2.2.115

STBYWCPVHN1

WCVHN1

123.2.2.116

STBYWCPVHN2

WCVHN2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

Oracle Identity Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

表3-18に、Oracle Identity Management EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。

表3-18 Identity Managementの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.1.2.111

ADMINVHN

なし

123.1.2.118

IDMHVHN1

なし

123.1.2.119

IDMVHN2

なし

123.1.2.122

OIDVHN1

なし

123.1.2.123

OIDVHN2

なし

123.1.2.124

OVDVHN1

なし

123.1.2.125

OVDVHN2

なし

123.1.2.126

OIFVHN1

なし

123.1.2.127

OIFVHN2

なし

123.1.2.128

OAMVHN1

なし

123.1.2.129

OAMVHN2

なし

123.1.2.130

OAAMVHN1

なし

123.1.2.131

OAAMVHN2

なし

123.1.2.132

OIMVHN1

なし

123.1.2.133

OIMVHN2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-19に、Oracle Identity Management EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、表3-6で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-19 Identity Managementのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.2.2.111

STBYADMINVHN

ADMINVHN

123.2.2.118

STBYIDMVHN1

IDMVHN1

123.2.2.119

STBYIDMVHN2

IDMVHN2

123.2.2.122

STBYOIDVHN1

OIDVHN1

123.2.2.123

STBYOIDVHN2

OIDVHN2

123.2.2.124

STBYOVDVHN1

OVDVHN1

123.2.2.125

STBYOVDVHN2

OVDVHN2

123.2.2.126

STBYOIFVHN1

OIFVHN1

123.2.2.127

STBYOIFVHN2

OIFVHN2

123.2.2.128

STBYOAMVHN1

OAAMVHN1

123.2.2.129

STBYOAMVHN2

OAAMVHN2

123.2.2.130

STBYOAAMVHN1

OAAMVHN1

123.2.2.131

STBYOAAMVHN2

OAAMVHN2

123.2.2.132

STBYOIMVHN1

OIMVHN1

123.2.2.133

STBYOIMVHN2

OIMVHN2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

管理サーバー、Oracle Identity Manager管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-7)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。

表3-20 浮動IPアドレス

物理ホスト名

仮想ホスト名

浮動IP

AdminServer

ADMINVHN

123.1.2.134

OIMHOST1

OIMVHN1

123.1.2.135

OIMHOST2

OIMVHN2

123.1.2.136

SOAHOST1

SOAVHN1

123.1.2.137

SOAHOST2

SOAVHN2

123.1.2.138

注意:

詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

表3-21に、Oracle Portal、Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle Portalエンタープライズ・デプロイメントの構成については、図4-9を参照してください。本番サイトにおけるOracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの構成については、図4-10を参照してください。

表3-21 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.1.2.111

ADMINVHN

なし

123.1.2.126

APPVHN1

なし

123.1.2.127

APPVHN2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-22に、Oracle Portal、Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。本番サイトにおけるOracle Portalエンタープライズ・デプロイメントの構成については、図4-9を参照してください。本番サイトにおけるOracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの構成については、図4-10を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、表3-9で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-22 Oracle Portal、Forms、ReportsおよびDiscovererのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.2.2.111

STBYADMINVHN

ADMINVHN

123.2.2.126

STBYAPPVHN1

APPVHN1

123.2.2.127

STBYAPPVHN2

APPVHN2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-2、表3-4、表3-6および表3-8に示されているホスト名別名は、スタンバイ・サイトではローカルに正しいIPアドレスへと解決されます。Oracle Fusion Middleware障害時リカバリ・トポロジでホスト名解決を構成する2通りの方法については、第3.1.1.1項「ホスト名解決」を参照してください。

Oracle WebCenter Contentの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

表3-23に、Oracle WebCenter Content EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle WebCenter Content EDGデプロイメントの構成については、図4-11を参照してください。

表3-23 Oracle Enterprise Content Managementの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.1.2.111

ADMINVHN

なし

123.1.2.112

WCCVHN1

なし

123.1.2.114

WCCVHN2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-24に、Oracle WebCenter Content EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle WebCenter Content EDGデプロイメントの構成については、図4-11を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、表3-11で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-24 Oracle WebCenter Contentのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.2.2.111

STBYADMINVHN

ADMINVHN

123.2.2.112

STBYWCCVHN1

WCCVHN1

123.2.2.113

STBYWCCVHN2

WCCVHN2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

Oracle Business Intelligenceの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

表3-25に、Oracle Business Intelligence EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle Business Intelligence EDGデプロイメントの構成については、図4-14を参照してください。

表3-25 Oracle Business Intelligenceの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.1.2.115

ADMINVHN

なし

123.1.2.116

BIVHN1

なし

123.1.2.117

BIVHN2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-26に、Oracle Business Intelligence EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Business Intelligence EDGデプロイメントの構成については、図4-11を参照してください。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、表3-11で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表3-26 Oracle Business Intelligenceのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

123.2.2.115

STBYADMINVHN

ADMINVHN

123.2.2.116

STBYBIVHN1

BIVHN1

123.2.2.117

STBYBIVHN2

BIVHN2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

3.1.3 ロード・バランサに関する考慮事項

Oracle Fusion Middlewareコンポーネントを高可用性トポロジでデプロイする場合には、ハードウェア・ロード・バランサが必要です。次の機能を備えたハードウェア・ロード・バランサをお薦めします。

- 仮想ホスト名を使用して実際のサーバーのプールにトラフィックの負荷を分散する機能: クライアントは、実際のホスト名を使用するかわりに、仮想ホスト名を使用してサービスにアクセスします。これによって、ロード・バランサはプール内のサーバーにリクエストの負荷を分散できます。

- ポート変換の構成。

- ポート(HTTPおよびHTTPS)の監視。

- 仮想サーバーとポートの構成: 外部ロード・バランサで仮想サーバー名およびポートを構成する機能。仮想サーバー名とポートは次の要件を満たす必要があります。

- ロード・バランサでは、複数の仮想サーバーの構成が可能である必要があります。各仮想サーバーについては、複数のポート上のトラフィック管理を構成できることが必要です。たとえば、Oracle Internet Directoryクラスタの場合、ロード・バランサでは、LDAPおよびLDAPSトラフィックの仮想サーバーとポートを構成する必要があります。

- 仮想サーバー名がIPアドレスと関連付けられており、DNSの一部である必要があります。クライアントは、仮想サーバー名を使用してロード・バランサにアクセスできる必要があります。

- ノードの障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。

- リソースの監視、ポートの監視およびプロセスの障害の検出: ロード・バランサは、通知などの方法を使用してサービスやノードの障害を検出し、障害が発生したノードへのOracle Net以外のトラフィックの送信を停止できる必要があります。ロード・バランサで障害を自動的に検出できる場合は、その機能を使用してください。

- フォルト・トレラント・モード: ロード・バランサをフォルト・トレラント・モードで構成することを強くお薦めします。

- その他: トラフィックの転送先となるバックエンド・サービスが使用できない場合、コール元のクライアントに即座に戻るようにロード・バランサの仮想サーバーを構成することを強くお薦めします。この構成は、クライアント・システムにおけるTCP/IPの設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。

- スティッキーなルーティング機能: CookieやURLに基づいてコンポーネントへのスティッキーな接続を維持する機能。

- SSLアクセラレーション: この機能は推奨されますが、必須ではありません。

- Oracle Access Managerを使用したIdentity Managementの構成については、TCP接続タイムアウトの数値を大きくして、ディレクトリ層でロード・バランサに仮想サーバーを構成します。この値は、Oracle Access Managerとディレクトリ層の間でトラフィックがない場合に、その予想される最大時間より大きい必要があります。

- クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。

3.1.4 仮想サーバーに関する考慮事項

様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらは、実際のホストおよびポートに対して適切に構成し、サービスが継続されるようにする必要があります。また、可用性を確保するために、実際のホストおよびポートを監視して、サービスが停止した場合はできるだけ早く、それらのホストやポートへのトラフィックが停止されるようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

外部トラフィックと内部トラフィックを処理する場合は、ロード・バランサを2つ使用することをお薦めします。このようなトポロジでは、一方のロード・バランサを外部HTTPトラフィック用に設定し、もう一方のロード・バランサを内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なDMZ間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。

ロード・バランサに定義された一部の仮想サーバーは、コンポーネント間の通信に使用されます。これらの仮想サーバーは内部トラフィック用に使用され、企業の内部DNSに定義されます。ホスト名の解決に単一のグローバルDNSサーバーを使用する場合は、これらの仮想サーバーに別名を作成することをお薦めします。

個別のDNSサーバーを使用してホスト名を解決する場合は、別名を作成する必要はありません。

各種Oracle Fusion Middleware製品に必要な仮想サーバーを次の表に示します。

表3-27 Oracle SOA Suiteの本番サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

別名

Oracle SOA

外部

soa.mycompany.com

なし

Oracle SOA

内部

soainternal.mycompany.com

なし

管理コンソール

内部

admin.mycompany.com

なし

表3-28 Oracle SOA Suiteのスタンバイ・サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

仮想サーバー名別名

Oracle SOA

外部

soa.mycompany.com

なし

Oracle SOA

内部

stbysoainternal.mycompany.com

soainternal.mycompany.com

管理コンソール

内部

admin.mycompany.com

なし

表3-29 Oracle WebCenter Portalの本番サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

別名

Oracle WebCenter Portal

外部

wcp.mycompany.com

なし

Oracle WebCenter Portal

内部

wcpinternal.mycompany.com

なし

Oracle SOA Internal

内部

soainternal.mycompany.com脚注 1

なし

管理コンソール

内部

admin.mycompany.com

なし

脚注1 SOAドメインを使用して拡張する場合に必要です。

表3-30 Oracle WebCenter Portal Suiteのスタンバイ・サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

仮想サーバー名別名

Oracle WebCenter Portal

外部

wcp.mycompany.com

なし

Oracle WebCenter Portal

内部

stbywcpinternal.mycompany.com

wcinternal.mycompany.com

Oracle SOA Internal

内部

soainternal.mycompany.com脚注 1

soainternal.mycompany.com

管理コンソール

内部

admin.mycompany.com

なし

脚注1 SOAドメインを使用して拡張する場合に必要です。

表3-31 Oracle Identity Managementの本番サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

別名

Oracle Internet Directory

外部

oid.mycompany.com

なし

Oracle Internet Directory

内部

oidinternal.mycompany.com

なし

Oracle Virtual Directory

外部

ovd.mycompany.com

なし

Oracle Virtual Directory

内部

ovdinternal.mycompany.com

なし

Oracle Identity Federation

外部

oif.mycompany.com

なし

Oracle Identity Federation

内部

oifinternal.mycompany.com

なし

Oracle Identity Manager

外部

oim.mycompany.com

なし

Oracle Identity Manager

内部

oiminternal.mycompany.com

なし

シングル・サインオン

外部

sso.mycompany.com

なし

シングル・サインオン

内部

ssointernal.mycompany.com

なし

管理コンソール

内部

admin.mycompany.com

なし

表3-32 Oracle Identity Managementのスタンバイ・サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

別名

Oracle Internet Directory

外部

oid.mycompany.com

なし

Oracle Internet Directory

内部

stbyoidinternal.mycompany.com

oidinternal.mycompany.com

Oracle Virtual Directory

外部

ovd.mycompany.com

なし

Oracle Virtual Directory

内部

stbyovdinternal.mycompany.com

ovdinternal.mycompany.com

Oracle Identity Federation

外部

oif.mycompany.com

なし

Oracle Identity Federation

内部

stbyoifinternal.mycompany.com

oifinternal.mycompany.com

Oracle Identity Manager

外部

oim.mycompany.com

なし

Oracle Identity Manager

内部

stbyoiminternal.mycompany.com

oiminternal.mycompany.com

シングル・サインオン

外部

sso.mycompany.com

なし

シングル・サインオン

内部

stbyssointernal.mycompany.com

ssointernal.mycompany.com

管理コンソール

内部

admin.mycompany.com

なし

表3-33 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

別名

Oracle Portal

外部

portal.mycompany.com

なし

Oracle Portal

内部

portalinternal.mycompany.com

なし

Oracle FormsおよびOracle Reports

外部

forms.mycompany.com

なし

Oracle FormsおよびOracle Reports

内部

formsinternal.mycompany.com

なし

Discoverer

外部

disco.mycompany.com

なし

Discoverer

内部

discointernal.mycompany.com

なし

管理コンソール

内部

admin.mycompany.com

なし

表3-34 Oracle Portal、Reports、FormsおよびDiscovererのスタンバイ・サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

仮想サーバー名別名

Oracle Portal

外部

portal.mycompany.com

なし

Oracle Portal

内部

stbyportalinternal.mycompany.com

portalinternal.mycompany.com

Oracle FormsおよびOracle Reports

外部

forms.mycompany.com

なし

Oracle FormsおよびOracle Reports

内部

stbyformsinternal.mycompany.com

formsinternal.mycompany.com

Discoverer

外部

disco.mycompany.com

なし

Discoverer

内部

stbydiscointernal.mycompany.com

discointernal.mycompany.com

管理コンソール

内部

admin.mycompany.com

なし

表3-35 Oracle WebCenter Contentの本番サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

別名

Oracle WebCenter Content

外部

wcc.mycompany.com

なし

Oracle WebCenter Content

内部

wccinternal.mycompany.com

なし

Oracle SOA Internal

内部

soainternal.mycompany.com脚注1

なし

管理コンソール

内部

admin.mycompany.com

なし

脚注1 SOAドメインを使用して拡張する場合に必要です。

表3-36 Oracle WebCenter Contentのスタンバイ・サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

仮想サーバー名別名

Oracle Enterprise Content Management

外部

ecm.mycompany.com

なし

Oracle Enterprise Content Management

内部

stbyecminternal.mycompany.com

ecminternal.mycompany.com

Oracle SOA Internal

内部

stbysoainternal.mycompany.com脚注 1

soainternal.mycompany.com

管理コンソール

内部

admin.mycompany.com

なし

脚注 1 Oracle SOAドメインを使用して拡張する場合に必要です。

表3-37 Oracle Business Intelligenceの本番サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

別名

Oracle Business Intelligence

外部

bi.mycompany.com

なし

Oracle Business Intelligence

内部

biinternal.mycompany.com

なし

Oracle Access Manager Internal

内部

oaminternal.mycompany.com脚注 1

なし

管理コンソール

内部

admin.mycompany.com

なし

脚注 1 Oracle Access Managerドメインを使用して拡張する場合に必要です。

表3-38 Oracle Business Intelligenceのスタンバイ・サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

仮想サーバー名別名

Oracle Business Intelligence

外部

bi.mycompany.com

なし

Oracle Business Intelligence

内部

stbybiinternal.mycompany.com

biinternal.mycompany.com

Oracle Access Manager Internal

内部

stbyoaminternal.mycompany.com脚注 1

oaminternal.mycompany.com

管理コンソール

内部

admin.mycompany.com

なし

脚注 1 Oracle Access Managerドメインを使用して拡張する場合に必要です。

3.1.5 ワイド・エリアDNSの操作

サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは本番ロールを引き継ぐ新しいサイトに透過的にリダイレクトされる必要があります。本番サイトのエントリ・ポイントにクライアント・リクエストを送信するには、DNS解決を使用します。このリダイレクションを実現するには、本番サイトへのリクエストを解決するワイド・エリアDNSをスタンバイ・サイトにスイッチオーバーする必要があります。DNSスイッチオーバーを実行するには、グローバル・ロード・バランサを使用するか、DNS名を手動で変更します。

注意:

ハードウェア・ロード・バランサは、各サイトのフロントエンドにあることを前提とします。サポートされているロード・バランサについては、次のWebサイトを参照してください。

http://support.oracle.com

この項では、次の項目について説明します。

- グローバル・ロード・バランサの使用

- DNS名の手動変更

3.1.5.1 グローバル・ロード・バランサの使用

グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。

通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、スタンバイ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだスタンバイ・サイトにリクエストが送信されるようになります。

DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバーおよびフェイルオーバーとして機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。

3.1.5.2 DNS名の手動変更

DNSスイッチオーバーを使用するこの方法では、当初は本番サイトのロード・バランサのIPアドレスにマップされていた名前とIPのマッピングを手動で変更する必要があります。マッピングはスタンバイ・サイトのロード・バランサのIPアドレスにマップするように変更します。スイッチオーバーを実行する手順は次のとおりです。

1. 本番サイトのロード・バランサ・マッピングの現在の存続時間(TTL)値を書き留めます。このマッピングはDNSキャッシュ内にあり、TTLが経過するまでそこに保持されます。例として、TTLが3600秒であるとします。

2. TTL値を短い間隔(60秒など)に変更します。

3. 元のTTLの間隔が1回経過するまで待ちます。これは、ステップ1で書き留めた元のTTL値である3600秒です。

4. スタンバイ・サイトがリクエストを受信するようにスイッチオーバーされていることを確認します。

5. スタンバイ・サイトのロード・バランサを解決するようにDNSマッピングを変更します。通常の操作に適したTTL値(3600秒など)を指定してください。

DNSスイッチオーバーを使用するこの方法は、スイッチオーバー操作またはフェイルオーバー操作として機能します。ステップ2で設定するTTL値は、その時間内にクライアント・リクエストを十分に処理できないような値にする必要があります。TTLを変更する場合、実質的には、アドレス解決のキャッシュ・セマンティックを長い時間から短い時間に変更することになります。キャッシュ時間が短くなるため、DNSリクエストが増加する可能性があります。

3.2 ストレージに関する考慮事項

この項では、エンタープライズ・デプロイメントの障害時リカバリ・ソリューションで使用するストレージを設計する際の推奨事項について説明します。

3.2.1 Oracle Fusion Middlewareのアーティファクト

通常、特定の環境内のOracle Fusion Middlewareコンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。これは、ボリュームとコンシステンシー・グループを設計する際の重要な考慮事項です。アーティファクトの中には静的なものもあれば、動的なものもあります。

静的アーティファクト

静的アーティファクトは、頻繁には変更されないファイルやディレクトリです。次のようなものがあります。

- MW_HOME: Oracle Middlewareホームは通常、OracleホームとOracle WebLogic Serverホームで構成されます。

- Oracleインベントリ: /etcディレクトリにある、oraInst.locおよびoratabファイル。

- BEAホームの一覧: UNIXの場合、user_home/bea/beahomelistにあります。

動的またはランタイム・アーティファクト

動的またはランタイム・アーティファクトは、頻繁に変更されるファイルです。ランタイム・アーティファクトには次のようなものがあります。

- ドメイン・ホーム: 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。

- Oracleインスタンス: Oracleインスタンスのホーム・ディレクトリ。

- .earファイルや.warファイルなどのアプリケーション・アーティファクト。

- MDSリポジトリなどのデータベース・アーティファクト。

- Oracle Fusion Middlewareで使用されるデータベース・メタデータ・リポジトリ。

- JMSプロバイダやトランザクション・ログなどの永続ストア。

3.2.2 OracleホームとOracleインベントリ

Oracle Fusion Middlewareでは、1つのバイナリ・インストールから複数の管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。

ORACLE_HOMEまたはWL_HOMEを異なるノードの複数のサーバーで共有する場合は、パッチのインストールおよび適用における整合性を確保するために、それらのノードのOracleインベントリとMiddlewareホームの一覧を常に最新の状態にしておくことをお薦めします。

ノードでoraInventoryを更新して、これに共有ストレージのインストールを関連付けるには、ORACLE_HOME/oui/bin/attachHome.shを使用します。

Middlewareホームの一覧を更新してWL_HOMEを追加または削除するには、user_home/bea/beahomelistファイルを使用します。これは、このトポロジに示されているものに加えてインストールしたノードで必要になります。

3.2.3 ストレージ・レプリケーション

この項では、共有ストレージにボリュームを作成する際のガイドラインを説明します。ストレージ・デバイスで使用可能なストレージ・レプリケーション・テクノロジの機能によっては、層内の各ノードでマウント・ポイント、ディレクトリおよびシンボリック・リンクを作成しなければならないことがあります。

ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証される場合:

- その層で実行されるサーバーごとにボリュームを1つずつ作成します。たとえば、アプリケーション層では、WebLogicの管理サーバー用にボリュームを1つと管理対象サーバー用に別のボリュームを作成できます。

- 各層に対して、その層のボリュームをメンバーとするコンシステンシー・グループを1つ作成します。

- 2つのシステムによってボリュームが同時にマウントされる場合、ストレージ・サブシステムによっては、クラスタ・ファイル・システムが必要になることがあります。ただし、異なるシステム上のOracleプロセスが1つのファイルまたはディレクトリ・ツリーに同時にアクセスするという既知のケースはありません。NFSはクラスタ・ファイル・システムなので、NFSで接続されたストレージを使用している場合、クラスタ・ファイル・システム・ソフトウェアを追加する必要はありません。

ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合:

- 各層にボリュームを1つずつ作成します。たとえば、アプリケーション層用のボリューム、Web層用のボリュームというように作成できます。

- その層の各ノード用に別個のディレクトリを作成します。たとえば、アプリケーション層のボリュームにSOAHOST1用のディレクトリを作成し、Web層のボリュームにWEBHOST1用のディレクトリを作成します。

- ボリューム上のそのディレクトリに対するマウント・ポイント・ディレクトリを各ノードに作成します。

- マウント・ポイント・ディレクトリへのシンボリック・リンクを作成します。層内のノード間で同じディレクトリ構造を使用できるように、シンボリック・リンクを作成する必要があります。

- 2つのシステムによってボリュームが同時にマウントされる場合、ストレージ・サブシステムによっては、クラスタ・ファイル・システムが必要になることがあります。ただし、異なるシステム上のOracleプロセスが1つのファイルまたはディレクトリ・ツリーに同時にアクセスするという既知のケースはありません。NFSはクラスタ・ファイル・システムなので、NFSで接続されたストレージを使用している場合、クラスタ・ファイル・システム・ソフトウェアを追加する必要はありません。

注意:

障害時リカバリ・サイトの共有ストレージを設定する前に、『Oracle Fusion Middlewareリリース・ノート』の高可用性に関する章を参照して、高可用性環境で共有ストレージをベースとしたデプロイメントに関する既知の問題を確認してください。

Oracle Fusion Middlewareのリリース・ノートは次のURLにあります。

http://www.oracle.com/technology/documentation/middleware.html

3.2.4 ファイルベースの永続ストア

WebLogic Serverアプリケーション・サーバーは通常、高可用性を確保するためにクラスタ化されています。Oracle SOA Suiteトポロジのローカル・サイトの高可用性については、Java Message Service(JMS)およびトランザクション・ログ(TLog)にファイルベースの永続ストアを使用します。このファイルベースの永続ストアは、クラスタのすべてのメンバーがアクセス可能な共有ストレージに配置する必要があります。

SANストレージ・システムでは、Oracle Clustered File System(OCFS2)など、ホスト・ベースのクラスタまたは共有ファイル・システム・テクノロジを使用する必要があります。OCFS2は、対称型の共有ディスク・クラスタ・ファイル・システムです。これを使用すると、各ノードでメタデータとデータの両方をSANに対して直接読み書きできます。

NASストレージ・システムを使用している場合、クラスタ・ファイル・システムを追加する必要はありません。

3.3 データベースに関する考慮事項

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジで使用するOracle Databaseの設定に関する推奨事項と考慮事項を説明します。

1. 使用するトポロジの要件に応じて、本番サイトとスタンバイ・サイトの両方にReal Application Clusterデータベースを作成することをお薦めします。

2. メタデータ・リポジトリを実行するデータベースについては、障害時保護テクノロジとしてOracle Data Guardをお薦めします。Oracle Active Data GuardまたはOracle GoldenGateを使用することもできます。

注意:

Oracle GoldenGateは、アクティブ-パッシブ構成でのみ使用できます。

詳細は、次を参照してください。

- Oracle Active Data Guard:
http://www.oracle.com/in/products/database/options/active-data-guard/index.html

- Oracle GoldenGate:
http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html

3. 使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、これが正しく特定されていることを確認してください。
詳細は、Oracle Data Guardの概念と管理、および関連事項として次のURLにある最大可用性アーキテクチャに関する情報を参照してください。

http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

4. 同期REDO転送によってレスポンス時間やスループットに影響が生じる可能性があるため、十分な帯域幅を備えた、待機時間の少ないネットワークを構成します。

5. スタンバイ・サイトのデータベースのLOG_ARCHIVE_DEST_nパラメータにSYNCまたはASYNC属性を指定しておく必要があります。属性を指定しなかった場合は、デフォルトでASYNCに設定されます。

6. スタンバイ・サイトのデータベースは、管理リカバリ・モードである必要があります。これによって、スタンバイ・サイトのデータベースは常にメディア・リカバリの状態になります。管理リカバリ・モードを使用すると、フェイルオーバー時間を短縮できます。

7. 本番サイトとスタンバイ・サイトのtnsnames.oraファイルに、本番サイトとスタンバイ・サイト両方のデータベースをエントリしておく必要があります。

8. 中間層の同期が実行された場合は必ず、Data Guardでデータベースの手動同期を強制的に実行することを強くお薦めします。これは特に、メタデータ・リポジトリに構成データを格納するコンポーネントに該当します。

9. 本番サイトとスタンバイ・サイトの両方でデータベース・ホスト名の別名を設定することを強くお薦めします。これによって、シームレスなスイッチオーバー、スイッチバックおよびフェイルオーバーが実現します。

3.3.1 データベースのTNSNAMES.ORAエントリの作成

Oracle Data Guardでは本番データベースとスタンバイ・データベースが同期されるため、本番データベースとスタンバイ・データベースが相互を参照できる必要があります。

Oracle Data Guardでは、tnsnames.oraファイル・エントリを使用して、本番データベースとスタンバイ・データベースにリクエストを送信します。そのため、本番データベースとスタンバイ・データベースのエントリをtnsnames.oraファイルに作成する必要があります。Oracle Data Guardでtnsnames.oraファイルを使用する方法の詳細は、Oracle Databaseのドキュメント・セットにあるOracle Data Guardの概念と管理を参照してください。

3.3.2 Oracle Data Guardを使用した手動によるデータベースの強制同期

中間層の構成データをOracle Database・リポジトリに格納するOracle Fusion Middlewareコンポーネントについては、中間層の同期が実行された場合は必ず、Oracle Data Guardを使用して、データベースを手動で強制的に同期してください。alter system archive log allというSQL文を使用して、ログを切り替えます。これにより、本番サイトとスタンバイ・サイトのデータベースの同期が強制的に行われます。

例3-9に、本番サイトのデータベースとスタンバイ・サイトのデータベースを強制的に同期する場合に使用するSQL文を示します。

例3-9 手動によるOracle Data Guardデータベースの強制同期

ALTER SYSTEM ARCHIVE LOG ALL;

3.3.3 データベース・ホスト名の別名の設定

必要に応じて、本番サイトとスタンバイ・サイトのデータベースにデータベース・ホスト名の別名を設定できます。この別名は、DNSまたはデータベース・インスタンスを実行する各ノードの/etc/hostsファイルで定義する必要があります。

障害時リカバリ環境では、アクティブに接続を受け取るサイトが本番サイトになります。フェイルオーバー操作またはスイッチオーバー操作が正常に完了すると、スタンバイ・サイトが新しい本番サイトになります。

この項の例では、custdbhost1およびstbycustdbhost1という名前のデータベース・ホストの別名を定義します。表3-39に、別名を定義する前のデータベース・ホスト名とデータベース接続文字列を示します。

表3-39 データベース・ホスト名と接続文字列

サイト

データベース・ホスト名

データベース接続文字列

本番

custdbhost1.us.oracle.com

custdbhost1.us.oracle.com:1521:orcl

スタンバイ

stbycustdbhost1.us.oracle.com

stbycustdbhost1.us.oracle.com:1521:orcl

この例では、本番サイトのすべてのデータベース接続文字列に「custdbhost1.us.oracle.com:1521:orcl」という形式を使用します。フェイルオーバー操作またはスイッチオーバー操作の後、この接続文字列を「stbycustdbhost1.us.oracle.com:1521:orcl」に変更する必要があります。ただし、表3-40に示されているように、データベース・ホスト名に「proddb1」という別名を作成することで、接続文字列を手動で変更しなくて済むようにすることができます。これにより、シームレスなフェイルオーバーとスイッチオーバーが実現します。

表3-40 データベース・ホストの別名の指定

サイト

データベース・ホスト名

別名

データベース接続文字列

本番

custdbhost1.us.oracle.com

proddb1.us.oracle.com

proddb1.us.oracle.com:1521:orcl

スタンバイ

stbycustdbhost1.us.oracle.com

proddb1.us.oracle.com

proddb1.us.oracle.com:1521:orcl

この例では、本番サイトのデータベース・ホスト名とスタンバイ・サイトのデータベース・ホスト名に「proddb1.us.oracle.com」という別名を作成し、本番サイトとスタンバイ・サイトの接続文字列に「proddb1.us.oracle.com:1521:orcl」という形式を使用できるようにします。フェイルオーバー操作およびスイッチオーバー操作の際、接続文字列を変更する必要がないため、シームレスなフェイルオーバーとスイッチオーバーが実現します。

/etc/hostsファイル・エントリで別名を指定する際の形式は次のとおりです。

<IP>    <ALIAS WITH DOMAIN> <ALIAS>    <HOST NAME WITH DOMAIN> <HOST NAME>

この例では、本番サイトのホストcustdbhost1とスタンバイ・サイトのホストstbycustdbhost1にproddb1というデータベース・ホスト名の別名を作成します。hostsファイル・エントリでは、<ALIAS WITH DOMAIN>パラメータでデータベース・ホスト名の完全修飾された別名を、<ALIAS>パラメータでデータベース・ホスト名の短い別名を、<HOST NAME WITH DOMAIN>パラメータで完全修飾されたホスト名を、<HOST NAME>パラメータで短いホスト名を指定する必要があります。

そのため、本番サイトの/etc/hostsファイルでは、ホストcustdbhost1のエントリが次のようになっていることを確認してください。

152.68.196.213 proddb1.us.oracle.com proddb1 custdbhost1.us.oracle.com custdbhost1

また、スタンバイ・サイトの/etc/hostsファイルでは、ホストstbycustdbhost1のエントリが次のようになっていることを確認してください。

140.87.25.40   proddb1.us.oracle.com proddb1 stbycustdbhost1.us.oracle.com stbycustdbhost1

3.4 開始ポイント

スタンバイ・サイトを設定する前に、管理者はプロジェクトの開始ポイントを評価する必要があります。通常、Oracle Fusion Middleware障害時リカバリ・トポロジを設計する際の開始ポイントは次のいずれかです。

- 本番サイトがすでに作成されており、スタンバイ・サイトが計画および作成中です。
既存の本番サイトがある場合にOracle Fusion Middleware障害時リカバリのスタンバイ・サイトを設計する方法については、第3.4.1項「既存のサイトを基にした設計」を参照してください。

- 既存の本番サイトもスタンバイ・サイトもありません。両方とも設計して作成する必要があります。
既存の本番サイトもスタンバイ・サイトもない場合にOracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく設計する方法については、第3.4.2項「新しいサイトの設計」を参照してください。

- 一部のホストやコンポーネントが現在の本番サイトに存在するものの、そのサイトまたはスタンバイ・サイトに新しいホストやコンポーネントを追加して、適切に機能するOracle Fusion Middleware障害時リカバリ・トポロジを設定する必要があります。
この章に記載されている関連情報を参考にして、Oracle Fusion Middleware障害時リカバリ・トポロジを設計および実装してください。

3.4.1 既存のサイトを基にした設計

管理者の開始ポイントが既存の本番サイトである場合、本番サイトの構成データおよびOracleバイナリがファイル・システムにすでに存在します。また、ホスト名、ポートおよびユーザー・アカウントもすでに定義されています。本番サイトが存在する場合、管理者は次の方法を選択できます。

- 対称スタンバイ・サイトを設計します。第3.5.1項「対称トポロジの設計に関する考慮事項」を参照してください。

- 非対称スタンバイ・サイトを設計します。第3.5.2項「非対称トポロジの設計に関する考慮事項」を参照してください。

- 本番サイトが共有ストレージにない場合、本番サイトを共有ストレージに移行し、対称スタンバイ・サイトまたは非対称スタンバイ・サイトを作成します。第3.4.1.1項「共有ストレージへの既存の本番サイトの移行」を参照してください。

3.4.1.1 共有ストレージへの既存の本番サイトの移行

Oracle Fusion Middleware障害時リカバリ・ソリューションでは、共有ストレージを使用して、Oracle Fusion Middlewareの中間層構成の障害時保護に使用するストレージ・レプリケーションを実装します。本番サイトがすでに作成されている場合、サイトを構成するOracle Fusion MiddlewareインスタンスのOracleホーム・ディレクトリが共有ストレージに配置されていない可能性があります。その場合、Oracle Fusion Middleware障害時リカバリ・ソリューションを実装するには、それらのホームをすべて共有ストレージに移行する必要があります。

ローカル・ディスクから共有ストレージに本番サイトを移行する際のガイドラインは次のとおりです。

1. 実行するバックアップはすべて、オフライン・バックアップである必要があります。詳細は、『Oracle Fusion Middleware管理者ガイド』のバックアップのタイプに関する説明および推奨されるバックアップ計画に関する説明を参照してください。

2. ルート・ユーザーとしてバックアップを実行する必要があり、その権限を保持している必要があります。『Oracle Fusion Middleware管理者ガイド』のバックアップ計画の概要に関する説明を参照してください。

3. これは1回のみの操作なので、ドメイン全体をリカバリすることをお薦めします。

4. 共有ストレージのディレクトリ構造は、第4.1.1項「ディレクトリ構造とボリューム設計」の説明に従って設定する必要があります。

5. Oracle SOA Suiteについては、『Oracle Fusion Middleware管理者ガイド』のOracle SOA Suiteのバックアップおよびリカバリの推奨事項に関する説明を参照してください。

6. Oracle WebCenter Portalについては、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenter Portalのバックアップおよびリカバリの推奨事項に関する説明を参照してください。

7. Oracle Identity Managementについては、『Oracle Fusion Middleware管理者ガイド』のOracle Identity Managementのバックアップおよびリカバリの推奨事項に関する説明を参照してください。

8. Oracle WebLogic Serverについては、『Oracle Fusion Middleware管理者ガイド』のOracle JRFインストールのバックアップおよびリカバリの推奨事項に関する説明を参照してください。

9. Web層については、『Oracle Fusion Middleware管理者ガイド』のWeb層インストールのバックアップおよびリカバリの推奨事項に関する説明を参照してください。

10. Oracle WebCenter Contentについては、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenter Contentのバックアップおよびリカバリに関する推奨事項の項を参照してください。

11. Oracle Business Intelligenceについては、『Oracle Fusion Middleware管理者ガイド』のOracle Business Intelligenceのバックアップおよびリカバリの推奨事項に関する説明を参照してください。

12. Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererのバックアップとリカバリに関する推奨事項については、『Oracle Fusion Middleware管理者ガイド』のOracle Portal、Oracle Forms Services、Oracle Reportsの各インストールのバックアップおよびリカバリの推奨事項に関する説明を参照してください。

3.4.2 新しいサイトの設計

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジの新しい本番サイトを実装する際の考え方を紹介します。ここでは、ホスト名を事前に計画し、ホスト名別名と物理ホスト名を解決するようにホストを構成して、これらの名前に基づいて構成をスタンバイ・サイトにコピーするようにストレージ・レプリケーションを設定することによって、本番サイトを計画および設定する方法について説明します。本番サイトを設計する際には、スタンバイ・サイトについても計画する必要があります。対称スタンバイ・サイトまたは非対称スタンバイ・サイトのいずれかを選択できます。

既存の本番サイトを使用せずに新しい本番サイトを設計する場合は、Oracle Universal Installerを使用して本番サイトにソフトウェアをインストールし、ホスト名別名やソフトウェア・パスなどのパラメータが両方のサイトで同じになるように慎重に設計する必要があります。

Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく作成する場合、次のような柔軟性があります。

1. 本番サイトとスタンバイ・サイトの各ホストが目的のホスト名別名および物理ホスト名を使用するように、Oracle Fusion Middleware障害時リカバリ・ソリューションを設計できます。ホスト名の計画については、第3.1.1項「ホスト名の計画」を参照してください。

2. 本番サイトを最初から設計して作成する場合、各Fusion MiddlewareインストールのOracleホーム名およびOracleホーム・ディレクトリを選択できます。
サイトを最初から設計して作成する方が、この章で説明した設計要件に合わせて既存のサイトを変更するよりも簡単です。

3. 本番サイトのホストのFusion Middlewareインストールに、スタンバイ・サイトのホストで使用するポートと競合しないポートを割り当てることができます。
既存の本番サイトとスタンバイ・サイト間におけるポートの競合を確認して解決するよりも、この方が簡単です。

3.5 トポロジに関する考慮事項

この項では、次のトポロジの設計に関する考慮事項について説明します。

- 対称トポロジ

- 非対称トポロジ

3.5.1 対称トポロジの設計に関する考慮事項

対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層がまったく同じように構成されます。対称トポロジでは、本番サイトとスタンバイ・サイトで同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションを使用します。また、両方のサイトで同じポートが使用されます。システムはまったく同じように構成され、アプリケーションは同じデータにアクセスします。このマニュアルでは、エンタープライズ構成用に、Oracle Fusion Middleware障害時リカバリで対称トポロジを設定する方法について説明します。

3.5.2 非対称トポロジの設計に関する考慮事項

非対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成に相違があります。非対称トポロジでは、スタンバイ・サイトで使用するハードウェアの数が少ない場合があります(本番サイトには4つのホストと4つのFusion Middlewareインスタンスがあるのに対して、スタンバイ・サイトには2つのホストと4つのFusion Middlewareインスタンスがある場合など)。また、別の非対称トポロジでは、スタンバイ・サイトで使用するFusion Middlewareインスタンスの数が少ない場合があります(本番サイトのFusion Middlewareインスタンスが4つであるのに対して、スタンバイ・サイトのFusion Middlewareインスタンスが2つである場合など)。さらに別の非対称トポロジでは、データベースの構成が異なる場合があります(本番サイトではReal Application Clustersデータベースを使用し、スタンバイ・サイトでは単一インスタンス・データベースを使用する場合など)。

4 障害時リカバリ・サイトの設定と管理

この章では、Oracle SOA Suiteのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用して、本番サイトおよびスタンバイ・サイトの設定に必要な手順を説明します。

次のトピックが含まれます:

- サイトの設定

- 本番サイトの作成

- スタンバイ・サイトの作成

- 非対称スタンバイ・サイトの作成

- サイトの操作および管理の実行

- Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用

注意:

Oracle Site Guardを使用してスイッチオーバーやフェイルオーバーなどの障害回復操作を自動化することができます。詳細は、第5章「Oracle Site Guardの使用方法」を参照してください。

4.1 サイトの設定

この項では、本番サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。

次のトピックが含まれます:

- ディレクトリ構造とボリューム設計

- ストレージ・レプリケーション

- データベース

- ノード・マネージャ

本番サイトの作成を開始する前に、次の事前準備が完了していることを確認してください。

- 中間層ホストのホスト名別名を設定します。第3.1.1項「ホスト名の計画」を参照してください。

- 本番サイトの共有ストレージに必要なボリュームを作成します。第4.1.1項「ディレクトリ構造とボリューム設計」を参照してください。

- マウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。第3.2.3項「ストレージ・レプリケーション」を参照して、本番サイトにシンボリック・リンクを作成する必要があるかどうかを確認してください。

- 使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、こうした情報が正しく特定されていることを確認してください。
詳細は、Oracle Data Guardの概念と管理、および関連事項として次のURLにある最大可用性アーキテクチャに関する情報を参照してください。

http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

4.1.1 ディレクトリ構造とボリューム設計

次の項では、お薦めするディレクトリ構造について詳しく説明します。エンド・ユーザーは他のディレクトリ・レイアウトを選択してもかまいませんが、ここで採用されているモデルを使用すると、コンポーネントが最適に分離され、構成における対称性が保たれるとともに、バックアップと障害時リカバリが容易になり、最大限の可用性が実現されます。

次の一覧では、ディレクトリとディレクトリ環境変数について説明します。

- ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを表します。

- MW_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を表します。

- WL_HOME: この環境変数および関連するディレクトリ・パスには、Oracle WebLogic Serverをホストするために必要なファイルがインストールされて格納されます。

- ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、製品スイート(Oracle SOA Suite、Oracle WebCenter Portal、Oracle Identity Managementなど)がインストールされている場所を表します。

- DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogic Domain情報(構成アーティファクト)が保存されている場所を表します。後述のように同じノード内にある場合でも、個々のWebLogic Serverで異なるドメイン・ディレクトリを使用できます。

- ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなど、1つ以上のシステム・コンポーネントが格納されます。Oracleインスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。

詳細は、次を参照してください。

- Oracle SOA Suiteのディレクトリ構造に関する推奨事項

- Oracle WebCenter Portalのディレクトリ構造に関する推奨事項

- Oracle Identity Managementのディレクトリ構造に関する推奨事項

- Oracle Portal、Forms、ReportsおよびDiscovererのディレクトリ構造に関する推奨事項

- Oracle WebCenter Contentのディレクトリ構造に関する推奨事項

- Oracle Business Intelligenceのディレクトリ構造に関する推奨事項

4.1.1.1 Oracle SOA Suiteのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のSOA管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-1は、Oracle SOA Suiteのディレクトリ構造のレイアウトを示しています。

図4-1 SOAのディレクトリ構造

「図4-1 SOAのディレクトリ構造」の説明

このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』およびOracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドを参照してください。

表4-1では、図4-1で色分けされている要素の意味を説明します。図4-1のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-1 ディレクトリ構造の要素

要素

説明

管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体が共有ディスクに配置されます。

固定名です。

インストール依存名です。

4.1.1.1.1 Oracle SOA Suiteのボリューム設計

図4-2および図4-3は、Oracle SOA Suiteのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle SOA Suiteトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

図4-2 Oracle Access Managerを使用したMySOACompanyトポロジ

「図4-2 Oracle Access Managerを使用したMySOACompanyトポロジ」の説明

図4-3 Oracle Access ManagerおよびBPMを使用したMySOACompanyトポロジ

このOracle SOA Suiteトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。

- 製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-2のVOLFMW1およびVOLFMW2)。

- 管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-2のVOLADMIN)。

- 管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-2のVOLSOA1およびVOLSOA2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

- JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-2のVOLDATA)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。

- Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-2のVOLWEB1およびVOLWEB2)。

- Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-2のVOLWEBINST1およびVOLWEBINST2)。

表4-2に、図4-2および図4-3に示されているOracle SOA Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-2 Oracle SOA Suiteのボリューム設計に関する推奨事項

層

ボリューム名

マウントされるホスト

マウント・ポイント

コメント

Web

VOLWEB1

WEBHOST1

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEB2

WEBHOST2

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEBINST1

WEBHOST1

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLWEBINST2

WEBHOST2

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLSTATIC1脚注 1

WEBHOST1

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

Web

VOLSTATIC2脚注 2

WEBHOST2

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

アプリケーション

VOLFMW1

SOAHOST1

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム

アプリケーション

VOLFMW2

SOAHOST2

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム

アプリケーション

VOLADMIN

SOAHOST1

/u01/app/oracle/admin/soaDomain/admin

管理サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLSOA1

SOAHOST1

/u01/app/oracle/admin/soaDomain/mng1

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLSOA2

SOAHOST2

/u01/app/oracle/admin/soaDomain/mng2

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLDATA

SOAHOST1、SOAHOST2

/u01/app/oracle/admin/soaDomain/soaCluster/jms

/u01/app/oracle/admin/soaDomain/soaCluster/tlogs

トランザクション・ログおよびJMSデータ用のボリューム

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.1.2 Oracle SOA Suiteのコンシステンシー・グループに関する推奨事項

Oracle SOA Suiteトポロジについては、次のコンシステンシー・グループをお薦めします。

- 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のDOMAINGROUP)。

- JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のDATAGROUP)。

- Middlewareホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のFMWHOMEGROUP)。

- Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のWEBHOMEGROUP)。

- Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のWEBINSTANCEGROUP)。

表4-3に、図4-2に示されているOracle SOA Suiteトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-3 Oracle SOA Suiteのコンシステンシー・グループ

層

グループ名

メンバー

コメント

アプリケーション

DOMAINGROUP

VOLADMIN

VOLSOA1

VOLSOA2

管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ

アプリケーション

DATAGROUP

VOLDATA

JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ

アプリケーション

FMWHOMEGROUP

VOLFMW1

VOLFMW2

Middlewareホーム用のコンシステンシー・グループ

Web

WEBHOMEGROUP

VOLWEB1

VOLWEB2

Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ

Web

WEBINSTANCEGROUP

VOLWEBINST1

VOLWEBINST2

VOLSTATIC1脚注 1

VOLSTATIC2脚注 2

Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.2 Oracle WebCenter Portalのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のOracle WebCenter Portal管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-1は、Oracle WebCenter Portalのディレクトリ構造のレイアウトを示しています(Oracle SOA SuiteとOracle WebCenter Portalの両方に同じディレクトリ構造のレイアウトが使用されます)。

4.1.1.2.1 Oracle WebCenter Portalのボリューム設計

図4-4は、Oracle WebCenter Portalのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle WebCenter Portalトポロジのものです。このトポロジのインストールおよび構成の手順は、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドを参照してください。

図4-4 Oracle Access Managerを使用したMyWCPCompanyトポロジ

「図4-4 Oracle Access Managerを使用したMyWCPCompanyトポロジ」の説明

このOracle WebCenter Portalトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。

- 製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-4のVOLFMW1およびVOLFMW2)。

- 管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-4のVOLADMIN)。

- SOAの管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLSOA1およびVOLSOA2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

- Oracle WebCenter Portalの管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLWCP1およびVOLWCP2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

- JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-4のVOLDATA)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。

- Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLWEB1およびVOLWEB2)。

- Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLWEBINST1およびVOLWEBINST2)。

表4-4に、図4-4に示されているOracle WebCenter Portalトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-4 Oracle WebCenter Portalのボリューム設計に関する推奨事項

層

ボリューム名

マウントされるホスト

マウント・ポイント

コメント

Web

VOLWEB1

WEBHOST1

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEB2

WEBHOST2

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEBINST1

WEBHOST1

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLWEBINST2

WEBHOST2

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLSTATIC1脚注 1

WEBHOST1

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

Web

VOLSTATIC2脚注 2

WEBHOST2

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

アプリケーション

VOLFMW1

SOAHOST1

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム

アプリケーション

VOLFMW2

SOAHOST2

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム

アプリケーション

VOLADMIN

SOAHOST1

/u01/app/oracle/admin/soaDomain/admin

管理サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLSOA1

SOAHOST1

/u01/app/oracle/admin/soaDomain/mng1

SOAの管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLSOA2

SOAHOST2

/u01/app/oracle/admin/soaDomain/mng2

SOAの管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLWC1

WCPHOST1

/u01/app/oracle/admin/wcpDomain/mng1

Oracle WebCenter Portalの管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLWC2

WCPHOST2

/u01/app/oracle/admin/wcpDomain/mng2

Oracle WebCenter Portalの管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLDATA

SOAHOST1、SOAHOST2、WCPHOST1、WCPHOST2

/u01/app/oracle/admin/soaDomain/soaCluster/jms

/u01/app/oracle/admin/soaDomain/soaCluster/tlogs

トランザクション・ログおよびJMSデータ用のボリューム

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.2.2 Oracle WebCenter Portalのコンシステンシー・グループに関する推奨事項

Oracle WebCenter Portalトポロジについては、次のコンシステンシー・グループをお薦めします。

- 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のDOMAINGROUP)。

- JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のDATAGROUP)。

- Middlewareホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のFMWHOMEGROUP)。

- Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のWEBHOMEGROUP)。

- Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のWEBINSTANCEGROUP)。

表4-5に、図4-4に示されているOracle WebCenter Portalトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-5 Oracle WebCenter Portalのコンシステンシー・グループ

層

グループ名

メンバー

コメント

アプリケーション

DOMAINGROUP

VOLADMIN

VOLSOA1

VOLSOA2

管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ

アプリケーション

DATAGROUP

VOLDATA

JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ

アプリケーション

FMWHOMEGROUP

VOLFMW1

VOLFMW2

Middlewareホーム用のコンシステンシー・グループ

Web

WEBHOMEGROUP

VOLWEB1

VOLWEB2

Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ

Web

WEBINSTANCEGROUP

VOLWEBINST1

VOLWEBINST2

VOLSTATIC1脚注 1

VOLSTATIC2脚注 2

Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.3 Oracle Identity Managementのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 11gでは、Oracle Identity Managementコンポーネントの製品バイナリと実行時アーティファクトを別々にすることができます。製品バイナリはORACLE_HOMEディレクトリに配置され、実行時アーティファクトはORACLE_INSTANCEディレクトリに配置されます。

このモデルでは、Web層およびデータ層については、ホストごとに(製品バイナリ用の)ORACLE_HOMEを1つと、インスタンスごとにORACLE_INSTANCEを1つ共有ストレージにインストールすることをお薦めします。ORACLE_HOMEは、ホストで実行されるすべてのインスタンス間で共有されますが、ORACLE_INSTANCEには、各インスタンスで独自の場所が使用されます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。

アプリケーション層については、ホストごとにMiddlewareホーム(MW HOME)を1つ(それぞれに、各製品スイートのWLS HOMEとORACLE_HOMEがあります)共有ストレージにインストールすることをお薦めします。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、この場所を、追加でインストールすることなくそのまま使用できます。

ドメイン・ディレクトリとMW_HOMEを別々にすることはできません。ドメイン・ディレクトリはMW_HOMEに配置され、ホストで実行されるすべての管理サーバーおよび管理対象サーバー間で共有されます。第4.1.1.3項「Oracle Identity Managementのディレクトリ構造」では、Oracle Identity Managementのディレクトリ構造のレイアウトを紹介します。

図4-5 Oracle Identity Managementのディレクトリ構造

「図4-5 Oracle Identity Managementのディレクトリ構造」の説明

表4-6 ディレクトリ構造の要素

要素

説明

管理サーバー・ドメインのディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ・コントロール・ディレクトリ、JMSログ、TXログ、およびMW_HOME全体は共有ディスク上にあります。

管理対象サーバー・ドメインのディレクトリは、共有ディスクに配置する必要があります。また、管理対象サーバー・ドメインのディレクトリを複数のノード上で共有する場合、ノード間で同じ共有ディスクの場所をマウントする必要があります。Web層のinstance_nameディレクトリは、共有ディスクに配置する必要があります。

固定名です。

インストール依存名です。

このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。図4-5のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

4.1.1.3.1 Oracle Identity Managementのボリューム設計

図4-6、図4-7および図4-8は、Oracle Identity Managementのトポロジを示しています。この項で説明するボリューム設計は、これらのOracle Identity Managementトポロジのものです。このトポロジのインストールおよび構成の手順は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

図4-6 Oracle Access Managerを使用したMyIMCompanyトポロジ

「図4-6 Oracle Access Managerを使用したMyIMCompanyトポロジ」の説明

図4-7 Oracle Access ManagerおよびOracle Identity Managerを使用したMyIMCompanyトポロジ

図4-8 Oracle Adaptive Access Managerを使用したMyIMCompanyトポロジ

図4-6、図4-7および図4-8に示されているOracle Identity Managementのエンタープライズ・デプロイメントを設定する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

Oracle Identity Managementについては、次のボリューム設計をお薦めします。

- Middlewareホーム用に各Identity Managementノードでボリュームを1つプロビジョニングします。このボリュームには、WebLogic Serverホーム、Identity ManagementのOracleホーム、そのホストで実行される管理サーバーおよび管理対象サーバーのドメイン・ディレクトリも格納されます。これらは、表4-7のVOLIDM1およびVOLIDM2です。

- ディレクトリ層およびWeb層のOracleホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-7のVOLWEB1、VOLWEB2、VOLOID1、VOLOID2、VOLOVD1およびVOLOVD2です。

- ディレクトリ層およびWeb層のOracleインスタンス・ホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-7のVOLWEBINST1、VOLWEBINST2、VOLOIDINST1、VOLOIDINST2、VOLOVDINST1およびVOLIOVDINST2です。

- Identity Management Oracleインスタンス、管理サーバーおよびアプリケーション層の管理対象サーバーのインスタンス用に各ノードでボリュームを1つずつプロビジョニングします。このボリュームは、管理サーバーおよび管理対象サーバーのインスタンスで共有されます。これらは、表4-7のVOLIDMINST1およびVOLIDMINST2です。

- JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-7のVOLDATA)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。

表4-7に、図4-6に示されているOracle Identity Managementトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-7 Oracle Identity Managementのボリュームに関する推奨事項

層

ボリューム名

マウントされるノード

マウント・ポイント

コメント

Web

VOLWEB1

WEBHOST1

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEB2

WEBHOST2

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEBINST1

WEBHOST1

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLWEBINST2

WEBHOST2

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLSTATIC1脚注 1

WEBHOST1

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

Web

VOLSTATIC2脚注 2

WEBHOST2

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

アプリケーション

VOLIDM1

IDMHOST1

/u01/app/oracle/product/fmw

Identity ManagementのMiddlewareホーム用のボリューム

アプリケーション

VOLIDM2

IDMHOST2

/u01/app/oracle/product/fmw

Identity ManagementのMiddlewareホーム用のボリューム

アプリケーション

VOLIDMINST1

IDMHOST1、OIMHOST1およびOAAMHOST1

/u01/app/oracle/admin

Oracleインスタンス用のボリューム

アプリケーション

VOLIDMINST2

IDMHOST2、OIMHOST2およびOAAMHOST2

/u01/app/oracle/admin

Oracleインスタンス用のボリューム

ディレクトリ

VOLOID1

OIDHOST1

/u01/app/oracle/product/fmw/idm

Oracle Internet DirectoryのOracleホーム用のボリューム

ディレクトリ

VOLOID2

OIDHOST2

/u01/app/oracle/product/fmw/idm

Oracle Internet DirectoryのOracleホーム用のボリューム

ディレクトリ

VOLOIDINST1

OIDHOST1

/u01/app/oracle/admin

Oracle Internet DirectoryのOracleインスタンス用のボリューム

ディレクトリ

VOLOIDINST2

OIDHOST2

/u01/app/oracle/admin

Oracle Internet DirectoryのOracleインスタンス用のボリューム

ディレクトリ

VOLOVD1

OVDHOST1

/u01/app/oracle/product/fmw/idm

Oracle Virtual DirectoryのOracleホーム用のボリューム

ディレクトリ

VOLOVD2

OVDHOST2

/u01/app/oracle/product/fmw/idm

Oracle Virtual DirectoryのOracleホーム用のボリューム

ディレクトリ

VOLOVDINST1

OVDHOST1

/u01/app/oracle/admin

Oracle Virtual DirectoryのOracleインスタンス用のボリューム

ディレクトリ

VOLOVDINST2

OVDHOST2

/u01/app/oracle/admin

Oracle Virtual DirectoryのOracleインスタンス用のボリューム

アプリケーション

VOLDATA

OIMHOST1、OIMHOST2

/u01/app/oracle/admin/oimDomain/soaCluster/jms

/u01/app/oracle/admin/oimDomain/soaCluster/tlogs

トランザクション・ログおよびJMSデータ用のボリューム

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.3.2 Oracle Identity Managementのコンシステンシー・グループに関する推奨事項

Oracle Identity Managementトポロジについては、次のコンシステンシー・グループをお薦めします。

- アプリケーション層のMiddlewareホーム・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のIDMMWGROUPグループです。

- アプリケーション層のOracleインスタンス・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のIDMINSTGROUPグループです。

- Oracle Internet DirectoryのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOIDHOMEGROUPグループです。

- Oracle Internet DirectoryのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOIDINSTGROUPグループです。

- Oracle Virtual DirectoryのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOVDHOMEGROUPグループです。

- Oracle Virtual DirectoryのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOVDINSTGROUPグループです。

- Oracle Access Managerのアイデンティティ・サーバーおよびアクセス・サーバー・コンポーネント用のOracle Access ManagerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOAMGROUPグループです。

- Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のWEBHOMEGROUPグループです。

- Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のWEBINSTGROUPグループです。

- JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のDATAGROUPです。

表4-8に、図4-6に示されているOracle Identity Managementトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-8 Oracle Identity Managementのコンシステンシー・グループ

層

グループ名

メンバー

コメント

ディレクトリ

OIDHOMEGROUP

VOLOID1

VOLOID2

Oracle Internet DirectoryのOracleホーム用のコンシステンシー・グループ

ディレクトリ

OIDINSTGROUP

VOLOIDINST1

VOLOIDINST2

Oracle Internet DirectoryのOracleインスタンス用のコンシステンシー・グループ

ディレクトリ

OVDHOMEGROUP

VOLOVD1

VOLOVD2

Oracle Virtual DirectoryのOracleホーム用のコンシステンシー・グループ

ディレクトリ

OVDINSTGROUP

VOLOVDINST1

VOLOVDINST2

Oracle Virtual DirectoryのOracleインスタンス用のコンシステンシー・グループ

アプリケーション

IDMMWGROUP

VOLIDM1

VOLIDM2

Middlewareホーム用のコンシステンシー・グループ

アプリケーション

IDMINSTGROUP

VOLIDMINST1

VOLIDMINST2

Identity Managementインスタンス用のコンシステンシー・グループ

Web

WEBHOMEGROUP

VOLWEB1

VOLWEB2

Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ

Web

WEBINSTGROUP

VOLWEBINST1

VOLWEBINST2

VOLSTATIC1脚注 1

VOLSTATIC2脚注 2

Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.4 Oracle Portal、Forms、ReportsおよびDiscovererのディレクトリ構造に関する推奨事項

図4-9は、Oracle Portalのエンタープライズ・デプロイメント・トポロジ・ダイアグラムです。このOracle Portalトポロジを含む障害時リカバリ・サイトには、第4.1.1.4.1項「Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計」と第4.1.1.4.2項「Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループに関する推奨事項」に記載されているボリューム設計とコンシステンシー・グループを使用できます。

図4-9のOracle Portalエンタープライズ・トポロジの詳細は、11.1.1.2 Oracle Portalエンタープライズ・デプロイメント・ガイドに記載されています。このマニュアルの入手方法は、My Oracle Support(以前のOracle MetaLink)にある記事ID 952068.1「Oracle Fusion Middleware 11g(11.1.1.2)Portal、Forms、ReportsおよびDiscoverエンタープライズ・デプロイメント・ガイド」を参照してください。My Oracle SupportのURLは次のとおりです。

http://support.oracle.com

図4-9 Oracle Portalのトポロジ・ダイアグラム

「図4-9 Oracle Portalのトポロジ・ダイアグラム」の説明

図4-10は、Oracle Forms、ReportsおよびDiscovererのエンタープライズ・トポロジ・ダイアグラムです。このトポロジを含む障害時リカバリ・サイトには、第4.1.1.4.1項「Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計」と第4.1.1.4.2項「Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループに関する推奨事項」に記載されているボリューム設計とコンシステンシー・グループを使用できます。

図4-10のOracle Forms、ReportsおよびDiscovererエンタープライズ・トポロジの詳細は、11.1.1.2 Oracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメント・ガイドに記載されています。このマニュアルの入手方法は、My Oracle Support(以前のOracle MetaLink)にある記事ID 952068.1「Oracle Fusion Middleware 11g(11.1.1.2)Portal、Forms、ReportsおよびDiscoverエンタープライズ・デプロイメント・ガイド」を参照してください。My Oracle SupportのURLは次のとおりです。

http://support.oracle.com

図4-10 Oracle Forms、ReportsおよびDiscovererのトポロジ

「図4-10 Oracle Forms、ReportsおよびDiscovererのトポロジ」の説明

4.1.1.4.1 Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計

図4-9に示されているOracle Portalトポロジと図4-10に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトについては、次のボリューム設計をお薦めします。

- Middlewareホーム用に各アプリケーション層ホストでボリュームを1つプロビジョニングします。このボリュームには、WebLogic Serverホーム、Oracle Portal、Reports、FormsおよびDiscovererコンポーネントのOracleホーム、そのホストで実行される管理サーバーおよび管理対象サーバーのドメイン・ディレクトリも格納されます。これらは、表4-9のVOLPFRD1およびVOLPFRD2です。

- Web層のOracleホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-9のVOLWEB1およびVOLWEB2です。

- ディレクトリWeb層のOracleインスタンス・ホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-9のVOLWEBINST1およびVOLWEBINST2です。

- アプリケーション層のOracleインスタンス・ホーム用に各ノードでボリュームを1つプロビジョニングします。このボリュームは、管理サーバーおよび管理対象サーバーのインスタンスで共有されます。これらは、表4-9のVOLPFRDINST1およびVOLPFRDINST2です。

- アプリケーション層のOracle Reports出力ディレクトリ用にボリュームを1つプロビジョニングします。このボリュームは、Oracle Reportsサーバーを実行するすべてのノードでマウントされます。これは、表4-7のVOLREPOUTです。

表4-9に、図4-9に示されているOracle Portalトポロジと図4-10に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトのボリューム設計に関する推奨事項の概要を示します。

表4-9 Oracle Portal、Reports、FormsおよびDiscovererのボリューム設計に関する推奨事項

層

ボリューム名

マウントされるホスト

マウント・ポイント

コメント

Web

VOLWEB1

WEBHOST1

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEB2

WEBHOST2

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEBINST1

WEBHOST1

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLWEBINST2

WEBHOST2

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLSTATIC1脚注 1

WEBHOST1

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

Web

VOLSTATIC2脚注 2

WEBHOST2

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

アプリケーション

VOLPFRD1

APPHOST1

/u01/app/oracle/product/fmw

WebLogic Server、およびOracle Portal、Forms、ReportsおよびDiscovererバイナリ用のボリューム

アプリケーション

VOLPFRD2

APPHOST2

/u01/app/oracle/product/fmw

WebLogic Server、およびOracle Portal、Forms、ReportsおよびDiscovererバイナリ用のボリューム

アプリケーション

VOLPFRDINST1

APPHOST1

/u01/app/oracle/admin

Oracleインスタンス用のボリューム

アプリケーション

VOLPFRDINST2

APPHOST2

/u01/app/oracle/admin

Oracleインスタンス用のボリューム

アプリケーション

VOLREPOUT

APPHOST1、APPHOST2

/u01/app/oracle/admin

レポート出力用のボリューム

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.4.2 Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループに関する推奨事項

図4-9に示されているOracle Portalトポロジと図4-10に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトについては、次のコンシステンシー・グループをお薦めします。

- Web層のOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-10のWEBHOMEGROUPです。

- Web層のOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-10のWEBINSTGROUPです。

- アプリケーション層のMiddlewareホームを含むボリュームから成るコンシステンシー・グループを1つ作成します。これは、表4-10のPFRDMWGROUPです。

- アプリケーション層のOracleインスタンス・ホームを含むボリュームから成るコンシステンシー・グループを1つ作成します。これは、表4-10のPFRDINSTGROUPです。

- Oracle Reportsの出力ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-10のREPOUTGROUPです。

表4-10に、図4-9に示されているOracle Portalトポロジと図4-10に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-10 Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループ

層

ボリューム名

メンバー

コメント

アプリケーション

PFRDMWGROUP

VOLPFRD2

VOLPFRD2

Middlewareホーム用のコンシステンシー・グループ

アプリケーション

PFRDINSTGROUP

VOLPFRDINST1

VOLPFRDINST2

インスタンス・ホーム用のコンシステンシー・グループ

アプリケーション

REPOUTGROUP

VOLREPOUT

Reportsの出力ディレクトリ用のコンシステンシー・グループ

Web

WEBHOMEGROUP

VOLWEB1

VOLWEB2

Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ

Web

WEBINSTGROUP

VOLWEBINST1

VOLWEBINST2

VOLSTATIC1脚注 1

VOLSTATIC2脚注 2

Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.5 Oracle WebCenter Contentのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のOracle Enterprise Content Management管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-11は、Oracle WebCenter Content Suiteのディレクトリ構造のレイアウトを示しています。

図4-11 Oracle WebCenter Contentのディレクトリ構造

「図4-11 Oracle WebCenter Contentのディレクトリ構造」の説明

図4-11のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-11では、図4-11で色分けされている要素の意味を説明します。図4-11のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-11 ディレクトリ構造の要素

要素

説明

管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体が共有ディスクに配置されます。

固定名です。

インストール依存名です。

このディレクトリ構造の設定の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドを参照してください。

4.1.1.5.1 Oracle WebCenter Contentのボリューム設計

図4-12は、Oracle WebCenter Contentのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle WebCenter Contentトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドを参照してください。

図4-12 Oracle WebCenter Contentエンタープライズ・デプロイメントの参照トポロジ

「図4-12 Oracle WebCenter Contentエンタープライズ・デプロイメントの参照トポロジ」の説明

このOracle WebCenter Contentトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。

- 製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-12のVOLFMW1およびVOLFMW2)。

- 管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-12のVOLADMIN)。

- 管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-12のVOLWCC1およびVOLWCC2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

- JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-12のVOLDATA)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。

- Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-12のVOLWEB1およびVOLWEB2)。

- Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-12のVOLWEBINST1およびVOLWEBINST2)。

表4-12に、図4-12に示されているOracle Enterprise Content Management Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-12 Oracle WebCenter Contentのボリューム設計に関する推奨事項

層

ボリューム名

マウントされるホスト

マウント・ポイント

コメント

Web

VOLWEB1

WEBHOST1

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEB2

WEBHOST2

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEBINST1

WEBHOST1

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLWEBINST2

WEBHOST2

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLSTATIC1脚注 1

WEBHOST1

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

Web

VOLSTATIC2脚注 2

WEBHOST2

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

アプリケーション

VOLFMW1

WCCHOST1

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム

アプリケーション

VOLFMW2

WCCHOST2

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム

アプリケーション

VOLADMIN

WCCHOST1

/u01/app/oracle/admin/wccDomain/admin

管理サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLWCC1

WCCHOST1

/u01/app/oracle/admin/wccDomain/mng1

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLWCC2

WCCHOST2

/u01/app/oracle/admin/wccDomain/mng2

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLDATA

WCCHOST1、WCCHOST2

/u01/app/oracle/admin/wccDomain/soaCluster/jms

/u01/app/oracle/admin/wccDomain/soaCluster/tlogs

トランザクション・ログおよびJMSデータ用のボリューム

UCM関連の他のディレクトリは、ドメインの外部に構成されます。

UCMファイル(VaultおよびWeblayout)のボリュームはドメインの外部に作成されます。

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.5.2 Oracle WebCenter Contentのコンシステンシー・グループに関する推奨事項

Oracle WebCenter Contentトポロジについては、次のコンシステンシー・グループをお薦めします。

- 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のDOMAINGROUP)。

- JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のDATAGROUP)。

- Middlewareホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のFMWHOMEGROUP)。

- Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のWEBHOMEGROUP)。

- Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のWEBINSTANCEGROUP)。

表4-13に、図4-12に示されているOracle WebCenter Contentトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-13 Oracle WebCenter Contentのコンシステンシー・グループ

層

グループ名

メンバー

コメント

アプリケーション

DOMAINGROUP

VOLADMIN

VOLWCC1

VOLWCC2

管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ

アプリケーション

DATAGROUP

VOLDATA

JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ

アプリケーション

FMWHOMEGROUP

VOLFMW1

VOLFMW2

Middlewareホーム用のコンシステンシー・グループ

Web

WEBHOMEGROUP

VOLWEB1

VOLWEB2

Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ

Web

WEBINSTANCEGROUP

VOLWEBINST1

VOLWEBINST2

VOLSTATIC1脚注 1

VOLSTATIC2脚注 2

Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.6 Oracle Business Intelligenceのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のOracle Business Intelligence管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-13は、Oracle Business Intelligence Suiteのディレクトリ構造のレイアウトを示しています。

図4-13 Oracle Business Intelligenceのディレクトリ構造

「図4-13 Oracle Business Intelligenceのディレクトリ構造」の説明

図4-13のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-14では、図4-13で色分けされている要素の意味を説明します。図4-13のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-14 ディレクトリ構造の要素

要素

説明

管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体が共有ディスクに配置されます。

固定名です。

インストール依存名です。

このディレクトリ構造の設定の詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドを参照してください。

4.1.1.6.1 Oracle Business Intelligenceのボリューム設計

図4-14は、Oracle Business Intelligenceのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle Business Intelligenceトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドを参照してください。

図4-14 Oracle Business Intelligenceエンタープライズ・デプロイメントの参照トポロジ

「図4-14 Oracle Business Intelligenceエンタープライズ・デプロイメントの参照トポロジ」の説明

このOracle Business Intelligenceトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。

- 製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-15のVOLFMW1およびVOLFMW2)。

- 管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-15のVOLADMIN)。

- 管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-15のVOLBI1およびVOLBI2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

- JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-15のVOLDATA1)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。

- Oracle Business Intelligence Enterprise Edition(EE)の共有ファイルおよびディレクトリ用にボリュームを1つプロビジョニングします(表4-15のVOLDATA2)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。このボリュームには、Oracle BIリポジトリ(RPDファイル)、Oracle BI Presentation Catalog、グローバル・キャッシュおよびOracle BI Schedulerの共有スクリプトが含まれます。

- Oracle Business Intelligence Publisherの共有構成ファイルおよびディレクトリ用にボリュームを1つプロビジョニングします(表4-15のVOLDATA3)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。このボリュームには、Oracle Business Intelligence Publisherの構成ファイルが格納されます。

- Oracle Business Intelligence Publisherカタログ用にボリュームを1つプロビジョニングします(表4-15のVOLDATA4)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。このボリュームには、Oracle Business Intelligence Publisherを使用して作成するオブジェクト(レポート、データ・モデル、スタイル・テンプレートなど)を格納するOracle Business Intelligence Publisherカタログが格納されます。

- Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-15のVOLWEB1およびVOLWEB2)。

- Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-15のVOLWEBINST1およびVOLWEBINST2)。

- Oracle Business IntelligenceのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-15のVOLBIINST1およびVOLBIINST2)。

表4-15に、図4-14に示されているOracle Business Intelligence Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-15 Oracle Business Intelligenceのボリューム設計に関する推奨事項

層

ボリューム名

マウントされるホスト

マウント・ポイント

コメント

Web

VOLWEB1

WEBHOST1

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEB2

WEBHOST2

/u01/app/oracle/product/fmw/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEBINST1

WEBHOST1

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLWEBINST2

WEBHOST2

/u01/app/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLSTATIC1脚注 1

WEBHOST1

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

Web

VOLSTATIC2脚注 2

WEBHOST2

/u01/app/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

アプリケーション

VOLBIINST1

HOST1

/u01/app/oracle/admin/bi_instance

Oracle Business Intelligenceのインスタンス用のボリューム

アプリケーション

VOLBIINST2

HOST2

/u01/app/oracle/admin/bi_instance

Oracle Business Intelligenceのインスタンス用のボリューム

アプリケーション

VOLFMW1

HOST1

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle Business Intelligenceのバイナリ用のボリューム

アプリケーション

VOLFMW2

BIHOST2

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle Business Intelligenceのバイナリ用のボリューム

アプリケーション

VOLADMIN

BIHOST1

/u01/app/oracle/admin/biDomain/admin

管理サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLBI1

BIHOST1

/u01/app/oracle/admin/biDomain/mng1

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLBI2

BIHOST2

/u01/app/oracle/admin/biDomain/mng1

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLDATA1

BIHOST1、BIHOST2

/u01/app/oracle/admin/biDomain/biCluster/jms

/u01/app/oracle/admin/biDomain/biCluster/tlogs

トランザクション・ログおよびJMSデータ用のボリューム

アプリケーション

VOLDATA2

BIHOST1、BIHOST2

/u01/app/oracle/admin/biDomain/biCluster/repository

Oracle BIリポジトリ(RPDファイル)、Oracle BI Presentation Catalog、グローバル・キャッシュおよびOracle BI Schedulerの共有スクリプト用のボリューム

アプリケーション

VOLDATA3

BIHOST1、BIHOST2

/u01/app/oracle/admin/biDomain/biCluster/bipublisher/config

Oracle Business Intelligence Publisherの構成ファイル用のボリューム

アプリケーション

VOLDATA4

BIHOST1、BIHOST2

/u01/app/oracle/admin/biDomain/biCluster/bipublisher/reports

Oracle Business Intelligence Publisherを使用して作成するオブジェクト(レポート、データ・モデル、スタイル・テンプレートなど)用のボリューム

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.6.2 Oracle Business Intelligenceのコンシステンシー・グループに関する推奨事項

Oracle Business Intelligenceトポロジについては、次のコンシステンシー・グループをお薦めします。

- 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のDOMAINGROUP)。

- JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のDATAGROUP1)。

- Oracle Business Intelligenceの共有ファイルとディレクトリ、およびOracle Business Intelligence Publisherの構成フォルダを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のDATAGROUP2)。

- Middlewareホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のFMWHOMEGROUP)。

- Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のWEBHOMEGROUP)。

- Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のWEBINSTANCEGROUP)。

- Oracle Business IntelligenceのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のBIINSTANCEGROUP)。

表4-16に、図4-14に示されているOracle Business Intelligenceトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-16 Oracle Business Intelligenceのコンシステンシー・グループ

層

グループ名

メンバー

コメント

アプリケーション

DOMAINGROUP

VOLADMIN

VOLBI1

VOLBI2

管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ

アプリケーション

DATAGROUP1

VOLDATA1

JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ

アプリケーション

DATAGROUP2

VOLDATA2

VOLDATA3

VOLDATA4

Oracle Business Intelligenceの共有ファイルとディレクトリ、およびOracle Business Intelligence Publisher構成用のコンシステンシー・グループ

アプリケーション

FMWHOMEGROUP

VOLFMW1

VOLFMW2

Middlewareホーム用のコンシステンシー・グループ

アプリケーション

BIINSTANCEGROUP

VOLBIINST1

VOLBIINST2

VOLSTATIC1脚注 1

VOLSTATIC2脚注 2

Oracle Business IntelligenceのOracleインスタンス用のコンシステンシー・グループ

Web

WEBHOMEGROUP

VOLWEB1

VOLWEB2

Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ

Web

WEBINSTANCEGROUP

VOLWEBINST1

VOLWEBINST2

VOLSTATIC1脚注 3

VOLSTATIC2脚注 4

Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注3 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注4 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.2 ストレージ・レプリケーション

Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定するには、次の手順を実行します。

1. スタンバイ・サイトで、本番サイトのピア・ホストに使用されている物理ホスト名と同じホスト名別名が作成されていることを確認します。

2. スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。

3. スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンクを作成します(スタンバイ・サイトでシンボリック・リンクを設定する必要があるのは、本番サイトでシンボリック・リンクを設定した場合のみです)。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

4. 本番サイトにインストールしたものと同じOracle Fusion Middlewareインスタンスをスタンバイ・サイトにインストールする必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているOracleソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。

5. 共有ストレージ・ベンダーが規定しているその他の必要な構成を実行して、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のストレージ・レプリケーションを有効にします。

6. 本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、本番サイトとスタンバイ・サイトの共有ストレージ間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。

7. スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。

8. Oracle Fusion Middleware障害時リカバリの本番サイトに含まれているデータベースの障害保護機能がOracle Data Guardによって提供されていることを確認します。Oracle Databaseの障害保護にストレージ・レプリケーション・テクノロジは使用しないでください。

9. スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。

10. 本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行することを強くお薦めします。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。

4.1.3 データベース

Oracle Fusion Middleware障害時リカバリ・トポロジで使用するOracle Databaseの設定に関する推奨事項および考慮事項の詳細は、第3.3項「データベースに関する考慮事項」を参照してください。

4.1.3.1 Oracle Data Guardの設定

Oracle Data Guardは、プライマリ・サイトとスタンバイ・サイトのOracle Fusion Middlewareリポジトリ・データベース間に設定する必要があります。スタンバイ・サイトのデータベースは、フィジカル・スタンバイ・データベースとして設定する必要があります。この項では、スタンバイ・サイトのデータ層の設定と構成について説明します。

Oracle Data Guardの詳細は、Oracle Databaseのドキュメント・セットの『Oracle Data Guard概要および管理』を参照してください。

4.1.3.1.1 前提条件

後述のOracle Data Guardの設定および構成手順は、次の条件を満たしていることを前提としています。

- スタンバイ・サイトのRACクラスタおよびASMインスタンスが作成されています。

- スタンバイ・サイトおよび本番サイトのRACデータベースでフラッシュ・リカバリ領域を使用しています。

- スタンバイ・サイトのデータベース・ホストにOracleソフトウェアがすでにインストールされています。

- スタンバイ・サイトのDB_HOMEの物理パスが本番サイトのものと一致しています。

4.1.3.1.2 Oracle Data Guard環境の説明

Oracle Data Guardの手順では、表4-17に記載されている環境変数を本番サイトのSOAデータベースに使用します。

表4-17 本番サイトのSOAデータベースに使用する環境変数

変数

値

SOAデータベースのホスト名

soadbhost1.mycompany.com

soadbhost2.mycompany.com

ORACLE_HOME

/u01/app/oracle/product/db_1

SOA_DBNAME

PSOA

SOA_DB_UNIQUE_NAME

PSOA

SOA_DB_INSTANCE_NAMES

SOA1、SOA2

SOA_SERVICE_NAMES

PSOA、SSOA

ORACLE_SID

SOA1、SOA2

Oracle Data Guardの手順では、表4-18に記載されている環境変数をスタンバイ・サイトのSOAデータベースに使用します。

表4-18 スタンバイ・サイトのSOAデータベースに使用する環境変数

変数

値

SOAデータベースのホスト名

soadbhost1.mycompany.com

soadbhost2.mycompany.com

ORACLE_HOME

/u01/app/oracle/product/db_1

SOA_DBNAME

PSOA

SOA_DB_UNIQUE_NAME

SSOA

SOA_DB_INSTANCE_NAMES

SOA1、SOA2

SOA_SERVICE_NAMES

PSOA、SSOA

ORACLE_SID

SOA1、SOA2

Oracle Data Guardの設定手順は、次の項で詳しく説明します。

- ファイルの収集とバックアップの実行

- スタンバイ・サイトでのOracle Net Servicesの構成

- スタンバイ・サイトでのインスタンスおよびデータベースの作成

- データベースのスイッチオーバーおよびスイッチバックのテスト

4.1.3.1.3 ファイルの収集とバックアップの実行

ファイルを収集し、データベースのバックアップを実行する手順は、次のとおりです。

1. プライマリ・サイトのSOADBHOST1で、ステージング用のディレクトリを作成します。例:

$ mkdir -p /u01/app/stage/psoa

2. スタンバイ・サイトのSOADBHOST1で、同じパスを作成します。ステップ1に記載されている例に従ってください。

3. プライマリ・サイトのSOADBHOST1でデータベース・インスタンスpsoa1に接続し、spfileからpfileを作成します。例:

SQL > create pfile='/u01/app/stage/psoa/initpsoa.ora' from spfile;

4. プライマリ・サイトのSOADBHOST1でRMANに接続し、データベースのバックアップを実行して、ステージング・ディレクトリにバックアップ・ファイルを配置します。例:

$ $ORACLE_HOME/bin/rman target /

RMAN> backup device type disk format '/u01/app/stage/psoa/%U' database plus
archivelog;

RMAN> backup device type disk format '/u01/app/stage/psoa/%U' current
controlfile for standby;

5. 次の手順に従って、RMANによって作成されたバックアップが有効であることを検証します。

6. プライマリ・サイトのSOADBHOST1でRMANに接続し、バックアップ・サマリを表示します。

7. ステップ4でRMANによって作成されたバックアップ・セットを検証します。

RMAN> list backup summary;
using target database control file instead of recovery catalog
List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
93      B  A  A DISK        14-MAY-07       1       1       NO      TAG20070514T122312
94      B  F  A DISK        14-MAY-07       1       1       NO      TAG20070514T122315
95      B  F  A DISK        14-MAY-07       1       1       NO      TAG20070514T122315
96      B  A  A DISK        14-MAY-07       1       1       NO      TAG20070514T122629
97      B  F  A DISK        14-MAY-07       1       1       NO      TAG20070514T123220

RMAN> validate backupset 93;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=451 instance=psoa1 devtype=DISK
channel ORA_DISK_1: starting validation of archive log backupset
channel ORA_DISK_1: reading from backup piece /u01/app/stage/psoa/34ihmtdg_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/app/stage/psoa/34ihmtdg_1_1 tag=TAG20070514T122312
channel ORA_DISK_1: validation complete, elapsed time: 00:00:02

8. プライマリ・サイトのSOADBHOST1で、listener.ora、sqlnet.oraおよびtnsnames.oraファイルを$ORACLE_HOME/network/adminディレクトリからステージング・ディレクトリにコピーします。

9. オペレーティング・システムのユーティリティを使用して、プライマリ・サイトのSOADBHOST1上のステージング・ディレクトリの内容をスタンバイ・サイトのSOADBHOST1上のステージング・ディレクトリにコピーします。

4.1.3.1.4 スタンバイ・サイトでのOracle Net Servicesの構成

スタンバイ・サイトでOracle Net Servicesを構成する手順は、次のとおりです。

1. listener.ora、sqlnet.oraおよびtnsnames.oraファイルを、プライマリ・サイトのSOADBHOST1上のステージング・ディレクトリからスタンバイ・サイトのすべてのノード上の$ORACLE_HOME/network/adminディレクトリにコピーします。

2. 各スタンバイ・ホストのlistener.oraファイルを、そのホストの仮想IPを含むように変更します。

3. プライマリRACノードやスタンバイRACノードなど各ノードのtnsnames.oraファイルを、プライマリおよびスタンバイのすべてのネット・サービス名を含むように変更します。

4. local_listenerおよびremote_listenerパラメータに使用されているOracle Netの別名を、各スタンバイ・ホストのリスナーを指すように変更します。次の例は、tnsnames.oraファイルの抜粋です。

#local_listener
PSOA =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = soadbhost1-vip)
(HOST = soadbhost2-vip)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = psoa)
)
)
#remote_listener
SSOA =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = soadbhost1-vip)
(HOST = soadbhost2-vip)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ssoa)
)
)

5. スタンバイ・データベース・ホストでリスナーを開始します。

4.1.3.1.5 スタンバイ・サイトでのインスタンスおよびデータベースの作成

スタンバイ・サイトでインスタンスおよびデータベースを作成する手順は、次のとおりです。

1. REDOデータを安全に送信するために、プライマリ・サイトとスタンバイ・サイトのデータベースでパスワード・ファイルを使用していることを確認するとともに、SYSユーザーのパスワードがすべてのシステムで同じであることを確認します。スタンバイ・データベースの両方のノードでパスワード・ファイルを作成してください。例:
スタンバイ・サイトのSOADBHOST1の場合

$ cd $ORACLE_HOME/dbs
$ orapwd file=orapwpsoa1 password=welcome1

スタンバイ・サイトのSOADBHOST2の場合

$ cd $ORACLE_HOME/dbs
$ orapwd file=orapwpsoa2 password=welcome1

2. スタンバイ・サイトのSOADBHOST1上のステージング領域から$ORACLE_HOME/dbsディレクトリにpfileをコピーし、名前を変更します。例:

$ cp /u01/app/stage/psoa/initpsoa.ora $ORACLE_HOME/dbs/initsoa1.ora

3. プライマリ・ノードからコピーしたスタンバイの初期化パラメータ・ファイルを、表4-19に記載されているパラメータを含むように変更します。

表4-19 スタンバイの初期化パラメータ・ファイルで指定するパラメータ

パラメータ

値

RACパラメータ

*.cluster_database=true

PSOA1.instance_name=SOA1

PSOA2.instance_name=SOA2

PSOA1.instance_number=1

PSOA2.instance_number=2

PSOA1.thread=1

PSOA2.thread=2

PSOA1.undo_tablespace=UNDOTBS1

PSOA2.undo_tablespace=UNDOTBS2

*.remote_listener=LISTENERS_PSOA

Data Guardパラメータ

*.db_unique_name=SSOA

*.log_archive_config='dg_config=(SSOA,PSOA)'

*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'

*.log_archive_dest_2='service=PSOA valid_for=(online_logfiles,primary_role) db_unique_name=PSOA'

*.db_file_name_convert='+DATA/PSOA/','+DATA/SSOA/','+RECO/PSOA','+RECO/SSOA'

*.log_file_name_convert='+DATA/PSOA/','+DATA/SSOA/','+RECO/PSOA','+RECO/SSOA'

*.standby_file_management=auto

*.fal_server='PSOA'

*.fal_client='SSOA'

その他のパラメータ

*.background_dump_dest=/u01/app/admin/PSOA/bdump

*.core_dump_dest=/u01/app/admin/PSOA/cdump

*.user_dump_dest=/u01/app/admin/PSOA/udump

*.audit_file_dest=/u01/app/admin/PSOA/adump

*.db_recovery_file_dest='+RECO'

*.dispatchers=PSOAXDB

4. スタンバイ・サイトのSOADBHOST1上のASMインスタンスに接続し、スタンバイ・データベースのDB_UNIQUE_NAMEと同じ名前のディレクトリをDATAディスク・グループ内に作成します。例:

SQL> alter diskgroup data add directory '+DATA/SSOA';

5. スタンバイ・サイトのSOADBHOST1上のスタンバイ・データベースに接続し(スタンバイ・データベースはIDLE状態です)、スタンバイDATAディスク・グループにSPFILEを作成します。例:

SQL> CREATE SPFILE='+DATA/SSOA/spfilepsoa.ora' FROM
PFILE='?/dbs/initsoa1.ora';

6. スタンバイ・サイトのSOADBHOST1およびSOADBHOST2上の$ORACLE_HOME/dbsディレクトリで、SPFILEへのポインタを含むPFILEを作成します。PFILEは、init<OracleSID>.oraというネーミング規則に従う必要があります。例:
SOADBHOST1の場合

$ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/SSOA/spfilepsoa.ora'" > initsoa1.ora

SOADBHOST2の場合

$ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/SSOA/spfilepsoa.ora'" > initsoa2.ora

7. スタンバイの初期化パラメータ・ファイルで参照されているすべてのスタンバイ・ホストでダンプ・ディレクトリを作成します。例:

$ mkdir -p $ORACLE_BASE/admin/psoa/bdump
$ mkdir -p $ORACLE_BASE/admin/psoa/cdump
$ mkdir -p $ORACLE_BASE/admin/psoa/udump
$ mkdir -p $ORACLE_BASE/admin/psoa/adump

8. スタンバイ・サイトのSOADBHOST1で、ORACLE_HOME、PATHおよびORACLE_SIDを設定し、制御ファイルをマウントせずにスタンバイ・データベースを起動します。このホストにはステージング・ディレクトリが必要です。例:

SQL > startup nomount

9. プライマリ・サイトのSOADBHOST1から、RMANを使用して、プライマリ・データベースをスタンバイとしてASMディスク・グループに複製します。例:

$ rman target / auxiliary sys/oracle@ssoa
RMAN> duplicate target database for standby;

10. SQL*Plusを使用して、新しく作成したデータベースにログインし、正しく作成されていることを検証します。例:

$ sqlplus '/as sysdba'

11. スタンバイ・サイトのSOADBHOST1上のスタンバイ・データベースに接続し、スタンバイ・ロールをサポートするためにスタンバイREDOログを作成します。例:

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
GROUP 5 SIZE 300M,
GROUP 6 SIZE 300M,
GROUP 7 SIZE 300M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2
GROUP 8 SIZE 300M,
GROUP 9 SIZE 300M,
GROUP 10 SIZE 300M;

12. スタンバイ・サイトのSOADBHOST1で、スタンバイ・データベースでの管理リカバリおよびリアルタイム適用を開始します。例:

SQL> ALTER DATABASE recover managed standby database using current logfile
disconnect;

13. スタンバイ・サイトのSOADBHOST1およびSOADBHOST2で、Server Control(SRVCTL)ユーティリティを使用して、スタンバイ・データベースとデータベース・インスタンスをOracle Cluster Registry(OCR)に登録します。例:

$ srvctl add database -d psoa -o /u01/app/oracle/product/10.2.0/db_1
$ srvctl add instance -d psoa -i soa1 -n soadbhost1
$ srvctl add instance -d psoa -i soa2 -n soadbhost2

14. データベースとASMインスタンス間に依存関係を確立します。例:

$ srvctl modify instance -d psoa -i soa1 -s +ASM1
$ srvctl modify instance -d psoa -i soa2 -s +ASM2
$ srvctl enable asm -n stbdd03 -i +ASM1
$ srvctl enable asm -n stbdd04 -i +ASM2

15. ステージング・ディレクトリ(/u01/app/stage/psoa/initpsoa.ora)にあるプライマリの初期化ファイルのData Guardパラメータを次の値に変更および追加して、Oracle Data Guardを使用するようにプライマリ・データベースを構成します。

*.log_archive_config='dg_config=(SSOA,PSOA)'
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'

*.log_archive_dest_2='service=SSOA valid_for=(online_logfiles,primary_role) db_unique_name=SSOA'

*.db_file_name_convert='+DATA/SSOA/','+DATA/PSOA/','+RECO/SSOA','+RECO/PSOA'

*.log_file_name_convert='+DATA/SSOA/','+DATA/PSOA/','+RECO/SSOA','+RECO/PSOA'

*.standby_file_management=auto

*.fal_server='SSOA'

*.fal_client='PSOA'

16. プライマリ・サイトのSOADBHOST1上のプライマリ・データベースに接続し(プライマリ・データベースはIDLE状態です)、プライマリDATAディスク・グループにSPFILEを作成します。例:

SQL> CREATE SPFILE='+DATA/PSOA/spfilepsoa.ora' FROM
PFILE='/u01/app/stage/psoa/initpsoa.ora';

17. プライマリ・サイトのSOADBHOST1およびSOADBHOST2上のORACLE_HOME/dbsディレクトリで、SPFILEへのポインタを含むPFILEを作成します。PFILEは、init<OracleSID>.oraというネーミング規則に従う必要があります。例:
SOADBHOST1の場合

$ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/PSOA/spfilepsoa.ora'" > initsoa1.ora

SOADBHOST2の場合

$ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/PSOA/spfilepsoa.ora'" > initsoa2.ora

18. パラメータを変更したら、プライマリ・データベースを再開します。

19. スタンバイ・ロールをサポートするために、プライマリ・データベースでスタンバイREDOログを作成します。例:

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
GROUP 5 SIZE 300M,
GROUP 6 SIZE 300M,
GROUP 7 SIZE 300M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2
GROUP 8 SIZE 300M,
GROUP 9 SIZE 300M,
GROUP 10 SIZE 300M;

20. V$ARCHIVED_LOGビューへの問合せを実行して、アーカイブされたREDOログ内の既存のファイルを特定し、Oracle Data Guardの構成を確認します。例:

SQL> select sequence#, first_time, next_time from v$archived_log order by sequence#;

21. プライマリ・データベースで、次のSQL文を発行してログ切替えを強制し、現在のオンラインREDOログ・ファイル・グループをアーカイブします。

SQL> alter system archive log current;

22. スタンバイ・データベースでV$ARCHIVED_LOGビューへの問合せを実行して、REDOデータがスタンバイ・データベースで受信およびアーカイブされていることを確認します。

SQL> select sequence#, first_time, next_time from v$archived_log order by sequence#;

4.1.3.1.6 データベースのスイッチオーバーおよびスイッチバックのテスト

新しく作成したフィジカル・スタンバイ・データベースとプライマリRACデータベース間でデータベースのスイッチオーバー操作およびスイッチバック操作が正しく機能することをテストする手順は、次のとおりです。

1. プライマリ・サイトでRACデータベースの1つのインスタンス(PSOA)以外をすべて停止します。たとえば、本番サイトのSOADBHOST1で次のコマンドを実行します。

$ srvctl stop instance -d psoa -i soa2

2. 現在のプライマリ・データベースでフィジカル・スタンバイへのロール移行を開始します。たとえば、本番サイトのSOADBHOST1で次のコマンドを実行します。

SQL > ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

3. プライマリ・インスタンスを停止し、プライマリ・インスタンスをマウントします。たとえば、本番サイトのSOADBHOST1で次のコマンドを実行します。

SQL > shutdown immediate
SQL > startup mount

4. これで、両方のデータベースがフィジカル・スタンバイ・モードになりました。両方のデータベースがフィジカル・スタンバイ・モードであることを確認するには、両方のデータベースで次のSQL問合せを実行します。

SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PHYSICAL_STANDBY

5. フィジカル・スタンバイ・データベース・ロールをプライマリ・ロールに切り替えます。たとえば、スタンバイ・サイトのSOADBHOST1で次のコマンドを実行します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

6. これで、フィジカル・スタンバイ・データベースが新しいプライマリになりました。

7. 新しいプライマリ・データベースを停止し、srvctlを使用して、両方のRACノードを起動します。たとえば、スタンバイ・サイトのSOADBHOST1で次のコマンドを実行します。

srvctl start database -d psoa

8. 新しいフィジカル・スタンバイ・データベース(元のプライマリ)で、データベースの管理リカバリを開始します。たとえば、プライマリ・サイトのSOADBHOST1で次のコマンドを実行します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

9. 新しいフィジカル・スタンバイ・データベースへのREDOデータの送信を開始します。たとえば、スタンバイ・サイトのSOADBHOST1で次のコマンドを実行します。

SQL> ALTER SYSTEM SWITCH LOGFILE;

10. V$ARCHIVED_LOGビューへの問合せを実行して、新しいフィジカル・スタンバイ・データベースでアーカイブ・ログ・ファイルが受信されているかどうかを確認します。

4.1.4 ノード・マネージャ

ノード・マネージャは、SSLを使用して管理サーバーと通信します。スタンバイ・サイトでこの通信が正しく機能するには、物理ホスト名を使用してSSL証明書を作成する必要があります。この項の項目は次のとおりです。

- 自己署名証明書の生成

- IDキーストアの作成

- 信頼キーストアの作成

- カスタム・キーストアを使用するためのノード・マネージャの構成

これらの項の例では、図4-2に示されているOracle SOA Suiteエンタープライズ・トポロジに対してこれらのタスクを実行する方法を紹介します。

注意:

図4-2に示されているOracle SOA Suiteエンタープライズ・トポロジを障害時リカバリ・トポロジの本番サイトとして設定する場合は、図4-2に示されているホスト名の代わりに、表3-1に示されている物理ホスト名を本番サイトに使用する必要があります。

この項の手順は、WebLogic Serverがインストールされているアプリケーション層ホストで実行する必要があります。

4.1.4.1 自己署名証明書の生成

次の手順に従って、自己署名証明書を生成します。

1. $WL_HOME/server/binディレクトリにあるsetWLSenvスクリプトを使用して、環境を設定します。

2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、$MW_HOME/user_projects/domains/SOADomainディレクトリ下にcertsディレクトリを作成します。

3. ユーザー定義ディレクトリからutils.CertGenツールを実行して、WebLogic Serverがインストールされているアプリケーション層ホストの証明書を作成します。構文は次のとおりです。

Syntax: java utils.CertGen <key_passphrase> <cert_file_name> <key_file_name> [export|domestic] [hostname]

たとえば、次のコマンドを入力します。

java utils.CertGen welcome1 soahost1_cert soahost1_key domestic soahost1
java utils.CertGen welcome1 soahost2_cert soahost2_key domestic soahost2

4.1.4.2 IDキーストアの作成

次の手順に従って、utils.ImportPrivateKeyユーティリティを使用してIDキーストアを作成します。

1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreというIDキーストアを新しく作成します。

2. このキーストアは、証明書と同じディレクトリに作成します。たとえば次のとおりです。

$MW_HOME/user_projects/domains/j2eeDomain/certs

3. utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートするときに、アイデンティティ・ストアが存在しなければ作成されます。

4. WebLogic Serverがインストールされているアプリケーション層ホストの証明書と秘密鍵をアイデンティティ・ストアにインポートします。必ず、インポートする証明書と鍵のペアごとに異なる別名を使用してください。構文は次のとおりです。

Syntax: java utils.ImportPrivateKey <keystore_file> <keystore_password>
<certificate_alias_to_use> <private_key_passphrase> <certificate_file>
<private_key_file> [<keystore_type>]

たとえば、次のコマンドを入力します。

java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 appIdentity1
welcome1 $MW_HOME/user_projects/domains/SOADomain/certs/soahost1_cert.pem
$MW_HOME/user_projects/domains/SOADomain/certs/soahost1_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 appIdentity2
welcome1 $MW_HOME/user_projects/domains/SOADomain/certs/soahost2_cert.pem
$MW_HOME/user_projects/domains/SOADomain/certs/soahost2_key.pem

4.1.4.3 信頼キーストアの作成

次の手順に従って、信頼キーストアを作成します。

1. keytoolユーティリティを使用して、appTrustKeyStoreという信頼キーストアを新しく作成します。

2. 新しい信頼キーストアを作成するには、必要なルートCA証明書のほとんどがすでに含まれている、標準Javaキーストアを使用します。標準Java信頼キーストアは、直接変更しないようにすることをお薦めします。

3. $WL_HOME/server/libディレクトリにある標準Javaキーストアcacertsを証明書と同じディレクトリにコピーします。例:

cp $WL_HOME/server/lib/cacerts
$MW_HOME/user_projects/domains/SOADomain/certs/appTrustKeyStore.jks

4. 標準Javaキーストアのデフォルト・パスワードはchangeitです。デフォルト・パスワードは、keytoolユーティリティを使用して、必ず変更するようにしてください。構文は次のとおりです。

keytool -storepasswd -new <NewPassword> -keystore <TrustKeyStore> -storepass
<Original Password>

たとえば、次のコマンドを入力します。

keytool -storepasswd -new welcome1 -keystore appTrustKeyStore.jks -storepass
changeit

5. CA証明書CertGenCA.derは、utils.CertGenツールによって生成されたすべての証明書への署名に使用され、$WL_HOME/server/libディレクトリにあります。keytoolユーティリティを使用して、このCA証明書をappTrustKeyStoreにインポートする必要があります。構文は次のとおりです。

keytool -import -v -noprompt -trustcacerts -alias <AliasName> -file
<CAFileLocation> -keystore <KeyStoreLocation> -storepass <KeyStore Password>

たとえば、次のコマンドを入力します。

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
$WL_HOME/server/lib/CertGenCA.der -keystore appTrust.jks -storepass welcome1

4.1.4.4 カスタム・キーストアを使用するためのノード・マネージャの構成

$WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後にある次の行を編集して、新しく作成したカスタム・キーストアを使用するように各ノードのノード・マネージャを構成します。これらの行とその意味は次のとおりです。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=<Identity KeyStore>
CustomIdentityKeyStorePassPhrase=<Identity KeyStore Password>
CustomIdentityAlias=<Identity Key Store Alias>
CustomIdentityPrivateKeyPassPhrase=<Private Key used when creating Certificate>
CustomTrustKeyStoreFileName=<Trust KeyStore>
CustomTrustKeyStorePassPhrase=<Trust KeyStore Password>

たとえば、SOAHOST1のnodemanager.propertiesファイルで次のように編集します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=$MW_HOME/user_projects/domains/SOADomain/certs
/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=welcome1
CustomIdentityAlias=appIdentity1
CustomIdentityPrivateKeyPassPhrase=welcome1
CustomTrustKeyStoreFileName=$MW_HOME/user_projects/domains/SOADomain/certs
/appTrust.jks
CustomTrustKeyStorePassPhrase=welcome1

たとえば、SOAHOST2のnodemanager.propertiesファイルで次のように編集します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=$MW_HOME/user_projects/domains/SOADomain/certs
/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=welcome1
CustomIdentityAlias=appIdentity2
CustomIdentityPrivateKeyPassPhrase=welcome1
CustomTrustKeyStoreFileName=$MW_HOME/user_projects/domains/SOADomain/certs
/appTrust.jks
CustomTrustKeyStorePassPhrase=welcome1

4.2 本番サイトの作成

この項では、本番サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。

本番サイトの作成を開始する前に、次の事前準備が完了していることを確認してください。

- 中間層ホストのホスト名別名を設定します。第3.1.1項「ホスト名の計画」を参照してください。

- 本番サイトの共有ストレージに必要なボリュームを作成します。第4.1.1項「ディレクトリ構造とボリューム設計」を参照してください。

- マウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。第3.2.3項「ストレージ・レプリケーション」を参照して、本番サイトにシンボリック・リンクを作成する必要があるかどうかを確認してください。

詳細は、次を参照してください。

- Oracle SOA Suiteトポロジの本番サイトの作成

- Oracle Identity Managementトポロジの本番サイトの作成

- Oracle WebCenter Portalトポロジの本番サイトの作成

- Oracle WebCenter Contentトポロジの本番サイトの作成

- Oracle Business Intelligenceトポロジの本番サイトの作成

- Oracle Portal、Forms、ReportsおよびDiscovererトポロジの本番サイトの作成

- 本番サイトの設定の検証

4.2.1 Oracle SOA Suiteトポロジの本番サイトの作成

本番サイトは、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

1. 第4.1.1.1.1項「Oracle SOA Suiteのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

3. 『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従って、Oracle SOA Suiteをインストールおよび構成します。ただし、次の点が異なります。

1. 共有ストレージ・デバイス上に作成したボリュームにOracle SOA Suiteコンポーネントをインストールします。

2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

3. JMSストアおよびトランザクション・ログ用に各サイトで別個のボリュームを作成します。

4. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーのホスト名検証の無効化に関する項を参照してください。

5. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

6. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.2 Oracle Identity Managementトポロジの本番サイトの作成

本番サイトは、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

1. 第4.1.1.3.1項「Oracle Identity Managementのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

3. 『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の説明に従って、Oracle Identity Managementをインストールおよび構成します。ただし、次の点が異なります。

1. 共有ストレージ・デバイス上に作成したボリュームにOracle Identity Managementコンポーネントをインストールします。

2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

3. JMSストアおよびトランザクション・ログ用に各サイトで別個のボリュームを作成します。

4. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーのホスト名検証の無効化に関する項を参照してください。

5. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

6. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.3 Oracle WebCenter Portalトポロジの本番サイトの作成

本番サイトは、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

1. 第4.1.1.2.1項「Oracle WebCenter Portalのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

3. Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle WebCenter Portalをインストールおよび構成しますが、次の点が異なります。

1. 共有ストレージ・デバイス上に作成したボリュームにOracle WebCenter Portalコンポーネントをインストールします。

2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

3. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドのOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーに対するホスト名検証の無効化に関する説明を参照してください。

4. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

5. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.4 Oracle WebCenter Contentトポロジの本番サイトの作成

本番サイトは、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

1. 第4.1.1.5.1項「Oracle WebCenter Contentのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

3. Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle Enterprise Content Managementをインストールおよび構成しますが、次の点が異なります。

1. 共有ストレージ・デバイス上に作成したボリュームにOracle Enterprise Content Managementコンポーネントをインストールします。

2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

3. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドの管理サーバーに対するホスト名検証の無効化に関する説明を参照してください。

4. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

5. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.5 Oracle Business Intelligenceトポロジの本番サイトの作成

本番サイトは、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

1. 第4.1.1.6.1項「Oracle Business Intelligenceのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

3. Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle Business Intelligenceをインストールおよび構成しますが、次の点が異なります。

1. 共有ストレージ・デバイス上に作成したボリュームにOracle Business Intelligenceコンポーネントをインストールします。

2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

3. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのbi_server1管理対象サーバーに対するホスト名検証の無効化に関する説明およびbi_server2管理対象サーバーに対するホスト名検証の無効化に関する説明を参照してください。

4. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

5. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.6 Oracle Portal、Forms、ReportsおよびDiscovererトポロジの本番サイトの構成

本番サイトは、次の製品のエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要があります。

- Oracle Portal
図4-9に示されているOracle Portalエンタープライズ・トポロジを使用する本番サイトを設定および構成する手順の詳細は、11.1.1.2 Oracle Portalエンタープライズ・デプロイメント・ガイドに記載されています。このマニュアルの入手方法は、My Oracle Support(以前のOracle MetaLink)にある記事ID 952068.1「Oracle Fusion Middleware 11g(11.1.1.2)Portal、Forms、ReportsおよびDiscoverエンタープライズ・デプロイメント・ガイド」を参照してください。My Oracle SupportのURLは次のとおりです。

http://support.oracle.com

- Oracle Forms、ReportsおよびDiscoverer
図4-10に示されているOracle Forms、ReportsおよびDiscovererエンタープライズ・トポロジを使用する本番サイトを設定および構成する手順の詳細は、11.1.1.2 Oracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメント・ガイドに記載されています。このマニュアルの入手方法は、My Oracle Support(以前のOracle MetaLink)にある記事ID 952068.1「Oracle Fusion Middleware 11g(11.1.1.2)Portal、Forms、ReportsおよびDiscoverエンタープライズ・デプロイメント・ガイド」を参照してください。My Oracle SupportのURLは次のとおりです。

http://support.oracle.com

前述のマニュアルの説明に従ってインストールおよび構成を行う必要がありますが、次のような違いがあります。示された手順に従ってください。

1. 第4.1.1.4.1項「Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

3. 前述のリンク先のホワイト・ペーパーの説明に従って、Oracle Portal、Forms、ReportsおよびDiscovererをインストールおよび構成します。ただし、次の点が異なります。

1. 共有ストレージ・デバイス上に作成したボリュームにOracle Portal、Forms、ReportsおよびDiscovererコンポーネントをインストールします。

2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

3. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドのOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーに対するホスト名検証の無効化に関する説明を参照してください。

4. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

5. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.7 本番サイトの設定の検証

Oracle SOA Suiteエンタープライズ・トポロジの本番サイトの設定を検証するには、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の次の項に記載されている検証手順を実行します。

- 「Oracle HTTP Serverのインストール」の次の項に記載されている検証手順

- ロード・バランサを使用したOracle HTTP Serverの検証に関する項

- 「ドメインの作成」の次の項に記載されている検証手順

- 管理サーバーの検証に関する項

- WLS_WSM1管理対象サーバーの起動と検証に関する項

- WLS_WSM2管理対象サーバーの起動と検証に関する項

- Oracle HTTP Serverを介したアクセスの検証に関する項

- Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証に関する項

- 「SOAコンポーネントを使用するためのドメインの拡張」の次の項に記載されている検証手順

- WLS_SOA1およびWLS_WSM1管理対象サーバーの検証に関する項

- WLS_SOA2管理対象サーバーの起動と検証に関する項

- Oracle HTTP Serverを介したアクセスの検証に関する項

- 「BAMを追加するためのドメインの拡張」の次の項に記載されている検証手順

- Oracle HTTP Serverを介したアクセスの検証に関する項

4.3 スタンバイ・サイトの作成

この項では、スタンバイ・サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。

次のトピックが含まれます:

- スタンバイ・サイトの作成

- スタンバイ・サイトの設定の検証

4.3.1 スタンバイ・サイトの作成

スタンバイ・サイトの作成を開始する前に、次の事前準備が完了していることを確認してください。

- スタンバイ・サイトで、第3.1.1項「ホスト名の計画」の手順に従って、ホスト名別名および物理ホスト名が正しく設定されていることを確認します。
スタンバイ・サイトの各ホストに、本番サイトのピア・ホストの物理ホスト名と同じホスト名別名が設定されていることを確認してください。

- スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。

- スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

4.3.1.1 データベースの設定

Oracle Data Guardは、プライマリ・サイトとスタンバイ・サイトのOracle Fusion Middlewareリポジトリ・データベース間に設定する必要があります。スタンバイ・サイトのデータベースは、フィジカル・スタンバイ・データベースとして設定する必要があります。プライマリ・サイトおよびスタンバイ・サイトでメタデータ・リポジトリを実行するデータベース間にOracle Data Guardを設定する手順は、第4.1.3.1項「Oracle Data Guardの設定」を参照してください。

また、スタンバイ・サイトでメタデータ・リポジトリを実行するデータベースが管理リカバリ・モードであることを確認してください。スタンバイ・データベースを管理リカバリ・モードにするには、次のSQLコマンドを実行します(disconnectオプションを指定すると、コマンドが正常に完了した後、SQLセッションが終了します)。

SQL> ALTER DATABASE RECOVERY MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

4.3.1.2 中間層の設定

スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareおよびWebLogic Serverソフトウェアのインストールや構成を行う必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。

スタンバイ・サイトの中間層ホストを設定する手順は、次のとおりです。

1. 本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、ストレージ・デバイス間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。

2. 本番サイトの共有ストレージをスタンバイ・サイトの共有ストレージと同期します。これによって、本番サイトからスタンバイ・サイトに初期のベースライン・スナップショットが転送されます。

3. スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。

4. ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。

4.3.2 スタンバイ・サイトの設定の検証

次の手順に従って、スタンバイ・サイトを検証します。

1. 本番サイトで実行中のプロセスを停止します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

2. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

3. Oracle Data Guardを使用して、データベースをフェイルオーバーします。

4. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

5. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。

4.4 非対称スタンバイ・サイトの作成

この項の手順では、Oracle Fusion Middleware障害時リカバリの非対称トポロジを設定する方法を説明します。

非対称トポロジは、本番サイトとスタンバイ・サイトの層で異なる障害時リカバリ構成です。Oracle Fusion Middleware障害時リカバリのほとんどの非対称トポロジでは、スタンバイ・サイトのリソースの数が本番サイトより少なくなっています。

この項を読む前に必ず、このマニュアルで前述した対称トポロジの設定に関する概念と情報に目を通し、理解しておいてください。対称トポロジの設定に関する概念の多くは、非対称トポロジを設定する際にも有効です。

第4.4.1項「非対称スタンバイ・サイトの作成」では、非対称トポロジを作成する際の基本的な手順を説明します。この章の前半で対称トポロジについてすでに説明した、非対称トポロジの設定に適用される概念については、詳しく説明しません。

4.4.1 非対称スタンバイ・サイトの作成

この項では、Oracle Fusion Middleware障害時リカバリのあらゆるタイプの非対称トポロジを作成する際の大まかな手順を説明します。本番サイトは、図4-2に示されているOracle SOA Suiteのエンタープライズ・デプロイメントです。スタンバイ・サイトは本番サイトと異なるものになります。

非対称トポロジを作成する手順は次のとおりです。

1. 本番サイトとスタンバイ・サイトを設計します。スタンバイ・サイトが本番ロールを引き継いだときに許容されるパフォーマンスを確保できるように、スタンバイ・サイトで必要となるリソースを特定してください。

注意:

スタンバイ・サイト・インスタンスのポートでは、本番サイトのピア・インスタンスと同じポート番号を使用する必要があります。そのため、スタンバイ・サイトで必要となるすべてのポート番号が使用可能である(スタンバイ・サイトで使用中でない)ことを確認してください。

2. 次の操作を実行して、Oracle Fusion Middleware障害時リカバリの本番サイトを作成します。

1. 本番サイトの共有ストレージ・システムで、本番サイト用にインストールするOracle Fusion Middlewareインスタンスのボリュームを作成します。詳細は、第4.1.1項「ディレクトリ構造とボリューム設計」を参照してください。

2. 本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。ボリューム設計の詳細は、第4.1.1.1.1項「Oracle SOA Suiteのボリューム設計」を参照してください。

3. 本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。Oracle中央インベントリ・ディレクトリの詳細は、第3.2.2項「OracleホームとOracleインベントリ」を参照してください。

4. 本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle HTTP Serverインスタンスに対して、静的HTMLページ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します(該当する場合)。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

5. 本番サイトの共有ストレージ・システムのボリュームに、本番サイト用のOracle Fusion Middlewareインスタンスをインストールします。詳細は、第4.2.1項「Oracle SOA Suiteトポロジの本番サイトの作成」を参照してください。

3. スタンバイ・サイトの共有ストレージ・システムでも、本番サイトの共有ストレージ・システムでOracle Fusion Middlewareインスタンスに対して作成したのと同じボリュームを、同じファイル権限とディレクトリ権限で作成します。この手順は重要です。これにより、後からストレージ・レプリケーションを使用してスタンバイ・サイト用にOracle Fusion Middlewareのピア・インスタンスのインストールを作成できるようになり、Oracle Universal Installerを使用したインストールが不要になるからです。

注意:

ストレージ・レプリケーションを構成する際には、本番サイトの共有ストレージ・システムで設定したすべてのボリュームがスタンバイ・サイトの共有ストレージ・システム上の同じボリュームにレプリケートされるようにしてください。

本番サイトの一部のインスタンスやホストがスタンバイ・サイトに存在しない場合でも、本番サイトのOracle Fusion Middlewareインスタンスに対して設定したすべてのボリュームでストレージ・レプリケーションを構成する必要があります。

4. 共有ストレージ・ベンダーが規定しているその他の必要な構成を実行して、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にします。本番サイトの共有ストレージ・システムのボリュームをスタンバイ・サイトの共有ストレージ・システムに非同期でコピーするように、ストレージ・レプリケーションを構成してください。

5. 本番サイトの共有ストレージ・システムの初期のベースライン・スナップショット・コピーを作成して、本番サイトとスタンバイ・サイトの共有ストレージ・システム間のレプリケーションを設定します。初期のベースライン・スナップショット・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリュームのすべてのディレクトリの内容が本番サイトのボリュームのディレクトリと同じであることを検証します。初期のスナップショットを作成する方法、および本番サイトとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にする方法の詳細は、共有ストレージ・ベンダーのドキュメントを参照してください。

6. ベースライン・スナップショットを作成したら、スタンバイ・サイトのホストでOracle Fusion Middlewareインスタンスについて次の手順を実行します。

1. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。

2. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。

3. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。

4. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。

5. スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。

6. スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。

前述の手順が完了すると、本番サイトのOracle Fusion Middlewareインスタンスのインストールがスタンバイ・サイトにレプリケートされます。スタンバイ・サイトは、次のすべての項目に該当する状態となります。

- Oracle Fusion Middlewareインスタンスは、本番サイトと同じボリューム上の同じOracleホーム・ディレクトリにインストールされています。また、ホストでは、Oracleホーム・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

- Oracle中央インベントリ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle中央インベントリ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

- Oracle HTTP Serverの静的HTMLページ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle HTTP Serverの静的HTMLページ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

- スタンバイ・サイトのOracle Fusion Middlewareインスタンスには、本番サイトの同じインスタンスに使用されているものと同じポートが使用されています。

4.4.1.1 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイトの作成

この項では、ホストおよびOracle Fusion Middlewareインスタンスの数が本番サイトより少ない非対称スタンバイ・サイトを作成する方法を説明します。

このOracle Fusion Middleware障害時リカバリ・トポロジの本番サイトは、図4-2に示されているOracle SOA Suiteのエンタープライズ・デプロイメントです。この本番サイトとその共有ストレージ・システムのボリュームを設定する方法、および必要なマウント・ポイントを作成する方法は、第4.1項「サイトの設定」から第4.1.1項「ディレクトリ構造とボリューム設計」に記載されています。

図4-15に、図4-2に示されている本番サイトの非対称スタンバイ・サイトを示します。

図4-15 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイト

「図4-15 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイト」の説明

図4-15に示されているOracle SOA Suiteの非対称スタンバイ・サイトのホストおよびインスタンスの数は、図4-2に示されているOracle SOA Suiteの本番サイトより少なくなっています。

図4-2の本番サイトには、ホストWEBHOST2およびSOAHOST2とこれらのホスト上のインスタンスが存在しますが、図4-15の非対称スタンバイ・サイトには、これらのホストとそのインスタンスが存在しません。そのため、スタンバイ・サイトのホストおよびインスタンスの数は、本番サイトより少なくなっています。

この非対称スタンバイ・サイトには、本番ロールを引き継いだときに適切なパフォーマンスを提供できるように、十分なリソースを確保することが重要です。

第4.4.1項「非対称スタンバイ・サイトの作成」に記載されている手順に従って、この非対称スタンバイ・サイトを設定すれば、スタンバイ・サイトは本番ロールを引き継ぐように適切に構成されます。

非対称スタンバイ・サイトを正しく設定するには、本番サイトの共有ストレージで作成したものと同じボリュームおよびコンシステンシー・グループをスタンバイ・サイトの共有ストレージで作成します。たとえば、Oracle SOA Suiteデプロイメントについて、表4-4のボリューム設計に関する推奨事項と表4-5のコンシステンシー・グループに関する推奨事項を使用して、本番サイトの共有ストレージを設定したとします。その場合、本番サイトの共有ストレージに使用したものと同じボリューム設計に関する推奨事項とコンシステンシー・グループに関する推奨事項を使用して、非対称スタンバイ・サイトの共有ストレージを設定します。

非対称スタンバイ・サイトでは、本番サイトに存在する一部のホストがスタンバイ・サイトに存在しません。たとえば、図4-15に示されているOracle SOA Suiteの非対称スタンバイ・サイトの場合、WEBHOST2とSOAHOST2がスタンバイ・サイトに存在しないため、スタンバイ・サイトの共有ストレージ・ボリュームに対してこれらのホスト上にマウント・ポイントを作成することはできず、作成する必要はありません。

4.4.2 非対称スタンバイ・サイトの設定の検証

次の手順に従って、スタンバイ・サイトを検証します。

1. 本番サイトで実行中のプロセスを停止します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

2. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

3. Oracle Data Guardを使用して、データベースをフェイルオーバーします。

4. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

5. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。

4.5 サイトの操作および管理の実行

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジで実行する操作および管理について説明します。

4.5.1 サイトの同期

スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。

本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行する必要があります。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。

Oracle Fusion Middleware障害時リカバリ・トポロジでのデータベースの同期は、Oracle Data Guardによって管理されます。

4.5.2 スイッチオーバーの実行

本番サイトを停止し(保守を行う場合など)、現在のスタンバイ・サイトを新しい本番サイトにする場合は、スタンバイ・サイトが本番ロールを引き継ぐように、スイッチオーバー操作を実行する必要があります。

スイッチオーバー操作を実行する手順は、次のとおりです。

1. 本番サイトで実行中のプロセスを停止します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

2. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

3. Oracle Data Guardを使用して、データベースをスイッチオーバーします。

4. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

5. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがスタンバイ・サイトにルーティングされるようにします。

6. ブラウザ・クライアントを使用してスイッチオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。
これで、元のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトが新しいスタンバイ・サイトになりました。

7. 2つのサイト間のレプリケーションを再確立します。ただし、スナップショット・コピーが逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。

前述の手順が完了すると、元のスタンバイ・サイトが新しい本番サイトになります。これで、元の本番サイトで保守を実行できるようになります。予定していた作業を元の本番サイトで実行した後、将来のいずれかの時点で、そのサイトを本番サイトまたはスタンバイ・サイトとして再度使用できます。

元の本番サイトを新しい本番サイトとして使用するには、第4.5.3項「スイッチバックの実行」に記載されているスイッチバック手順を実行してください。

4.5.3 スイッチバックの実行

スイッチオーバー操作を実行した後、スイッチバック操作を実行して、現在の本番サイトと現在のスタンバイ・サイトをスイッチオーバー操作前のロールに戻すことができます。

スイッチバック操作を実行する手順は、次のとおりです。

1. 現在の本番サイトで実行中のプロセスを停止します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

2. 現在の本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

3. Oracle Data Guardを使用して、データベースをスイッチバックします。

4. 新しい本番サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

5. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストが新しい本番サイトにルーティングされるようにします。

6. ブラウザ・クライアントを使用してスイッチバック後のテストを実行し、リクエストが解決されて新しい本番サイトにリダイレクトされていることを確認します。
これで、元のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトが新しいスタンバイ・サイトになりました。

7. 2つのサイト間のレプリケーションを再確立します。ただし、スナップショット・コピーが逆方向に(新しい本番サイトから新しいスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。

4.5.4 フェイルオーバーの実行

本番サイトが予期せず使用できなくなった場合、スタンバイ・サイトが本番ロールを引き継ぐように、フェイルオーバー操作を実行する必要があります。

フェイルオーバー操作を実行する手順は、次のとおりです。

1. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

2. スタンバイ・サイトから、Oracle Data Guardを使用して、データベースをフェイルオーバーします。

3. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

4. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがスタンバイ・サイトにルーティングされるようにします。

5. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されて本番サイトにリダイレクトされていることを確認します。
これで、スタンバイ・サイトが新しい本番サイトになりました。元の本番サイトが使用できなくなった原因を調べることができます。

6. 元の本番サイトを現在のスタンバイ・サイトとして使用するには、2つのサイト間のレプリケーションを再確立する必要があります。ただし、スナップショット・コピーが逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。

元の本番サイトを新しい本番サイトとして使用するには、第4.5.3項「スイッチバックの実行」に記載されているスイッチバック手順を実行してください。

4.5.5 スタンバイ・サイトの定期テストの実行

このマニュアルでは、Oracle Fusion Middlewareの本番サイトとスタンバイ・サイトの障害時リカバリを設定する方法を説明します。Oracle Fusion Middleware障害時リカバリの通常の構成は、次のようになっています。

- ストレージ・レプリケーションを使用して、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージにOracle Fusion Middlewareの中間層のファイル・システムおよびデータをコピーします。通常の操作時には、本番サイトはアクティブで、スタンバイ・サイトはパッシブです。本番サイトがアクティブな場合、スタンバイ・サイトはパッシブで、スタンバイ・サイトの共有ストレージは読取り専用モードです。スタンバイ・サイトの共有ストレージに対して行われる書込み操作は、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージへのストレージ・レプリケーション操作のみです。

- Oracle Data Guardを使用して、本番サイトのOracle Databaseのデータベース・データをスタンバイ・サイトのスタンバイ・データベースにコピーします。デフォルトでは、本番サイトのデータベースはアクティブで、スタンバイ・サイトのスタンバイ・データベースはパッシブです。スタンバイ・サイトがスタンバイ・ロールの間(パッシブである間)、スタンバイ・サイトのスタンバイ・データベースは管理リカバリ・モードです。本番サイトがアクティブな場合、スタンバイ・データベースに対して行われる書込み操作は、Oracle Data Guardによって実行されるデータベースの同期操作のみです。

- 本番サイトが使用できなくなったときには、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。現在の本番サイトが予期せず使用できなくなった場合は、フェイルオーバー操作(第4.5.4項「フェイルオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。また、現在の本番サイトを意図的に停止する場合は(予定した保守の場合など)、スイッチオーバー操作(第4.5.2項「スイッチオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。

通常の方法でスタンバイ・サイトをテストする場合は、現在の本番サイトを停止し、スイッチオーバー操作を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。ただし、企業では、現在の本番サイトを停止してスイッチオーバー操作を実行することなく、障害時リカバリのスタンバイ・サイトの定期テストを実行することもできます。

現在の本番サイトを停止せずにスタンバイ・サイトをテストする代替方法では、スタンバイ・サイトの読取り専用共有ストレージのクローンを作成し、クローニングされたスタンバイ・サイトの共有ストレージをテストで使用します。この代替テスト方法を使用する手順は、次のとおりです。

1. 共有ストレージ・ベンダーが提供しているクローニング・テクノロジを使用して、スタンバイ・サイトの共有ストレージでスタンバイ・サイトの読取り専用ボリュームのクローンを作成します。クローニングされたスタンバイ・サイトのボリュームが書込み可能であることを確認します。スタンバイ・サイトを1回だけテストする場合は、1回のみのクローン操作とすることができます。ただし、スタンバイ・サイトを定期的にテストする場合は、スタンバイ・サイトのクローニングされた読取り/書込みボリュームへのスタンバイ・サイトの読取り専用ボリュームの定期クローニングを設定できます。

2. スタンバイ・サイトのデータベースのバックアップを実行し、本番サイトとスタンバイ・サイトのデータベース間のOracle Data Guardレプリケーションを変更します。

- 10.1のデータベースについては、10.1 Oracle Data Guardのドキュメントに記載されている手順に従って、レプリケーションを中断します。

- 10.2以降のデータベースについては、次の手順に従って、スナップショット・スタンバイ・データベースを確立します。

1. フラッシュ・リカバリ領域がない場合は、設定します。

2. REDO Applyを取り消します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE CANCEL;

3. 保証付きリストア・ポイントを作成します。

SQL> CREATE RESTORE POINT standbytest
GUARANTEE FLASHBACK DATABASE;

4. プライマリ(本番)サイトで現在のログをアーカイブします。

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

5. アクティブ化するスタンバイ・サイト接続先を遅延させます。

SQL> ALTER SYSTEM SET
LOG_ARCHIVE_DEST_STATE_2=DEFER;

6. ターゲット・スタンバイ・データベースをアクティブ化します。

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

7. データベースが読取り専用で開いている場合、Forceオプションを指定してデータベースをマウントします。

SQL> STARTUP MOUNT FORCE;

8. 保護モードを下げて、データベースを開きます。

SQL> ALTER DATABASE SET STANDBY DATABASE TO
MAXIMIZE PERFORMANCE;
SQL> ALTER DATABASE OPEN;

- 11gのデータベースについては、『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースの管理に関する項に記載されている手順に従って、スナップショット・スタンバイ・データベースを確立します。

3. Oracle Data Guardのデータベース・リカバリ手順に従って、スタンバイ・データベースをオンラインにします。

4. スタンバイ・サイトのコンピュータで、次の手順に従って、スタンバイ・サイトのクローニングされた読取り/書込み共有ストレージ・ボリュームを指すようにmountコマンドを変更します。

1. 読取り専用の共有ストレージ・ボリュームをアンマウントします。

2. クローニングされた読取り/書込みボリュームを同じマウント・ポイントでマウントします。

5. スタンバイ・サイトのテストを実行する前に、ホスト名が本番サイトのコンピュータではなくスタンバイ・サイトのコンピュータを指すように、テストの実行に使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、スタンバイ・サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。

6. スタンバイ・サイトのテストを実行します。

スタンバイ・サイトのテストが完了したら、次の手順に従って、元の本番サイトを本番サイトとして再度使用します。

1. スタンバイ・サイトのコンピュータで、スタンバイ・サイトの読取り専用共有ストレージ・ボリュームを指すようにmountコマンドを変更します。つまり、mountコマンドを、テストを実行する前の状態に戻します。

1. クローニングされた共有ストレージの読取り/書込みボリュームをアンマウントします。

2. 読取り専用の共有ストレージ・ボリュームをマウントします。

これで、mountコマンドがスタンバイ・サイトのテストを実行する前の状態にリセットされました。

2. 本番サイトのデータベースとスタンバイ・サイトのスタンバイ・データベース間のレプリケーションを実行するように、Oracle Data Guardを構成します。この構成を実行すると、スタンバイ・データベースは再度、管理リカバリ・モードに設定されます。

- 10.1のデータベースについては、10.1 Oracle Data Guardのドキュメントに記載されている手順に従って、データベースを再インスタンス化します。

- 10.2以降のデータベースについては、次の手順に従います。

1. アクティブ化したデータベースをフィジカル・スタンバイ・データベースに戻します。

SQL> STARTUP MOUNT FORCE;
SQL> FLASHBACK DATABASE TO POINT standbytest;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> STARTUP MOUNT FORCE;

2. 管理リカバリを再開します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE USING CURRENT LOGFILE DISCONNECT;

3. スタンバイ接続先を再度有効にし、ログを切り替えます。

SQL> ALTER SYSTEM SET
LOG ARCHIVE DEST STATE 2=ENABLE;

- 11gのデータベースについては、『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースの管理に関する項に記載されている手順に従って、レプリケーションを再度設定します。

3. 元の本番サイトを再度使用する前に、ホスト名がスタンバイ・サイトのコンピュータではなく本番サイトのコンピュータを指すように、本番サイトへのアクセスに使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、本番サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。

4.5.6 テストでのpeer-to-peerファイル・コピーの使用

Oracle Fusion Middleware中間層コンポーネントの障害保護および障害時リカバリにストレージ・レプリケーション・テクノロジを使用する代わりに、テスト環境でpeer-to-peerファイル・コピー・メカニズムを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトのホストからスタンバイ・サイトのピア・ホストに中間層のファイル・システム・データをレプリケートできます。peer-to-peerファイル・コピー・メカニズムの例として、rsync(UNIXシステムのオープン・ソース・ユーティリティ)があります。

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジでストレージ・レプリケーションの代わりにrsyncを使用する方法を説明します。ここでは、対称トポロジのコンテキストにおけるrsyncについて説明します。対称トポロジの詳細は、第4.4項「非対称スタンバイ・サイトの作成」を参照してください。このセクションで説明されるrsyncの情報は、peer to peerファイル・コピー・メカニズムにも適用されます。

この項を読む前に、このマニュアルの他の部分にも目を通し、Oracle Fusion Middleware障害時リカバリ・トポロジでストレージ・レプリケーションとOracle Data Guardを使用する方法を理解しておいてください。Oracle Fusion Middlewareコンポーネントの障害保護および障害時リカバリでのストレージ・レプリケーションとrsyncの使用には、多くの類似点があります。

注意:

ストレージ・レプリケーション・テクノロジの代わりにrsyncを使用して、本番サイトからスタンバイ・サイトに中間層のファイル・システム・データをレプリケートできます。ただし、rsyncを使用した場合、次のようなストレージ・レプリケーションの便利な機能を使用することはできません。

- ストレージ・レプリケーションでは、本番サイトで前のスナップショットが作成された時点まで変更をロールバックできます。
rsyncでは、レプリケートされた本番サイトのデータによってスタンバイ・サイトのデータが上書きされるため、レプリケーションをロールバックすることはできません。

- ストレージ・レプリケーションでは、共有ストレージ・システムで各ホスト・クラスタについて設定したボリュームによって、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間でそのホスト・クラスタのデータの整合性が保証されます。
rsyncでは、データの整合性は保証されません。

ストレージ・レプリケーションと比較すると、このような短所があるため、実際の本番環境では、障害時リカバリにrsyncを使用することはできません。

4.5.6.1 Oracle Fusion Middleware障害時リカバリ・トポロジでのrsyncとOracle Data Guardの使用

rsyncとOracle Data Guardを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの障害保護および障害時リカバリを実現するときには、次の2つの基本原則が適用されます。

1. Oracle Fusion Middleware中間層コンポーネントの障害保護には、rsyncを使用します。

2. Oracle Fusion Middlewareトポロジで使用されるOracle Databaseの障害保護には、Oracle Data Guardを使用します。Oracle Databaseの障害時リカバリを実現するようにOracle Data Guardを設定する方法の詳細は、第3.3項「データベースに関する考慮事項」を参照してください。

4.5.6.1.1 Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用

rsyncを使用してOracle Fusion Middleware中間層コンポーネントの障害保護および障害時リカバリを実現する手順は、次のとおりです。

1. 本番サイトのホストからスタンバイ・サイトのピア・ホストへのファイルのレプリケーションが有効になるように、rsyncを設定します。rsyncをインストールおよび設定する手順、および構文と使用方法の詳細は、rsyncのマニュアル・ページを参照してください。rsyncに関する情報は、http://rsync.samba.orgで入手できます。

2. 1つ以上のOracle Fusion Middlewareコンポーネントがインストールされている本番サイトの各ホストについて、次のディレクトリおよびファイルを、スタンバイ・サイトのピア・ホスト上の同じディレクトリおよびファイルにコピーするように、rsyncを設定します。

- Oracle Fusion Middlewareのホーム・ディレクトリおよびサブディレクトリと、それらのディレクトリ内のすべてのファイル

- ホストのOracle中央インベントリ・ディレクトリおよびファイル(Oracle Fusion Middlewareインストール用のOracle Universal Installerエントリを含む)

- ホスト上のOracle HTTP Serverインストール用のOracle Fusion Middlewareの静的HTMLページ・ディレクトリ(該当する場合)

- Oracle Formsによってホスト上に作成された.fmbおよび.fmxデプロイメント・アーティファクト・ファイルと、Oracle Reportsによってホスト上に作成された.rdfデプロイメント・アーティファクト・ファイル(該当する場合)

注意:

rsyncをルートとして実行してください。ユーザーにパスワードの入力を求めるプロンプトを表示せずにrsyncが機能するようにするには、SSHによってパスワードの入力を求めるプロンプトが表示されないように、本番サイトのホストとスタンバイ・サイトのホスト間にSSHキーを設定します。

3. 前の手順でrsyncを設定した本番サイトのホストについて、cronジョブなどのスケジュール済ジョブを設定します。これらのスケジュール済ジョブを使用すると、rsyncによって、本番サイトのホストからスタンバイ・サイトのホストへのこれらのファイルのレプリケーションを定期的に自動実行できます。Oracle Fusion Middlewareの構成がそれほど頻繁に変更されない本番サイトについては、1日1回の間隔をお薦めします。

4. 本番サイトのホストでOracle Fusion Middlewareの中間層の構成が変更された場合(新しいアプリケーションがデプロイされた場合など)は必ず、rsyncを使用して、スタンバイ・サイトのピア・ホストとそのホストの手動同期を実行する必要があります。

5. 本番サイトのホスト上にあるOracle Fusion Middlewareの中間層インスタンスを、rsyncを使用して手動でスタンバイ・サイトのピア・ホストと同期させた場合は、関連する本番サイトのOracle Fusion Middlewareインスタンスのデータベース・リポジトリも、Oracle Data Guardを使用して手動で強制的にスタンバイ・サイトと同期させる必要があります。Oracle Data Guardを使用してOracle Databaseを手動で強制的に同期させる方法の詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動強制」を参照してください。

4.5.6.1.2 フェイルオーバー操作およびスイッチオーバー操作の実行

rsyncを使用している場合、本番サイトからスタンバイ・サイトへのフェイルオーバーまたはスイッチオーバーを実行する手順は次のとおりです。

1. 本番サイトで実行中のプロセスを停止します(該当する場合)。

2. 本番サイトのホストとスタンバイ・サイトのピア・ホスト間のrsyncジョブを停止します。

3. Oracle Data Guardを使用して、本番サイトのデータベースをスタンバイ・サイトにフェイルオーバーします。

4. スタンバイ・サイトで、Oracle Fusion Middlewareサーバー・インスタンスのプロセスを手動で開始します。

5. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストをスタンバイ・サイトにルーティングします。

6. ブラウザ・クライアントを使用してフェイルオーバー後またはスイッチオーバー後のテストを実行し、スタンバイ・サイト(現在の本番サイト)でリクエストが解決されていることを確認します。
これで、スタンバイ・サイトが新しい本番サイトになり、本番サイトが新しいスタンバイ・サイトになりました。

7. 2つのサイト間のrsyncレプリケーションを再確立します。ただし、逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)レプリケートされるようにレプリケーションを構成してください。

元の本番サイトを新しい本番サイトとして使用するには、前述の手順をもう一度実行します。ただし、元の方向で(元の本番サイトから元のスタンバイ・サイトへ)レプリケートされるようにrsyncレプリケーションを構成してください。

4.6 Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用

この項では、11g Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードする方法を説明します。

この項の一覧では、Oracle Fusion Middleware障害時リカバリの本番サイトでパッチ・セットを適用して、11g Oracle Fusion Middlewareホームをアップグレードする手順について説明します。

次の手順は、パッチを適用するOracle Fusion MiddlewareインスタンスのOracle中央インベントリが本番サイトの共有ストレージに配置されていて、パッチが適用されたインスタンスのOracle中央インベントリをスタンバイ・サイトにレプリケートできるようになっていることを前提としています。

11g Oracle Fusion Middlewareのパッチ・バージョンをアップグレードする手順は、次のとおりです。

1. 開始時の状態が保持されるように、本番サイトのバックアップを実行します。

2. パッチ・セットを適用して、本番サイトのインスタンスをアップグレードします。

3. パッチ・セットを適用したら、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージを手動で強制的に同期させます。これによって、本番サイトのパッチが適用されたインスタンスとOracle中央インベントリがスタンバイ・サイトの共有ストレージにレプリケートされます。

4. パッチ・セットを適用したら、Oracle Data Guardを使用して、本番サイトとスタンバイ・サイトのOracle Databaseを手動で強制的に同期させます。Oracle Fusion Middlewareの一部のパッチ・セットでは、リポジトリが更新される場合があります。そのため、この手順を必ず実行して、本番サイトのデータベースの変更をスタンバイ・サイトのデータベースに同期させます。

5. これでアップグレードは完了です。障害時リカバリ・トポロジで処理を再開できます。

注意:

パッチは、11g Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトでのみ適用する必要があります。Oracle Fusion MiddlewareインスタンスまたはOracle中央インベントリのパッチの場合、本番サイトの共有ストレージがスタンバイ・サイトの共有ストレージにレプリケートされるときに、パッチがコピーされます。本番サイトでパッチをインストールした場合は、同期操作を実行する必要があります。

同様に、本番サイトのデータベースのパッチをインストールした場合、同期を実行すると、Oracle Data Guardによってスタンバイ・サイトのスタンバイ・データベースにパッチがコピーされます。

5 Oracle Site Guardの使用方法

この章では、既存のOracle Fusion Middleware障害時リカバリ・ソリューションにOracle Site Guardを設定して、本番サイトおよびスタンバイ・サイトでスイッチオーバーおよびフェイルオーバーなどの操作を自動化する方法について説明します。

内容は次のとおりです。

- 開始前の重要な注意点

- Oracle Site Guardの概要

- Oracle Site Guardのインストール

- 前提条件

- Oracle Site Guardの設定

- 操作計画の使用

- エラー管理フレームワーク

- Site Guard構成の管理

- サンプル・シナリオ: Oracle BI Enterprise Edition

5.1開始前の重要な注意点

Oracle Site Guard for Oracle Fusion Middlewareコンポーネントの構成を始める前に、次の注意点を参照してください。

- 障害時リカバリおよびこの章で使用されるOracle Site Guard用語を理解するには、第1.1.2項「用語」を参照してください。

- Oracle Fusion Middleware用のOracle Site Guardを構成する前に、第2項「Fusion Middlewareコンポーネントに関する推奨事項」を参照してください。

- 第3.1.1項「ホスト名の計画」の説明に従って、ホスト名が構成されているか確認してください。

- 第3.1.2項「仮想IPおよび仮想ホスト名に関する考慮事項」の説明に従って、仮想IPアドレスおよび仮想ホスト名が構成されているか確認してください。

- 第3.2項「記憶域に関する考慮事項」を参照してください。

- 第3.3項「データベースに関する考慮事項」を参照してください。

- 第3.3項「データベースに関する考慮事項」の説明に従って、Oracle Data Guardを構成して、Oracle Databaseの障害時リカバリが提供されているか確認してください。

注意:

Oracle Data Guard Brokerに関する項の説明に従って、Oracle Data GuardのOracle Data Guard Brokerを構成する必要があります。

- 第4章「障害時リカバリ・サイトの設定と管理」の説明に従って、既存のOracle Fusion Middleware障害時リカバリ・セットアップが設定されているか確認してください。

5.2 Oracle Site Guardの概要

Oracle Site Guardは、主に、2つの障害回復サイト間のスイッチオーバーおよびフェイルオーバーを編成します。この章で説明されているとおりに、これらのサイトを作成する必要があります。Oracle Site Guardには次の機能があります。

- 企業データの高可用性、データ保護および障害時リカバリを保証します。

- スイッチオーバーやフェイルオーバーなどの障害回復操作を自動化します。計画停止または計画外停止によりプライマリ・サイトが使用できなくなった場合、Site Guardはスタンバイ・サイトを本番ロールに自動的に切り替えることができ、このため、停止に関連付けられた停止時間を最小限にします。

この項には次のトピックが含まれます:

- Oracle Site Guardのメリット

- Oracle Site Guardの操作

- Enterprise Manager Cloud Controlにおけるサイトの説明

5.2.1 Oracle Site Guardのメリット

Enterprise Manager Cloud Control12c リリース1(12.1.0.2)の機能として利用できるOracle Site Guardは、Oracle Fusion Middlewareコンポーネントを使用して構成できます。これには、次の利点があります。

準備済レスポンスが原因で発生するエラーの削減

Oracle Site Guardは、障害時にヒューマン・エラーが起きる可能性を削減させるのに役立ちます。障害回復計画が作成およびテストされ、アプリケーション内の準備済レスポンスで練習が行われます。障害時リカバリのOracle Site Guard操作が始まると、ユーザは介入する必要がありません。

記憶域の統合

Oracle Site Guardでは、簡単なメカニズムを使用して、任意のストレージ・アプライアンスと統合します。操作ワークフロー内で、任意のユーザ定義のストレージ・ロール・リバーサル・スクリプトに対するコールアウトを使用して、スイッチオーバーまたはフェイルオーバーを実行するストレージ・アプライアンスと統合します。

ターゲット依存性

サイトを起動または停止している間、Oracle Site Guardは自動的に、ターゲット間の依存性を処理します。

エンドツーエンド障害時リカバリの自動化

Oracle Site Guardは、ストレージ・アプライアンスと緩やかに統合することで、障害時リカバリ操作をエンドツーエンドで編成し、ストレージ・ロール・リバーサルを実行します。また、同時にOracle Data Guard Brokerと統合して、データベース・ロール・リバーサルを実行します。次にOracle Site Guardは、スイッチオーバーまたはフェイルオーバーを実行する前に、プライマリ・サイトを停止し、障害時リカバリが完了した後でスタンバイ・サイトを実行します。

Site Guardは、構成が完了すると、フェイルオーバーまたはスイッチオーバーなどの操作中にアプリケーション内のすべてのコンポーネントを管理し、これらの操作が完了しているか確認します。

5.2.2 Oracle Site Guardの操作

Oracle Site Guardは、Oracle Fusion Middleware 11gで高可用性、データ保護、および障害時リカバリを保証しています。また、次の障害時リカバリ操作を自動化します。

- サイトの停止

- サイトの起動

- サイトのスイッチオーバー

- サイトのフェイルオーバー

5.2.3 Enterprise Manager Cloud Controlにおけるサイトの説明

サイトは、データセンター内の関連するターゲットのコレクションで、Oracle Site Guardは、これを対象にスイッチオーバーやフェイルオーバーなどの障害時リカバリ操作を実行します。アプリケーションのグループを同時に実行する必要があります。たとえば、サイトは、Oracle Fusion Middlewareインスタンス、データベースおよびストレージ・デバイスで構成されます。Oracle Site Guardは、Enterprise Manager Cloud Control汎用システム・ターゲットを使用してサイトを表現します。いずれのサイトも、それがプライマリであるかスタンバイであるかにかかわらず、Oracle DatabaseおよびOracle Fusion Middlewareドメインなどの他のターゲット・タイプのコレクションである汎用システムとして表現されます。Oracle Site Guardは、単一のEnterprise Manager Cloud Controlによって、プライマリ・サイトとスタンバイ・サイトの両方が管理されるEnterprise Managerデプロイメントをサポートしています。

図5-1に、単一のEnterprise Manager Cloud Controlインスタンスによって管理されるOracle Fusion Middleware障害時リカバリ・トポロジの概要を示します。

図5-1 Enterprise Manager Cloud Controlが管理するOracle Fusion Middleware障害時リカバリ・トポロジにおける本番サイトとスタンバイ・サイト

「図5-1 Enterprise Manager Cloud Controlが管理するOracle Fusion Middleware障害時リカバリ・トポロジにおける本番サイトとスタンバイ・サイト」の説明

図5-1に示したトポロジの重要な側面をいくつか、次に示します。

- 単一のEnterprise Manager Cloud Controlインスタンスが、本番サイトおよびスタンバイ・サイトを監視します。

- Oracle Management Agent (EM Agent)は、本番サイトおよびスタンバイ・サイトのすべてのホストにインストールされます。例:

- OPMN管理システム・コンポーネント(WEBHOST1およびWEBHOST2)

- Oracle Fusion Middlewareアプリケーション(APPHOST1およびAPPHOST2)

- Oracle RACデータベース(DBHOST1およびDBHOST2)

Oracle Management Agent (EMエージェント)は、Enterprise Manager Cloud Controlのコア・コンポーネントの1つで、Enterprise Managerシステムで管理対象外ホストを管理対象ホストに変換できます。管理エージェントはプラグインと連携することにより、管理対象ホスト上で実行されているターゲットを管理します。

- 本番サイトに障害または計画外の停止が発生した場合には、Oracle Site Guardは次の手順を自動化して、トポロジ内でスタンバイ・サイトが本番のロールを引き継げるようにします。

1. 本番サイトからスタンバイ・サイトへのレプリケーションを停止します(障害発生時には、その障害によりレプリケーションがすでに停止している可能性があります)。

2. Oracle Data Guardを使用して、Oracle Databaseのフェイルオーバーまたはスイッチオーバーを実行します。

3. スタンバイ・サイトに記憶域をマウントします。

4. スタンバイ・サイトでサービスとアプリケーションを起動します。

5.3 Oracle Site Guardのインストール

Oracle Site Guardは、Enterprise Manager Cloud Control12c リリース1(12.1.0.2)ソフトウェアに付属しています。Enterprise Managerコマンドライン・インタフェース(EM CLI)を使用して、Site Guard構成を管理できます。次の手順を実行する必要があります。

注意:

Oracle Site Guardライセンスの詳細は、『Oracle Fusion Middlewareライセンス情報』を参照してください。

- Oracle Fusion Middleware Enterpriseをデプロイするには、Enterprise Manager Cloud Control 12c リリース1(12.1.0.2)をインストールします。Enterprise Manager Cloud Control 12 c リリース1(12.1.0.2)のインストールの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の「Oracle Management Agentのインストール」の章の説明に従って、Enterprise Managerが管理する各ホストにOracle Management Agent (EM Agent)がインストールされていることを確認してください。

- Oracle Management Agentのインストール後、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の「インストール後の作業」の項の説明に従って、Enterprise Manager CloudホストおよびEnterprise Managerが管理するすべてのホストからroot.shスクリプトを実行してください。

- 『Oracle Enterprise Managerコマンドライン・インタフェース』の「コマンドライン・インタフェースの概要およびインストール」の章の説明に従って、Enterprise Managerコマンドライン・インタフェース(EM CLI)をインストールします。

注意:

Oracleでは、Oracle Management Serviceがインストールされている場所と同じMiddlewareホームにEM CLIをインストールすることをお薦めします。例: <OMS_HOME>/bin/emctl。

5.4 前提条件

Oracle Site GuardのOracle Fusion Middleware 11g製品を構成する際の前提条件は次のとおりです。

- プライマリ・サイトおよびスタンバイ・サイトでのターゲットの検出

- 本番システムとスタンバイ・システムの作成

- Oracle Site Guardの資格証明の作成

- ソフトウェア・ライブラリの構成

- カスタム・スクリプトの作成

- ストレージ・スクリプトの作成

5.4.1 プライマリ・サイトおよびスタンバイ・サイトでのターゲットの検出

プライマリ・サイトでのターゲットの検出の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ターゲットの追加」を参照してください。

Oracle Site Guardでは、検出する必要のある次のターゲット・タイプをサポートしています。

- Oracle Fusion Middlewareファーム

- Oracle HTTP ServerおよびOracle Fusion MiddlewareファームのOracle Internet Directory部分などのOracle Fusion Middleware管理システム・コンポーネント

- Real Application Cluster (RAC)データベース

- 単一インスタンス・データベース

スタンバイ・サイトが本番ロールを引き継ぐことができるように、スタンバイ・サイトでターゲットを検出する前に、第4.5.2項「スイッチオーバーの実行」の説明に従って、手動でスイッチオーバーを実行する必要があります。

スイッチオーバーの実行後、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ターゲットの追加」に説明されている手順を完了して、スタンバイ・サイトのターゲットを検出することができます。

注意:

プライマリ・サイトが本番ロールを引き継ぐことができるように、スタンバイ・サイトでターゲットを検出した後、第4.5.2項「スイッチオーバーの実行」の説明に従って、手動でスイッチオーバーを実行する必要があります。

5.4.2 本番システムとスタンバイ・システムの作成

プライマリ・サイトおよびスタンバイ・サイトの汎用システムを作成する必要があります。各汎用システムには、表現しているサイトに関連するすべてのターゲット(Oracle Fusion MiddlewareFarmおよびDatabase)が含まれている必要があります。

次のいずれかのオプションを使用してシステムを作成できます。

- Enterprise Manager Cloud Controlコンソールを使用した汎用システムの作成

- EMCLIコマンドを使用した汎用システムの作成

5.4.2.1 Enterprise Manager Cloud Controlコンソールを使用した汎用システムの作成

プライマリ汎用システムを作成するには、次の手順を実行します。

1. Enterprise ManagerにEM_CLOUD_ADMINISTRATORユーザーでログインします。

2. 「ターゲット」、「システム」の順に選択します。
システム・ページが表示されます。

3. ドロップダウン・メニューから「汎用システム」を選択して、「追加」をクリックします。

4. 「一般」セクションで、プライマリ・システムの名前を入力します。

5. 「メンバー」セクションで、「追加」をクリックします。

6. ターゲットを選択し、「選択」をクリックします。次を関連付ける必要があります。

- 次を含むOracle Fusion Middlewareファーム

- 管理サーバー

- 管理対象サーバー

- OPMN管理対象システム・コンポーネント

- Oracle RACデータベース・インスタンスを使用している場合は、次に、インスタンスをクラスタ・データベース・ターゲットと関連付ける必要があります。単一のデータベース・インスタンスの場合、そのインスタンスをデータベース・インスタンス・ターゲットに関連付ける必要があります。

注意:

次のターゲット・タイプはサポートされていません。

- データベース・システム

- 各RACインスタンス

7. ドロップダウン・メニューからタイムゾーンを選択します。

8. 「次へ」をクリックします。
「アソシエーションの定義」ページが表示されます。

9. 「次へ」をクリックします。
「可用性の基準」ページが表示されます。

10. 「可用性の基準」から、「任意のキー・メンバー」メンバー・オプションを選択します。

11. 「メンバー」パネルで「AdminServer」を選択し、ダブルクリックします。
「AdminServer」が「メンバー」パネルから削除され、「キー・メンバー」パネルに追加されます。

12. 「次へ」をクリックします。
「グラフ」ページが表示されます。

13. 「次へ」をクリックします。
「確認」ページが表示されます。

14. 設定を確認して「終了」をクリックします。

15. この手順を使用して、スタンバイ・サイトの汎用システムを作成します。

5.4.2.2 EMCLIコマンドを使用した汎用システムの作成

コマンドラインで次のemcliコマンド(<OMS_HOME>/bin/emctlにあります)を実行して、汎用システムを作成することができます。

注意:

新しいEMCLIクライアントの設定の詳細は、Cloud Controlコンソール内の「Enterprise Managerコマンドライン・インタフェースのダウンロード」ページを参照してください。このページにアクセスするには、Cloud Controlの「設定」メニューから「プリファレンス」を選択して、「コマンドライン・インタフェース」をクリックします。

emcli create_system
-name="name"
-type=<system>
-add_members="name1:type1;name2:type2;..."]...
-timezone_region="actual timezone region"

注意:

ターゲットのステータスおよびアラート情報を取得するには、get_targetsコマンドを実行します。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』の「Verbリファレンス」の章を参照してください。

パラメータ

説明

-name

システムの名前を入力します。

-type

タイプとしてgeneric_systemを入力します。

-add_members

既存のターゲットをシステムに追加します。各ターゲットは、名前と値のペアtarget_name:target_typeで指定します。このオプションは、複数回指定できます。

-timezone_region

タイムゾーン・リージョンを指定します。

『Oracle Enterprise Managerコマンドライン・インタフェース』の「create_system」を参照してください。

注意:

この手順を使用して、スタンバイ・サイトの汎用システムを作成します。

5.4.3 Oracle Site Guardの資格証明の作成

Enterprise Manager Cloud Controlコンソールを使用して、Oracle Site Guardに関連付けられた次のターゲットに、名前付き資格証明を作成する必要があります。

- ホスト(通常ユーザーの場合)

- ホスト(ルート権限を持つユーザー)

- Oracle WebLogic Server

- Oracle Database

注意:

- ここで作成される資格証明は、後にSite Guard構成に関連付けられます。Site Guardは、同じターゲット・タイプのすべてのターゲットに対して同じ資格証明を指定することができます。たとえば、システム内のすべてのデータベースでは、同じsysdba資格証明を使用できます。また、Site Guardでは、同じ種類のターゲットで異なる資格証明を使用することもできます。

- 資格証明がノード間(プライマリ・サイトおよびスタンバイ・サイト)で同じである場合、スタンバイ・サイトで実行しているターゲットの資格証明を作成する必要はありません。

Enterprise Manager Cloud Controlコンソールを使用して資格証明を作成するには、次の手順を実行します。

1. Enterprise ManagerにEM_CLOUD_ADMINISTRATORユーザーでログインします。

2. 「設定」→「セキュリティ」→「名前付き資格証明」をクリックします。
「名前付き資格証明」ページが表示されます。

3. 「作成」をクリックします。
「資格証明の作成」ページが表示されます。

4. 「一般プロパティ」セクションで、次のように指定します。

- 資格証明名: 資格証明の名前を指定します。

- 認証ターゲット・タイプ: ホストには「ホスト」、Oracle WebLogic Serverには「Oracle WebLogic Server」、およびOracle Databaseには「データベース・インスタンス」をドロップダウン・メニューから選択します。

- 資格証明タイプ: ドロップダウン・メニューから資格証明を選択します。

- ホスト: ホスト資格証明

- ホスト(ルート権限を持つユーザー): ホスト資格証明

- Oracle WebLogic Server: Oracle WebLogic資格証明
Oracle WebLogic Server管理者ユーザー資格証明を指定します。

- Oracle Database: データベース資格証明
Oracle Database SYSユーザー資格証明を指定します。

- ターゲット・タイプ: ドロップダウン・メニューからターゲットを選択します。

- ホスト: ホスト

- ホスト(ルート権限を持つユーザー): ホスト

- Oracle WebLogic Server: Oracle WebLogic Server

- Oracle Database: データベース・インスタンス

5. 「資格証明プロパティ」セクションで、次のように指定します。

- ユーザー名: ユーザー名を入力します。

- パスワード: パスワードを入力します。

- パスワードの確認: パスワードを確認します。

- 実行権限: ドロップダウン・メニューから特権資格証明を設定します。

- ホスト: なし

- ホスト(ルート権限を持つユーザー): 「Sudo」を選択して、「別名実行」フィールドに値を入力します。

- Oracle Database: SYSDBA

6. 「テストと保存」をクリックします。資格証明をテストするホスト名を入力します。

5.4.4 ソフトウェア・ライブラリの構成

Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)は、Oracle Site Guardが操作計画の実行に必要とするスクリプトを格納するリポジトリです。ソフトウェア・ライブラリの記憶域の場所を構成するには、次の手順を実行します。

1. Enterprise ManagerにEM_CLOUD_ADMINISTRATORユーザーでログインします。

2. 「設定」→「プロビジョニングとパッチ適用」→「ソフトウェア・ライブラリ」をクリックします。
「ソフトウェア・ライブラリ: 管理」ページが表示されます。

3. 「記憶域のタイプ」ドロップダウン・ボックスから「OMS共有ファイルシステム」を選択します。

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

5. すべてのOMSからアクセスできる「名前」および「場所」を指定し、「OK」をクリックします。

注意:

ソフトウェア・ライブラリの記憶域の場所は、すべてのOMSからローカル・ディレクトリのようにアクセスできる必要があるため、複数OMSのシナリオでは、OCFS2またはNFSを使用したクラスタ・ファイルシステムを設定する必要があります。単一のOMSシステムでは、任意のローカル・ディレクトリでかまいません。

ジョブが実行され、すべての即時利用可能なコンテンツがアップロードされます。ディスクのスピードにより、15分から30分かかります。

注意:

詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ソフトウェア・ライブラリの構成」を参照してください。

5.4.5 カスタム・スクリプトの作成

障害時リカバリ操作(停止、起動、スイッチオーバーまたはフェイルオーバー)のワークフローで、サイト・レベルで実行するカスタム・スクリプトを作成できます。次のスクリプトを作成できます。

- 前処理スクリプト

- 後処理スクリプト

必要なスクリプトを作成し、それらを、スクリプトを実行する各ホスト上の宛先フォルダに保存します。スクリプトを作成したら、「前処理スクリプトおよび後処理スクリプトの関連付け」の項の説明に従って、カスタム・スクリプトをOracle Site Guardに関連付ける必要があります。

注意:

- カスタム・スクリプトでは、リターン・コードを明確に定義する必要があります。スクリプトは、成功した場合は0を戻し、失敗した場合は、ゼロ以外の値を戻す必要があります。

- スクリプトの実行に必要な権限を持っていることを確認してください。

5.4.6ストレージ・スクリプトの作成

次のストレージ・スクリプトを作成する必要があります。

- マウント・スクリプト

- アンマウント・スクリプト

- スイッチオーバー・スクリプト

- フェイルオーバー・スクリプト

必要なスクリプトを作成し、それらを、スクリプトを実行する各ホスト上の宛先フォルダに保存します。「ストレージ・スクリプトの関連付け」の項の説明に従って、ストレージ・スクリプトをOracle Site Guardに関連付ける必要があります。

注意:

スクリプトの実行後、実行リターン・コード値が0であることを確認します。リターン・コードがゼロ以外の場合、スクリプトは失敗です。適切なリターン・コードでスクリプトを実装しているか確認します。

5.5 Oracle Site Guardの設定

このセクションでは、プライマリ・サイトおよびスタンバイ・サイトでOracle Fusion Middleware障害操作を管理するための、Enterprise Manager Cloud ControlでのOracle Site Guardのセットアップおよび構成について説明します。次の手順を実行する必要があります。

- Oracle Site Guard構成の作成

- サイトの資格証明の関連付け

- 前処理スクリプトおよび後処理スクリプトの関連付け

- ストレージ・スクリプトの関連付け

5.5.1 Oracle Site Guard構成の作成

Oracle Site Guardは、(第5.4.2項「本番システムとスタンバイ・システムの作成」で作成される)プライマリ・サイトおよびスタンバイ・サイトを関連付け、スイッチオーバーおよびフェイルオーバーのような障害時リカバリ操作を自動化します。Oracle Site Guardを実行する前に、プライマリ・サイトとスタンバイ・サイトを構成し、それをOracle Site Guardに関連付ける必要があります。プライマリ・サイトおよびスタンバイ・サイトの構成を追加するには、コマンドラインで次のemcliコマンドを実行する必要があります。

注意:

emcliへのログインの詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』の「コマンドライン・インタフェースの概要およびインストール」の章を参照してください。

emcli create_siteguard_configuration
-primary_system_name="system_name"
-standby_system_name="system_name"

パラメータ

説明

-primary_system_name

プライマリ・サイトに関連付けられるシステムの名前を入力します。

-standby_system_name

スタンバイ・サイトに関連付けられるシステムの名前を入力します。

Site Guardの構成例については、付録B「Oracle Site Guardのサンプル・スクリプト」を参照してください。

既存のプライマリ・サイトおよびスタンバイ・サイトの間の関連付けを表示するには、コマンドラインで次のemcliコマンドを実行する必要があります。

emcli get_siteguard_configuration
-primary_system_name="system_name"
-standby_system_name="system_name"

5.5.2 サイトの資格証明の関連付け

第5.4.3項「Oracle Site Guardの資格証明の作成」で作成された資格証明をサイトのターゲットに関連付ける必要があります。

次のターゲットで、資格証明を関連付ける必要があります。

- Oracle Fusion Middlewareがインストールされ、構成されているホスト(標準ユーザーおよびルート権限を持つユーザーの場合)

- Oracle WebLogic管理サーバー

- Oracle Database

コマンドラインで資格証明フレームワークemcliコマンドを実行して、ターゲットの名前付き資格証明を関連付けます。

emcli create_siteguard_credential_association
-system_name="name"
-credential_type="type"
-credential_name="name"
-credential_owner="owner"

パラメータ

説明

-system_name

サイトに関連付けられるシステムの名前を指定します。

-credential_type

ターゲットに応じた資格証明タイプを指定します。

- ホスト: HostNormal

- ホスト(ルート権限を持つユーザー): HostPrivileged

- Oracle WebLogic Server: WLSAdmin

- Oracle Database: DatabaseSysdba

-credential_name

資格証明の名前を指定します。

-credential_owner

資格証明の所有者を指定します。

資格証明関連付けの例については、付録B「Oracle Site Guardのサンプル・スクリプト」を参照してください。

5.5.3 前処理スクリプトおよび後処理スクリプトの関連付け

障害時リカバリ操作ワークフローのカスタム・スクリプトを作成することができます。カスタム・スクリプトは、Enterprise Manager Cloud Controlが管理していないコンポーネントに作成されます。

注意:

スクリプト引数を名前/値ペアとしてスクリプトに指定できます。例: test.pl -param1 value1 -param2 value2。

カスタム・スクリプトをOracle Site Guardに関連付けるには、コマンドラインで次のemcliコマンドを実行します。

emcli create_siteguard_script
-system_name= "name"
-operation="operation_name"
-script_type="script_type"
-host_name="name of the host"
-path="path of the script"
-all_hosts="true"

パラメータ

説明

-system_name

スイッチオーバー操作を実行しているシステムを指定します。

-operation

操作の機能。例: Switchover、Failover、StartまたはStop。

-script_type

実行する機能に応じたスクリプトのタイプとして選択できるオプションは、次のとおりです。

- Pre-Script

- Post-Script

-path

スクリプトへのパスを入力します。

-host_name

スクリプトを実行するホストの名前。

注意: 操作を実行しているシステムに関連付けらるホスト名を指定していることを確認してください。

-all_hosts

スクリプトがシステムのすべてのホストで実行されるようにするには、このオプション・フラグを指定します。このパラメータは、host_nameを無視します。

5.5.4 ストレージ・スクリプトの関連付け

次のストレージ・スクリプトを関連付ける必要があります。

- プライマリ・サイトおよびスタンバイ・サイトのマウント・スクリプト

- プライマリ・サイトおよびスタンバイ・サイトのアンマウント・スクリプト

- プライマリ・サイトおよびスタンバイ・サイトのスイッチオーバー・スクリプト

- プライマリ・サイトおよびスタンバイ・サイトのフェイルオーバー・スクリプト

プライマリ・サイトおよびスタンバイ・サイトのマウント・スクリプト

マウント・スクリプトを関連付けるには、コマンドラインで次のemcliコマンドを実行します。

emcli create_siteguard_script
-system_name="system_name"
-operation="operation_name"
-script_type="Mount"
-host_name="name of the host"
-path="path of the script"
-all_hosts= "true"

プライマリ・サイトおよびスタンバイ・サイトのアンマウント・スクリプト

カスタム・スクリプトを関連付けるには、コマンドラインで次のemcliコマンドを実行します。

emcli create_siteguard_script
-system_name="system_name"
-operation="operation_name"
-script_type= "UnMount"
-host_name="name of the host"
-path="path of the script"
-all_hosts="true"

プライマリ・サイトおよびスタンバイ・サイトのスイッチオーバー・スクリプト

カスタム・スクリプトを関連付けるには、コマンドラインで次のemcliコマンドを実行します。

emcli create_siteguard_script
-system_name="system_name"
-operation="operation_name"
-script_type="Storage-Switchover"
-host_name="name of the host"
-path="path of the script"
-all_hosts="true"

プライマリ・サイトおよびスタンバイ・サイトのフェイルオーバー・スクリプト

カスタム・スクリプトを関連付けるには、コマンドラインで次のemcliコマンドを実行します。

emcli create_siteguard_script
-system_name="system_name"
-operation="operation_name"
-script_type="Storage-Failover"
-host_name="name of the host"
-path="path of the script"
-all_hosts="true"

5.6 操作計画の使用

操作計画には、Site Guard操作の実行フローが含まれます。操作計画を使用して、操作が実行される順序を定義することができます。たとえば、Oracle HTTP Serverの停止、ドメインでのAdministration Serverの停止などがあります。

操作計画を使用するには、次の手順を実行する必要があります。

- 操作計画の作成

- 事前チェック・ユーティリティの実行

- 操作計画の送信

- 操作計画の監視

5.6.1 操作計画の作成

コマンドラインで次のemcliコマンドを実行すると、操作計画を作成することができます。

emcli create_operation_plan
-primary_system_name="name"
-standby_system_name="name"
-system_name="name"
-operation="name"
-name="name"

詳細は、付録C「create_operation_plan」を参照してください。

5.6.2 事前チェック・ユーティリティの実行

Oracle Site Guardは、操作を実行する前に、事前チェック・ユーティリティを自動的に実行します。また、Site Guard操作を実行する前に、事前チェック・ユーティリティを実行することもできます。Site Guardは、次の事前チェックを実行します。

- フェイルオーバー操作を実行する前に、プライマリで実行中のFusion Middlewareファームがダウンしていないかどうかを確認します。

- 操作の対象となるすべてのホストのエージェント・ステータスを確認します。

- 操作計画の対象となるすべてのターゲットが、Enterprise Managerレポジトリに存在しているか確認します。

- 各ターゲット・ホストで構成されたすべてのスクリプト(pre/post/mount/umount/storage role reversal)の存在をアサートします。

- データベースがロール・リバーサル(スイッチオーバー/フェイルオーバー操作)の準備ができているかを確定するために、ブローカー事前チェックを実行します。

- データベース・ロール・チェックの実行

コマンドラインで次のemcliコマンドを実行する必要があります。

emcli run_prechecks
-operation_plan="operation_plan_name"

パラメータ

説明

-operation_plan

操作計画の名前を入力します。

Enterprise Manager Cloud Controlを使用して、事前チェック操作のステータスを監視することもできます。

関連項目:

付録C「run_prechecks」。

5.6.3 操作計画の送信

コマンドラインで次のemcliコマンドを実行して、操作計画を送信する必要があります。

emcli submit_operation_plan
-name="operation plan_name"
[-run_prechecks={true|false}]

パラメータ

説明

-name

操作計画の名前を入力する必要があります。

-run_prechecks

事前チェックを実行する場合に指定します。詳細は、「事前チェック・ユーティリティの実行」を参照してください。

関連項目:

付録C「submit_operation_plan」。

5.6.4 操作計画の監視

操作計画を監視するには、次の手順を実行する必要があります。

1. EM_CLOUD_ADMINISTRATORユーザーとして、Enterprise Manager Cloud Controlコンソールにログインします。

2. 「Enterprise」→「プロビジョニングとパッチ適用」→「プロシージャ・アクティビティ資格証明」をクリックします。
「プロビジョニング」ページが表示されます。

3. 「プロシージャ・アクティビティ」タブをクリックします。

注意:

コマンドラインで次のemcliコマンドを実行して、ステータスを確認することもできます。

get_instance_status_instance="GUID"

GUID情報を取得するには、次のコマンドを実行します。

emcli get_instances
-type="SiteGuard"

5.7 エラー管理フレームワーク

Oracle Site Guardは、Enterprise Manager Cloud Controlデプロイメント・プロシージャ・フレームワークを使用して、リモート・ホストで障害操作を編成します。このフレームワークは、手順内の個別のターゲット・レベルではなく、最上位の手順(例: Start WLS Managed Server)で適用できる、エラー・モード(停止と継続)を使用したエラー管理サポートを提供します。ただし、障害時リカバリ・シナリオでは、正常に機能しない可能性が大きくなります。たとえば、一部のホストは停止して、アクセスできなくなったり、一部のサーバーでは、起動しなくなったりする場合があります。このような障害を解決するために、Oracle Site Guardは、ターゲット・レベルでエラー・モードを定義するオプションを用意しており、手順を有効化または無効化することができます。デフォルトでは、エラー・モードはstopで、実行モードはcontinueです。この項には次のトピックが含まれます:

- エラー・モード

- 操作計画でのエラー・モードの更新

- 失敗した操作の再試行

注意:

詳細は、第7章「Oracle Site Guardのトラブルシューティング」を参照してください。

5.7.1 エラー・モード

特定の操作計画の手順における個別のターゲットに対して、次のエラー・モードを定義することができます。

- エラー・モードの停止

- エラー・モードの継続

5.7.1.1 エラー・モードの停止

手順が失敗した場合、実行フローは停止します。手順のステータスは、「アクション必須」になります。Enterprise Manager Cloud Controlコンソールからこの失敗を手動で確認して、実行を再開する必要があります。確認後、実行フローは継続しますが、失敗した手順は再試行されません。失敗した手順は、コンソールからジョブ・レベルで再試行できますが、再試行操作のステータスは、ターゲット・レベル・ステータスまたは最上位の手順ステータスでは、反映されません。これがデフォルトのエラー・モードです。図5-2および図5-3を参照してください。

図5-2 ステータスの詳細

「図5-2 ステータスの詳細」の説明

図5-3 エラー・モードの停止

「図5-3 エラー・モードの停止」の説明

5.7.1.2 エラー・モードの継続

このエラー・モードでは、手順が失敗した後でも実行フローは継続します。手順のステータスは、「失敗」を示しますが、操作は継続され、最上位の手順のステータスは、「エラーで完了」を示します。図5-4は、エラー・モードの継続の例を示しています。

図5-4 エラー・モードの継続

「図5-4 エラー・モードの継続」の説明

5.7.2 操作計画でのエラー・モードの更新

コマンドラインで次のemcliコマンドを実行すると、操作計画のエラー・モード(エラーおよび実行)を更新することができます。

emcli update_operation_plan
-name="plan_name"
-step_number={step number}
-target_host={host name}
-error_mode={error mode}
-enabled={true|false}

パラメータ

説明

-name

操作計画の名前。

-step_number

更新する必要がある手順の数

-target_host

システムの名前。このオプションを入力すると、StartまたはStop操作を実行できます。

-error_mode

エラー・モードのタイプ。例: StopまたはContinue。

-enabled

trueまたはfalseを指定します。

図5-5では、ユーザー定義による更新操作計画の例を示しています。

図5-5 エラー・モードの更新

「図5-5 エラー・モードの更新」の説明

5.7.3 失敗した操作の再試行

失敗した操作を再試行するには、次の手順を実行します。

1. EM_CLOUD_ADMINISTRATORユーザーとして、Enterprise Manager Cloud Controlコンソールにログインします。

2. 「Enterprise」→「プロビジョニングとパッチ適用」→「プロシージャ・アクティビティ資格証明」をクリックします。
「プロビジョニング」ページが表示されます。

3. 「プロシージャ・アクティビティ」タブをクリックします。

4. 失敗した操作を選択し、「アクション必須」を選択します。

5. 「埋込みプロシージャ・ステップ」セクションで、「アクション必須」をクリックします。

6. 失敗した操作を選択し、「失敗」を選択します。

7. 「ターゲット」セクションで、失敗した操作を選択し、「失敗」をクリックします。

8. 「再試行」をクリックします。

9. 「Enterprise」→「プロビジョニングとパッチ適用」→「プロシージャ・アクティビティ資格証明」をクリックします。

10. 「プロシージャ・アクティビティ」タブをクリックします。

11. 失敗した操作を選択し、「アクション必須」を選択します。

12. 「埋込みプロシージャ・ステップ」セクションで、「アクション必須」をクリックします。

13. 失敗した操作を選択し、「アクション必須」を選択します。

14. 「確認」をクリックします。

注意:

ボタンを無効化するには、「確認」を数回クリックする必要があります。

15. 「完了」をクリックします。

5.8 Site Guard構成の管理

emcliコマンドを使用して、次のSite Guard構成を管理します。

- ホストの追加

- サイトの停止

- サイトの起動

- サイト・スイッチオーバーの実行

- サイト・フェイルオーバーの実行

関連項目:

Site Guard構成をコマンドラインから直接管理するemcliコマンドのリストについては、付録C「Oracle Site Guardコマンドライン・インタフェース・リファレンス」を参照してください。

5.8.1 ホストの追加

ホストを追加するには、付録C「add_siteguard_script_hosts」の説明に従って、手順を実行します。ホストの表示および削除の詳細は、付録C「get_siteguard_script_hosts」および付録C「delete_siteguard_script_hosts」を参照してください。

5.8.2 サイトの停止

サイトを停止するには、コマンドラインで次のemcliコマンドを実行します。

emcli submit_operation_plan
-name="name"
-run_prechecks="true"

パラメータ

説明

-name

操作計画の名前を入力します。

-run_prechecks

trueまたはfalseを入力します。

Site Guardの構成例については、付録B「Oracle Site Guardのサンプル・スクリプト」を参照してください。

5.8.3 サイトの起動

サイトを起動するには、コマンドラインで次のemcliコマンドを実行します。

emcli submit_operation_plan
-name="name"
-run_prechecks="true"

パラメータ

説明

-name

操作計画の名前を入力します。

-run_prechecks

trueまたはfalseを入力します。

Site Guardの構成例については、付録B「Oracle Site Guardのサンプル・スクリプト」を参照してください。

5.8.4 サイト・スイッチオーバーの実行

サイト・スイッチオーバーを実行するには、コマンドラインで次のemcliコマンドを実行します。

emcli create_operation_plan
-name="switchover-site1"
-run_prechecks="true"

パラメータ

説明

-name

スイッチオーバーを実行するには、サイトの名前を入力します。

-run_prechecks

trueまたはfalseを入力します。

Site Guardの構成例については、付録B「Oracle Site Guardのサンプル・スクリプト」を参照してください。

5.8.5 サイト・フェイルオーバーの実行

サイト・フェイルオーバーを実行するには、コマンドラインで次のemcliコマンドを実行します。

emcli create_operation_plan
-name="failover-site1"
-run_prechecks="true"

パラメータ

説明

-name

フェイルオーバーを実行するには、サイトの名前を入力します。

-run_prechecks

trueまたはfalseを入力します。

Site Guardの構成例については、付録B「Oracle Site Guardのサンプル・スクリプト」を参照してください。

フェイルオーバー操作を実行したら、手動でデータベースを回復する必要があります。詳細は、『Oracle Data Guard Broker』の「データベースの回復方法」を参照してください。

5.9 サンプル・シナリオ: Oracle BI Enterprise Edition

このセクションでは、Oracle Site Guardを設定して本番サイトおよびスタンバイ・サイトで障害時リカバリを管理するのに必要な手順を説明する例としてOracle Business Intelligence Enterprise Edition (EE)エンタープライズ・デプロイメント・トポロジーを使用します。次のタスクを実行する必要があります。

- タスク1: Oracle Business Intelligence Enterpriseデプロイメントの設定

- タスク2: プライマリ・サイトおよびスタンバイ・サイトのターゲットの検出

- タスク3: Oracle Business Intelligenceの本番システムとスタンバイ・システムの作成

- タスク4: 資格証明の作成

- タスク5: Oracle Site Guard構成の作成

- タスク6: サイトの資格証明の関連付け

- タスク7: 前処理スクリプトおよび後処理スクリプトの作成

- タスク8: ストレージ・スクリプトの関連付け

- タスク9: 操作計画の作成

- タスク10: BISystem1の起動

- タスク11: BISystem1の停止

- タスク12: Oracle Site Guard事前チェック・ユーティリティの実行

- タスク13: サイト・スイッチオーバーの実行

- タスク14: サイト・フェイルオーバーの実行

5.9.1 タスク1: Oracle Business Intelligence Enterpriseデプロイメントの設定

『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence』の説明に従って、Oracle Business Intelligenceエンタープライズ・デプロイメントを設定します。

次の要件が満たされていることを確認してください。

- 「Oracle Business Intelligenceの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名」の説明に従って、ホスト名が構成されていることを確認してください。

- 「Oracle Business Intelligenceの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名」の説明に従って、仮想IPアドレスおよび仮想ホスト名が構成されていることを確認してください。

- 第4.1.1.6項「Oracle Business Intelligenceのディレクト構造に関する推奨事項」を参照してください。

- 第4.2.5項「Creating the Production Site for the Oracle Business Intelligenceトポロジの本番サイトの作成」の説明に従って、Oracle Business Intelligence本番サイトが構成されていることを確認してください。

- 第4.3.1項「スタンバイ・サイトの作成」の説明に従って、Oracle Business Intelligenceスタンバイ・サイトが構成されていることを確認してください。

5.9.2 タスク2: プライマリ・サイトおよびスタンバイ・サイトのターゲットの検出

Enterprise Manager Cloud Control 12c リリース1(12.1.0.2)で、Oracle BI Enterprise Editionプライマリ・サイトおよびスタンバイ・サイトのターゲットを検出する必要があります。詳細は、「プライマリ・サイトおよびスタンバイ・サイトでのターゲットの検出」を参照してください。

次のターゲットが利用できます。

- 管理サーバー

- 管理対象サーバー(bi_server1およびbi_server2)

- OPMN管理システム・コンポーネント(WEBHOST1およびWEBHOST2)

- Oracle RACデータベース・インスタンス(CUSTDBHOST1およびCUSTDBHOST2)

注意:

Oracle Business Intelligence OPMN管理対象システム・コンポーネントは、Enterprise Manager Cloud Controlでは検出されません。Oracle Business Intelligence OPMN管理対象システム・コンポーネントを管理するには、「起動および停止スクリプトの作成」の説明に従って、カスタム・スクリプトを作成します。

図5-6および図5-7は、利用可能なOracle Fusion MiddlewareファームおよびRACデータベース・ターゲットを示しています。

図5-6 Oracle Fusion Middlewareターゲット

「図5-6 Oracle Fusion Middlewareターゲット」の説明

図5-7 データベース・ターゲット

「図5-7 データベース・ターゲット」の説明

5.9.3 タスク3: Oracle Business Intelligenceの本番システムとスタンバイ・システムの作成

「本番システムとスタンバイ・システムの作成」の説明に従って、手順を実行します。本番サイトおよびスタンバイ・サイトの名前としてそれぞれ、BISystem1およびBISystem2を入力します。

図5-8は、BISystem1システムを示しています。

図5-8 本番サイトおよびスタンバイ・サイトの汎用システム

「図5-8 本番サイトおよびスタンバイ・サイトの汎用システム」の説明

5.9.4 タスク4: 資格証明の作成

詳細は、「Oracle Site Guardの資格証明の作成」を参照してください。

5.9.5 タスク5: Oracle Site Guard構成の作成

プライマリ・サイトおよびスタンバイ・サイトの構成を追加するには、コマンドラインで次のemcliコマンドを実行する必要があります。

emcli create_siteguard_configuration
-primary_system_name="BISystem1"
-standby_system_name="BISystem2"

詳細は、付録C「create_siteguard_configuration」を参照してください。

既存のプライマリ・サイトおよびスタンバイ・サイトの間の関連付けを表示するには、コマンドラインで次のemcliコマンドを実行する必要があります。

emcli get_siteguard_configuration
-primary_system_name="BISystem1"
-standby_system_name="BISystem2"

5.9.6 タスク6: サイトの資格証明の関連付け

次のターゲットに対して、名前付き資格証明を関連付ける必要があります。

- ホスト(通常ユーザーおよびルート権限を持つユーザーの場合)

- ホスト(ルート権限を持つユーザー)

- Oracle WebLogic Server

- Oracle Database

資格証明フレームワークemcliコマンドを実行して、次のように名前付き資格証明を作成します。

- ホスト・ターゲットの資格証明の作成

- Oracle WebLogic Serverターゲットの資格証明の作成

- Oracle Databaseターゲットの資格証明の作成

ホスト・ターゲットの資格証明の作成

Oracle Business Intelligence Enterprise Edition (EE)のインストールおよび構成先となるホストの資格証明を指定する必要があります。コマンドラインで次のemcliコマンドを実行します。

ホスト(通常ユーザー)のBISystem1

emcli create_siteguard_credential_association
-system_name="BISystem1"
-credential_type="HostNormal"
-credential_name="NC_HOSTNORMAL"
-credential_owner="sysman"

ホスト(ルート権限を持つユーザー)のBISystem1

emcli create_siteguard_credential_association
-system_name="BISystem1"
-credential_type="HostPrivileged"
-credential_name="NC_HOSTSUDO"
-credential_owner="sysman"

ホスト(通常ユーザー)のBISystem2

emcli create_siteguard_credential_association
-system_name="BISystem1"
-credential_type="HostNormal"
-credential_name="NC_HOSTNORMAL"
-credential_owner="sysman"

ホスト(ルート権限を持つユーザー)のBISystem2

emcli create_siteguard_credential_association
-system_name="BISystem1"
-credential_type="HostPrivileged"
-credential_name="NC_HOSTSUDO"
-credential_owner="sysman"

詳細は、付録C「create_siteguard_credential_association」を参照してください。

Oracle WebLogic Serverターゲットの資格証明の作成

コマンドラインで次のemcliコマンドを実行して、Oracle WebLogic Serverの資格証明を指定する必要があります。

BISystem1

emcli create_siteguard_credential_association
-system_name="BISystem1"
-credential_type="WLSAdmin"
-credential_name="NC_WLSADMIN"
-credential_owner="sysman"

BISystem2

emcli create_siteguard_credential_association
-system_name="BISystem2"
-credential_type="WLSAdmin"
-credential_name="NC_WLSADMIN"
-credential_owner="sysman"

詳細は、付録C「create_siteguard_credential_association」を参照してください。

Oracle Databaseターゲットの資格証明の作成

コマンドラインで次のemcliコマンドを実行して、Oracle Databaseの資格証明を指定する必要があります。

BISystem1

emcli create_siteguard_credential_association
-system_name="BISystem1"
-credential_type="DatabaseSysdba"
-credential_name="NC_BIDBINSTANCES"
-credential_owner="sysman"

BISystem2

emcli create_siteguard_credential_association
-system_name="BISystem2"
-credential_type="DatabaseSysdba"
-credential_name="NC_BIDBINSTANCES"
-credential_owner="sysman"

詳細は、付録C「create_siteguard_credential_association」を参照してください。

コマンドラインで次のemcliコマンドを実行して、資格証明がシステムに関連付けられているかを検証することができます。

emcli get_siteguard_credential_association
-system_name="System_Name"

図5-9は、BISystem1に関連付けられた資格証明を示しています。

図5-9 BISystem1に関連付けられた資格証明

「図5-9 BISystem1に関連付けられた資格証明」の説明

5.9.7 タスク7: 前処理スクリプトおよび後処理スクリプトの作成

Oracle Site Guardには、障害時リカバリ操作ワークフローにユーザー指定のスクリプトを含めるオプションが用意されています。次の前処理スクリプトおよび後処理スクリプトを作成する必要があります。

- 起動および停止スクリプトの作成

- スイッチオーバーおよびフェイルオーバー・スクリプトの作成

注意:

必要なスクリプトを作成した後、それらを、スクリプトを実行する各ホスト上の宛先フォルダに保存する必要があります。例: /u01/app/oracle/admin/bi_instance/sgscripts。

詳細は、「前処理スクリプトおよび後処理スクリプトの関連付け」を参照してください。

5.9.7.1 起動および停止スクリプトの作成

Oracle Business Intelligence OPMN管理対象システム・コンポーネントに起動および停止スクリプトを作成する必要があります。これらのシステム・コンポーネントを管理するには、次の起動および停止スクリプトを作成する必要があります。

- BISystem1での起動操作の後処理スクリプト

- BISystem1での停止操作の前処理スクリプト

- BISystem2での起動操作の後処理スクリプト

- BISystem2での停止操作の前処理スクリプト

BISystem1での起動操作の後処理スクリプト

コマンドラインで次のemcliコマンドを実行して、起動操作の後処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem1"
-operation="Start"
-script_type="Post-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/startbisystemcomponents.sh"
-host_name="BIHOST1"
-host_name="BIHOST2"
-role="Primary"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem1での停止操作の前処理スクリプト

コマンドラインで次のemcliコマンドを実行して、停止操作の前処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem1"
-operation="Stop"
-script_type="Pre-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/stopbisystemcomponents.sh"
-host_name="BIHOST1"
-host_name="BIHOST2"
-role="Primary"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem2での起動操作の後処理スクリプト

コマンドラインで次のemcliコマンドを実行して、起動操作の後処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem2"
-operation="Start"
-script_type="Post-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/startbisystemcomponents.sh"
-host_name="STBYBI1"
-host_name="STBYBI2"
-role="Primary"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem2での停止操作の前処理スクリプト

コマンドラインで次のemcliコマンドを実行して、停止操作の後処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem2"
-operation="Stop"
-script_type="Pre-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/stopbisystemcomponents.sh"
-host_name="STBYBI1"
-host_name="STBYBI2"
-role="Primary"

詳細は、付録C「create_siteguard_script」を参照してください。

5.9.7.2 スイッチオーバーおよびフェイルオーバー・スクリプトの作成

次のスクリプトを作成する必要があります。

- BISystem1でのスイッチオーバー操作の前処理スクリプト

- BISystem1でのスイッチオーバー操作の後処理スクリプト

- BISystem1でのフェイルオーバー操作の後処理スクリプト

- BISystem2でのスイッチオーバー操作の前処理スクリプト

- BISystem2でのスイッチオーバー操作の後処理スクリプト

- BISystem2でのフェイルオーバー操作の後処理スクリプト

BISystem1でのスイッチオーバー操作の前処理スクリプト

コマンドラインで次のemcliコマンドを実行して、スイッチオーバー操作の前処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem1"
-operation="Switchover"
-script_type="Pre-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/stopbisystemcomponents.sh"
-host_name="BIHOST1"
-host_name="BIHOST2"
-role="Primary"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem1でのスイッチオーバー操作の後処理スクリプト

コマンドラインで次のemcliコマンドを実行して、スイッチオーバー操作の後処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem1"
-operation="Switchover"
-script_type="Post-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/startbisystemcomponents.sh"
-host_name="BIHOST1"
-host_name="BIHOST2"
-role="Standby"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem1でのフェイルオーバー操作の後処理スクリプト

コマンドラインで次のemcliコマンドを実行して、フェイルオーバー操作の後処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem1"
-operation="failover"
-script_type="Post-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/startbisystemcomponents.sh"
-host_name="BIHOST1"
-host_name="BIHOST2"
-role="Standby"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem2でのスイッチオーバー操作の前処理スクリプト

コマンドラインで次のemcliコマンドを実行して、スイッチオーバー操作の前処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem2"
-operation="Switchover"
-script_type="Pre-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/stopbisystemcomponents.sh"
-host_name="STBYBI1"
-host_name="STBYBI2"
-role="Primary"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem2でのスイッチオーバー操作の後処理スクリプト

コマンドラインで次のemcliコマンドを実行して、スイッチオーバー操作の後処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem2"
-operation="Switchover"
-script_type="Post-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/startbisystemcomponents.sh"
-host_name="STBYBI1"
-host_name="STBYBI2"
-role="Standby"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem2でのフェイルオーバー操作の後処理スクリプト

コマンドラインで次のemcliコマンドを実行して、フェイルオーバー操作の後処理スクリプトを作成します。

emcli create_siteguard_script
-system_name= "BISystem2"
-operation="failover"
-script_type="Post-Script"
-path="/u01/app/oracle/admin/bi_instance/sgscripts/startbisystemcomponents.sh"
-host_name="STBYBI1"
-host_name="STBYBI2"
-role="Standby"

詳細は、付録C「create_siteguard_script」を参照してください。

5.9.8 タスク8: ストレージ・スクリプトの関連付け

「カスタム・スクリプトの作成」の説明に従ってストレージ・スクリプトを作成した後、次を実行する必要があります。

- BISystem1のストレージ・スイッチオーバー・スクリプト

- BISystem2のストレージ・スイッチオーバー・スクリプト

- BISystem1のストレージ・フェイルオーバー・スクリプト

- BISystem2のストレージ・フェイルオーバー・スクリプト

BISystem1のストレージ・スイッチオーバー・スクリプト

コマンドラインで次のemcliコマンドを実行して、フェイルオーバー操作のストレージ・スイッチオーバー・スクリプトを関連付けます。

emcli create_siteguard_script
-system_name= "BISystem1"
-operation="Switchover"
-script_type="Storage-Switchover"
-path="/u01/app/oracle/admin/bi_instance/sgstoragescripts/switchovertobisystem1.sh"
-host_name="BIHOST1"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem2のストレージ・スイッチオーバー・スクリプト

コマンドラインで次のemcliコマンドを実行して、フェイルオーバー操作のストレージ・スイッチオーバー・スクリプトを関連付けます。

emcli create_siteguard_script
-system_name= "BISystem2"
-operation="Switchover"
-script_type="Storage-Switchover"
-path="/u01/app/oracle/admin/bi_instance/sgstoragescripts/switchovertobisystem2.sh"
-host_name="STBYBI1"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem1のストレージ・フェイルオーバー・スクリプト

コマンドラインで次のemcliコマンドを実行して、フェイルオーバー操作のストレージ・スイッチオーバー・スクリプトを関連付けます。

emcli create_siteguard_script
-system_name= "BISystem1"
-operation="Failover"
-script_type="Storage-Failover
-path="/u01/app/oracle/admin/bi_instance/sgstoragescripts/failovertobisystem1.sh"
-host_name="BIHOST1"

詳細は、付録C「create_siteguard_script」を参照してください。

BISystem2のストレージ・フェイルオーバー・スクリプト

コマンドラインで次のemcliコマンドを実行して、フェイルオーバー操作のストレージ・スイッチオーバー・スクリプトを関連付けます。

emcli create_siteguard_script
-system_name= "BISystem2"
-operation="Failover"
-script_type="Storage-Failover"
-path="/u01/app/oracle/admin/bi_instance/sgstoragescripts/failovertobisystem2.sh"
-host_name="STBYBI1"

詳細は、付録C「create_siteguard_script」を参照してください。

5.9.9 タスク9: 操作計画の作成

次の操作計画を作成する必要があります。

- BISystem1での起動操作の操作計画

- BISystem1での停止操作の操作計画

- BISystem2での起動操作の操作計画

- BISystem2での停止操作の操作計画

- BISystem2でのスイッチオーバー操作の操作計画

- BISystem1でのスイッチオーバー操作の操作計画

- BISystem2でのフェイルオーバー操作の操作計画

- BISystem1でのフェイルオーバー操作の操作計画

詳細は、「操作計画の操作」を参照してください。。

BISystem1での起動操作の操作計画

コマンドラインで次のemcliコマンドを実行して、起動操作計画を作成します。

emcli create_operation_plan
_system_name="BISystem1"
-operation="Start"
-name="start-bisystem1"
-role="Primary"

詳細は、付録C「create_operation_plan」を参照してください。

BISystem1での停止操作の操作計画

コマンドラインで次のemcliコマンドを実行して、停止操作計画を作成します。

emcli create_operation_plan
-system_name="BISystem1"
-operation="Stop"
-name="stop-bisystem1"
-role="Primary"

詳細は、付録C「create_operation_plan」を参照してください。

BISystem2での起動操作の操作計画

コマンドラインで次のemcliコマンドを実行して、起動操作計画を作成します。

emcli create_operation_plan
-system_name="BISystem2"
-operation="Start"
-name="start-bisystem2"
-role="Primary"

詳細は、付録C「create_operation_plan」を参照してください。

BISystem2での停止操作の操作計画

コマンドラインで次のemcliコマンドを実行して、停止操作計画を作成します。

emcli create_operation_plan
-system_name="BISystem2"
-operation="Stop"
-name="stop-bisystem2"
-role="Primary"

詳細は、付録C「create_operation_plan」を参照してください。

BISystem2でのスイッチオーバー操作の操作計画

コマンドラインで次のemcliコマンドを実行して、スイッチオーバー操作計画を作成します。

emcli create_operation_plan
-primary_system_name="BISystem1"
-standby_system_name="BISystem2"
-operation="Switchover""
-name="switchover-to-bisystem2"

詳細は、付録C「create_operation_plan」を参照してください。

BISystem1でのスイッチオーバー操作の操作計画

コマンドラインで次のemcliコマンドを実行して、スイッチオーバー操作計画を作成します。

emcli create_operation_plan
-primary_system_name="BISystem2"
-standby_system_name="BISystem1"
-operation="Switchover""
-name="switchover-to-bisystem1"

詳細は、付録C「create_operation_plan」を参照してください。

BISystem2でのフェイルオーバー操作の操作計画

コマンドラインで次のemcliコマンドを実行して、フェイルオーバー操作計画を作成します。

emcli create_operation_plan
-primary_system_name="BISystem1"
-standby_system_name="BISystem2"
-operation="Failover"
-name="Failover-to-bisystem2"

詳細は、付録C「create_operation_plan」を参照してください。

BISystem1でのフェイルオーバー操作の操作計画

コマンドラインで次のemcliコマンドを実行して、フェイルオーバー操作計画を作成します。

emcli create_operation_plan
-primary_system_name="BISystem2"
-standby_system_name="BISystem1"
-operation="Failover"
-name="Failover-to-bisystem1"

詳細は、付録C「create_operation_plan」を参照してください。

操作計画の一覧表示

すべての操作計画を一覧表示するには、コマンドラインで次のemcliコマンドを実行します。

emcli get_operation_plan
-name={plan name}

図5-10は、BISystem1およびBISystem2のすべての操作計画の例を示しています。

図5-10 BISystem1およびBISystem2の操作計画

「図5-10 BISystem1およびBISystem2の操作計画」の説明

操作計画の詳細の一覧表示

操作計画についての情報を入手するには、コマンドラインで次のemcliコマンドを実行します。

emcli get_operation_plan_details
-name={plan name}

詳細は、付録C「get_operation_plan_details」を参照してください。

5.9.10 タスク10: BISystem1の起動

BISystem1を起動するには、コマンドラインでemcliコマンドを使用して、start-bisystem1操作を送信します。

emcli submit_operation_plan
-name="start-bisystem1"

詳細は、付録C「submit_operation_plan」を参照してください。

図5-11は、start-bisystem1操作ステータスを示しています。

図5-11 起動ステータス

「図5-11 起動ステータス」の説明

次の手順を実行して、Enterprise Manager Cloud Controlコンソールからステータスを監視することもできます。

1. EM_CLOUD_ADMINISTRATORユーザーとして、Enterprise Manager Cloud Controlコンソールにログインします。

2. 「Enterprise」→「プロビジョニングとパッチ適用」→「プロシージャ・アクティビティ」をクリックします。
「プロビジョニング」ページが表示されます。

3. 「プロシージャ・アクティビティ」タブをクリックします。

5.9.11 タスク1: BISystem1の停止

BISystem1を停止するには、コマンドラインでemcliコマンドを使用して、stop-bisystem1操作を送信します。

emcli submit_operation_plan
-name="stop-bisystem1"

詳細は、付録C「submit_operation_plan」を参照してください。

図5-12は、stop-bisystem1操作ステータスを示しています。

図5-12 停止ステータス

「図5-12 停止ステータス」の説明

5.9.12 タスク12: Oracle Site Guard事前チェック・ユーティリティの実行

操作計画が送信されると、Oracle Site Guardは、事前チェック・ユーティリティを実行します。

操作計画の事前チェック・ユーティリティを実行するには、コマンドラインで次のemcliコマンドを実行します。

emcli run_prechecks
-operation_plan="name"

詳細は、付録C「run_prechecks」を参照してください。

図5-13は、コマンドラインの事前チェック・ユーティリティemcliコマンドの例を示しています。

図5-13 事前チェック・ユーティリティ

「図5-13 事前チェック・ユーティリティ」の説明

5.9.13 タスク13: サイト・スイッチオーバーの実行

次の手順を実行する必要があります。

- BISystem1へのスイッチオーバー

- BISystem2へのスイッチオーバー

BISystem1へのスイッチオーバー

BISystem1に対してサイト・スイッチオーバーを実行するには、コマンドラインで次のemcliコマンドを実行します。

emcli submit_operation_plan
-name="switchover-to-bisystem1"
-run_prechecks="true"

詳細は、付録C「submit_operation_plan」を参照してください。

図5-14は、スイッチオーバーの操作ステータスを示しています。

図5-14 BISystem1のスイッチオーバー・ステータス

「図5-14 BISystem1のスイッチオーバー・ステータス」の説明

BISystem2へのスイッチオーバー

BISystem2に対してサイト・スイッチオーバーを実行するには、コマンドラインで次のemcliコマンドを実行します。

emcli submit_operation_plan
-name="switchover-to-bisystem2"
-run_prechecks="true"

詳細は、付録C「submit_operation_plan」を参照してください。

図5-15は、スイッチオーバーの操作ステータスを示しています。

図5-15 BISystem2のスイッチオーバー・ステータス

「図5-15 BISystem2のスイッチオーバー・ステータス」の説明

スイッチオーバーの実行後、図5-16で示すように、Site Guard構成の関連付けが更新されます。

図5-16 更新されたSite Guardステータス

「図5-16 更新されたSite Guardステータス」の説明

5.9.14 タスク14: サイト・フェイルオーバーの実行

次の手順を実行する必要があります。

- BISystem1へのフェイルオーバー

- BISystem2へのフェイルオーバー

BISystem1へのフェイルオーバー

BISystem1に対してサイト・フェイルオーバーを実行するには、コマンドラインで次のemcliコマンドを実行します。

emcli submit_operation_plan
-name="failover-to-bisystem1"
-run_prechecks="true"

詳細は、付録C「submit_operation_plan」を参照してください。

図5-17は、フェイルオーバーの操作ステータスを示しています。

図5-17 BISystem1のフェイルオーバー・ステータス

「図5-17 BISystem1のフェイルオーバー・ステータス」の説明

BISystem2へのフェイルオーバー

BISystem2に対してサイト・フェイルオーバーを実行するには、コマンドラインで次のemcliコマンドを実行します。

emcli submit_operation_plan
-name="failover-to-bisystem2"
-run_prechecks="true"

詳細は、付録C「submit_operation_plan」を参照してください。

図5-18は、フェイルオーバーの操作ステータスを示しています。

図5-18 BISystem2のフェイルオーバー・ステータス

「図5-18 BISystem2のフェイルオーバー・ステータス」の説明

6 障害時リカバリのトラブルシューティング

この章では、障害時リカバリ・トポロジにおいてOracle Fusion Middlewareをデプロイおよび管理するときに一般的に遭遇する可能性がある状況、およびそうした状況に対処するための手順について説明します。内容は次のとおりです。

- Oracle Fusion Middleware障害時リカバリ・トポロジのトラブルシューティング

- 追加情報

6.1 Oracle Fusion Middleware障害時リカバリ・トポロジのトラブルシューティング

この項では、Oracle Fusion Middleware構成時に一般的に遭遇する可能性がある状況と構成の実行手順について説明します。内容は次のとおりです。

- 本番サイトおよびスタンバイ・サイトのホスト名解決の確認

- 障害時リカバリ・トポロジでのコンポーネントの問題の解決

- 共有ストレージにデプロイされたコンポーネントの問題の解決

6.1.1 本番サイトおよびスタンバイ・サイトのホスト名解決の確認

障害時リカバリ・トポロジで発生する問題の多くは、ホスト名解決が本番サイトおよびスタンバイ・サイトに対して正しく設定されていないことが原因です。

第3.1.1.5項「ホスト名解決のテスト」のホスト名検証手順を実行して、ホスト名解決が正しく設定されていることを確認してください。

6.1.2 障害時リカバリ・トポロジでのコンポーネントの問題の解決

障害時リカバリ・トポロジのコンポーネントで発生する可能性のある問題の中には、障害時リカバリの問題ではなく、コンポーネント自体に関するものがあります。

障害時リカバリ・トポロジで使用されているOracle Fusion Middlewareコンポーネントで問題が発生した場合、そのコンポーネントの『Oracle Fusion Middleware高可用性ガイド』のトラブルシューティングに関する項を参照して、発生した問題について記述されているかどうか確認します。

同様に、ご使用の障害時リカバリ・トポロジが、次のマニュアルで説明されている1つ以上のエンタープライズ・デプロイメントに基づいており、問題が発生した場合には、そのマニュアルのトラブルシューティングに関する項を参照して、発生した問題について記述されているかどうか確認します。

- Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド

- Oracle Portal、Forms、ReportsおよびDiscovererエンタープライズ・トポロジの詳細は、11.1.1.2 Oracle Portalエンタープライズ・デプロイメント・ガイドに記載されています。このマニュアルの入手方法は、My Oracle Support(以前のOracle MetaLink)にある記事ID 952068.1「Oracle Fusion Middleware 11g(11.1.1.2)Portal、Forms、ReportsおよびDiscoverエンタープライズ・デプロイメント・ガイド」を参照してください。My Oracle SupportのURLは次のとおりです。
http://support.oracle.com

- Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド

6.1.3 共有ストレージにデプロイされたコンポーネントの問題の解決

障害時リカバリ・トポロジのコンポーネントで発生する可能性のある問題の中には、障害時リカバリの問題ではなく、共有ストレージへのコンポーネントのデプロイに関するものがあります。

第6.1.2項「障害時リカバリ・トポロジでのコンポーネントの問題の解決」に示したマニュアルに記載されている共有ストレージに関する問題の中に、該当するものがない場合は、『Oracle Fusion Middlewareリリース・ノート』の共有ストレージの問題に関する説明を参照してください(Oracle Technology Networkで参照可能):

http://www.oracle.com/technology/documentation/middleware.html

6.2 追加情報

前の項の情報では不十分な場合は、My Oracle Support(旧称Oracle MetaLink)でさらに詳しい解決法を参照できます(次の場所を参照):

http://support.oracle.com

発生した問題の解決法が見つからない場合は、サービス・リクエストを記録してください。

Oracle Technology Networkで提供されている『Oracle Fusion Middlewareリリース・ノート』も参照できます。

http://www.oracle.com/technology/documentation/middleware.html

7 Oracle Site Guardのトラブルシューティング

表7-1では、障害時リカバリ・トポロジにおいてOracle Site Guardをデプロイおよび管理するときに一般的に遭遇する可能性がある状況、およびそうした状況に対処するための手順について説明します。

表7-1 トラブルシューティング

シナリオ

説明およびソリューション

事前チェック操作

事前チェック操作が失敗した場合、次のエラーが表示されます。

Nmo setuid status NMO not setuid-root (Unix-only)

Oracle Management Agentのインストール後、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の「インストール後の作業」の項の説明に従って、root.shスクリプトを実行してください。

Oracle Management Agentが停止している場合、リモート・ホストでコマンドを実行しようとすると、事前チェック操作がハングします。

操作に関連するすべてのホストが有効であり、構成されているすべてのスクリプトが、構成された場所のリモート・ホストで利用可能になっていることを確認してください。何らかの理由でOracle Management Agentにアクセスできない場合、Enterprise Manager Cloud Controlコンソールからログ・ファイルを確認してください。どのホストが停止しているかわかっている場合は、それらのホストの事前チェック操作を省略することができます。

Oracle WebLogic Server

ノード・マネージャは、次のエラーが原因で失敗する場合があります。

<Sep 13, 2011 8:45:37 PM PDT> <Error> <NodeManager> <BEA-300033> <Could not execute command "getVersion" on the node manager. Reason: "Access to domain 'base_domain' for user 'weblogic' denied".>

この問題は、ノード・マネージャ資格証明を変更した後、正しいノード・マネージャ・ユーザーおよびパスワード・トークンが各管理対象サーバーに指定されているかを確認するためのnmEnrollを実行していない場合に発生する可能性があります。

次の構文を使用して、nmEnrollを実行します。

nmEnroll([domainDir], [nmHome])

例:

nmEnroll('C:/oracle/user_projects/domains/prod_domain',
'C:/oracle/wlserver_10.3/common/nodemanager')

注意: 変更を有効にするには、ノード・マネージャを再起動する必要があります。

Enterprise Manager Cloud ControlでのOracle WebLogic Server管理サーバー接続の失敗が原因で、管理対象サーバーが起動できません。

Oracle Site Guardで管理対象サーバーを起動するには、管理サーバーおよびノード・マネージャが必要です。管理対象サーバーを正常に起動、停止できるように、管理サーバーが起動して、実行されているか確認してください。

操作計画

システムの一部であるOracle DatabaseまたはOracle Fusion Middlewareファームのようなターゲットは、操作計画ワークフローで検出できません。

この問題は、操作計画を作成した後でシステムにターゲットを追加すると発生する場合があります。操作計画の作成中、Oracle Site Guardには、システムの一部であるこれらのターゲットのみが含まれます。新しいターゲットを追加した場合は、操作計画を再作成する必要があります。

Oracle WebLogic Serverドメインの一部であるOracle WebLogic Server管理対象サーバー・ターゲットは、操作計画ワークフローの作成時に、Oracle Site Guardによって更新されたり、認識されたりしません。

Enterprise Manager Cloud Controlで自動検出を実行する前に、管理対象サーバーが起動して、実行されていることを確認してください。

システムの一部であるOPMN管理対象システム・コンポーネントは、操作計画ワークフローでは検出できません。

Oracle Site Guardは、Enterprise Manager Cloud Controlで表現されたOPMN管理対象システム・コンポーネントのみを検出します。たとえば、Oracle HTTP ServerおよびOracle Web CacheのようなOPMN管理対象システム・コンポーネントは、Enterprise Manager Cloud Controlで表現されます。これらのコンポーネントは、Oracle Fusion Middlewareファームの一部として検出されます。

システムの一部であるOracle RACデータベースeは、操作計画ワークフローでは検出できません。

Oracle RACデータベースは、Enterprise Manager Cloud ControlのRACデータベース・ターゲットの下にグループ化され、表現されます。RACデータベース・インスタンスが検出されると、RACデータベース・ターゲットが作成され、RACデプロイメントのすべてのデータベース・インスタンスは、RACデータベース・ターゲットの下にグループ化されます。この問題は、各RACインスタンス・ターゲットが、RACデータベース・ターゲットではなく、システムに追加された時に発生する場合があります。Oracle Site Guardは、個々のRACインスタンスを特定できません。

スイッチオーバーまたはフェイルオーバー操作

スイッチオーバーまたはフェイルオーバー操作の後、管理サーバーは、起動に失敗する場合があります。管理サーバーの出力ログ・ファイルには、次のようなエラーが報告されます。

<Jan 19, 2012 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/soadomain/aserver/soadomain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

このエラーは、ロックを正常にクリーンアップできなかったことが原因で、管理サーバー・ログ・ファイルに表示されます。このエラーを修正するには、EmbeddedLDAP.lokファイル(ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/servers/AdminServer/data/ldap/ldapfiles/に格納)を削除します。

スイッチオーバーまたはフェイルオーバー操作の後、管理サーバーは、起動に失敗する場合があります。管理サーバーの出力ログ・ファイルには、次のようなエラーが報告されます。

<Sep 16, 2011 2:04:06 PM PDT> <Error> <Store> <BEA-280061> <The persistent store "_WLS_AdminServer" could not be deployed: weblogic.store.PersistentStoreException:

[Store:280105]The persistent file store "_WLS_AdminServer" cannot open file _WLS_ADMINSERVER000000.DAT.>

このエラーは、ネットワーク・ファイル・システム(NFS)ストレージからのロックが原因で表示されます。ストレージ・ベンダーのNFSユーティリティを使用して、NFSロックを消去する必要があります。.DATファイルを一時的な場所にコピーし、そのコピーを元に戻してロックを消去します。

スイッチオーバーまたはフェイルオーバー操作の実行中、新しいプライマリ・システムの一部のホストは、利用できないか、停止している場合があります。Oracle Site Guardは、これらのホストではいずれの操作も実行できません。

これらのホストで実行中のサービスが必須ではなく、サイトが引き続き機能しており、他のノードで実行中のサービスに対してアクティブである場合は、操作計画を更新することで、停止しているホストに関連する手順を無効化することができます。Oracle Site Guardワークフローは、無効化されたすべての手順を省略してワークフローを実行します。

Oracle RACデータベース・インスタンスが停止している場合、スイッチオーバーまたはフェイルオーバー操作は失敗します。

操作計画の作成中に、Oracle Site Guardは、スイッチオーバーまたはフェイルオーバー操作を実行するOracle RACデータベース・インスタンスを決定します。RACに複数のインスタンスがデプロイされていて、一部のインスタンスが停止している可能性があります。スイッチオーバーまたはフェイルオーバー操作を実行する前に、インスタンスが起動して、実行されていることを確認する必要があります。RACインスタンスを特定するには、get_operation_plan_detailsコマンドを実行します。

データベース操作

事前チェック操作またはスイッチオーバー/フェイルオーバー操作が失敗した場合、次のエラーが表示されます。

Database Status:
DGM-17016: failed to retrieve status for database "racs"
ORA-16713: the Data Guard broker command timed out

このエラーは、ターゲット・データベース・インスタンスで、Oracle Data Guard Broker Data Guardモニター・プロセス(DMON)が停止していることが原因で発生する場合があります。データベース・インスタンスを再起動し、DMONプロセスが起動して、実行されていることを確認する必要があります。DMONプロセス・エラーのデータベース・ログ・ファイルを表示することもできます。CommunicationTimeoutパラメータを使用して、環境に適したタイムアウト値を選択することができます。詳細は、『Oracle Data Guard Broker』の「CommunicationTimeout」の項を参照してください。

A Oracleインベントリの管理

この付録では、本番サイトおよびスタンバイ・サイトでの、Oracle Fusion Middleware障害時リカバリ・トポロジにおけるOracleインベントリの管理方法について説明します。

次のトピックがあります。

- Oracleインベントリの更新

- Windowsレジストリの更新

A.1 Oracleインベントリの更新

本番サイトのホストでOracleインベントリを更新するときには(新しいOracleソフトウェアのインストール、既存のOracleソフトウェアへのOracleパッチ・セットまたはパッチの適用など)、スタンバイ・サイトのピア・ホストでも同じようにソフトウェアを更新する必要があります。そのためには、次のスクリプトを実行してスタンバイ・サイトのピア・ホストでOracleインベントリを更新します。

ORACLE_HOME/oui/bin/attachHome.sh

また、beahomelistファイルを更新して、ミドルウェア・ホームの場所を編集する必要があります。次のファイルを編集して、ミドルウェア・ホームの情報を更新します。

user_home/bea/beahomelist

(Windows) C:\bea\beahomelist

A.2 Windowsレジストリの更新

本番サイトのWindowsホストでOracleインベントリを更新するとき(新しいOracleソフトウェアのインストール、Oracleパッチ・セットまたはパッチの既存のOracleソフトウェアへの適用など)、次のWindowsレジストリ・キーを本番サイトのホストにエクスポートし、これをスタンバイ・サイトのピア・ホストにインポートすることによって、同じソフトウェア更新をスタンバイ・サイトのピア・ホストでも実行する必要があります。

HKEY_LOCAL_MACHINE\Software\oracle

また、システム・コンポーネント(Oracle Web Cacheなど)を変更する場合、次のWindowsレジストリ・キーを本番サイトのホストにエクスポートし、これをスタンバイ・サイトのピア・ホストにインポートする必要があります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

以前エクスポートしたキーをインポートするには、次のコマンドを使用します。

regedit /I <FileName>

例:

regedit /I C:\oracleregistry.reg

レジストリ・エディタを使用して、キーをインポートすることもできます。詳細は、レジストリ・エディタのヘルプを参照してください。

B Oracle Site Guardのサンプル・スクリプト

この付録は、Oracle Site Guardのサンプル・スクリプトを示しています。次が含まれています。

- Oracle Site Guard構成スクリプト

- Sun Storage ZFS Storage Applianceのロール・リバース・スクリプト

- NetApp Storageのロール・リバース・スクリプト

- akshスクリプト

例B-1 Oracle Site Guard構成スクリプト

#Login to emcli

emcli login -username="sysman" -password="sysman"

#Create site definitions

emcli create_siteguard_configuration -primary_system_name="NetappServer1System" -standby_system_name="NetappServer2System"

emcli get_siteguard_configuration

#Create credential associations

#Host credentials

emcli create_siteguard_credential_association -system_name="NetappServer1System" -credential_type="HostNormal" -credential_name="SG_CRED_HOST" -credential_owner="sysman"
emcli create_siteguard_credential_association -system_name="NetappServer1System" -credential_type="HostPrivileged" -credential_name="SG_CRED_HOST-PRIV" -credential_owner="sysman"

emcli create_siteguard_credential_association -system_name="NetappServer2System" -credential_type="HostNormal" -credential_name="SG_CRED_HOST" -credential_owner="sysman"
emcli create_siteguard_credential_association -system_name="NetappServer2System" -credential_type="HostPrivileged" -credential_name="SG_CRED_HOST-PRIV" -credential_owner="sysman"

#WLS credentials

emcli create_siteguard_credential_association -system_name="NetappServer1System" -credential_type="WLSAdmin" -credential_name="SG_CRED_WLS" -credential_owner="sysman"
emcli create_siteguard_credential_association -system_name="NetappServer2System" -credential_type="WLSAdmin" -credential_name="SG_CRED_WLS" -credential_owner="sysman"

#Database credentials

emcli create_siteguard_credential_association -system_name="NetappServer1System" -credential_type="DatabaseSysdba" -credential_name="SG_CRED_DB" -credential_owner="sysman"
emcli create_siteguard_credential_association -system_name="NetappServer2System" -credential_type="DatabaseSysdba" -credential_name="SG_CRED_DB" -credential_owner="sysman"

emcli get_siteguard_credential_association -system_name="NetappServer1System"
emcli get_siteguard_credential_association -system_name="NetappServer2System"

#Create operation plans

#Start/Stop NetappServer1System

emcli create_operation_plan -system_name="NetappServer1System" -operation="Start" -name="start-NetappServer1System"
emcli create_operation_plan -system_name="NetappServer1System" -operation="Stop" -name="stop-NetappServer1System"

#Start/Stop NetappServer2System

emcli create_operation_plan -system_name="NetappServer2System" -operation="Start" -name="start-NetappServer2System"
emcli create_operation_plan -system_name="NetappServer2System" -operation="Stop" -name="stop-NetappServer2System"

emcli get_operation_plans

#Switchover sites

#Swithover to NetappServer2System

emcli create_operation_plan -primary_system_name="NetappServer1System" -standby_system_name="NetappServer2System" -operation="Switchover" -name="switchover-to-NetappServer2System"

#Switchback to NetappServer2System

emcli create_operation_plan -primary_system_name="NetappServer2System" -standby_system_name="NetappServer1System" -operation="Switchover" -name="switchback-to-NetappServer1System"

#Failover sites

#Failover to NetappServer2System

emcli create_operation_plan -primary_system_name="NetappServer1System" -standby_system_name="NetappServer2System" -operation="Failover" -name="failover-to-NetappServer2System"

#Failover to NetappServer1System

emcli create_operation_plan -primary_system_name="NetappServer2System" -standby_system_name="NetappServer1System" -operation="Failover" -name="failover-to-NetappServer1System"

emcli get_operation_plans

例B-2 Sun Storage ZFS Storage Applianceのロール・リバース・スクリプト

1: # This script executes the switchover script of S7000 by doing role-reversal
2: #
3: #
4: ## Get the confirmation..
5: echo "Status at the source [ $CURRENT_PRIMARY ] "
6: ssh -T $CURRENT_PRIMARY < s7000_status_repl_src.aksh
7:
8: echo " Status at the target [$CURRENT_STANDBY]
9: ssh -T $CURRENT_STANDBY < s7000_status_repl_tgt.aksh
9:
10:echo "Going to failover from the source : $CURRENT_PRIMARY to the target : 11:CURRENT_STANDBY ."
12:
13:# Stop the replication
14:echo "Suspending the continuous replication at the source :  $CURRENT_PRIMARY "
15:
16:ssh -T $CURRENT_PRIMARY < s7000_stop_repl_at_source.aksh
17:
18:echo "Performing the role reversal at the target : $CURRENT_STANDBY "
19:
20:ssh -T $CURRENT_STANDBY < s7000_role_reverse_at_target.aksh
21:
22:echo "Status at the new source [$CURRENT_STANDBY ]"
23:
24: ssh -T $CURRENT_STANDBY < s7000_status_repl_src.aksh
25:
26:echo "Status at the new target [$CURRENT_PRIMARY_S7000 ]"
27:ssh -T $CURRENT_PRIMARY_S7000 < s7000_status_repl_tgt.aksh
28:

例B-3 NetAppストレージのロール・リバース・スクリプト

# Perform SnapMirror Update from the target storage system site
rsh BIHOST1 snapmirror update -S BIHOST2:VOLFMW1  BIHOST1:VOLFMW1
sleep 100
rsh BIHOST1 snapmirror update -S BIHOST2:VOLFMW2  BIHOST1:VOLFMW2
sleep 100
rsh BIHOST1 snapmirror update  -S BIHOST2:VOLADMIN  BIHOST1:VOLADMIN
sleep 100
rsh BIHOST1 snapmirror update  -S BIHOST2:VOLBI1  BIHOST1:VOLBI1
sleep 100
rsh BIHOST1 snapmirror update  -S BIHOST2:VOLBI2  BIHOST1:VOLBI2
rsh BIHOST1 snapmirror update -S BIHOST2:VOLBIINST1  BIHOST1:VOLBIINST1
sleep 100
rsh BIHOST1 snapmirror update -S BIHOST2:VOLBIINST2  BIHOST1:VOLBIINST2
rsh BIHOST1 snapmirror update -S BIHOST2:VOLWEB1 BIHOST1:VOLWEB1
sleep 100
rsh BIHOST1 snapmirror update -S BIHOST2:VOLWEB2 BIHOST1:VOLWEB2
sleep 100
rsh BIHOST1 snapmirror update -S BIHOST2:VOLWEBINST1 BIHOST1:VOLWEBINST1
sleep 100
rsh BIHOST1 snapmirror update -S BIHOST2:VOLWEBINST2  BIHOST1:VOLWEBINST2
sleep 100
rsh BIHOST1 snapmirror update  -S BIHOST2:VOLDATA1  BIHOST1:VOLDATA1
sleep 30
rsh BIHOST1 snapmirror update  -S BIHOST2:VOLDATA2  BIHOST1:VOLDATA2
sleep 30
rsh BIHOST1 snapmirror update  -S BIHOST2:VOLDATA3  BIHOST1:VOLDATA3
sleep 30
rsh BIHOST1 snapmirror update  -S BIHOST2:VOLDATA4  BIHOST1:VOLDATA4
sleep 100

# Make Netapp volumes on the new primary storage writable

rsh BIHOST1 snapmirror break BIHOST1:VOLWEB1
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLWEB2
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLWEBINST1
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLWEBINST2
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLFMW1
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLFMW2
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLADMIN
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLBI1
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLBI2
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLBIINST1
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLBIINST2
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLDATA1
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLDATA2
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLDATA3
sleep 30
rsh BIHOST1 snapmirror break BIHOST1:VOLDATA4
sleep 100

# Reverse Storage Roles

rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLWEB1 -w BIHOST2:VOLWEB1
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLWEB2 -w BIHOST2:VOLWEB2
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLWEBINST1 -w BIHOST2:VOLWEBINST1
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLWEBINST2 -w BIHOST2:VOLWEBINST2
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLBIINST1 -w BIHOST2:VOLBIINST1
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLBIINST2 -w BIHOST2:VOLBIINST2
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLFMW1 -w BIHOST2:VOLFMW1
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLFMW2 -w BIHOST2:VOLFMW2
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLADMIN -w BIHOST2:VOLADMIN
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLBI1 -w BIHOST2:VOLBI1
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLBI2 -w BIHOST2:VOLBI2
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLDATA1 -w BIHOST2:VOLDATA1
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLDATA2 -w BIHOST2:VOLDATA2
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLDATA3 -w BIHOST2:VOLDATA3
sleep 20
rsh BIHOST2 snapmirror resync -f -S BIHOST1:VOLDATA4 -w BIHOST2:VOLDATA4
sleep 20

例B-4 akshスクリプト

script
/**********************************************************
* Script to role reverse the target Sun Storage Appliance *
* Written By ABC                                   *
* 2 Feburary 2011                                          *
**********************************************************/

function deleteExistingProject(projectName, poolName)
{
printf("Making sure project: '" + projectName  + "' do not exist before on the standby appliance\n");

run ('cd /');
run ('shares');
run ('set pool=' + poolName);
try {
run ('select ' + projectName);
run ('confirm destroy');
} catch (err) {
printf("No Project to to delete.. \n");
}
}

function getSourcePackages(poolName, sourceId)
{
printf("Selecting the packages for source: " + sourceId + "\n");
run ('cd /');
run ('shares');
run ('set pool=' + poolName);
run('replication sources select ' + sourceId);
var packages = list();
return packages;
}

function roleReverseProject(projectName, poolName, sourceId)
{
deleteExistingProject(projectName, poolName);
var packages = getSourcePackages(poolName, sourceId);
for (var i = 0; i < packages.length; i++) {
run('select ' + packages[i]);
var projName = list();
if (projName == projectName) {
package = packages[i] ;
run('confirm reverse');
printf("Project Details after reversal \n");
run('show');
printf("Source and the target roles are reversed now..\n");
reverseReplication(projectName, poolName);
printf("Replication direction is reversed also\n");
break;
}//EOF if
run('cd ..');
}//EOF for
printf("The package chosen to role reverse : %s \n", package);
return package;
}

function reverseReplication(projectName, poolName)
{
run('cd /');
run('shares');
run('set pool=' + poolName);
run('select ' + projectName + ' replication');
run('select action-000');
run('set continuous=true');
run('commit');
}

roleReverseProject('SiteGuard','pool-0','source-000');

C Oracle Site Guardコマンドライン・インタフェース・リファレンス

Oracle Site Guardは、Enterprise Managerコマンドライン・インタフェース(EM CLI)を使用して、Site Guard構成をコマンドラインから直接管理するか、バッチ・プログラムまたはスクリプトから管理します。

注意:

EM CLIコマンドは大文字と小文字を区別するため、正しいEM CLI動詞を使用し、正しい入力を渡しているか確認してください。

この章では、Site Guardの構成に使用するすべてのEM CLI動詞を一覧表示します。

- add_siteguard_script_hosts

- create_operation_plan

- create_siteguard_configuration

- create_siteguard_credential_association

- create_siteguard_script

- delete_operation_plan

- delete_siteguard_configuration

- delete_siteguard_credential_association

- delete_siteguard_script

- delete_siteguard_script_hosts

- get_operation_plan_details

- get_operation_plans

- get_siteguard_configuration

- get_siteguard_credential_association

- get_siteguard_script_hosts

- get_siteguard_scripts

- run_prechecks

- submit_operation_plan

- update_operation_plan

- update_siteguard_configuration

- update_siteguard_credential_association

- update_siteguard_script

関連項目:

EM CLIの詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。

C.1 add_siteguard_script_hosts

ホストをSite Guard構成スクリプトに追加します。複数のホストを追加できます。

書式

emcli add_siteguard_script_hosts
-script_id="script_id"
-host_name="name1;name2;..."

パラメータ

説明

-script_id

スクリプトに関連付けられるID。

-host_name

スクリプトに関連付けるホスト。複数のホスト名を指定できます。

例C-1 ホストの追加

emcli add_siteguard_script_hosts
-script_id="10"
-host_name ="BIHOST1;BIHOST2"

C.2 create_operation_plan

Oracle Site Guard操作の操作計画を作成します。

書式

emcli create_operation_plan
-primary_system_name="name"
-standby_system_name="name"
-system_name="name"
-operation="name"
-name="name"
-role=""role"

パラメータ

説明

-primary_system_name

プライマリ・サイトに関連付けられるシステムの名前。スイッチオーバーまたはフェイルオーバー操作には、このオプションを入力します。

-standby_system_name

スタンバイ・サイトに関連付けられるシステムの名前。スイッチオーバーまたはフェイルオーバー操作には、このオプションを入力します。

-system_name

システムの名前。起動または停止操作には、このオプションを入力します。

-operation

操作の機能。例: switchover、failover、startまたはstop。

-name

操作計画の名前。

-role

操作(起動または停止)を実行する時に、システムに関連付けられるロール。

例C-2 操作計画の作成

emcli create_operation_plan
-primary_system_name="BISystem1"
-standby_system_name="BISystem2"
-operation="switchover"
-name="BISystem1-switchover-plan"
emcli create_operation_plan
-system_name="austin"
-operation="start"
-name="BISystem1-start-plan"
-role="Primary"

C.3 create_siteguard_configuration

Site Guardのサイト構成を作成します。システムおよびロールを関連付けます。

書式

emcli create_siteguard_configuration
-primary_system_name="name"
-standby_system_name="name1;name2;..."

パラメータ

説明

-primary_system_name

プライマリ・サイトに関連付けられるシステムの名前。

-standby_system_name

スタンバイ・システムに関連付けられるシステムの名前。複数のオプションおよび複数のシステム名を指定できます。

例C-3 Site Guard構成の作成

emcli create_siteguard_configuration
-primary_system_name="BISystem1"
-standby_system_name="BISystem2"

C.4 create_siteguard_credential_association

資格証明をサイト内のターゲットに関連付けます。

書式

emcli create_siteguard_credential_association
-system_name="name"
[-target_name="name"]
-credential_type="type"
-credential_name="name"
-credential_owner="owner"

[]は、オプションのパラメータであることを示します。

パラメータ

説明

-system_name

システムの名前。

-target_name

ターゲットの名前。このパラメータはオプションです。

-credential_type

資格証明のタイプ。例: HostNormal、HostPrivileged、WLSAdminまたはDatabaseSysdba。

-credential_name

資格証明の名前。

-credential_owner

資格証明の所有者。

例C-4 Site Guard資格証明アソシエーションの作成

emcli create_siteguard_credential_association
-system_name="BISystem1"
-credential_type="HostNormal"
-credential_name="HOST-SGCRED"
-credential_owner="sysman"

emcli create_siteguard_credential_association
-system_name="BIsystem1"
-target_name="database-instance"
-credential_type="HostNormal"
-credential_name="HOST-DBCRED"
-credential_owner="sysman"

C.5 create_siteguard_script

スクリプト(前処理スクリプト、後処理スクリプトおよびストレージ・スクリプト)をSiteGuard構成に関連付けます。

書式

emcli create_siteguard_script
-system_name="name"
-operation="name"
-script_type="type"
[-host_name=["name1;name2;..."]
-path="path"
[-all_hosts=["true or false"]
[-role=["role"]

パラメータ

説明

-system_name

システムの名前。

-operation

操作の名前。例: Switchover、Failover、StartまたはStop。

-script_type

スクリプトのタイプ。Mount、UnMount、Pre-Script、Post-Script、FailoverまたはSwitchoverを指定できます。

-host_name

このスクリプトを実行するホストの名前。

このパラメータはオプションで、2回以上指定できます。

-path

スクリプトのパス。

-all_hosts

スクリプトを、システム内のすべてのホストで実行できるようにするためのオプション・フラグ。このパラメータは、host_nameを無視します。例: trueまたはfalse。

-role

システム・ロールに基づいたスクリプトを構成するためのオプション・フラグ。デフォルトでは、スクリプトは、特定のシステムのプライマリ・ロールおよびスタンバイ・ロールの両方に対して構成されます。例: PrimaryまたはStandby。

例C-5 Site Guardスクリプトの作成

emcli create_siteguard_script
-system_name="BISystem1"
-operation="Switchover"
-script_type="Pre-Script"
-path="/tmp/prescript"
-all_hosts="true"
-role="Primary"

emcli create_siteguard_script
-system_name="BISystem1"
-operation="Switchover"
-script_type="Pre-Script"
-path="/tmp/prescript"
-host_name="BIHOST1"
-host_name="BIHOST2"

C.6 delete_operation_plan

Site Guard構成から指定された操作計画を削除します。

書式

emcli delete_operation_plan
-name="plan_name"

パラメータ

説明

-name

削除する操作計画の名前を指定します。

例C-6 操作計画の削除

emcli delete_operation_plan
-name="BISystem1-switchover"

C.7 delete_siteguard_configuration

Site Guard構成を削除します。指定されたシステムに関連する全体の構成(スクリプト、資格証明アソシエーション、サイト・アソシエーション、操作計画)および関連付けられているすべてのスタンバイ・システムは削除されます。

書式

emcli delete_siteguard_configuration
-primary_system_name="name"
-standby_system_name="name"

パラメータ

説明

-primary_system_name

プライマリ・システムの名前。primary_system_nameまたはstandby_system_nameのいずれかを指定します。

-standby_system_name

スタンバイ・システムの名前。

例C-7 Site Guard構成の削除

emcli delete_siteguard_configuartion
-primary_system_name="BISystem1"

emcli delete_siteguard_configuration
-standby_system_name="BISystem2"

C.8 delete_siteguard_credential_association

Site Guard構成から資格証明アソシエーションを削除します。

書式

emcli delete_siteguard_credential_association
-system_name="name"
[-target_name=["name"]
-credential_type="type"

パラメータ

説明

-system_name

サービスが置かれているシステムを指定します。

-credential_type

資格証明のタイプを指定します。HostNormal、HostPrivileged、WLSAdminまたはDatabaseSysdbaを指定できます。

-target_name

ターゲットの名前。このパラメータはオプションです。

例C-8 Site Guard資格証明アソシエーションの削除

emcli delete_siteguard_credential_association
-system_name="austin-system"
-credential_type="HostNormal"

emcli delete_siteguard_credential_association
-system_name="austin-system"
-target_name="austin-database-instance"
-credential_type="HostNormal"

C.9 delete_siteguard_script

Site Guard構成から指定されたスクリプトを削除します。

書式

emcli delete_siteguard_script
-script_id="script id"

パラメータ

説明

-script_id

スクリプトに関連付けられるID。

例C-9 Site Guardスクリプトの削除

emcli delete_siteguard_script
-script_id="10"

C.10 delete_siteguard_script_hosts

ホストまたは特定のスクリプトと関連付けられたホストを削除します。

書式

emcli delete_siteguard_script_hosts
-script_id="script id"
-host_name="name1;name2;..."

パラメータ

説明

-script_id

スクリプトに関連付けられるID。

-host_name

このスクリプトを実行するホストの名前。

このパラメータは、2回以上指定できます。

例C-10 Site Guardスクリプト・ホストの削除

emcli delete_siteguard_script_hosts
-script_id="10"
-host_name="BIHOST1"

C.11 get_operation_plan_details

指定された操作計画に関する手順ごとの詳細な情報を提供します。

書式

emcli get_operation_plan_details
-name="plan name"

パラメータ

説明

-name

操作計画の名前。

例C-11 操作計画の詳細の取得

emcli get_operation_plan_details
-name="BISystem1-switchover"

C.12 get_operation_plans

構成されたすべての操作計画を一覧表示します。

書式

emcli get_operation_plans
-name="operation plan_name"
-operation="operation_name"

パラメータ

説明

-name

操作計画の名前を指定します。

-operation

操作の名前を指定します。例: switchover、failover、startまたはstop。

例C-12 操作計画の取得

emcli get_operation_plans
-name="austin-switchover"
-operation="switchover"

C.13 get_siteguard_configuration

Site Guard構成を提供します。

書式

emcli get_siteguard_configuration
[-primary_system_name={name of the primary system}]
[-standby_system_name={name of the standby system}]

パラメータ

説明

-primary_system_name

プライマリ・システムの名前。このパラメータはオプションです。

-standby_system_name

スタンバイ・システムの名前。このパラメータはオプションです。

例C-13 Site Guard構成の取得

emcli get_siteguard_configuartion
-primary_system_name="BISystem1"
-standby_system_name="BISystem2"

C.14 get_siteguard_credential_association

システムに構成された資格証明アソシエーションを一覧表示します。

書式

emcli get_siteguard_credential_association
-system_name="name of the system"
[-target_name={name of the target}]
[-credential_type={type of the credential}]

パラメータ

説明

-system_name

システムの名前。

-target_name

ターゲットの名前。このパラメータはオプションです。

-credential_type

資格証明のタイプ。HostNormal、HostPrivileged、WLSAdminまたはDatabaseSysdbaを指定できます。

このパラメータはオプションです。

例C-14 Site Guard資格証明アソシエーションの取得

emcli get_siteguard_credential_association
-system_name="austin-system"
-credential_type="HostNormal"

emcli create_siteguard_credential_association
-system_name="austin-system"
-target_name="austin-database-instance"
-credential_type="HostNormal"

C.15 get_siteguard_script_hosts

スクリプトが実行されるように設計されたすべてのスクリプトに関連付けられたホストを一覧表示します。

書式

emcli get_siteguard_script_hosts
-script_id="script id"

パラメータ

説明

-script_id

スクリプトに関連付けられるID。

例C-15 Site Guardスクリプト・ホストの取得

emcli get_siteguard_script_hosts
-script_id="10"

C.16 get_siteguard_scripts

指定されたシステムに関連付けられたSite Guardスクリプトを取得します。

書式

emcli get_siteguard_scripts
-system_name="system_name"
-operation="operation_name"
[-script_type={type of the script}]
[-role={role of the system}]

パラメータ

説明

-system_name

システムの名前。

-operation

操作の名前。例: switchover、failover、startまたはstop。

-script_type

スクリプトのタイプ。例: mount、unmount、pre-script、post-script、failoverまたはswitchover。

-role

(プライマリ/スタンバイ)。システムに関連付けられたロールに基づいてスクリプトをフィルタ処理するオプションのパラメータ。例: PrimaryまたはStandby。

例C-16 Site Guardスクリプトの取得

emcli get_siteguard_scripts
-system_name="BISystem1"
-operation="Switchover"
-script_type="Pre-Script"

emcli get_siteguard_scripts
-system_name="austin-system"
-operation="Switchover"
-script_type="Pre-Script"
-role="Primary"

C.17 run_prechecks

特定の操作計画に対する事前チェック操作を送信します。

書式

emcli run_prechecks
-operation_plan="name_operation plan"

パラメータ

説明

-operation_plan

操作計画の名前。

Example C-17 事前チェックの実行

emcli run_prechecks
-operation_plan="BISystem1-switchover"

C.18 submit_operation_plan

指定された操作計画を送信して実行します。

書式

emcli submit_operation_plan
-name="name_operation plan"
[-run_prechecks={true/false}]

パラメータ

説明

-name

操作計画の名前。

-run_prechecks

事前チェックを実行します(trueまたはfalse)。このパラメータはオプションです。

例C-18 操作計画の送信

emcli submit_operation_plan
-name="austin-switchover"
-run_prechecks="true"

C.19 update_operation_plan

特定の操作計画の任意の手順で、エラー・モードおよび実行モードを更新します。

書式

emcli update_operation_plan
-name="operation plan_name"
[-step_number={step number}]
[-target_host={host name}]
[error_mode={error mode}]
[enabled={true/false}]

パラメータ

説明

-name

操作計画の名前。

-step_number

更新する必要のある手順の数。

-target_host

システムの名前。このオプションを入力して、操作を開始または停止します。

-error_mode

操作の機能。例: stopまたはcontinue。

-enabled

例C-19 操作計画の更新

emcli update_operation_plan
-name="austin-switchover"
-step_number="1"
-error_mode="Continue"
-enabled="true"

emcli update_operation_plan
-name="austin-switchover"
-target_host="myhost.domain.com"
-error_mode="Continue"
-enabled="true"

C.20 update_siteguard_configuration

Site Guard構成を更新して、スタンバイ・システムを追加します。1つのプライマリ・システムを、1つ以上のスタンバイ・システムに関連付けることができます。

書式

emcli update_siteguard_configuration
-primary_system_name="primary system_name"
-standby_system_name="standby system_name"

パラメータ

説明

-primary_system_name

プライマリ・システムの名前。

-standby_system_name

スタンバイ・システムの名前。このパラメータは、2回以上指定できます。

例C-20 Site Guard構成の更新

emcli update_siteguard_configuartion
-primary_system_name="BISystem1"
-standby_system_name="BISystem2"

注意:

サイト構成を更新する場合、「update_operation_plan」の説明に従って操作計画を更新する必要があります。

C.21 update_siteguard_credential_association

資格証明アソシエーションを更新します。

書式

emcli update_siteguard_credential_association
-system_name="name of the system"
[-target_name={name of the target}]
-credential_type="type of the credential"
-credential_name="name of the credential"
-credential_owner="credential owner"

パラメータ

説明

-system_name

システムの名前。

-target_name

ターゲットの名前。このパラメータはオプションです。

-credential_type

資格証明のタイプ。HostNormal、HostPrivileged、WLSAdminまたはDatabaseSysdbaを指定できます。

-credential_name

資格証明の名前。

-credential_owner

資格証明の所有者。

例C-21 Site Guard資格証明アソシエーションの更新

emcli create_siteguard_credential_association
-system_name="austin-system"
-credential_type="HostNormal"
-credential_name="HOST-SGCRED"
-credential_owner="sysman"

emcli create_siteguard_credential_association
-system_name="austin-system"
-target_name="austin-database-instance"
-credential_type="HostNormal"
-credential_name="HOST-DBCRED"
-credential_owner="sysman"

C.22 update_siteguard_script

任意のスクリプトに関連付けられたパスおよびall_hostsフラグを更新します。

書式

emcli update_siteguard_script
-script_id="ID associated with the script"
[-path={path of the script}]
[-all_hosts={flag to let script run on all the hosts in the system}]

パラメータ

説明

-script_id

スクリプトID。

-path

スクリプトのパス。

-all_hosts

スクリプトを、システム内のすべてのホストで実行できるようにするためのオプション・フラグ。例: trueまたはfalse。

例C-22 Site Guardスクリプトの更新

emcli update_siteguard_script
-script_id="10"
-path="/tmp/newprescript"
-all_hosts="true"

索引

A  C  D  E  F  G  H  I  K  L  M  N  O  P  R  S  T  V  W

A

ホスト名別名

定義, 1.1.2

データベース・ホストの設定, 3.3.3

アーキテクチャ

障害時リカバリ・ソリューション, 1.2.1

アーティファクト

すべてのOracle Identity Managementコンポーネントに共通, 2.5, 2.8, 2.9

すべてのOracle製品スイートに共通, 2

すべてのOracle WebCenterコンポーネントに共通, 2.3

すべてのSOA Suiteコンポーネントに共通, 2.4

Oracle Portal、Forms, Reports、およびDiscovererに共通, 2.6

Oracle WebLogic Serverに共通, 2.1

Oracle Fusion Middleware, 3.2.1

非対称スタンバイ・サイト

作成, 4.4

本番サイトより少数のホストおよびインスタンス, 4.4.1.1

非対称スタンバイ・サイトの設定

検証, 4.4.2

非対称トポロジ

作成, 4.4.1

定義, 1.1.2

設計上の考慮事項, 3.5.2

重複メッセージの回避

Oracle WebLogic Server JMSおよびトランザクション・ログ, 2.1.1

C

証明書

自己署名付き証明書, 4.1.4.1

すべてのOracle Identity Managementコンポーネントで共通のアーティファクト, 2.5, 2.8, 2.9 すべてのOracle製品スイートで共通のアーティファクト, 2 すべてのOracle WebCenterコンポーネントで共通のアーティファクト, 2.3 すべてのSOA Suiteコンポーネントで共通のアーティファクト, 2.4 Oracle Portal、Forms, Reports、およびDiscovererで共通のアーティファクト, 2.6 Oracle WebLogic Serverで共通のアーティファクト, 2.1 コンシステンシー・グループに関する推奨事項

Oracle Identity Management, 4.1.1.3.2

Oracle Portal、Forms、Reports、およびDiscoverer, 4.1.1.4, 4.1.1.4.2

Oracle SOA Suite, 4.1.1.1.2, 4.1.1.5.2, 4.1.1.6.2

Oracle WebCenter, 4.1.1.2.2

カスタム・キーストア

ノード・マネージャの構成, 4.1.4.4

D

データベース・アーティファクト

Oracle Access Manager, 2.5.6, 2.5.7, 2.5.8, 2.5.9

Oracle ADF, 2.2

Oracle B2B, 2.4.5

Oracle BPEL Process Manager, 2.4.2

Oracle Business Activity Monitoring, 2.4.9, 2.4.10

Oracle Business Intelligence Discoverer, 2.6.4

Oracle Directory Integration Platform, 2.5.3, 2.8.3

Oracle Directory Services Manager, 2.5.5, 2.8.5, 2.9.1, 2.9.2, 2.9.3

Oracle Forms, 2.6.2

Oracle HTTP Server, 2.7.1

Oracle Human Workflow, 2.4.4

Oracle Identity Federation, 2.5.4, 2.8.4

Oracle Identity Management, 2.5, 2.8, 2.9

Oracle Internet Directory, 2.5.1, 2.8.1

Oracle JCA Adapters, 2.4.8

Oracle Mediator, 2.4.3

Oracle Platform Security Services, 2.1.2

Oracle Portal, 2.6.1

Oracle Portal、Forms、Reports、およびDiscoverer, 2.6

Oracle Reports、2.6.3

Oracle SOA Service Infrastructure, 2.4.1

Oracle SOA Suite, 2.4

Oracle User Messaging Service, 2.4.7

Oracle Virtual Directory, 2.5.2, 2.8.2

Oracle Web Cache、2.7.2

Oracle Web Services Manager, 2.4.6

Oracle WebCenter, 2.3

Oracle WebCenter Discussions Server, 2.3.3

Oracle WebCenter Portlets, 2.3.2

Oracle WebCenter Spaces, 2.3.1

Oracle WebCenter Wiki and Blog Server, 2.3.4

Oracle WebLogic Server JMSおよびトランザクション・ログ, 2.1.1

データベースの考慮事項, 3.3 データベースに関する推奨事項, 4.1.3 データベース

Oracle Data Guardとの手動の強制同期, 3.3.2

TNSNAMES.ORAエントリの作成, 3.3.1

データベース・ホストのホスト名別名の設定, 3.3.3

障害時リカバリの用語の定義, 1.1.2 設計上の考慮事項

対称トポロジ, 3.5.1

非対称トポロジ, 3.5.2

設計

障害時リカバリ・トポロジ、新しい本番サイトの作成, 3.4.2

障害時リカバリ・トポロジ、 既存のサイトの一部を使用, 3.4

障害時リカバリ・トポロジ、 既存の本番サイトを使用, 3.4.1

対称障害時リカバリ・トポロジ, 3

ディレクトリ構造

障害時リカバリ・サイト, 4.1.1

ディレクトリ構造に関する推奨事項

Oracle Identity Management, 4.1.1.3

Oracle SOA Suite, 4.1.1.1, 4.1.1.5, 4.1.1.6

Oracle WebCenter, 4.1.1.2

障害

定義, 1.1.2

障害時リカバリ

アクティブ本番サイト, 1.2.1

アクティブ/パッシブ・モデル, 1.1.1, 1.2.1

共有ストレージへのマウント・ポイントの作成, 1.2.1

定義, 1.1.2

共有ストレージへのコンポーネントのデプロイ, 1.2.1

対称トポロジの設計に関する考慮事項, 3

新規本番サイトの作成によるトポロジの設計, 3.4.2

既存のサイトの一部からのトポロジの設計, 3.4

既存の本番サイトからのトポロジの設計, 3.4.1

サイトのディレクトリ構造とボリューム設計, 4.1.1

DNSサーバー解決, 3.1.1.1

サード・パーティのデータベース, 1.2.1

データベースの手動の強制同期, 3.3.2

中間層の手動の強制同期, 4.5.1

主要な側面, 1.2.1, 5.2.3

ローカル・ホスト名解決, 3.1.1.1, 3.1.1.2

概要, 1.1

アーキテクチャの概要, 1.2.1

パッシブ・スタンバイ・サイト, 1.2.1

サイト管理の実行, 4.5

サイト操作の実行, 4.5

問題の解決手段, 1.1.1

Oracle Databaseの保護, 1.2.1

Oracle Fusion Middleware製品バイナリ、構成、およびメタデータ・ファイルの保護, 1.2.1

サード・パーティ・データベースの保護, 1.2.1

サイトの設定, 4.1

サイトの設定および管理, 4

サイトの設定の開始ポイント, 3.4

サイトの同期, 4.5.1

用語, 1.1.2

ホスト名解決のテスト, 3.1.1.5

Oracle Data Guardの使用, 1.1.1

ストレージ・レプリケーション・テクノロジの使用, 1.1.1

グローバル・ロード・バランサの使用, 3.1.5.1

ホスト名解決における/etc/hostsファイルの使用, 3.1.1.2

テスト環境でのpeer-to-peerのファイル・コピーの使用, 4.5.6

障害時リカバリに関する推奨事項

Oracle Access Manager, 2.5.6, 2.5.7, 2.5.8, 2.5.9

Oracle ADF, 2.2

Oracle B2B, 2.4.5

Oracle BPEL Process Manager, 2.4.2

Oracle Business Activity Monitoring, 2.4.9, 2.4.10

Oracle Business Intelligence Discoverer, 2.6.4

Oracle Directory Integration Platform, 2.5.3, 2.8.3

Oracle Directory Services Manager, 2.5.5, 2.8.5

Oracle Forms, 2.6.2

Oracle HTTP Server, 2.7.1

Oracle Human Workflow, 2.4.4

Oracle Identity Federation, 2.5.4, 2.8.4

Oracle Identity Management, 2.5, 2.8

Oracle Internet Directory, 2.5.1, 2.8.1

Oracle JCA Adapters, 2.4.8

Oracle Mediator, 2.4.3

Oracle Platform Security Services, 2.1.2

Oracle Portal, 2.6.1

Oracle Portal、Forms、Reports、およびDiscoverer, 2.6

Oracle Reports、2.6.3

Oracle SOA Service Infrastructure, 2.4.1

Oracle SOA Suite, 2.4

Oracle User Messaging Service, 2.4.7

Oracle Virtual Directory, 2.5.2, 2.8.2

Oracle Web Cache、2.7.2

Oracle Web Services Manager, 2.4.6

Oracle WebCenter, 2.3

Oracle WebCenter Discussions Server, 2.3.3

Oracle WebCenter Portlets, 2.3.2

Oracle WebCenter Spaces, 2.3.1

Oracle WebCenter Wiki and Blog Server, 2.3.4

Oracle WebLogic Server JMSおよびトランザクション・ログ, 2.1.1

DNS

グローバルDNSサーバーを使用したホスト名の解決, 3.1.1.4

個別のDNSサーバーを使用したホスト名の解決, 3.1.1.3

DNSスイッチオーバー

ホスト名とIPのマッピングの手動の変更による実行, 3.1.5.2

グローバル・ロード・バランサを使用した実行, 3.1.5.1

動的またはランタイム・アーティファクト

Oracle Fusion Middleware, 3.2.1

E

エンタープライズ・デプロイメント・ガイド

取得、Oracle Portal、Forms、Reports、およびDiscoverer用, 4.1.1.4, 4.1.1.4, 4.2.6, 4.2.6, 6.1.2

/etc/hostsファイル

ローカル・ホスト名解決での使用, 3.1.1.1

F

フェイルオーバー

定義, 1.1.2

実行手順, 4.5.4

ファイル・システム・アーティファクト

Oracle ADF, 2.2

Oracle B2B, 2.4.5

Oracle HTTP Server, 2.7.1

Oracle Identity Management, 2.5, 2.8, 2.8.1, 2.8.3, 2.9

Oracle JCA Adapters, 2.4.8

Oracle Portal、Forms、Reports、およびDiscoverer, 2.6

Oracle Reports、2.6.3

Oracle SOA Suite, 2.4

Oracle User Messaging Service, 2.4.7

Oracle Web Cache、2.7.2

Oracle WebCenter, 2.3

Oracle WebLogic Server, 2.1

Oracle WebLogic Server JMSおよびトランザクション・ログ, 2.1.1

ファイルベースの永続ストア, 3.2.4

G

グローバルDNSサーバー

ホスト名解決での使用, 3.1.1.4

グローバル・ロード・バランサ

障害時リカバリ・トポロジでの使用, 3.1.5.1

H

ホスト名

計画, 3.1.1

ホスト名解決

プリファレンスの決定, 3.1.1.1

nsswitch.confファイルで定義される優先順位, 3.1.1.1

テスト, 3.1.1.5

ローカル・ホスト名解決における/etc/hostsファイルの使用, 3.1.1.2

DNSサーバー解決の使用, 3.1.1.1

グローバルDNSサーバー解決の使用, 3.1.1.4

ローカル・ホスト名解決の使用, 3.1.1.1, 3.1.1.2

pingコマンドを使用したテスト, 3.1.1.5

個別のDNSサーバー解決の使用, 3.1.1.3

ホスト名

本番およびスタンバイ・サイトの計画, 3.1.1

I

IDキーストア

作成, 4.1.4.2

K

キーストア

カスタム・キーストアを使用するためのノード・マネージャの構成, 4.1.4.4

トラスト・キーストアの作成, 4.1.4.3

IDキーストアの作成, 4.1.4.2

L

LDAPストア

Oracle Access Manager, 2.5.6, 2.5.7, 2.5.8, 2.5.9

ロード・バランサに関する考慮事項, 3.1.3 LockFileディレクティブ

Oracle HTTP Serverのパフォーマンスの問題を修正する変更, 2.7.1

M

マウント・ポイント

共有ストレージの場所, 1.2.1

N

ネットワーク・アーティファクト

Oracle ADF, 2.2

Oracle SOA Suiteコンポーネント, 2.4

Oracle WebCenterコンポーネント, 2.3

Oracle Identity Management, 2.5, 2.8, 2.9

Oracle Portal、Forms、Reports、およびDiscoverer, 2.6

Oracle WebLogic Server, 2.1

ノード・マネージャ

カスタム・キーストアを使用するための構成, 4.1.4.4

スタンバイ・サイト上での設定, 4.1.4

nsswitch.confファイル

ホスト名解決の優先順位の指定, 3.1.1.1

O

Oracle Access Manager

データベース・アーティファクト, 2.5.6, 2.5.7, 2.5.8, 2.5.9

障害時リカバリに関する推奨事項, 2.5.6, 2.5.7, 2.5.8, 2.5.9

LDAPストア, 2.5.6, 2.5.7, 2.5.8, 2.5.9

リカバリに関する推奨事項, 2.5.6, 2.5.7, 2.5.8, 2.5.9

特別な考慮事項, 2.5.7, 2.5.8

同期に関する推奨事項, 2.5.6, 2.5.7, 2.5.8, 2.5.9

Oracle ADF

データベース・アーティファクト, 2.2

障害時リカバリに関する推奨事項, 2.2

ファイル・システム・アーティファクト, 2.2

ネットワーク・アーティファクト, 2.2

リカバリに関する推奨事項, 2.2

同期に関する推奨事項, 2.2

Oracle B2B

データベース・アーティファクト, 2.4.5

障害時リカバリに関する推奨事項, 2.4.5

ファイル・システム・アーティファクト, 2.4.5

リカバリに関する推奨事項, 2.4.5

特別な考慮事項, 2.4.5

同期に関する推奨事項, 2.4.5

Oracle BPEL Process Manager

データベース・アーティファクト, 2.4.2

障害時リカバリに関する推奨事項, 2.4.2

リカバリに関する推奨事項, 2.4.2

同期に関する推奨事項, 2.4.2

Oracle Business Activity Monitoring

データベース・アーティファクト, 2.4.9, 2.4.10

障害時リカバリに関する推奨事項, 2.4.9, 2.4.10

リカバリに関する推奨事項, 2.4.9, 2.4.10

同期に関する推奨事項, 2.4.9, 2.4.10

Oracle Business Intelligence Discoverer

データベース・アーティファクト, 2.6.4

障害時リカバリに関する推奨事項, 2.6.4

リカバリに関する推奨事項, 2.6.4

特別な考慮事項, 2.6.4

同期に関する推奨事項, 2.6.4

Oracle Data Guard

スタンバイ・サイト上でのOracle Net Servicesの構成, 4.1.3.1.4

スタンバイ・サイト上でのインスタンスおよびデータベースの作成, 4.1.3.1.5

環境変数, 4.1.3.1.2

ファイルの収集とデータベースのバックアップの実行, 4.1.3.1.3

セットアップ, 4.1.3.1

前提条件および仮定の設定, 4.1.3.1.1

データベースのスイッチオーバーおよびスイッチバックのテスト, 4.1.3.1.6

データベースの手動の強制同期での使用, 3.3.2

Oracle Databaseの保護での使用, 1.1.1

Oracle Directory Integration Platform

データベース・アーティファクト, 2.5.3, 2.8.3

障害時リカバリに関する推奨事項, 2.5.3, 2.8.3

リカバリに関する推奨事項, 2.5.3, 2.8.3

同期に関する推奨事項, 2.5.3, 2.8.3

Oracle Directory Services Manager

データベース・アーティファクト, 2.5.5, 2.8.5, 2.9.1, 2.9.2, 2.9.3

障害時リカバリに関する推奨事項, 2.5.5, 2.8.5

リカバリに関する推奨事項, 2.5.5, 2.8.5, 2.9.1, 2.9.2, 2.9.3

特別な考慮事項, 2.5.5, 2.8.5, 2.9.1, 2.9.2, 2.9.3

同期に関する推奨事項, 2.5.5, 2.8.5, 2.9.1, 2.9.2, 2.9.3

Oracle Forms

データベース・アーティファクト, 2.6.2

障害時リカバリに関する推奨事項, 2.6.2

リカバリに関する推奨事項, 2.6.2

特別な考慮事項, 2.6.2

同期に関する推奨事項, 2.6.2

Oracle Fusion Middleware

アーティファクト, 3.2.1

動的またはランタイム・アーティファクト, 3.2.1

OracleホームおよびOracleインベントリ, 3.2.2

製品バイナリ、構成、およびメタデータ・ファイルの保護, 1.2.1

静的アーティファクト, 3.2.1

OracleホームおよびOracleインベントリ

Oracle Fusion Middleware, 3.2.2

Oracle HTTP Server

データベース・アーティファクト, 2.7.1

障害時リカバリに関する推奨事項, 2.7.1

ファイル・システム・アーティファクト, 2.7.1

リカバリに関する推奨事項, 2.7.1

特別な考慮事項, 2.7.1

同期に関する推奨事項, 2.7.1

Oracle HTTP Serverのパフォーマンスの問題

LockFileディレクティブの変更による修正, 2.7.1

Oracle Human Workflow

データベース・アーティファクト, 2.4.4

障害時リカバリに関する推奨事項, 2.4.4

リカバリに関する推奨事項, 2.4.4

同期の考慮事項, 2.4.4

Oracle Identity Federation

データベース・アーティファクト, 2.5.4, 2.8.4

障害時リカバリに関する推奨事項, 2.5.4, 2.8.4

リカバリに関する推奨事項, 2.5.4, 2.8.4

特別な考慮事項, 2.5.4, 2.8.4

同期に関する推奨事項, 2.5.4, 2.8.4

Oracle Identity Management

コンシステンシー・グループに関する推奨事項, 4.1.1.3.2

データベース・アーティファクト, 2.5, 2.8, 2.9

ディレクトリ構造に関する推奨事項, 4.1.1.3

障害時リカバリに関する推奨事項, 2.5, 2.8

ファイル・システム・アーティファクト, 2.5, 2.8, 2.8.1, 2.8.3, 2.9

ネットワーク・アーティファクト, 2.5, 2.8, 2.9

リカバリに関する推奨事項, 2.5, 2.8, 2.9

同期に関する推奨事項, 2.5, 2.8, 2.9

仮想サーバー, 3.1.4, 3.1.4

ボリューム設計に関する推奨事項, 4.1.1.3.1

Oracle Internet Directory

データベース・アーティファクト, 2.5.1, 2.8.1

障害時リカバリに関する推奨事項, 2.5.1, 2.8.1

リカバリに関する推奨事項, 2.5.1, 2.8.1

特別な考慮事項, 2.5.1, 2.8.1

同期に関する推奨事項, 2.5.1, 2.8.1

Oracle JCA Adapters

データベース・アーティファクト, 2.4.8

障害時リカバリに関する推奨事項, 2.4.8

ファイル・システム・アーティファクト, 2.4.8

リカバリに関する推奨事項, 2.4.8

同期に関する推奨事項, 2.4.8

Oracle Mediator

データベース・アーティファクト, 2.4.3

障害時リカバリに関する推奨事項, 2.4.3

リカバリに関する推奨事項, 2.4.3

同期に関する推奨事項, 2.4.3

Oracle Platform Security Services

データベース・アーティファクト, 2.1.2

障害時リカバリに関する推奨事項, 2.1.2

リカバリに関する推奨事項, 2.1.2

同期に関する推奨事項, 2.1.2

Oracle Portal

データベース・アーティファクト, 2.6.1

障害時リカバリに関する推奨事項, 2.6.1

リカバリに関する推奨事項, 2.6.1

特別な考慮事項, 2.6.1

同期に関する推奨事項, 2.6.1

Oracle Portal、Forms、Reports、およびDiscoverer

コンシステンシー・グループに関する推奨事項, 4.1.1.4.2

データベース・アーティファクト, 2.6

ディレクトリ構造に関する推奨事項, 4.1.1.4

障害時リカバリに関する推奨事項, 2.6

ファイル・システム・アーティファクト, 2.6

ネットワーク・アーティファクト, 2.6

エンタープライズ・デプロイメント・ガイドの取得, 4.1.1.4, 4.1.1.4, 4.2.6, 4.2.6, 6.1.2

リカバリに関する推奨事項, 2.6

同期に関する推奨事項, 2.6

仮想サーバー, 3.1.4

ボリューム設計に関する推奨事項, 4.1.1.4.1

Oracle Reports

データベース・アーティファクト, 2.6.3

障害時リカバリに関する推奨事項, 2.6.3

ファイル・システム・アーティファクト, 2.6.3

リカバリに関する推奨事項, 2.6.3

特別な考慮事項, 2.6.3

同期に関する推奨事項, 2.6.3

Oracle SOA Service Infrastructure

データベース・アーティファクト, 2.4.1

障害時リカバリに関する推奨事項, 2.4.1

リカバリに関する推奨事項, 2.4.1

同期に関する推奨事項, 2.4.1

Oracle SOA Suite

コンシステンシー・グループに関する推奨事項, 4.1.1.1.2, 4.1.1.5.2, 4.1.1.6.2

データベース・アーティファクト, 2.4

ディレクトリ構造に関する推奨事項, 4.1.1.1, 4.1.1.5, 4.1.1.6

障害時リカバリに関する推奨事項, 2.4

ファイル・システム・アーティファクト, 2.4

ネットワーク・アーティファクト, 2.4

リカバリに関する推奨事項, 2.4

同期に関する推奨事項, 2.4

仮想サーバー, 3.1.4, 3.1.4, 3.1.4, 3.1.4, 3.1.4, 3.1.4

ボリューム設計に関する推奨事項, 4.1.1.1.1, 4.1.1.5.1, 4.1.1.6.1

Oracle User Messaging Service

データベース・アーティファクト, 2.4.7

障害時リカバリに関する推奨事項, 2.4.7

ファイル・システム・アーティファクト, 2.4.7

リカバリに関する推奨事項, 2.4.7

特別な考慮事項, 2.4.7

同期に関する推奨事項, 2.4.7

Oracle Virtual Directory

データベース・アーティファクト, 2.5.2, 2.8.2

障害時リカバリに関する推奨事項, 2.5.2, 2.8.2

リカバリに関する推奨事項, 2.5.2, 2.8.2

特別な考慮事項, 2.5.2, 2.8.2

同期に関する推奨事項, 2.5.2, 2.8.2

Oracle Web Cache

データベース・アーティファクト, 2.7.2

障害時リカバリに関する推奨事項, 2.7.2

ファイル・システム・アーティファクト, 2.7.2

リカバリに関する推奨事項, 2.7.2

特別な考慮事項, 2.7.2

同期に関する推奨事項, 2.7.2

Oracle Web Services Manager

データベース・アーティファクト, 2.4.6

障害時リカバリに関する推奨事項, 2.4.6

リカバリに関する推奨事項, 2.4.6

同期に関する推奨事項, 2.4.6

Oracle WebCenter

すべてのコンポーネントで共通のアーティファクトおよび考慮事項, 2.3

コンシステンシー・グループに関する推奨事項, 4.1.1.2.2

データベース・アーティファクト, 2.3

ディレクトリ構造に関する推奨事項, 4.1.1.2

障害時リカバリに関する推奨事項, 2.3

ファイル・システム・アーティファクト, 2.3

ネットワーク・アーティファクト, 2.3

リカバリに関する推奨事項, 2.3

同期に関する推奨事項, 2.3

仮想サーバー, 3.1.4, 3.1.4, 3.1.4

ボリューム設計に関する推奨事項, 4.1.1.2.1

Oracle WebCenter Analytics

バックアップとリカバリの推奨事項, 2.3.5

Oracle WebCenter Discussions Server

データベース・アーティファクト, 2.3.3

障害時リカバリに関する推奨事項, 2.3.3

リカバリに関する推奨事項, 2.3.3

同期に関する推奨事項, 2.3.3

Oracle WebCenter Portlets

データベース・アーティファクト, 2.3.2

障害時リカバリに関する推奨事項, 2.3.2

リカバリに関する推奨事項, 2.3.2

同期に関する推奨事項, 2.3.2

Oracle WebCenter Spaces

データベース・アーティファクト, 2.3.1

障害時リカバリに関する推奨事項, 2.3.1

リカバリに関する推奨事項, 2.3.1

同期に関する推奨事項, 2.3.1

Oracle WebCenter Wiki and Blog Server

バックアップとリカバリの推奨事項, 2.3.6

データベース・アーティファクト, 2.3.4

障害時リカバリに関する推奨事項, 2.3.4

リカバリに関する推奨事項, 2.3.4

同期に関する推奨事項, 2.3.4

Oracle WebLogic Server

ファイル・システム・アーティファクト, 2.1

ネットワーク・アーティファクト, 2.1

Oracle WebLogic Server JMSおよびトランザクション・ログ

重複メッセージの回避, 2.1.1

データベース・アーティファクト, 2.1.1

障害時リカバリに関する推奨事項, 2.1.1

ファイル・システム・アーティファクト, 2.1.1

リカバリに関する推奨事項, 2.1.1

特別な考慮事項, 2.1.1

同期に関する推奨事項, 2.1.1

P

パッチ・セット

障害時リカバリ・トポロジでのOracle Fusion Middlewareホームへの適用方法, 4.6

物理ホスト名

定義, 1.1.2

pingコマンド

ホスト名解決のテストでの使用, 3.1.1.5

本番サイト

作成, 4.2

Oracle Identity Managementトポロジでの作成, 4.2.2

Oracle Portal、Forms、Reports、およびDiscovererトポロジでの作成, 4.2.6

Oracle SOA Suiteトポロジでの作成, 4.2.1

Oracle WebCenterトポロジでの作成, 4.2.3, 4.2.4, 4.2.5

本番サイトの設定

定義, 1.1.2

R

リカバリに関する推奨事項

Oracle Access Manager, 2.5.6, 2.5.7, 2.5.8, 2.5.9

Oracle ADF, 2.2

Oracle B2B, 2.4.5

Oracle BPEL Process Manager, 2.4.2

Oracle Business Activity Monitoring, 2.4.9, 2.4.10

Oracle Business Intelligence Discoverer, 2.6.4

Oracle Directory Integration Platform, 2.5.3, 2.8.3

Oracle Directory Services Manager, 2.5.5, 2.8.5, 2.9.1, 2.9.2, 2.9.3

Oracle Forms, 2.6.2

Oracle HTTP Server, 2.7.1

Oracle Human Workflow, 2.4.4

Oracle Identity Federation, 2.5.4, 2.8.4

Oracle Identity Management, 2.5, 2.8, 2.9

Oracle Internet Directory, 2.5.1, 2.8.1

Oracle JCA Adapters, 2.4.8

Oracle Mediator, 2.4.3

Oracle Platform Security Services, 2.1.2

Oracle Portal, 2.6.1

Oracle Portal、Forms、Reports、およびDiscoverer, 2.6

Oracle Reports、2.6.3

Oracle SOA Service Infrastructure, 2.4.1

Oracle SOA Suite, 2.4

Oracle User Messaging Service, 2.4.7

Oracle Virtual Directory, 2.5.2, 2.8.2

Oracle Web Cache、2.7.2

Oracle Web Services Manager, 2.4.6

Oracle WebCenter, 2.3

Oracle WebCenter Discussions Server, 2.3.3

Oracle WebCenter Portlets, 2.3.2

Oracle WebCenter Spaces, 2.3.1

Oracle WebCenter Wiki and Blog Server, 2.3.4

Oracle WebLogic Server JMSおよびトランザクション・ログ, 2.1.1

S

自己署名付き証明書

生成, 4.1.4.1

個別のDNSサーバー

ホスト名解決での使用, 3.1.1.3

共有ストレージ

マウント・ポイントの作成, 1.2.1

Oracleホーム・ディレクトリの作成, 1.2.1

サイトのフェイルオーバー

定義, 1.1.2

実行手順, 4.5.4

サイトのスイッチバック

定義, 1.1.2

実行手順, 4.5.3

サイトのスイッチオーバー

定義, 1.1.2

実行手順, 4.5.2

サイトの同期

定義, 1.1.2

SOA Suite

すべてのコンポーネントで共通のアーティファクトおよび考慮事項, 2.4

特別な考慮事項

Oracle Access Manager, 2.5.7, 2.5.8

Oracle B2B, 2.4.5

Oracle Business Intelligence Discoverer, 2.6.4

Oracle Directory Services Manager, 2.5.5, 2.8.5, 2.9.1, 2.9.2, 2.9.3

Oracle Forms, 2.6.2

Oracle HTTP Server, 2.7.1

Oracle Identity Federation, 2.5.4, 2.8.4

Oracle Internet Directory, 2.5.1, 2.8.1

Oracle Portal, 2.6.1

Oracle Reports、2.6.3

Oracle User Messaging Service, 2.4.7

Oracle Virtual Directory, 2.5.2, 2.8.2

Oracle Web Cache、2.7.2

Oracle WebLogic Server JMSおよびトランザクション・ログ, 2.1.1

スタンバイ・サイト

作成, 4.3

データベースの設定, 4.3.1.1

中間層の設定, 4.3.1.2

定期テストの実行, 4.5.5, 4.5.5

前提条件, 4.3.1

ノード・マネージャの設定, 4.1.4

設定の検証, 4.3.2

スタンバイ・サイトの設定

定義, 1.1.2

静的アーティファクト

Oracle Fusion Middleware, 3.2.1

ストレージの考慮事項, 3.2 ストレージ・レプリケーション, 3.2.3, 4.1.2 ストレージ・レプリケーション・テクノロジ

Oracle Fusion Middleware中間層コンポーネントの保護での使用, 1.1.1

スイッチバック

定義, 1.1.2

実行手順, 4.5.3

スイッチオーバー

定義, 1.1.2

実行手順, 4.5.2

シンボリック・リンク

共有ストレージ上のOracleホーム・ディレクトリ, 1.2.1, 1.2.1

対称トポロジ

定義, 1.1.2

設計上の考慮事項, 3.5.1

設計上の考慮事項, 3

ディレクトリ名およびパスの要件, 3

インストールするソフトウェアの要件, 3

ロード・バランサおよび仮想サーバー名の要件, 3

ポート番号の要件, 3

セキュリティの要件, 3

同期

中間層の構成変更後の手動の強制実行, 4.5.1

データベースに対する中間層の構成変更後の手動の強制実行, 3.3.2

本番サイトとスタンバイ・サイト, 4.5.1

同期の考慮事項

Oracle Human Workflow, 2.4.4

同期に関する推奨事項

Oracle Access Manager, 2.5.6, 2.5.7, 2.5.8, 2.5.9

Oracle ADF, 2.2

Oracle B2B, 2.4.5

Oracle BPEL Process Manager, 2.4.2

Oracle Business Activity Monitoring, 2.4.9, 2.4.10

Oracle Business Intelligence Discoverer, 2.6.4

Oracle Directory Integration Platform, 2.5.3, 2.8.3

Oracle Directory Services Manager, 2.5.5, 2.8.5, 2.9.1, 2.9.2, 2.9.3

Oracle Forms, 2.6.2

Oracle HTTP Server, 2.7.1

Oracle Identity Federation, 2.5.4, 2.8.4

Oracle Identity Management, 2.5, 2.8, 2.9

Oracle Internet Directory, 2.5.1, 2.8.1

Oracle JCA Adapters, 2.4.8

Oracle Mediator, 2.4.3

Oracle Platform Security Services, 2.1.2

Oracle Portal, 2.6.1

Oracle Portal、Forms、Reports、およびDiscoverer, 2.6

Oracle Reports、2.6.3

Oracle SOA Service Infrastructure, 2.4.1

Oracle SOA Suite, 2.4

Oracle User Messaging Service, 2.4.7

Oracle Virtual Directory, 2.5.2, 2.8.2

Oracle Web Cache、2.7.2

Oracle Web Services Manager, 2.4.6

Oracle WebCenter, 2.3

Oracle WebCenter Discussions Server, 2.3.3

Oracle WebCenter Portlets, 2.3.2

Oracle WebCenter Spaces, 2.3.1

Oracle WebCenter Wiki and Blog Server, 2.3.4

Oracle WebLogic Server JMSおよびトランザクション・ログ, 2.1.1

T

テスト

スタンバイ・サイト, 4.5.5

サード・パーティ・データベース

障害時リカバリ, 1.2.1

TNSNAMES.ORAエントリ

データベース用に作成, 3.3.1

トポロジ

定義, 1.1.2

トラスト・キーストア

作成, 4.1.4.3

TTL(存続時間)の値, 3.1.5.2

V

検証

非対称スタンバイ・サイトの設定, 4.4.2

本番サイトの設定

本番サイト, 4.2.7

スタンバイ・サイトの設定, 4.3.2 仮想IPの考慮事項, 3.1.3 仮想サーバー

Oracle Identity Management, 3.1.4, 3.1.4

Oracle Portal、Forms、Reports、およびDiscoverer, 3.1.4

Oracle SOA Suite, 3.1.4, 3.1.4, 3.1.4, 3.1.4, 3.1.4, 3.1.4

Oracle WebCenter, 3.1.4, 3.1.4, 3.1.4

ボリューム設計

障害時リカバリ・サイト, 4.1.1

ボリューム設計に関する推奨事項

Oracle Identity Management, 4.1.1.3.1

Oracle Portal、Forms、Reports、およびDiscoverer, 4.1.1.4.1

Oracle SOA Suite, 4.1.1.1.1, 4.1.1.5.1, 4.1.1.6.1

Oracle WebCenter, 4.1.1.2.1

W

ワイド・エリアDNSの操作, 3.1.5

Copyright © 2009, 2012, Oracle and/or its affiliates. All rights reserved.