Here is what it says:

Scale vertically (scale up)

To scale vertically (or scale up) means to add resources to a single node in a system, typically involving the addition of CPUs or memory to a single computer. Such vertical scaling of existing systems also enables them to leverage virtualization technology more effectively, as it provides more resources for the hosted set of Operating Systems and Application modules to share.”

Scale horizontally (scale out)
To scale horizontally (or scale out) means to add more nodes to a system, such as adding a new computer to a distributed software application. An example might be scaling out from one web server system to three.”

It then goes on to describe the tradeoffs as follows:

Tradeoffs
There are tradeoffs between the two models. Larger numbers of computers means increased management complexity, as well as a more complex programming model and issues such as throughput and latency between nodes; also, some applications do not lend themselves to a distributed computing model. In the past, the price differential between the two models has favored “scale out” computing for those applications that fit its paradigm, but recent advances in virtualization technology have blurred that advantage, since deploying a new virtual system over a hypervisor (where possible) is almost always less expensive than actually buying and installing a real one.

In the server world the direction is clearly towards scale up with future Intel Nehalem processors and virtual servers/hypervisors running hundreds of instances on a single node. This will put an increasing load on the network and network vendors like CISCO and Brocade are also scaling up to 8Gps FC and 10Gps Ethernet. It stands to reason that the storage systems will also need to scale up to support the increasing workloads of scale up servers and networks.

Hitachi Data Systems’ USP V is a storage system that can scale up to 128 processors which are tightly coupled around a large 512 GB data cache and 28 GB of separate control memory. It can support 224 physical FC ports, each of which can support 1024 virtual ports. Through virtualization of external storage it can scale to 247 PB of internal and external storage and support in-system copies, dynamic tiering, distance replication, and dynamic thin provisioning. It can support over 4 million aggregate IOPs.

The rest of the storage market appears to be going for a scale out approach, with a clustering of modular, two controller, storage systems that are limited in connectivity, cache and capacity.

For example, EMC has taken the scale out approach with their VMax storage. While they can loosely cluster 16 VMax engines together, each VMax engine has only two processors (directors) each with 64 GB of cache and 8 FC ports. Currently the maximum raw capacity with 1TB drives is 360 TB per engine. Since EMC does not provide any performance numbers, it is difficult to make comparisons on performance. That is the maximum scale up capability of a VMax cluster.

As indicated in the preceding Wikipedia comment on the tradesoffs between scale up and scale out, the scale out approach to storage may be cheaper for applications that fit that paradigm, but with the virtualization of servers and the consolidation of networks a scale up storage system that can virtualize and aggregate storage services will almost always be less expensive that a cluster of modular, dual processor storage systems.

In the recent EMC, CISCO, VMware coalition announcement they announced that they will have proprietary bundles for 300 to 800, 800 to 3000, and 3000 to 6000 virtual machines. While CISCO and VMware may be able to scale up to those numbers of virtual machines, it will be a challenge to see how VMax meets the I/O demands of these virtual machines with a scale out design.

According to Sharwood’s article, the presentation was dated 2008 and published October 28, 2009. It was a marketing presentation that gave guidance on selling NetApp’s V-Series storage virtualization product as well as an assessment of their competition.

From the assessment of the slides, NetApp’s strongest competitor for the V-Series product was HDS and the reason given was price. That may be surprising since a V Series can start at $30k while a USP V or VM starts at over $100k.

So how can a USP V/VM be lower in price than V Series?

The difference lies in the architecture of the USP V and its ability to scale up to meet the increasing workloads of server and storage consolidation.

One of the main reasons for storage virtualization is server and storage consolidation. Consolidation requires a storage system that can scale up and that requires a tightly coupled multiprocessor virtualization engine.

The V Series is essentially a gfiler, a NetApp head that sits in front of other storage systems. It is a single processor that does everything including the mapping of block I/O to their WAFL file system onto external storage. Any additional functions like snap copies and dedupe takes cycles from this processor and more memory and CPU power is required to run the ONTAP operating system.

