ViPR 2.1 - What is a ViPR virtual pool?

Table of Contents

What is a ViPR virtual pool?

After a ViPR System Administrator creates a virtual array, he or she must create virtual pools in the virtual array. Virtual pools are abstractions of underlying physical storage tiers with defined performance and protection characteristics.

A virtual pool represents a storage service offering from which you can provision storage. A virtual pool can reside in a single virtual data center, or it can span multiple virtual data centers.

ViPR has three types of virtual pools: block, file, and object.

Block virtual pools and file virtual pools are sets of block and file storage capabilities that meet various storage performance and cost needs.

Object virtual pools store object data. Storage on underlying ViPR-managed file arrays or commodity nodes backs them.

A ViPR user with a System Administrator role creates and configures block, file, and object virtual pools in a virtual data center. Rather than provision capacity on storage systems, a System Administrator can enable users to use block, file, and object virtual pools that meet their unique requirements.

After the System Administrator creates virtual pools, users can pick which virtual pool they want their storage to use. ViPR applies the built-in best practices to select the best physical array or Commodity node(s) and storage pool that meet the provisioning request.

Block and file virtual pools

For block and file virtual pools, the System Administrator defines a set of storage service capabilities, such as:

The System Administrator then assigns physical storage pools on the ViPR-managed storage systems to the virtual pool.

ViPR automatically matches existing physical pools on the ViPR-managed storage systems to the virtual pool characteristics that the System Administrator specifies. The System Administrator can enable ViPR to automatically assign the matching physical pools to the virtual pool that he or she is creating, or the System Administrator can select a subset of the matching physical pools manually to assign to the virtual pool. An important step, a System Administrator must set up the block and file virtual pools carefully, because the virtual pools drive all future block and file provisioning tasks that end users perform.

After the System Administrator creates the virtual pools, users can create file and block storage using the virtual pool that has the storage characteristics they require.

The file and block stores provide a set of built-in virtual pool capabilities and if desired, enable the System Administrator to define custom capabilities.

For example, the System Administrator defines two virtual pools in the file store:

In the following figure, the System Administrator creates a block virtual pool, Mission Critical. The defined set of storage capabilities indicate that the Mission Critical block virtual pool:

When end users want to create a volume that has these storage characteristics, they simply select the Mission Critical block virtual pool when they create the volume.

System Administrator Creates ViPR Virtual Pool

When a System Administrator creates a virtual pool, a virtual array must be defined. A System Administrator can assign a virtual pool to more than one virtual array.

An Access Control List (ACL) controls tenant access to each virtual pool. Only tenants in the virtual pool's ACL receive access to provision to that virtual pool. The System or Security Administrator sets the ACL for a virtual pool. If a System or Security Administrator does not set the ACL, all tenants in the ViPR virtual data center can use the virtual pool to provision.

A System Administrator can, if desired, enable a maximum total storage capacity (quota) on a virtual pool that cannot be exceeded. The ViPR metering records contain the maximum total capacity values for a virtual pool.

Object virtual pools

To create an object virtual pool, the System Administrator must only specify the name, description, and the type of the object virtual pool. The type can be:

The type depends on whether the System Administrator sets up the object virtual pool to provision object storage that uses the Object Service, the HDFS Service, or both.

Commodity-based or filer-based data stores provide the underlying storage for an object virtual pool. Each Commodity-based data store maps to a group of Commodity nodes. Each filer-based data store maps to a physical file share. The storage quality of a filer-based data store is defined by its file virtual pool storage capabilities.

The following figure shows a high-level view of how end users can provision object storage from ViPR object virtual pools. In this example, users in Tenants 1 and 2 set up default projects in which to store objects, and they specify a ViPR object virtual pool as the default virtual pool from which to provision their object storage. The object virtual pool is backed by three ViPR data stores that a System Administrator created from a ViPR file virtual pool. The file virtual pool maps to a physical file storage pool on an Isilon filer.

End Users Provision Object Storage from ViPR Object Virtual Pool

Geo-distributed object virtual pools

An object virtual pool can reside in a single virtual data center or it can span multiple virtual data centers. In a ViPR multisite configuration, a System Administrator could configure an object virtual pool so that it is stretched between two different virtual arrays in two different virtual data centers, as shown in the following figure. The object virtual pool, backed by underlying file- or Commodity-based storage, is globally visible and accessible to users in both virtual data centers. When users create buckets to store objects through Amazon S3, Openstack, and Atmos APIs, they can use this global object virtual pool to provision their storage.

End Users Access ViPR Object Storage from Data Centers in Different Locations

Back to Top