[PROPOSAL] mod_cloudbeat

[Paul Querna <pa...@querna.org>]

The Problem:  You just bought into whole cloud computing craze.  But how do you
load balance to this constantly changing fabric, without sysadmins
constantly changing
server configurations.  Most generic cloud computing platforms , for
example Amazon EC2,
provide almost no way of load balancing large application clusters.

The (vaporware) solution: mod_cloudbeat automatically finds all of your nodes,
both front end load balancers and backend application servers.  All load
balancing is completely configurationless if using mod_serf -- you just
turn on a new application server instance, and mod_cloudbeat picks it up.

The CloudBeat Protocol

On startup only a shared secret must be known, this is used to both uniquely
identify the cluster, and provide the ability to sign all requests.

If no known node address is supplied, and the heartbeat file does not list any
from previous runs, the node waits to be contacted by another node.

Once another node is known, it is contacted.  We send an HTTP request with
our capabilities, and the other node politely does the same to us.  This
includes downloading a list of peers from each other. For each peer that we
haven't communicated with, we repeat the exchange.

Once a peer has been contacted, we add it to the heartbeats file, which uses
the same file format as mod_heartmonitor, and can be consumed by other modules.

We send the first ping we randomize 1-10 seconds, to avoid thundering startup
herds, and from then on we ping every 10 seconds. The peer responds
with the basic scoreboard information about itself, which we update in the
heartbeat file.

URL Structure

To make stateless autoconfiguration on a cloud easier, Cloudbeat's internal
protocol uses /!cloudbeat/ as the url prefix.  This prefix is not
configurable at run time, to avoid more configuration cruft.

All data is expressed in JSON.

 /hello.json
     Returns a basic structure with the version of the protocol,
     and the capabilities of the host.  Other nodes should POST
     with their own information to this URL to initiate peering.
     {"version": 1, "capabilities": ["ping"]}
 /ping.json
     Returns the current busy/available workers information.
     {"workers": {"busy": 25, "idle": 475}, "uptime": 5444}

URL Authentication is done by computing an randomly seeded md5 signature of:
     seed + "$"+ MD5(seed + shared_secret + uri)
This is base64 encoded, and placed in a 'X-Cloudbeat-Auth' header.

Status: I'm hacking up a prototype using Serf + libjsox, I'll try to
get something into subversion soon, but would like feedback on how to
structure the protocol and any other ideas people have.

Thanks,

Paul

Re: [PROPOSAL] mod_cloudbeat

[Paul Querna <pa...@querna.org>]

On Mon, Mar 30, 2009 at 5:28 PM, "Plüm, Rüdiger, VF-Group"
<ru...@vodafone.com> wrote:
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Paul Querna
>> Gesendet: Montag, 30. März 2009 17:18
>> An: dev@httpd.apache.org
>> Betreff: Re: [PROPOSAL] mod_cloudbeat
>>
>> On Mon, Mar 30, 2009 at 5:10 PM, "Plüm, Rüdiger, VF-Group"
>> <ru...@vodafone.com> wrote:
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: Paul Querna
>> >> Gesendet: Montag, 30. März 2009 17:04
>> >> An: dev@httpd.apache.org
>> >> Betreff: Re: [PROPOSAL] mod_cloudbeat
>> >>
>> >> On Mon, Mar 30, 2009 at 4:45 PM, Jim Jagielski
>> >> <ji...@jagunet.com> wrote:
>> >> >
>> >> > On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
>> >> >>
>> >> >> URL Authentication is done by computing an randomly seeded
>> >> md5 signature
>> >> >> of:
>> >> >>    seed + "$"+ MD5(seed + shared_secret + uri)
>> >> >> This is base64 encoded, and placed in a
>> 'X-Cloudbeat-Auth' header.
>> >> >>
>> >> >
>> >> > Thinking outloud here... The idea I think is to ensure that
>> >> > the X-Cloudbeat-Auth defines an authenticated server, using
>> >> > the fact that it knows the shared secret. But how does the
>> >> > above do that? Say for example that A and B known to each
>> >> > other and B is sending X-Cloudbeat-Auth. This is easy to
>> >> > find out, of course. So I setup B' to send the exact same
>> >> > header and apply a DoS to B causing it to drop/hang/whatever.
>> >> > Won't A just see B' as B, maybe thinking that it had a
>> >> > momentary glitch and came back? It seems to me that we need
>> >> > some sort of IP:port knowledge in there as well.
>> >>
>> >> In my mind, URL includes the IP/port, so you shouldn't be
>> able to DoS
>> >> it this way.  I guess I should of been clearer by what I meant with
>> >> URL.
>> >>
>> >> I was thinking about this more, and we should also change
>> the hash to
>> >> sha1, considering it only takes a few days to find md5
>> collisions if
>> >> you have enough playstation 3s:
>> >>     seed + "$"+ sha1(seed + shared_secret + ip ":"+ port + URI)
>> >
>> > Which IP do you use here? The one from the client that
>> sends the request?
>> > Furthermore we should include a timestamp as we are very
>> vulnerable against
>> > replay attacks otherwise.
>>
>> Server A wants to talk to B.
>>
>> We include server B's IP in the hash that Server A sends to B.  (this
>> prevents B without knowledge of the secret from doing a replay).
>
> But it doesn't prevent A' that sniffed the traffic from A to B to replay.
> OTOH why fiddle with this auth stuff anyway. We could make it save by
> using TLS and client certs.

