Chapter 7: Load Balancing, Failover, and Component Availability
To deploy components on a cluster so that every component is available from every cluster member use the synchronization feature–see “Synchronization”. The sections below describe additional configuration that is required for components deployed in a cluster.
Stateful components such as EJB stateful session beans require additional configuration when deployed in a cluster. You must configure persistent state storage or inter-server replication so that the instance state is available on the different servers in the cluster. For details, see Chapter 28, “Configuring Persistence for Stateful Session Components,” in the EAServer Programmer’s Guide.
Partitioning restricts components to a subset of servers within a cluster. Partition an application by creating different logical server names, then installing component subsets into each logical server definition. Partitioning allows you to manually load balance within your cluster.
The Installed Packages folder lists the packages that are installed in a particular server. Even if a package is defined in a server's repository, and all files required for components in the package are available to the server, the server does not allow creation of instances of components for packages that are not installed in the server.
The following is a partitioning example:
Cluster “MyCluster” has
package “P1” installed.
package “P2” installed.
packages “P1” and “P2” installed.
Package P1 is available from
and package P2 is available from
See Chapter 3, “Managing Applications and Packages in EAServer Manager,” in the EAServer Programmer’s Guide for more information about installing packages.
You may want to use partitioning to separate CPU-bound components from database-bound components.
You can use EAServer Manager to mark selected components to support transparent automatic failover. If a client has an object reference for a component on a server that is a member of a cluster, the client’s object reference will provide transparent failover, unless all the servers in the cluster fail.
To avoid a single point of failure for a cluster, set the com.sybase.jaguar.cluster.startup cluster property to “check_servers.” See “Cluster start-up options” for more information.
Automatic failover is not the default for EAServer components. When a client is using a component that does not support automatic failover, and the server hosting that component fails, the client must create a new instance of that component to recover from the failure (which typically presents itself as a CORBA COMM_FAILURE system exception). However, the client does not need to create a new session, since the SessionManager::Session object supports automatic failover. The SessionManager::Session object is used implicitly by the PowerBuilder connection object and by the EAServer COM (ActiveX) proxy.
Setting automatic failover for a component from EAServer Manager
Locate and highlight the component you want to set.
Select File | Properties.
Select the Transactions tab.
Select the Automatic demarcation/deactivation check box and the Autofailover check box.
The following guidelines may be useful when you are writing components that support automatic failover.
The component should not retain conversational state in server memory (component instance variables), since the conversational state cannot be restored when a remote method call fails over from one server to another.
The following example shows why this would not work:
The client calls method A on component C on Server1. Method A retains some state in the instance in Server1’s memory.
The client calls method B on the same component. Server1 has failed, so the client transparently fails over to Server2 and calls method B on a newly instantiated instance of component B in Server2. Since method A has not been called on this instance, it does not hold the saved state.
If you must save state between calls, consider saving it in a database. For example, in an Internet shopping application, a “shopping cart” might be represented by a database entity, and every method call on the ShoppingCart component can save the appropriate changes to the database.
In other cases, you might want to code the client to use IDL structure and sequence types to pass a list of values to a single component method, instead of passing each value in a separate call and having the component attempt to collect the list of values using conversational state. This approach also reduces network traffic, and can greatly improve response times.
Duplicate database inserts or updates can result from the use of automatic failover, as in the following example:
The client calls method insertStuff on component C on Server1.
The insertStuff method inserts a record into a database.
The transaction is committed.
The server crashes before sending the reply message over the network to the client.
The client transparently fails over, and calls method insertStuff on a new instance of component C on Server2.
The insertStuff method inserts a new (duplicate) record into the database.
Everything works this time, but we now have a duplicate record in the database.
A simple design approach can help avoid such problems. Add a method to component C to generate a new ID for insertion: for example, newStuffId:
The client calls newStuffId to get a new unique ID. If you do not permit gaps in the ID numbering sequence, you cannot use this approach.
The client then calls insertStuff, passing the StuffId as a parameter.
insertStuff verifies that a record for that StuffId has already been inserted (or the database insert fails if StuffId is a unique key in the database).
Although insertStuff has been called twice, only one database change has been made.
A component that supports automatic failover can use other components or resources that do not directly support automatic failover.
|Copyright © 2005. Sybase Inc. All rights reserved.|