Denodo Platform High Availability in AWS

Applies to: Denodo 8.0 , Denodo 7.0
Last modified on: 05 Sep 2022
Tags: AWS Administration Cloud 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.

Note that using Solution Manager Automated Cloud Mode, all these steps can be automated, that is the Solution Manager creates a Network Load Balancer and registers targets for the corresponding ports while deploying Virtual DataPort nodes in AWS. You can refer to Solution Manager Automated Cloud Mode Quick Start Guide for more information

Architecture to create

Let’s see a working example of a configuration of a Denodo 8.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):

  • Denodo #Inst1: an Amazon EC2 instance running Denodo 8.0.
  • Denodo #Inst2: an Amazon EC2 instance running Denodo 8.0.
  • DenodoNLB: an Amazon Network Load Balancer (NLB).

This guide will explain the steps done for configuring the NLB in this environment. The NLB could be used also for autoscaling (see Configuring Autoscaling of Denodo in AWS), but this document will focus on creating the NLB 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 8.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:
  • Denodo8.0#Inst1:
  • Runtime port: 9999
  • ODBC port: 9996
  • Web container: 9090
  • Denodo8.0#Inst2:
  • Runtime port: 9999
  • ODBC port: 9996
  • Web container: 9090
  • The port 9997 need not be configured for Denodo 8.0 and it is applicable only for Denodo 7.0.
  • Finally, check those ports are accessible from the NLB.  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 associating 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 NLB 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).
  4. Once the target groups are created register the instances for each group. Right-click over the group and select Register targets:

 

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



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 the 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.
  2. Now all the groups should be correctly configured:


Note for Denodo 7.0, the 9997 port should also be 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 edit the %DENODO_HOME%/conf/vdp/VDBConfiguration.properties file.

Set the DNS name as the value for the com.denodo.vdb.vdbinterface.server.VDBManagerImpl.registryURL property.

For monitoring, if SSL is going to be enabled add the property com.denodo.vdb.vdbinterface.server.VDBManagerImpl.jmx.port. This port should be:

  • A new free port in the VDP server host.
  • As the factoryPort, the jmx.port has to be open in the firewall rules.
  • Each VDP instance must take a different jmx.port.
  • Load balancer has to redirect the jmx.port traffic to the corresponding nodes.

NOTE: This property was added in the Denodo 8 20210715 update and the Denodo 7 20201116 update.

com.denodo.vdb.vdbinterface.server.VDBManagerImpl.registryURL=DenodoELB2-9936cab4d1228435.elb.eu-north-1.amazonaws.com

com.denodo.vdb.vdbinterface.server.VDBManagerImpl.jmx.port=19994

After these changes, execute the script <DENODO_HOME>/bin/regenerateFiles.bat/.sh and 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.

NOTE: You may need to edit the /etc/hosts file of your Denodo instances to add an entry mapping the Load Balancer DNS name to the IP address of the instance.

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

This section applies for Denodo 7.0 and Denodo 8.0 as well.

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 8.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.

Session Stickiness

The Web Applications of Denodo Platform 8.0 should be configured with Session Stickiness in order to be able to route the requests from the same user to the same server, where the session is kept. In order to ensure that the session is not lost, you would need to configure the load balancer to use sticky sessions.

Steps to configure the Session Stickiness

  • In the Amazon EC2 console navigation pane, under the Load Balancing section, choose Target Groups.
  • Select the target group to open its details page. This should be the target group used by the Denodo web applications. For this example, DenodoHTTP Target Group is chosen.
  • Click on the Actions Drop-down menu and select Edit attributes.

  • From the Attributes section, select the Stickiness option

  • Click on Save changes.
  • The Target Group will now be updated with the Stickiness attribute ‘Enabled

For more information see Sticky Sessions.

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