Skip Navigation Links | |
Exit Print View | |
Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide |
1. High Availability in GlassFish Server
2. Setting Up SSH for Centralized Administration
3. Administering GlassFish Server Nodes
4. Administering GlassFish Server Clusters
5. Administering GlassFish Server Instances
6. Administering Named Configurations
7. Configuring Web Servers for HTTP Load Balancing
8. Configuring HTTP Load Balancing
9. Upgrading Applications Without Loss of Availability
10. Configuring High Availability Session Persistence and Failover
11. Configuring Java Message Service High Availability
12. RMI-IIOP Load Balancing and Failover
General Requirements for Configuring Load Balancing
Enabling RMI-IIOP Hardware Load Balancing and Failover
To Enable RMI-IIOP Hardware Load Balancing for the Application Client Container
Per-Request Load Balancing (PRLB)
Enabling Per-Request Load Balancing
To Enable RMI-IIOP Per-Request Load Balancing for a Stateless EJB
The following topics are addressed here:
When InitialContext load balancing is used, the client calls the InitialContext() method to create a new InitialContext (IC) object that is associated with a particular server instance. JNDI lookups are then performed on that IC object, and all lookup requests made using that IC object are sent to the same server instance. All EJBHome objects looked up with that InitialContext are hosted on the same target server. Any bean references obtained henceforth are also created on the same target host. This effectively provides load balancing, since all clients randomize the list of live target servers when creating InitialContext objects. If the target server instance goes down, the lookup or EJB method invocation will failover to another server instance. All objects derived from same InitialContext will failover to the same server instance.
IIOP load balancing and failover happens transparently. No special steps are needed during application deployment. IIOP load balancing and failover for the GlassFish Server supports dynamically reconfigured clusters. If the GlassFish Server instance on which the application client is deployed participates in a cluster, the GlassFish Server finds all currently active IIOP endpoints in the cluster automatically. Therefore, you are not required to manually update the list of endpoints if a new instance is added to the cluster or deleted from the cluster. However, a client should have at least two endpoints specified for bootstrapping purposes, in case one of the endpoints has failed.
GlassFish Server uses a randomization and round-robin algorithm for RMI-IIOP load balancing and failover.
When an RMI-IIOP client first creates a new InitialContext object, the list of available GlassFish Server IIOP endpoints is randomized for that client. For that InitialContext object, the load balancer directs lookup requests and other InitialContext operations to an endpoint on the randomized list. If that endpoint is not available then a different random endpoint in the list is used.
Each time the client subsequently creates a new InitialContext object, the endpoint list is rotated so that a different IIOP endpoint is used for InitialContext operations. The rotation is randomized, so the rotation is not to the next endpoint in the list, but instead to a random endpoint in the list.
When you obtain or create beans from references obtained by an InitialContext object, those beans are created on the GlassFish Server instance serving the IIOP endpoint assigned to the InitialContext object. The references to those beans contain the IIOP endpoint addresses of all GlassFish Server instances in the cluster.
The primary endpoint is the bean endpoint corresponding to the InitialContext endpoint used to look up or create the bean. The other IIOP endpoints in the cluster are designated as alternate endpoints. If the bean's primary endpoint becomes unavailable, further requests on that bean fail over to one of the alternate endpoints.
You can configure RMI-IIOP load balancing and failover to work with applications running in the ACC.
You can enable RMI-IIOP load balancing and failover for applications running in the application client container (ACC). Weighted round-robin load balancing is also supported.
This procedure provides an overview of the steps necessary to enable RMI-IIOP load balancing and failover with the application client container (ACC). For additional information on the ACC, see Developing Clients Using the ACC in Oracle GlassFish Server 3.1 Application Development Guide.
Before You Begin
The first five steps in this procedure are only necessary if you are enabling RMI-IIOP load balancing on a system other than the DAS. This is common in production environment, but less common in a development environment. For example, a developer who wants to experiment with a cluster and load balancing might create two instances on the same system on which the DAS is running. In such cases, steps 1-5 are unnecessary.
This utility produces an appclient.jar file. For more information on package-appclient, see package-appclient(1M).
The file is at appclient-install-dir /config/.
For a list of the path variables to update, see package-appclient(1M).
For example, on UNIX use chmod 700.
You specify the IIOP listeners as endpoints in Step 7.
For each instance, obtain the IIOP listener ports as follows:
asadmin> list-instances
A list of instances and their status (running, not running) is displayed.
The instances for which you want to display the IIOP listener ports must be running.
asadmin> get servers.server.instance-name.system-property.*.value
For example, for an instance name in1, you would enter the following command:
asadmin> get servers.server.in1.system-property.*.value
Use the endpoints that you obtained in Step 6.
If the GlassFish Server instance on which the application client is deployed participates in a cluster, the ACC finds all currently active IIOP endpoints in the cluster automatically. However, a client should have at least two endpoints specified for bootstrapping purposes, in case one of the endpoints has failed.
The target-server element specifies one or more IIOP endpoints used for load balancing. The address attribute is an IPv4 address or host name, and the port attribute specifies the port number. See client-container in Oracle GlassFish Server 3.1 Application Deployment Guide.
As an alternative to using target-server elements, you can use the endpoints property as follows:
jvmarg value = "-Dcom.sun.appserv.iiop.endpoints=host1:port1,host2:port2,..."
asadmin set instance-name.lb-weight=weight
… <client-container send-password="true"> <property name="com.sun.appserv.iiop.loadbalancingpolicy" \ value="ic-based-weighed"/> …
Keep the client jar file on the client machine.
For example:
asadmin --user admin --passwordfile pw.txt deploy --target cluster1 \ --retrieve my_dir myapp.ear
appclient --client my_dir/myapp.jar
Example 12-1 Setting Load-Balancing Weights for RMI-IIOP Weighted Round-Robin Load Balancing
In this example, the load-balancing weights in a cluster of three instances are to be set as shown in the following table.
|
The sequence of commands to set these load balancing weights is as follows:
asadmin set i1.lb-weight=100 asadmin set i2.lb-weight=200 asadmin set i3.lb-weight=300
Next Steps
To test failover, stop one instance in the cluster and see that the application functions normally. You can also have breakpoints (or sleeps) in your client application.
To test load balancing, use multiple clients and see how the load gets distributed among all endpoints.
See Also
See Enabling the High Availability Session Persistence Service for instructions on enabling the session availability service for a cluster or for a Web, EJB, or JMS container running in a cluster.