Making new server parameter inside upstream block

Maxim Dounin mdounin at mdounin.ru
Thu Feb 12 14:53:03 UTC 2015


Hello!

On Thu, Feb 12, 2015 at 05:19:46PM +0300, Дмитрий Шалашов wrote:

> Ok, thanks.
> 
> Can you imagine any other viable way to pass some information to each
> server? It doesn't need to change between server restarts.
> I may use a distinct variable for each of them but this seems ugly and
> error-prone...

You may want to rethink what you are trying to do.  In this 
particular case the whole task seems to be unneeded, see below.

> In case you are curious why would I need this, let me explain.
> Upstream directive support "hash consistent" method and in that case it
> uses `ketama` algorithm. That means that each server assigned a key and
> depending on its value (actually hash of that value) each server mapped to
> a multiple points on the ketama ring. So far so good.
> Documentation says that keys distribution is compatible with Perl
> Cache::Memcached::Fast module. And that means that key for each server is
> "$ip\0$port" (or something else for unix sockets, doesn't matter).
> This means that if server ip changes, position of server points on ketama
> ring will change too. Now, I'm balancing via this upstream not memcacheds
> or other rather ephemeral storages but files. Each server in the upstream
> have a hundreds of gigabytes of files. And I would like to avoid
> rebalancing all these files in case of public ip changes.
> So my idea was to pass a key for each server via parameter. Actually, to
> preserve compatibility with current keys, I would pass a base64 of
> "$ip\0$port" value, decode it during module init and happily use it for
> ketama purposes. And be safe against servers redeployments.

Just use names in the configuration.  Both Cache::Memcached::Fast 
and nginx will happily use names of servers and will derive 
Ketama points from names, not IP-addresses.  That is, key 
distribution will stay the same as long as you don't change names 
configured, regardless of IP-addresses.

-- 
Maxim Dounin
http://nginx.org/



More information about the nginx-devel mailing list