Keeping a single Redis cache endpoint available during node failures prevents application outages and avoids reconfiguring clients after maintenance or unexpected reboots.
A Pacemaker and Corosync cluster managed with pcs treats high availability as resources that start, stop, and move between nodes. The cache endpoint is typically modeled as a floating IP address (VIP) plus a systemd resource for Redis, grouped so the VIP comes up first and the service starts on the same node.
This setup is active-passive and does not provide automatic data replication by itself. Persistence (RDB or AOF) and any replication strategy must be configured separately, and the Redis listener (bind/protected-mode), firewall rules, and SELinux policy must allow client connections to the VIP on port 6379.
Related: How to set up Redis active-active with PCS
Related: How to create a Pacemaker cluster
Steps to set up Redis high availability with PCS:
- Confirm the cluster is online with quorum.
$ sudo pcs status Cluster name: clustername Cluster Summary: * Stack: corosync (Pacemaker is running) * Current DC: node-01 (version 2.1.6-6fdc9deea29) - partition with quorum * 3 nodes configured * 0 resource instances configured ##### snipped #####
- Identify the Redis service unit name on all nodes.
$ systemctl list-unit-files --type=service | grep -E '^(redis|redis-server)\.service' redis-server.service enabled enabled redis.service alias -
- Disable the detected Redis service unit on all nodes so it does not start outside cluster control.
$ sudo systemctl disable --now redis-server Synchronizing state of redis-server.service with SysV service script with /usr/lib/systemd/systemd-sysv-install. Executing: /usr/lib/systemd/systemd-sysv-install disable redis-server Removed "/etc/systemd/system/multi-user.target.wants/redis-server.service". Removed "/etc/systemd/system/redis.service". ##### snipped #####
The --now flag stops the service immediately.
Leaving Redis enabled can start multiple independent instances at boot and cause unexpected split-brain writes outside the VIP.
- Create a floating IP resource for the cache endpoint.
$ sudo pcs resource create redis_ip ocf:heartbeat:IPaddr2 ip=192.0.2.63 cidr_netmask=24 op monitor interval=30s
Using an IP already assigned on the network causes address conflicts and intermittent outages.
- Create the Redis service resource using the detected unit name.
$ sudo pcs resource create redis_service systemd:redis-server op monitor interval=30s
Use systemd:redis when that unit is present.
- Group the VIP and service resources so the VIP starts before Redis.
$ sudo pcs resource group add redis-stack redis_ip redis_service
The resource group keeps the VIP and Redis on the same node during failover.
- Verify the resource group placement.
$ sudo pcs status resources * Resource Group: redis-stack: * redis_ip (ocf:heartbeat:IPaddr2): Started node-01 * redis_service (systemd:redis-server): Started node-01 - Confirm Redis is reachable through the VIP.
$ redis-cli -h 192.0.2.63 ping PONG
Run from an application host or from the active node when redis-cli is available.
- Move the resource group to another node to validate failover.
$ sudo pcs resource move redis-stack node-02
The move command creates a temporary location constraint until cleared.
- Verify the VIP and service are started on the target node after the move.
$ sudo pcs status resources * Resource Group: redis-stack: * redis_ip (ocf:heartbeat:IPaddr2): Started node-02 * redis_service (systemd:redis-server): Started node-02 - Clear the temporary move constraint to restore normal placement decisions.
$ sudo pcs resource clear redis-stack
Forgetting to clear the constraint can pin the VIP to a single node and prevent automatic recovery.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
