Project

General

Profile

Dynamic data relocation for cache tiering

Summary

Satisfying complex demands for storage capacity and performance is a challenging job faced by cloud storage, especially on resource provision and optimization. For example, some business may has application which is more critical than others, and thus need to relocated the application data to a fast storage media. Another scenario is one specific contents is becoming extremely popular, e.g., the VM severing as a video server has a hot vedio, so it would be better to keep it in the performance tier to make sure the data is not evicted. In traditional CDN, the admin may load the contents manually, so we'd like to do the same thing for cache tier.

Owners

Interested Parties

  • Name (Affiliation)
  • Name (Affiliation)
  • Name

Current Status

Current cache tier is capable of manage the Ceph cluster performance automatically by efficiently boosting promote/write data to cache tier with flash drives.

Detailed Description

We want to implement a multi-tiered storage with different performances/capacities/costs inside ceph.
1) Support data relocation in OSD. With promotion and flush in the current code, this work is almost done in object level. Some work could be done here to allow the agent to do the relocation in the background, not driven by the client IO.
2) Tiers can be nested, so that we can have a multi-tiered storage. Say, for a 3 tier storage, SSD acts as the hot tier. Replicated pool with HDD acts as the warm tier. And EC pool can be the cold tier. We can even add the tape in as the coldest tier when we have the interface to access streamed storage.
3) Manually relocate data. RBD/RGW/CephFS can manually relocate data between tiers. For example, if we want to preload a hot video, RBD can initiate async commands to move the corresponding objects into the hot tier. We can also backup or archive a whole volume using this feature.
4) Automatically relocate data. OSD relocates data automatically based on the decision of the agent. The current implementation uses hit set to predict the access pattern from client. We may need to store more statistical data to make better predictions. This will need a clever algorithm.
Initially, we can do 1, 2 and 3. And leave 4 for later implementation until we have a such a 'clever' algorithm or make use of an existing one.

Work items

Coding tasks

  1. Task 1
  2. Task 2
  3. Task 3

Build / release tasks

  1. Task 1
  2. Task 2
  3. Task 3

Documentation tasks

  1. Task 1
  2. Task 2
  3. Task 3

Deprecation tasks

  1. Task 1
  2. Task 2
  3. Task 3