It's stated that Keycloak is built on top of the WildFly application server and its sub-projects like Infinispan (for caching) and Hibernate (for persistence).
Keycloak recommends to look in WildFly Documentation and High Availability Guide.
If understood correctly Standalone Clustered Configuration allows session replication or transmission of SSO contexts around the cluster.
I don't understand though if odd number of Keycloak nodes is required so that there will be quorum.
Singleton subsystem states
10.1.3. Quorum Network partitions are particularly problematic for singleton services, since they can trigger multiple singleton providers for the same service to run at the same time. To defend against this scenario, a singleton policy may define a quorum that requires a minimum number of nodes to be present before a singleton provider election can take place. A typical deployment scenario uses a quorum of N/2 + 1, where N is the anticipated cluster size. This value can be updated at runtime, and will immediately affect any active singleton services. e.g.
Is it somehow related to Keycloak and its Standalone Clustered Configuration?
Response from Keycloak mailing list:
No, Keycloak uses Infinispan for caching and Infinispan uses JGroups for clustering. JGroups doesn't need consensus.
It's stated that Keycloak is built on top of the WildFly application server and its sub-projects like Infinispan (for caching) and Hibernate (for persistence).
Keycloak recommends to look in WildFly Documentation and High Availability Guide.
If understood correctly Standalone Clustered Configuration allows session replication or transmission of SSO contexts around the cluster.
I don't understand though if odd number of Keycloak nodes is required so that there will be quorum.
No it is not strictly required. As in almost all distributed systems, having odd number of nodes helps recovering from Split Brain scenarios.