diff options
Diffstat (limited to 'src/documentation/content/xdocs/ClusteringAndFederation.html')
| -rwxr-xr-x | src/documentation/content/xdocs/ClusteringAndFederation.html | 135 |
1 files changed, 135 insertions, 0 deletions
diff --git a/src/documentation/content/xdocs/ClusteringAndFederation.html b/src/documentation/content/xdocs/ClusteringAndFederation.html new file mode 100755 index 0000000000..9bf1b10cbe --- /dev/null +++ b/src/documentation/content/xdocs/ClusteringAndFederation.html @@ -0,0 +1,135 @@ +<html> + <head> + <title>Apache Qpid : ClusteringAndFederation</title> + <link rel="stylesheet" href="styles/site.css" type="text/css" /> + <META http-equiv="Content-Type" content="text/html; charset=UTF-8"> + </head> + + <body> + <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff"> + <tr> + <td valign="top" class="pagebody"> + <div class="pageheader"> + <span class="pagetitle"> + Apache Qpid : ClusteringAndFederation + </span> + </div> + <div class="pagesubheading"> + This page last changed on Oct 19, 2006 by <font color="#0050B2">mmccorma</font>. + </div> + + <h1><a name="ClusteringAndFederation-ClusteringAndFederation"></a>Clustering And Federation</h1> + +<p>Each diagram below depicts a distributed network of exchanges and queues. The following notation is used in all diagrams:</p> +<ul> + <li>M: message</li> + <li>E: exchange</li> + <li>Q: queue</li> +</ul> + + +<h2><a name="ClusteringAndFederation-Multicast"></a>Multicast</h2> + +<div class="preformatted"><div class="preformattedContent"> +<pre> M1...Mn
+ +--------> Q
+ |
+ | M1...Mn
+ M1...Mn ---> E----+--------> Q
+ |
+ | M1...Mn
+ +--------> Q
+</pre> +</div></div> + +<p>Queue contents are duplicated across all queues. For this scenario PGM<br/> +would be ideal between E and Q, or even directly between E and<br/> +consumers.</p> + +<h2><a name="ClusteringAndFederation-LoadBalancing"></a>Load Balancing </h2> + +<div class="preformatted"><div class="preformattedContent"> +<pre> M1
+ +--------> Q
+ |
+ | ...
+ M1...Mn ---> E----+--------> Q
+ |
+ | Mn
+ +--------> Q
+</pre> +</div></div> + +<p>No ordering is guaranteed accross different queues. A naive<br/> +implementation could just be an exchange doing round-robin routing or<br/> +any algorithm of choice. A more complicated exchange could have flow<br/> +control between each queue and the exchange.</p> + +<h2><a name="ClusteringAndFederation-MultipleExchanges"></a>Multiple Exchanges </h2> + +<div class="preformatted"><div class="preformattedContent"> +<pre> M? ---> E1-----+ +-----> Q1
+ | |
+ | (n*m arrows) |
+ M? ---> E2-----+--------------+-----> Q2
+ | |
+ | |
+ M? ---> En-----+ +-----> Qm
+</pre> +</div></div> + +<p>Both the Load Balancing and Multicast scenarios can be extended by<br/> +adding multiple exchange nodes wired into the same (or an overlapping)<br/> +set of queues. One virtual mega exchange (with relaxed ordering<br/> +semantics) could be created by segmenting client connections between<br/> +exchanges. This could be done using a number of strategies, e.g.<br/> +round-robin dns, name mangling, redirects.</p> + +<p>The topologies described above could in theory be use in a variety of<br/> +scenarios ranging from an an isolated high speed subnet with<br/> +identically configured nodes to a loosely coupled WAN with separately<br/> +administered nodes. In fact a single network could include exchanges<br/> +bound to local queues, remote queues available on an isolated high<br/> +speed subnet, and remote destinations (exchange or queue) available<br/> +over WAN/internet. In the last case the exchange may be requred to<br/> +queue messages routed to the remote destination if the WAN/internet<br/> +link is down.</p> + +<p>In the terminology I've been using, a cluster is a set of machines<br/> +sharing the same software and configuration, and generally connected<br/> +via an isolated high speed subnet. A federation on the other hand<br/> +consists of distinctly configured machines individually wired<br/> +together. Both clustering and federation <b>could</b> share a common<br/> +protocol for message delivery. This could possibly even be used for<br/> +multicast if it were a simple stateless store-and-forward protocol.<br/> +(Note the "store" in "store-and-forward" can mean both store on disk<br/> +and store in memory.)</p> + +<p>With this model the key distinction between a cluster and a federation<br/> +is that all the nodes in a cluster are managed as a single unit, e.g.<br/> +one place to start/stop/add/remove/etc. Because of this the nodes in a<br/> +cluster have to pass control messages to each other distinct from the<br/> +general message traffic. These control messages need to be isolated<br/> +from the general message traffic (e.g. on their own subnet). This<br/> +could be done using JGroups and OpenAIS for Java and C++ respectively.</p> + +<p>This document doesn't directly address fault tolerance, but it is<br/> +assumed that any node/broker that contains state can be configured to<br/> +have a passive counterpart that supports two methodologies for<br/> +failover. Broker swapout based on virtual IP, or client reconnect to a<br/> +backup IP.</p> + + + </td> + </tr> + </table> + <table border="0" cellpadding="0" cellspacing="0" width="100%"> + <tr> + <td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td> + </tr> + <tr> + <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td> + </tr> + </table> + </body> +</html>
\ No newline at end of file |