In 2000, Hitachi Data Systems introduced the Lightning 9900 storage subsystem with an internal switch that tightly coupled Front End (FE) and Back End (BE) port processors through a global cache. This enabled any to any connection between the FE storage ports and the BE disk controllers. If an application needed more FE port processing power it just connected more FE ports through alternate paths that  could be switched to the cache image of their data. The internal switch provided the ability to scale up  to meet increasing server demands.  (see my previous post on scale up versus scale out) Besides scaling up it enables the storage system to dynamically scale out by partitioning the storage resources for different applications at different times based on policies that are triggered by time or events. Availability is also improved through its ability to switch around hotspots and failures.

Supporting this internal switch is a separate control memory which contains control information about port assignments, cache slots, track tables, and now, with the USP V, paging information for Dynamic (thin) Provisioning.  By changing bits in the control memory the configuration can be dynamically changed and data  can be moved between tiers of storage without interruption to the application.  This also enables the ability to attach external storage systems which are virtualized through the USP V’s global cache. The separation of control from data eliminates the contention that would occur between the two if they resided in the same cache memory.  A separate control memory also provides security for call home maintenance since the remote service rep can monitor and diagnose problems without exposing the data cache. 

Other storage vendors have introduced storage systems that include switches for loose coupling of modular storage systems. This enables storage systems to scale out to large capacities by modular increments. But it does not enable dynamic scale out across the resources of multiple modules to meet different application needs, and it does not scale up to meet increasing server needs. In a loosely coupled configuration the switch resides outside the modular storage systems and has some capability to transfer workload between modular systems, but the maximum storage resources that can be applied to a workload is that of one modular system’s FE and BE processors, cache, and attached disks.  It can not scale up to combine the use of resources across multiple modular storage nodes. Since control data is not separate, the meta data needed to manage the transfer of workload between modular nodes and synchronize the consistency of the separate caches can degrade performance.

Attached is a simplified drawing that illustrates the differences in how switches are used to tightly couple or loosly couple storage systems.

They agreed that the increasing workload required a storage system that could scale up as well as scale out as I noted in my previous post on Scale up or Scale out. Their next question was about the need for cache when I/O loads are random, since random I/Os are unpredictable and do not benefit from cache prefetch or cache reuse.

I believe there are at least three reasons for cache. The first reason is to mask the latency of the media on the back end through reuse and prefetch as noted above. When the I/O is very random the only way to address this is with faster media such as Flash disks, or wide striping which is available with most thin provisioning implementations.  Thin provisioning also helps to make more efficient use of expensive flash disks by eliminating the waste of allocated but unused capacity.

The second reason for cache memory is the support of functions like snap shots, copy on write, distance replication, tiering, and thin provisioning.  All these functions require access to control or meta data which needs to be stored in cache memory.  These functions are requiring more and more memory for meta data. This meta data has to be mirrored in cache and/or stored on disk.  Thin provisioning is a very heavy user of meta data. One competitor has 8GB cache in each drawer. When you read their user manual they say that 3 GB of that 8 Gb is used for control data, leaving only 5 GB for user data. Another vendor requires 143 KB for every thin device and 8 KB for every GB of reported thin device size.  Not only does this take away from the cache for use by production data, but it also impacts cache performance through the contention of production data with meta data traffic.

The USP V addresses this problem by servicing control data out of a separate control store memory that is accessed by separate busses than the switched connections to the data store. The result is no contention and more efficient operation of functions like thin provisioned wide striping which is important for support of  random I/O.

The third function of cache is to provide tight coupling of the storage resources so that it can be focussed on the processing of an I/O load. In this case I am talking about the ability to scale up as well as out with tight coupling through a global cache. As a virtual server platform scales up by adding more virtual machines or migrates to a faster multi core processor or switches from 4 Gbs FC to 8 Gbs FC  or 10 Gbs FCoE, that virtual server can access more of the storage port processors, cache,  and back end directors through a single global cache image. Loosely coupled modular storage systems will not be able to scale up to provide this capability.

