httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject [PROPOSAL] mod_cloudbeat
Date Sun, 29 Mar 2009 15:43:51 GMT
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

Mime
View raw message