Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

Combining AlwaysOn Groups With Failover Cluster Instances Expand / Collapse
Author
Message
Posted Wednesday, March 27, 2013 12:14 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:38 AM
Points: 6,416, Visits: 13,797
Marios Philippopoulos (3/26/2013)
I was reading an article that described a similar scenario of a single WSFC comprised of 2 FCIs

Could you provide the article link please


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

"Ya can't make an omelette without breaking just a few eggs"
Post #1435778
Posted Wednesday, March 27, 2013 3:31 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, September 25, 2014 1:51 PM
Points: 1,862, Visits: 3,608
Perry Whittle (3/27/2013)
Marios Philippopoulos (3/26/2013)
I was reading an article that described a similar scenario of a single WSFC comprised of 2 FCIs

Could you provide the article link please


Here it is:

AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using Failover Cluster Instances and Availability Groups
http://msdn.microsoft.com/en-us/library/jj215886

Here is the excerpt I am talking about:
"...
Instance Naming and File Path
The two FCIs must use different instance names within the same WSFC, for example, using “INST_A” as the instance name for the primary FCI and “INST_B” as the instance name for the DR FCI. (In contrast to availability groups, database mirroring permits each FCI to use the same instance name if the FCIs are on separate WSFCs. In Figure 1, both FCIs used the same the same instance name, INST_A, with the FCI+DBM solution).
..."


__________________________________________________________________________________

Turbocharge Your Database Maintenance With Service Broker: Part 2
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #1435807
Posted Friday, March 29, 2013 3:39 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:38 AM
Points: 6,416, Visits: 13,797
Marios Philippopoulos (3/26/2013)
Thank you for the article.

You're welcome.



Marios Philippopoulos (3/26/2013)
We are building a 3-node WSFC cluster that includes a 2-node FCI (active-passive configuration) coupled with a standalone AlwaysOn-AG instance on the 3rd node. Will we run into trouble if we name the instance the same on the FCI and AG nodes?

