So, I've been thinking about CMDB's (Configuration Management Database's) and how Open-AudIT can be used.
Essentially, I am thinking a CMDB is a list of CI's (Configuration Items) and their relationships (to other CI's). Open-AudIT contains a large list of details about many items - so there's a list of CI's right there. All we really need to do is to define how these CI's relate to one another.
I have encapsulated this data in essentially two tables. Table one defines a CI. What is it ? What table (and row) is it in ? Some other details not automatically captued by the audit scripts. Another table detailing the relationship between the CI's. The two CI's concerned. The type of relationship. Any credentials used, etc.
A large amount of this can be automatically populated, upon initial setup of a CI. I am thinking about the logic needed to auto create a number of CI's and their relationships by "following" the trail through the OAv2 database, linking them up.
I have also created a third table, essentially to say "These CI's (and their associated relationships) belong to this particular 'CMDB App'". So you can create a CMDB App of, say, a particular web application. Example CI's would be the website, the database, the users URL, the group of systems accessing it, the database credentials, etc, etc. Wrap the whole thing into a CMDB App, and it then becomes easy to run "what - if" type questions on the CMDB.
What if I change the website from server A to server B ? Show me all the affected CMDB Apps and the specific CI's for each CMDB App. That kind of thing.
I'm still thinking this through, but I think it could be a very powerful and compelling way to utilise the data contained within Open-AudIT.
Any comments and suggestions are more than welcome.
Subscribe to:
Post Comments (Atom)
Posts
This would be incredibly useful. I'm in the process of extending Open-AudIT to support our organization specific data. Specifically, the business apps supported by a server ("CMDB App") along with manually defined information about the app (SLA tier for BCP/DR, owner, app users, links to documentation). Sounds like your work would render mine obsolete =)
ReplyDeleteSomething I was thinking about was the ability to define a signatures that automatically make a server part of an overall business app. For example, I could define an "Email" application and tell Open-AudIT "if the Blackberry Server service is present, automatically add the host system to the Email application".
Once the server was associated with the business app it would inherit the SLA, owner, users, etc that we define at the app level. This info would be displayed when viewing a server, and would be available in a list view.
It might help if I explain one of the ways we plan to use Open-AudIT so you can see where my head is at... We do monthly patching of servers, and the server role defines when we can patch. Open-AudIT will be used to generate reports for patch scheduling. The reports will include schedules of when patching is allowed, who needs to be notified, etc. The reporting and patch management pages will probably be outside of Open-AudIT, but I want to make the Open-AudIT DB the central repository for all the relevant information.
Hey Ryan, can you post a list of attributes you are using for "CMDB App" ? I haven't thought too much about what would be needed in that table, so any help would be much appreciated.
ReplyDeleteAs for signatures, I think the Group functionality could be used for this (in OAv2 - it doesn't exist in Open-AudIT).
This comment has been removed by the author.
ReplyDelete* Server name
ReplyDelete* Flag as dev, QA, pre-deployment, production
* Physical Location
* Hardware Make / Model
* Hardware Specifications
* Serial Number
* Deployment Date
* Expiration Date
* Last patch date
* Role / applications (at the component level - e.g, Mailbox server)
* Business application attributes (server inherits these properties)
** Application name (major service - e.g., Email, Document Management)
** Business continuity class ("Platinum", "Gold", "Silver", "Bronze")
** Users
** Outage scheduling requirements
** Related applications and services (Interdependencies, e.g. Exchange depends on Active Directory)
** Link to configuration and build documentation
** Link to application test procedure
** Last DR test date
** Application owner
* Server specific overrides from parent:
** Outage scheduling
** Configuration documentation
** Test procedures
** Owner
Nice List.
ReplyDeleteAll of the * attributes, OAv2 already does.
For the rest, I have in OAv2 the ability to define arbitrary fields. These fields can be displayed anywhere in the "System Summary" page(s). That should go a long way to providing any fields not in the app, by default. I have this code working, but need to front-end it (IE - allow the user a form to setup these fields).