Content by Ashwarya Jagati

Making life easier with IBM Aspera on Cloud - part 2

Sometimes, small issues that seem unsurpassable and disrupt our work, can be easily resolved with a little more familiarity with the IBM Aspera on Cloud environment.

Below are a few common issues users encounter in IBM Aspera on Cloud, along with the workarounds.

These may be used as reference guidelines or treated as frequently asked questions.

FAQ 1 : Date Format Mismatch

Question:

The time zone and date format on my machine are set to the European standard (dd/mm/yyyy). However, on the Files or Packages page in IBM Aspera on Cloud, dates are displayed in the American format (mm/dd/yyyy), which can be confusing when interpreting timestamps.

Possible causes:

1. The “Default Language setting” under Account settings page is not configured  to “Use system default” Please refer to the below screenshot:
   
   
   

    

2. Your system’s default language/locale is set to a value not supported by IBM Aspera on Cloud the language will default to English US.

You can create a support ticket after checking these.

FAQ 2:

Question:

We know that Aspera Async supports synchronization with AWS S3 storage, but can it also support synchronization with Alibaba Cloud OSS?

Answer:

While Alibaba Cloud OSS is a valid storage option for HSTS, it must first be added as the docroot storage to be used.

Refer to the following link for instructions on configuring the docroot with Object Storage:
https://www.ibm.com/docs/en/ahts/4.4.x?topic=reference-setting-docroot-object-storage

FAQ 3:

Question:

In IBM Aspera on Cloud, when a package is uploaded to a tethered transfer server (on-premises), is the content directly accessible from the local storage (assuming no encryption), or can the files only be retrieved by downloading them through the IBM Aspera on Cloud console?

If the uploaded package is already stored at its intended destination (i.e., the local storage), I’d prefer to access it directly to avoid generating additional transfer volume. What is the expected behaviour in this scenario?

Answer:

Files uploaded to a tethered transfer server are locally accessible if they're not encrypted.

FAQ 4:

Question:

As an admin can I see my users’ files stored in IBM Aspera on Cloud?

I have a heap of files owned by user accounts that are deactivated and they need review the content and cleanup the data. 

Answer:

Yes, and no.

A user with only admin permissions and their own login cannot directly access files owned by other users in IBM Aspera on Cloud. However, if an admin (or any user) has the access key and secret for the node where the workspace resides, they can access all files in that storage, including those owned by deactivated users.

If a file was encrypted at rest by the original user, no one else, not even an admin can decrypt it unless they have the decryption key.

For cleaning up files from deactivated users, admins can perform storage-level cleanup by deleting home directories if they have the node credentials (access key and secret). These are provided in a special onboarding package to the primary admin when the IBM Aspera on Cloud instance is first provisioned.

Steps to delete the home folder:

Step 1) Navigate to the admin app, navigate to Nodes and storage and search for the node.

For nodes where node ownership is restricted to "Only ATS Admins", and the user is an Org Admin, the node secret must be entered to gain access (as in the below screenshot).

However, if the node ownership is set to "All Admins", then:

• An ATS Admin or Org Admin can access the node without entering the node secret. An ATS Admin can always directly navigate to the home folder and delete it as needed. With the simplified folder sharing feature, based on the node ownership settings, admins can access the nodes without needing to manually enter the node secret.

Step 2) Go to the user’s home folder and delete it.

Note: Be cautious while deleting as this action cannot be undone and the deleted folders are permanently removed without recovery.

FAQ 5:

Question:

How Does IBM Aspera on Cloud Scale with Increasing number of transfers?

Answer:

As transfer volumes grow, IBM Aspera on Cloud provides multiple options to scale and maintain high performance:

1. Scaling on Virtual Machines (VMs):
   Customers using VMs can increase the allocated resources (CPU, memory, network) to allow each node to handle more concurrent sessions and transfers.
   
   
2. Scaling on Bare Metal:
   When deploying on bare metal servers, it’s best to choose hardware with expansion capacity in mind. For example, if the initial requirement is 4 CPU cores, we recommend provisioning 8 cores upfront to accommodate future growth. Customers can then simply upgrade licenses to unlock additional capacity. Once hardware limits are reached, proceed to option 3.
   
   
3. Clustering with Load Balancers:
   For very large-scale environments (e.g., multi-Gbps transfer speeds) or when a single server's hardware limits are reached, customers can deploy a cluster of High-Speed Transfer Servers (HSTS) behind load balancers. This distributes concurrent transfers across multiple nodes, increasing overall capacity.
   
   
4. HSTS in CP4I (Cloud Pak for Integration):
   HSTS instances deployed within CP4I offer built-in scalability by adding more resources or pods to facilitate expansion.
   
   
5. Handling Slow Networks with Growing Client Numbers:
   Each HSTS node, whether VM or bare metal, has a limit on the number of concurrent transfers it can efficiently manage. While there are no benchmarks or documents for this concurrency limit, distributing load across multiple nodes as evenly as possible balances the load and improves throughput.
   
   

Note: Each node requires a dedicated license, and bandwidth caps are often part of license terms.

Knowledge is the key to unlocking the full value of your product. Stay tuned for more tips and insights from IBM Aspera on Cloud.