StorageRap

Tiering is not for Chuck Norris

2010-03-10T12:33:53-08:00

Separated at birth?

There have been some interesting discussions lately about storage tiering And just because 3PAR beat most everybody else to the punch this week with our AO announcement, I think it's important to keep things in perspective - storage tiering does not solve everybody's problems. Here is my top 10 list of reasons some people don't want to embrace tiering:

10. Chuck Norris does not need automation, automation needs Chuck Norris.

9. The Chuck Norris of IT, Larry Ellison, says Exadata is the only tier you need.

8. Chuck Norris & Larry Ellison will race to determine if tiering is good or evil.

7. Heard it uses gerbils, which is unfair to guinea pigs.

6. Chuck Norris got to Tom Georgens, he will get to you too.

5. Chuck Norris designed 3PAR's wide striping - who needs tiering?

4. Chuck Norris already tunes my storage in his sleep.

3. Larry Ellison is going to buy all the world's SSDs and corner the market.

2. Waiting to hear if Chuck Norris will discuss tiering this week on InfoSmack.

1. Too busy celebrating Chuck Norris' 70th b-day today to care about tiering.

Why AO is a game changer

2010-03-09T12:15:28-08:00

Yesterday, 3PAR announced Adaptive Optimization (AO), our solution for storage tiering and support for SSD flash drives. Here are the elements of this technology that I believe will have the most impact on customers and the rest of the industry.

1) Tiering works by making copies of data on lower cost, low-IOPS storage to high-IOPS storage - and back again. Storage tiering has been associated with ILM, which assumed data is initially located on more expensive, high-IOPS storage and, as it ages and is accessed less frequently, is moved to lower-cost, low-IOPS storage. The perception that tiering implies fast to slow data migration was reinforced by Compellent with it's early entrant storage tiering technology, Data Progression .

The economic benefits of tiering are much more compelling if data is originally located on low-IOPS storage and then moved to high-IOPS storage when it becomes useful to do so. This reduces the amount of high-IOPS storage that needs to be purchased and reserves high-IOPS storage for the applications that need it the most. This model of promoting data to high-IOPS storage will replace the old model of data "trickling downhill to cheap storage."

2) Sub-volume tiering means high-IOPS storage can be reserved for high-IOPS work and effectively shared by the applications that need it the most. AO copies data in 128 MB sub-volume regions that contain specific RAIDed volume slices. Many physical and virtual servers can have their volume's most active regions located in high-IOPS storage capacity at the same time.

Data redundancy is accomplished when AO reads data from it's source region and restripes it into a region on the target tier - using the RAID level of the target. AO allows data to be protected by whatever RAID is appropriate for the tier and the data. 3PAR's chunklet architecture is maintained for SSDs, which means a SSDs in an InServ array can apply several different RAID levels simultaneously. Every vendor's sub-volume tiering technology will be different, including the number of ways devices can be combined in RAID and how wide striping can be applied.

3) Tiering does not mean you have to buy SSDs to make it pay off. Tiering is a cost-reduction technology. One of the most obvious ways to reduce the cost of storage is to buy cheaper disks with higher capacity, such as SATA drives.

The regions used by AO are the same on-disk structures that 3PAR uses for it's Dynamic Optimization (DO) software that re-levels volumes across disk drives in an InServ array. A customer with all FC drives in an InServ array could take advantage of both AO and DO by increasing the capacity of an array with SATA drives, using Dynamic Optimization to redistribute their volumes across the SATA drives and then using FC drives as their high-IOPS AO tier. This way, they can continue to get the IO rates they expect, but reduce the cost of incremental capacity as they upgrade their system.

4) The system determines what to move and how to move it. I/O density rate is a term that refers to how much data access occurs in a region over a given amount of time. AO recognizes region candidates for tiering by their I/O density rates.

Administrators control the AO participation for each volume by assigning them to an AO Profile and a QoS Gradient. The profile is a short stack of device-RAID levels, such as SATA RAID 6, FC RAID 5(7+1) and SSD RAID5 (3+1). AO allows either 2 or 3 device RAID levels in the profile's stack.

The QoS gradient is a relative determinant of how quickly the volume will be acted upon. I like to think of it as something like different viscosities for different fluids, but for storage. AO today has three QoS gradients, performance, cost and balanced.

Back in Novemebr, Tony Asaro wrote about his discussions with HDS' storage customers regarding storage tiering.

