Repository navigation
Sticky Sessions for a Keycloak Cluster: Which guide is right? #8692
Replies: 8 comments 6 replies
|
I am also interested in a statement to this issue 👍 |
|
@lukaseckert Variant B is what makes more sense. We had a discussion a long time ago related to this but I can not find the thread right now. But basically, doing Variant B is much more natural to most reverse proxies and also leverages their capabilities of choosing the best LB strategy. It also avoids misconfiguration and additional overhead when looking up entries because entries should be owned by the node that created that entry. |
|
Hi @pedroigor , |
|
|
|
What if you change the cache owners to meet the amount of instances you have? Then you should be able to answer the petition from any instance. |
|
Qurious whats the performance hit you got if you decided not to set the session affinity? Is it very significant? |
|
|
|
|
That updated link is for Keycloak 17. Does the latest Keycloak docs have a section on sticky sessions? |
|
@slominskir The approach is the same. We also include this option, commented, in We can update the production guide to include: |
|
Adding something to the production guide sounds good. It appears the section on sticky sessions is missing in the latest docs, possibly because server installation is no longer a top level doc. It isn't immediately obvious what spi-sticky-session-encoder-infinispan-should-attach-route does exactly. Bonus points if the docs actually include specific proxy examples (such as haproxy) or even better point to working docker compose examples. |
|
@slominskir could you please check #16893? |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hey everyone,
I'd like to ask if someone could clarify how to correctly setup sticky sessions for a Keycloak cluster behind an HAProxy load balancer for optimal performance. While there is a nice documentation at https://www.keycloak.org/docs/latest/server_installation/index.html#sticky-sessions, this (at least to my understanding ;) seems to contradict the guidelines in the Keycloak book by @stianst and @pedroigor
(Chapter 9 / Keeping session affinity).
Variant A / keycloak.org: Stick to the node which is the Infinispan session owner
From the workflow description at keycloak.org, HAProxy might route the initial request to node1. The Keycloak instance at node1 might create a session cookie like
AUTH_SESSION_ID=123.node2, and from that point, HAProxy should route all requests to node2, because the session's Infinispan data is stored (only) on node2.That means, HAProxy must parse the special
<session-id>.<owner-node-id>syntax to read the ownerNodeId, so it can route the subsequent requests to the optimal node (here: node2).(So far I did not find a way to configure HAProxy accordingly. There is only a "prefix" but no "suffix" mode, so this results in AUTH_SESSION_IDs like
node1~123.node2which seems to be the worst-case when all requests stick to node1 but the session data is on node2)Variant B / Keycloak Book: Stick to the node which got the initial request
See https://books.google.de/books?id=WBsvEAAAQBAJ&pg=PA181&lpg=PA181
From the guide in the Keycloak book, the ownerId should be removed from the AUTH_SESSION_ID cookie by setting
shouldAttachRoute=falseon thestickySessionEncoder. At the same time, HAProxy stickyness should be configured independent from Keycloak by using a dedicated "KC_ROUTE" cookie, which is controlled by HAProxy only (cookie KC_ROUTE insert indirect nocache).Question:
Variant B makes sense to me if the session data is always stored on the initially requested node, however that seems to contradict the Keycloak.org docs, which state that the session data is stored on one of the cluster nodes based on the hash of the sessionId. Any ideas on this?
Thanks for your support and the great work on Keycloak!
All reactions