[jboss-cvs] JBossAS SVN: r99194 - projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Jan 11 03:07:41 EST 2010
Author: laubai
Date: 2010-01-11 03:07:41 -0500 (Mon, 11 Jan 2010)
New Revision: 99194
Modified:
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml
Log:
Edited Clustering Guide Intro.xml
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml 2010-01-11 07:30:13 UTC (rev 99193)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml 2010-01-11 08:07:41 UTC (rev 99194)
@@ -6,7 +6,7 @@
<para>
Clustering allows you to run an application on several parallel servers
- (a.k.a cluster nodes) while providing a single view to application
+ (also known as cluster nodes) while providing a single view to application
clients. Load is distributed across different servers, and even if
one or more of the servers fails, the application is still accessible
via the surviving cluster nodes. Clustering is crucial for scalable
@@ -45,10 +45,10 @@
</itemizedlist>
</listitem>
- <listitem>
+ <!--<listitem>
<para>EJB session bean clustering, for both stateful and stateless
beans, and for both EJB3 and EJB2.</para>
- </listitem>
+ </listitem>-->
<listitem>
<para>A distributed cache for JPA/Hibernate entities.</para>
@@ -60,9 +60,9 @@
when a bean is changed on any node.</para>
</listitem>
- <listitem>
+ <!--<listitem>
<para>Distributed JMS queues and topics via JBoss Messaging.</para>
- </listitem>
+ </listitem>-->
<listitem>
<para>Deploying a service or application on multiple nodes in the
@@ -80,8 +80,9 @@
</para>
<para>
- In this <emphasis>Clustering Guide</emphasis> we aim to provide you with
- an in depth understanding of how to use JBoss Enterprise Web Platform's clustering features.
+ This part of the <citetitle>Administration and Configuration Guide</citetitle>
+ aims to provide you with an in depth understanding of how to use
+ JBoss Enterprise Web Platform's clustering features.
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 Enterprise Web Platform Clustering,
and then to provide some background information that will allow you to
@@ -111,7 +112,8 @@
<listitem id="clustering-prep-dualconfig">
<para><emphasis role="bold">Install JBoss Enterprise Web Platform 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
+ download onto the filesystem on each server. For more information, see the
+ <citetitle>Installation Guide</citetitle>. <!-- See the
<emphasis>Administration and Configuration Guide</emphasis> for
full details.--></para>
@@ -120,7 +122,7 @@
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>/var/jboss</literal>, you would:</para>
+ was unzipped to <filename>/var/jboss</filename>, you would:</para>
<programlisting>
$ cd /var/jboss/server
@@ -157,8 +159,9 @@
</note>
</listitem>
- <listitem id="clustering-prep-serverpeerid">
- <para><emphasis role="bold">Determine a unique integer "ServerPeerID" for each
+ <!--<listitem id="clustering-prep-serverpeerid">
+ <para><emphasis role="bold">Determine a unique integer
+ <varname>ServerPeerID</varname> for each
node.</emphasis> This is needed for JBoss Messaging clustering,
and can be skipped if you will not be running JBoss Messaging
(i.e. you will remove JBM from your server
@@ -167,7 +170,7 @@
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>
- </listitem>
+ </listitem>-->
</itemizedlist>
<para>Beyond the above required steps, the following two optional steps are
@@ -178,9 +181,10 @@
<listitem>
<para id="clustering-prep-clustername">
<emphasis role="bold">Pick a unique name for your cluster.</emphasis>
- The default name for a JBoss Enterprise Web Platform cluster is "DefaultPartition". Come
- up with a different name for each cluster in your environment, e.g.
- "QAPartition" or "BobsDevPartition". The use of "Partition" is not
+ The default name for a JBoss Enterprise Web Platform cluster is
+ <literal>DefaultPartition</literal>. Devise a different name for each
+ cluster in your environment, for example, <literal>QAPartition</literal>
+ or <literal>BobsDevPartition</literal>. 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, as it gets included in every message
sent around the cluster. We'll cover how to use the name you
@@ -212,14 +216,15 @@
<title>Launching a JBoss Enterprise Web Platform Cluster</title>
<para>The simplest way to start a JBoss server cluster is to start
several JBoss instances on the same local network, using the
- <literal>-c all</literal> command line option for each instance. Those
+ <code>-c all</code> command line option for each instance. Those
server instances will detect each other and automatically form a cluster.
</para>
<para>Let's look at a few different scenarios for doing this. In each
- scenario we'll be creating a two node cluster, where the ServerPeerID
+ scenario we'll be creating a two node cluster, where the <varname>ServerPeerID</varname>
for the first node is <literal>1</literal> and for the second node is
- <literal>2</literal> <!--(see <xref linkend="clustering-prep-serverpeerid"/>)-->. We've decided to call our cluster "DocsPartition"
+ <literal>2</literal> <!--(see <xref linkend="clustering-prep-serverpeerid"/>)-->. We've decided to
+ call our cluster <literal>DocsPartition</literal>
and to use <literal>239.255.100.100</literal> as our multicast address.
These scenarios are meant to be illustrative; the use of a two node
cluster shouldn't be taken to mean that is the best size for a cluster;
@@ -227,12 +232,25 @@
<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", 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>.
- Assume on each machine JBoss is installed in <literal>/var/jboss</literal>.</para>
+ <para>This is the most common production scenario. For this example, assume that:</para>
+ <itemizedlist>
+ <listitem>
+ <para>The machines are named <literal>node1</literal> and <literal>node2</literal>.
+ </para>
+ </listitem>
+ <listitem>
+ <para><literal>node1</literal> has an IP address of <literal>192.168.0.101</literal>,
+ and <literal>node2</literal> has an address of <literal>192.168.0.102</literal>.</para>
+ </listitem>
+ <listitem>
+ <para>The <varname>ServerPeerID</varname> is <literal>1</literal> for
+ <literal>node1</literal>, and <literal>2</literal> for <literal>node2</literal>.
+ </listitem>
+ <listitem>
+ <para>On each machine, JBoss is installed in <filename>/var/jboss</filename>.</para>
+ </listitem>
+ </itemizedlist>
+
<para>On node1, to launch JBoss:</para>
<programlisting>
@@ -246,16 +264,17 @@
<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>
+ -b 192.168.0.102</programlisting>
+<!-- -Djboss.messaging.ServerPeerID=2 -->
<para>The <literal>-c</literal> switch says to use the <literal>all</literal>
config, which includes clustering support. The <literal>-g</literal> switch
sets the cluster name. The <literal>-u</literal> switch sets the multicast
address that will be used for intra-cluster communication. The
<literal>-b</literal> switch sets the address on which sockets
- will be bound. The <literal>-D</literal> switch sets system
- property <literal>jboss.messaging.ServerPeerID</literal>, from which
- JBoss Messaging gets its unique id.</para>
+ will be bound. <!--The <literal>-D</literal> switch sets system
+ property <varname>jboss.messaging.ServerPeerID</varname>, 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>
@@ -265,7 +284,7 @@
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
+ that is, it 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>
@@ -273,19 +292,19 @@
<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
+ Scenario 1. The difference from Scenario 1 is that we need to be sure
each Enterprise Web Platform instance has its own work area. So, instead of using
the <literal>all</literal> config, we are going to use the
<literal>node1</literal> and <literal>node2</literal> configs we
- copied from <literal>all</literal> earlier in <!--
+ copied from <literal>all</literal> in <!--
<xref linkend="clustering-prep-dualconfig"/>-->the previous section.</para>
<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>
-
+ -b 192.168.0.101 </programlisting>
+<!-- -Djboss.messaging.ServerPeerID=1 -->
<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>
@@ -293,7 +312,8 @@
<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>
+ -b 192.168.0.102 </programlisting>
+<!-- -Djboss.messaging.ServerPeerID=2 -->
</listitem>
<listitem>
@@ -302,30 +322,29 @@
only has one IP address available. Two processes can't bind sockets
to the same address and port, so we'll have to tell JBoss to use
different ports for the two instances. This can be done by
- configuring the ServiceBindingManager service by setting the
- <literal>jboss.service.binding.set</literal> system property.</para>
+ configuring the <classname>ServiceBindingManager</classname> service by setting the
+ <varname>jboss.service.binding.set</varname> system property.</para>
<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>
-
+ -b 192.168.0.101 -Djboss.service.binding.set=ports-default</programlisting>
+<!-- -Djboss.messaging.ServerPeerID=1 -->
<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>
+ -b 192.168.0.101 -Djboss.service.binding.set=ports-01</programlisting>
+<!-- -Djboss.messaging.ServerPeerID=2 -->
- <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
- the "ports-01" binding set, which by default for each port has an
- offset of 100 from the standard port number (e.g. JNDI on 1199).
- See the <literal>conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml</literal> file for the
- full ServiceBindingManager configuration.</para>
+ <para>This tells the <classname>ServiceBindingManager</classname> on the first node to use
+ the standard set of ports (for example, JNDI on port 1099). The second node uses
+ the <literal>ports-01</literal> binding set, which by default for each port has an
+ offset of 100 from the standard port number (for example, JNDI on port 1199).
+ See the <filename>conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml</filename>
+ file for the full <classname>ServiceBindingManager</classname> configuration.</para>
<para>Note that this setup is not advised for production use,
due to the increased management complexity that comes with using
@@ -334,7 +353,7 @@
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
+ on the command line for <literal>node1</literal> isn't technically necessary, since
<literal>ports-default</literal> is the default value. But using a
consistent set of command line arguments across all servers is
helpful to people less familiar with all the details.</para></note>
@@ -350,7 +369,7 @@
<section id="clustering-quickstart-http">
<title>Web Application Clustering Quick Start</title>
<para>JBoss Enterprise Web Platform supports clustered web sessions, where a backup
- copy of each user's <literal>HttpSession</literal> state is stored
+ copy of each user's <classname>HttpSession</classname> state is stored
on one or more nodes in the cluster. In case the primary node
handling the session fails or is shut down, any other node in the
cluster can handle subsequent requests for the session by accessing
@@ -377,16 +396,18 @@
web app, and it couldn't be simpler. Just add an empty
<literal>distributable</literal> element to your application's
<literal>web.xml</literal> file:</para>
- <programlisting><?xml version="1.0"?>
-<web-app xmlns="http://java.sun.com/xml/ns/javaee"
+ <programlisting><![CDATA[
+<?xml version="1.0"?>
+<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
- version="2.5">
+ version="2.5">
- <distributable/>
+ <distributable/>
-</web-app></programlisting>
+</web-app>
+]]></programlisting>
<para>Simply doing that is enough to get the default JBoss Enterprise Web Platform
web session clustering behavior, which is appropriate for most
@@ -397,7 +418,7 @@
</para>
</section>
- <section id="clustering-quickstart-ejbsessions">
+ <!--<section id="clustering-quickstart-ejbsessions">
<title>EJB Session Bean Clustering Quick Start</title>
<para>JBoss Enterprise Web Platform supports clustered EJB session beans, whereby
requests for a bean are balanced across the cluster. For
@@ -425,16 +446,17 @@
element to the bean's section in the JBoss-specific deployment
descriptor, <literal>jboss.xml</literal>:</para>
- <programlisting>
-<jboss>
- <enterprise-beans>
- <session>
- <ejb-name>example.StatelessSession</ejb-name>
- <jndi-name>example.StatelessSession</jndi-name>
- <clustered>true</clustered>
- </session>
- </enterprise-beans>
-</jboss> </programlisting>
+ <programlisting><![CDATA[
+<jboss>
+ <enterprise-beans>
+ <session>
+ <ejb-name>example.StatelessSession</ejb-name>
+ <jndi-name>example.StatelessSession</jndi-name>
+ <clustered>true</clustered>
+ </session>
+ </enterprise-beans>
+</jboss>
+]]></programlisting>
<para>See <xref linkend="clustering-session"/> for more advanced
configuration options.</para>
@@ -475,7 +497,7 @@
<property name="hibernate.cache.region.factory_class"
value="org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory"/>
<property name="hibernate.cache.region.jbc2.cachefactory" value="java:CacheManager"/>
- <!-- Other configuration options ... -->
+ # Other configuration options ...
</properties>
</persistence-unit>
</persistence>]]>
@@ -513,7 +535,7 @@
</para></note>
</section>
- </section>
+ </section>-->
More information about the jboss-cvs-commits
mailing list