Re: A backend per application - or backend per server group?
On Mon, Jan 21, 2013 at 7:30 PM, Sölvi Páll Ásgeirsson wrote: > Hello! > > I have a small question on 'idiomatic' haproxy configuration, when > serving multiple independent applications from > a a shared group of webservers and if I should define each > application/virtual directory as a dedicated backend or not. > I apologize if I'm missing something obvious from the documentation. No reason to choose one or the other ;-). I run two web applications on the same group of servers, however, each application has a dedicated backend that defines the same servers, there are individual checks for each application, allowing them to have different statuses. -- frontend vip00 mode http bind 0.0.0.0:80 acl is-apptwo dst 172.16.1.102 use_backend apptwo if is-fileac default_backend appone backend appone mode http option httplog option httpchk GET / HTTP/1.1\r\nHost:\ www option http-server-close balance roundrobin server http00 http00:80 check inter 2s server http01 http01:80 check inter 2s server localhost 127.0.0.1: check inter 2s backup backend apptwo mode http option httplog option httpchk GET /robots.txt option http-server-close balance roundrobin server http00 http00:81 check inter 2s server http01 http01:81 check inter 2s server localhost 127.0.0.1: check inter 2s backup -- I used different ports, but you could easily use the same server/port for each backend. The frontend uses an acl to sort out the backend, for my set-up I have a specific IP address for each app. You may very well use host headers etc. for your acls. The third server in each backend is a "sorry, we are down" page that is displayed only if all other servers in the backend are down.
A backend per application - or backend per server group?
Hello! I have a small question on 'idiomatic' haproxy configuration, when serving multiple independent applications from a a shared group of webservers and if I should define each application/virtual directory as a dedicated backend or not. I apologize if I'm missing something obvious from the documentation. The story: I'm doing a test deployment of HAProxy in front of a few IIS applications running on a small cluster of webservers. Each webserver hosts every application, so: haproxy -> [ webserver1(app1, app2, ...), webserver2(app1, app2, ...), ... ] My first approach was to define the whole cluster as a single backend, something like: -- frontend haproxy_test 172.20.253.20:80 default_backend ws_test backend ws_test option httpchk HEAD /status-check server www1 www1:80 check server www2 www2:80 check ... -- This approach, however, will not cause haproxy to remove individually failed applications from the load balance set, in the case where an application has failed but the server is otherwise OK. I then decided to define a backend per application and conditionally use that backend based on the URL, something like: -- frontend haproxy_test 172.20.253.20:80 default_backend ws_test acl ws_service1path_beg-i /service1 ... use_backend ws_service1 if ws_service1 backend ws_service1 option httpchk HEAD /service1/status-check server www1 www1:80 check ... backend ws_service2 option httpchk HEAD /service2/status-check server www1 www1:80 check ... -- Is the second approach the way to go? This complicates the haproxy config as the number of applications and servers grow, but, as far as I understand, increases the reliability of the frontend by not causing a single failed application to mark the entire frontend as offline. Would you rather make the /status-check of the root of the webserver be responsible for checking the health of every sub-application? Many, many thanks, regards, Sölvi Páll Á.
Re: Failed to persist on SSL session ID
Hi, Emeric Thank you very much. I tested again just now with the following two lines in backend section: stick-table type string len 32 size 30k expire 30m stick on ssl_fc_session_id The persistence on ssl sessions id worked well. Best Regards, Godbach
