The aim of this wiki is to briefly analise and summarise Weblogic's ability to provide HTTP session replication between clusters.
- No primary/backup scenario, all clusters are considered active: global load balancer determines which cluster to send it to based on the current number of requests being handled by each cluster.
- Local load balancer deals with intra cluster load balancing.
- Sticky sessions a requirement.
- If cluster node fails, failover is attempted on a local cluster node and if all cluster nodes fail to respond, failover is done to other cluster.
- No proxy architechture for replication, all cluster nodes can use the dedicated replication channel when needed.
- Inter cluster replication limited only to the HTTP session replication use case.
- Clusters must be identical, i.e. each cluster involved in cross cluster replication MUST have the same number of servers.
Two Use Cases
MAN HTTP Session State Replication
- To be used when clusters are close enough and network latency is not an issue.
- Synchronous in-memory session replication between clusters.
- Each server has a designated backup server (looks like this is statically defined in the global load balancer).
- If server fails in cluster, failover is done to another server in same cluster and this server communicates with the original backup (in the other cluster) to retrieve the session.
- If backup server fails, primary servers selects automatically a new backup server. Dunno based on which parameters.
- If communications between clusters fails, servers choose a new backup server in the local cluster. Once communication is reestablished, backup in remote cluster is used.
WAN HTTP Session State Replication
- To be used when clusters are far apart and network latency is noticeable.
- No in-memory replication but instead sessions are stored in database.
- Asynchronous session replication after request retrieving session state from database. On the designated backup node, replicated session is stored in database too.
- If entire cluster fails, failover is done to other cluster and requests continue to be process with last known state in database.
- If server fails in cluster, failover is done to designated backup in other cluster and a new secondary will be chosen to be backup (docu is not clear about whether this new secondary is in the local cluster or in another cluster).