Setting up Aspera Cluster Manager

For overview information about Aspera Cluster Manager (ACM), see Aspera Cluster Manager (Overview).

Installing ACM Software on the Shared Storage

Obtain the latest ACM software from Aspera and place it in the shared /mnt/shared/orchestrator/acm_data/ directory.
Extract the ACM software on the dedicated shared volume by running the following command, as root:
```
$ cd /mnt/shared/orchestrator/acm_data/
$ tar xzvf /root/acm4orchestrator-0-9.tar.gz
```
Note: You only need to run this step on one node; the /mnt/shared/orchestrator/acm_data/ directory is shared by both orchestrator servers.
Create a symbolic link by executing the following commands on both Orchestrator servers:
```
$ cd /opt/aspera
$ ln –s /mnt/shared/orchestrator/acm_data/ ./acm
```
Confirm that the file database.yml is present in the following directory:
```
/opt/aspera/orchestrator/config/
```
If you are using a distributed architecture, with MySQL running on servers that are separated from the Orchestrator servers, copy the database.yml file from the /opt/aspera/orchestrator/config/ directory on any Orchestrator server into the /opt/aspera/acm/config/ directory on any MyQL server.
Confirm that the MySQL user and password defined in database.yml match the MYSQL_USER and MYSQL_PWD values as defined in the following file:
```
/opt/aspera/acm/bin/acmcommon
```
Configure the services to run in the following directory:
```
/opt/aspera/acm/bin/acmcommon
```
By default, all services run together, as in the following example:
```
SERVICES=('APACHE' 'ORCHESTRATOR' 'MYSQL')
```
However, if you are running Orchestrator in a distributed architecture, there are additional steps.
- To run Orchestrator + Apache services only, set the following:
```
SERVICES=('APACHE' 'ORCHESTRATOR')
```
- To run MySQL services only, set the following:
```
SERVICES=('MYSQL')
```
Note: In a distributed architecture, the ACM mount points on /opt/aspera/acm/ must point to different folders on the shared systems for the Orchestrator + Apache services and the MySQL systems. This is required because SERVICES must be set differently on those systems.
For example, in /etc/fstab on the Orchestrator + Apache server, you could have the following:n
10.0.75.10:/home/mnt/shared/acm_data_orchestrator/ /mnt/shared/orchestrator/acm_data/ nfs4 rw,noac,sync,hard,intr 0 0
On the server for MySQL, you could have the following:
10.0.75.10:/home/mnt/shared/acm_data_mysql/ /mnt/shared/orchestrator/acm_data/ nfs4 rw,noac,sync,hard,intr 0 0
To configure the ACM log file to be /var/log/aspera.log, managed by the rsyslog service, on each node, modify /etc/rsyslog.conf with the following steps.
1. Add these lines at the end of the file (note that # Aspera Logging is text, not a command):
```
# Aspera Logging
local2.* -/var/log/aspera.log
```
2. Replace all cron.none occurrences with the following:
```
cron.none;local2.none
```
3. Replace /var/log/messages occurrence with -/var/log/messages
4. Restart rsyslog:
```
$ /etc/init.d/rsyslog restart
```
Set up your system to rotate the logs.
You may find that your log file, /var/log/aspera.log is growing too quickly. In that case, there are several ways to rotate Aspera logs:
- "Option A": Add /var/log/aspera.log to the following directory:
```
/etc/logrotate.d/syslog
```
- "Option B": Create an entry for aspera.log in the following file:
```
/etc/logrotate.conf
```
- "Option C": Create a separate configuration file for aspera.log in the following directory:
```
/etc/logrotate.d/
```
Option A will rotate your logs with the system logs (usually once a week, compressed, and saving the last 10 logs). However, on some servers, there is so much traffic that the logs need to be rotated more often than once a week; in that case, use Option B or C.

Option A: Add /var/log/aspera.log to the entries in /etc/logrotate.d/syslog, as follows:
```
/var/log/messages 
/var/log/secure 
/var/log/maillog 
/var/log/spooler 
/var/log/boot.log 
/var/log/cron 
/var/log/aspera.log { 
sharedscripts 
postrotate 
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true 
/bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true 
endscript 
}
```
Option B: Edit /etc/logrotate.conf by adding the configuration after the line # system-specific logs may also be configured here.

The following example compresses and rotates 10 logs whenever /var/log/aspera.log reaches 100MB. After log rotation is complete, it will run whatever scripts are specified by postrotate ... endscript.
```
/var/log/aspera.log {
rotate 10
size 100M
create 664 root
postrotate
/usr/bin/killall -HUP syslogd
endscript
compress
}
```
The following example compresses and rotates 10 logs once daily. Instead of moving the original log file and creating a new one, the copytruncate option tells logrotate to first copy the original log file, then truncate it to zero bytes.
```
/var/log/aspera.log {
daily
rotate 10
copytruncate
compress
}
```
Option C: Create a separate /etc/logrotate.d/aspera configuration file containing the same information as Option B.

If you find that logs are being overwritten before long transfers of many files are complete, you can increase the log size. For more information, see the IBM Aspera High-Speed Transfer Server Admin Guide.
Now that you have completed this procedure, you can review the steps in Setting up Aspera Cluster Manager.

Turning Off MySQL, Apache, and Orchestrator Services

Turn off the MySQL, Apache, and Orchestrator services with the chkconfig commands:

$ chkconfig aspera_mysqld off
$ chkconfig aspera_httpd off
$ chkconfig AsperaOrchestrator off

Running an ACM Sanity Check

The acmctl command has an option to check that the necessary configurations have been made that allow the acm_orchestrator script to run appropriately. You should make sure that each server passes the sanity test.

Run the acmctl command with the -s option on both nodes to verify the basic ACM prerequisites.
Note that the status of the Checking if an entry for ACM seems to exist in crontab displays as KO, not OK, in the example below, because the user has not yet created the crontab entry that will run the ACM software on each server.
```
$ /opt/aspera/acm/bin/acmctl –s

ACM sanity check
----------------
Checking if an entry for ACM seems to exist in the crontab     OK 
Checking that the orchestrator master service is disabled in chkconfig     OK 
Checking that SE Linux mode is not set to enforcing     OK
```
Correct any task that does not pass the sanity check (except for tasks with crontab status; those tasks are addressed in the next section).
Run the following command, where ip_address is the IP address of the host where the script is running:
```
/opt/aspera/acm/bin/acm_orchestrator ip_address
```
Examine the output to make sure there are no displayed errors.

Configuring the crontab Entry to Run ACM

Configure ACM services in crontab on both nodes so that the acm_orchestrator script is launched every minute.

Use the crontab –e command to configure your entry as follows.

$ crontab –e
* * * * * /opt/aspera/acm/bin/acm_orchestrator ip_address > /dev/null 2>&1

One parameter must be entered in crontab: the IP address of the host where the script is running. This parameter is passed to the acm_orchestrator script.

In the example below, the IP address is 10.0.71.21.

$ crontab –e
* * * * * /opt/aspera/acm/bin/acm_orchestrator 10.0.71.21 > /dev/null 2>&1

Once configured in crontab, the acm_orchestrator script runs regularly to determine the active node and start the required Orchestrator services on both the active and passive nodes, depending on their current status (active or passive).

Obtaining the crontab Parameter Values

To list the IP addresses available on a system, run the following command:

$ ip addr | grep "inet"
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
inet 10.0.75.21/16 brd 10.255.255 scope global eth0

To determine the correct value to use for the device number, run the following command:

$ stat -c "%d" /mnt/shared/orchestrator/acm_data/
                        20

/mnt/shared/orchestrator/acm_data/ is a placeholder for your shared storage mount point that contains ACM files.

Identifying the Status of ACM on Each Orchestrator Server

The following command can be used to identify which Orchestrator server is active and which is passive:

/opt/aspera/acm/bin/acmctl -i

For more information about using this command, see Disabling and Re-enabling ACM on One Node

Connecting to Orchestrator with the VIP

If a load balancer is providing a virtual IP address (VIP) in front of the Orchestrator servers, and the services are running properly, you can now connect to the Orchestrator application using the VIP assigned to the ACM cluster.