Linux VPS Redis Cluster Setup Tutorial: Complete High Availability Configuration with Sentinel and Sharding for 2026

Your application scales. User sessions pile up. Database queries slow down. You need Redis—but a single Redis instance becomes your weakest link.

Redis cluster setup solves this problem by distributing data across multiple nodes while maintaining high availability. This tutorial walks you through configuring a production-ready Redis cluster on Linux VPS with automatic failover, data sharding, and monitoring.

Understanding Redis Cluster Architecture

Redis cluster differs from basic master-slave replication. Instead of one master handling all writes, the cluster splits your dataset across multiple master nodes.

Each master has replicas for failover protection. The cluster uses consistent hashing to distribute keys.

Redis calculates a hash slot (0-16383) for each key and assigns it to a specific master node. When a master fails, its replica automatically promotes itself.

This architecture handles both horizontal scaling and high availability. You can add nodes to increase capacity or lose nodes without downtime.

Prerequisites and Server Requirements

You'll need at least three Linux VPS instances for a minimal production cluster. Redis requires an odd number of nodes to prevent split-brain scenarios during failover votes.

Each server should run Ubuntu 24.04, AlmaLinux 9, or Rocky Linux 9. Provision at least 2GB RAM and 20GB disk space per server.

Install Redis 7.2 or newer for the latest cluster features.

For hosting providers like HostMyCode VPS, ensure your instances are in the same data center or region. This minimizes network latency between cluster nodes.

Installing and Configuring Redis on Each Node

Start by installing Redis on all cluster nodes. On Ubuntu:

sudo apt update
sudo apt install redis-server -y
sudo systemctl enable redis-server

For AlmaLinux or Rocky Linux:

sudo dnf install epel-release -y
sudo dnf install redis -y
sudo systemctl enable redis

Configure each Redis instance for cluster mode. Edit /etc/redis/redis.conf:

bind 0.0.0.0
port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 15000
appendonly yes
protected-mode no

Each node needs a unique port. Use 7000, 7001, 7002 for your three masters.

Set different ports if running multiple Redis instances per server. Restart Redis on each node:

sudo systemctl restart redis-server

Creating the Redis Cluster

With Redis running on all nodes, create the cluster. From any node, run:

redis-cli --cluster create 10.0.1.10:7000 10.0.1.11:7001 10.0.1.12:7002 --cluster-replicas 0

Replace the IP addresses with your actual server IPs. The --cluster-replicas 0 flag creates a cluster without automatic replicas initially.

Redis will show you the proposed configuration and ask for confirmation. Type yes to proceed.

The cluster creation takes 30-60 seconds. Verify cluster status:

redis-cli -c -h 10.0.1.10 -p 7000 cluster nodes

You should see three master nodes, each responsible for different hash slots.

Adding Replica Nodes for High Availability

A cluster without replicas can't survive node failures. Add replica nodes to each master for automatic failover.

Install Redis on three additional servers using the same configuration. Use ports 7003, 7004, 7005 for the replicas.

Add each replica to the cluster:

redis-cli --cluster add-node 10.0.1.13:7003 10.0.1.10:7000 --cluster-slave
redis-cli --cluster add-node 10.0.1.14:7004 10.0.1.11:7001 --cluster-slave
redis-cli --cluster add-node 10.0.1.15:7005 10.0.1.12:7002 --cluster-slave

Each replica automatically discovers which master to replicate. The cluster balances load and handles assignments automatically.

Check the updated cluster configuration:

redis-cli -c -h 10.0.1.10 -p 7000 cluster info

The output should show cluster_known_nodes:6 and cluster_state:ok.

Testing Cluster Failover and Data Distribution

Test data distribution across nodes. Connect to any cluster node with the -c flag for cluster mode:

redis-cli -c -h 10.0.1.10 -p 7000

Set several keys and watch Redis redirect to different nodes:

SET user:1001 "john"
SET user:1002 "jane"
SET session:abc123 "active"
GET user:1001

Each key gets stored on a different master based on its hash slot. The client automatically follows redirections.

Test failover by stopping a master node:

sudo systemctl stop redis-server

Within 15 seconds (the configured timeout), the replica should promote itself to master. Check cluster status to confirm the failover completed successfully.

Optimizing Performance

Tune Redis memory usage for your workload. Edit the configuration on each node:

maxmemory 1gb
maxmemory-policy allkeys-lru
tcp-keepalive 300
timeout 300

