Calculating inflated Capacity for Deduplication
Article ID: 327051
Updated On:
Products
Issue/Introduction
When Deduplication is enabled on a vSAN cluster and you are planning on entering “Full data migration” maintenance mode.
it is important to note that the inflight data will not be de-duplicated as it is transferred between disk groups.
As a result, we must account for the amount of inflation that can occur at a capacity disk level prior to entering this decom state.
Environment
VMware vSAN 6.0.x
VMware vSAN 7.0.x
VMware vSAN 8.0.x
Resolution
With the release of 6.7 U3 there is a new screen in the Web Client that checks if there is enough space to do a full data migration ( see here for details ).
You can also run a pre-check to determine the outcome of putting a Host in Maintenance Mode.
For releases older than 6.7 U3: Manually calculating the amount of inflation:
Note: The below calculations shows rough figure, they do not depict actual amount of inflation.
1.) Run esxcli vsan storage get to determine if Deduplication/Compression is enabled. Note the VSAN UUID.
Example: esxcli vsan storage get
naa.500003972c8884e9:
Device: naa.500003972c8884e9
Display Name: naa.500003972c8884e9
Is SSD: true
VSAN UUID: 5221c646-88b6-5622-f995-0xxxxxxxxxxb
VSAN Disk Group UUID: 524f4373-2059-edb9-4023-9xxxxxxxxxxe
VSAN Disk Group Name: naa.500003972c88a7a1
Used by this host: true
In CMMDS: true
On-disk format version: 3
Deduplication: true
Compression: true
Checksum: 14403806300994667981
Checksum OK: true
Is Capacity Tier: true
2.) Capture the “capacityUsed” and “logicalCapacityUsed” values from DISK_STATUS
Example: cmmds-tool find -f json -t DISK_STATUS -u 5221c646-88b6-5622-f995-0xxxxxxxxxxb
{
"uuid": "5221c646-88b6-5622-f995-0xxxxxxxxxxb",
"owner": "580eb05a-3b56-6f85-2358-9xxxxxxxxxx1",
"health": "Healthy",
"revision": "2984",
"type": "DISK_STATUS",
"flag": "2",
"minHostVersion": "3",
"md5sum": "95251a137dab381e8dbb5ec9cec5813b",
"valueLen": "288",
"content": "{\"capacityUsed\": 848886642881, \"l2CacheUsed\": 0, \"l1CacheUsed\": 0, \"writeConsolidationRatio\": 10, \"avgReadsPerSecond\": 0, \"avgWritesPerSecond\": 0, \"avgThroughPutUsed\": 8192, \"avgReadServiceTime\": 0, \"avgReadQueueTime\": 0, \"avgWriteServiceTime\": 0, \"avgWriteQueueTime\": 0, \"avgDiskReadsPerSec\": 0, \"avgDiskWritesPerSec\": 0, \"avgSSDReadsPerSec\": 0, \"avgSSDWritesPerSec\": 0, \"estTimeToFailure\": 0, \"numDataComponents\": 32, \"logicalCapacityUsed\": 1274401521664, \"physDiskCapacityUsed\": 7717151298919}",
"errorStr": "(null)"
},
3.) Perform Calculation using the above example
\"capacityUsed\": 848886642881,
\"logicalCapacityUsed\": 1274401521664,
To figure out the current Dedupe ratio for the disk the calculation is "logicalCapacityUsed" / "CapacityUsed ".
1274401521664 / 848886642881 = 1.5x dedupe ratio
Cap after Inflation = logicalCapacityUsed (divide by 1024 three times to get GiB value)
1274401521664 / 1024 / 1024 / 1024 = 1186.88 GiB raw
This can be repeated for each disk to determine if there is enough raw capacity in the cluster.
Scripting the Calculation live:
To do this live on a host for all disks run the following on the host before entering decom to figure out how much raw capacity will be generated.
esxcli vsan storage list |grep "VSAN UUID"|awk '{print $3}'|while read i;do totalUsed=$(cmmds-tool find -f json -t DISK_STATUS -u $i |grep -o "\"logicalCapacityUsed\": [0-9]*"|awk '{print $2 / 1024 / 1024 / 1024}');echo "$i: Approx. $totalUsed GiB without dedupe/compression";done
Example output.:
520e35f5-6cfd-de13-eed5-9xxxxxxxxxxf: Approx. 0 GiB without dedupe/compression
5280832b-f606-89c7-e481-0xxxxxxxxxx1: Approx. 72.7656 GiB without dedupe/compression
52b70846-56cc-d63f-a3bc-1xxxxxxxxxx3: Approx. 6.48828 GiB without dedupe/compression
Feedback