So random I/O may not benefit directly from the cache benefits of reuse and prefetch,  but they benefit from the additional benefits of meta data caching, and tight coupling of all the storage system’s resources like port porcessors, control memeory, production cache, and backend directors to service a random I/O request.

I recently visited a customer who asked me what a good FTE (Full Time Employee) to TB ratio was for measuring productivity.  I told him that FTE per capacity managed was no longer a good measure of productivity.

In the past when we measured productivity  for operational costs in FTE  per GB, labor was the largest operational expense and the focus was on developing tools to make FTEs more efficient.  Five years ago I would visit a customer with 100 TB of storage and there might be 5 people managing it. When I visit that customer today I might find the same 5 people but now they have 500 TB. So have they become more efficient thanks to better tools? If that is the case why has operational costs continued to increase? Obviously operational costs have shifted some where else. An example might be found in device migration.

Five year ago there might have been 10 or 12 storage frames that made up the 50 TB, and storage was direct attached. Doing a device migration for direct attached storage with a handful of application servers could be done in few weekends. Today 500 TB could be on two storage frames connected to hundreds of servers through a SAN, and a device migration could take six months or more while migrating 4 or 5 applications a weekend to minimize application down time. For this reason David Merrill, the storage economist, estimates that the burdened cost to do a device migration today is about $7,000 to $10,000 per TB.

You can have one person do this migration and it will take 6 months. You can have 10 people do the migration and it will take 6 months, you can off shore it to India, and it will still take 6 months. This is no longer just an FTE problem, it is a scheduling problem. The best way to address a scheduling problem is through the use of storage virtualization. Storage virtualization separates the physical view from the logical view and enables most of the data to be migrated without disrupting the application. As storage systems get larger and larger and more and more applications are sharing the same storage frame, the need for storage virtualization will become mandatory.

Often I hear people talk about assigning data to tiers of storage based upon the “value” of the data, and they go through a very complicated study to classify the data by “value”. Some companies have spent several years on the classification of data and never finish. First, I would say that all data is valuable or you shouldn’t be keeping it. Secondly I would split out primary data from replicated data. Replicas are growing faster than primary data since we can not afford to stop applications today to do backups, development/test, data transformation, data mining, data distribution, and disaster recovery, etc. Rather than disrupt the application server to make these copies, it is simpler to have the storage systems make those copies, especially if we want a consistent copy across a group of related volumes. These copies do not have to be on the same tier of storage as the primary data. With storage virtualization you can snap them off to lower cost tiers of storage in the same storage system or to lower cost, externally attached, storage systems. There are also technologies to reduce the time and capacity required for making copies such as copy on write and Dynamic (thin) Provisioning.

Another way to classify a tier is by performance. This makes sense if there is a significant difference in price/performance between the storage tiers. Today we offer 200GB flash drives, 600 GB SAS disks, and 2 TB SATA in our modular AMS 2000 product which can move and copy data between internal tiers of storage without disruption to the application. As you can imagine, the differences in performance and cost per GB between these different types of media can be very significant. There are performance differences in rotation speed and RAID mapping which may make a difference for some types of workloads that are assigned to static tiers, but these differences may not justify the work to dynamically move data up and down tiers of storage on a frequent basis. Today, movement of data between tiers of storage is done by volumes or files, and moving large volumes and files is a very heavy workload that you might not want to do on a frequent basis.  You can start by allocating a volume to a mid tier of storage initially and if it turns out to need higher performance you can promote it to a higher performance tier  with storage virtualization. Storage virtualization provides  forgiveness if you happen to make a bad choice with your initial allocation.

With the USP and USP V dynamic movement of data across tiers can be automated through policies in a Tiered Storage Manager that are triggered by time or events that are generated by a Tuning Manager. In the USP  and USP V, we can also shred the old volume after migration to ensure privacy. In the USP V,  performance for a given tier of storage may be increased several times over through wide striping a volume across a large number of spindles. Wide striping is a feature of  Dynamic (thin) Provisioning which also shortens the time to move thin volumes versus normal fat, over allocated, volumes.

Data centers that implement disaster recovery, classify applications on the basis of RPO/RTO and assign critical application data to storage systems which have the capability to do distance replication for business continuity. Typically if an application must recover in hours, it uses enterprise storage to do synchronous and/or asynchronous replication. Enterprise storage used to consist of one tier of very expensive storage. However, today, with Hitachi Data System’s storage virtualization,  any internal or external tier of storage can be replicated for business continuity through the replication services of the USP or USP V.  Here again we can use Dynamic (thin) Provisioning to reduce the time and capacity needed for replication.

I have heard tiered storage referred to as HSM or Hierarchical Storage Management. HSM has a specific meaning for mainframes. In mainframes there used to be one tier of expensive storage, so to save storage capacity mainframes would do compression of the data and move the compressed data to a migration level 2 pool of storage. When they needed to access the data they would have to decompress it back to migration level 1 before they could use it. With the USP and USP V we can use virtualization to move mainframe volumes to low cost SATA disks tiers, either internal or external to the USPs. When we want to access the volumes we can access the volumes directly from the SATA tier without the need to move the data for decompression.

With the price and performance differences that we see today between flash drives, FC/SAS disks, and large capacity SATA disks the benefits of tiered storage have become very compelling. Storage Virtualization makes it easy to copy, move, and replicate data between internal and external tiers of storage without disruption to the applications. Additional services like copy on write, and Dynamic (thin) Provisioning can decrease the workload needed to do the tiering.

He not only covers what he expects to see in 2010 and 2011, but also trends that will be gaining ground in 2010 and trends that will not. There is a lot to agree with and a lot to disagree with, but overall it is well worth a read. As the title of the post indicates, many of the trends and predictions will be more of the same from 2009.

Of the trends that he predicts will be “slam dunks” I agree with his first four trends:
•    More cloud conversations and confusion
•    More server, desktop, IO and storage consolidation (virtualization)
•    Data footprint impact reduction ranging from deletion to archive to compress to dedupe among others
•    SSD and in particular flash continues to evolve

There will be more discussion and confusion around cloud, but there will also be some very clear offerings around content clouds, both private and public. While most customers will not be ready to use a cloud for primary data, many will consider cloud for content or reference data as a way to reduce the storage load in their data centers. The Hitachi Content Platform is available today and provides safe multi-tenancy for content data with RESTful interfaces that can scale to tens of Petabytes through a set of federated nodes.

Server, desktop, I/O and storage virtualization will also be a major trend. Storage virtualization will be a base requirement for future growth as we move to the next level of consolidation. Storage virtualization must be done at the right level in the stack. The SNIA definition of Storage Virtualization states that it is “The act of abstracting, hiding, or isolating the internal functions of a storage system or service from the application, host computer, or general network resources, for the purpose of enabling application and network independent management of storage or data. This definitely precludes doing storage virtualization in the network, application, or host computer. In order for systems to grow to thousand of server images, tens of thousands of network connections, and hundreds of Petabytes of data and still be efficiently managed; server, desktop, I/O, networks, and storage must be virtualized so they can add function and technology refresh independent of each other. They also must be able to scale together. If the host servers scale up with new multi-core technology, the networks, and storage must also be able to scale up as I pointed out in my previous blog post.

Data foot print reduction will also be a major trend that will provide a significant ROA, Return On Assets. Our customers are becoming increasingly aware of the value of moving static data, such as content data, reference data, or stale data from active storage repositories onto a Hitachi Content Platform that can manage the life cycle of static data, and avoid the need to back this data up. As long as there are at least two copies of the data and a way to prove immutability through hashing there should be no need to do backups for this type of data. The content platform can also provide de-duplication through single instance store and provide content aware search and retrieval of objects. By removing content data we reduce the working set of active data and eliminate the operational cost of managing the same data over and over again. Payformance is a good example of how this is done.

