| Highly-Available Redis Backend for an HST Server Cluster |
306
Option
Required
Type
Description
--expires-at
Optional
UTC time
The expiration date of
the bearer token in UTC
format. For example,
2016-06-23T13:21:58.453Z.
Default expiration is 1 hour
after token creation time.
--scope-role
Optional
String
The access level of the
bearer token. Value can be
admin
(default) or
user
.
admin
can change the
access key configuration,
user
cannot.
--token-key-length
Optional
Double
The length of the RSA
key. Must be a power of
2 between 1024 bits (128
bytes) and 16384 bits
(2048 bytes). Default key
length is 4096 bits.
Highly-Available Redis Backend for an HST Server Cluster
A guide to configuring a highly-available Redis database that is used by all HST Servers in a cluster.
Introduction
HST Server can be deployed as a high-availability cluster. This is done by configuring a Redis database cluster and
using HAProxy to connect the HST Servers to the Redis database. The Redis and HAProxy applications are included
in your HST Server installation.
Overview
Deploying HST Server as a high-availability cluster enables you to leverage the high-speed transfer capabilities of
Aspera with continuous availability and automatic failover if one node goes down.
A cluster consists of
nodes
. A node is a machine (physical, virtual, or container) on which IBM Aspera High-Speed
Transfer Server and Redis are installed. A Redis node can be a primary (also called a "master") or replica ("slave").
Cluster Architecture
In an HST Server cluster with a highly-available Redis backend:
• Each node has HST Server, Redis, and HAProxy. HST Server uses the
Redis database
to manage security and
transfers. In a cluster configuration, all HST Servers use the Redis database on the primary node, which is cloned
to the replica nodes.
• HST Server uses
Hiredis
, a Redis client, to interact with the Redis database.
• To direct Hiredis requests from all the HST Servers to the primary Redis node, the cluster uses
HAProxy
, a TCP
proxy, to identify which Redis nodes are running and which is the master.
•
Redis Sentinel
monitors the status of the Redis databases, communicates between Redis nodes, and automatically
promotes a replica to primary if the primary is failing.