Redis Configuration
Redis can be configured in multiple ways. Cherwell recommendations are based on testing results for working optimally with a general configuration of CSM.
This section offers suggestions on how to setup an ideal CSM environment, including high availability considerations that add resiliency to a Redis database.
Settings
Redis is a simple application that requires an executable to be present and running on a given machine. On the startup.exe, Redis reads a flat .config file that contains a number of value pairs to establish the different available settings. Some settings will be specific to your environment, but others directly impact CSM.
Common Settings
All Redis instances should be configured to NOT save any data to disk by commenting out the SAVE directive in the default config file. Commenting is done by adding a # in front of it. Use the password directive in the default file to set the password so communication with Redis only happens with processes that know the password.
Optional Settings
Depending on the environment, if you want to provide high availability, you need to configure sentinels, masters, and replicas. If the Redis memory demand exceeds what is provided on a single server, configure Redis with clustering. Using a cluster configuration provides three main benefits:
- Shares large memory cache across many servers.
- Provides high availability.
- Distributes the CPU load across multiple CPUs (Redis is a single CPU process).
For more information on Redis clusters, refer to the Redis Cluster Specification.
Clustering is only supported when CSM is using specific versions of Redis. See the System Requirements for details.
Connections
Run Redis in standalone, master/replica, or cluster mode. Ideally, the minimum configuration is master/replica with sentinels.
Sentinels
A sentinel is a component of Redis that keeps an eye on both the master and the replica. It identifies when the master goes down and immediately promotes the replica as the master. Ideally the minimal configuration has two sentinels, one for master and one for replica. When the sentinel switches the master, CSM switches as well if both are listed in Connect to field on the Server Manager.
For more information on Redis sentinels, refer to Redis Sentinel Documentation.
Master/Replica
This configuration is only required if operating Redis as a high availability service. If an organization wants to horizontally scale Cherwell services, only one Redis server is required.
A master/replica connection has one copy of the master data kept in a replica. The replica and master both must be configured via the Server Manager, including both IPs and both ports with the same password. If there is a cluster of Redis, add the IP of the cluster in Host field on the Server Manager. If master and replica copy each other, one is always master and one is replica. If the master goes down, the replica does not know unless there is a sentinel. If the master goes down, it becomes the replica when it comes up again. CSM does not need to know who is master and who is replica, just the nodes for Redis in the chain.
For more information, see the Redis Replication documentation.
Backup vs. Replica
Redis, by default, is setup to backup information to disk every second, but it causes slowdowns. When Redis is installed, the configuration file has a save directive with parameters. Turn off the save to disk by deleting the directive or commenting it out. Use a master/replica configuration to provide backup functionality. There are some points to remember:
- If all of Redis goes down and the customer does not have the save to disk feature, then everyone will be logged off and can log on again when it comes up.
- If all of Redis goes down and the customer does not have save to disk feature, then there is no way to predict how the server farm will behave because it fails and IIS shut down. This is why the save directive is not recommended.