With all of the recent work I’ve been doing building my first CMDB, I figured why not write about what I am building from a configuration standpoint and maybe a reader can help me, make some pointers, or even learn from what I’ve done thus far. Building a CMDB is an intense and detail oriented process. The way to go is to have flawless agents or robots that scan your network and report back unique attribute details to the CMDB. In my case, we started from the ground up so building from zero to infinity isn’t that bad when you’re controlling it manually. The catch will be of course, what happens when the database becomes a beast to maintain and you still need to create and remove items? That’s for a different discussion though. This post is specific to building database services and the relaionships the database has to a server and the sub-services it supports.
For example, I have been trying to build an Oracle based CI hierarchy that starts at the hardware server level, breaks down to the SID level, then database or schema level, to finally an application level. The objective is to capture all parameters and attributes within each layer and to use service CI’s under the server level that show the relationships and dependencies. The custom image I have added below provides a high level idea on the relationship. The tough part for me? Oracle terminology and design is still a bit new to me and I want to build this right the first time because hours of re-work in a CMDB just isn’t practical. Even saying that though, I spoke with our team architects, directors, and dba’s about the heirachy and overall everyone liked this approach. With that, it’s important to know that there is no standard way of building out the CMDB just as there’s no standard way in building your workflows for an ITIL process. You follow the guidelines and build for what suits your team or company. Hope that makes sense.
This design already had database server CIs in place as well as service CIs on the back end. Why? The service desk tool we have been using (Nimsoft Service Desk) allows us to open new requests, incidents, changes, and problems aligned to a service. Because of this, I thought adding these database items as services was the best alternative as the operations team could essentially open tickets against each individual component of the database. Since Oracle uses a SID level CI and MSSQL does not, SID A and SID B as show in my diagram can be completely bypassed and the database service CI can be a dependent of the DB server when Oracle is not being used. The app is dependent on the database or schema, the database is dependent on the SID (when applicable), and the SID or database is dependent on the server. Not having robots to collect electronic CI data can be difficult to keep up with and it’s critical to get buy in from everyone on your team to play a part in policing the CMDB and notifying you and other administrators of any changes or additions. Having a bulk upload tool like Nimsoft does, makes it really easy to add items coming from a spreadsheet or via xml.
My apologies for anyone who finds this explanation a bit confusing but if you’re working with CIs and building or maintaining a CMDB with database components, this layout or heirachy could be handy for you too. Good luck, let me know what you think, and as always, thanks for your time.