There was a lot written last week surrounding VMware's release of vSphere 4.1. Netapp appeared to have a lot to say, but it was confusing to figure out what they were really talking about. I think I've got it now.
It's unusual for a company to be invited as a centerpiece of high-visibility festivities and then mysteriously decide not to follow through. It would be like getting complimentary tickets and backstage passes from
Lady Ga Ga herself, telling all your friends about it and then not going. It it does make one wonder. Why wouldn't you do whatever it takes to be included in VMware's big summer announcement party? Well, if you're Netapp, the answer appears to be - "Being there is over-rated. Just make sure everyone thinks you were." Call it Photoshop for PR or call it keeping your poker face, it's a mash up of a blown opportunity and opportunistic courage.
The excitement for VMware's storage partners was concentrated in two areas: VAAI (vStorage API for array integration) and SIOC (Storage I/O Control). The initial release of VAAI includes new SCSI block storage commands that allow the arrays to offload host systems from redundant, resource-consuming tasks. SIOC is a method for managing I/O queues to create more fairness in accessing storage resources. Netapp issued a press release last week in conjunction with the vSphere 4.1 release, but it was for their Virtual Storage Console, not for the support of the storage enhancements in vSPhere 4.1. There was a flag waving mention of VAAI:
"Additionally, NetApp is supporting the new VMware vStorage APIs for
Array Integration (VAAI) capabilities that offload data management tasks
from the host server to the storage system. This can free up host CPU
cycles for better performance and increased virtual machine density."
That's not exactly saying anything, but its more than they had to say about SIOC, which was zilch.
The bottom of the release directs readers to Vaughn Stewart's blog for more info. Apparently, Netapp's PR department left the rest of the innuendo up to Vaughn - a diligent and loyal Netapp employee who understands that sometimes a vendor blogger doubles as a PR bagman. It looks like I need to add a new chapter to Vendor Blogging with Dummies.
You have to dig into the comments to get some of the details, but Vaughn's blog does a decent job explaining that Netapp is working on delivering VAAI functionality in
Q4 2010. Now, that's not all that late considering its only 6 months or so away, but as a privileged insider to VAAI development, it's not a great showing either. In fact, it wouldn't surprise me if
some of the companies who were not in the program, such as Compellent, HP, IBM and Xiotech come out
with VAAI plug-ins before Netapp does. As for 3PAR, we will have
our VAAI plug-in available in September as part of a maintenance
release. We didn't have a lot of time to develop VAAI functionality after gaining access to the APIs in early 2010, but we fast-tracked the
development of it in order to make the announcement.
As much as I admire Vaughn's hutzpah for stepping in to carry the load that others at Netapp should have, there were a few problems with what he said. First was the absurd statement that "
SAN is attempting to be more NAS-like". There is so much wrong with that statement that it's difficult to find a place to start. Who or what is SAN? Is VMWare SAN? Is the T10 SCSI standards committee SAN? Is SAN the being an embodiment of SAN the block protocol? Is there a virtual reality thing going on here? And what is NAS-like anyway? Does it have anything to do with the size of one's beak or the way particular vowels resonate in the sinus cavities? Or is it like racing the back roads in a used chevy? Whatever Vaughn meant, I tend to dislike the imprecision of technology anthropomorphism.
The second thing Vaughn said was "As for the first release of VAAI... These features ALREADY EXIST in NFS." Really, block zeroing? That is a function developed for EagerZeroThick volumes, which are only supported on VMFS datastores, not NFS datastores. Perhaps we will see that change in the future, but for now its SAN only.
Hardware assisted locking is a way to allow smaller granular locking for VMFS and addresses an issue with VMDK-level operations in a shared datastore. Because NFS puts VMDKs in separate datastores, which are locked independently, hardware assisted locking is unnecessary for NFS. In other words, its a SAN only function because the current NFS datastore architecture doesn't need it.
The other API in VAAI is Full Copy. This VAAI API appears to be functionally equivalent to a Netapp utility called RCU (Rapid Cloning Utility) that was included as a function in their Virtual Storage Console. It is not, however, something that exists in NFS, unless Netapp wants to give that feature to all it's NAS competitors. As a vSphere function, Full Copy will be available to all vendors that implement the VAAI APIs. It will be interesting to see what differences there are as far as programmatic control using the VAAI plug-ins, vendor-specific consoles and Powershell.
3. Compellent has the most full-featured implementation.
4. It will use expensive SSD resources for low-priority apps.
5. It won't work for VMFS data.
6. EMC is shipping it.
7. Tiering+SATA+SSDs will eliminate FC/SAS drives.
8. It only works with SSDs.
9. You will end up thrashing data across tiers.
10. You have to buy it before you can determine if it will work for you.
3PAR's sub-volume tiering, Adaptive Optimization (AO), comes with a lot of features that make it much better than what competitors say. It doesn't require SSDs and it's not for everybody, but if you need it, it will do the job.
A couple weeks ago, one of the major storage vendors had two major problems to resolve after one of their arrays suffered a firmware bug-induced failure at one of their cloud (email) service provider customers. They had to:
Help the customer get back to normal service levels after they had become unacceptable.
Confront a public relations problem after it was exposed by a leading storage publisher.
Meanwhile, their service provider customer had four major problems to resolve:
Get service levels back to acceptable levels.
Communicate to their customers what the problem was and how it was being addressed.
Re-engineer a solution to avoid the same happening again.
Credit customers for not delivering against SLA terms.
A vendor employee tried to address their public relations problem this way in his blog:
"OK, I'll take the blame for this -- sort of. We pride ourselves in putting a lot of thought into our customer designs. I'd argue that we're really, really good at it as well.
But not everyone is 100% sure of how their application will grow over time -- unfortunately, we're not psychics. And, let's be honest, not everyone necessarily wants to pay for redundancy we like to put into our designs.
We don't always get to directly engage all the time, either -- with products such as the (blanked out), most of this stuff moves through the channel. Somebody calls up one of our partners, says that they want to buy one of our products, and one gets sold -- and a lot of product gets sold that way."
I understand the desire to explain how messes become messy, but I'm not sure why he felt the need to speculate that his company's business partners or that their customer's budget were key elements of the problem. That is tantamount to saying, "All of our (blanked out) customers could have the same thing happen to them too." Anybody who has ever been close to one of these melt-downs knows there are many variables involved - including vendors underbidding each other and shaving elements from their bid in order to win the business.
From a distance, it looks like the vendor's response to the customer was good, although there apparently were some issues with failure notification from the array when the event occurred. I wouldn't call these sorts of things "Perfect Storms", but there are unfortunate scenarios where multiple things go awry. All vendors have these sorts of bad days, which serve as painful learning experiences. Unfortunately for customers, it's one of the ways vendors improve their customer support processes.
The customer also wrote in his blog, explaining the situation to their customers:
"Our SAN vendor analyzed the system logs for the event and determined that the service processor failure occurred due to a unique bug in the specific version of firmware on the system. Our vendor performed an emergency upgrade. The newer version of firmware includes a fix for the bug. We are taking additional corrective actions to make certain that there is enough spare capacity on the SAN. This will assure it performs without performance degradation in the event of a single hardware failure."
The reparation sounds reasonable, but it's not what I would call best of breed either. I'll explain why in the remainder of this post.
The old trusted dual controller just can't keep up
The explanation the service provider gave to their customers was only half correct. Yes, the failure in one controller was due to a firmware bug -and yes, all vendors find out about some of them at customer sites - but the inability of the surviving controller to handle the workload was another matter altogether.
The major defect of all dual controller designs for service provider applications is the uselessness of write cache when operating in degraded mode on a single controller.
When a dual controller array has a controller failure, all traffic is failed over to the surviving controller. However, this controller can't afford to place writes in cache because if this controller also fails any un-flushed writes in cache would be lost- making the recovery process all the more painful. As a result, the throughput of the controller degrades significantly because writes now take several orders of magnitude longer to process as each write must be completed at the physical disk level, instead of in fast cache memory. When you consider the sort of read/write ratios involved with an email application (heavy writes), it's not surprising to hear that it took 32 hours for the system to get caught up. I suspect that if the surviving controller had been able to use write cache, the customer might have experienced some amount of service level problems, but not nearly as bad as they suffered.
Write performance during array component failures is an important point that many customers give insufficient weight to when making their purchases. Public service providers certainly need to understand this. The exact same scenario - controller failure and subsequent drop in service levels - could certainly happen to a traditional data center customer, but the ramifications of this scenario are not as ugly as they are for a multi-tenant public service provider.
This case is a perfect example of how an older architecture is incapable of meeting the requirements of the new cloud service business model. If you are a cloud service provider reading this and wondering if you might have a similar exposure to a controller failure (including 3PAR customers with dual -controller arrays), my advice is to review what you have and start thinking about what you should expect if you have a controller failure and how you might want to deal with it on both a short-term and long-term basis. Best of breed cloud storage should not include dual controller arrays.
Their solution is to buy more and utilize it less
One of the identified corrective actions is having "enough spare capacity on the SAN", which in this case involves installing a second array. Without knowing the inside scoop, it looks like the idea is to split the workload across the two arrays so that if a controller failure occurs in either array, the performance drop won't be as noticeable. The array that doesn't suffer the failure will keep working as expected and the array that has the failure will only have half the load to deal with.
There are two primary problems with this "fix"
Performance will still suffer on the array with the controller failure
The I/O load will continue to increase over time
You are always going to have performance degradation of some sort when you can't use write caching, unless you are only reading data - which isn't the case here. It is flat out wrong to assume that a performance problem will not occur. Regardless, with the new two-array SAN, whichever system has the controller failure should be able to get caught up much faster than the 32 hours this customer had to wait. Of course, the customer's capacity and I/O load will almost certainly increase over time, and as that happens, the strategy of splitting the load between two arrays loses its effectiveness.
Along with adding the controllers, they are also certainly adding disk drives, and some notion of what "reasonable" utilization limits should be for them. The problem with limiting utilization as a best practice is that it puts the stamp of approval on inefficiency - not only for capacity utilization abut also for the power and cooling required to support all those underutilized drives. Most legacy arrays have built-in inefficiencies in the way data is laid out on disks, making it virtually impossible to achieve uniform utilization across all disk resources. The result is uneven consumption of disk capacity, as well as uneven I/O service levels among different disk groups, which is another variable in how much performance degrades following a controller failure in a dual controller array.
Finally, the customer now has two arrays to manage, including multipath connections, SAN zones, and all other aspects of the configuration, which all contribute down the road to change management complexities. The result is a net drag on administrator effort and an increased TCO.
How many do you need?
A true best of breed solution would address the root-cause deficiency in the array's design, without creating additional management and cost burdens to the customer. Obviously, more than two controllers are needed. But how many controllers does a cloud service provider need in an array? The answer is at least three. Why? Because when a single controller fails, there can still be two surviving controllers working together, mirroring their cache contents, and performing fast writes to cache memory. That said, controllers are usually packaged in pairs for redundancy purposes, which means that the most likely configurations will have four controllers.
If you compare a single quad controller array with two dual controller arrays there are some key advantages that immediately jump out:
No or limited loss of performance after a controller failure
All drives and cache can be used to service all workloads
Managing a single array significantly reduces cost and complexity
A better recipe for maintaining performance levels
The next question is; "Is there a suitable quad controller array that the customer could have used instead of the two dual controller arrays they have?" Yes, 3PAR's F400 or T400 arrays are both quad controller arrays. The disk drives in these arrays can be either SATA or FC, or a mix of both types if the customer wanted to implement tiering. Product information of the F400 can be found here, and the T400 here.
However, simply putting four controllers in an array does not necessarily guarantee that they will be able to sustain write caching if one of them fails. The array must have the ability to remap and re-mirror the write cache contents of all four controllers to the surviving controllers following the loss of a controller. It's an interesting geometric sort of problem: There are four controllers, each with their own cache and cache that is mirrored from the other controllers in the array. All cache contents, including mirrors, need to be distributed evenly across all controllers to avoid congestion and load imbalances. All cache content, including mirrors needs to be accounted for within the array so that if a controller fails, the other controllers will be able to identify all the surviving original and mirrored copies of data. For cache data that has lost either a primary or mirrored copy, a second (new) copy needs to be made. Finally, the amount of data in cache may need to be re-leveled (decreased) to fit into the degraded cache capacity (3 controllers instead of 4).
The software for doing this in a 3PAR array is Persistent Cache. Product information on Persistent Cache is here (PDF)
I made a 9 minute last year video describing how Persistent Cache works. Here it is again. Thanks for watching.
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.
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 .
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.
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.
Its all over the news today. STEC's stock is getting hammered because their largest customer, EMC, is delaying orders. I feel for the folks at STEC, its difficult being a supplier to industry behemoths like EMC. When realities don't meet expectations, things can crater in a hurry.
There is nothing wrong with flash SSD technology, it's simply a matter that the market demand hasn't ramped yet. Some of the EMC bloggers have chided me for my position on SSDs, but today's news pretty clearly vindicates what I've been saying all along:
Flash SSDs are still considered expensive and are difficult to justify
Customers can't use them intelligently or flexibly yet
The market for customers needing extreme low latency, is not ramping that quickly
The situation is changing gradually. Prices for SSDs are coming down, but there still needs to be a lot of work done by storage system vendors to flexibly use them - and this is going to continue to take time. EMC has said they will release their first version of FAST this year, but almost everybody is looking at future versions of FAST to get the sort of functionality they can actually use. Compellent's Data Progression software has the basic ability to move data on and off SSDs, but the number of SSDs that can be used per system is small and their sales are far too small to make up for what EMC has failed to deliver on. SSDs have a bright future, its just going to take longer to flourish.
So where is 3PAR on SSDs? We think they will be an important technology in the future and we are working on integrating them into our products in a way that will allow customers to take advanatge of their capabilities. In other words, we're going to have them, but we're not going to sell something that costs a lot of money if our customers can't leverage them.
(Author's note: a couple typos in the next to last paragraph have been corrected, which should make things clearer -mf 8-08-2009)
It's funny how things work in the stoblogosphere. The Anarchist goes after my reservationless post and steps in a pot hole of tchit and in the process brings blogging newcomer Enrico Signoretti - a Compellent reseller from Italy - out of the woodwork to howl about the stench.
A couple things about what Anarchist and Enrico said brought to light that people get 3PAR and Compellent confused sometimes. Mostly these are financial people - but lately Anarchist seems to be looking for a new career as a financial analyst as the long slow decline of Symmetrix sets in. Anyway, I felt compelled to point out the differences between 3PAR and Compellent, which got Enrico's attention again and like a true defender of the faith he posted on some things he felt I mis-spun. God, I love blogging. And for money's worth - it is much, much richer than twittering.
Of course, as things go, I recognized some pretty lame Compellent FUD that they have been feeding their resellers for some time now about 3PAR's hardware, which reminded me to post about it because it's actually a huge advantage for us. FWIW, I'm betting that no one from Compellent shows up to challenge it as they seem content to let their FUD-fed resellers do the dirty work for them. Clever, but in the end it's not a nice thing to do to guys like Enrico (have them carry you FUD for you). To be clear Enrico, you are OK with me, my gripe is not with you.
3PAR has been using Intel processors from it's inception in it's storage controllers. There are a lot of good things about this and it's heartwarming to see EMC finally move to Intel on V-Max after all these years. It takes them a long time to get caught up and of course, the target continues to move in front of them - despite their hollow declarations of parity. Oh yeah! And implementations don't matter either!
The proprietary stuff in Compellent's FUD has to do with our ASIC, which is a co-processor for storage functions. While Intel platforms have some great advantages (that we recognized 10 years ago), there are some shortcomings to using them - like segregating different types of I/O traffic - especially small database I/O versus long sequential streams. The ASIC in our system does this superbly, which is why our mixed application workload is so freaking good (along with our reservationless true wide striping.) Why would you want to buy a different array for each major application - that's a waste of resources.
But why would Compellent tell their resellers that 3PAR runs on proprietary hardware, when we run on Intel with a kick-ass co-processor to handle the hard stuff? It wouldn't be the usual disingenuous marketing tactics they like to accuse EMC of - would it?
The other thing our ASIC does is compute parity. Why on earth would you want to tie up your main controller processor doing this? Because you don't have the architecture to do it in a co-processor.
Which brings me to some of Hu Yoshida's recent posts. Hu has obviously been fed some things from the engineers in Odawara, Japan when he recently wrote about about the trade offs you have to make when you select your allocation size. Now I don't have much beef with Hu personally because he is a pretty good guy, but this post really only exposes the limitations of Hitachi's engineering team. Yes, there are trade offs in every design decision, but there are are an almost infinite number ofways to pay for them. 3PAR's design inception is still way ahead of the rest of the industry because people that designed high end cluster server systems for SUN designed the 3PAR architecture. I don't want to be too snide, but it's pretty clear that Hitachi has does not have the same sort of perspective on clustered systems design.
Whew - rant over. I'm going for my first coffee of the day now.
Enrico Signoretti is a blogger from Italy (la docle vita!) who just started posting in English. He has been on Twitter for some time and has expanded his voice to the ww storage blogosphere with his Cinetica Blog.
He is passionate about his business as a reseller for Compellent. People might wonder why I would refer to a blog from a Compellent reseller and the reason is that we have had a discussion about 3PAR and Compellent there that started with my last blog post - which was inspired somewhat by his first English blog post, which reminded me of a few things that I thought needed mentioning. That's blogging for you!
There are never enough bloggers who are passionate about their work! I also think it is very brave for a guy for a guy from Italy to talk about EMC the way he does. He obviously follows the storage blogosphere and knows what the big battle royale of storage blogging is like. It can be intimidating, but that hasn't stopped Enrico from jumping into the fray.
People may wonder why Compellent themselves did not respond to my previous blog posts. Et Tu - Compellent?
