StorageRap

Calculating the output of wide striping arrays

There has been some discussion recently about wide striping in the storage and virtualization communities and it struck me that a number of people were unsure what it was and how to think about it, so I thought I'd explain the basics here.

What is Wide Striping?

Wide striping is a method of spreading data over a large number of disk drives in a storage array in order to achieve a desired performance goal. The term wide striping has been used sometimes to refer to sets of disks with 16 to 32 members, or more.  It seems strange that somebody would classify a 32 member disk set as having wide striping, when you compare that to a disk set with 320 members, but that's how definitions in the storage industry tend to be broadly interpreted - especially by vendors :). 

The amount of work a disk drive does is measured in IOPS

One of the ways to measure storage performance is using a metric called IOPS - or IOs per second. An I/O is either an operation where the disk drive reads data from media or writes it to media.  Reads process faster than writes, so it is important to understand this mix in your applications. The amount of work a disk drive can do is proportional to the rotational speed of the drive. 

There are two basic classes of disk drives used in enterprise storage arrays today; lower-cost, lower performance SATA disk drives and higher-cost, higher performance disk drives with Fibre Channel (FC) or  SAS interfaces.

A 7,200 RPM SATA drive can sustain ~ 80 IOPS

A 15,000 RPM FC/SAS drive can sustain ~ 200 IOPS

In other words, a 15,000 RPM SAS/FC drive can do approximately 2.5 times more IOPS than a 7,200 RPM SATA drive.  You need approximately 5 SATA drives to sustain the same workload as a pair of FC/SAS drives running at maximum sustained levels.  

Storage workloads are determined by the applications being used and there is a great deal of variety in the performance requirements they have. Some applications need very little storage performance and some applications need a high level of storage performance. 

Workload isolation

Storage arrays that do not have wide striping tend to have high-priority workloads isolated on certain designated drives in order to meet the performance requirements of those applications. For instance, an array with 100 FC/SAS disk drives could have ten of those drives used exclusively by one high priority application to make sure that it has access to all of the 2,000 IOPS those drives can generate. 

Isolating workloads this way creates storage capacity utilization problems because the capacity requirements of most high performance applications tend to need fewer disk drives than IOPS requirements determine.  In other words, an application that has reserved the 2,000 IOPS of ten 450GB FC/SAS drives might only need 900GBs of capacity - with a utilization of 20%.

The IOPs requirements of applications change over time, which means an application that has it's workload isolated on a set number of drives can exceed their aggregate IOPS capabilities, creating a performance bottleneck for the application. The structure that was established to ensure sufficient IOPS becomes a performance problem. The process of adjusting and rebalancing the disk drives that are used to support isolated workloads can become extremely complicated and time consuming depending on many variables and creates opportunities for administrator errors.

Workload randomization

Alternatively, storage arrays with wide striping tend to have multiple applications sharing the IOPS generating capabilities of a large number of drives - up to all the drives in the system. Using this approach, the data from each applications is spread over all the drives being wide-striped to give all applications access to the the aggregate IOPS potential of the array. For example, an array with 100 FC/SAS disk drives that wide stripes data over all the drives would have 20,000 IOPS available for any and all applications at all times.

In contrast to workload isolation, discussed above, this approach is known as workload randomization because it mixes all the data in the array across all of the disk drives. In order to ensure data is written across all the disk drives, wide striping storage arrays tend to write data in very small increments on each drive. Applications with heavy IOPS workloads are utilizing all the drives in the system in relatively similar amounts.

By nature, wide striping eliminates array bottlenecks and achieves better storage utilization, but utilization levels depend on storage provisioning methods that are designed to take advantage of wide striping such as Thin Provisioning, which is another topic for another blog post. 

The lack of bottlenecks in a wide striping storage array also means that mixed workload performance is optimized because all applications have access to the full IOPS potential of the array. Virtualization environments benefit in two ways: 1) by being able to mix applications and VMs on physical servers without worrying about the creation of storage bottlenecks and 2) achieving higher VM densities.

Enterprise arrays with native, wide striping

There are two enterprise storage arrays that use native wide striping across all the disk drives in the system, without the need for administrators to organize RAID groups and create disk pools.

