[jboss-cvs] JBossAS SVN: r96552 - in projects/docs/enterprise/4.2.8/Server_Configuration_Guide: en-US and 1 other directory.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Thu Nov 19 02:05:32 EST 2009


Author: benlc
Date: 2009-11-19 02:05:31 -0500 (Thu, 19 Nov 2009)
New Revision: 96552

Added:
   projects/docs/enterprise/4.2.8/Server_Configuration_Guide/publican.cfg
Modified:
   projects/docs/enterprise/4.2.8/Server_Configuration_Guide/en-US/Clustering_Guide_Intro.xml
   projects/docs/enterprise/4.2.8/Server_Configuration_Guide/en-US/Deploy.xml
Log:
'committing changes regarding the separation of clusters as per JBPAPP-2510'


Modified: projects/docs/enterprise/4.2.8/Server_Configuration_Guide/en-US/Clustering_Guide_Intro.xml
===================================================================
--- projects/docs/enterprise/4.2.8/Server_Configuration_Guide/en-US/Clustering_Guide_Intro.xml	2009-11-19 07:04:26 UTC (rev 96551)
+++ projects/docs/enterprise/4.2.8/Server_Configuration_Guide/en-US/Clustering_Guide_Intro.xml	2009-11-19 07:05:31 UTC (rev 96552)
@@ -10,7 +10,7 @@
       <para>
 	      Clustering allows us to run an application on several parallel servers (a.k.a 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 enterprise applications, as you can improve performance by simply adding more nodes to the cluster. Clustering is crucial for highly available enterprise applications, as it is the clustering infrastructure that supports the redundancy needed for high availability.
       </para>
-	
+      
       <para>
 	      The JBoss Application Server (AS) comes with clustering support out of the box. The simplest way to start a JBoss server cluster is to start several JBoss instances on the same local network, using the <literal>run -c all</literal> command for each instance. Those server instances, all started in the <literal>all</literal> configuration, detect each other and automatically form a cluster.
       </para>
@@ -46,8 +46,94 @@
         <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.
 	</para>
+	</section>
+	<section><title>Separating Clusters</title>
+<!--  	<important><title>Important</title> -->
+	<para>
+		As discussed in <xref linkend="standardServerConfigurations"/>, the production configuration is based on the all configuration and supports clustering as a result. Server instances that run on the same network, which are started using the default configuration settings, will belong to the same cluster. As such, it is important to understand how to separate clusters during server startup. This will be required, for instance, to separate test clusters from production clusters.
+	</para>
+	<!--  </important> -->
+	<para>
+		The attributes and settings discussed below will be covered in detail in the sections that follow. They are introduced here to emphasize the importance of separating clusters during server startup. The relevant MBeans and their associated properties (<property>PartitionName</property> and <property>mcast_addr</property>) <emphasis>both</emphasis> require modification to successfully separate clusters. 
+			</para>
+			<formalpara><title>The HAPartition MBean</title>
+				<para>
+					Starting JBoss servers with their default clustering settings on a local network results in a default cluster named DefaultPartition that includes all server instances as its nodes. This setting is defined in the HAPartition MBean definition packaged with the standard JBoss AS distribution as in the following code sample: 
+				</para>
+			</formalpara>
+			<programlisting><![CDATA[<mbean code="org.jboss.ha.framework.server.ClusterPartition"
+  name="jboss:service=DefaultPartition">
+			
+  <! -- Name of the partition being built -->
+  <attribute name="PartitionName">
+    ${jboss.partition.name:DefaultPartition}
+  </attribute>
+  
+  ...
+  ...
+   
+</mbean>]]>
+			</programlisting>
+			<para>
+				<property>PartitionName</property> is an optional attribute to specify the name of the cluster. Its default value is DefaultPartition as indicated in the code sample above. It is necessary to use the -g  (a.k.a. --partition) command line switch to set this value at JBoss startup and create unique cluster (group) names. 
+			</para>
+			<programlisting><![CDATA[/run.sh -g QAPartition -b 192.168.1.100 -c all]]></programlisting>
+			<para>
+				As will be discussed in <xref linkend="HAPartition"/> to follow, the nodes that form a cluster must have exactly the same <property>PartitionName</property> and <property>ParitionConfig</property> elements. <property>ParitionConfig</property> elements are defined in the Cluster Partition MBean which will be discussed briefly here. 
+			</para> 
+			<formalpara><title>The Cluster Partition MBean</title>
+				<para>
+				Section <xref linkend="jbosscache-jgroups"/> discusses how the JGroups framework provides services to enable peer-to-peer communications between nodes in a cluster.
+				</para>
+			</formalpara>
+			<para>
+				JGroups configurations often appear as a nested attribute in cluster related MBean services, such as the PartitionConfig attribute in the ClusterPartition MBean or the ClusterConfig attribute in the TreeCache MBean. The behavior and properties of each protocol in JGroups can be configured via the MBean attributes. Below is an extract of a JGroups configuration in the ClusterPartition MBean showing the UDP protocol configuration:   
+			</para>
+			
+			<programlisting><![CDATA[<mbean code="org.jboss.ha.framework.server.ClusterPartition"
+  name="jboss:service=${jboss.partition.name:DefaultPartition}">
+	 
+  ... ...
+	 
+  <attribute name="PartitionConfig">
+    <Config>
+	  <UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}" 
+		   mcast_port="${jboss.hapartition.mcast_port:45566}"
+		   tos="8"
+		   ucast_recv_buf_size="20000000"
+		   ucast_send_buf_size="640000"
+		   mcast_recv_buf_size="25000000"
+		   mcast_send_buf_size="640000"
+		   loopback="false"
+           discard_incompatible_packets="true"
+           enable_bundling="false"
+           max_bundle_size="64000"
+           max_bundle_timeout="30"
+           use_incoming_packet_handler="true"
+           use_outgoing_packet_handler="false"
+           ip_ttl="${jgroups.udp.ip_ttl:2}"
+           down_thread="false" up_thread="false"/>
+           ...
+           ...
+    </Config>
+  </attribute>
+</mbean>]]>
+</programlisting>
+			<para>
+				The mcast_addr above specifies the multicast address (class D) for joining a group (i.e., the cluster). If omitted, the default is 228.8.8.8. The -u (a.k.a. --udp) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services.
+			</para>
+			<programlisting><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c all]]>
+</programlisting>
+			<para>
+				This switch sets the jboss.partition.udpGroup system property as indicated in the above ClusterPartition MBean code sample.
+			</para>
+			<important><title>Important</title>
+			<para>
+				The production server configuration is based on the all configuration and supports clustering as a result. Any server instance started using the default production configuration, that is located on the same network, will form part of single default cluster. Test clusters may inadvertently from a part of a production cluster unless the -u and -g flags are set during server startup as described above.
+			</para>  
+			</important>
 </section>
