Perlbal - Possible via a Perlbal plugin?

Author

Possible via a Perlbal plugin?

André Cruz

2007-04-18, 7:11 am

Hello.

I'm an happy Perlbal user so I'll start by congratulating the =20
development team.

I need a certain functionality and I would like to know if it's =20
possible to do this via a plugin (if all the hooks I need are in =20
place). I need to check the backend response to each request. If the =20
response is a redirect to a specific URL I need to set a cookie to =20
establish a temporary sticky session so that for the next X mins the =20
requests from this client will end up on the same backend that issued =20=

the redirect.

The application on the backend is not under my control, btw, I just =20
need to satisfy it's requirements and I would like to continue to use =20=

Perlbal.

So there are two parts this:

1- Check the response and set the cookie if needed.
2- Check the request for the cookie and send it to the requested =20
backend if it is set.

Is this doable?

Thanks and keep up the good work.

Andr=E9 Cruz

Brad Fitzpatrick

2007-04-18, 1:11 pm

The first step should be no problem.

The second, however, isn't currently implemented (sticky sessions), but a
related feature (hashing a request URL onto a specific backend) is being
requested lately by my employer. (thus sticky sessions is likely to be
implemented as well, since it basically comes for free)

Bot both uri hashing and sticky sessions come down to the basic problem
of: what to do in subsequent requests when that old node is out of the
pool or down? What are all the tunables for this policy/timeouts/etc?

And in your case, how do requests waiting for a specific backend compete
for requests waiting for any backend? Imagine 3*(n+1) queues, n per
backend (high+normal+low priorities), then then high+normal+low priorities
for ANY backend.

If more of these questions were answered, implementation would probably
happen sooner, but so far it's been kinda a low priority both at work and
in the community, as the typical answer is "stickiness implies your webapp
is broken!". (which you clarified isn't under your control....)

Any ideas?

On Wed, 18 Apr 2007, Andr=E9 Cruz wrote:

> Hello.
>
> I'm an happy Perlbal user so I'll start by congratulating the
> development team.

>
> I need a certain functionality and I would like to know if it's
> possible to do this via a plugin (if all the hooks I need are in
> place). I need to check the backend response to each request. If the
> response is a redirect to a specific URL I need to set a cookie to
> establish a temporary sticky session so that for the next X mins the
> requests from this client will end up on the same backend that issued
> the redirect.
>
> The application on the backend is not under my control, btw, I just
> need to satisfy it's requirements and I would like to continue to use
> Perlbal.
>
> So there are two parts this:
>
> 1- Check the response and set the cookie if needed.
> 2- Check the request for the cookie and send it to the requested
> backend if it is set.
>
> Is this doable?
>
> Thanks and keep up the good work.

> Andr=E9 Cruz
>
>

André Cruz

2007-04-18, 1:11 pm

On Apr 18, 2007, at 3:44 PM, Brad Fitzpatrick wrote:

> Bot both uri hashing and sticky sessions come down to the basic =20
> problem
> of: what to do in subsequent requests when that old node is out of =20=

> the
> pool or down? What are all the tunables for this policy/timeouts/etc?
>

In my situation, if the intended backend is not available then tough =20
luck, ignore the preference and use the best available one. In the =20
applications I have here the sticky sessions are needed purely for =20
efficiency (a cache that is not replicated across all nodes).

I would like to be able to configure the sticky session trigger and =20
timeout. Some applications require sticky sessions just to do some =20
auth checks and don't need them afterwards...
A small configurable timeout to wait for the backend to come up would =20=

be nice, but not a must-have. If it's not up, what can you do?

> And in your case, how do requests waiting for a specific backend =20
> compete
> for requests waiting for any backend? Imagine 3*(n+1) queues, n per
> backend (high+normal+low priorities), then then high+normal+low =20
> priorities
> for ANY backend.
>

Well... I guess clients that specify a backend should have precedence =20=

over others with the same priority but for any backend (since some =20
kind of flow is already active), but I would be satisfied if they =20
just received the same treatment as all the other requests.. But I =20
don't prioritize requests here so I'm biased.

Hope this helps,
Andr=E9 Cruz

Eric Lambrecht

2007-04-18, 1:11 pm

Andr=E9 Cruz wrote:[vbcol=seagreen]
> On Apr 18, 2007, at 3:44 PM, Brad Fitzpatrick wrote:
>=20
em[vbcol=seagreen]
he[vbcol=seagreen]

We needed to add uri hashing to our load balancer and ended up using the=20
Cisco Content Switching Module on our switch to perform this balancing=20
for us.

My understanding is that when a node drops out, its work is balanced=20
over the remaining nodes. I have no idea how this works, nor how it=20
would continue to work if another node dropped out, but I'll look around=20
for some documentation to see how these guys pull it off.

Eric...