3PAR InServ 

IBM XIV

There are many important differences between these two products, including the flexibility of RAID implementations and disk drive options, but the method of wide striping is similar.

Wide striping IOPS to servers

The number of IOPS delivered by an array is slightly less than the aggregate number of drives in the array, depending on the mix of reads and writes and the type of RAID that is used by a particular volume.  Here are a few examples of IOPS calculations for wide striping systems using different drive scenarios and 8k blocks.  The arrays modeled here do not include mixing RAID types for different volumes, except the last model that mixes RAID 5 on FC drives with RAID 6 on SATA drives.

Array 1: 80 450GB FC disk drives:  80% reads, 20% writes

Total IOPS of all drives in the array:   16,000

IOPS delivered to servers w/RAID 5:  10,000

IOPS delivered to servers w/RAID 10: 13,333

Array 2:  200 1GB SATA disk drives:  80% reads, 20% writes

Total IOPS of all drives in the array:   16,000

IOPS delivered to servers w/RAID 5:  10,000

IOPS delivered to servers w/RAID 10: 13,333

IOPS delivered to servers w/RAID 6:     7,505

The next array has both FC and SATA drives and changes the read/write ratio. In this case there are two different wide stripe sets, one that spans FC drives and the other that spans the SATA drives.

Array 3: 160 450GB FC + 480 SATA disk drives: 70% reads, 30% writes

Total IOPS of all drives in the array:   70,400

IOPS delivered to servers w/RAID 5:  37,052 

IOPS delivered to servers w/RAID 10: 54,153

IOPS delivered to servers w/RAID6 (SATA) & RAID5 (FC): 31075

Fact or fiction? CHP quotas and thin provisioning

Pat Gelsinger's moon shot

A couple weeks ago EMC's Pat Gelsinger outlined a vision for long-distance federated storage, which Chuck Hollis wrote about on his blog.  

It received a fair amount of attention in the storage community as a bold step by EMC to set a development course with far reaching potential.  StorageBod's take on it was to call it a moon shot, referring to NASA's enormous decade-long project in the 60's to put a man on the moon.

I remember being a kid during those years, thinking that anything would be possible in our lifetimes through the combination of imagination, hard work and glorious destiny.  We were encouraged by things like scuttling our yearly ice fishing expedition and taking a winter vacation to Disneyland instead.

One of the great all time memes is pursuing the dream. "If you dare to dream", the voices say, "you will be richly rewarded."  Not many details are given about the compensation part of the promise, but to a child growing up in the frozen north, you imagine things like living in California, near Disneyland with a lifetime membership. 

Silicon Valley and Route 128 replaced Disneyland as the places where dreams were made for tech whiz kids. The reward part became more obvious, but so did the reality of how much dreams can cost and that acronyms like ROI, tend to stop them. Start up companies fail for a lot of reasons, but eventually it's a matter of their dream losing a showdown with an ROI inquisition.   

But dreams don't necessarily always die. In today's world the technology dream is encapsulated in intellectual property (IP) and purchased by another company. Like a biological organism that can lie dormant for many years, the IP of the failed company can be revived at any time by applying development resources. The inevitable scrutiny for ROI may be suspended while the dream is being re-created, but eventually it has to face it's tormentors again.

Geslinger's federated storage dream at EMC is such a project. It started as the dream of a little startup in Edmonton called Yotta Yotta.  I remember the company and the passion the team had. It was a big dream that eventually could not stand up to ROI examination.

Now Pat Gelsinger, a relatively new exec at EMC appears to have bet his career on an acquired dream. It's not clear how all this came to pass, but it does not appear to have complete support within the company. For starters, it certainly competes for mind share with Atmos - another storage dream with similar characteristics, but different underlying technology.  Perhaps these two initiatives will be combined, but they don't look all that compatible at first glance.  The absence of Atmos in Gelsinger's vision suggests that Atmos is not living up to its hype.

The bigger issue would appear to be Gelsinger's focus on hardware and protocols, as opposed to higher level software. EMC has been moving to become much more of a software company under Joe Tucci's leadership. Gelsinger's federation dream looks like a hardware and firmware play.  

