VMware vSAN 6.6 – What’s New for Day 2 Operations?

VMware has just announced vSAN v6.6, with over 20 new features. While new and shiny features are nice I’d like to highlight a couple that I think might be undervalued from release feature-set perspective, but highly valuable in day to day operations of a vSAN environment, otherwise known as Day 2 operations.

vSAN Configuration Assist is one such new feature. While it’s true that it helps first time configuration of a greenfield installation with vSAN (no more bootstrapping, yay!), it also helps with Day 2 operations.

It helps configure new hosts added to an existing vSAN enabled cluster, but it also makes it possible to automate updating of IO controllers, both firmware and drivers directly from within vCenter. As everyone should know by now, vSAN is highly dependent on drivers and firmware being on supported levels. This improvement helps the improved vSAN Health Check (Enhanced Health Monitoring) alert you when new and verified drivers/firmware are available, and if the controller tools are available on the ESXi host, it can also update the firmware for you.

Directly from vCenter, utilising maintenance mode like you’re used to from patching your ESXi hosts from VMware Update Manager (even if it’s not integrated into VUM at this point).

This new features takes the vSAN HCL list to a new level, it’s no longer just a list over supported IO controllers and their firmware and drivers, it’s a now also a software distribution point. At the moment Dell EMC, Fujitsu, Lenovo and SuperMicro are all supported vendors for this new distribution model, hopefully the rest will follow suit quickly.

The second feature I would like to highlight as a Day 2 operations enhancement, is the new vSAN Cloud Analytics feature. If you participate, in the Customer Experience Improvement Program (CEIP), it will enable custom alerting for your environment, based on your own environment. For instance, if a new Knowledge Base article is published, that pertain to your specific setup, it will alert you about it. One example might be if you have Intel X710 NICs, which can cause PSODs — Wouldn’t it be nice if you got alerted that this might be an issue, and then told how to remediate it? Well, with vSAN 6.6 you’ll get exactly that.

With vSAN 6.6 you get both automated, and verified, firmware/driver upgrades, as well as proactive alerting for potential issues through the hive-mind that is the analytics service. This is what VMware calls Intelligent Operations and Lifecycle Management in this release, and it’s really hard to argue with that.

Of course, vSAN 6.6 provide other Day 2 Operations enhancements as well, like Degraded Device Handling (DDH), Simplified Stretched Cluster Witness replacement procedures, Capacity and Policy Pre-Checks and access to the vSAN control plane trough the ESXi Host Client, but I’ll leave those for later posts.

VMware vSAN: 2016 Edition

Both in 2014 and in 2015 I wrote pieces on the current status of VMware vSAN, and it’s time to revisit it for 2016.

My previous posts:

2014: VSAN: The Unspoken Future
2015: VMware VSAN: More than meets the eye.

vSAN 6.5 was released with vSphere 6.5, and brings a few new features to the table:

  • Virtual SAN iSCSI Target Service
  • Support for Cloud Native Apps running on the Photon Platform
  • REST APIs and Enhanced PowerCLI support
  • 2-Node Direct Connect
    • Witness Traffic Separation for ROBO
  • All-Flash support in the standard license (Deduplication and compression still needs advanced or enterprise)
  • 512e drive support

In my opinion, the first three items on that list are the most interesting. Back in 2015 I talked about VMware turning vSAN into a generic storage platform, and the new Virtual SAN iSCSI Target Service is a step in that direction. This new feature allows you to share vSAN storage directly to physical servers over iSCSI (VMware is not positioning this as a replacement for ordinary iSCSI SAN arrays), without having to do that through iSCSI targets running inside a VM.

The same goes for Cloud Native Apps support, where new applications can talk with vSAN directly through the API, even without a vCenter!

Both of these bypass the VM layer entirely, and provide external connectivity into the core vSAN storage layer.

Clearly these are the first steps towards opening up vSAN for external usage, expect to see more interfaces being exposed externally in future releases. An object store resembling Amazon S3 doesn’t sound too far fetched, does it? Perhaps even with back-end replication and archiving built-in. Stick your files in a vSAN and let the policies there determine which object should be stored locally, and which should be stored on S3? Or which should be replicated to another vSAN cluster, located somewhere else?

Being able to use SBPM for more than VM objects is a good idea, and it makes management of those non-VM workloads running in your vSAN cluster easier to monitor and manage.

Sure the rest of the items on the list are nice too, the two 2-node Direct Connect feature allows you to connect two nodes without the need for external 10 GbE switches, cutting costs in those scenarios. All-Flash support on all license levels is also nice, but as is the case with 512e drive support, it’s natural progression. With the current price point on flash devices, the vSAN Hybrid model is not going to get used much going forward.

All in all, the vSAN 6.5 release is a natural evolution of a storage product that’s still in it’s infancy. That’s the beauty of SDS, new features like this can be made available without having to wait for a hardware refresh.

#vDM30in30 progress:

Running a VSAN PoC – Customer reactions

I recently set up a VMware Virtual SAN 6.1 Proof-of-Concept for a customer, configuring a 3-node cluster based on the following setup:

Hardware:c04411605

  • HP ProLiant DL380 G9
  • 2 x Intel Xeon E5-2680 @ 2.50Ghz w/12 Cores
  • 392 GB RAM
  • 1 x Intel DC 3700 800GB NVMe
  • 6 x Intel DC S3610 1.4TB SSD
  • HP FlexFabric 556FLR-SFP+ 10GBe NICs

Virtual SAN Setup:

Since this was a simple PoC setup, the VSAN was configured with 1 disk group pr host with all 6 Intel DC S3610 drives used as the capacity layer, and the Intel DC P3700 NVMe cards set up as the cache. This gives a total of 21.61TB of usable space for VSAN across the cluster. With the Failures-To-Tolerate=1 (the only real FTT policy available in a three node 6.1 cluster) policy this gives 10.8TB of usable space.

vMotion and VSAN traffic were set up to run on a separate VLANs over 2 x 10GBe interfaces, connected to a Cisco backend.

Customer reaction:

After the customer had been running it in test for a couple of weeks, I got a single line email from them simply stating: “WOW!“.

They were so impressed with the performance (Those NVMe cards are FAST!) and manageability of the setup that they have now decided to order an additional 3 hosts, bringing the cluster up to a more reasonable 6 hosts, in a metro-cluster setup, and upgrade to VSAN 6.2 as soon as it’s available.  The compression, deduplication and erasure coding features of 6.2 will increase their available capacity just by upgrading. At the same time, adding three new hosts will effectively double the available physical disk space as well, even before the 6.2 improvements kick in.

VSAN will be this customers preferred storage platform going forward and they can finally move off they existing monolithic, and expensive, FC SAN over to a storage solution that outperforms it and greatly reduces complexity.