Prepare for load balancing and failover
For high scale or highly available deployments, consider using a pool of PingGateway servers with nearly identical configurations. Load balance requests across the pool to handle more load. Route around any servers that become unavailable.
Manage state information
Before spreading requests across multiple servers, decide how to manage state information. PingGateway manages state information in the following ways:
- Stores state information in a context
-
By using filters that can store information in the context. Most filters depend on information in the request, response, or context, some of which is first stored by PingGateway. For a summary of filters that can populate a context, refer to Summary of contexts.
By using a handler such as the ScriptableHandler that can store state information in the context. Most handlers depend on information in the context, some of which is first stored by PingGateway.
- Retrieves state information to local memory
-
By using filters and handlers that depend on the configuration of the local file system, such as the following filters:
When a server becomes unavailable, state information held in local memory is lost. To prevent data loss when a server becomes unavailable, set up failover. Server failover should be transparent to client applications.
Prepare stateless sessions
For example configurations, refer to Encrypt and share JWT sessions.
- JwtSession
-
Manage stateless sessions though JwtSession. Session content is stored on a JWT cookie on the user agent.
So that any server can read or update a JWT cookie from any other server in the same cookie domain, encrypt JWT sessions and share keys and secret across all PingGateway configurations.
Encrypt JWT sessions. The maximum size of the JWT session cookie is 4 KBytes, as defined by the browser. If the cookie exceeds this size, PingGateway automatically splits it into multiple cookies.
- Session stickiness
-
Session stickiness helps to ensure that a client request goes to the server holding the original session data.
If data attached to a context must be stored on the server-side, configure session stickiness so that the load balancer sends all requests from the same client session to the same server.
For an example configuration, refer to Share JWT sessions between multiple instances of PingGateway.
SAML in deployments with multiple instances of PingGateway
PingGateway uses AM federation libraries to implement SAML. When PingGateway acts as a SAML service provider, some internal state information is maintained in the fedlet instead of the session cookie. In deployments that use multiple instances of PingGateway as a SAML service provider, set up sticky sessions so that requests go to the server that started the SAML interaction.
For information, refer to Session state considerations in AM’s SAML v2.0 guide.