SQL Clustering or Hyper V Clustering

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!

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.

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.