The USP V starts with 32 processors which are tightly coupled through a single 64 GB global cache with write protection. It is a multiprocessor, where some processors handle the front end ports, others the backend ports, and still others handle replication. An internal switch can switch path connections to the data cache providing high availability and performance. A separate control store handles the meta data mapping for dynamic tiering and dynamic provisioning without impacting data cache performance.

So, in order to compete with the USP V for any significant workload with equivalent performance NetApp will have to sell many more V Series Filers. Each additional V Series increases management cost, software licensing and maintenance, additional network ports and network management, power/cooling/floorspace.

This is a good reminder that companies who require scalability and performance should take a hard look at their needs before buying. As we’ve seen here, the list price of a system doesn’t always mean final price in the end.

Since the reason for server virtualization is to consolidate servers to save costs,  they did not want to run this on an expensive monlithic DMX. The only solution is to run this workload on a USP V with low cost modular storage virtualized behind it.  The USP V has the multiprocessing capability that can scale up to support this load and scale out with lower cost external storage capacity. The USP V can also map the external storage into a Dynamic Provisioning pool, where the benfits of thin provisioning, wide stripe performance, and dynamic LUN provisioning can further reduce operational costs. 

Loading up on virtual servers makes sense when you have the right storage to go with it. Modular storage systems, whether they are standalone or loosely coupled for scale out, can not support large virtual server workloads like this.  This takes monolicthic storage systems that can scale up for performance and scale out with external storage for lower TCO.

The key feature for this extension to Switch IT On is the addition of the USP VM, which is our modular, rack mount version of the USP V storage virtualization controller. If you have existing FC storage from most current storage vendors, you can attach it to an existing or new USP VM with a free frame-based BOS V license and enhance these storage assets with enterprise functions like Dynamic (Thin) Provisioning, Dynamic Tiered Storage, and In-system Replication – free of licensing charges. The Dynamic Provisioning license is free for the first 10 TB; the other licenses for BOS V, Tiered Storage Manager, and In-System Replication are free for any amount of storage capacity.

One of the great things about Switch IT On II is that the program is extended to existing newly attached HDS AMS storage as well as existing third party storage.

A new option was added for the recently announced Hitachi NAS midrange platform 3080/3090. This option offers free NAS Data Migrator and Cross Volume Link software with the purchase of a Hitachi NAS 3080/3090. These software products will enable customers to manage their unstructured data automatically throughout the data’s life cycle with native HSM function and file level intelligent tiering. Policies could be set in Hitachi NAS to move files across tiers of storage based on time or events such as age or time last used.

This program is provided to highlight our unique capabilities in storage and file virtualization with the USP V, USP VM, and the Hitachi NAS 3080/3090 products. These offerings will enable customers to get additional value from their storage assets with fully paid, transferable licenses. Storage virtualization and dynamic provisioning alone could reclaim 50% or more of your over allocated storage silos.

Having been in the storage industry for some time now, I have the benefit of historical perspective. I started out when mainframe storage was the only external storage available. Mainframes were the original virtual server, built for running multiple partitions of concurrent applications which drove tremendous I/O loads across special processors called channels.  In order to support this type of workload, storage vendors had to build monolithic storage systems, that had multiple processors on the front ports to match the I/O load of the channels, a large global cache that could serve a consistent cached data image to multiple, load balancing, storage port processors, back end processors that could write the data to backend storage, and still other processors that could move data for business continuity. EMC developed the Symmetrix; IBM developed the Shark; and Hitachi developed the Freedom 7700 built around these features to address the I/O requirements of mainframe virtual servers. With a global cache, monolithic storage systems can scale up and out by adding front end processors, back end processors, and cache modules.

Lower Cost Modular Storage Systems for Non Virtualized Workstations

