Re: One arm vs. Two arm configuration

John Wobus <[email protected]>
Newsgroups gmane.comp.programming.load-balancing.general
Message-ID <[email protected]>
I used to favor two-armed, for the typical reasons.  My own preference 
dates back to the half-duplex Ethernet days, when that could be one of 
the influencing factors.

Recently, I've rethought this.  If the load balancer uses VLAN trunking 
and is attached on both sides to a single cloud of datacenter switches, 
possibly even to the same switch, then one-armed has some attractions.  
Going in/out of the same switch "feels" wrong in some ways, but it 
actually one less single point of failure as compared to two separate 
switches, and if the switch's capacity isn't challenged, then that's 
not an issue.  Furthermore, if you do have two physical connections and 
can channel them together, you get the same total throughput limit with 
some additional fail-soft capability (e.g., if an optical component 
goes) and flexibility in how the throughput is deployed, e.g. two 
full-duplex gigabit links channeled together could serve up to two 
gigabits of outbound traffic.  This ability to use the physical media 
capacity for either inbound or outbound traffic could possibly also 
apply to throughput licensing restrictions, e.g. if the device is 
licensed for 2 Gig of total traffic passing through.

All this could add complexity, but there are some interesting issues to 
weigh.  Parts of this depend upon your situation: if a lot of the 
networking in your datacenter is already established in a certain way 
and you are trying to fit in the load balancer, then that influences 
the overall design.

John

On Mar 30, 2009, at 12:41 PM, Bryan Call wrote:

> Most load balancing vendors support both a one armed and a two armed 
> configuration.  My question is what are the compelling reasons to go 
> with one over the other if you designing a network and don’t have 
> preexisting conditions that force you one direction?
>  
> Thanks,
>  
> Bryan Call - V.P. Of Technology
> Burstabit Media, Inc.
> 3130 West Maple Loop, Suite G-75, Lehi, UT 84043
> [P] 801-331-6945 Ext: 1103 [F] 801-880-8884
> AIM:
>  <unknown.jpg>THE INFORMATION CONTAINED IN THIS E-MAIL AND ANY 
> ATTACHED DOCUMENTATION IS INTENDED FOR THE USE OF THE ADDRESSEE ONLY, 
> IS CONFIDENTIAL AND MAY BE LEGALLY PRIVILEGED.  ANY DISSEMINATION, 
> DISTRIBUTION, COPYING, OR USE OF THIS COMMUNICATION WITHOUT PRIOR 
> PERMISSION OF THE SENDER IS STRICTLY PROHIBITED.  If you are not the 
> intended recipient, you must not disclose, copy, or distribute, or use 
> the information contained in this e-mail.  If you have received 
> this e-mail in error, please notify us immediately by return email.
>  
> <image001.jpg>_______________________________________________
> lb-l mailing list
> [email protected]
> http://vegan.net/mailman/listinfo/lb-l
> Searchable Archive: http://vegan.net/lb/archive
> http://lbdigest.com Load Balancing Digest
> http://lbwiki.com Load Balancing Wiki

_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.