bleh, just trying to avoid massive configuration hurdles to get a
system up and running, by for the most part trying to just avoid man
in the middle protection :(

Re: [PROPOSAL] mod_cloudbeat

[Jim Jagielski <ji...@jaguNET.com>]

On Mar 30, 2009, at 11:28 AM, Plüm, Rüdiger, VF-Group wrote:

>
> But it doesn't prevent A' that sniffed the traffic from A to B to  
> replay.
> OTOH why fiddle with this auth stuff anyway. We could make it save by
> using TLS and client certs.
>

Holy freholey! And I was worried about the overhead of
md5/sha1 ! :)

Re: [PROPOSAL] mod_cloudbeat

["Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>]

 

> -----Ursprüngliche Nachricht-----
> Von: Paul Querna 
> Gesendet: Montag, 30. März 2009 17:18
> An: dev@httpd.apache.org
> Betreff: Re: [PROPOSAL] mod_cloudbeat
> 
> On Mon, Mar 30, 2009 at 5:10 PM, "Plüm, Rüdiger, VF-Group"
> <ru...@vodafone.com> wrote:
> >> -----Ursprüngliche Nachricht-----
> >> Von: Paul Querna
> >> Gesendet: Montag, 30. März 2009 17:04
> >> An: dev@httpd.apache.org
> >> Betreff: Re: [PROPOSAL] mod_cloudbeat
> >>
> >> On Mon, Mar 30, 2009 at 4:45 PM, Jim Jagielski
> >> <ji...@jagunet.com> wrote:
> >> >
> >> > On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
> >> >>
> >> >> URL Authentication is done by computing an randomly seeded
> >> md5 signature
> >> >> of:
> >> >>    seed + "$"+ MD5(seed + shared_secret + uri)
> >> >> This is base64 encoded, and placed in a 
> 'X-Cloudbeat-Auth' header.
> >> >>
> >> >
> >> > Thinking outloud here... The idea I think is to ensure that
> >> > the X-Cloudbeat-Auth defines an authenticated server, using
> >> > the fact that it knows the shared secret. But how does the
> >> > above do that? Say for example that A and B known to each
> >> > other and B is sending X-Cloudbeat-Auth. This is easy to
> >> > find out, of course. So I setup B' to send the exact same
> >> > header and apply a DoS to B causing it to drop/hang/whatever.
> >> > Won't A just see B' as B, maybe thinking that it had a
> >> > momentary glitch and came back? It seems to me that we need
> >> > some sort of IP:port knowledge in there as well.
> >>
> >> In my mind, URL includes the IP/port, so you shouldn't be 
> able to DoS
> >> it this way.  I guess I should of been clearer by what I meant with
> >> URL.
> >>
> >> I was thinking about this more, and we should also change 
> the hash to
> >> sha1, considering it only takes a few days to find md5 
> collisions if
> >> you have enough playstation 3s:
> >>     seed + "$"+ sha1(seed + shared_secret + ip ":"+ port + URI)
> >
> > Which IP do you use here? The one from the client that 
> sends the request?
> > Furthermore we should include a timestamp as we are very 
> vulnerable against
> > replay attacks otherwise.
> 
> Server A wants to talk to B.
> 
> We include server B's IP in the hash that Server A sends to B.  (this
> prevents B without knowledge of the secret from doing a replay).

