Обчислювальний елемент ARC

Програмне забезпечення Nordugrid ARC є потужним інструментом для побудови грід-інфраструктур, що дозволяє гнучко налаштувати персоналізовану інсталяцію з тими опціями, що потрібні саме для вашого кластеру. Варіантів конфігурації обчислювального елементу ARC, особливо враховуючи можливість розширення за допомогою плагінів, є надзвичайно багато.

Метою даного посібника є висвітлення основних моментів, для базового налаштування обчислювального елементу ARC. Його слід розглядати як документацію для “швидкого старту” і початку роботи, проте не як вичерпну документацію.

Після запуску базового обчислювального елементу, наполегливо рекомендую прочитати посібник адміністратора ARC Computing Element System Administrator Guide та іншу документацію, що можна знайти на офіційному сайті Nordugrid для найбільш ефективного персоналізованого налаштування вашого обчислювальнгого елементу.

Інструкція орієнтована на останню версію програмного забезпечення Nordugrid ARC (13.02.3) та оновлюється у випадку виходу нових версій¹⁾.

Програмне забезпечення Nordugrid ARC може працювати на різних дистрибутивах GNU Linux. Бінарні пакети в репозиторіях достпні для систем RedHat (CentOS, Scientific Linux), Fedora, Debian та Ubuntu.

Для роботи в інфраструктурі EGI (зокрема для інсталяції інших бібліотек та програм) рекомендованим варіантов є використання ОС Scientific Linux. Насьогодні актуальною версією Scientific Linux є версія 6.4, яку і необхідно використовувати. Рекомендований варіант інсталяції - Minimal з подальшим встановленням всіх грід-пакетів.

Для Scientific Linux в інфраструктурі УНГ створено дзеркало, яке доцільно використовувати як для інсталяції ОС так і для отримання оновлень з максимальною швидкістю (особливо для тих, хто підключений через UARNET).

Пакети Nordugrid ARC доступні з репозиторіїв Nordugrid, EMI, UMD та навіть Fedora/EPEL. Ви можете обрати будь-який з репозиторіїв на свій смак, враховуючи необхідність в іншому програмному забезпеченні, що наявне в репозиторіях. Незалежно від встановлення грід-специфічних репозиторіїв інсталяція EPEL є обов'язковою.

Окрім пакетів Nordugrid ARC необхідно встановити репозиторій EGI Trustanchors (у випадку використання UMD - вже підключений) для встановлення сертифікатів довірених центрів сертифікації (в тому числі UGRID CA).

Для спрощення конфігурації програмного забезпечення грід, для дистрибутивів Scientific Linux 6.x розроблено репозиторій Blackjack, що насамперед містить пакети специфічні для роботи в УНГ. Так, наприклад, для підключення дзеркала Scientific Linux достатньо виконати команду:

yum install yum-conf-sl6x-imbg

Переконайтесь, що для вашого доменного імені прямий запис в DNS відповідає зворотньому запису, наприклад:

$ host arc.univ.kiev.ua
arc.univ.kiev.ua has address 91.202.129.241
$ host 91.202.129.241
241.129.202.91.in-addr.arpa domain name pointer arc.univ.kiev.ua.

Переконайтесь, що на машині встановлено правильний час. Без правильно встановленого часу, захищений зв'язок через мережу неможливий. Якщо ви не використовуєте локальні джерела синхронізації часу на обчислювальному кластері, найбільш раціональним варіантом синхронізації є використання NTP²⁾.

В UA-IX джерелом точного часу є сервери http://time.in.ua

Для налаштування синхронізації часу за допомогою NTP виконайте наступне:

# yum install ntp ntpdate
# echo -e "ntp.time.in.ua\nntp2.time.in.ua" > /etc/ntp/step-tickers 
# sed -e '/^server/s/^/#/' -e '$aserver ntp.time.in.ua\nserver ntp2.time.in.ua' -i ntp.conf
# chkconfig ntpdate on
# chkconfig ntpd on
# service ntpdate start
# service ntpd start

Пакети Nordugrid ARC розповсюджуються з базовим набором правил SELinux, проте через невелику кількість людей, що залишають SELinux ввімкненим даних щодо коректності роботи правил на реально працюючій системі немає. Більш-того, якщо ви будете налаштовувати інші грід-сервіси, які не сумісні з SELinux на тій самій машині (наприклад Site BDII) вам доведеться його вимкнути.

Насьогодні найбільш безпечним та рекомендованим варіантом є переведення SELinux в стан Permissive або його повне вимкнення. Для цього у файлі /etc/selinux/config необхідно вказати бажаний стан служби та перезавантажити машину³⁾.

Режим Permissive насьогодні є рекомендованим RedHat варіантом роботи для систем з невідлагодженими політиками, адже це не віключає SELinux і дозволяє виявляти помилки в журналі аудиту системи, але не заважає роботі сервісів (не відбувається жодних дій при виявленні помилок окрім журналювання).

Необхідною умовою роботи захищених протоколів зв'язку між грід-сервісами є наявність довірених центрів сертифікації. Всі необхідні сертифікати CA встановлюються в /etc/grid-security/certificates за допомогою метапакету:

yum install ca-policy-egi-core

Для оновлення списків відкликаних сертифікатів (CRL), що також є необхідною умовою функціонування інфраструктури безпеки грід, необхідно скористатися системною утилітою fetch-crl:

yum install fetch-crl
chkconfig fetch-crl-cron on
service fetch-crl-cron start
fetch-crl

За замочуванням, всі помилки (неможливість отримання CRL, тощо) які виникають під час роботи команди надсилаються поштою адміністратору сервера. Для запису журналу роботи fetch-crl в файл замість відправки поштою можна встановити пакет fetch-crl-log2file з репозиторію Blackjack.

Для роботи сервісу вам необхідно отримати сертифікат вузла для вашого доменного імені. В Україні діє єдиний сертифікований центр: UGRID CA, до якого необхідно звернутися з запитом.

Якщо ви інсталюєте тестову систему для не для роботи в реальній інфраструктурі - можна отримати сертифікат в будь-якому з тестових CA (наприклад UA-KNU-Testbed), або навіть згенерувати самопідписаний сертифікат власноруч.

Підписаний сертифікат та приватний ключ слід встановити в директорію /etc/grid-security/⁴⁾ з іменами hostcert.pem та hostkey.pem відповідно.

Переконайтесь в правильних правах доступу до сертифікатів:

chown 0:0 /etc/grid-security/host{cert,key}.pem
chmod 644 /etc/grid-security/hostcert.pem
chmod 400 /etc/grid-security/hostkey.pem

Nordugrid ARC наразі підтримує роботу з наступними локальними системами керування задачами кластеру:

• PBS (Torque, PBSPro)
• Condor
• LoadLeveler
• LSF
• SGE
• SLURM

На машині з ARC повинні бути доступні клієнти для LRMS вашого кластеру. Немає ніяких обмежень, щодо суміщення серверної частини LRMS та ARC на одній машині, головне наявність клієнтів.

Для найбільш розповсюдженої в УНГ LRMS - PBS, необхідно також надати доступ до журналів серверу (наприклад, за допомогою NFS) як до локальної директорії на машині з ARC.

Інсталяція базового набору пакетів відбувається шляхом встановлення метапакету:

yum install nordugrid-arc-compute-element

Метапакет встановлює наступні пакети⁵⁾:

• nordugrid-arc
• nordugrid-arc-arex
• nordugrid-arc-hed
• nordugrid-arc-plugins-needed
• nordugrid-arc-plugins-globus
• nordugrid-arc-gridftpd
• nordugrid-arc-ldap-infosys
• nordugrid-arc-aris

Додатково можна встановити пакети (непотрібно для базової конфігурації, що розглядається):

• nordugrid-arc-cache-service - сервіс, що дозволяє керувати інфраструктурою кешування файлів;
• nordugrid-arc-datadelivery-service - сервіс, до дозволяє керувати інфраструктурою передачі файлів (для інсталяцій з багатьма staging-серверами для балансування навантаження).

1. Для базової конфігурації ARC CE завантажте приклад файлу конфігурації та збережіть його як /etc/arc.conf.
2. Відредагуйте файл, замінюючи коментарі вигляду _E_MAIL_ADDRESS_TO_SEND_MAIL_FROM_ значеннями, що відповідають вашій інсталяції.
3. Приклад містить конфігурацію для надання ресурсів ВО ung.infrastructure, medgrid та moldyngrid. Внесіть відповідні зміни, щоб вказати актуальний список ВО, що будете підтримувати сами ви.
4. Приклад містить конфігурацію для PBS, якщо ви використовуєте інший LRMS - змініть відповідні параметри.

Конфігурація всіх компонентів ARC CE відбувається шляхом редагування єдиного конфігураційного файлу /etc/etc.conf, що розділено на секції. Вичерпний опорний перелік опцій та їх значень знаходиться в файлі /usr/share/doc/nordugrid-arc-*/examples/arc.conf.reference, що розповсюджується з пакетом nordugrid-arc.

Приклади конфігураційного файлу для налаштування роботи певних сервісів (які можна використосувати як базу для подальшої конфігурації) можна знайти в директорії /usr/share/doc/nordugrid-arc-doc-*/examples/ додатково інсталювавши пакет nordugrid-arc-doc.

Обчислювальний елемент складається з:

• A-REX - сервісу керування завданнями, що включає в себе авторизацію та відображення учасників ВО та інтеграцію з LRMS;
• GridFTP - сервіс для постановки завдань через протокол GSIFTP або простого доступу до файлів з грід-авторизацією;
• ARIS - інформаційної системи ресурсу, що надає інформацію про поточний стан ресурсу;
• Сервісів реєстрації ресурсу в індексах верхнього рівня
• Додаткових утиліт для забезпечення вищевказаних сервісів необхідною інформацією.

Розглянемо основні параметри конфігурації всіх необхідних механізмів.

Налаштування, що впливають на всі основні сервіси (A-REX, GridFTP та інформаційну систему) винесені в окрему секцію [common] конфігураційного файлу arc.conf.

[common]
x509_user_key="/etc/grid-security/hostkey.pem"
x509_user_cert="/etc/grid-security/hostcert.pem"
x509_cert_dir="/etc/grid-security/certificates"
gridmap="/etc/grid-security/grid-mapfile"

Також до загальних параметрів належить і інтеграція з LRMS, адже наприкінці все зводиться до керування та моніторингу локальних завдань. Наприклад, для PBS з планувальником MAUI необхідно додати наступну конфігурацію:

lrms="pbs"
pbs_bin_path="/usr/bin"
pbs_log_path="/var/spool/torque/server_logs/"
maui_bin_path="/usr/bin"

Окрім загальної інформації про LRMS необхідно також налаштувати черги, до яких будуть надсилатися завдання з грід. Принаймні одна черга є необхідною (наприклад grid):

[queue/grid]
name="grid"
comment="The most general grid queue"
nodememory="8000"

Параметр nodememory не є обов'язковим, проте його доцільно визначити для виключення задач, що потребують більше пам'яті аніж є на робочих вузлах (така задача буде очікувати вічно).

Конфігурація базових параметрів A-REX відбувається в секції [grid-manager]. Тут встановлюються параметри обробки задач (ліміти, часові інтервали, тощо), шляхи до необхідних файлів та директорій, параметри передачі файлів, журналів а також конфігуруються плагіни.

Обов'язкові параметри:

• controldir - шлях до бази даних завдань (в вигляді файлового дерева) A-REX. Локальна директорія.
• sessiondir - шлях до директорії в яку будуть завантажуватись файли задач. Спільна папка доступна на всіх робочих вузлах та на машині з ARC.
• mail - адреса з якої користувачам будуть надходити інформаційні повідомлення.

[grid-manager]
controldir="/var/spool/nordugrid/jobstatus"
sessiondir="/home/grid/scratch"
mail="grid.support@somewhere.org"

Серед необов'язкових, проте важливих для роботи параметрів слід відзначити кешування віхдних фалів:

cachedir="/home/grid/cache"

Важливим для роботи в сучасній грід-інфраструктурі є також активації WS-інтерфейсів, зокрема EMI-ES:

arex_mount_point="https://arc.univ.kiev.ua:60000/arex"
enable_emies_interface="yes"

Інші параметри, що можуть бути опціонально задані в секції [grid-manager] дозволяють персоналізувати кількісні параметри (такі як час валідності кешу чи максимальна кількість задач в різних станах). Рекомендується ознайомитись⁶⁾ зі списком всіх параметрів та, можливо, модифікувати деякі під свої потреби.

GridFTP інтерфейс постановки задач для ARC є історично першим і важливим для сумісності зі старими клієнтами та старою схемою інформаційної системи, що на сьогодні все-ще залишається у використанні в інфраструктурах EGIIS.

Більш того, з точки зору конфігурації сервісів ARC, контроль доступу та відповідність обліковим записам налаштовується саме в секцї [gridftp], хоча така конфігурація також впливає і на роботу WS-інтерфейсвів.

Для базового налаштування роботи за файлом відповідності достатньо мінімальних налаштувань GridFTP:

[gridftpd]
port="2811"
globus_tcp_port_range="9000,9300"
globus_udp_port_range="9000,9300"
pluginpath="/usr/lib64/arc/"
allowunknown="no"

[gridftpd/jobs]
path="/jobs"
plugin="jobplugin.so"
allownew="yes"

В наведеному прикладі визначено порт для роботи (2811) та динамічні порти для передачі даних (9000-9300). Вказані значення є значеннями за замовчуванням, але їх явна присутність в конфігураційному файлі зменшує імовірність забути відкрити такі порти в фаєрволі

Параметр allowunknown визначає можливість авторизації користувачів, які відсутні в файлі відповідності (grid-mapfile). За базовою авторизацією виключно за файлом відповідності, інші користувачі не повинні буди авторизовані.

Вказано шлях до плагінів та визначено плагін jobplugin.so для обробки грід-задач.

Якщо машина з ARC розташована за NAT-ом та ім'я машини не співпабає з доменним іменем необхідно додати опцію:

firewall="hostname"

Для обмеження доступу до сервісів використовується концепція груп. До іменованої групи необхідно додати тих користувачів, які до неї входять. Критеріїв додавання до групи є декілька. Найбільш значимим є критерій участі в ВО відповідно до інформації в проксі-сертифікаті, що задаєть за допомогою параметра voms.

[group/users]
voms="medgrid * * *"
voms="moldyngrid * production *"
voms="ops * * *"
voms="dteam * * *"

Засвідчення приналежності до ВО відбувається за допомогою цифрового підпису служби VOMS сервісами ARC. Щоб перевірити такий підпис, сервісам ARC необхідно надати інформацію про сертифікат служби VOMS. Джерелом такої інорфмації є файли .lsc, що містяться в директорії /etc/grid-security/vomsdir/<voname>/.

Найбільш простий спосіб встановити такі файли - скористатися готовими пакетами з репозиторію Blackjack, наприклад:

yum install vomsdir-moldyngrid

Щоб встановити .lsc файли для всіх ВО можна скористуватись метапакетом:

yum install vomsdir-bundle-UNG

Без використання репозиторію можна створити файли вручну, скориставшись сторінкою конфігурації VOMS (приклад)

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

[gridftpd/jobs]
groupcfg="users"

Для тривіальної авторизації без жодних обмежень доступу⁷⁾ можна визначити групу до якої входять всі користувачі:

[group/all]
all="all"

У будь-якого процесу в операційній системі є власник - локальний акаунт. За замовчуванням сервіси A-REX та GridFTP працюють з-під суперкористувача root для якого не перевіряються права доступу. Проте для запуску задач користувача, які надсилаються з грід-інфраструктури, використання акаунту root є надзвичайно небезпечним варіантом роботи. Тому грід-сервіси, для виконання операцій від імені грід-користувачів (запуск завдання в LRMS та інші) виконують з-під звичайних акаунтів користувача, що є обмеженими в правах доступу.

Таким чином необхідним елементом роботи є співставлення грід-ідентифікації (сертифікату користувача) та локального облікового запису - відображення користувачів.

Найбільш простим варіантом є статичне відображення за так званим файлом відповідності (grid-mapfile), де кожному DN сертифіката користувача ставиться у відповідність локальне ім'я акаунту.

Самий простий спосіб - використовувати єдиний акаунт для всіх грід-користувачів, проте за такого варіанту контроль доступу фактично відсутній. Один грід-користувач може отримати доступ до даних чи завадити роботі завдання іншого грід-користувача (можливо і ненавмисне), адже в межах операційної системи вони працюють під одним і тим самим акаунтом.

Рекомендується використовувати принаймні по користувачу на ВО (щоб одна ВО не змогла завадити роботі іншої).

Найбільш безпечним та гнучким варіатном є використання динамічного відображення, що спирається виключно на параметри участі в ВО та пули користувачів. Для динамічного відображення немає необхідності в grid-mapfile, проте необхідні додаткові бібліотеки та їх специфічні налаштування. Детальніше про динамічне відображення та його конфігурацію можна прочитати в розділах 4.5.5 “Dynamic vs static mapping” та 4.5.7 “Using LCAS/LCMAPS” ARC Computing Element System Administrator Guide.

Розглянемо нашалштування статичного відображення за файлом відповіднсоті.

Утиліта nordugridmap призначена для формування файлів відповідності з різних джерел, що знаходяться в мережі. В першу чергу це сервери VOMS, які містять інформацію про учасників ВО.

