Windows – SQL 2012 Availability Group issue – The core cluster resources do not move when we initiate AG fail-over

This is easiest to explain if you think about having multiple Availability Groups in your environment rather than just one. Each AG listener would have its own name and IP, and it could be failed over independently to either physical node.

In that environment, there are a few different parts:

• The physical nodes - each of which has its own IP address
• Each Availability Group listener - each of which has its own virtual name and address, and fails over back and forth between the nodes depending on who owns that particular Availability Group at that moment in time
• The cluster's management point - which also has its own virtual name and address, and can be different than the AG listener.

See, one of the nodes has to own the cluster. This becomes more and more important as your cluster grows out - for example, to multiple physical nodes rather than just two. That cluster manager keeps control of the cluster's state, which nodes own which moving parts, and so on.

All Windows clusters - even a simple 2-node, 1-AG setup - have this separate name and IP address for management. Most of the time, it doesn't matter who owns the cluster, but in a multi-node cluster (say, 3 nodes in your primary data center and 2 nodes in your disaster recovery data center) where you want to get down to last-man-standing as things fail, then it does start to matter.

Yes AG support multiple subnets as described here. Also make sure that your data provider supports MultiSubnetFailover .. .NET Framework 4 supports it.

To answer your question ...

IF you use .NET framework 4 or 3.5 then the provider will support it as described here.

Also, a good reference to SQL Server Multi-Subnet Clustering is well documented.

With legacy client libraries or third party data providers, you cannot use the MultiSubnetFailover parameter in your connection string. To help ensure that your client application works optimally with multi-subnet FCI in SQL Server 2012, try to adjust the connection timeout in the client connection string by 21 seconds for each additional IP address. This ensures that the client’s reconnection attempt does not timeout before it is able to cycle through all IP addresses in your multi-subnet FCI.