В статье описываются возможности механизмов управления ресурсами системы с использованием технологии Resource Management, которая является частью инновационной технологии Solaris Containers, появившейся в Sun Solaris 10.
Введение
Управление ресурсами является важным механизмом в администрировании любой системы и непосредственно влияет на эффективность использования аппаратных средств и качество предоставления сервиса.
Использование технологии управления ресурсами позволяет:
-
Распределять аппаратные ресурсы системы между различными задачами
-
Контролировать эффективность работы процессов и динамически выделять им необходимые ресурсы
-
Вести статистику работы процессов
Технология управления ресурсами появилась для операционной системы Solaris несколько лет назад в виде самостоятельных коммерческих продуктов: Solaris Resource Manager, который использовался для контроля над системными ресурсами (процессор, память, вход в систему), и Solaris Bandwidth Manager, в задачи которого входил контроль за сетевым трафиком. Частично функциональные возможности данных продуктов интегрировались в операционную систему Sun Solaris (начиная с Solaris 8) и от версии к версии их список постоянно расширялся. Так, например, в Solaris 10 было добавлено 15 новых параметров для управления ресурсами.
В Solaris 10 данные механизмы объединены в единую инновационную технологию Solaris Containers. Основной идеей данной технологии является полная изоляция всех процессов, функционирующих в системе, что существенно повышает надежность и безопасность ее работы.
Технология Solaris Containers состоит из двух основных компонентов: технологии управления ресурсами - Resource Management и технологии виртуальных зон - Solaris Zones, с помощью которой можно создавать независимые виртуальные копии операционной системы (подробно данная технология описывается в статье ╚Solaris Containers. Конфигурирование зон.╩)
Resource Management использует в своем арсенале ряд алгоритмов, позволяющих наиболее эффективно распределять ресурсы системы и предотвращать возможные критические ситуации, возникающие по причине их неконтролируемого использования.
Контроль над ресурсами осуществляется по трем основным механизмам:
-
Scheduling. Данный механизм позволяет распределять ресурсы небольшими предустановленными фрагментами между всеми процессами в заданном интервале времени. Если какому-либо процессу ресурсы в данный момент не требуются, то он освобождает их для других процессов.
-
Partitioning. В данном случае ресурсы разбиваются на предопределенные фрагменты и выставляются рабочей области. Механизм обеспечивает гарантированное предоставление процессам необходимых ресурсов.
-
Constraint. Данный механизм позволяет очерчивать границы потребления ресурсов для области выполнения задач.
Описание технологии
Для того чтобы четко определить функциональность используемых рабочих областей в операционной системе Solaris их гипотетически разделили на два основных типа: project(проекты) и task(задачи). Проекты представляют собой совокупность распределенных по сети задач, а сами задачи включают в себя рабочие процессы. Данная структура наглядно представлена на следующем рисунке:
Как видно из рисунка, проекты являются вершиной данного дерева. По своей сути их можно сопоставить с пользователями и группами пользователей, зарегистрированными в системе. Любой пользователь при входе в систему обязательно прикрепляется к определенному для него проекту либо проекту по умолчанию. Пользователь, также, может ассоциироваться и с несколькими проектами одновременно.
Система определяет к какому проекту прикреплен пользователь в момент его входа в нее по следующему алгоритму:
-
Просматривается файл /etc/user_attr (база расширенных атрибутов пользователей) и если этот пользователь в нем присутствует, то использует для него объявленный в этом файле параметр project
-
Просматривается файл /etc/project и если в нем объявлен проект для user. user_id, то система использует этот проект в качестве ╚default╩ для данного пользователя
-
Просматривается файл /etc/project и если в нем объявлен проект для group.group-name, то система использует этот проект в качестве ╚default╩ для данного пользователя, если эта группа является главной(primary) для данного пользователя
-
Если прописан проект default в файле /etc/project, то он назначается проектом по умолчанию для всех пользователей
Локальная база проектов, как вы уже очевидно догадались, находится в /etc/project. Ее можно делегировать в различные службы имен: NIS, NIS+, LDAP.
Формат этого файла довольно прост:
projname:projid:comment:user-list:group-list:attributes
где
projname √ имя проекта
projid √ уникальный идентификатор проекта
comment √ описание проекта (не обязательное поле)
user-list √ список пользователей, использующих данный проект
group-list √ список групп пользователей, использующих данный проект
attributes √ параметры, определяющие возможность использования ресурсов
|
Пример содержимого файла /etc/project: |
|
# cat /etc/project system:0:::: |
При успешном входе в систему проект в рамках процедуры входа создает новую задачу, которая включает в себя все процессы, ассоциированные с ней (см. рисунок выше). Задачи автоматически получают свой уникальный ID и однозначно привязываются только к одному проекту.
Задачи создаются при следующих действиях/командах:
- login
- cron
- su
- newtask
- setproject
Рассмотрим теперь, как можно на практике создавать, управлять и анализировать работу с проектами и задачами:
1. Используя команды id и ps можно определить с какими проектами ассоциирован пользователь: |
bash-2.05b$ id -p bash-2.05b$ ps -o user,pid,uid,projid
|
и для пользователя root: |
|
# id -p # ps -o user,pid,uid,projid
|
2. С помощью команды prstat можно динамически просматривать и процессы, работающие в системе, и проекты (опция - J): |
# prstat √J ══ PID USERNAME═ SIZE══ RSS STATE═ PRI NICE═════ TIME═ CPU PROCESS/NLWP══════ |
и задачи (опция -T): |
# prstat -T ══ PID USERNAME═ SIZE══ RSS STATE═ PRI NICE═════ TIME═ CPU PROCESS/NLWP══════ |
3. Создадим новый проект с именем test и идентификатором 150 для пользователя urix: |
# projadd -U urix -p 150 test
|
4. Добавим комментарии для вновь созданного проекта: |
# projmod -c "Test project for user urix" test # cat /etc/project system:0::::user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: test:150:Test project for user urix:urix::
|
5. Войдем под пользователем, используя команду su, и проверим, с какими проектами он ассоциирован: |
# su - urix Sun Microsystems Inc. SunOS 5.10 s10_55 May 2004 bash-2.05b$ projects
|
6. Теперь создадим новую задачу в проекте test. Система автоматически перенесет пользовательский shell-процесс в вновь созданную задачу: |
bash-2.05b$ newtask -v -p test bash-2.05b$ id -p
|
7. Выйдем из только что созданной задачи: |
bash-2.05b$ exit exit bash-2.05b$ id -p
|
Управление ресурсами
Традиционно все UNIX системы имеют в своем арсенале механизмы наложения лимитов на ряд ресурсов. Администраторы системы применяют их для ограничения пользовательским процессам использования таких ресурсов как: время доступа к CPU, количество открытых файлов, размер core-файла, объем памяти для сегмента данных процесса и т.д.
В операционной системе Sun Solaris концепция распределения ресурсов системы разделяется по уровням: проектам, задачам и процессам. Механизмы управления ресурсами базируются на специальных параметрах ╚тонкой╩ настройки (tunable parameters) ядра системы.
Эти параметры предназначены для оптимальной настройки операционной системы для решения конкретных задач, поставленных перед системой в целом. Прописываются они в конфигурационном файле ядра - /etc/system. (Подробно про тюнинг системы можно прочитать в ╚Solaris Tunable Parameters Reference Manual╩).
Технология управления ресурсами, к сожалению, на сегодняшний день позволяет управлять только частью параметрами ╚тонкой╩ настройки ядра системы. Но, как я уже отмечал выше, от версии к версии количество поддерживаемых параметров увеличивается. Параметры, использующиеся в механизмах управления ресурсами, переопределяют значения, установленные ранее в файле /etc/system.
Механизмы распределения ресурсов настраиваются через базу проектов - /etc/project.
Приведу несколько стандартных параметров для управления ресурсами:
Имя параметра |
Описание |
Значение |
project.cpu-shares |
Гарантированное количество частей-интервалов использования процессора |
количество |
project.max-shm-ids |
Максимальное количество частей памяти доступных проекту |
количество |
project.max-sem-ids |
Максимальное количество семафоров для данного проекта |
количество |
project.max-mes-ids |
Максимальная очередь сообщений для данного проекта |
количество |
project.max-shm-memory |
Общее количество памяти, выделенное для данного проекта |
размер (байты) |
project.max-lwps |
Максимальное количество LWP одновременно возможных в данном проекте |
количество |
project.max-tasks |
Максимальное количество задач в данном проекте |
количество |
task.max-cpu-time |
Максимальное время использования процессора для данной задачи |
время (секунды) |
task.max-lwps |
Максимальное количество LWP одновременно возможных в данной задаче |
количество |
process.max-cpu-time |
Максимальное время использования процессора для данного процесса |
время (секунды) |
process.max-file-descriptor |
Максимальный номер файлового дескриптора доступного для данного процесса |
индекс |
process.max-file-size |
Максимальный размер файла, который может создавать данный процесс |
размер (байты) |
process.max-core-size |
Максимальный размер core -файла, который может создавать данный процесс |
размер (байты) |
process.max-data-size |
Максимальный размер памяти, выделяемой для области данных данного процесса |
размер (байты) |
process.max-stack-size |
Максимальный размер сегмента памяти для стека, который выделяется для данного процесса |
размер (байты) |
Политика назначения параметров для управления ресурсами подразделяется на три основных типа:
- basic (базовый) √ может изменяться владельцем процесса
- privileged (привилегированный) √ изменяется только администраторами
- system (системный) √ устанавливается на операционную систему
Гарантированно для системы назначается один параметр системного типа, который и определяет величину данного ресурса в операционной системе. Привилегированных значений может быть установлено несколько для данного параметра, а вот базовых значений √ только одно. Если привилегированные значения не установлены, то используются базовые, определенные по умолчанию.
При превышении значений, установленных в параметрах, механизмы управления ресурсами выполняют определенные действия (actions). Эти действия подразделяются на глобальные и локальные. Глобальные действия применяются ко всем контролируемым ресурсам системы, а локальные только к конкретному процессу, который достиг установленного лимита.
Вы можете одновременно устанавливать несколько действий для одного параметра ограничения ресурса. Существует три типа локальных действий:
-
none √ при превышении лимита, установленного для данного параметра, никаких действий не выполняется. Это действие используют, в основном, при мониторинге использования ресурсов системы.
-
deny √ запрещает использовать ресурсы, превышающие установленный лимит.
-
signal= - при превышении лимита посылает сигнал данному процессу. Для технологии управления ресурсами доступны следующие сигналы:
- SIGABRT √ прерывает процесс
- SIGHUP √ сигнал разрыва линии
- SIGTERM √ прерывает процесс
- SIGKILL √ ╚жесткое╩ прерывание работы процесса
- SIGSTOP √ останавливает процесс
- SIGXRES √ сигнал превышения установленного лимита
- SIGXPSZ √ завершает процесс по причине превышения лимита по размеру файла
- SIGXCPU √ завершает процесс по причине превышения временного лимита использования CPU
Устанавливать лимиты вы можете либо с помощью ряда функций командной строки, либо с помощью Solaris Management Console (/usr/sbin/smc), либо напрямую редактируя /etc/project.
|
Рис.2 Управление ресурсами в Solaris Management Console |
Рассмотрим теперь практическое применение описанных механизмов:
1. Добавим к нашему проекту test параметр, ограничивающий количество выполняющихся процессов (task.max-lwps): |
# projadd -K 'task.max-lwps=(privileged,3,deny)' test # cat /etc/project system:0::::
|
2. Создадим новую задачу с шеллом csh; с помощью команды prctl посмотрим установленные значения для параметра task.max-lwps и попробуем ╚расплодить╩ несколько процессов: |
# newtask -p test csh sunfire# prctl -n task.max-lwps $$ sunfire# id -p sunfire# ps -o project,taskid -p $$ sunfire# csh
|
Мы поставили ограничение до 3 процессов и как только попытались запустить четвертый процесс csh √ система нам в этом отказала! |
3. Добавим теперь дополнительно еще несколько ограничивающих параметров в наш проект: |
# projmod -s -K 'task.max-lwps=(basic,10,none),(privileged,500,deny); process.max-file-descriptor=(basic,128,deny)' test # cat /etc/project system:0::::
|
посмотрим на значения, установленные в системе по умолчанию: |
# prctl -n process.max-file-descriptor $$ # prctl -n task.max-lwps $$
|
создадим новую задачу и посмотрим, изменились или нет значения параметров: |
# newtask -p test csh sunfire# prctl -n process.max-file-descriptor $$ sunfire# prctl -n task.max-lwps $$
|
как видно на примере, все значения, которые мы задавали для данного проекта, успешно установились. |
|
Рис.3 Установленные параметры для проекта test |
4. Используя команду prctl, можно ╚в горячую╩ изменять значения параметров. Посмотрим, вначале, какие значения у нас были установлены: |
sunfire# prctl -n task.max-lwps $$ sunfire# prctl -n process.max-file-descriptor $$
|
теперь наложим новые значения и проверим результаты: |
sunfire# prctl -n project.max-lwps -t privileged -v 3 -e deny -i project test sunfire# prctl -n task.max-lwps $$ sunfire# prctl -n process.max-file-descriptor -r -v 256 $$ sunfire# prctl -n process.max-file-descriptor $$ sunfire# exit #
|
5. Вы можете ╚в горячую╩ изменять состояние глобальных параметров с помощью команды rctladm: |
# rctladm
|
добавим теперь возможность отслеживать через syslog-сервис сообщения по параметру task.max-lwps: |
# rctladm -e syslog task.max-lwps # rctladm . task.max-lwps syslog=notice . #
|
6. С помощью Solaris Management Console возможно управлять ресурсами системы . Зададим ограничение по использованию времени работы процессора для проекта test: |
|
Рис.4 Установка параметра в SMC |
Теперь посмотрим на изменения в файле /etc/project и на список установленных параметров для проекта test: |
# cat /etc/project system:0::::
|
|
Рис.5 Установленные параметры для проекта test |
Управление ресурсами CPU. Fair Share Scheduler (FSS)
При распределении ресурсов процессора, в Sun Solaris, по умолчанию используется механизм временного разделения (TS - timesharing scheduling). Согласно этому механизму, система пытается распределить ресурсы процессора приблизительно равными долями между всеми запущенными процессами. С использованием ряда параметров *.max-cpu-time можно устанавливать время использования процессора для необходимых задач и процессов. Но время использования процессора не позволяет четко задать, в процентном отношении, ресурс его использования.
Если перед вами стоит задача гарантированного выделения необходимой части вычислительной мощности процессоров, то в этом случае, применяется технология долевого распределения (FSS - Fair Share Scheduler). С помощью механизмов FSS можно выдавать определенное количество частей (shares) использования процессорных ресурсов системы для необходимых вам проектов.
Части, распределяемые между проектами в FSS, не равносильны процентам использования процессорных ресурсов системы. Они определяют долю использования ресурса между различными проектами, и важным критерием является не количество выделенных частей, а их отношение по сравнению с другими проектами.
Проекты в системе могут находиться в одном из двух состояний: неработающий (idle) либо активный (active). Первое означает, что ни один процесс в данном проекте не использует ресурсов процессора. Обычно, это происходит, когда процессы находятся в ╚спящем╩ состоянии или остановлены. Активным проект становится в случае, когда хоть один из его процессов использует ресурсы процессора.
Для того чтобы подсчитать в численном эквиваленте количество используемых ресурсов процессора для данного проекта, нужно воспользоваться довольно простой формулой:
|
n √ количество активных проектов |
В тех случаях, когда в вашей системе установлено более 2 процессоров, их можно разделять на процессорные группы (processor sets). В этом случае формула для расчета примет следующий вид:
|
n √ количество активных проектов, а X √ номер процессорной группы |
Рассмотрим теперь пример использования данных формул. Пусть в нашей системе функционируют три активных проекта: А, В, С. Для начала проведем расчет для системы без назначенных процессорных групп. Выделим проекту А - одну часть ресурсов, В √ две части, С √ три части. В сумме получаем 1+2+3=6. Таким образом, получаем следующий результат:
|
Если в нашей системе, например, восемь процессоров, то можно их разделить на группы (как это сделать описывается ниже в разделе ╚Пулы ресурсов╩). Создадим три процессорные группы: 2 cpu+4 cpu+2 cpu. В первой группе функционируют все три проекта из нашего первого примера. Во второй группе: проект В- с двумя частями ресурсов и проект С - с тремя частями. В третьей группе √ только проект С √ с тремя частями.
Функционально это будет выглядеть следующим образом:
|
и расчет, в этом случае, дает следующие значения:
|
|
Перейдем теперь от теории к практической реализации механизма FSS.
1. Для начала, используя команду dispadmin, посмотрим, какие классы в нашей системе установлены: |
# dispadmin -l CONFIGURED CLASSES
|
2. Установим в нашей системе возможность использования класса FSS. Это действие вступит в ╚полную силу╩ при следующей перезагрузке системы: |
# dispadmin -d FSS # dispadmin -l CONFIGURED CLASSES
|
3. Понятно, что мы не хотим ждать, когда наша система будет в очередной раз ╚перезагружена╩, чтобы процессы могли использовать механизм FSS. Для этого воспользуемся командой priocntl, с помощью которой можно ╚в горячую╩ изменять класс для процессов. Перенесем процесс init (pid 1) в FSS класс, и посмотрим, появились или нет процессы в этом классе: |
# priocntl -s -c FSS -i pid 1 # ps -ef -o pset,class | grep -v CLS | sort | uniq
|
Можно переносить процессы и проекты из одного класса в другой, но необходимо помнить, что при следующей перезагрузке системы все они будут запущены в своем предопределенном классе: |
# priocntl -s -c FSS -i class TS # ps -ef -o pset,class | grep -v CLS | sort | uniq
|
Как видно на примере, после выполнения первой команды, в системе не осталось процессов, функционирующих в классе TS. |
4. Назначить часть процессорного ресурса для проекта можно с помощью параметра project.cpu-shares : |
# prctl -n project.cpu-shares -r -v 5 -i project test # cat /etc/project system:0::::
|
Пулы ресурсов (Resource pools)
Технология Resource management позволяет создавать пулы ресурсов. Основная задача пулов состоит в предоставлении рабочим областям необходимых ресурсов системы. Эта возможность позволяет задавать гарантированную производительность системы для решения поставленных задач.
С помощью пулов можно создавать процессорные группы и назначать классы FSS. По умолчанию система устанавливает пул ╚default pool╩ и одну процессорную группу - ╚default processor set╩. Эти параметры не могут быть удалены.
Использовать пулы удобно в следующих случаях:
-
Когда необходимо разделить систему на две части. Одна часть используется для пользователей и их процессов, а другая для системных ресурсов
-
Когда на сервере функционируют несколько критически важных задач. Таким образом, с помощью пулов можно разделить ресурсы системы между задачами
-
Когда необходимо гарантированно выделять отдельным пользователям системы определенные ресурсы
- Для работы real-time приложений
При наложении пула на проект необходимо установить для него атрибут project.pool в файле /etc/project либо выполнить команду:
# projmod -s -K project.pool=pool_test test
|
Каждый проект может быть ассоциированным только с одним пулом.
Для конфигурирования пулов используется статическая таблица параметров /etc/pooladm.conf. По умолчанию, в системе, механизм использования пулов отключен и данного файла нет. При включении механизма пулов этот файл можно создать с установленными параметрами ╚по умолчанию╩. Если в момент загрузки операционная система ╚видит╩ этот файл, то она активирует автоматически механизм пулов. Формат таблицы представляет собой стандартный XML и не редактируется ╚в ручную╩. Все изменения, которые вы осуществляете, накладываются с помощью команды poolcfg. Можно, также, использовать batch-файл - заготовку в виде текстового файла, с прописанными в нем параметрами.
Используя различные статические таблицы отличные от /etc/pooladm.conf, и с помощью механизма запуска приложения по расписанию (cron) вы можете изменять политику распределения ресурсов вашей системы, например: дневную, ночную, выходного дня и т.д.
1. Активируем механизм пулов (опция √e активирует механизм пулов, а √d отключает его): |
# pooladm √e
|
2. Создадим статическую таблицу /etc/pooladm.conf с параметрами ╚по умолчанию╩ и посмотрим на эти параметры: |
# pooladm √s # poolcfg -c info system sunfire ═════ pool pool_default ═════ pset pset_default ═══════════ cpu ═══════════ cpu
|
Для того чтобы сохранить активные значения работающего механизма пулов (динамическую таблицу) в альтернативную статическую таблицу, необходимо выполнить команду: |
# pooladm √s / путь / имя_таблицы
|
Активировать альтернативную таблицу можно с помощью команды: |
# pooladm √с /путь/имя_таблицы
|
Ряд параметров, используемых при конфигурировании механизма пулов ресурсов, представлены в следующей таблице:
Имя параметра |
Тип |
Описание |
system.poold.log-level |
string |
Уровень логов (по умолчанию NOTICE) |
system.poold.log-location |
string |
Расположение логов (по умолчанию /var/log/pool/poold) |
system.poold.monitor-interval |
unsigned int |
Мониторинг использования ресурсов (миллисекунды) |
system.poold.pid |
int |
PID для poold |
pset.max |
int |
Максимальное количество процессоров в данной процессорной группе. Процессор одновременно может быть привязан только к одной группе |
pset.min |
int |
Минимальное количество процессоров в данной процессорной группе. Не может быть выше количества установленных в вашем сервере процессоров |
cpu.pinned |
boolean |
Указывает, что данный процессор не может быть динамически перенесен в другую процессорную группу |
pool.importance |
unsigned int |
Значимость пула (по умолчанию =1) |
system.poold.objectives |
string |
Задает параметры использования ресурсов для poold |
pset.poold.objectives |
string |
Задает параметры использования ресурсов для процессорной группы |
1. Выполним следующие действия:
|
# poolcfg -c 'create pset pset_test (uint pset.min = 1; uint pset.max = 2)' # poolcfg -c 'create pool pool_test' # poolcfg -c 'associate pool pool_test (pset pset_test)' # poolcfg -c ▓modify pool pool_test (string pool.scheduler = "FSS")▓
# poolcfg -c info system sunfire ═════ pool pool_default ═════ pool pool_test ═══════════ int══ ═════ pset.sys_id -1 ═══════════ boolean════ pset.default true ═══════════ uint═ ═════ pset.min 1 ═══════════ uint═ ═════ pset.max 65536 ═══════════ string═════ pset.units population ═══════════ uint═ ═════ pset.load 9 ═══════════ uint═ ═════ pset.size 2 ═══════════ string═════ pset.comment ═══════════ cpu ═══════════ cpu ═════ pset pset_test # pooladm -c / *сохраним изменения* /
|
2. Зададим параметры распределения ресурсов . Опция wt-load √ контролирует распределение ресурсов, locality none √ не влияет на распределение ресурсов, locality tight √ выделять максимально возможные ресурсы. |
# poolcfg -c ▓modify system sunfire (string system.poold.objectives = "wt-load")▓ # poolcfg -c ▓modify pset pset_default (string pset.poold.objectives = "locality none")▓ # poolcfg -c ▓modify pset pset_test (string pset.poold.objectives = "locality tight; utilization < 80") ▓ # pooladm -c / *сохраним изменения* /
|
3. Создадим новую задачу в проекте test и поместим проект в наш пул: |
# newtask -p test csh # poolbind -i project -p pool_test test sunfire# poolbind -q $$ sunfire#
|
4. Используя команду poolstat можно просматривать информацию о пулах: |
# poolstat -r pset ═id pool═══════════ type rid rset═════════════════ min═ max size used load
|
Заключение
С полной информацией о технологии Solaris Containers можно ознакомиться на сайте http://docs.sun.com, в материалах Solaris 10, ⌠System Administration Guide: Solaris Containers √ Resource Management and Solaris Zones■.