Data centers today service multiple independent applications which share storage resources. Unless applications are completely isolated from one another, whenever they vie for a shared resource, contention occurs. Each of these applications often require predictable quality of service.
Unrestricted usage of the shared storage resources causes “Noisy neighbor” problem. Hence there is a need for a solution which can provide guaranteed Quality of Service (QoS).
Various performance SLAs that define QoS: Maximum and minimum IOPS, I/O latency etc.
Veritas Infoscale 7.1 provides a way to achieve Maxiops SLA for applications sharing storage resources. Veritas Infoscale 7.1 product Veritas volume manager (VxVM) provides a way to set maxiops on a set of volumes of application. Multiple volumes could be hosting an application.
VxVM allows setting maxiops for such an application by creating volume group from the volumes under the application. An application volume group is a logical grouping of volumes associated with an application. An application could further contain multiple volume groups depending on the nature of the application.
For example, the log volumes of a database application will need a different maxiops as compared to the data volumes. In such scenarios, separate volume groups could be created under the same application to set different maxiops. A volume cannot be shared between multiple application volume groups for setting maxiops limits.
How it works?
When an I/O request comes in from an application, it is serviced by the available volumes in the group until the application volume group reaches the maxiops limit. When the group exceeds this limit, further I/O requests on the group from the application are throttled and the request is queued. The queued I/O is taken up on priority for the next time interval along with new I/O requests from the application.
This allows other applications to better utilize the storage subsystem.
A new CLI called vxvolgrp has been introduced for managing volume groups and setting maxiops limits.
Following example illustrates comparison of I/O statistics when maxiops limit is not set and set with multiple volume groups for an application with different I/O patterns for a database:
# vxvolgrp -g oradg make datagrp datavol1 datavol2 # vxvolgrp -g oradg make loggrp logvol1 logvol2 # vxvolgrp -g oradg list Volume Group: datagrp volume(s): datavol1 datavol2 Volume Group: loggrp volume(s): logvol1 logvol2
Average number of I/O’s per volume group with very high maxiops value set:
# vxvolgrp -g oradg set loggrp maxiops=999999 # vxvolgrp -g oradg set datagrp maxiops=999999 # vxstat -g oradg -G -i 1 -c 10 AVG PER SECOND VOLUMEGROUP STATISTICS TYP NAME MaxIOPS ServicedIOPS QueuedIOPS(Transient) grp datagrp 999999 1466 0 grp loggrp 999999 2769 0 .. grp datagrp 999999 1896 0 grp loggrp 999999 3521 0
Average number of I/O’s per volume group with maxiops value set to 1000 for data volumes
# vxvolgrp -g oradg set datagrp maxiops=1000 grp datagrp 1000 1000 61 grp loggrp 999999 4293 0 .. grp datagrp 1000 1000 58 grp loggrp 999999 4298 0
Above statistics show that by setting maxiops SLA for data volume group of an application, IOPS for log volumes improve.
By using maxiops SLA feature for docker environments, customers can get predictable SLAs, preventing noisy neighbor problems by throttling non-critical container applications. This is achieved with integration of QoS functionality and InfoScale Storage plug-in for Docker.
See https://www.veritas.com/community/blogs/12-docker-persistent-storage-and-quality-service-next-genera... for more details.
By setting maxiops SLA, applications can get predictable quality of service and help resolve noisy neighbor problem.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.