Blog

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. Here’s a preview:

Buy it now.

↑ Back to top
  1. 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

  2. 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.

  3. 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.

  4. Pingback: When VMWare HA is Sufficient | Cranky DBA

  5. Pingback: When VMWare HA is Sufficient - SQL Server Blog - SQL Server - Telligent

  6. Pingback: Database technologies news on Oracle, SQL Server and MySQL

  7. 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 http://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.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

css.php