SSD Caching with 3.0.2 and above

IN THIS ARTICLE 

Provides an overview of Qumulo's LRU eviction based SSD caching in versions 3.0.2 and above of Qumulo Core

REQUIREMENTS

• Cluster running Qumulo Core 3.0.2 and above

DETAILS

In Qumulo Core, the SSDs are used to store data layout information, provide a fast persistence layer for data modifications coming into the cluster, and cache file system data and metadata for fast data retrieval. In contrast, the HDDs are used to store data that is accessed less frequently to ensure that the data is still available, but not taking up valuable SSD space.

Prior to 3.0.2, the FIFO-based (First In First Out) SSD caching feature allowed data to be written to the HDD while still residing on the SSD and further evict data from the SSDs based on the order of the writes. This results in an increased burst write window since we are able to write to a larger portion of the SSD at burst speed without waiting for any writes to HDD. Additionally, data that has been recently written has an increased likelihood of being on the SSD and is available for faster retrieval (since eviction of data is approximately based on the order of writes). The article SSD Caching with 3.0.1 and below explains this FIFO policy in more detail.

In Qumulo Core 3.0.2, we replaced the FIFO policy with an LRU (Least Recently Used) eviction policy that not only retains data that has been recently written to SSDs, but also the data recently read from SSDs. The data that is least recently read from or written to the SSD will be evicted first, while new reads and writes have a higher chance of remaining on the SSD. This LRU eviction policy results in faster retrieval of data and metadata that are frequently accessed on your cluster.

Read Promotion

The read promotion algorithm promotes data from the HDDs back up to the SSDs to enhance read performance. All data read from the HDDs has to go through a two-stage check that requires it to be read at least twice before being promoted. The first time a data block is read from the HDD, we’ll apply a filter that decides whether it may be promoted. If the filter is passed, the data will be added to the cache that tracks recently read data. On a subsequent read, if the data is still in the cache, the data will be selected for promotion to the SSD. Our two-stage check provides a property called scan-resistance, meaning that reading all files once (for example, as part of a backup job) doesn’t cause irrelevant data to be promoted to the SSD. 

Additionally, we favor promoting smaller read sizes that map to the more IOPS-heavy portion of a workload because SSDs provide a tremendous IOPS boost over HDDs. Smaller reads have the highest probability of promotion over subsequently larger reads, or reads that represent the portion of a workload that is serviced well by the hard drives.

Note that the new LRU eviction policy does not change how we handle read promotion from HDD to SSD. Data and metadata that are promoted to the SSD are also covered by the LRU eviction policy, newly-promoted data has a smaller likelihood of being evicted compared to the data that currently resides on the SSD, and continuous reads on the promoted data will help extend their tenancy on SSD.

RESOLUTION 

You should now have an overall understanding of  Qumulo's LRU eviction based SSD caching in versions 3.0.2 and above of Qumulo Core

ADDITIONAL RESOURCES

 SSD Caching with 3.0.1 and below

QQ CLI: Comprehensive List of Commands

Like what you see? Share this article with your network!