Disqus - Latest Comments for RZB

Re: From the Gazeta Wyborcza, ‘Missile Shield Talks: How the Bush Team Lost Poland’

RZB — Sat, 19 Jul 2008 07:48:23 -0000

Ms Rice does not have the background to understand Poland.

Poland is very unfortunate to be wedged between the two most uncivilized nations in Europe and has learned a bitter lesson from its ‘friends’ during the last war, at Yalta.
Yet it did not surrender, continued to bleed but had the inner strength to be the main factor in the downfall of communism.

By the fact that Poland is willing to host the missiles, proves that it is the only true friend of the US within the EU. Why not place these missiles closer to Iran… ask Italy, Germany or southern France and lets see the reaction.

US should make sure that Poland can defend itself…even briefly…in the time of need.
How is this different from Israel?

Otherwise, the US should not ask Poland to take on such a great risk. Poland deserves to have at least one generation to grow up in peace.

Re: ONStor Claims that Cougar Storage features Power and Cooling Efficiency

RZB — Sat, 19 Jul 2008 04:34:35 -0000

I think that we need to re-think this a bit.

ONStor power saving is minimal as the ‘low power’ design relates only to the controller chassis. The difference is X86 architecture vs MIPS RISC….perhaps 100 watts difference in total controller power consumption for the equivalent performance.
Other features such as fan speed control and the controller operational temperature range seem to be much the same.

The bulk of power consumption is still in the disks and the associated JBOD chassis …. and it will be much like any other competitive system. Disks will require much the same operational environment on all systems and require stabilized temperature environment.

Having said that… architecturally, the ONStor is a nice system.

Re: We virtualize servers, we virtualize networks, why not virtualize storage?

RZB — Sat, 19 Jul 2008 03:51:01 -0000

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.

Re: We virtualize servers, we virtualize networks, why not virtualize storage?

RZB — Fri, 18 Jul 2008 07:26:15 -0000

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.

Re: We virtualize servers, we virtualize networks, why not virtualize storage?

RZB — Thu, 17 Jul 2008 03:11:25 -0000

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 ?