Designing for Production
The information in the section discusses important topics you need to know about when designing your Redis Enterprise Software cluster for a production deployment.
The hardware requirements for Redis Enterprise Software (RS) are different for development and productions environments. Development environment hardware requirements If you are looking to do development, test or experimentation with RS, you can use non-production hardware (e.g. laptops, desktop, small VM/instance, etc.). Item Description Minimum Requirements Recommended # of nodes per cluster One node is fine, but to utilize the advanced cluster features at least two nodes are required.
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. Disk Sizing for Heavy Write Scenarios In extreme write scenarios, when AOF is enabled, the AOF rewrite process may require considerably more disk space for database persistence. To estimate the required persistent disk space in such cases, use the formula described below. The required persistent disk space for AOF rewrite purposes in extreme write scenarios, assuming identical shard sizes: X (1 + 3Y +Y²) where: X = each shard size Y = number of shards
For each node in the cluster, you can configure both a persistent storage and an ephemeral storage path. 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, e.g server logs, configurations, files. For example, if you choose any type of persistence for a database, then the persistence information is stored in this location. Ephemeral storage is optional.
You can configuration 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 Redis.io. Discovery Service For the Discovery Service which utilizes the Redis Sentinel API, the following clients are tested and recommended: Redis-py (Python redis client) HiRedis (C redis client) Jedis (Java redis client) Ioredis (NodeJS redis client) If you need to use other clients with the Discovery Service, perhaps look at Sentinel Tunnel, a utility published by Redis Labs for this purpose.
Redis Enterprise Software (RS) is supported on several operating systems, cloud environments, and virtual environments. All choices below are 64-bit compatible. Note: This document covers RS 5.0 and up. Platform Versions/Information Ubuntu 14.04, 16.04 64-bit, Server or Desktop. The Server version is recommended for production deployments. RHEL/CentOS 6 6.7, 6.8, 6.9 64-bit. Requires at least "Minimal Install" configuration. RHEL/CentOS 7 7.
It is important to ensure 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 ensure 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 ensure that all server clocks are synchronized.