(I was reading an article that described a similar scenario of a single WSFC comprised of 2 FCIs on 2 different subnets; in that article they mention that instance names should be different; I'm not clear why).

Since all 3 nodes are part of the same cluster (they have to be for AO), you could potentially install the FCI to the 3rd node. Since instance names are unique within the cluster, this is why you need separate instance names. Incidentally why do you feel that having your live and DR instances named differently will cause you issues??


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

"Ya can't make an omelette without breaking just a few eggs"
Post #1436851
Posted Friday, March 29, 2013 9:24 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, September 25, 2014 1:51 PM
Points: 1,862, Visits: 3,608
Perry Whittle (3/29/2013)
Marios Philippopoulos (3/26/2013)
Thank you for the article.

You're welcome.



Marios Philippopoulos (3/26/2013)
We are building a 3-node WSFC cluster that includes a 2-node FCI (active-passive configuration) coupled with a standalone AlwaysOn-AG instance on the 3rd node. Will we run into trouble if we name the instance the same on the FCI and AG nodes?

(I was reading an article that described a similar scenario of a single WSFC comprised of 2 FCIs on 2 different subnets; in that article they mention that instance names should be different; I'm not clear why).

Since all 3 nodes are part of the same cluster (they have to be for AO), you could potentially install the FCI to the 3rd node. Since instance names are unique within the cluster, this is why you need separate instance names. Incidentally why do you feel that having your live and DR instances named differently will cause you issues??


__________________________________________________________________________________

Turbocharge Your Database Maintenance With Service Broker: Part 2
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #1437173
Posted Friday, March 29, 2013 9:51 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, September 25, 2014 1:51 PM
Points: 1,862, Visits: 3,608
We are using a DNS alias for the virtual network name (VNN) of the sql instance on the FCI cluster to direct connectivity of our applications to the prod instance.

Say the VNN is PRODSQLVS01 and the instance name is INST01. We can then connect to PRODSQLVS01\INST01 to get to the FCI instance hosted in nodes 1 or 2. If the DNS alias of the above VNN is BATMAN, then connecting to BATMAN\INST01 accomplishes the same thing. In the event of a disaster in the primary data center hosting nodes 1 and 2, we will then simply point the DNS alias to node 3, the DR node. Our applications will not "know" which server this is, as long as using BATMAN\INST01 will get them connected. But this plan will fail if the SQL instance on node 3 is not also named INST01.

I know the AG listener is the proper way to address this DR scenario, but we will not be able to implement a listener until all our apps are upgraded to .net 4.0.

I was recently able to implement availability groups on a multi-node cluster lab environment using the same instance name for the same AG on multiple nodes with no issues. In that setup I had no FCIs, just standalone instances. I don't see how the requirement for different instance names on different nodes fits into all this.


__________________________________________________________________________________

Turbocharge Your Database Maintenance With Service Broker: Part 2
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #1437176
Posted Tuesday, May 14, 2013 5:58 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 1:03 AM
Points: 7, Visits: 760
how would you approach it if you need to install as follow:

Prod site: FCI over 2 nodes
DR: FCI over 2 (or single) nodes
AlwaysOn between the two FCIs

So all 3 (or 4) nodes must be part of same WSFC. what if the were both already running prior to your AlwaysOn plans, how do you 'combine' the two separate WSFCs then ?

then with shared storage, each FCI set has shared storage only between then, not between sites. how would you set this up in Cluster Manger / how do you validate the cluster and tell it to validate the storage only between 2 Prod nodes, and also validate the storage for the 2x DR nodes only, if all 4 nodes are in the same cluster now?
Post #1452888
Posted Friday, May 24, 2013 11:57 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 6:18 AM
Points: 2, Visits: 109
...tell it to validate the storage only between 2 Prod nodes, and also validate the storage for the 2x DR nodes only, if all 4 nodes are in the same cluster now?

That's what I am struggling with now in my virtual lab,
node1 > storage1
node2 > storage1
works like charm, then I've added
node3, node4, and I want to add storage only for node3 and node4, and there configure second WFC, and later run AO between them

my final idea is
node1,node2 : same dc1, part of 4node metro cluster, hosting SQL FCI "DC1SQL"
node3,node4 : same dc2, part of 4node metro cluster, hosting SQL FCI "DC2SQL"
AO from DC1SQL to DC2SQL
seems impossible...
Post #1456639
Posted Friday, May 24, 2013 5:57 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 1:03 AM
Points: 7, Visits: 760
salkasalka (5/24/2013)


node3, node4, and I want to add storage only for node3 and node4, and there configure second WFC, and later run AO between them

my final idea is
node1,node2 : same dc1, part of 4node metro cluster, hosting SQL FCI "DC1SQL"
node3,node4 : same dc2, part of 4node metro cluster, hosting SQL FCI "DC2SQL"
AO from DC1SQL to DC2SQL
seems impossible...


I got mine to work in the end, as follow:

* all nodes HAVE to be the same WSFC (as per documentation). cannot add a node into a WSFC if its already part of another.

* no magical 'merging' of 2x separate WSFCs

* pre-validate your 2x DC1 nodes, including storage. then pre-validate your 2x DC2 nodes, including storage. when all good, then create your 4x node cluster, and run validation, excluding storage.

* from there its just a matter of setting possible-owners on resources

* your 2x FCIs should have the same drive letters and paths to make AO easier to manage. bringing them into the same WSFC is not a problem, but while they are under the Available Storage default resource group you can obviously not assign the same drive letter twice. So at this stage you create your Roles in the WSFC, one for each FCI. First you bring all the Available Storage online, say on node1. half of them will stay offline, because they can physically only connect to node3 & 4. you create your Role and assign those disks to the new role. This takes them out of Available Storage, so you can re-use drive letters again before creating your Role2, for your FCI2

* now you have 2 Roles/Resource groups ready, so during install of Clustered SQL you just select this pre-staged Role.

* when both FCIs are installed, make sure possible-owners are all correct on all resources. (AG group create will actually fail/warn if some is incorrect)

* create AG & Listener and you're good to go!
Post #1456741
Posted Saturday, May 25, 2013 1:05 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 6:18 AM
Points: 2, Visits: 109
it's working, thank you! :) great help was also that MS whitepaper (link provided by Marios Philippopoulos)
Post #1456768
Posted Saturday, May 25, 2013 6:22 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, September 25, 2014 1:51 PM
Points: 1,862, Visits: 3,608
Hey all, thanks for the feedback.

I ended up opening a case with Microsoft, asking them about the requirement for different instance names. After some back and forth, Microsoft has confirmed that the requirement for different instance names does indeed apply in the scenario of 2 Failover-Cluster Instances (FCIs) on 2 different subnets, as part of the same WSFC cluster.

In my case - one FCI on subnet1 and one standalone instance on subnet2 - the instance names can be the same;
Microsoft supports this configuration.

I hit a couple of snags, however, while configuring this setup:

(1) While installing the SQL standalone instance on subnet2 I got this error:
The directory d:\xxxxxxxxx\xxxxx is not a valid path. Standalone sql server on wfc cluster cannot have files on shared disk locations

The remedy for this was to evict that node from the WSFC cluster, do the SQL install, and add it back:
http://social.msdn.microsoft.com/Forums/en-US/sqlsetupandupgrade/thread/479792d7-f9ce-4033-af6a-37901b5d8fd9/

(2) Error while creating the Availability Group:
Failed to create, join or add replica to availability group 'MYAG1', because node 'MyNode3' is a possible owner for both replica 'SRVS1\Instance1' and 'SRVPH1\Instance1'. If one replica is failover cluster instance, remove the overlapped node from its possible owners and try again.

The cure here was to go to Failover Cluster Manager and unselect the 3rd node, SRVPH1, (where the standalone SQL instance was located) from the list of possible owners of the FCI.


__________________________________________________________________________________

Turbocharge Your Database Maintenance With Service Broker: Part 2
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #1456782
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse