United States
Site Map Contacts Hitachi Global Community
Hu's Blog - Data Storage and Virtualization Thought Leader Hitachi - Inspire the Next

Hu Yoshida's Blog - Vice President | Chief Technology Officer

Home > Corporate > HDS Blogs > HDS Bloggers > Hu's Blog
Products, Solutions and more

Hu's Blog

Cartesian Scaling

by Hu Yoshida on Feb 15, 2010

My fellow HDS bloggers Ken Wood and Michael Hay have been using the term Cartesian scaling to describe what I call Scale up and Scale out. Cartesian scaling is the ability to scale in two directions, up and out. I have resisted using this term since I thought it sounded too technical to describe what I thought was a simple concept.

(The term Cartesian comes from the French philosopher Rene Descartes who wrote a paper Discourse on the Method, where he introduces a way to order objects on paper using two intersecting axes as a measuring guide. In this way he was able to link geometry and algebra.)

When I talk to customers about the scale up and scale out advantages of the USP V versus competitive products that only scale out, listeners often see this as an either or. Either you scale up or you scale out. They would recognize that the USP V with its global cache and switch architecture could scale up but would overlook the fact that it can also scale out.

The other day I was talking with Russ Fellows and John Webster of the Evaluator Group about this concept and they thought that using one word like Cartesian was less likely to cause the either/or situation that scale up and scale out seemed to evoke. They also brought up the idea of three dimensional Cartesian scaling.

After thinking about this it occurred to me that there is a third dimension. cartesian-scale6
That dimension is external storage virtualization. There are other products
ike the EMC DMX that can scale up and scale out with its Direct Matrix
and global cache, but there is no other product that can also scale through
external storage virtualization like the USP V. As we add external storage
through virtualization, we can scale up the  capabilities of the external
storage with a large global cache, and additional port processors. We
can also add the external storage to a Dynamic (Thin) Provisioned pool
and scale it out to a number of different servers.

With this new dimension, scale up and scale out is no longer adequate to
describe the scaling attributes of the USP V. So from here on out I will be
talking about Cartesian scaling.

Related Posts Plugin for WordPress, Blogger...

Comments (8 )

Michael Hay on 15 Feb 2010 at 2:33 pm

Hu, this is a good point and I’m glad that it encapsulates your logical argument to users, customers, press and analysts on scaling in the datacenter. I would also like to add that with our external storage we are actually taking advantage of distributed RAID protection. Namely the underlying storage system has its own RAID engine running and protecting the data. This continues without having to force the USP-V into doing the RAID protection for the external device. So I do agree that we are implementing Cartesian scaling today in the USP-V and we are further following a trend in the industry that started in the Supercomputing world with the NEC Earth Simulator in 2002. (Note Supercomputing innovations typically find their way into traditional business IT 5-10 years from their initial debut in the Supercomputing space. That makes the NEC Earth Simulator of particular interest because it has been 8 years since it was available, implying that we should be seeing it impacting business IT already.)

Art on 15 Feb 2010 at 2:39 pm

As I understand it, and was explained to me during various executive presentations of USPV and USPVM, the ability to scale “external” is mostly geared towards migration and tier2 storage practices. Has this changed? as I recall there were issues and even an advisory from HP about utilizing the virtualization {external scaling) of the USPVM when HP ran into issues with Tier1 offerings behind the USPVM engine with Oracle applications.

Thanks
Art

Hubert Yoshida on 15 Feb 2010 at 4:35 pm

It depends on what you consider as “Tier 1″. If you have been using a modular two controller storage system as “Tier 1″, in most cases you would see an improvement in “Tier 1″ performance when connected to the USP V or USP VM due to the large global cache and the ability to load balance across the port processors in the USP V/VM. If you are using a global cache storage system for Tier 1 performance then you would not see much difference in performance, unless you also used some of the new features in the USP V/VM like Dynamic Provsioning which provides wide striping performance.

The USP VM is a smaller 19 inch rack mount version of the USP V with about 1/4 the cache and port processors. So in some intense Tier 1 workload environments,the performance is not as good as compared to native Tier 1 systems or Tier 1 systems external to the USP V. In this case the tier 1 applications should be run internally on the USP VM and the external storage used for lower tier use.

One of the most common reasons for an application to be classified as a Tier 1 application is the requirement for distance replication for DR. The USP V or VM can offload that workload so that the Tier 1 application can be run on lower cost external storage without sacrificing the protection of distance replication.

Vinod Subramaniam on 20 Feb 2010 at 12:21 am

Hu

I tend to look at this entire scalability issue from a different perspective.
Storage vendors have to classify customers as Capacity Hungry or IO Hungry.
Once this is done the foundation is laid for choosing a scalability model.

For a capacity hungry customer e.g 500TB and around 20000 IOPS it may not make sense to pick a USPV and the scale up model. It may make more sense to pick a USPVM with AMS2500′s behind it and the scale out model.

For a IO hungry customer e.g 100TB and 200000 IOPS it will make sense to pick a USPV and the scale up model.

The Storage Industry’s mantra of every 1TB added requires 1GB of cache needs to revisited.
A capacity hungry customer may need 1GB of cache for every 10TB added.
A IO hungry customer may need 2GB of cache for every TB added.

Array sizing and capacity planning ( TB, Processors, Cache ) is mostly black magic at best.

– Vinod

Hu Yoshida on 22 Feb 2010 at 2:10 pm

Vinod, thanks for your insight. I will make additional comments in my next post.

[...] Vinod Subramaniam, the founder and CEO of Clearthought Inc.  provided the following comment on my post on Cartesian scaling. [...]

[...] posted a recent blog on Cartesian methods to describe scale-up, scale-out AND the virtualization dimension or [...]

[...] February, I published a blog post on Cartesian scaling, or the ability to scale in multiple [...]

Hu Yoshida - Storage Virtualization Thought LeaderMust-read IT Blog

Hu Yoshida
Vice President and Chief Technology Officer

Connect with Us

     

Switch to our mobile site