Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Maximizing Performance, Availability, and Security of BEA WebLogic Clusters

Maximizing Performance, Availability, and Security of BEA WebLogic Clusters

Through advanced clustering capabilities, BEA WebLogic Server-based e-business applications can be scaled across multiple servers. (Note: WebLogic Server supports multiple types of clustering, only one of which is relevant here - what is referred to as Web Clustering. In Web Clustering, the clustering of the HTTP or presentation layer of the Web application is addressed. This is what is referred to here.) Availability is enhanced by replicating application components and their state, as well as client session state information. In the event of the failure of a server mid-session, the client's session can be restored on another server without loss of session data. The WebLogic Server cluster makes this functionality transparent to clients who view the cluster as a single "virtual server."

As software infrastructure evolved to include specialized applications servers optimized for the delivery of Web content, the network infrastructure also evolved to become "content aware." Cisco Systems is an early pioneer in the development of content switching, a category of network devices which are designed to optimize the delivery of Web-based applications. These high-performance networking devices understand the nature of Web-based transactions and how to route them to the most capable server at any given moment in time. They are used to increase the scalability, performance, availability, and security of Web-based applications. This article describes how Cisco CSS 11000 Series Content Services Switches ("Cisco Content Switches") can be used to maximize the capabilities of BEA WebLogic Clusters.

WebLogic Clustering in Action
A single client transaction may require multiple HTTP operations to complete. A simple example of this might be the presentation interface for a Web-based stock trading portal. A client might go through several steps in executing a trade (getting quotes, doing research, placing the order, receiving a confirmation, etc.) The application keeps track of the "state" of this transaction through each of its subsequent phases. In order to provide protection from failure, this session state can be replicated to another server. In the event of failure of the primary server, the session can be reinitiated to a new server (either the server which hosted the state replica or a third server that recovers the session state from it). WebLogic supports three different methods for replicating and recovering session state: database replication (via JDBC), file-based replication, and in-memory replication.

File and database replication are similar. Each server in the cluster maintains connections to a shared file server or database server. State information is written to a file or to a database record as it is created or changed. Upon failure of a server in the cluster, subsequent client requests are routed to another available member of the cluster (more on this shortly). The new server reads the session ID (established at the initiation of the session and stored in a cookie or encoded in the URL of the request) and fetches the associated state from the database or file system. The new server can now continue processing the client's transaction.

In-memory replication sends state information from a primary server to a designated backup, where it is maintained in memory. Upon failure of the primary server, the client will be routed to a new server. This new server will either have the state replica (in which case it designates a new server as the backup, creates a backup copy of the session state, and assumes the primary role) or it will fetch the state from the backup (in which case it assumes the primary role, cleans up the session state from the old backup, elects a new backup server, and creates a new state replica on the backup). Like the session ID, the backup server ID is encoded in the cookie or URL, allowing the new server to recover session state from the backup. The new server can now continue processing the client's transaction.

Request Routing
Because multiple servers in a cluster are capable of servicing a particular set of client requests, some mechanism must be used to route client requests made to the "virtual server" to one of the real servers in the cluster. The first, and simplest, goal of a request routing mechanism is stated as follows:

1.   To balance load across the available servers in the cluster
For transactions that span multiple HTTP operations (and possibly multiple TCP connections), once a client session has been established with a particular server cluster member, subsequent operations should be directed to the same member until the session completes. This will reduce the overhead and latency associated with fetching session state from another server for each successive operation, thereby improving user response time and improving overall utilization of the cluster.

Therefore a second goal of request routing for WebLogic clusters is:

2.   To maintain "persistent sessions" between clients and cluster members who are cooperating to perform complex transaction logic
Simple DNS-based load balancing available in public domain DNS servers such as BIND will allow the operator to configure multiple host addresses in association with a particular domain name (e.g., www.mystore.com). Clients attempting to access this site will be resolved to each of the configured addresses in "round robin" fashion. Clients will cache the returned name-to-address mapping for the time-to-live configured in the DNS server by the domain name owner. (Note: Although this is the specified behavior for DNS clients, actual behavior varies considerably by operating system and by browser.) Subsequent requests to the same host name will be directed to the same server (using the cached mapping) - thereby performing a crude type of session persistence. A major downfall of DNS-based schemes, however, is that they are incapable of routing around a server failure. Once a client is "bound" to a server, that binding remains in place until the time-to-live for the cached name-to-address mapping expires. Clients can, therefore, continue to attempt to contact a host even though that server has failed or been taken out of service. Clearly, then, something more than simple round-robin DNS is needed for a robust local request routing mechanism. (Note: DNS-based techniques, when deployed in conjunction with more robust local request routing schemes, are in fact very useful for disaster recovery and for balancing load between multiple geographically separate locations.) It is therefore appropriate to expand our list of request routing goals.

3.   To rapidly detect and route around server and process failures
Proxy Web server-based request routing takes the approach of front ending the cluster with an additional server which accepts incoming client requests and directs them to the appropriate server. A BEA WebLogic Server acting as a proxy for third-party Web servers is an example of this approach. By participating in the clustering protocol, the proxy is able to detect failure of servers quickly and route around them. Session persistence is provided via examination of the session cookie. Because it is a full member of the cluster, the proxy understands the session cookie format and the associations between sessions and servers. Because they are general-purpose application servers, however, these proxies are not optimized for the task of request routing and are, therefore, lower performance than specialized load-balancing appliances.

Load-balancing appliances are general-purpose PCs with software tuned for loadbalancing applications. Much like first-generation routers, these general-purpose architectures use a single, centralized CPU for all load-balancing decisions as well as for packet forwarding. Additional functionality is added by utilizing off-the-shelf PC boards (such as SSL acceleration cards) and writing drivers to integrate them with the rest of the system. By focusing on a specific task, these appliances provide better performance, redundancy, and features than their proxy server-based counterparts. Ultimately, however, the hardware architecture of appliances becomes the limiting factor in the performance and scalability of the cluster. For enterprise-class applications, performance must be included as one of the goals for request routing.This goal may be stated as follows.

4.   To scale in accordance with the anticipated client request volume and data transfer rates
In much the same way that general-purpose computing architectures became a limiting factor to scaling for first-generation routers, general-purpose PC architectures have become a limiting factor for request routing. Recognizing this, Cisco Systems pioneered the development of the technology now known as "content switching." The core intellectual property associated with content switches is a switching architecture that separates the processing of the control functions associated with request routing (such as server selection, session establishment, and health checking, etc.) from the processing associated with the packet forwarding functions of request routing (such as network address translation [NAT], TTL decrementing, MAC address replacement, etc.) This fundamental separation of function allows Cisco Content Switches to provide both superior features and function as well as superior performance compared to PC-based load-balancing equipment.

Cisco Content Switches Provide High Server Farm Availability
From a logical perspective, Cisco Content Switches are deployed in front of the WebLogic cluster, as shown in Figure 1. Client requests to the cluster are directed to a Virtual IP address (VIP), representing the cluster to the outside world. A Cisco Content Switch receives connections and HTTP requests from the outside world and routes them to the appropriate member(s) of the cluster based on configured policies. These policies will take into account the failover and persistence mechanisms discussed earlier.

Cisco Content Switches provide a complete set of features for maintaining a high-availability WebLogic cluster, including switch redundancy, session state failover, and advanced health checking.

Switch Redundancy
Cisco Content Switches are typically deployed in redundant pairs. In the event of a failure of the primary switch, the secondary switch will take over. Depending on the configuration of session state redundancy, this failover may take place without disrupting the client-to-server connection. Certain configurations may use both switches as simultaneously active and backup for certain groups of servers or content types - a configuration known as "Active-Active" redundancy.

Session State Redundancy
For some applications, it is critical for the Cisco Content Switch failover to occur without disrupting existing client-to-server connections. For such applications, the content switches can be configured to maintain session state information on both primary and secondary switches. In the event of a failure, the redundant switch will forward packets associated with the existing connection between client and server as soon as the underlying network reconverges.

Advanced Health Checking
Cisco Content Switches use both active and passive techniques to monitor server health. By periodically probing servers, the content switch will rapidly detect server failures and quickly re-route connections to available servers. A large variety of health checking features are supported, including the ability to verify Web servers, SSL servers, Application servers, databases, FTP servers, streaming media Servers, and others.

Cookie Switching Technology Offers Flexible Session Persistence Options
As I previously discussed, for performance reasons, once the initial selection of a server within the cluster is made, it is important to keep connections from the same client routed to the same server until the transaction is completed. This is referred to as "session persistence." It is absolutely critical that the content switch leave the session cookies sent from server to client and from client to server intact. Cisco Content Switches also support two different methods for achieving session state persistence for WebLogic clusters.

Active Cookie Insert
When using this method, the content switch is configured to insert a unique cookie for each server when a new session is detected. This cookie is then sent by the client back to the server and used by the content switch to keep the session routed to the same server.

Cookie Matching
In this mode of operation, the content switch is configured to look for a specific string in the cookie that indicates the server which initially set it. This may either be a string that is uniquely identified in the session cookie for this purpose or a different cookie set by the WebLogic programmer. Although this method is potentially more complex from a programming perspective, it gives the Web application designer the most flexibility in controlling the application behavior. (Note: Cookie matching can be used for numerous purposes, including dynamic load shedding and third-party routing. These techniques will not be discussed here.)

Cisco Content Switches Enhance Site Security
Cisco Content Switches can protect the WebLogic Cluster in four different ways.

Access Control Lists
By constructing access control lists on content switches, the operator can control who has access to the real IP addresses of the cluster members as well as who has access to the switches themselves.

Network Address Translation (NAT)
Cisco Content Switches perform NAT from the Virtual IP address (which represents the cluster to the outside world) to the real IP addresses of the cluster members. This allows the server cluster members to be numbered using private IP address space. More importantly, it hides the details of the internals of the cluster configuration.

Denial-of-Service Protection
Because Cisco Content Switches participate in both TCP and HTTP, they are in an ideal position to detect and stop TCP-and HTTP-based denial of service attacks - before they can impact a server.

Firewall Load Balancing
If the application generates enough traffic to warrant additional firewalls, Cisco Content Switches can be used to load balance multiple firewalls.

SSL Acceleration Improves Performance and Enables Persistence
Running SSL on WebLogic Servers is a tremendous drain on server resources. Cisco SSL Acceleration technology (available in Cisco CSS 11500 Content Switches and Catalyst 6500 switches) can offload SSL processing, enabling server resources to be focused on value-added WebLogic functions. In addition, as persistence information used by the Cisco Content Switches is inside the HTTP header, it is no longer visible when carried inside SSL-encrypted sessions. Cisco SSL Acceleration technology terminates these sessions prior to applying content switching decisions, enabling all of the persistence options previously discussed to become available for secure sites.

High Scalability and Performance Options
In addition to raw switching performance, Cisco Content Switches provide capabilities that can be leveraged to scale the performance of WebLogic Servers as well as the performance of client to Server connections.

Server Farm Partitioning
Cisco Content Switches can partition components of a single Web application across multiple cluster members. For example the following two URLs: http://www.mycompany.com/quotes/getquote.jsp and http://www.mycompany.com/trades/order.jsp could be located on two different servers even though the domain name is the same. This allows the application developer to easily scale the application to multiple servers without many code modifications. Furthermore, it maximizes the cache coherency (and thus, performance) of the servers by keeping requests for the same pages on the same servers.

Additionally, Cisco Content Switches may be used to push requests for cacheable content (such as image files) to a set of caches which may serve them more cost effectively than the application servers themselves.

HTTP 1.1 Connection Remapping
When using HTTP 1.1, clients may request multiple URLs over the same TCP connection. This allows the client and server to run more efficiently by reducing the overhead of TCP connection maintenance. When content is partitioned across multiple servers and/or caches as described in the preceding section, it is important to be able to send multiple HTTP GETs for different pieces of content that might arrive over the same HTTP 1.1 connection to different servers. Effectively, the client side HTTP 1.1 connection must be "remapped" from one server to another. Cisco Content Switches perform this function to maximize connection efficiency.

BEA WebLogic Servers include advanced clustering capabilities to scale applications. Cisco Content Switches maximize the performance, availability, and security of BEA WebLogic Server clusters by understanding the nature of Web-based transactions and routing them to the most capable server at any given moment in time. This combined solution results in maximum end-user experience.


  • www.bea.com/products/weblogic/server/ paper_wls_clustering.pdf
  • More Stories By Vadim Rosenberg

    Vadim Rosenberg is the product marketing manager for BEA WebLogic Server. Before joining BEA two years ago, Vadim had spent 13 years in business software engineering, most recently at Compaq Computers (Tandem Division) developing a fault-tolerant and highly scalable J2EE framework.

    More Stories By Brian Walck

    Brian Walck is the director of Product Management at Cisco Systems. His responsibilities include developing products for Cisco’s content switching product line, as well as developing core strategies in content billing and provisioning. He sits on the Networld+Interop advisory board, and has authored numerous white papers.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    IoT & Smart Cities Stories
    Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
    Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
    IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
    The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
    Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
    Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...