10gリリース5（10.2.0.5.0）
B53907-01
 目次 |
 索引 |
| Oracle Enterprise Manager アドバンスト構成 10gリリース5（10.2.0.5.0） B53907-01 |
|
この章では次の項について説明します。
ホスト・コンピュータにOracle Management Agentをインストールすると、Enterprise Managerでは自動的にデフォルト・メトリック・セットの収集が開始されます。これは、そのホスト上の各ターゲットのパフォーマンスおよび可用性の監視に使用できます。これらのターゲット・メトリックの一部については、デフォルトのしきい値設定（メトリックにおける問題を通知する時期を決定）がEnterprise Managerに用意されています。
選択したメトリックについて、デフォルトのしきい値をカスタマイズできます。このようなカスタマイズを実行すると、新規の設定がローカル・ディスク上のファイルに保存されます。これらの設定の保存について、次の項でより詳しく説明します。
Enterprise Managerでは各ターゲットに対するデフォルトの収集基準が、各Oracle Management Agentホストの次の場所に保存されます。
AGENT_HOME/sysman/admin/default_collection/
一部のターゲットについては、Oracle Enterprise Manager 10g Grid Controlコンソールを使用してデフォルトのメトリック収集設定を変更できます。たとえば、ホスト・ターゲットのデフォルトのしきい値を変更できます。このような変更を実行すると、新規のデフォルト収集ファイルが次のディレクトリに作成されます。
AGENT_HOME/sysman/emd/collection/
この収集ファイルは、sysman/admin/default_collectionディレクトリに保存されているデフォルトの収集情報を上書きします。
特定のターゲットのメトリックしきい値を変更した場合、sysman/emd/collectionディレクトリからカスタマイズ収集情報を削除することによって、デフォルトのメトリック収集設定をリストアできます。
たとえば、特定のデータベース・ターゲットのデフォルト収集をリストアする場合は、そのターゲットに対するカスタマイズ収集ファイルをsysman/emd/collectionディレクトリから削除します。Enterprise Managerでは、sysman/admin/default_collectionディレクトリに保存されているメトリック収集情報の使用が開始されます。
Oracleソフトウェア製品をホスト・コンピュータにインストールするたびに、Oracle Universal Installerによってソフトウェアのインストール情報がハード・ディスクに保存されます。このソフトウェア構成情報を含むディレクトリおよびファイルは、Oracle Universal Installerインベントリと呼ばれます。
Enterprise Managerを使用してOracleソフトウェアのインストールを監視する際、Universal Installerインベントリに保存されている情報が利用されます。
ホスト・コンピュータの構成に関する情報を収集する際、デフォルトでは、ホスト上に1つのOracle Universal Installerインベントリがあるものと想定されます。具体的には、Enterprise Managerはホスト上でOracle Universal Installerを実行する際に使用されるインベントリを認識します。
ただし、複数のインベントリがある場合もあります。たとえば、Oracleサポートに連絡をとり、Oracleソフトウェア・インストールのクローンを作成しているような場合です。このような場合は、次の手順を使用して、同一ホスト上の複数のインベントリのソフトウェア情報をEnterprise Managerで追跡および管理できるようにしてください。
ホスト上の複数のインベントリを認識できるようにEnterprise Managerを設定するには、次のようにします。
この例で示した管理エージェントの状態は、Database Controlのインストールを表します。他のインストールに使用する管理エージェント状態の詳細は、
16.2.1項「AGENT_HOMEディレクトリとAGENT_STATEディレクトリ」を参照してください。
OUIinventories.addを開きます。ファイル内の指示には、Oracleホームのマッピングに関するその他の技法とともに、複数のインベントリの指定時に使用する書式が記述されています。
次のホスト構成情報の収集時に、通常Enterprise Managerで収集されるデフォルト・インベントリに加えて、OUIinventories.addファイルで指定したインベントリからもソフトウェア構成情報の収集が開始されます。
もう1つの方法として、次の定期収集スケジュールの前に追加インベントリから収集されるデータを確認するには、Grid Controlコンソールの「ホスト」ホームページにナビゲートして、「構成」タブをクリックし、ページ・タイムスタンプの横にある「データを更新」アイコンをクリックします。
管理エージェントは、主要な2つのディレクトリ構造を認識します。1つは、ソフトウェア・バイナリおよびすべての未変更メタデータが格納されるインストール・ディレクトリです。もう1つは、すべてのカスタマイズ内容および出力とログの内容の、格納または生成、あるいはその両方が行われる構成/状態ディレクトリです。標準の管理エージェント・インストールでは、この2つのディレクトリは同じです。ただし次の場合は、この2つのディレクトリが別になることもあります。
emctl deploy agentコマンドを使用する）状態のみの管理エージェント・デプロイ（$ORACLE_HOMEと$EMSTATE）
前述の各例では、同じバイナリ・インストールから管理エージェントの複数のインスタンスが実行されます。これらのインスタンスは個々の構成を保守するために別々の場所を持ちますが、同じバイナリ・セットを使用します。コマンドemctl agent statusを使用すると、管理エージェントのバイナリおよび状態の場所の値がわかります。
Oracle Database 10gターゲットを最初に検出した際、監視資格証明をチェックして、DBSNMPデータベース・ユーザー・アカウントのパスワードがデータベース・ターゲット・プロパティで正しく設定されていることを確認します。
監視資格証明の設定以外に、Oracle Database 10gターゲットを監視するために必要な構成タスクはありません。
ただし、Oracle9iデータベースまたはOracle8iデータベースを監視するとき、Grid Controlコンソールを使用して特定のタイプのデータベース・パフォーマンス・メトリックを監視する場合には追加構成が必要です。
これらの追加パフォーマンス・メトリックを監視するには、Oracle Statspackおよびその他のEnterprise Managerパッケージが、監視中のデータベースにインストールされ構成されていることが必要です。
これらの追加オブジェクトがデータベース内になく構成もされていない場合、Enterprise Managerは完全なパフォーマンス・メトリック・セット用のデータを収集することができません。また、「エラーSQL」や「上位SQLレポート」のような、通常なら「データベース」ホームページから容易に入手できるような情報もEnterprise Managerでは収集できなくなります。
Grid Controlコンソールで「データベースの構成」ウィザードを使用して必要なパッケージをデータベースにインストールするか、もしくは次の手動による手順を使用します。
Statspackおよびその他の必須データベース・オブジェクトを、Enterprise Managerで管理中のOracle9iデータベースに手動でインストールするには、SQL*Plusおよび次の手順を使用します。
この手順の各コマンドについて、AGENT_HOMEをOracle Management Agentホーム・ディレクトリの実際のパスに置き換え、ORACLE_HOMEをデータベース・ホーム・ディレクトリのパスに置き換えてください。
次に例を示します。
$PROMPT> ./sqlplus "connect / as sysdba"
SQL> @AGENT_HOME/sysman/admin/scripts/db/config/dbmon
次のプロンプトが表示されます。
Enter value for dbm_password:
スクリプトで各種の構成変更が実行され、再びSQL*Plusプロンプトが表示されます。
次に例を示します。
SQL> connect DBSNMP
SQL> @AGENT_HOME/sysman/admin/scripts/db/config/response.plb SQL> grant EXECUTE on dbsnmp.mgmt_response to OEM_MONITOR;
SQL> @ORACLE_HOME/rdbms/admin/spcreate
次に例を示します。
SQL> connect PERFSTAT;
SQL> define snap_level='6'; SQL> define cinterval='1'; SQL> define cjobno='-1'; SQL> @AGENT_HOME/sysman/admin/scripts/db/config/spset
SQL> grant OEM_MONITOR to dbsnmp;
grant select on sys.ts$ to OEM_MONITOR; grant select on sys.seg$ to OEM_MONITOR; grant select on sys.user$ to OEM_MONITOR; grant select on sys.obj$ to OEM_MONITOR; grant select on sys.sys_objects to OEM_MONITOR; grant select on sys.file$ to OEM_MONITOR; grant select on sys.attrcol$ to OEM_MONITOR; grant select on sys.clu$ to OEM_MONITOR; grant select on sys.col$ to OEM_MONITOR; grant select on sys.ind$ to OEM_MONITOR; grant select on sys.indpart$ to OEM_MONITOR; grant select on sys.indsubpart$ to OEM_MONITOR; grant select on sys.lob$ to OEM_MONITOR; grant select on sys.lobfrag$ to OEM_MONITOR; grant select on sys.partobj$ to OEM_MONITOR; grant select on sys.tab$ to OEM_MONITOR; grant select on sys.tabpart$ to OEM_MONITOR; grant select on sys.tabsubpart$ to OEM_MONITOR; grant select on sys.undo$ to OEM_MONITOR;
SQL> show parameter job_queue_processes
show parameterコマンドの出力がゼロの場合は、次の手順を実行してjob_queue_processes初期化パラメータを変更します。
spfileを使用してデータベースを起動する場合は、次のコマンドを入力します。
SQL> alter system set job_queue_processes = 2 SCOPE=BOTH;
その他の場合は次の手順を実行します。
AGENT_HOME/bin
$PROMPT> ./emctl agent reload
Grid Controlコンソールへの不正なアクセスを回避するため、事前定義された一定期間の間にアクティビティが発生しない場合、ユーザーはGrid Controlコンソールから自動的にログアウトします。たとえば、ユーザーがブラウザを起動したまま職場を離れた場合でも、このデフォルト機能により、Enterprise Managerの管理者アカウントを他の無認可のユーザーが使用することはできません。
デフォルトでは、システムが45分以上アクティブでない状態が続くと、Enterprise Managerの処理を実行しようとしても再度Grid Controlコンソールにログインすることを求められます。
デフォルトのタイムアウト時間を延長または短縮するには、次のようにします。
IAS_HOME/sysman/config/
emoms.propertiesファイルを開き次のエントリを追加します。
oracle.sysman.eml.maxInactiveTime=time_in_minutes
oracle.sysman.eml.maxInactiveTime=60
emoms.propertiesファイルを保存して閉じます。
この項では、クラスタ、クラスタ・データベース、および検出インスタンスの構成方法について説明します。
インストールされたが、インストール中にターゲットして自動的に検出されなかったクラスタ・ターゲットを追加するには、次の手順を実行します。
クラスタ・ターゲットを追加した後は、「データベース」ページまたは「すべてのターゲット」ページからクラスタ・データベース・ターゲットを追加できます。
クラスタ・データベース・ターゲットを追加するには、次の手順を実行します。
ターゲットの検出が完了すると、「クラスタでターゲットが検出されました」ページに、新しく検出されたRACデータベースが表示されます。データベースが表示されない場合は、後述の「トラブルシューティング」の項を参照してください。
追加のインスタンスを構成する必要がある場合、次の手順に従います。
構成の問題が発生した場合は、次の必要な条件をチェックして、自動検出が正常に機能することを確認してください。
前述の条件を確認した後も自動検出で構成の問題が解決されない場合は、クラスタ・データベースを手動で構成できます（16.5.2項「クラスタ・データベースの構成」を参照）。
Oracle Enterprise Manager Grid Controlの構成の詳細は、第3章「Grid Controlの一般的な構成」を参照してください。
クライアントは、ホストおよびオペレーティング・システムのユーザーです。収集されるクライアント構成データには、次のものがあります。
クライアント・システム・アナライザ（CSA）を使用すると、Webサーバーの管理者はエンドユーザーのクライアント・データを収集および分析できます。クライアント・データはアプレットにより収集され、診断されてCSAアプリケーションに送り返されます。Oracle Management Agentは、このデータをEnterprise Managerの管理リポジトリにアップロードします。クライアント構成収集アプレットによりクライアント構成データが収集され、CSAアプレットで指定されたWebサーバー・ディレクトリに書き込まれた後、そのクライアント構成データはOracle Management Repositoryにアップロードされます。
クライアント・システム・アナライザは、Enterprise ManagerとともにプリインストールされているGrid Controlアプリケーションで使用できます。あるいは、CSAを別個にWebサーバーにデプロイすることもできます。
Grid Controlのクライアント・システム・アナライザ（CSA）のインスタンスは、Enterprise Managerとともにプリインストールされています。このオプションを使用すると、個別のWebサーバーを設定しなくてもクライアント・データを収集できます。プリインストールされたCSAアプリケーションをEnterprise Managerでアクティブにするには、「デプロイ」をクリックします。次に「Grid Controlのクライアント・システム・アナライザ」をクリックし、アプリケーションをアクティブにするためのボタンを使用します。CSAがアクティブになると、エンドユーザーは、CSAアプレットを実行するために提供されたURLを使用できるようになります。CSAアプレットは、クライアント・システムから基本クライアント構成情報を収集し、Oracle Collaboration Suiteクライアント・システムからOracle Collaboration Suiteクライアント情報を収集できます。
クライアント・システム・アナライザ・アプリケーションは、別個に任意のJ2EE対応Webサーバーにデプロイできます。「デプロイ」タブをクリックします。次に「クライアント・システム・アナライザの開始」をクリックし、「クライアント・システム・アナライザ・アプリケーションのデプロイ」をクリックします。次の手順に従ってCSAアプレットをデプロイし、クライアント構成データを収集します。
CSAアプリケーションには、CSAディレクトリと必要なJSPアプレット・ファイルが含まれています。CSAアプリケーションは、EARファイルとしてパッケージ化されています。このデフォルトEARファイルをダウンロードするには、「クライアント・システム・アナライザ・アプリケーションのダウンロード」をクリックします。デフォルトのCSA EARファイルをカスタマイズするには、次の要素を変更します。
CSAアプリケーションは、標準のJ2EEアプリケーションとしてアプリケーション・サーバー上にデプロイされます。CSAアプリケーションをデプロイした後は、他のWebアプリケーションと同様に、コンテキスト・パラメータを変更できます。
クライアント・データを収集するためには、ユーザーがCSAアプリケーションにアクセスする必要があります。ユーザーはCSA JSPページに直接アクセスするか、または別のアプリケーションからリンクを使用してアクセスできます。次の方法を使用すると、ユーザーをCSAに自動的にリダイレクトできます。
収集されたクライアント・データは、Webサーバー上の受信ファイル・ディレクトリ内に記録されます。収集されたクライアント・データをEnterprise Managerにアップロードするには、次の操作を実行する必要があります。
CSAデプロイをテストするには、CSAページのURLをクリックし、クライアント・データが収集されていることを確認します。
クライアント・システム・アナライザ（CSA）を詳細に構成するには、CSAアプリケーションのWARファイル内のコンテキスト・パラメータを変更します。
これらのパラメータの他に、CSAリダイレクション・パラメータも構成可能です。リダイレクションを有効にするには、サーブレット・フィルタを使用するか、他のいくつかのページにCSAリダイレクションJSPファイルを追加します。リダイレクションが機能するためには、次のコンテキスト・パラメータが使用可能になっている必要があります。
異なるアプリケーションに対して、異なるパラメータ・セットが必要となる場合もあります。たとえば、異なるルール・セットおよびカスタム・コードを持つ2つの異なるアプリケーションがあり、管理者がそれらを異なるCSAコレクタ・ターゲットに関連付けるとします。このようなシナリオでは、管理者は、<application name> ruleFileや<application name> appletJarなどのコンテキスト・パラメータを使用して、特定のアプリケーションに対してruleFile、appletJar、scriptおよびoutputDirパラメータを指定することができます。コンテキスト・パラメータとして、またはURLを介してアプリケーションを指定すると、CSAはそのアプリケーションに固有のパラメータ値を使用して実行されます。アプリケーションを指定しない場合、またはアプリケーションのパラメータが1つも上書きされていない場合は、デフォルトのパラメータが使用されます。
システムが特定の制約条件を満たしているかどうかに関する即時のフィードバックをユーザーが受けられるように、CSAアプリケーションにカスタム・ルールを指定できます。例16-1にRULESファイルの例を示し、その後にファイル内に含まれる各タグについて説明します。
<RULES> <RULE> <NAME>Client has sufficient memory</NAME> <DESCRIPTION>Checks to see if the client has enough memory to run the application</DESCRIPTION> <VIOLATION> //ROWSET[@TABLE='MGMT_ECM_HW']/ROW/AVAIL_MEMORY_SIZE_IN_MB[number() < $arg=SIZE$] </VIOLATION> <SEVERITY level="CRITICAL"> <PARAM id='SIZE'>100</PARAM> <MOREINFO> <TEXT>Application cannot run with less than 100 MB. </TEXT> </MOREINFO> </SEVERITY> <SEVERITY level="WARNING"> <PARAM id='SIZE'>150</PARAM> <MOREINFO> <TEXT>Approaching minimum memory level</TEXT> </MOREINFO> </SEVERITY> </RULE> </RULES>
例16-1は、クライアントにアプリケーションを実行するための十分なメモリーがあるかどうかをチェックするために使用可能なルールを示したものです。<VIOLATION>は、アプレットが、すべての収集済データが含まれたXMLファイルに対して評価するXPATH式です。この違反はXMLファイルに組み込まれたXPATH式であるため、XPATH内の<、>、&などの特定の文字は、実体に置き換える必要があります。XPATH式がNull以外のノード・セットを返す場合、ルールは失敗しています。この例では、クライアントの使用可能メモリーが特定量に満たない場合、ルールは失敗します。違反をトリガーする実際の量は、様々な重大度レベルを使用して構成できます。
例16-1では、アプレットは最初にVIOLATION式内の部分文字列$arg=SIZE$を100に置き換えてから、式を評価します。クライアントの使用可能メモリーが100MB未満の場合、ルールは失敗し、ステータスがクリティカルになります。アプレットは、「Application cannot run with less than 100 MB of memory」というメッセージとともにこのステータスを示します。ルールが正常に成功した場合、アプレットは$arg=SIZE$を150に置き換えて再試行します。このルールが失敗した場合、アプレットは「Approaching minimum memory level」というメッセージを表示します。アプレットがすべての指定の重大度レベルを通過したが、違反が検出されなかった場合、ルールは成功です。
管理者は、カスタム・プロパティを収集するためのカスタム・クラスを作成する他に、デプロイメント・ディスクリプタ内にカスタム・プロパティを指定することができます。カスタム・プロパティ名を指定するには、csa value_<name>という形式のコンテキスト・パラメータを含めます。コンテキスト・パラメータ名の<name>フィールドは、クライアント・システム・アナライザ（CSA）によってカスタム・プロパティ名として扱われ、パラメータの値はカスタム・プロパティ値として扱われます。同様に、管理者はcsa_type_<name>、csa_type_ui_<name>、csa_name_ui_<name>、csa_display_ui_<name>およびcsa_history_tracking_<name>パラメータを使用して、type、type_ui、name_ui、display_uiおよびhistory_trackingフィールドをそれぞれ指定できます。また、同じネーミング規則を使用して、CSAアプレットURLに対してカスタム・プロパティを指定することもできます。
次の各項では、クライアント構成のユースケースの例を概説します。
管理者は、2つの異なるWebアプリケーションを使用してユーザーの互換性をチェックできます。1つ目は、多数の各種プラグインを使用してコンテンツを配信するオンライン教育Webサイトです。これにより管理者は、すべてのユーザーが必要なプラグインをインストールしていることを確認できます。2つ目はソフトウェアのディストリビューション・ポータルです。これにより管理者は、ポータルからソフトウェアをダウンロードするすべてのユーザーが必要なハードウェアおよびオペレーティング・システムを使用していることを確認できます。この場合、両方のアプリケーションに固有のルール・セットが必要ですが、管理者は次のリストに示された収集タグを使用することで、両方のアプリケーションに対して1つのCSAインスタンスを使用できます。
<context-param> <param-name>csa teaching ruleFile</param-name> <param-value>teaching_rules.xml</param-value> </context-param> <context-param> <param-name>csa distribution ruleFile</param-name> <param-value>distribution_rules.xml</param-value> </context-param>
例16-2は、ルール・ファイルを選択するための収集タグの使用のみを示しています。しかし、収集タグはどのCSAコンテキスト・パラメータに対しても使用できます。
また、収集タグは、クライアント構成がEnterprise Manager管理リポジトリに格納される方法にも影響を与えます。ユーザーが例16-2のteachingアプリケーションからのリンクを使用してCSAにアクセスした場合、CSAは収集タグteachingのルールを実行する他に、このタグをクライアント構成データとともに管理リポジトリに格納します。収集タグは、クライアント構成の一意の識別子の一部となります。このため、1つのクライアントが管理リポジトリ内に、それぞれ固有のタグを含む複数の構成を持つことが可能になります。クライアント・データへのアクセスを制限するために、収集タグをEnterprise Managerターゲットに関連付けることができます。この場合、Enterprise Managerユーザーがクライアント構成の収集タグに関連付けられたターゲットに対する表示権限を持つ場合に、そのクライアント構成の表示のみが可能です。
たとえば例16-2で、teachingアプリケーションのホスティングにホストH1、アプリケーション・サーバーA1およびデータベースD1が使用され、distributionアプリケーションにホストH2、アプリケーション・サーバーA2およびデータベースD2が使用されるとします。6つのターゲットはすべてEnterprise Managerにより監視されており、ユーザーXはA1、H1およびD1へのアクセス権を、ユーザーYはA2、H2およびD2へのアクセス権を持っています。2人のEnterprise Managerユーザーそれぞれが、アプリケーションの1つに使用されるリソースを監視しているため、各ユーザーがそのアプリケーションのクライアントも監視していると考えられます。その場合、Enterprise Managerのスーパーユーザーは、teachingタグをA1、D1またはH1に関連付け、distributionタグをA2、D2またはH2に関連付けます。これにより、ユーザーXはteachingタグを持つすべてのクライアント構成を表示でき、ユーザーYはdistributionタグを持つすべての構成を表示できます。
Enterprise Managerでクライアント・データへのアクセスを制限するには、収集タグを使用します。ユーザーが表示権限を持つターゲットにクライアント構成の収集タグが関連付けられている場合のみ、ユーザーはそのクライアント構成を表示できます。たとえば、収集タグCがターゲットT1と関連付けられている場合、ターゲットT1を表示できるユーザーのみが、タグCを持つクライアント構成を表示できます。例16-2では、ユーザーXはteachingタグに関連付けられたターゲットに対する表示権限を持つため、teachingタグを持つクライアント構成を表示できます。しかし、distributionタグは、ユーザーXが表示できるどのターゲットにも関連付けられていないため、ユーザーXはdistributionタグを持つクライアント構成を表示できません。スーパーユーザーは、「収集タグの関連付け」ページを使用して、収集タグをターゲットに関連付けることができます。このページには、「デプロイ」タブから、または「設定」ページの「Grid Controlのクライアント・システム・アナライザ」リンクからアクセスできます。スーパーユーザーは、収集タグの関連付けの内容に関係なく、すべてのクライアント構成を表示できます。
通常のCSAデータ以外に電子メール・クライアントのユーザー設定も行う必要のある管理者は、例16-3に示すように、カスタマイズAPIを使用することにより、このデータをCSAにより収集された他のデータに追加できます。
oracle.symsan.eml.ecm.csa.CSAResultInterfaceを実装する1つのクラスと、oracle.sysman.eml.ecm.csa.CSACustomIntefaceを実装する1つのクラスが必要です。どちらのクラスも、例16-3に示されています。前者はacme.csa.custom、後者はacme.csa.resultとしています。
public interface CSACustomInterface { /** * requires: none * effects: returns a CSAResultInterface object that may contain custom * properties. Other effects are determined by the customActions method * in the implementing class * modifies: unknown - dependent on implementing class. * @param inputData contains client config data collected by default, plus * applet parameters, etc.None of the data in the inputData is guaranteed * to be there as there could have been collection errors. * @return a data structure that may contain custom properties */ CSAResultInterface customActions(CSAInputInterface inputData); } public interface CSAResultInterface { /** * requires: none * effects: returns an array of custom properties * modifies:none * @return String[][7] where ... * * String[i][0] is a name * String[i][1] is a value of the i-th row. (Type and name must be unique.) * String[i][2] is a type/category of data (could be null), * String[i][3] is the displayed value of the name of the property * String[i][4] is the displayed value of the type of the property * String[i][5] indicates data item (ie "Y") whose history should be computed * String[i][6] indicates data item (ie "Y") should be displayed in default UI */ String[][] getResultsData(); } public interface CSAInputInterface { /** * Get data value for given name * requires: name is not null * effects: returns the data value associated with the name * modifies: none * @param name the name of the key whose value is to be returned * @return the value assocaited with name * */ String getDataValue(String name); /** * Get table-formatted data. * requires: name is not null * effects: returns the table with this name * modifies: none * @param name the name of the table * @return the rows of the child tables * */ CSAInputInterface[] getDataTable(String name); }
カスタム・コードにより収集された追加データは、表MGMT_ECM_CSA_CUSTOMに格納されます。カスタム・コードは、データをこの表に追加するために、CSAResultInterfaceを実装するオブジェクト内にデータを返します。また、アプレットによりcustomActionsメソッドに渡されるCSAInputInterfaceオブジェクトを変更することで、CSAによって収集された標準のデータを操作できます。
カスタム・コードはルールの評価前に実行されるため、管理者はカスタム・データに基づくルールを記述することもできます。たとえば、管理者が、適切なIMAPサーバーでユーザーの電子メール・クライアントが設定されていない場合にクリティカル・エラーが発生するようなルールを記述するとします。この場合、管理者は、IMAPサーバーの設定を取り出してMGMT_ECM_CSA_CUSTOM表に格納するカスタム・コードを記述してから、これらの値をチェックするルールを記述します。
CSAはユーザーのマシン上での管理エージェントの使用には関与しないため、管理リポジトリ内のデータを最新の状態に保つには、エンド・ユーザーがCSAを定期的に実行するしかありません。これを確実に行うために、ユーザーがCSAを最近実行したかどうかをチェックし、実行していなければCSAを再び実行するようユーザーに通知するという方法があります。このチェックは、Oracleが提供するCSAサーブレット・フィルタを使用して実施できます。
CSAサーブレット・フィルタは、ユーザーのブラウザが実行されるたびに、CSAで設定されたCookieをチェックします。このCookieのペイロードによりCSAの最後の実行時刻が示されます。このフィルタを使用するには、管理者が、頻繁にアクセスされるアプリケーション（従業員ポータルなど）の前にこのフィルタを配置します。次に、ユーザーがCSAを実行する時間間隔を設定します。ユーザーがポータル・アプリケーションへの接続を試行するたびに、フィルタがそのリクエストを遮断し、CSA Cookieをチェックします。Cookieが存在しない場合、またはその存続期間が管理者が指定した実行間隔を超過している場合、ユーザーはCSAページにダイレクトされます。それ以外の場合、ユーザーはアプリケーションへの接続を許可されます。
たとえば、Acme CorporationのCSAインスタンスがwww.acme.com/csa/CSA.jspにデプロイされているとします。また、この会社のポータルがwww.acme.com/portalにあり、従業員はこのポータルを使用して電子メールのチェック、個人情報へのアクセス、または会社に関連するニュースを表示できるとします。ポータルは従業員によって頻繁にアクセスされるため、Acmeの管理者は、CSAデータを最新の状態に保つためにこのポータルを使用することにします。この場合、管理者は次の手順を実行します。
<context-param> <param-name>csa csaURL</param-name> <param-value>www.acme.com/csa/CSA.jsp</param-value> </context-param> <context-param> <param-name>csa execInterval</param-name> <param-value>2592000</param-value> </context-param>
バックグラウンドの別個のブラウザ・ウィンドウ内でCSAを実行する方法もあります。これを設定するには、csa_uiModeパラメータを使用します。このパラメータを1に設定した場合、フィルタは最初のウィンドウと同じサイズの新しいブラウザ・ウィンドウを開き、CSAページに移動します。パラメータを2に設定した場合、CSAは不可視モードで実行されます。この場合、フィルタは新しいブラウザ・ウィンドウを開くとすぐに最小化し、CSAが完了すると同時にウィンドウを閉じます。
次のデプロイ例では、主要な3つの要素が登場します。1つ目は、CSAの設定を行うCSA管理者です。2つ目は、Enterprise Managerでクライアント・データを表示するEnterprise Managerユーザーです。3つ目はエンド・ユーザーです。エンド・ユーザーのデータはCSAにより収集されます。
この例では、CSA管理者はCSAを使用してヘルプデスクの業務をサポートしています。特定のアプリケーションの実行で問題が発生すると、エンド・ユーザーはカスタマ・サポートをコールできます。カスタマ・サポートの技術担当者は、必要に応じて、特定のURLにアクセスしてCSAを実行するようにユーザーに指示できます。Enterprise Managerユーザーは、CSAにより収集されたデータを使用してエンド・ユーザーをアシストするサポート担当者です。顧客の問題を診断するプロセスの時間を短縮するため、CSA管理者は、ヘルプデスク担当者が考えられる問題を素早く特定できるよう、rules.xmlというファイル内にいくつかのルールを作成します。最も単純な例として、1つのアプリケーションのサポートを行うヘルプデスクを設置するとします。アプリケーションはホストapplication.acme.com上のアプリケーション・サーバーで実行されています。このホストにはEnterprise Managerの管理エージェントがインストールされており、この管理エージェントが、oms.acme.com/emにある管理サービスにデータを戻します。クライアント・データを確認しようとするヘルプデスク担当者は、ユーザーhelpdeskとしてEnterprise Managerにログインできます。このユーザーにスーパーユーザー権限はありません。
前述の設定では、ユーザーがヘルプデスクをコールしてアプリケーションのサポートを依頼すると、ヘルプデスクの技術担当者は、application.acme.comにある適切なURLからCSAを実行するようにユーザーに指示できます。管理エージェントは、一定時間の経過後にデータを収集し、そのデータを管理リポジトリにロードします。ヘルプデスクの技術担当者は、helpdeskとしてEnterprise Managerにログインし、顧客のオペレーティング・システム・ユーザー名やホスト名などの識別フィールドを検索して顧客情報を見つけることができます。デフォルトでは、管理エージェントは2分ごとに出力ディレクトリの新しいデータをチェックします。ただし、$ORACLE_HOME/sysman/admin/default_collection/oracle_csa_collector.xmlファイルを編集することで、この時間間隔は短くできます。
例16-4では、システム管理者が、人事管理（HR）部と販売部の2つの部署の従業員が使用するハードウェアおよびソフトウェアを監視します。この管理者は、Enterprise Managerユーザーでもあり、CSA管理者でもあります。この例の設定は、サーブレット・フィルタの使用例で説明した設定と似ていますが、ここでは、各部署がそれぞれのポータル・アプリケーションをhr.acme.com/portalおよびsales.acme.com/portalに置いています。管理者はホストserver1.acme.com上にアプリケーション・サーバーを設定し、URL http://server1.acme.com/csa/CSA.jspを使用してCSAをデプロイします。server1.acme.comの管理エージェントは、データを収集し、それをoms.acme.com/emにある管理サーバーに送信します。管理者は30日に1回データを収集し、不可視モードでCSAを実行しようとしています。また、2つの異なる部署のデータを、hrおよびsalesという異なる収集タグを使用して区別しようとしています。管理者は、sysmanとしてEnterprise Managerにログインできるため、両方のタグを持つクライアントを表示できます。
管理者は、両方のアプリケーションにCSAサーブレット・フィルタをデプロイすることによって、ユーザーがCSAにダイレクトされるように調整します。2つのアプリケーションのフィルタ・コンテキスト・パラメータの大部分は同じです。ただし、各アプリケーションは別々のタグに対応しているため、csa csaURLパラメータの値は少し異なります。HRポータルの値はhttp://server1.acme.com/csa/CSA.jsp?application=hrであり、販売ポータルの値はhttp://server1.acme.com/csa/CSA.jsp?application=salesです。
<context-param> <param-name>csa csaURL</param-name> <param-value>www.acme.com/csa/CSA.jsp?application=sales</param-value> </context-param> <context-param> <param-name>csa execInterval</param-name> <param-value>2592000</param-value> </context-param> <context-param> <param-name>csa uiMode</param-name> <param-value>2</param-value> </context-param>
この設定では、HRポータルからCSAにダイレクトされるHR部のユーザーはタグhrを持ち、販売部のユーザーはタグsalesを持ちます。このため、管理者がHR部のマシン上のハードウェアのみの情報を表示しようとする場合には、Enterprise Managerで「クライアント構成」ページの「収集タグ」フィルタを使用し、単にこれをhrに設定します。
この例では、CSAを使用して、アプリケーションの実行中に発生する可能性のある問題をエンド・ユーザーに通知することが最終的な目標です。設定は例2で使用した設定と似ていますが、この例では、CSA管理者はアプリケーションごとにルールを作成します。また管理者は、エンド・ユーザーが可能性のある問題を確認できるように、最初のブラウザ・ウィンドウ内でCSAを実行することにしています。
例16-5は、販売ポータル上のCSAサーブレット・フィルタのコンテキスト・パラメータ値を示しています。
<context-param> <param-name>csa csaURL</param-name> <param-value>www.acme.com/csa/CSA.jsp?application=sales</param-value> </context-param> <context-param> <param-name>csa execInterval</param-name> <param-value>2592000</param-value> </context-param> <context-param> <param-name>csa uiMode</param-name> <param-value>0</param-value> </context-param>
例16-6は、ルールを収集タグにマップするためのコンテキスト・パラメータ定義を示しています。
<context-param> <param-name>csa sales ruleFile</param-name> <param-value>sales_rules.xml</param-value> </context-param> <context-param> <param-name>csa distribution ruleFile</param-name> <param-value>hr_rules.xml</param-value> </context-param>
次の各項では、Oracle Enterprise Managerでのソフトウェア・ライブラリの設定および構成の方法について説明します。
ソフトウェア・ライブラリは、すべてのOracle Management Server（OMS）からアクセス可能なディレクトリに置く必要があります。OMSが1つのみの場合は、ローカルのディレクトリに置くことができます。複数のOMSがある環境では、すべてのOracle Management Serverからアクセス可能なNetwork File Server上のディレクトリを使用します。全コンポーネントのバイナリ・データが保存されるファイルを格納するのに十分な領域が、共有記憶域にあることを確認してください。
オペレーティング・システム・コンポーネントを作成する場合は、LinuxインストールのすべてのRPMが含まれるTARファイルがソフトウェア・ライブラリに格納されます。Oracleデータベース・コンポーネントを作成する場合は、参照Oracleホーム・ディレクトリからの全ファイルを含むTARファイル、またはインストール可能なメディアからの内容が、ソフトウェア・ライブラリに格納されます。
共有記憶域は、NFSマウント・ポイントを介して、その環境のすべてのOracle Management Serverからアクセス可能であることを確認してください。
プロビジョニング・アプリケーションのグラフィカル・ユーザー・インタフェースでは、コンポーネント、ディレクティブおよびイメージの様々なタブが表示されます。これらのタブにアクセスできるかどうかは、割り当てられている権限によって決まります。たとえば、スーパーユーザー権限を持つ場合は「管理」タブにアクセスできます。「管理」タブには複数のセクションがあり、その環境の様々な要素の構成に使用できます。
ソフトウェア・ライブラリを構成するには、次の手順に従います。
ソフトウェア・ライブラリを削除するには、「管理」タブからソフトウェア・ライブラリを選択して「削除」をクリックします。
ソフトウェア・ライブラリのコンポーネントを削除するには、ソフトウェア・ライブラリからコンポーネントを選択して「削除」を選択します。これにより、コンポーネントが削除されます。削除したコンポーネントをファイルシステムから完全にクリーンアップするには、次のコマンドを実行する必要があります。
<OMS HOME>/bin/purgeDeploymentLibrary <conn string> <username> <password> [-job <oms_host>]
このコマンドのオプションは次のとおりです。
<conn string>の書式はjdbc:oracle:thin:@dbhost:dbport:sidです。dbhost、dbportおよびsidは、適切な値に置き換える必要があります。
<username>はリポジトリのユーザー名です。
<password>はリポジトリのパスワードです。
[-job <oms_host>]はオプションです。使用すると、ジョブが発行されます（スケジュールは即時）。Enterprise Managerコンソールの「ジョブ」ページにナビゲートすると、ジョブのステータスを確認できます。
<oms_host>はOMSのホスト名です。
権限委譲プロバイダとは、別のユーザーの権限を使用してアクティビティを実行することをログイン・ユーザーに許可するプログラムのことです。通常、特定のユーザーに付与される権限は、集中管理されます。
Enterprise Managerの優先資格証明を使用すると、次の2つのタイプの権限委譲プロバイダを使用できます。
sudoの場合、許可されているユーザーは、sudoユーザー管理ファイル（sudoers）で指定されているsuperユーザーまたは他のユーザーとしてコマンドを実行できます。コマンド起動元のユーザーがrootである、またはターゲット・ユーザーがコマンド起動元のユーザーと同じ場合は、パスワードが不要です。そうでない場合はデフォルト時、ユーザーはパスワードを使用して自分自身の認証を実行する必要があります。
superの場合、ユーザーに権限が付与されているかどうかは、/etc/sudoersファイルをチェックして判断されます。ユーザーが認証されると、タイムスタンプが更新され、該当ユーザーはパスワードなしで短期間（sudoersファイル内で上書きされないかぎり5分間）sudoを使用することができます。
Symark PowerBrokerの場合、UNIXのシステム管理者は、root（または他の重要なアカウント）として特定のプログラムを他のユーザーが実行できる環境を指定できます。そのため、ユーザー・アカウントの追加やライン・プリンタ・キューの固定といったアクションの担当を、rootのパスワードを公開することなく、適切な要員に安全に割り当てることができます。その結果、rootの権限全体を、データベースやファイルの権限の変更、ディスクの消去といった誤用や乱用から保護することができます。
Symark PowerBrokerは、一般的なシステム管理タスクを実行する既存のプログラムや、その独自のユーティリティ・セットにアクセスすることができます。Symark PowerBroker上で動作するように開発されているユーティリティでは、パスワード、アカウント、バックアップ、ライン・プリンタ、ファイルの所有権や削除、再起動、ユーザーのログアウト、ユーザー・プログラムの中断、どのユーザーがどこからどこにログインが許可されているかのチェックなどを管理することができます。また、TCP/IP、ロード・バランサ、cron、NIS、NFS、FTP、rlogin、アカウンティング・サブシステムの管理も提供できます。ユーザーは、制限付きのシェルやエディタを使用し、rootとして特定のプログラムやファイルにアクセスすることができます。
sudoおよびPowerBrokerの詳細は、各製品のドキュメントを参照してください。
Enterprise Managerのコマンドライン・インタフェース（EM CLI）を使用すると、ユーザーはホストの権限委譲プロバイダ・プロパティの設定/編集を実行できます。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。設定および構成の詳細は、権限委譲プロバイダに関するドキュメントを参照してください。
権限委譲設定は、EM CLIコマンドライン・インタフェースのcreate_privilege_delegation_setting動詞により作成できます。
EM CLIのcreate_privilege_delegation_setting動詞を使用すると、sudo権限委譲設定を作成できます。明示的な構文および例については、EM CLIのコマンドライン・ヘルプまたは『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。
EM CLIを使用して権限委譲設定を設定する際は、次の変数を使用できます。変数では大文字と小文字が区別されます。
| 変数 | 定義 |
|---|---|
|
%PASSWORD% |
コマンドを実行するユーザーのパスワード |
|
%RUNAS% |
コマンドを実行するユーザー |
|
%USERNAME% |
コマンドを実行するユーザーの名前 |
|
%command% |
sudoコマンド |
emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_type=SUDO -settings="SETTINGS:<すべてのオプションとともに使用するコマンド>"
次の例は、EM CLIを使用してsudo設定を作成する方法を示しています。この場合、sudoは/opt/sudo/binにインストールされています。
>emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_ type=SUDO -settings="SETTINGS:/opt/sudo/bin/sudo -S -u %RUNAS% %command%"
EM CLIのcreate_privilege_delegation_setting動詞を使用すると、PowerBroker権限委譲設定を作成できます。
EM CLIを使用して権限委譲設定を設定する際は、次の変数を使用できます。変数では大文字と小文字が区別されます。
| 変数 | 定義 |
|---|---|
|
%PASSWORD% |
コマンドを実行するユーザーのパスワード |
|
%RUNAS% |
コマンドを実行するユーザー |
|
%USERNAME% |
コマンドを実行するユーザーの名前 |
|
%command% |
sudoコマンド |
>emcli create_privilege_delegation_setting
-setting_name=powerbroker_setting_1 -setting_type=POWERBROKER -settings="SETTINGS:<すべてのオプションとともに使用するコマンド>;
[PASSWORD_PROMPT_STRING,<PowerBrokerのパスワード・プロンプト>]"
./emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_ type=SUDO -settings="SETTINGS: /opt/powerbroker/bin/pbrun -u %RUNAS% %command%"
権限委譲設定は、作成し終わったら、選択したターゲットに適用する必要があります。権限委譲設定の作成プロセスの場合と同様に、権限委譲設定はEM CLIを使用して、指定したターゲットに適用します。この設定は、1つまたは複数のホスト、あるいはコンポジット（グループ）ターゲット（グループには、ホスト・ターゲットが1つ以上含まれていること）に適用できます。
EM CLIのapply_privilege_delegation_setting動詞を使用すると、権限委譲設定をホスト・ターゲットに適用できます。
emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=host -target_names="host1;host2;...""
-input_file="FILE:hosts.txt" -force="yes/no
権限委譲プロパティを多数のホストに適用する場合は、次の例のように、-target_namesオプションのかわりに-input_fileオプションを使用して、すべてのホストが含まれるファイルを指定することができます。
./emcli apply_privilege_delegation_setting -setting_name=<setting name>
-target_type=host -input_file="FILE: /mydirectory/file.txt" -force=yes
EM CLIのapply_privilege_delegation_setting動詞を使用すると、権限委譲設定をコンポジット（グループ）ターゲットに適用できます。
emcli apply_privilege_delegation_setting -setting_name=<設定名> -target_type=composite -target_names="group" -force="yes/no"
./emcli apply_privilege_delegation_setting -setting_name=<setting name>
-target_type=composite -input_file="FILE: /mydirectory/file.txt" -force=yes
ホスト・ターゲットに対する権限委譲設定の適用に成功したら、EM CLIまたはGrid Controlコンソールを使用して、ホスト・ターゲットの優先資格証明を設定できます。
管理者は、ステータスが無効な新しい権限委譲設定を作成し、それをターゲットに適用すると、権限委譲設定を無効にすることができます。この無効な設定は、任意の権限委譲プロバイダ（sudo/PowerBroker）に適用できます。これにより、権限委譲設定をホストから削除できます。
./emcli create_privilege_delegation_setting -setting_name= disabled_setting -setting_type=SUDO -disabled=yes
./emcli apply_privilege_delegation_setting -setting_name= disabled_setting
-target_type=host -target_names="host1;host2;..." -force=yes
Enterprise Managerで使用する信頼ベースのモデルでは、高度の粒度で職責を指定できます。管理者は、sudoまたはpbrunの構成エントリを設定し、Enterprise Managerの特定機能の権限をそのOSユーザーに割り当てることができます。管理エージェントには、nmosudoという新しい実行可能ファイルが導入されています。管理者は、sudo/pbrunを構成することにより、権限の低いユーザーが権限の高いユーザーとしてnmosudoを実行できないようにすることができます。
次の例で、管理者がユーザーjoeに任意のEnterprise Managerジョブをユーザーoracleとして実行させる場合、/etc/sudoersファイル内の対応するエントリは次のようになります。
(JOB_USERS) ALL : (RUNAS_USERS) AGENT_HOME /bin/nmosudo *
ここで、joeはJOB_BACKUP_USERSリストの中、oracleはRUNAS_USERSリストの中にあります。
Enterprise Managerにより、実行可能ファイルnmosudoは、OMSからエージェントを介したリモート操作実行要求のみを受け取ることが保証されます。nmosudoは、要求がエージェントからのものであることを検証できないと、該当するリモート操作を実行しません。そのため、前述の例で示したように、ユーザーjoeがnmosudoをコマンドラインから直接起動し、ユーザーoracleとしてPerlスクリプトを実行することはできません。
|
 Copyright © 2003, 2009 Oracle Corporation. All Rights Reserved. |
|