On Thu, 9 Jul 2015 14:52:19 +0000 mlist <[email protected]> wrote: > Hi, > we see there is a new feature of HAProxy, peer and share table > (sticky-table). This peer feature can be used to have in synch stick cookie > so if one haproxy goes down the other can take over connections ?
Yes, the stick table remember and share each which is sticked to which server. You can use any criteria of the connexion, and of course you can use a cookie set by your application. In othe way, HAProxy can put his own cookie in the HTTP response and use it for the persistance. This mode is useful because you don't need to share the stick table and two "unconnected" haproxy can assure the high avalaibility without loosing the session affinity. > There is some HAProxy native feature to have HAProxy nodes configuration in > synch automatically or we have to rely on external tools like rsync manually > or as we do on LVS a cron job executing a script to synch configuration ? The stick table synchronisation is a native protocol. The configuration or map synchronisation must be done by external tools. > What is your choice ? The choice depends of each problem. HAProxy is very rich and permits to solve many LB and HA issues. Generally I prefer the simplest solution able to solve my issues. > For the connection limitation, you speak of frontend and per backand server > minconn / maxconn ? it isn't right to divide by n (n=numero ov HAProxy) > established total and per server connection ? also if this is not perfect > we'll have at most always (n * maxconn). This divide guaranty that your serveur will not exceed the limitation. If your server can process 100 connections, you tune the maxconn of your HAProxy to 50 per server. If the first lb process 75 connections, and the second process only 25 (because bad repartition in front of LBs) the first one is limits the connections, and the users requests will be latency, however the limited server does not reach 100 connections. > Also... I know that a major pros of L7 load balancing is to manage centrally > all phase of the communication (sticky, balancing, etc. ), but in Hybrid > Cloud thinking... is not right to can controll the connection up to a certain > point and so using some mechanism as L4 load balancer (as LVS) to put in > direct communication clients and final servers. At least for communications > not rely on sticky (persistent) session, one can alleviate periodic > extraordinary high connection rate redirecting connection for some services > (L7 acl) in a Public Cloud wihout weigh down our Private Cloud infrastructure > ? Probably there is some other way... We do not see at the moment... I don't understand the relation between L4 and L7 load-balancing, and the private and public cloud. Thierry > > > > -----Original Message----- > From: Thierry FOURNIER [mailto:[email protected]] > Sent: giovedì 9 luglio 2015 14.51 > To: mlist > Cc: '[email protected]' > Subject: Re: Load Balancing the Load Balancer > > On Thu, 9 Jul 2015 11:08:58 +0000 > mlist <[email protected]> wrote: > > > We have a question about Load Balancing the load balancer... We have as now > > 2 LVS load balancer in active / passive configuration with keepalived. > > We want to introduce L7 load balancer (HAProxy) in active / active > > configuration, so we have not only HA configuration but also load balanced > > configuration of load balancer. We think we can do that using the two > > active / passive LVS machine to load balancing request on 2 HAProxy > > machine, using correctly persistence (LVS) and stickiness (HAProxy) so > > application / session behave as expected. We do not found such solution on > > the Internet, do you think this is a bad design ? > > > Hi, > > this is the classic design, but make sure that the both haproxy > configruation are the same (mainly with the stick cookie name and > values). > > You must known that its not really possible to limit the amount of > connexions to your servers because the first haproxy don't known the > current connexions of the second haproxy. > > Thierry > > -- > Il messaggio e' stato analizzato alla ricerca di virus o > contenuti pericolosi da MailScanner, ed e' > risultato non infetto. > >
