Best way to map database cluster CIs in the CMDB?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-12-2016 07:58 AM
We are designing the CI taxonomy of databases in preparation for loading them into the ServiceNow CMDB, and we've run into some problems figuring out the best way to implement database clusters. We have multiple types of databases and not all of them are clustered, but Oracle clusters are the most common. The prevailing examples online seem to use either the "Cluster" CI type or create a new CI type named something like "Database Cluster". Obviously, either of these solutions would work, but we want to be mindful of setting this up in a way that could prevent us from using features in upcoming releases and integrating with plug-ins, especially in regard to implementing Service Mapping.
Using an Oracle database cluster as an example, looking at the out-of-the box CI classes and relationships, it looks like Database (cmdb_ci_database) and Oracle Instance (cmdb_ci_db_ora_instance) could easily represent the logical database (clustered or not) and running software respectively, by using appropriate attributes (e.g. cmdb_ci_database.clustered & .cluster_type, etc.) and relationships (e.g. cmdb_ci_db_ora_instance Runs on::Runs cmdb_ci_server, cmdb_ci_database Members::Member of cmdb_ci_db_ora_instance, and cmdb_ci_appl Depends on::Used by cmdb_ci_database, etc.).
My questions are essentially 1) Does this type of model make sense? 2) Is there a better way to do it?
- Labels:
-
Enterprise Asset Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-20-2017 09:16 AM
Hi, whilst I don't quite have the answer to this I can say that it is imperative to create a tool (ServiceNow) agnostic domain / data model that defines your requirements. Only then should you look to your tool to see if it can fulfil this.
I got as far as the domain model but the organisation did not have the appetite to delve into the world of databases on its implementation. 'Maybe next year' they said 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-20-2017 03:55 PM
The high level model that makes the most sense seems to be...
cmdb_ci_appl (or cmdb_ci_service) Depends on::Used by cmdb_ci_database
cmdb_ci_database Depends on::Used by (or Hosted on::Hosts) cmdb_ci_cluster
cmdb_ci_cluster Members::Member of cmdb_ci_server
Will be sorting out specific relationships in the next few weeks.
If you think adding databases would be beneficial, then stick with it. I find that configuration managers tend to forget more about integrations, relationships, and dependencies than some process owners ever learn, so you're probably right
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-20-2017 04:52 PM
Hello Graham.
I would "group" them the way ServiceNow Infrastructure Discovery does. You mentioned ServiceMapping, and ServiceMapping will require Horizontal Discovery. So it only makes sense to group them however Discovery would.
I do not know Oracle very well, but the answer is on the docs site or the wiki. If you cannot find it, let me know and I can look at one of my instances where I have Discovery running. Or you could reach out to your sales person or professional services team. They should be able to provide insight.
Best Regards,
Jeremy Perdue, ServiceNow Consultant | Contender Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-21-2017 07:03 AM
Jeremy,
My above post is how I believe an OOTB Helsinki Discovery would find them. We are currently working on the professional services engagement for ServiceMapping. We couldn't wait for that at the time of my initial post, because we had an immediate need to get it implemented at that time.