But it doesn't prevent A' that sniffed the traffic from A to B to replay.
OTOH why fiddle with this auth stuff anyway. We could make it save by
using TLS and client certs.

Regards

Rüdiger

Re: [PROPOSAL] mod_cloudbeat

[Paul Querna <pa...@querna.org>]

On Mon, Mar 30, 2009 at 5:10 PM, "Plüm, Rüdiger, VF-Group"
<ru...@vodafone.com> wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Paul Querna
>> Gesendet: Montag, 30. März 2009 17:04
>> An: dev@httpd.apache.org
>> Betreff: Re: [PROPOSAL] mod_cloudbeat
>>
>> On Mon, Mar 30, 2009 at 4:45 PM, Jim Jagielski
>> <ji...@jagunet.com> wrote:
>> >
>> > On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
>> >>
>> >> URL Authentication is done by computing an randomly seeded
>> md5 signature
>> >> of:
>> >>    seed + "$"+ MD5(seed + shared_secret + uri)
>> >> This is base64 encoded, and placed in a 'X-Cloudbeat-Auth' header.
>> >>
>> >
>> > Thinking outloud here... The idea I think is to ensure that
>> > the X-Cloudbeat-Auth defines an authenticated server, using
>> > the fact that it knows the shared secret. But how does the
>> > above do that? Say for example that A and B known to each
>> > other and B is sending X-Cloudbeat-Auth. This is easy to
>> > find out, of course. So I setup B' to send the exact same
>> > header and apply a DoS to B causing it to drop/hang/whatever.
>> > Won't A just see B' as B, maybe thinking that it had a
>> > momentary glitch and came back? It seems to me that we need
>> > some sort of IP:port knowledge in there as well.
>>
>> In my mind, URL includes the IP/port, so you shouldn't be able to DoS
>> it this way.  I guess I should of been clearer by what I meant with
>> URL.
>>
>> I was thinking about this more, and we should also change the hash to
>> sha1, considering it only takes a few days to find md5 collisions if
>> you have enough playstation 3s:
>>     seed + "$"+ sha1(seed + shared_secret + ip ":"+ port + URI)
>
> Which IP do you use here? The one from the client that sends the request?
> Furthermore we should include a timestamp as we are very vulnerable against
> replay attacks otherwise.

Server A wants to talk to B.

We include server B's IP in the hash that Server A sends to B.  (this
prevents B without knowledge of the secret from doing a replay).

I dislike adding a timestamp as it tends to make the protocols more
brittle, but maybe int(current unix timestamp / 2 days in seconds)
would allow boxes out of sync, but prevent long term replay and hash
reuse.

Thanks,

Paul

Re: [PROPOSAL] mod_cloudbeat

["Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>]

 

> -----Ursprüngliche Nachricht-----
> Von: Paul Querna 
> Gesendet: Montag, 30. März 2009 17:04
> An: dev@httpd.apache.org
> Betreff: Re: [PROPOSAL] mod_cloudbeat
> 
> On Mon, Mar 30, 2009 at 4:45 PM, Jim Jagielski 
> <ji...@jagunet.com> wrote:
> >
> > On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
> >>
> >> URL Authentication is done by computing an randomly seeded 
> md5 signature
> >> of:
> >>    seed + "$"+ MD5(seed + shared_secret + uri)
> >> This is base64 encoded, and placed in a 'X-Cloudbeat-Auth' header.
> >>
> >
> > Thinking outloud here... The idea I think is to ensure that
> > the X-Cloudbeat-Auth defines an authenticated server, using
> > the fact that it knows the shared secret. But how does the
> > above do that? Say for example that A and B known to each
> > other and B is sending X-Cloudbeat-Auth. This is easy to
> > find out, of course. So I setup B' to send the exact same
> > header and apply a DoS to B causing it to drop/hang/whatever.
> > Won't A just see B' as B, maybe thinking that it had a
> > momentary glitch and came back? It seems to me that we need
> > some sort of IP:port knowledge in there as well.
> 
> In my mind, URL includes the IP/port, so you shouldn't be able to DoS
> it this way.  I guess I should of been clearer by what I meant with
> URL.
> 
> I was thinking about this more, and we should also change the hash to
> sha1, considering it only takes a few days to find md5 collisions if
> you have enough playstation 3s:
>     seed + "$"+ sha1(seed + shared_secret + ip ":"+ port + URI)

Which IP do you use here? The one from the client that sends the request?
Furthermore we should include a timestamp as we are very vulnerable against
replay attacks otherwise.

Regards

Rüdiger

Re: [PROPOSAL] mod_cloudbeat

[Paul Querna <pa...@querna.org>]

On Mon, Mar 30, 2009 at 4:45 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
>>
>> URL Authentication is done by computing an randomly seeded md5 signature
>> of:
>>    seed + "$"+ MD5(seed + shared_secret + uri)
>> This is base64 encoded, and placed in a 'X-Cloudbeat-Auth' header.
>>
>
> Thinking outloud here... The idea I think is to ensure that
> the X-Cloudbeat-Auth defines an authenticated server, using
> the fact that it knows the shared secret. But how does the
> above do that? Say for example that A and B known to each
> other and B is sending X-Cloudbeat-Auth. This is easy to
> find out, of course. So I setup B' to send the exact same
> header and apply a DoS to B causing it to drop/hang/whatever.
> Won't A just see B' as B, maybe thinking that it had a
> momentary glitch and came back? It seems to me that we need
> some sort of IP:port knowledge in there as well.

In my mind, URL includes the IP/port, so you shouldn't be able to DoS
it this way.  I guess I should of been clearer by what I meant with
URL.

I was thinking about this more, and we should also change the hash to
sha1, considering it only takes a few days to find md5 collisions if
you have enough playstation 3s:
    seed + "$"+ sha1(seed + shared_secret + ip ":"+ port + URI)

Thanks,

-Paul

Re: [PROPOSAL] mod_cloudbeat

[Jim Jagielski <ji...@apache.org>]

On Mar 30, 2009, at 10:45 AM, Jim Jagielski wrote:

>
> On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
>>
>> URL Authentication is done by computing an randomly seeded md5  
>> signature of:
>>    seed + "$"+ MD5(seed + shared_secret + uri)
>> This is base64 encoded, and placed in a 'X-Cloudbeat-Auth' header.
>>
>
> Thinking outloud here... The idea I think is to ensure that
> the X-Cloudbeat-Auth defines an authenticated server, using
> the fact that it knows the shared secret. But how does the
> above do that? Say for example that A and B known to each
> other and B is sending X-Cloudbeat-Auth. This is easy to
> find out, of course. So I setup B' to send the exact same
> header and apply a DoS to B causing it to drop/hang/whatever.
> Won't A just see B' as B, maybe thinking that it had a
> momentary glitch and came back? It seems to me that we need
> some sort of IP:port knowledge in there as well.
>

Hold on a tic... if the uri is the uri of what *I am handling*
then, of course, this is sufficient. But if it's the
prefix of urls that will be handled (like the 1st arg
to ProxyPass) then it's not.

Re: [PROPOSAL] mod_cloudbeat

[Jim Jagielski <ji...@jaguNET.com>]

On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
>
> URL Authentication is done by computing an randomly seeded md5  
> signature of:
>     seed + "$"+ MD5(seed + shared_secret + uri)
> This is base64 encoded, and placed in a 'X-Cloudbeat-Auth' header.
>

Thinking outloud here... The idea I think is to ensure that
the X-Cloudbeat-Auth defines an authenticated server, using
the fact that it knows the shared secret. But how does the
above do that? Say for example that A and B known to each
other and B is sending X-Cloudbeat-Auth. This is easy to
find out, of course. So I setup B' to send the exact same
header and apply a DoS to B causing it to drop/hang/whatever.
Won't A just see B' as B, maybe thinking that it had a
momentary glitch and came back? It seems to me that we need
some sort of IP:port knowledge in there as well.

Re: [PROPOSAL] mod_cloudbeat

[Paul Querna <pa...@querna.org>]

On Sun, Mar 29, 2009 at 7:36 PM, Graham Leggett <mi...@sharp.fm> wrote:
> Paul Querna wrote:
>
>> no, this is just a utility module, which tells you where other members
>> are.
>>
>> second, mod_backhand has never been ported to 2.x, and it does allow
>> you to autoconfigure on cloud-enviroments, which mostly do not have
>> private VLANs for multicast.
>>
>> I'm trying to keep it as a simple module that does a small number of
>> utility tasks well, and then it provides this information for other
>> people and modules to use -- mod_serf or mod_proxy can consume that
>> data to do proxying/load balancing or whatever.
>
> On my list of things to do is a module that is able to locate backend
> servers using zeroconf/bonjour, and this sounds similar (although not the
> same, obviously).
>

That is much closer to what mod_heartbeat does -- It uses multicast
like zeroconf/bonjour, but the problem is that in most cloud
enviroments, you don't have the ability to use multicast between
nodes, at least right now.

Re: [PROPOSAL] mod_cloudbeat

[Graham Leggett <mi...@sharp.fm>]

Paul Querna wrote:

> no, this is just a utility module, which tells you where other members are.
> 
> second, mod_backhand has never been ported to 2.x, and it does allow
> you to autoconfigure on cloud-enviroments, which mostly do not have
> private VLANs for multicast.
> 
> I'm trying to keep it as a simple module that does a small number of
> utility tasks well, and then it provides this information for other
> people and modules to use -- mod_serf or mod_proxy can consume that
> data to do proxying/load balancing or whatever.

On my list of things to do is a module that is able to locate backend 
servers using zeroconf/bonjour, and this sounds similar (although not 
the same, obviously).

Does a generalised server-wide hook/provider exist to do "lookups", 
where a lookup could be something trivial, like round robin DNS, to 
something more complex, such as what you're proposing?

Regards,
Graham
--

Re: [PROPOSAL] mod_cloudbeat

[Paul Querna <pa...@querna.org>]

On Sun, Mar 29, 2009 at 6:00 PM, Graham Leggett <mi...@sharp.fm> wrote:
> Paul Querna wrote:
>
>> The (vaporware) solution: mod_cloudbeat automatically finds all of your
>> nodes,
>> both front end load balancers and backend application servers.  All load
>> balancing is completely configurationless if using mod_serf -- you just
>> turn on a new application server instance, and mod_cloudbeat picks it up.
>
> You're describing mod_backhand, as I recall.

no, this is just a utility module, which tells you where other members are.

second, mod_backhand has never been ported to 2.x, and it does allow
you to autoconfigure on cloud-enviroments, which mostly do not have
private VLANs for multicast.

I'm trying to keep it as a simple module that does a small number of
utility tasks well, and then it provides this information for other
people and modules to use -- mod_serf or mod_proxy can consume that
data to do proxying/load balancing or whatever.

Re: 2.4 or 3.0 ? (Was: Re: [PROPOSAL] mod_cloudbeat)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Jim Jagielski wrote:
> due to the refactorings as well. Does it make sense to branch
> off 2.4 before we go further?

Nah... 2.4?  3.0?  That seems like a value judgement once things
stabilize.

We can leave out 'not yet ready' modules.  We shouldn't leave out
the changes required to core; we needed them - why wouldn't other
dev author folks need them?

2.4 or 3.0 ? (Was: Re: [PROPOSAL] mod_cloudbeat)

[Jim Jagielski <ji...@jaguNET.com>]

On Mar 29, 2009, at 1:32 PM, Paul Querna wrote:

> On Sun, Mar 29, 2009 at 7:28 PM, ntwrkd <nt...@gmail.com> wrote:
>> Can you explain why this would not be accomplishable through
>> mod_proxy_balancer and would merit it's own module?
>
> 1) it is not currently possibly to add proxy workers without a
> graceful restart, meaning you either need to script or have an admin
> do something every time you add a node in the cloud.
>

