4.4. Програмне забезпечення lcg

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

Прикладом такого програмного забезпечення може служити ПЗ LCG (LHC Computing Grid), що розробляється в Європейському центрі ядерних досліджень (CERN). Спочатку метою проекту LCG була розробка повністю функціонуючої GRID-системи на базі Globus Toolkit для обробки даних у фізиці високих енергій. З часом область застосування LCG розширилася, і в даний час це – один з найпоширеніших пакетів, що швидко розвиваються, ПО GRID.

Пакет LCG складається з декількох частин, званих елементами. Кожен елемент є самостійним набором програм (одні і ті ж програми можуть входити в декілька елементів), що реалізовують деякий сервіс, і призначений для установки на комп'ютер під управлінням ОС Scientific Linux.

Нижче перераховані основні елементи LCG і їх призначення:

• CE (Computing Element) – набір програм, призначений для установки на вузол, що управляє, обчислювального кластера. Даний елемент надає універсальний інтерфейс до системи управління ресурсами кластера і дозволяє запускати на кластері обчислювальні завдання;

• SE (Storage Element) – набір програм, призначений для установки на вузол зберігання даних. Даний елемент надає універсальний інтерфейс до системи зберігання даних і дозволяє управляти даними (файлами) в GRID-системі;

• WN (Worker Node) – набір програм, призначений для установки на кожен обчислювальний вузол кластера. Даний елемент надає стандартні функції і бібліотеки LCG завданням, що виконуються на даному обчислювальному вузлі;

• UI (User Interface) – набір програм, що реалізовують призначений для користувача інтерфейс GRID-системи (інтерфейс командного рядка). У цей елемент входять стандартні команди управління завданнями і даними, деякі з яких розглянуті в наступному розділі;

