| Oracle® Site Guard管理者ガイド リリース12.1.0.7 E57717-02 |
|
 前 |
 次 |
この章では、Oracle Site Guardの用語およびEnterprise Manager Cloud Controlコンソールでのサイトのアーキテクチャについて説明します。Oracle Site Guardにより実行される様々な操作のワークフローの概要についても説明します。
次のトピックが含まれます:
このドキュメントでは次の用語を使用します。
ターゲット
ターゲットは、エンタープライズ内のインフラストラクチャおよびビジネス・コンポーネントを表すコアEnterprise Managerエンティティです。ビジネスが効率的に機能するには、これらのコンポーネントを監視および管理する必要があります。ターゲットの例としては、Oracle Fusion MiddlewareファームやOracleデータベース・インスタンスがあります。Oracle Site Guardの障害時リカバリ操作は、1つのサイトの1つ以上のターゲットを保護するように設計されます。
サイト
データセンター内の関連するエンティティを論理的にグループ化したものです。たとえば、Web層、ミドルウェア層およびデータベース層のソフトウェア・コンポーネント、さらには関連付けられたストレージのすべてが、1つのサイトを構成することがあります。Oracle Site Guardは、サイトに対する障害時リカバリ操作を実行します。Oracle Site Guardでは、1つのデータセンターに対して複数のサイトを定義でき、各サイトに対する障害時リカバリ操作を独立して管理できます。
プライマリ・サイト
Oracle Site Guardによる保護対象として構成されているアクティブ・アプリケーション(一連のターゲット)を現在ホストしているサイトです。プライマリ・サイトは、本番サイトとも呼ばれます。
スタンバイ・サイト
障害時リカバリ操作が発生したときに保護対象アプリケーション(一連のターゲット)をホストすることが意図されているサイトです。
ロール
サイトの現在の役割です。ロールはプライマリまたはスタンバイのいずれかです。
スイッチオーバー
本番サイトとスタンバイ・サイトの役割を逆転するプロセスは、スイッチオーバーと呼ばれます。スイッチオーバーは、定期的な検証のために行う、または現在の本番サイトで計画メンテナンスを実行するための計画済の操作です。スイッチオーバー中に、現在のスタンバイ・サイトが新しい本番サイトになり、現在の本番サイトが新しいスタンバイ・サイトになります。
フェイルオーバー
(本番サイトに障害が発生したことなどが原因で)本番サイトが突然使用できなくなった後で、現在のスタンバイ・サイトを新しい本番サイトにするプロセスは、フェイルオーバーと呼ばれます。
操作計画
操作計画には、特定のOracle Site Guard操作の実行フローが含まれます。障害時リカバリ操作の手順を実行する順序、およびシリアル、パラレルなどのその他の属性を定義します。
事前チェック
事前チェックは、事前に順序付けられた一連のチェックで、操作計画が、保護対象として想定される環境に準拠しているかどうかを確認します。事前チェックは、障害時リカバリの準備状況を評価するために使用され、必要に応じて実行されます。
ヘルス・チェック
事前に順序付けられた一連のチェックであるヘルス・チェックは、ユーザー定義のスケジュールに基づいて定期的に実行されるようにプログラムできます。ヘルス・チェックは、障害時リカバリの準備状況を継続的に評価するために使用されます。
カスタム事前チェック・スクリプト
カスタム事前チェック・スクリプトは、Oracle Site Guard操作計画の事前チェック・プロシージャの一部として実行されるユーザー定義のスクリプトです。事前チェック・スクリプトの数と実行順序は、操作計画の一部として定義できます。
前処理スクリプト
前処理スクリプトはサイト固有のユーザー定義のスクリプトで、Oracle Site Guard操作の開始時にサイトで実行されます。前処理スクリプトの数と実行順序は、操作計画の一部として定義できます。
後処理スクリプト
後処理スクリプトはサイト固有のユーザー定義のスクリプトで、Oracle Site Guard操作の終了時にサイトで実行されます。後処理スクリプトの数と実行順序は、操作計画の一部として定義できます。
グローバル前処理スクリプト
グローバル前処理スクリプトは操作固有のユーザー定義のスクリプトで、Oracle Site Guard操作計画の開始時にサイトで実行されます。グローバル前処理スクリプトの数と実行順序は、操作計画の一部として定義できます。
グローバル後処理スクリプト
グローバル後処理スクリプトは操作固有のユーザー定義のスクリプトで、Oracle Site Guard操作計画の終了時にサイトで実行されます。グローバル後処理スクリプトの数と実行順序は、操作計画の一部として定義できます。
スーパー管理者
スーパー管理者は特権ユーザーの1つで、Enterprise Managerのすべてのターゲットと、Oracle Site Guardのすべての構成、操作およびアクティビティにアクセスできます。
サイトは、1つ以上のユーザー・アプリケーションを実行するソフトウェア・コンポーネントおよび関連付けられたハードウェアの論理的なグループです。たとえば、サイトは、ソフトウェア・コンポーネントに関連付けられた記憶域とともに、Oracle Fusion Middlewareインスタンス、Oracle Fusion Applicationインスタンス、Oracleデータベースをデプロイするために使用されるサーバー(ホスト)のコレクションで構成できます。Oracle Site Guardは、Enterprise Manager Cloud Control汎用システム・ターゲットを使用してサイトを表現します。いずれのサイトも、それがプライマリであるかスタンバイであるかにかかわらず、Oracle DatabaseおよびOracle Fusion Middlewareドメインなどの他のターゲット・タイプのコレクションである汎用システムとして表現されます。Oracle Site Guardは、プライマリ・サイトとスタンバイ・サイトの両方が同じEnterprise Manager Cloud Controlデプロイメントにより管理されるEnterprise Managerデプロイメントのみをサポートしています。
図2-1は、同じ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データベース(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 Sun ZFS Applianceのストレージ・ロール・リバーサル・アクティビティを実行するために使用します。ストレージ・スイッチオーバー・スクリプトがスイッチオーバー操作中に実行され、マウント・スクリプトが実行される前にスタンバイ・サイトで実行されます。ストレージ・フェイルオーバー・スクリプトがフェイルオーバー操作中に実行され、マウント・スクリプトが実行される前にスタンバイ・サイトで実行されます。
表2-1は、Oracle Site Guardを使用してサイトを設定中に使用される様々なタイプのスクリプトの概要を示しています。
図2-2および図2-3は、スクリプトのソースおよび機能のビジュアル表現を示しています。
表2-1 Oracle Site Guardで使用されるスクリプトのタイプ
| スクリプトのタイプ | ユーザーが用意していますか(カスタム・スクリプト) | Oracle Site Guardが用意していますか(バンドルされたスクリプト) |
|---|---|---|
|
カスタム事前チェック・スクリプト |
はい(オプション) |
いいえ |
|
前処理スクリプト、後処理スクリプト、グローバル前処理スクリプト、グローバル後処理スクリプト |
はい(オプション) |
いいえ |
|
マウントおよびアンマウント・スクリプト |
はい(オプション) |
はい(ユーザーが構成する必要があります) |
|
ストレージ・スイッチオーバーおよびストレージ・フェイルオーバー・スクリプト |
はい(オプション) |
はい(Oracle Sun ZFSのみ。ユーザーが構成します。) |
図2-4、図2-5および図2-6は、Oracle Site Guardが異なる操作のために様々なタイプのユーザー定義のスクリプトを実行する順序を示しています。
|
注意: フェイルオーバー中にプライマリ・サイトで実行されるオプションのスクリプトは、スイッチオーバー操作中にプライマリ・サイトで実行したスクリプトと同じです。ユーザーがフェイルオーバー中にプライマリ・サイトを停止した場合、プライマリ・サイトのスクリプトはフェイルオーバー操作の一部としてのみ実行されます。 |
|
注意: カスタム事前チェック・スクリプトは、フェイルオーバー操作のためにプライマリ・サイトで実行するようスケジュールされます。ただし、プライマリ・サイトがアクセス不可または使用不可である可能性があるため、これらのスクリプトが「エラー時も続行」モードで実行するよう設定されます。 |
スクリプトのタイプおよび必要な実行時動作に応じて、適切な形式を使用してスクリプトのパスを構成する必要があります。Oracle Site Guardは、構成パスおよびユーザーが用意したスクリプトのタイプを使用してスクリプトの場所(パス)を決定します。表2-2は、様々なタイプのスクリプト、ユーザーが指定する必要がある対応するスクリプト・パスおよびOracle Site Guardが抽出および使用するコンポーネントの構成方法の例を示しています。表2-2にリストされていないスクリプト・パス形式はサポートされていません。
表2-2 例: スクリプト・パスの構成
| スクリプトの場所 | スクリプト・タイプ | ユーザー構成パス | Oracle Site Guardが抽出したスクリプト・パス |
|---|---|---|---|
|
Enterprise Managerソフトウェア・ライブラリ |
シェル・スクリプト |
|
|
|
Perlスクリプト |
|
|
|
|
Pythonスクリプト |
|
|
|
|
ユーザー定義(カスタム) |
シェル・スクリプト |
|
|
|
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の事前チェックおよびヘルス・チェック機能を拡張できます。カスタム事前チェック・スクリプトは、組込み事前チェック機能と同じように機能します。ユーザー定義の事前チェック・スクリプトが例外を検出し、エラーをSite Guardに戻す場合、その事前チェック手順は失敗とみなされ、事前チェック・スクリプトの構成方法(スクリプト実行手順が属性「エラー時に停止」で構成されている場合など)に応じて、障害時リカバリ操作が中断する可能性があります。
障害時リカバリ構成には、通常、アプリケーション層とデータベース層によりデータ・ストレージ用に使用される、1つ以上のストレージ・アプライアンスとデータ・ストアが含まれます。障害時リカバリ時にこれらのデータをスタンバイ・サイトで利用できるようにするために、これらのデータ・ストアをプライマリ・サイトからスタンバイ・サイトに、連続レプリケーションまたは定期的なレプリケーションを使用してレプリケートする必要があります。サイトのスイッチオーバーまたはフェイルオーバーの操作を正常に完了するには、Oracle Site Guardは障害時リカバリ・プロセスの一部として、ストレージ・ロール・リバーサルも実行する必要があります。
プライマリ・サイトとスタンバイ・サイトとの間のデータ・レプリケーションの効率性および適時性は大きく変動する特徴があり、ネットワークの帯域幅、輻輳、待機時間、ストレージ・アプライアンスの負荷、レプリケートされるデータの量などの多くの要因により異なります。プライマリ・サイトのソース・データとスタンバイ・サイトのレプリケートされたデータとの間には、ある程度のラグが存在することが一般的です。Oracle Site Guardには、障害時リカバリ操作が実行開始前に許容されるレプリケーション・ラグの量を構成するためのメカニズムが用意されています。障害時リカバリ操作の事前チェック・フェーズで、Oracle Site Guardは現在のレプリケーション・ラグをチェックします。ラグがユーザー指定のしきい値を超えている場合、Oracle Site Guardは障害時リカバリ操作を実行しません。
次のラグ・チェック・パラメータを構成できます。
データベース・ラグ・チェック
このパラメータは、Oracle Data Guardにより管理されるREDO適用およびREDO転送に許容されるラグを指定します。
ZFSラグ・チェック
このパラメータは、ZFSにより管理されるアプリケーション層ストレージ・レプリケーションに許容されるラグを指定します。
ストレージ管理操作は、障害時リカバリ操作の重要な部分です。障害時リカバリ中に、アプリケーションをスタンバイ・サイトに移行する前にストレージ・レプリケーションを逆にしてストレージ・アプライアンスを再構成する必要があります。Oracle Site Guardには、様々なストレージ・テクノロジに対するストレージ統合オプションが用意されています。
次のトピックは、Oracle Site Guardにより提供されるストレージ統合オプションを説明します。
Oracle Site Guardには、Oracle Sun ZFSストレージに対する統合機能が組み込まれています。Oracle Sun ZFSストレージ・アプライアンスをデプロイする場合、Oracle Site Guardにバンドルされているストレージ管理スクリプト(zfs_storage_role_reversal.sh)を使用して、Oracle Site Guardの障害時リカバリ操作の一部としてSun ZFSストレージ・ロール・リバーサルを編成できます。
Oracle Site Guardでは、他のストレージ・テクノロジ独自のカスタム・ストレージ管理スクリプトをOracle Site Guard操作計画に組み込めるスクリプト統合フレームワークが提供されており、他のストレージ・テクノロジを統合できます。操作計画実行のストレージ・スクリプト実行フェーズ中に独自のカスタム・ストレージ管理スクリプトを起動することにより、サードパーティ・ストレージ・テクノロジに対するストレージ・ロール・リバーサルを実装できます。
Oracle Site Guardでは、ストレージ管理スクリプトだけでなく、ファイル・システムをマウントまたはアンマウントするためのユーザー・スクリプトも統合できます。たとえば、スイッチオーバー操作時に、プライマリ・サイトで複数層アプリケーションが使用するファイル・システムがアプリケーションの停止後にアンマウントされ、その後、スタンバイ・サイトでそれらのファイル・システムのレプリケートされたバージョンがアプリケーションの起動前にマウントされます。プライマリ・サイトとスタンバイ・サイトでのアプリケーション・サーバーに対するこれらのアンマウントおよびマウントの操作は、組み込まれているスクリプト統合のためのメカニズムを使用して編成できます。Oracle Site Guardには、mount_umount.shというファイル・システムのマウントおよびアンマウントの操作を処理するためのスクリプトがバンドルされています。または、操作計画の適切な時点で起動する独自のカスタム・スクリプトを定義できます。
Oracle Site Guard操作計画を実行する場合、実行前に計画をカスタマイズし、計画の実行を監視し、計画実行中に発生したエラーを管理し、変更後に計画実行を再試行できます。
この項には次のトピックが含まれます:
Oracle Site Guardの操作計画は、トポロジと環境に応じてカスタマイズできます。操作計画の各手順は、次のパラメータを使用してカスタマイズできます。
手順を実行のために有効化または無効化するかどうかの指定(無効化された手順は実行中にスキップされます)
実行順序の別の時点への手順の移動(ドメイン・グループ内で起動する管理対象サーバーの順序の変更など)
手順のエラーを処理する方法の指定(つまり、エラーが発生した場合の操作の実行の停止または継続)
指定されたグループの手順を順次または並行して実行する必要があるかどうかの指定(指定されたドメイン・グループのすべての管理対象サーバーの同時(並行)起動の試行など)
Oracle Site Guardの障害時リカバリ操作は、Oracle Enterprise Managerプロシージャとして実行され、各操作の結果はOracle Enterprise Manager Cloud Controlコンソールの「プロシージャ・アクティビティ」ページで監視できます。Oracle Site Guard操作の「プロシージャ・アクティビティ」画面には、各操作計画の手順が階層化されて表示され、実行された各手順の結果がグラフィカルなアイコンで示されます。手順に成功すると緑のチェック・マークが表示され、手順に失敗すると赤の十字が表示されます。アイコン
は、手順がスキップされて実行のために構成されていないことを示します。このメカニズムにより、操作計画の進捗サマリーを視覚的に把握できます。
「操作アクティビティ」ページで表示する場合、各操作計画または事前チェックの実行詳細が結果のサブ手順を含むトップレベル手順の階層として編成されます。最初に、トップレベル手順のみがユーザーに表示されます。結果のサブ手順は各トップレベル手順内で閉じられて表示されません。ただし、操作アクティビティの各トップレベル手順は、トップレベル手順をクリックして展開し、階層を移動して下位のサブ手順を選択することにより、さらに詳細に確認できます。各サブ手順の実行ログも、詳細に確認できます。操作アクティビティがこのように階層で編成されているので、操作計画の結果をあらゆる詳細レベルで確認できます。
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では、IDを管理するための包括的な資格証明管理フレームワークが用意されており、Enterprise Managerターゲットへのアクセスが承認および認証の下で行われるようにしています。通常、名前付き資格証明を使用するようにOracle Site Guardを構成する前に、Enterprise Managerでこれらの資格証明を設定できます。資格証明を構成すると、保護対象サイトのすべての管理対象ターゲットに対するアクセスに対して、これらの資格証明がOracle Site Guardにより使用されます。
サイトのトポロジによっては、ホスト、Oracleデータベース・インスタンス、WebLogic Server、他のターゲット・タイプなどの様々なターゲットに対して、Oracle Site Guardによる名前付き資格証明の使用が必要な場合があります。Enterprise Managerで資格証明を設定する方法の詳細は、Oracle Enterprise Managerライフサイクル管理ガイドを参照してください。
必要なターゲット資格証明をEnterprise Managerの資格証明管理フレームワークで構成したら、これらの資格証明をOracle Site Guardの資格証明構成プロセスで使用できます。Oracle Site Guardの資格証明構成では、障害時リカバリ操作でOracle Site Guardがアクセスおよび制御するターゲットに対して有効な資格証明を関連付ける必要があります。資格証明の設定と関連付けを行う方法の詳細は、第4.3項「資格証明アソシエーションの作成」を参照してください。
Oracle Site Guardでは、Enterprise Managerにより提供されるユーザー・アカウント・フレームワークを使用する、ロールベースのアクセス制御(RBAC)が提供されます。Enterprise Managerでは、Enterprise Manager内の様々な領域や機能に対して、事前構成されたロールが提供されます。これらの管理者ロールの1つはEM_SG_ADMINISTRATORで、Enterprise Manager内のOracle Site Guardに焦点を当てたアクティビティ用にカスタマイズされています。この組込みロールを使用することにより、Oracle Site Guardの管理タスクに焦点を当てたユーザーを作成できます。または、カスタマイズした独自のロールやユーザーを作成して、Oracle Site Guardの機能へのロールベースのアクセスを非常に柔軟にチューニングできます。
ロールベースのアクセス制御を設定する方法の詳細は、第3.2.2項「Oracle Site Guardの管理者ユーザーの作成」を参照してください。
Oracle Site Guardには、Oracle DatabaseのスイッチオーバーやOracle Weblogic Serverの起動または停止など、障害時リカバリ操作の実行中に通常必要であるアクティビティを実行するための組込みスクリプト(バンドルされているスクリプト)が含まれます。これらの組込みスクリプトはEnterprise Managerソフトウェア・ライブラリの一部として含まれ、すべての必要なスクリプトが操作の実行中に適用可能なホストに自動的にデプロイされます。ただし、組込みスクリプトに加えて、ユーザーは操作の一部として他のカスタム・スクリプトを自動的にデプロイして実行する必要がある場合があります。Oracle Site Guardは、ユーザーが独自のカスタム・スクリプトをEnterprise Managerソフトウェア・ライブラリにアップロードして計画を作成する場合にこれらのスクリプトを操作計画に追加するメカニズムを提供します。
Enterprise Managerソフトウェア・ライブラリの一部であるスクリプトを使用する別の利点は、これらのスクリプトが実行時にすべての構成されたスクリプトに自動的にデプロイされることです。一方、Enterprise Managerソフトウェア・ライブラリの一部でないユーザー・スクリプトは、操作計画の実行を開始する前に構成されたスクリプト・ホストごとに手動でデプロイする必要があります。
ユーザーがEnterprise Managerソフトウェア・ライブラリに追加できる様々なタイプのスクリプトの詳細は、第2.3.1項「拡張性」を参照してください。
外部的にデプロイまたはソフトウェア・ライブラリを介してデプロイされるユーザー定義のスクリプトは、スクリプトを実行するホストに構成された資格証明を使用して通常実行されます。これらの資格証明はEnterprise Manager資格証明管理フレームワークに構成および保持され、ホスト通常資格証明またはホスト特権資格証明と呼ばれます。ただし、他のセットの資格証明を資格証明リポジトリに追加し、この代替セットの資格証明で実行するスクリプトを構成することもできます。これは、スクリプト・ホストに構成された標準(ホスト通常)または特権(ホスト特権)資格証明と異なる資格証明権限がスクリプトに必要な場合に便利です。たとえば、特定のユーザーIDを使用してホストのサーバー・プロセスを停止するために実行する必要があるスクリプトです。
ユーザー定義のスクリプトは、最初に他のエンティティで認証する必要があるアクションを頻繁に実行し、この認証を実行するために1つ以上のセットの資格証明が必要です。スクリプトに資格証明をハードコードすることを回避したり、スクリプトにクリアテキスト・パラメータとして資格証明を確実に渡すため、Oracle Site Guardは1つ以上のセットの資格証明を構成されたスクリプトに安全に渡すメカニズムを提供します。これらの資格証明は、Oracle Enterprise Managerの資格証明管理フレームワークの安全な方法で格納および保持されます。これらの資格証明がユーザー・スクリプトのパラメータとして構成および関連付けられた後、Oracle Site Guardは実行時間にこれらの資格証明を暗号化してユーザー・スクリプトに渡します。ユーザー・スクリプトはこれらの資格証明を抽出して認証するために使用できます。
ユーザー・スクリプト内の暗号化された資格証明の抽出の詳細は、付録A「パラメータとして渡された資格証明の抽出(例)」を参照してください。
Oracle Site Guardのワークフローは、操作としても扱われ、Enterprise Managerデプロイメント・プロシージャとしてモデル化されます。
プライマリ・サイトに障害または計画外の停止が発生した場合には、Oracle Site Guardは次の手順を自動化して、トポロジ内でスタンバイ・サイトが本番のロールを引き継げるようにします。
プライマリ・サイトで実行しているサービスとアプリケーションを停止し、プライマリ・サイトのストレージをアンマウントします。
プライマリ・サイトからスタンバイ・サイトへのストレージ・レプリケーションを停止して、ストレージ・ロール・リバーサルを実行します。
Oracle Data Guard Brokerを使用して、Oracle Databaseのフェイルオーバーまたはスイッチオーバーを実行します。
スタンバイ・サイトにレプリケートされたストレージ(ファイル・システム)をマウントします。
スタンバイ・サイトでサービスとアプリケーションを起動します。この時点で、スタンバイ・サイトが本番のロールを引き継ぎます。
|
注意: 連続ストレージ・レプリケーションが構成されていない場合、Site Guard操作を開始する前にプライマリ・サイトからスタンバイ・サイトへの最終的なストレージ・レプリケーションを実行することをお薦めします。ただし、プライマリ・サイトに失敗した場合、この最終的なレプリケーションを実行できない可能性があります。 |
Oracle Site Guardのワークフローに対しては、Enterprise Managerのプロシージャ管理フレームワークを使用して、監視、一時停止、再開および停止を行うことができます。
Oracle Site Guardでは、障害時リカバリ操作用に、用途が明確な次のワークフローが提供されています。
スイッチオーバー・ワークフローは、本番アクティビティをプライマリ・サイトからスタンバイ・サイトに制御された方法で移行します。図2-7は、典型的なスイッチオーバー・ワークフローで実行される手順の例を示します。
フェイルオーバー・ワークフローは、本番アクティビティをスタンバイ・サイトに強制的に移行します。フェイルオーバー・ワークフローが開始されると、Oracle Site Guardにより、プライマリ・サイトは利用できないと想定され、すべての保護対象アプリケーションがスタンバイ・サイトで起動されます。図2-8は、典型的なフェイルオーバー・ワークフローで実行される手順の例を示します。
起動ワークフローは、本番アクティビティをサイトで起動します。このワークフローは、通常、メンテナンス後にサイトを起動するため、またはスイッチオーバーなどの大規模なワークフローのテストの一部としてサイトの起動が可能であることをテストするために使用されます。図2-9は、典型的な起動ワークフローで実行される手順の例を示します。
停止ワークフローは、本番アクティビティをサイトで停止します。このワークフローは、通常、メンテナンス用にサイトを停止するため、またはスイッチオーバーなどの大規模なワークフローのテストの一部としてサイトの停止が可能であることをテストするために使用されます。図2-10は、典型的な停止ワークフローで実行される手順の例を示します。
