A goal of the CMS is to provide relevant information to processes like Incident or Change management. Looking from a perspective of a business application using an application resource, like an Oracle Schema, the process requires to know which Schema is being used. The issue we're running into has to do with Oracle RAC or Oracle Dataguard, and to some extent MS-SQL Always-On: How to link a business application to an application resource?
The perspective of the business application is to know which Schema it is using; today, the discovery runs on a Node, which returns a Composition Oracle, which in turns return a Composition Schema. In a Oracle RAC/DG environment, we end up with as many Schema as there is Oracle. This is the issue, in RAC, from an Oracle DBA point of view, there is only one Schema, being provided by multiple Oracle.
What I’m asking is that would it be possible to change the discovery process to return a single instance of Schema when only a single instance exists from the point of view of the Running Software? This has an impact of the discovery, reconciliation, relationships type.
The benefit to the processes would be to have a single CI to manage, the configuration manager would be able to link to their Schema based on their business application perspective, DBA would consider the CMS to be more realistic, ITIL processes would be able to use them in their processes.
(We could also apply this philosophy to any types of application resource which has multiple paths, like Cloud based applications, Web Servers, ...)
2020-04-13: I did have a conversation with some internal people. The suggestion so far is to add a CI to link the Schema's together, and then have this new CI linked to the Business Application.
Hi ViauJoc. I completely understand what you guys were describing. I switched over to a separate/custom DB class model years ago (12?). The model I went with was a lesser version of the DMTF CIM standard representation, which allowed representing databases, connection context, and runtime in a vendor agnostic manner. As a side note, doing so allowed me to deal with issues like removing port/SID/Service from the protocol entry, to reduce the number of required SQL protocol entries by like 10x since they only needed the user/password. Anyway, I totally understand.
The class model is an anchor for the data. Then there is work refactoring the code for discovery/integration jobs using those, followed by getting future content developers (whoever writes the next discovery package) to follow suite. I was just suggesting this could be used for more than just Oracle, or any of the database types. It' really a type of runtime. And should developers start to apply the logic mentioned above (for the Oracle DB fix) on any software that could be modeled like a cluster... they could make a bigger splash.
Just going through voting/adding value on some the recent topics; feel free to reach out if you want to continue the convo (contact ). I'm always open to those.
SQL Server is already modeled correctly. There are ClusterSoftware CIs under the Node and the only "SQL Server" object is under the ClusterResourceGroup. With Oracle, the problem is that the "Oracle" object has multiple roles. The proposed topology here for Oracle is basically adapted from SQL Server and DB2 when running under an HACMP cluster. We don't have any other database products running in cluster that we can refer to.
FWIW, the enhancement being discussed above is for a strict CI Type, or at least under the Database category.
This exact same logic should be employed for any software that has a single context and yet sprawls out over more than one execution environment (e.g. cluster/hosted app/streamed app). So if you bump up a level in the Class Model when creating the CITs and valid links... it would help those areas too.