Such is the logic of one of our competitors who claims that “they have 4 Gb throughout their array, and Pillar doesn’t”. Wow! Could I be your best friend? Is there any chance that if I studied under you for a few years I could amass that keen insight? The architects of our Axiom never thought of that, it is just too esoteric. If they could have only anticipated the need to have 80 jagabytes per second everywhere, they could have eliminated all bottlenecks? If only I could have drawn that pirate, I too could have been accepted into your college. (Sorry, that was mean, but gawd).

The line of reasoning leads to six-lane driveways and trees with trunks and branches that are all the same diameter. It’s stupid. I guess the reason why I get so bent out of shape about it is because it is not a service to customers to tell them something like that. Tell the truth, if you know it. What limits one architecture is not what limits another – for some it is memory bandwidth, and for others the number of RAID controllers or a pitiful amount of write cache. But don’t make up some dumb thing like “we have 4 Gb everywhere” implying that it makes you better.

Some architectures would benefit from 4, 8 or higher Gb-per-second connections to their disk. Why? Because they do all operations (RAID rebuilds and the sort) over their back-end fabric connections, like this particular competitor does. How many disks share the fabric? The back end architecture has more than a lot to do with the traffic on the interconnect – and some older architectures need lots more bandwidth than Pillar’s Axiom to accomplish the same thing.

To wit, RAID calculations, drive sparing, and rebuilds are not accomplished using the Axiom’s Fibre channel fabric connecting the Slammers to its Bricks. These drive-intensive, bandwidth-hogging, and latency-provoking operations are contained within the Brick for SATA drives, and 2 Bricks for FC drives. This great topology is what yields Pillar’s industry-leading rebuild, performance under fault, and general performance specs. This is real.

It turns out that some topologies also employ fewer, higher performance channels while others employ more numerous, lower performance channels. The issue is the aggregate bandwidth of the fabric, not bandwidth of any individual connection. The term fabric here is enlightening – you don’t tell someone that the thread size of your rope is bigger than someone else’s, therefore your rope is stronger….lest they ask, how many threads in each rope?

So while some people might find appeal to the symmetry of six lanes everywhere, or trees whose branches and trunk are all the same diameter, it is too simple-minded an assertion from which to draw conclusions.

I will confess that my driveway is wide enough to weave a bit to avoid inappropriate obstacles, but my wife still manages to park her car smack dab in the middle of everything for “just a second”.

When people pile lots of Applications on a Slammer – it takes horsepower to virtualize a large storage pool. The Axiom 600 is about twice as fast as the Axiom 500, so for bigger installations our Customers can apply the AX600 to their advantage. The AX600 even improves CIFS and NFS performance on smaller NAS applications as well.

Axiom was designed to work better with larger workloads, hence our customers can drive up utilization and pool efficiency with many (especially disparate) applications connected to it. Thus, we built the Axiom 600 to extend the number of Applications, and spindles that can be supported before you have to add another Slammer (you can add 4 Slammers of any type or model to a storage pool). Of course our Axiom 500 customers can upgrade (about 12 have so far) to the Axiom 600 with their data in place.

Mike Vizard, SVP and Editorial Director for Ziff Davis Media wrote the following blog today in response to our announcement.

The Storage Virtualization Conundrum

The problem that most people are trying to solve when they start to dabble with storage virtualization is basically utilization. IT managers realize that most of their storage assets are way under utilized in terms of capacity, so they naturally want to look at ways of creating pools of storage across multiple devices that can be easily shared by any number of applications and servers.

To accomplish that, IT organizations have typically had to either upgrade to new storage hardware that supports the ability to pool storage or look for a software-based approach that would allow them to create virtual pools of storage from arrays supplied by different vendors. In either event, there are tradeoffs to be made. The upgrade to new storage virtualization is expensive and the systems themselves can be difficult to manage in terms of allocating pools of storage resources across application sets that can change dynamically. It takes a lot of finesse and skill to make that scale across the entire enterprise. Furthermore, if they take a software-based approach to storage virtualization, they basically wind up turning off a lot of the value-added capabilities of their storage hardware as the intelligence for managing the storage infrastructure moves from being embedded in the hardware into what amounts to a generic storage application.