I expect to see more use of flash drives in enterprise systems despite the fact that the price/capacity will still be about 10 times higher than spinning disk. The combination of dynamic tiered storage and Dynamic Provisioning will help to optimize the use of flash drives to make them cost effective for high performance applications. With Dynamic Provisioning we can eliminate the waste of allocated but unused space from taking up expensive flash capacity. When we combine it with dynamic tiered storage we can efficiently move thin volumes from a wide striped storage pool to a flash pool when flash performance is required. The use of flash drives and wide striping will help to address the increasing random I/O needs of high performance Virtual servers and Hyper visors with their many virtual machines stacked inside them.

There are a lot of other comments which were triggered by Greg’s post. I would be interested in any comments you may have regarding trends in storage for the current year.

Many dot com SSPs went bust because each new customer that signed up required dedicated storage resources to ensure security and quality of service which destroyed the business model based on shared resources. Others had to over provision storage resources in order to meet peak demands while most of the time the storage was sitting idle consuming expensive data center floor space, power and cooling, and cash flow dollars. The dot com storage service providers were ahead of their times, unfornately the technology to support their business model was not available. Many thought that the introduction of Storage Area Networks was the technology solution but they soon found out that SANs provided connectivity but did not solve the problems of shared resources and dynamic provisioning. So what is different today for cloud storage providers?

The new technologies that will help cloud service providers are server and storage virtualization and dynamic provisioning.

Server virtualization will enable the dynamic sharing of server resource by virtual machines in a safe multi tenant environment. Storage virtualization will enable the ability to dynamically add capacity, move applications to the most cost effective tier of storage, and simplify the migration to new technology platforms. In the HDS USP V, partitioning and port priority processing can be used to ensure safe multi-tenancy and QoS for applications. Dynamic provisioning is the virtualization of storage capacity which enables thin provisioning, dynamic provisioning of LUNs, load balancing, and wide striping performance. It also allows over commitment of storage capacity to meet peak requirements.

While these new technologies solve the old problems of shared resources that the SSPs had to face, there are new challenges that have to be solved. One of the new challenges is driven by server virtualization and faster processors and networks. The old service providers used single core blade servers that drove one operating system’s worth of I/O load over 1 GB FC. Today the cloud service providers will be using multi core processors with multiple virtual machines, over 8 GB FC or 10 GB FCoE. This will require storage systems that can scale up to meet the increasing I/O demands of the servers, applications, and networks. The USP V with its 128 processors that are tightly coupled through a global cache will have the power to scale up as well as scale out through virtualization of external storage.

So while the dot com service providers are a memory, I believe the future of cloud services will be viable if we choose the right technologies for shared resources, safe multi-tenancy, flexible configurations, and the ability to scale up and out.

While the economy seems to be getting better, budget planners are still very cautious and so we will continue to see a drive to consolidate to reduce cost and thin down the fat to be more agile. Therefore data center virtualization will be a top priority for 2010.  We have already seen the adoption of server virtualization platforms with more competitive offerings and faster more powerful processors and networks becoming mainstream. The next major step in data center consolidation will be in the consolidation of storage through thin provisioning.

We have  seen capacity virtualization, or thin provisioning, introduced by most storage vendors in 2009. While there was initial concern about over provisioning and confusion about the benefits or drawbacks of chunk or page sizes, users who have tried thin provisioning have seen benefits in increased utilization, ease of provisioning, and wide stripe performance. However, a major inhibitor has been the need to rip and replace existing storage since thin provisioning requires architectural changes to manage the meta data associated with virtual pools of capacity.

However, vendors like Hitachi Data Systems, who can combine thin provisioning with storage virtualization, can provide thin provisioning for existing storage without the need to rip and replace. Hitachi Data Systems can reclaim 40% or more of existing storage capacity on external storage systems, just by attaching them to the USP V, discovering their LUNs and moving them into a Dynamic Provisioning pool which can reside internal to the USP V or on external storage systems.

