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

- Сервіс завантаження  і спільних робіт, також відомий  як "PSE" - Problem Solving Environment, який надає засоби для управління потоком завдань.

- Сервіси пошуку програмного  забезпечення, які дозволяють досліджувати  і вибрати необхідне для вирішення  проблеми програмне забезпечення. Прикладами можуть служити NetSovle і Nimf.

- Сервіси авторизації,  які визначають правила використання  ресурсів для користувачів GRID. Ці  сервіси використовують протоколи  рівня Resource та протоколи рівня безпеки.

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

- Сервіси співробітництва,  які забезпечують синхронний  і асинхронний скоординований  обмін інформацією між великими  спільнотами користувачів. Прикладами  можуть служити CAVERNsoft, Access GRID.

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

 

Рівень Application

Рівень Application включає в себе додаток користувача, яке функціонує в середовищі GRID (рис. 4).

 

Рис. 4 - Взаємодія прикладної програми з різними  рівнями GRID-системи

 

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

 

6. Застосування  GRID на практиці

Наведемо два приклади, щоб проілюструвати, як на практиці функціонує GRID-архітектура. Таблиця 1 показує служби, які могли б бути використані для виконання багатоаспектного моделювання та програм, які поділяють кванти обчислювальних ресурсів (див. рис. 1). Базові елементи рівня фабрикатів в кожному з прикладів одні й ті ж: комп'ютери, системи зберігання та мережі. Крім того, для забезпечення зв'язку та безпеки кожен ресурс перемовляється зі стандартними протоколами рівня Зв'язки і протоколами рівня Ресурсів для наведення довідок, виділення пам'яті та управління. Вище цього, кожен додаток використовує якусь суміш універсальних і значною мірою проблемно-орієнтованих служб рівня Кооперації. У разі трасування променів припускаємо, що додаток розраховане на використання обчислювальної системи, яка має високої пропускною здатністю [14]. Для того, щоб в середовищі ВО керувати виконанням великою кількістю майже незалежних завдань, така система повинна вести інформаційний облік наборів активних та очікують запуску завдань, виявляти для кожного завдання місце розташування відповідних ресурсів, організовувати завантаження та використання таких ресурсів, виявляти і реагувати на різного роду відмови і так далі.

 

Таблиця 1: GRID-служби, використані при конструюванні двох додатків рис. 1.

 

	Багатоаспектне моделювання	Трасування променів
Кооперація(проблемно-залежна)	Об'єднувач розв'язувачів, архіватор розподілених даних	Контрольна точка, управління завданнями,відновлення від збоїв, підготовка виконання завдань
Кооперація (групова)	Виявлення ресурсів, брокери  ресурсів, системний моніторинг, авторизація  учасників, скасування сертифікатів
Ресурси	Доступ до обчислень, доступ до даних, доступ до інформації про структуру, стан і продуктивності системи
Зв'язок	Комунікація (IP), служба імен (DNS), аутентифікація,авторизація, делегування
Фабрикатів	Системи зберігання, комп'ютери, мережі, репозитарії програм, Каталоги

 

Розробка такої системи  в контексті нашої GRID-архітектури використовує як залежні від предметної області служби рівня Кооперації (динамічна контрольна точка, управління пулом завдань, подолання збоїв), так і універсальні служби цього рівня (посередництво, реплікація даних для виконуваних і загальних вхідних файлів), а також стандартні протоколи рівнів Ресурсів і Зв'язки. Проект Condor-G є першим кроком до досягнення цієї мети. У разі додатки, використовуваного при багатоаспектному моделюванні, на самому верхньому рівні мають місце проблеми зовсім іншого характеру. Деякі прикладні інфраструктури (наприклад, CORBA, CCA) можуть використовуватися для конструювання додатки з їх різних компонентів. Ми також вважаємо, що в даному випадку необхідні механізми для виявлення відповідних обчислювальних ресурсів, резервування часу на цих ресурсах, для організації завантаження та використання, для забезпечення доступу до віддаленого сховища даних і так далі. Знову ж, і тут може бути використаний ряд проблемно-залежних служб рівня Кооперації (наприклад, об'єднувач розв'язувачів завдань, архіватор розподілених даних), але основні базові кошти будуть ті ж, що й у випадку трасування променів.

 

 

7. Приклади зв’язку GRID з іншими технологіями

 

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

 

World Wide Web

