[upstream] consistent hash support backup?

[Ruslan Ermilov]

On Wed, Nov 08, 2017 at 10:00:44PM +0800, 洪志道 wrote:
> Thank you for your reply.
> 
> What I want to solve is that backup servers can be selected when all the
> primary servers are unavailable.
> 
> Now I use error_page to solve it, but it's not convenient in the case of
> multi-servers-locations.
> Especially some locations have already config error_page directive.
> 
> upstream backends {
>     hash $uri consistent;
>     server 10.0.0.1;
>     server 10.0.0.2;
> }
> 
> upstream backup {
>     server 10.0.0.3;
> }
> 
> server {
>      ...
>      location / {
>         error_page  502 504 = @fallback;
>         proxy_pass  http://backends;
>      }
> 
>      location @fallback {
>         proxy_pass  http://backup;
>      }
> }
> 
> But if hash support backup, it would be handier, such as following.
> 
> upstream backends {
>     hash $uri consistent;
>     server 10.0.0.1;
>     server 10.0.0.2;
>     server 10.0.0.3  backup; # Unfortunately it's now allowed.
> }
> 
> server {
>      ...
>      location / {
>         proxy_pass  http://backends;
>      }
> }
> 
> Anyway.
> 
> 1. Can you share the reason for "backup" option is not allowed combined
> with the hash module?

Well, "backup" just doesn't make much sense in case of hash/ip_hash.
As explained previously, if "backup" was allowed with hash, backup
servers could only be selected when falling back from hash to round
robin after 20 unsuccessful tries.

> 2. Is there any problem if I add the flag 'NGX_HTTP_UPSTREAM_BACKUP'  in
> the hash module?

Not that I'm aware of.  Moreover, if you put the "hash" directive
after the "server" directives in your example, then due to the bug
you'll be able to use "backup", and things should just work the
way you describe them.  But it's not recommended, nor is guaranteed
to work, use at your own risk.  It's this bug that I called "bypass"
in my previous email.

>     I know it's not an ideal design.
> 
> Thanks again.
> 
> 
> On Wed, Nov 8, 2017 at 9:11 PM, Ruslan Ermilov <ru at nginx.com> wrote:
> 
> > On Mon, Nov 06, 2017 at 09:35:14PM +0800, 洪志道 wrote:
> > >    Hi!
> > >    We know that consistent hash upstream improve its selection in the
> > latest
> > >    version.
> > >
> > >  -        if (hp->tries >= points->number) {
> > >  -            pc->name = hp->rrp.peers->name;
> > >  +        if (hp->tries > 20) {
> > >               ngx_http_upstream_rr_peers_unlock(hp->rrp.peers);
> > >  -            return NGX_BUSY;
> > >  +            return hp->get_rr_peer(pc, &hp->rrp);
> > >
> > >  Does it mean that "backup" option is allowed in the module?
> >
> > It just means that if, after 20 tries, we weren't able to select
> > a peer using the hash algorithm, then we'll continue a selection
> > process using the round-robin algorithm.  This is also consistent
> > with the ip_hash module.
> >
> > >                     |NGX_HTTP_UPSTREAM_MAX_CONNS
> > >                     |NGX_HTTP_UPSTREAM_MAX_FAILS
> > >                     |NGX_HTTP_UPSTREAM_FAIL_TIMEOUT
> > >  +                  |NGX_HTTP_UPSTREAM_BACKUP
> > >                     |NGX_HTTP_UPSTREAM_DOWN;
> >
> > We do not support backup servers with ip_hash and hash balancers,
> > though there's currently a bypass that allows to have backup
> > servers in configurations with hash balancers.  But these backup
> > servers will be used only when falling back to round-robin, which
> > is unlikely.
> >
> > >  I wonder how to archive the effect of "backup" in hash like round robin,
> > >  even if we don't want to use error_page.
> >
> > I'm not sure what did you mean here.