Viability of nginx instead of hardware load balancer?

David Murphy david at icewatermedia.com
Thu Sep 24 23:57:03 MSD 2009


For that you would likely want the  DC to setup HSRP so  you would have port
fail over, which would allow for a re-arp, but preventing a "arpstorm"

David

-----Original Message-----
From: owner-nginx at sysoev.ru [mailto:owner-nginx at sysoev.ru] On Behalf Of
Gabriel Ramuglia
Sent: Thursday, September 24, 2009 12:32 PM
To: nginx at sysoev.ru
Subject: Re: Viability of nginx instead of hardware load balancer?

Another problem with the floating ip is locking arp. The routers on my host
lock the arp for a given ip to whichever mac address it first hears claiming
to have that ip, so I can't switch ips on the same segment between machines
without talking to them first (or presumably letting the arp entry expire)

On Thu, Sep 24, 2009 at 6:04 PM, Payam Chychi <pchychi at gmail.com> wrote:
> On Thu, Sep 24, 2009 at 8:46 AM, Gabriel Ramuglia <gabe at vtunnel.com>
wrote:
>> My experiences with spread were less than stellar, but instead of 
>> going into that, I'll just give a piece of advice. Spread first tries 
>> to communicate using multicast, and then falls back to broadcasting.
>> At my hosting provider, since their equipment didn't support 
>> multicast, this meant that, even though communications were only 
>> going between two computers and did not need to be broadcast to 
>> everyone, all communications were being broadcast to everyone on the 
>> subnet. It didn't take long before my hosting provider null routed my 
>> server. You can override this behaviour by telling spread to 
>> communicate using unicast, but this only works if there is only one 
>> destination for each source piece of information.
>>
>> Just something to keep in mind
>> -Gabe
>>
>> On Thu, Sep 24, 2009 at 4:04 PM, Barry Abrahamson <barry at automattic.com>
wrote:
>>>
>>> On Sep 17, 2009, at 5:49 AM, John Moore wrote:
>>>
>>>> It certainly does, thanks! Could I trouble you to explain a little 
>>>> more about your use of Wackamole and Spread? I've not used either of
them before.
>>>
>>> There is a How-to here:
>>>
>>> http://www.howtoforge.com/setting-up-a-high-availability-load-balanc
>>> er-with-haproxy-wackamole-spread-on-debian-etch-p2
>>>
>>> You are just using nginx instead of HAProxy, but the Wackamole and 
>>> Spread portion still applies.
>>>
>>> Scalable Internet Architectures (
>>> http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossna
>>> gle/dp/067232699X ) also has a section on how this works.
>>>
>>>> Also, is there any reason why a hosting company would have problems 
>>>> with such a setup (i.e., this won't be running in our hardware on 
>>>> our premises, but we have full control of Linux servers).
>>>
>>> Yes, you have to be a little careful here and ask questions up 
>>> front.  A lot of hosting companies segment their switches such that 
>>> each port is it's own VLAN which means you can't "float" IPs between 
>>> ports which is what you need for this to work.  If you tell your 
>>> hosting company what you are trying to do and tell them that you 
>>> need to be able to have IPs which are programmatically moved between 
>>> switch ports they should be able to tell you if this is possible or 
>>> not.  Some hosts may require you have some sort of "private rack" or
other upgrade to make this possible.
>>>
>>> Barry
>>>
>>> --
>>> Barry Abrahamson | Systems Wrangler | Automattic
>>> Blog: http://barry.wordpress.com
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> why not just ask for your own private vlan?  a private vlan will not 
> only create a boundry around your unciast/broadcast traffic but it 
> will also allow you to have your own ip unshared ip space (as appose 
> to shared vlan/shared ip space). Also, private vlan will give you the 
> frameworkf or moving your ip space anywhere you want inside the 
> network.
>
> In regards to floating ip, just hava them provision you on a layer2 
> segment, that will allow you to have multiple ports on their netowrk, 
> in the same private vlan, in different locations
>
>
> --
> Payam Tarverdyan Chychi
> Network Security Specialist / Network Engineer
>
>






More information about the nginx mailing list