| Oracle® Site Guard管理者ガイド 13c リリース3 E98541-01 |
|
 前へ |
 次 |
この項では、Oracle Site Guardとそのメリットについて説明します。
サイトは、1つ以上のユーザー・アプリケーションを実行するソフトウェア・コンポーネントおよび関連付けられたハードウェアの論理的なグループです。
たとえば、サイトは、Oracle Fusion Middlewareインスタンス、Oracle Fusion Applicationインスタンス、Oracle Databaseをデプロイするために使用されるサーバー(ホスト)のコレクションとこれらのソフトウェア・コンポーネントに関連付けられたストレージで構成できます。Oracle Site Guardは、Enterprise Manager Cloud Control汎用システム・ターゲットを使用してサイトを表現します。いずれのサイトも、それがプライマリであるかスタンバイであるかにかかわらず、Oracle DatabaseおよびOracle Fusion Middlewareドメインなどの他のターゲット・タイプのコレクションである汎用システムとして表現されます。Oracle Site Guardは、プライマリ・サイトとスタンバイ・サイトの両方が同じEnterprise Manager Cloud Controlデプロイメントにより管理されるEnterprise Managerデプロイメントのみをサポートしています。
次の図は、同じEnterprise Manager Cloud Controlデプロイメントにより管理されるOracle Fusion Middleware障害時リカバリ・トポロジの主要部分を示しています。
図2-1 Enterprise Manager Cloud Controlにより管理されるOracle Fusion Middleware障害時リカバリ・トポロジにおけるプライマリ・サイト(本番サイト)とスタンバイ・サイト
Oracle Fusion Middleware障害時リカバリ・トポロジの主な側面は次のとおりです。
単一のEnterprise Manager Cloud Controlがプライマリ・サイトおよびスタンバイ・サイトを監視します。
Oracle Management Agent (EMエージェント)は、プライマリ・サイトおよびスタンバイ・サイトのすべてのホストのローカル(レプリケートされていない)記憶域にインストールされます。
次に例を示します。
Web層の管理対象システム・コンポーネント(WEBHOST1およびWEBHOST2)
Oracle Fusion Middlewareアプリケーション(APPHOST1およびAPPHOST2)
Oracle RAC Database (RAC DBHOST1およびRAC DBHOST2)
Oracle Management Agent (EMエージェント)は、Enterprise Manager Cloud Controlのコア・コンポーネントの1つで、Enterprise Managerシステムで管理対象外ホストを管理対象ホストに変換できます。管理エージェントはEnterprise Managerプラグインと連携して、管理対象ホスト上で動作しているターゲットを監視します。
Oracle Site Guardには、拡張性、ストレージ統合、実行の監視、資格証明の管理といった機能が備わっています。
Oracle Site Guardの主な機能は次のとおりです。
Oracle Site Guardでは、操作ワークフローの特定のポイントにカスタム・スクリプトを挿入することにより、組込みの障害時リカバリ機能を拡張できます。
拡張性のメカニズムを利用すると、障害時リカバリ操作中に、カスタマイズしたサイト固有および操作固有のアクティビティを実行するメカニズムが提供されます。
拡張に関して、挿入できるスクリプトの数に制限はありません。これらのユーザー定義のスクリプトが実行される時間および方法と実行される順序は、スクリプト・タイプを選択して構成できます。
この項では、次の項目について説明します。
Oracle Site Guardには、その機能の拡張に使用できるいくつかの種類のスクリプトが用意されています。
Oracle Site Guardの機能をカスタマイズおよび拡張するには、次のいずれかのスクリプトを使用します。
カスタム事前チェック・スクリプト
これらのスクリプトは、ユーザーによって用意されます。操作計画を実行する前に発生する事前チェックまたはヘルス・チェック・フェーズ中のユーザー定義のアクティビティを実行するために使用されます。カスタム事前チェック・スクリプトは、事前チェックまたはヘルス・チェックの一部として実行されます。
前処理スクリプト
これらのスクリプトは、ユーザーによって用意されます。操作計画内のサイト固有の操作の開始時にユーザー定義のアクティビティを実行するために使用されます。前処理スクリプトは、サイトでOracle Site Guardがターゲット関連の操作を実行する前に実行されます。
後処理スクリプト
これらのスクリプトは、ユーザーによって用意されます。操作計画内のサイト固有の操作の終了時にユーザー定義のアクティビティを実行するために使用されます。後処理スクリプトは、サイトでOracle Site Guardがターゲット関連のすべての操作を実行した後に実行されます。
グローバル前処理スクリプト
これらのスクリプトは、ユーザーによって用意されます。操作計画の開始時にユーザー定義の操作固有のアクティビティを実行するために使用されます。グローバル前処理スクリプトは、Oracle Site Guardが最初のサイト(通常はプライマリ・サイト)で操作を実行する前に実行されます。
グローバル後処理スクリプト
これらのスクリプトは、ユーザーによって用意されます。操作計画の終了時にユーザー定義の操作固有のアクティビティを実行するために使用されます。グローバル後処理スクリプトは、Oracle Site Guardが最後のサイト(通常はスタンバイ・サイト)で操作を完了した後に実行されます。
マウント/アンマウント・スクリプト
これらのスクリプトはOracle Site Guardにバンドルされていますが、独自のスクリプトを定義することもできます。操作中にファイル・システムでマウントおよびアンマウント操作を実行するために使用されます。すべてのサービスおよびアプリケーションがプライマリ・サイトで停止した後、アンマウント・スクリプトが実行されます。サービスまたはアプリケーションがスタンバイ・サイトで起動する前に、マウント・スクリプトが実行されます。
ストレージ・スクリプト
これらのスクリプトはOracle Site Guardにバンドルされていますが、独自のストレージ・スクリプトを定義することもできます。これらは、障害時リカバリ操作中にOracle Sun ZFS Applianceのストレージ・ロール・リバーサル・アクティビティを実行するために使用します。ストレージ・スイッチオーバー・スクリプトは、スイッチオーバー操作中に実行され、マウント・スクリプトが実行される前にスタンバイ・サイトで実行されます。ストレージ・フェイルオーバー・スクリプトは、フェイルオーバー操作中に実行され、マウント・スクリプトが実行される前にスタンバイ・サイトで実行されます。
表2-1は、Oracle Site Guardでサイトを設定する際に使用する様々なタイプのスクリプトの概要を示しています。
図2-2および図2-3は、スクリプトのソースおよび機能のビジュアル表現を示しています。
表2-1 Oracle Site Guardで使用されるスクリプトのタイプ
| スクリプトのタイプ | ユーザーが用意するか(カスタム・スクリプト) | Oracle Site Guardに用意されているものか(バンドルされたスクリプト) |
|---|---|---|
カスタム事前チェック・スクリプト |
はい(オプション) |
いいえ |
前処理スクリプト、後処理スクリプト、グローバル前処理スクリプト、グローバル後処理スクリプト |
はい(オプション) |
いいえ |
マウントおよびアンマウント・スクリプト |
はい(オプション) |
はい。ユーザーが構成する必要があります。 |
ストレージ・スイッチオーバーおよびストレージ・フェイルオーバー・スクリプト |
はい(オプション) |
はい。Oracle Sun ZFSおよびNetApp MetroCluster専用です。ユーザーが構成します。) |
図2-2 Oracle Site Guardスクリプト: 実行内容
図2-3 Oracle Site Guardスクリプト: 提供者
Oracle Site Guard操作の実行ワークフローは、実行される操作(スイッチオーバー、フェイルオーバーまたは起動/停止)に応じて異なります。
図2-4、図2-5および図2-6は、Oracle Site Guardが各種操作用のユーザー定義のスクリプトを実行する順序を示しています。
図2-4 スイッチオーバー操作のスクリプトの実行順序
図2-5 フェイルオーバー操作のスクリプトの実行順序
注意:
フェイルオーバー中にプライマリ・サイトで実行されるオプションのスクリプトは、スイッチオーバー操作中にプライマリ・サイトで実行したスクリプトと同じです。ユーザーがフェイルオーバー中にプライマリ・サイトを停止した場合、プライマリ・サイトのスクリプトはフェイルオーバー操作の一部としてのみ実行されます。
図2-6 開始または停止操作のスクリプトの実行順序
注意:
カスタム事前チェック・スクリプトは、フェイルオーバー操作のためにプライマリ・サイトで実行するようスケジュールされます。ただし、プライマリ・サイトがアクセス不可または使用不可である可能性があるため、これらのスクリプトが「エラー時も続行」モードで実行するよう設定されます。
スクリプト・タイプおよび実行時動作に応じて、ユーザー定義のスクリプトのパスを適切な形式で構成します。
Oracle Site Guardは、構成パスおよびユーザーが用意したスクリプトのタイプを使用してスクリプトの場所(パス)を決定します。表2-2は、様々なタイプのスクリプト、ユーザーが指定する必要がある対応するスクリプト・パスおよびOracle Site Guardが抽出および使用するコンポーネントの構成方法を示しています。次の表に示すスクリプト・パス形式のみがサポートされています。
表2-2 Enterprise Managerソフトウェア・ライブラリのスクリプト・パス
| スクリプト・タイプ | ユーザー構成パス | Oracle Site Guardが抽出したスクリプト・パス |
|---|---|---|
シェル・スクリプト |
|
|
Perlスクリプト |
|
|
Pythonスクリプト |
|
|
表2-3 カスタム・スクリプトのスクリプト・パス
| スクリプト・タイプ | ユーザー構成パス | Oracle Site Guardが抽出したスクリプト・パス |
|---|---|---|
シェル・スクリプト |
|
|
Perlスクリプト |
|
|
Pythonスクリプト |
|
|
障害時リカバリ操作を開始する前に、事前チェックおよびヘルス・チェックを実行することによって、スタンバイ・サイトが本番のロールを実行できる状態にあることを確認します。
障害時リカバリ計画を成功させるには、計画が保護対象の環境を正確に表している必要があります。保護対象サイトでトポロジの変更や構成のずれが発生すると、障害時リカバリ計画と環境との間の同期が失われてしまい、計画が部分的に、または完全に意味のないものになってしまう可能性があります。障害時リカバリ計画と保護対象環境との間のこの相違は、障害時リカバリが実際に実行されるまで検出されないことがよくあります。
Oracle Site Guardでは、事前チェックおよびヘルス・チェックを使用して、この問題を解決できます。
事前チェックは、サイトの障害時リカバリの準備状況を評価するために必要に応じて使用する自動化されたプロシージャです。
事前チェックは、選択された操作計画が成功するかどうかをチェックするために、自動的に(スタンドアロン・モードで)実行できます。また、操作計画を実行する前に起動することもできます。この場合、事前チェックが失敗すると、操作計画は実行されません。操作計画の前に起動される事前チェックはオプションであり、必要に応じてスキップできます。
ヘルス・チェックは、障害時リカバリの準備状況を継続的に評価するために定期的に実行される事前チェックです。
ヘルス・チェックは特定の操作計画に対して構成され、ユーザー指定のスケジュールが関連付けられる必要があります。たとえば、スタンバイ・サイトへのスイッチオーバー計画に関連付けられたヘルス・チェックを、その操作計画の忠実度を継続的に監視するために、毎週水曜日と土曜日の午前0時30分に実行するように設定できます。また、ヘルス・チェックの結果が電子メールで通知されるように選択することもできます。
構成済の各操作計画にヘルス・チェックを関連付けることができ、異なる計画のヘルス・チェックは相互に独立して実行できます。操作計画のヘルス・チェックは、いつでも停止できます。
Oracle Site Guardは、事前チェック中およびヘルス・チェック中に次のチェックを実行します。
計画されている障害時リカバリ操作の対象となるすべてのホストに接続可能かどうかをチェックします。このチェック中に、Oracle Site Guardは、ホストに構成された資格証明を使用して各ホストにログインします。これにより、ホストに接続可能であり、ディレクティブおよびスクリプトを実行するためにアクセスできます。
プライマリおよびスタンバイ・データベースが正しく構成され、Data Guard保護が正しく機能しているかどうかをチェックします。このチェックは次を確認します。
プライマリおよびスタンバイ・データベース名が正しい。
データベース・ログイン資格証明が正しい。
Data Guard Brokerがデータベースのスイッチオーバーを実行できます。
データベース・フラッシュバック・ステータスが「オン」に設定されています。
Data Guard REDOおよびトランスポート・ラグがユーザーによって指定された制限内です。
ZFSストレージ・レプリケーションが正しく機能しているかどうかをチェックします。このチェックは次を確認します。
レプリケーション・ラグがユーザーによって指定された制限内です。
ソースおよび宛先ZFSアプライアンスに接続可能です。
ログイン資格証明が有効です。
レプリケーション・アクションが正しく構成されています。
各構成済ユーザー・スクリプトが正しい場所にあるかどうかを確認してユーザー・スクリプトが正しく構成されているかどうかをチェックします。
スイッチオーバーまたはフェイルオーバー中にレプリケートされたファイル・システムをマウントできるかどうかをチェックします。これを確認するため、チェックでは、マウント操作のためにファイル・システム・マウント・ポイントが存在しアクセスできることを確認します。
Data GuardおよびZFSレプリケーション・ラグ・チェックがユーザーによって指定された範囲内かどうかをチェックします。
注意:
関連付けられた事前チェックは、作成される操作計画ごとに自動的に作成されます。ただし、ヘルス・チェックは操作計画に対して明示的にスケジュールする必要があります。
該当するいずれかの操作で実行されるカスタム(ユーザー定義)スクリプトを追加することによって、組込みの事前チェックおよびヘルス・チェックをカスタマイズできます。
これにより、障害時リカバリ・ワークフローに含まれる必要があるサードパーティ・コンポーネントの事前チェックを挿入して、Oracle Site Guard事前チェックおよびヘルス・チェック機能を拡張できます。カスタム事前チェック・スクリプトは、組込み事前チェックと同じように機能します。カスタム事前チェック・スクリプトが例外を検出し、エラーを戻す場合、その事前チェック手順は失敗とみなされ、スクリプトの構成方法(スクリプト実行手順が属性「エラー時に停止」で構成されている場合など)に応じて、障害時リカバリ操作が中断する可能性があります。
プライマリ・サイトとスタンバイ・サイトとの間のデータ・レプリケーションの効率性および適時性は、ネットワークの帯域幅、輻輳、待機時間、ストレージ・アプライアンスの負荷、レプリケートされるデータの量などの多くの要因により異なります。
障害時リカバリ構成には、通常、アプリケーション層とデータベース層によりデータ・ストレージ用に使用される、1つ以上のストレージ・アプライアンスとデータ・ストアが含まれます。障害時リカバリ時にこれらのデータをスタンバイ・サイトで利用できるようにするために、これらのデータ・ストアをプライマリ・サイトからスタンバイ・サイトに、連続レプリケーションまたは定期的なレプリケーションを使用してレプリケートする必要があります。サイトのスイッチオーバーまたはフェイルオーバーの操作を正常に完了するには、Oracle Site Guardは障害時リカバリ・プロセスの一部として、ストレージ・ロール・リバーサルも実行する必要があります。
プライマリ・サイトのソース・データとスタンバイ・サイトのレプリケートされたデータとの間には、ある程度のラグが存在することが一般的です。Oracle Site Guardには、障害時リカバリ操作の実行開始前に許容されるレプリケーション・ラグの量を構成するためのメカニズムが用意されています。障害時リカバリ操作の事前チェック・フェーズで、Oracle Site Guardは現在のレプリケーション・ラグをチェックします。ラグがユーザー指定のしきい値を超えている場合、Oracle Site Guardは障害時リカバリ操作を実行しません。
次のラグ・チェック・パラメータを構成できます。
データベース・ラグ・チェック
このパラメータは、Oracle Data Guardにより管理されるREDO適用およびREDO転送に許容されるラグを指定します。
ZFSラグ・チェック
デフォルトのSite Guardは、ZFSによって管理されるアプリケーション層のストレージ・レプリケーションに対して適切なラグ値を決定します。または、ZFSラグ・チェック・パラメータを使用して、許容ラグ値を指定することもできます。
障害時リカバリ中に、アプリケーションをスタンバイ・サイトに移行する前にストレージ・レプリケーションの方向を逆にしてストレージ・アプライアンスを再構成する必要があります。
ストレージ操作の管理は、障害時リカバリに不可欠なものです。Oracle Site Guardには、様々なストレージ・テクノロジに対するストレージ管理および統合オプションが用意されています。
次の項では、Oracle Site Guardのストレージ統合オプションについて説明します。
Oracle Site Guardには、Oracle Sun ZFSストレージ・ロール・リバーサルを編成するための組込みスクリプトが用意されています。
Oracle Sun ZFSストレージ・アプライアンスをデプロイする場合、バンドルされているストレージ管理スクリプトzfs_storage_role_reversal.shを使用して、Oracle Site Guardの障害時リカバリ操作の一部としてOracle Sun ZFSストレージ・ロール・リバーサルを編成できます。
Oracle Site Guardには、NetApp MetroClusterストレージ・ロール・リバーサルを編成するための組込みスクリプトが用意されています
NetApp MetroClusterの障害時リカバリ構成をデプロイした場合、バンドルされているNetAppストレージ管理スクリプトsiteguard_netapp_control.shを使用して、Oracle Site Guardの障害時リカバリ操作の一部としてNetApp MetroClusterストレージ・ロール・リバーサルを編成できます。詳細は、https://support.oracle.comでOracle Site Guard Feature For NetApp MetroClusterというタイトルのMOSノート(ドキュメントID 1964220)を参照してください。
Oracle Site Guardでは、独自のカスタム・ストレージ管理スクリプトをOracle Site Guard操作計画に組み込めるようにすることで、ストレージ・テクノロジとの統合を提供しています。
操作計画実行のストレージ・スクリプト実行フェーズ中に独自のカスタム・ストレージ管理スクリプトを起動することにより、サードパーティ・ストレージ・テクノロジに対するストレージ・ロール・リバーサルを実装できます。
Oracle Site Guardには、ファイル・システムをマウントおよびアンマウントするための組込みスクリプトが用意されています。また、カスタム・スクリプトを使用して、ファイル・システムを管理することもできます。
Oracle Site Guardでは、ストレージ・テクノロジと統合できるだけでなく、ファイル・システムを管理するための独自のスクリプトを組み込むことができます。たとえば、スイッチオーバー操作時に、プライマリ・サイトで複数層アプリケーションが使用するファイル・システムがアプリケーションの停止後にアンマウントされ、その後、スタンバイ・サイトでそれらのファイル・システムのレプリケートされたバージョンがアプリケーションの起動前にマウントされます。プライマリ・サイトとスタンバイ・サイトでのアプリケーション・サーバーに対するこれらのアンマウントおよびマウントの操作は、組み込まれているスクリプト統合のためのメカニズムを使用して編成できます。Oracle Site Guardには、ファイル・システムのマウントおよびアンマウントの操作を処理するためのmount_umount.shスクリプトが用意されています。または、操作計画の適切な時点で起動する独自のカスタム・スクリプトを定義できます。
スタンバイ・サイトの検証では、スタンバイ・サイトを完全に機能するサイトに変換して、スタンバイ・サイトをテストおよび検証できます。
サイト・ガードの標準の障害時リカバリ構成では、スタンバイ・サイトはオフラインになっており、ビジネス操作には使用できません。
スタンバイ・サイトを検証用にオープンするには、サイトに対して「検証用にオープン」タイプの操作計画を構成および実行します。テストおよび検証が完了したら、「スタンバイに戻す」タイプの操作計画を構成および実行することによって、サイトをスタンバイ・ロールに戻すことができます。
スタンバイ・サイトを検証用にオープンするときのOracle Site Guardの動作は次のとおりです。
スタンバイ・データベースをフィジカル・スタンバイ・データベースからスナップショット・スタンバイ・データベースに変換します。このモードでは、Data Guard REDOログがプライマリからスタンバイに引き続き送信されますが、ログはスタンバイ・データベースには適用されません。(Oracle Site Guardで「スタンバイに戻す」操作を実行することによって)データベースをフィジカル・スタンバイ・データベースに戻すと、累積されたREDOログが適用されます。
このサイト・ガード構成の中で、ZFSによってレプリケートされたプロジェクトをクローニングして、そのプロジェクトの読取りおよび書込み可能コピーを作成します。クローニングされたプロジェクト内のファイル・システムがマウントされ、スタンバイ・サイトのアプリケーションで使用できるようになります。スタンバイ・サイトのアプリケーションによって、クローニングされたプロジェクトの読取りまたは書込みが行われている間も、プライマリ・サイトからスタンバイ・サイトへのZFSレプリケーションは(最初に構成されたとおりに)中断することなく続行されます。検証用にオープンされたスタンバイ・サイトが「スタンバイに戻す」操作によってクローズされると、クローニングされたファイル・システムはアンマウントされ、「検証用にオープン」操作の一環として作成されたZFSクローンは破棄されます。
他の操作計画で使用されることを想定して、構成されているすべてのグローバル前処理スクリプトとグローバル後処理スクリプト、前処理スクリプトと後処理スクリプト、およびカスタム事前チェック・スクリプトを実行します。
スタンバイ・サイトが検証用にオープンされても、データベースREDO転送およびZFSストレージ・レプリケーションは構成どおりに中断することなく続行されるため、リカバリ・ポイント目標(RPO)には影響は生じません。プライマリ・サイトのトランザクション・データが失われることはありません。ただし、受信スイッチオーバーまたはフェイルオーバーがスタンバイ・サイトによってすぐに受け入れられるわけではないため、リカバリ時間目標(RTO)には影響が生じます。プライマリ・サイトからスタンバイ・サイトにスイッチオーバーまたはフェイルオーバーされるようにするには、事前にスタンバイ・サイトを(標準)スタンバイ・モードに戻す必要があります。
スタンバイ・サイトを検証モードでオープンすると、次のようなメリットがあります。
障害時リカバリ構成の正確性の信頼度が増します。また、スタンバイ・サイトが稼働を開始し、期待どおりに動作することを検証できます。
パッチのテスト、新しい構成の検証および分析やレポートの生成にスタンバイ・サイトを使用することで、リソース使用率が向上します。
注意:
検証用にオープンされたスタンバイ・サイトに関する重要事項を次に示します。
検証用にオープンされたスタンバイ・サイトは障害時リカバリ・サイトとして使用できません。プライマリ・サイトからの受信スイッチオーバーまたはフェイルオーバーが受け入れられるようにするには、事前に(「スタンバイに戻す」を使用して)スタンバイ・ロールに戻す必要があります。
検証用にオープンされたスタンバイ・サイトを本番アクティビティ(カスタマ・トラフィック)用に使用することは避ける必要があります。サイトがスタンバイ・サイトに戻ると、サイトで実行されたトランザクションはすべて破棄されるためです。
物理スタンバイに対するプライマリ・データベースにRedoRoutesプロパティが割り当てられている場合は、ルールで(LOCAL : ... )として指定する必要があります。そうでない場合は、Data Guard Brokerがスナップショット・スタンバイへの変換を実行できず、操作はORA-16692エラーで失敗します。ローカル・プライマリ・データベース値を持つRedoRoutesを構成する方法の詳細は、Oracle Databaseのドキュメントを参照してください。
実行グループを使用すると、パラレル実行される(共通機能領域内での)実行の手順順序をカスタマイズできます。
サイト・ガード操作計画は、計画の実行時に共通機能領域またはターゲット・タイプを処理するいくつかの個別バケットで構成されます。たとえば、1つのバケットにサイトのすべてのデータベース・インスタンスが含まれます。これらの各バケットは、通常、そのバケットの対象となるターゲット・タイプまたは機能を処理する1つ以上の手順で構成されます。また、バケットの実行モードにより、バケットの手順の実行形式(シリアルまたはパラレル)が決まります。
たとえば、一般的な操作計画には、サイト内の次の各機能領域を対象としたすべての手順を含む個別バケットが含まれています。
すべてのOracle WebLogic Serverドメインの停止
すべてのデータベースのスイッチオーバー
すべての前処理スクリプトの実行
すべてのマウントまたはアンマウント・スクリプトの実行
実行グループを使用すると、バケット内の正確な編成順序を定義できます。たとえば、実行グループ3に含まれる操作計画手順は、実行グループ2のすべての手順の実行が終了してから、すべてパラレル実行されます。同様に、実行グループ3のいずれの操作計画手順も、実行グループ4のいずれかの手順が開始されるまでに必ず終了します。したがって、各操作計画手順を特定のグループの特定のバケットに配置して、それぞれの操作計画手順を実行するタイミングを決定できます。
操作計画を作成すると、最初に各バケットの実行モードがパラレルとしてマークされ、バケット内のすべての手順が実行グループ1に配置されます。ただし、操作計画を編集し、各手順の実行グループをカスタマイズしてその実行順序を指定できます。
注意:
実行モードがシリアルのバケットでは、すべての手順が順次実行されるため、実行グループは無関係になります。これは、各手順をそれぞれ独自の実行グループに配置することと同じです。サイト・ガードでは、操作計画を編集し、シリアル実行バケットの手順の順序を変更できます。
サイト・ガードUIで計画を表示または編集する際には、「実行グループ」列はデフォルトで非表示になります。
カスタム事前チェックは実行グループに配置できますが、定期事前チェックは配置できず、常にパラレル実行されます。
この項では、Oracle Site Guardで実行計画をカスタマイズ、実行および監視する方法について説明します。
Oracle Site Guard操作計画を実行する場合、実行前に計画をカスタマイズし、計画の実行を監視し、計画実行中に発生したエラーを管理し、変更後に計画実行を再試行できます。
この項では、次の項目について説明します。
Oracle Site Guard操作を環境に合わせてカスタマイズする方法について説明します。
Oracle Site Guard操作計画は、環境の特性に合わせてカスタマイズできます。具体的には、任意の操作手順を次の方法でカスタマイズできます。
手順を実行のために有効化または無効化するかどうかの指定(無効化された手順は実行中にスキップされます)
実行順序の別の時点への手順の移動(ドメイン・グループ内で起動する管理対象サーバーの順序の変更など)
手順のエラーを処理する方法(つまり、エラーが発生した場合に操作実行を停止するか、続行するか)を指定します。
特定のグループの手順をシリアル実行するかパラレル実行するか(たとえば、すべての管理対象サーバーを同時に起動するか、管理対象サーバーを一度に1つずつ起動するか)を指定します。
Oracle Enterprise Manager Cloud Controlコンソールの「プロシージャ・アクティビティ」ページで操作結果を監視できます。
Oracle Site Guardの障害時リカバリ操作は、Oracle Enterprise Managerのデプロイメント・プロシージャとして実行されます。Oracle Site Guard操作の「プロシージャ・アクティビティ」画面には、各操作計画の手順が階層化されて表示され、実行された各手順の結果がグラフィカルなアイコンで示されます。手順が成功するとチェック・マークが、失敗するとバツ印が表示されます。アイコン
は、手順がスキップされ、実行対象として構成されていないことを示します。このメカニズムにより、操作計画の進捗サマリーを視覚的に把握できます。
「操作アクティビティ」ページで表示する場合、各操作計画または事前チェックの実行詳細が結果のサブ手順を含むトップレベル手順の階層として編成されます。最初に、トップレベル手順のみがユーザーに表示されます。結果のサブ手順は各トップレベル手順内で閉じられて表示されません。ただし、操作アクティビティの各トップレベル手順は、トップレベル手順をクリックして展開し、階層を移動して下位のサブ手順を選択することにより、さらに詳細に確認できます。各サブ手順の実行ログも、詳細に確認できます。操作アクティビティがこのように階層で編成されているので、操作計画の結果をあらゆる詳細レベルで確認できます。
Oracle Site Guard操作計画の各手順には、構成できる関連付けられたエラー・モードがあります。
このエラー・モードは、手順の実行時に発生するエラーをOracle Site Guardがどのように処理するかを定義するものです。
次のエラー・モードを指定できます。
エラー時に停止
このモードでは、現在の手順の実行中にエラーが検出されると、Oracle Site Guardは操作計画の実行を停止します。
エラー時も続行
このモードでは、現在の手順の実行中にエラーが検出されでも、Oracle Site Guardは次の手順の実行を継続します。
操作の実行時に発生したエラーが原因で実行が停止された場合、エラーの原因となった問題を解決して、操作を再試行できます。
Oracle Site Guardは、失敗した操作の実行を、失敗が発生した手順から再開します。「remove」をクリックして失敗した手順を無視し、操作を再試行することもできます。この場合、Oracle Site Guardは失敗した手順を無視し、失敗した手順の直後から操作計画の実行を再開します。
Oracle Site Guardで使用される資格証明を管理する方法について説明します。
Oracle Enterprise Managerには、アイデンティティを管理したり、Oracle Enterprise Managerターゲットへのアクセスが承認および認証の下で行われるようにするための資格証明管理フレームワークが用意されています。
通常、名前付き資格証明を使用するようにOracle Site Guardを構成する前に、Enterprise Managerでこれらの資格証明を設定できます。資格証明を構成すると、保護対象サイトのすべての管理対象ターゲットに対するアクセスに対して、これらの資格証明がOracle Site Guardにより使用されます。
サイトのトポロジによっては、ホスト、Oracleデータベース・インスタンス、WebLogic Server、他のターゲット・タイプなどの様々なターゲットに対して、Oracle Site Guardによる名前付き資格証明の使用が必要な場合があります。Enterprise Managerでの資格証明の設定の詳細は、資格証明の設定に関する項を参照してください。
Oracle Site Guard操作で資格証明を使用する方法について説明します。
必要なターゲット資格証明をEnterprise Managerの資格証明管理フレームワークで構成したら、それらをOracle Site Guardの資格証明構成プロセスで使用できます。Oracle Site Guardの資格証明構成では、障害時リカバリ操作でOracle Site Guardがアクセスおよび制御するターゲットに対して有効な資格証明を関連付ける必要があります。資格証明を設定し、それらをターゲットに関連付ける方法の詳細は、「資格証明アソシエーションの作成」を参照してください。
Oracle Site Guardでは、Oracle Enterprise Managerにより提供されるユーザー・アカウント・フレームワークを使用する、ロールベースのアクセス制御(RBAC)が提供されます。
Oracle Enterprise Managerでは、Enterprise Manager内の様々な領域や機能に対して、事前構成されたロールが提供されます。これらの管理者ロールの1つはEM_SG_ADMINISTRATORで、Enterprise Manager内のOracle Site Guardに焦点を当てたアクティビティ用にカスタマイズされています。この組込みロールを使用することにより、Oracle Site Guardの管理タスクに焦点を当てたユーザーを作成できます。または、カスタマイズした独自のロールやユーザーを作成して、Oracle Site Guardの機能へのロールベースのアクセスを非常に柔軟にチューニングできます。
ロールベースのアクセス制御を設定する方法の詳細は、「Oracle Site Guardの管理者ユーザーの作成」を参照してください。
Oracle Site Guardには、障害時リカバリ操作中に、Oracle DatabaseのスイッチオーバーやOracle WebLogic Serverの起動や停止といった一般的なアクティビティを実行できるように、すぐに使用できるスクリプトが用意されています。
これらのスクリプトはEnterprise Managerソフトウェア・ライブラリの一部として含まれ、すべての必要なスクリプトが操作実行中に適用可能なホストに自動的にデプロイされます。ただし、バンドルされているスクリプトに加えて、操作の一部として他のカスタム・スクリプトを自動的にデプロイして実行する必要がある場合があります。Oracle Site Guardは、独自のカスタム・スクリプトをEnterprise Managerソフトウェア・ライブラリにアップロードし、計画を作成する場合にこれらのスクリプトを操作計画に追加するメカニズムを提供します。
Enterprise Managerソフトウェア・ライブラリの一部であるスクリプトを使用する別の利点は、これらのスクリプトが実行時にすべての構成されたスクリプトに自動的にデプロイされることです。一方、Enterprise Managerソフトウェア・ライブラリの一部でないユーザー・スクリプトは、操作計画の実行を開始する前に構成されたスクリプト・ホストごとに手動でデプロイする必要があります。
ユーザーがEnterprise Managerソフトウェア・ライブラリに追加できる様々なタイプのスクリプトの詳細は、「拡張性」を参照してください。
資格証明のセットを資格証明リポジトリに追加し、それらの資格証明を使用して実行するようスクリプトを構成できます。
外部的にデプロイまたはソフトウェア・ライブラリを介してデプロイされるユーザー定義のスクリプトは、スクリプトを実行するホストに構成された資格証明を使用して通常実行されます。これらの資格証明はEnterprise Manager資格証明管理フレームワークに構成および保持され、ホスト通常資格証明またはホスト特権資格証明と呼ばれます。
他のセットの資格証明を資格証明リポジトリに追加し、このセットの資格証明で実行するスクリプトを構成することもできます。これは、スクリプト・ホストに構成された標準(ホスト通常)または特権(ホスト特権)資格証明と異なる資格証明権限がスクリプトに必要な場合に便利です。たとえば、特定のユーザーIDを使用してホストのサーバー・プロセスを停止するために実行する必要があるスクリプトです。
Oracle Site Guardは、資格証明を構成済スクリプトに渡すためのメカニズムを提供します。
ユーザー定義のスクリプトは、最初に他のエンティティで認証する必要があるアクションを頻繁に実行し、この認証を実行するために1つ以上のセットの資格証明が必要です。スクリプトに資格証明をハードコードすることを回避したり、スクリプトにクリアテキスト・パラメータとして資格証明を確実に渡すため、Oracle Site Guardは1つ以上のセットの資格証明を構成されたスクリプトに安全に渡すメカニズムを提供します。これらの資格証明は、Oracle Enterprise Managerの資格証明管理フレームワークの安全な方法で格納および保持されます。これらの資格証明がユーザー・スクリプトのパラメータとして構成および関連付けられた後、Oracle Site Guardは実行時間にこれらの資格証明を暗号化してユーザー・スクリプトに渡します。ユーザー・スクリプトはこれらの資格証明を抽出して認証するために使用できます。
ユーザー・スクリプト内の暗号化された資格証明の抽出の詳細は、「パラメータとして資格証明を渡す」を参照してください。
Oracle Site Guardのワークフロー(または操作)は、Enterprise Managerデプロイメント・プロシージャとしてモデル化されます。
Oracle Site Guardでは、障害時リカバリ操作用に、用途が明確な次のワークフローが提供されています。
プライマリ・サイトに障害または計画外の停止が発生した場合には、Oracle Site Guardは次の手順を自動化して、トポロジ内でスタンバイ・サイトが本番のロールを引き継げるようにします。
プライマリ・サイトで実行しているサービスとアプリケーションを停止し、プライマリ・サイトのストレージをアンマウントします。
プライマリ・サイトからスタンバイ・サイトへの進行中のレプリケーションを無効にし、ロール・リバーサルを実行します。
Oracle Data Guard Brokerを使用して、Oracle Databaseのフェイルオーバーまたはスイッチオーバーを実行します。
スタンバイ・サイトにレプリケートされたストレージ(ファイル・システム)をマウントします。
スタンバイ・サイトでサービスとアプリケーションを起動します。この時点で、スタンバイ・サイトが本番のロールを引き継ぎます。
注意:
連続ストレージ・レプリケーションが構成されていない場合、Site Guard操作を開始する前にプライマリ・サイトからスタンバイ・サイトへの最終的なストレージ・レプリケーションを実行することをお薦めします。ただし、プライマリ・サイトに失敗した場合、この最終的なレプリケーションを実行できない可能性があります。
Oracle Site Guardのワークフローに対しては、Enterprise Managerのプロシージャ管理フレームワークを使用して、監視、一時停止、再開および停止を行うことができます。
このワークフローは、本番アクティビティをプライマリ・サイトからスタンバイ・サイトに移行するためのものです。
スイッチオーバー・ワークフローは、本番アクティビティをプライマリ・サイトからスタンバイ・サイトに制御された方法で移行します。図2-7は、典型的なスイッチオーバー・ワークフローで実行される手順を示しています。
注意:
障害時リカバリ操作は、トポロジおよびサイト構成に応じて異なる各種操作で構成されます。
図2-7 スイッチオーバー・ワークフロー
このワークフローは、本番アクティビティをスタンバイ・サイトに移行するためのものです。
フェイルオーバー・ワークフローは、本番アクティビティをスタンバイ・サイトに強制的に移行します。フェイルオーバー・ワークフローが開始されると、Oracle Site Guardにより、プライマリ・サイトは利用できないと想定され、すべての保護対象アプリケーションがスタンバイ・サイトで起動されます。図2-8は、典型的なフェイルオーバー・ワークフローで実行される手順を示しています。
図2-8 フェイルオーバー・ワークフロー
このワークフローは、本番サイトのアクティビティを起動するためのものです。
起動ワークフローは、本番サイトのアクティビティを起動します。このワークフローは、通常、メンテナンス後にサイトを起動するため、またはスイッチオーバーなどの大規模なワークフローのテストの一部としてサイトの起動が可能であることをテストするために使用されます。図2-9は、典型的な起動ワークフローで実行される手順を示しています。
図2-9 起動ワークフロー
このワークフローは、本番サイトのアクティビティを停止するためのものです。
停止ワークフローは、本番サイトのアクティビティを停止します。このワークフローは、通常、メンテナンス用にサイトを停止するため、またはスイッチオーバーなどの大規模なワークフローのテストの一部としてサイトの停止が可能であることをテストするために使用されます。図2-10は、典型的な停止ワークフローで実行される手順を示しています。
図2-10 停止ワークフロー
このワークフローは、スタンバイ・サイトを機能サイトに変換して、テストおよび検証できるようにするためのものです。
検証用にオープン・ワークフローは、スタンバイ・サイトを機能サイトに変換します。通常、このワークフローは、テストおよび検証のために、スタンバイ・サイトを機能サイトに変換する目的で使用します。図2-11は、典型的な検証用にオープン・ワークフローで実行される手順を示しています。
図2-11 検証用にオープン・ワークフロー
このワークフローは、検証用にオープンされたサイトをスタンバイ・サイトに戻すためのものです。
スタンバイに戻すワークフローは、検証用にオープンされたサイトをスタンバイ・サイトに戻します。通常、このワークフローは、スイッチオーバーやフェイルオーバーなどの障害時リカバリ操作のために、検証用にオープンされたサイトをスタンバイ・サイトに戻す目的で使用します。図2-12は、典型的なスタンバイに戻すワークフローで実行される手順の例を示しています。
図2-12 スタンバイに戻すワークフロー
