[hornetq-commits] JBoss hornetq SVN: r10114 - in trunk/docs/eap-manual/en: diagrams and 1 other directories.
do-not-reply at jboss.org
do-not-reply at jboss.org
Tue Jan 11 13:17:02 EST 2011
Author: ataylor
Date: 2011-01-11 13:17:01 -0500 (Tue, 11 Jan 2011)
New Revision: 10114
Added:
trunk/docs/eap-manual/en/diagrams/
trunk/docs/eap-manual/en/diagrams/ha-topologies1.odg
trunk/docs/eap-manual/en/images/
trunk/docs/eap-manual/en/images/simple-colocated.jpg
trunk/docs/eap-manual/en/images/simple-colocated2.jpg
trunk/docs/eap-manual/en/images/simple-colocated3.jpg
trunk/docs/eap-manual/en/images/simple-dedicated-jca-remote.jpg
trunk/docs/eap-manual/en/images/simple-dedicated-jca.jpg
trunk/docs/eap-manual/en/images/simple-dedicated.jpg
Modified:
trunk/docs/eap-manual/en/clusters.xml
Log:
updated documentation
Modified: trunk/docs/eap-manual/en/clusters.xml
===================================================================
--- trunk/docs/eap-manual/en/clusters.xml 2011-01-10 22:52:30 UTC (rev 10113)
+++ trunk/docs/eap-manual/en/clusters.xml 2011-01-11 18:17:01 UTC (rev 10114)
@@ -39,18 +39,39 @@
EAP instances this would mean that each EAP instance would have a live server and 1 backup server as in
diagram1.
</para>
- <para>todo add image</para>
<para>
+ <graphic fileref="images/simple-colocated.jpg" align="center" format="jpg" scale="30"/>
+ </para>
+ <para>
+ Here the continuous lines show before failover and the dotted lines show the state of the cluster after
+ failover has occurred. To start with the 2 live servers are connected forming a cluster with each live server
+ connected to its local applications (via JCA). Also remote clients are connected to the live servers. After
+ failover the backup connects to the still available live server (which happens to be in the same vm) and takes
+ over as the live server in the cluster. Any remote clients also failover.
+ </para>
+ <para>
+ One thing to mention is that in that depending on what consumers/producers and MDB's etc are available messages
+ will be distributed between the nodes to make sure that all clients are satisfied from a JMS perspective. That is
+ if a producer is sending messages to a queue on a backup server that has no consumers, the messages will be
+ distributed to a live node elsewhere.
+ </para>
+ <para>
+ The following diagram is slightly more complex but shows the same configuration with 3 servers. Note that the
+ cluster connections ave been removed to make the configuration clearer but in reality all live servers will
+ form a cluster.
+ </para>
+ <para>
+ <graphic fileref="images/simple-colocated2.jpg" align="center" format="jpg" scale="30"/>
+ </para>
+ <para>
With more thn 2 servers it is up to the user as to how many backups per live server are configured, you can
have
as many backups as required but usually 1 would suffice. In 3 node topology you may have each EAP instance
configured
- with 2 backups, 1 for each of the other live servers, or you may just want to have 1 backup for each live.
+ with 2 backups in a 4 node 3 backups and so on. The following diagram demonstrates this.
</para>
<para>
- The reason for having the backup server colocated is so they work with MDB's, when a back up server comes ive
- it forwards any messages to the live server who deals with them in the normal fashion. If your application was
- pure JMS you could, if chosen, use a dedicated backup server.
+ <graphic fileref="images/simple-colocated3.jpg" align="center" format="jpg" scale="30"/>
</para>
<section>
<title>Configuration</title>
@@ -444,10 +465,100 @@
<section>
<title>Dedicated Live and Backup in Symmetrical cluster</title>
<para>
- In reality the configuration for this is exactly the same as in the previous section, the only difference is
- that a backup will reside on an eap instance of its own. of course this means that the eap instance is passive
- and not used until the backup comes live and is only really useful for pure JMS applications.
+ In reality the configuration for this is exactly the same as the backup server in the previous section, the only
+ difference is that a backup will reside on an eap instance of its own rather than colocated with another live server.
+ Of course this means that the eap instance is passive and not used until the backup comes live and is only
+ really useful for pure JMS applications.
</para>
+ <para>The following diagram shows a possible configuration for this:</para>
+ <para>
+ <graphic fileref="images/simple-dedicated.jpg" align="center" format="jpg" scale="30"/>
+ </para>
+ <para>
+ Here you can see how this works with remote JMS clients. Once failover occurs the HornetQ backup Server takes
+ running within another eap instance takes over as live.
+ </para>
+ <para>
+ This is fine with applications that are pure JMS and have no JMS components such as MDB's. If you are using
+ JMS components then there are 2 ways that this can be done. The first is shown in the following diagram:
+ </para>
+ <para>
+ <graphic fileref="images/simple-dedicated-jca.jpg" align="center" format="jpg" scale="30"/>
+ </para>
+ <para>
+ Because there is no live hornetq server running by default in the eap instance running the backup server it
+ makes no sense to host any applications in it. However you can host applications on the server running the live
+ hornetq server. If failure occurs to an live hornetq server then remote jms clients will failover as previously
+ explained however what happens to any messages meant for or sent from JEE components. Well when the backup comes
+ live, messages will be distributed to and from the backup server over HornetQ cluster connections and handled
+ appropriately.
+ </para>
+ <para>
+ The second way to do this is to have both live and backup server remote form the eap instance as shown in the
+ following diagram.
+ </para>
+ <para>
+ <graphic fileref="images/simple-dedicated-jca-remote.jpg" align="center" format="jpg" scale="30"/>
+ </para>
+ <para>
+ Here you can see that all the Application (via JCA) will be serviced by a HornetQ server in its own eap instance.
+ </para>
+ <section>
+ <title>Configuration of dedicated Live and backup</title>
+ <para>
+ The live server configuration is exactly the same as in the previous example. The only difference of course
+ is that there is no backup in the eap instance.
+ </para>
+ <para>
+ For the backup server the <literal>hornetq-configuration.xml</literal> is unchanged, however since there is
+ no live server we need to make sure that the <literal>hornetq-jboss-beans.xml</literal> instantiates all
+ the beans needed. For this simply use the same configuration as in the live server changing only the
+ location of the <literal>hornetq-configuration.xml</literal> parameter for the <literal>Configuration</literal>
+ bean.
+ </para>
+ <para>
+ As before there will be no <literal>hornetq-jms.xml</literal> or <literal>jms-ds.xml</literal> configuration.
+ </para>
+ <para>
+ If you want both hornetq servers to be in there own dedicated server where they are remote to applications,
+ as in the last diagram. Then simply edit the <literal>jms-ds.xml</literal> and change the following lines to
+ </para>
+ <programlisting>
+ <config-property name="ConnectorClassName" type="java.lang.String">org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</config-property>
+ <config-property name="ConnectionParameters" type="java.lang.String">host=127.0.0.1;port=5446</config-property>
+ </programlisting>
+ <para>
+ This will change the outbound JCA connector, to configure the inbound connector for MDB's edit the
+ <literal>ra.xml</literal> config file and change the following parameters.
+ </para>
+ <programlisting>
+ <config-property>
+ <description>The transport type</description>
+ <config-property-name>ConnectorClassName</config-property-name>
+ <config-property-type>java.lang.String</config-property-type>
+ <config-property-value>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</config-property-value>
+ </config-property>
+ <config-property>
+ <description>The transport configuration. These values must be in the form of key=val;key=val;</description>
+ <config-property-name>ConnectionParameters</config-property-name>
+ <config-property-type>java.lang.String</config-property-type>
+ <config-property-value>host=127.0.0.1;port=5446</config-property-value>
+ </config-property>
+ </programlisting>
+ <para>
+ In both cases the host and port should match your live server. If you are using Discovery then set the
+ appropriate parameters for <literal>DiscoveryAddress</literal> and <literal>DiscoveryPort</literal> to match
+ your configured broadcast groups.
+ </para>
+ </section>
+ <section>
+ <title>Running the shipped example</title>
+ <para>
+ EAP ships with an example configuration for this topology. Look under
+ <literal>extras/hornetq/resources/examples/cluster-with-dedicated-backup</literal>
+ and follow the read me
+ </para>
+ </section>
</section>
</section>
</chapter>
\ No newline at end of file
Added: trunk/docs/eap-manual/en/diagrams/ha-topologies1.odg
===================================================================
(Binary files differ)
Property changes on: trunk/docs/eap-manual/en/diagrams/ha-topologies1.odg
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: trunk/docs/eap-manual/en/images/simple-colocated.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/docs/eap-manual/en/images/simple-colocated.jpg
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: trunk/docs/eap-manual/en/images/simple-colocated2.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/docs/eap-manual/en/images/simple-colocated2.jpg
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: trunk/docs/eap-manual/en/images/simple-colocated3.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/docs/eap-manual/en/images/simple-colocated3.jpg
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: trunk/docs/eap-manual/en/images/simple-dedicated-jca-remote.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/docs/eap-manual/en/images/simple-dedicated-jca-remote.jpg
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: trunk/docs/eap-manual/en/images/simple-dedicated-jca.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/docs/eap-manual/en/images/simple-dedicated-jca.jpg
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: trunk/docs/eap-manual/en/images/simple-dedicated.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/docs/eap-manual/en/images/simple-dedicated.jpg
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
More information about the hornetq-commits
mailing list