View Source

Standard Configuration

The standard Chorus deployment is compatible with all major, and many smaller cloud environments. It requires:

An x86-64 or arm64 instance
Debian 10 image
4+ cores
16GB+ RAM
30GB+ SSD block storage
Bulk HDD-backed block storage (e.g. AWS EBS, Azure Standard HDD, GCP Persistent Disk)
Inbound network access on HTTP/80, HTTPS/443, and optionally SFTP on 2200 or 2222

This deployment model works in exactly the same manner as a Chorus DCE installation on-premise. The entire OS and application stack is managed by the Chorus software, with no external service dependencies.

Refer to Supported Hardware for guidance on sizing instances against storage requirements, or contact us for specific recommendations.

High Availability

The Chorus software includes native clustering support for large, highly available platforms. For on-premise installations, this requires independently operated database and storage systems, but these are available in the public cloud as managed services.

For a cluster deployment, you will need licences for each planned cluster node - contact your account manager to discuss licensing options.

A high-availability deployment on AWS can avoid any single point of failure, or endure the failure of an entire availability zone, and comprises:

Amazon RDS for MariaDB 10.4.x
- Choose the optional Standby instance for automatic failover
- We typically recommend m6g instances, to support CPU-intensive search operations.
- io1 SSD will normally be required for the IO density - the minimum 20GB storage will be sufficient in many cases, but at least 100 IOPS will be consumed even for a minimally sized cluster at idle.
- Create a parameter group for Chorus, including the following settings
  - max_prepared_stmt_count = 500000
  - sql_mode = NO_ENGINE_SUBSTITUTION,NO_AUTO_CREATE_USER
  - table_definition_cache = 100000
  - time_zone (select the same time zone as used for your Chorus application servers)
Amazon MQ for RabbitMQ
- For high-availability, choose the cluster deployment option.
- mq.m5.large is sufficiently sized for almost all deployments
- Consider a single-instance mq.t3.micro for smaller deployments, as the cost of 3 mq.m5.large instances may be excessive relative to the rest of the cluster
EFS
- Use lifecycle management to automatically tier storage for lower effective cost/GB
- Add Network access mount targets in at least two availability zones
Administrative Chorus instance
- Debian 10 base
- Refer to the installation guide for repository setup instructions
- Mount the EFS volume at /space (see the AWS documentation under "Attach")
- In the installer, choose:
  - Cluster Deployment: yes
  - Cluster Role: master (note the cluster joining key)
  - Use External Database: yes (provide the RDS details)
  - Use Separate RabbitMQ: yes (provide the AmazonMQ details - note use SSL: yes)
  - Run Background Tasks: no
- Configure a valid, verifiable SSL certificate for the admin node. This can be done via the Chorus Manager UI accessing this node
Standby Chorus daemon instance
- Separate AZ to admin instance
- Debian 10 base
- Refer to the installation guide for repository setup instructions
- Mount the EFS volume at /space (see the AWS documentation under "Attach")
- In the installer, choose:
  - Cluster Deployment: yes
  - Cluster Role: standby
  - Run Background Tasks: no
  - Join Cluster: FQDN of the administrative instance, matching its SSL certificate
  - Cluster Passphrase: (the value provided when installing the admin instance)
Chorus webservers (2+ instances, across the availability zones in use)
- Debian 10 base
- Refer to the installation guide for repository setup instructions
- Mount the EFS volume at /space (see the AWS documentation under "Attach")
- In the installer, choose:
  - Cluster Deployment: yes
  - Cluster Role: worker
  - Run Background Tasks: no
  - Join Cluster: FQDN of the administrative instance, matching its SSL certificate
  - Cluster Passphrase: (the value provided when installing the admin instance)
Chorus background processing servers (2+ instances, across the availability zones in use)
- Debian 10 base
- Refer to the installation guide for repository setup instructions
- Mount the EFS volume at /space (see the AWS documentation under "Attach")
- In the installer, choose:
  - Cluster Deployment: yes
  - Cluster Role: worker
  - Run Background Tasks: yes
  - Join Cluster: FQDN of the administrative instance, matching its SSL certificate
  - Cluster Passphrase: (the value provided when installing the admin instance)
