Where I work we have a configuration management database, or CMDB. The term CMDB comes from the Information Technology Infrastructure Library, or ITIL. ITIL to some is a true four-letter word, but the idea of the CMDB has been incredibly handy for us to track information about servers, applications & their support information, IP addresses, warranties, etc. Our CMDB is a full-blown product made for this, but there are millions of ways to keep track of this sort of thing.
The thing is, I think people spend too much time tracking stuff that’s not useful, or that the CMDB cannot be authoritative for. Like the number of CPUs in a host, or amount of RAM. These are things that you can poll the servers for, and that the only authoritative number is what the server is reporting. So why even bother putting it in a database? The same is true for DNS information. The CMDB usually isn’t attached directly to the DNS servers & zone files, so how do you keep the information in sync?
People also put things in a CMDB that should just be standardized. Like the name of a server in the backup system. Often you can tell a backup client that the name of the server is something different than the servername itself. We just decided, a long time ago, to never do that. That way we have one less thing to track.
That said, I also think too little information goes into these databases about application support. Sure, there’s sysadmins in the database, who to call when the server isn’t up, but what about the application people? Why aren’t they in the database, too?
I’m very interested to know what people are doing for CMDBs, whether it’s a full-blown product, Access database, or a text file, and what information they’re putting in there. I’m also interested in what you’re doing with a CMDB. Does your monitoring system pull directly from it to find who to page? How do you get data in and out?
One reason you place the physical amount of memory in the CMDB is so you can keep up with memory failures, as most Dell servers just mark the DIMM bad and continue on into the boot. So your server with 32GB of ram is still up and running but now only on 24GB and if you dont have the DB reference you might not catch the degregation. As well as the obvious reason that some technicians get sticky fingers and think that server doesnt need 64GB but their home system needs more.
Well, for Dell you can just look up the original system configuration via the Warranty Status web page. But I do see your point. Shouldn't hardware monitoring catch the fault, though?
Sticky fingers is a problem that's going to be hard to solve with a system like a CMDB.
I work with capacity planners who use CMDB output do to theoretical capacity analysis of their installed server base. For them, the "not useful" bits like the number of CPUs are crucial, because they often don't have access to the server management tools to extract that information directly.
One problem they encounter is that the CMDB has incomplete or conflicting data. For example, there might be records that contain just an IP address, along with CMDB error codes indicating that no other information was available. Another problem is that the CMDB data conflicts with other management tool reports, or is obviously wrong (like showing a Dell R710 installed in 1996 and running AIX).
Daniel, that's a good point about capacity planners. Perhaps it would be better to expose that information to them in some other way, or for management to tell whoever has the data to get it to them.
As for the conflicting data, that's the biggest reason I don't like putting stuff into a non-authoritative repository. You have to spend time deconflicting it, and keeping it accurate. I'd rather have a good, ad-hoc way to get it from the source.
In your 'ideal' CMDB, what fields would you have?
And then a loaded question: If employees are accessing your network with their mobile devices (and who doesn't), should those devices be tracked in the CMDB?
For us, desktops and mobile devices are tracked outside of the CMDB. I don't know why, and I don't know if I'd make that same decision myself. The CMDB is mainly for data center purposes.
What fields would I have? Server name & type of server (physical, virtual). Whether it's production, test, QA, dev, etc. Is it operational, being built, being decommissioned? The OS type & major version. The model of the server & serial number. The sysadmins associated with the server. The maintenance window. The location of the server. Any billing information.
Beyond those basics the CMDB needs to have the relationships to IP addresses assigned to the server, applications that run on the server, and relationships to any infrastructure the server is attached to, or part of, in the case of a cluster. I say relationships because those should be their own objects, with their own support data.
I wouldn't put anything in the CMDB that isn't absolutely needed by someone in IT to do their job, since the more you have in the database the more you need to maintain. Maintaining a CMDB is overhead for an organization, though it can help reduce overhead of other tasks. I didn't mention CPUs or RAM, though if someone needs them for something and there isn't another mechanism for gathering that data it might be worth having in the CMDB.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.