2 of 2 people found this helpful
We have server (class=ComputerSystem) -> rack (class=Rack), rack -> datacenter (class= Physical Location), datacenter -> address (class=Physical Location)
So we use Physical Location for both the datacenter CI and the actual physical address CI. This class has several location specific attributes that should help you differentiate the multiple data centers in one location.
All these classes have the standard location attributes as well such as site, floor, room etc.
So - the above relationship hierarchy will help you see where a server is (either which rack or which datacenter), and also help you assess impact if, say, power to a rack or even a whole datacenter is in trouble.
While the above is working fine for us, please also be aware that BMC have mentioned in the past that the Rack class may be dropped in future versions on CMDB in favor of a better mechanism for exactly this type of requirement. Do a search in this forum for posts that discuss Racks and Blade Enclosures and you'll see where the thinking in these areas was going.
Thanks for quick response. Few more query on above one.
Source Destination Relationship BMC_PhysicalLocation BMC_COMPUTERSYSTEM BMC_Dependency (as per BMC Sheet) BMC_Rack/BMC_Chasis BMC_COMPUTERSYSTEM BMC_HostedSystemComponent (fetched from Community)
-->What kind of relationship will exists between a Rack and DC or Vice-Versa.
-->What kind of relationship will exist between Site (physcial Location) and DC (when we have mutiple DC in one site). So that if i open the site/physical location CI i can see the attached DC with that Site.
1 of 1 people found this helpful
I'd use BMC_ElementLocation for both.You can then see all racks in a DC and all DCs in a site/location.
So it will be
Location -> DataCenter -> Rack -> Server
Having a direct link from DC to Rack seems a little weird without something in between, but is still physically/technically correct.