Designating state servers
A state servers clustering deployment model improves scalabiltity by reducing communication between nodes.
You can select a few engine nodes as state servers. This deployment approach scales better than the all-nodes approach because additional nodes do not require connections to every existing node, they only require a connection between each server and each state server.
Configure this deployment by setting the preferred.node.indices of other servers in a group to those of the state servers. Configure the load balancer to isolate the state-server nodes from end-user traffic.
|
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. |
The following diagram illustrates the state-server approach.
In this example, the two state-server nodes have indices of 1 and 2. The preferred.node.indices property of the engine nodes handling requests would be preferred.node.indices=1,2.
Because the state servers are not processing transactions (based on the setup of the load balancer), the preferred.node.indices property for them is not used and can be left blank.
|
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. |