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.
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.
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 127.0.0.1:6379> 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!
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.
Data persistence is optional and can be enabled or disabled depending on your needs. There are various options available:
Which option should you choose? The answer to this question depends on your use case, as each option has advantages and disadvantages:
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.
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.
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.
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:
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.