Introduction to IBM Aspera HSTS Highly Availability Cluster:
- In this blog, we would learn about the Aspera HSTS and its Clustering method in order to save the failover time and stable the server continuously.
Introduction to Aspera High-Speed Transfer Server( HSTS):
- It stands for High-Speed Transfers Server used to move or transfer a large set of data like TBs of Streaming data from one end to another end throughout the world.
- IBM Aspera has the patented technology FASP protocol through which the data transfers with deliverable speed is maximum compared to the traditional TCP protocol with the maximum utilization of available bandwidth.
- IBM Aspera is a Core Transfer engine application through which the transferable data is pushed into the server.
- it is connected to various transfer applications through which the data is moved to its core engine.
Introduction to Aspera HSTS High availability cluster:
- Aspera HSTS HA clustering is based on the concept of application cluster, in order to reduce the failover time and for continuous availability.
- The basic concept of the highly available cluster for Aspera HSTS is that there should be a minimum of 3 Aspera HSTS servers in order to pass the pre-requisite of High Availability.
- Here is why we need a minimum odd number of HSTS servers, the reason behind this is if one HSTS server is down for any external reason or any system failure occurs then immediately HSTS server in that group will take over and it acts as a primary server for transfers.
Prerequisites for Aspera HSTS High Availability Clusters:
- The primary pre-requisite of an HSTS high availability cluster is that there should be a minimum odd number of HSTS servers. The Minimum is 3.
- All three HSTS servers must be having common shared storage in order to store the delivery content transferred by HSTS client applications.
Features of Aspera HSTS High Available Cluster:
- Aspera HSTS server contains robust and reliable database software built-in during HSTS installation.
- Redis database is consistent throughout time.
- Redis has an advantage, can take snapshots in regular time intervals.
- Automatically passes primary failover HSTS to replica HSTS server that can act as the primary server for High availability.
Explanation of Aspera HSTS High Availability Cluster:
We will have 3 HSTS servers with common shared storage, we would select any of the HSTS servers that would act as primary and the rest as the replicas.
We could consider one HSTS server as a master node that contains all the details of the HSTS servers like the primary server and replicated servers.
HSTS uses hiredis as a Redis client to interact with Redis database.
Redis Sentinel monitors the Redis database and shifts the control to replicated servers if the primary server failover.
When an HSTS cluster is configured successfully we can test it by creating an Aspera HSTS node on any of the servers whether it is primary or the replicated server, that node API would be reflected in all the servers in a cluster, the same thing occurs for deletion if we delete the node API, it would be deleted in the all of the servers.
This is how the HSTS cluster environment is set up with highly available servers whenever a failover occurs or the primary HSTS server fails due to any reason, Redis database would help, and with a minimum time of 5 minutes, the replicated server takes control and becomes the primary server.