Actually, this is the purpose of dropping a weight to 0: being able to maintain sticky sessions. If you want to shutdown rudely your server, preventing everybody to access it, use the disable keyword.
Baptiste On Wed, May 29, 2013 at 5:55 PM, Godbach <[email protected]> wrote: > Hi Baptiste > > It doesn't matter. :-) > > When the weight of server is set to 0 with the balance roundrobin algorithm, > srv->eweight is update to 0 and > fwrr_update_server_weight() (lb_fwrr.c) will be called as below: > > static void fwrr_update_server_weight(struct server *srv) > { > ... > old_state = srv_is_usable(srv->prev_state, srv->prev_eweight); > new_state = srv_is_usable(srv->state, srv->eweight); > > if (!old_state && !new_state) { > srv->prev_state = srv->state; > srv->prev_eweight = srv->eweight; > return; > } > else if (!old_state && new_state) { > fwrr_set_server_status_up(srv); > return; > } > else if (old_state && !new_state) { > fwrr_set_server_status_down(srv); > return; > } > ... > } > > Since srv->eweight is 0, new_state should be also 0, then > fwrr_set_server_status_down() will be called. > At the end the server will be remove from weight tree by fwrr_dequeue_srv() > and lb_tree by fwrr_remove_from_tree(). > But the srv->state has not been updated, still keeps in SRV_RUNNING. As a > result, when the same server is selected by > sticking rules, it will be used again. > > > >> AH, sorry, my mistake. >> I read your mail too quickly. >> >> Baptiste >> >> On Wed, May 29, 2013 at 9:18 AM, Godbach <[email protected]> wrote: >>> >>> Hi Baptiste >>> >>> Thanks for your replying. >>> >>> I am using the balance roundrobin algorithm and sticking on src, not the >>> the >>> balance source algorithm. The configuration has been presented in my >>> first >>> mail as below: >>> >>> >>>>> backend pool >>>>> balance roundrobin. >>>>> stick-table type ip size 200k expire 600s >>>>> stick on src >>>>> server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn >>>>> 0 >>>>> slowstart 0s >>>>> server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn >>>>> 0 >>>>> slowstart 0s >>>>> >>> Best Regards, >>> Godbach >>> >>> >>> On 2013/5/29 13:35, Baptiste wrote: >>>> >>>> Hi Godbach, >>>> >>>> Before reading HAProxy source code, it worths reading its >>>> configuration guide for the options you use. >>>> IE, the balance source algorithm would tell you that: >>>> >>>> "This algorithm is static by default, which means that changing a >>>> server's weight on the fly will have no effect, but this can be >>>> changed using "hash-type"." >>>> >>>> Please update your configuration following the recommandation above >>>> and let us know your feedback. >>>> >>>> Baptiste >>>> >>>> >>>> >>>> On Wed, May 29, 2013 at 5:22 AM, Godbach <[email protected]> wrote: >>>>> >>>>> Hi, all >>>>> >>>>> It is expected that new http request will not get response from the >>>>> server of which weight was changed to 0. It cannot work well with >>>>> persistence on src but work well without the persistence in lastest >>>>> snapshot. >>>>> >>>>> There are two servers in my backend, and persistence on src ip has been >>>>> enabled in backend. The configuration in backend as below: >>>>> >>>>> backend pool >>>>> balance roundrobin. >>>>> stick-table type ip size 200k expire 600s >>>>> stick on src >>>>> server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn >>>>> 0 >>>>> slowstart 0s >>>>> server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn >>>>> 0 >>>>> slowstart 0s >>>>> >>>>> During continuous http requset with the same client, the stick table as >>>>> below: >>>>> # table: pool, type: ip, size:204800, used:1 >>>>> 0x17d2284: key=172.22.16.250 use=0 exp=599095 server_id=1 >>>>> Then I set weight of server 1 to 0 use command as below: >>>>> set weight pool/1 0 >>>>> And I get the weight of server 1 with command: >>>>> get weight pool/1 >>>>> The result is >>>>> 0 (initial 1) >>>>> So I think I have set the weight of sever1 to 0 successfully. But the >>>>> response still comes from server 1 which server 2 is expected. And the >>>>> stick table keeps the same. >>>>> >>>>> I review the code of process_sticking_rules() in session.c. The codes >>>>> when server is found as below: >>>>> >>>>> 1403 ptr = stktable_data_ptr(rule->table.t, ts, >>>>> STKTABLE_DT_SERVER_ID); >>>>> 1404 node = >>>>> eb32_lookup(&px->conf.used_server_id, stktable_data_cast(ptr, >>>>> server_id)); >>>>> 1405 if (node) { >>>>> 1406 struct server *srv; >>>>> 1407 >>>>> 1408 srv = container_of(node, struct >>>>> server, >>>>> conf.id); >>>>> 1409 if ((srv->state & SRV_RUNNING) || >>>>> 1410 (px->options & PR_O_PERSIST) || >>>>> 1411 (s->flags & SN_FORCE_PRST)) { >>>>> 1412 s->flags |= SN_DIRECT | >>>>> SN_ASSIGNED; >>>>> 1413 s->target = &srv->obj_type; >>>>> 1414 } >>>>> 1415 } >>>>> 1416 } >>>>> 1417 stktable_touch(rule->table.t, ts, 1); >>>>> >>>>> Line 1409 used (srv->state & SRV_RUNNING) to check the server status. >>>>> If I used srv_is_usable() to instead such as below: >>>>> - if ((srv->state & SRV_RUNNING) || >>>>> + if (srv_is_usable(srv->state, srv->eweight) || >>>>> >>>>> The new request will get response from server 2 once the weight of >>>>> server 1 is set to 0. But it seems to be just a workaround. >>>>> >>>>> Since the manual of haproxy about 'set weight' says that: >>>>> A typical usage of this command is to disable a server during an update >>>>> by setting its weight to zero. >>>>> >>>>> I am wondering that whether the flag SRV_RUNNING of server should be >>>>> cleared or not when its weight is set to 0. >>>>> >>>>> -- >>>>> Best Regards, >>>>> Godbach >>>>> >>> >>> -- >>> Best Regards, >>> Godbach > >
