HTTPS clone URL
Subversion checkout URL
Daemon for zero-configuration management of a heterogeneous cluster of backend web servers and the accompanying libraries.
C++ Ruby Shell
Fetching latest commit...
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
|CMakeLists.txt||Add debug info to the build.|
CloudBridge --- Cloudbridge is a server that sits between your front-end webservers (apache/nginx/etc) and your application servers (currently rails using mongrel). It has the advantage over traditional appserver clustering techniques of limiting the amount of configuration required while also improving worst case behaviour. In the traditional setup, you have a frontend server doing reverse proxy requests to backend app servers. This setup is a huge win over directly exposing your backend servers because it allows for load balancing, optimized resource usage (heavy on memory backends aren't sitting idle waiting for a client to close their connection), and good scalability (since you can add backend nodes with no external configuration changes). However, this configuration has the disadvantage of causing an increase in maintenance effort in that when a backend is disabled or goes down unexpectedly, the frontend server must either be told about this or discover it. If it does not, this usually results in hung connections or broken requests for the user at worst, or extremely more complex frontend servers at best. Cloudbridge works to avoid this situation by reversing the connection to the backend. It is a reverse-reverse proxy. In cloudbridge's system, the backends and frontends both connect to cloudbridge, and it matches connections based on hostname. When a backend goes down or comes up, it simply stops or starts sending requests to cloudbridge, and no additional configuration is needed. Cloudbridge is not the only solution to employ this technique. At the very least, there is also swiftiply and probably other more proprietary solutions. Where cloudbridge goes one step beyond swiftiply is in the fact that it requires no configuration for backend hosts. By using an HTTP protocol extension (the BRIDGE request documented in doc/protocol.txt), it allows the backend to specify what host it is listening for. This makes setting up a hosting cluster extremely easy. In order to prevent unauthorized access to a domain, the cloudbridge server may be configured to require a key to be presented to the server in the BRIDGE request that authenticates its ownership over that host name. This allows also for the open-cloudbridge technique, which is demonstrated on oncloud.org. You can use oncloud.org to experiment with the system. Instructions are presented there.