Follow

About InfiniBox compression

InfiniBox compresses incoming writes for both thick and thin entities. However, the saved capacity is managed differently, as follows:

  • Thin entities - the savings from data reduction remain available in the pool's physical capacity
  • Thick entities - the savings remains allocated to the entity (thus, cannot be reused.) 
    • Thick entity snapshots - as snapshots are thin entities, the savings remain available in the pool's physical capacity

Using capacity freed from data reduction

Once entities benefit from data reduction they effectively free capacity that can be reused. The freed capacity is returned to the pool and the stroage admin can act as follows:

  • Leave the freed capacity in the pool, allowing any of the pool admins to use it
  • Reduce the pool size, allowing the storage admin to reuse that capacity elsewhere.

Reduction ratio

Data reduction ratios vary, depending on the dataset. For example, virtual machines and databases tend to include many zeros, increasing the data reduction, while data that is encrypted before writing it to the storage does not compress well.

The maximum available reduction ratio is 16:1.

Increased system virtual capacity

As of this InfiniBox release, the ratio between the system physical capacity and system virtual capacity is 1:2.5.

  • InfiniBox systems with an out of the box version 3.0 and up - the ratio is 1:2.5
  • InfiniBox systems that upgrade to 3.0:
    • With ratio below 1:2.5 - the ratio is increased to 1:2.5
    • With ration of 1:2.5 and up - the ratio is not changed 

Introducing compression to an existing InfiniBox system

  • On an existing system, prior to the introduction of the compression feature, all pools and their entities are not compressed.
  • Upon upgrading to an InfiniBox software release that features compression, all existing pools and their entities remain uncompressed
  • When creating a new pool and marking it as compressed, it will be compressed
  • The transition of an entity from a non-compressed pool to a compressed pool is described below.

Default compression behavior

  • System level
    • Upon upgrade to InfiniBox 3.0 or later, the system is set to be compressed by default.
    • This means that all new pools are compressed by default.
    • The default system setting can be changed.
  • Pool level
    • By default, when an InfiniBox system is upgraded to version 3.0 or later, its pools are set to be compressed. All new entities are created with compression (unless manually changed).
    • Existing pool entities are not compressed, unless manually set to do so. 
  • Entity level
    • When an entity is created, the availability of compression is determined at creation time and is inherited from the pool.
    • The compression setting can be changed at any time.

Performance protection

InfiniBox employs multiple mechanisms to make sure that performance is not degraded as a result of compression:

  • Writes:
    • Any write to the storage is first accepted in memory to guarantee minimal latency
    • Only compressed as data is destaged from RAM to persistent media.
    • Only data that is going to be destaged gets compressed (as many writes get overwritten while in the cache, InfiniBox avoids unnecessary compression)
    • Once the data is destaged, it is compressed in sections (sets of consecutive 64KB) increments, creating a large enough dataset to achieve effective compression, but still keeping each of the sections separated. This allows the system to retrieve any section without having to retrieve the entire stripe.
  • Reads:
    • Reads from RAM and SSD do not require decompression
    • Data retrieved from disk is decompressed when loaded into the cache.
Was this article helpful?
0 out of 0 found this helpful

0 out of 0 found this helpful

Comments