Chapter 1. Introduction

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.


What Does GRIO Do?

GRIO does the following:

  • Enables a user application to reserve part of a system's I/O resources for its exclusive use

  • Guarantees delivery of data from a storage device at a predefined rate, regardless of any other I/O activity on the system or on other nodes in the cluster

  • Ensures that the rate at which a process issues I/O does not exceed its guarantee and will throttle the I/O if necessary

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

Terminology

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 quality of service.

  • Reservation is the set of quality-of-service parameters requested by a user application. Reservation requests are forwarded to the ggd2(1M) bandwidth management daemon.

  • 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 regardless of any other I/O activity on the system or on other nodes within its cluster.

  • Stream is the object within the kernel that encodes the reservation's quality-of-service parameters and maintains the necessary scheduling and monitoring state required to fulfill the guarantee.

GRIOv1 and GRIOv2 Differences

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” in Chapter 3.

Table 1-1 summarizes the primary differences between GRIOv1 and GRIOv2.

Table 1-1. Differences Between GRIOv1 and GRIOv2

GRIOv1

GRIOv2

Reservation-granting daemon:

ggd

ggd2

Userspace library:

libgrio

libgrio2

Logical volumes:

XLV

XVM

Filesystems supported:

Local XFS filesystems only

Local XFS filesystems and shared CXFS filesystems

Multiple-node support:

No

Yes

Qualification model:

Device-level: the maximum sustainable bandwidth for each hardware component in the I/O path (including the storage devices themselves, the SCSI and Fibre Channel busses, system interconnects, and bridges), is qualified separately

Filesystem-level: the maximum sustainable bandwidth is measured across the entire filesystem under a realistic application workload. The qualified bandwidth is stored as follows:

  • XFS: in the /etc/griotab file

  • CXFS: in the cluster database

Monitoring service

Limited administration tools

Comprehensive tools for measuring and monitoring delivered quality-of-service levels, including collection of per-stream performance metrics. You can use the information provided by the quality-of-service 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 griomon(1M), grioqos(1M), and grioadmin (1M) man pages.

Control of non-GRIO-managed I/O

No control

Cluster-wide encapsulation and control. 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 managed by GRIO is automatically associated with a system-managed kernel stream. The ggd2 daemon allocates otherwise unused bandwidth to these streams, which allows non-GRIO-managed I/O 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.

For more information, see the ggd2(1M), griotab(4), grioadmin(1M), grioqos(1M), griomon(1M), and grioqos(5) man pages

Overview

This guide provides the information you need to administer GRIO. It discusses the following: