VMworld 2018 vSAN Roundup – Monday, Aug 27th

VMworld is now officially underway, and as usual, day 1 is full of new announcements. vSAN is no exception. There have been announcements around the next release of vSAN (6.7U1), specific vSAN improvements to VMware Cloud on AWS, a Cloudera Hadoop validation on vSAN and a beta announcements. Since we’ve had quite a number of announcements,  I though I would try to capture them all in one place.

vSAN 6.7U1

There are a whole bunch of new features in this announcement. These range from VMware Update Manager (VUM) support for Firmware during vSAN upgrades, TRIM/UNMAP support for shrinking VMDKs on vSAN, as well as a new quick-start guided cluster creation wizard in vCenter. The quick-start wizard guides the user through the deployment process for vSAN. From an operational perspective, there are now new maintenance mode pre-checks. There is also more detailed insight into cluster capacity usage, as well as historical usage. From an availability perspective, there is also the ability to include “nested fault domains” on standard clusters (available via special request only).  This feature is no longer exclusive to vSAN stretched clusters. Now you can protect your VMs within racks as well as across racks with this secondary failures to tolerate feature. There are other improvements to vSAN in 6.7U1 as well. I’ll do a more detailed write-up once we release this new version.

VMware Cloud on AWS

The first new feature here is a big one. VMware Cloud on AWS is underpinned by vSAN. What was announced today is that vSAN will now be able to consume AWS Elastic Block Store (EBS) rather than physical devices. The big advantage here of course is that customers can now scale storage independent of compute. And since the vSAN datastore size is no longer tied to the capacity of the physical devices in the hosts, it can be significantly larger using EBS. Pretty cool, eh?

And if you are not impressed by that, look at this tweet from Yanbing, Senior VP and GM of our business unit at VMware, highlighting that this year’s Hands on Labs at VMworld are using EBS:

One other vSAN announcement for VMC on AWS relates to the availability of vSAN encryption as a data service. Customers now have the ability to use vSAN encryption with keys stored in AWS Key Management Service (KMS). This enables encryption of data at rest with AWS’s managed service for creating and controlling the encryption keys. All data in VMware Cloud on AWS is encrypted. At no additional cost.

Another cool announcement relates to AWS RDS, the Amazon Relational Database Service. While this is not vSAN specific per-se, Amazon RDS will soon be available on VMware. This means that you can now set up, operate, and scale databases in on-premises and hybrid environments, and migrate them to AWS, or to VMware Cloud on AWS. There is more detail about this on the VMware site here and on the AWS site here.

Cloudera validation for Hadoop on vSAN

In a nutshell, we’ve already had customers running Big Data workloads on vSAN. Cloudera and VMware have now partnered to validate their flavor of Hadoop to run on vSAN. This is pretty cool, and a lot of work has gone on in the background to make this a reality. You can read more about the Cloudera on vSAN validated design on our StorageHub site here.

vSAN Beta Announcement

Last but not least, there was a vSAN Private beta announcement. There are a number of different parts to this beta. The first is vSAN-DP, or vSAN native Data Protection. The second is vSAN File Services. The final part is related to Cloud Native Storage, essentially persistent storage and data services for Cloud Native Applications. I cannot say anymore than that as these are still under NDA, but if you are interested in participating in this private beta, you can register your interest in the beta here.

As you can see, a lot of very cool and interesting announcement in the vSAN space today at VMworld 2018.

4 comments
  1. Hi Cormac,

    Are there any update on this release regarding strect cluster configuration and iSCSI luns?

    We are in the process of implementing a new vsan strecth cluster and our customer has a physical RAC from ORACLE.

    The main idea here is to create a policy using PFTT= and SFTT=1 in order to get only local copies of data because replication is handle by ORACLE RAC.

    I mean, we have 4 ESXi and 1 ORACLE server in each datacenter, so we add iSCSI targets only to local ORACLE server, create the above policy and leave replication in application layer.

    We read in some notes that currently is not supported, because yo can´t configure data locality in iSCSI with strecth cluster although this configuration don´t use data locality rules.

    Thanks in Advanced.

    Marcos Ortiz

    • To the best of my knowledge, there has been no change in our position here Marco – my understanding is that there is still no support for iSCSI on stretched clusters. IIRC, the reason for this is that the iSCSI owner could be located on the other side of the cluster to the storage, thus we would have all iSCSI I/O traversing the inter-site link. Let me ask internally to see if there are any upcoming plans to address it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.