DISQUS

RZB · 1 year ago

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 ?

thehotaisle · 1 year ago

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

RZB · 1 year ago

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.

thehotaisle · 1 year ago

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

RZB · 1 year ago

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.