When adding the cluster IPs under Access Point for Administering the Cluster, do we only include IPs for the public subnets, or do we also need to include an IP for the private subnet(s)? This cluster will be used for a three-node multi-subnet AlwaysOn Availability Group. As for the listener, I know it needs to include all of the public subnets, but I'm not sure how the cluster core resources should be configured.


Please see No such thing as a Heartbeat Network and Everything You Know About Clustering is Wrong. These don't really answer your question, but perhaps will change the question to, "Do we need a heartbeat network?"

With Windows 2008 and later, a heartbeat network is not required, and it's really only going to benefit if your "public" network gets so saturated that cluster communications are delayed, in which case the "heartbeat" network may stop a failover from occurring (ref. Shanky's comment below). This was a nice safeguard that made more sense in the days of 10/100 Mbs networks, and although it's certainly possible to saturate a 10 Gps link, it's far less likely. I.e., if you anticipate having major issues with your public network, then a private network might ease some of the pain, but you'll still need to address the public network issues to cure the disease.

Additionally, the use of file witness and majority node quorum features additionally reduces the need for a private network for cluster stability. Many clusters for availability groups now span geographic regions where it doesn't make sense to bridge your network just for the purpose of putting the DR node on the same subnet. Again--if it added a huge amount of value, it might make sense, but the benefit just isn't there.

The monitoring built-in to availability groups can initiate failover even if the cluster doesn't detect any problem, and I don't think it would care about a private network as it would only care about the route it is using for replication. Hopefully someone can post a reference to how AGs might benefit, or not, from a private network in different scenarios, but I'm guessing that it doesn't exist because the private network has not been required for 10 years now.

If you think that the replication of the database will put significant load on the public network, you can use a private network for the replication by setting the endpoints to the private addresses. See Configuring a Dedicated Network for SQL Server Always On Availability Groups Data Replication Traffic. Yes, I know there is a link in the article to a previous article advocating a private network. My point is that if your public network is so bad that you need a private network, you are probably going to have a lot of failovers and other issues. It's like buying insurance for a leaky boat--great, you've got insurance, but the boat is still going to sink.

  • a heartbeat network is not required, that is correct. And it really doesn't benefit to have one, well that is bit debatable there are few scenarios where heartbeat may actually be useful. Please see Is it safe to run a Windows Failover Cluster Public and Heartbeat on a Single NIC?
    – Shanky
    Dec 7 '18 at 11:37
  • Thanks a lot for the important suggestions. Now i understand the concept. Thanks again. Dec 7 '18 at 14:11
  • @user9394033 This question could be the basis for a lot of research and a small book, but reality dictates that network issues and clusters = unhappiness, regardless of whether there's a private network. Dec 7 '18 at 14:18
  • As long as there is no other HADR alternative we will have to live with it i guess...makes life more tough for new comers like me... Dec 7 '18 at 16:05
  • Also with Windows Server 2016+ you can ensure that the cluster does not lose quorum if it is unable to connect to the other nodes. See docs.microsoft.com/en-us/windows-server/storage/storage-spaces/… Dec 7 '18 at 16:28

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.