Shortly after that, work stations began to externalize their storage through the advent of the SCSI interface. Since workstations served a single operating system and also drove the I/O through a Host Bus Adapter, the I/O load was very low. As a result storage systems for workstations did not need the high end functions and costs of a monolithic storage system. All they needed was a single storage processor that could handle all the I/O workload from the front end port, to the cache, to the backend ports. For protection against data loss a second processor was added in standby mode. The write data in the primary processor’s cache is replicated to the secondary processor’s cache for write data protection. It must be noted that a two processor controller system is not a high availability system. Even if the data is protected when one processor fails, good practice dictates that you stop and fix the failed processors, before the secondary processors fails. This was not a concern since maintenance windows were usually available for applications running on a non virtualized server. Since the two storage processors (storage controllers) could be mounted in a drawer in a standard 19 inch rack and disk drawers could be added into the same rack and daisy chained to the controller drawer, these storage systems became known as modular storage systems. Modular storage systems with two storage controllers are limited in their ability to scale up or out.

An Approach to scale Modular Storage Systems

Because of their lower cost and simplicity of configuration, modular storage systems have become very popular, and it is predicted by many analyst that 80% or more of storage capacity will be on modular storage and the demise of the monolithic storage is imminent. However, modular storage systems lack scalability which is a major disadvantage in a world exploding with data. In order to overcome this issue we are starting to see a movement to scale out these modular systems by clustering them around Rapid I/O, Ethernet, or other types of switch technology. Scale out works as long as the workload also scales out. It does not work if the workload requires scale up.

Virtual Servers Are Driving the Need for Scale up Storage

While the demise of the mainframe is still debatable, we are seeing the rise of more virtual servers like VMware and HyperV. The future of servers is clearly virtualization and the requirements they place on storage systems is similar to that of mainframe servers. Now there are 5 or more applications running on the same server platform and I/O load has increased in proportion. Also when storage is not available more applications are affected. This type of workload requires monolithic storage that can scale up as well as out and provide the performance, availability, and scalability required for virtual server environments. Simply put a cluster of modular storage systems won’t be able to hack it. If you are looking at heavy/dense Hypervisor/Virtual Server workloads, you would be better off with a monolithic DMX, DS8000, or USP V than a scale out VMAX or XIV. EMC and IBM both understand this and are hanging on to their aging monolithic storage systems in case the server virtualization market really takes off and the VMAX and XIV can’t cope with the workload demands. . While the initial acquisition costs of monolithic storage are perceived to be higher, the reality is that the operational costs of dealing with a cluster of loosely coupled modular storage controllers, leads to a higher TCO. The reason is that you constantly have to fire fight controller availability issues and deal with the sprawl problem inherent with modular storage

A Scale out and Scale up Storage Solution for Virtual Servers

Today the best solution would be a monolithic USP V with low cost modular storage virtualized behind it. Virtual server workloads also tend to be more random than non virtualized workloads so flash drives in the front end USP V improves random read performance and is another example of how this combination can scale up. Here you have the best of both worlds, a monolithic front end that can meet the increasing performance and availability demands of virtual server workloads and low cost back end capacity. Instead of simply scaling out by attaching more and more VMAX nodes to a VMAX switch, you can scale out by attaching modular storage behind a USP V and also scale up by leveraging the monolithic capability of the USP V. My fellow HDS blogger, Michael Hay calls this “Cartesian Scaling.”

From my perspective, we have been providing customers cloud enabling technologies since we introduced the virtualization capabilities of the USP. There are many SaaS providers and Network Computing companies like Telstra, Australia’s leading telecommunications and information services company, which is hosting and delivering their services through the cloud using Hitachi Data Systems storage virtualization services today.

I am currently in the Nordics where many of the large service providers like EDB in Sweden and Norway are using Hitachi Storage to provide the performance and agility that is required to outsource and host storage services for companies that are striving to reduce costs during  economic down turn.

The same capabilities that are needed for service providers are needed for cloud computing services and other services that may be delivered over a public network. Agility requires storage and file virtualization for data mobility across tiers of storage, Dynamic Provisioning for quick provisioning of changing server requirements, and a content platform that can support multiple tenants and automate the life cycle management of content in a compliance environment. In addition it requires an integrated suite of management and reporting tools as in the case of EDB.

