GRIO version 2 (GRIOv2) is the second-generation guaranteed-rate I/O product from SGI.
|Note: When it is necessary to distinguish between the previous version (version 1) and the current version (version 2), this guide uses the terms GRIOv1 and GRIOv2. Where the term GRIO is used without qualification, it refers to version 2.|
Enables a proportion of a filesystem's I/O resources to be reserved for the exclusive use of a process or compute node
Ensures that the rate at which a process or node issues I/O does not exceed its reservation and throttles I/O if necessary
Ensures that the aggregate utilization of a filesystem never exceeds a configurable maximum level, referred to as the qualified bandwidth
With a carefully selected and verified qualified bandwidth, you can use GRIO to meet the quality-of-service requirements of demanding I/O workloads where data must be processed without interruption.
GRIO includes the following features:
Support for CXFS filesystems shared among nodes in a cluster as well as locally attached XFS filesystems
A simple filesystem-level performance qualification model (rather than the often complex device-qualification model used in GRIOv1)
A range of tools for monitoring and measuring delivered bandwidth and I/O service time
GRIO uses the following terminology:
Quality of service (QoS) refers to the performance properties of a system service (such as worst-case bandwidth or I/O service time).
Qualified bandwidth is the maximum bandwidth that can be delivered by a filesystem (and the XVM volume on which it resides) in a given configuration under a realistic application workload such that all applications are delivered an adequate QoS.
Reservation is the set of QoS parameters requested by a user application. Reservation requests are forwarded to the ggd2(1M) bandwidth management daemon. GRIO supports two kinds of reservations:
Explicit application-level reservations, which are made by individual applications using the libgrio2 APIs
Node-level bandwidth allocations, which are used within GRIO to control all of the I/O flowing from a compute node to a given filesystem.
Guarantee is the assurance made by the system to a user process that it will deliver data from a storage device at the reserved rate.
Stream is the object within the kernel that encodes the reservation's QoS parameters and maintains the necessary scheduling and monitoring state required to fulfill the guarantee.
Table 1-1 summarizes the primary differences between GRIOv1 and GRIOv2.
Table 1-1. Differences Between GRIOv1 and GRIOv2
Device-level: the maximum sustainable bandwidth for each hardware component in the I/O path is qualified individually. (This includes the storage devices, SCSI and Fibre Channel busses, system interconnects, and so on.)
Filesystem-level: the maximum sustainable bandwidth is measured across the entire filesystem under a realistic application workload. The qualified bandwidth is stored as follows:
Limited administration tools
Comprehensive tools for measuring and monitoring delivered QoS levels, including collection of per-stream performance metrics.
When GRIOv2 begins managing a filesystem, every node with access to that filesystem is notified. From that point on, all user and system I/O that does not have an explicit reservation is encapsulated. This means that I/O that is not explicitly managed by a GRIO reservation is automatically associated with a system-managed kernel stream. The ggd2 daemon allocates otherwise unused bandwidth to these streams, which allows I/O that is not explicitly managed by a GRIO reservation to be processed even when there are active reservations in the system. ggd2 dynamically adjusts the amount of bandwidth allocated for this purpose based on monitoring of filesystem demand and utilization.
You can use the information provided by the QoS infrastructure to choose the tradeoff between resource utilization and delivered I/O performance that is most appropriate for a given application mix, workload, and production environment.
For more information, see the following:
Chapter 4, “Administering GRIO” and the grioadmin(1M) man page
Chapter 5, “Monitoring Quality of Service” and the grioqos(5) and grioqos(1M) man pages
The following man pages:
Although you can have both the GRIOv1 and GRIOv2 subsystems installed on the same machine, only one of them can be active. For more information, see “Starting GRIO on IRIX Servers” in Chapter 3.
This guide provides the information you need to administer GRIO. It discusses the following: