This is the WSO2 Elastic Load Balancer documentation version 2.0.1. View documentation for the latest release.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

The WSO2 Elastic Load Balancer is built using Apache Tribes, which is the group management framework used by Apache Tomcat as well as Apache Axis2, Apache Axis2 clustering module, Apache Synapse - one of the best performant mediation frameworks, and the autoscaling component from the award-winning WSO2 Carbon framework. The diagram below depicts its high-level architectural view.

Figure: The WSO2 ELB Architectural Components

WSO2 Carbon Auto-Scaling

Keeps track of the traffic to each Cloud Service cluster, and makes decisions related to scaling the system up and down depending on the load fluctuation. It is also responsible for keeping a sanity check on the system. This sanity check ensures that the minimum system configuration, such as the minimum number of running instances of each Service and load balancer cluster is maintained at all times.

Synapse Mediation Framework

A Synapse endpoint by the name "ServiceDynamicLoadBalanceEndpoint" routes messages to the appropriate node.

First, the cloud service cluster to which the message has to be sent is identified using the Host HTTP header. Then a member from that service cluster to which the message has to be routed to, is selected according to the load balancing algorithm specified, and the message is sent to that member. The response from that member is sent back to the client, which originated the request. There is the possibility of a member failing while the LB is trying to forward a request to it. In that case, "ServiceLoadBalanceEndpoint" will try to fail-over to another available member if possible. A failed member will be suspended for a specified period.

This endpoint is also responsible for handling sticky sessions. When a request comes in, it first checks whether there is sticky session created for that client. If found, the request will be forwarded to the relevant member. Sticky sessions are identified using the value of the JSESSIONID cookie.

 

 

 

  • No labels