Technology Short Take #9

Merry Christmas, and thanks for the mention/link.

Hi Scott,

Hope you had a great Christmas.

Re your comment that VSP and VMAX. While VSP and VMAX clearly share many similarities, however, “in this regard” as you put it I do not personally believe they share a similarity. (Assuming Ive understood what you are inferring)

In VMAX all processors are tied to either a front end or back end port. Unless I’m getting rusty on VMAX, these processors manage front end and back end I/O as well as things like T/F and RDF…. The processors/slices are named something like A through H with some being tied to backend and other to front end ports. E.g. H0 and H1 ports on the front a VMAX are mapped to processor/slice H. The resources of slice H cannot be utilised by other front or backend ports (at least not in the same way…).

VSP has ASICs that are tied to front and back end ports in a similar way (these are purpose built I/O processors), but VSP also has a pool of intel CPUs that are pooled and that execute the equivalents of T/F and RDF etc. These general purpose intel chips dont handle I/O, they execute most of the additional functions such as thin provisioning, dynamic provisioning….

To be honest, I like what Hitachi have done from an architectural perspective. Although Im not sure if its worth the investment (custom ASICs etc) and if it makes mush difference from a performance, availability and maintenance perspective. I imagine there are some benefits but I don’t know how well they actually work. Will be interesting to see how the differences pan out. I also like how VSP and VMAX are going down different architectural roads – keeps things interesting.

I think I’ll have a crack at a VMAX vs VSP post over the next week or so, but one that wont see me lose my job

Nigel

Hello Scott – thanks for linking to my blog. I would like to correct your impression that the Hitachi VSP and the EMC VMAX share architectural similarities. In fact they are contrasting architectures. The Hitachi VSP is a tightly coupled pool of global processors, global cache, Front End processors, and Back End processors, where the tight coupling is done through an internal switch matrix. With this architecture, we can scale out individual components like Front End processor blades or scale up performance with global processor blades without having to add other components. The VMAX architecture consists of storage nodes that are loosely coupled over an external switch. Each storage node is basically a two controller modular storage system with a limited number of storage ports, cache, and disks. The two controllers consist of two processors, which support all the functions like replication, tiering, snap shots, etc. in addition to the front end and back end processing. When an application talks to a VMAX system it can only talk to one of the storage nodes and is limited to the resources in that one storage node. Additions to a VMAX has to be done by adding an entire storage node, even only additional disk capacity is required.

When an application talks to a VSP it can access a common pool of resources that can scale across the entire VSP system, including up to 247 PB of external storage, and the scaling can be done by individual components.

Amrith Kumar provided a good analogy in my post on “Redefining scale-up and scale-out” by comparing the difference in storage architecture to that of server MPP and SMP architectures.

http://blogs.hds.com/hu/2010/12/redefining-scale-up-and-scale-out.html#comments

Each subsystem in an MPP is self contained with its own processor, memory, operating system, and application which communicates with the other subsystems over a high speed interconnect. This type of system does not scale unless there is additional software that can distribute the application workload across the subsystems. This is not required with an SMP since it shares the same memory, operating system, and application. The VMAX architecture is similar to the MPP architecture while the VSP is similar to the SMP in that it can share all the resources in the support of a storage application.

Happy New Year Nigel,

Thanks for helping to clarify the difference between the VMAX and VSP architectures. The concept of having a pool of Intel processors to handle the general purpose functions of Dynamic Provisioning, tiering, replication, etc is one that many people over look. As you note, Hitachi continues to use a customized processor for our front and backend I/O processing. Hitachi learned many years ago that I/O processing can be optimized by using an instruction set that is optimized for I/O. However, over the years as the storage systems took on more workload like, replication and dynamic tiering, etc, these processors were required to do more general processing. In the VSP, Hitachi separated the I/O processing from general processing to distribute the processing workload and enable the I/O processors to be refocused on processing I/O. Using a reduced instruction, the dual core I/O processors in the VSP can process more I/O than a general purpose quad core processor, with less cost and power consumption. This separation also enables more scaling flexibility in adding separate pairs of I/O and general purpose processors as required.

I am looking forward to your post on VMAX vs. VSP. Let me know if you need any information from Hitachi.

For the record, depending upon performance and capacity
requirements, each VMAX engine can support either 16, 24 or 40
DAEs, or 240/360/600 drives; DAEs can be added to existing engines
non-disruptively in groups of 8 (additional engines can also be
added non-disruptively).

Nigel and Scott, great discussion.

What Scott says is the bottom line. It doesn’t matter what is inside as long as it provides efficiency, performance, integration, and functionality at a competitive price.

As far as VMware goes, we believe the VSP provides better scalability and better support for the VAAI offload functions like write Zeros, copy, and SCSI Reserve offload, because of the way we separate the general purpose computing from the I/O processing and tightly couple them through a global cache. In other storage systems, the same commodity processor must service all these functions out of an active/passive cache, which is bound to affect performance and scalability.

In terms of time to market, Hitachi feels that using custom designed ASICs gives us an advantage, since we do not need to wait for the development of off the shelf components to deliver new functionality. Hitachi is a vertically integrated company with a heavy investment in R&D and we can develop what we need when we need it. Hitachi was the first to introduce the internal switch architecture in storage systems, as well as virtual ports, dynamic cache partitioning, dynamic tiering, Dynamic provisioning for internal and external storage, etc.

The question of separate cores or separate processors, is one of modularity. Adding I/O FED and BED processors can be done at a more granular level than adding VSD general purpose multi-core processors. Hitachi is using both approaches in the VSP.

Barry — so for the record, if you need 601 drives, do you need to add another engine? With 8 VMAX engines do you support 4800 drives?

Thanks Scott for opening up this discussion. We are in
agreement. Certainly all systems have inflection points where they
have to add more hardware, but it is the granularity of the
hardware we add that makes a difference. If you need more
processing power in a VSP you add VSD blades or cache adapters, for
connectivity or external storage – FEDs, for internal drives –BEDs.
There is a point where we need to add another control frame to
house more than 4 VSD blades, or 4 BED blades, or 8 Cache adapters,
or 12 FED blades and I also need to add drive frames when I exceed
3 drive modules. The point is that the VSP is more granular in
scaling since it can add components as needed without having to add
whole storage nodes with dual quad core processors, dual cache
modules, FEDs, BEDS, and DAE’s.