10 リカバリ・アプライアンスのモニタリング

この章では、メトリックの構成および構成設定を含め、リカバリ・アプライアンスの基本的なモニタリングを実行する方法について説明します。

リカバリ・アプライアンスのモニタリングについて

この項には次のトピックが含まれます:

• リカバリ・アプライアンスをモニタリングする目的

• リカバリ・アプライアンス・モニタリング機能の概要

• リカバリ・アプライアンスをモニタリングするためのCloud Controlインタフェース

• リカバリ・アプライアンスをモニタリングするための基本的なタスク

関連項目:

アーキテクチャの概要については、「保護ポリシー」を参照してください

リカバリ・アプライアンスをモニタリングする目的

進行中のリカバリ・アプライアンス管理において、リカバリ・アプライアンスの全体的な健全性を定期的にモニタリングし、保護されたデータベース、バックアップ・ジョブおよびレプリケーション・ジョブ、記憶域使用状況のステータスを確認することは、非常に重要です。

リカバリ・アプライアンス・モニタリング機能の概要

この項では、Oracleで提供されているモニタリング・ツールについて説明します。

Cloud Control

リカバリ・アプライアンス管理者の主要なモニタリング・ツールは、Oracle Enterprise Manager Cloud Control (Cloud Control)インシデントおよびイベント通知フレームワークです。プライマリ・インタフェースはリカバリ・アプライアンスのホームページで、警告、アラート、エラーが目立つように表示されます。Cloud Controlに統合されたモニタリング・フレームワークは、問題を管理し、解決するまで追跡する有効な方法です。

領域管理は、リカバリ・アプライアンスの管理において非常に重要です。記憶域需要に対応する十分な時間を確保するには、予測される記憶域ニーズがいつ使用可能な記憶域量の合計に達するかを知っておく必要があります。Cloud Controlには、記憶域使用量の総計に関する警告およびエラー・メッセージが表示されるため、必要な変更を加えるための十分な時間を確保できます。

Cloud Controlでは、管理目標にあわせて設定をカスタマイズできます。たとえば、特定のデータベースのリカバリ・ウィンドウ目標を満たすのに必要な領域が、予約済領域のユーザー定義比率である場合、警告を受信することができます。電子メール・アラートを構成して、システムにログインすることなく、問題の通知をただちに受信することもできます。

関連項目:

Cloud Controlオンライン・ヘルプ

Oracle Configuration Manager

Oracle Configuration Managerは構成情報を収集し(デフォルトでは毎日)、Oracle Management Repositoryにアップロードします。サービス・リクエストを記録する場合、構成データがサービス・リクエストに関連付けられます。Oracle Support Serviceは、データを分析してよりよいサービスを提供します。

Oracle Configuration Managerには、次の利点があります。

• サポートの問題を解決する時間の短縮

• 問題を回避するための事前の対策の提供

• ベスト・プラクティスおよびOracleナレッジ・ベースへのアクセスの改善

• 顧客のビジネス・ニーズの理解の向上および一貫したレスポンスとサービスの提供

各OracleホームにはOracle Configuration Managerソフトウェアがインストールされます。一般に、各Oracleホームには、My Oracle Support (MOS)資格証明で情報を収集してアップロードするコレクタが構成されています。配置されているOracleホームおよびコレクタが切断されているか構成されていないOracleホームの情報を収集するセントラル・コレクタも構成できます。

関連項目:

• Oracle Configuration Managerの概要は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。

• Oracle Configuration Managerコレクション概要

自動サービス・リクエスト(ASR)

自動サービス・リクエスト(ASR)は、特定のリカバリ・アプライアンス・ハードウェアに障害が発生すると自動的にサービス・リクエストを開く機能です。ASRは、ディスク、ファン、電源装など、最も一般的なサーバー・コンポーネントで障害を検出します。ASRはサーバー・コンポーネントのみをモニターし、発生する可能性のあるすべての障害を検出するわけではありません。

ASRは、SMTP、SNMPアラートなど、カスタマ・データ・センター内のその他のモニタリング・メカニズムにかわるものではありません。交換ハードウェアの発送を促進および簡素化する補完メカニズムです。

関連項目:

ASRの設定方法については、『Zero Data Loss Recovery Applianceオーナーズ・ガイド』を参照してください。

リカバリ・アプライアンスをモニタリングするためのCloud Controlインタフェース

