4

We will soon be implementing our Dynamics AX installation. Our aim is to have high availability and we are working closely with our implementers.

We raised the question to them about SQL and Hyper-V Clustering. They recommended that when running in a complete virtualized platform there is no real reason to virtualize at application layer (SQL) and that just setting up Hyper V clustering in Windows Server and creating your SQL and all other related Application VM's on LUN's to back-end storage (in our case HP P2000) and just running the VHD files in high availability mode using CSV's.

Is this true? Or should we be clustering SQL separately at VHD level?

Many thanks!

dqnet
  • 305
  • 2
  • 9

2 Answers2

5

They recommended that when running in a complete virtualized platform there is no real reason to virtualize at application layer

This is potentially dangerous advice. Hyper-V clustering allows high availability in the event of a hardware failure - that is all.

In-guest clustering allows for OS-level high availability in the event of a BSOD, failed Windows Update, application fault, or any other failure mode that isn't hardware related. It also allows you to patch these systems and applications without incurring downtime to the application, which may be important for something like a Dynamics install.

There are plenty of configurations where it doesn't make sense to add in-guest clustering when using hypervisor-level clustering, because you're OK restoring from backup in the event of an OS failure, but to say that it is never needed because clustering is done at the hypervisor is sketchy advice at best. They are most effective when used in tandem.

MDMarra
  • 100,734
  • 32
  • 197
  • 329
  • Definitely a miss-communication, it wasn't said in those exact words. Thanks for your advice, it makes more sense now. However application downtime and patching can be done after office hours when most employees wont really be using the system. I am still a little worried to press on with just HyperV clustering. Backups are taken twice a day so I guess that makes things a little safer however if your advice is to cluster at SQL level then how would one use Always-on in a cluster within a VM cluster? Isn't that going excessively too complictated? :/ – dqnet Mar 03 '14 at 17:49
  • @serverimeco I guess "too complicated" is a relative term. I've configured AlwaysOn Availability Groups inside of Hyper-V and VMware for many clients, though they do tend to be on the larger side. Smaller clients typically will live with the downsides of hypervisor-only clustering. It's really up to you as to how much downtime is acceptable. View it like this: How long would it take to do a full bare metal restore of your database VM? How much data is the most you could lose this way? Is this downtime and data loss acceptable? If so, you don't *need* in-guest clustering. – MDMarra Mar 03 '14 at 18:08
  • 1
    Another thing that I'll note is that AlwaysOn AGs require SQL Server Enterprise, which is costly. Traditional failover clustering, mirroring, log shipping, etc is available in Standard Edition which is much more affordable. In some cases, the price dictates the solution as much as any other factor. – MDMarra Mar 03 '14 at 18:09
  • @MDMara, I think it might be a little too much for us. We definitely have a window or two in the "reasonable time bracket" to do any patching or similar. But is that generally how it works? Doing Hyper V clustering at server level and then cluster SQL in individual VM's using CSV's and HyperV clustering? – dqnet Mar 04 '14 at 04:47
  • 1
    I would say no - as in: you do not need a CSV with you do SQL level clustering as you can live with one machine going down. – TomTom Mar 04 '14 at 05:58
  • @serverimeco I'm not sure what you're asking. You cluster SQL like its a physical machine if you want in-guest clustering. – MDMarra Mar 04 '14 at 11:59
  • Ah totally understand now. I was wondering if you could cluster SQL VM's using AlwaysOn whilst clustering at the VHD level using HyperV. I never knew that was possible. I think HyperV clustering will suffice our need. Ill run HyperV replication to be extra safe as that seems much easier to setup despite having to manually intervene to get it back up. By the way, will live migration work with AlwaysOn SQL VM clusters? – dqnet Mar 04 '14 at 17:02
  • Yes, you can cluster at the SQL level with AlwaysOn while clustering at the Hyper-V level as well. Live migration will work, though a long migration cutover may trigger a heartbeat timeout which could switch the active node. This really only happens on heavily overprovisioned systems – MDMarra Mar 04 '14 at 17:05
3

They recommended that when running in a complete virtualized platform there is no real reason to virtualize at application layer

Incompetence. SImple like that.

It totally depends on your requirements. And how you do it.

SQL Server level standard clustering is active /passive and that will restart the sql server instance when the other fails, which still should be faster than restarting the VM.

SQL Server alternative is High Availability Groups and that has thebenefit of 2 sotorages so if a fialing server takes down the database files, then the other machine can take over. No shared storage needed.

It really depends what you need.

That needs also depends on patching ;) When you patch the VM containing SQL Server - that may be a downtime. Can you do that? (planned downtime, maintenance window).

Generally "no real reason" like you told is either incompetence or bad communication - there are multiple reasons. The question is whether they are relevant for you. We cna not decide that. But there are good reasons not to use a CSV and use replicated local storage for a High Availability Group in SQL Server.

TomTom
  • 51,649
  • 7
  • 54
  • 136
  • Ha. Same answer posted at the same time. Hopefully he takes the advice :) – MDMarra Mar 03 '14 at 16:05
  • 1
    Would be nice. I am not sure he needs that type of HA though - but yeah, a general "no reason" is a sign of incompetence. I would assume details got lost in the communication. – TomTom Mar 03 '14 at 16:07