Modified: qpid/site/docs/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Active_Passive_Cluster.html URL: http://svn.apache.org/viewvc/qpid/site/docs/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Active_Passive_Cluster.html?rev=1368244&r1=1368243&r2=1368244&view=diff ============================================================================== --- qpid/site/docs/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Active_Passive_Cluster.html (original) +++ qpid/site/docs/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Active_Passive_Cluster.html Wed Aug 1 20:54:46 2012 @@ -1,31 +1,66 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>1.13. Active-passive Messaging Clusters (Preview)</title><link rel="stylesheet" type="text/css" href="css/style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"><link rel="home" href="index.html" title="AMQP Messaging Broker (Implemented in C++)"><link rel="up" href="ch01.html" title="Chapter 1. Running the AMQP Messaging Broker"><link rel="prev" href="Using-message-groups.html" title="1.12. Using Message Groups"><link rel="next" href="ch01s14.html" title="1.14. Queue Replication with the HA module"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">1.13. Active-passive Messaging Clusters (Preview)</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="Using-message-groups.html">Prev</a> </td><th width="60%" align="center">Chapter 1. +<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>1.13. Active-passive Messaging Clusters</title><link rel="stylesheet" type="text/css" href="css/style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"><link rel="home" href="index.html" title="AMQP Messaging Broker (Implemented in C++)"><link rel="up" href="ch01.html" title="Chapter 1. Running the AMQP Messaging Broker"><link rel="prev" href="Using-message-groups.html" title="1.12. Using Message Groups"><link rel="next" href="ch01s14.html" title="1.14. Queue Replication with the HA module"></head><body><div class="container" bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><DIV class="header"><DIV class="logo"><H1>Apache Qpidâ¢</H1><H2>Open Source AMQP Messaging</H2></DIV></DIV><DIV class="menu_box"><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>Apache Qpid</H3><UL><LI><A href="http://qpid.apache.org/index. html">Home</A></LI><LI><A href="http://qpid.apache.org/download.html";>Download</A></LI><LI><A href="http://qpid.apache.org/getting_started.html";>Getting Started</A></LI><LI><A href="http://www.apache.org/licenses/";>License</A></LI><LI><A href="https://cwiki.apache.org/qpid/faq.html";>FAQ</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>Documentation</H3><UL><LI><A href="http://qpid.apache.org/documentation.html#doc-release";>0.14 Release</A></LI><LI><A href="http://qpid.apache.org/documentation.html#doc-trunk";>Trunk</A></LI><LI><A href="http://qpid.apache.org/documentation.html#doc-archives";>Archive</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>Community</H3><UL><LI><A href="http://qpid.apache.org/getting_involved.html";>Getting Involved</A></LI><LI><A href="http://qpid.apache.org/source_repository.html";>Source Repository</A></LI><LI><A href ="http://qpid.apache.org/mailing_lists.html";>Mailing Lists</A></LI><LI><A href="https://cwiki.apache.org/qpid/";>Wiki</A></LI><LI><A href="https://issues.apache.org/jira/browse/qpid";>Issue Reporting</A></LI><LI><A href="http://qpid.apache.org/people.html";>People</A></LI><LI><A href="http://qpid.apache.org/acknowledgements.html";>Acknowledgements</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>Developers</H3><UL><LI><A href="https://cwiki.apache.org/qpid/building.html";>Building Qpid</A></LI><LI><A href="https://cwiki.apache.org/qpid/developer-pages.html";>Developer Pages</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>About AMQP</H3><UL><LI><A href="http://qpid.apache.org/amqp.html";>What is AMQP?</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>About Apache</H3><UL><LI><A href ="http://www.apache.org";>Home</A></LI><LI><A href="http://www.apache.org/foundation/sponsorship.html";>Sponsorship</A></LI><LI><A href="http://www.apache.org/foundation/thanks.html";>Thanks</A></LI><LI><A href="http://www.apache.org/security/";>Security</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV></DIV><div class="main_text_area"><div class="main_text_area_top"></div><div class="main_text_area_body"><DIV class="breadcrumbs"><span class="breadcrumb-link"><a href="index.html">AMQP Messaging Broker (Implemented in C++)</a></span> > <span class="breadcrumb-link"><a href="ch01.html"> Running the AMQP Messaging Broker - </th><td width="20%" align="right"> <a accesskey="n" href="ch01s14.html">Next</a></td></tr></table><hr></div><div class="section" title="1.13. Active-passive Messaging Clusters (Preview)"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="chap-Messaging_User_Guide-Active_Passive_Cluster"></a>1.13. Active-passive Messaging Clusters (Preview)</h2></div></div></div><div class="section" title="1.13.1. Overview"><div class="titlepage"><div><div><h3 class="title"><a name="id579486"></a>1.13.1. Overview</h3></div></div></div><p> - This release provides a preview of a new module for High Availability (HA). The new module is - not yet complete or ready for production use. It being made available so that users can - experiment with the new approach and provide feedback early in the development process. - Feedback should go to <a class="ulink" href="mailto:[email protected]"; target="_top">[email protected]</a>. - </p><p> - The old cluster module takes an <em class="firstterm">active-active</em> approach, i.e. all the - brokers in a cluster are able to handle client requests simultaneously. The new HA module - takes an <em class="firstterm">active-passive</em>, <em class="firstterm">hot-standby</em> approach. - </p><p> - In an active-passive cluster only one broker, known as the <em class="firstterm">primary</em>, is - active and serving clients at a time. The other brokers are standing by as - <em class="firstterm">backups</em>. Changes on the primary are immediately replicated to all the - backups so they are always up-to-date or "hot". If the primary fails, one of the backups is - promoted to take over as the new primary. Clients fail-over to the new primary - automatically. If there are multiple backups, the backups also fail-over to become backups of - the new primary. Backup brokers reject connection attempts, to enforce the requirement that - only the primary be active. + </a></span> > <span class="breadcrumb-node">Active-passive Messaging Clusters</span></DIV><div class="section" title="1.13. Active-passive Messaging Clusters"><div class="titlepage"><div><div><h2 class="title"><a name="chap-Messaging_User_Guide-Active_Passive_Cluster"></a>1.13. Active-passive Messaging Clusters</h2></div></div></div><div class="section" title="1.13.1. Overview"><div class="titlepage"><div><div><h3 class="title"><a name="id480158"></a>1.13.1. Overview</h3></div></div></div><p> + + The High Availability (HA) module provides + <em class="firstterm">active-passive</em>, <em class="firstterm">hot-standby</em> + messaging clusters to provide fault tolerant message delivery. + </p><p> + In an active-passive cluster only one broker, known as the + <em class="firstterm">primary</em>, is active and serving clients at a time. The other + brokers are standing by as <em class="firstterm">backups</em>. Changes on the primary + are replicated to all the backups so they are always up-to-date or "hot". Backup + brokers reject client connection attempts, to enforce the requirement that clients + only connect to the primary. + </p><p> + If the primary fails, one of the backups is promoted to take over as the new + primary. Clients fail-over to the new primary automatically. If there are multiple + backups, the other backups also fail-over to become backups of the new primary. </p><p> - This approach depends on an external <em class="firstterm">cluster resource manager</em> to detect - failures and choose the primary. <a class="ulink" href="https://fedorahosted.org/cluster/wiki/RGManager"; target="_top">Rgmanager</a> is supported + This approach relies on an external <em class="firstterm">cluster resource manager</em> + to detect failures, choose the new primary and handle network partitions. <a class="ulink" href="https://fedorahosted.org/cluster/wiki/RGManager"; target="_top">Rgmanager</a> is supported initially, but others may be supported in the future. - </p><div class="section" title="1.13.1.1. Why the new approach?"><div class="titlepage"><div><div><h4 class="title"><a name="id582994"></a>1.13.1.1. Why the new approach?</h4></div></div></div><p> - The new active-passive approach has several advantages compared to the - existing active-active cluster module. - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> + </p><div class="section" title="1.13.1.1. Avoiding message loss"><div class="titlepage"><div><div><h4 class="title"><a name="id505341"></a>1.13.1.1. Avoiding message loss</h4></div></div></div><p> + In order to avoid message loss, the primary broker <span class="emphasis"><em>delays + acknowledgment</em></span> of messages received from clients until the + message has been replicated to and acknowledged by all of the back-up + brokers. + </p><p> + Clients buffer unacknowledged messages and re-send them in the event of + a fail-over. + <sup>[<a name="id508619" href="#ftn.id508619" class="footnote">1</a>]</sup> + If the primary crashes before a message is replicated to + all the backups, the client will re-send the message when it fails over + to the new primary. + </p><p> + Note that this means it is possible for messages to be + <span class="emphasis"><em>duplicated</em></span>. In the event of a failure it is + possible for a message to be both received by the backup that becomes + the new primary <span class="emphasis"><em>and</em></span> re-sent by the client. + </p><p> + When a new primary is promoted after a fail-over it is initially in + "recovering" mode. In this mode, it delays acknowledgment of messages + on behalf of all the backups that were connected to the previous + primary. This protects those messages against a failure of the new + primary until the backups have a chance to connect and catch up. + </p><div class="variablelist" title="Status of a HA broker"><p class="title"><b>Status of a HA broker</b></p><dl><dt><span class="term">Joining</span></dt><dd><p> + Initial status of a new broker that has not yet connected to the primary. + </p></dd><dt><span class="term">Catch-up</span></dt><dd><p> + A backup broker that is connected to the primary and catching up + on queues and messages. + </p></dd><dt><span class="term">Ready</span></dt><dd><p> + A backup broker that is fully caught-up and ready to take over as + primary. + </p></dd><dt><span class="term">Recovering</span></dt><dd><p> + The newly-promoted primary, waiting for backups to connect and catch up. + </p></dd><dt><span class="term">Active</span></dt><dd><p> + The active primary broker with all backups connected and caught-up. + </p></dd></dl></div></div><div class="section" title="1.13.1.2. Replacing the old cluster module"><div class="titlepage"><div><div><h4 class="title"><a name="id506620"></a>1.13.1.2. Replacing the old cluster module</h4></div></div></div><p> + The High Availability (HA) module replaces the previous + <em class="firstterm">active-active</em> cluster module. The new active-passive + approach has several advantages compared to the existing active-active cluster + module. + </p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"> It does not depend directly on openais or corosync. It does not use multicast which simplifies deployment. </li><li class="listitem"> @@ -39,51 +74,36 @@ It can take advantage of features provided by the resource manager, for example virtual IP addresses. </li><li class="listitem"> - Improved performance and scalability due to better use of multiple CPU s + Improved performance and scalability due to better use of multiple CPUs </li></ul></div><p> - </p></div><div class="section" title="1.13.1.2. Limitations"><div class="titlepage"><div><div><h4 class="title"><a name="id579804"></a>1.13.1.2. Limitations</h4></div></div></div><p> + </p></div><div class="section" title="1.13.1.3. Limitations"><div class="titlepage"><div><div><h4 class="title"><a name="id509006"></a>1.13.1.3. Limitations</h4></div></div></div><p> There are a number of known limitations in the current preview implementation. These will be fixed in the production versions. - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> + </p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"> Transactional changes to queue state are not replicated atomically. If the primary crashes during a transaction, it is possible that the backup could contain only part of the changes introduced by a transaction. </li><li class="listitem"> - During a fail-over one backup is promoted to primary and any other backups switch to - the new primary. Messages sent to the new primary before all the backups have - switched could be lost if the new primary itself fails before all the backups have - switched. - </li><li class="listitem"> - Acknowledgments are confirmed to clients before the message has been dequeued - from replicas or indeed from the local store if that is asynchronous. - </li><li class="listitem"> - When used with a persistent store: if the entire cluster fails, there are no tools to help - identify the most recent store. - </li><li class="listitem"> - A persistent broker must have its store erased before joining an existing cluster. - In the production version a persistent broker will be able to load its store and - avoid downloading messages that are in the store from the primary. + Not yet integrated with the persistent store. A persistent broker must have its + store erased before joining an existing cluster. If the entire cluster fails, + there are no tools to help identify the most recent store. In the future a + persistent broker will be able to use its stored messages to avoid downloading + messages from the primary when joining a cluster. </li><li class="listitem"> Configuration changes (creating or deleting queues, exchanges and bindings) are - replicated asynchronously. Management tools used to make changes will consider the - change complete when it is complete on the primary, it may not yet be replicated - to all the backups. - </li><li class="listitem"> - Deletions made immediately after a failure (before all the backups are ready) may - be lost on a backup. Queues, exchange or bindings that were deleted on the primary could - re-appear if that backup is promoted to primary on a subsequent failure. - </li><li class="listitem"> - Better control is needed over which queues/exchanges are replicated and which are not. - </li><li class="listitem"> - There are some known issues affecting performance, both the throughput of - replication and the time taken for backups to fail-over. Performance will improve - in the production version. - </li><li class="listitem"> - Federated links from the primary will be lost in fail over, they will not be - re-connected on the new primary. Federation links to the primary can fail over. - </li><li class="listitem"> - Only plain FIFO queues can be replicated. LVQ and ring queues are not yet supported. - </li></ul></div></div></div><div class="section" title="1.13.2. Virtual IP Addresses"><div class="titlepage"><div><div><h3 class="title"><a name="id585587"></a>1.13.2. Virtual IP Addresses</h3></div></div></div><p> + replicated asynchronously. Management tools used to make changes will consider + the change complete when it is complete on the primary, it may not yet be + replicated to all the backups. + </li><li class="listitem"> + Deletions made immediately after a failure (before all the backups are ready) + may be lost on a backup. Queues, exchange or bindings that were deleted on the + primary could re-appear if that backup is promoted to primary on a subsequent + failure. + </li><li class="listitem"> + Federated links <span class="emphasis"><em>from</em></span> the primary will be lost in fail over, + they will not be re-connected to the new primary. Federation links + <span class="emphasis"><em>to</em></span> the primary can fail over. + </li></ul></div></div></div><div class="section" title="1.13.2. Virtual IP Addresses"><div class="titlepage"><div><div><h3 class="title"><a name="id485468"></a>1.13.2. Virtual IP Addresses</h3></div></div></div><p> Some resource managers (including <span class="command"><strong>rgmanager</strong></span>) support <em class="firstterm">virtual IP addresses</em>. A virtual IP address is an IP address that can be relocated to any of the nodes in a cluster. The @@ -95,69 +115,85 @@ A virtual IP address can be used by clients and backup brokers to connect to the primary. The following sections will explain how to configure virtual IP addresses for clients or brokers. - </p></div><div class="section" title="1.13.3. Configuring the Brokers"><div class="titlepage"><div><div><h3 class="title"><a name="id576940"></a>1.13.3. Configuring the Brokers</h3></div></div></div><p> + </p></div><div class="section" title="1.13.3. Configuring the Brokers"><div class="titlepage"><div><div><h3 class="title"><a name="id504207"></a>1.13.3. Configuring the Brokers</h3></div></div></div><p> The broker must load the <code class="filename">ha</code> module, it is loaded by default. The following broker options are available for the HA module. - </p><div class="table"><a name="ha-broker-options"></a><p class="title"><b>Table 1.18. Options for High Availability Messaging Cluster</b></p><div class="table-contents"><table summary="Options for High Availability Messaging Cluster" border="1"><colgroup><col align="left" class="c1"><col align="left" class="c2"></colgroup><thead><tr><th colspan="2" align="center"> + </p><div class="table"><a name="ha-broker-options"></a><p class="title"><b>Table 1.18. Broker Options for High Availability Messaging Cluster</b></p><div class="table-contents"><table summary="Broker Options for High Availability Messaging Cluster" border="1"><colgroup><col align="left" class="c1"><col align="left" class="c2"></colgroup><thead><tr><th colspan="2" align="center"> Options for High Availability Messaging Cluster </th></tr></thead><tbody><tr><td align="left"> - <code class="literal">--ha-cluster <em class="replaceable"><code>yes|no</code></em></code> + <code class="literal">ha-cluster <em class="replaceable"><code>yes|no</code></em></code> </td><td align="left"> Set to "yes" to have the broker join a cluster. </td></tr><tr><td align="left"> - <code class="literal">--ha-brokers <em class="replaceable"><code>URL</code></em></code> + <code class="literal">ha-brokers-url <em class="replaceable"><code>URL</code></em></code> </td><td align="left"> <p> The URL - <sup>[<a name="id571870" href="#ftn.id571870" class="footnote">a</a>]</sup> - used by brokers to connect to each other. If you use a virtual IP address - then this is a single address, for example - <code class="literal">amqp:20.0.20.200</code>. If you do not use a virtual IP - address then the URL must list all the addresses of brokers in the - cluster, for example <code class="literal">amqp:node1,node2,node3</code> + <sup>[<a name="id478976" href="#ftn.id478976" class="footnote">a</a>]</sup> + used by cluster brokers to connect to each other. The URL can + contain a list of all the broker addresses or it can contain a single + virtual IP address. If a list is used it is comma separated, for example + <code class="literal">amqp:node1.exaple.com,node2.exaple.com,node3.exaple.com</code> </p> - </td></tr><tr><td align="left"><code class="literal">--ha-public-brokers <em class="replaceable"><code>URL</code></em></code> </td><td align="left"> + </td></tr><tr><td align="left"><code class="literal">ha-public-url <em class="replaceable"><code>URL</code></em></code> </td><td align="left"> <p> - The URL used by clients to connect to the brokers. This has the same - format as the <code class="literal">--ha-brokers</code> URL above. + The URL that is advertised to clients. This defaults to the + <code class="literal">ha-brokers-url</code> URL above, and has the same format. A + virtual IP address is recommended for the public URL as it simplifies + deployment and hides changes to the cluster membership from clients. </p> <p> - If this option is not set, clients will use the same URL as brokers. This option allows you to put client traffic on a different network from broker traffic, which is recommended. </p> - </td></tr><tr><td align="left"><code class="literal">--ha-replicate</code></td><td align="left"> - <p> + </td></tr><tr><td align="left"><code class="literal">ha-replicate </code><em class="replaceable"><code>VALUE</code></em></td><td align="left"> + <p> Specifies whether queues and exchanges are replicated by default. - For details see <a class="xref" href="">???</a> + <em class="replaceable"><code>VALUE</code></em> is one of: <code class="literal">none</code>, + <code class="literal">configuration</code>, <code class="literal">all</code>. + For details see <a class="xref" href="chap-Messaging_User_Guide-Active_Passive_Cluster.html#ha-creating-replicated" title="1.13.7. Creating replicated queues and exchanges">Section 1.13.7, âCreating replicated queues and exchangesâ</a>. </p> </td></tr><tr><td align="left"> - <p><code class="literal">--ha-username <em class="replaceable"><code>USER</code></em></code></p> - <p><code class="literal">--ha-password <em class="replaceable"><code>PASS</code></em></code></p> - <p><code class="literal">--ha-mechanism <em class="replaceable"><code>MECH</code></em></code></p> + <p><code class="literal">ha-username <em class="replaceable"><code>USER</code></em></code></p> + <p><code class="literal">ha-password <em class="replaceable"><code>PASS</code></em></code></p> + <p><code class="literal">ha-mechanism <em class="replaceable"><code>MECH</code></em></code></p> </td><td align="left"> - Authentication settings used by brokers to connect to each other. - </td></tr></tbody><tbody class="footnotes"><tr><td colspan="2"><div class="footnote"><p><sup>[<a id="ftn.id571870" href="#id571870" class="para">a</a>] </sup> + Authentication settings used by HA brokers to connect to each other. + If you are using authorization + (<a class="xref" href="chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Authorization" title="1.5.2. Authorization">Section 1.5.2, âAuthorizationâ</a>) + then this user must have all permissions. + </td></tr><tr><td align="left"><code class="literal">ha-backup-timeout <em class="replaceable"><code>SECONDS</code></em></code> </td><td align="left"> + <p> + Maximum time that a recovering primary will wait for an expected + backup to connect and become ready. + </p> + </td></tr><tr><td align="left"><code class="literal">link-maintenance-interval <em class="replaceable"><code>SECONDS</code></em></code></td><td align="left"> + <p> + Interval for the broker to check link health and re-connect links if need + be. If you want brokers to fail over quickly you can set this to a + fraction of a second, for example: 0.1. + </p> + </td></tr></tbody><tbody class="footnotes"><tr><td colspan="2"><div class="footnote"><p><sup>[<a id="ftn.id478976" href="#id478976" class="para">a</a>] </sup> The full format of the URL is given by this grammar: </p><pre class="programlisting"> - url = ["amqp:"][ user ["/" password] "@" ] addr ("," addr)* - addr = tcp_addr / rmda_addr / ssl_addr / ... - tcp_addr = ["tcp:"] host [":" port] - rdma_addr = "rdma:" host [":" port] - ssl_addr = "ssl:" host [":" port]' +url = ["amqp:"][ user ["/" password] "@" ] addr ("," addr)* +addr = tcp_addr / rmda_addr / ssl_addr / ... +tcp_addr = ["tcp:"] host [":" port] +rdma_addr = "rdma:" host [":" port] +ssl_addr = "ssl:" host [":" port]' </pre><p> </p></div></td></tr></tbody></table></div></div><br class="table-break"><p> To configure a HA cluster you must set at least <code class="literal">ha-cluster</code> and - <code class="literal">ha-brokers</code>. - </p></div><div class="section" title="1.13.4. The Cluster Resource Manager"><div class="titlepage"><div><div><h3 class="title"><a name="id565105"></a>1.13.4. The Cluster Resource Manager</h3></div></div></div><p> + <code class="literal">ha-brokers-url</code>. + </p></div><div class="section" title="1.13.4. The Cluster Resource Manager"><div class="titlepage"><div><div><h3 class="title"><a name="id515081"></a>1.13.4. The Cluster Resource Manager</h3></div></div></div><p> Broker fail-over is managed by a <em class="firstterm">cluster resource manager</em>. An integration with <a class="ulink" href="https://fedorahosted.org/cluster/wiki/RGManager"; target="_top">rgmanager</a> is provided, but it is possible to integrate with other resource managers. </p><p> The resource manager is responsible for starting the <span class="command"><strong>qpidd</strong></span> broker - on each node in the cluster. The resource manager <em class="firstterm">promotes</em> + on each node in the cluster. The resource manager then <em class="firstterm">promotes</em> one of the brokers to be the primary. The other brokers connect to the primary as - backups, using the URL provided in the <code class="literal">ha-brokers</code> configuration + backups, using the URL provided in the <code class="literal">ha-brokers-url</code> configuration option. </p><p> Once connected, the backup brokers synchronize their state with the @@ -175,7 +211,7 @@ network partition divide a cluster into two sub-groups which cannot see each other. Usually a <em class="firstterm">quorum</em> voting algorithm is used that disables nodes in the inquorate sub-group. - </p></div><div class="section" title="1.13.5. Configuring rgmanager as resource manager"><div class="titlepage"><div><div><h3 class="title"><a name="id554322"></a>1.13.5. Configuring <span class="command"><strong>rgmanager</strong></span> as resource manager</h3></div></div></div><p> + </p></div><div class="section" title="1.13.5. Configuring rgmanager as resource manager"><div class="titlepage"><div><div><h3 class="title"><a name="id502213"></a>1.13.5. Configuring <span class="command"><strong>rgmanager</strong></span> as resource manager</h3></div></div></div><p> This section assumes that you are already familiar with setting up and configuring clustered services using <span class="command"><strong>cman</strong></span> and <span class="command"><strong>rgmanager</strong></span>. It will show you how to configure an active-passive, @@ -191,45 +227,42 @@ <!-- This is an example of a cluster.conf file to run qpidd HA under rgmanager. This example assumes a 3 node cluster, with nodes named node1, node2 and node3. + +NOTE: fencing is not shown, you must configure fencing appropriately for your cluster. --> <cluster name="qpid-test" config_version="18"> - <!-- The cluster has 3 nodes. Each has a unique nodid and one vote for quorum. --> + <!-- The cluster has 3 nodes. Each has a unique nodid and one vote + for quorum. --> <clusternodes> - <clusternode name="node1" nodeid="1"> - <fence/> - </clusternode> - <clusternode name="node2" nodeid="2"> - <fence/> - </clusternode> - <clusternode name="node3" nodeid="3"> - <fence/> - </clusternode> + <clusternode name="node1.example.com" nodeid="1"/> + <clusternode name="node2.example.com" nodeid="2"/> + <clusternode name="node3.example.com" nodeid="3"/> </clusternodes> <!-- Resouce Manager configuration. --> - <rm log_level="7"> <!-- Verbose logging --> + <rm> <!-- There is a failoverdomain for each node containing just that node. - This lets us stipulate that the qpidd service should always run on all nodes. + This lets us stipulate that the qpidd service should always run on each node. --> <failoverdomains> <failoverdomain name="node1-domain" restricted="1"> - <failoverdomainnode name="node1"/> + <failoverdomainnode name="node1.example.com"/> </failoverdomain> <failoverdomain name="node2-domain" restricted="1"> - <failoverdomainnode name="node2"/> + <failoverdomainnode name="node2.example.com"/> </failoverdomain> <failoverdomain name="node3-domain" restricted="1"> - <failoverdomainnode name="node3"/> + <failoverdomainnode name="node3.example.com"/> </failoverdomain> </failoverdomains> <resources> <!-- This script starts a qpidd broker acting as a backup. --> - <script file="!!sysconfdir!!/init.d/qpidd" name="qpidd"/> + <script file="/etc/init.d/qpidd" name="qpidd"/> <!-- This script promotes the qpidd broker on this node to primary. --> - <script file="!!sysconfdir!!/init.d/qpidd-primary" name="qpidd-primary"/> + <script file="/etc/init.d/qpidd-primary" name="qpidd-primary"/> <!-- This is a virtual IP address for broker replication traffic. --> <ip address="20.0.10.200" monitor_link="1"/> @@ -257,8 +290,6 @@ This example assumes a 3 node cluster, w <ip ref="20.0.20.200"/> </service> </rm> - <fencedevices/> - <fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/> </cluster> </pre><p> @@ -274,14 +305,14 @@ This example assumes a 3 node cluster, w </p><p> The <code class="literal">resources</code> section also defines a pair of virtual IP addresses on different sub-nets. One will be used for broker-to-broker - communication, the other for client-to-broker. + communication, the other for client-to-broker. </p><p> To take advantage of the virtual IP addresses, <code class="filename">qpidd.conf</code> should contain these lines: </p><pre class="programlisting"> ha-cluster=yes - ha-brokers=20.0.20.200 - ha-public-brokers=20.0.10.200 + ha-brokers-url=20.0.20.200 + ha-public-url=20.0.10.200 </pre><p> This configuration specifies that backup brokers will use 20.0.20.200 to connect to the primary and will advertise 20.0.10.200 to clients. @@ -301,22 +332,24 @@ This example assumes a 3 node cluster, w original node fails. Running the <code class="literal">qpidd-primary</code> script does not start a new broker process, it promotes the existing broker to become the primary. - </p></div><div class="section" title="1.13.6. Broker Administration Tools"><div class="titlepage"><div><div><h3 class="title"><a name="id546558"></a>1.13.6. Broker Administration Tools</h3></div></div></div><p> - Normally, clients are not allowed to connect to a backup broker. However management tools are - allowed to connect to a backup brokers. If you use these tools you <span class="emphasis"><em>must - not</em></span> add or remove messages from replicated queues, or delete replicated queues or - exchanges as this will corrupt the replication process and may cause message loss. + </p></div><div class="section" title="1.13.6. Broker Administration Tools"><div class="titlepage"><div><div><h3 class="title"><a name="id499259"></a>1.13.6. Broker Administration Tools</h3></div></div></div><p> + Normally, clients are not allowed to connect to a backup broker. However + management tools are allowed to connect to a backup brokers. If you use + these tools you <span class="emphasis"><em>must not</em></span> add or remove messages from + replicated queues, nor create or delete replicated queues or exchanges as + this will disrupt the replication process and may cause message loss. </p><p> <span class="command"><strong>qpid-ha</strong></span> allows you to view and change HA configuration settings. </p><p> The tools <span class="command"><strong>qpid-config</strong></span>, <span class="command"><strong>qpid-route</strong></span> and - <span class="command"><strong>qpid-stat</strong></span> will connect to a backup if you pass the flag <span class="command"><strong>--ha-admin</strong></span> on the + <span class="command"><strong>qpid-stat</strong></span> will connect to a backup if you pass the flag <span class="command"><strong>ha-admin</strong></span> on the command line. </p></div><div class="section" title="1.13.7. Creating replicated queues and exchanges"><div class="titlepage"><div><div><h3 class="title"><a name="ha-creating-replicated"></a>1.13.7. Creating replicated queues and exchanges</h3></div></div></div><p> By default, queues and exchanges are not replicated automatically. You can change the default behavior by setting the <code class="literal">ha-replicate</code> configuration option. It has one of the following values: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><em class="firstterm">all</em>: Replicate everything automatically: queues, exchanges, bindings and messages. + </p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><em class="firstterm">all</em>: Replicate everything automatically: queues, + exchanges, bindings and messages. </li><li class="listitem"><em class="firstterm">configuration</em>: Replicate the existence of queues, exchange and bindings but don't replicate messages. </li><li class="listitem"><em class="firstterm">none</em>: Don't replicate anything, this is the default. @@ -339,18 +372,18 @@ This example assumes a 3 node cluster, w <code class="literal">node</code> entry to the address like this: </p><pre class="programlisting"> "myqueue;{create:always,node:{x-declare:{arguments:{'qpid.replicate':all}}}}" - </pre></div><div class="section" title="1.13.8. Client Connection and Fail-over"><div class="titlepage"><div><div><h3 class="title"><a name="id560960"></a>1.13.8. Client Connection and Fail-over</h3></div></div></div><p> + </pre></div><div class="section" title="1.13.8. Client Connection and Fail-over"><div class="titlepage"><div><div><h3 class="title"><a name="id495282"></a>1.13.8. Client Connection and Fail-over</h3></div></div></div><p> Clients can only connect to the primary broker. Backup brokers automatically reject any connection attempt by a client. </p><p> Clients are configured with the URL for the cluster (details below for each type of client). There are two possibilities - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> + </p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"> The URL contains multiple addresses, one for each broker in the cluster. </li><li class="listitem"> The URL contains a single <em class="firstterm">virtual IP address</em> that is assigned to the primary broker by the resource manager. - <sup>[<a name="id567823" href="#ftn.id567823" class="footnote">1</a>]</sup></li></ul></div><p> + <sup>[<a name="id518923" href="#ftn.id518923" class="footnote">2</a>]</sup></li></ul></div><p> In the first case, clients will repeatedly re-try each address in the URL until they successfully connect to the primary. In the second case the resource manager will assign the virtual IP address to the primary broker, @@ -373,13 +406,15 @@ This example assumes a 3 node cluster, w Qpid</em> for details on how to keep the client aware of cluster membership. </p><p> - Suppose your cluster has 3 nodes: <code class="literal">node1</code>, <code class="literal">node2</code> - and <code class="literal">node3</code> all using the default AMQP port. To connect a client you - need to specify the address(es) and set the <code class="literal">reconnect</code> property to - <code class="literal">true</code>. Here's how to connect each type of client: - </p><div class="section" title="1.13.8.1. C++ clients"><div class="titlepage"><div><div><h4 class="title"><a name="id579791"></a>1.13.8.1. C++ clients</h4></div></div></div><p> + Suppose your cluster has 3 nodes: <code class="literal">node1</code>, + <code class="literal">node2</code> and <code class="literal">node3</code> all using the + default AMQP port, and you are not using a virtual IP address. To connect + a client you need to specify the address(es) and set the + <code class="literal">reconnect</code> property to <code class="literal">true</code>. The + following sub-sections show how to connect each type of client. + </p><div class="section" title="1.13.8.1. C++ clients"><div class="titlepage"><div><div><h4 class="title"><a name="id479991"></a>1.13.8.1. C++ clients</h4></div></div></div><p> With the C++ client, you specify multiple cluster addresses in a single URL - <sup>[<a name="id579255" href="#ftn.id579255" class="footnote">2</a>]</sup> + <sup>[<a name="id479466" href="#ftn.id479466" class="footnote">3</a>]</sup> You also need to specify the connection option <code class="literal">reconnect</code> to be true. For example: </p><pre class="programlisting"> @@ -391,7 +426,7 @@ This example assumes a 3 node cluster, w </p><pre class="programlisting"> qpid::messaging::Connection c("node1,node2,node3","{reconnect:true,heartbeat:10}"); </pre><p> - </p></div><div class="section" title="1.13.8.2. Python clients"><div class="titlepage"><div><div><h4 class="title"><a name="id564123"></a>1.13.8.2. Python clients</h4></div></div></div><p> + </p></div><div class="section" title="1.13.8.2. Python clients"><div class="titlepage"><div><div><h4 class="title"><a name="id500370"></a>1.13.8.2. Python clients</h4></div></div></div><p> With the python client, you specify <code class="literal">reconnect=True</code> and a list of <em class="replaceable"><code>host:port</code></em> addresses as <code class="literal">reconnect_urls</code> when calling @@ -405,7 +440,7 @@ This example assumes a 3 node cluster, w connection via the 'heartbeat' option. For example: </p><pre class="programlisting"> connection = qpid.messaging.Connection.establish("node1", reconnect=True, reconnect_urls=["node1", "node2", "node3"], heartbeat=10) - </pre></div><div class="section" title="1.13.8.3. Java JMS Clients"><div class="titlepage"><div><div><h4 class="title"><a name="id558369"></a>1.13.8.3. Java JMS Clients</h4></div></div></div><p> + </pre></div><div class="section" title="1.13.8.3. Java JMS Clients"><div class="titlepage"><div><div><h4 class="title"><a name="id518146"></a>1.13.8.3. Java JMS Clients</h4></div></div></div><p> In Java JMS clients, client fail-over is handled automatically if it is enabled in the connection. You can configure a connection to use fail-over using the <span class="command"><strong>failover</strong></span> property: @@ -423,7 +458,56 @@ This example assumes a 3 node cluster, w In a Connection URL, heartbeat is set using the <span class="command"><strong>idle_timeout</strong></span> property, which is an integer corresponding to the heartbeat period in seconds. For instance, the following line from a JNDI properties file sets the heartbeat time out to 3 seconds: </p><pre class="screen"> connectionfactory.qpidConnectionfactory = amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672',idle_timeout=3 - </pre></div></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a id="ftn.id567823" href="#id567823" class="para">1</a>] </sup>Only if the resource manager supports virtual IP addresses</p></div><div class="footnote"><p><sup>[<a id="ftn.id579255" href="#id579255" class="para">2</a>] </sup> + </pre></div></div><div class="section" title="1.13.9. Security."><div class="titlepage"><div><div><h3 class="title"><a name="id508871"></a>1.13.9. Security.</h3></div></div></div><p> + You can secure your cluster using the authentication and authorization features + described in <a class="xref" href="chap-Messaging_User_Guide-Security.html" title="1.5. Security">Section 1.5, âSecurityâ</a>. + </p><p> + Backup brokers connect to the primary broker and subscribe for management + events and queue contents. You can specify the identity used to connect + to the primary with the following options: + </p><div class="table"><a name="ha-broker-security-options"></a><p class="title"><b>Table 1.19. Security options for High Availability Messaging Cluster</b></p><div class="table-contents"><table summary="Security options for High Availability Messaging Cluster" border="1"><colgroup><col align="left" class="c1"><col align="left" class="c2"></colgroup><thead><tr><th colspan="2" align="center"> + Security options for High Availability Messaging Cluster + </th></tr></thead><tbody><tr><td align="left"> + <p><code class="literal">ha-username <em class="replaceable"><code>USER</code></em></code></p> + <p><code class="literal">ha-password <em class="replaceable"><code>PASS</code></em></code></p> + <p><code class="literal">ha-mechanism <em class="replaceable"><code>MECH</code></em></code></p> + </td><td align="left"> + Authentication settings used by HA brokers to connect to each other. + If you are using authorization + (<a class="xref" href="chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Authorization" title="1.5.2. Authorization">Section 1.5.2, âAuthorizationâ</a>) + then this user must have all permissions. + </td></tr></tbody></table></div></div><br class="table-break"><p> + This identity is also used to authorize actions taken on the backup broker to replicate + from the primary, for example to create queues or exchanges. + </p></div><div class="section" title="1.13.10. Integrating with other Cluster Resource Managers"><div class="titlepage"><div><div><h3 class="title"><a name="id504747"></a>1.13.10. Integrating with other Cluster Resource Managers</h3></div></div></div><p> + To integrate with a different resource manager you must configure it to: + </p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem">Start a qpidd process on each node of the cluster.</li><li class="listitem">Restart qpidd if it crashes.</li><li class="listitem">Promote exactly one of the brokers to primary.</li><li class="listitem">Detect a failure and promote a new primary.</li></ul></div><p> + </p><p> + The <span class="command"><strong>qpid-ha</strong></span> command allows you to check if a broker is primary, + and to promote a backup to primary. + </p><p> + To test if a broker is the primary: + </p><pre class="programlisting"> + qpid-ha -b <em class="replaceable"><code>broker-address</code></em> status --expect=primary + </pre><p> + This command will return 0 if the broker at <em class="replaceable"><code>broker-address</code></em> + is the primary, non-0 otherwise. + </p><p> + To promote a broker to primary: + </p><pre class="programlisting"> + qpid-ha -b <em class="replaceable"><code>broker-address</code></em> promote + </pre><p> + </p><p> + <span class="command"><strong>qpid-ha --help</strong></span> gives information on other commands and options available. + You can also use <span class="command"><strong>qpid-ha</strong></span> to manually examine and promote brokers. This + can be useful for testing failover scenarios without having to set up a full resource manager, + or to simulate a cluster on a single node. For deployment, a resource manager is required. + </p></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a id="ftn.id508619" href="#id508619" class="para">1</a>] </sup> + Clients must use "at-least-once" reliability to enable re-send of unacknowledged + messages. This is the default behavior, no options need be set to enable it. For + details of client addressing options see "Using the Qpid Messaging API" + in <em class="citetitle">Programming in Apache Qpid</em> + </p></div><div class="footnote"><p><sup>[<a id="ftn.id518923" href="#id518923" class="para">2</a>] </sup>Only if the resource manager supports virtual IP addresses</p></div><div class="footnote"><p><sup>[<a id="ftn.id479466" href="#id479466" class="para">3</a>] </sup> The full grammar for the URL is: </p><pre class="programlisting"> url = ["amqp:"][ user ["/" password] "@" ] addr ("," addr)* @@ -431,6 +515,6 @@ This example assumes a 3 node cluster, w tcp_addr = ["tcp:"] host [":" port] rdma_addr = "rdma:" host [":" port] ssl_addr = "ssl:" host [":" port]' - </pre></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="Using-message-groups.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch01.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch01s14.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">1.12. + </pre></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="Using-message-groups.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch01.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch01s14.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">1.12. Using Message Groups -  </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 1.14. Queue Replication with the HA module</td></tr></table></div></body></html> +  </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 1.14. Queue Replication with the HA module</td></tr></table></div><div class="main_text_area_bottom"></div></div></div></body></html>
Modified: qpid/site/docs/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Broker_Federation.html URL: http://svn.apache.org/viewvc/qpid/site/docs/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Broker_Federation.html?rev=1368244&r1=1368243&r2=1368244&view=diff ============================================================================== --- qpid/site/docs/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Broker_Federation.html (original) +++ qpid/site/docs/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Broker_Federation.html Wed Aug 1 20:54:46 2012 @@ -1,12 +1,12 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>1.4. Broker Federation</title><link rel="stylesheet" type="text/css" href="css/style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"><link rel="home" href="index.html" title="AMQP Messaging Broker (Implemented in C++)"><link rel="up" href="ch01.html" title="Chapter 1. Running the AMQP Messaging Broker"><link rel="prev" href="ch01s03.html" title="1.3. Cheat Sheet for configuring Exchange Options"><link rel="next" href="chap-Messaging_User_Guide-Security.html" title="1.5. Security"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">1.4. Broker Federation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch01s03.html">Prev</a> </td><th width="60%" align="center">Chapter 1. +<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>1.4. Broker Federation</title><link rel="stylesheet" type="text/css" href="css/style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"><link rel="home" href="index.html" title="AMQP Messaging Broker (Implemented in C++)"><link rel="up" href="ch01.html" title="Chapter 1. Running the AMQP Messaging Broker"><link rel="prev" href="ch01s03.html" title="1.3. Cheat Sheet for configuring Exchange Options"><link rel="next" href="chap-Messaging_User_Guide-Security.html" title="1.5. Security"></head><body><div class="container" bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><DIV class="header"><DIV class="logo"><H1>Apache Qpidâ¢</H1><H2>Open Source AMQP Messaging</H2></DIV></DIV><DIV class="menu_box"><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>Apache Qpid</H3><UL><LI><A href="http://qpid.apache.org/index.html";>Hom e</A></LI><LI><A href="http://qpid.apache.org/download.html";>Download</A></LI><LI><A href="http://qpid.apache.org/getting_started.html";>Getting Started</A></LI><LI><A href="http://www.apache.org/licenses/";>License</A></LI><LI><A href="https://cwiki.apache.org/qpid/faq.html";>FAQ</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>Documentation</H3><UL><LI><A href="http://qpid.apache.org/documentation.html#doc-release";>0.14 Release</A></LI><LI><A href="http://qpid.apache.org/documentation.html#doc-trunk";>Trunk</A></LI><LI><A href="http://qpid.apache.org/documentation.html#doc-archives";>Archive</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>Community</H3><UL><LI><A href="http://qpid.apache.org/getting_involved.html";>Getting Involved</A></LI><LI><A href="http://qpid.apache.org/source_repository.html";>Source Repository</A></LI><LI><A href="http:// qpid.apache.org/mailing_lists.html">Mailing Lists</A></LI><LI><A href="https://cwiki.apache.org/qpid/";>Wiki</A></LI><LI><A href="https://issues.apache.org/jira/browse/qpid";>Issue Reporting</A></LI><LI><A href="http://qpid.apache.org/people.html";>People</A></LI><LI><A href="http://qpid.apache.org/acknowledgements.html";>Acknowledgements</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>Developers</H3><UL><LI><A href="https://cwiki.apache.org/qpid/building.html";>Building Qpid</A></LI><LI><A href="https://cwiki.apache.org/qpid/developer-pages.html";>Developer Pages</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>About AMQP</H3><UL><LI><A href="http://qpid.apache.org/amqp.html";>What is AMQP?</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV><DIV class="menu_box_top"></DIV><DIV class="menu_box_body"><H3>About Apache</H3><UL><LI><A href="http:// www.apache.org">Home</A></LI><LI><A href="http://www.apache.org/foundation/sponsorship.html";>Sponsorship</A></LI><LI><A href="http://www.apache.org/foundation/thanks.html";>Thanks</A></LI><LI><A href="http://www.apache.org/security/";>Security</A></LI></UL></DIV><DIV class="menu_box_bottom"></DIV></DIV><div class="main_text_area"><div class="main_text_area_top"></div><div class="main_text_area_body"><DIV class="breadcrumbs"><span class="breadcrumb-link"><a href="index.html">AMQP Messaging Broker (Implemented in C++)</a></span> > <span class="breadcrumb-link"><a href="ch01.html"> Running the AMQP Messaging Broker - </th><td width="20%" align="right"> <a accesskey="n" href="chap-Messaging_User_Guide-Security.html">Next</a></td></tr></table><hr></div><div class="section" title="1.4. Broker Federation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="chap-Messaging_User_Guide-Broker_Federation"></a>1.4. Broker Federation</h2></div></div></div><p> + </a></span> > <span class="breadcrumb-node">Broker Federation</span></DIV><div class="section" title="1.4. Broker Federation"><div class="titlepage"><div><div><h2 class="title"><a name="chap-Messaging_User_Guide-Broker_Federation"></a>1.4. Broker Federation</h2></div></div></div><p> <em class="firstterm">Broker Federation</em> allows messaging networks to be defined by creating <em class="firstterm">message routes</em>, in which messages in one broker (the <em class="firstterm">source broker</em>) are automatically routed to another broker (the <em class="firstterm">destination broker</em>). These routes may be defined between exchanges in the two brokers (the <em class="firstterm">source exchange</em> and the <em class="firstterm">destination exchange</em>), or from a queue in the source broker (the <em class="firstterm">source queue</em>) to an exchange in the destination broker. Message routes are unidirectional; when bidirectional flow is needed, one route is created in each direction. Routes can be durable or transient. A durable route survives broker restarts, restoring a route as soon as both the source broker and the destination are available. If the connection to a destination is lost, messages associated with a durable route continue to accu mulate on the source, so they can be retrieved when the connection is reestablished. </p><p> Broker Federation can be used to build large messaging networks, with many brokers, one route at a time. If network connectivity permits, an entire distributed messaging network can be configured from a single location. The rules used for routing can be changed dynamically as servers change, responsibilities change, at different times of day, or to reflect other changing conditions. </p><p> Broker Federation is useful in a wide variety of scenarios. Some of these have to do with functional organization; for instance, brokers may be organized by geography, service type, or priority. Here are some use cases for federation: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> + </p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p> Geography: Customer requests may be routed to a processing location close to the customer. </p></li><li class="listitem"><p> Service Type: High value customers may be routed to more responsive servers. @@ -108,7 +108,7 @@ qpid-route [OPTIONS] list connections [& <span class="command"><strong>-t <transport> [ --transport <transport>]</strong></span> </td><td align="left"> Transport protocol to be used for the route. - <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> + <div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p> tcp (default) </p></li><li class="listitem"><p> ssl @@ -315,6 +315,6 @@ localhost 10009 tcp N Passive </td><td align="left"> If a cluster is federated to another cluster, only one of the nodes has an actual connection to remote node. Other nodes in the cluster have a passive connection. - </td></tr></tbody></table></div></div><br class="table-break"></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch01s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch01.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="chap-Messaging_User_Guide-Security.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">1.3. + </td></tr></tbody></table></div></div><br class="table-break"></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch01s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch01.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="chap-Messaging_User_Guide-Security.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">1.3. Cheat Sheet for configuring Exchange Options -  </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 1.5. Security</td></tr></table></div></body></html> +  </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 1.5. Security</td></tr></table></div><div class="main_text_area_bottom"></div></div></div></body></html> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
