SQL Cluster

I am fairly new to SW so bare with me. I have not been able to find a recent answer for this question. I currently have a SQL cluster that has two IP addresses (environment does not use DHCP) When the SQL servers are patched the server fails over to the other IP address on a different subnet.

Right now SW is only polling one IP address (lets say its 169.0.0.1) . My question is can we add a dynamic IP address to the current SQL node (SQL_Node_1) so when one ip address fails it starts polling the other IP address?

Or is the best option to create a group that contains two nodes (SQL_Node_1 / 2 ) that are dependent on each other. Say node 2 doens't start pulling unitl node 1 goes done.

Current Node set up:

Name : SQL_Node_1

IP Polling : 169.0.0.1

Polling method: ICMP

Node was created using Dynamic query

Thank you for any help!

Find more posts tagged with

sql_cluster

npm

Accepted answers

All comments

stuartd

You don't mention if your SQL pair are in an HA setup but I'm guessing they are.

The answer for us was for our DBA's to create a SQL Listener, and then SW "talks" to the listener IP, not the individual servers.

adam.beedell

You can approach this in different ways.
Easiest is probably to monitor the AG in addition to the two sub servers, you can even use the hostname attribute to see which is active, kinda.

SteveK

For our clusters, we have a DNS alias for the active cluster, example would be: EnvA-SQLCluster. That cluster is made up of 2 nodes/hosts, say: EnvA-SQLNode1/EnvA-SQLNode2. The cluster name has its own IP, and Node1 and Node2 each have their own IP. Whatever host is active would also respond to the Cluster IP. I believe this is the setup @stuartd is talking about. I have not been on the SQL cluster build out side of things enough to be able to speak intelligently on that configuration.

So with our Cluster and each node having its own IP, now we can talk the SW side of things. In this scenario we would normally add 3 nodes to SolarWinds, each based off of the IP (or DNS if you have it, but you said you don't). For the Node1/Node2 system we configure those to alert off of CPU, Memory, Up/Down, etc... We also only monitor the C drive volume on these. On the Cluster node, we monitor all of the other volumes (excluding C). This is due to us having those volumes following the active node. We also have our SAM monitors for SQL associated to that node as well.

The benefit of this approach is we have our operations team, who are mainly incharge of the OS itself, able to receive alerts when a specific node is down. Then the DBA team who is responsible for all things SQL app stack would receive the alerts for the cluster status. We also branch out those secondary/application volumes to alert to the DBA first, since we request they double check the health and configuration before just throwing more storage at the issue.