vmwarelicense12
Enthusiast
Enthusiast

Enable TRIM/UNMAP on vSAN

As I understand TRIM/UNMAP is disabled pr. default on vSAN 6.7.u1 (the version we are using).

so i would like to enable it on our vSAN production.

Enabling it is easy to do, but is there something is should keep in mind before doing so?

When enabled how do I then ensure that Linux/Windows OS automatically free unused space?

Tags (1)
0 Kudos
3 Replies
TheBobkin
VMware Employee
VMware Employee

Hello vmwarelicense123​,

The steps for enabling this on the cluster, what you need to check/configure on the Guest-OSes and how to monitor it etc. can all be found here:

UNMAP/TRIM Space Reclamation on vSAN | vSAN Space Efficiency Technologies | VMware

Bob

0 Kudos
vmwarelicense12
Enthusiast
Enthusiast

I have seen that link, but I just need to know it it is safe to enable on our production environment, or I need to consider something first?

0 Kudos
TheBobkin
VMware Employee
VMware Employee

vmwarelicense123​ , please read the article, it clearly states that this operation can be IO intensive and thus you should monitor the performance of the cluster while doing this (and obviously it is implied that you should stop/slow down if you are negatively impacting other workloads):

Performance Impact

This process does carry performance impact as IO must be processed to track pages that are no longer needed. The largest impact will be UNMAP's issued against the capacity tier directly. For environments with high deletions performance should be monitored.

No one can (nor should) respond to your question with 'Yes this is safe' or 'No this is not safe' to do in a production environment as this would be ignoring the multitude of variable that determine this. For example: whether your cluster is well configured and/or suited for high performance workloads, whether your cluster is already being pushed to the brink of its storage capabilities (this can also vary depending on what else is being done in the cluster e.g. time of day, backups running, large provisioning or database jobs), how much data you are unmapping etc. .

The only way you are going to be able to assess this is to monitor the clusters performance while doing a limited (and preferably quantified) amount of unmap operations, preferably done at relatively quieter times of day (if there are any) and when there are less other things that will be putting load on the cluster (e.g. backups, provisioning/migrations or anything else that is IO intensive), then once you have established this baseline (and have confirmed it is not having negative impacts for other workloads), increase the amount being done until you have a better idea of how much extra load you can put on this cluster. Also note that just because it has no/minimal impact in one cluster does not mean it will be the same for another cluster.

Bob