RFC fair-share prioritisation of tape-to-disk user data staging requests

[tiborsimko]

When a lot of CERN Open Data portal's content will live on tapes as the primary storage, and users will be able to consult a few sample files that are living on disk and then ask for staging the remaining majority of files from tapes, it may happen that many persons will sent numerous data staging requests.

To cope with situations of user request storms of this kind, it would be useful to foresee several fair-share staging strategies on how the incoming requests will be handled from the incoming queue.

For inspiration, in REANA, sometimes a user submits several thousands of workflows, which may be blocking the queue for days. We have introduced different workflow scheduling strategies that the REANA administrator can set in order to alleviate these concerns. We basically have a simple fifo strategy (first in, first out) and a fair-share-oriented balanced strategy. The latter is a combination of (i) paying attention to the number of requests submitted by each user (so that if Alice submits 20, and Bob 1, the latter will be taken in priority when the queue liberates), but also (ii) paying attention to the capabilities of the cluster at the given time (so that if Alice asks for 1 GB of RAM only, and Bob for 120 GB of RAM, and the cluster currently has only 24 GB free, then Alice's request will be prioritised).

In the context of the CERN Open Data portal and the tape-to-disk user staging requests, one could think of something similar to achieve fair-sharing, prioritising over users and over content and over technical capabilities of the system. For example:

• If a request is submitted anonymously, it has lowest priority (0).
• If a request is submitted by an identified person, it has higher priority (1).
• If Alice submits 2000 requests and Bob submits 1 request, the priority of Alice would be scaled down to let Bob pass.
• However, if Alice asks for data living "together" on the same tapes, it may make sense technically to prioritise these requests over "jumping all over tapes" every night, so the pure number of request should not be the only governing piece of information.
• Content-wise, prioritising "full recalls" (all file indexes) over "partial recalls" (just a few index files) may be of interest, assuming the former is for research, the latter is simply to peruse more file samples than offered by default.
• Content-wise, prioritising collision data over simulated data may make sense, especially if a large number of anonymous users asks for simulated data and small number for collision data. (Well, we plan to have all collision data on disk rather than tapes, whenever possible, so this point is just a hypothetical one, to show that the content type can also play a role in planning recalls one day perhaps.)
• ... or another simple content-orieneted general rule, such as prioritising recalls of smaller datasets over those of larger datasets.

Just some examples to stimulate discussion.