導出されたアソシエーションの使用方法

5 導出されたアソシエーションの使用方法

ITインフラストラクチャを効率的に管理するには、ITエンティティ間の関係を把握する必要があります。ITIL (Information Technology Infrastructure Library)で説明されているようなベスト・プラクティスは、このような関係の取得と使用に依存します。Enterprise Managerは、サポートされる関係の種類を拡大し、これらの関係を保持できる宣言的メカニズムを追加します。また、システム内のエンティティのメンバーシップを関係に基づいて決定します。正確な関係に基づいて、各種Enterprise Managerアプリケーションおよびコンポーネントでは、次のような顧客の利用をサポートできます。

依存性分析。

たとえば、ホストのシャットダウンの(アプリケーションとインフラストラクチャに対する)影響を理解します。
トポロジ・ビューア。
変更管理。

たとえば、テストから本番インスタンスまでなど、クローン・データベースのソースを追跡するため。
問題を分析および特定するためにアプリケーション・コンポーネント間の相互依存関係を知る必要のあるエンドツーエンドのパフォーマンス分析。
VMリソースの割当て方法の変更など、関係の変更追跡。

この章の内容は次のとおりです。

概要

Enterprise Managerでは、関係の概念は、内部的にアソシエーションと呼ばれます。アソシエーション(アソシエーション・インスタンス)は、2つの管理対象エンティティ間の関係を表し、3つの値、すなわちソース、宛先およびアソシエーション・タイプを指定します。たとえば、"database1 exposed_by listener1"では、database1がソース、listener1が宛先、"exposed_by"がアソシエーション・タイプです。

プラグイン開発者が、管理対象エンティティ・タイプに適用されるアソシエーション・タイプを定義し、正しいアソシエーション(アソシエーション・インスタンス)が存在することを検証します。

Enterprise Managerアソシエーションの概念について

ここでは、アソシエーション・タイプを定義する簡潔で宣言的な手段を提供するアソシエーション導出ルールについて説明します。アソシエーション導出(アソシエーションの有無が収集されたデータから導出されるため、このように呼ばれます)は、開発者がターゲットから収集されたデータに基づいてアソシエーション・インスタンスを作成および削除できるメカニズムです。

アソシエーション導出メカニズムでは、アソシエーションと収集された構成データの整合性を保ち、(アクセスできるデータが少ないエージェント・ロジックによるのではなく)すべての既知のデータに基づいてアソシエーションを集中的に決定できます。

アソシエーション導出の使用方法

アソシエーション導出を使用するには、次の手順を実行します。

ターゲット構成の収集後に実行するロジックを指定します。

このロジックは、ソース管理対象エンティティのグローバル一意識別子(GUID)、アソシエーション・タイプおよび宛先管理対象エンティティGUIDを指定するトリプル形式でアソシエーション・インスタンスのセットを導出します。たとえば、oracle_listenerタイプのターゲットのアソシエーション導出ロジックは、リスナーとリスニング対象の各データベース間のアソシエーションを表す3つの項目を返すことができます。
3つの項目の導出に使用されるロジックを含むSELECT文を作成および実行します。

返される各行には、アソシエーション・タイプ、ソースおよび宛先の列が含まれ、存在する必要のあるアソシエーションを表します。
エンタープライズ構成管理のスナップショット・タイプに対する導出ロジックを登録します。

すべてのスナップショットの収集後に、登録されたロジックが呼び出されます。ロジックへの入力は、データが収集されるターゲットのGUIDです。

ターゲットTのスナップショットSに対するアソシエーション導出ロジックが実行されると、導出されたアソシエーションで、ターゲットTのスナップショットSに対する以前に導出されたアソシエーションが置換されます。たとえば、アソシエーションA1およびA2が昨日収集され、本日はA1のみ収集される場合、A2は実際上削除されます。

アソシエーション導出ルール管理の使用方法

アソシエーション・フレームワークの強化には、構成データとしてのアソシエーションの処理が含まれます。変更追跡や保存されたスナップショットなどのエンタープライズ構成管理機能は、アソシエーションおよび従来の構成データに適用されるようになりました。アソシエーションは、ソースと宛先のターゲット・コンポーネントに加えて、ターゲットGUIDを指定できるようになりました。

Oracle定義のアソシエーション・タイプについて

