Re: haproxy 1.5dev7 server check failed with IPv6
Check for ipv4 www server is OK, but ipv6 is not work which result http status 503 I telnet to ipv6 www server , which is OK. The error log is : [ALERT] 090/162901 (2069) : Cannot bind to source address before connect() for backend The config is : global maxconn 100 user root group root nbproc 1 tune.bufsize 16384 log /dev/log local3 crit stats socket /var/run/ha_stats_socket defaults option accept-invalid-http-response option accept-invalid-http-request log global mode http timeout client 60s timeout connect 60s timeout server 120s no option httpclose option clitcpka backlog 40960 option dontlognull no option abortonclose no option allbackups no option forceclose no option nolinger no option redispatch frontend ap bind 80 maxconn 100 use_backend wwwipv4 if . use_backend wwwipv6 if . backend wwwipv4 source 0.0.0.0 usesrc hdr_ip(X-Forwarded-For) server SERVER 192.168.36.2:8080 maxconn 2 check fall 3 rise 3 inter 30s fastinter 1s downinter 1s option http-server-close option http-pretend-keepalive backend wwwipv6 source 0.0.0.0 usesrc hdr_ip(X-Forwarded-For) server SERVER 2012:af:fffd::2:8080 maxconn 2 check fall 3 rise 3 inter 30s fastinter 1s downinter 1s option http-server-close option http-pretend-keepalive 在 2012年3月31日 上午11:49,Delta Yeh 写道: > I use transparent proxy, so maybe my transparent proxy setting is > wrong with IPv6. > Thanks for your reply. > > 在 2012年3月30日 上午4:20,Sander Klein 写道: >> Hi, >> >> >> On 29.03.2012 16:44, Delta Yeh wrote: >>> >>> Hi, >>> It seems haproxy failed to do server check with IPv6. >>> The top is like: >>> browser---haproxy-www server >>> >>> I did the following tests: >>> 1. IPv4 http server with server check, it works >>> 2. IPv6 http server with server check, I get http 503. After disable >>> server check, I get http 200. >>> 3. IPv4 and IPv6 server with server check, only see IPv4 check packet. >>> I get 503 when access WWW with IPv6. I get 200 when access WWW >>> server with IPv4. >> >> >> Are you sure it's not an config error on the webserver side? I've been >> running dev7 for quite some time and do a lot of IPv6 checks. Never had any >> problems with it. >> >> Greets, >> >> Sander >>
Monster Energy hats, Monster hats
Monster Energy Hats was on his head at the time, and also another girl, who was, Isupposed, from the strong likeness between them, her sister. She had the same mass of soft brown hair. But to me her monster energy hats appeared almost common place in comparison. Monster energy hats Monster energy caps --- posted at http://www.serverphorums.com http://www.serverphorums.com/read.php?10,471922,471922#msg-471922
red bull hats low classes, fix around second relate after seeing
gram according to Nuo can truely of success' spreading Edward's accident that a fireball Shu brings is big. Want to know although the fireball Shu just fastens magic trick for the fire of low class most , , once success of spread, represent a gram depend on Nuo F through can the feeling know and manipulate a chemical element, but this one step, in fact is an important meaning one step, that 42 lately- recruited apprentices, up to now return have no one person can succeed of exceed this one step. Is at the thought of here, Edward is without extra trouble unbearable to is a burst of to disappoint, sighed tone, picked up two personal letters from the table of in front, turned round to leave room. Just fix around second house of in, 3410 people seat on the floor and see appearance just in the contemplation, moreover, also more than ten individuals round the Long just fixs a second body side around, is just fixing around of instruction under, study a few time immemorial magic tricks of red bull hats low classes, fix around second relate after seeing Edward's arrival of add to work harder more, small and ingenious place, making to hear Edward has to admire, either. --Red bull Hats Red bull caps --- posted at http://www.serverphorums.com http://www.serverphorums.com/read.php?10,471923,471923#msg-471923
wholesale dc hats however
Debt settlement can save you thousands of dollars,wholesale dc hats, but can also be a complicated process if you are working alone. A professional team can really simplify the process of reducing your debt, and will only charge you for services after the settlement are complete. You should know the basics of this service before committing to it as a financial plan, however, since it may not be right for your personal financial situation. ---DC Hats DC caps --- posted at http://www.serverphorums.com http://www.serverphorums.com/read.php?10,471924,471924#msg-471924
How do I correctly self-manufacture custom snapback hats?
I understand Ill need fabrics/templates and sewing guidelines along with plastic snaps,etc. where can i find these pieces and how do i make it all come together in good quality? --- Snapback Hats Snapback Caps --- posted at http://www.serverphorums.com http://www.serverphorums.com/read.php?10,471925,471925#msg-471925
Re: haproxy 1.5dev7 server check failed with IPv6
Hi, On Sat, Mar 31, 2012 at 05:03:28PM +0800, Delta Yeh wrote: > backend wwwipv6 >source 0.0.0.0 usesrc hdr_ip(X-Forwarded-For) ^^ I was sure I would find an IPv4 "source" statement. It's impossible for haproxy to establish a connection to an IPv6 server using and IPv4 source address (and conversely). >server SERVER 2012:af:fffd::2:8080 maxconn 2 check fall 3 rise 3 inter > 30s fastinter 1s downinter 1s Also transparent mode does not work in IPv6 right now. Its addition to the kernel is recent and we have to check if the API changed and if so, how. What I'd strongly suggest is to simply forward to your server normally and have your server log the X-Forwarded-For address. Alternatively you may want to check if you can implement the PROXY protocol in your server and have haproxy send it. Regards, Willy
Re: output of haproxy 1.5-dev8 -vv
Hi Aleks, On Wed, Mar 28, 2012 at 05:40:08PM +0200, Aleksandar Lazic wrote: > Hi, > > what are you thinking to add all -D flags to -vv output? You have all those you specified in the make options. The only ones you don't have are the implicit ones that the Makefile decided to add for you based on the build options (which are reported). > When I call -vv I don't know if the SPLICE is integrated int the build > or not? You have "OPTIONS = USE_LINUX_SPLICE=1 USE_PCRE=1", which means that if you do make OPTIONS="USE_LINUX_SPLICE=1 USE_PCRE=1", you'll get the same binary. I find this much more useful than storing some random -D flags which are not always easy to reinject into the make command line (which is the reason why it was changed to be done this way). Regards, Willy
Re: haproxy with keepalived
On Wed, Mar 28, 2012 at 09:47:47PM +, Jens Dueholm Christensen (JEDC) wrote: > Hey Baptiste > > You're very welcome - hopefully others can use it. > > At least there was a (somewhat) reasonable explanation and easy fix to the > problem once I figured out what was happening. > > I re-read my previous post, and realised that one thing was a bit unclear: > > The homepage I linked to mentioned that the rp_filter setting also *might* > have something to do with correcting the problem. > I cannot verify this, as I already had turned off rp_filter in my setup. > > Your milage may also vary depending on distribution - Debian, Suse, RHEL, > CentOS etc etc - I have only tested with RHEL. > > At least I'm sure that this strange behaviour is limited to linux-flavour > OSes. FreeBSD (that I also use) does not exibit the same behaviour. Clearly on linux it's common to have ARP working in a "strange way" for some people, because its IPv4 stack works exactly like the IPv6 one, with addresses having a host scope, so any network card is able to respond to an ARP request. I've been using Julian Anastsov's patchset for more than 10 years on 2.2 then 2.4 to add the arp_announce, arp_filter, arp_ignore etc... sysctls. Now they're in 2.6 by default but I too think that the default values are confusing, so one of the very first things I do when I install a system is to switch them. The second one is to set ip_nonlocal_bind :-) Regards, Willy
Re: tcp resets on reload haproxy
Hi Dominik, On Fri, Mar 30, 2012 at 03:52:20PM +0200, Mostowiec Dominik wrote: > Hi, > Thanks for the response. > > I have another problem: > > 11:20:58.713922 IP siege_host.46589 > loadbalancer.8123: Flags [S], seq > 1849604553, win 14600, options [mss 1460,nop,wscale 4], length 0 > 11:20:58.713951 IP loadbalancer.8123 > siege_host.46589: Flags [S.], seq > 121266129, ack 1849604554, win 14600, options [mss 1460,nop,wscale 6], length > 0 > 11:20:58.714687 IP siege_host.46589 > loadbalancer.8123: Flags [.], ack 1, > win 913, length 0 > 11:20:58.714894 IP siege_host.46589 > loadbalancer.8123: Flags [P.], seq > 1:151, ack 1, win 913, length 150 > 11:21:00.717226 IP siege_host.46589 > loadbalancer.8123: Flags [F.], seq 151, > ack 1, win 913, length 0 > 11:21:00.717254 IP loadbalancer.8123 > siege_host.46589: Flags [.], ack 1, > win 229, length 0 Did you notice that your request packet (the 4th) was lost on the network ? That's one reason why we always want to set timeouts above 3 sec (generally 4 or 5), so that it covers one TCP retransmit. I guess you captured on the siege_host (you did not have -vv nor -S so some info are missing) ? Also, you shoul be careful with the system config on siege_host, as it does not have SACK enabled, which makes things worse when your network is lossy. This packet loss issue is the reason for the pause you observe since the request never reaches haproxy. If you increase your siege timeout above 3s you'll see that many requests take 3s to be processed due to the retransmit and that other ones still fail. You really need to find what is causing these losses and to fix that, it's impossible to run a benchmark on a lossy network! Check your switches and your NICs. Ensure you're not running with an old bnx2 NIC with an old firmware. BTW I have a few comments about your config : > global > maxconn 163937 What's the reason for this magic number ? > user haproxy > group haproxy > daemon > nbproc 16 Wow 16 procs ! I don't know what you intend to do, but it will generally not bring anything and might even reduce the performance. > defaults > log global > modehttp > option httplog > option dontlognull > option forwardfor > retries 1 > contimeout 1s < 3s timeout, see above > clitimeout 33s > srvtimeout 33s > grace 7s grace serves no purpose these days, especially if all instances share the same setting (the goal was to make some instances stop before other ones to fail external health checks). I see that you have no default maxconn, so your frontends will still be limited by the default maxconn (2000). (...) > Haproxy is started with "-n 163937 -N 163937" options. OK so -N sets it. Still strange value anyway. > I attached stats for test when nbproc is set to '1'. Hmmm the load was very low : 691 MB/20k conn = 34kB per connection At peak you reached 34kB*850 sess/s = 29 MB/s ~= 250 Mbps It's very concerning that you're experiencing network losses at this rate. Just a hint, it's more likely that the losses are located on the siege host or between it and the network than on the haproxy host, because when you run haproxy on a lossy machine you generally observe failed health checks, which you didn't have here during the test. > Somthing is wrong with my configuration ? Not particularly, let aside the strange numbers. Regards, Willy
Re: Can we perform rsp_add for specified hosts?
On Sat, Mar 31, 2012 at 06:00:05AM +0200, Baptiste wrote: > Hi, > > You're trying to insert a RESPONSE header if a REQUEST header exists. > It may not work, either never match or always match. > I mean that your acl has an undetermined state when called. > You should match something from the response to be sure it works. In practice it will never match because when you get the response, you don't have the request anymore. That's why we'd like to finish the move from ACL to patterns and have sticky ones. In the meantime if you need to do this for only one (or very few) hosts, you can switch the request to different backends depending on the hostname and perform the rewrite in the backend. Regards, Willy
Re: PROXY protocol and "balance source"
Hi Alex, I could finally reproduce your issue with 1.5-dev8. You won the jackport, this bug has been there forever since "balance source" was introduced in 1.2.11 six years ago ! The IP address pointer was erroneously mapped to IPv4, which is wrong. The attached patch fixes it. BTW, if your stud really emitted : "PROXY TCP6 :::127.0.0.1 :: 52460 7302" Then it is wrong since the second field ("::") is the destination address and it cannot be zero. It's possible that it logs the IP it's listening to instead of logging the IP the client connected to. This is not critical since it's not used here, but dst-based ACLs or transparent forwarding would not work. Cheers, Willy >From 5dd7fa1f6b8eec57bff8ff4630afd7eb3e837b5e Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Sat, 31 Mar 2012 19:53:37 +0200 Subject: [PATCH] BUG/MEDIUM: balance source did not properly hash IPv6 addresses The hash of IPv6 addresses was not properly aligned and resulted in the last quarter of the address not being hashed. In practice, this is rarely detected since MAC addresses are used in the second half. But this becomes very visible with IPv6-mapped IPv4 addresses such as :::1.2.3.4 where the IPv4 part is never hashed. This bug has been there forever, since introduction of "balance source" in v1.2.11. The fix must then be backported to all stable versions. Thanks to Alex Markham for reporting this issue to the list ! --- src/backend.c | 19 ++- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/src/backend.c b/src/backend.c index 39ee58b..f6e2d73 100644 --- a/src/backend.c +++ b/src/backend.c @@ -497,7 +497,6 @@ int assign_server(struct session *s) clear_target(&s->target); if (s->be->lbprm.algo & BE_LB_KIND) { - int len; /* we must check if we have at least one server available */ if (!s->be->lbprm.tot_weight) { err = SRV_STATUS_NOSRV; @@ -538,19 +537,21 @@ int assign_server(struct session *s) switch (s->be->lbprm.algo & BE_LB_PARM) { case BE_LB_HASH_SRC: - if (s->req->prod->addr.from.ss_family == AF_INET) - len = 4; - else if (s->req->prod->addr.from.ss_family == AF_INET6) - len = 16; + if (s->req->prod->addr.from.ss_family == AF_INET) { + srv = get_server_sh(s->be, + (void *)&((struct sockaddr_in *)&s->req->prod->addr.from)->sin_addr, + 4); + } + else if (s->req->prod->addr.from.ss_family == AF_INET6) { + srv = get_server_sh(s->be, + (void *)&((struct sockaddr_in6 *)&s->req->prod->addr.from)->sin6_addr, + 16); + } else { /* unknown IP family */ err = SRV_STATUS_INTERNAL; goto out; } - - srv = get_server_sh(s->be, - (void *)&((struct sockaddr_in *)&s->req->prod->addr.from)->sin_addr, - len); break; case BE_LB_HASH_URI: -- 1.7.2.1.45.g54fbc
Q: no option http-server-close
Hi, I thought that no option http-server-close activate the server keep-alive handling but I get ... 2012/03/31 22:04:41 [debug] 32644#0: *94159 http header: "Connection: close" ... in my nginx log. Is there a flag or option in the haproxy custom log format http://haproxy.1wt.eu/git?p=haproxy.git;a=blob;f=doc/configuration.txt;h=2ede20860576f17e2ee91ff26f409876ec32729d;hb=HEAD#l8741 which shows if the client/proxy/server request is a keep-alive request, similar like http://httpd.apache.org/docs/2.2/mod/mod_log_config.html %X Maybe there could be a %Cc => - Client no-keep alive request + Client keep alive request %Bc => - Backend no-keep alive request + Backend keep alive request logging variable ;-) Please can anybody help me to activate the server keep-alive. My config is this. http://pastebin.com/4S9S8GHD haproxy version. ### /home/haproxy/server/haproxy/sbin/haproxy -vv HA-Proxy version 1.5-dev8 2012/03/24 Copyright 2000-2012 Willy Tarreau Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -O2 -g -fno-strict-aliasing OPTIONS = USE_LINUX_SPLICE=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Available polling systems : sepoll : pref=400, test result OK epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 4 (4 usable), will use sepoll. ### Kernel: uname -a Linux HOSTNAME 3.0.0-16-virtual #28-Ubuntu SMP Fri Jan 27 18:22:35 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux OS: cat /etc/issue Ubuntu 11.10 \n \l # Thank you for your help Aleks
Re: output of haproxy 1.5-dev8 -vv
Hi, On 31-03-2012 18:31, Willy Tarreau wrote: Hi Aleks, On Wed, Mar 28, 2012 at 05:40:08PM +0200, Aleksandar Lazic wrote: When I call -vv I don't know if the SPLICE is integrated int the build or not? You have "OPTIONS = USE_LINUX_SPLICE=1 USE_PCRE=1", which means that if you do make OPTIONS="USE_LINUX_SPLICE=1 USE_PCRE=1", you'll get the same binary. I find this much more useful than storing some random -D flags which are not always easy to reinject into the make command line (which is the reason why it was changed to be done this way). Ok thanks. BR Aleks
Re: Q: no option http-server-close
Hi Aleks, On Sat, Mar 31, 2012 at 10:33:26PM +0200, Aleksandar Lazic wrote: > Hi, > > I thought that > > no option http-server-close > > activate the server keep-alive handling but I get It only disables this option, but maybe you were having option httpclose somewhere else ? > ... > 2012/03/31 22:04:41 [debug] 32644#0: *94159 http header: "Connection: > close" > ... > > in my nginx log. > > Is there a flag or option in the haproxy custom log format > > http://haproxy.1wt.eu/git?p=haproxy.git;a=blob;f=doc/configuration.txt;h=2ede20860576f17e2ee91ff26f409876ec32729d;hb=HEAD#l8741 > > which shows if the client/proxy/server request is a keep-alive request, > similar like > > http://httpd.apache.org/docs/2.2/mod/mod_log_config.html > > %X > > Maybe there could be a > > %Cc => - Client no-keep alive request > + Client keep alive request > > %Bc => - Backend no-keep alive request > + Backend keep alive request > > logging variable ;-) This is a good idea and I don't think it would be too hard to do with the new logging format. I'm forwarding to William who's working on the log format at Exceliance so that we don't forget to take a look at this. > Please can anybody help me to activate the server keep-alive. Precisely you won't enable server keep-alive, at most it will be the tunnel mode where only the first request is analysed. I've been desperately trying to find the time to finish the keep-alive work for more than 1 year now! > My config is this. > > http://pastebin.com/4S9S8GHD OK got it. Your frontend has option http-server-close (inherited from the default section) and you only set "no option ..." in the backend, but the frontend has already planned on cutting the connection after the first request. If you want to mix the modes, you should really move the option out of the defaults section to the only backend where you want it. Cheers, Willy
Re: Q: no option http-server-close
Hi Willy, On 31-03-2012 23:18, Willy Tarreau wrote: Hi Aleks, On Sat, Mar 31, 2012 at 10:33:26PM +0200, Aleksandar Lazic wrote: [snipp] Is there a flag or option in the haproxy custom log format http://haproxy.1wt.eu/git?p=haproxy.git;a=blob;f=doc/configuration.txt;h=2ede20860576f17e2ee91ff26f409876ec32729d;hb=HEAD#l8741 which shows if the client/proxy/server request is a keep-alive request, similar like http://httpd.apache.org/docs/2.2/mod/mod_log_config.html %X Maybe there could be a %Cc => - Client no-keep alive request + Client keep alive request %Bc => - Backend no-keep alive request + Backend keep alive request logging variable ;-) This is a good idea and I don't think it would be too hard to do with the new logging format. I'm forwarding to William who's working on the log format at Exceliance so that we don't forget to take a look at this. Thank you. I think this could also be used interesting for the TCP keepalives ;-) Please can anybody help me to activate the server keep-alive. Precisely you won't enable server keep-alive, at most it will be the tunnel mode where only the first request is analysed. I've been desperately trying to find the time to finish the keep-alive work for more than 1 year now! Yep, sorry I have forgotten this, due to the fact that I was in the http-keepalive way. I have removed the 'no option ...' ad keep the server-close in defaults. cheers Aleks
new balance algorithm
I am just investigating use of haproxy for the first time. I'd like the balancing algorithm to send http request to the first server in the list until the number of requests hits a configurable number. When the request limit for a server is hit, I then want new requests to go to the next server until that server hits its configurable limit. So, instead of RR, I want to load down a server before overflowing to the next server. What I think I want to do is to always have the last server in the farm not have any requests. If it does, I will activate another server to ensure I have enough capacity to handle the load spike. But, when the last two servers go completely idle again, I can deactivate the last idle server. My servers are "in the cloud" and I pay for each one that is activated so I think this type of load balancing would help me activate only servers I need (saving me money). I would plan to automate this by having all servers included in the haproxy config but only the first server would initially be UP and all others DOWN. When a server handles a request, it makes sure that its next server is activated. When a server doesn't handle any requests for some time, it deactivates its next server (if any). Does this make sense? I'm new to scaling out and haproxy, so if this scheme already exists, please point me to where it is discussed in the documentation. Kevin
Re: new balance algorithm
On Sat, Mar 31, 2012 at 7:55 PM, Kevin Heatwole wrote: > I am just investigating use of haproxy for the first time. > > I'd like the balancing algorithm to send http request to the first server in > the list until the number of requests hits a configurable number. When the > request limit for a server is hit, I then want new requests to go to the next > server until that server hits its configurable limit. So, instead of RR, I > want to load down a server before overflowing to the next server. > > What I think I want to do is to always have the last server in the farm not > have any requests. If it does, I will activate another server to ensure I > have enough capacity to handle the load spike. But, when the last two > servers go completely idle again, I can deactivate the last idle server. > > My servers are "in the cloud" and I pay for each one that is activated so I > think this type of load balancing would help me activate only servers I need > (saving me money). > > I would plan to automate this by having all servers included in the haproxy > config but only the first server would initially be UP and all others DOWN. > When a server handles a request, it makes sure that its next server is > activated. When a server doesn't handle any requests for some time, it > deactivates its next server (if any). You could implement this by monitoring your available slots on a backend, once the slots decrease %N of total slots, spin up new instances. Apply the same logic in reverse to turn off nodes. I presume you can hardcode IP addresses ahead of time? > > Does this make sense? I'm new to scaling out and haproxy, so if this scheme > already exists, please point me to where it is discussed in the documentation. > > Kevin
Re: new balance algorithm
On Mar 31, 2012, at 11:06 PM, David Birdsong wrote: > On Sat, Mar 31, 2012 at 7:55 PM, Kevin Heatwole wrote: >> I would plan to automate this by having all servers included in the haproxy >> config but only the first server would initially be UP and all others DOWN. >> When a server handles a request, it makes sure that its next server is >> activated. When a server doesn't handle any requests for some time, it >> deactivates its next server (if any). > > You could implement this by monitoring your available slots on a > backend, once the slots decrease %N of total slots, spin up new > instances. Apply the same logic in reverse to turn off nodes. You make a good point. I was also thinking of using dynamic WEIGHTs in haproxy by setting the last available server to have a WEIGHT of 1% and then when that server starts getting a steady stream of requests, up its WEIGHT to 100% and allocate a new last server. I think I could make your suggestion work, but I'd rather just have it all configured in the load balancer. I'd also rather see the load balancer have some mechanism to tell the last active server it should spin up a spare or to deactivate itself so it is completely in control.
Re: new balance algorithm
> On Mar 31, 2012, at 11:06 PM, David Birdsong wrote: >> On Sat, Mar 31, 2012 at 7:55 PM, Kevin Heatwole wrote: >>> I would plan to automate this by having all servers included in the haproxy >>> config but only the first server would initially be UP and all others DOWN. >>> When a server handles a request, it makes sure that its next server is >>> activated. When a server doesn't handle any requests for some time, it >>> deactivates its next server (if any). >> >> You could implement this by monitoring your available slots on a >> backend, once the slots decrease %N of total slots, spin up new >> instances. Apply the same logic in reverse to turn off nodes. > I just noticed in the documentation that the http-check can send its state. This seams to contain enough info (scur and qcur) for a script to decide to activate or deactivate a server. I like that this decision can be made using the stats from the load balancer. So, I think this is sufficient for my needs and I don't need a new balance algorithm.
Re: new balance algorithm
On Sat, Mar 31, 2012 at 08:06:23PM -0700, David Birdsong wrote: > On Sat, Mar 31, 2012 at 7:55 PM, Kevin Heatwole wrote: > > I am just investigating use of haproxy for the first time. > > > > I'd like the balancing algorithm to send http request to the first server > > in the list until the number of requests hits a configurable number. When > > the request limit for a server is hit, I then want new requests to go to > > the next server until that server hits its configurable limit. So, instead > > of RR, I want to load down a server before overflowing to the next server. > > > > What I think I want to do is to always have the last server in the farm not > > have any requests. If it does, I will activate another server to ensure I > > have enough capacity to handle the load spike. But, when the last two > > servers go completely idle again, I can deactivate the last idle server. > > > > My servers are "in the cloud" and I pay for each one that is activated so I > > think this type of load balancing would help me activate only servers I > > need (saving me money). > > > > I would plan to automate this by having all servers included in the haproxy > > config but only the first server would initially be UP and all others DOWN. > > When a server handles a request, it makes sure that its next server is > > activated. When a server doesn't handle any requests for some time, it > > deactivates its next server (if any). > > You could implement this by monitoring your available slots on a > backend, once the slots decrease %N of total slots, spin up new > instances. Apply the same logic in reverse to turn off nodes. Or you can download latest snapshot and use "balance first", which was proposed by Steen Larsen one month ago :-) Willy