To improve data throughput and provide basic fault tolerance, you can configure multiple FlowForce Server instances to run as a cluster. This provides the following benefits:
•Leaner resource management
•Reduced risk of service interruption
|Note:||Cross-system clusters are not supported, which means that a worker-master connection cannot be established between different OS platforms (e.g., between Linux and Windows).|
When hardware limits cause FlowForce Server to be overwhelmed by multiple job instances running simultaneously, it is possible to redistribute workload to another running instance of FlowForce Server (a so-called "worker"). You can set up a cluster comprised of a "master" machine and multiple "worker" machines and thus take advantage of all the licensed cores in the cluster.
One of the machines designated as a "master" continuously monitors job triggers and allocates queued items to workers, or even to itself, depending on configuration. You can control the queue settings and decide, for each job, the queue where it should be assigned. For example, you can optionally configure the master machine not to process any job instances at all and thus free up its resources and dedicate them exclusively to continuous provision of FlowForce Service as opposed to data processing.
You can restart or temporarily shut down gracefully any running instance of FlowForce Server that is not the "master", without interrupting provision of service. Note that the "master" is expected to be available at all times; restarting or shutting it down will still interrupt provision of service.
In case of disasters such as hardware failures, power outages, unplugged network cables, and similar, the impact depends on whether the affected machine is a "worker" or a "master":
•If the machine is a "worker", any running FlowForce job instances on that worker will be lost. However, general provision of FlowForce service will not be lost, because new instances of the same job will be taken over by a different worker (or by the master, if configured). The execution status of the job, including failure, is reported to the master and visible in the job log, so that an administrator can take appropriate action manually.
•If the machine is a "master", provision of service is lost. In this case, new job instances cannot start as long as the master is unavailable.