I have been asked to present at the SAGE-AU conference in August on Open Source Tools. My talk will be about Configuration Management and CMDB's... I wonder if Open-AudIT will get a plug ? :-)
FYI - SAGE-AU Conference is on from the 9th - 13th of Auagst in Hobart, Tasmaina.
http://www.sage-au.org.au/conference-2010/
They're (the organisers) still finalising details around schedule, presenters, etc, etc.
Showing posts with label CMDB. Show all posts
Showing posts with label CMDB. Show all posts
Tuesday, May 4, 2010
Thursday, April 30, 2009
Open-AudIT as a CMDB
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.
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:
Posts (Atom)
Posts
