Runtime cluster and cloud local storage

You can improve performance and resiliency for runtime clusters and runtime clouds by using local storage for working data and runtime assets. When enabled, certain files are stored or copied to a local directory within each cluster node instead of reading and writing to the shared files system.

Boomi highly recommends using local storage for clustered runtimes. You can enable this for existing runtimes within the Runtime Management screen by selecting the Use Local Storage for Runtime Assets setting on the Properties panel’s Basic tab. For new runtimes, you can enable local storage during installation. Refer to the topic Enabling Local Storage for a runtime cluster or runtime cloud.

Types of assets elegible for local storage:

• Working data - Temporary files used during integration process executions. Long-term execution history is still stored on the shared file system.
• Boomi runtime libraries - Core JAR libraries included in the runtime installation.
• Connectors - Connector artifacts.
• Custom libraries - User-deployed custom JAR files.
• Java JRE/JDK - Java runtime if using the Boomi-supplied Java installation.

Considerations for working data

• By default, working data is stored in the shared file system within the runtime installation directory as follows.
  • Runtime clusters and runtime clouds store working data in their data and tempdata directories.
  • Multi-tenant runtime clouds store attachment-specific working data in an account-specific directory. For example: \<Atom\_Cloud\_installation\_directory\>/accounts/account-123456.890ABC
• When local storage is enabled, the data, tmpdata and attachment-specific working data will be restored in subdirectories, under the configuration Working Data Local Storage Directory.
• In rare situations, you can set a different working data storage location for each node in a runtime cluster or runtime cloud within a node-specific container.properties file. Refer to the topic Add a Node-Specific container.properties file.
• A sub directory of the Shared File System (SFS) cannot be used as Working Data Local Storage Directory.
• Do not use the system’s /temp directory as the local working data storage location because this directory may be purged by the operating system in a way that can interfere with process execution.
• If Working Data Local Storage Directory is configured but Use Local Storage for Runtime Assets is not enabled, only the working data files will be persisted to the local node. This could be the case for runtimes installed prior to the availability of the Use Local Storage for Runtime Assets property. We recommend enabling this setting for all clustered runtimes.

Partitioned storage for multi-tenant runtime clouds for working data

You can configure multi-tenant runtime clouds to use partitioned storage for account-specific working data. With partitioned storage, account directories are spread among multiple shared network directories instead of all residing in the runtime cloud installation directory. This spreads network I/O load across multiple file servers and allows independent backups and restores of smaller subsets of accounts. If configured, this will override the Working Data Local Storage Directory.

To enable and configure partitioned storage for a runtime cloud, set the Account Working Data Directories property (com.boomi.container.accountsDirs) in the runtime cloud’s Properties dialog to specify multiple shared network directories, separated with a semicolon. For example com.boomi.container.accountsDirs=\\\\fileserver1\\Cloud\\accounts;\\\\fileserver2\\Cloud\\accounts. Refer to the Enabling Partitioned Storage for a runtime Cloud topic.

When partitioned storage is enabled, account directories are spread between the specified locations for load balancing that is based primarily on the amount of free disk space and secondarily on the count of previously assigned accounts. As new accounts are added to the runtime cloud, they are assigned to the specified locations based on the same criteria.