I’ve been looking into getting some form of in memory caching for my sites BUT at same time do it in a way in which data would still be there in case of a crash and also do it HA style to be able to do maintenance on it without having some form of service interruption.
Enter – Redis (If you’re not familiar with Redis go to: https://redis.io/ . There are also some alternatives to it which bring more features and some of them even more performance to the table so do explore the alternatives.)
This interesting bit of software does pretty much everything I need it to do and at same time is popular enough to last for a long time. (at least long enough to test the alternatives)
Looking at its documentation I noticed that to build a proper Redis cluster you need quite a few nodes installed (a minimum of 3 masters each with its own slave) which translates to you need quite a few nodes to manage in terms of configuration and updates.
It may be true that doing it that way you’d have a full on proper cluster and would be able to handle millions of hits BUT for my personal needs I can live with a simpler setup (I only need it for my personal websites which – at least for now – don’t have that much traffic).
My solution: Setup a 2 node linux cluster (pcs / corosync / pacemaker and why not CentOS7) with some HA storage (DRBD) handling the folder that redis uses to store the in-memory data (/var/lib/redis/) and redis installed and running on the primary node and not running on the secondary one (it will be managed by the cluster)
Setting up the cluster is as easy as following this guide: https://clusterlabs.org/quickstart-redhat.html
Once the cluster part is sorted you will have to get the DRBD stuff installed on both nodes. A decent article on how to do this and even get it clustered will be here: https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/ch07.html
Here’s how it looks like in my case:
[root@redis1 ~]# pcs resource
Master/Slave Set: redisClone [redis]
Masters: [ redis2 ]
Slaves: [ redis1 ]
redis_fs (ocf::heartbeat:Filesystem): Started redis2
redis_service (ocf::heartbeat:redis): Started redis2
[root@redis1 ~]#
As you can see from the above output, I’m managing the drbd stuff, the mountpoint and the service using the cluster so if one of these nodes goes down the cluster will move the resources to the other node.
I did not create a floating ip on the nodes themselves because I have haproxy in front of them which is also part of a cluster where I do have a floating ip configured so I left that part out because in my case it’s being handled by a different set of nodes. In your case feel free to setup a floating ip for this purpose.
To get Redis going all I did was << yum install redis >> then looked at /etc/redis.conf (particularly at the bind option and at the password option considering that by default it will only allow localhost traffic to go through which is not an option for me) and made some adjustments to it as I saw fit (I did not start the service nor enable it, that is the job of the cluster)
Tested everything works ok using redis-cli then last step was to configure php (/etc/php.ini in my case) on the webservers to start using redis for sessions.
session.save_handler = redis session.save_path = "tcp://xxx.xxx.xxx.xxx:6379" (replace xxx.xxx.xxx.xxx with your floating ip for the redis service)
Doing it this way is not as scalable and as resilient as doing it the clustered way because this is just a simple fail-over setup BUT does allow you to start using redis in a way that is HA (highly available) and at same time allows one to stay on the cheap side while doing maintenance without taking his/her sites down in the process. With time, as you get more and more traffic to your sites and you’re making more and more money in the process, you can switch to the clustered setup to also get some load balancing into the equation (will allow you to scale horizontally) but remember this – there is no such thing as NO DATA LOSS with Redis! (or any other form of in memory cache) so do be careful how you use it (for starters remember that it is there to speed things up and NOT to store things permanently)
Oh yeah, I remembered one more tiny detail. Redis was supposed to be a service that one uses for his own stuff. If you’re thinking about running Redis as a service that you provide to your customers you’ll need to provide separate instances (one or more per customer) ideally running in some container or vm and with filters to allow traffic to it only from its owner’s applications and/or services.
Enjoy!