With Erasure Coding we can shrink write-cold data even more to have less used space on the extend store. I’m not going to explain how this works as Nutanix has done a great job explaining this already (Link, Link). In this blog post I want to show when Erasure Coding kicks in and how much data reduction I got.
My lab is a 4 node cluster (which is the minimum nodes to enable Erasure Coding) so I will have a saving approximately 25%. This is because I have a strip size of 2/1 (2 data blocks and 1 parity block) and off course 1 empty block for the rebuild.
Lets put this to the test. I have created the following storage container:
The “Erasure-Coding” storage container is create with no storage optimisation enabled except Erasure Coding.
There are 4 Windows virtual machine created with their bootdisk (100GB) on the default workload container and a 200GB data disk on the erasure coding storage container:
Then I generated 100GB of random data on each virtual machine on the disk which is on the erasure coding enabled storage container:
I’ve waited a full curator scan to be sure storage optimalisation is up to data 😉
As you can see in the screenshot the actual data is still 400GiB on the Storage Container:
And to be more specific the curator reduction report is also showing the same numbers (800GB as this is the raw data, as I’m running Replication Factor 2).
Now lets wait for 7 days. To see what erasure coding is doing with the data.
And the curator data reduction report looks like this:
Please keep in mind that erasure coding is only for specific type of workloads, for example:
- Write once, read many (WORM) workloads;
- Backups;
- Archives;
- File servers;
- Log servers;
- Email (depending on usage).
