Database discovery

miguelrios
Tera Contributor

Hello,

I'm seeking for guidance,

We are using Discovery to get some database servers, the problem/concern we have is that we are getting the instances or listeners (using Oracle as example) related directly to the server (AIX) but we don't see the database server classification for Oracle, or an application between the AIX server and the listeners,

Basically the Database admins want to see, AIX server -> Oracle application -> Oracle Instance in the dependany view,

Do you know why is excluding this middle Oracle application element?

Thanks in advance.

bernyalvarado

1 ACCEPTED SOLUTION

doug_schulze
ServiceNow Employee
ServiceNow Employee

Miguel,



That would be correct, there is no concept of database server, you have a database instance that runs on a compute.   Two separate and distinct CI's with no concept of a general "oracle application"..



now to be fair in a service model there could be a business application that supports a service, say Database services but that does not fit into a structural CMDB model.   Clearly looks represented as it should and please welcome your DB Admins to the world of ITIL for me



Let me know if that helps or if I can provide additional understanding.


View solution in original post

16 REPLIES 16

So this database CI is related to the instances how?   Are they in a dependent relationship?   Are they a reference? In the CMDB I dont see either.. You dont need database CI to run instances and instances do not provide for your database CI, nor does the Database CI provide supporting components to the instance (reference).



I believe this is where you extend into the service model and not a CMDB.   That Database Services (your Database CI) are provided by instances 1,2,3 ect..but instances are independent CI's that have a one to one relationship to the compute that runs them.



Now fairly some folks have told me in the past to go pound sand , they are going to represent the CI's as they see fit darn you and your ITIL Doug..   Which is fair, ultimately the good folks that pay our checks get to decide, all we can do is give the best structure to standards that closest resemble what the industry adheres to.   With that said Tom yes that could work but again, I see that more in a service model then CMDB.



And why do tables exist that arent populated OOB?   Well you gotta remember Discovery came long after integrations back in the day.   Fred, Dr Loo and Bow put in "placeholder tables" (my term) that customer might want to use as the platform was getting off the ground, and, they kinda stuck around... I have tried for years to get them removed or only show what discovery is going to fill in, but that would be kinda selfish especially with all the other tools we now have that might populate the CMDB.



Hope that helps continue the conversation..


So, none of the example I discussed in currently in ServiceNow that is why you don't see either. My thinking, and how its implemented in other tools (BMC for one), is not the concept of the service but a holistic representation of a discovered database and all its instances. So, you could have a class for database and have the "holistic" CI there with dependency relationships to the database instance and listener CIs. The instances would have Runs on relationships (as they have now) to the server CI. The reason for the holistic database CI is to group/relate all of the discovered instances together so that you can better identify how many instances are deployed in an environment, also if you are performing a change to a database, you would have to remember to associate each individual instance of the database to the CRQ. This is an issue if you don't know where all of the instances are or if there are any others because if you are making a change to a database, that change affects every instance, not just one. Correct?



I think discovering every database as a "service" is overkill. I certainly wouldn't want to use ServiceWatch to do that for thousands of databases as we have here. I could see a service relationship for "Database Services" then a relationship to "Oracle" then to the holistic database CIs then to the instances then to the servers.



Database relationship concept.JPG



Thoughts?



As for the Database servers section, it kinda threw me because I was hoping that their was a way to auto-detect and show in the list all of the server CIs where a Database was discovered running. Maybe have a flag set on the server CI and then show only those server CIs under that section. It would make it very easy to then show what discovered servers had a DB on them instead of some type of report to look at instances and follow relationships to gat back to the server CI.


Tom, you lost me at "how BMC did it" ..   Our conversation is now done....



Kidding, no I think you misunderstand me when I say service model, I wasn't referencing ServiceMapping, but business services as a whole. In the map you provide above (with the relationships) Id challenge you there, for your holistic DB does not provide for anything, your DB instance is not dependent on a category CI to run, its dependent on the compute power. In your example I would see it as a contains relationship, that your holistic DB service, contains these contained database instances again within the service model (not servicemapping).



But to help my understanding, what will define if a DB instance belongs in that container?   Guess it could just be local requirements, all version 11 DB instances?   Eh, you can go 20 different directions there..



And to the Database Server table, sure why not.. if it suits a local requirement if a instance is found running on a compute check a flag that says its a database server and modify the module to show those compute powers that have the box checked.. But, what if that server is also running apache?   Isn't it then a WebServer and your check box would be now invalid?   Think about that for a second and see why there isn't a concept of Database server class, but rather a database instance that is related to a computer that its running on.


Ha Ha, have to get a dig in there every once in a while for features seen elseware and not in ServiceNow



I agree on your change of the relationship of "contains" instead of "depends on". If you are referring to the holistic database CI as a container, the determination would be that the instance has the same name minus the server host name (duo1234@server1 & duo1234@server2 would be related to the CI "duo1234" representing the database (holistic CI).



Database relationship concept.JPG



As far as the database server topic, Im not saying that by discovering a database running on the server we are "classifying" the server as only a database server, we are just pulling out (bucketing) for easier reference the servers discovered as having a database running on them hence the existing breakouts.



database servers pic.JPG



We already have a discovered grouping of servers for webservers in the "Application Servers -> Tomcat or IIS" accept those are really instances (logical app server)   and not the actual server CIs that are running the webserver instance.


app servers pic.JPG



Thoughts?


Tom, you are correct they are instances in the Application list, but (get ready to suffer some semantics) they are Application Servers by nature of their task. They serve different application layer instances (EARs/WARs/Jars) that provide the actual service.   You just have to absorb that the term 'server' is used in both the compute and application space.   I had to learn this in my ServiceMapping ramp up.   In a previous life I was a DataCenter system admin, now I live in this application space and have been brought to the light that applications can be servers (but not computer servers)   because they provide for the processing capability for the extended application components, just as compute provides processing for the instance of an application.   Hope that makes sense.