Поширеність Web-технологій (наприклад, стандартних протоколів - TCP / IP, HTTP, SOAP і інших, а також таких мов  як HTML і XML) робить їх привабливими в  якості платформи для конструювання  ВО систем і додатків. Тим не менш, у той час як ці технології чудово вирішують питання підтримки інтерактивної взаємодії клієнтського броузера з Web-сервером, що і є основою організації Web, вони не цілком достатні для реалізації тих досить різноманітних моделей інтерактивної взаємодії, які зустрічаються в контексті діяльності ВО. Наприклад, сьогоднішні Web-броузери зазвичай використовують для аутентифікації користувача протокол TLS, але не підтримують функції одноразової реєстрації або делегування.Для інтеграції GRID з Web-технологіями можна запропонувати наступні абсолютно очевидні рішення. Наприклад, включення в Web-броузери забезпечуваних GSI коштів одноразової реєстрації для протоколу TLS, дозволило б здійснювати одноразову реєстрацію на безлічі Web-серверів. Можливості делегування, передбачені в GSI, дозволили б броузеру клієнта делегувати повноваження Web-серверу так, щоб цей сервер надалі міг діяти від імені клієнта. У свою чергу такі рішення суттєво спростять використання Web-технологій при створенні "ВО-порталів", які забезпечать тонким клієнтам інтерфейси зі складними ВО додатками. WebOS передбачає вирішення деяких з цих проблем [15].

 

Провайдери послуг зберігання та програм

