Big enterprise shops aspire to build a Configuration Management DataBase that will track their IT assets, how they’re configured, who relies on them, what applications live on them, and so on.
Let’s take a simple web application as an example: what would it take to document its components and configuration? We would want to know:
- What servers it lives on – including the database server(s), the web server(s), the app server(s), and any file server(s) where it might store content
- What parts of the app live on what servers
- How the application is configured on that server
- How the server itself is configured
- Who to notify when any of these moving parts change
If it’s done right, it ties in with other IT systems in the shop. When a server goes down, the CMDB could tell us:
- What applications are affected
- Who we need to notify
- What the server’s last known good config was
Building an enterprise-wide CMDB is a lot of work because of the complexity and cost involved, and some say it can’t be done.
At the enterprise level, they might be right – but for a SQL Server DBA, we do the impossible all the time. This Thursday, I’m doing a Pain of the Week webcast on how to build a simple CMDB to collect information about your SQL Server environment using freely available tools like SQL Server 2008’s Central Management Server, its group query execute functionality, and Quest Discovery Wizard. You can register for the webcast online.