Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

We're going to host a large SQL Server 2012 under a VMware virtualization and we need it to be highly available.

These are the three options I found supported, but couldn't find a lot of info and comparison on who's better and why (and mostly - what's the disadvantages):

  1. VMware HA - pro: cheap and easy to use and configure, just let the VM team deal with it. con: no HA for system upgrades, e.g. SQL upgrades, Windows services-packs\KBs etc.
  2. SQL Server Failover Cluster (FCS) - pro: well known, supported, saves space (compared to AlwaysOn Availability Group), HA for system upgrades. con: I haven't heard of successful clusters over VM, or at least good ones. Heard it's a mess and to "stay away from it". A bit harder to admin, some problems may take days to figure out (no-one with a lot of knowledge).
  3. SQL Server AlwaysOn Availability Group - pro: HA for everything! system, DB etc. con: New, added administering and hard to confiugre, new problems to deal with, double the space(!), "no strings attached" (to other servers).

That's pretty much it.

I would appreciate any info you may have about this, and would appreciate even more recommendations (hopefully based on test cases).

~Thanks.

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

It really depends on what you are trying to protect from and what your SLAs are. If your goal is to protect against hardware failure and you can handle a few minutes of downtime in the event of a hardware failure then stick with the native VMware options.

If you need to protect yourself from blue screens then clustering on AlwaysOn AGs will be the way to go. If you are just trying to protect yourself from hardware failures but you can't afford to have even a few minutes of downtime then clustering of AlwaysOn AGs will again be the way to go.

Choosing between FCI (Fully Clustered Instance) and AG will depend on what you are trying to do. If you need to scale out reads for reporting then AG. If storage costs are not an issue then AG. Keep in mind that FCI will require RDMs if you are using fiber channel or iSCSI. If you use RDMs then you have to deal with not having vMotion while the VMs are online. With AGs you don't need RDMs so you don't have this issue.

There are lots of options available to you, it just depends on which way to go.

As for clustering under VMware, it works just fine. I've got lots of clients who have virtualized most or all of their SQL Servers and have plenty of Windows clusters inside of VMware.

share|improve this answer
    
Thank you very much. One thing though, in paragraph 3 - "If storage costs are an issue then AG" - you mean if it's not an issue, right? cause AlwaysOn has double the data storage. (right?) –  user27177 Aug 16 '13 at 21:51
    
Yep. However depending on the situation storage costs for AGs can be less than with clustering as AGs support local disk where FCIs require SAN storage, but generally speaking AGs will be less cost. I'll correct the answer. –  mrdenny Aug 18 '13 at 6:16
add comment

VMware HA will soon bring a new option, which will be announced at VMworld (end of August 2013), this might help you a little. Drawback though that still remains is that with HA (incl the new feature) you cannot do maintenance on one node and have the other node server requests like you mentioned in the cons already. In my opinion HA is never an option when you are aiming for the five 9's uptime.

Also keep in mind that HA doesn't detect application failure (did I mention the announcement at VMworld). As long as your Guest OS is running and doing IO, HA is happy and will not trigger.

Clustering VMs is no harder that Clustering physical servers. I have several customers running SQL Clusters on VMware. There are some VMware KB articles that tell you exactly how to do this, which boils down to just a number of "need to know" settings.

In early days there were a lot of issues with MS Clustering on VMware that were mainly caused by timing issues. Placing the OS disk on slow storage, causingn time-outs, causing faulty failover triggers. That is all in the past now.

Can't tell you much on option 2 & 3

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.