Repository navigation
Replies: 7 comments 5 replies
|
This is now available as preview as part of Keycloak 26.7 which was released earlier this week. I've updated the description above. Please try it out and provide your feedback. |
|
Maybe I'm not seeing all parts of the picture, as I'm rather new to Keycloak, but I'm wondering: I am running a non-geo-redundant Keycloak Setup backed by a Galera Cluster, using the built-in Infinispan and EDIT: this quote from the blog post might give some input to my question:
Cheers |
|
In the stateless mode, the embedded caches for the realm and authorization data will make Keycloak a lot faster when processing requests. Once you cache things, you'll need to invalidate the caches once data chances. In stateless mode, we still would use the JGroups and the clustering to propagate the invalidations within a cluster, and would use the extra table in the database to notify other clusters of invalidations. But we're not touching any neighbor nodes of a cluster when processing any login or token refresh in stateless mode. You can use the stateless mode and have a multiple clusters-of-one, but that would have the trade-off of slower updates to realm data as the propagation via the database is rather slow (although you can make the polling interval of 100ms smaller to be 10ms). Note that you pay this penalty only when you spin up multiple clusters. If there is only a single cluster, KC will notice that and will not need to wait for any other clusters to process invalidations. With all that: I'd argue you should keep a single cluster (either stateless or non-stateless), and keep the Infinispan/JGroups connection between the nodes. |
|
There is now a blog post Multi-Cluster v2 and Stateless Mode that hopes to provide some more insights. We also touched on stateless briefly in today's Keycloak Hour of Code. |
|
I'm currently in the process of building a (actually two) keycloak cluster distributed over multiple sites. I am slightly puzzled by the behaviour I encounter. Here is my setup: Keycloak Version: 26.7.1 The keycloak containers are build to communicate with the support systems on their site respectively. Here is the behaviour I don't quite understand: Best; |
|
Hi @KaiLaeger, the behavior you described is not intended. We expect the changes to be visible in all clusters after the operation completes.
Can you clarify what you did here? You should set
The change should be visible without clearing caches manually. Did you check that the table is being populated when you update a client? Can you double-check your logs for warnings? |
The cluster with the stateless feature installed and the
The interesting part is, that the behaviour is consistent, whether I install the |
|
@KaiLaeger - I've created #51855 to track this one. Let's discuss there on how to reproduce it. |
|
@KaiLaeger identified a mis-configuration (runtime parameter for the cluster name was missing), so I consider this resolved. |
|
In the main branch, we today switched the feature stateless and with that multi-cluster v2 to a supported feature. As the next Keycloak is due on Sep 30, these are the last days to try out our nightly release and report bugs. Thanks! |
|
This is now fully supported in 26.8: https://www.keycloak.org/high-availability/multi-cluster-v2/introduction |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
As part of #49469 and the previous discussion in #48573, the Keycloak 26.7 has the preview feature
stateless.This discussion thread should help to collect feedback to eventually graduate the feature to
supported. Follow #50642 for the progress.The docs as "multi-site deployment (v2)" is available in the 26.7 docs and nightly docs.
See Concepts for multi-cluster deployments (v2) on how this is implemented, or the blog post Multi-Cluster v2 and Stateless Mode for an overview.
All reactions