EMC® ViPR® Controller Concepts
Table of Contents
The ViPR Controller does not sit in the data path for file and block stores. This ensures applications can access storage and all its underlying value and data services embedded in the storage arrays without performance degradation.
ViPR Controller is deployed as a vApp and contains the functionality to automate block and file storage provisioning tasks. Once deployed, you can set up one storage control point for one or more physical data centers. One ViPR Controller controls all the storage resources within the ViPR Controller virtual data center (See What is a ViPR virtual data center? for more information).
The storage virtualization that ViPR Controller provides enables you to combine several physical storage pools into a ViPR Controller virtual storage pool, or add several physical storage arrays into a virtual array . (See What are ViPR block and File virtual pools. for more information)
ViPR Controller System Administrators define policies through the ViPR Controller abstractions of virtual pools and virtual arrays so that ViPR Controller can abstract and pool storage resources based on storage attributes. Once the virtual pools and arrays are set up, storage provisioning tasks are automated and delivered to end users as services through a self-service catalog in the ViPR Controller UI. Policy and management functions are applied in the aggregate, simplifying the process.
ViPR Controller enables software-defined data centers by providing the following features:
- Storage automation capabilities for multi-vendor block and file storage environments
- Management of multiple data centers in different locations with single sign-on data access from any data center
- Data replication between geographically-dispersed data centers to protect against data center failures with active-active functionality
- Integration with VMware and Microsoft compute stacks to enable higher levels of compute and network orchestration
- Comprehensive and customizable platform reporting capabilities that include capacity metering, chargeback, and performance monitoring through the included ViPR Controller SolutionPack
When a System Administrator adds storage systems to the ViPR Controller virtual data center, ViPR Controller discovers the arrays' physical ports and storage pools and brings them under ViPR Controller management. ViPR Controller uses the physical pools and ports on the storage systems to make the storage devices visible to the hosts. ViPR Controller discovers physical block and file storage, SAN, and hosts and then controls the provisioning and connectivity of these physical assets.
ViPR Controller natively discovers and manages the block and file storage systems listed in the listed in theEMC ViPR Controller Support Matrix, which is available for download from the EMC Community Network at community.emc.com. ViPR Controller can also support discovery of third-party block storage systems through OpenStack.
Array support through OpenStack via the ViPR Third-Party Block Storage Provider enables ViPR Controller to discover any third-party block array that an OpenStack block storage (Cinder) driver supports. See the CinderSupportMatrix to view a list of block storage systems that OpenStack Cinder drivers support.Back to Top
- A comprehensive REST Application Programming Interface (API) that allows developers to write applications without regard to the underlying hardware and software.
- A web-based User Interface (UI) that provides the ability to configure and monitor ViPR Controller, as well as perform self-service storage provisioning tasks through an intuitive Service Catalog.
- A Command Line Interface (CLI) that provides an interface for developers and data center administrators to manage storage resources.
A virtual data center is a collection of storage infrastructure that can be managed as a cohesive unit by data center administrators. Geographical co-location of storage systems in a virtual data center is not required. However, high bandwidth and low latency are assumed in the virtual data center.
A virtual data center represents the span of control of a ViPR Controller; a single virtual data center exists for each ViPR Controller.
You can deploy ViPR Controller as a multisite configuration, where several ViPR Controller Controllers control multiple data centers in different locations. In this type of configuration, ViPR Controller Controllers behave as a loosely coupled federation of autonomous virtual data centers. See for more information.
The virtual data center enables a ViPR Controller administrator to discover physical storage and abstract it into ViPR Controller virtual arrays and virtual pools. and . These abstractions are key to enabling software-defined storage. They also enable administrators to implement easy to understand policies to manage storage. See What is a ViPR virtual array? and What are ViPR block and file virtual pools? for more information)
These ViPR Controller virtual array and pool abstractions significantly simplify the provisioning of block and file storage. Users consume storage from virtual pools of storage that a ViPR Controller administrator makes available to them, which relieves storage administrators from provisioning tasks. When end users provision storage, they need to know only the type of storage (virtual pool) and the host/cluster to which the storage should be attached. They do not have to know the details of the underlying physical storage infrastructure.
All ViPR Controller resources are contained and managed in the virtual data center. The virtual data center is the top-level resource in ViPR Controller. The following figure shows a high-level conceptual diagram of the ViPR Controller virtual data center with its primary storage resources.Back to Top
ViPR Controller aggregates physical arrays into virtual arrays, similarly to how vCenter aggregates multiple physical servers into an ESX cluster, but at a much larger scale. A virtual array is a ViPR Controller abstraction for underlying physical storage (arrays) and the network connectivity between hosts and the physical storage. A ViPR Controller virtual array provides a more abstract view of the storage environment for use in applying policies or provisioning.
ViPR Controller System Administrators use virtual arrays to partition the ViPR Controller virtual data center into groups of connected compute, network, and storage resources for purposes of fault tolerance, network isolation, or tenant isolation. System Administrators can abstract EMC and non-EMC storage arrays into a single or multiple virtual arrays that is presented to hosts.
With the ViPR Controller virtual array, all the unique capabilities of the physical arrays are available, but ViPR Controller automates the operations of all the different array tools, processes, and best practices to simplify provisioning storage across a heterogeneous storage infrastructure. In this way, ViPR Controller can make a multivendor storage environment look like one big virtual array. In a data center environment, virtual arrays can be large-scale enterprise SANs or computing fabric pods.
Only ViPR Controller users with a System Administrator role can create virtual arrays. Although the end users who provision storage are aware of virtual arrays, they are unaware of the underlying infrastructure components (such as shared SANs or computing fabrics). Only the System Administrator has access to this information.
The following figure shows how a System Administrator can abstract a physical file/block array into a ViPR Controller virtual array.
ViPR Controller makes it easy to create virtual arrays. When a System Administrator creates a virtual array in the ViPR UI, he or she can add an entire physical block or file array to the virtual array, which brings the storage ports, pools, networks, switches, and connected host endpoints associated with the physical array under ViPR Controller management. A physical array can be abstracted into a virtual array with one click by the System Administrator. If desired, System Administrators also can manually add storage ports, pools, and networks to virtual arrays. See for more information.
Network connectivity essentially defines a virtual array. It includes:
- SAN and IP networks connecting the physical arrays and hosts
- SAN switches (fabric managers) in the SAN networks
- Host and storage ports connected to the networks
- ViPR Controller virtual pools (virtual pools associated with the physical pools on the arrays are brought into the virtual array)
When creating a virtual array, the System Administrator should verify that all the physical arrays that participate in the virtual array are connected to the same fabrics or virtual storage area networks (VSANs) to ensure that they all have the same network connectivity to the environment. When they populate a virtual array with physical arrays and networks, System Administrators must ensure that when the virtual array presents storage to the host, the host can physically reach that storage.
After the System Administrator creates virtual arrays with their host-to-array network connectivity, the System Administrator then carves the underlying physical storage in the virtual array into policy-based virtual pools that have defined storage capabilities (See What are ViPR block and file virtual pools for more information).
By creating and defining the virtual pools in the virtual arrays, the System Administrator can build ViPR Controller policies that are automatically applied by ViPR Controller across heterogeneous arrays.
An Access Control List (ACL) controls tenant access to each virtual array. Only tenants in the virtual array's ACL receive access to provision to that virtual array. The System or Security Administrator sets the ACL for a virtual array. If a System or Security Administrator does not set the ACL, all tenants in the ViPR Controller virtual data center can use the virtual array to provision. See , and for more information.
A System Administrator can group many physical arrays into a virtual array and can also partition a single physical array into several virtual arrays.
Example 1. A virtual array includes multiple physical arrays
A virtual array can span multiple physical arrays, as the following figure shows. You can also use RecoverPoint and VPLEX Metro configurations to connect virtual arrays through disaster recovery and high-availability links.
Example 2. Multiple virtual arrays include partitions of a single physical array
The following figure shows an example where a System Administrator partitions a single physical array into two virtual arrays.
Virtual Array 1 includes Networks A and B with their collection of connected host and storage ports and Virtual Pool A on the array. All physical devices in a virtual array must be able to communicate with each other in the virtual array for ViPR Controller to manage the storage infrastructure properly. After a user requests a volume or file system export from the array to make the storage visible on a host, ViPR Controller determines which network in the virtual array contains the desired host initiator ports and storage ports, and then selects the switch that can manage that network.
The preceding figure depicts a scenario that has no shared networks among virtual arrays. In this scenario, all the physical storage ports and pools associated with a network are in the network's assigned virtual array. For example, the physical ports and pools in Network A are in Virtual Array 1.
However, a System Administrator can assign a network (SAN fabric or IP network) to more than one virtual array. When a System Administrator assigns a network to multiple virtual arrays, all the storage ports and pools associated with the network are automatically added to the assigned virtual array. A System Administrator can, however, choose to select a subset of ports or pools manually from a network to associate with a virtual array.
A System Administrator can manually assign ports to any number of virtual arrays. Manually assigned ports are only in their assigned virtual arrays, they cannot be implicitly assigned to any other virtual arrays. Implicit assignment for a port occurs when there are no manual assignments for the port. In this case, the port is accessible from any virtual array to which the network containing the port has been assigned.
Consider the following scenario:
A System Administrator assigns Network A to two virtual arrays: Virtual Array 1 and Virtual Array 2. Network A contains four storage ports. By default, all four storage ports are automatically added to both Virtual Array 1 and Virtual Array 2.
The System Administrator decides that he or she wants to assign two ports (ports 1 and 2) manually to Virtual Array 1, as shown in the following figure.
These two ports are now exclusively in Virtual Array 1.
Virtual Array 1 contains ports 1, 2, 3, and 4. (Ports 1 and 2 were manually assigned by the System Administrator, and ports 3 and 4 were automatically assigned to this virtual array when the System Administrator assigned the network to the virtual array.)
Virtual Array 2 contains ports 3 and 4.Back to Top
After a ViPR Controller System Administrator creates a virtual array, he or she must create block/file virtual pools in the virtual array. A virtual pool represents a storage service offering from which you can provision storage. A virtual pool can reside in a single virtual array, or it can span multiple virtual arrays.
ViPR Controller has two types of virtual pools: block virtual pools and file virtual pools.
Block virtual pools and file virtual pools are sets of block and file storage capabilities that meet various storage performance and cost needs.
A ViPR Controller user with a System Administrator role creates and configures block and file virtual pools in a virtual data center. Rather than provision capacity on storage systems, a System Administrator can enable users to use block and file virtual pools that meet their unique requirements. See , or for more information.
After the System Administrator creates virtual pools, users can pick which virtual pool they want their storage to use. ViPR Controller applies the built-in best practices to select the best physical array and storage pool that meet the provisioning request.
For block and file virtual pools, the System Administrator defines a set of storage service capabilities, such as:
- type of storage (file or block)
- protocol (FC, iSCSI, CIFS, NFS)
- storage system type (VMAX/VMAX3, VNX block or file, VNXe block or file, Hitachi, ScaleIO, XtremIO, IBM XIV, third-party block, Isilon, NetApp, Data Domain)
- protection characteristics
- performance characteristics
The System Administrator then assigns physical storage pools on the ViPR Controller-managed storage systems to the virtual pool.
ViPR Controller automatically matches existing physical pools on the ViPR Controller-managed storage systems to the virtual pool characteristics that the System Administrator specifies. The System Administrator can enable ViPR Controller 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:
- A Tier 1 virtual pool with high-speed I/O and data protection capabilities optimized to minimize disruption to database access for critical business applications.
- A Tier 2 virtual pool that has lower I/O speed and no data protection capabilities that the System Administrator sets up for users to provision their internal development and testing applications.
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:
- is in the VMAX_VA_1 virtual array
- the storage system type is EMC VMAX
- the protocol is Fibre Channel
- the data protection is RecoverPoint
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.
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 Controller virtual data center can use the virtual pool to provision. See , and for more information.
A System Administrator can, if desired, enable a maximum total storage capacity (quota) on a virtual pool that cannot be exceeded. The ViPR Controller metering records contain the maximum total capacity values for a virtual pool.Back to Top
Compute virtual pools can only be created in ViPR Controller by System Administrators when there is at least one logical compute system under ViPR Controller management. Each logical compute system contains compute elements, in the way that a UCS contains one or more chassis that contain the blades. System Administrators can add a compute system to ViPR Controller as a physical asset. In ViPR Controller, UCS systems are referred to as Vblock compute systems.
A Vblock system is a converged hardware system from VCE (VMware, Cisco, and EMC) that is comprised of a UCS, EMC storage systems, and networks. These Vblock components are added separately into ViPR Controller as physical assets. They must be physically and logically connected for ViPR Controller to carry out provisioning operations. Once added into the system, a System Administrator should create one or more virtual arrays to define storage visibility within ViPR Controller. For details seeViPR Controller Support for Vblock Systems, which is available from the ViPR Controller Product Documentation Index.
Once a virtual array is created, and the compute virtual pool is associated with the virtual array,ViPR Controller understands which UCS systems have visibility to storage and will use that information during the process of creating compute virtual pools and provisioning. For more information see ViPR Controller User Interface Virtual Data Center Configuration Guidewhich is available from the ViPR Controller Product Documentation Index.
Compute virtual pools are the abstraction used to create pools of hosts. This is very similar to the ViPR Controller concept of file and block storage virtual pools, which abstract physical pools of block and file storage. Compute virtual pools abstract physical compute elements such as UCS blades, and storage virtual pools abstract physical storage in underlying storage arrays. Compute virtual pools are used to provision hosts while storage virtual pools are used to provision storage.
When ViPR Controller System Administrators create a compute virtual pool, they can manually assign specific blades to a compute virtual pool, or define qualifiers (such as memory, CPU speed, processors, etc.) that allow ViPR Controller to automatically assign the blades to a pool based on the criteria of the qualifier.
For each UCS that is part of a compute virtual pool, a service profile template can be assigned. A UCS service profile template (SPT), or updating service profile template (uSPT) is created by a UCS administrator and contains all the required settings to set up a blade. ViPR Controller users can then use the UCS SPT, or uSPT at the time of provisioning to configure the blades.
An SPT, or uSPT must be assigned for each UCS or that UCS will not be used when provisioning from that compute virtual pool. The SPTs, or uSPTs are discovered by ViPR Controller to make them easy to assign to the pools.
Compute virtual pools are used to provision hosts in the Vblock system services in the ViPR Controller Service Catalog to create new hosts. You have the option to use ViPR Controller to provision the hosts with or without an ESX 5.x operating system. The compute virtual pool is used as the pool of UCS blades from which ViPR Controller creates the hosts. ViPR Controller assigns the UCS SPT, or uSPT settings associated with the compute virtual pool to each of the new hosts/blades in the cluster. The SPT, and uSPT also define the layer 2 networking on each host.Back to Top