IIOP Failover in Dynamic Clusters

Requirement: Clients should experience high-availability when accessing network services. Availability should be transparent and not require altering programs. Problem: Availability needs to work on multiple platforms and must not require additional hardware/software, other than the remoting system. Solution: Replicate the service in a cluster. Advertise all replica addresses. On client invocation, if a replica address fails, have the remoting infrastructure try another address. Requirement: The number of replicas in the cluster can change dynamically (e.g., more/less instances to handle heavier/lighter loads, instances failing, online upgrades). Problem: Clients need to know the current cluster membership but are not able to participate in group membership communication. Solution: Give the initial cluster membership a label. Whenever membership changes generate a new label. Advertise the label. When a client invokes a service, send the label (as “out-of-band ” data) along with the request. When servicing a request and the label is out-of-date, have the server return the new membership label and addresses as out-of-band data in the reply. IIOP: Add label/addresses to IORs. When invoking an IOR try another address if one fails. Cache successful addresses to avoid fallback (important for stateful-sessions). Send the label with requests as a ServiceContext. If outof-date return an up-to-date reference with the reply in a ServiceContext. Experience: In an application server, this failover mechanism did not degrade system performance. Contribution: This failover mechanism provides highavailability IIOP communication in dynamic clusters