StorageRap

EMC, the Misanthropic Media Company?

It's getting very hard to keep up with all the crazy social media stunts coming out of Hopkington, but they seem to have done it to themselves again.  First was the questionable spamming for viewers so they could claim they had a viral video, then today they just "leaked" a 3PAR sales "kill sheet" - and also apparently established a "secret" site with the URL Notapp.com, where they compared their own guarantee program to Netapp's.  According to Simon Sharwood at Search Storage Australia, the site was removed and accessing the URL directed browsers to EMC's site.

Perhaps it is all part of a new marketing strategy by newcomer Jeremy Burton, who joined EMC as Chief Marketing Officer back in March.  As best I can tell, Burton's new marketing strategy for the company is that people will believe anything.  Maybe he doesn't think there are enough new products coming out of EMC - or that the delays in getting their ballyhooed FAST out the door are too embarrassing - but instead of trying to promote EMC on its own merits, it looks like he is doing his utmost to mud wrestle.  Is that what EMC is paying him the big bucks for? 

EMC suddenly is taking a bigger interest in 3PAR. That's good. Search Storage Australia just published parts of a competitive document that EMC was circulating to it's partners about 3PAR.  It certainly wasn't a surprise because we'd seen it previously, but I was sorry to see it published because it made EMC look ridiculous, which was working pretty well for us. But now that it's been outed, here is what we have to say about it (in the guise of Ineption's lead character, the CRO)

The messaging is not built in, but our zero detection technology for optimizing capacity is. The host SW commands to do this are short and do not require "careful coordination".  Veritas, Oracle, Windows Server and Linux software all work with minimal operator effort. For instance, this document from Oracle, describes the whole process, with the sole operator command being this:  #bash ASRU LDATA.

Can EMC provide online reclamation of zeroed space without risking capacity overruns and with tolerable performance? 3PAR can. Does EMC have these capabilities in both mid-range and enterprise storage arrays? 3PAR does.

3PAR has both Flash and 1 TB SATA drives.  We also have Adaptive Optimization software that uses Flash SSDs for storage tiering. EMC still doesn't have it after they made such a big deal about it last year. They like to tell customers that their size gives them development advantages, but their track record doesn't support their claim.

3PAR arrays allow users to create many tiers, but without the need for disk pools. Tiers are constructed from the combination of drive type plus RAID level. For instance, you can have separate tiers for SATA, FC and Flash SSD drives with the RAID level you select. Our Dynamic Optimization software allows admins to move data from one tier to another. You can "dial in"  the performance and protection you want.

All systems have a peak output , ours just happens to have a lot more throughput than theirs - and at higher disk utilizations.  We have published benchmarks that show how our systems perform. They don't. Adding disk drives to a system and utilizing those drives is far easier with a 3PAR system than either VMAX or Clariion where you have to wrestle with putting drives in the pools you want to use them for.

There are no disk pools in 3PAR storage. Pools trap resources so you can't use them. Work isolation in pools leads to hot spots and storage admin nightmares.  Wide striping does not mean you can't have tiers. That is an idiotic statement.

VMAX can configure large pools - and all the drives in them have to be at the same RAID level meaning you can't create multiple tiers within those pools. If you want multiple tiers, you need multiple pools and all the headaches that involves. Change management in an environment with multiple pools is complicated. You also need to consider the pools needed for snapshots and remote replication. Are those easy to provision and change on EMC storage. Most would say "no".

3PAR uses all disk spindles all the time for delivering IOPS and pro-active sparing is done using reserved space on those drives.  Rebuilds do process quickly. Would EMC have you believe they never have to perform drive rebuilds? Really?

The RAID6 thing really makes me sad. They look so stupid when they say it. We're all sorry to say goodbye to that piece of FUD.  

Our front end archiecture was designed for large-scale parallel connectivity to match the massive bandwidth capabilities of our wide striped back end. Our benchmarks and the cost per IOPs in those benchmarks speak for themselves. Our customers also tend to run 3PAR systems at much higher disk utilizations than they run other vendor's arrays. 

We support a huge number of ports on our systems w/full active/active data access across all controllers. All controller nodes can be used to access all data volumes.  We have a number of customers that run fairly sizable SANS without switches because they have enough ports on their arrays so they don't need to consolidate access through switches.

5- 9s? We're there. Our systems get pounded on every day in some of the largest private and public data centers in the world. They are designed with complete redundancy in all components and have advanced capabilities such as Persistent Cache to maintain high levels of performance even after the loss of a controller.