While thin provisioning has many benefits, the management of smaller chunks or pages of data will place a higher demand on the cache and processing power of the storage systems which may impact performance especially if it is combined with other storage functions like copies, moves, and replication.

On top of the increased workload for thin provisioning, the virtualization of servers will increase I/O processing load dramatically. Instead of one operating system per processor we now may have 5 to 10 operating systems per virtual server platform. Since each Operating systems is firing off I/O’s to what are essentially file shares in a virtual machine file system, the I/O from this VM file system will tend to be very random, which places an even higher workload on the cache and disks of a storage system.  While the wide striping of thin provisioning will help to distribute the I/O across more disk arms, there will be more processing of meta data to support this.

The USP V eliminates most of the overhead of meta data management by using pages instead of chunks and chunklets and managing meta data in a separate cache accessed by separate busses than the data cache.

Unlike other thin provisioning storage products the USP V is an enterprise storage system that can scale up as well as scale out. The USP V can scale up to support the increasing load from a VM file system by adding additional processors through alternate paths which can work on the same image of the file system in the USP V’s large global cache. It can also dynamically add to the global cache and increase the Dynamic Storage pool if more spindles are required.  The USP V can start with 32 processors and scale out to 128 processors. It can also loosely couple to another USP V or to the next generation USP V for non disruptive tech refresh. Capacity can be scaled out to peta bytes by adding additional external storage systems virtualized behind the USP V.

The USP V has the ability to scale up and out to support server virtualization and thin provisioning. With storage virtualization it can enhance existing storage assets with these new services for data center consolidation. It also designed to couple to the next generation USP V without application down time.  This type of flexibility makes the USP V  ideal for support of data center virtualization now and for the future.

I look forward to 2010 and future dialogue with you around the storage issues and thoughts of the day.

Happy New Year!

“V-Max scales out using the Virtual Matrix. V-Max engines are not “loosely” coupled with RapidIO - RapidIO plays the same inter-process(or) communications role as does the Direct Matrix in DMX. The one ASIC in the V-Max manages the interface to the RapidIO fabric, as well as providing numerous data manipulation services to the local nodes.”

“The simplest way to explain it, since you seem to have a better grasp on the DMX architecture is this: V-Max assigns specific tasks to each core in each director (there are 8 cores per node). These “tasks” are analguous to prior Symm FA, DA, RA (etc.) ports. Incoming I/O requests are received by an FA, and queued to the appropriate DA pair. The DA pair could be local (the two nodes in an Engine), or they could in fact be targeted to a pair of DA processes running within a different engine. In this case, the I/O is queued over the RapidIO fabric - the fabric itself carries multiple simultaneous communication sessions, moving commands and data at different priorities.”

“Net-net - very similar to DMX, just all the I/O processes run on cores instead of “slices”, and the Virtual Matrix replaces the Direct Matrix.”

From information I can gather about DMX and VMax, I do not believe they are very similar. The main difference is not about the connections of a Direct Matrix or Virtual Matrix switch. The main difference is that the DMX has a global cache and the VMax has local cache.

Here are schematics of the DMX and of VMax that I have downloaded from Barry’s Blog. 

In the DMX, the Front End Adapters and Back End Device Adapters are separate processors and are tightly coupled through an internal Direct Matrix to a global cache. All the FAs and DAs are working directly with the same cache and any FA can read or write to any DA.

In the VMax the FAs and DAs are bundled with a cache into one multi core processor Although EMC labels this as Global Memory it is really local cache memory. Two of these processors make up one VMax engine. It looks very similar to the Clariion Architecture with two processor complexes with separate local cache and separate FA/DA. Instead of a true global cache that is connected directly to the FAs and DAs through an internal Direct Matrix, the VMax cache consists of local caches that are bundled with FAs and DAs and are connected through an external Rapid IO switch. This type of connection requires a store and forward cache architecture which I would not classify as a global cache.

