synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Afkham Azeez" <afk...@gmail.com>
Subject Re: Intelligent Synapse Load Balancer
Date Thu, 12 Jun 2008 06:31:35 GMT
This can be done. I will send a patch once I implement this.

Thanks
Azeez

On Thu, Jun 12, 2008 at 11:18 AM, Ruwan Linton <ruwan.linton@gmail.com>
wrote:

> Azeez,
>
> This seems cool, and this will be a good addition to synapse.
>
> I remember there was a user request for this kind of a load balance
> scenario some time back.
> One small suggestion; it will be good to have the same implemented as non
> intelligent LB :-)
>
> I mean you can specify the server host names (ip address and ports) in the
> load balancer configuration (they will not be automatically discovered) and
> synapse load balances any request comes to the it on round robin to the
> specified servers. This is same as what you have done but just without the
> intelligence of the servers (you have to specify them).
>
> A use case for this is sometime one may want to direct messages only to a
> set of servers but not to all in the cluster, or when there is no cluster
> (just a few servers which provides the same service).
>
> Thanks,
> Ruwan
>
>
> On Thu, Jun 12, 2008 at 11:02 AM, Afkham Azeez <afkham@gmail.com> wrote:
>
>>       I also need to mention that the membership scheme, load balancer
>> group and application group can be specified in the cluster configuration
>> section of the axis2.xml file. The relevant section in the axis2.xml is
>> hsown below:
>>
>>
>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>       <!--
>>            The membership scheme used in this setup. The only values
>> supported at the moment are
>>            "multicast" and "wka"
>>
>>            1. multicast - membership is automatically discovered using
>> multicasting
>>            2. wka - Well-Known Address based multicasting. Membership is
>> discovered with the help
>>                     of one or more nodes running at a Well-Known Address.
>> New members joining a
>>                     cluster will first connect to a well-known node,
>> register with the well-known node
>>                     and get the membership list from it. When new members
>> join, one of the well-known
>>                     nodes will notify the others in the group. When a
>> member leaves the cluster or
>>                     is deemed to have left the cluster, it will be
>> detected by the Group Membership
>>                     Service (GMS) using a TCP ping mechanism.
>>         -->
>>         <parameter name="membershipScheme">multicast</parameter>
>>
>>        <!--
>>          The clustering domain/group. Nodes in the same group will belong
>> to the same multicast
>>          domain. There will not be interference between nodes in different
>> groups.
>>         -->
>>         <parameter name="domain">apache.axis2.domain</parameter>
>>
>>         <!--
>>          Indicates the mode in which this member is running. Valid values
>> are "application" and
>>          "loadBalance"
>>
>>          application - This member hosts end user applications
>>          loadBalance - This member is a part of the load balancer cluster
>>         -->
>>         <parameter name="mode">application</parameter>
>>
>>         <!--
>>         This is the even handler which will be notified in the case of
>> load balancing events occurring.
>>         This class has to be an implementation of
>> org.apache.axis2.clustering.LoadBalanceEventHandler
>>
>>         This entry is only valid if the "mode" parameter is set to
>> loadBalance
>>         -->
>>         <parameter name="loadBalanceEventHandler">
>>             org.apache.synapse.core.axis2.SynapseLoadBalanceEventHandler
>>         </parameter>
>>
>>         <!--
>>         This parameter is only valid when the "mode" parameter is set to
>> application. This indicates
>>         the domain in which the the applications being load balanced are
>> deployed.
>>         -->
>>         <parameter
>> name="applicationDomain">apache.axis2.application.domain</parameter>
>>
>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>> Session affinity and failover will also be provided with this Intelligent
>> Load Balancer implementation.
>>
>> Thanks
>> Azeez
>>
>>
>> On Thu, Jun 12, 2008 at 9:22 AM, Afkham Azeez <afkham@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pzfreo@gmail.com>
>>> wrote:
>>>
>>>> Azeez
>>>>
>>>> First thoughts are this is *very* cool.
>>>>
>>>> My second thought is that its a little too "hard coded". It would be
>>>> nice to allow plugging in different group/cluster discovery
>>>> mechanisms.
>>>>
>>>
>>> Can you further elaborate on what you meant by  the group discovery
>>> mechanism being hard-coded? The underlying Axis2 based clustering
>>> implementation now supports dynamic, static & well-known address (hybrid)
>>> group discovery, this will be automatically available. See
>>> http://afkham.org/2008/05/group-membership-management-schemes.html.
>>> Also, the we can plug-in a different implementation based on a different
>>> group communication framework.
>>>
>>> Azeez
>>>
>>>
>>>
>>>> Paul
>>>>
>>>> On Wed, Jun 11, 2008 at 12:47 PM, Afkham Azeez <afkham@gmail.com>
>>>> wrote:
>>>> > Hi Folks,
>>>> > There are some limitations in the current load balancer. e.g. if we
>>>> have 2
>>>> > identical services in 2 different worker nodes, which are fronted by
a
>>>> > synapse load balancer instance. In such a case, we need to provide 4
>>>> > endpoints in the synapse.xml file. As can be seen, this is not a very
>>>> > scalable solution. Hence, I'm implementing an Intelligent load
>>>> balancing
>>>> > mechanism where the application members are discovered at runtime, and
>>>> the
>>>> > endpoint do not need to be statically specified in the synapse.xml
>>>> file. So
>>>> > the synapse.xml file will simply look like this:
>>>> >
>>>> > <definitions xmlns="http://ws.apache.org/ns/synapse">
>>>> >     <sequence name="main" onError="errorHandler">
>>>> >         <in>
>>>> >             <send>
>>>> >                 <endpoint>
>>>> >                     <intelligentLoadbalance/>
>>>> >                 </endpoint>
>>>> >             </send>
>>>> >             <drop/>
>>>> >         </in>
>>>> >         <out>
>>>> >             <send/>
>>>> >         </out>
>>>> >     </sequence>
>>>> >
>>>> >     <sequence name="errorHandler">
>>>> >         <makefault>
>>>> >             <code value="tns:Receiver"
>>>> > xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/>
>>>> >             <reason value="COULDN'T SEND THE MESSAGE TO THE SERVER."/>
>>>> >         </makefault>
>>>> >         <header name="To" action="remove"/>
>>>> >         <property name="RESPONSE" value="true"/>
>>>> >         <send/>
>>>> >     </sequence>
>>>> > </definitions>
>>>> >
>>>> > Currently, the application endpoints are calculated by replacing the
>>>> IP and
>>>> > port of the incoming request with that of the member to which this
>>>> request
>>>> > will be forwarded to. I have only tested with HTTP/S for the moment.
>>>> More
>>>> > details about the design can be found here:
>>>> > http://afkham.org/2008/06/fault-resilient-dynamic-load-balancing.html
>>>> >
>>>> > Please provide your valuable feedback on this approach.
>>>> >
>>>> > --
>>>> > Thanks
>>>> > Afkham Azeez
>>>> >
>>>> > http://afkham.org
>>>> > http://www.wso2.org
>>>> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>>>>
>>>>
>>>>
>>>> --
>>>> Paul Fremantle
>>>> Co-Founder and CTO, WSO2
>>>> Apache Synapse PMC Chair
>>>> OASIS WS-RX TC Co-chair
>>>>
>>>> blog: http://pzf.fremantle.org
>>>> paul@wso2.com
>>>>
>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks
>>> Afkham Azeez
>>>
>>> http://afkham.org
>>> http://www.wso2.org
>>> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>>>
>>
>>
>>
>> --
>> Thanks
>> Afkham Azeez
>>
>> http://afkham.org
>> http://www.wso2.org
>> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>>
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"




-- 
Thanks
Afkham Azeez

http://afkham.org
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760

Mime
View raw message