Концепція GRID-систем, її розвиток. Сучасний стан GRID-систем. Віртуальні організації

рис. 1

Фактично організація  може брати участь в одній або  декількох ВО, надаючи для поділу деякі або всі свої ресурси. На малюнку показані (у овалах) три  фактично існуючі організації і  дві ВО: P, яка об'єднує учасників  консорціуму аерокосмічного проекту, і Q, яка пов'язує колег, приголосних  розділяти вільні кванти комп'ютерного часу, наприклад, при розрахунках  трасування променів. Організація, показана в лівій частині малюнка, бере участь в P, а показана праворуч бере участі в Q, а третя є членом як P, так і Q. політики, регулюючі доступ до ресурсів (резюміруемие в "квотах") різняться, відповідно, для фактичних організацій, ресурсів Іво, залучених в загальний процес.

Відносини поділу можуть з  часом динамічно змінюватися  залежно від умов застосування виділених  ресурсів, характеру дозволеного  доступу і складу учасників, яким дозволений доступ. І ці відносини  зовсім необов'язково пов'язані з  необхідністю явного поіменного вказівки учасників, а цілком можуть бути неявно визначені через політики управління доступом до ресурсів.

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

Наприклад, новий учасник, що вступає в ВО Q, повинен бути в змозі визначити, до яких ресурсів може бути отриманий доступ, "якість" цихресурсів та політики управління доступом.

Відносини поділу часто представляються  не просто схемою "клієнт-сервер", а досить розвиненою одноранговой структурою типу "точка - точка", де провайдери можуть виявитися споживачами, а відносини поділу можуть існувати між будь-яким підмножиною учасників. Відносини поділу можуть об'єднуватися для узгодженого використання на багатьох ресурсах, кожен з яких належить однієї з організацій. Наприклад, розрахунки, розпочаті у ВО Q на одному пулі обчислювальних ресурсів, можуть пізніше отримати доступ до даних або запустити рішення під задач де-небудь ще. У таких ситуаціях важливою ставати здатність контрольованими способами делегувати повноваження, це ж стосується механізмів узгодження операцій (так званого, спільного планування - cosheduling) на всій безлічі ресурсів.

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

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

 

4. Концепція GRID-систем

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

системні компоненти, визначає цілі та функції цих компонент  і показує, як ці компоненти взаємодіють  один з одним.

Визначення GRID-архітектури  ми почнемо з передумови, що для  забезпечення ефективної діяльності ВО необхідно мати можливість встановлювати  відносини поділу між будь-якими  потенційними учасниками. Таким чином, центральною проблемою, що вимагає  дозволу, виявляється інтероперабельність (взаємодія різних програмних і апаратних засобів - interoperability). У контексті розгляду мережних технологій інтероперабельність означає спільність протоколів. Тому наша GRID-архітектура, по-перше, перш за все, є архітектурою протоколів, що визначають базові механізми, за допомогою яких користувачі та ресурси ВО домовляються, встановлюють, управляють і використовують відносини поділу. Заснована на стандартах відкритої архітектури сприяє розширюваності, інтероперабельності, мобільності та спільному використанню загальних програм; стандартні протоколи полегшують визначення стандартних служб, які забезпечують удосконалення можливостей. Для підтримки програмування абстрактних конструкцій, необхідних при створенні зручного у використанні GRID, ми можемо також розробити, так звані Інтерфейси Прикладного Програмування (Application Programming Interfaces - API) і Інструментарій Розробки Програмного забезпечення (Software Development Kits - SDK). Разом, ця технологія і архітектура складають те, що часто називається як проміжне програмне забезпечення (служби, необхідні для підтримки загального набору додатків в розподіленої мережевої середовищі - "Middleware" [1]), хоча ми уникаємо використання цього терміна тут через його

невизначеність.

Чому інтероперабельність є настільки фундаментальною системною можливістю? Справа полягає в тому, що ми повинні гарантувати формування відносин поділу між довільними групами, вступ нових учасників динамічно і через різні платформи, мови і програмні середовища. У такому контексті механізми приносять мало користі, якщо вони не визначені і не реалізовані так, щоб їх інтероперабельність не лімітована кордонами організацій, політиками управління і типами ресурсів. Без інтероперабельності ВО програми та учасники змушені встановлювати двосторонні домовленості про розділення, оскільки немає гарантії, що механізми, використовувані між будь-якими двома групами можуть бути розширені для будь-яких інших груп. Без такої гарантії динамічне створення ВО зовсім неможливо, а кількість типів ВО, які можуть бути сформовані, суворо обмежена. Точно також як Web революціонізувала поділ інформації, надавши для цілей інформаційного обміну універсальний протокол і синтаксис (HTTP і HTML), нам необхідні стандартні протоколи для повсюдного поділу ресурсів.

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

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

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

