NetApp QOS extra spec is not implemented properly
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
Undecided
|
Alex Meade |
Bug Description
The NetApp NFS and iSCSI QOS extra spec for volume types is not implemented correctly. It currently requires a QOS policy to be applied at the flexVol level. The scheduler then assigns a new cinder volume to the flexVol which has the QOS policy applied to it. This results in a situation where multiple cinder volumes are all fighting for the same QOS limits, rather than each getting the implied limit. For example:
QOS policy of 100 MB/s is applied to a flexVol by the NetApp admin.
5 cinder volumes are created with the 100 MB/s QOS policy applied via volume-type. They are all placed into the flexVol created in the first step.
These 5 cinder volumes are now fighting each other for the 100 MB/s that the flexVol has allocated to it.
The expected behavior is that each cinder volume would independently have their own 100 MB/s limit, not a combined limit.
In order to do this, the QOS policy should be applied at the LUN level for the iSCSI driver. The NFS driver is another can of worms, as I'm not aware of a way to apply a QOS policy to a file.
Changed in cinder: | |
status: | New → Confirmed |
Changed in cinder: | |
assignee: | nobody → Alex Meade (alex-meade) |
Changed in cinder: | |
milestone: | none → next |
Changed in cinder: | |
status: | Fix Committed → Fix Released |
milestone: | next → none |
This can and should be fixed for iSCSI. The fix is to simply apply the QoS policy to the LUN rather than ensuring the LUN lands on a flexvol with a QoS policy.
For NFS the existing behavior should be preserved until we can get additional support on the backend for per-file or per-directory QoS.
The UI should not need to change at all to fix this bug, although the docs need to be updated to reflect the differences in the behavior between NFS and iSCSI.