リカバリ・アプライアンスをモニタリングするための主要なインタフェースは、リカバリ・アプライアンスのホームページになります。次の図に示すように、存在する警告とアラートがホームページに表示されます。

図dblra_monitor.pngの説明

ホームページの次のセクションで、モニタリング情報を表示します。

• サマリー

  このセクションでは、問題なし、アラートあり、警告ありのデータベースの数を表示します。Cloud Controlでは、アラートは特定のメトリック条件が発生したことを示すインジケータです。たとえば、アラートはメトリックしきい値に達したことを示します。

• メディア・マネージャおよびレプリケーション

  これらのセクションでは、copy-to-tapeおよびリカバリ・アプライアンス・レプリケーション・サービスのステータスを表示します。

• 保護されたデータベースの問題

  このセクションでは、保護されたデータベースのバックアップ・ステータスの概要を示します。また、影響を受けたデータベースを示すためのカテゴリ・フィルタを使用できます。

• インシデントとイベント

  このセクションでは、リカバリ・アプライアンスおよび関連付けられているすべてのターゲットについてレポートされたインシデントとイベントを表示します。ターゲットおよびカテゴリ別にフィルタリングできます。「サマリー」リンクをクリックして、「インシデント・マネージャ」にドリルダウンし、インシデントの詳細情報を表示できます。

  注意:

  根本にある問題が解決されると、警告は自動的にクリアされます。

関連項目:

• 「リカバリ・アプライアンス・ホームページへのアクセス」

• リカバリ・アプライアンスのホームページのコンポーネントの詳細は、Cloud Controlオンライン・ヘルプを参照してください。

リカバリ・アプライアンスをモニタリングするための基本的なタスク

この項では、リカバリ・アプライアンスをモニタリングする場合の基本的なタスクについて説明します。次の図は、「リカバリ・アプライアンスのワークフロー」に説明されている全体的なワークフローを、モニタリング・タスクを強調して示したものです。

図10-1 リカバリ・アプライアンス・ワークフローでのモニタリング・タスク

「図10-1 リカバリ・アプライアンス・ワークフローでのモニタリング・タスク」の説明

通常、モニタリング・タスクを実行する順序は次のとおりです。

1. 構成フェーズでは、メトリック設定を構成します(「リカバリ・アプライアンスの設定と構成」を参照)。たとえば、しきい値を上回った場合に警告を発行するようにリカバリ・アプライアンスを構成できます。

   「メトリックと収集設定の変更」で、このタスクについて説明します。

2. 進行中のメンテナンス・フェーズでは(「Recovery Applianceのメンテナンス・タスク」を参照)、必要に応じて保護ポリシーを変更します。一般的な変更タスクには次のものがあります。

   • 必要に応じて、インシデントを調査します。

     「インシデント・マネージャ・ページの表示」で、このタスクについて説明します。

   • 必要に応じて、メトリックを表示します。

     「メトリックと収集設定の変更」で、このタスクについて説明します。

メトリックと収集設定の変更

メトリックと収集設定ページには、ターゲット・メトリック収集のしきい値とスケジュールの詳細が表示されます。このページを使用して、ターゲット・メトリックやその他の収集対象アイテムの警告しきい値とクリティカルしきい値、および収集の時間間隔を編集できます。このページでは、変更可能な設定の場合、「編集」列に鉛筆アイコンが示されます。

前提条件

RASYSとしてリカバリ・アプライアンスのメタデータ・データベースにログインする必要があります。

前提条件

データベースのリカバリ・ウィンドウ目標を満たすのに必要な領域が、予約済領域設定の80%である場合、警告を受信したいと考えています。クリティカルしきい値は95%にします。

メトリックと収集設定を変更するには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

2. 「リカバリ・アプライアンス」メニューから、「モニタリング」をクリックし、「メトリックと収集設定」設定をクリックします。

   「メトリックと収集設定」ページが表示されます。

   
   図metric_and_coll_sett.pngの説明

3. 「表示」メニューで「すべてのメトリック」が選択されていない場合は、選択します。

   ページがリフレッシュされ、使用可能なすべてのメトリックが表示されます。

4. 「保護されたデータベース」を展開します。

5. 「予約済領域のパーセンテージとしてのリカバリ・ウィンドウ領域」という行が見つかるまで、ページを下にスクロールします。