Another discussion was around using policies to automate the process. One group was a bit concerned about automating this process but realized that, again, with PBs of data being stored that the only way to effectively implement intelligent tiered storage is via automation. Additionally, it is not an all or nothing proposition. You can select certain volumes and applications to implement and gain a comfort level before deploying more widely. One of the key tenants of technology is to automate otherwise manually cumbersome processes. We just need to get over that hurdle but we need to do so in a planned, considered and reasoned way.

By applying measured I/O density rates, AO profiles and QoS Gradients, 3PAR has taken the first major steps to automating storage tiering and removing the burden from administrators.

5) Tiering can and should scale out. David Floyer from Wikibon wrote a good piece yesterday on our announcement where, among many things, he discussed how 3PAR is using smaller SSDs spread over more controllers:

....it spreads a small amount of SSD amongst the 3PAR engines so the IO’s aren’t all going to a single drive and sucking up a lot of bandwidth – it’s nicely balanced. Traditional implementations will use larger drive with more IO’s going to that drive. The part of the array with that drive will get more activity.
In practice we don’t think this will matter all that much because, for example, EMC’s V-Max has more bandwidth to play with than 3PAR and EMC uses its cache to transfer data between tiers to avoid bottlenecks. Nonetheless, on paper, the 3PAR implementation looks to be more efficient which means (in theory) it can do more with less flash. But nobody really knows yet.

3PAR storage arrays avoid I/O bottlenecks by incorporating tiny virtual storage elements (chunklets) and spreading the workload over as many devices and controllers as possible. This approach differs from other vendors where smaller groups of resources are created and then combined into larger constructs that are more cumbersome to manage and tune than a single widely distributed storage span. The same concepts apply to SSD integration, where InServ arrays accommodate multiples of many, smaller sized SSDs for scaling out high-IOPS tiers for those customers that may want to expand their use of AO in the future .

3PAR Countdown: AO & SSDs

2010-03-08T12:09:26-08:00

The news is here, and here, and here.

3PAR announced its storage tiering technology today with the introduction of our Adaptive Optimization (AO) software and with support for flash SSDs.

There's probably going to be a lot of discussion about storage tiering and AO in the weeks to come, so stay tuned.

Tired of being virtually tongue tied? Give Mosh a chance!

2010-03-04T06:36:00-08:00

I was talking with my InfoSmack co-conspirator, Greg Knieriemen (iknerd.com) last week about virtual junk and how the word "virtualization" was so incredibly unwieldy. It was killing my lazy mouth to have to do so much work for such a well-understood term/topic.

(BONUS QUESTION: is "virtualization" a noun, verb, or WHAT? )

Fear no more, bad spellers and slothful speakers! The new word for virtualization is MOSHWARE. MoshWare is software that enables all sorts of systems and applications to be blended, pureed, mashed and moshed together in a single computer, or MoshBox. It also allows MoshMachines (or MMs) to be relocated to other MoshBoxes using functions such as m-Motion or TransMoshinization.

Of course the word "MoshWare" could apply to many other things, including social networking sites, such as Twitter. There needs to be a modifying word or prefix for the social context in order to differentiate machine MoshWare (its true form) from social MoshWare. Devo MoshWare works for me.

Blade servers also provide Moshable benefits, similar to those of MoshWare, but in hardware. Whereas "Blade server" has 3 syllables, the much smaller word "BladeMosh" simply rolls off the tongue like a Scotsman's beverage.

One of the great things about MoshWare is getting rid of unnecessary networking adapters by consolidating network traffic on fewer links over the MoshNet! Not only that, but storage MoshNets can be implemented as Switchless SAMs (Storage Area MoshNets). To accomplish this, a MoshBox's HBAs are cabled directly to a storage array's ports without an intervening switch. When you consider that this eliminates two switches at at time (for HA) - as well as the need for zoning, the economic benefits can be significant. We have a number of customers at 3PAR who do just that and have saved a lot of money in the process. This means installing more SAN adapters in storage arrays, but if the arrays can accommodate them it might be worth considering. Is it for everybody - certainly not, but is is another option for reducing the cost of storage.

So what about Moshed storage - or STORMOSH! SAN and NAS are different forms of StorMosh, but DAS is most certainly Moshless. The amount of Moshing a StorMosh does depends on it's design. Some StorMoshi require a large amount of Manual Moshing (ManMosh is an oxymoron to be sure), whereas other StorMoshi, such as those from 3PAR and Dell EqualLogic, Mosh at a very high level.

The graphic below shows an implementation of a MoshStack ,with a MMs running inside MoshBoxes, connected to a StorMosh via a Switchless SAM.

A case of overkill - and how tiering avoids it

2010-03-03T14:18:14-08:00

