Hi Kelly,
Here's what I've done in the past: - A blade chassis is a computer in its own right so map it in the computer system class - Map blades also as computer systems and relate them as components of the blade chassis - Relate computer systems that are in real racks to the racks in the rack class - Relate blades and virtual systems running on the blades to a cluster as you may not know which actual blade is hosting a VM at a particular time - Add height and rack location attributes to the computer system class - Add a new tab and table to the rack class and display the computers in the rack in the table along with their height and position - Add a field under the table showing the sum of the heights of the computers - Add a new attribute to the rack to hold the size of the rack - Create a new power management class (sibling of UPS) to hold power strips and power sources (product categorisation defines each) - Relate the strips and power sources to the computers - Use the CI location fields to identify where the racks are located (including room & floor with appropriate naming conventions) The federation you can do to Nlyte might be better and replace some of the above but in my case the client didn't have any data centre tools and wasn't prepared to pay for any!! I've also been involved with mapping building -> floor -> room to separate, related physical locations as we needed in this case to store access, air conditioning and other details for each of these areas in the CMDB. Don't be afraid of extending the CMDB as you'll get better value from it if it stores what the users want and in doing so can retire the spreadsheets and ad-hoc databases they are probably using now! Cheers Peter From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Logan, Kelly Sent: 26 April 2012 16:51 To: [email protected] Subject: Rack and Enclosure modeling in CMDB 2.1 ** Hello all, I am looking for some experience/advice: We are looking at modeling our computer centers in Atrium CMDB 2.1 (w/ ARS & ITSM 7.6.4), including the racks and enclosures. I am looking at several concepts right now to model this data and would be interested in any strategies others have found to be useful in their environments. What I am looking to determine now is not only how to model the data itself, but what processes will be automatically provided, and what processes I will have to customize/create in order to help Infrastructure do their job. Here's what I am thinking of right now (in broad terms): 1. Extend the BMC_Equipment class to create PQ_Rack and PQ_Enclosure classes, perhaps with AU (slot) classes as well. 2. Utilize BMC_PhysicalLocation to represent object locations (Rack 3-5, AU slot 2) and use custom reports to track overall locations. 3. Extend the current BMC_Rack and BMC_Chassis to add necessary attributes. 4. Federate the location (rack, enclosure) data into a custom Nlyte-like application. If there is a way to utilize the Common Data Model without customization, that would be my preference. Note that the Racks and Enclosures do not simply hold blades, they also hold network modules/patch panels, SANs, power, etc; each of these may also take up more than one slot per. By processes, I mean that Infrastructure will want to be able to quickly tell from an asset name, where it is precisely (site, grid location, rack and enclosure slot). Or, given a two slot asset, where they can plug it in (display the racks where two consecutive slots are available, or at least show the open slots in a fashion that it is easy to see where two consecutive ones are). For example, if I follow strategy 1. and create PQ_Rack and PQ_Enclosure classes, let's say I create AU (slot) classes as well, with component relationships to the racks and enclosures. It seems like this would allow me to define the number of AUs by creating only those CIs (If a rack has 20 slots, I create 20 AU CIs). This would also let me indicate when a slot is unavailable (because cords it is used for cord management, for example) by setting that AU CI's status. Each thing put into a slot would be connected to it using a location relationship. This seems to be the cleanest and most Object Oriented of the set, and if I understand the system correctly, I could only allow 1:1 relationships between the slot and the slotted asset, which would prevent any mistakes. There is concern however that this would involved too much extra work. Again, if anyone has tried modeling racks and enclosures in this kind of detail or done some investigation on doing it I would appreciate your experience and advice on the subject. Thank you in advance, Kelly Logan, Sr. Systems Administrator (Remedy, Planview), GMS ProQuest | 789 E. Eisenhower Parkway, P.O. Box 1346 | Ann Arbor MI 48106-1346 USA | 734.997.4777 [email protected] www.proquest.com ProQuest...Start here. 2010 InformationWeek 500 Top Innovator P Please consider the environment before printing this email. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender, and delete the message from your computer. _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
