Bitnami Redis for Google Multi-Tier Solutions

What are the differences between a Bitnami Single-Tier Solution and Multi-Tier Solution?

Single-tier architecture implies that all the required components of an application run on a single server. If your environment is growing and becoming more complex, a single layer architecture will not meet your scalability requirements. Single-Tier Solutions are great for departmental applications, smaller production environments, new users, or those applications that don't support multi-tier architectures.

The typical architecture of a Bitnami Single-Tier Solution looks like this:

Single-tier architecture

Multi-tier architecture involves more than one server and infrastructure resource. As an example, the Front End-Database topology separates the application server from the database server. This allows you to extend workloads in the cloud and tailor your application to meet specific scalability and reliability goals. Multi-Tier Solutions provide more sophisticated deployment topologies for improved scalability and reliability for larger production or mission critical environments.

This Bitnami Multi-Tier Solution 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. This topology is illustrated below:

Multi-tier architecture

Description

Redis is an open source, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.

First steps with the Bitnami Redis Stack

Welcome to your new Bitnami application running on Google Cloud Platform! Here are a few questions (and answers!) you might need when first starting with your application.

What credentials do I need?

You need two sets of credentials:

  • The application credentials, consisting of a username and password. These credentials allow you to log in to your new Bitnami application.

  • The server credentials, consisting of an SSH username and key. These credentials allow you to log in to your Google Cloud Platform server using an SSH client and execute commands on the server using the command line.

What is the administrator username set for me to log in to the application for the first time?

Username: user

What is the administrator password?

The password is randomly assigned when you first launched the application through the Google Cloud Launcher. Refer to the FAQ to learn how to find the application credentials.

What SSH username should I use for secure shell access to my application?

SSH username: bitnami

How do I get my SSH key or password?

You will need to create and associate an SSH key pair with the server(s). Use the same key pair for secure shell access to the server. Click here for more information.

How to start or stop the services?

NOTE: The steps below require you to execute the commands on the remote server. Please check our FAQ for instructions on how to connect to your server through SSH.

Each Bitnami server includes a control script that lets you easily stop, start and restart all the services installed on the current individual server.

Obtain the status of a service with the service bitnami status command:

$ sudo service bitnami status

Use the service bitnami command to start, stop or restart all the services in a similar manner:

  • Start all the services.

    $ sudo service bitnami start
    
  • Stop all the services.

    $ sudo service bitnami stop
    
  • Restart all the services.

    $ sudo service bitnami restart
    
TIP: To start, restart or stop individually each server of the cluster, check the FAQ section about how to start or stop servers in a Multi-Tier Solution.

How to connect instances hosted in separate virtual networks or VPCs?

The Google Cloud Platform makes it possible to connect instances hosted in separate Virtual Private Clouds (VPCs), even if those instances belong to different projects or are hosted in different regions. This feature, known as VPC Network Peering, can result in better security (as services do not need to be exposed on public IP addresses) and performance (due to use of private, rather than public, networks and IP addresses).

Learn more about VPC Network Peering.

How to check cluster replication status?

To check the status of the replication in your Redis deployment, log in to the master server host through SSH, and execute the Redis command line client as follows. Replace the YOURPASSWORD placeholder with the value of your password:

$ redis-cli -a YOURPASSWORD INFO Replication

The output of these commands will be a list of connected cluster nodes and their current status.

How to add nodes to the cluster?

IMPORTANT: These steps assume that you have already installed the Google Cloud SDK and you are signed in to the Google Cloud Platform through the gcloud command-line client. If this is not the case, please refer to the Google Cloud SDK documentation for instructions on how to install and use the command-line client.

To add nodes to the cluster, follow these steps:

  • Log in to the Google Cloud Console.
  • Browse to the Deployment Manager and select the deployment to which you wish to add nodes.
  • In the deployment overview, review the deployment properties and click to view the "Expanded Config" deployment configuration file.

Expanded configuration

  • Copy or download the contents of the "Expanded Config" file to the server with the Google Cloud SDK as expanded-config.yaml.
  • Edit the file using a text editor and add configuration for one or more additional nodes, by copying the configuration and metadata for an existing node and its corresponding data disk and then updating the copied configuration to use a unique name for the new node(s) and data disk(s).

    For example, to add a new MongoDB node to a MongoDB cluster, here is an abridged example of the configuration and metadata that you would update to add a new node and data disk. To create a unique name for the new node, you would typically replace the XX placeholder in the node name with a number.

    NOTE: The code block below is an illustrative example for MongoDB and will differ in your specific deployment. You should always copy the code block from your deployment's actual configuration file.
     - metadata:
         dependsOn:
         - mongodb-multivm-2-node-XX-data
         - mongodb-multivm-2-node-0
       name: mongodb-multivm-2-node-XX
       properties:
         bootDiskType: pd-standard
         canIpForward: true
         disks:
         - autoDelete: true
           boot: true
           deviceName: mongodb-multivm-2-node-XX-boot
           initializeParams:
             diskType: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/zones/us-central1-f/diskTypes/pd-standard
             sourceImage: projects/bitnami-launchpad/global/images/bitnami-mongodb-3-4-7-0-linux-debian-8-x86-64-nami
           type: PERSISTENT
         - autoDelete: true
           boot: false
           deviceName: mongodb-multivm-2-node-XX-data
           source: $(ref.mongodb-multivm-2-node-XX-data.selfLink)
           type: PERSISTENT
         machineType: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/zones/us-central1-f/machineTypes/n1-standard-1
         metadata:
             ...
         networkInterfaces:
         - accessConfigs:
           - name: External NAT
             type: ONE_TO_ONE_NAT
           network: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/global/networks/default
           subnetwork: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/regions/us-central1/subnetworks/default
         serviceAccounts:
         - email: default
           scopes:
           - https://www.googleapis.com/auth/cloudruntimeconfig
         tags:
           items:
           - mongodb-multivm-2-node-XX
         zone: us-central1-f
       type: compute.v1.instance
     - name: mongodb-multivm-2-node-XX-data
       properties:
         sizeGb: 10
         type: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/zones/us-central1-f/diskTypes/pd-standard
         zone: us-central1-f
       type: compute.v1.disk    
    
  • Preview the updated deployment with the command below. Replace the DEPLOYMENT-ID placeholder in the command below with the correct name of your deployment.

    $ gcloud deployment-manager deployments update DEPLOYMENT-ID --config expanded-config.yaml --preview
    
  • Once you have verified that the deployment preview is correct, confirm the deployment and initialize the new node(s):

    $ gcloud deployment-manager deployments update DEPLOYMENT-ID
    

Verify that the new node(s) have been added successfully by logging in to the Google Cloud Console and selecting the deployment to check the number of running nodes. Once you have confirmed that the new node(s) have been added successfully, log in to the primary node and verify that the new node(s) are now part of the cluster by checking the cluster replication status.

How to check the Redis Sentinel status

To check the status of Redis Sentinel, log in to the master server host through SSH, and execute the Redis command line client as follows. Replace the MASTERSET placeholder with the master set name:

$ redis-cli -p 26379 SENTINEL sentinels MASTERSET

This command will show a list of sentinel instances for this master, and their current status.

What is the default configuration?

By default, the Redis server is configured to run on the default port 6379. You can connect to the server locally or remotely using the redis-cli command line tool. Replace the YOURPASSWORD placeholder with the value of your password:

$ redis-cli -h SERVER-IP -a YOURPASSWORD

The Redis server is configured following the security guidelines from the official Redis documentation. Although you use a password to connect to the server, it is strongly recommended to change your firewall policies to only accept connections from the IP address that you are using to connect to the Redis server.

Redis version

In order to check which Redis version your machine is running, execute the following command from the console:

$ redis-server -v

Redis configuration file

The Redis configuration file is located at /opt/bitnami/redis/etc/redis.conf.

Redis port

The default port on which Redis listens is 6379.

Redis log file

The Redis log file is created at /opt/bitnami/redis/logs/redis-server.log.

How is the cluster configured?

The Bitnami Multi-Tier Solution for Redis uses multiple VMs, consisting of 1 master and 2 or more slaves, to provide a horizontally scalable and fault-tolerant deployment. Data automatically replicates from the master node to all slave nodes. In addition to that, every virtual machine includes a Redis Sentinel to ensure high availability. Data persistence is optional and easy to enable.

By default, Redis is set with the configuration below:

  • Replication: Master instances can perform read/write operations that are replicated to the slaves nodes to have the data available for read only queries.
  • (Optional) Persistence: You can choose between RDB + AOF (with a fsync "every second" policy) persistence or disable it at all. See the Redis official documentation about persistence for further information on this.
  • High Availability: This is achieved thanks to Redis Sentinel. In case of failure in the instances, the Sentinels will agree on select a new master/slaves configuration, to keep the deployment working. For more information, refer to the Redis Sentinel Documentation.

How to connect to the Redis server?

Connect to Redis from the same computer where it is installed with the redis-cli client tool. Replace the YOURPASSWORD placeholder with the value of your password:

$ redis-cli -a YOURPASSWORD
127.0.0.1:6379>

Once connected, use the Redis get and set commands to save and retrieve keys and their values. Here's an example:

127.0.0.1:6379> set foo bar
OK
127.0.0.1:6379> get foo
"bar"

How to connect to Redis from a different machine?

IMPORTANT: We strongly discourage opening ports to allow inbound connections to the server from a different network. Making the application's network ports public is a significant security risk. The recommended way for connecting two instances deployed in different networks is by using VPC network peering. If you must make it accessible over a public IP address, we recommend restricting access to a trusted list of source IP addresses and ports using firewall rules. To do so, follow the instructions below.

Connecting to Redis from the same network

NOTE: You will only be able to connect to your Redis instances from machines that are running in the same network as your Redis instances.

You can now connect to Redis using the command below. Replace the YOURPASSWORD placeholder with the value of your password:

$ redis-cli -h SERVER-IP -a YOURPASSWORD

Connecting to Redis from a different network

If you must connect to the database from a machine that it is not running in the same network as the Redis cluster, you can follow these approaches (these are shown in order of preference, from the most secure to the less recommended solution):

  • Option 1: Peer both virtual networks to secure the connections between the two instances. Learn how to connect instances in different networks using network peering.
  • Option 2: Create an SSH tunnel to connect the database console to perform administrative tasks using the primary host's public IP address. Refer to the FAQ for more information on this.

    NOTE: You should only access the primary server using an SSH tunnel if you wish to temporarily connect to, or use, the Redis console. This approach is not recommended to permanently connect your application to the Redis cluster, as a connectivity failure in the SSH tunnel would affect your application's functionality.
  • Option 3: Make the server publicly accessible and restrict access to a trusted list of source IP addresses using firewall rules. Refer to the FAQ for information on opening ports in the server firewall.

How to change Redis persistence mode?

NOTE: Please, make sure you perform these steps in all the instances of your deployment.

By default, Bitnami solution uses RDB + AOF persistence to provide a good balance between performance and data durability.

However, you can change the modes to adapt Redis persistence to your needs. There are multiple possibilities to do so. Find below how to disable AOF as an example:

  • Edit the configuration file /opt/bitnami/redis/conf/redis.conf. Change the appendonly configuration directive from yes to no:

      appendonly no
    
  • Edit the Redis configuration file /opt/bitnami/redis/conf/redis.conf. Change the appendonly configuration directive from yes to no as shown below:

      appendonly no
    

    This change will apply when you restart the server.

  • (Optional) To apply the change inmediately, execute the following command. Replace the YOURPASSWORD placeholder with the value of your password:

      $ redis-cli -a YOURPASSWORD CONFIG set appendonly no
    

For more information on this, please check the Redis official documentation about Redis Persistence.

How to change the Redis password?

NOTE: Please, make sure you perform these steps in all the instances of your deployment.

You can modify the Redis password by editing the following files and replacing the existing password:

  • Edit the /opt/bitnami/redis/etc/redis.conf file. Note that you need to replace the NEWPASSWORD placeholder with the value of your new password:

      requirepass NEWPASSWORD
      masterauth NEWPASSWORD
    
  • Edit the /opt/bitnami/redis-sentinel/etc/sentinel.conf file. Replace the MASTERSET and NEWPASSWORD placeholders with the values of the master set name and your new password:

      sentinel auth-pass MASTERSET NEWPASSWORD
    
  • (Optional) To change the password at runtime and don't restart the Redis service, change the configuration files as is explained above and execute the following commands. Replace the CURRENTPASSWORD and NEWPASSWORD placeholders with the values of the current password and your new password:

      $ redis-cli -a CURRENTPASSWORD CONFIG set requirepass NEWPASSWORD
      $ redis-cli -a CURRENTPASSWORD CONFIG set masterauth NEWPASSWORD
    
  • Restart Redis Sentinel:

      $ sudo service bitnami restart redis-sentinel
    

How to test Redis with a client?

NOTE: You will only be able to perform these steps from machines that are running in the same network as your Redis instances. See Connecting To Redis From A Different Network.

You can test your Redis installation with a client like Predis, which is written in PHP. Find a complete list of Redis clients here.

NOTE: To use the example script below, you must have PHP installed on the server. You can check this by executing php -v. If you don't have it available, you can easily install PHP on Debian with the command sudo apt-get install php5 or on CentOS with the command sudo yum install php.

Begin by extracting the contents of the downloaded archive and creating a simple script named example.php.

$ cd predis-1.0
$ nano example.php

The script begins by including the class autoloader file and instantiating an object of the class:

require 'autoload.php';
$client = new Predis\Client(array(
  'host' => '127.0.0.1',
  'port' => 6379,
  'password' => 'PASSWORD'
));

Notice that it configures the client object by defining the Redis server host, port and password. Replace these values with actual values for your server.

You can now use the object's set() and get() methods to add or remove values from the cache. In this example, the set() method stores the value 'cowabunga' using the key 'foo'. The key can then be used with the get() method to retrieve the original value whenever needed.

$client->set('foo', 'cowabunga');
$response = $client->get('foo');

Here's the complete code for the example.php script:

<?php
require 'autoload.php';
$client = new Predis\Client(array(
  'host' => '127.0.0.1',
  'port' => 6379,
  'password' => 'PASSWORD'
));
$client->set('foo', 'cowabunga');
$response = $client->get('foo');
echo $response;
?>

Save the file and run it.

$ php example.php

The script will connect to your Redis server, save the value to the key 'foo', then retrieve and display it.

How to load a module to Redis?

NOTE: Please, make sure you perform these steps in all the instances of your deployment.

You can extend your Redis solution using the Redis modules. Thus, you can implement new features and add new functionalities to your application.

Follow the instructions below to load a module to Redis:

IMPORTANT: Before follow the steps below, you must compile the source code of the module. Check the Redis Modules official documentation for more information on this.
  • Once you have the compiled module library (module.so), the recommended way to load the module is during the startup of Redis by adding the following configuration directive to the configuration file /opt/bitnami/redis/etc/redis.conf:

      loadmodule /path/to/the/module.so
    

    The configuration will take effect in the next time you restart Redis.

  • (Optional) To load the module at runtime (with no downtime), execute the following command. Replace the YOURPASSWORD placeholder with the value of your password:

      $ redis-cli -a YOURPASSWORD MODULE LOAD /path/to/the/module.so
    

For more ways to load modules, please check the oficial documentation Redis Modules: Loading modules.

google-templates