Solved

SQL Server 2012 High Availability options

Posted on 2014-03-28
3
335 Views
Last Modified: 2014-04-14
I have a web-based application based on SQL Server 2012 which we want to have highly available, meaning 2 separate SQL servers in the same datacenter 'in sync' with each other, and a process whereby if the main SQL server fails, within a minute or so the application servers are talking to the backup SQL.

We also have a 2nd datacenter with 1 SQL server which we'd also like in the pool if possible.

I know SQL Standard and Enterprise 2012 offer AlwaysOn, but that is the only feature that matters to me and differentiates them from SQL Web, and the price difference is huge.

Can anyone recommend a 3rd party product to do this? Perhaps Doubletake or something similar?

Thanks
0
Comment
Question by:tabush
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
3 Comments
 
LVL 28

Expert Comment

by:Ryan McCauley
ID: 39965753
I'd encourage you to look at Stardard edition - it runs about $1700/core retail and it supports a two-node failover cluster instance (FCI), which addresses your HA within the same data center (Web edition doesn't support failover clustering). An FCI includes two physical servers, with shared storage between them (your SAN, presumably), and one server is ready to take over for the other in case of a failure, usually with around 30 seconds of downtime.

You're correct that AlwaysOn would work well in the situation you're describing with DR at a separate data center, but since it's an Enterprise feature, you're looking at going from $1700/core to $7800, and likely isn't worth it for you. That said, standard edition still supports all forms of replication, so you can set up either log shipping or maybe transactional replication to your DR site from your primary servers. That way, your remote server is ready to take over once you redirect your application tier.

From a licensing perspective, you may not even need to license the remote site - as long as you're not running reporting from the DR server and no clients are connecting, I don't believe it has to be licensed. However, you'll want to confirm that with a license specialist (I'm not one), as the licensing for HA, DR, and warm failovers is very nuanced, where some implementations require licensing and some do not. If we were to license the second site, you now have the option of running reporting from the replicated server, which would alleviate some load on your primary servers (if that's an issue).

I hope that answers your questions, and if you need some more detail, please elaborate and I'll fill in where I can.
0
 
LVL 2

Author Comment

by:tabush
ID: 39966888
thanks @ryanmccauley, i'm actually looking to avoid shared storage, which i believe always on solves, but it's damn expensive... we are looking at SPLA licensing and it's literally around 10x the price of web edition.
0
 
LVL 28

Accepted Solution

by:
Ryan McCauley earned 500 total points
ID: 39966960
Ah - that makes sense. Unfortunately, you're limited on replication options as well - Web edition can be the recipient of a replication stream, but it can't be the originator. However, Web Edition does support log shipping, so you may want to look into that:

http://technet.microsoft.com/en-us/library/ms187103.aspx

Alternatively, you could have a bit more control if you wanted by taking backups and manually replicating them to your secondary site. I've set up something like this before (manually) and it could easily be modified to include transaction log backups as well as full backups (link to my blog post about it, including scripts):

http://www.trycatchfinally.net/2009/09/moving-a-sql-server-database-to-another-server-on-a-schedule-without-using-replication/

Basically, a SQL Agent job is set up on the source side that takes the backups and compresses them (I was using SQL 2000 - however, SQL 2012 Web Edition doesn't support compression, so you'd likely stick with the same approach), and then ships them to a remote site via FTP. Once they're at the remote site, another SQL Agent job on the destination server uncompresses and restores the backup.

Using this process, you could keep a remote site pretty close to in sync by sending log backups every few minutes. However, log shipping would accomplish much the same thing and is natively built in to SQL Server 2012, so unless you've got an aversion for some reason, that's probably the way to go.
0

Featured Post

Best Practices: Disaster Recovery Testing

Besides backup, any IT division should have a disaster recovery plan. You will find a few tips below relating to the development of such a plan and to what issues one should pay special attention in the course of backup planning.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

This article explains how to reset the password of the sa account on a Microsoft SQL Server.  The steps in this article work in SQL 2005, 2008, 2008 R2, 2012, 2014 and 2016.
For both online and offline retail, the cross-channel business is the most recent pattern in the B2C trade space.
Familiarize people with the process of utilizing SQL Server functions from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Ac…
Via a live example, show how to setup several different housekeeping processes for a SQL Server.

751 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question