Yellow Bricks

by Duncan Epping

encryption

Disk format change going from 6.x to vSAN 6.6?

· ·

Internally I received a comment around the upgrade to 6.6 and the disk format version change. When you upgrade to 6.6 also the version of  disk changes, it goes to version 5. In the past with these on-disk format changes a data move was needed and the whole disk group would be reformat. When going from vSAN 6.2 (vSphere 6.0 U2 that is!) to vSAN 6.6 there is no data move needed. The update is simply a metadata update, and on the average cluster will take less than 20 minutes.

When introducing encryption in to the environment you will need to evac data though as this will be a reformat of the disk. Reason for it being is that the disk will need to be encrypted and so will the data. This doesn’t mean however that if you want to “rekey” your environment a full format and data move is needed, vSAN Encryption has the ability to do a so called “shallow rekey” which means that the Key Encryption Key (KEK) will be replaced (see animated gif below), but not the Data Encryption Key (DEK). It is possible to do a deep rekey, but this will mean a full reformat and data evac of all disk groups. I hope that clears things up.

VMware vSAN 6.6 demo: vSAN Encryption

· ·

Yesterday I posted a quick video overview of a couple new features that are part of vSAN 6.6. (haven’t seen it, go watch that one first!) I mentioned in that demo that I would potentially do one on Encryption. As I had over a dozen people asking already I figured I would throw a demo together today. Build an environment in our development cloud and below is the result. In the demo we will show how to configure vSAN Encryption and more. Oh, 1080p version can be found here. Enjoy.

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.