Previous
Next


HTTP Session-Based Load Balancing  Locate

WSO2 SOA Enablement Server supports Level 7 load balancing. (The number refers to the application layer in the OSI model.) To understand this feature you need to be familiar with these terms:

Cluster

A set of computers with identical functionality

Node

A member of a cluster

The common scenario is that a user connects to a load balancer and it sends the request to a particular node in a cluster. The load balancer must maintain session affinity, meaning that all requests related to a session are forwarded to the same node. In the current implementation the load balancer forwards all requests from a single client to exactly one node. When the session is started and maintained by one client the affinity is guaranteed.

Currently CISCO Content Services Switch™ is the only supported load balancer, but it should be easy to migrate to other load balancing hardware that WSO2 may support in the future.

WSO2 SOA Enablement Server for Java load balancing has been tested on CISCO Content Services Switch CSS 11500.

[Note]Note

The nodes of a cluster must have the same functionality. In the WSO2 SOA Enablement Server for Java point of view, this means they must have the same Web service packages deployed on the server. This can be assured using the 'hot deployment' feature.

In hot deployment, there is an application directory that holds application packages that are waiting to be deployed to the WSO2 SOA Enablement Server server (by default $WASP_HOME/app) and a working directory (by default $WASP_HOME/work) that contains unpacked working copies of the application packages. This is done automatically. When a new package appears in app it is automatically installed.

This feature makes it straightforward to put the application directory on a network drive shared by all the nodes. The locations of application and working directory are configurable in the conf/serverconf.xml file. Please see 'Hot' Deployment for more details.

CISCO Content Services Switch-Based Load Balancing  Locate

WSO2 SOA Enablement Server for Java contains support for load balancing mechanisms provided by CISCO Content Services Switch 430 - Cookie-Passive Sticky and Cookie-Insert Sticky. You can find more information about the CISCO Content Services Switch at http://www.cisco.com/warp/public/cc/pd/cxsr/400/index.shtml.

Cookie Passive Sticky  Locate

Cookie-passive sticky relies on cookie information (an HTTP header) that has to be generated by the server. The server affinity is based on the cookie. Client requests have to continue with the server cookie (contained in the last response). Communication is proxied by CISCO Content Services Switch. The name of the cookie is a configurable option of CISCO Content Services Switch.

Cookie Insert Sticky  Locate

Unlike the cookie-passive sticky, the cookie-insert option relies on a cookie created by CISCO Content Services Switch. With cookie insert, the CISCO Content Services Switch inserts a unique cookie for each server when it detects a new session. The name of the cookie is a configurable option of CISCO Content Services Switch. Client requests have to continue with the cookie (contained in the previous response). Communication is proxied by CISCO Content Services Switch.

WSO2 SOA Enablement Server for Java Support for CISCO Content Services Switch  Locate

Stateful SOAP communication with WSO2 SOA Enablement Server assumes that all requests from a client are processed by one specific Web service instance running on a specific WSO2 SOA Enablement Server instance. Each message from a server is marked by a unique id, which identifies the Web service instance. As load balancing is based on distributing SOAP requests among a number of server instances, some stateful SOAP requests could be redirected to incorrect server instances. To prevent this happening, requests need to be marked with a cookie with a configurable name (a sticky cookie). CISCO Content Services Switch directs all requests with the same cookie value to the same server instance. These cookies are set in HTTP responses (either by CISCO Content Services Switch or the server, according to mode). The client must 'remember' these cookies and set them in subsequent HTTP requests over the course of the communication. This client functionality is implemented in the package lb_cookies_interceptor.jar.

When CISCO Content Services Switch runs in Cookie-Passive Sticky mode, it expects server to insert sticky cookie. This functionality is also implemented by the package lb_cookies_interceptor.jar.

Both techniques require support from the software which is to be balanced using CISCO Content Services Switch. The support in WSO2 SOA Enablement Server is provided by the lb_cookies_interceptor.jar package.

To add support for load balancing to your installation of WSO2 SOA Enablement Server, you must install the lb_cookies_interceptor.jar package on the client side. (Server-side installation is only required for cookie-passive.) This can be done either automatically by selecting the 'custom' option followed by 'Load Balancing Cookies Interceptor' when installing WSO2 SOA Enablement Server for Java™ using the Installation Wizard, or manually as follows:

  • Support for Cookie-Passive Sticky - You must install the lb_cookies_interceptor.jar package on both server and client sides. To install the package on the client side, simply add it to the classpath of your application. To install the package onto the WSO2 SOA Enablement Server, you may deploy it using the deploy tool or the WSO2 SOA Enablement Server for Java administration console, or you may copy it into the WASP_HOME/app directory.

  • Support for Cookie-Insert Sticky - You must install the lb_cookies_interceptor.jar package on the client side. To install the package on the client side, simply add it to the classpath of your application.

The load-balancing technique (cookie-passive or cookie-insert) and the name of the unique cookie is set in the deployment descriptor of the lb_cookies_interceptor.jar package. The default technique is cookie-insert and the default cookie name is 'sticky-cookie.' (please see Example 3) To change these settings, you must edit the deployment descriptor and redeploy it.

Example 3. Deployment Descriptor of the lb_cookies_interceptor Package

<?xml version="1.0" encoding="UTF-8" ?>
<package name="lb_cookies_interceptor"
            library="true"
            client-package="true"
            targetNamespace="http://wso2.com/wasp/app/lb_cookies_interceptor"
            version="4.6"
            xmlns:tns="http://wso2.com/wasp/app/lb_cookies_interceptor"
            xmlns:ext="http://wso2.com/wasp/package/lb_cookies_interceptor"
            xmlns="http://wso2.com/wasp/package/1.2">
    <documentation url="http://todo">
        <display-name>Loadbalancing cookies interceptors</display-name>
        <description>Loadbalancing cookies interceptors</description>
        <small-icon>http://www.wso2.com/images/logo_others.gif</small-icon>
    </documentation>
    <!-- Lodbalancing module - adds cookies interceptors to the default interceptor chains -->
    <module name="LbModule" 
                     implementation-class="com.systinet.wasp.lb_cookies_interceptor.LbModule">
        <!-- Sticky cookie name -->
        <ext:stickyName>sticky-cookie</ext:stickyName>
        <!-- mode - either cookie-insert or cookie-passive -->
        <ext:mode>cookie-insert</ext:mode>
    </module>
</package>

As you can see, the package deployment descriptor contains the module 'LbModule' and its configuration options. The cookie name is set in the <ext:stickyName> element. The load-balancing technique is set in the <ext:mode> element.



Previous
Next