Enable RDB snapshots for data persistence:

save 900 1
save 300 10
save 60 10000

For write-heavy workloads, adjust the AOF (Append Only File) settings:

appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Monitor cluster performance with:

redis-cli -c -h 10.0.1.10 -p 7000 --latency-history -i 1

This shows real-time latency measurements. Values under 1ms indicate healthy performance.

Implementing Redis Sentinel for Enhanced Monitoring

While Redis cluster handles basic failover, Redis Sentinel provides advanced monitoring and notification features.

Create a Sentinel configuration file /etc/redis/sentinel.conf:

port 26379
sentinel monitor mymaster 10.0.1.10 7000 2
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 10000

Start Sentinel on each server:

redis-sentinel /etc/redis/sentinel.conf

Sentinel monitors your cluster masters and can trigger external scripts when failovers occur. This enables automated alerts and recovery procedures.

For advanced monitoring and alerting, HostMyCode managed VPS includes pre-configured monitoring. It integrates with Redis Sentinel automatically.

Scaling the Cluster with Hash Slot Rebalancing

Add more nodes as your data grows. Adding a new master requires redistributing hash slots across all masters.

Install Redis on new servers with cluster configuration. Add the new node:

redis-cli --cluster add-node 10.0.1.16:7006 10.0.1.10:7000

Rebalance hash slots to include the new master:

redis-cli --cluster rebalance 10.0.1.10:7000 --cluster-use-empty-masters

This process moves hash slots between masters while maintaining data availability. The rebalancing can take several minutes depending on your dataset size.

Add a replica for the new master:

redis-cli --cluster add-node 10.0.1.17:7007 10.0.1.16:7006 --cluster-slave

Cluster Security and Access Control

Secure your cluster with authentication and network restrictions. Enable AUTH on all nodes:

requirepass your-strong-password
masterauth your-strong-password

Configure firewall rules to restrict Redis ports to cluster nodes only:

sudo ufw allow from 10.0.1.10 to any port 7000
sudo ufw allow from 10.0.1.11 to any port 7000
sudo ufw allow from 10.0.1.12 to any port 7000

Use Redis ACLs for fine-grained access control:

ACL SETUSER app-user on >app-password ~* +@all -@dangerous

This creates a user with read/write access but blocks dangerous commands like FLUSHALL.

Check out our guide on VPS security hardening checklist for comprehensive server security.

Monitoring and Troubleshooting Common Issues

Monitor cluster health with these key commands:

redis-cli -c cluster nodes  # Shows all nodes and their status
redis-cli -c cluster info   # Overall cluster health
redis-cli -c info memory    # Memory usage per node

Common issues and solutions:

Cluster state fail: Usually indicates network connectivity problems between nodes. Check firewall rules and network latency.

Hash slot conflicts: Occur when nodes disagree about slot assignments. Fix with:

redis-cli --cluster fix 10.0.1.10:7000

Memory pressure: Monitor with INFO memory. Scale horizontally by adding nodes or vertically by increasing RAM.

Set up log monitoring to catch issues early:

tail -f /var/log/redis/redis-server.log | grep -E "FAIL|ERROR|WARN"

Our VPS monitoring with Netdata tutorial shows how to track Redis metrics alongside other system resources. This provides comprehensive monitoring for your entire infrastructure.

Frequently Asked Questions

How many nodes do I need for a Redis cluster?

A minimum of three master nodes is required for Redis cluster. For high availability, add one replica per master, totaling six nodes. This configuration can survive the loss of any single node without downtime.

Can I run Redis cluster on a single server?

Yes, but it defeats the purpose of clustering. Running multiple Redis instances on one server provides no failover protection. Use separate VPS instances to ensure true high availability.

What happens when a master node fails?

The cluster automatically promotes the failed master's replica to become the new master. This process takes 15-30 seconds depending on your timeout configuration. Client applications need to support Redis cluster protocol to handle the transition smoothly.

How do I backup a Redis cluster?

Each node maintains its own data subset. Create backups by running BGSAVE on all master nodes simultaneously, then copy the resulting dump.rdb files. For automated backups, use cron jobs or our database backup automation guide.

Can I mix Redis versions in a cluster?

No, all cluster nodes must run the same Redis version. Version mismatches cause protocol incompatibilities and unpredictable behavior. Always upgrade all nodes together during maintenance windows.