Администрирование кластера

Полезные материалы по настройке подсистем кластера

Учетные записи в Slurm

Пользователи и учёт

В Slurm есть две системы учёта пользователей. Первая система основана на системных учётных записях, хранит в служебных файлах обобщённую статистику истории запуска задач и используется для простой системы вычисления приоритетов - share. Вторая система - полноценная система биллинга использует БД для хранения полной истории запуска задач, системы учётных групп (account), ограничений ресурсов (QOS) и т.п.

Первая система не требует использования БД и сохраняет текущую информацию в файлах в каталоге, заданном параметром StateSaveLocation:

assoc_mgr_state, assoc_usage, clustername, dbd.messages, fed_mgr_state,  job_state, last_config_lite, layouts_state_base, node_state, part_state, priority_last_decay_ran, qos_usage, resv_state, trigger_state

Для запуска задач в первой системе достаточно завести пользователя на уровне ОС. Для второй системы необходимо зарегистрировать его в БД:

sacctmgr -i add user testuser DefaultAccount=root 

Ассоциация (Association)

Учёт ресурсов в Slurm ведётся на основе учётных ассоциаций, каждая из которых объединяет четыре понятия:

  • кластер;
  • учетную группу (account);
  • имя пользователя;
  • необязательное имя раздела (partition).

Существует порядок создания учетных ассоциаций. Сначала описываются кластеры, потом учетные группы, и лишь потом пользователи. Пользователь при создании ассоциируется с существующей учетной группой, и эта ассоциация применяется по умолчанию для учета его задач.

Создание кластера

Кластер описывается в двух местах: в конфигурации Slurm и в учётной базе данных.

slurm.conf

AccountingStorageType=accounting_storage/slurmdbd
AccountingStoreJobComment=YES
ClusterName=uran

Создание записи в базе:

sacctmgr add cluster uran

Создание учетных групп

  • Учетная группа (account) используется для подсчёта ресурсов, использованных для запуска задач в рамках какого-либо договора, проекта и т.п.;
  • Накопленные данные об использованных ресурсах влияют на приоритет задач, запускаемых от имени учетной группы;
  • Учетная группа может быть использована для установки уровня обслуживания (QOS) задач, запускаемых от имени учетной группы;
  • С учетной группой может быть связано произвольное количество пользователей, в том числе ни одного;
  • Учетные группы могут быть организованы в иерархическое дерево путём назначения группе родительской группы;
  • Верхний уровень иерархии имеет стандартное имя root;
  • Имя учетной группы должно быть уникальным и не может быть использовано повторно в другой ветви иерархии учетных групп;
  • При подсчете приоритетов учитывается положение группы в иерархии;
  • Пользователь может связан с несколькими учетными группами, но должен иметь группу по умолчанию (DefaultAccount).

Примеры команд для создания иерархии организации и иерархии внешних пользователей, работающих по договорам:

sacctmgr add account imm Description="Институт математики и механики" Organization=imm
sacctmgr add account imm_opo Description="Отдел программного обеспечения" Organization=imm_opo parent=imm
sacctmgr add account imm_opo_sector_1 Description="Сектор системного программирования" Organization=imm_opo parent=imm_opo

sacctmgr add account external Description="Внешние пользователи" Organization=external
sacctmgr add account dogovor_10 Description="Договор N10" Organization=external
sacctmgr add account dogovor_11 Description="Договор N11" Organization=external

Отображение созданных учетных записей:

sacctmgr show account
sacctmgr show account -s   # Показывает ассоциации связанные с аккаунтами

При добавлении или изменении учетной группы доступны следующие параметры:

  • Cluster= добавить учетную группу в указанные кластеры. По умолчанию учетная группа добавляется ко всем существующим кластерам.
  • Description= описание учетной группы. (По умолчанию - имя учетной группы)
  • Name= имя учетной записи.
  • Organization= организация на которую зарегистрирована учетная группа. По умолчанию это организация родительской учетной группы, если родительская учетная группа не является корневой. Если родитель root, то при создании по умолчанию используется имя учетной группы.
  • Parent= сделать эту учетную группу дочерним элементом другой учетной группы (уже существующей).

