Free ESG report : Seamless data management with Avere FXT

Can ViPR - EMC's virtual data management package - really aggregate logical storage units across different devices?

EMC's new storage virtualisation and management layer of software, ViPR, is interposed between server applications and arrays like VMAX. If it cannot aggregate LUNS across the drive arrays underneath it then this would be a serious limitation.

Applications in servers access items known as storage volumes, a logical construct made from: part of a disk drive; a complete disk drive; or, as is common in these days of large amounts of data, many disk drives.

Volumes are numbered and addressed as Logical Unit Numbers, or LUNs. A LUN for a volume spanning several disk drives is a common need and one met by block-access storage arrays such as EMC's VMAX. What applications often need to do is to aggregate LUNS across disk drive arrays so as to provide even larger addressable amounts of storage.

The structure of such an aggregated LUN is known to a system-level application in servers using it, but not to the individual component arrays.

We have heard from an industry source that "ViPR is unable to aggregate LUNs from multiple arrays as [it has] no agent deployed on servers to understand volume structure".

According to Amitabh Srivastava, head of EMC’s advanced software division, ViPR has a decoupled control and data plane: the controller operates in the control plane and is responsible for storage resource management while the ViPR data services operate in the data plane. Each of them can provide aggregation in their respective path.

So, turning to ViPR controller LUN aggregation, Srivastava said:

The ViPR controller enables the user to create a single virtual array that may span LUNs from multiple arrays that pool resources of similar capabilities across multiple arrays. The controller is not in the data path and will not provide aggregation of individual LUNs across physical arrays, it simply appears like a single disk with multiple partitions. Within an array, LUNs can be grown up to the capacity of the array.

ViPR does not aggregate LUNs across storage arrays, however. That has to happen in the storage data path, according to Srivastava:

Providing for LUN aggregation functionality requires data path storage virtualisation. Any such solution compromises performance and latency guarantees that the physical array is designed to provide. For instance, flash-based solutions are optimised for both throughput and latency – getting inserted into the data path would negate the capabilities of both.

LUN aggregation in the storage data path can add latency to data access and slow down a storage array's response to data IO requests. So ViPR doesn't do it, but data services layered on ViPR can do it where performance is not such an issue:

A large proportion of our customers today are highly performance-sensitive and since the ViPR Controller operates in the control plane we can drastically simplify management of their infrastructure without introducing any performance overhead.

… in those instances where customers are less performance-sensitive we can leverage ViPR data services, such as ViPR object data services, which does aggregation of underlying arrays for objects allowing them to span multiple arrays.

Srivastava went to explain that block data path services are enabled through EMC's VPLEX virtual storage suite, which provides data path virtualisation for block services. Future plans for VPLEX include making it available as a ViPR data service.

ViPR Data Services slide from David Goulden's EMCWorld 2013 keynote.

In general, Srivastava said: "There were a number of reasons we did this but primarily it was to give us the flexibility necessary to support all our users today and into the future." ®

5 ways to reduce advertising network latency