Runtime cluster installation checklist (Linux)

Before you can install the runtime cluster on Linux, ensure that your computer meets the system requirements, you synchronize clocks, you consider failover and disaster recovery needs, and you configure NFS storage.

Check runtime cluster system requirements

Check the runtime cluster’s system requirements.

Synchronize clocks and time zones

Ensure that the clock on all runtime cluster nodes, including central storage services (such as NFS), synchronize regularly using a Network Time Protocol (NTP) server. However, suppose the clocks on the machines are not closely synchronized. In that case, you are likely to encounter problems with:

• Clustering protocol
• Accurate time recording for cross-node action
• Accurate handling of files on the shared file system

Ensure that you set all machines to use the same time zone, including the devices on which the runtime cluster nodes run and the file servers you use. Refer to your operating system’s documentation for instructions on setting your machines’ time zone.

Consider failover and disaster recovery needs

For information about backup and disaster recovery best practices for runtime clusters and runtime clouds, review the following resources in the Boomi Community:

• Best Practices for Run Time High Availability and Disaster Recovery knowledge article
• Backup and Disaster Recovery video

If you take point-in-time snapshots of your systems with a tool such as VMware, you do not have to take images of the nodes in a runtime cluster or runtime cloud. The nodes do not contain any valuable information beyond operating system settings. However, if you want to take a snapshot of a runtime cluster or runtime cloud node, do so only once at setup time and before starting the node.

Note: Boomi does not recommend taking snapshots of runtime cluster or runtime cloud nodes on an ongoing basis. Doing so can negatively impact the node's operational stability.

Configure NFS storage

• Ensure that you enable the nfslock daemon at startup and is running on the NFS client nodes.
• Ensure that you mount central storage in the same path on all nodes and that the runtime cluster or runtime cloud service account has write access to the path.
• Ensure that you correctly identify users and groups across mounts. For example, viewing file details in NFS mounted directories displays valid user and group names.
  • The idmapd daemon often controls NFSv4. Ensure this is enabled and running on each node and NFS server.
• Leverage mount options that support binary execution through the share.
  • NFS client /etc/fstab example: vers=3,noatime,nodiratime,rw,hard,intr,bg,addr=nfsserver.domain.com
    • vers= — Specifies the NFS version the server must support. Depending on the client or server setup, this option might not be necessary.
    • noatime — Disables access time tracking on files. This information is generally unnecessary to maintain and can waste nontrivial I/O bandwidth.
    • nodiratime — This option is the same as noatime except for directories.
    • rw — Requires read and write access by the runtime.
    • hard — Requires NFS client operations to complete. Not using this option might cause silent data corruption.
    • intr — Allows signals to interrupt NFS operations. This prevents the system from stopping if the NFS server stops responding.
    • bg — Allows the system to start up even if the initial NFS mount fails. This prevents the system from stopping on startup if the NFS server is not available.
    • addr= — The address used for servers with multiple IP subnets on the same interface. Usually, this setting is not needed.
• If you are using NFSv3, both TCP and UDP ports must be open.
• If you are using NFSv4, it requires bind mounts to function.
  • NFS server /etc/fstab example: /data/boomi/exports/data/boomi none bind 0 0
  • NFS Server /etc/exports example: /exports <ipaddr/32>(rw,insecure,no_subtree_check,nohide,fsid=0,sync,no_root_squash)

Install the runtime cluster

After you complete the prerequisites, complete the following tasks in order.

1. Download the runtime cluster installer.

2. Set up Linux shared directories for the runtime cluster.

3. Install the initial runtime cluster node on Linux.

4. Install additional nodes on each machine (node) that you want to add to the runtime cluster.

5. (Optional) See the section about maintaining runtimes, runtime clusters, and runtime clouds. Clouds. You can modify how the runs, change default settings or even remove it.

6. (Optional) If you didn’t enable local storage when you ran the installer, recommends that you do to reduce unnecessary network traffic. See the topic runtime cluster and runtime cloud working data storage.

Boomi runtime cluster on AWS or Azure

If you are want to use AWS or Azure infrastructure to host your runtime cluster, you might want to consider the Boomi runtime cluster AWS Quickstart or the Boomi Kubernetes runtime cluster Quickstart to simplify your installation and configuration. The quickstarts can reduce hundreds of manual procedures to a few steps, so you can build a Boomi runtime cluster production environment quickly and can start using it immediately.

• Runtime cluster on AWS Quickstart.
• Boomi Kubernetes runtime cluster Quickstart
• AWS Kubernetes Boomi Blueprint runtime cluster

note

There are AWS credits available to cover the cost of initial proof-of-concept and trial deployments based on approval. To learn more, see the Boomiverse article Deploy a Boomi runtime cluster on AWS with One Click.