GRID technologies

1 МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ УКРАЇНИ «КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ» Навчально-науковий комплекс «Інститут прикладного системного аналізу» Петренко А.І., Свістунов С.Я., Кисельов Г.Д ПРАКТИКУМ З ГРІД- ТЕХНОЛОГІЙ Призначений для магістерської підготовки за спеціальністю 8.05010103 „Системне проектування ‖, але може бути корисним і для інших спеціальностей напрямків „Комп‘ютерні науки ‖ і „Комп‘ютерна інженерія ‖. Київ 2011 2 УДК 004.75; 681.3 Петренко А.І., Свістунов С.Я., Кисельов Г.Д. Практикум з грід-технологій. – Київ: НТУУ «КПІ», 2011. – 180 с.: іл. Анотація: Грід-технологій дозволяють об'єднати інформаційні і обчислювальні ресурси шляхом створення комп'ютерної інфраструктури нового типу, яка забезпечує глобальну інтеграцію ціх ресурсів на основі мережевих технологій і спеціального програмного забезпечення проміжного рівня (між базовим і прикладним ПЗ), а також набору стандартизованих служб для забезпечення надійного спільного доступу до географічно розподілених інформаційних і обчислювальних ресурсів: окремим комп'ютерів, кластерів, сховищ даних. Метою практикуму з грід-технологій є ознайомлення студентів з концепцією грід-комп‘ютингу та поточним станом справ у цій області та набуття практичних навичок з використання грід-технологій для аналізу, оптимізації та проектування інженерних об'єктів. Практикум призначений для проведення лабораторних занять з дисципліни «Грідтехнології для розподілених обчислень та обробки даних» магістерської підготовки за спеціальністю „Системне проектування‖, але може бути корисним і для інших спеціальностей напрямків „Комп‘ютерні науки‖ і „Комп‘ютерна інженерія‖. Практикум також може бути рекомендований студентам та аспірантам усіх спеціальностей, які вивчають сучасні інформаційні технології в межах своїх предметних галузей, а також їх викладачам. Відповідальний редактор Рецензенти: В.С. Рогоза, д-р техн.наук, проф. С.С. Забара, д-р техн.наук, проф. С.Г.Стіренко, к-т.техн.наук, доц. 3 ЗМІСТ Передмова .................................................................................................. 8 Завдання № 1. Вступ до грід-технології.............................................. 13 1 Короткі теоретичні відомості ............................................................ 13 1.1 Концепція грід.................................................................................. 13 1.2 Міжнародні грід-проекти................................................................. 23 1.3 Грід в Україні ................................................................................... 35 1.4 Навчальна грід-інфраструктура ..................................................... 42 1.5 Порядок виконання завдання: ........................................................ 48 1.6 Контрольні запитання ...................................................................... 49 Література ................................................................................................ 49 Завдання № 2. Робота на обчислювальному кластері з використанням локальної системи управління PBS .......................... 51 2.1 Короткі теоретичні відомості .......................................................... 51 2.1.1 Багатопроцесорної обчислювальної системи ............................. 51 2.2 Методика роботи на обчислювальному кластері ......................... 62 2.3 Корисні програми для роботи на кластері: .................................... 70 2.4 Приклад виконання роботи ........................................................... 83 2.5 Порядок виконання лабораторної роботи ................................... 89 2.6 Завдання до лабораторної роботи .................................................. 90 2.7 Контрольні запитання ..................................................................... 90 Література ................................................................................................ 91 Завдання № 3. Отримання сертифікату користувача .......................... 92 3 Короткі теоретичні відомості ............................................................ 92 3.1 Інфраструктура відкритого ключа ................................................. 92 4 3.2 Ідентифікація користувачів і Grid вузлів ...................................... 97 3.3 Делегування прав і використання довіреності ............................. 99 3.4 Сервіс управління віртуальними організаціями і авторизація користувачів .......................................................................................... 102 3.5 Користувач в GRID........................................................................ 107 3.6 Порядок виконання роботи .......................................................... 109 3.7 Завдання до лабораторної роботи ............................................... 122 3.8 Контрольні питання ....................................................................... 122 Література .............................................................................................. 123 Завдання № 4. Проміжне програмне забезпечення грід - ARC ..... 124 4 Короткі теоретичні відомості .......................................................... 124 4.1 Архітектура та основні компоненти ARC................................... 126 4.2 Система керування завданнями ................................................... 138 4.3. Команди інтерфейсу користувача .............................................. 144 4.4 Команди роботи з даними............................................................ 164 4.5 Команди тестування ....................................................................... 169 4.6 Опис завдання ................................................................................. 171 4.7. Приклад виконання лабораторної роботи ................................... 180 4.8 Завдання до лабораторної роботи ................................................ 186 4.9. Контрольні питання ....................................................................... 187 Завдання №5. Проміжне програмне забезпечення грід - gLite ........ 189 5 Короткі теоретичні відомості ......................................................... 189 5.1. Архітектура та основні компоненти GLITE .............................. 190 5.2 Система управління завданнями .................................................. 207 5 5.3 Опис завдання ................................................................................ 229 5.4 Приклад виконання лабораторної роботи ................................... 247 5.5 Завдання до лабораторної роботи ................................................ 256 5.6 Контрольні питання ....................................................................... 257 Завдання № 6. Інформаційна система і моніторинг ........................ 258 6 Короткі теоретичні відомості .......................................................... 258 6.1 Інформаційна система gLite ......................................................... 258 6.1.1 Система Globus Monitoring and Discovery Service (MDS) ...... 259 6.2 Система (Relational Grid Monitoring Architecture) R-GMA ....... 272 6.3. Інформаційна система NorduGrid ARC ....................................... 274 6.4 Моніторинг грід-системи. Основні положення.......................... 276 6.5 Приклади засобів моніторингу грід-систем ............................... 280 6.6 Доступ до даних інформаційної системи gLite .......................... 288 6.8 Доступ до даних інформаційної системи ARC .......................... 303 6.9 Завдання до лабораторної роботи .............................................. 308 6.10 Контрольні питання.................................................................. 308 Література .............................................................................................. 309 Завдання № 7. Реєстрація і отримання користувачем доступу до грідсистеми через веб- сервіс ..................................................................... 311 7.1 Короткі теоретичні відомості. Концепція наукового шлюзу (Science Gateways) ................................................................................ 311 7.2 Інструментальні засоби побудови грід- порталів застосувань .. 316 7.3 Інструментальні засоби на основі Globus Toolkit ....................... 317 7.4 Інструментальний засіб GridSpeed ............................................. 319 7.5 Проект Grid Programming Environment ....................................... 321 6 7.6 Інструментальний засіб GridSphere Portal Framework ................ 328 7.7 Приклад виконання практичної роботи ....................................... 334 7.8 Завдання до практичної роботи .................................................... 341 7.9 Контрольні питання ........................................................................ 342 Література .............................................................................................. 342 Додатки до практикуму з грід-технологій ....... Ошибка! Закладка не определена. 7 Передмова Грід є технологією забезпечення гнучкого, безпечного і скоординованого загального доступу до ресурсів. При цьому слово «ресурс» розуміється в дуже широкому сенсі, тобто ресурсом може бути апаратура (жорсткі диски, процесори), а також системне і прикладне програмне забезпечення (бібліотеки, програми). Таким чином, грід претендує на роль універсальної інфраструктури для обробки даних, в якій функціонує множина сервісів, які дозволяють дати нову якість рішення різних класів задач. Особливо – таких, які неможливо вирішити у адекватні строки локально на одному, навіть найпотужнішому комп‘ютері:  масова обробка потоків даних великого об'єму;  багато параметричний аналіз даних;  моделювання на віддалених суперкомп'ютерах;  реалістична візуалізація великих наборів даних;  складні бізнес-додатки з великими об'ємами обчислень. В умовах розподіленого програмного забезпечення, а також віддалених робочих місць користувачів і ресурсів виконання операцій у грід ініціюється видачею запиту до деякої служби (сервісу) і здійснюється, як правило, послідовністю взаємодіючих служб, кожна з яких виконує частину необхідної обробки. Надійність обробки запиту забезпечується шляхом моніторингу збоїв і повторного запиту на альтернативних ресурсах. Грід-технології і всесвітня грід-мережа ідуть на зміну вже звичному Інтернету з його веб - послугами як засіб сумісного використання обчислювальних потужностей та сховищ даних. Тому серед пріоритетних напрямків інформатизації та розвитку сучасних інформаційних технологій в Україні в Постанові Кабінету Міністрів 8 України №1020 від 23 вересня 2009 року «Державна цільова науковотехнічна програма впровадження і застосування грід-технологій на 2009-2013 роки» були зазначені задачі створення Національної грідінфраструктури для наукових досліджень і розгортання підготовки і перепідготовки фахівців, здатних забезпечити функціонування грідсередовища і застосування грід- технологій в науці, освіті та інших галузях, оскільки грід-технології є досить новим напрямком в інформаційних технологіях і в Україні бракує таких фахівців. Сфера застосування грід-технологій не обмежується лише вирішенням складних наукових і інженерних задач. Із розвитком грід проникає в промисловість і бізнес. Грід-технології вже активно застосовуються у світі як державними організаціями управління, оборони, сфери комунальних послуг, так і приватними компаніями, наприклад, фінансовими і енергетичними. Область застосування грід зараз охоплює ядерну фізику, захист навколишнього середовища, прогноз погоди і моделювання кліматичних змін, чисельне моделювання в машино - і авіабудуванні, біологічне моделювання, фармацевтику тощо. Постановою Ради Міністрів України в 2011 році була з ініціативи ННК «Інститут прикладного системного аналізу» введена нова спеціальність «Системне проектування» з напрямку «Комп‘ютерні науки» для підготовки фахівців у сфері застосувань розподілених інтелектуальних середовищ і , зокрема, грід- технологій в науці і освіті. Для її реалізації розпочато викладання дисципліни „Грід – технології для розподілених обчислень та обробки даних ”, яка узагальнює сьогоднішнє уявлення про грід - технології та проблеми, яки виникають на шляху їх розроблення і впровадження. У результаті вивчення дисципліни студенти повинні: 9 ▪ знати: основи грід – технологій, які дозволяють об‘єднати обчислювальні ресурси та ресурси зберігання даних, архітектуру грід – систем, які використовуються в Україні, принципи функціонування основних складових частин грід–системи, технологію підготовки завдань для використання грід – середовища; ▪ вміти: вибирати і використовувати проміжне програмне забезпечення для вирішення науково – практичних завдань, адаптувати пакети прикладних програм до середовища грід, використовувати вхідні мови опису завдання і даних, відслідковувати хід обчислювального процесу під час числового експерименту чи процесу моделювання; ▪ набудуть навички: практичного використання найбільш поширеного проміжного програмного забезпечення gLite та ARC. Даний практикум містить необхідний теоретичний матеріал, приклади виконання завдань і є навчально-методичним забезпеченням дисципліни «Грід – технології для розподілених обчислень та обробки даних». Він призначений для прискорення підготовки фахівців з грід технологій, навчання їх роботі з цими новими засобами, зокрема, при застосовуванні в чисельних розрахунках, що потребують великих комп‘ютерних ресурсів. експериментальних Він складається з виконання циклу досліджень, націлених на набуття практичних навичок використання грід – технології для вирішення науково – практичних завдань: ▪ робота на обчислювальному кластері з використанням локальної системи управління PBS для вивчення технології віддаленого доступу до ресурсів багатопроцесорної обчислювальної системи та набуття практичних знань та навичок компіляції та запуску простих програм з використанням системи управління кластера; 10 ▪ отримання сертифікату користувача, для чого користувач вчиться генерувати пару ключів: відкритий ключ (як частина сертифікату) та закритий ключ (для підпису сертифікату); отримувати сертифікат, створювати проксі-сертифікат та користуватися їм; ▪ вивчення технології видаленого доступу до грід-ресурсів, що працює під управлінням проміжного програмного забезпечення ARC, коли користувач, використовуючи обчислювальний кластер під управлінням UNIX - сумісною ОС, розробляє файл завдання на мові xRSL для запуску через ППЗГ ARC згідно варіанта завдання, запускає задачу з сервера доступу, попередньо створивши проксі-сертифікат, під час виконання задачі перевіряє її статус; ▪ вивчення технології видаленого доступу до грід-ресурсів, що працює під управлінням проміжного програмного забезпечення gLite, коли користувач розробляє файл завдання на мові JDL для запуску через ППЗГ gLite згідно варіанта завдання,запускає задачу з сервера доступу, попередньо створивши проксі-сертифікат, перевіряє її статус під час виконання , отримує результати виконання і аналізує їх; ▪ вивчення побудови інформаційної системи і системи моніторингу промислових грід - систем, що працюють під управління проміжного програмного забезпечення gLite і ARC і вирішують задачу збору і управління даними про стан грід, отримуючи інформацію від безлічі розподілених джерел - постачальників. Підсистема призначена для постійного контролю функціонування грід-системи і забезпечення своєчасного реагування на виникаючі проблеми. Таким чином, з допомогою цього практикуму можна, отримавши сертифікат, готувати свої задачі для запуску, вибирати обчислювальний елемент, на якому виконуватиметься завдання, контролювати процес виконання, проглядати результати виконання завдання і зберігати 11 вихідні файли на комп'ютері користувача. Передбачається, що користувачі практикуму зможуть під час навчання через українську національну грід- інфраструктуру набути практичний досвід роботи з обчислювальними ресурсами суперкомп‘ютерів НТУУ‖КПІ‖ і Інституту теоретичної фізики та інших, об‘єднаних в сумісну мережу, а також з інформаційними ресурсами Світового «Геоінформатика і сталий розвиток». 12 Центру Даних (СЦД) Завдання № 1. Вступ до грід-технології Мета: вивчення основ грід – технологій, які використовуються для забезпечення наукових досліджень, стану їх впровадження в світі і Україні, базових інформаційних мережевих джерел про існуючі грідсистеми і грід-застосування. 1 Короткі теоретичні відомості 1.1 Концепція грід Останні десять років є роками зародження та розвитку нового напрямку в інформаційних технологіях, назву якому (як традиційно вважається) дали у 1998 році Я.Фостер та К.Кессельман – «Грід» (англ. «Grid») [1]. Грід, як засіб сумісного використання обчислювальних потужностей та сховищ даних, дозволяє вийти за межі простого обміну даними між комп‘ютерами і зрештою перетворити їх на свого роду гігантський віртуальний комп‘ютер, доступний у режимі віддаленого доступу з будь-якої точки, незалежно від місця розташування користувача. Грід-технології використовуються для створення географічно розподіленої обчислювальної інфраструктури, яка поєднує ресурси різних типів з колективним доступом до цих ресурсів в рамках віртуальних організацій, які складаються з підприємств і фахівців, які спільно використовує ці загальні ресурси. Розвиток і впровадження грід-технологій носять стратегічний характер. У найближчій перспективі ця технологія дозволить створити принципово новий обчислювальний інструмент для розвитку високих технологій у різних сферах людської діяльності. В 2004 році Джордж Буш офіційно оголосив про початок президентської стратегічної грід-програми (Strategic Grid Computing 13 Initiative), основною метою якої є «створення єдиного національного простору високопродуктивних обчислень». Критичні (проривні) технології в державах, що будують економіку, засновану на знаннях, досліджуються й розробляються на базі широкого використання високопродуктивних обчислень. І іншого шляху немає. Не маючи потужної суперкомп'ютерної інфраструктури: • неможливо створити сучасні вироби високої (аерокосмічна техніка, судна, енергетичні блоки електростанцій різних типів) і навіть середньої складності (автомобілі, конкурентоспроможна побутова техніка і т.п.); • неможливо швидше конкурентів розробляти нові ліки й матеріали із заданими властивостями; • неможливо розвивати перспективні технології (біотехнології, нанотехнології, альтернативну енергетику майбутнього і т.п.) Сьогодні суперкомп'ютерні технології по праву вважаються найважливішим чинником для забезпечення конкурентоспроможності економіки країни, а єдиний спосіб перемогти конкурентів - це можливість обігнати їх у обчисленнях. Тут доречні слова Президента Ради з конкурентоспроможності США: «Технології, таланти й гроші доступні багатьом країнам. Тому США стоять перед загрозою непередбачуваних закордонних економічних конкурентів. Країна, що бажає перемогти в конкуренції, повинна перемогти в обчисленнях» . Неважливо, про конкуренцію в якому секторі економіки йде мова: наведене вище стосується як традиційних переробних секторів економіки, видобувних і так і нових технологій. Тому в розвинених країнах світу для переходу до економіки знань створюється нова інфраструктура держави –– державна система з потужних суперкомп'ютерних центрів, об'єднаних надшвидкісними каналами зв'язку в грід-систему. Тобто, по суті, мова йде про національну 14 науково-дослідну інформаційно-обчислювальну мережу. Для такої системи часто використовують термін «кібер-інфраструктура». США витрачала у 2005-2009 роках на створення національної кіберінфраструктури від 2 до 4 млрд. доларів на рік з державного бюджету. Як наслідок цього, в США вже успішно функціонують чотири національні грід-мережі, яки перебувають під турботливою опікою ключових державних відомств: комп'ютерна мережа національного фонду наукових досліджень (NSF Computing Grid), інформаційна мережа підтримки НАСА (NASA Information Power Grid), глобальна інформаційна мережа міністерства оборони (DOD GI Grid) і мережа суперкомп'ютерної ініціативи міністерства енергетики (DOE ASCI Grid). Одночасно суперкомп'ютери із й цим оновлюються розвиваються мережі і будуються наукових нові установ і університетів. Велику увага грід-технологіям в останні роки приділяє й керівництво Євросоюзу. В 2005 році Європейська Комісія підготувала спеціальну програму загальним кошторисом у 13 млрд. євро, у рамках якої грід-компьютингу відводиться роль стимулятора і найважливішого ресурсу для перетворення Євросоюзу в «саму конкурентоспроможну у світі економіку знань». В липні 2006 року китайські засоби масової інформації оголосили про завершення роботи над Китайським освітнім грід-проектом (China Educational Grid Project - CEGP). CEGP об'єднав комп'ютерні мережі декількох десятків найбільших університетів країни і надав мільйонам китайських студентів прямий доступ до баз даних, інтерактивних навчальних курсів і до сервісних додатків з самих різних напрямків і дисциплін. Зовсім недавно до цього альянсу підключилася Індія, яка 15 реалізує власну Національну грід-ініціативу GARUDA, яка об'єднує в грід-мережу 17 найбільших науково-дослідних центрів країни. Успішно розвивається проект «Скіф Грід» в рамках об‘єднаної програмі Білорусії та Росії. Проект «Скіф Грід» курирує Об'єднаний інститут інформатики. В основні завдання проекту входять розробка й створення мережі, яка зв'яже воєдино суперкомп'ютери «Скіф» (вже встановлено більш 60 у Білорусії і Росії) і всі обчислювальні центри. Така розподілена система одержала назву - "СКІФ Полігон". За свідченням співробітників інституту інформатики, грід-технології, засновані на мережній інтеграції обчислювальних процесів, дозволяють різним командам працювати разом, багаторазово підсилюючи використання суперкомп'ютерів за рахунок кооперації. Ідея використовувати мережу суперкомп‗ютерів для вирішення складних завдань, мабуть, зародилася набагато раніше (спроби робилися з 60-х років ХХ століття ), однак зараз вона набула завершеної форми у вигляді «концепції грід». Традиційно засновниками розвитку грід - обчислень вважають фізиків-ядерників, і дотепер їх потреба в обробці величезних об‗ємів експериментальних даних є рушійною силою для реалізації програм з впровадження грід. Досить згадати хоча б діяльність Європейського центру ядерних досліджень (CERN), де встановлений Великий Андронний Коллайдер. Однак, грід-технології успішно застосовуються і в інших галузях науки і техніки, оскільки пропонують універсальний підхід до вирішення проблеми нестачі обчислювальних ресурсів: адже очевидно, що в загальному випадку мережа суперкомп‗ютерів спроможна вирішити складніші задачі, ніж кожен з її складових окремо. Якщо перекладати дослівно, грід означає «сітка, ґрати». Погодьтеся, асоціації, пов‘язані в нашій мові з цим словом, зовсім не 16 відповідають змісту вільної кооперації суперкомп‘ютерів для високопродуктивних обчислень, яка покладена в основу грід-технологій. Найближче за смислом, мабуть, поняття power grid – мережа електроживлення, розподілений ресурс загального користування, коли кожен може легко підключитися через розетку і використовувати стільки електроенергії, скільки йому потрібно. Аналогічно користувачі з допомогою грід отримують можливість прямого підключення до віддаленої обчислювальної мережі, не цікавлячись, звідки беруться потрібні для роботи обчислювальні ресурси й ресурсі зберігання даних, які для цього використовуються мережі передачі даних, паролі доступу чи протоколи тощо. При цьому аналогом інфраструктури електричних мереж (ліній електропередачі, диспетчерських пунктів підстанцій, трансформаторів, та ін.) виступає грід–інфраструктура з проміжним програмним грід забезпеченням (Middleware), за допомогою якого виконується „віртуалізація‖ ресурсів. Проте слід зазначити, що хоч динаміка розвитку в цій галузі дозволяє сподіватися на успішне якнайширше впровадження грідтехнологій у найближчому майбутньому, багато питань все ще є предметом дискусій і досліджень. Нижче коротко перераховуються та пояснюються основні властивості грід, до яких відносять:  Спільне використання розподілених ресурсів. Грід відкриває можливості з співробітництва, яких були б важко досягти іншими засобами. Водночас виникають питання «справедливості» розподілу ресурсів, створення та управління віртуальними організаціями (ВО).  Об‘єднання обчислювальних потужностей. Таким чином будується система з сумарною потенційною обчислювальною потужністю, що перевершує потужності її складових, і при цьому досягається більш ефективне використання апаратних засобів, зменшення часу простою. 17 Для досягнення цієї мети необхідні досконалі канали зв‗язку з досить жорсткими вимогами до їх параметрів.  Віртуалізація. Включає в себе такі поняття, як маскування від користувача складності апаратної та програмної реалізації системи та її складових, географічних відстаней між вузлами, приналежності вузлів різним організаціям, створення ілюзії роботи з «віртуальним суперкомп‗ютером».  Неоднорідність (гетерогенність). Типова грід-система складається з множини різнорідних апаратних засобів та різноманітного програмного забезпечення (і має успішно функціонувати в таких умовах).  Децентралізоване управління. Немає єдиного «власника» всієї системи, що вимагає використання механізмів розподіленого управління.  Інтероперабельність. Функціональна сумісність роботи різних компонентів грід та навіть різних грід-інфраструктур базується на стандартизації інтерфейсів. Підходи, що не враховують стандартів, є мало перспективними.  Прозорість доступу. Грід має надавати доступ до ресурсів користувачам, не зважаючи на конкретну топологію мережі чи локальну реалізацію механізмів доступу до тих чи інших вузлів та їх ресурсів.  Масштабованість. Грід має забезпечувати механізми підключення нових обчислювальних ресурсів, користувачів, сховищ даних тощо без впливу на існуючих учасників: грід повинен мати здатність динамічно реконфігуруватись.  Безпека. Одна з головних вимог до грід-системи – безпека доступу до ресурсів, що зумовлює обмежений набір дозволених операцій для авторизованих користувачів та програм. 18 Ідейною основою технології грід є об'єднання ресурсів шляхом створення комп'ютерної інфраструктури нового типу, яка забезпечує глобальну інтеграцію інформаційних і обчислювальних ресурсів на основі мережевих технологій і спеціального програмного забезпечення проміжного рівня (між базовим і прикладним ПЗ), а також набору стандартизованих служб для забезпечення надійного спільного доступу до географічно розподілених інформаційних і обчислювальних ресурсів: окремим комп'ютерам, кластерам, сховищам даних. Поява технології грід обумовлено наступними передумовами:  необхідністю вирішення складних наукових, виробничих, інженерних і бізнес-задач;  стрімким розвитком мережевого транспортного середовища й технологій високошвидкісної передачі даних;  наявністю в багатьох організаціях обчислювальних ресурсів суперкомп'ютерів або, що найбільше часто зустрічається, організованих у вигляді кластерів персональних комп'ютерів. До теперішнього часу вже реалізовані й реалізуються міжнародні проекти з створення грід-систем. Більша частина цих проектів має експериментальний характер, але є і приклади промислових реалізацій. Виходячи з результатів аналізу проектів, можна зробити висновок про три напрямки розвитку грід-технологій: обчислювальний грід, грід для інтенсивної обробки даних і семантичний грід для обробки і інтелектуального аналізу даних з різних баз даних. Метою першого напрямку є досягнення максимальної швидкості обчислень за рахунок глобального розподілу обчислень між комп'ютерами. Проект DEISA (www.desia.org) може бути прикладом цього напрямку. Метою другого напрямку є обробка величезних об'ємів даних 19 відносно нескладними програмами за принципом «одна задача – один процесор». Доставка даних для обробки на обчислювальний ресурс і передача результатів обчислення у цьому випадку являють собою досить складну задачу. Для цього напрямку грід-інфраструктура представляє собою об'єднання обчислювальних кластерів. Один із проектів, метою якого і є створення промислової грід-системи для обробки наукових даних, є проект EGEE (Enabling Grids for E-sciencE) та його продовження EGI (European Grid Initiative), який виконується під егідою Європейського Союзу (www.eu-egee.org). Учасниками цього проекту є більше 90 наукових і освітніх установ із усього миру. Метою третього напрямку є обробка і аналіз даних з різних баз даних для виявлення в первинних даних раніше невідомих, нетривіальних, практично корисних інтерпретацій знань, необхідних для прийняття рішень у різних сферах людської діяльності. Це нова технологія інтелектуального аналізу даних прихованих у закономірностей вигляді з метою виявлення значущих особливостей, кореляцій, тенденцій і шаблонів. Сучасні системи, так звані здобичі даних, використовують засновані на методах штучного інтелекту засоби уявлення і інтерпретації, що і дозволяє знаходити розчинену в терабайтних сховищах не очевидну, але вельми цінну інформацію. Даний напрямок розвитку грід-технологій на даний час має експериментальний характер і знаходиться в стадії розвитку. Незважаючи на досить тісну взаємодію багатьох проектів, конкретні реалізації грід- систем відрізняються друг від друга, хоча до теперішнього часу з достатньою визначеністю спостерігається тенденція стандартизації більшості компонентів. Із самих загальних позицій ця технологія характеризується простим набором критеріїв:  координація використання ресурсів при відсутності централізованого 20 керування цими ресурсами;  використання стандартних, відкритих, універсальних протоколів і інтерфейсів;  забезпечення високоякісного обслуговування користувачів. Концепція грід базується на наступних технологічних досягненнях:  швидке та постійне збільшення продуктивності мікропроцесорів масового виробництва (сучасний персональний комп'ютер на базі процесора може зрівнятися за швидкістю обчислень із суперкомп'ютерами 10-літньої давнини);  поява швидкісних оптоволоконних ліній зв'язку: сьогодні в розвинених країнах базові лінії зв'язку в мережі Інтернет мають пропускну здатність 10 Гб/с і вище, а підключення до мережі багатьох наукових організацій відбувається на швидкості в 1-2 Гб/с;  феномен Інтернету, глобалізація процесу обміну інформацією й інтеграції світової економіки;  безперервне вдосконалювання технологій і засобів інформаційної безпеки. По суті грід є «надбудовою» над Інтернет. Його основне призначення - організація розподілених обчислень для рішення складних задач науки й технології, які вимагають більших обчислювальних ресурсів (потужності комп'ютерів, ресурсів зберігання даних) і зменшення часу обчислень. На відміну від безструктурної мережі Інтернет, грід - чітко впорядкована система. Певною мірою грід можна умовно назвати обчислювальним Інтернет. Користувач, підключаючись до грід, отримує доступ до потужності тисяч обчислювальних серверів, на яких він може здійснювати обчислення й 21 зберігати як величезні масиви даних, так і інформацію про результати їхньої обробки. У цій мережі приділяється першорядна увага проблемам безпеки - адже анонімність, зручна при спілкуванні в Інтернет, може стати надзвичайно небезпечної при роботі з науковими або практичними даними. Запитуючи яку-небудь інформацію в глобальній базі даних грід, користувач одержить вичерпну відповідь на питання про її достовірність, повноту й доступність. Відомо, що зараз у світі близько 500 млн. персональних комп'ютерів, однак, у середньому використовується всього лише 15% цих обчислювальних ресурсів! Система грід- обчислень дозволить більш ефективно використати наявну базу обчислювальних ресурсів. У комп'ютерних грід-системах різні організації, яки мають загальні наукові або практичні інтереси, на добровільній основі створюють об'єднання, що у грід-технологіях називається віртуальною організацією(ВО). Учасники віртуальної організації зв'язані між собою за допомогою Інтернет таким чином, що їхні обчислювальні потужності поєднуються. Система містить у собі обчислювальні ресурси і ресурси зберігання даних, але при цьому кожна організація контролює використання своїх ресурсів. Користувачі можуть одержувати практично необмежені ресурси для обчислень і зберігання даних, не замислюючись про їхнє походження. Кожний з учасників надає свої обчислювальні ресурси (або їхню частину) для використання іншими учасниками і в той же час отримує доступ до ресурсів інших учасників. Розвиток грід-технологій стає стратегічним національним завданням. На сьогодні країна, яка не має власної розвинутої грід-інфраструктури, навіть не зможуть претендувати на статус розвинутої країни. 22 1.2 Міжнародні грід-проекти е-Наука і грід-проекти EGEE та EGI В наукової літературі використовується термін е-Наука (e-Science), який характеризує сучасний підхід до науки, який включає підтримку розподіленої глобальної співпраці вчених за допомогою Інтернет і віртуалізації величезних сховищ даних, комп‘ютерних ресурсів ї наукового обладнання. На даний час вченим проводити збір і Інтернет і обробку грід дозволяють величезних масивів експериментальних даних або результатів моделювання, розроблення засобів моделювання і аналіз даних, забезпечують віддалений доступ до складних приладів і обмін інформацією в рамках розподілених, міждисциплінарних співтовариств дослідників. На початкової стадії свого розвитку грід-технології призначалися для вирішення складних наукових, виробничих і інженерних завдань, які неможливо вирішити в розумні терміни на окремих обчислювальних пристроях. Проте тепер область застосування грід-технологій не обмежується тільки цими типами завдань. Поступово грід проникає в промисловість і бізнес, великі підприємства створюють грід-системи для вирішення власних виробничих завдань. Таким чином, грід претендує на роль універсальної інфраструктури для обробки даних, в якій функціонує безліч грід-сервісів, що дозволяють вирішувати не тільки конкретні прикладні завдання, але і пропонують сервісні послуги: пошук необхідних ресурсів, збір інформації про стан ресурсів, зберігання і доставка даних. Область застосування грід зараз охоплює ядерну фізику, захист навколишнього середовища, прогноз погоди і моделювання кліматичних змін, чисельне моделювання в машино - і авіабудуванні, біологічне моделювання, фармацевтику. 23 Декілька прикладів для демонстрації суті проблеми. Компанія InSiteOne – американська компанія, яка працює у сфері медичних зображень. Вони заявляють, що річна кількість рентгенівських зображень в США перевищує 420 мільйонів і має щорічний приріст в 12%. Типове зображення містить багато мегабайт цифрових даних і повинно зберігатися як мінімум п'ять років. У Великобританії, програма e-Science зараз розглядає можливість фінансування проекту з створення маммографічного архіву. Кожна маммограма містить 100 мегабайт даних і повинна зберігатися з відповідними метаданими. На даний момент у Великобританії щорічно створюється близько 3 мільйонів маммограм. У США для порівняння створюється 26 мільйонів маммограм, що містять багато петабайт даних. Критичною проблемою для таких медичних зображень ( як і для всіх медичних цифрових даних) є проблема точності і чистоти цих даних. Це означає, що в більшості випадків немає можливості використовувати різні методи стиснення, які могли б істотно зменшити розміри даних, що зберігалися. Іншим ключовим питанням для таких медичних даних є безпека, оскільки секретність і конфіденційність даних пацієнта є найголовнішим моментом для довіри таким технологіям. У Великобританії загальні вимоги до кількості даних, яки зберігаються для соціальних наук, збільшилися з 400 гігабайт в 1995-му році до більш ніж терабайта в 2001. Хоча подальше зростання і прогнозується, загальний об‘єм не повинен перевищити сотні терабайт до 2010 року. Архів ESRC в Ессексі, підрозділ MIMAS в Манчестері і підрозділ EDINA в Единбурзі мають досвід в управлінні архівами для соціальних наук. Підрозділи MIMAS і EDINA забезпечують доступ до статистики переписів Великобританії, постійних урядових опитів, 24 банків макроекономічних даних, наборів цифрових карт, бібліографічних баз даних і електронних журналів. Також зараз створюються величезні історичні бази даних. Подібну картину можна спостерігати і в інших країнах. Для оброблення подібних масивів даних сьогодні функціонують сотні галузевих і міждисциплінарних грід-проектів, деякі з котрих приведені в табл.1.1 [2]. Вони можуть бути цікавими для студентів, які повинні активно користуватися новими досягненнями у сфері обчислень, у контексті їх застосування до прикладних галузей. Таблиця 1.1 Перелік відомих в світі грід-проектів Назва проекту Короткий опис Контактна інформація Проекти з фізики Grid Physics Грід-інфраструктура для Network обробки великих масивів www.griphyn.org даних з фізики Particle Physics Обчислювальний грід Data Grid для потреб фізики http://www.ppdg.net/ елементарних частинок LHC Computing Грід- інфраструктура для http://lcg.web.cern.ch/LCG/ Grid обчислень та збереження даних результатів експериментів на LHC (Великому Адронному Коллайдері) CERN Fusion Грід-інфраструктура для Collaboratory фізики синтезу International Грід база даних для Virtual потреб фізики та 25 http://www.fusiongrid.org/ http://www.ivdgl.org/ Datagridlab астрономії Проекти з астрофізики NEMO Project Обчислення для http://nemoweb.lns.infn.it/ підводного телескопа Черенкова, для виявлення високоенергетичних частинок ANTARES Обчислення для іншого http://antares.in2p3.fr/ підводного телескопа, для виявлення високоенергетичних частинок MAGIC Моделювання впливів на http://wwwmagic.mppmu.mpg атмосферу космічних .de/introduction/ вітрів Проекти з астрономії ESA Planck Створення http://www.rssd.esa.int/index.p mission мікрохвильової карти hp?project=Planck неба ASTROGRID Віртуальна обсерваторія http://www.astrogrid.org/ (Великобританія) US Virtual Віртуальна обсерваторія Observatory (США) http://www.us-vo.org/ Проекти з наук про Землю Cooperation for Співпраця з http://www.quakes.uq.edu.au/ Earthquake моделювання та ACES/ 26 Simulation передбачення землетрусів Geosciences Grid Грід для підтримки http://www.geongrid.org/ досліджень з наук про Землю EarthSystemGrid Проект з аналізу впливів http://www.earthsystemgrid.org/ на клімат, та передбачення довгострокових кліматичних змін Інженерія Geodise: Грід- система по http://www.geodise.org/ Aerospace Design розробці та оптимізації Optimisation інженерних рішень Біохімія, медицина Molecular Розробка віртуальної Modelling for лабораторії для Drug Design досліджень з http://www.gridbus.org/vlab/ молекулярної біології Neuro Science - Грід-система для http://www.gridbus.org/neuro Brain Activity обробки результатів grid/ Analysis зчитування активності головного мозку Bioinformatics Дослідження в області http://www.bbsrc.ac.uk/funding/ and e-science стволових клітин, opportunities/index.htm programme активності головного мозку 27 CHARON Один із під проектів http://egee.cesnet.cz/en/voce/ EGEE з використання Charon.html грід для обчислювальної хімії OpenMolGrid Відкритий проект http://www.openmolgrid.org/ обчислювального грід для молекулярної хімії та інженерії Grid-Enabled Грід-система для Medical медичного моделювання http://www.gemss.de/ Simulation Services Biomedical Система з досліджень в Informatics галузі біоінформатики http://www.nbirn.net/ Research Network Medical Data Система з досупу до Grid http://rainbow.essi.fr/wiki/dok Manager -розподілених баз uwiki/doku.php?id=public_na медичних знань mespace:mdm Міжгалузеві проекти DataGrid Мета проекту - http://eu- побудувати наступне datagrid.web.cern.ch/eu- покоління datagrid/ обчислювальної інфраструктури, що забезпечує інтенсивні обчислення і аналіз 28 великих баз даних спільного використання, які містять від сотень Терабайт до Петабайт інформації. Datacentric Grid Грід-система для http://research.cs.queensu.ca/h Project інтенсивних операцій з ome/skill/datacentric.html даними, які майже не переміщуються. Іншими словами, є бажання змінити традиційний погляд на те, що процесори - головний ресурс в системах і тому дані повинні переміщуватися до процесорів. Оpen grid Відкрита грід- http://www.opensciencegrid.or infrastructure for інфраструктура для g/ science науки Enabling Grids Європейська грід- for E-sciencE інфраструктура для е- http://www.eu-egee.org/ науки Berkeley Open Берклі відкрита Infrastructure for інфраструктура для Network мережевих обчислень http://boinc.berkeley.edu/ Computing 29 (BOINC) EUROGRID Проект демонструє http://www.eurogrid.org/ використання Грід в відібраних наукових і індустріальних галузях (біотехнології, метео, автоматизації інженерії, розвитку технологій і високопродуктивних обчислень), враховуючи специфічні вимоги цих галузей. International Grid (iGrid) Проект Ілінойсівського університету і http://www.isoc.org/inet99/pro ceedings/4a/4a_2.htm університету Індіани з першої демонстрації можливостей грідтехнологій і їх подальшого розвитку з участю партнерів з Австралії, Канади, Німеччини, Японії, Нідерландів, Росії, Швейцарії, Сінгапуру і Тайваню. 30 Стислий огляд проектів, наведених в табл.1.1, приведено в [2]. Ми ж детально розглянемо європейський проект лише EGEE і його подовження – проект EGI [11]. Мета проекту EGEE (Enablіng Grіds for E-scіence іn Europe) - об'єднати національні, регіональні і тематичні грід-розробки в єдину грід-інфраструктуру для підтримки наукових досліджень, які виконуються науковими установами Європи. Ця інфраструктура надає дослідникам (як в академічних колах, так і в різних областях економіки) цілодобовий доступ до високопродуктивних обчислювальних ресурсів незалежно від їхнього географічного розташування. Проект підтримувався та фінансувався Європейської комісією. Проект стартував у 2004 році у винятково сприятливих умовах: до його формального початку в проекті EDG вже були розроблені і розміщені основні сервіси і почата розробка проміжного програмного забезпечення і поширення інформації. Рис.1.1 - Етапи розвитку проекту EGEE Проект мав три стадії (рис.1.1), в результаті реалізації яких було розроблено проміжне програмне забезпечення gLite і побудована промислова грід-інфраструктура. Весь бюджет проекту був розподілене наступним чином: 24% - науково дослідні розробки; 28% - розробка та впровадження сервісів; 48% - підтримка та розвиток існуючих мереж та грід-систем. 31 Основними завданнями проекту EGEE були:  поширення інформації про грід-технології;  залучення нових користувачів, їх навчання;  підтримка додатків;  підтримка і обслуговування грід-інфраструктури і взаємодія з основними провайдерами;  розробка і інтеграція програмного забезпечення проміжного рівня;  забезпечення безпеки грід-систем;  розробка мережевих сервісів. Для виконання цих завдань були сформовані дослідницькі інтернаціональні групи за напрямками: JRA1 – розробка та інтеграція проміжного програмного забезпечення; JRA2 – забезпечення якості; JRA3 – розробка та впровадження сервісів та стандартів забезпечення безпеки грід-систем; JRA4 – розробка мережевих сервісів; NA1 – управління проектом; NA2 – поширення інформації про грід-технології та залучення нових користувачів; NA3 – навчання користувачів; NA4 – вибір та інтеграція грід-додатків; NA5 – міжнародне співробітництво; SA1 – підтримка, експлуатація та управління європейськими грідсистемами; SA2 – забезпечення мережевих ресурсів. Для відпрацьовування початкового рівня впровадження грідінфраструктури, офіційної оцінки її експлуатаційних якостей і функціональності була обрана обробка експериментальних даних, що отримуються в результаті експериментів на прискорювачі LHC, які ведуться в Європейському центрі Швейцарія, www.cern.ch), де ядерних досліджень грід-інфраструктура (CERN, забезпечує збереження й аналіз петабайтів реальних і змодельованих даних з фізики високих енергій. Однак в подальшому грід-інфраструктура 32 почала використовуватися для різних галузей науки: археологія, астрономія, астрофізика, захист довкілля, комп‘ютерна хімія, наука про Землю, фінанси, фізика плазми, геофізика, науки про життя, мультимедіа, матеріалознавства тощо. Ця інфраструктура відкрита також для індустріальних і соціально економічних співтовариств. У проекті EGEE брали участь більш 90 організацій з більш ніж 45 країн. Організації учасники проекту були об'єднані в регіональні грідфедерації. Сумарна обчислювальна потужність цієї самої великої міжнародної грід-інфраструктури на час завершення проекту складала понад 41,000 процесорів і 5 Пб (PetaBytes) дискової пам‘яті, функціонувало більш 240 обчислювальних кластерів. Мережа обслуговувала більше ніж 10,000 споживачів і 150 віртуальних організацій з продуктивністю більше 100,000 обчислювальних завдань за день. Робота EGEE для масового користувача заснована на проміжному програмному забезпеченні і сервісах gLite [10,14]. Для контролю за функціонуванням цієї інфраструктури розроблені й успішно функціонують різні засоби моніторингу (проходження функціональних тестів, монітори завдань, стану сайтів і інформаційної системи) [13]. Як транспортне середовище для передачі даних і програм інфраструктури EGEE використовувалась дослідницька мережа GEANT і підключені до неї регіональні мережі. Логічним подовження проекту EGEE став проект EGI (European Grid Infrastructure), який націлено на розвиток національних грідпроектів європейських країн. EGI відмовляється від ієрархічної побудови грід-інфраструктури, яка була реалізована в проекті EGEE, та від централізованих грід-сервісів управління грід-системою. Всі ці кореневі грід-сервіси, які забезпечують 33 функціонування грід- інфраструктури, повинні бути розгорнути в країнах учасниках проекту EGI. Така реорганізація дозволить національним грід-інфраструктурам (NGI) забезпечити повний контроль та максимально надійну функціональність національних грід-систем. Для участі в міжнародних проектах національні грід-ініціативи мають об‘єднатися в рамках віртуальних організацій, надаючи свої обчислювальні ресурсі та ресурси зберігання даних у спільне користування. Проект EGI почав працювати на весні 2010 року. Перехідний період від теперішнього стану європейських грід до EGI продовжиться перші три роки. В основу цієї ініціативи закладена співпраця між національними грід інфраструктурами (National Grid Initiatives, NGIs) і координуючою організацією (the EGI Organisation) (рис.1.2). Рис.1.2 - Взаємодія національних NGI і EGI Ця співпраця повинна забезпечити подальший розвиток стійкої і постійно діючої глобальною грід-інфраструктури, яка забезпечує оптимальне використання обчислювальних зберігання даних. 34 ресурсів і ресурсів 1.3 Грід в Україні В Україні впровадження грід-технологій у наукових дослідженнях перебуває на початку свого життєвого циклу - фактично на стадії науково-дослідних розробок. Перший в Україні Грід-вузол був створений у 2002 році у Харківському фізико-технічному інституті НАН України в рамках спільних проектів з Об‘єднаним інститутом ядерних досліджень (м. Дубна, Росія) та Європейським центром ядерних досліджень (CERN) (м. Женева, Швейцарія). У 2005 році з ініціативи Інституту теоретичної фізики ім. М.М.Боголюбова НАН України (ІТФ) і Інформаційно-обчислювального Центру Київського Національного Університету Тараса Шевченка (КНУ) у рамках системи AliEn-ГРІД для обробки даних експерименту ALICE (ЦЕРН) були створені ще два вузли. Найпотужніший на сьогодні в Україні грід-вузіл був побудований в НТУУ «Київський політехнічний інститут» у 2008 році. Основа грід-інфраструктури України була побудована при виконанні двох програм: «Впровадження грід-технологій і створення кластерів у Національній академії наук України» та «Розвиток інформаційних і телекомунікаційних технологій в освіті та науці», основним виконавцем якої були Національна академія наук України та Міністерство освіти та науки України (рис.1.3). За концептуальну основу побудови обчислювальних кластерів у України була прийнята концепція Beowulf, тому всі обчислювальні кластери побудовані на базі платформ x86 та x86_64, мають двох - і (чотирьох -) процесорні сервери з 1-4 Гбайт оперативної пам'яті і жорсткі диски об‘ємом 36-80 Гбайт. Для забезпечення між серверного обміну даними використана технологія Gigabit Ethernet з пропускною здатністю 1 Гбіт/с або використовується технологія InfiniBand з 35 пропускною здатністю 2,5 Гбіт/с. Дисковий простір на жорстких дисках обчислювальних вузлів використовується для розміщення операційної системи (завантаження виконується з локальних дисків), пакетів прикладних програм і тимчасових файлів, і він є не доступним користувачам для зберігання своїх файлів. Для зберігання програм і даних користувачів. а також даних загального користування кожен кластер має дисковий масив (Network Attached Storage, NAS). Рис.1.3 - Грід-інфраструктура України На всіх кластерах встановлена вільно розповсюджувана операційна система Linux, а для організації запуску завдань і розподілу навантаження на кластерах використається система керування завданнями OpenPBS (рис.1.4). Для побудови грід–інфраструктури України було використано програмне забезпечення проміжного рівня (middleware) ARC (Advanced 36 Resource Connector), що також відоме під назвою проекту NorduGrid [5-9]. Рис.1.4 - Моніторинг грід - інфраструктури НАН України Грід-інфраструктура України представляє собою потужний обчислювальний територіально розподілений комплекс, який на даний час забезпечує розв‘язування складних наукових завдань у різних прикладних областях. По своїй суті це дуже різноманітні завдання. Наведемо декілька прикладів таких завдань:  обробка і аналіз експериментальних даних про андрон – андронні та ядерно–ядерні зіткнення на прискорювачі LHC (ALICE, ATLAS і TOTEM експерименти) і RHIC; порівняння теоретичних моделей виникнення кварк–глюонної плазми з майбутніми експериментальними даними;  моделювання білків і розрахунки молекулярної динаміки ряду білків, які можуть бути мішенями для розробки нових лікарських 37 препаратів, у тому числі ВІЛ-протеази і її мутантів, резистентних до інгібіторів;  аналіз біологічних послідовностей, моделювання просторової структури та поведінки біологічних макромолекул, моделювання процесів специфічної взаємодії макромолекул між собою та з низькомолекулярними речовинами;  дослідження спектрів зірок і субзіркових об'єктів, які перебувають на різних еволюційних стадіях; дослідження фізики активних процесів на поверхні кометних ядер; моделювання процесів формування та еволюції великомасштабних структур всесвіту, таких як галактики і ядра галактик (чорні дірки), скупчення галактик, процесів утворення і еволюції зірок;  розроблення та впровадження міждисциплінарного програмного комплексу моделювання складних об‘єктів і процесів різної фізичної природи з паралельною організацією обчислень і з формуванням математичної моделі об‘єкту автоматичним досліджень, який задовольняє потреби широкого кола науковців в засобах математичного моделювання і обчислювальної підтримки наукових досліджень. Постановою Кабінету Міністрів України від 23-го жовтня 2009 року була затверджена Державна цільова науково-технічна програма впровадження і застосування грід-технологій на 2010—2013 роки. Метою Програми є створення національного грід та широке впровадження грід-технологій у наукову та соціально-економічну сферу. Основними завданнями Програми є:  створення національної грід-інфраструктури з впровадженням комплексної системи захисту інформації відповідно до законодавства; 38  залучення українських науковців до участі у міжнародних сучасних унікальних експериментах і комп‘ютерної обробці даних, участі у наукових форумах;  впровадження і застосування грід-технологій в економічній, фінансовій та соціальній сфері, промисловості, медицині та під час проведення наукових досліджень і спостережень у режимі реального часу;  підготовка фахівців для роботи з грід-технологіями. Основними виконавцями програми є Національна академія наук України, Міністерство освіти та науки України та Міністерство охорони здоров‘я України. Інститут теоретичної фізики ім. М.М.Боголюбова НАН України є головною організацією по виконанню програми, а директора інституту Академіка А.Г.Загороднього призначено керівником всієї Програми. Основні напрямки робіт за програмою: 1. Створення і розвиток матеріально-технічної бази національної грід-інфраструктури, інтеграція її у міжнародний грідпростір. Даний напрямок включає наступні завдання:  проектування, побудова та підтримка роботи базового координаційного грід-центра національного рівня;  проектування і побудова регіональних координаційних грід-центрів;  проектування і побудова ресурсних центрів національного рівня (ресурсні центри національної грід-інфраструктури створюються на базі обчислювальних центрів інституту кібернетики НАН України та НТУУ «КПІ»);  побудова нових та посилення існуючих кластерів і грід-платформ доступу в провідних академічних інститутах; 39  технічне забезпечення необхідної пропускної здатності каналів зв‘язку національної грід-мережі, зокрема, для забезпечення функціонування грід-кластерів у наукових центрах НАН і МОН;  технічне забезпечення відповідності параметрів інфраструктури існуючих вітчизняних науково-освітніх мереж вимогам функціонування у науково-освітній європейській мережі GEANT-3. 2. Розробка і впровадження технологій функціонування грід- інфраструктури. Даний напрямок включає наступні завдання:  створення систем тестування, моніторингу та обліку використання грід-ресурсів;  впровадження єдиного проміжного програмного забезпечення (middleware) gLite в національній грід-інфраструктурі;  дослідження і розробка методів і засобів об‘єднання грід–технологій і технологій веб-послуг, механізмів формування грід-послуги як розширення веб-послуги;  відкриття регіональних філій Центру Сертифікації і надання міжнародних сертифікатів наявним національним грід- ресурсам і користувачам. 3. Створення комплексної системи захисту інформаційних ресурсів у національній грід-інфраструктурі. Даний напрямок включає наступні завдання:  розробка і впровадження загальних засобів і методів інформаційної безпеки комп‘ютерної інфраструктури;  розробка і впровадження апаратних і програмних засобів безпеки грід-інфраструктури, які включають: аутентифікацію та розмежування доступу користувачів, захист передачі даних та захист інформаційних ресурсів. 40 4. Розробка та впровадження грід-технологій в науково- технічну та соціально-економічну сфери діяльності. Даний напрямок включає наступні завдання:  використання грід-технологій в фундаментальних наукових та науково-прикладних дослідженнях, розробка та використання програмних пакетів і комп‘ютерних сервісів у наукових і науковопрактичних дослідженнях на основі грід-технологій;  застосування грід-технологій для розв‘язання інженерних, промислових і соціально-економічних задач. 5. Розвиток засобів формування даних, їх збереження та інтелектуальної обробки, використання їх для створення різноманітних баз даних, що є елементами грід-інфраструктури. Даний напрямок включає наступні завдання:  розробка і створення грід-сховищ даних на основі кеш-серверних технологій для накопичення інформації і обробки даних в регіональних координаційних та ресурсних центрах:  розробка та інтегрування українського СЦД ―Геоінформатика і сталий розвиток ― у мережу Світових Центрів Даних, у вітчизняну та міжнародну грід-інфраструктури;  розроблення і впровадження методів ефективного використання існуючих грід- ресурсів за допомогою інтелектуальної обробки даних (DataMining). Створення пілотного комплексу систем автоматизованого прийняття рішень . 6. Організаційне та методичне забезпечення підготовки фахівців для роботи в грід-середовищі і застосування грід- технологій в науці, освіті та інших галузях. Даний напрямок включає наступні завдання: 41  забезпечення підготовки фахівців у сфері застосувань грідтехнологій в науці;  створення навчальних грід-систем при базовому і регіональних координаційно-операційних грід-центрах. Звичай, життя вносить свої корективи і в 2010 році через кризу на фінансування заходів з Програми було виділені тільки 6,784 млн. грн. замість запланованих 120 млн. грн. Це дозволили виконати 29 проектів. У 2011 році об‘єм фінансування Програми склав 7,8 млн. грн., що дозволили почати виконання 43 проектів по завдання Програми. Виділені кошти не дозволяють виконати завдання Програми в повному обсязі, але напрямок розвитку грід - технологій входить у п'ятірку пріоритетних наукових напрямів України, які будуть фінансуватися нехай і в зменшеному об'ємі. 1.4 Навчальна грід-інфраструктура Інтенсивний розвиток грід-технологій робить актуальним завдання підготовки фахівців у даній області інформаційних технологій. Обов'язковим і невід'ємним етапом у її вирішенні є створення спеціалізованої грід-інфраструктури для проведення навчання як звичайних користувачів, так і адміністраторів та розробників грідсервісів. Поки що завдання підготовки кваліфікованого персоналу в області грід кожний із проектів, який використовує грід-технології, вирішує самостійно. Наприклад, у проекті EGEE існував окремий напрямок по проведенню практичних інфраструктури, створеної занять в для рамках підготовки користувачів EGEE/WLCG, — NA3 (http://public.eu-egee.org/activities/na3_details.html), які були реалізовані на базі полігона GILDA (https://gilda.ct.infn.it/). Експлуатація даного 42 комплексу можлива тільки для цільових груп даного проекту. Використовується лише один тип програмного забезпечення проміжного рівня — INFN Grid, повністю сумісного з gLite Відносна (http://glite.web.cern.ch/glite/). короткостроковість дії сертифікатів для користувачів, яких навчають (14 днів), досить щільний розклад тренінгів, тобто досить інтенсивне використання ресурсів інфраструктури, унеможливлює, наприклад, проведення семестрових занять для студентів. На даний час навчання грід-технологіям у Європі одержало свій розвиток у проекті ICEAGE (International Collaboration to Extend and Advance Grid Education) http://www.iceage-eu.org/v2/index.cfm), який фінансується Європейською комісією й головною метою якого є забезпечення механізму швидкого поширення знань від малої групи піонерів у цій області до широкої європейської аудиторії. У рамках національних і міжнаціональних проектів (наприклад, OSG, EELA-2), навчання представлене школами з грідтехнологій (як правило, це одне-двох тижневий захід, що містить лекції й практичні заняття з роботи на тієї або іншій грід-інфраструктурі), семінарами й онлайн курсами для самостійного освоєння матеріалу. Для забезпечення Об'єднаному навчання грід-користувачів в 2004 році в інституті ядерних досліджень (ЛІТ ОИЯИ Росія, http://lit.jinr.ru/), за участю співробітників Лабораторії інформаційних технологій того ж інституту, була створена автономна грід- інфраструктура на виділених серверах для забезпечення навчання користувачів. В 2009 році до даної навчальної грід-інфраструктури підключилися Національний технічний університет України «Київський політехнічний інститут» та Інститут М.М.Боголюбова НАН України. 43 теоретичної фізики ім.. На даний час об‘єднана міжнародна навчальна грід- інфраструктура, на основі проміжного програмного забезпечення gLite, складається з навчальних грід-сайтів Міжнародної міжурядової організації «Об‘єднаний інститут ядерних досліджень» (Російська Федерація, Дубна), Інституту теоретичної фізики імені М.М.Боголюбова НАНУ (Україна, Київ), Державного наукового центру Російської Федерації «Інститут фізики високих енергій» (Російська Федерація, Протвіно), Софійського університету імені Клемента Охрідського (Болгарія, Софія), Національного технічного університету України «Київський західного політехнічний університету інститут» імені (Україна, Неофіта Київ), Південно- Рильського (Болгарія, Благоєвград), Інституту математики та інформаційних технологій Академії наук Узбекистану (Узбекистан, Ташкент). Структура навчальної грід-інфраструктури станом на травень 2010 року наведена на рис.5. Рис. 1.5 - Навчальна інфраструктура edu У навчальній грід-інфраструктурі встановлені наступні сервіси (рис.1.6): 44  grid-сайт (RU-JINR): інтерфейс користувача (User Interface, UI), обчислювальний елемент (Computing Element, CE) типу LCG-CE із двома обчислювальними вузлами (Worker Nodes, WNs), елемент зберігання даних (Storage Element, SE) типу Disk Pool Manager (DPM), файловий каталог (LCG File Catalog, LFC), система управління розподілом завдань (Workload management system, WMS), сервіс збору й зберігання інформації про задачі і їх статус (Logging and bookkeeping, LB), інформаційний сервіс з ресурсів grid-сайту - site BDII (sBDII), інформаційний сервіс про grid-сайти - top BDII (tBDII);  grid-сайт (RU-JINR-2): LCG-CE із двома обчислювальними вузлами й сервісами DPM SE і sBDII;  grid-сайт (RU-JINR-MPI): обчислювальний елемент LCG-CE із трьома обчислювальними вузлами й підтримкою Message Passing Interface (MPI) для навчання роботи з паралельними задачами, сервіси DPM SE і sBDII;  grid-сайт (SU-Protvino-IHEP): інтерфейс користувача, LCG-CE із двома обчислювальними вузлами, SE типу dCache, система керування задачами, сервіси LB і sBDII;  grid-сайт обчислювальними (UZ-IMIT): вузлами WMS, (у LCG-CE найближчому c чотирма майбутньому адміністраторами цього сайту планується довести число робочих вузлів до 16), що підтримують рахунок паралельних задач, WMS, сервіси LB, sBDII, tBDII;  grid-сайт (BG-SU): інтерфейс користувача, LCG-CE із чотирма обчислювальними вузлами, DPM SE, сервіс sBDII; 45  grid-сайти (UA-BITP): інтерфейс користувача, LCG-CE c восьма обчислювальними вузлами, DPM SE, WMS, сервіси LB, LFC, sBDII, tBDII;  grid-сайт (UA-KPI-HPCC): інтерфейс користувача, LCG-CE c восьма обчислювальними вузлами, DPM SE, WMS, сервіси LB, LFC, sBDII, tBDII. Наявність в інфраструктурі декількох обчислювальних елементів дозволяє продемонструвати студентам можливість автоматичного вибору системою управління завантаженням якогось одного з них, який задовольняє зазначеним у файлі опису задачі критеріям (наприклад, з мінімальним числом задач у черзі, з певним типом системи керування локальними ресурсами, з якимсь конкретним установленим програмним забезпеченням і т.д.). Присутність декількох елементів зберігання даних дає можливість показати таку функціональність грід-середовища, як копіювання даних з одного SE на іншій, реплікацію (створення копій того самого набору даних на різних SE), вибір оптимального CE стосовно зазначеного SE та інше. Рис.1.6 - Склад обчислювальних ресурсів віртуальних організацій 46 Рис.1.7 -. Навчальні грід-сайти в грід-інфраструктурі України Для забезпечення навчального процесу в "Інституті прикладного системного аналізу" (ІПСА) Національного технічного університету України «Київський політехнічний інститут» були проведені роботи по розширенню навчальної грід-інфраструктури. Додатково в обчислювальному центрі КПІ був розгорнуто Сервіс управління віртуальними організаціями - Virtual Organizations Management service (VOMS), який підтримує віртуальну організацію kpiedu (забезпечення навчального процесу в КПІ) та bitpedu (забезпечення навчання співробітників НАН України) і локальний сертифікаційний центр (СА) для видачі грід-сертифікатів користувачам-студентам, щоб створену інфраструктуру зробити повністю автономною. Додатково для забезпечення навчання по використанню грідінфраструктури під управлінням проміжним програмним забезпеченням ARC було встановлено два грід-сайту BITP training cluster (Інституті 47 теоретичної фізики імені М.М. Боголюбова НАНУ) KPI training cluster (Національного технічного університету України «Київський політехнічний інститут»), які включено в загальну грід-інфраструктуру України (рис.1.7). 1.5 Порядок виконання завдання: 1. Вивчити матеріали вітчизняних сайтів з грід-технологій: www.grid.kpi.ua/, www.initiativa.com/ www.grid.nas.gov.ua/ 2. Переглянути в Інтернет матеріали одного з існуючих національних грід-сайтів (табл. 1.2) Таблиця 1.2. • Austria – AustrianGrid • Latvia - LatGrid • Belgium – BEGrid • Lithuania - LitGrid • Bulgaria – BgGrid • Netherlands – DutchGrid • Croatia – CRO-GRID • Norway – NorGird • Cyprus – CyGrid • Poland - Pioneer • Estonia - EEGrid • Serbia – AEGIS • France – ICAR • Slovenia - SiGNET • Germany – D-GRID • Spain – IBERgrid • Greece - HellasGrid • Sweden – SweGrid • Ireland - Grid-Ireland • Turkey – TR-Grid • Israel – Israel Academic • United Grid Kingdom – eScience 3. Порівняти можливості і параметри української і обраної національної грід-інфраструктур. 4. Зробити висновки по роботі. 48 1.6 Контрольні запитання 1.Що таке грід? 2. Яке призначення проміжного програмного грід забезпечення (middleware)? 3. Які базові грід-сервіси Ви знаєте? 4. Нащо вводиться сертифікат користувача? 5. Як відбувається взаємодія користувача с грід-системою? 6. Що таке GEANT? 7. Які європейські грід-інфраструктури і грід-проекти Ви знаєте? 8. Які параметри національної грід-інфраструктури в Україні Ви знаєте? 9. Чи достатня інформація про грід-розробки в Україні з існуючих сайтів? 10. Чим навчальна грід-система відрізняється від професійної? Література 1. Петренко А.И., Вступ до Grid технологій в науці та освіті: навчальний посібник. - К.: НТУУ «КПІ», 2008,- 120с. (http://moodle.ntu-kpi.kiev.ua) 2. Петренко А.И., Застосування Grid технологій в науці та освіті: роздатковий матеріал до вивч. курсу для студ. спец. «Інформаційні технології проектування» - К.: НТУУ «КПІ», 2009,- 144 . (http://moodle.ntu-kpi.kiev.ua) 3.Петренко А.І., Булах Б.В.,Хондар В.Д. Семантичні грід- технології для науки і освіти:додатковий матеріал. -// К.: НТУУ «КПІ», 2010.- 178 c. ( http://moodle.ntu-kpi.kiev.ua) 4. Introduction to Grid Computing, December 2005, IBM Redbook www.ibm.com/redbooks. 5. NorduGrid project - http://www.nordugrid.org. 6. The NorduGrid Grid Manager And GridFTP Server: Description And Administrator‘s Manual. -http://www.nordugrid.org/papers.html 49 7. xRSL (Extended Resource Specification Language), O.Smirnovahttp://www.nordugrid.org/papers.html 8. ARC User Interface: User‘s Manual http://www.nordugrid.org/documents/NorduGrid-UI.pdf 9. The NorduGrid/ARC Information System, (Technical Description and Reference Manual), Balázs Kónya - http://www.nordugrid.org/papers.html 10. Glite 3.1 User Guide - https://edms.cern.ch/file/722398/1.2/gLite-3UserGuide.pdf 11. EGEE User‘s Guide, WMS Service - https://edms.cern.ch/document/572489/1 12. Grid Computing Making the Global Infrastructure a Reality, edited by Fran Berman, Geoffrey Fox, Tony Hey. – (Wiley series in communications networking & distributed systems), 2003 .- 1007 с. 13. Monitoring and Discovery Services.- http://www.globus.org/mds/mds2/ 14. EGEE Middleware Architecture, DJRA1.1. https://edms.cern.ch/document/476451/1.0. 50 Завдання № 2. Робота на обчислювальному кластері з використанням локальної системи управління PBS Мета: вивчення технології віддаленого доступу до ресурсів багатопроцесорної обчислювальної системи та набуття практичних знань і навичок компіляції та запуску простих програм з використанням системи управління кластера. 2.1 Короткі теоретичні відомості 2.1.1 Багатопроцесорної обчислювальної системи Останні роки у всьому світі відбувається бурхливе впровадження обчислювальних кластерів. Це викликано тим, що кластери стали загальнодоступними і дешевими апаратними платформами для високопродуктивних обчислень. Крім того, існує досить велика кількість науково-практичних завдань, вирішення яких вимагає використання великої кількості ресурсів обчислювальних систем. Такі завдання можуть бути вимогливі до ресурсу процесорного часу, але так само можуть бути надзвичайно вимогливі до ресурсу оперативної пам'яті. Практика показує, що використання однопроцесорної системи навіть дуже високій продуктивності не дозволяє ефективно вирішувати такі задачі за прийнятний час. У разі, коли завдання оперує з величезною кількістю даних, як, наприклад, при обробці експериментальних даних, отриманих з прискорювача елементарних часток, буває дуже важко використати одну якусь багатопроцесорну систему. Але перш ніж ми перейдемо до розгляду обчислювальних ресурсів, які використовуються в грід, розглянемо класифікацію обчислювальних систем. Детальніше різні класифікації обчислювальних 51 систем можна подивитися в [1]. Ми ж розглянемо найбільш використовувану класифікацію багатопроцесорних систем за принципом їх організації, а точніше - за способом доступу к пам'яті. Можна виділити три класи:  симетричні багатопроцесорні системи (Symmetric Multiprocessing, SMP), в яких доступ до пам'яті рівноправний для кожного процесора;  системи з неоднорідним доступом до пам'яті (Non - Uniform Memory Access, NUMA), в якій пам'ять розподілена, але логічно залишається загальною;  системи з розподіленою пам'яттю (Massively parallel processing, MPP), в яких кожен процесор має безпосередній доступ тільки до локальної пам'яті свого вузла. Дуже коротко розглянемо кожну з цих обчислювальних систем. Симетричні мультипроцесорні системи (SMP) SMP - системи складаються з деякої кількості однорідних процесорів і масиву пам'яті, який розділяється між процесорами. Найпростіше рішення є таким. коли процесори звертаються до пам'яті через загальну системну шину (рис.2.1). Наявність загальної пам'яті значно спрощує організацію взаємодії процесорів між собою і спрощує програмування, оскільки паралельна програма працює в єдиному адресному просторі. 52 Рис.2.1 - Схема архітектури класу SMP Проте існує ряд проблем, властивих системам цього типу. Усі вони, так або інакше, пов'язані з оперативною пам'яттю. Окрім конфліктів при зверненні до загальної шини пам'яті виникла проблема, пов'язана з наявністю кеш-пам'яті. У багатопроцесорних системах, побудованих на базі мікропроцесорів зі вбудованою кеш-пам'яттю, порушується принцип рівноправного доступу до будь-якої точки пам'яті. Дані, що знаходяться в кеш-пам'яті деякого процесора, недоступні для інших процесорів. Це означає, що після кожної модифікації копії деякої змінної, що знаходиться в кеш-пам'яті якогонебудь процесора, необхідно робити синхронну модифікацію самої цієї змінної, розташованої в основній пам'яті, що породжує великі накладні витрати і, як наслідок, падіння продуктивності. Системи з неоднорідним доступом до пам'яті (NUMA) Для вирішення багатопроцесорних проблем, системах, що було виникають вирішено в симетричних пожертвувати однорідністю і організувати неоднорідний доступ до пам'яті (Non Unifom Memory Access, NUMA) при збереженні єдиного для усіх процесорів адресного простору Система складається з однорідних базових модулів (плат), які містять невелику кількість процесорів. C кожним модулем зазвичай 53 пов'язаний один або декілька блоків пам'яті. Модулі об'єднані за допомогою високошвидкісного комутатора. Підтримується єдиний адресний простір для усіх модулів. Апаратно підтримується доступ до видаленої пам'яті, т. е. до блоків пам'яті,приписаним іншим модулям. Швидкість доступу з модуля до блоків пам'яті, приписаним цьому модулю, у декілька разів вище, ніж до інших блоків пам'яті. У разі, якщо апаратно підтримується когерентність кешів в усієї системі (звичайно це так), говорять про архітектуру cc - NUMA (cache - coherent NUMA). Масивно-паралельні системи (MPP) Наступним кроком стало рішення відмовитися від єдиного адресного простору для усіх процесорів багатопроцесорної системи. У MPP системах кожному процесору приписана його власна оперативна пам'ять. Інші процесори не мають можливості звернутися до не своєї пам'яті, проте процесори пов'язані комунікаційним середовищем. Кожен процесор має можливість передати іншому процесору повідомлення через комунікаційне середовище (рис.2.2). Рис.2.2 - Структура системи класу MPP Зазвичай комунікаційне середовище влаштоване таким чином, що повідомлення для інших процесорів доставляються транзитним чином 54 через треті процесори. Про такі системи говорять як про системи з розподіленою пам'яттю. Трійку процесор, пам'ять, обладнання для комунікацій зазвичай виносять на окрему плату і надалі називають вузлом MPP системи. При цьому на кожному вузлі може функціонувати або повноцінна операційна система, або скорочений іі варіант, який підтримує тільки базові функції ядра, а повноцінна операційна система працює на спеціальному керуючому комп'ютері. Зараз на вузол MPP системи досить часто встановлюють декілька процесорів або багатоядерні процесори. В результаті вузол MPP системою може бути SMP системою. У вузлах апаратні засоби для організації комунікацій влаштовані так, що звільняють центральний процесор від участі в трансляції даних. Окрім традиційних суперкомп'ютерів типу Cray T3E і IBM SP, клас комп'ютерів з розподіленою пам'яттю останнім часом активно розширюється за рахунок обчислювальних кластерів. Одним з перших проектів, що започаткував ім'я «Beowulf - кластери» цілому класу паралельних систем, виконаний в науковому центрі NASA Goddard Space Flight Center. Проект Beowulf стартував влітку 1994 року, і незабаром було зібрано 16-процесорний кластер на процесорах Intel 486DX4/100 Мгц. На кожному вузлі було встановлено по 16 Мбайт оперативної пам'яті і по 3 мережевих карти для звичайної мережі Ethernet. Для роботи в такій конфігурації були розроблені спеціальні драйвери, яки розподіляють трафік між доступними мережевими картами. Результати експлуатації такого кластера виявилися успішними, тому зараз більше 80% суперкомп'ютерних систем у списку Top500 відносяться до кластерних систем. 55 Обчислювальний кластер - це мультикомп‘ютер, який складається з певного числа окремих комп'ютерів (вузлів), зв'язаних між собою єдиною комунікаційною системою. Кожний вузол має свою локальну оперативну пам'ять. При цьому загальної фізичної оперативної пам'яті для вузлів не існує. З погляду наведеної раніше класифікації обчислювальні кластери відрізняються від MPP систем насамперед тим, що вузли кластера – це повноцінні комп'ютери. Якщо в якості вузлів кластера використовуються мультипроцесори (мультипроцесорні комп‘ютери з загальною пам'яттю), то такий кластер називається SMP-кластером. Комунікаційна система зазвичай дозволяє вузлам взаємодіяти між собою тільки за допомогою передачі повідомлень, але деякі системи можуть забезпечувати і однобічні комунікації, тобто дозволяти будьякому вузлу виконувати масовий обмін інформацією між своєю пам'яттю й локальною пам'яттю будь-якого іншого вузла. Якщо всі вузли, які входять до складу обчислювального кластера, мають однакову архітектуру і продуктивність, то ми маємо справу з однорідним обчислювальним кластером. Інакше - з неоднорідним. Зрозуміло, що різних варіантів побудови кластерів багато. Одна з істотних відмінностей пов‘язана з використанням різних мережевих технологій. Вибір мережевого з‘єднання обчислювальних вузлів визначається, насамперед, класом завдань, які планується розв‘язувати на кластері. Спочатку Beowulf-кластери будувалися на базі звичайної 10мегабитной мережі Ethernet. Сьогодні використовується мережа Gigabit Ethernet, як правило, на базі комутаторів. Основна перевага такого рішення – низька вартість обладнання. Разом з тим, більші накладні витрати на передачу повідомлень у рамках Gigabit Ethernet приводять до 56 серйозних обмежень на спектр завдань, які ефективно вирішуються на таких кластерах. Виходячи з міркувань вартості, продуктивності й масштабованості, проектувальники кластерних систем роблять вибір між Gigabit Ethernet, комунікаційними SCI, Myrinet, технологіями (опис Infiniband основних та іншими параметрів комунікаційних технологій можна знайти, наприклад, на сайті http://www.parallel.ru). Типовий обчислювальний кластер, побудований з використанням Gigabit Ethernet комутатора, представлений на рис.2.3. Рис.2.3 - Структурна схема типового обчислювального кластера В таблиці 2.1 наведено перелік функцій для кожного об‘єкту обчислювального кластера. 57 Таблиця 2.1. Об’єкт № кластеру Робочий 1 вузол Призначення Вузли кластеру зв‘язані між собою за допомогою Gigabit Ethernet. Встановлена однакова для всіх обчислювальних вузлів операційна система, що завантажується власного жорсткого диску. Жорсткий з диск призначений для завантаження ОС і зберігання тимчасових файлів. Обчислювальне навантаження між вузлами розподіляється автоматично за допомогою програми диспетчера кластеру. Термінал 2 Використовується для налагодження операційної керування системи на вузлах кластера. Перемикання між системними блоками здійснюється за допомогою селектора KVM switch. Вхідний 3 вузол Сервер, на якому зберігається інформація про кластеру облікові записи користувачів, і через який здійснюється доступ до обчислювальних ресурсів кластера. Зовнішній 4 Дисковий масив, призначений для зберігання даних дисковий масив загального користування. KVM 5 switch Використовується керування для (монітор, підключення клавіатура, системних блоків обчислювальних забезпечує перемикання між ними. 58 терміналу миша) до вузлів та Комутатор 6 Використовується для передачі даних між вузлами кластеру кластера, вхідним сервером і дисковим масивом, при цьому передача здійснюється через мережу Gigabit Ethernet. Комутатор 7 Використовується для передачі даних між локальної кластером та комп‘ютерами користувачів локальної мережі мережі. Маршрутизатор 8 Забезпечує доступ до мережі Інтернет. Найпоширенішим є використання однорідних кластерів, тобто таких, де всі обчислювальні вузли абсолютно однакові за своєю архітектурою і продуктивністю. Один сервер виконує функції керуючого вузла (frontend) кластера. На цьому комп'ютері встановлене програмне забезпечення, яке активізує обчислювальні вузли при завантаженні операційної системи і управляє запуском програм на кластері. Обчислювальні завдання користувачів виконуються на обчислювальних вузлах, при чому вони розподіляються таким чином, що на кожний процесор розподіляється не більше одного обчислювального процесу. Користувачі мають термінальний доступ до головної машини кластеру (цей сервер забезпечує зв'язок кластера із зовнішньою мережею через корпоративну локальну обчислювальну мережу або через Інтернет). Найчастіше для забезпечення термінального доступу використовується протокол SSH. На цьому ж сервері розміщені конфігураціях домашні каталоги користувачів. У деяких для доступу користувачів і розміщення домашніх каталогів виділяється окремий сервер, так званий сервер доступу. Доступ на обчислювальні вузли 59 кластера або закритий для користувачів, або можливий, наприклад, для ручного управління компіляцією завдання. Виконання програм на кластері здійснюється в так званому "пакетному" режимі – користувач не має безпосередньої, "інтерактивної" взаємодії із програмою, програма не може очікувати ведення даних із клавіатури й виводити їх безпосередньо на екран. Більше того, програма користувача може працювати тоді, коли користувач не підключений до кластера. В якості системи пакетної обробки завдань використовується найбільш поширена Portable Batch System (www.openpbs.org), доступна зараз як мінімум у двох варіантах: вільно розповсюджуваний Open PBS і комерційний варіант Professional PBS. Обчислювальний кластер, як правило, працює під управлінням однієї з версій ОС Linux - багато користувальницької операційної системи. Всі вузли кластера мають доступ до загальної файлової системи, яка розміщується на файл-сервері. Іншими словами, файл може бути створений, наприклад, на головній машині або на обчислювальному вузлі, а потім прочитаний під тим же ім'ям на іншому вузлі. Запис в один файл одночасно з різних вузлів неможлива, але запис у різні файли припустима. Крім загальної файлової системи можуть використовуватися локальні диски на обчислювальних вузлах кластера. Їх звичай використовують програми для зберігання тимчасових файлів. Після закінчення (точніше, безпосередньо перед завершенням) роботи програми ці файли віддаляються. Існує декілька способів задіяти обчислювальні потужності кластера [2]. 1. Виконувати певну кількість однопроцесорних задач. Це може бути розумним варіантом, якщо 60 потрібно провести множину незалежних обчислювальних експериментів з різними вхідними даними, при цьому час виконання розрахунків не має значення, а всі дані розміщаються в оперативної пам'яті, доступної одному процесу. 2. Використовувати готові пакети програм, в яких реалізовані паралельні обчислення. Для деяких задач доступні безкоштовні або комерційні паралельні програми, які при необхідності можна використовувати на кластері. Як правило, для цього досить, щоб програма була доступна у вихідних кодах (open source code), реалізована з використанням інтерфейсу MPI на мовах С/C++ або Фортран. Приклади вільно розповсюджуваних паралельних програм, реалізованих за допомогою MPI: GAMESS-US (квантова хімія), POVRay-MPI (трасування променів). 3. Здійснювати в власних програмах виклик додатків з стандартних бібліотек для паралельних обчислень. Для деяких галузей, наприклад, лінійна алгебра, доступні бібліотеки, які дозволяють вирішувати широке коло стандартних завдань із використанням можливостей паралельної обробки. Якщо використання таких стандартних завдань становить більшу частину обчислювальних операцій програми, то використання такої паралельної бібліотеки дозволить одержати паралельну програму практично без написання власного паралельного коду. Інформацію про інші паралельні бібліотеки й програми, реалізовані за допомогою MPI, можна знайти за адресою http://www-unix.mcs.anl.gov/mpi/libraries.html. 4. Створювати власні однопроцесорні або паралельні програми. Це найбільш трудомісткий, але й найбільш універсальний засіб. 61 2.2 Методика роботи на обчислювальному кластері Доступ до кластеру Для роботи з обчислювальним кластером користувач повинен мати свій обліковий запис на керуючому вузлі кластера. Користувач отримує логін (реєстраційне ім’я), пароль та домашню директорію (якщо ім‘я користувача, наприклад, student, то домашня директорія знаходиться в /home/student). Користувач має доступ до кластера та можливість роботи на ньому з будь-якого комп‘ютера, який знаходиться у локальній мережі інституту чи Інтернет. Віддалений доступ до головної машини кластера здійснюється за допомогою протоколу SSH. Робота в SSH – сесії відбувається в термінальному (текстовому, консольному) режимі. Параметри SSH-з‘єднання уточнюється у викладача. Для роботи з обчислювальним кластером з свого комп‘ютера під керування операційної системи Linux необхідно використовувати консольний ssh-клієнт, який входить в дистрибутив Linux. підключення до обчислювального кластеру необхідно Для виконати консольну команду: ssh им’я_користувача@машина –p порт Наприклад: ssh student@cn.hpcc.ntu-kpi.kiev.ua –p 2222 У випадку успішного підключення до сервера, буде запропоновано ввести ім‘я (логін), а потім – пароль. login as: student student@cn.hpcc.ntu-kpi.kiev.ua's password: 62 При введенні паролю символи на екрані не відображаються. Якщо все введено правильно, то користувач отримує доступ до своєї домашній директорії і на екрані відобразиться консоль командного інтерпретатора в наступному форматі: им‘я_користувача@машина поточний_каталог Наприклад: [student@n02 ~]$ Примітка. Необхідно пам’ятати, що консоль Linux, на відміну від Windows, розрізняє регістр написання символів, що вводяться, тобто mydoc.txt та mydoc.TXT – це не одне й те саме. Список основних команд Linux - див. у Додатку 3. Для роботи з обчислювальним кластером з Windows комп‘ютера по безпечному протоколу SSH рекомендується використовувати в якості SSH - клієнта програму PuTTY, яка вільно розповсюджується і проста у використанні. Інсталяційну версію програми PuTTY можна отримати за адресою: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Для з‘єднання з обчислювальним кластером в початковому вікні (рис.2.4) потрібно обрати в check-box «Connection type» протокол SSH, в полі «Host Name» ввести ім‘я сервера доступу кластера (або IP адресу) та в полі «Port» ввести номер порту, по якому виконується з‘єднання. Примітка. Для коректного відображення unicode-кодування в сеансі SSH необхідно в налаштуваннях putty в розділі Window>Translation вказати кодування замовчанням кодування KOI8-R. 63 UTF-8, замість прийнятої за Рис.2.4 - Інтерфейс програми PuTTY Натискання кнопки «Open» призведе до відправки запиту на підключення до обчислювального кластера. У випадку успішного підключення, буде запропоновано ввести логін, а потім – пароль. Після успішної перевірки, користувач отримує доступ до своєї домашній директорії і на екрані відобразиться консоль командного інтерпретатора, яка показано вище. Примітка. При першому підключенні до кластера можлива поява діалогового повідомлення «PuTTY Security Alert», на яке слід дати ствердну відповідь. Робота на кластері Універсальним засобом роботи на обчислювальному кластері під управлінням операційної системи Linux є робота через консоль. Користувачу для збереження файлів доступний лише його домашній 64 каталог. Для роботи з файлами та каталогами існує кілька корисних команд: Команда Пояснення Показати ls список каталогів та файлів у поточному каталозі pwd Показати ім‘я поточного каталогу cd назва_каталогу Змінити каталог mkdir назва_каталогу Створити каталог rm Видалити файли. З опцією -r рекурсивно видаляє каталоги clear Очистити екран cp що куди Зкопіювати файли або каталогі locate Знайти файл mv Переместити файл cat Вивести на екран вмісту файлу grep Знайти символьний рядок в тексті mcedit Редактор файлів (утиліта mc) Детальні відомості про ці команди, а також - про всі інші можна отримати, набравши в консолі: man назва_команди. Більш розширену інформацію про більшість програм можна отримати, набравши: info назва_команди. Примітка. При роботі в консолі зручно користуватися клавішею авто підстановки Tab. Якщо набравши кілька перших символів назви програми або файлу, користувач натисне на клавішу Tab, то система доповнить їх до повного імені за умови, що є лише єдиний варіант доповнення. Якщо варіантів кілька, то з‘явиться їх список. Введення 65 додаткових символів, які однозначно визначають потрібне ім‘я, та натискання клавіші Tab призведе до вибору імені файлу чи команди. Приклади: 1) Визначення поточного каталогу користувача [student@n02 ~]$ pwd /home/localusers/student 2) Перехід у домашній каталог [student@n02 /]$ cd $HOME або: [student@n02 /]$ cd ~ 3) Створення піддиректорії test/subtest в поточному каталозі [student@n02 ~] $ mkdir –p test/subtest 4) Копіювання файлу test.txt із поточного (символ «точка») каталогу у щойно створений. Перехід у цю директорію. [student@n02 ~]$ cp ./test.txt ./test/subtest/ [student@n02 ~]$ cd test/subtest 5) Виведення вмісту поточного каталогу [student@n02 subtest]$ ls test.txt Копіювання файлів При роботі на обчислювальному кластері користувачу доведеться копіювати файли зі свого комп‘ютера в домашню директорію на кластері (програми, вхідні дані, бібліотеки) та навпаки (лістинг, результати розрахунків). Таку операцію можна виконати двома шляхами: копіювати файли за протоколом SSH або за протоколом FTP (SFTP). 66 Копіювання файлів за протоколом SSH є більш рекомендованим при віддаленому доступі. Цей протокол забезпечує шифрування інформації, яка передається мережею. Для копіювання файлів за протоколом SSH з Windows комп‘ютера рекомендується використовувати утиліту pscp.exe (доступна за тим же посиланням, що і програма PuTTY). Для копіювання файлів за протоколом SSH з Linux рекомендується використовувати консольну команду scp. Формат команди копіювання для цих утиліт практично однаковий: pscp.exe –P порт адреса_джерела адреса_приймача scp –P порт адреса_джерела адреса_приймача де адреса_джерела і адреса_приймача мають вигляд: им‘я_користувача@машина:файл_або_папка Нижче представлено приклад виконання команди з Windows комп‘ютера для копіювання користувачем student деякого файлу test.txt, що розміщений в директорії c:\temp на локальному комп‘ютері, в домашню директорію користувача на обчислювальному кластері. C:\PuTTY>pscp.exe -P 2222 c:\temp\test.txt student@cn.hpcc.ntukpi.kiev.ua: student@cn.hpcc.ntu-kpi.kiev.ua's password: test.txt | 6 kB | 6.4 kB/s | ETA: 00:00:00 | 100% Припустимо, користувач student завантажив pscp.exe у каталог C:\PuTTY. Першим обов‘язковим параметром цієї команди є файл, що копіюється, – джерело. В даному прикладі це c:\temp\test.txt. А student@cn.hpcc.ntu-kpi.kiev.ua – адреса «приймача» файлу. Якщо не вказати теку-приймач, то файл копіюється в домашній каталог 67 користувача. Якщо або тека-джерело, або тека-приймач знаходяться в тій системі, де виконується команда, то можна не вказувати ім‘я користувача та адресу машини. Обидві команди підтримують опцію командного рядка -r, що дозволяють рекурсивне копіювання каталогу. Для перевірки успішності копіювання файлу test.txt, розміром 6 КБ в домашній каталог користувача на кластері (консоль Linux) використовується команда ls: [student@n02 ~]$ ls -la test* -rw-rw-r-- 1 student student 6552 Dec 22 12:20 test.txt Для виконання операції копіювання файлів з Windows комп‘ютера можна використовувати програму WinSCP3. Інтерфейс програми WinSCP3 нагадує інтерфейс програми PuTTY (рис.5). Для з‘єднання з обчислювальним кластером в початковому вікні (рис.2.5) потрібно натиснути кнопку «New» та ввести ім‘я сервера доступу кластера (або IP адресу), номер порту, за яким виконується з‘єднання, логін користувача та пароль. Потім необхідно зберегти введені параметри сесії, вказавши своє ім‘я. Рис. 2.5 - Початковий інтерфейс програми WinSCP3 68 Примітка. Логін користувача та пароль з міркувань безпеки рекомендується не зберігати в сесії, а вводити при кожному з’єднанні з кластером. Якщо на комп‘ютері користувача вже є збережена сесія в PuTTY, то її можна перенести до WinSCP3, вибравши розділ «Session» и натиснувши кнопку «Import». Для встановлення зв‘язку з кластером потрібно обрати сесію з списку збережених сесій та натиснути кнопку «Login». Після успішного з‘єднання з кластером відобразиться (рис.2.6) панель програми WinSCP3, подібна до Norton/Total Commander (в настройках програми можна вибрати інтерфейс, подібний до Windows Explorer). Рис. 2.6 - Інтерфейс програми WinSCP3 В лівої частині – відображається зміст поточного каталогу на комп'ютері користувача, а в правої частині - зміст домашньої директорії на кластері. 69 Для здійснення операції копіювання використовуються функціональна кнопка «F5 – Copy». Примітка. Для завершення роботи з програмою WinSCP3 необхідно вибрати пункт меню «Session» та виконати команду «Disconnect». 2.3 Корисні програми для роботи на кластері: 1) Файловий менеджер mc При роботі на кластері можна використовувати файловий менеджер Midnight Commander (mc), який дуже схожий на FAR чи Norton Commander (рис.2.7). Цей файловий менеджер можна запустити з консолі: mc -ca Необов‘язковий ключ -ca необхідний для коректного відображення спеціальних символів в ssh – сесії. Рис.2.7 - Інтерфейс програми MC 70 2) Текстовий редактор mcedit Користувачу рекомендується основну частину вихідних файлів готувати на своїй локальній машині в звичних текстових редакторах. Для внесення незначних змін у файли добре підходить вбудований у mc редактор. Для запуску цього редактора слід встановити курсор на потрібному файлі та натиснути клавішу F4. Для створення та редагування нового файлу – «Shift + F4». У цьому редакторі присутні усі основні засоби, що є в подібних програмах: копіювання, вставка, пошук, заміна, підсвічення синтаксису та ін. Перелік основних команд редактора наведено в Додатку №1. 3) Текстовий редактор Emacs, VIM Якщо необхідні більш складні засоби редагування, то можна використати редактори vi / vim та emacs. Обидва ці редактори мають більш ніж тридцятирічну історію та стали «культовими» у світі UNIX. Vim є більш простим (за функціональністю), але менш наочним редактором. Основна функція vim - робота з вхідними текстами програм. emacs - це більш ніж редактор. З його допомогою можна здійснювати професійну верстку; набір, запуск та налагодження програм; прийом / відправлення електронної пошти та новин; навігацію по жорсткому диску; використовувати в якості органайзера та багато іншого. Недолік цих редакторів - достатньо складне управління (особливо - vim), яке не можна назвати інтуїтивно зрозумілим для користувачів, які звикли до роботи в ОС Windows. Перелік основних команд редакторів наведено в Додатку №2. 71 4) Інструментальні засоби розробки власних програм На Linux кластері у розпорядженні користувачів є необхідний набір засобів розробки програм. Перерахуємо тільки основні програмні засоби. Інструкції з використання, а також опис опцій компіляторів є в мережі Інтернет.  GNU-C и GNU-C++ компілятори, яки виконують компіляцію, асемблювання і створення коду, який буде виконуватися. Працюють з файлами на мовах C і C++. Виконання програми: gcc [ option | filename ]... g++ [ option | filename ]... Значення деяких важливих опцій: -c створити тільки об‘єктний файл (source.o) -o file створити файл, який буде виконуватися з ім‘ям file, (за замовчуванням створюється файл з ім‘ям a.out).  Python – сучасний і досить елегантний об'єктно-орієнтований інтерпретатор. Він дозволяє використати ефективні високо рівневі структури даних і пропонує простий, але ефективний підхід до об'єктноорієнтованого програмування. Інтерпретатор Python і багато стандартних бібліотек знаходяться у вільному доступі у вигляді вхідних кодів і двійкових файлів для усіх основних платформ. Додаткова інформація на офіційному сайті Python http://www.python.org . Виконання програми: рython [ option | filename ]... 72 5) Пакетна обробка обчислювальних задач Обчислювальні задачі на кластері слід виконувати лише за допомогою локального планувальника задач. Система управління завданнями Torque версії 2.3.6 з менеджером ресурсів Maui 3.2.6. , яка встановлена на учбовому кластері, призначена для управління запуском завдань на дозволяє багатопроцесорних автоматично обчислювальних розподіляти системах. обчислювальні ресурси Вона між завданнями, управляти порядком їх запуску, часом роботи, отримувати інформацію про стан черг та стан виконання завдання. При неможливості запуску завдань негайно, вони ставляться в чергу і чекають, поки не звільняться потрібні ресурси. Планувальник задач розподіляє задачі за чергами відповідно до вказаних при запуску параметрів. Менеджер ресурсів відповідає за пошук ресурсів для задачі. При виділенні ресурсів враховується пріоритет задачі. Задачі з низьким пріоритетом будуть довше очікувати в черзі на ресурси. Для коректної роботи з Torque потрібно виконати ряд підготовчих операцій:  Налаштувати між вузлами ssh- аутентифікацію за ключами.  Додати у конфігураційний Вашого shell (за замовчуванням bash - $HOME/.bashrc) наступний рядок: PATH=$PATH:/opt/torque/bin Основні команди для роботи з системою управління завданнями наведені в таблиці. Команда qsub Пояснення Постановка задачі у чергу 73 Перегляд стану черг та виконуваних qstat задач qalter Зміна параметрів поставлених задач qhold Перевод задачі у стан очікування qrerun Перезапуск задачі qrls Звільнення задачі зі стану очікування qdel Видалення задачі з системи керування ресурсами Надсилання задачі сигналу qsig Коротко розглянемо роботу з деякими з них. 5.1) qsub - команда призначена для відправки завдання на виконання. Підтримується: режим вводу параметрів задачі через опції qsub; із читанням тіла задачі із стандартного вводу; повний опис задачі в окремому файлі. Процес виконання задачі, відправленої за допомогою команді qsub, має наступні кроки:  задача ставиться в чергу, вказану в описі завдання (опція -q);  відповідно до запиту на ресурсі (опція -l) обираються обчислювальні вузли, на яких задача буде виконуватись;  скрипт задачі запускається на одному з вузлів із встановленими змінними середовища, які дозволяють дізнатись про список виділених ресурсів;  далі під час виконання завдання за розподіл навантаження відповідає сам скрипт задачі. 74 Найважливіші опції: -q <назва черги> Задає чергу, до якої треба помістити задачу. Наразі в якості імені треба вказувати local. -l <специфікація потрібних ресурсів> необхідні для виконання Дозволяє визначити задачі ресурси. Задавати їх слід у формі назва_ресурсу=значення,назва_ресурсу=значення... Найбільш використовувані опції: cput - максимальна кількість процесорного часу, використовуваного всіма процесами задачі; nodes - кількість вузлів, резервованих для задачі. Підтримується зазначення атрибутів вузлів, як то кількість процесорів на вузол; walltime - максимальна кількість реального часу, під час якого задача може знаходитись у стані виконання; pmem - максимальна кількість пам'яті для одного процесу задачі. -o <назва файлу> Шлях до файлу, в якому буде збережено стандартній потік виводу задачі. -e <назва файлу> Шлях до файлу, в якому буде збережено стандартній потік помилок задачі. -k o|e|oe|n Вказує менеджеру не копіювати файли виводу на вузол, з якого задача була поставлена. Натомість, вони залишаються на вузлі, на якому виконувалася задача. -t <список> Зручна можливість запускати масив задач. 75 Приклад №1 Для локальних користувачів призначена черга local, яку треба явно вказати за допомогою параметру -q команди постановки задачі qsub. В якості тіла завдання, виконаємо команду hostname, що відобразить назву вузла, на якому виконувалась задача. Примітка. В наступному прикладі після введення 'hostname' потрібно натиснути Enter і Ctrl+D [student@n03 ~]$ qsub -q local hostname 5034.pbs.kpi Тут 5034.pbs.kpi - ідентифікатор завдання у локальній системі, за яким можна за ним слідкувати. Майже одразу таке коротке завдання завершується і у директорії, з якої воно було поставлене, з'являються вихідні файли: [student@n03 ~]$ ls STDIN.e5034 STDIN.o5034 ... [student@n03 ~]$ cat STDIN.* n04 Як видно, задача виконувалась на вузлі №4. Приклад №2 Наступний приклад - запуск задачі за допомогою файлу опису задачі. Вхідний файл (назвемо його - mybatch) має наступний вигляд: #!/bin/bash #PBS -l nodes=1:ppn=4 #PBS -N test #PBS -o job.out 76 #PBS -e job.err echo Running on host `hostname` echo Time is `date` echo Directory is `pwd` echo This jobs runs on the following processors: echo `cat $PBS_NODEFILE` echo $PBS_NODEFILE Пояснимо цей опис: Рядок Пояснення #!/bin/bash Виклик стандартного інтерпретатора #PBS -l nodes=1:ppn=4 Ресурси: 1 вузол з 4 ядрами #PBS -N test Назва для задачі (до 15 символів) #PBS -o job.out Вихідний файл ~/job.out #PBS -e job.err Файл для повідомлень про помилки ~/job.err Далі йдуть команди до виконання: echo Running on host Вивести назву хоста, де виконується задача `hostname` echo Time is `date` Вивести дату echo Directory is `pwd` Вивести робочий каталог echo This jobs runs on the following processors: echo `cat Вивести вміст файлу зі списком вузлів, $PBS_NODEFILE` призначених задачі echo $PBS_NODEFILE Вивести назву файлу зі списком вузлів, призначених задачі 77 Відправка на виконання тестового скрипту здійснюється по команді: [student@n03 ~]$ qsub mybatch Якщо на момент запуску на кластері будуть доступні ресурси, вказані в описі задачі, то майже одразу можна переглянути результат: [student@n03 ~]$ cat job.* Running on host n04 Time is Срд Гру 29 13:51:16 EET 2010 Directory is /home/localusers/bogdan This jobs runs on the following processors: n04.kpi n04.kpi n04.kpi n04.kpi /var/spool/torque/aux/n04//5036.pbs.kpi Приклад №3 При формуванні скрипта завдання можуть бути вказані, як необхідні, умови виконання завдання, різні параметрі обчислювальних ресурсів. Наприклад, можна вказати певний обчислювальний вузол, набір вузлів з певними параметрами та інше. В наведеному прикладі завдання для свого виконання потребує обчислювальний вузол з 200 Мб вільної оперативної пам‘яті. [student@n03 ~]$ qsub -l mem=200mb /home/user/script.sh В наступному прикладі завдання для свого виконання потребує вузол node01 з 200 Мб вільної оперативної пам‘яті. [student@n03 ~]$ qsub -l nodes=node01,mem=200mb /home/user/script.sh 78 Слід зауважити що завдання буде чекати в черзі поки вузол node01 не звільниться від завдань. Приклад №4 Коли завдання виконується, командний скрипт використовує набір змінних середовища для виконання певних дій за алгоритмом завдання, наприклад, створення вихідних файлів. Деякі корисні змінні середовища, які передаються задачі, наведені в таблиці. Змінна Пояснення PBS_VERSION Версія системи керування задачами (СКЗ) PBS_SERVER DNS-ім'я сервера СКЗ PBS_JOBNAME Назва задачі, визначена користувачем PBS_JOBID Ідентифікатор задачі, визначений сервером СКЗ PBS_ENVIRONMENT Тип задачі: PBS_BATCH - для пакетної, та PBS_INTERACTIVE - для інтерактивної PBS_ARRAYID Порядковий номер, якщо запущений масив задач PBS_TASKNUM Номер задачі на вузлі PBS_NODENUM Порядковий номер вузла PBS_VNODENUM Порядковий номер віртуального вузла (ЦП) PBS_NODEFILE Шлях до файлу, в якому записаний список вузлів, призначених задачі PBS_QUEUE Назва черги, в яку потрапила задача PBS_O_HOST Назва вузла, з якого запущено задачу PBS_O_LOGNAME Реєстраційне власника 79 ім'я (логін) користувача- Робоча директорія, з якої було запущено PBS_O_WORKDIR задачу Домашня тека користувача на вузлі, з якого PBS_O_HOME запущено задачу PBS_O_SHELL Інтерпретатор команд користувача-власника PBS_O_PATH Список шляхів користувача-власника PBS_O_LANG Мова користувача-власника 5.2) qstat - команда призначена для перегляду стану черг та виконуваних задач. Опції: <без параметрів> Інформація про власні задачі у стандартному вигляді. -q Інформація про черги. -a Інформація про задачі усіх користувачів. -f Інформація про задачі у розширеному вигляді. Приклад №5 Для отримання інформації про всі черги та задачі користувача необхідно виконати команду qstat без параметрів. Припустимо, у користувача виконується одна задача: [student@n03 ~]$ qstat Job id Name User Time Use S Queue ------------------------- ---------------- --------------- -------- - ----5041.pbs test student 80 0 R local В отриманій відповіді: Job id Ідентифікатор задачі, що отриманий при виконанні Name Ім‘я задачі User Ім‘я користувача, що запустив задачу Time Use Процесорний час, який витрачено задачею S (State) Стан задачі: R - задача виконується, Q - чекає у черзі Queue Черга Команда qstat з параметром –а дасть більш розширену інформацію про задачі. Виконання qstat з параметром –Q дасть коротку інформацію про всі черги та задачі. Виконання qstat з параметром –В дасть зведену статистику за всіма чергами. Отримання інформації про задачі інших користувачів неможливо, можливо переглядати лише загальне число запланованих та запущених задач. 5.3) qalter - команда дозволяє змінювати параметри відправлених на виконання задач. Не можна змінювати параметри задач, що виконуються на даний момент. Список опцій схожий на такий у команди qsub. 5.4) hold - за допомогою команди можна перевести задачу у стан очікування. 5.5) qrls - команда звільняє задачу зі стану очікування. 5.6) qrerun – повторна відправка задачі на виконання. 5.7) qdel - команда видаляє задачі з системи керування ресурсами. 81 5.8) команда дозволяє надіслати задачі сигнал на зразок UNIX-команди kill Приклад №6 Відміна виконання програми здійснюється командою qdel идентифікатор_задачі: [student@n03 ~]$ qdel 5041.pbs Цією командою задача, яка стоїть у черзі, видаляється з неї, а задача, що вже виконується, знімається з виконання. Далі почне виконуватися наступна за чергою та пріоритетом задача. Задача знімається протягом деякого часу, тобто при виконанні qstat безпосередньо після qdel видалена задача все ще може бути відображена в таблиці. Рекомендації щодо запуску задач на навчальному кластері 1. Параметри вузлів учбового кластера дають можливість розраховувати на приблизно 1Гб оперативної пам'яті на ядро (вузли бездискові, тому файлу підкачки немає). Слід уникати перевищення цього значення, адже це може призвести до аварійного завершення задач. Вказування при запуску кількості необхідної пам'яті не гарантує наявності вказаного об'єму вільної оперативної пам'яті на вузлі. 2. Якщо задача використовує не тісний паралелізм (тобто немає значного обміну даними між процесами), то при запуску краще вказувати необхідну кількість ядер, а не відповідну кількість процесорів. Таким чином можна скоротити час очікування задачі в черзі. 3. Наступні дві команди є еквівалентними: 82 qsub -q local -l nodes=8 qsub -q local -l nodes=8:ppn=1 Як перша, так і друга забезпечать отримання 8-ми обчислювальних ядер на одному чи декількох вузлах. Ядра виділяться незалежно одне від одного. Розподіл по вузлах може бути будь-яким, наприклад: 8, 1+7, 2+2+3+1, 1+1+1+1+1+1+1+1 тощо. Проте, якщо команда має значення ppn>1, то менеджер виділить саме ту кількість вузлів, що вказана у nodes. 2.4 Приклад виконання роботи Завдання: Розробити програму яка обчислює функцію sin(x) за допомогою апроксимації рядом Тейлора, та виконати обчислення на учбовому кластері с використанням локальної системи керування кластером. Провести оцінку похибки наближення для різних n і кожного фіксованого x. Крок 1: Розробка алгоритму обчислення З підручника з чисельних методів відомо: якщо функція f(x) нескінченно диференціюється в деякому околі точки a, то формальний ряд  f ( k ) (a) ( x  a)  зветься рядом Тейлора функції f в точці a. (k )! i 0 k Ряд Тейлора може бути використано для апроксимації функцій. Так sin(x) може бути представлено наступним рядом: n Sin ( x, n)   (1) i 1 i 1 x 2*i 1 , де n -> ∞ (2 * i  1)! В залежності від кількості членів ряду ми отримаємо різні наближення до точного значення sin(x). 83 Крок 2: Розробка програми обчислення Реалізуємо обраний алгоритм, приміром, на мові програмування python. За допомогою текстового редактору створимо файл sinsum.py, який матиме вигляд: import os.path import xml.dom.minidom as dom from math import sin # function to compute the Sin(x,n) sum def Sin(x, n): s=x term = x for i in range(2, n+1): term = term * x**2 / ((2 * float(i) - 2) * (2 * float(i) - 1)) s += (-1)**(i-1) * term value_of_sum = s first_neglected_term = (-1) * term * x**2 / ((2 * float(n+1) - 2) * (2 * float(n+1) - 1)) exact_error = sin(x) - value_of_sum return value_of_sum, first_neglected_term, exact_error # build the table of results def table(x, nlist): print '\nx=%g, sin(x)=%g' % (x, sin(x)) for n in nlist: n = int(n) value, next, error = Sin(x, n) print 'n=%-8d %-16g (next term: %16.12e '\ 'error: %16.12e)' % (n, value, next, error) # determine the xml data file path 84 filename = "sinsum.xml" filepath = "task_7/" + filename if os.path.isfile(filepath): filename = filepath # open xml file and get the doc = dom.parse(filename) root = doc.getElementsByTagName("root")[0] for node in root.childNodes: if node.nodeType == node.ELEMENT_NODE: data = node.firstChild.nodeValue.split(', ') if node.nodeName == 'x': xlist = data if node.nodeName == 'n': nlist = data # walk across the list of x from xml for x in xlist: table(float(x), list(nlist)) # use epsilon to determine the error level def Sin2(x, epsilon=1.0E-6): x = float(x) i=2 term = x s = term while abs(term) > epsilon: term = term * x**2 / ((2 * float(i) - 2) * (2 * float(i) - 1)) s += (-1)**(i-1) * term i += 1 return s, i - 1 85 x = 20 print "\nfor x = %d:" % x for k in range(2, 20, 2): epsilon = 10**(-k) approx, n = Sin2(x, epsilon=epsilon) exact = sin(x) exact_error = exact - approx print 'epsilon: %7.1e, exact error: %16.12e, n=%d' % \ (epsilon, exact_error, n) Необхідні дані для розрахунку помістимо в файл sinsum.xml, який матиме вигляд: <?xml version="1.1" encoding="UTF-8"?> <root> <x>0.01, 0.1, 0.7, 1, 1.2</x> <n>1, 2, 5, 10, 25, 50, 75, 100, 250, 500</n> </root> Крок 3: Розробка опису завдання для локального планувальника кластеру На навчальному кластері в якості локальної системи управління використовується система PBS тому слід підготувати опис завдання на виконання. За допомогою текстового редактору створимо файл sinsum. sh, який матиме вигляд: #!/bin/bash #PBS -r n #PBS -N task_7 #PBS -q short #PBS -o sinsum.out #PBS -e sinsum.err 86 #PBS -l walltime = 00:30:00 #PBS -l select=mem=100mb:ncpus=1:nodes=1 date python sinsum.py date В необхідних умовах для завдання ми додатково вказали граничний час виконання - 30 хвилин, об‘єм оперативної пам‘яті - 100 Мб. В файлі результатів виконання нашої програми буде додатково відображено номер обчислювального вузла кластера, на якому виконувалось завдання, час початку розрахунків та завершення розрахунку (команди hostname та date) для оцінки часу виконання обчислень. Крок 4: Відправка завдання на виконання Тепер можна відправити наш скрипт опису завдання на виконання та перевіряти стан задачі: [student@n03 ~]$ qsub sinsum.sh 5048.pbs.kpi [student@n03 ~]$ qstat Job id Name User Time Use S Queue ------------------------- ---------------- --------------- -------- - ----5048.pbs sinsum student 0 R local Примітка. В результаті виконання програми програмами генерується і файл помилок виконання. Даній крок повторюється до тих пір поки файл помилок буде нульового розмиру. Крок 5: Перевірка результатів розрахунків 87 Після завершення розрахунків матимемо файл з результатами sinsum.о: [student@n03 ~]$ ls -la sinsum.o -rw------- 1 student student 30176 Dec 29 17:41 sinsum.o Зміст файлу результатів можна переглянути за допомогою редактору і потім скопіювати на комп‘ютер користувача для підготовки звіту. Нижче представлено перші 1000 символів змісту файлу результатів розрахунку sin(x): Результати розрахунків для двох значень x=0.01 та x=0.1 мають вигляд: x=0.01, sin(x)=0.00999983 n=1 0.01 (next term: -1.666666666667e-07 error: -1.666658333357e-07) n=2 0.00999983 (next term: -8.333333333333e-13 error: 8.333316675602e-13) n=5 0.00999983 (next term: -2.505210838544e-30 error: 0.000000000000e+00) n=10 0.00999983 (next term:-1.957294106339e-62 error: 0.000000000000e+00) n=25 0.00999983 (next term:-6.446959640457e-169 error: 0.000000000000e+00) n=50 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=75 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=100 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=250 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=500 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) x=0.1, sin(x)=0.0998334 n=1 0.1 (next term: -1.666666666667e-04 error: -1.665833531719e-04) n=2 0.0998333 (next term: -8.333333333333e-08 error: 8.331349481139e-08) n=5 0.0998334 (next term: -2.505210838544e-19 error: -1.387778780781e-17) n=10 0.0998334 (next term: -1.957294106339e-41 error: -1.387778780781e-17) n=25 0.0998334 (next term: -6.446959640457e-118 error: -1.387778780781e-17) n=50 0.0998334 (next term: -1.060901275372e-261 error: -1.387778780781e-17) n=75 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) 88 n=100 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) n=250 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) n=500 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) 2.5 Порядок виконання лабораторної роботи 1) Отримати у викладача обліковий запис (логін та пароль) на сервері доступу учбового кластеру. Користувач має доступ до кластера та можливість роботи на ньому з будь-якого комп‘ютера, який знаходиться у локальній мережі інституту чи Інтернет. Віддалений доступ до сервера доступу кластера здійснюється за допомогою SSH (робота з ssh-клієнтами для Windows- и Linux-машин розглянута вище). Параметри SSH-з‘єднання, прийняті в даному лабораторному практикумі (актуальна інформація уточнюється у викладача), наступні:  Доступ з мережі Інтернет - адреса: cn.hpcc.ntu-kpi.kiev.ua (77.47.192.51) порт: 2222  Доступ з локальної мережі КПИ – адреса: (10.6.12.252) порт: 222 2) Розробити алгоритм обчислення функції (згідно обраного варіанту Додаток №4) та програму, яка реалізує даний алгоритм. 3) Розробити опис завдання для виконання на учбовому кластері за допомогою системи PBS. 4) Провести розрахунки на учбовому кластері. Оцінити час виконання. 5) Скласти протокол виконання лабораторної роботи. Протокол повинен містити: завдання студента згідно варіанту; опис обраного алгоритму обчислення; текст програми, яка реалізує обраний алгоритм обчислення; скріншоти послідовності виконання команд відправки на 89 виконання та перевірки статусу виконання завдання і отримані повідомлення; результати розрахунків. 2.6 Завдання до лабораторної роботи Приклади завдань (варіанти завдань наведені в Додатку №4) Обчислити значення функції exp(x) в двох фіксованих точках за допомогою апроксимації функції рядом Тейлора і оцінити отриману похибку в залежності від кількості членів ряду. Для аналітично заданої функції f(x) = x-sin(x) сформувати регулярну таблицю відліків в вузлах (бажано, щоб амплітуда інтервалу не перевищувала 1), приблизити отримані дані інтерполяційним поліномом і оцінити отриману похибку, порівнявши на інтервалі початкову аналітично задану функцію і значення поліному. 2.7 Контрольні запитання 1. Симетричні багатопроцесорні системи (Symmetric Multiprocessing, SMP). Побудова, особливості, переваги і недоліки . 2. Системи з неоднорідним доступом до пам'яті (Non - Uniform Memory Access, NUMA). Побудова, особливості, переваги і недоліки . 3. Системи з розподіленою пам‘яттю (Massively parallel processing, MPP). Побудова, особливості, переваги і недоліки. 4. Кластерні системи. Побудова, особливості, переваги і недоліки. 5. Пояснити терміни продуктивності обчислювальної системи: пікова (теоретична, гранична) і реальна. 6. Архітектура кластерів типу Beowulf . Функції елементів кластеру. 7. Які технічні засоби для віддаленої роботи на кластері ви знаєте? 90 8. Як саме ви їх використовували? 9. Що таке планувальник задач, його функції? 10. Що таке менеджер ресурсів, його функції? 11. Основні команди PBS та їх параметри. 12. Назвіть послідовність дій при запуску обчислювальних задач на кластері. Література 1. Евгений Борисов. Вычислительные системы сверхвысокой производительности. http://mechanoid.narod.ru/high_perf/index.html 2. Михаил Кузьминский. Кластеры на базе ОС Linux. Ж. «Computer World», №5,1998. 3.. Вл. В. Воеводин. Суперкомпьютерная грань компьютерного мира. http://parallel.ru/vvv/intro2hpc.html 4. Воеводин Вл.В., Жуматий С.А."Вычислительное дело и кластерные системы".-М.: Изд-во МГУ, 2007. - 150 с. (http://www.parallel.ru/info/parallel/cluster/) 5. Лацис А. Как построить и использовать суперкомпьютер.-М.: Бестселлер, 2003.-240с. 6. Немет Є., Снайдер Г.,Сибасс С., Хейн Т. UNIX. Руководство системного администратора. Для профессионалов.-СПб.:Питер, 2006.928 с. 91 Завдання № 3. Отримання сертифікату користувача Мета: вивчення технології забезпечення безпеки грідінфраструктури та отримання сертифікатів користувачів для роботи в навчальній грід-системі. 3 Короткі теоретичні відомості 3.1 Інфраструктура відкритого ключа Криптографія є галуззю прикладної математики, яка займається питаннями безпеки передачі даних. У криптографії відправник переводить незахищену інформацію (звичайний текст) у закодований текст (цифровий текст). Одержувач використовує засоби криптографії для переведення отриманого цифрового тексту назад у звичайний текст, а також для перевірки особистості відправника, цілісності даних або кількох із названих показників одночасно. Криптографічні технології можна використовувати для забезпечення повного спектру послуг з безпеки. Цифровий підпис є одним із механізмів, які можна застосовувати для захисту автентичності і цілісності електронних документів. Його можна використовувати для документу будь-якої форми, який обробляється в електронному вигляді. Цифровий підпис реалізується за допомогою методу криптографії на основі унікальної зв‘язаної пари ключів, в якій один з них використовується для створення підпису (приватний ключ), а другий – для перевірки підпису (відкритий ключ). Приватний ключ повинен зберігатися у таємниці, оскільки будь-хто, хто має до нього доступ, може підписувати документи. На доповнення до цього, захист цілісності відкритого ключа також є важливим. Такий захист здійснюється шляхом використання сертифікату відкритого ключа. 92 В грід системах існує спеціальна підсистема безпеки для забезпечення безпечного доступу до ресурсів в незахищених мережах загального доступу (Інтернет) з урахуванням прав даного користувача і правил обслуговування користувачів даним ресурсним центром (такі правила часто називають «локальною політикою»). Практично у всіх великих грід-системах робота цієї підсистеми заснована на інфраструктурі безпеки Grid (Grid Security Infrastructure, GSI), яка розроблена Globus Alliance [ 1 ]. Підсистема конфіденційність надає передачі такі сервіси, інформації і як аутентифікація, делегування прав. Під делегуванням прав мається на увазі, що користувачеві потрібно лише один раз пройти процедуру аутентифікації, а далі система сама забезпечить його аутентифікацію на всіх ресурсах, які він планує використовувати. GSI, у свою чергу, заснована на надійній і широко використовуваній технології відкритих криптографічних ключів (Public Кеу Infrastructure, PKI). Термін «інфраструктура відкритого ключа» (ІВК) походить від криптографії відкритого ключа. Інфраструктура відкритого ключа є поєднанням програмного забезпечення, шифрувальних технологій і послуг, які допомагають забезпечити безпеку комунікацій і бізнесоперацій у мережах загального доступу. Інфраструктура відкритого ключа об‘єднує цифрові сертифікати, криптографію відкритого ключа і органи сертифікації та забезпечує побудову загальної архітектури безпеки організації. Типова ІВК включає в себе видачу цифрових сертифікатів індивідуальним користувачам і серверам, програмне забезпечення з реєстрації кінцевого користувача; 93 інтеграцію із сертифікатами; інструменти для управління, оновлення та скасування сертифікатів, а також інші послуги і підтримки, пов‘язані з ними. До функціональних елементів інфраструктури відкритого ключа відносяться органи сертифікації, органи реєстрації, сховища та архіви. – Орган сертифікації (ОС) як нотаріус видає або скасовує сертифікати. – Орган реєстрації (ОР) – організація, якій ОС довіряє зареєструвати або яка ручається перед ОС за зв‘язок між відкритими ключами та ідентифікацією власників сертифікатів. – Сховище – це база даних активних сертифікатів і список анульованих сертифікатів – САС (Certificate Revocation List – CRL) для системи ОС. – Архів є базою даних, яку використовують при вирішенні майбутніх спорів. – Користувачі ІВК – це організації або фізичні особи, які використовують ІВК, але не видають сертифікати. Орган сертифікації є базовим складовим компонентом для ІВК, сукупністю комп‘ютерних технічних засобів, програмного забезпечення і людей, які управляють ними. Він має своє ім‘я і відкритий ключ. Орган сертифікації виконує такі 4 основні функцій ІВК: 1. Видає сертифікати. 2. Має інформацію про статус сертифікату і видає САС. 3. Видає свої поточні сертифікати і САС. 4. Містить архіви даних про статус виданих ним сертифікатів, що втратили юридичну силу. Орган сертифікації випускає цифровий сертифікат для ідентифікації кожної окремої особи, підтверджуючи, що особа має відповідні повноваження. Цифровий сертифікат зазвичай містить 94 відкритий ключ, інформацію про особу власника відповідного приватного ключа, термін дії сертифікату, а також власний цифровий підпис ОС. Орган сертифікації також повинен видавати та обробляти списки анульованих сертифікатів, які містять перелік усіх сертифікатів, дію яких скасовано. Орган реєстрації створено для перевірки даних сертифікату для ОС. Орган реєстрації є системою комп‘ютерних технічних засобів, програмного забезпечення і людей, які управляють ними. На відміну від ОС, ОР часто управляється одною людиною. Кожен ОС має список акредитованих ОР; ОС знає ОР за назвою і відкритим ключем. Додатки ІВК у значній мірі залежать від служби каталогів із дистрибуції сертифікатів і даних про сертифікати, що лежать в їх основі. Каталог забезпечує засоби для зберігання і розповсюдження сертифікатів, а також управління процесом внесення оновлень у сертифікати. Архів відповідає за тривале зберігання інформації від імені ОС. Архів встановлює те, що інформація була коректною в момент її отримання і не піддавалася модифікації в період її зберігання в архіві. Архів захищає інформацію за допомогою технічних механізмів і відповідних процедур під час її перебування в архіві. Якщо в майбутньому виникає спір щодо підпису, цю інформацію можна використовувати для встановлення факту застосування для підписання документу приватного ключа, пов‘язаного із сертифікатом. Власники сертифікату отримують інші сертифікати від ОС в залежності від організації або спільноти, членами якої вони є. ІВК зазвичай складається з багатьох ОС, пов‘язаних вивіреними каналами. Вивірений канал пов‘язує сторону з одною або кількома вивіреними 95 третіми особами, такими чином, щоб сторона, яка покладається, могла мати упевненість в дійсності використовуваного сертифікату. Є дві традиційні архітектури побудови ІВК, а саме: ієрархічна і переплетена. Третій підхід, з‘єднана архітектура ОС, був розроблений з метою вирішення проблеми, що стоїть перед організаціями, які шукають шляхів з‘єднання своєї ІВК з ІВК їх ділових партнерів. У ієрархічній архітектурі органи сертифікації організовані за ієрархією під «кореневим» ОС, який видає сертифікати підлеглим ОС. Ці ОС можуть видавати сертифікати іншим ОС або користувачам, які знаходяться нижче за них в ієрархії зв‘язків. В ієрархічній ІВК кожна сторона, яка покладається, знає відкритий ключ свого кореневого ОС. Будь-який сертифікат можна перевірити, перевіривши канали сертифікації для сертифікатів, починаючи з кореневого ОС. У переплетеній архітектурі незалежні ОС сертифікують один одного (тобто видають сертифікати один одному), що дає результат загального переплетіння вивірених зв‘язків між рівними ОС. Сторона, яка покладається, знає відкритий ключ ОС «біля» неї, і, як правило, того, хто видав її сертифікат. Сторона, яка покладається, здійснює перевірку сертифікату шляхом перевірки каналу сертифікації, який походить від вивіреного ОС. У грід-інфраструктурі існує певна кількість незалежних органів сертифікації – засвідчувальних центрів (Центрів сертифікації). Ці центри мають свої підписані сертифікати, тобто у них немає спільного кореневого сертифікату. Проте у грід створена можливість розповсюдження довіри між його суб‘єктами. Це робиться шляхом встановлення у систему (імпорту) пакету файлів з описом кожного Засвідчувального центру: відкритого ключа, списку скасованих сертифікатів, опису політики іменування тощо. Таким чином, кожен 96 учасник грід довіряє лише тим суб‘єктам, які отримали сертифікати у засвідчувальних центрах, які вибрав даний учасник. 3.2 Ідентифікація користувачів і Grid вузлів В якості ідентифікаторів користувачів і ресурсів в GSI (Grid Security Infrastructure) використовуються цифрові стандарту X.509 (стандарт міжнародної організації сертифікати International Telecommunication Union, ITU). У роботі з сертифікатами X.509 і в процедурі видачі/отримання сертифікатів задіяне три сторони: 1. Центр Сертифікації (Certificate Authority, CA) – спеціальна організація, яка володіє повноваженнями видавати (підписувати електронним способом) цифрові сертифікати. Різні CA зазвичай незалежні між собою. Стосунки між CA і його клієнтами регулюються спеціальним документом і довіра до сертифікату будується на довірі до центру сертифікації, який підписав цей сертифікат. 2. Власник сертифікату – користувач грід або грід-ресурс, який користується сертифікаційними послугами центру сертифікації. Центр сертифікації включає в сертифікат дані, які надаються власником (ім'я, організація і іншу інформацію) і завіряє його своїм цифровим підписом. Зокрема власникові сертифікату привласнюється унікальне ім'я (Distinguished Name, DN), наприклад, a. “O=Grid/O=Globus/OU=itso.grid.com/CN=Sergiy Petrov“ 3. Користувачі або ресурси, які виконують аутентифікацію інших грід-об'єктів – вони покладаються на інформацію з сертифікатів при отриманні його від об'єктів, який ідентифікуються. Вони можуть приймати або відмовляти в прийомі сертифікатів, які підписані певним CA. 97  ім'я суб'єкта: ідентифікує особу або об'єкт, які представлені сертифікатом.  відкритий ключ, що належить цьому суб‘єкту.  ідентифікаційні дані центру сертифікації, який підписав сертифікат, чим засвідчив, відповідність публічного ключа та імені суб‘єкту.  розширення сертифіката, що містять додаткові інформаційні дані, а також обмеження на сферу застосування сертифіката.  цифровий підпис даного центру сертифікації. Certificate: Data: Version: 3 (0x2) Serial Number: 10 (0xa) Signature Algorithm: sha1WithRSAEncryption Issuer: C=UA, L=KYIV, O=HPCC, CN=KPIEDU CA Validity Not Before: Dec 19 02:49:47 2010 GMT Not After : Dec 19 02:49:47 2011 GMT Subject: DC=org, DC=kpiedu, O=people, CN=da2121 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:b0:1b:9d:f8:be:34:b5:17:95:43:5e:e4:ef:a5: ef:3b:22:5c:d8:15:cc:72:82:7f:8a:58:97:c2:46: <--------- Вирізано декілька рядків --------> 2a:15:3e:a4:65:63:ca:5f:97:cb:e0:36:b7:2b:17: b9:5e:5f:7b:7c:b1:60:57:81:a0:75:97:62:93:31: 04:9b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, E-mail Protection X509v3 Subject Key Identifier: F2:73:31:9C:55:07:5F:96:C1:FA:1A:B7:6D:A2:65:A3:BD:0B:F7:AA X509v3 Authority Key Identifier: keyid:82:DF:79:C2:D8:0C:31:4E:71:E9:14:84:BF:48:50:73:27:F3:AC:D6 X509v3 Certificate Policies: Policy: 0.0.0.1 Signature Algorithm: sha1WithRSAEncryption a1:66:71:e8:9d:36:98:7d:8e:91:c3:e2:57:46:e9:93:75:55: 09:38:54:a1:72:c1:92:83:dc:fe:32:1f:a3:e8:b0:e0:ec:3a: <--------Вирізано декілька рядків --------> b4:0d:d8:dc:2c:18:8e:38:68:68:bd:e7:65:65:60:08:cb:aa: cc:65:0a:79:e6:90:2d:6a:47:bf:f3:05:e7:9b:9a:93:dc:b6: 31:1c:25:53 Рис. 3.1 - Структура сертифікату В GSІ використовуються два типи сертифікатів X.509:  Сертифікат користувача (User Certificate), який повинен мати кожен користувач, що працює з грід-системою. Сертифікат користувача містить інформацію про ім'я користувача, організацію, до якої він належить, і центр сертифікації, який видав даний сертифікат. 98  Сертифікат вузла (Host Certificate) повинен мати кожен вузол (грід-сервіс або ресурс) грід-системи. Сертифікат вузла аналогічний сертифікату користувача, але в ньому замість імені користувача вказується доменне ім'я конкретного грід-вузла. Сертифікат стандарту Х.509 GSI (Grid Security Infrastructure) включає такі основні елементи, показані на рис.3.1. Дійсні сертифікати зберігаються в спеціальному репозиторії центру сертифікації; там же зберігається список відкликаних сертифікатів (Certificate Revocation List, CRL). Центр сертифікації засвідчує приналежність сертифіката даному користувачеві або грідвузлу, які ідентифікуються своїми унікальними іменами (Distinguished Name, DN). Для генерації несиметричний сертифікату алгоритм використовується шифрування. При в цьому основному в режимі шифрування відкритий ключ використовується для шифрування, закритий ключ – для розшифровки. У випадку використання цифрового підпису: закритий ключ – для шифрування, відкритий ключ – для розшифровки. Цифровий підпис може створити лише власник закритого ключа. Тому важливою вимогою є безпечне зберігання закритого ключа. 3.3 Делегування прав і використання довіреності Важливою умовою для ефективної роботи розподілених систем є можливість делегування прав користувача грід-сервісам. Річ у тому, що практично будь-який запит користувача проходить через декілька сервісів. І якби не було механізму делегування, користувачеві було б необхідно аутентифікуватися на кожному сервісі в ланцюжку, що 99 оброблює даний запит. Це означає, що користувач після відправлення завдання має невідривно бути біля свого комп'ютера і відповідати на запити про свою аутентифікацію від кожного сервісу в ланцюжку. Фактично це робить роботу в грід-середовищі неможливою – в усякому разі, при запуску великого набору завдань. Делегування прав дозволяє уникнути цієї проблеми. Для забезпечення безпеки в грід-системах та делегування прав користувача грід - сервісам використовується спеціальне доручення (proxy certificate, проксі-сертифікат), з коротким (близько декількох годин) терміном дії. Цю довіреність «виписує» (виконує відповідну команду користувацького інтерфейсу) сам користувач за допомогою свого постійного сертифікату, діючи в цьому випадку як «сертифікаційний центр» для самого себе. За допомогою цього проксісертифікату грід-сервіси виконують дії від імені користувача – власника сертифікату,наприклад, запускають завдання на обчислювальному ресурсі. Виконуючи команди користувача, грід-сервіси можуть взаємодіяти між собою без участі користувача. При цьому також використовується ІВК, а сервіс виконує команди від імені цього користувача. Для цього сервісу потрібен не лише сертифікат (С0), а й приватний ключ користувача (К0). Оскільки передавати комусь свій приватний ключ заборонено, то була створена система проксісертифікатів. Користувач генерує нову пару ―закритий ключ-сертифікат‖ (К1С1) та підписує створений сертифікат власним закритим ключем (К0), таким чином виступаючи засвідчувальним центром для цієї пари ―закритий ключ-сертифікат‖. Далі ця пара К1-С1, а також сертифікат користувача (С0) передається сервісу, який використовує користувач. 100 Якщо даному сервісу необхідно звернутися до іншого сервісу, то процес повторюється: генерується нова пара ―закритий ключ-сертифікат‖ (К2С2) та підписується закритим ключем, отриманим сервісом (К1), а потім ця пара (К2-С2) та всі попередньо отримані сервісом ключі та сертифікати (С0,С1,К1) передаються далі. Як видно з рис.3.2, утворюється так званий ланцюг довіри К0-С0-К1-С1-К2-С2. Рис.3.2 - Ланцюг довіри Перевірка ланцюга довіри відбувається наступним чином. Нехай сервіс отримав такий набір С0-К1-С1-К2-С2, тоді послідовність дій така: – перевіряється, що ключ К2 відповідає сертифікату С2; – перевіряється, що сертифікат С2 підписаний ключем К1 (тобто підпис на сертифікаті С2 можна розшифрувати за допомогою відкритого ключа з сертифікату С1); – перевіряється, що ключ К1 відповідає сертифікату С1; 101 – перевіряється, що сертифікат С1 підписаний ключем К0 (тобто підпис на сертифікаті С1 можна розшифрувати за допомогою відкритого ключа з сертифікату С0). Якщо перевірки пройшли вдало, то К2-С2 можуть використовуватися у подальших взаємодіях. Якщо на одному з етапів перевірка показала якусь невідповідність (неспівпадання), то ланцюг довіри визначається як розірваний, тобто довіра між сервісами не встановлюється і взаємодія не відбувається. Така помилка може свідчити про намагання отримати несанкціонований доступ до ресурсів з боку третіх осіб від імені власника сертифікату С0. Проксі-сертіфікат не може бути відкликаний, тому створення довгострокової довіреності дуже небажано. Проте при виконанні операцій, які вимагають достатньо великого проміжку часу, може закінчитися термін дії такого доручення, що призведе до некоректного завершення операції. Для виключення подібних випадків використовують спеціальний сервіс, який за запитом користувача автоматично відновлює термін дії проксі-сертифікату без втручання користувача. За своєчасним оновленням проксі-сертифікату стежить брокер ресурсів підсистеми управління завантаженням. При використанні сервісу відновлення доручення, користувач цілком довіряє йому свої повноваження на весь час дії довготривалого сертифікату. 3.4 Сервіс управління віртуальними організаціями і авторизація користувачів Віртуальна організація (ВО) є одним з ключових понять грідтехнологій. ВО об'єднують співтовариство користувачів, які спільно працюють в деякій прикладній галузі. Таким чином, користувачі, які належать одній ВО, пред'являють до грід-ресурсів приблизно однакові 102 вимоги і можуть обслуговуватися на уніфікованому рівні, що значно спрощує управління грід. Кожна віртуальна організація має власну політику, і відповідно до неї надаються ресурси користувачам даної ВО. З технічної точки зору відомості про зареєстрованих в даній грідінфраструктурі віртуальні організації та їх склад зберігаються в базі даних, яка використовуються ресурсними центрами для вирішення питання про допуск завдань конкретного користувача на даний ресурс. Грід-ресурси надаються на основі політики самої віртуальної організації і локальної політики ресурсних центрів – в цьому і полягає процес авторизації. Для гнучкого управління правами різних користувачів віртуальна організація може мати внутрішню структуру, тобто містити різні групи користувачів, а окремим користувачам можуть бути приписані різні ролі. Цим різним групам і ролям в процесі авторизації привласнюються різні права доступу до грід-ресурсів (відповідно і до політики ресурсних центрів). Рис.3.3 - Механізм авторизації VO LDAP 103 На початковій стадії розвитку грід, коли кількість користувачів була не велика, для авторизації на віддаленому ресурсі використовувався простий механізм, запропонований у проекті Globus. Всі користувачі, які мають визначалися в право виконувати задачі на ресурсі, простому текстовому файлі grid-mapfile. Адміністрування цього файлу виконувалося адміністраторами грідресурсу. Потім у проектах EDG і DataTAG стали використовувати Lightweight Directory Access Protocol (LDAP) - сервер для адміністрування інформації про користувачів на рівні віртуальних організацій (рис.3.3). Була розроблена утиліта mkgridmap, яка дозволяла ресурсу автоматично завантажувати інформацію з бази даних і обновляти gridmap-file. Однак, користувач періодично повинен був корегувати запис, тому що змінювалися ролі користувачів, ресурси й т.д. В грід- системі під управлінням проміжного програмного забезпечення ARC авторизація користувачів на віддаленому ресурсі і досить виконується за допомогою gridmap-file файлу. Наступним етапом розвитку авторизації користувачів стала служба VOMS (Virtual Organization Membership Service – Сервіс управління членством у віртуальних організаціях), який став основнім механізмом авторизації в проміжному програмному забезпеченні gLite. Служба VOMS була розроблена в проекті European DataGrid (http://eu-datagrid.web.cern.ch/eu-datagrid/) і вона є сервісом авторизації для управління даними в рамках декількох організаційних об'єднань. VOMS є базою даних про призначені користувачам ролі і можливості, які використовуються при виконанні дій в грід – системі та відображуються в проксі - сертифікатах користувачів. 104 В грід–системах, які працюють під управлінням проміжного програмного забезпечення gLite, інформацію для авторизації користувачів надає сервіс VOMS. Сервер VOMS використовує реляційну базу даних MYSQL або ORACLE даних як систему зберігання і реалізує додавання некритичних розширень до проксі- сертифікату користувача, які необхідні для його авторизації. Простіше кажучи, VOMS є простою базою даних облікових записів, яка надає інформацію в спеціальному форматі (VOMS повноважень). Менеджер віртуальної організації може адмініструвати її дистанційно за допомогою командного рядка або через Web-інтерфейс. Зокрема, він може присвоювати певні повноваження і права користувачам і маніпулювати цією інформацією. Аутентіфікований користувач може надіслати запит про можливість членства в віртуальної організації та про свою роль. Після того, як користувачеві буде надано членство в віртуальної організації, він може запросити короткостроковий проксі-сертифікат для доступу до ресурсів грід-інфраструктури. Для генерації проксі- сертифікату користувач виконує команду voms-proxy-init з параметрами, які відносяться до віртуальної організації, групи, ролей і можливостей, до яких він має доступ на підставі свого сертифікату. VOMS генерує короткостроковий проксі-сертифікат для аутентифікації користувача і для доступу до ресурсів грід. 105 Рис.3.4 - Архітектура сервісу VOMS Структурно VOMS (рис.3.4) складається з двох незалежних частин: - клієнтською, яка відповідає за видачу проксі-сертифікату за запитом користувача, який належить до віртуальній організації; - адміністративній частині, яка відповідає за адміністрування членства користувачів у віртуальній організації. Список членів віртуальної організації зберігається на спеціальному сервері (LDAP Server). В подальшому цей список поширюється на всі грід-ресурси, які підтримують дану віртуальну організацію. Крім того, цей список синхронізується з списком локальних користувачів, зареєстрованих на цьому грід-ресурсі (зазвичай виконується через файл grid - mapfiles у форматі Fully Qualified Attribute Names (FQANs): "/C=CH/O=CERN/OU=GRID/CN=Simone Campana 7461” .dteam "/C=CH/O=CERN/OU=GRID/CN=Andrea Sciaba 8968" .cms 106 VOMS має вбудовану систему ведення журналу, яка підтримає Unix syslog і яка може бути використана для аудиту подій, що відбуваються в системі. На даний час, більш ніж 200 віртуальних організацій працюють в рамках національних грід-проектів та в рамках міжнародного проекту EGI. Для доступу до ресурсів глобальної інфраструктури EGI необхідно бути членом однієї з них. Перелік віртуальних організацій можна знайти на сайті http://operations-portal.egi.eu/vo). 3.5 Користувач в GRID Аутентифікація і авторизація користувачів для середовищ віртуальних організацій в грід- системі має наступні властивості: - Єдиний вхід. Користувач повинен реєструватися і аутентифікуватися лише один раз на початку сеансу роботи, отримуючи доступ до усіх доступних (дозволених) ресурсів базового рівня архітектури грід. - Делегування прав. Користувач повинен мати можливість запуску програм від власного імені. Таким чином, програми отримують доступ до всіх ресурсів, на яких користувач авторизований. Користувацькі програми можуть, при необхідності, делегувати частину своїх прав іншим програмам. - Довірче відношення до користувача. Якщо користувач вимагає одночасну роботу з ресурсами декількох постачальників, то при налаштуванні захищеного середовища користувача система безпеки не повинна вимагати взаємодії постачальників ресурсів одного з одним. 107 Таким чином для отримання доступу до ресурсів грід – системи користувачеві необхідно: 1. Мати персональний цифровий сертифікат, підписаний центром сертифікації. 2. Бути зареєстрованим в віртуальній організації. Для отримання сертифікату необхідно виконати наступні кроки : – зареєструватися на сайті Центру сертифікації та отримати скрипт, за допомогою якого буде згенеровано запит на сертифікат; – виконати отриманий скрипт на комп‘ютері з встановленою бібліотекою openssl (зазвичай будь-яка UNIX-система), який згенерує приватний ключ та запит на сертифікат; – відправити згенерований запит на сертифікат до Центру інструкції, вказані сертифікації; – отримати сертифікат, виконуючи повідомленні від Центру сертифікації про підписання сертифікату. Рис. 3.5 - Процедура отримання сертифікату користувача 108 у Персональні сертифікати у форматі X.509 видаються на термін один рік з можливістю подовження терміну дії. Для вступу у відповідну віртуальну організацію необхідно: - заповнити на сайті віртуальної організації (VOMS-сервер) реєстраційну форму; - отримати по електронній пошті лист, який підтверджує факт заповнення реєстраційної форми і містить адресу Web - сторінки, на яку необхідно зайти для завершення процесу реєстрації; - дочекатися, поки адміністратор віртуальної організації проінформує вас про успішну реєстрацію у віртуальній організації. 3.6 Порядок виконання роботи Для доступу до ресурсів навчальної грід-системи студент повинен: 1. бути легальним користувачем обчислювальних ресурсів (мати облікову запис); 2. мати персональний цифровий сертифікат, підписаний навчальним центром сертифікації; 3. бути зареєстрованим в навчальній віртуальній організації. Доступ до обчислювальних ресурсів студент отримав при виконанні першої лабораторної роботи. Далі будуть наведені кроки, яки необхідно виконати для отримання сертифікату і реєстрації в віртуальної організації. Отримання сертифіката користувача Для отримання сертифікату необхідно виконати наступні кроки: 109 1) Завітати на сайт Центру сертифікації та зареєструватися там для отримання скрипта, який згенерує закритий ключ та запит на сертифікат публічного ключа. Навчальний Центр сертифікації KPIEDU CA знаходиться за адресою http://bdii-edu.hpcc.kpi.ua/ca/ та має спрощений інтерфейс порівняно з офіційним центром сертифікації UGRID CA (https://ca.ugrid.org/cert.php). Студенту необхідно ввести ім‘ям та прізвище в поле Common Name. Рис.3.6 - Крок 1 отримання сертифікату користувача 2) Завантажити скрипт та виконати його на комп‘ютері зі встановленим openssl (зазвичай будь-яка UNIX-система). Для виконання отриманого крипта рекомендується використати інтерфейсний вузол кластера, попередньо скопіювавши туди отриманий скрипт в домашню директорію студента. Після копіювання файлу скрипта слід змінити права доступу для забезпечення виконання скрипта від імені користувача за командою: chmod u+x generate_request.sh 110 Під час генерації ключа буде запитано пароль, яким буде зашифровано ключ. Пароль повинен бути досить складним для забезпечення надійного зберігання ключа. lobzik@ubuntu:~/Downloads$ ./generate_request.sh -----------------------------------------------------------------------Creating the cryptographic keypair for your certificate. The file named /home/lobzik/.globus/userkey.pem will contain your private key. This file must not be shared with anyone and must be kept in a safe place. Never transfer your private key using plain communication channels (email, telnet sessions, ftp and so on). Choose strong password for your private key. Remember, CP/CPS states that the password should be at least 15 characters long. If you will forget your password no one will help you: your certificate will become useless. NEVER USE EMPTY PASSWORD! NEWER STORE YOUR PASSWORD ALONG WITH THE PRIVATE KEY! -----------------------------------------------------------------------------Press [Enter]... Generating a 2048 bit RSA private key ............+++ .........................................................................+++ writing new private key to '/home/lobzik/.globus/userkey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: -----------------------------------------------------------------------111 All done. Your private key is stored in the file /home/lobzik/.globus/userkey.pem -----------------------------------------------------------------------rm -f "$CONF" "$REQ" >/dev/null 2>&1 Press [Enter]... Після виконання цієї команди в домашньому каталозі користувача створюється новий підкаталог .globus c трьома файлами: - usercert_request.pem запит - на отримання цифрового сертифікату; - usercert.pem – файл, куди необхідно скопіювати отриманий цифровий сертифікат користувача (частина з відкритим ключем); - userkey.pem - приватний ключ сертифікату користувача. Примітка. Процедура генерації учбових сертифікатів формує файли в вигляді userteq.20100419-145354.mail, usercert.20100419- 145354.pem, userkey.20100419-145354.pem тобто додає к імені файлу дату генерації та номер запиту. Запит на отримання сертифікату слід направити відповідальному за сертифікацію в Український Тестовий Центр сертифікації. Примітка. Після виконання процедури генерації запиту на сертифікат файл usercert.pem зазвичай містить наступні рядки інструкції для перевірки отриманих рекомендується виконати вказані сертифікату користувача. 112 сертифікатів. інструкції після Студенту отримання The issued certificate should be placed here. The corresponding key file is /home/svistunov/.globus/userkey.20100419-145354.pem You can always check if your certificate and your private key do correspond to each other by issuing two commands /opt/globus/bin/openssl rsa -in /home/svistunov/.globus/userkey.20100419145354.pem -noout -modulus /opt/globus/bin/openssl x509 -in <your-certificate> -noout -modulus and check that their outputs are the same. 3) Згенерований запит на сертифікат (файл userreq.pem) слід відправити до Центру сертифікації http://bdii-edu.hpcc.kpi.ua/ca/ Рис.3.7 - Крок 3 процедури отримання сертифікату користувача Закритий ключ не потрібно відправляти в навчальний центр сертифікації, а необхідно зберігати в захищеному місці. 4) Отримати сертифікат. У навчальному Центрі сертифікації обробка запитів відбувається автоматично, тому можна одразу після надсилання запиту отримати сертифікат за вказаним посиланням. Рис.3.8 - Крок 4 процедури отримання сертифікату користувача 113 Примітка. відкриється Після вікно натискання браузера з на вказаний сертифікатом. лінк (адресу) Рекомендується скопіювати вміст в текстовий файл (.txt) а потім скопіювати його в директорію .globus на кластері. Зберігши отриманий сертифікат в файлі usercert.pem, маємо пару файлів: приватний ключ (userkey.pem) та сертифікат (usercert.pem), який засвідчує належність публічного (відкритого) ключа певній особі. Незважаючи на те, що закритий ключ додатково захищений паролем, про всі випадки втрати чи можливого несанкціонованого доступу до закритого ключа необхідно негайно повідомляти в навчальний центр сертифікації. Реєстрації у віртуальній організації Процедура реєстрації у навчальній віртуальної організації виконується за допомогою звичайного браузера через мережу Інтернет. Щоб використовувати браузер для взаємодії з сервісами грід, необхідно надати йому свої приватний ключ та сертифікат. Це зручно зробити, об‘єднавши ключ та сертифікат в один файл формату PKCS12, наприклад, такою командою: openssl pkcs12 -export -inkey userkey.pem -in usercert.pem –out cert.p12 -name "My certificate" Примітка. Цю команду слід виконувати з директорії .globus на кластері. Отриманий у результаті файл cert.p12 слід скопіювати на комп‘ютер з інтернет-браузером та імпортувати сертифікат у браузер. 114 Процедура імпорту (послідовність кнопок меню) дещо відрізняється для різних браузерів. Нижче наведені послідовності дії по імпорту сертифікату *.p12 до різних популярних браузерів: Firefox (версія 3.6.x, українізована) 1. У меню «Інструменти» вибрати пункт «Налаштування». 2. Вибрати вкладку «Додатково», на ній вкладку «Шифрування» и натиснути кнопку «Перегляд Сертифікатів». Відкриється вікно. 3. Вибрати вкладку «Ваші сертифікати і натиснути кнопку «Імпорт». 4. Вказати шлях до файлу з сертифікатом (*.p12). Internet Explorer (версія 6.x та вище, русифікована) 1. Меню «Сервис ->«Свойства обозревателя». 2. Вибрати вкладку «Содержание» и натиснути в групі «Сертификаты». кнопку «Сертификаты». Відкриється вікно. 3. Вибрати вкладку «Личные» и натиснути кнопку «Импорт». Запуститься «Мастер импорта сертификатов». Виконуючи інструкції, виберіть файл з сертифікатом (*.p12). Крім того, необхідно вибрати опцію «Включить усиленную защиту закрытого ключа», щоб браузер не зберігав введений пароль. Opera (версія 11.x, русифікована) 1. У «Меню вибрати пункт «Настройки -> Общие настройки». 2. Перейти на вкладку «Расширенные» та вибрати у списку пункт «Безопасность». 3. Натиснути кнопку «Управление сертификатами». Відкриється вікно. 4. Вибрати вкладку «Личные» и натиснути кнопку «Импорт». 5. Вказати шлях до файлу з сертифікатом (*.p12). 115 Для виконання лабораторних робіт створена навчальна віртуальна організація kpiedu. Для реєстрації в навчальній віртуальній організації необхідно у браузері зі встановленим *.p12 сертифікатом відкрити сторінку реєстрації на VOMS-сервері за адресою https://vomsedu.hpcc.kpi.ua:8443/voms/kpiedu. У вікні реєстрації (рис.3.9) необхідно: - в полі «Your email address» вказати адресу електронної почти студента для отримання повідомлень, - в полі «Your institute» вказати групу, в який навчається студент, - в полі «Comments for the VO admin» вказати фамілію та ім‘я студента. Рис.3.9 - Інтерфейсне вікно реєстрації у віртуальній організації Після заповнення та відправки реєстраційної форми на вказану в запиті електрону адресу буде надіслано лист підтвердження реєстрації. Студенту необхідно виконати всі інструкції, вказані в цьому листі. Якщо все виконано вірно згодом на вказану в запиті електрону адресу 116 буде надіслано лист від адміністратора віртуальної організації про підтвердження реєстрації. Після завершення процесу реєстрації в списку користувачів з‘явиться новий рядок: Рис.3.10 - Інтерфейсне вікно членів віртуальної організації Тепер можна починати роботу в навчальній грід-системі. Генерація проксі-сертифікату Доступ до грід-системи повинен надавати користувачу можливість повноцінно працювати з грід-системою, тобто запускати нові завдання, керувати вже запущеними та отримувати результати роботи завдань, 117 яки завершилися. Найбільш стандартним є інтерфейс командного рядка (Command Line Interface – CLI), який дозволяє виконувати всі операції управління завданнями і даними, а також виконувати адміністративні дії. При виконанні більшості лабораторних робіт з даного курсу використовується саме цей спосіб доступу до навчальної грідсистеми. Користувач має доступ до грід-системи з будь-якого комп'ютера, який підключений до локальної мережі інституту або мережі Інтернет через, так званий, користувацький інтерфейс (User Interface - UI). Віддалений доступ до комп'ютера з UI інтерфейсом виконується за допомогою SSH. Параметри SSH – з‘єднання (актуальна інформація уточнюється у викладача): - з мережі Інтернет: сервер зі встановленим користувацький інтерфейсом: ui.hpcc.kpi.ua (77.47.192.56 порт 22). Логін і пароль співпадає з тим, що був виданий студенту для доступу на учбовий обчислювальний кластер; - з комп'ютерної встановленим мережі користувацький інституту доступ інтерфейсом на сервер виконується зі через інтерфейсний вузол кластера. Параметри SSH - з‘єднання з інтерфейсним вузлом кластера : - з локальної мережі інституту адреса: 10.6.12.252 порт 222; - з мережі Інтернет: адреса cn.hpcc.ntu - kpi.kiev.ua (77.47.192.51) порт: 2222. Після цього виконується SSH – з‘єднання ui.hpcc.kpi.ua (77.47.192.56 порт 22). 118 до серверу [svistunov@n03 ~]$ ssh svistunov@ui.hpcc.kpi.ua Scientific Linux CERN SLC release 4.5 (Beryllium) [svistunov@ui ~]$ Команди, які створюють проксі-сертифікати (grid-proxy-init та voms-proxy-init) за замовчуванням, шукають файли із закритим ключем та сертифікатом користувача у папці .globus домашнього каталогу користувача. У параметрах цих функцій можна задати й інше розміщення цих файлів. Також функції вимагають, щоб на файли були встановлені відповідні права доступу. Їх можна задати, наприклад, таким чином: chmod 644 ~/.globus/usercert.pem chmod 400 ~/.globus/userkey.pem Для генерації проксі - сертифікату використовується команда gridproxy-init (у відповідному рядку необхідно ввести пароль). Протокол виконання команди має вигляд, подібний наступному: [svistunov@ui task3-pbs]$ grid-proxy-init Your identity: /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov Enter GRID pass phrase for this identity: Creating proxy ..................................... Done Your proxy is valid until: Fri Dec 17 03:28:16 2010 Примітка. Проксі - сертифікат отриманий по цій команді буде використовуватися для виконання завдань в грід системі під керуванням проміжного програмного забезпечення ARC. 119 За замовченням доручення дійсне на протязі 12 годин. Доручення з іншим строком дії може бути створена за допомогою параметра – hours. Необхідно враховувати, що чим більше термін дії доручення, тим більша ймовірність, що використовувані вами ресурси будуть атаковані хакерами. Якщо сертифікат був установлений невірно, то видається повідомлення про помилку ―user certificate not found‖, а у випадку помилки в паспортному слові – повідомлення ―wrong pass phrase‖. Для отримання інформації про видане доручення, використовуйте команду grid-proxy-info з параметром –all, яка відображає повну інформацію про доручення: [svistunov@ui task3-pbs]$ grid-proxy-info -all subject : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov/CN=485375392 issuer : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov identity : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov type : RFC 3820 compliant impersonation proxy strength : 512 bits path : /tmp/x509up_u6000 timeleft : 11:59:52 Для генерації проксі–сертифікату з посилання на віртуальну організацію використовується команда voms-proxy-init (у відповідному рядку необхідно ввести пароль). Протокол виконання команди має вигляд, подібний наступному: [svistunov@ui task3-pbs]$ voms-proxy-init -voms kpiedu Enter GRID pass phrase: Your identity: /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov Creating temporary proxy ....................... Done 120 Contacting voms-edu.hpcc.kpi.ua:15002 [/DC=org/DC=ugrid/O=hosts/O=UGRID/OU=HPCC/CN=voms-edu.hpcc.kpi.ua] "kpiedu" Done Creating proxy ............................................................... Done Your proxy is valid until Thu Dec 2 00:52:19 2010 Для отримання інформації про видане доручення використовується команда voms-proxy-info з параметром –all, яка виводить повну інформацію про доручення: [svistunov@ui task3-pbs]$ voms-proxy-info -all subject : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov/CN=proxy issuer : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov identity : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov type : proxy strength : 1024 bits path : /tmp/x509up_u6000 timeleft : 11:59:44 === VO kpiedu extension information === VO : kpiedu subject : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov issuer : /DC=org/DC=ugrid/O=hosts/O=UGRID/OU=HPCC/CN=voms-edu.hpcc.kpi.ua attribute : /kpiedu/Role=NULL/Capability=NULL timeleft : 11:59:43 uri : voms-edu.hpcc.kpi.ua:15002 Примітка. Слід відмітити що в даному випадку в проксісертифікаті зберігається інформація і про віртуальну організацію до якої належить користувач. 121 Для знищення доручення до закінчення її терміну дії можна використати команду grid-proxy-destroy. Проте ця команда знищує лише локальну копію доручення, не чіпаючи копії, які використовувались при виконанні вашого завдання на віддалених ресурсах та іншими службами грід. Окремі елементи інформації можуть бути отримані за допомогою відповідних значень параметрів команди. Більш детальну інформацію про всі ці команди можна отримати, якщо їх виконувати з параметром -help. 3.7 Завдання до лабораторної роботи Дана лабораторна робота є підготовчим етапом для лабораторних робіт з використання ресурсів навчальної грід системи. Вона складається з наступних кроків:  отримання навчального сертифікату користувача;  реєстрація в навчальної віртуальної організації;  генерації проксі-сертифікату за допомого команд grid-proxy-init, voms-proxy-init;  перевірки згенерованого проксі-сертифікату за допомого команд grid-proxy-info, voms-proxy-info. За результатами роботи студент складає протокол, який повинен містить скріншоти виконаних команд генерації та перевірки проксі– сертифікату. 3.8 Контрольні питання 1. Сучасна модель безпеки в грід. Складові частини цієї моделі. 122 2. Цифровий підпис. Поясніть на прикладі принцип його використання. 3. Ідентифікація користувачів і грід вузлів. 4. Формат сертифікатів відкритих ключів X.509. 5. Сертифікаційний центр. Основні функції і його місце в забезпеченні безпеки грід. 6. Як працюють сертифікати при ідентифікації користувача сервером грід? 7. Алгоритм отримання сертифікату користувача. 8. Делегування прав і використання доручення. 9. Як працює сервіс VOMS (Virtual Organization Membership Service – Сервіс управління членством у віртуальних організаціях)? 10. Сервіс управління віртуальними організаціями і авторизація користувачів грід. Література 1. EGEE Middleware Architecture, DJRA1.1, https://edms.cern.ch/document/476451/1.0. 2. Global Security Architecture, DJRA1.3, https://edms.cern.ch/document/487004/1.1. 3. VOMS User‘s Guide, EGEE-JRA1-TEC-571991, https://edms.cern.ch/file/571991/1/voms-guide.pdf. 4. Introduction to Grid Computing, December 2005, -IBM Redbook, www.ibm.com/redbooks - 241 c. 5. Grid Computing in Research and Education, April 2005, - IBM Redbook, www.ibm.com/redbooks - 145 c. 123 Завдання № 4. Проміжне програмне забезпечення грід - ARC Мета: вивчення технології віддаленого доступу до грід-ресурсів, які працюють під управлінням проміжного програмного забезпечення ARC, та набуття практичних навичок виконання завдань на грідресурсах. 4 Короткі теоретичні відомості Проект NorduGrid, відомий також як «Nordic Testbed for Wide Area Computing», почався в 2001 році ( http://www.nordugrid.org/). Основна мета проекту полягала в побудові грід-інфраструктури в скандинавських країнах (Данія, Норвегія, Швеція та Фінляндія), яка могла б використовуватися вченими для виконання складних завдань з обробки даних і таким чином оцінити, як ця нова технологія може інтенсифікувати наукові обчислення. Перша тестова експлуатація грідінфраструктури проекту NorduGrid була проведена в травні 2002 року при розв‘язанні задач симуляції даних для експерименту ATLAS. Результати дослідної експлуатації були успішними і довели, що розроблена грід-система вирішила поставлені перед нею завдання. Архітектура NorduGrid проектувалася, виходячи з положення, що вона повинна бути одночасно максимально зручною як для користувачів системи, так і для системних адміністраторів. Основні положення, які були покладені в основу розробки проміжного програмного забезпечення (middleware) NorduGrid, можна сформулювати так:  почати розробку з простих рішень, які працюють і будуть працювати надалі;  уникати архітектурних рішень, при яких є сервіси, відмова в роботі яких може привести до відмови всієї системи в цілому; 124  система має бути масштабованою, тобто збільшення розміру грід- інфраструктури не повинно призводити до внесення змін у проміжне програмне забезпечення;  власники обчислювального ресурсу, який передається в грід, повинні зберігати повний контроль над цим ресурсом, тобто операційна система, локальна система управління завданнями, локальна політика адміністрування користувачів не повинні мінятися при підключенні ресурсу до грід-інфраструктури;  ніяких специфічних вимог до конфігурації обчислювального кластера і до інсталяції проміжного програмного забезпечення за можливістю не повинно бути;  проміжне програмне забезпечення за можливістю не повинно бути залежним від операційної системи на обчислювальному кластері;  проміжне програмне забезпечення повинне встановлюватись тільки на одному сервері, що виконує роль вхідного вузла (front-end) грід-сайту;  обчислювальні вузли кластера можуть мати внутрішні адреси і не обов'язково забезпечувати доступ до них із загальнодоступної мережі Інтернет;  обчислювальний кластер повинний бути доступний і для виконання завдань локальних користувачів, тобто завдання, що приходять із грід-інфраструктури, ні чим не відрізняються від локальних завдань. Розробникам проекту NorduGrid вдалося виконати більшість перерахованих вище вимог, і було створено програмне забезпечення проміжного рівня ARC (Advanced Resource Connector), що й дотепер є одним із трьох промислових middleware у Європі. 125 4.1 Архітектура та основні компоненти ARC Основні архітектурні рішення ARC відповідають загальноприйнятим підходам побудови грід. В грід-інфраструктурі проекту NorduGrid використовується організація ресурсів, аналогічна реалізованої в проекті EU DataGrid. ARC забезпечує наступні функції:  Інформаційні (збір і надання інформації про ресурси грідсистеми);  Динамічне включення ресурсів до грід-системи та їх моніторинг;  Відправлення завдань на виконання в грід - систему і керування завданнями;  Розподіл завдань за ресурсами;  Керування даними і ресурсами. Всі функції реалізовані у вигляді сервісів (служб), які опираються на відомі програмні засоби з відкритим кодом: OpenLDAP (Lightweight Directory Access Protocol), OpenSSL (Open Secure Socket Layer) і SASL (Simple Authentication Security Layer). Реалізація виконана за допомогою бібліотек Globus Toolkit 2 (GT2), безпека досягається шляхом використання протоколів та інфраструктурних рішень GSI (Grid Security Infrastructure), заснованих на надійній та широко використовуваній інфраструктурі криптографії з відкритим ключем (Public Key Infrastructure - PKI). Програмне забезпечення проміжного рівня ARC спирається на протоколи Globus і реалізовано за допомогою API Globus Toolkit та являє собою надбудову над інструментами Globus. ARC не використовує наступні інструменти зі складу Globus: GRAM (Globus Resource Allocation Manager) компоненти, відповідальні за створення / видалення процесів; утиліти управління завданнями; Gatekeeper та 126 скрипти Job-manager, сервер Gridftp, схеми та інформаційні постачальники MDS (Monitoring and Discovery Service). Натомість в ARC запропоновано власний набір сервісів:  Grid Manager (сервіс керування завданнями користувачів);  gridftp (сервіс передачі файлів - ARC/NorduGrid GridFTP server);  User Interface (інтерфейс користувача);  Broker (планувальник завдань);  система моніторингу. Крім цього запропонована нова інформаційна схема, для якої розроблені постачальники даних, розширена мова опису ресурсів (xRSL) . Таким чином, хоча ARC і побудований на бібліотеках Globut Toolkit, він являє собою нове проміжне програмне забезпечення. На рис.4.1 представлені основні компоненти ARC і схематично показана взаємодія між ними. Нижче наданий короткий опис цих компонентів. Інтерфейс користувача(User Interface) При розробці ARC ставилась мета створення програмного забезпечення виробничої якості, використовуючи як основний принцип максимально повну децентралізацію, тому на кожному робочому місці користувача грід-мережі встановлюється персональний брокер, функція якого полагає в підборі найбільш придатного ресурсу для виконання завдання користувача. Цей підхід відрізняє ARC від централізованої схеми EU DataGrid, з єдиним брокером на всі робочі місця. 127 Рис.4.1 - Основні компоненти ARC Інтерфейс користувача, який має назву Intelligent Brokering Client, є ключовим сервісом, що був розроблений у рамках проекту NorduGrid користувачів і призначений до для грід-системи забезпечення з наступним допуску керуванням завдань цими завданнями. В одній програмної оболонці (рис.4.2) реалізовані функції пошуку ресурсів, призначення ресурсів завданню, відправки завдання на виконання та повного контролю за виконанням завдання на обчислювальному ресурсі. Рис.4.2 - Структура інтерфейсу користувача ARC 128 З точки зору користувача Intelligent Brokering Client являє собою набір команд для запуску, моніторингу і управління завданнями, копіювання файлів та запитів про стан ресурсів. Інформаційна система (Information System) Інформаційна система ARC є розподіленою динамічною системою, яка надає інформацію про стан ресурсів грід-середовища і використає для роботи MDS (Monitoring and Discovery Service), інформаційну систему Globus. Стандартний пакет MDS є відкритим інструментарієм для створення інформаційної системи для грід і побудований на базі програмного забезпечення OpenLDAP. MDS 2 базується на двох ключових протоколах: Grid Information Protocol (GRIP) і Grid Registration Protocol (GRRP). Перший надає можливість створення запитів, відповідей на них та виконання операцій пошуку. Другий забезпечує реєстрацію компонентів монітору. Вся інформація об'єднується в ієрархічну структуру – дерево інформації каталогів (Directory Information Tree, DIT). Інформація, яка збирається інформаційною системою, може бути найрізноманітнішою і містити, наприклад, дані про конфігурацію або стан як всієї системи, так і окремих її ресурсів (тип ресурсу, доступний дисковий простір, кількість процесорів, обсяг пам'яті, продуктивність та інше). Вся інформація логічно організована у вигляді дерева, і доступ до неї здійснюється за стандартним протоколом LDAP – псевдорозподіленої бази даних. Ієрархічна структура MDS представлена на рис. 4.3. 129 Рис. 4.3 - Ієрархічна структура MDS Інформаційна система ARC складається із трьох основних компонентів: 1. IP (Information Provider), що є джерелом інформації про конкретний ресурс або частину ресурсу; 2. GRIS (Grid Resource Information Service), шо надає інформацію про вузол грід-системи, що може бути як обчислювальним вузлом, так і яким-небудь іншим ресурсом. GRIS опитує індивідуальні IP і поєднує отриману від їх інформацію в рамках єдиної інформаційної схеми; 3. GIIS (Grid Index Information Service), що поєднує інформацію з різних GRIS або інших GIIS. GIIS верхнього рівня містить всю інформація про стан даної грід-системи. Інформація про стан ресурсів грід-системи генерується динамічно постачальниками інформації на ресурсах за запитом користувача або агента (pull-модель). Постачальниками інформації є спеціальні програми, які слугують інтерфейсом ресурсів грід-системи та збирають про них інформацію. 130 У складі ARC розроблений свій набір постачальників інформації для заповнення записів власної схеми. Далі інформація, що отримана від постачальників, може кешуватися на різних рівнях розподіленої бази даних. У складі системи реалізовані наступні елементи: локальні постачальники інформації, локальні бази даних (кеш першого рівня), індекси інформації (також з механізмом кешування, але вищих рівнів), механізм м'якої реєстрації, а також інформаційна модель (схема) для представлення грід-ресурсів. Інтерфейс користувача із вбудованим брокером та система моніторингу є головними споживачами динамічної інформації, яка отримується і зберігається в інформаційній системі. Локальні бази даних з‘єднуються разом через індекси інформації GIIS. Використання динамічної реєстрації дає можливість будувати різні топології індексованих ресурсів. В Українському національному грід, сервіс GIIS (lcg.bitp.kiev.ua) розміщено в Інституті теоретичної фізики ім. Н.Н.Боголюбова НАН України. Дублюючий сервер розміщений у Київському Державному Університеті Тараса Шевченко. Ці сервери використовуються для управління, збору і зберігання інформації про обчислювальні ресурси, які зареєстровані в української грід-мережі (поєднує інформацію з GRIS, встановлених на обчислювальних кластерах). Додатково на виділеному сервері (lcg.bitp.kiev.ua) в ІТФ встановлено сервіс Grid Monitor – систему моніторингу грідінфраструктури, що періодично опитує розподілену інформаційну систему та представляє результати у вигляді взаємозалежних Webсторінок. В ARC розроблена своя інформаційна модель, яка відображає обчислювальні ресурси користувачів і черги у вигляді LDAP-дерева, де 131 кожному ресурсу відповідає під-дерево. Інформаційна модель складається з трьох основних компонентів: - локальні інформаційні дерева, які відповідають за опис і характеристику ресурсів (обчислювальних і ресурсів зберігання даних). Генеруються на ресурсі та опціонально кешуються. Надаються клієнтові за запитами через інтерфейс LDAP; - служби індексування, що підтримують динамічні списки ресурсів (посилання на локальні інформаційні дерева); - процеси реєстрації, які працюють на локальних ресурсах і реєструють локальні дерева в службах індексації. Реєстрація завжди ініціюється реєстрантом. Рис.4.4 - Загальна архітектура NorduGrid ARC IS 132 На рис. 4.4 зображена загальна архітектура NorduGrid ARC IS. Інформаційна система ARC дозволяє робити два типи запитів: - запит служб індексації для вибору відповідних локальних інформаційних дерев; - прямий запит інформаційного дерева за його адресою. Локальне інформаційне дерево збирає динамічну інформацію, реалізує кешування першого рівня для локальної інформації й надає запитану інформацію клієнтам, використовуючи протокол LDAP. Локальне інформаційне дерево по суті є модифікованою OpenLDAP базою даних. Інформацію на ресурсі збирають програми-постачальники. Вони отримують дані від системи пакетної обробки завдань, від локального грід-сервісу (Grid Manager або GridFTP сервер) або від локальної операційної системи (для Linux систем це інформація з каталогу /proc). Зібрану інформацію аналізує служба GRIS. Інформація кешується і, якщо вона відсутня в кеші, знову запитуються постачальники. Кешування оберігає вузли від зайвого навантаження через багаторазове звернення до постачальників. Для створення загальної інформаційної структури локальні дерева об'єднуються в загальну систему. Для цього використовуються процеси реєстрації та служби індексування. Індексні служби збирають тільки контактну інформацію ресурсів, дані з самих дерев ці служби не використовують. Процеси реєстрації слугують для зв'язку між індексними службами і локальними деревами. Служби індексування є спеціалізованою LDAР базою даних. Клієнт, який шукає відповідні ресурси, проходить по дереву від найвищого рівня до LDAР елементів обчислювальних вузлів або ресурсів зберігання даних. Коли клієнт отримав адресу конкретного 133 ресурсу, він робить прямий запит і підключається за протоколом LDAP до локального інформаційного дерева цього ресурсу. Постачальниками в даному моніторі виступають спеціальні програми, яки отримують дані від системи пакетної обробки завдань, від локального грід-сервісу або від локальної операційної системи. Перетворювачами слугують служби індексування. Кластери описані об'єктним класом LDAP nordugrid-cluster, що містить набір атрибутів для опису властивостей обладнання, програмного забезпечення і системного програмного забезпечення кластера. Інформаційна модель розрізняє і підтримує кластери та черги як виділені цілком для грід, так і змішаного використання. Кластер надає доступ до черг, виділеним для завдань із грідмережі, які описуються класом nordugrid-queue. Дерево містить піддерева nordugrid-authuser і nordugrid-job (поділ виконується класом nordugrid-info-group). Кожен грід-користувач, який авторизований для запуску завдань у чергу, повинен мати свій запис у черзі. Аналогічно кожне грід-завдання, запущене в чергу, відображається відповідним записом. Запис nordugrid-authuser містить всю інформацію, яка ставитися у відповідність до авторизованого грід-користувача, навіть таку, як кількість процесорів, виділених для цього користувача в даній черзі, обсяг доступної дискового простору, і т.д. В ARC зроблений акцент на інформацію, що стосується користувача, тому що така інформація для нього більш важлива, ніж загальна інформація про ресурси кластера. Записи nordugrid-job описують завдання, запущені на виконання на кластері. І включають унікальний ідентифікатор в грід-мережі, заголовок сертифіката власника 134 завдання, статус завдання, обчислювальний вузол, на якому виконується завдання, і т.д. Записи про завдання зберігаються на кластері, на якому завдання виконуються. Крім вищевказаних схема включає класи nordugrid-se й nordugridrc для опису сховищ даних і каталогів реплік відповідно. При розробці ARC було ухвалене рішення про блокування функції кешувания в GIIS. У підсумку користувачі або агенти одержують результати запитів прямо від ресурсів, а GIIS виконує тільки функції індексації. Обчислювальні кластери (Computing Cluster) Ресурси під керуванням програмного забезпечення ARC формуються з окремих обчислювальних кластерів. Кластер містить вхідний (Head Node) вузол, що керує через внутрішню закриту мережу деякою кількістю робочих вузлів. Програмне забезпечення містить у собі стандартну систему пакетної обробки і додаткові компоненти для взаємодії з грід- мережею. Важливою властивістю архітектури ARC є той факт, що для робочих вузлів кластера не потрібен прямий вихід в Інтернет. Цей принцип відповідає тій вимозі, що ARC реалізовано як додатковий компонент, який впроваджує локальні ресурси в грід-мережу і дозволяє завданням, які надійшли на кластер з грід-мережі, працювати поряд з локальними завданнями. Тому на вхідному вузлі кожного кластера, підключеного до мережі Інтернет, встановлені сервіси (рис.4.5):  Grid Manager (Грід-менеджер) - сервіс керування завданнями користувачів. Grid Manager дозволяє користувачеві відправляти завдання до грід-мережі та одержувати результати розрахунків,  GridFTP Server – сервіс, що забезпечує доступ до локальної файлової системи. GridFTP Server надає FTP-подібний доступ до 135 локальних файлів і забезпечує інтерфейс для контролю над завданням. Крім того, GridFTP підтримує віртуальне дерево каталогів, що надає кожному користувачеві можливість контролю доступу, який базується на імені в сертифікаті користувача,  Downloader and Uploader - сервіси передачі пакетних завдань і передачі результатів розрахунків на комп'ютер користувача.  GRIS - надає інформацію про обчислювальний вузол грід- системи. Рис.4.5 - Загальна архітектура обчислювального елементу NorduGrid ARC Сервіс грід-менеджер використовується для запуску завдань на грід-системі та окрім управління завданнями відповідає за переміщення вхідних і вихідних даних з підтримкою використання каталогів метаданих. Дані обробляються тільки до і після завершення завдань. Передбачається, що користувач вказує повну інформацію про вхідні дані, необхідні для виконання завдання, і про вихідні дані, які є результатами виконання завдання. Це найістотніше обмеження даного підходу. 136 Грід-менеджер був спеціально розроблений для ARC. Він базується на бібліотеках і сервісах Globus Toolkit та використовує наступні елементи Globus:  GridFTP – сервіс, що забезпечує швидкий і надійний доступ до даних у грід із вбудованим механізмом підтримки безпеки;  GASS – сервіс віддаленого доступу до зовнішньої пам'яті по протоколах http та https;  Каталог реплік – сховище метаданих;  Сервіс розміщення реплік – створений в проектах Globus та EDG;  Мова специфікації ресурсів RSL (resource specification language). В ARC використовується xRSL (extendable resource specification language – розширена мова специфікації ресурсів). Grid Manager складається з декількох окремих модулів, таких як: • grid-manager - основний модуль. Він відповідає за виконання завдання, зміну і контроль станів завдання та запуск інших модулів. • downloader - цей модуль відповідає за переміщення вхідних даних на обчислювальний ресурс і їх запис до спеціальної директорії. • uploader - цей модуль відповідає за переміщення результуючих (output files) файлів на певний ресурс зберігання та реєстрацію в індексному сервісі. • frontend-info-collector – утиліта, яка збирає інформацію про діалог із вхідного вузла та зберігає її в спеціальному діалоговому файл. • gm-kick - спеціальна утиліта, відповідальна за «живучість» грід- менеджера. Вона посилає запити GM і обробляє відгук. Грід-менеджер реалізує децентралізовану модель доступу до грідресурсів , яка означає відсутність центрального сервера, через який повинні проходити всі завдання в грід-мережі. 137 Грід-менеджер має наступну функціональність:  Однаковий інтерфейс для запуску завдань і переміщення даних з комп‘ютера користувача (використається GridFTP);  Підтримку GridFTP, FTP, HTTP, HTTPS серверів для переміщення даних з можливістю пошуку і реєстрації інформації в каталогах метаданих;  Відмовостійка передача даних;  Кешування завантажених даних;  Повідомлення через e-mail про статус завдання з можливістю надання користувачеві інформації про обробку завдання (log file);  Встановлення конфігурація середовища оточення для програмних пакетів;  Маніпулювання сесійними директоріями (створення, очищення, і т.д.). В якості ідентифікаторів користувачів та ресурсів в ARC використаються цифрові сертифікати X.509. Авторизація (надання користувачеві прав на доступ до ресурсу) виконується відповідно до результатів аутентифікаціі та локальної політики авторизації, прийнятої для даного ресурсу. Системні адміністратори кластерів зберігають повний контроль за вибором тих грід-користувачів, кому надається доступ до ресурсу. Локальний процес авторизації виконується шляхом встановлення у файлі (grid-mapfile) на ресурсі відповідності між прийнятою множиною користувачів грід та локальними обліковими записами. 4.2 Система керування завданнями Для використання ресурсів грід-мережі на комп'ютерах користувачів встановлюється спеціальне програмне забезпечення (User 138 Interface - UI), яке забезпечує взаємодію з грід-середовищем (зокрема, дозволяє запускати завдання і одержувати результати). Користувач взаємодіє з ARC за допомогою утиліт командного рядка. ARC надає команди для відправлення завдань до грід-мережі, запиту стану завдань і кластерів, одержання даних від завершених завдань, переривання завдань, і т.д. Також існують засоби для копіювання і видалення файлів у сховищах даних та каталогах реплік: 1. Програмний код завдання виконується на обчислювальному ресурсі без участі користувача (у пакетному режимі). Сам код зазвичай не вимагає адаптації до умов грід. У деяких випадках може знадобитися його доповнення прологом/епілогом, які виконують підготовчі/завершальні операції, наприклад, доставку оброблюваних даних. 2. Завдання надається планувальникові завдання у вигляді формалізованого опису, складеного мовою опису ресурсів (xRSL). Способи опису завдань докладно обговорюються далі. 3. Грід-ресурси використовуються колективно безліччю користувачів, тому завдання не обов'язково починає виконуватися відразу після запуску: воно може чекати звільнення ресурсів, зайнятих іншими завданнями. Завдання, які очікують на ресурси, зберігаються в чергах ресурсних центрів CE. 4. Питання безпеки в ARC вирішуються на основі принципів GSI. Перед тим, як почати працювати з ARC-UI, користувач має згенерувати тимчасовий проксі-сертифікат за допомогою команд grid-proxy-init або voms-proxy-init. 139 Типовий сеанс роботи користувача в грід-інфраструктурі показаний на рис.4.6. 1. Отримати доступ до клієнтського інтерфейсу ППЗГ Вхід Так Є дійсний сертифікат? 2.б. Згенерувати проксі-сертифікат 3. Сформувати файл опису задачі Р о б о т а Ні 2.а. Отримати сертифікат у центрі сертифікації Типовий сеанс роботи в Грід 4. Запустити задачу на виконання у 5. Перевірити статус задачі г р і д Завершено ? Так Ні 6. Вивантажити результати Так 7. Знищити проксісертифікат Ні Закінчити сеанс? Вихід Рис.4.6 - Типовий сеанс користувача в грід-системі З точки зору грід-менеджера, завдання переходить зі стану в стан в процесі свого життєвого циклу (якщо про такий цикл можна говорити стосовно до завдання). На рис.4.7 показані стани завдання. Користувач має можливість відслідковувати стан завдання командами запиту з UI до NorduGrid Information System (IS). 140 Рис. 4.7 - Стани завдання в ARC Розглянемо детально кожен стан, у якому може перебувати завдання: • Accepted – У цьому стані завдання передане на обраний обчислювальний елемент, але не виконується. Грід-менеджер аналізує опис завдання і, якщо не знайдено синтаксичних помилок, передає його на наступний крок. Якщо в описі завдання знайдена помилка, то завдання знімається з обробки і переходять у стан Finishing. 141 • Preparing - Процес збору вхідних файлів, виконання завдання і передача файлів результату називається сесією (session). Кожне завдання має свій ідентифікатор (jobid), що визначає його в GM і в NorduGrid Information System. Кожному завданню виділяється тимчасова директорія на обчислювальному елементі, яка називається сесійною директорією (SD). Вхідні файли (опис завдання, файли програми і файли даних) копіюються в сесійну директорію. Передача файлів виконується за GridFTP протоколом. У стані preparing всі файли збираються в SD. Грід-менеджер завантажує файли, зазначені в описі завдання, і чекає закінчення завантаження файлів з інтерфейсу користувача. Якщо всі файли успішно завантажені, то завдання переходить в наступний стан. Якщо хоча б один файл не можливо завантажити (відсутній) або при передачі відбулася помилка чи відповідь від інтерфейсу користувача затягується за часом (помилки в мережі), то завдання переходить у стан Finishing (якщо помилка випадкова, то в цьому випадку завдання повертається в стан Accepted і чекає повторної спроби запуску). В грід-менеджері можна встановити обмеження на кількість завдань у стані Preparing. • Submitting – У цьому стані відбувається взаємодія з локальною системою управління кластером Local Resource Management System (LRMS), яка відповідає за розподіл завдань за обчислювальними вузлами. В ARC підтримуються основні системи розподілу завдань PBS, SGE, Condor. У цьому стані завдання передається на виконання. Якщо передача завдання в локальну систему управління пройшла успішно, то завдання переходить в наступний стан. У протилежному випадку завдання переходить в стан Finishing. В грід-менеджері можна встановити обмеження на кількість завдання в стані Submitting і у стані InLRMS. 142 • InLRMS – Завдання перебуває в черзі (очікує звільнення ресурсу) або виконується. Грід-менеджер не виконує ніяких дій і очікує завершення виконання завдання. • Cancelling – Аварійне завершення завдання або завершення завдання за командою користувача. • Finishing - Іде обробка вихідних файлів. Певні вихідні дані (файли, які створені в результаті виконання завдання) переміщуються на зазначений у завданні ресурс зберігання даних і реєструються в індекссервісі. Файли, які не потрібно зберігати на ресурсі зберігання даних, користувач повинен скопіювати самостійно, використовуючи команду інтерфейсу користувача ngget. Всі інші тимчасові файли видаляються з сесійної директорії на початку цього кроку. В грід-менеджері можна встановити обмеження на кількість завдань в цьому стані. Якщо при копіюванні файлу відбулася помилка, то завдання може перейти в стан InLRMS для повторного запуску. • Finished – Ні яких дій більше грід-менеджер не виконує. Користувач має сам завантажити всі потрібні йому файли з сесійної директорії. Сесійна директорія залишається доступною для користувача ще якийсь час (за замовчанням один тиждень). Після цього завдання переходить в стан Deleted. Час «видалення» (deletion time) може бути одержаний з NorduGrid Information System як атрибут команд nordugridpbs-job-sessiondirerasetime або nordugrid-pbs-job. Якщо завдання перейшло в стан Finished помилково, то воно може бути повторно відправлено на виконання командами інтерфейсу користувача. Якщо завдання потрапило в стан Finished зі стану Submitting, то воно позначається як PENDING. Це зроблено для того, щоб не перевищувати ліміти, встановлені при конфігуруванні. Виключенням є завдання, які потрапили в цей стан зі стану InLRMS і мають нестачу вхідних файлів, 143 зазначених в описі завдання. Таке завдання розглядається як завершень помилково зі стану Preparing. • Deleted – У цей стан завдання переходить, якщо користувач не скопіював результати виконання, і файли видаляються. Про завдання залишається мінімальна інформація. 4.3. Команди інтерфейсу користувача Для використання грід-ресурсів на комп'ютерах користувачів інсталюється спеціальне програмне забезпечення (User Interface - UI), що забезпечує взаємодію з грід - середовищем. Користувач взаємодіє з ARC за допомогою утиліт командного рядка. ARC надає команди для відправки завдань в грід-мережу, запиту стану завдань і кластерів, отримання даних від завершених завдань, переривання завдань і так далі. Також існують засоби для копіювання і видалення файлів в сховищах даних і каталогах реплік. В даному розділі наведено основні команди користувацького інтерфейсу ARC-UI. Більш детальну інформацію про систему обробки завдань та команди ARC-UI можна знайти на сайті NorduGrid (http://www.nordugrid.org/) у розділі «Документація». Таблиця 4.1. Команда Перелік основних команд ARC версії 0.8.* Операція ngsub відправлення завдання на грід-ресурси для виконання ngstat перегляд стану кластерів і завдань ngcat перегляд виводу і помилок завдань ngget копіювання вихідних файлів після завершення завдань ngkill відміна виконання завдання ngclean видалення виводу завдання із кластера 144 Команда Операція ngcp команда копіювання файлів ngrm видалення файлів Розглянемо приклади використання кожної з команд, опис опцій яких наведено у Додатку 6. 1) ngsub - відправлення завдання на грід-ресурси для виконання Синтаксис команди: ngsub [options] <task ...> де: [options] - опції команди, яки можуть приймати значення: [-c| -C|-g|-G |-e |-f |-o |-dryrun | dumpxrsl | -U |-t|-d |-x | -X |-v|-h ]; <task ...> - послідовність команд опису завдання або файл, що описує завдання, які необхідно виконати. Приклад 1. Опис завдання на виконання створюється за допомогою мови опису завдань (Extended Resource Specification Language, XRSL) і містить необхідні вхідні дані, вимоги до ресурсів і відомості про місця, куди повинні бути записані результати обробки завдання. Найпростіше завдання – вивід "Hello World" в термінальному вікні- має вигляд: ngsub -e '&(executable="/bin/echo")(arguments="Hello World")(stdout="hello.txt")' Ця команда відправляє завдання на будь-який доступний для прийому завдань даного користувача грід-ресурс (DN користувача повинен бути включено в grid-mapfile на даному грід-ресурсі) специфічних вимог до виконання завдання. 145 без Завдання буде виконана на кластері в пакетному режимі і результати збережені у файлі стандартного виводу hello.txt. Користувач надалі має вручну завантажити цей файл за командою ngget на свій комп'ютер з інтерфейсом користувача. Якщо завдання успішно відправлене на виконання на віддалений обчислювальний ресурс, то завданню присвоюється ідентифікатор (job ID), який відображається в термінальному вікні (standard output). Ідентифікатор завдання ( job ID) дозволяє контролювати всі етапи виконання завдання на віддаленому ресурсі. Типовий ідентифікатор завдання має вигляд: gsiftp://site.it.uni.org:2812/jobs/10308913211503407485 Цей ідентифікатор використовується надалі для виконання запитів: перегляду стану завдання (ngstat), аварійного завершення завдання (ngkill), повторного запуску завдання (ngresub), одержання результатів виконання (ngget). По своїй структурі ідентифікатор завдання – це URL сесійної директорії для даного завдання. Він дозволяє користувачеві переглянути цю директорію і одержати додаткову інформацію про завдання. Приклад 2. Команди опису завдання зберігаються в окремому файлі. Це дозволяє більш детально виконати опис вимог до ресурсів, вхідних та висхідних файлів. Приклад такого найпростішего завдання приведено нижче. Файл опису завдання (test.xrsl): & (executable=hello.sh) (inputFiles=(hello.sh "")) 146 (stdout="out.txt") (stderr="err.txt") (outputFiles=("out.txt" "")("err.txt" "")) (jobname="Hello grid") Файл скрипту (hello.sh): #!/bin/sh echo "Hello grid!" hostname date pwd У цьому прикладі зазначено, що в якості завдання використовується файл скрипту hello.sh, а результати виконання завдання будуть збережені в файлі out.txt, файл реєстрації помилок err.txt. Відправка даного завдання на виконання виконується за командою: ngsub test.xrsl Примітка. Вхідні й вихідні файли типу sandbox («пісочниці») можна використовувати тільки для невеликих завдань (типу скриптовых файлів) з невеликими об'ємами вихідних даних. Завдання з більшими об'ємами вхідних і вихідних даних необхідно зчитувати й записувати безпосередньо на грід-елемент зберігання даних (storage element). Неправильне використання (переповнення) «пісочниць» може призвести до порушення роботи брокера ресурсів. 147 Приклад 3. Користувач може вказати конкретний грід-ресурс для виконання завдання. Для цього використовується опція –c . В прикладі завдання буде відправлена на виконання на грід кластер grid.nbi.dk. ngsub -c grid.nbi.dk test.xrsl Зокрема, можна задати список грід - кластерів у файлі й використати опцію -C для посилання на цей список. ngsub -C preferred_sites test.xrsl Приклад 4. Для контролю за виконанням команди ngsub дуже зручно використовувати опцію –d, яка означає завдання рівня виводу проміжної інформації роботи брокера ресурсів. Дана опція приймає значення від -3 (мінімальний ) до 3 (повний вивід). За замовчуванням debuglevel = 0. За цією командою будуть роздруковані всі проміжні кроки обробки завдання до моменту пошуку кластера, що найбільше задовольняє умовам, заданим в його описі. Нижче наведено протокол виконання команди при виводі мінімальної інформації. ngsub -d 1 test.xrsl Proxy subject name: /O=Grid/OU=GlobusTest/OU=lcg.bitp.kiev.ua/OU=bitp.kiev.ua/CN=Sergiy Svistunov/CN=1183023934 Proxy valid to: 2007-04-25 00:19:55 Proxy valid for: 11 hours, 30 minutes, 32 seconds Queue selected: nordu@nordu.bitp.kiev.ua File uploaded: /tmp/rsl.nRpBaY File uploaded: /mnt/homes/alkin/grid_test/hello.sh 148 Job submitted with jobid: gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Приклад 5. Дуже корисна опція –o, яка дозволяє вказати ім‘я файлу, в якому буде записаний ідентифікатор (ID) завдання, наданий завданню брокером ресурсів. В подальшому користувач може це ім‘я файлу використовувати для перевірки статусу завдання і не запам‘ятовувати сам ідентифікатор. ngsub -о my_jobid_list test.xrsl В подальшому для виконання запитів: перегляду стану завдання (ngstat), аварійного завершення завдання (ngkill), повторного запуску завдання (ngresub), одержання результатів виконання (ngget) необхідно використовувати опцію –o в ціх командах. У цьому прикладі завдання, ідентифікатор якого записано у файлі my_jobid_list, буде знято с виконання. ngkill -i my_jobid_list Дуже часто виникає ситуація, коли при виконанні команди ngsub кластер відповідає на запити дуже довго або взагалі не відповідає. У загальному випадку це не пов'язано безпосередньо із завданням, а скоріше обумовлено затримками передачі даних через мережу або проблемами конкретного кластера. Але ця ситуація затримує відправлення завдання на виконання. Для прискорення процесу відправки завдання необхідно задати менший інтервал очікування відповіді за допомогою опції –t. ngsub -t 5 test.xrsl 149 Приклад 6. Список доступних кластерів для виконання завдання при виконанні команда ngsub визначається за запитом до інформаційної системи. За замовчанням список доступних серверів інформаційних систем (ARC Information System – GIIS серверів) розповсюджується разом з дистрибутивним пакетом проміжного програмного забезпечення ARC. Після інсталяції цей список зберігається в файлі giislist. Користувач може сформувати будь-який інший список GIIS-серверів, і записати його в конфігураційному файлі або задати за допомогою опції -g. ngsub -g ldap://hostname[:port]/basedn myjob.xrsl Для запиту до LDAP сервера може бути використана різна форма завдання DN , як зазначено в прикладі: ngsub -g ldap://index1.nordugrid.org:2135/O=Grid/Mds-Voname=NorduGrid myjob.xrsl ngsub -g ldap://index1.nordugrid.org:2135/mds-voname=NorduGrid,O=Grid myjob.xrsl Користувач може сформувати список GIIS-серверів і зберегти його у файлі з подальшім посилання на цей список з використанням опції - G. Наприклад: ngsub -G my_GIIS_list myjob.xrsl 150 2) ngstat - перегляд стану завдань Ця команда використовується для одержання інформації про стан (статус) завдання і має синтаксис: ngstat [options] [job ...] де: [options] - опції команди, яки можуть приймати значення: [-a | -i |-c |-C |-s |-g |-G |-q | -l | -t|-d |-x | -X |-v|-h ]; [job ...] - ідентифікатор завдання ( job ID). Для опцій -a, -i, -c, -C, -s команда ngstat виводить інформацію для всіх завдань користувача, які задовольняють заданому критерію. Приклад 7. Для одержання інформації про стан конкретного завдання користувача необхідно вказати ідентифікаційний номер завдання, котрий присвоєно завданню брокером ресурсів. Нижче наведено типовий приклад використання команди і вивід інформації про стан завдання. ngstat gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Job gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Job Name: Hello grid Status: FINISHED Exit Code: 0 Завдання завершилося успішно і користувач може отримати результати виконання завдання. 151 Приклад 8. Для отримання списку завдань користувача, які перебувають у заданому стані «statusstr», використовується опція -s. Наведена нижче команда виводить список завдань користувача, що виконуються: ngstat -s "INLRMS:R" Для завершених завдань необхідно розрізняти стани FINISHED і FAILED, які вказують, чи завершилося завдання успішно, чи ні. Приклад 9. При застосуванні команди ngstat можна використовувати комбінації опцій. Наведена нижче команда виводить інформацію про всі завдання користувача, що завершилися, плюс інформацію про всі завдання (у будь-якому стані) на кластері my.grid.org й інформацію про завдання з ідентифікатором gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571. ngstat -s FINISHED -c my.grid.org gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Приклад 10. Якщо сформовано файл, в якому збережені ідентифікатори завдань користувача, то використання опції –o дозволить уникнути вводу ідентифікатору. ngstat -о my_jobid_list Примітка. Якщо в файлі записано більш одного ідентифікатора, то на екрані відобразиться список всіх ідентифікаторів. Користувач повинен вказати номер рядку, в котрому знаходиться потрібний ідентифікатор завдання, стан якого необхідно перевірити. 152 3) ngcat - перегляд виводу і помилок завдань При виконанні завдання зручно контролювати хід його виконання шляхом перегляду потокового виводу результатів та повідомлень про помилки. За командою ngcat можливе добування цієї інформації з кластера, на якому завдання виконується, і вивід її на екран користувача. Синтаксис команди: ngcat [options] [job ...] де: [options] - опції команди, яки можуть приймати значення: [-a | -i |-c |-C |-s |-o |-e |-f | -l | -t|-d |-x | -X |-v|-h ]; [job ...] - ідентифікатор, який присвоєно завданню ( job ID). Команда ngcat відображає на екрані стандартний вивід завдання (опція -o), стандартний вивід помилок при виконанні завдання (опція e) і помилки, які фіксує грід- менеджер (Grid Manager) при обробці завдання (опція -l). Для опцій протоколювання -a, -i, -c, -C, -s та [job...] друкується файл (log file) для всіх завдань користувача, які задовольняють заданому критерію. Приклад 11. Наведена нижче команда відображає у вікні термінальної системи користувача файл протоколювання для всіх завдань, які завершилися в грід - системі, плюс файл протоколювання виконання всіх завдань (не залежно від стану, у якому вони перебувають) на кластері my.grid.org і файл протоколювання для завдання із зазначеним ідентифікатором gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571. 153 ngcat -s FINISHED -c my.grid.org gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 4) ngget - копіювання вихідних файлів після завершення завдань Ця команда дозволяє зберегти в домашній директорії користувача на комп'ютері із установленим користувальницьким інтерфейсом файли результатів виконання завдання, які відзначені як вихідні файли в описі завдання. Синтаксис команди: ngget [options] [job ...] де : [options]- опції команди, яки можуть приймати значення: [-a | -i |-c |-C |-s |-dir |-j |-keep | -l | -t|-d |-x | -X |-v|-h ], [job ...] - ідентифікатор, який присвоєно завданню ( job ID). Ця команда дозволяє копіювати результати виконання завдань, які завершилися. Копіювання результатів виконання завдання у домашню директорію користувача виконується або за ідентифікатором завдання (jobID), який привласнюється йому при виконанні команди ngsub, або за ім‘ям завдання (job name attribute), яке задається як атрибут в опису завдання. Для того, щоб користувач міг отримати результати виконання свого завдання за командою ngget, файли результатів повинні бути вказані в описі завдання мовою xRSL у атрибуті outputfiles, як то показано нижче: (outputfiles=(file1 "")(file2 "")) 154 Стандартні файли stdout, sterr та директорія gmlog за замовчанням розглядаються грід-менеджером як результуючі файли завдання, і користувачеві не потрібно описувати їх у списку результуючих файлів в атрибуті outputfiles. Приклад 12. Приклад застосування команди ngget для копіювання результатів виконання завдання та протокол її виконання наведено нижче. ngget gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Results stored at /mnt/homes/alkin/grid_test/2152211778453271868406571 Jobs processed: 1, successfuly downloaded: 1 За замовчуванням команда ngget створює в домашній директорії користувача нову піддиректорію з таким же ім'ям, як і сесійна директорія завдання на віддаленому ресурсі. Зазвичай, це довгий цифровий рядок. У цій піддиректорії будуть збережені всі файли результатів виконання завдання, які в описі визначені в атрибут outputfiles опису завдання. Користувач надалі має сам повинен вилучати ці піддиректорії з результатами старих завдань. Якщо результуючих завдання файлів, користувача варто генерує забезпечити багато їх маленьких архівацію перед завантаженням на комп'ютер користувача. Це пов'язане з тим, що передача великої кількості маленьких файлів може зайняти всі доступні TCP порти, виділені для передачі даних сервером, і це може привести до помилок передачі файлів. 155 Приклад 13. Наведена нижче команда копіює результати для всіх завдань користувача, які завершилися на грід- ресурсах, плюс результати всіх завдань, що завершилися, на кластері my.grid.org і результати завдання з зазначеним ідентифікатором gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571. ngget -s FINISHED -c my.grid.org gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Приклад 14. Якщо сформовано файл, в якому збережені ідентифікатори завдань користувача, то використання опції -i дозволить виконати копіювання результатів без вводу ідентифікатору завдання. ngget -i my_jobid_list Примітка. Якщо в файлі записано більш одного ідентифікатору, то на екрані відобразиться список всіх ідентифікаторів. Користувач повинен вказати номер рядку, в котрому знаходиться потрібний ідентифікатор завдання результати виконання якого необхідно скопіювати в домашню директорію. 156 5) ngkill – відміна виконання завдання Ця команда дозволяє зняти з виконання завдання користувача на будь-якій стадії його оброблення в грід-інфраструктурі і має наступний синтаксис: ngkill [options] [job ...] де : [options]- опції команди, яки можуть приймати значення: [-a | -i |-c |-C |-s |-dir |-j |-keep | -t|-d |-x | -X |-v|-h ], [job ...] - ідентифікатор завдання ( job ID). Приклад 15. Приклад застосування команди ngkill для дострокового завершення завдання наведено нижче. ngkill gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Зняття завдання з виконання є асинхронним процесом, тому може пройти певний час після відправлення команди до реального завершення завдання. Якщо команда ngkill завершилася успішно, то всі файли завдання видаляються з кластера, на якому виконувалося завдання. Для того, щоб цього не відбулося, варто використати опцію – keep, як показано в прикладі 16. Приклад 16. ngkill - keep gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Надалі за командою ngget або ngcat користувач може зберегти результуючі файли пперерваного завдання в домашньої директорії користувача для наступного аналізу. 157 Приклад 17. При виборі опцій -a, -i, -c, -C, -s та [job...] з виконання знімаються всі завдання користувача, які задовольняють заданому критерію. В цьому прикладі знімаються з виконання всі завдання користувача, які виконуються на грід-ресурсах, плюс всі завдання на кластері my.grid.org (не залежно від стану, у якому вони перебувають), і завдання із зазначеним ідентифікатором gsiftp://nordu.bitp.kiev.ua:2811/jobs/ 2152211778453271868406571. ngkill -s INLRMS:R -c my.grid.org gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Приклад 18. Якщо сформовано файл, в якому збережені ідентифікатори завдань користувача, то використання опції -i дозволить зняти з виконання всі завданя користувача, номери jobID яких записані у файлі «filename». ngget -i my_jobid_list 6) ngresub – повторна відправка завдання на виконання Дана команда застосовується, коли користувач на може відновити оригінальний xRSL файл опису завдання. Зазвичай така ситуація виникає, коли xRSL-файл опису завдання генерується зі скриптів і складно встановити однозначну відповідність з одержаним ідентифікатором завдання. За цією ж командою можлива повторна відправка завдання на виконання за її ідентифікатором. Однак, 158 використовувати команду ngresub можливо тільки для завдань, в описі яких був визначений атрибут gmlog. Синтаксис команди: ngresub [options] [job ...] де : [options]- опції команди, які можуть приймати значення: [-a | -i |-c |-C|-s|-k |-K |-g | -G|-o| -dryrun| -dumpxrsl| -keep| -t|-d |-x | -X |-U| -v| -h ], [job ...] - ідентифікатор завдання ( job ID). Приклад 19. Приклад застосування команди ngresub для повторного виконання завдання наведено нижче: ngkill gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 Важливо розрізняти опції -c й -k (так само, як і опції -C й -K). Для опції -c або –cluster команда ngresub шукає зазначені для повторного запуску ідентифікатори завдання та їх опис тільки на заданому кластері. Це дозволяє вказавши опцію -a запустити на повторне виконання всі завдання, які були спочатку спрямовані на зазначений кластер. Опція -k або -kluster використається для вказівки кластера, на якому необхідно заново запустити завдання на виконання. Приклад 20. ngresub -c fire.ii.uib.no myjob.xrsl 159 За цією командою виконується повторний запуск на виконання всіх завдань користувача на кластері fire.ii.uib.no та завдання myjob.xrsl на кожному з доступних кластерів, за винятком тих, на яких це завдання вже виконується на даний час. Приклад 21. ngresub -c grid1.ua.org -k grid2.ub.org За цією командою виконується повторний запуск на кластері grid2.ub.org всіх завдань користувача, які раніше були запущені на кластері grid1.ua.org. Якщо повторний запуск завдання виконався успішно, то інформація про попередній запуск завдання видаляється з кластера, на якому вона була запущена раніше (якщо була зазначена опція -keep, то ця дія не виконується). Старий log-файл (gmlog) не зберігається й не передається на нові сервери. Для опцій -a, -i, -c, -C, -s та [job...] запускаються на повторне виконання всі завдання користувача, які задовольняють заданому критерію. Приклад 22. ngresub -s FAILED -c my.grid.org gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 За цією командою виконується повторний запуск на виконання всіх завдань користувача, які мали стан FAILED, плюс всі завдання на кластері my.grid.org (не залежно від стану, в якому вони перебувають) і повторно запускається на виконання на кластері my.grid.org завдання із ідентифікатором gsiftp://nordu.bitp.kiev.ua:2811/jobs/ 2152211778453271868406571. 160 7) ngclean - видалення файлів виводу результатів виконання завдання з кластера, на якому воно виконувалося Якщо завдання завершилося помилково або користувач не хоче копіювати результати виконання завдання на свій комп'ютер, то користувач ,не чекаючи, поки Grid Manager сам видалить тимчасові файли, може самостійно очистити дисковий простір та видалити ідентифікатори завершених завдань з інформаційної системи. Всі ці операції виконуються за командою ngclean, яка має наступний синтаксис: ngclean [options] [job ...] де : [options]- опції команди, які можуть приймати значення: [-a | -i |-c |-C|-s|-f |-t|-d |-x | -X | -v|-h ], [job ...] - ідентифікатор завдання ( job ID). Приклад 23. ngclean -s FAILED -c my.grid.org gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 За цією командою виконується віддалення всіх файлів результатів виконання завдань, які мали стан FAILED, плюс всіх файлів результатів виконання завдань на кластері my.grid.org (не залежно від стану, в якому вони перебувають) і всіх файлів результатів виконання завдання із ідентифікатором gsiftp://nordu.bitp.kiev.ua:2811/jobs/ 2152211778453271868406571. 8) ngrenew - відновлення проксі - сертифіката завдання Часто трапляється ситуація, коли дія проксі-сертифіката користувача завершується, а завдання ще виконується (або очікує виконання в черзі на віддаленому кластері). У цьому випадку, якщо 161 завдання почне зберігати результуючі файли на елементі зберігання даних (Storage Element), то ця операція завершитися аварійно і можлива втрата результатів розрахунку. По команді ngrenew користувач може подовжити дію проксі-сертифікату для завдання. Така операція повинна бути виконана, поки дія старого проксі-сертифікату ще не закінчилася. У випадку, якщо завдання завершилося аварійно через закінчення терміну дії проксі- сертифікату при збереженні результатів, в наступні 24 години за командою ngresume Grid Manager може відновити перервану операцію збереження файлів і завершити завдання. Синтаксис команди: ngrenew [options] [job ...] де : [options]- опції команди, яки можуть приймати значення: [-a | -i |-c |-C|-s|-t|-d |-x | -X | -v|-h ], [job ...] - ідентифікатор завдання ( job ID). Перед виконанням команди ngrenew необхідно створити новий проксі-сертифікат користувача за допомогою команди: grid-proxy-init -valid 24:00 Використання опції -valid дозволяє вказати термін дії проксісертифікату (у прикладі 24 години). Можливе використання і розширеного проксі-сертифікату, що генерується за допомогою команди voms-proxy-init. Приклад 24. Після створення нового проксі-сертифікату користувача можливо використання команди ngrenew: 162 ngrenew -s FAILED -c my.grid.org gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 За цією командою виконується оновлення проксі-сертифікату для завдань користувача, які малі стан FAILED, плюс для всіх завдань користувача на кластері my.grid.org (не залежно від стану, в якому вони перебувають) і виконується оновлення проксі- сертифікату для завдання із ідентифікатором gsiftp://nordu.bitp.kiev.ua:2811/jobs/ 2152211778453271868406571. 9) ngresume - відновлення роботи завдання після збою при виконанні У випадку, коли завдання завершилося аварійно із-за помилки при зчитуванні вхідних файлів, помилок при записі файлів результатів завдання на елемент збереження даних, закінчення терміну дії проксісертифікату, то користувач може виконати повторний запуск на виконання своїх завдань, використавши команду ngresume. Перед виконанням цієї команди користувач повинний переконатися, що його проксі- сертифікат дійсний, а потім використати команду ngrenew для подовження дії проксі- сертифікату для завдань, які він бажає повторно відправити на виконання, і виконати ngresume. Виконання завдання буде поновлене з того стану, у якому воно перебувало до аварійного завершення. Синтаксис команди: ngresume [options] [job ...] де : [options]- опції команди, які можуть приймати значення: [-a | -i |-c |-C|-s|-t|-d |-x | -X | -v|-h ], [job ...] - ідентифікатор завдання ( job ID). 163 Приклад 25. За командою, наведеною нижче, виконується відновлення роботи завдань користувача, які мали стан FAILED, плюс всі завдання, які завершилися аварійно на кластері my.grid.org (не залежно від стану, у якому вони перебувають) і завдання із ідентифікатором gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571. ngresume -s FAILED -c my.grid.org gsiftp://nordu.bitp.kiev.ua:2811/jobs/2152211778453271868406571 4.4 Команди роботи з даними 1) ngls - перегляд змісту директорії на ресурсі Ця команда дозволяє переглянути зміст та деякі атрибути файлів на ресурсі зберігання даних в певної директорії, яка задається за допомогою URL, і має синтаксис: ngls [options] <URL> де: [options]- опції команди, які можуть приймати значення: [-h | -v |-d |-l |-L |-m |-r ], <URL> - файл або URL. Ця утиліта дозволяє переглянути список файлів, які зберігаються на елементі зберігання даних, а також переглянути зміст робочих директорій завдань, використовуючи ідентифікаційний номер (job ID) завдання в якості URL. 164 Приклад 26. Для виводу переліку файлів, які зберігаються на елементі зберігання даних, використовуються команда в форматі: ngls rls://rc.host:38203/logical_file_name Нижче наведена приклад виводу файлів, яки зберігаються в сесійної директорії завдання з заданим ідентифікатором: ngls -l gsiftp://lscf.nbi.dk:2811/jobs/1323842831451666535 Для виводу повної інформації про файли в директорії, включаючи URLs, звідки ці файли були завантажені, використовується опція –L: ngls -L srm://grid.uio.no:58000/srm/managerv1/johndoe/log2 2) ngcp - команда копіювання файлів Ця команда дозволяє копіювати файли між грід-кластерами. Ця утиліта є частиною грід-менеджера (Grid Manager), але її можна використовувати і з інтерфейсу користувача. Синтаксис команди: ngcp [options] <source> <destination> де: [options]- опції команди, які можуть приймати значення: [-h | -v |-d |-y |-p |-n |-i |-u | -r |-R |-t | -f |-T |-r ], < source > - URL джерела (файлу, що копіюється), <destination> - URL приймача (файлу, куди копіюється). Команда ngcp може виконувати багато потокову передачу даних, якщо сервер підтримує таку операцію. В випадку, якщо буде копіюватися вся директорія, опис URL джерела повинний завершуватися символом "/". Якщо приймач зазначено з символом "/" наприкінці і джерело зазначене аналогічно, те це означає, що директорія, куди будуть передаватися файли, аналогічна джерелу. 165 Приклад 27. Приклади використання команди наведено нижче. ngcp gsiftp://lscf.nbi.dk:2811/jobs/1323842831451666535/job.out \ file:///home/myname/job2.out ngcp gsiftp://aftpexp.bnl.gov;threads=10/rep/my.file \ rc://;threads=4@grid.uio.no/lc=Collection,rc=Catalog/zebra4.f ngcp http://www.nordugrid.org/data/somefile gsiftp://hathi.hep.lu.se/data/ 3) ngrm - видалення файлів з ресурсу зберігання даних, який задано за допомогою URL. Команда ngrm дозволяє користувачеві видаляти файли на будьякому пристрої, що завданий своїм URL. Синтаксис команди: ngrm [options] <source> де: [options]- опції команди, які можуть приймати значення: [-h | -v |-d |-y |-p |-n |-i |-u | -r |-R |-t | -f |-T |-r ], < source > - URL джерела (файлу, що видаляється). Команда ngrm видаляє файли з індексного каталогу (RC, RLS чи подібного), і хоча при виконанні фізичні файли можуть бути не стерті, будуть видалені їх посилання в базі даних. Після такої операції файли стають недоступними для використання. 166 Приклад 28. Приклад використання команди наведено нижче. ngrm rc://grid.uio.no/lc=Collection,rc=Catalog/badfile#\\ ngacl - модифікація інформації про контроль доступу 4) Ця команда відновлює або змінює інформацію управління доступом, пов'язану з елементом збереження даних, якщо сервіс підтримує мову опису управління доступом GridSite GACL. Синтаксис команди: ngacl [options] getjput <URL> де: [options]- опції команди, які можуть приймати значення: [-h | -v |-d ], getjput - метод доступу для Grid ACL об'єкта, <URL> - URL об'єкта . ACL документ (у форматі XML файлу) виводиться при завданні параметра «get», і вибирається при завданні параметра «set» стандартному вході. Приклад 29. ngacl get gsiftp://se1.ndgf.csc.fi/ndgf/tutorial/dirname/filename ngacl set gsiftp://se1.ndgf.csc.fi/ndgf/tutorial/dirname/filename $<$ myacl 167 на 5) ngtransfer - передача даних між серверами Ця команда виконує пряму передачу даних між двома серверами і має синтаксис: ngtransfer [options] <destination> де: [options]- опції команди, які можуть приймати значення: [-s | -h |-v |-d ], <destination> - URL сервера, куди буде копіюватися файл. Ця команда забезпечує копіювання файлів з різних джерел на сервер, адреса якого задана у вигляді URL. Приклад 30. ngtransfer -s http://www.host1.org/dat1 -s gsiftp://host2.org/dir/dat1 \ se://se.host.org/se_service?new_file_lfn 6) ngstage - копіювання файлу зі стрічкового дискового пристрою на жорсткий диск Якщо файли даних зберігається на стрічковому пристрої зберігання даних, то при виконанню завдання з обробки таких даних виникають певні труднощі. Вони пов‘язані з виконанням операції зчитування файлів зі стрічкового пристрою, яка займає багато часу. Якщо виконання завдання з обробки даних перевищить ліміт використання часу процесора для локальної черги завдань, то воно буде аварійно завершене планувальником завдань обчислювального кластера. Для того, щоб виключити цю ситуацію, використається команда ngstage , що переписує файл зі стрічкового пристрою на жорсткий диск. Ця команда повинна бути виконана до запуску завдання з обробки даних на виконання. Її синтаксис: 168 ngstage [options] <URL(s)> де: [options]- опції команди, які можуть приймати значення: [-q |-c |-D |-d |-r |-s |-h |-v |-t], <URL(s)> - URL файлу для копіювання . Після запуску команда повертає ідентифікатор запиту (request ID), що надалі може бути використаний для моніторингу виконання команди (з опцією -q) або для аварійного завершення команди (опція -c ). Повний список активних запитів команди ngstage на копіювання файлів можна одержати, використовуючи опцію - h . Для опцій -q, -l необхідно вказати URL файл-сервера, на якому ці команди виконуються. Для опції -s (звичайно вона відповідає srm:// протокол ) URL сервера в початковому запиті можна опустити. Приклад 31. ngstage srm://srm.ndgf.org/pnfs/ndgf.org/data/atlas/tape/file.1\\ ngstage -q -2139909111 -s srm://srm.ndgf.org У прикладі показане виконання запиту на копіювання і перевірка його стану. 4.5 Команди тестування Проміжне програмне забезпечення ARC постачається з досить обмеженим набором тестових утиліт, які перевіряють різні функціональні можливості грід- ресурсів. Команда тестування ngtest містить набір тестових завдань, які перевіряють працездатність грід-сервісів. Ця команда використовується 169 для тестування кластерів, які підключаються у перший раз до грідінфраструктури,. За допомогою цієї команди користувач, який починають працювати із грід-сервісами вперше, може одержати великий обсяг інформації про його авторизацію на конкретному обчислювальному ресурсі або елементі зберігання даних, інформацію про приналежність до віртуальної організації, а також може виконати запуск різних тестових завдань в грід-інфраструктурі. Крім того, можна перевірити, чи встановлене необхідне програмне забезпечення на віддаленому обчислювальному ресурсі. Синтаксис команди: ngtest [options] де: [options]- опції команди, які можуть приймати значення: [-E |-j |-R |-O |-V |-r |-c |-C |-g |-G |-o |-dryrun |-dumpxrsl | -t |-d |-x |-X | -v |-h], Приклад 32. Отримання переліку обчислювальних ресурсів,доступних користувачеві для відправки завдання на виконання: ngtest –R Приклад 33. Отримання інформації про сертифікат користувача: ngtest -E Приклад 34. Відправлення тестового завдання на виконання: ngtest -J 1 170 В параметрах команди ngtest вказується номер тестового завдання (1,2,3). Опис тестових завдань наведено нижче. Тест 1. Це тестове завдання обчислює прості числа протягом двох хвилин і зберігає результат обчислення у вигляді списку. Код програми, необхідні бібліотеки та файл завдання завантажуються на обраний кластер з різних серверів, і потім виконується компіляція програми перед її виконанням. У такий спосіб перевіряються різні служби і сервіси грід- кластера. Тест 2. Це тестове завдання не виконує обчислень,а просто друкує «hello, grid». Тест 3. Це тестове завдання перевіряє можливість грід-кластера завантажувати файли (8 файлів), використовуючи різні протоколи ( HTTP, FTP, gsiFTP й RLS) передачі даних. Приклад 35. Відправлення тестового завдання на обраний кластер: ngtest -J 1 -c grid.place.org Приклад 35. Відправлення тестового завдання на виконання з виводом діагностичної інформації: ngtest -J 1 -d 2 4.6 Опис завдання Перед запуском завдання командою ngsub користувач повинен сформувати опис завдання мовою xRSL (Extended Resource Specification Language). Опис завдання повинен містити всю необхідну 171 для виконання на віддаленому ресурсі інформацію (файл виконання, параметри, і т.д.), а також набір вимог, якому має відповідати кластер, щоб виконати завдання (вільний дисковий простір, установлене програмне забезпечення) і інформацію про те, куди мають бути записані результати виконання завдання. Як тільки користувач запускає завдання за допомогою ngsub, інтерфейс користувача (UI) встановлює зв'язок з інформаційною системою, спочатку для пошуку доступних ресурсів, а потім для опитування кожного з доступних кластерів на відповідність вимогам опису завдання. Якщо зазначено, що необхідне завантаження вхідних файлів з каталогу реплік, то встановлюється зв'язок і з цим каталогом. Далі інтерфейс користувача встановлює відповідність між вимогами, зазначеними в описі завдання, та інформацією, отриманою від кластерів, і вибирає обчислювальний кластер, який задовольняє вимогам завдання. Якщо кластер, який задовольняє вимогам завдання знайдений, завдання відправляється на кластер і розміщується в локальній черзі завдань на виконання. Extended Resource Specification Language (xRSL) – версія мови опису завдання, побудована на основі мови специфікації ресурсів RSL, яка була розроблена в рамках проекту Globus. В архітектурі ARC мова специфікації ресурсів (xRSL) має подвійне призначення: крім опису завдання користувачем та використання нових атрибутів, вона описує комунікацію між інтерфейсом користувача та Грід-менеджером. Тому всі специфікації xRSL можна розділити на дві частини:  RSL користувача – набір атрибутів, яки задані користувачем у файлі опису завдання. Цей файл інтерпретується інтерфейсом користувача і після необхідних модифікацій передається Грідменеджеру. 172  RSL Грід-менеджера – набір атрибутів, попередньо оброблених інтерфейсом користувача, готовий для інтерпретації Грід-менеджером. Такий функціональний розподіл, а також введення нових і перевизначення деяких атрибутів, призвело до створення нової версії мови опису завдання, названої Extended Resource Specification Language. Типовий xrsl-файл має вигляд: & (* this is comment *) (executable=ex.sh) (executables=example1) (inputFiles=(example1 "")) (arguments=”100000000” “13” “0.324”) (stdout="out.txt") (stderr="err.txt") (outputFiles=("out.txt" "")("err.txt" "")) (gmlog="gridlog") (jobname="Example") (cputime=20) (middleware>="nordugrid-arc-0.3.24") У цьому прикладі зазначено, що в якості вхідного файлу, який буде виконуватися на ресурсі, використовується скрипт ex.sh, а результати записуються в стандартні вихідний файл (stdout="out.txt") і файл реєстрації помилок (stderr="err.txt"), які потім необхідно завантажити на комп'ютер користувача. 173 Синтаксис та правила формування опису завдання Синтаксис та правіла формування опису завдання дуже прости і можуть бути сформульовані наступним чином: 1) Файл опису завдання - це текстовий файл, який містить набір рядків пар «атрибут-значення», які розміщені у круглі дужки, а також логічні оператори «&» (логічне «і») та «|» (логічне «або»): (attribute=value) або (attribute=value value2) 2) У якості значення деяких атрибутів виступають пари значень: (attribute=(value1 value2)(value3 value4)) 3) Значення повинні бути взяті в лапки, якщо вони містять пропуски або спеціальні символи: +&|()=<>!"'^#$ 4) Опис завдання починається з символу «&», за яким йдуть пари «атрибут-значення»: & (attribute1=value1) (attribute2=value2)... 5) Коли необхідно поєднати атрибути зв'язком логічне «або» ( «|») , використовується наступна конструкція: (|(attribute=value1)(attribute=value2)...) 6) Коментарі виділяються в (* *) і не можуть бути розміщені в середині другого коментарю: (* comments *) 7) Імена атрибутів нечутливі до регістру. 174 8) Опис завдання, який містить декілька незалежних завдань, має вигляд: +(&(...))(&(...))(&(...)) Використання атрибутів опису завдання розглянемо на простих прикладах. Більш детальний опис атрибутів наведено в Додатку 6. Приклад 35. Нижче наведено простіший приклад опису завдання, яке виводить в стандартний потік «Hello Grid». & (executable=/bin/echo) (arguments="Hello Grid" ) (stdout="hello.txt") (stderr="hello.err") (jobname="My Hello Grid") Розглянемо детальніше опис завдання. Атрибут «executable» визначає команду або описує ім'я файлу, який буде переданий на виконання до локальної системи керування кластером. Це може бути файл (.exe), скрипт (.sh) або команда системи Linux. Атрибут «stdout» вказує що вивід результатів буде здійснено в стандартний файл виводу. Ім‘я файлу стандартний файл виводу має бути вказаний іншому випадку він буде внесений «hello.txt». Зазвичай в атрибуті outputFiles, в до цього списку за ім'ям ARC- клієнта. Якщо стандартний файл виводу не визначений, ARC-клієнт сам присвоює йому ім'я. 175 Атрибут «stderr» вказує що вивід помилок виконання буде здійснено в стандартний файл виводу помилок з ім‘ям «hello.err». Стандартний файл виводу помилок має бути вказаний в атрибуті outputFiles, в іншому випадку він буде внесений до цього списку за ім'ям ARC-клієнта. Якщо стандартний файл помилок не визначений, ARC- клієнт сам присвоює йому ім'я. Атрибут «arguments» визначає список параметрів для файлу, який буде виконуватися на ресурсі. За синтаксисом атрибуту (arguments=<string> [string] ... ) значення, які передаються програмі як параметри, перелічуються з роздільником пропусків. Атрибут «jobname» визначає ім‘я завдання, яке надано користувачем. Це ім'я може бути використане при виконанні команд клієнтського інтерфейсу ARC. Приклад 36. Одне з найбільш серйозних завдань додатків ARC це переміщення великої кількості файлів (найчастіше великого розміру) для виконання програми і після завершення завдання. Для цього в xRSL були введені два атрибути: inputFiles та outputFiles, кожен з яких має список пар «локальне ім'я файлу – ім'я файлу (або URL-адреси)». Синтаксис атрибутів має вигляд: (inputFiles=(<filename> <source>) ... ), де (<filename> [size][.checksum]) ... ) (outputFiles=(<string> <URL>) ... ) Нижче наведено приклад використання атрибутів inputFiles та outputFiles в опису завдання: 176 & (executable= "run.sh") (jobname="rot13-se") (arguments="5") (inputfiles= ("run.sh" "http://www.nordugrid.org/data/run.sh") ("Makefile" "gsiftp://hathi.hep.lu.se/public/ngtest/Makefile") ("prime.cpp" "ftp://ftp.nordugrid.org/applications/test/prime.cpp")) (outputFiles= (result "gsiftp://grid.tsl.uu.se/tutorial/tallinn/tallinn-meeting.encoded") (rot13.out "gsiftp://grid.tsl.uu.se/tutorial/tallinn/rot13.out") (rot13.err "gsiftp://grid.tsl.uu.se/tutorial/tallinn/rot13.err")) (stdout="rot13.out") (stderr="rot13.err") Користувач може вказати файл, який буде передаватися на виконання в пакеті завдання (атрибут inputFiles) , або вказати файл, який вже попередньо збережений на системі збереження даних. Якщо ім'я файлу починається з ("/"), то це означає, що зазначено повний шлях розміщення файлу на віддаленому сайті. В даному прикладі перед виконанням завдання вхідні файли завдання "run.sh", "Makefile", "prime.cpp" завантажуються на обраний обчислювальний вузол, після чого контроль передається грідменеджеру. По завершенню завдання вихідні файли result, rot13.out, rot13.err копіюються в зазначене в атрибуті місце зберігання грідменеджером (в прикладі на сервер grid.tsl.uu.se). Якщо сервер зберігання не зазначений в атрибуті, то передбачається, що користувач сам виконає копіювання цих файлів за допомогою команди ngget. Як 177 місце збереження вихідного файлу можна вказати псевдо-URL каталогу реплік, в якому вихідний файл буде зареєстрований. Приклад 37. Наступний приклад ілюструє використання атрибутів опису ресурсів, які необхідні для виконання завдання: & (executable="checkall.sh") (rsl_substitution=("TOPDIR" "/home/johndoe")) (rsl_substitution=("BIGFILE" "/scratch/johndoe/100mb.tmp")) (environment =("ATLAS" "/opt/atlas") ("CERN" "/cern")) (inputFiles = ("file1" gsiftp://grid.uio.no$(TOPDIR)/remfile.txt) ("bigfile.dat" $(BIGFILE) ) ) (outputFiles= ("file1" "gsiftp://grid.tsl.uu.se/tmp/file1.tmp") ("100mb.tmp" "rls://rls.nordugrid.org:39281/test/bigfile") ("be_kaons.hbook" gsiftp://ce1.grid.org/kaons.hbook) ) (jobName="NGtest") (stdin="myinput.dat") (stdout="myoutput.dat") (stderr="myerror.dat") (gmlog="gmlog") (cluster="cluster1.site2.org") (cpuTime=10) (memory=32) (disk=1) (startTime="2011-09-25 21:30") 178 Для того, щоб проводити пошук ресурсів, які відповідають вимогам завдання, на базі конфігурації кластера, використовуються атрибути middleware, architecture, runTimeEnvironment, cluster, memory, benchmarks та інші. Використовуючи атрибут «cluster», користувач може явно вказати грід-ресурс, на який буде відправлено завдання для виконання. Однак, завдання не буде відправлено на ресурс, якщо він не задовольняє іншим вимогам завдання. Атрибут «cpuTime» вказує максимальне значення процесорного часу, яке запитується для виконання завдання. Цей атрибут має бути вказаний для завдань, які направляються на обчислювальні ресурси, у яких встановлено ліміт використання часу процесора для локальної черги завдань. Для завдання, яке для виконання використовує декілька процесорів, це значення дорівнює сумі часу для кожного процесора. Завдання, яке перевищує цій термін, буде аварійно завершене планувальником завдань обчислювального кластера. Якщо обмеження на використання процесорного часу на віддаленому обчислювальному ресурсі відсутнє і цей атрибут не заданий, то завдання буде виконувати стільки часу, скільки дозволяє конфігурація системи на віддаленому ресурсі. Атрибут «memory» вказує об‘єм оперативної пам‘яті, необхідний для виконання завдання. Аналогічно до cpuTime цей атрибут використовується для формування переліку ресурсів, які задовольняють вимогам завдання. Завдання, яке перевищує цей ліміт пам'яті, буде, швидше за все, аварійно завершене планувальником завдань обчислювального кластера. Атрибут «startTime» визначає час початку обробки завдання грідменеджером. Фактичний початок 179 оброблення завдання на обчислювальному вузлі залежить від локальних механізмів планування, але він починається не раніше, ніж StartTime. Користувацький атрибут «rsl_substitution» дозволяє виконати підстановку довгих значень URL адресів файлів, що робить опис завдання наочним. 4.7. Приклад виконання лабораторної роботи У цьому розділі наведено приклад послідовності кроків, які повинні бути виконані студентом, щоб відправити завдання до грідсистеми, яка працює під керування проміжного програмного забезпечення ARC, та контролювати процес його виконання. Для виконання лабораторних робіт встановлено локальний клієнт ARC. У домашній директорії студента міститься файл nordugrid-arcstandalone-0.8. 3-1.el4.i386.tgz. Для забезпечення запуску завдання в навчальну грід-інфраструктуру необхідно виконати команди (запуск команд із домашньої директорії користувача): tar xzf nordugrid-arc-standalone-0.8. 3-1.el4.i386.tgz cd nordugrid-arc-standalone-0.8. 3-1 source setup.sh В результаті виконання цих команд буде інстальоване програмне забезпечення користувальницького інтерфейсу ARC. Примітка. Наведені вище команди спочатку розархівують програмне забезпечення в окрему піддиректорію (nordugrid-arcstandalone-0.8. 3-1), а потім встановлюють змінні оточення 180 для виконання команд користувацького інтерфейсу ARC. Змінні оточення діють тільки в даному сеансі роботи с системою. При повторному сеансі роботи з ARC системою необхідно виконати тільки наступні команди: cd nordugrid-arc-standalone-0.8. 3-1 source setup.sh Перед використанням кожної з команд користувацького інтерфейсу (ARC-UI) необхідно мати дійсний проксі-сертифікат. Його можна створити за допомогою команди voms-proxy-init або, альтернативно, за допомогою команди grid-proxy-init. Якщо проксісертифікат уже є на комп‘ютері з користувацьким інтерфейсом, то можна використати змінну середовища X509_USER_PROXY для вказівки шляху до нього. Крім того, у каталозі $HOME/.globus необхідно мати пару сертифікат/закритий ключ, тобто файли - usercert.pem, userkey.pem з правами доступу 0600 й 0400, відповідно. Це так звані підготовчі операції, які повинні бути зроблені при виконанні даної лабораторної роботи. Тепер перейдемо до виконання лабораторної роботи. Завдання. Розробити програму апроксимації функції sin(x) рядом Тейлора та виконати обчислення в навчальній грідінфраструктурі під керуванням проміжного програмного забезпечення ARC. При виконанні другої лабораторної роботи в домашньої директорії студента знаходилися файли: - sinsum.py – програма обчислення апроксимації функції sin(x) рядом Тейлора розроблена за допомогою мови програмування python; 181 - sinsum.xml - дані для розрахунку; - sinsum.sh – скрипт виконання завдання для локальної системи планування кластеру. Крок 1: Створення файлі опису завдання За допомогою текстового редактору створимо файл (ім‘я файлу sinsum.xrsl) опису завдання наступного змісту: & (executable= sinsum.sh) (executables= sinsum.py) (inputFiles=( sinsum.py "")( sinsum.xml "")) (stdout=" sinsum.out") (stderr=" sinsum.err") (outputFiles=(" sinsum.out" "")(" sinsum.err" "" )) За допомогою текстового редактору внесемо зміни в файл sinsum.sh, як наведено нижче: #!/bin/bash chmod 777 sinsum.py date python sinsum.py date Крок 2: Створення проксі - сертифікату. Проксі – сертифікат створюється командою grid-proxy-init (у користувача буде запитаний пароль сертифікату): 182 [svistunov@ui nordugrid-arc-standalone-0.8.3-1]$ grid-proxy-init Your identity: /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov Enter GRID pass phrase for this identity: Creating proxy ..................................... Done Your proxy is valid until: Fri Dec 17 03:28:16 2010 Перевірюємо дійсність створеного проксі-сертифікату командою grid-proxy-info: [svistunov@ui nordugrid-arc-standalone-0.8.3-1]$ grid-proxy-info -all subject : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov/CN=485375392 issuer : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov identity : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov type : RFC 3820 compliant impersonation proxy strength : 512 bits path : /tmp/x509up_u6000 timeleft : 11:59:52 Крок 3: Відправлення завдання на виконання. Запуск завдання на виконання здійснюється командою ngsub: [svistunov@ui nordugrid-arc-standalone-0.8.3-1]$ ngsub -c arc.hpcc.kpi.ua 1.xrsl Job submitted with jobid: gsiftp://arc.hpcc.kpi.ua:2811/jobs/1612412921649682141870065 183 Крок 4: Перевірка стану виконання завдання. Перевірка стану завдання виконується командою ngstat із зазначенням ідентифікатора завдання в якості аргументу: [svistunov@ui nordugrid-arc-standalone-0.8.3-1]$ ngstat gsiftp://arc.hpcc.kpi.ua:2811/jobs/1612412921649682141870065 Job gsiftp://arc.hpcc.kpi.ua:2811/jobs/1612412921649682141870065 Job Name: Example_ARC Status: EXECUTED [svistunov@ui nordugrid-arc-standalone-0.8.3-1]$ ngstat gsiftp://arc.hpcc.kpi.ua:2811/jobs/1612412921649682141870065 Job gsiftp://arc.hpcc.kpi.ua:2811/jobs/1612412921649682141870065 Job Name: Example_ARC Status: FINISHED Exit Code: 0 Після завершення завдання (статус FINISHED) можна переходити до наступного кроку. Крок 5: Копіювання результатів виконання завдання в домашню директорію користувача. Копіювання результатів виконання завдання виконується командою ngget із вказівкою ідентифікатору завдання в якості аргументу: [svistunov@ui nordugrid-arc-standalone-0.8.3-1]$ ngget gsiftp://arc.hpcc.kpi.ua:2811/jobs/1612412921649682141870065 Results stored at /home/localusers/svistunov/nordugrid-arc-standalone0.8.3-1/1612412921649682141870065 Jobs processed: 1, successfuly downloaded: 1 184 Крок 6: Перегляд результатів виконання завдання Як вказано у попередньому кроці результати виконання завдання збережені в директорії /home/localusers/svistunov/nordugrid-arc-standalone-0.8.31/1612412921649682141870065. У файлі sinsum.out знаходиться результат виконання. Такими є його перші 1000 символів: Результати розрахунків для двох значень x=0.01 та x=0.1 мають вигляд x=0.01, sin(x)=0.00999983 n=1 0.01 (next term: -1.666666666667e-07 error: -1.666658333357e-07) n=2 0.00999983 (next term: -8.333333333333e-13 error: 8.333316675602e-13) n=5 0.00999983 (next term: -2.505210838544e-30 error: 0.000000000000e+00) n=10 0.00999983 (next term: -1.957294106339e-62 error: 0.000000000000e+00) n=25 0.00999983 (next term: -6.446959640457e-169 error: 0.000000000000e+00) n=50 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=75 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=100 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=250 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=500 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) x=0.1, sin(x)=0.0998334 n=1 0.1 (next term: -1.666666666667e-04 error: -1.665833531719e-04) n=2 0.0998333 (next term: -8.333333333333e-08 error: 8.331349481139e-08) n=5 0.0998334 (next term: -2.505210838544e-19 error: -1.387778780781e-17) n=10 0.0998334 (next term: -1.957294106339e-41 error: -1.387778780781e-17) n=25 0.0998334 (next term: -6.446959640457e-118 error: -1.387778780781e-17) n=50 0.0998334 (next term: -1.060901275372e-261 error: -1.387778780781e-17) n=75 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) n=100 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) n=250 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) n=500 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) 185 Виконав порівняння з результатами, які були отримано при виконанні другої лабораторної роботи, переконуємося в ідентичності отриманих значень. Крок 6: Віддалення проксі-сертифікату Після завершення роботи необхідно виконати команду grid-proxydestroy, яка знищує проксі-сертифікат користувача. [svistunov@ui nordugrid-arc-standalone-0.8.3-1]$ grid-proxy-destroy 1. 4.8 Завдання до лабораторної роботи Розробити файл завдання на мові xRSL для виконання у навчальній грід-інфрастуктурі під керування проміжного програмного забезпечення ARC програми, яка була розроблена в другій лабораторної роботи згідно варіанта студента. 2. Створити проксі-сертифікат. 3. Відправити завдання на виконання у навчальну грід- інфраструктуру . 4. Під час виконання завдання перевірити її стан. 5. Скопіювати результати виконання завдання в домашню директорію. 6. Порівняти отримані результати з результатами, які були отримані в другій лабораторної роботи. Порівняти час виконання завдання. 7. Скласти протокол виконання лабораторної роботи. Протокол повинен містити: опис завдання на мові xRSL, скріншоти виконання команд інтерфейсу користувача при відправленні завдання виконання та перевірки його стану та результатів розрахунків. 186 на 1. 4.9. Контрольні питання Філософія розробки ARC. 2. Архітектура проміжного програмного забезпечення ARC. Функції, які виконують основні компоненти. 3. Сервіс обчислення ARC. Основні компоненти і функції. 4. Сесійна директорія . Призначення, алгоритм роботи. 5. Статуси завдання в ARC. Стислий опис кожного статусу. 6. Інтерфейс користувача в ARC. Основні компоненти і функції. 7. Інформаційна система ARC. Основні компоненти і функції. 8. Забезпечення безпеки в ARC. 9. Мова опису завдання в ARC. 10. Основні команди інтерфейсу користувача в ARC. 11. Послідовність дій користувача з виконання завдання в ARC. Література 1. Introduction to Grid Computing, December 2005, -IBM Redbook, www.ibm.com/redbooks - 241 c. 2. Grid Computing in Research and Education, April 2005, - IBM Redbook, www.ibm.com/redbooks - 145 c. 3. NorduGrid project. http://www.nordugrid.org 4. The NorduGrid Grid Manager And GridFTP Server: Description And Administrator‘s Manual. http://www.nordugrid.org/papers.html 5. The NorduGrid Brokering Algorithm, M.Ellert, http://www.nordugrid.org/papers.html 6. xRSL (Extended Resource Specification Language), O.Smirnova, http://www.nordugrid.org/papers.html 7. Usage statistics and usage patterns on the NorduGrid, K.Pajchel, http://www.nordugrid.org/papers.html 187 8. ARC User Interface: User‘s Manual http://www.nordugrid.org/documents/NorduGrid-UI.pdf 9. The NorduGrid ‖Smart‖ Storage Element, A.Konstantinov, http://www.nordugrid.org/papers.html 10. The NorduGrid/ARC Information System, (Technical Description and Reference Manual), Balázs Kónya, http://www.nordugrid.org/papers.html 188 Завдання №5. Проміжне програмне забезпечення грід - gLite Мета: вивчення технології віддаленого доступу до грід-ресурсів, які працюють під управління проміжного програмного забезпечення gLite та набуття практичних навичок виконання завдань з використанням грід-ресурсів. 5 Короткі теоретичні відомості Грід – це територіально розподілене програмно-апаратне комп'ютерне середовище із принципово новою організацією обчислень та управління потоками інфраструктура завдань призначена і для даних. Така об'єднання комп'ютерна обчислювальних потужностей різних організацій. Найважливішим компонентом грідінфраструктури є проміжне програмне забезпечення (middleware), яке призначене для управління завданнями, забезпечення доступу до даних великого обсягу в універсальному просторі імен, швидкого переміщування і тиражування даних з одного географічно віддаленого обчислювального вузла на інший і організації синхронізації копій. Програмне забезпечення проміжного рівня gLite було розроблено в рамках проекту EGEE (www.eu-egee.org), і перша версія була введена в промислову експлуатацію у 2004 році. Рис.5.1. Історія створення ППЗ gLite 189 В наступних фазах проекту EGEE-II, EGEE-III на основі досвіду експлуатації були внесені зміни та доповнення у промислову версію gLite 3.0. На даний час використовуються дві версії gLite 3.1 та gLite 3.2, які в цілому збігаються за архітектурою і відрізняються тільки синтаксисом команд. В даному лабораторному практикумі розглядається робота з проміжним програмним забезпеченням gLite версії 3.1. 5.1. Архітектура та основні компоненти GLITE У цій частині будуть розглянуті лише концептуальні основи, на яких побудовані основні підсистеми проміжного програмного забезпечення gLite. Додаткову інформацію щодо програмної реалізації підсистем, питань інсталяції та конфігурування сервісів можна отримати в офіційної документації на сайті http://glite.web.cern.ch. В загальному вигляді промислова грід-система включає наступні основні структурні компоненти:  сукупність комп'ютерів зі встановленими на них інтерфейсами користувачів;  сукупність ресурсних центрів;  набір базових грід-сервісів. Ресурсний центр забезпечує працездатність двох типи ресурсів (або одного з них):  обчислювального ресурсу, на якому виконується завдання користувачів з обчислювальний обробці даних. ресурс в Сервіс, який представляє грід-інфраструктурі, називається обчислювальним елементом (Computing Element, CE);  ресурсу зберігання даних, який забезпечує зберігання даних та передачу даних між аналогічними ресурсами і/або вибраним ресурсом і 190 користувачем. Сервіс, який представляє ресурс зберігання даних в грідінфраструктурі, називається елементом зберігання (Storage Element, SE). Проміжне програмне забезпечення gLite складається з наступних сервісів:  інтерфейс користувача (User Interface, UI), який забезпечує доступ користувача до грід – ресурсів;  підсистема управління завантаженням грід – ресурсів (Workload Management System, WMS), яка призначена для обробки запитів на виконання завдань, пошуку відповідних ресурсів і контролю виконання завдань;  підсистема управління даними (Data Management System, DM), яка призначена для обробки запитів на зберігання та передачу даних. До основних служб цієї підсистеми відносяться служби каталогів:  o служба файлових каталогів; o служба каталогу сервісів; підсистема інформаційного обслуговування і моніторингу (Information System, IS), яка забезпечує зберігання та відображення інформації про стан грід-ресурсів, про стан виконання завдань та іншої інформації стосовно грід-ресурсів;  підсистема безпеки і контролю прав доступу (Grid Security Infrastructure, GSI), яка забезпечує безпечний та конфіденційний доступ до грід-ресурсів. До основних служб цієї підсистеми сертифікатів (Certificate відносяться: o служба видачі і підтримки Authority, CA); o служба реєстрації віртуальних організацій і користувачів; 191 o служба управління віртуальними організаціями і видачі проксі-сертификатів (Virtual Organization Membership Service, VOMS); o служба продовження дії проксі-сертифікату (MyProxy Service, MP);  підсистема протоколювання (Logging and Bookkeeping, LB), яка призначена для зберігання поточної інформації про події в грід – системі та відслідкування стану завдань, які виконуються;  підсистема обліку (Accounting Subsystem, AS), яка призначена для обліку використання грід - ресурсів. Сервіси gLite доступні користувачеві через інтерфейс командного рядка (Command Line Interface, CLI), який і будемо розглядати у наступних розділах. Інший тип інтерфейсу - графічний (Graphical User Interface, GUI), як правило, надається порталами і не входить у дистрибутивний пакет gLite. Третій тип - інтерфейс програмного доступу (Application використовується Programming розробниками Interface, API) прикладного в основному програмного забезпечення та адміністраторами грід – ресурсів. Тепер перейдемо до розгляду основних підсистем. Підсистема управління завантаженням (Workload Management System) Ця підсистема відповідає за обробку запитів на виконання завдань, пошук відповідних ресурсів і контроль виконання завдання. Взаємодія з підсистемою WMS здійснюється за допомогою інтерфейсу користувача (UI), який дозволяє надсилати відповідні команди та виконувати запити до всіх підсистем. 192 Основними операціями, які виконуються за допомогою інтерфейсу користувача, є:  формування і отримання списку ресурсів, необхідних для виконання певного завдання;  відправка завдання для виконання на обчислювальний ресурс;  перевірка стану виконання завдання;  відміна виконання завдань;  копіювання файлів результатів виконання завдання;  отримання облікової інформації про завдання, що виконувались (тривалість використання ресурсів, вартість виконання завдання і так далі);  отримання інформації про стан виконання завдання в контрольних точках (для відповідної категорії завдань);  виконання інтерактивних завдань за допомогою спеціального модуля-слухача (listener). Завдання на виконання користувач формує на мові опису завдань (Job Description Language, JDL), яка представляє собою опис вимог до виконання завдання і буде розглянута в цьому розділі пізніше. Компонентами підсистеми управління завантаженням (WMS), приведеної на рис. 5.1, є:  Мережевий сервер (NS - Network Server) і проксі-менеджер завантаження (WMProxy) ;  Менеджер робочого навантаження (WM -Workload Manager);  Брокер ресурсів (RB - Resource Broker);  Контролер завдань (JC - Job Controller);  Адаптер завдань – (CondorC/DAGMan);  Реєстрація і протоколювання (LB - Logging and Bookkeeping); 193  Монітор лог-файлів ( LM - Log Monitor). Рис.5.1 - Архітектура WMS Мережевий Сервер (Network server, NS) - загальний мережевий демон, що забезпечує підтримку контролю завдань, які надходять на виконання. Він відповідає за прийом запитів, що надходять від WMS-UI (наприклад, виконання завдання, видалення завдання) та, якщо запити є коректними за синтаксисом, направляє запити до Workload Manager. Проксі-Менеджер (Workload Manager Proxy, WMProxy) забезпечує доступ до функціональних можливостей WMS через інтерфейс веб-сервісів. Крім того, він забезпечує одночасну підтримку великої кількості залежних підзавдань і підтримку загальнодоступних і додаткових файлів «пісочниць» для завдань, які складаються з декілька незалежних підзавдань. Менеджер робочого навантаження (Workload Manager, WM) основний компонент WMS, який відповідає за обробку запитів. Для обчислювальних завдань існують два основних типи запитів: відправка на виконання та відміна виконання завдання. Для запиту на виконання завдання WM за отриманою інформацією від брокера ресурсів (Resource 194 Broker, RB), який і відповідає за пошук ресурсів, передає завдання відповідному обчислювальному елементу (Computing element, CE). Брокер ресурсів (Resource Broker, RB) - один з важливих модулів який бере участь у прийнятті менеджером робочого навантаження рішення про відправку завдання на обраний обчислювальний ресурс. Брокер ресурсів забезпечує підбор обчислювальних ресурсів на основі: опису завдання; поточного стану завантаження грід-системи; обраної політики розподілу завдань за ресурсами. Брокер ресурсів може реалізовувати різні політики призначення завдання ресурсу. Для так званого «нетерплячого планування» ресурси, які задовольняють вимогам завдання, підбираються якомога швидше і завдання відправляється на обчислювальні ресурси. В іншому варіанті політики планування («ледача політика планування») завдання перебувають в черзі на WM, поки який-небудь ресурс не стає доступним. Потім вільному ресурсу підбирається найбільш відповідне завдання з тих, яки очікують на виконання, і далі менеджер робочого навантаження відправляє завдання цьому ресурсу для виконання. Інформаційний супермаркет (Information Super Market, ISM) входить в склад менеджера робочого навантаження і реалізує різні політики призначення завдання ресурсу на основі інформації про характеристики ресурсів та поточної інформації про завантаження ресурсів. Інформаційний супермаркет складається зі сховища даних про ресурси, що є доступним для читання брокером. Формування актуальної інформації про поточний стан ресурсів виконується за допомогою активного опитування ресурсів та реєстрації повідомлень від ресурсів. Інший фундаментальний компонент внутрішнього дизайну менеджера робочого навантаження - Черга завдань (Task Queue, TQ), 195 яка надає можливість якийсь час зберігати запит на виконання, якщо ресурси, які відповідають вимогам завдання, не доступні для прийому завдань. Запити на виконання, для яких не вдалося відразу підібрати ресурси, будуть повторно направлятися на обробку або періодично (при «нетерплячому плануванні», push-модель), або після отримання інформаційним супермаркетом повідомлення від ресурсу про наявність доступних процесорів для виконання завдань (при «ледачій політиці планування», pull-модель). Наступним компонентом WMS, який бере участь у циклі обробки запиту на виконання завдання, є Адаптер завдань (Job Adapter, JA). Адаптер завдань забезпечує остаточну підготовку JDL-опису завдання перед його передачею в CondorC для фактичного направлення на виконання на обчислювальний елемент. Крім обробки JDL- файлу для CondorC цей модуль також відповідає за створення скрипту для завдання, в якому записано всі відповідні інструкції для створення середовища виконання на робочому вузлі обчислювального елемента. CondorC - модуль, відповідальний за виконання фактичних операцій з управління завданнями (відправка на виконання, відміна виконання та інші). DAGMan (Manager DAG) – мета-планувальник, основне завдання якого полягає в управлінні графом залежних підзавдань (DAG запитом) та в контролі за всіма етапами виконанням складного завдання. Монітор лог-файлів (Log Monitor, LM) – модуль, відповідальний за перегляд журналу CondorC і перехоплення подій, пов‘язаних з поточними завданнями, тобто подій, які стосуються змін станів завдання (наприклад, виконане завдання, скасоване завдання та інші). 196 Служба поновлення проксі-сертифікату забезпечує наявність проксі-сертифікату для всього циклу виконання завдання. Ця служба базується на службі MyProxy (буде розглянута окремо). Служба реєстрації і протоколювання (Logging and Bookkeeping, LB) забезпечує моніторинг виконання завдання. Вона зберігає реєстраційну й облікову інформацію щодо подій, які генеруються різними компонентами WMS. Користувач може отримати інформацію про стани виконання його завдання за допомогою відповідних команд інтерфейсу користувача. Крім активних запитів про стан завдання користувач може також зареєструватися для того, щоб одержувати повідомлення про зміни в стані завдань (наприклад, про закінчення виконання завдання). Всі компоненти підсистеми управління завантаженням взаємодіють з службою протоколювання для реєстрації інформації про завдання, які вони обробляють. Це дозволяє користувачам запитувати й одержувати інформацію про завдання. Крім того, під час фази підбора ресурсів Брокер ресурсів взаємодіє з каталогами підсистеми управління даними для пошуку місця розташування файлів, визначених у списку вхідних даних в описі завдання. Отримання інформація про місце розташування файлів дозволяє спрямувати завдання на обчислювальний ресурс, який розташовано ближче до ресурсу зберігання даних, на якому зберігаються файли, необхідні для виконання завдання, або будуть зберігатися результати виконання завдання. Підсистема управління завантаженням також побічно взаємодіє з VOMS, оскільки вона утримує інформацію про віртуальні організації і групи, до яких належить власник проксі-сертифікату, створеного VOMS, щоб правильно ідентифікувати користувача і надати відповідний доступ до грід-ресурсів. Компонент поновлення дії проксі197 сертифікату контактує зі службою MyProxy для автоматичного відновлення дії проксі-сертифікату для довготривалих завдань. Нарешті (але не в останню чергу) підсистема управління завантаженням взаємодіє з обчислювальними елементами для відправки завдання на виконання (це робить CondorC) і для того, щоб одержувати синхронні/асинхронні повідомлення про стан ресурсів і їх характеристики. Обчислювальний елемент Обчислювальний елемент (Computing Element, CE) - це сервіс, який представляє обчислювальні ресурси даного грід-вузлу і виконує функції управління виконанням завданнями (запуск, відміну виконання і так далі). З програмної точки зору обчислювальний елемент містить компоненти, які є інтерфейсом між менеджером грід-ресурсів і локальною системою управління обчислювальними ресурсами (PBS, LSF та інші). Обчислювальний елемент виконує наступні основні функції:  проводить взаємну аутентифікацію з клієнтом;  аналізує запит, сформований на мові опису завдань;  відображає клієнтський запит на обліковий запис формального локального користувача, права якого відповідають локальній політиці обчислювального ресурсу і правам грід-користувача, який є власником завдання;  відправляє завдання на виконання і проводить його подальший моніторинг, повідомляючи клієнта про помилки, завершення завдання і інші події. Окрім функцій управління завданнями обчислювальний елемент також надає інформацію про поточний стан ресурсів. У push-моделі 198 поточний стан ресурсів публікується в інформаційної службі, і вона використовується підсистемою управління завантаженням для вибору обчислювального елементу, на якому буде виконуватись завдання. У pull-моделі ця інформація пересилається підсистемі управління завантаженням в повідомленні, головним змістом якого є те, що "обчислювальний елемент доступний і готовий прийняти нове завдання". Підсистема управління даними Прикладне завдання має бути в змозі звернутися до своїх даних, незалежно від фактичного розташування обчислювального ресурсу. Необхідно забезпечити доступ до систем зберігання різного типу, які встановлені і використовуються в ресурсних центрах – від простих файлових систем до пристроїв масового зберігання даних. Щоб не мати справи з особливостями кожного індивідуального пристрою зберігання даних, кожен включений в грід-інфраструктуру ресурс зберігання даних повинен підтримувати стандартний інтерфейс. В даний час найбільш поширеним інтерфейсом є менеджер ресурсів зберігання даних (Storage Resource Manager, SRM). При управлінні даними в грід-системі головним чином мають справу з файлами. Зберігання даних у вигляді файлів є типовим в наукових дослідженнях і є зручним в багатьох інших випадках, коли треба обробляти дуже великі об'єми даних. Підсистема управління даними (Data Management Subsystem, DM) включає три сервіси, яки підтримують доступ до файлів:  ресурс зберігання даних (Storage Element, SE);  сервіс каталогів (Catalog Services, CS);  планувальник передачі даних (Data Scheduler, DS). 199 У розподіленому грід-середовищі файли користувача можуть зберігатися в безлічі екземплярів (реплікацій), які розміщені на різних ресурсах зберігання даних. Завдання сервісу каталогів і планувальника передачі даних полягає в тому, щоб зробити процес управління реплікаціями прозорим для користувача і щоб прикладні програми мали доступ до файлів за їх глобальними для всього грід іменами або за дескрипторами метаданих. Іншими словами, хоча реально доступ до файлів відбувається на одному з ресурсів зберігання даних, які входять до складу грід-системи, підсистема управління даними забезпечує глобальну файлову систему в масштабах всього грід (концепція віртуалізації наборів даних). Захист файлів від несанкціонованого доступу забезпечується підсистемою безпеки і контролю прав доступу, зокрема, за допомогою списків контролю доступу (Access Control List, ACL). В ресурсному центрі сервіс, який відповідає за зберігання даних зветься елементом зберігання (Storage Element, SE) і складається з:  пристроїв зберігання зі всіма відповідними апаратними засобами і драйверами;  реалізації інтерфейсу SRM;  служби передачі даних для набору транспортних протоколів;  служби введення/виводу файлів;  модулів взаємодії з підсистемами реєстрації і безпеки. Прикладні завдання користувача під час виконання на обчислювальному елементі використовують безпосередньо службу введення/виводу для доступу до своїх даних на пристрої зберігання, інтерфейс SRM і службу безпеки. Служба передачі файлів (File Transfer service, FTS) управляє потоками даних. За функціональністю 200 вона аналогічна службі управління пакетними завданнями обчислювального ресурсу. Ресурс зберігання, на який передаються дані, завжди є локальним для даного екземпляра служби передачі, при цьому ресурс зберігання - джерело даних може бути всередині або поза межами даного ресурсного центру. Служба передачі файлів в gLite складається з наступних компонентів:  служба розміщення файлів - отримує і зберігає всі запити про передачу даних в своїй базі даних. Користувачі взаємодіють із службою передачі виключно через клієнтів цієї служби;  агент передачі - опитує базу даних служби розміщення про доступні передачі, для яких ресурс зберігання, керований цим агентом, є пунктом призначення;  бібліотека передачі файлів - забезпечує рівень управління поверх спеціалізованих грід-протоколів передачі даних. Вона може контролювати стан передачі і має можливість відмінити її. В грід-інфраструктурі використовуються глобальні каталоги, які дозволяють шукати файли і управляти файлами і їх реплікаціями в масштабах всього грід, створюючи тим самим віртуальну файлову систему. Концептуально, розрізняють каталог метаданих (Metadata Catalog, МС), файловий каталог (File Catalog, FC), каталог реплікацій (Replica Catalog, RC) і об'єднаний каталог. Каталог метаданих забезпечує операції запису і отримання результатів запитів про метадані. Метадані – це дані про дані, тобто вони повинні на щось посилатися, про що мають додаткову інформацію. В даному випадку метадані посилаються на логічні імена файлів. Метадані дуже залежать від специфіки прикладної галузі. Тому загальний каталог повинен містити вельми обмежений набір метаданих, 201 але мати інтерфейси до каталогів метаданих конкретних віртуальних організацій. Файловий каталог надає можливість проводити дії над логічними іменами файлів. Такими діями можуть бути створення директорій, перейменування файлів і створення символічних посилань. Каталог реплікацій забезпечує операції, пов'язані з дублюванням (реплікацією) файлів в грід. Зокрема, він забезпечує додавання і видалення копій (реплікацій) файлів на різних ресурсах зберігання даних. Об'єднаний каталог забезпечує всі операції, які потребують синхронізованого доступу принаймні до двох каталогів, типу створення віртуальних (логічних) директорій, створення і видалення нових файлів. Каталоги повинні підтримувати масові операції з файлами (операції над сукупністю файлів) як частину свого інтерфейсу. Такі операції збільшують продуктивність і оптимізують взаємодію користувачів з грід-службами. Підсистема інформаційного обслуговування і моніторингу Підсистема інформаційного обслуговування і моніторингу вирішує задачу збору і управління даними про поточний стан грід ресурсів, отримуючи інформацію від безлічі розподілених джерел – постачальників. Підсистема призначена для постійного контролю функціонування грід-системи і забезпечення своєчасного реагування на виникаючі проблеми. Інформаційні системи загального призначення (бази даних і сервіси директорій) не підходять для використання в системі розподіленого моніторингу. Дані про стан обробки завдань та дані про поточний стан грід-ресурсів мають короткий час своєї актуальності 202 після чого вони стають недостовірними. Тому частота їх оновлень має бути високою, тоді як звичайні бази даних оптимізовані на обробку запитів, а не на оновлення інформації, яка зберігається. У інформаційній системі грід повинна бути забезпечена дуже мала затримка при передачі даних від місця отримання даних до місця, де вони зберігаються. У свою чергу, приймаюча сторона повинна підтримувати високу швидкість прийому, обумовлену частими оновленнями. Архітектура інформаційної системи з такими властивостями (Grid Monitoring Architecture, GMA) була запропонована в проекті Globus. В системі моніторингу GMA реалізовано функціональний розділ збору даних і операцій пошуку даних. Дані моніторингу зберігаються розподілено – там же, де і виконується їх збір. Оскільки сумарний об'єм даних дуже великий, для оптимізації пошуку даних за всім інформаційним масивом було запропоновано адресувати пошукові запити «реєстру метаданих», який є індексом розподіленого зберігання і дозволяє визначити джерело зберігання необхідних даних. Далі запит переадресується до місця зберігання і там проводиться пошук. Підсистема безпеки і контролю прав доступу. Підсистема безпеки і контролю прав доступу забезпечує безпечний доступ до ресурсів в незахищених мережах Інтернет з урахуванням прав користувача і правил обслуговування користувачів ресурсним центром (такі правила часто називають "локальною політикою"). Практично в усіх великих грід - системах робота цієї підсистеми заснована на інфраструктурі безпеки грід (Grid Security Infrastructure, GSI), яка розроблена Globus Alliance. Підсистема надає такі сервіси, як аутентифікація, конфіденційність передачі інформації і делегування прав. Під делегуванням прав мається на увазі, що 203 користувачеві треба лише один раз пройти процедуру аутентифікації, а далі система сама потурбується про те, щоб аутентифіцировать його на усіх ресурсах, якими він збирається скористатися. GSI, у свою чергу, заснована на надійній і широко використовуваній технології відкритих криптографічних ключів (Public Key Infrastructure PKI). Підсистема протоколювання Підсистема протоколювання (Logging and Bookkeeping, LB) відстежує кроки обробки завдань, процес виконання завдань в грідсистеми, фіксує події (відправку на виконання, призначення відповідного обчислювального ресурсу завданню, початок виконання і так далі), пов‘язані з завданням. Підсистема протоколювання збирає і обробляє повідомлення про події від різних компонентів підсистеми управління завантаженням для представлення узагальненого поточного стану завдання. Користувач не бере участі в зборі даних від компонентів підсистеми управління завантаженням і просто звертається до підсистеми протоколювання за необхідною інформацією. Підсистема протоколювання надає інтерфейси для запитів інформації про завдання, а також для реєстрації запитів на отримання повідомлень про зміни стану завдань. Підсистема протоколювання підтримує два типи запитів: запити про стан завдань, які повертають детальний опис станів певної кількості завдань, і запити про події, які повертають інформацію про події, що отримала LB від компонентів WMS. Як правило, запити про завдання використовуються, щоб прослідкувати штатну обробку завдань; запити про події використовуються, головним прослідкувати аварійну поведінку. 204 чином, для того, щоб Інший спосіб протоколювання – взаємодії користувачів реєстрація для з підсистемою отримання повідомлень. Використовуючи клієнт повідомлень, користувач реєструється на сервері підсистеми протоколювання для отримання повідомлень. При цьому він повинен визначити умови, при яких надсилаються повідомлення. Запит на реєстрацію надсилається серверу підсистеми протоколювання так само, як синхронні запити, і зберігається там. У відповідь сервер указує унікальний ідентифікаційний номер запиту на повідомлення, за допомогою якого користувач надалі може звертатися до цього сервера, наприклад, для зміни умов, які викликають повідомлення, продовження періоду дії реєстрації або її відміни і навіть для зміни адресата повідомлень. Інформація про завдання, які зберігається на сервері підсистеми протоколювання, доступна лише для власника завдання і для тих користувачів, яких власник вказав в спеціальному списку контролю доступу (Access Control List, ACL). Користувачі в ACL можуть бути визначені безпосередньо за їх іменами (вказаними в їх сертифікатах) або за назвами груп віртуальних організацій (або за названими цілих ВО). Підсистема обліку До теперішнього часу існуючі грід-системи використовувалися для наукових досліджень, в яких ресурси надавалися науководослідними організаціями в сумісне використання для досягнення загальних некомерційних цілей. Тому детальний облік використання ресурсів не був першочерговим завданням. Проте з переходом грідсистем до повнофункціонального обслуговування різних груп користувачів питання про облік використання грід-ресурсів стає вельми 205 актуальним, зокрема, і у зв'язку з можливим введенням оплати (у тій або іншій формі) за використання ресурсів. Програмне забезпечення підсистеми обліку DGAS (DataGrid Accounting System) gLite не має центрального архіву облікової інформації. Облікова інформація розподілена між незалежними серверами обліку, які ведуть записи обліку груп користувачів і грідресурсів. Підсистема обліку складається з трьох компонентів:  служби реєстрації користувачів і ресурсів, а також зберігання облікової інформації;  служби формування ціни;  служби збору інформації про використання ресурсів. Постійно працюючі агенти служби збору інформації про використання ресурсів встановлюються на обчислювальні елементи і елементи зберігання даних. Служба реєстрації користувачів і ресурсів та зберігання облікової інформації (Home Location Register, HLR) відповідає за зберігання обліковій інформації. Вона отримує облікову інформацію (так звані, звіти про використання) від служби збору інформації і зберігає її для обслуговування подальших запитів. Інформація, отримана від служби реєстрації користувачів і ресурсів, може бути відсортована за різними критеріями, наприклад, за користувачами, ресурсами, або за виконаними завданнями. Звіти про використання ресурсів є основою для подальшого підрахунку (разом із службою формування ціни) вартості завдання для можливих взаєморозрахунків користувачів і провайдерів ресурсів. Окрім загальної інформації про облікові записи користувачів і ресурсів сервер HLR зберігає інформацію про використання ресурсів кожним із завдань, пов'язаних з обліковими записами ресурсу і/або користувача. 206 Служба формування ціни (Price Authority, PA) визначає ціну за використання грід- ресурсів в межах свого адміністративного домену. Ціни, які зберігаються в ціновій базі даних, можуть призначатися вручну або з використанням різних динамічних алгоритмів оцінки. 5.2 Система управління завданнями Для грід-користувача обчислювальна діяльність в грід- інфраструктурі виглядає наступним чином: він відправляє завдання на виконання, завдання доставляється на обчислювальний ресурс із загального ресурсного пула грід, завдання виконується, а результати виконання копіюються користувачем на комп‘ютер, з якого здійснювалася відправка. Реалізовані в системі управління завданнями технології підтримують розподілену обробку, забезпечуючи: автоматичне виділення обчислювальних ресурсів, які задовольняють вимогам завдання; переміщення програм, вхідних і діагностичних файлів; створення середовища виконання, на ресурсі якого буде виконуватися завдання. Форми діяльності користувача в грід і на окремому комп'ютері відрізняються в декількох аспектах. 1. Програмний код завдання виконується на обчислювальному ресурсі без участі користувача (у пакетному режимі). Сам код програми зазвичай не вимагає адаптації до умов грід. У деяких випадках може знадобитися його доповнення прологом/епілогом, які виконують підготовчі/завершальні операції, наприклад, доставку даних для обробки. 2. Завдання надаються системі управління завданнями у вигляді формалізованого опису, складеного мовою JDL (Job Description Language). 207 3. Ресурси грід використаються колективно безліччю користувачів, тому завдання не обов'язково починає виконуватися відразу після запуску: воно може чекати звільнення ресурсів, зайнятих іншими завданнями. Завдання, які очікують на ресурси, зберігаються в чергах. 4. Перед тим, як почати працювати з системою gLite, користувач повинен згенерувати тимчасовий проксі-сертифікат за допомогою команди voms-proxy-init. Типовий сеанс роботи користувача в грід-инфраструктурі представлений на рис.5.2. 1. Отримати доступ до клієнтського інтерфейсу ППЗГ Вхід Так Є дійсний сертифікат ? 2.б. Згенерувати проксі-сертифікат 3. Сформувати файл опису задачі Р Ні о 2.а. Отримати сертифікат у центрі сертифікації 4. Запустити задачу на виконання б о 5. Перевірити статус задачі т а Типовий сеанс роботи в Грід Завершено ? Так у 7. Знищити проксісертифікат г р Вихід Ні 6. Вивантажити результати Так Ні Закінчити сеанс? і Рис.5.2 - Типовий сеанс роботи користувача в грід-інфраструктурі д З точки зору системи управління завданнями завдання переходить зі стану в стан від початку обробки до завершення. На рис.5.3 показані стани завдання. Користувач має можливість відслідковувати стан 208 завдання командами запиту з інтерфейсу користувача до інформаційної системи. Нижче наведене пояснення кожного можливого стану завдань: Рис.5.3 - Стани завдання в процесі його обробки  SUBMITTED – завдання відправлено користувачем за відповідною командою на виконання, але ще не передано для обробки Мережевому Серверу (NS).  WAITING – завдання було прийнято мережевим сервером і чекає обробки менеджером завантаження, або обробляється допоміжними модулями менеджера робочого навантаження.  READY – завдання було оброблено менеджером робочого навантаження і його допоміжними модулями (зокрема, що відповідні за знаходження обчислювального елементу), але ще не було відправлено на обчислювальний елемент (локальну пакетну системну чергу) через контролер завдань і CondorС. Цей стан не існує для DAG завдань, оскільки для DAG завдань проводиться підбір ресурсів тільки для його 209 вершин, і завдання відразу передається безпосередньо менеджеру DAGMan.  SCHEDULED – завдання чекає в черзі на обчислювальному елементі. Цей стан також не існує для DAG, оскільки він безпосередньо не відсилається на обчислювальний елемент (відсилаються завдання, що відповідають його вершинам).  RUNNING – завдання виконується. Для DAG завдань це означає, що DAGMan почав його обробляти.  DONE – виконання завдання закінчене, або CondorС вважає, що воно перебуває в кінцевому стані.  ABORTED – обробка завдання була відмінена управління завданнями системою (наприклад, очікування в черзі виявилося занадто довгим, перевищення ліміту виділення ресурсів, закінчення терміну дії проксі-сертифікату користувача та інше).  CANCELLED – обробка завдання перервана за запитом користувача.  CLEARED – файли результатів виконання завдання були передані користувачеві або віддалені через перевищення часу зберігання тимчасових файлів на обчислювальному елементі. Команди інтерфейсу користувача Для використання грід-ресурсів на комп'ютерах користувачів інсталюється спеціальне програмне забезпечення інтерфейс користувача (User Interface - UI), яке забезпечує взаємодію з грід - середовищем. Користувач взаємодіє з сервісами gLite за допомогою утиліт командного рядка. Інтерфейс користувача надає команди для відправки завдань в грід - систему, запиту стану завдань і кластерів, отримання 210 даних від завершених завдань, переривання завдань і так далі. Також існують засоби для копіювання і видалення файлів в сховищах даних і каталогах реплік. В даному розділі наведено основні команди інтерфейсу користувача системи gLite. Більш детальну інформацію про систему обробки завдань та команди інтерфейсу користувача можна знайти на сайті http://glite.web.cern.ch/glite/documentation/ у розділі «Документація». Основними командами інтерфейсу користувача є:  glite-wms-job-delegate-proxy – делегування проксі –сертифікату до WMProxy та присвоєння відповідного ідентифікатора.  glite-wms-job-list-match <jdl_file> - формування переліку обчислювальних ресурсів, які задовольняють вимогам виконання завдання і на яких авторизовано даного користувача;  glite-wms-job-submit <jdl_file> - відправка завдання на виконання, опис якого міститься у файлі <jdl_file>.  glite-wms-job-cancel <job_Id> - відміна виконання завдання.  glite-wms-job-status <job_Id> - відображення стану виконання завдання.  glite-wms-job-output <job_Id> - копіювання результатів виконання завдання. Повертаючись до особливостей роботи в грід, звернемо увагу на те, що обробка команд виконується різними службами системи управління завданнями, які взаємодіють між собою. У зв'язку із цим виконання команд потребує певного часу. 211 Розглянемо приклади використання кожної з команд. Опис опцій команд наведено в Додатку 7. 1) glite-wms-job-delegate-proxy - делегування проксі –сертифікату до WMProxy та присвоєння відповідного ідентифікатору. Синтаксис цієї команди: glite-wms-job-delegate-proxy -d <dID> де: <dID> - ідентифікатор. Приклад 1. Модель аутентифікації для сервісу WMРroxy визначає наступне: на додаток до діючого проксі-сертификату (користувач повинен створити проксі-сертифікат за допомогою команди voms-proxy-init) користувач повинен делегувати свої повноваження WM proxy-серверу. Користувач може визначити ідентифікатор delegationId, який буде асоційований з призначеним делегуванням за допомогою опції delegationid (скорочено -d). Якщо використовується опція - d, то ім'я делегування зберігається для того, щоб використовуючи команду glitewms-job-submit, можна було отримати ім'я цього делегування, не створюючи нового (необхідно буде вказувати ім'я делегування з опцією – d). В наведеному нижче прикладі створено делегування для WMProxy, використовуючи як ідентифікатор логін користувача, який можна отримати зі змінної оточення $USER: [UPM04@ui ~]$ echo $USER UPM04 [UPM04@ui ~]$ glite-wms-job-delegate-proxy -d $USER 212 Connecting to the service https://wms.euag.org:7443/glite_wms_wmproxy_server ======== glite-wms-job-delegate-proxy Success ============ Your proxy has been successfully delegated to the WMProxy: https://wms.euag.org:7443/glite_wms_wmproxy_server with the delegation identifier: UPM04 Делегування проксі-сертифікату може бути створено за допомогою опції - a, яка визначає автоматичне делегування. Коли використовується ця опція, то немає необхідності викликати glite-wmsjob-delegate-proxy - d <userid>, але в цьому випадку користувач повинні вказуватимете опцію - a при кожному використанні команд glite-wms-job-submit або glite-wms-job-list-match. 2) glite-wms-job-list-match - формування списку ресурсів для виконання завдання користувача Відображає список ідентифікаторів ресурсів (з відповідними рангами, якщо вказана відповідна опція), на яких користувач авторизований і які задовольняють вимогам опису завдання. Синтаксис команди: glite-wms-job-list-match <delegation-opts> [options] <jdl_file> де: <delegation-opts> – опції делегування проксі-сертифікату, які приймають значення: [-d|-a ] [options] - опції команди, які можуть приймати значення: [-version| -help|-config |-debug |-logfile |-noint |-output |- endpoint | -rank| -default-jdl |-vo ]; 213 < jdl_file > - послідовність команд опису завдання або файл, який містить опис завдання. Приклад 2. Перш ніж відправити завдання на виконання корисно перевірити, які обчислювальні ресурси можуть прийняти завдання для виконання. Це можна зробити, використовуючи команду glite-wms-job-list-match. Як ми вже бачили, за допомогою опції -d можна створити делегування і призначити йому ідентифікатор. Оскільки ми використали в якості ідентифікатора призначене для користувача ім'я (отримане з $USER), воно і буде використано в якості значення опції для цієї команди. [UPM04@ui ~]$ glite-wms-job-list-match -d $USER test.jdl Connecting to the service https://wms.euag.org:7443/glite_wms_wmproxy_server COMPUTING ELEMENT IDs LIST The following CE(s) matching your job requirements have been found: *CEId* - ce.euag.org:2119/jobmanager-lcgpbs-gilda - grid-ce0.desy.de:2119/jobmanager-lcgpbs-cms - gw-2.ccc.ucl.ac.uk:2119/jobmanager-sge-default - grid-ce2.desy.de:2119/jobmanager-lcgpbs-cms ================================================= 214 Отриманий список обчислювальних елементів підтверджує, що в JDL файлі опису завдання немає синтаксичних помилок і що завдання може бути виконано на будь-якому обчислювальному ресурсі зі списку. Приклад 3. В наступному прикладі використаємо опцію -a, яка визначає автоматичне делегування, і опцію –rank, яка забезпечить сортування доступних ресурсів згідно рангу. [UPM04@ui ~]$ glite-wms-job-list-match -a --rank test.jdl Connecting to the service https://wms.euag.org:7443/glite_wms_wmproxy_server ==================================================== COMPUTING ELEMENT IDs LIST The following CE(s) matching your job requirements have been found: *CEId* *Rank* - CE.pakgrid.org.pk:2119/jobmanager-lcgpbs-cms 0 - grid-ce0.desy.de:2119/jobmanager-lcgpbs-cms -10 - gw-2.ccc.ucl.ac.uk:2119/jobmanager-sge-default -56 - grid-ce2.desy.de:2119/jobmanager-lcgpbs-cms -107 Також дуже корисно використовувати опцію -o <file path>, яка дозволить зберігати сформований список ресурсів в окремому файлі. 215 3) glite-wms-job-submit – відправлення завдання на грід-ресурси для виконання Ця команда призначена для відправки завдання користувача на виконання в грід-систему і має наступний синтаксис: glite-wms-job-submit <delegation-opts> [options] <jdl_file> де: <delegation-opts> - опції делегування проксі –сертифікату, які приймають значення: [-d|-a ]; [options] - опції команди, які можуть приймати значення: [-version| -help|-input|-endpoint|-resource|-nodes-resource|-nolisten| -nomsg|-lrms|-to|-valid|- register-only|-proto|- start| -output|-noint|- debug| -logfile|-default-jdl|-dag |-jsdl |-pretty-print| -collection |-json | -config |-vo ]; < jdl_file > - послідовність команд опису завдання або файл, який містить опис завдання. Приклад 4. Для того, щоб передати завдання на виконання, системою управління завданнями використовується текстовий файл, який містить команди мови опису завдання (Job Description Language - JDL). JDL описує саме завдання і необхідні вимоги і умови для його виконання. Нижче показаний простий JDL файл (test.jdl) простого завдання в грід: Type = "Job"; JobType = "Normal"; Executable = "/bin/hostname"; StdOutput = "std.out"; StdError = "std.err"; OutputSandbox = {"std.out","std.err"}; 216 для запуску Arguments = "-f"; RetryCount = 7; Атрибут Executable визначає команду, яка буде виконана на обчислювальному вузлі (Worker Node - WN). Атрибут OutputSandbox визначає файли, які користувач хоче отримати назад після виконання завдання. За звичай, це файли, до яких перенаправляється вивід результатів виконання завдання і повідомлення про помилки. Їх імена визначаються атрибутами StdOutput і StdError відповідно. Також у разі якого-небудь збою визначена кількість повторних запусків. [UPM04@ui ~]$ glite-wms-job-submit -a test.jdl If the submission is successful, the output is similar to: Connecting to the service https://wms.euag.org:7443/glite_wms_wmproxy_server ========= glite-wms-job-submit Success ================= The job has been successfully submitted to the WMProxy Your job identifier is: https://lb102.cern.ch:9000/vZKKk3gdBla6RySximq_vQ Примітка. Для відправки завдання на виконання користувач повинен мати дійсний проксі – сертифікат, який потрібно згенерувати за командою voms-proxy-init з зазначенням в якості параметра ідентифікатора віртуальної організації, до якої належіть користувач. Якщо дійсного сертифікату у користувача немає, то як результат виконання команди glite-wms-job-submit буде отримано повідомлення про помилку подібне тому, як наведено нижче: 217 Error - Operation failed Unable to delegate the credential to the endpoint: https://wms104.cern.ch:7443/glite_wms_wmproxy_server User not authorized: unable to check credential permission (/opt/glite/etc/glite_wms_wmproxy.gacl) (credential entry not found) credential type: person input dn: /C=CH/O=CERN/OU=GRID/CN=John Doe В разі успішної присвоюється відправки унікальний завдання на виконання йому ідентифікатор. В прикладі це https://lb102.cern.ch:9000/vZKKk3gdBla6RySximq_vQ В загальному вигляді ідентифікатор має формат: https://<LB_hostname>[:<port>]/<unique_string> Перша частка <LB_hostname>[:<port>] ідентифікатора – це URL серверу LB, який відслідковує інформацію про завдання (реєстрація завдання, стан виконання). Друга частка <unique_string> ідентифікатора – це унікальний номер завдання, який генерується WMS-UI. Така побудова ідентифікатору завдання гарантує його унікальність в грід-системі. Приклад 5. При використанні команди glite-wms-job-submit використовувати опцію дуже корисно -o <file path>, яка дозволить зберігати ідентифікатор завдання в окремому файлі. В прикладі, який наведено нижче, використовується опція -d для делегування: 218 отримання ідентифікатору [UPM04@ui ~]$ glite-wms-job-submit -d $USER -o jobid test.jdl Connecting to the service https://wms.euag.org:7443/glite_wms_wmproxy_server =========lite-wms-job-submit Success ====================== [UPM04@ui ~]$ glite-wms-job-submit -d $USER -o jobid test.jdl Connecting to the service https://wms.euag.org:7443/glite_wms_wmproxy_server ========= glite-wms-job-submit Success =================== The job has been successfully submitted to the WMProxy Your job identifier is: https://wms.euag.org:9000/tcl6gKsrMJm8TReyXcc7tQ The job identifier has been saved in the following file: /home/UPM04/jobid В файлі /home/UPM04/jobid буде записано jodID – ідентифікатор завдання, який присвоюється завданню в грід-системі. Якщо тією же командою буде відправлено на виконання ще одне завдання, то його jobID буде додано у кінець файлу. В подальшому даний файл буде використано для перегляду стану виконання завдань. 219 4) glite- wms-job-status – перегляд стану завдання Ця команда використовується для одержання інформації про стан (статус) завдання і має синтаксис: glite-wms-job-list-status [options] <jobId> де: [options] - опції команди, які можуть приймати значення: [-version| -help|-config|-debug|-logfile |-noint|-input|-output|-all| -config-vo|-verbosity|-from |-to |-user-tag|-status|-exclude|-nonodes ]; < jobId > - ідентифікатор завдання (jobId). Приклад 6. Для отримання інформації про статус конкретного завдання користувача необхідно вказати ідентифікаційний номер завдання, котрий присвоєно завданню брокером ресурсів. Нижче наведено типовий приклад використання команди і інформація про стан завдання, яка виводиться: [UPM04@ui ~]$ glite-wms-job-status https://wms.euag.org:9000/tcl6gKsrMJm8TReyXcc7tQ ****************************************************** BOOKKEEPING INFORMATION: Status info for the Job: https://wms.euag.org:9000/tcl6gKsrMJm8TReyXcc7tQ Current Status: Running Status Reason: Job successfully submitted to Globus Destination: ce.euag.org:2119/jobmanager-lcgpbs-gilda Submitted: Fri Jul 31 05:20:54 2009 UTC ************************************************************* 220 Приклад 7. У тому випадку, якщо ми використали файл jobid для збереження ідентифікаторів завдань (опція - o при запуску), виконання команди відбувається таким чином: [UPM04@ui ~]$ glite-wms-job-status -i jobid -----------------------------------------------------------------1 : https://wms.euag.org:9000/0GSFe8gObmvvyOJOvWx2-A 2 : https://wms.euag.org:9000/DNfFrL9cxnTTHzl9edVCJg 3 : https://wms.euag.org:9000/tcl6gKsrMJm8TReyXcc7tQ a : all q : quit -----------------------------------------------------------------Choose one or more jobId(s) in the list - [1-3]all:3 ******************************************************** BOOKKEEPING INFORMATION Status info for the Job : https://wms.euag.org:9000/tcl6gKsrMJm8TReyXcc7tQ Current Status: Running Status Reason: Job successfully submitted to Globus Destination: ce.euag.org:2119/jobmanager-lcgpbs-gilda Submitted: Fri Jul 31 05:20:54 2009 UTC На підставі інформації про ідентифікатори завдань, які збережені в файлі, виводиться список ідентифікаторів завдань, статус яких може бути запрошений окремо або для усіх завдань відразу. Опція -i визначає ім'я файлу, з якого команда прочитує jobID для контролю статусу. Додатково до статусу завдання, відображається обчислювальний елемент, на якому виконується (виконувалося) завдання. 221 Для DAG завдань інформація про статус видається для кожного простого завдання, яке входить в склад DAG завдання: > glite-wms-job-status https://gundam.cnaf.infn.it:9000/Ah4clHKVD1VMOMVrdkCZw ************************************************************* BOOKKEEPING INFORMATION: Status info for the Job : https://gundam.cnaf.infn.it:9000/Ah4clHKVD1VMOMVrdkCZw Current Status: Ready Status Reason: unavailable Destination: dagman Submitted: Mon Mar 7 17:25:22 2005 CET - Nodes information for: Status info for the Job : https://gundam.cnaf.infn.it:9000/ayNofwCnlus68s3qQvFEA Current Status: Submitted Submitted: Mon Mar 7 17:25:08 2005 CET Parent Job: https://gundam.cnaf.infn.it:9000/Ah4clHKVD1VMOMVrdkCZw ************************************************************* Status info for the Job : https://gundam.cnaf.infn.it:9000/9FfFXd7ИпWuoPSlyqMVZNQ Current Status: Submitted Submitted: Mon Mar 7 17:25:08 2005 CET Parent Job: https://gundam.cnaf.infn.it:9000/Ah4clHKVD1VMOMVrdkCZw ************************************************************* Status info for the Job : 222 https://gundam.cnaf.infn.it:9000/wlgiicvWUe6Br7nbjIxcn Current Status: Submitted Submitted: Mon Mar 7 17:25:08 2005 CET Parent Job: https://gundam.cnaf.infn.it:9000/Ah4clHKVD1VMOMVrdkCZw Як видно, команда glite-wms-job-status дає, в цьому випадку, інформацію про DAG у цілому та про всі його вершини. Можна також одержати інформацію про окрему вершину, використовуючи її власний ідентифікатор. Інформація про події, пов'язані з обробкою окремої вершини DAG, повинна бути окремо запитана (за допомогою цієї ж команди) з явним завданням ідентифікатора вершини. 5) glite-wms-job-output - копіювання вихідних файлів після завершення завдання Команда glite-wms-job-output дозволяє скопіювати на комп'ютер із установленим інтерфейсом користувача файли результатів виконання завдання, які відзначені як вихідні файли в опису завдання. Синтаксис команди: glite-wms-job-output [options] <jobId> де: [options] - опції команди, які можуть приймати значення: [-version| -help|-config| --input |-output|-proto|-config |-vo|-list-only| -nosubdir|-nopurge| -debug| -json|-logfile|-noint|- |-dir]; < jobId > - ідентифікатор завдання (jobId). 223 Приклад 8. Якщо завдання успішно завершилося (статус Done(Success)), то результат виконання може бути отриманий за допомогою команди glitewms-job-output. В цьому випадку також не потрібно вказувати ідентифікатор делегування: [UPM04@ui ~]$ glite-wms-job-output -i jobid -----------------------------------------------------------------1 : https://wms.euag.org:9000/0GSFe8gObmvvyOJOvWx2-A 2 : https://wms.euag.org:9000/DNfFrL9cxnTTHzl9edVCJg 3 : https://wms.euag.org:9000/tcl6gKsrMJm8TReyXcc7tQ a : all q : quit -----------------------------------------------------------------Choose one or more jobId(s) in the list - [1-3]all (use , as separator or for a range): 3 Connecting to the service https://wms.euag.org:7443/glite_wms_wmproxy_server JOB GET OUTPUT OUTCOME Output sandbox files for the job: https://wms.euag.org:9000/tcl6gKsrMJm8TReyXcc7tQ have been successfully retrieved and stored in the directory: /tmp/jobOutput/UPM04_tcl6gKsrMJm8TReyXcc7tQ В результаті виконання команди всі файли результатів виконання завдання скопійовані в директорію /tmp/jobOutput/UPM04_tcl6gKsrMJm8TReyXcc7tQ. 224 Для того, щоб переглянути вміст результатів виконання нашого прикладу, виконаємо наступні команди: [UPM04@ui ~]$ cd /tmp/jobOutput/UPM04_tcl6gKsrMJm8TReyXcc7tQ [UPM04@ui UPM04_tcl6gKsrMJm8TReyXcc7tQ]$ ls –la total 12 drwxr-xr-x 2 UPM04 UPM04 4096 Jul 31 05:51 . drwxrwxrwt 8 root root 4096 Jul 31 05:51 .. -rw-rw-r-- 1 UPM04 UPM04 0 Jul 31 05:51 test.err -rw-rw-r-- 1 UPM04 UPM04 13 Jul 31 05:51 test.out [UPM04@ui UPM04_tcl6gKsrMJm8TReyXcc7tQ]$ cat test.out wnc.euag.org [UPM04@ui UPM04_tcl6gKsrMJm8TReyXcc7tQ]$ Приклад 9. В наведеному нижче прикладі використовується опція -dir для явного визначення директорії, в яку будуть скопійовані результати виконання завдання: [UPM04@ui ~]$ glite-wms-job-output -i jobid --dir jobdir -----------------------------------------------------------------1 : https://wms.euag.org:9000/0GSFe8gObmvvyOJOvWx2-A 2 : https://wms.euag.org:9000/DNfFrL9cxnTTHzl9edVCJg 3 : https://wms.euag.org:9000/tcl6gKsrMJm8TReyXcc7tQ a : all q : quit -----------------------------------------------------------------225 Choose one or more jobId(s) in the list - [1-3]all (use , as separator or for a range): 3 Connecting to the service https://wms.euag.org:7443/glite_wms_wmproxy_server JOB GET OUTPUT OUTCOME Output sandbox files for the job: https://wms.euag.org:9000/tcl6gKsrMJm8TReyXcc7tQ have been successfully retrieved and stored in the directory: /home/UPM04/jobdir 6) glite- wms-job-cancel - відміна виконання завдання Ця команда дозволяє відмінити виконання завдання користувача на будь-якій стадії його обробки в грід-інфраструктурі і має наступний синтаксис: glite-wms-job-cancel [options] <jobId> де: [options] - опції команди, які можуть приймати значення: [-version| -help|-config|-debug|-logfile |-noint|-input|-output|-all|-config| -vo]; < jobId > - ідентифікатор завдання (jobId). Приклад 10. Приклад застосування команди glite-wms-job-cancel дострокового завершення завдання наведено нижче. 226 для $ glite-wms-job-cancel https://wms104.cern.ch:9000/P1c60RFsrIZ9mnBALa7yZA Are you sure you want to remove specified job(s) [y/n]y : y Connecting to the service https://wms.euag.org:7443/glite_wms_wmproxy_server ============= glite-wms-job-cancel Success =============== The cancellation request has been successfully submitted for the following job(s): - https://wms104.cern.ch:9000/P1c60RFsrIZ9mnBALa7yZA 7) glite-wms-job-logging-info – перегляд інформації по раніше відправленим на виконання завданням Ця команда відображає список усіх подій, пов'язаних із відправленим завданням, які були зареєстровані в службі LB компонентами WMS впродовж усього періоду обробки запиту на виконання завдання. Запит на отримання інформації пересилається службі реєстрації і обліку, яка і надає необхідну інформацію. Для завдань типу DAG команда повертає тільки події, пов'язані з завданням в цілому, а не з окремими вершинами (підзавданнями). команди: 227 Синтаксис glite-wms-job-logging-info [options] <jobId> де: [options] - опції команди, яки можуть приймати значення: [-version|-help|-config|-debug|-logfile|-noint|-input|-output|-config-vo| -verbosity|-from|-to|-user-tag|- event|-exclude ]; < jobId > - ідентифікатор завдання (jobId). Якщо процес виконання завдання йде не так, як очікувалося, можливо використати команду glite-wms-job-logging-info, щоб переглянути події, пов'язані із завданням. Результат виконання команди має вигляд ,подібний до даного: > glite- wms-job-logging-info https://wms.hpcc.kpi.ua:9000/mc5arTDgqPJzGWC4EzSfrw ************************************************************* LOGGING INFORMATION: Printing info for the Job : https://wms.hpcc.kpi.ua:9000/mc5arTDgqPJzGWC4EzSfrw -іEvent: RegJob - source = UserInterface - timestamp = Fri Mar 4 18:05:28 2005 CET -іEvent: Transfer - destination = NetworkServer - result = START - source = UserInterface - timestamp = Fri Mar 4 18:05:29 2005 CET -іEvent: Transfer - destination = NetworkServer 228 - result = OK - source = UserInterface - timestamp = Fri Mar 4 18:05:32 2005 CET -іEvent: Accepted - source = NetworkServer - timestamp = Fri Mar 4 18:05:23 2005 CET -іЦе дозволяє перевірити, чи була проблема при обробці завдання компонентами системи управління завданнями і, якщо потрібно, можна в подальшому відмінити виконання завдання. 5.3 Опис завдання Файл опису завдання на мові опису завдання JDL (Job Description Language) є ключовим для відправки завдання в грід і правильного підбору ресурсів. Цей файл описує необхідні вхідні дані, вихідні дані і вимоги до ресурсів. Нижче наведений типовий приклад файлу опису завдання : [ Type = "Job"; JobType = "Normal"; Executable = "myexe"; StdInput = "myinput.txt"; StdOutput = "message.txt"; StdError = "error.txt"; InputSandbox = {"/users/pacini/example/myinput.txt", "/users/pacini/example/myexe"}; OutputSandbox = {"message.txt", "error.txt"}; 229 Requirements = other.GlueCEInfoLRMSType == "PBS"; Rank = other.FreeCPUs; ] Такий JDL- файл забезпечує передачу файлу myexe для виконання на віддалений обчислювальний елемент, на якому встановлена локальна система управління завданнями PBS. використано файл myinput.txt В якості вхідних даних буде Стандартні потоки завдання переадресовуються на робочому обчислювальному вузлі у файл message.txt і error.txt і можуть бути пізніші отримані за допомогою команди glite-wms-job-output. Одне з найважливіших досягнень системи управління завданнями gLite – це реалізація автоматичного розподілу завдань за обчислювальними ресурсами. Розподіл проводиться з врахуванням поточного стану завантаження ресурсу і характеристик ресурсу (число завдань у черзі, архітектура серверів, на яких буде виконуватися завдання та інше). Ці відомості доступні брокеру ресурсів з інформаційної служби gLite. Вибір обчислювальних виконується, виходячи з елементів для виконання завдання двох умов: вимог (Requirements) і рангу (Rank), які задаються користувачем в атрибутах опису завдання. Вимоги визначають підмножину ресурсів, які підходять для виконання. Ранг відображає переваги окремого ресурсу з множини підходящих ресурсів. Атрибут Requirements записується у вигляді булевого виразу. В якості змінних у ньому вказуються атрибути, які представляють обчислювальний елемент в інформаційній системі (у записі їм передує 230 префікс ―other.‖). Завдання може бути відправлено на обчислювальний елемент, якщо значення виразу дорівнює true. Наприклад: Requirements = other.GlueCEInfoLRMSType == "PBS" && other.GlueCEInfoTotalCPUs > 2 ; Цей вираз задає вимоги до обчислювального елементу: потрібна локальна система управління завданнями PBS і кількість потрібних процесорів не менше 2. Атрибут Rank дозволяє визначити, які обчислювальні елементи є кращими для виконання завдання. Він задається арифметичним виразом, який залежить від значень інформаційних атрибутів обчислювального елементу. Завдання буде відправлене на виконання на обчислювальний елемент, якщо: 1) задовольняє вимогам, заданим в атрибуті Requirements і 2) має найвище значення атрибута Rank. Цей атрибут має важливе значення, тому що ним визначається, як довге завдання буде перебувати в локальної черзі на обчислювальному елементі, тобто повний час його обробки. Один з можливих способів завдання Rank: Rank = other.GlueCEPolicyMaxRunningJobs - other.GlueCEStateRunningJobs; Атрибут GlueCEPolicyMaxRunningJobs представляє максимальне число завдань, які можуть одночасно виконуватися на обчислювальному елементі, а GlueCEStateRunningJobs – число завдань, яки в даний час виконуються. Інший спосіб: Rank = -other.GlueCEStateEstimatedResponseTime; 231 Зазначений інформаційний атрибут являє собою оцінку часу очікування завдання в черзі локального планувальника ресурсів до початку виконання. Цей спосіб визначення Rank здається найкращим, однак оцінка часу очікування може бути зроблена дуже приблизно. Атрибут вимог до ресурсу (Requirements) є логічним виразом, який може містити навіть регулярні вирази. Наступний приклад опису вимог це ілюструє: Requirements = (( other.GlueHostOperatingSystemName == "CentOS" || other.GlueHostOperatingSystemName == "RedHatEnterpriseAS" ) && ( other.GlueHostOperatingSystemRelease >= 3.0 && other.GlueHostOperatingSystemRelease < 4.0 ) ) || (( other.GlueHostOperatingSystemName == "Scientific Linux" || other.GlueHostOperatingSystemName == "Scientific Linux CERN" ) && ( RegExp("3\.[0-9]\.[0-9]",other.GlueHostOperatingSystemRelease) ) ); Типи завдання описується двома атрибутами: Type та JobType. Система управляння завданнями підтримує роботу як із простими завданнями, так і зі складними, атрибут Type має, відповідно, значення ―Job‖ або ―DAG‖. Тип DAG (direct acyclic graph of dependent jobs) відповідає завданню, у якому повинна бути виконана впродовж певного часу послідовність простих завдань. 232 Для простого завдання застосуємо другий атрибут – JobType. Воно може бути звичайним (Normal), а також: - інтерактивним (Interactive). Завдання такого роду підтримує зв'язок із точкою запуску; - паралельним (MPICH), тобто таким, яке потребує для виконання декількох процесорів; - з контрольними точками (Checkpointable). Такі завдання зберігають проміжні стани і при необхідності їх можна виконати знову не спочатку, а з якогось із збережених станів; - серілізуючим (Partitionable). Виконується кілька екземплярів одного звичайного завдання, які обробляють різні вихідні набори даних. Перераховані характеристики можуть поєднуватися одна з одною, наприклад, JobType= {―Checkpointable‖, ―MPICH‖}. Прості завдання Оскільки складні завдання базуються на простих, почнемо з останніх і розглянемо атрибути опису стандартних файлів та вибору ресурсів. Система управляння завданнями забезпечує переміщення файлів між комп'ютером користувача і обчислювальним ресурсом, на якому буде виконуватися завдання, але обмежується, мінімально необхідним набором стандартних файлів операційної системи Linux: файлом завдання, який буде виконуватися, вхідними даними, діагностичними повідомленнями і файлом повідомлень про помилки. Трьом останнім файлам відповідають потоки stdin, stdout й stderr, використовуються в застосуваннях заздалегідь визначеним чином. 233 які Вхідні файли (файл завдання, який буде виконуватися, і файл даних), що знаходяться у файловій системі комп'ютера користувача з встановленим інтерфейсом користувача, передаються спочатку на сервер WMS а потім при запуску завдання на обчислювальному вузлі завантажуються в створену для цього завдання домашню директорію. Завантаження виконується скриптом командної оболонки, який генерується Job Adapter і виступає як пролог завдання. Вхідні файли, які копіюються на обчислювальний вузол, повинні бути визначені, поперше, своїми абсолютними іменами в атрибуті JDL-файла InputSandbox, і по-друге, відносними іменами в атрибутах Executable (Executable = "myexe") і StdInput (StdInput = "myinput.txt"). Вихідні файли діагностики і помилок створюються при виконанні завдання в домашній директорії на обчислювальному вузлі і копіюються при завершенні завдання на сервер WMS, звідки їх можна одержати за допомогою команди glite-wms-job-output. Вихідні файли повинні бути визначені в атрибутах OutputSandbox, StdOutput й StdError. Оскільки переміщення файлів відбувається через тимчасовий буфер на сервері WMS, передбачається, що всі вони будуть невеликого розміру. Тим самим, реалізовані засоби доставки файлів спрямовані на мінімально необхідну підтримку віддаленого виконання програм. Що стосується прикладних даних, які обробляються або створюються додатком, то для роботи з ними в програмі повинні використовуватись засоби системи управління даними. 234 Приклад 11. Нижче наведено приклад опису простого завдання, в якому не генеруються вихідні файли, окрім стандартних: [ Type = "job"; JobType = "normal"; Executable = "script.sh"; Arguments = "60"; STDOUTPUT = "SIM.OUT"; StdError = "sim.err"; MyProxyServer = "skurut.cesnet.cz"; OUTPUTSANDBOX = { "sim.err","sim.out"}; InputSandbox = { "/home/fpacini/GUI/sbin/script.sh" }; rank = (other.GlueCEPolicyMaxRunningJobsother.GlueCEStateRunningJobs); requirements = other.GlueCEStateStatus == "Production" ; ] Приклад 12. Нижче наведено приклад опису простого завдання, в якому генерується вихідний файл результатів обчислення: [ Type = "job"; JobType = "normal"; VirtualOrganisation = "cms"; Executable = "test.sh"; Arguments = "1 20000 sim1"; 235 StdInput = "file2"; StdOutput = "sim.out"; StdError = "sim.err"; OutputSandbox = { "sim.out", "sim.err" }; RetryCount = 2; OutputData = { [ // No StorageElement is specified – Close SE is taken OutputFile = "dataset1.out"; LogicalFileName = "lfn:myoutdata.1" ], [ OutputFile = "dataset2.out"; LogicalFileName = "lfn:myoutdata.2" ] }; InputSandbox = { "/home/mytest/JNI/test.sh", "/home/mytest/DATA/file2", "/home/mytest/DATA/sim.dat" }; Environment = "SIM_ROOT=/usr/local/"; rank = other.GlueHostMainMemoryRAMSize; // job is submitted to a CE having a close SE with at least 5GB free requirements = anyMatch( other.storage.CloseSEs, target.GlueSAStateAvailableSpace > 5120); ] 236 Приклад 13. Нижче наведено приклад опису простого завдання, в якому наведено опис вхідних файлів і файлів результатів обчислення: [ Type = "job"; // JobType is not mandatory – If not specified “normal” is the default JobType = "normal"; VirtualOrganisation = "cms"; Executable = "test.sh"; Arguments = "1 20000 sim1"; StdInput = "file2"; StdOutput = "sim.out"; StdError = "sim.err"; OutputSandbox = {"sim.out", "sim.err"}; // disable job re-submission in case of failure RetryCount = 0; InputData = { "lfn:mydatafile1", "lfn:mydatafile2", "guid:135b7b23-4a6a-11d7-87e7-9d101f8c8b70" }; DataAccessProtocol = {"gridftp", "file"}; OutputData = { [ OutputFile = "dataset1.out"; StorageElement = "grid011.pd.infn.it"; LogicalFileName = "lfn:myoutdata.1" ], 237 [ OutputFile = "dataset2.out"; LogicalFileName = "lfn:myoutdata.2" ], [ OutputFile = "dataset3.out" ], [ OutputFile = "dataset4.out"; StorageElement = "grid001.ct.infn.it" ] }; OutputSE = "grid011.pd.infn.it"; InputSandbox = { "/home/fpacini/JNI/test.sh", "/home/fpacini/DATA/file2", "/home/fpacini/DATA/sim.dat", "/home/fpacini/HandsOn-0409/WP1testA" }; // Ranking is done according to cost for accessing InputData rank = other.DataAccessCost; requirements = (other.GlueCEStateFreeCPUs>=2) && (other.GlueCEInfoLRMSType=="lsf") ] 238 Паралельні завдання Система управління завданнями забезпечує обмежену підтримку багато процесорних паралельних завдань, які використовують протокол MPI. Для таких завдань в опису завдання задається атрибут NodeNumber, який визначає число необхідних процесорів. Крім того до виразу в атрибуті Requirements автоматично додається оператор AND: (other.GlueCEInfoTotalCPUs $>=$ NodeNumber) && Member(other.GlueHostApplicationSoftwareRunTimeEnvironment," MPICH"), який означає вибір обчислювального елементу, на якому число процесорів більше NodeNumber, і те, що для підтримки паралельних обчислень встановлена бібліотека MPICH. Приклад 14. Нижче наведено приклад опису паралельного завдання: [ Type = "job"; JobType = "mpich"; VirtualOrganisation = "iteam"; // This is the minimum number of CPU needed by the job NodeNumber = 6; Executable = "cpi"; StdOutput = "sim.out"; StdError = "sim.err"; OutputSandbox = { "sim.err", "sim.out" }; 239 // This attribute triggers the proxy-renewal mechanism MyProxyServer = "skurut.cesnet.cz"; RetryCount = 3; InputSandbox = { "/home/fpacini/JDL2/fox/cpi" }; requirements = other.GlueHostNetworkAdapterOutboundIP && Member("IDL2.1",other.GlueHostApplicationSoftwareRunTimeEnvironment); rank = other.GlueCEStateFreeCPUs;; ] Інтерактивні завдання Незважаючи на те, що система управління завданнями обробляє завдання в пакетному режимі, існує можливість прямого контакту з завданням на етапі його виконання. Для цього воно визначається як інтерактивне (JobType=”Interactive” ). У цьому випадку стандартні потоки stdin, stdout і stderr перехоплюються на обчислювальному вузлі, де виконується завдання, і перенаправляються на комп'ютер, з якого виконана команда відправки завдання на виконання. Зв'язок здійснюється за X-протоколом, тому на комп'ютері, з якого виконана відправки завдання, повинен працювати X-сервер, який відкриває вікно для вводу і виводу. Вікно і процес (grid_console_shadow), який прослуховує порт, призначений для зв'язку, автоматично запускаються при виконанні команди glite-wms-job-submit. При розриві з'єднання або при необхідності з'єднання з іншого комп'ютера воно може бути відновлене командою glite-wms-job-attach. 240 Приклад 14. Нижче наведено приклад опису інтерактивного завдання: [ Type = "job"; JobType = "interactive"; VirtualOrganisation = "bio"; Executable = "scriptint.sh"; RetryCount = 1; // grid_console_shadow listens on this port. If not specified is // assigned by the OS ListenerPort = 6000; FuzzyRank = true; InputSandbox = { "/home/fpacini/JDL2/fox/scriptint.sh", "/home/fpacini/JDL2/fox/cpi", "/home/fpacini/DATA/sim.dat" }; requirements = (other.GlueHostOperatingSystemRelease == "LINUX") && (other.GlueHostMainMemoryRAMSize >= 128) // this is needed for Interactive jobs. Don’t need to specify it. It is // added automatically by UI && (other.GlueHostNetworkAdapterOutboundIP); rank = other.GlueHostBenchmarkSF00 ] 241 Завдання з контрольною точкою Для спеціального типу завдань із контрольною точкою (JobType="CheckpointableЄ) система управління завданнями підтримує можливість періодичного збереження стану задачі таким чином, що при збої в виконанні завдання можна виконати знову, але не з початку, а з якогось проміжного етапу. Така можливість дуже корисна при виконанні довгострокових обчислень. Опис завдання із контрольною точкою будується з тих же атрибутів, які застосовуються для простих завдань, однак повинні бути задані також додаткові атрибути – JobSteps й CurrentStep. Перший перераховує імена контрольних точок або задає їх максимальну кількість, а другий визначає, з якої точки повинен бути виконаний запуск. Передбачається, що програма, яка виконується в завданні, повинна бути організована спеціальним чином і використовувати API контрольних точок. Спочатку вона повинна одержувати інформацію про номер контрольній точки, з якої стартувала, а в процесі розрахунку повинна запам'ятовувати свій стан у файлі контрольних точок. Запис стану містить: ідентифікатор поточної точки, набір змінних програми та їх значення. Відзначимо, що поки запропонований апарат контрольних точок обмежений за своєю функціональністю і не містить засобів автоматичного перезапуску завдань у випадку, наприклад, збоїв обладнання. 242 Приклад 15. Нижче наведено приклад опису завдання с контрольною точкою: [ Type = "job"; JobType = "checkpointable"; VirtualOrganisation = "eo"; // This is the total number of steps for the job. Not mandatory // if your job already knows it JobSteps = 10000000; CurrentStep = 1; Executable = "hsum"; Arguments = "200000 gsiftp://lxde01.pd.infn.it/tmp/root_test/"; StdOutput = "sim.out"; StdError = "sim.err"; InputData = { "lfn:wp1-test-file-01-lfn", "lfn:wp1-test-file-02-lfn", "lfn:wp1-test-file-04-lfn" }; DataAccessProtocol = {"file", "rfio"}; OutputSandbox = { "sim.err", "sim.out" }; RetryCount = 3; InputSandbox = { "/home/fpacini/GUI/sbin/hsum" }; 243 // This is the default rank expression rank = -other.GlueCEStateEstimatedResponseTime; // semicolon “;” can be omitted for last attribute specification requirements = other.GlueCEInfoLRMSType=="pbs" ] DAG завдання Поряд із простими система управління завданнями вміє керувати наборами залежних між собою простих завдань, оформлених у вигляді одного складного. Складні завдання застосовуються для організації паралельно-послідовної обробки даних, яка складається з ряду етапів, частина з яких залежна за вхідними даними від результатів інших етапів. Залежність етапів проявляється в тому, що деякі з них можуть виконуватися паралельно, а інші не можуть почати виконання перш, ніж закінчаться їх попередники. Цьому відповідає модель складного завдання – ациклічний граф з орієнтованими ребрами (DAG - directed acyclic graph), в якому вузли позначають завдання. Ребро графа, спрямоване з вузла A у вузол B, означає, що завдання B не може виконуватися раніше завдання A ( рис.5.4). Рис.5.4 - Приклад DAG-завдання 244 У текстовій формі опис складного завдання включає опис завдання в цілому, опис його простих складових та залежності між ними. Структура опису завдання виглядає наступним чином: [ Type = "dag"; max_nodes_running = 5; nodes = [ node = [ description = [ JobType = "Normal"; Executable = "a.exe"; InputSandbox = { “your_input”}; ]; ]; ... node = [ description = [...] ; ]; ]; dependencies= { { node, node }, { node, node }, {node, mynode }, { { node, node, mynode }, node } }; ]; У загальній частині опису завдання використовуються атрибути, які застосовуються для простих завдань, і вони успадковуються всіма складовими, якщо не перекриваються явно в їхніх описах. В атрибуті 245 nodes визначаються складові (атрибут description або file, якщо опис перебуває у файлі) та їх залежності (dependencies). Базова форма запису залежностей – список пар { базовий вузол, залежний вузол}, наприклад: dependencies = { { node, node }, { node, node }, {node, mynode }} Припускається також скорочений запис: { { node1, node2, node3 }, node4 }}, де node4 залежить від трьох інших вузлів. Обробкою складного завдання управляє спеціальний компонент – DAG Manager (Dagman), який контролює завершення складових та здійснює запуск нових, якщо всі завдання, від яких вони залежать, виконані. Довготермінові завдання Існує ймовірність того, що термін дії початкового проксісертифікату скінчиться раніше, ніж завершиться завдання. Якщо це трапиться і проксі-сертифікат не буде відновлений, виконання завдання буде передчасно зупинене і скасоване. Для уникнення цього система управління завданнями дозволяє автоматичне поновлення авторизації, якщо проксі-сертифікат контролюється сервером MyProxy. Для використання механізму автоматичного поновлення терміну дії проксі-сертифікату, треба спочатку зареєструвати його на сервері MyProxy, командою: myproxy-init -s <server> -t <hours> -d -n де <server> - адреса сервера MyProxy, <hours> - кількість годин, протягом яких проксі-сертифікат повинен бути дійсним на сервері. Оскільки проксі-сертифікат тільки копіюється на сервер, для відправлення завдання необхідно створити локальний короткостроковий проксі-сертифікат, використовуючи команду voms246 proxy-init. Менеджер робочого завантаження візьме відновлений проксісертифікат із сервера MyProxy для відповідних завдань. Потреба в поновленні проксі-сертифікату повинна бути явно визначена в файлі опису завдання за допомогою атрибута MyProxyServer, наприклад: MyProxyServer = "skurut.ics.muni.cz"; Інформація про проксі-сертифікати, які зберігаються на сервері, може бути отримана за допомогою команди myproxy-info -s <server> -d і проксі-сертифікат може бути знищений командою myproxy-destroy -s <server> -d. Після віддалення проксі-сертифікату із сервера MyProxy завдання, яке в даний час виконується, більше не буде одержувати відновлений проксі-сертифікат. 5.4 Приклад виконання лабораторної роботи У цьому розділі наведений приклад послідовності кроків, які повинні бути виконані, щоб відправити завдання в грід-систему та контролювати процес його виконання. Перед використанням кожної з команд WMS-UI необхідно мати дійсний проксі-сертифікат, доступний системі управління завданнями. Його можна створити за допомогою команди voms-proxy-init. Якщо проксі-сертифікат вже є на комп‘ютері з встановленим WMS-UI (ui-edu.hpcc.kpi.ua), то можна використати змінну середовища X509_USER_PROXY для зазначення шляху до нього. Крім того, у каталозі $HOME/.globus необхідно мати пару сертифікат/закритий ключ, тобто файли - usercert.pem, userkey.pem з правами доступу 0600 та 0400, відповідно. Це так звані підготовчі 247 операції, які повинні бути зроблені при виконанні даної лабораторної роботи. Тепер перейдемо до виконання лабораторної роботи. Завдання. Розробити програму апроксимації функції sin(x) рядом Тейлора, та виконати обчислення у навчальній грідінфраструктурі під управлінням проміжного програмного забезпечення gLite. При виконанні другої лабораторної роботи в домашньої директорії студента знаходилися файли: - sinsum.py – програма обчислення апроксимації функції sin(x) рядом Тейлора, розроблена за допомогою мови програмування python; - sinsum.xml - дані для розрахунку; - sinsum.sh – скрипт виконання завдання для локальної системи планування кластеру. Крок 1 Створення файлі опису завдання За допомогою текстового редактору створимо файл (ім‘я файлу sinsum.jdl) опису завдання наступного змісту: [ Type = "Job"; JobType = "Normal"; Executable = "sinsum.sh"; StdOutput = "sinsum.out"; StdError = "sinsum.err"; InputSandbox = {"sinsum.py", "sinsum.sh", "sinsum.xml"}; OutputSandbox = {"sinsum.out", "sinsum.err"}; ] 248 За допомогою текстового редактору внесемо зміни в файл sinsum.sh, як наведено нижче: #!/bin/bash chmod 777 sinsum.py date python sinsum.py date Крок 2 Створення проксі - сертифікату Проксі – сертифікат створюється командою voms -proxy-init (у користувача буде запитаний пароль сертифікату) з зазначенням віртуальної організації (kpiedu), до якої належить студент: [svistunov@ui task3-pbs]$ voms-proxy-init -voms kpiedu Enter GRID pass phrase: Your identity: /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov Creating temporary proxy ....................... Done Contacting voms-edu.hpcc.kpi.ua:15002 [/DC=org/DC=ugrid/O=hosts/O=UGRID/OU=HPCC/CN=vomsedu.hpcc.kpi.ua] "kpiedu" Done Creating proxy ............................................................... Done Your proxy is valid until Thu Dec 2 00:52:19 2010 249 Перевірюємо дійсність створеного проксі-сертифікату по команді voms-proxy-info. [svistunov@ui task3-pbs]$ voms-proxy-info -all subject : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov/CN=proxy issuer : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov identity : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov type : proxy strength : 1024 bits path : /tmp/x509up_u6000 timeleft : 11:59:44 === VO kpiedu extension information === VO : kpiedu subject : /DC=org/DC=ugrid/O=people/O=BITP/OU=BITP/CN=Sergiy Svistunov issuer : /DC=org/DC=ugrid/O=hosts/O=UGRID/OU=HPCC/CN=voms-edu.hpcc.kpi.ua attribute : /kpiedu/Role=NULL/Capability=NULL timeleft : 11:59:43 uri : voms-edu.hpcc.kpi.ua:15002 Після цього можна почати використання команд інтерфейсу користувача WMS-UI. Крок 3. Перевірка доступних ресурсів для виконання завдання Часто корисно перевірити результати підбору ресурсу до реального відправлення завдання на виконання. Для цього використовується команда glite-wms-job-list-match. Для даного файлу опису завдання ця команда поверне список відповідних ресурсів згідно їх рангу. Ресурс із найвищим рангом буде зазначений першим: 250 [svistunov @ui ~]$ glite-wms-job-list-match -а sinsum.jdl Connecting to the service https://wms.hpcc.kpi.ua:7443/glite_wms_wmproxy_server =================================================== COMPUTING ELEMENT IDs LIST The following CE(s) matching your job requirements have been found: *CEId* - ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu - lcg-edu.bitp.kiev.ua:2119/jobmanager-lcgpbs-kpiedu ============================================= Крок 4. Відправлення завдання на виконання Якщо підібрані ресурси задовольняють користувача, завдання можна відправити на виконання: [svistunov@ui task3-glite]$ glite-wms-job-submit -a -o sinsum.id sinsum.jdl Connecting to the service https://wms.hpcc.kpi.ua:7443/glite_wms_wmproxy_server =========== glite-wms-job-submit Success =============== The job has been successfully submitted to the WMProxy Your job identifier is: https://wms.hpcc.kpi.ua:9000/mc5arTDgqPJzGWC4EzSfrw The job identifier has been saved in the following file: /home/localusers/svistunov/task3-glite/sinsum.id 251 Крок 5. Перевірка стану виконання завдання. Перевірка стану завдання виконується командою glite-wms-jobstatus: [svistunov@ui task3-glite]$ glite-wms-job-status -i sinsum.id ================================================== 1 : https://wms.bitp.kiev.ua:9000/YPyNoujhCxGUEKzYjaqZm 2 : https://wms.hpcc.kpi.ua:9000/mc5arTDgqPJzGWC4EzSfrw a : all q : quit ----------------------------------------------------------------------------------Choose one or more jobId(s) in the list - [1-2]all:2 ================================================= BOOKKEEPING INFORMATION: Status info for the Job : https://wms.hpcc.kpi.ua:9000/mc5arTDgqPJzGWC4EzSfrw Current Status: Running Status Reason: Job successfully submitted to Globus Destination: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu Submitted: Wed Dec 1 12:57:46 2010 EET ================================================== [svistunov@ui task3-glite]$ glite-wms-job-status -i sinsum.id =================================================== 1 : https://wms.bitp.kiev.ua:9000/YPyNoujhCxGUEKzYjaqZm 252 2 : https://wms.hpcc.kpi.ua:9000/mc5arTDgqPJzGWC4EzSfrw a : all q : quit -----------------------------------------------------------------Choose one or more jobId(s) in the list - [1-2]all:2 ===================================================== BOOKKEEPING INFORMATION: Status info for the Job : https://wms.hpcc.kpi.ua:9000/mc5arTDgqPJzGWC4EzSfrw Current Status: Done (Success) Exit Code: 0 Status Reason: Job terminated successfully Destination: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu Submitted: Wed Dec 1 13:17:26 2010 EET ====================================================== . Після успішно завершення завдання (статус Done), можна скопіювати результати на комп'ютер користувача із встановленим інтерфейсом користувача (WMS-UI). 253 Крок 6 Копіювання результатів виконання завдання: [svistunov@ui task3-glite]$ glite-wms-job-output -i sinsum.id ===================================================== 1 : https://wms.bitp.kiev.ua:9000/YPyNoujhCxGUEKzYjaqZm 2 : https://wms.hpcc.kpi.ua:9000/mc5arTDgqPJzGWC4EzSfrw a : all q : quit -----------------------------------------------------------------Choose one or more jobId(s) in the list - [1-2]all (use , as separator or for a range): 2 Connecting to the service https://wms.hpcc.kpi.ua:7443/glite_wms_wmproxy_server ====================================================== JOB GET OUTPUT OUTCOME Output sandbox files for the job: https://wms.hpcc.kpi.ua:9000/mc5arTDgqPJzGWC4EzSfrw have been successfully retrieved and stored in the directory: /tmp/jobOutput/svistunov_mc5arTDgqPJzGWC4EzSfrw Результати виконання збережені в директорії /tmp/jobOutput/svistunov_mc5arTDgqPJzGWC4EzSfrw. Якщо необхідно, щоб результати були збережені в місці розташування, відмінному від використовувати опцію -dir. 254 /tmp/jobOutput, потрібно Крок 7 Перегляд результатів виконання завдання Як вказано в попередньому кроці результати виконання завдання збережені в директорії /tmp/jobOutput/svistunov_mc5arTDgqPJzGWC4EzSfrw. У файлі sinsum.out знаходиться результат виконання. Такими є його перші 1000 символів: Результати розрахунків для двох значень x=0.01 та x=0.1 мають вигляд: x=0.01, sin(x)=0.00999983 n=1 0.01 (next term: -1.666666666667e-07 error: -1.666658333357e-07) n=2 0.00999983 (next term: -8.333333333333e-13 error: 8.333316675602e-13) n=5 0.00999983 (next term: -2.505210838544e-30 error: 0.000000000000e+00) n=10 0.00999983 (next term: -1.957294106339e-62 error: 0.000000000000e+00) n=25 0.00999983 (next term: -6.446959640457e-169 error: 0.000000000000e+00) n=50 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=75 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=100 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=250 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) n=500 0.00999983 (next term: -0.000000000000e+00 error: 0.000000000000e+00) x=0.1, sin(x)=0.0998334 n=1 0.1 (next term: -1.666666666667e-04 error: -1.665833531719e-04) n=2 0.0998333 (next term: -8.333333333333e-08 error: 8.331349481139e-08) n=5 0.0998334 (next term: -2.505210838544e-19 error: -1.387778780781e-17) n=10 0.0998334 (next term: -1.957294106339e-41 error: -1.387778780781e-17) n=25 0.0998334 (next term: -6.446959640457e-118 error: -1.387778780781e-17) n=50 0.0998334 (next term: -1.060901275372e-261 error: -1.387778780781e-17) n=75 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) n=100 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) n=250 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) n=500 0.0998334 (next term: -0.000000000000e+00 error: -1.387778780781e-17) 255 Виконав порівняння з результатами, які були отримані при виконанні другої лабораторної роботи, переконуємося в ідентичності отриманих значень. Крок 8 Віддалення проксі-сертифікату Після завершення роботи необхідно виконати команду vomsproxy-destroy, яка знищує проксі-сертифікат користувача. [svistunov@ui ~]$ voms-proxy-destroy 5.5 Завдання до лабораторної роботи 1. Розробити файл завдання на мові JDL для виконання в навчальній грід-інфрастуктурі, під управлінням проміжного програмного забезпечення gLite, програми, яка була розроблена в другій лабораторної роботи, згідно варіанту студента. 2. Створити проксі-сертифікат. 3. Відправити завдання на виконання в навчальну грід-інфрастуктуру. 4. Під час виконання завдання перевірити його статус. 5. Скопіювати результати виконання завдання в домашню директорію. 6. Порівняти отримані результати з результатами, яки були отримані при виконанні другої лабораторної роботи. Порівняти час виконання завдання. 7. Скласти протокол виконання лабораторної роботи. Протокол повинен містити: опис завдання на мові JDL, скріншоти виконання команд інтерфейсу користувача. У скріншотах відобразити відправлення завдання на виконання, перевірку стану завдання, результати розрахунків. 256 5.6 Контрольні питання 1. Історія розробки проміжного програмного забезпечення gLite в проекті EGEE. 2. Основні сервіси gLite, основні компоненти і їх призначення. 3. User Interface gLite. Призначення та функції. 4. WMProxy. Призначення, алгоритм роботи. 5. Workload Management System. Основні компоненти та призначення. 6. Алгоритм виконання простого завдання gLite. Послідовність команд і взаємодія компонентів. 7. Статуси завдання. Взаємодія компонентів Workload Management System. 8. Job monitoring. Взаємодія компонентів Workload Management System. 9. Інформаційна система gLite. Призначення й основні функції. 10. Monitoring and Discovery Service (MDS). Основні компоненти й взаємодія. 11. Storage Element gLite. Основні компоненти й призначення. 12. Управляння даними в gLite. 13. Storage Resource Management. Призначення й функції. 14. Типи завдань в gLite. 15. Завдання типу DAG в gLite. Приклад опису завдання на мові JDL. 257 Завдання № 6. Інформаційна система і моніторинг Мета: вивчення архітектури побудови інформаційних систем промислових грід, які працють під управлінням проміжного програмного забезпечення gLite і ARC, ознайомлення с існуючими системами моніторингу грід та набуття практичних навичок виконання запитів до інформаційної системи. 6 Короткі теоретичні відомості Підсистема інформаційного обслуговування і моніторингу забезпечує збір та управління даними про поточний стан грід-ресурів, хід виконання завдань, отримуючи інформацію від багатьох розподілених джерел – постачальників, і призначена для постійного контролю за функціонуванням грід-системи. 6.1 Інформаційна система gLite В проміжному програмному забезпеченні gLite інформаційна система виконує збір, зберігання інформації про поточний стані ресурсів та надає інформацію для інших підсистем, включаючи підсистему управління завданнями та даними, та забезпечує обробку запитів від користувачів, Фактично паралельно існують дві інформаційні системи: Globus Monitoring and Discovery Service (MDS), яка базується на OpenLDAP (відкритій реалізації протоколу Lightweight Directory Access Protocol, LDAP), та R-GMA (Relational Grid Monitoring Architecture). Інформаційна система Monitoring and Discovery Service (MDS) використовує найбільш загальну концептуальну модель представлення даних GLUE Schema (Grid Laboratory for a Uniform Environment) і вживається для: 258  збереження інформації про ресурси;  публікації їх стану. Друга інформаційна система R-GMA (Relational Grid Monitoring Architecture) побудована у відповідності з архітектурною моделлю моніторингу грід - GMA (Grid Monitoring Architecture) та забезпечує: 1. збір, збереження та отримання структурованої інформації довільної природи; 2. постачання інформації від розподілених джерел в базу даних в оперативному режимі; 3. публікацію інформації. Далі розглянемо стисло архітектуру побудови обох інформаційних систем. 6.1.1 Система Globus Monitoring and Discovery Service (MDS) Система MDS розроблена в рамках проекту Globus. На даний час інформаційна система MDS використовується у всіх грід-проектах і в такій інформаційної системі акумульована інформація про обчислювальні грід-ресурси практично всіх обчислювальних центрів з різних країн світу, які приймають участь в грід-проектах. До переваг MDS слід віднести те, що окрім даних про обчислювальні ресурси (сервери, робочі станції, кластери) в системі також представлена інформація про мережеві ресурси (конфігурація мережі та параметри, які описують її продуктивність). Наявність цієї інформації дає можливість враховувати пропускну здатність мережі при попередньому плануванні розподілу завдань за обчислювальними ресурсами, що, в свою чергу, обчислення. 259 дозволяє істотно оптимізувати Інформаційна система MDS заснована на двох ключових протоколах: Grid Information Protocol (GRIP) і Grid Registration Protocol (GRRP). Перший надає можливість виконувати запити і отримувати відповіді на них та здійснювати операції пошуку необхідної інформації. Другий - забезпечує реєстрацію компонентів інформаційної системи. Вся інформація об'єднується в ієрархічну структуру – дерево інформаційних каталогів (Directory Information Tree, DIT). Основу MDS складають сервіс інформації про грід-ресурси Grid resource information service (GRIS) і сервіс індексної інформації грід Grid Index Information Service (GIIS). За своїм місцем в ієрархії грід- сервісів дані служби забезпечують:  Рівень ресурсів: Сервіс інформації про грід-ресурси (Grid resource information service - GRIS) реєструє себе на одному або декількох сервісах індексної інформації, збирає за допомогою спеціальних модулів статичну й динамічну інформацію про стан складових частин грід-ресурсу і публікує її в сервісах індексної інформації за допомогою GRRP. На грід-сайті один GRIS працює на кожному сервісі: обчислювальному елементі (CE), елементі зберігання даних (SE), брокері ресурсів (RB), MyProxy та інші.  Рівень сайту: Сервіс індексної інформації грід (Grid Index Information Service- GIIS) надає агреговану інформацію про складові частини грід-ресурсу. Сервіси індексної інформації об'єднуються в ієрархічну структуру, в якій кожен GIIS зазвичай накопичує інформацію з індексних сервісів нижчого рівня (GIIS першого рівня накопичує інформацію від GRIS). На GIIS також покладаються завдання представлення інформації в певному вигляді, сортування інформації тощо. Запити можуть направлятися як до сервісів індексної інформації, так і безпосередньо до сервісів 260 інформації про ресурси. Використовується протокол GRIP. Сервіс індексної інформації в проміжному програмному забезпеченні gLite отримав назву site BDII. За функціональним призначенням сервіс індексної інформації виконує наступні функції:  ◦ збирає інформацію від всіх GRIS у грід-сайті; ◦ зберігає цю інформацію в Berkeley DB; ◦ робить її доступної для Top level Information Index. Верхній рівень: Top Berkeley DB Information Index (BDII) – сервіс, який збирає інформацію від всіх GIIS та зберігає її в базі даних Berkeley DB. Інформація, яка збережена в BDII, доступна тільки через http запити. На рис.6.1 наведена архітектура інформаційної системи gLite. Спеціальне програмне забезпечення Information Provider, яке розташовано на обчислювальному ресурсі та ресурсі зберігання даних, генерує актуальну інформацію про ресурси: статичну, наприклад, тип SE, і динамічну, таку як розмір дисковий простір на SE, який використовується для файлів користувача. Ця інформація публікується за допомогою resource-level BDII, який працює на ресурсі. Сервіс sitelevel BDII використовується для зберігання і публікації даних з усіх resource-level BDIIs, які знаходяться на сайті (рис.6.1). На верхньому рівні ієрархії використовується сервіс top-level BDII (рис.6.2). BDIIs на цьому рівні налаштовані таким чином, що читають інформацію з усіх грід-сайтів, які визначені як елементи грідінфраструктури. Цей BDIIs працює як кеш для зберігання актуальної інформації про стан грід-інфраструктури у своїй базі даних. Крім того, BDIIs цього рівня містить всю доступну інформацію про грід-сайти, які зареєстровані в цій грід-інфраструктурі. 261 Рис.6.1 - Архітектура інформаційної системи Незважаючи на наявність верхнього рівня, завжди можливо отримати інформацію про окремо обраний ресурс прямо від site-level BDIIs чи resource-level BDIIs. Крім того, top-level BDIIs отримує інформацію про грід-сайти від Grid Operations Centre (GOC), де менеджер операційного центру вводить початкову інформацію про грідсайт при його реєстрації. Рис. 6.2. Схема передачі інформації 262 В основі реалізації MDS лежить служба директорій LDAP (Lightweight Directory Access Protocol). Для представлення метаінформації організована автономна директорія (MDS-директорія), яка відрізняється від звичайної директорії власною схемою, яка розширює стандартну схему LDAP набором класів, необхідних для представлення елементів глобальної обчислювальної системи. В основі представлення даних в системі MDS використовується GLUE (Grid Laboratory for a Uniform Environment) Schema, і тому спочатку розглянемо, яким чином вона реалізована. Історично склалося так, що на початковому етапі розвитку грідпроектів кожна грід-система задача власне забезпечення проміжне програмне забезпечення. сумісності (interoperability) стояла досить гостро. Зокрема в рамках одного проекту WLCG І використовувала функціонувало декілька функціональної грід-систем (LCG/EGEE, OSG і NGDF Grids), яки мали різні інформаційні системи. Для вирішення проблеми функціональної сумісності був започатковано проект GLUE (Grid Laboratory for a Uniform Environment), який об'єднав проекти European DataGrid (EDG), DataTAG , US iVDGL і Globus з метою створення єдиного опису грід-ресурсів в інформаційній системі. В 2002 році була розроблена перша версія GLUE схеми уніфікованого опису даних. В 2004 році була розроблена версія 1.2, а в 2006 році ця схема була впроваджена в проекті LCG/EGEE. На даний час використовується вже версія GLUE 2.0. Основна мета розробки і впровадження GLUE схеми - це забезпечення стандартизації опису обчислювальних грід-ресурсів, доступності цих ресурсів, опис сервісів, які наявні в грід-системі. Представлені дані в GLUE схемі повинні відповідати на основні питання: 263  які ресурси доступні,  які властивості цих ресурсів,  у якому стані в даний час перебувають ці ресурси. Сама схема надає абстрактне представлення грід-ресурсів за допомогою UML опису в термінах об'єктів (objects), які мають атрибути (attributes) і зв'язані відношеннями (relations) з іншими об'єктами. У загальному вигляді схема розпадається на кілька частин (рис.6.3). Рис.6.3. Структура GLUE схеми опису ресурсів На верхньому рівні сайт (Site) GLUE схема описує інформацію про грід- ресурси. Рівнем нижче представлені дані про обчислювальний елемент (CE) і елемент зберігання даних (SE), які є основними компонентами грід-системи; про абстрактні сервіси (Service), надавані в грід-системі; про мережеву інформацію (Network), яка описує зв'язок між CE й SE об'єктами; про обчислювальні вузли (Cluster), які входять в склад обчислювального елементу. Стисло наведено характеристики інформації, яка зберігається в GLUE схемі. 264 основні Інформація про сайт (Site information). На верхньому рівні об'єкт GlueSite представляє найбільш загальну інформацію про грід-сайт : географічне розташування, контактну інформацію та іншу. Більша частина інформації заповнюється системними адміністраторами грідсайту, але частина її конфігурується стандартними засобами адміністратора проекту (наприклад, WLCG). Інформація про грід- сервіси (Service information). У цьому розділі представлена загальна абстрактна інформація про сервіси, які надає грід-система. У існуючих реалізаціях інформація про сервіси не зв'язана прямо з інформацією про обчислювальні елементи й елементи зберігання даних. Але надалі планується описувати спеціалізацію грідресурсів. Інформація про обчислювальні елементи (Computing Element). Об'єкт GlueCE і пов'язані з ним об'єкти описують обчислювальні ресурси подібно тому, як вони були описані в проекті EDG. Крім того, об'єкт GlueCE містить інформацію про чергу локальних задач цього обчислювального ресурсу. Інформація про елемент збереження даних (Storage Element). Стандартна GLUE схема описує вкрай мало атрибутів і об'єктів, пов'язаних з системами збереження даних. У схемі представлені об'єкти, які описують доступний дисковий простір, файлову систему і протокол доступу. Додатково в схемі представлена концепція області збереження (Storage Area (SA)), яка описує дисковий простір для зберігання файлів даних. Крім того, у схемі представлена концепція протоколів доступу (Control Protocol and Access Protocol), які використовуються для адміністрування даних. Інформаційна модель LDAP базується на об'єктах (entries), яки мають один або більше атрибутів. Кожен об'єкт має Distinguished Name 265 (DN), який робить його унікальним, а кожен атрибут має одне або кілька значень. Distinguished Name формується з послідовності пар атрибут / значення і вибудовується в деревоподібну ієрархічну структуру, яка називається Directory Information Tree (DIT). Модель директорій LDAP, яка використовується в MDS, з точки зору представленої інформації поділяється на:  модель інформаційної бази директорії - описує структуру інформації, яка представлена в директорії LDAP;  модель інформаційного дерева директорії - описує прийнятий у директорії LDAP спосіб організації і ідентифікації інформації;  модель розподіленої директорії - описує архітектуру і засоби реалізації розподілених у мережі директорій;  функціональну модель - описує операції, які використовуються для доступу та адміністрування представленої в директорії інформації;  модель забезпечення безпеки - визначає засоби захисту інформації в директорії від неавторизованого доступу. Інформація розміщується в директорії у вигляді об'єктів, які звуться точками входу в директорію (directory entries). За змістом кожен об'єкт, який входить в директорію, відображає факт існування деякої сутності реального світу: організації, людини, сервера і т.д. Об'єкт характеризується власним набором атрибутів. Окремий атрибут має ім'я і може приймати одне або декілька значень певного типу. У моделі директорій LDAP використовується фіксований набір типів значень. Тип визначає формат припустимих значень об‘єкту, а також способи порівняння та і упорядковування цих значень. Для кожного об'єкта директорії встановлюється, до якого класу або класів він належить. Ця приналежність відображається у формі завдання обов'язкового атрибута з ім'ям objectClass, значеннями якого є 266 імена класів. Класи об'єктів визначаються в схемі директорії. В оголошенні класу задається його ім'я і перераховуються атрибути, які використовуються в об'єктах даного класу, а також фіксуються ті з них, наявність значень у які обов'язково. Крім того, можуть бути визначені один або кілька батьківських класів, значення яких будуть успадковуватися. Всі атрибути, які згадуються як обов'язкові в батьківських класах, стають обов'язковими і у класі, який породжується. Те ж саме стосується і необов'язкових атрибутів. Особливістю подання схеми в LDAP є те, що тут визначення атрибутів не включається в оголошення класів, а надаються самостійно. У такий спосіб у схемі спочатку визначається набір атрибутів, які потім використовується при побудові класів об'єктів. Такий підхід дозволяє виключити ситуацію появи в класах однаково пойменованих атрибутів з різними типами значень. Об'єкти директорії організовані у вигляді деревоподібної структури, яка має назву – інформаційне дерево директорії. Підпорядкованість об'єктів у дереві директорії, як правило, відображає географічну, організаційну або іншу підпорядкованість сутностей реального світу, які відповідають об'єктам директорії. Унікальні імена об'єктів (DN - distinguished name), які дозволяють ідентифікувати об'єкти в директорії поза залежності від їх підпорядкованості, утворяться за допомогою групування (конкатенації) відносних унікальних імен об'єктів на шляху від кореня до об'єкту, який ідентифікується (аналогічно повному ім'ю файлу в ієрархічної файловій системі). Синтаксично унікальні імена записуються в зворотної послідовності - від об'єкта до кореня. 267 Рис.6.4 - Приклад структури даних LDAP На рис.6.4 представлено приклад фрагмента інформаційного дерева. На верхньому рівні ієрархії знаходиться об'єкт з DN-ім'ям о=grid. На наступних рівнях розташовуються об'єкти, які використовуються для групування організацій за територіальною належністю. Далі наведений об'єкт st=Geneva як об‘єкт, підпорядкований попередньому. На останньому рівні розташовані об'єкти з описом персональних даних. Кожний LDAP-сервер має власну внутрішню базу даних, у якій безпосередньо зберігається один або кілька фрагментів директорії. Логічно кожний фрагмент являє собою піддерево інформаційного дерева директорії. Ідентифікація кожного піддерева здійснюється за допомогою завдання суфікса - унікального імені (DN) об'єкта, який є коренем цього піддерева. Визначення набору суфіксів (тобто фрагментів директорії, які обслуговуються сервером) входить в обов'язок адміністратора LDAP-серверу. 268 В розподілених інформаційних системах, яки базуються на моделі LDAP, для забезпечення ефективності пошуку інформації використовується реплікація даних. Реплікація - це механізм, за допомогою якого фрагменти директорії, розташовані на одних серверах, автоматично копіюються на інші. Використання реплікації дозволяє істотно підвищити доступність даних, забезпечуючи стійкість до збоїв, більш високу продуктивність, збалансоване завантаження серверів. При реалізації механізму реплікації розрізняють сервер-постачальників даних і сервер-одержувачів. Будь-який LDAP-сервер може одночасно виступати як у ролі постачальника, так і в ролі одержувача. Для того, щоб сервер міг використовуватися як постачальник, використовується спеціальний журнал, у якому фіксуються всі зміни, які відбуваються в даних. За допомогою журналів мінімізуються об'єми даних, що пересилаються: не вся директорія, а тільки зміни, які відбулися із часу попередньої реплікації. Функціональні операції, підтримувані службою директорій LDAP, базуються на клієнт-серверній архітектурі і дозволяють: відкрити з'єднання клієнта із сервером, провести аутентифікацію клієнта, виконати пошук і модифікацію об'єктів у директорії, закрити з'єднання при завершенні роботи. Забезпечення безпеки в LDAP має певні особливості. По-перше, LDAP визначає протокол взаємодії клієнта і сервера. Для забезпечення безпеки цього протоколу прийнятий традиційний підхід, заснований на використанні механізмів Secure Socket Layer (SSL). Шар SSL забезпечує взаємну аутентифікацію клієнта і сервера; гарантує відсутність втрат інформації, переданої через мережу; 269 дозволяє зберегти конфіденційність інформації при передачі. У цілому використання SSL в LDAP побудовано за аналогією з іншими безпечними мережевими протоколами, наприклад https і ftps. З іншого боку, служба директорій LDAP являє собою інструмент для реалізації інформаційних систем, і тому вона повинна забезпечувати безпеку інформації, яка зберігається в системі, захищаючи її від несанкціонованого доступу. Розмежування доступу в LDAP у даний момент не стандартизовано. Однак існують загальні принципи розмежування доступу, які простежуються у всіх реалізаціях. Користувачі і групи користувачів в LDAP представлені у вигляді об'єктів директорії. За великим рахунком ці об'єкти нічим не відрізняються від інших інформаційних об'єктів. Для представлення користувачів використовується клас person, або похідні від нього класи inetOrgPerson, organizationalPerson і ін. Об'єкти цих класів мають, крім іншої інформації, атрибути userPassword і userCertificate. Такі об'єкти LDAP розглядає як зареєстрованого користувача. Унікальне ім'я (DN) цього об'єкту виконує роль ім'я для входу (login name). Інформація, яка визначає правила розмежування доступу, представляється в директоріях LDAP за допомогою спеціальних атрибутів aci (Access Control Information instruction), які можуть бути додані до будь-якого об'єкта директорії. Для ілюстрації управління доступом до директорії LDAP розглянемо наступний приклад. Для того щоб надати всім користувачам директорії, включаючи анонімних, право доступу на читання та пошук у фрагменті директорії, яка містить інформацію про KIAM, і одночасно надати право ведення цієї інформації адміністратору директорії, потрібно встановити наступні aci-інструкції "o=KIAM,o=RAS,c=RU": 270 в об'єкти з DN aci: (target = "ldap:///o=KIAM,o=RAS,c=RU ") (targetattr=*) allow (read,search) userdn = ldap:///anyone" aci: (target = "ldap:///o= o=KIAM,o=RAS,c=RU") (targetattr=*) allow (add,modify,delete) userdn = "ldap:///cn=Directory Manager,o=KIAM,o=RAS,c=RU " При авторизації доступу клієнта до певного об'єкта директорії LDAP-сервер використовує наступну схему. Спочатку підсумуються всі aci-інструкції, приписані до самого об'єкта, а також до всіх об'єктів, розташованим в інформаційному дереві директорії на шляху, який з'єднує даний об'єкт із коренем директорії. Після цього розглядаються всі aci-інструкції, які забороняють виконання дії. Якщо знайдена хоч б одна заборонна інструкція, то виконання дії блокується. Далі розглядаються всі aci-інструкції, які дозволяють задану дію. Якщо такі інструкції відсутні, то виконання даної дії також блокується. Таким чином, інструкції, які забороняють дії, мають безумовний пріоритет перед інструкціями, яки дозволяють виконання операції. З технічної точки зору будь-який LDAP-сервер, на якому встановлена схема MDS, може використовуватися в якості MDSсерверу. Верхні рівні директорії MDS побудовані за тим же принципом, що і відповідні рівні LDAP-директорії. На першому рівні розташований об'єкт з ім'ям o=grid, а на другому - об'єкт c=US. Обидва цих об'єкти є по суті фіктивними, оскільки не зберігають ніякої корисної інформації. Усі реальні об'єкти, які відображають метаінформацію, підпорядковані вершинам o=grid, c=US інформаційного дерева. Така організація забезпечує можливість у майбутньому інтегрувати MDS-директорію в глобальну директорію LDAP. Оскільки система MDS є надбудовою над LDAP, вона успадковує все програмне забезпечення, наявне в службі директорій. Зокрема її розробникам не довелося витрачати додаткові зусилля на реалізацію 271 операцій пошуку, модифікації даних, аутентифікацію і авторизацію користувачів і т.п. Для цих цілей у MDS застосовуються стандартні користувацькі утиліти і API, прийняті в LDAP. Принципове значення має те, що основний обсяг інформації в MDS збирається і актуалізується в автоматичному режимі. Для цього реалізована необхідна інфраструктура, яка базується на взаємодії MDS-сервера і комплексу резидентних програм (демонів), які встановлюються на обчислювачах, що підключаються до інформаційної системи. Доступ до даних MDS не захищений (не потрібно мати грід-сертифікат) тобто можливо як читання клієнтам і користувачам, так і запис за допомогою сервісів, які публікують інформацію. 6.2 Система (Relational Grid Monitoring Architecture) R-GMA Система R-GMA була впроваджена в проекті DataGrid і за своїми функціональними можливостями об'єднує в собі інформаційну і моніторингову системи, які засновані на реляційній моделі представлення даних. Даний монітор надає такий доступ до інформації, начебто вся вона зберігається в єдиній базі даних, але тільки в рамках однієї віртуальної організації. Єдина база даних розподіляється на окремі таблиці. Внесення та запит даних здійснюється за допомогою звичайних SQL-запитів. Проте в системі не існує централізованого репозиторію, який би зберігав дані для таблиць. Віртуальна база даних фактично складається зі списку визначень таблиць (схеми), списку постачальників (реєстру) та набору правил, за якими визначаються, які постачальники повинні надавати конкретного SQL-запиту. 272 інформацію при надходженні Рис.6.5. Основані компоненти системи R-GMA Користувачі та служби грід-середовища запитують інформацію з віртуальної бази даних за допомогою абонентів. Потрібна інформація надходить до бази від постачальників (рис.6.5). Абоненти звертаються до реєстру, щоб вибрати зі списку тих постачальників, які в змозі надати інформацію для відповіді на SQL-запит, який надійшов від клієнта, після чого звертаються до постачальників безпосередньо. Таким чином, R-GMA є реляційною реалізацією класичної архітектури грід-моніторингу. В R-GMA існує три види постачальників: Primary, Secondary and On-demand. Постачальники баз даних призначені для отримання інформації, яка була зібрана раніше та збережена у базі даних. Потокові постачальники – для динамічного збереження даних, які щойно надійшли, до пам'яті. Постачальники реєструють себе в системі, а при припиненні роботи постачальника система його видаляє. Реєстр постачальників централізований, хоча існує потенційна можливість його розподіленої реалізації. 273 Між реєстром та замовниками знаходиться шар проміжного програмного забезпечення, який динамічно будує послідовні запити для тих випадків, коли замовлення не можна задовольнити однією операцією вибірки. RGMA може використовуватися разом з MDS 2, але при цьому значно знижується швидкодія. Ця система має великі потенційні можливості масштабування, хоча вони поки знаходяться на стадії розробки. Очевидно, що об‘єднання всієї інформації в одну логічну базу даних забезпечує виняткову зручність для користувача, однак потребує багато ресурсів. 6.3. Інформаційна система NorduGrid ARC Інформаційна система NorduGrid ARC IS є складовою частиною проміжного програмного забезпечення ARC. Детально структура проміжного програмного забезпечення ARC та побудова інформаційної системи була розглянута в лабораторній роботі №4. В даному розділі розглянемо тільки основні складові компоненти інформаційної системи. Система складається з трьох основних компонентів: - локальні інформаційні дерева, що відповідають за опис і характеристику ресурсів (обчислювальних і сховищ). Генеруються на ресурсах, вибірково кешуються. Надаються клієнтові за запитом через інтерфейс LDAP; - служби індексування, які підтримують динамічні списки ресурсів (посилання на локальні інформаційні дерева); - процеси реєстрації, що працюють на локальних ресурсах і реєструють локальні дерева в службах індексації. Реєстрація завжди ініціюється реєстрантом. 274 Система дозволяє робити два типи запитів: 1. запит служб індексації для вибору відповідних локальних інформаційних дерев; 2. прямий запит інформаційного дерева за його адресою. Загальна архітектура NorduGrid ARC IS зображена на рис. 6.6. Рис.6.6 - Загальна архітектура NorduGrid ARC IS Локальне інформацію, інформаційне реалізує дерево кешування (LIS) першого збирає рівня динамічну для локальної інформації і надає запитану інформацію клієнтам, використовуючи протокол LDAP. Локальне інформаційне дерево по суті є модифікованою OpenLDAP базою даних. Інформацію на ресурсі збирають програми-постачальники. Вони отримують дані від системи пакетної обробки завдань, від локального grid-рівня (Grid Manager або GridFTP сервер) або від локальної операційної системи (для Linux систем це інформація з каталогу /proc). Перетворювачами слугують служби індексування. Зібрану інформацію зберігає служба GRIS. Інформація кешується, і якщо вона відсутня в 275 кеші, будуть знову опитані постачальники. Кешування оберігає вузли від зайвого навантаження через часте звернення до постачальників. Для створення загальної інформаційної структури локальні дерева об'єднуються в загальну систему. Для цієї мети використовуються процеси реєстрації і служби індексування. Індексні служби збирають тільки контактну інформацію ресурсів, дані з власне дерев ці служби не використовують. Процеси реєстрації слугують для зв'язку між індексними службами і локальними деревами. Служби індексування є спеціалізованою LDAР базою даних. Клієнт, який шукає відповідні ресурси, проходить за деревом від найвищого рівня до LDAР елементів обчислювальних вузлів або сховищ. Коли клієнт отримав адресу конкретного ресурсу, він робить прямий запит і підключається за протоколом LDAP до його локального інформаційного дерева. Об‘єктами моніторингу усіх вищезазначених систем є обчислювальні вузли та стан мережі, що їх з‘єднує в кластерну систему. Система моніторингу NorduGrid ARC IS також може надавати інформацію про задачі, що виконуються або стоять у чергах в даному грід-середовищі. 6.4 Моніторинг грід-системи. Основні положення Грід – це середовище, яке складається з ресурсів, які знаходяться в різних місцях, мережевих ресурсів, які з‘єднують їх, і взаємоузгодженого за всією інфраструктурою проміжного програмного забезпечення, яке зв'язує ці ресурси та підтримує виконання дистанційних операцій і реалізує функції контролю і управління операційним середовищем. Успішність функціонування грід-системи при виконанні задач користувачів та при плануванні завантаження 276 обчислювальних ресурсів багато в чому залежить від ефективної роботи системи моніторингу грід-середовища. Моніторинг грід-середовища, зазвичай складається з чотирьох етапів:  генерування подій (опит сенсорами вузлів і представлення інформації у потрібному вигляді);  обробка подій, які були згенеровані;  передача зібраної інформації за вказаними адресами;  презентація зібраної інформації. Слід зазначити, що презентувати інформацію можна як людям – користувачам, так і іншим програмним компонентам. До моніторингу грід-середовища висуваються наступні вимоги:  масштабованість.;  розширюваність;  підтримка різних моделей доставки даних;  мобільність;  забезпечення необхідного рівня безпеки. В загальному випадку систему моніторингу можна представити так, як показано на рисунку 6.7: 277 Рис.6.7. Загальний вигляд системи грід-моніторингу Архітектура грід-моніторингу складається з наступних стандартних складових:  Постачальник – процес, за допомогою якого надається інформація про об'єкти моніторингу (обчислювальні вузли). Постачальником виступають спеціальні служби на кластері, які надають інформацію про нього інформаційній системі та користувачу.  Замовник – процес, який отримує інформацію про об'єкти як мінімум одного постачальника. Замовником виступає, по-перше, користувач, який, використовуючи наданий йому інтерфейс, запитує інформацію про вузли конкретного кластеру; по-друге, інформаційна система, яка опитує всі кластери грід - системи та збирає загальні дані про них; по-третє, інформаційна система верхнього рівня, яка збирає дані про наявні в системі інформаційні системи нижніх рівнів.  Реєстр – пошуковий сервіс, який дозволяє постачальникам публікувати дані, а замовникам – отримувати необхідну їм інформацію. 278 У реєстрі також зберігаються відомості про те, як зв'язатися з об'єктами (адреса, протокол, вимоги безпеки і т.д.). Реєстр може знаходитися в інформаційних системах як нижнього, так і верхнього рівня. Обмін повідомленнями між архітектурними складовими відбувається за допомогою спеціального API (Application Programming Interface). Після знаходження за допомогою реєстру потрібного постачальника замовник зв'язується з ним напряму для отримання детальної інформації або для виконання необхідних дій (наприклад, запуску завдання). Архітектура моніторингу також визначає служби, які мають інтерфейси як замовника, так і постачальника, це так звані перетворювачі (republisher). Вони виконують фільтрацію, накопичення, усереднювання, широкомовлення (broadcasting) і кешування інформації. Крім того, в архітектурі передбачені репозиторії схем, які зберігають інформацію про типи об'єктів. Перетворювачі і репозиторії схем є опціональними компонентами, але майже всі комплексні системи моніторингу їх використовують. Репозиторій схем може бути частиною реєстру. Перетворювачами виступають інформаційні системи обох рівнів. В існуючих промислових грід-системах розрізняють наступні рівні моніторингу грід-середовища: - Моніторинг грід-застосувань (Grid Applications monitoring). Основне завдання таких систем моніторингу – це постійна перевірка працездатності прикладного програмного забезпечення, яке використовуються для проведення наукових обчислень в грідсередовищі. Прикладами таких систем є Experiment Dashboards [8]. 279 Application monitoring [7], - Моніторинг проміжного програмного грід забезпечення (Grid Middleware monitoring). Основне завдання – це постійна перевірка працездатності сервісів, яка входять до складу проміжного програмного грід забезпечення . Прикладами таких систем є: Grid Services monitoring [9], Gstat [10], SAM/GridView [11], GridICE [12], GridPP Real Time Monitor [13]. - Моніторинг ресурсів (Local Resources monitoring). Основне завдання – постійна перевірка працездатності обчислювальних ресурсів та локальних сервісів, які відповідають за роботу ресурсу в цілому. Прикладами таких систем є Lemon/SLS [14], Nagios [15], Ganglia [16] . Кількість існуючих систем моніторингу грід-середовища не обмежується наведеними вище, тому в наступному розділі ми розглянемо функціональні можливостей декількох систем. 6.5 Приклади засобів моніторингу грід-систем Система моніторингу GridICE Розподілена система мониторингу грід-систем GridICE була розроблена в рамках проекту EU-DataTAG в 2002 році в INFN (Італія) і в подальшому включена в проект EU-EGEE. На даній час система повністю інтегрована в проміжне програмне забезпечення gLite. 280 Рис.6.8 - Екран системи грід-моніторингу GridICE ((http://gridice2.cnaf.infn.it:50080/gridice/) GridICE має централізовану архітектуру (рис.6.8), в якій головний сервер періодично відправляє запити до обчислювальних ресурсів для отримання інформації про поточний стан ресурсів, статус виконання завдання, мережеві параметри. GridICE має спеціальний модуль взаємодії з системою MDS для доступу до інформації. Крім того, GridICE має власні модулі (sensors) для отримання даних про стан обчислювальних вузлів та використовує MDS в якості постачальника даних. GridICE дозволяє відображати як агреговану моніторингову інформацію про стан обчислювальних ресурсів, так і детальну інформації по окремим обчислювальним вузлам. Система моніторингу GridICE розповсюджується за відкритою ліцензією. 281 Система моніторингу MonALISA Система моніторингу MonALISA (Monitoring Agents using а Large Integrated Services Architecture) призначена для моніторингу поточного стану обчислювальних вузлів і мереж у масштабних розподілених системах. Основою даної системи є багато- потокова служба паралельного та незалежного збору даних з багатьох джерел, якими виступають системи моніторингу кластерів (Ganglia, HawkEye і т.п.). Кожен модуль для збору даних конкретного типу або для роботи з конкретним постачальником діє у своєму незалежному потоку, тому система може функціонувати навіть, якщо в якомусь її потоці виник збій. Для зменшення навантаження на систему сервер намагається використовувати для поточних завдань вже створені потоки і, тільки якщо це не можливо, у новому потоці буде завантажено новий модуль. Система завжди створює керівний потік, який відповідає за видалення потоків, які працюють з помилками, та їх повторне створення в разі, якщо вони не виконали своє завдання. Потоки системи можуть працювати як за моделлю push, так і за моделлю pull. Зібрані дані зберігаються локально, індексуються в вбудованій або в зовнішній базах даних і доставляються за запитом замовникові. Клієнт після знаходження відповідної служби може запитувати інформацію як в реальному часі, так і з бази даних, а також підписатися на отримання інформації про певні параметри. Клієнт може використовувати будьякий сторонній фільтр для представлення інформації в потрібному вигляді. Для роботи з кожним клієнтом також створюється окремий потік. Для отримання інформації від служб клієнти використовують спеціальні проксі-сервіси. Використання проксі-сервісів дозволяє отримувати інформацію від служб, які працюють на захищених firewall 282 комп‘ютерах та здійснювати контроль над з‘єднаннями служб. Ще однією функцією даних сервісів є мультиплексування інформації в разі її одночасного запиту багатьма клієнтами. Служби і модулі монітору управляються за допомогою графічного інтерфейсу, що дозволяє віддалено налаштовувати параметри моніторингу. MonALISA автоматично перевіряє наявність нових версій і відключає служби, що стали непотрібними. MonALISA має графічний інтерфейс. За його допомогою відбувається візуалізація зібраних даних, детальне відображення інформації про кожен вузол системи або системи в цілому. Графічний клієнт динамічно отримує інформацію про підключення нових служб або модулів і автоматично її відображає. MonALISA – гнучкий інструмент загального призначення, проте його реалізація на мові Java накладає обмеження на продуктивність. Також цей монітор використовує широкомовну розсилку, яка збільшує навантаження на мережу. Постачальниками для даної системи виступають локальні монітори. Служба моніторингу виконує роль перетворювача. Ця система є гнучким інструментом загального призначення і одним з найбільш універсальних засобів моніторингу грід-середовища. Система моніторингу MonALISA розповсюджується за відкритою ліцензією. Нижче на рис.6.9 показано (http://monalisa.caltech.edu/). 283 екран системи MonALISA з Рис.6.9 - Екран системи грід-моніторингу MonALISA Система моніторингу GStat Система моніторингу Gstat була розроблена для відображення інформаційного стану грід-інфраструктури проекту EGEE/WLCG. В даний час система використовується для моніторингу в проекті EGI. Перелік грід-сайтів вибирається з центральної бази даних GOCDB операційного центру грід у Тайбеї. Система Gstat відображає завантаження грід-ресурсів при виконанні завдань з деталізацією за віртуальними організаціями. Gstat дозволяє відображати як агреговану моніторингову інформацію про стан обчислювальних ресурсів, так і детальну інформації по окремим обчислювальним вузлам. Нижче на рис.6.10 представлено екран системи Gstat з (http://goc.grid.sinica.edu.tw/gstat/). 284 Рис.6.10 - Екран системи грід-моніторингу GStat Система моніторингу Service Availability Monitoring (SAM) Система моніторингу Service Availability Monitoring (SAM Test) розроблена в CERN (Швейцарія) для тестування грід-інфраструктури проект EGEE/WLCG. Представляє собою набір тестів перевірки доступності грід-сервісів сайтів, які входять в проект EGEE/WLCG. Перелік грід-сайтів вибирається з центральної бази даних GOCDB та з BDII верхнього рівня, яка знаходиться в ЦЕРН. Встановлені тести періодично перевіряють роботу сервісів CE, SE, BDII, RB. Спеціальні тести перевіряють виконання тестового завдання на грід-сайті та отримання результатів. Для перегляду результатів тестів потрібен сертифікат, встановлений в браузері. На рис.6.11 представлено єкран системи sam.cern.ch:8443/sam/sam.py) 285 SAM з (https://lcg- Рис.6.11 - Екран системи грід-моніторингу SAM Система моніторингу ARC Grid Monitor Система моніторингу ARC Grid Monitor є стандартним засобом моніторингу стану грід-інфраструктури під управлінням проміжного програмного забезпечення ARC і входить в склад дистрибутивного пакету. За своєю структурою Grid Monitor представляє Веб орієнтований додаток, розроблений мовою PHP, для отримання інформації з інформаційної системи ARC. У грід - моніторі можна виділити сім основних модулів: загальний грід-монітор, опис обчислювального ресурсу (кластера), інформація про стан черги на локальному ресурсі, інформація про завдання користувача, інформація про користувача, список атрибутів, список користувачів. 286 Більшість об'єктів головного вікна являють собою гіпер посилання для доступу до інформації відповідних модулів системи моніторингу. Грід - монітор є зручним, надійним і самим затребуваним інструментом серед користувачів і системних адміністраторів. На рис.6.12 представлено екран системи моніторингу ARC стану сайтів Українського національного грід (http://gridmon.bitp.kiev.ua) Рис.6.12 - Система грід-моніторингу ARC Grid Monitor 287 6.6 Доступ до даних інформаційної системи gLite Для доступу до даних інформаційної системи в проміжному програмному забезпеченні gLite є дві утиліти lcg-infosites та lcg-info, які дозволяють запобігти використанню складних LDAP запитів. Нижче наведено приклади використання цих утиліт для отримання інформації про грід-ресурси. 1) Команда lcg-infosites - одержання інформації про грід ресурси. Має наступний синтаксис: lcg-infosites --vo <vo name> options -v <verbose level> --is <BDII to query> де: --vo - назва віртуальної організації (ВО), -v - рівень деталізації виводу отриманої інформації, --is - URL серверу BDII, якщо використовується сервер, відмінний від сервера, визначеного в конфігураційному файлі грід-сайту, оptions – опції команди (табл.6.1). Таблиця 6.1. Опції команди lcg-infosites ce Відображається інформація про обчислювальні елементи: кількість процесорів, кількість завдань, що виконуються, кількість завдань у чергах, імена CE. Всі дані групуються за ВО. se Відображається інформація за елементами зберігання даних: імена SE, разом з типом Storage System, об‘єм доступної пам‘яті та пам‘яті, що використовується. 288 closeSE Відображаються імена CE, що підтримують дану ВО разом з найближчим SE. Відображається lfc ім‘я lfc-каталога для користувачів віртуальної організації Відображається tag назва ―міток‖ для встановленого програмного забезпечення на грід-ресурсі разом з іменем відповідного CE. Об‘єднання опцій ce та se all Приклад 1. В прикладі відображається інформація про обчислювальні елементи (CE), які приймають завдання на виконання від користувачів учбової віртуальної організації kpiedu: [svistunov@ui ~]$ lcg-infosites --vo kpiedu ce #CPU Free Total Jobs Running Waiting ComputingElement ---------------------------------------------------------24 24 0 0 0 ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu [svistunov@ui ~]$ lcg-infosites --vo bitpedu ce #CPU Free Total Jobs Running Waiting ComputingElement ---------------------------------------------------------- Для відображається інформація про обчислювальні елементи (CE), які приймають завдання на виконання від користувачів об‘єднаної навчальної віртуальної організації edu, запит модіфікується: 289 [svistunov@ui ~]$ lcg-infosites --vo edu ce #CPU Free Total Jobs Running Waiting ComputingElement ---------------------------------------------------------3 3 0 24 24 0 1 1 0 0 0 0 0 vps117.jinr.ru:2119/jobmanager-pbs-edu 0 0 ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-edu ce.ngc6475.ihep.su:2119/jobmanager-lcgpbs-edu Приклад 2. В прикладі, наведеному нижче, відображається інформація про елементи зберігання даних (SE) в учбової віртуальної організації edu: [svistunov@ui ~]$ lcg-infosites --vo edu se Avail Space(Kb) Used Space(Kb) Type SEs ---------------------------------------------------------158235389 9663665 2825883 11 n.a n.a vps121.jinr.ru se.ngc6475.ihep.su Примітка. Унавчальній грід-інфраструктурі України на даний час не встановлено елементів зберігання даних. Якщо виконати дану команду, вказавши віртуальну організацію kpiedu, то одержимо відповідь яка наведена нижче. [svistunov@ui ~]$ lcg-infosites --vo kpiedu se Avail Space(Kb) Used Space(Kb) Type SEs ---------------------------------------------------------Приклад 3. 290 В прикладі, наведеному нижче, відображається інформація про найближчі обчислювальні елементи (CE) до елементу зберігання даних (se.ngc6475.ihep.su) у навчальній віртуальній організації edu: [svistunov@ui ~]$ lcg-infosites --vo edu closeSE Name of the CE: vps117.jinr.ru:2119/jobmanager-pbs-edu vps121.jinr.ru Name of the CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-edu Name of the CE: ce.ngc6475.ihep.su:2119/jobmanager-lcgpbs-edu se.ngc6475.ihep.su Приклад 4. В прикладі, наведеному нижче, відображається інформація про програмне забезпечення зареєстроване в інформаційної системі віртуальної організації atlas: [svistunov@ui ~]$ lcg-infosites --vo atlas tag valor del bdii: gt5.pnpi.nw.ru:2170 Name of the CE: cluster.pnpi.nw.ru VO-atlas-cloud-NL VO-atlas-offline-11.5.0 VO-atlas-offline-12.0.1 VO-atlas-offline-12.0.2 VO-atlas-production-12.0.3 VO-atlas-production-12.0.4 VO-atlas-production-12.0.5 VO-atlas-release-11.0.42 VO-atlas-release-11.0.5 VO-atlas-tier-T3 291 для Примітка. У навчальній грід-інфраструктурі України на даний час не встановлено додаткового програмного забезпечення для виконання лабораторних робіт. Якщо виконати дану команду, вказавши віртуальну організацію kpiedu, то одержимо відповідь яка наведена нижче. [svistunov@ui ~]$ lcg-infosites --vo edu tag Name of the CE: vps117.jinr.ru Name of the CE: ce.hpcc.kpi.ua Name of the CE: ce.ngc6475.ihep.su 2) Команда lcg-info - одержання характеристик грід- ресурсів. Ця команда використовується для одержання характеристик CE або SE, які задовольняють деяким умовам, і виводить значення заданої множини атрибутів. Інформація береться з BDII, визначеного змінною оточення LCG_GFAL_INFOSYS. Її синтаксис: lcg-info options [--bdii <bdii>] [--vo <vo>] [--sed] [--query <query>] [--attrs <list>] де: --vo - назва віртуальної організації (ВО), -query - команда запиту. Умова, якій повинні задовольняти відібранні CE(SE), --sed - вивід інформації в sed-орієнтованому форматі, 292 --bdii - URL серверу BDII, якщо використовується сервер, відмінний від сервера, визначеного в конфігураційному файлі грідсайту, --attrs - список атрибутів, які будуть виводитись для відібраних CE(SE), оptions – опції команди (табл.6.2). Таблиця 6.2. Опції команди lcg-info --list-attrs Список всіх атрибутів, які можуть бути в запиті та в списку для виводу --list-сe Список всіх СE, що задовольняють умові, або всіх СE, якщо умова не визначена --list-se Список всіх SE, що задовольняють умові, або всіх SE, якщо умова не визначена --help Відображення сторінки довідкової інформації Приклад 5. В прикладі, наведеному нижче, відображається список атрибутів (представлено частина списку), які підтримуються в інформаційної системі: [svistunov@ui ~]$ lcg-info --list-attrs Attribute name WorstRespTime CEAppDir Glue object class Glue attribute name GlueCE GlueCEStateWorstResponseTime GlueCE GlueCEInfoApplicationDir TotalCPUs GlueCE GlueCEInfoTotalCPUs MaxRunningJobs GlueCE GlueCEPolicyMaxRunningJobs CE GlueCE GlueCEUniqueID WaitingJobs MaxCPUTime GlueCE GlueCEStateWaitingJobs GlueCE GlueCEPolicyMaxCPUTime 293 LRMSVersion GlueCE GlueCEInfoLRMSVersion MaxTotalJobs GlueCE GlueCEPolicyMaxTotalJobs CEStatus GlueCE GlueCEStateStatus LRMS GlueCE GlueCEInfoLRMSType CEVOs GlueCE GlueCEAccessControlBaseRule AssignedJobSlots GlueCE GlueCEPolicyAssignedJobSlots FreeCPUs GlueCE GlueCEStateFreeCPUs RunningJobs GlueCE GlueCEStateRunningJobs EstRespTime GlueCE GlueCEStateEstimatedResponseTime FreeJobSlots GlueCE GlueCEStateFreeJobSlots Cluster GlueCE GlueCEInfoHostName TotalJobs GlueCE GlueCEStateTotalJobs Priority GlueCE GlueCEPolicyPriority Приклад 6. В наступному прикладі відображається список всіх обчислювальних елементів, які задовольняють наступну умову: загальна кількість процесорів >=10 і ОС Scientific Linux. Додатково виведено кількість завдань, що виконуються, і кількість вільних процесорів: [svistunov@ui ~]$ lcg-info --list-ce --query 'TotalCPUs>=10,OS=*SL*' -attrs 'RunningJobs,FreeCPUs' --vo edu - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-edu - RunningJobs - FreeCPUs 0 24 294 Як зазначено в прикладі синтаксис визначення умови має загальний вигляд: attr1 op1 valueN, ... attrN opN valueN , де attrN – ім‘я атрибута. Для запису логічного виразу використовуються позначення логічних операцій =, >= , <= . Декілька умов можуть бути об‘єднані через логічне «і». В якості розділювача використовується кома, пропуски не допускаються: [svistunov@ui ~]$ lcg-info --list-ce --query 'TotalCPUs>=10,OS=*SL*' -attrs 'RunningJobs,FreeCPUs' --vo kpiedu - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu - RunningJobs - FreeCPUs 0 24 Приклад 7. В наступному прикладі відображається список всіх обчислювальних елементів віртуальних організацій kpiedu та edu, у яких кількість вільних процесорів >=5 та додатково відображається кількість вільних процесорів: [svistunov@ui ~]$ lcg-info --list-ce --query 'FreeCPUs>=5' --attrs 'FreeCPUs' --vo kpiedu - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu - FreeCPUs 24 [svistunov@ui ~]$ lcg-info --list-ce --query 'FreeCPUs>=5' --attrs 'FreeCPUs' --vo edu - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-edu - FreeCPUs 24 295 Приклад 8. В наступному прикладі відображається повний список всіх обчислювальних елементів: [svistunov@ui ~]$ lcg-info --list-ce - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-edu - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-ukraine - CE: ce.ngc6475.ihep.su:2119/jobmanager-lcgpbs-dteam - CE: ce.ngc6475.ihep.su:2119/jobmanager-lcgpbs-edu - CE: ce.ngc6475.ihep.su:2119/jobmanager-lcgpbs-ops - CE: vps117.jinr.ru:2119/jobmanager-pbs-edu Приклад 9. В наступному прикладі відображається кількість вільних процесорів для обчислювальних елементів віртуальної організації edu: [svistunov@ui ~]$ lcg-info --list-ce --attrs 'FreeCPUs' --vo edu - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-edu - FreeCPUs 24 296 - CE: ce.ngc6475.ihep.su:2119/jobmanager-lcgpbs-edu - FreeCPUs 1 - CE: vps117.jinr.ru:2119/jobmanager-pbs-edu - FreeCPUs 3 Приклад 10. В наступному прикладі відображається список всіх „відміток‖ для встановленого програмного забезпечення на визначеному CE - cluster.pnpi.nw.ru: [svistunov@ui ~]$ lcg-info --list-ce --query 'CE=*ce.hpcc.kpi.ua:2119*' --attrs 'Tag' - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-edu - Tag GLITE-3_0_0 GLITE-3_1_0 LCG-2 LCG-2_1_0 LCG-2_1_1 LCG-2_2_0 - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu - Tag GLITE-3_0_0 GLITE-3_1_0 LCG-2 LCG-2_1_0 LCG-2_1_1 LCG-2_2_0 297 - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-ukraine - Tag GLITE-3_0_0 GLITE-3_1_0 LCG-2 LCG-2_1_0 LCG-2_1_1 LCG-2_2_0 Приклад 11. В наступному прикладі відображається список всіх CE з визначеним ПЗ для ВО kpiedu, на яких встановлено пакет програмного забезпечення LCG-2. Додатково виводиться кількість процесорів: [svistunov@ui ~]$ lcg-info --list-ce --vo kpiedu --query 'Tag=*LCG-2*' -attrs 'TotalCPUs' - CE: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu - TotalCPUs 24 Приклад 12. В наступному прикладі відображається список всіх елементів зберігання даних (SE), що задовольняють умові, для віртуальної організації edu, де об‘єм доступної пам‘яті >=100000Kb. Додатково виводиться найближчий SE: [svistunov@ui ~]$ lcg-info --list-se --vo edu --query 'AvailableSpace>=10000' --attrs 'CloseCE' - SE: se.ngc6475.ihep.su 298 - CloseCE ce.ngc6475.ihep.su:2119/jobmanager-lcgpbs-ops ce.ngc6475.ihep.su:2119/jobmanager-lcgpbs-edu ce.ngc6475.ihep.su:2119/jobmanager-lcgpbs-dteam - SE: vps121.jinr.ru - CloseCE vps117.jinr.ru:2119/jobmanager-pbs-edu Приклад 13. Для доступу до інформації яка зберігається на LDAP сервері, можна використовувати запит с використанням команди ldapsearch. Для GLUE схеми, яка реалізована в LDAP, коренева директорія (Directory Information Tree (DIT)) завжди: o=grid. Параметри запиту в команді ldapsearch залежать від рівня сервера інформаційної системи. Для GRIS рівня частка запиту mds-vo-name приймає значення: mds-vo-name=resource (для BDII сервісу порт 2170), а сама команда набуває вигляд: ldapsearch –x –H ldap://<Resource DN>:2170 –b mds-voname=resource,o=grid Для GIIS рівня сайту частка запиту mds-vo-name приймає значення: mds-vo-name=<SITE NAME> (BDII сервісу порт 2170)‫‏‬, а сама команда набуває вигляд: ldapsearch –x –H ldap://<SiteBDII DN>:2170 –b mds-vo-name=<SITE NAME>,o=grid 299 Для верхнього рівня (top BDII) частка запиту mds-vo-name приймає значення: mds-vo-name=local (BDII сервис порт 2170)., а сама команда набуває вигляд: ldapsearch –x –H ldap://<Resource DN>:2170 –b mds-voname=local,o=grid. В наступному прикладі ілюструється виконання запиту до серверу bdii.hpcc.kpi.ua за допомогою команди ldapsearch: [svistunov@ui ~]$ ldapsearch -LLL -x -h bdii.hpcc.kpi.ua:2170 -b "mds-voname=resource, o=grid" dn: Mds-Vo-name=resource,o=grid objectClass: GlueTop objectClass: Mds Mds-Vo-name: resource dn: GlueServiceUniqueID=bdii.hpcc.kpi.ua_bdii_top_1813027130,Mds-Vo-name=resou rce,o=grid objectClass: GlueTop objectClass: GlueService objectClass: GlueKey objectClass: GlueSchemaVersion GlueServiceUniqueID: bdii.hpcc.kpi.ua_bdii_top_1813027130 GlueServiceName: UA-KPI-HPCC-bdii_top GlueServiceType: bdii_top GlueServiceVersion: 3.0.0 GlueServiceEndpoint: ldap://bdii.hpcc.kpi.ua:2170/mds-vo-name=local,o=grid GlueServiceStatus: OK GlueServiceStatusInfo: bdii OK GlueServiceSemantics: https://twiki.cern.ch/twiki/bin/view/EGEE/BDII GlueServiceStartTime: 1970-01-01T03:00:00+03:00 300 GlueForeignKey: GlueSiteUniqueID=UA-KPI-HPCC GlueSchemaVersionMajor: 1 GlueSchemaVersionMinor: 3 dn: GlueServiceDataKey=FCR-URL,GlueServiceUniqueID=bdii.hpcc.kpi.ua_bdii_top_1 813027130,Mds-Vo-name=resource,o=grid objectClass: GlueTop objectClass: GlueServiceData objectClass: GlueKey objectClass: GlueSchemaVersion GlueServiceDataKey: FCR-URL GlueServiceDataValue: http://lcg-fcr.cern.ch:8083/fcr-data/exclude.ldif GlueChunkKey: GlueServiceUniqueID=bdii.hpcc.kpi.ua_bdii_top_1813027130 GlueSchemaVersionMajor: 1 GlueSchemaVersionMinor: 3 dn: GlueServiceDataKey=glite-info-service_version,GlueServiceUniqueID=bdii.hpc c.kpi.ua_bdii_top_1813027130,Mds-Vo-name=resource,o=grid objectClass: GlueTop objectClass: GlueServiceData objectClass: GlueKey objectClass: GlueSchemaVersion GlueServiceDataKey: glite-info-service_version GlueServiceDataValue: 1.5 GlueChunkKey: GlueServiceUniqueID=bdii.hpcc.kpi.ua_bdii_top_1813027130 GlueSchemaVersionMajor: 1 GlueSchemaVersionMinor: 3 dn: GlueServiceDataKey=glite-info-service_hostname,GlueServiceUniqueID=bdii.hp cc.kpi.ua_bdii_top_1813027130,Mds-Vo-name=resource,o=grid objectClass: GlueTop objectClass: GlueServiceData objectClass: GlueKey objectClass: GlueSchemaVersion 301 GlueServiceDataKey: glite-info-service_hostname GlueServiceDataValue: bdii.hpcc.kpi.ua GlueChunkKey: GlueServiceUniqueID=bdii.hpcc.kpi.ua_bdii_top_1813027130 GlueSchemaVersionMajor: 1 GlueSchemaVersionMinor: 3 Приклад 14. В наступному прикладі ілюструється виконання запиту для одержання значення двох атрибутів з класу GlueCESEBind для всіх грід-сайтів: [svistunov@ui ~]$ ldapsearch -LLL -x -h ce.hpcc.kpi.ua:2170 -b "mds-vo-name=resource, o=grid" \ 'objectclass=GlueCESEBind' GlueCESEBindCEUniqueID GlueCESEBindUniqueID dn: GlueCESEBindSEUniqueID=se.hpcc.kpi.ua,GlueCESEBindGroupCEUniqueID=ce.hpcc. kpi.ua:2119/jobmanager-lcgpbs-ukraine,Mds-Vo-name=resource,o=grid GlueCESEBindCEUniqueID: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-ukraine dn: GlueCESEBindSEUniqueID=se.hpcc.kpi.ua,GlueCESEBindGroupCEUniqueID=ce.hpcc. kpi.ua:2119/jobmanager-lcgpbs-edu,Mds-Vo-name=resource,o=grid GlueCESEBindCEUniqueID: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-edu dn: GlueCESEBindSEUniqueID=se.hpcc.kpi.ua,GlueCESEBindGroupCEUniqueID=ce.hpcc. kpi.ua:2119/jobmanager-lcgpbs-kpiedu,Mds-Vo-name=resource,o=grid GlueCESEBindCEUniqueID: ce.hpcc.kpi.ua:2119/jobmanager-lcgpbs-kpiedu 302 6.8 Доступ до даних інформаційної системи ARC Доступ до інформації, яка зберігається у інформаційної системі ARC, виконується за допомогою команди ldapsearch. В запиті необхідно вказати LDAP сервер, з якого отримується відповідь. Наступні приклади ілюструють виконання запитів. Приклад 15. [svistunov@nordug ~]$ ldapsearch -h nordug.bitp.kiev.ua -p 2135 -x -b 'mds-voname=local,o=grid' 'objectclass=nordugrid-cluster' # extended LDIF # # LDAPv3 # base <mds-vo-name=local,o=grid> with scope subtree # filter: objectclass=nordugrid-cluster # requesting: ALL # # nordug.bitp.kiev.ua, local, Grid dn: nordugrid-cluster-name=nordug.bitp.kiev.ua,Mds-Vo-name=local,o=Grid objectClass: Mds objectClass: nordugrid-cluster nordugrid-cluster-name: nordug.bitp.kiev.ua nordugrid-cluster-aliasname: BITP Cluster nordugrid-cluster-comment: i686-linux-gnu arch cluster nordugrid-cluster-owner: Bogolyubov Institute for Theoretical Physics nordugrid-cluster-acl: VO:Ukraine nordugrid-cluster-location: UA-03143 nordugrid-cluster-issuerca: /DC=org/DC=ugrid/CN=UGRID CA nordugrid-cluster-issuerca-hash: 0a12b607 nordugrid-cluster-trustedca: /C=AM/O=ArmeSFo/CN=ArmeSFo CA nordugrid-cluster-trustedca: /C=AR/O=e-Ciencia/OU=UNLP/L=CeSPI/CN=PKIGrid nordugrid-cluster-trustedca: /C=PK/O=NCP/CN=PK-GRID-CA nordugrid-cluster-trustedca: /C=PL/O=GRID/CN=Polish Grid CA 303 nordugrid-cluster-trustedca: /C=PT/O=LIPCA/CN=LIP Certification Authority nordugrid-cluster-trustedca: /C=RS/O=AEGIS/CN=AEGIS-CA nordugrid-cluster-trustedca: /C=RU/O=RDIG/CN=Russian Data-Intensive Grid CA nordugrid-cluster-trustedca: /C=SE/O=AddTrust AB/OU=AddTrust External TTP Netw ork/CN=AddTrust External CA Root nordugrid-cluster-trustedca: /C=SI/O=SiGNET/CN=SiGNET CA nordugrid-cluster-trustedca: /C=SK/O=SlovakGrid/CN=SlovakGrid CA nordugrid-cluster-trustedca: /C=TH/O=NECTEC/OU=GOC/CN=NECTEC GOC CA nordugrid-cluster-trustedca: /C=TR/O=TRGrid/CN=TR-Grid CA nordugrid-cluster-trustedca: /C=TW/O=AS/CN=Academia Sinica Grid Computing Cert ification Authority Mercury nordugrid-cluster-trustedca: /C=UA/O=BITP/OU=HEPD/CN=UA-BITP nordugrid-cluster-trustedca: /C=UA/ST=Kyiv/L=Kyiv/O=National Taras Shevchenko University of Kyiv/O=Information & Computer Center/OU=cluster/CN=cluster.univ .kiev.ua/emailAddress=cluster@univ.kiev.ua nordugrid-cluster-trustedca: /C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science C A nordugrid-cluster-trustedca: /C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root nordugrid-cluster-trustedca: /C=US/O=National Center for Supercomputing Applic ations/OU=Certificate Authorities/CN=GridShib CA nordugrid-cluster-trustedca: /C=US/O=National Center for Supercomputing Applic ations/OU=Certificate Authorities/CN=MyProxy nordugrid-cluster-trustedca: /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Netw ork/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware nordugrid-cluster-trustedca: /C=VE/O=Grid/O=Universidad de Los Andes/OU=CeCalC ULA/CN=ULAGrid Certification Authority nordugrid-cluster-trustedca: /DC=BR/DC=UFF/DC=IC/O=UFF LACGrid CA/CN=UFF Latin American and Caribbean Catch-all Grid CA nordugrid-cluster-trustedca: /DC=CN/DC=Grid/CN=Root Certificate Authority at C NIC nordugrid-cluster-trustedca: /DC=CN/DC=Grid/DC=SDG/CN=Scientific Data Grid CA nordugrid-cluster-trustedca: /DC=EDU/DC=UTEXAS/DC=TACC/O=UTAUSTIN/CN=TACC Cla ssic CA nordugrid-cluster-trustedca: /DC=EDU/DC=UTEXAS/DC=TACC/O=UTAUSTIN/CN=TACC Roo t CA 304 nordugrid-cluster-trustedca: /DC=HK/DC=HKU/DC=GRID/CN=HKU Grid CA nordugrid-cluster-trustedca: /DC=IN/DC=GARUDAINDIA/CN=Indian Grid Certification Authority nordugrid-cluster-trustedca: /DC=LV/DC=latgrid/CN=Certification Authority for Latvian Grid nordugrid-cluster-trustedca: /DC=MD/DC=MD-Grid/O=RENAM/OU=Certification Autho ity/CN=MD-Grid CA nordugrid-cluster-trustedca: /DC=NET/DC=PRAGMA-GRID/CN=PRAGMA-UCSD CA nordugrid-cluster-trustedca: /DC=ORG/DC=SEE-GRID/CN=SEE-GRID CA nordugrid-cluster-trustedca: /DC=RO/DC=RomanianGRID/O=ROSA/OU=Certification Authority/CN=RomanianGRID CA nordugrid-cluster-trustedca: /DC=TW/DC=ORG/DC=NCHC/CN=NCHC CA nordugrid-cluster-trustedca: /DC=bg/DC=acad/CN=BG.ACAD CA nordugrid-cluster-trustedca: /DC=by/DC=grid/O=uiip.bas-net.by/CN=Belarusian G id Certification Authority nordugrid-cluster-trustedca: /DC=ch/DC=cern/CN=CERN Root CA nordugrid-cluster-trustedca: /DC=ch/DC=cern/CN=CERN Trusted Certification Auth ority nordugrid-cluster-trustedca: /DC=cz/DC=cesnet-ca/CN=CESNET CA nordugrid-cluster-trustedca: /DC=cz/DC=cesnet-ca/O=CESNET CA/CN=CESNET CA 3 nordugrid-cluster-trustedca: /DC=cz/DC=cesnet-ca/O=CESNET CA/CN=CESNET CA Root nordugrid-cluster-trustedca: /DC=es/DC=irisgrid/CN=IRISGridCA nordugrid-cluster-trustedca: /DC=org/DC=balticgrid/CN=Baltic Grid Certification Authority nordugrid-cluster-trustedca: /DC=org/DC=ugrid/CN=UGRID CA nordugrid-cluster-trustedca: /O=Grid/O=NorduGrid/CN=NorduGrid Certification Authority nordugrid-cluster-trustedca: /O=Grid/OU=GlobusTest/OU=simpleCAlcg.bitp.kiev.ua/CN=Globus Simple CA nordugrid-cluster-contactstring: gsiftp://nordug.bitp.kiev.ua:2811/jobs nordugrid-cluster-support: dkarpenko@bitp.kiev.ua nordugrid-cluster-lrms-type: PBSPro nordugrid-cluster-lrms-version: 10.0.0.82981 nordugrid-cluster-lrms-config: Up to 4 jobs per node 305 nordugrid-cluster-architecture: x86_64 nordugrid-cluster-opsys: Scientific Linux 4 nordugrid-cluster-opsys: 2.6.9-34.ELsmp nordugrid-cluster-homogeneity: TRUE nordugrid-cluster-nodecpu: 2xIntel(R) Xeon(TM) CPU 2.80GHz nordugrid-cluster-nodememory: 4092 nordugrid-cluster-nodeaccess: outbound,8Mbps nordugrid-cluster-totalcpus: 96 nordugrid-cluster-usedcpus: 0 nordugrid-cluster-cpudistribution: 8cpu:12 nordugrid-cluster-prelrmsqueued: 0 nordugrid-cluster-totaljobs: 0 nordugrid-cluster-sessiondir-free: 26692 nordugrid-cluster-sessiondir-total: 31555 nordugrid-cluster-sessiondir-lifetime: 4320 nordugrid-cluster-cache-free: 26692 nordugrid-cluster-cache-total: 31555 nordugrid-cluster-middleware: nordugrid-arc-0.8.3.1 nordugrid-cluster-middleware: globus-5.0.2 nordugrid-cluster-middleware: AliEn nordugrid-cluster-runtimeenvironment: VIRGO/GADGET nordugrid-cluster-runtimeenvironment: VIRGO/COSMOMC nordugrid-cluster-runtimeenvironment: INTEL-MPI nordugrid-cluster-runtimeenvironment: GROMACS nordugrid-cluster-runtimeenvironment: ROOT-2704 nordugrid-cluster-credentialexpirationtime: 20110607162231Z Mds-validfrom: 20110106131959Z Mds-validto: 20110106132029Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 306 Приклад 16. В наступному прикладі відображається список всіх активних грідзадач, які зареєстровані в локальній інформаційній системі на обчислювальному ресурсі: [svistunov@nordug ~]$ ldapsearch -h nordug.bitp.kiev.ua -p 2135 -x -b 'mds-voname=local,o=grid' 'objectclass=nordugrid-job' # gsiftp://nordug.bitp.kiev.ua:2811/jobs/112391291992797875472109, jobs, nord u, nordug.bitp.kiev.ua, local, Grid dn: nordugrid-job-globalid=gsiftp://nordug.bitp.kiev.ua:2811/jobs/112391291992 797875472109,nordugrid-info-group-name=jobs,nordugrid-queue-name=nordu,nordug rid-cluster-name=nordug.bitp.kiev.ua,Mds-Vo-name=local,o=Grid objectClass: Mds objectClass: nordugrid-job nordugrid-job-globalid: gsiftp://nordug.bitp.kiev.ua:2811/jobs/112391291992797 875472109 nordugrid-job-globalowner: /DC=org/DC=ugrid/O=people/O=UGRID/CN=Oleksandr Bory sov nordugrid-job-jobname: esc2drate_b100_48 nordugrid-job-execcluster: nordug.bitp.kiev.ua nordugrid-job-execqueue: nordu nordugrid-job-submissionui: 194.44.37.138:53659;nordug.bitp.kiev.ua nordugrid-job-submissiontime: 20101210145317Z nordugrid-job-sessiondirerasetime: 20101213152323Z nordugrid-job-proxyexpirationtime: 20101212182549Z nordugrid-job-gmlog: gridlog nordugrid-job-clientsoftware: nordugrid-arc-0.8.3 nordugrid-job-cpucount: 1 nordugrid-job-usedcputime: 0 nordugrid-job-usedwalltime: 0 nordugrid-job-status: DELETED 307 Mds-validfrom: 20110106132244Z Mds-validto: 20110106132314Z # search result search: 2 result: 0 Success # numResponses: 21 # numEntries: 20 6.9 Завдання до лабораторної роботи 1. Використовуючи команди запитів до інформаційної системи, одержати статичну та динамічну інформацію про грід-сайти навчальної інфраструктури. 2. Скласти протокол виконання лабораторної роботи. Протокол повинен містити: скріншоти виконання команд запитів до інформаційної системи. 6.10 1. Контрольні питання Основні функції системи інформаційного обслуговування та моніторингу як складової частини проміжного програмного забезпечення. 2. Monitoring and Discovery Service (MDS). Основні компоненти та взаємодія. 3. GLUE схема представлення даних по грід-системі. 4. Архітектура R-GMA. 5. Служба директорій LDAP (Lightweight Directory Access Protocol). Побудова та використання в інформаційної системі. 6. Типи постачальників в gLite R-GMA. 7. Команди доступу до даних інформаційної системи gLite. 308 8. Команда ldapsearch для доступу до даних інформаційної системи. 9. Рівні моніторингу в грід. 10. Система моніторингу GridMap. Побудова, призначення, основні завдання. 11. Система моніторингу MonALISA. Побудова, призначення, основні завдання. 12. Система моніторингу GridICE. Побудова, призначення, основні завдання. 13. Система моніторингу GSTAT . Побудова, призначення, основні завдання. 14. Система моніторингу Sites Functional Tests. Побудова, призначення, основні завдання. 15. Система моніторингу Nagios. Побудова, призначення, основні завдання. Література 1. Grid Computing Making the Global Infrastructure a Reality, edited by Fran Berman, Geoffrey Fox, Tony Hey. – (Wiley series in communications networking & distributed systems), 2003 , 1007 с. 2. Openldap. http://www.openldap.org 3. Monitoring and Discovery Services. http://www.globus.org/mds/mds2/ 4. Runtime Environment Registry, http://www.csc.fi/grid/rer/ 5. The GLUE Information model versin 1.2 http://infnforge.cnaf.infn.it/glueinfomodel/ 6. BDII homepage, https://twiki.cern.ch/twiki/bin/view/EGEE/BDIIv4 7. http://networkmonitorsoftware.net/appplication/. 309 8. http://dashboard.cern.ch/ 9. Tierney B. et al.: A Grid Monitoring Service Architecture. Global Grid Forum Performance Working Group, 2001 10. http://gstat-prod.cern.ch/gstat/about 11. http://event.twgrid.org/isgc2007/presentation/OperationandManagement I-RajeshKalmady-03292007.pdf 12. http://gridice.forge.cnaf.infn.it/ 13. http://www.hep.ac.uk/ 14. http://lemon.web.cern.ch/lemon/index.shtml 15. http://www.nagios.org/ 16. http://ganglia.sourceforge.net/ 310 Завдання № 7. Реєстрація і отримання користувачем доступу до грід- системи через веб- сервіс Мета: вивчення архітектури побудови порталів доступу до ресурсів промислових грід, які працюють під управлінням проміжного програмного забезпечення gLite і ARC, ознайомлення с існуючими бібліотеками для побудови веб- сервісів та набуття практичних навичок розробки веб – сторінки для відправлення завдання на виконання в навчальну грід – систему. 7.1 Короткі теоретичні відомості. Концепція наукового шлюзу (Science Gateways) Портал (portal) – точка доступу до різнорідних інформаційних ресурсів і програмних Використання терміну застосувань портал (або пов‘язане програмних не з додатків). інформаційною спрямованістю матеріалу, а з концепцією побудови його архітектури. Архітектура порталу містить ядро системи та набор компонентів, які забезпечують основну функціональність порталу. Розширення використання веб-сервісів (XML Web Services) і грід для реальних промислових проектів пов'язане з можливістю створення динамічних грід-застосувань, які б дозволяли враховувати специфічні вимоги та конфігурацію завдань користувача, надавати послуги за вимогою (on-demand), а також обслуговувати динамічно створювані віртуальні організації користувачів. Запропонована Global Grid Forum (GGF - організація стандартизації в грід) Відкрита Архітектура ГрідСервісів (ОГСА, OGSA - Open Grid Services Architecture) визначає базові грід-сервіси та інтерфейси і надає базову платформу для 311 створення розподілених динамічних грід-застосувань (програмних додатків). Важливо відзначити, що OGSA припускає реалізацію грідсервісів на основі веб-сервісів, використовуючи спеціальний профіль для опису веб-сервісів у вигляді ресурсів зі станом WSRF (Web Services Resource Framework). Реалізація грід-застосувань вимагає спеціальної інфраструктури грід-сервісів (GridMW - Grid middleware), яка включає інфраструктуру обміну повідомленнями і інфраструктуру загальних грід-сервісів, які архітектурно розміщаються між рівнем застосувань і мережевим рівнем. GridMW знайшла свій розвиток у рамках великих міжнародних проектів і консорціумів, таких як EGEE (Enabling Grid for E-sciencE, http://public.eu-egee.org/), OSG (Open http://www.opensciencegrid.org), (http://www.globus.org/). Однак і існуючі Science Globus рішення Grid, Alliance в основному орієнтовані на об'єднання в грід розподілених обчислювальних ресурсів. Більше широке застосування грід для підтримки розподілених систем колективної роботи (GCE - Grid-based Collaborative Environment) вимагає рішення безлічі додаткових технічних і операційних питань, як на архітектурному рівні, так і на рівні самих грід-сервісів. У першу чергу це стосується динамічного запуску на виконання грід-сервісів і підтримки відповідних послуг безпеки в динамічному режимі роботи грід-застосувань. За останні кілька років, з появою специфікації WSRF (Web Services Resource Framework), сервіс - орієнтована архітектура (SOA) і Web технології стали активно використовуватися при побудові грід- 312 систем для вирішення наукових завдань. У проекті Teragrid такі грідсистеми одержали назву наукових шлюзів (Science Gateways). Мета наукового шлюзу полягає в тому, щоб надати співтовариству користувачів доступ до наукових інструментів і застосувань, які виконуються на внутрішніх обчислювальних ресурсах. Користувачі повинні працювати із цими програмами як з розширенням свого робочого стола без турботи про те, що для організації таких обчислень потрібне потужне грід-середовище. Звичайно ці шлюзи організуються за допомогою Web-порталу та набору деяких утиліт. На поточний час існує безліч прикладів шлюзових систем, які відрізняються за архітектурою та переліком сервісів. У більшості випадків сервіси шлюзів надбудовуються безпосередньо над компонентами OGSA таким чином, що грід-рівень є практично непомітним. Можна виділити два типи наукових шлюзів. Перший тип це наукові шлюзи, яки служать для з'єднання декількох грідінфраструктур. Прикладом шлюзів такого типу є існуючий шлюз між TeraGrid і Open Science Grid (OSG). Він надає користувачам OSG доступ до ресурсів TeraGrid. Другий тип шлюзів являє собою набір інструментів, які забезпечують прозорий доступ до віддалено працюючих додатків і баз даних великій кількості користувачів. Звичайно ці системи використовують Web-портал і додаткові інструменти. Існує безліч вдалих прикладів організації такого типу сервісної архітектури. Деякі проекти будуються на основі потужної грід-інфраструктури, подібної OGSA, у той час як інші істотно спрощені, не вимагають такої потужної основи, а замість цього реалізують певні функції базового проміжного програмного забезпечення самостійно. Прикладом таких проектів є система Taverna, широко використовувана в біомедицині, засоби компонування потоків 313 Kepler і Triana. Останні реалізовані у вигляді настільних інструментів компонування потоків для реалізації простих сервісів, однак вони самі також можуть бути використані як компоненти більше великої грідархітектури. Організація наукових шлюзів на основі OGSA-подібної грідінфраструктури є більш комплексним завданням, рішення якого дозволяє отримати значно більше можливостей. На рисунку 7.1 зображений варіант архітектурної моделі наукового шлюзу. Рис. 7.1 – Сервіс - орієнтована архітектура наукового шлюзу Функції шлюзу, побудованого на основі даної моделі, зводяться до наступного. Портал-сервер ідентифікує користувача та установлює авторизацію для доступу до даних і ресурсів застосувань. Застосування, як правило, реалізуються у вигляді послідовності процесів (потоків), які виконуються від імені користувача. Для створення цих потоків портал надає користувачу програми-утиліти із графічним інтерфейсом, що дозволяє компонувати потоки з набору цих програмних компонентів. 314 Програми-утиліти компілюють графічне представлення створеного потоку у внутрішній опис процесів і протоколів їхньої взаємодії (наприклад, за допомогою мови BPEL), що зберігається в модулі управління потоками й модулі метаданих. Модуль управління потоками повинен взаємодіяти з метаданими застосування й сервісами даних, реєстром програмних додатків, директоріями даних, брокером ресурсів грід, сервісом повідомлень і сервісами застосувань для організації виконання потокових завдань. Для кожного доступного застосування існує свій сервіс, що забезпечує його запуск і виконання в складі потоку. На основі інформації, отриманої від реєстру даних і застосувань, модуль управління потоками ініціює через брокер ресурсів запуск сервісу застосування для виконання останнього на призначеному обчислювальному ресурсі. У випадку збою модуль управління потоками забезпечує перезапуск застосування, якщо це ще актуально в контексті потоку, який виконується. Модуль (змішування) даних і метаданих виконує функції маппування та синхронізації вхідних, вихідних і метаданих з абстрактними унікальними ідентифікаторами, які використовуються в грід-середовищі для операцій з даними. Сервіси повідомлень використовуються для реєстрації та моніторингу роботи застосувань. Вони здатні реєструвати деякі задані події і передавати повідомлення про це модулю управління потоками для корегування або зміни ходу процесів, які виконуються. Кожний сервіс застосування генерує події про поточний стан програми протягом усього часу її роботи. На основі цих подій складається повна історія експерименту, який виконується, що дає можливість аналізувати 315 кожний крок процесу та забезпечити інформацію про походження всіх даних, отриманих у ході експерименту. Гнучкість сервіс-орієнтованої архітектури наукових шлюзів дозволяє виконувати застосування у вигляді простих компонентів на будь-яких платформах, але це реалізується за допомогою прозорої для користувача взаємодії з могутнішими та більш безпечними грідсервісами. Сервісна компонентів, яка архітектури здатна шлюзу організувати у вигляді виконання модульних застосувань необхідним чином і на необхідних ресурсах, дає можливість побудувати систему, яка працює в локальному оточенні, але в той же час може використовувати потужності більших грід-систем. 7.2 Інструментальні засоби побудови грід- порталів застосувань Грід - портали визначаються як клас серверних Інтернет додатків, яки забезпечують захищений інструментарій для он - лайнового збору інформації про грід - сервіси й грід - ресурси і що надає інструментальні засоби для використання цих грід - сервісів і грід ресурсів для цілей виконання користувальницьких завдань [6] . Організація Grid Computing Environment Research Group розділяє портали на дві групи: користувальницькі портали і портали застосувань [7]. Перша група орієнтована на забезпечення доступу користувачів, об'єднаних у віртуальні організації (Virtual Organization - VO) для рішення спільних наукових завдань, потребуючих значних обчислювальних ресурсів. При цьому цей доступ реалізується в вигляді заміни стандартного доступу до ресурсу за допомогою термінальної системи на систему доступу через портал. Друга група порталів орієнтована на забезпечення доступу не тільки до грід-ресурсів, але й 316 для полегшення підготовки даних для інженерних пакетів і використання цих пакетів у грід- середовищі. Прикладами вдалого використання портальних рішень для виконання наукових розрахунків можуть бути портали: Cactus [6], Astrophysics Simulation Collaboratory (ASC) [8], PACI HotPage [9]. Однак, вже при створенні перших портальних систем розробники зрозуміли, що для полегшення програмування порталу та стандартизації роботи з функціями доступу к грід-ресурсам необхідно користуватись набором відповідних інструментальних засобів. Так з'явився інструментарій розробника GridPort toolkit [10], який був використаний при створенні PACI HotPage, або - Grid Portal Development Toolkit (GPDK) [11]. Ці інструментальні засоби являють собою API бібліотеки на фундаменті сервісів Globus. Наявність інструментальних засобів дозволило розробникам порталів сконцентрувати свої зусилля на розробці прикладних портальних програм і на реалізації логіки використання інженерних пакетів, виділивши функції Globus в окремі стандартизовані бібліотеки. 7.3 Інструментальні засоби на основі Globus Toolkit Інструментарій, названий Commodity Grid Kits [12], був створений для простого та природного використання функцій і сервісів Globus [13] у мовах програмування, таких як Perl, Python або Java. Основна ідея цього інструментарію – дозволити користувачам за допомогою CGK забезпечити доступ до грід-сервісів. GridPort toolkit – це API бібліотеки на мові програмування Perl, побудовані як надбудова над бібліотеками Perl CoG [14]. Вони використовують бібліотеки Globus Toolkit для доступу до розподілених ресурсів при виконанні завдань і отриманні інформації про сервіси. 317 Тому, для своєї роботи, вона вимагає, щоб була встановлена локальна копія Globus клієнта. Використання інструментальних засобів Commodity Grid Kits у порталі вимагає, щоб користувач мав дійсних Globus сертифікат для доступу до обчислювальних грід-ресурсів. Інструментальний засіб Grid Portal Development Toolkit (GPDK) є Java бібліотекою, побудованої на основі Java CoG [15]. Цей інструментарій містить у собі Globus клієнт і не вимагає установки цього програмного забезпечення на клієнтській стороні. Портал, побудований на основі цього інструментарію, так само, для своєї роботи вимагає дійсний Globus сертифікат користувача. Бібліотека GridSphere [16] є частиною GridLab [17] проекту та надає програмісту веб застосувань модель портлету (portlet). Портлет, це стандартний портальний компонент інтерфейсу користувача. Якщо портлет для застосування вже розроблений, то користувач може його вибрати та підключити, що дає можливість створити свій персональний грід-портал. Проект Open Grid Computing Environment (OGCE) [18], який виконувався під егідою US National Science Foundation, забезпечує загальне грід-портальне рішення, яке дозволяє об'єднати зусилля багатьох розробників у цій галузі. Іншим прикладом забезпечення доступу до веб - сервісів на основі портальних рішень є myGrid [19], частина проекту UK e-Science. Представлені інструментальні засоби є як простими API, так і складними портлетними моделями, яки підтримують веб-сервіси. Загальними для всіх цих інструментальних засобів є те, що розроблені за їх допомогою портали припускають інтерактивну взаємодію безпосередньо із грід - сервісами і розробники таких порталів повинні 318 бути фахівцями з грід - технологій та веб-програмування. Інформація про найбільш поширені Європі грід-портали узагальнена в табл.7.1. 7.4 Інструментальний засіб GridSpeed Основна мета розробки інструментального засобу GridSpeed [20], виконаного в Tokyo Institute of Technology (TiTech), це дати можливість користувачам динамічно генерувати портали застосувань без створення програмного коду. Узагальнена схема архітектури порталу програмних застосувань на основі GridSpeed [21] представлена на рисунку 7.2. Рис. 7.2 - Архітектура GridSpeed Для динамічної генерації порталу застосувань і наступної його публікації (розміщенні на веб-сервері) використовується система веб сторінок, названа Grid Portal Generation Wizard. Така система дозволяє користувачеві за допомогою спеціальних веб-сторінок виконати візуальне проектування необхідних грід-ресурсів і програм, які будуть 319 використовуватися. На основі цієї інформації надалі генерується портал і, за допомогою спеціальної системи GridSpeed Portal Repository (Descriptor Repository), виконується його публікація. Сгенерований портал публікується на сервері GridSpeed і стає доступним користувачам. Так само сервер підтримує рольовий механізм прав доступу користувачів до розміщених на сервері порталів. Система GridSpeed забезпечує роздільне зберігання інформації про доступні ресурси та програми. Це дозволяє створювати портали, які виконують завдання користувачів з використанням програмних застосувань на різних ресурсах. використовуючи Крім створений того, адміністратор користувачем порталу прикладний порталу, побудувати новий для нового набору ресурсів. може, інтерфейс Система GridSpeed підтримує створення порталу орієнтованого на структуру конкретного застосування. Так само, система GridSpeed підтримує розподіл грід-ресурсів, яки працюють під управлінням різного програмного забезпечення проміжного рівня. У даний момент GridSpeed підтримує: 1) одноразовий запуск завдання на виконання; 2) запуск однієї і того ж завдання з різними наборами даних; 3) комбінацію зазначених вище способів з можливістю визначення залежності між завданнями. Завдання першого типу відповідають множині обчислювальних застосувань, наприклад, порівняння отриманих експериментальних даних з обраною моделлю. Другий тип завдань характеризує параметричні задачі та найбільше підходить для використання грід-ресурсів, коли таж сама розрахункова програма запускається на виконання з різними наборами даних на розподілених ресурсах. 320 Завдання більш складної обчислювальної структури відносяться до третього типу. Для таких завдань GridSpeed також реалізує просту схему управління потоком завдань. Різні застосування використовують різні сервіси, такі як, Globus та SSH, різні планувальники завдань Condor, LoadLeveler, LSF, PBS і різні служби передачі даних: GridFTP, SRB. Система GridSpeed дозволяє враховувати ці особливості на верхньому рівні опису ресурсів для конкретного застосування. На даний момент у системі реалізовані планувальники завдань DAGMan [24] та UNICORE [23]. Система Grid Portal Generation Wizard організований як система веб-сторінок, які послідовно завантажуються і у яких користувач відповідає на запитання з використання грід-ресурсів для обраної програми. Результатом є сгенеровані порталом два об'єкти: об'єкт опису ресурсів (computing environment object), який описує ресурси зберігання даних, обчислювальні ресурси, протокол передачі даних, і об'єкт опису застосування (application object), який включає опис програми, дані, форми і т.п. Об‘єкти, які створені користувачем, можуть використовуватися і для побудови інших портальних застосувань. 7.5 Проект Grid Programming Environment Проект Grid Programming Environment (GPE) компанії Intel призначений для створення універсального інтерфейсу до різних реалізацій проміжного програмного грід-забезпечення. Основна ідея універсального інтерфейсу полягає в тому, щоб виділити з різних реалізацій деяку загальну функціональність, яка повинна бути у будь якої грід-платформи, і реалізувати її у вигляді деякого інструментарію високого рівня. При цьому реалізація даної функціональності буде різною для кожного конкретного 321 проміжного програмного забезпечення. Схожі ідеї багаторазово зустрічалися і раніше. Як приклад можна згадати всім відому технологію Java. Нагадаємо, що програми на Java можуть бути трансльовані в байт-код, який виконується на віртуальній машині Java (JVM). Віртуальна машина Java, у свою чергу, під різні операційні системи має окремі реалізації. Таким чином, програміст розробляє свої програмні додатки, не замислюючись про те, під якою операційною системою вони будуть функціонувати. Розробники інструментарію GPE прагнули зробити ситуацію з розробкою грід-застосувань дуже схожої на розглянуту вище. При цьому програміст, спираючись на універсальний інтерфейс, повинен розробити грід-застосування лише один раз, не замислюючись про апаратну частину і можливості конкретного проміжного програмного забезпечення. Розвиток даного підходу є серйозним кроком на шляху до успіху всієї грід-технології. На даний час розробка інструментарію GPE ведеться в рамках проекту Open Source і доступна для вільного завантаження з ресурсу SourceForge.net (http://gpe4gtk.sourceforge.net). Вирішити проблему універсального інтерфейсу заважає також і різноманіття інтерфейсів користувача самих програмних застосувань (різних у різних завданнях). Різні прикладні програми можуть мати користувальницькі інтерфейси, які дуже різняться і які досить важко об'єднати в єдиній системі (наприклад, програма тривимірного моделювання або редактор тексту). Очевидно, єдиним розумним шляхом у цієї ситуації є розробка гнучкої клієнтської інфраструктури, яка дозволяла б розробникам грід-застосувань розширювати користувальницький інтерфейс базового клієнтського програмного додатку, виходячи з конкретного завдання, яке потрібно виконати за допомогою грід - ресурсів. Таким чином, користувач зможе працювати 322 із клієнтською частиною системи, яка наділена зручним проблемноорієнтованим інтерфейсом користувача. Варто відмітити, що розробники інструментарію GPE приділили цьому питанню велику увагу, запропонувавши відразу кілька графічних клієнтів для своєї системи з можливістю розширення інтерфейсу користувача. Підбиваючи підсумок всьому вищезазначеному, можна виділити наступні передумови створення інструментарію GPE:  необхідно вирішити проблему взаємодії та інтеграції між різними реалізаціями проміжного програмного грід-забезпечення;  необхідно надати розробникам простий високорівневий механізм впровадження існуючих застосувань, що не вимагає істотних змін коду програми;  необхідно надати користувачам розвинену клієнтську інфраструктуру, що дозволяла б вирішувати ті або інші завдання, взаємодіючи зі зручним проблемно-орієнтованим інтерфейсом користувача. Отже, система GPE являє собою високорівневий інструментарій, заснований на стандартах, і інтерфейс, який забезпечує одночасно декілька реалізацій проміжного програмного грід-забезпечення. Використання даного інструментарію дозволяє полегшити процес переносу застосувань у грід. Програма адаптується тільки до інструментарію GPE. Підтримка ж інших реалізацій грід-систем забезпечується автоматично на основі універсального інтерфейсу. Інструментарій GPE дозволяє користувачам і розробникам одержати прозорий доступ до розподілених обчислювальних ресурсів і ресурсів зберігання даних за допомогою технології веб-сервісів. Проілюструємо це на багаторівневій архітектурній схемі інструментарію GPE (рис. 7.3). 323 GUI Framework Applications GridBean SDK Service Registry Services BPEL Workflow Service Atomic Services TSI OS Repository Service Resource Broker GridBean Service Atomic Services TSI TSI TSI Basic GridServices Interface Utility Data Center Data Center Рис. 7.3 – Архітектура інструментарію GPE На самому верхньому рівні – рівні програмних додатків (Applications) – GPE надає набір із засобів розробки, утиліт і документації (GridBean SDK), який дозволяє програмістам створювати грід-застосування, що не залежать від конкретної грід-платформи, з проблемно-орієнтованим користувальницьким інтерфейсом. На цьому ж рівні перебуває клієнтська частина інструментарію (GUI Framework), яка дозволяє сховати складність технологій, яки знаходяться на нижчих рівнях, від користувача. Клієнтам GPE надається графічний інтерфейс користувача, реалізований у вигляді звичайних Java-програм або вебпорталів. Для доступу до грід середовища необхідна тільки встановлення клієнтської частини GPE, за допомогою якої здійснюється взаємодія з високорівневими грід-сервисами. Для доступу до грід через веб-портал користувачеві взагалі не потрібна інсталяція якого-небудь додаткового програмного забезпечення на комп'ютер. Доступ забезпечується за допомогою стандартного браузера. У цьому випадку доступ до грід-середовища можна отримати, наприклад, з Інтернет-кафе 324 або з малопотужного кишенькового комп'ютера, підключеного до мережі . Далі йде рівень високорівневих грід-сервісів (Services), призначених для управління даними користувача та завданнями, які можуть бути виконані на різних реалізаціях проміжного програмного забезпечення, а також для виконання деяких інших операцій. Розглянемо основні високорівневі грід-служби, які використовує інструментарій GPE:  Сервіси управління ресурсами й реєстр цільових систем (Dynamic Resource and Service Registry) – призначені для зберігання інформації про доступні обчислювальні ресурси й зареєстровані цільові системи, а також для управління грід-ресурсами;  Сервіс виконання BPEL-Процесів (BPEL Workflow Service), який призначений для виконання процесів (workflows), описаних у термінах мови Business Process Execution Language (BPEL);  Сховище образів ОС (OS Repository Service), що забезпечує доступ до бінарних образів операційних систем, які містять настроєні середовища функціонування грід-служб, готові для установки на доступні обчислювальні ресурси;  Сервіс завантаження GridBean (GridBean Service), який надає користувачам останні версії грід-застосувань. Всі високорівневі грід-служби в процесі своєї роботи звертаються до базових грід-служб або до атомарних сервісів (Atomic Services). Атомарні сервіси призначені для управління грід-вузлом (у ролі якого може виступати, наприклад, кластер або суперкомп'ютер) і забезпечення безпечного доступу до нього через мережу Інтернет. Для кожної підтримуваної реалізації проміжного програмного забезпечення 325 необхідна своя реалізація даних сервісів, оскільки саме на цьому рівні проявляються відмінності різних реалізацій. Основні атомарні сервіси, реалізовані в інструментарії GPE:  Target System Factory Service – створення ресурсів, відповідальних за цільові системи;  Target System Service – відправлення завдань на цільову систему, доступ до розподілених файлових систем;  Job Management Service – управління запущеними на цільовій системі завданнями, доступ до розподілених файлових систем;  Storage Management Service – управління файлами на цільовій системі, ініціювання імпорту й експорту файлів;  File Transfer Service – передача даних по відповідному протоколу. Нарешті, найнижчим рівнем у розглянутій архітектурі є інтерфейс цільової системи (Target System Interface – TSI). Через інтерфейс цільової системи виконуються всі операції на конкретному апаратному забезпеченні, тому він повинен бути запущений на кожному грід-вузлі, будь це окремий комп'ютер або кластер. Саме він взаємодіє з операційною системою або системою управління кластером на окремому комп'ютері або кластері відповідно. Однієї з особливостей проекту GPE є розвинена клієнтська частина. Існує три види клієнтських застосувань:  Application Client - клієнт для ―звичайних‖ користувачів;  Expert Client - клієнт для досвідчених користувачів і експертів в галузі грід;  Portal Client - клієнт для мобільних користувачів. Крім того, до складу GPE входить також два службових графічних додатки, не призначених для запуску грід-програм: 326  Admin Client - клієнт для адміністраторів сегмента грід;  Remote File Manager - програма для виконання файлових операцій у грід. Проект GPE цікавий тим, що його головною метою є масове впровадження грід-технологій у виробничу діяльність організацій і їх повсякденне використання. Основні ідеї грід одержали зручний вигляд як для користувача, так і для розробника, при цьому зберігши основний потенціал грід- технологій. Клієнтська частина системи GPE може бути використана як початківцями в галузі грід-обчислень, так і професіоналами. Для цього, для кожної категорії користувачів передбачений свій клієнт, який буде найбільш зручним. Серверна частина системи GPE націлена на забезпечення взаємодії клієнтської частини і різних реалізацій проміжного програмного забезпечення. Дана взаємодія можлива лише при використанні стандартів. Основа системи GPE – це стандарти, на яких ґрунтується система. Наприклад, стандарт OGSA (Open Grid Services Architecture) – відкрита архітектура грід-служб, у якому визначається загальна архітектура грід–компонентів на основі грід-сервісів і стандартизовані схеми їх взаємодії, який також використовується в переважній більшості серйозних проектів. Основною мовою програмування системи GPE і розробки GridBean є мова програмування Java, яка забезпечує незалежність від конкретної платформи. Це ще один плюс на користь системи GPE, тому що на рівні мови програмування забезпечується міжплатформений переніс розробленого програмного забезпечення. Втрату продуктивності при використанні мови програмування Java до мінусів віднести не можна, тому що Java використовується тільки для 327 управління ресурсами, ніяких обчислювальних розрахунків програмами, які написані мовою Java, не виконується. 7.6 Інструментальний засіб GridSphere Portal Framework Інструментальний засіб GridSphere був розроблений в 2002 році в рамках проекту GridLab, який фінансувався Європейським Союзом. Головною метою розробки порталу було створення надійного вебінтерфейсу для європейських і світових користувачів грід. Почавши зі специфікацій API, багато в чому ідентичних IBM Websphere® 4.2, проект згодом еволюціонував до порталу-контейнеру, сумісного з JSR 168, який базується на взаємодіючих портлетах. Портлет - одна з технологій, вживаних для побудови інтернет порталу. У інших термінах, портлет - це Java-сервлет, який працює усередині порталу. Портлети - це візуальні компоненти, які можуть бути вбудовані у вебсторінки порталу. Портлети містять ―міні програмні додатки‖, які можуть відображати інформаційний контент або надавати доступ до різних сервісів (рис.7.4). Рис. 7.4 – Схема реалізації портлету GridSphere 328 Стандартний портальний компонент (портлет) в даному випадку визначається як реалізація деякого сервісу, який запускається портальним сервером. Портлет містить деякі дані, набір власних бізнесфункцій, а також має стандартне відображення на робочих панелях порталу. Портлети зазвичай (але не обов'язково) виглядають як стандартні "віконця" на робочій панелі. Їх можна відкривати і закривати, видаляти і переміщати з місця на місце, що дозволяє об'єднувати на одному екрані різнорідну інформацію, отриману з різних джерел: персонального комп'ютера, локальної або корпоративної мережі підприємства і, звичайно, Internet. Перелік операцій користувача з портлетом визначається його роллю і установками, заданими адміністратором. Створення порталу в основному зводиться до інтеграції (збірці) готових компонентів, заздалегідь адаптованих до багаторазового використання. Компоненти є елементарними архітектурними абстракціями, з якими оперує проектувальник подібних систем. За допомогою зв'язок, з урахуванням обмежень, зокрема не функціональних, вони з'єднуються в цілісні конфігурації. Крім стандартних операцій з вікнами (скрутити і розвернути) кожен портлет володіє також набором «модів-опцій», таких як перегляд, редагування, конфігурація і допомога. Як приклад, розглянемо портлет, який дозволяє користувачам настроювати інформацію про себе. Опція «перегляд» надасть інформацію про користувача. Опція «допомога» надає інформацію про те, як цю інформацію можна змінити і як її використовувати. Опція «редагування» дозволяє редагувати інформацію про користувача. І нарешті, опція «конфігурація» дозволяє адміністраторам порталу змінювати настройки даного портлета. 329 У рамках підходу, відомого як контейнерний або компонентний, портлети працюють практично незалежно один від одного - вони поміщаються в загальний контейнер, який надає їм шар відображення, диспетчеризацію запитів і доступ до системних ресурсів. Альтернативною методикою є канальна інтеграція, яка приписує з‘єднувати компоненти логічними каналами, конфігурація яких відображає хід робочих процесів. Робочий процес описується на якій-небудь відповідній мові опису процесів у вигляді сценарію. Системні ресурси тут виділяються, виходячи із завантаження каналів. Вибір на користь того або іншого підходу здійснюється, виходячи із специфіки задач користувача: контейнерна модель добра для підприємства, а канальна - для вирішення розподілених завдань без чітко виділеного центру управління. Портал GridSphere поставляється разом з набором ключових портлетів, яки надають всю необхідну для запуску порталу функціональність. Портал GridSphere надає можливість користувачам добудовувати своє портальне середовище, додаючи або видаляючи портлети. Опис зовнішнього вигляду порталу зроблено у форматі XML і, таким чином, може бути легко відредаговано. GridSphere має систему контролю доступу (Role Base Access Control system), яка поділяє користувачів на гостей, користувачів, адміністраторів і суперкористувачів (super users). Оскільки розробка порталу здійснена міжнародним співтовариством, портал має вбудовану підтримку французької, англійської, німецької, голландської, чеської, польської, угорської, італійської та навіть арабської, китайської і японської мов. При розробці GridSphere особлива увага приділялася сумісності портлетов зі стандартом JSR 168. Завдяки цьому розробники мають можливість за короткий час зібрати базові файли для розгортання 330 продукту, що значно прискорює процес розробки порталу. Також існує можливість використання Spring Framework - розвитої моделі служби портлетів, за допомогою якої можна інкапсулювати логіку роботи портлетів і поширювати її на інші портлети. GridSphere у вигляді моделі MVC може застосовуватися в таких технологіях, як JSF або Struts; те же саме відноситься і до бібліотек GridSphere, які були розроблені в рамках проекту для полегшення процесу розробки. Для всіх розробників портлетів доступно середовище програмування Hibernate Framework, яка підтримує особисті (персистентні) операції з даними. Портал GridSphere має наступні особливості:  API портлетів повністю сумісно з JSR 168;  підтримується розробка портлетів в стандарті JSF;  доступний додатковий API портлетів, практично повністю сумісний з IBM WebSphere ® 4.2;  підтримка розробки та інтеграції нових портлетів;  основні портлети Gridsphere: Login, Logout, настроювання мови інтерфейсу користувача, відображення вікна портлету, персоналізація облікового запису користувача і інтерфейсу, адміністративні портлети для реєстрації користувачів, груп користувачів, управління портлетами і зовнішнім виглядом порталу;  високорівнева модель для створення складних портлетів за допомогою бібліотек GridSphere;  опис зовнішнього вигляду порталу у форматі XML, що дозволяє легко його модифікувати;  можливість персистентних операцій з даними при роботі з базами даних за допомогою Hibernate framework; 331  вбудовані тести Junit/Cactus для повного тестування портлетів на сервері з генерацією звітів по тестах;  підтримка портлетних програмних додатків Struts за допомогою Portals Struts Bridge. Портал GridSphere 2.0 підтримує дві моделі розробки портлетів. Первинна модель базується на стандартах IBM Websphere® Portlet API v4.1+, тобто портлети для WebSphere можуть бути легко перенесені в GridSphere. Крім того, GridSphere надає модель розробки портлетів на основі стандарту JSR 168 Portlet API, яка підтримується IBM, Oracle, Sun, Plumtree і багатьма іншими розробниками серверів додатків. Портал GridSphere має вбудовану підтримку контролю доступу. Кожна група користувачів має своє ім'я, опис і набір портлетів, до яких користувач із цієї групи має доступ, причому кожному портлету можна призначити різні права доступу. Користувачі можуть входити в одну або кілька груп (одержуючи в останньому випадку доступ до декількох наборів портлетів), при цьому кожний користувач має певний статус усередині групи. ―адміністратор‖ Статус або може бути ―гість‖, ―суперкористувач‖. ―Гість‖ ―користувач‖, може тільки переглядати портал, у той час як ―користувач‖, після ідентифікації, одержує можливість набудовувати портлети для відображення необхідної йому інформації. ―Адміністратор‖ має доступ до режиму конфігурації портлетів, що був описаний раніше, і може змінювати параметри ініціалізації портлетів. ―Суперкористувач‖ може виконувати будь-які дії над портлетами. Цей статус фактично еквівалентний статусу ―root‖ для Unix-подібних операційних систем. Кожний побудований на основі портлетів програмний додаток може мати файл опису group.xml, який визначає початкову групу та права доступу до портлету програмного додатку. 332 Служба портлетів інкапсулює операції, які можуть бути повторно використані іншими портлетами. Використання служб значно знижує складність портлетів, які розробляються. Служба портлетів надає наступні переваги:  Вбудовані механізми забезпечення безперервності операцій полегшують роботу з реляційними базами даних.  Вбудована модель контролю доступу дозволяє легко створювати проксі-служби безпеки, що контролюють доступ до різних об'єктів залежно від статусу користувача.  Інтеграція з тестовим каркасом порталу полегшує написання тестів Junit. Служби портлетів можуть бути використані при розробці портлетів для WebSphere. Оскільки в специфікаціях JSR 168 служби портлетів відсутні, для створення служб розробники можуть використовувати спеціальний JSR-підклас ―ActionPortlet‖. Контейнер портлету GridSphere реалізовано у вигляді вебзастосування, що вимагає використання зовнішнього оточення, такого як сервлет контейнер Jakarta Tomcat. У процесі інсталяції в сервлетконтейнер вбудовуються додаткові бібліотеки. Інформація про найбільш поширені у світі грід-портали узагальнена в табл.7.1. Таблиця 7.1. Приклади популярних грід-порталів Портал GILDA, Опис Тип GILDA (Grid INFN Laboratory for Dissemination Портал https://gilda.ct.infn.it/ Activities) – це віртуальна лабораторія, створена доступу для того, щоб демонструвати / розповсюджувати можливості Grid. Портал GILDA P-Grade − це середовище 333 розробки та виконання інформаційного потоку грід задач, що базується на останній версії грідпорталу P-Grade. Оснований на стандарті JSR-168 (Portlet Java Портал GridSphere Request) http://www.gridsphe Specification і призначений для застосувань обслуговування користувачів грід: доступу до re.org ресурсів, запуску задач, моніторингу і візуалізації результатів. Містить різні портлети для зв‘язку порталу з веб-сайтом і пошуку потрібної інформації Портал P-Grade Оснований на веб-середовищі для розроблення, Портал http://www.lpds.szta виконання ki.hu/pgrade/ та моніторингу інформаційних застосувань потоків на різних грід-платформах (Globus Toolkit 2, Globus Toolkit 4, LCG та gLite). Включає програмне забезпечення та документацію. Migrating Desktop Забезпечує доступ користувачів до грід-ресурсів, Портал Platform виконує моніторинг і візуалізацію, виконання застосувань http://desktpo.psnc.pl інтерактивних застосувань, керування файлами даних. SDSC HotPage, HotPage – це набір скриптів cgi та html-сторінок, Портал http://www.growl.or що дають користувачам можливість отримати доступу g.uk/ukhec_portal/n доступ до інформації про віддалені комп‘ютери з ode6.html веб-браузера. 7.7 Приклад виконання практичної роботи У даній практичній роботі необхідно розробити веб-сервіс відправки завдання в навчальну грід - інфраструктуру під управління проміжного програмного забезпечення gLite 3.1 із використанням 334 бібліотеки jLite, розробленої O.В. Сухорословим [25, 26, 27, 28, 29] (Центр грід-технологій Інституту системного аналізу Російської Академії Наук). Бібліотека доступна для завантаження за адресою http://code.google.com/p/jlite/ Бібліотека jLite реалізує високорівневій інтерфейс прикладного програмування, який містить операції аналогічні командам користувацького оточення gLite. Даний інтерфейс приховує від програміста складність проміжного програмного забезпечення та його конфігурації. Бібліотека реалізована на базі існуючих API gLite і зовнішніх компонентів, таких як Apache Axis, Java CoG Kit, Condor ClassAd. Дистрибутив jLite включає всі зовнішні залежності, яки спрощують його установку. Крім того, для використання jLite не потрібна інсталяція користувацького оточення gLite. Це дозволяє використовувати бібліотеку на будь-якій платформі з підтримкою Java, включаючи Windows, що відкриває нові можливості для розробників грід-застосувань. Бібліотека jLite доступна для завантаження та використання на умовах ліцензії Apache License 2.0. Існуюча реалізація jLite API включає всі базові операції, пов'язані з запуском завдань в грід-інфраструктурі:  Створення тимчасового проксі-сертифікату користувача за допомогою сервісу віртуальний організацій VOMS;  Делегація проксі-сертифікату сервісу управління завданнями WMS;  Пошук обчислювальних ресурсів, яки задовольняють вимогам грідзавдання;  Запуск завдання на виконання, який включає завантаження вхідних даних на сервіс WMS (підтримуються наступні типи завдань: normal, collection, parametric);  Моніторинг статусу виконання грід-завдання; 335  Завантаження результатів виконання завдання на локальну машину. Надаючи простий у використанні програмний інтерфейс, jLite тим самим полегшує створення різноманітних грід-застосувань на основі проміжного програмного забезпечення gLite, таких як проблемноорієнтовані оболонки, портали або грід-сервіси. Схема доступу до грід інфраструктурі з використанням бібліотеки jLite показана на рисунку 7.5. Рис. 7.5 – Структурна схема доступу до грід-ресурсів Підготовчі операції, які повинні бути зроблені при виконанні даної лабораторної роботи:  Бібліотека jLite встановлюється на Веб-сервері для забезпечення доступу до функцій з використанням звичайного браузера. Всі необхідні 336 конфігураційні параметри для використання бібліотеки jLite вже встановлені і не потребують корегування.  У каталозі $HOME/.globus необхідно мати пару – сертифікат/закритий ключ, тобто файли - usercert.pem, userkey.pem з правами доступу 0600 та 0400, відповідно, і студент повинен бути зареєстровано у навчальній віртуальній організації. Завдання даної практичної роботи виконується у два етапи: 1. перевірка роботи тестового прикладу, який знаходиться в директорії $JLITE_HOME/src/jlite/examples/Demo.java. 2. розробка графічного інтерфейсу портальної системи, яка дозволяє користувачу забезпечувати запуск завдання у грід-інфраструктурі за допомогою браузера. Опис типового сценарію (модуль Demo.java) використання функцій бібліотеки jLite для відправки завдання в грід інфраструктуру: import java.util.List; import jlite.GridSession; import jlite.GridSessionConfig; import jlite.GridSessionFactory; import jlite.MatchedCE; import jlite.util.PasswordPrompt; import jlite.util.Util; import org.glite.jdl.JobAd; import org.globus.gsi.GlobusCredential; /** * Приклад використання бібліотки jLite API. * @author Oleg Sukhoroslov */ public class MyDemo1 { public static void main(String[] args) { try { /* * ----------------------------------------337 * Крок 1. Конфігурування та створення грід сесії * ----------------------------------------*/ GridSessionConfig config = new GridSessionConfig(); // user's private key passphrase config.setUserKeyPass( PasswordPrompt.prompt("Enter your private key passphrase: ")); // Директорії з розміщенням конфігураційних файлів для // необхідно уточнювати у викладача. В прикладі вказані // директорії від "$JLITE_HOME // path to CA certificates // config.setCertDir("etc/certs/ca"); // paths to VOMS configuration files and certificates // config.setVOMSDir("etc/vomses"); // config.setVOMSCertDir("etc/certs/voms"); // path to WMProxy configuration files // config.setWMSDir("etc/wms"); // create Grid session GridSession session = GridSessionFactory.create(config); /* * -------------------------------------------* Крок 2. Створення проксі сертифікату(12 hour lifetime) * -------------------------------------------*/ String vo = PasswordPrompt.promptNoMasking("Enter VO name: "); GlobusCredential proxy = session.createProxy(vo, 12*3600); System.out.println("Created user proxy: " + proxy.getSubject()); /* * --------------------------------------------* Крок 3. Делегування проксі сертифікату WMProxy серверу * --------------------------------------------*/ session.delegateProxy("myId"); /* 338 * ---------------------------* Крок 4. Завантаження опису завдання * ---------------------------*/ JobAd jad = new JobAd(); jad.fromFile("завдання_користувача.jdl"); String jdl = jad.toString(); /* * ----------------------------------------* Крок 5 (optional). Формування переліку ресурсів * ----------------------------------------*/ List<MatchedCE> ces = session.listMatchedCE(jdl); System.out.println("Matched Computing Elements: "); for (MatchedCE ce : ces) { System.out.println("\t" + ce.getId()); } /* * -------------------------* Крок 6. Відправка завдання на виконання * -------------------------*/ String jobId = session.submitJob(jdl,"завдання_користувача.jdl "); System.out.println("Started job: " + jobId); /* * -------------------------- 339 * Крок 7. Перевірка статусу виконання завдання * -------------------------*/ String jobState = ""; do { Thread.sleep(10000); jobState = session.getJobState(jobId); System.out.println("Job status: " + jobState); } while (!jobState.equals("DONE") && !jobState.equals("ABORTED")); /* * --------------------------* Крок 8. Завантаження результатів виконання завдання * --------------------------*/ if (jobState.equals("DONE")) { String outputDir = "директорія для завантаження результатів" + Util.getShortJobId(jobId); session.getJobOutput(jobId, outputDir, true); System.out.println("Job output is downloaded to: " + outputDir); } } catch (Exception e) { e.printStackTrace(); } } } 340 Перевіривши роботу тестового прикладу необхідно розробити вебсторінку мовою програмування Java для відправки завдання у навчальну грід-систему. На рисунку 7.6, наведеному нижче, показано приклад інтерфейсу користувача. Рис. 7.6 – Приклад веб-сторінки доступу до грід-ресурсів 7.8 Завдання до практичної роботи 1. Використовуючи бібліотеку jLite розробити веб-сторінку, яка дозволяє відправити завдання на виконання та результати виконання завдання. 341 відобразити 2. Скласти протокол виконання практичної роботи. Протокол повинен містити: програмний код веб-сторінки і скріншоти екранів виконання команд відправки завдання до навчальної грід-системи. 7.9 Контрольні питання 1. Яка різниця між користувальницькими порталами і порталами застосувань (програмних додатків). 2. Назвіть основні характеристики інструментальних засобів створення грід-порталів на основі Globus Toolkit. 3. Назвіть основні переваги інструментального засобу створення грід-порталів на основі GridSphere. 4. Назвіть приклади проектів побудови порталів доступу до грідінфраструктури. Література 1. "Web Services Architecture," World Wide Web Consortium Working Group Note, 11 November 2004, available from http://www.w3.org/TR/ws-arch/. 2. Foster, I. et al, "GFD.30, The Open Grid Services Architecture, Version 1.0," Global Grid Forum, 25 January 2005. http://www.gridforum.org/documents/GWD-I-E/GFD-I.030.pdf 3. Web Services Resource Framework. - http://www.globus.org/wsrf/ 4. AAAuthreach framework and GAAAPI for AuthN/AuthZ services. – http://www.uazone.org/demch/projects/aaauthreach/index.html 5. NSF Teragrid Project, http://www.teragrid.org/ 6. Dennis Gannon, Beth Plale, Marcus Christie и др. «Service Oriented Architectures for Science Gateways on Grid Systems», 2005, 342 Department of Computer Science, Indiana University, Bloomington Indiana, USA; http://cat.inist.fr/?aModele=afficheN&cpsidt=17414801 7. Cactus Project - An open source problem solving environment, http://www.cactuscode.org/Presentations/GridPortals_2000.ppt 8. Grid Compute Environment (GCE) Research Group-Global Grid Forum, http://www.computingportals.org 9. The Astrophysics Simulation Collaboratory (ASC) – https://www.ascportal.org 10. NPACI HotPage Grid Computing Portal, http://hotpage.paci.org. 11. Thomas, M. et al., ―The GridPort Toolkit Architecture for Building Grid Portals‖, in the 10th IEEE Intl. Symp. on High Perf. Dist. Comp. 12. Novotny, J. in ―Concurrency and Computation: Practice and Experience‖. pp.1129– 1144. 2002. 13. Commodity Grid Kits, http://www.globus.org/toolkit/cog.html) Building Grid Computing Portals: The NPACI Grid Portal Toolkit/ Chapter Authors: Mary P. Thomas, John R. Boisseau p 675-700) в Grid Computing 2003 ISBN: 9780470853191 14. The Globus Alliance, http://www.globus.org. 15. Perl CoG, https://gridport.npaci.edu/cog/. Или статья по перл. http://aspen.ucs.indiana.edu/gce/C558perlcogkit/CPE_Perl_CoG_subm itted.pdf 16. Von Laszewski, G., Foster, I., Gawor, J. & Lane, P., ―A Java Commodity Grid Kit‖, Concurrency and Computation: Practice and Experience, 13, pp.643–662, 2001. 17. GridSphere, http://www.gridsphere.org. 18. GridLab, http://www.gridlab.org. 343 19. OGCE: Open Grid Computing Environment, http://www.ogce.org/index.php. 20. The MyGrid Project, http://www.ebi.ac.uk/mygrid/. 21. GridSpeed, http://www.gridspeed.org. 22. Suzumura, T., Nakada, H. & Matsuoka, S., ―GridSpeed: A Web- based Grid Portal Generation Server‖, in CCGrid, Poster. 23. UNiform Interface to COmputing REsources (UNICORE), http://www.unicore.de/. 24. DAGMan, http://www.cs.wisc.edu/condor/dagman/. 25. O.V. Sukhoroslov. jLite: A Lightweight Java API for gLite // Proceedings of the 3rd International Conference "Distributed Computing and Grid-technologies in Science and Education", GRID‘2008, Dubna, Russia, 30 June - 4 July, 2008. 26. jLite: http://jlite.googlecode.com/ 27. http://grid2008.jinr.ru/pdf/afanasiev2.pdf 28. Сухорослов О.В. Высокоуровневые средства разработки грид-приложений и проблемно-ориентированных сервисов. Теория и практика системного анализа: Труды I Всероссийской научной конференции молодых ученых. – Т. II. – Рыбинск: РГАТА имени П. А. Соловьева, 2010. С198-205 http://www.isa.ru/tpsa/images/tpsa2.pdf 29. Сухорослов О.В. Высокоуровневые средства разработки Grid-приложений для инфраструктуры EGEE. // Параллельные вычислительные технологии (ПаВТ'2009): Труды международной научной конференции (Нижний Новгород, 30 марта – 3 апреля 2009г.) –Челябинск: Изд. ЮУрГУ, 2009. – 839 с. (с. 718-723). 344

GRID technologies

Related documents

Products

Support

GRID technologies

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib