Re: Load Balancing the Load Balancer
On 7/18/2015 3:50 AM, mlist wrote: Ok. Thank you. I read and tested little more haproxy. As now I use haproxy to balance web applications (http/https). As I can test, for web application load balancing "cookie insert" on all haproxy configuration can handle failover as client connect always with cookie inserted by ne of load balancer. So at failover the new contacted load balancer know where to route request and session works well. Probably also Sticky table works, but with cookie insert there is more independence between LBs. I read about clients problems with more cookie set, is this a real problem or a problem only for old browsers (agents) ? I ask you a last question: do you have experience with LVS L4 load balancer in front of Hhaproxy ? How you resolved VIP arp problem ? As I know the simple solution is to add VIP on lo interface, using arp_announce and arp_ignore. I'm using a CentOS 7 with kernel 3.10.0-229.7.2.el7 Can you point me in the right direction ? My haproxy installs uses pacemaker to handle failover. I have resources in pacemaker for the VIP, haproxy, and gratuitous arp for the VIP, so that other hosts on the LAN will instantly know that the IP address has moved. Pacemaker has constraints so that the arp and haproxy must be on the same host as the vip, and so the vip starts before everything else. Here is my full pacemaker config with the public IP address redacted: http://apaste.info/OU4 Thanks, Shawn
Re: Server IP resolution using DNS in HAProxy
On 07/17/2015 10:37 PM, Baptiste wrote: >> First would be resolution of SRV records and actually using the port >> supplied by the SRV record as the port for the server. I looked at the code >> and it doesn't seem like too much work, most of it would probably be >> changing the config stuff accordingly. > > You're right, this could be an interesting option. > Actually, we though about the SRV records to populate a full backend > server list with IP, name, port, weight using a single DNS query. Awesome! That's exactly what I want :) It's what I tried to express in the second part of my request, probably in a slightly weird way. >> The other one is... well you asked for it ;) so here it goes: it would be >> great to express in the config something like "resolve this name and use up >> to X servers from the reply". The backend then allocates X servers. >> Assuming that the initial lookup returns Y results, the (sorted) records >> get assinged to the first Y servers, the other X-Y servers get marked as >> down. Upon a new lookup, same procedure for a potentially changing value of >> Y. >> I realize this a pretty bold feature request for several reasons, but I >> have actually spent some thought on it think it might be doable without >> really violating any of HAProxy's design paradigms. I would also be willing >> to invest some time (code) into this myself. >> If you think this might be at least worth a discussion, I'd be happy to >> share some more detailed thoughts and it would be great to hear your >> thoughts on that, too. > > First, there are some limitations about creating servers on the fly in > a backend. > So instead, we propose you to pre-allocate servers by configuration > and then wait for the DNS to populate it. It's kind of what I meant, although I had something in mind where you say once "preallocate 20 servers for this backend" instead of listing 20 servers with the same hostname. But that's syntactic sugar and I would happily use the solution listing a server for each desired allocation. > I don't speak about a request per server, I speak here about one > request for the whole farm :) Again, awesome! That's what I'm looking for! > You go one step further than the design we have about SRV records to > populate the backend. > We thought using priority to decide whether a server is active or backup. > The advantage is that you don't need to reload HAProxy to change your X value > ;) Yes, perfect. And, what I tried to express above, HAProxy should mark some servers down if the number records received is less than the number of servers configured. > I would welcome a contribution about SRV record type. > That said, before this, I have to rewrite part of the response parser > to store the response in a real DNS packet structure instead of > keeping data in a buffer. Sounds good. I am not sure what you have in mind there or what parts of the code would be touched by that, so if you let me know when it's done I'll happily send some patches as a base for further discussion! Thanks, Baptiste, this get's me even more excited about HAProxy than I am already :) Cheers, Conrad -- Conrad Hoffmann Traffic Engineer SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany Managing Director: Alexander Ljung | Incorporated in England & Wales with Company No. 6343600 | Local Branch Office | AG Charlottenburg | HRB 110657B
RE: cookie prefix strange behavior
Hi Baptiste, as you can see using prefix or sticky table we found this invalid
cookie problem.
- Why without haproxy in the middle we do not have this problem ? why a browser
send an INVALID cookie ?
- How we can match absence of prefix ? can be done directly by haproxy ?
Roberto
-Original Message-
From: Baptiste [mailto:bed...@gmail.com]
Sent: venerdì 17 luglio 2015 22.09
To: mlist
Cc: haproxy@formilux.org
Subject: Re: cookie prefix strange behavior
Hi Roberto,
Look in your log lines, block 2, HAProxy says "--IN". 'IN' is for
cookie persistence.
'I' means the cookie sent by the client is invalid and 'N' means
HAProxy did not perform any action on persistence.
In such case, you could try to match that there are no prefix in your
cookie and do a redirect to a page which cleans up the cookie then
redirect the user to the login page.
Baptiste
On Fri, Jul 17, 2015 at 5:49 PM, mlist wrote:
> We found this behavior does not appears if we manually clean cookie in the
> browser. There is a configuration option to invalidate old cookie so client
> does not reuse this strange cookie not recognized by server ?
>
>
>
>
>
> Roberto
>
>
>
>
>
>
>
> From: mlist
> Sent: venerdì 17 luglio 2015 16.19
> To: 'haproxy@formilux.org'
> Subject: cookie prefix strange behavior
>
>
>
> We have compiled and installed haproxy version 1.6 dev2.
>
>
>
> If we use cookie insert all works, but if we use cookie prefix
> (ASP.NET_SessionId) or sticky table in which one have to specify cookie to
> be sticked, so using cookie name = ASP.NET_SessionId) we have a strange
> behavior.
>
>
>
> BLOCK1
>
> As you can see below, we open a browser and make a request, cookie prefix
> mechanism works well, we can login and use the application (all subsequent
> requests go on the some server).
>
>
>
> BLOCK2
>
> But if we open a new browser instance (chrome in this case, but this happen
> also if we open IE) the client uses a strange “ASP.NET_SessionId” cookie
> without haproxy prefix with back-end server, server does not ask client to
> set a new cookie.
>
> As of login, clearly, backend server does not recognize the cookie sent by
> client (haproxy do a plain roundrobin distribution, no cookie management was
> done) and so backend server return an error.
>
> Can this be a bug of haproxy or a bad configuration by us ?
>
>
>
>
>
>
>
> BLOCK1
>
> Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37322
> [17/Jul/2015:14:55:49.414] front_end_https~ back_end_https/SERVER1
> 2/0/44/18/64 302 467 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/ HTTP/1.1"
>
> Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37324
> [17/Jul/2015:14:55:49.484] front_end_https~ back_end_https/SERVER1
> 2/0/5/22/29 200 6449 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/login.aspx HTTP/1.1"
>
> Jul 17 14:55:52 ha_server1 haproxy[5604]: client_ip:37328
> [17/Jul/2015:14:55:52.284] front_end_https~ back_end_https/SERVER1 2/0/1/3/7
> 404 1424 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
> 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l}
> "GET /app1/segreteria HTTP/1.1"
>
> Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37344
> [17/Jul/2015:14:55:59.452] front_end_https~ back_end_https/SERVER1 2/0/1/2/5
> 301 448 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
> 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l}
> "GET /app1/anagrafenet HTTP/1.1"
>
> Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37345
> [17/Jul/2015:14:55:59.461] front_end_https~ back_end_https/SERVER1
> 2/0/1/32/36 302 435 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/anagrafenet/ HTTP/1.1"
>
> Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37346
> [17/Jul/2015:14:55:59.501] front_end_https~ back_end_https/SERVER1
> 2/0/1/27/31 200 6625 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/login.aspx HTTP/1.1"
>
> Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37359
> [17/Jul/2015:14:56:06.515] front_end_https~ back_end_https/SERVER1
> 1/0/4/64/69 302 6712 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {|946|Mozilla/5.0 (Windows NT 6.2; WOW64)
> AppleWebKit/537.36 (KHTML, l} "POST /app1/login.aspx HTTP/1.1"
>
> Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37361
> [17/Jul/2015:14:56:06.588] front_end_https~ back_end_https/SERVER1
> 2/0/1/175/179 200 28897 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/anagrafenet/default.
RE: Load Balancing the Load Balancer
Ok. Thank you. I read and tested little more haproxy. As now I use haproxy to balance web applications (http/https). As I can test, for web application load balancing "cookie insert" on all haproxy configuration can handle failover as client connect always with cookie inserted by ne of load balancer. So at failover the new contacted load balancer know where to route request and session works well. Probably also Sticky table works, but with cookie insert there is more independence between LBs. I read about clients problems with more cookie set, is this a real problem or a problem only for old browsers (agents) ? I ask you a last question: do you have experience with LVS L4 load balancer in front of Hhaproxy ? How you resolved VIP arp problem ? As I know the simple solution is to add VIP on lo interface, using arp_announce and arp_ignore. I'm using a CentOS 7 with kernel 3.10.0-229.7.2.el7 Can you point me in the right direction ? Roberto -Original Message- From: Baptiste [mailto:bed...@gmail.com] Sent: venerdì 17 luglio 2015 21.25 To: mlist Cc: Thierry FOURNIER; haproxy@formilux.org Subject: Re: Load Balancing the Load Balancer On Wed, Jul 15, 2015 at 1:14 PM, mlist 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. > > > 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 ? It does not work like this :) Persistence is based on your client and server capabilities as well as the type of protocol. IE, if you want persistence over POP protocol, then use source IP and a stick table. If you want persistence for a web mail application where clients are browsers and they can use a cookie, then use a cookie set by HAProxy. If you want persistence over a PHP or Java application, without inserting a new cookie, then store cookies generated by the application servers in a stick table you share between your HAProxy... etc... > >>> 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.) rsync or scp... I mean, it's not only a cfg file, but also your SSL certificates, your ACLs, MAPs, etc... Baptiste -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto.