Создание пользователей

Создание пользователя Slurm с именем xxx и учетной группой по умолчанию (обязательно) yyy:

sacctmgr create user name=xxx DefaultAccount=yyy

При необходимости пользователи могут также добавляться в дополнительные учетные группы, например:

sacctmgr add user xxx Account=zzzz

Имя учетной группы может указываться в пакетных заданиях пользователя, например, с помощью sbatch :

-A <account> или --account=<account> 

Список пользователей:

sacctmgr show user #показывает пользователей и их учетные группы по умолчанию
sacctmgr show user -s #показывает пользователей и все их ассоциации
sacctmgr show user -s test_user #выдает учетные группы пользователя test_user

При добавлении или изменении пользователя доступны следующие параметры:

  • Account= Учетная группа(ы) для добавления пользователя (см. также DefaultAccount ).
  • AdminLevel= Это поле используется, чтобы позволить пользователю добавлять учетные привилегии этому пользователю. Возможные варианты:
    • None
    • Operator - может добавлять/изменять/удалять любой объект базы данных (пользователь, учетная запись и т. Д.) и добавлять других операторов. На SlurmDBD, обслуживаемом slurmctld, эти пользователи могут: просматривать информацию, которая блокируется для регулярного использования флагом PrivateData; создавать/изменять/удалять бронирование.
    • Admin - эти пользователи имеют тот же уровень привилегий, что и оператор в базе данных. Они также могут изменять что-либо в slurmctld, как если бы они были пользователем slurm или root.
  • Cluster= добавлять к ассоциациям только на этих кластерах (по умолчанию все кластеры)
  • DefaultAccount= учетная группа по умолчанию. (обязательный параметр).
  • DefaultWCKey= пользовательский ключ по умолчанию для пользователя, используемый, когда не указан WCkey при отправке задания. (Используется только при отслеживании WCkey .)
  • Name= имя пользователя
  • Partition= Название раздела Slurm, к которому относится данная ассоциация.

Изменение и удаление объектов

При изменении свойств объектов и при их удалении можно задавать параметры в стиле SQL, используя ключевые слова WERE и SET. Некоторые параметры, например имя объекта, изменить нельзя. Типичная команда имеет следующий вид:

sacctmgr modify <entity> set <options> where <options>

Например:

sacctmgr modify user set DefaultAccount=none where DefaultAccount=test

меняет у пользователей учетную группу по умолчанию "test" на "none".

Удаление пользователя из учетной группы:

sacctmgr remove user brian where Account=imm_opo

Удаление пользователей означает, в первую очередь, удаление ассоциаций.

После того, как объект был добавлен, изменен или удален, соответствующие изменения отправляются соответствующим демонам Slurm и мгновенно становятся доступными для использования.

Примечание. В большинстве случаев удаленные объекты сохраняются, но помечены как удаленные. Если объект существовал менее 1 дня, то он будет удален полностью. Такое поведение предназначено для защиты от опечаток.

Печать объектов

sacctmgr show cluster|account|user [-s] format=account%20,description%40  [<name>]
sacctmgr show cluster|account|user [-s] [-n] -p [<name>]
  • -s показывает связанные объекты
  • format= задает список полей и количество символов, отводимых на поле
  • -n - без строки заголовка
  • -p - формат удобный для программного разбора

Использованы материалы со страницы https://wiki.fysik.dtu.dk/niflheim/Slurm_accounting

Ограничение ресурсов в Slurm

Для ограничения ресурсов необходимо включить в slurm.conf строку:

AccountingStorageEnforce=limits

TRES

Ресурсы, который можно отслеживать и использовать для ограничения, называются TRES. TRES - это комбинация типа и имени. В настоящий момент используются следующие типы TRES:

  • пакетные буферы - burst buffers (BB)
  • ЦПУ (CPU)
  • энергия (Energy)
  • GRES
  • лицензии (License)
  • память (Mem)
  • узлы (Node)
  • вычисляемый (Billing)

Вычисляемый TRES рассчитывается из TRESBillingWeights раздела. Он предварительно вычисляется во время планирования для каждого раздела, чтобы обеспечить соблюдение лимитов. После завершения задачи он пересчитывается по реально использованным ресурсам. Пример TRESBillingWeights:

TRESBillingWeights="CPU=1.0,Mem=0.25G,GRES/gpu=2.0"

Установка ограничений на пользователя:

sacctmgr modify user xxx set MaxTRES=cpu=1000 MaxTRESMinsPerJob=6000 GrpTRESMins=60000

Ограничения с префиксом Max - обозначают максимальный ресурс на одну задачу, с префиксом Grp - суммарное количество ресурсов на все задачи, когда либо запущенные пользователем (на самом деле, история потихоньку очищается и предел не является абсолютным) . В данном примере задано ограничение счёта одной задачи в 100 часов на 1000 процессорах и суммарное время в 1000 часов.

QOS

Качество обслуживания (QOS) объединяет несколько ограничений на TRES. Конфигурация QOS должна иметь как минимум стандартное значение QOS с названием normal. Дополнительные QOS'ы могут переопределять ограничения.

Например, QOS high256 с высоким приоритетом и ограничением на количество ЦПУ :

sacctmgr add qos high256 priority=10 MaxTRESPerUser=cpu=256

Просмотр существующих QOS:

sacctmgr show qos 

Назначение пользователю DefaultQOS:

sacctmgr -i modify user where name=XXXX set DefaultQOS=normal

Назначение дополнительных QOS пользователю:

sacctmgr -i modify user where name=XXXX set QOS=normal,high
sacctmgr -i modify user where name=XXXX set QOS+=high

Для того, чтобы воспользоваться дополнительным QOS пользователи должны указывать его в параметрах sbatch, например:

sbatch --qos=high256 ... 

Иерархия ограничений

Ограничения Slurm применяются в следующем порядке:

  1. QOS раздела (partition)
  2. QOS задания
  3. Ограничение ассоциации пользователя (user+account+cluster)
  4. Ограничение ассоциации учетной группы (account+cluster), по возрастанию иерархии
  5. Ассоциация root_account+cluster
  6. Ограничения раздела
  7. Нет ограничений

Выдача отчётов в Slurm

Запросить информацию по заданиям, используя следующие команды:

  • sacct - отображает данные всех заданий (завершившихся/считающихся/ждущих очереди);
  • sreport [options] - генерирует отчеты из данных учета Slurm;
  • sstat <JobID> - отображает информацию (использование памяти, ЦПУ и т.д) о считающейся задаче по её JobID ;
  • seff <JobID> - отображает эффективность использования ЦПУ и памяти завершившейся задачей по её JobID ;
  • scontrol show jobs - отображает состояние запущенных задач;
  • scontrol show assoc_mgr - отображает текущее содержимое внутреннего кэша slurmctld для пользователей, ассоциаций и/или qos.

sacct

Просмотр задач конкретного пользователя:

sacct -u user

Просмотр задач всех пользователей:

sacct -a

Начало и конец периода:

sacct --start=2018-07-01 --end=2018-07-15

sreport

Примеры использования sreport для создания отчетов:

sreport cluster UserUtilizationByAccount
sreport cluster AccountUtilizationByUser 

Показать статистику в виде дерева учетных карточек (accounts):

sreport cluster AccountUtilizationByUser tree 

Вывести отчета в виде таблицы с разделителем '|' для дальнейшей обработки скриптами:

sreport -p ... 

Выбор диапазонов дат:

sreport ... start=2018-06-01 end=2018-06-30
sreport ... start=`date -d "last month" +%D` end=`date -d "this month" +%D`

Изменение формата даты/времени в заголовке отчета (форматы в man strftime):

env SLURM_TIME_FORMAT = "%d-%b-%Y_%R" sreport ... 

Задание единиц времени, отображаемых в потреблении ресурсов (по умолчанию - минуты):

sreport -t hourper ... 

Задание TRES, отображаемых в потреблении ресурсов (по умолчанию - cpu):

sreport --tp cpu,gpu ... 

Показать учетные записи пятидесяти самых активных пользователей за 2017 год:

