Replication Within a MAN This section discusses possible failover scenarios Failover Scenarios in a MAN The following sections describe various failover

Failover and Replication in a Cluster 6-15 If backup-cluster-address is NULL, WebLogic Server assumes that you are using a third-party product to handle replication. In this case, session data is not persisted to the remote database, but is persisted locally.

6.2.4.4 Configuring a Replication Channel

A replication channel is a normal network channel that is dedicated specifically to replication traffic between clusters. For general information on configuring a network channel, see Configuring Network Resources in Configuring Server Environments for Oracle WebLogic Server. When creating a network channel to be used as the replication channel in cross-cluster replication, the following considerations apply: ■ You must ensure that the replication channel is created on all cluster members and has the same name. ■ The channel should be used only for replication. Other types of network traffic should be directed to other network channels.

6.2.4.5 MAN HTTP Session State Replication

Resources within a metropolitan area network MAN are often in physically separate locations, but are geographically close enough that network latency is not an issue. Network communication in a MAN generally has low latency and fast interconnect. Clusters within a MAN can be installed in physically separate locations which improves availability. To provide failover within a MAN, WebLogic Server provides an in-memory mechanism that works between two separate clusters. This allows session state to be replicated synchronously from one cluster to another, provided that the network latency is a few milliseconds. The advantage of using a synchronous method is that reliability of in-memory replication is guaranteed.

6.2.4.5.1 Replication Within a MAN This section discusses possible failover scenarios

across multiple clusters within a MAN. Figure 6–6 shows a typical multi-cluster environment within a MAN. Note: The performance of synchronous state replication is dependant on the network latency between clusters. You should use this method only if the network latency between the clusters is tolerable. 6-16 Using Clusters for Oracle WebLogic Server Figure 6–6 MAN Replication This figure shows the following HTTP session state scenario: 1. A client makes a request which passes through the global load balancer. 2. The global load balancer passes the request to a local load balancer based on current system load. In this case, the session request is passed to Local Load Balancer 1. 3. The local load balancer in turn passes the request to a server within a cluster based on system load, in this case S1. Once the request reaches S1, this Managed Server becomes the primary server for this HTTP session. This server will handle subsequent requests assuming there are no failures. 4. Session state information is stored in the database of the primary cluster. 5. After the server establishes the HTTP session, the current session state is replicated to the designated secondary server.

6.2.4.5.2 Failover Scenarios in a MAN The following sections describe various failover

scenarios based on the MAN configuration in Figure 6–6 . Failover Scenario 1 Failover and Replication in a Cluster 6-17 If all of the servers in Cluster 1 fail, the global load balancer will automatically fail all subsequent session requests to Cluster 2. All sessions that have been replicated to Cluster 2 will be recovered and the client will experience no data loss. Failover Scenario 2 Assume that the primary server S1 is being hosted on Cluster 1, and the secondary server S6 is being hosted on Cluster 2. If S1 crashes, then any other server in Cluster 1 S2 or S3 can pick up the request and retrieve the session data from server S6. S6 will continue to be the backup server. Failover Scenario 3 Assume that the primary server S1 is being hosted on Cluster 1, and the secondary server S6 is being hosted on Cluster 2. If the secondary server S6 fails, then the primary server S1 will automatically select a new secondary server on Cluster 2. Upon receiving a client request, the session information will be backed up on the new secondary server. Failover Scenario 4 If the communication between the two clusters fails, the primary server will automatically replicate session state to a new secondary server within the local cluster. Once the communication between the two clusters, any subsequent client requests will be replicated on the remote cluster.

6.2.4.5.3 MAN Replication, Load Balancers, and Session Stickiness MAN replication relies