Against that backdrop the folks at Pillar Data Systems have decided to issue an interesting challenge as part of the release of their new Axiom 600MC storage controller. The company is guaranteeing customers that they will see 80 percent disk utilization, which they say is the highest in the industry and about twice as much utilization the average customer sees from any other storage solution.

The reason Pillar Data Systems can make this claim is because of their approach to policy-based storage management. By using a set of pull-down menus to essentially profile the storage requirements of each application, the Axiom 600MC makes sure that applications with similar performance requirements don't sit on the same array. This means that customers should only see a very limited amount of storage bottlenecks because the applications accessing any given disk array at the same time will have substantially different I/O performance characteristics. Essentially, this means that Pillar Data Systems is managing the process of intelligently distributing where the data resides across the arrays to both maximize utilization and reduce bottlenecks.

This really opens up the whole question of the value of storage virtualization given the fact that at least one vendor is now guaranteeing utilization rates of 80 percent. Essentially, IT organizations now need to ask themselves if they really need to go through the pain of creating and managing virtual pools of storage when they now have a more efficient way of basically throwing more hardware at the storage growth problem.

Time will tell if the whole issue of storage virtualization is going to be carried along by the rising momentum of server virtualization. There's certainly a lot of powerful marketing behind the storage virtualization concept. But the first question that any IT organization should really ask before they follow everybody down the virtualization path is exactly what problem are they trying to solve? And when they stop to think about that, they may just want to pause long enough to consider all the possibilities.

Mike Vizard clearly gets it. VMWare/Server Virtualization is about increasing server utilization to save costs in the evolving, more agile datacenter. Axiom is about Storage utilization to the same end – through an intelligent operating system that embeds QoS and Application-Awareness in the entire platform.

Oh, and the Axiom 600MC is a Mission Critical 5-9’s capable platform for very high-end Tier 1 applications. Guaranteed.

What anyone wants out of an HDD is access density; IOPS/GB, and a High GB/$ (more normally specified as low $/GB, but I inverted this to make a point on the following graph).

Unfortunately we can see from this that as GB/$ has gone up sharply, access density has dropped precipitously. What is access density? Access density translates to the number of actuators chasing data. Thus with the relentless pursuit of more GB per disk drive, access density has gone in the tank.

We all know that the low capacity models of server drives last a lot longer than a mere $/GB consideration can explain, and the reason is that the more capacity you have under an actuator, the lower the performance of a subsystem comprised of these sorts of disks.

So 24 spindle “shelves”, or in Pillar’s parlance - Bricks, have higher access density than the same capacity, low RPM larger platter incarnations. Hence, better performance.

There are a few interesting and very enlightening points you can make about this:

1. Access density is always at odds with cost for HDD-based subsystems of a given RPM.

2. Access density always gets better with smaller platter sizes for an equal number of platters.

3. Smaller form factor drives of the high RPM variety don’t yield as big an improvement as you might think, because 95mm (3.5” form factor) 15K RPM drives already use smaller platters – closer to the 2.5” form factor that the SFF HDD uses anyway

4. What Small Form Factor Drives give you is the ability to package them in a serviceable enclosure that puts more actuators per TB in the familiar storage tray! Serviceability is key for small, medium, and large Enterprise.

5. There has always been an option of stacking drives in some high density fashion to optimize actuators per unit volume, but Serviceability is just about always compromised – hence it is not a common practice.

OK good, now the question is… what else can we do to get around access density? Well, with legacy architectures the answer is cache (don’t use the disk if we can avoid it). We can pay more and use smaller disks – oh, the wonderful days of 9GB disk drives.

Or, we could take a large capacity disk with great $/GB, and short-stroke the disk. As an example, let’s say we use 10% of the drive’s capacity. The access density will go up by about 20X!! (~2X from access time reduction, 10X from the fact that the actuator is chasing 10% of the capacity). Wow!. And to think we made that HUGE improvement by only increasing the $/GB by 10X. Oops.

