/
Use Redis with Identity Server

Use Redis with Identity Server

See System Recommendations and Supported Platforms for the supported Redis version.

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.

AnchorLinkDescription
[1]https://redis.io/Redis homepage
[2]https://redis.io/topics/quickstartRedis quick start and installation
[3]https://redis.io/topics/cluster-tutorialRedis clustering guide
[4]https://redis.io/topics/adminTopics around operating Redis
[5]https://redis.io/documentationRedis documentation

Terminology

TermDescription
Active nodeA process like a web server serving incoming requests.
Execution environmentA physical or virtual runtime environment where processes run. For example, physical servers, virtual machines, container orchestration etc.
Primary / ReplicaThe primary instance is the main source whereas replica is mirroring the primary source and waiting to take over in case of failure.
Passive nodeA 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 modelActive SSO nodesPassive SSO nodesNumber of login transactions / secAverage response time
High-Availability (active-passive)11302.5 s
High-Performance (2 active nodes)20801.5 s
The metrics are based on Ubisecure's reference environment. The test case is for performing end-user login initiated by OpenID Connect Authorization code flow and requesting UserInfo.

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