Defining subclusters
Subclustering improves efficient scaling by limiting session-state communication to other nodes within a subcluster.
Node indices can be configured to divide a cluster into subgroups, or subclusters, of a few nodes each. Using this configuration, each node in a subcluster shares session-state information only with other members of the subcluster. This approach requires include::partial$pf_rc_ph_loadbalancerstickysessionsrequirement.adoc[tags=pf_ph_loadBalancerStickySessionsRequirement] The advantage of this approach is that cluster throughput scales more linearly, because the creation of an additional subcluster will not degrade the performance of any other group.
The underlying cluster protocol still requires that all nodes are able to communicate with one another. The topology here is only an optimization for the runtime state-management services that support the concept of preferred nodes. Additionally, this architecture does not support OpenID Connect back-channel logout or the SAML 2.0 single logout (SLO) profile using the SOAP binding. If you need to use either of these capabilities, you must choose between sharing all nodes and designating state servers deployment strategies in directed clustering. This architecture also does not support the capability to revoke sessions after password change or reset. If you are using this capability, you are limited to the sharing all nodes and designating state servers deployment strategies. |
The following diagram illustrates the subcluster approach.
In this example, the preferred.node.indices
property of each server in the cluster lists the indices of all nodes in its subgroup (including itself). Requests are directed to all nodes but the load balancer directs user sessions to the same subcluster.
When PingFederate acts as an OAuth authorization server (AS) and the access token management instance uses a reference token data model, the resource server (RS) must send a request to PingFederate to de-reference the access token for the corresponding identity and security information. Because the OAuth clients and the RS send their requests separately, PingFederate shares reference token information among all engine nodes despite any state server or subcluster setup. |