Nutanix Scalability – Part 5 – Scaling Storage Performance for Physical Machines

Part 3 and Part 4 has taught us that Nutanix provides excellent scalability for Virtual Machines and provides ABS and Volume Group Load Balancer (VG LB) for niche workloads which may require more performance than a single node can provide.

Now that we’ve learned how to scale a Virtual machines performance, let’s see how the same rules apply to physical servers.

So you’ve got your physical server and a Nutanix cluster, now what?

As Part 3 and Part 4 explained, more virtual disks increase the storage performance for virtual machine, the same is true for physical servers using ABS.

Virtual disks will be presented to the physical server via iSCSI (ABS), for optimal performance you should have at least one virtual disk per node in your cluster. The reason for this is each vDisk is managed by a stargate (Nutanix IO engine) instance which runs in every Controller VM (CVM).

If you have a four node cluster, you need to use at least four virtual disks to utilise the four node cluster optimally. For an eight node cluster, eight or more virtual disks is required to ensure all CVMs (stargate instances) can actively provide a boost in performance.

The following tweet shows how the pathing increased from four on the four node cluster and when an additional fours node were added the pathing dynamically changed to use all eight nodes.

Therefore when using ABS for physical workloads, especially those high end database servers, I recommend using a minimum of 8 vDisks however if your cluster size is greater than 8, match the number of vDisks with the cluster size as your starting point.

If you have an 8 node cluster, you could for example use 32 vDisks and these will spread evenly across the nodes, resulting in four per stargate instance which is perfectly fine.

Using more vDisks than your current cluster size also means when additional nodes are added, ABS can dynamically load balance the vDisks across the new and existing nodes to automatically scale your performance.

Let’s cover the same MS Exchange and MS SQL examples covered for Virtual Machines in Parts 3 and 4 but now specifically for physical servers using ABS.

Let’s say we have an MS Exchange server with 20 databases, the performance requirements for each database is typically in the range of hundred of IOPS, in which case I would recommend one virtual disk (e.g.: VMDK) per database and another for the logs.

In the case of a large MS SQL server which may require tens or hundreds of thousands of IOPS to a single database, I recommend using multiple vDisks per database which involves Splitting SQL datafiles across multiple VMDKs to optimise VM physical server performance.

Sound familiar? The above two paragraphs are literally a copy/paste from Part 3 because the exact same rules apply to physical servers and virtual machines. Simple right!

Still need more performance?

Again, the exact same rules apply to physical servers with ABS as they do to virtual machines. In no particular order, as we’ve learned from Part 3 & 4:

  • Increase the vCPU of the Nutanix Controller VM (CVM)
  • Increase the vRAM of the Nutanix Controller VM (CVM)
  • Add storage only nodes

Can’t get much easier than that!

Summary:

From Parts 3, 4 and 5 we have learned that Nutanix provides the ability to scale the performance of individual servers, be it physical or virtual using the same simple strategies of adding virtual disks, storage only nodes or Controller VM (CVM) resources and how doing so increases performance to meet virtually (pun intended) any performance requirements.

Is there any reason you couldn’t confidently say Nutanix is doing 3 tier better than the SAN vendors? I’d love to hear if you have any corner cases.

Back to the Scalability, Resiliency and Performance Index.

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.