BMC Communities Banner

Loose Coupling

7 Posts tagged with the cmdbf tag
vwiles
-by Van Wiles, Technical Marketing

 

Here are some reasons why a federation of MDRs implementing the CMDBf specification still needs a “Single Source of Truth” and how to implement it…

 

For many years, BMC has been promoting a federated CMDB approach that features a centralized repository of configuration information, providing federated access to extended information from management data repositories (MDRs).  I would like to refer to this centralized repository as a “configuration directory” since this more clearly identifies its purpose.

 

Standards are emerging that enable multiple MDRs to form a CMS (Configuration Management System, a collection of MDRs with discovery, data management and human interfaces).  I have worked on one such effort, the CMDB Federation specification that is now being finalized by the CMDBf workgroup in the DMTF.

 

The question must be asked – is a configuration directory still necessary once these standards have reached viability?  There are some very good arguments to be made for NOT maintaining a centralized repository such as a recent blog by Glenn O’Donnell (http://blogs.forrester.com/it_infrastructure/2009/04/is-a-cmdb-even-possible.html), but I have some practical concerns with a purely federated approach.  There are also good reasons to consider certain MDRs as “master” for the classes of information they provide, so I think Glenn makes some very good points that are consistent with our approach.

 

I believe that for the foreseeable future, a CMS still requires a configuration directory for a few important reasons.

 

Relationships

 

Even though MDRs may maintain more accurate, complete, and up-to-date information about certain configuration items, the information about relationships to other configuration items may not be available in the same MDR.  Maintaining these relationships across MDRs without a configuration directory will present problems for scalability and data integrity.  Every relationship must have two endpoints, and the identity of these endpoints must be persistent and unique.  This CAN be accomplished without a configuration directory, but is logistically difficult to maintain potentially many cross-repository references.

 

Normalization and Reconciliation

 

Multiple MDRs may have information about the same class of configuration items.  Normalization and reconciliation of this information requires careful planning and in some cases, human intervention.  Perhaps this process can be embedded into rules to enable normalization and reconciliation on-the-fly, but this makes many risky assumptions about accuracy and scalability that are un-proven in a large scale implementation.

 

Registration and Query

 

Without a configuration directory, configuration information must be gathered in real time by either a sequence of queries to each MDR, or by querying a federating MDR that delegates the query and aggregates the result.  In practical terms, any large implementation would probably cache the results of these queries and attempt to minimize large cross-repository queries.  Thus, whether the synchronization of information from multiple repositories is maintained by a caching mechanism or by registration and periodic synchronization, the end result is effectively the same.  This is one reason why the CMDB Federation specification defines a Registration service – not to register MDRs (which would more likely be done in a web service registry), but to register the persistent identity of “items” that form the core configuration directory.

 

Authorization and Change Management

 

Probably the most important reason to maintain a configuration directory is to provide a consistent and reliable source of information for the change and release management processes.  While discovery of the actual configuration items may provide the most accurate and up-to-date information, that does not mean that it represents the authorized configuration.  There may be an error in the configuration that is revealed by discovery.  Without a configuration directory, each MDR would be responsible to maintain the authorized configuration, and provide consistent ways to detect and report differences between the authorized and actual configuration records.

 

Summary

 

To summarize, the use of federated MDRs to report detailed, up-to-date information about configuration items and associated records is a key feature of a Configuration Management System.  The ability to access and exploit this information will be enhanced by the CMDB Federation standard, and hopefully by some standardization of data model mappings in the future.  But the practical implementation of a CMS still requires a federating CMDB that provides persistency, rationalization, and uniform authorized access to a Single Source of Truth about the core configuration items.

 

It is still a recommended best-practice to minimize the scope and level of detail in the configuration directory to those items (and the properties of those items) that are required to support the configuration and change management processes of ITIL.  The CMDB Federation standard (when finalized) will support and enhance this approach.

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink Tags: configuration_management_database, standards, cmdbf, federated_cmdb, best_practices, itil, cmdb_implementation
Alena Hitzemann
-by Van Wiles, Lead Integration Engineer

Continuing explanation (in the context of the CMDB Federation workgroup) of the use of records to model items of similar types.

Since I am clarifying some things today, first I should clarify what I can clarify about CMDBf workgroup activities at DMTF.

 

I can state my opinions about what is going on in the CMDBf workgroup, including giving some insight about what I am thinking in the meetings, but I cannot really say what the workgroup has decided or is considering. Therefore, please note that whatever I say about this workgroup is my personal opinion and is subject to change or different interpretation from other members of the workgroup.

 

OK, disclaimers aside - things have changed slightly since we started the CMDBf workgroup at DMTF (as you would expect unless we are just wasting our time!)

 

In a previous posting about modeling CIM_VirtualComputerSystem I indicated that the best way to expose a sub-classed model in CMDBf is to associate an item with records of each class in the inheritance hierarchy. This would still work (and may suit your purposes), but an MDR is also allowed to return an item with a record that has the properties of the requested recordType even though the recordType has a different name.

 

Ah - let me clarify with an example. Let's assume (contrary to my last post on this subject) that the MDR implementation model

CIM_VirtualComputerSystem as one big record with CIM_ComputerSystem and all other parent-class attributes. The CMDBf client issues a query for items with CIM_ComputerSystem records and certain propertyValue constraints. It is legitimate for the GraphQuery operation to return these items with:

 

  • One CIM_VirtualComputerSystem record (where the client must assume that the MDR considers CIM_VirtualComputerSystem to be a subclass of the requested CIM_ComputerSystem recordType).
  • One CIM_VirtualComputerSystem record and one CIM_ComputerSystem record (thus the client can tell explicitly that this item matches the requested recordType). For efficiency the Query service may choose to factor out the common properties from the CIM_VirtualComputerSystem records that are returned.

 

If I were implementing a CMDBf Query service I would choose the latter approach because the client will not need knowledge of the inheritance model to understand why the operation returned CIM_VirtualComputerSystem in response to its CIM_ComputerSystem query. There is also the possibility that this knowledge could be conveyed in the XML schema or other mechanism, but this places a pretty big burden on clients who don't understand my data model.

One more note on the subject of CIM_VirtualComputerSystem - its usage is apparently being deprecated by CIM (see http://www.dmtf.org/standards/cim/cim_schema_v219/cim_schema_2.19.0Experimental-MOFs.zip) in favor of simply using CIM_ComputerSystem with a CIM_HostedDependency relationship to another CIM_ComputerSystem. What? This is presumably because so many management systems have a hard time distinguishing between virtual and physical systems.

 

There's also an issue of how a Query service interprets a request if the MDR has something like BMC_ComputerSystem when the client asks for CIM_ComputerSystem. The GraphQuery operation may return these items with:

 

  • One CIM_ComputerSystem record (where the Query service maps its BMC data model to CIM), or
  • One CIM_ComputerSystem record and one BMC_ComputerSystem record, so the client gets both perspectives

 

Again I would choose the latter approach, but I can't really factor out any properties from BMC_ComputerSystem because BMC_ComputerSystem is not formally derived from CIM_ComputerSystem and does not have an identical set of properties. It's just another record which the client may choose to use or ignore. If the client just wants CIM_ComputerSystem records, it can use the contentSelector/selectedRecordType to screen out the BMC_ComputerSystem noise.

 

I hope this gives you some more perspective and clarity. Things are a lot more clear for me, but that is mostly because I just cleaned my glasses!

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink Tags: cmdb, open_standards, cmdbf, federation
Alena Hitzemann
-by Van Wiles, Lead Integration Engineer

A possible answer to the question of how to model CIM associations in CMDBf.

Last time I posted a question - to see if we can move toward a resolution on the question about modeling a CIM association using CMDBf relationships. William Vambenepe replied to me on his blog here: http://stage.vambenepe.com/archives/212.

 

Basically his answer can be summarized as: (a) Some authoritative group like the CMDBf workgroup defines a convention for mapping CIM association roles to CMDBf source and target, and/or (b) CMDBf workgroup provides an ontology language that allows records to be related to each other (e.g. RDF/OWL semantics.)

 

While I like his proposal about a naming convention for relationship records (such as CIM_Dependency_from_Antecedent_to_Dependent), it would allow any implementation to model the source/target direction either way. At least it would be definitive about the role of source and target for that relationship. I also like the idea of having an ontology language to describe the record types more thoroughly, but I would not want to force MDRs and consumers to read and understand the ontology in order to use the interface.

 

I guess in a perfect world everyone would model it the same way, so if we said "source is always the first role and target is always the second role" we would at least have a simple match most of the time, and the naming convention would confirm the roles of source and target.

 

Note that an ontology language or some embeded mapping of data models allows an MDR to return records it considers to match your query, even if the record type has a different name. Here's an example.

 

Assume I could have this i1 -r1-> i2 <-r2- i3 graph in a CIMOM where:

  • i1 has a CIM_ComputerSystem record
  • r1 has a CIM_ParticipatingCS_from_Antecedent_to_Dependent” record
  • i2 has a CIM_Cluster record
  • r2 has a CIM_ConcreteDependency_from_Dependent_to_Antecedent” record
  • i3 has a CIM_Organization record

So in English I have an organization which depends on a cluster of computer systems.

 

Now I want to see what computer systems support this organization. I can invert r2 as CIM_ConcreteDependency_from_Antecedent_to_Dependent (vr2) and have this: i1 -r1-> i2 -vr2-> i3. Now I can query i1 to i3 via CIM_Dependency_from_Antecedent_to_Dependent with depthLimit 2 or more and find this graph. Great! But I made a couple of assumptions that the casual observer might not have noticed:

 

  • CIM_Dependency is a superclass of CIM_ConcreteDependency and CIM_ParticipatingCS. We have decided it is OK to match a record type which is considered to be of the same type as the request, even if there is no strict XSD extension model to validate this.
  • We are also considering defining a way (via RDF/OWL) to expose theseclass relationships.
    An MDR could respond with an inverse relationship that satisfies your query, even though this relationship record does not actually exist in that form (really a special case of the previous item).

 

Reversing direction in the underlying data store query could be challenging, but that’s why we hire geniuses (well maybe we need a few more).

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink Tags: federated, cmdbf, configuration_management_database, cmdb, cmdb_implementation, federation, open_standards
Alena Hitzemann
-by Van Wiles, Lead Integration Engineer

How do you model a dependency relationship in a directional metamodel? This question is surprisingly difficult to answer.

First I must apologize for not posting anything for the last two months. I guess I had writer's block. Then again I know some who would prefer to get more meaningful posts less frequently, so at least I can satisfy the latter part of that preference!

 

So we have this question about how to expose an existing CIM association as a relationship using the CMDBf metamodel. Take CIM_Dependency for example. It seems that about half of all CIM associations are based on CIM_Dependency so answering this question may be generally useful.

 

CMDBf would require the MDR to represent a CIM_Dependency association as a relationship between two items, where the relationship has a record of type CIM_Dependency (and maybe other records too). So far, so good (a no-brainer if you have been following my blog or other CMDBf activities).

 

Now - how do you represent the Antecedent and Dependent properties of this record? The first part of the answer is not too hard - a concatenation of the existing Key properties of each CIM instance will work within a CIM Object Manager. But how do you relate Antecedent and Dependent to CMDBf source and target in the relationship metamodel? That's the tricky part (and very important for an MDR, I might add). In the picture below, can you tell whether Computer System depends on Person (like server depends on administrator) or Person depends on Computer System (like I depend on my laptop)?

If your MDR implementation decides that the Antecedent role maps to the relationship target and my MDR implementation decides that Antecedent maps to source, we won't have interoperability even though we are both using the same data model (!!) In other words, our MDRs may not reconcile or respond to a query with predictable results. A graph traveral from one MDR to the other may get stuck in between.

 

It would be a lot easier if every Association in CIM had a sense of direction, like "depends on" for example; then it would be grammatically obvious (at least to someone who understands English) - source depends on target. I suspect it's a bit late for that wish to come true.

 

There may be a couple of ways out of this modeling conundrum. The CMDBf workgroup at DMTF could define how to map these basic CIM association REFs to source and target and ask every MDR implementation that supports CIM to follow these conventions. That's a real possibility and easy to implement if we catch every MDR before they go with their own instincts.

 

I had another way out, but got lost in the maze. Help! I'm waiting for someone else in the workgroup or in my little blog world to make a better suggestion.

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink Tags: open_standards, cmdbf, configuration_management_database, cmdb_implementation, federation
Alena Hitzemann
-by Van Wiles, Lead Integration Engineer

This entry illustrates ways to model a CIM_VirtualComputerSystem in CMDBf.

Here's an example that will illustrate how multiple records are used to represent a configuration item in CMDBf notation.

 

Let's assume I have an MDR that has information about VMWare guest systems. The question for CMDBf is - how will I expose this information to a federating CMDB or other CMDBf query client? One really good way is to map the information to the Common Information Model (I'll use version 2.16 for this example).

 

CIM_VirtualComputerSystem in CIM 2.16 is a subclass of CIM_ComputerSystem, which is a subclass of CIM_System, which is a subclass of CIM_EnabledLogicalElement, ...

 

In CMDBf parlance, there is an item representing this virtual machine (virtual "lump of plastic and steel" as some in the committee call it.) Then there are records describing this item.

 

Now, I could take all the inherited attributes from those CIM classes and make one big CIM_VirtualComputerSystem record. This would be really easy to process, but it leaves out some important functionality. What if I want to query for all Computer Systems or all Systems in general? This could only be done with a very complex query searching for all possible subclass record types.

 

Alternatively (and recommended), I can model the VM as an item with a CIM_VirtualComputerSystem record plus a CIM_ComputerSystem record, plus a CIM_System record, all the way to a CIM_ManagedElement record. This will allow maximum flexibility for the query client to find exactly the items it needs to query.

 

Now a more difficult question - if I want to use the Registration service of CMDBf and mass-register all my VMs, should I register each item with all these records? That could be a lot of network and parsing overhead. Plus, I wouldn't expect the federating CMDB to replicate and store all this information.

 

Probably the best answer is to associate another record with the item that provides just enough information to identify the item. This record should indicate that the item is a virtual computer system with a certain name and other identifying properties, possibly combining attributes from multiple superclasses. There is no standard schema for these identifying records today - this is an open question for the community to answer. Your feedback is welcome!

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink Tags: cmdbf, federation
Alena Hitzemann
-by Van Wiles, Lead Integration Engineer

The CMDBf 1.0 spec could be implemented in many ways by many parties.

Here are a few ways the CMDBf 1.0 spec (not a standard yet) can be implemented.

 

First - it is important to understand that the spec describes web services. These services can be written and delivered by anyone, not just the vendor of a particular CMDB or MDR. So let's say there are three scenarios (there may be more):

 

1. Each CMDB and MDR vendor produces its own CMDBf services for its own product lines
2. Third-party software vendors produce CMDBf services for popular CMDB and MDR products and market these adapters independently
3. Consulting service providers produce CMDBf services for custom applications to be used with other CMDBf implementations

 

I will guess that these are all viable options and could very well come to market in the reverse order from above (custom implementations first).

 

Second, the spec can be implemented in many ways - "push-mode", "pull-mode" or both, varying levels of query support, varying record types, etc.

 

Now comes a tricky question - can you market these adapters without a common data model, or an exponentially-expanding set of data-mapping objects? The point here is that some maturity will be required before this is really plug-and-play.

 

So, leaving the modeling/mapping question aside for now, let's see how a third-party could produce adapters for a pair of MDR's. I'll start with a picture.

IntegrationBlog1.png

In the picture above, all the CMDBf services and processes are provided by a third-party (call it Lavender Software.) Lavender has adapters for each MDR proprietary interface, plus transformers to register items and relationships from Vendor A to Vendor B CMDB, and a User Interface to query the registered CMDBf Query Services.

 

This picture could change if one or both vendors produce their own CMDBf services and the customer wants to switch. In this case, Lavender Software might provide a way to switch services to another vendor. In this case, you can imagine that it would be much less painful to exchange information between CMDBf services in a common format, at least in the case of registration. Additionally, it would be really helpful to the query UI if items of like-kind had common type-names (like Incident or Computer System for example).

IntegrationBlog2.png

 

In the final picture, vendors A and B have provided XML schemas and registration processes for their services, and a contract integrator has been hired to connect the services. All that is required is for the contractor to use the registered services and provide a query client interface for the customer.

IntegrationBlog3.png

 

Final note: open standards and open source go together like shoes and socks (except that standards smell better with age.) There is an open source project giving some very interesting insight on a CMDBf implementation over SML/CML starting here: http://wiki.eclipse.org/Leveraging_CMDBf. This is part of the Eclipse COSMOS project which is sponsored by some of the original consortium companies. It should be a useful starting point if you are interested in implementing CMDBf.

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink Tags: eclipse_cosmos, cmdbf, open_source, open_standards, sml, federation
Alena Hitzemann
-by Van Wiles, Lead Integration Engineer

What's going on in my year 2008 (I think)...

I haven't posted lately - if you subscribe to this blog, I'm still here!

 

The CMDBf consortium work has wrapped up - I plan to be actively participating in the DMTF committee to support CMDB federation now. I'm working on another post about CMDBf records in the meantime, while the DMTF committee is getting ready to launch.

 

In other areas, I'll be supporting development efforts to integrate with BMC Atrium technology. I expect this technology to expand well beyond CMDB this year, so remember that "BMC Atrium" is not synonymous with "CMDB". As always this will involve a lot of learning for new releases and features. It will also require some leadership as we develop a methodology for validating and certifying interoperability.

 

Anyway - I wish you a safe and prosperous New Year wherever you are!

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink Tags: standards, cmdbf, federated_cmdb, service_oriented_architecture, cmdb
vwiles

vwiles

 Member since: Jul 7, 2005

View vwiles's profile

Actions

Popular Blog Posts