sreport user top start=2017-01-01 end=2017-12-31 TopCount=50 -t hourper --tres=cpu,gpu 

Отчет об использовании кластера:

sreport -t hourper cluster Utilization

Интеграция Linux и Active Directory

Существует несколько путей для интеграции Linux компьютеров в домен. Часть из них построена на использовании специализированной программ winbind из пакета Samba, а часть использует автономные PAM и NSS модули для непосредственного взаимодействия с сервером домена.

Общие настройки OpenLDAP

Пути к файлам, использованные на этой странице, относятся к дистрибутивам Linux CentOS 6/7.

Основные файлы конфигурации

/etc/openldap/slapd.conf

Конфигурация LDAP-сервера slapd. Содержимое файла для запуска slapd в режиме прокси описано в статье"OpenLDAP в режиме прокси для Active Directory".

/etc/openldap/ldap.conf

Базовая конфигурация клиентов из пакета OpenLDAP (ldapsearch, ldapwhoami, slapd в режиме прокси). Параметры из этого файла могут быть перезаписаны в командной строке. Этот файл не влияет на демон nslcd - у того свои настройки LDAP в /etc/nslcd.conf.

/etc/nslcd.conf

Конфигурация демона nslcd, который обеспечивает доступ к LDAP кэширующему серверу имен nscd. Конфигурационный файл описан в разделе "Имена пользователей и групп из LDAP (nslcd)".

Создание баз slapd

Используется два основных каталога для хранения баз /etc/openldap/slapd.d и /var/lib/ldap. Первый каталог используется для хранения конфигурации в виде базы database config. Второй - для хранения локальной базы записей LDAP или (в режиме прокси) для хранения кэша модулем pcache. В каталоге /var/lib/ldap для корректного создания базы должен находиться файл DB_CONFIG.

cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

Конфигурация slapd может храниться в двух форматах: в файле /etc/openldap/slapd.conf и в каталоге /etc/openldap/slapd.d. Конфигурация из каталога имеет больший приоритет, поэтому при изменениях файла /etc/openldap/slapd.conf надо удалить базу /etc/openldap/slapd.d и сгенерировать ее заново:

sudo rm -rf /etc/openldap/slapd.d/*; sudo -u ldap slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d -v -d -1

slaptest проверяет синтаксис slapd.conf, строит базу config в /etc/openldap/slapd.d и пытается создать bdb/hdb базы (если они описаны в slapd.conf) в /var/lib/ldap. Опция -d -1 - обеспечивает выдачу отладочной информации, что бывает полезно для поиска ошибок в файле конфигурации.

Иногда при генерации баз в /var/lib/ldap slaptest выдает ошибку:

Checking configuration files for : bdb_db_open:
db_open(/var/lib/ldap/id2entry.bdb) failed: No such file or directory (2)

В этом случае имеет смысл один раз запустить slapd от root'а (с опцией отладки, чтобы он не ушел в фоновый режим), а потом поменять владельца сгенерированых файлов.

slapd -d -1; chown -R ldap:ldap /var/lib/ldap

Целостность баз slapd

Для обеспечения целостности баз соответствующая библиотека ведёт логи транзакций, которые позволяют восстановить базу в случае сбоя на диске или аварийного отключения питания. Логи транзакций накапливаются в каталоге /var/lib/ldap/ с именами вида log.0000000001, log.0000000002 и т.д. Для кеширующего прокси целостность баз не имеет значения, поэтому сохранение логов транзакций можно отключить, добавив в файл /var/lib/ldap/DB_CONFIG строку set_flags DB_LOG_AUTOREMOVE

Запись логов

Для записи логовов slapd в конфигурационный файл syslog/rsyslog необходимо добавить правило

local4.* /var/log/ldap.log

Отладка slapd

Для отладки slapd запускается с опцией -d N, где N - число, каждый бит которого включает определенный тип отладочной печати. При запуске с опцией отладки slapd не уходит в фоновый режим и выдает отладочную печать на stderr. slapd -d -1 включает вывод всей доступной отладочной печати. Запуск slapd с опцией -d \? выдает список допустимых значений отладочных режимов и мнемонические обозначения для них. В зависимости от подключенных модулей-оверлеев, список отладочных режимов может меняться. В частности, модуль pcache добавляет свой отладочный флаг. При запуске slapd -d pcache выдается предупреждение, что используется неверный флаг отладки, но работает как надо.

Если есть желание отлаживать slapd, запущенный в фоновом режиме, то вместо опции -d следует использовать -s - запись в syslog.

Список битов, используемых с опциями -d и -s

    Any                            (-1, 0xffffffff)
    Trace                          (1, 0x1)
    Packets                        (2, 0x2)
    Args                           (4, 0x4)
    Conns                          (8, 0x8)
    BER                            (16, 0x10)
    Filter                         (32, 0x20)
    Config                         (64, 0x40)
    ACL                            (128, 0x80)
    Stats                          (256, 0x100)
    Stats2                         (512, 0x200)
    Shell                          (1024, 0x400)
    Parse                          (2048, 0x800)
    Sync                           (16384, 0x4000)
    None                           (32768, 0x8000)
    pcache                         (4096, 0x1000)

Мониторинг нагрузки

В slapd.conf включаем монитор и разрешаем доступ локальному root'у

database monitor
access to *
        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
        by * none

Просмотр данных

#Просмотр разделов, доступных для опроса
ldapsearch  -Y EXTERNAL -H ldapi:/// -b 'cn=Monitor' 
#Просмотр конкретного раздела
ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Statistics,cn=Monitor' -s base '(objectClass=*)' '*' '+'

Пример использования ldapsearch

Для отладки можно формировать запросы к LDAP-серверу командой ldapsearch. Например:

ldapsearch -H ldap://localhost/ -x -b "dc=example,dc=com" -LLL '(sAMAccountName=testuser)'

Тестирование запроса nslcd:

ldapsearch -H ldap://localhost/ -x -b "ou=People,dc=example,dc=com" -LLL '(&(&(&(&(objectClass=user)(!(objectClass=computer)))(uidNumber=*))(unixHomeDirectory=*))(sAMAccountName=testuser))'

OpenLDAP в режиме прокси для Active Directory

Общие настройки slapd описаны в статье "Общие настройки OpenLDAP".

Предполагается, что slapd выступает кэширующим прокси между Linux компьютерами в локальной сети и внешним сервером AD, работающим под управлением Win2008R2 или старше. Задачей кэширующего сервера является обеспечение отказоустойчивости при кратковременных разрывах связи с сервером АД. Клиентом выступает Linux с сервером nslcd. Соответствующая конфигурация nslcd описана в отдельной статье.

Для доступа к LDAP в AD заведен пользователь Manager с паролем secret.

Изменение схемы LDAP

В поставке CentOS нет схемы LDAP из AD. Отсутствие необходимых атрибутов приводит к тому, что запросы с этими атрибутами не обрабатываются модулем pcache, причём без какой-либо диагностической информации.

Источником схемы может быть репозиторий https://github.com/dkoudela/active-directory-to-openldap + доработка схемы NIS, в которую для совместимости с AD добавлено имя атрибута 'unixHomeDirectory', причем, обязательно в первой позиции.

/etc/openldap/schema/nis.schema

attributetype ( 1.3.6.1.1.1.1.3 NAME ('unixHomeDirectory' 'homeDirectory')
        DESC 'The absolute path to the home directory'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Ещё один вариант (неполный) схемы AD в прикреплённом файле. Источник схемы.

Тестирование кэша

Для проверки работоспособности кэша необходимо запустить сервер в режиме отладки slapd -d 4096 и заставить nslcd обратиться к нему (например выполнив команду nscd -i passwd;id testuser).

В хорошем случае при первом запросе атрибутов пользователя в логе будут строки вида :

QUERY NOT ANSWERABLE
QUERY CACHEABLE

при повторных запросах будет выдаваться

QUERY ANSWERABLE (answered 3 times)

В плохом случае постоянно будут выдаваться строки

QUERY NOT ANSWERABLE
QUERY NOT CACHEABLE

Файлы конфигурации

Ниже перечислены конфигурационные файлы в которые надо внести изменения.

/etc/sysconfig/ldap

Файл содержит опции, которые используются при запуске slapd командой systemctl start slapd или service slapd start

#Явно перечисляем интерфейсы по которым будет доступен прокси
SLAPD_LDAP=no
SLAPD_LDAPI=no
SLAPD_LDAPS=no
SLAPD_URLS="ldapi:/// ldap://192.168.1.1/ ldap://192.168.2.1/ ldap://127.0.0.1/"

/etc/openldap/ldap.conf

В этом файле важен параметр TLS_REQCERT allow. Без него невозможно подключиться к серверу АД с самоподписанным сертификатом.

#URI - адрес сервера. Протокол доступа может быть ldap: и ldaps:
URI ldaps://ldapserver.example.com/
#BASE - ветка дерева LDAP в которой ведется поиск
BASE dc=example,dc=com
#TLS_CACERTDIR - путь к каталогу с сертификатами SSL для установки защищенного соединения с сервером
TLS_CACERTDIR /etc/openldap/certs
#TLS_REQCERT - что делать если сертификат сервера не найден. 'allow' - продолжить соединение
TLS_REQCERT allow

/etc/openldap/slapd.conf

Основной конфигурационный файл

# Схема из репозитория https://github.com/dkoudela/active-directory-to-openldap
# nis.schema  с небольшой модификацией
include         /etc/openldap/schema_ad/microsoftattributetype.schema
include         /etc/openldap/schema_ad/microsoftattributetypestd.schema
include         /etc/openldap/schema_ad/corba.schema
include         /etc/openldap/schema_ad/core.schema
include         /etc/openldap/schema_ad/cosine.schema
include         /etc/openldap/schema_ad/duaconf.schema
include         /etc/openldap/schema_ad/dyngroup.schema
include         /etc/openldap/schema_ad/inetorgperson.schema
include         /etc/openldap/schema_ad/java.schema
include         /etc/openldap/schema_ad/misc.schema
include         /etc/openldap/schema_ad/nis.schema
include         /etc/openldap/schema_ad/openldap.schema
include         /etc/openldap/schema_ad/ppolicy.schema
include         /etc/openldap/schema_ad/collective.schema
include         /etc/openldap/schema_ad/microsoftobjectclass.schema


#Источник данных
database ldap                                                                 
suffix          "DC=example,DC=com"
uri             ldap://ldap.example.com/ 
rootdn          "OU=People,DC=example,DC=com"
rebind-as-user  yes

# От чьего имени подключаемся к АД
idassert-bind   bindmethod=simple
                binddn="CN=Manager,DC=example,DC=com"
                credentials="secret"
                mode=none
# Кто может подключаться к нам (все - анонимно и без авторизации)                                                                              
idassert-authzFrom "*"

# Опциональное отображение атрибутов passwd на схему AD
# в нашем варианте оно делается на уровне nslcd
#moduleload rwm
#overlay  rwm
#rwm-map attribute uid sAMAccountName
#rwm-map attribute dn distinguishedName
#rwm-map attribute homeDirectory unixHomeDirectory
#rwm-map attribute gecos displayName

# Кэширование
# Загрузка модуля и включение оверлея к базе LDAP
moduleload pcache.la
overlay pcache

# pcache <database> <max_entries> <numattrsets> <entry_limit> <cc_period> 
# параметры базы:
# <database> for cached entries. 
# <max_entries> when reached - cache replacement is invoked
# <numattrsets> = pcacheAttrset
# <entry_limit> limit to the number of entries returned 
# <cc_period> Consistency check time to wait

# в базе в формате BerkleyDB хранится 2000 записей, один набор атрибутов/фильтров с индексом 0
pcache hdb 2000 1 1000 300

#кэшируем все атрибуты (0 - индекс)
pcacheattrset 0 *

#шаблон запроса должен в точности совпадать с указанным, иначе запрос не кэшируется
#нужные шаблоны запросов можно отследить, запустив slapd в отладочном режиме - slapd -d 4096
#ниже приведены шаблоны запросов nslcd в CentOS 7 с модификацией фильтра, описанной в http://parallel.uran.ru/node/408
#кэшируем перечисленные запросы и храним их 900 секунд  (0 - индекс)

pcacheTemplate (&(&(objectClass=)(uidNumber=*)(unixHomeDirectory=*))(uidNumber=)) 0 900 120
pcacheTemplate (&(&(objectClass=)(uidNumber=*)(unixHomeDirectory=*))(sAMAccountName=)) 0 900 120
pcacheTemplate (&(objectClass=)(uidNumber=*)(unixHomeDirectory=*)) 0 900 120
pcacheTemplate (&(|(objectClass=)(objectClass=))(|(memberUid=)(member=))) 0 900 120
pcacheTemplate (&(|(objectClass=)(objectClass=))(gidNumber=)) 0 900 120
pcacheTemplate (&(|(objectClass=)(objectClass=))(memberUid=)) 0 900 120
pcacheTemplate (&(|(objectClass=)(objectClass=))(cn=)) 0 900 120

# максимальный размер запроса
sizelimit unlimited

# путь к базе
directory /var/lib/ldap
cachesize 200

# индексы для ускорения доступа
index objectClass                       eq,pres
index                                   member
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

Ссылки

  1. Обход ошибки missing id2entry.bdb

  2. OpenLDAP proxy для M$ Active Directory

Прикрепленный файлРазмер
Иконка простого текстового файла ad_schema.txt4.09 КБ

Имена пользователей и групп из LDAP (nslcd)

Всё необходимое для получения имен пользователей из LDAP в CentOS 7 находится в пакете nss-pam-ldapd. Этот пакет добавляет модуль pam_ldap.so в библиотеку libpam, модуль libnss_ldap.so в библиотеку libnss и сервер nslcd (работающий в связке с кэширующим сервером nss - nscd), который и выполняет запросы к LDAP серверу.

В файле /etc/nsswitch.conf необходимо добавить ldap, как источник данных для баз passwd, group и shadow:

passwd:   files ldap
shadow:   files ldap
group:    files ldap

В файле /etc/nslcd.conf гнобходимо настроить сервер LDAP и набор запросов к нему. Запросы включают фильтры, которые позволяют выбрать записи относящиеся к той или иной базе, и отображения стандартных имен в базе на эквивалентные по смыслу имена, которые использует схема LDAP на сервере. В примерах есть пара рабочих вариантов настроек для доступа к серверу Active Directory. Для сервера slapd из OpenLDAP модификация запросов, скорее всего, не требуется.

# Выбираем записи имеющие атрибуты uidNumber и unixHomeDirectory
# При запросе к фильтру добавляется &(sAMAccountName=username)
# 
# Не совсем понятно зачем явно отбрасываются  записи для компьютеров.
# Возможно существуют сценарии с назначением компьютеру атрибута unixHomeDirectory.
filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))

# Отображение полей passwd на атрибуты АД
map    passwd uid              sAMAccountName
map    passwd homeDirectory    unixHomeDirectory
map    passwd gecos            displayName

Сложнее с вариантом, когда для доступа к АД используется slapd в режиме кэширующего прокси, используемого для отказоустойчивости при кратковременных обрывах связи с сервером АД. Этот прокси не кэширует запросы с фильтром, использующим операцию "НЕ", а следовательно, и запрос из предыдущего примера. Для работы через кэширующий прокси рабочим оказался упрощённый вариант фильтра:

filter passwd (&(objectClass=user)(uidNumber=*)(unixHomeDirectory=*))

Авторизация пользователей в Kerberos (pam_krb5 и другие)

Ссылки:

Linux: SSH + LDAP(Kerberos) - http://xvoids.blogspot.ru/2008/09/linux-rhel-ssh-kerberos-ldapad.html

Аутентификация в apache используя Active Directory и kerberos - http://val-khmyrov.blogspot.ru/2011/04/apache-active-directory-kerberos.html

Прокси сервер Squid в Active Directory с Kerberos аутентификацией - http://www.theadmin.ru/linux/squid/proksi-server-squid-v-active-directory-s-kerberos-autentifikaciej/

Admin Guide for Mod_auth_kerb - http://www.its.mn/hp_docs/apache/mod_auth_kerb.admin.guide mod_auth_kerb - http://modauthkerb.sourceforge.net/configure.html

Kerberos Single Signon with Joomla! or other PHP apps - http://sammoffatt.com.au/knowledge-base-mainmenu/9-joomla/7-kerberos-single-signon-with-joomla-or-other-php-apps

Using mod_auth_kerb and Windows 2000/2003/2008R2 as KDC - http://www.grolmsnet.de/kerbtut/

Структура БД Slurm

Большинство таблиц содержат колонки: время создания, время модификации, признак удаления - creation_time, mod_time, deleted.

acct_table Таблица учетных групп

  • name,description,organization

user_table Таблица пользователей

  • name, admin_level

super_assoc_table Таблица ассоциаций пользователь-учетная группа на кластере

  • id_assoc - уникальный номер
  • deleted - операция acctmgr remove удаляет запись, если она была создана несколько минут назад, иначе помечает, как удаленную.
  • user,acct - пара пользователь-учетная группа. У учетной группы поле user пустое, поле acct пустым не бывает.
  • parent_acct - родительская учетная группа. Бывает только у учетной группы.
  • lft,rgt - загадочные поля.

super_job_table Таблица заданий на кластере super

  • job_db_inx - уникальный индекс. Введён, поскольку id_job назначается за пределами DB.
  • id_job - числовой id задачи
  • account - текстовое имя учетной группы. Используется sacct при формировании списка заданий учетной группы.
  • id_assoc - номер ассоциации
  • id_user, id_group - системные UID,GID без привязки к assoc_table
  • nodelist - список узлов в формате slurm (node[3-5,7]). Есть особое значение 'None assigned'
  • nodes_alloc - число узлов
  • node_inx - список узлов в виде их числовых индексов (3-5,108-212)
  • work_dir - рабочий каталог. Поле появилось с какой то версии Slurm. До того пустой.
  • time_submit, time_start, time_end - времена в формате unix timesatmp.
    В SQL функция UNIX_TIMESTAMP('2018-09-01 12:00:00'). Обратное преобразование FROM_UNIXTIME(1447430881);
  • state - числовое значение состояния задачи

Значения state

enum job_states {
  JOB_PENDING,   /* queued waiting for initiation */
  JOB_RUNNING,   /* allocated resources and executing */
  JOB_SUSPENDED, /* allocated resources, execution suspended */
  JOB_COMPLETE,  /* completed execution successfully */
  JOB_CANCELLED, /* cancelled by user */
  JOB_FAILED,    /* completed execution unsuccessfully */
  JOB_TIMEOUT,   /* terminated on reaching time limit */
  JOB_NODE_FAIL, /* terminated on node failure */
  JOB_PREEMPTED, /* terminated due to preemption */
  JOB_BOOT_FAIL, /* terminated due to node boot failure */
  JOB_DEADLINE,  /* terminated on deadline */
  JOB_OOM,       /* experienced out of memory error */
  JOB_END        /* not a real state, last entry in table */
};

super_step_table Таблица параллельных задач (step), сформированных командами srun в рамках одного задания. Один srun - одна задача (step).

  • job_db_inx - связь с таблицей job_table
  • id_step - номер шага от 0 и далее, -2 - особый случай batch - формируется через sbatch.
  • time_start, time_end - индивидуальные времена шагов. job.time_start=min(step.time_start), job.time_end=max(step.time_end).
  • task_cnt - количество запущенных srun процессов (каждый из которых может занимать несколько ядер).

Извлечение задач на кластере super по номеру задания

select j.id_job,j.job_name,s.step_name,j.nodelist,s.nodelist,j.nodes_alloc,s.nodes_alloc,s.id_step
   from super_job_table as j
   join super_step_table as s
     on j.job_db_inx=s.job_db_inx
  where j.id_job=24747; 

Задания на кластере super, не сумевшие стартовать задачу

select j.id_job
  from super_job_table as j
  left join super_step_table as s
    on j.job_db_inx=s.job_db_inx
  where s.job_db_inx IS NULL