Currently, yes, but it's not something that could not be
somewhat easily added. The main reason for slotmem is
to provide for that... being able to organically grow and
shrink shared-mem is next.

> 2) I am tired of monolithic modules like mod_proxy -- mod_heartbeat,
> mod_heartmonitor are good examples, they do one thing, and provide
> that information to other modules to use, they aren't the 'entire
> stack' in one module -- which is what doing it directly in
> mod_proxy_balancer would do.  mod_proxy's internals also need serious
> rethought, any time you have structures with 50+ members, we did
> something wrong in the design.
>
>>

+1...

Question time: With the vast number of changes going on,
it appears that we are not so much stabilizing trunk as we
are adding stuff to it. This is OK, but it also means that
using trunk as a starting point for our next new version
is becoming more difficult, not less. Plus, since we seem
to be extending the time for that to happen, we are making
potential backports from trunk to httpd-2.2 more difficult
due to the refactorings as well. Does it make sense to branch
off 2.4 before we go further?

Personally, I like the mod_serf stuff very much, but am having
a tough time keeping track of the serious amount of work being
done, and so cannot provide any real useful feedback or patches
until I try to follow what's been going on and understand before
I make stupid mistakes....

Re: [PROPOSAL] mod_cloudbeat

[Paul Querna <pa...@querna.org>]

