Well, the announcement has been made and it’s official, Dell and Compellent are in talks over a “merger” which basically means Dell acquiring Compellent for around $27.50 per share.  The press release can be found here.  Even as recently as a couple of weeks ago, [...] ]]>

Well, the announcement has been made and it’s official, Dell and Compellent are in talks over a “merger” which basically means Dell acquiring Compellent for around $27.50 per share.  The press release can be found here.  Even as recently as a couple of weeks ago, Compellent were denying acquisition rumours.

Compellent’s share price has risen dramatically in the last couple of days (see chart), presumably as speculation rose on the possibility of the acquisition.  However, the current share price (and peak) are well above the suggested price from Dell and I guess that signifies a number of things.  Either speculators got greedy and overpurchased or they expected another bidder to come into the market and trump Dell as happened over 3Par.  But who would want to do that now?  HP surely wouldn’t bother as they have 3Par and have made it plain that 3Par is the foundation of their future storage plans for the next 10 years.  EMC are unlikely to even see Compellent as being worth their effort.  IBM have focused on their own new technology in the shape of the v7000 array.  Hitachi/HDS don’t acquire technologies and in any case they have existing modular products and no need of the Compellent technology.  What about Netapp?  Well, they have ploughed their own furrow and built a strategy around (their own definition of) unified storage; one array to rule them all, so perhaps not.

For those companies not in the storage business directly (like Cisco, Microsoft), then Compellent doesn’t seem a large enough acquisition to make any impact to their existing business.  So it looks like Dell might finally be lucky this time after being the jilted bride so many times before.

Compellent would fit easily into Dell’s server/storage business, meeting the requirements of medium sized businesses for which Equallogic is too small.  This of course would directly affect their EMC/CLARiiON reseller relationship, which in any case seems to have been on rocky ground over the last few years – more of a marriage of convenience than a partnership for life.  This still leaves Dell with a big gap at the top end of the market.  Theoretically they can resell Symmetrix/V-MAX (although I have no direct evidence or experience of V-MAX sales via Dell) but EMC may decide to break completely with their reseller agreement (and in any case I think the Symmetrix business for Dell wasn’t that large or profitable), leaving a big gap in the Dell storage portfolio.

Whilst ultimately for Compellent the Dell acquisition is likely to be a good thing, for Dell their storage strategy remains incomplete and that will be an ongoing problem for them to compete with the likes of IBM, HP and VCE in the stack wars.  One little suggestion; Compellent shareholders, when you get your cash, you may not want to put it into Dell stock…

Disclaimer: HP paid for my flights, hotels and meals during this trip.  I was otherwise not remunerated for my time or required to blog about the event.

The event was more a media/press session rather than a technical deep dive, [...] ]]> I’ve just returned from spending two days in Barcelona, attending the HP Converged Infrastructure Event.

Disclaimer: HP paid for my flights, hotels and meals during this trip.  I was otherwise not remunerated for my time or required to blog about the event.

The event was more a media/press session rather than a technical deep dive, although technical product managers were on hand and the assembled bloggers did exercise the product managers’ knowledge.  We were presented to on the new P9500 (the HP model of the HDS VSP) and on new blade systems.

Having seen the P9500 in a different skin only a week before, there weren’t any major surprises in the hardware.  For those of you who are interested in the hardware, Calvin Zito has a video here.  However we were shown a new software feature called APEX (Application Performance Extender) that enables QOS to be applied to servers (and on HP-UX, applications) for I/O on the P9500.  APEX seems like a great idea; a centralised server collects performance statistics on each server (using agents, unfortunately), then makes decisions on workload prioritisation that are then fed to the P9500 array in order to implement the QOS policies.

I do think however that APEX has some issues.  Firstly, response time is measured on the basis of the view of the host of that I/O.  Now I know it’s notoriously difficult (nay, impossible) to measure end-to-end performance in a SAN network and to determine how each component influences the I/O latency.  There could be multiple Fibre Channel switch hops, buffer credit congestion (especially in stretched fabrics), latency introduced by replication and so on.  Consequently the view the host sees of an I/O could be vastly different to the way the array believes it is servicing that I/O.  This could result in skewed I/O balancing, which isn’t good.  Hopefully as more information is made available, I will be able to provide more insight, suffice to say for now, that the concept is good; the proof will be in the detail.

Day 2 of the CI event was a 3Par roadshow.  3PAR is being pushed as the saviour for HP Storage and that can be seen by the fact that Dave Scott, who headed up 3Par, has been appointed General Manager for the StorageWorks business.  I personally believe 3Par is a great product, and with the momentum they’ve achieved so far with their R&D spend, it can only get better as HP publicly committed to significant increased R&D in the platform.  HP stated that only 11% of the external storage market comes their way and they intend to use 3Par to go after the other 89%.

