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:

Item Description Minimum Requirements Recommended
Nodes per cluster You can install on one node but many features require at least two nodes. 1 node >= 2 nodes
RAM per node The amount of RAM for each node. 4GB >= 8GB
Storage per node The amount of storage space for each node. 10GB >= 20GB

Production Environment

We recommend these hardware requirements for production systems or for development systems that are designed to demonstrate production use cases:

Item Description Minimum Requirements Recommended
Nodes per cluster At least 3 nodes are required to support a reliable, highly available deployment that handles process failure, node failure, and network split events in a consistent manner. 3 nodes >= 3 nodes (Must be an odd number of nodes)
Cores* per node RS is based on a multi-tenant architecture and can run multiple Redis processes (or shards) on the same core without significant performance degradation. 4 cores >=8 cores
RAM* per node Defining your RAM size must be part of the capacity planning for your Redis usage. 15GB >=30GB
Ephemeral Storage Used for storing replication files (RDB format) and cluster log files. RAM x 2 >= RAM x 4
Persistent Storage Used for storing snapshot (RDB format) and AOF files over a persistent storage media, such as AWS Elastic Block Storage (EBS) or Azure Data Disk. RAM x 3 In-memory >= RAM x 6 (except for extreme 'write' scenarios); Redis on Flash >= (RAM + Flash) x 5.
Network We recommend using multiple NICs per node where each NIC is >100Kbps, but RS can also run over a single 1Gbps interface network used for processing application requests, inter-cluster communication, and storage access. 1G >=10G

*Additional considerations:

  • Cores:
    • When the CPU load reaches a certain level, RS tries to migrate "noisy" shards to a different node in the cluster and sends an alert to the operator.
    • If your application is designed to put a lot of load on your Redis database, make sure that you have at least one available core for each shard of your database.
    • If some of the cluster nodes are utilizing more than 80% of the CPU, consider migrating busy resources to less busy nodes.
    • If all the cluster nodes are utilizing over 80% of the CPU, consider scaling out the cluster by adding a node.
  • RAM:
    • Since Redis uses a relatively large amount of buffers (such as for slave communication, client communication, and pub/sub commands) make sure that at least 30% of the RAM is "unused" on each node.
    • If some of the cluster nodes are utilizing more than 65% of the RAM, you should look at migrating busy resources to less busy nodes.
    • If all the cluster nodes are utilizing over 70% of the RAM, you should look to scale out the cluster by adding a node.
    • Do not run other memory-consuming systems on the RS node.