EMC ViPR. Concepts Guide. Version

Transcription

1 EMC ViPR Version Concepts Gide

2 Copyright EMC Corporation. All rights reserved. Pblished in USA. Pblished Febrary, 2014 EMC believes the information in this pblication is accrate as of its pblication date. The information is sbject to change withot notice. The information in this pblication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this pblication, and specifically disclaims implied warranties of merchantability or fitness for a particlar prpose. Use, copying, and distribtion of any EMC software described in this pblication reqires an applicable software license. EMC², EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other contries. All other trademarks sed herein are the property of their respective owners. For the most p-to-date reglatory docment for yor prodct line, go to EMC Online Spport ( For docmentation on EMC Data Domain prodcts, go to the EMC Data Domain Spport Portal ( EMC Corporation Hopkinton, Massachsetts In North America EMC ViPR Concepts Gide

3 CONTENTS Figres 5 Chapter 1 ViPR Introdction 7 Abot... 8 Introdction to ViPR Controller... 8 Discover physical infrastrctre... 9 Define ViPR abstractions Provision storage Introdction to ViPR Data Services...11 Interfaces...12 API UI...13 CLI ViPR integration with compte stacks...13 Chapter 2 ViPR-specific Resorces 17 ViPR resorce conceptal overview Virtal data center...19 Virtal array...19 Virtal pool Tenant...24 Project Service catalog...25 Chapter 3 Storage Resorces Managed by ViPR 27 Storage system Storage pool SAN switch (fabric manager) Network Volme Volme export...30 File system Snapshot Host vcenter Server/clster...32 Data store Object Bcket Chapter 4 User Roles and Access Control Lists (ACLs) 37 User roles...38 Access Control Lists (ACLs)...40 Adding sers into ViPR User role resorce views...42 EMC ViPR Concepts Gide 3

4 CONTENTS 4 EMC ViPR Concepts Gide

5 FIGURES Virtal pools ViPR abstraction of nderlying physical storage ViPR resorce conceptal overview...18 Virtal arrays in the ViPR virtal data center...20 Virtal array partitioning Manal and atomatic port assignments in shared network among virtal arrays Creating a block virtal pool ViPR data services virtal pool and related resorces...24 Network connectivity in the ViPR virtal data center...29 Data store mapping to physical file shares...33 Using bckets for object storage and ingesting file share data...34 EMC ViPR Concepts Gide 5

6 FIGURES 6 EMC ViPR Concepts Gide

7 CHAPTER 1 ViPR Introdction The prpose of this gide is to explain the high-level architectre, core concepts, and entities associated with ViPR. To se ViPR effectively, yo shold nderstand the concepts introdced in this gide. This chapter contains the following topics. Abot... 8 Introdction to ViPR Controller...8 Introdction to ViPR Data Services...11 Interfaces...12 ViPR integration with compte stacks...13 ViPR Introdction 7

8 ViPR Introdction Abot EMC ViPR is a software-defined platform that abstracts, pools, and atomates a data center's nderlying physical storage infrastrctre. It provides a single control plane for heterogeneos storage systems to data center administrators. ViPR enables software-defined data centers by providing: Storage atomation capabilities for heterogeneos block and file storage (control path). Object data management and analytic capabilities throgh Data Services that create a nified pool (bcket) of data across file shares (data path). Integration with VMware and Microsoft compte stacks to enable higher levels of compte and network orchestration. A comprehensive RESTfl interface for integrating ViPR with management and reporting applications. A web-based User Interface (UI) that provides the ability to configre and monitor ViPR, as well as perform self-service storage provisioning by enterprise sers. Comprehensive and cstomizable platform reporting capabilities, inclding capacity metering, chargeback, and performance monitoring throgh the inclded ViPR SoltionPack. Introdction to ViPR Controller ViPR solves a very difficlt problem faced by enterprise IT departments and data center administrators today: how to achieve a highly efficient clod-style operating model in a mlti-vendor storage environment that can manage and share storage from a central view while still sing and maximizing existing storage system capabilities? ViPR software-defined storage is advantageos in the following enterprise scenarios: Enterprises experiencing explosive storage growth with flat IT bdgets that want to consistently plan, configre, protect, migrate, and manage heterogeneos storage resorces (data center storage atomation). Enterprises transforming their IT infrastrctre to provide storage-as-a-service (STaaS) for IT-as-a-service (ITaaS). Enterprises deploying private and hybrid clods to facilitate the delivery of highervale services. The bsiness problems that ViPR solves are smmarized below. Existing Storage Environments Storage Environments with ViPR - - Many storage control points within a One storage control point per physical data center data center. (which is the eqivalent of a ViPR virtal data center). One ViPR instance controls all the storage resorces within the virtal data center. Disparate, complex storage management abstractions. Complex IT processes needed to deliver storage. Simple, ser- and developer-friendly storage management abstractions. Administrators set policies and definitions (on virtal arrays, pools, and storage services in the UI) once; 8 EMC ViPR Concepts Gide

9 ViPR Introdction Existing Storage Environments Storage Environments with ViPR - - storage provisioning is atomated thereafter. Developer access to self-service storage. Lack of visibility into storage sage, availability, performance, and overall health for data center administrators de to storage silos. End reslt: Delivery is too slow, and the cost of storage operations is too high. Clear visibility into storage sage, availability, performance, and overall health for data center administrators. End reslt: Agile and efficient storage operations. Discover physical infrastrctre The ViPR Controller accomplishes the above by taking over the storage control plane and simplifying/atomating the management of block and file storage. It allows sers to operate at the level of ViPR virtal abstractions, so that ViPR administrators can define the policies for storage consmption in the ViPR software and provide services to their end sers. ViPR aggregates and pools physical storage systems and pools into virtal arrays and pools in a manner similar to VMware vcenter. Policy and management fnctions are applied in the aggregate, ths simplifying the process. The ViPR Controller allows yo to: discover physical block and file storage to bring nder ViPR management. abstract block and file physical storage into defined ViPR abstractions sch as virtal arrays and virtal pools (also referred to as Virtal Storage Arrays and Virtal Storage Pools). atomate storage tasks and deliver storage throgh a self-service catalog in the ViPR UI to enable self-service storage provisioning. centralize management and file/block provisioning operations across physical and virtal environments. Once ViPR is deployed in a data center, ViPR discovers the physical infrastrctre inclding storage systems, Fibre Channel storage area networks (SANs), and hosts so that ViPR can nderstand the fll topology of the data center. ViPR discovers the physical storage pools and the storage ports for each storage system registered with ViPR. The physical pools and ports on the storage systems are sed by ViPR to make the storage devices visible to the hosts. ViPR discovers and manages the block and file storage systems listed below. Storage System Block Storage File Storage EMC VPLEX X EMC Symmetrix VMAX X EMC VNX X X Isilon NetApp X X Discover physical infrastrctre 9

10 ViPR Introdction Define ViPR abstractions After discovering the physical infrastrctre, ViPR administrators define the following ViPR abstractions: Virtal arrays Virtal pools End ser services sing virtal arrays and pools These abstractions are key to enabling software-defined storage, and provide ViPR administrators a way to implement easy-to-nderstand policies for managing storage. Virtal arrays are logical gropings of nderlying physical storage systems, and virtal pools contain one or more nderlying physical storage pools. A virtal pool defines a set of storage capabilities that describe the qality of storage, sch as type of disks, thick/ thin devices, and protection featres sch as snapshots, replication, and high availability. The ViPR Controller manages storage at the virtal level throgh virtal arrays and pools. This atomates storage provisioning tasks and allows sers to provision their own storage for hosts and applications. With ViPR, the block and file data paths are nchanged; data is still managed directly by the nderlying block and file arrays. This allows sers to contine to take fll advantage of the nderlying intelligent storage technologies, withot introdcing I/O latencies. ViPR services provide a ser-friendly and highly cstomizable experience for the self service ser. ViPR administrators define the services for the end sers based on the defined virtal arrays and virtal pools as well as other discovered entities like hosts and vcenter servers. An example of a ViPR service is the Create Block Volme for Host service, which allows the end ser to specify a host for which storage mst be provisioned, and a virtal array and pool from which the block storage has to be derived. Figre 1 Virtal pools Provision storage 10 EMC ViPR Concepts Gide ViPR simplifies the provisioning of block and file storage. End sers consme storage from virtal pools of storage made available to them by a System Administrator. When provisioning storage, all end sers have to know is the type of storage (virtal pool) and the host/clster to which the storage shold be attached - they do not have to specify

11 ViPR Introdction detailed storage parameters. Users sch as server/virtal infrastrctre administrators wold know this information and can therefore perform self-service provisioning sing ViPR. The figre below shows how self-service provisioning works: an end ser cold create a volme sing the Mission Critical virtal pool (which has premim storage qality inclding high levels of data protection and redndancy) and then se this volme in applications that are critical to bsiness operation. The volme (or the file system, as the case may be) is created from the nderlying physical storage, withot showing the nderlying complexity to the end ser. The end storage sers in the organization can se ViPR's service catalog to execte storage provisioning operations (for example, create block volme for host) withot having to know anything abot the nderlying storage infrastrctre. ViPR's comprehensive REST API also allows higher level orchestration engines to deliver richer vale-added services to end sers. ViPR not only provides the virtal abstractions, which are a key component in enabling software-defined storage, bt also provides comprehensive vale-added atomation. For example, when a ser exectes a service to Create Block Volme for Host, ViPR provisions and formats the volme, creates a file system on it, exports it to the hosts, programs the SAN fabric, and forces a host level I/O scan to mont the volme, thereby providing an end-to-end service to the ser. Figre 2 ViPR abstraction of nderlying physical storage ViPR Virtal Data Center discovery of heterogeneos physical storage ports physical pool A physical pool B physical storage system with physical storage pools and ports (This ViPR-managed storage system is only visible to a ser with a ViPR System Administrator or System Monitor role.) abstracted storage Mission Critical virtal pool physical storage pool A physical storage pool B Physical storage pools A and B are abstracted into the Mission Critical virtal pool. ViPR clients End sers only see the Mission Critical virtal pool for selfservice provisioning, not the nderlying physical storage system. ViPR CLI client ViPR virtal appliance in a 3 VM configration Introdction to ViPR Data Services ViPR aggregates mlti-vendor heterogeneos storage into a nified storage platform. This storage platform forms the nderlying infrastrctre for hosting a range of data services to spport the storage and maniplation of object data, and to spport collecting, managing and tilizing nstrctred content at massive scale. ViPR Data Services are critical enablers for Clod and Big Data applications. ViPR crrently spports the following Data Services: Introdction to ViPR Data Services 11

12 ViPR Introdction Object Data Service Provides the ability to store, access, and maniplate nstrctred data as objects on file-based storage systems, sch as EMC VNX, Isilon and NetApp. The Object Data Service is compatible with existing EMC Atmos, Amazon S3, and OpenStack Swift APIs. The Object Data Service also provides the ability to access a set of objects as files directly on the nderlying file storage device, with native file system performance, enabling in-place access to the data for file-based applications. HDFS Data Service Provides Hadoop Distribted File System (HDFS) spport, enabling existing filebased storage to be leveraged to bild robst, scalable data processing environments based on the Hadoop framework. The HDFS Data Service allows organizations to analyze existing data on file arrays withot moving it to a separate repository. With the HDFS Data Service, the ViPR virtalized storage environment can be sed as a Big Data repository against which Hadoop analytic applications can be rn. ViPR Data Services allow yo to: Ingest data from existing file systems, store the data as objects, and make it available for se by ViPR object and HDFS services. The object data can be accessed as files sing file access mode or the HDFS service. In both cases the directory strctre of the ingested data is preserved. Access and maniplate the same data sing the Object and HDFS services. Object containers created sing the object APIs can be made available as HDFS storage, enabling data broght into ViPR as objects, or created in ViPR as objects, to be sed as the target for Hadoop map and redce jobs, whilst still being available for pdate by the object services. Use existing Hadoop infrastrctre with ViPR-managed data withot any changes by simply referencing ViPR HDFS as the data sorce. Interfaces ViPR incldes three management interfaces to provide maximm ser flexibility: A RESTfl application programming interface (API) A command line interface (CLI) A graphical ser interface (GUI) called the ViPR Admin and Self-Service UI (referred to as the UI) API ViPR provides a powerfl REST API. Throgh the API, yo can extract information, create, delete, modify, monitor, and meter logical storage resorces. All data and resorces managed by ViPR are accessible via the API. The ViPR API allows developers to write applications withot regard to the nderlying hardware and software. The ViPR REST API for the Object Data Service spports the Amazon Simple Storage Service (S3), OpenStack Swift, and EMC Atmos storage APIs. Developers can write applications to mltiple clod APIs and execte those workloads on ViPR in an enterprise data center or a service provider s clod. The open API enables both enterprises and service providers to bild developer commnities that attract developers and independent software vendors to create vale-adding data services. 12 EMC ViPR Concepts Gide

13 ViPR Introdction UI CLI ViPR incldes a bilt-in management UI that provides a browser-based ser interface for the capabilities available in ViPR. This incldes adding physical storage resorces sch as arrays and switches into ViPR, creating virtal storage resorces sch as virtal arrays and pools from the physical resorces, and managing these resorces from one central control plane. The UI simplifies configring the ViPR virtal data center and managing the diverse nderlying physical storage infrastrctre, withot redcing the strength of EMC array featres. Storage provisioning is simplified, bt sers still have access to array-specific featres sch as snapshots and RecoverPoint and VPLEX data protection featres. The UI presents the most common storage se cases as services throgh the service catalog. A ser with a System Administrator or Tenant Administrator role can configre the service catalog to cstomize the services offered and to control access to the services. Users can then perform self-service provisioning by choosing the appropriate storage service from the service catalog and choosing the virtal pool and array that meets their storage needs. The ViPR CLI provides an interface for developers and data center administrators to manage storage resorces. The CLI install software is packaged with ViPR and is installed on a stand-alone client machine. ViPR integration with compte stacks ViPR-managed storage integrates with several VMware and Microsoft applications so that storage can be seamlessly provisioned, managed, and monitored within these applications. ViPR integration with VMware and Microsoft applications provides the following benefits: Streamlines the interaction between data center administrators and server/virtal infrastrctre administrators to increase operational efficiency. Allows the ViPR administrators to define the storage policies and bondaries and then delegate athority to the server/virtal infrastrctre administrators to selfmanage their storage. Provides the server/virtal infrastrctre administrators the ability to do this selfmanagement from their native tools (VMware vcenter and Microsoft System Center Virtal Machine Manager (SCVMM). ViPR has a bilt-in storage provider for VMware vcenter and installable components that allow ViPR data and resorces to be managed and monitored throgh the following VMware and Microsoft applications. ViPR component Integrates with - - EMC ViPR Storage Provider for VMware vcenter VMware vsphere/vcenter Server (service bilt into the ViPR virtal appliance) EMC ViPR Plg-in for VMware vcenter Orchestrator VMware vcenter Orchestrator client or REST API VMware vsphere/vcenter Server UI 13

14 ViPR Introdction ViPR component Integrates with - - VMware vclod Atomation Center EMC ViPR Analytics Pack for VMware vcenter Operations Management Site EMC ViPR Add-in for Microsoft System Center Virtal Machine Manager EMC Virtal Storage Integrator (VSI) for VMware vsphere Web Client v6.0 VMware vcenter Operations Management Site Microsoft Service Center Virtal Machine Manager VMware vsphere/vcenter Server EMC ViPR Storage Provider for VMware vcenter The ViPR Storage Provider for VMware vcenter integrates ViPR with the vcenter Server and allows vcenter administrators to view ViPR virtal pools and se them to select the appropriate storage when creating new virtal machines. It also reports events and alarms originating from ViPR. Refer to the EMC ViPR Storage Provider for VMware vcenter Registration and Usage Gide for more information. EMC ViPR Plg-in for VMware vcenter Orchestrator The EMC plg-in for vcenter Orchestrator provides an orchestration interface to the ViPR software platform. The ViPR plg-in has pre-packaged workflows which consist of both bilding block workflows providing more granlar operations, and higher level workflows to carry ot common activities sch as provisioning storage for an entire clster. The ViPR plg-in mst be installed and configred from the vcenter Orchestrator Configration interface. Once it is installed, the fnctionality provided with the ViPR plgin can be invoked throgh: vcenter Orchestrator client, web client, or REST API VMware vsphere Web Client VMware vclod Atomation Center with the EMC ViPR Enablement Kit for vclod Atomation Center. Refer to the Clod Atomation with EMC ViPR Enablement Kit for vclod Atomation Center White Paper for complete details. Refer to the EMC ViPR Plg-in for VMware vcenter Orchestrator Installation and Configration Gide and the workflow docmentation, which can be generated from vcenter Orchestrator, for frther information. EMC ViPR Analytics Pack for VMware vcenter Operations Management Site The EMC ViPR Analytics Pack for VMware vcenter Operations Management Site is designed to: Import ViPR inventory, metering, and event data to VMware vcenter Operations Management Site. Provide pre-configred dashboards for trobleshooting isses in ViPR. Provide a collection of volme, storage port, storage system, and virtal pool data for compting key resorce stats scores sed in ViPR. Present dashboard views that smmarize resorce details, the behavior of individal metrics, and ViPR event alerts. Improve the health scores of ViPR resorces by tilizing performance data from VNX/ VMAX adapters. 14 EMC ViPR Concepts Gide

15 ViPR Introdction Refer to the EMC ViPR Analytics Pack for VMware vcenter Operations Management Site Installation and Configration Gide for more information. EMC ViPR Add-in for Microsoft System Center Virtal Machine Manager (SCVMM) The EMC ViPR Add-in for Microsoft SCVMM integrates prepackaged services with SCVMM for allocating and managing ViPR storage with the SCVMM hypervisors and hosts throgh the System Center Virtal Machine Manager console (VMM console). The prepackaged services allow yo to perform the following fnctions on ViPR storage: Provision a volme for a clster. Expand a volme for a clster. Delete a volme. Create pass-throgh disks. Expand a pass-throgh disk. Refer to the EMC ViPR Add-in for Microsoft Virtal Machine Manager Installation and Configration Gide and the EMC ViPR Add-in for Microsoft Virtal Machine Manager Online Help for more information. EMC VSI for VMware vsphere Web Client version 6.0 EMC VSI allows yo to easily provision and manage ViPR storage for ESX/ESXi hosts. VSI is an architectre that enables the featres and fnctionality of ViPR storage. Tasks that yo can perform with VSI inclde storage provisioning, storage mapping, and viewing information sch as capacity tilization. VSI interfaces within the vcenter to access the ViPR storage. Refer to the EMC VSI for VMware vsphere Web Client Version 6.0 Prodct Gide for more information. ViPR integration with compte stacks 15

16

17 CHAPTER 2 ViPR-specific Resorces This chapter contains the following topics. ViPR resorce conceptal overview Virtal data center...19 Virtal array...19 Virtal pool Tenant...24 Project Service catalog...25 ViPR-specific Resorces 17

18 ViPR-specific Resorces ViPR resorce conceptal overview A high-level conceptal diagram of the ViPR virtal data center with its primary storage resorces is shown below. Figre 3 ViPR resorce conceptal overview ViPR Virtal Data Center Data Center Infrastrctre - millions of storage resorces - heterogeneos storage - partitioning of host, network, and storage resorces into virtal arrays for falt tolerance ESX hosts Virtal Array host por orts Networ works storag rage ports ESX hosts Virtal Array host por orts Networ works storag rage ports Virta tal Pool physical pools Virtal Pool physical pools physical storage systems physical storage systems Mlti-Tenant - self-service provisioning, metering, and monitoring - role-based athorization Tenants Projects Block Storage Volmes File Storage File Systems Object Storage Bckets Storage as a Service (STaaS) - programmable, elastic - different virtal pools - policy-based management - integration into VMware clod stack and Microsoft Hyper-V - reporting on storage capacity, allocation, and health Block Control Service File Control Service Data Services Virtal Virtal Virtal Virtal Virtal Virtal Virtal Virtal Virtal Pool Pool Pool Pool Pool Pool Pool Pool Pool The concepts in ViPR relate to the ViPR-defined logical abstractions (or resorces) that are niqe to ViPR and the physical resorces that are managed by ViPR. These are explained in detail in the following sections. ViPR-specific resorces Virtal data center on page 19 Virtal array on page 19 Virtal pool on page 22 Tenant on page 24 Project on page 25 Service catalog on page EMC ViPR Concepts Gide

19 ViPR-specific Resorces Physical resorces managed by ViPR Storage system on page 28 Storage pool on page 28 SAN switch on page 28 Network on page 29 Volme on page 30 Volme export on page 30 File system on page 31 Snapshot on page 31 Host on page 31 vcenter server/clster on page 32 Data store on page 32 Object on page 33 Bcket on page 34 Virtal data center The virtal data center represents the ViPR storage control point in a physical data center. The virtal data center is a collection of storage infrastrctre that is managed as a cohesive nit. Geographical co-location of storage systems in a virtal data center is not reqired. However, high bandwidth and low latency is assmed within the virtal data center. One ViPR instance can control all the storage resorces within the virtal data center. Typically one ViPR virtal appliance is deployed for each physical data center. Note In ftre releases, it will be possible to deploy ViPR as a geographically-dispersed configration, where several ViPR instances control mltiple data centers in different locations. In this ftre configration, ViPR instances cold be implemented as a looselycopled federation of atonomos virtal data centers. However, federation of geographically-dispersed virtal data centers is not spported in the ViPR 1.0 release. Storage resorces volmes, file systems, and objects are provisioned into the virtal data center. All ViPR resorces are contained and managed within the virtal data center; the virtal data center is the top-level resorce in ViPR. Virtal array A virtal array is an abstract or logical array that is created by a System Administrator to partition a virtal data center into a grop of connected compte, network, and storage resorces. A virtal data center is typically partitioned into virtal arrays for prposes of falt tolerance, network isolation, or tenant isolation. A virtal array can span mltiple physical arrays and conversely a physical array can be partitioned into mltiple virtal arrays. Virtal arrays can also be connected throgh disaster recovery and high-availability links in environments sing RecoverPoint and VPLEX Metro configrations. Virtal data center 19

20 ViPR-specific Resorces Figre 4 Virtal arrays in the ViPR virtal data center ViPR Virtal Data Center Virtal Array Virtal Array Networks DR HA Networks virtal pools virtal pools Hopkinton, MA Data Center Westboro, MA Data Center EMC/NetApp Storage EMC/NetApp Storage A virtal array is essentially defined by network connectivity and incldes: SAN switches/fabric managers within the networks IP networks connecting the storage systems and hosts Host and storage ports connected to the networks ViPR virtal pools (In addition to network connectivity, a virtal array is associated with one or more virtal pools.) In a data center environment, examples of virtal arrays cold be large-scale enterprise SANs or compting fabric pods. Althogh the end ser provisioning storage may be aware of virtal arrays, they are not aware of the nderlying infrastrctre components (sch as shared SANs or compting fabrics). This information is only available to the System Administrator. Tenant access to each virtal array is controlled by an Access Control List (ACL). Only tenants that are inclded in the virtal array's ACL are permitted provisioning access to that virtal array. The ACL for a virtal array is set by the System or Secrity Administrator. If no ACL is set, the virtal array can be sed for provisioning by all tenants in the ViPR virtal data center. Consider the example shown in the figre below. Virtal Array 1 incldes (or is mapped to) Networks A and B with their collection of connected host and storage ports, as well as Virtal Pool A on the array. All physical devices within a virtal array mst be able to commnicate with each other within the virtal array for ViPR to manage the storage infrastrctre properly. When a ser reqests a volme or file system export from an array to make the storage visible on a host, ViPR determines which network in the virtal array contains the desired host initiator ports and storage ports, and then selects the switch that can manage that network. 20 EMC ViPR Concepts Gide

21 ViPR-specific Resorces Figre 5 Virtal array partitioning ViPR Virtal Data Center host host host initiator ports host initiator ports Network A Network B Network C Network D VSAN VSAN VSAN VSAN Virtal Pool A storage ports Virtal Pool B physical pools physical pools Virtal Array 1 Virtal Array ray 2 physical storage system volme/file system export path from storage port to host initiator port The above figre depicts a scenario where there are no shared networks among virtal arrays. In this scenario, all the physical storage ports and pools associated with a network are inclded in the network's assigned virtal array. For example, all the physical ports and pools in Network A are inclded in Virtal Array 1. However, a network (SAN fabric or IP network) can be assigned to more than one virtal array. When a network is assigned to mltiple virtal arrays, all the storage ports and pools associated with the network are atomatically added to the assigned virtal array. However, yo may choose to manally select a sbset of ports or pools from a network to associate with a virtal array. Consider the following scenario where Network A is assigned to two virtal arrays: Virtal Array 1 and Virtal Array 2. Network A has for storage ports in it. By defalt, all for storage ports are atomatically added to both Virtal Array 1 and Virtal Array 2. Bt the System Administrator decides that s/he wants to manally assign two ports (ports 1 and 2) to Virtal Array 1, as shown in the figre below. These two ports are now exclsively inclded in Virtal Array 1; they cannot be assigned to another virtal array. So after the manal assignment of ports 1 and 2 to Virtal Array 1: Virtal Array 1 incldes ports 1, 2, 3 and 4. (Ports 1 and 2 were manally assigned, and ports 3 and 4 were atomatically assigned to this virtal array when the network was assigned.) Virtal Array 2 incldes ports 3 and 4. Virtal array 21

22 ViPR-specific Resorces Figre 6 Manal and atomatic port assignments in shared network among virtal arrays Virtal Array 1 Virtal Array 2 Network A p1 p2 p3 p4 Virtal pool There are three types of virtal pools in ViPR: block, file, and data services. Block and file virtal pools are sets of block and file storage capabilities that are created to meet varios storage performance and cost needs. Rather than provisioning capacity on storage systems, the System Administrator can give sers the ability to se block and file virtal pools that meet their niqe reqirements. Data services virtal pools are sed to store object data and are backed by storage on nderlying ViPR-managed file arrays. The System Administrator is responsible for creating and configring block, file, and data services virtal pools within a virtal data center. Block and file virtal pools For block and file virtal pools, the System Administrator defines a set of storage service capabilities, sch as type of storage (file or block), protocol (FC, iscsi, CIFS, NFS), storage system type (VPLEX, VMAX, VNX block or file, Isilon, NetApp), protection, and performance characteristics. The System Administrator then associates the virtal pool to physical storage pools on the ViPR-managed storage systems. ViPR atomatically matches existing physical pools on the ViPR-managed storage systems to the virtal pool characteristics specified by the System Administrator. The System Administrator has the option of allowing ViPR to atomatically associate the matching physical pools to the virtal pool that he or she is creating, or the System Administrator can manally select a sbset of the matching physical pools to associate to the virtal pool. This is an important step; a System Administrator mst careflly set p the block and file virtal pools, becase the virtal pools are the driver for all ftre block and file provisioning tasks performed by end sers. Once the System Administrator has created the virtal pools, sers can create file and block storage sing the virtal pool that has the storage characteristics they reqire. The file and block stores provide a set of bilt-in virtal pool capabilities and enable the System Administrator to define cstom capabilities, if desired. For example, the System Administrator cold define two virtal pools in the file store: A Tier 1 virtal pool with high-speed I/O and data protection capabilities optimized to minimize disrption to database access for critical bsiness applications. A Tier 2 virtal pool that has lower I/O speed and no data protection capabilities that will be sed for internal development and testing prposes. In the figre below, the System Administrator creates a block virtal pool named Mission Critical. The defined set of storage capabilities indicate that the Mission Critical block virtal pool is associated with the VMAX_VA_1 virtal array, the storage system type is EMC VMAX, the protocol is Fibre Channel, the data protection is RecoverPoint, and so on. 22 EMC ViPR Concepts Gide

23 ViPR-specific Resorces When an end ser wants to create a volme with these storage characteristics, he or she simply selects the Mission Critical block virtal pool when the volme is created. Figre 7 Creating a block virtal pool ViPR Virtal Data Center Name: Mission Critical Storage Type: Block Provisioning Type: Thick Virtal Array: VMAX_VA_1 Protocol: Fibre Channel virtal pool Nmber of Paths: 4 Drive Type: SSD System Type: EMC VMAX Data Protection: RecoverPoint AtoTiering: FAST spport System Administrator creates a virtal pool named Mission Critical with a defined set of storage qality parameters. physical pool A ports VMAX storage system physical pool B System Administrator associates physical storage pools on a VMAX storage system to the virtal pool. Mission Critical virtal pool physical pool A physical pool B Physical storage pools A and B are virtalized into the Mission Critical virtal pool. End sers only see the Mission Critical virtal pool for self-service provisioning, not the nderlying physical storage pools and storage system. Note When a virtal pool is created, a virtal array mst be defined. A virtal pool can be associated with more than one virtal array. Tenant access to each virtal pool is controlled by an Access Control List (ACL). Only tenants that are inclded in the virtal pool's ACL are permitted access to that virtal pool. The ACL for a virtal pool is set by the System or Secrity Administrator. If no ACL is set, the virtal pool can be accessed by all tenants. Refer to ACLs for more information. A virtal pool has a maximm total storage capacity (qota) associated with it that cannot be exceeded. The sed and maximm total capacity vales for a virtal pool are inclded in ViPR metering records. Data services virtal pools To create a data services virtal pool, the System Administrator only needs to specify the name, description, and the type of the data services virtal pool. The type can be either Object, HDFS, or Object and HDFS, depending on whether the System Administrator wants to set p the data services virtal pool to provision object storage sing the Object Data Service or the HDFS Data Service, or both. The data services virtal pool is backed by storage from ViPR data stores. Each data store maps to a physical file share and the storage qality of the data store is defined by the storage capabilities of the associated file virtal pool. Refer to data stores for more information. The figre below shows a high level view of how object storage is provisioned in ViPR. In this example, Tenants 1 and 2 set p defalt projects in which to store objects and they specify a ViPR data services virtal pool as the defalt virtal pool to provision their object storage. The data services virtal pool is provisioned with two ViPR data stores that were created by a System Administrator from a ViPR file virtal pool. The file virtal pool maps to a physical file storage pool on an Isilon filer. Virtal pool 23

24 ViPR-specific Resorces Figre 8 ViPR data services virtal pool and related resorces Tenant 1 Tenant 2 defalt project 1 defalt project 2 ViPR data services virtal pool (object, HDFS, or object + HDFS) ViPR data store 1 GB ViPR data store 3 GB ViPR file virtal pool (10 GB) physical file storage pool physical file shares ViPR-managed filer Tenant A tenant represents an organization/company operating within the ViPR virtal data center. Tenants are created in the ViPR virtal data center to isolate organizations from each other in a clod service provider infrastrctre. As an example, imagine Company PDQ and Company XYZ are two tenants sharing the same infrastrctre within the ViPR virtal data center: secrity isolation between the tenants ensres that no one from Company PDQ can know of or affect anything in Company XYZ and vice versa. When sing ViPR Data Services, sers from different tenants see a tenant URL namespace that is limited to the information associated with their tenancy. For example, sers in the Company XYZ tenant only see information related to Company XYZ. Each tenant is configred with its own list of mapped sers who are athenticated to perform provisioning operations within that tenant. ViPR is designed to operate in a mlti-tenant environment where each tenant has its own list of athenticated sers. When a Tenant Administrator creates a tenant, he or she maps sers into the tenant by specifying the ser domain(s), ser attribte(s), or grop membership(s) that exist in the ViPR virtal data center. These domains/ser grops are available in the ViPR virtal data center becase the Secrity Administrator adds sers into the system by accessing ser domains/grops in existing Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) acconts. These AD/LDAP ser grops/domains/attribtes are specified in the athentication providers set p by the Secrity Administrator to bring sers into the entire virtal data center. The Tenant Administrator can then se the existing ser domains and related ser attribtes to specify which grops of sers he or she wants to map into their tenant. 24 EMC ViPR Concepts Gide

25 ViPR-specific Resorces The ViPR virtal data center is organized sch that there is a root tenant called the provider tenant. The provider tenant wold be the clod service provider in a pblic clod deployment or an entire enterprise IT organization in a private clod deployment. In an enterprise private clod scenario, there is only the provider tenant, with no nderlying tenants (sbtenants). In the clod service provider scenario, a ser in the provider tenant with the Tenant Administrator role may create tenants nder the provider root tenant (for example, the Company PDQ and XYZ tenants), where each tenant is configred with its own list of mapped sers who are allowed to operate within the tenant. Note that in the API and CLI, the tenants are referred to as sbtenants. A tenant has a maximm total storage capacity (qota) associated with it that cannot be exceeded. The sed and maximm total capacity vales for a tenant are inclded in ViPR metering records. Tenant access to virtal arrays and virtal pools can be controlled by an Access Control List (ACL). Note that virtal arrays and virtal pools are accessible to all tenants by defalt. However, a System or Secrity Administrator can assign an ACL to a virtal array or virtal pool to restrict them to be sed by specified tenants only. Refer to ACLs on page 40 for more information. Project A ViPR project is a groping of resorces mapped to applications, virtal data centers, departments, or other entities meaningfl to the ser. Users can create their own projects within their tenant, and they can provision mltiple storage resorces from different data services to their projects (for example, storage volmes, file systems, or objects sch as files or images). Resorces from one project can be shared between sers nder the same tenant. Examples of sing projects cold be: A ser creates a project for a Photo Albm application and provisions one block volme for a ser accont database and one data store for storing the pictres. A ser creates a project called VDC Data Stores and provisions it into mltiple volmes for se by their ESX clster. A Tenant Administrator creates a project for se by a specific department. A ser mst be assigned the Tenant Administrator or Project Administrator role in order to create projects. One level of projects can be created nder a tenant. A Tenant Administrator has fll management access to all projects within the Tenant. A Project Administrator can only create projects; they cannot manage the resorces within the project. A project has a maximm total storage capacity (qota) associated with it that cannot be exceeded. The sed and maximm total capacity vales for a project are inclded in ViPR metering records. Service catalog The service catalog in the ViPR UI enables sers to select a pre-configred service which is appropriate to the storage operation they want to perform. Services encapslate the most common storage operations that ViPR provisioning sers will want to perform. Users rn services from the service catalog in order to create and manage block and file storage. The services are groped logically into categories sch as: Block storage services Project 25

26 ViPR-specific Resorces Block protection services File storage services File protection services Block storage services for Linx Block storage services for Windows Block storage services for VMware File services for VMware Examples of services in the block storage services category inclde: Create block volme for a host Export volme to a host Expand block volme Remove block volmes Change virtal array Change virtal pool 26 EMC ViPR Concepts Gide

27 CHAPTER 3 Storage Resorces Managed by ViPR This chapter contains the following topics. Storage system Storage pool...28 SAN switch (fabric manager)...28 Network Volme Volme export...30 File system Snapshot Host vcenter Server/clster...32 Data store Object Bcket Storage Resorces Managed by ViPR 27

28 Storage Resorces Managed by ViPR Storage system The first step in configring ViPR after deploying the virtal appliance is to add physical storage systems into the ViPR virtal data center. Adding storage systems to ViPR can only be performed by a ser with a System Administrator role. When storage systems are added, ViPR atomatically discovers the storage pools and ports on each storage system and adds them into the ViPR virtal data center. When storage systems with their associated storage pools and ports are added into ViPR, they are atomatically registered, meaning they can be managed by ViPR. The System Administrator can nregister storage systems, pools, and ports if he or she does not want these physical storage resorces managed by ViPR. Only a System Administrator has visibility and control over the physical storage components in ViPR. (A System Monitor can also see the physical storage components, bt has read-only access.) Other sers in the ViPR virtal data center do not see the nderlying physical storage infrastrctre. ViPR spports EMC VPLEX, VMAX, VNX, Isilon, and NetApp storage systems for block and file storage provisioning. For object storage, ViPR spports VNX file, Isilon, and NetApp filers. If a System Administrator tries to add a storage system into ViPR that does not meet the minimm version spported by ViPR, the storage system will be identified as Incompatible, and will not be discovered and managed by ViPR. Refer to the EMC ViPR Data Sheet and Compatibility Matrix on spport.emc.com for the specific storage system models and versions spported. Storage pool Physical storage pools on a physical storage system are atomatically discovered and added into ViPR when a System Administrator adds the physical storage system into the ViPR virtal data center. The System Administrator can associate ViPR-managed physical storage pools to a virtal pool. This virtal pool is what is presented to end sers for self-service provisioning; they do not see the nderlying physical storage pools. Virtal pools simplify storage provisioning tasks for the end ser by abstracting the nderlying physical storage pools. (Refer to virtal pools on page 22 for more information.) Note that a physical storage pool can be associated to more than one virtal pool. A physical storage pool has to be associated to a virtal pool and a virtal array by the System Administrator before it can be sed for self-service provisioning by end sers. SAN switch (fabric manager) 28 EMC ViPR Concepts Gide After adding storage systems into ViPR, a System Administrator adds SAN switches into ViPR. SAN switches are called fabric managers in the UI. When a Fibre Channel switch (sch as a Cisco or Brocade switch) is added to ViPR, ViPR discovers the Fibre Channel SAN, (that is, its connected host and storage ports) and one or more networks are atomatically created that contains the switch s connected ports. One network is created for each Cisco VSAN or Brocade fabric that is discovered on the SAN switch. For example, on a Cisco switch, if there is a VSAN named VSAN 3180 with several host and storage ports, a network named VSAN_3180 is atomatically created with the appropriate endpoints poplated.

29 Storage Resorces Managed by ViPR Fibre Channel networks are atomatically discovered and created from SAN switches, bt the networks are not initially associated with a virtal array. The System Administrator mst assign the discovered networks to virtal arrays when he or she sets p the ViPR virtal data center. Network Networks are located within virtal arrays and represent connectivity within the virtal arrays. A network maps to physical switch connectivity. One network maps to each VSAN/fabric discovered on a switch with its collection of endpoints; that is, the storage system ports and host ports (initiator ports on a host ESX server) to which the switch is connected. Networks control the paths of storage resorces. A network is important for exporting volmes and file systems it is the physical connection path that a volme/file system takes when it is exported from a storage system to make it visible on the host to the ser. Note that networks for VNX block storage systems reqire a SP-A and SP-B port pair in each network. There are two types of networks in ViPR: SAN and IP networks. SAN networks control the paths of volmes and IP networks control the paths of file systems and object data reqests. IP networks mst be created manally by the System Administrator and then assigned to a virtal array for file data service operations. The System Administrator can also assign an IP network to the Object/HDFS Data Service, if object data path operations will be performed in the ViPR virtal data center. The figre below shows SAN network connectivity in a virtal data center with typical Fibre Channel mlti-pathing sing two SAN networks per virtal array. Figre 9 Network connectivity in the ViPR virtal data center ViPR Virtal Data Center host initiator ports host initiator ports Network A Network B Network C Network D VSAN VSAN VSAN VSAN storage ports storage ports Virtal Pool A CoS CoS CoS volmes CoS CoS CoS Virtal Pool ol B volmes CoS Virtal Array 1 Virtal Arrayray 2 physical storage system Ble dotted lines represent the path a volme takes throgh the SAN when it is exported from a storage system to make it visible on an ESX host. Networks can be configred for atomatic SAN zoning, meaning that ViPR atomatically picks the best path a volme takes throgh the SAN. Network 29

30 Storage Resorces Managed by ViPR Each virtal array is shown with two SAN networks; however there is no limit to the nmber of networks in a virtal array. Note that on a single physical storage system the storage ports can be connected and participating in networks located in two virtal arrays for high availability, while the initiator ports on the ESX hosts are connected and participating in networks located in only one virtal array. The membership of a physical storage system to a virtal array is via the network connectivity and one physical storage system may participate in many virtal arrays and many networks. The diagram also shows that a specific volme exported from Virtal Pool A to a specific host initiator port can take two potential paths throgh either Networks A or B within Virtal Array A. That is becase ViPR allocates at least one path in each of the networks to which the target host is connected. In this case, the target host is connected to two networks, so there are two volme export paths; one throgh each network connected to the host. Volme Volme export A volme is a nit of block storage capacity that has been allocated by a ser to a project. Volme provisioning operations are performed after the System Administrator has set p the ViPR virtal data center. Volmes are provisioned within the context of a project by sers who meet one of the following criteria: have a Tenant Administrator role. are a project owner. have an ALL access control list (ACL) permission on the project. See ACLs on page 40 for more information on project ACL permissions. When a volme is created, the ser mst select the project and virtal array in which the volme will reside, and the virtal pool that will define the volme's storage performance characteristics. Once the volme is created, it can be exported (within its virtal array) to mltiple hosts. In this way, a host clster can be provisioned with shared block storage. Exports are sed to export a volme to one or mltiple host initiator ports, thereby making a volme visible on one or mltiple hosts. A volme can only be exported to hosts which reside in the same virtal array. Volme exports are sefl for setting p shared storage within a clster. Shared storage can be a list of volmes and volme snapshots previosly provisioned within a virtal array. When the export is created, a list of initiators from the hosts in the clster are specified; the shared storage will be visible to these hosts. Once a volme export is created, incremental changes can be made to it, sch as: Add volme or volme snapshot to the shared storage pool. Remove volme or volme snapshot from the shared storage pool. Add new host to the clster by adding the initiator port from that host to the export. Remove visibility of shared storage to a host by removing initiator ports from the export. Similar to block storage volme provisioning, exports are also created within the scope of a virtal array. Therefore, volmes and snapshots that are added to an export mst belong to the same virtal array. Host initiator ports mst be part of SANs belonging to the same virtal array as the export. 30 EMC ViPR Concepts Gide