The delays in bringing their FAST tiering software - a product they were hyping in April of 2009 -  to market have shown that size doesn't matter much when it comes to delivering technology on time.  I'm not saying 3PAR always delivers on time, but EMC is far from immune to these problems. In fact, the need for them to coordinate across multiple product lines creates certain disadvantages for them.

As to their comments on our support; they are pure FUD and grasping for straws.  We would not be able to maintain the customers we have if it were not for our efforts at supporting them.

  * * * * * *

The following content was added on July 30th by Rusty Walther, 3PAR's Vice President of Customer Services & Support. 

Stating that 3PAR “outsources support” is just plain silly, especially coming from a company that keeps most of the worlds’ largest offshore outsourcing companies in business.  Like EMC, 3PAR uses Third Party Maintenance suppliers (TPM’s) for break-fix field activities.  In some geographies, EMC and 3PAR even use the “same” TPM.  But EMC also outsources most of their volume call center and Level-1 Technical Support to offshore suppliers.  Not so at 3PAR.  Everyone that touches a 3PAR support case is a 3PAR-badged employee.  I challenge EMC to identify a single outsourcing company that handles 3PAR technical support.  EMC’s outsourced technical support sub-contractors could be listed alphabetically, by geography, or by technology category … but you’d need a couple of sheets of paper to do it.

Robert Cockerill from Thames River Capital: A man with broad responsibilities and 3PAR storage

3PAR customers like that fact that 3PAR arrays are so easy and fast to manage. In this video, Robert Cockerill from Thames River Capital in London talks about all the various things he does, his Windows-based infrastructure, how 3PAR's thin provisioning helps him manage it all and how simple it was to protect it with 3PAR Remote Copy.

Clarifying VAAI capabilities and implementations

Virtual Geek and I had a discussion on his post yesterday about vSphere's VAAI capabilities announced yesterday.

I wrote about the fact that we already had zero detect technology in our product, which is useful for the new Full Copy command because it allows customers to remove zeroed data from clones when they are created and return them to array free space.

The discussion became a bit confused when Chad interpreted what I was saying as pertaining to Block Zeroing.

Block Zeroing and Full Copy are different aspect of the VAAI API.  The intent of block zeroing is to reduce the amount of CPU effort and storage traffic required to write zeroes across an entire EagerZeroThick (EZT) VMDK when it is created.  The intent of Full Copy is to make clones of VMs quickly without consuming I/O bandwidth.   Things get interesting when you start thinking about making a full copy of an EZT VMDK that was created using VAAI with block zeroing - but I'll discuss that later.

I also want to clarify what zero detection technology is. 3PAR T and F class arrays have zero detection technology, which is enabled by Thin Persistence software, that recognizes zeroed blocks as they are read by the array and returns them to the array's free pool.  Any read requests made to these block addresses will return a zero value. In essence it is dedupe for zeroes.

However, Zero detection is not needed when an EZT VMDK is created using the VAAI plug-in because the array will recognize the intent of the command and not write the zeroes. In other words, the VMDK will only contain a very small amount of reserved space when it is created. Again, any attempts to read blocks in those ranges will return zero values. Zero detection is effectively bypassed during the creation of the EZT VMDK.

The exception to this behavior is when the EZT VMDK being created is written to a thick volume - in that case the array will write zeroes across the entire VMDK. 

The remaining cases for the creation of EZT VMDKs on 3PAR arrays occur when the VAAI is not used. For a thick volume, the entire VMDK has zeroes written to it.  Thin volumes not using zero detect also have zeroes written over the entire VMDK. Thin volumes with zero detect will not have zeroes written to them and will contain only a small amount of reserved space. 

FWIW, the reserved space is used as instantly-available capacity that can be allocated on-demand when writes start coming into the volume.  3PAR arrays always "read ahead" free space to improve the performance of thin provisioning.

The next bit here could be a bit thorny, so clear your head. The matter of making a Full Copy of an EZT VMDK to a thinly provisioned volume was something Chad said was not allowed.  My assumption here is that the type of thin provisioning used makes a big difference.

For instance, if you are using TP from VMware, I could see where they would not allow a full copy to be made. The problem is that the full copy will return all the zero values for the source VMDK, whether or not those zeroes were ever actually written - and write them to the target TP volume.  In other words, the target could be much larger than the source. In the VMware TP scheme, this could make for problems in a hurry if you were making a bunch of clones this way.

