Yellow Bricks

by Duncan Epping

Change of dates: VMworld Europe now September 11th until 14th!

· ·

Just received the confirmation / news that VMworld Europe has a changed date. It will be held in Barcelona again in 2017, however the date is now September 11th until 14th! So make sure to write this down in your calendar already, personally I think it is great… the closer we can get to Barcelona summer, the better! Note that VMworld US is once again in Mandelay Bay in Las Vegas, and will be held from August 27 – August 31, 2017. See you there next year.

Oh and before I forget, Metallica will have a new album out… just saying @VMworld Event Team. #MetallicaAtVMworld

Benchmarking an HCI solution with legacy tools

· ·

I was driving back home from Germany on the autobahn this week when thinking about 5-6 conversations I have had the past couple of weeks about performance tests for HCI systems. (Hence the pic on the rightside being very appropriate ;-)) What stood out during these conversations is that many folks are repeating the tests they’ve once conducted on their legacy array and then compare the results 1:1 to their HCI system. Fairly often people even use a legacy tool like Atto disk benchmark. Atto is a great tool for testing the speed of your drive in your laptop, or maybe even a RAID configuration, but the name already more or less reveals its limitation: “disk benchmark”. It wasn’t designed to show the capabilities and strengths of a distributed / hyper-converged platform.

Now I am not trying to pick on Atto as similar problems exist with tools like IOMeter for instance. I see people doing a single VM IOMeter test with a single disk. In most hyper-converged offerings that doesn’t result in a spectacular outcome, why? Well simply because that is not what the solution is designed for. Sure, there are ways to demonstrate what your system is capable off with legacy tools, simply create multiple VMs with multiple disks. Or even with a single VM you can produce better results when picking the right policy as vSAN allows you to stripe data across 12 devices for instance (which can be across hosts, diskgroups etc). Without selecting the right policy or having multiple VMs, you may not be hitting the limits of your system, but simply the limits of your VM virtual disk controller, host disk controller, single device capabilities etc.

But there is even a better option, pick the right toolset and select the right workload(Surely only doing 4k blocks isn’t representative of your prod environment). VMware has developed a benchmarking solution that works with both traditional as well as with hyper-converged offerings called HCIBench. HCIBench can be downloaded for free, and used for free, through the VMware Flings website. Instead of that single VM single disk test, you will now be able to test many VMs with multiple disks to show how a scale-out storage system behaves. It will provide you great insights of the capabilities of your storage system, whether that is vSAN or any other HCI solution, or even a legacy storage system for that matter. Just like the world of storage has evolved, so has the world of benchmarking.

vSphere Replication 6.5, 5 minute RPO for ALL!

· ·

I just noticed the following in the vSphere Replication 6.5 release notes which I felt was worth sharing:

5-minute Recovery Point Objective (RPO) support for additional data store types – This version of vSphere Replication extends support for the 5 minute RPO setting to the following new data stores: VMFS 5, VMFS 6, NFS 4.1, NFS 3, VVOL and VSAN 6.5. This allows customers to replicate virtual machine workloads with an RPO setting as low as 5-minutes between these various data store options.

We have had this for vSAN in specific for a while now, but I hadn’t realized yet that we were enabling this for all sorts of datastores in this release. Definitely a great reason to move up to vSphere 6.5 and re-evaluate which VMs can do with a 5 minute RPO and use this great replication mechanism that just ships with vSphere for free! More info found in the release notes here.

If you like to know more about the 6.5 release visit this page with the links to all docs/downloads by William Lam.

The difference between VM Encryption in vSphere 6.5 and vSAN encryption

· ·

More and more people are starting to ask me what the difference is between VMCrypt aka VM Encryption and the beta feature we announced not to long ago called vSAN Encryption. (Note, we announced a beta, no promises were made around dates or actual releases or releasing of the feature.) Both sounds very much the same and essential both end up encrypting the VM but there is a big difference in terms of how it is implemented. There are advantages and disadvantages to both solutions. Lets look at VM Encryption first.

VM Encryption is implemented through VAIO (vSphere APIs for IO Filters). The VAIO framework allows a filter driver to do “things” to/with the IO that a VM sends down to a device. One of these things is encryption. Now before I continue, take a look at this picture of where the filter driver sits.

As you can see the filter driver is implemented in the User World and the action against the IO is taken at the top level. If this for instance is encryption then any data send across the wire is already encrypted. Great in terms of security of course. And all of this can be enabled through policy. Simply create the policy, select the VM or VMDK you want to encrypt and there you go. So if it is that awesome, why vSAN Encryption?

Well the problem is that all IO is encrypted at the top level. This means that it is received in the vSAN write buffer fully encrypted, then the data at some point needs to be destaged and is deduplicated and compressed (in all-flash). As you can imagine, encrypted blocks do not dedupe (or compress) well. As such in an all-flash environment with deduplication and compression enabled any VM that has VM Encryption through VAIO enabled will not provide any space savings.

With vSAN Encryption this will be different. The way it will work is that it will provide “encryption at rest”. The data travels to the destination unencrypted then when it reaches its destination it is written encrypted to the cache tier, then it is decrypted before it is destaged, and it will be encrypted after it is deduplicated and/or compressed again. This means that you will benefit from space saving functionality, however encryption in this case is a cluster wide option, which means that every VM will be encrypted, which may not be desirable.

So in short:

  • VM Encryption (VAIO)
    • Policy based (enable per VM)
    • Data travels encrypted
    • No/near zero dedupe
  • vSAN Encryption
    • Enabled on a cluster level
    • Data travels unencrypted, but it is written encrypted to the cache layer
    • Full compatibility with vSAN data services

I hope that clarifies why we announced the beta of vSAN Encryption and what the difference is with VM Encryption that is part of vSphere 6.5.

Virtual SAN >> vSAN, and grown to 5500 customers!

· ·

Not that it is a big deal, but as some people are like me they probably prefer to use the right name. As of this week Virtual SAN was renamed to vSAN. I am not sure we will see the change in the product in 6.5 (I doubt it) and even the website changes will take a while, but expect to see this soon.

Oh, and before I forget, there was the Q3 earnings announcement, vSAN is still growing strong, 5500 customers at the moment! And lets not forget: “software license bookings continue to exceed expectations with vSAN and VxRail increasing over 150% year over year.” I say: Bring on Q4! And I can’t wait for 6.5 to ship 🙂