Not just Hypervisor Agnostic, Hypervisor Version Agnostic!

Its well known that Nutanix is Hypervisor agnostic supporting ESXi, Hyper-V and KVM, but what most people either don’t know, or haven’t considered, is the fact the Nutanix Operating System (NOS) version is not dependant on the hypervisor version.

What does this mean?

You can run the latest and greatest NOS 4.1.x releases on ESXi 5.0 , ESXi 6.0 or anything in between. In fact, you could run older versions of NOS such as 3.x with vSphere 6.0 as well (although I see no reason you would do this.)

Why is this important?

This past week I was discussing with some government customers how they can perform upgrades of NOS using our 1-Click upgrade, and I was asked a similar question on several occasions:

“What version of ESXi do we need?”

The reason the customers asked this question is because for large environments, changing/upgrading the hypervisor can be a significant project requiring Design/project management and implementation labor which could cost huge amounts of money when the only goal is to increase storage performance or functionality.

NOS can be upgraded independent of the Hypervisor (and without performing a single vMotion or putting hosts into maintenance mode). This ensures that customers who cannot or do not wish to upgrade ESXi for any reason, continue to benefit from the ever increasing performance and feature set of NOS.

While hyper-converged solutions like Nutanix combine the compute/hypervisor layer and the storage layer delivering numerous benefits over traditional 3-tier architecture, it’s a significant advantage to be able to independently upgrade the compute or storage layer.

This is something Nutanix delivers which is just one of the many ways we make our solution “Uncompromisingly Simple”.

Oh, did I mention NOS also provides support for 1-Click Hypervisor and Firmware upgrades ? 🙂

Related Articles:

Microsoft Support for MS SQL on NFS datastores

QUESTION: Is MS SQL supported when running in a vSphere environment where the SQL databases/logs are in a VMDK on an NFS datastore?

Short answer: YES!

Note: I have confirmed this with the Principal Program Manager for SAP, SQL & Azure Customer Programs.

Here are some important Microsoft Knowledge Base articles to confirm this statement.

1. Support policy for Microsoft SQL Server products that are running in a hardware virtualization environment

2. Support policy for Microsoft software that runs on non-Microsoft hardware virtualization software

It is important to note, no where in the above support policies is storage protocol even mentioned. To me this is a very smart move by the SQL team as the underlying storage protocol is abstracted from the VM, making it irrelevant.

The key requirements are:

a) The platform must be SVVP (Server Virtualization Validation Program) certified

VMware is SVVP certified, as is shown by on the SVVP Website.

b) The SQL Server product must be a supported version under its current Microsoft Support Lifecycle policy

For more information about Microsoft Support Lifecycle policies, visit the following Microsoft Support website: http://support.microsoft.com/?pr=lifecycle

c) Virtualization support per SQL features based on SQL Edition

This can be verified here under “Virtualization Support” and the below table is from this KB showing what is supported based on SQL edition.

virtusupportsql

Now in saying SQL is supported when running in a VMDK on NFS datastores, there are some limitations as discussed in SQL AlwaysOn Availability Group support in VMDKs on NFS Datastores.

In summary, old style SQL clustering requiring Shared disks which is not supported.

However SQL Always on Availability Groups (AAG) and SQL Mirroring are supported, which are the two configurations you should be considering these days.

I hope this helps clear up any confusion.

Now for the MS Exchange team to follow the lead of the SQL team!

See Virtualizing Exchange on vSphere with NFS backed storage for more details.

SQL AlwaysOn Availability Group support in VMDKs on NFS Datastores

Recently I had a customer contact me about doing SQL Always-On Availability Groups on Nutanix and they were wondering if it was supported due to the fact Nutanix recommend and run by default NFS datastores.

The customer did the right thing and investigated and came across the following VMware KB:

Microsoft Clustering on VMware vSphere: Guidelines for supported configurations (1037959)

The KB has the following table and the relevant section to MS SQL AAGs is highlighted.

SQLsupportnfs

As you can see the table indicates (incorrectly I might add) that SQL Always On Availability Groups are not supported on NFS when in fact the storage protocol is not relevant to non shared disk deployments.

The article goes onto provide further details about the supported clustering and vSphere versions as shown below with no further (obvious) mention of storage protocols.

pix1

However down the bottom of the article it states (as per the below screenshot):

3. In-Guest clustering solutions that do not use a shared-disk configuration, such as SQL Mirroring, SQL Server Always On Availability Group (Non-shared disk), and Exchange Database Availability Group (DAG), do not require explicit support statements from VMware.

pix2

As a result, SQL Always-On Availability Group non shared disk deployments are supported by VMware when deployed in VMDKs on NFS datastores (as are Exchange DAG deployments).

To ensure there is no further confusion, Michael Webster and I are currently working with VMware to have the KB updated so it is no longer confusing to customers with NFS storage.

For those of you wanting to learn more about Virtualizing SQL Server with vSphere, checkout my friend and colleague Michael Webster (VCDX#66) VMware Press book below.

virtualizing-sql-server-cover-small (1)