Setting up redis-sentinel cluster nodes on openSUSE Leap 15.5 for Magento 2 High Availability session caches

Prerequisites and System Preparation

This guide assumes a foundational understanding of Redis, Sentinel, and Linux system administration. We will be setting up a Redis Sentinel cluster on openSUSE Leap 15.5. Ensure you have at least three nodes available for the Sentinel cluster to achieve quorum and fault tolerance. For this demonstration, we’ll use three nodes, but a production deployment should consider more for robustness.

Each node requires Redis server installed. The installation process on openSUSE Leap 15.5 is straightforward using `zypper`.

Installing Redis Server

On each of your intended Redis and Sentinel nodes, execute the following command:

Node 1, Node 2, Node 3

Run the following commands on each server:

sudo zypper refresh
sudo zypper install redis

After installation, ensure the Redis service is enabled and started. It’s crucial to configure Redis to listen on specific IP addresses rather than just `127.0.0.1` to allow Sentinel and potentially Magento to connect from other nodes.

Configuring Redis for Sentinel Communication

Edit the Redis configuration file, typically located at /etc/redis.conf. You’ll need to make the following adjustments:

Node 1 Redis Configuration (/etc/redis.conf)

# Bind to the specific IP address of this node and localhost for local management
# Replace '192.168.1.101' with the actual IP of Node 1
bind 127.0.0.1 192.168.1.101

# Set a strong password for Redis clients
requirepass YOUR_REDIS_PASSWORD

# Enable AOF persistence for data durability
appendonly yes

# Configure AOF fsync policy (e.g., every second)
appendfsync everysec

# Set a password for Sentinel to connect to Redis
# This is a separate password from requirepass, used by Sentinel itself.
# If not set, Sentinel will use the requirepass password.
# For simplicity, we'll use the same password here.
masterauth YOUR_REDIS_PASSWORD

Repeat this configuration for Node 2 and Node 3, adjusting the bind directive to their respective IP addresses (e.g., 192.168.1.102 for Node 2, 192.168.1.103 for Node 3). Ensure YOUR_REDIS_PASSWORD is identical across all nodes.

After modifying redis.conf on each node, restart the Redis service:

sudo systemctl restart redis

Verify Redis is running and accessible from other nodes (if firewall rules permit):

redis-cli -h 192.168.1.101 -p 6379 -a YOUR_REDIS_PASSWORD ping

You should receive a PONG response.

Setting up Redis Sentinel Nodes

Redis Sentinel is a distributed system that provides high availability for Redis. It monitors Redis instances, performs automatic failovers, and provides configuration for clients.

The Sentinel configuration file is typically named sentinel.conf. You’ll need to create or edit this file on each node that will run a Sentinel process. For this setup, we’ll run Sentinel on all three nodes that also host Redis.

Sentinel Configuration (/etc/redis/sentinel.conf)

Create a new configuration file or edit an existing one. A common location is /etc/redis/sentinel.conf. Ensure the directory exists and has appropriate permissions.

# Specify the IP address Sentinel should bind to.
# Binding to 0.0.0.0 makes it accessible from any interface,
# or specify the node's IP for more restricted access.
# Replace '192.168.1.101' with the actual IP of the node.
bind 192.168.1.101

# Port for Sentinel to listen on (default is 26379)
port 26379

# Define the master Redis server.
# 'mymaster' is the name of the master Redis instance.
# '192.168.1.101' is the IP of the master Redis server.
# '6379' is the port of the master Redis server.
# '2' is the quorum: the number of Sentinels that must agree
# that a master is down for a failover to be initiated.
# For a 3-node Sentinel cluster, a quorum of 2 is typical.
# For a 5-node cluster, a quorum of 3.
sentinel monitor mymaster 192.168.1.101 6379 2

# Specify the password for Sentinel to authenticate with Redis master/slaves.
# This must match the 'masterauth' directive in redis.conf.
sentinel auth-pass mymaster YOUR_REDIS_PASSWORD

# How often Sentinel should check the master and replicas (in milliseconds).
sentinel down-after-milliseconds mymaster 5000

# How long Sentinel should wait before attempting a failover.
sentinel failover-timeout mymaster 10000

# Number of replicas to promote to master during failover.
# For Magento, you typically want one master.
sentinel parallel-syncs mymaster 1

# Log file location
logfile "/var/log/redis/sentinel.log"

# Set Sentinel to run as a daemon
daemonize yes

Important Notes for Sentinel Configuration:

• Replace 192.168.1.101 with the actual IP address of the node where this sentinel.conf is being configured.
• The sentinel monitor line defines the master. Initially, one of your Redis instances will be the master. Sentinel will manage failover to a replica if the master becomes unavailable.
• The quorum value is critical for cluster stability. For N Sentinel nodes, a quorum of floor(N/2) + 1 is recommended. For 3 Sentinels, 2 is sufficient.
• sentinel auth-pass is essential if your Redis instances are protected by a password.
• sentinel down-after-milliseconds determines how long a Redis instance must be unreachable before being marked as Subjectively Down (SDOWN).
• sentinel failover-timeout is the maximum time Sentinel will wait to complete a failover.
• sentinel parallel-syncs controls how many replicas can be reconfigured to sync with the new master simultaneously after a failover. For Magento, a value of 1 is generally safe to avoid overwhelming the new master.

Copy this sentinel.conf file to the other Sentinel nodes (Node 2 and Node 3), adjusting the bind directive to their respective IP addresses. Ensure the sentinel monitor line points to the *initial* master’s IP address and port, and that the sentinel auth-pass is consistent.

Starting and Managing Redis Sentinel Services

On each node where you’ve configured Sentinel, you need to start the Sentinel service. openSUSE Leap 15.5 uses systemd.

Node 1, Node 2, Node 3

Execute the following commands on each server:

# Create the log directory if it doesn't exist
sudo mkdir -p /var/log/redis
sudo chown redis:redis /var/log/redis

# Start the Sentinel service
sudo systemctl start redis-sentinel

# Enable Sentinel to start on boot
sudo systemctl enable redis-sentinel

# Check the status of the Sentinel service
sudo systemctl status redis-sentinel

You should see output indicating the service is active and running. Check the Sentinel log file (/var/log/redis/sentinel.log) for any errors or initial connection messages.

Verifying Sentinel Cluster Operation

Once all Sentinel instances are running, you can verify their status and the monitored master from any of the Sentinel nodes.

Checking Sentinel Status

Connect to one of the Sentinel instances using redis-cli in Sentinel mode:

redis-cli -h 192.168.1.101 -p 26379 -a YOUR_REDIS_PASSWORD
# If you didn't set a password for Sentinel itself, omit -a YOUR_REDIS_PASSWORD
# If Sentinel is running on a different port, adjust -p accordingly.

Once connected, use the following Sentinel commands:

SENTINEL masters

This command will list all monitored masters. You should see an entry for mymaster, along with details about its current status, IP, port, and the number of Sentinels monitoring it.

SENTINEL sentinels mymaster

This command lists the Sentinel instances that are currently monitoring mymaster. You should see all your configured Sentinel nodes listed here.

SENTINEL replicas mymaster

This command lists the Redis replicas currently associated with mymaster. Sentinel will use these during a failover.

Configuring Magento 2 for High Availability Cache

Magento 2 Enterprise Edition supports Redis for session storage and caching. To leverage the Sentinel cluster for high availability, you need to configure Magento’s app/etc/env.php file.

Magento 2 env.php Configuration

Edit your Magento 2 app/etc/env.php file. Locate the cache and session sections and modify them to point to your Sentinel cluster. The key is to use the Sentinel port and specify the master name (mymaster in our example).