Application Load Balancer (HTTPS)
- Configure backends of the web server nodes
- Configure frontend SSL
- Specify the availability zones in use for the Chorus cluster nodes
Network Load Balancer
- Configure port 80 to forward to the web server nodes
- Configure port 443 to forward to the ELB instance
- Configure port 2200/2222 to forward to the web server nodes (optional, for SFTP)
Security Groups
- Chorus (SG containing all cluster nodes)
  - Outbound traffic to the Chorus-DB SG for MySQL (TCP/3306)
  - Outbound traffic to the Chorus-MQ SG for AMQPS (TCP/5671)
  - Outbound traffic to the Chorus-EFS SG for NFS (TCP/2049)
  - Outbound traffic to the Chorus-SGT SG on TCP/18000-18999
  - Outbound traffic to the Chorus-ADM SG on TCP/8401
  - Outbound traffic to the Third Light Update server, updates.thirdlight.com (currently 5.153.64.81) for HTTP/HTTPS (TCP/80 and TCP/443)
  - Outbound traffic to the Chorus SG for ICMP echo request/echo reply
  - Inbound traffic from the Chorus SG for ICMP echo request/echo reply
  - Inbound traffic from the Chorus-SGT SG on TCP/18000-18999
  - Inbound traffic from the Chorus-ADM SG on TCP/22
- Chorus-SGT (SG containing the admin and standby nodes)
  - Outbound traffic to the Chorus SG on TCP/18000-18999
  - Inbound traffic from the Chorus SG on TCP/18000-18999
- Chorus-ADM (SG containing just the admin node)
  - Outbound traffic to the Chorus SG on TCP/22
  - Inbound traffic from the Chorus SG on TCP/8401
  - Inbound traffic from your admin network for SSH and HTTPS (TCP/22 and TCP/443)
- Chorus-DB (SG used for the RDS instance)
  - Inbound traffic from the Chorus SG for MySQL (TCP/3306)
- Chorus-MQ (SG used for the AmazonMQ instance)
  - Inbound traffic from the Chorus SG for AMQPS (TCP/5671)
- Chorus-EFS (SG used for the EFS Network Access targets)
  - Inbound traffic from the Chorus SG for NFS (TCP/2049)
- Chorus-WEB (SG used for the web server nodes)
  - Inbound traffic from the Chorus-ALB for HTTPS (TCP/443)
  - Inbound traffic from the Chorus-NLB for HTTP and SFTP (TCP/80, TCP/2200 and TCP/2222)
- Chorus-ALB (SG used for the Application Load Balancer instance)
  - Inbound traffic from the Chorus-NLB SG for HTTPS (TCP/443)
  - Outbound traffic to the Chorus-WEB SG for HTTPS (TCP/443)
- Chorus-NLB (SG used for the Network Load Balancer instance)
  - Inbound traffic from everywhere on TCP ports 80, 443, 2200, 2222
  - Outbound traffic to the Chorus-WEB SG for HTTP and SFTP (TCP/80, TCP/2200 and TCP/2222)
  - Outbound traffic to the Chorus-ALB SG for HTTPS (TCP/443)

The Chorus application server instances here should all be on the same architecture - we recommend that they be m6g (arm64) instances, but they can be m6i/m6a (x86-64) instances. m6g.xlarge instances provide a good amount of memory per node, and are suitable for constructing a moderate sized cluster by scaling the number of web and background nodes appropriately. m6g.large can be used for a smaller cluster, with a reduction in maximum processable pixel dimensions of stored images.

If the admin node is unavailable, it will not be possible to deploy software updates, join additional nodes to the cluster, and some periodic scheduled tasks will not run, but there is no impact on availability. This node should be restored before attempts to modify the configuration are made - contact support for assistance in reinstating this node if it is totally lost.

FAQs

Q: Is it possible to use a read replica database?

A: Provided replication lag is consistently less than 5s, it is possible to use a read-replica for searching. Typically, however, this is not a useful configuration as the replica also needs to have a standby to maintain HA, so it is usually preferable to simply deploy a more powerful instance type for the writable database. It is not possible at the present time to provide a list of database instances to achieve HA with multiple independent read replicas. If you would like to pursue this option, please discuss the specifics of your requirements with us.

Q: Is Amazon Aurora supported?

A: No. Amazon Aurora, in MySQL compatible edition, still has important behaviour differences which cause issues with non-unique UUIDs.

Q: Can S3 be used instead of EFS?

A: No. Chorus requires a block-level filesystem, so S3 isn't currently supported. It is technically possible to mount S3 as a virtual filesystem (s3fs), but this is not recommended - the filesystem compatibility layer adds significant performance penalties, and it can generate large numbers of S3 requests.