6. この行に対して、次の値を入力して「OK」をクリックします。

   • 「警告のしきい値」列に80と入力します。

   • 「クリティカルのしきい値」列に95と入力します。

   確認メッセージが表示されます。

   注意:

   これらのしきい値を上回ったときに生成されるアラート・メッセージのデフォルト・テキストを変更するには、鉛筆アイコンをクリックします。

7. 必要に応じて、他のメトリック設定を変更します。

関連項目:

メトリックと収集設定の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

インシデント・マネージャ・ページの表示

「インシデントとイベント」セクションには、リカバリ・アプライアンスのすべてのインシデント、イベントおよび警告が表示されます。任意のインシデントをクリックして、インシデント・マネージャ・ページを開きます。インシデント・マネージャを使用すると、環境に影響するインシデントと問題を1か所で検索、表示、管理および解決できます。

前提条件

RASYSとしてメタデータ・データベースにログインする必要があります。

前提条件

このチュートリアルでは、リカバリ・アプライアンスのリカバリ・アプライアンス・ホームページの「インシデントとイベント」セクションに警告が表示されると想定します。詳細を取得できます。

インシデント・マネージャ・ページを表示するには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

2. 可能性のある問題については、「インシデントとイベント」セクションを確認してください。

   たとえば、このセクションには次の警告が表示されます。

   ORA-64739: RECOVERY_WINDOW_GOAL is lost for database STORE22 
   

3. 関心のあるインシデントのサマリー・リンクをクリックします。

   選択した警告のインシデント・マネージャ・ページが、一般サブページが選択された状態で表示されます。

   
   図incident.pngの説明

4. サブページをクリックすると、インシデントの詳細情報を取得できます。

関連項目:

インシデント・マネージャの詳細は、Cloud Controlオンライン・ヘルプを参照してください。

パフォーマンスの監視

リカバリ・アプライアンスには、システムのパフォーマンスを評価する際に役立つユーティリティとして、rastat.plとnetwork_throughput_test.shの2つが付属しています。

rastatユーティリティによるパフォーマンス統計の生成

rastat.plは、リカバリ・アプライアンスに対するテストを実行してパフォーマンス統計を収集するコマンドライン・ユーティリティで、システムのボトルネックを特定する際に便利です。

テストでは、次の統計が生成されます。

• ネットワーク経由でリカバリ・アプライアンスに送信されたバックアップ・データ

• ネットワーク経由でリカバリ・アプライアンスから受信したリストア・データ

• リカバリ・アプライアンスのASMディスク・グループの読取りまたは書込みI/O

• リカバリ・アプライアンスのコンテナ・ファイルの読取りまたは書込みI/O

• リカバリ・アプライアンスのコンテナ・ファイルの割当て率

このユーティリティは、保護されたデータベースまたはアップストリームのリカバリ・アプライアンスであるLinuxまたはUNIXベースのクライアント・マシンから実行できるPerlのスクリプトです。ただし、I/Oテストはリカバリ・アプライアンス・サーバーから直接実行することもできます。

保護された1つ以上のデータベースで複数のテストを並行して実行すれば、実環境をシミュレートできます。それぞれのテスト結果は、個々のクライアントのパフォーマンスを表します。保護された他のデータベースとリカバリ・アプライアンスのテスト中に、バックアップやリストア、または他のテストなど継続中のアクティビティがあると、統計結果に影響する場合があります。

rastatユーティリティを実行する前提条件

rastatユーティリティを実行する前に、次の前提条件が満たされていることを確認してください。

• rastatを実行するプラットフォームが、LinuxまたはUNIXであること。

• 保護されたデータベースからユーティリティを実行する場合は、リカバリ・アプライアンス計算サーバーの/opt/oracle.RecoveryAppliance/client/ディレクトリからrastat.plファイルをコピーします。

• 「保護されたデータベースの登録」の説明に従って、保護されたデータベースをリカバリ・アプライアンスに登録する手順を完了します。

• ユーティリティを実行する際に、該当するオプションを使用して設定する予定がない場合は、環境変数$ORACLE_HOMEと$ORACLE_SIDが構成されていることを確認します。

rastatユーティリティの実行

この項では、rastat.plを実行する方法を説明したうえで、各種のパフォーマンス・テストを実行する方法の例と、その出力サンプルを示します。

注意:

