Обчислювальний елемент ARC [Регіональний операційний центр УНГ]

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

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

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

Після запуску базового обчислювального елементу, наполегливо рекомендую прочитати посібник адміністратора [[http://www.nordugrid.org/documents/arc-ce-sysadm-guide.pdf|ARC Computing Element System Administrator Guide]] та іншу документацію, що можна знайти на офіційному сайті [[http://www.nordugrid.org/documents/|Nordugrid]] для найбільш ефективного персоналізованого налаштування вашого обчислювальнгого елементу.

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

===== Підготовка до інсталяції ARC CE =====
==== Операційна система ====
Програмне забезпечення Nordugrid ARC може працювати на різних дистрибутивах GNU Linux. Бінарні пакети в [[tech:repos|репозиторіях]] достпні для систем RedHat (CentOS, Scientific Linux), Fedora, Debian та Ubuntu. 

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

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

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

Окрім пакетів Nordugrid ARC необхідно встановити [[tech:repos#egi_trustanchors|репозиторій EGI Trustanchors]] (у випадку використання UMD - вже підключений) для встановлення сертифікатів довірених центрів сертифікації (в тому числі [[https://ca.ugrid.org|UGRID CA]]).

Для спрощення конфігурації програмного забезпечення грід, для дистрибутивів Scientific Linux 6.x розроблено [[tech:repos#blackjack|репозиторій Blackjack]], що насамперед містить пакети специфічні для роботи в УНГ. Так, наприклад, для підключення [[tech:sl_mirror|дзеркала Scientific Linux]] достатньо виконати команду:
  
  yum install yum-conf-sl6x-imbg

==== Необхідні попередні налаштування ====
=== DNS back-resolve ===
Переконайтесь, що для вашого доменного імені прямий запис в 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((якщо ARC запущений на віртуальній машині, будь-ласка зверніться до документації вашого гіпервізора щодо особливостей використання NTP. Наприклад для KVM, 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

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

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

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

=== Сертифікати СА та списки CRL ===
Необхідною умовою роботи захищених протоколів зв'язку між грід-сервісами є наявність довірених центрів сертифікації. Всі необхідні сертифікати 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'' з [[tech:repos#blackjack|репозиторію Blackjack]].

=== Сертифікат вузла ===
Для роботи сервісу вам необхідно отримати сертифікат вузла для вашого доменного імені. В Україні діє єдиний сертифікований центр: [[https://ca.ugrid.org|UGRID CA]], до якого необхідно звернутися з запитом.

Якщо ви інсталюєте тестову систему для не для роботи в реальній інфраструктурі - можна отримати сертифікат в будь-якому з тестових CA (наприклад [[http://testbed.univ.kiev.ua/ca_request.php|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

=== Клієнти та журнали LRMS ===
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-серверами для балансування навантаження).

===== Конфігурація ARC CE за 5 хвилин =====

  - Для //**базової**// конфігурації ARC CE [[http://grid.org.ua/examples/arc.conf.basic|завантажте приклад файлу конфігурації]] та збережіть його як ''/etc/arc.conf''.
  - Відредагуйте файл, замінюючи коментарі вигляду ''___E_MAIL_ADDRESS_TO_SEND_MAIL_FROM___'' значеннями, що відповідають вашій інсталяції.
  - Приклад містить конфігурацію для надання ресурсів ВО ung.infrastructure, medgrid та moldyngrid. Внесіть відповідні зміни, щоб вказати актуальний список ВО, що будете підтримувати сами ви.
  - Приклад містить конфігурацію для PBS, якщо ви використовуєте інший LRMS - змініть відповідні параметри.
===== Конфігурація ARC CE =====

Конфігурація всіх компонентів 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 ====
Конфігурація базових параметрів 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]'' дозволяють персоналізувати кількісні параметри (такі як час валідності кешу чи максимальна кількість задач в різних станах). Рекомендується ознайомитись((дивись arc.conf.reference)) зі списком всіх параметрів та, можливо, модифікувати деякі під свої потреби.
==== Налаштування GridFTP ====

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>/''.

Найбільш простий спосіб встановити такі файли - скористатися готовими пакетами з [[tech:repos#blackjack|репозиторію Blackjack]], наприклад:
  yum install vomsdir-moldyngrid
  
Щоб встановити ''.lsc'' файли для всіх ВО можна скористуватись метапакетом:
  yum install vomsdir-bundle-UNG
  
Без використання репозиторію можна створити файли вручну, скориставшись [[http://voms.grid.org.ua/voms/?vo=medgrid&action=configuration| сторінкою конфігурації VOMS (приклад)]]


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

  [gridftpd/jobs]
  groupcfg="users"

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

  [group/all]
  all="all"

==== Відображення (mapping) користувачів ====

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

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

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

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

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

Найбільш безпечним та гнучким варіатном є використання динамічного відображення, що спирається виключно на параметри участі в ВО та пули користувачів. Для динамічного відображення немає необхідності в grid-mapfile, проте необхідні додаткові бібліотеки та їх специфічні налаштування. Детальніше про динамічне відображення та його конфігурацію можна прочитати в розділах 4.5.5 "Dynamic vs static mapping" та 4.5.7 "Using LCAS/LCMAPS" [[http://www.nordugrid.org/documents/arc-ce-sysadm-guide.pdf|ARC Computing Element System Administrator Guide]].

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

=== Налаштування nordugridmap ===

Утиліта ''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''((всі акаунти повинні існувати в системі на всіх робочих машинах, найкраще для цього використовувати централізовані сервіси авторизації, наприклад LDAP)).

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

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

Після конфігурації необхідно викликати ''nordugridmap'' вручну та переконатися, що списки користувачів коректно отримуються з серверів. Якщо все налаштовано вірно - необхідно відредагувати конфігурацію CRON та активувати регулярне виконання утиліти:
  sed '2s/^#//' -i /etc/cron.d/nordugridmap

=== Налаштування ARC ===
Для базової класичної авторизації за файлом відповідності окрім параметра ''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 (велика кількість задач).

=== Glue1.2 та Glue2.0 схеми для Site-BDII ====

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

Для роботи в EGI, та публікації інформації в Site-BDII необхідною умовою є публікація даних згідно схеми Glue1.2((насьогодні остання ревізія Glue схеми 1.3 проте в конфігураційному файлі використовується номер версії 1.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, як інформаційну систему ресурсу, можна прозоро додати до [[tech:site-bdii|Site-BDII]].
==== Реєстрація в індекси ====
Для роботи клієнтів необхідна загальна множина ресурсів з якої можна обрати обчислювальний елемент, що відповідає вимогам задачі. Роль такої множини виконуються індески інформаційних систем, наявність яких виключає необхідність постановки задача на кожен кластер "вручну".

=== GIIS ===
Історично першим та базовим індексом для Nordugrid ARC є індекс Grid Resource Information Index (GIIS)((сучасну останню версію GIIS, що працює на основі BDII називають EGIIS - Enhanced 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"

=== EMIR ===
Індексом нового покоління, що спирається на Glue2 і дозволяє прозоро працювати з WS-інтерфейсами є EMI Registry (EMIR). Для реєстрації в EMIR необхідно [[tech: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 а вже потім з усіх інших серверів.