Reads or writes come in through a Front End port to the local cache in a VMax processor. If the I/O is queued for the Back End in another VMax engine, it must be forwarded across the RapidIO switch to the cache that belongs to the processor that owns the  Back End port. The communication between the local caches requires a store and forward across an external switch. When a read is made to an FE port, the command is stored in the local cache, then forwarded across the external switch to another local cache where the BE port is located. If it is a READ miss, status is passed back over the switch to the FE cache, and the BE proceeds to read data from the  local disk into its local cache, where it is stored and then forwarded to the FE cache. With writes, the commands and data will be stored and forwarded to two separate VMax engines to provide cache write protection. As Barry says, “the I/O is queued over the RapidIO fabric - the fabric itself carries multiple simultaneous communication sessions, moving commands and data at different priorities.” Sounds like a lot of overhead.

The DMX would not have to do this since all the FE and BE processors work with the same cache for commands, meta data, and data. There is no need to store and forward.

The USP V is similar to the DMX in that it is a tightly coupled multi-processor with a global cache. However, the difference is that the USP uses a dynamic cross bar switch between the processors and global cache modules, and command or meta data is kept in a separate control memory  connected directly to the processors to avoid contention between the accesses to meta data and user data. This gives the USP V higher scale up as well as scale out performance and the ability to virtualize externally attached storage from heterogeneous vendors. EMC appears to have copied the switching concept from Hitachi to gain scale out capability but they put it in the wrong place for scale up performance.

If any of you have tested the VMax please let us know your experiences.

I am fairly certain EMC briefed Beth on this announcement and that she had access to their references, so it’s safe to say her information is pretty accurate here are my thoughts on what I read in the PR and from Beth’s article:

Is EMC behind the competition? – Hitachi has had policy based file and LUN level tiering for some time. HDS announced a non disruptive tiering feature called “Dynamic Optimizer” over 10 years ago in the Freedom 7700 product, which later became Cruise Control, then Volume Migrator, then Tiered Storage Manager. EMC is still behind with the inability to extend FAST to external storage systems through storage virtualization and support FAST with thin provisioning. At this time it is not known how FAST v1 will play with other EMC features like TimeFinder, SRDF, etc. FAST v2 with sub LUN level tiering is still in the future and Compellent already offers that today. Whether they will be the first of the enterprise storage array vendors to provide this capability is still an open question until they deliver it. However, being first is not as important as meeting market requirements. An increasing market requirement is performance.

Performance impact – With the trend toward consolidated multi-core processors, stacking of operating systems with VMware, and increasing storage network bandwidth to 8Gbs FC and 10Gbs FCoE, the demand for storage system performance will increase dramatically. Migration of LUNs will impact performance through contention for storage array resources so customers must have visibility into application windows where data migrations can occur. Beth reports that previous customer experience with DMX Symm Optimizer found that the whole frame was locked during a migration. Remember VMax is still a static “Bin File” mapped cache and not a dynamic cache like the USP V. I believe they will need to lock some resources during the migration. Movement of data within a storage frame requires a lot of meta data management. They have to manage the meta data within their data cache over the same internal paths that are used for data access. The VMax and CX4 are single processor controllers that are loosely coupled. They are not multi-processors like the USP V and they don’t have a separate control memory with separate internal connections to the processors for efficient processing of meta data.

Complexity issues – Creation of 256 different tiers according to RAID level, drive speed or drive type, assignment of storage groups to tiering policy, percentage of a storage groups capacity that can reside on any tier, all implies that there is a lot to consider and a heavy amount of EMC services will probably be required to implement this. New utilities are required to help administrators discover available storage tiers and add policies for migrating data and a new “wizard” to asses existing storage efficiencies that can be gained with more tired storage. Sounds like a lot of new things to manage.

