June 17, 2015 at 4:11 am
What I asked for: Three Windows Server 2012 R2 machines with independent storage running a SQL Server 2014 AlwaysOn Availability Group. DB1 would be the primary, DB2 would be a synchronous replica, and DB3 would be a remote asynchronous replica.
What I was given: a two-node Windows Server 2012 R2 WSFC to run SQL Server 2014 Enterprise with shared storage and a third (remote) Windows Server 2012 R2 machine with independent storage, also with SQL Server 2014 Enterprise, to host an AlwaysOn Availability Groups asynchronous replica. DB1 and DB2 (as Cluster1) share an E: drive. The remote DB3 has its own E: drive. Initially, DB3’s E: drive was claimed as a cluster resource and I couldn’t even see it. I’ve had several ugly days trying to make this work and have temporarily given up, installing DB3 as a standalone SQL Server that is no longer part of the WSFC and pointing everything towards that (it was originally a third node in the WSFC).
So this is my question (I’m not even sure I’m asking it right): Is it possible to create an AlwaysOn Availability Group with nested clusters (i.e. create the AOAG with Cluster1 and DB3 and somehow ignore the individual nodes that comprise Cluster1)? Am I just thinking about this wrong?
TIA!
June 17, 2015 at 2:39 pm
Yes and no. You can create an AlwaysOn Availability Group where one of the replicas is a cluster (they refer to it as AlwaysOn Failover Cluster Instance (FCI)). So in this scenario you would have one replica hosted on the FCI and a secondary on the stand-alone instance.
The bad news is that the stand-alone instance still has to be a member of the WSFC. Availability Groups are managed by the WSFC and it is a requirement for AlwaysOn that any instance to be setup for AlwaysOn be configured as a member of the WSFC.
Joie Andrew
"Since 1982"
June 18, 2015 at 4:09 am
alex_pixley (6/17/2015)
What I was given: a two-node Windows Server 2012 R2 WSFC to run SQL Server 2014 Enterprise with shared storage and a third (remote) Windows Server 2012 R2 machine with independent storage, also with SQL Server 2014 Enterprise, to host an AlwaysOn Availability Groups asynchronous replica. DB1 and DB2 (as Cluster1) share an E: drive. The remote DB3 has its own E: drive. Initially, DB3’s E: drive was claimed as a cluster resource and I couldn’t even see it.
This is an incorrect configuration for an AlwaysOn Availability group configuration. All nodes, whether hosting an FCI or standalone instance, must be part of the same WSFC.
Please see my stairway to HA on this site starting at this link
http://www.sqlservercentral.com/articles/Failover+Clustered+Instance+(FCI)/107536/[/url]
Any drive assignments used for an FCI are claimed within the whole cluster, the standalone installer checks any paths. There is a work around some have found, this is to evict the node from the cluster, install stand alone instance and then join back to the cluster.
I'm fairly sure this is not supported though, what if you ever tried to install the FCI on the node where the stand alone instance was installed??
alex_pixley (6/17/2015)
I’ve had several ugly days trying to make this work and have temporarily given up, installing DB3 as a standalone SQL Server that is no longer part of the WSFC and pointing everything towards that (it was originally a third node in the WSFC).
It will never work in this configuration, you won't be able to enable the standalone instance for AlwaysOn when the node is not part of a WSFC.
alex_pixley (6/17/2015)
So this is my question (I’m not even sure I’m asking it right): Is it possible to create an AlwaysOn Availability Group with nested clusters (i.e. create the AOAG with Cluster1 and DB3 and somehow ignore the individual nodes that comprise Cluster1)? Am I just thinking about this wrong?TIA!
The FCI is added as a replica to the AlwaysOn group along with DB3 as a partner replica. It still doesn't match your intended design though, is that an issue for you?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
June 18, 2015 at 6:54 am
Perry Whittle (6/18/2015)
...It will never work in this configuration, you won't be able to enable the standalone instance for AlwaysOn when the node is not part of a WSFC.
It will never work in this configuration, you won't be able to enable the standalone instance for AlwaysOn when the node is not part of the WSFC.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
June 18, 2015 at 8:32 am
thank you Johan for the correction 😉
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
June 18, 2015 at 8:39 am
As you know with AlwaysOn it's the little things that really matter.
Don't just set it up, but test it to the max before you go live.
And that includes Backup and Recovery scenario's.
If it bites, it bites hard
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
June 18, 2015 at 12:05 pm
Perry Whittle (6/18/2015)
This is an incorrect configuration for an AlwaysOn Availability group configuration. All nodes, whether hosting an FCI or standalone instance, must be part of the same WSFC.
I actually knew this, but removing it from the WSFC was an act of desperation. Now that you've confirmed that this is a workable (if difficult) configuration, I'll set my nose back to the grindstone.
Perry Whittle (6/18/2015)
Please see my stairway to HA on this site starting at this linkhttp://www.sqlservercentral.com/articles/Failover+Clustered+Instance+(FCI)/107536/[/url]
Thank you so much for this link. It clarifies many of the holes in my previous understanding.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply