At the end of this chapter you will be able to:
- Cluster Introduction and Architecture
- Networks and Clusters
- Cluster Communication
- A cluster is a group of WebLogic Server instances, working in coordination.
Benefits of Clustering
- There are two main benefits of clustering together WebLogic servers:
- Scalability allows you to add and remove servers without disrupting current services.
- High-Availability ensures that when a server (in a cluster) fails, there are other servers to take over the work so the client is not affected.
The key capabilities of a WebLogic cluster are:
– Application Failover
When an object in an application is performing a task becomes unavailable, another object will take over and finish the job.
When all the services and applications in a single site fail they can switch to a separate site and continue processing.
When a server fails, pinned services can be migrated to another server in a cluster.
– Load Balancing
The even distribution of tasks and communications across multiple servers.
- Applications are generally broken into multiple tiers, each representing their distinct functionality:
- Web tier
- Presentation tier
- Business or object tier
- WebLogic provides clustering support for all three tiers.
- Other services, such as JMS and JDBC, can take advantage of clusters but load-balancing and failover is a little different.
Deciding on Cluster Architecture
Good architecture is somewhat subjective but there are a few global considerations:
– Efficient replication
– Optimal load balancing
– Effective failover
– Reliable communication
- There are two primary cluster architectures to choose from:
- Basic Cluster architecture
- Multi-tier architecture
Basic Cluster Architecture
Basic cluster architecture combines static HTTP, presentation logic, business logic and objects into one cluster.
Multi-Tier Cluster Architecture
The Web tier and the business logic with services can be separated into two clusters.
When to Use Multi-tier Architecture
- The multi-tier cluster is recommended for Web Applications that require:
- Load balancing for method calls to clustered EJBs
- Flexibility for load balancing between servers that provide
- HTTP content and servers that provide clustered objects
- Higher availability (fewer single points of failure)
- More flexible security
Basic Cluster Architecture Advantages and Disadvantages
- The basic cluster architecture has these advantages:
- Easy administration
- Flexible load balancing
- Robust security
- The basic cluster architecture has these disadvantages:
- Cannot load balance EJB method calls
- Load balancing across the tiers may become unbalanced
Multi-tier Advantages and Disadvantages:
- The multi-tier architecture has these advantages:
- Improved load balancing
- Load balancing of EJB methods
- Higher availability
- Improved security options
- The multi-tier architecture has these disadvantages:
- Can create a bottleneck when presentation tier makes frequent calls to the business logic
- Increased licensing cost
- Added firewall configuration complexity
- Proxy servers are used to provide load balancing and failover for a cluster.
- Are the client’s first level of interaction with the cluster
- Give the cluster its single server appearance
- A proxy server can be either software-based or hardware-based.
- A software-based proxy server may be an internal WebLogic servlet or a 3rd party application.
- A hardware-based proxy server is typically a physical load balancer.
Basic Cluster Proxy Architecture:
Similar to the basic cluster architecture, except static content is hosted on non-clustered HTTP servers.
Multi-Tier Cluster Proxy Architecture
Similar to the multi-tier cluster architecture, except static content is hosted on non-clustered HTTP servers.
- WLS is compatible with major Web servers using the following plug-ins:
- Sun Java System Web Server plug-in (formerly Netscape iPlanet or Sun One Web Server)
- IIS plug-in (Microsoft IIS)
- Apache plug-in
- Delegate dynamic content requests to WLS
- Round-robin across a cluster
- Support routing based on URL path or on MIME type of the requested file or both
- Route HTTP requests to back-end WLS instances based on session cookie or URL rewriting
- Avoid failed servers in the cluster
Proxy Plug-in Vs. Load Balancer
- There are many advantages to using a physical load balancer instead of the proxy plug-in:
- No need to configure client plug-ins
- Eliminating the proxy layer reduces the number of connections
- The availability of more sophisticated load balancing algorithms
- There are a number of disadvantages as well:
- Additional administration
- Explicit configuration of “sticky” sessions for stateful web Applications
- If possible, place static web content on separate web servers in the DMZ.
- Use combined tier architecture if your presentation and control tier makes multiple invocations of the business tier.
- Make sure that your architecture choice supports passing active and passive cookies between the cluster and client application.
Cluster in Networks
- WebLogic Server clusters can be created in three different kinds of networks:
- Local Area Networks
- Metropolitan Area Networks
- Wide Area Networks
- When you are configuring your cluster, you will need to keep in mind the type of network you are using.
Local Area Networks
- A local area network (LAN) serves a local set of computers.
- They usually use high quality, high-speed communication links
- Typical data transmission speeds are 100 megabits/second
- Most clusters exist within a single LAN
Metropolitan Area Networks:
- A Metropolitan Area Network (MAN) is a network that usually spans a campus or a city.
- You can have different clusters located reasonably close to each other within a MAN.
Wide Area Networks
- A Wide Area Network (WAN) usually spans a wider geographical area and can be made up of smaller MANs and Local Area Networks (LAN).
- You can have different clusters located in different regions within a WAN.
A cluster can be located in different LANs within a MAN or within a WAN
Server Communication in a Cluster
- WebLogic Server instances in a cluster communicate with one another using two different techniques:
- Multicast (UDP)
- Sockets (peer-to-peer TCP)
- IP multicast broadcasts one-to-many communications among clustered instances.
- IP sockets are used for peer-to-peer communications between servers.
Detecting a Failure:
- WebLogic clusters detect a failure of a server instance in the following ways:
- Through the use of IP sockets
- Through the WebLogic server heartbeat
- If a server in the cluster unexpectedly closes it’s socket, it will be market as “failed” and it’s services will not be used.
- Server instances use multicast to broadcast heartbeats every 10 seconds to other server instances in the cluster.
- If three heartbeats are missed from a peer server, the server is marked as “failed” and it’s services will not be used
- WebLogic Server uses one-to-many communication for:
- Cluster-wide JNDI updates
- Cluster “heartbeats”
- Because all one-to-many communications occur over IP multicast, when designing a cluster, consider these factors:
- If your cluster spans multiple subnets, you network must be configured to reliably transmit messages
- A firewall can break IP multicast transmissions
- The multicast address should not be shared with other applications
- Multicast storms may occur
- WebLogic Server uses peer-to-peer communications for:
- Accessing non-clustered objects that reside on a remote server instance in the cluster
- Replicating HTTP session states and stateful session EJB states between a primary and a secondary server
- Accessing clustered objects that reside on a remote server instance (typically, in a multi-tier cluster architecture)
- Multi-tier clusters will require more IP Sockets than a combined-tier cluster:
- One socket for replicating session states
- One socket for each WebLogic Server in the EJB cluster, for accessing remote objects
- As an example, using a three-node cluster, the worst-case scenario would be five open sockets per server:
- One primary and secondary replicated session
- Each server simultaneously invokes a remote EJB method on each node in the cluster
Communication in a WAN:
- In a WAN, the servers in your cluster may span multiple subnets.
- In order for multicast messages to reliably transmit across the WAN your network must meet the following requirements:
- Full support of IP multicast packet propagation
- A network latency that allows for multicast messages to reach their destination in 200 to 300 milliseconds
- A multicast time-to-live value high enough to ensure that routers do not discard multicast packets
In this chapter we discussed:
- Cluster Introduction and Architecture
- Networks and Clusters
- Cluster Communication