openstack team mailing list archive

[John Dickinson <me@xxxxxx>]

The given options (DNS, SW load balancer, and HW load balancer) are all things I've seen people use in production Swift clusters.

As mentioned in another reply, DNSRR isn't really load balancing, but it can be used if nothing else is available.

One thing to consider when choosing a load balancer is if you want it to also terminate your SSL connections. You shouldn't ever terminate SSL within the Swift proxy itself, so you either need something local (like stunnel or stud) or you can combine the functionality with something like Pound or HAProxy. Both Pound and HAProxy can do load balancing and SSL termination, but for SSL they both use OpenSSL, so you won't see a big difference in SSL performance. Another free option (for smaller clusters) is using LVS.

You could also use commercial load balancers with varying degrees of success.

Swift supports being able to tell the healthcheck middleware to send an error or not (https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L185), so when configuring your load balancer, you can more simply manage the interaction with the proxy servers by taking advantage of this feature.

I would strongly recommend against using nginx as a front-end to a Swift cluster. nginx spools request bodies locally, so it is not a good option in front of a storage system when the request bodies could be rather large.

--John





On Jun 7, 2013, at 1:24 AM, Heiko Krämer <info@xxxxxxxxxxxxxxx> wrote:

> Hey Kotwani,
> 
> we are using an SW loadbalancer but L3 (keepalived).
> DNS round robin are not a load balancer :) if one node is done, some connections will arrive the down host that's not the right way i think.
> 
> HTTP Proxy are an option but you make a bottleneck of your connection to WAN because all usage will pass your proxy server.
> 
> You can use Keepalived as a Layer3 Loadbalancer, so all your incoming responses will distributed to the swift proxy servers and delivered of them. You don't have a bottleneck because you are using the WAN connection of each swift proxy servers and you have automate failover of keepalived with an other hot standby lb ( keepalived are using out of the box pacemaker + corosync for lb failover).
> 
> 
> Greetings
> Heiko
> 
> On 07.06.2013 06:40, Chu Duc Minh wrote:
>> If you choose to use DNS round robin, you can set TTL small and use a script/tool to continous check proxy nodes to reconfigure DNS record if one proxy node goes down, and vice-versa.
>> 
>> If you choose to use SW load-balancer, I suggest HAProxy for performance (many high-traffic websites use it) and NGinx for features (if you really need features provided by Nginx). 
>> IMHO, I like Nginx more than Haproxy. It's stable, modern, high performance, and full-featured.
>> 
>> 
>> On Fri, Jun 7, 2013 at 6:28 AM, Kotwani, Mukul <mukul.g.kotwani@xxxxxx> wrote:
>> Hello folks,
>> 
>> I wanted to check and see what others are using in the case of a Swift installation with multiple proxy servers for load balancing/distribution. Based on my reading, the approaches used are DNS round robin, or SW load balancers such as Pound, or HW load balancers. I am really interested in finding out what others have been using in their installations. Also, if there are issues that you have seen related to the approach you are using, and any other information you think would help would be greatly appreciated.
>> 
>>  
>> As I understand it, DNS round robin does not check the state of the service behind it, so if a service goes down, DNS will still send the record and the record requires manual removal(?). Also, I am not sure how well it scales or if there are any other issues. About Pound, I am not sure what kind of resources it expects and what kind of scalability it has, and yet again, what other issues have been seen.
>> 
>>  
>> Real world examples and problems seen by you guys would definitely help in understanding the options better.
>> 
>>  
>> Thanks!
>> 
>> Mukul
>> 
>>  
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Mailing list: 
>> https://launchpad.net/~openstack
>> 
>> Post to     : 
>> openstack@xxxxxxxxxxxxxxxxxxx
>> 
>> Unsubscribe : 
>> https://launchpad.net/~openstack
>> 
>> More help   : 
>> https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp