/ Zope / Apsis / Pound Mailing List / Archive / 2009 / 2009-01 / Session Affinity and Backend Determination

[ << ] [ >> ]

[ https setup problem / Elan Ruusamäe ... ] [ Request: add client IP to e500 error log message ... ]

Session Affinity and Backend Determination
justin.kinney(at)academy.com
2009-01-23 16:10:17 [ FULL ]
I am trying to configure pound to help me first determine a what backend 
to send the request to, and then to maintain affinity for that backend.

Hello everybody,

I've got 4 domino mail server clusters as back ends (8 total servers) for 
inotes, and each one of those has an authentication page that works as 
follows:

1. When the user logs in, the mail server performs a lookup to find out 
what that user's home mail server is.  It then sets a header "X-Notes" 
accordingly, which contains a value later evaluated by pound.  Note that a 
cookie called "LtpaToken" is also set, which I'm attempting to use for 
session tracking.
2. At the next request, pound directs that user to the correct mail 
server, using a HeadRequire statement.

My problem lies in using the HeadRequire to do this.  I understand that 
the header does not persist, so the next HeadRequire will not match. 
Modifying the application to keep setting that header is a possibility, 
but one that I would like to avoid.

Is there a way to configure pound to perform the HeadRequire once, and 
then use session tracking to keep the user at a backend?

My config is pasted below.

Thanks in advance,
Justin

##################################################
User    "wwwrun"
Group   "www"
LogFacility local1
LogLevel 1
Control "/tmp/sinotes.ctl"
# Timeout for Clients - Default is 10, but if you start seeing client 
timeout errors, increase this
Client 30
# Timeout for BackEnds - Default is 15, but increase or decrease as needed
TimeOut 90

# Listener for HTTP requests
ListenHTTP
        Address 10.1.100.218
        Port    81

        # Cluster A
        Service
                HeadRequire "X-Notes: .*A.*" 
 
                Session
                        Type    Cookie
                        ID      "LtpaToken"
                        TTL     300
                End
 
                # pwapdom01
                BackEnd
                        Address 10.1.254.110
                        Port 80
                        Priority 9
                End

                # pwapdom02
                BackEnd 
                        Address 10.1.254.126
                        Port 80
                        Priority 1
                End

        End
 
        # Cluster B
        Service
                HeadRequire "X-Notes: .*B.*"

                Session
                        Type    Cookie
                        ID      "LtpaToken"
                        TTL     300
                End

                # pwapdom02
                BackEnd
                        Address 10.1.254.126
                        Port 80
                        Priority 1
                End

                # pwapdom08
                BackEnd 
                        Address 10.1.254.62
                        Port 80
                        Priority 9
                End

        End

        # Cluster C
        Service 
                HeadRequire "X-Notes: .*C.*"

                Session
                        Type    Cookie
                        ID      "LtpaToken"
                        TTL     300
                End

                # pwapdom10
                BackEnd
                        Address 10.1.254.116
                        Port 80
                        Priority 9
                End
                # pwapdom11
                BackEnd
                        Address 10.1.254.120
                        Port 80
                        Priority 1
                End
        End

        # Cluster D
        Service 
                HeadRequire "X-Notes: .*D.*"

                Session
                        Type    Cookie
                        ID      "LtpaToken"
                        TTL     300
                End

                # pwtcapdom01
                BackEnd 
                        Address 10.32.0.51
                        Port 80
                End
 
                # pwapdom01 (Only if pwtcapdom01 is dead)
                Emergency
                        Address 10.1.254.110
                        Port 80
                End
        End

        # Catch-All
        Service 
                # pwapdom01
                BackEnd 
                        Address 10.1.254.110
                        Port 80
                End

                # pwapdom02
                BackEnd 
                        Address 10.1.254.126
                        Port 80
                End

                # pwapdom08
                BackEnd 
                        Address 10.1.254.62
                        Port 80
                End

                # pwapdom10
                BackEnd 
                        Address 10.1.254.116
                        Port 80
                End
                # pwapdom11
                BackEnd 
                        Address 10.1.254.120
                        Port 80
                End
        End
End
Attachments:  
text.html text/html 16395 Bytes

Re: [Pound Mailing List] Session Affinity and Backend Determination
justin.kinney(at)academy.com
2009-01-27 18:15:16 [ FULL ]
> I am trying to configure pound to help me first determine a what
backend[...]
[...]

Nobody?  Anybody with any alternatives or ideas about how they might pull 
this off?

My other line of thinking revolves around using Apache + mod_proxy (et. 
al.) to proxy a request back to one 4 pound listeners that each represent 
one of our notes clusters.  Once the request is at the proper pound 
listener, session affinity is handled using the LtpaToken cookie described 
above.  I've got proof of concept somewhat working using this method, but 
I'm not sure if it is the appropriate path to go down.  I'd be happy to 
hear from anybody who has an opinion or advice.

Any response appreciated,
Justin
Attachments:  
text.html text/html 1178 Bytes

Re: [Pound Mailing List] Session Affinity and Backend Determination
Andreas Andersson <andreas.andersson(at)gmail.com>
2009-01-27 18:35:26 [ FULL ]
I wanted to do the exact same thing but ending up just doing something
similar but not as good basing the backend on the calling ip.

