| Oracle Enterprise Manager Grid Controlクイック・スタート・ガイド 10gリリース2（10.2） B31252-01 |
|
 戻る |
 次へ |
企業においては、電子メール、ERP、CRM、アプリケーション、オンライン・バンキング、オンライン・ストア、オンライン株取引などのサービスは、エンドユーザーに有用な機能を提供するエンティティです。通常、これらのサービスが使用される場合に、ユーザーが直面する一般的な問題は、サービスの可用性、重要なアクティビティの実行およびサービスのパフォーマンスです。企業内で実行されるビジネス機能またはアプリケーションを表す1つ以上のサービス・モデルを定義することで、これらの問題を解決できます。サービスの監視は、運用目標と品質保証契約（SLA）の達成に役立ちます。
今日のビジネス・アプリケーションは重要で複雑なので、IT組織が高い基準と可用性でアプリケーションのサービス・レベルを監視して管理することが非常に重要になります。これらのサービスは重要なタイプのビジネス提供を構成するので、これらのサービスを監視し、ビジネス活動に悪い影響を与える前に素早く問題に対処することが、企業においては不可欠です。Enterprise Manager Grid Controlが提供する広範なサービスのモデリングと監視のソリューションは、概要レベルから個別のコンポーネント・レベルに至るまで、サービスを効率よく管理するのに役立ちます。
この章では、サービス管理に関する次の内容について説明します。
システムは、1つ以上のサービスを集合的にホストするターゲットの論理的なグループです。システム内のターゲットは、相互にリレーションシップまたは関連付けを持つことができます。1つのシステムが、1つ以上のサービスをサポートできます。Enterprise Manager Grid Controlでは、システムはターゲット・タイプを構成します。たとえば、Enterprise Managerで電子メール・アプリケーションを監視するには、最初に、データベース、リスナー、アプリケーション・サーバーおよび電子メール・アプリケーションが動作するホスト・ターゲットで構成される、Mail Systemといった名前のシステムを作成します。次に、電子メール・アプリケーションを表すサービス・ターゲットを作成し、それがMail Systemターゲット上で動作することを指定します。
Lindaは、SLAを保守するために、すべてのコンポーネント（技術スタック）およびそれぞれのリレーションシップを理解する必要があります。そのためには、システムを作成して、サービスをシステムと関連付けます。
Enterprise Managerシステムを使用すると、分散したターゲットを論理的に編成し、効率的かつ効果的に管理および監視することができます。
ここでは、システムを作成し、サービスとシステムを関連付けることでサービスを効率よく処理する方法について説明します。
システムを作成するには、次のようにします。
「ターゲット」ページで、「システム」セカンダリ・タブを選択します。
「追加」をクリックします。
システムのタイム・ゾーンとコンポーネント、コンポーネント間の関連付け、表示するグラフ、データの列およびダッシュボードで表示する形式を指定します。
「OK」をクリックします。
「システム」ページが表示されます。作成したシステムが、システムの一覧に追加されています。システムの名前をクリックすると、そのホームページを表示できます。「ダッシュボードの起動」をクリックすると、システムのダッシュボードを表示できます。
作業する必要のあるすべての環境に対して、同じようにシステムを作成できます。
Grid Controlを使用すると、企業内で実行されるビジネス機能またはアプリケーションを表す1つ以上のサービス・モデルを定義できます。サービスの例としては、CRMアプリケーション、オンライン・バンキング、電子メール・サービスなどがあります。比較的簡単な形式のサービスは、DNS、LDAP、POP、SMTPなどのプロトコルでサポートされるビジネス機能です。
定義できるサービス・モデルのタイプとしては、汎用サービス、Webアプリケーションおよび集約サービスがあります。汎用サービスは、Enterprise Managerで作成できる単純なサービス・モデルです。重要なビジネス機能を表すサービス・テストを定義することで、1つ以上のサービス・モデルを定義できます。集約サービスは、1つ以上の他のサービスと論理的に結合されたサービスです。集約サービスの可用性、パフォーマンスおよび使用状況は、構成サービスの可用性、パフォーマンスおよび使用状況によって決まります。Webアプリケーションは、WebベースのアプリケーションまたはWebサイトをモデル化する特別なタイプのサービスです。Webアプリケーション・ターゲットは、Webアプリケーションのすべてのコンポーネントを統合し、アプリケーションの可用性、パフォーマンス、使用状況を決定します。次のサービスを監視することもできます。SLAは、サービスの可用性、パフォーマンスおよび使用状況を評価するために使用されます。サービス・レベルを定期的に監視することで、IT組織は、問題とその潜在的な影響を識別し、サービス障害の根本原因を診断し、SLAに従って問題を解決することができます。サービスの監視は、運用目標とSLAの実現に役立ちます。
サービスに関する作業を行う際に理解しておく必要のあるいくつかの概念について説明します。
可用性: サービスの可用性は、ある時点においてエンド・ユーザーがどの程度サービスにアクセスできるかを示す測定値であり、サービスによって異なります。可用性は、サービス・テストの正常な実行に基づいています。サービスの可用性は、サービスをホストしている基盤のシステムに基づいている場合もあります。キー・ビーコンからのすべてまたは少なくとも1つのトランザクションが終了していれば、サービスは使用可能とみなされます。
サービス・テスト: サービスには、1つ以上のテストを関連付けることができます。これらのテストを使用して、サービスをリモートで監視します。トランザクションは、Webアプリケーションのパフォーマンスと可用性をテストするために使用されるサービス・テストです。Webアプリケーションに対する重要なビジネス・アクティビティをトランザクションとして記録し、それを使用してWebアプリケーションの可用性とパフォーマンスをテストします。トランザクションは、少なくとも1つのビーコンで正常に実行できる場合、使用可能とみなされます。
一部のサービス・テストのリストとそれによって決定される内容を次に示します。
DNS: DNS（Domain Name System）サービスの可用性とパフォーマンス
カスタム・スクリプト: カスタム・スクリプトまたは実行可能ファイルを使用することによるサービスの可用性とパフォーマンス
FTP: FTP（File Transfer Protocol）サービスの可用性とパフォーマンス
Webトランザクション: Webアプリケーションの可用性とパフォーマンス
HTTP Ping: Web URLの可用性とパフォーマンス
ホストPing: ICMP（Internet Control Message Protocol）を介したネットワーク・ホストのレスポンス性
IMAP: IMAP（Internet Message Access Protocol）サービスの可用性とパフォーマンス
DBC SQLタイミング: データベースへのJDBC（Java Database Connectivity）接続の可用性とパフォーマンス
LDAP: LDAP（Lightweight Directory Access Protocol）サービスの可用性とパフォーマンス
NNTP: NNTP（Network News Transfer Protocol）ニュースグループ・サービスの可用性とパフォーマンス
Oracle SQLタイミング: Oracleデータベースへの接続の可用性とパフォーマンス
POP: POP（Post Office Protocol）サービスの可用性とパフォーマンス
ポート・チェッカ: ネットワーク・クライアントが特定のホストのポート・セットに接続できる可能性。
SMTP: SMTP（Simple Mail Transfer Protocol）サービスの可用性とパフォーマンス
TNS Ping: TNS（Transparent Network Substrate）プロトコルを介したデータベースのレスポンス性
SOAP: Webサービスの可用性とレスポンス時間
パフォーマンスと使用状況メトリック: サービスのパフォーマンスと使用状況を測定するためのメトリックを定義できます。パフォーマンスは、エンド・ユーザーから見たサービスのレスポンス時間を示します。使用状況は、システムに対するユーザーの需要または負荷に基づきます。サービス・テストがビーコンによって実行されるときは、パフォーマンス・メトリックはサービス・テストについて収集されます。ビーコンは、一定の間隔でテストを実行する管理エージェントの機能です。複数のビーコンによって収集されたレスポンス・データの最小、最大、および平均を計算できます。また、システム・コンポーネントに対するパフォーマンス・メトリックを収集し、すべてのコンポーネントについての最小値、最大値、平均値を計算することもできます。使用状況メトリックは、サービスがホストされているシステム・コンポーネントの使用状況に基づいて収集されます。特定のコンポーネントの使用状況を監視することも、コンポーネントのセットの最小値、最大値、平均値を統計的に計算することもできます。これらのメトリックに対してしきい値を設定し、通知とアラートを受け取ることもできます。
品質保証契約（SLA）: サービス・レベル・パラメータは、サービスの品質を測定するために使用されます。これらのパラメータは、通常、実際のSLAまたは運用目標に基づきます。サービス・レベル管理機能を使用すると、SLAについて企業を監視し、サービス提供時間内の可用性とパフォーマンスのニーズを満たしていることを検証できます。SLAの場合、運用目標または契約目標に従ってレベルを指定できます。サービス・レベルを監視することで、ビジネス・プロセスとアプリケーションの品質とコンプライアンスを保証できます。
LindaはDBAマネージャですが、彼女のチームはアプリケーションの品質保証契約（SLA）を満たす責任を負っています。SLAは、4つの主要な開発センターからのアプリケーションの可用性とパフォーマンスをカバーしています。サービス・モデルを定義し、Grid Control内からこれらのビジネス・アプリケーションを監視します。その前に、システムを定義し（サービスをサポートする技術スタック）、可用性、パフォーマンス、使用状況の各パラメータとサービス・レベルのルールを定義する必要があります。
一般的なエンド・ユーザー機能をシミュレートするサービス・テストを1つ以上作成することで、サービスを定義できます。これらのサービス・テストを使用して、重要なビジネス機能のパフォーマンスと可用性を測定し、問題があるときにはアラートを受け取り、一般的な問題を識別し、障害の原因を診断することができます。ここでは、サービスを定義して監視するための手順について説明します。
他のターゲットと同様に、サービスは、サービスが存在するホストにOracle Agentソフトウェアをインストールすると検出されます。
サービスを手動で定義するには、次のようにします。
「ターゲット」ページで、「サービス」セカンダリ・タブを選択します。
ページに目的のサービスが表示されない場合は、「追加」リストからサービスのタイプを選択し、「実行」をクリックします。
関連するウィザードが表示されます。たとえば、「汎用サービス」タイプを選択した場合は、汎用サービスの作成ウィザードが表示されます。
「一般」ページで、サービスのタイム・ゾーンと名前を指定します。
既存のシステムをこのサービスと関連付ける場合は、「システムの選択」をクリックします。システムをまだ定義していない場合は、サービスと関連付ける前に作成する必要があります。システムとサービスを関連付けることは必須ではありませんが推奨されます。根本原因分析などの機能は、キー・システム・コンポーネントが正しく定義されていることに依存します。
「可用性」ページで、サービスの可用性タイプを指定します。
「サービス・テスト」ページで、このサービスの可用性を監視するためのサービス・テストを選択します。
選択したテストのタイプに基づいて、関連するテスト・パラメータを指定する必要があります。サービスには、1つ以上のテストを関連付けることができます。これらのテストを使用して、サービスをリモートで監視し、サービスの可用性とパフォーマンスを判定します。サービス・テストを定義する際には、様々なプロトコルを使用できます。
「ビーコン」ページでは、サービスを監視するビーコンの場所を追加し、少なくとも1つのビーコンをキーとして指定します。
少なくとも1つのキー・ビーコンでテストを正常に実行できる場合、サービスは使用可能とみなされます。キーとして指定したビーコンが、サービスの可用性を判定するために使用されます。
「パフォーマンス・メトリック」ページで、サービス・テストまたはシステムに基づいてメトリックを定義するかどうかを指定した後、サービスのパフォーマンスを測定するために使用するメトリックを定義します。
パフォーマンス・メトリックは、各リモート・ビーコンに対するサービスのパフォーマンスを評価するのに役立ちます。一般に、ローカル・ビーコンは、Webアプリケーション・ホストに対してローカルなので、非常に有効で一貫したレスポンス時間を備えています。リモート・ビーコンは、アプリケーションのエンド・ユーザーが経験するレスポンス時間が反映されたデータを提供します。
「使用状況メトリック」ページでは、1つ以上のシステム・コンポーネントのメトリックに基づいて使用状況メトリックを定義します。使用状況メトリックは、システムと関連付けられたサービスに対してのみ定義できます。
選択した内容を確認し、「終了」をクリックします。
他の種類のサービスも同じように定義できます。
サービス・レベルは、サービス品質の尺度であり、営業時間全体に対する、指定されている可用性とパフォーマンスの基準をサービスが満たしている時間の割合として定義されます。これはサービス・レベル・ルールによって定義され、ルールはすべてのサービスに対して自動的に作成されます。
ここでは、作成したサービスに対して自動的に定義されたサービス・レベル・ルールを編集する方法について説明します。
サービス・レベル・ルールを編集するには、次のようにします。
「ターゲット」ページで、「サービス」セカンダリ・タブを選択します。
サービス・レベル・ルールを編集するサービスを選択します。
サービスのホームページで、「関連リンク」セクションの「サービス・レベル・ルールの編集」をクリックします。
「サービス・レベル・ルールの編集」ページが表示されます。一部のルール・パラメータに対してはデフォルト値が使用されます。ただし、サービスごとにサービス・レベル・ルールを編集して、サービスに適した評価条件を正確に定義する必要があります。
営業時間全体に対して、サービスが可用性とパフォーマンスの基準を満たすことを要求する時間の割合を指定します。
デフォルトでは、サービスは、定義されている営業時間のうち、指定されている基準である85%を満たすことが要求されます。
実際のサービス・レベルに対する次のパラメータを指定します。
営業時間: 可用性またはパフォーマンスの問題が発生することなくサービスが機能する必要のある時間帯。
可用性の基準: サービスが稼働しているものとみなされる可用性の状態。サービスの可用性に影響を与えない要素としては、「ブラックアウト中」または「不明」を選択できます。「ブラックアウト中」を選択すると、使用可能なサービス時間としてサービス・ブラックアウト時間（サービスを技術的に使用不可能にする計画的なアクティビティ）を指定できます。「不明」を選択すると、管理エージェントが使用できないためにサービスが監視されない時間を指定できます。
パフォーマンス基準: サービス・レベルに影響を与えるパフォーマンス・メトリック。指定したパフォーマンス・メトリックに対してクリティカル・アラートがトリガーされると、サービス・レベルは影響を受けます。
「OK」をクリックします。
サービスの監視は、運用目標とSLAの実現に役立ちます。ユーザーのWebアプリケーション・サービスへのアクセス時に記録されたレスポンス時間に関するデータを分析して、Webアプリケーション内のすべてのURLに対するエンド・ユーザーの操作を追跡し、エンド・ユーザーに直接影響を与えるパフォーマンスのボトルネックを検出できます。サービスを監視するには、サービスのエンド・ユーザーがよくアクセスするアクティビティまたは機能をシミュレートするサービス・テストを定義し、サービス・テストを実行する地理的な場所を指定して、Enterprise Managerビーコンでサービス・テストを実行した後、様々な監視メカニズムを使用して結果を分析する必要があります。次に、これらの手順を簡単に説明します。
サービス・ダッシュボードを使用すると、サービス・レベルがビジネスの期待値と目標に達しているかどうかを判定できます。サービス・ダッシュボードにより、管理者は中心となる場所からすべてのサービス・レベル情報を参照できます。ステータスを簡単に把握できるよう、すべてのサービスを単一のダッシュボードにまとめることができます。ダッシュボードには、各サービスの可用性ステータス、パフォーマンスと使用状況のデータ、さらにはサービス・レベルの統計情報まで表示されます。問題の根本原因まで簡単にドリルダウンしたり、故障したコンポーネントがサービス自体に与える影響を判定したりできます。
サービスは、非常に複雑な場合があります。サービス・トポロジ・ビューを使用すると、サービスとそのコンポーネントの間の依存状態が簡単にわかるようになります。サービスで障害が発生すると、根本原因分析によって示される障害の原因の可能性がある部分が、トポロジ・ビューでハイライトされます。トポロジ・ビューアでは、サービスとシステムの間の依存関係を確認できます。サービス・トポロジは集約サービスに対して最も役立ちます。
Grid Controlでは、サービスの問題を診断して可能性がある原因を特定するのに役立つ複数のツールが提供されています。Grid Controlの根本原因分析（RCA）機能を使用すると、影響を受けたサービスが使用していたシステム・コンポーネントの可用性、パフォーマンスおよび構成のデータをフィルタ処理することで、サービスの障害を分析できます。この機能は、サービス障害の原因のように見えますが、問題の実際の根本原因の副次的な影響または兆候でしかない問題を除去するのに役立ちます。
RCA情報には、トポロジ・ビューアからもアクセスできます。トポロジ・ビューアは、階層的なレベルをグラフィカルに表してコンポーネント間のリレーションシップを表示するツールです。サービスとシステム・コンポーネントの間の線は、関連のある障害を示しています。総合的な診断ツールを使用すると、Oracle Application Serverスタックに素早くドリルダウンしたり、様々なアプリケーション・サーバーやデータベース・コンポーネントのレスポンス時間を監視したりすることができます。RCAを使用すると、大きな依存トポロジを横断して問題領域を素早く識別し、サービス障害の特定の可能性のある原因の通知を受け取ることにより、RCAを使用しないと手作業で行わなければならない困難な作業が自動化されます。
Webアプリケーション・サービスの場合は、パフォーマンスが低下したら、相互トランザクションのトレースを使用することで、必要に応じて問題のあるトランザクションをトレースできます。一連のユーザー・アクションとナビゲーション・パスを自動的に記録する直観的な再生レコーダを使用して、トランザクションを記録できます。対話形式でトランザクションを再生し、Webアプリケーションのすべての層についてレスポンス時間を詳しく分析して、素早く診断を下すことができます。
相互トランザクションのトレース機能は、トランザクション・パフォーマンス監視機能やエンド・ユーザー・パフォーマンス監視機能を補完して、パフォーマンスの問題の原因の診断を支援します。問題を解決したら、相互トランザクションのトレースを使用して、問題が適切に修復されたことも検証できます。
Grid Controlのリクエスト・パフォーマンス診断機能は、アプリケーション・サーバーおよびバックエンド問題の診断プロセスに対して有益な機能です。すべてのURLリクエストのJ2EEおよびデータベース・パフォーマンスに関する履歴の詳細を提供します。詳細なJ2EEおよびデータベースのブレークダウンを調査し、リクエストの処理時間を分析するこことで、問題がサーブレット、JSP、EJBメソッドまたはSQL文内にあるかどうかを判別できます。この情報を使用すれば、簡単に問題の原因を特定し、Webアプリケーションの適切なコンポーネントを素早く修復するために必要な処理を行うことができます。
Lindaは、サービスの問題を、技術スタックの特定のコンポーネントまで掘り下げてトレースできる必要があります。RCAを使用することで、問題のコンポーネントに焦点を当てることができます。
RCAは、キー・コンポーネントの可用性ステータスを評価して、そのコンポーネントがサービス障害の原因かどうかを判定します。RCAが考慮する追加条件やコンポーネント・テストを指定できます。サービスで障害が発生すると、RCAは、可能性のある原因の一覧をサービスのホームページに返します。可能性のある根本原因としては、障害のあるサブサービスやキー・システム・コンポーネントなどがあります。このトピックでは、障害のあるサービスに対してRCAを実行する方法について説明します。
RCAを実行するには、次のようにします。
「ターゲット」ページで、「サービス」セカンダリ・タブを選択します。
RCAを実行するサービスを選択します。
サービスのホームページが開きます。
「監視構成」をクリックし、「根本原因分析の構成」をクリックします。
現在のモードが「手動」に設定されている場合は、「モードを自動に設定」をクリックして、サービスやそのコンポーネントの状態が変化したときのRCAを有効にします。
RCAを手動で実行すると、RCAは結果を保存しないので、後で履歴を参照できません。
表で、テストするキー・コンポーネントに対する「コンポーネント・テスト」列のリンクをクリックし、コンポーネントの適切なテストを追加します。
しばらくしてから、サービスのホームページに戻り、「可能性のあるサービス失敗の原因」の見出しの下を参照します。RCA詳細リンクを参照する場合は、このリンクをクリックして「根本原因分析の詳細」ページを表示します。
「失敗の原因」表でメッセージをクリックして、特定の原因に関するアラートの詳細を表示します。
RCA機能は、サービス・トポロジ・ビューアを使用して表示することもできます。このビューアでは、サービスと他のサービスに対するそのリレーションシップ、システムおよびインフラストラクチャ・コンポーネントがグラフィカルに表示され、RCAによって識別された原因がハイライトで示されます。
|
注意: トポロジ・ビューアは、Microsoft Windows上でInternet Explorer 5.5以上、Adobe SVG Viewer 3.0を使用している場合のみサポートされます。他のブラウザおよびAdobe SVG Viewer 6.0はサポートされていません。 |
トポロジ・ビューアとRCAを使用すると、サービスの障害の原因になっているコンポーネントを分離できます。
Oracle by Example（OBE）には、このマニュアルに関するシリーズがあります。
サービス・レベル管理のOBEでは、注釈付きのスクリーン・ショットを使用してこの章のタスクを説明します。
http://www.oracle.com/technology/obe/obe10gEMR2/Quick_Start/system_services/system_services.htm