Much of the data that will reside in the cloud will be content data and as part of this cloud announcement, we are announcing a new version of the Hitachi Content Archive Platform and renaming it the Hitachi Content Platform. While HCAP has proven to be ideal for large archive projects like the George W. Bush presidential archives, it has proven to be much more than an archive where you park data for long term retention. Companies like Payformance Corporation, a medical billing company,  have led the way in using HCAP for their production data. They used to gather billing information from many sources, normalize them and store them in a data base so that it could be searched. This data base had to be backed up on a regular basis, which was getting more costly as the volumes increased. Today they are ingesting the billing artifacts directly into HCAP where it can be indexed and searched in a secure compliant repository. Since the data is static, they replicate it to another HCAP in a remote site and have eliminated the need to do backup.  They now manage and replicate over 30 million artifacts in near real time between the two sites, avoiding lengthy backup, tape media, and labor intensive efforts while making data readily available in various formats to their customers. This is not an archive; this is a content platform for production data.

For more insight on today’s announcement, please read my fellow HDS bloggers, Michael Hay and Miki Sandorfi, who have also provided their perspectives on today’s announcement.

Unfortunately this post was interpreted as supporting Chuck Hollis’ view on dedupe of primary data.

There are many ways to optimize capacity and reduce operational costs for primary data, including thin provisioning and archive. The opportunities for dedupe of primary data, as Jered acknowledges in his blog, is harder to find. One other consideration about primary data is that it may be copied many times over for additional offline processing, like data mining, extract/translate/load, development test, etc. Some primary data volumes and may be copied and moved over 20 times. You would probably have to redupe before you make those copies, and the copies may be moved to storage that does not have the dedupe capability. A lof of data older than 60 days may never be referenced again. If you archive out the stale data and thin provision the source, these efficiencies carry forward with the copies and moves.  In the case of files, when they become inactive, stub the file out of the file share to an active archive like HCAP, and you are only backing up the stub with the file share. 

So my suggestion was that archive of stale data at the primary source volume or file will reduce the working set of active data and reduce the work and capacity requirements for everything that follows including dedupe.

I agree with Chuck and think his post was very well written. I would like to offer some additional views on dedupe.

Dedupe is most effective for backup where there is a lot of repetitive bit strings. But dedupe for backup is addressing the symptom and not the cause. The cause is all the stale data that we backup and dedupe over and over again. Most data that is over 60 days old will rarely be referenced again. This stale data also does not need to be restored as long as it is stubbed out to a content repository like HCAP which is replicated for data recovery.

Use an active archive solution like HCAP to reduce the working set and eliminate stale data from your backups, dedupe, and restores. This not only reduces storage capacity requirements but also reduces operational costs.

While some people use dedupe for archiving, if that archive is for compliance, it may be better to do single instance store to avoid the discussion as to whether or not dedupe and redupe constitutes a modification or the probability of a hash collision which could lose data. The HDS HCAP platform does single instance store and does not do dedupe for content archive. Hashing is done for immutability to ensure that the content has not changed between ingestion and retrieval.

Chuck alludes to the concept of tiering as a work around for I/O density where primary data can be moved to high performance tiers when they need performance. Today that requires the movement of volumes or files. Moving volumes up and down tiers of storage in response to performance requirements is practical only if the volumes are virtualized so that data movement does not disrupt the application. Moving volumes is a heavy task so it is best done sparingly where the requirements for tiering are infrequent or the periods of high performance are predictable and the data can be staged ahead of time. On the other hand moving files is more practical with Hitachi HNAS which does file virtualization and can move files non-disruptively between tiers of storage and also stub out a file to HCAP based on policies. With the Hitachi Data Discovery Suite, HDDS, file can be indexed and moved between HNAS tiers and HCAP based on content awareness.

Dynamic provisioning also helps to reduce the workload of tiering and dedupe by eliminating the overhead of “zero” pages.

So I agree with Chuck. “Dedupe is a useful tool for taming information (data) growth, but it is not a panacea”. I would also add that dedupe is great at addressing the symptom of bloated storage growth, but other solutions like Dynamic Provisioning, and File and Content services are more effective in addressing the cause which is stale data and over provisioning.

If you remember about 5 years ago, ILM, Information Life Cycle management was all the rage.  ILM was the  ” policies, processes, practices, and tools used to align the business value of information with the most appropriate and cost effective IT infrastructure from the time information is conceived through its final disposition. “ 

