This section describes various CloudBees Flow behaviors and possible modifications that you may want to make in your CloudBees Flow configuration.
In a default installation, an agent is installed alongside the CloudBees Flow server, and a resource named local is automatically created for the agent. In a cluster, the local resource points to only one node. By default, some of the plugins and sample code installed with CloudBees Flow automatically use the local resource because it is usually present.
Many CloudBees Flow users also write procedures that use the local resource for these reasons:
A user knows the local resource exists.
The user needs local access to the file system, such as access to the log files or configuration files.
The user needs local access to resources on the CloudBees Flow server to perform tasks such as checking the CPU, memory, or disk space usage.
Any existing procedures for local access to CloudBees Flow server file systems or resources need to be modified when you change your installation to run in a server cluster. There are now multiple CloudBees Flow server nodes, each with their own log files, configuration files, and local resources. The name of the CloudBees Flow log file on a CloudBees Flow server node in a cluster has also been changed to
commander-<hostname>.log to facilitate collecting the multiple logs together without them overwriting each other.
CloudBees Flow does not support the local host IP address (127.0.0.1) for any CloudBees Flow configuration, because it is ambiguous when multiple servers are used.
If you are using clustering for performance reasons, you must manage your machine resources efficiently. You use additional machine resources if you run a CloudBees Flow agent and CloudBees Flow server on the same machine. If you are concerned about performance, remove any agents from your CloudBees Flow server node machines. You should also verify that any agents that may have been installed as part of an earlier configuration are also removed. An agent is installed automatically with any CloudBees Flow service by default.
If you are using clustering only for reliability reasons, you must reduce or eliminate single points of failure. In this configuration, having a single server node that runs the local agent is counterproductive. If you need a more reliable configuration, you can install agents on all of your CloudBees Flow server node machines and put them in a resource pool named local . Local agents should be used for broadcast and maintenance type work. See Agent Resource Strategies for more information.
If you have a local agent on each CloudBees Flow server, it may be appropriate for some procedures to have one or more procedure steps that are broadcast across all the resources in the local resource pool. These procedure steps are probably followed by a step that aggregates the resulting data in an appropriate way. For other procedures, it may be more appropriate to use the shared file system to which all the CloudBees Flow servers have access, and still have the step run on a single agent.
If you do not have any agents local to any of your server machines, a local resource is not automatically created. There are two possible strategies to handle this:
Do not have a local resource and remove any local resource on your system. For everything that is currently configured to use the local resource, reconfigure them to use other resources.
Create a resource pool called local for agents on non-CloudBees Flow-server machines. Everything that is configured to use the local resource now runs on an agent of the local pool. However, this agent is no longer local to any of your CloudBees Flow server nodes.
If anything relies on the local resource being local to the server, it must be modified to work across multiple server nodes, to function remotely from an agent running on another machine, or to be both. In some configurations, you may need to use the shared file system between the CloudBees Flow servers and the remote agent.
For example, if you want to write log-parsing procedures using nonlocal agents, you can configure all of your CloudBees Flow servers to write their logs to different locations in this shared file system. A procedure step running on a remote agent machine with access to this shared file system can then parse all the server logs.
The built-in database is not supported in a clustered CloudBees Flow configuration. You must use an alternate database listed in Supported Alternate Databases : Oracle, MS SQL Server, or MySQL.
The contents of the DATA_DIRECTORY/broker-data directory can never be shared between nodes in a CloudBees Flow cluster.
This may occur when a virtual machine running a CloudBees Flow server is cloned, and the DATA_DIRECTORY/broker-data directory is also cloned as part of the cloning operation.
If this occurs, remove the DATA_DIRECTORY/broker-data directory from the new virtual machine (VM) as follows:
Shut down the CloudBees Flow server on the new VM.
Delete the DATA_DIRECTORY/broker-data directory on the new VM.
Restart the server on the new VM.