A couple posts ago, discussing Netapp CEO, Tom Georgens' now famous quote on tiering, I wrote:

To be fair, Georgens DID get support from the contrarian Drunken Data.

This was the only reference to Jon Toigo and his blog. Apparently this thoughtless insult set Jon off because a week later he wrote a whole lot of overkill in response. Considering the effort he made, it doesn't seem fair to just ignore it all.

1. I listen to customers, so do Chuck Hollis, Barry Burke, Mark Twomey, Val Bercovici, Alex McDonald, and most of the vendor bloggers. We might take away different things, but I'd bet there is a fair amount of overlap in those discussions.

2. Tiering is all about reducing cost. It's not going to reduce costs for every customer, but customers needing performance acceleration for certain apps at various times can save a lot of money with tiering. There is no need to configure a system for overkill, when a smaller number of high-performance devices and tiering can do the job.

3. Bruce Kornfeld at Compellent is a blogging wannabe. He can change that if he wants to by engaging the rest of the storage blogosphere.

Speaking of overkill, there are a lot of installed arrays that are great examples of capacity overkill. It's often discussed as poor utilization, but that is just another way of saying customers purchased far more capacity than they needed. In other words, they bought an overkill solution.

3PAR's thin technologies are all about avoiding capacity overkill. If you think you might want to get away from overkill storage implementations, it's a good time to do it with 3PAR, while we have our 50% capacity guarantee program running.

Top 10 Reasons HDS is out at Oracle

2010-03-03T04:19:37-08:00

iKnerd (Greg Knieriemen) broke the story yesterday about Oracle/Sun breaking off their relationship with HDS. That got everybody twittering - with the majority of tweets from the storage universe suggesting Oracle had greedy motives. How unfair! So, the video below attempts to restore balance to the universe and brings Netapp, HP, cloud computing, 3PAR and Larry's toys into the discussion.

If you are a Sun storage customer and think its time to change, you should check out 3PAR. We have a lot of ex-Sun server engineers who designed our storage cluster. I'm sure you'll appreciate the architecture of our InServ arrays, as well as our 50% capacity reduction guarantee.

