Setup AlwaysOn on existing SQL 2012 Cluster

  • Hello,

    We have an existing SQL Server 2012 Enterprise cluster with 2 nodes (active-active) and uses Windows 2008 R2 OS. We are looking for a way to increase HA as well as offload backups to secondary server and it was suggested that AlwayOn could be an option.

    The questions I have are:

    1) Is it possible to turn on AalwaysOn feature on an existing cluster?

    2) If yes to above, does the secondary replica need to exist as a node on the same cluster or can it be on a completely different cluster?

    3) If the secondary replica is on the same cluster (i.e. we add a 3rd node to existing 2 node cluster), can that node be provisioned with storage from a completely different SAN? (i.e. Node 1 and Node 2 accesses LUNs on SAN1 and Node 3 accesses LUNs on SAN2).

    Any help would be much appreciated.

    Thank you!

  • feersum_endjinn (5/19/2015)


    Hello,

    We have an existing SQL Server 2012 Enterprise cluster with 2 nodes (active-active) and uses Windows 2008 R2 OS. We are looking for a way to increase HA as well as offload backups to secondary server and it was suggested that AlwayOn could be an option.

    If I read it correct from above, you have a 2 node cluster with 2 failover cluster instances running, one on each node, is this correct?

    feersum_endjinn (5/19/2015)


    1) Is it possible to turn on AalwaysOn feature on an existing cluster?

    If the instances are a minimum of SQL server 2012 Enterprise edition and they are part of a Windows Server Failover Cluster then you may enable the AlwaysOn availability feature.

    feersum_endjinn (5/19/2015)


    2) If yes to above, does the secondary replica need to exist as a node on the same cluster or can it be on a completely different cluster?

    All replicas in an AlwaysOn availability group must be part of the same WSFC. You may straddle a group across repliacs in different clusters but only as a temporary solution for a migration. Cluster objects cannot fail across clusters as clusters are not federated.

    feersum_endjinn (5/19/2015)


    3) If the secondary replica is on the same cluster (i.e. we add a 3rd node to existing 2 node cluster), can that node be provisioned with storage from a completely different SAN? (i.e. Node 1 and Node 2 accesses LUNs on SAN1 and Node 3 accesses LUNs on SAN2).

    Any help would be much appreciated.

    Thank you!

    In an ideal world your AlwaysOn availability group replicas will be standalone instances and will not use shared storage at all. Presenting shared LUNs is only required for FCI deployments.

    Read through my stairway to alwayson starting at this link[/url].

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

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

  • Hi Perry,

    Thank you very much indeed for your reply. And yes, I’m already on level 1 of the stairway (coincidentally while listening to Zeppelin!).

    To answer your first question – yes, it’s two FCI’s, one on each node. The nodes are not equally resourced in terms of hardware. With regards to AlwaysOn, we are only concerned about one of the FCI’s.

    I understand your replies to 1 and 2 but I’m not sure if I understand your reply to Q3.

    In my current setup – FCI instance 1 (let’s called SQL-CL-01) has exclusive, direct access to LUN’s on a SAN. Any secondary replicas (i.e. new WSFC nodes) will also have exclusive access to LUN’s on a second SAN.

    So, if I understand correctly, I would now add a third node (Node-3), but this node will only be a member of WFCS. It will not be a member of SQL-CL-01. Instead Node-3 will have its own standalone instance of SQL. And this instance will be a secondary replica.

    Forgive me for asking this Windows Server administration question – but does WSFC allow you to add nodes (years!) after initial configuration and setup?

    Thanks again for your help!

  • feersum_endjinn (5/19/2015)


    I understand your replies to 1 and 2 but I’m not sure if I understand your reply to Q3.

    In my current setup – FCI instance 1 (let’s called SQL-CL-01) has exclusive, direct access to LUN’s on a SAN. Any secondary replicas (i.e. new WSFC nodes) will also have exclusive access to LUN’s on a second SAN.

    Are the existing cluster nodes servicing the FCIs on separate sites with SAN to SAN replication?

    feersum_endjinn (5/19/2015)


    So, if I understand correctly, I would now add a third node (Node-3), but this node will only be a member of WFCS. It will not be a member of SQL-CL-01. Instead Node-3 will have its own standalone instance of SQL. And this instance will be a secondary replica.

    Yes, that's correct. The storage can be presented from anywhere, local or networked, but for networked would only be zoned for the single server it is to service.

    feersum_endjinn (5/19/2015)


    Forgive me for asking this Windows Server administration question – but does WSFC allow you to add nodes (years!) after initial configuration and setup?

    Thanks again for your help!

    You can add or remove nodes at any time

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

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

  • Nope, there will be no SAN to SAN replication. The reason why I mentioned separate SAN's was because I wasn't sure if WSFC supported having nodes that accessed non-shared disks. But now I understand that this is supported and it's in fact desirable to have anyway.

  • feersum_endjinn (5/19/2015)


    Nope, there will be no SAN to SAN replication. The reason why I mentioned separate SAN's was because I wasn't sure if WSFC supported having nodes that accessed non-shared disks. But now I understand that this is supported and it's in fact desirable to have anyway.

    I think you may be misunderstanding what I'm saying. What I'm asking is are the current cluster nodes on separate sites and is there any san to san replication which would be typical in a cluster where the nodes are geographically dispersed. For instance

    Site A is in Tokyo, Japan

    Site B is in New York, USA

    Site A has cluster node A and its shared storage is on SAN A

    Site B has cluster node B and its shared storage is on SAN B

    Cluster node A has instance A which is active, the LUNs on SAN A are replicated at block level to SAN B, where the resources are inactive.

    Upon failover of the clustered instance A, SAN B is brought online and the clustered instance A starts on Cluster node B

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

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

  • feersum_endjinn (5/19/2015)


    But now I understand that this is supported and it's in fact desirable to have anyway.

    Ideally, no it's not. You don't want shared replicated storage. It's expensive, requires maintenance and is complex.

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

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

  • No, the cluster nodes are (rather will be) located in the same data centre, same room, same VM hosts. Only difference is that Node-1 and Node-2 are members of a SQL FCI and LUN's are provisioned from one SAN. Node-3 will (after posting here I have figured out) be a standalone instance with storage provisioned from a separate SAN also located on the same premises.

  • Would like to do a POC using one of the cloud based service providers but it sounds like most of them don't provide out-of-the-box WSFC's. Even Azure. 🙁

  • feersum_endjinn (5/21/2015)


    No, the cluster nodes are (rather will be) located in the same data centre, same room, same VM hosts.

    Ok, got it

    feersum_endjinn (5/21/2015)


    Only difference is that Node-1 and Node-2 are members of a SQL FCI and LUN's are provisioned from one SAN.

    Perfectly acceptable

    feersum_endjinn (5/21/2015)


    Node-3 will (after posting here I have figured out) be a standalone instance with storage provisioned from a separate SAN also located on the same premises.

    Doesn't matter whether its local or a SAN, the key is this storage is not in any way available to the remaining cluster nodes.

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

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

Viewing 10 posts - 1 through 9 (of 9 total)

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