3 Replies Latest reply: Aug 13, 2012 3:58 AM by patchsk RSS

Interested in CMDB Patterns?

Felix Bodmer

The Atrium CMDB Data Modeling Guide doesn't offer much information on how to apply BMC best practice when creating CMDB and Impact models. I've spent quite some time developing models for some generic patterns - covering the whole stack.

 

Was wondering if there is any interest in the community in that work. I published an example on: http://felixbodmer.wordpress.com/infrastructure-patterns/compute-server/

 

The idea would be that as a community we could collectively improve these patterns. I would contribute the patterns and in return would hope to get some feedback on the design and open issues I listed.

 

Unless there is already a place where all this is happening - but that would be a very secret place as I've been talking to many individuals about this and searched the web for countless hours.

  • 1. Re: Interested in CMDB Patterns?
    careyw

    Hello Felix

     

    The model you suggested looks very sound, and very detailed. From a totally theoretical point of view, if you are considering things like fans etc as CIs, then creating impact relationships from memory and processor CIs would also seem important.The value of these is both for configuration purposes (knowing what the details of the server are) and for impact management (when an event occurs, what are the impacts). So if you MUST have that detail for config. understanding, and/or you have the level of monitoring that supports these CIs, then there is a valid case for their inclusion.

     

    However my question is who will maintain this level of detail in a 'real' deployment of this conceptual model?? Do you have discovery tools that will 'drill in' to this level of detail (I know some do but not everyone has these available). Can you afford to scan the entire infrastructure environment for this detail, and then  integrate this back to Atrium?? That's alot of scan time and data and lot of integration/sync time and data, for anything other than a small departmental view. Without the assurance that either an automated process like an autodiscovery tool) or a manual process (like Change Management) is keeping this data up to date, is it practical to go this deep??

  • 2. Re: Interested in CMDB Patterns?
    avalveka

    Hi Felix,

     

    I do agree with careyw, the model you suggested looks good. The time you have spent for designing this model is worth.

     

    Yes- Theoretically we can consider fan as CI but here we need to see from infrastructure point of view, if you have separate cooling system for machines then impact would be less(heat dissipation) if fan goes down or its stopped working. This will reduce number of r relationships. On other  point Memory and CPU is equally important for Impact relationship as it would affect on performance.(if CPU usage goes high -> directly affect on performance).

     

    Thanks and Regards,

    Abhijit Valvekar

  • 3. Re: Interested in CMDB Patterns?
    patchsk

    I really liked your representation on a computer system ci. Very detailed. But as other suggested it takes lot of resoruces to maintain this level of detail. Otherwise it becomes stale very fast and will not serve the purpose of single source of truth.

    I think you do not need to represent CPU and Memory as a physical ci unless you really want to track memory sticks and cpu sockets at physical level for example  when you want to interchange with other hardware. Even in that case who is going to update the cmdb relationships  when they interchange memory stick from one hardware to another hardware?

    As per the events being generate on those CIs, the frequent events generated are when the CPU or memory reaches above a threashold, which can be mapped to application which is using that server instead of at physical  CPU or Memory level.