What does the Pacer, Yugo and Arbitrated Loop have in common?

Posted on February 11, 2010 | 1 Comment
What does the Pacer, Yugo and Arbitrated Loop have in common? You are probably running one of them in your datacenter. 

 
 George Crump recently blogged over at InfoWorld and asked, “do we really need Tier 1 storage”?  It struck me as interesting topic and while I disagreed with his reasons on where he put our solution, I tend to agree that the others mentioned are right where they should be.  In his article he specifically mentions some of the reasons both the monolithic array manufactures as well as the “modular guys” have “issues” and he zeroed in on performance and scalability.  Now his article was speaking about the front end controllers, but I think he missed out on pointing to the backend architectures as well.  I thought this would make a great blog posting 🙂  As you recall in my  “Performance Starved Applications” blog and my “Why running your hotel, like you run your Storage array can put you out of business” blog  I said that if you lined up the various different storage vendors next to each other about the only difference is the logo and the software loaded on the controllers.     

   
 Did you also know that if you looked behind those solutions you would see a large hub architecture – also known as our dear old friend “Mr. Arbitrated Loop”?  This is like running your enterprise wide Ethernet infrastructure on Ethernet hubs.  Can you imagine having to deal with them today?  For all those same reasons we dropped ethernet hubs like a bad habit, you should be doing the same thing with your storage array manufacturer if they are using arbitrated loops  in their backend storage.  Talk about a huge bottleneck to both capacity as well as performance at scale!!  So what’s wrong with Fibre Channel Arbitrated Loop (FCAL) on the backend?  Well for starters it doesn’t scale well at all.  Essentially you can only reference 126 components (for example a disk drive) per loop.  Most storage arrays support dual loops which is why you typically see a lot of 224 drive solutions on the market today, with 112 drives per loop – approaching the limit and creating a very long arbitration time.  Now, for those that offer more, it’s usually because they are doing more loops (typically by putting more HBA’s in their controller heads) on the backend.  The more loops on the backend, the more you have to rely on your controllers to manage this added complexity. When you are done reading my blog post, go and check out Rob Peglar’s blog post around storage controller “Feature Creep” called Jack of All Trades, Master of NONE !.  At the end of the day the limitations of FCAL on the backend is nothing new.   

  

About 4 years ago we at Xiotech became tired of dealing with all of these issues.  We rolled out a full Fabric backend on our Magnitude 3D 3000 (and 4000) solution.  We deployed this in a number of accounts.  Mostly it was used for our GeoRAID/DCI configuration where we split our controllers and bays between physical sites up to 10Km.  Essentially each bay was a loop all to itself directly plugged into a fabric switch.  Fast forward to our Emprise product family and we’ve completely moved away from FCAL on our backend.  We are 100% FULL, Non Blocking, Sweet and as pure as your mamas homemade apple pie Fabric with all of the benefits that it offers!!       

 My opinion (are you scooting towards the front of your chair in anticipation?) is unless you just enjoy running things in hubs I would STRONGLY advise that if you are looking at a new purchase of a Storage Array you should make sure they are not using 15-year old architecture on their backend !!  If you are contemplating architecting a private cloud, you should first go read my blog post on “Building resilient, scalable storage clouds” and applying the points I’ve made, to that endeavor.  Also, if you really are trying to make a decision around what solution to pick I would also suggest you check out Roger Kelley (@storage_wonk) over at http://www.storagewonk.com/.  He talked about comparing storage arrays “Apples to Apples”  and brought up other great differences.  Not to mention, Pete Selin (@pjselin) over at his blog talked about “honesty in the Storage biz” which was an interesting take on “Apples vs Apples” relative to configurations and pricing.  Each of these blog posts will give you a better understanding on how we differentiate ourselves in the market.         

  

Thanks,        

  @StorageTexan       

 

   

  

 

Advertisement
This entry was posted in Uncategorized and tagged , , , , , , , , , , , , , , , , , . Bookmark the permalink.

One response to “What does the Pacer, Yugo and Arbitrated Loop have in common?”

  1. Pingback: Data Progression? Extents of tiering? « Pjselin's Blog