In contrast, if you were using a 3PAR array with zero detection, the Full Copy of the source VMDK would return zeroes for the entire VMDK, but the zero detection would strip them out again as the target was being written.  You could make as many clones as you wanted this way, knowing that the physical capacity they consume would be a multiple of the physical capacity consumed by the source VMDK. In other words, you wouldn't have to worry about virtual zero bloat making a mess of your VMFS volume.

One of the big differences between 3PAR's zero detection technology and other vendors zero-reclaim technology is that 3PAR's process is real-time-on-ingestion as data comes into the array, whereas zero-reclaim works in a post processing fashion after the zeroes have already consumed disk space. This could be a significant difference in many cases because the post-processing method has the potential to create unexpected capacity-full conditions before the zero-reclamation process even has a chance to start.

vSphere 4.1 Array Integration on steroids

We've been anxiously waiting for VMware's announcement of vSphere 4.1 for weeks.  There are many big things in this release, including significantly scaling the management capabilities of vCenter and increasing the number of simultaneous vMotions that are supported.  The door is open for ESX deployments to achieve much greater densities than they could previously and that's a big deal to large enterprises who want to get more resources under the control of fewer points of management. There are still great gains to be made in consolidation - more on that later.

In the storage world, there are a couple big things, SIOC and array integration through the VAAI API.  Technodrone has put together an excellent post on SIOC and I highly recommend that anyone wondering how to make this functionality works should go to this post and read it. Array integration has been advanced in three ways:

• Hardware assisted locking
• Full copy
• Block zeroing

Array integration through the VAAI API is already at a very advanced status at 3PAR with some of the most important functions implemented through our I/O co-processor ASIC.  While some companies want to write off the importance of hardware, 3PAR believes there are many things that need to be done in hardware to get the performance needed to truly scale storage for virtual environments.  Our co-processors are key to getting much greater storage utilization and higher VM ratios and are one of the 3PAR innovations that separate our best of breed products from everybody else.  The capabilities discussed below are available in the hardware today, and will be enabled with a software upgrade in September.

OK, lets talk about hardware assisted locking first. For customers that have experienced locking problems, this is a big deal. The problem has been well-documented online - but in a nutshell, customers have run into problems where an operation that locked the LUN for a VMFS did not complete, thereby freezing all I/Os for all systems using that LUN. That was certainly a nasty problem - not a bug necessarily, but certainly an incredible pain in the rear to all involved.

VMware's response in vSphere 4.1 was to include a command in the VAAI API using an atomic test and set instruction for implementing fine grained locks for small block sizes. There will still be locking in VMware, but on a much smaller scale.

Unique to 3PAR is the fact that this new locking mechanism is implemented in our I/O co-processors where it completes very quickly, as opposed to implementing it in code in the controller. If you consider an environment with high VM ratios and multiple vMotions going on you want this granular locking mechanism to as quickly as possible. Nobody else comes close to the speed that 3PAR processes them.

Next is the new Full Copy capability - also with co-processor assistance to reduce the capacity of the copy that is made. 3PAR has zero detect and reclaim technology integrated into the co-processor. With zero detection running in an array, as new writes are made, strings of zeros are detected by the co-processor and those blocks are returned to free space inside the array.  If future reads are made to those blocks, zero values are returned, but not from disk. The result is that copies of VMDKs with lots of zeros in it, will be much smaller after the copy is made - and the copy will proceed much faster.

This sort of functionality works amazingly well with EagerZeroThick (EZT) volumes in vSPhere.  VMware requires EZT for Fault Tolerance (FT) and MSCS clusters and also recommends EZT for high performance. The main complaints about EZT are that it takes extra time to write all those zeroes when the VMDK is created and that it doesn't work well with thin provisioning. With 3PAR's zero detection, the time it takes to writes all those zeros and the space they consume is a non-issue, but more on that later.  Virtual Geek at EMC wrote about VAAI today and in his discussion of what does not work for full copy he mentioned copying from an EZT volume to a thin provisioned one.  Actually, he's wrong about that where 3PAR is concerned, because EZT to Thin works very well on a 3PAR array with zero detect.

The image below illustrates the advantages of using EZT on a 3PAR array with zero detection:

The last API element to discuss is Block Zeroing. The idea is that the host communicates to the array to write a string of zeros when it is provisioning storage or overwriting blocks to a non-EZT VMDK.  vSphere writes a lot of zeroes in order to maintain data integrity with multi-tenancy. The hypervisor zeroes zero out blocks prior to writing them in order to ensure that a virtual data imprint from an old VM does not occur for a new VM.

