[LU-17902] add NRS TBF policy for nodemap

• Type: Improvement
• Resolution: Unresolved
• Priority: Major
• Affects Version/s: Lustre 2.16.0
• Labels: TBF medium nodemap
• Severity: 3
• Epic Link: MTFL: Per-Tenant QoS with TBF
• Assignee: Qian Yingjin
• Reporter: Andreas Dilger

Description

For isolation of workloads across multiple sub-tenants of a filesystem, it would be useful to allow registering an NRS TBF rule for a nodemap. This can be proxied to some extent by setting a TBF rule for a project ID, but this doesn't work if there are multiple project IDs used by a single nodemap.

Issue Links

• is duplicated by: LU-18089 NRS TBF for nodemap
• is related to: LU-19077 nodemap must map ptlrpc_body_v2/v3 pb_uid/pb_gid/pb_prjid fields
• is related to: LU-18179 Implementation of Round-Robin/Fair Share response with Token Bucket Filters
• is related to: LU-14501 NRS TBF UID: limit per "any" user?
• is related to: LU-17166 add NRS TBF rule for projid

Comments

[Qian Yingjin]

I will rebase it later.

For your question, 

To make NRS TBF so smart to detect the node map changing (adding and removing), maybe we should both name and id of node map into the key of a TBF class. Each matching will compare both name and id of the node map? In the current version and previous version, we only compare one of them (either name, or id), not both.

And the adding/removing node map will change the id, I think. Thus NRS TBF can detect the change during the matching.

However, this means more memory used for each TBF class.

[Gerrit Updater]

"Qian Yingjin <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/57254
Subject: LU-17902 nrs: add NRS TBF policy for nodemap
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: bae391a8d8a698c7b4fc7d193785b5ef55cb7af9

[Sebastien Buisson]

I have a question for node map TBF support:
Should we use @lu_nodemap.nm_id or @lu_nodemap.nm_name as the key for TBF scheduling class?
I think both can be used as key to identify a nodemap.

Good question. nm_id is unique and could be used as the key. However, if a nodemap is removed and then recreated with the same name, its id will be different, but maybe admins would expect it to be treated as before? In this case, it would make sense to use nm_name as the key for TBF: even if the nodemap is recreated, the same TBF rules apply, and do not need to be fixed.

[Qian Yingjin]

improved "fair share" balancing between buckets

What's the "faire share" meaning?

 

I have a question for node map TBF support:

Should we use @lu_nodemap.nm_id or @lu_nodemap.nm_name as the key for TBF scheduling class?

I think both can be used as key to identify a nodemap.