<?php
return [
    'backend' => [
        'front' => [
            'Mage_Cache_Backend_Redis' => [
                'backend' => 'Mage_Cache_Backend_Redis',
                'options' => [
                    'server' => '192.168.1.101', // IP of one of your Sentinel nodes
                    'port' => '26379',         // Sentinel port
                    'database' => '0',         // Redis database for cache
                    'password' => 'YOUR_REDIS_PASSWORD', // Redis password
                    'compress_data' => '1',    // Enable data compression
                    'compression_lib' => '',   // Leave empty for default zlib
                    'sentinel_master_name' => 'mymaster', // The name of your master defined in sentinel.conf
                    'sentinel_password' => 'YOUR_REDIS_PASSWORD', // Sentinel password (if different from Redis password)
                    'sentinel_timeout' => '0.5', // Sentinel connection timeout in seconds
                    'sentinel_read_timeout' => '1', // Sentinel read timeout in seconds
                    'sentinel_connect_timeout' => '1', // Sentinel connect timeout in seconds
                    'sentinel_retry_connect' => '5', // Number of retries for Sentinel connection
                    'persistent' => '',        // Leave empty for non-persistent connections
                    'force_standalone' => '0', // Set to '1' to force connection to a single Redis instance (disables Sentinel)
                    'connect_retries' => '1',  // Number of retries for Redis connection
                    'read_timeout' => '10',    // Redis read timeout in seconds
                    'automatic_cleaning_factor' => '0', // Disable automatic cache cleaning by Redis
                    'compress_tags' => '1',    // Enable compression for cache tags
                    'compress_threshold' => '2048', // Compression threshold for data
                    'compression_level' => '1', // Compression level
                    'load_remote_data' => '1', // Load remote data from Redis
                    'caching_application' => 'Magento', // Application identifier
                    'remote_cache_group' => ' Magento', // Cache group identifier
                    'use_lua_script' => '1',   // Use Lua scripts for cache operations
                    'nmap_port' => '6379'      // Port for Redis master/replica
                ]
            ]
        ]
    ],
    'session' => [
        'save' => 'redis',
        'redis' => [
            'sentinel_hosts' => '192.168.1.101:26379,192.168.1.102:26379,192.168.1.103:26379', // Comma-separated list of Sentinel nodes
            'sentinel_master_name' => 'mymaster', // The name of your master defined in sentinel.conf
            'password' => 'YOUR_REDIS_PASSWORD', // Redis password
            'database' => '1',         // Redis database for sessions
            'sentinel_password' => 'YOUR_REDIS_PASSWORD', // Sentinel password (if different)
            'sentinel_timeout' => '0.5', // Sentinel connection timeout
            'sentinel_read_timeout' => '1', // Sentinel read timeout
            'sentinel_connect_timeout' => '1', // Sentinel connect timeout
            'sentinel_retry_connect' => '5', // Number of retries for Sentinel connection
            'connect_retries' => '1',  // Number of retries for Redis connection
            'read_timeout' => '10',    // Redis read timeout
            'persistent' => '',        // Leave empty for non-persistent connections
            'force_standalone' => '0', // Set to '1' to force connection to a single Redis instance
            'nmap_port' => '6379'      // Port for Redis master/replica
        ]
    ]
];

Key Configuration Points for Magento:

• For the cache section, you specify server as one of your Sentinel node IPs and port as the Sentinel port (26379). The crucial parameters are sentinel_master_name and sentinel_password.
• For the session section, you provide a comma-separated list of sentinel_hosts (IP:Port for each Sentinel node). Again, sentinel_master_name and sentinel_password are vital.
• Ensure YOUR_REDIS_PASSWORD is correctly set for both Redis and Sentinel authentication.
• The database values for cache and session should ideally be different to avoid conflicts.
• sentinel_timeout, sentinel_read_timeout, and sentinel_connect_timeout can be tuned based on your network latency and performance requirements.
• force_standalone should be set to '0' to enable Sentinel functionality. Setting it to '1' will bypass Sentinel and connect directly to the specified server/sentinel_hosts, defeating the purpose of high availability.

After updating app/etc/env.php, you must clear Magento’s cache for the changes to take effect:

php bin/magento cache:clean
php bin/magento cache:flush

Testing Failover

To test the high availability setup, you can simulate a failure of the current Redis master.

Simulating Master Failure

On the current Redis master node (e.g., Node 1), stop the Redis service:

sudo systemctl stop redis

Monitor the Sentinel logs on the other Sentinel nodes (Node 2 and Node 3). You should see messages indicating that the master is being marked as down and a failover process is being initiated. After a short period (determined by your down-after-milliseconds and failover-timeout settings), one of the replicas should be promoted to master, and Sentinel will update its configuration.

You can verify the new master by connecting to Sentinel again and running SENTINEL master mymaster. The IP and port should now reflect the newly promoted master.

Restart the original Redis master (Node 1) after the failover is complete. Sentinel will detect it as a new replica and reconfigure it accordingly.

sudo systemctl start redis

This setup provides a robust Redis cluster for Magento 2 session and cache storage, significantly improving the availability and resilience of your e-commerce platform.