The Hot Aisle Logo
Fresh Thinking on IT Operations for 100,000 Industry Executives
« Previous: What is an Economizer?
Next: VESDA Air Sampling Smoke Detectors »
Published by Steve O'Donnell on Wednesday 16th July 2008, 19:25 | Related | Filed Under

I have been thinking about why virtualization is now mature in lots of IT Infrastructure technologies…

  • Servers (VMWare, Parallels, Mainframe VM, Solaris Domains, AIX LPARS etc..)
  • Networks (Virtual Private Networks VPNs are endemic)
  • Firewalls
  • Desktops (VDI)

…but it just hasn’t got to mainstream in enterprise storage.

I think that I have worked it out. Enterprise storage is (almost) the last vestige of proprietary computing where a small number of storage controller vendors jealously manipulate and control the market. What do I mean by manipulate and control the market? Well remember when certain mainframe vendors used Fear Uncertainty and Doubt (FUD) to control the mainframe market? Remember when buying plug compatible hardware was risky (or so your mainframe account manager would suggest)?

Well enterprise storage vendors play exactly the same game today. Try breaking up your enterprise storage solution so that you can get best value, say attempt to buy the Fiber Channel switches and SAN from Cisco and the Storage Controller from EMC. You will fall off at the first hurdle because you can’t buy Cisco SAN switches directly, they come via Storage Controller vendors. Even if you could, I can hear the FUD whispering campaign already.

“We can’t support those configurations, the storage architecture is so complex that we must deliver the entire end-to-end solution. You are taking a huge risk and if it goes wrong you are on your own….”

So when you make a decision to go with one enterprise storage vendor, it is extremely hard to break away from them. Unless you just throw all of the old stuff out and replace it with a completely new SAN and new Storage Controllers, it is impossibly hard to get end-to-end support for a mixed environment. So most firms don’t, they stick with their old vendor and allow prices to creep up and service to drop because the alternative is just too difficult.

The answer to this conundrum is with us. Take the intelligence out of the Storage Controller and put it into the network! Use virtualization to commoditize the storage controllers and introduce competition into enterprise storage.

Some years ago I worked at Cable & Wireless and implemented IBM’s SVC in order to commoditize enterprise storage and to deliver operational benefits.

Here are those benefits:

  • Separation between the storage front end and back end allows data to be migrated transparently
  • Ability to deploy low cost storage (SATA) for all applications and only migrate them to higher performance storage if the performance is unacceptable – we can migrate them transparently with no outage
  • We can remove out of date or unreliable storage arrays with no down time
  • We can increase the capacity of storage for a host without any down-time
  • We can totally change the design of the back end without impacting the hosts
  • (Yes you can screw up the initial design and then change it later)
  • We can integrate multi vendor storage arrays with no host compatibility impact
  • We can snapshot between FC and SATA disks allowing Integration and User Acceptance testing to be performed at low cost
  • We can provide inter-site synchronous replication without expensive array based software such as SRDF
Why not share this article?
  • Digg
  • Technorati
  • LinkedIn
  • TwitThis
  • Facebook
  • NewsVine
  • StumbleUpon
  • Reddit
  • del.icio.us
  • Mixx
  • ThisNext
  • Slashdot
  • MySpace
  • Google
  • Live
  • E-mail this story to a friend!
  • Print this article!
  • feedmelinks
  • muti
  • YahooMyWeb
  • Blogsvine

