2015-04-08 06:55 AM
I have setup PerfMon and was about to add a cluster until I read the bullet point below, which I was a little concerned about:
OnCommand Performance Manager requires that any volumes that you want to monitor be in a QoS policy group. Volumes that are not in a policy group are automatically added to the default policy group when you add the cluster. When Performance Manager analyzes the cluster for configuration changes every 15 minutes, it adds any new volumes not in a policy group to the default policy group. If an SVM is in a policy group, Performance Manager cannot monitor the volumes contained in the SVM and the overall analysis is impacted. Removing the SVM from the policy group corrects this issue.
Unfortunately, I do not have a lab to test this in and confirm what would result from this change. Can somebody please provide some feedback in regards to the implications here? We do not use any QoS Policy Group configured, so applying a default conifguration without any parameters should probably not have any impact, but I thought to solicit some feedback here prior to taking adding a production site -- rather be safe than sorry :-)
Any advise here would be greatly appreciated.
2015-04-08 10:32 AM
The warning message that you get with OPM is somewhat confusing with respect to QoS policies.
A step back first. QoS is not required to be used on cDot of course. But, if an object is associated with a QoS policy, the "flow path" of request to response through the array is slightly altered. There are a ton of counters as you know for every performance statistic you can think of pretty much. These continue to get counted. The essential difference is that associating an object with a QoS policy triggers a little additional flow within the controller to validate the operation against the policy. OPM also picks up on those details as part of the total data collection. It isn't significant, but of course it also isn't free.
The default QoS just triggers the additional flow path as needed but without actually limiting anything in terms of IOPS, bandwidth, etc. So it's basically a switch that turns on some extra function that you do want in OPM.
Now - to the warning. QoS policies are associated to a specific SVM (vServer). As with any policy, only objects withint that SVM can be associated with the policy. Creating the policy does not associate the policy to any particular object within the SVM - it just makes the policy available within the SVM.
QoS policies can be applied to volumes or to the SVM as a whole. If applied to a volume, the policy limits operation capability of the volume based on limits in the policy. If applied to the SVM, the limit applies to the SVM as a whole, not individually to volumes within the SVM.
OPM requires that a QoS policy be applied at the volume level. If you add a cluster to OPM, any SVM that does not have a QoS policy will get one created (with no specific limitations) and then that policy is applied to all volumes in the SVM. If you are already using QoS, don't just use the "default" policy - define you're own uniquely named QoS policies (which is standard best practice for policies in general of course). Then, and volumes within SVMs that don't have an associated QoS policy can safely get the default QoS policy applied, even if the one named "default" had to be created in addition to those you have designated.
For the second part of the warning, remember that QoS can be applied at the volume level or the SVM level. If such is the case, OPM will not try to create/apply a QoS policy to the volumes within that SVM and thus will not monitor those volumes (the dual QoS's that might be created aren't good for performance). So to use OPM across all volumes you just can't apply QoS policies at the SVM level or choose to not fully monitor all performance statistics on the volumes within that SVM. If you remove the QoS policy from the SVM, OPM will go back and generate (if needed) a default policy and push it out to the volumes in that SVM as it would have during the initial monitoring pass.
The big effect of the QoS policy requirement is that it can change the way you think of QoS. Applying QoS at the SVM level is appropriate when you have a group ov volumes (in that SVM) for which you don't care about individual performance but you do care about the aggregate performance. might be appropriate when you have either a common set of volumes in a single application that you want to set a general level of I/O capability. To monitor through OPM you need to take that bulk QoS off, which means you may not have a good replacement when you have to try to limit on the individual component level. Trade-offs.
Hope this helps.