Integrate Distributed, Fault-Tolerant Caching with your App using Bitnami's Redis High Availability Solution

Published on March 15, 2018
Vikram Vaswani

Vikram Vaswani

Share this article

Looking for a scalable, distributed in-memory cache for your application? Well, you'll be happy to hear that Bitnami's Redis High Availability solution is now available in the Azure Marketplace and Google Compute Platform. This solution lets you deploy Redis in a high-availability, production-ready cluster in just a few clicks.

Cluster topology

Redis High Availability uses multiple virtual machines to replicate your data from a master node to a configurable number of replicas. Every virtual machine includes a Redis Sentinel to ensure high availability, giving you fault-tolerant, horizontally scalable data storage for your application. The cluster is configured following current best practices for security and scalability.

Deploying the Redis cluster

Why not try it out now? Sign in to the Google Cloud Console or Azure Marketplace, search for "bitnami redis high availability", choose the number of nodes you need (the default is 3) and deploy the cluster. Once the cluster is successfully deployed, you can log in to the primary node via SSH (Microsoft Azure instructions and Google Cloud Platform instructions) and run the commands below to check that everything is working (replace PASSWORD with your Redis password):

$ redis-cli -a PASSWORD> info

Check the "Replication" section of the output. It should show you the role of the current node (in this case, it's the master node) as well as the number of slave nodes and their IP addresses. If you see output similar to the above, your cluster is good to go!

Cluster status

Understanding the default network configuration and security

The cluster operates on ports 6379 (Redis) and 26379 (Redis Sentinel). For security reasons, these ports are not open for external connections by default. To allow external access to the Redis cluster, you can use virtual network peering, an SSH tunnel or an IP address whitelist. Refer to our documentation (Microsoft Azure instructions and Google Cloud Platform instructions) for more information on these options.

The Redis password is configured by you when you first deploy the solution. If you need to modify it, edit the main Redis configuration file at /opt/bitnami/redis/etc/redis.conf. Redis logs are stored in the /opt/bitnami/redis/logs/redis-server.log file.

By default, the Bitnami Redis High-Availability solution is configured with n1-standard-1 instances on Google Cloud Platform (1vCPU, 3.75 GB RAM) and D1_V2 instances on Microsoft Azure (1vCPU, 3.5 GB RAM). Of course, you can change these default instance types when deploying the solution.

In Bitnami's Redis High Availability solution, data automatically replicates from the master node to all slave nodes. Master instances support both read and write operations, while slaves are configured for read-only operations. Find out more about replication.

Understanding data persistence

Data persistence is optional and can be enabled or disabled depending on your needs. There are various options available:

  • RDB persistence: A point-in-time snapshot of the data stored in the cluster
  • AOF persistence: A log of every change made to the data in the cluster
  • RDB + AOF persistence: A combination of the previous two approaches
  • No persistence

Which option should you choose? The answer to this question depends on your use case, as each option has advantages and disadvantages:

  • RDB persistence is ideal if you need to back up your data at regular intervals without losing performance and you want the ability to store backup files offsite for recovery. However, if the cluster fails, you will still lose some data (the changes between the last backup and the instant of failure).
  • AOF persistence ensures minimum data loss in case of a cluster failure, as Redis will automatically replay the write log to arrive at the correct state when the cluster restarts. However, because AOF logs every write operation, it reduces the performance of the cluster, especially when set to use a fsync "every second" policy.
  • Using both RDB and AOF persistence ensures maximum safety of your data and gives you the option to back up data in a separate location for speedy recovery.

If performance is most important, you can also disable data persistence completely. Remember that when data persistence is disabled, all data will be lost if the cluster is shut down or terminates unexpectedly. Find out more about data persistence.

Testing redundancy and retrieving node metrics

The best thing about Bitnami's Redis High Availability solution is… yup, high availability. Every node includes a Redis Sentinel to ensure high availability. In case of a node failure, the Sentinels will automatically agree on a new master/slave configuration to keep the cluster operational. Therefore, if one node fails, your application will keep chugging along because it can still read and write data from the cluster.

To see this in action, connect to the master node and use the INFO command to check that there are two slaves currently connected. While you're there, also define a new variable and set it to a numeric value.

Testing redundancy

NOTE: Before proceeding with the next step, Microsoft Azure users should ensure that at least one of their slave nodes has a public IP address and that they are able to connect to it using SSH.

Now, turn off the master node, then connect to either of the slave nodes via SSH and run the INFO command. You will see that there is now one less node in the cluster and one of the previous slaves is now the new master node. Check the value of the variable set earlier and confirm that it's still intact.

Testing redundancy

You can also use the INFO command to keep track of cluster statistics, such as cache metrics, connections, memory usage, replication backlog and more. Here's an example:

Node metrics

You can do a lot more with Redis, and the Bitnami Redis High Availability solution gives you a secure, flexible and scalable platform on which to build your application. Add Bitnami's automatic updates and support for multiple cloud platforms, and you've got a solution that's ideal for common production scenarios, including data caching, message queuing or analytics.

Find out more about configuring and using Bitnami Redis High Availability in our docs and tweet @bitnami to tell us what you liked (or didn't like) about it!