-<section> <title>HAPartition</title>
+<section id="HAPartition"> <title>HAPartition</title>
 	
 <para>
 		    HAPartition is a general purpose service used for a variety of tasks in AS clustering.  At its core, it is an abstraction built on top of a JGroups Channel that provides support for making/receiving RPC invocations on/from one or more cluster members.  HAPartition also supports a distributed registry of which clustering services are running on which cluster members. It provides notifications to interested listeners when the cluster membership changes or the clustered service registry changes. HAPartition forms the core of many of the clustering services we'll be discussing in the rest of this guide, including smart client-side clustered proxies, EJB 2 SFSB replication and entity cache management, farming, HA-JNDI and HA singletons.
@@ -88,16 +174,13 @@
                     in the <literal>HAPartition</literal> MBean.</para>
         <itemizedlist>
           <listitem>
-            <para><emphasis role="bold">PartitionName</emphasis> is an optional attribute to specify the
-		    name of the cluster. Its default value is <literal>DefaultPartition</literal>. Use the <literal>-g </literal> (a.k.a. --partition) command line switch to set this value at JBoss startup.</para>
+            <para><emphasis role="bold">PartitionName</emphasis> is an optional attribute to specify the name of the cluster. Its default value is <literal>DefaultPartition</literal>. Use the <literal>-g </literal> (a.k.a. --partition) command line switch to set this value at JBoss startup.</para>
           </listitem>
           <listitem>
 		  <para><emphasis role="bold">NodeAddress</emphasis> is an optional attribute used to help generate a unique name for this node.</para>
           </listitem>
           <listitem>
-            <para><emphasis role="bold">DeadlockDetection</emphasis> is an optional boolean attribute that
-                            tells JGroups to run message deadlock detection algorithms with every request. Its default
-                            value is <literal>false</literal>.</para>
+            <para><emphasis role="bold">DeadlockDetection</emphasis> is an optional boolean attribute that tells JGroups to run message deadlock detection algorithms with every request. Its default       value is <literal>false</literal>.</para>
           </listitem>
           <listitem>
             <para><emphasis role="bold">StateTransferTimeout</emphasis> is an optional attribute to specify the timeout for state replication across the cluster (in milliseconds). State replication refers to the process of obtaining initial application state from other already-running cluster members at service startup.  Its default value is <literal>30000</literal>. </para>
@@ -231,7 +314,7 @@
                     to hot-deploy the application archive file (e.g., the EAR, WAR or SAR file) in the
 		    <code>all/farm/</code> directory of any of the cluster members and the application will be automatically
                     duplicated across all nodes in the same cluster. If node joins the cluster later, it will pull in
-                    all farm deployed applications in the cluster and deploy them locally at start-up time. If you
+                    all farm deployed applications in the cluster and deploy them locally at startup time. If you
                     delete the application from one of the running cluster server node's <literal>farm/</literal>
                     folder, the application will be undeployed locally and then removed from all other cluster server
                     nodes farm folder (triggers undeployment.) You should manually delete the application from the farm

Modified: projects/docs/enterprise/4.2.8/Server_Configuration_Guide/en-US/Deploy.xml
===================================================================
--- projects/docs/enterprise/4.2.8/Server_Configuration_Guide/en-US/Deploy.xml	2009-11-19 07:04:26 UTC (rev 96551)
+++ projects/docs/enterprise/4.2.8/Server_Configuration_Guide/en-US/Deploy.xml	2009-11-19 07:05:31 UTC (rev 96552)
@@ -35,7 +35,7 @@
     
   </section>
   
-  <section>
+  <section id="standardServerConfigurations">
     <title>Standard Server Configurations</title>
     
     <para>The JBoss Enterprise Platform ships with four server configurations. You can choose which configuration to start by passing the -c parameter to the server startup script. For instance, command run.sh -c all would start the server in the all configuration. Each configuration is contained in a directory named jboss-as/server/[config name]/. You can look into each server configuration's directory to see the default services, applications, and libraries supported in the configuration.</para>

Added: projects/docs/enterprise/4.2.8/Server_Configuration_Guide/publican.cfg
===================================================================
--- projects/docs/enterprise/4.2.8/Server_Configuration_Guide/publican.cfg	                        (rev 0)
+++ projects/docs/enterprise/4.2.8/Server_Configuration_Guide/publican.cfg	2009-11-19 07:05:31 UTC (rev 96552)
@@ -0,0 +1,7 @@
+# Config::Simple 4.59
+# Thu Nov 19 15:20:05 2009
+
+debug: 1
+xml_lang: en-US
+brand: JBoss
+




More information about the jboss-cvs-commits mailing list