doc/install/crunch2-slurm/install-dispatch.html.textile.liquid

   1 ---
   2 layout: default
   3 navsection: installguide
   4 title: Install the Slurm dispatcher
   5
   6 ...
   7 {% comment %}
   8 Copyright (C) The Arvados Authors. All rights reserved.
   9
  10 SPDX-License-Identifier: CC-BY-SA-3.0
  11 {% endcomment %}
  12
  13 {% include 'notebox_begin_warning' %}
  14 @crunch-dispatch-slurm@ is only relevant for on premises clusters that will spool jobs to Slurm. Skip this section if you use LSF or if you are installing a cloud cluster.
  15 {% include 'notebox_end' %}
  16
  17 # "Introduction":#introduction
  18 # "Update config.yml":#update-config
  19 # "Install crunch-dispatch-slurm":#install-packages
  20 # "Start the service":#start-service
  21 # "Restart the API server and controller":#restart-api
  22
  23 h2(#introduction). Introduction
  24
  25 This assumes you already have a Slurm cluster, and have set up all of your compute nodes with "Docker":../crunch2/install-compute-node-docker.html or "Singularity":../crunch2/install-compute-node-singularity.html.  Slurm packages are available on all distributions supported by Arvados. Please see your distribution package repositories. For information on installing Slurm from source, see "this install guide":https://slurm.schedmd.com/quickstart_admin.html
  26
  27 The Arvados Slurm dispatcher can run on any node that can submit requests to both the Arvados API server and the Slurm controller (via @sbatch@).  It is not resource-intensive, so you can run it on the API server node.
  28
  29 h2(#update-config). Update config.yml
  30
  31 Crunch-dispatch-slurm reads the common configuration file at @/etc/arvados/config.yml@.
  32
  33 Add a DispatchSLURM entry to the Services section, using the hostname where @crunch-dispatch-slurm@ will run, and an available port:
  34
  35 <notextile>
  36 <pre>    Services:
  37       DispatchSLURM:
  38         InternalURLs:
  39           "http://<code class="userinput">hostname.zzzzz.arvadosapi.com:9007</code>": {}</pre>
  40 </notextile>
  41
  42 The following configuration parameters are optional.
  43
  44 {% include 'hpc_max_gateway_tunnels' %}
  45
  46 h3(#PollPeriod). Containers.PollInterval
  47
  48 crunch-dispatch-slurm 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 @ns@, @us@, @ms@, @s@, @m@, or @h@.  For example:
  49
  50 <notextile>
  51 <pre>    Containers:
  52       <code class="userinput">PollInterval: <b>3m30s</b>
  53 </code></pre>
  54 </notextile>
  55
  56 h3(#ReserveExtraRAM). Containers.ReserveExtraRAM: Extra RAM for jobs
  57
  58 Extra RAM to reserve (in bytes) on each Slurm 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.  Helpful when using @-cgroup-parent-subsystem@, where @crunch-run@ and @arv-mount@ share the control group memory limit with the user process.  In this situation, at least 256MiB is recommended to accommodate each container's @crunch-run@ and @arv-mount@ processes.
  59
  60 Supports suffixes @KB@, @KiB@, @MB@, @MiB@, @GB@, @GiB@, @TB@, @TiB@, @PB@, @PiB@, @EB@, @EiB@ (where @KB@ is 10[^3^], @KiB@ is 2[^10^], @MB@ is 10[^6^], @MiB@ is 2[^20^] and so forth).
  61
  62 <notextile>
  63 <pre>    Containers:
  64       <code class="userinput">ReserveExtraRAM: <b>256MiB</b></code>
  65 </pre>
  66 </notextile>
  67
  68 h3(#MinRetryPeriod). Containers.MinRetryPeriod: Rate-limit repeated attempts to start containers
  69
  70 If Slurm is unable to run a container, the dispatcher will submit it again after the next PollPeriod. If PollPeriod is very short, this can be excessive. If MinRetryPeriod is set, the dispatcher will avoid submitting the same container to Slurm more than once in the given time span.
  71
  72 <notextile>
  73 <pre>    Containers:
  74       <code class="userinput">MinRetryPeriod: <b>30s</b></code>
  75 </pre>
  76 </notextile>
  77
  78 h3(#KeepServiceURIs). Containers.Slurm.SbatchEnvironmentVariables
  79
  80 Some Arvados installations run a local keepstore on each compute node to handle all Keep traffic.  To override Keep service discovery and access the local keep server instead of the global servers, set ARVADOS_KEEP_SERVICES in SbatchEnvironmentVariables:
  81
  82 <notextile>
  83 <pre>    Containers:
  84       SLURM:
  85         <span class="userinput">SbatchEnvironmentVariables:
  86           ARVADOS_KEEP_SERVICES: "http://127.0.0.1:25107"</span>
  87 </code></pre>
  88 </notextile>
  89
  90 h3(#PrioritySpread). Containers.Slurm.PrioritySpread
  91
  92 crunch-dispatch-slurm adjusts the "nice" values of its Slurm jobs to ensure containers are prioritized correctly relative to one another. This option tunes the adjustment mechanism.
  93 * If non-Arvados jobs run on your Slurm cluster, and your Arvados containers are waiting too long in the Slurm queue because their "nice" values are too high for them to compete with other Slurm jobs, you should use a smaller PrioritySpread value.
  94 * If you have an older Slurm system that limits nice values to 10000, a smaller @PrioritySpread@ can help avoid reaching that limit.
  95 * In other cases, a larger value is beneficial because it reduces the total number of adjustments made by executing @scontrol@.
  96
  97 The smallest usable value is @1@. The default value of @10@ is used if this option is zero or negative. Example:
  98
  99 <notextile>
 100 <pre>    Containers:
 101       SLURM:
 102         <code class="userinput">PrioritySpread: <b>1000</b></code></pre>
 103 </notextile>
 104
 105 h3(#SbatchArguments). Containers.Slurm.SbatchArgumentsList
 106
 107 When crunch-dispatch-slurm invokes @sbatch@, you can add arguments to the command by specifying @SbatchArguments@.  You can use this to send the jobs to specific cluster partitions or add resource requests.  Set @SbatchArguments@ to an array of strings.  For example:
 108
 109 <notextile>
 110 <pre>    Containers:
 111       SLURM:
 112         <code class="userinput">SbatchArgumentsList:
 113           - <b>"--partition=PartitionName"</b></code>
 114 </pre>
 115 </notextile>
 116
 117 Note: If an argument is supplied multiple times, @slurm@ uses the value of the last occurrence of the argument on the command line.  Arguments specified through Arvados are added after the arguments listed in SbatchArguments.  This means, for example, an Arvados container with that specifies @partitions@ in @scheduling_parameter@ will override an occurrence of @--partition@ in SbatchArguments.  As a result, for container parameters that can be specified through Arvados, SbatchArguments can be used to specify defaults but not enforce specific policy.
 118
 119 h3(#CrunchRunCommand-cgroups). Containers.CrunchRunArgumentList: Dispatch to Slurm cgroups
 120
 121 If your Slurm cluster uses the @task/cgroup@ TaskPlugin, you can configure Crunch's Docker containers to be dispatched inside Slurm's cgroups.  This provides consistent enforcement of resource constraints.  To do this, use a crunch-dispatch-slurm configuration like the following:
 122
 123 <notextile>
 124 <pre>    Containers:
 125       <code class="userinput">CrunchRunArgumentsList:
 126         - <b>"-cgroup-parent-subsystem=memory"</b></code>
 127 </pre>
 128 </notextile>
 129
 130 When using cgroups v1, the choice of subsystem ("memory" in this example) must correspond to one of the resource types enabled in Slurm's @cgroup.conf@.  The specified subsystem is singled out only to let Crunch determine the name of the cgroup provided by Slurm.  Limits for other resource types will also be respected.
 131
 132 When doing this, you should also set "ReserveExtraRAM":#ReserveExtraRAM .
 133
 134 {% include 'notebox_begin' %}
 135
 136 Some versions of Docker (at least 1.9), when run under systemd, require the cgroup parent to be specified as a systemd slice.  This causes an error when specifying a cgroup parent created outside systemd, such as those created by Slurm.
 137
 138 You can work around this issue by disabling the Docker daemon's systemd integration.  This makes it more difficult to manage Docker services with systemd, but Crunch does not require that functionality, and it will be able to use Slurm's cgroups as container parents.  To do this, configure the Docker daemon on all compute nodes to run with the option @--exec-opt native.cgroupdriver=cgroupfs@.
 139
 140 {% include 'notebox_end' %}
 141
 142 h3(#CrunchRunCommand-network). Containers.CrunchRunArgumentList: Using host networking for containers
 143
 144 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.
 145
 146 <notextile>
 147 <pre>    Containers:
 148       <code class="userinput">CrunchRunArgumentsList:
 149         - <b>"-container-enable-networking=always"</b>
 150         - <b>"-container-network-mode=host"</b></code>
 151 </pre>
 152 </notextile>
 153
 154 {% assign arvados_component = 'crunch-dispatch-slurm' %}
 155
 156 {% include 'install_packages' %}
 157
 158 {% include 'start_service' %}
 159
 160 {% include 'restart_api' %}