Чому ми також обговорюємо  тут можливості API і SDK? Звичайно, є  щось більш значуще для ВО ніж  інтероперабельність, протоколи та служби. Розробники повинні мати можливість створювати витончені додатки в складній і динамічній виконавчої середовищі. Користувачі повинні мати можливість працювати з цими додатками. Працездатність додатків, їх справність, вартість розробки і супроводу - все це надзвичайно важливі фактори. Стандартні абстракції, API's і SDK's допомагають прискорити розробку програм додатків, забезпечують спільне використання загальних програм і покращують переносимість додатків. API's і SDK's є доповненням, а не альтернативою протоколам. Без стандартних протоколів інтероперабельність може бути досягнута на рівні API тільки шляхом використання усюди єдиної реалізації програми, що нездійсненно в багатьох зацікавлених ВО, або на основі знання кожної реалізацією деталей кожної іншої реалізації. (Метод Jini, використовуваний в [2], пропонує завантаження процедури протоколу на віддалений сайт, що не дозволяє обійти цю вимогу).

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

 

5. Архітектура GRID

При описі різних рівнів архітектури GRID, будемо слідувати моделі "пісочного годинника". Як показано на рис. 2, горловина пісочного годинника  відповідає невеликому кількості базових  абстракцій і протоколів (таких як TCP і HTTP в Internet), які необхідні для  зв'язку високорівневих служб з низькорівневими.

Деталізуючи рис. 2, архітектуру GRID можна представити у вигляді  ієрархічної структури (рис. 3), що складається  з декількох рівнів. На кожному  з представлених рівнів існують  свої сервіси, взаємодіючі за допомогою  певних протоколів.

 

Рис. 2 - Модель пісочного  годинника

 

Рис. 3 – Багаторівнева  архітектура GRID

 

Рівень Fabric

Цей рівень надає ресурси, спільний доступ до яких забезпечується через протоколи GRID. Для доступу до обчислювальних ресурсів потрібні:

- Механізми для запуску  програми та моніторингу її  виконання.

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

- Механізми для запуску  програми та моніторингу її виконання

- Механізми для посилки  / отримання файлів, у тому числі  високошвидкісні багатопотокові механізми [7], механізми для читання / запису підмножин файлів;

- Механізми для проведення  віддаленої вибірки даних [8];

механізми менеджменту, які  дозволили б контролювати ресурси, призначені для пересилання даних;механізми, що дозволяють дізнатися апаратні і  програмні характеристики і поточне  завантаження;

- Механізми поліпшеного  резервування. Для доступу до мережевих ресурсів потрібні:

- Механізм менеджменту  та контролю над ресурсами,  призначеними для мережевого  трафіку (пріоритети, резервування);

- Функції визначення характеристик і завантаження мережі. Для доступу до ресурсів репозиторію кодів програм потрібно механізм управління версіями вихідного та об'єктного коду (наприклад, система CVS). Для доступу до ресурсів каталогів потрібно механізм забезпечення зберігання даних, обробки запитів та проведення оновлення даних.

 

Рівень Connectivity

Рівень Connectivity визначає базові комунікаційні та ідентифікаційні протоколи, необхідні для проведення специфічних для GRID операцій (транзакцій). Комунікаційні протоколи дозволяють здійснювати обмін даними між ресурсами рівня Fabric. Ідентифікаційні протоколи, побудовані на комунікаційних сервісах, надають криптографічних захищений механізм для веріфіцірованія та ідентифікації користувачів і ресурсів. Рішення проблеми безпеки на рівні Connectivity має базуватися на існуючих стандартах. Ідентифікація користувача може бути здійснена різними способами [9]. Зокрема, може бути використано одноразове реєстрування. При використанні цього методу користувачі повинні реєструватися в обчислювальному середовищі тільки один раз і, після успішного завершення операції, отримати доступ до ресурсів рівня Fabric. Іншим способом ідентифікації є делегування. Програма користувача повинна мати доступ до ресурсів, на яких він авторизований. Опціонально програма повинна бути здатна передати підмножина своїх прав іншій програмі. Природно, кожен провайдер ресурсів може мати ряд локальних рішень з безпеки. Система безпеки обчислювальної середовища повинна взаємодіяти з цим класом локальних рішень.

 

Рівень Resource

Рівень Resource базується на комунікаційному і авторизационном протоколах рівня Connectivity. Він визначає протоколи для:

- Здійснення безпечного  обміну інформацією;

- Ініціалізації, моніторингу  та проведення спільних операцій  на індивідуальних ресурсах;

- Створення облікових  записів користувачів;

- Проведення обліку утилізованого  часу для кожного з користувачів.Для доступу та контролю над локальними ресурсами сервіси рівня Resource використовують функції рівня Fabric. Слід зазначити, що протоколи рівня Resource повністю пов'язані з індивідуальними ресурсами.За своїм призначенням протоколи рівня Resource можуть бути згруповані в два класи:

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

- Протоколи менеджменту,  які використовуються для надання  доступу до спільних ресурсів.

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

 

Рівень Collective

На рівні Collective згруповані протоколи і сервіси, які не пов'язані з будь-яким конкретним ресурсом, є більш глобальними за природою і забезпечують колективна взаємодія ресурсів. Прикладами сервісів рівня Collective, служать:

- Сервіс директорії, який  дозволяє учасникам GRID досліджувати  наявні ресурси та їх властивості  [5]. Цей сервіс використовує протокол GRIP рівня Resource.

- Сервіси розподілу і  планування ресурсів, обробки заявок  користувачів дозволяють учасникам  GRID отримувати доступ до необхідних  ресурсів, а також планувати виконання  завдань на них. Прикладами  реалізації таких сервісів можуть служити AppLeS], Condor-G, Nimrod-G і DRM брокер.

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

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