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