FCI + Always On

  • Hi,

    I want to setup a 3 nodes solutions. NODE_A, NODE_B and NODE_C are part of the same WSFC.

    Node_A -> Contains the SQL Server Role, with the sql server clustered instance and its resources
    Node_B-> SQL Server role can be failover to Node_B using WSFC.
    Node_C-> This node contains another SQL server Instance , and is configured with AlwaysON AG as the target for the primary instances on nodes NODE_A and NODE_B

    With that configuration , I can connect to SQL Server using the AlwaysOn Listener.
    When I do a maual failover from primary Instance to the AlwaysOn Instance, I can connect to SQL Server using the AlwaysOn Listener.
    When I do a manual failover from SQL Server Role from Node_a to Node_b, I can not connect to SQL Server using the AlwaysOn Listener.

    Am I missing something?

    Regards

  • Just to be clear NODE A and Node B are set up as an FCI with Node B being Passive.
    Node C is the secondary replica of the Instance running on either NODE A or Node B.

    The answer to your questions is YES.

    If SQL SERVER Is either running on the Primary Node A or Node B. Then the listener can be used.
    If the AG is failed over to NODE C. Then the LISTENER can still be used.

  • The node operating as the (AG),PRIMARY will be the node that the LISTENER will connect to.

  • Super Cat - Monday, December 18, 2017 4:04 AM

    The node operating as the (AG),PRIMARY will be the node that the LISTENER will connect to.

    Super Cat - Monday, December 18, 2017 3:28 AM

    Just to be clear NODE A and Node B are set up as an FCI with Node B being Passive.
    Node C is the secondary replica of the Instance running on either NODE A or Node B.

    The answer to your questions is YES.

    If SQL SERVER Is either running on the Primary Node A or Node B. Then the listener can be used.
    If the AG is failed over to NODE C. Then the LISTENER can still be used.

    Ok, so something is wrong with my configuration because I can not connect through my listener when failover is performed manually from node_a to node_b

    Here you can see my problem   https://youtu.be/r5A5f5NtW1Y
    In the minute 02:10 I move my FCI from node_a to node_b

  • crcoracle - Saturday, December 16, 2017 5:23 AM

    When I do a manual failover from SQL Server Role from Node_a to Node_b, I can not connect to SQL Server using the AlwaysOn Listener.

    Am I missing something?

    Regards

    What is the status of the listener IP and name resources in the cluster role, after this failover?

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

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

  • select * from sys.dm_hadr_availability_replica_cluster_states

    I would expect to see Joined_FCI  for NODE A and B in column Join State Desc
    and 
    Joined_STANDALONE for NODE C

    select * from sys.dm_tcp_listener_states

    Does the Dashboard show any errors.?

  • crcoracle - Monday, December 18, 2017 4:53 AM

    Super Cat - Monday, December 18, 2017 4:04 AM

    The node operating as the (AG),PRIMARY will be the node that the LISTENER will connect to.

    Super Cat - Monday, December 18, 2017 3:28 AM

    Just to be clear NODE A and Node B are set up as an FCI with Node B being Passive.
    Node C is the secondary replica of the Instance running on either NODE A or Node B.

    The answer to your questions is YES.

    If SQL SERVER Is either running on the Primary Node A or Node B. Then the listener can be used.
    If the AG is failed over to NODE C. Then the LISTENER can still be used.

    Ok, so something is wrong with my configuration because I can not connect through my listener when failover is performed manually from node_a to node_b

    Here you can see my problem   https://youtu.be/r5A5f5NtW1Y
    In the minute 02:10 I move my FCI from node_a to node_b

    Please review my stairway to AlwaysOn starting at the following link

    http://www.sqlservercentral.com/stairway/112556/

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

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

  • Perry Whittle - Monday, December 18, 2017 5:56 AM

    crcoracle - Saturday, December 16, 2017 5:23 AM

    When I do a manual failover from SQL Server Role from Node_a to Node_b, I can not connect to SQL Server using the AlwaysOn Listener.

    Am I missing something?

    Regards

    What is the status of the listener IP and name resources in the cluster role, after this failover?

    Listener and name resources of the Listener Role are UP in node_a after failover SQL Server role to node_b

  • Super Cat - Monday, December 18, 2017 6:36 AM

    select * from sys.dm_hadr_availability_replica_cluster_states

    I would expect to see Joined_FCI  for NODE A and B in column Join State Desc
    and 
    Joined_STANDALONE for NODE C

    select * from sys.dm_tcp_listener_states

    Does the Dashboard show any errors.?

    select * from sys.dm_hadr_availability_replica_cluster_states

    28C14CED-0282-44B1-8111-12D10A53E5C4    CLSQL2K16REP\AONCLSPRO    8E3CAF1B-AFC7-444F-B76C-A76EFA37D11E    1    JOINED_STANDALONE
    D650F444-FF2A-4070-A9D1-2C3A52191644    CLSQL2K16S2\PROINTERNA    8E3CAF1B-AFC7-444F-B76C-A76EFA37D11E    2    JOINED_FCI

    select * from sys.dm_tcp_listener_states (I have another AG with another listener)

    6    ::    0    5022    2    DATABASE_MIRRORING    0    ONLINE    2017-12-14 10:19:50.807
    7    0.0.0.0    1    5022    2    DATABASE_MIRRORING    0    ONLINE    2017-12-14 10:19:50.807
    3    ::1    0    53433    0    TSQL    0    ONLINE    2017-12-14 10:19:50.020
    4    127.0.0.1    1    53433    0    TSQL    0    ONLINE    2017-12-14 10:19:50.020
    1    ::    0    53432    0    TSQL    0    ONLINE    2017-12-14 10:19:50.013
    2    0.0.0.0    1    53432    0    TSQL    0    ONLINE    2017-12-14 10:19:50.017

    Dashboard says:
    This secondary replica is not connected to the primary replica. The connected state is DISCONNECTED.

  • what does a cluster validation report show?

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

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

  • When theSQL fail over clustered instance is failed over from node a to node b, primary DB comes "Resolving"

  • Perry Whittle - Monday, December 18, 2017 10:29 AM

    what does a cluster validation report show?

    ?

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

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

  • crcoracle - Monday, December 18, 2017 4:53 AM

    Super Cat - Monday, December 18, 2017 4:04 AM

    The node operating as the (AG),PRIMARY will be the node that the LISTENER will connect to.

    Super Cat - Monday, December 18, 2017 3:28 AM

    Just to be clear NODE A and Node B are set up as an FCI with Node B being Passive.
    Node C is the secondary replica of the Instance running on either NODE A or Node B.

    The answer to your questions is YES.

    If SQL SERVER Is either running on the Primary Node A or Node B. Then the listener can be used.
    If the AG is failed over to NODE C. Then the LISTENER can still be used.

    Ok, so something is wrong with my configuration because I can not connect through my listener when failover is performed manually from node_a to node_b

    Here you can see my problem   https://youtu.be/r5A5f5NtW1Y
    In the minute 02:10 I move my FCI from node_a to node_b

    crcoracle you cannot use cluster manager to move nodes as you showed in the video at 2:10.
    You must always use SSMS to failover. 

    Restrictions on Using The WSFC Failover Cluster Manager with Availability Groups

    Do not use the Failover Cluster Manager to manipulate availability groups, for example:

    • Do not add or remove resources in the clustered service (resource group) for the availability group.
    • Do not change any availability group properties, such as the possible owners and preferred owners. These properties are set automatically by the availability group.
    • Do not use the Failover Cluster Manager to move availability groups to different nodes or to fail over availability groups. The Failover Cluster Manager is not aware of the synchronization status of the availability replicas, and doing so can lead to extended downtime. You must use Transact-SQL or SQL Server Management Studio.

    Alex S

Viewing 13 posts - 1 through 12 (of 12 total)

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