• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

vSAN 8.0 ESA and Compression by default?

Duncan Epping · Oct 24, 2022 · 8 Comments

Starting with vSAN 8 ESA (Express Storage Architecture) how data services have been implemented has changed significantly compared to the Original Storage Architecture. In vSAN OSA compression (and deduplication) happens before the data is stored on disk on each of the hosts the data is stored on. With vSAN 8.0 ESA this has changed completely. With vSAN ESA compression actually happens all the way at the top of the architecture, as shown and explained in the diagram/slide below.

Now, the big benefit of course of this is that if you compress the data first, and you compress the data from let’s say 4K to 2K then only 2K needs to be sent over the network to all hosts where the data is being stored. Not only that, if data needs to encrypted then only 2KB needs to be encrypted, and of course when you checksum the data then also only 2KB needs to be checksummed. So what are the savings here when encryption is enabled on ESA vs OSA?

  • Less data to send over the network
  • Less data to encrypt when encryption is enabled
  • Less data to checksum
  • Compression only takes place on the source host, and not on the destination hosts, so a lower number of CPU cycles is used for each IO

Also, with vSAN ESA the granularity in terms of compression is also different than with vSAN OSA. With OSA vSAN would compress from 4KB down to 2KB and that is it. If it couldn’t compress down to 2KB then it would not compress the block. With vSAN ESA that has changed. vSAN ESA will aim to always compress, but of course, it needs to make sense. No point in compressing 4KB down to 3.8KB. And yes, vSAN ESA will also go beyond 2KB if possible. As mentioned above in the screenshot, theoretically it is possible to reach an 8:1 compression ratio per 4KB block.

Now, the other difference is that you enable/disable compression through policy. How do you do this? When you create a policy for ESA you have the options in Storage Rules as shown in the screenshot below, “No Preference” (Default), “No space efficiency”, “Compression only”, and “Deduplication and compression”.

Now, let’s be clear, “Deduplication and compression” is not an option for ESA as “Deduplication” has not been implemented just yet. When you configure either of the other three options the outcome is as follows:

  • No preference – Compression enabled
  • No space efficiency – Compression disabled
  • Compression only – Compression enabled

Can you validate this? Yes, you can, and of course, I did to show you how that works. I created three policies with the above options selected for each respectively. I also created three VMs, with each of them having the appropriate policy selected as you can see in the screenshot below. VM_CompDisabled has the policy “Comp_Disabled” associated with it, and of course, that policy had “No space efficiency” selected.

Now, where can you see if the object actually has compression enabled or disabled? Well, this is where it becomes a bit more complex, unfortunately (yes, I filed a feature request). If you want to validate it you will have to go to the command line and check the object itself. Simply copy the UUID you see in the screenshot above and use the command “cmmds-tool find -t DOM_OBJECT -u <UUID>“. When you run this command you will receive a lengthy output, and that output will contain the following string,("compressionState" i1), when compression is disabled.

Compression Enabled on vSAN ESA Object

One more thing I want to mention, as compression does not happen on a “physical” disk layer, or on the “disk group layer” as they do with vSAN OSA. If you switch between policies where compression is enabled/disabled, you will not see a massive rewrite of data occurring. When you switch from Disabled to Enabled only newly written data will be compressed! Same applies to when you switch back. Only newly written data will be impacted by the policy change.

For those who prefer to hear/see me going through the UI to disable compression on a per-VM basis, make sure to watch the below demo!

Related

Server, Storage, vSAN esa, express storage architecture, vsan, vsan 8, vsan esa

Reader Interactions

Comments

  1. Steffen Richter says

    25 October, 2022 at 10:49

    Hi Duncan, thanks for the technical insights! Your last sentence(s) caught my attention: “Only newly written data will be impacted by the policy change.”

    Is there also a way to enforce something like a “rolling upgrade” of the assocaited objects for space-efficiency reasons (or to fully remove it), to enforce the desired capabilities for future as well as existing data?

    Reply
    • Duncan Epping says

      25 October, 2022 at 11:45

      No there’s not at the moment.

      Reply
  2. [email protected] Tech/Youtube始めました/VMware黒本著者 (@lab8010) says

    25 October, 2022 at 13:31

    Hi Duncan,
    Thanks for your detail article and I always enjoy your blog.

    I have some questions for this feature.
    1. If the data can not compress 50% or more(4K to 2K or less), is the data sent as original size?

    2. Is “Dedupe” also supported vSNA ESA? Or is it only for vSAN OSA? I read vSAN 8.0 docs but could not find about dedupe wirh vSAN ESA.

    Again thanks for your information sharing.

    Reply
    • Duncan Epping says

      25 October, 2022 at 14:23

      ESA works differently than OSA. With OSA compression always was from 4K to 2K. If it wasn’t 2K we wouldn’t bother, and we also wouldn’t go below 2K either. With ESA if we can compress from 4K to 3K or 4K to 1K we will do that.

      Reply
    • Duncan Epping says

      25 October, 2022 at 14:24

      Deduplication is not supported yet on vSAN ESA, that is only available for OSA with 8.0.

      Reply
  3. [email protected] Tech/Youtube始めました/VMware黒本著者 (@lab8010) says

    27 October, 2022 at 08:34

    Hi Duncan, thanks a lot for your detail answers for me.

    Reply
  4. RayD says

    11 November, 2022 at 06:25

    Hi Duncan, do you know if I can upgrade in-place from OSA 8.x to ESA 8.x if my hardware supports ESA?

    Reply
    • Duncan Epping says

      11 November, 2022 at 09:34

      At this point there’s no in-place upgrade capability.

      Reply

Leave a Reply Cancel reply

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007), the author of the "vSAN Deep Dive", the “vSphere Clustering Technical Deep Dive” series, and the host of the "Unexplored Territory" podcast.

Upcoming Events

May 24th – VMUG Poland
June 1st – VMUG Belgium

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2023 · Log in