Компоненти підсистеми управління завантаженням

Після відправки за допомогою інтерфейсу користувача, запит обробляється декількома компонентами WMS. Їх точний склад може варіюватися в залежності від конкретного ППО, але зазвичай в нього входять:

· менеджер завантаження (можливо з додатковим проксі-сервером);

· планувальник / брокер ресурсів;

· адаптер завдань;

· модуль, відповідальний за виконання фактичних операцій з управління завданнями (напрямок на виконання, видалення завдання, і т.д.);

· монітор log-файлів WMS.

 

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

 

Основним типом запитів до WMS є запити на виконання завдань. А головними результатами їх обробки підсистемою є:

· правильний підбір грід-ресурсу для виконання конкретного завдання на підставі опису завдання на мові JDL та інформації про доступні ресурси;

· напрямок завдання на обраний ресурс.

Першу задачу вирішує компонент, званий планувальником або брокером ресурсів (Resource Broker, RB). Існування відповідних ресурсів для даного завдання залежить не тільки від стану ресурсів, але також і від політики їх використання, якою слідують адміністратори ресурсу і / або адміністратор віртуальної організації, до якої належить користувач.

Брокер ресурсів може слідувати різної стратегії при розподілі завдань по ресурсах:

· один крайній варіант стратегії - після надходження запиту на виконання завдання, як можна швидше підбираються найбільш підходящі ресурси та, як тільки рішення прийнято, завдання передається на обраний ресурс для виконання («нетерпляче планування», в англомовній літературі називається також push-model);

· інший крайній варіант - завдання знаходяться в менеджері завантаження, поки будь-якої ресурс не стає доступним, після чого звільнився ресурсу підбирається найбільш відповідне завдання (що чекали на в менеджері) і передається цього ресурсу для виконання («лінива політика планування», pull-model);

· можливі проміжні комбіновані варіанти стратегії підбору ресурсів.

 

Для виконання своїх завдань брокер використовує базу даних про ресурси, яка оновлюється в результаті яких отримання повідомлень від ресурсів, або активного опитування ресурсів підсистемою інформаційного обслуговування та моніторингу, або деякої комбінації цих двох механізмів оновлення. Крім того, спеціальний компонент WMS, що відповідає за взаємодію з інформаційної підсистемою, може бути налаштований так, щоб певні повідомлення про зміну станів ресурсів могли викликати початок роботи брокера. Це забезпечує реалізацію «ледачою політики планування» (наприклад, після повідомлення, що якийсь ресурс звільнився брокер инициализирует відправку на нього очікує завдання).

Іншим важливим компонентом, що підвищує стійкість роботи WMS, є модуль управління чергою завдань, який дає можливість упродовж певного часу зберігати запит на виконання завдання, навіть якщо ніякі ресурси, відповідні його вимогам, не доступні негайно. Запити, по яким не вдалося відразу підібрати ресурси, будуть повторені або періодично (при «нетерплячому плануванні») або як тільки повідомлення про нові доступні ресурси з'являються в сховище даних (при «ледачою політиці планування»). В іншому випадку, такі ситуації могли б привести до негайного припинення виконання завдання через відсутність відповідного ресурсу.

Для того щоб грід-система була здатна обробляти не тільки незалежні один від одного завдання, а й сукупності завдань, залежно яких описуються спрямованим графом без замкнутих петель, WMS повинна мати мета-планувальник DAG. Його основна мета полягає в тому, щоб управляти графом (тобто, DAG-запитом), визначати, які вершини графа є вільними від залежностей, і стежити за виконанням відповідного завдання.

Перед тим, як відправити завдання в ресурсний центр може знадобитися його додаткова обробка - остаточна підготовка JDL-опису завдання і створення обгортають скрипта для нього, який формує відповідне середовище виконання на робочому вузлі відповідного ресурсного центру (зокрема, це необхідно для передачі файлів-контейнерів введення / виведення; в програмісткою літературі такі файли часто називаються "sandboxes" - «пісочниці»). Така обробка виконується окремим модулем - Адаптер завдань.

Далі слід модуль, відповідальний за виконання фактичних операцій з управління завданнями (напрямок на виконання, видалення завдання, і т.д.), які виконуються за запитами менеджера завантаження. В ППО gLite як цього модуля використовується CondorC [2].

Монітор log-файлів відповідальний за перегляд повідомлень модуля управління завданнями (наприклад, в gLite - log-файлів CondorC), і перехоплення цікавих подій щодо поточних завдань, тобто подій, що стосуються змін станів завдання (наприклад, виконане завдання, скасоване завдання, і т. Д.), а також за ініціалізацію відповідних дій.