Red Hat Training

A Red Hat training course is available for JBoss Enterprise SOA Platform

Chapter 18. Managing Your Cluster

18.1. Cluster

A cluster is a group of loosely-connected computers that work together in such a way that they can be viewed as a single system. The components (or nodes) of a cluster are usually connected to each other through fast local area networks, each node running its own operating system. Clustering middleware orchestrates collaboration between the nodes, allowing users and applications to treat the cluster as a single processor. Clusters are effective for scalable enterprise applications, since performance is improved by adding more nodes as required. Furthermore, if at anytime one node fails, others can take on its load.

18.2. Stateless Service Failover

The JBoss Enterprise SOA Platform provides "failover" capabilities for stateless services. If one node fails, the service will be resumed on another. The ServiceInvoker hides much of the fail-over complexity from users but it only works with native Enterprise Service Bus messages and, furthermore, not every gateway has been programmed to take advantage of it. Hence, non-ESB Aware messages sent to these gateway implementations may not be able to use service fail-over.

18.3. ServiceInvoker

The ServiceInvoker (org.jboss.soa.esb.client.ServiceInvoker) manages the delivery of messages to the specified Services. It also manages the loading of end-point references and the selection of couriers, thereby providing a unified interface for message delivery.
The ServiceInvoker was introduced to help simplify the development effort as it hides much in the way of the lower-level details and works opaquely with the stateless service fail- over mechanisms. As such, ServiceInvoker is the recommended client-side interface for using services within the JBoss Enterprise SOA Platform.
You can create an instance of the ServiceInvoker for each service with which the client interacts. Once created, an instance examines the registry to determine the primary end-point reference and, in the case of fail-overs, any alternative end-point references.

18.4. Load Balancing

Load balancing is a computer networking methodology to distribute workload across multiple computers or a computer cluster, network links, central processing units, disk drives, or other resources, to achieve optimal resource utilization, maximize throughput, minimize response time, and avoid overload. Using multiple components with load balancing, instead of a single component, also increases reliability through redundancy.

18.5. Configure a Load-Balancing Policy

Procedure 18.1. Task

  1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployers/jbossesb-properties.xml.
  2. Scroll down to the org.jboss.soa.esb.loadbalancer.policy property. Set it with the policy you wish to use.
  3. Save the file and exit.

18.6. Load Balancing Policies

Table 18.1. Load balancing Policies Available

Policy Name Description
first available If a healthy service binding is found it will be used until it dies. The next end-point reference in the list will then be used. There is no load balancing between the two service instances with this policy.
round robin A standard load-balancing policy whereby each end-point reference is utilised in list order.
random robin This is like the round robin, but the selection is randomized.

Note

The end-point reference list used by the policy may become smaller over time as "dead" EPRs are removed. When the list is exhausted or the time-to-live of the list cache is exceeded, the ServiceInvoker will obtain a fresh list of EPRs from the Registry.

18.7. Change the Registry's Cache's Lifespan

Procedure 18.2. Task

  1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployers/jbossesb-properties.xml.
  2. Scroll down to the section that contains property name="org.jboss.soa.esb.registry.cache.validityPeriod. Set this property (which is the time-out value) to what you require (the default is sixty seconds): 
    <properties name="core">
<property name="org.jboss.soa.esb.registry.cache.life" value="60000"/>
<!-- 60 seconds is the default -->
</properties>
  3. Save the file and exit.
Result

The ServiceInvoker will obtain a fresh list of end-point references from the registry when this time value is exceeded.

18.8. Run the Same Service on More than One Node in a Cluster

Procedure 18.3. Task

  • To run the same service on more than one node in a cluster, wait until the Registry's cache revalidates.

18.9. Remove Failed End-Point References from the Registry

Procedure 18.4. Task

  1. Open the jbossesb-properties.xml in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployers/jbossesb-properties.xml.
  2. Scroll down to the section that contains org.jboss.soa.esb.failure.detect.removeDeadEPR. Set this property to true.
  3. Save the file and exit.

    Warning

    Note that the default setting is false because this feature should be used with extreme care. If it is employed, the end-point reference for a service that is simply overloaded and, therefore, slow to respond may, inadvertently, be removed by mistake. There will be no further interactions with these "orphaned" services you may have to restart them.

18.10. Support for Clustering in the BPEL Engine

In order to make the BPEL Engine work correctly in a clustered environment, you must configure it to utilise a database shared between all of the environment's nodes. (This is because BPEL persists every process states in a database.)
In order for it to dispatch the SOAP requests to all of the nodes correctly, a load balancer is also required.

18.11. Configure BPEL Clustering

Procedure 18.5. Task

  1. Open the jboss-beans.xml example file in your text editor.
  2. Set the @database@ property to one of the following:
    • mysql
    • postgre
    • db2
    • sqlserver
    • oracle
    • sybase
  3. Save the file and exit.
  4. Copy the jboss-beans.xml file to SOA_ROOT/jboss-as/server/PROFILE/deploy/riftsaw.sar/META-INF/.
  5. Replace SOA_ROOT/jboss-as/server/PROFILE/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml with riftsaw-cache-manager-jboss-beans.xml.

    Warning

    Attempting to install another BPEL Engine deployment can break the integration.

    Note

    If you want to use the service that you have deployed onto the cluster, specify the load balancer's URL instead of the SOAP address in the WSDL file.

18.12. Deploy a BPEL Process on a Cluster

Procedure 18.6. Task

  • Copy your BPEL artifact into the farm directory: cp FILENAME.jar SOA_ROOT/jboss-as/server/PROFILE/farm.

    Note

    Remember that clustering is only available for the "production" and "all" profiles.

    Note

    When you invoke your BPEL service, specify the load balancer's URL (instead of the SOAP address specified in the WSDL). The load balancer will then decide which of the cluster's servers to use.