Enterprise Managerには、ほとんどのプラグイン開発者のニーズを満たすアソシエーション・タイプの共通セットが用意されています。プラグイン開発者はこれらのアソシエーション・タイプについてよく理解して使用する(該当する場合)ことをお薦めします。また、インテグレータおよびドキュメントの表を、アソシエーション・タイプおよびすべてのアソシエーション・タイプの使用状況(allowed_pairs)が記載されているドキュメントへのリンクで更新することをお薦めします。

次の図は、コア・アソシエーション・タイプの階層を示しています。

プラグイン開発者の担当作業の概要

プラグイン開発者は、導出されたアソシエーションについて、次のステップに従う必要があります。

所有する管理対象エンティティ(ME)に対して表す必要のあるすべてのアソシエーションを識別します。

一般に、これには、所有するMEとその他のME間の包含または依存のアソシエーションが含まれます。特定されたアソシエーションの種類ごとに、そのタイプのアソシエーション・インスタンスが必ず最新状態に保たれるようにする担当者を決定するために、関連MEタイプの所有者との調整が必要な場合があります。一部のアソシエーション(特にhosted_byおよびmanaged_by)は、Enterprise Managerによって自動的に保持されるため、アソシエーション導出ルールを使用する必要はありません。
Enterprise Managerに付属の即時利用可能なアソシエーション・タイプのセットについて理解し、最も適切なタイプを使用します。

詳細は、「Oracle定義のアソシエーション・タイプについて」を参照してください。
正しいアソシエーションを返し、許容できる状態で実行する問合せを指定します。

必要な構成データが収集されていない場合は、許容できるパフォーマンスを保証するような収集を追加する必要もあります。ルールでは、必要な場合に評価がトリガーされるように、ルール問合せのベースとなる構成表を特定する必要があります。
アソシエーション導出ルールを使用して、管理リポジトリに存在する構成データに基づいて、存在するアソシエーションを(宣言的に)記述していることを確認します。

ルールは、(ターゲット・プロパティ変更も構成収集として処理される)構成収集によってトリガーされます。

パフォーマンスの維持

導出ルールの評価は頻繁になる場合があるため、低パフォーマンスのルール問合せは問題となる可能性があります。ルール作成者は、必要な索引が存在すること確認し、トリガーごとに生成される特定の問合せに基づいて問合せパフォーマンスをテストする必要があります。

具体的には、各トリガーは異なる問合せの実行の原因となるため、トリガーごとにルール問合せのテストを実行する必要があります。ルール問合せが値を返す方法は、トリガーに応じて特定のターゲット・GUIDにバインドされていることに注意してください。

これらのバインディングを使用する索引が必要です。さらに、問合せは、外部から問合せへのバインディングのプッシュを妨げない方法で記述する必要があります。

オーバーラップ・アソシエーションについて

複数のルールで同じアソシエーションを導出できますが、通常はこのようなオーバーラップ・ルールの作成を回避することをお薦めします。この項では、複数のルールでアソシエーションが導出された場合の処理について説明、これを回避する場合および方法に関する推奨を示します。

ルールによって導出されたアソシエーション間のオーバーラップについて

複数のルールが同じアソシエーションを導出すると、そのアソシエーションは各ルールが導出しなくなるまで存在し続けます。これが求めるものである場合もあります。たとえば、2つのアプリケーション・ターゲット・タイプがそれぞれ実行されているOracle WebLogic Serverとアクセスするデータベースの両方を認識しているとします。その認識に基づいて、Oracle WebLogic Serverとデータベース間のアソシエーションを導出する方法をそれぞれ持っています。いずれかのルールがアソシエーションを導出した場合、そのアソシエーションは現実に存在します。両方のルールがそのアソシエーションを導出しなくなった場合のみ、アソシエーションは存在しなくなったと考えることができます。

"いずれかのルールが導出した場合は存在する"というセマンティクスは、意図したものでないことがあります。データベースとOracleホーム間のinstalled_onアソシエーションについて定義できる2つのルールを考えてみます。いずれも同じデータにアクセスしますが、一方はOracleホームに対するプロパティ変更によってトリガーされ、他方はデータベースに対する変更によってトリガーされます。いずれかのルールが関係がなくなったと判断するとすぐに、アソシエーションは削除される必要があります。このような場合、2つのトリガーを持つ単一のルールを使用します。