On Sun, Mar 29, 2009 at 7:28 PM, ntwrkd <nt...@gmail.com> wrote:
> Can you explain why this would not be accomplishable through
> mod_proxy_balancer and would merit it's own module?

1) it is not currently possibly to add proxy workers without a
graceful restart, meaning you either need to script or have an admin
do something every time you add a node in the cloud.

2) I am tired of monolithic modules like mod_proxy -- mod_heartbeat,
mod_heartmonitor are good examples, they do one thing, and provide
that information to other modules to use, they aren't the 'entire
stack' in one module -- which is what doing it directly in
mod_proxy_balancer would do.  mod_proxy's internals also need serious
rethought, any time you have structures with 50+ members, we did
something wrong in the design.

> I think also mod_rest_cache could be utilized to invalidate objects
> throughout various cloud CDN's.

I'm not entirely sure what this means, but I assume you want the
ability to send PURGE requests to servers to clear their on disk
caches?

Thanks,

Paul

Re: [PROPOSAL] mod_cloudbeat

[ntwrkd <nt...@gmail.com>]

Can you explain why this would not be accomplishable through
mod_proxy_balancer and would merit it's own module?
I think also mod_rest_cache could be utilized to invalidate objects
throughout various cloud CDN's.

On Sun, Mar 29, 2009 at 9:35 AM, Sander Temme <sc...@apache.org> wrote:
>
> On Mar 29, 2009, at 9:00 AM, Graham Leggett wrote:
>
>> Paul Querna wrote:
>>
>>> The (vaporware) solution: mod_cloudbeat automatically finds all of your
>>> nodes,
>>> both front end load balancers and backend application servers.  All load
>>> balancing is completely configurationless if using mod_serf -- you just
>>> turn on a new application server instance, and mod_cloudbeat picks it up.
>>
>> You're describing mod_backhand, as I recall.
>
>
> If I recall correctly, mod_backhand was "SYN arrives at cluster member, may
> be ACKed by another cluster member".  This is more about dynamically finding
> out who the cluster members are.
>
> S.
>
> --
> Sander Temme
> sctemme@apache.org
> PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF
>
>
>
>

Re: [PROPOSAL] mod_cloudbeat

[Sander Temme <sc...@apache.org>]

On Mar 29, 2009, at 9:00 AM, Graham Leggett wrote:

> Paul Querna wrote:
>
>> The (vaporware) solution: mod_cloudbeat automatically finds all of  
>> your nodes,
>> both front end load balancers and backend application servers.  All  
>> load
>> balancing is completely configurationless if using mod_serf -- you  
>> just
>> turn on a new application server instance, and mod_cloudbeat picks  
>> it up.
>
> You're describing mod_backhand, as I recall.


If I recall correctly, mod_backhand was "SYN arrives at cluster  
member, may be ACKed by another cluster member".  This is more about  
dynamically finding out who the cluster members are.

S.

-- 
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF

Re: [PROPOSAL] mod_cloudbeat

[Graham Leggett <mi...@sharp.fm>]

Paul Querna wrote:

> The (vaporware) solution: mod_cloudbeat automatically finds all of your nodes,
> both front end load balancers and backend application servers.  All load
> balancing is completely configurationless if using mod_serf -- you just
> turn on a new application server instance, and mod_cloudbeat picks it up.

You're describing mod_backhand, as I recall.

Regards,
Graham
--