How to set up a Shares cluster

IN THIS ARTICLE:

Description

Aspera Shares can be deployed as a cluster for improved performance and availability.

In a Shares cluster, instances of the Shares web application are run on multiple systems (typically, two) and connected to shared storage.

Such a set up allows you to load balance the traffic coming into your Shares servers. Alternatively, you could also implement a high availability (HA) system by having a redundant Shares instance to replace the main Shares instance should it go down.

Note:

This article demonstrates a cluster setup connected to one shared MySQL server. In order to avoid having this MySQL server as a single point of failure, your shared storage will need to be HA. Take note that HA MySQL requires the NDB storage engine.

Additionally, this article does not include any implementation details for handling Shares failovers. Aspera offers Aspera Cluster Manager (ACM), a free software module that handles the configuration and starting of services of failed over nodes for you. If you would like more information on ACM, contact Aspera.

The instructions below will show you how to set up your Shares cluster, which entails configuring each Shares instance and connecting it to a shared MySQL database.

Environment

  • Product: Shares
  • Operating System: Linux, Windows

Instructions

1. Install Shares on each machine in your cluster.

Follow the install instructions in the Shares product manual as normal for your operating system.

2. Set up the shared MySQL server

By default each Shares installation comes bundled with its own MySQL server. However, in a cluster all the Shares instances must connect to the same shared MySQL server, usually one on a machine separate from the Shares instances for reliability.

You need to migrate both the Shares and Stats Collector databases from one of your Shares instances to the remote MySQL server. Choose one of your Shares instances to migrate from, and follow the configuration instructions:

Note that the database names differ slightly on Linux and Windows.

For a Shares instance on Linux the databases to migrate are:

  • shares
  • stats_collector

For a Shares instance on Windows the databases to migrate are:

  • web_production
  • stats_collector

3. (Linux only step) Disable the local MySQL server on all Shares instances

For a Shares instance on Linux, run the following commands to disable MySQL:

# rm /opt/aspera/shares/etc/runit/runlevels/setup/mysqld
# rm /opt/aspera/shares/etc/runit/runlevels/up/mysqld

4. Copy files to the other Shares instances

All the Shares instances need to have the same copy of certain files in order to work properly as a cluster.

Use the Shares instance that you migrated the databases from as your source of these files. Copy the following files from this system over to all the other Shares instances:

Windows
C:\Shares\statscollector\etc\keystore.jks
C:\Shares\statscollector\etc\persistence.xml
C:\Shares\www\config\aspera\secret.rb
C:\Shares\www\config\database.yml
C:\Shares\www\config\initializers\secret_token.rb

Linux
/opt/aspera/shares/u/stats-collector/etc/keystore.jks
/opt/aspera/shares/u/stats-collector/etc/persistence.xml
/opt/aspera/shares/u/shares/config/aspera/secret.rb
/opt/aspera/shares/u/shares/config/database.yml
/opt/aspera/shares/u/shares/config/initializers/secret_token.rb

5. Your Shares cluster is now set up

You should now be able to complete your load balancing/failover system.

Troubleshooting

1. Cannot connect multiple Shares servers to the same node -- one fails with an Unauthorized error

This error indicates that your Shares instances do not share the same copy of the required files in step 4 of the instructions above. Check again and verify that these files are copied to the proper locations and are identical on all Shares instances.

2. After adding a node, the following error appears: “Stats collector issue. Node unknown. Configuration changes have not had time to propagate to the stats collector or node configuration incorrect.”

This error likely indicates that the Stats Collector private and public keys do not match. The private key is located in the keystore.jks file which must be the same on all Shares instances. The public key is stored in the shared MySQL database.

This mismatch can occur if you did not copy the keystore.jks file from the machine on which you migrated the database from.

In order to fix this, you will need to regenerate the keys:

a. Choose one Shares instance and navigate to the Stats Collector directory:

  • Linux: /opt/aspera/shares/u/stats-collector
  • Windows: C:\Shares\statscollector

From this directory, run the following command:

# java -jar lib/stats-collector-admin.jar regenerate-keys 

b. From this Shares instance, copy the keystore.jks (path listed in step 4 of the instructions) file to the other Shares instances.

c. On each Shares instance navigate to the following directory:

  • Linux: /opt/aspera/shares/u/shares/bin
  • Windows: C:\Shares\www

and run the following rake task to resave all the nodes:

# rake aspera:stats_collector:add_all_nodes
Have more questions? Submit a request

0 Comments

Article is closed for comments.
Powered by Zendesk