| Oracle Enterprise Manager概要 10gリリース5（10.2.0.5） B53905-01 |
|
 戻る |
 次へ |
この章では、Enterprise Managerを使用して、Oracle WebLogic Server、Oracle Application Server、Oracle BPEL Process Managerなどのミドルウェア・ターゲットを管理する方法について説明します。
この章の内容は次のとおりです。
ミドルウェアとは、基本的に、Webアプリケーション用の実行時インフラストラクチャを提供するアーキテクチャの中間層を示します。ミドルウェアは、Oracle WebLogic Server、Oracle Application Server、Oracle BPEL Process Manager、Oracle BI Suite Enterprise Editionなどのターゲットで構成されます。各ミドルウェア・ターゲットには、特定のターゲットの監視に役立つ独自のコンソールが用意されていますが、Grid Controlの提供する単一ウィンドウ・ソリューションでは、ミドルウェア・ターゲットの複数のインスタンスと多くのミドルウェア・ターゲットを単一のコンソールで検出および集中監視できます。
たとえば、Oracle Application Serverは、すべてのOracle Application Serverに付属するスタンドアロンのApplication Server Controlを使用して管理できます。または、他の複数のOracle Application Serverおよび他のミドルウェア・ターゲットのホストとともに、Grid Controlを使用して管理することもできます。
この項では、Application Server ControlおよびGrid Controlについて説明します。また、これらを使用する状況についても説明します。
各Oracle Application Serverインスタンスは、この特定のアプリケーション・サーバー・インスタンスを管理するためのApplication Server Controlとともにインストールされます。Application Server Controlは、アプリケーション・サーバーのインスタンス、ファームおよびクラスタを監視および管理するために設計されたWebベースの管理機能を提供します。また、アプリケーションのデプロイ、パフォーマンスのリアルタイムの監視、セキュリティの管理およびアプリケーション・サーバーのコンポーネントの構成も可能です。
Application Server Controlは、環境でアプリケーション・サーバーを検出、監視および管理するために、様々な基礎となるテクノロジに大きく依存しています。これは、Application Server Controlコンソールおよび次の基礎となるテクノロジで構成されます。
監視データを収集するように設計されたローカル・バージョンのOracle管理エージェント
ただし、1つのApplication Server Controlのみを使用して、複数のアプリケーション・サーバーを管理できます。通常、エンタープライズ構成には複数のアプリケーション・サーバーがあり、個別のApplication Server Controlを使用してこれらのすべてのインスタンスを管理することは、非常に困難です。
集中管理およびその他の管理機能（アプリケーション・サービス・レベルの管理、デプロイメント、パフォーマンスの傾向アラートの履歴データの収集など）については、Grid Controlを使用できます。
Application Server Controlでは、単一のアプリケーション・サーバー・インスタンスおよびそのコンポーネントをスタンドアロンで管理しますが、Grid Controlでは、環境内の複数のアプリケーション・サーバーの集中管理が可能です。
たとえば、10の異なるホストに10のアプリケーション・サーバーがインストールされている場合、Grid Controlを使用して、これらの10のアプリケーション・サーバーおよびホストをすべて単一のウィンドウで管理できます。各ホストに管理エージェントをデプロイすると、Grid Controlによって自動的にこれらのホストのアプリケーション・サーバーが検出され、デフォルトの監視レベル、通知ルールおよびその他のデフォルト設定を使用したアプリケーション・サーバーの監視が自動的に開始されます。同様に、ネットワーク全体にOracle WebLogic Serverドメインなどの複数の論理エンティティが存在する場合、それらすべてをGrid Controlで検出し、単一のコンソールを使用して監視できます。
Grid Controlには、専用のアプリケーション・サーバーのホームページがあります。このページから、管理者に必要な主要情報に簡単にアクセスできます。また、Grid Controlには、Oracle WebLogic ServerドメインやOracle WebLogic Serverクラスタなどの論理エンティティ用の個別のホームページもあります。
概要レベルでは、Grid Controlのホームページ（図8-1）には次のものがあります。
アプリケーション・サーバーの状態、応答性およびパフォーマンス・データ
アプリケーション・サーバーおよびそのコンポーネントのリソース使用率
これらのコア・コンポーネントを起動、停止および再起動するための機能
問題を迅速に識別および解決するためのアラートおよび診断ドリルダウン
アプリケーション・サーバーの状態に関する詳細情報のメトリック
特定のタスクを実行するときに役立つGrid Controlのその他のページへのリンク
次に、Oracle WebLogic管理対象サーバーのホームページを示します。
Grid Controlには、環境内のミドルウェア・ターゲットを監視する包括的な機能のセットが用意されています。ミドルウェア・ターゲットに関する最も重要な情報のサマリーを表示できます。それらのパフォーマンスの監視、生成されるアラートおよびポリシー違反の表示、一定期間に加えられた構成の変更の追跡およびそれらに対するその他の管理タスクの実行が可能です。
Grid Controlを使用して、次のミドルウェア・ターゲットを監視できます。
表8-1 監視されるミドルウェア・ターゲット
| 監視のターゲット | Grid Controlが提供するサービス | 関連リンク |
|---|---|---|
|
Oracle WebLogic Serverドメイン、Oracle WebLogic ServerクラスタおよびOracle WebLogic管理対象サーバー |
|
|
|
Oracle Application Server |
|
アプリケーション・サーバー環境のバックアップおよびリカバリの管理 |
|
Oracle HTTP Server |
|
|
|
OC4J |
|
|
|
OracleAS Web Cache |
|
|
|
Oracle BPEL Process Manager |
Business Process Execution Language（BPEL）はXMLベースの言語で、Webサービスの組合せにより複数のエンタープライズ間でタスクを共有します。Oracle BPEL Process Managerでは、プロセスを簡単に設計、デプロイ、監視および管理するBPEL標準に基づいたフレームワークが使用できます。 |
|
|
Oracle Application Serverファーム |
OracleASファームは、同じファーム・リポジトリを共有するOracleAS DCMの管理対象クラスタとOracle Application Serverインスタンスの集合です。 |
|
|
Oracle Application Server DCMの管理対象クラスタおよびOracle Application Serverクラスタ |
OracleAS DCM管理対象クラスタは、同じ構成およびアプリケーション・デプロイメントを持つリリース9.0.4からリリース10.1.2のOracle Application Serverインスタンスの集合です。OracleASクラスタは、リリース10.1.3以降のバージョンのOracle Application Serverインスタンスの集合です。 |
|
|
Oracle BI Suite Enterprise Edition（Oracle BI Suite EE） |
Oracle BI Suite EEは一連のビジネス・インテリジェンス・ツールが統合された包括的なセットを提供する統合製品であり、それらのツールを使用すると様々なソースから情報を収集して分析し、非常に広範な対象ユーザーと共有することができます。それは1つの論理コンポジット・ターゲットであり、そのコンポーネントはOracle BI Presentation Server、Oracle BI Cluster Controller、Oracle BI Analytics ServerおよびOracle BI Schedulerです。また、DAC Serverを監視することもできます。 |
|
|
Oracle Service Bus |
|
Oracle Service Busプロキシ・サービスへのSOAPテストの追加 |
|
サード・パーティ・アプリケーション・サーバー |
手動で次のサード・パーティ・アプリケーション・サーバーを検出し、その状態を監視します。
また、これらのサード・パーティ・アプリケーション・サーバーにデプロイされたアプリケーションを表示し、構成情報の表示、比較および検索などのエンタープライズ構成管理タスクを実行できます。ドメイン、クラスタまたはセル内のメンバーを表示できます。 |
第9章「ホストおよびサード・パーティ・ターゲットの管理」 |
|
サード・パーティ・プラグイン |
手動で次のサード・パーティ・プラグインを検出し、その状態を監視します。
|
第9章「ホストおよびサード・パーティ・ターゲットの管理」 |
|
注意: サード・パーティ・ターゲットの監視の詳細は、第9章「ホストおよびサード・パーティ・ターゲットの管理」を参照してください。 |
|
重要: Enterprise Managerリリース10.2は、アプリケーション・サーバー・ターゲットのリリース9.0.4からリリース10.1.2のみをサポートします。このリリースでは、OracleAS管理対象クラスタはOracleASクラスタと呼ばれます。ただし、Enterprise Managerリリース10.2.0.2には、アプリケーション・サーバー・ターゲットの10.1.3のサポートが追加されているため、わかりやすくする目的で用語を修正し、DCMが管理するものとアプリケーション・サーバー・ターゲットのリリース10.1.3に関連するものを区別しています。 |
この項では、Grid Controlを使用してミドルウェア・ターゲットに関する重要な情報を表示する方法について説明します。
Grid Controlには、ステータスや可用性を含むターゲットに関する一般情報が用意されています。これにより、ターゲットの実行方法、デプロイされた場所、バージョン、ホーム・ディレクトリの場所などを知ることができます。ターゲットが論理ターゲットで、その固有のメンバーをグループ化する場合、メンバーシップの詳細も提示されます。
Grid Controlでは、過去24時間に発生した様々なクリティカル、警告およびエラー・アラートが表示されます。これらのアラートは、特定のメトリック条件が発生したことを示します。たとえば、メトリックしきい値に達すると、アラートがトリガーされます。この詳細を使用し、ターゲットおよびアラートをトリガーした問題をドリルダウンして調べることができます。詳細は、この章の「自動監視およびアラート」を参照してください。
Grid Controlでは、アプリケーション・サーバー・ターゲットに違反する様々な情報、警告およびクリティカルなポリシー・ルールも表示されます。ターゲットに対する個別のポリシー・コンプライアンス・スコアをまとめて表示できます。コンプライアンス・スコアにより、ミドルウェア・ターゲットの状態を迅速に判断できます。また、過去24時間、過去1週間、過去1か月またはユーザー定義の期間でのポリシーの傾向の概要を表示し、ポリシー違反を解決する手段を決定できます。
また、Grid Controlでは、セキュリティ・ポリシー・ルールを最後に評価した時間を表示し、ターゲットの個別のポリシー・コンプライアンス・ソースをまとめて表示できます。
Grid Controlでは、アプリケーション・サーバー・インスタンスでのJ2EEアプリケーション・デプロイの詳細が表示できます。最もアクティブなアプリケーションおよびシステム・リソースを最も使用しているアプリケーションを、迅速に評価できます。
Grid Controlを使用すると、現在のリアルタイムのアプリケーション・パフォーマンスに基づいた情報、または管理リポジトリからの履歴データに基づいた情報を更新する場合、柔軟性が向上します。たとえば、過去24時間、過去1週間または過去1か月の間で、最もアクティブなアプリケーションを確認できます。
Oracle WebLogic Serverドメイン、OracleASファーム、OracleASクラスタなどの論理コンポジット・ターゲットに対して、Grid Controlは、グループを構成しているメンバー・ターゲットに関するロールアップ情報を提供します。「メンバー」タブで、特定のコンポジット・ターゲットに関連付けられたメンバーを表示し、そのステータスを確認し、それぞれを起動、停止および再起動できます。
また、Grid Controlでは、OracleAS DCMの管理対象クラスタのメンバーの高可用性（HA）グループを調査できます。高可用性グループは、DCM管理のクラスタにクラスタ化されたアプリケーション・サーバー・インスタンスのコンポーネントのうち類似したものをまとめて構成したグループです。たとえば、OC4J高可用性グループには、OracleASクラスタのOC4Jインスタンスのグループがあります。
この項では、ミドルウェア・ターゲットのパフォーマンスを監視するGrid Controlの機能について説明します。
Grid Controlには、各ミドルウェア・ターゲットに対して事前定義されたパフォーマンス・メトリックのセットが用意されています。メトリックを選択すると、しきい値が特定のメトリックに対して定義されているかどうか確認できます。Grid Controlでは、アラートを生成するメカニズムとしてメトリック内で定義されたしきい値が使用されます。一方、このアラートを使用して、ターゲットが稼働中か停止中か、ターゲットのディスクが一杯になりそうであることなどが、通知されます。つまり、全体的なパフォーマンスを監視できます。
パフォーマンス・メトリックでは、メトリックの詳細は、現在のリアルタイムの値（30秒、1分または5分）または過去の値（過去24時間、7日または31日）で表されます。履歴情報は、グラフおよび表で表示されます。傾向を確認する場合はグラフを使用し、過去のメトリック重大度履歴の詳細を調査する場合は、表を使用します。
Grid Controlには、アラートの自動監視および生成を簡単に行うための包括的な機能セットが用意されています。ホスト上のOracle管理エージェントは、このホスト上のミドルウェア・ターゲットを自動的に検出し、Grid Controlによるステータス、状態およびパフォーマンスの無人監視をサポートします。
Grid Controlは、エンタープライズ全体に分散しているこれらのターゲットから診断情報を収集して評価します。ミドルウェアの広範囲にわたるパフォーマンス・メトリックが、事前定義済しきい値に到達していないか自動的に監視されます。
たとえば、Grid Controlを使用すると、次のことを自動的に監視できます。
アプリケーション・サーバーのCPUまたはメモリー使用（サーバーのOracle Application Server Containers for J2EE（OC4J）インスタンスによって実行されている個々のJava Virtual Machine（JVM）の詳細な監視などを含む）
アプリケーションから個々のサーブレットおよびEnterprise JavaBeans（EJB）までを含む、J2EEアプリケーションの応答性
リクエスト数、最大処理時間および最大平均処理時間に基づく上位サーブレット
Oracle Application Serverまたはそのコア・コンポーネントが停止した場合、またはパフォーマンス・メトリックが警告しきい値またはクリティカルしきい値に達した場合、Grid Controlによってアラートが生成され、通知が送信されます。Grid Controlは、電子メール（ポケットベル通知システムを含む）、SNMPトラップを介した通知、カスタム・スクリプトの実行による通知、またはそのいずれかをサポートします。
アラート通知を受信した場合、Grid Controlを使用して簡単にその問題を調べ、必要に応じて修正処理を実行できます。たとえば、CPUがOC4Jによって過剰に使用された場合は、そのコンテナで実行されているアプリケーションが調べられることになります。Grid Controlのアプリケーション・サーバーのホームページの「上位J2EEアプリケーション」タブ（図8-7）を使用すると、ボリュームが最大または応答性が最小のアプリケーションを迅速に識別できます。その後、ボトルネックを特定するために、アプリケーションのサーブレット、Java Server Pages（JSP）またはEJBをドリルダウンして診断できます。
アラート条件を自動的に解決するための修正処理を設定できます。これらの修正処理により、アラートに対する日々の対応が自動的に実行されるため、処理時間を短縮し、ユーザーに問題が著しく影響する前に問題に対処できるようになります。
また、監視テンプレートを使用して、エンタープライズ全体の監視設定を簡単に標準化することもできます。監視設定を1回指定するだけで、すべてのOracle Application Serverターゲットに適用できます。監視テンプレートには、次のような、通常Oracle Application Serverターゲットの監視に設定するすべてのGrid Controlのパラメータが定義されています。
テンプレートを適用するターゲット・タイプ
メトリック（ユーザー定義のメトリックなど）、しきい値、メトリック収集スケジュールおよび修正処理
テンプレートを変更する場合、新しい変更内容を伝播するために、このテンプレートを関連するOracle Application Serverターゲットに再適用できます。監視テンプレートは必要に応じて何度でも再適用できます。
Oracle Application Server、OracleASファームおよびOracleAS DCMの管理対象クラスタの監視機能以外に、Grid Controlにはこれらのターゲットのトポロジ表示機能が用意されています。これらのトポロジを表示することにより、ホスト上で動作しているアプリケーション・サーバーおよびコンポーネント、これらのコンポーネントの相関関係、およびデプロイメントの様々な層を介してリクエストがルーティングされる方法を理解できます。このようにデータ・センター・エンタープライズのトポロジを視覚化することにより、管理者は、エンタープライズのアーキテクチャを効率的に監視、管理および確認できます。
Grid Controlには、次の3つの異なるトポロジのビューがあります。各ビューには、現在のステータス、アラートとポリシー違反の数、およびCPU/メモリー使用状況パフォーマンスのメトリックを含むコンポーネントのキー・メトリックが重なって表示されます。
ホスト・ビュー: デプロイメントの物理的なビューが表示され、ホストと、ホストによって管理されるコンポーネントおよびインスタンスの関係が示されます。
ルーティングの概要: トポロジのルーティング・ビューが表示され、線で接続されたコンポーネントとアプリケーション・フローの全体像が示されます。このルーティングには、OracleAS Web CacheからOracle HTTP Server、OC4JからDBインスタンスまでのルーティングが含まれます。
ルーティングの詳細: リクエストをトポロジ内のその他のコンポーネントにルーティングするために様々なコンポーネントによって使用されるプロトコルとポートが示されます。
これらのルーティング・ビューを使用すると、トポロジ構成に関する様々な問題を即時に修復できます。たとえば、OC4Jインスタンスがユーザー・リクエストを受信しない場合、ルーティング詳細ビューにより、ユーザー・リクエストをこのOC4JインスタンスにルーティングするためにフロントエンドOracle HTTP Serverインスタンスが正しく構成されているかどうかを確認します。OracleAS Web Cache、Oracle HTTP ServerまたはOC4Jコンポーネントが互いに重複している場合、これらは同じボックスに表示されます。
たとえば、一連のOracleAS Web Cacheがすべて同じOracle HTTP Serverインスタンス・セットに対してルーティングされている場合、これらは同じボックスにまとめられます。同様に、一連のOC4Jインスタンスが同じOracle HTTP Serverインスタンス・セットによってルーティングされており、同じJ2EEアプリケーション・セットによってもホストされている場合、これらは同じボックスにまとめられます。類似コンポーネントは1つにまとめられるため、ルーティングの概要またはルーティングの詳細ビューに視覚的に表示されたトポロジにより、サービスの可用性の問題の発生時に根本原因分析を即時に実行できます。
Grid Controlでは、Oracleシステム監視ダッシュボードにアクセスし、ターゲットの状態も監視できます。ただし、この機能はOracleASファーム、OracleAS DCM管理対象のクラスタ、Oracle Application Server、OC4J高可用性グループおよびHTTP Server高可用性グループにのみ提供されます。
Oracleシステム監視ダッシュボードでは、わかりやすいアイコンとグラフィックを使用して情報が示されるため、最近の変更内容を特定し、問題の識別と対処がすぐにできます。管理対象のターゲットの情報要件に合せて表示属性をカスタマイズし、最近の問題のステータス・インジケータを監視し、ダッシュボードを最後に表示してからトリガーされた新しいアラートを表示できます。
Grid Controlには、ミドルウェア・ターゲットで管理タスクを実行する機能が用意されています。次の操作を実行するWebベースのインタフェースがあります。
ミドルウェア・ターゲットを起動、停止または再起動します。
構成情報の表示や比較などの構成管理タスクを実行します。詳細は、この章の「構成の管理」を参照してください。
事前に定義されている検索問合せのリストにアクセスし、構成情報を検索および取得します。詳細は、この章の「構成の管理」を参照してください。
Enterprise Managerのイベント監視インフラストラクチャにアプリケーション・インスツルメンテーションを統合します。詳細は、この章の「拡張可能監視」を参照してください。
個別パッチまたはパッチ・セットをステージングまたは適用し、アプリケーション・サーバーのOracleホームを1つ以上のホストにクローニングします。詳細は、この章の「ミドルウェア環境のクローニングおよびパッチ適用」を参照してください。
スケジュールしたバックアップおよびリカバリを実行します。詳細は、この章の「アプリケーション・サーバー環境のバックアップおよびリカバリの管理」を参照してください。
ブラックアウトを作成し、定期的にメンテナンスを実行します。
アプリケーション・サーバーで発行されたすべてのGrid Controlについてスケジュール済、稼働、一時停止中、および問題（停止/失敗）ありの実行数を表示します。
Application Serverのファームを作成し、そのコンポーネントを管理します。
Grid Controlに同梱されるパフォーマンスおよび状態メトリックにより、使用する環境のアプリケーション・ターゲットを自動的に監視できます。メトリックが事前定義済の警告またはクリティカルしきい値に達すると、Grid Controlでアラートが生成され、管理者に通知されます。
ただし、ミドルウェア・ターゲットでメンテナンス作業を実行する際に、ターゲットを停止している間、アラートを発生させたくない場合があります。その場合、ブラックアウトをスケジュールし、ミドルウェア・ターゲットの監視を一時停止できます。
ブラックアウトによって、1つ以上の監視対象ターゲットに対するデータ収集アクティビティを一時停止できるため、ターゲットに対して計画されたメンテナンスを実行できます。この間に監視を続行すると、収集されたデータには、通常の日常操作の結果にはみられない傾向とその他の監視情報が表示されます。ターゲットのパフォーマンスについて、より正確で長期にわたる実態を把握するには、ブラックアウトを使用してデータ分析から特殊な状況を排除する必要があります。
Grid Controlでは、新しいブラックアウトの定義、既存のブラックアウトの表示、および不要なブラックアウトの編集、停止、削除ができます。「ブラックアウト」オプションは、アプリケーション・サーバー・ターゲットのホームページの「一般」セクションにあります。OracleASファームのようなコンポジット・ターゲットでは、このオプションは「管理」タブにあります。
Grid Controlには、OracleASファーム、OracleAS DCM管理対象クラスタ、OracleASクラスタ、Oracle WebLogic ServerドメインおよびOracle WebLogic Serverクラスタにジョブを作成するジョブ・システムが用意されています。たとえば、Oracle WebLogic Serverドメインの場合、ジョブを作成してサーバーを自動的に起動、停止または再起動できます。また、スケジュール済、稼働中、一時停止中のジョブ、または問題があるジョブの詳細を表示できます。コンポジット・ターゲットから直接ジョブをスケジュールして、OSコマンドをメンバーで実行、またはいずれかのOPMNコンポーネントを起動、停止または再起動できます。
Grid Controlを使用すると、J2EEまたはWebアプリケーションから直接サービスを作成し、サービスの可用性およびパフォーマンスを追跡できます。アプリケーション・サーバーで稼働中のビジネス・アプリケーションは、組織から提供されるサービスの質をそのまま反映しています。その重大性および複雑性を考慮すると、すべての組織にとり、容認できる応答時間内にリクエストに対するサービスを提供し対応できることが必要になっています。
J2EEまたはWebアプリケーションからサービスを作成すると、ユーザーにとり有用な機能を提供するエンティティとしてアプリケーションをグループ化できます。これにより、ユーザーに与えられる機能を表すサービスの全体的なパフォーマンスを監視し、サービスが依存するインフラストラクチャ・コンポーネントを監視できます。また、問題がある場合はアラートを受信し、システム内の共通の問題を識別し、障害の原因を診断して、それらを解決できます。
J2EEまたはWebアプリケーションのサービスの作成の際に、Grid Controlはサービス依存性を作成し、選択されたアプリケーションが依存するコンポーネントを識別します。コンポーネントとは、ホスト、データベース、アプリケーション・サーバーなどの、連携してJ2EEまたはWebアプリケーションをホストするインフラストラクチャ・コンポーネントを指します。アプリケーションに必要なコンポーネントを識別すると、Grid Controlはそのコンポーネントにシステムを作成し、サービスを作成して、アプリケーションと関連付けます。
つまり、サービス作成の際に、Grid Controlは、選択したアプリケーションにすでに使用可能な依存性マッピングがあるかどうか確認します。使用可能な場合、まったく同じメンバーで別のシステムを作成せずに、既存のシステムを使用してサービスが作成されます。
アプリケーションの依存性マッピングに応じて、新しいシステムで新しいサービス、既存のシステムで新しいサービスを作成する、またはサービスをリフレッシュできます。
Grid Controlを使用すると、Oracle BPEL Process ManagerターゲットやOracle Service Busターゲットなどのミドルウェア・ターゲットに対してインフラストラクチャ・サービスを作成できます。
|
注意: この項でのミドルウェア・ターゲットは、Oracle BPEL Process ManagerターゲットとOracle Service Busターゲットのみを示しています。 |
インフラストラクチャ・サービスは依存性サービスで、ミドルウェア・ターゲットが依存するインフラストラクチャ・コンポーネントを識別します。インフラストラクチャ・コンポーネントとは、ホスト、データベース、アプリケーション・サーバーなどの、連携してミドルウェア・ターゲットをホストするインフラストラクチャ・コンポーネントを指します。
インフラストラクチャ・サービスは新しいシステムまたは既存のシステムのいずれかに作成でき、すでにインフラストラクチャ・サービスがある場合は、それをリフレッシュしても構いません。インフラストラクチャ・サービスおよびシステムを作成すると、ミドルウェア・ターゲットおよびミドルウェア・ターゲットが依存するコンポーネントの管理が向上します。
たとえば、Oracle BPEL Process Managerターゲットにインフラストラクチャ・サービスの作成が終了すると、Grid Controlを使用して該当するOracle BPELターゲット内のすべてのプロセスの集合サービスを作成できます。集合サービスは、サービスの論理グループ化で、ここでは、インフラストラクチャ・サービスおよび可用性サービスを指します。可用性サービスとは、選択したOracle BPELプロセスに関連付けられるパートナ・リンクにSOAP（Simple Object Access Protocol）テストを初めて追加する時に作成されるサービスです。集合サービスにより、Oracle BPEL Process Managerに作成されたサービスの全体がわかり、それらの可用性、パフォーマンスおよび使用状況の監視に役立ちます。
Grid Controlを使用すると、選択したOracle BPEL Process Managerに関連付けられるパートナ・リンクにSOAPテストを追加して、可用性をテストできます。
SOAPは、パートナ・リンクのWebサービスで使用されるXMLベースのメッセージ・プロトコルです。各SOAPメッセージは、単一のSOAPエンベロープで構成されます。エンベロープは、メッセージの処理方法、メッセージを処理する人物および処理がオプションか必須かを定義します。
Grid Controlを使用すると、Webサービスで公開されるポート・タイプに固有の特定のメソッドが選択でき、入力パラメータの適切な値を指定できます。SOAPテストは、選択したメソッドを起動し、Webサービスが稼働中かどうか確認します。これにより、パートナ・リンクのパフォーマンスを追跡し、その停止を知ることができます。
Grid Controlを使用すると、Oracle Service Busのビジネス・サービスに関連付けられるプロキシ・サービスまたはエンド・ポイントにSOAPテストを作成できます。追加されたSOAPテストは、これらのパートナ・ビジネス・サービスにより使用されるWebサービスの可用性とレスポンス時間の監視に役立ちます。
SOAPテストを最初に追加したときに、その可用性サービスが自動的に作成されます。可用性サービスは、集合サービスの子サービスとして追加されます。追加される他のすべてのSOAPテストは、同じ可用性サービスに組み込まれます。
Grid Controlを使用すると、Oracle WebLogic管理対象サーバーにデプロイされたアプリケーションのWebサービスにSOAPテストを作成できます。SOAPテストを最初に追加したときに、その汎用サービスが自動的に作成されます。汎用サービスは、アプリケーションのWebサービスの可用性を監視するために作成されます。汎用サービスは、デフォルトで<appname>_webservices_availabilityという形式で作成されます。次回SOAPテストを作成したときに、Grid Controlによって新規SOAPテストと既存のサービスが関連付けられます。
Grid Controlでは、選択されたBPEL Process ManagerにBPELプロセスをプロビジョニングするデプロイメント・プロシージャを提供しています。BPELプロセスをプロビジョニングするデプロイメント・プロシージャは、次の事前定義済フェーズから構成されています。
ステージの設定: このフェーズでは、BPELのプロセスおよびその他の依存関係を設定します。基本的に、BPELスーツケース・ファイルの設定を実行した後、それらのファイルをデプロイ用に一時的な場所にステージングし、deploy.jarをターゲット・ホスト上でステージングします。
デプロイ: このフェーズでは、選択したターゲットのBPEL Process Manager上でBPELプロセスをデプロイします。
設定のクリーンアップ: このフェーズでは、個々のホスト上でステージングされた一連のファイルおよびフォルダをクリーンアップします。
BPELプロセス・スーツケース・ファイルは、汎用コンポーネントとして、Oracleソフトウェア・ライブラリに配置する必要があります。そして、デプロイに利用できるようになると、デプロイメント・プロシージャを実行して、BPEL Process Manager上でプロセスをデプロイできます。
Grid Controlでは、エクスポートしたOracle Service BusリソースをターゲットのOracle Service Busドメインにデプロイし、現在の構成をある環境から別の環境に移動するデプロイメント・プロシージャを提供しています。
Oracle Service Busリソースは、個別のプロジェクトに編成できます。プロジェクトは、非階層型で結合されていないトップレベルのグループ化構成メンバーです。すべてのリソース（ビジネス・サービス、プロキシ・サービス、WSポリシー、WSDL、スキーマ、XQuery変換、JARなど）は、厳密にただ1つの重複しないプロジェクト内に存在します。各リソースは、プロジェクトの直下に作成するか、別のフォルダに編成できます。フォルダは、プロジェクト内に作成することも、別のフォルダ内に作成することもできます。これらのフォルダは、プロジェクト・レベルがルート・ディレクトリに相当するファイル・システム内のディレクトリと同様です。
「Oracle Service Busリソース・プロビジョニング」デプロイメント・プロシージャを使用すると、エクスポートするOracle Service Busドメインのプロジェクトを選択し、そのプロジェクトのリソースを別のOracle Service Busドメインにデプロイできます。リソースは、プロジェクト・レベルまたはリソース・レベルでエクスポートできます。どちらの方法でも、技術的には、リソースはJARファイルとしてエクスポートされます。JARファイルは、ターゲットのOracle Service Busドメインにデプロイされます。すでにJARファイルとしてOracle Service Busドメインからエクスポートされたリソースがある場合、そのファイルをOracleソフトウェア・ライブラリ（ソフトウェア・ライブラリ）にアップロードし、デプロイメント・プロシージャを使用してソフトウェア・ライブラリからデプロイできます。
「Oracle Service Busリソース・プロビジョニング」デプロイメント・プロシージャは、次の事前定義済フェーズから構成されています。
リソースのエクスポート: ソースのOracle Service Busドメインからすべてのリソースをエクスポートします。
エクスポート済JARファイルの保存: エクスポートしたJARファイルを汎用コンポーネントとしてOracleソフトウェア・ライブラリ（ソフトウェア・ライブラリ）に保存します。
デプロイメントのためのエクスポート済JARファイルの転送: JARファイルをソース・ホストからデプロイメントの宛先に転送します。
選択したソフトウェア・ライブラリ・コンポーネントのデプロイメント用のステージング: 選択したソフトウェア・ライブラリ・コンポーネントをデプロイ先のOracle Service Busドメインのホストにコピーします。
リソースのデプロイおよびカスタマイズ: 選択したターゲット上にリソースをデプロイしてカスタマイズします。
カスタマイズ・ファイルを使用して、変更された環境に合うようにリソース内の環境値および参照を変更することも可能です。カスタマイズ・ファイルには、選択したリソース内のすべての環境値のカスタマイズを含めることができます。また、依存性のあるリソース内の参照を変更するために、参照カスタマイズ・タイプの変更を含めることもできます。Oracle Service Busコンソールを使用して、これらのカスタマイズ・ファイルを作成できます。
|
注意: Oracle Service Busプロビジョニングは、Oracle WebLogic Serverドメインがリモート管理エージェントを使用して検出される場合にはサポートされません。たとえば、host2で稼働する管理エージェントを使用して、host1で稼働するOracle WebLogic ServerドメインとOracle Service Busを検出した場合、Oracle Service Busリソースをプロビジョニングしようとするとエラーが発生します。 |
Oracle Application Serverコンポーネントは、すべてのタイプのイベントを記録するメッセージを含むログ・ファイルを生成します。これには、起動および停止情報、エラー、警告メッセージ、HTTPリクエストのアクセス情報および追加情報が含まれます。
ただし、ログ・ファイルに記録される情報は膨大なため、どの更新がいつ加えられたのかを追跡するのが困難です。また、定期的に大量の情報が更新されるため、ログ・ファイルのサイズが拡大し、一定期間にシステムに占める領域が増加します。このようなログ・ファイルは、別のファイルに内容を手動でアーカイブし、異なる場所に格納して管理します。
この問題を考慮して、Grid Controlはログ・ローテーション機能で拡張されているため、Oracle Application Serverコンポーネントのログをより効率的に管理できます。特に、Grid Controlを使用して、次のことができます。
スケジュールした日時に、自動的にログをローテーションするジョブをスケジュール
ローテーションしたログ・ファイルを異なるディレクトリに格納して、システムの領域を管理
Grid Controlを使用すると、特定のOracle Application Serverコンポーネント・タイプのログを表示し、ローテーションする必要があるログを選択できます。また、ログ・ローテーション・ジョブは、マルチタスク・ジョブの一部にできます。
ログ・ローテーション・ジョブが実行されると、Grid Controlはローテーションする必要があるログのコンポーネントを自動的に停止します。停止後、既存のログ・ファイルの内容は別のファイルに移され、実際のローテーションのタイムスタンプで区別されます。元のログ・ファイルは、新しいログを記録するために空になります。これが完了すると、Grid Controlはコンポーネントを再起動します。
Grid Controlには、ミドルウェア・ターゲットに対して実行可能な一連の構成管理機能が用意されています。
Oracle管理エージェントは、個々の構成ファイルからOracle Application Serverターゲットに関する情報を収集し、HTTP/HTTPSを介してこの情報をOracle管理サービスに伝達します。この情報は管理リポジトリに格納されます。この情報は定期的に収集および更新され、変更内容の監査が実行されます。Enterprise Managerの構成管理機能により、ユーザーは特定のコンポーネントにある目的の構成データに効率的にアクセスできます。
|
関連項目: 第4章「エンタープライズ構成管理」の「ハードウェアとソフトウェアの構成」 |
これらの構成詳細を比較し、ミドルウェア・ターゲットの2つのインスタンス間の相違点と類似点を表示できます。最後に収集された2つの構成を比較したり、保存されている2つの構成ファイルを比較できるという柔軟性があります。また、1つの構成を複数の構成と比較したり、管理リポジトリ内の1つの構成を保存済構成ファイルと比較することもできます。
Grid Controlを使用して、複数のミドルウェア・ターゲットにわたって構成を検索し、構成の異常を検出できます。たとえば、Oracle Application Serverソフトウェアのインストール/パッチ・バージョンの組合せが適切でない、またはOracle Application Serverのコア・コンポーネントのソフトウェア構成データの組合せが適切でないなどの異常があります。より高度な検索を実行すると、特定のアプリケーションまたはその他のリスナーをホストしているすべてのコンポーネントを識別できます。
たとえば、Oracle Application Serverターゲット用として用意されているGrid Controlの「管理」ページを使用すると、次を検索できます。
オリジナル・サーバー
特定のインストール設定を持つアプリケーション・サーバー
エンタープライズ構成全体にわたってデプロイされたアプリケーションによって使用されるデータ・ソース
特定のOC4Jインスタンス、アプリケーション・サーバー・インスタンスまたはホストにデプロイされるJ2EEアプリケーション
エンタープライズ構成全体にわたってデプロイされたJ2EEアプリケーションのモジュール
エンタープライズ・トポロジのアプリケーション・サーバー・ポート
また、BPEL Process Managerのターゲットの場合は、BPELプロセス、その様々なバージョン、および各バージョンに関連付けられているスーツケース・ファイルを表示できます。さらに、様々なバージョンのBPELプロセス・スーツケース・ファイルを比較し、各バージョンで実行された変更を追跡することもできます。図14-13は、バージョンの選択および比較方法を示しています。このように様々なバージョンを比較することにより、BPELプロセス・スーツケース・ファイル内の変更に起因するパフォーマンスの改善または劣化の原因を特定できます。
管理者の多くはしばしば、アプリケーション環境に固有の条件を確認するためのカスタム・ロジックを作成する必要があります。Grid Controlでは、Grid Controlのイベント監視インフラストラクチャにアプリケーション・インスツルメンテーションを統合できます。アプリケーション開発者がJMXまたはWebサービス操作などの規格を使用してアプリケーション・インスツルメンテーションを公開する場合、使いやすいコマンドライン・ツールを使用してインスツルメンテーション用の管理プラグインを作成し、Grid Controlのイベント監視システムを利用してインスツルメンテーションを監視できます。このようなインスツルメンテーションをGrid Controlに統合するためにXMファイルを編集したり、統合コードを作成する必要はありません。次の手順にそのまま従い、アプリケーション定義のインスツルメンテーションをGrid Controlに統合します。
JMXのMBeanインタフェースとWebサービスのWSDLを分析するコマンドライン・インタフェースを使用して、管理プラグインを作成します。
管理プラグイン・アーカイブをGrid Controlにインポートします。
管理プラグインを管理エージェントにデプロイします。
管理プラグイン・アーカイブに定義されているターゲット・タイプのターゲット・タイプ・インスタンスを作成します。
監視テンプレート、修正処理、履歴およびリアルタイム・メトリック・ビュー、アラート、通知ルールのカスタマイズ、アプリケーション・インスツルメンテーション・メトリックから生成されたイベントのメソッドを含むGrid Controlのイベント監視システムを利用します。
パフォーマンスの問題をトラブルシューティングする場合、最もアクティブなサーブレットまたはJSPを認識しておくと役立ちます。Grid Controlのアプリケーション・サーバーの「パフォーマンス」ページの「上位サーブレット」または「上位JSP」リンク（図8-14および図8-15）を使用すると、アプリケーション・サーバー・インスタンスで動作している上位のJavaサーブレットまたはJSPを識別できます。また、サーブレットおよびJSPをリクエスト数、最大処理時間および最大平均処理時間別にソートして表示できます。
Grid Controlのすべての診断の場合と同様に、アプリケーション・サーバーの診断レポートは現行データまたは履歴データに基づいて作成できます。アプリケーション・サーバーのメトリックは、収集され、管理リポジトリに格納されるため、状況が変化した後もデータの分析は可能です。たとえば、履歴データおよび診断レポートを使用すると、数日前または数週間前に発生したアプリケーションのパフォーマンスの問題を調べることができます。
さらに、データを管理リポジトリから取得する期間をカスタマイズすることもできます。カスタマイズできる期間は、次のとおりです。
過去24時間、過去7日間または過去31日間の事前定義済範囲
カスタマイズした任意の日、週、月、年数範囲
任意の開始日および終了日（ただし、この期間は99年以内）
この項では、ミドルウェア・ターゲットをメンテナンスするGrid Controlの機能について説明します。
バックアップおよびリカバリは、ハードウェアの障害やデータの消失からの保護、および消失が発生した場合のデータの再構築に関連する様々な計画および手順を意味します。包括的なバックアップ計画では、中間層およびアプリケーション・サーバー・インフラストラクチャのOracleホームを含むアプリケーション・サーバー環境全体をバックアップできるように調整された手法を採る必要があります。
Grid Controlは、単一のアプリケーション・サーバーまたはアプリケーション・サーバーのグループのバックアップおよびリカバリを管理するために役立ちます。
Grid Controlを使用して、次を実行できます。
バックアップのスケジュール
リカバリを目的としたアプリケーション・サーバーのバックアップのリストア
バックアップ・ジョブのステータスの表示
リカバリ・ジョブのステータスの表示
必要なバックアップ設定の構成
バックアップのタイプ、および推奨されるバックアップ/リカバリ計画の詳細は、『Oracle Application Server管理者ガイド』を参照してください。
Grid Controlの自動プロビジョニング・ツールを使用して、データ・センターを確実に標準化したり、これらのタスクに要する時間を大幅に短縮できます。トポロジの標準化の整合性を維持するには、インストールおよび構成ではなくクローニングによって新しいインスタンスを追加することをお薦めします。
クローニングにより、新しいインスタンスをエンタープライズ・トポロジ内のその他のインスタンスと同じになるように正確にインストールおよび構成できます。クローニングは、構成とデプロイメントは保持しながら既存のインストールを別の場所にコピーするプロセスです。Grid Controlのクローニング・ウィザードを使用すると、アプリケーション・サーバーのアクセス管理およびアイデンティティ管理に関連するインストール、特にOracleホームのあるディレクトリの複製を自動化できます。また、そのマルチキャスト機能により、1回の操作で複数のターゲット・ホスト上に複数のクローンを作成できます。
My Oracle Supportへの直接リンクを使用して、Grid Controlは、Oracle Application Serverインストールに適用する必要がある重要なパッチのリストを事前かつ定期的に取得します。また、Grid Controlは、データ・センター環境を分析し、アプリケーション・サーバー・インスタンスに適用可能なパッチをユーザーに通知します。その他すべてのパッチも、特定のターゲットのコンテキストで手動で検索できます。さらに、強力なジョブ・システム・インフラストラクチャを使用してパッチの適用を自動化することもできます。パッチを即時に適用することや、メンテナンス・ウィンドウでアプリケーションをスケジュールするとともに、メンテナンス・ウィンドウでOracle Application Serverインスタンスをバック・アウトすることも可能です。
|
関連項目: 第13章「ライフサイクル管理」の「クローニング」および「パッチ適用」 |
この項では、Grid Controlを使用してアイデンティティ管理ターゲットを管理する方法について説明します。この項の内容は次のとおりです。
アクセス管理は、エンタープライズ・リソースへのユーザー・アクセス制御の手段です。アクセス管理製品を使用すると、異機種間アプリケーション環境に対する集中ファイングレイン・アクセス管理およびOracle Portal、Oracle Collaboration SuiteおよびOracle E-Business SuiteなどのOracle製品との即時利用可能な統合が可能になります。Oracle Identity Managementは、エンタープライズでユーザーIDを管理するための製品セットで、これを使用すると、企業はユーザーIDをファイアウォール内外のすべてのエンタープライズ・リソースを通じてエンドツーエンド・ライフサイクルで管理できます。自動ユーザーIDプロビジョニングによって、IT管理コストの削減およびセキュリティの向上が実現します。また、プロビジョニングは法規制のコンプライアンスにおいて重要な役割を果します。コンプライアンス・イニシアティブでは、これらの規格へのコンプライアンスの実証のみではなく、企業ポリシーの施行にも焦点が置かれています。エンタープライズ・アイデンティティ管理ソリューションは、ユーザーおよびそのアクセス権限を監査する手段のみでなく、企業ポリシーのユーザー管理面を実装するメカニズムも提供することができます。
Oracleのアイデンティティ管理製品を次に示します。
Access Manager
アクセス・サーバー
アイデンティティ・サーバー
以前はOracle COREid Aceess and Identityと呼ばれていたOracle Access Managerは、異機種間環境で稼働中のWebアプリケーションやリソースへのアイデンティティ管理およびアクセス制御を提供します。複雑なディレクトリ中心の環境で大規模なユーザーを管理するために必要な、ユーザーおよびグループ管理、委任管理、パスワード管理およびセルフ・サービス機能が使用できます。
Access Managerは、ブラウザ・フォーム、デジタル証明書およびスマートカードなどの一般的な認証メソッドをすべてサポートし、OracleAS 10g、Oracle WebLogic、IBM WebSphere、Vignetteなどのほとんどのアプリケーション・サーバーおよびポータルとシームレスに統合します。ユーザーIDおよび資格証明には、Oracle Internet Directory、Microsoft Active DirectoryおよびSun Java System Directoryを含む様々なリポジトリからアクセスできます。Access Managerを使用すると、ユーザー・アクセス・ポリシーを、粒度の高い集中管理を通じて定義および強制できます。
アクセス・サーバーを使用して、URLおよびHTTPではないレガシー・アプリケーションなどのリソースを保護できます。アクセス・サーバーにより、エンタープライズ・アプリケーションに対する認証および認可サービスが提供されます。アイデンティティ・サーバーで格納した情報を使用して、リソースにアクセスできるユーザー、グループおよび組織を制御します。また、Oracle Access Manager固有のオブジェクト・クラスを使用するディレクトリ・サーバーのリソースへのアクセスを制御する構成設定およびセキュリティ・ポリシーの情報を格納します。同じディレクトリを使用して、アクセス・サーバー構成設定、アクセス・ポリシー・データおよびユーザー・データを格納できます。このデータは異なるディレクトリ・サーバーにも格納できます。
アイデンティティ・サーバーは、アプリケーションのセットで、委任管理、ユーザー・セルフ・サービスおよびリアルタイム変更管理を提供します。アイデンティティ・サーバーは、ユーザー、グループおよび組織の情報を格納します。たとえば、ディレクトリ・サーバーのグループを作成、管理および削除できます。承認が不要なセルフサービス、承認が必要なサブスクリプション、ルール・ベースのサブスクリプション、サブスクリプション禁止などのグループに対するサブスクリプション・ポリシーを定義できます。
Oracle Identity Managerプラットフォームを使用すると、ユーザーIDのプロビジョニングおよびプロビジョニング解除が自動化され、企業によるユーザーIDのライフサイクルのエンドツーエンドにわたる管理が、ファイアウォールの内側と外側の両方のエンタープライズ・リソース全体で可能になります。また、包括的なワークフロー・エンジンに内包された、ユーザー・プロビジョニング、アイデンティティ管理およびパスワード管理を自動化するアイデンティティ管理プラットフォームを提供します。
自動ユーザーIDプロビジョニングによって、IT管理コストの削減およびセキュリティの向上が実現します。また、プロビジョニングは法規制のコンプライアンスにおいて重要な役割を果します。Oracle Identity Managerの主な機能には、パスワード管理、ワークフローおよびポリシー管理、IDリコンシリエーション、レポートおよび監査、アダプタを介した拡張性が含まれます。
また、Oracle Identity Managerでは、アテステーションがサポートされます。アテステーションは、ユーザーまたはシステム管理者が定期的に人々のアクセス権を確認するプロセスです。既存のサーベンス・オクスリー法が規定する要件では、すべての重要な財務システムに対して3〜6か月単位でアテステーションを実行することが企業に求められています。Identity Managerには、非常に柔軟性のあるアテステーション・ソリューションが含まれ、エンタープライズ顧客はこれを使用して費用効率が高くタイムリな方法でこれらの法的要件を満たすことができます。Identity Managerでアテステーション・プロセスを設定すると、エンタープライズ顧客は、評価のためのユーザー・アクセス権レポートの生成、伝達、確認、サインオフ、委任、追跡およびアーカイブのプロセスを定期的または不定期ベースで自動化できます。
ビジネス・プロセスをWebに移行する企業が増えるにつれて、多くの組織がエンタープライズの境界を拡大し、パートナ・アプリケーションを含める必要に迫られています。フェデレーテッド・アイデンティティ管理を使用すると、ドメイン間のシングル・サインオンが可能になり、他のドメインで管理されるリソースにアクセスする場合に、企業がユーザーIDを管理および保証できるため、企業は独立して業務を行いながらビジネス目的のために連携できます。
以前はCOREid Federationとして知られていたOracle Identity Federationは、スタンドアロン・アプリケーションの使いやすさと移植性を、スケーラブルで規格ベースの実績ある相互操作アーキテクチャと組み合せた、自己完結型のフェデレーション・ソリューションを提供します。これにより、企業がビジネス・パートナを企業ポータルまたはエクストラネットに安全にリンクできるようになり、また、企業のプライバシおよびセキュリティに関する規制へのコンプライアンスが高まります。IDフェデレーションを使用すると、企業は複数のパートナを管理しながら、連携した業界標準のプロトコルを選択できます。IDフェデレーションは、顧客のアイデンティティ管理インフラストラクチャ（OracleおよびOracle以外）との組込み統合を提供して包括的なユーザー・エクスペリエンスを実現し、自動登録、アイデンティティ・マッピング、シームレスなアクセス制御ナビゲーションなどの例に対応します。
Enterprise Managerを使用すると、エンタープライズ構成内のAccess、Identity、Identity FederationおよびIdentity Managerの可用性を監視し、状態を診断できます。各ホストに管理エージェントをデプロイすると、Enterprise Managerを使用して、自動的にこれらのホストのアイデンティティ管理コンポーネントを検出して、デフォルトの監視レベル、通知ルールなどを使用したこれらのキー・コンポーネントの監視を自動的に開始できます。
Access、Identity、Identity FederationおよびIdentity Managerのいずれにかかわらず、すべてのアイデンティティ管理ターゲットには、専用のサーバーのホームページがあり、このページから管理者に必要な主要情報に簡単にアクセスできます。アイデンティティ管理サーバーの各ホームページは次の機能を提供します。
サーバー・ステータス、応答性およびパフォーマンス・データ
問題を迅速に識別および解決するためのアラートおよび診断ドリルダウン
サーバーおよびそのコンポーネントのリソース使用率
ローカルで監視されるアクセス・サーバーおよびアイデンティティ・サーバーの場合、これらのコア・コンポーネントを起動、停止および再起動するための機能
アクセス・サーバーおよびアイデンティティ・サーバーの構成パラメータ
図8-16に、Access Managerのアクセス・サーバーのホームページを示します。
アイデンティティ管理サービスは、Grid Controlに定義されているIdentity Managementシステム上で動作します。システムには、アイデンティティ・サービスが使用するソフトウェア・インフラストラクチャ・コンポーネントが含まれます。システムには、データベース、HTTPサーバー、OC4Jおよびその他のサーバーなどのコンポーネントが含まれます。
システムは、アイデンティティ管理デプロイメントを構成するデータ・センター・コンポーネントのビューを提供するためにGrid Controlにまとめられたサーバー・ターゲットの集合です。Identity Managementシステムは、アイデンティティ・スイート・コンポーネントがGrid Controlで検出されると作成されます。Grid Controlでは、これらのコンポーネントのパフォーマンスおよび可用性も監視され、Identity Managementシステムの状態を表示するシステム・ダッシュボードも1つのウィンドウに表示されます。
図8-17に、Access Managerのアイデンティティ・システムのホームページを示します。
アイデンティティ管理サービスは、Grid Controlで構成される論理ターゲットです。Grid Controlを使用して、アイデンティティ・コンポーネント・インスタンスにWebアプリケーション・サービスの構成プロセスを段階的に実行します。サービスを構成した後、このサービスは「サービス」ページに表示されます。
Grid Controlでは、重要なアプリケーション機能はサービスとして定義および監視されます。各サービスはGrid Controlビーコンによって監視されます。ビーコンは、サービスに対する実際のユーザー・アクセスをシミュレートするサービス・テストを実行します。サービスの可用性およびパフォーマンスは自動的に監視され、問題はただちに管理者に報告されます。アイデンティティ管理サービスの可用性およびパフォーマンスを監視することにより、ユーザーから見える問題をより迅速に識別して解決できるため、ユーザーに与える影響を最小限に抑えることができます。
アクセス・サービスを使用すると、サービス・レベル監視を実行できます。認証または認可サービスが使用できない場合、管理者にサービスの不具合が通知されます。この場合、管理者は根本原因分析を実行して問題の原因を診断できます。
Grid Controlのアクセス・サーバー・ターゲットを検出します。ターゲット検出の詳細は、Grid Controlのヘルプを参照してください。これにより、関連付けられたシステムが作成されます。
Grid Controlの「サービス」タブから、「汎用サービスの追加」を選択し、「実行」をクリックします。
汎用サービスの作成ウィザードが表示されます。
「汎用サービスの作成: 一般」ページで、サービスの名前を指定し、Accessシステムを関連付けます。「次」をクリックします。
「汎用サービスの作成: 可用性」ページで、「サービス・テストに基づく可用性の定義」を選択します。これにより、Webトランザクションを作成できます。「次」をクリックします。
「汎用サービスの作成: サービス・テスト」ページで、「トランザクションの記録」を選択し、「実行」をクリックします。
「サービス・テストの作成」ページの「ステップ」セクションで、「記録」をクリックします。
「Webトランザクションの記録」ページで、「起動」をクリックします。新しいブラウザ・ウィンドウが表示されます。
ブラウザに、アクセス・サーバーで保護されているURLを入力します。「シングル・サインオンのログイン」が表示されたら、ユーザー名およびパスワードを入力します。
「Webトランザクションの記録」ページで、「停止」をクリックして「続行」をクリックします。「Webアプリケーションの作成: サービス・テスト」ページが再表示されます。「続行」をクリックします。
「汎用サービスの作成: ビーコン」ページで、作成したWebトランザクションを実行するビーコンを追加します。「次」をクリックします。
「汎用サービスの作成: パフォーマンス・メトリック」ページで、「次」をクリックします。
「汎用サービスの作成: 使用状況メトリック」ページで、「次」をクリックします。
「汎用サービスの作成: 確認」ページで、「終了」をクリックし、ビーコン・テストで監視するアクセス・サービスを作成します。
アイデンティティ・サービスを使用すると、管理者はAccess Manager IDのサービス・レベル監視を実行できます。ユーザー認証またはグループ認可サービスが使用できない場合、管理者にサービスの不具合が通知されます。この場合、管理者は根本原因分析を実行して問題の原因を診断できます。
Grid ControlのIdentityサーバー・ターゲットを検出します。ターゲット検出の詳細は、Grid Controlのヘルプを参照してください。これにより、関連付けられたシステムが作成されます。
Grid Controlの「サービス」タブから、「汎用サービスの追加」を選択し、「実行」をクリックします。
汎用サービスの作成ウィザードが表示されます。
「汎用サービスの作成: 一般」ページで、サービスの名前を指定し、アイデンティティ・システムを関連付けます。「次」をクリックします。
「汎用サービスの作成: 可用性」ページで、「サービス・テストに基づく可用性の定義」を選択します。これにより、Webトランザクションを作成できます。「次」をクリックします。
「汎用サービスの作成: サービス・テスト」ページで、「トランザクションの記録」を選択し、「実行」をクリックします。
「サービス・テストの作成」ページの「ステップ」セクションで、「記録」をクリックします。
「Webトランザクションの記録」ページで、「起動」をクリックします。新しいブラウザ・ウィンドウが表示されます。
ブラウザに、アイデンティティ・システムのURL（<host:port/identity/oblix>）を入力し、アイデンティティ・システムの「コンソール」リンクをクリックします。「ログイン」ページが表示されます。
「Webトランザクションの記録」ページで、「停止」をクリックして「続行」をクリックします。「Webアプリケーションの作成: サービス・テスト」ページが再表示されます。「続行」をクリックします。
「汎用サービスの作成: ビーコン」ページで、作成したWebトランザクションを実行するビーコンを追加します。「次」をクリックします。
「汎用サービスの作成: パフォーマンス・メトリック」ページで、「次」をクリックします。
「汎用サービスの作成: 使用状況メトリック」ページで、「次」をクリックします。
「汎用サービスの作成: 確認」ページで、「終了」をクリックし、ビーコン・テストで監視するアイデンティティ・サービスを作成します。
Identity ManagerのWebアプリケーション・サービスの作成の詳細は、オンライン・ヘルプのIdentity ManagerのWebアプリケーションの作成に関するトピックを参照してください。
Identity Federationのサービス・レベル監視のIdentity Federationサービスを作成できます。Identity Federationサービスを作成する手順は、Accessまたはアイデンティティ・サービスの作成手順と同様です。
Grid Controlを使用して、すべてのアイデンティティ管理サービスを監視できます。サービスごとに、パフォーマンス、使用状況および可用性が監視されます。
各サービスには、専用のホームページがあります。Grid Controlのサービスのホームページには、次が表示されます。
ステータス、応答性およびパフォーマンス・データ
サービスのリソース使用状況データ
その他のサービスおよび関連システムを含む、サービスのサブコンポーネントのステータス、パフォーマンス・アラート、使用状況アラートおよびポリシー違反などのサマリー情報
サービスのサブコンポーネントのホームページへのリンク
問題を迅速に識別および解決するためのアラートおよび診断ドリルダウン
サービス・ダッシュボード
サービス・ダッシュボードには、各アイデンティティ管理ターゲットのステータス、パフォーマンスおよび使用状況に関する最上位のビューが表示されます。また、ダッシュボードには、サービスごとに様々な期間におけるサービス・レベルのコンプライアンスも表示されます。ダッシュボードはアイデンティティ・システム・ターゲットのホームページから直接起動できます。また、Enterprise Managerユーザー以外のユーザーが表示できるように、サービス・ダッシュボードを公開することもできます。これにより、管理者はエンド・ユーザーに対してセルフサービス・ステータスのWebページを提供できます。
次を実行するための関連リンク
サービスのメトリックの表示
クライアント構成の表示
サービスの編集
サービス・ターゲットのプロパティの表示
ブラックアウトの管理
メトリックしきい値およびポリシーの表示および管理
アイデンティティ管理の個別のサービスは、重要なシステム・コンポーネントに関連付けられます。これにより、Enterprise Managerは、サービス停止が検出されるたびにシステム・レベルまで根本原因分析を実行できます。Grid Controlでアイデンティティ管理サービスを構成する場合、このサービスの重要なシステム・コンポーネントも構成されます。アイデンティティ管理サービスが停止すると、Enterprise Managerは根本原因分析を自動的に実行し、停止の原因の重要なシステム・コンポーネントを判別します。
Enterprise Managerは、エンタープライズ全体に分散している診断情報をアイデンティティ管理ターゲットから自動的に収集して評価します。Enterprise Managerで管理するすべてのターゲットの場合と同様に、アイデンティティ管理の多数のパフォーマンス・メトリックが事前定義済しきい値を超えていないか、自動的に監視されます。Grid Controlでは、メトリックがこれらのしきい値を超えた場合にアラートが生成されます。
Grid Controlを使用して、アイデンティティ管理サービスのパフォーマンスおよび可用性の問題を診断できます。たとえば、サービスが停止した場合、根本原因分析により、主な原因が重要なサービス/システム・コンポーネントの停止であるかどうかを確認します。サービスのパフォーマンスの問題が検出された場合、管理者は、このサービスおよびこのサービスによって使用される任意のサービス/システム・コンポーネントに関連する詳細なメトリックを一定期間にわたって調査できます。Identity Managementシステムの1つ以上のサーバー・コンポーネントに問題があると考えられる場合、システムのホームページのメトリックおよびグラフを使用して問題を診断できます。
Grid Controlには、アイデンティティ管理の管理者にとって役立つ、次のような一般的な機能が多数用意されています。
ジョブの自動化: Grid Controlのジョブ・システムを使用して、自動化するタスクをスケジュールできます。
ポリシー: ポリシー・フレームワークを使用して、アイデンティティ管理インフラストラクチャをサイト固有の規格に準拠させることができます。
データベースおよびアプリケーション・サーバー管理: 1つのGrid Controlコンソールを使用して、必要に応じてアイデンティティ管理デプロイメント内の特定のデータベースおよびアプリケーション・サーバーを管理することもできます。
拡張機能: Grid Controlには、アイデンティティ管理デプロイメントの一部である可能性がある主要なネットワーク・コンポーネントの監視機能も用意されています。また、Grid Controlを拡張し、Enterprise Managerでは即時に認識されないその他のコンポーネントを監視することもできます。