At that time SANs had been well adopted and lower cost storage like SATA was becoming available.  Storage vendors were rushing to define their solutions for ILM. Some vendors were extolling the benefits of moving data up and down tiers of storage based on changing business requirements. While ILM was a good idea, the technology was not there to implement this idea without a lot of extra work.

The tiers of storage were static. While there was cost differentiation between types of storage and there was SAN connectivity, there was no dynamic capability to move data between tiers. Even if the tiers of storage resided in the same storage frames, you had to move the data between tiers with software, which meant disruption to the application.  Non-disruptive movement of data between tiers of storage requires storage virtualization. Hitachi with the USP V and yes, IBM SVC , can do non disruptive movement of data, in volumes, between tiers of storage.

However, volume movement of data can mean a lot of heavy lifting. Volumes are getting larger and moving a TB volume across tiers of storage is not something you want to do on a frequent basis. As a result you may assign a volume to an intermediate tier and promote it only if it needs more performance or demote it if it doesn’t. The more likely use of dynamic tiered storage volumes is to create copies to lower cost tiers for offline processing like data mining, or development test.

Tiering with files is easier to do. Today it can be combined with block tiers and Content Archives and comes closer to the vision of ILM. One can define a file system across different tiers of storage and Hitachi’s HNAS can move a file in a file share across the tiers using policies based on POSIX information. For instance if the file is an MP3 file  HNAS could  move it to the lowest cost storage or delete it.

It can also be stubbed out of the file share and pushed to an HCAP content platform where it can be injested, indexed and stored for long term retention. HNAS could set a policy to move all PDFs older than 60 days and containing the word “budget” to HCAP and let HCAP manage the lifecycle of this file.  If HNAS needs to retrieve it, it just pulls it up via the stub. When the file share is backed up, no resources are spent on the file that was stubbed to HCAP.

Dedupe is a great tool for reducing the backup load, but dedupe is really addressing the symptom and not the cause.   The cause is stale data that we backup over and over again. If we stub the stale data out to HCAP, we address the cause, which is stale data.  As long as we maintain two HCAP copies of data, there is no need to back up the data that resides in HCAP.

If you want to hear more, please tune into the webcast on Wednesday, September 30, from 9am to 10 am.  The Economic Benefits of Intelligent File Tiering    

I recently had the opportunity to visit an SVC customer and found out that they have been reading our blogs and were very familiar with the discussion between Barry and myself. While they were very happy with the SVC’s ability to migrate data off of an EMC frame onto an IBM frame, they ran into difficulty when they also tried to migrate the SAN from Brocade switches to CISCO switches. That’s when it became apparent to them that IBM was really virtualizing the SAN and not the Storage.

As you may know the SVC sits in the middle of two SAN’s. One SAN presents virtual disks to the applications on the front end and another SAN presents managed disk to the storage arrays on the backend. The SAN’s have to be carefully zoned so that they do not overlap. My memory may not be correct but I think Barry also mentioned the need for another SAN just for the ports on the SVC clusters. This zoning of two or three SAN’s and the scrambling of LUNs between managed disks and virtual disk is what was causing the difficulty in migrating the SAN Switches. So whatever benefit they gained from migrating from EMC to IBM storage they paid for in the SAN migrations. Since the USP V does storage virtualization, it uses the LUNs in the external storage as though they were USP V LUNs, providing all the services of the USP V to storage systems that may not have any of this capability natively. It does not need to add additional SANs or scramble the LUNs for remapping. SAN switch migration for the USP V would not be a problem.

I asked why they were converting from Brocade to CISCO, and their answer was that they were planning ahead for FCoE. I pointed out that the SVC may work well in a FC SAN, but may have to do a lot more work to guarantee delivery of packets in a lossy network like Ethernet. The SVC will have to be reworked in order to work in a non FC environment, where packets may be dropped when the network gets congested.   Since the USP V does its virtualization in the storage controller, we would be able to convert the front end ports to FCoE ports and not do a major revision of the storage virtualization functions.

So as I said in my first post on this subject. The difference between the SVC and USP V virtualization is the difference between SAN virtualization and storage virtualization