Flow Production Tracking cluster topologies
Local installations of Flow Production Tracking are no longer offered. This documentation is intended only for those with existing instances of Flow Production Tracking Enterprise Docker. Click here for a list of our current offerings.
This article gives an overview of the different configurations of Flow Production Tracking Enterprise Docker.
Flow Production Tracking Cluster
Flow Production Tracking Enterprise Docker (SE Docker) can be configured and deployed in many different ways. Flow Production Tracking components can be spread out on multiple servers, allowing Flow Production Tracking to scale with users and load.
Single server - Standard configuration; all of Flow Production Tracking components running on the same server.
Standalone DB - Database running on its own server. Recommended if you expect more than 100 users.
Standalone API and DB - In this configuration, API (script) requests are handled by a dedicated server. The database is also running on its own server. Intended for heavy API users.
Fully exploded - Flow Production Tracking can scale heavily by increasing the number of App Servers handling requests. Memcached and the Transcoder can also be running on dedicated servers.
Flow Production Tracking topology can be modified later on if the limitations of the initial setup are reached, but it requires downtime.
Multiple App Servers and API Servers can be set up, but these kind of configurations are usually reserved for advanced users. If you feel that you should have an advanced setup, let us know in your setup support ticket and we will discuss the options.
Staging cluster
It is mandatory to have a staging cluster for local install clients. Staging clusters are enforced for many reasons:
- It allows testing of any modifications before applying them in production.
- It allows you to test your scripts and workflows without impact on your production.
- It allows testing of data migrations when the Flow Production Tracking version is updated, to make sure there will be no issues migrating your production data.
The main goal of a staging cluster is to prevent, as much as possible, the chances of having downtime due to upgrade operations. We recommend having a dedicated cluster for staging, using the single server topology, but other options are available, like hosting the staging site in the same hardware as production. Let us know in your support ticket if you are interested in other options.