Well, here is what the Axiom QoS does for you. It allows you to short stroke the drive, and get a HUGE access density improvement. But instead of throwing away the other 90% of the capacity, it allows you to sneak in and access that part of the disk in a way that only causes the access density of the high performance capacity (10% share) to drop by say, 10%, from 10X better to only 9X better. WOW! You get the whole drive space back, but have a portion of it that behaves like it has 9X the access density!!

You see, the truth is that stove-piped storage doesn’t get you anything if you can buy a single array that can mitigate contention while increasing access density.

If you have a long memory and been around awhile like me, you can actually recall the days when this meant mainframe and minicomputers (and 8 track tape!). Tiering was by platform, and they were all very expensive relative to today.

Most of our competitors tier by platform, although it is pretty much all open, networked modular arrays. Few people are building closed interface monolithic storage anymore, unless they have a cash cow to milk.(DMoooooX)

So to some, the modern idea of Tiering is allowing different types of disk on the same platform and allowing the storage for less critical applications to be SATA on the same platform that FC disk resides. You can see a lot of confusion in chat rooms and blog posts around this. Tiering on an array – well just about everyone has this don’t they? Sure, if you define it as having SATA and FC disk on the same array. We have finally reached the point where people at companies like NetApps (I know, but I like saying it that way since they are so officially uptight about their damn name) have stopped saying SATA will never make it into the enterprise. Whoopty do!

So to me, Tiering on disk goes much further. For those of you who think I am going to say down to the location on the platter, you’re wrong. Tiering on disk to me means that you don’t have to think about what platter, and define LUNs or Filesystems to reside certain types of disk. Tiering on the array means you have a storage pool, the array picks the type of disk you need out of the pool based on your application requirements. It also means that the system will move or migrate LUNs and File systems based on changing requirements. For those of you who think this is standard, that QoS, Application-Aware, and auto-migration of data from FC to SATA are standard, you need to look again. They are far from standard; in fact they are basically not there unless you buy a Pillar Axiom.

Tiering on disk means you don’t have to buy 2, 3, 4 different platforms to meet disparate needs in your IT shop; you buy one platform that meets those needs out of a disk storage pool according to the application requirements you specify when you set it up. The only thing you need to do is pick some disk resources that encompass the needs of your applications to put into the pool, like SATA 1TB disk, FC 300GB 15K RPM disk to span a wide range of high capacity and high performance for QoS to work with for all your applications.

Why? Efficiency. Utilization is driven up with proper application of a storage pool in your data center. You can use both the capacity and the IOPs of the spindles you own using Axiom instead of one or the other.

While I think this is incorrect, I did point out that this happened once before and there are reasons other than Cost per GB that might drive this crossover.

My IBM team 10 years ago or so developed a 1-inch drive we called the “MicroDrive”. Well, before you could buy 256MB of Flash, we sold 1GB MicroDrives. Although the cost per MB was much cheaper with the MicroDrive, the marginal value of the capacity was not large enough to motivate its purchase by a large enough proportion of the users. Only in extreme situations where the largest capacity was of value would someone choose the “cheaper” solution. Essentially, the value of a robust solid state solution was higher than the one that gave a lower cost per MB.

It’s kinda like making a trip to a Warehouse Store that sells groceries; it may be cheaper by the pound to buy a 10 pound block of cheddar cheese, but unless you’re feeding an Army the stuff will turn green before you can use it. In this situation the one pounder is easier to keep in the fridge, and you can use it up before you get sick of trying to add cheddar cheese to everything you make. Never mind the large quantity value proposition.

Such will be the case for Laptops – 128GB of SSD is a lot, and its speed and physical robustness is far more valuable than an extra 128GB for all but the most geeky users.

How about the Enterprise? Well, sure there are a lot of Customers who will find the speed and size of SSD to be ideal for certain circumstances, but with the capacity demands today it is unlikely that we can afford to substitute all the Petabytes of HDD with SSD for at least another 4-5 years.

So I am not sure Tucci was blowin’ smoke, but in the least his assertion seems a bit aggressive.

Perhaps if I started a “Pinheads and Patriots” section of the Blog? Nah, one of those is enough.