EMC World this year will be very interesting as the company tries to figure out how to spin all of the varying visions they are projecting.  Most of the attendees will be customers and fans of EMC, but I'm betting that there will be more confusion and questions about what the company's direction really is. Do their multiple visions make sense together?  Are they visions that have an understandable, attainable ROI?  Or do clash with each other and leave people wondering how much they will cost and how long will they take to be finished - if ever.

I am OK with health care reform, now how about political reform?

Our expectations for how laws are made might need to be reset.  The old adage, "you don't want to see it" doesn't really work any more in an increasing connected world.  This one was hard to avoid.

FWIW, I think the democratic strategy of mostly ignoring the republicans was the best one because the republicans are apparently only interested in derailing any outcomes while the democratically controlled congress is in power.  And this is how things are going to be as long as we agree to be elect representatives of the same two, entrenched parties.  Not a great scenario for government productivity.  No wonder there is so much cynicism surrounding politics.

In the aftermath of this, the republicans are going forward with a "vote the bums out" crusade. The democrats, on the other hand, will try to portray the republicans as log-jammers, a position that is much less appealing than the bum's rush approach. Of course, sweeping the floor of incumbents favors the republicans numerically because there are more democrats to sweep out. So what will change? The balance of power shifts, but the whining, bickering and polemics stay the same.

To me, the answer is simple, but making it happen is virtually impossible - and that is to get another national party off the ground.  There are a lot of reasons why it won't work, but I'm a bit tired of hearing why things can't be done in politics.  One of the ways to start chipping away at the two party system is to change the way primary elections work.  Here is a link to a ballot initiative that will be on this year's June 20th primary ballots in California.

Get out the Kleenex, Dell is back in the arms of EMC!

It's official today, for now anyway. Dell and EMC are back together doing the old shoop shoop dedupe after trying to ignore each other for much of the last year. 

OMG!  I wasn't sure who to call first, my agent, the paparazzi or Dr. Phil to talk this over with. Like, this was SOOOO predictable -  like, you know - two people that start out as adversaries become attracted to each other out of financial necessity and then they find out, like, they don't really have that much in common, except that, like, they sort of need each other to use as an excuse when they are, like trying to get out of other situations that they don't, like, you know, like very much? 

Will this relationship become the longest running technology soap opera of all time?   The rumor mill has been pretty quiet  lately concerning Dell's plans to acquire technology companies and create more leverage and generate higher margins. So how is a new deal with an old flame going to help them do that?  I can only guess that the EqualLogic business at Dell has not panned out as well for Dell as they have been saying.  Perhaps storage investogators Chris Mellor,  Beth Pariseau or Simon Sharwood can dig up something about this? 

 As it is with so many sales relationships, it will only last as long as the tricks that the respective sales forces play on each other don't get too nasty.  Somebody is going to make more money than the other and the one with the smaller surprise won't be very happy when they find out their party is a bring your own event.

Good luck to both for having done something they will probably both regret, but never admit to having any.

 

Finding a cure for Private Cloud halitosis

It's easy to get caught up in the excitement of new concepts in this business and it's one of the things us marketing people like the most.  We also like love competition, (oh really!), which means there is  pressure to be omniscient - or at least to appear to be. Whether it's bluster or public brainstorming, we've all listened to somebody who appeared to be very confident in what they were saying, only to find out later that they were pretty much clueless. Sometimes the industry plays a giant game of telephone, where there is a massive exchange of misspoken, misinterpreted and misaligned thought experiments. 

One of the symptoms of mass-confusion is an abundance of definitions as people struggle to understand new terminology.  Defining a legitimate new concept makes it easier to think about and puts it in a frame of reference where it can be scrubbed for financial and technical viability.  Rarely, things like Twitter defy financial gravity, but most other half-baked technology concepts acquire a fish-belly patina under the harsh  light of a CFO's or CEO's scrutiny. "Tell me again why you think we need this new capital black hole and when you figure it's going to recoup half the ROI - and why we are paying you to waste your time on it?"

Larry Ellison has proven himself over many years to have an excellent perspective on technology trends and he wonders what cloud computing is. To him, its an information service built from exisiting technologies, - not some new technology all its own. I've been trying to think of a good way to disagree with his perspective and have quite a problem justifying anything having to do with Private Cloud.  Public Cloud, yes - Private Cloud - no defense.   