Провайдери прикладних послуг, провайдери послуг зберігання та подібні  їм обслуговуючі компанії зазвичай пропонують використовувати специфічні, ділові та інженерні програми з наявних  в їх розпорядженні джерел (наприклад, у разі звернення до ASP провайдерам) і зовнішні сховища інформації (при  зверненні до SSP провайдерам). У цих  випадках замовник підписує договір  на обслуговування, в якому визначається доступ до спеціальної конфігурації апаратно-програмних ресурсів. Безпека  при цьому повинна бути забезпечена  шляхом використання технологій Віртуальних  Приватних Мереж (Virtual Private Network - VPN), що дозволяє корпоративної мережі (intranet) замовника охопити ресурси керовані системами ASP або SSP від імені замовника. Інші SSP системи пропонують послуги поділу файлів, і в таких випадках доступ забезпечується засобами HTPP, FTP, або WebDAV із застосуванням користувальницьких ідентифікаторів і паспортів, також списків контролю доступом, керуючих доступом до ресурсів.З позиції перспективи розвитку ВО ці технології представляються низькорівневим інструментарієм розробника. VPN і статичне конфігурування дуже ускладнюють досягнення багатьох можливостей поділу, властивих ВО. Наприклад, використання VPN призводить до того, що зазвичай ASP-додаток не має можливості отримати доступ до даних, розташованим в сховище, керованому окремої SSP-системою. Схожа ситуація має місце і при спробі динамічного реконфігурація ресурсів усередині відокремленої ASP-або SSP-системи, що фактично вдається здійснити вкрай рідко. Поділ завантаження між кількома провайдерами, що є звичайним рішенням в індустрії енергопостачання, поки невідомо в сфері надання послуг провайдерами. Основна проблема тут полягає в тому, що VPN не є ВО: вона не може бути розширена динамічно з тим, щоб охопити інші ресурси і не забезпечує віддаленого провайдера ресурсів якими-небудь засобами управління поділом її ресурсів. Інтеграція GRID-технологій в середу ASP-і SSP-систем дозволить істотно розширити набір можливостей цих систем. Зокрема, стандартні GRID-служби і GRID-протоколи можуть бути використані для того, щоб досягти поділу апаратних і програмних ресурсів. Замовник міг би при цьому домовитися про надання йому на основі SLA конкретних апаратних ресурсів і потім використовувати ресурсні протоколи GRID для того, щоб динамічно виділяти ті апаратні ресурси, які необхідні саме для виконання того чи іншого конкретного додатка. Механізми гнучкого делегування та управління доступом до ресурсів дозволили б замовнику безпосередньо і ефективно здійснювати прогін його додатків на комп'ютері ASP і безпечний доступ до даних через SSP-систему, а також об'єднувати ресурси з безлічі ASP-або SSP-систем зі своїми власними ресурсами, коли це диктується складністю розв'язуваної задачі. Інфраструктура одноразової реєстрації дозволить динамічно пов'язувати безліч доменів безпеки, якщо це дійсно необхідно, для забезпечення складних додатків. Надзвичайно важливі GRID-механізми управління ресурсами і протоколи, що здійснюють облік їх використання та оплати, які необхідні при динамічному надання і резервування ресурсів (наприклад таких, як обсяг пам'яті, смуга пропускання та ін.).

 

Системи корпоративного комп'ютингу

Усі технології корпоративних  розробок такі, як CORBA, Enterprise Java Beans, Java 2 Enterprise Edition і DCOM, являють собою системи, сконструйовані для створення з їх допомогою розподілених додатків. Вони підтримують стандарти інтерфейсів до ресурсів, механізми віддаленого виклику, служби торгівлі для виявлення ресурсів і тому істотно полегшують вирішення проблеми поділу ресурсів всередині однієї організації. Тим не менше, ці механізми не відповідають специфічним вимогам ВО, перерахованим вище. Владнання питань, пов'язаних з поділом ресурсів, при цьому, як правило, вирішується в якійсь статичній формі і, крім того, обмежується рамками однієї організації. Основним видом інтерактивної взаємодії тут виявляється спілкування в парі клієнт-сервер, а не координоване використання безлічі ресурсів. Ці розгляду наводять на думку те, що GRID-технології можуть зіграти певну роль всередині корпоративного комп'ютингу. Наприклад, у випадку з CORBA, ми могли б сконструювати такий Брокер Запитів Об'єктів (Object Request Broker - ORB), який використовує механізми GSI для дозволу міжвідомчих проблем безпеки. Ми також могли б розробити Адаптер Мобільних Об'єктів (Portable Object Adaptor), який взаємодіє з GRID-протоколом управління ресурсами щодо доступу до ресурсів, розподіленим по всій ВО. Ми змогли б сконструювати такі базуються на GRID служби Іменування і Торгівлі, які використовували б протоколи інформаційного обслуговування GRID для опитування джерел інформації, розподілених між великими ВО. У кожному разі використання протоколів GRID забезпечує удосконалення тієї чи іншої функції (наприклад, междоменной безпеки), відкриває можливість для взаємодії з іншими (non-CORBA) клієнтами. Аналогічні розгляду можуть бути проведені щодо Java і Jini. Наприклад, протоколи та засоби реалізації Jini пристосовані для невеликих наборів апаратури. Середа "Grid Jini", що використовує GRID-протоколи і GRID-служби, дозволила б застосовувати абстракції Jini у великомасштабній, міжвідомчої середовищі.

 

Інтернет і  одноранговий комп'ютинг.

Одноранговий (peer-to-peer) комп'ютинг, (наприклад, застосовуваний у системах поділу файлів таких, як Napster, Gnutella і Freenet [16]) і інтернет - комп'ютинг (застосовуваний, наприклад, системами SETI @ home, Parabon, і Entropia) є більш загальними (чим клієнт-сервер) підходами до поділу програмних і обчислювальних структур, які згадували, характеризуючи суть ВО. У зв'язку з цим вони мають багато спільного з GRID-технологіями. Фактично, ми бачимо, що на сьогодні технічна складова робіт у цих підходах практично не перетинається. Одна з причин в тому, що розробники однорангового та інтернет - комп'ютингу досі цілком зосереджувалися на рішеннях вертикальної інтеграції за принципом "пічної труби" ("stovepipe"), а не на визначенні загальних протоколів, які допускали б поділ інфраструктури і інтероперабельність. (Це, звичайно, загальна характеристика нових ринкових ніш, в яких учасники все ще сподіваються зберегти монополію). Інша причина полягає в тому, що спектр форм поділу, необхідних у різних додатках досить обмежений, наприклад, поділом файлів без контролю доступу або розділяються обчисленнями за допомогою центрального сервера. У міру того, як ці програми стають все більш складними, а потреба в інтероперабельності все більш очевидною, ми будемо свідками інтенсивної збіжності інтересів однорангового, інтернет-та GRID - комп'ютингу [17]. Наприклад, технології одноразової реєстрації, делегування та авторизації можуть бути важливі, коли буде потрібно організувати взаємодію служб поділу обчислень і даних, а політики управління доступом до індивідуальних ресурсів стануть більш досвідченими..

 

8. Перспективи GRID

GRID - це наступна генерація  Інтернет. GRID не є альтернативою  Інтернету: це швидше за все  набір додаткових протоколів  і служб, побудованих на базі  протоколів і служб Інтернету,  для підтримки розробки та  використання додатків у великомасштабній  середовищі обробки даних та  обчислень. Будь-який ресурс, який  є частиною GRID, також, за визначенням,  є частиною Мережі.

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

GRID вимагає розподіленої  операційної системи. З цієї  точки зору програмне забезпечення GRID має передбачати такі служби  операційної системи, що інсталюються  на кожній використовуваної у  ВО системі, які забезпечують  для GRID, ті ж можливості, які  надає операційна система окремого  комп'ютера: а саме, прозорість  щодо розміщення, іменування, безпеки  і т.д. Іншими словами, з цієї  точки зору програмне забезпечення GRID розглядається як засіб створення  якоїсь віртуальної машини. Тим  не менш, ми вважаємо, що такий  погляд суперечить нашим основним  цілям: широкому розповсюдженню  і інтероперабельності. Ми переконані, що відповідна модель – це просто набір інтернет-протоколів, який забезпечує широкий спектр ортогональних служб, спрямованих на унікальні проблеми, що виникають в мережевій середовищі. Високий ступінь фізичної та адміністративної гетерогенності, що має місце в середовищі GRID, означає, що традиційна прозорість недосяжна, з іншого боку, це відкриває можливість досягнення угоди про стандартні протоколах.

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