| Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド 12c (12.2.1.2) E82708-02 |
|
 前 |
 次 |
Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジについて確認し、本番サイトおよびスタンバイ・サイトを設定する方法について確認します。
注意:
スイッチオーバーやフェイルオーバーなどの障害時リカバリ操作は、Oracle Site Guardを使用して自動化できます。『Oracle Site Guard管理者ガイド』を参照してください。
この章の内容は次のとおりです。
Oracle障害時リカバリ・サイトを設定する方法を確認します。
本番サイトの作成を開始する前に、次の点を確認します。
「ホスト名の計画」の説明に従って、中間層ホストのホスト名別名を設定します。
「ディレクトリ構造とボリュームの設計」の説明に従って、本番サイトの共有ストレージに必要なボリュームを作成します
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定します。
この項には次のトピックが含まれます:
障害時リカバリ・トポロジで推奨されるディレクトリ構造について確認します。
このドキュメントで推奨されるディレクトリ・レイアウトと異なるものを選択できますが、採用されているモデルを使用すると、コンポーネントが最適に分離され、構成における対称性が保たれるとともに、バックアップと障害時リカバリが容易になり、最大限の可用性が実現されます。
次の一覧では、ディレクトリとディレクトリ環境変数について説明します。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを表します。
ORACLE_HOME: この関連ディレクトリ・パスは、Oracle Fusion Middlewareが存在する場所を指します。
WL_HOME: この環境変数と関連ディレクトリ・パスには、Oracle WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。
PROD_DIR: この環境変数および関連するディレクトリ・パスは、製品スイート(Oracle SOA Suite、Oracle WebCenter Portal、Oracle Identity Managementなど)がインストールされている場所を表します。
DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogic Domain情報(構成アーティファクト)が保存されている場所を表します。各種のWebLogic Serverは、同じノード内にある場合でも異なるドメイン・ディレクトリを使用できます。
ORACLE_INSTANCE: Oracleインスタンスには、1つ以上のシステム・コンポーネントが含まれます。Oracleインスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。
「Oracle SOA Suiteに推奨されるディレクトリ構造」を参照してください。
この項には次のトピックが含まれます:
Oracle SOA Suiteに推奨されるディレクトリ構造について確認します。
Oracle Fusion Middlewareでは、単一のバイナリ・インストールから複数のSOA管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリ・ファイルをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのOracleホーム(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがある)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。複数のボリュームによって実現する保護はこれによって保証されませんが、ユーザーによる削除や個々のファイルの破損から保護できます。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムへの配置もサポートされていますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-1は、Oracle SOA Suiteのディレクトリ構造のレイアウトを示しています。
このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
ボリューム設計の詳細は、次の項を参照してください。
Oracle SOA Suiteに推奨されるボリューム設計について確認します。
図4-2および図4-3は、Oracle SOA Suiteのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle SOA Suiteトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
図4-2 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジのダイアグラム
図4-3 Oracle SOA SuiteおよびOracle Service Busエンタープライズ・デプロイメント参照用トポロジのダイアグラム
このOracle SOA Suiteトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。
製品の冗長バイナリ・ファイルを格納する2つのOracleホーム用にボリュームを2つプロビジョニングします(表4-1のVOLFMW1およびVOLFMW2)。
管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-1のVOLADMIN)。
管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-1のVOLSOA1およびVOLSOA2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。
JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-1のVOLDATA)。ドメイン全体で1つのボリュームが、ドメインのすべてのノードでマウントされます。
Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-1のVOLWEB1およびVOLWEB2)。
Oracle HTTP Serverのドメイン・ホーム用に各ノードでボリュームを1つプロビジョニングします(表4-1のVOLOHS1およびVOLOHS2)。
注意:
Web層のホストには、通常、ローカル・ストレージが推奨されます。この構成を定期的に他のアプリケーション層のボリュームにレプリケートして、スタンバイに同期したり、本番WebホストからスタンバイWebホストに直接同期することができます。表4-1に、図4-2および図4-3に示されているOracle SOA Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。
表4-1 Oracle SOA Suiteのボリューム設計に関する推奨事項
| 層 | ボリューム名 | マウントされるホスト | マウント・ポイント | 備考 |
|---|---|---|---|---|
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverのドメイン・ディレクトリのボリューム |
Web |
|
|
|
Oracle HTTP Serverのドメイン・ディレクトリのボリューム |
Web |
|
|
|
(オプション)静的HTMLコンテンツ用のボリューム |
Web |
|
|
|
(オプション)静的HTMLコンテンツ用のボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
管理サーバーのドメイン・ディレクトリおよびその他の共有構成(デプロイメント・プラン、アプリケーション、キーストアなど)のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
トランザクション・ログおよびJMSデータ用のボリューム |
コンシステンシー・グループに関する推奨事項は、次を参照してください。
Oracle SOA Suiteに推奨されるコンシステンシー・グループについて確認します。
Oracle SOA Suiteトポロジについては、次のコンシステンシー・グループをお薦めします。
管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2のDOMAINGROUP)。
JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2のRUNTIMEGROUP )。
Oracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2のFMWHOMEGROUP)。
表4-2に、図4-2に示されているOracle SOA Suiteトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。
表4-2 Oracle SOA Suiteのコンシステンシー・グループ
| 層 | グループ名 | メンバー | 備考 |
|---|---|---|---|
アプリケーション |
|
|
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
アプリケーション |
|
|
JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ |
アプリケーション |
|
|
Oracleホーム用のコンシステンシー・グループ |
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定する方法を確認します。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定するには、次のようにします。
スタンバイ・サイトで、本番サイトのピア・ホストに使用されている物理ホスト名と同じホスト名別名が作成されていることを確認します。
スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。
スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンクを作成します(スタンバイ・サイトでシンボリック・リンクを設定する必要があるのは、本番サイトでシンボリック・リンクを設定した場合のみです)。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
本番サイトにインストールしたものと同じOracle Fusion Middlewareインスタンスをスタンバイ・サイトにインストールする必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているOracleソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。
本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、本番サイトとスタンバイ・サイトの共有ストレージ間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。
スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。
Oracle Fusion Middleware障害時リカバリの本番サイトに含まれているデータベースの障害保護機能がOracle Data Guardによって提供されていることを確認します。Oracle Databaseの障害保護にストレージ・レプリケーション・テクノロジは使用しないでください。
スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。
本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行することを強くお薦めします。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。
Oracle SOA Suiteエンタープライズ・デプロイメントでOracle Database 11.2またはOracle Database 12.1 MAAデータベースをインストールおよび構成する方法を確認します。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用されるOracle Databaseの設定に関する推奨事項と考慮事項は、「データベースに関する考慮事項」を参照してください。
Oracle Maximum Availability Architecture (MAA)は、計画停止の停止時間を短縮し、計画外停止を防止、検出およびリカバリするOracleの包括的なアーキテクチャです。
Real Application Clusters (RAC)およびData Guardは、プライマリ・サイトにRACデータベースが含まれ、セカンダリ・サイトにRAC物理スタンバイ・データベースが含まれるデータベースMAAソリューションの基礎を提供します。
この項では、次の項目について説明します。
ヒント:
また、この項のタスクの多くはOracle Enterprise Manager Cloud Control (Cloud Control)を使用して実行することもできます。
Cloud Controlを使用したデータベースの設定および管理は、ダウンタイムの制御および障害時リカバリ操作の簡略化に役立ちます。
Enterprise Manager Cloud Control 12cのインストールの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。
Cloud Controlを使用したOracle Data Guardの設定の詳細は、Oracle Enterprise Manager Cloud Control 12cによるOracle Data Guardの設定および管理を参照してください。
次の前提条件が満たされていることを確認してください。
スタンバイ・サイトのOracle RACクラスタおよび自動ストレージ管理(ASM)インスタンスが作成済です。
スタンバイ・サイトおよび本番サイトのOracle RACデータベースでフラッシュ・リカバリ領域を使用しています。
Oracle RACデータベースがarchivelogモードで実行されています。
スタンバイ・サイトのデータベース・ホストにOracleソフトウェアがすでにインストールされています。
共有ORACLE_HOME構成では、TNS_ADMINディレクトリはローカルの非共有ディレクトリである必要があります。
この項で示す例には、表4-3で説明する環境変数が含まれています。
表4-3 プライマリおよびスタンバイ・データベースで使用される変数
| 変数 | プライマリ・データベース | スタンバイ・データベース |
|---|---|---|
データベース名 |
|
|
SOAデータベースのホスト名 |
|
|
データベースの一意の名前 |
|
|
インスタンス名 |
|
|
サービス名 |
|
|
次の手順に従って、Oracle Data Guardの設定用のプライマリ・データベースを準備します。
注意:
Oracle Data Guardの設定の前提条件の詳細は、『Oracle Data Guard Broker』の前提条件に関する項を参照してください。
プライマリ・データベースで強制ロギングを使用可能にします。
SQL> alter database force logging; SQL> select name, log_mode, force_logging from v$database; NAME LOG_MODE FOR ---------- ---------------- ------- PSOA ARCHIVELOG YES
オンラインREDOログと同じサイズのスタンバイREDOログをプライマリ・データベースに作成します。DUPLICATEコマンドは、スタンバイ・データベースでスタンバイREDOログを自動的に作成します。
**INTERNAL XREF ERROR**に示すように、同じ数に1つ加えた追加のREDOログを各スレッドで使用することをお薦めします。
スタンバイ・ノード1で、例4-1に示すように、スタンバイ・データベースの静的SIDエントリを提供し、プライマリ(soa1)と同じORACLE_SIDの値を持つリスナー(たとえば、LISTENER_DUPLICATE)を作成し、起動します。
listener.oraファイルへの次のパスを提供します。
GRID_HOME/network/admin/listener.ora
次のコマンドを実行して、GRID_HOME/bin::からlsnrctlを使用し、リスナーを起動および検証します。
lsnrctl start listener_duplicate lsnrctl status listener_duplicate
スタンバイ・ノード2で、例4-2に示すように、スタンバイ・データベースの静的SIDエントリを提供し、プライマリ(soa2)と同じORACLE_SIDの値を持つリスナー(たとえば、LISTENER_DUPLICATE)を作成し、起動します。
listener.oraファイルへの次のパスを提供します。
GRID_HOME/network/admin/listener.ora
注意:
リスナーはクラスタ・レベルで構成され、すべてのノードがリスナーのポートおよび環境設定を継承します。したがって、TNS_ADMINディレクトリ・パスはすべてのノードで同じ値を持ちます。
共有ORACLE_HOME構成では、TNS_ADMINディレクトリはローカルの非共有ディレクトリである必要があります。これらのネットワーク・ファイルはIFILESとして含まれます。
次の手順を実行して、それぞれインスタンスSOA1およびSOA2を持つSOADC1.DBHOST1およびSOADC1.DBHOST2の2ノード・クラスタに共有ORACLE_HOMEのTNS_ADMINを設定します。
各ノードにローカル・ネットワーク・ディレクトリを作成します。たとえば、/local_network_dir/network_adminなどです。
各ノードの場所/local_network_dir/network_adminにローカルlistener.oraファイルを作成します。
ローカルlistener.oraファイルに、LISTENER_duplicateパラメータの値を追加します。
共通listener.oraファイルのGRID_HOME/network/adminに、IFILEパラメータ値を次のように追加します。
IFILE=/local_network_dir/network_admin/listener.ora
次のコマンドを実行して、リスナーを起動および検証します。
lsnrctl start listener_duplicate lsnrctl status listener_duplicate
プライマリ・ノードのデータベース・ホームに、手順3で作成したリスナーに接続するためのOracle Net別名を作成します。例4-3を参照してください。
たとえば、GRID_HOME/bin/tnsping dupです。
REDOトランスポート用のOracleパスワード・ファイル認証を構成します。次の要件を満たすことを確認します。
remote_login_passwordfileをEXCLUSIVEに設定します。
SQL> show parameter remote_login_passwordfile NAME TYPE VALUE --------------------------------- -------------- -------------------------------- remote_login_passwordfile string EXCLUSIVE
プライマリ・パスワード・ファイルを補助インスタス用の場所にコピーします。
スタンバイ・ホストのORACLE_HOME/dbsディレクトリで、次のパラメータを使用してpfile、initsoa1.oraを作成します。
db_name=soa db_unique_name=ssoa sga_target=5g
すべてのスタンバイ・ホストにsoaデータベースの監査ディレクトリを作成します。
mkdir -p /u01/app/oracle/admin/soa/adump
スタンバイ・ホスト上のssoaデータベースにアクセスするために、Oracle Net別名をすべてのプライマリ・ホストに作成します。
すべてのホストにpsoa and ssoa用のOracle Net別名があることを確認します。作成するすべての別名は、ノードVIPではなくスキャン・リスナーを参照する必要があります。また、local_listener変数がプライマリ・ホストの別名に設定されている場合は、スタンバイ・サイトに、プライマリ・ホスト上のローカル・リスナーを指す変数の詳細を入力します。例4-4と例4-5を参照してください。
注意:
プライマリ・ノード2 (SOADC1.DBHOST2)では、次のように、プライマリ・ノード2のVIPを指すようにpsoa_local_listenerのHOST値を更新します。
psoa_local_listener =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=prmy2-vip)(PORT = 1521))
)
)
共有Oracleホームを使用している場合は、2つのノードのVIPをlocal_listenerパラメータに追加します。
次に例を示します。
psoa_local_listener =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=prmy1-vip)(PORT = 1521))
(ADDRESS=(PROTOCOL = TCP)
(HOST=prmy2-vip)(PORT = 1521))
)
)
注意:
スタンバイ・ノード2 (SOADC2.DBHOST2)では、次のように、スタンバイ・ノード2のVIPを指すようにssoa_local_listenerのHOST値を更新します。
ssoa_local_listener = (ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby2-vip)(PORT = 1521))
)
)
共有Oracleホームを使用している場合は、2つのノードのVIPをlocal_listenerパラメータに追加します。
次に例を示します。
ssoa_local_listener =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby1-vip)(PORT = 1521))
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby2-vip)(PORT = 1521))
)
)
スタンバイ・ホストで、ORACLE_SIDをプライマリ・データベースと同じ値(ORACLE_SID=soa1)に設定し、手順9で作成したスタンバイPFILEを使用してスタンバイ・データベースでstartup nomountコマンドを実行します。
値を取得するには、次の問合せを使用します。
SQL> select p.inst_id,instance_name, name,value from gv$parameter p, gv$instance i where p.inst_id=i.inst_id and p.name='cluster_interconnects';
| INST_ID | INSTANCE_NAME | NAME | VALUE |
|---|---|---|---|
| 1 | dbm1 | cluster_interconnects | 192.168.44.225 |
| 2 | dbm2 | cluster_interconnects | 192.168.44.226 |
プライマリ・ホストでパラメータcluster_interconnectsが設定されている場合は、これを無効にします。
SQL> alter system reset cluster_interconnects scope=spfile sid='soa1'; SQL> alter system reset cluster_interconnects scope=spfile sid='soa2';
プライマリ・ホストで、Recovery Manager (RMAN)スクリプトを実行して、コマンドduplicate target database for standby from active databaseを使用してプライマリ・データベースを複製します。
注意:
このコマンドは、環境によって異なります。コマンドの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータベースの複製に関する項を参照してください。
例4-6を参照して、異なるディスクグループ名を持つ2つのシステム間での複製方法を理解します。
例4-7を参照して、同じディスクグループ名+DATAを持つ2つのシステム間での複製方法を理解します。
手順14で説明するように、プライマリ・ホストでパラメータcluster_interconnectsを無効にした場合は、spfileで元の値に戻す必要があります。
(オプション) 手順3で作成したリスナーを停止し、削除します。
例4-1 静的SIDを持つリスナーを作成および起動するスクリプト
LISTENER_duplicate = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = soadc2.dbhost1) (PORT = 1521)(IP = FIRST)))) SID_LIST_LISTENER_duplicate = (SID_LIST = (SID_DESC = (SID_NAME = soa1) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)))
例4-2 静的SIDを持つリスナーを作成および起動するスクリプト
LISTENER_duplicate = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = soadc2.dbhost2) (PORT = 1521)(IP = FIRST)))) SID_LIST_LISTENER_duplicate = (SID_LIST = (SID_DESC = (SID_NAME = soa2) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)))
例4-3 Oracle Net別名を作成するスクリプト
dup = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = soadc2.dbhost1) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = soa1)))
例4-4 プライマリ・ノード1 (SOADC1.DBHOST1)のサンプルtnsnames.oraファイル
psoa =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL= TCP)
(HOST=prmy-scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = psoa)
)
)
ssoa =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby-scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ssoa)
)
)
psoa_local_listener =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=prmy1-vip)(PORT = 1521))
)
)
例4-5 スタンバイ・ノード1 (SOADC2.DBHOST1)のサンプルtnsnames.oraファイル
psoa =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL= TCP)(HOST=prmy-scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = psoa)
)
)
ssoa =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby-scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ssoa)
)
)
ssoa_local_listener =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby1-vip)(PORT = 1521))
)
)
例4-6 異なるディスクグループ名を持つ2つのシステム間でのデータの複製
rman <<EOF connect target sys/password; connect auxiliary sys/password@dup; run { allocate channel prmy1 type disk; allocate channel prmy2 type disk; allocate channel prmy3 type disk; allocate channel prmy4 type disk; allocate auxiliary channel stby type disk; duplicate target database for standby from active database spfile parameter_value_convert '+DATA_prmy','+DATA_stby','+RECO_prmy','+RECO_stby' set db_file_name_convert '+DATA_prmy','+DATA_stby' set db_unique_name='ssoa' set db_create_online_log_dest_1='+DATA_stby' set db_create_file_dest='+DATA_stby' set db_recovery_file_dest='+RECO_stby' set log_file_name_convert '+DATA_prmy','+DATA_stby','+RECO_prmy','+RECO_stby' set control_files='+DATA_stby/ssoa/standby.ctl' set local_listener='ssoa_local_listener' set remote_listener='stby-scan:1521'; } EOF
例4-7 同じディスクグループ名+DATAを持つ2つのシステム間でのデータの複製
rman <<EOF connect target sys/password; connect auxiliary sys/password@dup; run { allocate channel prmy1 type disk; allocate channel prmy2 type disk; allocate channel prmy3 type disk; allocate channel prmy4 type disk; allocate auxiliary channel stby type disk; duplicate target database for standby from active database spfile set db_unique_name='ssoa' set control_files='+DATA/ssoa/standby.ctl' set local_listener='ssoa_local_listener' set remote_listener='stby-scan:1521'; } EOF
例4-8 サンプルREDOログ
SQL> alter database add standby logfile thread 1 group 9 size 500M, group 10 size 500M, group 11 size 500M; SQL> alter database add standby logfile thread 2 group 12 size 500M, group 13 size 500M, group 14 size 500M;
スタンバイ・データベースでRAC構成を完了するには、「プライマリ・データベースの複製の手順」の手順を実行します。さらに、次の手順を実行します。
スタンバイ・データベースで一時パラメータ・ファイルを作成します。
SQL> create pfile='/tmp/p.ora' from spfile;
スタンバイ・データベースの+DATA_stbyにSPFILEを作成します。
SQL> create spfile='+DATA_stby/ssoa/spfilessoa.ora' from pfile='/tmp/p.ora';
デフォルト・ファイルを削除します。
$rm /u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/spfilesoa1.ora
すべてのスタンバイ・ホストにinitsoan.oraファイルを作成します。ファイルは、手順2で作成したSPFILEの場所を指す必要があります。
cat /u01/app/oracle/product/11.2.0/dbs/initsoa1.ora spfile='+DATA/ssoa/spfilesoa.ora
スタンバイ・システムで、マウント状態のインスタンスを再起動します。
startup mount
次のようにRACデータベースをCRSに登録します。
srvctl add database -d ssoa –o /u01/app/oracle/product/11.2.0/db_1 srvctl add instance -d ssoa -i soa1 -n soadc2.dbhost1 srvctl add instance -d ssoa -i soa2 -n soadc2.dbhost2 srvctl modify database –d ssoa –r physical_standby
この項では、Data Guard構成の作成の基本的な手順について説明します。
Data Guard Brokerの詳細は、Oracle Data Guardのインストールに関する項の手順を参照してください。
Data Guard Broker構成を作成するには、次の手順を実行します。
例4-9 dgmgrlへのアクセスによるプライマリ・ホストのData Guard Broker構成の作成
dgmgrl sys/password
DGMGRL> create configuration 'dg_config' as
primary database is 'psoa'
connect identifier is psoa;
Configuration "dg_config" created with primary database "psoa"
DGMGRL> add database 'ssoa' as
connect identifier is ssoa;
Database "ssoa" added
DGMGRL> enable configuration;
Enabled.
次の手順を実行して、Data Guard Broker構成が正常に作成されたことを確認します。
例4-10 Data Guard Broker構成の検証
DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: psoa- Primary database ssoa- Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
データベースのスイッチオーバーおよびスイッチバックを実行できます。
Oracle Data Guard Brokerを使用したスイッチオーバー操作の実行
Oracle Data Guard Brokerを使用してスイッチオーバー操作を実行するには、次のタスクを完了します。
「Data Guard Broker構成の作成」の手順を使用して作成したOracle Data Guard Broker構成を検証します。
構成を検証するには、次のコマンドを実行します。
DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: psoa- Primary database ssoa- Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
SWITCHOVERコマンドを実行して、プライマリ・データベースとスタンバイ・データベースのロールを入れ替えます。**INTERNAL XREF ERROR**では、Data Guard Brokerが、古いプライマリ・データベースの停止および再起動を、スイッチオーバー操作の一部として自動的に実行する方法を示します。
DGMGRL> switchover to 'ssoa'; Performing switchover NOW, please wait... New primary database "ssoa" is opening... Operation requires shutdown of instance "psoa1" on database "psoa" Shutting down instance "psoa1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires startup of instance "psoa1" on database "psoa" Starting instance "psoa1"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "ssoa"
スイッチオーバーの完了後、SHOW CONFIGURATIONコマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。
DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: ssoa- Primary database psoa- Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
SQL Plusを使用したスイッチオーバー操作の実行
次の操作を実行して、新しく作成したフィジカル・スタンバイ・データベースとプライマリOracle RACデータベース間でデータベースを正しくスイッチオーバーまたはスイッチバックします。
注意:
Oracle Data Guard Brokerのスイッチオーバーおよびフェイルオーバー操作の詳細は、『Oracle Data Guard Broker』のスイッチオーバーおよびフェイルオーバー操作に関する項を参照してください。
Oracle SOAエンタープライズ・デプロイメント・トポロジで本番サイトを作成する方法を確認します。
本番サイトを作成する前に:
「ホスト名の計画」の説明に従って、中間層ホストのホスト名別名を設定します。
「ディレクトリ構造とボリュームの設計」の説明に従って、本番サイトの共有ストレージに必要なボリュームを作成します。
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定します。
この項には次のトピックが含まれます:
Oracle SOA Suiteトポロジの本番サイトを作成します。
『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従って、本番サイトをインストールおよび構成します。
注意:
この項では、Oracle SOA Suiteトポロジの本番サイトの作成方法について説明します。異なるトポロジの本番サイトを作成する場合は、Install a Production Environment: Plan, Install & Configure an Enterprise Deploymentカテゴリに記載されている適切なOracle Fusion Middlewareのエンタープライズ・デプロイメント・ガイドを参照してください。次の項で、本番サイトのインストールおよび構成を実行する方法について説明します。
共有ストレージ・デバイスでボリュームおよびコンシステンシー・グループを作成します。
共有ストレージ・デバイスにボリュームおよびコンシステンシー・グループを作成するには、 「Oracle SOA Suiteに推奨されるボリューム設計」を参照してください。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。
本番サイトおよびスタンバイ・サイトのホスト名の計画の詳細は、「ホスト名の計画」を参照してください。
Oracle SOA Suiteをインストールおよび構成します。
Oracle SOA Suiteをインストールおよび構成するには、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照し、次の変更を適用してください。
SOA Suiteを例としてOracle Fusion Middlewareが使用するデータ・ソースを構成し、プライマリ・データベースのフェイルオーバーまたはスイッチオーバーの場合に接続のフェイルオーバーを自動化します。
ドメインで使用されるすべてのデータ・ソースを構成します。
さらに、データベースを使用した永続ストアおよびサーバー移行に使用するリース・データ・ソースを構成してフェイルオーバーを自動化します。GridLinkデータ・ソースを変更する必要があります。
ONS構成を更新して、本番およびスタンバイ両方のサイトONSを含めます。
次の例に示すように、ONSアドレス・リストの項目はカンマで区切る必要があります。
prmy-scan:6200,stby-scan:6200
「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。次の例は、成功した場合の接続通知を示しています。
Connect test for prmy-scan:6200 succeeded.
JDBC URLを更新して、両方のサイトに適切なサービスを含めます。
データベースがData Guardを使用するOracle Fusion Middleware SOAアクティブ/パッシブ構成のSOAデータ・ソースのサンプルJDBC URLを次に示します。
jdbc:oracle:thin:@
(DESCRIPTION_LIST =
(LOAD_BALANCE = off)
(FAILOVER = on)
(DESCRIPTION =
(CONNECT_TIMEOUT = 10)
(TRANSPORT_CONNECT_TIMEOUT = 3)
(RETRY_COUNT = 3)
(ADDRESS_LIST =
(LOAD_BALANCE = on)
(ADDRESS =
(PROTOCOL = TCP)(HOST = prmy-scan)(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME =soaedg.example.com)
)
)
(DESCRIPTION =
(CONNECT_TIMEOUT =10)
(TRANSPORT_CONNECT_TIMEOUT = 3)
(RETRY_COUNT = 3)
(ADDRESS_LIST =
(LOAD_BALANCE = on)
(ADDRESS =
(PROTOCOL =TCP)(HOST = stby-scan)(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME = soaedg.example.com))
)
)
「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。次の例は、成功した場合の接続通知を示しています。
Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))) succeeded.
BI専用: このコマンドは、中間層データベースの接続詳細を同期し、接続詳細の変更時にBIコンポーネントが中間層データベースにアクセスできることを確認します。コマンドの位置:
DOMAIN_HOME/bitools/bin/sync_midtier_db.sh注意:
UNIXの場合、これをマスター・ホストで実行する必要があります。同期スクリプトを実行します。
DOMAIN_HOME/bitools/bin/sync_midtier_db.sh
スクリプトには、更新されるデータ・ソースが表示されます。
管理対象サーバーおよびBIシステム・コンポーネントを再起動します。
スタンバイ・サイトを作成する方法を確認します。
スタンバイ・サイトを作成するために、Oracle SOAエンタープライズ・デプロイメント・トポロジを例として使用します。
この項には次のトピックが含まれます:
スタンバイ・サイトで操作できるように準備します。
スタンバイ・サイトで操作できるように準備するには、次のようにします。
「ホスト名の計画」の手順に従って、ホスト名別名および物理ホスト名を正しく設定します。
スタンバイ・サイトの各ホストに、本番サイトのピア・ホストの物理ホスト名と同じホスト名別名が設定されていることを確認してください。
共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します
本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareやOracle WebLogic Serverソフトウェアのインストールや構成を行う必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトにインストールされているソフトウェアがスタンバイ・サイトにレプリケートされます。
スタンバイ・サイトの中間層ホストを設定するには、次の手順を実行します。
Oracle WebLogic管理サーバーでホスト名の検証を有効にしている場合、スタンバイ・サイトの証明書の適切なトラスト・ストアおよびキー・ストアを更新します。
証明書は、スタンバイ・サイトのノード専用に作成する必要があります。
ノードの証明書の作成の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の中間層とハードウェア・ロード・バランサ間のSSL通信の有効化に関する項を参照してください。
これらの項の例では、図4-2に示されているOracle SOA Suiteエンタープライズ・トポロジに対してタスクを実行する方法を紹介します。
注意:
この項には次のトピックが含まれます:
utils.ImportPrivateKeyユーティリティを使用して証明書をキー・ストアにインポートします。keytoolユーティリティを使用して証明書をインポートします。utils.ImportPrivateKeyユーティリティを使用して証明書をキー・ストアにインポートします。
utils.ImportPrivateKeyユーティリティを使用して証明書をキー・ストアにインポートするには、次の手順を実行します。
スタンバイ・サイトを検証します。
スタンバイ・サイトを検証するには、次の手順を実行します。
非対称Oracle Fusion Middleware障害時リカバリ・トポロジを作成する方法について説明します。
非対称トポロジは、本番サイトとスタンバイ・サイトで異なる障害時リカバリ構成です。障害時リカバリのほとんどの非対称トポロジでは、スタンバイ・サイトと本番サイトの相違点は、スタンバイ・サイトのリソースの数が本番サイトより少ないという点です。
このドキュメントの前述の章で対称トポロジの設定方法を確認してください。対称トポロジの設定に使用する概念の多くは、非対称トポロジを設定する際にも有効です。
この項には次のトピックがあります。
Oracle Fusion Middleware障害時リカバリ・トポロジの非対称スタンバイ・サイトを作成します。
本番サイトは、図4-2に示されているOracle SOA Suiteエンタープライズ・デプロイメントとして想定します。非対称スタンバイ・サイトは本番サイトと異なるものになります。
非対称スタンバイ・サイトを作成するには、次の手順を実行します。
本番サイトとスタンバイ・サイトを設計します。スタンバイ・サイトが本番ロールを引き継いだときに許容されるパフォーマンスを確保できるように、スタンバイ・サイトで必要となるリソースを特定してください。
注意:
スタンバイ・サイト・インスタンスのポートでは、本番サイトのピア・インスタンスと同じポート番号を使用する必要があります。そのため、スタンバイ・サイトで必要となるすべてのポート番号が使用可能である(スタンバイ・サイトで使用中でない)ことを確認してください。
次の操作を実行して、Oracle Fusion Middleware障害時リカバリの本番サイトを作成します。
本番サイトの共有ストレージ・システムで、本番サイト用にインストールするOracle Fusion Middlewareインスタンスのボリュームを作成します。「ディレクトリ構造とボリュームの設計」を参照してください。
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
ボリューム設計の詳細は、「Oracle SOA Suiteに推奨されるボリューム設計」を参照してください。
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
Oracle中央インベントリ・ディレクトリの詳細は、「OracleホームとOracleインベントリ」を参照してください。
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle HTTP Serverインスタンスに対して、静的HTMLページ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します(該当する場合)。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
本番サイトの共有ストレージ・システムのボリュームに、本番サイト用のOracle Fusion Middlewareインスタンスをインストールします。「Oracle SOA Suiteトポロジの本番サイトの作成」を参照してください。
スタンバイ・サイトの共有ストレージ・システムでも、本番サイトの共有ストレージ・システムでOracle Fusion Middlewareインスタンスに対して作成したのと同じボリュームを、同じファイル権限とディレクトリ権限で作成します。この手順は重要です。これにより、後からストレージ・レプリケーションを使用してスタンバイ・サイト用にOracle Fusion Middlewareのピア・インスタンスのインストールを作成できるようになり、Oracle Universal Installerを使用したインストールが不要になるからです。
注意:
ストレージ・レプリケーションを構成する際には、本番サイトの共有ストレージ・システムで設定したすべてのボリュームがスタンバイ・サイトの共有ストレージ・システム上の同じボリュームにレプリケートされるようにしてください。
本番サイトの一部のインスタンスやホストがスタンバイ・サイトに存在しない場合でも、本番サイトのOracle Fusion Middlewareインスタンスに対して設定したすべてのボリュームでストレージ・レプリケーションを構成する必要があります。
共有ストレージを構成して、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にします。本番サイトの共有ストレージ・システムのボリュームをスタンバイ・サイトの共有ストレージ・システムに非同期でコピーするように、ストレージ・レプリケーションを構成してください。
本番サイトの共有ストレージ・システムの初期のベースライン・スナップショット・コピーを作成して、本番サイトとスタンバイ・サイトの共有ストレージ・システム間のレプリケーションを設定します。初期のベースライン・スナップショット・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリュームのすべてのディレクトリの内容が本番サイトのボリュームのディレクトリと同じであることを検証します。初期のスナップショットを作成する方法、および本番サイトとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にする方法の詳細は、共有ストレージ・ベンダーのドキュメントを参照してください。
ベースライン・スナップショットを作成したら、スタンバイ・サイトのホストでOracle Fusion Middlewareインスタンスについて次の手順を実行します。
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。
この時点で、本番サイトのOracle Fusion Middlewareインスタンスのインストールがスタンバイ・サイトにレプリケートされています。スタンバイ・サイトは、次のすべての項目に該当する状態となります。
Oracle Fusion Middlewareインスタンスは、本番サイトと同じボリューム上の同じOracleホーム・ディレクトリにインストールされています。また、ホストでは、Oracleホーム・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
Oracle中央インベントリ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle中央インベントリ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
Oracle HTTP Serverの静的HTMLページ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle HTTP Serverの静的HTMLページ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、「ストレージ・レプリケーション」を参照してください。
スタンバイ・サイトのOracle Fusion Middlewareインスタンスには、本番サイトの同じインスタンスに使用されているものと同じポートが使用されています。
ホストおよびインスタンスの数が少ない非対称スタンバイ・サイトを作成するには、次のトピックを参照してください。
ホストおよびOracle Fusion Middlewareインスタンスの数が本番サイトより少ない非対称スタンバイ・サイトを作成します。
このOracle Fusion Middleware障害時リカバリ・トポロジの本番サイトは、図4-2に示されているOracle SOA Suiteエンタープライズ・デプロイメントとして想定します。「サイトの設定」から「ディレクトリ構造とボリュームの設計」では、この本番サイトと共有ストレージ・システムのボリュームを設定する方法および必要なマウント・ポイントの作成方法について説明しています。
図4-4に、図4-2に示されている本番サイトの非対称スタンバイ・サイトを示します。
図4-4に示されているOracle SOA Suiteの非対称スタンバイ・サイトのホストおよびインスタンスの数は、図4-2に示されているOracle SOA Suiteの本番サイトより少なくなっています。
図4-2の本番サイトには、ホストWEBHOST2およびSOAHOST2とこれらのホスト上のインスタンスが存在しますが、図4-4の非対称スタンバイ・サイトには、これらのホストとそのインスタンスが存在しません。そのため、スタンバイ・サイトのホストおよびインスタンスの数は、本番サイトより少なくなっています。
この非対称スタンバイ・サイトには、本番ロールを引き継いだときに適切なパフォーマンスを提供できるように、十分なリソースを確保することが重要です。
「非対称スタンバイ・サイトの作成」に記載されている手順に従って、この非対称スタンバイ・サイトを設定すれば、スタンバイ・サイトは本番ロールを引き継ぐように適切に構成されます。
非対称スタンバイ・サイトを正しく設定するには、本番サイトの共有ストレージで作成したものと同じボリュームおよびコンシステンシー・グループをスタンバイ・サイトの共有ストレージで作成します。たとえば、Oracle SOA Suiteデプロイメントについて、表4-1のボリューム設計に関する推奨事項と表4-2のコンシステンシー・グループに関する推奨事項を使用して、本番サイトの共有ストレージを設定したとします。その場合、本番サイトの共有ストレージに使用したものと同じボリューム設計に関する推奨事項とコンシステンシー・グループに関する推奨事項を使用して、非対称スタンバイ・サイトの共有ストレージを設定します。
非対称スタンバイ・サイトでは、本番サイトに存在する一部のホストがスタンバイ・サイトに存在しません。たとえば、図4-4に示されているOracle SOA Suiteの非対称スタンバイ・サイトでは、WEBHOST2とSOAHOST2が存在しないため、スタンバイ・サイトの共有ストレージ・ボリュームに対してこれらのホスト上にマウント・ポイントを作成することはできず、作成する必要はありません。
スタンバイ・サイトを検証します。
スタンバイ・サイトを検証するには、次の手順を実行します。
Oracle Fusion Middleware障害時リカバリ・トポロジを操作および管理する方法を確認します。
この項には次のトピックが含まれます:
rsyncを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトのホストからスタンバイ・サイトのピア・ホストに中間層のファイル・システム・データをレプリケートします。本番サイトで中間層の変更を導入した場合に、本番サイトとスタンバイ・サイトの同期化を強制的に実行する方法を確認します。
通常の操作では、スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。
本番サイトで中間層の変更を導入した場合(本番サイトに新しいアプリケーションをデプロイした場合など)、同期化を強制的に実行します。ストレージ・レプリケーション・テクノロジを使用して同期化を強制的に実行するには、ベンダー固有の手順に従ってください。
Oracle Fusion Middleware障害時リカバリ・トポロジでのデータベースの同期化は、Oracle Data Guardによって管理されます。
スイッチオーバー操作は、スタンバイ・サイトを本番ロールとして設定します。
本番サイトを停止したり(メンテナンスを実行する場合など)、現在のスタンバイ・サイトを本番サイトにすることを計画している場合に、この操作が必要になります。
スイッチオーバー操作を実行するには、次の手順を実行します。
これで、前のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトでメンテナンスを実行できるようになりました。元の本番サイトでメンテナンスを実行した後、将来、そのサイトを本番サイトとしてもスタンバイ・サイトとしても使用できます。
注意:
この注意事項はBI固有のシステムにのみ適用されます。
スイッチオーバー操作後、CDSでEssbaseキューブを作成すると、次のようなエラーで失敗する可能性があります。
oracle.essbase.cds.util.CDSException: oracle.essbase.cds.util.CDSException: java.sql.SQLException: ORA-25153:
次のようなselect文を使用して一時表領域を指定します(ここで、BIS17V1はOracle Business Intelligence RCU接頭辞です)。
select username,temporary_tablespace from dba_users where username like 'BIS17V1%'
前述のコマンドを実行すると、次のような一時表領域のリストが返されます。
USERNAME.....TEMPORARY_TABLESPACE
BIS17V1_IAU_VIEWER.....BIS17V1_IAS_TEMP
BIS17V1_STB.....BIS17V1_IAS_TEMP
BIS17V1_IAU_APPEND.....BIS17V1_IAS_TEMP
BIS17V1_MDS.....BIS17V1_IAS_TEMP
BIS17V1_IAU.....BIS17V1_IAS_TEMP
BIS17V1_BIPLATFORM......BIS17V1_IAS_TEMP
BIS17V1_OPSS.....BIS17V1_IAS_TEMP
スイッチオーバー後、内容およびデータファイルも含め、表領域BIS17V1_IAS_TEMPが削除されます。
一時表領域BIS17V1_IAS_TEMPを一時ファイルとして、/work/primy/oradata/stnby/BIS17V1_IAS_TEMP.dbfの場所(例)に250MBのサイズで作成します。
次のように、(一時表領域のリストを使用する場所で)alterコマンドを発行します。
alter user BIS17V1_OPSS temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_BIPLATFORM temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_MDS temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU_APPEND temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_STB temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU_VIEWER temporary tablespace BIS17V1_IAS_TEMP ;
元の本番サイトを本番サイトとして使用するには、「スイッチバックの実行」の説明に従って、スイッチバックを実行します。
フェイルオーバー操作は、本番サイトが使用できなくなった場合に、スタンバイ・サイトを本番ロールとして設定します。
フェイルオーバー操作を実行するには、次の手順を実行します。
注意:
フェイルオーバー操作後、CDSでEssbaseキューブを作成すると、次のようなエラーで失敗する可能性があります。oracle.essbase.cds.util.CDSException: oracle.essbase.cds.util.CDSException: java.sql.SQLException: ORA-25153:
次のようなselect文を使用して一時表領域を指定します(ここで、BIS17V1はOracle Business Intelligence RCU接頭辞です)。
select username,temporary_tablespace from dba_users where username like 'BIS17V1%'
前述のコマンドを実行すると、次のような一時表領域のリストが返されます。
USERNAME.....TEMPORARY_TABLESPACE
BIS17V1_IAU_VIEWER.....BIS17V1_IAS_TEMP
BIS17V1_STB.....BIS17V1_IAS_TEMP
BIS17V1_IAU_APPEND.....BIS17V1_IAS_TEMP
BIS17V1_MDS.....BIS17V1_IAS_TEMP
BIS17V1_IAU.....BIS17V1_IAS_TEMP
BIS17V1_BIPLATFORM......BIS17V1_IAS_TEMP
BIS17V1_OPSS.....BIS17V1_IAS_TEMP
フェイルオーバー後、内容およびデータファイルも含め、表領域BIS17V1_IAS_TEMPが削除されます。
一時表領域BIS17V1_IAS_TEMPを一時ファイルとして、/work/primy/oradata/stnby/BIS17V1_IAS_TEMP.dbfの場所(例)に250MBのサイズで作成します。
次のように、(一時表領域のリストを使用する場所で)alterコマンドを発行します。
alter user BIS17V1_OPSS temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_BIPLATFORM temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_MDS temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU_APPEND temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_STB temporary tablespace BIS17V1_IAS_TEMP ;
alter user BIS17V1_IAU_VIEWER temporary tablespace BIS17V1_IAS_TEMP ;
元の本番サイトを本番サイトとして再度使用するには、「スイッチバックの実行」の説明に従って、スイッチバックを実行します。
スタンバイ・サイトの読取り専用共有ストレージのクローンを作成し、これを使用してスタンバイ・サイトをテストする方法を確認します。
通常のOracle Fusion Middleware障害時リカバリ構成では、次のものを使用します。
ストレージ・レプリケーション。これを使用して、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージにOracle Fusion Middlewareの中間層のファイル・システムおよびデータをコピーします。通常の操作時には、本番サイトはアクティブで、スタンバイ・サイトはパッシブです。本番サイトがアクティブな場合、スタンバイ・サイトはパッシブで、スタンバイ・サイトの共有ストレージは読取り専用モードです。スタンバイ・サイトの共有ストレージに対して行われる書込み操作は、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージへのストレージ・レプリケーション操作のみです。
Oracle Data Guard。これを使用して本番サイトのOracle Databaseのデータベース・データをスタンバイ・サイトのスタンバイ・データベースにコピーします。デフォルトでは、本番サイトのデータベースはアクティブで、スタンバイ・サイトのスタンバイ・データベースはパッシブです。スタンバイ・サイトがスタンバイ・ロールの間(パッシブである間)、スタンバイ・サイトのスタンバイ・データベースは管理リカバリ・モードです。本番サイトがアクティブな場合、スタンバイ・データベースに対して行われる書込み操作は、Oracle Data Guardによって実行されるデータベースの同期操作のみです。
スタンバイ・サイト。本番サイトが使用できなくなった場合に、これを本番ロールとして使用します。現在の本番サイトが予期せず使用できなくなった場合は、フェイルオーバー操作(「フェイルオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。また、現在の本番サイトを意図的に停止する場合は(予定したメンテナンスの場合など)、スイッチオーバー操作(「スイッチオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。
通常の方法でスタンバイ・サイトをテストする場合は、現在の本番サイトを停止し、スイッチオーバー操作を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。ただし、企業では、現在の本番サイトを停止してスイッチオーバー操作を実行することなく、障害時リカバリのスタンバイ・サイトの定期テストを実行することもできます。
スタンバイ・サイトをテストする別の方法では、スタンバイ・サイトの読取り専用共有ストレージのクローンを作成し、クローニングされたスタンバイ・サイト共有ストレージをテストで使用します。
この代替テスト方法を使用するには、次の手順を実行します。
共有ストレージ・ベンダーが提供しているクローニング・テクノロジを使用して、スタンバイ・サイトの共有ストレージでスタンバイ・サイトの読取り専用ボリュームのクローンを作成します。クローニングされたスタンバイ・サイトのボリュームが書込み可能であることを確認します。スタンバイ・サイトを1回のみテストする場合、これは1回かぎりのクローン操作にできます。ただし、スタンバイ・サイトを定期的にテストする場合は、スタンバイ・サイトの読取り専用ボリュームの、スタンバイ・サイトの読取り/書込みクローン・ボリュームへの定期的クローニングを設定できます。
スタンバイ・サイトのデータベースのバックアップを実行し、本番サイトとスタンバイ・サイトのデータベース間のOracle Data Guardレプリケーションを変更します。
10.2以降のデータベースについては、次の手順に従って、スナップショット・スタンバイ・データベースを確立します。
フラッシュ・リカバリ領域がない場合は、設定します。
REDO適用を取り消します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE CANCEL;
保証付きリストア・ポイントを作成します。
SQL> CREATE RESTORE POINT standbytest
GUARANTEE FLASHBACK DATABASE;
プライマリ(本番)サイトで現在のログをアーカイブします。
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
アクティブ化するスタンバイ・サイト接続先を遅延させます。
SQL> ALTER SYSTEM SET
LOG_ARCHIVE_DEST_STATE_2=DEFER;
ターゲット・スタンバイ・データベースをアクティブ化します。
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
データベースが読取り専用で開いている場合、Forceオプションを指定してデータベースをマウントします。
SQL> STARTUP MOUNT FORCE;
保護モードを下げて、データベースを開きます。
SQL> ALTER DATABASE SET STANDBY DATABASE TO
MAXIMIZE PERFORMANCE;
SQL> ALTER DATABASE OPEN;
Oracle Data Guardのデータベース・リカバリ手順に従って、スタンバイ・データベースをオンラインにします。
スタンバイ・サイトのコンピュータで、次の手順に従って、スタンバイ・サイトのクローニングされた読取り/書込み共有ストレージ・ボリュームを指すようにmountコマンドを変更します。
読取り専用の共有ストレージ・ボリュームをアンマウントします。
クローニングされた読取り/書込みボリュームを同じマウント・ポイントでマウントします。
スタンバイ・サイトをテストする前に、ホスト名が本番サイトのコンピュータではなくスタンバイ・サイトのコンピュータを指すように、テストの実行に使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、スタンバイ・サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。
スタンバイ・サイトのテストを実行します。
スタンバイ・サイトのテストが完了したら、次の手順に従って、元の本番サイトを本番サイトとして再度使用します。
スタンバイ・サイトの読取り専用共有ストレージ上のボリュームを指すようにスタンバイ・サイト・コンピュータのmountコマンドを変更します。つまり、mountコマンドを、テストを実行する前の状態にリセットします。
クローニングされた共有ストレージの読取り/書込みボリュームをアンマウントします。
読取り専用の共有ストレージ・ボリュームをマウントします。
これで、mountコマンドがスタンバイ・サイトのテストを実行する前の状態にリセットされました。
本番サイトのデータベースとスタンバイ・サイトのスタンバイ・データベース間のレプリケーションを実行するように、Oracle Data Guardを構成します。この構成を実行すると、スタンバイ・データベースは再度、管理リカバリ・モードに設定されます。
Oracle Database 10.2以降については、次の手順に従います。
アクティブ化したデータベースをフィジカル・スタンバイ・データベースに戻します。
SQL> STARTUP MOUNT FORCE; SQL> FLASHBACK DATABASE TO POINT standbytest; SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> STARTUP MOUNT FORCE;
管理リカバリを再開します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE USING CURRENT LOGFILE DISCONNECT;
スタンバイ接続先を再度有効にし、ログを切り替えます。
SQL> ALTER SYSTEM SET
LOG ARCHIVE DEST STATE 2=ENABLE;
Oracle Database 12cの場合、フィジカルおよびスナップショット・スタンバイ・データベースの管理に関する項の手順に従って、レプリケーションを再度設定します。
元の本番サイトを再度使用する前に、ホスト名がスタンバイ・サイトのコンピュータではなく本番サイトのコンピュータを指すように、本番サイトへのアクセスに使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、本番サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。
テスト環境でユーティリティrsyncを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトのホストからスタンバイ・サイトのピア・ホストに中間層のファイル・システム・データをレプリケートします。
テスト環境で中間層のコンポーネントをレプリケートする代替方法は、rsyncユーティリティ(ピアツーピア・ファイル・コピーを使用)を使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトのホストからスタンバイ・サイトのピア・ホストに中間層のファイル・システム・データをレプリケートします。rsyncユーティリティの使用は、対称トポロジのコンテキストで説明されています。
Oracle Fusion Middlewareコンポーネントの障害保護と障害時リカバリの場合、ストレージ・レプリケーションの使用とrsyncユーティリティの使用には多数の類似点があるため、Oracle Fusion Middleware障害時リカバリ・トポロジにおけるOracle Data Guardでのストレージ・レプリケーションを確認してください。
注意:
ストレージ・レプリケーション・テクノロジの使用とrsyncユーティリティの使用の次の重要な相違点に注意して、中間層のファイル・システムをレプリケートしてください。
ストレージ・レプリケーションの使用時は、本番サイトで前のスナップショットが作成された時点まで変更をロールバックできます。
rsyncユーティリティの使用時は、レプリケートされた本番サイトのデータによってスタンバイ・サイトのデータが上書きされるため、レプリケーションをロールバックすることはできません。
ストレージ・レプリケーションの使用時は、共有ストレージ・システムで各ホスト・クラスタについて設定したボリュームによって、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間でそのホスト・クラスタのデータの整合性が保証されます。
rsyncユーティリティの使用時は、データの整合性は保証されません。
これらの相違点があるため、rsyncユーティリティは本番環境ではサポートされておらず、テスト環境のみでサポートされています。
この項には次のトピックが含まれます:
rsyncユーティリティおよびOracle Data Guardを使用する方法を確認します。rsyncとOracle Data Guardの使用Oracle Fusion Middleware障害時リカバリにおいてUNIX rsyncユーティリティおよびOracle Data Guardを使用する方法を確認します。
注意:
Oracle Database用のOracle Data Guardの設定方法の詳細は、「データベースに関する考慮事項」を参照してください。
次の項では、rsyncユーティリティおよびOracle Data Guardを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジで本番サイトとスタンバイ・サイト間で保護および強制的に同期化を実行する方法について説明します。
rsyncユーティリティを使用して、Oracle Fusion Middleware中間層コンポーネントを保護およびリカバリします。rsyncユーティリティの使用時にフェイルオーバーまたはスイッチオーバー操作を実行する方法を確認します。UNIX rsyncユーティリティを使用して、Oracle Fusion Middlewareの中間層コンポーネントを保護およびリカバリします。
rsyncユーティリティを使用するには、次の手順を実行します。
Oracle Site Guardは、2つの障害時リカバリ・サイト間のスイッチオーバーおよびフェイルオーバーを編成します。
Oracle Site Guardでは、次のことを行います。
企業データの高可用性、データ保護および障害時リカバリを保証します。
スイッチオーバーやフェイルオーバーなどのOracle Site Guard操作を実行します。プライマリ・サイトが計画停止または計画外停止のため使用不可となった場合、スイッチオーバーまたはフェイルオーバー・プロセスはOracle Site Guardを使用して開始する必要があります。
Oracle Site Guardの使用方法の詳細は、Oracle Site Guard管理者ガイドを参照してください。
Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードします。
パッチを適用するOracle Fusion MiddlewareインスタンスのOracle中央インベントリが本番サイトの共有ストレージに配置されていて、パッチが適用されたインスタンスのOracle中央インベントリをスタンバイ・サイトにレプリケートできるようになっていることを前提としています。
Oracle Fusion Middlewareのパッチを適用するには、次の手順を実行します。
注意:
パッチは、Oracle Fusion Middleware 12c障害時リカバリ・トポロジの本番サイトでのみ適用する必要があります。Oracle Fusion MiddlewareインスタンスまたはOracle中央インベントリのパッチの場合、本番サイトの共有ストレージがスタンバイ・サイトの共有ストレージにレプリケートされるときに、パッチがコピーされます。本番サイトでパッチをインストールした場合は、同期操作を実行する必要があります。
同様に、本番サイトのデータベースのパッチをインストールした場合、同期を実行すると、Oracle Data Guardによってスタンバイ・サイトのスタンバイ・データベースにパッチがコピーされます。
