[jboss-cvs] JBossAS SVN: r82716 - in projects/docs/community/5/Clustering_Guide/en-US: images and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Jan 8 18:15:29 EST 2009
Author: bstansberry at jboss.com
Date: 2009-01-08 18:15:29 -0500 (Thu, 08 Jan 2009)
New Revision: 82716
Added:
projects/docs/community/5/Clustering_Guide/en-US/images/clustering-as-arch.png
Modified:
projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml
Log:
[JBAS-6358] Progress checkin on Introduction chapter rewrite
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-01-08 23:14:07 UTC (rev 82715)
+++ projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml 2009-01-08 23:15:29 UTC (rev 82716)
@@ -95,7 +95,7 @@
<para>
The goal of this section is to give you the minimum information
needed to let you get started experimenting with JBoss AS Clustering.
- Each of the areas touched on in this section is covered in much greater
+ Most of the areas touched on in this section are covered in much greater
detail later in this guide.
</para>
@@ -155,7 +155,7 @@
</listitem>
<listitem>
- <para><emphasis role="bold">Determine a unique integer "ServerPeerID" for each
+ <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
@@ -165,7 +165,7 @@
</listitem>
</itemizedlist>
- <para>Beyond the above steps, the following two steps are
+ <para>Beyond the above required steps, the following two optional steps are
recommended to help ensure that your cluster is properly isolated
from other JBoss AS clusters that may be running on your network:</para>
@@ -209,7 +209,8 @@
</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
+ <link linkend="clustering-prep-serverpeerid">ServerPeerID</link>
for the first node is <literal>1</literal> and for the second node is
<literal>2</literal>. We've decided to call our cluster "DocsPartition"
and to use <literal>239.255.100.100</literal> as our multicast address.
@@ -223,7 +224,7 @@
machines are named "node1" and "node2" and 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>1</literal>.
+ 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>On node1, to launch JBoss:</para>
@@ -281,10 +282,10 @@
<listitem>
<para><emphasis role="bold">Scenario 3: Two Nodes on a Single, Non-Multihomed, Server</emphasis></para>
- <para>This scenario is similar to Scenario 2, but here the machine
+ <para>This is similar to Scenario 2, but here the machine
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
- a different ports for the two instances. This can be done by
+ 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>
@@ -443,7 +444,8 @@
<jta-data-source>java:/SomeDS</jta-data-source>
<properties>
<property name="hibernate.cache.use_second_level_cache" value="true"/>
- <property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory"/>
+ <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 ... -->
</properties>
@@ -460,9 +462,7 @@
package org.example.entities;
import java.io.Serializable;
-
import javax.persistence.Entity;
-
import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;
@@ -487,18 +487,48 @@
<section id="clustering-concepts-def">
<title>Cluster Definition</title>
<para>
- A cluster is a set of nodes that communicate with each other and work toward a common goal. In a JBoss Application Server cluster (also known as a “partition”), a node is an JBoss Application Server instance. Communication between the nodes is handled by the JGroups group communication library, with a JGroups Channel providing the core functionality of tracking who is in the cluster and reliably exchanging messages between the cluster members. JGroups channels with the same configuration and name have the ability to dynamically discover each other and form a group. This is why simply executing “run -c all” on two AS instances on the same network is enough for them to form a cluster – each AS starts a Channel (actually, several) with the same default configuration, so they dynamically discover each other and form a cluster. Nodes can be dynamically added to or removed from clusters at any time, simply by starting or stopping a Channel with a configuration and na!
me that matches the other cluster members.
+ A cluster is a set of nodes that communicate with each other and work
+ toward a common goal. In a JBoss Application Server cluster (also known
+ as a “partition”), a node is an JBoss Application Server instance.
+ Communication between the nodes is handled by the JGroups group communication
+ library, with a JGroups Channel providing the core functionality of tracking
+ who is in the cluster and reliably exchanging messages between the cluster
+ members. JGroups channels with the same configuration and name have the
+ ability to dynamically discover each other and form a group. This is why
+ simply executing “run -c all” on two AS instances on the same network is
+ enough for them to form a cluster – each AS starts a Channel (actually,
+ several) with the same default configuration, so they dynamically discover
+ each other and form a cluster. Nodes can be dynamically added to or removed
+ from clusters at any time, simply by starting or stopping a Channel with a
+ configuration and name that matches the other cluster members.
- In summary, a JBoss cluster is a set of AS server instances each of which is running an identically configured and named JGroups Channel.
+ In summary, a JBoss cluster is a set of AS server instances each of which
+ is running an identically configured and named JGroups Channel.
</para>
<para>
- On the same AS instance, different services can create their own Channel. In a default 5.0.x AS, four different services create channels – the web session replication service, the EJB3 SFSB replication service, the EJB3 entity caching service, and a core general purpose clustering service known as HAPartition. In order to differentiate these channels, each must have a unique name, and its configuration must match its peers yet differ from the other channels.
+ On the same AS instance, different services can create their own Channel.
+ In a default 5.0.x AS, four different services create channels – the web
+ session replication service, the EJB3 SFSB replication service, the EJB3
+ entity caching service, and a core general purpose clustering service known
+ as HAPartition. In order to differentiate these channels, each must have a
+ unique name, and its configuration must match its peers yet differ from the
+ other channels.
</para>
<para>
- So, if you go to two AS 5.0.x instances and execute <literal>run -c all</literal>, the channels will discover each other and you'll have a conceptual <literal>cluster</literal>. It's easy to think of this as a two node cluster, but it's important to understand that you really have 4 channels, and hence 4 two node clusters.
+ So, if you go to two AS 5.0.x instances and execute <literal>run -c all</literal>,
+ the channels will discover each other and you'll have a conceptual
+ <literal>cluster</literal>. It's easy to think of this as a two node
+ cluster, but it's important to understand that you really have 4 channels,
+ and hence 4 two node clusters.
</para>
- <para>On the same network, even for the same service, we may have different clusters. <xref linkend="clustering-Partition.fig"/> shows an example network of JBoss server instances divided into three clusters, with the third cluster only having one node. This sort of topology can be set up simply by configuring the AS instances such that within a set of nodes meant to form a cluster the Channel configurations and names match while they differ from any other channels on the same network. </para>
+ <para>On the same network, even for the same service, we may have different clusters.
+ <xref linkend="clustering-Partition.fig"/> shows an example network of JBoss
+ server instances divided into three clusters, with the third cluster only
+ having one node. This sort of topology can be set up simply by configuring
+ the AS instances such that within a set of nodes meant to form a cluster the
+ Channel configurations and names match while they differ from any other
+ channels on the same network. </para>
<figure id="clustering-Partition.fig">
<title>Clusters and server nodes</title>
<mediaobject>
@@ -509,25 +539,57 @@
</figure>
<para>
- The section on “JGroups Configuration” and on “Isolating JGroups Channels” covers in detail how to configure Channels such that desired peers find each other and unwanted peers do not. As mentioned above, by default JBoss AS uses four separate JGroups Channels. These can be divided into two broad categories: the Channel used by the general purpose HAPartition service, and three Channels created by JBoss Cache for special purpose caching and cluster wide state replication.
+ The section on “JGroups Configuration” and on “Isolating JGroups Channels”
+ covers in detail how to configure Channels such that desired peers find
+ each other and unwanted peers do not. As mentioned above, by default JBoss
+ AS uses four separate JGroups Channels. These can be divided into two
+ broad categories: the Channel used by the general purpose HAPartition
+ service, and three Channels created by JBoss Cache for special purpose
+ caching and cluster wide state replication.
</para>
</section>
<section id="clustering-concepts-arch">
<title>Service Architectures</title>
- <para>The clustering topography defined by the <literal>HAPartition</literal> MBean on each node is
- of great importance to system administrators. But for most application developers, you are probably more concerned about the cluster architecture from a client application's point of view. Two basic clustering architectures are used with JBoss AS: client-side interceptors (a.k.a smart proxies or stubs) and external load balancers. Which architecture your application will use will depend on what type of client you have.
+ <para>The clustering topography defined by the <literal>HAPartition</literal>
+ MBean on each node is of great importance to system administrators. But for
+ most application developers, you are probably more concerned about the cluster
+ architecture from a client application's point of view. Two basic clustering
+ architectures are used with JBoss AS: client-side interceptors (a.k.a smart
+ proxies or stubs) and external load balancers. Which architecture your
+ application will use will depend on what type of client you have.
</para>
<section id="clustering-concepts-arch-proxy">
<title>Client-side interceptor architecture</title>
<para>
- Most remote services provided by the JBoss application server, including JNDI, EJB, JMS, RMI and JBoss Remoting, require the client to obtain (e.g., to look up and download) a stub (or proxy) object. The stub object is generated by the server and it implements the business interface of the service. The client then makes local method calls against the stub object. The stub automatically routes the call across the network and where it is invoked against service objects managed in the server. In a clustering environment, the server-generated stub object includes an interceptor that understands how to route calls to multiple nodes in the cluster. The stub object figures out how to find the appropriate server node, marshal call parameters, un-marshall call results, and return the result to the caller client.
+ Most remote services provided by the JBoss application server, including
+ JNDI, EJB, JMS, RMI and JBoss Remoting, require the client to obtain
+ (e.g., to look up and download) a remote proxy object. The proxy object
+ is generated by the server and it implements the business interface of
+ the service. The client then makes local method calls against the proxy
+ object. The proxy automatically routes the call across the network where
+ it is invoked against service objects managed in the server. The proxy
+ object figures out how to find the appropriate server node, marshal call
+ parameters, un-marshall call results, and return the result to the caller
+ client. In a clustered environment, the server-generated proxy object includes an
+ interceptor that understands how to route calls to multiple nodes in the
+ cluster.
</para>
-<para>The stub interceptors maintain up-to-date knowledge about the cluster. For instance, they know the IP addresses of all available server nodes, the algorithm to distribute load across nodes (see next section), and how to failover the request if the target node not available. As part of handling each service request, if the cluster topology has changed the server node updates the stub interceptor with the latest changes in the cluster. For instance, if a node drops out of the cluster, each of client stub interceptor is updated with the new configuration the next time it connects to any active node in the cluster. All the manipulations done by the service stub are transparent to the client application. The client-side interceptor clustering architecture is illustrated in <xref linkend="clustering-InterceptorArch.fig"/>.
+<para>The proxy's clustering logic maintains up-to-date knowledge about
+ the cluster. For instance, it knows the IP addresses of all available
+ server nodes, the algorithm to distribute load across nodes (see next section),
+ and how to failover the request if the target node not available.
+ As part of handling each service request, if the cluster topology has
+ changed the server node updates the proxy with the latest changes
+ in the cluster. For instance, if a node drops out of the cluster, each of
+ proxy is updated with the new topology the next time it connects to any
+ active node in the cluster. All the manipulations done by the proxy's
+ clustering logic are transparent to the client application. The client-side
+ interceptor clustering architecture is illustrated in <xref linkend="clustering-InterceptorArch.fig"/>.
</para>
<figure id="clustering-InterceptorArch.fig">
<title>The client-side interceptor (proxy) architecture for clustering</title>
@@ -545,7 +607,22 @@
<section id="clustering-concepts-arch-balancer">
<title>External Load Balancer Architecture</title>
<para>
- Other JBoss services, in particular the HTTP-based services, do not require the client to download anything. The client (e.g., a web browser) sends in requests and receives responses directly over the wire according to certain communication protocols (e.g., the HTTP protocol). In this case, an external load balancer is required to process all requests and dispatch them to server nodes in the cluster. The client only needs to know about how to contact the load balancer; it has no knowledge of the JBoss AS instances behind the load balancer. The load balancer is logically part of the cluster, but we refer to it as “external” because it is not running in the same process as either the client or any of the JBoss AS instances. It can be implemented either in software or hardware. There are many vendors of hardware load balancers; the mod_jk Apache module is an excellent example of a software load balancer. An external load balancer implements its own mechanism for unde!
rstanding the cluster configuration and provides its own load balancing and failover policies. The external load balancer clustering architecture is illustrated in <xref linkend="clustering-BalancerArch.fig"/>.
+ Other JBoss services, in particular the HTTP-based services, do not
+ require the client to download anything. The client (e.g., a web browser)
+ sends in requests and receives responses directly over the wire according
+ to certain communication protocols (e.g., the HTTP protocol). In this
+ case, an external load balancer is required to process all requests and
+ dispatch them to server nodes in the cluster. The client only needs to know
+ how to contact the load balancer; it has no knowledge of the JBoss AS
+ instances behind the load balancer. The load balancer is logically part
+ of the cluster, but we refer to it as “external” because it is not running
+ in the same process as either the client or any of the JBoss AS instances.
+ It can be implemented either in software or hardware. There are many
+ vendors of hardware load balancers; the mod_jk Apache module is an excellent
+ example of a software load balancer. An external load balancer implements
+ its own mechanism for understanding the cluster configuration and provides
+ its own load balancing and failover policies. The external load balancer
+ clustering architecture is illustrated in <xref linkend="clustering-BalancerArch.fig"/>.
</para>
<figure id="clustering-BalancerArch.fig">
<title>The external load balancer architecture for clustering</title>
@@ -556,7 +633,9 @@
</mediaobject>
</figure>
<para>
- A potential problem with an external load balancer architecture is that the load balancer itself may be a single point of failure. It needs to be monitored closely to ensure high availability of the entire cluster's services.
+ A potential problem with an external load balancer architecture is that
+ the load balancer itself may be a single point of failure. It needs to be
+ monitored closely to ensure high availability of the entire cluster's services.
</para>
</section>
@@ -615,12 +694,53 @@
<section id="clustering-blocks">
<title>Clustering Building Blocks</title>
- <para></para>
+ <para>The clustering features in JBoss AS are built on top of lower level
+ libraries that provide much of the core functionality. <xref linkend="clustering-as-arch.fig"/>
+ shows the main pieces:
+ </para>
+
+ <figure id="clustering-as-arch.fig">
+ <title>The JBoss AS clustering architecture</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" fileref="images/clustering-as-arch.png"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+
+ <para><emphasis role="bold">JGroups</emphasis> is a toolkit for reliable
+ point-to-point and point-to-multipoint communication. JGroups is used for
+ all clustering-related communications between nodes in a JBoss AS cluster.
+ See <xref linkend="clustering-blocks-jgroups"/> for more on how JBoss AS
+ uses JGroups.</para>
+
+ <para><emphasis role="bold">JBoss Cache</emphasis> is a highly flexible
+ clustered transactional caching library. Many AS clustering services
+ need to cache some state in memory while 1) ensuring for high availability
+ purposes that a backup copy of that state is available on another node
+ if it can't otherwise be recreated (e.g. the contents of a web session)
+ and 2) ensuring that the data cached on each node in the cluster is consistent.
+ JBoss Cache handles these concerns for most JBoss AS clustered services.
+ JBoss Cache uses JGroups to handle its group communication requirements.
+ <emphasis role="bold">POJO Cache</emphasis> is an extension of the
+ core JBoss Cache that JBoss AS uses to support fine-grained replication
+ of clustered web session state. See <xref linkend="clustering-blocks-jbc"/>
+ for more on how JBoss AS uses JBoss Cache and POJO Cache.</para>
+
<section id="clustering-blocks-jgroups">
<title>Group Communication with JGroups</title>
<para></para>
+ <section id="clustering-blocks-jgroups-sharedtransport">
+ <title>The JGroups Shared Transport</title>
+ <para></para>
+ </section>
+
+ <section id="clustering-blocks-jgroups-channelfactory">
+ <title>The Channel Factory Service</title>
+ <para></para>
+ </section>
</section>
<section id="clustering-hapartition">
@@ -709,17 +829,39 @@
</section>
- <section><title>JBoss Cache channels</title>
- <para>
- JBoss Cache is a fully featured distributed cache framework that can be
- used in any application server environment or standalone. JBoss AS
- integrates JBoss Cache to provide cache services for HTTP sessions,
- EJB 3.0 session beans, and EJB 3.0 entity beans. Each of these cache
- services is defined in a separate Mbean, and each cache creates its own
- JGroups Channel. We will cover those MBeans when we discuss specific
- services in the next several sections.
- </para>
-</section>
+ <section id="clustering-blocks-jbc">
+ <title>Distributed Caching with JBoss Cache</title>
+ <para>
+ JBoss Cache is a fully featured distributed cache framework that can be
+ used in any application server environment or standalone. JBoss Cache
+ provides the underlying distributed caching support used by many of the
+ standard clustered services in a JBoss AS cluster, including:
+ <itemizedlist>
+ <listitem><para>Replication of clustered webapp sessions.</para></listitem>
+ <listitem><para>Replication of clustered EJB3 Stateful Session beans.</para></listitem>
+ <listitem><para>Clustered caching of JPA and Hibernate entities.</para></listitem>
+ <listitem><para>Clustered Single Sign-On.</para></listitem>
+ <listitem><para>The HA-JNDI replicated tree.</para></listitem>
+ <listitem><para>DistributedStateService</para></listitem>
+ </itemizedlist>
+ </para>
+
+ <para>Users can also create their own JBoss Cache and POJO Cache
+ instances for custom use by their applications, see
+ <xref linkend="jbosscache.chapt"/> for more on this.</para>
+
+ <para>JBoss AS ships with a reasonable set of default JBoss Cache
+ configurations that are suitable for standard clustered service
+ use cases listed above. Most applications that involve the standard
+ clustered services just work out of the box with the default configurations.
+ You only need to tweak them when you are deploying an application that
+ has special network or performance requirements.</para>
+
+ <section id="clustering-blocks-jbc-cachemanager">
+ <title>The JBoss AS CacheManager Service</title>
+ <para></para>
+ </section>
+ </section>
</section>
<section id="clustering-intro-farm">
Added: projects/docs/community/5/Clustering_Guide/en-US/images/clustering-as-arch.png
===================================================================
(Binary files differ)
Property changes on: projects/docs/community/5/Clustering_Guide/en-US/images/clustering-as-arch.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
More information about the jboss-cvs-commits
mailing list