Connect2id server 5.0.3 introduces support for Redis as 2nd level in-memory store
Second level in-memory store with Redis / AWS ElastiCache
With this release we are introducing support for deploying the Connect2id server with Redis as a 2nd level in-memory store. You may benefit from this if you're operating an IdP or SSO service with more than 10M users.
Since its 1.0 release in 2014 the Connect2id server has utilised Infinispan to provide caching and in-memory storage (on the JVM heap) for a number of objects that an OpenID provider needs to handle, such as user sessions, sticky authorisations and client registrations. If high availability is required or a large user base needs to be serviced the way to handle that is by launching additional Connect2id server nodes, and let Infinispan replicate (or distribute) the in-memory data across them.
Such a cluster setup can work reasonably well, provided there are sufficient free resources (free JVM memory and CPU time) on each node to accommodate critical cluster topology events, such as a node failing (or being taken offline), or one or more nodes joining to respond to a sudden spike in demand. If the free JVM memory on one or more nodes is low, topology changes may cause significant cluster instability, leading to slower IdP response times. To stay away from such trouble make sure you periodically monitor the available memory on your JVMs and add new nodes preemptively. Long GC pauses can also become a problem with 16+ GB heaps, so when setting up a Connect2id cluster, choose in favour of having more nodes with less RAM, than fewer nodes but with more RAM.
The introduction of Redis as a 2nd level cache / in-memory store now make it much easier to scale a Connect2id server cluster up and down, and importantly, to do that independently from the main underlying in-memory store.
How is such a cluster set up?
Connect2id server tier -- Two or more Connect2id servers where Infinispan is configured in the lightweight invalidation mode, meaning that between themselves the server nodes only emit messages to indicate that a particular object key has been deleted or updated, so that the other nodes can clear
(invalidate) it if they cache a local copy of it. Actual data is not moved between the Connect2id server nodes.
Redis tier -- Provides the underlying (authoritative) caching and in-memory storage of objects. If a Connect2id server node does not find an object in its own cache, it will try to load it from Redis (and then the database, if the type of object is persisted).
We have provided a sample Infinispan configuration file for using Redis as a 2nd level in-memory store on AWS in the Connect2id server package:
To override the default Redis server settings set the following Java system properties:
- redisHost to point to your Redis server hostname / IP address
- redisPort to point to your Redis server port (6379)
You can also edit these in the Infinispan config XML itself.
Important: Make sure the Redis database is not shared with other apps, and that no extraneous keys exist in buckets 1 through 9!
We also tweaked the server configuration a bit to permit deployment on JBoss 7 (and possibly other versions as well).
Several components have also been updated, most notably Infinispan to v8.2.4.
To download a ZIP package of Connect2id server 5.0.3:
As WAR package only:
Get in touch Connect2id support, we'll be delighted to help out.
Supports deployment to JBoss AS 7.
Supports Redis second level Infinispan in-memory / cache store.
Supports Infinispan map / cache clustering in invalidation mode.
Adds sample infinispan-redis.xml configuration for using Infinispan in invalidation mode and Redis as shared second level in-memory store / cache.
Adds JBoss AS 7 deployment profile.
- No changes
Upgrades to Connect2id Session Store 4.0.5.
Upgrades to Connect2id Authorization Store 4.6.
Upgrades to Infinispan 8.2.4.Final.
Upgrades to Jersey JAX-RS 2.23.2.
Upgrades to UnboundID LDAP SDK 3.2.0.