Назад | Перейти на главную страницу

Одноузловой сервер SLURM: ограничение интерактивного использования ЦП

У меня есть установка SLURM на одном узле, который также является "узлом входа". Я хотел бы ограничить интерактивное использование ЦП, например вне системы расписания.

Я нашел следующую статью, в которой предлагается использовать для этого cgroups: https://rolk.github.io/2015/04/20/slurm-cluster

Я подумал, что это идеально, и настроил это следующим образом:

/etc/cgconfig.conf:

group root {
        cpu {}
}

group interactive {
        cpu {
                cpu.cfs_period_us=100000;
                cpu.cfs_quota_us=400000;
        }
}

group batch {
        cpu {}
}

/etc/cgrules.conf:

root             cpu    root
slurm            cpu    batch
*                cpu    interactive

я использую cgrulesengd применять эти правила.

Проблема в том, что задачи, правильно поставленные в очередь с помощью SLURM, также выполняются под собственным пользователем соответствующего пользователя (а не slurm), поэтому они попадают в interactive cgroup. Конечно, я не этого хочу. Я предполагаю, что в статье, которую я читал, ожидалось, что задачи будут выполняться под slurm пользователь.

Есть ли способ поместить все задачи, выполняемые SLURM, в нужную контрольную группу?

Я уже некоторое время бьюсь головой об этой проблеме и, наконец, наткнулся на это решение на stackexchange: https://unix.stackexchange.com/questions/526994/limit-resources-cpu-mem-only-in-ssh-session. Мой ответ ниже адаптирован из этого. Сначала создайте свою ограниченную «интерактивную» контрольную группу в /etc/cgconfig.conf:

group interactive {
   perm {
      admin {
         uid=root;
         gid=root;
      }
      task {
         uid=root;
         gid=shelluser;
         fperm=775;
      }
   }
   cpu {
      cpu.cfs_period_us = "1000000";
      cpu.cfs_quota_us = "500000";
   }
   memory {
      memory.limit_in_bytes = "8G";
      memory.memsw.limit_in_bytes = "8G";
   }
}

Мы добавили подраздел perm {}, который позволит учетным записям пользователей помещать себя в эту контрольную группу, используя cgclassify (Я думаю, но не знаю наверняка, что тогда у них не будет разрешения на удалять сами из этой группы, однако это может быть лазейкой в ​​этом процессе. Для моих целей это потенциальная лазейка, которую я готов принять, учитывая мою пользовательскую базу). Раздел задач {} определяет, кому разрешено назначать задачи контрольной группе. В этом случае мы устанавливаем файл задач как доступный для записи для группы и принадлежащий группе «shelluser». Вам нужно, чтобы ваши пользователи были членами этой группы, иначе ничего из этого не сработает.

Теперь создадим скрипт /etc/profile.d/ssh.sh. В этом скрипте мы назначим сеансы ssh «интерактивной» контрольной группе, тем самым не позволяя пользователям напрямую перегружать системные ресурсы. Однако иногда вам нужно запускать некоторые вещи в интерактивном режиме, поэтому я разрешил запускать интерактивные сеансы, порождаемые slurm, неограниченно. Опять же, способ, которым я это сделал, почти наверняка может быть использован умным пользователем, но это риск, на который я готов пойти, учитывая наших пользователей:

# check if user is in an SSH session and *hasn't* been spawned by slurm
if [[ -n $SSH_CONNECTION ]] && [[ -z $SLURM_JOBID ]]; then
  # get the shell pid
  SESSIONPID=$$
  # attach the shell to the relevant cgroup
  cgclassify -g memory,cpu:interactive $SESSIONPID
  # now everything spawned by this shell should be in this cgroup
fi

Пользователи, входящие в систему через SSH, будут помещены в «интерактивную» контрольную группу при входе в систему (при условии, что они являются членами группы unix «shelluser»). В этом случае они будут ограничены 8 Гб и 1/2 одного процессора. Если им нужно иметь возможность запускать вещи напрямую без ограничений, они могут создать экземпляр bash в slurm с помощью

$ srun -p <partition> -c <cpus> --mem=<mem> -t <time> --pty /bin/bash

И он должен работать без ограничений.