Idea: Zeroconf/Avahi support?


#1

I’ve been considering a pair of Nginx modules that would support
Avahi/Zeroconf. That is, let Nginx announce itself via Avahi (one
module) and another that would let it detect other services via Avahi
(the second module) for use with the upstream module.

This would allow an Nginx instance to detect when new Nginx servers are
added to a cluster (upstream) and automatically start load balancing
them without having to edit the config file and signal Nginx.

It’s also worth mentioning that some web frameworks already support
Zeroconf (TurboGears being one), so they would be supported as well.

Thoughts? I’m interested in hearing if people see potential stumbling
blocks or show-stoppers before I invest a lot of energy in it.

Regards,
Cliff


#2

Hi Chris,

That is an excellent idea. I would be very interested in such a module
as it would allow me to use nginx to proxy a bunch of dynamic j2ee
applications. I’d be interested in working on the companion connector
for tomcat if one doesn’t already exist.

The major stubling block I can see is integrating the avahi resolver
(for lack of a better word) into Nginx without blocking.

Cheers

Dave


#3

Cliff W. ha scritto:

I’ve been considering a pair of Nginx modules that would support
Avahi/Zeroconf. That is, let Nginx announce itself via Avahi (one
module) and another that would let it detect other services via Avahi
(the second module) for use with the upstream module.

This would allow an Nginx instance to detect when new Nginx servers are
added to a cluster (upstream) and automatically start load balancing
them without having to edit the config file and signal Nginx.

This would probabily require a rewrite of the upstream module, to
support dynamic configuration.

[…]

Regards Manlio


#4

On Tue, 2009-03-10 at 08:05 +1100, Dave C. wrote:

Hi Chris,

That is an excellent idea. I would be very interested in such a module
as it would allow me to use nginx to proxy a bunch of dynamic j2ee
applications. I’d be interested in working on the companion connector
for tomcat if one doesn’t already exist.

The major stubling block I can see is integrating the avahi resolver
(for lack of a better word) into Nginx without blocking.

I’m still investigating, but I believe that Avahi supports async (via
dbus callback at least).

Cliff


#5

On Mon, 2009-03-09 at 22:26 +0000, Marcus C. wrote:

The major stubling block I can see is integrating the avahi resolver
(for lack of a better word) into Nginx without blocking.

Making Avahi non-blocking wouldn’t be difficult. If Avahi is
long-running, you can put it in a separate thread and send information
back to Nginx via writing information to a pipe (since Nginx isn’t
thread-safe). I’m not sure how Avahi works, but you might want to use
the a timed event (there are functions available for this in the Nginx
source) as a trigger.

It seems Avahi is actually designed to be tied into an event loop:

http://www.mail-archive.com/removed_email_address@domain.invalid/msg01141.html

Cliff


#6

Manlio P. wrote:

This would probabily require a rewrite of the upstream module, to
support dynamic configuration.

What about using a repeating timed event that checked for new upstream
servers, perhaps launching the search in a new thread? If the server
makeup has changed, then an event could be triggered to change the
upstream configuration? This wouldn’t require re-writing the upstream
module, but would it cause problems to existing connections to upstream
servers? Since events and file descriptors would already be registered
by this point, the main problem might be with connections where the next
upstream needed to be selected, but that might still be ok (depending on
how it’s implemented, which I’ve not looked at).

Of course rewriting of the upstream module might give a more elegant
solution. :wink:

[…]

Regards Manlio

Marcus.


#7

It seems Avahi is actually designed to be tied into an event loop:

http://www.mail-archive.com/removed_email_address@domain.invalid/msg01141.html

Even better. :slight_smile:

Marcus.


#8

Cliff W. wrote:

(for lack of a better word) into Nginx without blocking.

Making Avahi non-blocking wouldn’t be difficult. If Avahi is
long-running, you can put it in a separate thread and send information
back to Nginx via writing information to a pipe (since Nginx isn’t
thread-safe). I’m not sure how Avahi works, but you might want to use
the a timed event (there are functions available for this in the Nginx
source) as a trigger.

Marcus.


#9

Marcus C. ha scritto:

What about using a repeating timed event that checked for new upstream
servers, perhaps launching the search in a new thread? If the server
makeup has changed, then an event could be triggered to change the
upstream configuration?

This is already feasible without touching Nginx code.

Just write a small server (in a language like Python), than when a new
upstream is available, modify the Nginx configuration file and send an
HUP signal to the Nginx process.

[…]

Regards Manlio


#10

This is already feasible without touching Nginx code.

Just write a small server (in a language like Python), than when a new
upstream is available, modify the Nginx configuration file and send an
HUP signal to the Nginx process.
Sounds like a better idea, though I’m in Nginx-hacking mode at the
moment so didn’t think of it. :wink:

It would be pretty easy to adapt it to other servers, too - you’d just
need to change the output configuration.

Perhaps this type of monitor already exists, if not for Nginx for
something else.

Marcus.