Suppose you have Erasure Coding (EC-X) enabled on all of your containers. Over time you find that workload structure and type has changed and is no longer suitable for EC-X. What do you do?
Since migrating VMs between containers is a disruptive task alternative approach would be to disable EC-X on a container.
In preparation for the task there are a couple of factors we recommend are taken into consideration:
- There will be increased I/O at the storage layer. Once EC-X is disabled on a container additional data will be written to the container and replicated. The influx of the data can be estimated by reversing EC-X gains.
- Expect temporary increase of storage utilisation in addition to calculations above. Parity data will not be removed immediately. Parity data size can be reverse calculated based on the same EC-X gains estimates.
- There are no guardrails in terms of storage utilisation once EC-X is disabled. Please make sure there is sufficient space for the decoded data to be written — this includes free space overhead. When disabling EC-X on more than one container staging the change may be beneficial i.e. disabling EC-X on one container at a time.
- Unused parity blocks will be removed as part of background Curator jobs. It is difficult to estimate the time required to complete the decoded writes as well as removal of the unused parity block as the time required depends on cluster utilisation rates, size of the data to be written, size of the parity, replication factor, etc.
We recommend to open a pre-emptive case with Nutanix Support team. An SRE will be able to accurately access data compression, state of Curator and Stargate tasks and more.
Some more information Nutanix Bible: Erasure coding