Thanks for that, Cardo.
I'd looked in the "BMC Atrium CMDB 7.5.00 Data Modeling Guide", and on page 54 it talks about modeling software and hardware clusters. There is says "To do so, they could use the BMC_Component relationship to connect Computer A, Computer B, and Computer C to a performance measurement CI in the BMC_Cluster class."
Which I took to mean BMC advise using the BMC_Component relationship.
I'm coming to the conclusion that there actually isn't any right or wrong way to do all this. It's important that the relationship goes in the right direction, to allow service impact modelling and reporting. But exactly which relationship type to use doesn't make much difference.
That's interesting, but throws up another question. You're saying that the cluster is the parent, but that the XML erroneously specifies the computer as the parent.
Another issue I'm trying to get to the bottom of is the correct direction for such relationships. It was in connection with reporting on Business Service models using BMC Analytics - this was the thread: http://communities.bmc.com/communities/thread/41386.
Briefly, in our CMDB (v2.1) we have all our relationships going from parent to child, ultimately up to the business services. So a business service has parents but no children. For a dependency, this means the child is always dependent on its parent. Further, we assume source = parent, and destination = child, which I'm pretty certain is correct.
This (sort of) agrees with the Concepts and Best Practices Guide for our version, which says on page 48 that for BMC_Dependency the destination CI depends on the source CI. Sort of, because it does give what seems to be a contradictory description of the HostedSystemComponent relationship.
In BMC Analytics, to report on service mappings it requires that all relationships go in the same direction. But it assumes the complete opposite of what we've used in our CMDB ie the final business service has children but no parents.
For clusters, I'd see it as going computer system -> cluster -> service. As I say, I'd have it going parent -> child, parent -> child.
But you're saying in the first of these, Tideway (and ADDM) has the cluster as the parent. However, just because Tideway has them in a certain direction, does that mean CMDB would have them in the same direction?
Anyway, as you can tell, this is all quite confusing to me, and I need some sort of official definitive statement on the correct direction for relationships to go. Any ideas on where to find some a statement?!
PS Not sure which XML file you're referring to, but we don't have Tideway or ADDM, so presume it's part of those products.
Yes, the xml file is part of Tideway.
The relationship I referred to between a cluster and computer is the one created by Tideway in the CMDB based on the definition in the xml file.
I'm sure you've looked in the Data Modelling Guide supplied as one of the pdf's with Atrium 7.6.
I quote from page 11:
Relationships in the diagrams in this guide are illustrated using Unified Modeling Language (UML) standards. The UML notation may not be consistent with the BMC Atrium CMDB 7.6.00 user interfaces (UI). Some of this discrepancy is due to the absence of a direct UML equivalent to the relationships represented, and some of it is the lack of alignment between the CDM, the UI, and UML standards.
So, there is confusion between documents and the actual tools!!
The other document to look at is Mapping Your Data to BMC Atrium CMDB 7.6.00 Classes. The relationship normalisation tab helps define source and destination classes.
I don't think there's an issue with component relationships. The destination is a component of the source and this is usually easy to determine.
The dependency relationships are, however, prone to confusion.
I think you've got your business service relationships right. A business service should be a child of related computers/applications/etc. This is counter-intuitive for those whoc are thinking of relationships for the first time and have drawn diagrams with business services at the top and all other components below them.
In the end, which relationships to use and which way round they are is up to you. If you are using other BMC tools then I'd stick with their examples as much as possible so that you can always claim that you've gone out-of-the-box!
Many thanks for this. Yes, I'd read the Data Modelling Guide but forgot all about that section. It does seem I've got the dependency relationships right.
That section does definitely agree with how you've described Tideway working. However, I can't see that working when using BMC Analytics to report on the business service model!
I'll also have a look at "Mapping Your Data to BMC Atrium CMDB 7.6.00 Classes". Have probably read it already, but will revisit it.
Many thanks for your help.
A question and some comments.
1. The diagram above included in the second post for this discussion - can I clarify which BMC document and document version this comes from??
2. The cluster to server relationships question can get confusing if you are not clear on the type of cluster. We have modeled what I'd call regular clusters (say Veritas or Microsoft cluster services) where the cluster should be represented as dependent on the cluster nodes (and hence the cluster is the child or destination CI in the relationship in Atrium speak). We've also taken a 'dumbed down' approach to modeling virtual clusters with, say, several ESX servers supporting a number of virtual servers. We create a 'cluster' CI between the ESX and virtual servers, and represent the dependency relationship as (a) the ESX servers are 'parents' of the cluster and (b) the virtual servers are children of the clusters. We also use SIM and impact relationships in the CMDB, and the above cases work well. The impact relationships (we're on 7.6.02) are set the same way as the dependency relationships i.e. for MS clusters, the cluster nodes impact the cluster, as do the ESX hosts in the virtual cluster example. The 'virtual cluster' impacts the virtual servers also.
So as you can see, depedning on the situation, a cluster can be modeled as a parent in some cases, and a child in others.
The only other thing to be careful about is UML modeling standards. Dependency relationships are represented in a way that can also add confusion. The BMC Data Modelling guides highlight this pretty well.See pages 11/12 of the V7.6.04 document, particularly the top of page 12 . You need to be aware that a UML diagram and the way Atrium explorer will render a dependency relationship can be different.
Interesting to see this discussion open up again! My conclusion on clusters is that it doesn't really matter what relationship type you use. As careyw says, with ESX clusters the cluster can be both a parent and a child - this is also the approach I've taken.
The important thing is to have the relationships always pointing in the same direction (ie from parent to child), so you can do service impact analysis.
There's a question as to whether they should all point away from the ultimate business service, or towards it/them. The concensus seems to be that they should point towards the service, which is slightly counter intuitive.
But once you've decided whether you want the service to be a child or a parent, you just have to always set up the direction on all relationships so that they always point towards the service(s) (if the service is the ultimate child) or away from the service(s) (if the service is the ultimate parent).
The Relationship Normalization tab in the MappingYourData speadsheet was reviewed extensively, and updated for 7.7.00.
Here's what it contains for BMC_Cluster (4):