Sessions in a load balanced setup

Has anyone here implemented sessions in a load balanced environment using
database storage as a custom session handler? I'd be interested to hear
about your experiences. Upsides, downsides, bugs, troubles, security, etc.

Thanks,
Balazs

Balazs Wellisch wrote:

> Has anyone here implemented sessions in a load balanced environment using
> database storage as a custom session handler? I'd be interested to hear
> about your experiences. Upsides, downsides, bugs, troubles, security, etc.
>
> Thanks,
> Balazs

Hi,

Yes, I did, but not with loadbalancing.
The loadbalancingpart is however irrelevant if you use a database for
sessionstorage, since every session will contact the same database that
stores the sessions.
(If you plan to use more databases for sessionstorage, I give up. :P)

A good place to start is at ZEND:
http://www.zend.com/zend/spotlight/c...lery-wade8.php

That page contains a good example, but without sessionlocking.
I wrote my own that does implement sessionlocking. It is not tested 100%,
but seems to work great so far. If you are interested I'll publish it on
the net, but just start with zend. :-)

Regards,
Erwin Moller

> The loadbalancingpart is however irrelevant if you use a database for
> sessionstorage, since every session will contact the same database that
> stores the sessions.
> (If you plan to use more databases for sessionstorage, I give up. :P)

Yeah, the obvious solution is to store all the session information in a
single database. But that would limit the failover capability of the system.
I was thinking about setting up each box with its own copy of the database
and replicate the data between each one. However, I don't think this is a
feasible solution since session info changes all the time and I can't have
the dbs continuously replicate themselves all the time. I suppose I could
use sticky sessions, but I was wondering if there was a better solution out
there.

> A good place to start is at ZEND:
> http://www.zend.com/zend/spotlight/c...lery-wade8.php
>

Yes, I looked at Zend and I'm considering investing in their technology.

> That page contains a good example, but without sessionlocking.
> I wrote my own that does implement sessionlocking. It is not tested 100%,
> but seems to work great so far. If you are interested I'll publish it on
> the net, but just start with zend. :-)
>

I'm definitly interested and I'm sure others would benefit from your work as
well. Please let us know if you do decide to publish it!

Thanks,
Balazs

Balazs Wellisch wrote:
>> The loadbalancingpart is however irrelevant if you use a database for
>> sessionstorage, since every session will contact the same database that
>> stores the sessions.
>> (If you plan to use more databases for sessionstorage, I give up. :P)
>
> Yeah, the obvious solution is to store all the session information in a
> single database. But that would limit the failover capability of the system.
> I was thinking about setting up each box with its own copy of the database
> and replicate the data between each one. However, I don't think this is a
> feasible solution since session info changes all the time and I can't have
> the dbs continuously replicate themselves all the time. I suppose I could
> use sticky sessions, but I was wondering if there was a better solution out
> there.

There are a number of database technologies that will allow you to set
up replication even in high transaction environments. Oracle's RAS for
example.

Another option is to model the sessions through a persistence object
that uses a database as a backing model. . (Think queries answered from
the persistence object, writes go all the way through to the database,
missing queries are answered from database)

-david-

> There are a number of database technologies that will allow you to set
> up replication even in high transaction environments. Oracle's RAS for
> example.

Sorry, I guess I should've mentioned we have to use MySQL.

> Another option is to model the sessions through a persistence object that
> uses a database as a backing model. . (Think queries answered from the
> persistence object, writes go all the way through to the database, missing
> queries are answered from database)
>
That's a promissing idea. But I still don't see how that will help when a
session jumps from one server to another. Some mechanisim must ensure that
the entire session, along with whatever variables that session contains, is
current on each server. So, if a session gets created on server A and then
it jumps to server B it would have to already exist there. Otherwise the
user could have their session reset a number of times during their visit.
Replication is the only tool I know of that can accomplish this. Any
thoughts?

Balazs

Following on from Balazs Wellisch's message. . .
>Yeah, the obvious solution is to store all the session information in a
>single database. But that would limit the failover capability of the system.
>I was thinking about setting up each box with its own copy of the database
>and replicate the data between each one. However, I don't think this is a
>feasible solution since session info changes all the time and I can't have
>the dbs continuously replicate themselves all the time. I suppose I could
>use sticky sessions, but I was wondering if there was a better solution out
>there.

[The first time I've ever considered this issue so don't take it as
tried-n-tested]

Surely /each box/ doesn't need /its own/ database. If the objective is
to allow some failure to be brushed-off then two databases with
replication should do the trick when you need both DBs to be u/s before
the system fails. Also you would operate normally on a single DB with
the other in standby - as you'd be operating presumably with your main
DB.

Q: What happens if I log into your site twice from my Tabbed browser.
Might I operate as the same session but hitting different servers?[1]
If so what exploit could I use to load a trolley on both screens, buy on
one and decide not to buy on the other and have the cancel overwrite the
buy but not before the goods were authorised for dispatch. [Not a 'you
mustn't do it!, but a GLB-ism]

[1] Even if by hacking the browser (but more likely by cutting and
pasting ?SID=123456 from one tab to the other) - could be worth a lot of
money.


--
PETER FOX Not the same since the icecream business was liquidated
peterfox@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

Balazs Wellisch wrote:
>> There are a number of database technologies that will allow you to set
>> up replication even in high transaction environments. Oracle's RAS for
>> example.
>
> Sorry, I guess I should've mentioned we have to use MySQL.

Oracle RAS was an example. There may be an equivalent for MySQL.
(probably a commercial product...)

>> Another option is to model the sessions through a persistence object that
>> uses a database as a backing model. . (Think queries answered from the
>> persistence object, writes go all the way through to the database, missing
>> queries are answered from database)
>>
> That's a promissing idea. But I still don't see how that will help when a
> session jumps from one server to another. Some mechanisim must ensure that
> the entire session, along with whatever variables that session contains, is
> current on each server. So, if a session gets created on server A and then
> it jumps to server B it would have to already exist there. Otherwise the
> user could have their session reset a number of times during their visit.
> Replication is the only tool I know of that can accomplish this. Any
> thoughts?
>
> Balazs
Let me break it down.
1. There is one database which is replicated across two instances each
on its own server (i.e. fault tolerance for database and database
servers) The database access object has one access method which
understands which database is primary and which is secondary or the
database handles this for you. Some schemes will also alternate queries
between the two instances.
2. Each web service is on its own server and instantiates a persistence
object which talks to the database.
3. As a user session progresses, each new session value is stored in the
local persistence object (i.e. the one on the server that the browser is
currently talking to) *and* the value is also written through to the
database. This used to be called 'write-through caching'.
4. If the user requests session information which is already in the
persistence object, it is simply handed back.
5. If the user requests session information which is not already in the
persistence object, the database is queried for the [session:tag:value]
which is then stored in the local persistence object.
6. The only place this gets tricky is if you need what used to be known
as an 'atomic cache invalidate' (i.e. you want to guarantee the value of
a session variable across all persistence objects or, in other words,
force all persistence objects to refresh their local copies of the
session data from the database). If you need this, you will have to work
out some sort of intra-persistence object protocol (via the database
most likely but the network also works) to indicate that a
[session:tag:value] tuple should be refreshed from the database even
though it is in the local persistence store.

Clearer?
-david-

> Oracle RAS was an example. There may be an equivalent for MySQL. (probably
> a commercial product...)

Yes, I guess my next step is to find out what MySQL has to offer in this
regrad.

> 1. There is one database which is replicated across two instances each on
> its own server (i.e. fault tolerance for database and database servers)
> The database access object has one access method which understands which
> database is primary and which is secondary or the database handles this
> for you. Some schemes will also alternate queries between the two
> instances.
> 2. Each web service is on its own server and instantiates a persistence
> object which talks to the database.
> 3. As a user session progresses, each new session value is stored in the
> local persistence object (i.e. the one on the server that the browser is
> currently talking to) *and* the value is also written through to the
> database. This used to be called 'write-through caching'.
> 4. If the user requests session information which is already in the
> persistence object, it is simply handed back.
> 5. If the user requests session information which is not already in the
> persistence object, the database is queried for the [session:tag:value]
> which is then stored in the local persistence object.
> 6. The only place this gets tricky is if you need what used to be known as
> an 'atomic cache invalidate' (i.e. you want to guarantee the value of a
> session variable across all persistence objects or, in other words, force
> all persistence objects to refresh their local copies of the session data
> from the database). If you need this, you will have to work out some sort
> of intra-persistence object protocol (via the database most likely but the
> network also works) to indicate that a [session:tag:value] tuple should be
> refreshed from the database even though it is in the local persistence
> store.
>
> Clearer?
> -david-

I'm with you. Thank you for the advice!

Balazs

> Surely /each box/ doesn't need /its own/ database. If the objective is to
> allow some failure to be brushed-off then two databases with replication
> should do the trick when you need both DBs to be u/s before the system
> fails. Also you would operate normally on a single DB with the other in
> standby - as you'd be operating presumably with your main DB.

That is an option. However, I was thinking that from a maintenance
standpoint it would be easier to clone a system completely. That way I would
have a bunch of inexpensive, hot pluggable machines. This would give me
infinite scalability for a small initial investment and minimal
configuration to deal with as the number of systems increases. The database
is not going to be huge. Otherwise, you're right, it would probably make
more sense to go with your suggested setup of two separate databases.

> Q: What happens if I log into your site twice from my Tabbed browser.
> Might I operate as the same session but hitting different servers?[1] If
> so what exploit could I use to load a trolley on both screens, buy on one
> and decide not to buy on the other and have the cancel overwrite the buy
> but not before the goods were authorised for dispatch. [Not a 'you mustn't
> do it!, but a GLB-ism]
>
> [1] Even if by hacking the browser (but more likely by cutting and pasting
> ?SID=123456 from one tab to the other) - could be worth a lot of money.

This is more of an issue of security that I would have to deal with no
matter what. I think with URL based session ids turned off, session finger
prints and other security measures this problem can be eliminated.

Thanks for your advice.
Balazs