Effective management of IT infrastructure requires knowledge of the relationships between IT entities. Best practices such as those described by ITIL (Information Technology Infrastructure Library) rely on capturing and using such relationships.Enterprise Manager Cloud Control extends the kinds of relationships being supported and adds a declarative mechanism by which these relationships can be maintained. It also determines the membership of entities in a system based on relationships. Based on accurate relationships, various Enterprise Manager applications and components can support customer uses such as:
For example, understanding the impact (to applications and infrastructure) of shutting down a host.
For example, tracking the source of cloned databases such as from test to production instances.
End-to-end performance analysis, in which interdependencies between application components must be known in order to analyze and isolate issues.
Change tracking of relationships, such as changes in the way VM resources are allocated.
This chapter covers the following:
In Enterprise Manager, the concept of a relationship is internally referred to as an association. An association (association instance) represents a relationship between two managed entities and specifies three values, source, destination, and association type. For example, in ”
database1 exposed_by listener1”,
database1 is the source,
listener1 is the destination, and ”
exposed_by” is the association type.
As a plug-in developer, you are responsible for defining those association types that apply to your managed entity types and for verifying that the correct associations (association instances) are present.
This section describes association derivation rules, which provide a concise declarative means of defining association types. Association derivation (so called because the existence of associations is derived from collected data) provides a mechanism by which developers can cause association instances to be created and removed based on data collected from a target.
The association derivation mechanism allows you to keep the association consistent with the collected configuration data and to determine associations centrally based on all known data (instead of being done by agent logic, which has access to less data).
The logic derives a set of association instances in the form of triples that specify the source managed entity globally unique identifier (GUID), association type, and destination managed entity GUID. For instance, the association derivation logic for targets of type oracle_listener could return triples that represent associations between the listener and each database for which it listens.
Create and run a SELECT statement that contains the logic used to derive the triples.
Each returned row contains association type, source, and destination columns and represents an association that should exist.
After every snapshot collection, the registered logic is invoked. Input to the logic is the GUID of the target for which the data was collected.
When the association derivation logic for snapshot S of target T is executed, the derived associations replace the previously derived associations for snapshot S of target T. For example, if associations A1 and A2 were collected yesterday and only A1 is collected today, then A2 is effectively deleted.
Association framework enhancements include the treatment of associations as configuration data. Enterprise Configuration Management features such as change tracking and saved snapshots now apply to associations as well as to traditional configuration data. Associations can now specify source and destination target components, as well as target GUIDs.
Enterprise Manager provides a common set of association types that meets the needs of most plug-in developers. As a plug-in developer, you are encouraged to become familiar with these association types and use them if applicable. Oracle recommends that you update the Table of Integrators and Documents with links to the documents describing your association types and your usage of all association types (allowed_pairs).
Figure 5-1 shows the core association type hierarchy.
As a plug-in developer, you are responsible for the following steps with regard to derived associations:
Identify all associations that need to be represented for any managed entities (MEs) that you own.
This generally includes any containment or dependency associations between an ME you own and any other MEs. For each kind of association identified, you may need to coordinate with the owner of the related ME type to determine who should be responsible for assuring that association instances of that type are kept up to date. Some associations (in particular,
managed_by) are automatically maintained by Enterprise Manager, so association derivation rules should not be used for these.
Understand the set of out-of-box association types that are shipped with Enterprise Manager and ensure the use of the most appropriate type.
For more information, see Section 5.3.1, "About Out-of-Box Association Types".
Provide a query that returns the correct associations and performs acceptably.
If required configuration data is not collected, you must also add such collections to assure acceptable performance. Your rules must identify the configuration tables on which the rule query depends so that the evaluation is triggered when required.
Because the evaluation of derivation rules might be frequent, any poor performance of the rule queries can be problematic. Rule authors must ensure that any needed indexes are present and that they test query performance based on the specific queries that are generated for each trigger.
In particular, testing of the rule query must be done for each trigger because each trigger causes the execution of a different query. Note how rule query return values are bound to a given target GUID depending on your triggers.
It is possible for more than one rule to derive the same association, although Oracle recommends that you avoid creating such overlapping rules. This section describes what happens when an association is derived by multiple rules and includes suggestions on when to avoid this and how.
When more than one rule derives the same association, that association continues to exist until each rule no longer derives it. Sometimes, this is what you want. For example, suppose each of two application target types has knowledge of both the Oracle WebLogic Server on which it runs and the database it accesses. Based on that knowledge, each has a way to derive an association between the Oracle WebLogic Server and the database. If either rule derives the association, that association is real and should exist. Only when both rules no longer derive the association can you be sure that the association no longer exists.
The "exists when any rule derives it" semantics might not be what you intend. Consider two rules that could be defined for the
installed_on association between the database and Oracle home. Both access the same data, but one is triggered by a property change to the Oracle home and the other by a change to the database. As soon as either rule determines the relationship is gone, then the association should be deleted. In such a case, use a single rule with two triggers.
Suppose you did not take care to write only one rule in such cases. You might think that this mistake is not serious because the association will be deleted soon. But this is not so, and the bogus association might exist indefinitely. If in the previous example, the association was derived using two rules, then the database is upgraded and its OracleHome property gets changed. The association with the old Oracle home should be removed, but this will not happen until the other rule is fired. However, nothing about the Oracle Home target has changed, so its rule is not triggered and the association remains. Indeed, it is often the case that only one target is changed and the other remains unchanged for a long period of time. As a general rule, associations based on data from a specific set of tables should be derived using a single rule with multiple triggers.
Unless there are different reasons for asserting an association exists, only use one rule. In such cases, the associations returned by derivation rules should be disjoint. Another way to state this is that for those associations, the set of all rows returned by all rule queries must specify no duplications. An association is identified by source, destination, and association type. This means that the combination of these three values should be unique.
This section addresses three of the most frequently asked questions:
In most cases, your query and triggers will reference configuration (Enterprise Configuration Management) tables using the
CM$ views. If you refer to other tables and if that data might change independently of Enterprise Configuration Management table changes, then the associations might not be updated when required. If you have a use case in which a non Enterprise Configuration Management table is referenced where changes to that table must trigger rule evaluation, contact your Oracle representative.
Another consideration is the component in which the table is located. If the table your rule references is not part of the Enterprise Manager EDK, your plug-in must account for the dependency on that table's plug-in. For example, you must ensure that any object you reference already exists in the Management Repository using a plug-in dependency mechanism.
Target properties are being treated as configuration data and there is an Enterprise Configuration Management snapshot table that is populated for each target type. Some care should be taken in using data from this table:
Many target properties are set at discovery time and never modified.
Querying name/value pair data can be awkward and take longer than queries on other tables where the data is more structured.
If the data is available from both the target properties table and an Enterprise Configuration Management snapshot table, you should use the latter.
If you need to add collection of configuration data, you should do so in an Enterprise Configuration Management table, not as a new row in the target properties table.
In general, the use of target properties should be avoided and data should be collected and modelled using standard ECM mechanisms.
However, a rule might need to refer to target properties if, for example, the target has no Enterprise Configuration Management collections that can be added. If an association to such a target is to be created, there must be some way to identify it (for example, the rule must refer to its target properties).
If you must use target properties, then reference
MGMT_TARGET_PROPERTIES in your rule query. You can also reference
MGMT$TARGET_PROPERTIES in the rule query if the view already performs the join you need to do.
This is another example of overlapping associations (for more information, see Section 5.4, "About Overlapping Associations"). For example, you might have discovery logic that discovers an association between targets T1 and T2, plus a rule that derives the same association. Oracle recommends that you do not write two sets of logic to create the same association. In this case it is suggested that:
If a derivation rule is needed because the association might change, then write the derivation rule.
If the association that is discovered will not change until the source or destination is removed, then discovering the association is fine and might be more efficient.
If you do write two sets of logic to create the same association (discovery logic and derivation rule), then the discovered association will remain and the derivation logic will also assert the existence of that association. If the rule evaluation later determines that the association should no longer exist, the rule's assertion will be removed, but the association will continue to exist unless you manually delete the discovered association.