But writing all those zeroes consumes CPU and I/O bandwidth that could actually be used productively, so VMware included a new command to offload the host from writing zeroes, effectively shunting that workload to the array. Voila - problem solved with 3PAR!!  The zero detection and reclamation technology in a 3PAR array not only offloads the host from writing zeroes, but it also gives customers instantaneous reclamation of capacity with a smaller digital footprint (less capacity consumed) and faster performance. That's pretty cool and it's a trifecta that only 3PAR  has.

What is amazingly cool about today's vSphere announcement for 3PAR customers is that all three API elements, hardware assisted locking, full copy and block zeroing are already implemented in 3PAR's T and F series hardware platforms, and will be usable by the end of September with a firmware upgrade.

Our co-processor architecture really delivered for us this time. But it's been delivering the goods for our customers for a long time already. In virtualized environments our customers tell us they double their VM density, while cutting their storage capacity in half - all while reducing the amount of storage administration necessary by 90%. Those stats can be hard to believe, but when you look at what we delivered on the first day vSphere 4.1 was announced - when most people didn't even know we were working on it - it might make it easier for people to understand why. 

We take virtualized environments very seriously. People that don't know about 3PAR don't consider us to be a leader in virtualization, but when they find out the depth of technology we have and how well it works across our entire product line they understand we are leading in ways that really pay off for them. And the bigger they are, the bigger the rewards can be - especially after today.

He said, he said

Surprise, surprise.  After months after bad-mouthing their competitors for their capacity guarantee programs, EMC has done an about face and has announced their own, very restricted, guarantee program.

EMC offers a 20% capacity guarantee, as opposed to 50% from 3PAR's Get Thin Guarantee program. (FWIW, other vendors have also made 50% guarantees)  I guess EMC must be concerned they won't really be able to do it. Also, 3PAR's capacity guarantee applies to EMC customers, but EMC's program does not apply to 3PAR customers. What does that say?

