arvados-dispatch-lsf is only relevant for on premises clusters that will spool jobs to LSF. Skip this section if you use Slurm or if you are installing a cloud cluster.
Containers can be dispatched to an LSF cluster. The dispatcher sends work to the cluster using LSF’s
bsub command, so it works in a variety of LSF configurations.
In order to run containers, you must choose a user that has permission to set up FUSE mounts and run Singularity/Docker containers on each compute node. This install guide refers to this user as the
crunch user. We recommend you create this user on each compute node with the same UID and GID, and add it to the
docker system groups to grant it the necessary permissions. However, you can run the dispatcher under any account with sufficient permissions across the cluster.
Arvados-dispatch-lsf reads the common configuration file at
Add a DispatchLSF entry to the Services section, using the hostname where
arvados-dispatch-lsf will run, and an available port:
Services: DispatchLSF: InternalURLs: "http://
Review the following configuration parameters and adjust as needed.
sudo to execute
bsub, for example
sudo -E -u crunch bsub [...]. This means the
crunch account must exist on the hosts where LSF jobs run (“execution hosts”), as well as on the host where you are installing the Arvados LSF dispatcher (the “submission host”). To use a user account other than
Alternatively, you can arrange for the arvados-dispatch-lsf process to run as an unprivileged user that has a corresponding account on all compute nodes, and disable the use of
sudo by specifying an empty string:
Containers: LSF: # Don't use sudo
When arvados-dispatch-lsf invokes
bsub, you can add arguments to the command by specifying
BsubArgumentsList. You can use this to send the jobs to specific cluster partitions or add resource requests. Set
BsubArgumentsList to an array of strings. For example:
BsubArgumentsList: ["-C", "0", "-o", "/tmp/crunch-run.%J.out", "-e", "/tmp/crunch-run.%J.err"]
Note that the default value for
BsubArgumentsList uses the
-e arguments to write stdout/stderr data to files in
/tmp on the compute nodes, which is helpful for troubleshooting installation/configuration problems. Ensure you have something in place to delete old files from
/tmp, or adjust these arguments accordingly.
arvados-dispatch-lsf polls the API server periodically for new containers to run. The
PollInterval option controls how often this poll happens. Set this to a string of numbers suffixed with one of the time units
h. For example:
Extra RAM to reserve (in bytes) on each LSF job submitted by Arvados, which is added to the amount specified in the container’s
runtime_constraints. If not provided, the default value is zero.
KB is 103,
KiB is 210,
MB is 106,
MiB is 220 and so forth).
Older Linux kernels (prior to 3.18) have bugs in network namespace handling which can lead to compute node lockups. This by is indicated by blocked kernel tasks in “Workqueue: netns cleanup_net”. If you are experiencing this problem, as a workaround you can disable use of network namespaces by Docker across the cluster. Be aware this reduces container isolation, which may be a security risk.
CrunchRunArgumentsList: - "-container-enable-networking=always" - "-container-network-mode=host"
# yum install arvados-dispatch-lsf
# apt-get install arvados-dispatch-lsf
# systemctl enable --now arvados-dispatch-lsf # systemctl status arvados-dispatch-lsf [...]
systemctl status indicates it is not running, use
journalctl to check logs for errors:
# journalctl -n12 --unit arvados-dispatch-lsf
Make sure the cluster config file is up to date on the API server host then restart the API server and controller processes to ensure the configuration changes are visible to the whole cluster.
# systemctl restart nginx arvados-controller
The content of this documentation is licensed under the
Commons Attribution-Share Alike 3.0 United States licence.
Code samples in this documentation are licensed under the Apache License, Version 2.0.