Hi, It's weird you don't need the store-response. Test it as best as you can to avoid any issues later.
There is no way to monitor the peering, as far as I know. If a peer is unavailable, it means both haproxy can't reach each others. so you may have a bigger issue to fix before :) This is a multi-master way of working: each haproxy notifies its peers about the changes it made into the table. cheers On Sun, Feb 10, 2013 at 9:36 PM, Alex Davies <[email protected]> wrote: > Hi Baptiste (apologies!) > > I did some testing with this, it actually seemed that stick store-response > was not needed. > > I think this is working, at least it works in my test environment. Will test > it for real shortly. > > One question I had - what is the best way to "monitor" this peering? I didnt > see anything in the logs about the peers, nor anything in the haproxy status > URL. Obviously if the peering were to silently break down, this would be bad > for me! > > Thanks, > > -Alex > > > On Fri, Feb 8, 2013 at 4:22 AM, Baptiste <[email protected]> wrote: >> >> ahah, you can call me Baptiste :) >> >> You miss a "stick on cookie(PHPSESSID)". >> Also consider using the same expire delay you have on your application >> server. >> >> And last but not least, add a "peers" section (and a peer directive on >> the stick-table definition) where you provide all your HAProxy server >> IPs in order to get the table of each HAProxy synchronized. >> >> then you're done. >> >> Baptiste >> >> On 2/8/13, Alex Davies <[email protected]> wrote: >> > Hi Willy, >> > >> > Thanks for your suggestion. I'm guessing you mean something like this >> > backend: >> > >> > backend x >> > balance roundrobin >> > stick-table type string size 32k peers other_haproxy_server expire >> > 24h >> > stick store-response set-cookie(PHPSESSID) >> > >> > If I understand you correctly, you are saying that this will only mean >> > that >> > sessions become "persistant" once PHPSESSID is set. So, to translate >> > into >> > practicality, as long as the login page creates the relevant cooke (and >> > it >> > does not subsequently change once logged in), this should work nicely. >> > >> > Thanks, >> > >> > -Alex >> > >> > >> > >> > On Sun, Feb 3, 2013 at 7:59 AM, Baptiste <[email protected]> wrote: >> > >> >> Hi, >> >> >> >> the only way you could do what you want for now is using stick tables >> >> (and haproxy 1.5-dev17). >> >> You can learn the Set-Cookie from the server and match the Cookie in >> >> the table from the client. >> >> That way, all the request from a user will be sent to the same server, >> >> from the first to the last one. >> >> >> >> Today, haproxy is able to hash a HTTP header for load-balancing, so a >> >> configuration like: >> >> balance hdr(Cookie) >> >> could do the trick, but it means that ALL clients cookie to >> >> load-balance. And worste, since there is no phpsessionid cookie on the >> >> first request, there are chances that the first and the second >> >> requests won't be routed to the same server. >> >> >> >> I guess it would be possible soon to have a: >> >> balance cook(PHPSessionID) >> >> but it won't fix the sticking issue between first and second request >> >> since the cookie is not present in the first request. >> >> >> >> So if you really want using the algorithm method, you must be able to >> >> share cookies between your backend servers, only lucky people will be >> >> able to get authenticated. >> >> Well, maybe there are some dirty tricks like managing a farm for >> >> cookie-less clients and configuring PHP to learn an unknown session on >> >> the fly. >> >> >> >> Baptiste >> >> >> >> >> >> On Sun, Feb 3, 2013 at 2:03 AM, Alex Davies <[email protected]> wrote: >> >> > Hi All, >> >> > >> >> > What is the best way to configure haproxy to hash based on an >> >> > application >> >> > cookie (such as PHPSESSID), in a way that is consistent (meaning >> >> > multiple >> >> > haproxy servers will route to the same backend), ideally including >> >> > the >> >> > ability to weight backends (the configuration would clearly have to >> >> > be >> >> the >> >> > same on these different boxes). >> >> > >> >> > appsession obviously allows this for a single HAProxy server, but it >> >> seems >> >> > from the documentation that it generates a server based on the hash >> >> > at >> >> the >> >> > start of each session, so if the same session hit a different but >> >> > identically configured haproxy server it would end up with a >> >> > >> >> > Thanks, >> >> > >> >> > -Alex >> >> >> > > > > > > -- > Alex Davies > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the sender immediately by e-mail and delete this e-mail permanently.
