5:29 a.m.
I don't like the idea of introducing a sticky session, also I'd prefer if we could
at least provide the illusion of Keycloak being stateless.
Some issues with sticky sessions:
1) Load balancer needs session cookie to make requests from browser sticky
2) Also need to make requests from clients "sticky", either by a cookie or by
having clients go to a specific url (latter means exposing internal nodes as well as load
balancer)
3) Doesn't increase availability - in that case we still need some replication
An alternative solution is to have the user session provider deal with this. I propose we
use Infinispan to provide a clustered and sharded in-memory store for user sessions. This
means that Keycloak itself doesn't store user-sessions in-memory, but instead
delegates this to Infinspan. It also means that if someone really wants to persist user
sessions they still can (using clustered relational db, or a sharded mongodb).
With that in mind the stages involved in developing clustering support would be:
1) Use JPA (or Mongo) stores for everything with no caches
2) Use Docker to easily create a cluster (multiple Keycloak instances and Apache load
balancer) for testing
3) Create a cluster testsuite
4) Enable realm cache - using jgroups to send cache invalidation messages (messages are
signed with realm key and contain no sensitive data, only id that is invalidated, so
doesn't need to be encrypted)
5) Enable user cache - same as 4, but for users
6) Infinispan User Session provider
6.1) No replication or sharding
6.2) Replicated for availability
6.3) Sharded for scalability
This would support any load balancer (where the load balancer is the only externally
visible url) and a cluster of Keycloak servers. Any Keycloak server can process any
request. In non-clustered config we can use a single in-memory Infinispan cache to
retrieve user sessions from (so there's no need to maintain a separate in-mem user
session store). For increasing availability we can have multiple Infinispan nodes that
replicates all user sessions. Finally, for increased scalability Infinispan would shard on
user-session-id.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>, keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 23 September, 2014 9:09:21 AM
Subject: Re: [keycloak-dev] sticky sessions for UserSession
I think that generally there are 2 main purposes of clustering:
a) scalability and better performance (ideally n-times better
performance with n nodes in cluster)
b) failover
With in-memory session you will achieve (a), but (b) won't be addressed.
So if you have 2 keycloak nodes and you kill node-1, then all
UserSessions on node-1 will be lost and users would need to relogin. IMO
Sticky sessions are good, but there is still need to replicate sessions
(at least to 1 additional cluster node) if you want to address failover.
Or am I just not understand correctly what you meant?
Marek
On 22.9.2014 22:14, Bill Burke wrote:
> Was thinking about clustering. Sticky sessions combined with in-memory
> only UserSessions might be best for clustering. We'll need to change
> access code processing so that it is a) signed and b) contains the
> callback URL. In looking at SAML, it jsut seems we need to have the
> notion of an HttpSession and the idea of loading this session from a
> database (or even a clustered cache) doesn't seem very feasible or
> scalable.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev