Cloud infrastructures need to be efficient if they are going to compete. Money saved on operations is an annuity to cloud service providers that goes to the bottom line every day.
Terremark is a leading cloud service provider that delivers just in time infrastructure services, as described in this excellent post on the Boxed Ice blog today titled, The New Server Density Infrastructure. This post, written by a Terremark customer shows that Terremark is not only interested in driving down their own costs, but also in helping their customers be more efficient too.
If you are interested in a behind the scenes look at how Teerremark does it, you owe it to yourself to check out this case study on Wikibon today. This chart from the Wikibon study shows how Terremark derives its operational savings (click on it to see an enlarged version)
Savings from storage were projected to be 86%.
Guess who their storage vendor is? (The report says what equipment they are using). But one big clue is that it isn't EMC, as EMC's Chuck Hollis suggested back in July.
Cloud industry insiders know this stuff. We don't have all the cloud customers, but we have some of the most largest and most influential ones. Nobody really knows what changes cloud computing will bring to our industry, but 3PAR is very well prepared to be a key component of those infrastructures.
If you are at VMworld this year, please stop by our booth, #313, to see what all the commotion is about and why 3PAR storage is so popular for cloud computing.
There is no question that I'm going to get a lot of ribbing from friends of mine in the business when they read about this. After all, I was at Convergenet prior to it's acquisition by Dell and then again years later at EqualLogic when it was acquired by Dell and - as some have teased me about the inevitability of another Dell acquisition - it now appears that Dell intends to acquire 3PAR too. I only banged my head into the wall once when I was told about it.
At this point, it's all very new so I don't have much to say on the matter, but there are some things about this news that make me think it could be a very good thing. First, Dell clearly wants to be in the storage business, as they've proven the last several years. The EqualLogic acquisition was a starting point for them and they appear to be looking to become a much more serious enterprise storage player now with 3PAR's technology and products.
Second, the way I understand it, they want to have a bigger presence here in the valley, which is about time. As much as it might seem in Round Rock, the technology world doesn't revolve around Texas and it's important to have a corporate and development facility here.
Finally, I like both EqualLogic's and 3PAR's technologies and the people from both companies. Hopefully this will work out so that I'll be able to cover both in StorageRap because that would be fun - serious fun. But for now it's all conjecture and waiting to see what unfolds. You have to wonder about lightning that hits you three times.
# # #
The planned tender
offer described in this blog post has not yet commenced. The description
contained in this blog post is not an offer to buy or the solicitation of an
offer to sell securities. At the time the planned tender offer is commenced,
Dell will file a tender offer statement on Schedule TO with the Securities and
Exchange Commission (the "SEC"), and 3PAR will file a
solicitation/recommendation statement on Schedule 14D-9 with respect to the
planned tender offer. The tender offer statement (including an offer to
purchase, a related letter of transmittal and other tender offer documents) and
the solicitation/recommendation statement will contain important information
that should be read carefully before making any decision to tender securities
in the planned tender offer. Those materials will be made available to 3PAR’s
stockholders at no expense to them by contacting 3PAR’s Investor Relations
department at 510-897-4622. In addition, all of those materials (and all other
tender offer documents filed with the SEC) will be made available at no charge
on the SEC's website: www.sec.gov.
Statements in this
blog post that relate to future results and events are forward-looking
statements based on 3PAR’s current expectations. Actual results and events in
future periods may differ materially from those expressed or implied by these
forward-looking statements because of a number of risks, uncertainties and
other factors. All statements other than statements of historical fact are
statements that could be deemed forward-looking statements, including the
expected benefits of the transaction; management plans relating to the
transaction; any statements of the plans, strategies and objectives of
management for future operations, including the execution of integration plans;
any statements of expectation or belief; and any statements of assumptions
underlying any of the foregoing. Risks, uncertainties and assumptions include
the possibility that expected benefits may not materialize as expected; that
the transaction may not be timely completed, if at all; that, prior to the
completion of the transaction, 3PAR’s business may experience disruptions due
to transaction-related uncertainty or other factors making it more difficult to
maintain relationships with employees, licensees, other business partners or
governmental entities; that the parties are unable to successfully implement
integration strategies; and other risks that are described in 3PAR’s Securities
and Exchange Commission reports, including but not limited to the risks
described in 3PAR’s Annual Report on Form 10-K for the fiscal year ended March
31, 2010. 3PAR assumes no obligation and does not intend to update these
forward-looking statements.
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.
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.
London-based Ultraspeed has succeeded in the managed hosting business 13 years by being smart, opportunistic and service-oriented. A lot has changed during that time, especially customer expectations for uptime and how much customers rely on their hosting providers to respond quickly when needed. Web sites that are lucky enough to "go viral" can be a disaster if the hosting company's infrastructure is unable to adjust rapidly enough to meet demand.
In March, Ultraspeed opened their second data center in Amsterdam implementing a modular infrastructure design including multi-tenant 3PAR storage, VMware, Extreme Networks switches and customized servers. The highlight of their Amsterdam site is the ability to offer bi-directional DR services between London and Amsterdam using 3PAR's Remote Copy software. Ultraspeed is a member of 3PAR's Cloud-Agile program.
In this interview, conducted in February 2010, Jordon Gross, CEO of Ultraspeed and Michael Shanks, CTO joined us for coffee near their offices and talked about their company's history, it's technology, the challenges they face and how they expect things to shape up in the years to come.
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.
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.
The UK-based charity, Comic Relief, is once again using 3PAR storage as part of its IT infrastructure for raising millions of Pounds during it's nationwide Sport Relief campaign the weekend of March 19-21. StorageRap spoke with Comic Relief's Web Technology Manager, Charlotte Melen recently about the intangible benefits of working for Comic Relief and what technologies they use for their donations platform. Besides 3PAR, other key vendors include HP, Cisco, VMware and Oracle along with payment services from Paypal and RBS.
I couldn't help but wonder a bit this morning when I saw the WSJ story that Brocade was considering selling itself to the highest bidder. The article mentions that HP and Oracle would be potential acquirers, but the storage world is much more interesting and underhanded than THAT. If this story is true, there will likely be a great fight for Brocade as tech giants try to figure out whether it will impact their ability to make a buck 5 years from now.
Some of the giants appear to be going stack raving made, (Cisco, EMC, HP, Oracle) while others are content to watch this from the sidelines (IBM and Dell). The stack play is not aligned with the idea of open systems. Companies want to control customers by offering stacks of related products. IMHO, the stack play is good for vendors and bad for customers.
But it's the world we live in. The question this go -round is whether or not anybody will be able to sit out and watch Brocade get swallowed up. Here's my knee jerk breakdown of the pros and cons of the usual suspects making a move for Brocade:
HP: Brocade's business could pull up their existing SAN business, but its just as likely that their existing SAN business be a lodestone to a Brocade in HP expansion. The Procurve/Foundry mashup would claim severe casualties.
Oracle: I think this is the most ridiculous fantasy, but if it were to happen it would definitely answer the question about Oracle being in the HW business. Now imagine meetings with your Oracle sales rep.
EMC: Buy Brocade and kill it, make boyfriend Cisco ecstatically happy and piss off customers. Why not - nobody could stop it.
Cisco: No possible path to regulatory approval = see EMC above.
IBM: If IBM can't get this done, they really are just a services company.
Dell: It would finally get the networking company it needs to compete with Cisco, but imagine them trying to become an OEM vendor! Do you think people would mess with 'em? Really?
Microsoft: No overlap, great shock value and they don't want Oracle to have it.
IAC is an Internet media company with many well known properties. When I was on the east coast I stopped to see IAC's Marc Morales, who manages their security and infrastructure technology, and we spoke about how they are using 3PAR arrays, including thin provisioning, coast to coast remote copy (data replication), mixed workloads including Exchange and VMware and service.
The storage industry can be confusing - even to insiders. For example, people often compare 3PAR and Compellent because both companies are "newer" vendors working their way up against established competitors.
But that's about where the comparisons end. 3PAR arrays scale to performance levels that far exceed Compellent's. While it may be possible to attach the same number of drives to both arrays, when you push them both for total throughput, 3PAR crushes Compellent. With 100+ drive systems, there is no comparison. If you think you might need hundreds of drives, instead of less than 100, it's a slam dunk for 3PAR.
With less than 100 drives, our product lines overlap and that's probably where the confusion comes from because 3PAR's F-Class arrays compete with Compellent's. Our smallest F Class - the F200 scales from 16 to 192 drives and its bigger brother the F400 scales from 16 to 384 drives (with the addition of 2 more mesh active controllers). FWIW, you won't saturate a 3PAR controller by loading too many drives on it - the F Class controllers can handle 192 15K RPM drives with overhead to spare. Realistically, its probably not fair to Compellent to compare any of their systems to one of our quad controller F400s.
Nobody handles mixed workloads like 3PAR. Which means customers can put many different applications on our arrays and get excellent performance from their systems at very high disk utilization levels. Don't just take my word for it, see what our customers have said on TechValidate. (will require a login - it's not a 3PAR site). The key to this is the fine-grained allocations of storage combined with true wide striping - not based on pools and metas and hypers and such.
Both companies have delivered important storage virtualization innovations to the industry. 3PAR didn't invent thin provisioning, but we forced the issue in the industry and now it's a mandatory feature in all enterprise arrays. FWIW, our work in storage efficiency and utilization technologies continues and you can expect to see more from us in the future that allows customers to get the most from their capacity. We are always happy when customers dig deeper into this technology and compare our reservationless thin storage with any other vendor's thin implementations.
In Compellent's case, the delivery of Data Progression has been a key stimulus to the rest of the industry. EMC's FAST technology, due in its first release late this year is a clear attempt to catch up with Compellent. However, just as Thin Provisioning is not a 3PAR invention, the ability to move data between storage tiers is hardly a Compellent invention. When I was at EqualLogic, the product had the ability to move data automatically between tiers of storage spanning different systems. Their evacuate and replace capabilities rely on their automated tiering technology.
3PAR introduced it's Dynamic Optimization (DO) product in 2005, which redistributes data from one set of resources across an expanded or different set of resources. For instance, today a customer can add new drives to a 3PAR system and redistribute volumes across all the drives in the system using DO. They might do this for either capacity or performance reasons - or both. With storage capacity needs continuing to grow, it's important to be able to scale with performance and agility. When you add new drives to a 3PAR system, their capacity is a reservationless resources that can be used by any application, on demand - including for use as snapshots for existing or new applications.
Allegro is an online auction company in Poland and they are dominating the market in eastern Europe. Four guys from their technology team came to 3PAR HQ last week on a visit to several of their strategic vendors and they were nice enough to take the time to let me interview them. They take advantage of lots of open source software, and believe in running their operations on robust, flexible and scalable products from companies like 3PAR, Brocade and Cisco. The audio for this video is pretty soft, so you will probably need to crank up the volume to hear it.
*** Updated May 20, 2009 ** Infosmack podcasts are now available on iTunes here. If you have iTunes installed on your computer, click the link to open the Infosmack page on iTunes.
Infosmack covers a wide variety of data center topics, with a lot of talk about the storage world. This week's show covers Cisco/EMC acquisition rumors, Oracle/Sun's potential, Netapp, Brocade, Twitter and the new Star Trek movie. Click the player below to check out a few sound bytes from the show. If you want to hear more, click the link above for this week's episode.
I caught up with Tim Suttle from TechSoup Global for an interview recently where he spoke about their business, the services they provide to non-profits worldwide, and their technology infrastructure that includes a 3PAR mid range storage array, VMware Virtual Infrastructure, Microsoft IIS, SQL Server and Exchange, HP blade servers and Bluecoat packet shapers.