Customer fear of automation – Beth also reports that customers at EMC World were wary of automation, fearful that it may cause them to lose control of their data center. When errors occur in an automated process, the errors get propagated automatically. There must be some controls to avoid thrashing. A bigger question may be whether tiering is a task which should be done automatically at all, especially at the LUN level.  Moving or migrating LUNs is a very heavy task and should be done sparingly. Hitachi offers tiering for copies of primary data that do not need to be assigned to the same tier of storage as the primary data. We can assign primary data to an initial tier of storage and if for some reason it needs to be moved, Tiered Storage Manager software can dynamically move it to another tier, but moving the volume up and down tiers at the slightest change in usage will have an impact on system performance and is not best practice.

No thin provisioning – this is lacking in FAST v1. The benefits of dynamic or thin provisioning far out weigh the benefits of LUN tiering and has no impact on performance in the case of Hitachi Dynamic Provisioning. HDP provides dynamic provisioning of LUNs, wide striping performance, thin provisioning economics, thin moves/copies for operational efficiencies, and zero page reclaim for immediate payback. HDP is easy to manage, has better economics, and better performance. Usually once you assign storage to an HDP pool, with automatic wide striping, there will be little need to migrate it for performance reasons, even with SATA disks.

FAST is only available on VMax and Clariion CX4 – why not DMX? You can do FAST within a VMax or within a CX4 but not between VMax and CX4. What about other storage assets? With USP V we can provide HDP and tiering to internal as well as externally attached storage from other vendors. You are not locked in to a single vendor as you are with EMC’s VMax or CX4. Our modular AMS2000 already has the capability to do HDP and tiering within a frame.

Celerra file level FAST – apparently there is a different FAST for NAS. Our HNAS already has the capability to do, policy based, file aware tiering across internal and external, heterogeneous storage, archiving to HCP, and content aware search with Hitachi Data Discovery Suite. Setting policies for file aware tiering is as easy as selecting a menu option.

FAST v2 – FAST v1 sounds like the Virtual LUN feature that was introduced in the Clariion FLARE 16 operating system some time ago. However, there are some new management tools. To add interest and encourage customers to buy VMax, EMC announced a roadmap for FAST v2 which includes sub LUN level migration, de-duplication, spin down, and the possibility of migration between disparate EMC arrays like VMax and CX. This will take a lot more CPU power and cache resources for meta data processing and will place an even heavier load on the two controller architectures of the VMax and Clariion. This will also require another learning curve for customers. By the time they figure out how to set tiers and policies for LUN level tiering, they will have to learn how to do sub LUN level tiering and policy management. Since the pools will be configured for LUN tiering, will the pools have to be reconfigured for sub LUN tiering and will that require BIN File changes on the VMax?

Agility – Implementing FAST on modular architectures like VMax and CX4 limits the ability to meet changing storage requirements. If you exceed the ports, cache, or storage capacity of a VMax engine or CX, you have to add another VMax Engine or CX frames, you cannot incrementally add ports, cache, or capacity as you can to a USP V. Without Dynamic Provisioning you can not automatically load balance by striping across the width of a storage pool and rebalance the pool if more capacity is added. You would have to take a hit on resources in order to move LUNs from one tier to LUNs on another tier. Without storage virtualization, you cannot extend this to your existing assets. You would need to rip and replace your assets with a VMax or CX4.

Summary – This announcement of FAST sounds like a re-announcement of Virtual LUNs, which has been available on the FLARE operating systems since release 16. There will be a lot of things to learn about performance and management and integration with other key features like thin provisioning and SRDF, before this can be cut into production. This is a catch up announcement and the roadmap for FAST v2 only raises more question about how FAST will perform at the sub LUN level. The impact of FAST on storage subsystem performance will be the key to its acceptance.

I do not have much information on FAST, or VMax for that matter, so much of my opinions are speculation. If any of you have experience with FAST or VMax and can share your experiences or opinions please add a comment to this post. Tells us what you like about it, what works, and what doesn’t.