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]
