Comments

1. Jeff Darcy says:

   14 May 2008 at 13:39

   Cherry-​​pick much? The fact that one spe­cial­ized HP brain-​​fart layered on top of FC seems excess­ively com­plex in no way serves as an indict­ment of FC in gen­eral com­pared to iSCSI. Why don’t you try com­par­ing apples to apples? Find some pro­pri­et­ary redund­ant switch-​​trunking solu­tion at the same band­width level, and see if it is free of such com­plex­ity. I guar­an­tee it won’t be. If iSCSI is so dead simple, why have you writ­ten four art­icles as a primer on issues such as TCP win­dow sizes and LACP? It’s just com­plex­ity you’ve grown com­fort­able with, so you pay it no mind, while com­plex­ity in some­thing you’ve never bothered to learn seems much scarier.

   If you want make an hon­est argu­ment about the com­plex­ity of iSCSI vs. FC (or any­thing else) don’t just pick one example of one fail­ure mode from one vendor. Get some data on the whole set of fail­ure modes exper­i­enced by real admin­is­trat­ors in a stat­ist­ic­ally valid sample of real data cen­ters (not just those you per­son­ally entered because they had already decided on the one tech­no­logy you know). Get fig­ures for time and cost of those fail­ures, and only then can you do a real comparison.

   BTW, I did some com­par­is­ons the other week of actual gig­abits per second per dol­lar for vari­ous inter­con­nect tech­no­lo­gies, and the win­ner was neither 10GE (which brought up the rear) nor FC but IB. Kinda blows the whole “eco­nom­ic­ally com­pel­ling argu­ment” for iSCSI out of the water, doesn’t it? It’s no less com­plex, it’s no more cost-​​effective, it’s just famil­iar to a dif­fer­ent cabal inter­ested in max­im­iz­ing the dol­lar value of their cur­rent skills instead of devel­op­ing new ones.

   Reply
   • Greg Ferro says:

     14 May 2008 at 14:05

     Well of course I cherry pick. I can (a) only speak to what I know, and (b) the iSCSI posts are a ‘stream of con­scious­ness’ and I am learn­ing as I write them (as stated in the first post).

     In a sense, I have stated the hypo­thesis that iSCSI is bet­ter than Fibrechannel and I am attempt­ing to prove that by mov­ing through a design process.

     WRT IB, I agree the IB is bet­ter than Fibrechannel. I haven’t said so here, but from what I know now, high intens­ity sys­tems should have IB and not Fibrechannel.

     I believe this sup­ports the anti-​​FCOE/​FC stance, since Fibrechannel is not good for low end, and not good for high end.

     I will attempt to work through the fail­ures in future posts. I look for­ward to you telling me if I am cov­er­ing the bases.

     Reply
2. Vinf says:

   15 May 2008 at 20:12

   Hi,

   thanks for drop­ping by my blog..

   as I think someone has already poin­ted out; my art­icle was more about how HP imple­ment FC within their vir­tual con­nect mod­ules. I’ll freely agree that it’s not simple and I’m not advoc­at­ing it as a fant­astic solu­tion, merely doc­u­ment­ing my find­ings (which seem undoc­u­mented by HP themselves!) — the HP VC mod­ule is essen­tially a port aggreg­ator (not a switch) so I don’t think it will ever be simple — and I’m pretty sure there is an equi­val­ent device in the Ethernet/​iSCSI world should you choose to imple­ment one.

   But it’s not really valid to say that FC is rub­bish because of this par­tic­u­lar vendor’s imple­ment­a­tion of an aggregator/​concentrator product.

   A nor­mal (non HP VC) FC imple­ment­a­tion into a server (or indeed an HP blade using a pass through mod­ule, or integ­rated switch) isn’t any more com­plic­ated than an equi­val­ent iSCSI imple­ment­a­tion.. you still need redund­ant HBA’s (NICs) con­nec­ted to a pair of redund­ant FC switches (Ethernet switches) and you can failover/​load bal­ance down paths.

   Horses for courses but from a man­age­ment (PHB) point of view using FC for stor­age and Ethernet for “net­work” keeps things isol­ated in terms of band­width to a host/​service, and thus sup­port­ab­il­ity — which is why FC keeps on truck­ing IMHO.

   FWIW I agree with you; I like the iSCSI archi­tec­ture and that I can use cheap, com­mod­ity GigE (or 10GigE) trunked together to scale my stor­age fab­ric hori­zont­ally rather than go cap in hand to the EMC or HP gods and pay through the nose for a SAN controller/​fabric upgrade everytime I need more through­put to my SAN(s).

   In terms of the sec­tion with “what does that mean..?” hope­fully it comes across in my post that the HP VC mod­ule is not a way to trunk FC ports together and get more over­all band­width (like you could do with iSCSI), it merely maps phys­ical on-​​blade HBA’s ports over a back­plane to an exit socket on the back of the chassis inter­con­nect mod­ule.… so basic­ally, it’s one level above a pass-​​thru con­nector in that you can adjust the over-​​subscription rate, but other than that it’s a bit dumb!

   Thanks

   Reply
   • Greg Ferro says:

     16 May 2008 at 07:16

     The thing that leapt out of your post is that con­fig­ur­ing Fibrechannel can be tor­tu­ous. Yet many dis­cus­sions with Storage people have the state­ment along the lines of ‘but Fibrechannel is so easy to use, you just plug it in and it works’.

     As I have been research­ing iSCSI I under­stand how com­plic­ated get­ting the Network designed and con­figured is.

     So if Fibrechannel is as com­plex as your art­icle shows, then I think that iSCSI is about the same.

     I also agree with you on using a sep­ar­ate net­work for stor­age, and I have sug­ges­ted that in my series of art­icles start­ing here” http://​eth​er​e​al​mind​.com/​2​0​0​8​/​0​4​/​2​9​/​i​s​c​s​i​-​n​e​t​w​o​r​k​-​d​e​s​i​g​n​s​-​p​a​r​t​-​1​-​s​o​me-basics/.

     Hopefully this might help people who really want to use proper net­work­ing, instead of Fibrechannel.

     Reply