Для конфігурації nordugridmap використовуються секції [vo], що визначають джерела інформації та файли відповідності. Також можна провести тюнинг поведінки nordugridmap (час кешування, методи доступу) за допомогою параметрів секції [nordugridmap].

Розглягнемо ВО-орієнтований приклад конфігурації nordugridmap:

[vo]
vo="ung.infrastructure"
source="vomss://voms.grid.org.ua/voms/ung.infrastructure"
mapped_unixid="unguser"
file="/etc/grid-security/vomapfiles/ung.infrastructure"

[vo]
vo="moldyngrid"
source="vomss://voms.grid.org.ua/voms/moldyngrid"
voms_fqan_map="/moldyngrid/Role=production moldynproduser"
voms_fqan_map="/moldyngrid/md/Role=production moldynproduser"
mapped_unixid="moldynuser"
file="/etc/grid-security/vomapfiles/moldyngrid"

[vo]
vo="all"
source="vo://ung.infrastructure"
source="vo://moldyngrid"
mapped_unixid="nobody"
file="/etc/grid-security/grid-mapfile"

Блок для ВО ung.infrastructure генерує файл відповідності в якому всі учасники ВО будуть відображені на локальний акаунт unguser⁸⁾.

Блок для ВО MolDynGrid відображає учасників ВО з роллю production на акаунт moldynproduser а всіх інших учасників ВО на акаунт moldynuser.

Блок all об'єднує всі ВО в загальний файл відповідності, що буде використовуватись сервісами ARC.

Після конфігурації необхідно викликати nordugridmap вручну та переконатися, що списки користувачів коректно отримуються з серверів. Якщо все налаштовано вірно - необхідно відредагувати конфігурацію CRON та активувати регулярне виконання утиліти:

sed '2s/^#//' -i /etc/cron.d/nordugridmap

Для базової класичної авторизації за файлом відповідності окрім параметра gridmap блоку [common] немає необхідності в додатковій конфігурації.

Інформаційна система ARC наразі представлена як класичної LDAP-базою ARIS так і WSRF інтерфейсами A-REX. Метою інформаційної системи є ппублікація інфрмаціє про обчислювальний елемент, як статичної загальної інформації про кластер, так і динамічної інформації від LRMS про кількість вільних та зайнитих процесорів.

За збір інформації відповідає сервіс A-REX безпеосередньо. Сервіси ARIS лише отримуються інформацію від A-REX та публікуюють її через LDAP інтерфейс, тому при внесенні змін необхідно рестартувати саме A-REX.

Cтатична інформація визначається в блоці [cluster], наприклад:

[cluster]
# Ownership
cluster_alias="KNU ARC"
comment="ARC CE endpoint for KNU Cluster resources: http://cluster.kiev.ua"
cluster_location="UA-03022"
cluster_owner="National Taras Shevchenko University of Kyiv"
# VOs
authorizedvo="ung.infrastructure"
authorizedvo="moldyngrid"
# Contacts
clustersupport="grid@grid.org.ua"
# Technical details
lrmsconfig="Torque PBS with MAUI scheduler"
architecture="x86_64"
defaultmemory="512"
opsys="ScientificSL"
opsys="6.4"
opsys="Carbon"
nodeaccess="outbound"

Список авторизованих ВО, що публікується в інформаційну систему визначається саме параметрами authorizedvo, хоча реально вони не впливаються на авторизацію чи відповідність користувачів. Важливо тримати ці параметри узгодженими з блоком авторизації, щоб у клієнтів була правильна інформація щодо авторизації.

Парметр defaultmemory - кількість оперативної пам'яті в мегабайтах, яка буде запитана у LRMS у разі відсутності вимог в описі завдання, що надсилається користувачем.

Параметр nodeaccess визначає підключення робочих нод до інтернету. Ноди можуть отримати доступ в інтернет - outbound. До ноди можна підключитись напряму з інтернету (адреси на нодах, що маршрутизуються або “чесні” адреси) - inbound.

Конфігурація ARIS (ARC Resource Information System) відбувається в секціях [infosys]. Це налаштування сервісів BDII для публікації інформації в LDAP.

[infosys]
overwrite_config="yes"
port="2135"
threads="128"
timelimit="3600"

Для роботи ARIS достатньо параметрів за замовчуванням, але інколи доцільно змінити деякі з них. Наприклад значення кількості потоків серверу та обмеження часу на збір інформації. Збільшення таймліміту особливо важливе при довготривалій взаємодії з LRMS (велика кількість задач).