(Video note: For readers unfamiliar with #storagebeers, it was an event that started in the UK, by the blogger Storagebod and it has become a meme in the online storage community.)

Info about Oracle's ASM Reclamation Utility

There were some problems with the links that were posted this week regarding Oracle's ASM Storage Reclamation Utility (ASRU) and 3PAR's Thin Persistence.

ASRU is a stand alone utility that compacts data in a specified Oracle disk group and then frees up space that Oracle no longer needs. Here is a short white paper on it (PDF).

A second joint white paper written by Oracle and 3PAR describes the interaction of both products and gives an example showing how they work together. 

Both of these white papers pretty fast reads, without hyperbole and do a nice job clarifying the differences between thin provisioning and storage reclamation. 

The ability to reorganize an Oracle database shouldn't have to be limited by the storage structures that database resides on, but its a common problem for DBAs.  In addition to the technologies discussed in these white papers, 3PAR's architecture is reservationless, which means storage resources (capacity) are not locked for future use by specific purposes or applications. 

Another 3PAR product that database admins find very useful is Dynamic Optimization, which allows data to be transparently re-striped across resources in an array - which is especially useful when adding new drives to an array, adjusting RAID levels and changing the quality of service for a particular volume.

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

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 anarchist apprehended in 3PARvaTAR's chunklet matrix

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

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

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. 

Customer says 3PAR's online upgrade process is "Easy as Pie!"

From a customer's blog:

In the last few weeks 3PAR released a major software upgrade for their arrays which enables a boatload of new features, including enhanced thin provisioning, autonomic provisioning, and RAID-MP. Today I performed the upgrade to Inform OS 2.3.1, and it went without a hitch and was quite easy. Unlike high-end arrays from Hitachi, EMC, and IBM, the upgrade process is not complex and took no more than an hour of time.

The whole blog post is here:   Thanks for the kind words,  Derek!

Click on the image below to find out about our capacity guarantee program. The program EMC doesn't want you to check out.

Is your storage vendor a doctor, a used car salesman or just without a capacity guarantee?

There's been a dysfunctional discussion of capacity guarantee programs over on Chuck's blog. There had been more sensible, independent discussions on the Storage Architect's blog, but that apparently wasn't good enough for EMC - a company without a capacity guarantee program of their own.  Unfortunately, Chuck decided to shut down comments on his post, citing an overload of vendor hash - which could continue to go on as long as there is breath left in any bloggers from Netapp.

Chuck's post poses the question - do you want to buy from a doctor or a used car salesman.  The suggestion he makes is that EMC treats you like a doctor while 3PAR, HDS and Netapp treat you like  used car salesmen. 

The doctor picture he used was this one:

Which reminded me of Scrubs - but of course there are other doctor images he could have used:

In case you've been shunning the news, this is Dr. Conrad Murray.

The used car salesman picture was pretty funny:

I'd suggest Chuck is using classic used car sales tactics: "Who loves ya baby? The warranty them guys offer don't protect you from nuthin'. Your engine will blow up the day after the warranty expires. All they want is your munny!"  

Still, seeing as how he was linking this image to 3PAR (in one way or another), I'd have hoped he would have used a picture like this instead:

You might not end up buying that car, but you should at least check it out.

 

Chuck characterizes capacity guarantee programs as not being in the customer's best interests. That would be true if 3PAR, HDS and Netapp wanted to increase the number of unhappy customers they have, but that is just CRAZY EMC thought diarrheaship:

 

Instead, I'm pretty sure we all want our customers to be very happy with their storage solution:

 

Yes, 3PAR's capacity guarantee is a way to attract customers, but it's much more than that - it's a way to back up our efficiency claims by putting our money where our mouths are:

 

RecoveryMonkey had a post recently about FUD and the ridiculous corner case claims storage vendors sometimes make about each other.   3PAR has been telling customers for years that our products are more efficient than theirs and we are now backing it up with our capacity guarantee. It's not FUD, it's not spin and its definitely not a corner case.

EMC skating in the rear with IBM, HP (and Oracle/Sun) at the back of the capacity garantee derby

As Mike Riley points out on his Netapptips blog today, I was not exactly a fan of Netapp's guarantee program when it first came out, but now I am an unabashed supporter.  Sometimes other vendors come up with excellent ideas. 

Yesterday HDS announced their capacity guarantee program and although it depends heavily on the capacity differences between RAID 1 and RAID 5 (which is a little cheesy), they offer a contract and appear to be ready to put back the program with more than a hand wave. That leaves HP, IBM and EMC (oh wait - and Oracle Sun) as the major storage players who aren't offering a capacity guarantee for customers making a technology refresh on storage.

 The question is - are these programs just marketing ploys?    Sure they are, just as any customer satisfaction guarantee for any product is a marketing ploy designed to hook customers - whether it's soap, kitchen knives, bass lures, vacuum cleaners, etc, but these ploys and the products behind them are targeted directly at data center operators that are tired of over-spending on storage. All are serious products from some of the biggest names in the storage industry and proven technology leaders.  3PAR's thin technologies (provisioning, conversion, persistence, reclamation and zero-detection) continue to lead our industry.

Depending on the applications and requirements of your data center some of these products and programs will be a better fit than others.  All of them should save you money on capacity purchases, but there are other things to consider, such as required software and services.  The details of each vendors' programs are different. That said, if you are offered a contract to reduce your storage capacity costs, that's pretty strong negotiating leverage with any other vendor - whether or not they offer a guarantee.  And even if you are not ready to make a purchase now, you might want to know how these programs work so you can be better prepared when the time comes.

To find out more about 3PAR's capacity program, click the image below. 

The difference between a rant and thought diarrheaship.

Its been pretty quiet in the storage blogosphere so far in 2010.  Innocuous stuff.  No smack ups.  We all got the message late last year that readers were fed up with vendor bashing.  Well, the truce apparently can't last forever - or can it?

One of the most followed storage bloggers who works for a very large storage company wrote a post today that he characterized as a rant.  It wasn't much of a rant, but there were certainly aspects of it that fit this part of the Merriam-Webster definition:

    to utter in a bombastic declamatory fashion.

I think of rants as having elements of dark humor and scathing, pointed accusations.  This bombast had neither, but it did have pieces of whine mixed in.  Whining about how a competitor of theirs, 3PAR had come out with a program that they don't have an answer to.  Whine-bast that their strengths should be considered as the only ones that matter.  A general whine-bast that they should be the only ones allowed to make the rules.  A load of baloney, but not anything truly disgusting.

    Sort of a thought diarrheaship piece.

Does anybody actually get anything out of reading such tripe?

3PAR Countdown: 3PAR's Thin Guarantee Program

The news is here.



Very easy & straightforward.  Start fat and move to thin, efficient storage on a 3PAR F or T Class system.

For more information on 3PAR's Thin Guarantee Program, check out the page on 3PAR's web site here.