| Oracle® Enterprise Manager Cloud Control拡張プログラマーズ・ガイド 13c リリース1 F11803-01 |
|
 前 |
 次 |
ITインフラストラクチャを効率的に管理するには、ITエンティティ間の関係を把握する必要があります。ITIL (Information Technology Infrastructure Library)で説明されているようなベスト・プラクティスは、このような関係の取得と使用に依存します。Enterprise Manager Cloud Controlは、サポートされるこの種の関係を拡張し、これらの関係を保守できる宣言的なメカニズムを追加しています。また、システム内のエンティティのメンバーシップを関係に基づいて決定します。正確な関係に基づいて、各種Enterprise Managerアプリケーションおよびコンポーネントでは、次のような顧客の利用をサポートできます。
依存性分析。
たとえば、ホストのシャットダウンの(アプリケーションとインフラストラクチャに対する)影響を理解します。
トポロジ・ビューア。
変更管理。
たとえば、テストから本番インスタンスまでなど、クローン・データベースのソースを追跡するため。
エンドツーエンドのパフォーマンス分析。この分析では、問題を分析して分離するためにアプリケーション・コンポーネント間の相互依存性を把握する必要があります。
VMリソースが割り当てられる方法における変更など、関係の変更トラッキング。
この章では次の内容について説明します。
Enterprise Managerでは、関係の概念は、内部的にアソシエーションと呼ばれます。アソシエーション(アソシエーション・インスタンス)は、2つの管理対象エンティティ間の関係を表し、3つの値、すなわちソース、宛先およびアソシエーション・タイプを指定します。たとえば、"database1 exposed_by listener1"では、database1がソース、listener1が宛先、"exposed_by"がアソシエーション・タイプです。
プラグイン開発者が、管理対象エンティティ・タイプに適用されるアソシエーション・タイプを定義し、正しいアソシエーション(アソシエーション・インスタンス)が存在することを検証します。
ここでは、アソシエーション・タイプを定義する簡潔で宣言的な手段を提供するアソシエーション導出ルールについて説明します。アソシエーション導出(アソシエーションの有無が収集されたデータから導出されるため、このように呼ばれます)は、開発者がターゲットから収集されたデータに基づいてアソシエーション・インスタンスを作成および削除できるメカニズムです。
アソシエーション導出メカニズムでは、アソシエーションと収集された構成データの整合性を保ち、(アクセスできるデータが少ないエージェント・ロジックによるのではなく)すべての既知のデータに基づいてアソシエーションを集中的に決定できます。
このロジックは、ソース管理対象エンティティのグローバル一意識別子(GUID)、アソシエーション・タイプおよび宛先管理対象エンティティGUIDを指定するトリプル形式でアソシエーション・インスタンスのセットを導出します。たとえば、oracle_listenerタイプのターゲットのアソシエーション導出ロジックは、リスナーとリスニング対象の各データベース間のアソシエーションを表す3つの項目を返すことができます。
トリプルの導出に使用するロジックを含むSELECT文を作成して実行します。
返された各行には、アソシエーション・タイプ、ソースおよび宛先の列が含まれ、存在するアソシエーションを表します。
エンタープライズ構成管理のスナップショット・タイプに対する導出ロジックを登録します。
すべてのスナップショットの収集後、登録したロジックが起動されます。ロジックへの入力は、データが収集されたターゲットのGUIDです。
ターゲットTのスナップショットSに対するアソシエーション導出ロジックが実行されると、導出されたアソシエーションで、ターゲットTのスナップショットSに対する以前に導出されたアソシエーションが置換されます。たとえば、アソシエーションA1およびA2が昨日収集され、本日はA1のみ収集される場合、A2は実際上削除されます。
アソシエーション・フレームワーク拡張機能には、アソシエーションを構成データとして処理することが含まれています。変更トラッキングや保存済スナップショットなどのエンタープライズ構成管理の機能は、アソシエーションおよび従来の構成データに適用されるようになりました。現在、アソシエーションでは、ソースおよび宛先のターゲット・コンポーネントの他にターゲットGUIDも指定できます。
Enterprise Managerには、ほとんどのプラグイン開発者のニーズを満たすアソシエーション・タイプの共通セットが用意されています。プラグイン開発者はこれらのアソシエーション・タイプについてよく理解して使用する(該当する場合)ことをお薦めします。また、インテグレータおよびドキュメントの表を、アソシエーション・タイプおよびすべてのアソシエーション・タイプの使用状況(allowed_pairs)が記載されているドキュメントへのリンクで更新することをお薦めします。
図5-1に、コア・アソシエーション・タイプの階層を示します。
プラグイン開発者は、導出されたアソシエーションに関して次の手順を実行します。
所有する管理対象エンティティ(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ホームとのアソシエーションは削除される必要がありますが、もう一方のルールが起動されるまで削除は行われません。しかし、Oracleホーム・ターゲットに関して何も変更されなかったため、ルールはトリガーされず、アソシエーションは残ります。確かに、一方のターゲットのみが変更され、他方のターゲットは長期間変更されないままであることはよくあります。一般的なルールとして、表の特定のセットからのデータに基づいたアソシエーションは複数のトリガーを持つ単一のルールを使用して導出する必要があります。
アソシエーションが存在すると断定する別の理由がないかぎり、1つのルールのみを使用します。このような場合、導出ルールによって返されるアソシエーションは切り離す必要があります。これを別の言い方をすると、これらのアソシエーションの場合、すべてのルール問合せによって返されるすべての行のセットで重複しない必要があります。アソシエーションはソース、宛先およびアソシエーション・タイプによって特定されます。この3つの値の組合せは一意である必要があります。
この項では、最もよくある質問のうち、次の3つを説明します。
ほとんどの場合、問合せとトリガーはCM$ビューを使用して構成(エンタープライズ構成管理)表を参照します。他の表を参照する場合およびそのデータがエンタープライズ構成管理表の変更とは関係なく変更されることがある場合、アソシエーションは必要なときに更新されないことがあります。表に対する変更がルール評価をトリガーする必要があるエンタープライズ構成管理以外の表を参照するユースケースがある場合は、Oracle担当者に連絡してください。
もう1つの考慮事項は、表が存在するコンポーネントです。ルールで参照される表がEnterprise Manager EDKの一部でない場合、プラグインではその表のプラグインに対する依存関係を考慮する必要があります。たとえば、プラグイン依存性メカニズムを使用して、参照するオブジェクトが管理リポジトリ内にすでに存在していることを確認する必要があります。
ターゲット・プロパティは構成データとして処理され、ターゲット・タイプごとに移入されるエンタープライズ構成管理スナップショット表があります。この表のデータを使用する場合、注意する必要があります。
多くのターゲット・プロパティは、検出時に設定され、変更できません。
名前/値ペア・データの問合せは扱いにくく、データがさらに構造化されている他の表に対する問合せよりも時間がかかる可能性があります。
ターゲット・プロパティ表とエンタープライズ構成管理スナップショット表の両方からデータが使用できる場合は、後者を使用します。
構成データの収集を追加する必要がある場合は、ターゲット・プロパティ表の新しい行としてではなく、エンタープライズ構成管理表に追加します。
一般に、ターゲット・プロパティの使用は避け、標準のECMメカニズムを使用してデータを収集およびモデル化します。
しかし、追加できるエンタープライズ構成管理の収集がターゲットにないなどの場合、ルールでターゲット・プロパティの参照が必要になることがあります。そのようなターゲットに対するアソシエーションを作成する場合は、それを特定する方法が必要です(たとえば、ルールでそのターゲット・プロパティを参照する必要があります)。
ターゲット・プロパティを使用する必要がある場合は、ルール問合せでMGMT_TARGET_PROPERTIESを参照します。また、実行する必要がある結合をビューですでに実行している場合は、ルール問合せでMGMT$TARGET_PROPERTIESを参照することもできます。
これは、オーバーラップ・アソシエーション(詳細は、5.4項「オーバーラップ・アソシエーションについて」を参照)のもう1つの例です。たとえば、ターゲットT1とT2間のアソシエーションを検出する検出ロジックに加えて、同じアソシエーションを導出するルールがある場合があります。同じアソシエーションを作成する2組のロジックを記述しないことをお薦めします。この場合は、次のようにすることをお薦めします。
アソシエーションが変化することがあるため導出ルールが必要な場合は、導出ルールのみを記述します。
ソースまたは宛先が削除されるまで検出されたアソシエーションが変化しない場合は、アソシエーションの検出で構わず、より効率的である可能性もあります。
同じアソシエーションを作成するロジックを2組(検出ロジックと導出ルール)記述すると、検出されたアソシエーションが残り、導出ロジックもそのアソシエーションの存在を断定します。その後、アソシエーションがもう存在しないとルール評価が判断した場合、ルールの断定は削除されますが、検出されたアサーションを手動で削除するまでアサーションは存在し続けます。
