How should a Windows Clustered SQL Server be represented in a discovered Business Service.

[DuaneNMore]

We make use of Windows and SQL Clusters for availability purposes in our Data Centers. So we will have a 2 node SQL Cluster that is supporting some business service. The configuration from the upstream web server points to a cluster name but when it ultimately gets discovered it only incorporates the Active DB Node alive at the time of the discovery. It knows about the sql cluster because it identifies a cluster node in the map. 

Preference would be that Both nodes in the cluster be discovered, that way we can assign impact values that reflect the actual impact to the Business Service. As it is now, if dbActivesvr goes down, it appears like a single point of failure, when in fact dbBackupsvr will pick up the slack.

What is the recommended best practice here for properly discovering and mapping these clustered resources.

Similar question would exist for our F5 clusters. 

[dcwilson]

In my opinion the way it should be represented in a Business Service you have to deal with a messy Class - Windows Cluster Resource.

The Business Service has a (something like used by/depends on) relationship to the Application that has a (something like used by/depends on) relationship to the Cluster.  The Cluster has a (something like has member/member of) relationship to the Cluster Roles (OOB ServiceNow creates the the Windows Cluster Role CI  in the Windows Cluster Resource Class (which is a catch all for anything related to a Cluster.) ) and the Cluster Roles have (something like used by/depends on) relationship to the Cluster Node, The Cluster Node has a (something like used by/depends on) relationship to the resource it is running on.  OOB Discovery does a good job of keeping the relationships between the Role and Node accurate.

In my previous position the instance used the server name as part of the application instance name which created the issue the SQL Instance was created with the active physical server the node resided on as part of the name rather than the Cluster Role.  So when the Role is moved to another Node and it is re-Discovered it is recreated with the new server name.  Which is really a duplicate CI and this wouldn't happen if the application instance was associated to the Cluster Role rather than the server the Node is residing on.  

Haven't started Database discovery in this position as of yet, however I have noticed the application instance names do not include the server as part of the name, which makes it appear that there are duplicate CIs but they're not because they're running on different servers.

[DuaneNMore]

Horizontal discovery does a good job of discovery the cluster; its just that the service map is only partially aware of all of the components of the cluster; and as such the impact rules and map relationships don't really reflect well that construct.

[robertgeen]

Okay so 2 things to look at with this. The first is that Microsoft Clustering is done in such a way that when you discover it, it will only show the active node on the maps and add a +# to it to show that there are other servers on it. I had a client who had a requirement to show all the nodes in there and it required pattern changes to draw to the other nodes on the port that microsoft clustering uses. It's a bit of a messy workaround.

As for F5 what you should see is the active LTM that responds to the VIP will show along with all the nodes it's loading balancing for. As of now there is a bug in which there is no way to show the GTM -> All LTMs on the map but this is apparnetly fixed in London (the problem is that the GTM as a whole is just a DNS switch that happens so everytime you hit the VIP you are only going to see the LTM it is forwarding you too). As far as I know to make this work in London they had to do a back-end code change but Support hasn't been super helpful outlining what hat is (they also said it was fixed in the recent patch of Kingston but this turns out not to be true).