Background

Triofox may be deployed in scenarios that support "high availability" (HA). In general, "high availability" is achieved by deploying:

• Load Balancers - At least two HTTP/HTTPS application load balancers fronting the Triofox servers**
• Worker Nodes - At least two Triofox servers in the same "cluster"
• Databases - At least two external database servers host the Triofox database for the cluster. Triofox currently supports PostgreSQL 10.13, MySQL 5.7, and Microsoft SQL Server 2012+ database engines. PostgreSQL is the default database type.
• Storages - File shares in HA mode
• A fully qualified DNS name configured to point to the application load balancers

**Note:

• For load balancers, the Round Robin method and sticky session are recommended
• For on-prem database HA, we recommend using SQL Server AlwaysOn Availability Group

If at all possible, it would be wise to deploy the Triofox servers and database servers in separate but well-connected networks.

This diagram shows one potential scenario where Triofox is deployed at Amazon Web Services (AWS) in a single Region with two different

Availability Zones. This scenario also leverages AWS Relational Database Services (RDS) in HA mode:

A detailed explanation of this diagram is included at the end of this article in the section titled Triofox High Availability in AWS. This is just one possible deployment scenario. Triofox could be deployed in similar scenarios in Microsoft Azure or other public or private clouds.

Note that database configuration, replication, and maintenance are outside the scope of this document. Likewise, the configuration of the network and load balancers are outside the scope of this document.

There are two different "starting points" for deploying high availability:

1. Triofox hasn't been deployed yet. This is documented in the section below titled New Triofox Deployment.
2. Triofox was originally deployed in the "all-in-one" scenario where the database is deployed on the same server as Triofox. In this case, the database will need to be "migrated" from the Triofox server to an external database server. The migration process is documented separately.

The deployment of additional Triofox servers is the same regardless of the "starting point". See the section below titled Deploying an additional Triofox server in the cluster.

New Triofox Deployment

For new Triofox deployments, it is recommended that the latest version of Triofox be deployed (at least 12.5 or later).

Deploying the first Triofox server in the cluster

1. Prior to installing Triofox, you must create an empty database in PostgreSQL or Microsoft SQL Server. If using Microsoft SQL Server, the server must be configured to allow "SQL Authentication" as Triofox does not support Windows Integrated Authentication. A user account must be created for Triofox with full access to the database (i.e. "db_owner"). The database should be configured for high availability.
2. Triofox version 12.5 and later will display this page when navigating tohttp://localhost during the initial configuration of the server:
3. Clicking on the default - all in one drop-down displays:
4. Selecting Postgresql from the drop-down will display:
5. Selecting SQL Server from the drop-down will display:
6. Selecting "Mysql" from the drop-down will display
7. Select the engine from the drop-down (either PostgreSQL, MySql, or SQL Server) that matches your HA database deployment and fill in the text boxes with the information appropriate to your deployment.
8. After the installation has been completed, update the worker node configuration, setting the FQDN of the cluster to match the FQDN that resolves to the load

Deploying an additional Triofox server in the cluster

1. Install the same version of Triofox on the second server.
2. After installation, use the browser to navigate to http://localhost
3. Because it is a new installation the browser will be redirected to http://localhost/management/admindatabase.aspx
4. Select the same database engine with the same database configuration options as the first server.
5. The Triofox sign on page will be displayed
6. After signing in this http://localhost/managment/ClusterMgr.aspx page will be displayed. If not, please load the link directly.
7. Follow the same instruction in the "New Triofox Deployment" to set up External URL

Triofox High Availability in AWS

This section will describe the diagram at the beginning of this article. The same diagram is included here for easy reference:

A Triofox cluster could be deployed in AWS for high availability. At a high level, this diagram shows a single AWS Region with a single AWS Virtual Private Cloud(VPC) that spans two Availability Zones. Each Availability Zone contains two subnets, one Public facing and another Private.

The AWS RDS instances are deployed with network interfaces assigned to the Private subnets because there should be no need to access the RDS databases directly from the Internet. The Triofox servers are deployed with their network interfaces in the Public subnet because they will be accessible from the Internet. Likewise, the Application Load Balancers are deployed with network interfaces in the Public subnets as they will typically service any client using HTTPS (TCP 443).

At least three different VPC Network Security Groups (NSGs) should be deployed to secure traffic to these resources. For example, the RDS instances would only allow database traffic from the Triofox servers. The Triofox server would only allow HTTP/HTTPS from the load balancers, plus potentially RDP traffic from specific IP addresses. The load balancers would allow HTTP/HTTPS from any address (0.0.0.0/0).

Triofox supports the following AWS RDS instances types:

• Aurora PostgreSQL 10.13
• Aurora MySQL 5.7
• PostgreSQL 10.13
• MySQL 5.7
• Microsoft SQL Server 2012 and later