Denodo Platform High Availability in AWS

Applies to: Denodo 7.0
Last modified on: 27 Jan 2020
Tags: Cloud AWS Administration Cluster configuration

Download document

You can translate the document:

Overview

The Denodo Platform has been designed to remain available 24 hours a day, 365 days a year. A standalone Denodo node has its own mechanisms to provide the highest possible availability (limiting the concurrent requests, establishing a memory usage threshold, etc.) but there are also external factors like network failures or general hardware errors that make a single node deployment not enough for a system with high availability requirements.

A properly designed High-Availability configuration will offer no single-point-of-failure. This will require at least two Denodo Platform nodes deployed in an active-active or active-passive configuration:

  • Active-active: in this configuration a load balancer distributes workloads across multiple compute resources (Denodo nodes). Using a load balancer increases the availability and fault tolerance of applications.





Specifically for AWS,
AWS Elastic Load Balancing is a load balancer which distributes incoming application or network traffic across multiple targets, such as Amazon EC2 instances, containers, and IP addresses, in multiple Availability Zones.

It also allows to configure health checks, which monitor the health of the computing resources, so that the load balancer sends requests only to the healthy ones.

There are different types of load balancers:

  • Application Load Balancer (ALB): meant for web applications with HTTP and HTTPS traffic.
  • Network Load Balancer (NLB): meant for ultra-high performance, support for TCP and UDP protocols, and static IP addresses for the applications (RECOMMENDED)
  • Classic Load Balancer (ELB): previous generation of Load Balancer for HTTP, HTTPS, and TCP.
  • Active-passive: this configuration is meant for Disaster Recovery and Failover. In the previous configuration, what happens if the Load Balancer fails? A failover configuration will help in that case, so when an instance is not healthy, it can automatically switch to another backup instance.


Specifically for AWS, Amazon Route 53 service is a Domain Name System (DNS) web service which allows configure a failover with one Primary component (for example, the “Active” Elastic Load Balancer) and one Secondary resource (the “Passive” Elastic Load Balancer).


High Availability Step-by-step Guide

This guide will list the steps needed in each server for configuring an active-active high availability architecture in AWS.

Architecture to create

Let’s see a working example of a configuration of a Denodo 7.0 Cluster (2 Virtual DataPort nodes). The idea is to build this architecture in AWS:

Basically it consists of 2 Denodo instances and an Elastic Load Balancer (ELB):

  • Denodo70#Inst1: an Amazon EC2 instance running Denodo 7.0 (standalone installation).
  • Denodo70#Inst2: an Amazon EC2 instance running Denodo 7.0 (standalone installation).
  • DenodoELB: an Amazon Network Load Balancer (NBL).

This guide will explain the steps done for configuring the ELB in this environment. The ELB could be used also for autoscaling (see Configuring Autoscaling of Denodo in AWS), but this document will focus on creating the ELB in a static way.

Step #1: Launch Denodo instances and initial Denodo configuration

The first thing to do is to start the Denodo instances in Amazon EC2:

Before launching the Denodo Platform 7.0 servers, connect to the instances one-by-one and ensure they are configured in this way:

  1. Denodo ports: use the same ports in all instances but the Denodo Virtual DataPort auxiliary port. Each node in the cluster should use a different auxiliary port. For example:
  • Denodo70#Inst1:
  • Runtime port: 9999
  • Auxiliary port: 19997
  • ODBC port: 9996
  • Web container: 9090
  • Denodo70#Inst2:
  • Runtime port: 9999
  • Auxiliary port: 29997
  • ODBC port: 9996
  • Web container: 9090
  • Finally, check those ports are accessible from the ELB.  Make sure the firewall of the instances is configured properly and check the security groups of the instances.

    Note: The AWS Network Load Balancer does not allow to associate security-groups to it, so connections from all the VPC-CIDR must be allowed. The following configuration allows all traffic from VPC and Remote Desktop from another set of IPs (external):


 

  1. RMI host: the configuration should be the URL of the load balancer (it is not known at this moment, as the ELB was not created yet). This configuration is explained in the section Step #3: Additional configuration in Denodo instances.

Note: All these ports can be edited from the <DENODO_HOME>/conf/vdp/VDBConfiguration.properties file. After modifying this file , execute the script <DENODO_HOME>/bin/regenerateFiles.bat/.sh and restart the Virtual DataPort server for the changes to take effect.

Step #2: Create the Load Balancer

Before creating the NLB, creation of some Target Groups is needed.

A target group is used to route requests to one or more registered targets (nodes in the cluster). A Load Balancer rule needs to be associated with a target group (for example, connections to port 9999 have to go to this group of EC2 instances). We recommend having the groups created before creating the load balancer.

Basically we will need a group for each port opened in the load balancer. In our case, we will need one group for port 9999, another for port 9996, etc.

Create Target Groups

Follow these steps:

  1. Go to EC2, click on Target Groups and press the Create target group button:


  1. In the new Dialog enter the name of the group, select the type (in our case, Instance), the protocol (TCP), the port (for example, 9999) and the VPC where instances are running:

  1. Leave the advanced health check settings as default.
  2. Click on Create.
  3. Do it for all the ports: 9999 (for standard connections to Virtual DataPort), 9996 (ODBC connections), 9090 (Denodo Web container connections) and 19997 (auxiliary port of Denodo70#Inst1) and 29997 (Auxiliary port of Denodo70#Inst2)
  4. Once the target groups are created register the instances for each group. Right-click over the group and select Register and deregister instance / ip targets:



  1. Register the instances, selecting them and clicking on the Add to Registered button:



Note: The two instances have to be added to all groups but the Auxiliary port groups. These groups will contain only the specific instance configured with that auxiliary port.

Why is this needed? 

The auxiliary port (by default 9997) is a RMI Factory port. When a client is trying to connect to Virtual DataPort it connects to the port 9999, then the server responds saying the client that it has to connect to the host configured as RMIHost and the RMI Factory port 9997 for communications with the server.

For that reason, we have to set the IP (or DNS) of the Load Balancer as RMI host in our Denodo instances, and use a different auxiliary port (one per server).

With this configuration, the balancing is done at connection level, so all the requests sent to Denodo from the same connection will reach the same Denodo server.

Create the Network Load Balancer

The procedure to create the NLB is accomplished by:

  1. In EC2 console, select the Load Balancers menu entry and click over Create Load Balancer button.


create_balancer.PNG

  1. Select the balancer type: Network Load Balancer:


  1. Define the load balancer: name, if it is internet-facing or not, the listener ports and the VPC/Availability Zone.


  1. Configure Routing settings selecting an available Target Group (in this step we can select only one group for all the listeners, we will modify them later):


  1. Creation of more target groups is not needed (already done), review the details and create the NLB.


  1. Select the NLB and open the Listener tab to configure the target groups (now all listener ports are forwarded to the same group). Click on each Listened and click on Edit:


  1. Remove the wrong group:


  1. And associate the correct one:


  1. Click Accept and click on the Update button.


  1. Now all the groups should be correctly configured:


  1. Go to the Description tab and copy the DNS name of the Load Balancer.


Test if the instances are healthy in the NLB

Now, as the groups have been assigned to the Load Balancer, we can go to the Target Groups list again and check if the instances are healthy (it means the health-check is working fine):

Step #3: Additional configuration in Denodo instances

As previously discussed in Step #1, in all the Denodo instances of the cluster need to set the RMI host to the URL of the load balancer.

Go to the Description tab of the Load Balancer and copy the DNS name.

Connect to each Denodo instance, stop the Denodo servers and paste the DNS name into the %DENODO_HOME%/conf/vdp/VDBConfiguration.properties file:

After that execute the script <DENODO_HOME>/bin/regenerateFiles.bat/.sh  and to start again the Denodo services.

To verify that the configuration is correct try to connect from an external VDP Administration Tool to the URL of the load balancer

Step #4 (optional): Enabling SSL/TLS in connections to Denodo Platform

Enabling TLS is a matter of following the steps to enable SSL/TLS in Denodo Platform servers. No further configuration is needed in the Network Load Balancer for SSL unless you are using HTTPS and the port changes to 9443 which should be added to the NLB configuration.


Failover Step-by-step Guide

The High Availability Step-by-step section listed all the things that have to be configured to set-up a cluster of Denodo servers using a Network Load Balancer. All the nodes configured in the Target Group are available so the NLB will route user connections to all those nodes.

In some cases, an Active-Passive configuration is needed, for example, for Disaster recovery scenarios with a cluster of Active Denodo servers and another cluster as Passive. In the case that the Active cluster is down, all the connections to the cluster should be routed to the Passive one (which will be converted to Active at that time).

Architecture

Let’s see a working example of an Active-passive configuration of a Denodo 7.0 Cluster. The idea is to build this architecture in AWS:

           

Basically it consists of several Denodo instances in Amazon EC2, Elastic Load Balancers on top of each Denodo cluster and a new player Amazon Route 53:

  • Amazon Route 53 is basically a Domain Name System (DNS) web service which allows DNS routing and health-check to configure failover scenarios.
  • An Active-Passive failover needs to be configured with one Primary (the “Active” NLB) and one Secondary resource (the “Passive” NLB).

Step #1: Launch Denodo instances and configure the Load Balancers

Refer to the High Availability section for the detailed steps to build that.

We have to configure two load balancers: one for the Active cluster and another one for the Passive cluster.

Step #2: Configure Amazon Route 53

From the AWS console, go to the Route 53 service and go to Hosted zones (this document assumes that the domain is already configured in AWS):

Select your Route 53 domain to see the current Record Sets.

To create an Active-passive (or Disaster Recovery) configuration create a new Record Set associated with a Failover Routing Policy. Follow the steps bellow:

  1. Add the Active cluster. Click on the Create Record Set button:
  1. Type: A
  2. Use Alias for selecting the active NLB (previously created)
  3. Set Record type and ID as Primary
  4. Evaluate Target health: Yes (to use the health checks of the NLB)
  5. Associate with Health Check: No (not needed)
  6. Sample:



  1. Add the Passive cluster. Click on Create Record Set button:
  1. Type: A
  2. Use Alias for selecting the passive NLB (previously created)
  3. Set Record type and ID as Secondary
  4. Evaluate Target health: Yes (to use the health checks of the NLB)
  5. Associate with Health Check: No (not needed)
  6. Sample:


  1. Save the Record Set and check both records are correctly saved:

Failover without Load Balancers

In some non-standard configurations (for example, when single Denodo servers have to be configured as Active-Passive) we can avoid using Load Balancers so the Architecture is simpler:

For this specific case the configuration is quite similar but some changes are needed to the Record Sets and Health Checks. See the steps bellow:

  1. Configuration of Record Sets:
  1. Configure them to use IP addresses instead of the NLB alias. Get the IP address of the Amazon EC2 instance and paste it to the Values field of the Record Set:
  1. For the active node:


  1. For the Passive node:


  1. Check the new configuration is correct:


  1. Configuration of Health Checks: in the previous screenshots each record set is associated with a Health check. At this point they cannot be associated yet because they have to be created first.
  1. From the AWS Console > Route 53 go to Health Checks and Create a new Health check: Give a name for the health check and configure the IP address of the EC2 instance and the Denodo Virtual DataPort server port (by default, 9999). See screenshot:


  1. Do the same to create another Health check for the Passive EC2 instance.
  2. Go to the Health Checks list and wait until both health checks become Healthy:


  1. Return to the Hosted zone and configure the Record sets selecting the new Health checks.

That way if the Active node is down, the Health check will return that the record is Unhealthy, so Route 53 will switch the DNS to the Passive instance, so new connections will be routed to the healthy server.

Questions

Ask a question
You must sign in to ask a question. If you do not have an account, you can register here

Featured content

DENODO TRAINING

Ready for more? Great! We offer a comprehensive set of training courses, taught by our technical instructors in small, private groups for getting a full, in-depth guided training in the usage of the Denodo Platform. Check out our training courses.

Training