The financial analysis for outsourcing IT functions to a Public Cloud service provider is easy to understand.  You compare the costs of doing it internally with having a subscription with a service provider to it for you. There are a lot of details to collect, but its easy to see how the analysis lines up. The customer doesn't care much about the technology the service provider uses - as long as they get the services they've subscribed to. Does a customer care if their service provider is using Cisco UCS, HP Blade Center or Dell Servers, 3PAR, Netapp or EMC storage? Paraphrasing many others, the Public Cloud changes the way customers acquire information processing capabilities.  Public Cloud is legitimate because it is a distinctly different concept than business as usual in IT.

But the Private Cloud?  It's a different way to talk about building an internal infrastructure of software, servers, storage, networks, etc. The capitalization model is the same as it's ever been, the sales cycles are the same as they have ever been, the vendor selection process is the same as its ever been.  What does Private Cloud change?

Some would say, the technology is changing to enable new business-driven processes, such as  incorporating more detailed, fine-grained, usage-based billing for IT services. Really? - what is so cloud-like about that?  It's just the application of accounting principles applied to a shared capital and operating expense. CEOs, CFOs and COOs would all agree that this information might be useful and then wonder why its taken so long to get it. Do you really want to look these people in the eye and say "That's the benefit of implementing a Private Cloud"?  Wouldn't it be much better to say "We are improving our internal metering so we can assign costs to the various parts of the company."  Yes, it takes longer to say it, but the communication is a lot less convoluted when the words "Private Cloud" are avoided.

Then there is the aspect of sharing infrastructure resources among many different applications and user groups. Is that really cloud-like, or is it a by-product of virtualization?  That is all virtualization and it is a concept that CEO, CFOs and COOs can understand without hearing the word cloud.

Private Cloud is just a euphemism for the incremental improvements that are going on in technology infrastructures. Its business as usual - complete with all the hype. If you don't understand what's so special about it, don't worry, just picture yourself trying to explain it to your CEO and see if you can do it without using the words Private Cloud.  It's not very difficult.

An app to use with SSD tiering: backup

Latency-sensitive applications are the best candidates for storage tiering to SSDs with 3PAR's AO (Adaptive Optimization.Typically, these are:

1. High performance transaction processing, like securities trading, or
2. Single threaded applications that are idle while storage I/Os complete

People ask about Microsoft Exchange and I tell them it benefits a great deal from big, wide striping, but not much from tiering because Exchange performance is mostly a matter of providing adequate throughput.

An app that people run daily but is seldom associated with transaction processing is backup.  This SWCSA video discusses backup as well as the prevailing shift to dashcams and the implications for SWCSA branding.  

3PAR Countdown: Bateman Engineering in South Africa

The news is here.

It's gratifying to see our international business growing. Yesterday we announced our first South African Utility Storage customer, Bateman Engineering, who worked with our Channel Partner, SYSDBA there. 

Storage Caching 102 - mixed workloads

Chuck Hollis had an excellent post last week, discussing caching. 

About 10 years ago a small team that I was a part of looked at starting a company that would do something similar to what IBM's SVC does.  The idea was to create a SAN front end controller with a lot of cache memory that would virtualize  "downstream" storage and provide performance boosts through various techniques such as caching, striping, and multi-way mirroring.  We gave up on the idea when it became apparent to us that the project was quite a bit larger than we initially thought and it was unclear when we would ever have sufficient resources to get a competitive product to market. I think we could have sold the idea to venture capital investors who were throwing money at storage startups, but we couldn't sell it to ourselves. For those of you that wonder why I tend to think SVC is an important product, that's why - I know some of the things IBM did to make it work and I admire their ability to bring it to market.

Anyway, one of the hurdles we couldn't get past was how to deal with mixed workloads originating from multiple SAN attached servers simultaneously streaming data from data warehouses and IOPS from transaction databases and all sorts of other bursty, unpredictable applications competing for memory and disk resources. As a front-end appliance, you can control your own cache resources, but you can't do much about the back end disks because downstream arrays mask them from the appliance. In fact, there was no way to predict the performance of the downstream arrays for any given workload. We consulted with experts from the industry and research universities and they were all discouraging about the ability to significantly improve the performance of mixed workloads in a shared SAN appliance.

There were two issues: downstream arrays already had their own caches and the dynamics of sharing cache resources in an appliance. If these fundamental problems could be solved, the rest of the work was the not so simple matter of making it work as a cluster with mirrored cache for HA.

Uncoordinated multi-level caches have the problem of redundant data.  For example, pre-fetching data in the appliance's cache will likely end up loading the same data in the downstream array's cache.  With duplicated cache data, a cache hit on the appliance won't be that much faster than a cache hit in the downstream array - and a cache miss in both will be much slower. It's difficult to prove the value of THAT.  Its certainly possible to tune both caches differently, but this turns out to be easier said than done and tends to flatten the value of an "easy to use" appliance.

So, the way to overcome this is to make a HUGE cache in an appliance.  Increasing a cache's size can do a lot for performance and Chuck said,

The exception, of course, is if you've got the bucks to create a ginormous read cache, and pull almost all the significant data into memory.  Don't snicker -- there are a few use cases where this sort of approach makes sense.

In other words, create a RAM disk in cache. This technique is normally reserved for a single, high profile application and as Chuck wrote, there are use cases where this makes sense.  But it doesn't address the requirements of mixed workloads where there are a large number of applications that do not merit dedicated memory, but still need good performance.  It might be possible to micro-manage cache for some number of applications by dedicating cache for each of them, but that requires a great deal of work that is likely going to be a temporary solution lasting a couple of months at most. It's probably a great way to drive storage admins crazy.

A more palatable approach is to use a global cache that shares cache resources among multiple servers and their applications. In some cases, it's possible to predict workload demands (end of month processing for example), but in many cases, the instantaneous performance requirements cannot be predicted because it is driven by spontaneous events.  As many people are too familiar with, spikes in Internet activity and the corresponding bottlenecks in back end storage clearly elaborate the challenges of mixed workloads. Global caches that can accommodate large Internet traffic spikes are expensive and do not provide noticeable performance advantages most of the time - they are overkill.

The proliferation of virtualized servers has significantly increased the breadth of the mixture that a storage array has to deal with. In general, there is more overall I/O activity that is, for the most part, less predictable, and therefore more difficult to deal with in cache.  

The question is, is storage tiering with SSDs any better?  Possibly. If it is going to more effective than caching, it needs to be able to provide more control points and intelligence than cache typically does. For instance, the ability to prioritize and schedule applications for movement into SSD tiers could be an important difference. 3PAR's QoS Gradient concept in Adaptive Optimization is an example of a simple prioritization scheme. The internal counterpart to QoS Gradients is internal monitoring of I/O levels which help determine which applications are promoted. 

That's not to say caching can't have some of the same controls, but traditionally caching has been more reactive than proactive.  To be clear, tiering is also reactive, but within the context of intelligent preparation and business-driven policies. 

Still, considering the cost of SSDs, you have to ask the question is tiering overkill too? It might be. If the array can keep up most of the time, how much SSD capacity should be purchased?  These are the sorts of things that will be determined over the next couple years.

The best technology to date for dealing with mixed workloads continues to be wide striping. If you throw out latency-sensitive applications from the mix - those are the same apps Chuck Hollis referred to when he talked about the applicability of "ginormous read caches" - then the array just has to provide adequate throughput at reasonable service times (latencies).

Wide striping does this by spreading the workload mix over as many disk drives as possible.  Not the number of drives that fit in a shelf or can be added to a RAID group, but all the drives in an array, at best or all the drives of a particular class, day SATA or FC. Wide striping very thin layers of data across hundreds of drives means that hundreds of servers can be accessing data simultaneously, with a minimal amount of contention.  The result is that all the drives are kept busy at the same rate and that none of them bear an unfair burden. The overall sustainable throughput is very high, scales by adding more drives and in general fits the profile of mixed workloads better than any affordable caching scheme does.

We've become accustomed to thinking that more memory is the answer to all storage performance problems, but that doesn't exhaust the potential of massed disk drives.     

Tiering is not for Chuck Norris

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

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

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!

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

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

 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.)