|
/
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
|
|
|
|
|
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
|
|
|
|
|
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:
[...]
[...]
|
|
|
|
|
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
|
|
|
|
|
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:
[...]
[...]
|
|
|
|
|
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:
[...][...][...]
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
|