RMI-IIOP Load Balancing and Failover

Sheetal Vartak

Agenda

Overview

What problem/use cases this feature is solving?

Details

Client Configuration

Support for hw load balancers

Open issues

Overview

LB definition :

Load Balancing refers to the process of distributing requests from "Clients" to different server replicas or Name Servers. The goal is to spread the load evenly across the cluster, thus ensuring higher scalability.

Failover definition :

Failover refers to the process of sending the request to the next alive server instance in the event of the chosen server instance going down.

Why was RMI-IIOP FOLB introduced

High availability of EJBs motivated this feature work.

The client should be able to experience high availability when accessing network services. Availability should be transparent and not require altering programs.

New feature in glassfish : The cluster shape can change dynamically. (i.e. instances can be added or deleted dynamically, instances could fail, online upgrades).

Details

The server side ORB (GroupInfoService) registers with GMS (Group Membership Service) to receive updates on the cluster shape changes.

The client side ORB gets notification from the GroupInfoService as and when there is a dynamic reconfiguration of the cluster.

What the user needs to do

IIOP FOLB can be configured for app clients as well as standalone clients.

The client needs to specify the following properties:

com.sun.appserv.iiop.endpoints

com.sun.appserv.iiop.loadbalancingpolicy

These properties can be system properties or be specified in the sun-acc.xml for app clients.

The client does not need to know the cluster shape for specifying the endpoints. It only needs to specify 2 or more endpoints (for bootstrapping purposes). The value of this property should be a comma-separated string of <host>:<port> values.

The load Balancing policy can take 2 values:

ic-based (plain IC based)

ic-based-weighted (Weighted Round Robin algo)

User config conti...

No need to set any other JNDI related property for e.g. InitialContextFactory. The app server's JNDI implementation handles the rest.

Sticky LB

Sticky LB conti...

Sticky LB conti...

APIs

glassfish/appserv-core

package com.sun.appserv.naming

RoundRobinPolicy

S1ASCtxFactory

package com.sun.enterprise.appclient

Main

Package com.sun.enterprise.naming

SerialContext

SerialInitContextFactory

Support for Hardware Load Balancers

Server side config in domain.xml (<jvm-options>) :

-Dcom.sun.corba.ee.ORBUserConfigurators.com.sun.corba.ee.impl.plugin.hwlb.VirtualAddressAgentImpl=dummy

-Dcom.sun.CORBA.ORBVAAHost=host where the HW LB is running

-Dcom.sun.CORBA.ORBVAAPort=port where the HW LB is running

Client side config in JAVA_CMD :

-Dorg.omg.CORBA.ORBInitialHost=host where the HW LB is running

-Dorg.omg.CORBA.ORBInitialPort=port where the HW LB is running

-Dcom.sun.corba.ee.ORBUserConfigurators.com.sun.corba.ee.impl.plugin.hwlb.NoConnectionCacheImpl=dummy

Open Issues

6328358 <BLOCKING>Loadbalancing on IIOP Over SSL Not working

6331551 Loadbalancing on IIOP Over SSL_MUTUALAUTH tests failed

No admin configuration support

Find out more about what kind of HW LB support matters to the customer.

Related Specifications

RMI-IIOP Load Balancing and Failover functional specification GlassFish v1 :

http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/AS9.0-RMI-IIOP-FOLB-FS.sxw

OMG CORBA specification 3.02 :

http://www.omg.org/technology/documents/formal/corba_iiop.htm

IIOP LB/FO design document :

http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/FODynamicCluster.pdf

Provide a service by replicating it in a cluster of machines.

(re)label the current cluster membership.

Advertise all cluster instance addresses and the membership label.

Have the client-side remoting system transparently try another address if one fails (and henceforth stick to it)

When the cluster shape changes, update the cluster membership label in each cluster instance.

Have the client send the membership label that it has along with the request.

When servicing requests, have the server-side system compare the client's membership label with its own label. If out-of-date, return the new label with reply.

When a client tries to lookup an object, the InitialContext instance (IC) that gets created is associated with a particular server instance. From then on, all requests made using that InitialContext object (IC) are sent to the same server instance. This is how stickiness is ensured.If the server instance associated with an IC is down, then the request for lookup is failed over to another server instance. Both the LB policies are based on Sticky-IC. The algorithms used are different.

Sheetal Vartak

2004-08-11T23:34:02

Sheetal Vartak