April 4, 2016 at 8:00 pm
Hi all,
As the topic goes, we do not want to
- use database mirroring because it will no longer be supported soon
- use log shipping due to the backup/transfer/apply time gap
We cannot use high availability group because we do not have an enterprise license.
We can use failover cluster though, but the nodes are on the same site.
Can we build a failover cluster 2 or 3 nodes across sites ? (e.g. 2 on primary site, 1 on DR site)
Is there any differences between
- Microsoft Windows Multi-Site Failover Cluster
- Multi-Subnet Windows Server Failover Clusters
Regards,
Noob
April 5, 2016 at 2:05 am
IMHO Log Shipping is still the best option for DR in many situations.
If you thing that the time gap between backup/restores is an issue, maybe you're looking for HA and not DR (or maybe both).
You can still implement HA at your primary site with any technique (clustering, mirroring and log shipping are your only options if you're in STD) and have data replicated at a DR site with a totally different technology (log shipping or replication).
-- Gianluca Sartori
April 5, 2016 at 2:59 am
We're missing the most critical information needed for a DR design.
What's your RPO and RTO?
What kind of disasters are you protecting against (for example, clustering won't protect against a SAN failure)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 5, 2016 at 9:37 am
GilaMonster (4/5/2016)
We're missing the most critical information needed for a DR design.What's your RPO and RTO?
What kind of disasters are you protecting against (for example, clustering won't protect against a SAN failure)
Hi Gila,
We are trying to prevent a total site failure but still have < 5 minutes of transaction lost.
Sorry to sound broad but the RPO and RTO = the best that we could in all the options available.
- seems like db mirroring can achieve the closest RPO/RTO but it is obsolete soon
- log shipping will have a time gap for transport and apply which I think will be more then > 5 minutes (not sure if we could schedule log backup and log apply in 5 minutes interval - too frequent ?)
Thus , we are looking at Failover cluster across sites.
It seems like multi-site clustering (using SAN replication) do prevent SAN failure on 1 site.
But we are not sure if we are able to do a multi-site / multi-subnet failover cluster and if there are any difference between them.
Thus we are asking around to see what the common practise in the industry here for building a DR using standard edition
Regards,
Noob
April 5, 2016 at 9:40 am
spaghettidba (4/5/2016)
IMHO Log Shipping is still the best option for DR in many situations.If you thing that the time gap between backup/restores is an issue, maybe you're looking for HA and not DR (or maybe both).
You can still implement HA at your primary site with any technique (clustering, mirroring and log shipping are your only options if you're in STD) and have data replicated at a DR site with a totally different technology (log shipping or replication).
Hi Spaghettidba,
Yeap.. We do want a DR, but we do want the DR 's data to be as close to the Primary as possible.
In another words, we can't have a DR that is (near in sync) with the Production using standard edition yea ?
(maybe < 5 minutes of transaction lost)
Regards,
Noob
April 5, 2016 at 9:42 am
It would be worth your while to consider the cost of these alternative solutions vs the enterprise license cost. It might be about the same if you factor in time, complexity of solution support etc.
April 5, 2016 at 9:49 am
You are making the same basic mistake everyone seems to with DR and HA .. yes multisite clustering is great .. but this has to mean you're using multiple storage otherwise you still have a spof - with such a solution, like availability groups, if someone drops a table by mistake it's gone elsewhere too so you'll still need to ideally log ship to cover yourself against accidental data loss, malicious data loss and out and out damage/corruption.
As I remarked to someone else log shipping is so simple but it does give you protection which mirroring/replication/availability groups cannot.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
April 5, 2016 at 10:04 am
szejiekoh (4/5/2016)
- seems like db mirroring can achieve the closest RPO/RTO but it is obsolete soon
And 2-node availability groups in Standard edition is coming (in SQL 2016)
Thus , we are looking at Failover cluster across sites.
It seems like multi-site clustering (using SAN replication) do prevent SAN failure on 1 site.
Multiple SANs, and the cost of the software for the replication, and you can't afford an Enterprise edition license?
And if you get it set up incorrectly, it will give you only a false sense of security (last time I saw a client doing that, every one of their DR tests had failed)
You need to define, agree and document your RPO and RTO. I didn't ask for them because I was bored. If you don't know what your objectives are for recovery, how will you know whether you can meet them or not
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 6, 2016 at 4:13 am
Hi Gila,
Thanks for your reply. please do not misunderstand me, I do not meant to give you a brief answer on the RPO and RTO.
It is because I do not have the answer myself as well, end-users/management will tell you they want everything, with the cheapest cost.
So if my limitation is stuck with Standard, what do you recommend to offer the closest RPO and RTO among all the available solutions (using standard) for setting up a DR site.
It seems like the way to go is to do logshipping for DR.
Regards,
Noob
April 6, 2016 at 4:28 am
szejiekoh (4/6/2016)
It is because I do not have the answer myself as well
You need to get it, because those are numbers you'll be held to when/if a disaster happens.
If management expects max downtime to be 10 minutes and you take an hour to get the system back, you'll be the one held responsible for the manager's expectation not been met
, end-users/management will tell you they want everything, with the cheapest cost.
And I want a million pounds and a trip to the moon.
We don't all get what we want.
You need to sit down with the owners of the system and/or managers and hammer out those SLAs. The lower the numbers they want, the more it will cost. The less they're willing to pay, the higher the numbers will be. That's reality.
HA/DR planning is hard, but get it wrong and you could lose your job or lose the entire business.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 6, 2016 at 12:02 pm
What Gila said. If you do the cost analysis of doing all this extra stuff vs the cost of the enterprise license, you might be pleasantly surprised that the the EL is cheaper.
April 7, 2016 at 6:50 am
GilaMonster (4/6/2016)
szejiekoh (4/6/2016)
It is because I do not have the answer myself as wellYou need to get it, because those are numbers you'll be held to when/if a disaster happens.
If management expects max downtime to be 10 minutes and you take an hour to get the system back, you'll be the one held responsible for the manager's expectation not been met
, end-users/management will tell you they want everything, with the cheapest cost.
And I want a million pounds and a trip to the moon.
We don't all get what we want.
You need to sit down with the owners of the system and/or managers and hammer out those SLAs. The lower the numbers they want, the more it will cost. The less they're willing to pay, the higher the numbers will be. That's reality.
HA/DR planning is hard, but get it wrong and you could lose your job or lose the entire business.
Hi Gila,
Your right. Will sit down and discuss with them.
Thanks.
Regards,
Noob
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply