Вступ до розподілених обчислень

 

Тема 1. Вступ до розподілених обчислень

Питання

1.Загальні питання про розподілені обчислення.

2.Модель розподілених обчислень.

.Різниця між локальними та розподіленими обчисленнями.

.Вісім оман щодо розподілених обчислень.

.Десять технологічних тенденцій розвитку мережних розподілених обчислень.

.Масштаби мережних розподілених обчислень.

Більшість сучасних обчислень є розподіленими. Локальні обчислення, що є основою компютерних наук, і розвиваються до сих пір, є швидше винятком, ніж правилом.

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

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

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

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

. Розподілені обчислення виступають у декількох формах, кожна з яких вимагає свого набору понять, коли наступає час побудови розумної моделі програмування, тобто такої моделі, для якої її архітектори продумано розглядають аспекти, не охоплені ВОВ-моделлю (модель ввід-опрацювання-вивід) розгортання ПЗ (програмне забезпечення) в системі. У табл. 1.1 представлена ієрархічна класифікація систем РО (розподілених обчислень), що природно охоплює системи МРО (мережних розподілених обчислень).

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

Рис. 1. Проста модель МРО

Таблиця 1. Ієрархічна класифікація мереж розподілених обчислень

СімействоТип обчисленьТипове використанняЛокальна (вбудована, наприклад, в автомашину)Закриті РООдин користувачЛокальна (від однієї кімнати до комплексу будинків)Кластерні РОБагато-багатокористувальницькаМережна (закрита ЛОМ)Закриті МРОБагато-багатокористувальницькаМережна (закрита ГОМ)Закриті МРОБагатокористувальницькаМережна (відкрита ЛОМ)Відкриті МРОБагатокористувальницькаМережна (Інтернет)Відкриті МРОВбудована/однокористувальницька/ багатокористувальницька

У цій моделі МРО вихідні дані одного вузла стають входом іншого вузла. У дійсності, як показує модель, інформація може передаватися в обох напрямках.

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

3. Є чотири ключових розходження між локальними обчисленнями і віддаленими (або розподіленими) обчисленнями:

затримка;

доступ до пам'яті;

паралельність;

часткова відмова.

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

Доступ до пам'яті, здійснюваний з арбітражем через рівні абстракції, є корисним і застосовним. Зверніть увагу, що серед інших особливостей, посередниками для пам'яті також служать мови визначення інтерфейсу IDL; такі підходи іноді дозволяють досить добре приховувати фундаментальні різниці пам'яті вузлів МРО, залежно від використання й контексту.

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

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

