[jboss-cvs] JBossAS SVN: r84591 - projects/docs/community/5/Clustering_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Sat Feb 21 09:11:56 EST 2009
Author: bstansberry at jboss.com
Date: 2009-02-21 09:11:56 -0500 (Sat, 21 Feb 2009)
New Revision: 84591
Modified:
projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml
Log:
General edits
Modified: projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml
===================================================================
--- projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml 2009-02-21 11:20:20 UTC (rev 84590)
+++ projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml 2009-02-21 14:11:56 UTC (rev 84591)
@@ -76,14 +76,14 @@
<para>
In this <emphasis>Clustering Guide</emphasis> we aim to provide you with
an in depth understanding of how to use JBoss AS's clustering features.
- In this first chapter, the goal is to provide some basic "Quick Start"
+ In this first part of the guide, the goal is to provide some basic "Quick Start"
steps to encourage you to start experimenting with JBoss AS Clustering,
and then to provide some background information that will allow you to
- understand how JBoss AS Clustering works. The later chapters in the
- <emphasis>Clustering Guide</emphasis> then explain how to use features
- listed above. Finally, we provide some more details about advanced
- configuration of JGroups, the core technology that underlies JBoss AS
- Clustering.
+ understand how JBoss AS Clustering works. The next part of the
+ guide then explains in detail how to use these features to cluster
+ your JEE services. Finally, we provide some more details about advanced
+ configuration of JGroups and JBoss Cache, the core technologies that
+ underlie JBoss AS Clustering.
</para>
<section id="clustering-quickstart">
@@ -105,18 +105,19 @@
<listitem>
<para><emphasis role="bold">Install JBoss AS on all your servers.</emphasis>
In its simplest form, this is just a matter of unzipping the JBoss
- download onto the filesystem on each server. See the
- "Administration and Configuration Guide" for full details.</para>
+ download onto the filesystem on each server. <!-- See the
+ <emphasis>Administration and Configuration Guide</emphasis> for
+ full details.--></para>
<para id="clustering-prep-dualconfig">If you want to run multiple
JBoss AS instances on a single server, you can either install the
full JBoss distribution onto multiple locations on your filesystem,
or you can simply make copies of the <literal>all</literal>
configuration. For example, assuming the root of the JBoss distribution
- was unzipped to <literal>/home/userA/jboss</literal>, you would:</para>
+ was unzipped to <literal>/var/jboss</literal>, you would:</para>
<programlisting>
-$ cd /home/userA/jboss/server
+$ cd /var/jboss/server
$ cp -r all node1
$ cp -r all node2</programlisting>
</listitem>
@@ -138,7 +139,7 @@
switches or routers between your servers. If you are planning to
run more than one node on a server, make sure the server's routing
table includes a multicast route. See the JGroups documentation
- at http://www.jgroups.org
+ at <ulink url="http://www.jgroups.org">http://www.jgroups.org</ulink>
for more on this general area, including information on how to use
JGroups' diagnostic tools to confirm that multicast is working.
</para>
@@ -153,8 +154,10 @@
<listitem>
<para id="clustering-prep-serverpeerid"><emphasis role="bold">Determine a unique integer "ServerPeerID" for each
node.</emphasis> This is needed for JBoss Messaging clustering,
- and can be skipped if you will not be running JBoss Messaging.
- JBM requires that each node in a cluster have a unique integer
+ and can be skipped if you will not be running JBoss Messaging
+ (i.e. you will remove JBM from your server
+ configuration's <literal>deploy</literal> directory).
+ JBM requires that each node in a cluster has a unique integer
id, known as a "ServerPeerID", that should remain consistent
across server restarts. A simple 1, 2, 3, ..., x naming scheme is
fine. We'll cover how to use these integer ids in the next section.</para>
@@ -173,7 +176,8 @@
up with a different name for each cluster in your environment, e.g.
"QAPartition" or "BobsDevPartition". The use of "Partition" is not
required; it's just a semi-convention. As a small aid to performance
- try to keep the name short. We'll cover how to use the name you
+ try to keep the name short, as it gets included in every message
+ sent around the cluster. We'll cover how to use the name you
pick in the next section.
</para>
</listitem>
@@ -185,7 +189,9 @@
communication. Pick a different multicast address for each cluster
you run. Generally a good multicast address is of the form
<literal>239.255.x.y</literal>. See
+ <ulink url="http://www.29west.com/docs/THPM/multicast-address-assignment.html">
http://www.29west.com/docs/THPM/multicast-address-assignment.html
+ </ulink>
for a good discussion on multicast address assignment. We'll cover
how to use the address you pick in the next section.
</para>
@@ -217,7 +223,7 @@
<itemizedlist>
<listitem><para><emphasis role="bold">Scenario 1: Nodes on Separate Machines</emphasis></para>
<para>This is the most common production scenario. Assume the
- machines are named "node1" and "node2" and node1 has an IP address
+ machines are named "node1" and "node2", while node1 has an IP address
of <literal>192.168.0.101</literal> and node2 has an address of
<literal>192.168.0.102</literal>. Assume the "ServerPeerID" for
node1 is <literal>1</literal> and for node2 it's <literal>2</literal>.
@@ -226,13 +232,16 @@
<para>On node1, to launch JBoss:</para>
<programlisting>
$ cd /var/jboss/bin
-$ ./run.sh -c all -g DocsPartition -u 239.255.100.100 -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1</programlisting>
+$ ./run.sh -c all -g DocsPartition -u 239.255.100.100 \
+ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1</programlisting>
- <para>On node2, it's the same except for a different -b value and ServerPeerID:</para>
+ <para>On node2, it's the same except for a different <literal>-b</literal>
+ value and ServerPeerID:</para>
<programlisting>
$ cd /var/jboss/bin
-$ ./run.sh -c all -g DocsPartition -u 239.255.100.100 -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2</programlisting>
+$ ./run.sh -c all -g DocsPartition -u 239.255.100.100 \
+ -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2</programlisting>
<para>The <literal>-c</literal> switch says to use the <literal>all</literal>
config, which includes clustering support. The <literal>-g</literal> switch
@@ -243,18 +252,20 @@
property <literal>jboss.messaging.ServerPeerId</literal>, from which
JBoss Messaging gets its unique id.</para>
</listitem>
- <listitem><para><emphasis role="bold">Scenario 2: Two Nodes on a Single, Multihomed, Server</emphasis></para>
+ <listitem>
+ <para><emphasis role="bold">Scenario 2: Two Nodes on a Single, Multihomed, Server</emphasis></para>
<para>Running multiple nodes on the same machine is a common scenario
in a development environment, and is also used in production in
- combination with Scenario 1. (Running all the nodes in a production
- cluster on a single machine is generally not recommended, since the
- machine itself becomes a single point of failure.) In this version
- of the scenario, the machine is multihomed, i.e. has more than one IP
- address. This allows the binding of each JBoss instance to a different
- address, preventing port conflicts when the nodes open sockets.
+ combination with Scenario 1. (Running <emphasis>all</emphasis> the
+ nodes in a production cluster on a single machine is generally not
+ recommended, since the machine itself becomes a single point of
+ failure.) In this version of the scenario, the machine is multihomed,
+ i.e. has more than one IP address. This allows the binding of each
+ JBoss instance to a different address, preventing port conflicts
+ when the nodes open sockets.
</para>
- <para>Assume that single machine has the <literal>192.168.0.101</literal> and
+ <para>Assume the single machine has the <literal>192.168.0.101</literal> and
<literal>192.168.0.102</literal> addresses assigned, and that the two
JBoss instances use the same addresses and ServerPeerIDs as in
Scenario 1. The difference from Scenario 1 is we need to be sure
@@ -267,13 +278,17 @@
<para>To launch the first instance, open a console window and:</para>
<programlisting>
$ cd /var/jboss/bin
-$ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1</programlisting>
+$ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \
+ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1</programlisting>
- <para>For the second instance, it's the same except for different -b and -c values and a different ServerPeerID:</para>
+ <para>For the second instance, it's the same except for different
+ <emphasis>-b</emphasis> and <emphasis>-c</emphasis> values and a
+ different ServerPeerID:</para>
<programlisting>
$ cd /var/jboss/bin
-$ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2</programlisting>
+$ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \
+ -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2</programlisting>
</listitem>
<listitem>
@@ -288,13 +303,17 @@
<para>To launch the first instance, open a console window and:</para>
<programlisting>
$ cd /var/jboss/bin
-$ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1 -Djboss.service.binding.set=ports-default</programlisting>
+$ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \
+ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1 \
+ -Djboss.service.binding.set=ports-default</programlisting>
<para>For the second instance:</para>
<programlisting>
$ cd /var/jboss/bin
-$ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 -b 192.168.0.101 -Djboss.messaging.ServerPeerID=2 -Djboss.service.binding.set=ports-01</programlisting>
+$ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \
+ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=2 \
+ -Djboss.service.binding.set=ports-01</programlisting>
<para>This tells the ServiceBindingManager on the first node to use
the standard set of ports (e.g. JNDI on 1099). The second node uses
@@ -309,11 +328,18 @@
environments where developers want to use clustering but cannot
multihome their workstations.</para>
+ <note><para>Including <literal>-Djboss.service.binding.set=ports-default</literal>
+ on the command line for node1 isn't technically necessary, since
+ <literal>ports-default</literal> is the ... default. But using a
+ consistent set of command line arguments across all servers is
+ helpful to people less familiar with all the details.</para></note>
+
</listitem>
</itemizedlist>
- <para></para>
+ <para>That's it; that's all it takes to get a cluster of JBoss
+ AS servers up and running.</para>
</section>
<section id="clustering-quickstart-http">
More information about the jboss-cvs-commits
mailing list