Последнее изменение файла: 2020.10.12
Скопировано с www.bog.pp.ru: 2023.10.01
Bog BOS: Sun Grid Engine
Sun Grid Engine (sge, gridengine) представляет собой распределённую систему управления
очередями заданий, предназначенных для пакетного выполнения
на узлах кластера (grid, cloud, distributed resource management).
Кластер (grid) представляет собор набор вычислительных ресурсов, доступных
пользователям через одну (обычно) точку доступа.
SGE позволяет администратору задать политику управления ресурсами,
следуя которой планировщик распределяет задания по узлам кластера в соответствии с целями
организации (сроки завершения, приоритеты, SLA),
имеющимися свободными ресурсами, возможностями вычислительных устройств и требованиями заданий к ресурсам.
Пользователи запускают задания, не заботясь о месте их выполнения.
Пакетная организация работ позволяет значительно увеличить пропускную способность кластера.
Задания могут быть как обычными пакетными, так и интерактивными и параллельными,
имеется поддержка нескольких систем контрольных точек
с возможность динамической миграции заданий с узла на узел.
Разрабатывался фирмой Gridware (Distributed Resource Management - DRM), куплена Sun Microsystems в 2000.
Лицензия - SISSL (open source). Версия - 6.2u3/6.1u6 (документация к последней версии только в виде wiki).
Поддерживаемые ОС - Solaris 8/9/10, Mac OS X 10.4/10.5, HP-UX 11.0, IBM AIX 5.1/5.3,
Linux (ядро 2.4 или 2.6, glibc 2.3.2), MS Windows XP Pro SP1, MS Windows Server 2003/2008,
MS Windows Vista.
Кластер состоит из вычислительных хостов, управляющего (master) хоста,
запасного управляющего хоста (shadow master), административных хостов и пользовательских (submit) хостов.
Распределение хостов является ролевым - управляющий хост может одновременно являться и вычислительным.
Роли хостов должны быть зарегистрированы на управляющем хосте.
SGE может управлять отдельным кластером или группой кластеров
(cells, переменная окружения SGE_CELL) - позволяет съэкономить 2MB ;)
при оформлении кластера в виде ячейки.
Имя кластера задаётся переменной окружения SGE_CLUSTER_NAME.
Пользователи на всех вычислительных и пользовательских хостах должны иметь одинаковые имена и uid.
На каждом вычислительном хосте работает демон,
контролирующий выполнение заданий на данном хосте и соответствующую очередь.
Вычислительный хост может выполнять несколько заданий одновременно.
Задание представляет собой запрос на определённые вычислительные ресурсы.
Описание задания содержит требования (profile) к объёму памяти, скорости ЦП, наличию лицензий,
имя пользователя и имя группы пользователей, имя проекта.
Главный демон получает от рабочих демонов информацию о производительности и загрузке узлов,
текущем состоянии выполняемых заданий, посылает им задания.
На главном хосте работает - понятное дело - главный демон (sge_qmaster), который принимает задания
от пользовательских хостов и помещает их в очередь ожидания до освобождения
подходящего вычислительного хоста, ведёт таблицы хостов (доступные ресурсы и текущий уровень
нагрузки), заданий, очередей, пользователей и их прав, решает какую задачу помещать в какую очередь,
как переупорядочить задания в очереди, чтобы соблюсти равномерную загрузку, приоритеты
и сроки выполнения, посылает задания вычислительным хостам, отслеживает ход работ и пишет журналы.
Имеется 3 политики упорядочивания заданий (используются одновременно, влияние каждой политики определяется её весом
и нормализованным значением):
приоритет (задаётся ключом "-p" команды qsub и пр.), вес по умолчанию - 1
срочность (Urgency) - приоритет рассчитывается из заявленных требований к ресурсам,
требуемого срока окончания работ и времени ожидания
(взвешенная сумма из суммы взвешенных требований к ресурсам, времени ожидания и веса крайнего срока,
делённой на остаток времени до крайнего срока запуска; задаётся вес крайнего срока и вес ожидания)
(под)политики, основанные на раздаче плюшек (tickets)
Можно комбинировать (под)политики, использующие плюшки, назначая им размер пула плюшек для каждой (под)политики):
Functional - плюшки раздаются на основе взвешенной важности
пользователя, отдела, проекта и задания (веса и важности задаются администратором)
Share-based - плюшки раздаются исходя из заданной доли (?пользователя, группы, проекта)
и истории потребления ресурсов - ЦП, ОП и ввод/вывод (строится дерево узлов и
назначается доля каждого узла)
Override - ручное управление (плюшки раздаются администратором) отдельным заданием или
всеми заданиями пользователя, отдела, проекта, очереди временно или постоянно
При использовании плюшечной политики каждое задание при запуске
получает набор плюшек из пула каждой используемой политики.
Размер функционального и разделяемого пула задаётся администратором.
Администратор и оператор могут вбросить порцию плюшек в систему (override).
Через определённые интервалы времени (Shedule Interval) задание может получить очередную
порцию плюшек (или потерять, если использует больше ресурсов, чем обещало).
Планировщик через определённые интервалы времени пытается запустить задания из списка
ожидания на выполнение:
предварительно вычеркивает из рассмотрения
переполненные очереди (заняты все слоты)
перегруженные очереди (исходя из данных датчиков загрузки ресурсов)
неподходящие очереди (недостаточной мощности по одному из ресурсов?
но здесь мы ничего не знаем о заданиях)
сортирует оставшиеся очереди исходя из минимума нагрузки (типы измеряемых нагрузок
и их масштабирование задаются в настройках очереди и хоста;
можно компенсировать всплеск нагрузки при запуске задания (Load adjustment))
вычеркивает неготовые (?) задания
резервирует ресурсы для высокоприоритетных заданий (чтобы они не ожидали бесконечно большого куска ресурса,
глядя как маленькие задания проскакивают мимо) и
пропускает низкоприоритетные быстрые задания, требующие зарезервированный ресурс (backfilling);
можно ограничить максимальное количество резервирований за интервал планирования
сортирует задания из очереди ожидания по взвешенному количеству плюшек,
срочности (urgency) и приоритету (ключ -p);
задания, превышающие лимит для данного пользователя или группы пользователей ставятся в конец
посылает первое задание на выполнение в первую подходящую по ресурсам очередь - выбор экземпляра очереди
Административный хост управляет распределённой системой.
Пользовательский хост может посылать задания главному демону (qsub) и проверять их состояние (qstat).
Имеется графический интерфейс (QMON) и программный интерфейс DRMAA
(Distributed Resource Management Application API).
Запасной управляющий хост (демон sge_shadowd) готовится заместить главный демон в случае проблем.
Хосты могут объединяться в группы хостов (иерархически),
Группа "@allhosts" включает в себя все вычислительные хосты.
Консоль ARCo (Accounting and Reporting Console) позволяет собирать данные, хранить их в СУБД (SQL) и
создавать отчёты.
Модуль SDM (Service Domain Manager) помогает обеспечивать соблюдение SLA.
SGE использует системные учётные записи пользователей.
Любой пользователь, имеющий учётные записи на пользовательском и вычислительном хостах
может запускать задания на выполнение в рамках SGE.
Имя и uid пользователя должны быть одинаковы на всех пользовательских и вычислительных хостах.
SGE ведёт свои группы пользователей двух типов: списки доступа и списки подразделения
(группа одновременно может быть обоих типов). Группа SGE может содержать имена пользователей
и имена UNIX групп (имеют префикс '@').
При установке создаются группы пользователей deadlineusers (список доступа)
и defaultdepartment (список подраздления).
Можно ограничить доступ пользователей (через списки доступа) к кластеру, отдельным очередям,
окружениям параллельного доступа и проектам.
Пользователь может входить в несколько списков доступа.
Списки подразделений (department) используются при определении политики планирования.
Пользователь может быть членом только одного подразделения.
SGE может автоматически создавать пользователей (настройки кластера - Enforce User - Auto;
не забыть задать параметры для пользователей по умолчания там же).
Типы пользователей:
администратор (manager) - суперпользователи административных хостов всегда имеют эту привилегию
оператор - могут управлять системой, но не могут изменять конфигурацию
пользователь - может запускать задания на выполнение
владелец очереди - может приостанавливать и закрывать очередь
Очередь (cluster queue) определяет класс заданий, которые могут выполняться на одном или
нескольких вычислительных хостах. Один хост может быть указан в нескольких очередях.
Каждый исполнительный хост имеет экземпляр (instance) очереди (имя-очереди@имя-хоста).
Экземпляр очереди может быть связан с группой хостов (домен очереди, имя-очереди@@имя-группы).
Настройки экземпляра очереди могут отличаться от общих настроек очереди.
При установке создаётся очередь all.q, в которую помещаются все исполнительные хосты.
Класс заданий определяется набором допустимых атрибутов заданий (например, возможность миграции на другие хосты).
Очередь при запуске задания может быть выбрана автоматически,
исходя из требований задания к ресурсам или назначена явно.
Задание ожидает выполнения в списке ожидания планировщика,
при помещении его в экземпляр очереди оно немедленно начинает выполняться.
Каждое задание привязывается к одному экземпляру очереди на всё время выполнения.
Очередь (экземпляр очереди) может иметь владельца (владельцев), которые могут закрывать очередь
и приостанавливать задания.
Очереди могут храниться в текстовом формате (локально, classic) или в Berkeley DB
(локально или на выделенном сервере - интерфейс RPC).
Berkeley DB в отличие от текстового формата обеспечивает неблокирующую запись и большую устойчивость.
Обязателен при использовании запасного упраавляющего сервера (в варианте с выделенным сервером).
Календарь (только один), привязанный к очереди, позволяет автоматически изменять состояние очереди
(закрывать и открывать, приостанавливать и возобновлять) в указанное время и/или день недели/года.
Имеется понятие подчинённых (subordinate) очередей - в настройке очереди
(целиком или для отдельного хоста) можно указать приостанавливать (SIGSTOP/SIGCONT) работу
указанной подчинённой очереди (экземпляра очереди на том же хосте)
при заполнении указанного количества слотов в исходной очереди.
SGE имеет набор встроенных атрибутов ресурсов и возможность добавлять свои атрибуты
и средства их измерения (sensors). Совокупность известных системе атрибутов называется complex.
Атрибут может быть привязан к очереди (например, h_vmem - максимально допустимый
размер виртуальной памяти), текущему состоянию хоста (например, mem_free или место на диске)
или всему кластеру (место на сетевом диске) и идентифицирует наличие ресурса определённой величины.
При установке к каждой очереди и хосту привязывается набор атрибутов по умолчанию.
Их нельзя изменить или удалить.
Планировщик принимает во внимание наличие ресурсов требуемой заданием величины.
Также планируется и учитывается потребление расходуемых ресурсов (consumable) - ОП, лицензии,
дисковое пространство, пропускная способность сети - исходя из запросов заданий.
Исходное значение расходуемого ресурса задаётся администратором (для кластера и/или
отдельной очереди и/или хоста) или измеряется, т.е.
ресурс может одновременно быть учитываемым (consumable) и реально измеряемым (load).
Контрольные точки.
Типы заданий: пакетные, интерактивные.
Проекты могут использоваться для определения политики использования ресурсов
(ресурсы могут делиться между проектами, проекты могут получать оговоренный процент плюшек).
Пользователи должны иметь право доступа к проекту (или проектам), чтобы
получить от планировщика преимущества, связанные с этим проектом (через списки доступа).
При запуске задания пользователь может указать проект, к которому у него есть доступ.
Можно настроить кластер так, чтобы пользователь был обязан указывать проект.
Профили планировщика определяют интервал планирования, тщательность планирования
и объём доступной информации о планировании:
normal - собирается максимум информации
high - для больших кластеров, собирается меньше информации
max - для очень большого потока маленьких заданий, информация не собирается вовсе
Правила переименования путей (в файлах $SGE_ROOT/имя-ячейки/common/sge_aliases
и ~/.sge_aliases) позволяют задать правила преобразования имёни текущего рабочего каталога (cwd)
при запуске заданий с определённых пользовательских хостов на определённых вычислительных хостах.
Журналы выводятся в /usr/share/gridengine/$SGE_CELL/spool/qmaster/messages
и /usr/share/gridengine/$SGE_CELL/spool/имя-хоста/messages.
Между версиями 1.6 и 1.8 куда-то затерялся sge_schedd.
будет единый кластер или группа кластеров (рекомендую единый)
имя ячейки (default) и кластера (выбирается автоматически по номеру порта sge_qmaster)
какой хост будет главным
будет ли запасной главный хост и где (полный HA не достижим в любом случае)
какие хосты будут исполнительными хостами
какие хосты будут дополнительными административными хостами
какие хосты будут дополнительными пользовательскими хостами
формат очереди - локальная или Berkeley DB,
выделенный сервер BD или нет (локальная - /var/spool/gridengine)
где будет корень (/usr/share/gridengine и общий каталог для default на NFS)
профиль планировщика (normal)
имя администратора root или sgeadmin (sgeadmin)
имена и uid пользователей на пользовательских и исполнительных хостах должны совпадать
интервал дополнительных идентификаторов Unix групп
(требуются для контроля при параллельном выполнении заданий на одном хосте -
по одной на каждое задание: 20000-20100?)
будут ли использоваться сертификаты при обмене между узлами кластера
(CSP - certificate security protocol)
будет ли использоваться SDM (Service Domain Manager) или SGE Inspect - потребуется JMX на мастере
(используются сертификаты)
тип установки - интерактивная или автоматическая
Убедиться, что на всех узлах в /etc/services имеются строки (UDP лишнее?):
sge_qmaster 6444/tcp # Grid Engine Qmaster Service
sge_qmaster 6444/udp # Grid Engine Qmaster Service
sge_execd 6445/tcp # Grid Engine Execution Service
sge_execd 6445/udp # Grid Engine Execution Service
Убедиться, что на всех узлах в /etc/passwd есть пользователь sgeadmin в группе (/etc/group) sgeadmin
(/usr/share/gridengine и /sbin/nologin) с одинаковыми gid и uid.
Создать на NFS общий каталог для ячейки default.
Пакеты для установки SGE имеются в репозитариях (SGE_ROOT=/usr/share/gridengine):
общие файлы в пакете gridengine (6.2-6.fc10.x86_64 в F10, 6.1u3-6.el5 в EPEL для RHEL5/CentOS5 - требуется fedora-usermgmt),
пакет gridengine-qmaster для главного демона (включает работу с Berkley DB),
пакет gridengine-execd для исполнительных демонов,
пакет gridengine-qmon для администрирования
(требуется /usr/X11R6/lib/libXm.so.2 из openmotif21-2.1.30-11.RHEL4.6),
пакет gridengine-devel для DRMAA.
Имеются "родные" пакеты sun-sge-common-6.2-3 и sun-sge-bin-linux24-x64-6.2-3 (SGE_ROOT=/gridware/sge/)
и просто архивы ge-6.1u6-common.tar.gz и ge-6.1u6-bin-lx24-amd64.tar.gz.
Установка главного хоста
(обязательно до пользовательских и административных хостов,
автоматически регистрируется в качестве административного и пользовательского хоста скриптом установки):
установить пакеты gridengine и gridengine-qmaster (--noscrips)
export SGE_ROOT=/usr/share/gridengine
chmod +x /etc/profile.d/sge.*
начальная настройка /etc/sysconfig/gridengine и /usr/share/gridengine/my_configuration.conf
закоментировать CreateSGEStartUpScripts в inst_sge в 3 местах
su - sgeadmin (предварительно дать право на login)
cd $SGE_ROOT
./inst_sge -m [-csp] (ответить на множество вопросов) или
./inst_sge -m [-csp] -noremote -auto имя-шаблона (пакетная установка,
журнал записывается в install_имяхоста_время.log):
использовать специально припасённого пользователя sgeadmin
корневой каталог установки - /usr/share/gridengine
порты к этому моменту должны быть определены в /etc/services
имя ячейки - default
указать рабочий каталог qmaster - на NFS (или можно/нужно локально?)
проверять права доступа к файлам (?)
не обращать внимание на домен при сравнении имён хостов
создаются каталоги
классический формат очереди
после создания каталога имя-ячейки (default) перенести его на NFS,
а здесь сделать символьную ссылку
ввести интервал uid (20000-20100)
имя рабочего каталога для вычислительных хостов, которые не будут иметь своего локального
рабочего каталога на NFS (нужно указать локальный каталог - поменять qconf)
ввести почтовый адрес администратора для получения сообщений об ошибках
при получении ошибки об отсутствии скрипта запуска демонов запустить
их вручную ("service sgemaster start")
ввести список (через пробел) будущих вычислительных хостов
ввести список (через пробел) будущих административных и пользовательских хостов
выбрать профиль планировщика (normal)
отнять право на login у пользователя sgeadmin
обеспечить автоматический запуск сервиса sgemaster с помощью chkconfig
(демоны sge_qmaster и sge_schedd)
проверить наличие процессов sge_qmaster и sge_schedd
добавить административные права пользователю sgeadmin: qconf -am sgeadmin
закоментировать CreateSGEStartUpScripts в $SGE_ROOT/inst_sge в 6 местах (исправлено в 6.2u5)
в файле ./util/install_modules/inst_common.sh убрать в функции проверки CheckBinaries в списке BINFILES имена sge_qmaster, sge_schedd и qacct - зачем проверять их наличие на клиенте? (исправлено в 6.2u5)
в CentOS 6 удалить "::1 localhost" из /etc/hosts
su - sgeadmin (дать право на login)
проверить, что хост имеет административные полномочия (на главном хосте: qconf -sh),
если нет, то добавить (на главном хосте: qconf -ah имя-рабочего-хоста) - а зачем?
удалить каталог default (нет в 6.2u5) и сделать ссылку имя-ячейки (default) на NFS
(в частности, имя главного хоста извлекается из default/common/act_qmaster)
./inst_sge -x -noremote (в конфигурацию прописываются несуществующие /usr/bin/X11/xterm и
/usr/sbin/in.telnetd; имя локального рабочего каталога (/var/spool/gridengine/);
потом вручную запустить "service sge_execd start";
проверить наличие процесса sge_execd
обеспечить автоматический запуск сервиса sge_execd (chkconfig)
занести хост в тестовую очередь
запуск тестового задания: "qsub имя-скрипта-на вычислительном-хосте";
результат (stderr и stdout) в домашнем каталоге пользовательского хоста:
имя-скрипта.eНОМЕР и имя-скриптаoНОМЕР.
добавить в список submit host, настроить очереди и группы хостов
Установка вычислительного хоста (6.2, "родные" пакеты - не получилось):
установить пакеты sun-sge-common-6.2-3 и sun-sge-bin-linux24-x64-6.2-3
export SGE_ROOT=/gridware/sge
chown -R sgeadmin:sgeadmin $SGE_ROOT
cd $SGE_ROOT
ln -s /gridware/sge /usr/share/gridengine
закоментировать CreateSGEStartUpScripts в $SGE_ROOT/inst_sge в 6 местах
su - sgeadmin (дать право на login)
cd $SGE_ROOT
проверить, что хост имеет административные полномочия (на главном хосте: qconf -sh),
если нет, то добавить (на главном хосте: qconf -ah имя-рабочего-хоста)
сделать ссылку имя-ячейки (default) на NFS
./inst_sge -x -noremote
нет контакта с главным хостом - несовместимый протокол?
chmod u+s $SGE_ROOT/utilbin/lx24-amd64/rsh # вот зачем так программировать?
cd $SGE_ROOT
закоментировать CreateSGEStartUpScripts в $SGE_ROOT/inst_sge в 6 местах
создать /var/spool/gridengine/ (с правами для sgeadmin)
создать /etc/init.d/sge_execd (в RHEL4 у killproc нет ключа "-p")
chmod +x /etc/init.d/sge_execd
chkconfig --add sge_execd
su - sgeadmin (дать право на login)
cd $SGE_ROOT
проверить, что хост имеет административные полномочия (на главном хосте: qconf -sh),
если нет, то добавить (на главном хосте: qconf -ah имя-рабочего-хоста) - а зачем?
сделать ссылку имя-ячейки (default) на NFS
создать /var/spool/gridengine/default
./inst_sge -x -noremote (в конфигурацию прописываются несуществующие /usr/bin/X11/xterm и
/usr/sbin/in.telnetd)
ввести имя ячейки (default)
имя локального рабочего каталога (/var/spool/gridengine/)
в нужный момент вручную запустить "service sge_execd start"
экземпляр очереди для этого вычислительного хоста добавляется в группу "allhosts" (1 слот)
проверить наличие процесса sge_execd
обеспечить автоматический запуск сервиса sge_execd (chkconfig)
Устанавливаются в /usr/share/gridengine/default/common/settings.sh (/etc/profile.d/sge.sh)
или /usr/share/gridengine/default/common/settings.csh (/etc/profile.d/sge.csh):
SGE_ROOT - указывает корневой каталог файлов SGE (/usr/share/gridengine)
Пользователи должны иметь право на чтение каталога $SGE_ROOT/имя-ячейки/common.
Вычислительный демон создаёт на время выполнения задания рабочий каталог,
его расположение определяется параметров tpdir настроек очереди.
Задания являются пакетными, так что не надо вставлять в .bashrc команды типа stty.
num_proc - число аппаратных потоков (ЦП с HT - это 2 num_proc)
load_short - средняя за 1 минуту длина очереди планировщика процессов
load_medium - средняя за 5 минут длина очереди планировщика процессов
load_avg - средняя за 5 минут длина очереди планировщика процессов
load_long - средняя за 15 минут длина очереди планировщика процессов
np_load_short - средняя за 1 минуту длина очереди планировщика процессов, делённая на num_proc
np_load_medium - средняя за 5 минут длина очереди планировщика процессов, делённая на num_proc
np_load_avg - средняя за 5 минут длина очереди планировщика процессов, делённая на num_proc
np_load_long - средняя за 15 минут длина очереди планировщика процессов, делённая на num_proc
mem_free
swap_free
virtual_free (mem_free+virtual_free)
mem_used
swap_used
virtual_used (mem_used+swap_used)
mem_total (mem_free+mem_used)
swap_total (swap_free+swap_used)
virtual_total (mem_total+swap_total)
Можно добавлять свои "сенсоры" (load sensor) для мониторинга
добавленных атрибутов (работают как демоны, путь определяется
в настройке кластера - конфигурации хоста - Load Sensor).
Примеры приведены в /usr/share/gridengine/util/resources/loadsensors/
(nuser.sh подсчитывает количество работающих в данный момент пользователей).
sge_execd проверяет наличие глобального скрипта qloadsensor в каталоге исполняемых файлов (/usr/share/gridengine/bin/lx26-amd64/)
и запускает его (предварительно добавить ресурс mem_total_neg в настройки комплекса).
Руками можно прописать в complex_values, а скрипт (ни qloadsensor, ни прописанный явно)
не добавляет ни в load_values, ни в complex_values (/usr/share/gridengine/util/resources/centry/mem_total_neg делал)
Например:
Отслеживаемые атрибуты можно приписывать к кластеру (будут доступны как
глобальные значения и для всех вычислительных хостов) или к хостам.
Значение фиксированных атрибутов добавлять так: "qconf -me имя хоста", далее в строке complex_values вписать "имя_атрибута=значение".
Посмотреть значения измеряемых и фиксированных аттрибутов: "qconf -se имя-хоста".
Получить список хостов, отфильтрованный по значению атрибута: "qhost -l имя-атрибута=значение".
Получить значения атрибута для хостов: "qhost -F имя-атрибута".
Добавление расходуемых ресурсов slot_req и mem_req (можно объявить расходуемыми h_vmem и s_vmem?):
добавить в комплекс ("qconf -mc") потребляемые ресурсы
добавить в каждую очередь потребляемые ресурсы ("qconf -mq имя-очереди"):
complex_values mem_req=128G slot_req=16
расставить реальные значения доступной для задач памяти и ядер по хостам
запуск задачи с указанием требований: "qsub -l slot_req=4 -l mem_req=16G"
посмотреть текущее состояние ресурсов: "qstat -q имя-очереди -F mem_req"
Общий расходуемый ресурс надо привязывать к хосту по имени global.
Задание правил квотирования ресурсов осуществляется с помощью набора правил (RQS, resource quota sets).
вывести список наборов: "qconf -srqsl"
вывести набор: "qconf -srqs"
добавить набор: "qconf -arqs имя"; набор заключается в фигурные скобки и содержит следующие параметры
(на отдельной строке имя, пробел, значение), может содержать несколько правил (limit), :
name (имя набора)
enabled (по умолчанию - false)
description
limit [имя-правила] [фильтр-применимости-правила-к-заданию] to {имя-комплекса=значение | взвешенная-сумма}
# фильтр может содержать (списки через запятую в фигурных скобках, отрицание после "!"):
users список-пользователей-или-ACL # по умолчанию '*'
projects список-проектов # '*' - все задания с указанным именем проекта, '!*' - все задания без указания имени проекта
pes список-PE # '*' - все задания с указанным PE (параллельным окружением), '!*' - все задания без указания PE
queues список-очередей # по умолчанию '*'
hosts список-хостов-и-групп-хостов # по умолчанию '*'
изменить набор: "qconf -mrqs имя"
удалить набор: "qconf -drqs имя"
вывести текущее состояние квот: qquota
Пример набора, ограничивающего количество заданий во всех очередях на каждом хосте двукратным числом ядер:
{
name limit_slots_to_cores_rqs
description Prevents core oversubscription across
enabled true
limit hosts {*} to slots=$num_proc*2
}
Добавление в группу: "qconf -aattr hostgroup hostlist имя-хоста @имя-группы".
Добавление в очередь: "qconf -aattr queue slots количество очередь@имя-хоста".
Множители текущей нагрузки позволяют отмасштабировать ценность
ресурсов данного хоста относительно некоторого базового уровня при получении отчётов
о текущей нагрузке с целью планирования выполнения заданий (по умолчанию - 1).
Множители использованных заданиями ресурсов позволяют отмасштабировать ценность
ресурсов данного хоста относительно некоторого базового уровня для отчётности (по умолчанию - 1):
cpu - израсходованное время ЦП (?)
mem - память (?)
io - ввод/вывод (?)
Права доступа для пользователей (предварительно необходимо определить перечни
пользователей типа списков доступа).
Права доступа для имеющихся проектов.
Значения потребляемые и фиксированных ресурсов (список потенциальных
типов ресурсов определяется отдельно).
Какие типы ресурсов включать в отчёты (список потенциальных
типов ресурсов определяется отдельно).
При создании (модификации) очереди задаются (sge_queue_conf.5):
имя очереди
список хостов и групп хостов, на которых будут созданы экземпляры очереди
общие настройки
номер очереди
список номеров процессоров, которые будут использоваться для выполнения заданий,
или номер набора процессоров (UNDEFINED)
каталог для временных файлов (/tmp)
интерпретатор команд (/bin/csh заменить на /bin/sh)
режим запуска интерпретатора команд
posix_compliant
unix_behavior (управляющий комментарий)
начальное состояние очереди (default) при создании и перезапуске sge_execd
перезапускать ли упавшие из-за системных сбоев задания (перекрывается "qsub -r")
календарь, привязанный к очереди (только один)
интервал между посылками предупреждающих сигналов (SIGUSR1 и SIGUSR2)
и сигналами остановки (suspend и kill); при запуске qsub требуется указать "-notify"
приоритет запускаемого процесса (nice)
количество слотов в очереди (по умолчанию - по одному слоту на каждое ядро каждого хоста)
допустимый тип заданий (пакетные, интерактивные, любые)
методы выполнения
скрипт, выполняемый перед каждым заданием (prolog), как отдельный процесс;
требуются права на выполнение;
т.е. переменные окружения не наследуются;
можно добавить переменную окружения в $SGE_JOB_SPOOL_DIR/environment (sgeadmin:sgeadmin)
скрипт, выполняемый после каждого задания (epilog), как отдельный процесс;
требуются права на выполнение;
метод запуска задания (Starter Method, программа запуска задания, имя скрипта в /var/spool/gridengine/$HOSTNAME/job_scripts/$JOB_ID
и параметры передаются ей)
метод остановки задания (скрипт или имя сигнала вместо SIGKILL)
метод приостановки задания (скрипт или имя сигнала вместо SIGSTOP)
метод возобновления задания (скрипт или имя сигнала вместо SIGCONT)
настройка контрольных точек
минимальный интервал между контрольными точками
ссылки на описания методов работы с контрольными точками (checkpoint object)
настройка параллельного окружения: выбор из ранее определённых описаний PE
настройки при каком уровне загрузки не запускать в очереди новые задания и когда
приостанавливать уже выполняемые
имя и максимальное значение атрибута, при котором ещё можно запускать новые задания
имя и значение атрибута, при котором приостанавливать уже выполняемые задания
интервал между последовательными приостановками
количество заданий, приостанавливаемых за один раз
ограничения на параметры заданий (жёсткие и мягкие)
календарное время (calendar?)
время ЦП (h_cpu, s_cpu; в секундах?)
размер файла (h_fsize, s_fsize)
размер данных (h_data, s_data
размер стека (h_stack, s_stack)
размер core (h_core, s_core
размер RSS (h_rss, s_rss
размер виртуальной памяти (h_vmem, s_vmem)
время календарное? (h_rt, s_rt; в секундах?)
доступные для управления заданиями в очереди атрибуты (complex)
подчинённые очереди - приостанавливаются, если данная очередь загружена
разрешённые и запрещённые пользователи (предварительно необходимо определить перечни
пользователей типа списков доступа); пустые списки - доступ всем без ограничений
разрешённые и запрещённые проекты
владельцы очереди и экземпляров очереди
Формат описания календаря - /usr/share/man/man5/sge_calendar_conf.5.gz.
Позволяет задать интервалы времени (по дням года и/или недели и по времени суток),
в которые задания должны быть запрещены (по умолчанию), остановлены или разрешены.
Пакетные задания запускаются командой qsub, в качестве параметра указывается имя скрипта, который
должен находиться в текущем рабочем каталоге на каждом вычислительном узле.
Аргументы скрипта указываются следом за строкой "--".
Скрипт должен иметь управляющий комментарий ('#!').
qsub интерпретирует управляющие комментарии '#$', извлекая из них дополнительные ключи запуска.
Скрипт должен самостоятельно подготовить окружение (установить пути доступа, загрузить модули,
перейти в нужный каталог) и затем запустить приложение.
Список командных интерпретаторов для login задаётся в настройках кластера (чтобы выполнялся .bash_profile).
Имеется возможность определить требования по умолчанию
для всех пользователей кластера ($SGE_ROOT/имя-ячейки/common/sge_request) или
для отдельных пользователей (~/.sge_request или рабочий-каталог/.sge_request), файлы содержат ключи команды qsub
(значения -q из файлов сливаются, а не замещаются).
Ключи:
-@ имя-файла (читать ключи из файла)
-a [[CC]]YY]MMDDhhmm[.SS] (запускать не ранее указанного времени)
-ac имя=значение (добавить в контекст; виден по "qsta -j")
-A учётная-запись-для-отчётов
-b {n|y} (скрипт не обрабатывается на пользовательском хосте; он может не существовать там;
может быть двоичным файлом)
-clear (отменить использование файлов с умолчаниями)
-c ? (условие для создания контрольных точек)
-ckpt имя (тип окружения для создания контрольных точек)
-cwd (запускать задание из текущего рабочего каталога ? а иначе?)
-C
-e файл-для-ошибок (stderr, ~/"имя-задания".e"номер-задания" на использованном вычислительном узле)
-hard (последующие требования обязательны)
-hold_jid список-номеров-заданий (дождаться окончания указанных заданий)
-notify (перед приостановкой и удалением задания ему посылаются сигналы SIGUSR1 и SIGUSR2
соответственно; интервал перед предупреждением задаётся в настройке очереди;
qalter и qmon позволяют установить этот флаг для уже запущенного процесса)
-j {n|y} (перенаправить stderr в stdout)
-l имя-ресурса=значение (требование ресурсов)
-m {b|e|a|s} (посылать письмо при старте задания, завершении, аварийном завершении, приостановке)
-M email-адрес
-N имя-задания (по умолчанию совпадает с именем скрипта)
-o файл-стандартного-вывода (stdout, ~/"имя-задания".o"номер-задания" на использованном вычислительном узле)
-p приоритет
-pe singlehost число (задача займёт указанное число слотов)
-P имя-проекта
-r
-soft (последующие требования желательны)
-S путь-интерпретатора-команд
Приоритеты источников ключей (слева направо, сверху вниз)
командная строка
управляющие комментарии в скрипте
рабочий-каталог/.sge_request
~/.sge_request
$SGE_ROOT/имя-ячейки/common/sge_request
При запуске задания (qsub, qsh и пр.) заполняется перечень требований (значений атрибутов)
к кластеру в целом (глобальные атрибуты, например, место на сетевом диске),
вычислительному хосту (атрибуты хоста, например, архитектура или свободная память)
или очереди (параметры очереди, например, максимально допустимое время счёта) - профиль задания (profile).
При выборе очереди для выполнения планировщик учитывает эти требования.
Требования к атрибутам могут быть обязательными (hard) или желательными (soft).
qalter - изменить описание ещё не запущенного задания
qresub - клонировать задание
qhold - придержать запуск задания
qrls - разрешить выполнение придержанного ранее задания
qdel - удалить задание
qmod - остановка и перезапуск задания (-sj и -usj)
интерактивные задания
qrsh - поддерживается терминальный ввод/вывод
(для запуска графических программ
необходимо задать DISPLAY самостоятельно и обеспечить права доступа - "xhost +";
запускаются "/usr/share/gridengine/utilbin/lx26-amd64/rshd -l" и /usr/share/gridengine/utilbin/lx26-amd64/qrsh_starter;
открывает порт 1023/tcp; стандартный ввод остаётся на хосте запуска (без радостей readline))
qsh - запуск xterm на малозагруженном подходящем хосте; в настройках кластера (не хостов)
задаётся путь к xterm на каждом узле; параметр -display позволяет задать X сервер
(создаваемый ssh localhost:10.0 не подходит; нужны права доступа к X серверу - "xhost +" - и дырка в iptables)
qlogin - начать сеанс на малозагруженном подходящем хосте (запуск там /usr/sbin/in.telnetd и подсоединение к нему)
qtcsh
параллельные задания
qmake (привет Qt! ;) - make, умеющий выполнять шаги задания параллельно
на различных узлах кластера
qmon - графический интерфейс (настройки по умолчанию в виде X ресурсов
из файле /usr/share/gridengine/qmon/Qmon отредактировать и записать в /usr/lib/X11/app-defaults/Qmon,
.Xdefaults или .Xresources или с использованием переменной окружения XAPPLRESDIR или команды xrdb;
фильтры просмотра в ~/.qmon_preferences)