1

Как другие администраторы управляют ресурсами ЦП на многоядерных хостах, на которых выполняются тюрьмы, например, выделяя соответствующее количество ядер для эксклюзивного использования определенными тюрьмами, а также резервируя подходящее количество ядер для эксклюзивного использования системой хоста?

TL; DR

Я изучаю, как управлять процессорами, используя rctl(8) , /etc/rctl.conf , cpuset(1) и связанные инструменты.

В качестве упражнения я работаю с 8-ядерной системой. Я хотел бы выделить ЦП 0-3 для использования исключительно процессами хост-системы и сделать ЦП 4-7 доступными только для заключенных в тюрьму процессов.

Я сталкиваюсь с двумя фундаментальными проблемами в моем ментальном ландшафте этой проблемы. Во-первых, поскольку cpuset может применять маску ЦП только к существующей цели (процесс, тюрьма и т.д.), В настоящее время я должен сначала запустить тюрьму, а затем ограничить набор процессоров. Это означает, что заключенные в тюрьму процессы, которые создаются до того, как будет создано ограничение cpuset будут работать за пределами набора ЦП. Если эти заключенные в тюрьму процессы являются долгоживущими, то они должны быть перезапущены после cpuset , чтобы гарантировать, что тюрьма остается в пределах его ограничения.

Во-вторых, по тем же причинам, что и № 1, мне не ясно, как заставить хост-систему ограничивать использование своего собственного ЦП, чтобы она не использовала ни один из ЦП, предназначенных для запуска тюрем. Опять же, поскольку ограничение набора ЦП должно быть установлено до рождения процесса, кажется, что сам init(8) должен быть запущен с ограниченным набором ЦП. Я не могу найти какой-либо механизм, чтобы сделать это.

Чтобы решить первую проблему, связанную с возможностью запуска тюрьмы с немедленным ограничением cpuset , этот синтаксис не работал в /etc/jail.conf:

path                = "/jail/$name";

test {
  jid = 42;
# This is the default value before tweaking:
#  exec.start        = "/bin/sh /etc/rc";
#  restrict this jail to CPU7 only:
  exec.start        = "/usr/bin/cpuset -c -l 7 /bin/sh /etc/rc";
  host.hostname     = "test";
  ip4.addr          = "public|10.160.161.162";
  mount.devfs       = true;
  allow.raw_sockets = true;
  allow.sysvipc     = true;
}

Другой неудачный подход состоял в том, чтобы восстановить значение по умолчанию exec.start и запустить jail с:

# cpuset -c -l 7 service jail start test

Что касается второй проблемы, то есть ограничения хост-системы для предотвращения не заключенных в тюрьму процессов (jail id = 0) с использованием процессоров, которые зарезервированы для заключенных в тюрьму процессов (jail id> 0, я не уверен, с чего начать. Казалось бы, самый элегантный способ - с самого начала ограничить init(8) , чтобы любые процессы, которые он запускает, наследовали то же ограничение ЦП. Менее элегантный хак может состоять в том, чтобы использовать rctl.conf чтобы создать ограничение ЦП на основе определенного класса входа и назначить всех пользователей этому классу входа. Это все еще не позволяет ограничить системные демоны, запускаемые init до инициализации rctl . Наивный взгляд на rcorder(8) предполагает, что rctl запускается относительно поздно в процессе запуска rc, на 127-м месте из 166 в моей системе:

# cd /etc/rc.d
# rcorder * | grep -xn rctl
127:rctl
# rcorder * | wc -l
     166

Какие решения и лучшие практики были разработаны для решения такого рода проблем? Сейчас я читаю некоторые исторические дискуссии 2014 года, касающиеся вопроса запуска init(8) с конкретным процессором. К сожалению, патч, предложенный OP этого потока, больше не доступен.

|источник

0