Viewing 5 Comments

    • ^
    • v
    Absolutely correct.
    We need to decouple the ‘intelligence’ …but don’t complicate the storage server.

    What is needed is a ‘simple’, unmanaged, backend ‘storage brick’ which delivers raid - protected, fixed-size LUNs, dual ported controller, SATA, SAS or FC backplane. It would be based on a high volume, low-cost ‘open’ controller & come with empty disk cradles to save costs.

    I suggest that the remaining features….mirroring, volume management, migration, remote replication, etc. …i.e. much like those found in the IBM SVM… should reside on generic ‘virtualized’ storage server, in front of the SAN switch. One could easily add striping with additional RAID protection. This software is not difficult and should be open source….including the management software.

    So…one could create a number of such virtualized storage servers, driving a large number of storage bricks… through a 10Gbit switch, using iSCSI or (preferably) the new FCoE protocol.

    Given the new configurational flexibility, one should be able to easily create and tear-down such storage servers, choose to run at block or file level ... NFS, GFS, pNFS, Hadoop , etc.

    Do you see any problems….is there a market for such a ‘no brand’ , data center specific product ?
    • ^
    • v
    I think that there is definitely a need to move away from proprietary storage controllers that lock up the market today. There are a couple of areas in your comment that I probably don't agree with.

    Unmanaged anything is impossible to live with in a real large scale operations shop. The objective is to have the lights out and have instrumentation tell us remotely when there is a problem. If can also fix the problem remotely that is cool.

    Fixed size LUNS are a pain also as they are horribly inefficient in allocating storage space. What we want is the ability to attach a LUN and grow or shrink it without having to restart the host. Again this is preferable if it can be automated.

    I think we will be buying storage from Seagate and Hitachi direct as no brand generic disks cabinets are low value add. Perhaps we get to an Intel like situation where the disk makers package and the retailers label engineer.

    I think you are right that Fiber is dead (not everyone has got this yet) and Ethernet will win as it is cheap and made in enormous volumes. We will see Cisco dominate the switch space.

    The filesystem will become less and less important as attachment speed increases and we get efficient storage device drivers in hosts. Having lots of options is cool. Maybe we can have all of these filesystems available on a single piece of virtual disk and who cares how we get to the underlying data - Windows uses SMB, Unix NFS etc..

    Getting power management right is going to be important - how do we make sure we power only the disks that are needed? Like Copan which is great technology.

    Thanks for the comments

    Steve
    • ^
    • v
    Steve...thank you. This is an interesting discussion.

    The reason for fixed-size LUNs is to simplify the management of the ‘storage brick’ … and let the ‘storage server’ address the LVM issues and provisioning…including ‘thin’ provisioning. LUNs can be preset to the required granularity….but do not change.

    Sure… there can be some basic management built in (it is already there), but you should not need to use it on a ‘live’ system. This standardizes the approach with the rest of the features on the ‘storage server’ …. which under server-level virtualization is highly available, configurable and manageable.

    Everything in the storage brick is automated i.e. there is no need to control ‘raid groups’, cache … or anything else. Exported LUNs are protected against disk failures i.e. we provide transparent rebuilds, management of spare disks and the addition of new disks.

    You simply remove faulty disks or add more disks to obtain more LUNs. This firmware is basic to most of today’s controllers. All of the management and the ‘higher level features’ should go on the ‘storage server’, where they belong, closer to the OS.

    There is probably a good reason to tag LUNs with some new attributes …e.g. relative speed, level of protection, etc…. to enable that the storage server to make more intelligent LUN management decisions.

    The problem with FC is that there are only a couple of ‘related’ suppliers…. more or less a monopoly. Also, IB won’t make it as it is and will remain a single - source product.

    FCoE is FC (i.e. SCSI) and only the physical layer is different. The rest of the issue at the data center level is at the Layer 2 switch level. This is not complicated if you go with an end-to-end solution …i.e without bridging to FC.

    This requires the FCoE target driver in the above ‘storage brick’, which should be a relatively easy task to firmware or software developers with prior experience with FC.

    I think that it would be wrong to buy Cisco (or Brocade) gospel, based on the transitioning the data center, via the FC fabric.

    The high cost of Cisco Layer 2 switches is unacceptable….much like the big iron storage. Are they trying to buy time…. to ‘complicate’ the FCoE standard as it was done with endless FC standards in the past ... to maintain margins ?

    This will not work, as this time around there is a solid FC reference point and no lock-in at the chip level. Layer 2 switches should cost no more than $100 per port….since the new 10G silicon costs around $25 per port… and where is the complexity ?

    Any NEW data center infrastructure should be designed as an end-to-end FCoE solution. Some of the larger customers can force the issue and bypass Cisco at the Layer 2 switch level. …if not they deserve what they get.

    Please let me know if I am wrong.
    • ^
    • v
    Perhaps I wasn't clear - when I said Cisco will dominate, I meant at the layer 2 level. Vendors who try to derail perfectly good industry standards for commercial advantage should be avoided.

    The big message (and one that is starting to get through) is that the days of big bucks in Storage Controllers is gone. The value is moving into the network with virtualization.

    Steve
    • ^
    • v
    Steve,
    I agree with your observation on storage …. but to be fair, we don’t want the cost to move into switches.
    FCoE has little impact on Layer 2 switches as long as there is no need for bridging to FC. Layer 2 switches are relatively ‘simple’ and standards well defined … hopefully there will be many competing suppliers. I suggest that there is a lot more complexity in storage (even at the RAID level) and if we need to destroy the current pricing on storage, we should do likewise with L2 switches. I think that Google are already doing this….others will need to follow to compete in the data center space.
 

Trackbacks

(Trackback URL)

  • Bookmarks about Storage

    December 2, 2008 at 3:30 am

    [...] - bookmarked by 6 members originally found by loveallu89 on 2008-10-24 We virtualize servers, we virtualize networks, why ...

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus