Yellow Bricks

by Duncan Epping

6.2

How is Virtual SAN doing? 3500 customers reached!

· ·

Are you wondering how Virtual SAN is doing? The recent earnings announcement revealed that… Virtual SAN is doing GREAT! Over 3500 customers so far (21 months after the release!) and 200% Year over Year growth. I loved how Pat Gelsinger described Virtual SAN: “VMware’s simple enterprise grade native storage for vSphere”. It doesn’t get more accurate and to the point than that, and that is how people should look at it. vSphere native storage, it just works. Just a couple of things I wanted to grab from the earnings call (transcript here) that I think stood out with regards to VSAN:

and I – having been three years at EMC as a storage company, part of it is it just takes a while to get a storage product mature, right, and that – we have crossed the two-year cycle on VSAN now. The 6.2 release, as I would say, checks all the boxes with regard to key features, capabilities and so on, and we are, I’ll say right on schedule, right, we’re seeing the inflection point on that business, and the 6.2 release really hit the mark in the marketplace very well.

I’d say we’re clearly now seen as number one in a hyper-converged infrastructure space, and that software category we think is going to continue to really emerge as a powerful trend in the industry.

I think Zane mentioned a large financial services company. We had a large EMEA retailer, a large consumer goods manufacturer, a large equipment engines company, and each one of these is really demonstrating the power of the technology.

We also had good transactional bookings as well, so it wasn’t just in big deals but also transactional performance was good. So the channel participation is increasing here.

So we really left Q1 feeling really good about this area, and I’m quite bullish about its growth potential through the year and 2017 and beyond.

I think I don’t need to add anything other than… Go VSAN!

Can I still provision VMs when a VSAN Stretched Cluster site has failed?

· ·

A question was asked internally if you can still provision VMs when a site has failed in a VSAN stretched cluster environment. In a regular VSAN environment when you don’t have sufficient fault domains you cannot provision new VMs, unless you explicitly enable Force Provisioning, which most people do not have enabled. In a VSAN stretched cluster environment this behaviour is different. In my case I tested what would happen if the witness appliance would be gone. I had already created a VM before I failed the witness appliance, and I powered it on after I failed the witness, just to see if that worked. Well that worked, great, and if you look at the VM at a component level you can see that the witness component is missing.

Next test would be to create a new VM while the Witness Appliance is down. That also worked, although I am notified by vCenter during the provisioning process that there are less fault domain than expected as shown in the below screenshot. This is the difference with a normal VSAN environment, here we actually do allow you to provision new workloads, mainly because the site could be down for a longer period of time.

Now next step would be to power on the just created VM and then look at the components. The power on works without any issues and as shown below, the VM is created in the Preferred site with a single component. As soon though as the Witness recovers the the remaining components are created and synced.

Good to see that provisioning and power-on actually does work and that behaviour for this specific use-case was changed. If you want to know more about VSAN stretched clusters, there are a bunch of articles on it to be found here. And there is a deepdive white paper also available here.

Virtually Speaking Podcast Episode 7 – VSAN Customer Use Cases

· ·

The Storage and Availability Tech Marketing team runs a podcast called Virtually Speaking Podcast every week. This week it was my turn to be a guest on their show. We spoke about VSAN / use cases / all-flash and various other random topic that came up. It was a fun conversation, and I am going to try to tune in more often for sure. (Although I do listen to it every week, I haven’t been able to join live…) Make to sign up, so you don’t miss out on an episode. Listen to Pete Flecha, John Nicholson and I through the below player. I hope you will enjoy it as much as I did.

VSAN 6.2, checksumming where you should

· ·

Today I was talking to a customer about the checksum functionality that is part of VSAN 6.2. They asked me if VSAN was still prone to bit rot scenarios, and they mentioned other potential bottlenecks like no data locality… It was fairly straight forward to set it straight as with VSAN 6.2 we do have a “host local read cache” and we checksum all data by default on write and on read, and yes we also scrub the disk to pro-actively detect potential issues. I’ve already written about these features a couple of times, but today when explaining to this customer how VSAN’s checksumming functionality is implemented the customer immediately realized the benefits of our hypervisor based implementation. Note that the diagram below shows the VM running on a different host then where the actual data is located, the VM could easily be running on the same host as where one of the replicas is located…

vsan 6.2 checksumming

When it comes to checksums, these are calculated on the host where the VM resides. Why? Well you can imagine that you will want to protect your data against all types of potential corruption and issues. Not just when at rest, but you want to calculate the checksum before the data leaves the host, before it is replicated / distributed, before it hits the disk controller, before it goes to persistent media! Even if a bit flips while traveling across the network to be written to persistent media this will be detected and corrected.That is exactly what VSAN does, which is unique. As the title says, checksumming where you should… at the source.

Migrating from Hybrid to All-Flash VSAN

· ·

I had this question twice last week and I went through the exercise in the lab so I figured I would share the experience. Migrating from Hybrid to All-Flash VSAN is pretty straight forward, and is pretty much an rolling migration. One thing I want to point out is that you need to do the full migration first before you enable any dataservices (dedupe/compression/raid-5/6). This is how you do it:

  1. Open the vSphere Web Client.
  2. Click the Hosts and Clusters tab.
  3. Select the cluster which you want to migrate to all-flash Virtual SAN.
  4. Click the Manage tab.
  5. Click Settings.
  6. Click Disk Management.
  7. Select the first Disk Group and click the Remove Disk Group icon
  8. Select Full data migration and click Yes
  9. Remove the physical HDDs from the host
  10. Add the new Flash devices to the host
  11. Ensure there are no partitions on the flash devices
  12. Ensure they are marked as flash devices
  13. Now create a new Disk Group on this host by clicking the “Create a new disk group” button
  14. Select the Caching Device
  15. Select the Capacity Devices
  16. Click OK

Repeat above steps for each host in the cluster. When finished upgrading all hosts in your cluster you can now enable your dataservices and/or change policies.