How To Optimize Cache Flush Operations Between Identity Servers and Access Servers
Last updated on SEPTEMBER 21, 2016
Applies to:COREid Access - Version: 10.1.4.2 to 10.1.4.3
This problem can occur on any platform.
In a typical production environment there could be one or more Identity Servers configured to interact with one or more Access Servers. Let’s consider a setup, which has 4 Identity Servers and 4 Access Servers. The Access Servers interact with clients like WebGates, AccessGates, CacheFlush AccessGates. In such a setup, the Access Server is automatically informed of changes in the Identity System. This is done by configuring the Identity Server to notify the Access Server of each change to user and group information. The Access Server caches are then automatically flushed and replaced with the latest information.
Using the setup above as an example, the Access Manager SDK of each of the 4 Identity Servers is configured to communicate with all 4 Access Servers. For the Access Manager SDK's to be used for cache flush by the Identity Servers, all 4 Access Servers have been configured as primary. The limit for Max Connections is set to 2, which means, at any given time only 2 of the Access Servers will be used for load balancing. This is shown in the diagram below, here OIS1 to OIS4 are Identity Servers and AAA1 to AAA4 are Access Servers :
This setup, with multiple Access Servers that use a secure communication, mode could turn out to be a bottleneck in the system.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms