>> 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. So if we'll use share stick table between 2 HAProxy LB we'll do not need cookie to maintain backend server sessions and if we'll use cookie we do not need to share stick table ? in the latter case how the surviving HAProxy know where to route the request to the correct backend server using some haproxy.cfg with some beckend server definition ? >> 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. I mean your choice to take in sync haproxy.cfg file between 2 or more haproxy LB (rsync, custom script, etc.) >> 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. I read something about that but I'm to go deep... some L4 LB (LVS) can work managing first connection and so redirecting communication to the backend, after that source and backend communicate directly without LB analyzing every subsequent packet. This is not so useful in L7 as the culprit is managing every packet to allow complex and correct management of all communication (cookie, stick, acl, ecc), but for some situation such escape can be usefull. I hope I'm clear... but this is no so important as now. Thank you in advance Roberto -----Original Message----- From: Thierry FOURNIER [mailto:thierry.fourn...@arpalert.org] Sent: mercoledì 15 luglio 2015 11.04 To: mlist Cc: 'haproxy@formilux.org' Subject: Re: Load Balancing the Load Balancer On Thu, 9 Jul 2015 14:52:19 +0000 mlist <ml...@apsystems.it> 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:thierry.fourn...@arpalert.org] > Sent: giovedì 9 luglio 2015 14.51 > To: mlist > Cc: 'haproxy@formilux.org' > Subject: Re: Load Balancing the Load Balancer > > On Thu, 9 Jul 2015 11:08:58 +0000 > mlist <ml...@apsystems.it> 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. > > -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto.
