VMware HA is Not Database Server High Availability

I served with High Availability. I knew High Availability. High Availability was a friend of mine.  VMware HA, you’re no High Availability.

See, for us database administrators, high availability means protection when:

  • The system drive fills up because some potato decided to download a bunch of files
  • An operating system or database server update goes horribly awry
  • Or even when an OS or SQL update goes right – because the beauty of real high availability solutions is that they let you patch the standby node first, make sure it works, and then fail over to it so you can patch the other node.

Don’t get me wrong – I love VMware, and I love using VMware HA for database servers.  It’s a fantastic way to get higher availability for those old dinosaur database servers running SQL Server 2000 that we just can’t kill, yet still run important apps.  But in systems where uptime really matters, a single virtual machine isn’t the answer to high availability.  That’s where solutions like clustering, database mirroring, replication, and AlwaysOn Availability Groups come into play.

Thankfully, there’s good news: when VMware HA is paired with SQL Server technologies, they can both work even better.  Two standalone physical database servers running AlwaysOn Availability Groups are more reliable than just one server, but two virtual machines doing the same thing are even more reliable.  They’re protected from hardware failures because they can be spun up on any VMware host in the datacenter.  They’re more flexible because we can add CPU power or memory quickly based on demand.

I’ve blogged about why your SQL Server cluster shouldn’t be virtualized, and that still holds true.  If you need to build a hybrid AlwaysOn solution involving both failover clustered instances (FCIs) and standalone instances, I would rather not put the FCIs in VMware first.  But if you’re under pressure from management to cut costs and cut your datacenter footprint, put the rest of the instances in virtual machines.  You’ll gain the power and comfort you want from physical machines while getting even higher availability from the virtual machines.  Everybody wins, and the future will be better tomorrow.

Wanna learn more? Check out our VMware, SANs, and Hardware training videos. It’s a 5-hour training video series explaining how to buy the right hardware, configure it, and set up SQL Server for the best performance and reliability.

Previous Post
Big Changes for Big Virtual Machines in VMware vSphere 5
Next Post
Choosing the Right SQL Server Version: It’s Trickier than You’d Think

15 Comments. Leave new

  • Michael Heindel
    January 22, 2013 12:34 pm

    There are so many factors involved in an optimal HA SQL environment. I was fortuante to speak with one of the SQLCAT team members about our planned design.

    Your blog posts are often used as refrences when we are trying to make a point outside of the Data team. Please continue to refence Unicorns. Our Storage Team is unable to compete against Unicorns.

    Michael

    Reply
  • I’ve written about this before as well and am devoting some space in the new book about these kinds of things. I’m always amazed at how many people think that VM stuff supplants needing to do things in SQL Server. On twitter today there was a thread around just using VM replication and it taking the place of having to do a traditional SQL Server backup.

    Reply
  • There are so many factors involved in an optimal HA SQL environment – sooooo true. I am constantly being asked to cluster our VM SQL Servers. Not so fast I say, I need to know how the VM Cluster is set up first amongst many other things. “why” say our VM admins “just cluster it like you would a physical server”. and so it goes on and on….

    when’s the new book out Allen, really enjoyed Pro SQL Server 2008 Failover Clustering so looking forward to it.

    Reply
  • Very helpful post and follow-up comments. We currently have mirrored SQL Server 2008 instances in our primary data centre and a single SQL Server 2008 instance in our disaster recovery data centre with merge replication between the primary and disaster recovery instances.

    We have a remote mirroring witness server which is also the merge replication distributor. This represents a single point of failure in our high availability architecture (!). We are looking to eliminate this and have a number of options:

    SQL Server clustering on physical servers.
    SQL Server clustering on VMWare virtual servers with VMware HA.
    VMware HA.

    We don’t face some of the challenges Brent outlines in https://www.brentozar.com/archive/2012/09/why-your-sql-server-cluster-shouldnt-be-virtualized/ as we have a small operations team responsible for the server, database and VMware environment.

    As the DBA my inclination is to go down the SQL Server clustering route. I have taken a look at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1037959 which highliglights some of the limitations of running MSCS on VMware: vMotion migration, storage vMotion, hot adding memory and CPU ….

    Would welcome any thoughts.

    Reply
  • Hi Brent, it’s been 4 years since your post. Do you have any different thoughts on using VMware solely on HA without sql HA Like AG, mirroring…? My company wants to use ONLY vmware for SQL server HA. Any scenarios where AG can do in terms of HA that VMware won’t be able to? Thanks!

    Reply
  • Thanks Brent for this Article !
    I have to design an architecture HA SQL , I have proposed a solution with 2 VM with BAG (as the customer wants standard edition) , but the application doesn’t support downtime and in BAG when failover occurs there is a few seconds of downtime and the application needs to reconnect to the new primary.. So our VMware team told me that the VMWare HA could do the job , what do you think ? could you help me to arguments my architecture ? thanks for your help

    Reply
    • Christine – sure, we do this kind of consulting all the time. Click SQL Critical Care Consulting up at the top of the page, and check out Patient C’s findings for an example of the kinds of deliverables we do with our clients. You can also see the pricing from there.

      Reply
  • PETE C. ADRIAN
    March 28, 2019 12:24 pm

    Hey Brent – Got a question yesterday im not sure about? Can AlwaysOn Nodes sit in a VM host. Im assuming yes, but shouldn’t be on different VM hosts? Thanks Pete

    Reply
  • Hi Brent,
    I just wonder if you have any update on vmWare Vmotion on primary SQL replica with larger memory allocation and potentially a lot of update activities? The purpose of vMotion here is for patching up the ESX host where some primary SQL AAG replicas are running.
    Thanks & regards,
    Irene

    Reply
    • Irene – the post wasn’t really about vMotion, no, and I haven’t written about that. For VMware info, your best bet will be a VMware blogger – I tend to focus more on SQL Server. Sorry about that! It’s a legit question, but I just don’t stay current on VMware enhancements.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.