За замовчуванням інформація в LDAP публікується тільки з використанням схими інформації Nordugrid - власної схеми, яку розуміють тільки ARC клієнти та сервіси.

Для роботи в EGI, та публікації інформації в Site-BDII необхідною умовою є публікація даних згідно схеми Glue1.2⁹⁾ та нової схеми Glue2.0 яка повинна витіснити Glue1.2. Насьогодні під час перехідного періоду необхідно публікувати дані в усіх схемах.

Активується публікація даних за схемами Glue1.2 та Glue2.0 параметрами:

[infosys]
infosys_glue12="enable"
infosys_glue2_ldap="enable"

Але кожна зі схем потребує додаткових даних, що відсутні вNordugrid схемі. Ці дані визначають додатково, в відповідних блоках конфігурації:

[infosys/glue12]
resource_location="Kyiv, Ukraine"
resource_latitude="50.382906"
resource_longitude="30.470279"
cpu_scaling_reference_si00="16750"
processor_other_description="Cores=2,Benchmark=67-HEP-SPEC06"
glue_site_web="http://cluster.kiev.ua"
glue_site_unique_id="UA-KNU"
provide_glue_site_info="false"

[infosys/admindomain]
name="UA-KNU"
description="National Taras Shevchenko University of Kyiv"
www="http://cluster.kiev.ua"
distributed="no"

Після активації схем Glue, інформаційну систему ARC, як інформаційну систему ресурсу, можна прозоро додати до Site-BDII.

Для роботи клієнтів необхідна загальна множина ресурсів з якої можна обрати обчислювальний елемент, що відповідає вимогам задачі. Роль такої множини виконуються індески інформаційних систем, наявність яких виключає необхідність постановки задача на кожен кластер “вручну”.

Історично першим та базовим індексом для Nordugrid ARC є індекс Grid Resource Information Index (GIIS)¹⁰⁾.

В Україні функціонує два GIIS сервіси - на ресурсах КНУ та ІТФ. Для реєстрації необхідно додати наступну конфігурацію:

[infosys/cluster/registration/KNU]
targethostname="giis.grid.org.ua"
targetport="2135"
targetsuffix="mds-vo-name=ukraine,o=grid"
regperiod="300"

[infosys/cluster/registration/BITP]
targethostname="lcg.bitp.kiev.ua"
targetport="2135"
targetsuffix="mds-vo-name=ukraine,o=grid"
regperiod="300"

Індексом нового покоління, що спирається на Glue2 і дозволяє прозоро працювати з WS-інтерфейсами є EMI Registry (EMIR). Для реєстрації в EMIR необхідно додатково налаштувати сервіс EMIR-SERP, активувавши Glue2 схему.

Перед запуском сервісів доцільно перевірити синтаксис конфігураційного файлу виконавши:

/etc/init.d/a-rex validate

Після успішної валідації запустіть сервіси:

service gridftpd start
service a-rex start
service nordugrid-arc-slapd start
service nordugrid-arc-bdii start
service nordugrid-arc-inforeg start

При наявності декількох черг виникає необхідність прив'язки задач певних ВО саме до певної черги. Особливо таке питання актуальне для приорітезації тестових завдань системи Nagios, щоб запезпечити їх приорітетне виконання в певній черзі LRMS.

Щоб налаштувати таку прив'язку необхідно:

1. Активувати плагін arc-vomsac-check в секції [grid-manager]:

authplugin="ACCEPTED 60 /usr/libexec/arc/arc-vomsac-check -L %C/job.%I.local -P %C/job.%I.proxy"

2. Додати параметри доступу за участю в ВО до конфігурації черг:

  [queue/grid_rt]
  ac_policy="VOMS: UATest"
  ac_policy="VOMS: ops"
  ac_policy="VOMS: dteam"
  
  [queue/grid]
  ac_policy="VOMS: moldyngrid"
  ac_policy="VOMS: ung.infrastructure"
  
  

При найвності декілько реплік в каталозі (наприклад LFC) за допомогою послідовності приорітетів можна досягти оптимальної та найшвидшої передачі даних. Так, якщо найближчим та найшвидшим елементом зберігання для вашого кластеру є storage.immsp.kiev.ua, то необхідно до конфігурації [grid-manager] додати:

preferredpattern="storage.immsp.kiev.ua|.ua$"

При такій конфігурації, при найявності файлу на storage.immsp.kiev.ua він буде отриманий саме з цього сховища даних, потім з будь-якого серверу ім'я якого закінчується на .ua а вже потім з усіх інших серверів.