Setup AG and Listener on WSFC MultiSubnet in different locations, getting error 19456

  • Here is the scenario:

    Trying to setup AlwaysOn Cluster with 3 subnets in it.  I do NOT intend to setup availability replicas in every subnet nor do I want to. I want to do the following

    Subnets are as below:

    FCI A = 10.222.10.xxx (2 nodes on same subnet)
    Instance B = 10.219.10.xxx (different node and subnet)
    Instance C = 10.225.10.xxx (different node and subnet)

    FCI instance A
    AOAG -> AG1 with secondary replica on Instance B  and primary on FCI A
    AG1 will NEVER have a secondary replica on Instance C

    So the million dollar question is: Why when I create an AG listener for AG1, do I have to create it on subnets for A,B and C if instance C is NOT going to be an availability replica for AG1???!?!?!?
    Clustered resources can be restricted with possible owners in the advanced options!  Shouldn't SQL create the AG listener only on the AG replicas and restrict the others out by possible owners?  I think even if I do this manually, SQL will NOT join the secondary into the AG unless the listener has subnets for EVERY node in the cluster.  Please confirm or tell me I am losing my mind and give me a reason why they went with this design.  Seems like a bug to me.

  • The ultimate goal here is to have another instance on subnet C which replicates to the same instance in subnet B ( B is our COLO for DR) I would like to maximize HW and licenses by using this shared model. Nodes in subnet A are all just for local HA installed as FCI just on two nodes. I fail to see why I have to reserve an IP for the AG listener for AG1 in subnet C if I have no secondary replicas in subnet C for AG1. Again am I missing something here?

  • nathanlbell - Tuesday, March 28, 2017 2:40 PM

    Here is the scenario:

    Trying to setup AlwaysOn Cluster with 3 subnets in it.  I do NOT intend to setup availability replicas in every subnet nor do I want to. I want to do the following

    Subnets are as below:

    FCI A = 10.222.10.xxx (2 nodes on same subnet)
    Instance B = 10.219.10.xxx (different node and subnet)
    Instance C = 10.225.10.xxx (different node and subnet)

    FCI instance A
    AOAG -> AG1 with secondary replica on Instance B  and primary on FCI A
    AG1 will NEVER have a secondary replica on Instance C

    So the million dollar question is: Why when I create an AG listener for AG1, do I have to create it on subnets for A,B and C if instance C is NOT going to be an availability replica for AG1???!?!?!?
    Clustered resources can be restricted with possible owners in the advanced options!  Shouldn't SQL create the AG listener only on the AG replicas and restrict the others out by possible owners?  I think even if I do this manually, SQL will NOT join the secondary into the AG unless the listener has subnets for EVERY node in the cluster.  Please confirm or tell me I am losing my mind and give me a reason why they went with this design.  Seems like a bug to me.

    do not touch the possible owners list on AG cluster resources, these are managed automatically.
    Subnet IPs are required for all replicas that participate in the AG.
    For more on multi subnet and listeners check this link

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • If you are setting up an availability group listener across multiple subnets and plan to use static IP addresses, you need to get the static IP address of every subnet that hosts an availability replica for the availability group for which you are creating the listener. Usually, you will need to ask your network administrators for the static IP addresses.

    This is NOT the behavior that I am experiencing.  When I try to add a listener to AG1 with primary replica in subnet A and secondary replica in subnet B, and just a joined node in subnet C,  SQL throws the error:

    Msg 19456, Level 16, State 0, Line 11

    None of the IP addresses configured for the availability group listener can be hosted by the server 'XXXXXXXXX'. Either configure a public cluster network on which one of the specified IP addresses can be hosted, or add another listener IP address which can be hosted on a public cluster network for this server.

    It is on the joined node in subnet C which currently does not even have a SQL instance on it. 

  • nathanlbell - Wednesday, March 29, 2017 7:01 AM

    If you are setting up an availability group listener across multiple subnets and plan to use static IP addresses, you need to get the static IP address of every subnet that hosts an availability replica for the availability group for which you are creating the listener. Usually, you will need to ask your network administrators for the static IP addresses.

    This is NOT the behavior that I am experiencing.  When I try to add a listener to AG1 with primary replica in subnet A and secondary replica in subnet B, and just a joined node in subnet C,  SQL throws the error:

    Msg 19456, Level 16, State 0, Line 11

    None of the IP addresses configured for the availability group listener can be hosted by the server 'XXXXXXXXX'. Either configure a public cluster network on which one of the specified IP addresses can be hosted, or add another listener IP address which can be hosted on a public cluster network for this server.

    It is on the joined node in subnet C which currently does not even have a SQL instance on it. 

    above you specify the following

    nathanlbell[hr[
    FCI A = 10.222.10.xxx (2 nodes on same subnet)
    Instance B = 10.219.10.xxx (different node and subnet)
    Instance C = 10.225.10.xxx (different node and subnet)

    You have an instance of sql server on node C, correct?

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply