Shares On Demand (SHOD) Migration Procedure

Overview

This article is for customers who wants to migrate their SHOD (Shares On Demand) from one instance to another.   This procedure will only work when migrating to the same release version.  If you are on an older version of Shares and want to migrate to a newer version, please contact Aspera Support for details.

If you are still investigating Aspera on Demand options and want to learn more, please view the Aspera Cloud site for more info.

 

Migration Procedure

1) Connect to your SHOD from a Terminal/Command Prompt via SSH as root

#  ssh -i [customer's perm] -p 33001 ec2-user@[ec2 host IP]
# sudo su -

If you are not sure how to login to your Aspera Server, please see this article.

 

2) Back up the existing data and configuration files

a. Back up your Shares application and data

# mkdir /backup
#  /opt/aspera/shares/script/rake.sh backup DIR=/backup

 

b. Back up your purchased SSL certificate files (if applicable)

 If you have your own purchased SSL certificate, please  back up the files by running the following commands.

# cp /opt/aspera/shares/conf/cert.key  /backup/cert.key
# cp /opt/aspera/shares/conf/cert.pem /backup/cert.pem

 

c. Obtain Customer ID and Entitlement ID

You need to know your customer ID and entitlement ID to entitle the new system.  If you don't know these ID's, you can find out by running the following command.

# /opt/aspera/bin/alee-admin register  <enter> <enter>

 

d. Zip up the "/backup" directory and move the file to a location where you can access from your new system

 

3) Launch a new SHOD instance with the same SSH Key, Region and Security Group and entitle the new system

If you are not sure how to launch a new AMI, please see this article

 # /opt/aspera/bin/alee-admin register CustomerID EntitlementID

 For example,

 # /opt/aspera/bin/alee-admin register AsperaTest 54321e1234-1a1b-111a-ab1c-a1234567b111

 

4) Restore the new machine

a. Create system accounts and transfer accounts via Aspera Console.

You can skip this step if you just use the default user accounts/group and didn't create any additional users on your old machine.

Login to your new SHOD as admin, click Aspera Console

Login to Aspera Console as admin, go to Nodes ->edit ->Accounts -> Add User

 add_new_user_in_console.jpg

b. Via Aspera Console, make sure the docroot for all the users are the same as the ones on the old system.

 

c. Restore Shares configuration and data

Move the backup file from the old system to the new system and run the following command.

# /opt/aspera/shares/script/rake.sh restore DIR=/path/tothe/backupfiles

 

d. Restore SSL Certificate files

You can skip this step if you use a self-signed certificate.  This step is only necessary if you have a purchased SSL certificate.

Rename your exisiting SSL files

# mv /opt/aspera/shares/conf/cert.key  /opt/aspera/shares/conf/cert.key.org
# mv /opt/aspera/shares/conf/cert.pem /opt/aspera/shares/conf/cert.pem.org

Copy your back up SSL files to /opt/aspera/shares/conf

# cp  cert.key /opt/aspera/shares/conf/
# cp  cert.pem /opt/aspera/shares/conf/

Restart Nginx

# /etc/init.d/aspera_shares_nginx restart 

 

 e. Restore the hostname of  your Shares

You can skip this step if you DO NOT have a hostname for your server.  This step is only necessary if you use a hostname rather than an IP address to connect to your server.

Update the hostname using the following command:

# asctl apache:hostname transfer.aspera.com

     Note: DO NOT install new SSL cert when prompted as the cert has been moved over.

 

 f. Update the <server> section in aspera.conf to reflect the new hostname

You can skip this step if you DO NOT use a custom hostname for your server.

<server>
    <server_name>transfer.aspera.com</server_name>
</server>

 

 g. Add new Node users

You can skip this step if you use the defult user setting.  This is only necessary if you added additional Node users on the original system.

#  /opt/aspera/bin/asnodeadmin -a username

 

 h. Restart the background service

#   /etc/init.d/aspera_shares_delayed_job restart

 

5) Migrate the Elastic IP address from the original Shares to the new Shares

You can skip this step if you DO NOT use Elastic IP address for your server. If you use a unique hostename with a dynamic IP address, you will need to update your DNS entry.  The following steps are only necessary if you use an Elastic IP address from AWS.

      a) Use the AWS interface to reassign the Elastic IP from the old instance to the new instance.

      b) Navigate to AWS Elastic IP menu.

      c) Select the IP address and disassocitate the address from the old Shares instance

      d) Select the IP address and associate Address with the new Shares instance

 

6) Log into your new Shares

Use your original admin account and password to login to your new Shares and update your nodes with the new node user password.  By default, the password is your instance ID.

Node_Edit.png

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk