Connection with Load Balancing Hardware Failover with Load Balancing Hardware
6.2.3.1 Connection with Load Balancing Hardware
Figure 6–3 illustrates the connection procedure for a client accessing a cluster through a load balancer. Figure 6–3 Connection with Load Balancing Hardware When the client of a Web application requests a servlet using a public IP address: 1. The load balancer routes the clients connection request to a WebLogic Server cluster in accordance with its configured policies. It directs the request to WebLogic Server A. 2. WebLogic Server A acts as the primary host of the clients servlet session state. It uses the ranking system described in Section 6.2.1.2, Using Replication Groups to select a server to host the replica of the session state. In the example above, WebLogic Server B is selected to host the replica. 3. The client is instructed to record the location of WebLogic Server instances A and B in a local cookie. If the client does not allow cookies, the record of the primary and secondary servers can be recorded in the URL returned to the client via URL rewriting. 6-10 Using Clusters for Oracle WebLogic Server 4. As the client makes additional requests to the cluster, the load balancer uses an identifier in the client-side cookie to ensure that those requests continue to go to WebLogic Server A rather than being load-balanced to another server in the cluster. This ensures that the client remains associated with the server hosting the primary session object for the life of the session.6.2.3.2 Failover with Load Balancing Hardware
Should Server A fail during the course of the clients session, the clients next connection request to Server A also fails, as illustrated in Figure 6–4 . Figure 6–4 Failover with Load Balancing Hardware In response to the connection failure: 1. The load balancing hardware uses its configured policies to direct the request to an available WebLogic Server in the cluster. In the above example, assume that the load balancer routes the clients request to WebLogic Server C after WebLogic Server A fails. Note: You must enable WebLogic Server URL rewriting capabilities to support clients that disallow cookies, as described in Section 6.2.2.1.1, Using URL Rewriting to Track Session Replicas. Failover and Replication in a Cluster 6-11 2. When the client connects to WebLogic Server C, the server uses the information in the clients cookie or the information in the HTTP request if URL rewriting is used to acquire the session state replica on WebLogic Server B. The failover process remains completely transparent to the client. WebLogic Server C becomes the new host for the clients primary session state, and WebLogic Server B continues to host the session state replica. This new information about the primary and secondary host is again updated in the clients cookie, or via URL rewriting.6.2.4 Session State Replication Across Clusters in a MANWAN
Parts
» Oracle Fusion Middleware Online Documentation Library
» Document Scope and Audience Guide to this Document
» What Are the Benefits of Clustering? What Are the Key Capabilities of a Cluster?
» Servlets and JSPs EJBs and RMI Objects
» Getting Connections with Clustered JDBC Failover and Load Balancing for JDBC Connections
» Pure-Java Versus Native Socket Reader Implementations
» Client Communication via Sockets
» How WebLogic Server Creates the Cluster-Wide JNDI Tree
» How WebLogic Server Updates the JNDI Tree Client Interaction with the Cluster-Wide JNDI Tree
» Load Balancer Configuration Requirements Load Balancers and the WebLogic Session Cookie
» Related Programming Considerations How Session Connection and Failover Works with a Load Balancer
» Round-Robin Load Balancing Weight-Based Load Balancing
» Transactional Collocation Optimization for Collocated Objects
» Methods of Configuring Clusters Load Balancing for JDBC Connections
» Using Replication Groups HTTP Session State Replication
» Connection with Load Balancing Hardware Failover with Load Balancing Hardware
» Configuration Requirements for Cross-Cluster Replication
» Configuring Session State Replication Across Clusters
» Clustering Objects with Replica-Aware Stubs
» Failover and JDBC Connections Understanding Server and Service Migration
» Migration Terminology Oracle Fusion Middleware Online Documentation Library
» Features That Use Leasing Leasing Versions
» Determining Which Type of Leasing To Use High-availability Database Leasing
» Non-database Consensus Leasing Leasing
» Preparing for Automatic Whole Server Migration
» Configuring Automatic Whole Server Migration
» Startup Process in a Cluster with Migratable Servers
» Automatic Whole Server Migration Process
» Manual Whole Server Migration Process Administration Server Role in Whole Server Migration
» Migratable Server Behavior in a Cluster Node Manager Role in Whole Server Migration
» Cluster Master Role in Whole Server Migration
» JMS-related Services JTA Transaction Recovery Service
» Custom Store Availability for JMS Services Default File Store Availability for JTA
» Best Practices for Targeting JMS when Configuring Automatic Service Migration
» Architecture Web Application Tiers
» Combined Tier Architecture De-Militarized Zone DMZ Load Balancer Proxy Plug-In
» No Collocation Optimization Firewall Restrictions
» Multi-Tier Proxy Architecture Proxy Architecture Benefits Proxy Architecture Limitations
» Proxy Plug-In Versus Load Balancer
» DMZ with Two Firewall Configuration
» Dynamic Cluster Address If you do not explicitly define a cluster address
» Configuration Roadmap Install WebLogic Server
» Starting a WebLogic Server Cluster
» Configure Node Manager Configure Load Balancing Method for EJBs and RMIs
» Sample web.xml This section contains a sample deployment descriptor file
» Accessing Applications Via the Proxy Server Ensure that applications clients will
» Configure Replication Groups Configure Migratable Targets for Pinned Services
» Migrating When the Currently Active Host is Unavailable Use this migration
» Configure Multicast Time-To-Live TTL Configure Multicast Buffer Size
» Cluster-Related Configuration Options Follow Usage and Configuration Guidelines
» Manual Migration of the JTA Transaction Recovery Service State Management in a Cluster
» Naming Considerations Administration Server Considerations
» Firewall Considerations Avoiding Problems
» Check the Server Version Numbers Check the Multicast Address Check the CLASSPATH Value
Show more