Paul,
I have planned this for a future iteration. This is actually a different
load balancing algorithm, where if a perceived load of a node is high, we
abstain from sending further requests to it until it recovers. We should be
able to plug this into the currently available LB or the new LB I'm writing.
I have also planned to dynamically fire-up new application nodes when the
load increases. I guess the term intelligent LB may be misleading and a
better term would be dynamic LB or HA LB. So indeed, we can abstract away
the idea of "which systems are available and how much load can they accept"
into the LB algorithm, which is consistent with the current design and
implementation.
<sequence name="main" onError="errorHandler">
<in>
<send>
<endpoint>
*<intelligentLoadbalance failover="true"
algorithm="intelligent"/>*
</endpoint>
</send>
<drop/>
</in>
<out>
<send/>
</out>
</sequence>
Thanks
Azeez
On Fri, Jun 13, 2008 at 3:34 AM, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> Azeez
>
> I guess I'm probably misunderstanding your proposal. I have a feeling
> that what you are proposing supports what I want, but maybe in a
> slightly different syntax and model.
>
> Maybe if I explain what I'm thinking you can map what you are
> proposing onto it and then I'll understand it better.
>
> My understanding of how intelligent load balancers communicate with
> endpoints is that there is usually some form of plugpoint that allows
> the loadbalancer to know which endpoints are available and in what
> proportion to send requests to those endpoints.
>
> So for example, the load balancer may call an API:
>
> EndpointReport getEndpoints("serviceX");
>
> where EndpointReport will be a map of endpoints and a weighting:
>
> {
> "192.168.2.1" -> 65%
> "192.168.2.2" -> 35%
> }
>
> Typically underneath this API is some kind of information gathering
> system. There are three usual systems: (1) access to the application
> running on the endpoint (so this corresponds to getting information
> directly from the Axis2 group communications), (2) running an OS-level
> agent on the system that monitors CPU, Memory and IO, or (3) pinging
> systems and seeing how fast they respond.
>
> So I guess I'm thinking that this abstraction should not assume there
> is a group communication system but simply abstract away the idea of
> "which systems are available and how much load can they accept".
>
> Paul
>
> On Thu, Jun 12, 2008 at 10:39 PM, Afkham Azeez <[EMAIL PROTECTED]> wrote:
> > This is not about assuming that Axis2 nodes are going to be load
> balanced.
> > The clustering/group mgt framework underlying Synapse is based on Axis2.
> > There is no group comm facility available at the Synapse layer. I've
> > designed the Axis2 clustering implementation such that it can run either
> in
> > application or load balancer modes. In the load balancer mode, it simply
> > informs Synapse about the changes in the application group memebership.
> So
> > the given axis2.xml file shows how Synapse needs to be configured to be
> > deployed as a clustered load balancer, managing a set of application
> nodes
> > which belong to the application domain. Of course, we may have .Net nodes
> in
> > this application domain. However, the group communications protocol at
> the
> > .Net cluster and that used by Synapse need to be interoperable since the
> > load balancer discovers the application members using the group
> > communication service.
> >
> > Azeez
> >
> >
> > On Thu, Jun 12, 2008 at 5:44 PM, Paul Fremantle <[EMAIL PROTECTED]>
> wrote:
> >>
> >> I guess what I mean is - suppose its not Axis2 that is being load
> >> balanced. Can we make a plug-point/API where Synapse gets information
> >> on the status of the cluster. Then we could also load-balance a .NET
> >> cluster by writing a plug-in that provides that information.
> >>
> >> So rather than configuring this in the axis2.xml, we could have a
> >> parameter in the Synapse config:
> >>
> >> <endpoint>
> >> <intelligentLoadbalance
> >> helper="org.apache.axis2.cluster.LoadBalanceInformationHelper"/>
> >> </endpoint>
> >>
> >> or
> >>
> >> <endpoint>
> >> <intelligentLoadbalance
> >>
> >>
> helper="org.apache.synapse.extensions.dotNetLoadBalanceInformationHelper"/>
> >> </endpoint>
> >>
> >> Paul
> >> On Thu, Jun 12, 2008 at 4:52 AM, Afkham Azeez <[EMAIL PROTECTED]> wrote:
> >> >
> >> >
> >> > On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <[EMAIL PROTECTED]>
> >> > 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 <[EMAIL PROTECTED]>
> >> >> 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
> >> >> [EMAIL PROTECTED]
> >> >>
> >> >> "Oxygenating the Web Service Platform", www.wso2.com
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > 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
> >> [EMAIL PROTECTED]
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> >
> > --
> > 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
> [EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Thanks
Afkham Azeez
http://afkham.org
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
