Originating Author: David Vellante
The basic philosophy behind XIV is let the system manage complexity (e.g. data placement, performance tuning, etc). XIV’s virtualization approach that spreads data over all disks in the array is optimized for capacity utilization, performance, and storage management simplicity. Generally, 3PAR is accepted in the industry as the gold standard for ease-of-use, and it appears at least on paper that XIV is challenging 3PAR's leading status. While XIV is newer and doesn’t have the infrastructure built up around it that other entrants have, the trend in the storage industry is becoming clearer: ease-of-use, simplicity, and reduction in complex management tasks are increasingly in demand.
As CFOs pose questions like “Does IT matter?” and senior management is intensely focused on both CAPEX and OPEX efficiencies, it stands to reason that IT professionals who have built up skills around managing storage complexity should ask themselves: “How valuable will these skills be in five years?”
Some of the more cumbersome tasks that are necessary in many of today’s storage environments are things like LUN management and data placement. For example, when you want to create a LUN, you must specify where you want the LUN to be placed by finding contiguous space on the array that is large enough to handle the application. If that physical space runs out, you need to find a new location (more contiguous space) and move data around. This space needs to be defined, set up and ‘attached’ to the applications via a logical unit number (LUN) that is specific to an array and a volume which is mounted by an application. Storage admins need to understand the connection between the applications-->volumes-->devices. In addition, the admin needs to understand the ports through which an application accesses devices. This is critical because security practices dictate that data on a LUN can only be addressed by applications with requisite access rights.
These tasks are often deemed as onerous and require special knowledge, skills, and processes built up over many years. While there are tools and management systems that help facilitate these tasks (e.g. EMC’s Virtual LUNS), underneath the covers this is all going on, and storage admins need to have fairly specific knowledge of these dynamics in case something goes awry.
In theory, this all goes away with infrastructure like XIV. Storage pools are created for capacity isolation reasons, not performance. The storage admin does not plan the layout of the volumes relative to physical drive resources. Storage pools and volumes can be dynamically resized. LUN Maps define the open systems server and the LUNs to be accessed. Logical volumes can be added to or removed from any map dynamically. The reason is that everything is broken up, and the volume (a logical construct) is protected by its volume identifier, and you define what applications can address that volume. All security, path allocation, data placement, copy management, cache management, and everything else is dealt with by the ‘black box’ array OS. Again, in theory a customer has complete security, automation, data placement, performance tuning, free space allocation, etc. The drawback is the level below the logical construct cannot be accessed by the admin. If something goes wrong…you’re dead. This approach requires trust that everything is going to be managed correctly.
These issues apply not only for operations but also application development. If application design specifies THE highest performance – you will pay the price, perhaps unnecessarily. Organizations should avoid designing applications to require purpose-built storage unless it is absolutely justified.
Action Item: Organizations need to have earnest discussions about the business value of data management and decide where they want resources to be targeted. High performance mission critical applications may warrant traditional complexity however most information in the data center requires good enough performance and the greatest simplicity possible. Emerging architectures like 3PAR and XIV provide a glimpse of the future of storage management underpinned by removing complexity, not just hiding it.
Footnotes: