Thanks, Peter! You make a good point about the blade enclosure, I will see if that should be added as a tracked computer system as well.
Infrastructure is looking to replace the Nlyte product, which is one reason I'm considering hosting this data in the CMDB. One advantage I believe is that I can use the sandbox functionality to automatically offer the planning requirement they want (to be able to model major restructuring without affecting the production data). Another is that I can use Atrium Integrator to update this data (from realtime monitors and static update files). The disadvantage is creating and maintaining this data in the CMDB instead of federating out to another system (which is why I am still considering this idea, if anyone has a good freeware rack tracking system that they've integrated with). Note that there is both a requirement for easy updating of information (moving things from rack to rack on a weekly, sometimes daily basis) and for mass updates (patching all OS of a specific type, or moving one rack's contents to another). Here's what I've worked out so far, two extra classes and two extra relationships: (Equipment parent) class PQ_Enclosure (type set by CTI: Rack, PatchPanel, Blade Enclosure, etc) (Equipment parent) class PQ_Slot that will be related to PQ_Enclosure (component) and to slotted CIs. Relationship PQ_SlottedLocation: Cardinality Many:1 , Regular data storage, Source PQ_SLOT, Destination BMC_BaseElement. Relationship PQ_AvailableSlot: Cardinality 1:Many, Regular data storage, Source PQ_Enclosure, Destination PQ_SLOT. So the basic model is PQ_Enclosure --PQ_AvailableSlot--> PQ_Slot --PQ_SlottedLocation--> (Slotted CI) The idea is to have a flexible structure that can be used to represent any physical object that holds a set of other objects, from a rack to a blade enclosure to a SAN. Since an enclosure can contain another enclosure, I can use the same class to for the rack, the blade enclosure in the rack, etc. One enclosure can have many slots, and one device can connect to many slots, but each slot may only be connected to one enclosure and one CI, so the system should inherently prevent double-slotting a CI. This should also allow impact analysis to be done through a rack to determine effect of changes and allow for transparent change management of restructuring. Regarding room location, I am planning on using the BMC_PhysicalLocation class to denote the rack's location by room and grid coordinates. Since each asset will be related to a rack that will have this location set, this should allow me to consolidate the location information of all of the assets in a rack in one location object, reducing duplication of data. Also the location of an object would be updated automatically when it is moved from one enclosure to another, reducing maintenance. What I am not sure about yet is how this will actually look to the user or how much work it will be to set up and maintain it. For example: 1. Can you see a relationship one or two levels away on the CI relationship table? For example, if I have a rack that has a BMC_PhysicalLocation object related (room 345, grid 1,8), a blade enclosure related to the rack and a blade related to that enclosure, from the blade's relationship table, I'm assuming I won't see the location object related, right? If I won't, is there an easily available mechanism to trace up the tree to find and display it on the CI form? 2. I'm thinking that I can add a table onto the PQ_Enclosure form that will allow for searches of related PQ_Slots, with a filter to let the user choose between All, Open, and Filled slots. Any problems with this? 3. What will the easiest way be to find a particular combination of slots? What I imagine is a button that brings up a dialog that lets the user choose location, enclosure/slot type, and number of slots needed. For example, say there is a three AU enclosure that needs to be mounted. If there is an easier mechanism built in, please let me know, but here are my thoughts otherwise: a. I could reduce the scope of the search with a running tally of open slots on the enclosure themselves; start with a list of only the enclosures that have enough slots, then search to find consecutive. b. A smart search could start with the number of consecutive slots needed, (ex: 3), table walk related slots in order, add to a counter for each open slot found, reset the counter for used slot found, and stop when counter equals slots needed. 4. Another useful piece will be having a visual representation, Nlyte style; i.e., the enclosure objects and relationships would be exported to this solution and a visual image of the rack and the objects in it would be generated. I have been told there are some freeware (visio?) solutions that will let you plot relationships in controlled fashion like this. Does anyone have any recommendations on, or advice on exporting this data out to, one of these solutions? 5. Am I correct in assuming that I can create the CIs and relationships as described above (assuming classes have been created and reconciliation rules generated) by importing from a spreadsheet or similar source using Atrium Integrator? I am envisioning a list of racks with ids, a separate list of slots with the rack ids, objects with the slot ids, etc. 6. Is any of this available Out Of Box as part of Capacity Management or another solution? 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 kelly.lo...@proquest.com<mailto:kelly.lo...@proquest.com> 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. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peter Romain Sent: Thursday, April 26, 2012 1:36 PM To: arslist@ARSLIST.ORG Subject: Re: Rack and Enclosure modeling in CMDB 2.1 ** 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:arslist@ARSLIST.ORG] On Behalf Of Logan, Kelly Sent: 26 April 2012 16:51 To: arslist@ARSLIST.ORG 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 kelly.lo...@proquest.com<mailto:kelly.lo...@proquest.com> 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<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://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"
