1

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ

УКРАЇНИ

ТЕРНОПІЛЬСЬКИЙ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

ІМЕНІ ІВАНА ПУЛЮЯ

Кафедра: “Комп’ютерні науки”

П О С І Б Н И К

з дисципліни

ТЕХНОЛОГІЇ РОЗПОДІЛЕНИХ СИСТЕМ

ТА ПАРАЛЕЛЬНИХ ОБЧИСЛЕНЬ

для студентів спеціальності7.05010101 – Інформаційні управляючі системи та

технології

ТЕРНОПІЛЬ 2012

2

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ, МОЛОДІ ТА СПОРТУ

УКРАЇНИ

ТЕРНОПІЛЬСЬКИЙ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

імені ІВАНА ПУЛЮЯ

Кафедра: “Комп’ютерні науки”

П О С І Б Н И К

з дисципліни

ТЕХНОЛОГІЇ РОЗПОДІЛЕНИХ СИСТЕМ ТА ПАРАЛЕЛЬНИХ

ОБЧИСЛЕНЬ

для студентів спеціальності7.05010101 – Інформаційні управляючі системи та технології

Розглянуто на засіданні кафедри КН

протокол №2 від 04.09.2012 р.

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

протокол №2 від 27.09.2012 р.

ТЕРНОПІЛЬ 20123

Посібник з дисципліни “Технології розподілених систем та паралельних

обчислень” для студентів спеціальності 7.05010101 – Інформаційні управляючі

системи та технології. / Уклад.: Марценко С.В, Шимчук Г.В. – Тернопіль: ТНТУ

2012 – 258 с.

Посібниу призначений для полегшення засвоєння дисципліни “Технології

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

модульної системи навчання і індивідуальних завдань, тестів, екзаменаційних

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

Укладачі: Марценко С.В., доцент

Шимчук Г.В., асистент

Відпов. за випуск М.В. Приймак, професор

Рецензент М.М. Касянчук, доцент

4

ЗМІСТ

ВСТУП 5

1 GRID-ТЕХНОЛОГІЇ 9

2 ПАРАЛЕЛЬНІ ОБЧИСЛЮВАЛЬНІ МЕТОДИ 136

3 ПАРАЛЕЛЬНЕ ПРОГРАМУВАННЯ 199

ЛІТЕРАТУРА 261

5

ВСТУП

Технологія Grid використовується для створення географічно розподіленої

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

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

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

Термін Grid (сітка, решітка) почав використовуватися з середини 90-х років

і був обраний по аналогії з мережами передачі і розподілу електроенергії (Power

Grids).

Розвиток і впровадження технології Grid носить стратегічний характер. У

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

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

людської діяльності.

Ідейною основою технології Grid є об'єднання ресурсів шляхом створення

комп'ютерної інфраструктури нового типу, що забезпечує глобальну інтеграцію

інформаційних і обчислювальних ресурсів на основі мережевих технологій і

спеціального програмного забезпечення проміжного рівня (між базовим і

прикладним ПО), а також набору стандартизованих служб для забезпечення

надійного сумісного доступу до географічно розподілених інформаційних і

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

інформації і мережам.

Поява технології Grid обумовлена наступними передумовами:

– необхідністю рішення складних наукових, виробничих, інженерних і

бізнес-задач;

– стрімким розвитком мережевого транспортного середовища і

технологій високошвидкісної передачі даних;

– наявністю в багатьох організаціях обчислювальних ресурсів:

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

організованих у вигляді кластерів.

6

Застосування технології Grid може забезпечити новий якісний рівень, а

іноді і реалізувати принципово новий підхід в обробці величезних об'ємів

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

візуалізацію великих наборів даних, складні бізнес-додатки з великими об'ємами

обчислень.

7

1 GRID-ТЕХНОЛОГІЇ

Напрями розвитку технології Grid

До теперішнього часу вже реалізовані і реалізуються безліч проектів по

створенню Grid-систем. Більша частина цих проектів має експериментальний

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

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

– обчислювальний Grid;

– Grid для інтенсивної обробки даних;

– семантичний Grid для операцій з даними з різних баз даних.

Метою першого напряму є досягнення максимальної швидкості обчислень

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

DEISA (www.desia.org) може служити прикладом цього напряму, в якому

робиться спроба об'єднання суперкомп'ютерних центрів.

Метою другого напряму є обробка величезних об'ємів даних відносно

нескладними програмами за принципом «одне завдання – один процесор».

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

складним завданням. Для цього напряму інфраструктура Grid є об'єднанням

кластерів. Один з проектів, метою якого і є створення виробничої Grid-системи

для обробки наукових даних, є проект EGEE (Enabling Grids for E-SCIENCE), який

виконується під егідою Європейського Союзу (www.eu-egee.org). Учасниками

цього проекту є більше 90 наукових і освітніх установ зі всього світу, включаючи

Україну.

Побудова інфраструктури Grid в рамках проекту EGEE орієнтована, в

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

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

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

(CERN, www.cern.ch) прискорювача LHC.

Проект EGEE тісно зв'язаний на даній фазі розвитку з проектом LCG (LHC

8

Computing Grid), який, по суті, і є його технологічною базою.

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

реалізації Grid-систем відрізняються одна від одної, хоча в наш час з достатньою

визначеністю почала спостерігатися тенденція стандартизації більшості

компонентів, що означає найважливіший етап формування технології Grid

(архітектура, протоколи, сервіси та ін.). З найзагальніших позицій ця технологія

характеризується простим набором критеріїв:

– координація використання ресурсів за відсутності централізованого

управління цими ресурсами;

– використання стандартних, відкритих, універсальних протоколів і

інтерфейсів;

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

Концепція побудови GRID

Прогрес в області розробки нових обчислювальних пристроїв і мережевих

технологій вражає. Тільки за останніх 15 років тактова частота персональних

машин зросла з 10 Мгц до 5ГГц (500 разів), а пропускна спроможність мереж з 10

Мбіт/с до 100 Гбіт/с (10000 разів).

Але не за горами деякі принципові обмеження, наприклад, постійна часу

поляризації діелектрика рівна 10 – 13сек, що встановлює верхню межу на тактову

частоту будь – яких операцій на рівні ~1013 Гц. (Тгц).

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

можливостей. Одним з шляхів вирішення проблеми – паралельне виконання

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

технології вже використовуються, наприклад, при побудові Ethernet – интерфейса

для швидкості 10 Гбіт/сек (Fast Ethernet).

Зв'язок між продуктивністю обчислювача і потрібною пропускною

спроможністю каналів обміну встановлює емпіричний закон Amdahl, який

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

відповідати пропускна спроможність вводу/виводу, рівна мегабіту в секунду.

9

У якійсь мірі техніка WWDM (Wide Wavelength Division Multiplexing) може

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

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

понизити вартість виконання обчислювальних операцій.

GRID дозволяє виявити і використовувати вільні обчислювальні ресурси.

Ця система для передачі програм і даних використовує стандартні канали і

протоколи (Ethernet, SDH, АТМ, TCP/IP, MPLS і так далі). Переваги GRID

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

Поки не склалося точне визначення того, що слід вважати за GRID. До цього

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

сегментами (область супер – ЕОМ) і системи об'єднані через Інтернет (слабо

зв'язані GRID). Технологія GRID, вирішуючи свої проблеми, сама стає рушійною

силою при розробці нових мережевих технологій (напр. GRIDFTP і ін.).

Широке впровадження в телекомунікації оптоволокна відкриває додаткові

можливості, у тому числі і для систем GRID. Оскільки для отримання необхідної

смуги пропускної спроможності достатньо 2нм у вікні прозорості волокна,

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

волокна.

При сучасних швидкостях обміну (більше 1 Гбіт/с) транспортний протокол

ТСР (L4) почав обмежувати ефективність обміну. Проблеми виникають при

великій смузі пропускання B і RTT.

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

гарантії якості обслуговування QOS. Це, перш за все, RSVP – TE (IntServ) і MPLS

– TE (DiffServ). Для динамічного формування пріоритетних потоків

привабливіший MPLS – TE (розділення потоків по DSCP) особливо у разі єдиного

сервіс – провайдера. Але при з'єднаннях точка – точка це не істотно.

Техніка гарантії QOS дозволяє розділити інформаційні потоки по

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

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

відсутність сумісної техніки гарантії QOS в LAN і WAN.

10

Для забезпечення QOS може використовуватися протокол IEEE 802.17 (RPR

– Resilient Packet Ring).

Поява протоколу (GMPLS) відкриває додаткові можливості в сфері передачі

програм і даних. Оскільки протокол GMPLS практично працює на рівні L1,

значення RTT виявляється мінімізованим.

За своєю природою GMPLS в деяких випадках має проблеми з підтримкою

динамічної маршрутизації, та і час реконфігурації із-за механічного

перенастроювання дзеркал достатньо великий.

Тут з'єднання відбувається по схемі Е2Е і з цієї причини не виникає

необхідності в буферизації (звідси слідує мінімізація RTT).

Первинна роль архітектури GRID полягає у використанні незадіяних

ресурсів.

SOA (Service Oriented Architecture – архітектура, орієнтована на сервіс) –

хоча GRID може працювати без архітектури, орієнтованої на сервіс, бізнес і

керівники IT служб, повинні зрозуміти, що побудова SOA, украй необхідна і

бажана. Веб – сервіси на основі SOA дозволяють виключити міжпрограмні і

інформаційні обміни – що сприяє раціоналізації операцій, збільшенню

продуктивності, більшої гнучкості і низької вартості обчислень.

Business Process Flow (управління бізнес – процесами) – як тільки

з'являється архітектура, орієнтована на сервіс, підприємство може починати вести

бізнес-процеси прозорим способом, використовуючи існуючі інформаційні

системи.

GRID є технологією забезпечення гнучкого, безпечного і скоординованого

загального доступу до ресурсів. При цьому слово «ресурс» розуміється в дуже

широкому сенсі, тобто ресурсом може бути апаратура (жорсткі диски, процесори),

а також системне і прикладне ПО (бібліотеки, додатки).

У термінології GRID сукупність людей і організацій, що вирішують спільно

те або інше загальне завдання і що надають один одному свої ресурси,

називається віртуальною організацією. Наприклад, віртуальною організацією

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

11

колаборації. Віртуальні організації можуть розрізнятися за складом, масштабом,

часом існування, родом діяльності, цілями, відносинами між учасниками

(довірені/не довірені особи) і так далі. Склад віртуальних організацій може

динамічно мінятися.

Стандартизація Grid

У останні декілька років технологія Grid еволюціонувала від ретельно

конфігурованої інфраструктури, яка підтримувала виконання обмеженого числа

додатків категорії Grant Challenge на високопродуктивній апаратурі, до

динамічного середовища, розвиток якого направляє міжнародне співтовариство.

У міру становлення технології Grid реальністю до процесу її розвитку все більш

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

надійного програмного забезпечення, що підтримує середовища Grid за межами

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

на пов'язані з нею  протоколи і стандарти. Пристосування до архітектури Grid

технології Web-сервисів принесло істотну користь та привело до появи дещо

фрагментованого середовища розробки. Розробники програмного забезпечення і

Grid-сервісів добиваються відповідності угодам і стандартам, широко поширеним

в їх співтоваристві. Проте по різних політичних і технічних причинах є декілька

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

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

забезпечення Grid, оскільки вони не упевнені, що майбутні стандарти

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

стандартизації Grid є Global Grid Forum (GGF www.ggf.org). Крім того, роботи по

стандартизації ведуться в Organization for the Advancement of Structured

Information Standards (OASIS www.oasis.org), World Wide Consortium (W3C

www.w3c.org), Distributed Management Task Force (DMTF www.dmtf.prg), Web

Services Interoperability Organization (WS-I www.ws-i.org), Internet2

(www.internet2.edu) і Liberty Alliance (www.projectliberty.org). Найбільш важливим

стандартом, покликаним визначити загальну, стандартну і відкриту архітектуру

Grid, є стандарт Open Grid Services Architecture (OGSA), що розвивається GGF. У

12

березні 2004 р. була випущена перша версія стандарту (OGSA 1.0), а в червні 2005

р. вийшла друга версія стандарту. OGSA є сервіс-орієнтованою архітектурою, в

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

реалізовуються з використанням Web-сервісів. Стандарт призначається для

визначення всіх основних сервісів, які можуть використовуватися в додатках e-

business або e-science, включаючи управління роботами і ресурсами, комунікації і

безпеку. Робота по специфікації інтерфейсів сервісів, семантики, протоколів і

інших технічних деталей надана різним робочим групам усередині GGF і іншим

організаціям по стандартизації Grid. Перша конкретизація OGSA була здійснена в

документі Open Grid Services Infrastructure (OGSI), випущеному в липні 2003 р.

Цей документ базувався на понятті Grid-сервіса, розширенні Web-сервиса, в

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

OGSI 1.0 визначається набір принципів і розширень для використання WSDL і

XML Schema при організації Web-сервісів з підтримкою стану. Критики OGSI

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

розширенні стандартного WSDL; дуже сильна об'єктна орієнтованість. Це

привело до виникнення руху за визначення альтернативної інфрастуктури Grid,

заснованої на чистих специфікаціях Web-сервісів. 20 січня 2004 р. HP, IBM,

Fujitsu і Globus Alliance оголосили про випуск WS-Resource Framework (WSRF

www.globus.org/wsrf). Цей документ складається з набору специфікацій для

виразу зв'язку між ресурсами, що володіють станами, і Web-сервісами. У

специфікаціях визначаються конкретні формати повідомлень і зв'язані визначення

на XML. Остаточні результати були передані двом новим технічним комітетам

OASIS: WS-Resource Framework (WSRF) TC і WS-Notification (WSN) TC. WSRF

TC відповідає за стандартизацію специфікацій WS-Resource Lifetime

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

Web-сервіси для ліквідації ресурсу); WS-Resource Properties (визначаються

способи запиту і модифікації ресурсів, що описуються XML-документами

Resource Property); WS-ServiceGroup (визначаються способи представлення і

управління колекціями Web-сервісів і/або WS-ресурсами); WS-BaseFaults

13

(визначається базовий XML-тип, використовуваний при обміні повідомленнями в

Web-сервісах для інформування про збої). WSN TC займається стандартизацією

трьох специфікацій, що відносяться до інтерфейсів Web-сервісів: WS-

BaseNotification (асинхронне сповіщення, що включає інтерфейси виробника і

споживача); WS-BrokeredNotificatiion (асинхронне сповіщення); WS-Topics

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

планують Grid-проекты, користуються альтернативними специфікаціями, що

включають Basic Profile (BP1.0) від WS-I, Web Services Grid Application

Framework (WS-GAF, North-East Regional e-Science Centre www.neresc.ac.uk/ws-

gaf) і WS-I+ (Open Middleware Infrastructure Institute www.omii.ac.uk).

Специфікація BP1.0 була опублікована в квітні 2004 р. і містила керівництво по

використанню SOAP. WSDL і UDDI. У WS-GAF пропонується підхід, відмінний

від OGSI, до розширення функціональності Web-сервісів для задоволення потреб

Grid-додатків. У WS-I+ указуються існуючі стандарти, які є потенційно

сумісними із стандартами Grid, що розвиваються. Фактичним стандартом безпеки

в Grid є Grid Security Infrastructure (GSI http://forge.gridforum.org/projects/gsi-wg). У

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

на стандарти GSI. У проектах GridShib (http://grid.ncsa.uiuc.edu/GridShib) і ESP-

GRID (http://e-science.ox.ac.uk/oesc/projects) створені нові механізми і стратегії

розподіленої аутентифікації, що дозволяють віртуальним організаціям в Grid

інтегруватися з традиційною інфраструктурою корпоративної безпеки.

Архітектура Grid

Open Grid Services Architecture (OGSA) направлена на стандартизацію

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

GRID. По суті стандарт OGSA визначає сервіси GRID, їх можливості і те, на яких

технологіях вони засновані. Проте, OGSA не розрізняє особливостей технічної

сторони специфікації; метою є визначення – що є системою GRID. OGSA

називають архітектурою, оскільки вона направлена на побудову і установку

інтерфейсів, з яких можуть бути побудовані, системи, засновані на відкритих

стандартах WSDL.

14

Таблиця 1.1 – Пропонований OGSA інтерфейс служб GRID

Тип порту Операція Опис

GridService FindServiceData Запит різної інформації про сервіси GRID, включаючи основну діагностичну інформацію, інформацію про інтерфейси і про особливості сервісів. Підтримка різних мов запитів

SetTermination Time Установка часу знищення сервісу GRID

Destroy Видалення служби

Notification – Source SubscribeTo –

NotificationTopic

Підписка на повідомлення про події, що відносяться до сервісів, і заснована на типі повідомлення

Notification – Sink Deliver Notification Виконання і асинхронна вставка повідомлення

Registry RegisterService

UnregisterService

Реєстрація додатків GRID. Анулювання реєстрації додатків GRID

Factory CreateService Створення нового сервісу GRID

Handle Map FindByHandle Повернення посилання про службу GRID, що асоціюються з їх дескрипторами

Є два основні критерії, що виділяють GRID – системи серед інших систем,

що забезпечують доступ до ресурсів, що розділяються:

1. GRID – система координує розрізнені ресурси. Ресурси не мають

загального центру управління, а GRID – система займається координацією їх

використання, наприклад, балансуванням навантаження. Тому проста система

управління ресурсами кластера не є системою GRID, оскільки здійснює

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

доступ. GRID – системи мають лише обмежений доступ до ресурсів, залежний від

політики того адміністративного домену (організації-власника), в якому цей

15

ресурс знаходиться.

2. GRID – система будується на базі стандартних і відкритих протоколів,

сервісів і інтерфейсів. Не маючи стандартних протоколів, неможливо легко і

швидко підключати нові ресурси в GRID – систему, розробляти новий вигляд

сервісів і так далі.

Додамо ще декілька властивостей, якими зазвичай володіють GRID –

системи:

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

потенційно до будь-яких видів ресурсів;

– масштабованість: працездатність GRID – системи при значному

збільшенні або зменшенні її складу;

– гнучка і могутня підсистема безпеки: стійкість до атак зловмисників,

забезпечення конфіденційності;

– можливість контролю над ресурсами: застосування локальних і

глобальних політик і квот;

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

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

ресурсами.

Хоча сама технологія GRID не прив'язана до певних ресурсів, найчастіше

реалізації GRID – систем забезпечують роботу з наступними типами ресурсів:

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

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

масового зберігання даних;

– мережеві ресурси;

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

В ідзначимо різницю між технологією GRID і реалізаціями GRID – систем.

Технологія GRID включає лише найбільш загальні і універсальні аспекти,

однакові для будь-якої системи (архітектура, протоколи, інтерфейси, сервіси).

Використовуючи цю технологію і наповнюючи її конкретним змістом, можна

реалізувати ту або іншу GRID – систему, призначену для вирішення того або

16

іншого класу прикладних завдань.

Не слід змішувати технологію GRID з технологією паралельних обчислень.

В рамках конкретної GRID – системи, звичайно, можливо організувати паралельні

обчислення з використанням існуючих технологій (PVM, MPI), оскільки GRID –

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

обчислювальних вузлів. Проте технологія GRID не є технологією паралельних

обчислень, в її завдання входить лише координація використання ресурсів.

Архітектура GRID визначає системні компоненти, цілі і функції цих

компонент і відображає способи взаємодії компонент один з одним. Архітектура

GRID є архітектурою взаємодіючих протоколів, сервісів і інтерфейсів, що

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

з'єднання з GRID – системою, спільно використовують обчислювальні ресурси

для вирішення різного роду завдань. Архітектура протоколів GRID розділена на

рівні (рисунок 1.1), компоненти кожного з них можуть використовувати

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

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

сервісів, прикладних інтерфейсів і засобів розробки ПО), не надаючи строгий

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

концепції.

Інфраструктура GRID заснована на наданні ресурсів в загальне

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

іншого. У цьому плані ключове поняття інфраструктури GRID – віртуальна

організація, в якій кооперуються як споживачі, так і власники ресурсів. Мотиви

кооперації можуть бути різними. У існуючих GRID – системах віртуальна

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

об'єднуються для досягнення загальної мети.

GRID – система є середовищем колективного компьютинга, в якій кожен

ресурс має власника, а доступ до ресурсів відкритий в режимі, що розділяється за

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

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

17

існування.

Ефективний розподіл ресурсів і їх координація є основними завданнями

системи GRID, і для їх вирішення використовується планувальник (брокер

ресурсів). Користуючись інформацією про стан GRID – системи, планувальник

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

резервує їх для її виконання. Під час виконання завдання може запитати у

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

завдання всі відведені для неї обчислювальні ресурси звільняються, а ресурси

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

Важливою властивістю систем GRID є те, що користувачеві не потрібно

знати про фізичне розташування ресурсів, відведених його завданню. Вся робота

по управлінню, перерозподілу і оптимізації використання ресурсів лягає на

планувальник і виконується непомітно для користувача. Для користувача

створюється ілюзія роботи в єдиному інформаційному просторі, що володіє

величезними обчислювальними потужностями і об'ємом пам'яті.

18

GRID є найбільш складним інформаційним середовищем, що коли-небудь

створюється людиною. Для системи такої складності дуже важлива проблема

забезпечення надійного функціонування і відновлення при збоях. Людина не

здатна устежити за станом тисяч різних ресурсів, що входять в GRID – систему, і

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

моніторингу, яка стежить за станом окремих ресурсів. Дані про стан заносяться в

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

іншими сервісами, що дозволяє мати достовірну інформацію, що постійно

оновлюється, про стан ресурсів.

У GRID – системах використовується складна система виявлення і

класифікації помилок. Якщо помилка відбулася з вини завдання, то завдання буде

зупинено, а відповідна діагностика направлена її власникові (користувачеві).

Якщо причиною збою послужив ресурс, то планувальник проведе перерозподіл

ресурсів для даного завдання і перезапустить його.

Збої ресурсів є не єдиною причиною відмов в GRID – системах. Через

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

важливо своєчасно визначати переобтяжені і вільні ресурси, проводячи

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

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

використовуючи систему моніторингу, постійно стежить за станом ресурсів і

автоматично приймає необхідні заходи для запобігання перевантаженням і

простою ресурсів.

У розподіленому середовищі, яким є GRID – система, життєво важливою

властивістю є відсутність так званої єдиної точки збоїв. Це означає, що відмова

будь-якого ресурсу не повинна приводити до збою в роботі всієї системи. Саме

тому планувальник, система моніторингу і інші сервіси GRID – системи

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

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

У GRID – системах використовуються сучасні технології передачі даних,

забезпечення безпеки і відмовостійкої.

19

Базовий рівень

Базовий рівень (Fabric Layer) архітектури GRID описує служби, що

безпосередньо працюють з ресурсами. Ресурс є одним з основних понять

архітектури GRID. Ресурси можуть бути вельми різноманітними, проте, як вже

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

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

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

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

– мережеві ресурси.

Обчислювальні ресурси надають користувачеві GRID – системи (точніше

кажучи, завданню користувача) процесорні потужності. Обчислювальними

ресурсами можуть бути як кластери, так і окремі робочі станції. При всій

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

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

Необхідною умовою для цього є наявність спеціального програмного

забезпечення, званого ПЗ проміжного рівня (middleware), що реалізує

стандартний зовнішній інтерфейс з ресурсом і дозволяє зробити ресурс

доступним для GRID – системи. Основною характеристикою обчислювального

ресурсу є продуктивність.

Ресурси пам'яті є простором для зберігання даних. Для доступу до ресурсів

пам'яті також використовується програмне забезпечення проміжного рівня, що

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

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

20

ІнформаційніІнформаційні ресурсиресурси

ІнформаційніІнформаційні ресурсиресурси

Рисунок 1.2 – Ресурси GRID

Ресурси памРесурси пам''ятіятіРесурси памРесурси пам''ятіятіОбчислювальні Обчислювальні ресурсиресурси

Обчислювальні Обчислювальні ресурсиресурси

Мережеві ресурсиМережеві ресурсиМережеві ресурсиМережеві ресурси

GRID – системи, будь то жорсткий диск на робочій станції або система масового

зберігання даних на сотні терабайт. Основною характеристикою ресурсу пам'яті є

його об'єм.

Інформаційні ресурси і каталоги є особливим видом ресурсів пам'яті. Вони

служать для зберігання і надання метаданих і інформації про інші ресурси GRID –

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

об'єм інформації про поточний стан GRID – системи і ефективно виконувати

завдання пошуку.

Мережевий ресурс є сполучною ланкою між розподіленими ресурсами

GRID – системи. Основною характеристикою мережевого ресурсу є швидкість

передачі даних. Географічно розподілені системи на основі даної технології здатні

об'єднувати тисячі ресурсів різного типу, незалежно від їх географічного

положення.

Рівень зв'язку

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

протоколи аутентифікації.

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

базового рівня.

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

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

користувачів і ресурсів.

Протоколи рівня зв'язку повинні забезпечувати надійний транспорт і

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

дивлячись на існуючі альтернативи, зараз протоколи рівня зв'язку в GRID –

системах припускають використання тільки стека протоколів TCP/IP, зокрема: на

мережевому рівні – IP і ICMP, транспортному рівні – TCP, UDP, на прикладному

рівні – HTTP, FTP, DNS, RSVP. Враховуючи бурхливий розвиток мережевих

технологій, в майбутньому рівень зв'язку, можливо, залежатиме і від інших

протоколів.

Для забезпечення надійного транспорту повідомлень в GRID – системі

21

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

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

має рацію, підтримка надійних транспортних протоколів). В даний час ці рішення

ґрунтуються як на існуючих стандартах безпеки, спочатку розроблених для

Інтернет (SSL, TLS), так і на нових розробках.

Ресурсний рівень

Ресурсний рівень (Resource Layer) побудований над протоколами

комунікації і аутентифікації рівня зв'язку архітектури GRID. Ресурсний рівень

реалізує протоколи, що забезпечують виконання наступних функцій:

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

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

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

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

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

Протоколи цього рівня спираються на функції базового рівня для доступу і

контролю над локальними ресурсами. На ресурсному рівні протоколи

взаємодіють з ресурсами, використовуючи уніфікований інтерфейс і не

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

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

1. інформаційні протоколи, які отримують інформацію про структуру і

стан ресурсу, наприклад, про його конфігурацію, поточне завантаження, політику

використання;

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

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

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

доступ до даних). Протоколи управління повинні перевіряти відповідність

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

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

операціями.

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

22

до списку для базового рівня архітектури GRID. Додалася лише вимога єдиної

семантики для різних операцій з підтримкою системи оповіщення про помилки.

Колективний рівень

Колективний рівень (Collective Layer) відповідає за глобальну інтеграцію

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

з окремо узятими ресурсами. У колективному рівні розрізняють загальні і

специфічні (для додатків) протоколи. До загальних протоколів відносяться, в

першу чергу, протоколи виявлення і виділення ресурсів, системи моніторингу і

авторизації співтовариств. Специфічні протоколи створюються для різних

додатків GRID (наприклад, протокол архівації розподілених даних або протоколи

управління завданнями збереження стану і тому подібне).

Компоненти колективного рівня пропонують величезну різноманітність

методів сумісного використання ресурсів. Нижче приведені функції і сервіси, що

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

– сервіси каталогів дозволяють віртуальним організаціям виявляти

вільні ресурси, виконувати запити по іменах і атрибутах ресурсів, таким як тип і

завантаження;

– сервіси сумісного виділення, планування і розподілу ресурсів

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

планування виконуваних на ресурсах завдань;

– сервіси моніторингу і діагностики відстежують аварії, атаки і

перевантаження;

– сервіси дублювання (реплікації) даних координують використання

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

швидкості доступу до даним відповідно до вибраних метрик, таких як час

відповіді, надійність, вартість і т.п.;

– сервіси управління робочим завантаженням застосовуються для опису

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

– служби авторизації співтовариств сприяють поліпшенню правил

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

23

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

політики доступу на основі інформації про ресурси, протоколи управління

ресурсами і протоколи безпеки зв’язуючого рівня;

– служби обліку і оплати забезпечують збір інформації про

використання ресурсів для контролю звернень користувачів;

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

великому співтоваристві користувачів.

Прикладний рівень

Прикладний рівень (Application Layer) описує призначені для користувача

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

Додатки функціонують, використовуючи сервіси, визначені на рівнях, що

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

доступ до необхідних служб, а також прикладні програмні інтерфейси

(Application Programming Interface – API), відповідні даним протоколам.

Для полегшення роботи з прикладними програмними інтерфейсами

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

програмного забезпечення (Software Development Kit – SDK). Набори

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

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

протоколів з додатковими викликами прикладних програмних інтерфейсів

нижнього рівня.

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

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

протоколи, сервіси і прикладні програмні інтерфейси, проте подібні надбудови не

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

GRID – систем.

Грід-сервіси та їх специфіка

Грід як шлях до Веб нового покоління

Веб-технології відіграли суттєву роль у справі вільного доступу та

24

спільного використання інтернет-ресурсів. Чергового прориву на цьому шляху,

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

Вони обіцяють забезпечити зв’язність ресурсів, їх функціональну сумісність на

принципово новому рівні, незважаючи на географічні обмеження чи

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

агрегування географічно розподілених, автономних ресурсів залежно від їх

доступності, потужності, вартості, адміністративних політик, вимог користувачів

до якості обслуговування та надійності тощо. Таким чином, Веб може

розглядатися як “інформаційний грід”, а Грід – як “розширений веб”, що позначає

те, що Грід йде далі суто інформаційного обміну, надаючи можливість спільного

використання комп’ютерних ресурсів (ЦП, пам’ять, сховища, мережі, програми,

високоточне обладнання тощо), а не лише інформації. Серед додаткових

можливостей, які Грід може потенційно запропонувати порівняно з Веб, можна

вказати хоча б такі [7]: автоматичне динамічне оновлення та розширення,

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

синтез знань, автоматичне рішення питань сумісності. Однак, претендуючи на

місце у майбутньому Веб, Грід має бути узгоджений з веб-технологіями не лише з

концептуального боку, а й з технічного.

Грід-сервіси та їх особливості

Розглядаючи грід-систему у статиці, можна представити Грід як множину

компонентів – користувачів, апаратних ресурсів, програм, служб. Основу частину

компонентів Грід складають грід-ресурси. Під ресурсом можна розуміти будь-

який реальний чи уявний об’єкт, до якого потрібно надати доступ іншим

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

ресурсів: фізичні (обчислювальні ресурси, сховища, мережі, периферія), та логічні

(дані, знання, прикладні програми). Таке представлення Грід як взаємопов’язаної

множини ресурсів відоме як “ресурсно-орієнтоване”. В той же час, ресурси та

користувачі Грід перебувають у постійній взаємодії: вони взаємодіють між собою,

надсилаючи чи отримуючи запити та відповіді на них, при цьому діючи як

незалежні агенти. З такою динамічною поведінкою грід-систем добре

25

узгоджується “сервісно-орієнтований” підхід, базовим поняттям якого є сервіс.

Під сервісом можна розуміти деякий програмний модуль із визначеною

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

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

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

сервісно-орієнтованої архітектури (SOA) виділяють наступні: максимальне

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

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

моніторингу сервісів. Ці загальні принципи згодом конкретизувалися [8] у

наступний перелік:

1. Стандартизований контракт. Інтерфейс взаємодії сервісів описується

документально.

2. Слабка зв’язність. Взаємозв’язки між сервісами мають бути такими,

що мінімізують взаємозалежності.

3. Абстрагування сервісів. Внутрішня логіка сервісу має бути прихована

від зовнішнього світу, який обізнаний лише з його контрактом.

4. Повторне використання. Логіка розбивається на сервіси з думкою про

вигоду повторного використання.

5. Автономність сервісів. Сервіси контролюють логіку, яку вони

інкапсулюють.

6. Відсутність внутрішнього стану. Задля мінімізації використання

ресурсів та кращої масштабованості сервіси не повинні зберігати свій стан між

викликами.

7. Автоматизоване виявлення. Сервіси супроводжуються метаданими,

що уможливлюють їх автоматизоване виявлення та ідентифікацію.

8. Здатність до компонування. Сервіси мають бути добре придатними

для поєднання, незалежно від складності композиціювання.

Зважаючи на ці особливості та відштовхуючись від сервісно-орієнтованого

підходу, підходящою абстракцією для одиниці функціональності Грід є грід-

сервіс: спеціалізована автономна служба, що є базовою складовою частиною

26

середовища зі слабкими зв’язками між компонентами, яким є Грід. Наприклад,

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

сховищ, грід-сервіси для рішення складних обчислювальних задач

використовують обчислювальні грід-ресурси тощо. Надалі будемо спиратися на

саме таке загальне трактування грід-сервісу як самостійної функціональної

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

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

визначення грід-сервісу як веб-сервісу, що надає набір визначених інтерфейсів та

слідує певним домовленостям, визначеним у “Відкритій архітектурі грід-сервісів”

(OGSA) [9]. Для того, щоб розрізняти ці поняття, реалізацію грід-сервісів за

OGSA будемо іменувати OGSA-сервісами. Виділяють також базові грід-сервіси,

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

передача даних, моніторинг та ін.), та прикладні, додаткові, спеціалізовані грід-

сервіси, що надають додаткову функціональність (напр., вирішуючи

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

астрономія, біомедицина, фізика тощо) та можуть використовувати у своїй роботі

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

вирішення задач, грід-порталів). Щоправда, реалії Грід вносять деякі уточнення у

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

сервісів порівняно з принципами SOA варто виділити такі [9]:

1. Тривалий час існування та складний життевий цикл. Грід-сервіси,

зазвичай, мають складнішу логіку, ніж просто “запит-відповідь”. Тому грід-

сервіси можуть існувати довше, аніж від моменту надходження запиту до сервісу

до надсилання сервісом відповіді.

2. Підтримка внутрішнього стану. Грід-сервіси можуть слугувати для

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

програми тощо. В цьому випадку, грід-сервіс має змінювати стан об’єктів, за які

він відповідає, у відповідь на вхідні запити. Якщо ж кожному з таких об’єктів

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

змінювати свій стан та зберігати його протягом всього часу існування зв’язаного з

27

ним об’єкту. Цей пункт явно суперечить пункту 6 викладених вище принципів

SOA.

3. Оповіщення. Грід-сервіси мають підтримувати механізм оповіщень, за

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

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

4. Узгодженість із інфраструктурою безпеки Грід (GSI).

Життєвий цикл грід-сервісів

Вищевикладені пункти потребують деяких уточнень. Наведемо кілька

прикладів. Так, якщо сервіс слугує для надання синхронних відповідей на запити

типу “надати перелік доступних грід-вузлів”, то йому не потрібно підтримувати

механізм оповіщень, існувати постійно між вхідними запитами, підтримувати свій

внутрішній стан. Все, що має виконувати такий сервіс – зчитати збережений на

поточний момент перелік грід-вузлів з бази даних і передати цю інформацію

клієнту. Однак, якщо сервіс слугує для управління конкретною грід-задачею (сама

задача представлена як окремий сервіс), то цей сервіс зобов’язаний існувати так

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

або опитувати поточний внутрішній стан сервісу. Таким чином, грід-сервіси як

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

поведінки чи особливості життєвого циклу. Ці обмеження вводяться на етапі

конкретизації грід-системи у певну архітектурну модель. Так, архітектура OGSA,

що успішно реалізована в таких пакетах програмного забезпечення проміжного

шару Грід, як Globus Tooklit 4 [10] чи UNICORE [11], зобов’язує грід-сервіс

дотримуватись вимог 1-4. Будь-яке інше конкретне архітектурне рішення може

відходити від цих вимог, і, можливо, лишатись при цьому життєздатним. Дане

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

урахуванням можливості забезпечення вимог 1-4, при цьому не орієнтуючись

виключно на архітектуру OGSA та сумісність з нею.

Веб-сервіси: перевірене рішення для SOA

На сьогодні найбільш популярною технологією, яка реалізує принципи SOA

є веб-сервіси. Часто ці терміни навіть помилково сприймають як синоніми. Веб-

28

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

незалежно від їх географічної рознесеності чи технологічної (апаратної,

програмної) гетерогенності. Веб-сервіси як платформа для організації

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

сервісів B2B, e-Science, e-Government. Їх застосування сприяє впровадженню

міжмашинної взаємодії, зменшуючи обсяги ручної, неавтоматизованої роботи

користувачів. Будучи добре стандартизованими, веб-сервіси спрощують задачу

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

постачальників. Цю задачу значно полегшує і той факт, що веб-сервіси є

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

веб-сервісів, таких як XML, WSDL, SOAP та UDDI, дозволяє на практиці

реалізувати принципи SOA на рівні “будь-що є сервісом”. Очевидним є бажання

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

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

Таблиця 1.2 – Спільні та відмінні риси грід- та веб-сервісів

Веб-сервіси Грід-сервіси

Спільні

принципи

Модульність, слабка зв’язність,

прагнення до повторного

використання, абстрагування,

здатність до поєднання, моніторинг,

категоризація

Життєвий

цикл

Від запита до відповіді, збереження

даних у БДМ

Існування між запитами,

впродовж часу

існування грід-ресурсу

Внутрішній

стан

Відсутність спеціальної підтримки як

ідеологічно, так і в стандартах

Має підтримуватись

через особливості грід-

ресусрів

29

Продовження таблиці 1.2

Оповіщення

Прийнято додаткові

стандарти WS-

Notification

Мають підтримуватись через

специфіку роботи Грід.

БезпекаСтандарти WS-

SecurityПідтримка GSIМ

СтандартизаціяВизначені, зрілі

стандарти

Наявність різних реалізацій

проміжного програмного забезпечення

грід не сприяє стандартизації

Грід-сервіси та веб-сервіси: можливість інтеграції

До цього моменту було показано, веб-сервіси та грід-сервіси ідеологічно

мають і багато спільного, і декотрі відмінності. Уточнимо їх (таблиці 1.2). Ці

відмінності традиційно виділяються теоретиками Грід (в основному, учасниками

Global/Open Grid Forum) як важливі передумови для введення доповнень у

стандарти веб-сервісів. Чи є ці зміни необхідними та принципово неминучими,

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

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

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

оскільки веб-сервіси не у всьому сумісні з архітектурою грід [9], то мова може

йти про компромісне змішане “Грід-Веб-рішення”. Вже згадані OGSA-сервіси

були першою спробою поєднати грід- та веб-сервіси на рівні, близькому до

стандартів. OGSA не лише визначила семантику грід-сервісу, а й вказала

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

існувати тривалий час та підтримували внутрішній стан. Як результат, була

розроблена специфікація OGSI (Open Grid Services Infrastructure) [12], яка,

реалізуючи принципи OGSA, визначала грід-сервіс як веб-сервіс, що відповідає

певним домовленостям по інтерфейсам та поведінці. Було визначено, як саме

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

30

циклом, отримання оповіщень, обробки помилок. Ці визначені специфікацією

домовленості надавали можливість надійного, безпечного, відмовостійкого

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

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

набула популярності у веб-спільноти. На зміну їй було розроблено сімейство

стандартів WSRF (Web Service Resource Framework) [13], вже таки затверджене

OASIS. WSRF зосереджується на створенні, адресації, управлінню життевим

циклом ресурсів, що мають внутрішній стан. Була проведена межа між веб-

сервісом та ресурсом, та вказані шляхи, за допомогою яких клієнт міг звертатися

до конкретного ресурсу. У роботі [7] робиться спроба виділити два ортогональні

методи інтеграції веб- та грід-сервісів: грід-орієнтовані веб-сервіси та веб-

орієнтовані грід-сервіси. Перший підхід полягає у тому, що веб-сервіси

набувають деякої грід-специфічної функціональності, тобто “наслідуюються” від

грід-сервісів, якщо користуватися об’єктно-орієнтованою термінологією. Другий

підхід полягає у тому, що грід-сервіси використовують веб-сервіси як

комунікатори, як “базовий клас” для наслідування, таким чином грід-сервіси

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

Однак ми будемо дотримуватись дещо іншої класифікації, а саме: грід-

сервіси, що адаптовані під стандарти Веб та веб-сервіси, адаптовані під вимоги

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

сервісами. Перший підхід полягає у адаптації архітектури грід-сервісів під

існуючі стандарти веб-сервісів, другий – у розширенні стандартів веб-сервісів для

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

розширення WSRF). Загальні наслідки від застосування обох підходів для грід- та

веб-спільноти окреслено в таблиці 1.3.

31

Таблиця 1.3 –. Можливі шляхи узгодження грід та веб-сервісів

Наслідки

для...

Адаптація Грід під стандарти

веб-сервісів

Адаптація Веб під вимоги грід-

сервісів

Грід

архітектура грід-сервісів

віддаляється від концепції

“ресурс-як-сервіс”

можливо реалізувати складну

поведінку грід-сервісів,

відповідну до життєвого циклу

грід-ресурсів

Веб

грід-сервіси автоматично

сумісні з існуючими веб-

сервісами, адаптувати

численний WS-інструментарій

не потрібно

існуючі веб-рішення можуть

мати проблеми із сумісністю з

грід-сервісами, якщо не будуть

підтримувати усіх нововведень.

Як видно, кожен з підходів має свої недоліки: потрібно або переглядати

архітектуру грід так, щоб вона була придатна до реалізації на “чистих” веб-

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

доповнення до веб-сервісів та ризикувати не дочекатися їх затвердження (у

випадку з OGSI) чи прийняття та просування веб-спільнотою. Тепер розглянемо

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

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

сервісів: SOAP, WSDL, UDDI, стандарти WS-*. Другий підхід краще дослідити на

прикладах еволюції специфікацій OGSA-OGSI-WSRF.

Веб-сервіси як спосіб реалізації грід-сервісів

Базові елементи технології веб-сервісів

Архітектура веб-сервісів базується на трьох основних елементах [14]:

SOAP (Simple Object Access Protocol, простий протокол доступу до

об’єктів) як протокол обміну XML-повідомленнями,

32

WSDL (Web Service Description Language, мова опису веб-сервісів) як

стандартна мова опису контрактів сервісів,

UDDI (Universal Description Discovery & Integration, універсальний

опис, виявлення, інтеграція) як стандартний механізм для пошуку сервісів.

Переваги веб-сервісів, що зробили їх популярними, наступні: незалежність від

мови програмування та платформи, та використання мови XML, для якої існує

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

взаємодія клієнта з веб-сервісом. Головні актори у взаємодії:

програмний клієнт (не сам користувач, а програма, в т.ч. – інший веб-

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

реєстр сервісів (UDDI-сховище описів веб-сервісів, в якому

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

та використання клієнтами);

сам веб-сервіс (програма, що здатна обмінюватись повідомленнями по

протоколу SOAP відповідно до WSDL-контракту, постачальник веб-сервісу

відповідальний за публікацію його опису у UDDI та забезпечення його

доступності).

Наступна схема (рисунок 1.3) ілюструє порядок взаємодії з веб-сервісом.

Постачальник веб-сервісу може не публікувати його метадані у реєстрі, не

створювати WSDL-опису. Таке спрощене рішення залишиться дієвим у невеликих

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

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

слід опублікувати його опис, бажано – у стандартному сховищі.

33

Рисунок 1.3 – Взаємодія з веб-сервісом: обробка повідомлень

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

порядок взаємодії з ним, опитавши реєстр. Стандартний UDDI-сервіс реєстру

покликаний допомогти в автоматизації процесу пошуку сервісів. Однак

допустимим є публікація контракту веб-сервісу і у інші способи – головне, щоб

цільові клієнти могли ознайомитись із цим контрактом стосовно інтерфейсу

взаємодії із сервісом. Отримавши з реєстру (чи будь-де інде) WSDL-опис веб-

сервісу, клієнт може з нього дізнатись, де і як звернутися до сервісу. WSDL є

мовою опису інтерфейсів для веб-сервісів. За цим етапом вже слідує

безпосередньо етап взаємодії. Клієнт надсилає веб-сервісу дані, загорнуті у

SOAP-повідомлення. Зазвичай передача йде по протоколу HTTP. Веб-сервіс

розгорнутий на веб-сервері, зі встановленим SOAP-процесором, який дозволяє

“розпакувати” дані з XML-повідомлення. Після виконання корисних дій, веб-

сервіс повертає клієнту відповідь, загортаючи її назад у HTTP-SOAP-

повідомлення. Слід відзначити, втім, що SOAP може використовуватись з будь-

яким протоколом прикладного рівня: SMTP, FTP, HTTP та інш. Проте, найчастіше 34

SOAP використовується разом з HTTP. Перш ніж перейти до розгляду окремих

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

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

встановити контейнер: зв’язку “веб-сервер програм (Application Server) + SOAP-

процесор (SOAP engine)” (детальніше про SOAP – див. далі). Допустимі два

шляхи: намагатися не залежати від конкретної реалізації контейнера,

використовуючи готові відкриті продукти, чи розробити власне спеціалізоване

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

кола розробників, що може бути занадто обтяжливо, як показав приклад пакету

проміжного програмного забезпечення Globus Toolkit 4. Розробники GT4

створили власний контейнер “Java WS Core” на базі Axis 1.x як середовище

функціонування WSRF-сервісів (рисунок 1.4). Втім, після досвіду 5 років

використання та підтримки було прийнято рішення про припинення розвитку WS-

core, оскільки за цей час технології еволюціонували, бібліотеки Axis 1.x та

PureTLS застаріли. Це поставило під питання майбутнє WSRF-архітектури

базових сервісів Грід, від якої (можливо, тимчасово) відійшли її ж творці у

наступній 5-ій версії GT. Цей приклад доводить, що при виборі технічних засобів

слід враховувати, наскільки широке коло їх користувачів, стабільність розвитку,

підтримку, перспективи, мінливість тих чи інших стандартів, на яких вони

базуються.

Рисунок 1.4 – SOAP-контейнер GT4 [10]

35

SOAP

SOAP – це протокол обміну XML-повідомленнями. Встановлюючи правила

на структуру повідомлень, придатні і для односторонньої комунікації, SOAP

особливо корисний при клієнт-серверній взаємодії у RPC-стилі (запит-відповідь).

Одною з вагомих переваг протоколу SOAP над, скажімо, CORBA, є те, що

постачальник сервісу не зобов’язаний надавати скомпільовані клієнтські

“заглушки” для усіх типів клієнтів (SOAP взагалі не прив’язаний до платформи чи

мови програмування). По-друге, протокол SOAP є більш дружнім до файрволів.

Однак ці переваги досягаються за рахунок меншої продуктивності, спричиненої

витратами на обробку XML-повідомлень.

SOAP-повідомлення є синтаксично коректними (англ. well formed) XML-

документами. Структурними елементами є пролог (необов’язковий елемент) з

XML-декларацією та SOAP-конверт (пакунок, envelope) – кореневий елемент,

який містить елементи заголовку (необов’язковий) та тіла повідомлення [14]:

XML Declaration (optional).

SOAP Envelope (the root element.

SOAP Header (optional.

SOAP Body.

Характерними є дві речі: відносно велика частка службових символів

(корисна інформація, фактично, полягає у назві методу, типу параметру та його

значенні – див. Приклад), та використання просторів імен (namespaces).

Використання просторів імен, визначених у XML-схемах, дає, між іншим,

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

схемам. Це, звичайно, знизить швидкість обробки. Тобто, протокол SOAP, з

одного боку, – простий та незалежний від ОС чи мови програмування, що є

перевагою у випадку грід-середовищ. Він добре підходить під модель “запит-

відповідь”, допускає механізми автоматизованої перевіки повідомлень на їх

відповідність встановленим зразкам, в наявності є автоматизовані засоби для

розробників програмного забезпечення (в т.ч. грід-сервісів).

36

Лістинг 1.1 – Простий приклад повідомлення-запиту для методу “піднести

ціле число у квадрат” матиме вигляд.

Однак, для викорстання у Грід може знадобитися додатковий захист –

шифрування самого вмісту XML-повідомлень. Слід також відзначити чималі

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

інших протоколів типу CORBA. Це слід враховувати при розробці грід-сервісів,

які інтенсивно обмінюються значними об’ємами даних.

WSDL-опис

Згідно підходу SOA інтерфейси сервісів мають бути чітко описані та

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

поєднуватись сервіси різних розробників. WSDL-документ – це контракт веб-

сервісів, мова WSDL – це мова опису інтерфейсів веб-сервісів [14]. WSDL-опис є

також XML-документом, що зручно з точки зору наявних засобів розбору для

різних мов програмування. Існує дві специфікації WSDL – перевірена часом і досі

популярна 1.1, та офіційно рекомендована W3C у 2007 р. нова версія 2.0.

Розглянемо деякі особливості мови WSDL на прикладі версії 2.0, маючи на увазі

деякі відмінності між версіями, показані на рисунку 2.3. Опис веб-сервісу можна

37

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

допомогою системи типів (зазвичай з використанням XML-схеми), поняттями

повідомлень, які сервіс приймає та відправляє. Шаблони обміну повідомленнями

визначають послідовність та кількість повідомлень. Елемент operation зв’язує

шаблони обміну повідомленнями з одним або кількома повідомленнями. Елемент

interface групує операції (елементи operation) незалежно від протоколу передачі

даних. У конкретній частині опису елементи binding задають транспорт та формат

доставки для інтерфейсів (елементів interface). Елемент servcie endpoint пов’язує

мережеву адресу із елементом binding. Нарешті, елемент service групує елементи

endpoint, що реалізують загальний інтерфейс.

Рисунок 1.5 – Відмінності у термінології WSDL 1.1 та 2.0

38

Лістинг 1.2 – Задання параметрів

Ще раз підкреслимо значимість WSDL-контракту для побудови архітектури

на веб-сервісах (і грід-сервісах): опис інтерфейсу сприяє автоматизації при

взаємодії з веб-сервісом не лише людини, розробника програмного забезпечення,

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

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

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

повідомленнями є синхронними. Асинхронні ж оповіщення не входять до

стандарту WSDL 2.0. Також WSDL 2.0 все ще бракує семантики, що може бути

виправлене за рахунок додаткових анотацій.

UDDI

UDDI (Universal Description, Discovery and Integration) надає відносно

незалежний механізм для публікації та пошуку описів сервісів. Він підтримує

різні типи описів сервісів, включаючи WSDL-документи, стандартні Java-

інтерфейси чи інші XML-документи. У специфікації визначається API реєстру,

причому інтерфейс призначений виконувати дві важливі задачі: реєструвати

бізнес та його сервіси, і шукати зареєстровані сервіси та прив’язуватись до них.

Тобто вузол UDDI-реєстру слугує як провайдер сервісу (публікуючи сервіси), як

реєстр сервісів (надаючи можливість проглядати каталог веб-сервісів), та

запитувач сервісів (шукаючи запитаний сервіс та прив’язуючи клієнта до нього). І

реєстрація, і опитування здійснюються через визначені UDDI-команди, які

передаються через SOAP[14]. UDDI насправді представляє собою веб-сервіси, що

дозволяють клієнтам реєструвати інтерфейс на вузлі, проглядати, перевіряти,

прив’язуватись до зареєстрованих сервісів. Для доступу до цих сервісів UDDI

клієнт надсилає SOAP-повідомлення у термінах UDDI-схеми. На рис. показана

39

базова архітектура UDDI-реєстру стосовно запитів. SOAP-запит надсилається до

серверу та десеріалізується SOAP-процесором на UDDI-вузлі. Далі виконуються

UDDI-запити до реєстру, що перетворюються на запити до бази даних. Відповідь

зворотнім порядком через SOAP-процесор для серіалізації та веб-сервер

доставляється клієнту (рисунку 1.6).

Рисунок 1.6 – Спрощена схема архітектури UDDI-реєстру

Тобто використання UDDI передбачає обмін SOAP-повідомленнями.

Можливе створення власних приватних реєстрів для корпоративного інтранету

або B2B-мережі. Публічні реєстри різного часу створювались на ibm.com,

microsoft.com, sap.com, uddi.org, xmethods.com. Згодом, компанії зосередились на

приватних реєстрах, використовуючи UDDI як стандартний механізм реєстрації

та пошуку корпоративних сервісів у внутрішній мережі або для представлення

своїх сервісів бізнес-партнерам. Реєстри UDDI зберігають інформацію про

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

модель даних та API які дозволяють публікацію такої інформації та її опитування.

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

інформація різних типів проіндексована та представлена відповідним чином.

Конкретніше говорять, що UDDI підтримує три типи даних реєстру: «білі

40

сторінки» (довідник бізнес-учасників за іменем), «жовті сторінки» (бізнес за

категорією) та «зелені сторінки» (бізнес за сервісами):

Білі сторінки – функції UDDI як білих сторінок дозволяють шукати

бізнес по імені або якомусь іншому унікальному ідентифікатору типу DUNS чи

Thomas Register. Ця інформація доступна через елемент businessEntity.

Жовті сторінки – бізнес по категоріям. UDDI також підтримує

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

інформація також пов’язана з елементом businessEntity.

Зелені сторінки – умовно позначають можливість UDDI реєструвати

бізнес та проглядати зареєстровані записи по типам сервісів та можливостям, які

вони надають. Ці можливості надаються елементами businessService та

bindingTemplate.

Тобто загалом, UDDI дозволяє реєстрацію та пошук за такими критеріями:

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

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

(рисунок 2.5). Уся інформація в реєстрі зберігається у вигляді взаємопов’язаних

екземплярів кількох типів структур даних [15]:

businessEntity (інформація про організацію-постачальник сервісу)

businessService (опис функціональності сервісу)

bindingTemplate (технічні тедалі сервісу)

tModel (атрибути чи метадані про сервіс, такі як таксономії,

транспорт, цифрові підписи тощо)

publisherAssertions (відношення між сутностями в реєстрі)

subscription (запит на внесення змін до списку сутностей)

Кожна структура даних в реєстрі має унікальний ключ – UUID (Universally

Unique ID). Що важливо, реєстр дозволяє побудову різних таксономій для

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

41

Рисунок 1.7 – Структури даних реєстру та приклад їх заповнення

UDDI надає можливість реєструвати чи отримувати на запит WSDL-

документ певного сервісу. Оскільки як UDDI, так і WSDL описують деталі

сервісу (у власний спосіб), між ними є певний зв’язок. Використання гнучкості

моделі даних UDDI та взаємовідповідностей між UDDI та WSDL дозволяє:

автоматичну реєстрацію сервісів із їх WSDL-описами у реєстрі та

автоматичне створення гнучких запитів до UDDI на основі знань з

WSDL-опису. Таблиця відповідності елементів WSDL та UDDI наведена нижче.

42

Таблиця 1.4 – Відповідність елементів WSDL та UDDI (варіант)

WSDL UDDI

інтерфейси

(portType/interfacetModel

portType/interface tModel

локальна назва portType tModelName

місцезнаходження WSDL overviewURL

прив`язка (binding) tModel

Binding tModel

binding Namespace keyedReference у categoryBag

локальна назва binding tModelName

portType на який

посилається bindingkeyedReference уcategoryBag

протокол keyedReference у categoryBag

Транспорт keyedReference у categoryBag

сервіс (service) businessService

Service businessService

service Namespace keyedReference у categoryBag

локальна назва service keyedReference у categoryBag

посилання (port/endpoint) bindingTemplate

Port bindingTemplate

port Namespace keyedReference, що міститься в businessService

локальна назва portInstanceParms у tModelInstanceInfo, що

відносяться до tModel прив’язки

binding, вказаний у porttModelInstanceInfo із tModelKey для tModel, що

відноситься до binding

portType, вказаний у porttModelInstanceInfo із tModelKey для tModel, що

відноситься до portType

43

Таблиця 1.5 – Відповідність елементів BPEL та UDDI (варіант)

WSDL UDDI

Process tModel

process NamespacekeyedReference у

categoryBag

локальна назва of process tModelName

місцезнаходження BPEL-документа з описом

процесуoverviewURL

WSDL portTypes portType tModels

Port bindingTemplate

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

виконання цілих маршрутів веб-сервісів, описаних мовою BPEL (детальніше –

див. у наступних розділах), можливо використати наступні відповідності для

відображення BPEL у UDDI (таблиця 1.5). Структури даних UDDI, зокрема,

tModel, як вже зазначалося, можуть слугувати для додання семантики в реєстр.

Так, можна створити (використати) онтологію веб-сервісів, та прив’язати її

елементи до структур UDDI, причому за відсутності відповідників

використовуються нові елементи tModel. Таким чином існує можливість

створення модулів семантичного пошуку сервісів. У [16] пропонується підхід,

який полягає у розширенні структури даних UDDI businessService додатковим

елементом serviceProfile, який вказуватиме на збережену DL-онтологію (KIF,

DAML, OWL) сервісу. У роботі [17] пропонується подолати обмеженість

синтаксичного пошуку UDDI за рахунок «обгортання» інтерфейсу UDDI у

компонент-брокер, що підтримує семантичний пошук, та, паралельно із

внутрішньою переадресацією запитів до UDDI, опитує базу онтологій.

WS-*

Стандарти На додачу до трьох основних елементів технології веб-сервісів

(SOAP, WSDL, UDDI), було випущено ряд специфікацій, які стандартизують

44

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

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

WS-Addressing

WS-Addressing [18] встановлює стандартний механізм включення даних про

маршрутизацію повідомлень у заголовки SOAP. Цей механізм доповнює

транспорт мережевого рівня, який лише турбується про доставку повідомлення до

диспетчера, який здатний прочитати метадані у SOAP-заголовку. WS-Addressing

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

заголовку (wsa:ReplyTo), який містить кінцеве посилання (EPR) на одержувача

відповіді. Це відокремлює час життя SOAP-транзакції «запит-відповідь» від

тривалості життя HTTP-запиту/відповіді, дозволяючи (що важливо) довготривалі

сеанси.

Кінцеві посилання.

Кінцеве посилання (англ. endpoint reference, EPR) – це XML-структура, що

інкапсулює інформацію, корисну для адресації WS-повідомлення. Вона включає:

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

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

його призначення, а також – необов’язкові метадані (WSDL, WS-Policy) про

сервіс. Параметри посилання:

URI точки призначення.

Source endpoint – EPR сервісу, що відправив це повідомлення

(диспетчер).

Reply endpoint -- EPR, на яке слід надіслати відповідь.

Fault endpoint -- EPR, на яке слід надсилати повідомлення про

помилки.

Action – значення, що може визначати семантику повідомлення (URI).

Унікальний ідентифікатор повідомлення (URI).

Відношення до попередніх повідомлень (пара URI).

Важливими для реалізації грід-сервісів є такі моменти: підтримка

довготривалих транзакцій та можливість включення до стандартного заголовка

45

довільної інформації (напр., інформації що, стосується стану сервісу, яку в

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

методів сервісу).

WS-Security

WS-Security [19] є гнучким та багатофункціональним доповненням до

SOAP, яке впроваджує механізми безпеки. Протокол вказує, яким чином вимоги

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

також дозволяє роботу з різними форматами, такими як SAMP, Kerberos, X.509.

Основним акцентом є використання XML-підпису та XML-шифрування. WS-

Security описує три головні механізми:

Як підписувати SOAP-повідомлення для гарантування цілісності та

non-repudiation.

Як шифрувати повідомлення для гарантування конфіденційності.

Як додавати авторизацію (security-tokens).

Специфікація дозволяє використання широкий набір форматів

цифрового підпису, алгоритмів шифрування, механізмів довіри, та security-tokens:

Сертифікати X.509.

Kerberos tickets.

Логін/пароль.

SAML-Assertion.

інші довільні засоби авторизації.

Формати та семантика обраного варіанту визначається у пов’язаних

документах-профілях. WS-Security включає елементи безпеки у заголовок SOAP-

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

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

конструкційним елементом, який разом із іншими розширеннями для веб-сервісів,

дозволить збудувати різноманітні моделі безпеки. Реальна захищеність реалізації

цієї специфікації є відповідальністю розробника. Поза увагою цієї специфікації

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

(конкретні шифри, формати, алгоритми).

46

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

1.Transport Layer Security (без WS-Security) Типовий приклад –

комунікація через HTTPS, WS-Security стає непотрібною, що сприятливо впливає

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

2.Якщо ж довіряти проміжним ланкам не можна, повідомлення слід

підписувати та, за потреби, шифрувати.

3.Потрібно додатково гарантувати відповідальність (non-repudiation) –

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

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

яких визначено у WS-Security.

При цьому слід враховувати, що накладні витрати на шифрування та підпис

є достатньо суттєвими. Якщо продуктивність критична, слід намагатися

використовувати лише один з видів захисту – шифрування або підпис. Накладні

витрати пояснюються зростанням об’єму повідомлень та криптографічною

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

повідомлень на швидкість їх обробки. За одним з них вимірювались 25 різних

типів SOAP-повідомлень різного об’єму та складності, захищених WS-Security та

WS-SecureConversation, на ЦП Pentium 4 2,8 ГГц. Воно виявило, що шифрування

проходило швидше за підпис; одночасне шифрування та підпис у 2-7 разів

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

операцій з безпеки до SOAP в десятки разів повільніше, ніж шифрування чи

підпис простих даних. Важливість стандарту WS-Security для грід-сервісів

полягає в тому, що він, підтримуючи X.509-сертифікати, дозволяє інтегруватися

веб-сервісам у стандартну інфраструктуру безпеки грід (GSI) [20].

RESTful-веб-сервіси та Грід

Існують і альтернативні підходи до реалізації веб-сервісів. Одним з них є

так званий REST-підхід, що базується на засадах архітектури Representational

State Transfer [21]. За такого підходу спрощується реалізація клієнтів, оскільки

такі веб-сервіси використовують сам лише протокол HTTP як основу для

47

взаємодії, без додаткових протоколів-надбудов. REST-веб сервіси на даний

момент не є стандартом, а лише підходом, набором поширених практик.

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

справу із тимчасовими сутностями зі станом – ресурсами. Адже ключовою

абстракцією інформації у REST і є ресурс. Компоненти архітектури REST

виконують маніпуляції над ресурсами шляхом передачі представлень ресурсів,

отриманих в певні моменти часу. Саме представлення ресурсу – це самі дані

ресурсу та його метадані. При цьому при взаємодії компонентів (запит-відповідь)

кожен запит містить в собі всю інформацію про стан.

Запит складається із управляючої частини (команди), ідентифікатора

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

містить метадані ресурса (в довільній формі) та (необов’язкове) представлення

ресурса. Загально кажучи, RESTful-веб-сервіс є набором ресурсів, взаємодія з

якими відбувається через HTTP-методи GET, PUT, POST та DELETE, та

допустимих представлень ресурсів, узгоджених між споживачем сервісу та самим

сервісом. При цьому важливим є відповідність логічної операції над ресурсом

HTTP-методу. Звичайний варіант наведено в таблиці 2.5.

Таблиця 1.6 – Семантика HTTP-операцій в рамках REST-веб-сервісів

Операція Операнд – колекція ресусрів Операнд – ресурс

GETОтримання списку всіх елементів

колекції (та їх URI)

Отримання представлення

ресурсу

PUT Заміна колекції на нову Оновлення ресурсу

POST

Створення нового ресурсу в

колекції з автоматичним

присвоєнням ідентифікатора

Ресурс розглядається як

окрема колекція – див. POST

для колекції

DELETE Видалення усієї колекції Видалення ресурсу

Наприклад, операція «GET http://example.com/grid-tasks/ HTTP/1.1» має

наступну семантику: «отримати перелік усіх грід-задач на ресурсі example.com».

48

А, наприклад, операція «POST http://example.com/grid-tasks HTTP/1.1» (далі в тілі

повідомлення опис задачі в певному форматі) має такий смисл: «запустити нову

грід-задачу на ресурсі example.com». Питання придатності REST-стилю для грід-

сервісів набуває актуальності разом із ростом популярності самого REST-підходу

(напр.[22]). Підтримка REST-стилю була додана у WSDL 2.0.

Компонування веб-сервісів

Безперечно, особливий інтерес представляє можливість об’єднання веб-

сервісів у складніші послідовності для автоматизованого, узгодженого виконання.

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

різному рівні, наприклад, як виконувані бізнес-процеси, чи як абстрактні бізнес-

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

взаємодії. Абстрактні ж бізнес-процеси не мають бути виконані, вони лише

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

процеси відіграють описову роль, роль шаблонів. Обидва ці названі підходи

можуть бути виражені за допомогою мови WS-BPEL [23]. Також можна описати

взаємодію сервісів як «оркестровку» (orchestration) чи як «хореографію»

(choreography). Різниця полягає в тому, що при оркестровці присутній окремий

процес, центральний диспетчер, який контролює взаємодію сервісів. При

хореографії такого централізованого контролера немає, і кожен учасник взаємодії

діє по своїм правилам. WS-BPEL є мовою оркестровки, а не хореографії, веб-

сервісів, причому для опису повідомлень використовується специфікація WSDL

1.1 (це стосується навіть останньої версії стандарту WS-BPEL 2.0). Окрім надання

можливості автоматизації отримання та відправки повідомлень, мова WS-BPEL

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

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

сервісів, слід мати на увазі, що вже існує багатий інструментарій для BPEL-мов, в

т.ч. WS-BPEL, який дозволяє організовувати складні сценарії узгодженого

виконання веб-сервісів. Але цей інструментарій сумісний не з усіма стандартами і

підходами (може не підтримувати WSDL 2.0, REST тощо).

Семантичні розширення веб-сервісів

49

Принципи, що лежать в основі веб-сервісів, на диво прості. І вони нічого не

додають нового в світ розподілених обчислень і Інтернету:

особа, відповідальна за веб-сервіс, визначає формат запитів до свого

веб-сервісу і його відповідей;

будь-який комп'ютер в мережі робить запит до веб-сервісу;

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

назад відповідь.

Цією дією може бути, наприклад виведення, котирування акцій, виведення

ціни на певний продукт, збереження запису в календарі зустрічей, переклад

тексту з однієї мови на іншій, або перевірка номера кредитної картки. Веб-сервіси

додали новий рівень функціональності, роблячи перший крок в напрямку

прозорої інтеграції розподілених компонентів програмного забезпечення,

використовуючи веб-стандарти. Проте поточні технології веб-сервісів, засновані

на SOAP, WSDL та UDDI, оперують на синтаксичному рівні і вимагають участі

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

та виконання веб-сервісів необхідний їх семантичний опис. Опис веб-сервісів у

машинно-зрозумілому форматі дозволяє отримувати більш складну

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

постачальниками. Крім того, це робить можливою інтероперабельність без

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

веб-сервісів, необхідна повна інфраструктура: починаючи від концептуальної

моделі, продовжуючи формальною мовою, що надає формальний синтаксис і

семантику для цієї моделі, і закінчуючи середовищем виконання, що «склеює» усі

компоненти, які використовують цю мову. Серед ініціатив, які пропонують таку

інфраструктуру, можна перерахувати декілька: Web-Service Modelling Ontology

[5], OWL-S, Semantic Web-Service Framework та WSDL-S.

WSMO

Ініціатива Web-Service Modelling Ontology (WSMO) є одним із основних

напрямків у Європі, що має на меті стандартизацію уніфікованої інфраструктури

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

50

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

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

семантичних веб-сервісів. Фактично, семантичні веб-сервіси мають на меті

перетворення перехід до нової генерації Веб, де Інтернет перетворений із

репозиторію інформації, зрозумілого людині в загально-світову систему

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

інтегрувати базові принципи архітектури Веб, а також принципи розподілених

сервіс-орієнтованих систем. Тому WSMO заснований на наступних принципах:

Веб-сумісність: WSMO наслідує концепцію Універсального

ідентифікатора ресурсу (Universal Resource Identifier, URI) для унікального

визначення об’єктів. Крім того, WSMO адаптує поняття просторів імен для

цілісних інформаційних областей, підтримує XML та інші технологічні

рекомендації W3C поруч із децентралізацією ресурсів.

Базування на онтологіях: Онтології використовуються як модель

даних, що означає їх використання у всіх описах ресурсів та обмінів впродовж

процесу використання сервісу. Онтології широко використовуються як найбільш

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

семантичного Веб. Екстенсивне використання онтологій робить можливою

семантично-покращену обробку інформації та забезпечення інтероперабельності.

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

Строге розділення: Розділення символізує ізоляцію ресурсів у

WSMO, яка означає, що кожен ресурс визначений незалежно від інших, не

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

відповідає відкритій та розподіленій природі Веб.

Центральність посередництва: В якості доповнюючого

архітектурного принципу, посередництво адресує обробку гетерогенності, що

природно виникає у відкритих середовищах. Неоднорідність може трапитись в

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

важливість посередництва для успішного вводу у дію веб-сервісів, приділяючи

йому ключову роль у інфраструктурі.

51

Онтологічне розподілення ролей: Користувачі, або, більш загально,

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

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

відповідно до своїх уподобань щодо погоди, культури та піклування за дітьми в

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

готелі та квитків на літак. Базова епістемологія WSMO розрізняє бажання клієнтів

та наявні сервіси.

Опис проти реалізації: WSMO відрізняє опис елементів семантичного

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

описових засобів, заснованих на відповідних формалізмах для забезпечення

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

нових виконавчих технологій. WSMO має на меті забезпечити підходящу модель

онтологічного опису для сумісності з цими технологіями.

Семантика виконання: Для перевірки специфікації WSMO,

формальна семантика виконання WSMX, як й інші WSMO-задіяні системи,

забезпечують технічну реалізацію WSMO. Цей принцип слугує засобом точного

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

Сервіс проти Веб-сервісу: Веб-сервіс – це обчислювальна сутність,

яка може допомогти користувачу досягти певної мети через свій виклик. Служба

ж є фактичним значенням, забезпеченим цим викликом. WSMO надає засоби для

опису веб-сервісів, що забезпечують доступ до певних служб. WSMO створений

для опису першого, а не заміни другого.

Розглянемо концептуальну модель WSMO. Елементи онтології WSMO

описані за допомогою мови мета-мета-моделей на основі Meta Object Facility

(MOF) [6]. MOF визначає абстрактну мову та інфраструктуру для специфікації,

конструювання та керування технологічно-нейтральними мета-моделями.

Оскільки WSMO планувався як метамодель семантичних веб-сервісів, MOF був

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

чотирьох шарів MOF (мета-мета-модель, мета-модель, шар моделі та

інформаційний шар), мова визначення WSMO відповідає шару мета-мета-моделі,

52

сама WSMO скаладає рівень мета-моделі, власне онтології, веб-сервіси, цілі та

посередники складають рівень моделі і фактичні дані, які описані онтологією та

передаються між веб-сервісами відповідають інформаційному шару. Найбільш

часто використовувана мета-модельна конструкція MOF для визначення

елементів WSMO – це Клас (і неявно класоузагальнююча конструкція sub-Class)

разом із його Атрибутами, типами Атрибутів та специфікаторами кількості. Для

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

функціональними властивостями. Вони базуються на наборі метаданих Dublin

Core (DC) для загальних відомостей щодо елемента та інших сервісно-залежних

властивостях, пов’язаних із QoS.

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

використовується у всіх компонентах WSMO. Використовуючи MOF, онтологія

може бути визначена наступним чином:

Лістинг 1.3 – Використання MOF

Як вже було вказано, набір нефункціональних властивостей наявні для

характеризування онтологій. Імпортовані онтології дозволяють модульний підхід

до дизайну онтології і можуть використовуватись за умови відсутності конфліктів

між ними. В реальних умовах при імпорті онтологій, необхідні деякі кроки для

зливання та трансформації імпортованих онтологій для розв’язування

неспівпадінь. Через це використовуються онтологічні посередники (OO

Mediators). Поняття є базовими елементами узгодженої термінології певного

53

проблемного домену. Зв’язки використовуються для моделювання

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

функції є спеціальним видом зв’язку, із унарним діапазоном та N-мірним доменом

(параметри наслідуються зі зв’язку), де значення діапазону функціонально

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

посилання на сховище екземплярів (тобто місце окремого від онтології місця їх

зберігання).

Веб-сервіси. WSMO надає засоби опису для сервісів, що запрошуються

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

Лістинг 1.4 – Використання WSMO

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

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

властивості якості сервіса (quality of service). Додатковий тип посередника (WW

Mediator) доданий для вирішення проблеми неспівпадінь віж веб-сервісами,

пов’язаних із протоколом. Два останні атрибута визначають два ключові поняття

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

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

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

впливів; та інтерфейс (interface), що визначає як поводиться сервіс для досягнення

його функціональності. Інтерфейс служби складається із опису клієнт-среверної

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

функціональність веб-сервіса через агрегування інших веб-сервісів.

54

Задачі. Задача визначає цілі, які може переслідувати користувач під час

звернення до веб-сервісу, описуючи аспекти пов’язані із його побажаннями щодо

запрошуваної функціональності та поведінки. Онтології використовуються як

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

користувацьку точку зору на процес використання веб-сервіса і тому, відповідно,

є окремими сутностями найвищого рівня в WSMO.

Лістинг 1.5 – Окремі сутності найвищого рівня в WSMO

Запрошувана здатність у визначенні задачі представляє функціональність

сервісів, яку б він хотів мати, а запрошуваний інтерфейс репрезентує інтерфейс

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

Mediators. Поняття посередництва у WSMO адресує обробку

неоднорідностей між елементами, що мають взаємодіяти, через вирішення

розбіжностей між різними використаними термінологіями (рівень даних),

комунікаційною поведінкою (рівень протоколів) та бізнес-процесами. WSMO-

посередник з’єднує елементи WSMO, зберігаючи їх слабку зв’язаність, та

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

WSMO-посередник включає елемент-джерело та елемент-ціль і сервіс обробки

невідповідностей.

55

Лістинг 1.6 – Опис елемента WSMO-посередник

WSMO визначає різні типи посередників для приєднання окремих

елементів: OO Mediators приєднують та забезпечуєть взаємодію між

гетерогенними онтологіями, GG Mediators поєднують задачі, WG Mediators

з’єднують веб-сервіси із задачами, і WW Mediators забезпечують

інтероперабельність між різними веб-сервісами.

OWL-S

OWL-S є веб-сервісною онтологією, заснованою на OWL; її задача – надати

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

способом, що природньо грунтується на OWL. Часто на онтологію OWL-S

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

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

OWL, може бути використаний для описання сервісів.

Онтологія OWL-S основним чином складається із трьох взаємопов’язаних суб-

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

використовується для вираження того, що сервіс робить для оголошення,

конструювання викликів до сервісу та порівняння сервісів; модель процесу

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

моніторинг та відновлення; і «заземлення» встаовлює відповідність моделі

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

(зазвичай описується за допомогою WSDL).

56

Усі ці суб-онтології поєднані в поняття Сервіс, яке слугує організаційною

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

створюється екземпляр концепції Сервіс. Сервіс має властивості представляє,

описаний та підтримує. Класи ServiceProfile (що ідентифікує суб-онтологію

профілю), ServiceModel (суб-онтологія моделі процесу) та ServiceGrounding (суб-

онтологія прив’язок) – це діапазони значень цих властивостей. Кожний екземпляр

Service представляє опис ServiceProfile, описаний ServiceModel, та підтримує

ServiceGrounding. ServiceProfile надає засоби опису сервісів, що запропоновані

постачальниками та сервісів, що вимагаються споживачами. Не профіль визначає

представлення сервісу, а, використовуючи наслідування OWL, спеціалізовані

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

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

Profile. Сервіс, визначений через профіль OWL-S, моделюється функцією трьох

базових типів інформації:

Організація, що надає сервіс: Інформація щодо постачальника

послуги (наприклад, контактна інформація оператора підтримки, що

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

його роботи).

Функція, яку виконує сервіс: Перетворення, що виконується службою.

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

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

виконання.

Особливості, що характеризують сервіс: Опис цих особливостей

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

параметрів сервісу, що може містити будь-який тип інформації (профіль OWL-S

надає механізм представлення цих даних).

Найбільш суттєвий тип інформації, представленої у профілі, що відіграватиме

ключову роль впродовж виявлення сервісу, є специфікація функціональності,

пропонованої сервісом. Профіль OWL-S наголошує два аспекти функціональності

сервісу:

57

Трансформація інформації представлена входами та виходами

сервісу.

Зміна стану внаслідок виконання сервісу представлена передумовами

та наслідками сервісу.

Профіль OWL-S не надає схему для опису екземплярів

входів/виходів/передумов/наслідків (ВВПН). Проте така схема існує у онтології

процесу. Вважається, що ВВПН, опублікована профілем є підмножиною ВВПН

процесу, тому очікується, що процесова частина опису містить ці екземпляри, а

профіль може просто вказувати на них. Властивостями класу Profile, який

онтологія профілю OWL-S визначає для вказування на ВВПН, є:

hasParameter: діапазон значень – екземпляри параметрів

онтології процесу.

hasInput: діапазон значень – екземпляри входів онтології

процесу.

hasOutput: діапазон значень – екземпляри виходів онтології

процесу.

hasPrecondition: визначає одну із передумов сервіса та

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

hasResult: означає один із результатів сервісу, визначений

класом Result онтології процесу; специфікує умови, за яких були згенеровані

вихідні значення сервісу. Цей параметр також визначає, які доменні зміни

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

Оскільки профіль OWL-S описує тільки загальне функціонування сервісу,

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

розглядається як процес, і OWL-S визначає субклас ServiceModel для можливості

визначити процеси. З точки зору OWL-S, процес – це не обов’язково програма, а

більше специфікація шляхів клієнтської взаємодії із сервісом. Процес може

генерувати та повертати деяку нову інформацію на основі інформації, що йому

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

виходами процесу. Також, процес може генерувати зміни загального стану. Ці

58

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

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

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

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

та виходи представляються як субкласи загального класу Parameter (кожен

параметр має тип, визначений за допомогою URI). Може існувати будь-яка

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

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

впливів. Виходи та впливи можуть залежати від загального стану у момент

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

формулами. OWL-S трактує такі вирази як літерали: або текстові, або XML.

Останнє використовується для мов, чиє стандартне кодування – це XML (SWRL,

RDF тощо). Перше ж для мов на зразок KIF. Процеси поєднані із ВВПН,

використовуючи наступні властивості:

hasParticipant має значення класу Participant.

hasInput має значення класу Input.

hasOutput має значення класу Output.

hasLocal має значення класу Local.

hasPrecondition має значення класу Condition.

hasResult має значення класу Result.

Процес включає як мінімум дві сторони. Одна – це клієнт, з точки зору

якого описаний процес, інша – це сервіс, з яким має справу клієнт. Як клієнт, так і

сервіс називаються учасниками; вони прямо пов’язані із процесом через

властивість hasParticipant. Через властивості hasInput та hasOutput приєднуються

входи та виходи процесу. Входи процесу можуть як напряму іти від користувача,

так і з попередніх кроків того самого процесу. Наявність передумови визначає, що

процес не може бути виконаний успішно, якщо вона не виконуються; передумови

приєднані до процесу через властивість hasPrecondition. Можливі продукти

роботи процесу – наслідки (або впливи) та виходи – приєднані до процесу не на

59

пряму. А через властивість hasResult. Хоча властивості, описані попередньо,

спільні для всіх процесів OWL-S, існують три їх типи:

Атомарні. Описують сервіси, що очікують одне (можливо,

складене) повідомлення та повертають одне (можливо, складене) повідомлення у

відповідь.

Композитні. Процеси, що містять певну інформацію стану;

кожне повідомлення клієнта оновлює цей стан.

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

тобто простий процес може бути використаний для того, щоб дати уявлення про

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

спрощеної моделі деякого композитного процесу.

Атомарні процеси схожі на дії, які сервіс може виконати при його застосуванні у

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

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

уможливлювання декількох уявлень щодо одного і того ж процесу. Атомарні

процеси можна викликати напряму, і вони не містять субпроцесів; їх виконання є

однокроковим (з точки зору викликаючої сторони), тобто вони приймають

повідомлення, роблять щось і повертають повідомлення-відповідь. Композитні

процеси можна розібрати на інші (атомарні, композитні або прості) процеси; їх

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

OWL-S підтримує наступний набір управляючих конструкцій:

Sequence: набір процесів, що мають бути виконані послідовно.

Split: набір процесів, що мають бути виконані одночасно;

конструкція виконана, коли усі їз її компонентів заплановані на виконання.

Split + Join: набір процесів для паралельного виконання із

синхронізацією; завершується, коли усі процеси-учасники завершені.

Choice: Виконує одну із управляючих конструкцій із заданого

набору; будь-яка із них може бути обрана для виконання.

Any-Order: Дозволяє процесам-компонентам виконання у будь-

якому порядку, але послідовно.

60

If-Then-Else: Перевірити умову; якщо виконується, зробити

Then; якщо не виконується – зробити Else.

Iterate: Виконати процес декілька разів. Конструкція не робить

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

поновлення.

Repeat-While та Repeat-Until: повторення, доки умова

справджується/не справджується.

Опис композитного процесу не має інтерпретуватись як поведінка сервісу, а

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

повідомленнями із сервісом. Крім того, якщо композитний процес має загальний

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

SWSF

Semantic Web Services Framework (SWSF) є одним із найновіших підходів до

семантичних веб-сервісів, і пропонується та пропагандуєтьсяКомітетом мови

семантичних веб-сервісів (Semantic Web Services Language Committee, SWSLC) з

Semantic Web Services Initiative (SWSI). Інфраструктура складається із двох

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

називається Semantic Web Services Ontology (SWSO) та мови, що

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

описів, що називається Semantic Web Services Language (SWSL). SWSO

представляє концептуальну модель для семантичного опису веб-сервісів та

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

SWSL: SWSL-FOL заснованій на логіці першого порядку (First-Order Logic, FOL)

або SWSL-Rules, заснованій на логічному програмуванні. Результуючі онтології

мають назви FLOWS (First-Order Logic Ontology for Web Services), що полягається

на семантику логіки першого порядку, та ROWS (Rule Ontology for Web Services),

що опирається на семантику логічного програмування.

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

модель, зупинимось на FLOWS. Розробка онтології FLOWS відбувалась під

впливом онтології OWL-S ontology вивчених під час її розробки уроків. Іншим

61

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

поведінкової моделі процесу на основі Мови специфікації процесу (Process

Specification Language, PSL). FLOWS можна розглядати як розширення/уточнення

онтології OWL-S, сфокусоване на забепеченні інтероперабельності або семантики

для існуючих стандартів у області веб-сервісів (наприклад, BPEL, WSDL, тощо).

Хоча між онтологіями FLOWS та OWL-S є багато спільного, одна із важливих

відмінностей у виразності базової мови. FLOWS заснований на FOL, чиї

можливості багатші за OWL-S, заснованій на OWLDL. Засновуючись на логіці

першого порядку, FLOWS використовує логічні предикати та терміни для

моделювання загального стану.

Особливості обчислення ситуації, такі, як використання потоків, предикати,

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

середовища. Інваріантні предикати та терміни у SWSO називаються відносинами.

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

сервісів, моделі процесу та прив’язок.

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

інформації щодо сервісу. Модель процесу – для опису роботи процесу Прив’язки

для зв’зування семантичних абстрактних описів сервісу з допомогою SWSO до

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

веб-сервісі.

WSDL-S

WSDL-S пропонує механізм для додавання до функціональних описів веб-

сервісів, представлених мовою WSDL, семантики. Відштовхуючись від того, що

семантична модель веб-сервісу вже існує, WSDL-S описує спосіб прив’язування

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

WSDL. Використовуючи елементи розширення WSDL, можна створити набір

анотацій для семантичної характеристики входів, виходів та роботи веб-сервіса.

Таким чином, семантична модель знаходиться за межами WSDL, що робить цей

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

62

тому, що він є інкрементальним, оскільки будується на існуючому стандарті із

використанням існуючого досвіду та розробленого інструментарію. До того ж,

користувач за допомогою WSDL сумісно аспекти семантичного та операційного

рівнів веб-сервісів. Робота WSDL-S керується набором принципів, найважливіші

із яких є:

Заснованість на існуючих веб-стандартах. Стандарти представляють

ключові положення для створення інтеграційних рішень і, як наслідок, WSDL-S

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

Анотації мають бути агностичними стосовно мови представлення

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

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

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

семантичними рушіями. Таким чином WSDL-S не приписує, яка семантична мова

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

Підтримка анотацій типу даних у XML Schema: Так як XML Schema

є важливим форматом визначення даних і бажаним є повторне використання

інтерфейсів, описаних за допомогою XML, WSDL-S підтримує анотацію XML

схем. Ці анотації використовуються для додавання семантики до входів та виходів

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

– це визначення відповідності складних типів XML Schema та онтологічних

концепцій. Оскільки WSDL-S не визначає конкретної мови опису, техніка

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

представлення.

WSDL-S пропонує п’ять елементів розширення для використання при анотації

входів, виходів та роботи веб-сервісів:

modelReference: елемент, що визначає відношення один-до-

одного між елементами схеми та поняттями онтології;

schemaMapping: атрибут, що може бути доданий до елементів

XSD або складних типів, щоб асоціювати їх із онтологією (один-до-багатьох та

багато-до-одного);

63

precondition: розширюючий елемент (дочірній до operation), що

використовується для вказування комбінації складних виразів та умов в онтології,

що мають виконуватись перед виконанням веб-сервісу;

effects: схожий до попереднього елемент за винятком, що умови

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

category: розширення елементу interface, що вказує на

категоризаційну інформацію, що може бути використана, наприклад, при

публікації веб-сервісу.

Кожен із цих елементів може бути використаний для створення анотацій.

Відкрита архітектура грід-сервісів

Все ж, для реалізації концепції «усе як ресурс», яка може бути моделлю для

грід-сервісної інфраструктури, можливостей вищеназваних стандартів може

виявитись недостатньо. Група дослідників, що представляла Global (Open) Grid

Fourm, послідовно впроваджувала власну концепцію сервісно-орієнтовної

архітектури Грід, яка, пройшовши розвиток від загального опису архітектури

OGSA [9] до стандарту WSRF [13], згодом була реалізована в кількох масштабних

грід-інфраструктурах [10, 11]. Сформувати рекомендації щодо реалізації грід-

сервісів просто неможливо, не взявши до уваги цей цінний досвід.

Головні засади OGSA

Виходячи з того, що у Грід, як і у подібних внутрішніх IT-структурах

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

управління динамічниими групами ресурсів та сервісів. Ці групи ресурсів можуть

бути різними за масштабом, тривалістю життя, постачальниками, можуть бути як

однорідними, так і гетерогенними, можуть поєднуватись у різні способи. Ці

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

(OGSA) [9].

Семантика грід-сервісу за OGSA

Як вже зазначалося, здатність до віртуалізації та поєднання різних сервісів

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

64

у стандартній семантиці взаємодії сервісів, наприклад – у єдиній домовленості

при оповіщенні про помилки.

З цією метою OGSA дає своє вузьке визначення грід-сервісу як веб-сервісу,

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

домовленостей [9]. Інтерфейси мають охоплювати виявлення, динамічне

створення, управління тривалістю існування, оповіщення, управління сервісом,

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

моменти складають основу концепції OGSA-сервісів.

Інтерфейси та домовленості, яким слідує сервіс, стосуються, зокрема,

поведінки при управлінні тимчасовими екземплярами сервісів. Грід-середовище

та ВО передбачають, що часто є необхідність у динамічному створенні нових

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

стан. Коли ж дані про стан стають непотрібними – їх слід знищити. Прикладами

таких тимчасових сутностей із власним станом є: дані сесії відеоконференції,

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

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

суттєво впливає на управління, іменування, пошук та використання сервісів.

Сервісна модель

Як вже зазначалося, головний лейтмотив OGSA – це «все має бути

представлене як сервіс» (сервіс – сутність з мережевими можливостями, що надає

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

сховища, мережі, програми, бази даних – все це сервіси у OGSA. Прийняття

єдиної загальної сервісно-орієнтованої моделі означає, що всі ці компоненти

середовища віртуалізуються. Конкретніше кажучи, OGSA все представляє як грід-

сервіс, називаючи ним веб-сервіс, який дотримується ряду домовленностей та

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

OGSA-сервіси, дозволяє побудову сервісів вищого рівня на його основі.

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

OGSA-сервіс реалізує один або більше інтерфейсів, при чому кожен інтерфейс

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

65

послідовністю повідомлень. Ці інтерфейси відповідають portType у WSDL. Набір

portTypes, які підтримуються конкретним сервісом (та деяка додаткова

інформація по версіям), вказаний у елементі serviceType сервісу (розширення

WSDL, введене в OGSA).

Грід-сервіси можуть підтримувати власний внутрішній стан (дані стану)

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

іншого, що має той самий інтерфейс.

Прив’язка інтерфейса до протоколу може визначати семантику доставки, що

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

середовищі складно гарантувати, що повідомлення дійшло до адресата. З іншого

боку, важливо, щоб адресат зі станом отримав не більше одного примірника

повідомлення (або жодного). В такому випадку бажано було б використовувати

протокол, який би реалізовував це правило. Іншим побажанням для протоколу є

підтримка взаємної аутентифікації.

Сервіси OGSA можуть створюватись та знищуватись динамічно.

Знищуватись явно за вказівкою, або ж неявно через системний збій. Для

управління життєвим циклом сервісу OGSA визначає відповідні інтерфейси.

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

щоб відрізняти один динамічно створений екземпляр сервісу від іншого. Тому

кожний екземпляр грід-сервісу отримує унікальний ідентифікатор – Grid Service

Handle (GSH) [9], який відрізняє його від усіх інших існуючих на даний момент, в

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

збереженням стану, він, звичайно, може використовувати той самий GSH.

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

буде додана підтримка нових протоколів. Тому GSH не несе жодної інформації

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

окремим динамічним екземпляром, інкапсулюється у посилання Grid Service

Reference (GSR). На відміну від GSH, який є незмінним, GSR для екзпмпляру

сервісу може змінюватись впродовж його життя. GSR може мати явний термін

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

66

існування екземпляру, тому OGSA впроваджує механізм отримання оновленого

GSR.

Результат від використання GSR, період існування якого закінчився, є

невизначеним. Також слід мати на увазі, що навіть утримання дійсного GSR не

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

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

завадить його використанню через GSR.

Реалізація концепції грід-сервісів: від OGSI до WSRF

Еволюція підходів до реалізації грід-сервісів

Специфікація відкритої інфраструктури веб-сервісів версії 1.0, видана у

липні 2003, визначає набір домовленостей та розширень щодо використання мови

опису веб-сервісів та XML-схем для реалізації веб-сервісів із підтримкою стану.

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

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

визначення та доступу до даних стану, для асинхронного оповіщення про зміну

стану, для представлення та керування наборами екземплярів сервісів, і для

стандартної обробки помилок виклику сервісів. У січні 2004 була запропонована

платформа ресурсів веб-сервісів як рефакторинг та еволюція OGSI, що спирається

на використання нових стандартів веб-сервісів, зокрема WS-Addressing, та на

досвід від впровадження свого попередника. WSRF зберігає практично усі

функціональні можливості OGSI, змінюючи синтаксис (напр., використовуючи

WS-Addressing) та впроваджуючи нову термінологію. Додатково, WSRF розбиває

функціональність OGSI на 5 різних специфікацій, що можуть поєднуватись.

Розглянемо більш детально взаємозв’язки між WSRF та OGSI [24].

Ядром OGSI був грід-сервіс як веб-сервіс, що дотримується низки угод для

таких цілей, як управління життєвим циклом, доступ до стану та оповіщення про

його зміни. OGSI-грід-сервіси надавали можливість контрольованого управління

розподіленим та часто – довгоживучим станом, що часто вимагається у

розподілених середовищах. OGSI також вводить поняття стандартної фабрики та

67

реєстрації інтерфейсів для створення та пошуку грід-сервісів, а також базовий тип

помилки.

Згодом архітектура веб-сервісів еволюціонувала: як приклад –

впровадження WSDL 2.0 та вихід специфікації WS-Addressing. Ці розробки

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

використовують функціональність інших специфікацій (зокрема WS-Addressing).

Це був слушний час для узгодження функціоналу OGSI із архітектурою веб-

сервісів (WS-Arch). Також OGSI 1.0 поєднував в одній специфікації функції,

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

OGSI для створення платформи відносно незалежних стандартів.

Як результат такої спроби – набір специфікацій (таблиця 1.8),

загальновідомий як платформа ресурсів веб-сервісів [13], в той час, за питання

оповіщень (підписка, доставка) відповідає група специфікацій WS-Notification.

Разом, ці специфікації зберігають усі суттєві функціональні можливості, присутні

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

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

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

використання функціональності, закладеній ще у OGSI.

Важливо показати, як саме нові специфікації WSRF та WS-Notification

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

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

пропонують відмінні чи вдосконалені можливості.

Таблиця 1.8 – Специфікації WSRF

Назва специфікації Короткі відомості

WS-

ResourceProperties

Описує те, як асоціюються ресурси зі станом та веб-

сервіси для створення WS-ресурсів, та як доступні

властивості ресурсу можуть бути отримані, змінені,

видалено

WS-ResourceLifetime Дозволяє запитувачу знищити ресурс негайно або

68

заплановано

WS-

RenewableReferences

Додає анотацію до WS-Addressing Endpoint Reference,

яка потрібна для отримання нової кінцевої точки, коли

поточна стає недійсною

Продовження таблиці 1.8

WS-ServiceGroupДля створення та використання груп неоднорідних

сервісів через посилання

WS-BaseFault Описує базовий тип помилки

WS-Notification

(сімейство

Стандартні підходи до оповіщень, що використовують

шаблон “публікація-підписка”.

OGSI

Доповнимо та уточнимо викладене вище про OGSI. Специфікація визначає:

набір розширень до WSDL, багато з яких вже стали відображені у

WSDL 2.0;

конструкції WSDL для представлення, опитування, оновлення даних

сервісу (метадані та стан);

конструкції Grid Service Handle та Grid Service Reference для адресації

грід-сервісів;

визначення загальної інформації про помилки від операцій із

залученням XML-схеми та пов’язаної семантики WSDL. Просто визначається

базовий формат повідомлень про помилки, без змін до моделі повідомлень про

помилки WSDL;

набір операцій по створенню та знищенню грід-сервісів, який надано

як для явного знищення сервісів, так і для неявного збору сміття від сервісів, у

яких збіг термін існування;

набір операцій по створенню та використанню за посиланням груп

гетерогенних веб-сервісів;

69

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

елементів даних сервісів.

Існує як мінімум 6 (!) різних реалізацій специфікації OGSI, тому було набуто

деякий досвід практичного використання OGSI. На додачу, були спроби створити

специфікації “верхнього рівня” по відношенню до конструкцій OGSI [24].

Зміни у стандартах веб-сервісів та критика OGSI

З тих пір, як ще на початку 2002 р. Розпочалась розробка OGSI, світ веб-

сервісів істотно змінився. Зокрема, виникли нові специфікації та шаблони

використання, які спрощували реалізацію ідей, закладених у OGSI.

WS-Addressing [18] пропонує нейтральний до транспорту (протоколу

доставлення повідомлень) механізм адресації веб-сервісів. Специфікація визначає

XML-елементи для ідентифікації кінцевих точок (endpoints) веб-сервісу і їх

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

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

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

закладена у посиланні на кінцеву точку, не лише надає адресу самого веб-сервісу,

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

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

WS-MetaDataExchange пропонує ряд механізмів для отримання інформації

про опублікований сервіс, такої як WSDL-опис, XML-схема та ін.

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

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

підтримувати специфікацію, яка дублює ці стандарти. Розробка WSRF також була

відповіддю на критику OGSI з боку спільноти користуачів технології веб-сервісів

[24]:

1. Специфікація перевантажена. У OGSI не було чіткого розмежування

функцій для підтримки послідовного, поступового прийняття. Наприклад,

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

роботи із даними сервісу. Сімейства специфікацій WSRF та WS-Notification

врахували ці зауваження.

70

2. Проблеми при роботі із існуючими веб-сервісами та інструментарієм.

OGSI “агресивно” використовує XML-схеми, наприклад, повсемісним

використанням атрибутів xsd:any чи документно-орієнтованими WSDL-

операціями. Це спричиняло проблеми, наприклад, із викорстанням JAX-RPC.

WSRF натомість використовує стандартні механізми XML-схем, звичні

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

щоб розширювати визначення portType з WSDL 1.1, визначаються ”легальні” для

WSDL 1.1 шляхи для анотування елемента portType для асоціацій WSDL-операцій

із ресурсною моделлю.

3. Занадто сильна об’єктна орієнтація. В рамках OGSI моделлю ресурсу

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

сервісу, таким чином поєднуючи в собі сам сервіс та стан. Як зазначалося у

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

на відсутність стану чи окремих екземплярів у веб-сервісів. Не всі реалізації веб-

сервісів підтримують динамічне створення та знищення сервісу. У специфікації

WSRF акцент зміщений на відокремлення веб-сервісу від керованих ним

сутностей, які підтримують стан. WSRF вказує спосіб поєднання веб-сервісу та

stateful-ресурсу, називаючи це “WS-Resource” та застосовуючи WS-Addressing для

адресації таких поєднань.

4. Впровадження WSDL 2.0. Автори OGSI використовували конструкції

із запропонованого тоді чорнового варіанту специфікації WSDL 2.0. Затримка із

публікацією цієї специфікації створювала проблеми із сумісністю існуючого

інструментарію та OGSI. Враховуючи це, слід орієнтуватися на сумісність із вже

існуючими та популярними стандартами, як WSDL 1.1. для запобігання залучення

нових інструментів.

Перехід до WSRF

Перехід до WSRF [13] включав такі кроки:

1. введення концепції ресурсу веб-сервісу (WS-Resource);

2. чіткіше розмежування функцій та вивчення інших специфікацій по

веб-сервісам;

71

3. широший погляд на механізм оповіщень, який є загальною

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

оповіщення про зміну стану.

Конструкція WS-Resource WSRF головним чином пов’язаний із створенням,

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

WSRF надає засоби подання стану як stateful-ресурсу та закріплює зв’язки між

веб-сервісами та ресурсами. Поєднання ресурсу зі станом та веб-сервісу названо

WS-Resource – ресурс веб-сервісу. Платформа описує визначення таких ресурсів

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

сервісу, а також як управляти життєвим циклом ресурсу.

Як видно з короткого порівняння (таблиця 2.8), як OGSI, так і WSRF пов’язані з

тим, як управляти ресурсами зі станом через інтерфейс веб-сервісів. Навіть

зважаючи на те, що ці два підходи моделюють ресурси зі станом по різному –

відповідно, як OGSI-грід-сервіс та як ресурс веб-сервісу WS-Resource – вони

надають принципово ідентичну функціональність та використовують семантично

подібні WSDL-описи інтерфейсу. Як OGSI-сервіс, так і WS-Resource можуть бути

створені, адресовані, перевірені, знищені у подібний спосіб.

WSRF має дві головні переваги над OGSI. По-перше, WSRF був краще

узгоджений як із існуючими XML-стандартами, так із новими, такими як WS-

Addressing. Таким чином, новий підхід легше реалізувати за допомогою

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

використати з існуючими веб-сервісами. Друга перевага – концептуальна.

Термінологія та конструкції OGSI помилково переконали частину веб-сервіс-

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

WSRF показав, що мета полягала лише в маніпулюванні ресурсами через

інтерфейс веб-сервісів. Ніщо не заважало в рамках обох підходів реалізувати

сервіс без стану, що просто транслює операції до внутрішніх ресурсів. WSRF

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

зі станом.

72

WSRF також зважив і на інші висновки [24], набуті після публікації

специфікації OGSI. Практика показала, що інтерфейс OGSI Factory (фабрика) не

настільки корисний, й існували відмінні методи, що досягали тої ж мети. Тому

WSRF просто визначає більш загальний шаблон WS-Resource Factory (фабрики

ресурсів).

Інтерфейс оповіщень OGSI не підтримував багатьох функцій, потрібних у

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

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

прогалину має заповнити сімейство специфікацій WS-Notification.

OGSI використовує Grid Service Reference (GSR) для адресації сервісу, а

також вводить конструкцію Grid Service Handle (GSH) та механізм HandleResolver

як один із способів контролю відповідностей між абстрактними, довготривалими

іменами та конкретними, імовірно, тимчасовими адресами [9]. Комбінація цих

трьох конструкцій дає кілька окремих функцій у взаємозалежному наборі

механізмів. WSRF визначає незалежні механізми для цих функцій. Специфікація

WS-RenewableReferences визначає можливість стабільності кінцевих посилань

шляхом додавання спеціальних політик.

Великий об’єм та обсяг специфікації OGSI зробили її важкою для читання

та розуміння, та для визначення того, які фрагменти є суттєвими для тої чи іншої

задачі. Тому WSRF розбиває функціонал OGSI на окремі специфікації, що

дозволяє також їх гнучке поєднання. Вже згадувалось про те, що використання

XML-стандартів у OGSI погано сумісне із існуючим інструментарієм. Тому було

прийнято рішення про більш консервативний підхід до використання XML-схеми,

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

розширюваної операції у OGSI [24].

73

Рисунок 1.8 – Порядок роботи із веб-сервісом, OGSI-сервісом та WSRF-сервісом

Розширення GWSDL до portType з WSDL 1.1 в рамках OGSI було більше

зайвим “синтаксичним цукром” для розширення інтерфейсу. На додачу, GWSDL

йде навіть далі із проголошенням даних сервісу як частини визначення

74

інтерфейсу. На жаль, GWSDL був найбільшою перешкодою використання OGSI.

Тому WSRF просто визначає свої повідомлення за допомогою конструкцій WSDL

1.1, та вимагає від розробників складних інтерфейсів просто копіювати та

вставляти компоненти таких інтерфейсів до повноцінного переходу на WSDL 2.0.

Приклади реалізації грід-сервісних архітектур

Головними «експлуатантами» специфікацій WSRF є розробники ПЗПШ

(програмного забезпечення проміжного шару) Globus Toolkit 4 [10] та UNICORE 6

[11]. В обох із них базові грід-сервіси успішно реалізовані з урахуванням засад

OGSA таWSRF, однак сама архітектура істотно відрізняється, що піддає сумніву

можливість вирішення проблеми функціональної сумісності між ПЗПШ лише за

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

версія GT – п’ята, в якій тимчасово призупинено використання WSRF-грід-

сервісів. Підтримка усіх особливостей специфікацій WSRF виявилася заскладною

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

під питання доцільність використання специфікацій WSRF, особливо при

розробці прикладних грід-сервісів. В роботі [25] обидва ці ПЗПШ досить

несподівано порівнюються (протиставляються) із семантичними підходами

(WSMO, OWL-S) з точки зору пошуку сервісів, що є натяком на потенційну

несумісність грід-сервісів WSRF та існуючих технологій семантичних веб-

сервісів.

Щоб додатково дослідити ступінь реальної придатності WSRF для побудови

прикладних грід-сервісів, звернемося до існуючого досвіду. Існує чимало спроб

використати готовий інструментарій GT чи UNICORE для створення прикладних

сервісів (різного ступеня успішності). Зважаючи на потенційні проблеми із

семантичним розширенням, додатково звернемо увагу на інший аспект –

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

веб-сервісів) разом із WSRF-грід-сервісами.

В роботі [26] пропонується архітектура грід-сервісів для біоінформатики.

Основними компонентами такої системи є OGSA-DAI для об’єднання

75

гетерогенних ресурсів даних, програма GYM з обробки білкових структур, WSRF-

сервіси доступу до них та BPEL-процесор для виконання робочих потоків.

Вказано шляхи адаптації BPEL до WSRF-сервісів.

Рисунок 1.9 – Запропонована в [26] архітектура, що поєднує BPEL та WSRF

Роботи [27, 28] підтверджують потенційну можливість використання BPEL

та WSRF на прикладі системи, що використовує графічну нотацію CRESS,

середовище ActiveBPEL та грід-сервіси GT4.

В роботі [27] наводиться приклад архітектури (ГІС-системи) для виконання

бізнес-процесів в середовищі, де співіснують традиційні веб-сервіси та WSRF-

сервіси. Пропонується використовувати єдиний модуль управління робочими

потоками, доступ з якого до сервісів різного типу забезпечується через проміжні

адаптери та проксі-об’єкти.

У [28] пропонується розширити стандарт BPEL новим видом діяльності

gridInvoke задля уможливлення створення потоків WSRF-сервісів. Рішення

перевіряється за допомогою інструментарію ActiveBPEL та модулю з візуального

створення потоків для середовища проектування Eclipse.

Робота [29] досліджує можливість використання WS-BPEL-потоків та

WSRF-сервісів ПЗПШ UNICORE для виконання потоків наукових задач. Вкзазано

специфіку наукових потоків порівняно з традиційними бізнес-процесами: більшу

76

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

третьою стороною (third-party transfers), швидка мінливість потоків із

накопиченням досвіду. Запропоноване рішення полягає у розробці процесора

потоків BIS-Grid, адаптованого під специфіку підсистеми запуску задач даного

ПЗПШ.

Рисунок 1.10 – Пропозиція щодо розширення стандарту BPEL задля запуску

WSRF-сервісів [28]

Нарешті, у [30] пропонується ціла платформа CINWEGS (Collaborative

Integrated Web and Grid Services) для узгодженої роботи веб- та грід-сервісів.

Серед обраних технічних рішень для реалізації платформи – бібліотека та

середовище виконання веб-сервісів Apache Axis, WSRF-сервіси GT4, реєстр

Apache jUDDI, процесор робочих потоків ActiveBPEL.

На основі розглянутого вище можна зробити наступні висновки. За формальними

ознаками, WSRF є розширенням стандартних веб-сервісів рядом специфікацій, які

покликані надати можливість моделювати тимчасові ресурси із власним станом.

Практика показала, що при інтеграції WSRF-рішень з існуючими

напрацюваннями (stateless веб-сервісами, засобами оркестровки, семантичної

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

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

77

реалізації концепції WS-ресурсу залучений шаблон фабрики, який є чужим для

звичайних веб-сервісів, а також специфічне використання WS-Addressing

(рисунок 1.10). Це при тому, що WSRF було спробою виправити ситуацію з

OGSA / OGSI, де було впроваджено надзвичайно багато власних рішень, які не

могли прижитися у Веб – реєстри, фабрики, GSH/GSR тощо. І хоча декларується,

що WSRF є реалізацією OGSA, між ними багато відмінностей.

Тож справедливим є питання: а чи можна уникнути використання стандартів

WSRF, які так і не набули поширення? З урахуванням розглянутих раніше деталей

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

стверджувати, що це реально (детальні уточнення див. у наступному розділі).

Відштовхуючись від використання веб-сервісів як комунікаторів, як інтерфейсу

зв’язку, не переобтяжуючи їх додатковими стандартами, можна побудувати,

принаймні, прикладні грід-сервіси, які б спирались на існуюче ПЗПШ та не мали

б стільки проблем із сумісністю з існуючим веб-інструментарієм.

GRID І БАЗИ ДАНИХ. УПРАВЛІННЯ GRID-ОТОЧЕННЯМ

Розподілені БД

 Основною причиною розробки систем, що використовують бази даних,

являється прагнення інтегрувати усі оброблювані в організації дані в єдине ціле і

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

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

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

децентралізації обробки даних. Децентралізований підхід, по суті, відбиває

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

відділів, проектних груп і тому подібного, які фізично розподілені по різних

офісах, відділеннях, підприємствах або філіях, причому кожна окрема одиниця

має справу з власним набором оброблюваних даних. Розробка розподілених баз

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

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

78

забезпечивши при цьому їх збереження саме в тих місцях, де вони найчастіше

використовуються. Подібний підхід розширює можливості спільного

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

Розподілені системи покликані вирішити проблему островів інформації.

Бази даних іноді розглядають як деякі електронні острови. Це положення може

бути наслідком географічної роз'єднаності, несумісності використовуваної

комп'ютерної архітектури, несумісності використовуваних комутаційних

протоколів і так далі. Інтеграція окремих баз даних в одне логічне ціле здатна

змінити подібний стан справ.

 Щоб почати обговорення пов'язаних з розподіленими СКБД проблем,

передусім необхідно утямити, що ж таке розподілена база даних.

 Розподілена база даних – Набір логічно пов'язаних між собою даних (і їх

описів), що розділяються, які фізично розподілені в деякій комп'ютерній мережі.

З цього витікає наступне визначення.

Розподілена СКБД – Програмний комплекс, призначений для управління

розподіленими базами даних і який дозволяє зробити розподіленість інформації

прозорою для кінцевого користувача.

Система управління розподіленими базами даних (СКРБД) складається з

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

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

сполучені між собою лініями зв'язку і кожен з яких працює під керуванням

окремої СКБД. Будь-який з сайтів здатний незалежно обробляти запити

користувачів, що вимагають доступу до даних (що створює певну міру локальної

автономії), які зберігаються локально, а також здатний обробляти дані мережі, що

зберігаються на інших комп'ютерах мережі.

Користувачі взаємодіють з розподіленою базою даних через програми

(застосування). Застосування можуть бути класифіковані як ті, які не вимагають

доступу до даних на інших сайтах (локальні застосування), і ті, які вимагають

подібного доступу (глобальні застосування). У розподіленій СКБД повинно

79

існувати хоча б одне глобальне застосування, тому будь-яка СКРБД повинна мати

наступні особливості.

Набір логічно пов'язаних розподіоених даних.

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

Між фрагментами може бути організована реплікація даних.

Фрагменти і їх репліки розподілені по різних сайтах.

Сайти пов'язані між собою мережевими з'єднаннями.

Робота з даними на кожному сайті управляється СКБД.

СКБД на кожному сайті здатна підтримувати автономну роботу

локальних застосувань.

СКБД кожного сайту підтримує хоч би одне глобальне

застосування.

 Немає необхідності в тому, щоб на кожному з сайтів системи існувала своя

власна локальна база даних, що і показане на прикладі топології СКРБД,

представленої на рисунку 1.11.

Рисунок 1.11 – Топологія   системи   управління розподіленою базою даних

 

80

Приклад розподіленої обробки даних.

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

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

незалежних комп'ютерних системах. Подібні комп'ютерні системи можуть бути

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

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

взаємодіяти між собою, а розгортання в системі СКРБД забезпечить доступ до

даних, розміщених в інших відділеннях компанії. В результаті клієнт, що

проживає в одному місті, зможе звернутися в найближче відділення компанії і

ознайомитися з об'єктами нерухомості, що надаються в оренду в іншому

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

відомостей зв'язуватися з потрібним містом по телефону або посилати поштове

повідомлення.

З визначення СКРБД виходить, що для кінцевого користувача

розподіленість системи має бути абсолютно прозора. Іншими словами, від

користувачів має бути повністю прихований той факт, що розподілена база даних

складається з декількох фрагментів, які можуть розміщуватися на різних

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

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

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

називають основним принципом побудови розподілених СКБД. Цей принцип

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

можливостей, але, на жаль, одночасно ставить перед програмним забезпеченням

СКРБД безліч додаткових завдань, з якими ми детальніше ознайомимося далі.

Розподілена обробка

Дуже важливо розуміти відмінності, існуючі між розподіленими СКБД і

розподіленою обробкою даних.

Розподілена обробка – Обробка з використанням централізованої бази

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

Паралельні СКБД

81

Крім того, слід чітко розуміти відмінності, існуючі між розподіленими і

паралельними СКБД.

Паралельна СКБД – Система управління базою даних, що функціонує з

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

(якщо це можливо) розпаралелювати виконання деяких операцій з метою

підвищення загальної производи-тельности обробки.

Переваги і недоліки, властиві розподіленим СКБД

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

традиційними централізованими системами баз даних. На жаль, ця технологія не

позбавлена і деяких недоліків. У цьому розділі ми обговоримо як переваги, так і

недоліки, властиві системам з розподіленими базами даних.

Переваги

Віддзеркалення структури організації

Подільність і локальна автономність

Підвищення доступності даних

У централізованих СКБД відмова центрального комп'ютера викликає

припинення функціонування усієї СКБД. Проте відмова одного з сайтів СКРБД

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

система в цілому збереже свою працездатність. Розподілені СКБД проектуються

так, щоби забезпечувати продовження функціонування системи, незважаючи на

подібні відмови. Якщо виходить з ладу один з вузлів, система зможе

перенаправити запити до вузла, що відмовив, на адресу іншого сайту.

Підвищення надійності

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

розміщені на більш, ніж одному сайті, відмова окремого вузла або сполучного

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

Підвищення продуктивності

Якщо дані розміщені на самому навантаженому сайті, який успадкував від

систем-попередників високий рівень паралельності обробки, то розгортання

розподіленої СКБД може сприяти підвищенню швидкості доступу до бази даних

82

(в порівнянні з доступом до віддаленої централізованої СКБД). Більше того,

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

центрального процесора і служб вводу/виводу може виявитися нижчим, ніж у разі

централізованої СКБД.

Економічні вигоди

Виявляється, що набагато вигідніше встановлювати в підрозділах

організації власні малопотужні комп'ютери, крім того, значно дешевше додати в

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

Друге потенційне джерело економії має місце у тому випадку, коли бази

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

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

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

може виявитися економічно вигідним розділити застосування на відповідні

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

Модульність системи

У розподіленому середовищі розширення існуючої системи здійснюється

набагато простіше. Додавання в мережу нового сайту не чинить впливу на

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

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

усуваються шляхом додавання в мережу нових обчислювальних потужностей і

пристроїв дискової пам'яті. У централізованих СКБД зростання розміру бази

даних може вимагати заміни і устаткування (потужнішою системою), і

використовуваного програмного забезпечення (потужнішою або гнучкішою

СКБД).

Недоліки

Підвищення складності

Розподілені СКБД, здатні приховати від кінцевих користувачів розподілену

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

продуктивності, надійності і доступності, безумовно є складнішими програмними

комплексами, ніж централізовані СКБД. Той факт, що дані можуть піддаватися

83

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

СКРБД. Якщо реплікація даних не буде підтримуватися на необхідному рівні,

система матиме нижчий рівень доступності даних, надійності і продуктивності,

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

недоліки.

Збільшення вартості

Збільшення складності означає і збільшення витрат на придбання і супровід

СКРБД (в порівнянні із звичайними централізованими СКБД). Разворачива-ние

розподіленої СКБД зажадає додаткового устаткування, необхідного для установки

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

зв'язку, викликаних зростанням мережевого трафіку. Крім того, зростуть витрати

на оплату праці персоналу, який буде потрібно для обслуговування локальних

СКБД і мережевих з'єднань.

Проблеми захисту

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

розподілених системах потрібно буде організувати контроль доступу не лише до

даних, реплікованих на декілька різних сайтів, але і захист мережевих з'єднань

самих по собі. Раніше мережі розглядалися як абсолютно незахищені канали

зв'язку. Хоча це частково справедливо і для теперішнього часу, проте відносно

захисту мережевих з'єднань досягнутий дуже істотний прогрес.

Ускладнення контролю за цілісністю даних

Цілісність бази даних означає коректність і узгодженість даних, що

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

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

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

вимагає доступу до великої кількості даних, використовуваних при виконанні

перевірок, але не вимагає виконання операцій оновлення. У розподілених СКБД

підвищена вартість передачі і обробки даних може перешкоджати організації

ефективного захисту від порушень цілісності даних.

Відсутність стандартів

84

Хоча цілком очевидно, що функціонування розподілених СКБД залежить

від ефективності використовуваних каналів зв'язку, тільки останнім часом стали

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

даних. Відсутність стандартів істотно обмежує потенційні можливості

розподілених СКБД. Крім того, не існує інструментальних засобів і методологій,

здатних допомогти користувачам в перетворенні централізованих систем в

розподілені.

Недолік досвіду

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

розподілених СКБД спеціального призначення, що дозволило уточнити вимоги до

використовуваних протоколів і встановити коло основних проблем. Проте на

поточний момент розподілені системи загального призначення ще не набули

широкого поширення. Відповідно, ще не накопичений необхідний досвід

промислової експлуатації розподілених систем, порівнюваний з досвідом

експлуатації централізованих систем. Такий стан справ є серйозним стримуючим

чинником для багатьох потенційних прибічників цієї технології.

Ускладнення процедури розробки бази даних

Розробка розподілених баз даних, окрім звичайних труднощів, пов'язаних з

процесом проектування централізованих баз даних, вимагає прийняття рішення

про фрагментацію даних, розподіл фрагментів по окремих сайтах і організації

процедур реплікації даних. Усі ці проблеми детальніше будуть розглядатись

нижче.

Усі переваги і недоліки, властиві розподіленим СКБД, перераховані в

таблиці 1.9.

 

85

Таблиця 1.9 – Переваги і недоліки розподілених СКБД

Переваги Недоліки

Відображення структури

організації

Підвищення складності

Разделяемость і локальна

автономність

Збільшення вартості

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

Підвищення надійності Ускладнення контролю за цілісністю даних

Підвищення продуктивності Відсутність стандартів

Економічні вигоди Недолік досвіду

Модульність системи Ускладнення процедури розробки бази даних

 

Гомогенні і гетерогенні розподілені СКБД

Розподілені СКБД можна класифікувати як гомогенні і гетерогенні. У

гомогенних системах усі сайти використовують один і той же тип СКБД. У

гетерогенних системах на сайтах можуть функціонувати різні типи СКБД, що

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

сайти з реляційними, сітковими, ієрархічними або об'єктно-орієнтованими СКБД.

Гомогенні системи значно простіше проектувати і супроводжувати. Крім

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

додаючи нові сайти до вже існуючої розподіленої системи. Додатково з'являється

можливість підвищувати продуктивність системи за рахунок організації на різних

сайтах паралельної обробки інформації.

Гетерогенні системи зазвичай виникають в тих випадках, коли незалежні

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

новостворювану розподілену систему. У гетерогенних системах для організації

взаємодії між різними типами СКБД потрібно буде організувати трансляцію

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

використовуваної СКБД користувачі кожного з сайтів повинні мати можливість

вводити запити, що цікавлять їх, на мові тієї СКБД, яка використовується на

86

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

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

можуть бути потрібні з друго-го сайту, який характеризується такими

особливостями, як:

інший тип використовуваного устаткування;

інший тип використовуваної СКБД;

інший тип використовуваного устаткування і СКБД.

Якщо використовується інший тип устаткування, проте на сайті

встановлений той же самий тип СКБД, методи виконання трансляції цілком

очевидні і включають заміну кодів і зміну довжини слова. Якщо типи

використовуваних на сайтах СКБД різні, процедура трансляції ускладнюється

тим, що необхідно відображувати структури даних однієї моделі у відповідні

структури даних іншої моделі. Наприклад, відношення в реляційній моделі даних

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

Крім того, потрібно буде транслювати текст запитів з однієї використовуваної

мови на іншій (наприклад, запити SQL-оператор SELECT потрібно буде

перетворити в запити з операторами FIND і GET мови маніпулювання даними

сіткової СКБД). Якщо відрізняються і тип використовуваного устаткування, і тип

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

викладене вище назвичайно ускладнює обробку даних в гетерогенних СКБД.

Типове рішення, використовуване в деяких реляційних системах, полягає в

тому, що окремі частини гетерогенних розподілених систем повинні

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

кожного з використовуваних типів СКБД в мову і модель даних реляційної

системи. Проте підходу з використанням шлюзів властиві деякі серйозні

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

транзакціями навіть для окремих пар систем. Іншими словами, шлюз між двома

системами представляє собою не більше, ніж транслятор запитів. Наприклад,

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

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

87

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

трансляції запитів з мови однієї СКБД на мову іншої СКБД. Тому вони не

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

представленням даних в різних схемах.

Розробка розподілених реляційних баз даних

У попередніх заняттях вашій увазі була запропонована методологія

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

На даному занятті ми розглянемо додаткові чинники, які повинні братися до уваги

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

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

Фрагментація. Будь-яке відношення може бути розділене на

деяку кількість частин, які називаються фрагментами, які потім розподіляються

по різних сайтах. Існують два основні типи фрагментів: горизонтальні і

вертикальні. Горизонтальні фрагменти є підмножинами кортежів, а вертикальні –

підмножини атрибутів.

Розподіл. Кожен фрагмент зберігається на сайті, вибраному з

врахуванням "оптимальної" схеми їх розміщення.

Реплікація. СКРБД може підтримувати актуальну копію

деякого фрагмента на декількох різних сайтах.

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

Існують чотири альтернативні стратегії розміщення даних в системі:

централізоване, роздільне (фрагментоване), розміщення з повною реплікацією і з

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

кожної з цих стратегій, і розглянемо їх у світлі досягнення визначених вище

цілей.

Централізоване розміщення

Ця стратегія передбачає створення на одному з сайтів єдиної бази даних під

управлінням СКБД, доступ до якої матимуть усі користувачі мережі (ця стратегія

під назвою "розподілена обробка" вже розглядалася нами вище.) В цьому випадку

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

88

оскільки для отримання будь-якого доступу до даних потрібна установка

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

Рівень надійності і доступності в системі низький, оскільки відмова на

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

Роздільне (фрагментоване) розміщення

В цьому випадку база даних розбивається на фрагменти, що не

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

елемент даних буде розміщений на тому сайті, на якому він найчастіше

використовується, отриманий рівень локальності посилань буде високий. За

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

буде невисокий також рівень надійності і доступності даних в системі. Проте він

буде вищий, ніж в попередньому варіанті, оскільки відмова на будь-якому з сайтів

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

При правильно вибраному способі розподілу даних рівень продуктивності в

системі буде відносно високим, а рівень затрат на передачу даних – низьким.

Розміщення з повною реплікацією

Ця стратегія передбачає розміщення повної копії усієї бази даних на

кожному з сайтів системи.

Розміщення з вибірковою реплікацією

Ця стратегія є комбінацією методів фрагментації, реплікації і централізації.

 Фрагментація. Призначення фрагментації

Коректність фрагментації

Фрагментація даних не повинна виконуватися непродумано, навмання.

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

фрагментації.

Повнота. Якщо екземпляр відношення R розбивається на

фрагменти, наприклад R1,  R2,.., Rn, то кожен елемент даних, присутній відносно

R, має бути присутнім, принаймні, в одному із створених фрагментів. Виконання

цього правила гарантує, що які-небудь дані не будуть втрачені в результаті

виконання фрагментації.

89

Таблиця 1.10 – Порівняльні характеристики різних стратегій розподілу

даних

Розміщення

даних

Локальність

посилань

Надійність і

доступністьПродуктивність

Вартість

пристроїв

зберігання

Витрати на

передачу

даних

Централізоване Найнижча Найнижча Незадовільна Найнижча Найвищі

Фрагментованое Висока1 Низька для

окремих

елементів;

висока для

системи в

цілому

Задовільна1 Найнижча Низькі

Повна реплікація Найвища Найвища Хороша для

операцій читання

Найвища Високі для 

операцій

обновлення,

низькі для

операцій

читання

Вибіркова

реплікація

Висока1 Низька для

окремих

елементів,

висока для

системи

Задовільна 1 Середня Низькі

  1 За умови якісного проектування.

Відновлюваність. Повинна існувати операція реляційної

алгебри, що дозволяє відновити відношення R з його фрагментів. Це правило

гарантує збереження функціональних залежностей.

Неперетинання. Якщо елемент даних di присутній у фрагменті

Ri, то він не має бути одночасно присутнім в якому-небудь іншому фрагменті.

Винятком з цього правила являється операція вертикальної фрагментації, оскільки

в цьому випадку в кожному фрагменті мають бути присутніми атрибути

90

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

правило гарантує мінімальну надлишковість даних у фрагментах.

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

разі вертикальної фрагментації – атрибут.

Типи фрагментації

Існують два основні типи фрагментації: горизонтальна і вертикальна.

Горизонтальні фрагменти є підмножинами кортежів відношення, а вертикальні –

підмножини атрибутів відношення, як показано на рисунку 1.12.

 

Рисунок 1.12 – Різні   типи   фрагментації : а) горизонтальна; б) вертикальна

 

Крім того, існують ще два типи фрагментації: змішана (рисунок 1.13) і

похідна (що є варіантом горизонтальної фрагментації).

Рисунок 1.13 – Змішана фрагментація: а) горизонтально розділені вертикальні

фрагменти; б) вертикально розділені горизонтальні фрагменти

 

Відмова від фрагментації

Останній варіант можливої стратегії полягає у відмові від фрагментації

відношень. Наприклад, відношення Branch (відідлення компанії) містить невелику

кількість кортежів, котрі відносно рідко оновлюються. Замість того, щоб

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

91

по номеру відділення компанії), має сенс залишити це відношення

нефрагментованим і просто розмістити на кожному з сайтів його репліковані

копії. Це перший етап типової процедури визначення схеми фрагментації (пошук

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

відношення, розташовані на одиничній стороні зв'язків типу "один до багатьох", і

підібрати для них оптимальні схеми фрагментації. На останньому етапі

аналізуються відношення, розміщені на множинній стороні тих же зв'язків. Саме

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

Забезпечення прозорості в РСКБД

Розподілені СКБД можуть забезпечувати різні рівні прозорості. Проте у

будь-якому випадку переслідується одна і таже мета: зробити роботу з

розподіленою базою даних абсолютно аналогічної роботі із звичайною

централізованою СКБД. Виділимо чотири основні типи прозорості, які можуть

мати місце в системі з розподіленою базою даних.

Прозорість розподіленості.

Прозорість транзакцій.

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

Прозорість використання СКБД.

Прозорість розподіленості

Прозорість розподіленості бази даних дозволяє кінцевим користувачам

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

Прозорість транзакцій

Прозорість транзакцій в середовищі розподілених СКБД означає, що при

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

і узгодженості розподіленої бази даних. Розподілена транзакція здійснює доступ

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

транзакцій розділяється на декілька субтранзакцій – по одній для кожного сайту,

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

представляються агентами.

92

СКРБД повинна гарантувати атомарність глобальних транзакцій, а це

означає, що усі її субтранзакції будуть або зафіксовані, або скасовані. Таким

чином, СКРБД повинна синхронізувати виконання глобальної транзакції так, щоб

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

фінальна операція фіксації результатів усієї глобальної транзакції.

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

Прозорість виконання вимагає, щоб робота в середовищі СКРБД

виконувалася точно так, як і в середовищі централізованої СКБД.

Обробник розподілених запитів виробляє стратегію виконання, котра є

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

оцінюються за такими показниками:

час доступу, що включає фізичний доступ до даних на диску;

час роботи центрального процесора, що витрачається на

обробку даних в первинній пам'яті;

час, необхідний для передачі даних по мережевих з'єднаннях.

Розглянемо спрощений варіант реляційної схеми програми з базою даних,

що включає наступних три відношення:

Property (Еш, City)         10 000 записів, що зберігаються в Лондоні.

Renter(Їм, Max_Price)     100 000 записів, що зберігаються в Глазго.

Viewing(Ешг, Rno)         1 000 000 записів, що зберігаються в Лондоні.

Щоб отримати список об'єктів нерухомості в Абердине, які були оглянуті

потенційними покупцями, згідними придбати об'єкти нерухомості  дорожче 

200000,   можна  скористатися  наступним SQL -запитом:

SELECT p.pno FROM property p INNER JOIN

((renter r INNER JOIN viewing v ON r.rno = v.rno)

ON p.pno = v.pno

WHERE p.city = 'Aberdeen' AND r.max price > 200000;

Для простоти припустимо, що кожен кортеж у відношеннях має довжину,

рівну 100 символам, що існує тільки 10 покупців, згідних придбати нерухомість за

ціною більше 200000, і що в місті Абердин було проведено 100000 оглядів

93

об'єктів нерухомості. Вважатимемо також, що час виконання обчислень

несуттєвий в порівнянні з часом передачі даних, а швидкість передачі даних по

каналах зв'язку складає 10000 символів в секунду, причому на кожне

повідомлення, що відправляється між двома сайтами, припадає затримка доступу,

рівна 1 секунді.

Проаналізовано шість можливих стратегій виконання цього запиту і для

кожного з них обраховано відповідний час реакції системи.

 Стратегія

1.

Переслати відношення Renter в Лондон і виконати там обробку

запиту :

Час = 1+(100 000 * 100/10 000) = 16,7 хв.

Стратегія 2. Переслати стосунки Property і Viewing в Глазго і виконати там

обробку запиту :

Час = 2+[(1 000 000 + 10 000) * 100/10 000] = 28 год.

Стратегія 3. З'єднати стосунки Property і Viewing в Лондоні, вибрати кор-тежи

для об'єктів нерухомості, розташованих в Абердине, а потім для

кожного з відібраних кортежів перевірити в Глазго, чи встановив

цей клієнт значення стелі допустимої стои-мости нерухомості Max

Price > 200 000 фунтів стерлінгів. Про-верка кожного кортежу

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

Час = 100 000 * (1+100/10 000) + 100 000 * 1 = 2,3 дня.

Стратегія 4. Вибрати   в   Глазго   кортежі   клієнтів,   що встановили   значення

Max Price > 200 000 фунтів стерлінгів, після чого для кожного з j їх

перевірити в Лондоні, чи оглядав цей клієнт об'єкти не-движимости

в Абердине. І в цьому випадку кожна перевірка вклю-чает відправку

двох повідомлень.

Час = 10*(1+100/10 000) + 10* 1 ≈20 с.                                       

Стратегія 5. З'єднати стосунки Property і Viewing в Лондоні, вибрати сведе-ния

про огляди об'єктів в Абердине, виконати проекцію ре-

зультирующей таблиці по атрибутах Рпо і Rno, після чого пере-слать

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

94

Max Price >  200 000 фунтів стерлінгів.  Для спрощення припустимо,

що довжина кортежу після операції проекції також дорівнює 100

символам.

Час = 1 + (100 000 * 100/10 000) = 16,7 хв.

Стратегія 6. Вибрати клієнтів зі значенням атрибуту Max_Price > 200 000 фун-

тов стерлінгів в Глазго і переслати результуючу таблицю в Лондон

для відбору відомостей про огляди об'єктів нерухомості в р.

Абердин:

Час = 1 + (10 * 100/10 000) ≈1с.

 Таблиця 1.11 – Порівняння результатів застосування різних стратегій для

обробки одного і того ж розподіленого запиту

№ Стратегія Час

1. Переслати відношення Renter в Лондон і виконати там обробку

запиту

16,7

хв.

2 Переслати стосунки Property і Viewing в Глазго і виконати там

обробку запиту28 ч.

3 З'єднати стосунки Property і Viewing в Лондоні, вибрати кортежі для

об’єктів нерухомості в Абердині, а потім для кожного з відібраних

кортежів провірити в Глазго, чи встановив цей клієнт максимальне

значення допустимої вартості нерухомості Max Price > 200000

2,3

дні

4 Вибрати в місті Глазго кортежі клієнтів, що встановили значення Max

Price > 200000, після чого для кожного з них перевірити в Лондоні, чи

оглядав цей клієнт об'єкти нерухомості в Абердині

20 с.

5 З'єднати стосунки Property і Viewing в Лондоні, вибрати відомості

осмот-рах об'єктів в Абердине, виконати проекцію результуючої

таблиці по атрибутах Рпо і Rno, після чого переслати отриманий

результат в Глазго для відбору кортежів по умові Max Price > 200 000

16,7

хв.

6 Вибрати клієнтів зі значенням атрибуту Max Price > 200000 в Глазго і

переслати результуючу таблицю в Лондон для відбору відомостей

про огляди об'єктів нерухомості в Абердині

1с.

95

 Прозорість використання СКБД

Прозорість використання СКБД дозволяє приховати від користувача СКРБД

той факт, що на різних сайтах можуть функціонувати різні локальні СКБД. Тому

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

Як правило, це один з найскладніших в реалізації типів прозорості.

Декілька слів на закінчення

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

прозорості в середовищі розподілених СКБД, відзначалося, що досягнення повної

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

прозорості не може бути віднесена до типу "усе або нічого", оскільки може бути

організована на декількох різних рівнях. Кожен з рівнів має на увазі наявність

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

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

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

надається на кожному з сайтів. З іншого боку спектру знаходяться непрозорі

системи, в яких єдиною угодою є формат обміну даними і набір функціональних

можливостей, що надаються кожним сайтом в системі.

Дванадцять правив Дейта для РСКБД

Наостанок ми перерахуємо дванадцять правив (чи цілей), які були

сформульовані Дейтом для типової СКРБД. Основою для побудови усіх цих

правил є те, що розподілена СКБД повинна сприйматися кінцевим користувачем

точно так, як і звична йому централізована СКБД. Дані правила схожі з

дванадцятьма правилами Кодда для реляційних систем.

Правило 0. Основний принцип

З точки зору кінцевого користувача розподілена система повинна виглядати

в точності так, як і звичайна, нерозподілена система.

Правило 1. Локальна автономність

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

автономність означає наступне:

96

локальні дані належать локальним власникам і

супроводжуються локально;

усі локальні процеси залишаються чисто локальними;

усі процеси на заданому сайті контролюються тільки цим

сайтом.

Правило 2. Відсутність опори на центральний сайт

У системі не повинно бути жодного сайту, без якого система не зможе

функціонувати. Це означає, що в системі не повинно існувати центральних

серверів таких служб, як управління транзакціями, виявлення взаємних

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

Правило 3. Безперервне функціонування

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

її функціонування для виконання таких операцій, як:

додавання або видалення сайту з системи;

динамічне створення або видалення фрагментів з одного або

декількох сайтів.

Правило 4. Незалежність від розташування.

Незалежність від розташування еквівалентна прозорості розташування.

Користувач повинен діставати доступ до бази даних з будь-якого з сайтів. Більше

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

зберігались на його сайті, незалежно від того, де вони фізично зберігаються.

Правило 5. Незалежність від фрагментації

Користувач повинен діставати доступ до даних незалежно від способу їх

фрагментації.

Правило 6. Незалежність від реплікації

Користувач не повинен потребувати відомостей про наявність реплікації

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

доступу до конкретної копії елементу даних, а також не повинен піклуватися про

оновлення усіх наявних копій елементу даних.

Правило 7. Обробка розподілених запитів

97

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

розташованих на більш, ніж одному сайті.

Правило 8. Обробка розподілених транзакцій

Система повинна підтримувати виконання транзакцій, як одиниці

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

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

властивостей транзакцій, а саме: атомарності, узгодженості, ізольованості і

тривалості.

Правило 9. Незалежність від типу устаткування

СКРБД має бути здатна функціонувати на устаткуванні з різними

обчислювальними платформами.

Правило 10. Незалежність від операційної системи

Прямим наслідком попереднього правила є вимога, згідно з яким СКРБД

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

Правило 11. Незалежність від мережевої архітектури

СКРБД має бути здатна функціонувати в мережах з різною архітектурою і

типами носія.

Правило 12. Незалежність від типу СКБД

СКРБД має бути здатна функціонувати поверх різних локальних СКБД,

можливо, з різним типом використовуваної моделі даних. Іншими словами,

СКРБД повинна підтримувати гетерогенність.

Останніх чотири правила є доки лише ідеальними. Оскільки їх

формулювання є занадто загальним, і внаслідок недостатності наявних стандартів

на комп'ютерну і мережеву архітектуру, в осяжному майбутньому можна чекати

лише часткового задоволення розробниками вказаних вимог.

 Резюме

Розподілена база даних є набором логічно пов'язаних між собою

даних (і їх описів), що розділяються, які фізично розподілені в деякій

комп'ютерній мережі. СКРБД є програмний комплексом, призначеним для

прозорого управління розподіленої базою даних.

98

Розподілену СКБД не слід змішувати з розподіленою обробкою,

при якій доступ до централізованої СКБД одночасно надається багатьом

користувачам в комп'ютерній мережі. СКРБД також відрізняється від паралельної 

СКБД,  в  якій локальна  система управління базою даних функціонує з

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

організувати паралельне виконання операцій (якщо це можливо) з метою

підвищення продуктивності системи.

Переваги СКРБД полягають в тому, що вона дозволяє відбити

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

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

отримати економію коштів, а також організувати модульне збільшення розмірів

системи.

Усі взаємодії виконуються за допомогою мережевих з'єднань, 

які можуть бути як локальними, так і глобальними. Локальні мережеві з'єднання 

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

спроможність, чим глобальні.

Аналогічно тому, як централізована СКБД повинна надавати

опреде-ленный набір стандартних функцій,  розподілена СКБД повинна надавати

розширені можливості установки з'єднань, включати розширену службу

системного каталогу, забезпечувати розподілену обробку запитів, підтримувати

розширені засоби розпаралелювання операцій, а також мати власну службу

відновлення.

Кожне відношення може бути розділене на деяку кількість

частин, званих фрагментами. Фрагменти можуть бути горизонтальними,

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

або декількох сайтах. З метою поліпшення доступності даних і підвищення

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

реплікація.

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

наступних цілей: забезпечення локальності посилань, підвищення надійності і

99

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

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

мінімізації витрат на передачу даних. Три основних пра-вила коректності

фрагментації включають вимоги повноти, відновлюваності і непересікальності.

Існують чотири стратегії розподіли, що визначають спосіб

розміщення даних : централізований (єдина централізована база даних),

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

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

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

способів).

З точки зору користувача, СКРБД повинна виглядати точно так,

як і звичайна централізована СКБД, що досягається за рахунок забезпечення

различ-ных типів прозорості. Завдяки прозорості розподілу користувачі не

потребують яких-небудь відомостей про існуючу в системі

фрагментації/реплікацію. Прозорість транзакцій забезпечує збереження

узгодженості глобальної бази навіть за наявності паралельного доступу до неї з

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

виконання дозволяє системі ефективно обробляти запити, що включають

звернення до даних на декількох сайтах. Прозорість використання СКБД дозволяє

системі функціонувати поверх установлен-ных на окремих сайтах локальних

СКБД різного типу.

 Керування розподіленою паралельністю.

Цілі, що стояти при обробці розподілених транзакцій, не

відрізняються від переслідуваних при обробці транзакцій у централізованих

системах. Однак досягти цих цілей у випадку СКРБД складніше, оскільки

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

й всіх її субтранзакцій.

Якщо графіки виконання транзакцій на шкірному із сайтів

упорядковані, то глобальний графік (об' єднання всіх локальних графіків) також

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

100

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

послідовних графіках на всіх сайтах.

Для забезпечення розподіленої впорядкованості можуть

використовуватися два методи: з використанням блокування або тимчасових

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

блокування булі встановлені до скасування хоча б однієї з них. Протоколи

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

первинними копіями й розподіленою схемою. Крім того, може використатися

метод блокування більшості. При використанні тимчасових міток транзакції

впорядковуються таким чином, що найбільш старі транзакції у випадку конфлікту

одержують перевагу.

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

вимагає злиття локальних графів очікування з наступним аналізом глобального

графа на наявність петель. При виявленні петлі для її усунення одна або більше

транзакцій повинні бути скасовані й перезапущені. У розподілених СКБД існують

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

централізована, ієрархічна й розподілена.

Специфічними причинами відмов у розподіленому середовищі є

втрата повідомлень, відмова ліній зв'язку й мережних з' єднань, відмова окремих

сайтів і розчленовування мережі. Для організації відновлення на шкірному із

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

відкату й повторного виконання транзакцій, необхідного при відновленні після

відмови.

Двофазний протокол фіксації транзакцій складається з етапів

голосування й ухвалення  глобального  рішення.   На першому  етапі 

координатор  опитує учасників про їхню готовність до фіксації транзакції. Якщо

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

транзакція й всі її локальні   субтранзакції   будуть   скасовані.   Глобальна  

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

проголосували за фіксацію результатів. При використанні двофазного протоколу

101

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

залишитися заблокованими.

Трифазний протокол фіксації транзакцій неблокуючий.  Він

припускає розсилання координатором транзакції між етапами голосування й

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

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

транзакції.

Модель X/Open DTP являє собою один з варіантів архітектури

обробки  розподілених  транзакцій,   побудованої   на  застосуванні  протоколу

OSI - TP і двофазного протоколу фіксації транзакцій. У цій моделі визначаються

прикладні програмні інтерфейси й методи взаємодії між додатками, що

запускають транзакції, менеджерами транзакцій, менеджерами ресурсів і

менеджерами передачі даних.

Реплікацією  називається процес  генерації й  відтворення 

декількох копій даних на одному або більше сайтів. Це дуже важливий механізм,

оскільки з його допомогою організації можуть надавати своїм користувачам

доступ до актуальної інформації там і тоді, коли це їм потрібно. Використання

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

продуктивності (у тихий випадках, коли централізовані ресурси виявляються

перевантаженими), підвищення надійності зберігання й доступності даних, а

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

призначених для систем підтримки прийняття рішень.

КЕРУВАННЯ РОЗПОДІЛЕНОЮ ПАРАЛЕЛЬНІСТЮ

 

Управління розподіленими транзакціями

 Раніше було відмічено, що цілі розподіленої обробки транзакцій аналогічні

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

використовувані для цього методи істотно складніші, оскільки розподілена СКБД

повинна забезпечувати нерозривність усієї глобальної транзакції, а також кожній

102

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

виконання транзакцій, що запускаються прикладними програмами, і взаємодіє з

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

паралельним виконанням в системі. Мета роботи планувальника полягає в

досягненні максимального рівня розпаралелювання в системі з одночасною

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

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

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

диспетчер відновлення забезпечує відновлення бази даних і переведення її в

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

відновлення також відповідає за відновлення бази даних до деякого узгодженого

стану і після відмов системи. Диспетчер буферів забезпечує передачу даних між

дисковими пристроями і оперативною пам'яттю комп'ютера.

У розподіленій СКБД усі ці модулі як і раніше є в кожній локальній СКБД.

Крім того, на кожному вузлі функціонує диспетчер глобальних транзакцій, або

координатор транзакцій, що координує виконання глобальних і локальних

транзакцій, ініційованих на цьому вузлі. Усі взаємодії між вузлами здійснюються

через компонент передачі даних (диспетчери транзакцій на різних вузлах не

взаємодіють безпосередньо один з одним).

Процедура виконання глобальної транзакції, запущеної на вузлі

здійснюється таким чином.

Координатор транзакцій (ТС1) на вузлі S1, ділить транзакцію на

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

каталозі системи.

Компонент передачі даних на вузлі – відправляє опис

відповідних субтранзакцій на вузли S2 і S3.

Координатори транзакцій на вузлах S2 і S3 організовують

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

координаторові TC1 за допомогою компонентів передачі даних. Увесь описаний

процес схематично представлений на рисунку 1.13.

103

 

Рисунок 1.13 – Схема координації виконання розподілених транзакцій

 

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

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

виконанням, виявлення взаимоблокировок і відновлення.

 Управління паралельним виконанням в розподіленому середовищі

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

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

розподілених СКБД. Але спочатку слід ознайомитися з цілями, які стоять перед

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

Цілі управління паралельним виконанням в розподіленому середовищі

Якщо припустити, що в системі не існує відмов, то призначення механізму

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

елементів даних і завершенні кожної елементарної операції в межах деякого

встановленого проміжку часу. Крім того, прийнятний механізм управління

паралельним виконанням в розподіленій СКБД повинен забезпечувати наступне:

стійкість до відмов на вузлі і в лініях зв'язку;

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

вимогам продуктивності;

невисокий додатковий рівень споживання процесорного  часу і

інших системних ресурсів;

104

задовільні показники роботи з мережевими з'єднаннями, що

мають велику тривалість часу затримки з'єднання;

відсутність додаткових обмежень на структуру елементарних

операцій.

У попередніх заняттях були описані основні проблеми, які можуть

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

До них відносяться проблеми втраченого оновлення, залежності від проміжних

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

розподіленому середовищі, але тут доводиться долати ще і труднощі, викликані

розподіленим зберіганням даних. Одна з них називається проблемою

узгодженості багатьох копій даних і виникає в тих випадках, коли існує декілька

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

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

елементу даних на одному з вузлів необхідно відбити цю зміну і в усіх інших

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

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

копійованих елементів виконується в системі синхронно, як частина транзакції,

що включає початкову операцію оновлення.

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

Концепція впорядкування, описана раніше, може бути розширена з

урахуванням особливостей зберігання даних в розподіленому середовищі. Якщо

графік виконання транзакцій на кожному з вузлів є упорядковуваним, то

глобальний графік (є об'єднанням усіх локальних графіків) також буде

впорядковуваним, за умови, що послідовності локального впорядкування є

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

одному і тому ж порядку в еквівалентному послідовному графіку на усіх вузлах.

Тому, якщо субтранзакцію Ti на вузлі S1 позначити як , необхідно забезпечити,

що якщо <  то <  для усіх вузлів Sx, на яких транзакції <  мають

субтранзакції.

105

Рішення по організації управління паралельним виконанням в

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

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

даних. Тому, якщо дана множина транзакцій, які повинні виконуватися

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

Механізм блокування забезпечує, що графік паралельного

виконання транзакцій буде еквівалентний деякому (непередбачуваному) варіанту

послідовного виконання цих транзакцій.

Механізм обробки часових відміток гарантує, що графік

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

послідовного виконання цих транзакцій відповідно до їх часових відміток.

Якщо база даних являється або централізованою, або фрагментовано, але не

використовуює реплікації даних, то в ній існує тільки одна копія кожного

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

або можуть бути виконані на одному з віддалених вузлів. В цьому випадку

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

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

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

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

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

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

не лише на кожному з локальних рівнів, але і на глобальному рівні, якщо

взаємоблокування виникає при зверненні до даних, розміщених на декількох

вузлах.

Протоколи блокування

Розглянемо наступні протоколи, засновані на двофазному блокуванні (2PL),

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

розподілених СКБД. До них відносяться централізований протокол двофазного

блокування, двофазне блокування з первинними копіями, розподілений протокол

двофазного блокування і блокування більшості копій.

106

Централізований протокол двофазного блокування

При використанні цього протоколу існує єдиний вузол, на якому

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

усій розподіленій СКБД існує тільки один планувальник, або диспетчер

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

запуску глобальної транзакції на вузлі S1 централізований протокол двофазного

блокування працює таким чином.

1. Координатор транзакцій на вузлі S1 розділяє глобальну транзакцію на

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

глобальному системному каталозі. Координатор відповідає за дотримання

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

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

копій цього елементу даних. Тому координатор повинен зажадати встановити

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

звільнити ці блокування. Для читання оновлюваного елементу даних координатор

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

якщо така існує.

2. Локальні диспетчери транзакцій, які беруть участь у виконанні

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

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

звичайними правилами протоколу двофазного блокування.

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

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

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

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

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

знаходиться аж до того моменту, коли необхідне блокування може бути надане.

Варіантом цієї схеми є випадок, коли координатор транзакцій виконує усі

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

107

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

окремими локальними диспетчерами транзакцій.

Перевага централізованого протоколу двофазного блокування полягає в

тому, що його можна відносно просто реалізувати. Виявлення взаимоблокировок

може виконуватися тими ж методами, що і в централізованих СКБД, оскільки уся

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

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

централізація в розподіленій СКБД автоматично призводить до появи вузьких

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

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

швидкодія обмежує можливості усієї системи. Крім того, відмова цього вузла

викликає порушення роботи усієї розподіленої системи, тому вона стає менш

надійною. Проте цій схемі властивий відносно невисокий рівень витрат на

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

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

потребувати відправки йому не менше 2n + 3 повідомлень, у тому числі:

один запит на блокування;

одне повідомлення про надання  блокування;

n сполучень з вимогою оновлення;

n підтверджень про виконане оновлення;

один запит на зняття блокування.

Двофазне блокування з первинними копіями

У цьому варіанті протоколу спроба подолати недоліки централізованого

протоколу двофазного блокування робиться за рахунок розподілу функцій

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

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

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

вибирається як первинна копія (primary copy), a усі інші розглядаються як

вторинні (slave copy). Вибір первинного вузла може здійснюватися за різними

108

правилами, причому вузол, який вибраний для управління блокуванням первинної

копії даних, не обов'язково повинен містити саму цю копію.

Цей протокол є простим розширенням централізованого протоколу

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

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

первинна копія, і послати запит на блокування елементу відповідному

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

виняткове блокування тільки його первинної копії. Після того, як первинна копія

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

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

запобігти читанню іншими транзакціями застарілих значень даних. Проте немає

необхідності виконувати усі оновлення у вигляді однієї елементарної операції.

Цей протокол гарантує актуальність значень тільки первинної копії даних.

Подібний підхід може використовуватися в тих випадках, коли дані

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

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

Недоліками цього підходу є ускладнення методів виявлення взаємоблокувань у

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

системі певної міри централізації, оскільки запити на блокування первинної копії

елементу можуть бути виконані тільки на єдиному вузлі. Останній недолік може

бути частково компенсований за рахунок застосування резервних вузлів, що

містять копію інформації про блокування елементів. Цей протокол

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

продуктивності, чим централізований протокол двофазного блокування, в

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

Розподілений протокол двофазного блокування

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

централізованому протоколу двофазного блокування, але вже за рахунок

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

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

109

що знаходяться на його вузлі. Якщо дані не піддаються реплікації, цей протокол

функціонує аналогічно протоколу двофазного блокування з первинними копіями.

Інакше розподілений протокол двофазного блокування використовує особливий

протокол управління реплікацією, що дістав назву "Читання однієї копії і

оновлення усіх копій" (Read - One - Write - All - ROWA). В цьому випадку для

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

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

виняткові блокування на усіх копіях. У такій схемі управління блокуваннями

здійснюється децентралізованим способом, що дозволить позбавитися від

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

свої недоліки, пов'язані з істотним ускладненням методів виявлення

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

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

первинними копіями), які викликані необхідністю блокувати усі копії кожного

оновлюваного елементу. У цьому протоколі виконання глобальної операції

оновлення, що має агентів на n вузлах, зажадає передачі не менше 5n

повідомлень, у тому числі:

n сполучень із запитами на блокування;

n сполучень з наданням блокування;

п сполучень з вимогою оновлення елементу;

n сполучень з підтвердженням виконаного оновлення;

n сполучень із запитами на зняття блокування.

Це кількість повідомлень може бути скорочена до 4n, якщо не передавати

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

операції остаточної фіксації розподіленої транзакції.

Блокування більшості копій

Цей протокол можна вважати розширенням розподіленого протоколу

двофазного блокування, в якому усувається необхідність блокування усіх копій

реплікованого елементу даних перед його оновленням. В цьому випадку

диспетчер блокувань також є на кожному з вузлів системи, де він управляє

110

блокуваннями усіх даних, що розміщуються на цьому вузлі. Коли транзакції

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

системи, вона повинна відправити запит на блокування цього елементу більше,

ніж на половину з усіх тих n вузлів, де є його копії. Транзакція не має права

продовжувати своє виконання, поки не встановить блокування на більшості копій

елементу даних. Якщо їй не вдасться це зробити за деякий встановлений

проміжок часу, вона відміняє свої запити і інформує усі вузли про відміну її

виконання. Якщо більшість підтверджень будуть отримані, усі вузли

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

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

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

встановлене тільки для однієї транзакції.

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

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

підвищеній складності алгоритму, ускладненні процедур виявлення

взаємоблокувань, а також необхідності відправки великої кількості повідомлень із

запитами на встановлення блокування та з запитами на відміну блокування.

Метод успішно працює, але показує себе надмірно жорстким відносно блокувань,

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

даних, а цей метод вимагає установки блокувань на більшості копій.

Протоколи з часовими відмітками

Протоколи для централізованих баз даних, що використовують часові

відмітки, описані раніше. Завданням подібних протоколів є глобальне

впорядкування транзакцій таким чином, що старіші транзакції (що мають меншу

тимчасову відмітку) у разі конфлікту отримують пріоритет. У розподіленому

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

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

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

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

111

синхронізований, а при використанні лічильників подій ніщо не перешкоджає

виробленню одних і тих же значень лічильника одночасно на різних вузлах.

Загальним підходом в розподілених СКБД є конкатенація локальної часової

відмітки з унікальним ідентифікатором вузла у форматі <локалъная_відмітка,

ідентифікатор_вузла>. Значення ідентифікатора вузла має менший ваговий

коефіцієнт, що гарантує впорядкування подій відповідно до моменту їх

виникнення і лише потім відповідно до місця їх появи. Щоб запобігти

виробленню більш завантаженими вузлами великих значень часових відміток в

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

механізм синхронізації значень часових відміток між вузлами. Кожен вузол

поміщає свою поточну часову відмітку в повідомлення, що передаються на інші

вузли. При отриманні повідомлення вузол-одержувач порівнює поточне значення

його часової відмітки з отриманим і, якщо його поточна часова відмітка

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

часової відмітки, яке було отримано ним в повідомленні. Наприклад, якщо вузол 1

з поточною часовою відміткою <10, 1> передає повідомлення на вузол 2 з

поточною часовою відміткою <15,2>, то вузол 2 не змінює свою часову відмітку. І

навпаки, якщо поточна часова відмітка на вузлі 2 рівна <5, 2>, то вузол 2 повинен

змінити свою часову відмітку на <11, 2>.

Технології ActiveX та CORBA для побудови розподілених систем

ActiveX/DCOM – це корпоративна технологія з фірмовим знаком Microsoft.

Головне її призначення – полегшення написання мережевих розподілених

об'єктно-орієнтованих застосувань. По суті, ActiveX – це ні що інше, як

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

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

Automation, OLE Documents, OLE Controls) і елементами ActiveX? Відповідь дуже

проста. OLE-механізми засновані на компонентній об'єктній моделі (COM,

Component Object Model), яка дозволяє створювати об'єктно-орієнтовані

застосування на одній машині у рамках операційної системи Windows, що

функціонує на ній, a ActiveX використовує DCOM (Distributed Component Object

112

Model) – розподілену компонентну об'єктну модель, яку реалізують бібліотеки

ActiveX, що являються за об'ємом значно менше, чим бібліотеки OLE, а за

швидкістю – швидше. Іншими словами, бібліотеки OLE переписані так, щоб

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

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

бібліотеками ActiveX. Моделі СОМ і DCOM спираються на базові мережеві

протоколи, такі як TCP/IP, і входять до складу операційної системи.

Що таке СОМ і DCOM

COM (Component Object Model) розшифровується просто – компонентна

об'єктна модель. DCOM (Distributed Component Object Model) – це, відповідно,

розподілена компонентна об'єктна модель.

Microsoft розробляє і підтримує DCOM виключно для створення серверів

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

Microsoft, два інших комп'ютерних гіганта – Sun і IBM – спираються на

міжнародний стандарт CORBA. За бажання можна спільно використати обидві ці

технології.

DCOM просто розширює можливості СОМ в частині реєстрації віддалених

об'єктів, тому його іноді називають "СОМ з подовженим дротом".

Прикладні інтерфейси COM API – це усе ті ж, усім відомі OLE-інтерфейси,

що ведуть своє походження від DDE (Dynamic Data Exchange), – динамічного

обміну даними, що дозволяє єдиним способом в Windows здійснювати обмін

інформацією між процесами.

По суті своїй СОМ є простим об'єктним розширенням OLE-технології, коли

в локальній моделі засобів автоматизації OLE команди від клієнта проходять

через модуль-ініціалізатор (proxy), а повідомлення – в модуль-перехідник (stub),

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

показано на рис 1.14.

 

113

Рисунок 1.14 – Схема роботи OLE Automation

 

Наочніше ця ж схема, але вже в специфікації СОМ, представлена на

рис. 1.14.

Модель СОМ значно простіша з точки зору програмістів і її набагато

зручніше використати в невеликих локальних мережах.

У дистанційній моделі, яка тепер замість СОМ дістала назву DCOM,

ініціалізатор і перехідник стали абсолютно іншими, тепер в них

використовуються процедури дистанційного виклику (RPC) для передачі запитів

клієнта по мережі до модуля Remote Server Process, що функціонує на сервері.

Клієнтська частина DCOM, аналогічна колишньому механізму Automation

Manager, передає дані клієнта вказаному OLE-серверу і дані у відповідь по мережі

до програми-клієнта, як показано на рис. 1.15.

 Як можна бачити з приведених рисунків, чудовою властивістю DCOM є

його прозорість як для користувача, так і для програміста. Можна створити і

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

дистанційному режимі простим перенесенням OLE-сервера на віддалений ПК, на

якому працює модуль адміністратор автоматизованого управління DCOM. Потім

треба просто зареєструвати нове місце розташування OLE-сервера за допомогою

звичайної утиліти (наприклад, з арсеналу засобів Visual Basic). Програмістові не

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

OLE-сервер віддалено. Зараз майже у будь-якій RAD-системі є шаблони для

створення OLE -серверів, методи і об'єкти яких доступні при роботі в

дистанційному режимі. І, оскільки реєстрацію віддаленого сервера легко

114

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

небудь додаткових дій, щоб скористатися новими можливостями.

Рисунок 1.15 – Схема взаємодії для локального і віддаленого варіантів

 

Робота серверів OLE в дистанційному режимі має ряд істотних переваг, у

тому числі спрощене адміністрування і обслуговування, можливість його

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

система захисту доступу і достовірності даних. Але найголовніше перевага – це

здатність віддалених OLE-серверів виконувати роль серверів застосувань, тобто

своєрідних виконавців алгоритмів (у новій термінології – бізнес-правил) для

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

115

Реалізація цієї можливості є ключовим моментом в створенні трирівневої

архітектури ділових застосувань Microsoft, в якій частина призначеного для

користувача інтерфейсу розміщена на робочій станції клієнта, бізнес-логіка – на

сервері середнього рівня, а надпотужні засоби обробки даних – на SQL-сервері

бази даних (рис. 1.16).

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

намагатися ділити програму на частини), якщо вона не вирішує загальну

проблему ефективності.

 

Рисунок 1.16 – Трирівнева архітектура бізнес-застосувань

 

Проте у фірмовій документації Microsoft, присвяченій OLE-об’єктам,

стверджується: "Найчастіше розміщення сервер-об’єктів доступу до даних на тій

машині, де знаходиться база даних, може істотно скоротити завантаження мережі

і збільшити загальну швидкість передачі даних". Є приклади реалізації

трирівневих клієнт-серверних застосувань, де результати перевершують усі

очікування. Продуктивність мережі практично перестає впливати на час обробки

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

OLE-сегменти приводить до значного підвищення ефективності роботи

застосування в цілому. Більше того, трафік в мережі істотно зменшується і стає

більше передбачуваним.

116

Найприйнятніший, і найбільш простий, ефективний підхід на думку

більшості творців територіально-розподілених застосувань – це створення

трирівневої архітектури. У цій моделі є користувач-клієнт і сервер бази даних, а

також середній рівень, який діє як "діловий" або інтелектуальний сервер

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

логіку системи на сервер застосувань, який міг би знаходитися на тому ж самому

комп'ютері, що і сервер бази даних (чи на іншому комп'ютері). Часто це дає ефект

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

"товстих" клієнтів. Сервер застосувань здійснює запити до сервера бази даних за

вимогами клієнтів і реалізує бізнес-логіку, що не лише спрощує розробку і

супровід клієнтів, але також означає, що слід модифікувати тільки одну програму

при зміні ділової логіки реалізації бізнес-процесів.

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

приклад з реального життя. Припустимо, є велика транспортна компанія M-Trans,

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

проходження вантажу. Коли ви відправляєте вантаж з Москви в Делі, вам дається

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

вашим вантажем на шляху слідування, ви просто завантажуєте програму (назвемо

її MTrack) і вводите свій транспортний номер. Діалоговий модуль зв'язується з

центральною універсальною ЕОМ компанії і відшукує інформацію відносно

поточного місця розташування і стану вашого вантажу. Наприклад, ви могли б

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

що він був вже отриманий замовником. Електронний підпис замовника,

природно, повинен свідчити про цей відрадний факт.

Поки усе звучить, подібно до банальної історії про типове обслуговування

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

від типу присвоєного транспортного номера. Різні типи чисел  означають  різні 

типи  послуг,   що надавались   користувачеві (наприклад, можливість упевнитися

в підписі замовника товару, достовірності упаковки і т. д.). Щоб зробити MTrack

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

117

користувач не повинен потребувати інтерпретації типу номера, який він отримав.

Було б логічне покласти цю процедуру на центральну ЕОМ, але відносно неї у

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

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

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

такого рішення заперечувала група супроводу програмного забезпечення,

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

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

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

використовується більш ніж 50000 замовниками, це було б справжнім кошмаром.

Тому було покінчено з ідеєю інтерпретувати транспортний номер користувача за

допомогою відповідного діалогового вікна програми.

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

застосувань на базі Windows в центрі даних компанії. Цей сервер застосувань міг

би реалізувати усю ділову логіку, щоб розпізнавати різні типи транспортних

номерів. Програма клієнта просто б зв'язувалася з сервером застосувань, а він вже

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

ЕОМ. Це дійсно усунуло б проблему модифікації, тому що тільки сервер

застосувань повинен був би модифікуватися, якби типи пропонованих послуг

змінилися.

Цей приклад хороший тим, що показує, як потрібно використати сервер

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

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

своїй роботі одночасно тисячі клієнтів. Викликається він дистанційно і виконує

корисну роботу. Клієнт і сам би міг мати на своїй машині цей модуль і усе для

нього, клієнта, було б набагато простіше. Але річ у тому, що клієнтів – 50000, а

модуль часто модифікується!

Усі інші аргументи на користь триланкової архітектури зводяться доки до

того, що вона краща, тому що вона краща, – мовляв на клієнтові нічого не

потрібно інсталювати, окрім інтерфейсів до віддаленого програмного сервера.

118

Але при цьому, проте, не видно ніякої особливої вигоди, якщо програмне

забезпечення, яке переноситься на сервер застосувань, рідко модифікується.

Завантаження мережі залишається тим же, а на сервер падає левова частка

проблем, пов'язаних з масовим обслуговуванням клієнтів, управлінням

транзакціями і відстежуванням черг.

 Що мається на увазі під технологіями ActiveX

ActiveX служить одній єдиній меті: забезпечувати функціонування

програмних компонентів усередині складених програмних контейнерів. Ці

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

ActiveX – технологія Microsoft, призначена для написання мережевих

застосувань. Оскільки самим напрямом, що динамічно розвивається, в

комп'ютерній індустрії є Інтернет, саме тут найприродніше можуть знайти своє

місце програми, написані з використанням технології ActiveX. He випадково

останнім часом поняття ActiveX і Інтернету часто зустрічаються поруч. В той же

час технологія ActiveX має значно більше універсальну сферу застосування.

Стандарт ActiveX дозволяє програмним компонентам взаємодіяти один з

одним по мережі незалежно від мови програмування, на якій вони написані. За

допомогою ActiveX можна "оживити" Web-сторінки ефектами мультимедіа,

інтерактивними об'єктами або складними застосуваннями. ActiveX забезпечує

деякі зв'язні засоби, за допомогою яких окремі програмні компоненти на різних

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

ActiveX включає в себе клієнтску і серверну частини, а також бібліотеки для

разробника.

 Керуючі елементи ActiveX (ActiveX Controls)

Що ж це таке насправді? Найбільш проста відповідь – ця нова назва для

керуючих  елементів OCX, або навіть для ще раніше них існуючих VBX. Будь-

який готовий або створений вами управляючий елемент OLE – це вже ActiveX-

елемент, який може використовуватися в програмах. Проте подібні OLE-елементи

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

119

Типовий недолік існуючих OLE-елементів – їх значні розміри. Це

обумовлено складністю структури OLE-інтерфейсів, а також тим фактом, що при

підготовці в Microsoft бібліотек, використовуваних для генерації управляючих

елементів, розміри їх не оптимізувалися. Якщо в системі користувача якийсь з

цих елементів відсутній, доводиться завантажувати його через інтернет, отже,

розмір управляючих елементів, Web-сторінок має бути якомога менше. З

технічної точки зору ActiveX-елемент – це деякий COM-об'єкт, через основний

OLE-інтерфейс якого, IUnknown, організовується доступ до інших інтерфейсів

цього об'єкту.

По суті за допомогою ActiveX-елементів програміст створює

високорівневий, придатний для багатократного використання об'єкт з деякою

корисною функцією. Потім цей елемент може бути переданий (чи проданий)

іншому програмістові, якому згодиться як деякий "будівельний блок". Більшість

програмних інструментальних систем, таких як Delphi, Visual Basic, Visual C++

підтримують засоби взаємодії з ActiveX-елементами. В ролі ActiveX-елементів

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

електронної таблиці. У продажі є тисячі таких елементів від різних

постачальників. Їх богаті функціональні можливості і різноманіття – окреме,

найбільш важливе достоїнство платформи ActiveX.

Можна запитати, а яке відношення це має до Інтернету і баз даних?

Відповідь i інтерпретації Microsoft звучатиме так: найпряміше і безпосереднє. За

своєю суттю платформа ActiveX – це адаптація існуючих технологій Microsoft

стосовно Web. По заявах Microsoft керуючі елементи ActiveX працюють швидше,

ніж Java-аплети. Складні функції можна додавати клацанням миші. Головне,

проте, не в тому, що ActiveX, як і Java-аплети, здатні оживити Web-сторінки.

Куди важливіше той факт, що управляючі елементи ActiveX, дозволяють

відвідувачам Web-вузла виконувати складні операції, отримувати потрібну

інформацію від баз даних і від застосувань, працюючих на інших серверах або

навіть на других Web-вузлах.

120

Оскільки ActiveX-файл є родичем VBX, він може використовуватися і в

звичайному Visual Basic, і в мові сценаріїв VBScript. У таблиці 1.12 перераховані

основні бібліотечні типи, що використовуються у Windows.

 

Таблиця 1.12 – Бібліотечні типи, використовувані в Windows

Управляючий

елемент

Роз

ши-

рення

Функція

Бібліотеки (Dynamic

link library), що динамічно

підключається

.dll Дозволяє користувачам діставати

доступ до функцій, підпрограм і ресурсів з

інших застосувань

Visual Basic .vb

x

Забезпечує той же призначений для

користувача сервіс, що і DLL. Може

застосовуватися в інтегрованих

середовищах розробки, таких як Visual

Basic 3.0, MSVC++ 1.52 і Delphi 1.0

ActiveX .OC

X

Забезпечує призначений для

користувача сервіс, такий же, як DLL, і

той же, що і VBX. На додаток, OCX є

більш функціональними і краще

використовує усі доступні йому ресурси.

Підтримується практично усіма відомими

RAD-системами

 

Охарактеризуємо коротко базові поняття і ключові об'єкти, з яких

будуються керуючі елементи ActiveX.

Контейнер і взаємодія з ним

Управляючий елемент ActiveX не може існувати сам по собі, він завжди

"живе" усередині свого контейнера і тісно взаємодіє з ним. Через властивості

оточення (ambient properties) об'єкт має доступ до інформації про поточний стан

121

свого "власника". Контейнер підтримує додаткові методи, властивості і події, які

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

Властивості оточення

Інформація про стан контейнера доступна ActiveX-елементу через об'єкт

AmbientProperties, посилання на який може бути отримане через властивість

Ambient об'єкту UserControl.

Наприклад, властивість UserControl.Ambient.BackCoior відображає поточне

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

ActiveX-елемента. Грамотно написаний ActiveX-елемент повинен поводитися

відповідно до поточного стану контейнера. Повідомлення

userControl_Ambientchanged сповіщає управляючий елемент ActiveX про зміну

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

Додаткові властивості

Додаткові властивості (extender properties) надаються контейнером, але

зовні виглядають як частину інтерфейсу елементів управління ActiveX. Розробник

ActiveX-елемента має доступ до додаткових властивостей через властивість

Extender об'єкту userControl. Специфікація елементів управління ActiveX вимагає,

щоб усі контейнери підтримували  Наступні  Додаткові  властивості:   Name,   

Visible,    Parent,    Cancel Default. Для доступу до додаткових властивостей завжди

використовується механізм пізнього зв'язування (late - bound), оскільки на момент

компіляції невідомо, з яким контейнером належить працювати ActiveX-елементу.

Коли користувач звертається до властивості (методу) ActiveX control, то

першим управління отримує об'єкт Extender. Якщо він не підтримує цю

властивість (метод), то викликається обробник ActiveX Controls.

Об’єкт UserControl

ActiveX-елемент, створений на Visual Basic, завжди містить (агрегує) об'єкт

userControl. Розміщення і налаштування властивостей складових (constituent)

ActiveX-елемента проводиться за допомогою редактора властивостей.

Об'єкт userControl має стандартний інтерфейс. Ви можете написати свої

обробники для подій, генерованих цим об'єктом, надати для використання або

122

перевизначити стандартні властивості. Так само ваш ActiveX-елемент може

експортувати методи, властивості і події складових компонентів.

Ключові події

В процесі свого існування ActiveX-елемент отримує сповіщення про ряд

подій, генерованих об'єктом UserControl. Найбільш важливими є:

initialize.   Найперша  подія,  завжди  відбувається  при 

створенні ActiveX-елемента. У цей момент об'єкт ще не має зв'язку зі своїм

контейнером.

initProperties. Ця подія сповіщає про розміщення нового

ActiveX-елемента у формі. У момент його приходу вбудований об'єкт вже має

зв'язок зі своїм контейнером. Як правило, обробник події виконує початкову

ініціалізацію властивостей ActiveX-елемента.

ReadProperties. При завантаженні форми (як у DesignMode, так

і в RunMode) вбудовані в неї елементи створюються наново і їх властивості

ініціалізувалися значеннями, збереженими у файлі з розширенням .frm. Подія

ReadProperties  сповіщає ActiveX-елемент про  необхідність  виконати

ініціалізацію. У цей момент об'єкт має зв'язок зі своїм контейнером.

 CORBA и Enterprise JavaBeans – лідери найновіших технологій. Навіщо

потрібна CORBA

Відразу обмовимося, що під CORBA ми розумітимемо CORBA/IIOP, тому

що сама специфікація CORBA не стандартизує мережевий протокол передачі

даних між клієнтом і сервером. Кожен виробник брокера об'єктних запитів, який,

по суті і є CORBA, може запропонувати власний протокол транспортної служби

передачі даних. Проте для забезпечення інтероперабельності брокерів запитів від

різних виробників OMG (Object Management Group – міжнародна некомерційна

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

створенням програмного забезпечення) розробив загальний протокол GIOP. Його

відображення в TCP/IP дістало назву протоколу Internet Inter ORB Protocol (IIOР).

Завдяки цьому, будь-яке застосування CORBA/IIOP повинне працювати і

123

взаємодіяти з іншими CORBA/IIOP-додатками незалежно від платформ,

виробників програмного забезпечення і операційних систем.

CORBA (Common Object Request Broker Architecture) – це технологія для

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

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

Так от, CORBA – це архітектура, яка з максимальними зручностями забезпечує

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

багато RAD-системи: Delphi, включають у свій арсенал підтримку CORBA.

Втім, традиційні RAD-системи, подібні Visual Basic, не потребують

CORBA, тому що орієнтуються на наявний в Microsoft власний брокер об'єктних

запитів, існуючий під іменем DCOM. Надалі виробникам програмних продуктів

для програмістів стане все важче і важче підтримувати обидві технології. Delphi-

програмісти можуть заспокоювати себе тим, що є можливість працювати і з

CORBA, і з DCOM.

Звичайно ж, CORBA – більше масштабований, відкритіший і грандіозніший

проект, ніж DCOM. CORBA розглядає вже існуючі застосування, як деякі

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

описавши їх інтерфейси за допомогою спеціальної мови описів IDL (Interface

Definition Language – мова опису запитів), для якого існують компілятори у

більшість сучасних мов програмування. CORBA є прообразом нашого об'єктного

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

програмісти усіх країн по мільйону разів переписують наново один і той же

алгоритм, якщо він вимагає внесення деяких невеликих змін. Навіщо?

Адже у будь-якому випадку, безумовно, існує кращий варіант того

фрагмента програмного коду, який переписується із самого початку людьми, ніби

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

пішли інженери комп'ютерних систем? Та тому, що вони вже дуже давно

використовують об'єктну технологію у вигляді незмінних конструкторських

елементів ("чіпів"). А програмісти по-старому розпочинають з пісочку: спочатку

124

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

вже потім з тієї цегли побудуємо конструкцію. Кустарне виробництво.

Що означають об'єктні технології в програмуванні, і не лише в

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

панування Мережі? Ми вимушені визнати, що сучасне виробництво начисто

позбавлене індивідуалізму і визнає тільки те, що може бути розмножене.

Найкращим варіантом вважається той, який ви не створюєте, а лише настроюєте,

компонуючи його з різного набору об'єктів, описуючи їх властивості і задаючи

різні методи, що виконують той або інший вид роботи. Виграш продуктивності

виходить колосальний. У всьому панує єдиний принцип – повторне використання

компонентів. Ваша праця, якщо ви є творцем нових інформаційних об'єктів і

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

об'єкт: процес або програму, які можуть використати інші клієнти і об'єкти з

метою використання ваших методів, якщо вони містять в собі щось нове,

незалежно від ваших бажань, місцезнаходження і часу.

Звичайно, було б ідеально, якби повторно використовувані об'єкти самі б не

були об'єктами, а їх творець мав права на плоди своєї творчості. Але ж неможливо

уявити собі, що б творець якого-небудь об'єкту творив у вакуумі, він усього лише

наслідує структуру якого-небудь опису, якого-небудь шаблону, класу або групи

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

оформляються на універсальній мові програмування в JavaBeans або в ActiveX, те

ж, по суті, відбувається і з авторськими текстами, що перетворюються не на

індивідуальні плоди творчості, а в один нескінченний і універсальний коментар.

Який сенс наново описувати те, що вже одного разу описано? Проте це робиться, і

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

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

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

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

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

статус анонімності. Використовуються вже не повноцінні імена, а усього лише

125

ідентифікатори, не індивідуальні паролі, а сертифікати. Творців не може бути

надто багато. Врешті-решт єдиним творцем усього стає сама Мережа.

У цих умовах розмови про авторські права стають просто смішні. Ніхто

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

невід'ємною рисою систем об'єктних реалізацій. Ви просто оголошуєте себе

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

текстів і модифікуєте їх відповідно до своїх установок. Творець набуває себе

усього лише у витяганні нових сенсів із старих конструкцій – форм і інструментів

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

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

собі перевизначені ключові системні і смислові блоки, так що вони стають

поліморфними, т. е. поводяться і представляються абсолютно по-різному, залежно

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

Приклади абсолютно прості: ви включаєте свій телевізор таким самим

способом, як праску, електропіч або настільну лампу. Усі предмети, що

відносяться до класу "Прилад", містять метод "включити", але в процесі

включення, залежно від типу приладу (підкласу), єдиний метод "включити"

поводиться поліморфно, тобто викликає абсолютно різні електричні і блокові

функції: для праски – одні, для телевізора – інші. Можна так перевизначити класи

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

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

поліморфно. Більше того, існують програмні засоби (Java+XML), які здатні

динамічно модифікувати контент. Попри те, що Java і XML самі по собі досить

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

прості і приємні, бо вони відводять його від необхідності знати внутрішні

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

управління ними.

Точно так, як і він зараз управляє своїм телевізором, не замислюючись про

його технічний склад, в майбутньому, завдяки новим, усе більш досконалим

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

126

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

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

властивостями. Вони самі, будучи підключені до електронних систем,

неодноразово дефиніюють (перевизначають) свої інформаційні запити до

ресурсів, які система запам'ятовує і згодом використовує. Завжди, як тільки

людина вступає у взаємодію з програмованими об'єктами, він сам стає об'єктом,

він сам стає програмованим.

Для постмодерністської епохи, завершенням якої є Інтернет, цінності в

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

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

залишилася лише електрика. Безглуздо заявляти свої права на конструкції, які

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

точка відліку – Мережа. Сучасні люди вже не здатні круто змінити парадигму

свого існування. Творчість в епоху Інтернету є витяганням усе нових і нових

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

Сила CORBA в тому, що це система, що самоописується і

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

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

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

обмежене, способи існування і місцезнаходження об'єктів жорстко не визначені.

Будь-який об'єкт може бути затребуваний іншим об'єктом або програмою в

довільній точці Мережі, і це дуже сильно нагадує телепортацію.

Архітектура CORBA.

Чотири головні елементи CORBA архітектури показані на рис. 1.16.

Брокер об'єктних запитів (ORB – Object Request Broker)

визначає механізми взаємодії об'єктів в різнорідній мережі. Посередник об'єктних

запитів, ORB, або просто брокер, – це логічне ядро системи. Саме він дозволяє

об'єктам посилати запити і отримувати відповіді від інших об'єктів в мережі. ORB

– це проміжне програмне забезпечення, яке встановлює відношення між об'єктами

в розподіленому середовищі. Брокер по посиланню знаходить на сервер, що

127

містить об'єкт-адресат (object implementation – реалізація об'єкту); активізує його,

доставляє до нього запит; передає параметри і викликає відповідний метод, після

чого повертає результат клієнтові. Ролі клієнта і сервера при цьому можуть

мінятися. Взаємодія може бути встановлена між безліччю об'єктів. OMG розробив

спеціальну мову верхнього рівня для опису ORB і інших компонентів CORBA –

так званий IDL (Interface Definition Language – мова опису інтерфейсів). У ній

немає присвоєнь,    звичайних    мовних    конструкцій,    типу    if    чи    while,

функцій і логічних переходів і т. д. IDL – це мова декларацій, вона описує

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

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

IDL і CORBA. У цьому і привабливість – можна змусити працювати старі

програми, якщо правильно описати їх інтерфейси і використати компілятор з IDL,

який має відображення в конкретну мову програмування. Важливо зрозуміти, що

є два типи інтерфейсів: динамічні і статичні. Перші визначаються на стадії

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

момент виконання, на працюючому застосуванні.

Сервіси  об'єктів  (Object  Services)  є  основними  системними

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

Універсальні засоби (Common Facilities) є також системними

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

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

Прикладні об'єкти  (Application  Objects)  використовуються 

в конкретних прикладних завданнях.

Так, все-таки, навіщо потрібна CORBA?

 

128

Рисунок 1.16 – Головні елементи CORBA

 

Розподілені застосування

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

розподілених застосувань. Але виникає нове питання – а навіщо взагалі потрібний

цей розподіл? Як тільки ви зіткнетеся з ним, то побачите перед собою величезну

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

вимагають бути розподіленими з наступних причин:

дані, використовувані застосуванням, – розподілені;

обчислення – розподілені;

користувачі застосування – розподілені.

Розподілені дані

Деякі застосування повинні виконуватися на безлічі комп'ютерів, тому що

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

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

локальні. Такі історичні (чи інші) причини, що визначають розподілену

організацію даних.

Розподілені обчислення

Деякі застосування виконуються на безлічі комп'ютерів, щоб скористатися

перевагою паралельного обчислення для вирішення специфічних завдань,

наприклад, пов'язаних з дешифруванням. Інші застосування також можуть

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

специфічних систем для реалізації різних частин свого алгоритму. Розподілені

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

неоднорідності розподіленої системи.

Розподілені користувачі

Деякі застосування розподілені по безлічі комп'ютерів, тому що користувачі

зв'язуються і взаємодіють один з одним через це застосування. Кожен користувач

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

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

129

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

цього виду застосувань ілюструється на рис. 1.17.

Як вже говорилося, CORBA є ідеальною архітектурою для створення таких

застосувань. Актуальність її в наші дні активно затребувана розвитком Інтернету і

систем електронної комерції, де багато функцій має бути розподілені по мережі і

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

ActiveX, або JavaBean-компонентів.

Брокер об'єктних запитів, ORB, ставить запит об'єкту і повертає будь-який

результат клієнтові (рис. 1.18).

 

Рис1нок 1.17 – Розподілені користувачі

Рисунок 1.18 – Механізм взаємодії: клієнт запитує об'єкт через посередника ORB

 

Від клієнта до сервера

Оскільки CORBA є стандартом для створення розподілених застосувань,

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

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

залежністю від місцезнаходження, мови і архітектури.

130

Можна чітко сформулювати ключові особливості CORBA-стандарту:

CORBA-об’єкти можуть знаходитись в будь-якому месці

мережі;

CORBA-об’єкти можуть взаємодіяти з іншими CORBA -

объектами на будь-яких платформах;

CORBA-об’єкти можуть бути написані на будь-якій мові

програмування, для якого є інтерфейс, що реалізовується IDL-компілятором (такі

є для Java, C++, C, SmallTalk, COBOL і Ada).

Використовуючи CORBA,можна створювати розподілені системи, де різні

компоненти (інтерфейси користувачів, бізнес-алгоритми, доступ до баз даних і т.

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

Кожен компонент зв'язуватиметься з іншим тільки через оголошений інтерфейс.

При цьому можна відлагоджувати і підтримувати частини програм окремо.

 

Рисунок 1.19 – Архітектура CORBA-сумісного застосування, що викликає безліч

об'єктів з безлічі комп'ютерів

 

Клієнтська частина CORBA

Коли CORBA-сумістний об'єкт використовує метод, що знаходиться в

іншому об'єкті, він викликає стаб (stub), тобто деяку порожню оболонку

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

stub-файлі. Цей стаб використовує локальний ORB, посилає запит і отримує 131

відповідь. Об'єкту немає ніякої необхідності знати подробиці відносно ORB або

дійсного місцезнаходження сервера. Усі CORBA-клієнти і сервери з'єднуються

через брокерів ORB, використовуючи їх як посередників.

JDK містить ORB, який дозволяє створювати CORBA-сумісні програми на

Java.

Клієнтський стаб створюється при першому визначенні серверного

інтерфейсу в клієнтові за допомогою мови визначення інтерфейсів IDL. CORBA

IDL визначає тип об'єкту, його методи, властивості і т. д. CORBA IDL – це

абсолютно нейтральна і чисто декларативна мова.

Стаб потім використовує локальний ORB, посилає запит і отримує

відповідь. ORB надає своєрідну шину для проходження обміну структурованими

даними. Ця шина використовує IIOP як транспортний протокол між брокерами

ORB.

 Серверна частина CORBA

При витяганні запиту IIOP сервер ORB використовує так званий

Basic Object Adapter (BOA) в комбінації з депозитарієм виконання (Implementation

Repository – набором конкретних класів і бібліотек, наявних на сервері) для

передачі параметрів запиту до необхідного серверного об'єкту через серверний

стаб. Іноді запитують – навіщо так складно? Відповідь проста, щоб легше було

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

на вирішенні системних питань, пов'язаних з мережевою специфікою і

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

в точності так само, як він не замислюється про внутрішній устрій телефонної

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

Basic Object Adapter BOA – це набір системних сервісів ORB

для встановлення з'єднання з серверними об'єктами по їх ідентифікаторах

(об'єктні посилання).

Server IDL Stub Служить для забезпечення інтерфейсу до

кожного сервісу. На серверній стороні такої стаб, щоб відрізнити його від

клієнтського стаба, називається скелетон.

132

Implementation Repository Це набір класів на стороні сервера,

доступний усім розподіленим клієнтам через систему об'єктних посилань.

Сервіси CORBA

Важливою частиною стандарту CORBA є визначення набору розподілених

послуг (сервіси CORBA), щоб підтримувати інтеграцію і взаємодію розподілених

об'єктів. Вони визначені як стандартні об'єкти CORBA з інтерфейсами IDL і іноді

ще згадуються як об'єктні сервіси (рис. 1.20).

 

Рисунок 1.20 – Об'єктні сервіси

 

Є безліч CORBA-сервісів. Найпопулярніші з них наведені в таблиці 1.13.

 

Таблиця 1.13 – Найбільш популярні сервіси CORBA

Сервіс Опис

Життєвий цикл об’єкта

(Object life cycle)

Визначає, яким чином CORBA-об’єкти будуть

створені, видалені, переміщені або скопійовані

Іменування (Naming) Визначає спосіб символічного позначення CORBA -

объектов

Події (Events) Обробка подій

Відношення

(Relationships)

Визначають стосунки  між об'єктами  (головний,

підлеглий, зв'язковий і т. д.)

Перетворення об'єктів з

однієї форми в іншу

(Externalization)

Координує перетворення об'єктів із зовнішніх форм у

внутрішні і навпаки

Транзакції Координують доступ до CORBA-об’єктів

133

(Transactions)

134

Продовження таблиці 1.13Контроль доступу

(Concurrency Control)

Забезпечує обслуговування блокування об'єктів

CORBA

Властивість (Property) Підтримує   асоціацію   пари :   ім'я-значення для

об'єктів CORBA

Продавець (Trader) Підтримує  пошук  CORBA-об’єктів,   заснований на

афішованих властивостях об'єкту

Запрос (Query) Підтримка запитів до об'єктів

 

CORBA-продукти

Не забувайте, що CORBA – це усього лише специфікація. Що стосується

програмних виробів, що реалізовують архітектуру CORBA, то їх є множина.

Окремі продавці забезпечують свої брокери CORBA і IDL для відображення в

різні мови програмування. Усі вони зобов'язані підтримувати Java. У таблиці. 1.14

приведені найбільш відомі реалізації CORBA.

 

Таблиця 1.14 – Найбільш відомі реалізації CORBA

ORB Опис

Java ORB Java 2 ORB поставляється у складі   Sun's Java SDK. Там

відсутні деякі особливості повної специфікації

VisiBroker

for Java

Популярний Java ORB з Inprise Corporation. VisiBroker

вбудований у багато інших продуктів. Приміром, саме він був

вбудований у браузер Netscape Communicator.

OrbixWeb Добротний Java ORB з lona Technologies (для Unix)

WebSphere Потужний сервер застосувань зі вбудованим ORB від

IBM

Free or

shareware ORBs

CORBA-реалізації для різних мов програмування

доступні для завантаження по мережі Інтернет з різних

джерел

135

2 ПАРАЛЕЛЬНІ ОБЧИСЛЮВАЛЬНІ МЕТОДИ

Побудова паралельних обчислювальних систем, аналіз і моделювання

паралельних обчислень.

Шляхи досягнення паралелізму. Під паралельними обчисленнями

розуміють процеси обробки даних, в яких комп’ютерна система одночасно

здійснює декілька операцій. Досягнення паралелізму можливе за умови виконання

наступних вимог до архітектурних принципів побудови обчислювального

середовища:

- незалежність функціонування окремих пристроїв ЕОМ - ця вимога

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

введення-виведення, обробляючим процесорам, пристроям пам’яті);

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

надлишковості може здійснюватися у таких формах: використання

спеціалізованих пристроїв (окремі процесори для цілочислової та дійсної

арифметики, пристрої багаторівневої пам’яті - регістри, кеш); дублювання

пристроїв ЕОМ шляхом використання декількох однотипних обробляючих

процесорів чи кількох пристроїв оперативної пам’яті.

Окремою формою забезпечення паралелізму може бути конвеєрна

реалізація обробляючих пристроїв, коли виконання операцій в пристроях

представляється як виконання послідовності складових операції команд. В

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

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

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

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

декількох процесів використовується єдиний процесор. Такий режим є

псевдопаралельним, коли активним, виконуваним, може бути один єдиний

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

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

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

136

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

іншого процесу, готового до виконання. В цьому режимі з’являються багато

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

синхронізації процесів, та ін.), та, як результат, цей режим можна використати за

умови початкової підготовки паралельних програм;

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

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

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

конвеєрних та векторних пристроїв оброблення;

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

паралельної обробки даних, коли використовуються декілька пристроїв

оброблення, достатньо віддалених один від одного, коли передача даних за

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

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

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

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

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

декількох окремих ЕОМ з використанням каналів зв’язку локальних чи

глобальних інформаційних мереж.

Далі розглядатимемо другий тип організації паралелізму, який реалізується

у багатопроцесорних обчислювальних системах.

Приклади паралельних обчислювальних систем. Розмаїття паралельних

обчислювальних систем величезне. Кожна така система унікальна, в кожній з них

встановлюються різні апаратні складові: процесори (Intel, Power, AMD, HP, Alpha,

Nec, Cray, та ін.), мережеві карти (Ethernet, Myrinet, Infiniband, SCI,...). Вони

функціонують під управлінням різних операційних систем (версії Unix/Linux,

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

Видається, що практично неможливо знайти між ними щось спільне, що не так.

Далі будуть сформульовані варіанти класифікацій паралельних обчислювальних

систем. Розглянемо декілька прикладів.

137

Суперкомп’ютери. Початком ери суперкомп’ютерів вважається 1976 різ з

появою векторної системи Cray 1. Результати, показані цією системою на

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

з іншими, тому система отримала назву "суперкомп’ютер" і протягом тривалого

часу вона визначала розвиток всієї індустрії високопродуктивних обчислень.

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

ринку стали з’являтися системи з кардинально різними характеристиками, тому

поняття "суперкомп’ютер" стало багатозначним і неодноразово переглядалися.

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

продуктивність, не зворотно приводять до необхідності постійно переглядати таку

позицію. З альтернативних означень найбільш цікаві два: економічне та

філософське. Перше означає, що суперкомп’ютер - це система, ціна якої вища за 1

- 2 млн. доларів США, друге - що суперкомп’ютер - це комп’ютер, потужність

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

Програма ASCI. Програма ASCI (http://www.llnl.gov/asci/) - Accelerated

Strategic Computing Initiative, яка підтримується Міністерством енергетики США,

в якості однієї з основних цілей - створення суперкомп’ютерів з продуктивністю в

100 TFlops (Терафлопс, означає 1 трильйон операцій за секунду). Перша система

серії ASCI - ASCI Red, створена в 1996 р. компанією Intel, стала першим в світі

комп’ютером з продуктивністю в 1 TFlops, яка надалі була доведена до 3 TFlops.

Трьома роками пізніше з’явилися ASCI Blue Pacific від IBM та ASCI Blue

Mountain від SGI, які стали першими на той час суперкомп’ютерами з швидкодією

3 TFlops. В червні 2000 р. була введена в дію система ASCI White

(http://www.llnl.gov/asci/platforms/white/) з піковою продуктивністю вище за 12

TFlops, реальна продуктивність на тесті LINPACK скала 4938 TFlops, пізніше цей

показник був доведений до 7304 TFlops. Апаратно ASCI White є системою IBM

RS/6000 SP з 512 симетричними мультипроцесорами (SMP) вузлами. Кожний

вузол має 16 процесорів, система в цілому - 8192 процесорів. Оперативна пам’ять

системи складає 4 ТВ, ємність дискового простору складає 180 ТВ. Всі вузли

системи є симетричними мультипроцесорами IBM RS/6000 POWER 3 з 64 -

138

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

операційну систему, локальний диск та 16 процесорів. Процесори POWER 3 є

суперскалярними 64 - розрядними числами конвеєрної організації з двома

пристроями з обробки команд з плаваючою комою та трьома пристроями з

обробки цілочислових команд. Вони здатні виконувати до 8 команд за тактовий

цикл та до 4 операцій з плаваючою комою за такт. Тактова частота кожного

такого процесора 375 MHz.

Програмне забезпечення ASCI White підтримує мішану модель

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

всередині SMP - вузла. Операційна система є версією Unix - IBM AIX. AIX

підтримує як 32 -, так і 64 - розрядні системи RS/6000. Підтримка паралельного

коду на ASCI White включає паралельні бібліотеки, налагоджування, зокрема

TotalView), профілювання, утиліти IBM та сервісні програми з аналізування

ефективності виконання. Підтримуються бібліотеки MPI, OpenMP, потоки POSIX

та транслятор директив IBM. Є паралельне налагодження IBM.

Система BlueGene. Один з найпотужніших нині суперкомп’ютерів у світі

створений фірмою IBM, роботи в цьому напрямку продовжуються донині. На

даний час система називається "BlueGene/L DD2 beta-System", вона є першою

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

в дію в роботу її пікова продуктивність досягне 360 TFlops. Основні напрямки

застосування є гідродинаміка, квантова хімія, моделювання клімату, та ін.

Поточний варіант системи має такі характеристики: 32 стійки по 1024 двох

ядерних 32-бітних процесори PowerPC 440 з тактовою частотою 0.7 GHz; пікова

продуктивність - порядку 180 TFlops; максимально показана продуктивність (на

тесті LINPACK) - 135 TFlops.

MBC - 1000. Один з найпотужніших в РФ суперкомп’ютерів -

Багатопроцесорна обчислювальна система МВС-1000М встановлена у в

Міжвідомчому супекомп’ютерному центрі РАН, роботи з його створення

проводилися з 2000 до 2001рік. Склад системи такий: 384 двох процесорних

модулі на базі Alpha 21264 з тактовою частотою 667 MHz (кеш L2 - 4 Mb), зібрані

139

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

сервер NetApp F840; мережі Myrinet 2000 та Fast/Gigabit Ethernet; мережевий

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

по 2 Gb оперативної пам’яті, HDD 20 GB, мережеві карти Myrinet (2000 Mbit). при

обміні даними між модулями з використанням протоколів МР1 на мережі Myrinet

пропускна здатність в МВС-1000М складає 110-150 Mb в секунду.

Кластер AC3 Velocity Cluster. Цей кластер встановлений в Корнельському

університеті США є результатом сумісної діяльності університету та консорціуму

АС3 (Advanced Cluster Computing Consortium), утвореного компаніями Dell, Intel.

Microsoft, Giganet та ще 15 виробників ПЗ з метою інтеграції різних технологій

для створення кластерної архітектури для навчальних та державних установ.

Склад кластера: 64 чотирьох процесорних сервери Dell PowerEdge 6350 на базі

Intel Pentium III Xeon MHz, 4 GB HDD, 100 MBit Ethernet card; 1 восьми

процесорний сервер Dell PowerEdge 6350 на базі Intel Pentium III Xeon 550 MHz, 8

GB RAM, 36 GB HDD, 100 MBit Ethernet card.

Чотирьох процесорні сервери змонтовані по вісім штук на стійку і

працюють під управлінням ОС Microsoft Windows NT 4.0 Server Enterprise Edition.

Між серверами встановлено з’єднання на швидкості 100 Мбайт/с через Cluster

Switch компанії Giganet.

Завдання в кластері управляються з використанням Cluster ConNTroller,

створеного в Корнельському університеті. Пікова продуктивність АС3 Velocity

складає 122 GFlops з вартістю в 4-5 меншою, порівняно з суперкомп’ютерами з

аналогічними показниками. На момент виходу в дію, в 2000 році, кластера з

показниками на тесті LINPACK в 47 GFlops займав 381 стрічку в списку Top 500.

Кластер NCSA NT Supercluster. В 2000 році в Національному центрі

суперкомп’ютерних технологій (NCSA - National Center for Supercomputing

Applications) на основі робочих станцій Hewlett-Packard Kayak XU PC workstation

(http://www.hp.com/desktops/kaeak/) був зібраний ще один кластер, для якого була

вибрана операційна система OC Microsoft Windows. Розробники назвали його NT

Supercluster (http://archive.ncsa.uiuc.edu/SCD/Hardware/NTCluster/). На момент

140

введення в дію кластер з показником на тесті LINPACK в 62 GFlops та піковою

продуктивністю в 140 GFlops займав 207 стрічку списку Top 500. Кластер

побудований з 38 двох процесорних серверів на базі Intel Pentium III Xeon 550

MHz, 1 Gb RAM, 7.5 Gb HDD, 100 MBit Ethernet card. Зв’язок між вузлами

базується на мережі Myrinet (http://www.myri.com/murinet/index.html). Програмне

безпечення кластера: операційна система - Microsoft Windows NT 4.0;

компілятори - Fortran77, C/C++; рівень передачі повідомлень базується на HPVM

(http://www-csag.ucsd.edu/projects/clusters.html).

Кластер Thunder. Нині чисельність систем, зібраних на основі процесорів

корпорації Intel, які представлені в списку Top 500, складає 318. Самий потужний

суперкомп’ютер, який представляє собою кластер на основі Intel Itanium2,

встановлений в Ліверморській національній лабораторії (США). Апаратна

конфігурація кластера Thunder (http://www.llnl.gov/linux/thunder/); 1024 сервери,

по 4 процесори Intel Itanium 1.4GHz в кожному; 8 Gb оперативної пам’яті на

вузол; загальна місткість дискової системи 150 Tb. Програмне забезпечення:

операційна система CHOS 2.0; середовище паралельного програмування MPICH2;

налагоджування паралельних програм TotalView; Intel та GNU Fortran, C/C++

компілятори. Нині кластер Thunder займає 5 позицію списку Top 500 (на момент

встановлення - влітку 2004 року він займав 2 стрічку) з піковою продуктивністю

22938 GFlops і максимально показаною на тесті LINPACK 19940 GFlops.

Класифікація обчислювальних систем.

Найпоширенішим способом класифікації ЕОМ є систематика Флінна

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

увага способам взаємодії способам взаємодії послідовностей (потоків)

виконуваних команд та оброблюваних даних В рамках цього підходу

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

- SISD (Single Instruction, Single Data) - системи, в яких існує одиночний

потік команд та одиночний потік даних. До такого типу можна віднести звичайні

послідовності ЕОМ;

- SIMD (Single Instruction, Multiple Data) - системи з одиночним потоком

141

команд та множинним потоком даних. Подібний клас складають

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

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

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

пристроєм управління. Цей підхід використовувався в попередні роки (системи

ILLIAC IV чи СМ-1 компанії Thinking Machines), останнім часом його

застосування обмежено, в основному, створенням спеціалізованих систем;

- MISD (Multiple Instruction, Single Data) - системи, в яких існує множинний

потік команд та одиночний потік даних. Стосовно цього типу систем немає єдиної

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

відповідають цьому типу обчислювальних систем, не існує і введення такого

класу застосовується для повноти класифікації; інші спеціалісти відносять до

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

конвеєрною обробкою даних;

- MIMD (Multiple Instruction, Multiple Data) – системи з множинним

потоком команд та множинним потоком даних. До подібного класу відноситься

більшість паралельних багатопроцесорних обчислювальних систем.

Систематика Флінна широко використовується при конкретизації типів

комп’ютерних систем, але вона призводить до того, що практично всі типи

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

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

систематики Флінна. Для класу MIMD запропонована загальновизнана

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

базується на використовуваних способах організації оперативної пам’яті в цих

системах. Такий підхід дає змогу розрізнити два важливих типи

багатопроцесорних систем - multiprocessors (мультипроцесори чи системи з

спільною пам’яттю, що розділяється) та multicomputers (мультикомп’ютери чи

системи з розподіленою пам’яттю).

Мультипроцесори. Для подальшої систематики мультипроцесорів

враховується спосіб побудови спільної пам’яті. Перший можливий варіант -

142

використання єдиної, централізованої, спільної пам’яті (shared memory). Такий

підхід забезпечує однорідний доступ до пам’яті (uniform memory access чи UMA )

і є основою для побудови векторних паралельних процесорів (parallel vector

processor чи PVP) та симетричних мультипроцесорів (symmetric multiprocessor чи

SMP). Прикладами першої групи є суперкомп'ютер Cray T90, другої - IBM

eServer, SunStarFire, HP Superdome, SGI Origin та ін. Однією з основних проблем,

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

різних процесорів до спільних даних та забезпечення, у зв’язку з цим,

однозначності (когерентності) вмісту різних кешів (cache coherence problem). Це

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

можуть виявитися і кешах різних процесорів. Якщо за таких обставин, за

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

розділеної змінної, то значення копій в кешах інших процесорів виявляться

такими, що не відповідають дійсності і їх використання призведе до

некоректності обчислень. Забезпечення однозначності кешів реалізується на

апаратному рівні - для цього після зміни спільної змінної всі копії цієї змінної в

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

обов’язкового звертання до основної пам’яті. Необхідність забезпечення

когерентності призводить до деякого зниження швидкості і ускладнює створення

систем з достатньо великою кількістю процесорів.

Наявність спільних даних при паралельних обчисленнях приводить до

необхідності синхронізації взаємодії одночасно виконуваних потоків команд. Так

якщо зміна спільних даних потребує для свого виконання певної послідовності

дій, то необхідно забезпечити взаємне виключення (mutual exclusion), щоб ці

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

Задачі взаємного виключення та синхронізації відносяться до числа класичних

проблем, і їх розгляд при розробці паралельних програм є одним з основних

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

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

буде однаковою для всіх елементів пам’яті). Такий підхід іменується

143

неоднорідним доступом до пам’яті (non-uniform memory access чи NUMA). Серед

систем з таким типом пам’яті виділяють: а) системи, в яких для надання даних

використовується тільки локальна кеш-пам’ять наявних процесорів (cache-only

memory architecture чи COMA); прикладами є KSR-1 та DDM; б) системи, в яких

забезпечується когерентність локальних кешів різних процесорів (cache-coherent

NUMA чи CC-NUMA); серед таких систем: SGI Origin 2000, Sun HPC 10000,

IBM/Sequent NUMA-Q2000; в) системи, в яких забезпечується спільний доступ до

локальної пам’яті різних процесорів без підтримки на апаратному рівні

когерентності кешу (non-cache coherent NUMA чи NCC-NUMA); наприклад,

система Cray T3E.

Використання розподіленої спільної пам’яті (distributed shared memory чи

DSM) спрощує проблеми створення мультипроцесорів (відомі приклади систем з

кількома тисячами процесорів), проте проблеми ефективного використання

розподіленої пам’яті (час доступу до локальної та віддаленої пам’яті може

різнитися на декілька порядків) приводить до істотного підвищення складності

паралельного програмування.

Мультикомп'ютери. Це багатопроцесорні системи з розподіленою

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

пам’яті (no-remote memory access чи NORMA). Незважаючи на всю схожість

подібної архітектури з системами з розподіленою спільною пам’яттю,

мультикомп'ютери мають принципову відмінність: кожний процесор системи

може використовувати тільки свою локальну пам’ять, в той час як для доступу до

даних, розташованих на інших процесорах, слід явним чином виконати операції

передачі повідомлень (message passing operations). Такий підхід застосовується за

умови побудови двох важливих типів багатопроцесорних обчислювальних систем

- масивно-паралельних систем (massively parallel processor) та кластерів (clusters).

Серед представників першого типу систем - IBM RS/6000 SP2, Intel PARAGON,

ASCI Red, трансп’ютерні системи Parsytec та ін.; прикладами кластерів є,

наприклад, системи AC3 Velocity та NCSA NT Supercluster. Характеристикою

обчислювальних систем кластерного типу є надзвичайно швидкий розвиток

144

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

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

програмних засобів забезпечується можливість уніфікованого управління (single

system image), надійного функціонування (availability) та ефективного

використання (performance). Кластери можуть бути утворені на основі вже

наявних у споживачів окремих комп’ютерів або ж сконструйовані з типових

комп’ютерних елементів, що не потребує істотних фінансових витрат.

Застосування кластерів може певною мірою усунути проблеми, пов’язані з

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

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

порівняно невеликої кількості (декілька десятків) окремих комп’ютерів (lowly

parallel processing). Тобто для паралельного виконання в алгоритмах розв’язку

обчислювальних задач достатньо виділити тільки крупні незалежні частини

розрахунків (coarse granularity), що в свою чергу, знижує складність побудови

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

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

кластера за допомогою передачі повідомлень приводить до значних часових

затримок, що накладає додаткові обмеження на тип розроблюваних паралельних

алгоритмів та програм. Звертається увага на відмінність поняття кластера від

мережі комп’ютерів (network of workstations чи NOW).

Для побудови локальної комп’ютерної мережі використовують більш прості

мережі передачі даних (порядку 100 Мбіт/сек). Комп’ютери мережі більше

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

додаткових робіт. Слід зауважити, що існують також інші способи класифікації

обчислювальних систем.

Приклади топології мережі передачі даних. Структура ліній комутації між

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

визначається, як правило, з врахуванням можливостей ефективної технічної

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

інтенсивності інформаційних потоків при паралельному вирішенні

145

найпоширеніших обчислювальних задач. До числа типових топологій зазвичай

відносять такі схеми комунікації процесорів (рис. 2.1):

1) Повний граф 2) Лінійка

3) Кільце 4) Зірка

5) 2 - вимірна решітка 6) 3 - вимірна решітка

Рисунок 2.1 – Приклади топології багатопроцесорних обчислювальних

систем

- повний граф (completely-connected graph або clique) - система, в якій між

будь-якою парою процесорів існує пряма лінія зв’язку. Така топологія забезпечує

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

умови великої кількості процесорів;

- лінійка (linear array або farm) - система, в якій всі процесори

перенумеровані по порядку і кожний процесор, окрім першого і останнього, має

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

Така схема є такою, що реалізується просто, а з іншого боку, відповідає структурі

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

організації конвеєрних обчислень;

146

- кільце (ring) - ця топологія отримується з лінійки процесорів з’єднанням

першого і останнього процесорів лінійки;

- зірка (star) - система, в якій всі процесори мають лінії зв’язку з певним

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

централізованих схем паралельних обчислень;

- решітка (mesh) - система, в якій граф ліній зв’язку утворює прямокутну

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

вона може бути ефективно використана при паралельному виконанні багатьох

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

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

- гіперкуб (hypercube) - ця топологія є окремим випадком структури

решітки, коли за кожною розмірністю сітки є тільки два процесори (тобто

гіперкуб містить 2N процесорів при розмірності N). Такий варіант організації

мережі передачі даних поширений на практиці і характеризується таким рядом

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

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

гіперкубі кожний процесор зв’язаний рівно з N сусідами; N - вимірний гіперкуб

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

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

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

процесорів (ця величина називається відстанню Хеммінга).

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

системи в багатьох випадках використовують комутатор (switch), через який

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

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

Одночасність виконання декількох комунікаційних операцій обмежена - в будь-

який момент часу кожний процесор може приймати участь лише в одній операції

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

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

собою.

147

Характеристики топології мережі. Як основні характеристики топології

мережі передачі даних використовуються такі показники:

- діаметр - показник, який визначається як максимальна відстань між двома

процесорами мережі (такою відстанню є величина найкоротшого шляху між

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

для передачі даних між процесорами, оскільки час передачі пропорційний

довжині шляху;

- зв’язність (connectivity) - показник, який характеризує наявність різних

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

показника можна визначити як мінімальна кількість дуг, які слід видалити для

розділення мережі передачі даних на дві незв’язні області;

- ширина бінарного поділу (bisection width) - показник, який визначається як

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

дві незв’язні області однакового розміру;

- вартість - показник, який можна визначити, наприклад, як загальна

кількість ліній передачі в багатопроцесорній обчислювальній системі.

Для порівняння в таблиці 2.1 наводяться значення перерахованих

показників для різних топологій мережі передачі даних.

Характеристика системних платформ для побудови кластерів. За

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

нині операційні системи Unix та Microsoft Windows. Далі розглядатимемо рішення

на основі ОС сім’ї Microsoft Windows. Microsoft Compute Cluster Server 2003

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

на кластерних системах. CCS складається з операційної системи Microsoft

Windows Server 2003 та Microsoft Compute Cluster Pack (CCP) - набору

інтерфейсів, утиліт та інфраструктури управління. Разом з ССР постачається

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

власну реалізацію MPI (Microsoft MPI). Окрім того, до Microsoft Compute Cluster

Server 2003 логічно примикає Microsoft Visual Studio 2005 - інтегроване

середовище розробки (IDE), яке містить компілятор та налагоджування програм,

148

розроблених з використанням технологій MPI та OpenMP.

Таблиця 2.1 – Характеристики топологій мережі передачі даних (р -

кількість процесорів)

Топологія Діаметр Ширина

бісекції

Зв’язність Вартість

Повний граф 1 p2/4 p-1 P(p-1)/2

Зірка 2 1 1 p-1

Повне двійкове

дерево

2log((p+1)/2) 1 1 p-1

Лінійка p-1 1 1 p-1

Кільце [p/2] 2 2 P

Решітка N=2 2( -1) 2 2(p- )

Решітка-тор N=2 2[ /2] 2 4 2p

Гіперкуб log p p/2 log p (p log p)/2

Як обчислювальні вузли кластера застосовуються 64 - бітові процесори сім’ї

х86 з, мінімум, 512 Мб оперативної пам’яті та 4 Гб вільного дискового простору.

На обчислювальних вузлах кластера слід встановити ОС Microsoft Windows Server

2003 (Standard, Enterprise або Compute Cluster Edition). До складу CCP входить

Microsoft MPI - версія реалізації стандарту MPI 2 від Argonne National Labs. MS

MPI сумісна з МРІСН 2 і підтримує повнофункціональний АРІ з більш ніж 160

функціями. MS MPI у Windows Compute Cluster Server 2003 задіє WinSock Direct

протокол для найкращої продуктивності та ефективного використання

центрального процесора. MS MPI може використати будь-яке Ethernet з’єднання,

яке підтримується Windows Server 2003, та з’єднання InfiniBand чи Myrinet, з

використанням WinSock Direct драйверів, які постачаються виробниками

апаратного забезпечення. MS MPI підтримує мови програмування C, Fortran 77,

Fortran 90, a Microsoft Visual Studio 2005 включає паралельне налагоджування, яке

працює з MS MPI. Розробники можуть запустити свій MPI - додаток на декількох

149

обчислювальних вузлах, та Visual Studio автоматично з’єднатися з процесами на

кожному вузлі, надаючи змогу розробнику призупиняти додаток і проглядати

значення змінних в кожному процесі окремо.

Крім реалізації MPI до складу ССР входить зручна система планування

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

призначати запуски програм на певний час, завершувати "завислі" задачі, та ін. В

поточній версії робота можлива або через графічний інтерфейс, або через

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

системи та через інші інтерфейси: СОМ, web - сервіс, та ін. Windows Compute

Cluster Server 2003 підтримує 5 різних мережевих технологій, причому кожний

вузол може мати від 1 до 3 мережевих карток. Правильний вибір

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

обчислювального кластера.

Моделювання і аналіз паралельних обчислень

При розробці паралельних алгоритмів розв’язку складних задач важливим є

аналіз ефективності використання паралелізму - оцінка отримуваного

прискорення процесу обчислень, скорочення тривалості розв’язування задачі.

Модель обчислень у вигляді графа "операції - операнди". Для опису

існуючих інформаційних залежностей в алгоритмах рішення задач, що

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

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

операцій однакова і дорівнює 1 (одиниця виміру). Приймемо, що передача даних

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

(наприклад, за наявності спільної розділеної пам’яті в паралельній

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

алгоритмів приводиться далі.

Зобразимо множину операцій, виконуваних в досліджуваному алгоритмі

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

залежності у вигляді ациклічного орієнтованого графа

150

де є множиною вершин графа, що є виконуваними операціями

алгоритму, а є множиною дуг графа (дуга належить графу тільки в тому

випадку, якщо операція не показує результату виконання операції ). Для

прикладу на рис. 2.2 показаний граф алгоритму визначення площі прямокутника,

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

виконання вибраного алгоритму розв’язку задачі можна використати різні схеми

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

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

при побудові моделі обчислень можна поставити задачі вибору обчислювальної

схеми алгоритму, що найбільш підходить для паралельного обчислення.

Рисунок 2.2 – Приклад обчислювальної моделі алгоритму у вигляді графа

"операції-операнди"

В цій обчислювальній моделі алгоритму вершини без вхідних дуг можуть

використовуватися для задавання операція введення, а вершини без вихідних душ

- для операцій виведення. Позначимо через множину вершин графа без вершин

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

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

151

немає шляху в рамках вибраної схеми обчислень, можна виконати паралельно

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

спочатку всі операції множення, а потім перші дві операції віднімання).

Можливий спосіб опису паралельного виконання алгоритму може полягати в

наступному.

Нехай є кількістю процесорів, використовуваних для виконання

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

(розклад)

, (2.1)

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

виконання операції процесора та тривалість виконання операції . Для того

щоб розклад міг бути реалізований, необхідно виконання таких вимог при

задаванні множини :

1) , тобто один і той же процесор не повинен

призначатися різним операціям в один і той же момент часу;

2) , тобто до призначеного моменту виконання операції

всі необхідні дані вже повинні бути обчислені.

Визначення часу виконання паралельного алгоритму. Обчислювальна

схема алгоритму разом з розкладом може розглядатися як модель

паралельного алгоритму , виконуваного з використанням процесорів.

Тривалість виконання паралельного алгоритму визначається максимальним

значенням часу, що використовується в розкладі

. (2.2)

Для вибраної схеми обчислень бажано використання розкладу, який

забезпечує мінімальну тривалість виконання алгоритму

. (2.3)

Зменшення тривалості виконання можна забезпечити шляхом підбору

найкращої обчислювальної схеми

152

. (2.4)

Оцінки , та можна застосувати як показники тривалості

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

можливого паралелізму можна визначити оцінку найшвидшого виконання

алгоритму

. (2.5)

Оцінку можна розглядати як мінімально можливу тривалість виконання

паралельного алгоритму при використанні необмеженої кількості процесорів

(концепція обчислювальної системи з нескінченною кількістю процесорів, яка

називається паракомп'ютером, широко застосовується при теоретичному

аналізуванні паралельних обчислень). Оцінка визначає тривалість виконання

алгоритму при використанні одного процесора і представляє, тим самим,

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

такої оцінки є важливою задачею при аналізуванні паралельних алгоритмів,

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

(прискорення тривалості розв’язку задачі). Очевидно, що

, (2.6)

де - кількість вершин обчислювальної схеми без вершин введення.

Важливо відмітити, що якщо при визначення оцінки обмежитися розглядом

тільки одного вибраного алгоритму розв’язку задачі і використати величину

, (2.7)

то отримувані при такій оцінці показники прискорення

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

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

тривалість послідовного рішення слід визначати з врахуванням різних

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

, (2.8)

де операція мінімуму береться по множині всіх можливих послідовних

153

алгоритмів розв’язку даної задачі.

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

властивості оцінок тривалості виконання паралельного алгоритму.

Теорема 1. Мінімально можлива тривалість виконання паралельного

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

алгоритму, тобто

. (2.9)

Теорема 2. Нехай для деякої вершини виведення в обчислювальній схемі

алгоритму існує шлях з кожної вершини введення. Крім того, нехай вхідна

ступінь вершин схеми (кількість вхідних дуг) не перевищує 2. Тоді мінімально

можлива тривалість виконання паралельного алгоритму обмежена знизу

значенням

, (2.10)

де - кількість вершин введення в схемі алгоритму.

Теорема 3. При зменшенні кількості використовуваних процесорів

тривалість виконання алгоритму збільшується пропорційно величині зменшення

кількості процесорів, тобто

. (2.11)

Теорема 4. Для будь-якої кількості використовуваних процесорів

справедлива така верхня оцінка для тривалості виконання паралельного

алгоритму

. (2.12)

Теорема 5. Тривалості виконання алгоритму, яка зіставляється з

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

порядку ~ , а саме,

. (2.13)

При меншій кількості процесорів тривалість виконання алгоритму може

перевищувати більш ніж в 2 рази найкращу тривалість обчислень при наявній

чисельності процесорів, тобто154

. (2.14)

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

формування паралельних алгоритмів: при виборі обчислювальної схеми

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

для паралельного виконання доцільна кількість процесорів визначається

величиною ~ ; тривалість виконання паралельного алгоритму обмежується

зверху величинами, наведеними в теоремах 4 та 5.

Показники ефективності паралельного алгоритму. прискорення

(speedup) отримуване при використанні паралельного алгоритму для процесора,

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

(2.15)

тобто як відношення тривалості рішення задач на скалярній ЕОМ до

тривалості виконання паралельного алгоритму(величина застосовується для

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

розумітися, як кількість вхідних даних задачі).

Ефективність (efficiency). використання паралельним алгоритмом

процесорів при розв’язку задачі визначається співвідношенням

, (2.16)

(величина ефективності визначає середню частку часу виконання

алгоритму, протягом якої процесори реально задіяні для розв’язку задачі). З цих

співвідношень можна показати, що в найкращому випадку і . В

разі практичного застосування цих показників для оцінки ефективності

паралельних обчислень слід врахувати дві таких позиції.

1). За певних обставин прискорення може виявитися більша чисельність

використовуваних процесорів - в цьому випадку кажуть про існування

понад лінійного (superliner) прискорення. На практиці понад лінійне прискорення

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

послідовної та паралельної програм. Так за умови розв’язку задачі на одному

процесорі виявляється недостатньо оперативної пам’яті для зберігання всіх

155

оброблюваних даних, тоді стає необхідним використання більше повільної

зовнішньої пам’яті (у випадку використання кількох процесорів оперативної

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

процесорами). Ще однією причиною понад лінійного прискорення може бути

нелінійний характер залежності складності рішення задачі від об’єму

оброблюваних даних. Так, наприклад, відомий алгоритм бульбочкового

сортування характеризується квадратичною залежністю кількості необхідних

операцій від числа впорядкованих даних. Як результат, при розподілі

сортувального масиву між процесорами може бути отримано прискорення, що

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

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

методів.

2) При уважному аналізуванні можна звернути увагу, що спроби

підвищення якості паралельних обчислень за одним з показників (прискоренню

чи ефективності) можуть призвести до погіршення ситуації за другим

показником, оскільки показники якості паралельних обчислень часто

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

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

падіння ефективності. І навпаки, підвищення ефективності досягається в багатьох

випадках при зменшенні чисельності процесорів (в граничному випадку ідеальна

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

процесора). Як результат, розробка методів паралельних обчислень часто

передбачає вибір певного компромісного варіанту з врахуванням бажаних

показників прискорення та ефективності.

В разі вибору належного паралельного способу розв’язку задачі може

виявитись корисною оцінка вартості обчислень, яка визначається як добуток

тривалості паралельного рішення задачі та чисельності використаних процесорів

.= (2.17)

В зв’язку з цим можна означити поняття вартісно-оптимального (cost-

optimal) паралельного алгоритму як методу, вартість якого пропорційна 156

тривалості виконання найкращого паралельного алгоритму.

Розглянемо, для ілюстрації, навчальний приклад розв’язку задачі

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

Навчальний приклад обчислення часткових сум послідовності числових

значень

Розглянемо задачу знаходження часткових сум послідовності числових

значень

,(2.18)

де - кількість підсумованих значень (назва задачі - prefix sum problem) .

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

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

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

. (2.19)

Послідовний алгоритм знаходження суми. Традиційний алгоритм

розв’язку цієї задачі полягає в послідовності знаходження суми елементів

числового набору

, (2.20)

(2.21)

Обчислювальну схему цього алгоритму можна подати наступним чином,

рис. 2.3:

Рисунок 2.3 – Послідовна обчислювальна схема алгоритму знаходження суми157

, (2.22)

де є множиною операцій (вершини

означають операції введення, кожна вершина , відповідає добавленню

значення до накопичуваної суми ) а

(2.23)

є множиною дуг, що визначають інформаційні залежності операцій. Можна

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

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

Каскадна схема знаходження суми. Паралелізм алгоритму знаходження

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

базується на використанні асоціативності операції додавання. Інший варіант

знаходження суми (відомий, як каскадна схема) полягає в наступному, рис. 2.4:

- на першій ітерації каскадної схеми всі вихідні дані розбиваються на пари, і

для кожної пари обчислюється сума їх значень;

- далі всі отримані суми також розбиваються на пари, і знову виконується

знаходження суми значень пар, і т.д.

Рисунок 2.4 – Каскадна схема алгоритму знаходження суми

Цю обчислювальну схему можна визначити як граф (нехай )

, (2.24)

де є вершини графа ( - операції

158

введення, - операції знаходження суми першої ітерації, і т.д.) а

множина дуг графа визначається співвідношеннями:

. (2.25)

Нескладно оцінити, кількість ітерацій каскадної схеми , яка виявляється

рівною величині

, (2.26)

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

(2.27)

співпадає з кількістю операцій послідовного варіанту алгоритму

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

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

. (2.28)

Оскільки вважається, що тривалість виконання будь-яких операцій

однакова і одинична, то , тому показники прискорення та

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

, (2.29)

, (2.30)

де - необхідна чисельність процесорів для виконання каскадної

схеми.

Аналізуючи отримані характеристики, можна помітити, що тривалість

паралельного виконання каскадної схеми співпадає з оцінкою для

паракомп’ютера в теоремі 2. Проте ефективність використання процесорів

зменшується із збільшенням чисельності значень сумування

за умови .

Модифікована каскадна схема. Отримання асимптотичної ненульової

ефективності можна забезпечити в разі використання модифікованої каскадної

схеми. Для спрощення побудови оцінок можна припустити . Тоді в

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

159

виконуваних етапи знаходження суми, рис. 2.5:

Рисунок 2.5 – Модифікована каскадна схема знаходження суми

- на першому етапі обчислень всі значення сум поділяються на

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

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

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

один від одного, тобто для цього необхідна наявність не менше

процесорів);

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

звичайна каскадна схема.

Тоді для виконання першого етапу потрібно паралельних операцій з

використанням процесорів. Для виконання другого етапу необхідно

(2.31)

паралельних операцій для процесорів. Як результат, даний

спосіб знаходження суми характеризується такими показниками:

. (2.32)

З врахуванням отриманих оцінок показники прискорення та ефективності

модифікованої каскадної схеми визначаються співвідношеннями:

, (2.33)

. (2.34)

160

Порівнюючи ці оцінки з показниками загальної каскадної схеми, можна

помітити, що прискорення для запропонованого паралельного алгоритму

зменшилось в 2 рази, проте для ефективності нового методу знаходження суми

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

за умови .

Можна помітити, що дані значення показників досягаються тоді, коли

чисельність процесорів становить величину, визначену в теоремі 5. Слід

підкреслити, що, на відміну від звичайної каскадної схеми, модифікований

каскадний алгоритм є вартісним - оптимістичним, оскільки вартість обчислень в

цьому випадку

(2.35)

пропорційна тривалості виконання послідовного алгоритму.

Обчислення всіх часткових сум. Розглянемо задачу обчислення всіх

часткових сум послідовності значень і проаналізуємо можливі способи

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

на скалярному комп’ютері може бути отримано з використанням звичайного

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

. (2.36)

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

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

розпаралелювання потребує залучення нових підходів для розробки нових

паралельно - орієнтованих алгоритмів рішення задач. Так для розглянутої задачі

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

за паралельних операцій (як і в випадку обчислень загальної суми), може

полягати в наступному, рис. 2.6:

- перед початком обчислень створюється копія вектора значень суми (

;

- далі на кожній ітерації сумування , формується допоміжний

вектор шляхом зсуву праворуч вектор на позицій (які вивільняються при

зсуві позиції ліворуч встановлюються в нульове значення); ітерація алгоритму

161

завершується паралельною операцією знаходження суми векторів та .

Всього паралельний алгоритм виконується за паралельних операцій

складання. На кожній ітерації алгоритму паралельно виконуються скалярних

операцій додавання, таким чином, загальна кількість скалярних операцій

визначається величиною

(2.37)

(паралельний алгоритм містить велику кількість операцій порівняно з

послідовним способом знаходження суми). Необхідна кількість процесорів

визначається кількістю значень, щодо яких визначається сума ( ).

Рисунок 2. 6 – Схема паралельного алгоритму обчислення всіх часткових сум (величини jiS

означають суми значень від i до j

елементів числової послідовності)

З урахуванням отриманих співвідношень показники прискорення та

ефективності паралельного алгоритму визначення всіх часткових сум оцінюється

наступним чином:

. (2.38)

.

(2.39)

З побудованих оцінок випливає, що ефективність алгоритму також

зменшується із збільшенням чисельності значень, щодо яких визначається сума, і

за необхідності підвищення величини цього показника може виявитися корисною

модифікація алгоритму, як і у випадку звичайної каскадної схеми.

Оцінка максимально досяжного паралелізму

Оцінка якості паралельних обчислень передбачає знання найкращих

(максимально досяжних) значень показників прискорення та ефективності, проте

162

отримання ідеальних величин для прискорення та для ефективності

може бути забезпечено не для всіх обчислювальних трудомістких задач. Так. для

учбового прикладу, що розглядається, мінімально досяжний час паралельного

обчислення суми числових значень складає . Корисними для розв’язку цієї

задачі можуть бути теоретичні твердження наведені вище. Розглянемо також

закономірності, корисні при побудові оцінок максимально досяжного

паралелізму.

1. Закон Амдаля. Досягненню максимального прискорення може

перешкоджати існування в виконуваних обчисленнях послідовних розрахунків,

які можна розпаралелити. Нехай - частка послідовних обчислень в алгоритмі

обробки даних, що застосовується. Тоді у відповідності з законом Амдаля

прискорення процесу обчислень з використанням процесорів обмежується

величиною

. (2.40)

Так за наявності 10% послідовних команд у виконуваних обчисленнях

ефект використання паралелізму не може перевищувати 10-кратного прискорення

обробки даних. В розглянутому навчальному прикладі обчислення суми значень

для каскадної схеми частка послідовних розрахунків складає і, як

результат, величина можливого прискорення обмежена оцінкою .

Закон Амдаля характеризує одну з самих серйозних проблем в галузі

паралельного програмування (алгоритмів без певної частки послідовних команд

практично не існує). проте часто часка послідовних дій характеризує не

можливість паралельного рішення задач, а послідовні властивості застосовуваних

алгоритмів. Тому частка послідовних обчислень може бути істотно знижена при

виборі методів, придатніших для розпаралелювання

Розгляд закону Амдаля відбувається в припущенні, що частка послідовних

розрахунків є сталою величиною і не залежить від параметра , який визначає

обчислювальну складність розв’язуваної задачі. Проте для великого ряду задач

частка є спадною функцією від , і в цьому випадку прискорення для

фіксованої кількості процесорів може бути збільшено за рахунок збільшення

163

обчислювальної складності розв’язуваної задачі. Проте для більшості задач частка

є спадною функцією від , і в цьому випадку прискорення для фіксованої

кількості процесорів може бути збільшено за рахунок збільшення обчислювальної

складності розв’язуваної задачі. Це зауваження можна сформулювати як

твердження, що прискорення є зростаючою функцією від параметра

(це твердження називається ефектом Амдаля). Так, в навчальному прикладі,

обчислення суми значень при використанні фіксованої чисельності процесорів

сумарний набір даних може бути розділений на блоки розміру , для яких

спочатку паралельно можна обчислити часткові суми, а далі ці суми можна

скласти з використанням каскадної схеми. Тривалість послідовної частини

виконуваних операцій (мінімально можлива тривалість паралельного виконання)

в цьому випадку складає

, (2.41)

що призводить до оцінки частки послідовних розрахунків як величини

. (2.42)

Як випливає з отриманого виразу, частка послідовних розрахунків спадає

із зростанням і в граничному випадку маємо оцінку максимально можливого

прискорення .

2. Закон Густавсона-Баріса. Оцінимо максимально досяжне прискорення

виходячи з наявної частки послідовних розрахунків у виконуваних паралельних

обчисленнях:

, (2.43)

де та - тривалість послідовної та паралельної частин виконуваних

обчислень, відповідно, тобто

, . (2.44)

З врахуванням введеної величини можна отримати

, , (2.45)

що дає змогу побудувати оцінку для прискорення

164

, (2.46)

яка після спрощення приводиться до типу закону Густавсона-Барсіса

(Gustafson - Barsis’s law)

. (2.47)

Стосовно навчального прикладу підсумовування значень при використанні

процесорів тривалість паралельного використання складає

, (2.48)

що відповідає послідовній частці

. (2.49)

За рахунок збільшення чисельності підсумованих значень величина може

бути зневажливо малою, забезпечуючи отримання ідеально можливого

прискорення .

При розгляді закону Густавсона-Барсіса слід враховувати те, що із

збільшенням чисельності використовуваних процесорів темп зменшення

тривалості паралельного розв’язку задач може спадати (після перевищення

певного порогу). Проте за рахунок зменшення тривалості обчислень складність

розв’язуваних задач може бути збільшена (для навчальної задачі підсумовування

може бути збільшений розмір набору значень, що складається). Оцінку

отримуваного при цьому прискорення можна визначити з використанням

сформульованих закономірностей. Така аналітична оцінка корисна, оскільки

розв’язок складніших варіантів задач на одному процесорі може виявитися

достатньо трудомістким, навіть неможливим, наприклад, в силу нехватки

оперативної пам’яті. З врахуванням цих обставин оцінку прискорення,

отримувану у відповідності з законом Густавсона-Барсіса , ще називають

прискоренням масштабування (scaled speedup), оскільки ця характеристика може

показати, наскільки ефективно можна організувати паралельні обчислення при

165

збільшенні складності розв’язуваних задач.

Аналіз масштабованості паралельних обчислень

Метою застосування паралельних обчислень є не тільки зменшення

тривалості розрахунків, але й забезпечення можливості розв’язку складніших

варіантів задач (таких постановок, розв’язок яких не представляється можливим

при використанні одно процесорних обчислювальних систем). Здатність

паралельного алгоритму ефективно використовувати процесори при підвищенні

складності обчислень є важливою характеристикою виконуваних розрахунків.

Тому паралельний алгоритм називають масштабованим (scalable), якщо в разі

росту чисельності процесорів він забезпечує збільшення прискорення при

збереження постійного рівня ефективності використання процесорів. Можливий

спосіб характеристики властивостей масштабованості полягає в наступному.

Оцінимо накладні витрати (total overhead), які мають місце при виконанні

паралельного алгоритму

. (2.50)

Накладні витрати з’являються за рахунок необхідності організації взаємодії

процесорів, виконання деяких додаткових дій, синхронізації паралельних

обчислень і т.п. Використовуючи введене позначення, можна отримати нові

вирази для тривалості паралельного рішення задачі та відповідного прискорення:

.(2.51)

Застосовуючи отримані співвідношення, ефективність використання

процесорів можна виразити як

. (2.52)

Останній вираз показує, що якщо складність розв’язуваної задачі є

фіксованою ( ), то при зростанні чисельності процесорів ефективність, як

правило, буде спадати за рахунок зростання накладних витрат . При фіксації

чисельності процесорів ефективність їх використання можна покращити шляхом

166

підвищення складності розв’язуваної задачі (вважається, що при зростанні

параметра складності накладні витрати збільшуються повільніше, ніж об’єм

обчислень ). Як результат, при збільшенні чисельності процесорів в більшості

випадків можна забезпечити певний рівень ефективності з використанням

відповідного підвищення складності розв’язуваних задач. Тому важливою

характеристикою паралельних обчислень стає співвідношення необхідних темпів

росту складності розрахунків та чисельності використовуваних процесорів.

Нехай є бажаний рівень ефективності виконуваних обчислень. З

виразу для ефективності можна отримати

або , . (2.53)

Породжувану останнім співвідношенням залежність між складністю

розв’язуваної задачі та чисельністю процесорів називають функцією

ізлефективності (isoefficiency function).

Отримаємо виведення виразу для функції ізоефективності для

навчального прикладу знаходження суми числових значень. В цьому випадку

. (2.54)

і вираз для функції ізоефективності набуде вигляду

. (2.55)

Як результат, наприклад, при чисельності процесорів для забезпечення

рівня ефективності (тобто кількість значень суми повинна бути не

менше . Або ж, при зростанні чисельності процесорів з до для

забезпечення пропорційного зростання прискорення необхідно

збільшити чисельність значень суми в разів.

Оцінка комунікаційної трудомісткості паралельних алгоритмів

Алгоритми маршрутизації. Алгоритми маршрутизації визначають шлях

передачі даних від процесора - джерела повідомлення, до процесора, до якого

повідомлення повинно бути доставлено. розрізняють наступні можливі способи

167

рішення такої задачі;

- оптимальні які визначають завжди найкоротші шляхи передачі даних, та

неоптимальні алгоритми маршрутизації;

- детерміновані і адаптовані методи вибору маршрутів (адаптивні алгоритми

визначають шляхи передачі даних в залежності від існуючого завантаження

комунікаційних каналів).

До числа найпоширеніших оптимальних алгоритмів відноситься клас

методів по координатної маршрутизації (dimension-ordered routing), в яких пошук

шляхів передачі даних здійснюється по черзі для кожної розмірності топології

мережі комунікації. Так для двомірної решітки такий підхід приводить до

маршрутизації, коли передача даних спочатку виконується по одному напрямку

(наприклад, по горизонталі до досягнення вертикалі, на якій розташований

процесор призначення), а далі дані передаються впродовж другого напрямку (ця

схема відома під назвою алгоритму ХУ - маршрутизації). Для гіперкуба по

координатна схема маршрутизації може полягати, наприклад, в циклічній

передачі даних процесору, який визначається першою відмінною бітовою

позицією в номерах процесорів - того, на якому повідомлення розташовується в

даний момент часу, та того, на який воно повинно бути передане.

Методи передачі даних. Тривалість передачі даних між процесорами

визначає комунікаційну складову (communication latency) тривалості виконання

паралельного алгоритму в багатопроцесорній обчислювальній системі. Основний

набір параметрів, що описують тривалість передачі даних, складається з

наступного ряду величин:

- тривалість початкової підготовки ( ) характеризує тривалість підготовки

повідомлення для передачі, пошуку маршруту в мережі і т.п.;

- тривалість передачі службових даних ( ) між двома сусідніми

процесорами (тобто для процесорів, між якими є фізичний канал передачі даних).

До службових даних може відноситися заголовок повідомлення, блок даних для

виявлення похибок передачі і т.п.;

- час передачі одного слова даних по одному каналу передачі даних ( ).

168

Тривалість подібної передачі визначається полосою пропускання комунікаційних

каналів в мережі.

До числа найпоширеніших методів передачі даних відносяться два

основних способи комунікації. Перший з них орієнтований на передачу

повідомлень (метод передачі повідомлень, чи МПС) як неподільних (атомарних)

блоків інформації (store and-forward routing або SFR). При такому підході

процесор, який містить повідомлення для передачі, готує весь об’єм даних для

передачі, визначає процесор, якому слід направити дані, і запускає операцію

пересилки даних. Процесор, якому направлено повідомлення, в першу чергу

здійснює прийом повністю всіх даних і тільки потім приступає до пересилки

прийнятого повідомлення далі за маршрутом. Тривалість пересилання даних

для методу передачі повідомлення розміром байтів за маршрутом довжиною

визначається виразом

. (2.56)

За умови достатньо довгих повідомлень тривалістю передачі службових

даних можна знехтувати і вираз для тривалості передачі даних можна записати в

простішому вигляді:

. (2.57)

Другий спосіб комунікації базується на представленні повідомлень,

що пересилаються, у вигляді блоків інформації меншого розміру - пакетів, в

результаті чого передача даних може бути зведена до передачі пакетів (метод

передачі пакетів або МПП). ЗА умови такого методу комунікації (cut-through

routing або CTR) процесор, що приймає, може здійснювати пересилку даних за

подальшим маршрутом безпосередньо відразу після прийому чергового пакету, не

очікуючи завершення прийому даних всього повідомлення. Тривалість

пересилання даних при використанні методу передачі пакетів визначається

виразом:

. (2.58)

Порівнюючи отримані вирази отримані вирази, можна помітити, що в

більшості випадків метод передачі пакетів приводить до більш швидкого

169

пересилання даних; крім того, даний підхід знижує потребу в пам’яті для

зберігання даних, що пересилаються, при організації прийому-передачі

повідомлень, а для передачі пакетів можуть використовуватися одночасно різні

комунікаційні канали. З іншого боку, реалізація пакетного методу потребує

розробки більш складного апаратного та програмного забезпечення мережі, може

збільшити накладні витрати (тривалість підготовки та тривалість передачі

службових даних). Крім того, при передачі пакетів можливе виникнення

конфліктних ситуацій (дедлоків).

Аналіз трудомісткості основних операцій передачі даних. При всьому

розмаїтті виконуваних операцій передачі даних при паралельних способах

розв’язку складних науково-технічних задач, певні процедури взаємодії процесів

мережі можна віднести до числа основних комунікаційних дій, або найбільш

широко розповсюджених на практиці паралельних обчислень, або тих, до яких

можна багато інших процесів прийому-передачі повідомлень. Важливо відмітити,

що в рамках подібного базового набору для більшості операцій комунікації

існують процедури, обернені за дією вихідним операціям. Як результат, аналіз

комунікаційних процедур доцільно виконувати попарно, оскільки в багатьох

випадках алгоритми виконання прямої та зворотної операцій можуть бути

отримані наслідки не з однакових посилань.

Передача даних між двома процесорами мережі. Складність цієї

комунікаційної операції може бути наслідком підстановки довжини

максимального шляху (діаметра мережі) в вирази для тривалості передачі даних

при різних методах комунікації, табл. 2.2.

Таблиця 2.2.– Тривалість передачі даних між двома процесорами

Топологія Передача

повідомлень

Передача пакетів

Кільце

Решітка-тор

Гіперкуб

170

Передача даних від одного процесора всім іншим процесорам мережі.

Операція передачі даних (одного і того ж сполучення) від одного процесора всім

іншим процесорам мережі (one-to-all broadcast або single-node broadcast) є однією

з найчастіше виконуваних комунікаційних дій. Двоїста до неї операція - прийом

на одному процесорі повідомлень від всіх інших процесорів мережі (single-node

accumulation). Подібні операції використовуються, зокрема, при реалізації

матрично-векторного множення, розв’язку систем лінійних рівнянь методом

Гауса, розв’язку задачі пошуку найкоротших шляхів та ін.

Найпростіший спосіб реалізації операції розсилання полягає в її виконанні

як послідовності попарних взаємодій процесорів мережі Проте за такого підходу

більша частина пересилань є надлишковою і можливе застосування більш

ефективних алгоритмів комунікації.

Передача повідомлень. Для кільцевої технології процесор - джерело

розсилання може ініціювати передачу даних відразу двом своїм сусідам, які, в

свою чергу, прийнявши повідомлення, організують пересилання далі по кільцю.

Трудомісткість виконання операції розсилання в цьому випадку визначатиметься

співвідношенням:

. (2.59)

Для топології типу решітка-тор алгоритм розсилання можна отримати із

способу передачі даних, застосованого для кільцевої структури мережі. Так,

розсилка може бути виконана у вигляді двох етапної процедури. на першому етапі

організується передача повідомлень всім процесорам мережі, розташованим на

тій же горизонталі решітки, що й процесор - ініціатор передачі. На другому етапі

процесори, які отримали копію даних на першому етапі, розсилають

повідомлення по своїм відповідним вертикалям. Оцінка тривалості операції

розсилки у відповідності з описаним алгоритмом визначається співвідношенням;

. (2.60)

Для гіперкубу розсилка може бути виконана в ході N - етапної процедури

171

передачі даних. На першому етапі процесор-джерело повідомлення передає дані

одному з своїх сусідів (наприклад, по першій розмірності) - в результаті після

першого етапу є два процесори, які мають копію даних, що пересилаються (цей

результат можна інтерпретувати також як розбиття вихідного гіперкуба на два

таких однакових за розміром гіперкуби з розмірністю N-1, що кожний з них має

копію вихідного повідомлення). На другому етапі два процесори, задіяні на

першому етапі, пересилають повідомлення своїм сусідам по другій розмірності і

т.д. в результаті такого розсилання тривалість операції оцінюється з

використанням виразу:

. (2.61)

Порівнюючи отримані вирази для тривалості виконання операції

розсилання, можна відмітити, що найкращі показники мають технології типу

гіперкуб; більше того, можна показати, що такий результат є найкращим для

вибраного способу комунікації з використанням повідомлень.

Передача пакетів. Для топології типу кільце алгоритм розсилання можна

отримати шляхом логічного зображення кільцевої структури мережі у вигляді

гіперкубу. В результаті на етапі розсилання процесор - джерело повідомлення

передає дані процесору, який знаходиться на відстані від вихідного

процесора. Далі, на другому етапі обидва процесори, які вже мають дані, що

розсилаються, після першого етапу, передають повідомлення процесорам, які

знаходяться на відстані , і т.д. Трудомісткість виконання операції розсилання

за такого методу передачі даних визначається співвідношенням:

(2.62)

(як і раніше, за достатньо великих повідомленнях тривалістю передачі

службових даних можна знехтувати).

Для топології типу решітка-тор алгоритм розсилання можна отримати із

способу передачі даних, застосованого для кільцевої структури мережі, у

відповідності з тим же способом, що і у випадку використання методу передачі

повідомлень. Отриманий в результаті такого узагальнення алгоритм розсилання

172

характеризується таким співвідношенням для оцінки тривалості виконання:

. (2.63)

Для гіперкуба алгоритм розсилання (та, відповідно, часові оцінки

тривалості виконання) при передачі пакетів не відрізняється від варіанту для

методу передачі повідомлень.

Передача даних від всіх процесорів всім процесорам мережі. Операція

передачі даних від всіх процесорів всім процесорам мережі (all-to-all broadcast або

multinode broadcast) є природним узагальненням одиночної операції розсилки,

двоїста до неї операція - прийом повідомлень на кожному процесорі від всіх

процесорів мережі (multinode accumulation). Подібні операції широко

використовуються, наприклад, при реалізації матричних обчислень.

Можливий спосіб реалізації множинного розсилання полягає у виконанні

відповідного набору операцій одиночного розсилання. Проте такий підхід не є

оптимальним для багатьох топологій мережі, оскільки частина необхідних

операцій одиночного розсилання потенційно може бути виконана паралельно.

Передача повідомлень. Для кільцевої топології кожний процесор може

ініціювати розсилання свого повідомлення одночасно (в якомусь вибраному

напрямку по кільцю). В будь-який момент кожний процесор виконує прийом і

передачу даних, завершення операції множинного розсилання відбудеться через

циклів передачі даних. Тривалість виконання операції розсилання оцінюється

співвідношенням:

. (2.64)

Для топології типу решітка-тор множинне розсилання повідомлень може

бути виконана з використанням алгоритму, отриманого узагальненням способу

передачі даних для кільцевої структури мережі. Схема узагальнення полягає в

наступному. На першому етапі організується передача повідомлень роздільно по

всім процесорам мережі, які розташовані на одних і тих же горизонталях решітки

(в результаті на кожному процесорі однієї і тієї ж горизонталі формуються

укрупнені повідомлення з розміром , які об’єднують всі повідомлення

горизонталі). Тривалість виконання етапу:

173

. (2.65)

На другому етапі розсилання даних виконується по процесорам мережі, які

утворюють вертикалі решітки. Тривалість цього етапу:

. (2.66)

Загальна тривалість операції розсилання визначається співвідношенням:

(2.67)

Для гіперкуба алгоритм множинного розсилання повідомлень можна

отримати узагальненням раніше описаного способу передачі даних для топології

типу решітки на розмірність гіперкуба N. В результаті такого узагальнення схема

комунікації полягає в наступному. На кожному етапі , виконання

алгоритму функціонують всі процесори мережі, які обмінюються своїми даними

із своїми сусідами i - ої розмірності і формують об’єднані повідомлення.

Тривалість операції розсилання може бути отримана з використанням виразу:

. (2.68)

Передача пакетів. Застосування більш ефективного для кільцевої

структури та топології типу решітка-тор методу передачі даних не приводить до

якогось поліпшення тривалості виконання операції одиночного розсилання, на

випадок множинного розсилання приводить до перевантаження каналів передачі

даних (тобто, до існування ситуацій, коли в один і той же момент для передачі по

одній і тій же лінії є декілька пакетів даних, що очікують). Перевантаження

каналів приводить до затримок при пересиланні даних, що і не дозволяє з’явитися

всім перевагам методу передачі пакетів. Широко поширеним прикладом операції

множинного розсилання є задача редукції (reduction) , яка визначається в

загальному вигляді як процедура виконання тієї чи іншої обробки даних,

отриманих на кожному процесорі в ході множинного розсилання. Способи

розв’язку задачі редукції полягають в наступному:

- безпосередній підхід полягає у виконанні операції множинного розсилання

і, після цього, обробки даних на кожному процесорі зокрема;

- більш ефективний алгоритм можна отримати в результаті застосування

174

операції одиночного прийому даних на окремому процесорі, виконання на цьому

процесорі дій з обробки даних і розсилання отриманого результату обробки всім

процесорам мережі;

- найкращий спосіб розв’язку задачі редукції полягає в суміщенні

процедури множинного розсилання та дій з обробки даних, коли кожний

процесор відразу після прийому чергового повідомлення реалізує потрібну

обробку отриманих даних (наприклад, виконує додавання отриманого значення з

наявною на процесорі частковою сумою. Тривалість рішення задачі редукції при

такому алгоритмі реалізації у випадку, наприклад, коли розмір даних, що

пересилаються, має одиничну довжину ( ) і топологія мережі має структуру

гіперкуба, визначається співвідношенням:

. (2.69)

Іншим типовим прикладом використання операції множинного розсилання є

задача знаходження часткових сум послідовності значень

(2.70)

Вважається, що кількість значень співпадає з кількістю процесорів,

значення розташовується на – у процесорі, а результат повинен

отримуватися на процесорі з номером . Алгоритм розв’язку цієї задачі також

можна отримати з використанням конкретизації загального способу виконання

множинної операції розсилання, коли процесор виконує сумування отриманого

значення (але тільки в тому випадку, якщо процесор – відправник значення має

менший номер, ніж процесор – одержувач.

Узагальнена передача даних від одного процесора всім іншим

процесорам мережі. Загальний випадок передачі даних від одного процесора всім

іншим процесорам мережі полягає в тому, що всі повідомлення, що розсилаються,

різні (one-to-all personalized communication чи single-node scatter) . Двоїста

операція передачі даних для даного типу взаємодії процесорів - узагальнений

прийом повідомлень (single-node gather) на одному процесорі від всіх інших

процесорів мережі (відмінність цієї операції від раніше розглянутої процедури

збірки даних на одному процесорі полягає в тому, що узагальнена операція збірки 175

не передбачає якоїсь взаємодії повідомлень (наприклад, редукції) в процесі

передачі даних). Трудомісткість операції узагальненого розсилання порівнювана

із складністю виконання процедури множинної передачі даних. Процесор -

ініціатор розсилання посилає кожному процесору мережі повідомлення з

розміром , і, тим самим, нижня оцінка тривалості виконання операції

характеризується величиною .

Проаналізуємо трудомісткість узагальненої розсилки для випадку топології

типу гіперкуб. Можливий спосіб виконання операції полягає в майбутньому.

Процесор - ініціатор розсилання передає половину своїх повідомлень одному з

своїх сусідів (наприклад, за першою розмірністю) - в результаті вихідний гіперкуб

стає розділеним на два гіперкуби половинного розміру, в кожному з яких

міститься рівно половина вихідних даних. Далі, дії з розсилання повідомлень

можуть бути повторені, і загальна кількість повторень визначається вихідною

розмірністю гіперкуба. Тривалість операції узагальненого розсилання можна

характеризувати співвідношенням:

(2.71)

(як і відмічалося раніше, трудомісткість операції співпадає з тривалістю

виконання процедур множинного розсилання).

Узагальнена передача даних від всіх процесорів всім процесорам

мережі. Цей тип передачі даних представляє собою найбільш загальний випадок

комунікаційних дій. Необхідність виконання подібних операцій виникає в

паралельних алгоритмах швидкого перетворення Фур’є, транспонування матриць

та ін.

Передача повідомлень. Загальна схема алгоритму для кільцевої топології

полягає в наступному. Кожний процесор здійснює передачу всіх своїх вихідних

повідомлень своєму сусідові ( в якомусь вибраному напрямку по кільцю). Далі

процесори здійснюють прийом направлених до них даних, далі серед прийнятої

інформації вибирають свої повідомлення, після чого виконують подальше

розсилання частини даних, що розсилаються. Тривалість виконання подібного

набору передачі даних оцінюється згідно виразу:

176

. (2.72)

Спосіб отримання алгоритму розсилання даних для топології решітка-тор

той же самий, що і у випадку розгляду інших комунікаційних операцій. На

першому етапі організується передача повідомлень роздільно по всім процесорам

мережі, які розташовані на одних і тих же горизонталях решітки (кожному

процесору по горизонталі передаються тільки ті вихідні повідомлення, що

повинні бути направлені процесорам відповідної вертикалі решітки). Після

завершення етапу на кожному процесорі збираються повідомлень, призначених

для розсилання по одній вертикалі решітки. На другому етапі розсилання даних

виконується по процесорам мережі, які утворюють вертикалі решітки. Загальна

тривалість всіх операцій розсилань визначається співвідношенням:

. (2.73)

для гіперкуба алгоритм узагальненого множинного розсилання повідомлень

можна отримати шляхом узагальнення способу виконання операції для топології

типу решітка на розмірність гіперкуба . В результаті такого узагальнення схема

комунікації полягає в наступному. На кожному етапі , виконується

алгоритму функціонують всі процесори мережі, які обмінюються своїми даними

із своїми сусідами по - й розмірності і формують об’єднані повідомлення. За

організації взаємодії двох сусідів канал зв’язку між ними розглядається як

сполучний елемент двох рівних за розміром полі гіперкубів вихідного гіперкуба, і

кожний процесор пари посилає іншому процесору тільки ті повідомлення, що

призначені для процесорів сусіднього гіперкуба. Тривалість операції розсилання

можна отримати з використання виразу:

(2.74)

(крім витрат на пересилання, кожний процесор виконує операцій і

сортування своїх повідомлень перед обміном інформацією з своїми сусідами).

Передача пакетів. Як і у випадку множинного розсилання, застосування

методу передачі пакетів не приводить до покращення часових характеристик для

операції узагальненого множинного розсилання. Для прикладу розглянемо

177

застосування методу виконання даної комунікаційної операції для мережі з

топологією типу гіперкуб. В цьому випадку розсилання можна виконати за

ітерацію. На кожній ітерації всі процесори розбиваються на взаємодіючі пари

процесорів, причому це розбиття на пари може бути виконане таким чином, щоб

повідомлення, які передаються парами, не використовували одні і ті ж шляхи

передачі даних. Як результат, спільна тривалість операції узагальненого

розсилання можна визначити у відповідності з виразом:

. (2.75)

Циклічний зсув. Окремий випадок узагальненого множинного розсилання

є процедурою перестановки (permutation), який представляє собою операцію

перерозподілу інформації між процесорами мережі, в якій кожний процесор

передає повідомлення визначеному певним способом іншому процесору мережі.

Конкретний варіант перестановки - циклічний q - зсув (circular q - shift), коли

кожний процесор , передає дані процесору з номером . Подібна

операція зсуву використовується, наприклад, при організації матричних

обчислень.

Оскільки виконання циклічного зсуву для кільцевої топології може бути

забезпечено з використанням простих алгоритмів передачі даних, розглянемо

можливі способи виконання даної комунікаційної операції тільки для топологій

решітка-тор та гіперкуб за різних методах передачі даних.

Передача повідомлень. Загальна схема алгоритму циклічного зсуву для

топології решітка-тор полягає в наступному. Нехай процесори пронумеровані за

стрічками решітки від 0 до . На першому етапі організується циклічний зсув з

кроком по кожній стрічці зокрема (якщо при реалізації такого зсуву

повідомлення передаються через праві границі стрічок, то після виконання кожної

такої передачі необхідно здійснити компенсаційний зсув вверх на 1 для

процесорів першого стовпця решітки). На другому етапі реалізується циклічний

зсув вверх з кроком для кожного стовпця решітки. Загальна тривалість всіх

операцій розсилань визначається співвідношенням:

178

. (2.76)

Для гіперкуба алгоритм циклічного зсуву можна отримати шляхом

логічного представлення топології гіперкуба у вигляді кільцевої структури. Для

отримання такого представлення встановимо взаємно-однозначну відповідність

між вершинами кільця та гіперкуба. Необхідна відповідність може бути отримана,

наприклад, з використанням відомого коду Грея. Детальніший виклад механізму

встановлення такої відповідності здійснено нижче; для наочності на рис.

2.7.наводиться вигляд гіперкуба для розмірності із зазначенням для кожного

процесора гіперкуба відповідної вершини кільця. Позитивною властивістю

вибору такої відповідності є той факт, що для будь-яких двох вершин в кільці,

відстань між якими дорівнює для деякого значення , шлях між відповідними

вершинами в гіперкубі містить тільки дві лінії зв’язку (за виключенням випадку

, коли шлях в гіперкубі має одиничну довжину).

Уявимо величину зсуву у вигляді двоїстого коду. Кількість ненульових

позицій коду визначає кількість етапів в схемі реалізації операції циклічного

зсуву. На кожному етапі виконується операція зсуву з величиною кроку, яка

задається найстаршою ненульовою позицією значення (наприклад, за умови

вихідної величини зсуву на першому етапі виконується зсув з кроком 4,

на другому етапі крок зсуву дорівнює 1). Виконання кожного етапу (окрім зсуву з

кроком 1) полягає в передачі даних по шляху, який включає дві лінії зв’язку. Як

результат, верхня оцінка для тривалості виконання операції циклічного зсуву

визначається співвідношенням

. (2.77)

179

Рисунок 2.7 – Схема відображення гіперкуба на кільце (в кружках наведені

номери процесорів гіперкуба)

Передача пакетів. Використання пересилання пакетів може підвищити

ефективність виконання операції циклічного зсуву для топології гіперкуб.

Реалізація всіх необхідних комунікаційних дій в цьому випадку може бути

забезпечена шляхом відправки кожним процесором всіх даних, що

пересилаються,безпосередньо процесорам призначення. Застосування методу по

координатної маршрутизації дасть змогу уникнути колізій при використанні ліній

передачі даних (в кожний момент часу для кожного каналу буде існувати не

більше одного готового для відправки повідомлення) Довжина найбільшого

шляху за умови такого розсилання даних визначається як , де -

найбільше ціле значення таке, що - дільник величини зсуву . Тоді тривалість

операції циклічного зсуву можна охарактеризувати з використанням виразу

(2.78)

(за умови достатньо великих розмірів повідомлень тривалістю передачі

службових даних можна знехтувати і тривалість виконання операції можна

визначити як ).

Методи логічного зображення топології комунікаційного середовища.

Ряд алгоритмів передачі даних припускає простіший виклад в разі використання

певних топологій мережі між процесорних з’єднань. Крім того, багато методів

комунікації можна отримати з використанням того чи іншого логічного

зображення використовуваної топології. Як результат, важливою при організації

паралельних обчислень є можливість логічного зображення різноманітних

топологій на основі конкретних, фізичних, між процесорних структур.

Способи логічного зображення (відображення) топологій характеризується

наступними трьома основними характеристиками:

- ущільнення дуг (congestion), яке виражається як максимальна кількість дуг

логічної топології, які відображаються в одну лінію передачі фізичної топології;

- подовження дуг (dilation), яке визначається як шлях максимальної

довжини фізичної топології, на якій відображається дуга логічної топології;180

- збільшення вершин (expansion), яке обчислюється як відношення кількості

вершин в логічній та фізичній топологіях.

Для розглядуваних топологій обмежимося питаннями відображення

топологій кільця та решітки на гіперкуб.

Представлення кільцевої топології у вигляді гіперкуба. Встановлення

відповідності між кільцевою топологією та гіперкубом можна виконати з

використанням двійкового рефлексивного коду Грея (binary reflected Gray

code), який визначається у відповідності з виразами:

,

(2.79)

де задає номер значення в коді Грея, а N є довжиною цього коду. Для

ілюстрації на рис. 2.8. показано відображення кільцевої топології на гіперкуб для

мережі з процесорів.

Код Грея для

N=1

Код Грея для

N=1

Код Грея для

N=1

Номери процесорів

гіперкуба кільця

0 0 0 0 0 0 0 0

1 0 1 0 0 1 1 1

1 1 0 1 1 3 2

1 0 0 1 0 2 3

1 1 0 6 4

1 1 1 7 5

1 0 1 5 6

1 0 0 4 7

Рисунок 2.8 –Відображення кільцевої топології на гіперкуб для мережі з

процесорів.

Важлива властивість коду Грея: сусідні значення та мають

тільки одну бітову позицію, що різниться. Як результат, сусідні вершини в

181

кільцевій технології відображаються на сусідні процесори в гіперкубі.

Відображення топології решітки на гіперкуб. Відображення топології

решітки на гіперкуб можна виконати в рамках підходу, використаного для

кільцевої структур мережі. Тоді для відображення решітки на гіперкуб

розмірності можна прийняти правило, що елементу решітки з

координатами відповідає процесор гіперкуба з номером:

.

де операція || означає конкатенацію кодів Грея.

Оцінка трудомісткості операцій передачі даних для кластерних систем.

Для кластерних обчислювальних систем одним з широко застосовуваних способів

побудови комунікаційного середовища є використання концентраторів (hub) чи

(switch) для об’єднання процесорних вузлів кластера в єдину обчислювальну

мережу. В цих випадках топологія мережі кластера представляє собою повний

граф, в якому є певні обмеження на одночасність виконання комунікаційних

операцій. Так, за умови використання концентраторів передача даних в кожний

поточний момент може виконуватися тільки між двома процесорними вузлами;

комунікатори можуть забезпечувати взаємодію декількох пар процесорів, що не

перетинаються. Інший часто використовуваний напрямок при створенні кластерів

полягає у використанні методу передачі пакетів (часто реалізується на основі

стеку протоколів ТСР/ІР) в якості основного способу виконання комунікаційних

операцій.

Якщо вибрати для подальшого аналізу кластери цього поширеного типу

(топологія у вигляді повного графа, пакетний спосіб передачі повідомлень), то

трудомісткість операції комунікації між двома процесорними вузлами можна

оцінити у відповідності з виразом (модель А)

; (2.80)

оцінка подібного типу випливає із співвідношень для методу передачі

пакетів при одиничній довжині шляху передачі даних, тобто . Відмічаючи

можливість подібного підходу, разам з тим слід помітити, що в рамках

розглядуваної моделі тривалість підготовки даних вважається сталою (не

182

залежить від об’єму даних, що передаються), тривалість передачі службових

даних не залежить від кількості пакетів, що передаються, і т.п. Ці припущення

не в повній мірі відповідають дійсності, і часові оцінки, отримувані в результаті

використання моделі, не можуть мати необхідну точність.

З врахуванням наведених зауважень, схема побудови часових оцінок може

бути уточнена; в рамках нової розширеної моделі трудомісткість передачі даних

між двома процесорами визначається у відповідності з такими виразами (модель

В):

(2.81)

де є кількістю пакетів, на яку розбивається повідомлення,

що передається, величина визначає максимальний розмір пакета який може

бути доставлений в мережу (для операційної системи MS Windows в мережі Fast

Ethernet =1500 байт), а є об’єм службових даних в кожному з пакетів, що

пересилаються (для протоколу ТСР/ІР, ОС Windows в мережі Fast Ethernet =78

байт). В наведених співвідношеннях константа характеризує апаратну

складову латентності і залежить від параметрів використовуваного мережевого

обладнання, значення задає тривалість підготовки одного байта даних для

передачі по мережі. Як результат, величина латентності

(2.82)

збільшується лінійно в залежності від об’єму даних, що передаються. При

цьому припускається, що підготовка даних для передачі другого та всіх інших

пакетів може бути суміщена з пересиланням по мережі попередніх пакетів і

латентність не може перевищувати величини:

. (2.83)

Окрім латентності, в запропонованих виразах для оцінки трудомісткості

комунікаційної операції можна уточнити також правило обчислення тривалості

передачі даних

, (2.84)

що дає змогу враховувати ефект збільшення об’єму даних, що передаються,

при зростанні числа пакетів, що пересилаються, за рахунок добавлення службової

183

інформації (заголовків пакетів).

Для практичного застосування перерахованих моделей необхідно виконати

оцінку значень параметрів використовуваних співвідношень. В цьому відношенні

корисним може виявитися використання також простіших способів обчислення

часових витрат на передачу даних - однією з відомих схем подібного типу є

підхід, в якому трудомісткість операції комунікації між двома процесорними

вузлами кластера оцінюється у відповідності з виразом:

, (2.85)

це модель С, запропонована Хокні (the Hockney model).

2.3. Принципи розробки паралельних методів

Розробка алгоритмів (особливо методів паралельних обчислень) для

розв’язку складних задач часто є істотною проблемою. Вважатимемо, що всі

обчислювальні схеми розв’язування задач, які розглядатимуться далі як приклади,

відомі. Ефективні способи організації паралельних обчислень можуть полягати в

наступному:

- виконання аналізу наявних обчислювальних схем і здійснення їх розділу

(декомпозиції) на частини (під задачі), які можна реалізувати в значному ступені

незалежно одна від одної;

- виділення для сформованого набору під задач інформаційних взаємодій,

які повинні здійснюватися в ході розв’язування вихідної поставленої задачі;

- визначення необхідної (або доступної) для розв’язку задачі

обчислювальної системи і виконання розподілу наявного набору під задач між

процесорами системи.

За умови самого загального аналізу зрозуміло, що об’єм обчислень

для кожного використовуваного процесору повинен бути приблизно однаковий -

це дасть змогу забезпечити рівномірне обчислювальне завантаження

(балансування) процесорів. Крім того зрозуміло, що розподіл під задач між

процесорами повинно бути виконано таким чином, щоб кількість інформаційних

зв’язків (комунікаційних взаємодій) між під задачами було мінімальним. Після

виконання всіх перерахованих етапів проектування можна оцінити ефективність

184

розроблюваних паралельних методів: для цього визначаються значення

показників якості породжуваних паралельних обчислень (прискорення,

ефективність, масштабованість). За результатами проведеного аналізу може

виявитися необхідним повторення окремих (в граничному випадку всіх) етапів

розробки. Повернення до попередніх кроків розробки може відбуватися на будь-

якій стадії проектування паралельних обчислювальних схем.

Рисунок 2.9 – Загальна схема розробки паралельних алгоритмів

Тому часто виконуваною додатковою дією в наведеній вище семі

проектування, рис. 2.9, є коригування складу сформованої множини задач після

визначення наявної кількості процесорів - під задачі можуть бути укрупнені

(агреговані) за наявності малої кількості процесорів, або навпаки, деталізовані в

іншому випадку В цілому, ці дії можна означити як масштабування

розроблюваного алгоритму як окремий етап проектування паралельних

обчислень.

Для застосування отриманого в кінцевому підсумку паралельного методу,

необхідно виконати розробку програм для розв’язку сформованого набору під

задач і розмістити розроблені програми по процесорам у відповідності з

вибраною схемою розподілу під задач. для проведення обчислень програми

запускаються на виконання (програми на стадії виконання іменуються 185

процесами), для реалізації інформаційних взаємодій програми повинні мати в

своєму розпорядженні засоби обміну даними (канали передачі повідомлень). Слід

відмітити , що кожний процесор виділяється для розв’язання єдиної під задачі,

проте за наявності великої кількості під задач чи використання обмеженої

кількості процесорів це правило може не витримуватися і, в результаті, на

процесорах може виконуватися одночасно декілька програм (процесів). Зокрема

при розробці та початковій перевірці паралельної програми для виконання всіх

процесів може використовуватися один процесор (за умови розташування на

одному процесорі процеси виконуються в режимі розділення часу).

Можна відмітити, що такий підхід в значній мірі орієнтований на

обчислювальні системи з розподіленою пам’яттю, коли необхідні інформаційні

взаємодії реалізуються за допомогою передачі повідомлень за каналами зв’язку

між процесорами. Тим не менше ця схема може бути застосована без втрати

ефективності паралельних обчислень і для розробки паралельних методів для

систем з загальною пам’яттю - в цьому випадку механізми передачі повідомлень

для забезпечення інформаційних взаємодій повинні бути замінені операціями

доступу до спільних (розділюваних) змінних.

Моделювання паралельних програм. Розглянута схема проектування і

реалізації паралельних обчислень дає спосіб розуміння паралельних алгоритмів і

програм. На стадії проектування паралельний метод може бути представлений у

вигляді графа "під задачі - повідомлення", який представляє собою не що інше, як

укрупнене (агреговане) представлення графа інформаційних залежностей (графа

"операції - операнди").

Аналогічно на стадії виконання для опису паралельної програми можна

використати модель у вигляді графа "процеси - канали", в якій замість під задач

використовується поняття процесор, а інформаційні залежності замінюються

каналами передачі повідомлень. Додатково на цій моделі можна показати

розподіл процесів за процесорами обчислювальної системи, якщо кількість під

задач перевищує чисельність процесорів.

186

Рисунок 2.10 – Модель паралельної програми у вигляді графа "процеси - канали"

Використання двох моделей паралельних обчислень дають змогу краще

розділити проблеми, які проявляються при розробці паралельних методів. Перша

модель - граф "під задачі - повідомлення" - дає змогу зосередитися на питаннях

виділення під задач однакової обчислювальної складності, забезпечуючи при

цьому низький рівень інформаційної складності між під задачами. Друга модель -

граф "процеси - канали" - концентрують увагу на питаннях розподілу під задач за

процесорами, забезпечуючи ще одну можливість зниження трудомісткості

інформаційних взаємодій між під задачами за рахунок розміщення на одних і тих

же процесорах інтенсивно взаємодіючих процесів. Крім того, ця модель дає змогу

краще аналізувати ефективність розробленого паралельного методу і забезпечує

можливість більш адекватного опису процесу виконання паралельних обчислень.

Сутність додаткових пояснень для використовуваних понять в моделі "процеси-

канали" така:

- під процесом розуміють виконувану на процесорі програму, яка

використовує для своєї роботи частину локальної пам’яті процесора і містить ряд

операцій прийому/передачі даних для організації інформаційної взаємодії з

іншими виконуваними процесами паралельної програми;

- канал передачі даних з логічної точки зору можна розглядати як чергу

повідомлень, в яку один чи декілька процесів можуть відправляти дані, що

187

пересилаються, і з яких процес - адресат може добувати повідомлення, які

відправляються іншими процесами.

В загальному випадку, можна вважати, що канали виникають динамічно в

момент виконання першої операції прийому/передачі з каналом. За ступенем

загальності канал може відповідати одній чи кільком командам прийому даних

процесу - одержувачу; аналогічно при передачі повідомлень канал може

використовуватись однією чи кількома командами передачі даних одного чи

кількох процесів. Для зниження складності моделювання і аналізу паралельних

методів вважатимемо, що ємність каналів необмежена і, як результат, операції

передачі даних виконуються практично без затримок простим копіюванням

повідомлень в канал. З іншого боку, операції прийому повідомлень можуть

приводити до затримок (блокування), якщо запитувані з каналу дані ще не були

відправлені процесами - джерелами повідомлень. Слід мати на увазі важливу

перевагу розглянутої моделі "процеси-канали" - в ній проводиться чітке

розмежування локальних (виконуваних на окремому процесорі) обчислень та дій з

організації інформаційної взаємодії одночасно виконуваних процесів. Такий

підхід значно знижує складність аналізу ефективності паралельних методів та

істотно спрощує проблеми розробки паралельних програм.

Етапи розробки паралельних алгоритмів. Розглянемо детальніше

викладену вище методику розробки паралельних алгоритмів. Ця методика

включає етапи виділення під задач, визначення інформаційних залежностей,

масштабування і розподіл під задач за процесорами обчислювальної системи, рис.

2.9.

Розділення обчислень на незалежні частини. Вибір способу розділення на

незалежні частини базується на аналізі обчислювальної схеми рішення вихідної

задачі. Вимоги, яким повинен задовольняти підхід, що вибирається, складається в

забезпеченні рівного об’єму обчислень у під задачах, що виділяються, та

мінімуму інформаційних залежностей між цими під задачами (за інших рівних

умов слід віддавати перевагу рідким операціям передачі повідомлень великого

розміру порівняно з частими пересиланнями даних невеликого об’єму). В

188

загальному випадку, проведення аналізу і виділення задач представляє собою

достатньо складну проблему - вирішенню питання допомагає розв’язати

існування двох типів схем, що часто зустрічаються, рис. 2.11.

Рисунок 2.11 – Розділення даних матриці: а) стрічкова схема, б) блочна схема

Для великого класу задач обчислення зводяться до виконання однотипної

обробки великого набору даних - до такого класу задач відносяться, наприклад,

матричне числення, чисельні методи розв’язку рівнянь в частинних похідних та

ін. В цьому випадку кажуть, існує паралелізм за даними, і виділення під задач

зводиться до розділення наявних даних. Для великої кількості задач розділення

обчислень за даними приводить до породження одно -, двох -, тривимірних

наборів під задач, в яких інформаційні зв’язки існують тільки між найближчими

сусідами (такі схеми часто називаються сітками чи решітками), рис. 2.11.

Рисунок 2.12 – Регулярні одно -, двох - та тривимірні структури базових під задач

після декомпозиції даних

Для іншої частини задач обчислення можуть полягати в виконанні різних

операцій над одним і тим же набором даних - в цьому випадку кажуть про

наявність функціонального паралелізму (як приклад, можна навести задачі

189

обробки послідовності запитів до інформаційних баз даних, обчислення з

одночасним застосуванням різних алгоритмів розрахунку та ін.). Часто

функціональна декомпозиція використовується для організації конвеєрної

обробки даних (наприклад, для виконання певних перетворень даних обчислення

можна звести до функціональної послідовності введення, обробки і збереження

даних). Важливим при виділенні під задач є вибір потрібного рівня декомпозиції

обчислень. Формування максимально можливої кількості під задач забезпечує

використання гранично досяжного рівня паралелізму розв’язуваної задачі, проте

ускладнює аналіз паралельних обчислень. Застосування в разі декомпозиції

обчислень тільки достатньо "крупних" під задач приводить до ясної схеми

паралельних обчислень, проте може ускладнити ефективне використання

достатньо великої кількості процесорів. Можливе розумне поєднання цих двох

підходів може полягати в застосуванні як конструктивних елементів декомпозиції

тільки тих під задач, для яких методи паралельних обчислень відомі. Так при

аналізі задачі матричного множення як під задачі можна використовувати методи

скалярного добутку векторів чи алгоритм матрично-векторного множення.

Подібний проміжний спосіб декомпозиції обчислень дає змогу забезпечити

простоту представлення обчислювальних схем та ефективність паралельних

розрахунків. Під задачі, що вибираються за умови такого підходу, далі

іменуватимуться базовими, вони можуть бути елементарними (неподільними),

якщо не припускають подальшого розділення, чи складовими - в іншому випадку.

Виділення інформаційних залежностей. За наявності обчислювальної

схеми розв’язку задачі після виділення базових під задач визначення

інформаційних залежностей між ними не викликає ускладнень. Етапи виділення

під задач та інформаційних залежностей достатньо складно піддаються

розділенню. Виділення під задач повинно відбуватися з врахуванням необхідних

інформаційних зв’язків, після аналізу об’єму і частоти необхідних інформаційних

об’ємів між під задачами може знадобитися повторення етапу розділення

обчислень. В разі проведення аналізу інформаційних залежностей між під

задачами слід розрізняти (переважні форми інформаційної взаємодії підкреслені):

190

- локальні та глобальні схеми передачі даних - для локальних схем передачі

даних в кожний момент часу виконується тільки між невеликою кількістю під

задач (які розташовані, як правило на сусідніх процесорах), для глобальних

операцій передачі даних в процесі комунікації приймають участь всі під задачі;

- структурні та довільні способи взаємодії - для структурних способів

організації взаємодії приводить до формування певних стандартних схем

комунікації (наприклад, у вигляді кільця, прямокутної решітки і т.д.), для

довільних структур взаємодії схема виконання операцій передач даних не має

характеру однорідності;

- статичні чи динамічні схеми передачі даних - для статистичних схем

моменти та учасники інформаційної взаємодії фіксуються на етапах проектування

та розробки паралельних програм, для динамічного варіанту взаємодії структура

операції передачі даних визначається в ході виконання обчислень;

- синхронні та асинхронні способи взаємодії - для синхронних способів

операції передачі даних виконуються тільки за готовності всіх учасників взаємодії

і завершуються тільки після повного закінчення всіх комунікаційних дій, за

асинхронного виконання операцій учасники взаємодії можуть не очікувати

повного завершення дій з передачі даних. Для представлення способів взаємодії

достатньо складно виділити переважні форми організації передачі даних:

синхронний варіант, як правило, більш простий для застосування, в той час як

асинхронний спосіб часто дає змогу істотно знизити часові затримки, викликані

операціями синхронної взаємодії.

Для оцінки правильності етапу виведення інформаційних залежностей

можна скористатися таким контрольним списком питань:

- чи відповідає обчислювальна складність під задач інтенсивності їх

інформаційних взаємодій?

- чи є однаковою інтенсивність інформаційних взаємодій для різних під

задач?

- чи є схема інформаційної взаємодії локальною?

- чи не перешкоджає виявлена інформаційна залежність паралельному

191

розв’язку під задач?

Масштабування набору під задач. Масштабування розробленої

обчислювальної схеми паралельних обчислень проводиться у випадку, якщо

кількість наявних під задач відрізняється від числа планованих до використання

процесорів. Для скорочення кількості під задач слід виконати укрупнення

(агрегацію) обчислень. Застосовувані тут правила співпадають з рекомендаціями

початкового етапу виділення під задач: під задачі, що визначаються, як і раніше,

повинні мати однакову обчислювальну складність, а об’єм та інтенсивність

інформаційних взаємодії між під задачами повинні залишатися на мінімально

можливому рівні. Як результат, першими претендентами на об’єднання є під

задачі з високим ступенем інформаційної взаємозалежності. За недостатньої

кількості наявних під задач для завантаження всіх доступних для використання

процесорів слід виконати деталізацію (декомпозицію) обчислень. Як правило,

проведення подібної декомпозиції не викликає будь-яких ускладнень, якщо для

базових задач методи паралельних обчислень відомі.

Виконання етапу масштабування обчислень повинно звестися, в кінцевому

підсумку, до розробки правил агрегації та декомпозиції під задач, які повинні

параметрично залежать від чисельності процесорів, застосовуваних для

обчислень.

Список контрольних питань для оцінки правильності етапу масштабування

такий:

- чи не погіршиться локальність обчислень після масштабування наявного

набору під задач?

- чи мають під задачі після масштабування однакову обчислювальну та

комунікаційну складність?

- чи відповідає кількість задач чисельності наявних процесорів?

- чи залежать параметричні правила масштабування від кількості

процесорів?

Розподіл під задач між процесорами. Розподіл під задач між процесорами

є завершальним етапом розробки паралельного методу. Слід відмітити, що

192

управління розподілом навантаження для процесорів можливе тільки для

обчислювальних систем з розподіленою пам’яттю, для мультипроцесорів (систем

із спільною пам’яттю) розподілення навантаження, як правило, виконується

операційною системою автоматично. Крім того, цей етап розподілу під задач між

процесорами є надлишковим, коли кількість під задач співпадає з чисельністю

наявних процесорів, а топологія мережі передачі даних обчислювальної системи є

повним графом (тобто всі процесори пов’язані між собою прямими лініями

зв’язку). Основний показник успішності виконання даного етапу - ефективність

використання процесорів, яка визначається як відносна частка часу, протягом

якого процесори використовувалися для обчислень, пов’язаних з розв’язком

вихідної задачі. Шляхи досягнення позитивних результатів в цьому напрямку

залишаються попередніми: як і раніше, слід забезпечити рівномірний розподіл

обчислювального навантаження між процесорами і мінімізувати кількість

повідомлень, що передаються між ними. Як і в попередніх етапах проектування,

оптимальне рішення проблеми розподілу під задач між процесорами базується на

аналізі інформаційної зв’язності графа "під задачі - повідомлення". Зокрема, під

задачі, що мають інформаційні взаємодії, доцільно розміщати на процесорах, між

якими існують прямі лінії передачі даних. Вимога мінімізації інформаційних

обмінів між процесорами може суперечити умові рівномірного завантаження.

Можна розмістити всі під задачі на одному процесорі і повністю усунути між

процесорну передачу повідомлень, проте завантаження більшості процесорів в

цьому випадку буде мінімальним.

Розв’язком питань балансування обчислювального навантаження значно

ускладнюється, якщо схема обчислень може змінюватися в ході розв’язування

задачі. причиною цього можуть бути неоднорідні сітки при розв’язуванні рівнянь

в частинних похідних, розрідженість матриць та ін. Використовувані на етапах

проектування оцінки обчислювальної складності рішення під задач можуть мати

наближений характер, а кількість під задач може змінюватися в ході обчислень.

Тоді може знадобитися перерозподіл базових під задач між процесорами вже

безпосередньо в ході виконання паралельної програми (тобто доведеться

193

виконати динамічне балансування обчислювального навантаження). Ці питання

досить складні в галузі паралельних обчислень, всі вони виходять за межі цього

навчального курсу.

Для прикладу коротко охарактеризуємо спосіб динамічного управління

розподілом обчислюваного навантаження, який називається схемою "менеджер-

виконавець" (the manager-worker scheme), При використанні цього підходу

припускається, що під задачі можуть виникати і завершуватися в ході обчислень,

при цьому інформаційні взаємодії між під задачами або повністю відсутні, або

мінімальні. У відповідності з цією схемою для управління розподілом

навантаження в системі виділяється окремий процесор-менеджер, якому доступна

інформація про всі наявні під задачі. інші процесори системи є виконавцями, які

для отримання обчислювального навантаження звертаються до процесора-

менеджера. Породжувані в ході обчислень нові під задачі передаються назад

процесору-менеджеру і можуть бути отримані для розв’язку за умови наступних

звертань процесорів-виконавців. Завершення обчислень відбувається в момент,

коли процесори-виконавці завершили рішення всіх переданих їм під задач, а

процесор-менеджер не має яких-небудь обчислювальних навантажень для

виконання. Доцільними є наступні питання для перевірки етапу розподілу під

задач:

- чи не призводить розподіл декількох задач на один процесор до зростання

додаткових обчислювальних витрат?

- чи існує необхідність динамічного балансування обчислень?

- чи не є процесор-менеджер "вузьким" місцем при використанні схеми

"менеджер-виконавець"?

Паралельне рішення гравітаційної задачі N тіл. Багато задач в галузі

фізики приводяться до операцій обробки даних для кожної пари об’єктів наявної

фізичної системи. Такою задачею є, зокрема, проблема, відома як гравітаційна

задача N тіл (чи просто задачі N тіл). В загальному вигляді ця задача описується

наступним чином. Нехай є велика кількість тіл, для кожного з яких відома маса,

початкове положення та швидкість. Під дією гравітації положення тіл змінюється,

194

і потрібне рішення задачі полягає в моделюванні динаміки зміни системи N тіл

протягом певного заданого інтервалу часу. Для проведення такого моделювання

заданий інтервал часу розбивається на часові відрізки невеликої тривалості і далі

на кожному кроці моделювання обчислюються сили, які діють на кожне тіло, а

потім оновлюються швидкості та положення тіл. Очевидний алгоритм рішення

задачі N тіл полягає в аналізуванні на кожному кроці моделювання всіх пар

об’єктів фізичної системи і виконанні для кожної отримуваної пари всіх

необхідних розрахунків. Як результат, за такого підходу тривалість виконання

однієї ітерації моделювання складатиме

, (2.86)

де - тривалість пере обчислення параметрів однієї пари тіл.

Тобто обчислювальна схема розглянутого алгоритму є порівняно простою,

що дає змогу використати задачу N тіл як ще однією наглядною демонстрацією

застосування методики розробки паралельних алгоритмів.

Розділення обчислень на незалежні частини. Вибір способу розділення

обчислень не викликає жодних ускладнень - очевидний підхід полягає у виборі як

базової під задачі всього набору обчислень, пов’язаних з обробкою даних якогось

одного тіла фізичної системи.

Виділення інформаційних залежностей. Виконання обчислень, пов’язаних

з кожною під задачею, стає можливим тільки у випадку, коли в під задачах є дані

(положення та швидкості пересувань) про всі тіла фізичної системи. Як результат,

перед початком кожної ітерації моделювання кожна під задача повинна отримати

всю необхідну інформацію від всіх інших під задач системи. Така процедура

передачі даних називається операцією збирання даних. В розглядуваному

алгоритмі ця операція повинна бути виконана для кожної під задачі - такий

варіант передачі даних називається операцією узагальненого збору даних.

Визначення вимог до необхідних результатів інформаційного обміну не

приводить до однозначного встановлення потрібного інформаційного обміну між

під задачами - досягнення потрібних результатів може бути забезпечено за

допомогою різних алгоритмів виконання операції узагальненого збору даних

195

Найпростіший спосіб виконання необхідного інформаційного обміну полягає в

реалізації послідовності кроків, на кожному з яких всі наявні під задачі

розбиваються попарно і обмін даними здійснюється між під задачами утворених

пар. За належної організації попарного розділення під задач (N-1) - кратне

повторення описаних дій приведе до повної реалізації потрібної операції збору

даних.

Розглянутий метод організації інформаційного обміну достатньо

трудомісткий - для збору всіх необхідних даних слід провести N-1 ітерацію, на

кожній з яких виконується одночасно N/2 операцій передачі даних. Для

скорочення потрібної кількості ітерацій можна звернути увагу на факт, що після

виконання першого кроку операції збору даних під задачі будуть вже містити не

тільки свої дані, але й дані під задач для обміну даних відразу про два тіла

фізичної системи - тим самим, після завершення другої ітерації кожна під задача

міститиме відомості про чотири тіла системи і т.д. Цей спосіб реалізації обмінів

дає змогу завершити необхідну процедуру за ітерацій. За цих умов об’єм

даних, що пересилаються в кожній операції обміну, подвоюється від ітерації до

ітерації: на першій ітерації між під задачами пересилаються дані про одне тіло

системи, на другій - про два тіла і т.д.

Масштабування і розподіл під задач по процесорам. Чисельність тіл

системи N значно перевищує кількість процесорів . Тому розглянуті раніше під

задачі слід укрупнити, об’єднавши в рамках однієї під задачі обчислення для

групи з N/ тіл. Після проведення такої агрегації чисельність під задач і кількість

процесорів співпадатиме і при розподілі під задач між процесорами залишиться

забезпечити наявність прямих комунікаційних ліній між процесорами з під

задачами, у яких змінюються інформаційні обміни при виконанні операції збору

даних.

Аналіз ефективності паралельних обчислень. Оцінимо ефективність

розроблених способів паралельних обчислень для розв’язку задачі N тіл. Оскільки

запропоновані варіанти відрізняються тільки методами виконання інформаційних

обмінів, для порівняння підходів достатньо визначити тривалість операції

196

узагальненого збору даних. Використаємо для оцінки тривалості передачі

повідомлень модель, запропоновану Хокні, - тоді тривалість виконання операції

збору даних для першого варіанту паралельних обчислень можна виразити як

, (2.87)

де - параметри моделі Хокні (латентність та пропускна здатність мережі

передачі даних), а задає об’єм даних, що пересилаються, для одного тіла

фізичної системи.

Для другого способу інформаційного обміну об’єм даних, що

пересилаються на різних ітераціях збору даних, відрізняється. На першій ітерації

об’єм повідомлень, що пересилаються, складає , на другій ітерації цей об’єм

збільшується вдвічі і становить 2 і т.д. В загальному випадку, для ітерації з

номером об’єм повідомлень оцінюється як . Як результат, тривалість

виконання операції збору даних в цьому випадку визначається виразом:

.

(2.89)

Порівняння отриманих виразів показує, що другий розроблений спосіб

паралельних обчислень має істотно вищу ефективність, потребує менших

комунікаційних витрат і допускає кращу масштабованість за умови збільшення

кількості використовуваних процесорів.

Контрольні питання

1. Що розуміється під поняттям "паралельні обчислення"?

2. Які основні типи кластерів використовуються в США?

3. Яким чином класифікуються обчислювальні системи за Флінном?

4. Які показники характеризують топології мережі даних?

5. В чому полягає сутність закону Амдаля?

6. В чому полягає сутність функціонального паралелізму?

197

3 ПАРАЛЕЛЬНЕ ПРОГРАМУВАННЯ

В обчислювальних системах з розподіленою пам’яттю процесори

функціонують незалежно один від одного. Для організації паралельних обчислень

в таких умовах необхідно мати можливість розподіляти обчислювальне

навантаження та організувати інформаційну взаємодію (передачу даних) між

процесорами. Рішення цих питань забезпечує інтерфейс передачі даних (message

passing interface - MPI). В загальному плані, для розподілу обчислень між

процесорами необхідно проаналізувати алгоритм розв’язку задачі, виділити

інформаційні незалежні фрагменти обчислень, провести їх програмну реалізацію і

потім розмістити отримані частини програми на різних процесорах. В рамках МРІ

прийнятий простіший підхід - для рішення поставленої задачі розробляється одна

програма, яка запускається одночасно на виконання на всіх наявних процесорах.

Для уникнення ідентичності обчислень на різних процесорах, можна підставляти

різні дані для програми на різних процесорах та використовувати наявні в МРІ

засоби для ідентифікації процесора, на якому виконується програма (тим самим

надається можливість організувати в обчисленнях в залежності від

використовуваного програмою процесора). Такий спосіб організації паралельних

обчислень отримав назву моделі "дона програма множина процесів" (single

program multiple processes or SPMP).

Для організації інформаційної взаємодії між процесорами інформаційної

взаємодії між процесорами в самому мінімальному варіанті достатньо операцій

прийому і передачі даних(повинна існувати технічна можливість комунікації між

процесорами - канали чи лінії зв’язку). В МРІ існує ціла множина операцій

передачі даних, які забезпечують різні способи пересилання даних, реалізують

практично всі раніше розглянуті комунікаційні операції. Саме ці можливості є

найбільш сильною стороною МРІ. Намагання створення програмних засобів

передачі даних між процесорами почали здійснюватись практично відразу з

появою локальних комп’ютерних мереж. Проте ці засоби часто були часто

незрозумілими і несумісними. Тобто одна з самих серйозних проблем в

198

програмуванні - переносимість програм при переведенні програмного

забезпечення на інші комп’ютерні системи - проявлялась при розробці

паралельних програм в максимальному ступені. Як результат, вже з 90 - х років

ХХ ст. стали вживатися заходи із стандартизації засобів організації передачі

повідомлень в багатопроцесорних обчислювальних системах. Початком робіт, що

призвели до появи МРІ, послужило проведення робочої наради із стандартів для

передачі повідомлень в середовищі розподіленої пам’яті (the Workshop on

Standards for Message Passing in a Distributed Memory Environment, Williamsburg,

Virginia, USA, April 1992). За підсумками наради була утворена робоча група ,

пізніше перетворена в міжнародне товариство МРІ Forum, результатом діяльності

якого було створення і прийняття в 1994 р. стандарту інтерфейсу передачі

повідомлень (message passing interface - MP) версії 1.0. В наступні роки стандарт

МРІ послідовно розвивався. В 1997 р. був прийнятий стандарт МРІ версії 2.0.

Тепер можна пояснити значення поняття МРІ. По-перше, МРІ - це стандарт,

якому повинні задовольняти засоби організації передачі повідомлень. По-друге -

це програмні засоби, які забезпечують можливості передачі повідомлень і при

цьому відповідають всі вимогам стандарту МРІ. Так, за стандартом ці програмні

засоби повинні бути організовані у вигляді бібліотек програмних функцій

(бібліотека МРІ) і повинні бути доступними для найбільш використовуваних

алгоритмічних мов С та Fortran. Подібну "двоїстість" МРІ слід враховувати при

використанні термінології. Як правило, абревіатура МРІ застосовується при

згадуванні стандарту, а сполучення "бібліотека МРІ" вказує ту чи іншу

програмну реалізацію стандарту. Проте достатньо часто для скорочення

позначення МРІ використовується для бібліотек МРІ, і, тим самим, для

правильної інтерпретації терміну слід враховувати контекст.

Питання, пов’язані з розробкою паралельних програм з використанням МРІ,

достатньо добре розглянутий в літературі. Наведемо ряд важливих позитивних

обставин:

- МРІ дає змогу в значному ступені знизити гостроту проблеми перенесення

паралельних програм між різними компонентами системи - паралельна програма,

199

розроблена на алгоритмічній мові С чи Fortran з використанням бібліотеки МРІ,

як правило, працюватиме на різних обчислювальних платформах;

- МРІ сприяє підвищенню ефективності паралельних обчислень, оскільки

нині практично для кожного типу обчислювальних систем існують реалізації

бібліотек МРІ, які в максимальному ступені враховують можливості

комп’ютерного обладнання;

- МРІ зменшує складність розробки паралельних програм, оскільки більша

частина раніше нами розглянутих основних операцій передачі даних

передбачається стандартом МРІ, з іншого боку, вже є велика кількість бібліотек

паралельних методів, створених з використанням МРІ.

МРІ: основні поняття та означення

Розглянемо основні поняття та означення, які є основоположними для

стандарту МРІ.

Поняття паралельної програми. Під паралельною програмою в рамках

МРІ розуміють множину одночасно виконуваних процесів. Процеси можуть

виконуватися на різних процесорах, але на одному процесорі можуть

розташовуватися і декілька процесів (в цьому випадку їх виконання здійснюється

в режимі розділення часу). В граничному випадку для виконання паралельної

програми може використовуватися один процесор - як правило, такий спосіб

застосовується для початкової перевірки правильності паралельної програми.

Кожний процес програми породжується на основі копії одного і того ж

програмного коду (модель SPMP). Цей програмний код, зображуваний у вигляді

виконуваної програми, повинен бути доступним в момент запуску паралельної

програми на всіх використовуваних процесорах. Вихідний програмний код для

виконуваної програми розроблюється на алгоритмічних мовах С чи Fortran із

застосуванням тієї чи іншої реалізації бібліотеки МРІ.

Кількість процесів та чисельність використовуваних процесорів

визначається в момент запуску паралельної програми засобами середовища

виконання МРІ - програм і в ході обчислень не може змінюватися без

застосування спеціальних, але рідко задіяних засобів динамічного породження

200

процесів та управління ними, які з’явилися в стандарті МРІ версії 2.0. Всі процеси

програми послідовно перенумеровані від ) до , де є загальна кількість

процесорів. Номер процесу іменується рангом процесу.

Операції передачі даних. Основу МРІ складають операції передачі

повідомлень. Серед передбачених в складі МРІ функцій розрізняють парні (point-

to-point) операції між двома процесами та колективні (collective) комунікаційні дії

для одночасної взаємодії декількох процесів.

Для виконання парних операцій можна використовувати різні режими

передачі, серед яких: синхронний, блокуючий та ін. - повний перелік можливих

режимів буде розглянутий далі. До стандарті МРІ включено більшість основних

операцій передачі даних.

Поняття комунікаторів. Процеси паралельної програми об’єднуються в

групи. Іншим важливим поняттям МРІ, що описує набір процесів, є поняття

комунікатора. Під комунікатором в МРІ розуміють спеціально створюваний

службовий об’єкт, який об’єднує в своєму складі групу процесів і ряд додаткових

параметрів (контекст), використовуваних при виконанні операцій передачі даних.

Парні операції передачі даних виконуються тільки для процесів, які

належать одному і тому ж комунікатору. Колективні операції застосовуються

одночасно для всіх процесів одного комунікатора. Як результат, вказівка на

використовуваний комунікатор є обов’язковою для операцій передачі даних в

МРІ. В ході обчислень можуть створюватися нові та видалятися існуючі групи

процесів та комунікатори. Один і той же процес може належати різним групам і

комунікаторам. Всі наявні в паралельній програмі процеси входять до складу

конструйованого за умовчанням комунікатора з ідентифікатором

MPI_COMM_WORLD. У версії 2.0 стандарту з’явилася можливість створювати

глобальні комунікатори (intercommunicator), які об’єднують в одну структуру

пару груп за необхідності виконання колективних операцій між процесами з

різних груп. Детальній розгляд можливостей МРІ для роботи з групами і

комунікаторами буде даний далі.

Типи даних. При виконанні операцій передачі повідомлень для вказівки

201

даних в функціях МРІ, які передаються чи отримуються, необхідно вказувати тип

даних, що пересилаються. МРІ містить великий набір базових типів даних, що

багато в чому співпадають з типами даних в алгоритмічних мовах С чи Fortran.

Крім того, в МРІ є можливості створення нових похідних типів даних для більш

точного і короткого опису вмісту повідомлень, що пересилаються. Детальний

розгляд можливостей МРІ для роботи з похідними типами даних буде виконаний

далі.

Віртуальні технології. Парні операції передачі даних можна виконати між

будь-якими процесами одного і того ж комунікатора, а в колективній операції

приймають участь всі процеси комунікатора. Логічна топологія ліній зв’язку між

процесами має структуру повного графа (незалежно від наявності реальних

фізичних каналів зв’язку між процесорами). Для подальшого викладу і аналізу

ряду паралельних алгоритмів доцільним є логічне представлення наявної

комунікаційної мережі у вигляді тих чи інших топологій.

В МРІ є можливість представлення множини процесів у вигляді решітки

довільної розмірності, рис. 2.1. Граничні процеси решіток можуть бути оголошені

сусідніми, і, тим самим, на основі решіток можуть бути означені структури типу

тор. Крім того, в МРІ є засоби також для формування логічних (віртуальних)

топологій будь-якого потрібного типу. Детальний розгляд можливостей МРІ для

роботи з топологіями буде здійснений далі. Перед початком розгляду МРІ

звернемо увагу на наступні зауваження:

- опис функцій та всі приклади програм, що наводитимуться, будуть

представлені на алгоритмічній мові С; особливості використання МРІ для

алгоритмічної мови Fortran будуть розглянуті далі;

- коротка характеристика наявних реалізацій бібліотек МРІ та загальний

опис середовища виконання МРІ - програм будуть розглянуті далі;

- основне викладення можливостей МРІ буде зорієнтовано на стандарт

версії 1.2 (так званий МРІ-1), нововведення стандарту версії 2.0 будуть розглянуті

далі.

Приступаючи до вивчення МРІ, можна відмітити, що МРІ є достатньо

202

складним - в стандарті МРІ передбачається наявність більше ніж 120 функцій. З

іншого боку, структура МРІ є старанно продуманою - розробка паралельних

програм може бути розпочата вже після розгляду 6 функцій МРІ. Всі додаткові

можливості МРІ можна засвоїти у міру зростання складності розроблюваних

алгоритмів і програм. Виклад матеріалу від простого до складного буде основою

подальшого викладу навчального матеріалу.

Вступ до розробки паралельних програм з використанням МРІ

Основи МРІ. Наведемо мінімально необхідний набір функцій МРІ,

достатній для розробки порівняно простих паралельних програм.

Ініціалізація та завершення МРІ - програм. Першою функцією МРІ, що

викликається, повинна бути функція:

int MPI_Init(int *argc, char ***argv),

де

- argc - вказівник на кількість параметрів командної стрічки,

- argv - параметри командної стрічки,

яка застосовується для ініціалізації середовища виконання МРІ - програми.

Параметрами функції є кількість аргументів в командній стрічці та адреса

вказівника на масив символів тексту самої командної стрічки.

Останньою функцією МРІ, що викликається, обов’язково повинна бути

функція:

int MPI_Finalize (void).

Як результат, можна відмітити, що структура паралельної програми,

розроблена з використанням МРІ, повинна мати наступний вигляд:

#include ’’mpl. h’’

int main(int argc, char *argv[ ] {

<програмний код без використання функцій МРІ>

MPI_Init (&argc, &argv);

<програмний код з використанням функцій МРІ>

MPI_Finalize();

203

<програмний код без використання функцій МРІ>

return 0;

}

Слід відмітити наступне:

- файл mpi. h містить означення іменованих констант, прототипів функцій та

типів даних бібліотеки МРІ;

- функції MPI_Init є обов’язковими і повинні бути виконані (тільки один

раз) кожним процесом паралельної програми;

- перед викликом MPI_Init може бути виконана функція MPI_Initialized для

означення того, чи був раніше виконаний виклик MPI_Init, а після виклику

MPI_Finalized (ця функція з’явилася тільки в стандарті МРІ 2.0) аналогічного

призначення.

Розглянуті приклади функцій дають представлення синтаксису іменування

функцій в МРІ. Імені функції передує префікс МРІ, далі слідує одне чи декілька

слів назви, перше слово в імені функції починається з заголовкового слова, слова

розділяються знаком підкреслювання. Назви функцій МРІ, як правило,

пояснюють призначення виконуваних функцій дії.

Означення кількості та рангу процесів. Означення кількості процесів у

виконуваній паралельній програмі з використанням функції:

int MPI_size(MPI_Comm, comm int *size),

де

- comm - комунікатор, розмір якого визначається,

-size - кількість процесів в комунікаторі, яка визначається.

Для визначення рангу процесу використовується функція:

int MPI_Com_rank(MPI_Comm comm, int *rank),

де -

- comm - комунікатор, в якому визначається ранг процесу,

- rank - ранг процесу в комунікаторі.

Як правило, виклик функції MPI_Comm_size та MPI_Comm_rank

204

виконується відразу після MPI_Init для отримання більшої кількості процесів і

рангу поточного процесу:

#include "mpi . h"

int main(int argc, char *argv[ ]) {

int ProcNum, ProcRank;

<програмний код без використання функцій МРІ>

МРІ_Init(&argc, &argv);

<програмний код з використанням функції МРІ>

MPI_Finalize();

<програмний код без використання функції МРІ>

return 0;

}

Слід відмітити:

- файл mp.h містить означення іменованих констант, прототипів функцій і

типів даних бібліотеки МРІ;

- функції MPI_Init та MPI_Finalize є обов’язковими і повинні бути виконані

(тільки один раз) кожним процесом паралельної програми;

- перед викликом MPI_Init може бути використана функція MPI_Initialize

для визначення того, чи був раніше виконаний виклик MPI_Init, а після виклику

MPI_Initialize- MPI_Finalized (ця функція з’явилася тільки в стандарті МРІ версії

2.0) аналогічного призначення.

Розглянуті приклади функцій дають уявлення синтаксису іменування

функцій в МРІ. Імені функції передує префікс МРІ, далі слідує одне чи декілька

слів назви, перше слово в імені функції починається із заголовкового символу,

слова розділяються знаком підкреслювання. Назви функції МРІ, як правило,

пояснюють призначення виконуваних функцією дій.

Визначення кількості і рангу процесів. Визначення кількості у

виконуваній паралельній програмі здійснюється з використанням функції:

int MPI_Comm_size(MPI_Comm comm, int *size),

205

де

- comm - комунікатор, розмір якого визначається,

- size - кількість процесів в комунікаторі, що визначається.

Для визначення рангу процесу використовується функція:

int MPI_Comm_rank(MPI_Comm comm, int *rank),

де

- comm - комунікатор, в якому визначається ранг процесу,

- rank - ранг процесу в комунікаторі.

Як правило, виклик функцій MPI_Comm_size та MPI_Comm_rank

виконується зразу після MPI_ Init для отримання загальної кількості процесів і

рангу поточного процесу:

#include "mpi h"

int main(int argc, char *argv[ ] {

int ProcNum, ProcRanc;

<програмний код без використання функцій МРІ>

МРІ_Init(&argc, &argv);

MPI_Comm_size(MPI_COMM_WORLD, &ProcNum);

MPI_Comm_ranc(MPI_COMM_WORLD, &ProcRank);

<програмний код з використанням функцій МРІ>

МРІ_Finalize();

<програмний код без використання функцій МРІ>

return 0;

}

Слід відмітити:

- комунікатор MPI_COMM_WORLD, як вже зазначалося, створюється за

умовчанням і представляє всі процеси виконуваної паралельної програми;

- ранг, отриманий з використанням функції MPI_Comm_rank, є рангом

процесу, який виконав виклик цієї функції, тобто змінна ProcRank прийме різні

значення у різних процесів.

Передача повідомлень. Для передачі повідомлень-відправник повинен

206

виконати функцію:

int MPI_Send(void *buf, int count, MPI_Datatype type, int dest,

int tag, MPI_Comm comm),

де

- buf - адреса буфера пам’яті, в якому розташовані дані відправленого

повідомлення;

- count - кількість елементів даних повідомлення;

- type - тип елементів даних повідомлення, що пересилається;

- dest - ранг процесів, якому відправляється повідомлення;

- tag - значення-тег, яке використовується для ідентифікації

повідомлення;

- comm - комунікатор, в рамках якого виконується передача даних.

Для вказівки типу даних в МРІ, що пересилаються, є ряд базових типів,

повний список яких наведено в табл. 3.1.

Таблиця 3.1 – Базові (визначені) типи даних МРІ для алгоритмічної мови С

Тип даних МРІ Тип даних С

MPI_BYTE

MPI_CHAR signed char

MPI_DOUBLE double

MPI_FLOAT float

MPI _NT int

MPI_LONG long

MPI_LONG DOUBLE long double

MPI_PACKED

MPI_SHORT short

MPI_UNSIGNED_CHAR unsigned char

MPI_UNSIGNED unsigned int

MPI_UNSIGNED_LONG unsigned long

MPI_UNSIGNED_SHORT unsigned short

207

Слід зауважити:

- повідомлення, що відправляється, визначається через вказівку блоку

пам’яті (буфера), в якому це повідомлення розташовується. Використовувана для

вказівки буферу тріада

(buf, count, type)

входить до складу практично всіх функцій передачі даних;

- процеси між якими виконується передача даних, в обов’язковому порядку

повинні належати комунікатору, вказаному в функції MPI_Send;

- параметр tag використовується за необхідності розрізнювання

повідомлень, що передаються, в іншому випадку в якості значення параметра

можна використати довільне додатне ціле число (максимально можливе ціле

число не може бути більшим ніж та, що визначається реалізацією константа

MPI_TAG_UB) див. також опис функції MPI_Recv.

Відразу після завершення функції MPI_Send процес-відправник може

почати повторно використовувати буфер пам’яті, в якому розташовувалось

повідомлення, що відправлялось. Таким же чином слід розуміти, що в момент

завершення функції MPI_Send стан самого повідомлення, що пересилається може

бути різним: повідомлення може бути розташоване в процесі-відправнику, може

знаходитися в процесі-одержувачі чи може бути прийнято процесом одержувачем

з використанням функції MPI_Recv. Тобто завершення функції MPI_Send означає

лише те, що операція передачі початку виконується і пересилка повідомлення

рано чи пізно буде виконана. Приклад використання функції буде представлений

після опису функції MPI_Recv.

Прийом повідомлень. Для прийому повідомлення процес-отримувач

повинен виконувати функцію:

int MPI_Recv(void *buf, int count, MPI_Datatype type, int source,

int tag, MPI_Comm comm, MPI_Status *status) ,

де

- buf, count, type - буфер пам’яті для прийому повідомлення, призначення

208

кожного окремого параметра відповідає опису в MPI_Send;

- source - ранг процесу, від якого повинен буде виконаний прийом

повідомлення;

- tag - тег повідомлення, яке повинно бути прийнято для процесу;

- comm - комунікатор, в рамках якого виконується передача даних;

- status - вказівник на структуру даних з інформацією про результати

виконання операції прийому даних.

Слід відмітити:

- буфер пам’яті повинен бути достатнім для прийому повідомлення. За

нехватки пам’яті частина повідомлення буде втрачена і в ході завершення функції

буде зафіксована похибка переповнення; з іншого боку, повідомлення, що

приймається, може бути коротшим, порівняно з прийомним буфером, в цьому

випадку змінюється тільки ділянки буфера, які торкаються прийнятого

повідомлення;

- типи елементів повідомлення, що передається та приймається, повинні

співпадати;

- за необхідності прийому повідомлення від будь-якого процесу-

відправника для параметра source може бути вказано значення

MPI_ANY_SOURCE (на відміну від функції передачі MPI_Send, яка відсилає

повідомлення строго певному адресату);

- за необхідності прийому повідомлення з будь-яким тегом для параметра

tag може бути вказано значення MPI_ANY_TAG (за умови використання функції

MPI_Send повинно бути вказано конкретне значення тегу);

- на відміну від параметрів "процес-одержувач" та "тег", параметр

"комунікатор" не має значення, яке означає "будь-який комунікатор";

- параметр status дає змогу визначити ряд характеристик прийнятого

повідомлення:

int MPI_Get_count(MPI_Status *status, MPI_Datatype type,

int *count),

де

209

- status- статус операції MPI_Recv;

- type- тип прийнятих даних;

- count - кількість елементів даних в повідомленні.

Виклик функції MPI_Recv не повинен бути узгодженим з часом виклику

відповідної функції передачі повідомлення MPI_Send - прийом повідомлення

може бути ініційований до моменту, на момент чи після моменту початку

відправлення повідомлення. По завершенню функції MPI_Recv в заданому буфері

пам’яті буде розташовано прийняте повідомлення. Принциповий момент в цьому

випадку полягає в тому, що функція MPI_Recv блокувальна для процесу

одержувача, тобто його виконання призупиняється до завершення роботи функції.

Тобто, якщо з якихось причин очікуване для прийому повідомлення буде

відсутнє, то виконання паралельної програми буде блоковано.

Перша паралельна програма з використанням МРІ. Розглянутий набір

функцій виявляється достатнім для розробки паралельних програм (кількість

функцій МРІ, необхідних для початку розробки паралельних програм, становить

6). Програма, що наводиться нижче, є стандартним прикладом для алгоритмічної

мови С.

Програма 3.1 – Перша паралельна програма з використанням МРІ.

#include <atdio. h>

#include "mpi.h"

int main(int argc, char* argv[ ]{

int ProcRank, RecRank;

MPI_Status Status;

MPI_Init(&arc, &argv);

MPI_Comm_size(MPI_COMM_WORLD, &ProcMum);

MPI_Comm_rank(MPI_COMM_WORLD, &ProcRank);

if ( ProcRanc ==0 ){

// Дії виконувані тільки процесом з рангом 0

print("\n Hello from process %3d" , ProcRank);

210

for ( int i = 1; i < ProcNum; 1++ ) {

MPI_Recv(&RecvRank, 1, MPI_INT, MPI_ANY_SOURCE,

MPI_ANY_TAG, MPI_COM_WORLD, &Status);

printf("\n Hello from process %3d" , RecvRank);

}

}

else // Повідомлення, відправлене всіма процесми.

// крім процесів з рангом 0

MPI_Send(&ProRank, 1 MPI_INT, 0, 0, MPI_COMM_W)RLD);

MPI_Finalize();

}

Як випливає з тексту програми, кожний процес визначає свій ранг, після

чого дії в програмі розділяються. Всі процеси, крім процесу з рангом 0, передають

значення свого рангу нульовому процесу. Процес з рангом 0 спочатку друкує

значення свого рангу, а далі послідовно приймає повідомлення з рангами процесів

і також друкує їх значення. Слід відмітити, що порядок прийому повідомлень

завчасно не визначений і залежить від умов виконання паралельної програми (цей

порядок може змінюватися від запуску до запуску). Можливий варіант

результатів друку процесу ) може полягати в наступному (для паралельної

програми з чотирьох процесів):

Hello from process 0

Hello from process 2

Hello from process 1

Hello from process 3

Такий "плаваючий" тип отриманих результатів істотно ускладнює

розробку, тестування та налагодження паралельних програм, оскільки в цьому

випадку зникає один з основних принципів програмування - повторюваність

виконуваних обчислювальних експериментів. Як правило, якщо це не приводить

до втрати ефективності, слід забезпечувати однозначність розрахунків також при

використанні паралельних обчислень. Для розглядуваного простого прикладу

211

можна поновити постійність отримуваних результатів з використанням задавання

рангу процесу-відправника в операції прийому повідомлення:

MPI_Recv(&RecvRank, 1, MPI_ANY_TAG, MPI_COMM_WORLD,

&Status) .

Вказівка рангу процесу-відправника регламентує порядок прийому

повідомлень та терміни друкування будуть з’являтися строго в порядку зростання

рангів процесів (таке регламентування в окремих ситуаціях) може призводити до

уповільнення виконуваних паралельних обчислень). Розроблювана з

використанням МРІ програма, як в даному частковому варіанті, так і в самому

загальному випадку, використовується для породження всіх процесів паралельної

програми і повинна визначати обчислення, виконувані всіма цими процесами.

Тобто МРІ - програма є певною "мікропрограмою", різні частини якої

використовуються різними процесами. В наведеному прикладі програми виділені

рамкою ділянки програмного коду не виконуються одночасно жодним з процесів,

Перша з виділених ділянок з функцією прийому MPI_Recv виконується тільки

процесом з рангом 0, друга ділянка з функцією передачі MPI_Send задіється всіма

процесами, за виключенням нульового процесу.

Для розділення фрагментів коду між процесами використовується підхід,

який застосований у тільки розглянутій програмі, -з використанням функції

MPI_Comm_rank визначається ранг процесу, потім у відповідності з рангом

виділяються необхідні для процесу ділянки програмного коду. Наявність в одній і

тій же програмі фрагментів коду різних процесів також значно ускладнює

розуміння і, в цілому розробку МРІ - програми. В результаті можна

рекомендувати при збільшенні об’єму розроблюваних програм виносити

програмний код різних процесів в окремі програмні модулі (функції). Загальна

схема МРІ - програми в цьому випадку матиме вигляд:

MPI_Comm_rank(MPI_COMM_WORLD, &ProcRank );

if ( ProcRank == 0 ) DoProcess0( );

else if ( ProcRank == 1 ) DoProcess1)( );

else if ( ProcRank == 2 ) DoProcess2( );

212

В багатьох випадках, як і в розглянутому прикладі, виконувані дії різняться

тільки для процесу з рангом 0. В цьому випадку загальна схема МРІ - програми

приймає простіший вигляд:

MPI_Comm_rank(MPI_COMM_WORLD, &ProcRank);

if ( ProcRank == 0 ) DoManagerProcess( );

else DoWorkerProcesses( ) ;

На завершення обговорення прикладу пояснимо застосований в МРІ підхід

для контролю правильності виконання функцій. Всі функції МРІ (окрім

MPI_Write та MPI_Wtick) повертають як своє значення код завершення. В разі

успішного виконання функції код, що повертається, дорівнює MPI_SUCCESS.

Інші значення коду завершення свідчать про виявлення тих чи інших помилкових

ситуацій в ході виконання функцій. Для з’ясування типу виявленої похибки

використовується визначені іменовані константи, серед яких:

- MPI_ERR_BUFFER - невірний вказівник нв буфер;

- MPI_ERR_TRUNCATE - повідомлення перевищує розмір

прийомного буфера;

- MPI_ERR_COMM - невірний комунікатор;

- MPI_ERR_RANK - невірний ранг процесора, та ін.

Повний список констант для перевірки коду завершення вмісту міститься в

файлі mpi.h. Проте виникнення будь-якої похибки під час виконання функції МРІ

приводить до негайного завершення паралельної програми. Для того щоб мати

можливість проаналізувати код завершення, що повертається, слід скористатися

функціями МРІ, що надаються, із створення обробників похибок і управління

ними.

Визначення тривалості виконання МРІ - програми. Відразу після

розробки перших паралельних програм виникає необхідність визначення

тривалості виконання обчислень для оцінки тривалості виконання обчислень, яка

досягається, за рахунок використання паралелізму. Використовувані засоби для

213

виміру тривалості роботи програм залежать від апаратної платформи, операційної

системи, алгоритмічної мови і т.п. Стандарт МРІ включає визначення

спеціальних функцій для виміру часу, застосування яких дає змогу усунути

залежність від середовища виконання паралельних програм. Отримання

поточного моменту часу забезпечується з використанням функції:

double MPI_Wtime(void) ,

результат її виклику є кількість секунд, що пройшли від певного моменту

часу в минулому. Цей момент часу в минулому, від якого відбувається відлік

секунд, може залежати від середовища реалізації бібліотеки МРІ, і для виходу від

такої залежності функцію MPI_Wtime слід використати тільки для визначення

тривалості виконання тих чи інших фрагментів коду паралельних програм.

Можлива схема застосування функції MPI_Wtime може полягати в наступному:

double t1, t2, dt;

t1 = MPI_Wtime( );

t2 = MPI_Wtime( );

dt = t2 - t1;

Точність виміру функції також може залежати від середовища

виконання паралельної програми. Для визначення поточного значення точності

може бути використана функція:

double MPI_Wtick(vold) ,

яка дає можливість визначити часу в секундах між двома послідовними

показниками часу апаратного таймера застосованої комп’ютерної системи.

Початкове знайомство з колективними операціями передачі даних.

Функції MPI_Send та MPI_Recv, розглянуті раніше, забезпечують можливість

виконання парних операцій передачі даних між двома процесами паралельної

програмами. Для виконання комунікаційних колективних операцій, в яких задіяні

всі процеси комунікатора, в МРІ передбачений спеціальний набір функцій.

Розглянемо три таких функції, які застосовуються при розробці порівняно

простих паралельних програм. Для демонстрації застосування розглядуваних

функцій МРІ використаємо начальну задачу знаходження суми елементів вектора

214

:

.

Розробка паралельного алгоритму для рішення задачі є нескладною

задачею: слід розділити дані на рівні блоки, передати ці блоки процесам,

виконати в процесах знаходження суми отриманих даних, зібрати значення

обчислених часткових сум на одному з процесів і скласти значення часткових сум

для отримання загального результату розв’язуваної задачі. При подальшій

розробці демонстраційних програм цей розглянутий алгоритм буде спрощений:

процесам програми буде передаватися весь сумарний вектор, а не окремі блоки

цього вектора.

Передача даних від одного процесу всім процесам системи. Перша

задача при використанні розглянутого паралельного алгоритму знаходження суми

полягає в необхідності передачі значень вектора всім процесам паралельної

програми. Для розв’язку цієї задачі можна скористатися розглянутими раніше

функціями парних операцій передачі даних:

MPI_Comm_size(MPI_COMM_WORLD, &ProcNum) ;

for (int i= 1; i < ProcNum; 1++)

MPI_Send(&x, n, MPI_DOUBLE, i, 0, MPI_COMM_WORLD);

Проте таке рішення буде вкрай не ефективним, оскільки повторення

операцій передачі приводить до знаходження суми витрат (латентностей) на

підготовку повідомлень, що передаються. Цю операцію можна виконати за

ітерацій передачі даних. Досягнення ефективного виконання операції передачі

даних від одного процесу всім процесам програми (широко повідомлюване

пересилання даних) може бути забезпечено з використанням функції МРІ:

int MPI_Bcast(void *buf , int count, MPI_Datftype type, int root,

MPI_Comm comm),

де

- buf, count, type - буфер пам’яті з повідомленням, що відпраляється (для

процесу з рангом 0) та для прийому повідомлень (для всіх інших процесів);

- root - ранг процесу, який виконує розсилання даних;215

- comm - комунікатор, в рамках якого виконується передача даних.

Функція MPI_Bcast здійснює розсилку даних з буфера buf, який містить

count елементів типу type, з процесу, який має номер root, всім процесам, які

входять до комунікатора comm, рис. 3.1.

процеси процеси

а) до початку операції б) після завершення операції

Рисунок 3.1 – Загальна схема операції передачі даних від одного процесу всім

процесам

Слід відмітити:

- функція MPI_Bcast визначає колективну операцію, і при виконанні

необхідних розсилок даних виклик функції MPI_Bcast повинен бути здійснений

всіма процесами вказаного комунікатора;

- вказаний в функції MPI_Bcast буфер пам’яті має різне призначення в

різних процесів: для процесу з рангом root, яким здійснюється розсилання даних,

в цьому буфері повинно знаходитися повідомлення, що розсилається, а для всіх

інших процесів вказаний буфер призначений для прийому даних, які передаються;

- всі колективні операції "несумісні" з парними операціям, якщо прийняти

широко оголошуване повідомлення, відіслане з використанням MPI_Bcast,

функцією MPI_Recv неможна, для цього можна задіяти тільки MPI_Bcast.

Наведемо програму для розв’язку навчальної задачі знаходження суми

елементів вектора з використанням розглянутої функції.

Програма 3.2. Паралельна програма знаходження суми числових значень

#include <math. h>

216

#include <stdio. h>

#include <mp. i>

int main(int argc, char* argv[ ]){

MPI_Status Status;

// Ініціалізація

MPI_Init(&argc , &argv);

MPI_Comm_sizt(MPI_COMM_WORLD, &ProcRum);

MPI_Comm_rank(MPI_COMM_WORLD. &ProcRanc);

// Підготовка даних

ша ( ProcRank == 0 ) DataInitialization(x, N);

// Підготовка даних

if { ProcRank == 0 ) DataInitialization(z, H);

// Розсилання даних на всі процеси

//MPI_Bcast(x, N, MPI_DOUBLE, 0, MPI_Comm_WORLD);

// Обчислення часткової суми на кожному з процесів

// на кожному процесі підсумовуються елементи вектора xвід 11 до 12

k = N / ProcNum;

i 1 = k * ProcRank;

i 2 = k * ( ProcRank + 1);

if ( ProcRank == ProcNum-1) i2 =N;

for ( int i = 11; i < 12; i++ )

ProcSum = ProcSum + x[i];

// Збірка часткових сум на процесі з рангом 0

if ( ProcRank == 0 ) {

TotalSum = ProcSum;

217

for ( int i=1; i < ProcSum; i++ ) {

MPI_Recv(&ProcSum, 1, MPI_DOUBLE,MPI_ANY_SOURCE, 0,

MPI_COMM_WORLD, &Status);

TotalSum = TotalSum + ProcSum;

}

}

else // Всі процеси відсилають свої часткові суми

MPI_Send(&ProcSum, 1, MPI_DOUBLE, 0, 0,

MPI_COMM_WORLD);

// Виведення результату

if ( ProcRank == 0 )

printf("\nTotal Sum = %10.2f", TotflSum) ;

MPI_Finalize( ) ;

return 0;

}

В наведеній програмі функція DataInitialization здійснює підготовку

початкових даних. Необхідні дані можуть бути введені з клавіатури, прочитані з

файлу чи з генеровані з використанням датчика випадкових чисел - підготовка

цієї функції надається як задавання для самостійної розробки.

Передача даних від всіх процесів одному процесу. Операція редукції. В

розглянутій програмі підсумовування числових значень наявна процедура збору і

наступного підсумовування даних є прикладом часто виконуваної колективної

операції передачі даних від всіх процесів одному процесу. В цій операції над

значеннями, що збираються, та чи інша обробка даних (для підкреслювання

останнього моменту дана операція ще іменується операцією редукції даних). Як і

раніше, реалізація операції редукції з використанням звичайних парних операцій

передачі даних є неефективною і достатньо трудомісткою. Для найкращого

виконання дій, пов’язаних з редукцією даних, в МРІ передбачена функція:

int MPI_Reduce(void *recvbuf, int count ,

218

MPI_Datatype type, MPI_Op op, int root, MPI-Comm comm ,

де

- sendbuf - буфер пам’яті з повідомленням, яке відправляється;

- recvbuf - буфер пам’яті для результуючого повідомлення (тільки для

процесу з рангом boot)ж

- count - якість елементів в повідомленнях;

- type - тип елементів повідомлень;

- op - операція, яка повинна бути виконана над даними;

- root - ранг процесу. на якому має бути результат;

- comm - комунікатор, в рамках якого виконується операція.

Як операції редукції даних можуть бути виконані обумовлені в МРІ

операції, табл. 3.2. Окрім даного стандартного набору операцій можуть бути

визначені і нові додаткові операції безпосередньо самим користувачем бібліотеки

МРІ. Загальна схема виконання операції збирання і обробки даних на одному

процесі показана на рис. 3.2. Елементи отримуваного повідомлення на процесі

root представляють собою результати обробки відповідних елементів, що

передаються процесами повідомлень, тобто:

, ,

де є операція, яка задається при виклику функції MPI_Reduce (для

пояснення на рис. 3.3 показаний приклад виконання функції редукції даних).

219

процеси процеси

а) після завершення операції б) до початку операції

Рисунок 3.2 – Загальна схема операції збору і обробки на одному процесі даних

від всіх процесів

процеси процеси

а) після завершення операції б) до початку операції

Рисунок 3.3 – Процес виконання операції редукції при підсумовуванні даних, які

пересилаються, для трьох процесів (в кожному повідомленні 4 елементи,

повідомлення збираються на процесі з рангом 2)

Слід відмітити:

- функція MPI_Reduce визначає колективну операцію, тим самим виклик

функції повинен бути виконаний всіма процесами вказаного комунікатора. Всі

виклики функції повинні містити однакові значення параметрів count, type, op,

root, comm;

- виконання операції редукції здійснюється над окремими елементами

повідомлень, що передаються. Якщо повідомлення містить по два елементи даних

і виконується операція підсумовування MPI_SUM, то результат також буде

складатися з двох значень, перше з яких міститиме суму перших елементів всіх

220

відправлених повідомлень, а друге значення дорівнюватиме сумі других

елементів повідомлень, відповідно;

- не всі сполучення типу type та операції op можливі, дозволені сполучення

наведені в табл. 3.3.

Таблиця 3.2 – Базові (зумовлені) типи операцій МРІ для функцій редукції даних

Операція Опис

MPI_MAX Означення максимального значення

MPI_MIN Означення мінімального значення

MPI_SUM Означення суми значень

MPI_PRO

D

Означення добутку

MPI_LAN

D

Виконання логічної операції "І" над значеннями

повідомлень

MPI_BAN

D

Виконання бітової операції "І" над значеннями

повідомлень

MPI_LOR Виконання логічної операції "АБО" над значеннями

повідомлень

MPI_BOR Виконання бітової операції "АБО" над значеннями

повідомлень

MPI_LXO

R

Виконання логічної операції виключного "АБО" над

значеннями повідомлень

MPI_BXO

R

Виконання бітової операції виключного "АБО" над

значеннями повідомлень

MPI_MAX

LOC

Визначення максимальних значень та їх індексів

MPI_MIN

LOC

Визначення мінімальних значень та їх індексів

221

Таблиця 3.3 – Дозволені сполучення операції типу операнда в операції редукції

Операція Допустимий тип операндів

для алгоритмічної мови С

MPI_MAX, MPI_MIN,

MPI_SUM, MPI_PROD

Цілий, дійсний

MPI_LAND, MPI_LOR,

MPI_LXOR

Цілий

MPI_BAND, MPI_BOR,

MPI_BXOR

Цілий, байтовий

MPI_MINLOC, MPI_MAXLOC Цілий, дійсний

Застосуємо отриману інформацію для переробки раніше розглянутої

програми підсумовування: весь програмний код, виділений під рамкою, може

бути замінений на виклик однієї лише функції MPI_Reduces:

// Збірка часткових сум на процесі з рангом 0

MPI_Reduce(&ProcSum, &TotalSum, 1, MPI_DOUBLE, MPI_SUM,

0,

MPI_COMM_WORLD);

Синхронізація обчислень. В багатьох випадках незалежно виконувані в

процесах обчислення необхідно синхронізувати. Зокрема для виміру часу початку

роботи паралельної програми необхідно, щоб для всіх процесів одночасно були

завершені всі підготовчі дії, перед закінченням роботи програми всі процеси

повинні завершити свої обчислення і т.п. Синхронізація процесів, тобто

одночасне досягнення процесами тих чи інших точок процесу обчислень,

забезпечується за допомогою функції МРІ:

int MPI_Barrier(MPI_Comm comm) ,

де

- comm - комунікатор, в рамках якого виконується операція.

Функція MPI_Barrier визначає колективну операцію, і, тим самим, при

222

використанні вона повинна викликатися всіма процесами використовуваного

комунікатора. При виклику функції MPI_Barrier виконання процесу блокується,

продовження обчислень процесу відбудеться тільки після виклику функції

MPI_Barrier всіма процесами комунікатора.

Аварійне завершення паралельної програми. Для коректного завершення

паралельної програми у випадку непередбачених ситуацій слід використати

функцію:

int MPI_Abort(MPI_Comm comm, int errorcode ) ,

де

- comm - комунікатор, процеси якого необхідно аварійно зупинити;

- errorcode - код повернення та паралельної програми.

Ця функція коректно перериває виконання паралельної програми,

оповіщаючи про цю подію середовище МРІ, на відміну від функцій бібліотеки

алгоритмічної мови С, таких, як abort чи terminate. Звичайне її використання

полягає в наступному:

MPI_Abort(MPI_COMM_WORLD, MPI_ERR_OTHER);

Операції передачі даних між двома процесами. Режими передачі даних.

Розглянута раніше функція MPI_Send забезпечує так званий стандартний режим

відправки повідомлень, коли:

- на час виконання функції процес-відправник повідомлення блокується;

- після завершення функції буфер може бути використаний повторно;

- стан відправленого повідомлення може бути різним - повідомлення може

розташовуватися на процесі-відправнику, може знаходитися в стані передачі,

може зберігатися на процесі-одержувачі чи може бути прийнятий процесом-

одержувачем з використанням функції MPI_Recv.

Крім стандартного режиму в МРІ передбачаються такі додаткові

режими передачі повідомлень:

- синхронний режим полягає в тому, що завершення функції відправки

повідомлення відбувається тільки за отримання від процесу - одержувача

підтвердження про початок прийому відправленого повідомлення про початок

223

прийому відправленого повідомлення. Відправлене повідомлення чи повністю

прийнято процесом-одержувачем, чи знаходиться в стані прийому;

- буферизований режим передбачає використання додаткових системних

чи заданих користувачем буферів для копіювання в них відправлених

повідомлень. Функція відправки повідомлення завершується зразу ж після

копіювання повідомлення до системного буферу;

- режим передачі за готовністю може бути використаний тільки, якщо

операція прийому повідомлення вже ініційована. Буфер повідомлення після

завершення функції відправки повідомлення може бути повторно використаний.

Для іменування функції відправки для різних режимів виконання в МРІ

застосовується назва функції MPI_Send, до якого як префікс добавляється

початковий символ назви відповідного режиму роботи, тобто:

-MPI_Ssent - функція відправки повідомлення в синхронному режимі;

- MPI_Bsent - функція відправки повідомлення в буферному режимі;

- MPI_Rsent - функція відправки повідомлення в режимі за готовністю.

Список параметрів всіх перерахованих функцій співпадає із складом

параметрів функції MPI_Send. Для застосування буферного режиму передачі

може бути створений і переданий МРІ буфер пам’яті, використовувана для цього

функція має вигляд:

int MPI_Buffer_attach(void *buf size),

де

- buf - адреса буфера пам’яті;

- size - розмір буфера.

Після завершення роботи з буфером він повинен бути відключеним

від МРІ з використанням функції:

int MPI_Buffer_detach(void *buf , int *size),

де

- buf - адреса буфера пам’яті;

- size - розмір буфера, що повертається.

224

З точки зору практичного використання режимів можна навести такі

рекомендації:

- стандартний режим реалізується як буферизований чи синхронний, в

залежності від розміру повідомлення, що передається, який часто є найбільш

оптимізованим за продуктивністю;

- режим передачі за готовністю формально є найбільш швидким, але

використовується достатньо рідко, оскільки складно гарантувати готовність

операції прийому;

- буферизований режим також виконується достатньо швидко, але може

приводити до великим витратам ресурсів (пам’яті), - в цілому може бути

рекомендованим для передачі коротких повідомлень;

- синхронний режим є найбільш повільним, оскільки вимагає підтвердження

прийому, проте не потребує додаткової пам’яті для зберігання повідомлення. Цей

режим можна рекомендувати для передачі довгих повідомлень.

Для функції MPI_Recv не існує різноманітних режимів роботи.

Організація неблокуючих обмінів даних між процесами. Всі раніше

розглянуті функції відправки і прийому повідомлень - блокуючі, тобто такими,

що призупиняють виконання процесів до моменту завершення роботи викликаних

функцій. В той же час при виконанні паралельних обчислень частина повідомлень

може бути відправлена і прийнята завчасно, до моменту реальної потреби в даних,

що пересилаються. В таких ситуаціях небажано мати можливість виконання

функцій обміну даними без блокування процесів для суміщення процесів передачі

повідомлень та обчислень. Такий неблокуючий спосіб виконання обмінів є

складнішим для використання, але за правильного застосування може в значній

мірі зменшити втрати ефективності паралельних обчислень внаслідок повільних

(порівняно з швидкодією процесорів) комунікаційних операцій. МРІ забезпечує

можливість неблокованого виконання операцій передачі даних між двома

процесами. Найменування неблокуючих аналогів утворюється з назв відповідних

функцій шляхом добавлення префікса І (Immediate). Список параметрів

неблокуючих функцій містить звичайний набір параметрів вихідних функцій і

225

один додатковий параметр request з типом MPI_Request (в функції MPI_Irecv

відсутній також параметр status):

int MPI_Isend(void *buf. int count, MPI_batatype type, int dest

int tag, MPI_Comm comm, MPI_Request *request),

int MPI_Inssent(void *buf, int count, MPI_Datatype type, int dest,

int tag, MPI_Comm comm, MPI_Request *request),

int MPI_Ibsennd(void *buf , int count , MPI_Dftftipe tupe, int dest,

int tag, MPI_Comm comm, MPI_Request *request),

Int MPI_Irsend(void *buf , int count, MPI_Datatype type, int dest,

int tag, MPI_Comm comm, MPI_Request *request),

Int MPI_Irsend(void *buf , int count, MPI_Datatype type, int sourse,

int tag, MPI_Comm comm, MPI_Request *request).

Виклик неблокуючої функції приводить до ініціації запрошеної операції

передачі, після чого виконання функції завершається і процес може продовжувати

свої дії. Перед завершенням неблокуюча функція визначає змінну request, яка далі

може використовуватися для перевірки завершення ініційованої операції обміну.

Перевірка стану виконуваної неблокуючої операції передачі даних здійснюється з

використанням функції:

int MPI_Test(MPI_Request *request, int *flaq , MPI_status *status) ,

де

- request - дескриптор операції, визначений при визові неблокуючої

функції;

- flaq - результат перевірки (true, якщо операція завершена);

- status - результат виконання операції обміну (тільки для завершеної

операції).

Операція перевірки є неблокуючою, тобто процес може перевірити стан

неблокуючої операції обміну і продовжити далі свої обчислення, якщо за

результатами перевірки виявиться,що операція все ще не завершена. Можлива

схема суміщення обчислень і виконання неблокуючої операції обміну може

полягати в наступному:

226

MPI_Isend(buf, count, type, dest, taq, comm, &request );

...

do {

...

MPI_Test(&request , &flaq, &status ) ;

} while (! flaq) ;

Якщо за умови виконання неблокуючої операції виявиться, що продовження

обчислень неможливе без отримання даних, що передаються, то може бути

використана блокуюча операція очікування завершення операції:

int MPI_Wait(MPI_Request *request , MPI_Status *status) ,

де

- request - дескриптор операції, визначений при виклику неблокуючої

функції;

- status - результат виконання операції обміну (тільки для завершеної

операції).

- Окрім розглянутих, МРІ містить ряд додаткових функцій перевірки і

очікування неблокуючих операцій обміну:

- MPI_SNSTALL -перевірка завершення всіх перерахованих операцій

оюміну;

- MPI_Waitall - очікування завершення всіх операцій обміну;

- MPI_Testany - перевірка завершення хоча б однієї з перерахованих

операцій обміну;

- MPI_Waitany - перевірка завершення будь-якої з перерахованих

операцій обміну;

- MPI_Testsome - перевірка завершення кожної з перерахованих операцій

обміну;

- MPI_Waitsome - очікування завершення хоч однієї з перерахованих

операцій обміну та оцінка стану за всіма операціями.

Наведення простого прикладу використання неблокуючих функцій

достатньо складно. Доброю можливістю засвоєння розглянутих функцій можуть

227

бути алгоритми матричного множення, які будуть розглянуті далі.

Одночасне виконання передачі і прийому. Однією з часто виконуваних

форм інформаційної взаємодії в паралельних програмах є обмін даними між

процесами, коли для продовження обчислень процесам необхідно відправити дані

одним процесам і в той же час отримати повідомлення від інших. Найпростіший

варіант цієї ситуації полягає в обміні даними між двома процесами. Реалізація

таких обмінів з використанням звичайних парних операцій передачі даних може

бути неефективна, крім того, така реалізація повинна гарантувати відсутність

тупикових ситуацій, які можуть виникати, наприклад, коли два процеси

починають передавати повідомлення один одному з використанням блокуючих

функцій передачі даних. Досягнення ефективного і гарантованого одночасного

виконання операцій передачі і прийому даних може бути забезпечено з

використанням функції МРІ:

int MPI_Sendrecv(void *sbuf , int scount , MPI_Datatype stype .

int dest, int stag, void *rbuf , int rcount , MPI_Datatype etype,

int source , int rtag, MPI_Comm comm, MPI_Status *status )

де

- sbuf, scount, stype, dest, stag - параметри повідомлення, що передається;

- rbuf, rcount, rtype, source, rtag - параметри повідомлення, що

приймається4

- comm - комунікатор, в рамках якого виконується передача даних;

- status - структура даних з інформацією про результат виконання операції.

Як випливає з опису функція MPI_Sendrecv передає повідомлення, яке

описується параметрами (sbuf, scount, stype, dest, stag), процесу з рангом dest і

приймає повідомлення до буфера, який визначається параметрами (rbuf, rcount,

кtype, source, rtag), від процесу з рангом source. В функції MPI_Sendrecv для

передачі і прийому повідомлень застосовуються різні буфери. У випадку, коли

повідомлення, що відсилається більше не потрібно на процесі - відправнику, в

МРІ є можливість використання буфера:

int MPI_Sendrecv_replace(void *buf , int count , MPI_Datatyp type ,

228

int dest , int stag , int source , int rtaq , MPI_Comm comm ,

MPI_Status* status ) ,

- buf, count, type - параметри повідомлення, що передається;

- dest - ранг процесу, якому відправляється повідомлення;

- stag - тег для ідентифікації повідомлення, що відправляється;

- source - ранг процесу, від якого виконується прийом повідомлення;

- rtag - тег для ідентифікації повідомлення, що приймається;

- comm - комунікатор, в рамках якого виконується передача даних;

- status - структура даних з інформацією про результат виконання

операції.

Приклад використання функції для одночасного виконання операцій

передачі і прийому наведений далі.

Колективні операції передачі даних. Під колективними операціями в

МЗШ розуміють операції над даними, в яких приймають участь всі процеси

використовуваного комунікатора. виділення основних типів колективних

операцій буде виконаний далі.

процеси процеси

а) до початку операції б) після завершення операції

Рисунок 3.4 – Загальна схема узагальненої передачі даних від одного процесу всім

процесам

Узагальнена передача даних від одного процесу всім процесам.

Узагальнена операція передачі даних від одного процесу всім процесам (розподіл

даних) відрізняється від широкомовної розсилки тим, що процес передає

процесам дані, що розрізняються. Виконання даної операції забезпечується з

229

використанням функції:

int MPI_Scatter(void *sbuf , int scount , MPI_Datatype stype ,

voide *rbuf , int rcount , MPI_Datatype rtype, int root ,

MPI_Comm comm ) ,

де

- sbuf, scount, stype - параметри повідомлення, що передаються,

(scount визначає кількість елементів, що передаються на кожний процес);

- rbuf, rcount, rtype - параметри повідомлення, яке приймається в

процесах;

- root - ранг процесу, який виконує розсилку даних;

- comm - комунікатор, в рамках якого виконується передача даних.

В разі виклику цієї функції процес з рангом root здійснить передачу даних

всім іншим процесам в комунікаторі. Кожному процесу буде відправлено scount

елементів. Процес з рангом 0 отримає блок даних із sbuf елементів з індексами від

0 до scount - 1, процесу з рангом 1 буде відправлений блок з sbuf елементів з

індексами від scount до 2* scount 1 і т.д. Тим самим, спільний розмір

повідомлення, що відправляється, повинен бути рівний scount * p елементів, де p

є кількістю процесів в комунікаторі comm. Оскільки функція MPI_Scatter

визначає колективну операцію, виклик цієї функції при виконанні розсилки даних

може бути забезпечений на кожному процесі комунікатора. Функція MPI_Scatter

передає всі процесам повідомлення однакового розміру. Виконання більш

загального варіанту операції розподілу даних, коли розміри повідомлень для

процесів можуть бути різні, забезпечується з використанням функції

MPI_Scatterv. Приклад використання функції MPI_Scatter розглядається далі в

розділі з розробки паралельних програм множення матриці на вектор.

Узагальнена передача даних від всіх процесів одному процесу. Операція

узагальненої передачі даних від всіх процесів одному процесу (збір даних) є

двоїстою до процедури розподілу даних, рис. 3.5.

230

процеси процеси

а) до початку операції б) після завершення операції

Рисунок 3.5 – Загальна схема операції узагальненої передачі даних від всі

процесів одному процесу

Для виконання цієї операції в МРІ призначена функція:

int MPI_Gather(void *sbuf , int scount , MPI_Datatype stype ,

void *rbuf , int rcount , MPI_Datatype rtype ,

int root , MPI_Comm comm ) ,

де

- sbuf, scount, stype - пераметри повідомлення, що передається;

- rbuf, rcount, rtype - пераметри повідомлення, що приймається;

- root - ранг процесу, що виконує збирання даних;

- comm - комунікатор, в рамках якого виконується передача даних.

При виконанні функції MPI_Gather кожний процес в комунікаторі передає

дані з буферу sbuf на процес з рангом root. Процес з рангом root збирає всі

отримувані дані в буфері rbuf (розміщення даних в буфері здійснюється у

відповідності з рангами процесів - відправників повідомлень). Для того, щоб

розмістити всі дані, що надходять, розмір буфера rbuf повинен бути рівним scount

* p елементів, де p є кількість процесів в комунікаторі comm. Функція MPI_Gather

також визначає колективну операцію, і її виклик при виконанні збору даних

повинен бути забезпечений в кожному процесі комунікатора. при використанні

функції MPI_Gather збірка даних здійснюється тільки на одному процесі. Для

231

отримання всіх даних, що збираються, на кожному з процесів комунікатора слід

застосовувати функцію збору і розсилання:

int MPI_Allqather(void *sbuf , int scount , MPI_Datatype stype ,

void *rbuf , int rcount , MPI_Datatype rtype , MPI_Comm comm ) ,

де

- sbuf, scount, stype - параметри повідомлення, що передається;

- rbuf, rcount, rtype - параметри повідомлення, що приймається;

comm - комунікатор, в рамках якого виконується передача даних.

Виконання загального варіанту операції збору даних, коли розміри

повідомлень, що передаються процесами, можуть бути різними, забезпечується з

використанням функцій MPI_Gather та MPI_Allgatherv. Приклад використання

функції MPI_Gather буде розглянутий далі, при розробці паралельних програм

множення матриці на вектор.

Загальна передача даних від всіх процесів всім процесам. Передача

даних від всіх процесів всім процесам є найбільш загальною операцією передачі

даних, рис. 3.6.

процеси процеси

а) до початку операції б) після закінчення операції

Рисунок 3.6 – Загальна схема операції передачі даних від всіх процесів всім

процесам

Виконання цієї операції забезпечується з використанням функції:

int MPI_Alltoall(void *sbuf , int scount , MPI_Datatype stype ,

vjid *rbuf , int rcount , MPI_Datatype rtype , MPI_Comm comm ),

232

де

- sbuf, scount, stype - параметри повідомлень, що передаються;

- rbuf, rcount, rtype - параметри повідомлень, що приймаються;

- comm - комунікатор, в рамках якого виконується передача даних.

При виконанні функції MPI_Alltoall кожний процес в комунікаторі

передає дані з scount елементів кожному процесу (спільний розмір повідомлень,

що відправляються, в процесах повинен дорівнювати scount * p елементів, де p є

кількістю процесів в комунікаторі comm) і приймає повідомлення від кожного

процесу. Виклик функції MPI_Alltoall при виконанні операції загального обміну

даними повинен бути виконаний в кожному процесі комунікатора. Варіант

операції загального обміну даними, коли розміри повідомлень, що передаються

процесами, можуть бути різними, забезпечується з використанням функції

MPI_Alltoallv.

Приклад використання функції MPI_Alltoall буде розглянутий далі, при

розробці паралельних програм множення матриці на вектор.

Додаткові операції редукції даних. Розглянута вище функція MPI_Reduce

забезпечує отримання результатів редукції даних тільки на одному процесі. Для

отримання результатів редукції даних на кожному з процесів комунікатора слід

використати функцію редукції і розсилки:

int MPI_Allreduce(void sendbuf , void *recvbuf , int count ,

MPI_Datatype type , MPI_Op op , MPI_Comm comm ) ,

де

- sendbuf - буфер пам’яті з повідомленням, що відправляється;

- recvbuf - буфер пам’яті для результуючого повідомлення;

- count - кількість елементів в повідомленні;

- type - тип елементів повідомлень;

- op - операція, яка повинна бути виконана над даними;

- comm - комунікатор, в рамках якого виконується операція ) ,

Функція MPI_Allreduce виконує розсилку між процесами всіх результатів

операції редукції. Можливість управління розподілом цих даних між процесами

233

надається функцією MPI_Allreduce_scatter. Ще один варіант операції збору і

обробки даних, коли забезпечується отримання всіх часткових результатів

редукування, може бути реалізований з використанням функції:

int MPI_Scan(void *sendbuf , void *recvbuf , int count ,

MPI_Datatype type , MPI_Op op , MPI_Comm comm ) .

де

- sendbuf - буфер пам’яті з повідомлення, що відправляється;

- recvbuf - буфер пам’яті для результуючого повідомлення;

-count - кількість елементів в повідомленні;

- type - тип елементів повідомлення;

- op - операція, яка повинна бути виконана над даними;

- comm - комунікатор, в рамках якого виконується операція.

Загальна схема виконання функції MPI_Scan показана на рис. 3.7.

процеси процеси

а)до початку операції б) після завершення операції

Рисунок 3.7 – Загальна схема операції редукції з отриманням часткових

результатів обробки даних

Елементи отриманих повідомлень представляють собою результати обробки

відповідних елементів повідомлень, що передаються процесами. Для отримання

результатів на процесі з рангом використовуються дані від процесів, ранг

яких менший чи рівний , тобто

234

де - операція, що задається при виклику функції MPI_Scan.

Використання викладеного вище матеріалу стосовно колективних операцій

буде розглянуто далі.

Поняття похідного типу даних. В самому загальному вигляді під похідним

типом даних в МРІ розуміють опис набору значень передбаченого в МРІ типу,

причому в загальному випадку описувані значення не обов’язково неперервним

чином розташовуються в пам’яті. Задавання типу в МРІ прийнято здійснювати з

використанням карти типу (type map) у вигляді послідовності описів, що входять

до типу значень; кожне окреме значення описується вказівкою типу ті мішання

адреси місце розташування від деякої базової адреси, тобто

TypeMap={(type0, disp0),...,(typen-1, dispn-1)}.

Частина карти типу з вказівкою тільки типів значень іменується в МРІ

сигнатурою типу:

TypeSignature ={type0,...,typen-1}.

Сигнатура типу описує, які базові типи даних утворюють певний довільний

тип даних МРІ, і, тим самим, управляє інтерпретацією елементів даних при

передачі чи отриманні повідомлень. зміщення карти типу визначають, де

знаходять значення даних. Пояснимо розглянуте поняття на прикладі. Нехай до

повідомлення повинні входити значення змінних:

double a; /* адреса 24 */

double b; /* адреса 40 */

int n; /* адреса 48 */

Тоді похідний тип для опису таких даних повинен мати карту типу такого

вигляду:

{(MPI_DOUBLE, 0),

(MPI_DOUBLE, 16),

(MPI_INT , 24)}

Додатково для похідних типів даних в МРІ використовується наступний ряд

нових понять:

* нижня границя типу

235

lb(TypeMap) = minj(dispj) ;

* верхня границя типу

ub(TypeMap) = maxj(dispj + sizeof(typej))+ Δ;

* протяжність типу

extent(TypeMap) = ub(TypeMap) - lb(TypeMap) .

Згідно з означенням, нижня границя є суміщення для першого байта значень

розглядуваного типу даних. Відповідно, верхня границя є зміщення для байта,

який розташовується слідом за останнім елементом розглядуваного типу даних.

Величина зміщення для верхньої границі може бути округлена вверх з

врахуванням вимог вирівнювання адрес. Одна з вимог, які накладають деякі

реалізації мови С та Fortran, полягає в тому, щоб адреса елемента була кратною

довжині цього елемента в байтах. Наприклад, якщо тип int займає чотири байти,

то адреса елемента типу int повинна націло ділитися на чотири. Саме ця вимога

відображається в означення верхньої границі типу даних МРІ. Пояснимо це на

вже розглянутому прикладі набору змінних a, b, n, для якого нижня границя

дорівнює 0, а верхня приймає значення 32 (величина округлення 6 чи 4 в

залежності від розміру типу int). Тут слід відмітити, що потрібне вирівнювання

визначається за типом першого елемента даних в карті типу. Слід наголосити на

різниці понять "протяжність" та "розмір типу". Протяжність - це розмір пам’яті в

байтах, який слід відвести для одного елемента довільного типу. Розмір типу

даних - це кількість байтів, які займають дані (різниця між адресами останнього і

першого байтів даних). Різниця в значеннях протяжності і розміру в величині

округлення для вирівнювання адрес. В прикладі розмір типу дорівнює 28, а

протяжність - 32 (припускається, що тип int займає чотири байти).

Для отримання значення протяжності типу в МРІ передбачена функція:

int VHS_Type_extent(MPI_Datatype type , MPI_Aint *extent ) ,

де

- type - тип даних, протяжність якого знаходиться;

- extent - протяжність типу.

Розмір типу можна знайти, використовуючи функцію:

236

int MPI_Type_Size(MPI_Danatype type , MPI_Aint *size ) ,

де

- type - тип даних, розмір якого знаходиться;

- size - розмір типу.

Визначення нижньої і верхньої границь типу може бути виконано з

використанням функцій:

int MPI_Type_lb(MPI_Datatype type , MPI_Aint *disp ) та

int MPI_Type_ub(MPI_Datatype type , MPI_Aint *disp ) ,

де

- type - тип даних, нижня границя якого знаходиться;

- disp - нижня/верхня границя типу.

Важливою і необхідною при конструюванні довільних типів є функція

отримання адреси змінної:

int MPI_Address(void *location , MPI_Aint *address ) ,

де

- location - адреса пам’яті;

- address - адреса пам’яті в МРІ - форматі, що є переносним

(слід відмітити, що ця функція є переносним варіантом засобів отримання

адрес в алгоритмічних мовах С та Fortran).

Способи конструювання довільних типів даних. Для зниження

складності в МПІ передбачено декілька різних способів конструювання довільних

типів:

- неперервний спосіб дає змогу визначити неперервний набір елементів

наявного типу як новий довільний тип;

- векторний спосіб забезпечує створення нового довільного типу як набору

елементів наявного типу, між елементами якого є регулярні проміжки за

пам’яттю. Розмір проміжків задається в кількості елементів вихідного типу, в той

час як у варіанті Н - векторного способу цей розмір вказується в байтах;

- індексний спосіб відрізняється від векторного методу тим, що проміжки

між елементами вихідного типу можуть мати нерегулярний характер (є Н -

237

індексний спосіб, який відрізняється способом задавання проміжків);

- структурний спосіб забезпечує самий загальний опис довільного типу

через явну вказівку карти створюваного типу даних. Далі перераховані способи

конструювання довільних типів даних детальніше.

Неперервний спосіб конструювання. За неперервного способу

конструювання довільного типу даних в МРІ використовуються функція:

int MPI_Type_contigous(int count , MPI_Data_type oldtype ,

MPI_Datatype *newtype ),

де

- count - кількість елементів вихідного типу;

- oldtype - вихідний тип даних;

- newtype - новий тип даних, що визначається.

Як випливає з опису, новий тип newtype створюється, як count елементів

вихідного типу oldtype. Наприклад, якщо вихідний тип даних має карту типу

{(MPI_INT , 0) , (MPI_DOUBLE , 8)} ,

то виклик функції MPI_Type_contiquos з параметрами

MPI_Type_contiquous(2 , oldtype , &newtype ) ;

призведе до створення типу даних з картою типу

{(MPI_INT , 0 ) , (MPI_DOUBLE, 8) , (MPI_INT , 16 ) ,

(MPI_DOUBLE , 24 )}.

В певному розумінні наявність неперервного способу конструювання є

надлишковим, оскільки використання аргументу count в процедурах МРІ рівно

сильно використанню неперервного типу даних такого ж розміру.

Векторний спосіб конструювання. За умови векторного способу

довільного типу в МРІ застосовуються функції

int MPI_Type_vector(int count , snt blocklen , int stride ,

MPI_Data_type oldtype , MPI_Datatype *newtype ) та

238

int MPI_Type_hvector(int count , int blocken , MPI_Aint stride ,

MPI_Data_type oldtype , MPI_Datatype *newtype ) ,

де

- count - кількість блоків;

- blocklen - розмір кожного блока;

- stride - кількість елементів, розташованих між двома сусідніми блоками;

- oldtype - вихідний тип даних;

- newtype - новий тип даних, що визначається.

Відмінність способу конструювання, який визначається функцією

MPI_Type_hvector, полягає лише в тому, що параметр stride для визначення

інтервалу між блоками задається в байтах, а не в елементах вихідного типу даних.

За умови векторного способу новий похідний тип створюється як набір блоків з

елементів вихідного типу, між блоками можуть бути регулярні проміжки по

пам’яті. Подамо приклади використання даного способу конструювання типів:

- конструювання типу для виділення половини (тільки парних чи тільки

непарних) стрічок матриці з розміром :

MPI_Type_vector(n / 2, n, 2 * n , &StripRowTypo, &ElemType ) ,

- конструювання типу для виділення стовпця матриці розміром :

MPI_Type_vector(n . 1, n, &ColumnType, & ElemType ) ,

- - конструювання типу для виділення головної діагоналі матриці розміром

:

MPI_Type_vector(n , 1, n + 1 , &DiagonalType, & ElemType ) .

З врахуванням характеру прикладів, що наводяться, можна згадати наявну в

МРІ можливість створення похідних типів для опису під масивів з використанням

функції (дана функція передбачається стандартом МРІ - 2):

int MPI_Type_create_subarray(int ndims, int *sizes, int *subsizes,

int *starts, int order , MPI_Data_type oldtype, MPI_Datatype

*newtype ) ,

де

- ndims - розмірність масиву;

239

- sizes - кількість елементів в кожній розмірності вихідного масиву;

- subsizes - кількість елементів в кожній розмірності під масиву, що

визначається;

- starts - індекси початкових елементів в кожній розмірності під

масиву, що визначається;

- order - параметр для вказівки необхідності пере впорядкування;

- oldtype - тип даних елементів вихідного масиву;

- newtype - новий тип даних для опису під масивів.

Індексний спосіб конструювання. В разі індексного способу

конструювання довільного типу даних в МРІ використовуються функції:

int MPI_Type_indexed(int court , int blocklens[ ] , int indices[ ] ,

MPI_Data_type oldtype , MPI_Datatype *newtype ) та

int MPI_Type_hindexed(int court , int blocklens[ ] , MPI_Aint

indices[ ],

MPI_Data_type oldtype , MPI_Datatype *newtype ) ,

де

- count - кількість блоків;

- blocklens - кількість елементів в кожному блоці;

- indices - мішання кожного блоку від початку типу;

- oldtype - вихідний тип даних;

- newtype - новий тип даних, що визначається.

Як випливає з опису, в разі індексного способу новий похідний тип

створюється як набір блоків різного розміру з елементів вихідного типу, причому

між блоками можуть бути різні проміжки по пам’яті. Для пояснення цього

способу можна навести приклад конструювання типу для опису верхньої

трикутної матриці розміром :

// Конструювання типу для опису верхньої трикутної матриці for ( i =

0, i < n; i++ ) (

blocklens[i] = n - i;

indices [i] = i * n+i;

240

}

MPI_Type_indexed(n , blocklens, indices, &UTMatrixType ,

ElemType).

Як і раніше, спосіб конструювання, який визначається функцією

MPI_Type_hindexed, відрізняється тим, що елементи indices для визначення

інтервалів між блоками задаються в байтах, а не в елементах вихідного типу

даних. Існує ще одна додаткова функція MPI_Type_create_indexed_block

індексного способу конструювання для визначення типів з блоками однакового

розміру (дана функція передбачається стандартом МРІ - 2).

Структурний спосіб конструювання. Цей спосіб є самим загальним

методом конструювання довільного типу даних за умови явного задавання

відповідної карти типу. Використання такого способу здійснюється з

використанням функції:

int MPI_Type_struct( int count , int blocklens[ ] , MPI_Aint

indices[ ],

MPI_Data_type oldtypes[ ] , MPI_Datatype *newtype ) ,

де

- count - кількість блоків;

- blocklens - кількість елементів в кожному блоці;

- indices - зміщення кожного блоку від початку типу (в байтах);

- oldtypes - вихідні типи даних в кожному блоці зокрема;

- newtype - новий тип даних, що визначається.

Структурний спосіб додатково до індексного методу дає змогу вказувати

типи елементів для кожного блоку зокрема.

Оновлення похідних типів та їх видалення. Розглянуті вище функції

конструювання дають змогу визначати довільний тип даних. Додатково перед

використанням створений тип повинен бути оголошений з використанням

функції:

241

int MPI_Type_commit(MPI_Datatype *type ) ,

де

- type - оголошений тип даних.

За умови завершення використання похідний тип повинен бути анульований

з використанням функції:

int MPI_Type_free(MPI_Datatype *type ) ,

де

- type - тип даних, що анулюється.

Формування повідомлень з використанням упаковки та розпаковки

даних. Поряд з розглянутими раніше методами конструювання похідних типів в

МРІ передбачений також явний спосіб зборки і розробки повідомлень, які містять

значення різних типів і розташовуваних в різних ділянках пам’яті. Для

використання даного підходу слід визначити буфер пам’яті достатнього розміру

для збірки повідомлення. Дані, що входять до складу повідомлення повинні бути

упаковані до буферу з використанням функції:

int MPI_Pack(void *data , int count , MPI_Datatype type , void *buf ,

int bufsize , int *bufpos , MPI_Comm comm ) ,

де

- data - буфер пам’яті з елементами для упаковки;

- count - кількість елементів в буфері;

- type - тип даних для елементів, що упаковуються;

- buf - буфер пам’яті для упаковки;

- bufsize - розмір буфера в пам’яті;

- bufpos - позиція для початку запису в буфер (в байтах від початку

буфера);

- comm - комунікатор для упакованого повідомлення.

Функція MPI_Pack упаковує count елементів з буфера data до буфера

упаковки buf, починаючи з позиції bufpos. Загальна схема процедури упаковки

показана на рис. 3.8 а.

242

а) упаковка даних б) розпаковка даних

Рисунок 3.8 – Загальна схема упаковки і розпаковки даних

Початкові значення змінної bufpos повинно бути сформовано до початку

упаковки і далі встановлюється функцією MPI_Pack. Виклик функції MPI_Pack

здійснюється послідовно для упаковки всіх необхідних даних. Так, в раніше

розглянутому прикладі набору змінних a, b, n для їх упаковки необхідно

виконати:

bufpos = 0 ;

MPI_Pack(&a, 1 , MPI_DOUBLE , buf , buflen , &bufpos , comm ) ;

MPI_Pack(&b, 1 , MPI_DOUBLE , buf , buflen , &bufpos , comm ) ;

MPI_Pack(&n, 1 , MPI_DOUBLE , buf , buflen , &bufpos , comm ) ;

Для визначення необхідного розміру буфера для упаковки можна

застосувати функцію:

int MPI_Pack_size(int count , MPI_Datatype type , MPI_Comm comm,

int *size) ,

де

- count - кількість елементів в буфері;

- type - тип даних для упаковки елементів;

- comm - комунікатор для упакованого повідомлення;

- size - розрахований розмір буфера.243

Після упаковки всіх необхідних даних підготований буфер можна

використати в функціях передачі даних з вказівкою типу MPI_PACKED. Після

отримання повідомлення з типом MPI_PACKED дані можна розпакувати з

використанням функції:

int MPI_Unpack(void *buf , int bufsize , int *bufpos , void *data,

int count , MPI_Datatype type , MPI_Comm comm ) ,

де

- buf - буфер пам’яті з упакованими даними;

- bufsize - розмір буфера в байтах;

- bufpos - позиція початку даних в буфері (в байтах від початку

буфера);

- data - буфер пам’яті для розпакованих даних;

- count - кількість елементів в буфері;

- type - тип даних, що розпаковуються;

- comm -комунікатор для упакованого повідомлення.

Функція MPI_Unpack розпаковує, починаючи з позиції bufpos, чергову

порцію даних з буфера buf і розміщує розпаковані дані до буфера data. Загальна

схема процедури розпаковки показана на рис. 3.8б. Початкове значення змінної

bufpos повинно бути сформовано до початку розпаковки і далі встановлюється

функцією MPI_Unpack. Виклик функції MPI_Unpack здійснюється послідовно для

розпаковки всіх упакованих даних, за цього порядку розпаковки повинен

відповідати порядку упаковки. В раніше розглянутому прикладі упаковки для

розпаковки упакованих даних необхідно виконати:

bufpos = 0 ;

MPI_Unpask(buf , buflen , &bufpos , &a , 1, MPI_DOUBLE , comm);

MPI_Unpack(buf , buflen , &bufpos , &b , 1, MPI_DOUBLE , comm);

MPI_Unpack(buf , buflen , &bufpos , &n , 1, MPI_DOUBLE , comm);

Оскільки такий підхід (застосування упаковки для формування

повідомлень) приводить до появи додаткових дій з упаковки і розпаковки даних,

то даний спосіб може бути виправданий за умови порівняно невеликих розмірів

244

повідомлень та за малої кількості повторень. Упаковка та розпаковка може

виявитися корисною за умови використання буферів для буферизованого способу

передачі даних.

3.3. Управління групами процесів і комунікаторами.

Розглянемо можливості з управління групами процесів і комунікаторами.

Процеси паралельної програми об’єднуються в групи. До групи можуть входити

всі процеси паралельної програми; з іншого боку, в групі може знаходитися

тільки частина наявних процесів. Один і той же процес може належати декільком

групам. Управління групами процесів робиться для створення на їх основу

комунікаторів. Під комунікатором в МРІ розуміють спеціально створюваний

службовий об’єкт, який об’єднує в своєму складі групу процесів і ряд додаткових

параметрів (контекст), які використовуються при виконанні операцій передачі

даних. парні операції передачі даних виконуються тільки для процесів, які

належать одному і тому ж комунікатору. Колективні операції застосовуються

одночасно для всіх процесів комунікатора. Створення комунікаторів робиться для

зменшення області дії колективних операцій і для усунення взаємного впливу

різних виконуваних частин паралельної програми. Комунікаційні операції,

виконувані з використанням різних комунікаторів, є незалежними і не впливають

один на одного. Всі наявні в паралельній програмі процеси входять до складу

створюваних за умовчанням комунікатора та ідентифікатора

MPI_COMM_WORLD. За необхідності передачі даних між процесами з різних

груп необхідно створювати визначені в стандарті МРІ - 2 глобальні комунікатори

(intercommunicator). Взаємодія між процесами різних груп виявляється

необхідною за достатньо рідких умов і в рамках цього навчального курсу не

розглядається.

Управління групами. Групи процесів можна створити з вже наявних груп.

Як вихідну групу, можна використати групу, пов’язану з визначеним

комунікатором MPI_COMM_WORLD. Іноді може бути корисним комунікатор

MPI_COMM_SELF, визначений для кожного процесу паралельної програми, який

включає тільки цей процес. Для отримання групи, пов’язаної з існуючим

245

комунікатором, застосовується функція:

int MPI_Comm_group(MPI_Comm comm, MPI_Group *group),

де

- comm - комунікатор;

- group - група, пов’язана з комунікатором.

Далі, на основі наявних груп, можна створити нові групи:

- створення нової групи newgroup з наявної групи oldgroup, яка включатиме

до себе процесів - їх ранги перераховуються в масиві ranks:

int MPI_Group oldgroup, int n, int *ranks,

MPI_Group *newgroup),

де

oldgroup - існуюча група;

- n - кількість елементів в масиві ranks;

- ranks - масив рангів процесів, які будуть включені до нової групи;

- newgroup - створена група. newgroup з групи oldgroup, яка

включатиме

- створення нової групи n процесів, чиї ранги не співпадають з рангами,

перерахованими в масиві ranks:

int MPI_Group_excl(MPI_Group olgroup, int n, int *ranks,

MPI_Group *newgroup),

де

- oldgroup - наявна група;

- n - кількість елементів в масиві ranks;

- ranks - масив рангів процесів, які будуть виключені з нової групи;

-newgroup - створена група.

Для отримання нових груп над наявними групами процесів можна виконати

операції об’єднання, перетину та різниці:

- створення нової групи newgroup як об’єднання груп group1 та group2:

246

int MPI_Group_union(MPI_Group group1, MPI_Group group2,

MPI_Group *newgroup),

де

- group1 - перша група;

- group2 - друга група;

- newgroup - перетин груп;

- створення нової групи newgroup як перетину груп group1 та group2:

int MPI_Group_intersection(MPI_Group group1, MPI_Group group2,

MPI_Group *newgroup),

де

- group1 - перша група;

- group2 - друга група;

- newgroup - перетин груп;

- створення нової групи newgroup як різниці груп group1 та group2:

nt MPI_Group_вшааукутсу(MPI_Group group1, MPI_Group group2,

MPI_Group *newgroup),

де

- group1 - перша група;

- group2 - друга група;

- newgroup - перетин груп;

При конструюванні груп може виявитися корисною спеціальна

порожня група MPI_COMM_EMPTY. Ряд функцій МРІ забезпечує отримання

інформації про групу процесів:

- отримання кількості процесів в групі:

int MPI_Group_size(MPI_Group group, int *size),

де

- group - група;

247

- size - кількість процесів в групі.

- отримання рангу поточного процесу в групі:

int MPI_Group_rank(MPI_Group group, int *rank),

де

- group - група;

- rank - ранг процесів в групі.

Після завершення використана група повинна бути видалена:

int MPI_Group_free(MPI_Group *group),

де

- group - група, яка підлягає видаленню (виконання цієї операції не

торкається комунікаторів, в яких використовується група, що видаляється).

Управління комунікаторами. Розглянемо управління

інтеркомунікаторами, які використовуються для операцій передачі даних

всередині однієї групи процесів. Застосування інтеркомунікаторів для обмінів між

групами процесів виходить за межі цього навчального курсу. Для створення

нових комунікаторів існують два основних способи:

- дублювання вже наявного комунікатора:

int MPI_Comm_dup(MPI_Comm oldcom, MPI_comm *newcom),

де

- oldcom - наявний комунікатор, копія якого створбється;

- newcom - новий комунікатор;

- створення нового комунікатора з підмножини процесів наявного

комунікатора:

int MPI_Comm_create(MPI_Comm oldcom, MPI_Group group,

MPI_Comm *newcomm) ,

де

- oldcom - наявний комунікатор;

- group - підмножина процесів комунікатора oldcom;

- newcom - новий комунікатор.

248

Дублювання комунікатора може застосовуватись, наприклад, для усунення

можливості перетину по тегам повідомлень в різних частинах паралельної

програми (в тому числі і при використанні функцій різних програмних бібліотек).

Операція створення комунікаторів колективна, тобто повинна виконуватися всіма

процесами вихідного комунікатора. Для пояснення розглянутих функцій можна

навести приклад створення комунікатора, в якому містяться всі процеси, окрім

процесу, що має ранг 0 в комунікаторі MPI_Comm_WORLD (такий комунікатор

може бути корисним для підтримки схеми організації паралельних обчислень

"менеджер-виконавці"):

MPI_Group WorldGroup, WorkerGroup;

MPI_Comm Workers;

int ranks[1];

ranks[0] = 0;

// Створення групи процесів в МРІ_COMM_WORLD

MPI_Comm_group(MPI_COMM_WORLD, &WorldGroup);

// Створення групи без процесіу з рангом 0

MPI_Group_excl(WorldGroup, 1, ranks, &WorkerGroup);

// Створення комунікатора по групі

MPI_Comm_create(MPI_COMM_WORLD, WorkerGroup, &Workers);

...

MPI_Group_Free(&WorkerGroup);

MPI_Comm_Free(&Workers);

Швидкий і корисний спосіб одночасного створення декількох комунікаторів

забезпечує функція:

int MPI_Comm_split(MPI_Comm oldcom, int split, int key,

MPI_Comm *newcomm),

де

- nidcomm - вихідний комунікатор:

- split - номер комунікатора, якому повинен належати процес:

- key - порядок рангу процеса в створюваному комунікаторі;

249

- newcomm - створюваний комунікатор.

Створення комунікатора відноситься до колективних операцій, тому виклик

функції MPI_Comm_split повинен бути викликаний в кожному процесі

комунікатора oldcom. В результаті виконання функції процеси розділяються на

групи, що не перетинаються, з однаковим значенням параметра split. На основі

сформованих груп створюється набір комунікаторів. Для того, щоб вказати, що

процес не повинен входити до жодного із створюваних комунікаторів, слід

скористатися константою MPI_UNDEFINDED як значення параметра split. При

створенні комунікаторів для рангів процесів в новому комунікаторі вибирається

такий порядок нумерації, щоб він відповідав порядку значень параметрів key

(процес з великим значенням параметра key отримує великий ранг, процеси з

однаковим значенням параметра key зберігають свою відносну нумерацію). Як

приклад, розглянемо задачу зображення набору процесів у вигляді двовимірної

решітки. Нехай є загальна кількість процесів: подальший наступний

фрагмент програми забезпечує отримання комунікаторів для кожної стрічки

створюваної топології:

MPI_Comm comm;

int rank, row;

MPI_Comm_rank(MPI_COMM_WORLD, &rank);

row = rank / q;

MPI_Comm_split(MPI_COMM_WORLD, row, rank, &comm);

За умови виконання цього прикладу, наприклад, коли , процеси з

рангами (0, 1, 2) утворюють перший комунікатор, процеси з рангами (3, 4, 5) -

другий і т.д. Після завершення використання комунікатор повинен бути

видалений, для чого використовується функція:

int MPI_Comm_free(MPI_Comm *comm),

де

- comm - комунікатор, який підлягає видаленню.

Віртуальні топології. Під топологією обчислювальної системи

розуміють структуру вузлів мережі і ліній між цими вузлами. Топологія може

250

бути зображена у вигляді графа, в якому вершини є процесорами (процесами)

системи, а дуги відповідають наявним лініям (каналам) зв’язку. Парні операції

передачі даних можуть бути виконані між будь-якими процесами одного і того ж

комунікатора, а в колективній операції приймають участь всі процеси

комунікатора. Логічна топологія ліній зв’язку між процесами в паралельній

програмі має структуру повного графа (незалежно від наявності реальних

фізичних каналів зв’язку між процесами). Фізична топологія системи є такою, що

апаратно реалізується, і зміні не підлягає (хоч існують засоби побудови мереж, що

програмуються). Залишаючи незмінною фізичну основу, можна організувати

логічне зображення будь-якої необхідної віртуальної топології. для цього

достатньо, наприклад, сформувати той чи інший механізм додаткової адресації

процесів. Використання віртуальних процесів може виявитися корисним з ряду

причин. Віртуальна технологія, наприклад, може більше відповідати наявній

структурі ліній передачі даних. Застосування віртуальних технологій може

помітно спростити зображення і реалізацію паралельних алгоритмів. В МРІ

підтримується два типи топологій - прямокутна решітка довільної розмірності

(декартова топологія) та топологія графа довільного типу. Наявні в МРІ функції

забезпечують лише отримання нових логічних систем адресації процесів, що

відповідають віртуальним топологіям, що формуються. Виконання всіх

комунікаційних операцій повинно здійснюватися, як і раніше, з використанням

звичайних функцій передачі даних з використанням вихідних рангів процесів.

Декартові топології (решітки). Декартові топології, в яких множина

процесів представляється у вигляді прямокутної решітки, а для вказівки процесів

використовується декартова система координат, яка широко застосовується в

багатьох задачах для опису структури наявних інформаційних залежностей. В

числі прикладів таких задач - матричні алгоритми та сіткові методи розв’язування

диференціальних рівнянь в частинних похідних. Для створення декартової

топології (решітки) в МРІ призначена функція:

int MPI_Cart_create(MPI_Comm oldcomm, int ndims, int *dims,

int *periods, int reorder, MPI_Comm *cartcom),

251

де

- ndims - вихідний комунікатор;

- dims - розмірність декартової решітки;

- periods - масив даних ndims, задає кількість процесів в кожному

вимірі решітки;

- reorder - параметр допустимості зміни нумерації процесів;

- cartcomm - створюваний комунікатор з декартовою топологією

процесів.

Операція створення топології є колективною і повинна виконуватися всіма

процесами вихідного комунікатора. Для пояснення призначення параметрів

функції MPI_Cart_create розглянемо приклад створення двомірної решітки , в

якій стрічки і стовпці мають кільцеву структуру (за останнім процесом слідує

перший процес):

// Створення двомірної решітки

MPI-Comm GridComm ;

int dims[2], periods[2], reorder = 1;

dims[0] = dims[1] =4;

periods[0] = periods[1] = 1;

MPT_Cart_create(MPT_COMM_WORLD, 2, dims, periods, reorder,

&GridComm) ;

Слід зауважити, що внаслідок кільцевої структури вимірів сформована в

рамках прикладу топологія є тором. Для визначення декартових координат

процесу за його рангом можна скористатися функцією:

int MPI_Cart_coords(MPI_Comm comm, int rank, int ndims,

int *coords),

де

- comm - комунікатор з топологією решітки;

- rank - ранг процесу, для якого визначаються декартові координати;

- ndims - розмірність решітки;

- coords - декартові координати процесу, що повертаються функцією.

252

Зворотна дія - визначення рангу процесу за його декартовими координатами

- забезпечується використанням функції:

int MPI_Cart_rank(MPI_Comm comm, int *rank),

де

- comm - комунікатор з топологією решітки;

- coords - декартові координати процесу;

- rank - ранг процесу, що повертається функцією.

Важлива процедура розбиття решітки на підрешітки меншої розмірності

забезпечується з використанням функції:

int MPI_Cart_sub(MPI_Comm comm, int *subdims, MPI_Comm

*newcomm),

де

- comm - вихідний комунікатор з топологією решітки;

- subdims - масив для вказівки, які виміри повинні залишитися в

створюваній підрешітці;

- newcomm - створюваний комунікатор з підрешіткою.

Операція створення підрешіток також колективна і повинна виконуватися

всіма процесами вихідного комунікатора. В ході свого виконання функція

MPI_Cart_sub визначає комунікатори для кожної сполуки координат фіксованих

вимірів вихідної решітки. Для пояснення функції MPI_Cart_sub доповнимо

розглянутий раніше приклад створення двомірної решітки і визначимо

комунікатори з декартовою топологією для кожної стрічки і стовпця решітки

зокрема:

// Створення комунікаторів для кожної стрічки і стовпця решітки

MPI_Comm RowComm, ColCom,

int subdims[2];

// Створення комунікаторів для стрічок

subdims[0] = 0; // фіксації виміру

subdims[1] = 1; // наявність даного виміру в підрешітці

RowComm);

253

// Створення комунікаторів для стовпців

subdims[0] =1;

subdims[1] =0;

MPI_Cart_sub(GridComm, subdims, & ColCom);

В наведеному прикладі для решітки з розміром створюються 8

комунікаторів, по одному для кожної стрічки і стовпця решітки. для кожного

процесу, що визначається комунікатором RawComm та ColComm, відповідають

стрічці та стовпці, до яких даний цей процес належить. Додаткова функція

MPI_Cart_shift забезпечує підтримку процедури послідовної передачі даних по

одному з вимірів решітки (операція зсуву даних). В залежності від періодичності

виміру решітки, по якому виконується зсув, розрізняються два типи операції:

- циклічний зсув на елементів впродовж виміру решітки - в mod dim, де

dim є розміром виміру, впродовж якого відбувається зсув;

- лінійний зсув на позицій впродовж виміру решітки - в цьому варіанті

операції дані від процесу пересилаються процесу (якщо такий існує).

Функції MPI_Cart_shift забезпечує отримання рангів процесів, з

якими поточний процес (процес, який викликає функцію MPI_Cart_shift) повинен

виконати обмін даними:

int MPI_Card_shift(MPI_Comm comm, int dir, int disp, int *source,

int *dist),

де

- comm - комунікатор з топологією решітки;

- dir - номер виміру, по якому виконується зсув;

-disp - величина зсуву (за від’ємних значень зсув здійснюється до

початку вимірювання);

- source - ранг процесу, від якого повинні бути отримані дані;

- dst - ранг процесу, якому повинні бути відправлені дані.

Слід відмітити, що функція MPI_Cart_shift тільки визначає ранги процесів,

між якими повинен бути виконаний обмін даними в ході операції зсуву.

Безпосередня передача даних може бути виконана, наприклад, з використанням

254

функції MPI_Sendrecv.

Топології графа. Інформація по функціям МРІ для роботи з віртуальними

топологіями типу граф будуть розглянуті більш коротко. Для створення

комунікатора з топологією типу граф в МРІ призначена функція:

int MPI_Graph__create(MPI_Comm oldcom, int nnodes, int *index,

int *edges, int reorder, MPI_Comm *graphcom),

де

- oldcom - вихідний комунікатор;

- nnodes - кількість вершин графа;

− - index - кількість вихідних дуг для кожної вершини;

− - edges - послідовний список дуг графа;

− - reoder - параметр допустимості зміни нумерації процесів;

− - graphcom - створюваний комунікатор з топологією типу граф.

Операція створення топології є колективною і, тим самим, повинна

виконуватися всіма процесами вихідного комунікатора.

Рисунок 3.9 – Приклад графа для топології типу зірка

Для прикладу створимо топологію графа із структурою, поданою на рис.

3.9. В цьому випадку кількість процесів становить 5, порядки вершин (кількості

дуг, що виходять) приймають значення (4, 1. 1, 1, 1), а матриця інцидентності

(номери вершин, для яких дуги є вхідними) має вигляд:

Процеси Лінії зв’язку

0 1, 2, 3, 4

1 0

2 0

255

3 0

4 0

Для створення топології з графом даного типу необхідно виконати такий

програмний код:

/* Створення топології типу зірка */

int index[ ] = {4, 1, 1, 1, 1};

int edges[ ] = {1, 2, 3, 4. 0, 0, 0, 0, };

MPI_Comm StarComm StarComm;

MPI_Graph_create(MPI_COMM_WORLD, 5, index, edges, 1, &StarComm);

Наведемо ще дві корисні функції для роботи з топологіями графа. Кількість

сусідніх процесів, в яких від процесу, що перевіряється, є вхідні дуги, можна

отримати з використанням функцій:

int MPI_Graph_neighbors_count(MPI_Comm comm, int rank,

int *nneighbors),

де

- comm - комунікатор з топологією типу граф;

- rank - ранг процесу в комунікаторі;

- nneighbors - кількість сусідніх процесів.

Отримання рангів сусідніх вершин забезпечується функцією:

int MPI_Graph_neighbors(MPI_Comm comm, int rank,

int *nneighbors),

де

- comm - комунікатор з топологією типу граф;

- rank - ранг процесу в комунікаторі;

- neighbors - ранги сусідніх в графі процесів,

- mneighbors - розмір масиву neighbors.

Загальна характеристика середовища виконання МРІ - програм. Для

проведення паралельних обчислень в обчислювальній системі повинно бути

встановлене середовище виконання МРІ - програм, яке б забезпечувало розробку,

компіляцію, компоновку та виконання паралельних програм. Для виконання

256

першої частини перерахованих дій - розробки, компіляції, компоновки достатньо

звичайних засобів розробки програм (таких, як Microsoft Visual Studio), необхідна

лише наявність тієї чи іншої бібліотеки МРІ. Для виконання паралельних програм

від середовища виконання потрібно ряд додаткових можливостей, серед яких

наявність засобів вказівки використовувапних процесорів, операцій віддаленого

запуску програм і т.д. Бажаною є наявність в середовищі виконання засобів

профілювання, трасування та відлагодження паралельних програм. Нь цьому

стандартизація закінчується (стандарт МРІ - 2 дає певні рекомендації про те, як

повинно бути організовано середовище МРІ - програми, проте вони не є

обов’язковими). Є декілька різних середовищ виконання МПІ - програм, в

більшості випадків вони створюються сумісно з розробкою тих чи інших

варіантів МРІ - бібліотек. Як правило, вибір реалізації МРІ - біьліотек,

встановлення середовища виконання і підготовки\а інструкцій з використання

здійснюється адміністратором обчислювальної системи. Інформаційні ресурси

Інтернету, на яких розташовуються вільно використовувані реалізації МРІ, та

промислові версії МРІ містять вичерпну інформацію про процедури установки

МРІ, і виконання всіх необхідних дій не є чимсь складним. Запуск МПІ -

програми також залежить від середовища виконання, але в більшості випадків ця

дія виконується з використанням команди mpirum (стандарт МРІ - 2 рекомендує

використовувати команду mpiexec). В числі можливих параметрів цієї команди;

- режим виконання - локальний чи багатопроцесорний; локальний режим як

правило вказується з використанням ключа - localony, при виконанні паралельної

програми в локальному режимі всі процеси програми розташовуються на

комп’ютері, з якого процеси програми розташовуються на комп’ютері, з якого був

здійснений запуск програми. Такий спосіб виконання дуже корисний для

початкової перевірки працездатності та відладки паралельної програми, частина

такої роботи може бути виконана навіть на окремому комп’ютері поза рамками

багатопроцесорної обчислювальної системи;

- кількість процесорів, які слід створити при запуску паралельної програми;

- склад використовуваних процесорів, який визначається тим чи іншим

257

конфігураційним файлом;

- виконуваний файл паралельної програми;

- командна стрічка з параметрами для виконуваної програми.

Є значна кількість інших параметрів, які використовуються при розробці

достатньо складних паралельних програм - їх опис подається в довідково-

інформаційній літературі з відповідного середовища виконання МРІ - програм.

При запуску програми на декількох комп’ютерах виконуваний файл програми

слід скопіювати на ці комп’ютери чи він повинен знаходитися на загальному

доступному для всіх комп’ютерів ресурсі.

Додаткові можливості стандарту МРІ - 2. Стандарт МРІ - 2 був прийнятий

в 1997 р. Його використання до цих пір не обмежене. Основними причинами

цього є певний консерватизм розробників програмного забезпечення, складність

реалізації нового стандарту, та ін. Можливостей МРІ - 1 достатньо для реалізації

багатьох паралельних алгоритмів, а сфера застосування додаткових можливостей

МРІ - 2 виявляється не настільки широкою. Для знайомства із стандартом МРІ - 2

можна рекомендувати інформаційний ресурс http://www.mpiforum.org. Наведемо

коротку характеристику додаткових можливостей стандарту МРІ - 2:

- динамічне породження процесів, коли процеси паралельної програми

можуть створюватися і знищуватися в ході виконання;

- однобічна взаємодія процесів, що дає змогу бути ініціатором операції

передачі і прийому даних тільки одному процесу;

- паралельние введення/виведення, яке забезпечує спеціальний інтерфейс

для роботи процесів з файловою системою;

- розширення можливостей колективних операцій, до числа яких входить

(як приклад) взаємодія через глобальні комунікатори (intercommunicator);

- інтерфейс для алгоритмічних мов С++ та Fortran 90.

258

3.4. Контрольні питання

1. В чому полягає сутність поняття МРІ?

2. Як розуміти поняття "паралельне програмування"?

3. Як визначаються кількість і ранг процесів?

4. В чому полягає стандартний режим відправки повідомлення?

5. Як утворюється найменування найменування неблокуючих аналогів?

6. Що розуміють під поняттям "колективні операції передачі даних"?

259

ЛІТЕРАТУРА

1. Foster L., Kesselman C., Tuecke S. The Anatomy of the Grid: Enabling

Scalable Virtual Organizations. - International 1. Supercomputer Applications, 15(3),

2001.

2. Foster L., Kisl1imoto H., Savva A., Beny D. et al. The Open Grid Services

Architecture. - Global Grid Forum, 2005.

3. Foster L., Kesselman C., Tuecke S., Nick J.M. The Physiology of the Grid:

An Open Grid Services Architecture for Distributed Systems Integration. – Morgan

Kaufrnann Publishers, 2002.

4. Проект «Розробка та впровадження типових рішень щодо комплексної

системи захисту інформації в АІС НАНУ» Шифр –КСЗІ АІС НАНУ Безпека GRID

– технологій. Огляд технічних рішень. 2009. 79 ст.

5. Web Service Modelling Ontology. – Режим доступу:

http://www.wsmo.org/.

6. MetaObject Facility. - Режим доступу: http://www.omg.org/mof/.

7. Naseer, A. and Stergioulas, L.K., Integrating Grid and web Services: A

Critical Assessment of Methods and Implications to Resource Discovery, World-Wide

Web Conference (WWW2006)

8. Erl, Thomas. Service-Oriented Architecture: Concepts, Technology &

Design. New York: Prentice Hall/PearsonPTR. 2005

9. Foster I., Kesselman C., Nick J.M., Tuecke S. The Physiology of the Grid.

An Open Grid Services Architecture for distributed systems integration // Grid

Computing: Making the Global Infrastructure a Reality. New York: Wiley & Sons,

2003. P. 217-250.

10. Globus Toolkit - The Globus Alliance - www.globus.org/toolkit

11. UNICORE - Distributed computing and data resources - www.unicore.eu

12. Tuecke, S., Czajkowski, K., Foster, I., Frey, J., Graham, S., Kesselman, C.,

Maguire, T., Sandholm, T., Snelling, D., and Vanderbilt, P. (2003) Open Grid Services

Infrastructure (OGSI) Version 1.0. // Global Grid Forum - www.ggf.org.

260

13. Czajkowski, K., Ferguson, D., Foster, I., Frey, J., Graham, S., Sedukhin, I.,

Snelling, D., Tuecke, S., and Vambenepe, W. The WS-Resource Framework. March 5,

2004.

14. Eric Newcomer. Understanding Web Services: XML, WSDL, SOAP, and

UDDI. Addison-Wesley, USA, 2002 – 368 р.

15. L. Clement, A. Hately, C. Riegen, and T. Rogers. UDDI Version 3.0.2.

OASIS, Tech. Rep., 2004.

16. Jungho Jang, Buhwan Jeong, Hyunbo Cho, and J. Lee. Capability and

Extension of UDDI Framework for Semantic Enterprise Integration. Proceedings of

International Conference on Advances in Production Management Systems,

Washington D.C., September 18-21, 2005.

17. C. Goodwin, D.J. Russomanno and J. Qualls. Survey of Semantic

Extensions to UDDI: Implications for Sensor Services. Proceedings of the International

Conference on Semantic Web and Web Services, CSREA Press, Las Vegas, Nevada,

2007 - pp. 16-22.

18. Web Services Addressing Working Group -

http://www.w3.org/2002/ws/addr/

19. OASIS Web Services Security (WSS) TC -

www.oasis-open.org/committees/wss

20. Globus Toolkit Version 4 Grid Security Infrastructure: A Standards

Perspective. The Globus Security Team. Version 4, September 12, 2005

21. Fielding, Roy T.; Taylor, Richard N. Principled Design of the Modern Web

Architecture. ACM Transactions on Internet Technology (TOIT). New York:

Association for Computing Machinery. 2002: 115–150

22. Демичев А., Крюков А., Шамардин Л. Принципы построения грид с

использованием restful-веб-сервисов // Программные продукты и системы. 2009.

№ 4

23. OASIS Web Services Business Process Execution Language (WSBPEL)

TC - www.oasis-open.org/committees/wsbpel

261

24. Ian Foster, Steve Tuecke, David Snelling, Don Ferguson, Jeff Frey, Steve

Graham, Tom Maguire, Karl Czajkowski. From Open Grid Services Infrastructure to

WS-Resource Framework: Refactoring and Evolution. K. 2004

25. Toma, I., Iqbal, K., Roman, D., Strang, T., Fensel, D., Sapkota, B., Moran,

M., Gomez, J.M.: Discovery in grid and web services environments: A survey and

evaluation. International Journal on Multiagent and Grid Systems 3 (2007)

26. Onyeka Ezenwoye and S. Masoud Sadjadi, Ariel Carey, and Michael

Robinson. "Grid service composition in BPEL for scientific applications". In

Proceedings of the International Conference on Grid computing, high-performAnce and

Distributed Applications (GADA'07), Vilamoura, Algarve, Portugal, November 2007.

27. T. Fleuren and P. Müller, "BPEL Workflows Combining Standard OGC

Web Services and Grid-enabled OGC Web Services" in Proceedings of the 34th

Euromicro Conference on Software Engineering and Advanced Applications, Parma,

Italy 2008.

28. Tim Dörnemann, Thomas Friese, Sergej Herdt, Ernst Juhnke, Bernd

Freisleben. Grid Workflow Modelling Using Grid-Specific BPEL Extensions. In:

Proceedings of German e-Science Conference , Baden-Baden , 2007

29. Guido Scherp, André Höing, Stefan Gudenkauf, Wilhelm Hasselbring,

Odej Kao: Using UNICORE and WS-BPEL for Scientific Workflow Execution in Grid

Environments. Euro-Par Workshops 2009: 335-344

30. Diwakar, D.; Diwakar, S., “CINWEGS- An Integrated Web and Grid

Services Framework for Collaborative Solutions,” Next Generation Web Services

Practices, 2008. NWESP '08. 4th International Conference, pp. 21 – 27, 2008.

31. Бабу Сандарам. Что такое WSRF, Часть 1: Использование WS-

ResourceProperties. Пер. с англ.: Бродская И.М., Ухов Л.В. – ИПМ РАН. 2005. –

44с.

32. Конноли Томас, Бегг Каротин, Страчан Анна. Базы данных:

проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с

англ. : уч. пос. – М.: Издательский дом "Вильямс", 2000. – 1120 с.

262

33. Петренко А.І., Булах Б.В.,Хондар В.С/ Семантичні грід- технології для

науки і освіти:додатковий матеріал.

34. Шелестов А.Ю. Методи, моделі і технології аналізу та створення Grid-

систем для задач дослідження Землі. Київ – 2008.

35. Молчанов И.Н. Введение в алгоритмы параллельних вычислений. -

Киев: Наукова думка, 1991. - 195 с.

36. Гергель В.П. Теория и практика параллельных вычислений/Гергель

В.П. – М.:ИНТУИР.РУ Интернет-Университет Информационных технологий,

2007.

37. Воеводин В.В., Воеводин Вл.В. Параллельные вычисления. /еводин

В.В. – СПб.: БХВ-Петербург, 2002.

38. Аксак Н.Г. Паралельні та розподілені обчислення: пірдуч./ НГ.Аксак,

О.Г. Руденко, А.М.Гуржій. – Х.:Компанія СМІТ, 2009. – 480с. 

39. Эндрюс Г.Р. Основы многопоточного, параллельного и

распределенного программирования /Эндрюс Г.Р. – М.: «Вильямс», 2003. – 512 с.

40. Богачев К.Ю. Основы параллельного программирования. /Богачев

К.Ю. – М.: БИНОМ. Лаборатория знаний, 2003.

41. Фельдман Л. П., Назарова І.А. Паралельні однокрокові методи

чисельного розв’язання задачі Коші. Донецьк: «ДВНЗ» ДонНТУ, 2011. – 185 с.: іл.

42. М.В. Якобовский. Распределенные системы и сети . Учебное пособие.

– М: МГТУ «Станкин», 2000. – 118с., ил.

43. Дорошенко А.Ю. Лекції з паралельних обчислювальних систем. Київ:

Видавничий дім “КМ Академія”, 2003. – 42 с.

44. Г.Ю. Сисюк, О.А. Дурницька. Методичні вказівки "Паралельне

програмування" до лабораторних робіт для студентів зі спеціальностей

7.091501«Комп’ютерні системи та мережі» денної форми навчання. Кременчук:

КНУ, 2003. – 19с.

45. Аллен П. и др. J2EE. Разработка бизнес-приложений. — М.: ДиаСофт,

2002.

263

46. Амриш К., Ахмед Х. З. Разработка корпоративных Java-приложений с

использованием J2EE и UML. — М.: Изд. дом “Вильямс”, 2002.

47. Блэк Ю. Сети ЭВМ: протоколы, стандарты, интерфейсы. — М.: Мир,

1990.

48. Вязовик Н. А. Программирование на Java. — М.: Интернет-ун-т

информационных технологий — ИНТУИТ.РУ, 2003.

49. Дейтел Х. М. и др. Технологии программирования на Java 2. — М.:

Бином-пресс, 2003. — Кн. 3. Корпоративные системы, сервлеты, JSP, Web-

сервисы.

50. Джонс Э., Олант Д. Программирование в сетях Microsoft Windows.—

СПб.: Питер, 2002.

51. Как программировать на Java. — М.: Бином-пресс, 2003. — Кн. 1.

Основы программирования.

52. Перроун П. и др. Создание корпоративных систем на основе Java 2

Enterprise Edition. Руководство разработчика. — М.: Изд. Дом “Вильямс”, 2001.

53. Хорстманн К. С., Корнелл Г. Библиотека профессионала: Java 2. —

М.: Изд. дом “Вильямс”, 2004. — Т. I. Основы. — 848 с.; Т. II. Тонкости

программирования. — 1120 с.

54. Эккель Б. Философия Java. — СПб.: Питер, 2001.

55. Л.С. Глоба. Підручник. Розробка інформаційних ресурсів та систем.

(Том 1: «Розподілені системи», «Розподілені системи. Поняття розподіленого

середовища», «Зв’язок», «Процеси», «Іменування», «Синхронизація»). для

студентів спеціальностей 8.092401 «Телекомунікаційні системи та мережі»

8.092402 «Інформаційні мережі зв’язку». Київ – 2011. 414с.

56. http://uk.wikipedia.org/wiki/Кластер_(Інформатика)

57. Методичні вказівки до виконання лабораторних робіт з дисципліни

“Технології розподілених систем та паралельних обчислень” для студентів денної

та заочної форм навчання спеціальності 7.05010101 “Інформаційні управляючі

системи та технології”.

264

58. Берченко М.М., Березовська І.Б. Багатоядерні процесори:

мікроархітектура та особливості застосування. Тернопіль: ТНТУ, 2011

59. Берченко М.М., Березовська І.Б. Багатоядерні процесори:

мікроархітектура та особливості застосування. Львів: Ліга-Прес 2009

60. Васюра А.С., Мартинюк Т.Б., Куперштейн Л.М. Методи та засоби

нейроподібної обробки даних для систем керування. Вінниця: УНІВЕРСУМ-

Вінниця, 2008

61. Адамар Ж. Задача Коши для линейных уравнений с частными

производными гиперболического типа. М.: Наука, 1978.

62. Под ред. Р.А. Нелепина. Алгоритмический синтез нелинейных систем

управления. Ленинград: Издательство Ленинградского университета, 1990

63. Куфнер А., Фучик С. Нелинейные дифференциальные уравненияю.

М.: Наука 1988

64. Галіцин В.К., Левченко Ф.А. Багатокористувацькі обчислювальні

системи та мережі. К.: КНЕУ, 1998.

65. Корнеев В.В. Параллельные вычислительные системы. - М.: Нолидж,

1999 г.

66. Воеводин В.В., Воеводин Вл.В. Параллельные вычисления. - СПб.:

БХВ-Петербург, 2002 г.

67. Гергель В.П. Теория и практика параллельных вычислений. Учебное

пособие. - М.: Интернет-Университет Информационных Технологий; БИНОМ.

Лаборатория знаний, 2007 г.

265