このような場合に、1つのルールのみを記述するように配慮しなかったとします。アソシエーションはすぐに削除されるため、この誤りは重大ではないと考える可能性もあります。しかしそうではなく、不要なアソシエーションが無限に存在する可能性があります。前述の例で、2つのルールを使用してアソシエーションが導出された場合に、データベースをアップグレードしてOracleHomeプロパティを変更します。古いOracleホームとのアソシエーションは削除される必要がありますが、もう一方のルールが起動されるまで削除は行われません。しかし、Oracleホーム・ターゲットに関して何も変更されなかったため、ルールはトリガーされず、アソシエーションは残ります。確かに、一方のターゲットのみが変更され、他方のターゲットは長期間変更されないままであることはよくあります。一般的なルールとして、表の特定のセットからのデータに基づいたアソシエーションは複数のトリガーを持つ単一のルールを使用して導出する必要があります。

アソシエーションが存在すると断定する別の理由がないかぎり、1つのルールのみを使用します。このような場合、導出ルールによって返されるアソシエーションは切り離す必要があります。これを別の言い方をすると、これらのアソシエーションの場合、すべてのルール問合せによって返されるすべての行のセットで重複しない必要があります。アソシエーションはソース、宛先およびアソシエーション・タイプによって特定されます。この3つの値の組合せは一意である必要があります。

よくある質問

ここでは、最もよくある3つの質問に回答します。

ルール問合せではどの表を参照できますか。

ほとんどの場合、問合せとトリガーはCM$ビューを使用して構成(エンタープライズ構成管理)表を参照します。他の表を参照する場合およびそのデータがエンタープライズ構成管理表の変更とは関係なく変更されることがある場合、アソシエーションは必要なときに更新されないことがあります。表に対する変更がルール評価をトリガーする必要があるエンタープライズ構成管理以外の表を参照するユースケースがある場合は、Oracle担当者に連絡してください。

もう1つの考慮事項は、表が存在するコンポーネントです。ルールで参照される表がEnterprise Manager EDKの一部でない場合、プラグインではその表のプラグインに対する依存関係を考慮する必要があります。たとえば、プラグイン依存性メカニズムを使用して、参照するオブジェクトが管理リポジトリ内にすでに存在していることを確認する必要があります。

ターゲット・プロパティを使用するときのガイドラインはありますか。

ターゲット・プロパティは構成データとして処理され、ターゲット・タイプごとに移入されるエンタープライズ構成管理スナップショット表があります。この表のデータを使用する場合、注意する必要があります。

多くのターゲット・プロパティは検出時に設定され、決して変更されません。
名前/値のペア・データの問合せは扱いにくい場合があり、データがより構造化されている他の表の問合せより時間がかかることがあります。
- ターゲット・プロパティ表とエンタープライズ構成管理スナップショット表の両方のデータを使用可能な場合は、後者を使用する必要があります。
- 構成データのコレクションを追加する必要がある場合は、ターゲット・プロパティ表の新しい行としてではなく、エンタープライズ構成管理表でそれを行う必要があります。

一般に、ターゲット・プロパティの使用は避ける必要があり、データは標準のECMメカニズムを使用して収集およびモデル化する必要があります。

しかし、追加できるエンタープライズ構成管理の収集がターゲットにないなどの場合、ルールでターゲット・プロパティの参照が必要になることがあります。そのようなターゲットに対するアソシエーションを作成する場合は、それを特定する方法が必要です(たとえば、ルールでそのターゲット・プロパティを参照する必要があります)。

ターゲット・プロパティを使用する必要がある場合は、ルール問合せでMGMT_TARGET_PROPERTIESを参照します。また、実行する必要がある結合をビューですでに実行している場合は、ルール問合せでMGMT$TARGET_PROPERTIESを参照することもできます。

検出されたアソシエーションと導出されたアソシエーションはどのような関係ですか。

これは、オーバーラップ・アソシエーションの別の例です(詳細は、「オーバーラップ・アソシエーションについて」を参照)。たとえば、ターゲットT1とT2間のアソシエーションを検出する検出ロジックに加えて、同じアソシエーションを導出するルールがある場合があります。同じアソシエーションを作成する2組のロジックを記述しないことをお薦めします。この場合は、次のようにすることをお薦めします。

アソシエーションが変化することがあるため導出ルールが必要な場合は、導出ルールのみを記述します。
ソースまたは宛先が削除されるまで検出されたアソシエーションが変化しない場合は、アソシエーションの検出で構わず、より効率的である可能性もあります。

2つのロジック・セットを作成して同じアソシエーションを作成する場合は(検出ロジックと導出ルール)、検出されたアソシエーションが残り、導出ロジックはそのアソシエーションの存在もアサートします。後でルール評価でアソシエーションが存在しなくなったと判断された場合、ルールのアサーションは削除されますが、アソシエーションは検出されたアソシエーションを手動で削除するまで存在し続けます。