Use Redis with Identity Server
Introduction
From redis.io
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.
This article and related sub-articles cover the topic of using Redis as a session storage for Ubisecure Identity Server, namely Ubisecure SSO as Ubisecure CustomerID does not use Redis at the moment. This document is relevant when planning a high-performance deployment of Ubisecure Identity Server.
For configuration and installation, please refer to
Deployment models
Ubisecure Identity Server can be deployed using three different models
- Single node
- High Availability
- High Performance
This article relates to the High Performance deployment where Redis is included.
References and links
Anchor | Link | Description |
---|---|---|
[1] | https://redis.io/ | Redis homepage |
[2] | https://redis.io/topics/quickstart | Redis quick start and installation |
[3] | https://redis.io/topics/cluster-tutorial | Redis clustering guide |
[4] | https://redis.io/topics/admin | Topics around operating Redis |
[5] | https://redis.io/documentation | Redis documentation |
Terminology
Term | Description |
---|---|
Active node | A process like a web server serving incoming requests. |
Execution environment | A physical or virtual runtime environment where processes run. For example, physical servers, virtual machines, container orchestration etc. |
Primary / Replica | The primary instance is the main source whereas replica is mirroring the primary source and waiting to take over in case of failure. |
Passive node | A process like a web server that is ready to server incoming requests but is not actively doing it i.e. is in standby mode. |
Addressing linear scalability with Redis
As mentioned, Ubisecure Identity Server can be deployed to high-availability or high-performance environments. When the anticipated maximum load of incoming authentication requests (logins) will exceed the advised capacity of a High-Availability environment then a High-Performance deployment model should be considered.
Currently the rough estimation of transactions per deployment type is as follows
Deployment model | Active SSO nodes | Passive SSO nodes | Number of login transactions / sec | Average response time |
---|---|---|---|---|
High-Availability (active-passive) | 1 | 1 | 30 | 2.5 s |
High-Performance (2 active nodes) | 2 | 0 | 80 | 1.5 s |
High Availability deployment is meant for systems where failure of a component does not cause a service break. High Performance deployment model guarantees higher rate of login transactions as frequent write-intensive operations are performed on Redis instead of Ubilogin Directory. In this deployment model, Ubisecure SSO can serve requests using multiple instances, each being in active state.
Failure tolerance
Replica election process
In a multi-node Redis deployment, failure tolerance is achieved through multi-master / multi-replica deployment where replicas take over primary nodes when those go down.
The replica election process is roughly as follows
- A replica election starts when a primary node is in failed state.
- A replica whose primary node is down starts the election.
- In case of multi-replica setup, any of the replicas can start the election.
- Primary nodes participate to the election and vote for a replica to be promoted as primary.
- When a specific replica receives votes from majority of primary nodes it wins the election.
Number of primary nodes in a cluster
Note that it is essential that the majority of primary nodes are alive in order to the cluster to be considered healthy and capable of performing replica election. Therefore the suggested numb