3:14 p.m.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:09 a.m.
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.
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
8:16 a.m.
Another issue with sticky sessions is that it would be difficult to implement queries
(retrieve all user sessions and client sessions), remove expired sessions, etc..
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Marek Posolda" <mposolda(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 23 September, 2014 12:29:21 PM
Subject: Re: [keycloak-dev] sticky sessions for UserSession
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
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:24 a.m.
True.
On 9/23/2014 9:16 AM, Stian Thorgersen wrote:
Another issue with sticky sessions is that it would be difficult to
implement queries (retrieve all user sessions and client sessions), remove expired
sessions, etc..
----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "Marek Posolda" <mposolda(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 23 September, 2014 12:29:21 PM
> Subject: Re: [keycloak-dev] sticky sessions for UserSession
>
> 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:24 a.m.
Failures should be a rare event and performance is more important than
session retention, IMO. Replication is an expensive luxury and is not a
requirement for failover. We just need to ensure that users can relogin
on a node failure.
On 9/23/2014 3:09 AM, Marek Posolda wrote:
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3766
days inactive
3767
days old
5 comments
3 participants
participants (3)
-
Bill Burke -
Marek Posolda -
Stian Thorgersen