Configuring HAProxy for Tungsten Dashboard

Introduction

The Tungsten Dashboard is a browser-based GUI, designed to make using a Tungsten Cluster as easy as possible.

An optional part of setting up the Dashboard is the use of the free HA Proxy software to provide a level of fault tolerance to the Dashboard by using more than one node to gather information from or on which to execute cluster commands.

This blog post will walk you through configuring HA Proxy for the Tungsten Dashboard, along with the new command `tpm generate-haproxy-for-api` which helps automate the process by translating existing INI files into haproxy.cfg config file format.

The Brief

The Tungsten Dashboard uses the built-in Cluster API to view and control the clusters it has defined.

Since the API relies upon communications with a Manager, and all Managers in a cluster share the same information, the Tungsten Dashboard is able to function as long as it has access to an available manager in a cluster.

HAProxy allows the Dashboard to reach an available Manager on a database node without having to manage the availability logic.

HAProxy - Powerful, Stable and Free

The free and mature HAProxy software allows you to define a listener port called the frontend, and an associated pool of host/port definitions called a backend.

For the Tungsten Dashboard’s purposes, we typically define a frontend in HAProxy that takes API requests for the Manager and distributes those calls in a Round-Robin fashion to the available, appropriate cluster nodes defined via the associated backend, like this standalone cluster alpha:

frontend alpha
    bind *:8091
    default_backend    alpha

backend alpha
    balance     roundrobin
    server  db1 db1:8090 check
    server  db2 db2:8090 check
    server  db3 db3:8090 check

This means that as long as there is one node up with the Manager running, HAProxy will ensure that the API call will reach it and satisfy the Dashboard’s request.

It is ok to define a frontend and a backend with the same names since they are completely different namesets.

Here is an example of a Composite Cluster named global, with two child clusters, east and west:

The haproxy.cfg entries would look like this:

frontend global
    bind *:8091
    default_backend             global
frontend east *:8092
    default_backend             east
frontend west *:8093
    default_backend             west

backend global
    balance     roundrobin
    server  db1 db1:8090 check
    server  db2 db2:8090 check
    server  db3 db3:8090 check
    server  db4 db4:8090 check
    server  db5 db5:8090 check
    server  db6 db6:8090 check

backend east
    balance     roundrobin
    server  db1 db1:8090 check
    server  db2 db2:8090 check
    server  db3 db3:8090 check

backend west
    balance     roundrobin
    server  db4 db4:8090 check
    server  db5 db5:8090 check
    server  db6 db6:8090 check

We have one frontend port per cluster, so port 8091 is for global, 8092 for east and 8093 for west.

Note that any of the six nodes anywhere in the cluster can serve the composite parent service, but only the proper associated nodes can serve child cluster requests.

In the Dashboard, we would then easily configure the entire composite cluster by providing just the port number of 8091 for the global service to the Auto-Define dialog box, then click Proceed:

The Dashboard will interrogate the Manager for all needed information to populate the composite clusters. Note that in the results message, the Dashboard has located all three clusters: global, east and west. Click the link to reload the page and proceed:

New Tool as of Version 7: tpm generate-haproxy-for-api

Prior to version 7, a DBA would need to hand-define the haproxy.cfg entries for the Tungsten Dashboard.

As of Tungsten Clustering v7.0.0, you may now create the HAProxy definitions more easily with some help from the `tpm generate-haproxy-for-api` command.

This tool will read all available INI files and dump out corresponding haproxy.cfg entries with properly incrementing ports. If it is a Composite cluster, the composite parent will come first, followed by the composite children in alphabetical order.

To begin, simply execute the command on any node with a standard INI configuration file:

shell> tpm generate-haproxy-for-api
#### Begin Tungsten Dashboard ####

frontend global
    bind *:8091
    default_backend    global

frontend east
    bind *:8092
    default_backend    east

frontend west
    bind *:8093
    default_backend    west

backend global
    balance roundrobin
    server    db1-demo.continuent.com db1-demo.continuent.com:8090 check
    server    db2-demo.continuent.com db2-demo.continuent.com:8090 check
    server    db3-demo.continuent.com db3-demo.continuent.com:8090 check
    server    db4-demo.continuent.com db4-demo.continuent.com:8090 check
    server    db5-demo.continuent.com db5-demo.continuent.com:8090 check
    server    db6-demo.continuent.com db6-demo.continuent.com:8090 check

backend east
    balance roundrobin
    server    db1-demo.continuent.com db1-demo.continuent.com:8090 check
    server    db2-demo.continuent.com db2-demo.continuent.com:8090 check
    server    db3-demo.continuent.com db3-demo.continuent.com:8090 check

backend west
    balance roundrobin
    server    db4-demo.continuent.com db4-demo.continuent.com:8090 check
    server    db5-demo.continuent.com db5-demo.continuent.com:8090 check
    server    db6-demo.continuent.com db6-demo.continuent.com:8090 check

#### End Tungsten Dashboard ####

Simply copy-and-paste the output into the haproxy.cfg file at the bottom, then reload/restart HAProxy.

To change the starting port, just add the `--port NNNN` option.

Bonus

To see which INI file the Tungsten deployment is using, run this command:

shell> tpm query values deployment_external_configuration_source
{
  "deployment_external_configuration_source": "/etc/tungsten/tungsten.ini"
}

Wrap-Up

In this post we explored the details of HAProxy configuration for the Tungsten Dashboard, including the new tool, `tpm generate-haproxy-for-api`, included with Tungsten version 7+.

For more information, please see our online documentation:

Smooth sailing!

About the Author

Eric M. Stone
COO and VP of Product Management

Eric is a veteran of fast-paced, large-scale enterprise environments with 35 years of Information Technology experience. With a focus on HA/DR, from building data centers and trading floors to world-wide deployments, Eric has architected, coded, deployed and administered systems for a wide variety of disparate customers, from Fortune 500 financial institutions to SMB’s.

Add new comment