What is the best way to use the CI relationship types? What do the different types mean and what is the effect if you define one relationship type over another.
I have read on the forum that Parent-Child is a dependency relationship where the child can not function with out the parent being available. However when would you use the relationship type dependent vs parent-child?
And do these different relationship types affect your SLs and availability reports?
If someone can take the time to give scenarios or examples for each of the following relationship types I would be much obliged.
Parent-Child Connected Installed software Document backup Original Dependent Contains Is part of
Desktop PC, hard disc, speakers, sound card, monitor, antivirus software and external usb kit (drive & cable)
Hard disc and sound card are childs of Desktop PC. Monitor is connected with Desktop PC while speakers are dependent on sound card and also connected to PC. Antivirus is installed software. Usb kit is connected to pc, while drive & cable are parts of it.
A good example from George. Is not easy to choose the best relation type between CIs. To do this you should have in mind two basic criteria: 1. Physical or logical connection between CIs. 2. OVSD features regarding parent/child and free form relations. To give you an example, a good choice is to create parent child/relations between HW and SW CIs. (SW CIs are children). The reason is application ability to control the number of parent/child relations until Max. installation value has been reached. Other examples: 1. A printer is 'connected to' a PC 2. A license 'grants' a SW CI ('granted by') 3. A procedure document 'reference to' an application ('referenced by') Hope this helps you a little.
Say you have a pc and a monitor. If the pc fails the monitor can't display anything and vice versa. This dependancy is expressed as a parent-child relationship as the parent (pc) is affected by the child (monitor). Basically one CI cannot function without the other.
Peer to Peer relationships will establish a relationship between CI's without this hierarchy of parent child. A pc will work if the connected printer is not working and vice versa.
It is important to: Keep things simple Have as few relationships as possible Establish reverse relationships
Thanks for all the great replies. I understand the examples however here's a specific example question. If I have a switch connected to a several servers, is the relationship connected or dependent? The servers can't 'talk' to any other device unless the switch is up but is it really dependent?
Also, does the different relationship type have any impact on my SLA for the service or is the relationship type really for further clarity in the 'service mapping'.
It depends on the view point, I'm afraid. If you are using relations to map "network functionality", then yes, servers are depended on switches/hubs/routers/modems/whatever in order to have network connectivity. But in this case, the server is not only dependend on switch, is also depended on its network cards, cables etc.
On the "physical" level a pc is connected to a network device.
I would say that they are connected. The server does not need the switch to work. The server can boot up and you can manage the OS and apps regardless fo if the switch is connected or working etc.
I do take the point that for connectivity and for the server to "server" requests it needs to be conected to other communication devices (switched, routers etc.) but I take the approach that these devices are "connected".
If say the switch failed, the server does not fail also it is still operational. It however cannot server requests.
I think what would be useful (to me anyway)would be to talk about the types of viewpoints that should be considered, and from there create relationship types that are specific to that view. From a HARDWARE perspective a NIC card is a child (or subcomponent) of a server and the server is connected to the switch. The server as a whole does not function correctly with a failed NIC (sure it will boot and run OS but it is a boat anchore)and so they are dependent while the switch and server are not dependent on one another. Hardware type relationsships are the easy wins and a good place to cut teeth when starting.
From a SERVICE perspective: You can define a relationship type called upstream/downstream that is in effect the same as a parent child relationship but is defining a SERVICE perspective relationship. I'm kind of brainstorming here but I guess you would have to map how the service "flows" to the customer. A service is provided using a piece of software, software resides on (needs) a server, server connected to (needs) a switch. It is not quite that simple because each of those steps have their own dependancies for example the software may need a DB to function and there are server and network dependancies there, and the server has it's hardware perspective dependancies. But if all goes to plan through this part you have a service that is available to the network on a corprate level at the network core. Distribute that service to specific locations away from the core via some more network service and hardware dependancies. From there to an individual user through a connected PC.
A harware relationship of "connected" Will be an indication of a service "upstream" or "downstream" relationship.
Redundancy adds a level of complication I think. We are no longer dependant on a single data path or NIC card but on one or the other being available. Logicaly it is simple xor operation but how is that represented in a CMDB relationship? Service path "A" and "B" where as long a either/or is available the SLA is being met? Mapping out these seperate paths also leads to identifying single points of failure.
From a service perspective should the application providing the service be the root of service dependancies (each service has it's own root) or is the network condidered the root for all services? Services flow upstream to the network and from there back down to the user?
We use two simple rules to determine the type of relationship between two CIs:
1) We use parent-child ONLY if we want to benefit from OVSD's built-in functionality, which limits the number of such relationships to the total number of the non-unique child CI.
2) For all other relationships, we create as a relationship name a short phrase which, when read by the user, makes it completely clear what the relationship is. For example: is installed on is connected to