1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
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>
|
