2

We have WSFC with 4 nodes + a file share witness.

Only nodes 1-3 have SQL server on it with Availability Groups (AGs), and node 4 is shut down gracefully.

Node 1 has the primary AAG server.

Now, we recently had an uncontrollable outage for which the only thing we know for certain is that nodes 1 and 2 were together with power supply and network, but nodes 3-4, and the witness, were cut off - but probably still up.

Since the power supply renewed, WSFC is showing results that I don't understand:

  • Current host server is Node 3;
  • In Cluster Core Resources, IP addresses that belong to nodes 1 and 2, are shown as down;
  • In Nodes section, nodes 1-3 are shown as up, and node 4 down (as expected);

BUT: The primary AG server is still on node 1 as it was before, and it accepts read/write connections as usually.

This make me doubt if I understand correctly how WSFC and AGs work together.

  1. Should not the current WSFC host also be the primary AG server?
  2. How does the listener work? In our case, we have multi-subnet networking, and the listener's DNS name always resolves to 3 IP addresses among which one belongs to the current primary AG server, and works for connections. Does WSFC determine the listener's addresses?
  3. Is there any other principle (except quorum) that AG depends on WSFC?

Thanks.

1 Answer 1

3

Should not the current WSFC host also be the primary AG server?

No. The hosting of the core cluster resources is independent of the AG primary. Generally speaking, it's not super important which server is the WSFC host when dealing with a WSFC cluster for SQL Server Availability Groups.

How does the listener work? In our case, we have multi-subnet networking, and the listener's DNS name always resolves to 3 IP addresses among which one belongs to the current primary AG server, and works for connections. Does WSFC determine the listener's addresses?

This part mostly happens on the client that's connecting to SQL Server. The client gets that same list of IPs from DNS, and then tries each of them until one succeeds. The current primary server will respond and either accept the connection or redirect the client to another server in the cluster (depending on connection settings and other config like read-only routing).

Is there any other principle (except quorum) that AG depends on WSFC?

There's a neat breakdown on this in the docs as well: Relationship of SQL Server AlwaysOn Components to WSFC

In general though, the concept of quorum (which I'll take to be a part of the larger health monitoring / failover concept) is the most relevant one for WSFC and AGs.

2
  • 1
    And just to add on the first answer, you can have some AGs being primary on one node of the Cluster while some other AGs will be primary on another node. This prove that the AGs are not linked to the WSFC. If you keep node 4 downs, make sure your Voting configuration is done correctly. You do not want node 4 to have a vote if that server is always down. Actually, I think a good approch is only to give a vote to node that can have an automatic failover on them (if your node 3 is in another site, in asynchro, I would not give it a vote). See cluster configuration best practice for more info. Mar 6, 2020 at 18:53
  • Thanks for both answers. Mar 8, 2020 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.