The problem with pound is that all session tracking is per service, and
there is no global sessions.

Sorry, no better help from me :(

On Tue, Jan 27, 2009 at 18:15, <justin.kinney(at)academy.com> wrote:
[...]

[...]
Attachments:  
text.html text/html 1973 Bytes

RE: [Pound Mailing List] Session Affinity and Backend Determination
"Jacob Anderson" <jwa(at)beyond-ordinary.com>
2009-01-27 18:35:51 [ FULL ]
Hello Justin,

Pound already does this. Once a connection is established, that connection
can be bound using the session configuration:

  Session 
    Type IP
    TTL xxx
  End

That will keep the IP address of the client bound to the same BE. I know
this works because I use it and would not be able to have my applications
work if it didn't work.
[...]

RE: [Pound Mailing List] Session Affinity and Backend Determination
justin.kinney(at)academy.com
2009-01-27 21:54:09 [ FULL ]
> Pound already does this. Once a connection is established, that 
connection[...]
[...]
[...]
applications[...]

Sorry - after reading my previous post, I realize I wasn't too clear in my 
question.  I understand that pound session tracking can be used a number 
of different ways, and we use those other methods (IP, Cookie) in 
production environments today.

What I am looking for is a way for pound to do two things:

1. Identify which backend to send the request to by looking at a custom 
header "X-Notes".  (The only way I know of doing this is using 
"HeadRequire".
2. Send subsequent requests for the same client back to that backend.

The problem is that my backends cannot continuously add the header - they 
can only do it once.  This is being done by a login page that does a 
lookup on the userid and sets the header accordingly.  Once the user is at 
a backend, they don't get the header set any more.

Once the users are in a session with the backend, the HeadRequire will 
always fail because the header isn't being sent.  So the rule that allows 
them in for the first request is the same rule that assures they won't get 
back in if they don't have the header set.

Thanks,
Justin
Attachments:  
text.html text/html 1972 Bytes

Re: [Pound Mailing List] Session Affinity and Backend Determination
Andreas Andersson <andreas.andersson(at)gmail.com>
2009-01-27 22:05:19 [ FULL ]
This is almost exactly what I try to accomplish...

Each service will have HeadRequire to check X-notes (in my case I think it
will be a part of the url) and one backend that pairs this x-notes with one
backend server.
Subsequent calls will not match that service (no HeadRequire will match) and
there for not get the same sessions and regardless of where you store the
session pound won't find it.

Global sessions would fix all this. One suggestion is to define global
sessions outside the services and perhaps give it a name which will be
reused inside each service that should use it.

On Tue, Jan 27, 2009 at 21:54, <justin.kinney(at)academy.com> wrote:
[...]

[...]
Attachments:  
text.html text/html 2959 Bytes

Re: [Pound Mailing List] Session Affinity and Backend Determination
Doran Mori <doran(at)lmi.net>
2009-01-27 22:09:02 [ FULL ]
justin.kinney(at)academy.com
wrote:[...][...][...][...][...][...][...][...][...][...]

Give your users a cookie on your login page and use that as your custom header
to identify 
which backend to send the request to.

dmo

Re: [Pound Mailing List] Session Affinity and Backend Determination
Dave Steinberg <dave(at)redterror.net>
2009-01-27 22:13:45 [ FULL ]
> What I am looking for is a way for pound to do two things:[...]

I don't think that's possible currently - you'd need something that 
exists in every request to figure out how to lookup where to send them. 
  AFAIK pound doesn't support using one token to determine the session 
and then another to look it up later.

Regards,[...]

Re: [Pound Mailing List] Session Affinity and Backend Determination
Nathan Schmidt <nathan(at)pbwiki.com>
2009-01-27 22:55:16 [ FULL ]
We use this as the last Service entry in our conf file - it forces over to a
pre-flight server while keeping our standard domain names, sessions, and
certificates.

# Use a development server if the cookie "devmode=yesplease" is set.
Service
  HeadRequire "Cookie:.*devmode=yesplease"
  URL         ".*"
  BackEnd
    # preflight
    Address 10.0.1.37
    Port 80
  End
End

On Tue, Jan 27, 2009 at 1:13 PM, Dave Steinberg <dave(at)redterror.net>
wrote:
[...][...][...]
Attachments:  
text.html text/html 2205 Bytes

Re: [Pound Mailing List] Session Affinity and Backend Determination
justin.kinney(at)academy.com
2009-01-28 18:08:01 [ FULL ]
> We use this as the last Service entry in our conf file - it forces over 
to a[...]
[...]

Thanks for this!  It did not occur to me to use HeadRequire in this way. 
I'm testing this method now, but waiting for our dev team to modify the 
login page (similar to your pre-flight, i assume) to set a cookie instead 
of a header.

I'll let everyone know how it works.

Thanks,
Justin
Attachments:  
text.html text/html 1127 Bytes

Re: [Pound Mailing List] Session Affinity and Backend Determination
justin.kinney(at)academy.com
2009-01-28 18:09:02 [ FULL ]
> Give your users a cookie on your login page and use that as your [...]

Thanks.  This plus Nathan's suggestion may work out for us.

Thanks,
Justin
Attachments:  
text.html text/html 385 Bytes

MailBoxer