How to Configure Redis Cluster and Sentinel on RHEL 7

January 4, 2026
Linux
Comment off

How to Configure Redis Cluster and Sentinel on RHEL 7

Redis is an in-memory data structure store used as a database, cache, and message broker. For production environments requiring high availability and horizontal scalability, Redis offers two complementary mechanisms: Redis Cluster for automatic data sharding across multiple nodes, and Redis Sentinel for automatic failover of a primary-replica setup. This guide covers configuring both on RHEL 7 using yum and systemctl.

Prerequisites

RHEL 7 server(s) with root or sudo access — at least 3 hosts for a minimal Redis Cluster, or 1 primary + 2 replicas for Sentinel
Redis 3.0 or later (Redis Cluster requires 3.0+; Redis 5.0+ is recommended)
Ports 6379 (Redis) and 16379 (cluster bus) open between cluster nodes
Hostnames or IPs of all nodes available before you begin
EPEL repository enabled for Redis packages on RHEL 7

Step 1: Install Redis from EPEL

RHEL 7 does not include a current Redis version in its base repos. Enable the EPEL repository and install Redis.

sudo yum install -y epel-release
sudo yum install -y redis

Verify the installed version:

redis-server --version

Repeat this step on all nodes that will participate in the cluster or sentinel setup.

Step 2: Configure Redis Cluster Nodes

Redis Cluster requires at least 3 primary nodes. Each node needs its own redis.conf. On each node, edit /etc/redis.conf with the cluster-specific directives.

sudo vi /etc/redis.conf

Set the following options. Replace the bind address with the node’s actual IP address.

# Bind to the node's IP (do not use 127.0.0.1 for cluster nodes)
bind 192.168.1.10

# Redis port
port 6379

# Protect from accidental external access if not using auth
protected-mode no

# Enable cluster mode
cluster-enabled yes

# Cluster state file — Redis manages this automatically
cluster-config-file nodes.conf

# Milliseconds a node can be unreachable before considered failed
cluster-node-timeout 5000

# Persist data so the cluster can recover after restart
appendonly yes

Repeat on each cluster node, changing bind to each node’s respective IP address. For a 6-node cluster (3 primaries + 3 replicas), you would have identical configs on nodes at 192.168.1.10 through 192.168.1.15 with only the bind address differing.

Step 3: Start Redis on All Cluster Nodes

Enable and start the Redis service on every node before creating the cluster topology.

sudo systemctl enable redis
sudo systemctl start redis
sudo systemctl status redis

Confirm Redis is listening on the cluster bus port as well:

ss -tlnp | grep redis

You should see both port 6379 and port 16379 (6379 + 10000) in the output.

Step 4: Open Firewall Ports for Cluster Communication

sudo firewall-cmd --permanent --add-port=6379/tcp
sudo firewall-cmd --permanent --add-port=16379/tcp
sudo firewall-cmd --reload

Repeat on all cluster nodes. Redis Cluster nodes communicate with each other on the cluster bus port, so traffic on 16379 must be allowed between all participating hosts.

Step 5: Create the Redis Cluster

Use the redis-cli --cluster create command from any one node. This command automatically assigns slots and establishes the replication topology. The --cluster-replicas 1 flag means each primary gets one replica.

redis-cli --cluster create 
  192.168.1.10:6379 
  192.168.1.11:6379 
  192.168.1.12:6379 
  192.168.1.13:6379 
  192.168.1.14:6379 
  192.168.1.15:6379 
  --cluster-replicas 1

You will be prompted to accept the proposed slot assignments. Type yes to proceed. Redis divides the 16384 hash slots evenly across the 3 primary nodes (approximately 5461 slots each).

Step 6: Verify Cluster Status

Connect to any node and run the cluster info and nodes commands.

redis-cli -h 192.168.1.10 -p 6379 CLUSTER INFO

Look for cluster_state:ok and cluster_slots_assigned:16384 in the output. List all cluster nodes:

redis-cli -h 192.168.1.10 -p 6379 CLUSTER NODES

Test a write and read through the cluster (use -c for cluster mode which handles automatic slot redirection):

redis-cli -c -h 192.168.1.10 -p 6379 SET testkey "hello"
redis-cli -c -h 192.168.1.10 -p 6379 GET testkey

Step 7: Configure Redis Sentinel

Redis Sentinel provides high availability for a single-primary setup without sharding. It monitors the primary, notifies administrators of failures, and automatically promotes a replica to primary. You need at least 3 Sentinel processes for a reliable quorum.

First, configure a primary Redis node (192.168.1.20) with a standard /etc/redis.conf, and at least one replica pointing to it.

On the replica node, add to /etc/redis.conf:

replicaof 192.168.1.20 6379

On each of the 3 Sentinel hosts, create /etc/redis-sentinel.conf:

sudo tee /etc/redis-sentinel.conf <<'EOF'
# Sentinel listens on this port
port 26379

# Allow Sentinel to run in the background
daemonize yes
logfile /var/log/redis/sentinel.log
pidfile /var/run/redis/sentinel.pid

# Monitor the primary — "mymaster" is the logical name, quorum is 2
sentinel monitor mymaster 192.168.1.20 6379 2

# Milliseconds the primary must be unreachable before Sentinel acts
sentinel down-after-milliseconds mymaster 5000

# How many replicas can be reconfigured simultaneously during failover
sentinel parallel-syncs mymaster 1

# Milliseconds allowed for failover to complete
sentinel failover-timeout mymaster 10000
EOF

Step 8: Start Redis Sentinel

Start Sentinel on all 3 Sentinel hosts using the redis-sentinel binary or the redis-server binary in sentinel mode.

redis-sentinel /etc/redis-sentinel.conf

Or to run it as a systemd service, create a unit file:

sudo tee /etc/systemd/system/redis-sentinel.service <<'EOF'
[Unit]
Description=Redis Sentinel
After=network.target

[Service]
ExecStart=/usr/bin/redis-sentinel /etc/redis-sentinel.conf --supervised systemd
ExecStop=/usr/bin/redis-cli -p 26379 SHUTDOWN NOSAVE
User=redis
Group=redis
Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable redis-sentinel
sudo systemctl start redis-sentinel

Step 9: Test Sentinel Failover

Connect to Sentinel and check its view of the primary:

redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL replicas mymaster
redis-cli -p 26379 SENTINEL sentinels mymaster

To manually trigger a failover for testing:

redis-cli -p 26379 SENTINEL FAILOVER mymaster

After the failover completes, query the new primary:

redis-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster

This returns the IP and port of the currently active primary, which will now be one of the former replicas.

Conclusion

You have configured both Redis Cluster and Redis Sentinel on RHEL 7. Redis Cluster provides automatic data sharding across 3 or more primary nodes with configurable replicas, making it suitable for workloads that exceed the memory capacity of a single server. Redis Sentinel offers automatic failover for primary-replica setups where the dataset fits on one node but downtime must be minimized. Choose Cluster for scalability, Sentinel for simplicity and high availability. In production, combine both patterns with password authentication (requirepass and masterauth directives) and enable TLS for inter-node communication.

How to Configure Redis Cluster and Sentinel on RHEL 7