| Oracle® Enterprise Manager Cloud Control拡張プログラマーズ・ガイド 12c リリース4 (12.1.0.4) B70508-04 |
|
 前 |
 次 |
ITインフラストラクチャを効率的に管理するには、ITエンティティ間の関係を把握する必要があります。ITIL(情報技術基盤ライブラリ)で説明されているようなベスト・プラクティスは、このような関係を取得および使用することに基づいています。Enterprise Manager Cloud Control 12cでは、サポートされている様々な関係を拡張し、これらの関係を保持できる宣言型方式を追加しています。また、システム内のエンティティのメンバーシップを関係に基づいて決定します。正確な関係に基づいて、各種Enterprise Managerアプリケーションおよびコンポーネントでは、次のような顧客の利用をサポートできます。
依存性分析。
たとえば、ホストの停止による(アプリケーションおよびインフラストラクチャに対する)影響を把握するため。
トポロジ・ビューア。
変更管理。
たとえば、テストから本番インスタンスまでなど、クローン・データベースのソースを追跡するため。
エンドツーエンドのパフォーマンス分析。この分析では、問題を分析して分離するためにアプリケーション・コンポーネント間の相互依存性を把握する必要があります。
VMリソースが割り当てられる方法における変更など、関係の変更トラッキング。
この章では次の内容について説明します。
Enterprise Managerでは、関係の概念は、内部的にアソシエーションと呼ばれます。アソシエーション(アソシエーション・インスタンス)は、2つの管理対象エンティティ間の関係を表し、3つの値、すなわちソース、宛先およびアソシエーション・タイプを指定します。たとえば、"database1 exposed_by listener1"では、database1がソース、listener1が宛先、"exposed_by"がアソシエーション・タイプです。
プラグイン開発者が、管理対象エンティティ・タイプに適用されるアソシエーション・タイプを定義し、正しいアソシエーション(アソシエーション・インスタンス)が存在することを検証します。
この項では、アソシエーション・タイプを定義する簡潔かつ宣言的な方法であるアソシエーション導出ルールについて説明します。アソシエーション導出(アソシエーションの有無が収集されたデータから導出されるため、このように呼ばれます)は、開発者がターゲットから収集されたデータに基づいてアソシエーション・インスタンスを作成および削除できるメカニズムです。
アソシエーション導出メカニズムを使用すると、アソシエーションと収集された構成データの一貫性を保ち、すべての既知のデータに基づいて(より少ないデータにアクセスできるエージェント・ロジックによって実行するかわりに)アソシエーションを一元的に決定できます。
アソシエーション導出を使用するには、開発者は一般に次の手順を実行します。
ターゲット構成の収集後に実行するロジックを指定します。
このロジックは、ソース管理対象エンティティGUID、アソシエーション・タイプおよび宛先管理対象エンティティGUIDを指定するトリプル形式でアソシエーション・インスタンスのセットを導出します。たとえば、タイプoracle_listenerのターゲットに対するアソシエーション導出ロジックは、リスナーとリスニングする各データベース間のアソシエーションを表すトリプルを返します。
トリプルの導出に使用するロジックを含むSELECT文を作成して実行します。
返された各行には、アソシエーション・タイプ、ソースおよび宛先の列が含まれ、存在するアソシエーションを表します。
エンタープライズ構成管理のスナップショット・タイプに対する導出ロジックを登録します。
すべてのスナップショットの収集後、登録したロジックが起動されます。ロジックへの入力は、データが収集されたターゲットのGUIDです。
ターゲットTのスナップショットSに対するアソシエーション導出ロジックが実行されると、導出されたアソシエーションで、ターゲットTのスナップショットSに対する以前に導出されたアソシエーションが置換されます。たとえば、昨日アソシエーションA1およびA2が収集され、今日A1のみが収集された場合、A2は事実上削除されます。
Enterprise Manager Cloud Control 12cは、Enterprise Managerコンポーネントによるアソシエーションの使用を拡張し、アソシエーション・フレームワーク全体を強化しています。システム・ステンシルやトポロジ・ビューアを含め、アソシエーションの新しいコンシューマが導入されています。
アソシエーション・フレームワーク拡張機能には、アソシエーションを構成データとして処理することが含まれています。変更トラッキングや保存済スナップショットなどのエンタープライズ構成管理の機能は、アソシエーションおよび従来の構成データに適用されるようになりました。現在、アソシエーションでは、ソースおよび宛先のターゲット・コンポーネントの他にターゲットGUIDも指定できます。
Enterprise Managerには、ほとんどのプラグイン開発者のニーズを満たすアソシエーション・タイプの共通セットが用意されています。プラグイン開発者はこれらのアソシエーション・タイプについてよく理解して使用する(該当する場合)ことをお薦めします。また、インテグレータおよびドキュメントの表を、アソシエーション・タイプおよびすべてのアソシエーション・タイプの使用状況(allowed_pairs)が記載されているドキュメントへのリンクで更新する必要があります。
次の図は、コア・アソシエーション・タイプの階層を示したものです。
プラグイン開発者は、導出されたアソシエーションに関して次の手順を実行します。
所有する管理対象エンティティ(ME)について表す必要があるすべてのアソシエーションを特定します。
一般に、これには、所有するMEとその他のME間の包含または依存のアソシエーションが含まれます。特定されたアソシエーションの種類ごとに、そのタイプのアソシエーション・インスタンスが必ず最新状態に保たれるようにする担当者を決定するために、関連MEタイプの所有者との調整が必要な場合があります。一部のアソシエーション(特にhosted_byおよびmanaged_by)は、Enterprise Managerによって自動的に保持されるため、アソシエーション導出ルールを使用する必要はありません。
Enterprise Managerに同梱されているすぐに使用できるアソシエーション・タイプのセットを理解し、最も適切なタイプの使用を確認します。
詳細は、5.3.1項「すぐに使用できるアソシエーション・タイプについて」を参照してください。
正しいアソシエーションを返し、許容できる状態で実行する問合せを指定します。
必要な構成データが収集されていない場合は、許容できるパフォーマンスを保証するような収集を追加する必要もあります。ルールでは、必要な場合に評価がトリガーされるように、ルール問合せのベースとなる構成表を特定する必要があります。
アソシエーション導出ルールを使用して、リポジトリに存在する構成データに基づいて、存在するアソシエーションを(宣言的に)記述していることを確認します。
ルールは、(ターゲット・プロパティ変更も構成収集として処理される)構成収集によってトリガーされます。
導出ルールの評価は頻繁になる場合があるため、低パフォーマンスのルール問合せは問題となる可能性があります。ルール作成者は、必要な索引が存在すること確認し、トリガーごとに生成される特定の問合せに基づいて問合せパフォーマンスをテストする必要があります。
特に、ルール問合せのテストは、各トリガーによって異なる問合せが実行されるため、トリガーごとに実行する必要があります。ルール問合せが値を返す方法は、トリガーに応じて特定のターゲット・グローバル一意識別子(GUID)にバインドされていることに注意してください。
これらのバインディングを使用する索引が必要です。さらに、問合せは、外部から問合せへのバインディングのプッシュを妨げない方法で記述する必要があります。
複数のルールによって同じアソシエーションを導出することは可能ですが、通常、このようなオーバーラップ・ルールを作成することは避けます。この項では、複数のルールでアソシエーションが導出された場合の処理について説明、これを回避する場合および方法に関する推奨を示します。
複数のルールが同じアソシエーションを導出すると、そのアソシエーションは各ルールが導出しなくなるまで存在し続けます。これが求めるものである場合もあります。たとえば、2つのアプリケーション・ターゲット・タイプがそれぞれ実行されているOracle WebLogic Serverとアクセスするデータベースの両方を認識しているとします。その認識に基づいて、Oracle WebLogic Serverとデータベース間のアソシエーションを導出する方法をそれぞれ持っています。いずれかのルールがアソシエーションを導出した場合、そのアソシエーションは現実に存在します。両方のルールがそのアソシエーションを導出しなくなった場合のみ、アソシエーションは存在しなくなったと考えることができます。
"いずれかのルールが導出した場合は存在する"というセマンティクスは、意図したものでないことがあります。データベースとOracleホーム間のinstalled_onアソシエーションについて定義できる2つのルールを考えてみます。いずれも同じデータにアクセスしますが、一方はOracleホームに対するプロパティ変更によってトリガーされ、他方はデータベースに対する変更によってトリガーされます。いずれかのルールが関係がなくなったと判断するとすぐに、アソシエーションは削除される必要があります。このような場合、2つのトリガーを持つ単一のルールを使用する必要があります。
このような場合に、1つのルールのみを記述するように配慮しなかったとします。結局、アソシエーションはすぐに削除されるため、このミスは深刻ではないと考えるかもしれません。しかし、これがそうではなく、偽のアソシエーションがいつまでも存在する可能性があります。前述の例で、2つのルールを使用してアソシエーションが導出された場合に、データベースをアップグレードしてOracleHomeプロパティを変更します。古いホームとのアソシエーションは削除される必要がありますが、他方のルールが起動されるまで削除されません。しかし、Oracleホーム・ターゲットに関して何も変更されなかったため、ルールはトリガーされず、アソシエーションは残ります。確かに、一方のターゲットのみが変更され、他方のターゲットは長期間変更されないままであることはよくあります。一般的な経験則から、表の特定のセットからのデータに基づいたアソシエーションは複数のトリガーを持つ単一のルールを使用して導出する必要があります。
アソシエーションが存在すると断定する別の理由がないかぎり、1つのルールのみを使用する必要があります。このような場合、導出ルールによって返されるアソシエーションは切り離す必要があります。これを別の言い方をすると、これらのアソシエーションの場合、すべてのルール問合せによって返されるすべての行のセットで重複しない必要があります。アソシエーションはソース、宛先およびアソシエーション・タイプによって特定されます。つまり、これら3つの値の組合せは一意である必要があります。
この項では、最もよくある質問のうち、次の3つを説明します。
ほとんどの場合、問合せでは、CM$ビューを使用して構成(エンタープライズ構成管理)表を参照します。トリガーも同様です。他の表を参照する場合およびそのデータがエンタープライズ構成管理表の変更とは関係なく変更されることがある場合、アソシエーションは必要なときに更新されないことがあります。表に対する変更がルール評価をトリガーする必要があるエンタープライズ構成管理以外の表を参照するユースケースがある場合は、Oracle担当者に連絡してください。
もう1つの考慮事項は、表が存在するコンポーネントです。ルールで参照する表がEnterprise ManagerコアSDKに含まれていない場合、プラグインではその表のプラグインに対する依存性を考慮する必要があります。たとえば、プラグイン依存性メカニズムを使用して、参照するオブジェクトがリポジトリ内にすでに存在していることを確認する必要があります。
ターゲット・プロパティは構成データとして処理され、ターゲット・タイプごとに移入されるエンタープライズ構成管理スナップショット表があります。この表のデータを使用する場合、注意する必要があります。
多くのターゲット・プロパティは、検出時に設定され、変更できません。
名前/値ペア・データの問合せは扱いにくく、データがさらに構造化されている他の表に対する問合せよりも時間がかかる可能性があります。
ターゲット・プロパティ表とエンタープライズ構成管理スナップショット表の両方からデータが使用できる場合は、後者を使用します。
構成データの収集を追加する必要がある場合は、ターゲット・プロパティ表の新しい行としてではなく、エンタープライズ構成管理表に追加します。
一般に、ターゲット・プロパティの使用は避け、標準のECMメカニズムを使用してデータを収集およびモデル化します。
しかし、追加できるエンタープライズ構成管理の収集がターゲットにないなどの場合、ルールでターゲット・プロパティの参照が必要になることがあります。そのようなターゲットに対するアソシエーションを作成する場合は、それを特定する方法が必要です(たとえば、ルールでそのターゲット・プロパティを参照する必要があります)。
ターゲット・プロパティを使用する必要がある場合は、ルール問合せでMGMT_TARGET_PROPERTIESを参照します。また、実行する必要がある結合をビューですでに実行している場合は、ルール問合せでMGMT$TARGET_PROPERTIESを参照することもできます。しかし、トリガーでは、GC$TARGET_PROPERTIESビューをorcl_tp_configスナップショット・タイプに使用する必要があります。
MGMT_TARGET_PROPERTIESは、より効率的であるため問合せで使用しますが、GC$ビューで使用できないプロパティがいくつか含まれることがあります。GC$ビューでのプロパティ変更に基づいたトリガーのみ使用できます。たとえば、Enterprise Managerに正しく登録されたプロパティが含まれるのは、GC$ビューのみです。
これは、オーバーラップ・アソシエーション(詳細は、5.4項「オーバーラップ・アソシエーションについて」を参照)のもう1つの例です。たとえば、ターゲットT1とT2間のアソシエーションを検出する検出ロジックに加えて、同じアソシエーションを導出するルールがある場合があります。同じアソシエーションを作成する2組のロジックを記述しないことをお薦めします。この場合は、次のようにすることをお薦めします。
アソシエーションが変化することがあるため導出ルールが必要な場合は、導出ルールのみを記述します。
ソースまたは宛先が削除されるまで検出されたアソシエーションが変化しない場合は、アソシエーションの検出で構わず、より簡単または効率的である可能性もあります。
同じアソシエーションを作成するロジックを2組(検出ロジックと導出ルール)記述すると、検出されたアソシエーションが残り、導出ロジックもそのアソシエーションの存在を断定します。その後、アソシエーションがもう存在しないとルール評価が判断した場合、ルールの断定は削除されますが、検出されたアサーションを手動で削除するまでアサーションは存在し続けます。
