Relationship type to use between Service CI and equipment in cluster

AlbiAlb
Kilo Explorer

Actually we are using the classical relationship Depends On: Used by between the Service CI and the CIs where the service is running on. What about the scenario when the devices are in cluster. what relationship type can reflect these case? I am referring to any kind of cluster and Discovery is not being used (network cluster, MS server cluster etc)

1 ACCEPTED SOLUTION

CMDB Whisperer
Mega Sage
Mega Sage

A few things that might help here.

First, it sounds like you are creating flat relationships between Services and Servers.  While this is allowed in the platform and may be a quick way to obtain some service relationships, the Common Service Data Model (CSDM) is there to prescribe how services relate to infrastructure via Application Services, Applications, etc. You should make sure that you are following the relationships prescribed by CSDM.  

CSDM does not prescribe the relationships that are used to relate the Application Services to the specific application and infrastructure CIs that prescribe them.  For that you will want to make sure you use the Suggested Relationships.

If I understand your post you are either not using Discovery, or Discovery is not able to capture the cluster information.  If you don't have Discovery in place, or another method of identifying these as clustered CIs, you may want to consider the value of managing those clusters as CIs at all, and instead look for another way to represent these dependencies.  Technically a Service doesn't "run on" a Server.  (At least not the kind of Services we are talking about here.)  An Application Service can use a variety of relationships to its component CIs, including Depends On, Applicative Flow From/To, and Implements Endpoint From/To, but if you are populating those dependencies manually then Depends On is perfectly fine.  If you are capturing your Application CIs (the software installations that run as a process on a specific server) then your relationship should be from the Application Service to the Application, and then your Application should have a Runs On relationship to the Server(s).

That gets to the heart of your question: if an Application CI is intended to be specific to a Server, then how do you represent that it runs on a cluster?  That's where things get pretty hairy.  ServiceNow has a Cluster class and a Cluster Node class, which are logical representations of the cluster, and then the Servers are tied to the Nodes.  This is typically not something people choose to maintain manually, although it is technically possible.  

Assuming that you do not have Discovery, and that this is already too scary and not something you want to maintain manually, my suggestion would be that you simply use the Cluster CI as a logical node in your dependency map, and then create relationships from the Cluster down to your individual Server CIs.  So you will have Application Service --Depends on--> Cluster --Members--> Server1, Server2, Server3 or something to that effect.  From there, you can create a CMDB Query if you need to query across those relationships.

 


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

View solution in original post

2 REPLIES 2

CMDB Whisperer
Mega Sage
Mega Sage

A few things that might help here.

First, it sounds like you are creating flat relationships between Services and Servers.  While this is allowed in the platform and may be a quick way to obtain some service relationships, the Common Service Data Model (CSDM) is there to prescribe how services relate to infrastructure via Application Services, Applications, etc. You should make sure that you are following the relationships prescribed by CSDM.  

CSDM does not prescribe the relationships that are used to relate the Application Services to the specific application and infrastructure CIs that prescribe them.  For that you will want to make sure you use the Suggested Relationships.

If I understand your post you are either not using Discovery, or Discovery is not able to capture the cluster information.  If you don't have Discovery in place, or another method of identifying these as clustered CIs, you may want to consider the value of managing those clusters as CIs at all, and instead look for another way to represent these dependencies.  Technically a Service doesn't "run on" a Server.  (At least not the kind of Services we are talking about here.)  An Application Service can use a variety of relationships to its component CIs, including Depends On, Applicative Flow From/To, and Implements Endpoint From/To, but if you are populating those dependencies manually then Depends On is perfectly fine.  If you are capturing your Application CIs (the software installations that run as a process on a specific server) then your relationship should be from the Application Service to the Application, and then your Application should have a Runs On relationship to the Server(s).

That gets to the heart of your question: if an Application CI is intended to be specific to a Server, then how do you represent that it runs on a cluster?  That's where things get pretty hairy.  ServiceNow has a Cluster class and a Cluster Node class, which are logical representations of the cluster, and then the Servers are tied to the Nodes.  This is typically not something people choose to maintain manually, although it is technically possible.  

Assuming that you do not have Discovery, and that this is already too scary and not something you want to maintain manually, my suggestion would be that you simply use the Cluster CI as a logical node in your dependency map, and then create relationships from the Cluster down to your individual Server CIs.  So you will have Application Service --Depends on--> Cluster --Members--> Server1, Server2, Server3 or something to that effect.  From there, you can create a CMDB Query if you need to query across those relationships.

 


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

Thank you Paul for all the useful information. Yes we are using Discovery and its capturing information about virtualization, hosting etc but not information about the cluster.

 

Thank you for your help!