• RB (Resource Broker) – набір програм, що реалізовують систему управління завантаженням (брокер ресурсів). Це найбільш складний (і об'ємний) елемент LCG, що надає всі необхідні функції для скоординованого автоматичного управління завданнями в GRID-системі;

• PX (Proxy) – набір програм, що реалізовують сервіс автоматичного оновлення сертифікатів (myproxy);

• LFC (Local File Catalog) – набір програм, що реалізовують файловий каталог GRID-системи. Файловий каталог необхідний для зберігання інформації про копії (репліках) файлів, а також для пошуку ресурсів, що містять необхідні дані;

• BDII (Infornation Index) – набір програм, що реалізовують інформаційний індекс GRID-системи. Інформаційний індекс містить всю інформацію про поточний стан ресурсів, отримувану з інформаційних сервісів, і необхідний для пошуку ресурсів;

• MON (Monitor) – набір програм для моніторингу обчислювального кластера. Даний елемент збирає і зберігає в базі даних інформацію про стан і використання ресурсів кластера.

• VOMS (VO Management Service) – набір програм, що реалізовують каталог віртуальних організацій. Даний каталог необхідний для управління доступом користувачів до ресурсів GRID-системи на основі членства у віртуальних організаціях.

На один комп'ютер можлива установка відразу декількох елементів LCG, якщо це дозволяють його потужності (об'єм пам'яті і продуктивність). Мінімальна кількість вузлів, необхідних для розгортання повного набору ПЗ LCG, рівна трьом. Слід відмітити, що установка всіх сервісів на один вузол, хоча і можлива технічно, але настійно не рекомендується. Брокер ресурсів, з міркувань безпеки, слід розташувати на окремому вузлі. Обчислювальні вузли також слід виділити окремо, оскільки навантаження, що створюється на них працюючими завданнями, приведе до дефіциту ресурсів для решти сервісів. Решта всіх елементів може бути встановлені спільно.

У основі ПО LCG лежать розробки, виконані в рамках європейського проекту EDG (European DataGrid) кілька років тому. Зараз проект LCG активно розвивається і стоїть на порозі переходу до нової, більш функціональній інфраструктурі програмного забезпечення, що носить назву gLite. Даний перехід має на увазі поступову заміну застарілих програм новими із збереженням сумісності.

Важливо відзначити, що все програмне забезпечення, що розробляється в рамках проекту LCG, може вільно використовуватися. На основі цього програмного забезпечення можливе створення національних і регіональних GRID-систем для ефективного розподілу локальних ресурсів. LCG є технологічною базою для інфраструктури, що реалізовується в рамках проекту EGEE.

4.5. glite

Навіть враховуючи появу в Globus Toolkit 4 нових служб (CAS, RLS), слід визнати, що головний напрям його розвитку - засоби розробки і підтримки служб. Основна відмінність комплексу glite в тому, що крім інструментальних засобів, в нього входить ширший набір служб. glite істотно спирається на досвід ряду крупних європейських проектів: EDG, LCG, Alien, NorduGrid і створюється колективно - в його розробці беруть участь більше 80 фахівців з 11 дослідницьких центрів. glite повинен стати основним ГПЗ проекту EGEE, прийшовши на зміну комплексу Lcg-2.

Приведемо огляд основних підсистем glite.

Обчислювальний елемент (Computing Element - CE) - це служба, що представляє ресурсний вузол GRID і що виконує на нім функції управління завданнями (запуск, видалення і так далі). Звернення до CE можуть надходити або від інтерфейсу користувача, або від Менеджера завантаження (Workload Manager -wm), який розподіляє завдання по безлічі CE. У glite функціональність CE розширена в порівнянні з аналогічною службою Lcg-2. Якщо в Lcg-2 CE може працювати тільки у відповідністі до Push моделі (WM самостійно ухвалює рішення про посилку завдання на CE), то в glite можливий режим роботи CE також і в Pull моделі, коли CE запрошує завдання у WM.

Крім функцій управління завданнями CE також виробляє інформацію про стан ресурсів. У Push моделі її публікує інформаційна служба, і вона використовується WM для вибору CE, на якому запускатиметься завдання. У Pull моделі інформація вбудовується в посилане WM повідомлення "CE доступний".

Підсистема управління даними (Data Management Subsystem - DM) включає три служби, що підтримують доступ до файлів: елемент пам'яті (Storage Element - SE), служби каталога (Catalog Services - CS) і диспетчер даних (Data Scheduling -ds). Всі служби працюють з даними на файловому рівні, в протилежність, наприклад, системам баз даних, які оперують такими елементами як записи і поля.

У розподіленому середовищі GRID призначені для користувача файли можуть зберігатися в безлічі екземплярів - реплік, розміщених в різних місцях, і завдання CS і DS полягає в тому, щоб зробити процес управління репліками прозорим для користувача, так щоб додатки діставали доступ до файлів по їх іменах або дескрипторах метаданих.

Доступ до даним файлів реально відбувається через SE, але DM підтримує також концепцію віртуальних наборів даних. Це відкриває нові цікаві можливості, засновані на абстракції глобальної файлової системи: при навігації по файлах клієнтське застосування може бути влаштоване як командна оболонка Unix, використовуючи команди зміни директорій, проглядання файлів і тому подібне Захист файлів забезпечується в DM списками контролю доступу ACL (Access Control Lists).

Підсистема обліку (Accounting Subsystem - DGAS) акумулює інформацію про використання ресурсів GRID окремими користувачами, групами користувачів і віртуальними організаціями. Зібрана інформація дозволяє побудувати загальну картину діяльності в GRID, на основі якої може формуватися політика розподілу ресурсів і стягуватися плата за їх використання.

Підсистема протоколювання (Logging and Bookkeeping - LB) відстежує кроки обробки завдання, виконуються в різних точках GRID, фіксуючи події (запуск, розподіл на відповідний CE, початок виконання і так далі), що відбуваються і запам'ятовуючи їх. Інформація про події (протокол) поставляється компонентами WM і CE, для чого в ці компоненти вбудовуються звернення до LB.

Протоколи збираються в два прийоми. Спочатку події передаються в локальну службу (Locallogger) і записуються у файл на диску. Locallogger відповідає за передачу протоколу одному з серверів зберігання (Bookkeeper), який "збільшує" події, даючи загальну картину зміни станів завдання (Submitted, Running, Done.). Крім того, Bookkeeper зберігає різні атрибути завдання: його опис (JDL); CE, на якому воно виконувалося; коди завершення і так далі Як протокол станів, так і протокол подій можна отримати або за допомогою спеціального інтерфейсу WM, або через повідомлення при певних змінах стану, наприклад, при закінченні завдання.

Підсистема інформаційного обслуговування і моніторингу GRID (Relational Grid Monitoring Architecture - R-GMA) вирішує задачу збору і управління даними про стан GRID, отримуючи інформацію від безлічі розподілених джерел - постачальників. У її основі лежить розроблена однією з груп Global Grid Forum (GGF-PERF) схема "Споживач-Постачальник", що описує спосіб взаємодії цих компонентів. Оскільки схема достатньо загальна, вона застосовна як для зберігання даних про GRID (які ресурси і служби доступні, які їх характеристики), так і для моніторингу додатків.

R-GMA є реляційною реалізацією цього загального підходу. За наявності безлічі розподілених постачальників з погляду інформаційних запитів R-GMA діє як одна велика реляційна база даних. "Реляційність" виявляється у формі представлення даних: постачальники оголошують про склад публікованої інформації за допомогою конструкції SQL CREATE TABLE, публікують її за допомогою SQL INSERT, а споживачі отримують дані через SQL SELECT.

Підсистема управління завантаженням (Workload Management System - WMS) складається з ряду компонентів, відповідальних за розподіл завдань між ресурсами GRID, а також що забезпечують управління завданнями. Центральною компонентой є Менеджер завантаження (WM), який отримує від своїх клієнтів запити по управлінню завданнями. Зокрема, обробляючи запит типу "запуск" WM визначає відповідний для виконання CE, зважаючи на вимоги і переваги, задані в описі завдання.

Система безпеки. Вона розглядається як засіб захисту Web-служб і реалізована у вигляді додаткових модулів, що розміщуються в контейнерах (Apache Axis, Tomcat). Розроблені пропозиції по архітектурі безпеки: https://edms.cern.ch/document/487004/ і сформульовані основні цілі: модульність, розширюваність, відповідність стандартам Web-служб, що розвиваються (Ws-security).