The positioning of 3Par seems like a great move for HP.  The acquisition wasn’t a direct response to the Dell bid, but rather HP had been planning for some time to acquire 3Par and changes in management made that more easy to achieve as part of a Dell counter-offer.  But the confusing part of the day’s presentation was the omission of the P9500 array from the discussion.  A slide was displayed showing the evolution of the platforms for both traditional and service provider customers.  3Par is the only choice for service providers and is the major choice at Enterprise, mid and low-range.  XP (now P9000) is moved to the side and presumably only retained for mainframe or existing/specialist customers.

If 3Par is to become the premier HP storage product, there is going to need to be some serious thinking put in to converting customers.  Management (alerting, provisioning, billing etc) will all be different; there’s a whole set of migration strategies that will need to be developed; business models will change (new ways to calculate ROI/TCO).  Getting this information to customers rather than just discussing the tin will be HP’s greatest challenge and one I look forward to observing.

Meanwhile, here are a few pictures from the event.

In the first post, I discussed the shared storage model architectures typified by what we sometimes think of as Enterprise arrays, but I’ve called monolithic.  This term harks back to the mainframe [...] ]]> This is a series of post discussing storage array architectures.  Previous posts:

• Choosing Between Monolithic and Modular Architectures – Part I

In the first post, I discussed the shared storage model architectures typified by what we sometimes think of as Enterprise arrays, but I’ve called monolithic.  This term harks back to the mainframe days of large single computers (see Wikipedia definition), hence it’s use to describe storage arrays with a large single cache.  In the last 10 years we have seen a move away from the single shared cache to a distributed cache architecture built from multiple storage engines or nodes, each with independent processing capability but sharing a fast network interconnect.  Probably the most well known implementations of this technology have come from 3Par (InServ), IBM (XIV) and EMC (VMAX).  Let’s have a look at these architectures in more detail.

EMC VMAX

The VMAX architecture consists of one to eight VMAX engines (storage nodes) connected together by what is described as the Virtual Matrix Architecture.  Each engine acts as a storage array in its own right, with front-end host port connectivity, back-end disk directors, cache (which presumably is mirrored internally) and processors.  The VMAX engines connect together using the Matrix Interface Board Enclosure (MIBE), which are duplicated for redundancy.  The virtual matrix enables inter-engine memory access, which is required to provide connectivity when the host access port isn’t on the same engine as the data.  There are two diagrams in the gallery at the end of this post, one showing the logical view of the interconnected engines and the second showing how back-end disk enclosures are dedicated to each engine.

What’s not clear from the documentation is how the virtual matrix architecture operates, other than being based on the RapidIO.  I’m not sure if VMAX engines have direct access to the cache in other engines or whether the processor of connected engines is required.  In addition, can an engine access cache in another engine purely to manage throughput of the local host and disk connections? I’m not entirely sure.

3Par InServ

3Par storage arrays consist of multiple storage nodes joined through a high-speed interconnect.  They describe this as their InSpire architecture.  From 2 to 8 nodes are connected (in pairs) to a passive backplane with up to 1.6Gb/s of bandwidth between each node.  3Par use the diagram shown here to demonstrate their architecture and with 8 nodes, the numbers of connections can easily be seen.  I’ve also shown how connectivity increases in 2, 4, 6 and 8 node implementations.  InServ arrays write cache data in pairs, so each node has a partner.  Should one of the node pairs fail, the cache of the surviving partner is immediately written to another node (if one is present), so protecting the cache data.

The InServ and VMAX architectures are very similar but differ from each other in one subtle but important way.  3Par InServ LUNs are divided into chunklets (256KB slices of disk) that are spread across all disks within the complex.  So as an array is deployed and created, all of the nodes in the array are involved in serving data.  VMAX uses the Symmetrix architecture of hypers – large slices of disk – to create LUNs, with four hypers used to create a 3+1 RAID-5 LUN, for example.  As new engines are added to a VMAX array, the data is not redistributed across the new physical spindles, so data access is unbalanced across the VMAX engines and physical disks.  In this way, InServ has better opportunities to optimise the use of nodes, although within VMAX the use of Virtual Provisioning can help to spread load across disks in a more even fashion.  In addition, a fully configured VMAX array has up to 128Gb/s of bandwidth across the VMA, exceeding InServ’s capacity.

In my opinion the tradeoff here comes down to increased scalability with dedicated nodes versus the latency introduced when data isn’t located on the local node.  In the 3Par model, data is always being accessed across nodes.  In the EMC model, nodes only exchange data when the LUN’s physical disks aren’t located on the local node.  This leads to two problems.  Firstly, as more nodes are added, the number of node<->node connections increases exponentially.  For an 8-node array, there are at least 28 node to node connections (not including additional connections for redundancy).  This increases to 120 for 16 nodes (nearly 6-fold increase in connectivity for double the nodes) and nearly 500 connections for 32 nodes, to which VMAX can theoretically scale.  The second issue is that of diminishing returns.  As more nodes are added, more overhead is required to service data not found on the local node.  This leads to a situation where the benefits of adding additional nodes are so small to make it not worth doing.