Паралельність у даному вузлі має на увазі існування процесу системи, що поводиться як «планувальник» і відкладає виконуване поточне завдання, після того, як вона відробить свій інтервал часу («квант часу». Планувальник також відповідає за вибір наступного завдання для виконання і його (пере)запуску.

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

Багатопотокова обробка є видом багатозадачної обробки з малими непродуктивними витратами й без захисту завдань один від другого; всі потоки спільно використовують ту саму пам'ять.

В одиночному вузлі компонента системи або працюють, або ні, і керівний центр, наприклад операційна система, управляє всіма ресурсами. Безліч вузлів розподіленої системи забезпечують потенційно більше ресурсів, але відсутність керівного центра збільшує ресурсну невизначеність. Ця проблема є неминучою, і її нерозумно ігнорувати. В одиночному вузлі задана транзакція або відбувається (і це відомо), або не відбувається (що теж можна довідатися); у мережі додається ймовірність того, що транзакція може відбутися, але часткова відмова не дозволить нам це довідатися. Наприклад, або час віддаленого вузла мине до завершення транзакції, або він завершить транзакцію й потім його час мине, але вузол не зможе підтвердити транзакцію до завершення часу. Ця обставина збільшує в моделі МРО невизначеність, якої немає в локальній моделі і яка виникає майже цілком через відсутність керівного центра.

. Кожен, хто вперше створює розподілений додаток, робить наступні припущення. Всі вони зрештою виявляються помилковими, і всі викликають великі неприємності, а саме:

1.Мережа є надійною.

2.Затримка дорівнює нулю.

.Смуга пропускання необмежена.

.Мережа є безпечною.

.Топологія не змінюється.

.Є тільки один адміністратор.

.Транспортні витрати дорівнюють нулю.

.Мережа однорідна.

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

Табл. 2. Омани і ключові розходження: головні причини

Ключові відмінностіОманиГоловна причинаЧасткова відмова, паралельністьМережа є надійноюКриється в мережному проекті/реалізаціїЗатримкаЗатримка рівна нулюКінечність швидкості світлаПаралельністьСмуга пропущення не обмеженаКриється в мережному проекті/реалізаціїМережа є безпечноюВідсутність керівного центруЧасткова відмова, паралельністьТопологія не змінюєтьсяЄ тільки один адміністраторПаралельністьТранспортні витрати рівні нулюКриється в проекті/реалізації передачі данихДоступ до пам'ятіМережа одноріднаКриється в мережному проекті/реалізації

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

Контекст МРО

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

Експоненціальні закони

Трьома мета тенденціями, що виражаються в експоненціальному виді, є:

закон Мура: щільність транзисторів подвоюється кожні 18-24 місяців;

закон Джілдера: загальна смуга пропускання засобів обміну інформацією подвоюється кожні 6 місяців;

закон Меткалфа: потенційна цінність мережі дорівнює квадрату кількості вузлів.

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

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

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

Відгомони експонентних законів

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

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

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

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

При спробі створити список з десяти основних технологічних тенденцій необхідне об'єднання декількох з них. Хоча цей список не претендує на те, щоб бути повним, він показує масштаб і глибину прискорюваного проникнення мета тенденцій.

1.Бездротові й мобільні обчислення.

.Веб-служби і семантична Web.

.Робототехніка.

.Розшифрування геномів і біотехнологія.

.Матеріалознавство і нанотехнологія.

.Internet2, «всепроникаючі» і «всюдисущі» обчислення.

7.Глобалізація, СОТS і посилення конкуренції.

8.Системи реального часу і вбудовані системи, системи grid-обчислень, кластери і компонованість.

.Безпека, глобальна прозорість і закритість.

.Конкуруючі інфраструктури МРО, глобальна операційна система і рекомбінантне ПЗ.

Масштаби МРО

У табл. 3 перераховані загальні області досліджень в МРО.

Таблиця 3. Деякі області досліджень і розробок у МРО

Grid-обчисленняОднорангові системиСемантична WеЬОпераційні системиВеб-службиПроміжне ПЗБезпекаПросторові обчисленняВсюдисущі обчисленняРозподілене сховище (пам'ять)Всепроникаючі обчисленняРозподілені агентиОбчислення реального часу і вбудованіРозподілені алгоритмиКластерні концепціїРозподілені бази данихКолективні обчисленняРозподілені мультимедіаМасові паралельні системиРозподілені файлові системиМобільні і бездротові системиМережні протоколиНадійні системиМови

Є очевидні зв'язки між цими областями, наприклад, безпека МРО тісно зв'язана з усіма іншими категоріями розробки МРО. Розподілені агенти мають багато загального, принаймні, з всепроникаючими і всюдисущими обчисленнями тощо.

Всюдисущі і всепроникаючі обчислення

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

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

Веб-служби

До стандартизованого підходу з веб-службами до МРО необхідно підходити критично. Можливо необхідно віддати перевагу більш природним підходам, що втілені в розподілених обчисленнях і змішані із проявами обчислень реального часу і вбудованих обчислень. Частина дослідників вважає, що прихід протоколу SОАР ознаменував не найкращий день у світі стандартів Інтернету.

Веб-служби базуються на декількох випливають із ХМL концепцій, призначених для забезпечення стандартизованого мобільного обміну даними «компонентів» у МРО-cередовищах.

Архітектури G1оbаl ХМ Web Servises Architecture (розробники - Microsoft і ІМ.) включає ХМL (розширювана мова розмітки), SОАР (протокол простого доступу до обєкту) і UDDI (інтерфейс універсального каталогу і виявлення), WSDL (мова опису веб-служб).

Архітектура G1оbа1 ХМ Web Servises Architecture визначила б також принципи специфікації, які у зв'язуванні з аспектами семантичної Web могли б у майбутньому обумовити становлення інфраструктури МРО, що була б:

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

загального призначення - призначеної для роботи в широкому діапазоні сценаріїв ХМ Web Servises, від рішень «бізнес для бізнесу» і інтеграції додатків підприємства до однорангових додатків і служб «бізнес для споживача»;

федеративної - повністю розподіленої, призначеної для підтримки служб ХМ Web Servises, що перетинають границі організацій і довірчих середовищ, що не вимагають централізованих серверів або функцій адміністрування;

заснованої на стандартах - заснованої на протоколах, що підкоряються відповідним органам стандартизації.

Колективні обчислення

Головна ідея полягає в тому, щоб розглядати програму як засіб зв'язку з людьми, а не як набір команд комп'ютеру.

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

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

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

Колективні обчислення були б також плідним заняттям для учених, що прагнуть спільно використовувати дані. Дослідники в області біотехнологій, наприклад, добре інформовані про потенціал таких технологій, як ХМL, які при правильному розширенні можуть полегшити колективні зусилля, характерні для дослідницьких дисциплін.

Широкий спектр колективних обчислень, представлених у МРО, є міждисциплінарним по своїй природі; швидше за все, через зусилля НДДКР (науково-дослідницька, дослідницько-конструкторська робота) в цій широкій категорії буде відчуватися гуманізаційний вплив МРО на інформатику в цілому.

Надійні системи

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

У міру росту залежності від МРО у глобальному масштабі ймовірність криз через відмови в мережах і системах також росте. Чим більше МРО-додатків стануть нормою, тим більше розповсюдженими стануть відмови. Надійні системи повинні породжувати довіру в багатьох відносинах, якщо нам потрібно, щоб МРО продовжували збагачувати людську діяльність, не піддаючи її в такому ж ступені ризику.

Далі наведені два приклади з багатьох відмовостійких підходів до ПЗ, застосовних до розробки МРО-додатків. Ці методи в сполученні з іншими добре спроектованими процесами розробки і компонентами послужать створенню більше надійного ПЗ для МРО-систем.

. Метод перезапуску з контрольної точки

Основна частина досліджень надійного ПЗ для МРО проводилася паралельно росту Інтернету. Торес-Помалес привів ряд загальних підходів до відмовостійкості ПЗ, багато з яких можна застосувати до МРО, включаючи методи підвищення відмовостійкості ПЗ в одній версії (тобто, у єдину версію якої-небудь частини ПЗ вводяться додатковий програмний механізм, призначений для виявлення відмов і відновлення після них). Найпоширенішим прикладом такого підходу, наведеним Торрес-Помалесом, є механізм перезапуску з контрольної точки, схема якого наведена на рис. 2.

Рис. 2. Метод єдиної версії з перезапуском з контрольної точки

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

. Метод відновлюючих блоків

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

Тому, якщо одна версія відмовить при даній вхідній інформації, те необхідну вихідну інформацію надасть альтернативна версія.

Один із прикладів, наведених Торес-Помалесом, називається методом «відновлюючих блоків», що сполучить основну ідею перезапуску з контрольної точки з декількома версіями даного компонента: якщо помилка виявлена під час обробки одного варіанта, то виконується інша версія. Як показано на рис. 3, контрольна крапка створюється до виконання, і виявлення помилки в даному модулі може відбуватися в різних контрольних крапках по ходу виконання, а не тільки при вихідному тестуванні.

Рис. 3. Метод відновлюючих блоків

Хоча основна версія більшу частину часу буде виконуватися успішно, метод відновлюючих блоків дозволяє обробляти альтернативні варіанти паралельно (можливо, з меншою точністю, залежно від наявних ресурсів процесора), щоб забезпечувати загальну продуктивність, якщо додаток висуває такі вимоги.

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

З'єднання прикладних розробок і чистої математики є одним зі способів вивчити безпеки МРО. Іншою, більше парадоксальною дихотомією є збалансованість захисту і прозорості даних, яка приводить до характеристик, що піддаються виміру, доступності, якщо вона добре реалізована

Група IЕТ запропонувала такі елементи безпеки в RFC 2828, що визначають потреби Інтернету.

. Міри, прийняті для захисту системи.

. Стан системи в результаті проведення і підтримки мер для захисту теми.

. Стан ресурсів системи, захищений від несанкціонованого доступу і від несанкціонованої або випадкової зміни, руйнування або втрати даних.

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

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

На жаль, більшість сучасних додатків МРО не можуть бути зведені до таких моделей, якщо вони в підсумку повинні реалізувати всюдисущі обчислення.

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

Роботи в області МРО висунули комп'ютерні мови на передній край досліджень. Наприклад, мова програмування JAVA, безперечно, дала початок новому поколінню Інтернет-додатків. За допомогою JAVA-специфікації мова С++ без яких-небудь обмежень була об'єднана з байт-кодом і девізом Написано один раз, працює скрізь, і з'явилася можливість створити нові моделі для додатків, які б охоплювали відкриті мережі. Платформа JAVA була значним кроком у напрямку мережної платформи.

Приклади НДДКР, що ведуться в області мов, про які варто знати розроблювачам МРО:

JAVA/С#. Обєктно-орієнтовані мови, які інтерпретуються віртуальними машинами;

ХМL;

Проект Fох (Fох Рrоjесt) Проміжна мова зі строгим контролем типів і кодом, що несе докази безпеки.

p-саlсиlus. Теоретична модель обчислень для мобільного коду.

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

У цих прикладів розвитку мов у МРО є три такі загальні риси;

. Їхнє серйозне дослідження почалося в 1995 році (нульовому році Мережної ери) або після нього.

. Усі вводять у комп'ютерні мови відсутні до того мережні принципи роботи.

. Усі переглядають підходи до інформаційного обміну між розподіленими вузлами обчислень.

Кластерні концепції

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

Ключем до поняття кластерних обчислень є ідея єдиного образу системи. У кластерах передбачена плавна зміна розмірів і подолання відмов: коли один підвузол у кластері відмовляє, то інший готовий зайняти його місце так, щоб додатки (включаючи і його користувачів) практично цього не помітили. Також застосовуються гібридні кластери, у яких забезпечується достатня кількість підвузлів і є інтелектуальні засоби для подолання відмов і зміни розмірів.

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

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

Розподілені агенти

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

У будь-якій моделі, що базується на агентах, агент може передати (делегувати) деякі повноваження агентові, що може мати інтелект, бути мобільним або й тим, і іншим. Внаслідок невдалого початку, що трапилося зі штучним інтелектом, можливо, не зовсім реалістично говорити про інтелектуальних агентів у МРО. Проте можна сказати, що інтелектуальний агент міг би мати здатність робити висновки на основі правил і проводити імовірнісні аналізи рішень чи навчання від імені свого клієнта.

У контексті МРО мобільний агент може пересуватися між вузлами для виконання доручених йому завдань; такий погляд становить особливий інтерес для мобільних користувачів і мобільних засобів зв'язку. При цьому виникає багато питань у зв'язку з безпекою і моделями, що базується на довірі.

У МРО агенти і характеристики розподілених агентів спочатку розглядалися в проблемному просторі керування системами і мережами. Стандартизація розподілених агентів зараз проводиться в контексті семантичної, а також мови розмітки агентів DAML.

Розподілені алгоритми

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

МРО вводять цікаві вимірювання складності, що вязнуть у змінних часу і простору, які просто не видні моделям локальних обчислень.

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

. Модель синхронної передачі повідомлень.

. Модель асинхронної передачі повідомлень.

. Модель із асинхронним спільним використанням пам'яті.

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

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

Розподілені бази даних

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

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

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

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

Тема 2. Теорія МРО

Питання:

1.Основні принципи МРО.

2.Взаємовідношення теорії і практики в МРО.

.Системи передачі повідомлень.

.Візантійські відмови і проблема вибору лідера.

.Проблеми взаємного виключення в МРО.

.Проблеми відмовостійкості в МРО.

.Проблеми синхронності, причинних звязків і часу в МРО.

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

Таблиця 4. Класи відмов у МРО

Тип відмовиДжерелоОписЗупинкаВузолВузол зупиняється і не перезапускається. Інші вузли можуть виявити такий станВихід з ладуВузолВузол виходить з ладу і не перезапускається. Інші вузли можуть бути не здатні виявити такий станПомилка в каналіКаналПередане повідомлення ніколи не приходитьПомилка передачіВузолВузол завершив передачу, але повідомлення не прийнятеПомилка прийомуВузолПовідомлення прийняте але процес на вузлі його не опрацьовуєВізантійськаВузол чи каналВузол/канал поводиться довільно, включаючи помилки, довільні повідомлення, зупинки чи некоректні кроки опрацюванняГодинник (Таймер)ВузолВузол перевищив допустиму границю (межу) відхилення таймераПродуктивність вузлаВузолВузол перевищив межу інтервалу опрацюванняПродуктивність каналуВузолПеревищено межі передачі повідомлення

В МРО найбільш важким типом відмови є візантійські відмови. Наприклад, на вузлі можуть установитися неточні значення даних, або процес на вузлі може повернути невірне значення у відповідь на запит. Крім неточних або неповних даних, випадкові відмови можуть містити в собі одиничні випадки пропадання повідомлень або відмови через часові співвідношення. Такі відмови виявити значно важче, і тому відновлення після візантійських відмов стало однієї із самих вивчених областей теоретичної інформатики.

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

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

завершення. Кожний вузол у підсумку встановлює свою змінну рішення;

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

цілісність. За умови коректності лідера всім вузлам необхідно погодитися з будь-якою його пропозицією.

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

Крім візантійських відмов, які можуть містити випадкові відмови розроблювач сучасних МРО-систем повинен добре розбиратися в питаннях безпеки, які ортогонально пов'язані з візантійськими проблемами.

Вибір лідера

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

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

кінцевий стан - вузол або обраний, або ні;

коректністъ рішення - лідером обраний точно один вузол; всі інші вузли не обрані.

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

В одному із простих алгоритмів для кільцевої мережі з унікальними ідентифікаторами, показаному на рис. 4,

Рис. 4. Вибір лідера за допомогою ідентифікаторів

кожний вузол посилає повідомлення зі своїм ідентифікатором лівому одноранговому сусідові, а потім чекає повідомлень від свого однорангового сусіда праворуч. Коли він одержує повідомлення, то перевіряє ідентифікатор, що втримується в повідомленні. Якщо ідентифікатор у цьому повідомленні більший від його власного, то він пересилає повідомлення вліво; якщо ні, то він повідомлення не ретранслює. Коли вузол нарешті, одержує повідомлення зі своїм власним ідентифікатором, він оголошує себе лідером.

У підсумку вузол з найбільшим унікальним значенням (п5 на рис. 4) одержить повідомлення, що містить свій власний ідентифікатор, і це буде означати завершення процесу вибору. Кількість повідомлень, переданих у цьому прикладі, буде дорівнює 2n- 1, що є справедливим для будь-якої кільцевої мережі, у якій вузли однозначно розташовані, як показано на рисунку, незалежно від кількості вузлів.

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

Проблема взаємного виключення в МРО полягає в призначенні неподільного ресурсу, що не може використовуватися паралельно і одночасно декількома вузлами. Прикладом такого ресурсу може служити принтер: якщо до нього будуть мати одночасний доступ кілька вузлів. Важливими для рішення проблеми взаємного виключення в МРО є такі умови:

безпека. Одночасно в критично важливій області може виконувати дії тільки один вузол;

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

Найпростішим підходом до досягнення взаємного виключення в МРО є підхід із центральним сервером, що наведено на рис. 5.

Рис. 5. Взаємне виключення в МРО, що керується центральним сервером

Для входу у область вузол посилає повідомлення з запитом в сервер і очікує відповіді. Маркер, що означає дозвіл на вхід у критичну область, міститься у кінцевій відповіді сервера.

У наведеному прикладі вузол n0 запитує ресурс, який в даний час використовується вузлом n1. Вузол вже помістив запит в чергу, що керується центральним сервером. Коли n1 закінчить свою роботу в критичній області, то звільняється даний ресурс. Потім центральний сервер передає маркер дозволу входу вузлу n2 і, відповідно, обновлює чергу, роблячи n0 наступним в черзі.

Даний підхід має певні недоліки, наприклад, якщо ні один з процесів не використовує критичної області, для функціонування системи необхідно передавати два повідомлення (запит і передачу маркера дозволу входу), що додає непотрібні затримки.

Тому використовуються інші алгоритми.

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

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

Відновлення після відмов продовжує бути областю, що розвивається в теорії МРО.

Опрацювання транзакцій

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

Опрацювання транзакцій в інформатиці відбувається подібно до опрацювання транзакцій у бізнесі.

Властивості транзакцій. Транзакції в інформатиці мають такі властивості:

атомарність. Операція неподільна із зовнішньої точки зору;

непротиворечивістъ. Транзакція не порушує інваріанти системи (правильне виконання транзакцій повинне залишати базу даних у погодженому стані);

ізольованість. Транзакція не взаємодіє з іншими паралельними транзакціями.

надійність. Виконана один раз транзакція незмінна.

Показники надійності

Відмови класифікуються як часові, перемежовані (блукаючі) і постійні. Постійні відмови не проходять доти, поки не буде замінений компонент, що відмовив. Необхідно враховувати всі види відмов, щоб отримати відмовостійкі системи МРО.

Реплікація даних і компонентів

Крім алгоритмів відновлення після візантійських відмов і методів відновлюючих блоків, ще однією основною альтернативою для відмовостійкої системи є реплікація (дублювання) даних і компонентів

Причинні зв'язки стосуються порядку подій у часі.. У МРО відсутність керівного центра історично змістило акцент у часову область; синхронізація годинника у мережі може бути проблематичною. Наприклад, в алгоритмі Рікарта і Агравалі для взаємного виключення передбачається, що у вузлів у мережі є якась угода щодо часу, щоб здійснювати ефективний арбітраж мережних ресурсів.

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

Синхронність часу

Із самого початку МРО проблеми відхилення часу від точних показів і їх розфазування доставляли багато неприємностей розроблювачам. За кілька минулих років відбувся деякий прогрес у синхронізації годин МРО за допомогою нових апаратних і програмних механізмів, що дозволяють синхронізувати системи до декількох мілісекунд з універсальним скоординованим часом UTC (Coordinated Universal Time, що є синонімом середньому грінвичському часу GМТ - Greenwich Mean Time).

Прогрес у часовій синхронізації МРО можна описати у виді етапів:

. Синхронізація фізичних годинників.

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

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

Мережний протокол служби часу (NTP). Протокол був уведений в 1995 році для того, щоб дозволити всім вузлам в Інтернеті синхронізуватися з UТС за допомогою декількох підходів, залежно від характеристик локальної мережі. Для високошвидкісних ЛОМ підтримується режим багатоадресної передачі, режим виклику процедур, симетричний режим, призначений для використання серверами часу у ЛОМ. У всіх режимах здійснюється ненадійна передача повідомлень за допомогою стандартного транспортного протоколу Інтернету UDP (протокол передачі користувацьких дейтаграм).

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

Тема 3. Протоколи МРО

Питання:

1.Історична довідка про протоколи МРО

2.Концепція OSI 7

.Cтруктура ТСР/ІР стосовно МРО

.Керуюче програмне забезпечення МРО

Протоколи передачі даних лежать в основі існування Інтернету Знання принципів передачі даних на елементарному рівні також важливо для розроблювачів МРО, як і будь-які знання про мову програмування, середовищу розробки або платформі розгортання.

Коротка історія: від АRРАNЕТ до сучасного Інтернету

Керування перспективних досліджень і розробок уряду США (АRРА) стало замовником проекту АRРАNЕТ в 1968 р. Первісною метою АRРАNЕТ було посприяти установам США в придбанні досвіду взаємного з'єднання комп'ютерів і підвищенні продуктивності досліджень в області інформатики за допомогою кращого колективного використання ресурсів і ідей.

Були ретельно відібрані наукові установи з врахуванням наявних у них можливостей мережної підтримки або інших унікальних ресурсів, які могли б бути використані. Також розглядалися й технічні можливості, тому що вважалося, що для АRРАNЕТ необхідно розробити протоколи, що дозволяють здійснювати інформаційний обмін між різними типами комп'ютерів. Були обрані чотири об'єкти, які відповідали вимогам такої «родоначальної» мережі: Стенфордський дослідницький інститут, Каліфорнійський університет у Лос-Анджелесі, Каліфорнійський університет у Санта-Барбарі, Університет штату Юта.

Первісний протокол інформаційного обміну називався інтерфейсним процесором повідомлень ІМР і призначався для розміщення на кожному об'єкті. Тоді виникла ідея, що обміном між множиною різних комп'ютерних систем може керувати одна комунікаційна система, для якої було необхідно створити стандартний комунікаційний процесор, що надає сполучення з АRРАNЕТ. Тоді на кожному об'єкті було б необхідно розробити тільки один інтерфейс для одного стандартного ІМР. У цій ранній системі був покладений початок стандартам інформаційного обміну для Інтернету. У ній використовували модифікований комп'ютер DDP-516 (стійку розміром з холодильник і з пам'яттю 12 Кбайт), що був у той час одним із самих потужних на ринку міні-комп'ютерів. Передача першого слова LOGIN закінчилась на другій букві - мережа вийшла з ладу.

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

ДО 1981 року обмінювалися даними 213 хостів, і до них приблизно кожні 20 днів додавався новий хост. В 1982 році, коли як комунікаційний протокол для з'єднаних хостів був обраний ТСР/ ІР, був уперше використаний термін «Інтернет», і дійсно з'явилася сучасна мережа з комутацією пакетів.

З погляду керівництва, ріст Інтернету став результатом анархії в співробітництві. В 1979 році була сформована Рада з контролю над Інтернетом і його конфігурацією ІССВ, покликаний спостерігати за проектуванням і реалізацією протоколів усередині існуючого Інтернету. В 1983 році ІССВ був перейменований у Раду по діяльності в Інтернеті ІАВ, який фактично перетворився в організацію по стандартизації стандартів Інтернету.

В 1986 році ІАВ знову перетвориться, щоб здійснювати функцію спостереження за допомогою декількох допоміжних груп. З'явилися дві перші групи: Дослідницька група Інтернету IRTF для спостереження за дослідницькою діяльністю, пов'язаною із ТСР/ IP-Архітектурою Інтернету, і Група по інженерних проблемах Інтернету IЕТF, відповідальна за короткострокові і середньострокові інженерні проблеми, що стосуються Інтернету. Обидві групи існують дотепер.

До 1984 року, коли Вільям Гібсон придумав термін «кіберпростір», кількість хостів в Інтернеті перевищило 1000. Трьома роками пізніше їх стало 10 000. В 1995 році, коли почалася Мережна ера, число хостів в Інтернеті виросло приблизно з 4,8 до 9,5 мільйонів, і URL-Адреси (адреси електронної пошти) почали з'являтися в телевізійній рекламі.

Набір протоколів ТСР/IР, що сприяв зародженню передачі даних в Інтернеті, був уведений в 1982 році. У тому ж році Міжнародна організація по стандартизації OSI опублікувала 7-рівневу концептуальну модель взаємодії відкритих систем OSI для передачі даних. Модель OSI 7 була задумана для використання з мейн-фреймами і визначала протоколи, необхідні для обміну цих систем з такими пристроями, як модеми і термінали. 7 надає спосіб, за допомогою якого можна осмислено обговорювати принципи передачі даних і шляхи здійснення передачі.

Концепція OSI 7:

-розділені функції інформаційного обміну;

-кожний рівень має певний набір функцій;

мінімізована взаємодія між рівнями;

функціональні можливості не розподілені однаково між рівнями

Структура ТСР/ІР може наведена в табл. Обмін даними користувача пов'язаний з рівнями прикладним, відображення і сеансовим - трьома верхніми рівнями концептуального стеку. Три нижніх рівні здійснюють обмін даними, зв'язаний з мережею. На транспортному рівні організовано протокол керування передачею ТСР, що складається із двох частин: інтерфейсу (такого, як розєм) і протоколу «лінії передачі», що у дійсності створюється і підтримується виготовлювачами.

Таблиця 5. Структура ТСР/ІР

КористувачПрикладнийОбмін даними користувачаВідображенняПередача данихСеансовийТранспортнийТСР: інтерфейс і „лінія передачіМережевийЗалежні від мережіКанал між хостом і мережеюКанал данихФізичнийOSI-7(концептуально)ТСР/ІР (реально)

У стеці протоколів Інтернету (звідки походять протоколи ТСР і UDR) відповідальність трьох верхніх концептуальних рівнів: прикладного, відображення і сеансового - беруть на себе програми, що функціонують на цих рівнях. Як показано в табл. 5, це означає, що програми, що функціонують на цих рівнях, будуть відповідати за задачі, які концептуально визначені для цих рівнів.

На транспортному рівні функціонують як ТСР, так і UDR (а також і інші варіанти протоколів), на транспортному рівні створюється віртуальний канал.

Таблиця 6. Стек протоколів Інтернету

ПрикладнийTelnet FTR, SMTP, SNMP, HTPPВідображенняСеансовийТранспортнийTCP, UDPМережевийIPКанал данихARP, RRPФізичнийНе визначеноOSI-7Стек протоколів Інтернету

На підставі традиційних підходів і, отже, можливостей існуючих або успадкованих інфраструктур функціональні області верхнього рівня для керування системами і мережами історично сформувалися в такий спосіб:

керування конфігурацією: облік пристроїв, визначення конфігурації і надання ресурсів;

керування відмовами: «реагуюче» і «попереджувальне» керування відмовами системи;

керування продуктивністю: кількість загублених пакетів, допустимий час очікування, колізії і помилки СRС;

керування безпекою: традиційно не охоплюється додатками, орієнтованими на SNMP;

облік використання ресурсів: керування витратами і відстеження оплати послуг;

керування активами: статистика по пристроях, устаткуванню і адміністративному персоналу;

керування плануванням: аналіз тенденцій для обґрунтування модернізації мережі або збільшення смуги пропускання.

Тема 4. Обмін повідомленнями в МРО

Питання:

1.Суть інформаційного обміну

2.Передача повідомлень

.Схеми передачі повідомлень

По суті, пристосованість МРО обумовила розвиток декількох форм передачі повідомлень, що базуються на стандартизованих протоколах, які універсально застосовні в розробці додатків. Інформаційний обмін полягає не тільки в передачі інформації, але і її прийомі і остаточному розумінні, може бути представлений на зразок концептуальної, моделі OSI 7, як показано на рис. 6.

ОбмінСемантикаПовідомленняПротоколиПередача/прийомДаніРис. 6. Концептуальне подання інформаційного обміну

Навіть під час вражаючого росту Інтернету із середини 1990-х років єдиним найбільш популярним напрямком розробки програмістів була життєво важлива передача повідомлень. По суті, функціональна сумісність, що є «бойовим кличем» моделей з веб-службами, заснована на простій ідеї поміщення об'єкта в контейнер так, щоб зробити його повідомленням. Фактично це є суттю моделі з веб-службами: перетворення зручних для читання людиною веб-сторінок у повідомлення. Після того як дані відображені і перетворені в повідомлення, може бути почата передача таких повідомлень одному або декільком приймачам (для якої може бути необхідна маршрутизація на транспортному рівні моделі ОSI 7 чи вище).

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

Передача повідомлень у МРО може приймати багато форм. Певний тип переданих даних повинен підходити для певної операції, і це ж справедливо відносно форми їхньої передачі. Реалізація широкомовного розсилання повідомлення, наприклад, багато в чому відрізняється від передачі «один до одному». На природу повідомлень, природно, впливають часові співвідношення. Із простої передавальної моделі виникає складний набір реалізацій, що базується на трьох загальних поглядах на повідомлення:

- перетворення даних;

синхронність;

маршрутизація.

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

Спільно використовувана пам'ять у порівнянні з оброблюваними повідомленнями

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

Рис. 7. Схеми передачі повідомлень

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

Концепція перетворення типу даних, імовірно, більш точно визначається як перетворення типу документа; типізація даних на мовному рівні ортогонально співвідноситься з перетворенням даних, що відбувають при передачі повідомлень. Але перетворення даних для кожного документа операційно важливо для передачі повідомлень в Інтернеті і його вузлів. Наприклад, для шифрування і дешифрування повідомлень необхідно здійснювати складні перетворення даних, які повинні виконуватися надійним, упорядкованим образом. Таке опрацювання відбувається в множині точок, розподілених у часі і між ресурсами.

Крім шифрування, іншими прикладами перетворення документів служать опрацювання Java-в-ХМL, оболонки і контейнери метаданих і перетворення таблиць стилів у таких підходах, як XSLT.

Завдяки розширенню ХМL, роботі зі стандартизації і зростаючої доступності інструментів, що підтримують ці стандарти зараз стало можливим генерувати множину типів документів. Наприклад, технологія перетворення документів ХМL полегшила розробку спеціалізованих генераторів коду в проектах по розробці додатків. При цьому теоретично поліпшується функціональна сумісність платформ і інфраструктур.

Переваги підходу із провайдером передачі повідомлень

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

Тобто, асинхронна передача повідомлень по своїй суті є складнішою від снхронної.

Провайдер передачі повідомлень також створює можливість більше високої надійності їхньої передачі, залежно від характеристик вузлів, що беруть участь.

Маршрутизація є одним з аспектів передачі повідомлень у МРО і є завданням мережного рівня. Динамічне визначення шляху проходження інформації в сучасному Інтернеті як і раніше функціонально здійснюється в протоколах передачі даних нижнього рівня моделі ОSI 7.

Широкомовне і групове розсилання

Для МРО широкомовна і групова передача може надати гнучкий вибір варіантів передачі один-до-багатьох. В Інтернеті можливі три типи передачі:

одноадресна: звичайна один-до-одному;

широкомовна: глобальна один-до-багатьох (проходить через маршрутизатор);

багатоадресна, або групова: локальна один-до-багатьох (зупиняється біля маршрутизатора).

Широкомовні МРО-системи висувають багато унікальних і важких задач в області мережного керування. Таким системам, загалом, необхідна висока пропускна здатність (до 20 Мбіт/сек на канал), і до них пред'являються жорсткі вимоги по якості обслуговування для надійної гарантованої доставки; деякі види такої передачі можуть коштувати мільйони доларів за годину. Групове розсилання на основі ТСР/ІР використовувалися в деяких стандартних прикладних інфраструктурах, таких як мережна технологія Jini, і певною мірою в проекті JХТА.

Тема 5. GRID - технології

Питання:

1. Вступ до Грід-технологій

. Концепція Грід

. Архітектура Грід

. Понятие про віртуальну організацію

. Про розподіленя ресурсів в Грід

. Інструментальні засоби Грід

. Програмне забезпечення Грід

. Користувач в Грід

. Глобальна інфраструктура Грід для науки

.Грід в НУ Львівська політехніка

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

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

Є три напрямки розвитку технології Грід:

обчислювальний Грід;

Грід для інтенсивного опрацювання даних;

семантичний Грід для оперування даними з різних баз даних.

Метою першого напрямку є досягнення максимальної швидкості обчислень за рахунок глобального розподілу цих обчислень між комп'ютерами - наприклад, проект DEISA (www.desia.org), у якому об'єднуються суперкомп'ютерні центри.

Метою другого напрямку є опрацювання величезних обсягів даних відносно нескладними програмами за принципом «одне завдання - один процесор». Доставка даних для опрацювання і пересилання результатів у цьому випадку є досить складним завданням. Для цього напрямку інфраструктура Грід є об'єднанням кластерів. Один із проектів, метою якого є створення виробничої Грід-системи для опрацювання наукових даних, є проект EGEE (Enabling Grids for E-scienc), що виконується під егідою Європейського Союзу (www.eu-egee.org <#"justify">-координація використання ресурсів при відсутності централізованого керування ними;

-використання стандартних, відкритих, універсальних протоколів і інтерфейсів;

-забезпечення високоякісного обслуговування користувачів.

Грід є технологією забезпечення гнучкого, безпечного і скоординованого загального доступу до ресурсів. При цьому «ресурс» розуміється апаратура (жорсткі диски, процесори), системне і прикладне ПЗ (бібліотеки, додатки).

У термінології Грід сукупність людей і організацій, що вирішують спільно загальне завдання і надають один одному свої ресурси, називається віртуальною організацією (ВО).

Є два основних критерії, що виділяють Грід-системи від інших систем, що забезпечують роздільний доступ до ресурсів:

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

. Грід-Система будується тільки на базі стандартних і відкритих протоколів, сервісів і інтерфейсів.

Додаткові властивості, які повинні мати Грід-системи:

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

-масштабованість (працездатність при збільшенні чи зменшенні складу системи);

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

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

-гарантії якості обслуговування;

-можливість одночасної, скоординованої роботи з декількома ресурсами.

Найчастіше реалізації Грід-систем забезпечують роботу з такими типами ресурсів:

обчислювальні ресурси - окремі комп'ютери, кластери;

ресурси зберігання даних - диски і дискові масиви, стрічки, системи масового зберігання даних;

мережні ресурси;

програмне забезпечення - яке-небудь спеціалізоване ПЗ.

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

Грід - технологія відрізняється і від технології паралельних обчислень. У рамках конкретної Грід-системи, звичайно, можливо організувати паралельні обчислення з використанням існуючих технологій (PVM, MPI), оскільки Грід-систему можна розглядати як якийсь мета-комп'ютер, що має безліч обчислювальних вузлів. Проте технологія Грід не є технологією паралельних обчислень, у її завдання входить лише координація використання ресурсів.

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

Базовий рівень (Fabric Layer) описує служби, що безпосередньо працюють із ресурсами (рис.9). Є такі ресурси:

-обчислювальні ресурси;

-ресурси зберігання даних;

-інформаційні ресурси, каталоги;

-мережні ресурси.

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

Ресурси пам'яті - простір для зберігання даних. Для доступу до ресурсів пам'яті використовується ПЗ проміжного рівня, що реалізує уніфікований інтерфейс керування і передачі даних. Як і у випадку обчислювальних ресурсів, фізична архітектура ресурсу пам'яті не принципова для Грід-системи. Основною характеристикою ресурсу пам'яті є його обсяг.

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

Мережний ресурс є сполучною ланкою між розподіленими ресурсами Грід-системи. Основною характеристикою мережного ресурсу є швидкість передачі даних.

Рівень зв'язку (Connectivity Layer) визначає комунікаційні протоколи і протоколи аутентифікації.

Комунікаційні протоколи забезпечують обмін даними між компонентами базового рівня.

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

Незважаючи на існуючі альтернативи, на даний час протоколи рівня зв'язку в Грід-системах припускають використання тільки стеку протоколів TCP/IP, зокрема: на мережному рівні - IP і ICMP, транспортному рівні - TCP, UDP, на прикладному рівні - HTTP, FTP, DNS, RSVP.

Для забезпечення надійного транспорту повідомлень у Грід-Системі повинні використовуватися рішення, що передбачають гнучкий підхід до безпеки комунікацій (можливість контролю над рівнем захисту, обмеження делегування прав, підтримка надійних транспортних протоколів). У цей час ці рішення ґрунтуються як на існуючих стандартах безпеки, споконвічно розроблених для Інтернет (SSL, TLS), так і на нових розробках.

Ресурсний рівень (Resource Layer) побудований над протоколами комунікації і аутентифікації рівня зв'язку архітектури Грід. Ресурсний рівень реалізує протоколи, що забезпечують виконання таких функцій:

-узгодження політик безпеки використання ресурсу;

-процедура ініціації ресурсу;

-моніторинг стану ресурсу;

-контроль над ресурсом;

-облік використання ресурсу.

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

Розрізняють два основних класи протоколів ресурсного рівня:

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

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

Колективний рівень (Collective Layer) відповідає за глобальну інтеграцію різних наборів ресурсів, на відміну від ресурсного рівня, сфокусованому на роботі з окремо взятими ресурсами. У колективному рівні розрізняють загальні і специфічні (для додатків) протоколи. Загальні протоколи - протоколи виявлення і виділення ресурсів, системи моніторингу і авторизації співтовариств. Специфічні протоколи створюються для різних додатків Грід - протокол архівації розподілених даних, протоколи керування завданнями збереження стану тощо).

Компоненти колективного рівня пропонують різні методи спільного використання ресурсів. Функції і сервіси, які реалізовані в протоколах даного рівня такі:

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

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

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

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

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

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

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

-сервіси координації підтримують обмін інформацією в потенційно великому співтоваристві користувачів.

Прикладний рівень (Application Layer) описує користувальницькі додатки, що працюють у середовищі віртуальної організації. Додатка функціонують, використовуючи сервіси, визначені на нижчих рівнях. На кожному з рівнів є певні протоколи, що забезпечують доступ до необхідних служб, а також прикладні програмні інтерфейси (Application Programming Interface - API), що відповідають даним протоколам.

Для полегшення роботи із прикладними програмними інтерфейсами користувачам надаються набори інструментальних засобів для розробки програмного забезпечення (Software Development Kit - SDK).

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

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

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

Таким чином, можна визначити Грід-систему як просторово розподілене операційне середовище із гнучким, безпечним і скоординованим поділом ресурсів для виконання додатків у рамках певних віртуальних організацій.

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

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

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

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

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

У розподіленому середовищі, який є Грід-система, важливою властивістю є відсутність так званої єдиної точки збою. Це означає, що відмова будь-якого ресурсу не повинна приводити до збою в роботі всієї системи. Саме тому планувальник, система моніторингу і інші сервіси Грід-системи розподілені і продубльовані.

Розглянемо набір інструментальних засобів, використовуваних при реалізації проектів Грід і розроблених у рамках проекту Глобус (Globus Project), які дозволяють побудувати повнофункціональну Грід-Систему:

-GRAM (Globus Resource Allocation Manager), відповідальний за створення/видалення процесів. Встановлюється на обчислювальному вузлі (наприклад, робоча станція, обчислювальний кластер) Грід-системи. Користувальницькі додатки формують запити до GRAM спеціальною мовою RSL (Resource Specification Language).

-MDS (Monitoring and Discovery Service) забезпечує способи подання інформації (наприклад, дані про конфігурацію або стан як всієї системи, так і окремих її ресурсів - тип ресурсу, доступний дисковий простір, кількість процесорів, обсяг пам'яті, продуктивність та інше) про Грід-Систему. Вся інформація логічно організована у вигляді дерева, і доступ до неї здійснюється по стандартному протоколі LDAP (Lightweight Directory Access Protocol).

-GSI (Globus Security Infrastructure) забезпечує захист, що включає шифрування даних, а також аутентифікацію (перевірка достовірності, при якій установлюється, що користувач чи ресурс дійсно є тим, за кого себе видає) і авторизацію (процедура перевірки, при якій установлюється, що аутентифікований користувач або ресурс дійсно має права доступу) з використанням цифрових сертифікатів Х.509.

-GASS (Global Access to Secondary Storage) надає можливість зберігання масивів даних у розподіленому середовищі і доступу до цих даних. Визначає різні стратегії розміщення даних.

-Бібліотеки globus_io і Nexus використовуються як прикладними програмами так і компонентами Globus Toolkit для мережної взаємодії вузлів у гетерогенному середовищі.

Архітектура засобів керування ресурсами (Globus Resource Management Architecture - GRMA) має багаторівневу структуру (рис. 10).

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

При виборі обчислювального вузла брокер ресурсів повинен визначити, які вузли доступні в даний момент, їхнє завантаження, продуктивність і інші параметри, зазначені в RSL-запиті, вибрати найбільш оптимальний варіант (це може виявитися один чи кілька обчислювальних вузлів), згенерувати новий RSL-Запит (ground RSL) і передати його високорівневому менеджерові ресурсів (co-allocator). В запиті будуть вже більш конкретні дані, такі, як імена конкретних вузлів, необхідне кількість пам'яті і др. Основні функції високорівневого менеджера ресурсів такі:

-колективне виділення ресурсів;

-додавання/видалення ресурсів;

-одержання інформації про стан задач;

-передача початкових параметрів задачам.

Високорівневий менеджер ресурсів робить декомпозицію запитів ground RSL на множину простіших RSL-запитів і передає ці запити GRAM. Далі, при відсутності повідомлень про помилки від GRAM, завдання користувача запускається на виконання. У випадку, якщо один з GRAM повертає помилку, завдання або знімається з виконання, або спроба запуску виробляються повторно.

Менеджер GRAM надає верхнім рівням універсальний API для керування ресурсами вузла Грід. Сам GRAM взаємодіє з локальними засобами керування ресурсами вузла.

Організація доступу до ресурсів

GRAM - досить низькорівневий компонент Globus Toolkit, що є інтерфейсом між високорівневим менеджером ресурсів і локальною системою правління ресурсами вузла і може взаємодіяти з такими локальними системами керування ресурсами:

-PBS (Portable Batch System) - система керування ресурсами і завантаженням кластерів. Працює на платформах: Linux, FreeBSD, NetBSD, Digital Unix, Tru64, HP-UX, AIX, IRIX, Solaris.

-LSF (Load Sharing Facility) - аналогічна PBS. Розроблена компанією Platform Computing.

-NQE (Network Queuing Environment) - продукт компанії Cray Research, що використовується як менеджер ресурсів на суперкомп'ютерах, кластерах і системах Cray, може працювати і на інших платформах.

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

-Condor - вільно доступний менеджер ресурсів, розроблений студентами університетів Європи і США. Аналогічний перерахованим вище. Працює на платформах UNIX і Windows NT.

-Easy-LL - спільна розробка IBM і Cornell Theory Center, призначена для керування великим кластером IBM у цьому центрі. По суті є об'єднанням LoadLeveler і продукту EASY лабораторії Argonne National Lab.

-fork - найпростіший стандартний засіб запуску процесів в UNIX.

Структура GRAM представлена на рис. 11.

Щоб на даному обчислювальному вузлі можна було віддалено запускати на виконання програми, на ньому повинен виконуватися спеціальний процес Gatekeeper, який працює в привілейованому режимі і виконує такі функції:

-проводить взаємну аутентифікацію із клієнтом;

-аналізує RSL запит;

-відображає клієнтський запит на обліковий запис деякого локального користувача;

-запускає від імені локального користувача спеціальний процес Job Manager, і передає йому список необхідних ресурсів.

Після того, як Gatekeeper виконає свою роботу, Job Manager запускає завдання (процес або кілька процесів) і робить його подальший моніторинг, повідомляючи клієнта про помилки і інші події. Gatekeeper запускає тільки один Job Manager для кожного користувача, що керує всіма завданнями даного користувача. Коли завдань більше не залишається, Job Manager завершує роботу.

Всі перераховані компоненти, включаючи користувальницькі додатки, можуть використовувати інформаційний сервіс (Information Service) для одержання всієї необхідної інформації про стан Грід-системи. В Globus Toolkit роль інформаційного сервісу грає MDS. Цей компонент відповідає за збір і надання конфігураційної інформації, інформації про стан Грід-системи і її підсистем, а також забезпечує універсальний інтерфейс одержання необхідної інформації. MDS має децентралізовану, легко масштабовану структуру і працює як зі статичними, так і з динамічними даними, необхідними користувальницьким додаткам і різним сервісам Грід-системи. Ієрархічна структура MDS наведена на рис. 12.

MDS складається із трьох основних компонентів:

- IP (Information Provider) - є джерелом інформації про конкретний ресурс або частину ресурсу;

GRIS (Grid Resource Information Service) - надає інформацію про вузол Грід-системи. GRIS опитує індивідуальні IP і обєднує отриману від них інформацію в межах єдиної інформаційної схеми;

GIIS (Grid Index Information Service) - обєднує інформацію з різних GRIS або інших GIIS. Для зменшення часу реакції на запит і зниження мережного трафіка GIIS кешу дані. GIIS верхнього рівня містить всю інформація про стан даної системи Грід.

Інфраструктура безпеки Грід (Grid Security Infrastructure - GSI) забезпечує безпечну роботу в незахищених мережах загального доступу (Інтернет), надаючи такі сервіси, як аутентифікація, конфіденційність передачі інформації і єдиний вхід у Грід-систему. заснована на надійній і широко використовуваній інфраструктурі криптографії з відкритим ключем (Public Key Infrastructure - PKI).

Як ідентифікатори користувачів і ресурсів в GSI використовуються цифрові сертифікати X.509, в процедурі видачі/одержання сертифікатів задіяні:

центр сертифікації (Certificate Authority - CA) - спеціальна організація, що володіє повноваженнями видавати (підписувати) цифрові сертифікати;

підписчик - це людина або ресурс, що користується сертифікаційними послугами CA. CA включає в сертифікат дані, надавані передплатником (ім'я, організація та ін.) і ставить на ньому свій цифровий підпис.

користувач - це людина або ресурс, що покладається на інформацію із сертифіката при одержанні його від передплатника. В Globus Toolkit використовуються два типи сертифікатів X.509: сертифікат користувача (User Certificate), сертифікат вузла (Host Certificate) - вказується доменне ім'я конкретного обчислювального вузла.

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

Для рішення цієї проблеми на Global Grid Forum (GGF) була запропонована Відкрита архітектура сервісів Грід (Open Grid Services Architecture - OGSA). Стандарт OGSA визначає основний набір послуг, які надають Грід-системи, і описує їхню архітектуру.

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

Рівні архітектури OGSA наведені на рис. 13.

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

Середній рівень являє собою послуги на якому здійснюється узагальнення (віртуалізація) ресурсів. Користувачеві надаються високорівневі послуги із чітко визначеними інтерфейсами.

Верхній рівень представляє додатки, що використовують послуги для виконання різних завдань. Цей рівень в OGSA не специфікований.

Більша частина деталей, пов'язаних з конкретною реалізацією сервісів, в OGSA не обумовлюється. Замість цього OGSA опирається на сімейство технологій веб-сервісів (Web-services) Архітектура OGSA зосереджується на визначенні послуг у вигляді набору взаємодіючих сервісів.

Архітектура розроблялася з врахуванням таких ключових вимог, отриманих шляхом аналізу сценаріїв використання Грід-Систем. Цими вимогами є:

. Інтероперабельність. Більшість Грід-Систем є розподіленими і гетерогенними, тобто можуть містити в собі велику кількість платформ, операційних систем і мереж. Для ефективної роботи в таких умовах Грід-система повинна відповідати таким вимогам:

віртуалізація ресурсів (представлення ресурсів в узагальненій формі, що дозволяє абстрагуватися від непринципових розходжень ресурсів, що виконують ту саму функцію);

загальні способи керування (узагальнені механізми керування різнорідними ресурсами для спрощення адміністрування Грід-систем);

виявлення ресурсів (механізми забезпечення пошуку ресурсів з необхідними властивостями в гетерогенному оточенні);

стандартні протоколи (стандартизація протоколів для побудови гетерогенної інтероперабельної системи).

. Поділюваний доступ. Грід-система повинна дозволяти організовувати поділюваний доступ до ресурсів, що належать різним організаціям.

. Безпека включає такі вимоги:

аутентифікація і авторизація;

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

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

. Запуск завдань. Можливість запуску завдань на віддалених обчислювачах. При цьому пред'являються такі вимоги:

підтримка різних типів завдань;

керування завданнями;

диспетчеризація - завдання повинні автоматично направлятися на підходящі обчислювальні ресурси з урахуванням певних вимог (тип ОС, наявність бібліотек, кількість одночасно доступних обчислювачів тощо);

забезпечення ресурсами (засоби для автоматичного виділення потрібних завданню ресурсів і підготовки до їхнього використання).

. Маніпуляція даними. Повинні забезпечувати ефективні методи роботи з величезною кількістю даних. Необхідне виконання таких умов:

цілісність даних - механізми кешування і реплікації, що не приводять до одержання застарілих даних;

інтеграція даних - механізми для забезпечення одночасної роботи з декількома джерелами даних;

пошук даних.

. Гарантії якості обслуговування. Повинні забезпечуватися такі умови: мінімально допустима пропускна здатність мережі, гарантована продуктивність обчислювача, гарантований рівень безпеки тощо. При цьому можуть висуватися такі додаткові вимоги:

угода про якість обслуговування;

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

. Оптимізація виділення ресурсів. Грід-системи повинні вміти ефективно використовувати наявні ресурси і уміти оптимізувати їхнє виділення. Повинні використовуватися гнучкі механізми, наприклад, розподіл ресурсів на невеликі інтервали часу з наступним переглядом параметрів виділення.

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

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

. Простота використання і розширюваність.

. Масштабованість.

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

Прикладом такого ПЗ може бути ПЗ LCG (LHC Computing Grid) - розробник: Європейський центр ядерних досліджень CERN.

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

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

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

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

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

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

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

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

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

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

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

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

На один комп'ютер можлива установка відразу декількох елементів LCG, мінімальна кількість вузлів, необхідних для розгортання повного набору ПЗ LCG, дорівнює трьом.

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

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

єдиний вхід. Користувач повинен реєструватися і аутентифікуватися тільки один раз на початку сеансу роботи;

делегування прав. Користувач повинен мати можливість запуску програм від свого імені і делегувати частина своїх прав іншим програмам;

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

Для входу в Грід-систему користувач повинен:

бути легальним користувачем обчислювальних ресурсів у своїй організації;

мати персональний цифровий сертифікат, підписаний центром сертифікації;

бути зареєстрованим хоча б в одній ВО.

Веб-інтерфейси Грід

Прикладом веб-інтерфейсу до Грід-системи може бути GENIUS, розроблений в італійському інституті INFN (grid-demo.ct.infn.it), основною метою при створенні якого є:

ознайомлення користувача з технологією Грід;

надання доступу до сервісів Грід-системи через Інтернет;

простий і зручний графічний інтерфейс;

ефективний моніторинг поточного стану Грід-системи.

Веб-Інтерфейс GENIUS дозволяє виконувати всі основні операції по керуванню задачами і даними в Грід-системі, причому всі ці дії користувач може робити прямо із браузера.

Проект GILDA складається з таких частин:

GILDA Testbed - набір сайтів із установленим ПЗ LCG;

Grid Demonatrator - веб-інтерфейс GENIUS, що дозволяє працювати з певним набором додатків;

GILDA CA - центр сертифікації, що видає 14-денні сертифікати для роботи з GILDA;

GILDA VO - ВО, що обєднує всіх користувачів GILDA;

Grid Tutor - веб-інтерфейс GENIUS, використовується для демонстрації можливостей технології Грід;

Monitoring System - система моніторингу для GILDA Testbed.

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

Як приклад, розглянемо одну з найпотужніших у світі інфраструктура Грід, що реалізована в рамках проекту EGEE (Enable Grid E-scienc).

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

Для відпрацьовування, офіційної оцінки експлуатаційних якостей і функціональності системи обрані дві практичні області. Одна - опрацювання даних від експериментів на прискорювачі LHC, де Грід-Інфраструктура забезпечує зберігання і аналіз петабайтів (1015 байтів) реальних і змодельованих даних експериментів з фізики високих енергій, що ведуться в CERN. Інша - біомедичні Гріди, де декілька колаборацій розвязують однаково складні завдання, наприклад, пошук у геномних базах даних і індексування лікарняних баз даних, що становить декілька терабайтів у рік для однієї лікарні.

У рамках цієї інфраструктури створено понад 60 ВО.

У проекті EGEE беруть участь більше 90 організацій з 32 країн. Ці організації об'єднані в регіональні Гріди (федерації). У проекті беруть участь 13 федерацій. Сумарна обчислювальна потужність даної Грід-інфраструктури становить у даний момент понад 20 тисяч процесорів.

Проект EGEE має партнерські відносини з більш ніж 70 учасниками, що не входять у даний проект, у тому числі через ряд інших проектів Грід (рис. 14).

У завдання проекту входить:

-поширення інформації про технологію Грід;

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

-підтримка додатків;

-підтримка і обслуговування інфраструктури Грід і взаємодія з основними провайдерами;

-розробка і інтеграція програмного забезпечення проміжного рівня;

-забезпечення безпеки;

-розробка мережних сервісів.

У рамках проекту працюють:

Служба поширення інформації і розширення кола користувачів (Dissemination and Outreach Activity) тримає зібрані воєдино всі головні відомості про проект разом з посиланнями на відповідні регіональні веб-сайти (див. www.eu-egee.org). Крім того, ключові користувальницькі групи і групи потенційних користувачів можуть одержувати повідомлення зі спеціалізованих списків розсилання інформації з електронної пошти;

Служба навчання і включення до числа користувачів (Training and Induction Activity) випускає комплект навчальних матеріалів і курсів англійською мовою. Навчання організоване за регіональним принципом, і ключові матеріали можуть бути перекладені на відповідну європейську мову.

Служба розробки і інтеграції проміжного ПЗ для Грід (Grid Middleware Engineering and Integration Activity) підтримує і постійно вдосконалює набір програмних засобів, завдяки якому Грід-сервіси промислового рівня доступні основному колу користувачів. Діяльність, пов'язана із проміжними програмними засобами EGEE, полягає, головним чином, у їхньому перепроектуванні в плані їхньої функціональності. Проміжне програмне забезпечення розвивається в напрямку сервісно-орієнтованої архітектури, яка базується на стандартах, розроблених у рамках веб-сервісів. Центри перепроектування проміжного програмного забезпечення відповідають за такі ключові сервіси: доступ до ресурсів (Італія), організація даних (CERN), пошук і збір інформації (Великобританія), брокерські операції з ресурсами і облік ресурсів (Італія), безпека (країни Північної Європи). Безпосереднє відношення до цієї роботи мають групи забезпечення якості і безпеки Гридов (Quality Assurance and Grid Security). Центр інтеграції і тестування проміжного програмного забезпечення (Middleware Integration and Testing Center) перебуває в CERN.

Групи, що забезпечують експлуатацію Грід, гарантують високий рівень Грід-сервісів. Основними якостями, що визначають такий рівень Грід-Сервісів, є їхня керованість, стійкість до збоїв і різного роду несправностям, єдиний підхід до забезпечення безпеки, а також їхня розширюваність, необхідна для включення в роботу нових ресурсів негайно в міру їхньої появи. Головні завдання цих груп: підтримка базових сервісів інфраструктури, моніторинг і контроль Гридів, розміщення проміжного програмного забезпечення, підключення ресурсів, підтримка ресурсів і користувачів, загальне керування Гридами і міжнародне співробітництво. Оперативний центр (Operations Management Centre - ОМС) в CERN погоджує роботу п'яти центрів базової інфраструктури (Core Infrastructure Centre - CIC), розташованих в CERN, Франції, Італії, Росії, Великобританії, і восьми регіональних оперативних центрів (Regional Operation Centre - ROC), які, у свою чергу, координують роботу ресурсних центрів (Resource Cerntre - RC). Структура керування інфраструктурою Грід у проекті EGEE наведена на рис. 15.

Робота EGEE для масового користувача базується на проміжному програмному забезпеченні і сервісах проекту LCG (www.cern.ch/lcg).

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

Як транспортне середовище для передачі даних і програми інфраструктури EGEE використовує дослідницьку мережу GEANT і підключені до неї регіональні мережі.

Для включення в Грід-інфраструктуру EGEE нових користувачів і наукових співтовариств діють Служби прийому заявок і підтримки (Application Identification and Support Activity), які ідентифікують і підтримують починаючих користувачів із широкого кола академічних дисциплін і галузей економіки.

Проект створення національної Grid - інфраструктури для розвитку інформаційного суспільства в Україні, її склад і задачі вперше були озвучені академіком НАНУ Згуровським М.З на самітті WSIS (World Summit on Information Societу) у 2004 році. Мова йшла про необхідність створення освітнього і дослідницького сегменту інформаційного суспільства України з двома головними напрямками: широке використання інформаційних і комунікаційних технологій на всіх стадіях наукових досліджень і освіти, а також інформаційне управління відповідними галуззями.

Запропоновані цілі і задачі знайшли своє відображення вже у 2005 році в Державній цільовій програмі «Інформаційні та комунікаційні технології в освіті й науці на 2006-2010 роки», прийнятій Кабінетом Міністрів України (Постанова КМ України №1153 від 7 грудня 2005 року). Національний технічний університет «Київський політехнічний інститут виграв тендер проектів з реалізації завдання « Створення національної Grid - інфраструктури для підтримки наукових досліджень» цієї Державної цільової програми, оголошений Міністерством освіти і науки України.

Grid сегмент МОНУ на відміність від Grid сегменту НАНУ, який є Grid обчислювального типу (Computing Grid), можна віднести до Grid інформаційного типу (Data Grid), тому що проект Ugrid головним чином повязаний з забезпеченням обслуговування Української філії Світового Центру Даних (УФ СЦД), надавши його клієнтам віддалений доступ до світових сховищ наукових даних, можливості ефективного сумісного використання компютерів, унікальних експериментальних установок і приладів.

Згідно з рішенням Академії наук України від 3 квітня 2006 р. Українська філія СЦД є головною структурою на Україні, яка здійснює накопичення, збереження й обробку національних і світових даних, наданих відповідними організаціями (Інститут геофізики ім. С.І. Суботіна НАН України (Відділ сейсмічної небезпеки, Відділ геотермії й сучасної геодинаміки, Відділ геомагнетизму, Відділ глибинних процесів Землі і гравіметрії, Відділ фізичних властивостей речовини Землі і т.д.), Кримська експертна рада з оцінювання сейсмічної небезпеки й прогнозування землетрусів, Міністерство архітектури і будівельної політики АР Крим, Полтавська гравіметрична обсерваторія, Геомагнітні обсерваторії (Київ, Львів, Одеса), Іоносферні станції, Національний антарктичний науковий центр Міністерства освіти і науки України (Геомагнітна обсерваторія - Аргентина, Айленд), Головна Астрономічна обсерваторія НАНУ, Львівський державний університет (Обсерваторія Львів), Одеський державний університет (Обсерваторія Одеса), Кримська Астрофізична обсерваторія НДІ Міністерства освіти і науки України (Обсерваторія КРАО),Харківський інститут радіоелектроніки (ХНУРЕ)та ін.).

Проект Ugrid виконує команда з 10 : різних українських організацій (2-х академічних, 6-ти освітянських і 2-х промислових), яку очолюють Інститут Системного Аналізу (ІПСА) Національного Технічного Університету Київський політехнічний Інститут. Науковим керівником проекту є Михайло Захарович Згуровський, ректор НТУУКПІ, академік НАНУ, один з ініціаторів впровадження Grid технологій в Україні.

Серед виконавців проекту, крім НТУУКПІ, є Інститут проблем моделювання в енергетиці імені Г.Є. Пухова НАНУ (ІПМЕ), Харківський національний університет радіоелектроніки (ХНУРЕ), Львівський національний технічний університет „Львівська політехніка (НУЛП),, Запорізький національний технічний університет (ЗНТУ), Донецький національний політехнічний інститут (ДонНПІ), Дніпропетровський національний гірничий університет (ДНГУ), державне підприємство Львівський науково-дослідний радіотехнічний інститут(ЛНДРІ) і підприємство ЮСТАР.

Поточні обчислювальні ресурси проекту наведені в табл. 7.

Табл. 7. Власні обчислювальні ресурси проекту UGrid

ClusterProces-sorsNODs/ CPURAM/NOD (GB)HD (GB)STO-RAGE (TB)1. KPI Cluster, Национальный технический университет Украины «Киевский политехнический институт»33684/42362. ХНУРЕ, Харківський національний університет радіоелектроніки1010/11200,23. ЗНТУ, Запоріжський національний технічний університет252/1012004. НТУ Львівська політехніка82/432005. ДонНТУ, Донецький національний технічний університет121/12126.

Після модернізації кластеру НУТУ „КПІ він буде складатися з 586 процесорів з піковою потужністю вище 6 Тфлопс.

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

Передбачається створити Grid інфраструктуру з 6-ю ресурсно-операційними центрами (в Києві, Харкові, Донецьку, Дніпропетровську, Запоріжжі і Львові) і розпочати відділене обслуговування майбутніх користувачів - науковців з університетів та наукових установ України. ділянці.

1. В червні 2007 року підписана Угода з європейською організацією DANTE про підключення Національної науково-освітньої мережі УРАН (www.uran.net.ua <#"266" src="doc_zip15.jpg" />

Рис. 16. Отримання доступу користувачем через Web-портал SDGrid

. Встановлено програмного забезпечення NetSolve на кластері НТУУ КПІ для надання дослідникам можливості використання ресурсів Grid при проведенні обчислень в звичних для них робочих середовищах MATLAB/Mathematica/OctaveFortran/C/, встановлених на персональних компютерах. Користувач не піклується тепер про те, де знаходиться, як виявляється і викликається потрібний йому Grid ресурс; він тільки вказує ті критерії, за якими необхідно підібрати йому цей ресурс, і взаємодіє далі з цим ресурсом так само, як і з локальними ресурсами (процедурами, класами, програмами) його робочого середовища.

Докладніше дослідження, що проводяться, виглядають так

НТУУКПІ: Створення порталу знань, дослідження сумісності (inetroperability) проміжного програмного слою, створення Grid-додатка для моделювання сучасних мікро-електронно-механічних систем (МЕМС);

НТУ Львівська політехніка: створення потужної системі збереження даних на базі з використанням системи IBM BladeCenter QS21, що складається з 14 обчислювальних блейд-серверів на базі процесорів Cell та одного координуючого вузла;

- ЗНТУ, Запоріжський національний технічний університет: паралельна програмна модель нейронної мережі, дослідження паралельної реалізації методу молекулярної динаміки;

- ХНУРЕ, Харківський національний університет радіоелектроніки: програмне забезпечення для тестування продуктивності бібліотеки PVM.

Аналіз характеристик та напрямків застосування GRID-порталу у Львівському центрі GRID

Дослідження вимог та характеристик Grid-порталупортал забезпечує доступ користувачів до ресурсів, що є основними поняттями Grid-систем, та повинен відповідати таким вимогам [5]:

.Доступність. Доступ до Grid-порталу повинен здійснюватись з будь-якого місця та не залежати від типу обладнання користувача;

2.Доступ до різних служб повинен здійснюватись, використовуючи один той самий інтерфейс користувача;

3.Безпека. Необхідною умовою роботи в Grid є безпека інформації на всіх рівнях взаємодії користувача із системою, зокрема:

захищена передача даних по Web;

захищеність параметрів доступу користувача;

аутентифікація користувача;

захищеність на рівні віртуальної організації;

4.Інтерфейс користувача має бути достатньо простим та зрозумілим.

По суті будь-який Grid-портал являє собою графічний Web-інтерфейс, основними функціями якого є:

1.Навчання користувачів технології Grid-обчислень;

2.Забезпечення доступу до ресурсів Grid-систем через Інтернет;

.Ефективний моніторинг біжучого стану Grid-системи.

Тобто Grid-портал дозволяє здійснювати управління завданнями та даними в Grid-системі безпосередньо з браузера.

Доступ користувачів до ресурсів Grid-систем, зокрема до ресурсів Центру Суперкомпютерних Обчислень НТУУ «КПІ» здійснюється шляхом авторизації користувача за допомогою цифрових сертифікатів. Для надання сертифікатів в Україні відкрито Сертифікаційний центр відкритих ключів, який обслуговує всю національну Grid-інфраструктуру.

Отримання сертифікату є головним та необхідним кроком для отримання доступу до Grid-системи. Цифровий сертифікат є аналогом паспорту та дозволяє однозначно ідентифікувати користувача. Доступ до Grid-системи може бути здійснений з будь-якої точки (терміналу), в якій наявне відповідне програмне забезпечення (ПЗ).

При доступі до ресурсів Центру Суперкомпютерних Обчислень НТУУ «КПІ» користувач має можливість:

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

·Створювати прикладні програми з вихідних кодів за допомогою компіляторів, встановлених в системі;

·Використовувати наявні стандартні прикладні програми та бібліотеки;

·Отримувати перелік прикладних програм, компіляторів та бібліотек, встановлених в системі;

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

Сьогодні для користувачів надаються такі програмні засоби, дуже поширені серед наукової спільноти:

- MPI - OpenMPI (бібліотека для паралельного програмування)

Компілятори GCC (C/C++, Fortran-77, Fortran-95, інш.)

Паралельні пакети лінійної алгебри:

Інші пакети:

FFTW - C програма дискретного перетворення Фурє <#"justify">У 2008 р. за кошти Львівської політехніки в рамках програми інформатизації університету для його потреб, а також, враховуючи результати науково-технічної роботи з розробки структури Львівського ресурсно-операційного Grid-центру, була придбана система збереження даних для забезпечення інформаційних, файлових, обчислювальних та інших ресурсів Університету, що являє собою апаратно-програмний комплекс у складі системи збереження даних IBM System Storage DS3400 з підтримкою технології Fibre Channel, серверної системи для забезпечення спільного користування централізованими та розподіленими компютерними та інформаційними ресурсами на базі блейд-шасі ІBM eServer BladeCenter H Chassis та системи резервного копіювання даних на основі бібліотеки на магнітних стрічках IBM System Storage TS3100 Tape Library.

Це програмно-апаратне рішення вибране таким чином, щоб воно могло в перспективі інтегруватися з програмно-апаратною платформою Grid-центру, для якого була запланована система IBM BladeCenter QS21, що складається з 14 обчислювальних блейд-серверів на базі процесорів Cell та одного координуючого вузла.

Система збереження даних для забезпечення інформаційних, файлових, обчислювальних та інших ресурсів Університету укомплектована 4 блейд-серверами типу HS21XM:

Таблиця 9. Конфігурація блейд-сервера типу HS21XM

СкладовіКонфігураціяПроцесорXeon Quad Core E5335 2.0GHz/1333MHz/8MB L2 Оперативна память 3GB(2x512,2x1GB)PC2-5300 CL5 ECC DDR2 Chipkill FBDIMM Memory Kit, 8DIMM розємівМодуль управління cKVM Feature Card (StFF) for IBM BladeCenterПлата Fiber Channel QLogic 4Gb SFF Fibre Channel Expansion Card for IBM eServer BladeCenter Система діагностики (PFA)Жорсткі диски, память, процесор, вентилятори, блоки живлення, система регулювання напругиЖивленняДубльоване через зєднувальну платуШина кард розширенняPCI-X

Таблиця 10. Конфігурація блейд-сервера типу QS21

СкладовіКонфігураціяПроцесор2xCell BE / 3.2GHz Оперативна память2Gb 400 MHz XDRAM(1Gb per CPU)ЖивленняДубльоване через зєднувальну платуШина кард розширенняPCI-X

Ці 5 блейд-серверів, кількість яких в перспективі збільшиться до 14 штук, призначаються як для використання в складі системи збереження даних проектованого Grid-центру в Львівській політехніці, так і для потреб Університету для створення центру збереження даних рівня університету. Центр збереження даних забезпечить консолідовану ІТ-інфраструктуру, що, в свою чергу, дозволить здійснити:

- покращення якості ІТ-сервісів, потрібних для навчання та науки через реорганізацію надання інформаційних, обчислювальних, файлових та інших послуг і сервісів на рівні Університету з використанням методики відсутності єдиної точки відмови на основі використання традиційних відмовостійких схем, що передбачають кластеризацію і резервування пристроїв;

використання концепції серверних обчислень, яка об'єднує управління ресурсами, зменшує витрати і покращує доступ до прикладних задач;

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

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

Запуск даної системи фактично передбачав створення університетської SAN-мережі і визначальним фактором при цьому був вибір платформ, на яких вона буде збудована. Як відомо, система збереження даних DS3400 може підтримувати досить велику кількість серверів, але для цього є необхідне використання SAN-комутатора. На рис. 17 наведений приклад використання системи DS3400 з двома контролерами при підключенні до 4 серверів. Як видно з рис. 17, кожен сервер має 2 Fibre Channels HBA-адаптери для забезпечення функцій надлишковості для забезпечення обміну інформацією.

Було прийняте рішення не закуповувати окремий SAN-комутатор, оскільки існувала можливість використати Nortel Networks SAN-комутатор в складі блейд-шасі ІBM eServer BladeCenter H, який обслуговуватиме доступ до системи збереження даних DS3400. Це дозволило не лише оптимізувати витрати (вартість блейд-шасі в складі з усіма необхідними модулями та комутаторами згідно таблиці 3 є порівнювана з вартістю одного окремого SAN-комутатора), але і добитись рішення, в якому і блейд-сервери, і елементи SAN-мережі є повністю сумісні між собою.

Рис. 17. Приклад використання системи збереження даних ІВМ DS3400 при підключенні до 4 серверів.

Таблиця 11. Конфігурація блейд-шасі ІBM eServer BladeCenter H

СкладовіКонфігураціяШасіІBM eServer BladeCenter(tm) H Chassis або еквівалентВентиляториДубльовані із гарячою заміноюЗєднувальна платаПасивне дублюванняБлоки живлення2 дубльованих блока живлення (загальна к-сть 4) 2900WМодуль комутатори BladeCenter2 х 20 портові Nortel Networks Layer 2/3 Copper GbE Switch Module for BladeCenter або еквівалентFiber Channel комутатори2 x QLogic(R) 4Gb 20-port FC Switch Module for IBM eServer BladeCenter або еквівалентМодуль управлінняДубльований BladeCenter Redundant KVM/Advanced Management Module або еквівалент

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

архітектура протокол грід інтернет

Рис. 18. Схема розгортання комплексу в складі системи збереження даних, блейд-серверів, які забезпечують доступ до неї та SAN-мережі без використання окремого SAN-комутатора

Після запуску цього комплексу разом із системою резервного копіювання даних на основі бібліотеки на магнітних стрічках IBM System Storage TS3100 Tape Library планується перенесення сюди загальноуніверситетських сервісів, в тому числі і обчислювальних, які на даний момент виконуються на серверах типу HP, ІВМ, Intel та SuperMicro.

Рис. 19. Схема зображенням зєднань між блейд-серверами та системою збереження даних

Литература

1.I. Foster, C. Kesselman. The Grid: Blueprint for a New Computing Infrastructure. - Morgan Kaufmann Publishers, 1998.

2.I. Foster, C. Kesselman, S. Tuecke. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. - International J. Supercomputer Applications, 15(3), 2001, <http://www.globus.org/research/papers/anatomy.pdf>

.I. Foster, C. Kesselman, S. Tuecke, J.M. Nick. The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. - Morgan Kaufmann Publishers, 2002.

.I. Foster, H. Kishimoto, A. Savva, D. Berry et al. The Open Grid Services Architecture. - Global Grid Forum, 2005

.А.К. Кирьянов, Ю.Ф. Рябов Введение в технологию Грид // Петербургский институт ядерной физики им. Б.П. Константинова РАН. - 2006. - 39 с.

.Петренко А.І. Національна Grid - інфраструктура для забезпечення наукових досліджень і освіти // Системні дослідження і інформаційні технології. - Київ. - №1 - 2008. - C.79-92.

.M. Z. Zgurovsky. Development of Educational and Research Segment of Information Society in Ukraine. - //Proc. WSIS.-Tunis.- 2004.-P.103-107.

.M. Z. Zgurovsky. Development of Educational and Research Segment of Information Society in Ukraine. - //Системні дослідження та інформаційні технології. - Київ. - 2006. - №1. - С.7-17.

.Petrenko A.I. Development of Grid -infrastructure\for Educational and Research segment of Information Society in Ukraine with focus on Ecological monitoring and Telemedicine. - // Data Science Journal.- Volume 6.- Supplement, 14 April 2007. - P.583-590.

Тема 1. Вступ до розподілених обчислень Питання 1.Загальні питання про розподілені обчислення. 2.Модель розподілених обчислень. .Різниця між лок

Больше работ по теме: