Introduction to VNX-Block data compression

Fault symptom:

Data compression is used to save space. do more with less. VNX File/BLOCK has their own Compression function, today we will briefly introduce the VNX-BLOCK of data Compression, from a conceptual understanding of the VNX-BLOCK Compression.

Solution:

VNX Block data compression

The data compression process of the VNX block is incremental to 64 KB. If the 64 KB data can be compressed to save at least 8 KB, the system will compress the data and write it into the LUN. If the saved data volume is less than 8 kB, the data is directly written to the LUN without compression. This reflects the efficiency of the VNX compression function and will never spend any effort on paying too little. Compression can be enabled for any LUN type. After the initial compression process is completed, these LUNs will become ThinLUN, because ThinLUN allows the compression process to return the space to the Pool. For ThinLUN, 8 kB is the smallest space allocation unit. The Pool allocates space to the ThinLUN in units of 1 GB slice. Over time, if the compression can release enough 8 KB blocks, the system returns 1 GB slice to the pool for use by other LUNs. After the LUN is compressed, you will see that the consumed capacity of the LUN/Pool is reduced. This is what ThinLUN itself achieves together with the compression function.

The system also allows you to set the Compression rate. The Compression tab has the following options: High, Medium, and Low. The compression rate determines the compression strength, rather than the data reduction level. The compression rate is set to apply to initial compression, compression of new data, and decompression. The default value is Medium, which can be changed at any time.

After compression is enabled for the raid group lun, the system will perform an online migration to the ThinLUN, which will not cause server I/O interruption. Because the raid group lun is not located in any Pool, you must select a target Pool for the compressed LUN, that is, you can select an existing Pool or create a new Pool, you can also select the migration rate. Only those pools with sufficient space to store raid group lun data will be displayed in the Pool list. After the migration is complete, the original raid group lun will be unbind.

Decompression

The decompression process restores the compressed data to its original size. After compression is disabled for the compressed LUN, the whole LUN is decompressed in the background. After decompression, the RAID Group LUN and ThickLUN will be migrated back to ThickLUN, and the ThinLUN will be migrated to a new ThinLUN with a fragmentation process.

If the space usage of a Pool reaches 91%, the LUN's compression status will change to "system paused", and the host I/O will not be interrupted. This design is designed to ensure that the Pool has enough space for new write. If you decide to continue decompression, you can manually resume the decompression operation, but when the Pool space usage reaches 98%, the system will change the LUN's compression status to "system paused" and will not allow the unzipping operation to be resumed.

Compared with decompression, LUN migration can be another option. If you think the data on the LUN is more active than before, you can directly migrate the data to other LUNs instead of decompression, because migration allows you to move data to a faster disk, as long as the target LUN is larger than or equal to the source LUN.