(Hey, Claus Mikkelson at HDS. I've had a comment in on your blog for a couple days and it hasn't been posted yet. I know things can slip through the cracks sometimes, so I thought I'd bring it to your attention.)

Storage anarchist apprehended in 3PARvaTAR's chunklet matrix

2010-03-01T18:00:28-08:00

Last week, the storage anarchist published a virtual talk show featuring virtual me (3parfarley) as the special guest.

In a strange turn around of events, the 3D cartoon instantiation of storage anarchist was apprehended recently while sneaking around in 3PARvaTAR's chunklet matrix. Special cameo appearances are made by the Storage Architect, iKnerd and and Stephen Foskett direct from their karaoke concert last Thursday night @ #HPbladesday

3PAR, EMC, Netapp, IBM, Capacity Guarantee, storage, array, SAN, HDS

Netapp & tiering - Just when they thought things were looking up...

2010-02-24T05:00:03-08:00

Netapp has been on the hot seat ever since Tom Georgens, their CEO commented that tiering would soon be obsolete. Since then, a number of people have called him out on it, including yours truly (in a steering wheel cam), StorageBod, The Storage Architect, StorageZilla , a storage blogging wannabe, and last but not least, the Storage Anarchis t. To be fair, Georgens DID get support from the contrarian Drunken Data.

At the end of his post, the Storage Anarchist asks:

Are they just defending their chosen path of Flash-as-cache instead of –as-a-tier? Or is it deeper than that? Is there something inherent in WAFL that makes it difficult to implement multiple different tiers within a single array? Or is it something else?

It's tempting to suspect WAFL's snapshot mechanism is the problem, but there is nothing about file level snapshots that would preclude storage tiering. Storage tiering depends on the ability to redirect block addresses across devices classes, which can be done at an abstraction layer below the file system level. In Netapp's case, the issue appears to be an interlock between WAFL and Netapp's underlying RAID layer. So I'd say its mostly a Netapp RAID problem.

As writes come into a WAFL system, they are first staged to NVRAM in order to eliminate parity RAID write penalties and then they are written to "nearby" blocks using a tightly coupled relationship between the file system and its underlying RAID subsystem. This design has an unusual and intricate knowledge of disk drive operations and status within the RAID array. In other words, the file system in a Netapp machine is intricately coupled to the physical characteristics of the underlying storage hardware, which means creating block abstraction layers is highly improbable. The text-image below is from Netapp's Patent filing 6,138,126 dated October 24, 2000.

Now it's possible that this patent does not indicate the implementation within Filers today, but I'd say there is a good chance it explains Netapp's reluctance to embrace tiering. If this turns out to be Netapp's tiering shortcoming, Netapp would need to virtualize their RAID implementation in order to get to a point where they could start working on tiering.

Holy cow!! Is it possible that Netapp is actually THAT FAR behind in storage virtualization - not to mention the next wave of the technology - tiering?

If this analysis is correct, it may be that the only way to get tiering (not caching) with a Netapp system is to connect their V-Series filer to a third party array that offers tiering. If that's the case, will Netapp support it, seeing as how they don't have it on their home-grown Filers?

The hot seat could get a lot hotter.

The SWCSA rides again: A smackback for Georgens' whacked fast smack

2010-02-20T10:31:30-08:00

No, it's not a SWCSA rap, but it is a steering wheel cam, complete with a surprise ending- inspired by Stu @ at EMC.

Forget Netapp, is 3PAR vulnerable to "good enough" competition?

2010-02-18T11:44:33-08:00

In a self-described FUD piece today StorageBod wonders about Netapp's future. To put a finer point on his thoughts, in a comment he wrote:

Your first billion was the easiest billion; the rest gets harder...there's a target pointed in the middle of your foreheads' now. You are going to have to run even faster, even to stand still. Can you do it and can you do it without increasing your product set?

Normally I would enjoy this sort of badgering, but in a subsequent comment he wrote:

Complaint about NetApp is how vulnerable they are...they are not the only ones tho'...there are more vulnerable companies out there; 3Par, Compellant, Isilon, BlueArc etc, etc...the trailing pack who need to grow quickly or get bought.

OK, at least he mentioned 3PAR first! After all, we are larger than the rest of the pack he mentioned, not to mention in a much stronger financial position. To put a finer point on it, 3PAR is not vulnerable to debt (we have none), nor to cash weaknesses ($108 Million and increasing every year).

So what vulnerability is StorageBod imagining? I suspect it was similar to those voiced by EMC blogger Chuck Hollis:

But, as you point out, it doesn't strike many of us as a defensible position long-term. It's just too easy for competitors to provide a "good enough" and attack those rich margins.

EMC tended to think it was in an unassailable position a decade ago with the Symmetrix. We were quite wrong. If I was doing a storage startup, it'd be pointed directly at draining NetApp's profit pool.

I also think that single-product companies lose the benefit of hybridization -- combining multiple technologies in new and interesting ways.

My take on this is that the storage industry tends to have different dynamics than most other industries. Yes size matters and Netapp and 3PAR and everybody else plays by those rules, but after achieving a critical mass, size is less important than paying attention to details. Doing things more effectively - not just in a more grandiose fashion - makes the largest difference.

We are not concerned about competitors trying to copy us and providing "good enough". A competitor's assessment of "good enough" will likely not be adequate to many customers. It's how we grew our business over the last 10 years inside the jaws of EMC's formerly unassailable Symmetrix business. I was an independent outsider when 3PAR began and to tell the truth, I thought the folks at 3PAR were out of their minds. But 3PAR has steadily grown and continues to gain market share - primarily in the high end of the market. Admittedly, the high end has not been a place for hottest growth over the last decade, but we've climbed and are still steadily climbing. As the service provider model of IT evolves and gains traction, we like our chances with our products and technologies there. FWIW, our new mid range F-class systems are doing very well, but we probably need a larger reseller channel to address the number of mid-range opportunities we are seeing. That is a growth problem, not a shrinkage problem.

3PAR's capacity guarantee program works because we consistently deliver utilization levels that our customers didn't think were possible and we stand behind it with a contract. Customers continue to check it out and are coming to the understanding that great utilization comes from a system designed for optimal efficiency and not simply to be "good enough". If you stop thinking about storage administration as managing disk layouts you are on the right track. 3PAR admins don't manage disk layouts.

The question of hybridization and crossover potential is very interesting. Innovation can come from trying to tie disparate things together and this sort of integration is incredibly valuable when done well. However, a hybridization mind set often assumes that most core innovation has already been done and that most future gains will come from integrating across functional boundaries. 3PAR doesn't think fundamental storage technology is even close to being fully developed. The problems customers assume they have to live with should not be tolerated.

So yes, it's possible that we are vulnerable. The storms of technology change could make 3PAR and Netapp irrelevant in the years to come. Speaking only for 3PAR, we believe there is still a gold mine in revolutionizing storage efficiency and will continue to compete based on that belief.