| 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.