NETBACKUPとNETRESTOREのテストで、標準出力に結果が表示されない場合は、sbtio<pid>.logログ・ファイルを見れば結果を確認できます。

rastatユーティリティを実行するには、次のようにします。

1. 「rastatユーティリティを実行する前提条件」を参照して、ユーティリティを実行するシステムが前提条件を満たしていることを確認してください。

2. コマンド・プロンプト・ウィンドウを開きます。

3. 実行するテストの適切なコマンド構文を入力し、[Enter]キーを押します。

   一般的な構文とテストごとのオプションは、「rastatユーティリティのリファレンス」を参照してください。

例1: rastatを実行してバックアップのパフォーマンスをテスト

次の例では、NETBACKUPテストを指定して、バックアップ・ファイルのサイズを2048MBに設定し、リカバリ・アプライアンスのVPCユーザー接続文字列を指定して、--parmsオプションでRMAN構成を設定します。

>$ORACLE_HOME/perl/bin/perl rastat.pl --test=NETBACKUP --filesize=2048M 
--catalog=rman/rman@inst2 --parms='SBT_LIBRARY=/u01/oracle/lib/libra.so, 
ENV=(RA_WALLET=location=file:/u01/oracle/dbs/ra_wallet 
credential_alias=ra-scan:1521/zdlra5:dedicated)'

NETWORK TEST FROM PROTECTED DATABASE TO RECOVERY APPLIANCE

393 MB/s, 2048 MB sent

例2: rastatを実行して、リカバリ・アプライアンスのASMディスク・グループからの読取りI/Oをテスト

次の例では、ASMREADテストを指定して、テスト・ファイルのサイズを2048MBに設定し、リカバリ・アプライアンスのSYSユーザー接続文字列を指定して、読取り元のディスク・グループとして+RCVAREAを指定します。

>$ORACLE_HOME/perl/bin/perl rastat.pl --test=ASMREAD --filesize=2048M 
--rasys=admin/admin@inst2 --diskgroup=+RCVAREA

RECOVERY APPLIANCE READ IO TEST FROM DISK

Disk Group: +RCVAREA

2048 MB, 6.06s read IO time, .65s CPU time, 337.99 MB/s, 10.79% CPU usage

PL/SQL procedure successfully completed.

例3: rastatを実行して、リカバリ・アプライアンスのコンテナ・グループからの書込みI/Oをテスト

次の例では、CONTAINERWRITEテストを指定して、テスト・ファイルのサイズを2048MBに設定し、リカバリ・アプライアンスのSYSユーザー接続文字列を指定して、書込み先のディスク・グループとしてBLOCK_POOLコンテナ・グループを指定します。

>$ORACLE_HOME/perl/bin/perl rastat.pl --test=CONTAINERWRITE --filesize=2048M 
--rasys=admin/admin@inst2 --diskgroup=/:BLOCK_POOL 

RECOVERY APPLIANCE WRITE IO TEST TO CONTAINER FILES

Disk Group: /:BLOCK_POOL

2048 MB, 9.55s write IO time, 3.50s CPU time, 214.35 MB/s, 36.60% CPU usage

PL/SQL procedure successfully completed.

例4: rastatを実行して、リカバリ・アプライアンスのコンテナ・グループへのファイル割当てをテスト

次の例では、CONTAINERALLOCテストを指定して、テスト・ファイルのサイズを2048MBに設定し、リカバリ・アプライアンスのSYSユーザー接続文字列を指定して、書込み先のディスク・グループとしてBLOCK_POOLコンテナ・グループを指定します。

>$ORACLE_HOME/perl/bin/perl rastat.pl --test=CONTAINERALLOC --filesize=2048M 
--rasys=admin/admin@inst2 --diskgroup=/:BLOCK_POOL 

RECOVERY APPLIANCE CONTAINER FILE ALLOCATION TEST

Disk Group: /:BLOCK_POOL

2048 MB, 6.24s allocation time, 3.69s CPU time, 328.34 MB allocated per second, 59.09% CPU usage

PL/SQL procedure successfully completed.

ネットワーク・スループットのテスト

アプライアンスに付属しているnetwork_throughput_test.shスクリプトを使用すると、リカバリ・アプライアンス環境における理論上のネットワーク・スループットを測定できます。

ユーティリティの詳細と使用方法については、My Oracle SupportノートのドキュメントID 2022086.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=2022086.1)を参照してください。