IBM XIV

The IBM XIV array takes a different approach to node configurations that are directly connected to the underlying data protection mechanism of the hardware.  XIV uses only RAID-1 style protection, based on 1MB chunks of data known as partitions.  Data is dispersed across nodes in an even and pseudo-random fashion, ensuring that for any LUN, data is written across all nodes.  The architecture is shown in the XIV picture in the gallery at the end of this post.  Nodes (known in XIV as modules) are divided into interface and data types.  Interface modules have cache, processors, data disks and host interfaces.  Data modules have no host interfaces but still have cache, processors and disk.  Each module has twelve (12) 1TB SATA drives.  As data is written to the array, the 1MB partitions are written across all drives and modules ensuring that the two mirror pairs of any single partition do not reside on the same module.  Sequential partitions for a LUN are also spread across modules.  The net effect is that all modules are involved in servicing all volumes and the loss of any single module does not cause data loss.

Whilst XIV might be tuned for performance, there is still the inherent risk (however small) that a double disk failure results in a significant data loss, as all LUNs are spread across all disks.  Additionally the XIV architecture requires that every write operation must go through the Ethernet switches as data is written to the cache on the primary and secondary modules before being confirmed to the host.  As a consequence, overall bandwidth of a single module will be limited to the available network capacity, which is 6Gb/s for interface nodes and 4Gb/s for data nodes.  This value halves if either of the Ethernet switches fails.

Summary

The multi-node storage arrays on the market today are all implemented in slightly different ways.  Each has positive and negative points that contribute to the overall decision on which platform to choose for your data.  Whether any of them are suitable for “Enterprise” class data is an open question that continues to be the subject of much debate.  From my perspective I would want a “tier 1″ storage array to provide high levels of availability and performance, something each of these devices are capable of achieving.

Next I’ll discuss modular arrays and the benefits of dual controller architecture.

HP have been pretty [...] ]]> So there we have it.  A week after Dell announce their intention to acquire 3Par, HP put their cards on the table and trump the Dell bid with an updated offer of $24 a share.  This represents a 1/3 increase over the Dell $18/share offer.

HP have been pretty acquisitive in the storage arena over the last few years, acquiring LeftHand, Ibrix and others.  Why now would they want to acquire 3Par?

• Defensive positioning – 3Par being acquired by any of the major vendors could weaken HP’s position in the mid-to-enterprise market.  EVA is a fading product and unlikely to be the first choice for many organisations when choosing a mid-tier storage array (unless you’re an out and out HP shop of course).  Maybe HP felt they had to protect their existing mid-market position.
• Technology Replacement - As I just mentioned, the EVA looks long in the tooth.  Should HP replace or upgrade it?  Acquiring 3Par could be the answer to that problem – use InServ as the EVA replacement.  Goodbye EVA.  Alternatively, 3Par could be a replacement for the XP range of devices that HP OEM from Hitachi.  HDS are being brought closer to the Hitachi family (and making acquisitions of their own) so perhaps this is another defensive move on HP’s part, in case the Hitachi deal unravels.

Whatever the reason, HP & 3Par would create a large overlapping portfolio of similar products.  I’m not sure where the clear strategy would be, or what the marketing message would say; which product is best for enterprise, mid, SME and so on.

Final thought:  Will Dell rebid at a higher price?  Will anyone else come into the bidding?  Storage is clearly still hot acquisition territory.

Clearly the Farley Curse has struck again and for a mere $1.15 billion Dell plugs another gap in their storage portfolio.

Let’s face it, Equallogic [...] ]]> There’s nothing like a bit of surprise (ish) tech news to generate an off the cuff quick post; here’s today’s tidbit.  Dell are to acquire 3Par.

Clearly the Farley Curse has struck again and for a mere $1.15 billion Dell plugs another gap in their storage portfolio.

Let’s face it, Equallogic was good, but not high end enough.  3Par technology can span the medium and large enterprises leaving Equallogic to overlap the SMB market.

I think this could be great deal for both companies; 3Par get validation of their story and of their continued rise in customer base and access to even more customers.  Dell get to plug their higher end storage strategy with a great product and move further away from the EMC dependency.

What else could be coming up? A Dell Unified Computing Strategy based on 3par?  That would be interesting.

As I said, this is a quick post pending more thinking and reading.  In the meantime please give @3parfarley all the ribbing he’s requested, before he concedes and changes his twitter handle to @dellfarley….