6 martie 2012 21:21
I have successfully implemented a cluster SQL Server 2012 in our primary site and was planning to implement a node in secondary site to configure DR solution, however due to technical harware limitations, I was not able to attach the same storage in primary site to secondary site system. So I changed my plan to build another seperate cluster in secondary site to enable "High-Availability groups" option.
My question is : If I have two different clusters (can be configured with same AD account), can I configure availability groups?
Venugopal Saride MCITP - SQL Server 2008 Please click "Mark as Answer" if the post solves your problem - Thanks
7 martie 2012 01:48Moderator
>>If I have two different clusters (can be configured with same AD account), can I configure availability groups?TechNet Subscriber Support
It is available to configure the AlwaysOn Availability Groups among SQL Server clustered instances. However, all of them should be in the same domain. For each SQL Server clustered instance, it can just be treated as a stand along instance.
If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.
TechNet Community Support
- Marcat ca răspuns de Venugopal Saride 8 martie 2012 18:04
5 aprilie 2012 06:24
the following Microsoft whitepaper and SQL 2012 BOL state that all AlwaysOn DR replicas must be on the *same* cluster.
page 11 (I quote)
That the Windows Server Failover Clustering
(WSFC) service is integral to AlwaysOn Failover Cluster Instances is not new.
When you implement FCIs for high availability and database mirroring for
disaster recovery, you have two FCIs that reside in two WSFC clusters, one on
the primary site and one on the remote site.
When you use an availability group
for disaster recovery, however, the availability group requires all replicas to
be in the same WSFC cluster.
Here is SQL 2012 BOL quote:
Restrictions (Availability Groups)Availability replicas must be hosted by different nodes of
one WSFC cluster: For a given availability group, availability replicas
must be hosted by server instances running on different nodes of the same WSFC
something is amiss.... I dont understand the restriction.
can someone provide an official Microsoft *supported* answer - can we use AlwaysOn availability groups in DR in multi-sites scenarios, in SQL 2012 RTM, to replicate the databases between multiple *different* local clusters?
If yes, please provide some level of detail how this could be implemented.
- Editat de Yuri Budilov 5 aprilie 2012 06:39 adding from BOL
8 aprilie 2012 02:30This is something that I could initially wrap my head around. I tried doing what the OP described and was not successful. I was only able to use AlwaysOn with all nodes belonging to the same cluster. The AlwaysOn Wizard will not let you continue if the servers are in different clusters. Going by the launch event that I attended, AlwaysOn uses the clustering service and is not managed by SQL Server exclusively, therefore it's not technically possible.
13 aprilie 2012 01:37
I had this confirmed by Microsoft. To use SQL 2012 AlwaysOn for DR on multiple-sites *all replicas* must belong to the same Windows cluster i.e. a geo-cluster/stretched-cluster is required even though it does not need to use shared storage.
IMHO, IME, soapbox alert 8^)
Personally, I see this design/requirement as a major barrier for entry for many customers.
Previously, any SQL 2008 R1/R2 customer could just simply mirror their database (synch or asynch) from any db server to any server on any site (or same site) - clustered and non-clustered. It just worked. Simple. Likewise with Log Shipping too.
Note: Oracle 11g R2 E/E customers can also mirror (via Active Data Guard or plain Data Guard) any database from any server to any server. No (RAC) clustering is required for DR. Also relatively simple although not as easy as SQL Server 2008 DB Mirroring but I digress...
Now, in SQL 2012 - no so! The whole AlwaysOn DR process now requires a lot of up-front design, planning and co-ordination and it now requires the DBA team and infrastructure team (OS + storage teams) to play on the same side. In my experience this is often NOT the case. Add to that that I can no longer replicate those additional copies of databases to another cluster - all 5 copies must belong to same one cluster.
Now we add the additional multi-site Windows cluster management complexity (compared to local clusters) and I personally see AlwaysOn 2012 not being as widely used for multi-site DR scenarios as it would have been used without Windows Geo-Cluster requirement. And DB Mirroring is now deprecated in SQL 2012 leaving venerable Log Shipping the only other DR option (and its not a very pretty option, not in year 2012-13).
I sincerely hope this restriction will be addressed in future release of SQL Server, as all of a sudden Oracle 11g R2 DR solution has now become overall simpler to implement than SQL Server 2012 AlwaysOn DR. This must be a (dubious) first for Microsoft SQL Server ! 8^)
End of Soapbox.