The information in the section discusses important topics you need to know about when designing your Redis Enterprise Software cluster for a production deployment.

    Hardware requirements

    The hardware requirements for Redis Enterprise Software (RS) are different for development and production environments. In a development environment you can test your application with a live RS database. If you want to test your application under production conditions, use the production environment requirements. In a production environment you must have enough resources to handle the load on the database and recover from failures. Development Environment You can build your development environment with non-production hardware, such as a laptop, desktop, or small VM or instance, and with these hardware requirements:


    When architecting a Redis Enterprise Software solution, there are some specific networking features that are worth your time to understand and implement. Multi-IP and IPv6 Redis Enterprise Software (RS) supports server/instances/VMs with multiple IP addresses, as well as IPv6 addresses. RS related traffic can be logically and physically divided into internal traffic and external traffic: “Internal traffic” refers to internal cluster communications, such as communications between the nodes for cluster management purposes.


    When designing for production, there are key performance topics that you should read up on. Configuring Shard Placement In Redis Enterprise Software (RS), the location of master and slave shards on the cluster nodes can impact the database and node performance. Master shards and their corresponding slave shards are always placed on separate nodes for data resiliency. The shard placement policy helps to maintain optimal performance and resiliency. In addition to the shard placement policy, considerations that determine shard placement are: Separation of master and slave shards Available persistence and Redis on Flash (RoF) storage Rack awareness Memory available to host the database when fully populated The shard placement policies are:

    Persistent and ephemeral storage

    For each node in the cluster, you can configure both persistent storage and ephemeral storage paths. Persistent storage is mandatory. It is used by the cluster to store information that needs to persist even if a shard or a node fails, including server logs, configurations, files. For example, if you configure persistence for a database, then the persistence information is stored in this location. The persistent volume must be a SAN (Storage Area Network) using an EXT4 or XFS file system and be connected as an external storage volume.


    Configuring TLS Authentication and Encryption To prevent unauthorized access to your data, RS databases support the TLS protocol (the more secure successor to SSL) that includes: Encryption - Makes sure that the traffic can only be read by the sender and recipient. Authentication - The server or client makes sure that it communicates with an authorized entity. When you enable TLS for a database or CRDB, encryption is enforced on either all communications or only communications between clusters, and RS sends its certificate to clusters and clients for authentication to the database or CRDB.

    Supported Clients and Web Browsers

    You can configure Redis Enterprise Software (RS) programmatically with client libraries or manually with the RS Web Console. Redis Client Libraries For connecting to RS databases with your Redis application, you can use any of the available client libraries listed on Discovery Service We recommend these clients that are tested for use with the Discovery Service that uses the Redis Sentinel API: Redis-py (Python redis client) HiRedis (C redis client) Jedis (Java redis client) Ioredis (NodeJS redis client) If you need to use another client, consider using Sentinel Tunnel to discover the current Redis master with Sentinel and create a TCP tunnel between a local port on the client and the master.

    Synchronizing cluster node clocks

    It is important to make sure that all cluster node’s clocks are synchronized using Chrony and/or NTP. Without this synchronization, there may be problems with internal cluster communications and have downstream impacts. When you initially install Redis Enterprise Software, the install script asks for permission to configure a scheduled Cron job if it does not detect Chrony or NTP. This should make sure that the node’s clock is always synchronized. If you did not confirm configuring this job during the installation process, you must use the Network Time Protocol (NTP) regularly to make sure that all server clocks are synchronized.