January 20, 2014 at 7:12 am
Hi all, I posed a similar question previously and with a little bit more understanding, I'm still none the wiser!!
Presently we have a SQL 2008 R2 cluster, the main database on there is mirrored to a named instance on another server (different subnet) which is also a clustered instance. Mirroring is manual failover due to the WAN.
Now, from what I can gather and told we don't have disk replication available so that rules out a multi subnet cluster in 2012 terms, am I correct?
So, what would be the options available to me with SQL 2012 technology that supports the above, the more I look I cant actually find any solution other than continuing with the current set up - which I am reluctant to do due to mirroring being discontinued.
Many thanks
D
'Only he who wanders finds new paths'
January 20, 2014 at 7:26 am
david.alcock (1/20/2014)
Hi all, I posed a similar question previously and with a little bit more understanding, I'm still none the wiser!!Presently we have a SQL 2008 R2 cluster, the main database on there is mirrored to a named instance on another server (different subnet) which is also a clustered instance. Mirroring is manual failover due to the WAN.
Now, from what I can gather and told we don't have disk replication available so that rules out a multi subnet cluster in 2012 terms, am I correct?
So, what would be the options available to me with SQL 2012 technology that supports the above, the more I look I cant actually find any solution other than continuing with the current set up - which I am reluctant to do due to mirroring being discontinued.
Many thanks
D
An AlwaysOn group would be fine, it's essentially just mirroring anyway. You'll need to join the remote server to the same windows cluster as the primary servers, no replicated storage would be required.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 20, 2014 at 7:35 am
Thanks Perry!
Yes I did think it was still mirroring under the hood so to speak.
Here's perhaps the question, only the named instance on the 2nd cluster (DR) should be part of the group as that particular cluster, well the default, is for pre-production purposes. So I guess, can I still add the 2nd cluster but sync between instances - if that makes sense?
D
'Only he who wanders finds new paths'
January 20, 2014 at 7:41 am
Are the two clustered instances on separate Windows clusters?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 20, 2014 at 7:56 am
There are 2 separate clusters, production at the main site and pre-production that has 2 SQL instances on it (pre-production and disaster recovery).
D
'Only he who wanders finds new paths'
January 20, 2014 at 8:16 am
david.alcock (1/20/2014)
There are 2 separate clusters, production at the main site and pre-production that has 2 SQL instances on it (pre-production and disaster recovery).D
Although it's possible to create an AlwaysOn group across separate clusters it's not supported. All nodes should be part of the same Windows cluster. See here[/url] for more info
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 20, 2014 at 8:20 am
Am I right in thinking that if we had disk replication then we could add the other node into an availability group?
I have spent some time looking into this and kept coming with the same solution that we couldn't really utilise alwayson.
I'll have a read of the link, thank you ever so much for the time Perry, massively appreciated.
'Only he who wanders finds new paths'
January 20, 2014 at 8:54 am
david.alcock (1/20/2014)
Am I right in thinking that if we had disk replication then we could add the other node into an availability group?I have spent some time looking into this and kept coming with the same solution that we couldn't really utilise alwayson.
I'll have a read of the link, thank you ever so much for the time Perry, massively appreciated.
The whole point of AlwaysOn is that you don't need replicated\shared storage. The nodes only need to be a part of the same Windows cluster, which does not in itself require shared storage which i think is where you may be getting confused.
A Windows cluster will be perfectly happy spanning multiple sites providing you set it up correctly
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 20, 2014 at 9:01 am
Actually Perry its beginning to sink in and yes, that's exactly where I was getting confused...well one of the points!
Each of our clusters has 2 nodes, A/P. In order to utilise AlwaysOn, we would need to add each node (of each cluster) to ONE cluster. Then we can set up the roles of each server in the AG afterwards.
D
'Only he who wanders finds new paths'
January 20, 2014 at 9:11 am
david.alcock (1/20/2014)
In order to utilise AlwaysOn, we would need to add each node (of each cluster) to ONE cluster. Then we can set up the roles of each server in the AG afterwards.D
Yes, a node can be a member of only one cluster though so the best way forward would be to destroy the DR cluster and join both nodes to the Primary site cluster. Restore the databases from Primary site instance to the new DR instance with NORECOVERY and then implement the AO group.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 20, 2014 at 9:19 am
Yes and that's where the issue lies as the DR (SQL instance) sits on the pre-production (windows) cluster, so yes we'd have to have that within the same cluster and then setup the availability group.
That is where, from a business sense, there will be conflicts as there is lots of work happening on the pre-production side of things that they want separate, hence the two clusters to begin with. I have asked for a DR instance but no joy!
Well sir, my understanding has vastly improved this afternoon, many thanks.
'Only he who wanders finds new paths'
January 20, 2014 at 9:59 am
david.alcock (1/20/2014)
Yes and that's where the issue lies as the DR (SQL instance) sits on the pre-production (windows) cluster, so yes we'd have to have that within the same cluster and then setup the availability group.That is where, from a business sense, there will be conflicts as there is lots of work happening on the pre-production side of things that they want separate, hence the two clusters to begin with. I have asked for a DR instance but no joy!
Well sir, my understanding has vastly improved this afternoon, many thanks.
Generally, providing High Availability on your DR site is a futile exercise. DR is designed to be a temporary solution, if you ever fail to DR it should only be long enough to get the Primary site back online.
Couple of things;
Why can't you complete the set up during a maintenance window at the weekend for instance, it could likely be completed in a few hours at most.
Why the need to have the pre prod instance totally separate, even though all 4 nodes would be part of the same Windows cluster the Pre prod instance would be homed to the same nodes it's on now. It sounds like there is confusion on how the cluster will operate when all 4 nodes are migarted to a single Windows cluster.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 20, 2014 at 10:06 am
Set up time isnt an issue, as you say, weekend is fine.
The issue lies with the software the clusters are supporting and the providers have which stated that we have to have two identical setups, for production and pre-production - so therefore we would not be able to group as one. That isnt to say I wont be asking too!
D
'Only he who wanders finds new paths'
January 20, 2014 at 10:20 am
That's because they don't under stand how multi node clusters are configured and operate 😉
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 20, 2014 at 12:20 pm
Yes indeed and at the same time, thats why I need to act on your advice and guide them 🙂
D
'Only he who wanders finds new paths'
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply