| Oracle® Enterprise Manager Cloud Control拡張プログラマーズ・ガイド 13cリリース2 E92081-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つの項目を返すことができます。
3つの項目の導出に使用されるロジックを含むSELECT文を作成および実行します。
返される各行には、アソシエーション・タイプ、ソースおよび宛先の列が含まれ、存在する必要のあるアソシエーションを表します。
エンタープライズ構成管理のスナップショット・タイプに対する導出ロジックを登録します。
すべてのスナップショットの収集後に、登録されたロジックが呼び出されます。ロジックへの入力は、データが収集されるターゲットのGUIDです。
ターゲットTのスナップショットSのアソシエーション導出ロジックが実行されると、導出されたアソシエーションは、ターゲットTのスナップショットSについて以前に導出されたアソシエーションを置き換えます。たとえば、アソシエーションA1およびA2が昨日収集され、本日はA1のみ収集される場合、A2は実際上削除されます。
アソシエーション・フレームワークの強化には、構成データとしてのアソシエーションの処理が含まれます。変更追跡や保存されたスナップショットなどのエンタープライズ構成管理機能は、アソシエーションおよび従来の構成データに適用されるようになりました。アソシエーションは、ソースと宛先のターゲット・コンポーネントに加えて、ターゲットGUIDを指定できるようになりました。
Enterprise Managerには、ほとんどのプラグイン開発者のニーズを満たすアソシエーション・タイプの共通セットが用意されています。プラグイン開発者はこれらのアソシエーション・タイプについてよく理解して使用する(該当する場合)ことをお薦めします。また、インテグレータおよびドキュメントの表を、アソシエーション・タイプおよびすべてのアソシエーション・タイプの使用状況(allowed_pairs)が記載されているドキュメントへのリンクで更新することをお薦めします。
図5-1に、コア・アソシエーション・タイプの階層を示します。
図5-1 コア・アソシエーション・タイプの階層
プラグイン開発者は、導出されたアソシエーションについて、次の手順に従う必要があります。
所有する管理対象エンティティ(ME)に対して表す必要のあるすべてのアソシエーションを識別します。
一般に、これには所有するMEと他の任意のME間の包含または依存のアソシエーションが含まれます。識別されたアソシエーションの種類ごとに、関連するMEタイプの所有者と協力して、そのタイプのアソシエーション・インスタンスを最新に保つ責任を持つ担当者を決定することが必要な場合があります。一部のアソシエーション(特に、hosted_byとmanaged_by)は、Enterprise Managerによって自動的に保守されるため、これらに対してアソシエーション導出ルールを使用する必要はありません。
Enterprise Managerに付属の即時利用可能なアソシエーション・タイプのセットについて理解し、最も適切なタイプを使用します。
詳細は、「即時利用可能なアソシエーション・タイプについて」を参照してください。
正しいアソシエーションを返し、許容できる状態で実行する問合せを指定します。
必要な構成データが収集されていない場合は、許容できるパフォーマンスを保証するような収集を追加する必要もあります。ルールでは、必要な場合に評価がトリガーされるように、ルール問合せのベースとなる構成表を特定する必要があります。
アソシエーション導出ルールを使用して、管理リポジトリに存在する構成データに基づいて、存在するアソシエーションを(宣言的に)記述していることを確認します。
導出ルールの評価は頻繁になる場合があるため、低パフォーマンスのルール問合せは問題となる可能性があります。ルールの作成者は、必要な索引が存在することを確認し、各トリガーに対して生成された特定の問合せに基づいて問合せのパフォーマンスをテストする必要があります。
具体的には、各トリガーは異なる問合せの実行の原因となるため、トリガーごとにルール問合せのテストを実行する必要があります。ルール問合せが値を返す方法は、トリガーに応じて特定のターゲット・GUIDにバインドされていることに注意してください。
これらのバインドを使用する索引が必要です。さらに、問合せは、外部から問合せへのバインディングのプッシュを妨げない方法で記述する必要があります。
複数のルールで同じアソシエーションを導出できますが、通常はこのようなオーバーラップ・ルールの作成を回避することをお薦めします。ここでは、アソシエーションが複数のルールによって導出された場合に何が起きるかについて説明し、これを回避するタイミングと方法に関する提案を示します。
複数のルールが同じアソシエーションを導出する場合、そのアソシエーションは各ルールによって導出されなくなるまで存在し続けます。これが目的の動作である場合があります。たとえば、2つのアプリケーション・ターゲット・タイプがそれぞれ実行されているOracle WebLogic Serverとアクセスするデータベースの両方を認識しているとします。この認識に基づいて、それぞれにOracle WebLogic Serverとデータベース間のアソシエーションを導出する方法があります。どちらかのルールがアソシエーションを導出すると、そのアソシエーションが現実に存在します。両方のルールがアソシエーションを導出しなくなった場合にのみ、アソシエーションが存在しなくなったことが保証されます。
"いずれかのルールが導出した場合は存在する"というセマンティクスは、意図したものでないことがあります。データベースとOracleホーム間のinstalled_onアソシエーションに対して定義できる2つのルールについて考えます。どちらも同じデータにアクセスしますが、一方はOracleホームに対するプロパティ変更によってトリガーされ、もう一方はデータベースに対する変更によってトリガーされます。いずれかのルールが関係がなくなったと判断するとすぐに、アソシエーションは削除される必要があります。このような場合、2つのトリガーを持つ単一のルールを使用します。
このような場合に1つのルールのみ作成するように注意しなかったとします。アソシエーションはすぐに削除されるため、この誤りは重大ではないと考える可能性もあります。しかしそうではなく、不要なアソシエーションが無限に存在する可能性があります。前述の例で、2つのルールを使用してアソシエーションが導出された場合に、データベースをアップグレードしてOracleHomeプロパティを変更します。古いOracleホームとのアソシエーションは削除される必要がありますが、もう一方のルールが起動されるまで削除は行われません。ただし、Oracleホーム・ターゲットについては何も変更されていないため、そのルールはトリガーされず、アソシエーションが残ります。実際に、1つのターゲットのみ変更され、他のターゲットは長期にわたって変更されないことがよくあります。一般的なルールとして、表の特定のセットからのデータに基づいたアソシエーションは複数のトリガーを持つ単一のルールを使用して導出する必要があります。
アソシエーションが存在すると断定する別の理由がないかぎり、1つのルールのみを使用します。このような場合、導出ルールによって返されるアソシエーションを分解する必要があります。これを記述する別の方法は、これらのアソシエーションに対して、すべてのルール問合せで返されるすべての行のセットで重複を指定しないことです。アソシエーションは、ソース、宛先およびアソシエーション・タイプで識別されます。この3つの値の組合せは一意である必要があります。
ここでは、最もよくある3つの質問に回答します。
ほとんどの場合、問合せとトリガーはCM$ビューを使用して構成(エンタープライズ構成管理)表を参照します。他の表を参照する場合およびそのデータがエンタープライズ構成管理表の変更とは関係なく変更されることがある場合、アソシエーションは必要なときに更新されないことがあります。表に対する変更がルール評価をトリガーする必要があるエンタープライズ構成管理以外の表を参照するユースケースがある場合は、Oracle担当者に連絡してください。
もう1つの考慮事項は、表が存在するコンポーネントです。ルールで参照される表がEnterprise Manager EDKの一部でない場合、プラグインではその表のプラグインに対する依存関係を考慮する必要があります。たとえば、プラグイン依存性メカニズムを使用して、参照するオブジェクトが管理リポジトリ内にすでに存在していることを確認する必要があります。
ターゲット・プロパティは構成データとして扱われ、各ターゲット・タイプに移入されるエンタープライズ構成管理スナップショット表があります。この表のデータを使用する際には注意する必要があります。
多くのターゲット・プロパティは検出時に設定され、決して変更されません。
名前/値のペア・データの問合せは扱いにくい場合があり、データがより構造化されている他の表の問合せより時間がかかることがあります。
ターゲット・プロパティ表とエンタープライズ構成管理スナップショット表の両方のデータを使用可能な場合は、後者を使用する必要があります。
構成データのコレクションを追加する必要がある場合は、ターゲット・プロパティ表の新しい行としてではなく、エンタープライズ構成管理表でそれを行う必要があります。
一般に、ターゲット・プロパティの使用は避ける必要があり、データは標準のECMメカニズムを使用して収集およびモデル化する必要があります。
しかし、追加できるエンタープライズ構成管理の収集がターゲットにないなどの場合、ルールでターゲット・プロパティの参照が必要になることがあります。このようなターゲットへのアソシエーションを作成する場合は、それを識別する方法が必要です(たとえば、ルールはそのターゲット・プロパティを参照する必要があります)。
ターゲット・プロパティを使用する必要がある場合は、ルール問合せでMGMT_TARGET_PROPERTIESを参照します。ビューが必要な結合をすでに実行している場合は、ルール問合せでMGMT$TARGET_PROPERTIESを参照することもできます。
これは、オーバーラップ・アソシエーションの別の例です(詳細は、「オーバーラップ・アソシエーションについて」を参照)。たとえば、ターゲットT1とT2間のアソシエーションを検出する検出ロジックに加えて、同じアソシエーションを導出するルールがある場合があります。同じアソシエーションを作成するために2つのロジック・セットを作成しないことをお薦めします。この場合は、次のことが推奨されます。
アソシエーションが変化することがあるため導出ルールが必要な場合は、導出ルールのみを記述します。
ソースまたは宛先が削除されるまで検出されたアソシエーションが変化しない場合は、アソシエーションの検出で構わず、より効率的である可能性もあります。
2つのロジック・セットを作成して同じアソシエーションを作成する場合は(検出ロジックと導出ルール)、検出されたアソシエーションが残り、導出ロジックはそのアソシエーションの存在もアサートします。後でルール評価でアソシエーションが存在しなくなったと判断された場合、ルールのアサーションは削除されますが、アソシエーションは検出されたアソシエーションを手動で削除するまで存在し続けます。
